Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

fanglang
September 25, 2024
150

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

fanglang

September 25, 2024
Tweet

Transcript

  1. ©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以上(ピーク時)
  2. ©MIXI AWSのコストが高いという課題 • 事業継続のためにもコストを抑えることは大きな課題 ◦ これまで様々な施策を行ってきた(下記はその一例) ▪ MIXIにおけるクラウドコスト最適化術 〜 10年選手の現SREマネージャー

    2名に訊く 〜 ▪ 『家族アルバム みてね』に学ぶ、AWSのReserved InstancesとSavings Plansの勘所 ▪ みてねの動画再生にHLSを導入した話 ▪ 「無料・容量無制限でアップロード」を 支える みてねのコスト削減術 ▪ DBのコストを半額に!〜Amazon Aurora I/O-Optimizedの活用〜 • しかしまだまだ高い
  3. ©MIXI なぜマルチアーキテクチャが必要か • 一見arm64に全て置き換えるほうが良さそうだが、リスクもある ◦ みてねではSpotを優先利用していて、枯渇した場合はOndemandにフォールバックする運用 になっている ▪ Priority based

    expanderで実装 ◦ そのため、万が一Spotが枯渇した場合は逆にコストアップとなる ▪ Spotを安定的に利用できる保証はない ▪ x86_64とarm64の両方を使えるようにすることで、枯渇リスクを下げる
  4. ©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で実装した直後に発表された(泣)
  5. ©MIXI マルチアーキテクチャ対応の苦労 • CIでそれぞれのアーキテクチャでテストを実行する必要がある ◦ アーキテクチャの違いによるバグが出てしまう危険性 ◦ コストが倍かかる ▪ 開発時はarm64のテストをスキップする運用

    ◦ アーキテクチャによって処理を変える ▪ x86_64ではマイクロサービスのコンテナも立ち上げてテストを実行 ▪ arm64だけレスポンスをスタブするようにテストコードを改修 ▪ マイクロサービスの挙動はx86_64で担保できているので許容