はじめに
クラウド技術が発展し、Web サービスはクラウド技術を多く活用しています。
従来のオンプレミス環境では、物理的な Web サーバーで処理を受け付け、物理的なデータベースサーバーでデータを保管していました。
現在では、クラウド技術により、ユーザーからのリクエストに応じたスケール可能な処理を実現しています。
フロントエンド
特にフロントエンドの進歩は著しく、多様なサービスが次々と誕生しています。
Google Cloud は、Instance、Container、Function でスケーリングサービスを用意しています。
- Google Compute Engine
- Managed Instance Group で同一のインスタンスを負荷に応じて自動スケールする。
- Cloud Run
- 負荷に応じてコンテナを多数起動する。
- Cloud Functions
- 負荷に応じてプログラムを起動する。
これにより、リクエストに応じて多数のワークロードが並列に瞬時に立ち上がります。
このようなフロントエンドの進化に対して、データベースの領域はどうでしょうか。
データベース
フロントエンド領域に対して、データベースの進歩は限定的です。
もちろん、負荷に耐えられるような新しいアーキテクチャ ( Firestore 等) も産まれています。
しかし、従来からあるような SQL サーバーは、PaaS ( Platform as a Service ) としてバックアップなどの管理をクラウドに任せられるようにはなっているものの、コネクションプーリングなどの機能は SQL サーバー依存のままです。
背景には、SQL という技術が十分に成熟し実績があるため、それを引き続き利用したいというニーズが有るためです。
問題提起
これらの構成において、クラウドネイティブな技術を考える際にいくつか問題が発生します。
セッション管理
データベースサーバーは受け付けられるセッション数の上限が決まっています。
従来のような管理された台数による接続では、セッション管理が問題になることは稀です。
しかし、負荷に応じたスケール環境では問題になります。
リリース時などのバースト的な負荷に対して新しいワークロードが起動し接続が作られるため、データベースのセッション上限を超えてしまうことが考えられます。
その場合の影響は大きく、再接続のループからスローダウンやサービス停止につながります。
接続元の制限
特に Serverless 環境では、ワークロードのホストをクラウド側で管理しています。
そのため、サーバーのIP アドレスを固定できないことが一般的です。
そのため、従来行われていたような IP アドレスによるフィルタリングが難しく、インターネット全体、もしくはクラウドの管理する広範なネットワークに公開せざるを得ないという問題が発生します。
IaaS (Infrastructure as a Service) などでは、VPC といった範囲で管理ができていましたが、Serverless では難しくなった箇所です。
認証情報の管理
データベースの接続は、ID / Password による接続管理が一般的です。
クラウド上ではSecret Manager などサービスで管理することが可能ですが、プログラム内で接続情報を扱うことから、プログラムのバグや攻撃によって接続情報が漏洩してしまう懸念が発生します。
Google Cloud の解決策
上記の課題に対して、Google Cloud は複数の解決策を提供しています。
それぞれの解決策についてみていきます。
Cloud SQL Auth Proxy
Cloud SQL Auth Proxy は、安全な接続を担保する Proxy モジュールです。
フロントエンドのサーバーにモジュールを導入することで、Cloud SQL との安全な接続と認証をサポートしてくれます。
TLS 1.3 によるトンネリング、IAM 連携認証が可能です。
データベース利用者から見ると、以下のメリットを享受できます。
- 承認済みネットワーク不要
- Cloud SQL を設定する際、接続元を定義する『承認済みネットワーク』は不要です。
- Cloud Run などの IP 不定の環境からも安全に接続できます。
- Auth Proxy が安全なトンネル接続を行います。
- データベースパスワード不要
- Cloud SQL に接続するパスワードも管理不要です。
- ワークロードにアタッチされた Cloud IAM を用いて、安全な認証が可能です。
マネージド接続プーリング
マネージド接続プーリング は MySQL と PostgreSQL で利用できる接続プールです。
マネージド接続プーリングが、データベースとのプールを管理してくれることで、バースト接続に耐性をもたせることが可能です。
マネージド接続プーリングは、直接接続のほかに Cloud SQL Auth Proxy からの接続を受け付けることができ、IAM 認証も可能です。
データベース利用者から見ると、以下のメリットを享受できます。
- フルマネージドのプーリングサービス
- 自身で Instance や Pooling プログラムを管理せずに Pooling を利用できます。
- 接続が再利用されることから、新しい接続を確立するオーバーヘッドが削減されるためパフォーマンスが向上します。
- 安全な接続
- IAM 認証を用いて、接続を保護できます。
- バースト耐性
- アクセス急増でフロントエンドがバーストしても、接続に耐性をもたせることが可能です。
アーキテクチャ例
上述の構成によるアーキテクチャは以下のとおりです。
Cloud Run のサイドカーコンテナとして Cloud SQL Auth Proxy を動作させ、Cloud SQL データベースに接続します。
Cloud SQL 内では Managed Connection Pooling を利用して接続をプールします。
これにより、問題提起であげたセッション管理の問題や、接続元制限、認証情報の管理をフルマネージドサービスだけで解決することができました。
まとめ
データベース接続は、古くから問題が挙げられる技術的な課題です。
Google Cloud では、これらの課題をマネージドサービスを利用して解決することが可能です。
問題提起であげたようなことは、リリースなどのバースト的な負荷の発生時やデータベースからの情報漏洩時に初めて課題が認識されるような遅延型の地雷です。
Cloud SQL Auth Proxy やマネージド接続プーリングを活用して、安全に SQL を利用してください。
簡単30秒