みなさんこんにちは。マネージドサービス部MSS課の塩野(正)です。
オブザーバビリティ(Observability)という言葉はよく目にするようになりましたが、オブザーバビリティってどういうこと?オブザーバビリティを実現すると自分の生活がどうよくなるの?という観点で、オブザーバビリティのことをわかりやすいくお伝えしたいと思います。
オブザーバビリティ(Observability)とは
目次
想定読者
- 運用監視の担当者やアプリケーション開発の担当者
- オブザーバビリティがよくわからない方
オブザーバビリティの基礎
オブザーバビリティという言葉の定義で話題から外せないのは、こちらのオライリー社のオブザーバビリティ・エンジニアリングの本です。
出版社 :オライリー・ジャパン
そしてオブザーバビリティを説明する上でよく引用されているのがこの部分で、オブザーバビリティという言葉を端的に表現しています。
1 章 オブザーバビリティとは? :P31より引用
簡単に言うと、私たちが考えるソフトウェアシステムの「オブザーバビリティ」とは、システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明で きるかを示す尺度です。
余談な話になりますが、「オブザーバビリティ」という言葉の起源は、1960年代の制御理論までさかのぼります。1960年代初頭に、ルドルフ・カルマンは動的なシステムの内部状態を外部からの観測データに基づいて推定する概念を提唱、この概念が「可観測性(Observability)」と呼ばれ、「オブザーバビリティ」の語源と言われるようになりました。その後、オブザーバビリティの概念は、システム工学、情報科学、社会科学など、様々な分野に広がりました。特に、複雑なシステムや大規模なデータを扱う現代社会において、オブザーバビリティはシステムの理解や問題解決に不可欠な概念となっています。
オブザーバビリティを身近な例でたとえる
もう少し身近な例におきかえて話を進めましょう。
例えば風邪を引いた場合を想像してみてください。さっきから自分の体調が悪くなったように感じています。 その後、なんだか寒気がしてきて、咳や鼻水が出てきました。この状況から、おそらく症状から自分が風邪をひいているかもしれないと考えられそうです。
ここでは、自分の体からいくつかの重要なアラートが発生していると推測することができます。
寒気がするからおそらく熱が出ているだろうということで、市販の風邪薬を飲んで、おでこに冷えピタを貼って、とりあえず布団で横になるのがいわゆる従来型の監視の対応と同じ対処療法です。
原因は「おそらく風邪」だけど、「風邪」なのか、「インフルエンザ」なのか、「コロナ」なのか、「それ以外の病気」なのか現状は全くわかりませんが、とりあえず風邪っぽい症状なので市販薬を飲んでぐっすり寝ましたという状況です。
ここまでの内容を監視の話に戻すと、なんだかサーバの調子が悪くてリソースの使用状況を見てみるとCPU使用率やメモリ使用率が100%で張り付いていることがわかりました。過去の経験から、このような場合はとりあえずOSを再起動したら復旧したので、今回も復旧優先でOSを再起動しようという対処療法をおこなうパターンでしょうか。
毎回OSを再起動しているけど、原因って何だろうと思っていても、調べるための情報が手元にないと何も調べることができず、仮説すら立てられませんね。
病気の話に戻しますが、寒気がするけど熱があるかどうかわからない時はどうしますか?そんな時に使用する伝家の宝刀、もとい、みんなの便利アイテム「体温計」をきっと使っているはずです。
絶対に熱があると思って体温計で測った結果、実は平熱だったということで、なんだか残念な気持ちになったことはおそらく皆さん経験されていると思います。 その反対に、体調が少し悪いような気はするけどまだ元気と思っていて、念のため体温計で体温を測った時に39.5°と表示されると、一気に体調が悪くなったような気がするというのもきっと経験されていると思います。
体温計は現状を把握するためのひとつの道具で、それ以上でもそれ以下でもありません。体温計の数字は専門家である医師も当然確認しますし、素人である私たちも確認します。37°を超えると医師でも素人でも熱があるだろうと定量的に判断できるでしょう。なんとなく熱っぽいという状況だけでは定性的すぎて、実際に熱があるのかどうか判断できません。
監視もそうですが、オブザーバビリティの最低ラインはこの部分です。クラウドにリフトシフトした結果、API連携やマネージドサービスを使った複雑怪奇なシステムになっているそのシステム自体の現状把握って本当にできてますか?・・・というアンチテーゼでもあります。
そういう観点では病気も複雑怪奇なものになるかもしれません。ひとつの症状だけでは断片しか見えておらず、複数の症状や身体の状況を加味した結果、おおよその原因が特定されるものだろうと推測します。そんな病気の原因を調べる時は殆どの人が病院に行って見てもらっているはずです。では病院ではどのようなことをして病気の特定をしているのでしょうか。
病院に入って最初の一言に「オレすっごく体調悪いねん。あなたは医師というスペシャリストだから、見ただけで原因わかるやろ。原因と対処方法を教えて!」と言ったとしても、きっと「とりあえず検査してみましょうか」と促されるでしょう。
「オレすっごく体調悪いねん。見ただけで原因わかるやろ。すぐに治して!」と病院で叫んでいる人はきっとこのブログを読んでいる人の中にはいないと思いますが、インフラ担当やアプリ担当に対してすご~く雑に、「担当しているシステムの調子が悪いねん。こっちは何も触ってないけど調子がおかしいってことは、そっちでなんかやったんじゃない?原因調査と対処して!」といった発言をしたかどうか胸に手を当ててみて考えた結果、心当たりがあっては絶対にダメです。そのシステムや環境には間違いなくオブザーバビリティが足りてません。
仮にそういう発言をしたとしても、担当するお医者さん(インフラ担当、アプリ担当)は情報が何もないから困ってしまいますし、根本原因を特定するためにはとりあえず検査などで情報を集めて、状況を把握する必要があるでしょう。
病院では必要に応じて医師が血液検査をしたり、呼吸の乱れやリンパ腺の腫れを確認したり、インフルエンザ、コロナなどの検査キットを用いて検査をおこなうでしょう。その結果、インフルエンザの検査キットで陽性反応が出たら、その体調不良は「インフルエンザ」だったと判明します。
これは現代のシステム監視でも同じように考えることができ、MELTと呼ばれるメトリクス、イベント、ログ、トレースなどの情報を集めてシステムの状態を可視化する必要があります。可視化した結果を分析することで、応答が遅いのはSQLの構文が悪かったと判断できたり、APIのレスポンスにムラがあるためバッファを効かせる必要があると判断できたり、ショッピングサイトでカートのレスポンスが遅すぎて離脱している可能性があると推測できるとか、見えてくるものがたくさん出てきます。それらを定期的に確認しながら一つ一つ丁寧に潰していくことでシステムの安定性や堅牢性をもっと高めることができるという考え方こそがオブザーバビリティ(Observability)という概念になります。
システムの障害はインフラ起因のもの、アプリケーション起因のもの、それ以外のものなどたくさんありますが、ただシステムの障害を回避するためだけにオブザーバビリティを活用するのは本来もったいない使い方になるのかもしれません。オブザーバビリティは情報を集めて分析し、分析した情報を組織として活用していく文化でもあります。こうした情報を積み重ねて分析し活用することで、インフラ担当、アプリ担当のトラブル対応における工数の削減だけでなく、ウエブサイトの売り上げ向上、開発者の生産性向上など様々なメリットを享受できるでしょう。
まとめ
オブザーバビリティ(Observability)について身近な例に例えて表現してみましたが、最近オブザーバビリティという言葉をよく聞くけどそれって美味しいの?という目線の方がまだまだ多いように思います。クラウド環境をフル活用することで、システム開発のスピードをアップしたりオンプレ環境よりコスト削減できる反面、自分が理解できない機能が増えたことによる従来型監視の限界こそがオブザーバビリティという言葉が浸透してきた背景ではないかと私は考えています。
オブザーバビリティをもっと活用してみたい、オブザーバビリティを始めてみたいけど何から取り組んでいったらいいんだろうという方に向けたオブザーバビリティの導入を促進するサービスのご紹介をおこなっております。オブザーバビリティを始めるには専用のツールを使う必要があり、弊社ではアカウント開設などを含めた伴走型支援サービスをご用意しておりますので、もしオブザーバビリティの活用にご興味がある方は、こちらのお問合せフォームよりお申し付け頂けましたら幸いでございます。