アーキテクチャスタイルと通信パターン

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

Ricardo Sueiras

Principal Technologist

インストラクター紹介

アーキテクチャパターンとは？

 

 

 

• よくある問題に対する再利用可能な解決策です。
• パターンを知ることで、AWS サービスの組み合わせ方がわかります。
• アーキテクチャは、負荷時のアプリの動作に影響します。
• いくつかの主要なアーキテクチャパターンを学びましょう。

モノリス

 

 

 

 

• 密結合した単一のユニットです。
• コードベースもデプロイも1つです。
• 開発初期はシンプルです。
• スケーリングが困難：すべてを一括でスケールします。

マイクロサービス

 

 

• 小規模で独立したサービス：各サービスが1つのビジネス機能を担います。
• 各サービスを独立してデプロイ、スケール、更新できます。
• トレードオフ：運用の複雑さとサービス間通信の管理が増えます。

サーバーレス

• インフラ管理不要で、コードと設定だけに集中できます。
• マネージド AWS サービスを組み合わせて構築します。
• プロビジョニング、スケーリング、メンテナンスは AWS が担います。
• トレードオフ：実行時間の制限、コールドスタート、ベンダーロックインがあります。
• 運用オーバーヘッドはほぼゼロで、自動スケーリングに対応します。

 

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

• コンポーネントは直接呼び出しではなく、イベントの発行と購読で通信します。
• イベントは発生した出来事を記録します（注文確定、支払い受領、商品発送など）。
• プロデューサーがイベントを発行します。
• コンシューマーは関心のあるイベントを購読します。

 

密結合と疎結合のシステム

• 現代のクラウドアプリは複数のサービスで構成されます。
• サービスは処理を完了するために通信・連携する必要があります。
• 同期通信は密結合です。
• 非同期通信は疎結合です。

同期通信

 

• サービスがリクエストを送り、レスポンスを待ちます。
• レスポンスかタイムアウトまで呼び出し元はブロックされます。
• 実装と理解が容易です。
• 密結合：下流の遅延や障害が連鎖する可能性があります。
• タイムアウト、リトライ、サーキットブレーカーで対処します。

パターン：リクエスト/レスポンス

• ほとんどのアプリケーションインターフェースの基盤です。
• 動作が予測しやすいです。
• ユーザーに即座にフィードバックを返します。

非同期通信

 

• 送信側はレスポンスを待ちません。
• メッセージまたはイベントを送信後、処理を続けます。
• 受信側は独立してメッセージを処理します。
• 疎結合：スケーラビリティと耐障害性が向上します。
• トラフィックの急増や部分的な障害にも対応できます。
• 課題：重複メッセージ、順序制御、結果整合性があります。

パターン：キューによる疎結合

• プロデューサーがキューにメッセージを送信します。
• コンシューマーはメッセージを取り出し、独立して処理します。
• 障害の連鎖を防ぎます。
• プロデューサーとコンシューマーは独立してスケールできます。

 

パターン：ワーカーキュー

• 複数のワーカーが1つのキューからメッセージを取り出します。
• メッセージは並列処理されます。
• 水平スケーリングとスループット向上を実現します。
• メッセージの順序は保証されません。

パターン：パブリッシュ/サブスクライブ

• パブリッシャーが SNS トピックにメッセージを送信します。
• 複数のサブスクライバーが同じメッセージを受信します。
• 多数のコンシューマーへリアルタイムで配信します。

 

パターン：ファンアウト

• 1つのメッセージが複数のコンシューマーに同時に配信されます。
• イベント駆動アーキテクチャで広く使われます。
• 同じイベントに複数のサービスが反応する場合に有効です。

メッセージの順序制御

• ワークロードによっては、正しい順序でメッセージを処理する必要があります。
• Amazon SQS FIFO と Kinesis は順序付き処理をサポートします。
• 厳密な順序制御はスループットを低下させます。
• 正確性とスケーラビリティのバランスを取りましょう。

練習しましょう！

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