LinuCレベル4 システムアーキテクト システムアーキテクチャ 問11
システムアーキテクチャ／柔軟性を高めるアーキテクチャパターンスマートフォンアプリが、バックエンドの15個のマイクロサービスをそれぞれ直接呼び出している。サービスの分割や統合のたびにアプリの改修と再配布が必要になっており、さらに各サービスが外部からの要求の認証とアクセスログの記録を個別に実装しているため、実装のばらつきも問題になっている。サービス側の構成を自由に変えてもアプリに影響させないようにしたい。設計として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「システムアーキテクチャ」に対応。実際の試験問題ではありません）
- A外部からの入口にAPIゲートウェイを置いて単一の窓口とし、認証とログの記録をそこで行って、要求を内部の各サービスへ振り分ける
- B各サービスにサイドカープロキシを配置してサービスメッシュを構成し、サービス間の内部通信をmTLSで暗号化・相互認証する
- C認証とログの記録を共通ライブラリにまとめ、全サービスが同じバージョンのライブラリを組み込むことで実装のばらつきをなくす
- DサービスごとにL4ロードバランサーを置いて固定の仮想IPを割り当て、アプリにはその仮想IPを接続先として設定させる
正解：A
解説
APIゲートウェイは外部のクライアントに対する単一の入口となり、要求のパスなどに応じて内部のサービスへ振り分けます。クライアントはゲートウェイのAPIだけを知っていればよいため、内部でサービスを分割・統合してもゲートウェイの振り分けを変えるだけで済みます。認証やログの記録、流量の制御といった横断的な機能を入口に集約できるのも利点です。一方で、ゲートウェイが単一障害点や性能のボトルネックにならないよう冗長化と拡張を設計する必要があります。
選択肢ごとの解説
- A正しい。クライアントとサービスの間に入口を1つ設けることで、内部構成の変更をアプリから隠し、認証やログの記録も一か所にまとめられます。
- B誤り。サービスメッシュは主にサービス間（内部）の通信を扱う仕組みで、アプリが15個のサービスを個別に知っている問題は解消しません。
- C誤り。実装のばらつきは減りますが、ライブラリの更新には全サービスの再デプロイが必要で、アプリがサービスを直接呼ぶ構造も変わりません。
- D誤り。各サービスの台数増減は隠せますが、アプリは依然として15個の接続先を個別に知っている必要があり、サービスの分割・統合の影響も認証の集約も解決しません。