AWS認定資格の勉強をしていると、「サーバレス」や「疎結合」といった言葉がよく出てきます。
サーバレスサーバレスサーバレス・・・
疎結合疎結合ソケツゴウ・・・
と嫌でも覚えてしまうくらい、AWSが推奨している概念です。
今回はその「疎結合」について考えていきたいと思います。
目次
● 疎結合とは
● ユースケース
疎結合とは
疎結合には、対となる「密結合」があります。
▼疎結合
・他の処理との結びつきが弱く、個々で処理が完結する設計
・処理に変更があった場合、他の処理への影響が少ない
▼密結合
・他の処理との結びつきが強く、他の処理に強く依存してしまう設計
・処理に変更があった場合、他の処理への影響が大きい
システム開発は様々な処理モジュールが組み合わさって一つのものが築かれますが、そのモジュール同士の依存度を出来るだけ弱くする考え方が疎結合です。
密結合はその逆で、各モジュール間の依存度が強く、例えば一つの処理に負荷が集中し処理速度が低下すると、全体のパフォーマンスが低下してしまいます。
簡単にいうと、どこかで障害が発生したりボトルネックとなる箇所が一つでも存在すると全体に影響を与えてしまうのが密結合で、そうならないようにするのが疎結合ともいえます。
ユースケース
次のようなシステムがあったとします。
【日本シリーズ 2023 阪神タイガース VS オリックスバファローズ MVP投票システム】
テレビのリモコンのボタンを押下するとMVP選手が投票され、常に最新の投票状況が画面上に反映されるシステム
（拡大して表示）よくあるテレビのDボタンと連動したシステムですが、これは高視聴率が予想されるスポーツ番組で、一秒間に数千、数万件の投票データが送信されることが予測されます。
その場合どうなってしまうのか
（拡大して表示）
DBへの書き込みがボトルネックとなってしまい、処理の待ち状態が発生します。
その間にも次々と視聴者からは投票データが送信され、処理しきれずにパフォーマンスは低下をたどります。この状態で別の視聴者が投票データを送ると、その視聴者は更に長い待ち時間を要することになります。
これは「密結合」の設計といえます。
Amazon SQS
DBのボトルネックを解消するには、「投票を受け付ける処理」と「DB登録処理」を分けることが最善と言えるでしょう。
そこで登場するのが、「Amazon SQS」というサービスです。
（https://aws.amazon.com/jp/sqs/）
SQSとはSimpleQueueServiceの略で、AWSフルマネージドのキューイングサービスです。
ソフトウェアコンポーネント間で任意の量のメッセージを送信、保存、受信することができます。また、ものすごく耐久力があります。
今回のユースケースで考えると、視聴者からの投票データをSQSで次々と受け取り、それを1件ずつ順番にDB登録処理へ送信するのに最適といえます。
SQSを取り入れると、次のようなユースケースとなります。
（拡大して表示）
- 投票受付処理ではSQSにデータを送信するだけで処理を完了とし、テレビには投票完了のメッセージを表示する
- DB登録処理ではSQSからデータを定期的に受信し、順番にDB登録する
- 投票結果反映処理では5秒に1回の間隔でDBよりデータを取得し、最新の投票結果をテレビに反映する
短時間で多数送信される投票データをまずはSQSで受け止めておき、溜まっているデータを1件ずつ吸い上げる処理を挟み、順番にDBに登録していきます。最新データも常にリアルタイムで反映させなくてもよいでしょう。
視聴者は投票後にすぐに完了メッセージを受け取ることができ、最新の投票結果も5秒間隔で更新され続けていきます。
図解すると、次の緑破線に囲まれた3つの処理が個々で完結できる独立した処理となっています。
（拡大して表示）
処理間の依存性を弱くすることは大切
どこかにボトルネックがあると全体のパフォーマンスに影響してしまう、そういった密結合な構造は運用面でも保守面でも大変脆い状態であるといえます。
処理間の依存性を弱くし、それぞれを独立した処理とするマイクロサービス化、すなわち疎結合化が推奨されます。
今回はSQSを使用した疎結合の紹介でしたが、SQS以外にも「StepFunctions」や「EventBridge」など、AWSには疎結合を実現できるサービスが複数存在し、それぞれ得意・不得意があります。
それぞれのユースケースに合致した最適なサービスを選定することが大切です。
