コンテンツに移動
Containers & Kubernetes

Google Kubernetes Engine 上で SaaS プラットフォームを作成する

2023年11月30日
Google Cloud Japan Team

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

Software as a Service(SaaS)は、信頼性が高くすぐに使えるプロダクトをエンドユーザーに提供して体験してもらおうとするソフトウェア ベンダーにとって最適な配信方法です。SaaS サービスを構築する際に考慮しなくてはならない検討事項は多数ありますが、その一つが SaaS アプリケーションの実行に使用するフレームワークであることは言うまでもありません。現代のソフトウェア開発ではソフトウェア コンテナが使用されており、最新の SaaS プラットフォームを実行するための最も一般的な選択肢は当然、人気の高いコンテナ オーケストレーターである Kubernetes になります。この投稿では、Google Kubernetes Engine(GKE)で SaaS プラットフォームを構築する際に選択するアーキテクチャを決定するための基本についてご説明します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Creating_a_SaaS_Platform_on_GKE_v1.max-1800x1800.jpg

SaaS アプリケーションに GKE を使用する利点

GKE は、コンテナ化されたアプリケーションをデプロイする本番環境に対応したマネージド環境です。コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソース システムである Kubernetes に基づいており、Google が CNCF に寄付したものです。このプロジェクトには現在も主に Google が協力しています。

GKE は、SaaS アプリケーションに以下のような多くのメリットをもたらします。

  • グローバルに利用可能な IP アドレス: 受信リクエストのロケーションに応じて 1 つ以上のクラスタにルーティングするように設定できます。これにより、DR およびアプリケーション ルーティングの高度な構成が可能になります(詳しくは、マルチクラスタ Ingress と Google Cloud のグローバル ロードバランサをご覧ください)。
  • 費用の最適化: GKE は、インフラストラクチャに関する費用と使用量の調整に役立つ費用最適化インサイトを提供します。
  • スケーラビリティ: GKE では需要に合わせてアプリケーションのスケールアップやスケールダウンを簡単に行えます。現在のスケーリングの上限はクラスタあたり 15,000 ノードで、業界最多クラスです。
  • 高度なストレージ オプション: データに安全かつ確実に、高いパフォーマンスでアクセスできます。

4 つの一般的な SaaS GKE アーキテクチャ

SaaS アーキテクチャを選択する際、まず分離要件と SaaS アプリケーションの性質を検討する必要があります。Kubernetes の Namespace、ノード、クラスタのレベルでは、費用と分離の度合いが相反する関係にあります。それぞれの分離に伴って費用が増加します。次のセクションでは、各分離に基づくアーキテクチャについて、長所と短所も含めて詳しく概要を示します。以下で説明するすべての方法に加えて、GKE Sandbox を使用してホストシステムのセキュリティを強化できます。GKE のメインのセキュリティ概要ページは、ネットワーク セキュリティに関する考慮事項も記載されており、こちらからアクセスできます。

1. フラットなマルチテナント アプリケーション

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_Creating_a_SaaS_Platform_on_GKE_v1.max-1200x1200.jpg

SaaS アプリケーションをホストする方法の一つは、SaaS アプリケーションのコピーを使用して、Kubernetes Namespace への単一の Ingress ルーティングを設定することです。Ingress ルーターには、認証済みユーザーに固有のデータを提供するインテリジェンスが組み込まれています。この設定は、アプリケーションのソフトウェア レイヤを超えてユーザーを分離しなくて済む SaaS アプリケーションでは一般的です。また、この設計は通常、メイン SaaS アプリケーションのソフトウェア レイヤを介してテナンシーを制御するアプリケーションでのみ可能です。CPU、メモリ、ディスク / ストレージは、デフォルトのオートスケーラーを使用してアプリケーションの成長に合わせてスケーリングされ、特に使用量を増やすユーザーを気にする必要がありません。各 Pod に固有の永続ボリュームの要求を介してストレージを接続できます。

長所:

  • クラスタとノードは一意の単一リソースとして管理されます。

短所:

  • 複数のテナントが基盤として使用するサーバーが同じであり、あるテナント(「ノイジー ネイバー」)によって発生する CPU スパイクやネットワーキング イベントが他のテナントに影響を及ぼす可能性があります。
  • 複数のテナントで使用されるクラスタ コントロール プレーンが同じであるため、クラスタのアップグレードはすべてのテナントに同時に適用されます。
  • ユーザーデータはアプリケーション レイヤでのみ分離されるため、アプリケーションの障害により、あるユーザーのデータが別のユーザーのデータに混ざる可能性があります。

2. マルチテナント クラスタでの Namespace ベースの分離

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_Creating_a_SaaS_Platform_on_GKE_v1.max-2.max-1500x1500.jpg

このパターンでは、ホストのパスを使用して単一の Ingress ルーティングを設定し、特定顧客専用のアプリケーションのコピーが含まれる適切な Namespace にルーティングします。この設定は、顧客向けに高効率のリソース分離を必要とするお客様が一般的に使用します。各 Namespace に CPU とメモリの割り当てを設定し、スパイク時に余剰の容量を共有できます。各 Pod に固有の永続ボリュームの要求を介してストレージを接続できます。

長所:

  • テナントは分離された環境でリソースを共有して、効率を高め、セキュリティを強化できます。
  • クラスタとノードは一意の単一リソースとして管理されます。

短所:

  • 複数のテナントで基盤として使用するサーバーが同じであり、あるテナントによって発生する CPU スパイクやネットワーキング イベントが他のテナントに影響を及ぼす可能性があります。
  • 複数のテナントで使用されるクラスタ コントロール プレーンが同じであるため、クラスタのアップグレードはすべてのテナントに同時に適用されます。

3. ノードベースの分離

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_Creating_a_SaaS_Platform_on_GKE_v1.max-1300x1300.jpg

上記のように、このパターンでは、ホストのパスを使用して単一の Ingress ルーティングを設定し、特定テナント専用のアプリケーションのコピーが含まれる適切な Namespace にルーティングします。ただし、アプリケーションを実行するコンテナはラベルを使用して特定のノードに固定されます。これにより、Namespace ベースの分離のほかに、アプリケーションをノードレベルで分離することができます。このタイプのデプロイは、アプリケーションが大量のリソースを必要とする場合に使用されます。

長所:

  • テナントは分離された環境で専用のリソースを使用します。
  • クラスタとノードは一意の単一リソースとして管理されます。

短所:

  • 各テナントは独自のノードを取得し、テナントがアプリケーションを使用しているかどうかにかかわらず、インフラストラクチャ リソースを消費します。
  • 複数のテナントで使用されるクラスタ コントロール プレーンが同じであるため、クラスタのアップグレードはすべてのテナントに同時に適用されます。

4. クラスタベースの分離

https://storage.googleapis.com/gweb-cloudblog-publish/images/Cluster-based_isolation_.max-1100x1100.jpg

最後のパターンでは、一意の単一 Ingress ルーティングを使用して各クラスタにアクセスします。クラスタ内には、特定顧客専用のバージョンのアプリケーションが存在します。このタイプのデプロイは、アプリケーションが大量のリソースを必要とするだけでなく、特に厳格なセキュリティ標準を必要とする場合に使用されます。

長所:

  • テナントは、専用のクラスタ コントロール プレーンを備えている完全に分離された環境で専用のリソースを使用します。

短所:

  • 各テナントは独自のクラスタを取得し、テナントがアプリケーションを使用しているかどうかにかかわらず、インフラストラクチャ リソースを消費します。
  • クラスタは別々に更新する必要があるため、運用上の負担が大幅に増大する可能性があります。

ストレージに関する考慮事項

ベースライン アーキテクチャを選択したら、次に設定に追加する必要があるのはランタイム ストレージです。アプリケーション用のコンテナベースのストレージにはさまざまなオプションがあり、最適なオプションはアプリケーション固有の要件によって異なります。最適なオプションを決める際に考慮すべき、おそらく最も重要なことはレイテンシと永続性です。以下の表を使用し、利用可能なさまざまなオプションを選ぶ指針にしていただければ幸いです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/6_Creating_a_SaaS_Platform_on_GKE_v1.max-1600x1600.jpg

ローカル SSD(エフェメラル ストレージ):

最小容量: ディスクあたり 375 GB
アプリケーションが以下に当てはまるときにローカル SSD を使用します。

  • AI や ML、分析、バッチ処理、ローカル キャッシュ、インメモリ データベースなど、データをダウンロードして処理する場合。
  • 特殊なストレージの要件があり、高性能なローカル ストレージで raw ブロック アクセスが必要な場合。

または、特別なデータ アプリケーションを実行し、Pod のノードレベル キャッシュなどのローカル SSD を運用する必要がある場合もあるでしょう。このアプローチを使用すると、Aerospike や Redis などのインメモリ データベース アプリケーションのパフォーマンスを改善できます(詳細)。

永続ストレージ ディスク:
最小容量: 10 GB
高パフォーマンスと高可用性を備え、耐久性に優れたブロック ストレージにクラスタがアクセスする必要がある場合は、Persistent Disk ストレージを使用します。通常、Persistent Disk ボリュームは単一の Pod にアタッチされます。このストレージ オプションは、ReadWriteOnce アクセスモードに対応しています。GKE では、Persistent Disk ボリュームの構成に対応しており、レイテンシとパフォーマンスのさまざまなオプションが用意されています。これらのディスクは、高パフォーマンスの永続的なブロック ストレージを必要とする一般的なワークロードまたはデータベースに最適です。また、リージョンの冗長性を設定することもできます(詳細)。

オブジェクト ストレージ:
Cloud Storage バケットをアプリケーションに接続することもできます。FUSE CSI ドライバ(詳細)を使用して、ストレージ バケットをアプリケーションにマウントし、ローカルでリモート ファイルを操作することもできます。これは、コア アプリケーションの外部にストレージをハイドレートするパイプラインがある場合に最適なオプションです。

Filestore(NFS):
最小容量: 1 TB
Filestore で提供される一元化された NFS ストレージは、複数の Pod を接続して読み取り / 書き込みオペレーションを行うために使用できます。このオプションは、クラスタ内の複数のサービスに中央ストレージ設備への読み取り / 書き込みアクセスが必要な場合に適しています(詳細)。

自社サービス:
多くの GKE ユーザーは SaaS アプリケーションを Cloud SpannerCloud SQLRedis などのホスト型サービスに接続し、クラスタに接続しています。これは、セルフマネージド データ サービスが不要で、Google Cloud マネージド サービスを利用して運用上の負担を軽減できる場合に最適なオプションです。

事例紹介

「Google GKE 上に Weaviate Cloud Services(WCS)を構築することで、お客様のニーズに合わせて AI ネイティブのベクトル データベースを弾力的にスケーリングできます。」
- Weaviate、共同創設者 / CTO Etienne Dilocker 氏

「Google GKE を基盤として EDB BigAnimal™ を構築することで、EDB の Kubernetes に関する既存の専門知識を活用して、インテリジェントなマネージド データベース プラットフォームを実現することができました。GKE を使用すると、お客様に幅広いコンピューティングとストレージのオプションを提供しながら、オペレーターに合わせてプラットフォームには自動化を組み込むことができます。」
- EnterpriseDB、テクノロジー兼戦略担当シニアバイス プレジデント Benjamin Anderson 氏

「当社の次世代サーバーレス プロダクトはオブザーバビリティ、セキュリティ、検索といったユースケースにわたるお客様のさまざまなニーズを満たすように調整されており、管理のオーバーヘッドが発生しません」と、Elastic の Steve Kearns 氏は言います。「Google Cloud を利用するために GKE を選びました。GKE のおかげで、Google Cloud の最新のコンピューティング オプションとストレージ オプションを活用でき、費用、パフォーマンス、管理のしやすさの最適な組み合わせを実現できます。」
- Elastic、プロダクト管理担当バイス プレジデント Steve Kearns 氏

詳細

組織が GKE での SaaS アプリケーション配信を検討する際は、そうすることで得られるメリット、さまざまなアーキテクチャの長所と短所、数多くのストレージ オプションなど、考えるべきことがたくさんあります。また、GKE、GKE のセキュリティ、Google Cloud 内から SaaS アプリを配信して収益化する方法についてもよく理解しておくことをおすすめします。詳細については、以下のリソースをご確認ください。

ー GKE、シニア プロダクト マネージャー Brian Kaufman

投稿先