プロンプトとコンテキスト
複数のリアルタイムコンシューマー向けにユーザーイベントを取り込むデータプラットフォームを担当しています。トラフィックは1日の大半で安定していますが、キャンペーン期間中にスパイクが発生します。ビジネス上、持続的なスロットリングは許容できませんが、トラフィックが落ち込む時間帯のために容量を前払いしたくはありません。プロデューサーのスループット、読み取りレイテンシー、スロットリング、コンシューマーの遅延（lag）を取得でき、メンテナンスウィンドウ中に容量モードを切り替えられるものとします。
面接官が評価するポイント
面接官は、容量モードの変更が配信セマンティクスではなく、運用責任とコストの変更であることを理解しているかをテストしています。優れた回答では、過去のピークとバーストの形状を用いて自動スケーリングが価値をもたらすかを判断し、シャードごとの制限、コンシューマー数、リトライ、遅延復旧を確認します。不十分な回答では、トラフィックが変動するなら常にオンデマンドを選択すべきだと単純に述べるだけにとどまります。
最初に確認すべき明確化のための質問
- ピークはどのくらい続き、予測可能ですか？ 短く予測不可能なスパイクは、自動容量管理が有利です。
- 書き込みと読み取りは同時に制約を受けますか？ バイト数、レコード数、読み取り、コンシューマーの挙動を個別に測定します。
- 厳格なコスト上限や容量予算はありますか？ 予算が厳しい安定したトラフィックは、プロビジョンドモードの方が最適化しやすいです。
- コンシューマーはスループットを共有しますか、それとも専用の読み取りが必要ですか？ 複数のコンシューマーが存在すると、読み取りクォータとコストが変わります。
- チームは短時間の状態遷移を許容できますか？ モードの切り替えやバースト時のリトライには、明示的なランブックが必要です。
30秒の回答フレームワーク
「時間あたりの書き込み MB/s、レコードレート、読み取り MB/s、遅延、スロットリングを測定し、予測可能なピークとバーストを区別します。安定して予測可能なトラフィックにはスケーリングスケジュールを備えたプロビジョンド容量を使用できます。急激または予測不可能な変化にはオンデマンドが適していますが、ランプアップ、クォータ、コストを検証します。どちらの選択肢も、スロットリング、遅延復旧、エンドツーエンドのレイテンシー、月額費用のガードレールをクリアする必要があります。」
ステップバイステップの詳細な回答
- 容量のベースラインを構築する。 書き込みと読み取りを分単位で集計し、P50、P95、P99、ピーク持続時間、ホットパーティションキーを記録します。平均値はバーストを覆い隠してしまいます。
- スループット制限を確認する。 AWS のドキュメントでは、書き込みに対してデフォルトでシャードあたり 1 MB/s または 1,000 レコード/秒、読み取りに対して 2 MB/s の制限が規定されています。レコードサイズとバッチ処理をバイト数とレコード数の両方に換算します。
- モードを選択する。 安定した負荷にはスケーリング計画を伴うプロビジョンド容量を使用します。負荷が急激に変化する場合や予測が難しい場合はオンデマンドを優先し、自動調整のレイテンシーを記録します。
- コンシューマーをモデリングする。 共有読み取り、enhanced fan-out、リトライ、重複処理は読み取りクォータに影響します。コンシューマーの遅延は、プロデューサーのメトリクスだけでなく、容量計画に含める必要があります。
- コストをモデリングする。 プロビジョンドモードの場合、シャード時間とスケーリングのヘッドルームを含めます。オンデマンドの場合、実際のスループットとピーク時の課金に加え、リプレイやバースト時の二重書き込みを含めます。
- パイロット運用とロールバックを実施する。 非クリティカルなストリームを1つ切り替え、スロットリング、遅延復旧、P99 レイテンシー、月額費用を監視します。ガードレールに違反した場合は、順序性とリトライ動作を維持しながら検証済みのモードに戻します。
代替案としては、ホットパーティションキーの分割、書き込みのバッチ化、イベントサイズの縮小、Firehose によるバッファリング、予測可能なキャンペーンに対する事前スケーリングなどがあります。容量モードを変更しても、キーの偏り、低速なコンシューマー、無限リトライを解決することはできません。
模範回答
「分単位の書き込み・読み取り曲線を30日分調査し、P95/P99、ピーク持続時間、パーティションキーの偏りを算出します。レコードサイズを AWS のシャード制限に基づいて書き込み MB/s とレコードレートに変換し、共有コンシューマーのスループットと遅延復旧を確認します。数時間続く予測可能なピークに対しては、プロビジョンド容量を使用し、キャンペーン前に事前スケーリングを行います。短く予測不可能なピークに対しては、スロットリング 0.1% 未満、遅延復旧 p99 が 5 分未満、エンドツーエンドのレイテンシーがベースラインの 20% 以内、および月額コスト上限を条件として、非クリティカルなストリームでオンデマンドをパイロット運用します。両方のモードでホットパーティションと重複を監視します。容量モードの変更によって根本原因が覆い隠されてはなりません。」
よくある間違い
- 間違い: 平均スループットから見積もる → 失敗の理由: バーストやホットキーによって局所的なスロットリングが発生する → 対策: P95/P99、ピーク持続時間、キーの分散状況を使用する。
- 間違い: オンデマンドを無制限のスループットとして扱う → 失敗の理由: サービスクォータとランプアップが依然として影響する → 対策: ランプ動作、クォータ、バーストテストを検証する。
- 間違い: プロデューサーのコストのみを計算する → 失敗の理由: コンシューマー、リトライ、リプレイがスループットを増幅させる → 対策: エンドツーエンドのコストシナリオを構築する。
- 間違い: 配信セマンティクスを無視する → 失敗の理由: 容量モードは少なくとも1回の配信（at-least-once）や重複処理のリスクを排除しない → 対策: 冪等性、チェックポイント、遅延復旧を維持する。
フォローアップの質問と回答
オンデマンドでもスロットリングが発生します。最初に何を調整しますか？
全体的なスループット不足、ホットパーティションキー、遅延しているコンシューマーを切り分けます。バックオフ、再パーティショニング、またはコンシューマーの追加を選択する前に、レコードレート、キー分散、スケーリングイベントを確認します。
プロビジョンド容量の方が安くなるのはどのような場合ですか？
書き込みと読み取りが安定しており、ピークをスケジュールでき、使用率が高く維持される場合です。シャード時間とスケーリングのヘッドルームをモデリングしてください。単価のみを比較してはいけません。
キャンペーンのトラフィックが10倍に増加した場合はどうしますか？
まずオンデマンドのクォータと過去のランプ動作を確認します。予測可能なキャンペーンは事前にスケールさせ、プロデューサーのバックオフと遅延アラートを追加し、非クリティカルなイベントに対する縮退動作を定義します。
選択が正しいことをどのように証明しますか？
パイロット運用の前後で、同じ定義を用いてスロットリング、遅延復旧 p99、エンドツーエンドのレイテンシー、重複率、月額コストを比較します。2つのビジネスサイクルでガードレールを満たした後に適用範囲を拡大します。