Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

© 2024 Wantedly, Inc. イントロ

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

© 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週間後

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© 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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

© 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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

© 2024 Wantedly, Inc. その後

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

© 2024 Wantedly, Inc. まとめ

Slide 43

Slide 43 text

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