バックエンド面接：ACME ARI はどのようにして証明書の更新ストームを防ぐのか？

設問とコンテキスト

あるプラットフォームチームが 100,000 件の証明書を運用しています。古いクライアントは固定の cron や有効期間の割合に基づいて更新を行うため、リクエストが特定の 1 時間に集中してしまいます。候補者は RFC 9773 の RenewalInfo、推奨ウィンドウ、およびリトライのセマンティクスを説明した上で、CA、クライアント、キャッシュ、アラート、およびフォールバックの挙動を設計する必要があります。優れた回答では、プロトコルのアドバイス、クライアントの決定、および最終的な証明書の設定が明確に区別されます。

面接官が見ているポイント

候補者が ARI を ACME の注文フローの代替ではなく、ACME の更新情報拡張機能として理解しているか。
suggestedWindow、Retry-After、およびランダムな選択を正確に説明できるか。
replaces が先行証明書、アカウント、競合する注文をどのように紐付けるかを理解しているか。
ARI 非対応のクライアント、クロックスキュー、キャッシュ、レート制限、および CA の障害を考慮しているか。
更新成功率、ウィンドウの分布、および残存有効期間を用いて設計の妥当性を証明できるか。

最初に確認すべき明確化のための質問

どの CA が証明書を発行しており、クライアントを ARI 対応バージョンにアップグレードできますか？
緊急の失効や一括置き換えに対して、ウィンドウはどれくらい迅速に反応する必要がありますか？
リトライ、失効保護、および手動対応への切り替えの目標値は何ですか？
CA は匿名 GET、CDN キャッシュ、および IP 制限を通じて RenewalInfo を公開できますか？
ARI 非対応のクライアントについて、cron スケジュールをシャーディングしたり、安定したジッターを付与したりできますか？

30秒で答える要約

「RFC 9773 により、ACME サーバーは RenewalInfo を介して推奨更新ウィンドウを提供できます。クライアントは suggestedWindow を読み取り、その中の均等なランダム時刻を選択し、Retry-After、指数バックオフ、および既存のリトライポリシーに従います。注文では replaces を使用して先行証明書を紐付けることで、サーバーが置き換えを追跡し、優先順位を付け、または重複を拒否できるようにします。私なら RenewalInfo をキャッシュ可能かつレート制限付きにし、リクエストの分散と有効期限のヘッドルームを監視し、ARI を実装していないクライアント向けにジッター付きのフォールバックスケジュールを維持します。」

ステップごとの詳細な回答

1. ARI が解決する問題を述べる

固定間隔、有効期限日からのオフセット、および有効期間の割合は、いずれもリクエストを集中させるため、CA が負荷を動的に分散することができません。ARI を使用すると、CA は負荷、予定されている失効、または証明書のライフサイクル変更に基づいて新しいウィンドウを提案できます。これはクライアントに代わって注文を作成するものではなく、ACME のアカウント、認可、または検証ステップをバイパスするものでもありません。

2. RenewalInfo リソースを取得する

ARI 対応のディレクトリは renewalInfo URL を通知します。クライアントは証明書の Authority Key Identifier keyIdentifier とシリアル番号からリソースパスを構築し、未認証の GET を送信します。レスポンスには RFC3339 タイムスタンプとオプションの説明リンクが含まれます。

http

GET /renewal-info/<aki>.<serial> HTTP/1.1
Host: acme.example.com
Accept: application/json

HTTP/1.1 200 OK
Retry-After: 21600
Content-Type: application/json

{
  "suggestedWindow": {
    "start": "2025-01-02T04:00:00Z",
    "end": "2025-01-03T04:00:00Z"
  },
  "explanationURL": "https://acme.example.com/docs/ari"
}

ARI において Retry-After は、次に再確認するまでの希望インターバルを表します。単に現在の HTTP リクエストに対する最小待機時間としてのみ解釈すべきではありません。

3. ランダム化された更新時刻を選択する

クライアントはウィンドウ内で均等に選択し、ウィンドウがすでに過去である場合は速やかに更新する必要があります。正確にスリープできない cron クライアントは、目標時刻と次の起動時刻を比較します。すべての試行は、引き続きアカウント制限、ネットワークバックオフ、および記録された注文失敗に従います。

4. リトライと無効なウィンドウを処理する

接続タイムアウト、リクエストタイムアウト、および 5xx レスポンスは一時的なエラーであり、上限付き指数バックオフを使用できます。Retry-After の欠落や無効、無効なウィンドウ、DNS 障害、および 5xx 以外のエラーは長期的なエラーです。クライアントはローカルのデフォルトインターバル後にリトライし、フォールバックスケジュールを使用する必要があります。開始日時以前の終了タイムスタンプは、有効な通常ウィンドウではありません。

5. replaces を使用して置き換えを維持する

明確な先行証明書が存在する場合、クライアントは新しい注文に replaces を含めます。サーバーは先行証明書のアカウントと識別子を確認し、別の有効な注文によってすでに置き換えられた証明書を拒否します。これにより、同時更新を独立した新規証明書として扱うことなく、緊急置き換えの追跡、優先度ポリシー、および失効後のクリーンアップがサポートされます。

6. サーバーおよび運用の保護を構築する

RenewalInfo は機密情報ではない匿名の GET リソースです。正規化されたキャッシュキー、CDN またはエッジキャッシュ、および IP レート制限を使用して、エンドポイントが DoS トラフィックを増幅させないようにします。サーバーはクライアント数に基づいて適切な Retry-After を選択し、ウィンドウの QPS、キャッシュヒット率、5xx レスポンス、更新成功率、有効期限のヘッドルーム、および ARI 非対応クライアントの割合を監視します。

質の高い回答例

「私なら設計を、CA のアドバイス、クライアントのスケジューリング、および注文の紐付けに分割します。RFC 9773 は renewalInfo を通知し、クライアントは証明書の AKI とシリアルでクエリを行い、suggestedWindow 内の均等なポイントを選択し、上限付き指数バックオフを維持しながら Retry-After を使用してチェック頻度を制御します。注文には replaces が含まれ、サーバーはアカウントと識別子を検証して重複する置き換えを防ぎます。RenewalInfo は匿名であるため、CDN キャッシュ、正規化されたキャッシュキー、およびレート制限で保護します。ウィンドウの分布、有効期限のヘッドルーム、およびフォールバッククライアントを監視します。ARI 非対応のクライアントはジッター付きのレガシースケジュールを維持し、CA の緊急イベントには手動による早期実行パスを確保します。」

よくある間違い

ARI を自動更新サービスとして扱う → アドバイスを提供するのみです → 注文の作成と完了は依然としてクライアントが行います。
Retry-After のセマンティクスを無視する → ポーリングによって新たなスパイクが発生する可能性があります → 適切な範囲でサーバーのインターバルに従います。
すべてのクライアントを全く同じ秒に更新させる → マイクロストームが残ります → 均等なランダムポイントを選択し、バックオフを維持します。
replaces を任意の証明書 ID として扱う → 別のアカウントにリンクされる可能性があります → アカウント、識別子、および置き換え状態を検証します。
発行の成功率のみを監視する → 有効期限のヘッドルームや ARI カバレッジが低下する可能性があります → 分布、フォールバックの割合、および残存有効期間を追跡します。

フォローアップの質問と回答

なぜ RenewalInfo は匿名の GET でよいのですか？

推奨される時間枠を伝えるだけであり、機密情報とはみなされないためです。また、匿名 GET にすることでキャッシュが可能になり、クライアントと CA の負荷を軽減できます。ただし、サーバー側では正規化されたキャッシュキー、レート制限、および DoS 対策が依然として必要です。

ARI ウィンドウがすでに過去である場合はどうしますか？

エラーバックオフとアカウント制限に従いつつ、速やかに更新します。サーバーがウィンドウを過去の日時に設定している場合、通常は緊急の置き換えを示しているため、クライアントは通常の次回サイクルまで待つべきではありません。

ARI 非対応のクライアントをスムーズに移行するにはどうすればよいですか？

まず固定スケジュールに安定したジッターとシャーディングを追加し、次にクライアントのバージョンごとに ARI を有効化します。フォールバックの割合、更新失敗、および有効期限のヘッドルームを監視します。カバレッジが不十分な場合、CA はトラフィック全体が分散されていると見なすことはできません。

100,000 件の証明書をどのようにテストしますか？

同じ有効期限を持つ擬似証明書を使用して、RenewalInfo、キャッシュ、および注文の負荷テストを行います。ARI の導入前後で、分あたりの分布、ピーク値、更新レイテンシの P95、リトライ数、および有効期限のヘッドルームを比較します。5xx エラー、無効なウィンドウ、クロックスキュー、および CA の制限を注入し、クライアントのリトライが同期しないことを検証します。