多数の観測対象と複数のO11yバックエンドをOTELで横断的に繋いだ実装について

Transcript

1. 多数の観測対象と複数のO11yバックエンドを OTELで横断的に繋いだ実装について 2026/05/21 OpenTelemetryMeetup 2026-05 Kinto Technologies Corporation Platform Group / Platform Engineering Team Senior Cloud Engineer / Assistant Manager Jumpei Shimamura
2. ©KINTO Corporation. All rights reserved. 2 プロフィール KINTOテクノロジーズ株式会社 プラットフォーム開発部 / Platform Group Platform Engineering Team Senior Cloud Engineer / Assistant Manager 島村 純平(しまむら じゅんぺい） ＜経歴＞ 2009〜2021 新卒で航空系システム子会社へ入社 インフラエンジニアとして勤務 2021〜 KINTOにDevOps担当として入社 文化浸透の活動や標準化活動などを実施 現在はPlatform Engineering Teamのリーダーとして 生産性向上のためのツール開発・社内展開を実施
3. ©KINTO Corporation. All rights reserved. 3 Index 1 KINTOテクノロジーズのo11y概要 2 複数基盤向けのメトリクス転送要件 3 目次 3 パイプライン実装概要 4 課題とまとめ
4. ©KINTO Corporation. All rights reserved. 4 KINTOテクノロジーズのo11y概要 1
5. ©KINTO Corporation. All rights reserved. 5 過去の構成 X-Ray Amazon OpenSearch Amazon Grafana Amazon Prometheus 計装・収集 データ 保存 可視化 Metrics Log Trace AWS Distro OpenTelemetry X-Ray Amazon OpenSearch NewRelicAgent Metrics Log Trace AWSのマネージドサービスメイン NewRelicとは完全に使い分け
6. ©KINTO Corporation. All rights reserved. 6 2025年10月に新基盤に移行しました(しはじめました) 計装・収集 データ 保存 可視化 Metrics Log Trace AWS Distro OpenTelemetry NewRelicAgent Metrics Log Trace Grafana Loki Grafana Tempo Grafana Alloy 自作Logger GrafanaLabsのOSSスタックへ移行 https://blog.kinto-technologies.com/posts/2025-12-14-monitoringplatform-renewal/
7. ©KINTO Corporation. All rights reserved. 7 複数基盤向けのメトリクス転送要件 2
8. ©KINTO Corporation. All rights reserved. 8 内部的なo11yの使い分け ・しっかりと運用したいプロダクト ・関連するサービスが多いプロダクト ・社内プロダクト ・ある程度の運用で良いプロダクト ・申し込み系 ・車両管理系 ・PlatformGのシステム ・コンテンツ ・Claudeの利用状況 Application / AWS (ALB/CDN/WAF/Lambda/RDS) / ClaudeCowork Application / ClaudeCode Logs Metrics Upload
9. ©KINTO Corporation. All rights reserved. 9 メトリクス・ログの流れ Application AWS(ALB/CDN) AWS(WAF/Lambda/RDS) Claude(cowork/code) S3 Firehose Alloy 自作Logger o11y Account A Account B Tenant C Tenant D Application Ops CloudInfra Claude利用者 セキュリティ
10. ©KINTO Corporation. All rights reserved. 10 メトリクス・ログの流れ Application AWS(ALB/CDN) AWS(WAF/Lambda/RDS) Claude(cowork/code) S3 Firehose Alloy 自作Logger o11y Account A Account B Tenant C Tenant D Application Ops CloudInfra Claude利用者 セキュリティ
11. ©KINTO Corporation. All rights reserved. 11 パイプライン・実装概要 3
12. ©KINTO Corporation. All rights reserved. 12 要件と考え方 送信先のバックエンドが複数ある アプリログ・メトリクス・AWSログと複数のインプットがある コストやプロダクト要件により転送先を柔軟にしたい
13. ©KINTO Corporation. All rights reserved. 13 パイプライン、otelの実装(自作Logger) ・Golang製、既存ではLogstashで実施していた機能を置換 ・LogstashにOtelPluginはあるが古いのもあり内製 ・送付先がNewRelic/Lokiと複数 ・otel/sdk/logとotel/logを使用 Worker Worker Worker queue processor sender ・SQSポーリング storage ・S3ファイル取得 ・ログFormat ・OTELLOG変換 ・OTEL/HTTPで送信 NewRelicの中のアカウント送信振分は、LoggerのPod自体を分離してEventBridge/SNS/SQS側で整理 （AWS系のログのため、Loki/NewRelic両方へ送付）
14. ©KINTO Corporation. All rights reserved. 14 パイプライン、otelの実装(自作Logger) // log.Exporter を埋め込み、Export() をオーバーライド func (e *ExporterWithErrors) Export(ctx, logs) error { err := e.Exporter.Export(ctx, logs) // 元の処理 if err != nil { // atomic.Pointer でスレッドセーフにエラーを蓄積 e.errors.Store(...) } return err } 独自のSDKラッパーを作成 Exporter With Errors Logger Wrapper type LoggerWrapper struct { otelLogger otelLog.Logger } func (lw *LoggerWrapper) Emit(ctx, record) { lw.otelLogger.Emit(ctx, record) } Provider Wrapper type ProviderWrapper struct { otelProvider *log.LoggerProvider } // Shutdown / ForceFlush を nil ガード付きで委譲 テスト時にモックを作りやすくするために、使う機能（Emit）だけに絞ったインターフェースを定義
15. ©KINTO Corporation. All rights reserved. 15 パイプライン、otelの実装(Alloy) AWS(WAF/Lambda/RDS) Claude(cowork/code) Alloy AWS(WAF/Lambda/RDS) Firehose Alloy Firehose Alloy loki. source. awsfirehose otelcol. receiver. loki loki. process (tenant) otelcol. exporter. otelhttp loki. source. awsfirehose otelcol. receiver. loki otelcol. processor. batch otelcol. exporter. otelhttp otelcol. receiver. otlp otelcol. processor. batch otelcol. auth. header otelcol. exporter. otlphttp otelcol. exporter. splunkhec loki. process (timestamp) loki. write. dynamic_tenant otelcol. processor. batch
16. ©KINTO Corporation. All rights reserved. 16 パイプライン、otelの実装(Application系設定) Application AWS for Fluent Bit - PlatformGでConfigを含めてビルドして提供 - Sidecarとして起動 - NewRelicとLokiのどっちに送るかは使用イメージと設定により変えている - 2025/10にFluentbit v4.1.1ベースになるまで、[OUTPUT]でopentelemetryが使えず AWS Distro for OpenTelemetry (adot) - PlatformGで特定バージョンをECRへ保管してサポート - Sidecarとして起動 - ParameterStoreにConfigを記載して設定
17. ©KINTO Corporation. All rights reserved. 17 パイプライン、otelの実装(ログ統一の検討) Sidecarの統一を検討しましたが、firelensの仕様やS3にも永続保存のため書き出す要件 アプリケーション側の移行を考慮して、このタイミングでは実施しませんでした。 - firelensの送信先としてotelの設定が難しい - fluentbitだとForwardのINPUTを使って標準出力を受けている - otelだと該当するReceiverがなさそう - S3のExporterがadotに存在しない(otel pluginは存在するので、自力でビルドすれば可能) - OpenTelemetryのINPUTだと定期的なスクレイピングができない（受信） - Prometheusのスクレイピングはあるのでアプリケーションメトリクスはできそう - OpenTelemetryとNewRelicのOUTPUTはある - ECSのコンテナ周りのメトリクス収集が課題
18. ©KINTO Corporation. All rights reserved. 18 課題 4
19. ©KINTO Corporation. All rights reserved. 19 課題 ログのキューイングの仕組みがない NewRelicやLokiで429 TooManyが発生したり 失敗した際に、アプリケーションログの部分でOoMの懸念がある (AWS系はLoggerやFirehose、Alloyでキューイングされている) 自作LoggerからNewRelic向けの失敗が多い レスポンスで500エラーが発生しているが、原因がわかっていない
20. Thank you !