可観測性プラットフォームの進化は、孤立したデータウェアハウスや高価なプロプライエタリインデックスから、データレイクの柔軟性とウェアハウスのパフォーマンスを組み合わせた統一されたレイクハウスアーキテクチャに移行しています。初期のSaaS可観測性プロバイダーは、パフォーマンスの限界に直面し、ペタバイト規模での急激なコスト曲線に苦しんでいたElasticsearchやSplunkクラスタに依存していました。Apache IcebergやDelta Lakeのようなオープンテーブルフォーマットの出現により、オブジェクトストレージにおける原子的トランザクションと時間旅行が可能になり、Trinoのようなクエリエンジンはクラウドストレージ上でインタラクティブなSQLを提供するまでに成熟しました。この統合により、単一の共有インフラストラクチャから数千のテナントにサービスを提供する可能性が生まれましたが、厳格なセキュリティ境界を確保しながらサブ秒レイテンシを維持し、インテリジェントなティアリングを通じてストレージコストを最適化する新たな課題が生まれました。
主な課題は、異なるエージェント（Fluentd、Prometheus、OpenTelemetry）から毎秒何百万ものイベントを取り込む一方で、数エクサバイトの履歴データに対してインタラクティブなクエリパフォーマンスを提供するという矛盾する要件を調和させることにあります。従来の共有ノットデータベースは、テナント間クエリのノイズによって崩壊し、テナントごとのサイロは運用オーバーヘッドを引き起こします。厳格な分離により、テナントAのクエリはテナントBのデータを物理的にスキャンすることができず、行レベルのセキュリティフィルターはしばしばパフォーマンスの崖を引き起こします。さらに、すべてのデータをホットなSSDに保存することは経済的に不可能ですが、冷データをAmazon S3 Glacierに移動すると、アーカイブされたデータが突然クエリされた際にサブ秒のSLAを違反するリスクがあります。カタログサービスは、パーティションとスキーマの進化を追跡し、単一障害点または高速度取り込み時のスループットボトルネックを回避するために、分散化を維持する必要があります。
Apache Icebergをテーブルフォーマットとして使用し、Amazon S3、Azure Data Lake Storage、またはGoogle Cloud Storageの上に配置したティアードレイクハウスを設計します。Apache KafkaまたはAmazon Kinesisを介してストリームを取り込み、Apache FlinkまたはSpark Streamingを使用してデータを適切なティアに配置します：ホット（クエリノード上のローカルNVMe SSD）、ウォーム（S3 Standard）、またはコールド（S3 Glacier Instant Retrieval）。TrinoまたはPrestoを分散クエリエンジンとしてデプロイし、クエリスキャンレベルでテナント境界を強制するために、行レベルおよび列レベルのセキュリティポリシーのためにApache RangerまたはAWS Lake Formationと構成します。集中型ボトルネックを回避するために、地域のレプリカを持つHive MetastoreフェデレーションまたはAWS Glueを使用したフェデレーテッドカタログを実装します。自動ティアリングは、クエリログを監視するMLベースのヒートマップアナライザーによって駆動され、頻繁にアクセスされる冷データを再びウォームストレージに昇進させ、古くなったホットデータを降格させ、各ティア間でのクエリの透明性を確保するためにIcebergにメタデータポインタを保持します。
詳細な例：
NebulaObservabilityは、12,000の企業顧客にサービスを提供するSaaSプロバイダーで、古くなったElasticsearchクラスターの交換が必要でした。これは、8PBのストレージで月2百万ドルのコストがかかっていました。各顧客は、2-10TB/日のログとメトリクスを生成し、サブ秒のダッシュボード読み込み時間を伴うアドホックSQL分析を必要としています。規制要件は、顧客Aが顧客Bのデータの存在をタイミング攻撃やクエリエラーを通じて推測できないようにする厳格な分離を義務づけています。データの保持は13か月と義務づけられており、95％のクエリは過去72時間のデータにヒットします。以前のアーキテクチャは、「ノイジー・ネイバー」問題に悩まされており、一つの顧客の大きな集約クエリが他の顧客のパフォーマンスを低下させていました。
解決策1：シャーディングされたClickHouseクラスター
テナントベースのシャーディングを持つ大規模なClickHouseクラスターをデプロイすることが検討されました。その利点は、優れた単一クエリパフォーマンスと成熟したSQLサポートによるベクトル化された実行ですが、欠点は深刻でした：ペタバイト規模のクラスターの運用の複雑さ、パフォーマンス低下なしに行レベルのセキュリティを強制する難しさ、ストレージとコンピュートの独立したスケールの実現不可能性、さらに、テナントのオンボーディング中にClickHouseクラスターを再シャーディングするには数時間のダウンタイムと手動の介入が必要でした。
解決策2：テナントごとのPostgreSQLインスタンスとTimescaleDB
各テナントに隔離されたPostgreSQLインスタンスをプロビジョニングしてTimescaleDB拡張機能を使用することで、完璧なセキュリティ分離とシンプルなバックアップ戦略が提供されました。その利点は明確で、ネイティブな行レベルのセキュリティ、GDPRにおけるテナント削除の容易さ、テナント間の干渉がないことでした。しかし、欠点がこのアプローチを不可能にしました：12,000のデータベースインスタンスの管理、パッチサイクル、接続プールの枯渇による運用の悪夢。カラムフォーマットと比較して圧縮の欠如により、ストレージコストが急増し、プロバイダー自身の使用インサイトのためのテナント間分析が不可能になりました。
解決策3：階層ストレージを持つフェデレーテッドレイクハウス
Apache Icebergに基づくレイクハウスをTrinoと自動ティアリングで実装することは、最適なバランスを提供しました。その利点には、共有インフラの規模の経済、ユーザーエラーを防ぐIcebergの隠れたパーティショニング、およびS3の無限のスケーラビリティが含まれます。Apache Rangerによる行レベルのセキュリティは、クエリを変更することなく詳細なポリシーを可能にしました。自動ティアリングは、冷データをS3 Glacierに移動しながらメタデータをホットに保持することで、70％のストレージコストを削減しました。欠点には、重要な調整の複雑さがありました：クエリ計画には慎重なパーティションプルーニングが必要で、ティアリングアルゴリズムにはスラッシングを避けるためのトレーニングデータが必要でした。
選択された解決策とその理由：
解決策3が選ばれた理由は、このアプローチが惑星規模の要件を満たしつつ厳格な分離を維持していたためです。Icebergフォーマットのテーブルメタデータの原子的更新能力によって、ロックなしでのスキーマ進化が可能になり、ゼロダウンタイムデプロイメントにとって重要でした。Trinoのコネクタアーキテクチャは、クエリの条件を＜S3＞にプッシュダウンでき、スキャンデータを削減しました。自動ティアリングは、AWS Lambda関数を使用してAthenaクエリログによってトリガーされ、手動介入なしでコスト最適化を保証しました。このアプローチは、ストレージとコンピュートを分離し、トラフィックスパイク時に独立したスケーリングを実現しました。
結果：
このシステムは、12PBのアクティブデータに対して650msのp99クエリレイテンシを達成し、ピーク時に50,000の同時クエリをサポートしました。ストレージコストは以前のElasticsearchアーキテクチャと比較して68％削減され、月間で1.36百万ドルを節約しました。自動ティアリングは、データアクセスパターンの94％を正確に予測し、「キャッシュミス」がコールドストレージに発生するのは0.3％の時間だけでした。最初の18か月の運用中に、テナント間データ漏洩に関連するセキュリティ事件は記録されず、四半期ごとのペネトレーションテストによって検証されています。新しいテナントのオンボーディングは、30秒未満のメタデータ操作にすぎませんでした。
自動ティアリングアルゴリズムが「ウォーム」データを誤って降格させた場合、クエリレイテンシの爆発をどのように防ぎますか？
候補者はしばしばキャッシングに反応する提案をしますが、予測メカニズムを考慮していません。詳細な回答には、クエリアクセスログに対する指数平滑法を用いた予測ティアリングシステムを実装することが求められ、降格する前にミリ秒単位の初回バイトレイテンシを持つ「ぬるま湯」中間ティアをS3 Standard-IAで維持する必要があります。さらに、TrinoとS3の間に分散キャッシングレイヤーとしてAlluxioをデプロイすることで、予期しないアクセススパイクを吸収します。重要な詳細は、「読み込み時の昇進」を実装することです：コールドデータがアクセスされると、システムはそれを非同期にウォームティアにコピーし、現在のリクエストをS3 Glacier Instant Retrievalから提供して、以降のクエリがより高速なストレージにヒットするようにします。
スキーマ進化（列の追加）に対するACID一貫性を、グローバルトランザクションコーディネーターがボトルネックにならないようにするにはどうしますか？
ほとんどの候補者は分散ロックを提案しますが、これは「集中型ボトルネックなし」という要件に違反します。正しいアプローチは、Apache Icebergの楽観的同時実行制御とメタデータレイヤリングを活用することです。各テナントテーブルには独立したmetadata.jsonファイルの系譜があります。スキーマの変更は、新しいメタデータファイルを付加してシーケンス番号をインクリメントします；カタログ（例：AWS Glue）は、現在のメタデータファイルへのポインタのみを保存します。コミット中、ライターはポインタが変更されているか（競合）をチェックし、必要に応じて再試行します。これにより、テナントテーブルは独立した名前空間であるため、グローバルロックの必要が排除されます。稀なテナント間スキーマ更新（例：ユニバーサル列の追加）の場合は、原子的トランザクションの代わりに冪等性DDL操作を使用したサガパターンを使用します。
行レベルのセキュリティレイヤーをどのように設計して、「スーパーテナント」がCPUリソースを枯渇させる完全テーブルスキャンを実行し、サブ秒のSLAに違反しないようにしますか？
候補者はしばしばリソースガバナンスメカニズムを見逃します。解決策は、テナントクラス（プレミアム対スタンダード）ごとの厳格なCPU制限とメモリクォータを持つTrinoのリソースグループを使用した階層的なリソース分離です。Trinoのコストベースの最適化ツールを使用してクエリコストを推定する入場制御を実装しましょう；テナント固有のしきい値を超えるクエリは、実行されるのではなく、キューに入れられたり拒否されたりします。Kubernetesリソースクォータを使用して、クエリエンジンポッドをテナント専用のノードプールに分離し、CPUの枯渇を防ぎます。最後に、予測コストを超える長時間実行されるスキャンのためのクエリキリングポリシーを実装し、一般的な高コスト集約に対する物理化ビューを組み合わせることで、悪意のあるまたは偶発的な完全スキャンであっても、他のテナントのレイテンシに影響を与えられないようにします。