Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マルチCPUアーキテクチャ構成の実現に向けて
Search
fanglang
September 25, 2024
1
150
マルチCPUアーキテクチャ構成の実現に向けて
fanglang
September 25, 2024
Tweet
Share
More Decks by fanglang
See All by fanglang
海外から快適に使ってもらうためにしてきたこと / the battle with network latency
fanglang
0
4k
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
A Philosophy of Restraint
colly
203
16k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
7.9k
Music & Morning Musume
bryan
46
6.1k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Side Projects
sachag
452
42k
GraphQLとの向き合い方2022年版
quramy
43
13k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
A Modern Web Designer's Workflow
chriscoyier
692
190k
Six Lessons from altMBA
skipperchong
26
3.5k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Transcript
©MIXI マルチCPUアーキテクチャ構成の実現に向けて 2024/09/27 [みてね x アソビュー] EKS運用お困り事例紹介 @fanglang
©MIXI 尾関 芳郎 ソフトウェアエンジニア 株式会社MIXI みてねプロダクト開発部 プラットフォームG SREチーム 2018年1月よりSREとしてみてねにJoin テキサスホールデムポーカーとコーヒー豆の焙煎が趣味です。
@fanglang
©MIXI Agenda • AWSのコストが高いという課題 • なぜマルチアーキテクチャが必要か • マルチアーキテクチャ対応の苦労 • 今後の展望
©MIXI AWSのコストが高いという課題
©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以上(ピーク時)
©MIXI AWSのコストが高いという課題 • 事業継続のためにもコストを抑えることは大きな課題 ◦ これまで様々な施策を行ってきた(下記はその一例) ▪ MIXIにおけるクラウドコスト最適化術 〜 10年選手の現SREマネージャー
2名に訊く 〜 ▪ 『家族アルバム みてね』に学ぶ、AWSのReserved InstancesとSavings Plansの勘所 ▪ みてねの動画再生にHLSを導入した話 ▪ 「無料・容量無制限でアップロード」を 支える みてねのコスト削減術 ▪ DBのコストを半額に!〜Amazon Aurora I/O-Optimizedの活用〜 • しかしまだまだ高い
©MIXI AWSのコストが高いという課題 • 次の一手として、Graviton(arm64)アーキテクチャ採用に期待している ◦ 同等の x86 ベースのプロセッサと比較して最大 40% 優れた料金パフォーマンス
◦ AuroraやElastiCacheでは既に導入済み ◦ Spot Instanceの価格も安価で推移
©MIXI なぜマルチアーキテクチャが必要か
©MIXI なぜマルチアーキテクチャが必要か • 一見arm64に全て置き換えるほうが良さそうだが、リスクもある ◦ みてねではSpotを優先利用していて、枯渇した場合はOndemandにフォールバックする運用 になっている ▪ Priority based
expanderで実装 ◦ そのため、万が一Spotが枯渇した場合は逆にコストアップとなる ▪ Spotを安定的に利用できる保証はない ▪ x86_64とarm64の両方を使えるようにすることで、枯渇リスクを下げる
©MIXI なぜマルチアーキテクチャが必要か • ビッグバンリリースはリスクが大きい ◦ 安全のため、ワークロード毎の移行を計画 ▪ API (Puma) ▪
Job Queue (Sidekiq, Shoryuken) ▪ Cronjob (Rails Runner)
©MIXI マルチアーキテクチャ対応の苦労
©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で実装した直後に発表された(泣)
©MIXI マルチアーキテクチャ対応の苦労 • どうしてもarm64対応できない機能を切り出す ◦ ライブラリがx86_64にしか提供されていない機能がいくつかある ◦ 局所的にマイクロサービス化してx86_64で動かす ▪ 管理するものが増えてしまう、余計な通信が増えるリスク
◦ 参考:レガシーなシステムに向き合うということ
©MIXI マルチアーキテクチャ対応の苦労 • CIでそれぞれのアーキテクチャでテストを実行する必要がある ◦ アーキテクチャの違いによるバグが出てしまう危険性 ◦ コストが倍かかる ▪ 開発時はarm64のテストをスキップする運用
◦ アーキテクチャによって処理を変える ▪ x86_64ではマイクロサービスのコンテナも立ち上げてテストを実行 ▪ arm64だけレスポンスをスタブするようにテストコードを改修 ▪ マイクロサービスの挙動はx86_64で担保できているので許容
©MIXI 今後の展望
©MIXI 今後の展望 • まずは構築してリリースする ◦ 実はまだ完成していなくて本番投入できていません(2024年9月時点) ◦ 試算ではNodeの40%がGravitonになればEC2のコストが約10%下がる見込み • Karpenterの再導入
◦ Nodeのリソース効率向上によるコスト最適化が期待できる ◦ 以前、一度諦めた経緯がありますが、再チャレンジしたい