4年間の取り組みで実現したコンテナ技術を活用したスケーラブルなインフラ構築とコスト削減 / Container Summit 2023

2023.5.31
コンテナSummit 2023

Transcript

1. ©MIXI 4年間の取り組みで実現したコンテナ技術を活⽤した スケーラブルなインフラ構築とコスト削減 2023.5.31 株式会社MIXI Vantageスタジオ みてねプロダクト開発部 基盤開発グループ 清⽔ 勲 コンテナSummit 2023
2. ©MIXI About Me 清⽔ 勲 @isaoshimizu 2011年〜 株式会社ミクシィ（現MIXI） • 2011年8⽉〜 SNS「mixi」運⽤エンジニア • 2014年4⽉〜 モンスターストライク SRE • 2018年2⽉〜 家族アルバム みてね SRE • 2022年1⽉〜 SREグループ マネージャー • 2023年4⽉〜 基盤開発グループ マネージャー • 週末は社会⼈吹奏楽団での活動（楽団⻑、トロンボーン約30年、たまに指揮者）。 キャンプとクラフトビールが好き。
3. ©MIXI エンタメ×テクノロジーの⼒で、 世界のコミュニケーションを豊かにする サービスの創出を⽬指しています。 MIXI GROUPは、友だちや家族といった 親しい人々とのコミュニケーションを活性化する、 様々なサービスを開発・提供しています。 現在、スポーツ・ライフスタイル・デジタルエンターテインメント の3つの領域で事業を展開しており、 それぞれの主な事業内容は右の通りです。 また、近年の投資活動の拡大と重要性を勘案し、 FY2023からはスタートアップやファンド出資等の投資活動を事業化しました。 スポーツ事業 プロスポーツチーム運営および 公営競技ビジネスの推進 ライフスタイル事業 インターネットを活用し、 人々の生活に密着したサービスの提供 デジタルエンターテインメント事業 スマホゲームを中心としたゲームの提供 .*9*
   (3061ͷࣄۀྖҬ 3つの領域で “コミュニケーションの活性化” に向けた事業を推進
4. ©MIXI ओͳࣄۀɾαʔϏεͷϦϦʔε೥ද
5. ©MIXI 家族アルバム みてね
6. ©MIXI 家族アルバム みてね パパ・ママが撮った⼦どもの写真や動画を、祖⽗⺟や親戚など 招待した家族だけに簡単に共有できる写真・動画共有アプリ フォトブック 写真プリント 商品の例
7. ©MIXI 家族アルバム みてね みてねみまもりGPS みてね出張撮影 みてね年賀状 みてねコールドクター
8. ©MIXI 家族アルバム みてね • 2015年4⽉リリース • 現在は7⾔語・175の国と地域でサービスを提供 • 海外では「FamilyAlbum」という名称で展開中 • 2022年8⽉14⽇に利⽤者数が1,500万⼈※1 を突破 • ⽇本国内ではママやパパの半数となる47.1％の⽅※2 がご利⽤ ※1 iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計 ※2「みてね」登録時に⼊⼒されたお⼦さまの誕⽣⽇と厚⽣労働省発表「⼈⼝動態統計」から算出。2022年8⽉時点で47.1％
9. ©MIXI 約４年間に渡るコンテナ移⾏の取り組みを紹介 （家族アルバム みてねにおける事例）
10. ©MIXI コンテナ以前のインフラにおける課題
11. ©MIXI コンテナ以前のインフラ • VM のオーケストレーション（AWS OpsWorksによる） • Chef、Cookbookによるインフラの構築・デプロイ⾃動化 • オートスケール（時刻ベース、ロードベースなど） • VMのモニタリング機能の統合 • ユーザー管理、SSHキーの管理機能 などなど。構築当初は効率よく開発、デプロイができていた。
12. ©MIXI 数年運⽤していくうちにさまざまな課題に直⾯
13. ©MIXI コンテナ移⾏前の課題 デプロイ • ChefのCookbookの管理、コードの依存関係が複雑に • デプロイ速度の問題（Chefの仕組み上の問題） パフォーマンス • オートスケールが遅い（ピーク帯に問題が起きやすい） 開発・運⽤ • SSHしてホスト内で作業をしたくない（VM間の差分が⽣まれやすい） • Docker使って開発したいという声（＝本番でもDocker使いたい） コスト • オンデマンドインスタンス前提でコスト⾼
14. ©MIXI コンテナへの期待
15. ©MIXI コンテナへの期待 • OSに依存せず、イメージ化によるポータビリティ • どの環境でも簡単にイメージを配置できる • オートスケール時の起動の速さ • コンテナの配置の速さ、イメージのキャッシュ再利⽤ • ディスポーザブルなインフラの実現 • SSHする機会を減らす • 中断に強い（スポットインスタンスを活⽤しやすい） • 従来のVMよりも効率的なハードウェアリソースの活⽤ • ボトルネックが少ない、空きリソースを活⽤できる • さまざまなサービスがコンテナを前提としてきている • AWSの例 • Amazon EKS、Amazon ECS、AWS App Runner、AWS CodeBuild、AWS Batch、Amazon SageMaker
16. ©MIXI VM運⽤とコンテナ運⽤は何が違うのか
17. ©MIXI VM運⽤とコンテナ運⽤ VM コンテナ デプロイ VM内にコードを配置 プロセスの再起動 コンテナイメージの配置 コンテナの再起動 リソース管理 VMの台数、タイプを調整 コンテナの個数、リソースを調整 ソフトウェアアップデート VMイメージの置き換え VM内で直接アップデート コンテナイメージの修正・ビルド インフラモニタリング VM内にエージェントを配置 ホストにエージェントを配置 アプリケーションモニタリング APMを利⽤ APMを利⽤
18. ©MIXI どうやってコンテナへ移⾏したか
19. ©MIXI コンテナオーケストレーションの選定 まずコンテナを運⽤するにはオーケストレーションサービスを選ぶところから 組織や課題に合ったサービスを選ぶのがオススメ 例： Amazon ECS、Amazon EKS、Google Cloud Run、Google Kubernetes Engine コンテナオーケストレーションサービスが提供するもの（⼀例） • デプロイメント • スケジューリング • 可⽤性 • トラフィックルーティング • リソース管理 など 家族アルバム みてねでは「Amazon EKS」を採⽤
20. ©MIXI コンテナ移⾏の流れ 旧環境 新環境 1. 新環境を構成 旧環境 新環境 2. 両⽅の環境にデプロイできるように 旧環境 新環境 3. 機能ごとに徐々に移⾏ 移⾏を終えたものは旧環境から削除 デプロイ
21. ©MIXI 移⾏時のポイント Service A Service B API Job Worker Job Worker Job Worker Dev Stg Prod Dev Stg Prod Service A Service B API Job Worker Job Worker Job Worker Service A Service B API Job Worker Job Worker Job Worker Service A Job Worker Service A Job Worker 移⾏ 旧環境 新環境 ⼩さく移⾏していく Service A Job Worker 全機能を各環境にまとめて移⾏ではなく
22. ©MIXI ⻑年にわたる試⾏錯誤の結果、無事移⾏が完了！
23. ©MIXI コンテナ移⾏による効果はどうだったか
24. ©MIXI コンテナによる効果 • オートスケールの⾼速化 • 急なトラフィックの変化に対してもスピーディにスケールできるように • スポットインスタンスのフル活⽤ • 9割以上のインスタンスがスポットになり⼤幅なコスト削減 • 普段使っているスポットインスタンスはオンデマンド⽐較で60〜70%割安 • 構成がシンプルに • 構成がDockerfileに集約された • さまざまな環境でも同じ構成を作りやすくなった • イメージの再利⽤性
25. ©MIXI コンテナ移⾏時のトラブルに備えるために
26. ©MIXI 移⾏時のトラブルに備える 新たな環境においてどんなトラブルが起きるかわからない トラブルが起きた際に問題の原因調査をスムーズに⾏いたい 移⾏前にオブザーバビリティを整備しておく
27. ©MIXI 移⾏時に採⽤したオブザーバビリティツール • アプリケーションモニタリング • New Relic APM • インフラモニタリング • New Relic Infrastructure • Prometheus • Amazon CloudWatch • Grafana
28. ©MIXI アプリケーションのモニタリング • 従来からNew Relic APM（Application Performance Monitoring）を使ってきた • APMではアプリケーションのパフォーマンス、エラーの状況が詳細にわかる • VMでもコンテナでも動くアプリケーションは同じ • APMはどちらの環境でも漏れなく動作して、問題があれば原因となる情報を提供する
29. ©MIXI インフラのモニタリング • インフラのモニタリングはVMとコンテナで構成やモニタリング対象が異なる • VMよりコンテナの⽅が構成するコンポーネントの階層が多くなり複雑性が⾼くなる • New Relic Infrastructureのように網羅性の⾼いツールの活⽤は効果的 • 移⾏時においてはロードバランサーやデータベースのモニタリングも重要 • 前段でのトラフィックやエラーレートの変化に気づく • OSSも併⽤してコスト最適化するのも⼀つの選択肢
30. ©MIXI オブザーバビリティの重要性 • 未知の問題に対して原因の調査ができる • システムの移⾏など⼤きな変更を伴う場合、あらかじめ狙ったメトリクスの モニタリングだと問題に気づけないことがある • ⽇々の開発、運⽤においても役に⽴つことが多い • 開発段階からAPMを通じてパフォーマンスの問題に気づくことができる • システムに対する熟練度に関わらず、より多くのメンバーが分析できるよう になる
31. ©MIXI コンテナ移⾏時のオブザーバビリティはとても⼤事
32. ©MIXI まとめ
33. ©MIXI まとめ • 移⾏によってコンテナのメリットは⼗分に享受することができた • 運⽤コストもインフラコストも⼤きく削減することができた • システムの移⾏作業は⼩さく⾏い、早くフィードバックを得られるようなサイクル を回すことが⼤事 • オブザーバビリティを整えておくと、移⾏時のトラブル解決が早くなる＝ユーザー への影響を最⼩限にできる • コンテナ環境においてもNew Relic APMを重宝した • オブザーバビリティはトラブル解決だけでなく⽇々の開発や運⽤にも役⽴つ、 熟練度に関わらずより多くのメンバーが分析できるようになる