architecture-paradigm-serverless

サーバーレスアーキテクチャのパラダイム

使用する場合

• トラフィックが変動するイベント駆動型のワークロード
• クラウドネイティブアプリの運用負荷を最小限に抑える場合

使用しない場合

• 関数のタイムアウト制限を超える長時間実行プロセス
• 永続的な接続やローカル状態を必要とするアプリケーション

このパラダイムを採用する場合

• ワークロードがイベント駆動型で、断続的、または「バースト性」のトラフィックパターンを示す場合。
• インフラストラクチャの管理を最小限に抑え、実行ごとの従量課金モデルを採用することが目標の場合。
• ユースケースで「コールドスタート」によるレイテンシの制約を許容できる場合、または効果的に緩和できる場合。

導入手順

1. 関数を特定する：ワークロードを、HTTP リクエスト、メッセージキュー、スケジュールされたタイマーなどのイベントによってトリガーされる、小規模でステートレスな関数ハンドラーに分割します。
2. 状態を外部化する：永続状態には、データベースやキューなどのマネージドサービスを使用します。繰り返し実行しても意図しない副作用が発生しないことを検証できるよう、ハンドラーを冪等に設計します。
3. コールドスタートの緩和を計画する：レイテンシに敏感な経路では、関数の依存関係を最小限に抑えます。プロビジョンドコンカレンシーや「ウォーマー」関数などの戦略を採用し、コールドスタート時間を短縮します。
4. 計装とセキュリティを実装する：すべての関数で詳細なトレースとロギングを有効にします。IAM ロールには最小権限の原則を適用し、コストを管理するために関数ごとの予算を設定します。
5. デプロイを自動化する：SAM、CDK、Terraform などの Infrastructure-as-Code（IaC）フレームワークを使用して、再現可能で信頼性の高いリリースプロセスを作成します。

主な成果物

• 関数のトリガー、ランタイムの選択、状態管理戦略、コスト予測を記述したアーキテクチャ決定記録（ADR）。
• 関数を自動的にパッケージ化してデプロイするための、完全な Infrastructure-as-Code（IaC）および CI/CD パイプライン。
• 関数の実行時間、エラー率、コールドスタートの頻度、コストなどの主要なメトリクスを監視するオブザーバビリティダッシュボード。

リスクと緩和策

• ベンダーロックイン：
  • 緩和策：可能な場合は、プロバイダー固有の API を独自のインターフェースの背後に抽象化するか、移植性の高いフレームワーク（例：Serverless Framework）を採用して、単一のクラウドベンダーへの依存を軽減します。
• デバッグの難しさ：
  • 緩和策：分散した関数をまたいで実行をトレースするのは複雑になる場合があります。デバッグを簡素化するため、特定の計装ライブラリと構造化ロギングを標準化します。
• リソース制限：
  • 緩和策：コンカレンシーやメモリのクォータなど、プロバイダーが設定する制限を積極的に監視します。これらの制約内に収まるよう、ワークロードをシャーディング可能、または水平方向にスケーラブルに設計します。

具体的なコンポーネント

このパラダイムの実装でよく使われるツールや抽象化の用語です。 依存関係ではなく、tools: のフロントマターでもありません。

• cloud-sdk：AWS SDK、Google Cloud SDK、または Azure SDK。プラットフォームとのファーストクラスの統合
• serverless-framework：Serverless Framework、SAM、または CDK。宣言的な関数デプロイ
• IaC-tools：関数を取り巻く共有インフラストラクチャ向けの Terraform、Pulumi、またはプラットフォームネイティブの IaC

完了条件

• 関数をデプロイする前に、関数のトリガー、ランタイムの選択、状態の外部化戦略、 コールドスタートの緩和策、コスト予測を記載した ADR が作成されている。
• すべての関数とそのサポートインフラストラクチャについて、完全な IaC 定義（SAM、CDK、Terraform、または同等のもの）が存在し、 ゼロから再現可能なデプロイを実行できる。
• すべての関数ハンドラーが冪等である。同じイベントで繰り返し実行しても、同じ結果になり、 副作用が重複しない（入力を再生する単体テストで検証済み）。
• 関数が本番トラフィックを受ける前に、オブザーバビリティダッシュボードで関数の実行時間、エラー率、コールドスタートの頻度、 呼び出しあたりのコストを確認できる。