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

マルチCPUアーキテクチャ構成の実現に向けて 2024/09/27 [みてね x アソビュー] EKS運用お困り事例紹介 @fanglang ©MIXI

ソフトウェアエンジニア 尾関 芳郎 株式会社MIXI みてねプロダクト開発部 プラットフォームG SREチーム 2018年1月よりSREとしてみてねにJoin テキサスホールデムポーカーとコーヒー豆の焙煎が趣味です。 @fanglang ©MIXI

Agenda ● ● ● ● ©MIXI AWSのコストが高いという課題 なぜマルチアーキテクチャが必要か マルチアーキテクチャ対応の苦労 今後の展望

AWSのコストが高いという課題 ©MIXI

AWSのコストが高いという課題 ● ● 『家族アルバム みてね』（以降、みてね）は 世界中で2000万人以上が利用している大人気サービス(2023年11月時点) Amazon EKS (データプレーンはEC2) ○ ○ ○ ● ● ©MIXI 90%以上がSpot Instance Node数: 50〜800 Pod数: 1,000〜14,000 画像・動画数: 131億件以上(2024年3月時点) APIリクエスト: 1.5Mrpm以上(ピーク時)

AWSのコストが高いという課題 ● 事業継続のためにもコストを抑えることは大きな課題 ○ ● ©MIXI これまで様々な施策を行ってきた（下記はその一例） ■ MIXIにおけるクラウドコスト最適化術 〜 10年選手の現SREマネージャー 2名に訊く 〜 ■ 『家族アルバム みてね』に学ぶ、AWSのReserved InstancesとSavings Plansの勘所 ■ みてねの動画再生にHLSを導入した話 ■ 「無料・容量無制限でアップロード」を 支える みてねのコスト削減術 ■ DBのコストを半額に！〜Amazon Aurora I/O-Optimizedの活用〜 しかしまだまだ高い

• https://mixi-developers.mixi.co.jp/cloud-cost-optimization-c98058e5a64b
• https://gihyo.jp/article/2022/12/mitene-03aws-ri-sps
• https://team-blog.mitene.us/hls-6b749943c0b9
• https://speakerdeck.com/mixi_engineers/aws-cost-reduction-method-to-support-free-and-unlimited-uploading-in-mitene-family-album
• https://team-blog.mitene.us/amazon-aurora-i-o-optimized-891130ca63cd

AWSのコストが高いという課題 ● 次の一手として、Graviton(arm64)アーキテクチャ採用に期待している ○ ○ ○ ©MIXI 同等の x86 ベースのプロセッサと比較して最大 40% 優れた料金パフォーマンス AuroraやElastiCacheでは既に導入済み Spot Instanceの価格も安価で推移

• https://aws.amazon.com/jp/about-aws/whats-new/2021/11/elastic-beanstalk-aws-graviton-ec2/

なぜマルチアーキテクチャが必要か ©MIXI

なぜマルチアーキテクチャが必要か ● 一見arm64に全て置き換えるほうが良さそうだが、リスクもある ○ ○ ©MIXI みてねではSpotを優先利用していて、枯渇した場合はOndemandにフォールバックする運用 になっている ■ Priority based expanderで実装 そのため、万が一Spotが枯渇した場合は逆にコストアップとなる ■ Spotを安定的に利用できる保証はない ■ x86_64とarm64の両方を使えるようにすることで、枯渇リスクを下げる

• https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/expander/priority/readme.md

なぜマルチアーキテクチャが必要か ● ビッグバンリリースはリスクが大きい ○ ©MIXI 安全のため、ワークロード毎の移行を計画 ■ API (Puma) ■ Job Queue (Sidekiq, Shoryuken) ■ Cronjob (Rails Runner)

マルチアーキテクチャ対応の苦労 ©MIXI

マルチアーキテクチャ対応の苦労 ● Docker Imageのビルド ○ ○ QEMUによるマルチアーキテクチャビルドは遅くて使えない ■ arm64はx86_64上でエミュレートしているので遅い GitHub Actionsでx86_64, arm64のRunnerで並列にビルド → manifest作成 ■ ■ ©MIXI manifestを使うことでCPUアーキテクチャ毎に適切なイメージを自動でプルできる (余談)はじめはSelf-hosted Runnerを用いてEKS上でビルドしようとした ● 2024年6月からGitHub Actionsでarm64を使えるようになった ● Self-hosted Runnerで実装した直後に発表された(泣)

• https://github.blog/jp/2024-06-07-arm64-on-github-actions-powering-faster-more-efficient-build-systems/

マルチアーキテクチャ対応の苦労 ● どうしてもarm64対応できない機能を切り出す ○ ○ ○ ©MIXI ライブラリがx86_64にしか提供されていない機能がいくつかある 局所的にマイクロサービス化してx86_64で動かす ■ 管理するものが増えてしまう、余計な通信が増えるリスク 参考：レガシーなシステムに向き合うということ

• https://team-blog.mitene.us/a201fff59b42

マルチアーキテクチャ対応の苦労 ● CIでそれぞれのアーキテクチャでテストを実行する必要がある ○ ○ ○ ©MIXI アーキテクチャの違いによるバグが出てしまう危険性 コストが倍かかる ■ 開発時はarm64のテストをスキップする運用 アーキテクチャによって処理を変える ■ x86_64ではマイクロサービスのコンテナも立ち上げてテストを実行 ■ arm64だけレスポンスをスタブするようにテストコードを改修 ■ マイクロサービスの挙動はx86_64で担保できているので許容

今後の展望 ©MIXI

今後の展望 ● まずは構築してリリースする ○ ○ ● Karpenterの再導入 ○ ○ ©MIXI 実はまだ完成していなくて本番投入できていません(2024年9月時点) 試算ではNodeの40%がGravitonになればEC2のコストが約10%下がる見込み Nodeのリソース効率向上によるコスト最適化が期待できる 以前、一度諦めた経緯がありますが、再チャレンジしたい

• https://team-blog.mitene.us/karpenter-b48ca7cdc22a