システム設計面接で「この処理を非同期にしてください」と言われたとき、すぐに「メッセージキューを使います」と答えられる人は多いでしょう。ところが、「どのメッセージキューを使いますか」「なぜそれを選びましたか」と掘り下げられると、途端に言葉に詰まってしまうケースをよく見かけます。KafkaとRabbitMQとSQSは、どれも「メッセージキュー」というカテゴリに属していますが、その設計思想や得意とするユースケースは驚くほど異なります。
実は、メッセージキューの選択は面接官にとって候補者の設計力を測る格好の材料です。なぜなら、正しい選択をするには、システムの要件（スループット、レイテンシ、順序保証、exactly-once処理の必要性）を深く理解している必要があるからです。面接官は「Kafkaが一番人気だから」といった曖昧な理由ではなく、具体的な技術的根拠に基づいた選択理由を聞きたがっています。
この記事では、メッセージキュー設計面接で求められる知識を網羅的に解説します。Kafka、RabbitMQ、SQSそれぞれの特性を深掘りし、ユースケースに応じた選択基準、非同期処理パターン、そしてメッセージの信頼性を確保する設計まで、面接で使える実践的な内容をお伝えします。
メッセージキューの基本概念と面接での位置づけ
メッセージキューは、プロデューサー（送信者）とコンシューマー（受信者）の間に介在して、非同期通信を実現するミドルウェアです。両者が同時にオンラインである必要がなく、処理速度の差を吸収できるため、システム全体の柔軟性と耐障害性が向上します。面接でメッセージキューの話題が出るのは、候補者が同期処理と非同期処理のトレードオフを理解しているかを確認するためです。
そういえば、メッセージキューを導入する理由として「デカップリング」という言葉がよく使われますが、面接ではこの概念をもう少し具体的に説明できると好印象です。たとえばEコマースサイトで注文が完了した後、メール送信、在庫更新、ポイント付与という3つの処理を同期的に行うと、どれか1つが遅延するだけで注文レスポンス全体が遅くなります。メッセージキューを使って非同期化すれば、注文処理はキューにメッセージを投入するだけで完了し、後続の処理は各コンシューマーが独立して実行できます。
面接官が特に注目するのは、「どんなときにメッセージキューを使うべきで、どんなときに使うべきでないか」という判断力です。単純なリクエスト-レスポンスで十分なケースにメッセージキューを持ち込むと、かえってシステムの複雑性が増します。面接では「応答時間に厳しい制約がなく、処理の失敗をリトライで回復できるユースケースにメッセージキューが適しています」という判断基準を示しましょう。
メッセージングモデルの違い
メッセージキューの設計を議論する前に、2つの基本的なメッセージングモデルを理解しておく必要があります。Point-to-Point（キューイング）モデルとPublish-Subscribe（Pub/Sub）モデルです。
Point-to-Pointモデルでは、メッセージは1つのコンシューマーにのみ配信されます。複数のコンシューマーがいる場合でも、各メッセージを処理するのは1つのコンシューマーだけです。タスクの分散処理に適しており、たとえば画像のサムネイル生成や動画のトランスコードなど、重い処理を複数のワーカーに分散させるケースで使われます。
Pub/Subモデルでは、メッセージは購読しているすべてのコンシューマーに配信されます。イベント通知やデータの同期など、1つのイベントを複数のシステムに伝播させたい場合に使われます。面接では「注文イベントを在庫サービス、メールサービス、分析サービスの3つに同時に配信する場合はPub/Subモデルが適しています」と、具体的な例を添えて説明しましょう。
Kafka・RabbitMQ・SQSの特性比較
設計面接で最も差がつくのが、具体的な技術の特性を正確に把握しているかどうかです。Kafka、RabbitMQ、SQSはどれもメッセージの仲介役を果たしますが、その内部アーキテクチャは根本的に異なり、それぞれ得意とする領域が明確に分かれています。
Apache Kafkaは分散ストリーミングプラットフォームとして設計されており、大量のデータを高スループットで処理することに特化しています。メッセージはトピック内のパーティションに追記型で保存され、コンシューマーはオフセットを管理しながら自分のペースでメッセージを読み取ります。メッセージが消費後も保持されるため、過去のデータを再処理できる点がKafkaの大きな強みです。ログの集約、イベントソーシング、リアルタイムデータパイプラインといった用途で広く採用されています。
RabbitMQは従来型のメッセージブローカーで、AMQP（Advanced Message Queuing Protocol）に準拠しています。Exchangeとキューの組み合わせによる柔軟なルーティングが特徴で、Direct、Topic、Fanout、Headersという4種類のExchangeタイプを使い分けることで、きめ細かいメッセージの振り分けが可能です。メッセージはコンシューマーに配信されると通常は削除されるPush型のモデルを採用しています。
SQSとマネージドサービスの位置づけ
Amazon SQSはAWSが提供するフルマネージドのメッセージキューサービスです。自前でブローカーを構築・運用する必要がなく、スケーリングも自動的に行われるため、運用コストが大幅に削減できます。面接でSQSを提案する場合は「インフラの運用負荷を減らしたい」「AWSエコシステムと密接に統合したい」という明確な動機を示しましょう。
SQSにはStandard QueueとFIFO Queueの2種類があります。Standard Queueはほぼ無制限のスループットを提供しますが、メッセージの順序は保証されず、まれに重複配信が発生する可能性があります。FIFO Queueは厳密な順序保証と exactly-once 処理を提供しますが、スループットに制限があります。面接では「順序が重要な金融取引にはFIFO Queueを、順序が不要なログ収集にはStandard Queueを使います」という使い分けを説明できると、サービスの深い理解を示せます。
面接で「Kafkaを自前で運用するか、SQSを使うか」と聞かれた場合は、「チームの運用能力と要件によります」という前提のもと、具体的な判断基準を述べましょう。Kafkaはメッセージの再処理やストリーム処理が必要な場合に強力ですが、ZooKeeperの管理やパーティションの設計など、運用の複雑さが伴います。少人数のチームでシンプルなキューイングが目的なら、SQSの方が総合的なコストが低くなるケースが多いです。
メッセージの信頼性と配送保証
メッセージキュー設計面接で必ず掘り下げられるのが、メッセージの配送保証です。メッセージは失われないか、重複して処理されないか、順序は保たれるか。これらの問いに対する回答が、面接の評価を大きく左右します。
配送保証には3つのレベルがあります。At-most-once（最大1回）はメッセージが失われる可能性がありますが、重複処理は発生しません。At-least-once（最低1回）はメッセージの損失を防ぎますが、重複処理が発生する可能性があります。Exactly-once（厳密に1回）はメッセージが正確に1回だけ処理されることを保証しますが、実装が複雑でパフォーマンスへの影響も大きくなります。
面接で重要なのは、「すべてのケースでexactly-onceが必要です」と安易に答えないことです。多くのシステムでは、At-least-onceの配送保証とコンシューマー側の冪等性を組み合わせることで、実質的にexactly-onceと同等の効果を得られます。冪等性とは、同じ処理を何度実行しても結果が変わらない性質のことです。たとえば「ユーザーのポイントを100増やす」ではなく「ユーザーのポイントを500に設定する」という処理にすることで、重複実行されても問題が生じなくなります。
Dead Letter Queueの設計
メッセージの処理が繰り返し失敗した場合にどう対処するか、これも面接で頻出するテーマです。処理不能なメッセージ（ポイズンメッセージ）が通常のキューに残り続けると、そのメッセージのリトライがキュー全体のパフォーマンスを低下させてしまいます。
Dead Letter Queue（DLQ）は、一定回数のリトライに失敗したメッセージを隔離する仕組みです。面接では「リトライ回数を3回に設定し、すべてのリトライが失敗したメッセージはDLQに転送します。DLQのメッセージは監視対象として、アラートを設定して運用チームが手動で原因を調査します」という運用フローを含めた回答が効果的です。
DLQに入ったメッセージの取り扱いについても触れておくと、面接官の印象は良くなります。「原因を調査した後、修正済みのメッセージを元のキューに再投入する仕組みも用意します。この際、メッセージにリトライ回数やエラー情報のメタデータを付与しておくことで、デバッグが容易になります」という回答は、実務での運用経験を感じさせるものです。
非同期処理パターンと設計手法
メッセージキューを使った非同期処理にはさまざまなパターンがあり、面接ではユースケースに応じて適切なパターンを選択できることが求められます。単純なタスクキュー以外にも、サーガパターン、イベントソーシング、CQRS（コマンドクエリ責務分離）など、高度なパターンが話題に上ることがあります。
サーガパターンは、複数のマイクロサービスにまたがるトランザクションを管理するための手法です。分散トランザクション（2フェーズコミット）を使わずに、各サービスがローカルトランザクションを実行し、失敗時には補償トランザクションで元に戻すというアプローチです。たとえば「注文サービスが注文を作成し、在庫サービスが在庫を確保し、決済サービスが支払いを処理する」という一連の流れを、メッセージキューを介して協調させます。
面接でサーガパターンを説明する際には、コレオグラフィ方式とオーケストレーション方式の違いにも触れましょう。コレオグラフィ方式では、各サービスがイベントを発行し、他のサービスがそのイベントに反応して処理を進めます。オーケストレーション方式では、中央のオーケストレーター（サーガマネージャー）が全体の流れを制御します。面接では「サービスの数が少ない場合はコレオグラフィ方式が適していますが、フローが複雑になるとオーケストレーション方式の方が理解しやすく、デバッグも容易です」という使い分けの基準を提示できると評価が高まります。
バックプレッシャーとフロー制御
メッセージキューの設計で見落とされがちですが、面接で差がつくのがバックプレッシャーの設計です。プロデューサーがコンシューマーの処理速度を大幅に上回るペースでメッセージを送信した場合、キューに大量のメッセージが滞留し、最終的にはメモリ不足やディスク容量の枯渇につながります。
バックプレッシャーとは、下流のコンポーネントが処理しきれない場合に、上流のコンポーネントに対して送信速度を落とすよう信号を送る仕組みです。面接では「キューの深さを監視し、しきい値を超えた場合にプロデューサーの送信レートを制限するか、コンシューマーのスケールアウトを自動で行う設計にします」と答えると、システムの安定性に対する配慮を示せます。
Kafkaの場合、コンシューマーがPull型でメッセージを取得するため、自然とバックプレッシャーが働きます。コンシューマーが処理できる分だけメッセージをフェッチするので、過負荷になりにくい設計です。一方、RabbitMQのようなPush型のブローカーでは、prefetch countを設定してコンシューマーが同時に処理するメッセージ数を制限する必要があります。この違いを面接で説明できると、各技術の内部動作をよく理解している印象を与えられます。
面接シナリオ別の回答例
メッセージキュー設計面接で実際に出題されるシナリオを想定して、回答の組み立て方を見ていきましょう。面接官はシナリオを通じて、候補者の技術選定力、トレードオフの理解、そして実務的な設計能力を総合的に評価しています。
「大規模なログ収集システムを設計してください」というシナリオでは、Kafkaが最適な選択肢です。理由は、高スループットでデータを受け入れ、複数のコンシューマーグループが同じデータを独立して処理できるためです。回答の組み立て方としては、「各アプリケーションサーバーからFluentdなどのログコレクターがKafkaにログを送信し、リアルタイム分析用のコンシューマーグループとバッチ分析用のコンシューマーグループがそれぞれ独立してデータを処理します。Kafkaのデータ保持期間は7日間に設定し、障害時のリプレイにも対応します」という具体的な設計を示しましょう。
「注文処理システムのメール通知を非同期にしてください」というシナリオでは、要件の複雑さに応じてRabbitMQかSQSを選びます。面接では「メール送信は順序保証が不要で、リトライで回復可能な処理です。AWSを使っている前提であれば、運用コストの低いSQS Standard Queueを選択します。送信失敗時のリトライは3回まで行い、それでも失敗したメッセージはDLQに転送して手動で対応します」という回答で十分です。
パーティション設計とスケーリング
面接でKafkaを選択した場合、パーティション設計について掘り下げられることが多いです。パーティション数はスループットとコンシューマーの並列度に直結するため、慎重な設計が求められます。
回答のポイントは「パーティション数 >= コンシューマー数」という基本原則を踏まえつつ、パーティションキーの選定理由を説明することです。「ユーザーIDをパーティションキーにすることで、同一ユーザーのイベントが同じパーティションに入り、順序が保証されます。パーティション数は初期で12に設定し、コンシューマーを12台まで水平スケールできるようにします」という回答は、具体性があり面接官を納得させやすいでしょう。
パーティションの偏り（ホットパーティション）問題にも触れておくと、さらに高い評価が得られます。「特定のユーザーのイベントが極端に多い場合はパーティションが偏るため、イベントのサンプリングやパーティションキーの分散を検討します」という考慮点を示すことで、大規模システムの運用経験を感じさせる回答になります。
まとめ
メッセージキュー設計面接で成功するためには、Kafka、RabbitMQ、SQSの特性を正確に理解し、ユースケースに応じた選択ができることが不可欠です。面接官は「なぜその技術を選んだのか」という根拠を聞きたがっているため、各技術のアーキテクチャの違いと、それがもたらす実用上のメリット・デメリットを自分の言葉で説明できるように準備しておきましょう。
配送保証のレベル、Dead Letter Queueの設計、バックプレッシャーへの対処など、メッセージキューの運用に関わるテーマも面接の重要な評価ポイントです。これらのテーマについて、単なる知識としてではなく「自分が設計するならこうする」という具体的なアプローチを持っておくことで、面接での回答に説得力が生まれます。
メッセージキューはシステム設計の中で非常に汎用性の高いコンポーネントであり、面接でも頻繁に登場します。この記事の内容を土台にして、自分の経験やプロジェクトに当てはめながら理解を深めていくことが、面接突破への最短ルートになるでしょう。