- Glean は Google Cloud Dataflow 上の Apache Beam Streaming を使用して MySQL から大量のドキュメントを効率的に読み取って処理し、コンテンツ、権限、統計情報が常に最新の状態に保たれるようにしています。
- ストリーミングパイプラインのセットアップにより、スケーラブルで費用対効果の高い処理が可能になり、ドキュメントのキャッシュを維持し、データベースを並行して読み取ることにより、1 秒間に数百のドキュメントをシングルコアで処理できます。
- このアプローチにより、Glean はドキュメントがリアルタイムで処理され、変更やドロップされたイベントを処理するために定期的に再処理されるようになり、検索エクスペリエンスが向上しました。
Glean では、毎日何億ものドキュメントをクロールしています。これらのドキュメントがすべてクロールされたら、可能な限り最高の検索体験を提供するために、コンテンツ、権限、統計を最新の状態に保つために、常に解析と処理を行う必要があります。
この目的でバッチジョブを実行するのはコストがかかり、壊れやすく、MySQL との統合も困難でした。しかし、ストリーミングジョブを使用すると、すべてのドキュメントを少なくとも 1 日に 1 回再処理できました。このブログ記事では、Google Cloud Dataflow で Cloud SQL (MySQL) と Apache Beam を使用してこれをどのように実現したかについて説明します。これから説明するパイプラインはすべて、Google Cloud Platform（GCP）上のシングルワーカーのマルチコアセットアップを使用します。これにより、このユースケースには十分な垂直スケーラビリティが得られます。
新しいドキュメントをクロールすると、未加工のコンテンツが MySQL テーブルに書き込まれます。また、新しくクロールされたドキュメントの一意の ID で通知される Pub/Sub キューも管理しています。この文書は、構造化された情報を解析して抽出するために処理する必要があります。構造化された情報は、同じ MySQL テーブルに書き戻され、検索システムによって索引付けされます。Pub/Sub キューは、これがリアルタイムで行われることを保証します。また、Pub/Sub キューによってドロップされたイベントを処理したり、コーパスの経時変化に伴って変化する統計情報を再計算したりするために、ドキュメントを定期的に再処理する必要があります。これは、MySQL テーブルのデータを継続的にスキャンして再処理することで実現されます。このブログ記事の残りの部分では、主にシステムが MySQL からデータを読み込んで処理する方法に焦点を当てます。
MySQL テーブルからドキュメントを読み取るには、ストリーミングパイプラインを使用します。バッチよりもストリーミングを選択した主な要因は、スケーラビリティとコストの 2 つです。コーパスが増え続ける中、毎週のバッチジョブはスケーラブルではなく、ストリーミングパイプラインを使用することで各ドキュメントを少なくとも1日に1回処理できました。このコスト上の利点の大部分は、Pub/Sub キューを処理するためのストリーミングパイプラインをすでに維持する必要があったという事実によるものです。これらのマシンは十分に活用されていなかったため、追加費用なしで MySQL データベースのストリーミングスキャンを実行できました。
ストリーミングパイプライン (図 1 を参照) をセットアップするには、Google Cloud データフローランナーで Apache Beam を使用します。カスタム UnboundedSource を定義します。各インスタンスは、ドキュメントのキャッシュをクエリして処理すべき次のドキュメントを取得するカスタム UnboundedReader を作成します。このドキュメントのキャッシュは、スキャナーオブジェクトの静的インスタンスによって管理されます。使用中のワーカーのコア数に基づいて、このスキャナーによって MySQL テーブルに対して複数の並列データベース読み取りが行われます。これらの読み取りでは、各ドキュメントがコーパスのフルスキャンで最大 1 回処理されるように、ドキュメント ID 順にドキュメントをバッチで取得します。このセットアップにより、1 つのコアで 1 秒あたり数百件のドキュメントを処理できるようになりました (図 2 参照)。
スキャナーはキャッシュの状態 (最後に読み取られたドキュメントの ID、キャッシュに残っているドキュメントの数など) も記録し、これらを使用して追加のドキュメントを取得するタイミングや、コーパスのフルスキャンが完了したかどうかを判断します。その後、状態をリセットし、コーパスのスキャンを最初からやり直します。したがって、これにより、ストリーミングパイプラインのデータキューが無限に設定されます。
この設計と最適化のプロセスにより、小規模のお客様から大規模なお客様まで、スケーラブルで費用対効果の高いサービスを提供することが可能になりました。私たちは、ユーザーが仕事に必要なときに、必要なドキュメントを見つけられるように、常に改善を続けています。
追加の SQL クエリと最適化の詳細については、今後のブログで取り上げる予定ですので、ご期待ください。このブログ記事がおもしろくて、そのようなシステムで働きたいと思ったら、どうぞ 手を差し伸べて!
