[セッションレポート][DEV303] モダナイゼーションへの迅速な取り組み: コンテナーを使用して次世代のデータ パイプラインを構築する #GoogleCloudNext

2023.08.31

はじめに

Google Cloud Next '23 現地参加組の田中孝明です。

Google Cloud Next はクラスメソッドからは初参加らしいので現地の雰囲気も合わせてお伝えできればと思います。

お知らせ

9/4(月) 帰国後すぐにクラスメソッド日比谷オフィスにて recap イベント開催します。ビアバッシュ交えながら現地の熱狂をお伝えできればと思いますので是非ご参加お願いします。

セッション概要

データはビジネスを推進する燃料です。しかし、企業が収集するデータが増えれば増えるほど、管理が難しくなる可能性があります。コンテナーは、効率的でスケーラブルなデータ処理パイプラインを構築するための強力なツールです。このセッションでは、ストリーミング データ処理、バッチジョブ、オンデマンド データ処理という 3 つの主要なユースケースで Cloud Run を使用する方法を説明します。

セッション動画

セッション内容

オンデマンドデータ処理、バッチデータ処理、ストリーミング処理の3種類のデータ処理について。

オンプレミスのハードウェアから仮想マシン、そしえコンテナ化されたアプリケーションに至るまで、カスクテップでインフラストラクチャが徐々に抽象化される。

2つの非常に重要なことを提供。

ひとつは柔軟性によって、あらゆるフレームワークや言語を利用できるため特定のデータ処理プラットフォームに限定されない。

もうひとつはポータビリティ、コンテナをユースケースに最適なコンピューティングプラットフォームに移動できる。

Cloud Run からはじめて、ローカルディスクへのアクセスが必要になってきたら、同じコンテナを再構築せずに GKE Autopilot に移行できます。

ハイパフォーマンスコンピューティングをサポートする Google Batch も良い選択です。

最高レベルの抽象化製品は Cloud Run です。

Cloud Run はフルマネージドです。

様々なデータ処理のワークロードに最適です。

プロトタイプから本番アプリケーションまでできるだけ早く移行できるようにシンプルさと自動化を念頭に置いて設計されています。

オンデマンドのデータ処理について、これらはデータがありそれをアドホックベースで処理する必要がある。

事業報告書を作成する例、データベースを新しいスキーマに移行する例などがある。

Cloud Run jobs はこれらのケースに合っている。

Cloud Run jobs を bash から起動する例です。

Docker Build や Cloud Build のいずれかでコンテナを作成し、Cloud Run jobs をデプロイして名前をつけ、これを呼び出すことで Cloud Run jobs が作成される。

Cloud Run jobs も Cloud Run と同様にフルマネージドです。一般的なデータストレージソリューションと連携できる。

大量のデータを処理する必要がある場合に大規模な Job が必要になる場合がある。Job は複数のタスクに分割することができ、並列化して実行することもできる。

Cloud Run jobs が最大24時間のタイムアウトをサポートするようになりました。

Jobs の管理について。

Terraform など IaC からのインフラストラクチャーのアプローチ、Config Connector を使い、コンテナの更新を管理する。

Cloud Run jobs を定期的に呼ぶ方法、Cloud Scheduler を使用し、スケジュールされた Jobs を実行する。

連続する各ジョブで条件分岐が必要な場合は Cloud Workflows が適している。

これは Jobs のエラー処理にも、成功したか失敗したかを管理し分岐されるケースに最適。

イベントからペイロードを解析し、Cloud Workflows にイベントの環境変数を渡すこともできる。

プレビューですが、タスクのタイムアウトをオーバーライドできるようになる。間違いで無限ループが発生する際にタイムアウトを設定しておくと便利。

ストリーミングデータを扱う時にプッシュとプルという重要なパラダイムがある。

プッシュベースはキューにイベントをプッシュする。サーバーレスのパイプラインではプッシュベースのモデルが使用されてきた。

プルベースはコンピューティングが常に実行され、キューからタスクをプルするワーカーとなる。

スループットが非常に高く、メッセージの量が多い場合はプルベースの処理を採用する。

プルベースは一度に大量のイベントが発生すると大幅にスケールアップします。

たとえばデータベースに書き込もうとするワーカーを増やさないようにするためにはプルベースの処理を用います。つなげるインスタンスのリソースを制御できる。

Pub/Sub のプルサブスクリプションがある。

Cloud Run の Always CPU をオンにして CPU を常に割り当てる状態にする。 プルベースのワーカーは受信リクエストがないので、常に起動させておく必要がある。

近いうちに CPU使用率に基づいてスケールする機能を公開する予定がある。最小インスタンス数と最大インスタンス数を同じに設定する必要があったが今後は異なる値に設定できる。

できる限り効率的にデータを BigQuery に取り込み、SQLとクエリの高度な機能をしようして 分類情報を生成し処理すること。

ここいは販売データ、製品データ、外部データソース、ログなど様々な種類のデータがたくさんある。最近では毎月 150PB 処理している。

Looker やサードパーティのダッシュボードも使っている。

所感

この公演ではデータ処理用のサーバーレスパイプラインを構築する方法について話されました。プッシュベースとプルベースそれぞれの Cloud Run / Cloud Functions の設定方法や今後のアップデートなども盛り込まれていました。