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

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

Transcript

1. ©MIXI 1 EKSで実践する オブザーバビリティの現在地 [ログラス×みてね] Platform Engineeringを⽀えるKubernetes活⽤実例 @HonMarkHunt #Kubernetes活⽤実例
2. 2 ©MIXI 本間 匡晃(ホンマークハント) 株式会社MIXI みてねプラットフォーム部 SREグループ マネージャー ・5歳と2歳の娘がいます ・スニーカー収集・筋トレ・キャンプ ・一昨日ハムスターを飼い始めました @HonMarkHunt @honmarkhunt
3. ©MIXI 3 サービス紹介
4. 4 ©MIXI 家族アルバム みてねはスマホで撮った⼦どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。
5. 5 ©MIXI 2015年4⽉リリース • 7⾔語‧175の国と地域でサービスを提供 • 2025年7⽉に利⽤者数が2,700万⼈を突破
6. 6 ©MIXI 世界中の家族のこころのインフラをつくる みてね事業のMVV | Mission
7. 7 ©MIXI 今⽇のテーマ(1/3) 「家族アルバム みてね」のSREチームが Amazon Elastic Kubernetes Service (EKS)で Observabilityをどのように構成しているかの現状と課題 Observabilityと⼀⾔で⾔ってもかなり広義の⾔葉になってきている (Latency, Traffic, Errors, Saturation, Event Log等) 今回は Metrics, Logs, Traces のThree Pillarsの3要素にフォーカス
8. 8 ©MIXI 今⽇のテーマ(2/3) 「SREをはじめよう」*1 でも紹介されているDickersonの信頼性の階層構造でも 監視/Observabilityは信頼性の土台となる要素として位置付けられている SRE観点で「システムの状態が全くわからない」ケースはそこまで多くないかもしれない *1 SREをはじめよう(https://www.oreilly.co.jp/books/9784814400904/) SRE Kaigi 2026 弊社ブースでのアンケート結果 https://x.com/mixi_engineers/status/2017552037568037107
9. 9 ©MIXI 今⽇のテーマ(3/3) しかし、SREと開発者では関心ごとが異なる • システムは健全に動いている？ • SLOは違反していないか？ • 可用性は担保されているか？ • 今リリースした変更は正しく動いているか？ • このエラーは自分のコードか？ • お問い合わせの原因は？ 「SREが必要な情報にアクセスしシステムの健全性を担保すること」と 「Platformerとして開発者が必要な情報に容易にアクセスできる環境を作ること」は違いがある SREの関心 開発者の関心 今回は Metrics, Logs, Traces の3要素の基本的な構成を紹介しつつも、 Platform Engineerとしての観点で Observabilityをどのように捉え、どのように実装しているか、ま た、どんな課題があるかについてお話しします
10. 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の両⽅の責任を持つ
11. 11 ©MIXI システムとチーム構成 「家族アルバム みてね」における運⽤管理‧ オブザーバビリティの全貌 https://speakerdeck.com/isaoshimizu/overview-of-operation-management-and-observability-in-familyalbum?slide=31
12. ©MIXI 12 Metrics
13. 13 ©MIXI Metrics(1/3) • Prometheusを使⽤ ◦ クラスター内の Prometheus で収集 ◦ Amazon Managed Service for Prometheus に永続化 • Grafanaで可視化
14. 14 ©MIXI Metrics(2/3) • Prometheusを使⽤ ◦ クラスター内の Prometheus で収集 ◦ Amazon Managed Service for Prometheus に永続化 • Grafanaで可視化 SRE観点では 大きな課題は 顕在化していない
15. 15 ©MIXI Metrics(3/3) メトリクスにアクセスするための権限は開発者に付与してあり⾃由にアクセスできる状態だが、 開発者が求めているメトリクスを閲覧/提供できているのだろうか？ 直近も「デプロイが完了したのか = podが全て⼊れ替わったかわからない。」という会話があり、 SREがダッシュボードを作成し共有した  アドホックなサポートではなく開発者が必要な情報を⾃⾝で閲覧/分析できるように • PromQL, LogQL, NRQLなど独⾃クエリのハードル • そもそも収集したメトリクス全体の認知負荷が⾼いと⾃由な分析はできない？ • 権限を与えることと、使いこなせることは違う • Enablementの仕組みづくりの必要性があるかもしれない
16. ©MIXI 16 Traces
17. 17 ©MIXI Traces(1/1) • 主にNew Relicを利⽤ ◦ APM ◦ Error • データ量の観点からサンプリングしてNew Relic Agentを起動 • OpenTelemetryについてはNew Relicで⼀貫した体験が提供できているので 載せ替えや並⾛は現時点では検討していない • 開発者全員にアカウント発⾏はできていない ◦ (⾦額⾯の課題)
18. ©MIXI 18 Logs
19. 19 ©MIXI Logs(1/3) • ログの⽤途によって閲覧⽅法が分かれる • Amazon Athena ◦ 集計‧分析⽤途 ◦ Fluent Bitから Amazon Kinesisを経由し S3に保存 ◦ DailyでParquetへ変換 • Grafana Loki ◦ 障害調査‧デバッグ⽤途 ◦ Rails等の アプリケーションログ • 開発者要望から アーキテクチャ⾒直し中(後述)
20. 20 ©MIXI Logs(2/3) • Athenaでの分析への課題感からBigQueryへ ◦ DBデータとの突合 ◦ クエリの速度改善 • 分析基盤としてのBigQuery活⽤
21. 21 ©MIXI Logs(3/3) • 分析基盤としてのBigQuery、リアルタイム調査⽤のLoki • サービス‧組織の拡⼤に伴い機能要望や提供すべきPlatformは変遷する • Lokiでのよりカバー率の⾼いリアルタイムログ ◦ 現在対応中 ◦ Grafana AlloyとFluent Bitの混在 ◦ Amazon Kinesis Data Firehoseのコスト最適化 • いかに開発者の実際の利⽤フローから要望を拾い上げるか？
22. ©MIXI 22 まとめ
23. 23 ©MIXI まとめ • Observabilityと⼀⾔で表現しても個別⽤途で成熟度を判断するのは難しい • 同じもの‧ツールを⾒ていてもSREと開発者では要望が異なる ◦ SREの要望は⾃⾝が利⽤者なので反映しやすい ◦ 開発者向けの利⽤⽤途を如何にして拾い上げるかに課題がある ▪ 定量評価ができないとアドホックな対応になってしまう ▪ 開発者の障害調査/リリースフローなどに乗っ取ったCUJの定義など？ • サービス‧組織拡⼤に伴いPlatformも変遷する ◦ 変更前提のアーキテクチャ ◦ チーム内での開発優先度の問題