SAA学習-サーバレス-疎結合化の追求

今回のテーマ：疎結合化の追求

概要

5つの設計と11のベストプラクティスの対比よりサーバレスの観点は以下のオレンジ色の箇所となります。

コンポーネントの疎結合

コンポーネント間の相互依存を減らした構成を取ることにより、1つのコンポーネント変更や障害の影響を削減します。
プログラムの考え方だと構造を分ける認識になります。
なお、関連するAWSサービスは以下のようなものがあります。

• Lambda
• SQS
• ELB
• SNS

密結合の問題

密結合した構成は障害や修正に弱く不具合が発生しやすい傾向になります。
以下は密結合の概略図となります。

また、密結合のデメリットは以下ようなものがあります。

• 1インスタンスの障害の影響が全体に影響しやすい
• 1つの修正対応で他インスタンスへの影響を多く考慮しなければならない
• 負荷対応やスケーリングも容易にできない
• システム構成の追加/変更が難しい

疎結合化のメリット

ELBやAPIなどを利用し、結合点を削減したりメッセージ結合にすることで影響を減らすことが可能となります。 以下は疎結合化した場合の概略図となります。

また、疎結合化のメリットとしては以下のようなものがあります。

• 耐障害性が高まる
• 負荷対応やスケーリングが容易
• システム構成の追加/変更が容易

疎結合化のサービス概要

サーバレス化をするサービスやメッセージング処理をするサービスを利用し疎結合化を行います。
以下はAWSサービスとその概要になります。

AWSサービス	概要
ELB	サーバー間のトラフィック調整と連携をELBを起点することで疎結合化を実現する
SQS	SQSのキューイングによる通信でインスタンス間連携を結ぶことで疎結合化を実現
SNS	SNSのアプリケーション間通信でインスタンス間連携を結ぶことで疎結合化を実現
Lambda	サーバーインスタンスではなくLambdaによるトリガー処理を連携することで疎結合化を実現

通信系サービスによる疎結合

サーバー間の連携を直接結んで連携すると密結合となってしまいます。
概略図としては以下のようになります。

そのため、サーバー間の連携をメッセージング処理を結ぶことで疎結合化を実現します。
概略図としては以下のようになります。

疎結合化設計

疎結合化設計にはサーバーレス/キューイング通信/マネージド型サービスの利用を組み合わせて設計を行います。
以下は密結合タイプの設計パターンと疎結合化向けの設計パターンになります。

密結合タイプの設計パターン

• ユーザー認証/管理をバックエンドサーバーで処理
• 通常のEC2インスタンスでアプリケーションを構成
• アプリケーション間で直接通信
• 静的WEBシステムをEC2インスタンスEBSに保存

疎結合化向けの設計パターン

• ユーザー認証/管理をIAMなどのマネージド型サービスを利用
• なるべくLambdaなどサーバレスでアプリケーションを構成
• アプリケーション間はSQSなどMQ(message Queueing)通信で連携
• 静的WEBシステムをVPC外部のS3に保存

今回のテーマは以上です。