入門監視 第Ⅰ部を読んだ
チームで自律的に開発を進められる体制を作るためには、DevだけではなくOpsのスキルも身につけて、チーム単位で所謂DevOps的な動きができることが重要になってくる。自分の働くスタートアップのような小規模の会社だと、分業するのがそもそもリソース的に難しいという事情もあるが。
そんなわけで、あまりこれまで勉強してこなかったOps周りの知識を最近勉強中であり、その一環で監視に関する下記書籍を読み進めているので備忘録として自分の理解をまとめていく。
要約
1章 監視のアンチパターン
この章では陥りがちな5つのアンチパターンが紹介されている。
1. ツール依存
自分たちの会社の状況にあうツールを都度選ぶべきであり、あるツールを使う前提で問題に対処するのは良い結果に繋がらない。例えば、他社事例で上手くいったツールや構成を踏襲して自社のシステムを構築したとしても、自社の解決したい問題などの背景の違いによって上手くいかないケースは往々にしてある。なので、自社の課題を正しく認識してそれに合うツールを選択すべき。
また、必要であればツールを増やすことを恐れないことも重要。ツールが増えて認知コストが上がることよりも、目的に沿わない統合的なツールを使う場合の方が不利益を生む傾向にある。(ここはトレードオフだと思うのでどの辺が分岐点かは判断する必要がありそう。)
2. 役割としての監視
専任の監視ロールを作って集中できるようにすることは、一見良さそうに思える。しかし、完全にDevとOpsを分断するような専任チームを作ってしまうと監視責任者はよく知らないアプリケーションの監視を管理運用するということになり、それはあまり上手くいかない。監視とは役割ではなくスキルであるという認識をして、チーム内の全員が一定のレベルに達していることが重要。
3. チェックボックス監視
メトリクスを見ること＝監視ではない。例えば、CPU使用率がコンスタントに99%であろうとリクエストが無事に捌けているのであれば問題はない。動いている、ないしはユーザに問題なく価値提供できているとはどういう状態なのかを正しく認識し、そのためのメトリクスが設計できていることが重要。
4. 監視を支えにする
監視はあくまで通知であり、問題を修正するわけではない。障害が起きた場合は、それに関する問題の修正が可能かどうか検討する必要がある。ひどいコードを監視でなんとかしようと思ってはいけない。
5.手動設定
監視の設定にかける時間は監視自体にかけるよりも長い時間を要するので、より良い監視システムを目指すのであれば監視の設定は全て自動化すべき。
2章 監視のデザインパターン
この章では4つのデザインパターンが紹介されている。
1. 組み合わせ可能な監視
モノリシックな統合されたツールを使うよりも、専門的なツールを組み合わせて監視の仕組みを作る。組み合わせを考えるにあたって監視を構成する要素を下記の5つに分解して考える。
■データ収集
どう集めるかという観点ではプッシュとプル型が存在し、プッシュ型の方がポーリングをする中央サーバが不要であり、分散アーキテクチャでのスケール性は良いというのが筆者の経験則だが場合によるだろう。
何を集めるかという観点ではメトリクスとログが存在する。さらにメトリクスも、カウンタとゲージに分解される。カウンタは単調増加する計数量であり、例えば1日のリクエスト回数のようなもの。ゲージはある時点での瞬時値であり、例えば車の速度系の値などであり、過去の履歴の情報などを単体では含まない点に注意する必要がある。
ログは、連続した文字列でありJSONのような構造化されたものもあれば、非構造化された単なる文字列のものもある。構造化ログの方がログ単体での解釈が容易であり、可能ならば構造化ログを使う。しかし、ログの用途が人間が読むだけで、システムにパースする必要などがない場合は非構造化ログの方が楽なケースもある。
■データストレージ
データの種類に応じて適切な場所へ保存する。時系列データはTSDB(RRDやGraphiteのWhisperなど)に入れる。高度な検索をしたい場合などには、ElasticSearchなどの検索エンジンへ格納する。
■可視化
GraphanaやSmashingのようなダッシュボード製品やフレームワークを活用する。最高のダッシュボードは1つのサービス、あるいは1つのプロダクトのステータスを表示することに焦点を絞ったものであり、サービスを最もよく理解している人によって管理運用されるべき。
■分析とレポート
監視データの種類によっては分析レポートが必要となる。例えばSLAのレポーティングなどである。SLAのレポーティング時はメトリクスのサンプリング周期などに注意する。
■アラート
監視の目的はアラートを出すこと自体ではなく、アラートによって質問を投げかけることにある。(どう行動すべきかというインシデント対応フローまでセットにする必要があること？)
2. ユーザ視点での監視
まず監視を追加すべきなのは、ユーザとアプリケーションのやりとりが発生する箇所。シンプルな方法ではHTTPレスポンスコード(特に5xx番台)を使う。ただし、これによって何か問題が起きていることは分かるが、何が原因で問題が起きていることまでは分からないため、シンプルな方法を足掛かりにして広げて行くことが重要。
3. 作るのではなく買う
SaaSサービスを利用することで監視の仕組みをすぐに立ち上げることができる。多くの企業はSaaS->FOSS(Graphite,Prometheusなど)->独自プラットフォームという変遷を辿る傾向にあるが、最初の5年は少なくともSaaSサービスで十分だろう。
4. 継続的改善
組織の成熟度や規模の変化に応じて適切な監視要件は変化する。継続的に改善しよう。
3章 アラート、オンコール、インシデント管理
この章ではより良いアラートを作るためのヒントや運用体制について述べられている。
どうしたらアラートをよくできるか
アラートの内容に応じて適切な場所に送ることが重要。アラートはすぐに応答が必要なのであればPagerDutyなどに送る。すぐにアクションが不要ならチャットなどに送る。また、アラートには対象サービスへの手順書リンクを貼っておくことで対応フローが明確化できるが、手順書に書かれている作業を行うだけのフローになっている場合はそもそも自動化を検討すべき。
その他には、前述されているようにそもそもアプリケーションを改善することや適切なメトリクスを用いることなども重要である。
オンコール
オンコール対応は多大にストレスがかかるため、ローテーションすべき。また、アラートをチューニングするための動きとして、オンコール担当が前日のアラート一覧から各アラートが改善、または削除できないかを定期的に検討すると良い。また、オンコールの際に収集した情報を元に次のスプリントでアプリケーション自体の安定性向上計画を組むことも有効。その他にも、PagerDutyなどのツールを使ってエスカレーションパス構築などのオンコールの仕組みを補強すると良い。
インシデント管理
発生した問題を扱う手順についての紹介。インシデント発生時には、例えば以下のような役割に分かれて対応するフローを組むと良い。
■現場指揮官
直接的に調査にはかかわらず監督する役割。
■スクライブ
誰がいつ何をやったかなどを記録する、書記のような役割。
■コミュニケーション調整役
ステークホルダーと最新状況を都度共有する。
■SME
実際に手を動かして調査する人。
PagerDutyのドキュメントは参考になるので読むと良い。
response.pagerduty.com
