AWS のアプリケーションアーキテクチャパターン

AWS へのアプリケーションデプロイ

Dunieski Otano

Amazon Web Services Solutions Architect

講師紹介

適切なアーキテクチャが重要な理由

• アーキテクチャはトレードオフの集合であり、唯一の正解はありません
  • 設計の選択を左右する3つの問い:
    • コンポーネント間の結合度はどの程度か
    • 状態はどこで管理するか
    • 通信は同期か非同期か
  • 流行ではなく、ワークロードに合ったパターンを選ぶ

金曜夜の連鎖障害

• 決済 API の遅延がチェックアウト全体をブロックした
• すべてのサービスがその API を同期的に待機していた
• 解決策はより速い API ではなく、アーキテクチャの見直し

アーキテクチャの選択がデプロイを左右する理由

• 選択したパターンがアプリのスケーリングと障害挙動を決定します
  • 密結合の設計は高負荷時に破綻します
• 適切なパターンがデプロイを予測可能にします
  • 同じコードでも、本番環境での挙動は大きく異なります

主要なアーキテクチャパターン

• モノリシック：単一のデプロイ単位。導入がシンプル
• マイクロサービス：独立したサービスを個別にデプロイ
• イベント駆動：直接呼び出しではなく、イベントに反応するコンポーネント
  • ファンアウトはイベント駆動のサブパターンで、1つのイベントを複数のコンシューマーに配信

 

ステートフルとステートレス

• ステートレス：リクエスト間でクライアントデータを保持しない
  • どのインスタンスでも任意のリクエストを処理できる
• ステートフル：インスタンスが過去のやり取りを記憶する
• ステートレス設計が水平スケーリングを可能にします
  • 共有状態はDynamoDBまたはElastiCacheに移行する

密結合と疎結合

• 密結合：呼び出し元は呼び出し先のレスポンスを待機します
• 1つのサービスが遅いと、連鎖全体が停止します
• 疎結合：サービス間にAmazon SQSキューを配置します
• コンシューマーが停止中でも、プロデューサーは処理を継続できます

同期と非同期

• 同期：呼び出し元は結果が返るまでブロックします
• 呼び出し元が即座に結果を必要とする場合に使用します
• 非同期：呼び出し元は処理を渡してすぐに戻ります
• 低速、バースト的、または緊急性の低い処理に使用します

 

サードパーティ呼び出しの耐障害性パターン

• 指数バックオフによるリトライ：再試行間隔を徐々に延ばします
• サーキットブレーカー：障害中のサービスへの呼び出しを一時停止します
• デッドレターキュー：繰り返し失敗するメッセージを隔離します
• これらを組み合わせて使用します。無制限のリトライは障害を悪化させます

練習しましょう！

AWS へのアプリケーションデプロイ