「オブザーバビリティ・エンジニアリング」を読んで学んだこと

https://www.oreilly.co.jp/books/9784814400126/

最近よく耳にする 「オブザーバビリティ」 という概念について、体系的に学んでみたいと思い『オブザーバビリティ・エンジニアリング』を手に取りました。
この記事では、本書を読んで得られた気づきや、実務に活かせそうだと感じたポイントをまとめます。

オブザーバビリティとは？

本書籍ではオブザーバビリティを外部からシステムの内部状態をどれだけうまく推測できるかの尺度として定義しています。

従来のモニタリングにおける問題点

従来のモニタリングは既知の障害を検出するのには非常に有効です。
またエンジニアは既知の障害を検出するためにしきい値を元にしてアラートを設定するのが一般的な対応方法でした。
しかし本書籍では、このやり方には問題があると指摘しています。
あらかじめ想定していない障害 に対しては、しきい値ベースの監視では気づくことが難しいということです。
また過剰にアラームを設定したとしても、アラート疲れを誘発し重大なアラートを見逃す可能性もあります。

オブザーバビリティが適用出来ているとはどういうことか

本書籍によるとオブザーバビリティツールと呼ばれるものを入れるだけでオブザーバビリティを実現出来る訳ではなく下記項目がアプリケーション上で実現出来ている必要があるとのことでした。

• アプリケーションの内部構造が理解できる
• 予測できないことが起こった際に、どのようなシステム状態に陥っているかを理解できる
• 外部ツールを使って観測し、調査をすることで、内部動作とシステム状態を理解できる
• コードを変更することなく、内部状態を理解できる

オブザーバビリティに必要な要素

• メトリクス

  • システムの状態を数値として定期的に収集したもの。CPU 使用率やメモリ使用量、リクエスト数、レスポンスタイムなどが代表例です。数値の推移を時系列で見られるので、全体の傾向や異常値を把握するのに適しています。

• ログ

  • 特定のイベントに関連するインフラ、アプリケーション、ネットワーク、OS、およびシステムからのデータ

• トレース

  • ひとつのリクエストがシステム内をどう流れていったかを追跡する仕組み。
    リクエストごとに一意のトレースIDが付与され、それを辿ることで「どのサービスでどれくらい時間がかかったのか」を可視化できます。分散システムにおける遅延やボトルネックの特定に役立ちます。

これから実践していきたいこと

本書籍を読んだ感想としては、普段の案件ではプログラマーとして参画することが多く、インフラレイヤーを触る機会がほとんど無いため、オブザーバビリティツールの導入やOSのメトリクス等を設定するのは難しいかなと感じました。
しかしアプリケーションのログをどういう情報をどのタイミングで出力するかはプログラマーとして参画していても充分に関われる所だと思うので、オブザーバビリティの実現に向けてのファーストステップとして意識していこうと思います。