分散システムの設計面接は、多くのエンジニアにとって最も手ごわいテーマの一つではないでしょうか。単一のサーバーで完結するシステムとは異なり、複数のノードにまたがるシステムでは「ネットワークは信頼できない」という大前提のもとで設計を進めなければなりません。この前提を意識できるかどうかが、面接の合否を分ける大きなポイントになります。
実は、分散システム設計面接で面接官が最も聞きたいのは、CAP定理の定義を正確に暗唱できるかどうかではありません。知りたいのは、「この具体的なシナリオで一貫性と可用性のどちらを優先すべきか、そしてその理由は何か」という判断力です。理論と実践を結びつけて語れるかどうかが、評価の分かれ目になります。
この記事では、分散システム設計面接で頻出するCAP定理、一貫性モデル、分散合意アルゴリズムなどのテーマを、面接での回答に直結する形で解説していきます。抽象的な理論で終わらせるのではなく、「面接でこう聞かれたら、こう答える」という具体的な回答例も交えてお伝えします。
CAP定理の正しい理解と面接での語り方
CAP定理は、分散システムにおいて一貫性（Consistency）、可用性（Availability）、分断耐性（Partition Tolerance）の3つの性質を同時に満たすことはできないという定理です。面接で「CAP定理について説明してください」と聞かれたら、単にこの定義を述べるだけでなく、よくある誤解を解きほぐしながら説明することが重要です。
よくある誤解の一つが「3つの中から2つを選ぶ」という解釈です。この理解は部分的には正しいのですが、実際にはネットワーク分断は避けられないものであるため、現実の選択肢は「一貫性を優先するか（CP）」「可用性を優先するか（AP）」の2択になります。面接では「ネットワーク分断が発生した場合に、一貫性を犠牲にしてでもリクエストに応答し続けるか（AP）、一貫性を保証するためにリクエストを拒否するか（CP）の判断です」と説明すると、定理の本質を理解していることが伝わります。
そういえば、CAP定理の提唱者であるEric Brewerは、後に「CAP定理は過度に単純化されている」と述べています。実際のシステムでは、分断が発生していない通常時には一貫性と可用性の両方を提供でき、分断が発生した場合にのみトレードオフの判断が必要になります。面接でこのニュアンスに触れると、「教科書的な理解を超えて、実務的な視点を持っている」という印象を与えられます。
PACELC定理による拡張
CAP定理をさらに実用的に拡張したのがPACELC定理です。この定理は「分断が発生した場合（P）は可用性（A）と一貫性（C）のトレードオフがあり、分断がない通常時（E=Else）はレイテンシ（L）と一貫性（C）のトレードオフがある」と述べています。
面接でPACELC定理に言及できると、かなりの知識の深さをアピールできます。たとえばAmazon DynamoDBは「PA/EL」に分類されます。分断時には可用性を優先し、通常時にはレイテンシを優先する設計です。一方、Google Spannerは「PC/EC」に分類され、分断時にも通常時にも一貫性を優先します。面接で「このシステムの要件に合う一貫性モデルを選ぶにあたり、PACELC定理の観点からも検討します」と切り出せると、議論に深みが増すでしょう。
ただし、PACELC定理を語る際には、実際のシステムはきれいにカテゴリ分けできるものではなく、チューニングによって動作を調整できることも付け加えましょう。「DynamoDBでも強い一貫性読み取りを指定すれば一貫性を優先できます。設計時にはデフォルトの動作だけでなく、設定可能なオプションも含めて検討することが重要です」と述べれば、実務的な視点をアピールできます。
一貫性モデルの選択と設計への影響
分散システム設計面接で一貫性の話題が出ると、面接官はさまざまなレベルの一貫性モデルについて質問してきます。強い一貫性（Strong Consistency）から結果整合性（Eventual Consistency）まで、一貫性のスペクトラムを理解し、ユースケースに応じた選択ができることが求められます。
強い一貫性は、あるノードへの書き込みが完了した後は、どのノードから読み取っても最新のデータが返ることを保証します。これは最も直感的なモデルですが、実現するためにはノード間での同期通信が必要になり、レイテンシの増加やスループットの低下を招きます。金融機関の口座残高や在庫管理のように、データの正確性が絶対的に求められるシステムでは、強い一貫性が必要です。
結果整合性は、書き込み後にすべてのノードにデータが行き渡るまで時間がかかる可能性がありますが、最終的にはすべてのノードが同じデータを持つことを保証するモデルです。SNSの「いいね」のカウントやフォロワー数のように、多少の遅延が許容されるデータに適しています。面接では「一貫性の要件を厳しくするほどパフォーマンスが犠牲になる。だから、データの種類ごとに適切な一貫性レベルを選択する『混合一貫性アプローチ』が実務では一般的です」と説明すると、バランス感覚の良さをアピールできます。
因果一貫性とセッション一貫性
強い一貫性と結果整合性の間には、因果一貫性やセッション一貫性といった中間的なモデルがあります。面接でこれらのモデルに言及できると、一貫性の理解がより深いことを示せます。
因果一貫性は、因果関係のある操作の順序を保証するモデルです。たとえば、ユーザーAがコメントを投稿し、ユーザーBがそのコメントに返信した場合、どのノードでも「Aのコメント → Bの返信」の順序で表示されることを保証します。ただし、因果関係のない操作については順序を保証しません。面接では「SNSのコメント機能では、因果一貫性で十分です。強い一貫性を使うとレイテンシが悪化し、ユーザー体験が損なわれます」と答えることで、一貫性モデルの使い分けができることをアピールしましょう。
セッション一貫性は、同一セッション内での一貫性を保証するモデルです。ユーザーが自分の書き込みを直後に読み取れることを保証する「Read Your Writes」は、セッション一貫性の一種です。面接では「ユーザーがプロフィールを更新した直後に自分のプロフィールページを見た場合、更新内容が反映されている必要があります。この場合、Read Your Writes一貫性を適用し、書き込みを行ったノードから読み取ることで実現します」という実践的な例を出せると効果的です。
分散合意アルゴリズムの基礎
分散システム設計面接で上級者向けのテーマとして出題されるのが、分散合意アルゴリズムです。複数のノードがネットワーク遅延やノード障害がある中で、同じ値に合意するにはどうすれば良いか。この問題は分散システムの根幹に関わるテーマであり、面接で語れるとレベルの高い候補者として評価されます。
Raftアルゴリズムは、理解のしやすさを重視して設計された分散合意アルゴリズムです。リーダー選出、ログの複製、安全性の3つのサブ問題に分解されており、Paxosと比べて直感的に理解できます。面接で「分散合意にはRaftを採用します。リーダーがクライアントからの書き込みを受け付け、過半数のノードにログが複製されたら書き込みをコミットする仕組みです」と説明できれば、基本的な理解を示せます。
Paxosは歴史的に最も有名な分散合意アルゴリズムですが、その複雑さから実装の難易度が高いことで知られています。面接では「Paxosは理論的には優れていますが、実装が複雑なため、実務ではRaftベースのシステム（etcd、Consul、CockroachDBなど）を選ぶことが多いです」と答えると、理論と実務の両方を理解していることが伝わります。
リーダー選出とスプリットブレイン
分散合意に関連して、リーダー選出とスプリットブレインの問題も面接で出題されることがあります。複数のノードが同時にリーダーだと主張する「スプリットブレイン」状態は、データの不整合を引き起こす深刻な問題です。
Raftアルゴリズムでは、過半数の票を得たノードのみがリーダーになれるため、スプリットブレインを防止できます。面接では「3ノード構成の場合、2ノードの合意でリーダーが選出されます。ネットワーク分断で1ノードが分離された場合、2ノード側は引き続き動作できますが、1ノード側はリーダーを選出できないためリクエストを処理できなくなります。これにより、一貫性が保証されます」と具体的に説明しましょう。
ノード数の選定も面接で聞かれるポイントです。「なぜ3ノードや5ノードのような奇数が推奨されるのか」という質問には、「奇数ノードにすることで、ネットワーク分断時に必ず過半数を持つグループが存在し、リーダー選出の合意が取れるためです。3ノードなら1ノードの障害に、5ノードなら2ノードの障害に耐えられます」と答えましょう。
面接での設計シナリオと回答戦略
分散システム設計面接では、理論だけでなく具体的なシナリオを通じて設計力が問われます。面接官はシナリオを提示し、候補者がどのようにトレードオフを分析し、設計判断を下すかを観察しています。
「グローバルに展開するSNSのタイムラインを設計してください」というシナリオは、分散システムの典型的な問題です。この場合、タイムラインの読み込みは膨大なリクエスト数があり、レイテンシへの要求も厳しい一方、投稿の表示順序が多少前後しても致命的な問題にはなりません。面接では「タイムラインの読み込みにはAPモデルを採用し、結果整合性を許容します。各リージョンにレプリカを配置して最寄りのノードから読み取ることで、レイテンシを最小化します。投稿の書き込みは一つのリージョンをマスターとし、非同期でレプリケーションを行います」という設計を提案しましょう。
一方、「銀行の送金システムを設計してください」というシナリオでは、強い一貫性が絶対的に必要です。面接では「送金は残高の正確性が最優先のため、CPモデルを採用します。分散トランザクションを使って送金元と送金先の残高を同時に更新し、ネットワーク分断時はリクエストを拒否して二重送金を防止します。Raftベースの分散データベース（CockroachDBやTiDB）を使えば、強い一貫性を保ちながらもスケーラビリティを確保できます」と答えると、要件に応じた設計判断ができることを示せます。
コンフリクト解決の戦略
APモデルを採用した場合、複数のノードで同時にデータが更新されるとコンフリクト（衝突）が発生する可能性があります。面接では、このコンフリクトをどう解決するかという戦略も問われます。
Last Write Wins（LWW）は、タイムスタンプが最も新しい書き込みを勝者とする最もシンプルな戦略です。実装は容易ですが、先に書き込まれたデータが失われるリスクがあります。面接では「プロフィールの更新のように、最新の状態だけが重要なデータにはLWWが適しています」と説明しましょう。
CRDT（Conflict-free Replicated Data Type）は、コンフリクトが発生しても自動的に解決できるデータ構造です。カウンター、セット、マップなどの型があり、数学的にコンフリクトフリーであることが保証されています。面接で「SNSの『いいね』カウントにはGカウンター（CRDTの一種）を使い、各ノードで独立にカウントを増やし、読み取り時に合算することでコンフリクトなく一貫した値を得られます」と具体的に答えると、高い技術力を示せるでしょう。
面接でコンフリクト解決について聞かれた場合は、「データの種類と業務要件によって解決戦略を選択します」という前提を置いてから個別の戦略を説明すると、体系的な理解があることが伝わります。
まとめ
分散システム設計面接は、CAP定理や一貫性モデルといった理論的な知識と、具体的なシナリオでの設計判断力の両方が問われるテーマです。理論を暗記するだけでは不十分で、「なぜこのシステムにはAPモデルが適しているのか」「なぜ結果整合性で十分なのか」という根拠を、ビジネス要件と技術的な制約の両面から説明できることが重要です。
面接で高評価を得るためには、分散システムの「難しさ」を正直に認めたうえで、その難しさにどう対処するかを示すことが効果的です。「分散システムにおけるネットワーク障害は避けられないので、障害が起きた場合にどう振る舞うかを事前に設計に組み込みます」という姿勢を見せることで、面接官に信頼感を与えられます。
この記事で解説したCAP定理、PACELC定理、一貫性モデル、分散合意アルゴリズムの知識を組み合わせることで、分散システム設計面接の大部分のテーマに対応できるはずです。普段の業務で分散システムに触れる機会があれば、そこで得た知見を面接用の言葉で整理しておくことを強くおすすめします。