## Memo ## Memo with LLM ### 論文情報 - **タイトル**: Meta's Next-generation Realtime Monitoring and Analytics Platform - **著者と所属**: - Stavros Harizopoulos, Taylor Hopper, Morton Mo, Shyam Sundar Chandrasekaran, Tongguang Chen, Yan Cui, Nandini Ganesh, Gary Helmling, Hieu Pham, Sebastian Wong - 所属: Meta Platforms, Inc., Menlo Park, CA - **カンファレンス名**: PVLDB (Proceedings of the VLDB Endowment) - **発表年**: 2022年 - **巻号**: Volume 15, Issue 12, pp. 3522-3534 ### 論文概要 本論文は、Metaの次世代リアルタイム監視・分析プラットフォーム「Kraken」について述べている。Krakenは、従来のScubaシステムのアーキテクチャを大幅に再設計したもので、ストレージ管理をクエリサービングシステムから分離し、単一の永続的な真実の情報源（single source of truth）を導入することで、システムの耐障害性とクエリパフォーマンスを大幅に改善した。Krakenは、データの新鮮さに関する許容可能な範囲を維持しながら、ペタバイト規模のデータに対して数万のユーザーによる日常的な利用を可能にし、ユーザーに見える停止時間なしで完全な本番環境への移行を達成した。 ### 詳細解説 #### 問題設定 **背景と課題**: Scubaは、Metaの構造化ログ分析プラットフォームとして12年以上運用されてきた。数万のデータセットを持ち、数千のユーザーが日常的に使用している。エンジニアやデータサイエンティストは、大規模分散システムのデバッグ、システムパフォーマンスの可視化、運用上の洞察の導出などにScubaを利用している。 **従来のScubaのトレードオフ**: 1. **大規模なファンアウトツリーアーキテクチャ**: 数千のリーフノード、数十のアグリゲーター、1つのルートノードからなる3層の集約ツリートポロジーを採用。これによりジョインのサポートを犠牲にしたが、集約・射影・選択クエリを高速に実行可能。 2. **メモリはキャッシングに使用**: ブロックフラグメントキャッシングと中間結果キャッシングの2種類のキャッシングを実装。クエリ結果サイズとスクラッチスペースが制限される（GROUP BYグループ数を40万に制限）。 3. **時間列のみのゾーンマップ**: 多くのインデックスやブルームフィルターを使用する代わりに、時間列に対する単一のゾーンマップのみを採用し、取り込みオーバーヘッドを削減。 4. **フラットで柔軟なスキーマ**: ネストされたJSONデータを取り込むが、トップレベルでフラット化することで、パースとカラムナーブロック組立を高速化。 5. **ベストエフォートのデータ可用性と耐久性**: 各Scubaデプロイメントは地理的に独立しており、メッセージバスからデータを独立して消費し、データのコピーを1つだけ保存。これにより、異なるデプロイメント間でデータの同期が取れず、データギャップやデータ損失が発生。 **再設計の動機**: - **一貫性の向上**: ノード障害ごとにデータセットにギャップが生じ、各デプロイメントで異なる結果が返される問題 - **耐久性の向上**: 永続的なノード障害による永続的なデータ損失の問題 - **保持期間の延長**: 計算、ストレージ、ストレージ管理、取り込みが結合されているため、より多くの保持期間を提供するには、デプロイメント全体のサイズを増やす必要がある問題 - **運用オーバーヘッドの削減**: ホストドレイニングの簡素化、ノード安定性の向上、ストレージとコンピュートの独立したスケーラビリティの実現 #### 提案手法 **Krakenアーキテクチャの主要コンポーネント**: 1. **ビルディングブロック**: - **Scribe**: データをKrakenに書き込むための分散メッセージキュー。各カテゴリは複数のLogDeviceログによってバックアップされている。 - **Turbine**: ストリーミングアプリケーション管理サービス。Krakenテイラーのランタイム環境、スケーリング、チェックポイントストレージと配布を提供。 - **LogDevice**: 取り込みパイプラインのコンポーネント。各メッセージはログIDとログシーケンス番号（LSN）によって一意に識別可能。5つの物理的に分離されたクラスタに分散してプロビジョニングされ、各メッセージは3つのランダムに選択された物理クラスタに同期的に複製される。 - **BLOBストレージ**: Amazon S3に類似したBLOBストレージサービス。バックアップ、ステージングエリア、チェックポイントストレージの3つの目的で使用。 - **Shard Manager**: シャードの割り当て管理、リクエストのルーティング、ロードバランシング、フェイルオーバー処理を担当。 2. **データ取り込み（Ingestion）**: - Krakenのテイラーは、Scribeから入力サンプルを読み取り、それらをRowBlocksと呼ばれるカラムナーストレージ形式に変換。 - 各RowBlockには64ビットのランダムな一意IDが割り当てられる（32ビットのランダム整数と32ビットのタイムスタンプを連結）。 - RowBlocksはデータセットのパーティションにランダムに割り当てられ、シャードにマッピングされる。 - RowBlocksはLogDeviceクラスタに書き込まれる（シャード数と同じ数のログに対して、シャードごとに1つのログ）。 3. **シャーディング（Sharding）**: - データプレーンとコントロールプレーンで異なるシャーディングメカニズムを使用。 - データプレーン: データセットは設定可能な数のパーティションに従ってパーティション化される（初期32パーティション、最大8,192パーティション）。 - パーティションからシャードへのマッピング式: ``` ShardId = (hash(FormalizedPartitionName) + PartitionId²) rem NumShards ``` - NumShardsは素数として選択され、同じデータセットの複数のパーティションが同じシャードにマッピングされる確率を最小化。 4. **BLOBストレージのディレクトリ構造**: ``` scuba_backup/tree/shards └── <shard_id> (metadata: shard checkpoint) └── <dataset_partition> └── <rowblock_files> ``` - RowBlockファイル名: `lsn + offset`（ビット反転により逆時系列順にソート） 5. **コントロールプレーン**: - データとデータ管理コントロールメッセージを同じLogDeviceログ上で多重化。 - メッセージタイプ: Data（新しいRowBlocks）、Heartbeat（接続検出用）、Compaction（複数の小さいRowBlocksを大きなブロックに圧縮）、Update（RowBlockの置換または削除）。 6. **リモートバックアップとコンパクション**: - Backup and Compaction Service (BCS)が、バックアップとコンパクションを担当。 - BCSはLogDeviceログからRowBlocksを読み取り、同じデータセットパーティションからのRowBlocksをバッチ処理し、より大きなRowBlocksに圧縮してBLOBストレージにアップロード。 - 圧縮されたRowBlockの通知をLogDeviceログに追加し、リーフノードがBLOBストレージからダウンロードして元のRowBlocksを置き換える。 7. **データ管理**: - Update Serviceが時間範囲削除、サブサンプリング、カラム削除の3つの操作をサポート。 - 各操作は、データセットパーティションごとに並列に分散可能。 - 操作完了後、LogDeviceログにメッセージを書き込み、リーフノードに再同期または削除が必要なRowBlocksを通知。 8. **クエリ可能なストレージノード（Queryable Storage Nodes）**: - リーフノードは、Krakenのクエリ可能なデータストレージノード。 - 各グローバルシャードは、リージョンごとに正確に1つのリーフノードに割り当てられ、各リージョナルクラスタがKrakenデータの完全なコピーを1つ持つ。 - **クエリパス**: ユーザークエリはまずルートノードに到達し、ルートノードはデータセットパーティション設定とシャード割り当てのコピーを保持。データセット名を取得後、`N_Partitions`個のサブリクエストを作成（データセットパーティションごとに1つ）。 - **シャードデータブートストラップ**: シャード割り当て中、リーフノードはBLOBストレージからデータのスナップショットをダウンロードし、その後適切なLSNから対応するLogDeviceログのテイリングを再開。 9. **Nessie（仮想保持）**: - Krakenの保持期間制限を克服し、Metaのデータウェアハウスの機能を活用するために、仮想保持機能（コードネームNessie）を構築。 - データセットのカテゴリからのデータストリームをウェアハウスのデータ形式に変換し、定期的に各テーブルにダンプ。 - クエリがKrakenプロキシに到着すると、自動的に2つのクエリに分割: 1つはKrakenデプロイメントに送信され元の保持期間内のデータにアクセス、もう1つはNessieに送信されウェアハウスストレージから直接読み取り。 **本番化プロセス**: 1. **グローバルテイラー移行**: - 単一ライター・モデルへの移行: 複数の地理的に分離されたデータセンターリージョンに分散された単一のグローバルテイラージョブセット。 - パフォーマンステスト: 既存のScubaデプロイメントの1つを、3つのリージョンに複製されたZippyDBストレージに移行してテスト。 2. **データ移行**: - **新しいデータ**: 既存のScubaデプロイメントの1つを新しいグローバルテイラージョブに移行し、KrakenとレガシーScubaの両方にRowBlocksを書き込み。 - **履歴データ**: バージョニングメカニズムを導入。履歴データのコピー前に、テイラーは新しいバージョンで新しいRowBlocksを書き込むように計測。コピー中は、新しいバージョンのRowBlocksを無視し、履歴データの重複を防止。 3. **耐障害性テスト**: - **ドレインテスト**: 地理的なシャード配置制限を人為的に導入し、データセンターからシャードを退避させ、システムが他のデータセンターに十分な容量を持つことを確認。 - **Chaos Monkeyスタイルの障害注入テスト**: ネットワーク停止やアプリケーションレベルの障害などの戦術的な場所に障害を導入し、Scubaが非クリティカルな障害に対して回復力があり、クリティカルな依存関係が失敗した場合に適切に失敗することを確認。 #### 新規性 本研究の新規性は、以下の点にある: 1. **ストレージ管理とクエリサービングの分離**: 従来のScubaでは、リーフノードがデータ管理とクエリ処理の両方を担当していたが、Krakenでは、Backup Compaction ServiceやUpdate Serviceなどの独立したサービスにデータ管理を委譲。これにより: - リソース競合の削減: データ管理操作がユーザークエリのパフォーマンスに与える影響を最小化 - 一貫性の向上: 単一の真実の情報源により、異なるデプロイメント間での一貫性を保証 2. **単一の真実の情報源（Single Source of Truth）**: LogDeviceとBLOBストレージを組み合わせることで、地理的に分散した環境で単一の一貫したデータビューを提供。各シャードのデータは、バックアップ内のデータとLogDeviceログ内のデータの和集合として定義される。 3. **コントロールメッセージの多重化**: データメッセージとコントロールメッセージを同じLogDeviceログで多重化することで、データ管理操作の順序とデータの一貫性を保証。 4. **無停止での本番化**: ユーザーに見える停止時間なしで、計画的なデータ損失なしに、新しいアーキテクチャへの移行を達成。これは以下により実現: - 段階的な移行: 新しいデータと履歴データを別々に処理 - バージョニングメカニズム: 新旧データの重複を防止 - 継続的な検証: ドレインテストと障害注入テストによる耐障害性の検証 5. **地理的分散と耐障害性**: - Scubaテイラーは5つのデータセンターに分散 - LogDeviceクラスタは5つのデータセンターに地理的に分散 - 各メッセージは少なくとも3つのランダムに選択された物理クラスタに同期的に複製 先行研究との比較: - **Rockset [30]とNapa [3]**: 書き込み時にマテリアライズドビューの作成によって最適化を実行し、読み取り時のパフォーマンスを向上。Napaはさらに進んで、クライアントがコスト、新鮮さ、クエリパフォーマンスの要件に基づいてこれらの書き込み側最適化をトレードオフできるように設定。Krakenは、これらの概念をクライアントが変更可能な設定パラメータとして公開せず、代わりに取り込み時にオプションのサンプリングポリシーを設定できるようにしている。 - **[[Apache Druid]] [32]、Pinot [15]、[[2024__VLDB__ClickHouse - Lightning Fast Analytics for Everyone|ClickHouse]] [7]**: ストリーミングとバッチ取り込みのさまざまな形式をサポート。これらのシステムとは異なり、Krakenに取り込まれたデータは、単一の取り込みAPIを介してデータウェアハウスなどの複数のシステムに同時に取り込むことができる。 - **Procella [5]**: 取り込み時にデータをログに追加。データの新鮮さを向上させるため、データをベストエフォートの永続的なインメモリバッファと永続的なリモートストレージに二重書き込みするスキームを採用。Krakenは、小さなバッチングウィンドウの後に全てのデータを永続的なストレージに永続化してから、データをクエリ可能にする。 - **Dremel [24]**: 元のツリー集約アーキテクチャはScuba/Krakenのリーフアーキテクチャに最も近い。Dremelとは異なり、リアルタイム監視システムは新鮮さとクエリパフォーマンスに厳しいターゲットを持ち、ネストされたデータの完全なサポートではなく、大規模データセットのインタラクティブなパフォーマンスに焦点を当てている。 #### 実験設定 **データセット**: - 異なるサイズクラスから合計204のデータセットを選択 - サイズクラス別の典型的なデータセット: | Dataset | Size (GB) | # Shards | # Records | # Columns | |---------|-----------|----------|-----------|-----------| | T1 | 150,000 | 8,192 | 1.27 T | 3,500+ | | T2 | 50,000 | 8,192 | 869 B | 578 | | T3 | 1,000 | 1,024 | 46 B | 88 | | T4 | 500 | 128 | 17 B | 12 | | T5 | 50 | 32 | 1 B | 10 | - T5サイズクラスから200データセット、T1〜T4から各1データセットを選択 **評価期間**: - 連続する2週間にわたって、従業員からの100%の本番トラフィックを使用 - クエリトラフィックは、自動化されたワークロードと人間主導のワークロードの混合 **評価指標**: 1. **クエリレイテンシ**: P50クエリレイテンシ 2. **ネットワーク利用率**: 集約ツリー通信に使用されるバイト数 3. **取り込みレイテンシ**: エンドツーエンドの取り込みレイテンシ（Scribeがイベントを永続化した時刻とScubaリーフノードがイベントを永続化した時刻の差） 4. **リカバリ時間**: 障害注入テスト後のデータリカバリ時間 #### 実験結果 **1. クエリパフォーマンス**: - Krakenの単一の真実の情報源により、より細かいファンアウト制御が可能になり、P50レイテンシが大幅に改善: - T3より小さいデータセット: ストラグラーの影響を最小化するためにファンアウト係数を削減 - より大きなサイズクラスのデータセット: 並列性を高めるためにファンアウト係数を増加 - **結果**: レガシーScubaと比較して、P50クエリレイテンシが19.6%〜71.3%改善 - ネットワーク帯域幅の削減: - T3より小さいデータセットのファンアウト係数削減により、**ネットワーク利用率が50%削減** **2. 取り込みパフォーマンス**: - システム全体の平均取り込みレイテンシ: **8.22秒** - P50レイテンシ: **7.8秒** - データセットサイズクラス別の取り込みレイテンシ: | Dataset | Average | P50 | P99 | |---------|---------|-------|-------| | T1 | 17.5 s | 17.9 s| 24.9 s| | T2 | 13.8 s | 13.7 s| 20.7 s| | T3 | 11.4 s | 11.4 s| 18.2 s| | < T3 | 17.3 s | 16.8 s| 20.7 s| | All | 8.22 s | 7.8 s | 16.1 s| **3. リカバリ性能**: - 障害注入テスト: デプロイメントの10%のリーフノードを完全にネットワークから切断 - 6回のテスト（6ヶ月間にわたって異なるデプロイメントで実施）の平均リカバリ時間: **約180分** - リカバリプロセス: - テスト開始時: 約10%のシャードが失われる - システムは徐々に障害から回復し、シャードを他のサーバーに移動 **主要な知見**: 1. **パフォーマンスとスケーラビリティ**: Krakenは、新鮮さの目標を維持しながら、クエリレイテンシとネットワーク利用率を大幅に改善 2. **データ整合性**: 単一の真実の情報源により、異なるデプロイメント間での一貫した結果を保証 3. **運用上の利点**: ストレージとコンピュートの分離により、データ管理操作がクエリパフォーマンスに与える影響を最小化 4. **耐障害性**: 地理的に分散したアーキテクチャにより、データセンター全体の停止に対しても継続的なサービスを提供 ## Abstract 従来のデータベースシステムでは、データとシステムの可用性が結びついているが、構造化ログに対するリアルタイム監視と分析を対象とする広範なクラスのシステムにおいては、これらの特性を分離することができる。これらのシステムでは、応答性とデータの新鮮さが、完全に正確な回答よりも重要であることが多い。そのようなシステムの一つがMetaのScubaである。歴史的に、Scubaはデータの完全性と耐久性よりも、システムの可用性、結果の速度と新鮮さを優先してきた。これらの選択により、Scubaはテラバイト規模からペタバイト規模へと成長し、さまざまなユースケースのオンボーディングを継続できたが、不完全なデータへの対処とデータ損失の管理という運用コストも伴った。 本論文では、Scubaアーキテクチャの次世代版（コードネームKraken）を提示する。Krakenは、ストレージ管理をクエリサービングシステムから分離し、単一の永続的な真実の情報源を導入している。これにより、クライアントが観測するデータの新鮮さの許容範囲を尊重しながら、システムの耐障害性とクエリパフォーマンスに具体的な改善をもたらしている。また、ユーザーに見える停止時間なしに、古いシステムを段階的にシャットダウンしながら、Krakenを完全な本番環境に展開した過程についても説明する。