この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、虎塚です。
10月18日(日)、次世代 Web カンファレンスへ行ってきました。イベントの趣旨は「「次世代 Web カンファレンス」を開催します - Block Rockin’ Codes」で公開されています。
最後のセッション「monitoring」に参加したので、レポートします。
- オーナー: @songmuさん
- @mikedaさん
- クックパッド株式会社のインフラ監視をしている
- @rrreeeyyyさん
- ハートビーツ-でMSPをしている（サーバを預かって監視、構築など）
- @fujiwaraさん
- インフラや監視まわりのお仕事をしている
監視とは何か
mikedaさん：監視とは、サービスが正常に稼動しているかをみて、異常を検知したら収束させるという活動を含むもの。
fujiwaraさん：落ちたら困るので監視する。将来リソースが足りなくなりそうだとか傾向をみて、あらかじめ手を打つために監視する。ディスク容量や、アクセス数に対してサーバ台数が足りるかどうかのキャパシティプランニングのため。
songmuさん：kazuhoさんが「監視とは継続的なテストである」と以前書かれていた（参考: Kazuho@Cybozu Labs: 監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について) ）。それに加えて、計測という側面がある。テストと考えると、インフラとソフトウェアの境界はどんどん狭まってきているので、Serverspecでインフラをテストするように監視も今後もっとコード化されていくだろう。。システムの適正化やインフラコストの最適化のためもあるだろう。
mikedaさん：サービスの稼働率を、求められるレベルに保つためのもの。
rrreeeyyyさん：提供側が意図したものを提供できているかをみるためのもの。
songmuさん：以前入院したときに病院で「モニタリングつけていきますね」といわれた。心電図をとったり健康診断をすることも、医療業界ではモニタリングというのだなと思った。
チェック監視とメトリック監視
- チェック監視: 昔からNagiosでやっていたようなOK / NGの監視
- メトリック監視: 定期的に数値をとる監視
昔はほぼ前者だったが、今は後者も増えてきた。
mikedaさん：昔は独自にcron回して値を取っているくらいだったが、それにくらべるといまは当たり前のように細かいメトリックを取るようになった。
rrreeeyyyさん：値の取り方は違うが、チェック監視とメトリック監視の2つを切り分けて考えることはできない。メトリックで見てCPU利用率が上がっていたから、チェックでNGになった、とかあるので。
songmuさん：チェック監視とメトリック監視は分ける派と分けない派がいる。Nagiosはほぼ死活監視、Zabbixは全部一緒に値をとっておいて閾値のトリガーでアラートをかける。個人的には分けなくていい派。分ける人のこだわりはなんなんだろう。
mikedaさん：両方やっていたけど、OK / NGだけでいいとか、チェック監視とメトリック監視のどちらかだけでいいとか、要件がけっこう違う。最初はOK / NG出したいだけなのに、Zabbixでたくさん設定しないといけないなと思ったものだが、いまは一緒でいいかなと思う。
songmuさん：ログ監視でなにかキーワードが出てきたら一発アウトとか。
mikedaさん：外形監視は個別の監視として残っていくと思う。
監視の重要性の高まり
songmuさん：監視の重要性が高まってきている。いつのまにか24時間365日のサービスレベルが求められている。単にOK / NGでなく、メトリック細かくとらなきゃいけなくなった。
mikedaさん：昔は5分間隔での値の取得が当たり前だった。クックパッドに入ったら1分間隔で値をとっていてびっくりした。秒間数千リクエストあってすごい負荷がかかるので、それほんとにいるのと最初は思った。とはいえ、瞬間のスパイクを記録するには1分間隔が必要になる。でも間隔を選べるとうれしい。
rrreeeyyyさん：Webは当然速いことを求められるので、1分間隔でとってもそこから漏れたユーザ（のレスポンスタイム）が遅ければダメという話になる。値は細かくとっていくのがいいと思う。
fujiwaraさん：5分では粗い。数秒だけ値が上がると1分で見ても判別できない。そういう場合はグラフに出ないので、ログを全部みたり、次の日に同じ時間に待ち構えてみたりする。待ち構えていて本当に5秒間だけのスパイクがきたりする。
mikedaさん：以前担当したサービスで、遅いと簡単に落とされてしまうため、ログも何もわからなくなる問題があた。
fujiwaraさん：直近3日分くらいは1秒単位の分解能で値が残っているとうれしいが、現状はできない。
songmuさん：たまに必要な監視が入ってくる。むずかしいですよね。見ないといけないことが多い、サービス細分化にともなって見るべきものが多い、見方が職人芸化している、など課題がある。
監視むずかしすぎる問題
mikedaさん：システムに最も詳しい人が何を監視するかを決めなければいけない。解決も、同じ問題でむずかしい。
rrreeeyyyさん：Rubyくわしい人がいない状況で、PHPにだけくわしい人がRubyのシステムを監視するとかになると大変。自社ではチームがあって、それぞれ言語など得意分野ある。そこでのノウハウを共有できればよいが、実際はサービスに特化していたりして広めづらい。
fujiwaraさん：ミドルウェアで何を監視すればいいかは、運用するうちにわかる。監視テンプレートを公開してくれる人がいるが、自分のサービスに不要なものが入っていたり、必要なものが入っていなかったりする。トリガーの閾値は一般化しづらい。運用していくと煮詰まっていって、秘伝のたれになっていく。新しいミドルウェアを導入するとなると、また新しい秘伝のたれを数ヶ月かけて煮詰める。とても大変なので、新しいミドルウェアをほいほい入れなくていいように、自分から提案している。アプリエンジニアも（監視を）見てくれるような感じであればやりやすいかもしれないが。数ヶ月運用しないといい監視はできない。
mikedaさん：デフォルトテンプレートが全然使えないので、もっと監視テンプレートを公開してほしい。たとえばfujiwaraさんの監視テンプレートがkamipoさんのmy.confみたいに公開されるとうれしい。 (参考: etcfiles/my.cnf at master · kamipo/etcfiles)
mikedaさん：問題の解決もむずかしい。切り分けが必要だが分業がすすむとアタリをつけるのがむずかしくなる。深夜は皆いるわけでもないので、知識の共有化もむずかしい。
アプリケーションエンジニアとの協力
fujiwaraさん：深夜はアプリエンジニアが見ているチャットに障害情報を流す。それで起きる人と起きない人がいるが、けっこう起きてくれる。でも障害情報についてログだけで全部は伝えきれないので、ログの意味を説明しなければびっくりさせてしまう。サービスに影響がないアラートはレベルを下げたり、アラートへの対応方法を日頃から共有する必要がある。すべてのアラートを携帯電話に投げると、いっぱい通知がきて慣れてしまって、夜障害が発生しても起きないようになるので、アラートは厳選して送るのがよい。
songmuさん：前職ではfujiwaraさんと一緒だったが、fujiwaraさんは全部のアラートで絶対起きるので、自分の担当したサービスだけは起きようと思っていた。Chefを使うなど、アプリとインフラの連携はよくできていた。皆が秘伝のシェルスクリプトでやってたのが共通化された。監視のテンプレートもシェアされるといいなあ。sensuはそういうことをやっていると思っている。逆に、皆がプラグインを書くのでカオスになったりもしているが。もっとオープンな規格がでてきて、皆がそれを使えばハッピーかも。
mikedaさん：クックパッドでは監視の切り分けや一次対応をインフラチーム7人だけでしている。アプリチームと一緒にやるほうがいいかは悩み中。アラートを受ける人が少ないと、適当なアラートが放置されたり、ノウハウが共有されないので。
rrreeeyyyさん：MSPではお客さん次第で、アラートが上がったらすぐ教えてというお客さんもいれば、24時間対応チームで切り分けて対応方法まで考えて教えてほしいというお客さんもいる。チーム内で、お客さんによる対応の違いを教育したりしている。
fujiwaraさん：チームの規模による。規模がそこそこあれば、かならずしも皆を起こす必要はない。でも規模が小さいとアラートを感じてもらわないといけない。サービスに影響が起きてるよと。サービスに影響がないものは、アラートが高いレベルで上がらないようにしてる。アラートはだいたい4段階で出している。1つめは特に障害ではないが値が変化したもの、2つめはwarningで翌営業日くらいに対応しないとまずいもの（ディスクが80%超えたとか）。その上のアラートレベルでディスク90%超えを設置すると、それが出てから対応しようということになるけど、80%時点で対応したほうがよい。それより上は、レスポンスタイムの極度な悪化や、滅多にないが本当にヤバイもの。アプリケーションエンジニアに送るのは、サービスに影響があるアラート。デプロイしたコードがわるいとかで、障害がアプリ原因のことも半々くらいであるため。下から2つまでのアラートレベルではアプリケーションエンジニアは対応しなくていいことになってる。3営業日以内に対応すればいいようなものは、気にはかけておいてね、くらい。
mikedaさん：そもそも4〜5人くらいの体制で24時間対応は無理じゃないですか。どうなってるんですか。
fujiwaraさん：本当はちゃんと当番を組める体制をつくるか、作れなければ外に委託するべき。夜にきちんと起きられるという特殊能力に頼って運用してはいけない。家族にもわるいし。委託するとむずかしいのは、アプリケーションエンジニアに同じものを見てもらうことが難しくなってしまう点。問題解決に時間を要してしまう。自社で体制を組めると高い運用レベルを維持できるが、トレードオフになる。
mikedaさん：MSPさんではアプリのコードも見るんですか。
rrreeeyyyさん：契約には入ってないが、ベストエフォートでできるところまでみる。原因をアプリとインフラに厳密に切り分けられることは多くないので、なるべく見るようにしている。自社の場合は監視とマネージドというサービスがあり、後者はコードにも踏み込んで見る。
songmuさん：アプリケーションエンジニアは障害起きたらちゃんと見るべき。インフラがしっかり組まれていればアプリケーション側が原因であることが多いと思う。
fujiwaraさん：それは組み方による。たとえば落ちたらフェールオーバしたり、オートスケールするようにまで組めていれば、原因はアクセス急増とかに絞られるが、そこまでできてなければ原因は半々くらいという体感。
songmuさん：言いすぎたw やっぱり半々くらいということで。アプリ側の人が手を出せる状況や自分が原因だった時に言い出せる環境をつくることは大事だと思う。
次世代DBなど未来の話
songmuさん：メトリックへの要求が上がっている中で、MackerelではGraphiteを使っている。次世代DBが出てきているけど、皆さん検証や導入していますか。RRDtoolとかも。
mikedaさん：パフォーマンスの問題でNagiosからZabbixに乗り越えた。といってもZabbixのほうがパフォーマンスがよいというより、DBを経験者の多いMySQLに切り替えたかったのが大きかった
rrreeeyyyさん：マイクロサービスやDockerが出てくると、監視にはクラスタ管理もついてくる。Consulを使って監視している。
fujiwaraさん：Consulはうちでも監視以外の用途で使っている。アラート検知はできるが、投げるのは別途やらないといけなくて、経路を複雑にしたくないのでZabbixに一本化している。
songmuさん：時系列DBを使うのが当たり前になるかとおもいきや、MySQLをカリカリにチューニングして巨大なインスタンスに載せてしまえば、けっこう間に合う。監視をサービスとして提供するレベルになると、時系列パフォーマンス的にDBを検討しなければならないかもしれない。以前InfluxDBも検討したが、インタフェースが不安定なのでMackerelでは採用しなかった。DatadogだとCassandraを時系列DBとして使っているらしい。
fujiwaraさん：Zabbixも後ろをCassandraにするとスケールするらしい。w
songmuさん：DatadogはKafkaにまずデータを送ってから飛ばしている。監視ではメッセージングが大事だと感じる。Fluentdが監視に与えた影響は大きいなと思う。
mikedaさん：Fluentdの流行はすごかった。リアルタイムで全体のデータをとるのが一気に当たり前になり、インパクトがあった。監視ツールも派生でたくさんできた。
fujiwaraさん：ほぼリアルタイムになにかをとりこんでアラートあげるのが流行ったのは、Fluentdが監視に与えた偉大な功績。そういったことはログ収集がちゃんとできないと無理だから2010年より前にはなかった。昔は1時間に1回scpでログをどーんと集めていたのが、ほぼリアルタイムになった。
songmuさん：OSSでプラグインが作りやすかったので広まったのではないか。
監視の外部サービス利用
songmuさん：監視システムがどんどん複雑になっている感がある。外に出してしまおうという流れもあり、最近はDatadogのようなサービスがある。使い分けや試していることはありますか。
mikedaさん：クックパッドはDatadogを一部使っている。サーバに紐付かないデータをとるのに便利。お金の問題でサーバ1台1台には使ってない。
rrreeeyyyさん：SaaSが落ちてる間監視できないMSPは困るので、業務としてメインサービスをSaaSに置き換えることはしない。お客さんから、アプリの中にNew RelicやMackerelを入れて、監視だけ依頼されることはある。
fujiwaraさん：全部1つのZabbixでやってるが、今後もずっとそうかというと、そうしないと思う。監視が落ちた時のことを考えるのはつらい。収集したデータから何かを抽出するところに集中したい。
mikedaさん：すごく小さな会社にいた時はNew RelicやCloudWatchで監視していた。そういう場所ではZabbixとか管理したくない。最近調べたら、昔からある大きな会社はZabbixを使っているが、QuipperとかTreasure DataとかRettyとかはDatadogやNew Relicだけでやっているサービスも多い。むしろ主流だと思った。Mackarelも多い.
songmuさん：監視は本質的な問題ではないので外に置きたいという流れがある。ソースコード管理と同じように将来はそうなるでしょうね。
mikedaさん：New Relichはとても高いが、DatadogやMackarelは中小企業にはこれだなと思った。
songmuさん：New RelicはZabbixの置き換えとして強いだけでなく、アプリケーションに特化したデータとれるし、高いのもうなずける。
原因特定とか未来予測とか、これからこうなるとかありますか
mikedaさん：未来予測系はまだやっていない。Webサービス自体が機能追加もあり定常的なものではないので、障害予測はむずかしい。ディスクフルの予測などはできるが。
rrreeeyyyさん：うちもグラフの傾向を見たりするくらい。イベントの予定を入れるとスパイクを外れ値にしてくれるとか、よしなにやってほしさがある。
fujiwaraさん：アラートを0/1で上げるのでなく、人間がグラフをみてわかるような違いを教えてほしい。Fluentdのanomalyプラグインを入れると、アクセスが急増するとアラートが上がる（参考: muddydixon/fluent-plugin-anomalydetect）。でもイベントがあると反応するのは当たり前だから、アラートにしたくない。予兆を発見してほしい。先週の月曜と今週の月曜の監視値のグラフ画像を重ねてdiffをとり、差分をみるとかやったことはあるが、一般化するのがつらい。人間がみてわかるということはパターンだし機械学習でできるかも。
mikedaさん：障害予知よりも自動修復や原因特定をシステムがうまくやるほうが現実的かと思う。
fujiwaraさん：アラートを受けたときに見るのは、CPUだったりネットワークだったりクエリだったり。で、アタリをつけて原因を探す。並べて確認できるようにグラフを並べたページを作っているが、あやしい部分は自動で見つけてほしい。アタリをつけていると若いエンジニアがぽかんと見ていて、どうやって見つけたのかと聞かれて説明することがある。これもパターンなので記述できそう。
mikedaさん：検知を簡単にしたい。おかしな値を示すグラフだけサジェストしてほしい。イベントやデプロイをグラフに合わせて見る工夫やUIはありませんか。Datadogではイベントのプロットが上手い。
fujiwaraさん：アプリエンジニアもインフラエンジニアも見るチャットに、デプロイの予告も通知もアラートも流れるようにしている。スロークエリにグラフで気づいたら、デプロイのタイミングだったりするので、デプロイのdiffやmergeコミットをみていく。前後関係を洗いやすくなる。イベントが監視値とともに時系列でぜんぶ流れると便利かもしれない。
監視がラクになっている部分
songmuさん：PaaSを利用するなど監視がラクになっている部分もありますか。
mikedaさん：ノードの追加削除が簡単になっている場合多い。
rrreeeyyyさん：マネージが簡単になった。フェイルオーバを考えなくてよくなって、その部分の監視も不要になった。ただ、クラウド特有の観点も増えている。
fujiwaraさん：マネージドサービスが増えて、まかせると簡単だが、たとえばCloudWatchが提供してくれないメトリックス（たとえばCPU使用率）は取れない。数秒単位の細かい分解能で見ることもできない。ブラックボックスの中にあるかんじで、フェイルオーバ時の進行状況も所要時間も読めない。でも、今までの感覚で見ているからそう思うのかも。
マイクロサービスやコンテナ
mikedaさん：テンプレートで上手くやるとかオートスケーリングするようにするのは大事。自社ではマネージドサービスを許容している。
rrreeeyyyさん：クラスタやサーバ数増加などで、協調して動くのが当然になってきたので、エンジニア側もクラスタの必要台数や切り分け方法などを基本知識として知っておき、監視を設計できるようにしないといけないと思う。ラクに設定できるノウハウの共有などすすめたい。
fujiwaraさん：マイクロサービスやコンテナの管理では、集約した値を見る方向にいかないとだめ。1台1台を個別にみると、そのインスタンスは次の瞬間に捨てられるかもしれないので、全体としてHealthyかをみる。1台落ちたくらいで騒がないように関心や考え方を変えていく必要ある。それと、マイクロサービスといって、あまりいろいろなものを組み合わせないほうがよいのでは。モノリシックでいい部分もあると思う。
songmuさん：それぞれのコンポーネントが自動修復してくれるとうれしい。マネージドサービスはある程度落ちることを前提にしつつ、かつ落ちた時に自動修復してくれるという考え方だと思う。これまでは、どこかが落ちたらフェイルオーバして、後でそこも直していた。システムが複雑化すると、そのままでは無理。
mikedaさん：マネージドサービス実際落ちるのでなんとかしたい。
fujiwaraさん：正常なものに影響が出ないように異常なものを切り離すのはむずかしい。でもそれをしないとコンポーネントが増えるにつれて障害発生率がどんどん上がってしまう。
新しいパラダイムへの対応
songmuさん：新しいパラダイムにどう対処していますか。 新しいミドルウェアが出てくると、監視のインタフェースも出してほしい。H2Oにもissueを立て逃げした。（参考: monitoring interface like 'server-status' · Issue #430 · h2o/h2o）
rrreeeyyyさん：JavaScriptの実行を前提としたページをどうやって監視するのか（外形監視）。JavaScriptの実行状態を見ずにレスポンスタイムだけ見ているのは監視していないも同然。JavaScirpti実行時にコンポーネントがデータを正しく取得できることを監視するとか、そのあたりを整理したりプラグインやミドルウェアを作らないといけない。
fujiwaraさん：クライアントのクラッシュ数を集めることはしている。レンダリングは見てないが、PhantomJSでエラーを見つけたりはしている。レンダリングにかかる時間が長いとアウトなどもあるだろうし、サーバサイドだけでなくフロントの監視ももっと必要だ。
songmuさん：リアルタイムWebやHTTP2が出てきて繋ぎっぱなしになり、req/secさえ取ればよいわけではなくなってきた。そのあたりは難しくなってきていますか。
rrreeeyyyさん：Dockerはコンテナだから以前からの知見でいけそうだが、繋ぎっぱなしの部分はむずかしい。対応が必要。
fujiwaraさん：ストリーミングはreq/secのようには監視しづらい。アプリケーション側からログを出し、集約して監視する形に落とし込むしかない。アプリケーションも含めて監視を作り込むのがよい。
songmuさん：アプリケーションやミドルウェアを作る人は、監視の口を開けてくれるとうれしいです。
監視業務はどうなっていくか
mikedaさん：監視業務はなくならないので引き続きがんばる。
れいさん：全部自動復旧して監視業務がなくなるといいなと思うが、まだなので、むずかしい部分にも追随してやっていきたい。
fujiwaraさん：アプリも一緒に監視して育てていきたい。
おわりに
とても興味深いセッションでした。監視と問題解決をアプリケーションエンジニアと一緒におこなう仕組み作りの話は参考になりました。マイクロサービスと呼ばれる形のシステムの監視やコンテナの監視もまた、SaaSを利用して外出ししていく流れにあるのかもしれないと感じました。
予測検知に関しては、以前LINEさんのイベントで聞いたKPIモニタリングの話を思い出しました。業務分析ではなく、日常のシステム監視でも、こういった取り組みが出てくるかもしれませんね。
それでは、また。
ほかのセッションのレポートは、こちらです。
2
