『SoftwareDesign 2023年 6月号 特集「改善につながるオブザーバビリティ」』を読んだ
これまで縁のなかったオブザーバビリティに入門したかったので読んでみた。3章構成で、1章はオブザーバビリティについての概要、残りの2章は企業での実際の取り組みについての特集だった。
感想
オブザーバビリティの成熟度が高いと、システムやビジネスに与える影響が甚大である「認識しておらず、理解しておらず、監視していないもの（Unknown Unknowns）」に対して、問題に気付いたり、理解できなかった問題に対する答えを見つけ出せるようになるようになると理解した。※言葉の使い方としてはオブザーバビリティができている / できていないという言い方より、オブザーバビリティの成熟度が高い/ 低いという言い方が正しそう。
監視はシステムの健康状態を定期的にチェックする方法です。（省略）一方、オブザーバビリティはシステムの内部状態を観測し、エンジニアがシステム最適化のための洞察を得られる能力です。（省略）オブザーバビリティは監視を内包しており、監視自体は引き続き重要な手法として存在し続けています。
NewRelicの提唱するオブザーバビリティ成熟モデルでレベル2まで到達できていれば、機能としては問題ないがパフォーマンスが良くないところを改善できる。また、レベル3まで到達すればサービスを顧客がどのように使っているか可視化できる。NewRelicの提唱するオブザーバビリティ成熟モデルを使えば、自分が携わっているプロダクトのオブザーバビリティの成熟度がどこかわかり、レベルを上げることで得られる効果の説明がしやすそう。
おまけ
大まかな概念や実際の取り組みがわかったところで、手元で動かして体感したいと思い、JSUG勉強会のSpring Boot 3.0 オブザーバビリティツアーガイドで実際に体感してみた。
ツアーガイドの環境
- アプリケーションはSprin Boot 3.0
- オブザーバビリティ
- FilebeatでアプリケーションのログをElasticsearchに転送し、Kibanaで可視化する（ロギング部分）
- Prometheusが定期的にアプリケーションのメトリクスを取得し、Grafanaで可視化する（メトリクス部分）
- Zipkinにアプリケーションからトレースデータを送信して、ZipkinとKibanaで可視化する（トレーシング部分）
アーカイブ動画を視聴した時のメモ
- ログの形式をElasticsearchの標準の形式（ECSと呼ばれる）で出力するプラグインがある。
- プロセス間でトレースデータを共有することをContext Propagationと言い、プロトコルはW3C（Spring Boot 3系のデフォルト）とB3 （Spring Boot 2系のデフォルト）の2種類がある。
- Spring Bootの2系と3系の両方を使っているときはデフォルトのプロトコルが違うため注意!
- トレーシングの実装はZipkin BraveとOpenTelemetry（OTel）があり、OpenTelemetryの方が勢いがありそう
- ↓ ChatGPTにも聞いてみた
OpenTelemetryはクロスプラットフォームなトレーシングの規格とライブラリであり、データ収集、エクスポート、統合に広範なサポートがあります。Zipkin BraveはJava向けのトレーシングシステムで、Javaコミュニティで人気があります。両者は分散トレーシングの目的を果たすツールですが、OpenTelemetryはより広範なプラットフォームと統合性を持っています。
感想
- 可視化のダッシュボードを作るためにはメトリクスが何を意味するか理解する必要があり、勉強の方向性が広がった。
- オブザーバビリティを実現するためのインフラの構築や運用、セキュリティを考えると、SaaSを使った方が結果的には安く済みそう。
その他
ミドルウェアはセットアップされている前提のようだったので、公式の資料やChatGPTに相談しつつローカルのコンテナ環境でミドルウェアが動くようにした。
