©MIXI 1 『家族アルバム みてね』における Amazon EKSコストとの向き合い⽅ 2025/12/16 マネージドKubernetes運⽤戦記 − AKS‧GKE‧EKS、それぞれのリアルと最適解 @kohbis 

2 ©MIXI About Me Kohei SUGIMOTO 株式会社MIXI • 2022/04 ~ 『家族アルバム みてね』SRE X / @kohbis 

3 ©MIXI 本スライドのターゲット EKSを業務で運⽤‧管理している⽅ EKSの導⼊を検討している⽅ EKSは運⽤していない、導⼊予定もないが関⼼がある⽅ 三度の飯よりAWSコスト最適化のはなしが好きな⽅ 

©MIXI 4 『家族アルバム みてね』について 

5 ©MIXI 『家族アルバム みてね』について（1/2） 家族アルバム みてねはスマホで撮った⼦どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。 

6 ©MIXI 『家族アルバム みてね』について（2/2） 2015年4⽉にリリースして、ことし10周年 ● 7⾔語‧175の国と地域でサービスを提供 ● 2025年7⽉に利⽤者数が2,700万⼈を突破 

©MIXI 7 EKSの構成 

8 ©MIXI EKSの構成（1/2）〜概要〜 EKS on EC2（not Fargate） • 2021年にAWS OpsWorksから完全移⾏ 海外ユーザー体験向上のためMulti-Region • 東京 / バージニア北部 役割に応じてEKSクラスターを分離 • アプリケーションが動くクラスター   リージョンごとに配置 • 運⽤関連のコンポーネントが動く   Argo CD, Grafanaなど 

9 ©MIXI EKSの構成（2/2）〜ワークロード〜 スケールはおおよそ50〜300 Nodes, 500~6000 Pods（weekly） EC2ノードの80〜90%でSpotインスタンスを活⽤ ※1 EKS上のアプリケーションはさまざま • API • 動画ストリーミング • コンテンツ⽣成 • 解析処理 など 基本的には時期や時間帯で予測しやすいワークロード ※1 本スライドではSpotインスタンスを特別取り扱わない 

©MIXI 10 EKSにおけるコスト 

11 ©MIXI EKSにおけるコスト（1/2）〜前提の整理〜 コントロールプレーン費⽤（固定） • EKSクラスターごとに時間単位のコスト（数⼗ドル/month程度） ワーカーノード（EC2 or Fargate）費⽤（可変） • EKSクラスターで最も⼤きな割合を占める ストレージ（EBS）費⽤（可変） • ボリュームサイズやI/O によって変動 ネットワーク / データ転送費⽤（可変） • AZ間（やリージョン間）や外部通信で発⽣ 

12 ©MIXI EKSにおけるコスト（2/2）〜考え⽅〜 EKSは、AWSでおなじみのサービスを統合したフルマネージドKubernetes EKSコスト最適化においても（基本的に）AWSコスト最適化の 広く知られたプラクティスの適⽤が可能 （例）AWS Cloud Financial Management (CFM) フレームワーク 引⽤元：https://aws.amazon.com/jp/blogs/news/aws-cost-optimization-guidebook/ 

©MIXI 13 EKSコストの可視化 

14 ©MIXI EKSコストの可視化（1/5） AWSでよく使われるコスト可視化（最適化）ツール • AWS Cost Explorer • AWS Cost Optimization Hub など AWSサービスごとのコストや（EC2など）タグベースでコストを可視化が可能 ⼀⽅で、EKSクラスタ内のリソース（PodやNamespace単位）ごとには 把握できない場合がある EKS（Kubernetes）のように 複数ワークロードが同⼀インスタンス上で動くケースでは より詳細にアプローチする対象を絞り込みたい 

15 ©MIXI EKSコストの可視化（2/5）〜EKSのコスト配分〜 Split cost allocation data for Amazon EKS ※1 • AWS Cost and Usage Report（CUR）※2 にPod/Namespace単位の コストを含める仕組み • デフォルトではPod/Namespace/Deployment名などが含まれる • PodごとのCPU/メモリ使⽤量に応じてEC2コストを按分 • NamespaceやDeploymentなどKubernetesプリミティブに集計可能 • AWSではAthenaやQuickSightを使⽤可能 • データはS3にエクスポートされるためBigQueryなど任意ツールを使⽤可能 • Kubernetesラベルをコスト配分タグとして取り込み可能 • 2025年10⽉より利⽤可能 • カスタムラベルを使⽤してアプリケーション単位での可視化 （例）アプリケーション、事業組織、環境など ※1 https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data.html   CURのほか、KubecostやOpenCostなどのOSS、DatadogやNew Relicなどのオブザーバビリティツールも有⽤ ※2 AWS DataExports（CUR 2.0）とLegacy CURがある https://docs.aws.amazon.com/cur/latest/userguide/table-dictionary-cur2.html ※3 https://aws.amazon.com/about-aws/whats-new/2025/10/split-cost-allocation-data-amazon-eks-kubernetes-labels/ 

16 ©MIXI EKSコストの可視化（3/5）〜みてねでのCURデータ活⽤〜 （例）CURデータからNamespace/Deploymentごとのコストを可視化 

17 ©MIXI EKSコストの可視化（4/5）〜EKSのリソース使⽤率〜 EC2ノードはPodのリソース要求によりスケールするため リソース使⽤率が⾼い/割り当てが多いことのコスト影響は⼤きい • Deployment（≒ Pods） • CPU/メモリ使⽤率 • Node（≒ EC2）ごとの • CPU/メモリ使⽤率 • ディスク（≒ EBS）使⽤率 収集⼿段 • CloudWatch Container Insights • Prometheus（Node Exporter / kube-state-metrics）※1 • DatadogやNew Relicなどのエージェント ※1 EKSではPrometheus統合も利⽤可能 

18 ©MIXI EKSコストの可視化（5/5）〜みてねでのリソース使⽤率可視化〜 （例）PrometheusメトリクスからDeploymentごとのリソース使⽤率 

©MIXI 19 EKSコストの最適化 〜『家族アルバム みてね』での実践〜 

20 ©MIXI EKSコストの最適化（1/5）〜K8sリソース設計の⾒直し〜 KubernetesではPodのリソース指定とスケール※1 が EC2ノードのスケールに直結するためコスト影響が⼤きい 最適化ポイント • requests/limits の適正化 • 可視化したアプリケーションごとの使⽤率から コスト影響度や改善対象を判断 • アプリケーションのワークロード特性を考慮する • スケール条件（CPU/メモリ） • スパイクを考慮した limits 設定 • ほか、ノード起動時に割り当てる ボリューム（≒ EBS）サイズの最適化 ※1 Horizontal Pod Autoscaler（HPA）の使⽤を想定。ここではVertical Pod Autoscaler（VPA）については割愛 

21 ©MIXI EKSコストの最適化（2/5）〜Graviton（Arm）対応〜 AWS Graviton系（Arm）は インスタンスのコストパフォーマンスが高い傾向にある 最適化ポイント • マルチCPUアーキテクチャのリスク • 既存x86ノードと並存させ、一部のワークロードから対応をはじめる • nodeSelector / affinity / tolerations を活用 • 対象のワークロードは 移行リスクやコスト影響から判断 『EKS on EC2コストを Graviton導入で3割減した話』 https://team-blog.mitene.us/eks-on-ec2-graviton-ff08ecd4ec24 

22 ©MIXI EKSコストの最適化（2.5/5）〜Graviton（Arm）対応〜 AWS Gravitonの導入およびコスト削減について事例紹介に掲載いただきました！ https://aws.amazon.com/ec2/graviton/customers/#mixi 

23 ©MIXI EKSコストの最適化（3/5）〜ノードスケーラー改善〜 EC2ノードスケールは、EKSにおけるリソース管理の基盤であるため 適切なスケール構成をとることでコスト最適化につなげる 最適化ポイント • Cluster AutoscalerやKarpenterを必要に応じて選択 • Spot + On-Demandインスタンスを混合して構成し、Spotインスタンスが 優先して起動されるように構成 • Cluster AutoscalerではPriority based expanderの明⽰ • Karpenterではコスト最適なインスタンスの⾃動選択（結果Spotが起動） • ほか、Podリバランス、スケールイン遅延設定など 『Karpenterを再導入して EC2コストを削減した話』 https://team-blog.mitene.us/karpenterを再導入してec2コストを削減した話-72e9cc4ce08f 

24 ©MIXI EKSコストの最適化（4/5）〜AWSの強みを活かす〜 AWSの強みを活かしたコスト最適化 • Spotインスタンス • Savings Plans / Reserved Instancesの購⼊ • 予測可能なワークロードへの適⽤ • ネットワークデータ転送の最適化 • VPCピアリングやPrivateLinkの使⽤（AWS内部の通信に閉じる） • イメージ配置の最適化‧サイズ削減 • イメージPullからPod起動時間の短縮によるスケール⾼速化/効率化 • データ転送コストの削減 • EBSのボリュームタイプでgp3を使⽤、不要なEBSボリュームの削除 

25 ©MIXI EKSコストの最適化（5/5）〜Appendix〜 EKSコスト最適化にはアプリケーションチューニングも⾮常に重要 • 起動速度の改善 • Pod起動時間の安定化によりノードの過剰追加や確保時間を削減 • 処理の⾼速化、分割 • リソース使⽤時間やI/O待ち時間を短縮し、Pod稼働‧スケールの安定化 • 処理特性によりDeploymentを分割 • CPU/メモリ使⽤量の最適化 • マルチCPUアーキテクチャ対応（Graviton対応） • ステートレス設計（Spotインスタンス対応）※1 • 冪等性（Spotインスタンス対応） ※1 Kubernetes（Deployment）、アプリケーション両⽅でgracefulな終了を担保することが重要 

©MIXI 26 まとめ 

27 ©MIXI まとめ • EKSは、AWSのサービスが統合されたマネージドサービスKubernetesであり AWSのコスト最適化知⾒をそのまま活かせる • さらにAWS Cost and Usage Reportなどを使⽤して DeploymentやNamespaceごとのコストを詳細に可視化できる • さらにKubernetesのリソース制御、ノードスケーラー構成⾒直しなど Kubernetesのエコシステムを活⽤してコスト可視化‧最適化 AWSの運⽤知⾒ × Kubernetesの運⽤知⾒の両⾯を組み合わせ EKSで効率的なコスト最適化を実現 

©MIXI 28 ありがとうございました