本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。
第5回の今回は、Google Cloudのサーバーレス製品を活用したアーキテクチャに焦点を当て、アプリケーション開発における実装パターンを実践的ないくつかのユースケースにあわせて紹介をします。また、サービスの選定にまよったときの判断のポイントも紹介します。
基本のアーキテクチャパターン
まず最初に、クラウドアーキテクチャセンターを紹介します。Google Cloudでワークロードをビルドまたは移行するためのリファレンスアーキテクチャ、ガイダンス、ベストプラクティスがまとまっているページです。クラウドのアーキテクチャを検討する際に、こまったらここを参考にするとヒントが詰まっています。
Webアプリケーションを構築する（サーバーレス）
今回はもっとも一般的なユースケースの一つである、Webアプリケーションをサーバーレスで構築するパターンを紹介します。
- アプリケーションはコンテナで構築し、Cloud Runでホストします。
Cloud Runは、このコンテナイメージを受け取り、スケーラブルなサーバーレス環境で実行します。つまり、開発者はサーバの管理やスケーリングについて心配することなく、アプリケーションに集中できます。 - Cloud RunとCloud Load Balancingを連携します。
Cloud Load Balancingは、インターネットトラフィックを自動的に分散させるマネージドサービスです。Cloud Runと組み合わせることで、アプリケーションへのアクセスを効率的に処理し、グローバルなCDN（コンテンツ配信ネットワーク） を利用してコンテンツを高速に配信したり、WAF （ウェブアプリケーションファイアウォール） を通じてセキュリティ保護を強化したりすることができます。 - データベースはSpannerを使って構築します。
Spannerは、グローバルに分散されたデータベースであり、水平スケーリングや強力な一貫性を提供します。VPC（Virtual Private Cloud） やその他のネットワークの設定を意識することなく、安全にデータベースリソースにアクセスできるため、開発者はアプリケーションロジックの構築に集中できます。 - ログは標準出力がそのままCloud Loggingに流されるため、特別な設定は必要ありません。
アプリケーションからの標準出力
Cloud Run、Spannerともに過去の記事に詳細な解説があるので、興味があればこちらもご覧ください。
Webアプリケーションを構築する（RDBMS）
使い慣れたデータベースを利用したい場合は、Cloud SQLやAlloyDBなどのフルマネージドRDBMSサービスを利用できます。Cloud SQLやAlloyDBは、Google Cloudが提供するフルマネージド型のリレーショナルデータベース管理システムです。これらのサービスを使用することで、MySQLやPostgreSQLを使いつつ、データベースのセットアップ、保守、管理、スケーリングなどの運用負担をGoogle Cloudに委ねることができます。これにより、開発者はアプリケーションの開発に集中できるようになります。
Virtual Private Cloud
2024年3月のタイミングでは、一般的にServerless VPC Access Connectorというコンポーネントを作り、Cloud Runはそこを経由してVPCにアクセスする経路になります。Serverless VPC Access Connectorは、サーバーレス環境からVPCリソースに接続するためのブリッジ機能を提供します。このコネクタを設定することで、Cloud RunのインスタンスがVPC内にあるリソース、例えばCloud SQLデータベースに安全にアクセスできるようになります。このアクセス方法により、開発者はサーバーレスアプリケーションとプライベートネットワーク内のリソースをシームレスに統合できます。
現状プレビューですが、さらにこれを簡単にする方法としてDirect VPC egressがあります。この機能を利用することで、Serverless VPC Access Connectorを設置せずに直接VPC内のリソースへのアウトバウンド接続が可能になります。これにより、設定が簡素化され、パフォーマンスが向上する可能性があります。
サービス選定にまよったときの判断ポイント
ここまでWebアプリケーションの構築のパターンを簡単に紹介しましたが、たとえばデータベースの選定など、同じような性質のサービスを選ぶ際にどちらにするか、まようケースがあると思います。一般的には機能をベースに判断することが多い印象です。たとえばCloud SQLとFirestoreを比較した場合に思いつくのはデータの特性です。
- Cloud SQL: 構造化されたデータ
（RDBMS） - Firestore: 非構造化データ
（NoSQL）
もちろん、大切な観点でこれをベースに判断することは重要です。ただ忘れてはいけない観点として料金モデルも意識すると、より良い選択ができるようになります。たとえば、いまあげた2つのサービスの料金モデルを例にとると次のような違いがあります。
- Cloud SQL: 稼働している時間で課金
- Firestore: 読み書き操作の回数で課金
オペレーション
つまりCloud SQLは、トランザクションの整合性が重要で、関係データモデルに基づく複雑なクエリが多用されるアプリケーションに最適です。また、安定した稼働が予測される場合にコストパフォーマンスが良いでしょう。
一方Firestoreは
アプリケーションの要件、データの特性、予想されるトラフィックパターン、などに加えて現在のビジネスのステージ、そして料金モデルを総合的に考慮してサービス選定をすると素敵なクラウドライフが送れるはずです。
より実践的なアーキテクチャパターン
ここからは、より実践的なアーキテクチャパターンをみていきます。
IP固定する
企業がアプリケーションを開発し、外部のサービスやAPIに安全に接続する必要がある場合、接続元のIPアドレスを固定することが求められることがあります。Cloud Runからこれを実現する場合は、次のような設定を行います。
- Serverless VPC Access Connectorの使用: Cloud RunサービスをVirtual Private Cloud
（VPC） に接続するために、Serverless VPC Access Connectorを使用します。これにより、Cloud Runが実行されるコンテナからVPC内のリソースやサービスにアクセスできるようになります。 - Cloud NATを介した接続: VPC内にアクセスできるようになったら、次にCloud NAT
（Network Address Translation） を使用して、外部のサービスに対するすべての出口トラフィックのIPアドレスを固定します。Cloud NATを設定することで、VPCから外部に出るトラフィックがCloud NATを通過する際に、指定したIPアドレス （Cloud NATが持つIPアドレス） から出ていくようになります。
この設定により、Cloud Runから外部サービスに接続する際のIPアドレスをCloud NATが持つ固定のIPアドレスに統一することが可能になります。
DDoS対策やネットワークフィルタリング
反対に特定のIPからのアクセスのみを許可したいというユースケースもあると思います。Cloud RunとCloud Load Balancingを組み合わせて使用することで、Cloud Armorを活用し、このようなセキュアなアクセス制御を実現することが可能です。
- Cloud Armorの役割と機能
-
- IPベースのアクセス制御: Cloud Armorを使用すると、特定のIPアドレスからのアクセスのみを許可する、または特定のIPアドレスからのアクセスを拒否するといった、IPベースのアクセス制御ポリシーを設定できます。これにより、信頼できるソースからのアクセスのみを許可し、不正アクセスを防げます。
- ネットワークフィルタリング: ユーザーが設定したポリシーに基づいて、不要または悪意のあるトラフィックをフィルタリングし、アプリケーションへのアクセスを制御します。
- DDoS攻撃対策: Cloud Armorは、分散型サービス拒否
（DDoS） 攻撃などのネットワークベースの攻撃から保護するための機能を提供します。これにより、アプリケーションへの不正なトラフィックを防ぎ、サービスの可用性を維持できます。
Cloud Armorを利用することで、Cloud Runアプリケーションへのセキュアなアクセス制御を実現し、不正アクセスや攻撃からアプリケーションを保護できます。これにより、アプリケーションの安全性と信頼性を高めることができます。
CDNを使って静的コンテンツをキャッシュ
Cloud Runで動的なアプリケーションをホストしながら、同時に静的なコンテンツ
- Cloud CDNの役割と機能
-
- キャッシュ機能: Cloud CDNは世界中のエッジロケーションに静的コンテンツをキャッシュすることにより、エンドユーザーに近い場所からコンテンツを迅速に配信します。これにより、コンテンツの読み込み時間が大幅に短縮され、エンドユーザーの体験が向上します。
- レスポンスタイムの短縮: エッジロケーションからコンテンツを配信することで、サーバーとエンドユーザー間の物理的距離が短くなり、レスポンスタイムが短縮されます。
- 負荷の軽減: 静的コンテンツの配信をCDNが担うことで、オリジンサーバーの負荷が軽減されます。これにより、オリジンサーバーは動的コンテンツの生成やビジネスロジックの処理にリソースを集中できるようになります。
Cloud RunとCloud Load Balancingを使用してCloud CDNに接続することで、静的コンテンツと動的コンテンツの両方を高速かつ効率的に配信することができ、エンドユーザーに優れたウェブ体験を提供することが可能になります。
アプリケーションに認証をかける
Identity Aware Proxy
- IAPの役割と機能
-
- 認証と認可: IAPはユーザーの認証と認可を行い、許可されたユーザーのみがリソースにアクセスできるようにします。これにより、不正アクセスやデータの漏洩リスクを減らすことができます。
- Googleアカウントとグループの利用: 特定のGoogleアカウントやGoogleグループにアクセス許可を与えることができます。これにより、組織内のユーザー管理が容易になり、チームやプロジェクトごとにアクセス権を簡単に設定できます。
- Identity Platformとの連携: Identity Platformを使用すると、Googleアカウント以外のユーザー認証情報も利用して認証・
認可を実施できます。これにより、アプリケーションがより広範なユーザーベースに対応できるようになります。
Identity PlatformとIdentity Aware Proxyを組み合わせた具体的な認証の実装方法は、Google Cloud Japan カスタマーエンジニアのSuwaがまとめていますので、こちらもご覧ください。
IAPを使用することで、アプリケーションへのアクセスを厳密に制御しながら、ユーザーやグループに応じた柔軟なアクセス管理を実現することが可能です。これは、セキュリティを確保しつつ、必要なユーザーにのみサービスを提供したい場合に非常に有効な手段となります。
内部通信のみを許可する
Internal HTTP Load Balancingを使用することで、Google Cloud内で動作するアプリケーション間の安全な通信を実現できます。このサービスは、Google Cloudの内部ネットワーク内でのみアクセス可能な特別なタイプのロードバランサーであり、インターネットからは直接アクセスできません。これにより、社内向けアプリケーションや機密情報を扱うシステムのセキュリティを大幅に向上させることが可能です。
- Internal HTTP Load Balancingの役割と機能
-
- 高いセキュリティ: 外部インターネットからのアクセスが完全に遮断されているため、外部の脅威からシステムを守ることができます。
- 内部通信の最適化: Google Cloud内のサービス間での通信がスムーズに行われ、低遅延でのデータ交換が可能になります。
- プライベートな通信環境: オンプレミス環境や他のクラウドサービスとのプライベートな接続が必要な場合にも、安全に内部通信を行うことができます。
Internal HTTP Load Balancingを利用することで、Google Cloud内で運用するアプリケーションやデータベース間の通信を安全かつ効率的に行うことができます。これにより、企業は機密性の高いデータを扱うアプリケーションのセキュリティを強化しつつ、内部の通信効率も向上させることができます。
まとめ
本稿では、Google Cloudのサーバーレス製品を活用したアーキテクチャについて、いくつかのユースケースと実装パターンを紹介しました。
サーバーレスアーキテクチャは、開発者がインフラストラクチャの管理に時間を費やすことなく、アプリケーション開発に集中できるというメリットがあります。また、スケーラビリティやコスト効率にも優れています。具体的なアーキテクチャパターンは、アプリケーションの要件によって異なります。ぜひ、アプリケーションのユースケースを理解した上でいろいろなサービスを利用してみてください。
今回は基本のアーキテクチャパターンとその実践編を紹介しましたが、それ以外のCloud Runを使ったアーキテクチャパターンのまとめについては次の記事もご覧ください。
すこしでもみなさまのサーバーレス開発のお役に立てれば幸いです。次回はサービスメッシュとAnthos Service Meshについて紹介します。