DI-APP-03 2023 年版: アプリケーションをどこで動かすべきか 受講メモ

はじめに(受講動機)

• App Engine
• Cloud Functions
• Cloud Run
• Compute Engine
• Google Kubernetes Engine (GKE)

全てアプリケーションを実行する環境です。自分がGoogle Cloud を使い初めた頃(2016年頃?)、App Engine と Compute Engineのみが選択肢だったのですが(コンテナサービスもあったかもしれません)、今はいろいろサービスがふえています。2023年時点では何をつかうべきかのか? という点での知見が得られるということで受講しようとおもいました。
個人的には、上から下にいくほど開発規模が大きくなるイメージがあります。

セッションまとめ

• ユースケースによって使うサービスを選ぼう
• 柔軟性が高い順は Compute Engine、GKE、Cloud Run、Cloud Functions、App Engine
• 柔軟性が低い = 抽象度が高いということでメンテナンスの手間は減るので運用コスト的には有利
• Cloud RunよりApp Engineのほうがスケーリング耐性が高い
• バッチ用途であれば Cloud Batchもある
• Cloud Workstations with Duet AI で コード生成/補完がある開発環境を一元提供できる

このセッションでは、大きく二つを理解することがゴールとのことでした。

• Google Coudのアプリケーション基盤を適切に選択することができる
• ローカル開発からGoogle Cloudにアプリケーションをデプロイするまでの流れを理解する

個人的に前半につよく興味をもっているため、セッションの流れにそって、各アプリケーション基盤の特徴とユースケース、環境選択についての説明内容をふりかえります。写真禁止と勘違いをしていて画像がありませんが(フラッシュ写真禁止でした)、セミナー資料が公開されましたら追加したいとおもいます。
後半のデプロイの流れの話は割愛しています。ごめんなさい。

アプリケーション基盤の選択肢

抽象度と柔軟性という観点が紹介されました。
抽象度があがると柔軟性は減るが、メンテナンス割く時間も下がる。逆に抽象度が低いサービスは柔軟性が高くいろいろ出来るが、メンテナンス時間も増える。この観点で各サービスとユースケースを説明がありました。

個人的には実行時間のコストの話もいれてほしかったのですが、今回はスコープ外のようでした。

各サービスの概要、特徴、ユースケースの説明がつづきます。

Compute Engine

仮想マシン サービス。以下が利用可能

• 最大vCPU数 416
• 最大メモリ 12 TB
• Local SSD
• GPU
• LinuxとWindowsが利用可能

特徴

• ライブマイグレーション
• カスタムマシンタイプ(vCPUとメモリを別個に設定可能)
• インスタンスグループ
• 秒単位での課金

ユースケース

• サードパーティー アプリケーションの実行
• 物理マシン/仮想マシンのアプリケーション移行

GKE

フルマネージドなKubernetes サービス

• Kunernetesのエコシステムを活用
• Standard : ノード設定の柔軟性 (ノードprovisioning 、 セキュリティ、ネットワーク設定)
• Autopilot : ノード管理もGoogle にまかせられる

GKE Standard の特徴

• HIPPAとPCIDSSに準拠
• 自動スケーリング
• アップグレード、ノードを修復 (ここちょっと自信ないです)
• ハイブリッド/マルチクラウドが可能

GKE Autopilot の特徴

• ノード管理不要
• Pod単位での課金
• PodへのSLAが存在

GKEのユースケース

• マイクロサービスアーキテクチャにおける大規模Webアプリケーション
• データ処理基盤

GKE Standardのユースケース

• ノード設定変更が必要なゲームのバックエンド
• GPU/TPUを使うMLパイプライン

GKE Autopilotのユースケース

• 負荷テストツール環境
  (個人的に、負荷テストツールだけにGKEを利用するのも良いですが、基本はAutopilotを利用して、必要であればStandardを選択するのも一つの手段だと感じました)

Cloud Run

コンテナサービス

• 100ms毎の課金
• 最大 8 VCPU/32GB RAMが利用可能
• KnativeとAPI互換

特徴

• コンテナデプロイでURLが発行
• HTTP/2 WebSocket gRPC 等に対応
• 高度なトラフィック管理
• 0-Nの高速スケーリング
• イベント駆動も可

Cloud Run 第二世代

• CPU/ネットワークの性能向上
• システムコールなどLinuxと完全互換
• NFS/CIFS/Ceph等のネットワークファイルシステムのサポート

Cloud Run Jobs

• HTTPリクエストによらない実行
• 最大24時間の実行が可能
• 明示的な並列処理やリトライ回数を定義可能

ユースケース

• ステートレスなバックエンド
• (小規模な)マイクロサービスの構築
• 軽量なデータ変換処理
• (Cloud Storage トリガ等からの)イベント駆動処理

App Engine

アプリケーション実行基盤

• 2008年からサービス提供(信頼、実績が高い)
• 対応言語が存在
• フレキシブルはコンテナイメージに対応

ユーザーケース

• スパイク特性のあるWebアプリケーション (スケール性能がCloud Runよりも高い)
• 静的、動的コンテンツを利用するWebアプリケーション
• モバイルバックエンド

Cloud Functions

Function as a Service

• 100ms毎の課金
• 他のGoogle Cloudサービスとのイベント連携
• 最大8vCPU、32GiBメモリが利用可能

ユースケース

• サードパーティサービスAPIとの統合
• リアルタイムファイル処理 (イベント駆動処理が得意)

スライドで説明されたアプリケーション基盤は以上ですが、説明として Batch for Google Cloud も紹介されていました。完全マネージドのバッチ処理を作りたい場合には利用できるという事でしたが、 Cloud Run for Job との違い等の説明はなかったと思います。

アプリケーションをどこで動かすべきか?

※ここ、あまりメモがなくて実際の話とずれているかもしれません。

ユースケースにあわせて選択する、という話でしたが、具体的にこういう場合はこの基盤が鉄板! という話や、質問に答えるだけでこの基盤になるというような話はありませんでした。

向いていない基盤を選択することも必要ならばあり、という話もしていたかとおもいます。自分の例をあげるとすると、以下のような場合かなと理解しました。

• 将来の拡張を考えKubernetes基盤を導入する
• 運用者のスキルセット的にCompute Engineを利用する

アプリケーションの想定する規模や寿命、開発者/運用者のスキルセット、等を考えて適材適所で作っていくのは昔も今もかわらずですね。ただ、手軽さと運用の容易さから、多くの用途では第一選択肢としてはサービスはCloud Run、システム間連携はCloud Functionで考え、特別の事情があれば別の選択肢を考えるというのがよいのかなと感じました。