パネルディスカッション「今こそ改めて考える！OSSによるクラウド監視の勘所」を行いました
パネルディスカッション「今こそ改めて考える！OSS によるクラウド監視の勘所」を行いました
ミラクル・リナックス松永です。
さて、2016/11/5 に開催されました、「OSC2016 Tokyo/Fall」での講演の一枠で、「今こそ改めて考える！OSS によるクラウド監視の勘所」と題したパネルディスカッションを行いました。
当日は、事前登録をはるかに超える 75 名の方に参加いただきました。
今回のディスカッションでは、大手クラウドベンダーで運用を担当されている方などをパネリストにお招きし、計 4 名で意見を交わしました。
◎パネリスト（会社名：50 音順）
- さくらインターネット 野島氏
- GMO インターネット 郷古氏
- 日本仮想化技術 玉置氏
- ミラクル・リナックス 熊谷
◎モデレータ
- MKT インターナショナル 赤井氏
それぞれの簡単な自己紹介の後、以下 4 つのテーマでディスカッションを行いました。
まず、最初のテーマはこちら。
【Q1：OSS の監視ツールを導入して良かったことを教えてください】
こちらはどちらかというとクラウドベンダー 2 社への質問。
GMO インターネット社（郷古氏）では、古くからは Nagios を使っていたが、ConoHa リニューアルのころから Zabbix を使い始めたとのこと。
Nagios はテキストファイルベースで比較的軽い。API ベースでいろいろな操作ができるのが便利だと言っていました。
さくらインターネット社（野島氏）は Hobbit から Zabbix に置き換えている最中とのこと。
Zabbix は Action Script 実装などによって、「障害が起きたら（該当のもの）を実行するなど自動化しやすい。」と言っていました。
双方ともに同じような見解だったと思います。
また、情報が取りやすいということも利点としてあったようで、提案する側である日本仮想化技術社（玉置氏）や弊社（熊谷）の見解としても「先行者のおかげもあってノウハウは溜まってきている。」とのことだそうです。
それでは次のテーマです。
【Q2：上手く行ったこと、上手くいかなかったことを教えてください】
さくらインターネット社は Hobbit から Zabbix へ、GMO インターネット社は Nagios から Zabbix へ舵を切っているわけですが、お二人とも共通していたのが、「当初のリソース見積もりを超えてしまった」というところでした。
Nagios や Hobbit はどちらかと言うと " 軽い " という印象があり、これを基準にリソースを見積もると足りなくなるようです。
特にさくらインターネット社では、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 を検討しているかと思いますが、今回は実際に使ったり提案している立場からの話でしたので、非常に重みのある内容であったかと思います。
