現在位置: ホーム / みらくるブログ / パネルディスカッション「今こそ改めて考える!OSSによるクラウド監視の勘所」を行いました

パネルディスカッション「今こそ改めて考える!OSSによるクラウド監視の勘所」を行いました

「OSC2016 Tokyo/Fall」において、さくらインターネット社ほか2社と、「今こそ改めて考える!OSSによるクラウド運用の勘所」と題してパネルディスカッションを開催しました。

パネルディスカッション「今こそ改めて考える!OSSによるクラウド監視の勘所」を行いました

ミラクル・リナックス松永です。

さて、2016/11/5に開催されました、「OSC2016 Tokyo/Fall」での講演の一枠で、「今こそ改めて考える!OSSによるクラウド監視の勘所」と題したパネルディスカッションを行いました。
当日は、事前登録をはるかに超える75名の方に参加いただきました。

今回のディスカッションでは、大手クラウドベンダーで運用を担当されている方などをパネリストにお招きし、計4名で意見を交わしました。

パネリスト(会社名:50音順)
   さくらインターネット 野島氏
   GMOインターネット 郷古氏
   日本仮想化技術  玉置氏
   ミラクル・リナックス 熊谷
◎モデレータ
    MKTインターナショナル 赤井氏


それぞれの簡単な自己紹介の後、以下4つのテーマでディスカッションを行いました。OSC2016 Tokyo/Fall パネラー

(左から:熊谷、玉置氏、野島氏、郷古氏)

まず、最初のテーマはこちら。
【Q1:OSSの監視ツールを導入して良かったことを教えてください】

こちらはどちらかというとクラウドベンダー2社への質問。
GMOインターネット社(郷古氏)では、古くからはNagiosを使っていたが、ConoHaリニューアルのころからZabbixを使い始めたとのこと。
Nagiosはテキストファイルベースで比較的軽い。APIベースでいろいろな操作ができるのが便利だと言っていました。

さくらインターネット社(野島氏)はHobbitからZabbixに置き換えている最中とのこと。
ZabbixはAction Script実装などによって、「障害が起きたら(該当のもの)を実行するなど自動化しやすい。」と言っていました。

双方ともに同じような見解だったと思います。
また、情報が取りやすいということも利点としてあったようで、提案する側である日本仮想化技術社(玉置氏)や弊社(熊谷)の見解としても「先行者のおかげもあってノウハウは溜まってきている。」とのことだそうです。


それでは次のテーマです。
【Q2:上手く行ったこと、上手くいかなかったことを教えてください】

さくらインターネット社はHobbitからZabbixへ、GMOインターネット社はNagiosからZabbixへ舵を切っているわけですが、お二人とも共通していたのが、「当初のリソース見積もりを超えてしまった」というところでした。
NagiosやHobbitはどちらかと言うと"軽い"という印象があり、これを基準にリソースを見積もると足りなくなるようです。
OSC2016 Tokyo/Fall 会場特にさくらインターネット社では、Zabbixへの切り替えの時に監視サーバの台数(従来はHobbit7台くらい)が減らせるかどうかやってみたそうです。
ただ、「1台で監視する台数が3000台とか多すぎて、ちょっと細かくやろうとすると10万から20万監視項目となってしまい、監視データを取得するのに時間がかかった。」ということがあったそうで、MySQLのチューニングやZabbxiを3台くらいに増やすなど対応したとのことです。

性能問題で、相談を受けたことがあるか?という話で弊社(熊谷)に振られましたが、弊社(熊谷)の見解としては、「特にDBが性能ネックになることがあり、MIRACLE ZBXではDBパーティショニングでできるだけ救おうとしてはいるが、ハードウェアのスペック以上のことはさすがにできないので、適切な監視項目数とかにまとめる必要がある。」と言っていました。

さて、3つ目のテーマはこちら。
【Q3:正解が無い運用で何を正解だと考えて運用していますか?】

これが、一番奥の深い質問で、皆さん一様に「う~ん」と唸っていました。

GMOインターネット社(郷古氏)は、「こうすれば上手くいくというノウハウを集めて、同じ障害が起きたときにすぐに解決策引き出せるようにすること。」と言っていました。

野島氏は、「さくらインターネットで実現できているわけでなく、あくまでも個人的な見解である」とした上で、「H/Wの障害の時だけ人が動くのが正解だと思っている。障害の予兆などが予測できていれば、そこまでいかないように制限をかけるなりの設計をして、落ちないように工夫することが必要だ。」と言っていました。

弊社(熊谷)は、「一つ監視サーバを建てるとなんでもかんでも設定して全てをやろうとする。そうなると逆に管理しにくくなる。人や部署によって監視したい情報が変わるわけだから、適度に分散した方が良いのではないか?Hatoholを一番上や中間においてまとめて監視できれば良いと思う。」と話していました。

日本仮想化技術(玉置氏)はOpenStack運用提案の観点から、「インフラを監視するZabbixやテナントを監視するZabbixがあったりで、それらをまとめて監視できる方が良い。」と言っていました。
また、特にOpenStackは大量のログが出るので、如何にログを効率よく運用していくことが必要とのことです。


最後のテーマはこちらです。
【Q4:最近の課題やトピック、今後の監視で課題となることは?】

GMOインターネット(郷古氏)は、「適材適所でZabbixのようなツールと、ログを長期保存して分析できるようなツールが必要になるであろう。今後問題となるのは、おそらくDockerのコンテナ運用になると思うのが、PaaSをどうやって監視するかは混沌としていて、まだ難しい。」と言っていました。

さくらインターネット(野島氏)は、「サーバを使い捨てにする時代の流れの中で、自動的に監視登録できるようにならないとつらい。人が手で設定するのは限界である。」と言っていました。
また、加えて「システム開発の最初の方から運用を考えた設計になっていれば良いと思う。どうしても開発の後の方になってから監視を考えるために、自動化が考えにくい設計になってしまう。」を言っていました。

日本仮想化技術(玉置氏)は、「仮想サーバの監視はできているが、まだまだ仮想ネットワークの監視が不十分である。」との見解を示していました。

弊社(熊谷)は、「未来のことで言えば、壊れる前にある程度予測してできれば良いと思う。今々で言えば、ログならZabbixは苦手なので、Fluentd、Kibanaの方が強いのでそれを使うのも十分ありだと思う。」と言っていました。

最後に皆さんから、(これも何故か?)Hatoholでの一元監視を薦めていただきました。
Hatoholに期待を寄せていただいているようで、みんなで育てていきましょう!みたいな感じで締めくくられました。

各社各様にOSSを検討しているかと思いますが、今回は実際に使ったり提案している立場からの話でしたので、非常に重みのある内容であったかと思います。

>YouTubeでご覧いただけます