Observability成熟モデルについて
katzchang氏（以下、katzchang）：では、話をしていきます。今日は、New RelicでObservability成熟モデルというのがあるので、その話をします。New Relicのことはお話ししません。
で……あ、自己紹介をしろと書いてある。大谷和紀です。TwitterやはてなIDは「katzchang」です。好きなWebサービスは、はてなブックマークです。残ってほしいWebサービスは、はてなの増田（はてな匿名ダイアリー）です。
今、New RelicでSenior Customer Success Managerという肩書でやっています。New Relicに入ったのは去年の11月ぐらいで、それまではVOYAGE GROUPのZucksというところにいて、広告配信のシステムサービスを書いたりしていました。
そこでいろいろオブザーバビリティというか、New RelicやDataDog、Mackerelなどいろいろ使っていたので、その経験があって今に至るという感じですね。
それまではSI業界に7年ぐらいいて、二次請けぐらいのポジションで、パッケージ導入の要件定義から、概要設計、詳細設計、コーディング、テスト、導入、データ移行などいろいろしていました。
技術バックグラウンドは、言語的にはScala、Goあたりを使うことが多いです。前職の経験からAWSはなんとなくふんわり知ってるという感じ。Makefileは最強のマクロ言語だというふうに言ってます。なので、使い道注意です。
「ajito.fm」というPodcast、みなさんお聞きでしょうかね。自称準レギュラーでやっています。あとは、ボルダリングは12年ぐらいやっているんですけど、ずっと中級者です。New Relicのことはしゃべりません。
何をもって「正常に動いている」と言えるのか？
katzchang：しゃべらないと言いながらいろいろ言うんですけど、New Relicは社内のマテリアルというか素材がいろいろあっておもしろいので、わりとこれがおもしろいなと思って最近よく紹介をしています。
こんな感じですね。「0段階から4段階まであるよ」ということを彼らは……まあ「僕らは」と言うとあれなんですけど、言われています。どういうことかというと、「いきなり高度なことはできないよ。足元から一歩一歩いこうね」みたいな感じです。「まず計測を始めないとそもそも始まらないよね」「『何をもって正常に動いているか？』ということををまず考えてみてください」とよく言っています。
たぶんオブザーバビリティやモニタリングに関心のある人はとくに見ていると思うんですけど、Webサービスだと、例えばレイテンシ、トラフィックエラー、あとサチュレーション。サチュレーションはリソースがどのぐらい消費されているかという話だと言っていいと思うんですけど、そのへんを見ようということを最初に言っていますね。
「じゃあ、サーバのアプリケーションの人にとっては、何をもって正常に動いているというんですか？」というところですね。例えば「データがちゃんと表示されているか？」とか「ユーザーがちゃんと想定どおりのエンドポイントにたどり着いているか？」みたいなことも、おそらく正常に動いていなければ、結局ユーザーがちゃんと使えていないということを疑うかもしれない。
じゃあブラウザにとって何かというと、SRE的なサーバサイドのレイテンシを見ていたとしても、ブラウザからアクセスしたときに「なんかレイテンシが異様に遅い」とか、「よくわからないけどエラーになる」「そもそも404とかサーバにすらリクエストが到達していない」みたいなことも、実はサーバサイドだけ計測していてもわからないので、「ブラウザアプリケーションやモバイルアプリケーションにとって正常に動いているというのはどういう状態かということも、実は別にいろいろ考えられるんじゃないの？」という話をよく言っています。
「オブザーバビリティ」とは
katzchang：「For 〇〇」。例えば、機械学習をするエンジニアではないけど、そういう不確実でもないよりはマシ、みたいなものを動かす人たちにとって、正常というのはどういう状態を指すかというのはおもしろい視点になるんじゃないかなと思います。どうですかね。
netmarkjp氏（以下、netmarkjp）：あります。あとで触れるんですけど。
katzchang：（笑）。
netmarkjp：モニタリングで難しいのは、正常と通常という2つの状態があって、わりとみんな何を検出したいかががブレちゃうんですよね。そこをちゃんと払い落として「俺たちは何をやるんだ！」って決めてやらないと、もう迷子ですね。
意味わかんないというか、結局「なにもしないのにアラートだけ来ます」みたいなことが発生しちゃったりするので、正義と正義のぶつかり合いみたいなことが起きるんですよね。
katzchang：アラートを整理するにも、方針がないと、「これは正常として扱っていいんだっけ？ それとも……」みたいな。アラートも安易に潰せないし、それはみんなお悩みポイントだと思います。
netmarkjp：そうですね。
katzchang：何をもって正常として動いているのかというのがいわゆるモニタリングとか監視とか言っている分野でした。オブザーバビリティは、もう少し深掘ってどのように動いているのかという情報をいろいろ集めようというのが、最近みなさんが言っている「オブザーバビリティ」という用語だと理解しています。
メトリック・イベント・ログ・トレースが4本の柱
katzchang：次です。監視は「動いているか・動いていないか」で、オブザーバビリティは「どう動いているのか？」。
「なんか症状が出たよ」というのから、「その原因にたどり着きやすくして、その対処をちゃんとできるようにしようね」というのがオブザーバビリティで、「そのためにいろいろ情報を集めようね」というのがオブザーバビリティの基本なんじゃないかなと言っています。
なので、0段階目では「何を計測し始めようか？」というあたりから始めて、「その中でどう動いているのか？」というのも、もう少し深掘った情報まで計測しようみたいなことを言っています。
これはNew Relicの例なんですけど、よくあるのが「メトリックとログとトレースによってオブザーバビリティを確保しようね」ということはけっこう各社が言っています。あと、New Relicの場合は、それに対して「イベントというのも大事だよ」と言っているんですけど、PrometheusやDataDogは「メトリック・ログ・トレースというのが3本の柱だよ」みたいな感じで言っているはずです。
ごめんなさい。違ったらぜひつっこんでいただいて、次回、詳しい方はぜひ一緒におしゃべりしましょう。
netmarkjp：そうですね。
katzchang：計測を始めるといっても、まず基本的なところから計測を始めればいいんじゃないかなという感じです。ベストプラクティスとしていろいろあるし、各ツールもインストールしたらわりとすぐ動くものが用意されているはずなので、まずは使ってみて計測してみて、基本的なメトリックを押さえるところから始めてみましょう、というのがよくある話です。
第1段階は「Reactive」
katzchang：計測を始めると何が起こるかというと、アラートが起きます。定義次第だけど、アラートをぜひ起こしましょう。
第1段階は、Reactive。「何かが起こったときに反応しよう」みたいなやつですね。つまりアラート対応です。
「サービスが停止したときにちゃんと対応できているか」「アラートに気づけているか」「障害対応はちゃんとすばやく気持ちよくできているか」みたいなことがポイントになります。
あとは、サービス停止率、可用性ですね。普通に「アベイラビリティのパーセントをちゃんと見てみましょう」とか。障害発生率、発生率というのもちょっと古典的ですけど、「障害発生は何件あったの？」とか。あと、Webサービスなど、常に動き続けてメンテナンスをし続けることができるようなものは、平均MTTR（Mean Time To Recover）というのをよく取ったりします。
だから、WebサービスのサーバだったらMTTRになるし、リリースやデプロイの対応がしづらいモバイルアプリだったら、クラッシュレートなどをみなさんよく見ているんじゃないかなと思います。
これを改善していきましょうというのが受動的対応。最初は「安定させないと何も始まらないよね」ということですね。
2段階目「Proactive」
katzchang：それがある程度できたという段階になったら、もう少し踏み込んで対応していきましょうというのが次の段階です。Proactive。
例えば「不安定さをなくすのが1個のポイントになる」と言っていたりします。例えば「エラーにはならないんだけど、なんか遅いレンスポンス・トランザクションがある」とか、そういうことですね。あとは、そもそもその平均のパフォーマンスを改善していこうとか。
あと、安定してきたらようやくSLI・SLOもしくはSLAみたいなことが意識できます。SLOはObjectiveですね。不安定で障害がたくさん起こっているのに、Objective99パーセントだと言ってもたぶん誰も幸せにならないので、まずはある程度安定を目指しましょうという感じですね。
あとは、ユーザー体験というと、Webのブラウザアプリのリアルユーザーモニタリングみたいな分野もあるんですけど、その場合はちゃんとパフォーマンスが出てユーザーが離脱していないか。アプリケーションのパフォーマンスというよりはWebサイトのパフォーマンスみたいなものも、安定してきたら少し気になってくるよね、というところですね。
これ、自分でちょっとわかりにくいなと思わなくはないですけど、右側が目立ちますよね。これは明らかな障害です。
製品の話はしないと言っていたNew Relicの画面なんですけど、（右側の上のほうが）ピンクになっています。ピンクはアラートの設定にひっかかっているということなので、これは一段階目のリアクティブな対応で対処できる範囲です。
注目したいのは、左側ですね。（グラフに）ちょっと出てるところがありますよね。これは右に比べると小さいからなんとなく「別にいいんじゃないかな？」と思うし、実際アラートの条件にも入ってないんだけど、よく見るとふだんの1.5倍ぐらいパフォーマンスが悪いんですよね。「これいいんだっけ？」とか「なんで？」ということに答えられるようにしておきましょう、というのがこの段階です。
ものによっては対応が必要になったり、もしくはいらなかったりするとは思います。ただ「1.5倍悪いというのはちょっと気にする範囲かな」という感覚が自分の中にはあったので、こういう例を持ってきました。
なので、こういうところから不安定さを積極的になくしていこうというのがこの2段階目だと言っています。
3段階目「Predictive」
3段階目は予測的対応、Predictive。
よく私もいろいろな方やチームと話をしていて「やっぱりコストは抑えたいよね」みたいな話がよく出るんですけど、なんと「この段階になってようやくコスト削減がまじめにできるんじゃないの？」と書いてあって「確かに、なるほど」と思ったので、これはぜひ紹介したいです。
アラートを起こしているときにコストダウンもなにもないよね。「パフォーマンスを上げられるか下げられるか、どのへんにポイントがあるか」という段階は、パフォーマンスの調整の余地がたくさんあるので、まだコストダウンではない。
そこで、「3倍の余裕があるからサーバ半分まで減らせるよ」という予測は立てられなくはないんですけど、「まぁ、うん、そうですね、立てやすいところは立てればいいのかな。わかんない、うん」という感じです。
あとほかには、前職のZucksでは、避難訓練というかたちでわざと本番のクラスタに障害を起こして、その検知や対応ができるかというのをたまにやっていました。
netmarkjp：それはランダムですか？
katzchang：ランダムではないです。
netmarkjp：ではない。さすがに。
katzchang：私が壊してました。
netmarkjp：なるほど（笑）。
katzchang：例えば、昔Fluentdのプロセスがすごく不安定だった時期があって、結果的にRubyが依存しているメモリ管理のライブラリの不具合だったっぽいんですけど、その時に、Fluentdのプロセスが落ちたときの対応をなかなか自動化できなかったんですよ。2週間に1回ぐらいたまに落ちるという感じだったので。すごく嫌なやつ。
netmarkjp：うん（笑）。
katzchang：その時はわざと日中に私がFluentdのプロセスをわざと落として。それで、検知して、ほかのエンジニアがその対応をできるかということをやっていたりしたのが、もうけっこう前ですね。4年前とかかな。
netmarkjp：いいですね。本当に避難訓練って感じですね。
katzchang：そこでけっこう障害対応も安心して見れるし、あとあいつはだいたい昼間に落ちないので。
netmarkjp：なぜか（笑）。
katzchang：そう、なぜか落ちないので、昼間に落ちてみんなで対応できるのはすごい楽ですね。この前の……去年の夏でしたっけ？ AWSの障害も、たしかAWS側の作業が原因だったという話でしたっけ？ あれも日中に起こしてくれて助かりましたね。
netmarkjp：そうですね。あれは15時過ぎぐらいでしたね。
katzchang：そう。あれを夜中に起こされたらちょっとあれだし、金曜の5時に起こされたらみんな嫌だったんだろうなって思います。
netmarkjp：（笑）。
katzchang：あと実験的デプロイとか言いながら、「ばんばんリスクがあるデプロイをして、結局ダメだったら戻す」みたいなこともけっこう頻繁にやってましたね。パフォーマンスって結局、心配なところはいっぱいあるけど、実際どうなるかわからない。
netmarkjp：そうですね。
katzchang：僕らにとっても、経験あるエンジニアにとっても、どうなるか実際にはわからない部分がけっこうあるので、「意外と大丈夫だったよね」「このレベルだったら大丈夫だけど、副作用があるから、機能的にはリリースをして、そこからパフォーマンスの改善をやっていこう」みたいな、ステップを細かく切れるあたりの話を、僕らは実験的デプロイと呼んでいました。
デプロイ頻度が重要
katzchang：これもうちょっとスライド続くのかな。（スライドを見て）あ、なんかいい言葉になっちゃった。
katzchang：いい言葉になっちゃったって失礼ですね（笑）。
netmarkjp：いい言葉ですよ。
katzchang：いい言葉なんですよ。これは和田卓人さん（t_wada）が言っていたんですけど、「状況に応じて品質保証のやり方はいろいろあるよね。同じやり方をとると、過剰に品質保証するか、もしくは品質保証がされていない、リスクが実はすごく大きいみたいなことが起こり得るので、例としてはWebサービスとモバイルアプリはデプロイのやり方などがぜんぜん違うので、まったく別のやり方をしないとダメだよ」と言っています。
これはぜひ、修理系と非修理系なみたいな話が「ajito.fm」の第40回で出ているので、興味があれば聞いてみてください。訓練された誰かはこの「ajito.fm/40」の情報をハッシュタグつきでツイートすると思います。
これもいろいろ調べてておもしろかったんですよ。「Testing in Production, the safe way」というMediumの記事があって、たぶんあまり話題になっていないので読んでいる方はほとんどいないと思うんですけど。
あとは、『Accelerate』という本はけっこう有名で読んだ方も多いと思うんですけど、その中に「デプロイ頻度はけっこう大事だよ」ということが書いてあるので、「そのへんをいい感じに回していくのも僕らの方向性の1つだ」とよく言っています。
でも、個人的には検証したいところがあって、因果関係的に「いい組織ならデプロイが頻繁になるのか？」という議論って、本でどこまでされているんですかね。詳しい人がいたら、ぜひブログに書くか、次回出ていただくか、なにかしていただきたいです。結果的に、成長企業とデプロイ頻度とか、この4つの数字は関係があるよみたいな感じで言われていますよね。
4段階目「データ駆動」
次です、データ駆動。ここまでいくといろいろあるよねという感じなんですけど、例えばデプロイ。いろいろ機能の追加とかもあるんですけど、「それがちゃんと使われているの？」「ビジネスに対してどう紐づいてるの？」みたいなこともいろいろやっていきましょうという感じにしています。
デブサミで発表したときは、カオスエンジニアリングをどこにも分類してなかったんですけど、分類してみました。
カオスエンジニアリングの記事がNew Relicのブログにもあったのでこの前翻訳してみたんですけど、意外といろいろ高度なことを目指しているなという印象があったので、「環境によらないサービスの継続がカオスエンジニアリングの肝なんじゃないか」と思っていますが、みなさんどうでしょう。
前までは実は「実験的デプロイみたいなものもカオスエンジニアリングっぽいな」というふうに自称してたんですけど、そうでもないかもと思ってきました。このへんもおもしろいですよね。みなさん興味があるところじゃないかなと思います。
ツールを変えると運用が変わり、運用が変わると文化が変わる
まとめます。Observability成熟モデルというのがあります。一歩ずつやりましょう。1個のチームでも「この分野はここまでできている。この分野はまだ計測を始めてない」というところもいっぱいあると思うので、目安になればいいかなと思って紹介をさせていただきました。
あと、いろいろ記事を調べてるなかで、「オブザーバビリティチームの目標はログ・メトリクス・トレースの収集じゃなくて、事実（ファクト）とフィードバックに基づいたエンジニアリング文化のビルドだよ」と言っている人がいます。「へえ」って感じ。さらに、「その文化を組織全体に広げるところがゴールなんだよ」と。自分自身を振り返っても、組織全体に広げるところまではなかなか難しかったなと思います。
それから、「ツールと文化が大事だ」というのを、曽根壮大さんという方が言っています。
「ツールを変えると運用が変わって、運用が変わると何が変わると思います？」。この語り口がちょっといやらしいですね。
netmarkjp：（笑）。
katzchang：「そう、文化が変わるんですよ。文化がプロダクトを育てるんです」みたいなことを言っていて、「へえ、エモいな」と思ったので紹介をしました。
私からは以上です。ありがとうございます。
