ReadWrite Japan 第253回

Baiduはテクノロジー企業として、Googleを超えられるか

ReadWrite Japan

2016年2月25日 17:51

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の本番稼働させている経験について話を伺った。

Shaoshan Liu

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編集部
[原文]

この記事のキーワード :

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30