プロンプトと適用範囲
イベントプラットフォームにおいて、異なるチームが所有する Avro の writer と reader が存在します。ある変更では JSON の空白または doc のみが編集され、別の変更ではデフォルト値を持つフィールドが追加されます。レジストリは、互換性のない変更を拒否しながら、読み取り上の意味が同一であるスキーマを識別する必要があります。正規化、フィンガープリント、互換性ゲート、キャッシュネゴシエーションを設計してください。
これは Apache Avro 仕様の知識をテストするものです。フィンガープリントはセキュリティ署名ではなく識別子として扱い、すべての言語バインディングが同一のレジストリ API を公開していると仮定しないでください。
面接官がテストしていること
- Parsing Canonical Form、スキーマ解決、ビジネスバージョン番号の区別。
- どの属性が削除、順序変更、または正規化されるかの把握。
- 衝突リスクと規模に応じた 64 ビット、128 ビット、または SHA-256 フィンガープリントの選択。
- リリースゲート、キャッシュヒット、ネゴシエーション失敗、ロールバックのオブザーバビリティの設計。
明確化のための質問
- フィンガープリントの用途はローカルキャッシュキー、サービス間ネゴシエーション、監査およびサプライチェーンのアイデンティティのどれですか？
- レジストリは writer スキーマを保持し、consumer はフィンガープリントによって取得できますか？
- 互換性は後方互換性（backward）、前方互換性（forward）、双方向のどれですか？
- 衝突が発生した場合、システムは完全な正規バイトの比較にフォールバックできますか？
- クライアントが使用している Avro 仕様のバージョンは何ですか。また、カスタムの正規化ツールは存在しますか？
30秒での回答
「有効なスキーマを Avro の Parsing Canonical Form に変換し、その正規バイトのフィンガープリントを生成します。このルールにより、doc などのパースに関係のない属性が削除され、オブジェクトのキー順が正規化され、不要な JSON の空白が排除されます。フィンガープリントはキャッシュおよびネゴシエーションのインデックスにすぎず、完全なスキーマの信頼できるソースはレジストリのままであり、互換性は writer/reader の解決によって検証されます。小規模なキャッシュには 64 ビットの Rabin フィンガープリントを使用し、大規模な場合は 128 ビットまたは SHA-256 を使用し、衝突を処理するためにヒット後に正規バイトを比較します。すべてのリリースおよびランタイムのパスで、仕様バージョン、フィンガープリント、解決結果、フォールバック理由を記録します。」
ステップバイステップの設計
1. 正規バイトの生成
入力は有効な UTF-8 Avro JSON でなければなりません。プリミティブスキーマを単純形式に変換し、完全修飾名を展開し、冗長な名前空間を削除します。type、name、fields、symbols、items、values、size などのパース用属性のみを保持します。オブジェクトキーを順序付けし、JSON 文字列のエスケープを解除し、整数リテラルから引用符と先頭のゼロを削除し、文字列外の空白を削除します。
2. アイデンティティと互換性の分離
正規テキストが一致していることは、reader がパースにおいてスキーマを区別できないことを意味しますが、すべてのバージョンが相互に読み取り可能であることを証明するものではありません。ゲートは引き続きスキーマ解決を実行します。レコードフィールドの名前による照合、writer 固有フィールドの無視、reader で追加されたフィールドのデフォルト値の確認、仕様に従った数値のプロモーションなどです。
3. フィンガープリント長の選択
64 ビットの Rabin フィンガープリントは約 100 万個のスキーマのキャッシュに適しています。128 ビットのダイジェストはより大規模なコレクションに適しており、SHA-256 はより長い識別子を提供します。Avro はフィンガープリントがセキュリティ保証を提供しないことを明示しているため、署名、認可、整合性チェックは別途使用してください。レジストリは完全な正規バイトとスキーマを正本として保存します。
valid schema -> canonical bytes -> fingerprint
| |
registry value cache / handshake key4. リリースゲートの構築
コミット時に正規バイトとフィンガープリントを計算します。まず変更を doc、名前空間の冗長性、または空白のみとして分類し、次に本番環境の consumer セットに対して writer/reader 解決を実行します。ゲートは未加工の JSON テキストを比較するのではなく、「同一の正規形式」、「互換性はあるが異なる正規形式」、または「互換性なし」を報告する必要があります。フィンガープリント、完全なスキーマ、正規化ツールのバージョン、互換性レポートをまとめて永続化します。
5. ランタイムでのネゴシエーションと衝突からの復旧
consumer はフィンガープリントを送信します。ヒットした場合はキャッシュされたスキーマを返すか確認し、ミスの場合はレジストリに問い合わせます。異なる正規バイトが短いフィンガープリントを共有している場合は、完全なバイトを比較し、キャッシュを暗黙的に再利用するのではなく競合を返します。キャッシュキーは、誤ったヒットを減らすために、フィンガープリントと正規の長さ、または第 2 のコンテンツダイジェストを組み合わせることができます。
6. アップグレードと復旧のオブザーバビリティ
producer、consumer、フィンガープリント、正規化ツールのバージョン、解決結果、レジストリのレイテンシ、ミス、競合、フォールバックを記録します。イベントペイロードは絶対にログに記録しないでください。正規化ツールをアップグレードする際は、古いスキーマをオフラインで再計算し、古いキーと新しいキーを二重読み込み（dual-read）します。ヒット率と互換性レポートが安定した後にのみ切り替えを行い、ロールバック用に古いマッピングを保持します。
模範的な質の高い回答
「私は Avro スキーマを構造化入力として扱い、正規バイトを生成します。doc やパースに関係のないその他の属性を削除し、完全修飾名を展開し、キーの順序を修正し、文字列、整数、空白を正規化します。正規形式が一致することは、reader がスキーマを区別できないことを意味するだけであり、リリースゲートは依然として writer/reader 解決（特に reader で追加されたフィールドのデフォルト値、名前のマッチング、数値のプロモーション）を実行します。フィンガープリントはキャッシュとプロトコルネゴシエーションをサポートしますが、セキュリティはサポートしません。小規模では 64 ビット Rabin を使用し、大規模では 128 ビットまたは SHA-256 を使用し、ヒット後に完全なバイトを比較し、レジストリに完全なスキーマを保持します。テレメトリはフィンガープリント、正規化ツールのバージョン、互換性、ミス、競合をカバーし、アップグレードの二重読み込みとロールバックを可能にします。」
よくある間違い
- 未加工の JSON をハッシュ化する → 空白やキー順によって誤ったバージョンが作成される → 最初に正規化する。
- 同一の正規形式を普遍的な互換性として扱う → reader のデフォルト値やプロモーションがスキップされる → スキーマ解決を必ず実行する。
- 64 ビットフィンガープリントを署名として扱う → 偽造や改ざんに耐えられない → 署名とアクセス制御を別個に使用する。
- 短いフィンガープリントのみを保存する → ミスや衝突の際にスキーマを復元できない → 完全な正規バイトを保持する。
- 正規化ツールをその場で即時切り替える → 新旧のキャッシュキーが分断される → 切り替える前に二重読み込みして監視する。
フォローアップの質問と回答
なぜ doc の変更で正規形式が変わらないことがあるのですか？
doc はパースに関係がなく、正規形式のルールによって削除されます。製品ドキュメント、監査証跡、生成コードのメタデータでは、元のスキーマと変更メモを別途保存する必要がある場合があります。
衝突によって誤ったスキーマがデコードされなかったことをどのように証明しますか？
短いフィンガープリントはインデックスとしてのみ使用します。ヒット時に完全な正規バイトを比較し、異なる場合は競合を返し、完全なスキーマを取得してアラートを発生させ、自動デコードをブロックします。
なぜビジネスバージョン番号だけを使用しないのですか？
ビジネスバージョンはリリースの意図を表しますが、チーム間や JSON 表現間で同等のスキーマを重複排除することはできません。フィンガープリント、完全なスキーマ、解決レポートを組み合わせることで、重複排除、ネゴシエーション、監査がサポートされます。