グーグル・クラウド・ジャパンは7月18日、オンラインで第2回目となるコンテナとサーバレスに関連したサービスについてメディア向け勉強会を開催した。すでに第1回は6月に開催しており、今回は「Google Kuberntes Engine(GKE)」と「Cloud Run」を解説するとともに、SOMPOシステムズの導入事例が紹介された。
「マネージド」と「シンプル」を備えるGoogle Cloud
Google Cloudは、クラウドネイティブのアプリケーション開発・実行・運用に関わる機能をエンドツーエンドで提供するアプリケーションプラットフォームと位置付けている。
そのアプリケーション実行基盤について、グーグル・クラウド・ジャパン 技術部長(インフラ、アプリケーション開発)の安原稔貴氏は「複雑な初期構築や管理が不要で、比較的容易に使いはじめることができ、内製化をスタートしやすい」とし、「マネージド」と「シンプル」の2点に強みがあり、GKEとCloud Runもこれらの特徴を備えているという。
Google Kuberntes Engineの特徴
GKEはGoogle Cloud上でコンテナ化されたアプリケーションをデプロイ、運用管理を行うためのKubernetesのマネージドサービス。負荷分散や自動スケーリング、アップグレード、ノード修復をはじめ高度なクラスタ管理機能を備え、Kubernetes運用のペストプラクティスをマネージドサービスとして提供し、HIPPAやPCI DSSなど各種コンプライアンスに準拠している。
GKEクラスタを作成すると、管理用コンポーネントのコントロールプレーンと、アプリケーション実行環境のノードの2種類のコンポーネントを自動で構築し、それぞれKubernetesのコントロールプレーン、ノードに対応している。
通常のGKEであればコントロールプレーンだけGoogle Cloudが管理し、クラスタとノードの構成・管理はユーザーが行う。
2021年に追加されたAutopilotモードは本番ワークロードに適したベストプラクティスが適用されており、ノードの管理もGoogle Cloudで行う。そのため、アプリケーションエンジニアだけでも管理できることから、要因コストの低減が図れるという。
Cloud Runの特徴
一方、Cloud Runはフルマネージドをベースにしたサーバレス基盤。任意のプログラミング言語でコードを記述してコンテナイメージ化し、デプロイするだけでアプリケーションを実行することができるGoogle Cloudのフルマネージドサービスとなる。
安原氏は「ネットワーク設計などインフラに関する検討や作業が不要なためアプリケーション開発に集中できるほか、1000ノードまでわずか数秒で高速にスケールを可能としている。ともすればサーバレスアーキテクチャはベンダーロックインされると思われがちだが、Cloud RunはKubernetes上にサーバーレスなコンピューティング基盤を構築できるオープンソースソフトウェアのKnativeに準拠しているため、ベンダーロックインは避けられる」と説明する。
Kubernetesと比較してコードの記述後のフローが簡素化されており、コンテナイメージをpushしたあとは1つのコマンドでデプロイして実行が可能。高速な自動スケールについては、特に明示的に設定をしていなくてもリクエスト数に応じてスケーリングを行うため、リクエストが15分程度ない場合はコンテナインスタンスは0になるという。
このような特徴を持つCloud Runは、企業・組織における内製化の一助にもなると安原氏は話す。
企業・組織が内製開発に取り掛かる際、アプリケーション基盤を担当するインフラ運用チームがいないため学習して対応せざるを得ないことや、コンテナに関する知識・スキル不足、初期導入コストが高い、オートスケールの設定をしてもスパイクアクセスの速度に追い付けないといった課題を挙げている。
安原氏は「Cloud Runであればインフラ管理は不要であり、トラフィックがあったときにのみ料金が発生するため、コスト削減につながる。さらに、常に最新のパッチが適用されることからセキュリティを担保できる」と強調した。
SOMPOシステムズにおけるCloud Runの活用事例
続いて、SOMPOシステムズ 損保システム第一本部 副本部長の武井信之氏がCloud Runの実装事例について解説した。
同社がCloud Runを実装した対象システムは「教えて!SOMPO」だ。同システムは損害保険の代理店向け情報や、同社が独自に作成・登録した商品・事務情報など各種コンテンツを横断的に検索することができるというもの。本社と営業店間、営業店と代理店間での照会機能も有している。
アプリケーションアーキテクチャはGoogle Cloudをベースとし、コンピューティングはGoogle App Engine(GAE)、データベースはGoogle Cloud SQLを中心としている。一部コンポーネントはGoogle Compute Engineで構成し、社内向けアプリはGoogle Cloud、代理店向けはMicrosoft Azure、個人情報のマスキング処理はAmazon Web Services(AWS)と、マルチクラウド構成としている。
同システムにおけるCloud Runの実装箇所は、社内ユーザーが検索をする際に入力された文字に応じたサジェストを表示する機能。サジェスト候補の対象文字列をクライアントから直接Cloud Runにリクエストし、超低レイテンシでレスポンスを行い、サジェスト対象の文字列は日々の検索ログからバックエンドで処理して蓄積している。
具体的にはサジェスト機能のゲートウェイになるブブでビジネスロジック以外の機能を担っており、リクエストパラメータのバリデーションチェックや、エラー、応答時間、傾向分析情報といった各種ログの出力、サジェスト機能APIの呼び出しに利用している。
実際、GAEでも対応が可能だったが、当該箇所に実装した理由として将来的に代理店向けに展開することを検討していたことから、GAEの直受けだとファイアウォール設定の観点で課題になる可能性があったほか、相応のトランザクション量が想定されていたが処理自体は軽量かつチューニングも必要ではないと判断したため、Cloud Runを採用した。
武井氏はCloud Runのメリットとして「ソースコードがあれば、Google Cloud SDKのコマンド1つでコンパイルからデプロイまで可能なため取り回しが良い。また、TomcatやNginxなど、Webサーバの導入が自動化されているため迅速に動作させたいときに手間がかからないことに加え、SSL証明書の発行はドメイン取得と同時に自動で行う。デフォルトでオートスケールするためパフォーマンスチューニングをしなくても高負荷に耐えられ、利用者側の学習コストも低い」と効果を口にした。
今後、同社ではCloud Runwoコンピューティングの中心とした新しいアプリケーションの構築を引き続き、検討していくという。これはCloud Runのバッググラウンドの技術を把握するため、練度の高いエンジニアはGKEベースで開発を進めるほか、マルチリージョン構成が必要なアプリケーションにおいての適用も想定し、その場合は分散データベース「Cloud Spanner」と併用した構成設計を計画している。
そして、武井氏は「現在、GAEを利用しているアプリケーションについては順次、Cloud Runへの移行を検討・実行していく。Google Cloudと注力している領域のサービスにシフトすることで、進化の恩恵を直接的に受けやすい状態にしていければと考えている」と展望を語っていた。