先日こちらのイベントに参加してきました

https://findy.connpass.com/event/312930/

会場提供はKINTOテクノロジーさん、とてもおしゃれな会場でした！

本イベントではオブザーバビリティに対する知見や経験についてのLTが盛りだくさんで、オブザーバビリティを向上させたい方向けのイベントとなっていました

弊社のテクニカルアンバサダーの松田さんも登壇されていました！

こちらのイベントはオフラインでのみ開催されるものでしたので、LTの内容を簡単にレポートしていきます

以降、よくKubernetesをk8sと略するのと同じ要領で、オブザーバビリティ（Observability）のことをo11yと略します

o11y入門 外形監視を利用したWebアプリケーションへの最適なモニタリング

アイレット株式会社 松田啓佑さん

  • o11yデビューにあたって取り組んだ2つのこと
    • 最適なモニタリングの設計/実装
    • 取得可能なメトリクスを取得/可視化
    • 本LTでは「最適なモニタリングの設計/実装」について主に話す
  • o11yに取り組むまで
    • 受託だとo11yに切り込みにくかった
      • お客様要件ドリブン、アプリとインフラで分断
    • 自社サービス開発に取り組むことになったのでo11yを実践した
  • まずはスモールスタート！
    • ①本質的な監視の実装
      • いままでの監視でのもやもやポイント
        • 無意味なリソース監視
          • CPU、メモリ、、、クラウドで本当に必要なのか？
        • 不十分な外形監視
          • トップページの外形監視だけでいいんだっけ？
    • ②システム状態の可視化
      • そもそもメトリクス集約できてなかった
      • 一元的に確認できない
  • システムの異常を検知できるにはどうすべきか？
    • バックエンド監視
      • システム異常を検知できるエンドポイントを設けておくことで監視できるのでは？と考えた
      • NewRelicで監視を実装
    • フロントエンド監視
      • Cognitoとの連携が難しい
      • 外部からユーザー操作をシミュレーションした監視を実装した
    • バックエンドとフロントエンド監視を組み合わせて本質的な監視を実装！
      • ログ監視で足りない部分を補う
  • システム状態の可視化
    • NewRelicのダッシュボード機能でダッシュボードを作った
  • 結果、異常の検知と原因の分析が可能になった！

発表資料

https://speakerdeck.com/k5k/o11yru-men-wai-xing-jian-shi-woli-yong-sitawebapurikesiyonhenozui-shi-namonitaringu-techbrew

オブザーバビリティ・エンジニアリング本を輪読して取り組んだo11yのはじめの一歩

株式会社メタップスホールディングス 是永総一郎さん

  • ログとの付き合い方が変わった
    • 「オブザーバビリティ・エンジニアリング」の輪読会を通じて、o11yと監視の意味の違いがなんとなくわかった
      • 結論、オブザーバビリティと監視は全く別物！
    • 輪読会の前のログ調査の仕方
      • インシデント発生　→　メトリクス確認　→　エラーログを見て調査
        • o11yのSaaS入れてても、やってることは今までのログ調査と変わらない
    • o11yとは
      • o11yはログ、モニタリング、トレースの3つで成り立つ
        • 「様々な切り口でのログ比較が簡単にできるようにする」が求められる
      • いわば、「ログ調査の民主化」の実現がo11y！
        • 詳しい人でなくても調査ができるようにするのが目的
    • 輪読会の後のログ調査
      • 日常的にログを確認　→　エラー発生の条件をあぶり出す　→　エラーの原因を調査
        • 「インシデント発生　→　メトリクス確認　→　エラーログを見て調査」の流れに加えて実施
        • 日常的にログの確認と調査を行う！
  • 輪読会で見えてきた課題
    • 共通的なログフォーマットの作成
      • プロダクトによって言語、フレームワークが異なる
      • 共通化したい
    • AWSリソースのタグ付け設計を厳格化
      • o11yの視点でのタグ設計を全くしていなかった
      • どういう切り口があると便利か、を元にタグ設計を検討
      • 抽象的な考え方はAWSのホワイトペーパーにも記載があった

発表資料

死角を作らないAPIサーバーのObservability構築

KINTOテクノロジーズ株式会社 楢崎弘二さん

  • ウーブンシティで使用している決済プラットフォーム
    • ビジネスロジックに関わっている方から見たo11yを考える
    • 運用チームがいないがミッションクリティカルな決済系システムを扱っている
  • o11の死角を作らないために
    • 言語やフレームワークが既に持っているo11y機能をまずは検討する
      • リッチなライブラリを技術選定の基準にする
    • ログ、メトリクス、トレースを組み合わせる
    • SNSでのエゴサもo111yの一つと考える
  • o11y stackをうまく使う
    • ツールが増えるとクエリ言語が増えたりする
    • 生成AIに聞くことで開発を進める
  • 可視化に留まらないようにする
    • 認知して担当者に行動させるまでがo11yのゴールだ！
      • ダッシュボード作って満足！ではだめ
    • 「誰が何をしないといけないのか」を通知する
      • 感覚が麻痺するので通知しすぎないように注意

AWS と GCP を跨いだトレースを実現するまでの軌跡

株式会社 AbemaTV 山本哲也さん

  • 分散トレーシングの導入に至った背景
    • マイクロサービスが増えて複雑になっている
      • GKEクラスターでマイクロサービスを実装
      • 某サッカーの試合中継の負荷試験でボトルネック対応ができてないことが判明し、1週間で検証・実装した
  • 導入して見えてきた課題
    • AWSとGCの違いによる学習コスト増加
    • サンプリングレートを緩和したい
    • クラウドを跨いだマイクロサービスの可視化をしたい
      • AWS、GCそれぞれo11yのカスタムヘッダーが異なる
  • Otelの導入
    • アプリケーションPodからOtelコレクターに飛ばす
    • Grafana Tempoで可視化
    • EKSの場合
      • App Mesh controllerの設定を変更して送信設計を実装
        • デフォルトではX-Rayが使われるが、設定を変更することでヘッダーが変わる
    • GKEの場合
      • istio-proxyのトレースをOtelcolに送る
    • アプリケーション内部でスパンを生成している場合
      • gRPCでOtelに接続するようにSDKで実装
  • 課題
    • AWS、GCがカスタマイズしてつけるヘッダーを活かせていない
    • サンプリングレートの緩和ができていない

KTCにおけるO11yの整備と遷移

KINTOテクノロジーズ株式会社 島村純平さん

  • プラットフォームを作る側の観点での話
  • よくあるツール利用の遷移
    • 一般的（と思われる）遷移
      • 一番最初は「SaaS使って楽したい」
      • プロダクトが大きくなるとOSSやマネージドサービスを使ってカスタマイズする話が出てくる
    • ただし、KTCでは最初からカスタマイズしていた
      • AWSマネージドサービスとfluentbitを使ってカスタマイズ
      • 現在はNewRelicを追加した
  • o11yツールの整理
    • カスタマイズしていると、できることは多いけど使うまでが大変
      • ツールの導入、設定が大変
      • テンプレ化してユーザーに渡しているけど大変
    • NewRelicを入れると簡単に
      • ほぼ全てNewRelic一つで完結する
    • カスタマイズしているとログ、トレース、モニタリングが紐付けにくい
      • NewRelicなら全て統合できる
    • サービス拡大に伴い、プロダクトに採用される技術スタックが増えた
      • カスタマイズしてると大変。。。
    • 運用要件からオーバーしたツールになってないか気をつけた
      • 松竹梅でランク付け
      • 最初はSaaSでお手軽に触るようにしないと定着しないとわかった
  • 最初の一歩は容易に導入してトライアンドエラー
    • プロダクトが増えたら札束で殴ることも、、、
    • 新規ツールはドッグフーティングしてくれる仲間が大事

プロダクト開発エンジニア全員で取り組むオブザーバビリティ

株式会社ユーザーベース 安藤 裕紀さん

  • NewsPicksの開発体制
    • 「全員プロダクト開発エンジニア」という文化
      • フルサイクルでの開発
      • エンジニアが開発から運用までオーナーシップを持つ
      • チームが分かれていても同じオンコールシフトに入る
        • 問題意識
    • 価値観は素晴らしいが、オーナーシップを醸成していくことは難しい
      • 理解をできないものにオーナーシップは持てない
    • 理解して説明できる力の尺度を上げたい
      • 「なんでもわかる」は無理でもわかるようになりたい
      • 理解して説明できる力があれば、新しいものも飲み込める
        • そのためにやったこと
    • APMの導入
      • ユーザー視点での監視の実装
        • Syntheticが一番ユーザーに近いが、全てのユーザーストーリーを監視するにはコストが高すぎる
        • APMが一番コスパがいい
        • インフラのメトリクスはユーザーから遠いので捨てる
          • 「俺はたった今からインフラのメトリクスを捨てる！！」
      • NewRelicで実装
        • コードを読む前にAPIの内部処理がざっくり理解できる
    • 周辺サービスとのサービスマップを整える
      • 周辺システムにもNewRelic APMを広げていく
      • サービスマップで依存関係を可視化する
        • コードを読まなくてもざっくりわかるようにする
    • SLOを整備してアラートとCUJ（クリティカルユーザージャーニー）を直結させる
      • CUJから重要度をつけてSLOを策定してモニタリング対象を決定する
        • 事業上の重要度と照らし合わせてランクづけ
      • CUJとエンドポイントを決めていく
        • 開発チームはエンドポイントとSLOを設定してPR出すだけでOKという形にした
          • CDK for Terraformで実装
    • o11yツールを全員が使えるようにする
      • 高いけどみんなで頑張ることで効果がある、、、！
      • AWSコスト削減と並行してライセンス拡充していった
        • 徐々にNewRelicの市民権を獲得していった
  • サービスやユーザーのことを理解したいためにo11yを実装した

発表資料

所感

発表されていた皆さんに共通していたなと思ったこととして、「技術のことだけではなくユーザーやサービスそのもののことを考えている」というのがあったと思いました

エンジニアをやっていると、つい技術だけに目が行きがちです
ただ、あくまで技術はツールの一つであって、一番大事なのは技術で作られるサービスやシステムが提供する価値であるということを、改めて認識させられる内容でした

その手段の一つとして、o11yの向上というのは効果があるということもよくわかりました

手段と目的を履き違えないように気をつけようと思わせる、とても勉強になる内容でした