LinuCレベル4 システムアーキテクト システムアーキテクチャ 問15
システムアーキテクチャ／柔軟性を高めるアーキテクチャパターン社内の備品予約システムを新たに作る。開発と運用は5人の1チームが担い、利用者は数百人で、負荷は時間帯によらずほぼ一定である。機能の間では同じデータを参照・更新する処理が多く、リリースは月に1回程度の見込みである。アーキテクチャの判断として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「システムアーキテクチャ」に対応。実際の試験問題ではありません）
- A機能ごとのモジュールの境界を明確にした単一のアプリケーションとして作り、独立したデプロイや拡張が必要になった部分から切り出す
- B将来の拡張に備えて最初から機能ごとに十数個のサービスへ分け、サービスごとにデータベースも分けてSagaで整合性を保つ
- C機能ごとにサービスを分けてサービスメッシュを導入し、サービス間の通信の暗号化や再試行をサイドカープロキシに任せる
- D機能ごとにサービスを分けるが、全サービスが1つのデータベースを共有し、各サービスのリリースも同じ日にそろえて行う
正解：A
解説
マイクロサービスの利点は、サービスごとに独立してデプロイ・スケーリング・技術選択ができることですが、その代わりに分散による障害点の増加、サービス間の整合性の確保、運用基盤の整備といったコストを負います。小さな1チームで、負荷が一様、リリース頻度も低く、機能間で同じデータを扱う処理が多い条件では、利点がほとんど生きずにコストだけが増えます。このような場合は、内部のモジュール境界を明確にした単一のアプリケーションとして作り、独立させる必要が実際に生じた部分から切り出す判断が妥当です。境界を整えておけば、後からの分割も容易になります。
選択肢ごとの解説
- A正しい。利点が生きない段階で分散のコストを負わず、必要になった部分から切り出せる余地も残せます。
- B誤り。機能間で同じデータを扱う処理が多いため、データベースを分けるとSagaなどによる整合性の確保が多数必要になり、5人のチームには負担が過大です。複数チームが独立に開発・リリースする大規模なシステムなら検討に値します。
- C誤り。サービスメッシュは多数のサービス間の通信を一元的に制御したい場合に効果がありますが、コントロールプレーンやプロキシの運用が加わります。この規模と要件では導入の利点より運用負荷が上回ります。
- D誤り。データベースとリリース日を共有すると、サービスを分けても独立した変更やデプロイができず、ネットワーク越しの呼び出しのコストだけが増えます。いわゆる分散モノリスの状態です。