オブザーバビリティ・エンジニアリング
https://gyazo.com/c4d038453d83c57bd32c8b0ad53e6e8b
興味関心を全振りしているわけではないが業務上わりと重要性の高い知識だと認識していた
関連した勉強会に参加した際に知識不足も感じた
FindyのOtel勉強会参加し抽選であたった
@tkdn: #OTel_findy 参加後アンケートで抽選プレゼントとなっていた書籍、「オブザーバビリティ・エンジニアリング」を Findy さんからいただきました🙌 勉強会に参加した際に読まないとなーという感想をもっていたので大変嬉しいです。 運営の皆さまありがとうございます。
https://pbs.twimg.com/media/GLqPPwuasAAV7Ce.jpg
分散システムが増え複雑性を扱うようになった結果、従来のトラブルシューティングは機能しなくなった
従来というのはモノリシックなアプリケーションにおいてのボトルネックや障害の原因を特定するような場面でのデバッグや原因にあたりをつけるような行動
構造化イベント
仮説の反復的検証
コア分析ループ
モニタリングとオブザーバビリティの違い、オブザーバビリティ導入 モニタリングは既知の未知を扱いますが、オブザーバビリティは未知の未知を扱うのです。 高いカーディナリティと高いディメンション
リクエストないし処理に対して、いかにTraceに一意性があるか、いかに多くのキーバリューの情報を持てるか
tkdn.icon 普段DatadogダッシュボードでFargate Taskのタスク数・CPU使用率やALBの5xxカウント、その他DBの書き込みレイテンシーや多くのメトリクスがプロットされたグラフを見ているが、これはモニタリングだよなぁという感想を抱いた そのグラフを見て洞察を得るのが難しい
バックグラウンドにはサービス間の関連性などを見つけるなどの知識が必要となる
従来のモニタリングにおける対応はプロダクトに精通した(歴の長い)シニアメンバーが多かったが、オブザーバビリティを重要視することで感度が高く粘り強いメンバーの対応が増える(歴を問わない)
チーム内の最高のデバッガーは、通常、もっとも好奇心の強いエンジニアです。オブザーバビリティを実践しているエンジニアは、探索的な質問によってシステムを調査し、発見された答えを使って、さらにオープンエンドな調査ができます。オブザーバビリティとは、ある特定のシステムに関する深い知識を評価して調査上の直感を与えるのではなく、異なるシステム間で運用する熟練した調査能力を評価することです
モニタリングのデバッグ方法としてツールホッピングが挙げられている
tkdn.icon 実際にはDatadogでTraceIDを拾って AWS CloudWatchLogs にクエリ投げたりすることも多かったりするので、あまり現代的ではないのだよなと思うなどした
逆になぜログに頼らなければならないか? でいうとリクエストパラメータやユーザ情報だったりするので PII に抵触しない範囲でスパンにタグをつければよさそう
現代的なシステムにおけるオブザーバビリティの観点：
ステージングでのデバッグや検査は効果はなく本番環境で行うモデルへ移行している
ステージング環境の有用性や信頼性は以前よりさらに低下（モノリシックなアプリケーションでも再現は難しい）
コードフリーズし本番環境へ投入する前に安全性確保する従来の取り組みは制限的、いくぶん無駄であると認められはじめている
アラートはユーザ体験に直接影響を与える症状にのみ焦点をあて、アラート発生を抑えるモデルへ移行
オブザーバビリティ基礎
オブザーバビリティにおけるイベントベースに対比する形でメトリクスを解説
メトリクスによって提供される集合値イベントベースを代替できない
第一原理からのデバッグ
何が証明され、何が真実であると確認しているかを問うことから始めなくてはなりません。そして、その原理に基づいて仮説を立て、システムの観察に基づいてそれを検証したり、無効としたりしなければならないのです。
オブザーバビリティの威力はデバッグの際に事前に多くのことを知る必要がないこと
tkdn.icon AIOps のくだりでは機械的には検出できない認知的な文脈をもった分析は人間の仕事といった口振りなのでやはり選び取るのは人間の仕事…
コア分析ループを使い様々なディメンション・フィルタリングなどを使い総当たり分析を行う（のは現実的ではないのでツールに委ねたりする）
tkdn.icon Datadog でもAnomaly 検出や Watchdog なんかが該当しそう
オブザーバビリティとモニタリングの棲み分けについては、表9-1で解説される整理がわかりやすい
システム(サービスを実行する基盤となるインフラやランタイムに関する全般)を理解にするにはモニタリング
ソフトウェア(顧客二価値を提供する、積極的に開発しているコード)を理解するにはオブザーバビリティ
チームのためのオブザーバビリティ
オブザーバビリティをもちいたデバッグ
ソフトウェアの可制御性(Controllability)もオブザーバビリティに近しいものがある
初手ベンダーのSDKを使って自動計装することは多いが、繰り返し計装を充実させる・新しいコードには必ずスパンの特定に役立つ計装が含まれている、という状況が一番健全そう
tkdn.icon 今のPJでは OTel による計装をしていて、新しいメソッドや処理の追加には必ず Span が特定されるように計装している
さらにオブザーバビリティは、デバッグが必要なコードがシステムのどこに存在するかを見つけた出すためのもの
どのコンポーネントか？例外か？コンポーネントの処理時間は？データを壊しているか？
レイテンシースパイクを発見後の調査・デバッグの例:
e.g. 平均/P90/P99のレイテンシーから…
遅いリクエストパターンを洗い出しそのうち1つをトレースする。トレースしたリクエストのコンテキスト(関数、変数、DBクエリ...)をローカルで実行し、デバッガー・プロファイラーで再現させる
書き込みエンドポイント(特定のパスなど)で遅くなることを発見する。DBの接続先ホストでグルーピングすると、遅いクエリーはいくつかのプライマリ・データベースに分散しているように見えた。このデータベースは特定のインスタンスと特定のAZで発生していることがわかり、問題はソフトウェアではなく、クラウドのインフラストラクチャに問題があることがわかる
tkdn.icon 重要であることは理解しつつも、バーンアラートの算出や予測ウィンドウや基準ウィンドウあたりの概念は個人的に関心が薄くひかれる内容ではなかった
大規模なオブザーバビリティ
オブザーバビリティ実現のための買うか作るかといった観点からはじまり、テレメトリーデータ・イベントを扱うにはどういったデータストアがいいのか、Honeycomb Retriever における採用例を踏まえた内容がつづく
高頻度でな書き込みやバリエーションの多いトレースのクエリなどを踏まえてどういったワークロードとなるかを中心にしていて、オブザーバビリティツールにおける設計に踏み込んでいる
サンプリング手法についても記載がありイメージしやすさのため Go コードによる解説がある
tkdn.icon あまり意識していなかったが普段使っている Datadog トレースってサンプリングによりいくつかドロップしているんだっけ？ というのも少し気になった
Slack 社における自作とベンダーで組み合わせたテレメトリーデータのパイプラインなどはシステム構成の参考によさそう
https://opentelemetry.io/docs/collector/img/otel-collector.svg
上記にないものだと、recieverとprocessor, processorとexporterの間にバッファコンポーネントが置かれている
バックエンドや下流に流す前に短時間だけデータを格納する場所
オブザーバビリティの文化醸成
非エンジニアリング向けへの旨味もあるといった点はありそう
実際にユーザが使ったトレースからわかることは多くあるし新機能提供後の利用傾向もわかることから、うまみはあるよねはよくわかる。いわんやRUMをや
BIツールとはまったく違うものではあるけど、前述されているSlackエクスポーターにはリアルタイムダッシュボード向けのElasticsearch用エクスポーターがあることを考えると、時間が市場やビジネスの変動に影響を受けるようなシステムはメリットが高いように思った
オブザーバビリティ成熟モデル(OMM)
エンジニアリング組織における目標となるよう開発したそう
障害に対するレジリエンス、高品質のコード、複雑性と技術的負債の管理、リリースケイデンス、ユーザ行動の把握、あたりがOMMの根幹
AWSでは触れていないエンジニアのQoLに触れていてよかった
持続可能なシステムとエンジニアのQoL
複雑性のある(もしくは歴史的経緯により運用のつらい)ソフトウェアをあつかううえで、ほとんどの時間を顧客価値とは無関係な時間で使ってしまい、燃え尽き・無気力・モラル低下を起こしやすい