Baiduはテクノロジー企業として、Googleを超えられるか
500億ドル規模の市場をもつBaiduは中国で最も人気のある検索エンジンだが、ただの大手検索エンジンというわけではない。それと同時に、Googleのように、世界で最もイノベーティブなテクノロジー企業の一社という一面も持っている。
またこれもGoogleと同様だが、Baiduも自動運転の乗り物の可能性を追求しており、マシンラーニング、deep translation、映像認識やニューラルネットワークの分野で大規模な研究プロジェクトを計画している。彼らほどの規模のデータを管理できている企業はごくわずかだろう。
このプロジェクトはデータにおける未来を支配できるかどうかを賭けた探求であり、Baiduは世界をリードするビッグデータやクラウドコンピューティングの専門家たちを巻き込み、自社の爆発的な成長をマネジメントし、数えきれない顧客のデマンドや新しいビジネス構想に対応できるインフラを構築している。
ピーク時のトラフィックがI/Oに過大な負荷をかけ、データ階層を圧迫している事をBaiduはよく理解している。だからこそBaiduはバークレー大学 AMPLabから出てきたばかりのオープンソースプロジェクトAlluxio (かつてはTachyonと呼ばれていた)に熱い目を向けている。
Apache Spark(これもAMPLabの出だが)設立のころからの貢献者と共同で作られたAlluxioは、Barclaysのような世界規模の銀行から、Alibabaの様なショッピングサイト、IntelやIBMにいるようなエンジニアや研究者たちといったビッグデータの先端を行く人々から急に注目を集めるようになった。Alluxioはバージョン1.0がリリースされ、ビッグデータアプリとその裏にあるストレージと間にあるプログラム可能なインターフェイスとして機能し、メモリセントリックで強力なパフォーマンスを発揮する。
Baiduのシニアアーキテクト、Shaoshan Liuに、Alluxioの本番稼働させている経験について話を伺った。
ReadWrite(RW): どのような問題を解決しようとしてAlluxioを使いだしたのでしょうか?
Shaoshan Liu(SL): どうすれば我々の規模のデータを管理し、意味のある情報を引き出すことが出来るかという事は常に課題であり、いくつかのクリティカルなクエリのスループットを大幅に改善したいと考えてました。
データ量が膨大なため、各クエリが完了するまでに数十分、あるいは数時間もかかり、プロダクトマネージャは次のクエリを投入する為に何時間も待たなければならないという状況でした。更に腹立たしい事は、クエリを変更するためにはすべてのプロセスを実行しなおす必要があるという点です。
一年ほど前、我々はアドホッククエリを実行するためのエンジンの必要性に気づきました。スペックの概要は次のようなものです。”クエリエンジンはペタバイト規模のデータを管理でき、クエリの95%を30秒以内に処理できること”
そこでクエリエンジンをSpark SQLに切り替えました。使っていくうちにHadoopのマップリデュースよりもレイテンシの面で優位性がある事が分かってきました。我々はSpark SQLによってクエリ時間が平均で数分くらいになるのではないかと大いに
期待しましたが、話は思ってたほどうまくはいきませんでした。Spark SQLによって平均クエリ時間に4倍の改善はあったものの、それでも各クエリを処理するのに10分程度はかかったのです。
調査を進めるうちに問題が見つかりました。まずデータがいくつかのデータセンターに分散されている事から、クエリが遠隔地のデータセンターにあるデータを引っ張ってこようとしている可能性が高く、これがクエリ遅延の最大の要因になっているという事です。これはネットワークの問題です。ですがその解決は、あっちのノードをこっちに持ってくるみたいに簡単な話ではありませんでした。
RW: では解決の突破口とは何だったのですか?
SL: まず高パフォーマンス、高信頼性があり、かつペタバイト規模のデータを管理できるメモリセントリックなレイヤが必要でした。そこでSpark SQLを計算エンジン、Alluxioをメモリセントリックなストレージレイヤとして使うクエリシステムを開発し、1ヶ月ほど負荷テストを行いました。性能は驚くべきものでした。Spark SQL単体ではクエリを処理するのに100~150秒かかっていたのが、Alluxioと合わせて使うと10~15秒に短縮されました。これはローカルおよびリモートのAlluxioノードが混在した時の結果ですが、もしすべてのデータがローカルノードにあった場合、これは5秒まで縮まります。性能の向上は30倍です。この性能結果と信頼性に確信を得て、AlluxioとSpark SQLを使ったフルサイズのシステムを構築しました。
RW: そのシステムは現場でのパフォーマンスはどのようなものでしたか?
SL:システムを導入してBaiduでは典型的なクエリを使った性能計測を行いました。まず元々使ってたHiveでは1000秒以上、Spark SQL単体での計測は300秒でした。しかしAlluxioとSpark SQLを組み合わせたものの場合、約10秒で処理が終わりました。達成できた性能向上は100倍であり、プロジェクト目標に掲げていた要件をクリアするものでした。
去年、このシステムは200ノード以上の構成のクラスタに導入され、Alluxioがもつ先進的な機能(Tiered Storage)によって2ペタバイトもの容量が管理されています。Tiered Storageではストレージヒエラルキーを活用する事が出来ます。例えばメモリがヒエラルキーのトップ、その次がSSD、一番下がHDDという具合です。これら3つの媒体が合わさる事で2ペタバイトのストレージ容量を提供することが出来てます。
性能改善の他により大事な点として信頼性の問題が挙げられます。去年のAlluxioはデータインフラの中において安定して稼働しており、問題が起こったことはほぼありませんでした。この事は我々に自信を与えてくれます。
ちょうど今、より大規模な環境へのAlluxioの導入準備を進めているところです。手始めに1000ノードのAlluxioが稼働するクラスターを構築してそのスケーラビリティを実証しました。ここ数カ月、この50TBのRAM容量を持つクラスターは安定稼働してます。我々が知る限りこれは世界一大規模なAlluxioクラスターです。
グローバルで拡大し続けるGoogle、一方Baiduは中国ローカル市場にフォーカスしたところで牙城を築いているが、今後Baiduはどのように進化を遂げるのだろうか。
ReadWriteJapan編集部
[原文]
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- Azure Data Explorerができることを理解する
- Azure Data Explorerと各社のビックデータ分析サービスを比較する
- ビッグデータを並列処理するクラスタコンピューティングフレームワーク「Apache Spark 2.0」リリース
- PingCAP CEOのMax Liu、米HTAP Summit 2022でHTAP登場の背景を語る
- OSS:2016年の振り返りと2017年への展望
- ビッグデータ分析で効果を発揮するAzure Data Explorerとは
- KubeCon EU 2022からバッチシステムをKubernetesで実装するVolcanoを紹介
- Apache Kuduのシステム構成と内部アーキテクチャ
- 分散型データストアApache Kuduの特徴とユースケース
- 感情を数値化するAffectivaとSparkで動くBigDL