概要
'Hatena Engineer Seminar #34 オブザーバビリティの実現と運用編'に参加しました。 本記事では、各セッションの内容と感想をまとめます。
参加理由
オブザーバビリティ（o11y）と OpenTelemetry（OTel）に関心があり、さまざまな側面で o11y を学びたいため、参加しました。
セッション感想
「オブザーバビリティプラットフォーム開発におけるオブザーバビリティとの向き合い」
Mackerel のテクニカルリードの arthur-1 さんの発表でした。
Mackerel の機能企画者としての視点とシステム開発・運用者としての視点から o11y の実践事例と学び方について発表されていました。 実践例は Mackerel の機能拡張や改善であり、チーム活動では Dogfooding、PWG、研究会と o11y に向き合った内容でした。 特に印象的だったのは、API コール時のレートリミット対策でラベル付きメトリクスを活用し、問題のある Organization と時間帯を特定できた事例です。 また、PWG（Performance Working Group）で定期的にシステムを観察する文化も印象的でした。 週 2 回の o11y 研究会で OpenTelemetry の動向をキャッチアップする取り組みは、チーム全体でオブザーバビリティに向き合う姿勢として参考になりました。
「EKS のメトリクスを Mackerel に簡単に送るための OpenTelemetry Collector の Helm Chart を作った」
Mackerel に EKS のメトリクスをおくるために、OpenTelemetry Collector を独自拡張した発表でした。
既存の Helm Chart が利用しづらいという課題を解決するために独自に作成し、Mackerel にメトリクスを送信できるようにしていました。 具体的には、既存の OpenTelemetry Collector Helm Chart では presets の追加・上書きが複雑であるため、カスタマイズが困難という問題がありました。 それを解決する「mackerel-opentelemetry-collector」を開発されていました。 設定の追加・上書きが簡単で、複数の exporter を定義可能という特徴があります。 OTel の標準仕様を保ちながら使いやすさを向上させた点が印象的でした。
「Perl アプリケーションでトレースを実装するまでの工夫と苦労話」
当時の Perl の OTel SDK が仕様が不足していたり、破壊的な変更が多かったことから、どうにかして自作するといった内容でした。 AWS X-Ray を利用して、Collector で変換することでトレースに成功していました。 実装方針の「あったら使え、組み合わせて使え、足りなければ作れ、できたら乗り換えろ」という考え方が印象的でした。 既存のツールを最大限活用しながら不足部分を補う実践的なアプローチでした。 型の不一致や Semantic 規約への準拠、モンキーパッチによる自動計装など、多くの技術的課題を乗り越えていました。 GigaViewer やカクヨムなどのプロダクション環境で実運用されている点に、エンジニアリングの底力を感じました。
勉強会の全体的な感想
o11y に専門性を持っている Hatena のエンジニアの方々の発表でした。 どの発表も非常にレベルが高く、実践的な内容でたいへん勉強になりました。
特に学んだ点は以下です。
- Dogfooding とチーム活動によるオブザーバビリティ文化の醸成
- 既存ツールの制約を理解したうえでの独自ツール開発の判断基準
- 「足りなければ作る」精神と、将来の標準化を見据えた実装
今後は、まず手元の環境で OpenTelemetry を使った簡単なトレースの実装から始め、段階的にメトリクスやログの統合を進めていきたいと思いました。 ISUCON の勉強と合わせて、パフォーマンス改善の観点からも o11y の実践を深めていく予定です。
