Upgrade to Pro — share decks privately, control downloads, hide ads and more …

EKSで実践する オブザーバビリティの現在地

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for HonMarkHunt HonMarkHunt
February 19, 2026

EKSで実践する オブザーバビリティの現在地

2026/02/19(木) に開催された [ログラス×みてね] Platform Engineeringを支えるKubernetes活用実例 (
https://mixi.connpass.com/event/382719/ ) の登壇資料です

Avatar for HonMarkHunt

HonMarkHunt

February 19, 2026
Tweet

More Decks by HonMarkHunt

Other Decks in Technology

Transcript

  1. 7 ©MIXI 今⽇のテーマ(1/3) 「家族アルバム みてね」のSREチームが Amazon Elastic Kubernetes Service (EKS)で

    Observabilityをどのように構成しているかの現状と課題 Observabilityと⼀⾔で⾔ってもかなり広義の⾔葉になってきている (Latency, Traffic, Errors, Saturation, Event Log等) 今回は Metrics, Logs, Traces のThree Pillarsの3要素にフォーカス
  2. 9 ©MIXI 今⽇のテーマ(3/3) しかし、SREと開発者では関心ごとが異なる • システムは健全に動いている? • SLOは違反していないか? • 可用性は担保されているか?

    • 今リリースした変更は正しく動いているか? • このエラーは自分のコードか? • お問い合わせの原因は? 「SREが必要な情報にアクセスしシステムの健全性を担保すること」と 「Platformerとして開発者が必要な情報に容易にアクセスできる環境を作ること」は違いがある SREの関心 開発者の関心 今回は Metrics, Logs, Traces の3要素の基本的な構成を紹介しつつも、 Platform Engineerとしての観点で Observabilityをどのように捉え、どのように実装しているか、ま た、どんな課題があるかについてお話しします
  3. 10 ©MIXI システムとチーム構成 システム構成 • 家族アルバム みてねでは2021年からEKSをアプリケーション基盤に採⽤ *1 • 海外ユーザーの体験向上などの⽬的で2022年にEKSクラスタをマルチリージョン化

    *2 ◦ 東京リージョン(ap-northeast-1) ◦ バージニア北部リージョン(us-east-1) *1 4年間のEKS移⾏の取り組みを振り返って ( https://gihyo.jp/article/2022/11/mitene-02eks ) *2 家族アルバム みてね のインフラをマルチリージョン化しました ( https://team-blog.mitene.us/mitene-infra-multi-region-614717f0162d ) チーム構成 • みてね全体で100名以上、エンジニアで50名以上の組織 • SREチームは6名 • SREとPlatform Engineeringの両⽅の責任を持つ
  4. 13 ©MIXI Metrics(1/3) • Prometheusを使⽤ ◦ クラスター内の Prometheus で収集 ◦

    Amazon Managed Service for Prometheus に永続化 • Grafanaで可視化
  5. 14 ©MIXI Metrics(2/3) • Prometheusを使⽤ ◦ クラスター内の Prometheus で収集 ◦

    Amazon Managed Service for Prometheus に永続化 • Grafanaで可視化 SRE観点では 大きな課題は 顕在化していない
  6. 17 ©MIXI Traces(1/1) • 主にNew Relicを利⽤ ◦ APM ◦ Error

    • データ量の観点からサンプリングしてNew Relic Agentを起動 • OpenTelemetryについてはNew Relicで⼀貫した体験が提供できているので 載せ替えや並⾛は現時点では検討していない • 開発者全員にアカウント発⾏はできていない ◦ (⾦額⾯の課題)
  7. 19 ©MIXI Logs(1/3) • ログの⽤途によって閲覧⽅法が分かれる • Amazon Athena ◦ 集計‧分析⽤途

    ◦ Fluent Bitから Amazon Kinesisを経由し S3に保存 ◦ DailyでParquetへ変換 • Grafana Loki ◦ 障害調査‧デバッグ⽤途 ◦ Rails等の アプリケーションログ • 開発者要望から アーキテクチャ⾒直し中(後述)
  8. 21 ©MIXI Logs(3/3) • 分析基盤としてのBigQuery、リアルタイム調査⽤のLoki • サービス‧組織の拡⼤に伴い機能要望や提供すべきPlatformは変遷する • Lokiでのよりカバー率の⾼いリアルタイムログ ◦

    現在対応中 ◦ Grafana AlloyとFluent Bitの混在 ◦ Amazon Kinesis Data Firehoseのコスト最適化 • いかに開発者の実際の利⽤フローから要望を拾い上げるか?
  9. 23 ©MIXI まとめ • Observabilityと⼀⾔で表現しても個別⽤途で成熟度を判断するのは難しい • 同じもの‧ツールを⾒ていてもSREと開発者では要望が異なる ◦ SREの要望は⾃⾝が利⽤者なので反映しやすい ◦

    開発者向けの利⽤⽤途を如何にして拾い上げるかに課題がある ▪ 定量評価ができないとアドホックな対応になってしまう ▪ 開発者の障害調査/リリースフローなどに乗っ取ったCUJの定義など? • サービス‧組織拡⼤に伴いPlatformも変遷する ◦ 変更前提のアーキテクチャ ◦ チーム内での開発優先度の問題