プロンプトとコンテキスト
このシステムデザインの設問では、低レベルの TCP keep-alive パラメータを統制されたプラットフォーム機能へ昇華できるかがテストされます。単にプローブを頻繁に送信すればよいというわけではありません。トランスポートの生存性とアプリケーションの健全性を分離した上で、テナント分離、ポリシーバージョン、接続ライフサイクル、ネットワークコスト、および復旧を設計してください。
面接官がテストしていること
- アイドル時間、プローブ間隔、最大失敗回数、および偽陽性の関係を説明できるか。
- 安全なデフォルト値、テナントクォータ、権限、および設定バリデーションを設計できるか。
- ホットアップデート時のチャーン（大量切断・再接続）を引き起こさず、適切な接続ライフサイクルのタイミングでポリシーを適用できるか。
- 監査可能性、メトリクス、ロールアウト、ロールバック、および過負荷保護を提供できるか。
明確化のための質問
接続タイプ、クライアントとサーバーの制御権、共有ノード、NAT、モバイルネットワーク、プロキシ、およびデッド接続検出のビジネス目標を確認します。カーネルのサポート状況、keep-alive がデフォルトで無効化されているか、既存のアプリケーションハートビート、テナントごとの接続数とリソースバジェット、変更の即時反映が必要かどうかをチェックします。TCP プローブはトランスポート層の応答を確認するだけであり、アプリケーションレベルのヘルスチェックを代替するものではありません。
30秒の回答フレームワーク
保守的なグローバルデフォルト値とテナント上限を備え、アイドル時間、プローブ間隔、失敗回数の組み合わせを検証する、バージョン管理されたテナントポリシーサービスを構築します。新規接続はポリシーバージョンを読み取ってバインドし、膨大なソケットのリセットを避けるためにランタイムの更新は制御します。公開には承認、監査、段階的ロールアウト、自動ロールバックを必須とし、データプレーンはプローブ、切断、偽陽性を記録します。総プローブバジェットに上限を設け、コントロールプレーンが利用できない場合は最後に有効だったバージョンを引き続き使用し、ビジネスセマンティクスにはアプリケーションハートビートを確保します。
ステップごとの設計
1. ポリシーモデルと安全なデフォルト値の定義
idle-time、probe-interval、max-probes、接続スコープ、バージョン、有効期限、ソースを含めます。RFC 9293 では keep-alive を接続ごとに切り替え可能とし、デフォルトで無効にすることを規定しています。また、RFC 9643 ではプローブがリソースを消費するため保守的な間隔を推奨しています。十分に長いデフォルトのアイドル時間と間隔を採用し、テナントがこれらを短縮できるのはリソースバジェット内に限定します。
2. コントロールプレーンとデータプレーンの分離
コントロールプレーンはテナントポリシー、バージョン、監査ログを保存し、検証、承認、公開、ロールアウト、ロールバックの機能を提供します。接続セットアップまたはハンドシェイク後、データプレーンは署名付きスナップショットを読み取り、制御可能なソケットに適用して、有効なバージョンを報告します。短時間のコントロールプレーン停止ですべての接続が失敗してはならないため、最後に有効だったスナップショットをキャッシュし、期限切れ時の動作を定義します。
3. 組み合わせとクォータの検証
安全な下限を下回るプローブ間隔を拒否し、テナントごとの接続数とプローブレートに上限を設け、失敗回数が検出時間の目標と一致しているかを検証します。1つのテナントが特定のインスタンスグループにプローブを集中させないよう、ノード、ゾーン、エグレスパスごとにバジェットを計算します。設定の検証後であっても、リアルタイムのノード負荷に基づく第2の制限を適用します。
4. バージョンの配布とアップデートの処理
各接続にポリシーバージョンをバインドし、新規接続には最新の公開バージョンを使用させます。既存の接続は、バッチ処理、自然な再接続時、または次のアイドルサイクル時に更新し、数百万のソケットを一度に更新しないようにします。各リリースを少数のテナントやノードに段階的に適用し、検出時間、偽陽性、CPU、帯域幅、接続チャーンを比較してから拡大します。
5. オブザーバビリティと障害分類の構築
ポリシーバージョン、送信プローブ数、応答率、連続失敗回数、最終切断理由、再接続成功率、テナントごとのリソース使用量を記録します。ピアの切断、パケットロス、ノード過負荷、ポリシー期限切れ、アプリケーションハートビートの失敗を区別します。keep-alive 応答がないこと単体では切断を証明できないため、アラートは反復プローブとアプリケーションの成果を組み合わせる必要があります。
6. ロールバックと過負荷保護の設計
直前の安定バージョンと緊急用グローバルポリシーを保持します。ロールアウトによって切断、プローブトラフィック、または CPU が閾値を超えて増加した場合は、公開を停止して旧バージョンを復元します。更新が失敗した場合は、検証済みスナップショットで処理を継続します。ポリシーの急増が接続マネージャーを圧迫しないよう、レート制限、テナントサーキットブレーカー、キューバックプレッシャーを追加します。
高品質な回答例
アイドル時間、プローブ間隔、最大プローブ数、接続スコープ、監査データを含む、バージョン管理されたコントロールプレーンサービスとして keep-alive ポリシーを実装します。プラットフォームは無効化された保守的なグローバルデフォルトを採用し、接続およびプローブバジェットによってテナント設定に上限を設けます。新規接続は署名付きスナップショットを読み取ってそのバージョンをバインドし、既存の接続はバッチ処理または自然な再接続を通じてのみ更新します。ロールアウトには承認、段階的メトリクス、自動ロールバックが必要であり、プローブレート、応答、切断要因、偽陽性、再接続、ノード負荷を追跡します。keep-alive はトランスポートの生存性をカバーし、アプリケーションハートビートがビジネスの健全性を確認します。プローブトラフィックや切断が予期せず増加した場合は、伝播を停止して安定バージョンを復元します。
よくある間違い
- ACK が届いたことだけで keep-alive をアプリケーションのヘルスチェックとして扱ってしまうこと。
- ノード、エグレス、グローバルのプローブバジェットを設けずにテナントによる間隔短縮を許可すること。
- ポリシー変更直後にすべての接続を走査し、同期的なチャーンを引き起こすこと。
- バージョン、署名、監査ログ、最後に確認された正常なスナップショット（last-known-good snapshot）を省略すること。
- パケットロス、ピア切断、過負荷、偽陽性を分類せず、切断数だけを見ること。
- 段階的ロールアウトやロールバック経路を設けずにグローバルに公開すること。
フォローアップの質問と回答
なぜプローブ間隔を数秒に設定してはいけないのですか？
頻繁なプローブはネットワーク、CPU、バッテリーリソースを消費し、混雑を増幅させる可能性があります。検出目標、接続数、リソースバジェットからパラメータを計算し、ビジネスセマンティクスが必要な場合はアプリケーションハートビートを優先してください。
テナントが即時変更を求めた場合、どう対応しますか？
新規接続には承認済みバージョンを即座に使用させ、既存の接続にはノードごとのレート制限を設けた制限付きバッチで更新します。緊急のセキュリティ変更には高い優先度を与えることができますが、それでも承認者、スコープ、予想されるチャーン、ロールバック条件が必要です。
コントロールプレーンがダウンした場合はどうなりますか？
データプレーンは期限内の署名済みスナップショットを制限された期間だけ使用し続けます。期限切れ後は空の設定ではなく、安全なグローバルデフォルトにフォールバックします。復旧後は、すべての接続を一度に更新することなくバージョンを調整（リコンサイル）します。
keep-alive の偽陽性をどのように検出しますか？
連続したプローブ失敗を、アプリケーションハートビート、再接続の結果、パスのメトリクスと比較します。1回の ACK 未達では不十分であり、設定された失敗回数と、それを裏付けるビジネスまたはアプリケーションシグナルを必要とします。
1つの大規模テナントがプローブバジェットを消費し尽くすのをどのように防ぎますか？
接続数とプローブレートに基づいて、テナント、ノード、ゾーン、グローバルの階層型クォータを使用します。クォータを超えた場合は、間隔を長くする、積極的な設定を拒否する、またはクォータのアップグレードを要求しつつ、他のテナントの最小サービスレベルを維持します。