Oodleが大規模な可観測性を高速に保つ方法

可観測性の分野では、従来のデータベースアーキテクチャはストレージとコンピューティングを密結合し、突発的なクエリに備えて過剰に容量を確保するため、コストが高くなります。Oodleは異なるアプローチを採用しています。データをオブジェクトストレージ（S3など）に永続化し、必要なときだけコンピューティングリソースを起動します。このアイデアは単純に聞こえますが、大規模な負荷下で高速な応答を維持するには、データの取り込み、圧縮、クエリ実行の詳細な最適化が必要です。

Oodleのアーキテクチャは主にメトリクスデータを対象としていますが、ログやトレースにも同様に適用できます。その中核原則は、データの不変性、インシデント対応において最近のデータが重要であること、クエリ負荷の変動が大きいこと、同じデータが繰り返しクエリされることです。AIの導入により、これらの要件はさらに強化されています。AI支援デバッグツールは多数の並列クエリを発行し、モデルのライフサイクルはより長いデータ保持期間を要求します。従来の一体型アーキテクチャでは、このような成長に過剰なプロビジョニングなしには対応できません。

メトリクスデータの特殊性は、約30秒間隔で到着するものの、時系列ごとに順次書き込まれるわけではなく、多数の系列に分散してラウンドロビンで到着することです。これにより、単純な順次書き込みパターンに依存できない、圧縮でインターリーブされた断片を結合する必要がある、圧縮がバックグラウンドで行われている間も最近のデータに対する高速クエリが期待される、という問題が生じます。

Oodleのソリューションは次の通りです。

• ストレージとコンピューティングの分離：オブジェクトストレージは耐久性と経済性を提供し、サーバーレスコンピューティング（AWS Lambda）が突発的なクエリを処理します。
• 取り込み：Prometheus Remote WriteやOTLPプロトコルでデータを受信し、Write-Ahead Log（WAL）としてS3にバッチ書き込み。圧力ベースのフラッシュでホットパスの停滞を防止し、早期パーティショニングで後続のマージ作業を軽減します。
• 圧縮：WALデータを読み取りに適したファイル形式に変換。重複排除、インデックスファイルの書き込み、古いオブジェクトのクリーンアップを行います。
• Blazer：直近のWALデータをメモリにキャッシュし、圧縮が完了するまで高速なクエリを提供。高可用性レプリカもサポート。
• クエリパス：データの鮮度に基づいてクエリをルーティング。通常負荷は専用コンピューティング、バーストはLambdaで処理。カラム指向のPromQLエンジンとカラム指向の圧縮ファイルにより、必要なカラムのみを読み取り、スキャン量を削減。
• ファイル形式の最適化：メトリクス名でソートされたデータブロック、トレイラーメタデータによるターゲット読み取り、圧縮メタデータと辞書エンコーディング、カラムチャンクレベルのスキップなど、不要なデコードを削減。

さらに、OodleはシリアルなS3呼び出しを避け、並列読み取りと範囲読み取りを採用し、小さなメタデータをキャッシュしてオーバーヘッドを削減しています。圧縮ファイルは約128MBに制限され、並列化が容易で、巨大なモノリスファイルを回避します。データとメタデータは分離されて保存され、メタデータファイルは小さいため、迅速に取得できます。

最終的に、エンジニアリングチームは、ストレージクラスタの管理負担軽減、保持期間の経済性向上、予測不可能なクエリ同時実行性への対応、テレメトリ取り込みから利用可能な回答までの高速パスを実感しています。Oodleの設計目標は、1時間あたり10億以上の時系列を処理することです。