なお、「SoftLayer」のリセラーであるエフ・アイ・ティー・パシフィック社が、同ソリューションを組み込んだコードネームと同名の「Loogle」という製品を提供しており、本検証はこの製品がクラウド上で十分に利用できるかを確かめるために実施しました。
ログ解析ソリューション「Loogle」を開発した経緯
SoftLayer上での検証について説明する前に、まずは、Loogleという製品を簡単に紹介します。私は、理化学研究所の情報基盤センターに所属し、所内のネットワークの設計や運用、管理を15年ほど担当していました。運用は外部に委託していましたが、突然発生する障害に内部で対応しなければならないことも度々ありました。
障害が発生すると、障害の原因解明や問題解決の手掛かりを得るために、機器のログを解析するわけですが、大量のログをさまざまな視点で見ていくのは労力と時間が掛かり、たいへん苦痛でした。そこで、ログを解析するソフトの購入を検討しました。
市販ソフトはたくさんあり、いろいろとテストをしてみました。しかしながら、使い勝手が悪い、扱えるログの種類や検索できる項目が決められて自由度が低く、エンジニアの職人技が活かせない、あるいは機能は優れているが桁違いに高額であるなど、満足のいく市販ソフトは見つかりませんでした。
大量のログから、簡単かつ高速で必要な情報を検索し解析したいと考え、開発したのが“Loogle”です。“Loogle”は、思い付いたキーワードで検索ができること、大量のログが対象でも検索できること、検索を実行したら、数秒以内で解析できることに重点を置き、レポート機能を搭載せず、高速検索に特化して開発したログ解析ソリューションです。
検証にあたって、SoftLayerについての知識がまったくありませんでしたので、「目的を設定して使ってみる」のが早道と考え、まずは、LoogleがSoftLayer上で、どの程度スケーラブルに動作するのかを検証しました。これまで、Loogleをクラウド上で試したことがなかったため、たいへん興味深い検証になりました。
「Loogle」の特徴
Loogleは、アプリケーション（フレームワーク）で、少規模から大規模のログ解析を実施する基礎となるように設計されています。一口にログ解析と言っても形態はさまざまなのですが、Loogleは蓄えたSyslog的ログファイルを自由なキーワードで検索できます。大容量ログを高速に検索できるため、相関解析などが比較的容易に行えます。また、テンプレート方式の製品と異なり、テンプレートを作るごとにコストが掛からないため、必要になった時に解析したりアプリを作成すれば良いのも利点です。
仕組み的には、ログファイル専用の独自DBがコアであり、一種のNoSQL的なものと言っても間違いないと思います。このDBは、インデックス作成に一番コストが掛かり、今回の実験はそこに重点を置いて検証を実施しました。
SoftLayerは、I/O転送およびデータセンター間のデータ転送が無料で、仮想サーバーだけでなく、専有の物理サーバーが利用でき、CPU、GPUやストレージなど、豊富な選択肢が用意されています。
検証方針
今回の検証では、時間やリソース等のさまざまな制限がありました。特に、計算リソースについては、できれば専有サーバーを1000台程度使用したかったのですが（笑）、コストの関係もあり、限られたリソースでの検証となりました（Loogleはディスク依存度が高く、SSDやRAIDなどを専用ハードウェアで動作させればとても早くなります）。そこで、仮想サーバーとベアメタル（物理）サーバーの2形態で、2～3TBのSyslogファイルを転送し、インデックスを作成することにしました。
SoftLayerは、現時点では日本国内にデータセンターがありません。そこで、日本での利用を想定し、データの転送スピードが最も早かったサンノゼ（San Jose）のデータセンターへ、対象となるログを日本から転送して検証しました。
検証内容
SoftLayerのCCI（Cloudlayer Computing Instance）とBMC（Bare Metal Cloud）を使用して、Loogleによるベンチマーク試験を行いました。
ベンチマーク試験の方法は、次のとおりです。まず、日本にあるサーバーから、ログファイルを生成しつつサンノゼにあるCCI/BMCへ転送後、インデックス化を行いました。なお、Loogleはファイルの増加に追従するリアルタイムのインデックスには未対応であるため、5GBのログファイルの転送が終わり次第、インデックス化するバッチ処理を行いました。その際、インデックス化と転送に掛かった合計時間を計測しました。
検証1（CCIを使用）
まずはじめに、下記スペックのPrivate CCIを20台注文して試験環境を構築しました。CCIには、PublicとPrivateの2種類があります。PublicはCPUが他CCIと共有されますが、PrivateはCPUを占有することができます。本試験では、他のCCIからのCPUの影響を避けるため、Private CCIを使用しましたが、Public CCIを用いた場合は、この結果より遅くなる可能性があります。
- OS：Ubuntu 12.04-64 Minimal
- RAM：8GB
- Processor：8 CORE
- DISK：Local 100GB + Local 300GB
CPUは“E5-2650”（/proc/cpuinfoから情報を入手）で、追加のローカルディスク（300GB）のすべてをLoogleで利用することにしました。Loogleはログファイルの約2.5倍のディスク容量を消費するため、1台あたりで処理するログファイル量は100GBに設定しました。前述の方法でベンチマーク試験を行った結果、個々の処理時間はまちまちでした。
最短時間は、インデックス化に7時間13分37秒、全体の処理に7時間35分23秒。最長時間は、インデックス化に14時間40分17秒、全体の処理に15時間8分36秒でした。最短時間と最長時間では、実に倍の差となりました。同一スペックのCCIであるにもかかわらず、ここまで差が生じたのは、同じホストを共有している他のCCIのディスクアクセスの大小によるものだと思われます。およそ倍の差があることから、作成したCCIが同一ホストを共有し、お互いにディスクアクセスで干渉し合った可能性も高いと思われます。
なお、処理時間の平均時間は、インデックス化に9時間51分51秒、全体の処理に10時間26分3秒でしたが、実際にインデックス化が終了するためには、すべてのCCIで処理が終わる必要がありますので、いくら早く終わったCCIがあったとしても、最終的には一番遅いCCIに引きずられる結果です。つまり、本試験で処理したログファイル容量は2TBですが、最長の総合時間が15時間8分36秒であったことから、20台のCCIを使用して1日でインデックス化することができるログファイルの容量は約3.17TBと推定されます。
検証2（BMCを使用）
次に、下記スペックのBMCを20台注文して試験環境を構築しました。
- OS：Ubuntu 12.04-64 Minimal
- RAM：2GB
- Processor：2 CORE
- DISK：Local 500GB
実際に割り当てられたBMCのスペックは、下記のとおりでした。
- OS：Ubuntu 12.04.2-64 Minimal
- RAM：2x4GB Kingston 4GB DDR3 2Rx8
- Processor：3.4GHz Intel Xeon-SandyBridge E31270
注文したスペックよりも、メモリは6GB増え、CPUは2コア増え（合計で8スレッド）、非常にお得感がありました。なお、このBMCのスペックはあらかじめ分かっていたため、前述のCCIのスペックをこのスペックに近づけています。ただし、Loogleはマルチスレッドプログラムではないため、結果としてCPUが処理できるスレッド数は影響がないと考えられます。BMCはローカルディスクで500GBを使用できたため、ログファイル容量を170GB（5GB×34個）としました。
CCIと同様にベンチマーク試験を行った結果、個々の処理時間は僅差でした。
最短時間は、インデックス化に9時間54分35秒、全体の処理に10時間2分46秒。最長時間は、インデックス化に10時間19分7秒、総合時間は10時間26分43秒でした。CCIでは最短と最長で2倍もの差が出ましたが、BMCでは20分強の差でした。CCIと異なり、BMCは1台のリソースをすべて占有することができるため、他からの干渉を受けずに安定していることが分かりました。
本試験で処理したログファイル容量は3.4TB、最長の総合時間が10時間26分43秒であったことから、20台のBMCを使用して1日でインデックス化することができるログファイルの容量は約7.81TBであり、CCIと比べると2.45倍のログファイルを処理できました。すべてのBMCでほぼ同時にインデックス化が完了するため、処理時間に無駄がなく、CPUのスペックが異なっていることを考慮しても、CCIと比べて高速に処理できたと言えます。
本試験で使用したCCIは1台1時間あたり$0.88、BMCは1台1時間あたり$0.54で、価格の面でも有利でした。
検証を終えて
これまで、大容量のログを解析するLoogleは、クラウドでの使用には適さないと考えていましたが、SoftLayer上で動作検証を行った結果、BMCをうまく活用すれば、十分に利用できるというのが、今回の検証を通して分かりました。SoftLayerのサンノゼのデータセンターへ3.4TBのログを転送し、10時間26分43秒でインデックスを作成し解析することができました。月間では234TB相当のログ量であり、おそらく、多くの企業ではこの程度の処理ができれば十分であると思われます。
当初、国内にデータセンターがないことが効率に影響するのではないかと懸念しましたが、転送時間は結果にさほど影響しませんでした。データ転送に関しては、国内にデータセンターがなくても、多くのケースでは十分に対応できるのではないかと思います。
また、Loogleをクラウド用に特別にチューニングしなくても、BMCで効果的に動作したことから、SoftLayerはディスク依存度が高いオンプレミス的なアプリケーションをそのまま動作させるのに適したサービスだと思います。
社内アプリケーションのほとんどがこの範疇に属することから、有効性を評価しても良いのではないでしょうか。
今回は利用しませんでしたが、データセンター間の転送量が無料であることはディザスターリカバリーなどに有効だとすぐ思い付きますし、将来的に国内データセンターが開設されるようになれば、さらに用途が広がるのではないかと思われます（※1）。
SoftLayerは、日本では後発のクラウドサービスですが、その特徴を活用すれば十分に選択する価値があるサービスである、というのが今回の検証結果を踏まえた私の考えです。
こちらのムービーもご覧ください。
補足資料／「SoftLayer」のインスタンスの検証
今回、LoogleをSoftLayer上で検証するにあたり、あらかじめ「SoftLayer」のComputing InstanceとBare Metal Instance、2つのインスタンスの動作を検証しました。参考までに補足資料としてその詳細を記しておきます。
それぞれ、「SoftLayer」のWebポータル画面で、Salesメニューの「Add Hourly Computing Instance」と「Add Hourly Bare Metal Instance」から注文しました。
注文したサーバーのスペックは次のとおりです。
| 項目 | 値 |
|---|---|
| Data Center | San Jose |
| CPU | 2.0GHz x 4cores |
| RAM | 16GB |
| Operating System | Ubuntu Linux 12.04 LTS Minimal Install |
| Storage | 1TB（SAS） |
| Networking | 100Mbps Public&Private Networks |
| 項目 | 値 |
|---|---|
| Data Center | San Jose |
| CPU | 2.0GHz x 4cores |
| RAM | 16GB |
| Operating System | Ubuntu Linux 12.04 LTS Minimal Install |
| Storage | 500GB SATA |
| Networking | 100Mbps Public&Private Networks |
「SoftLayer」は、注文後、サーバーを2～4時間で利用開始できると案内しています。
今回注文した10台のComputing Instanceは、利用開始できる時間がそれぞれ異なりました。10分～15分後に利用開始できるようになったサーバーもあれば、2～3時間掛かったサーバーもありました。すべてのサーバーを短期間ですぐに利用したい場合には、少し不便な感じがします。Computing Instanceの注文から利用開始までの時間にバラツキは見られましたが、結果的には、「SoftLayer」が案内している時間内で、すべてのサーバーの利用が開始できました。
続いて2台のBare Metal Instanceを注文しました。Bare Metal Instanceは物理サーバーなので、サーバーのセットアップなどの作業は、仮想サーバーのComputing Instanceより時間が掛かると考えていました。結果的には、注文から3～4時間後にサーバーが利用開始できました。
サーバーの作成と設定作業の完了後、登録したメールアドレスにメールが届きましたので、早速サーバーにログインしてみました。SSHでIPアドレスを指定して各サーバーにログインし、実際のサーバーのスペックを確認し、注文時のスペック（今回は、主にCPUとネットワーク）と比べました。
| 項目 | 注文時 | 実際のスペックと測定値 |
|---|---|---|
| CPU | 2.0GHz x 7台 | Intel（R）Xeon（R）CPU E5-2650 0 @ 2.00GHz x 6台 |
| Intel（R）Xeon（R）CPU E5-2650 v2 @ 2.60GHz x 4台 | ||
|
NetWork RTT （※3） |
- | 126ms x 4台 |
| 141ms x 6台 |
| 項目 | 注文時 | 実際のスペックと測定値 |
|---|---|---|
| CPU | 2.0GHz x 2台 | Intel（R）Xeon（R）CPU E31270 @ 3.40GHz |
| Intel（R）Xeon（R）CPU E5-2650 v2 @ 2.60GHz | ||
|
NetWork RTT （※3） |
- | 128ms x 1台 |
| 140ms x 1台 |
表3、表4から分かるように、納入した実際のサーバーのスペックには、バラツキが見られます。CPUのタイプも、クロック数が若干変わっていました。特にBare Metal InstanceのCPUクロック数は2倍弱に増えていました。Computing InstanceとBare Metal Instanceの両方共、注文時のスペックより多めに増えており、サーバースペックの固定が必要な場合を除いては、利用者にメリットがあります。ネットワークについては、それぞれのサーバーにpingしてRTT（※3 RTT：Round Trip Time）を測ってみました。遠隔の同じデータセンター内にあるサーバーへの通信スピードが若干変わっていることが分かりました。
続いて、動作中のサーバースペックの変更を追加で注文しました。今回作成された10台のComputing Instanceのうち、1台のサーバーのNIC（ネットワークカード）の速度変更とHDDの追加をしました。Webポータル画面で、Computing Instancesの一覧から1台のサーバーを選択し、Computing Instance View画面のResources項目でDisk Space Upgrade、Network項目でPort Speed Upgradeを実行しました。「SoftLayer」では、スペックの変更を注文すると、対象のサーバーに即反映されます。早速、サーバーにログインして確認してみましたところ、追加で注文したHDDが自動的にサーバーに追加されておらず、結局手動で注文したHDDをサーバーにマウントする必要があり、この点が少し不便なところでした。
NICの速度を1Gbpsに変更したことをethtoolで確認したところ、ネットワーク速度の情報が出ておらず、NICが確実に1Gbpsに変更されたかどうかの確認ができませんでした。「SoftLayer」のオンラインサポートに問い合わせした後、担当者がサーバーにログインして状況の確認と原因の調査をしましたが、原因は不明でした。そこで、ファイル転送でスピードを測る代替案を担当者が提案してくれました。
「SoftLayer」のサーバーの運用サポートツールは少ない感じがしますが、オンラインサポートの担当者の対応が良く、とても便利でした。
