00:00
こんにちは、シニアソフトウェアエンジニアのriddleです。
こんにちは、ミドルソフトウェアエンジニアのひびのです。
このポッドキャストは、2人でIT業界の様々な話やキャリア、困ったことを話して、リアルを届けていこうという番組です。
オブザーバビリティとは
今回のテーマは、未経験でもトラブルシュートできる？、オブザバビリティって何なの?
イエーイ!
オブザバビリティについて話すんですね、今回。
そうです。今回はオブザバビリティについて話します。
リドルさんはもう職業がSREじゃないですか。
オブザバビリティにガッツリ関わっていらっしゃる。
そうですね。オブザバビリティの申し訳を言っても、ちょっと言い過ぎですけど。
僕もふわっとした理解しかしてないんですけど、英語から直訳すると監視しやすさとかそういう感じですかね。
その辺も含めてこの後ご紹介するので。
まず、ひみのさん、こんな悩みありませんか?
例えば、トラブルシューティングできるのが経験者のみですとか。
ありますね。特にいろんなシステムが動いてて、サービス構成が複雑になってくると起こる話ですよね。
トラブルシューティングを勘でやってたりしませんか?
トラブルシューティングを勘でやってるは心当たりがありますね。
いいですね。
そういう僕にぴったりの話が。
そう、そういうあなたにぴったり。
あともう一個、アンノーンアンノーンっていう話があるんですけど、これ知ってますか?
アンノーンアンノーン、いや知らないです。どういうことですか?
これね、ちょっと難しいんですけど、4つあって縦横で4小弦作るみたいな話で。
知ってる知らないが横軸、縦で知ってる知らないっていう全く同じラベルのものがあって、
知ってて知ってる、知らないと知ってる、知ってるが知らないみたいな、そういうわけわかんない話なんですけど、
すごいざっくり言うと、ノーンノーン、知ってて知ってると自覚してるっていうのが、
ひびのさん住所知ってますよね?自分の。
住所は、はい、知ってますよ。
ということは、ひびのさんは自分が自分の住所を知っているということを知ってますね。
あー、あれですかね、もしかしてあの、無地の地みたいな。
あーまあ近い近い。
で、あともう3つあるんですけど、知らないとわかっていること。
例えば、ひびのさんパエリア作れますか?
パエリア作れないです。
ということは、ひびのさんはパエリアの作り方を知らないということを知ってますね。
うん、確かに。
なので、知らないことを知ってますね。
そうですね、自分が知らないと自分でわかっている状態ですね。
一方で、知っているが自覚が薄いっていうやつもあって、
例えば、ひびのさん自転車乗れますね?
はい、乗れます。
じゃあどうやって左右のバランスとってますか?
パッと説明できないですね。
うまく筋肉を使って左右のバランスを調整しているんじゃないかと、
パッと出てくるのはそれくらいの回答ですが、
おそらくそんなにまとえてない感じがしますよね。
難しいですよね、いざ説明しようと思ったら。
ということで、知ってるけど知らないんですよ。
うん、確かに。
で、ちょっと話戻すんですけど、
unknown unknown、要するに知らないし、知らないことも知らないっていう状態のことを指していて、
例えば、家の中に配線があると思うんですよ、電源ケーブルとか。
そこから実は隠れた漏電リスクがあるとか、
例えばひびのさんが今まで食べたことないものに対して、
めちゃくちゃやばいアレルギーを実は持ってるとか。
これ知らないし、存在することも知らないですか?
そうですね、確かに。
で、システムにおいても同じことが言えて、
こういうめちゃくちゃ複雑なシステムで、
全然自分が知らないところで知らないことが起こるかもしれない、起きてるかもしれないっていうことがあるかもしれないですよね。
そうですね、それはもうあるものだと思っても良さそうなことですよね、僕らにとっては。
そうなんです。
なので、こういうアンノーアンノーンという領域に対しても、
うまいこと解決できないかっていうところ。
あとはさっきお話ししたトラブルシュートできるのが経験者のみとか、
勘でやってるみたいなところをうまいこと解決するのがオブザーバビリティです。
おー、なるほど。
それは気になりますね。
そうでしょ、これ気になるでしょ。
はい、ということでオブザーバビリティ入ってきます。
オブザーバビリティって日本語で言うと過観測性って言うんですよ。
過観測性、監視できること。
そうですね、観測できることってニュアンスなんですけど、
今回自分が読んだ本はオブザーバビリティエンジニアリングっていうオライリーさんから出てる本をベースにするんで、
ちょっとそこの話だと思って聞いてほしいんですが、
この本ではオブザーバビリティの定義を書かれていて、
この中ではシステムがどんな状態になったとしても、
めちゃくちゃ奇妙な状態だったとしても、
特に何のデプロイもせずに今の状態だけで理解して、
何が起こっているかを説明できるかどうかのしやすさを
オブザーバビリティがある状態で定義してました。
なるほど、じゃあ何かしらをデプロイして、
その挙動の差分が多分割れることを期待してデプロイするんですよね。
それを見なくても本当にまっさらな状態、
例えばインフラストラクチャーズコードを見ただけで、
どういう構成で動いているかとかが理解できる状態、
みたいな認識であってますかね。
ちょっと違ってて、例えば我々が本番環境に何か起こったときに、
分かんないからデバックログを仕込んだりすることあるじゃないですか。
ありますね。
絶対あると思うんですけど、
これをやらずに何か問題が起こったら、
こういうこと起きたんだなって判断できることっていうのが
オブザーバビリティのある状態ですね。
なるほど、なるほど。
これできたらめちゃくちゃ強くないですか。
だいたい何か変なことが起きても、
我々は何も手を入れずに取っているデータだけで、
ここ怪しいぞとか、
これ多分問題ここちゃうかみたいなことが分かる。
そうですね。
いやすごく大事ですよね。
なかなか実際に実データを見ないと分からないみたいな状況もある。
逆にそういう状況を作らないみたいなことも
オブザーバビリティに含まれるんですか。
それは含んでないですね。
どっちかっていうと、この後説明するんですけど、
大量のデータをとにかく集めまくることで、
後で状況を再現しやすくなるとか、
状況を追いやすくするっていうのがコアのコンセプトですね。
なるほど、なるほど。
なんとなく理解しました。
なんとなく分かっていると思うんですけど、
なんでこのオブザーバビリティってものが必要なのかについて紹介しますね。
モニタリングとの違い
最近はもうマイクロサービスアーキテクチャとか
分散システムみたいなものが割とよく聞く話になってきて、
よりシステムが大規模になったり複雑になったりみたいなことをしてるじゃないですか。
それに対応するために、例えばカオスエンジニアリングみたいな
本番環境で無理やり問題を起こすことで、
本来だったら気づけないような問題に気づくことができるみたいな
そういうアプローチがあったりだとかしてると思うんですけども、
そういう感じでアンノーアンノーな領域が増えてきたというのが
まず前提でありますと。
プラス、経験者のナレージで何とかしてきて、
でもその経験者いなくなったりとか、
経験者1人じゃさすがにカバーできないよねぐらいに領域が広がってくると、
チームとして運用が回らないので、
そういうところからこの新しい考え方っていうのが出てきたという感じです。
なるほど。
よく聞く言葉でモニタリングってあるじゃないですか。
ありますね。
この本でもモニタリングとオブザーバビリティって何が違うのってことは明確に説明されています。
何だと思いますか?
モニタリングとオブザーバビリティの違い。
うまく説明できないな。
僕の認識ではモニタリングって例えば、
ある環境で起こっているエラーのログだったりとか、
あとはデバッグログも含まれるのか、
そういうものの監視のしやすさまでいくとオブザーバビリティか。
ただ分かるんですよ。
さっきリドルさんがおっしゃった大量のデータを蓄積して再現しやすくするっていうコンセプトとは若干違う話ですよね。
モニタリングっていうのは。
そうですね。
例えばよくあるインフラレイヤーのモニタリングの話をすると、
CPUのメトリクス、今何%使ってますよとか、
ディスクが何%使っててもう少しでディスクがいっぱいになりますよみたいなものもモニタリングだったりしますし、
ログでエラーやワーンが出てるみたいなのもモニタリングでやってるところ多いかなと思います。
これが何が違うかというと、
さっきの4証言の話、知ってる知らないみたいな話を思い出してほしいんですけど、
モニタリングって事前に設定するじゃないですか。
そうですね。
なので知ってることしか分かんないんですよね。
確かに。
なので僕らはCPUが高騰すると怪しいっていう経験をしているので、
CPUをモニタリングしましょう。
90%に敷地設定して、それを超えたらアラートを出すようにしましょうっていうアプローチを先に打ってるんですけど、
オブザーバビリティはどっちかっていうと、
いろんな情報を取りまくっておいて、その情報が普段と違うとか、
こっちとこっちのサービスでちょっと差分が出てるとか、
このクラウドとこのクラウドで違うとか、
そういう規格によって問題を特定しましょうとか、問題を見つけましょうっていうアプローチですね。
はいはいはい、なるほどなるほど。
どうやってオブザーバビリティを高めるって話なんですけども、
今ってモニタリングとかするときにどういうデータを取ってますか普段。
モニタリングをするとき、さっきおっしゃったようなCPUのメトリクスだったり、
エラー、ログ、
あとはエラーに限らずリクエスト単位のデータも含めて、
ログとメトリクスと、あともう一個あります。
ログ、メトリクス、あとは、わからない。何ですか。
トレースですね。
あートレース、スタックトレースみたいなことですかね。
違います。分散トレーシングって呼ばれるやつで、
トレーシング技術の基礎
スパンとかコンテキストみたいな概念が出てくるんですけど、
例えば複数のサーバーで通信を行っている際に、
このサーバーでどれくらい時間がかかって、
次のサーバーでどれくらい時間がかかって、
最後のサーバーでどれくらい時間がかかったっていうものを
収集するための技術でトレーシングっていうものがあるんですけども、
例えばABCやって、リクエストが飛んできたら、
まずAがHttpリクエストを受け付けます。
そのタイミングで、次Bに投げますよね。
そのタイミングでAで最初に受け取ったHttpリクエストに付いている
スパンIDみたいなものがヘッダーにあるんですけど、
それを親として子供のスパンIDを発行して、
Bに投げ、BからCに投げみたいなことをやって、
戻ってくるとCがどのくらい時間かかったか、
Bがどのくらい時間かかったか、
最終的にAがどれくらい時間かかったかっていうデータを
全部外に投げることで、
どこのサーバーで時間がめちゃくちゃ食ってるのかっていうのを
測定するための仕組みがあって。
ワイドイベントの重要性
あれですね、データドックで見られるやつ。
そうそう。APMとかよく言われますね。
AWSだとクラウドAPMみたいな、
ちょっと名前忘れちゃいましたけど、
Googleクラウドだとクラウドトレースとか。
いろんなツールでAPMって見られることができるかなと思います。
APMちょっと怪しいかも。
APMはもうちょっと関数単位とかだったりするんで、
どっちかっていうとサービス間とかの方が
イメージは近いかな。
複数マイクロサービス間での関係性を追うっていう意味での
トレーシングっていうことですね。
そうですね。一応単体のサーバーでも全然使えて、
データベースの問い合わせとか、
Redisとかのメモリストアみたいなものへの問い合わせとか、
そういう外部の問い合わせに対してもスパンを発行できるので、
それぞれどれくらい時間がかかってて、
リクエストのうちどこがボトルネックなのかを
調べたりすることもできるような、
ここ10年くらいで結構使われるようになってきた話かなと思いますね。
ログとメトリクスとトレースと今3種類あるんですけど、
日比野さんも監視とかされたことあると思うとわかるんで、
それぞれ全然別の画面で見ませんか?
そうですね。おっしゃる通り。
メトリクスはダッシュボードでこうね、
CPUとかリクエストツールとか。
そうですね。
ログはログビューアーがバーってあって、
トレースはちょっと見たことないかもしれないですけど、
トレースのやつがあって、
それ見るとどういうリクエストがバーってあるかみたいな。
基本的にリクエスト単位で見るビューですもんね。
そうなんです。
かつあれですよね、
普段業務で扱ってると、
別々のタイミングで見ることが多くなってくる指標でもあるのかなと。
例えばメトリクスって、
主にインフラエンジニアの人が見る、
ミーティングで見るみたいなことが多い。
確かに。
実際にエラーログとかは、
具体的なトラブルシューティングで見ることが多いし、
なんとなく役割も分かれてくる気がしますね。
そうですね。
ただ実際は、システムを安定的に動かそうと思ったら全部見るべきじゃないですか。
はい、おっしゃる通り。
なので、この本の著者も言ってるんですけど、
全部一緒に見せろと。
バラバラんとこ行って見に行くのはめんどくさいし、
非効率的だと。
なので、この本の作者は新しいイベントを提唱していて、
今後はこれを送れというものを言っています。
今後はこれを送れ。
それは何ですか?
それはですね、この本ではワイドイベントと紹介されてますね。
ワイドイベント。
広いイベント。
何かというと、
単純に言うと、メタデータを300から400個くらいくっつけたイベントを送るってことですね。
なるほど。
それはあれですか、例えばイメージだと一つのリクエストがあります。
はい。
その一つのリクエストにはどこでどれくらい時間がかかっているかのトレースがまず含まれるじゃないですか。
そのサービス、各サービスで出たログがそこの中にメタデータとして含まれています。
さらに各コンピューターでのメトリクスみたいな情報も含まれていますみたいなイメージですか?
いや、どっちかっていうと、例えばHttpリクエストに対するワイドイベントを発行する場合のイメージで言うと、
日見野さんがスマホでリクエストを送ったとしましょう。
そうしたら日見野さんが使っているアプリはバージョンいくつで、Ratterのいくつで開発されていて、
iOSバージョンはいくつで、日本語で使っていて、ロゲーションはここで、IPアドレスはこれでみたいないろんなメタ情報があるじゃないですか。
それらを可能な限り全部つけるんですよ。
リクエストパラメータがこれで、こういうリクエストが飛んできました。
例えばAWSで動かしていたら、AWSの東京リージョンのAzaにあるインスタンスのメタデータの番号がこれで、
インスタンスIDこれで、何時何分にこういうHttpヘッダーで飛んできました。
っていう情報を全部取ってきて、レスポンス回すときもレスポンスとしてこういうデータ。
もちろんセキュアなデータはマスクすると思いますけど、全部こういうデータを返しましたみたいな、
要するに後でリプレイできるようなもの。
なるほど。
レベルのものを収集することによって、全部わかると。
なるほど。
ちなみに今のリドルさんの説明だと、いわゆる今説明いただいたのがワイドイベント、ワイドデータっていうものの全容ってことですよね。
そのコンセプトだともしかして、リクエスト自体が再現できれば、
メトリクスの情報は不要、なぜなら同じコンピューターを使えば再現できるはずだから、みたいな感じですか?
これにメトリクスってどういうものを指してますか?
例えばリクエストを処理したときのCPU利用率だったりとか。
だからワイドイベントの中に含めるんでしょうね。
そこも含まれているんですね。
全然含めていいはずです。
本当に一つのリクエストを再現するのに必要十分なデータ全て含まれているみたいな感じですかね。
そうですね。これをいっぱい集めると何が嬉しいかっていうと、
カーディナリティっていう概念あるじゃないですか、データベースにいきなり話しますけど。
カーディナリティは?
データのばらつきのことですね。
高カーディナリティっていうとユニークに限りなく近いようなデータの集まりになっているので、
それぞれバラバラのデータだし、低カーディナリティっていうと、
どの値も1から4のいずれかしか取らないとか、
そういうことを言うと思うんですけど、本当にいろんな属性のデータが集まるので、
イベント単位にバラバラですよね。
で、そういうイベントをある程度まとめて見てみると、
最初冒頭にもしゃべったんですけど、
AWSのAZ、Aだけでレイテンシーが上がってるとか、
このインスタンスだけおかしいとか、そういうのが見えてくるんですよね。
そうするとそこからAWSに問い合わせを上げたりとか、
ここのサーバーをとりあえず落としてみるとか、
そういうアプローチができるようになるので、
オブザーバビリティが高い状態と言えるよねっていうところが書かれていましたね。
オブザーバビリティの向上
なるほど、理解できたような、できていないような。
ちなみに何だろう、多分一つのリクエスト単位でも、
本当に不要なものまで全て含めて蓄積しているってことですよね。
そうです、あってます。
不要かどうかわかんないですね、unknownunknownなんで。
そうですね、unknownunknownをそれに気づくためにも必要ではありますよね。
不合的なストレージの使い方をしなきゃいけないのかなって今思って。
そうですね、なのでMavicっていう概念はやっぱりあって、
どれくらいのサンプリングレートで取るかっていうのは一定あるみたいですね。
サンプリングレートっていうのは、例えば単位時間あたりで、
蓄積していくのは実際はこのくらいの数のリクエストくらいですよみたいな意味ですか?
そうですね、そもそもサーバー側でサンプリングレートを1%設定したら、
100リクエストしたうちの1つだけワイドイベントとして送るって感じです。
なるほどなるほど、本当に何というか、
オブザーバビリティを高めるためにサンプリングしているっていう、
もう何かモニタリングのために取ってるデータとは別枠のデータみたいな感じなんですね。
そうですね、サンプリングしてる理由は単純にコストの話ですね。
だから不合だったら全部送ればいいし。
まあそうか。
なのでこれ勘違いしないでほしいのが、
オブザーバビリティでワイドイベントを送るんですけど、
これあくまで傾向を掴むためであって、原因を特定するためのものじゃないんですね。
そうですよね、オブザーバビリティのためのデータだと。
だからAZAが怪しそうって気づいたら、
AZAで何が起きてるか自体はもう分かんないんでAWSに問い合わせしてほしいですし、
このAPIでだけ何かおかしいことがあるってなったら、
例えばそれはエラーが出てるならエラーツールみたいな、
エラー集積してるツールみたいなものがあると思うんで、
そういうものからどこの行がおかしいんだろうかみたいなものを見てもらったりとか、
そういうアプローチになるので、あくまでいつもとおかしい場所とか、
そういうものを探すっていう感じですね。
なるほどなるほど、あれですね、
今思ったのはオブザーバビリティを高めるためのワイドイベントを
常に適切しているってことじゃないですか。
ある種機械的に今どこがハズレ地位として現れているかとかも通知できそうですね。
そうですね、AIと組み合わせてその辺りやるみたいなツールに組み込まれたりっていう例もあるので、
そういうここ怪しいよみたいなものの提案とかは割とAIのやる分野というか、
確かに。
やってくれるっぽいですね。
オープンテレメトリーの導入
今のそれこそここ最近のLLMとものすごく相性がいい技術というか、そういう感じがしますね。
ただ難しいのはさっき高カーディナリティって話をしましたが、
300から400ぐらいカラムがあるわけじゃないですか。
そうするとどういう組み合わせで持ってきて比較するのかって相当膨大な計算になるので、
多分AIに全部やらせるっていうのはちょっと難しいというか、
どうなっていくかをちょっと注目したいですね。
確かに怪しいデータの抽出までは本当に試測演算でできる範囲でやってとか、
実際の処理にかかるコストとのバランスを取る感じにはなりそうですね。
そうなんですよ。
ここまで聞いてひめのさん、オブザーバビリティ入れたくなりましたね。
オブザーバビリティ入れたくなりましたが、
これは今僕が関わっているサービスの例なんですけど、
複数クラウドにまたがったサービスを運用していて、
そうなるともしかしたらちょっと例えば連携周り、トレース部分でやりにくいところがあるんじゃないかなって思いました。
素晴らしい。ありがとうございます。
皆さんはそうおっしゃるんですよ。
そんなためにですね、最近そういったログとかメトリックスとかトレーシングについては標準企画が出ました。
なんと。
これがオープンテレメトリー、通称OTELと呼ばれるやつですね。
聞いたことある。オープンテレメトリー。
聞いたことありますか。
昔、オープンセンサスってやつとオープントレーシングってやつに2つに分かれてたんですけど、
よくわからなかったんで統一したんですよ。
よくわからなかったんでっていうのは本当かわからないですけど、
僕はよくわからなかったんで、それが統合してオープンテレメトリーってやつ1本になりました。
その企画化されてるってことは、
じゃあ例えばもしかしてAWSで取ったオープンテレメトリーに準拠したワイドイベントと
Googleクラウドで取ったオープンテレメトリーに準拠したワイドイベントを
例えば後々1つのデータストアに置いておけば後はもうトレーサーIDみたいなので
紐づけて分析が可能みたいな感じですかね。
そうですね。
何だったら別にだからAWSからデータドロッグに追ってる経由で送って
Googleクラウドからも追ってる経由でデータドロッグに送るとか。
そっかそっか。
このAPMの部分でもそっちの企画に変換しちゃえば使えちゃいますね。
すごい。
APMっていうかごめんなさい何かちゃんと言うと
オープンテレメトリーがSDKをたくさん出してるんですよ。
GoのSDKとか。
そのSDKを組み込むとHTTPリクエストが来たときに
オーテルベースのものを指定したところに投げてくれるんで
それを先をGoogleクラウドにするのかデータドロッグにするのか
はたまたAWSなのか他のサードパーティー系のものなのかわからないですけど
同じような書き方でいけると。
便利な時代ですね。
そう便利なんですよ。
しかもオープンテレメトリーはセマンティック企画っていうものを用意してくれていて
これ何かって言うと
HTTPリクエストだったらこういうものを取りなよみたいなの決めてくれてるんですよ。
それが準拠していれば作られてるんで
組み込むだけでその必要なものは全部投げてくれる勝手に。
ほうほうほう。
でプラスオーテルで投げられるようになりました。
今度は見える側が欲しいですよね。
見える側が欲しいですが
それがデータドロッグのダッシュボードとかそういう話じゃないですか?
あ、そうです。合ってるんですけど
ちょっと自分も詳細は不確定なんですけど
本の内容だけ言うと
ここの本で提唱しているオブザーバビリティの話と
各モニタリングとかやってる会社が出しているSaaSのオブザーバビリティが
厳密にはイコールじゃないので
オブザーバビリティ高めるためにこのツール入れてくださいってやつが
必ずしも一致してるわけじゃないみたいな話をしてるんですね。
オブザーバビリティカンファレンス
ポジショントークになると思うんですけど
この本の作者はハニカムっていうSaaSを出してて
そこがめちゃくちゃオブザーバビリティを推進してるんですね。
でこの本も出してるんで
そこのハニカムってやつはめっちゃいいよみたいなポジショントークをしてて
なるほど。
一応それ以外にも自前で構築する手段として
ELKスタックって呼ばれる
エラスティックサーチ、Kibana、B2、ログスタッシュっていう
OSSを組み合わせて自分で作ることでも一応同じようなことはできるけど
めっちゃ大変だよみたいなことが書かれてます。
なるほど。オブザーバビリティ改善なら
今はこれだよねみたいな組み合わせがあるってことですね。
そうですね。
昔のランプスタックみたいな。
そうそうそう。チャームスタック。そういうやつ。
なるほど。
なのでオープンテレメトリーのSDKを組み込んで
何かしらのクラウドなのか自前で構築したところにデータを送れば
あなたも明日からオブザーバビリティマスターになるという感じです。
なるほど。すごくわかりやすかった。
なんかここまで聞くとあれですね
次は具体的にこういう改善ができましたみたいな事例が気になりますね。
またいいフリありがとうございます。
実はですね私がコアスタッフを務める
オブザーバビリティカンファレンスと呼ばれるCNCFが
ホストしているイベントが2025年の10月27日にありますので
そんなあまりにもタイミングが良すぎる。
仕込みか?
じゃあ実際に各社の具体的な事例とか
こういうことしたらめっちゃ良かったよみたいな話が聞ける
素晴らしいイベントがあるってことですね。
マジやらせみたいになった。
これ僕全然リドルさんからこの話は聞いてなかったんですよ。
でもいいイベントですね。
ありがとうございます。
ちょうど今私が裏の方でどういうプロポーサルを募集するか
みたいなことを検討したりしているので
そこでですね決まったら募集しますので
いろいろ皆様からの面白いエピソードというか
こんな挑戦したよみたいなものを
ぜひ応募していただけると嬉しいです。
ということで今回はオブザーバビリティについて
モニタリングとの違いとか
経験者が必ずしもいなくても
いなくてもって言い過ぎかもしれないですけど
経験者頼りにならない問題解決の方法
トラブルシューティングの方法みたいなものを紹介しました。
ゆなさん全体どうでしたか?
オブザーバビリティについての知見がめちゃめちゃ深まった
ありがとうございます。
よかったです。
このポッドキャストではハッシュタグゆるITで
皆様からのコメントや意見募集しております。
またエピソードの概要欄からですね
グループフォームのリンクもありますので
そちらからの投稿も大歓迎です。
ありがとうございました。
