Arm移行タイムアタック

コスト削減はいついかなる時でも重要です。さて、もしサービスを別のCPUで動かすだけで2割安くなると言われたら、皆さんはどうするでしょうか? やりたいですよね。 ただし、サービス数は100以上、タイムリミットは2ヶ月です。

Wantedly Tech Night 〜サービスを支えるインフラ/SRE技術〜 にて発表 https://wantedly.connpass.com/event/332164/

Transcript

1. © 2024 Wantedly, Inc. Arm移行 タイムアタック Wantedly Tech Night 〜サービスを支えるインフラ /SRE技術〜 Nov. 20 2024 - Masaki Hara
2. © 2024 Wantedly, Inc. 自己紹介 原 将己 (@qnighy) 修士卒 → ウォンテッドリー 7年目 • バックエンド • Webフロントエンド基盤 • クラウドネイティブインフラ ↑NEW
3. © 2024 Wantedly, Inc. 今日持ち帰ってほしいこと • AWSのArmは安い! • 普段から基盤を整えているから素早く動ける。 素早く動いたあとは、基盤に還元するべき。
4. © 2024 Wantedly, Inc. イントロ
5. © 2024 Wantedly, Inc. Arm移行タイムアタック
6. © 2024 Wantedly, Inc. Arm移行タイムアタック
7. © 2024 Wantedly, Inc. Arm移行 Armにするだけで 2割安くなる ※2024-11-14時点
8. © 2024 Wantedly, Inc. Arm移行 ウォンテッドリーでの主要なワークロードは2種類 • RDS: Armに移行済みだった • EC2+EKS: Intelを利用中だった → EKSをArmに移行できたらコスト削減になる
9. © 2024 Wantedly, Inc. Arm移行タイムアタック
10. © 2024 Wantedly, Inc. Arm移行タイムアタック
11. © 2024 Wantedly, Inc. タイムアタック — 開始 • ウォンテッドリーのEKSでは、主にGitHub Actionsでビルドさ れたコンテナイメージを動かしている • Arm64に移行するなら、Arm64環境でビルドするか、クロス ビルドが必要 ◦ CodeBuildベースのRunnerの導入なども検討していたが、運用の手間や制約などの 懸念事項があり着手できていなかった
12. © 2024 Wantedly, Inc. タイムアタック — 開始 2024-06-03 GitHub Actions で Arm64 Runner が 利用可能に → Arm移行を決意 https://github.blog/news-insights/product-news/arm64-on- github-actions-powering-faster-more-efficient-build-systems/ ※パブリックベータ ※実際に企画したのは 1週間後
13. © 2024 Wantedly, Inc. タイムアタック — 時限 • AWSはいくつかの一括購入プランを提供している • ウォンテッドリーも一括購入を利用 • → 2024-07 下旬 に間に合わせると今年分の費用が削減で きる
14. © 2024 Wantedly, Inc. タイムアタック 1.5ヶ月での移行 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 6 7 Jun Jul
15. © 2024 Wantedly, Inc. 課題 課題は大きく3つ • 漸進的な移行を安全に行う • 多数のサービスに効率的に変更を適用する • 個々のサービスの固有の障害を克服する
16. © 2024 Wantedly, Inc. 漸進的な移行
17. © 2024 Wantedly, Inc. 漸進的な移行 Arm移行は漸進的に行うことにした。理由は2つ • ゼロイチではなく、部分的な成功をできるようにして保険をか けたい • そもそも移行できないことがわかっているサービスがあった ◦ Elasticsearch のバージョン 秘密 を動かしているので、短期間での Arm化は絶対 に無理 poyo
18. © 2024 Wantedly, Inc. 漸進的な移行 漸進的な移行のための道具 • Multi-platform image (image index) • Node selector
19. © 2024 Wantedly, Inc. Multi-platform image 複数のプラットフォームのイ メージを束ねたもの golang:latest = golang@sha256:c2d828f… golang@sha256:f61a48f… golang@sha256:6ebf8b0… linux/amd64 linux/arm/v7 golang@sha256:15b0073… linux/arm64/v8 golang@sha256:4e00ae6… golang@sha256:59b77b3… golang@sha256:42ed77f… golang@sha256:64c2158… golang@sha256:fd58f59… golang@sha256:cec804d… linux/386 linux/mips64le linux/ppc64le linux/s390x windows/amd64 windows/amd64
20. © 2024 Wantedly, Inc. Multi-platform image • Dockerfile内: ◦ $TARGETPLATFORM のイメー ジが使われる ◦ FROM --platform で上書き 可能 FROM golang:latest - image: golang:latest • 利用時: ◦ ホストのプラットフォームに合わ せて選択される ◦ k8sの場合: node platformに 応じて選択
21. © 2024 Wantedly, Inc. Node Selector Node Selector: Podの割り当て先 条件を指定 amd64 nodes arm64 nodes Pod
22. © 2024 Wantedly, Inc. 漸進的な移行 Node amd64 amd64, arm64 arm64 Selector - amd64 amd64 - arm64 arm64 - Image amd64 ✔ ✔ ✔ 󰢃 󰢃 󰢃 󰢃 both ✔ ✔ ✔ ✔ ✔ ✔ ✔ arm64 󰢃 󰢃 󰢃 󰢃 ✔ ✔ ✔
23. © 2024 Wantedly, Inc. 漸進的な移行 安全にarm64 nodeを導入するには、 全てのPodが以下のどちらかの条件を満たす必要がある • Node Selectorが設定されている • イメージが両方のプラットフォームに対応している
24. © 2024 Wantedly, Inc. 漸進的な移行 • Node Selectorを設定するほうが、全てのイメージのビルド を修正するより簡単だった • そうすればarm64 nodeを導入できる • そこから先は 0点 OR 100点ではなく、成果が漸進的に得られ るフェーズに入る ◦ 成果の不確実性を減らす重要なポイント
25. © 2024 Wantedly, Inc. 多数のサービス
26. © 2024 Wantedly, Inc. 多数のサービス • ウォンテッドリーでは原則 1 Repository = 1 Namespace (k8s) 1 Repository = 1 Image 1 Repository = 1 Unit of Deployment ◦ trunk-based開発なので、マージされるとリポジトリ全体がデプロイされる • これを1サービスとして、全部で100サービスくらいある
27. © 2024 Wantedly, Inc. 多数のサービス • 約100あるサービス全てで、 Node Selector の設定、および イメージのビルド方法の変更 を加える必要がある • なるべく効率的にやらないと1.5ヶ月では終わらない
28. © 2024 Wantedly, Inc. kube-go • 社内インフラ管理には、 kubectlをラップした kube-go という内製ツールが 使われている • ほとんどのマニフェストは kube-go によって自動生成される ネーミングが安直(?)なのは御愛嬌
29. © 2024 Wantedly, Inc. マニフェストの更新 内製ツールへの変更で 大多数は片付いた 内製ツールの更新PRも 自動化されている
30. © 2024 Wantedly, Inc. マニフェストの更新 内製ツールの 管理下にないものは 手動で対応 変更対象の特定には、CLI ツールを自作して利用。 こういうのは割り切って 気合で対応するのも重要
31. © 2024 Wantedly, Inc. Selector vs. Toleration • 実は Selector (Affinity) のほかに、 Taint/Toleration を使う方法もある • Taintは除外リストで書けるため、初動コストは小さい • しかし、作業が進むほど構成が変になりそう……。 ◦ arm64がメインになるのに、メインのNodeがtaintされている状態 • 将来性も考えて、Selectorで対応した ◦ よい基盤に支えられているので、よい基盤をお返しする必要がある
32. © 2024 Wantedly, Inc. イメージの移行 & サービス固有の障害
33. © 2024 Wantedly, Inc. イメージの移行 • amd64オンリーだったイメージをmulti-platformにする • 内製ツールのkube-goがビルド手順も管理しているので、変 更の大部分は一律でできる
34. © 2024 Wantedly, Inc. Multi-platform imageのビルド Multi-platform imageをビルドする方法は3種類 • 1種類のbuilderでクロスビルドする • リモートビルダーでビルドする • プラットフォーム別にビルドして、あとで結合する Actionsだとビルダーの仕組みに乗るのが難しいので、あとで結 合する方式を選択 docker buildx imagetools create を使う
35. © 2024 Wantedly, Inc. Multi-platform imageのビルド ビルド準備 amd64 runner イメージをビルド arm64 runner イメージをビルド イメージを結合 タグは :${SHA1}-amd64 タグは :${SHA1}-arm64 タグは :${SHA1}
36. © 2024 Wantedly, Inc. ビルド手順の変更 • 複数のGitHub Actions jobを使ってビルドするため、 shared workflowを整備 • その影響で、 Dockerfile の外でビルド準備をするのが難しく なった ◦ チェックアウトした状態で docker build が通らないといけない • これは良い制約であるため、あえて対策しなかった
37. © 2024 Wantedly, Inc. イメージの移行 • さすがに対応内容が多いので、チームメンバーなどに依頼し て手分けして作業 ◦ 依頼内容については、負荷の高いサービスを優先したり、すでにある知見を横展開しや いものを依頼に回すようにといった工夫をした。 • ここでサービス固有の問題がどれくらい出てくるかが心配だっ た
38. © 2024 Wantedly, Inc. サービス固有の問題 • サービスごとに固有の依存関係が、amd64にしか対応して いない可能性を危惧 • 実際、いくつかのケースでは依存の更新が必要だった • しかし、大多数のサービスではそのまま移行できた 🎉 これは、アプリケーション開発者が日々の更新を続けてくれて いたから。 ◦ これも一種の基盤。 ……という科学的根拠があるわけではないが、そう思っている。
39. © 2024 Wantedly, Inc. イメージの移行 • 最終的に、当初予定の 65% 程度の移行ができた。 ◦ 100% はさすがに厳しかった ◦ 進めば進むほど、細かくて移行が難しいものが残る ◦ 比率はコストへの寄与の推定値に基づく • 元々移行しない予定だったものを含めると、EC2コスト全体の 半分がarm化した。 50% (削減対象) × 20% (削減割合) = 10% の削減
40. © 2024 Wantedly, Inc. その後
41. © 2024 Wantedly, Inc. arm64移行のその後 • 移行できた割合に応じて購入割合を調整し、今年分の移行は 完了になった。 • 来年はさらに移行を進めたい。 ◦ できれば100%にしたい • Multi-platform imageはまだそのままになっている ◦ CIコストへの寄与がそこまで高くなかったため ◦ 理屈の上では、移行が完了したものから順に単一プラットフォームに戻せるはず
42. © 2024 Wantedly, Inc. まとめ
43. © 2024 Wantedly, Inc. 今日持ち帰ってほしいこと • AWSのArmは安い! • 普段から基盤を整えているから素早く動ける。 素早く動いたあとは、基盤に還元するべき。