お題と適切なコンテキスト
これはシステムデザインの質問です。肝心なのはURLまたはヘッダーによるバージョニングの選択ではなく、APIライフサイクルのコントロールプレーンを設計することです。コントラクト（規約）の変更は、影響分析、実際のコンシューマー検出、新旧の挙動チェック、段階的移行、そして証拠に基づくシャットダウンへと流れる必要があります。Microsoftは可能であれば後方互換性を維持することを推奨しており、Google Cloudも同様にまずは互換性のある進化を試みることを推奨しています。この面接では、それらの原則を複数のチーム間で機能するシステムへと変換することが求められています。
面接官が評価するポイント
- フォーマットの互換性、エンティティのセマンティクス（意味）の変更、そして真の破壊的変更を区別できているか。
- APIコントラクト、コンシューマー台帳、ランタイムトラフィック、および移行作業を連携させられているか。
- バージョンラベルだけでなく、互換性テスト、段階的ロールアウト、アラート、通知、ロールバックを設計できているか。
- 複数バージョンを維持する運用コスト、データ変換リスク、および組織の境界について説明できるか。
最初に確認すべき明確化のための質問
APIが内部向け、パートナー向け、一般公開のいずれであるか、コンシューマーを完全に特定できるか、そしてトラフィック、レイテンシ、可用性の目標を確認します。対象のフィールドがオプショナル（任意）であるか、その意味が変わるか、読み取り・書き込み・永続化データのいずれが関与するかを明確にします。OpenAPIなどのコントラクトソースの有無、クライアントSDK、通知チャネル、サポート期間、コンプライアンス要件、ロールバック可能期間について尋ねます。スケールが指定されていない場合は、自身の前提を提示します。
30秒の回答フレームワーク
私は「コントラクトレジストリ」「影響の検出」「互換性の検証」「移行の調整」「シャットダウンの証拠」の5つのステージを設計します。すべてのAPIコントラクトをレジストリに登録し、ルールエンジンが変更を分類した上で、静的依存関係とランタイムの呼び出しを組み合わせてコンシューマーを特定します。コンシューマーに期日と移行ガイドを含む通知を送りながら、新旧バージョンを並行稼働させます。段階的ロールアウト中は、バージョンごとに成功数、エラー数、残存トラフィックを記録します。重要なコンシューマーの移行が完了し、移行の証拠が揃い、ロールバックがリハーサルされ、オーナーが変更を承認した後にのみシャットダウンを実行します。
ステップごとの詳細な回答
1. コントラクトレジストリと変更ルールの構築
レジストリには、各API、バージョン、オーナー、フィールドのセマンティクス、認証スコープ、サポート状態、非推奨化日、移行ドキュメントを保存します。変更リクエストにはコントラクトのdiffが含まれ、ルールエンジンがフィールドの削除、enum値の縮小、必須性の変更、エラーセマンティクスの変更、エンティティ関係の変更にフラグを立てます。無視可能なフィールドの追加は通常互換性がありますが、クライアントが未知のフィールドを正しく無視するとは限らないため、チームには証拠に裏付けられた例外処理パスが必要です。
2. コンシューマーの検出と影響グラフの構築
リポジトリの依存関係、ゲートウェイログ、サービスメッシュのテレメトリ、SDK登録、および宣言情報を組み合わせて、API-バージョン-コンシューマーのグラフを作成します。静的検出では動的に構築されたリクエストを見落とす可能性があり、ランタイム検出では低頻度のバッチジョブを見落とす可能性があるため、証拠ソース、最終確認日時、信頼度を記録します。外部クライアントについては、ログを無期限の個人データとして扱うのではなく、必要なテナントおよびアプリケーション識別子のみを保持します。
3. セーフティゲートによる互換性の検証
変更ごとに、コントラクトテスト、コンシューマーリプレイ、サンプリングトラフィック比較を実行します。読み取り時のレスポンスセマンティクスを確認し、古いクライアントからの書き込みでデータ損失や意図しない副作用が発生しないことを検証します。破壊的変更は、シャドウトラフィックまたは少数のテナントコホートから開始します。バージョンのルーティングと機能フラグは元に戻せるようにする必要があります。テストスイートを通過したからといって未テストのコンシューマーでも問題ないとみなすのではなく、障害発生時には古いバージョンを維持します。
4. 通知、移行、複数バージョンの運用の調整
通知サービスは、コンシューマー、重要度、サポート契約に基づいて、移行ガイド、期日、リクエスト例、連絡先を送信します。外部顧客には照会可能なステータスページまたはコンソールが必要です。移行作業では、オーナー、ブロッカー、検証の証拠、最後の成功した呼び出しを記録します。複数バージョンの運用はテスト、デプロイ、監視のコストを増大させるため、すべてのバージョンを無期限にサポートするのではなく、バージョン数の上限、非推奨化ステージ、移行パスを設定します。
5. シャットダウンの判断、監視、および復旧
シャットダウンの前に、重要なコンシューマーのアップグレード完了、残存呼び出しが閾値未満であること、エラーの悪化がないこと、データ変換が可逆であること、サポート体制が整っていることを検証します。コホートとタイムウィンドウを活用し、新規オンボーディングを停止し、古い呼び出しに対して明確な非推奨エラーと移行リンクを返し、その後にルーティングを無効化します。互換性エラー、旧バージョンのトラフィック、移行完了率、通知到達率、ロールバック数、コンシューマーセグメント別のエラーを追跡します。Kubernetesは、安定性レベル、最小サポート期間、変換、ロールバックの制約を明示的なポリシーにする方法を示しています。組織向けにそれらの制約を設定し、その日付を機械的にコピーすることは避けます。
高品質な回答例
私はコンシューマーの種別、コントラクトのソース、削除されるフィールドの読み取り/書き込みセマンティクス、外部通知の義務、ロールバック可能期間を明確にします。コントラクトレジストリが変更ルールエンジンに入力を提供し、ルールエンジンは破壊的な差分を特定して、コードの依存関係、ゲートウェイログ、サービスメッシュテレメトリから構築された鮮度情報付きの影響グラフに関連付けます。互換性テスト、コンシューマーリプレイ、段階的なトラフィック適用により新旧の挙動を検証し、通知サービスが各コンシューマーに移行ガイドと期日を送信します。バージョンは並行稼働させ、移行作業には検証の証拠を保存します。重要なコンシューマーが移行し、残存トラフィックとエラーが閾値を満たし、ロールバックがリハーサルされ、オーナーが承認した後にのみ、古いルートを廃止します。監査ログに変更、通知、監視結果、ロールバックを記録することで、未知のクライアントが一斉に遮断されるのを防ぎます。
よくある間違い
- コンシューマーの検出やシャットダウンの証拠がないまま、URL、ヘッダー、セマンティックバージョニングのラベルについて議論すること。
- 静的コード検索や単一のアクセスログのみに依存し、動的呼び出しや低頻度の呼び出しを見落とすこと。
- 実際のクライアントのパース処理をテストせずに、オプショナルなフィールドの削除が自動的に安全であると思い込むこと。
- 段階的ロールアウトやロールバックを用意せずに、新しいバージョンをリリースして即座に古いバージョンを停止すること。
- テスト、監視、変換のコストを考慮せずに、すべてのバージョンを永遠にサポートし続けること。
- 期日、オーナー、エスカレーションパス、セグメント化されたメトリクスなしで、1通のメールを送信して済ませること。
フォローアップ質問と回答
外部クライアントが特定できない場合、シャットダウンをどのように判断しますか？
未知の利用状況をリスク状態として扱い、監視期間を延長し、テレメトリを増やし、契約上のオーナーに連絡するか移行診断を提供します。ログがゼロであることは利用がゼロであることを証明しません。シャットダウンの前には、復旧可能な拒否ポリシーと緊急フォールバックを使用します。
レスポンスフィールドの追加は常に互換性がありますか？
いいえ。ルール上は通常互換性があると分類されるかもしれませんが、実際のコンシューマーリプレイ、SDKマトリクス、エラーサンプリングによる検証が依然として必要です。厳格なスキーマバリデータを使用している場合は、個別の移行やバージョンの境界が必要になることがあります。
古いクライアントによって書き込まれたデータを安全に移行するにはどうすればよいですか？
まずセマンティックマッピングとデータ欠損なしの条件を定義し、その上でデュアルリード、デュアルライト、またはバージョン記録を伴うオフライン変換を使用します。変換は検証可能で可逆的でなければなりません。読み取り時にビジネス上の意味を暗黙的に変更してはなりません。
顧客が期日までにアップグレードできない場合はどうしますか？
契約とリスクに応じて、限定的な互換性期間、アダプター、または移行支援を提供し、コスト、オーナー、新たな終了日を記録します。例外措置は未知のトラフィックを減らすためのものであるべきで、古いバージョンを恒久化するためのものであってはなりません。
コントロールプレーンが単一障害点（SPOF）になるのを防ぐにはどうすればよいですか？
データプレーンのルーティングで、コントロールプレーンへのリアルタイムな書き込みを必須にしてはなりません。承認されたバージョンポリシーをキャッシュし、コントロールプレーンの障害時にも直近の安全な設定を維持します。レジストリ、通知、メトリクスのサービスは非同期に回復可能とし、一方でシャットダウンには二重承認と明示的なロールバック手順を必須とします。