はじめに
最近仕事の関係でObservability（オブザーバビリティ、可観測性）という単語をよく耳にするのだけど、今ひとつ周りの人と自分の解釈にズレがあったり言いたいことがうまく伝わらないことが多いようなので、備忘録も兼ねて自分の考えをダラダラと書き認めていこうかと思います。
これは業務や様々な書籍等で得た知識や経験を元に私個人の独断と偏見で思いの丈まとめるものなので悪しからず。
解釈は人それぞれあるとは思いますが、ここに書くことは大概間違ってはいないと信じています。
子どもの頃から文章を書くのは苦手だったので、読みづらいとか文章下手くそとかそういうクレームは勘弁してください。心折れるので。
ちなみに通知表の国語の成績は毎学期2でした。5点満点で。
背景
Observabilityを語る上で欠かせないのがDevOpsというコンテキストでしょう。
何年も前から言われていることですが、Dev（開発）とOps（運用）がお互い相反する利害関係の中であっても協力関係を築き、システムの開発と運用のサイクルを回してビジネスの継続的な運営と成長を目指しましょうという話があります。
DevOpsという単語でググると必ずと言っていいほど出てくる無限マーク（これ → ∞）の絵が出てきます。
Plan --> Code --> Build --> Test --> Release --> Deploy --> Operate --> Monitor --> そしてまたPlanというアレです。
DevとOpsそれぞれが担うプロセスでもって、継続的にサービスが成長することを示してます。
ここで特に重要なのは、MonitorからまたPlanに遷移するとこだと思います。
リリースしたサービスが適切に稼働しているか、エラーが出ていないか、パフォーマンスが劣化していないか、UXは向上したか、ビジネスにポジティブなインパクトを与えているか、等々を Monitor し、その結果を以て次の Plan に繋がるということです。
継続的にサービスを開発・運用してビジネスの成長につなげるためにはリリースしてお終いではなく、Monitorから再びPlanへとつなげることが重要なんです。
とは言っても、ただ監視しているだけでは当然良くないです。
問題が発生したら原因は何か、どう対処するかというのも含めて監視する必要があります。
そこでObservabilityという概念が重要になります。
Observabilityって何？
監視（Monitor）と何が違うの？
簡単に言うと、Monitorは「目を見張って事象を見る」こと、Observabilityは「問題が発生したとき、どこで問題が起きているのか、何が原因なのかを紐解くこと」に尽きると思います。
そのためには当然データを集めることが必要になりますし、それを運用で活用できる形で可視化したりアラートを作成したり詳細へとドリルダウンしたりということが求められます。
よくメトリクス、トレース、ログの3本柱でObservabilityを実現というような話を聞きますが、間違いではないですが、その3種類のデータを集めること自体がObservabilityの本質ではないと考えています。
重要なのは、それらのデータを以て「どれほど容易に状況を把握し事象を正確に把握できるか」「容易に観測することがどれほど担保されているか」というのが重要なポイントとなります。
メトリクス、トレース、ログ
これら3種類の性質の異なるデータそれ自体が意味を持つのは、コンテナやサーバーレスといったクラウド技術の台頭に伴うものでしょう。
何千というソースファイルと何百万行というソースコードから成るwarやearで固めたモノリシックなアプリケーションでは、Bytecode Instrumentationでアプリケーションのボトルネックやエラーをコード単位で捉えたり、スレッド単位で内部を解剖するようにパフォーマンスを捉えて運用するということが好まれることがあります。
もしくはログを監視してエラーを検知したらアラートを出して、ログからエラーメッセージを読み取ったり、ログに出力された情報でステップごとにデバッグするということが多々あると思います。
一方で、クラウド化に伴ってアプリケーション内のそれぞれの機能をサービスという形で切り出してお互いのサービスが疎結合して稼働するようなマイクロサービスの世界では、パフォーマンス監視するアプリケーションそのものの定義というかアーキテクチャーが変わってきます。
コンテナのようにリソースの入れ替わりが激しくライフサイクルが短い場合、また、予測不可能なタイミングやボリュームでスケールする環境では、ログだけで監視しようというのは、とてもじゃないけど現実的ではありません。
先述したようなAPMを活用しようとしても、言語やフレームワークも多様化するので、単一の監視方法というのが通用しなくなります。
様々な言語に対応したInstrumentationで実現する分散トレーシングという考え方が重要になります。
ZipkinやJaegerではそのクライアントライブラリから取得される情報は外部サービスとどのように連携しているか、サービス間の連携に問題がないかということを中心とした分散トレーシングとなります。
当然それだけでは内部の挙動まで追っていくことはできないので、ログで詳細を確認すると言う形で補うことが必要となります。
結果として、メトリクスで「何が起こっているのか」、トレースで「どのように問題が起きているのか」、ログで「なぜそのような問題が起きたのか」というのをそれぞれのデータの性質に合わせて観測することが重要になってきます。
この3種類のデータはどちらかというとシステム内部で発生するデータです。
他にもSynthetics（外形監視）を活用してSLIの測定をすることだったり、RUMでUXを把握することで、外部からユーザー影響やビジネスインパクトというのも同時に把握できますね。
ここらへん簡潔にまとめるのが難シイデスネ
実践するには？
Observabilityを謳う製品やサービスは世の中にたくさんあります。
CNCFのカオスマップでも Observability and Analysis にOSSからライセンスSW、SaaSまで様々なプロジェクトや製品が並んでいます。
その中で何がベストなのか？
使いやすさやスケーラビリティ、価格等々の観点から選ぶことがあるでしょう。
自分の好みと業務や運用方針との親和性が重要だと思いますが、ここでは製品の特長に言及するのはやめときます。キリないし。
何かおすすめのツールあったら教えてください。
まとめ
後半グダグダになったけど、一番言いたいのは、Observabilityナメんなってことです。
本気出せばこれだけで一晩語れます。しないけど。
Observe + ability ということで、 いかに容易に且つ的確に事象を捉え観察して正確な対処につなげられるか ということだけでもわかっていただけたら、ちょっとだけ頑張ってこの記事書いた甲斐があるというものです。
こんな読みづらい文章を最後まで読んでいただいてありがとうございます。
気が向いたらてにをは直して清書するかもしれません。いや、たぶんしません。