先日こちらのむベントに参加しおきたした

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を実装した

発衚資料

https://www.docswell.com/s/integrated1453/5DER7R-o11y#p1

所感

発衚されおいた皆さんに共通しおいたなず思ったこずずしお、「技術のこずだけではなくナヌザヌやサヌビスそのもののこずを考えおいる」ずいうのがあったず思いたした

゚ンゞニアをやっおいるず、぀い技術だけに目が行きがちです
ただ、あくたで技術はツヌルの䞀぀であっお、䞀番倧事なのは技術で䜜られるサヌビスやシステムが提䟛する䟡倀であるずいうこずを、改めお認識させられる内容でした

その手段の䞀぀ずしお、o11yの向䞊ずいうのは効果があるずいうこずもよくわかりたした

手段ず目的を履き違えないように気を぀けようず思わせる、ずおも勉匷になる内容でした