サーバーレスは、スケーラビリティについてあなたに嘘をついている
サーバーレスコンピューティングは、無限のスケーラビリティとオーバーヘッド・ゼロを約束します。AWS LambdaやGoogle Cloud Runのようなプラットフォームは、コンピューティング層を瞬時にスケールさせます。
しかし、バックエンドは依然としてクラッシュします。
問題はコンピューティングではありません。問題はデータベースにあります。
関数がスケールアップすると、「コネクション・ストーム」が発生します。新しい関数インスタンスが立ち上がるたびに、データベースへの新しい接続を試みます。もし1,000個の関数があれば、1,000件の接続リクエストが同時にPostgresやMySQLのインスタンスに押し寄せます。
リレーショナルデータベースには厳格な制限があります。その制限に達すると、新しい接続は失敗します。これが高レイテンシや5xxエラーの原因となります。コンピューティング層は準備ができているのに、データベースが悲鳴を上げている状態です。
これを解決するには、3つの戦略があります：
コネクションプロキシを使用する 関数をデータベースに直接接続しないでください。AWS RDS ProxyやGoogle Cloud SQL Proxyのようなプロキシを使用しましょう。このレイヤーは関数とデータベースの間に位置します。少数の永続的な接続プールを管理し、それを多数の関数間で共有します。
データプロキシレイヤーを実装する 高度なプロキシは、単なる接続管理以上の役割を果たします。例えば、以下のようなことが可能です：
- 読み取りと書き込みを異なるデータベースインスタンスに分散させる。
- 頻繁なクエリをキャッシュしてデータベースの負荷を軽減する。
- データベースに到達する前にクエリを最適化する。
- 非同期書き込みに移行する すべてのユーザーアクションを同期的なデータベース書き込みにするのはやめましょう。多くのタスクは、即時の整合性を必要としません。
これではなく： ユーザーのアクション -> 関数 -> 同期的なDB書き込み -> レスポンス
こちらを試してください： ユーザーのアクション -> 関数 -> キューにイベントをプッシュ -> 高速なレスポンス
別の関数がそのイベントを受け取り、後でデータベースに書き込むことができます。これにより、急激なトラフィックのスパイクからデータベースを保護できます。
真のスケーラビリティには、単なるコンピューティングのスケーリング以上のものが必要です。弾力的なデータアクセスを考慮して設計しなければなりません。理論上の最大値に合わせてプロビジョニングするのはやめましょう。バーストする関数とデータの間にバッファを構築し始めてください。
出典: https://dev.to/prabashanadev/your-serverless-is-lying-to-you-about-scale-4cga