LinuCレベル4 システムアーキテクト システムアーキテクチャ 問6
システムアーキテクチャ／柔軟性を高めるアーキテクチャパターン社内のサービス間通信の方式を選ぶ。呼び出す側・呼び出される側とも自社開発のバックエンドで、低遅延が求められ、インターフェースを厳密な型付きのスキーマで定義してクライアントのコードを自動生成したい。さらに、双方向に連続してデータを送り合うストリーミングも必要である。最も適した方式はどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「システムアーキテクチャ」に対応。実際の試験問題ではありません）
- AOpenAPIで仕様を記述したREST APIとし、JSONで送受信してHTTPのキャッシュの仕組みも活用する
- BGraphQLのエンドポイントを1つ設け、クライアントが必要なフィールドだけを問い合わせて取得する
- CProtocol Buffersでサービスを定義したgRPCとし、HTTP/2上でバイナリ形式のメッセージをやり取りする
- Dメッセージキューに要求を投入し、処理側が非同期に取り出して結果を別のキューへ返すようにする
正解：C
解説
gRPCは、Protocol Buffersでサービスとメッセージの型を定義し、そこから各言語のクライアント・サーバーのコードを生成するRPCの仕組みです。HTTP/2上でバイナリ形式のメッセージをやり取りするため、JSONのテキストより軽量で、単方向・双方向のストリーミングにも対応します。REST（OpenAPI）は汎用性が高くブラウザや外部公開に向き、GraphQLはクライアントが取得するデータの形を柔軟に決めたい場面に向きます。内部のバックエンド間で低遅延・厳密な型・双方向ストリーミングを求めるならgRPCが適しています。
選択肢ごとの解説
- A誤り。RESTとOpenAPIは外部公開やブラウザからの利用、HTTPキャッシュの活用に向きますが、双方向ストリーミングを標準の枠組みとしては備えていません。
- B誤り。GraphQLはクライアントが必要なデータだけを柔軟に取得したい場面、特にフロントエンド向けの集約に向く方式で、この要件の中心である双方向ストリーミングや低遅延化の決め手にはなりません。
- C正しい。gRPCはスキーマからのコード生成、HTTP/2上のバイナリ通信、双方向ストリーミングをすべて備えています。
- D誤り。キューによる非同期通信は処理の切り離しや負荷の平準化に向きますが、呼び出し側が即座に応答を得たい低遅延の同期通信には向きません。