PHPerKaigi 2018でタイトルの登壇をしてきました。
登壇内容は下記の通りです。
伝えたいことはスライドに大体あるし、勘所については過去のブログでもまとめています。
昨今のWebサービスは外部のサービスと連携し合うのは当たり前ですし、自分たちのサービスが違うサービスによって影響を受けたり、影響を与えたりすることも当たり前になっています。更にサービスは常に機能を追加・変更・削除することで進化しているのですからモニタリングの対象も常に変化しているはずです。ですのでWebサービスとしてどのようにあるべきかというところがモニタリングの勘所となります。もう少し説明するとサービスはServerに紐付いていないがシステム全体に影響するメトリックもありますよね？それも勿論モニタリングしましょうということです。例をあげますと例えば自分が運営するWebサービスがブログ・サイトならユーザの投稿数やカテゴリ別のアクセス数、課金アイテムの利用数のグラフなどを見たくなるでしょう。これはWebサービスだけでなくゲームなどでも同じようにダウンロード数や課金数、インストールされているOSのバージョンなども見たくなるはずです。そういった所をモニタリングしてWebサービスの振る舞いを知ることで自分たちのサービスに対する変更でユーザにどのように影響を与え、さらにそれがシステムにどんな影響を与えるのかわかりますし。その結果、正しいキャパシティプランニングを計画することが可能になってきますし、正しい変更だったかどうかを判断することができるのです。
スライドに出てくる必読ブログについて
id:papix さんと 
id:y_uuki さんのブログは必読です！！
一回読んでもピンと来ない人もいるかも知れません。
しかしそれでいいのです。
自分がモニタリングの道を進んでいくとある日、 あーあのゆううきくんのブログに書いてあったことはこういうことか みたいな事に気付くことがあります。
そしてpapixさんのブログにもある通り、それぞれが試行錯誤していった先に自分のモニタリング道が見えてきます。
モニタリングツールの話
OPCacheとAPCuは良いブログがあったのでリンクをご紹介します。
それとMackerelのプラグインを通した書くミドルウェアの監視についてはアドベントカレンダーでまとめたのでご参考ください。 Mackerelを使っていなくても監視の勘所がわかるように書いていて、他のツールでも同じ値はあるはずなので役立つと思います。
当日のQAについて
id:niwatako さんが全部Tweetしてくれてたので引用します(ありがとうございます！
Q1 障害時にインスタンスをアップしたAuroraをチューニングしたので下げたい
Q:DB監視について、自分の会社でAWSのAuroraを使っていて、DBが落ちる障害が起きた。インスタンスサイズを最大にあげて終わりにした。よくなっているが、価格が高すぎて困っている。
— にわタコ (@niwatako) 2018年3月10日
どうしたら適切なインスタンスサイズを選べるか。何を見ればよいのか。#phperkaigi
CPUかメモリかディスクIOが原因のほぼ9割。インスタンスサイズを上げるとこれが全部解決する。
— にわタコ (@niwatako) 2018年3月10日
チューニングしてどれかを下げられるか。
CPU50％を下回れば良い。ディスクIOはディスクサイズに依存する。#phperkaigi
メモリは(聞き取り自信なし?)バッファプールに乗っているか、インデクスが効いているか。発行されたSQLがきちんと実行されているかを見る。SlowQueryLogなどを見る。#phperkaigi
— にわタコ (@niwatako) 2018年3月10日
僕はDBの問題の多くは金の弾丸（スケールアップ）で解決すると思っています。 実際にRDBの問題はCPU、Disk IO、 Memoryの何れかのわけですから下手にシャーディングに手を出すよりスケールアップの方が筋が良いと思います。 しかしスケールアップは無限にはできず、限界があるのでパフォーマンスチューニングは定期的にする必要があります。 その時にモニタリングが必要でこれはリファクタリングのためのテストコードとまさに同じ価値です。 だからこそ、インフラのリファクタリングのためにモニタリングをやっていきましょうと言う前提で上記のような回答をしました。
Q2 サーバレスをどうやってモニタリングするか
小山さんがいい質問してくれました。
PaaS、コンテナの監視は
— にわタコ (@niwatako) 2018年3月10日
10秒で死ぬコンテナが10秒以上生きていたらおかしい。
今までは何時間で終わったか、どれだけ処理をしたかにフォーカスされていたが、サーバーレス時代は、ちゃんと終わっているか、数が増えていないかなどになる。#phperkaigi
アプリケーションレイヤーのコンテナはわかりやすいが、AuroraやコスモスDBはブラックボックス化されていくと思っていて、底をどうするかは我々エンジニアの課題だと思っている。#phperkaigi
— にわタコ (@niwatako) 2018年3月10日
これは僕の所感なので僕自身も試行錯誤している部分です。 だからみんなともっともっと知見交換していこうなっ！！
Q3 アプリケーションのログはどうモニタリングすればいいですか？
アプリケーションログを監視している
— にわタコ (@niwatako) 2018年3月10日
いろいろメトリクスを貼っていて煩雑。
どう管理したらよいか#phperkaigi
自分たちの作っているアプリケーションなら、ある程度ログの内容を精査できる。
— にわタコ (@niwatako) 2018年3月10日
クリティカルなものはクリティカルですよという通知が来れば良い。
ログに残すのはWarningになると思う。
課金などは大事な情報なので他のサービスに投げにくいので自分たちで加工して数値化するなどする#phperkaigi
CRITICALを監視するだけならチェック監視で出来るので簡単に始めれます。 Warningを収集してアドホックに見るにはElasticsearchとか便利です。
まとめ
可視化することだけでは品質は上がらないけど、品質を上げるためには可視化する必要があるってのは、モニタリングもテストコードも同じだよなー #phperkaigi
— どぅーあき (@do_aki) 2018年3月10日
つまりはこういうことです。 そしてサービスの品質を上げていくのは我々エンジニアしかいません。 今日から手を動かして世界を変えるのはあなた自身です。
