Web／分散システム設計 問題集・練習問題クイズ

決済作成APIで、クライアントが応答を受け取れず同じ要求を再送しても二重決済を防ぎたい。適切な設計はどれですか？

答え： クライアント発行の冪等性キーを保存し、同じキーと要求には以前の結果を返す

冪等性キーを業務結果と関連付けて原子的に保存すると、応答喪失後の再送を新規処理せず以前の結果へ対応付けられます。キーの有効期限と、同一キーで内容が異なる場合の拒否も定義します。

公開APIへ必須フィールドを追加したい。既存クライアントを壊しにくい変更方法はどれですか？

答え： まず任意フィールドとして追加し、既定動作・利用状況を整備してから新Versionで必須化する

API変更はadditiveかつ後方互換に進め、利用状況を計測しながら移行期間を設けます。契約を破る変更は明示的な新Versionと廃止計画で扱います。

更新が多い大規模データをAPIでページングする。深いOFFSETの遅延とページ間の重複を抑える方法はどれですか？

答え： 一意で安定した並び順と最後のキーを含むCursorを使う

作成時刻とIDなどによる一意な順序を決め、前ページ末尾より後を取得するkeyset方式ならIndex Seekを利用しやすく、途中挿入の影響も抑えられます。

API利用者ごとの短時間バーストを許容しつつ、平均要求率を制限したい。適切な方式はどれですか？

答え： Token Bucketを利用し、超過時は429とRetry-Afterを返す

Token Bucketは一定速度でTokenを補充し、蓄積分だけバーストを許可します。制限単位を利用者・API Key・Tenantなどで定義し、429と再試行目安を返します。

上流APIの残り応答時間が800msで、下流サービスを二つ順番に呼ぶ。適切なTimeout設計はどれですか？

答え： 全体Deadlineを伝播し、各呼出しへ残り時間より短い予算を割り当てる

入口で決めたDeadlineを伝播し、Networkや後処理の余白を引いて下流へ予算配分します。期限超過時は不要な処理をCancellationし、資源を解放します。

一時的な503に対する再試行で、障害中サービスへの同時集中を避ける方法はどれですか？

答え： 回数を制限し、指数BackoffへJitterを加え、冪等な操作だけを再試行する

指数Backoffは試行間隔を広げ、JitterはClient間の同期を崩します。再試行対象、総時間、回数を制限し、非冪等操作には冪等性制御が必要です。

下流サービスが連続失敗している間、呼出し元の資源を守り、回復確認も行いたい。適切な仕組みはどれですか？

答え： Circuit BreakerをOpenにして早期失敗し、一定時間後にHalf-Openで少数試行する

Circuit Breakerは失敗率などでOpenとなり、失敗が明らかな呼出しを短絡します。待機後のHalf-Open試行で回復を確認し、成功すればClosedへ戻します。

低優先度の帳票APIが接続Poolを使い切り、重要な決済APIまで停止することを防ぎたい。適切な設計はどれですか？

答え： 機能ごとにThread・接続・同時実行枠を分離するBulkheadを設ける

Bulkheadは船の隔壁のように資源を分離し、一機能の飽和を他機能へ波及させません。重要度に応じてPoolやSemaphoreの上限を設定します。

Consumer処理能力を超えるイベントが流入している。Memory枯渇を避けるBackpressure設計はどれですか？

答え： Bounded Queueと流量制御を使い、Producer抑制・拒否・遅延の方針を定める

容量を有限にし、満杯時の挙動をAPI・Broker・Reactive Streamの契約として定義します。重要度に応じて429、Producer待機、Queueing、負荷制限を使い分けます。

依存DBが停止した際、Podを再起動し続けずトラフィックだけを外したい。Probe設計はどれですか？

答え： Process健全性はliveness、依存先を含む受付可否はreadinessで分ける

livenessは再起動で回復できるProcess異常、readinessは現在要求を処理できるかを表します。共有DB障害は通常Pod再起動では直らないため、readinessで切り離します。

Network Partition中も二つのRegionで書込みを受け付ける設計を選ぶとき、CAPの観点で受け入れる必要があるものはどれですか？

答え： 一時的な不整合と、復旧後の競合解決

Partition Toleranceが必要な状況で両側のAvailabilityを維持すると、互いの更新を即時確認できず強いConsistencyを同時には保証できません。競合検出・解決規則を業務に合わせて設計します。

注文更新直後に同じ利用者が参照すると古いReplica値が見える。Read-your-writesを提供する方法はどれですか？

答え： 更新後一定期間はPrimaryへRoutingするか、Version以上のReplicaを待って読む

書込みで得たVersionやLSNをSessionへ保持し、その位置まで追随したReplicaを選ぶかPrimaryを読むと、その利用者の直前更新を観測できます。

注文、決済、在庫を別サービスが管理する。分散Transactionを使わず業務全体の失敗を扱う設計はどれですか？

答え： SagaでLocal Transactionを連鎖し、失敗時の補償処理を定義する

Sagaは各サービスのLocal TransactionとEventまたはCommandを組み合わせ、後続失敗時に返金・在庫解放など意味上の補償を実行します。補償自体の冪等性も必要です。

DB更新は成功したがEvent Brokerへの送信だけ失敗する二重書込み問題を防ぎたい。適切なPatternはどれですか？

答え： 業務更新とOutbox行を同じDB Transactionで保存し、Relayが後からBrokerへ送る

Transactional OutboxはEvent送信予定を業務Dataと原子的にCommitします。Relayは未送信行を再試行できるため、Consumer側の冪等性と組み合わせて欠落を防ぎます。

Brokerが同じEventを再配信しても副作用を一度だけにしたい。Consumer設計はどれですか？

答え： Event IDへ一意制約を設け、処理済み記録と業務更新を原子的に保存する

At-least-once配送では重複を正常系として扱います。永続的なDeduplication Keyと業務更新を同じTransactionへ含めれば、CrashやACK喪失後の再配信にも耐えられます。

BrokerがExactly-once配送を掲げている場合でも、外部DB更新に冪等性が必要な理由はどれですか？

答え： Broker内の保証は外部DBとの原子性まで自動的に含まず、CommitとACKの境界で再処理が起こり得る

保証範囲を明確にします。Broker内TransactionやDeduplicationがあっても、外部DB Commit後・ACK前のCrashなどでは処理が再開されるため、業務副作用を冪等にします。

顧客ごとの注文Event順序を維持しつつ、顧客間は並列処理したい。Partition Keyは何にすべきですか？

答え： customerId

同じcustomerIdを同じPartitionへRoutingすれば、その顧客の順序をPartition内で保ちつつ、異なる顧客は複数Partitionで並列化できます。Hot Key分布も監視します。

同じMessageが繰り返し失敗しQueue先頭を塞いでいる。適切な運用はどれですか？

答え： 上限回数後にDLQへ隔離し、原因・Alert・修正後の再投入手順を整備する

Poison Messageは有限回のRetry後にDLQへ分離し、正常Messageの進行を守ります。DLQ滞留数、最古Ageを監視し、修正後は安全にRedriveします。

Event Schemaへ新フィールドを追加する。旧Consumerとの互換性を保つ方法はどれですか？

答え： Fieldを任意またはDefault付きで追加し、Consumerは未知Fieldを無視できるようにする

EventはProducerとConsumerを独立Deployできるよう、前方・後方互換なSchema Evolutionを行います。Schema Registryと互換性Ruleで破壊的変更を検出します。

更新Modelは正規化し、検索画面は集計済みの別Modelで高速化したい。適切なPatternはどれですか？

答え： CQRSでCommand ModelとQuery Modelを分離し、Eventなどで同期する

CQRSは書込みのInvariantと読取り形状を分離できます。Query Model更新は通常非同期なので、Lag、再構築、冪等性、正本を明確にします。

Cache-asideで商品情報を取得する基本的な流れはどれですか？

答え： Cacheを読み、MissならDBから取得してCacheへ保存し、更新時はCacheを無効化する

Cache-asideではApplicationがCacheと正本DBを調整します。Miss時にLazy Loadし、更新時は通常DB Commit後にCacheを削除して次回再構築します。

人気Cache KeyのTTL切れと同時に大量RequestがDBへ到達するCache Stampede対策はどれですか？

答え： Key単位のSingle-flight、TTL Jitter、必要に応じた事前更新を使う

一つのLoaderだけが再計算し他Requestは結果を待つSingle-flightで重複処理を抑えます。Jitterは大量Keyの同時失効を分散します。

DB更新とCache削除のRaceで古い値が再Cacheされる問題を減らす設計はどれですか？

答え： DB Commit後にEventで無効化し、Version付きValueや短いTTLも組み合わせる

Commit済み変更に基づく無効化EventとVersion比較を使うと、遅れて到着した古い値による上書きを防ぎやすくなります。完全な同期が必要か、Bounded Stalenessでよいかも決めます。

CDNで言語別・圧縮方式別のResponseを安全にCacheしたい。Cache Key設計はどれですか？

答え： Pathと必要なQueryに加え、実際にResponseが変わる言語・Encoding HeaderだけをKeyへ含める

Responseを変化させる入力だけをCache Keyへ含めます。少なすぎるとData混在、多すぎるとHit率低下になるため、個人化ResponseはCacheしないか安全に分離します。

Cache Nodeを一台追加した際、大半のKey再配置を避けたい。適切な分散方法はどれですか？

答え： Consistent HashingとVirtual Nodeを使う

Consistent HashingはHash Ring上で近接NodeへKeyを割り当て、Node増減時の移動範囲を限定します。Virtual Nodeで物理Node間の偏りも緩和します。

Multi-tenantの注文DBをShard分割する。Tenant内Queryが多く、Tenant間Joinはほぼない。適切なShard Keyはどれですか？

答え： tenantIdを基礎にし、巨大Tenantには追加分割を検討する

主要Access Patternと同じtenantIdでCo-locationすると、多くのQueryを単一Shard内で完結できます。Tenant Sizeの偏りとRebalancing手順も設計します。

Read ReplicaのLagがあるSystemで、在庫確保直後の確認だけは最新値が必要である。適切なRoutingはどれですか？

答え： 整合性が必要な読取りはPrimaryまたは追随Version確認済みReplicaへ送り、一般参照だけReplicaへ送る

Read要件を分類し、在庫・権限など強い整合性が必要な経路はPrimaryまたは必要位置まで追随したReplicaを使います。一般画面はLag許容でScaleできます。

5 Replica中、書込み・読取りQuorumを設定して重なりを保証する条件はどれですか？

答え： R + W > 5となるようにする

N ReplicaでR + W > NならRead集合とWrite集合が少なくとも一台重なります。さらにW > N/2なら同時Write Quorum同士も重なります。実装のVersion比較も必要です。

旧LeaderがPartition後も書込みを続け、新Leaderと二重更新するSplit Brainを防ぐ仕組みはどれですか？

答え： 単調増加するFencing Tokenを各Leaderへ発行し、Storageが古いTokenの書込みを拒否する

Leaseが失効しても停止前のProcessが遅れて動く可能性があります。下流StorageがEpoch/Fencing Tokenを検証して古いLeaderを拒否することで安全性を守ります。

分散LockのLeaseを取得してBatchを実行する。安全な実装上の注意はどれですか？

答え： Lease期限、更新失敗、Clock前提を考慮し、重要な書込みにはFencing Tokenも使う

分散LockはCrash回復のため期限が必要ですが、停止・遅延したOwnerが期限後に再開する危険があります。Leaseだけに頼らず、書込み先で古いTokenを拒否します。

HTTP Serviceを複数Instanceへ水平Scaleし、任意InstanceへRoutingしたい。適切な設計はどれですか？

答え： ServiceをStatelessにし、Session状態は共有Storeまたは署名済みTokenで管理する

Instance固有状態を減らすと、Load Balancerが任意の正常InstanceへRoutingでき、Scale Out・再起動・Deployが容易になります。共有Session Storeにも可用性とTTLが必要です。

共有Session Storeが障害になると全Web Instanceへ影響する。適切な対策はどれですか？

答え： Storeを冗長化し、Timeout・容量・Eviction・再認証時の挙動を設計する

共有Storeは新しい集中依存になります。Replica・Failover、短いTimeout、適切なTTLと容量監視を設け、復旧不能時は安全に再認証を求めます。

二つのRegionで同じUser Profileを同時更新できるActive-Active構成に必要な設計はどれですか？

答え： 競合検出とField別Mergeまたは明示的な優先規則を定義する

Active-ActiveではNetwork遅延やPartitionにより同一Dataへの並行Writeが起きます。Version Vector、Timestamp、CRDT、業務MergeなどからData特性に合う規則を選びます。

DNS Failoverで障害Regionから待機Regionへ切り替える際の注意点はどれですか？

答え： TTLとResolver Cacheにより切替は即時ではないため、両系の重複Trafficを想定する

DNS回答は再帰ResolverやClientにCacheされるため、切替中は旧・新EndpointへTrafficが分かれます。TTL、Health Check、Data RPO、Session、Failbackを含めて訓練します。

一つの利用者RequestがAPI Gateway、Service、Queue、Workerを通る。End-to-endで追跡する方法はどれですか？

答え： Trace ContextをHTTPとMessage Headerへ伝播し、各Spanへ共通Trace IDを記録する

W3C Trace Contextなどを境界間で伝播し、同期・非同期処理をSpanとして関連付けます。Samplingと個人情報Maskingを適用し、Metric・Logとも相関させます。

可用性SLO 99.9%を設定したServiceで、Error Budgetを使う目的はどれですか？

答え： 許容される信頼性不足を定量化し、Release速度と安定化作業の判断基準にする

Error Budgetは100%とSLOの差で、一定期間に許容する失敗量です。消費が速ければReleaseを抑えて改善し、余裕があれば安全に変更を進める共通判断に使います。

平均Latencyは100msだが一部利用者が数秒待つ。改善判断に最も有用な指標はどれですか？

答え： p95・p99などのPercentileをEndpoint・Region別に確認する

Percentileは利用者の遅いTailを可視化します。平均は大量の高速Requestに希釈されるため、p95/p99とTraffic量、Error、依存先Spanを組み合わせます。

本番相当環境でService Instanceを意図的に停止するChaos Testを安全に行う方法はどれですか？

答え： 定常状態の仮説、影響範囲、停止条件、監視、Rollbackを事前定義して小さく開始する

Chaos Engineeringは無秩序な破壊ではなく、仮説を持つ制御された実験です。Blast Radiusを限定し、自動Abortと観測で安全性を保ちながら弱点を発見します。

平均到着率が毎秒200件、平均処理時間が0.5秒の処理で、Littleの法則による平均同時処理数はいくつですか？

答え： 100件

Littleの法則L=λWより、200件/秒×0.5秒=100件です。平均値なのでPeak、分散、待ちQueue、Headroomを別途考慮してCapacityを決めます。

CPU使用率は低いがQueue待ち時間が急増する非同期WorkerをAuto Scaleしたい。適切な指標はどれですか？

答え： Queue深さまたは最古Message AgeをWorker数・処理率と組み合わせる

I/O待ち中心のWorkerではCPUが飽和しなくてもBacklogが増えます。Queue Length per WorkerやOldest AgeをSLOに結び付け、起動時間とScale-in時の処理中Messageも考慮します。