こんにちは、エンジニアのYです。Apache Beamに関するカンファレンスであるBeam Summit 2022がアメリカ東部時間の7月18日〜20日にて開催されました。Apache Beamを用いるとデータのバッチ処理およびストリーム処理を実装・実行ができます。今回はBeam Summit 2022の参加レポートとして、セッションを3つピックアップして内容をお伝えします。
Apache Beamとは
公式ドキュメントによると、Apache Beamは次のように説明されています。
Apache Beam is an open-source, unified programming model for batch and streaming data processing pipelines that simplifies large-scale data processing dynamics.
ざっくりと和訳すると、バッチ処理とストリーム処理のデータパイプラインを定義・実行するオープンソースの統合プログラミングモデルと書かれています。統合データプログラミングモデルとは、データパイプラインを定義するプログラミング言語のSDKとRunnerと呼ばれる分散処理バックエンドを合わせたものです。つまり、Apache Beamは単なるライブラリだけでなく、実行環境まで含めたものを指します。
SDKが提供されているプログラミング言語はJava、Python、Goです（2022年7月20時点）。RunnerはApache FlinkやApache Spark、Google CloudのマネジメントサービスであるDataflowなどがあります。Beamはポータビリティを重要視しているため、SDKのパイプラインと独立してRunnerを柔軟に選択できます。
Beamのユースケースの例としては以下のようなものが考えられます。
- ファイルやメッセージブローカーから読み取ったデータのデータウェアハウスへのインポート
- 一定時間で区切ったデータのリアルタイム集計処理
- 機械学習に使用するトレーニングデータの前処理
SprocketにおけるBeamの利用
Sprocketの分析基盤ではデータウェアハウスとしてBigQueryを採用しています。分析対象のデータを加工し、BigQueryへインポートするストリーム処理をBeamにて行なっています。詳しいアーキテクチャなど興味のある方は過去のブログエントリーを参照してください。
Google's investment on Beam, and internal use of Beam at Google
こちらがカンファレンス初日のKeynoteの発表でした。GoogleのBeamへ対する姿勢を紹介するようなタイトルですが、Beamを取り巻く環境について広く述べられていました。Googleが展開しているYouTube、DeepMind、DataplexなどのサービスでもBeamが使用されているようです。登壇者のGoogleに入る前のキャリアがサーカス団の団長とのことで驚きです。
Multi Language Pipeline機能の拡充
BeamのMulti Language Pipeline機能を使用すると、複数の言語によるパイプラインの構築が可能です。例えば、Pythonで書かれたデータの変換処理をJavaで書かれたパイプラインにて呼び出すことができます。Beam自体の開発において、SDK間のポータビリティの充実が重要な側面となっています。このMulti Language Pipeline機能の拡充はポータビリティを向上させる上でキーとなっているとのことでした。
Multi Language Pipeline機能の思想は素晴らしいのですが、いたずらに使用すると複雑さを生んでしまう原因になってしまうリスクも感じました。開発規模が巨大になるとMulti Language Pipeline機能のうまみを享受できるようになるのではないかと考えます。
SDKの開発
BeamのGitHubページを見るとSDKが活発に開発されていることがわかります。直近ではGoのSDKが2022年7月24日にリリースされたバージョン2.40.0にてGAとなりました。また、Java、Python、Goに加え、TypeScriptのSDKも開発中とのことです。Beamをより多くの開発者に利用してもらうため、使用者の多いTypeScriptを選んだとのことでした。
TypeScript SDKの開発はまさかの選択で驚きました。登壇者の方も極めて実験的なプロジェクトと言ってましたので、今後の発展が気になるところです。
チュートリアルの充実
Beamの特徴の1つとして、学習のハードルの高さが挙げられます。そこで、Beam Playgroundが紹介されていました。Beam Playgroundでは環境構築の必要なくブラウザ上でBeamパイプラインを試すことができます。また、2022年末にA Tour of Beamというチュートリアルが出る予定であるとのことでした。A Tour of Goのようにブラウザでコードを書くことができるステップバイステップのプログラムが準備されているようでした。
個人的にはA Tour of Beamの登場に期待しています。現在、新しくジョインしたメンバーへのBeamの研修は主にプロダクションコードをペアプロにて開発するという形で行なっています。A Tour of Beamによって、より体系的にBeamのコーディングを習得できるようになればと考えています。
Optimizing a Dataflow pipeline for cost efficiency: lessons learned at Orange
Google Cloudが提供するBeamのマネジメントサービスであるDataflowのコスト削減方法がOrange Business Servicesという企業の実例を元に紹介されていました。ユースケースはCloud Pub/SubおよびCloud Storageからデータを取得し、BigQueryへパースしたデータをインポートすると言うSprocketと近いものでした。元々、Dataflowを運用する上で5,800,000ドル/年ものコストがかかっていたものを後述の施策の実施で440,000ドル/年に削減できたようです。次章ではOrange Business Servicesが実施したコスト削減の施策を紹介します。
コスト削減のための施策
まず初めに行ったのは、BigQueryへのデータインポートをStreaming APIからStorage Write APIへ変更したことです。Storage Write APIはUSリージョンにおいてStreaming APIに比べてデータ量あたりのコストは半分に設定されています。また、パフォーマンスの面においてもStorage Write APIの使用が推奨されています。ストリーム処理におけるDataflowを使用したBigQueryへのインポートを新しく実装する場合は、Storage Write APIの採用を一番に考えるのが良いとのことでした。本発表ではこのStorage Write APIへの切り替えが最も大きい効果を上げ、最大約68％ものコスト削減ができたようです。前述のようにSprocketが構築しているBeamのストリームシステムでもBigQueryへのインポートを行なっています。インポートにはレガシーなStreaming APIを採用しているため、本発表を受けてStorega Write APIへの切り替えを考えています。
次に行った施策はDataflowの設定のチューニングです。チューニングを行ったのは、Beamが実行されるインスタンスタイプ、使用するスレッド数の調整、Streaming Engineの無効化です。Dataflowジョブで採用されるデフォルトのインスタンスタイプはn1になりますが、より新しいn2のインスタンスタイプを指定していました。設定のチューニングで最も効果が大きかったものは、Streaming Engineの無効化でした。
次に紹介されていたのはBeamパイプラインのコード最適化でした。Beamパイプラインの記述において下記のようなプラクティスが紹介されていました。
- パイプラインの序盤でフィルタ処理を実施
- 複数回使用されるオブジェクトの初期化処理を各ステージで行うのでなく、パイプラインの初期化時に行う。
- GroupByKeyを行う際の各キーの要素数の偏りの排除
これらはどれも納得のいくもので、パイプライン構築時には意識していきたいと考えています。コードの最適化によって削減効果は最大約16％も得られたそうです。
最後に行ったのは、ストリーム処理を行う必要のないケースを洗い出し、バッチ処理に置き換えることでした。ストリーム処理はバッチ処理に比べて、インスタンスが起動し続けることになります。ユースケースを整理し、バッチ処理に置き換えたことで最大約62％もの削減ができたそうです。
Error handling with Apache Beam and Asgarde library
一般的なBeamパイプラインでのエラーハンドリング方法の紹介と登壇者が自作しているエラーハンドリングライブラリの紹介がされていました。Beamパイプラインにて発生したエラーをキャッチした場合、エラーを発生させた要素は外部のファイルやデータベースへの出力が推奨されているとのことでした。パイプライン内において処理が失敗した要素へのタグ付けはTupleTagが便利です。また、exceptionsIntoとexceptionsViaを使用することでわかりやすくエラーハンドリングが記述できます。最後に、これらのエラーハンドリングをより簡潔に記述するために登壇者が開発したAsgardeというJavaのライブラリが紹介されていました。
Sprocketではストリーム処理にて失敗した要素は別のストリームにより処理を行っています。そのため、TupleTagやexceptionInto、exceptionsViaなどを使用して同一ストリームにて処理する形へとコードを修正する予定をしています。
まとめ
Beam Summit 2022の参加レポートとしていくつかのセッションをご紹介しました。Sprocketのエンジニアチームでは使用している技術の将来像やベストプラクティスのキャッチアップに繋がるため、カンファレンスの業務時間内の参加を推奨しています。
Sprocketで働きませんか？
弊社ではカジュアル面談を実施しております。
ご興味を持たれましたら、こちらからご応募お待ちしております。
Discussion