というわけで、秋の出張第1弾はおなじみOracle OpenWorld 2012です。筆者は実に4年ぶりに取材チームに混ぜていただきました。4年前の2008年といえばちょうどExadataがはじめて発表されたときでもあります。あのころのオラクルはまだサンを買収していなくて、ExadataもHPがハード提供してたし、社長はマーク・ハードではなくチャールズ・フィリップだったし、そういやマーク・ハードはHPの社長としてビデオでラリー・エリソンのキーノートに登場していたんだよなー……としみじみ。変化の速いIT業界のこと、そりゃ4年も経てばまったく違う世界になりますよね。
OOW 2012のキーノートのもようなどは、すでに谷川チーフが何本か書かれているのでそちらをご覧いただくとして、ワタクシからは現地で発表が行われたNTTドコモのOracle CEPによるスマホのトラフィックデータ分析のシステム構築事例をご紹介したいと思います。いわゆるビッグデータ分析というとインフラではなくマーケの話になりやすい昨今ですが、この事例は超膨大なデータ量、それもものすごい頻度で発生するトラフィックを安定した品質でリアルタイム処理するミドルウェアに落としこむというもので、オラクルの担当者によれば世界的にもかなりレアなビッグデータ×インフラ事例とのこと。本稿ではNTTドコモ サービスプラットフォーム部 開発企画 担当部長 高橋慎一郎氏に伺ったお話をもとに、その概要をお伝えします。
スマホユーザが5,000万を超えても耐えられるトラフィック処理システムを構築
サービスプラットフォーム部 開発企画 担当部長
高橋慎一郎氏
筆者の周りではすっかりガラケーユーザを見なくなったのですが、スマホユーザの数が伸びるのはこれからが本番のようです。高橋氏のお話によれば、現在、ドコモの契約回線数6,000万のうち、約1,400万をスマホが占めており、さらにこの比率は増えていく傾向にあるとのこと。そして、通信事業者として国内トップを走り続けるドコモにとっては、たとえどんなにユーザ数が増え、トラフィック量が膨大になろうとも、安全で可用性の高い通信網の死守は至上命題というわけです。今年前半、たびたび耳にしたドコモの通信障害のニュース、ああいったトラブルは"ドコモ品質＝日本のインフラ品質"を掲げてビジネスをしている以上、本来はぜったいあってはならないわけですが、やはりスマホユーザの劇的な伸びに対応できなかったことが大きな要因のようです。
スマホのインフラ拡大に向けて継続的な投資を約束しているドコモですが、ドコモ品質を維持するには、増え続けるトラフィックの安全で確実で迅速な処理が欠かせません。とくに今後は、どんな特殊な事情が生じて一時的にトラフィックが集中しようとも、「つながらない」はもちろん「つながりにくい」も避けなくてはならない。そのためには現在、スマホのトラフィックがどこから発信されて、どこにつながろうとしているのか、ゲームサイトなのか、コンテンツストアなのか、それとも特定のWebサイトなのか、そのデータを漏れなく収集し、正しく分析する必要があります。つまりトラフィックの傾向を確実に把握することが、スマホにおいてもドコモ品質を維持し、高めていくための第一歩となるといえます。「スマホのトラフィック分析が難しいのは、その数だけでなく、ユーザがこれまでの携帯電話とは違ったサービスの使い方をするから。たとえばゲームであれば、従来は秒間10回だった入力が20回に増える」と高橋氏。電話とPCが融合した、スマートフォンならではの使い方、たとえば写真を撮ってソーシャルメディアにアップし、コメントをつけて共有する。このストリームがある時間帯に数万人、あるいは数十万人単位で集中したとき、トラフィックをさばききれるだけの処理能力をready状態にしておくことがいかに難しいか、門外漢の筆者でもなんとなく想像できます。
もちろん、ドコモではトラフィックデータの収集/分析は以前から行っていましたが、スマホの急激な普及にインフラが追いつかなくなっていることを強く認識し始めたのは「(スマホの契約数が)60万ユーザくらいになってから」だと高橋氏は振り返ります。処理能力だけでなく、コスト的にも従来アーキテクチャ(Sunマシンだったそうです)では高くつきすぎて、とても継続的なユーザ増加に耐えられそうもありませんでした。そこで「少なくともスマホユーザが4,000万ユーザまでなら楽勝で、5,000万を超えても耐えられるトラフィック処理システム(ストリーム処理サーバ)を構築する」ことを目標に製品の選定を開始したそうです。
ここで高橋氏は、このシステムにおける3つのチャレンジ項目を示してくれました。
- Big & Fast Data … 1,400万ユーザ、秒間70万トラフィックという膨大なストリームデータ
- No Data Loss … データロスを限りなくゼロにするためにインメモリで
- Scalability & Flexibility … ユーザの継続的増加とリアルタイムサービスへの対応
これらの条件を満たす製品として検討を重ねた結果、オラクルのCEPソリューション「Oracle Event Processing(以下、CEP)」と同じくオラクルのインメモリグリッドである「Oracle Coherence」が採用されました。高橋氏はこれらのミドルウェアを選択したことについて、「2つの製品の親和性が非常に高く、エンジンが高スループットに最適化されている。ユーザの増加に応じて、"横に並べて"システムを拡張することができ、しかもパフォーマンスが落ちない。アプリケーションの冗長性はCEPで、データアクセスの可用性はCoherenceでそれぞれ担保することで、発生し続ける膨大なストリームデータを継続処理できる。また、アプリケーション構築に必要な開発フレームワークの自由度が高いため、柔軟なチューニングがしやすい」と語っています。ストリーミングデータをインメモリで利用できるので、トラフィックの傾向変化への対応が劇的に改善されただけでなく、コスト面でも「従来の半分に削減」(高橋氏)できたといいます。
このシステムでは、トラフィックソースからWebアクセスデータを取得すると、CEP上でデータマッチングおよびデータ加工がマルチスレッドで行われます。CoherenceはCEPとシームレスに連携を取りながら、ユーザ属性割当サーバから取得したデータへの大容量インメモリにおける高速アクセスを可能にします。ストリーム処理サーバで出力されたデータはHadoop(Apache Hadoop)によるバッチ処理システムと連携しています。なお、高橋氏によれば本システムは「Linux上で構築されており、CEPとCoherenceは同じ筐体に置いているがインスタンスは別々」とのことです。
