サービスの連携と状態管理

AWS でのアプリケーション開発

Ricardo Sueiras

Principal Technologist

サービスの連携

 

• 複数のサービスが連携してワークフローを完了します。
• 連携戦略が必要です。
• アプローチは2つ：オーケストレーションとコレオグラフィ。

オーケストレーション

 

• 中央のオーケストレーターがワークフローを制御します。
• 実行順序を管理し、次に呼び出すサービスを決定します。
• リトライ、条件分岐、エラー処理に有効です。
• AWS では Step Functions を使い、Lambda・ECS・DynamoDB を連携します。

オーケストレーション

 

• ワークフローのロジックが一箇所に集約されるため、デバッグや監視が容易です。
• トレードオフ：中央依存が生じます。

コレオグラフィ

• 中央のコントローラーはありません。
• 各サービスが独立してイベントに反応します。
• 関連するイベントを受信し、それぞれ処理を実行します。
• ワークフロー全体を把握する必要はありません。
• 疎結合とスケーラビリティが向上します。

 

コレオグラフィ

• AWS では EventBridge、SNS、SQS を使用します。
• 高いスケーラビリティを実現します。
• トレードオフ：ワークフローが複雑になるほど把握やデバッグが難しくなります。

 

イベント駆動アーキテクチャ

• サービスはイベントの発行と消費によって通信します。
• サービス間の疎結合を促進します。
• 高いスケーラビリティを実現します。
• イベントの並列処理が可能になります。
• 既存のサービスを変更せずに新しいサービスを追加できます。

 

イベント駆動アーキテクチャ

 

• EDA 導入時のトレードオフ：
• 結果整合性を前提に設計します。
• べき等性を実装します。
• 障害処理がより複雑になります。

べき等性

 

• 同じ操作を何度実行しても、結果は同一です。
• 非同期およびイベント駆動システムにおける重要な設計原則です。
• 分散システムではリトライ・ネットワーク障害・再処理により重複イベントが発生します。
• システムの正確性と信頼性を維持します。

デッドレターキュー

 

• 非同期通信における障害を管理します。
• 問題のある「ポイズン」メッセージを隔離します。
• リトライを繰り返しても失敗したメッセージは DLQ に移動します。
• メインの処理フローは継続して動作します。

デッドレターキュー

• メッセージの順序が重要でない場合に使用します。
• 多少のデータ損失が許容される非重要システムでは省略できます。
• メッセージ順序を保持する必要がある場合は使用しません。

 

状態管理

• 状態管理はクラウドネイティブアプリの基本です。
• 状態とは、インタラクション間で保持されるデータです。
• サーバーにローカルで状態を保存すると、スケーラビリティと耐障害性が制限されます。

 

状態管理

• 状態管理は構築するシステムに応じてトレードオフが生じます。
• 外部状態によりスケーラビリティと耐障害性が向上します。
• コスト：レイテンシと複雑性が増加します。
• 考慮点：一貫性、キャッシュ、データアクセスパターン。

 

ステートフル

 

• セッションデータはサーバーに保持されます。
• リクエストは同じインスタンスにルーティングする必要があります（スティッキーセッション）。
• スケーリングの柔軟性が制限されます。
• インスタンスが障害を起こすと、セッションは失われます。

ステートレス

 

• すべてのリクエストが独立して処理されます。
• サーバーに状態は保存されません。
• 状態は外部システムで管理されます。
• クラウドネイティブアプリで推奨されるアプローチです。
• どのインスタンスでもリクエストを処理できるため、水平スケーリングが容易です。

練習しましょう！

AWS でのアプリケーション開発