Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

data tech2015 Winterセミナーレポート クラウディアンが語る、PINGから始めるビッグデータ分析  

edited by DB Online   2016/01/06 12:00

 ビッグデータ分析の醍醐味は、それまで無視されていた些細なデータを大量に集めることで購買などの重要なイベントを予測、そこから得られる知見に基づき好ましい方向に改善させることにある。12月3日に開催された「data tech 2015 Winter」では、クラウディアンのプリンシパル・サポート・エンジニアの佐藤剛宣氏が登壇。PINGやHEADによる死活監視のデータから、サーバの健全性のリアルタイム予測を行い、クラスタレベルや長期のトレンドを分析することで隠されたパターンを発見し、サービスの可用率や品質の向上に繋げる方法を紹介した。

IoT時代の分析基盤とは?

クラウディアン株式会社 エンジニアリング部
プリンシパル・サポート・エンジニア 佐藤 剛宣氏

 クラウディアンは日本生まれでシリコンバレーに本社がある会社で、現在グローバルに展開を進めており、75人の経験豊富な人材が集結している。その中で佐藤剛宣氏は、障害がおこる前に対処するアクティブな製品サポートを実現するため、Hadoop/Sparkに加え、Deep LearningやHTMなどを使い研究、調査を行っている。

 クラウディアンはAmazon S3互換のオブジェクトストレージ「CLOUDIAN HyperStore」をソフトウェアとアプライアンスの両方で提供している。この製品を使うことで、広く公開されているAmazon S3のAPIに準拠した、コスト効率の高いオブジェクトストレージをオンプレミスやプライベートクラウドにおいても利用できるようになる。米国では“S3 YOUR DATACENTER GUARANTEE”という、業界初のS3互換性保証キャンペーンを実施しているほど、高い互換性をウリにしている。

 この製品を採用するパブリッククラウドサービスの事例としては、ニフティ クラウドストレージ、NTTコミュニケーションズのBizホスティング Cloudn Object Storageなどがある。また、直接S3のAPIをエンドユーザーに公開していないが、内部で活用されている事例としては、NTT東日本の「フレッツ・あずけ~る」や石川コンピュータセンターの「BCPリモートバックアップサービス」などがある。

 クラウディアン自身でもCLOUDIAN HyperStoreを利用して「スマートサポート」を提供している。これは顧客の大量のログデータを自動的に収集分析し、顧客の運用効率を飛躍的に向上させるというものだ。

 佐藤氏は、IoT時代の分析基盤には、二つのトレンドがあると思っている。まず自動車やビデオなどによるIoTクライアントのビッグクライアント化がある。そのため、より近いデータセンターにデータをアップロードしたいというニーズにより分析クラスタの広域分散化が、今後ますます求められるようになる。

 広域分散の事例としては、欧州の大手クラウドサービスプロバイダが、CLOUDIAN HyperStoreを採用し、世界14データセンターに“〜10ペタバイト”のデータを分散配置している事例等がある。国内の事例では、大阪大学が中心となって、日米11拠点を相互接続し、災害復旧対策を検証しているプロジェクトがある。

 クラウディアンが行っているビデオ分析のパイロットプロジェクトでは、デジタルサイネージに取り付けられたカメラを使い、Deep Leaningにより物体認識と分類を行っている。たとえば東京で得られた映像データは近くのCLOUDIAN HyperStore にアップロードされる。ビッグクライアント化と広域分散が同時に進行している。

 これらの事例などを捉え、佐藤氏は「IoTが普及すると、世界中にビッグデータが分散する」と見ている。ただ、ビッグデータの移動はネットワークボトルネックのため、事実上不可能だ。そこで、ローカルストレージ上での解析処理をしながらも、ひとつのクラスタを構成することが求められる。

 IoT時代の分析基盤の課題と、それに対応するクラウディアンの製品は以下となる。

IoT時代の分析基盤の課題

PINGの応答時間分析による、クラスタヘルスの視覚化と予測のアイデア

 それでは、上表の「賢い分析タスク実行」とはどういうものか。Spark/Hadoopとどうインテグレーションするのかという話はあるが、まず、どうやってダイナミックにクラスタの状況を数値化できるかが最初の課題になる。

 そのために佐藤氏が最初に挙げるのが、各ノードのサーバーヘルス状況の数値化のためにPINGによるチェックだ。その情報を使い各ノード間にマトリックスを作成し、そこからクラスタの状況を可視化する。通常のトラフィックにはデイリーのパターンがあるので、それを認識し予測する。

 佐藤氏が示したクラスタの可視化のアイデアは、たとえばノードが3台、ABCとあった時、各ノードからそれぞれにリクエストを送る。レスポンスタイムを計測し、それらのマトリックスを作成する。ここで期待するのは、中心から離れるほど負荷が増大することを表現できるかだ。

 テストで使用した環境は、Amazon EC2上のmx4.large6台。リージョンはUS Eastで、ホスト名はcloudian-node1-6だ。使用したトラフィックパターンは、午後1時にピーク、午前1時にアイドルを迎えるもので、3リクエストのPUT/GET/DELETEが主体。毎分単位でTPSが変わり、ある程度のランダム性が含まれるようにした。

 テスト結果だが、まず主にPUT/GETで高負荷時に一定時間、繰り返し応答時間が悪くなることが観測されている。一方、最少レスポンスタイムをグラフにしてみると、今度はDELETEで、日本時間深夜にレスポンスが悪くなることが観測された。 以上の集計は、CLOUDIAN HyperStore S3のアクセスログでrequest info.logをスクリプトによりSparkで処理し、ExcelのPivot Graphで作成されている。

 では、PINGは実際に負荷を反映しているのか。以下の図はCloudian-node1で計測された、送信先ノード別の毎分平均レスポンスタイムの時系列グラフだ。

テスト結果(PINGによるヘルスチェック)

 どの結果からも3つのグループが観測された。自ノード(最速)、Cloudian-node3(遅い)、それ以外。ノード3が遅いのは、データセンターが違う場所にあることが原因と思われる。

 ただこのグラフではスケールが違うため、見にくい。そこでApache Cassandra同様に直近1000サンプルからPHI値を算出してスケールを同じにしたが、トラフィックの変動を吸収してしまった。この手法はスパイクを検知するのには優れているが、ゆるやかな変動には不向きのようだ。

 次にNano秒で観測された値をMicro秒に加工し、そのLog10の値を見たら、スケールが拡大されて見やすくなった。結構ノイズはあるものの、13時にかけてピーク、午前1時にかけてアイドルという傾向が観測できた。

 テスト結果を踏まえて、次に取り組んだのがクラスタの可視化だ。送信先ノード別の平均レスポンスタイムを計測したものをマトリックスにして、各カラム、宛先ごとの平均値と標準偏差を示す。標準化されたデータを使い、KMeansでクラスタリングし、クラスタの中心座標を取得している。そのあとPCAを使い、6次元のベクトルを2次元に圧縮している。

 

テスト結果(クラスタの可視化)

 以上のテストをまとめると、クラスタの中心からの距離で、一般的なレスポンスの性能が分かるだろうということが分かった。クラスタの可視化は、結構できそうだという感じだ。

 ここからはトラフィックパターンの認識と予測がテーマになる。宛先ホスト、時刻、PING応答時間だけの非常にシンプルなデータのため、通常の機械学習ではパターンを認識させることができない。どういうことかというと、通常の機械学習は、{X1、X2、…Xn}からなる変数を与えられることで、それらの相関関係を見つけて、確からしい答えPを返す。今回の例では、こうした変数にあたるものは時刻しかない。そもそも通常の機械学習は、時間の流れという概念を持っていない。

  Deep LearningのLSTMは、オブジェクトトラッキングに応用されるなど、時間の流れを考慮できると言えなくもない。ただ実際の時間の概念、たとえば「今、昼なのか夜なのか、週末なのか」という概念はない。

 そこで今回、PDAで有名なPalm Sourceの創業者のJef Hawkinsが立ち上げたNumentaのAI(HTM)を使ってみた。これは2006年に米国でベスセラーになった『On Intelligence』のコンセプト「人間の大脳新皮質は、絶え間なく予測を行っており、現実の入力との『違い』が検出されたときに、人は注意を向ける」を具体化したものだ。

 特徴としては、過去の膨大なパターンの中から、効率よく関連するパターンを取り出して予測し、予測と実際の差から異常値検出ができる。また時系列データ、位置情報データの両方のパターンに強みを持っている。

 以下の図が結果で、ノード別平均レスポンスタイムを1分ごとに描いているのだが、これを10分ごとにして、今まで2日分のグラフだったのだが、6日分のグラフになっている。

1分ごとのノード別平均レスポンスタイム(μ秒のlog10)から HTMに1ステップ先(10分後)を予測させたもの

 青が実際の値。オレンジがHTMに1ステップ先(10分後)を予測させたものになる。きちんとパターンを認識できていることが分かる。

 続けて佐藤氏は特定の日付、時刻に計測し、同様に予測したデータを示したが、結構、傾向が平均と一緒だった。HTMは突拍子もない予測はしないので、比較しやすくなっている。

10:10予測のクラスタを平均と重ねてlightningで視覚化(青:平均、紫10:10予測)

 これからの分析基盤は、IoTのビッグクライアント化に伴って、広域分散に対応できるかがより重要となってくる。広域分散の環境で、分析タスクを効率よく実行するために、より賢い分析実行が求められる。その賢い実行の解決策として、テストしてみたPINGの応答時間の分析と可視化だが、これに関しては、PINGの応答時間は、おおむねサーバの負荷に比例するといえそう、ということが分かった。

 また、可視化のためにかなり強引にPCAを使って次元圧縮を行ったが、それなりに一貫性が保てそうだ。グラフで、ビデオみたいにストリーミングで見ても、意味があるものになりそうだということが分かってきた。HTMのような時系列パターンを認識できそうなAIを活用することで、より安定した数値化、可視化が実現しそうということも分かった。

 佐藤氏は最後に「せっかくLightningというストリーミングでデータを流してグラフをアップデートできるサーバを使ったのだが、結果的には1ポイントずつ手作業でやることになった。ストリーミングを使ってリアルタイムで可視化できればなお良いと思う」と語り、セッションを閉じた。

関連リンク

著者プロフィール

All contents copyright © 2007-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5