BigQuery Omni を使用してマルチクラウド環境におけるログの取り込みと分析の費用を削減する

※この投稿は米国時間 2024 年 10 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

現在のデータ中心のビジネスでは、企業がさまざまなプラットフォームで数百もの個別のアプリケーションを運用することは珍しくありません。こうしたアプリケーションから生成されるログが膨大な量に及び、ログ分析に大きな課題が生じる場合があります。さらに、マルチクラウド ソリューションを広範に採用すると、精度と検索性を保つのも難しくなります。分散しやすいというログの性質が、有益な分析情報を引き出す妨げになることがあるためです。

BigQuery Omni は、この課題を効果的に解決し、全体的な費用を従来のアプローチよりも削減できるように設計されました。このブログ投稿では、その詳細を説明します。

ログ分析には、以下のようなさまざまなステップがあります。

• ログデータの収集: 組織のインフラストラクチャやアプリケーションからログデータを収集します。そうしたデータを収集する一般的なアプローチは、JSONL ファイル形式を使用し、Google Cloud Storage などのオブジェクト ストレージ アプリケーションに保存することです。マルチクラウド環境では、未加工のログデータをクラウド間で移動させると費用が高くつきます。

• ログデータの正規化: アプリケーションやインフラストラクチャが異なれば、生成される JSONL ファイルも異なります。各ファイルには、作成元のアプリケーションやインフラストラクチャに関連付けられた独自のフィールド セットがあります。データ分析を容易にするために、そうしたさまざまなフィールドを共通のセットに統合すると、データ アナリストが環境全体にわたって効率的かつ包括的に分析することができます。

• インデックス登録とストレージ: 正規化したデータは効率的に保存する必要あります。これはストレージとクエリの費用を削減し、クエリ パフォーマンスを向上させることにつながります。一般的なアプローチは、ログを Parquet のような圧縮されたカラム型ファイル形式で保存することです。

• クエリと可視化: ログデータに含まれる異常、アンチパターン、既知のスレッドを特定するための分析クエリを組織で実行できるようにします。

• データ ライフサイクル: ログデータが古くなると有用性が低下しますが、それでもストレージ費用はかかり続けます。費用を最適化するには、データ ライフサイクル プロセスを確立することが重要です。広く採用されている戦略は、（生成されてから 1 か月がすでに経過している古いログデータをクエリすることはまれであるため）ログを 1 か月後にアーカイブし、1 年後に削除するというものです。このアプローチでは、重要なデータへのアクセスを確保しながら、ストレージ費用を効果的に管理できます。

一般的なアーキテクチャ

マルチクラウド環境でログ分析を実装するために、多くの組織は以下のアーキテクチャを実装しています。

このアーキテクチャには長所と短所があります。

長所: 

• データ ライフサイクル: オブジェクト ストレージ ソリューションの既存の機能を活用してデータ ライフサイクル管理を実装するのは、比較的簡単です。たとえば Cloud Storage では、次のようなデータ ライフサイクル ポリシーを定義できます。（a）1 週間以上経過したオブジェクトを削除する - 収集ステップで入手できる JSONL ファイルの削除に使用できます。（b）1 か月以上経過したオブジェクトをアーカイブする - Parquet ファイルに使用できます。（c）1 年以上経過したオブジェクトを削除する - これも Parquet ファイルに使用できます。

• 下り（外向き）の費用が抑えられる: データをローカルに保存することで、クラウド プロバイダ間で大量の元データを送信する必要がなくなります。

短所:

• ログデータの正規化: さまざまなアプリケーションからログを収集すると、それぞれに対して Apache Spark のワークロードをコーディングし、メンテナンスすることになります。（a）エンジニアが不足し、（b）マイクロサービスの採用が急増している今、そうしたことは避ける方が賢明です。

• クエリ: データをさまざまなクラウド プロバイダに分散すると、分析と可視化の能力が大幅に低下します。

• クエリ: データ ライフサイクルの初期に作成されたアーカイブ ファイルを除外するのは簡単なことではなく、これを除外すると、アーカイブ ファイルを含むパーティションを避けるために WHERE 句を使用したときに、ヒューマン エラーを引き起こしやすくなります。解決策としては、Iceberg テーブルを使用し、必要に応じてパーティションを追加および削除することでテーブルのマニフェストを管理することが挙げられます。ただし、Iceberg テーブルのマニフェストを手動で操作するのは複雑であり、サードパーティ ソリューションを使用すると費用が増加するばかりです。

改善したアーキテクチャ

こうした要因を踏まえて練り直した解決案は、以下のようなアーキテクチャになります。つまり、BigQuery Omni を使用してこれらすべての問題に対処することになります。

このアプローチの主な利点は、さまざまな Spark ワークロードと、そのコーディングやメンテナンスを行うソフトウェア エンジニアが不要になることです。別の利点は、ストレージと可視化を除き、プロセス全体を 1 つのプロダクト（BigQuery）で処理できることです。費用削減に関連する利点もあります。それぞれについて以下で詳しく説明します。

正規化プロセスの簡素化

JSONL ファイルを指す外部テーブルを作成し、そのスキーマを自動的に決定する BigQuery の機能は非常に価値があります。この機能は多数のログスキーマ形式を扱う場合に特に便利です。JSONL コンテンツにアクセスするための単純な CREATE TABLE ステートメントを、アプリケーションごとに定義できます。その後、Hive 形式で 1 時間ごとにパーティショニングした圧縮済み Parquet ファイルに JSONL 外部テーブルをエクスポートするよう、BigQuery をスケジュール設定できます。以下のクエリは、1 時間ごとに実行するようスケジュール設定できる EXPORT DATA ステートメントの例です。このクエリの SELECT ステートメントは、直近の 1 時間で取り込まれたログデータのみを取得し、正規化されたフィールドを持つ Parquet ファイルに変換します。

クラウド プロバイダをまたぐ統合クエリプロセス

1 つのデータ ウェアハウス プラットフォームを複数のクラウド プロバイダで横断的に利用できるだけでも、すでにクエリプロセスにメリットがもたらされていますが、BigQuery Omni はクロスクラウド結合も行うことができます。これはログ分析の革新的な機能です。BigQuery Omni が登場する前は、さまざまなクラウド プロバイダのログデータを結合することは困難でした。データ量が多いため、元データを単一のマスター クラウド プロバイダに送信すると多額の下り（外向き）費用が発生します。一方、データの事前処理やフィルタリングを行うと分析のパフォーマンスが低下します。クロスクラウド結合では、複数のクラウドをまたいで単一のクエリを実行し、その結果を分析することができます。

TCO の削減に役立つ

最後に紹介するメリットは、総所有コスト（TCO）の削減に役立つということです。これは、このアーキテクチャの最も重要なメリットと言って差し支えないでしょう。これは 3 つの方法で測定できます。

1. エンジニアリング リソースの削減: このプロセスから Apache Spark をなくすことで 2 つのメリットがもたらされます。まず、ソフトウェア エンジニアが Spark コードの記述やメンテナンスを行わずに済みます。次に、デプロイ プロセスが迅速化し、ログ分析チームが標準 SQL クエリを使用して実施できるようになります。責任共有モデルの PaaS として、BigQuery と BigQuery Omni はそのモデルを AWS と Azure のデータに拡張します。

2. コンピューティング リソースの削減: Apache Spark は必ずしも最も費用対効果の高い環境を提供するとは限りません。Apache Spark ソリューションは、仮想マシン（VM）、Apache Spark プラットフォーム、アプリケーション自体という複数のレイヤで構成されています。一方、BigQuery はスロット（VM ではなく仮想 CPU）を利用します。また、エクスポート プロセス中に C コンパイル コードに変換されるエクスポート クエリでは、この特定のタスクのパフォーマンスが Apache Spark よりも高速になる可能性があります。

3. 下り（外向き）費用の削減: BigQuery Omni では、データをその場で処理し、クロスクラウド結合を通じて結果のみを送信できます。そのため、クラウド プロバイダ間で元データを移動させてデータの全体像を把握する必要がなくなります。

この環境で BigQuery を使用するには

BigQuery では、クエリの実行用に 2 種類のコンピューティング料金モデルが用意されています。

• オンデマンド料金（TiB 単位）- この料金モデルでは、各クエリで処理されたバイト数に基づいて課金されます。1 か月間に処理されたクエリデータのうち、最初の 1 TiB は無料です。ログ分析タスクではデータを大量に消費するため、このモデルを使用することはおすすめしません。

• 容量料金（スロット時間単位）- この料金モデルでは、クエリの実行に使用されたコンピューティング容量に対して課金されます。容量はスロット（仮想 CPU）単位で経時的に測定されます。この料金モデルでは BigQuery エディションの料金体系の利点を取り入れており、BigQuery オートスケーラーを使用するか、スロット コミットメント（ワークロードに対して常に利用可能な専用の容量で、オンデマンドより低額）を購入することができます。

Google は実証テストを行い、ログ JSONL データを圧縮 Parquet 形式にエクスポートすることに重点を置いたプロジェクトに対し、100 スロット（ベースライン 0、最大スロット数 100）を割り当てました。この設定により、BigQuery は 100 スロットすべてを消費することなく、1 日あたり 1 PB のデータを処理できました。

このブログ投稿で紹介したアーキテクチャでは、マルチクラウド環境におけるログ分析ワークロードの TCO 削減に対応することを目的とし、Apache Spark アプリケーションを BigQuery Omni 上で動作する SQL クエリで置き換えました。このアプローチは、エンジニアリング、コンピューティング、下り（外向き）の費用の削減に役立つと同時に、全体的な DevOps の複雑性を最小限に抑えることで、独自のデータ環境に価値をもたらします。

ー データ分析エンジニア Rodrigo Vale

ー AppMod カスタマー エンジニア TJ Mai