Serverless優先アーキテクチャ

serverless-firstは、15分を超える長時間実行プロセス、永続的なWebSocket接続を必要とするワークロード、予約容量が安価な一貫した高スループットトラフィックを持つアプリケーション、および低レベルのOSまたはネットワーク構成を必要とするシステムには不向きです。MicrocosmWorksは、アーキテクチャ設計中にこれらの制約に対して各ワークロードを評価し、serverlessがAPIエンドポイントとイベント処理を扱い、コンテナまたはVMが永続的なコンピューティングを必要とするワークロードを実行するハイブリッドアプローチを推奨しています。この実用的なアプローチにより、適合しないすべてのコンポーネントをserverlessに無理やり押し込むという一般的な間違いを避けることができます。

MicrocosmWorks は、重要なエンドポイントに対して provisioned concurrency を使用し、初期化時間を短縮するために関数バンドルの最適化を行い、Java ワークロード向けに Lambda SnapStart を戦略的に活用することで、Lambda cold starts を秒単位からミリ秒単位に短縮しています。また、レイテンシーに敏感なパスでは、Node.js や Python のような軽量ランタイムを最小限の依存関係で使用するようにアプリケーションを設計しており、provisioned concurrency がなくても cold starts を 200ms 未満に抑えています。このレイテンシーでも許容できないエンドポイントについては、Lambda@Edge または CloudFront Functions を使用して 10ms 未満の応答を実現しています。

MicrocosmWorks は、SST (Serverless Stack)、LocalStack、あるいは Serverless Framework のオフラインモードのようなツールを使用して、開発者のマシン上でクラウドサービスをほぼ本番環境に近い忠実度でエミュレートするローカル開発環境を構築します。私たちは、プルリクエストごとに起動される一時的なクラウド環境に対して実行される統合テストスイートを実装しており、開発者はステージング環境を共有することなく、実際の AWS サービスに対して検証できます。この二重のアプローチは、開発のための高速なローカルイテレーションループを提供するとともに、コードが本番環境に到達する前にクラウド固有の問題を捕捉します。

MicrocosmWorksは、serverlessが、可変的または急増するトラフィックパターンを持つアプリケーションにとって劇的に安価であることを発見しました。多くの場合、同等の常時稼働のcontainer deploymentsと比較して70-90%のコスト削減が可能です。しかし、月あたり1000万〜2000万以上の持続的なinvocationsのスループットでは、そのコストメリットは縮小します。当社はarchitecture design中に、お客様固有のトラフィックパターンに合わせて、serverlessのper-invocation料金と予約されたcontainer capacityを比較するコスト予測モデルを構築します。これには、API Gatewayの料金やデータ転送費用といった隠れたコストも含まれます。当社の最適化サービスは、1時間あたり$10〜$35のコンサルティング料金でご利用いただけ、定期的にserverlessの請求書をレビューし、過剰にプロビジョニングされたメモリ、過度な関数実行時間、または不要なAPI Gatewayの使用による無駄を特定します。

MicrocosmWorks は、Lambda 関数とデータベースの間に永続的な層としてデプロイされる Amazon RDS Proxy や PgBouncer のようなコネクションプーリングプロキシを使用します。これにより、数千の Lambda 接続が実際のデータベース接続の管理可能なプールに多重化されます。また、コネクションプーリングを使用してもボトルネックが生じるような高並行性ワークロードでは、DynamoDB やその他のコネクションレスなデータベースを優先するようにサーバーレスアプリケーションを設計しています。リレーショナルデータベースを使用しなければならないアプリケーションの場合、データベースの接続容量に合わせて並行する Lambda 呼び出しを制限する、接続認識型スケーリング制限を実装しています。