OpenStackの弱点、大量のログ発生問題を解決するNECネッツエスアイの取り組み

企業がプライベートクラウドを構築する際にOpenStackを選択することは、現時点ではかなり有力な選択肢だ。OpenStackはオープンソースソフトウェアであり、非常に多くのコンポーネントによって構成される「クラウドコンピューティングのオペレーティングシステム」とも言える複雑なソフトウェア群である。実際に運用を行っている企業に話を聞くと、その効果を評価する反面、まだ成熟していない部分も多々あるという。その中でも特に多い不満の一つが、ログの処理である。

ログは、それぞれのコンポーネントがエラーやウォーニングを管理者に知らせるという意味では当然必要なものだが、それがあまりに大量に発生してしまうと、「エラーを検知する」という本来の目的を達成できなくなってしまう。OpenStackの場合、開発しているエンジニアはそれぞれ所属も違えば、バックグラウンドも違うため、統一したログフォーマットが実現されていない。また、一日で100GBにも達するログデータの処理を目の当たりにして、運用の見直しを迫られるなどの弊害が出ているのが現実だ。

今回、そのようなログの分析とシステムの監視についてNECグループのシステムインテグレーター、NECネッツエスアイ株式会社のエンジニアが取り組んだプロジェクトについてインタビューを行った。

インタビューに応えてくれたのは、NECネッツエスアイ株式会社キャリア・パブリックソリューション事業本部パブリックソリューション事業部第四サービス部の畠泰三氏。それに、このプロジェクトが始まるに当たって牽引役としての役割を担った、NECネッツエスアイ株式会社パブリックソリューション事業部担当課長の中村雄二氏に話をきいた。

NECネッツエスアイの畠氏

まず、このプロジェクトに関して概要を教えてください。

畠：これはNECネッツエスアイと日本仮想化技術株式会社のパートナーのプロジェクトとして始まったもので、OpenStackの運用に際してログの管理と分析、それに監視の部分をもっと使いやすくしようということで始まりました。実際には、私が仮想化技術さんのオフィスで仮想化技術さんのプロジェクトの中に入って働くことで、OpenStack自体の知識と経験を深めようという取り組みですね。

実際にOpenStackのログの処理や監視の部分に問題がある、ということに着目してプロジェクトを始められたと思いますが、オープンソースとして他にソリューションはなかったんですか？

畠：OpenStack Foundationのサイトにはログに関する情報はありましたが、それをどうやって分析するのか、どうやって可視化するのか、といったような「考え方」のようなものはありませんでした。また、CanonicalやRed Hatのサイトをみてもそういう部分の情報はなかったので、これはやるしかないなと。実際にOpenStackを運用している企業、例えばドコモさんなどは、ちゃんとログ分析と監視をやっていると思うんですが、なかなかそのノウハウが公開されないんですね。なので、このプロジェクトは最初から公開するつもりで始めました。

これって通常のITシステムを運用している企業だと、ログ分析と監視はできて当たり前だと思うんですね。でもOpenStackだとその辺がなんかいい加減というか、ちょっと感覚が違うと言うか。

そういう意味で言えば、これからOpenStackを始めようとする企業にとってOpenStackに対する不満というか不具合の部分を少しでもなくそう、という意図があったということですね。

畠：そうですね。

今回のログ分析と可視化の部分に関して言えば、FluentdとElasticSearch、それにKibanaというログを処理する時にはよく聞く名前が出てきます。

畠：そうです。でも実際に様々なコンポーネントが吐き出すログをFluentdの正規表現でフィルターしようとすると、全てのメッセージに対してやることになりますが、それは現実的ではないと思います。なのでメッセージにタグを付けて、ブラックリストとホワイトリストとしてフィルターするという部分が、今回のソリューションの差別化の部分になります。

もうGitHubに公開してしばらく時間が経ってますが、今の状況はどんな感じですか？

畠：既にOpenStackを検討しているというお客様に、何度か説明に行ったりしています。直近でやらないといけないということはOpenStackの最新バージョンであるMitakaに対応するということですね。あとは、もっと皆さんに使ってもらってフィードバックが欲しいと思っていますので、どんどん使ってもらえるようにしたいと思っています。

ところでこれには何か名前が付いているんですか？

畠：え～と、GitHubの上ではOpsManagerという名前が付いています。

なんかあまりにマジメというかヒネリがないというか（笑）

畠：ええ（笑）　でもちょっと変わった名前にしようかなと思っていた時に、後ろの方の席から「変な名前は付けるな」っていう大合唱が聞こえてきまして（笑）

お察しします（笑）　では今後もこのソフトを進化させていくと。オープンソースソフトウェアらしく外部のエンジニアのコントリビューション、例えば海外のエンジニアとの協業みたいなものも考えているんですか？

畠：そうですね。そうできるといいと思います。それは今、日本仮想化技術さんとブロードバンドタワーさん、ミラクル・リナックスさんなどと一緒にやっている共同検証ラボとも同じ発想でやれると思うんですよね。海外の人と一緒にやるためには、もう少し英語ができるようにならないといけないとは思っていますけど（笑）

なお、今回のプロジェクトに関する畠氏のプレゼンテーションは以下を参照してほしい。

【OpenStack共同検証ラボ】OpenStack監視・ログ分析基盤の作り方 - OpenStack最新情報セミナー（2016年7月）

http://www.slideshare.net/VirtualTech-JP/openstackopenstack-openstack20167

次に、今回のNECネッツエスアイと日本仮想化技術株式会社との橋渡しを行った中村雄二氏とのインタビューを紹介しよう。中村氏はNECネッツエスアイの北米駐在員として、しばらくシリコンバレーなどで活躍をしていた人物だ。

NECネッツエスアイの中村氏

もともとNECネッツエスアイと仮想化技術株式会社とのコラボレーションが実現するに際しては、中村さんが言い出しっぺというか黒幕だったということを畠さんから伺っていますが。

中村：まぁ、黒幕とまでは言いませんが、そうですね（苦笑）　ちょっと前までアメリカにいた時のことですが、大企業が新しいことに取り組む際には全部自社でやらずに、外部の技術とかノウハウを利用するのが常識である、という状況を見聞きしていました。なので、今回のこともその発想です。現実的には事業部長がOKを出してくれたので、できたことですが、それも理詰めで説得したというよりも勢いで賛成してもらったという感じです。

そういうことができるのも、NECネッツエスアイがNEC本体とは別にかなり自由に動けるということが前提としてあるんですね。OpenStackに関してもNECとしてはRed HatのOpenStackをビジネスとして展開していますが、お客様からのリクエストとしてCanonicalのOpenStackやLinuxに関するシステムのニーズが出てきているのは分かっていたので、それを取りこぼさないようにしようということで、NECネッツエスアイとしてはCanonicalのOpenStackを推しています。OpenStackのサポートの部分でCanonicalと協業できているのはいいことだと思います。事実、案件の現場でも役に立っていますし。

勢いで事業部長を説得ですか！　会社に入って6年ぐらいの中堅どころでデキのいいエンジニア（畠泰三氏）を外に出すというのは、NECグループとしてはなかなかできない選択肢ですよね？

中村：そうですね。ちなみにOpenStackのビジネスをNECネッツエスアイとして推進するにあたっては、ちゃんとしたビジネスプランを書きましたよ（笑）　そこは勢いだけではなくて（笑）　エンジニアを外に出すという部分に関しては、売り上げ的にかなりの部分でNEC本体に依存する割合が減ってきたことにも関係すると思うんですが、承認とかその辺のプロセスがそれほど面倒くさくないというものあると思います。そして、これからは我々もインテグレーションだけではなくて、もっと上流のコンサルティングとかをやる必要が出てくると考えています。そうするためには社員教育ももちろん大事ですが、現場で覚えるというか、言葉は悪いですができている人から「盗む」ということも必要だと思います。そのことをエンジニアにはちゃんとブリーフィングしたうえで、今回のようなプロジェクトには参加してもらっています。

この協業は、日本仮想化技術さんにもNECネッツエスアイにもWin-Winの関係が築けていると思うんですよね。上流のコンサルだけではなくて、実際に構築のフェーズに入った際に我々のエンジニアが参加する、我々としてもより上流のコンサルを経験して知見を拡げられる。そういう関係を築けたのはよかったと思います。

システムインテグレーターがオープンソースソフトウェアをビジネスの素材として活用するのはもう当たり前だろうが、今回のNECネッツエスアイのように、人的交流も含めて戦略的に社外とコラボレーションするというやり方は、今後のインテグレーターにとってヒントになるかもしれない。