マルチCPUアーキテクチャ構成の実現に向けて

Transcript

1. ©MIXI マルチCPUアーキテクチャ構成の実現に向けて 2024/09/27 [みてね x アソビュー] EKS運用お困り事例紹介 @fanglang
2. ©MIXI 尾関 芳郎 ソフトウェアエンジニア 株式会社MIXI みてねプロダクト開発部 プラットフォームG SREチーム 2018年1月よりSREとしてみてねにJoin テキサスホールデムポーカーとコーヒー豆の焙煎が趣味です。 @fanglang
3. ©MIXI Agenda • AWSのコストが高いという課題 • なぜマルチアーキテクチャが必要か • マルチアーキテクチャ対応の苦労 • 今後の展望
4. ©MIXI AWSのコストが高いという課題
5. ©MIXI AWSのコストが高いという課題 • 『家族アルバム みてね』（以降、みてね）は 世界中で2000万人以上が利用している大人気サービス(2023年11月時点) • Amazon EKS (データプレーンはEC2) ◦ 90%以上がSpot Instance ◦ Node数: 50〜800 ◦ Pod数: 1,000〜14,000 • 画像・動画数: 131億件以上(2024年3月時点) • APIリクエスト: 1.5Mrpm以上(ピーク時)
6. ©MIXI AWSのコストが高いという課題 • 事業継続のためにもコストを抑えることは大きな課題 ◦ これまで様々な施策を行ってきた（下記はその一例） ▪ MIXIにおけるクラウドコスト最適化術 〜 10年選手の現SREマネージャー 2名に訊く 〜 ▪ 『家族アルバム みてね』に学ぶ、AWSのReserved InstancesとSavings Plansの勘所 ▪ みてねの動画再生にHLSを導入した話 ▪ 「無料・容量無制限でアップロード」を 支える みてねのコスト削減術 ▪ DBのコストを半額に！〜Amazon Aurora I/O-Optimizedの活用〜 • しかしまだまだ高い
7. ©MIXI AWSのコストが高いという課題 • 次の一手として、Graviton(arm64)アーキテクチャ採用に期待している ◦ 同等の x86 ベースのプロセッサと比較して最大 40% 優れた料金パフォーマンス ◦ AuroraやElastiCacheでは既に導入済み ◦ Spot Instanceの価格も安価で推移
8. ©MIXI なぜマルチアーキテクチャが必要か
9. ©MIXI なぜマルチアーキテクチャが必要か • 一見arm64に全て置き換えるほうが良さそうだが、リスクもある ◦ みてねではSpotを優先利用していて、枯渇した場合はOndemandにフォールバックする運用 になっている ▪ Priority based expanderで実装 ◦ そのため、万が一Spotが枯渇した場合は逆にコストアップとなる ▪ Spotを安定的に利用できる保証はない ▪ x86_64とarm64の両方を使えるようにすることで、枯渇リスクを下げる
10. ©MIXI なぜマルチアーキテクチャが必要か • ビッグバンリリースはリスクが大きい ◦ 安全のため、ワークロード毎の移行を計画 ▪ API (Puma) ▪ Job Queue (Sidekiq, Shoryuken) ▪ Cronjob (Rails Runner)
11. ©MIXI マルチアーキテクチャ対応の苦労
12. ©MIXI マルチアーキテクチャ対応の苦労 • Docker Imageのビルド ◦ QEMUによるマルチアーキテクチャビルドは遅くて使えない ▪ arm64はx86_64上でエミュレートしているので遅い ◦ GitHub Actionsでx86_64, arm64のRunnerで並列にビルド → manifest作成 ▪ manifestを使うことでCPUアーキテクチャ毎に適切なイメージを自動でプルできる ▪ (余談)はじめはSelf-hosted Runnerを用いてEKS上でビルドしようとした • 2024年6月からGitHub Actionsでarm64を使えるようになった • Self-hosted Runnerで実装した直後に発表された(泣)
13. ©MIXI マルチアーキテクチャ対応の苦労 • どうしてもarm64対応できない機能を切り出す ◦ ライブラリがx86_64にしか提供されていない機能がいくつかある ◦ 局所的にマイクロサービス化してx86_64で動かす ▪ 管理するものが増えてしまう、余計な通信が増えるリスク ◦ 参考：レガシーなシステムに向き合うということ
14. ©MIXI マルチアーキテクチャ対応の苦労 • CIでそれぞれのアーキテクチャでテストを実行する必要がある ◦ アーキテクチャの違いによるバグが出てしまう危険性 ◦ コストが倍かかる ▪ 開発時はarm64のテストをスキップする運用 ◦ アーキテクチャによって処理を変える ▪ x86_64ではマイクロサービスのコンテナも立ち上げてテストを実行 ▪ arm64だけレスポンスをスタブするようにテストコードを改修 ▪ マイクロサービスの挙動はx86_64で担保できているので許容
15. ©MIXI 今後の展望
16. ©MIXI 今後の展望 • まずは構築してリリースする ◦ 実はまだ完成していなくて本番投入できていません(2024年9月時点) ◦ 試算ではNodeの40%がGravitonになればEC2のコストが約10%下がる見込み • Karpenterの再導入 ◦ Nodeのリソース効率向上によるコスト最適化が期待できる ◦ 以前、一度諦めた経緯がありますが、再チャレンジしたい