問題と適用シナリオ
複数のエンジニアリングチームが共有するメトリクス監視およびアラートシステムを設計します。このシステムは50,000のサービスインスタンスを監視し、各インスタンスは200のアクティブな時系列を公開しており、15秒ごとに収集を行います。カウンター、ゲージ、ヒストグラム、ラベルによるフィルタリングと集約、ダッシュボード、およびルールベースのアラートをサポートします。新しい障害は、p99で60秒以内に通知ルーティングに入る必要があります。直近6時間の一般的なダッシュボードクエリは、p95で2秒以内に完了する必要があります。未加工のサンプルは7日間、1分間のロールアップは90日間、1時間のロールアップは13か月間保持されます。
3つのアベイラビリティゾーンを持つ1つのリージョンと、テナントIDのソースとして信頼できる認証を想定します。既存のメール、チャット、電話プロバイダーが通知を配信する場合があります。本設計では、これらを確実に生成、重複排除、グループ化、ルーティングする必要があります。ログとトレースは主な対象外です。面接では、高カーディナリティのラベル、重複および遅延サンプル、欠落データ、アラート状態、クエリの分離、監視プラットフォーム自体の障害検知に焦点を当てる必要があります。
2026年現在の英語および中国語の資料では、メトリクス監視とアラートは、時系列インジェスチョン、クエリ、アラート、高可用性を含む代表的なシステムデザイン面接の問題として提示されています。Prometheusのドキュメントは、時系列の同一性、プル型収集、WAL、保留中（pending）および発火中（firing）のアラート、グループ化、抑制（inhibition）に関する主要なセマンティクスを提供しています。Google SREは、ノイズの少ないアラートとブラックボックス監視の原則を提供しています。したがって、この設問は現在において代表的であり、技術的にも検証可能です。
面接官が評価しているポイント
第1に、候補者がサンプルのスループットとアクティブな時系列のカーディナリティを区別できるかどうかです。インスタンス数、インスタンスごとの時系列数、および収集間隔によって書き込みが決まります。メモリ、インデックス、およびクエリのファンアウトは、カーディナリティが原因で最初に破綻する可能性があります。ラベルに user_id や request_id を追加すると、トラフィックを増やすことなく時系列が何桁も増加する可能性があります。
第2に、耐久性のあるインジェスチョン、ダッシュボードクエリ、障害検知が完全なパスを形成しているかどうかです。コレクターがサンプルを受信したからといって、そのサンプルが永続化されたことを意味するわけではありません。アラートのルールは、負荷の高いアドホッククエリによって枯渇する可能性のある共有プールに依存すべきではありません。優れた回答では、確認応答の境界（acknowledgement boundary）を定義し、アラート用のキャパシティを確保し、遅延、重複、欠落、および部分的な結果のセマンティクスを指定します。
第3に、ストレージがアクセスパターンと一致しているかどうかです。最近のデータは頻繁に追加され、頻繁にクエリされます。履歴データは、イミュータブルなブロック、圧縮、インデックス、およびオブジェクトストレージに適しています。ダウンサンプリングでは、平均値の平均を計算することはできません。少なくとも sum、count、min、および max を保持する必要があります。ヒストグラムをマージするには、互換性のあるバケット境界が必要です。
最後に、アラートシステムはインシデント時にも耐えられなければなりません。インシデントが発生すると、エラーメトリクス、クエリ、通知が同時に急増することがあります。候補者は、ルールのシャーディング、状態の復元、通知の重複排除、アラートストーム、ノイズの多いテナントへの対処、自己監視、およびプラットフォームの障害ドメイン外にあるエンドツーエンドの生存プローブ（liveness probe）を網羅する必要があります。
回答前の明確化のための質問
- 収集対象は安定していますか？ ほとんどはプラットフォームによって検出される長期実行サービスです。存続期間の短いジョブや制限されたネットワークではプッシュゲートウェイを使用します。
- 提示された規模はグローバルですか、それともリージョンですか？ リージョンのピークとして扱います。追加のリージョンは個別に収集し、制御されたグローバルクエリを公開します。
- 確認応答の境界（ack boundary）は何ですか？ 書き込みゲートウェイは、サンプルがアベイラビリティゾーン間でレプリケートされた永続ログに入った後にのみ成功を返します。
- 重複や順序不同のサンプルは許可されますか？ ネットワークの再試行によってデータが重複する可能性があり、サンプルは一定の遅延ウィンドウ内で到着する可能性があります。同一の時系列とタイムスタンプには、決定論的な競合ルールを使用します。
- サンプルの欠落はゼロを意味しますか？ いいえ。測定されたゼロとは異なり、ターゲットの停止、収集の失敗、またはネットワーク分断を示している可能性があります。
- すべてのクエリが2秒以内に完了する必要がありますか？ いいえ。SLOは制限された一般的な6時間のクエリを対象としています。高カーディナリティや1か月にわたる生データスキャンにはクォータが設定されるか、非同期分析が使用されます。
- アラートのリカバリはどのように判断されますか？ ルールによって評価間隔、保持期間、データ欠落ポリシー、および復旧条件が定義されます。通知サービスがこれらを推測することはありません。
- テナントは任意のラベルを作成できますか？ クォータの範囲内で、ラベル数、長さ、アクティブな時系列数、および新しい時系列の作成レートの制限に従います。
- exactly-once（正確に1回）の通知が必要ですか？ いいえ。配信は at-least-once（少なくとも1回）であり、アラートのフィンガープリントと状態遷移に基づくべき等性を備えます。
- 生データとロールアップデータはどのように関連していますか？ ロールアップは、元のブロックが保持されている間は再計算が可能であり、その解像度とカバレッジのウォーターマークが記録されます。
30秒の回答フレームワーク
「規模は1,000万のアクティブな時系列で、毎秒約667,000サンプル、1日あたり576億サンプルになります。シャード化されたコレクターがサービスディスカバリからターゲットを取得し、存続期間の短いジョブはプッシュゲートウェイを使用します。正規化されたサンプルは、テナントおよび時系列フィンガープリントごとにゾーン間の永続ログに入り、その後、直近データ層とイミュータブルなタイムブロックに入ります。ラベルインデックスがクエリを処理し、カーディナリティバジェットによって user_id などの危険なラベルを抑制します。個別にプロビジョニングされたルールエンジンが固定タイムスタンプを評価し、inactive、pending、firing の状態を保持します。アラートマネージャーは、アラートの重複排除、グループ化、サイレント化、抑制、およびルーティングを行います。10倍の新規時系列サージ、重複および遅延サンプル、ゾーン障害、および外部カナリアを使用してこのパスを検証します。」
ステップごとの詳細解説
6つの不変条件から始めます。サンプルのラベルでテナントIDを宣言することはできない、確認応答されたサンプルは永続ログに入っている、1回の再試行で異なる結果が生成されることはない、欠落したデータが警告なしにゼロに変更されることはない、ダッシュボードの負荷がアラートのリソースを枯渇させることはない、そしてすべての拒否、破棄、遅延、および劣化には観測可能なカウントが存在する、という点です。
ステップ1：規模を再計算し、カーディナリティを最重要リソースとして扱う。
アクティブな時系列の計算は次のとおりです。
50,000 instances × 200 series/instance = 10,000,000 active series
10,000,000 ÷ 15 seconds ≈ 666,667 samples/second
666,667 × 86,400 ≈ 57.6 billion samples/dayPrometheusのストレージドキュメントでは、ローカルストレージの大まかな目安としてサンプルあたり1〜2バイトが示されています。そのレートでは、圧縮されたサンプルチャンクは1日あたり約57.6〜115.2 GB、3コピーの場合は1日あたり172.8〜345.6 GBを占有します。この見積もりには、ラベルインデックス、WAL、ヘッド、オブジェクトメタデータ、レプリカを超える安全マージン、および観測された分布の影響は含まれていません。これは目安（サニティチェック）であり、代表的なメトリクスを用いたベンチマークの代わりにはなりません。
新規の時系列はさらに危険です。リクエストレベルの user_id がラベルセットに入ると、値ごとに時系列の同一性が変わります。プラットフォームは、テナントおよびメトリクスごとに、アクティブな時系列、新規時系列の作成レート、ラベル数、ラベルの長さ、および許可されたキーを制限し、明示的な警告、隔離、および拒否のポリシーを設定する必要があります。
ステップ2：デフォルトでプル型収集を使用し、必要な場所でプッシュを使用する。
サービスディスカバリがターゲットセットを提供します。コントロールプレーンは、コンシステントハッシュまたはランデブーハッシュを使用してターゲットをコレクターに割り当てます。15秒ごとにコレクターがHTTP経由でプルし、信頼できるテナント、クラスター、ジョブ、およびインスタンスのフィールドを付加し、up、スクレイプ時間、サンプル数、エラーなどの収集メトリクスを生成します。プル型を採用することで、「ターゲットは存在したが収集に失敗した」という状態が直接可視化され、プラットフォーム側でペースを制御できるようになります。
存続期間の短いバッチジョブ、インバウンドアクセスのないネットワーク、およびすでにOTLPを出力している環境では、リージョンゲートウェイを使用します。ゲートウェイはIDを認証し、バッチサイズを制限し、フィールドを正規化して、同じインジェスチョン契約に入ります。クライアントの送信成功は、最終的なストレージの保存成功ではありません。ゲートウェイの成功は、プラットフォームがその永続境界に到達したことを意味します。コレクターは切断中に制限付きのローカルスプールを使用し、ディスクを無制限に埋めるのではなく、容量が枯渇した場合はカウンターとともに拒否します。
ステップ3：時系列の同一性とインジェスチョン契約を定義する。
時系列は tenant_id + metric_name + canonical_labels によって一意に識別されます。ラベルはハッシュ化される前にソートされ、正規化（canonical）エンコードされます。フィンガープリントが衝突した場合は完全な同一性を比較する必要があり、ハッシュだけでは不十分です。サンプルには、時系列ID、ソース時刻、観測時刻、値またはヒストグラム、データ型、および収集ソースが含まれます。
WriteBatch {
tenantId, sourceId, requestId,
samples: [{ metric, labels, sourceTimestamp, value }]
}ゲートウェイは、認証、ラベルの正規化、型検証、カーディナリティのバジェット確認、時間範囲のチェック、およびバッチ制限を実行します。次に、tenant_id + series_fingerprint によってゾーン間レプリケートログにパーティショニングします。ログへのコミットが確認応答（ack）の境界となります。同じ requestId は安全に再試行でき、ストレージは (series_id, source_timestamp) によって重複を排除します。同じ時系列およびタイムスタンプで異なる値が存在する場合は、固定の競合ポリシーに従い、競合メトリクスをインクリメントします。到着順序によって暗黙的に決定されてはなりません。
ステップ4：最近のデータ、履歴ブロック、およびインデックスを分離する。
追加可能なヘッド（head）が直近数時間のデータを保持し、遅延データに対する制限付きの変更を許可します。バックグラウンドワーカーがこれをイミュータブルな時間およびシャードでパーティショニングされたブロックへと凍結し、タイムスタンプデルタと値の圧縮を使用して、オブジェクトストレージにアップロードします。ブロックメタデータには、最小時間と最大時間、テナント、解像度、チェックサム、およびカバレッジウォーターマークが含まれます。コンパクションによって小さなブロックがマージされ、検証済みの代替ブロックによって完全にカバーされているブロックのみが削除されます。
転置インデックスは、ラベルのキー/値のペアを時系列IDにマップし、これによってデータブロックを特定します。ホットなラベルと時系列メタデータはキャッシュされる場合がありますが、テナントIDはすべてのキャッシュキーの一部となります。ダウンサンプリングにより、sum/count/min/max を持つ1分および1時間のブロックが作成されます。カウンターにはリセット処理が必要であり、ヒストグラムは互換性のあるバケットスキーマでのみマージされます。生データブロックは7日間、1分ブロックは90日間、1時間ブロックは13か月間保持されます。
ステップ5：クエリコストを予測可能にする。
クエリコーディネーターは、時間範囲、ラベルセレクター、集約、およびステップをパースします。最初に認証を行い、インデックスを使用して時系列を検索し、関連するブロックを並行して読み取ります。ロールアップは、要求されたステップと関数で許可されている場合にのみ選択されます。平均値は sum/count から再計算されます。既存のパーセンタイルを別の正しいパーセンタイルにロールアップすることはできません。最近のクエリは、ヘッドと永続化されたブロックをマージし、共有ウォーターマークで重複を排除します。
各クエリには、時系列数、スキャンされるポイント数、同時実行数、メモリ、および制限時間の制限があります。一般的なダッシュボードでは、直近6時間にわたってp95で2秒を達成するために、固定ステップ、事前集約、および短い結果キャッシングを使用します。1か月にわたる高カーディナリティの探索は、非同期ジョブになる場合があります。シャードに障害が発生した場合、APIは partial=true と欠落している範囲を返します。アラートルールはデフォルトで部分的な結果を拒否します。
QueryRange {
tenantId, expression, start, end, step, maxSeries
}
QueryResult { data, resolution, watermark, partial, warnings }ステップ6：ルール評価と通知ルーティングを分離する。
スケジューラーはテナントごとにルールグループをシャーディングし、明示的な評価タイムスタンプで15秒または30秒ごとに評価します。アラートインスタンスは、ルールと結果ラベルから派生した安定したフィンガープリントを持ち、inactive -> pending -> firing を遷移します。for の期間によって一時的なスパイクをフィルタリングします。keep_firing_for または明示的なヒステリシスにより、短時間のデータ欠落による繰り返しの解決（resolution）を防止します。また、すべてのルールは、データ欠落が正常か、アラート対象か、または不明かを宣言します。
高可用性構成の2つの評価エンジンが同じフィンガープリントをアラートマネージャーに送信することがあり、アラートマネージャーがそれを重複排除します。アラートマネージャーは、チーム、サービス、重要度ごとにルーティングし、1つのインシデントからのインスタンスをグループ化し、クラスターが到達不能な場合はダウンストリームのインスタンスアラートを抑制し、メンテナンス中は期限付きのサイレント設定を適用します。通知の状態はレプリケートされたストレージに保持されます。配信は at-least-once であり、べき等性キーとして alert_fingerprint + state_transition + receiver を使用します。ルール計算、状態、および通知キューは、アドホックなダッシュボードクエリから分離されたキャパシティを使用します。
ステップ7：障害、テナント分離、および自己監視を処理する。
コレクターが停止すると、ターゲットのリースは正常なインスタンスに移動します。短時間の重複収集は重複排除によって吸収されます。ログまたはストレージがバックプレッシャーをかけると、ゲートウェイは無制限のメモリキューを構築する代わりに、バッチを減らして明示的に拒否します。オブジェクトストレージの停止中も、レプリケートログと制限付きヘッドはデータの受け入れを継続し、ブロックの削除は停止します。安全なウォーターマークを超えた場合、テナントクォータによってアラートに不可欠なメトリクスが保護されます。クエリの障害によって、ルールが確認済みウォーターマークを読み取れなくなることがあってはなりません。
テナントIDはmTLSまたはサーバーが発行したトークンから取得され、サンプルの tenant ラベルから取得されることは決してありません。インジェスチョン、クエリ、ルールに対して個別の制限が適用されます。RBACがダッシュボードとアラート設定を制御し、ルール、サイレント設定、ルートへの変更は監査されます。プラットフォームは、インジェスチョンレイテンシ、ログのバックログ、ヘッドのウォーターマーク、ブロックの経過時間、スキャンされたクエリポイント、ルール評価の遅延、保留中および発火中のカウント、通知の失敗を監視します。
自己監視はプラットフォームの障害ドメインを共有するため、外部のブラックボックスカナリアが独立した環境から既知のメトリクスを継続的に書き込み、そのルールが発火して通知が届くのを待ってから解決します。期待されるハートビートが停止した場合、外部のデッドマンズチェック（dead-man check）が独立した通知パスを使用します。これにより、監視プラットフォームが完全に沈黙している状態を検出します。
ステップ8：負荷試験と障害挿入により保証内容を検証する。
定常状態の負荷は少なくとも毎秒667,000サンプルに達する必要があり、その後に2倍のバーストが続きます。次に、10倍の新規時系列レートを生成し、違反したテナントが分離され、他のテナントとルール評価が引き続きSLOを満たしていることを確認します。正確性テストでは、重複バッチ、同一タイムスタンプでの競合値、遅延ウィンドウ、カウンターリセット、ヒストグラムのマージ、ロールアップの再計算、およびブロックのコンパクション前後での同一結果をカバーします。
障害テストでは、コレクター、1つのゾーンのログレプリカ、ヘッドノード、クエリシャード、ルール評価エンジン、および通知プロバイダーを強制終了します。確認応答されたサンプルが残り、リースの重複が重複排除され、ルール状態が復元され、通知の再試行が無制限に増大しないことを検証します。最後に、インジェスチョン、ルール保持期間、グループ待機、および配信にわたるカナリアレイテンシを測定します。p99で60秒を確認するか、バジェットを消費したステージを特定します。
優れた回答例
「まず、50,000インスタンスに200系列を掛けて、1,000万のアクティブな時系列を算出します。15秒で割ると、毎秒約667,000サンプル、1日あたり576億サンプルになります。キャパシティ計画には、サンプルチャンクとラベルインデックスの両方を含める必要があります。アクティブな時系列および新規時系列レートのバジェットにより、user_id などのラベルがプラットフォームを枯渇させるのを防ぎます。
メインパスでは、サービスディスカバリとシャード化されたプル型コレクターを使用し、短時間のジョブにはプッシュゲートウェイを使用します。認証、ラベルの正規化、およびクォータチェックの後、サンプルはテナントおよび時系列フィンガープリントごとにゾーン間レプリケートログに入ります。コミットされたログ書き込みのみが確認応答されます。最近のデータはヘッドに入り、その後、イミュータブルな圧縮ブロックとオブジェクトストレージ内のラベル転置インデックスに凍結されます。バックグラウンドジョブが1分および1時間のロールアップを生成し、平均値は sum/count から再構築されます。
クエリコーディネーターは、時系列、ポイント数、メモリ、および期限のバジェットを設定し、時間、ラベル、解像度によってブロックをプルーニングします。個別にプロビジョニングされたルールエンジンが固定タイムスタンプを評価し、inactive、pending、firing の状態を保持します。アラートマネージャーはフィンガープリントによって重複排除を行い、グループ化、抑制、サイレント化、およびルーティングを行います。欠落データは明示的なルールポリシーに従い、通知には at-least-once 配信を使用します。
毎秒667,000サンプル、2倍のバースト、および10倍の新規時系列サージで負荷テストを行います。次に、重複および遅延サンプル、ゾーン障害、クエリシャードの障害、および通知プロバイダーの障害を挿入します。独立した環境のカナリアが、インジェスチョンから通知までを継続的に実行して、60秒のp99を検証し、プラットフォームの完全な沈黙を検出します。」
よくある間違い
- サンプルの毎秒レートのみを計算する → ラベルインデックスとアクティブな時系列が先にメモリを枯渇させる可能性がある → 1,000万のアクティブ時系列と新規時系列レートもバジェットに含める。
- 任意の
user_idラベルを許可する → 値ごとに別の時系列が作成される → ラベルポリシー、カーディナリティバジェット、および隔離を適用する。 - リクエスト受信時に確認応答を返す → プロセスまたはゾーンの障害によって確認済みのデータが失われる可能性がある → レプリケートログのコミット後にのみackを返す。
- 欠落をゼロとして扱う → 収集の失敗がビジネス上のゼロへの低下に見えてしまう → 古い状態（stale）または不明な状態（unknown）を保持し、ルール側でポリシーを選択できるようにする。
- 平均値の平均を取る → カウントが異なるバケットでは偏った結果が生成される →
sum/countを保持して再計算する。 - すべてのクエリが2秒以内に終わると約束する → 無制限のラベルと時間範囲は無制限のコストを持つ → SLOの範囲を限定し、クエリバジェットと非同期パスを強制する。
- アラートルールが部分的な結果を受け入れることを許可する → 1つのシャードの欠落が復旧のように見える場合がある → 完全なウォーターマークを要求するか、unknown 状態に遷移させる。
- インスタンスごとに通知する → 大規模な障害によってアラートストームが発生する → インシデントをグループ化し、抑制、サイレント設定、レート制限を使用する。
- exactly-once の通知を主張する → タイムアウトでは配信が成功したかどうかを証明できない → 安定したべき等性キーを備えた at-least-once 配信を使用する。
- プラットフォーム自身の仕組みでのみプラットフォームを監視する → 全面的な停止時にシグナルが生成されない → 独立したブラックボックスカナリアとデッドマンズパスを追加する。
フォローアップの質問と回答
フォローアップ1：なぜすべてのクライアントから直接プッシュさせないのですか？
長期実行サービスはプル型収集に適しています。プラットフォームがターゲットセットと頻度を把握し、測定された値と収集の失敗を区別でき、信頼できるリソースラベルを一貫して付加できるためです。存続期間の短いジョブ、制限されたネットワーク、および既存のOTLPクライアントにはプッシュ型が適しています。両方のエントランスは最終的に同じ検証および永続インジェスチョン契約を使用するため、2つの異なるクエリセマンティクスが発生するのを防ぎます。
フォローアップ2：正当なワークロードをブロックせずにカーディナリティを制御するにはどうすればよいですか？
ストック（蓄積量）とフロー（流入量）の両方を測定します。テナントおよびメトリクスごとのアクティブな時系列を制限し、1分あたりの新規時系列を制限します。ロールアウト前にカーディナリティのプレビュー機能を提供します。しきい値に近づいたら警告を発し、設定された危険なラベルを削除するか、メトリクスを隔離するか、テナントのポリシーに従って新規時系列を拒否します。破棄数と代表的な診断情報を保持しますが、機密性の高い未加工ラベルを通常のログにコピーしてはいけません。
フォローアップ3：遅延サンプルはアラートにどのように影響しますか？
ルールは固定の評価タイムスタンプで確認済みウォーターマークを読み取り、通常の遅延に対応するためにわずかな遅延時間を設ける場合があります。そのウォーターマークの後に到着した古いサンプルは履歴クエリを更新できますが、デフォルトで人間への通知を取り消すべきではありません。プロダクトで修正が必要な場合は、バージョニングされた修正イベントを発行します。遅延ウィンドウ、最大クロックスキュー、および競合ルールを文書化し、テストする必要があります。
フォローアップ4：なぜパーセンタイルを直接保存しないのですか？
複数のインスタンスや時間バケットからのp95値を平均化したり、別のp95操作に通したりしても、グローバルのp95を取得することはできません。マージ可能なヒストグラムバケットまたはスケッチを保存し、クエリ時に分布をマージしてからパーセンタイルを計算します。互換性のないバケット境界やスケッチパラメータには、個別の結果または明示的な移行が必要です。
フォローアップ5：高可用性のルールエンジンはどのようにして重複通知を回避しますか？
両方の評価エンジンが同じアラートインスタンスを計算して送信する可能性があります。インスタンスのフィンガープリントは、ルールおよび結果ラベル全体で安定しています。アラートマネージャーは、レプリケートされた状態を使用して、フィンガープリント、状態、および受信者ごとに重複排除、グループ化、およびルーティングを行います。評価処理をシングルトンにする必要はありません。ネットワーク分断によって稀に重複が発生することがあるため、受信者側でも同じべき等性キーを保持します。
フォローアップ6：オブジェクトストレージが利用できなくなると何が起こりますか？
レプリケートログと制限付きヘッドへの新規サンプルの書き込みを継続します。ブロックのアップロード、コンパクションによる削除、および安全なウォーターマークを超えた受け入れを一時停止します。テナントクォータによってアラートに不可欠なメトリクスを保護します。ログの保持期間内に復旧できない場合は、新しい書き込みを明示的に拒否してオペレーターに通知します。すべてのデータが受け入れられ続けていると偽ってはいけません。
フォローアップ7：グローバルなマルチリージョンクエリはどのように機能しますか？
広域ネットワークの分断によってローカルのアラートがサイレント化されないよう、各リージョンが独立して収集とアラートを行います。グローバルコーディネーターは、公開されたイミュータブルブロックまたは制御されたクエリパスターミナルを読み取り、各リージョンのウォーターマークと partial の状態を返します。真にグローバルなアラートメトリクスの少数のセットは、まずリージョン単位で集約され、その後、低カーディナリティの結果として別のルール環境にレプリケートされます。
フォローアップ8：60秒のアラート目標を破ったステージをどのように特定しますか？
カナリアサンプルの場合、ソース時刻、観測時刻、ログコミットウォーターマーク、ルール評価時刻、pending期間、グループ化待機、および通知受信を記録します。エンドツーエンドのヒストグラムをステージごとに分解し、最終的な到着を外部から検証します。ルールの5分間の for 節はプロダクト上の条件であり、プラットフォームの検出レイテンシではないため、プラットフォームの処理時間と設定された保持期間を分けてレポートします。