Arm移行タイムアタック

Wantedly Tech Night 〜サービスを支えるインフラ /SRE技術〜 Arm移行 タイムアタック Nov. 20 2024 - Masaki Hara © 2024 Wantedly, Inc.

自己紹介 原 将己 (@qnighy) 修士卒 → ウォンテッドリー 7年目 ● バックエンド ● Webフロントエンド基盤 ● クラウドネイティブインフラ ↑NEW © 2024 Wantedly, Inc.

今日持ち帰ってほしいこと ● AWSのArmは安い! ● 普段から基盤を整えているから素早く動ける。 素早く動いたあとは、基盤に還元するべき。 © 2024 Wantedly, Inc.

イントロ © 2024 Wantedly, Inc.

Arm移行タイムアタック © 2024 Wantedly, Inc.

Arm移行タイムアタック © 2024 Wantedly, Inc.

Arm移行 Armにするだけで 2割安くなる ※2024-11-14時点 © 2024 Wantedly, Inc.

Arm移行 ウォンテッドリーでの主要なワークロードは2種類 ● RDS: Armに移行済みだった ● EC2+EKS: Intelを利用中だった → EKSをArmに移行できたらコスト削減になる © 2024 Wantedly, Inc.

Arm移行タイムアタック © 2024 Wantedly, Inc.

Arm移行タイムアタック © 2024 Wantedly, Inc.

タイムアタック — 開始 ● ウォンテッドリーのEKSでは、主にGitHub Actionsでビルドさ れたコンテナイメージを動かしている ● Arm64に移行するなら、Arm64環境でビルドするか、クロス ビルドが必要 ○ CodeBuildベースのRunnerの導入なども検討していたが、運用の手間や制約などの 懸念事項があり着手できていなかった © 2024 Wantedly, Inc.

タイムアタック — 開始 2024-06-03 GitHub Actions で Arm64 Runner が 利用可能に ※パブリックベータ → Arm移行を決意 ※実際に企画したのは 1週間後 © 2024 Wantedly, Inc. https://github.blog/news-insights/product-news/arm64-ongithub-actions-powering-faster-more-efficient-build-systems/

• https://github.blog/news-insights/product-news/arm64-on-github-actions-powering-faster-more-efficient-build-systems/

タイムアタック — 時限 ● AWSはいくつかの一括購入プランを提供している ● ウォンテッドリーも一括購入を利用 ● → 2024-07 下旬 に間に合わせると今年分の費用が削減で きる © 2024 Wantedly, Inc.

タイムアタック 1.5ヶ月での移行 6 Jun 7 Jul 1 1 2 3 4 5 6 2 3 4 5 6 7 8 7 8 9 10 11 12 13 9 10 11 12 13 14 15 14 15 16 17 18 19 20 16 17 18 19 20 21 22 21 22 23 24 25 26 27 23 24 25 26 27 28 29 28 29 30 31 30 © 2024 Wantedly, Inc.

課題 課題は大きく3つ ● 漸進的な移行を安全に行う ● 多数のサービスに効率的に変更を適用する ● 個々のサービスの固有の障害を克服する © 2024 Wantedly, Inc.

漸進的な移行 © 2024 Wantedly, Inc.

漸進的な移行 Arm移行は漸進的に行うことにした。理由は2つ ● ゼロイチではなく、部分的な成功をできるようにして保険をか けたい ● そもそも移行できないことがわかっているサービスがあった ○ Elasticsearch のバージョン 秘密 に無理 poyo © 2024 Wantedly, Inc. を動かしているので、短期間でのArm化は絶対

漸進的な移行 漸進的な移行のための道具 ● Multi-platform image (image index) ● Node selector © 2024 Wantedly, Inc.

Multi-platform image linux/amd64 golang@sha256:f61a48f… linux/arm/v7 複数のプラットフォームのイ メージを束ねたもの golang@sha256:6ebf8b0… linux/arm64/v8 golang@sha256:15b0073… linux/386 golang@sha256:4e00ae6… linux/mips64le golang@sha256:59b77b3… golang:latest = golang@sha256:c2d828f… linux/ppc64le golang@sha256:42ed77f… linux/s390x golang@sha256:64c2158… windows/amd64 golang@sha256:fd58f59… windows/amd64 golang@sha256:cec804d… © 2024 Wantedly, Inc.

Multi-platform image FROM golang:latest - image: golang:latest ● Dockerfile内: ● 利用時: ○ ○ $TARGETPLATFORM のイメー ジが使われる FROM --platform で上書き 可能 © 2024 Wantedly, Inc. ○ ○ ホストのプラットフォームに合わ せて選択される k8sの場合: node platformに 応じて選択

Node Selector Node Selector: Pod Podの割り当て先 条件を指定 amd64 nodes © 2024 Wantedly, Inc. arm64 nodes

漸進的な移行 Node amd64 Selector Image amd64, arm64 arm64 - amd64 amd64 - arm64 arm64 - amd64 ✔ ✔ ✔ 󰢃 󰢃 󰢃 󰢃 both ✔ ✔ ✔ ✔ ✔ ✔ ✔ arm64 󰢃 󰢃 󰢃 󰢃 ✔ ✔ ✔ © 2024 Wantedly, Inc.

漸進的な移行 安全にarm64 nodeを導入するには、 全てのPodが以下のどちらかの条件を満たす必要がある ● Node Selectorが設定されている ● イメージが両方のプラットフォームに対応している © 2024 Wantedly, Inc.

漸進的な移行 ● Node Selectorを設定するほうが、全てのイメージのビルド を修正するより簡単だった ● そうすればarm64 nodeを導入できる ● そこから先は 0点 OR 100点ではなく、成果が漸進的に得られ るフェーズに入る ○ 成果の不確実性を減らす重要なポイント © 2024 Wantedly, Inc.

多数のサービス © 2024 Wantedly, Inc.

多数のサービス ● ウォンテッドリーでは原則 1 Repository = 1 Namespace (k8s) 1 Repository = 1 Image 1 Repository = 1 Unit of Deployment ○ trunk-based開発なので、マージされるとリポジトリ全体がデプロイされる ● これを1サービスとして、全部で100サービスくらいある © 2024 Wantedly, Inc.

多数のサービス ● 約100あるサービス全てで、 Node Selector の設定、および イメージのビルド方法の変更 を加える必要がある ● なるべく効率的にやらないと1.5ヶ月では終わらない © 2024 Wantedly, Inc.

kube-go ● 社内インフラ管理には、 kubectlをラップした kube-go という内製ツールが 使われている ネーミングが安直 (?)なのは御愛嬌 ● ほとんどのマニフェストは kube-go によって自動生成される © 2024 Wantedly, Inc.

マニフェストの更新 内製ツールへの変更で 大多数は片付いた 内製ツールの更新PRも 自動化されている © 2024 Wantedly, Inc.

マニフェストの更新 内製ツールの 管理下にないものは 手動で対応 こういうのは割り切って 気合で対応するのも重要 変更対象の特定には、CLI ツールを自作して利用。 © 2024 Wantedly, Inc.

Selector vs. Toleration ● 実は Selector (Affinity) のほかに、 Taint/Toleration を使う方法もある ● Taintは除外リストで書けるため、初動コストは小さい ● しかし、作業が進むほど構成が変になりそう……。 ○ arm64がメインになるのに、メインのNodeがtaintされている状態 ● 将来性も考えて、Selectorで対応した ○ よい基盤に支えられているので、よい基盤をお返しする必要がある © 2024 Wantedly, Inc.

イメージの移行 & サービス固有の障害 © 2024 Wantedly, Inc.

イメージの移行 ● amd64オンリーだったイメージをmulti-platformにする ● 内製ツールのkube-goがビルド手順も管理しているので、変 更の大部分は一律でできる © 2024 Wantedly, Inc.

Multi-platform imageのビルド Multi-platform imageをビルドする方法は3種類 ● 1種類のbuilderでクロスビルドする ● リモートビルダーでビルドする docker buildx imagetools create を使う ● プラットフォーム別にビルドして、あとで結合する Actionsだとビルダーの仕組みに乗るのが難しいので、あとで結 合する方式を選択 © 2024 Wantedly, Inc.

Multi-platform imageのビルド タグは :${SHA1}-amd64 amd64 runner イメージをビルド ビルド準備 イメージを結合 arm64 runner イメージをビルド タグは :${SHA1}-arm64 © 2024 Wantedly, Inc. タグは :${SHA1}

ビルド手順の変更 ● 複数のGitHub Actions jobを使ってビルドするため、 shared workflowを整備 ● その影響で、 Dockerfile の外でビルド準備をするのが難しく なった ○ チェックアウトした状態で docker build が通らないといけない ● これは良い制約であるため、あえて対策しなかった © 2024 Wantedly, Inc.

イメージの移行 ● さすがに対応内容が多いので、チームメンバーなどに依頼し て手分けして作業 ○ 依頼内容については、負荷の高いサービスを優先したり、すでにある知見を横展開しや いものを依頼に回すようにといった工夫をした。 ● ここでサービス固有の問題がどれくらい出てくるかが心配だっ た © 2024 Wantedly, Inc.

サービス固有の問題 ● サービスごとに固有の依存関係が、amd64にしか対応して いない可能性を危惧 ● 実際、いくつかのケースでは依存の更新が必要だった ● しかし、大多数のサービスではそのまま移行できた 🎉 これは、アプリケーション開発者が日々の更新を続けてくれて いたから。 ○ これも一種の基盤。 © 2024 Wantedly, Inc. ……という科学的根拠があるわけではないが、そう思っている。

イメージの移行 ● 最終的に、当初予定の 65% 程度の移行ができた。 ○ ○ ○ 100% はさすがに厳しかった 進めば進むほど、細かくて移行が難しいものが残る 比率はコストへの寄与の推定値に基づく ● 元々移行しない予定だったものを含めると、EC2コスト全体の 半分がarm化した。 50% (削減対象) × 20% (削減割合) = 10% の削減 © 2024 Wantedly, Inc.

その後 © 2024 Wantedly, Inc.

arm64移行のその後 ● 移行できた割合に応じて購入割合を調整し、今年分の移行は 完了になった。 ● 来年はさらに移行を進めたい。 ○ できれば100%にしたい ● Multi-platform imageはまだそのままになっている ○ ○ CIコストへの寄与がそこまで高くなかったため 理屈の上では、移行が完了したものから順に単一プラットフォームに戻せるはず © 2024 Wantedly, Inc.

まとめ © 2024 Wantedly, Inc.

今日持ち帰ってほしいこと ● AWSのArmは安い! ● 普段から基盤を整えているから素早く動ける。 素早く動いたあとは、基盤に還元するべき。 © 2024 Wantedly, Inc.