オブザーバビリティプラットフォームを掲げるはてなMackerelもスポンサー＆ブース出展。 スポンサーチケット持ちだけど、ブース立ちはせずに終日聴講とさせていただいた。
聴講セッションでの印象フレーズ抽出と一言感想。資料は公開されたら登録していこう。
裏番組も面白そうなのがいくつもあったので、アーカイブが出たら見ていきたい。
- Affordable Observability: Strategy to Implementation（honeycomb.io Liz Fong-Jones）
- 可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ（LayerX Yuzuru Ohira aka Joe）
- 現場の壁を乗り越えて、「計装注入」が拓くオブザーバビリティ（Datadog Japan G.K., Kento Kimura aka AoTo）
- Lizさんサイン会
- プロファイルとAIエージェントによる効率的なデバッグ（アマゾンウェブサービスジャパン合同会社 Yoshi Yamaguchi aka ymotongpoo）
- 反省から紐解くオブザーバビリティとして本当に必要だったテレメトリ（アマゾンウェブサービスジャパン合同会社 Mitsuaki Tsugo）
- ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう（Sansan株式会社 Eiji Maeda aka 前田 英司）
- あなたのオブザーバビリティは2年後も通用するか？ ～Splunkのレポートが示すオブザーバビリティの今と未来～（Splunk Services Japan合同会社 山村 悟史）
- オブザーバビリティと共に育てたID管理・認証認可基盤の歩み（株式会社カミナシ 高井 真人）
- クロージングキーノート: これからのオブザーバビリティ（仮）（Cisco Systems 大谷 和紀）
- 懇親会
Affordable Observability: Strategy to Implementation（honeycomb.io Liz Fong-Jones）
- 集約はカーディナリティが失われてしまうリスクがあるので最後の手段
- 必要なすべての属性を持った1つのビー玉を生成する
- Observabilityはチームスポーツ
- 1つのサービスから小さく始める
- OTelジャーニー
- ログを属性に置き換える
- ロードマップをひく
トークが滅茶苦茶速くて、ヒアリングなんとかなるやろと思ったけどコテンパンに。おとなしく翻訳見るべきであった…。良い話が多かっただけにもう一度和訳で見たい。
自動計装（ゼロコード計装）からスモールスタートで進めるなど、ジャーニー的には「APMやってくぞ」の号令の下で自分がこうやっていくといいんじゃないかと思ってこれまでやってきたのと、そう齟齬がなくて安心した。自分たちに役立った改善したと感じてもらうのは、実際何か起きないとわかりにくいところではありますね。
可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ（LayerX Yuzuru Ohira aka Joe）
- 開発環境でできていれば、それをもとにしているはずの本番も同じフローで見られる
- ログを見るリッチなツールとしてDatadogを使ってしまう懸念を持ったので連携はせず
- こういう風になるのではと想像しトレースで挙動を見る。見えないところがあったら計装を追加する。スパンの結果からアーキテクチャがわかる。ログから属性を作る
- APMが導入されているのでここまで動作しているという切り分けができている
ログを見るリッチなツールとして使ってしまう懸念（ほかのシグナルならもっと妥当に進められるのに）というのはなるほどと思った。APMが導入されているので動作の切り分けができる、というのはインスパイアさせていただこう。
現場の壁を乗り越えて、「計装注入」が拓くオブザーバビリティ（Datadog Japan G.K., Kento Kimura aka AoTo）
- 言語すら考えずにコンテナ・プロセス間でシステム機能を利用する計装方式
- Otel OperatorとOTel Injectorから成る
- Linuxのld.soか環境変数でプリロードさせる
- プリロードで謎挙動になる可能性はあるし、攻撃手法として使われるリスクはある
プリロード懐しい、昔Linuxでよく使ってたのはなんでだったっけ。
プリロードが許される vs 自動計装が許される だと、Java/Python/.NETあたりは運用チームでも判断実施しやすいので、自動計装でいいじゃんにならないかな？と思ったけど、「何の言語のが動いているかも考えたくない」な状況だと、手段の1つとしてはアリだなとも。まさにタイトルどおり現場の壁を乗り越えるためのものか。
技術的には面白いので、一手として知れたのはとてもありがたかった。
Lizさんサイン会
CREという職種を作ってくれてありがとうを言えた。おかげで今エンジニアを名乗れています。
飲茶コーナーも行ってきた、美味しくて最高。
プロファイルとAIエージェントによる効率的なデバッグ（アマゾンウェブサービスジャパン合同会社 Yoshi Yamaguchi aka ymotongpoo）
- 理想：修正すべき箇所をコード行レベルで特定したい
- 継続的プロファイルを使う
- テレメトリはコンテキスト
プロファイルの解析をAIに食わせるのはたしかにもう当たり前化してそうだなと思った。ちょうどトレースデータから解析してコード修正するのは同僚のKGAさんがブログに書いていた。継続的に取得するのは理想だけど問題はコストか。
反省から紐解くオブザーバビリティとして本当に必要だったテレメトリ（アマゾンウェブサービスジャパン合同会社 Mitsuaki Tsugo）
- 4大シグナル + アプリケーションログ/インフラログ + クラウド標準メトリクス + 分散トレース をとるのがよい
- ビジネスメトリクス系、セキュリティコンプライアンス系、パフォーマンス系、運用効率化系 を取得する
普通的ではあるが実際にはその普通がなかなか難しいのが世の中。クラウド標準メトリクスなら無料ですと言えるのは提供側の強みだなぁ。
ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう（Sansan株式会社 Eiji Maeda aka 前田 英司）
- 計装にも必要ならロジックを書こう
- 非同期処理は「来る」と「送る」。ちゃんとつなげる必要
- コンテキスト伝播だけはとにかく早くやろう
計装に生データでなくロジックを書くのは注意深くあったほうがよさそうだけど、せざるを得ないケースはいかにもありそう（OTTLでやるのも大変）。
非同期処理はそのあとの可視化はどういう感じになるのが一般に期待されるんだろう？ 間がすごく空いているものでも1トレースでつながっているということが重要だろうか。
あなたのオブザーバビリティは2年後も通用するか？ ～Splunkのレポートが示すオブザーバビリティの今と未来～（Splunk Services Japan合同会社 山村 悟史）
- o11yに期待するものに、アプリケーションのセキュリティ脆弱性の検出、重要なビジネスプロセスの監視 が上位にある
- リーダーグループは「標準化」「文化的な壁を共通の事実で乗り越える」「AIを実践しインシデント対応を成熟させる」
グローバルだとセキュリティ脆弱性やビジネスプロセス監視あたりが上位に出てくるのが面白い。基調講演と同じくo11yは導入企業内で一丸チームになれるかどうかが鍵なんだろうなと思った。
オブザーバビリティと共に育てたID管理・認証認可基盤の歩み（株式会社カミナシ 高井 真人）
- 認証認可のトークン発行・検証だと暗号化・署名・ハッシュなどでCPUがボトルネックになりやすい
- ソフトウェアエンジニアはKalman filterである
- ログのSN比が悪くならないように適宜出力する内容の調整に努めている
- ユーザー起因失敗率を計測。よく失敗している人がわかる→カスタマーサクセスに連絡→カスタマーサクセスからプロアクティブに連絡
技術的に面白かった。認証認可でCPUがボトルネックになるの、確かになるほど。
ユーザー起因の失敗を検知してカスタマーサクセスから連絡する流れ良いですね。
ライブラリはもし相手がOSSで、カミナシさま固有でなければFBしてほしい気がした。
クロージングキーノート: これからのオブザーバビリティ（仮）（Cisco Systems 大谷 和紀）
- 現地参加444、オンライン視聴590 すごい -これからのo11yは皆の状況による。レガシーシステムと新しいものでは課題が違うし、コンテキストなくしてプラクティスをやるのは無駄
- ともに見る力・わかる力・伝える力を高め、次の一歩を見つけよう
良い〆めだった。
懇親会
- LTはMackerelとプレイド
- 古い友人にいろいろお会いできた
