アーキテクチャ: 分析イベントとログの大規模取り込みの最適化

この記事では、Google Cloud で大規模な分析の取り込みを最適化するアーキテクチャについて説明します。この記事では、「大規模」とは 1 秒あたり 100,000 イベントを超える場合、またはイベント ペイロードの総サイズが 1 秒あたり 100 MB を超える場合を指します。

Google Cloud の弾力性のあるスケーラブルなマネージド サービスを利用すると、膨大な量の着信ログや分析イベントを収集して、BigQuery などのデータ ウェアハウスへの入力用に処理できます。

大量の分析データを取り込むためのアーキテクチャでは、ほぼリアルタイムでアクセスする必要があるデータと、短時間の遅延後に処理しても差し支えないデータとを区別して考慮し、それに応じてデータを適切に分割する必要があります。データをセグメント化すると、以下の点で便利です。

  • ログの整合性。完全なログを確認できます。ストリーミング割り当て制限やサンプリングにより、ログが失われることはありません。
  • コスト削減。イベントやログのストリーミング挿入を行うと、バッチジョブを使用して Cloud Storage から挿入する場合よりも高いレートで課金されます。
  • クエリリソースの確保。優先度の低いログをバッチ読み込みに移動することで、これらが予約済みのクエリリソースに影響するのを防ぐことができます。

次のアーキテクチャの図にそのようなシステムを示します。またこの図には、取り込み用のホットパスコールドパスというコンセプトが導入されています。

一般的な取り込み用パス

アーキテクチャの概要

このアーキテクチャでは、以下の 2 つのソースからデータが得られます。

  • 分析イベントは Pub/Sub トピックにパブリッシュされます。
  • ログは、Cloud Logging を使用して収集されます。

いずれかのソースからデータが取り込まれると、メッセージのレイテンシ要件に基づいて、データはホットパスかコールドパスのいずれかに入れられます。ホットパスでは、継続的なデータフローを処理できるストリーミング入力が使用されます。一方、コールドバスはバッチ処理であり、ユーザーが決定したスケジュールに従ってデータが読み込まれます。

ロギング イベント

Cloud Logging を使用して、標準オペレーティング システムのロギング機能で生成されたロギング イベントを取り込むことができます。Cloud Logging は、デフォルトで、標準イメージを含む多数の Compute Engine 環境で使用可能です。また、Cloud Logging エージェントを使用して多数のオペレーティング システムにインストールすることもできます。この Logging エージェントは、App Engine と Google Kubernetes Engine のデフォルト ロギングシンクです。

ホットパス

ホットパス ロギング

ホットパスでは、Cloud Logging シンクでフィルタを指定することで、サービスのモニタリングや分析に必要な重要なログが選別され、複数の BigQuery テーブルにストリーミングされます。ロギングレベル ERRORWARN に別々のテーブルを使用します。容量が多くなることが予想される場合には、サービスごとにさらに分割します。このベスト プラクティスを使用することで、1 テーブル 1 秒あたりの挿入数が 100,000 の上限を超えないようになり、このデータに対するクエリがうまく機能し続けるようになります。

コールドパス

コールドパス ロギング

コールドパスでは、Cloud Storage バケットでポイントされている Cloud Logging シンクを使用して、ほぼリアルタイムの分析が必要のないログが選別されます。ログはバッチ処理され、Cloud Storage の 1 時間ごとのバッチのログファイルに書き込まれます。これらのログは、Cloud Storage の標準のファイル インポート プロセスを使用して BigQuery にバッチ読み込みを行うことができます。これは、Google Cloud Console やコマンドライン インターフェース(CLI)だけでなく、単純なスクリプトを使用して開始することもできます。バッチ読み込みを使用しても、ホットパスのストリーミング取り込みやクエリのパフォーマンスに影響することはありません。トラブルシューティングやレポート生成を簡略化するために、ホットパスのログによって使用されるものと同じテーブルにコールドパスのログを直接マージする方法が、多くの場合適しています。

分析イベント

分析イベントには、Google Cloud 内のアプリサービスで生成されるものと、リモート クライアントから送信されるものがあります。これらの分析イベントを Pub/Sub を介して取り込み、Dataflow で処理すると、低レイテンシでシステムのスループットを高めることができます。分析イベントをホットとコールドでそれぞれ別の Pub/Sub トピックに送信することは可能ですが、まずすべてのイベントを 1 つのトピックに送ってから、ホットパスとコールドパスという別々の Dataflow ジョブを使用してそれぞれを処理する方式を取るべきです。こうすることで、ある分析イベントがたどるパスを変更したい場合に、Dataflow ジョブを更新するだけで対応できるようになります。これは、新しいアプリやクライアント バージョンをデプロイするよりも簡単です。

ホットパス

ホットパス イベント

イベントの中にはすぐに分析する必要のあるものもあります。たとえば、クライアントの不都合な動作や、不具合の要因を示唆するイベントなどです。自動スケーリング Dataflow ジョブを使用してそのようなイベントを Pub/Sub から選別し、BigQuery に直接送信する必要があります。このデータをデータフロー ジョブで分割し、1 テーブルあたり、1 秒間に 100,000 行という上限に到達しないようにすることができます。これにより、クエリのパフォーマンスも適切に保たれます。

コールドパス

コールドパス イベント

すぐにではなく、時間または日単位で追跡および分析する必要のあるイベントは、Dataflow によって Cloud Storage 上のオブジェクトに push することができます。Cloud Console、gcloud コマンドライン ツール、あるいは簡単なスクリプトを使用して、Cloud Storage から BigQuery への読み込みを開始できます。ホットパスのイベントと同じテーブルにそれらをマージできます。コールドパスのロギングと同様に、分析イベントのバッチ読み込みは予約されたクエリリソースに影響を及ぼすことはなく、ストリーミング取り込みパスの負荷は適度に保たれます。

BigQuery へのデータの読み込みの詳細については、データの読み込みの概要をご覧ください。

次のステップ