デベロッパー

どこで実行すべきか。Google Cloud のコンピューティング オプションの選択

where should i

※この投稿は米国時間 2021 年 7 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

どこでワークロードを実行すべきでしょうか。アプリケーション自体にとっても、そのアプリケーションの管理と開発を行うチームにとっても、実行するアプリケーションに適したインフラストラクチャ オプションを選択することが重要です。この投稿では、実行場所を決定するときに検討する必要がある特に重要な要素をいくつか取り上げて説明します。

サービスについて

  • Compute Engine - 仮想マシン。CPU、メモリ、ディスク、GPU の構成を予約して、実行する OS と追加ソフトウェアを決めます。

  • Kubernetes Engine - マネージド Kubernetes クラスタ。Kubernetes は、コンテナ化アプリケーションのデプロイ、スケーリング、管理を自動化するオープンソース システムです。クラスタを作成し、実行するコンテナを構成すると、Kubernetes がコンテナの実行を続け、スケーリング、アップデート、接続を管理します。

  • Cloud Run - コンテナを個別に実行するフルマネージドのサーバーレス プラットフォーム。コードまたはコンテナを指定すると、Cloud Run がホスティングして、ウェブやその他のイベントに対応できるよう、必要に応じて自動スケーリングします。

  • App Engine - ウェブ アプリケーション全体のための、フルマネージド型のサーバーレス プラットフォーム。App Engine は、ネットワーキング、アプリケーションのスケーリング、データベースのスケーリングを行います。サポートされるいずれかの言語でウェブ アプリケーションを作成し、App Engine にデプロイすると、スケーリング、バージョン更新などが処理されます。

  • Cloud Functions - イベント ドリブンのサーバーレス ファンクション。個別のファンクションのコードを作成すると、イベント(HTTP、Pub/Sub、Cloud Storage の変化など)が発生したときに、Cloud Functions がこのファンクションを呼び出します。

必要な抽象化のレベル

  • 基になるインフラストラクチャ(オペレーティング システム、ディスク イメージ、CPU、RAM、ディスクなど)をより詳細に制御する必要がある場合は、Compute Engine が適しています。これは、古いアプリケーションの移行や、特定の OS を必要とする既存のシステムによく使われるパスです。

  • コンテナを使うと OS を仮想化できます。これにより、1 つの OS インスタンスで複数のワークロードを実行できます。軽量で速く、ポータビリティも得られます。アプリケーションをコンテナ化する場合、オプションは主に 2 つあります。

    • 特定の OS、CPU、GPU、ディスク、メモリ、ネットワーキングのノードまで、コンテナを完全に制御する必要がある場合は、Google Kubernetes Engine(GKE)を使用することをおすすめします。柔軟性と制御は必要だが、運用とエンジニアリングのサポートが限られている場合は、GKE の Autopilot を利用できます。

    • インフラストラクチャのスケーリングを気にせずにコンテナのアプリケーションを実行したいだけであれば、Cloud Run が最適です。アプリケーション コードを作成して、コンテナにパッケージ化し、デプロイするだけです。

  • スケーラビリティと Google Cloud へのデプロイのことを考えずに HTTP ベースのアプリケーションをコーディングしたいだけであれば、ウェブ アプリケーションのホスティングと実行を行うように設計されたサーバーレスのフルマネージド オプションである App Engine が適しています。

  • コードがファンクションで、イベント / トリガーに基づいてアクションを実行するだけであれば、Cloud Functions でデプロイすることをおすすめします。

ユースケース

  • Compute Engine を使用するのは、特定のライセンス、OS、カーネル、ネットワーキングの要件がある古いアプリケーションを移行する場合です。例: Windows ベースのアプリケーション、ゲノミクス処理、SAP HANA。

  • GKE を使用するのは、アプリケーションが特定の OS または HTTP/s 以外のネットワークプロトコルを必要とする場合です。GKE を使用する場合、Kubernetes により、ハイブリッド環境やマルチクラウド環境へのデプロイと拡張が簡単になります。Anthos は、ハイブリッド デプロイとマルチクラウド デプロイのために特に設計されたプラットフォームです。インフラストラクチャからアプリケーションのパフォーマンスとトポロジまで、すべてのクラスタを 1 か所で明瞭に確認できます。例: マイクロサービス ベースのアプリケーション。

  • Cloud Run を使用するのは、HTTP/s と WebSocket をサポートする、任意のプログラミング言語で作成したコンテナ化されたアプリケーションをデプロイするだけの場合です。例: ウェブサイト、API、データ処理アプリ、Webhook。

  • App Engine を使用するのは、ウェブベースのアプリケーション(HTTP/s)をサーバーレス プラットフォームにデプロイしてホスティングする場合です。例: ウェブ アプリケーション、モバイルアプリのバックエンド

  • Cloud Functions を使用するのは、コードがファンクションで、Pub/Sub または Cloud Storage からのイベント / トリガーに基づいてアクションを実行するだけの場合です。例: Cloud Storage バケットに動画が保存されたらすぐに、動画のコード変換ファンクションを起動する。

オープンソースでのポータビリティが必要かどうか

ポータビリティとオープンソースのサポートが必要な場合は、GKE、Cloud Run、Cloud Functions を検討します。これらはすべて、オープンソースのフレームワークに基づいていて、ベンダー ロックインの回避に役立ち、インフラストラクチャをハイブリッド環境またはマルチクラウド環境に拡張できます。GKE クラスタは Kubernetes を利用します。Kubernetes は、クラスタ操作のメカニズムを提供するオープンソース クラスタ管理システムです。Cloud Run for Anthos は Knative を利用します。Knative は、Kubernetes でサーバーレス ワークロードをサポートするオープンソース プロジェクトです。Cloud Functions はオープンソースの FaaS(Function as a service)を使用します。FaaS は、複数の環境でファンクションを実行するフレームワークです。

チームの規模

小規模なデベロッパーのチームで、コードに集中したい場合は、Cloud Run や App Engine のようなサーバーレスのオプションが適しています。これらのオプションを利用すると、チームでインフラストラクチャ、スケーリング、運用の管理をする必要がなくなります。独自のツールやプロセスを使用している大きなチームには、Compute Engine または GKE の方が適しています。これらのオプションでは、CI / CD、セキュリティ、スケーリング、運用のプロセスを独自に定義できます。

課金モデルのタイプ

Compute Engine と GKE の課金モデルはリソースベースとなっていて、使用状況に関係なく、プロビジョニングしたインスタンスに応じて課金が発生します。継続利用割引と確約利用割引もあります。

Cloud Run、App Engine、Cloud Functions はリクエストごとの課金、つまり従量制です。

まとめ

アプリケーションに適したコンピューティング オプションを決めるには、関係するすべての要素を検討する必要があります。ただし、最終決断をする必要はありません。オプションはいつでも変更できます。

これらのポイントについて詳しくは、動画 Where Should I Run My Stuff? をご覧ください。

#GCPSketchnote をさらにご覧になるには、GitHub リポジトリthecloudgirl.dev をフォローしてください。同様のクラウド コンテンツについては、Twitter で @pvergadia@briandorsey をフォローしてください。

-Google デベロッパー アドボケイト Priyanka Vergadia

-デベロッパー アドボケイト Brian Dorsey