ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■信頼性と品質 / システム運用と管理
2022.09.01 2024.06.28 約5分
国内最大級 ITエンジニア向け勉強会プラットフォーム connpass においてグループ人数 No.1 の Forkwell Communityから、オブザーバビリティの「つぎの一歩を応援する、気づきと繋がりの場」 Observability Loungeシリーズ #1 をレポート。
Cloud Native Days でも Observabillity Conference 2022 が開催され、注目度が高まる オブザーバビリティ 、DevOps を正しく文化として定着させ、ユーザーに対してより良い価値を届ける為にも監視の重要性が増している状況です。
そして、昨今はマイクロサービス化やコンテナ化が進み、開発における利便性やサービスの安定性は高まりました。しかし、その分、システム全体としての構造は複雑化が進み、問題の特定などインシデント時のトラブルシューティングなどがより難しくなっており、監視も従来型の監視からレベルアップが求められています。
Forkwell の Observability Lounge #1 では『入門 監視 ― モダンなモニタリングのためのデザインパターン』の翻訳を手掛けられた現 Autify CTO の松浦 隼人氏をお迎えし、いま一度、監視の基礎を学びます。
5年前に出版された「入門 監視」は、システム監視における考え方、アプローチの方法など重要なことが多く書かれています。一方、監視対象や監視の仕組みの進化によって今では気にする必要がなくなったりといった点もあります。 今回は今でも変わらないシステム監視の原理原則に焦点を当てて、あらためて「入門 監視」を振り返ってみましょう。
テスト自動化プラットフォームを提供するオーティファイ株式会社CTOの松浦と申します。「入門 監視」が出版された経緯を少しお話します。「入門 監視」が出版された2017年、私はインフラエンジニアをしていました。ちょうどSREの考え方が台頭してきた頃で、いわゆるSRE本という電話帳のように分厚い本が出版されたりしましたが、その分厚さゆえ、なかなか読破に至りませんでした。そんなとき「入門 監視」のもとになる「Practical Monitoring」が出版されました。これが非常にコンパクトに監視についてまとめてあり面白かったので O’Reilly さんにお声がけし、翻訳をはじめました。2019年に日本語訳が出版されています。技術書は寿命が短いものですが「入門 監視」は比較的、長く読んでいただいており、とても嬉しく思っています。とはいえ原著出版が2017年なので、本日は「入門 監視」の中身を振り返りながら、今、状況が変わっていること、変わっていないことを取り上げてみたいなと思っています。
5年前に出版された「入門 監視」を改めて確認したところ「オブザーバビリティ」という言葉は片手で数える程しか出てきません。オブザーバビリティという考え方や言葉は、この5年間で非常に広まったといえるでしょう。
「システムの振る舞いや内部をどれだけ把握できるか」という度合いになります。オブザーバビリティはあくまでもその性質、システム全体の性質をどれだけ把握できるような性質かに焦点を当てた考え方です。
「入門 監視」を引用すると「コンポーネントの振る舞いや出力を監視し続けること」とあります。つまりシステム全体というよりは、そのコンポーネントの方に焦点を当てています。見るべきポイントが、マクロ的にシステム全体を見るオブザーバビリティに比べ、もっとミクロ的になります。昨今の定義では「高いオブザーバビリティをシステムに対して持たせるために必ず必要な1要素」といったところでしょう。オブザーバビリティの中に包含されるイメージです。
監視の対象も5年間で移り変わっています。
オンプレミス → 仮想マシン → コンテナ → サーバーレス → ？？
このように監視対象は、どんどん抽象化しています。
「アプリケーションをただ動かしたい」という開発者にとっては、サーバーの使い始めが簡単になったため、好都合でしょう。このように抽象化が進んだことでネットワーク、OSといった低レイヤの挙動を意識する必要がなくなりました。一方でトラディショナルな監視をしたままだと、トラブルシュートが難しいケースもあります。
管理の方法に一石を投じる要素としてコンテナオーケストレーションやサービスメッシュなどの考え方があります。
コンテナオーケストレーションツールを利用することで、簡単にコンテナ管理ができる一方、サービスメッシュのような考え方が入ってくると通信経路が複雑になったり、マイクロサービス化することでコンポーネントが増えてきます。
監視というのは、コンポーネントに焦点を当てる、いわば点の監視を寄せ集めたものが監視システムなのですが、それだけだとリクエストや処理がどう行われてるか把握できなくなってきました。こういった流れで線的な監視が必要になってきたと考えています。
クラウド監視サービスも5年間で進化しています。現在、生き残ってるサービスは、APMもあればインフラ監視もあるようなフルスタック的なサービスが多いです。
＜改めて読み直す「入門監視」＞
「入門 監視」の本は第一部ではアンチパターンを挙げて、二部でデザインパターンのお話をする構成になっていますので、まずはアンチパターンから幾つか見ていきたいと思います。
5年前から変わらないこと：「今も銀の弾丸となる監視ツールはない」
何か解決しようと思った時に「まずツールを導入しよう」と考えてしまうケースは、結構多いのではないでしょうか。しかし、銀の弾丸のようなツールはありません。「何を監視したいか」「どう監視したいか」を考えてからツールを選ぶようにしましょう。
どれだけ監視ツールが進化しても、あなたが監視したいことを1つのツールで全て解決できることは、ありません。
「監視」とは複雑な問題を一括りにしたものです。監視はコンポーネントに焦点を当て、そのコンポーネントをどのように監視するか考える必要があります。つまり何を監視するか？どう監視するか？の組み合わせが無限にあるのです。監視対象や方法に合わせた専門化されたツールを使うべきだと書籍では書いています。とはいえ5年前に比べ、フルスタックなツールの選択肢が増えました。いろいろな監視ツールを使い分けるというより、できるだけ監視したいものに合ったフルスタックなツールを選ぶことが理想です。
書籍には「必ずしも、ひと目でわかる必要はない。そのとき必要な情報を見ればいいのである」と書かれています。
ただ5年前に比べ、ツールの性能は上がっています。ダッシュボード1つに全てがまとまっていることは理想的ですし、今はBIツールに監視データを連携させてダッシュボードを作るといった選択肢も増えています。何か起きたときに「ここさえ見れば大丈夫」という状態にダッシュボードをまとめておく努力はしてもいいのかも知れません。
ただし「ひと目でわかる」にこだわりすぎて、ツールの数を無理に1つに絞る必要はありません。
監視の追加やメンテナンスが、特定の誰かの役割になっているっていうのはよくありません。「監視とは、システム開発運用に関わる誰もが持っているべきスキルである」というのが、この本の考え方です。何を監視するべきか？どう監視するべきか？ を一番知ってるっていうのは作った人ですよね。自分が作ったものに責任を持つために監視すべきであるという考え方は、変わらない原則だと考えています。
チェックボックス監視とは「監視しています」というための監視です。例えば「セキュリティ認証のために監視しなさい」と言われたからしています、ということです。これがあまり良くないな、というイメージはみなさん付くのではないでしょうか。言われたからするのではなく、必ず動いているかどうかを監視することが重要です。
動いていることを知りたい場合、OSのメトリクスのように低レイヤのメトリクスはあまり意味がありません。システムがきちんと動いている（レスポンスを返してる）ことを監視したいのであれば、別にOSのメトリクスを見る必要はないよね、という話です。
「監視があるから大丈夫」「何か問題が起きても監視が教えてくれるから大丈夫」と、思考停止してしまうことは危険です。常に監視しなくていいよう改善していく努力は大切です。例えば、監視アラートが上がったり、監視でおかしな値が検出された場合は、そうならないよう改善していくことが絶対に必要です。
1台のサーバーに監視を追加するのにも、大変な手間がかかったりします。しかし監視追加にハードルがあってはいけません。そのため、監視対象の追加削除は最低限、自動化すべきでしょう。今だとIaCで監視設定を管理することも有効です。ツールを活用してなんとかできる部分かなと思います。
先程、監視対象、手法に合わせた専門化したツールを使おう、というお話をしましたがそれらを疎に組み合わせて自分たちの監視プラットフォームを作ろうということが書籍には書かれています。、
監視サービスを構成するコンポーネントが5つ挙げられています。
特化したツールであれば組み合わせて使いますし、最近ではこれら5つが全部載せになっているようなツールもありますので状況に合わせて選択していくことになるのではないかと思います。
書籍でアラートについて面白い記載がありました。「監視は、質問を投げかけるためにある」というものです。アラートを出すのが目的ではない、アラート設定しておしまいではないということですね。脊髄反射的にアラートに反応し、対応して満足するのではなく、何らかの学びを得て次にいかしていくのが良いのではと思っています。
先ほど「OSのメトリクスは意味がない」というような話をしましたが、やはりシステム監視の究極の目的は、ユーザーに対してしっかりとサービス提供ができているか？です。できる限りユーザ視点で監視することが非常に大事だということです。
Webサービスでの究極はSynthetics監視でしょう。直接Webにアクセスし監視する、あるいはリアルユーザーモニタリング（RUM）の仕組みが今どんどん登場してきています。
「監視の仕組みが成熟していないなら、最初から作るな」
完璧な監視システムを初めから作るな、ということですね。まずは世の中にあるものを使ってみて、それから自分なりの監視の仕組みを突き詰めていくと良いでしょう。SaaSやオンプレミスの監視ツールは日々進化しています。自作するより買った方がいい傾向はより強まっているといえるでしょう。
監視システムに限らず、継続的改善が大切です。世の中のあらゆるシステムは、一度作って終わりではありません。例えば、監視対象に変化がなくても、アクセス数の増減など外的要因によって監視状況が変わってきたりします。状況に応じて監視システムを継続的に改善していくことが大切です。継続した注意深さと改善から世界レベルのシステムが生まれるのです。
ここからは Splunk Services Japan 大谷氏に参加いただき視聴者からの質問に答えていきます。
大谷 和紀
Splunk Services Japan合同会社 シニアセールスエンジニア、Observability
現職では、オブザーバビリティ（可観測性）製品を広めて使っていただく係をしています。それまでは業務システム業界でSEとして7年の経験を積んだ後、広告配信サービスを構築・運用をリーダー/CTOとして8年ほど経験しつつ、オブザーバビリティ製品のカスタマーサクセスも担当しつつ、スクラッチからのアプリケーション開発、DevOpsの推進、開発組織の改善などなどやってました。好きなビルドツールはMakeです。
松浦：SaaSの良いところってセットアップが楽なところだと思います。まずフリートライアルの範囲内で使ってみる、色々な機能を試してみるのがおすすめです。それがチームメンバーへの説得材料にもなりますよね。自分自身も腹落ちすると思います。価格表・機能リストを眺めるだけでなく、実際に導入してみることが大切でしょう。このツールは微妙だと思い込んでいたのに、使ってみたら結構良かった！なんてこともありますからね。
大谷：ある程度、業界のベストプラクティスが詰め込まれてますからね。ツールからベストプラクティスを学ぶ、という考え方もできるかも知れないですね。
—先ほどの「まずは使ってみましょう」が回答に近いかも知れませんね。
松浦：そうですね。OSSかOSS以外か……。ベンダーロックインを避けるためなのか、費用面なのかで回答も変わるのですが、費用面の説得ならば、導入したい人がコスト対効果を面倒臭がらずに出すということに尽きるかも知れません。基調講演でも話したように「作るのではなく買う」方がトータルコストが抑えられるという部分は、しっかりアピールした方がいいかも知れないですね。
大谷：過去に「Zabbixの運用に手間がかかっていない」という方がいました。理由を聞いてみたところ、実は相当古いver.を使っていました。「そりゃアップデートの手間がかからないよね」と思いました。見えないコストがリスクをはらむケースがあったりしますよね。
松浦：正直なところ、監視については何か障害が起きたり、ヒヤリハット的なものがあったときでしょうか。プロアクティブに変更するというより、問題が起きてから対応、改善することが結局は多くなりますね。先回りして仕組み化しておくことはもちろん大事ですよね。
大谷：テスト駆動開発でいわれる「不安をテストにしよう」を心がけるようにしています。「この機能って動かないのでは？」と、少しでも頭を過ぎったらテストしようがテスト駆動開発ですが、モニタリングも同じで少しでも不安ならモニタリングしよう、という流れをどんどん作っていけたらカバレッジも広がって良いですよね。
<質問全文はこちら>実際の現場では、インフラ側とアプリ側で運用する組織がわかれている場合もいまだ多いのですが、このような場合にも、スムーズな運用トラブルシュートするために重要だと思うことがあれば教えてください。
松浦：そうですね、大きな会社だとインフラとアプリ側で組織が分かれているケースはあると思います。誰がどのように対応するのかを明文化しておくことが大切です。トラブルシューティングやインシデント管理を例にあげると、最初に対応するのはインフラ側だけど、エスカレーション先に必ずアプリ側が入るとか。ルールにすることで特定の誰かに負荷が偏ったりするリスクも避けられるのではないでしょうか。
大谷：「私はインフラの人だからフロントエンドの指標は見ませんよ」だと、ちょっとうまくいかないですよね。あらゆる情報を集めてみんなが見れるようにしておくこと、情報の壁を無くしておくことが一番重要だと思いますね。
<質問全文はこちら>開発者全員がアラート対応を行う体制を構築する場合、どのような方法が効果的でしょうか？プロダクトに初めて監視を導入する場合、初期は不要なアラートが発生することもあり、SREが全てのアラートに対して対応を行っていきます。その後は全員でアラート対応をしたいですが、SREに負荷の偏りが多いと感じます。
—監視を初めて導入する場合の、立ち上がりについて中心に質問したいのですが、いかがでしょうか？
大谷：まず、SREはチームではなくプラクティスなんです。あなた達のSREのプラクティスを実現するにはどうすればいいか？を考える必要があります。SREプラクティスがいかに大事かを組織全体に浸透させて、最終的に誰がどう動くかを整理し直すのがおすすめですね。
松浦：開発者全員がアラート対応を行うか〜。開発者全員だと、やっぱり偏ってしまうので仕組みで、偏らないようにするのがいいのかなと。監視を直すのは追加した人であるべきというのが私の考え方なので、SREがすべてをやらないことが大切なのかも知れません。
<質問全文はこちら>不安を監視するのは凄く良いなと思う一方、不安をなんでも監視しようとするとコストに跳ね返ってしまって難しいかなと思っています。どう考えるべきでしょうか？
大谷：そのとおりなので、適した道具を使うのがポイントです。メトリクスが向いていないケースがまぁまぁあるので、カーディナリティに注意しましょう。向き不向きについては、監視SaaSのエンジニアに相談しましょう。もし向いていない場合、ログやトレースを使うことを検討してみてください。
松浦：全てをテスト、監視するのはコスト面で難しいですよね。ユーザー視点で不安か？という目線で、高いレイヤからの監視から見ていくと良いと思います。
松浦：ダッシュボード難しいですよね。残念ながら和訳がなくどちらも英語版になるのですが、「入門 監視」の24ページで紹介している2冊をおすすめします。
大谷：基本的には関心のあるデータを1箇所に集めましょうという考え方なんです。ビルトインダッシュボードが進化しているものを使ってもいいですし、それを参考にデータをかき集めてダッシュボードを作るのもおすすめです。
もう1点ポイントなのが、チャートや数字を並べるだけでなく、説明文をしっかりつけてあげるとめちゃくちゃ親切になります。
書籍でおすすめなのは「システム運用アンチパターン」です。この中にダッシュボードの作り方の記載があります。
CTO
大手Webサービス企業にて、大規模サービスのインフラ面を担当した後、GitHubにてテクニカルサポートエンジニアとして勤務。2019年9月にリードバックエンドエンジニアとしてオーティファイに入社した後、2020年1月に取締役CTOに就任。オライリー・ジャパン出版の「入門 監視」を始めとする技術専門書の翻訳も手掛ける。
