問題とスコープ
S3 Metadata tablesは、汎用バケットに対して表形式のオブジェクトメタデータを提供します。ジャーナルテーブルはオブジェクトとメタデータの変更を記録し、ライブインベントリテーブルは既存オブジェクトのスナップショットをバックフィルします。この質問は、イベントとスナップショットの組み合わせ、レイテンシと一貫性、アクセス制御、コスト、リカバリをテストするものであり、そのカテゴリは system-design です。すべてのS3リクエストに対する強力な一貫性を持つ外部インデックスではありません。
面接官がテストしていること
ジャーナルとインベントリの役割、初回バックフィルの影響、削除およびライフサイクルイベント、Icebergテーブルのクエリ、遅延・重複・欠損の処理について説明すること。テーブルバケットのIAM、クロスアカウントアクセス、機密メタデータ、パーティショニングとスキャンコスト、保持期間、再構築手順を網羅します。
明確化のための質問
- クエリには現在の状態、変更履歴、またはその両方が必要ですか？
- どの程度のディスカバリ遅延が許容され、削除やライフサイクルの移行はリアルタイムである必要がありますか？
- オブジェクト数、日次変更量、クエリのディメンション、保持期間はどのくらいですか？
- テナント、暗号化、タグ、カスタムフィールドを含め、誰がメタデータを読み取ることができますか？
- クロスアカウントまたはクロスリージョンでの利用が必要ですか、それとも単一のAWSアカウントのみですか？
- テーブル構成が削除された場合やバックフィルが失敗した場合の目標復旧時間（RTO）はどのくらいですか？
30秒の回答フレームワーク
「インベントリを使用して現在のオブジェクトのベースラインを確立し、ジャーナルを使用してその後の変更を追跡します。クエリコントラクトではスナップショットと履歴の保証を明示します。バックフィル中は未完了ステータスを公開し、イベント時刻とオブジェクトバージョンによってコンシューマーの重複を排除し、遅延や欠損についてアラートを発報します。テーブルバケットのリソースポリシーで読み取りを制限し、一般的なクエリをプルーニングし、ストレージ、スキャン、オブジェクトごとのコストをモデル化します。構成が失われた場合は、ソースS3と監査エクスポートを保持し、バージョン管理された構成から再構築して、ベースラインを調整（リコンサイル）します。」
ステップごとの回答
ステップ 1: データプロダクトの境界を定義する
「現在のカタログ」と「変更ログ」を個別のクエリコントラクトにします。カタログは暗号化されていないオブジェクトや期限切れ間近のオブジェクトを検出し、ジャーナルはガバナンスと監査のワークフローをトリガーします。ダウンストリームシステムは、イベントテーブルを欠損のない現在の状態のテーブルとして扱うべきではありません。
ステップ 2: バックフィルと切り替え（カットオーバー）を設計する
構成を作成し、完全なカバレッジを主張するクエリを公開する前に、インベントリのバックフィルを観察します。バックフィル中は、未スキャンのオブジェクトが存在しないと誤認されないよう、オブジェクトをカバー済み、保留中、または再試行用失敗に分類します。ベースラインの準備が整った後にのみ、ジャーナルを増分ソースとして接続します。
ステップ 3: スナップショットとイベントをマージする
オブジェクトキー、イベント時刻、イベントタイプを使用して、処理を冪等にします。削除、上書き、ライフサイクルの変更に関する監査レコードを保持します。コンシューマーはジャーナルを再生し、定期的にインベントリと調整して、インデックスを盲目的にリセットするのではなくギャップを修復する必要があります。
ステップ 4: アクセスと機密フィールドを保護する
テーブルバケットとテーブルに対するIAMリソースポリシーを使用して、プリンシパル、プレフィックス、および操作を制限します。データクラスごとにテナント、タグ、暗号化フィールドを承認し、必要なカラムのみを返します。クロスアカウントで使用する場合は、バケットの所有権、クエリコストの負担者、失効の伝播を定義します。
ステップ 5: コストを制御し障害から復旧する
一般的なフィルター用に派生テーブルをパーティショニングまたはマテリアライズし、フルスキャンや頻繁なアドホッククエリを制限します。ジャーナル、インベントリ、スキャン量、およびオブジェクトごとのコストを追跡します。構成が削除された場合、リージョンがサポートされていない場合、またはサービスが失敗した場合は、ソースイベントとエクスポートされたスナップショットを保持し、バージョン管理された構成から再構築して再度調整します。
模範解答
「私はインベントリを既存オブジェクトのベースラインとして扱い、ジャーナルを変更ソースとして扱い、クエリごとにレイテンシと一貫性の保証を明示します。構成を有効にした後、バックフィルを監視し、完了するまで完全カバレッジの結論は公開しません。その後、オブジェクトキー、イベント時刻、タイプによって冪等にマージし、定期的なインベントリ調整を実施します。テーブルバケットのIAM、機密フィールド、クロスアカウントコスト、およびクエリスキャンを個別に制限します。障害発生時は、メタデータテーブルを強力な一貫性を持つインデックスとして扱うのではなく、ソースS3と監査エクスポートを保持し、構成から再構築して欠損を検証します。」
よくある間違い
- ジャーナルをスナップショットとして扱う → 再生や損失によって誤った状態が発生する → インベントリと調整し、派生状態を維持する。
- バックフィル完了前にコンプライアンス結果を公開する → 未スキャンのオブジェクトが存在しないように見える → バックフィルのステータスとカバレッジを公開する。
- 上書きと削除の順序を無視する → 古いイベントが新しい状態を上書きする → イベント時刻、タイプ、および冪等性キーを使用する。
- 全員にテーブルバケットの読み取りアクセスを許可する → 機密メタデータが漏洩する → プリンシパル、カラム、テナントごとに認可する。
- ストレージのみを監視する → スキャンとオブジェクトごとの料金が肥大化する → ボリューム、頻度、および総コストを監視する。
- 構成喪失後にインデックスをリセットする → 監査リネージとギャップが消失する → 保持されたソースから再構築をバージョン管理して調整する。
フォローアップの質問
フォローアップ 1: ジャーナルとインベントリはどのように連携しますか？
インベントリは既存オブジェクトのスナップショットを提供し、ジャーナルはその後の変更を記録します。インベントリからベースラインを構築し、ジャーナルの変更を適用し、新しいインベントリと定期的に調整して、欠落または重複したイベントを修正します。
フォローアップ 2: バックフィルの未完了をどのように検出しますか？
バックフィルのステータス、カバレッジ、失敗を追跡し、未完了状態をクエリレイヤーに伝播します。完全カバレッジの結論は完了を待つか、結果を未完了として明示的にマークします。
フォローアップ 3: 重複イベントはどのように処理しますか？
オブジェクトキー、イベント時刻、イベントタイプ、および利用可能なバージョン情報から冪等性キーを生成します。重複した消費はno-op（何もしない処理）となり、不確実な順序はスナップショットの調整によって修正されます。
フォローアップ 4: S3 Metadata tablesを避けるべきなのはどのような場合ですか？
ビジネスがミリ秒レベルのread-after-write一貫性、複雑なトランザクション結合、または完全にカスタムなフィールドガバナンスを必要とする場合は、専用のインデックスまたはデータベースを検討してください。メタデータテーブルは、オブジェクトディスカバリ、監査、およびバッチガバナンスソースに適しています。