Shoeisha Technology Media

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

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

テーマ別に探す

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

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

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ポイントずつ手作業でやることになった。ストリーミングを使ってリアルタイムで可視化できればなお良いと思う」と語り、セッションを閉じた。



関連リンク

著者プロフィール

バックナンバー

連載:DB Press

もっと読む

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