$30 off During Our Annual Pro Sale. View Details »

Arm移行タイムアタック

Masaki Hara
November 20, 2024

 Arm移行タイムアタック

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

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

Masaki Hara

November 20, 2024
Tweet

More Decks by Masaki Hara

Other Decks in Programming

Transcript

  1. © 2024 Wantedly, Inc. 自己紹介 原 将己 (@qnighy) 修士卒 →

    ウォンテッドリー 7年目 • バックエンド • Webフロントエンド基盤 • クラウドネイティブインフラ ↑NEW
  2. © 2024 Wantedly, Inc. Arm移行 ウォンテッドリーでの主要なワークロードは2種類 • RDS: Armに移行済みだった •

    EC2+EKS: Intelを利用中だった → EKSをArmに移行できたらコスト削減になる
  3. © 2024 Wantedly, Inc. タイムアタック — 開始 • ウォンテッドリーのEKSでは、主にGitHub Actionsでビルドさ

    れたコンテナイメージを動かしている • Arm64に移行するなら、Arm64環境でビルドするか、クロス ビルドが必要 ◦ CodeBuildベースのRunnerの導入なども検討していたが、運用の手間や制約などの 懸念事項があり着手できていなかった
  4. © 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週間後
  5. © 2024 Wantedly, Inc. タイムアタック — 時限 • AWSはいくつかの一括購入プランを提供している •

    ウォンテッドリーも一括購入を利用 • → 2024-07 下旬 に間に合わせると今年分の費用が削減で きる
  6. © 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
  7. © 2024 Wantedly, Inc. 漸進的な移行 Arm移行は漸進的に行うことにした。理由は2つ • ゼロイチではなく、部分的な成功をできるようにして保険をか けたい •

    そもそも移行できないことがわかっているサービスがあった ◦ Elasticsearch のバージョン 秘密 を動かしているので、短期間での Arm化は絶対 に無理 poyo
  8. © 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
  9. © 2024 Wantedly, Inc. Multi-platform image • Dockerfile内: ◦ $TARGETPLATFORM

    のイメー ジが使われる ◦ FROM --platform で上書き 可能 FROM golang:latest - image: golang:latest • 利用時: ◦ ホストのプラットフォームに合わ せて選択される ◦ k8sの場合: node platformに 応じて選択
  10. © 2024 Wantedly, Inc. 漸進的な移行 Node amd64 amd64, arm64 arm64

    Selector - amd64 amd64 - arm64 arm64 - Image amd64 ✔ ✔ ✔ 󰢃 󰢃 󰢃 󰢃 both ✔ ✔ ✔ ✔ ✔ ✔ ✔ arm64 󰢃 󰢃 󰢃 󰢃 ✔ ✔ ✔
  11. © 2024 Wantedly, Inc. 漸進的な移行 • Node Selectorを設定するほうが、全てのイメージのビルド を修正するより簡単だった •

    そうすればarm64 nodeを導入できる • そこから先は 0点 OR 100点ではなく、成果が漸進的に得られ るフェーズに入る ◦ 成果の不確実性を減らす重要なポイント
  12. © 2024 Wantedly, Inc. 多数のサービス • ウォンテッドリーでは原則 1 Repository =

    1 Namespace (k8s) 1 Repository = 1 Image 1 Repository = 1 Unit of Deployment ◦ trunk-based開発なので、マージされるとリポジトリ全体がデプロイされる • これを1サービスとして、全部で100サービスくらいある
  13. © 2024 Wantedly, Inc. 多数のサービス • 約100あるサービス全てで、 Node Selector の設定、および

    イメージのビルド方法の変更 を加える必要がある • なるべく効率的にやらないと1.5ヶ月では終わらない
  14. © 2024 Wantedly, Inc. kube-go • 社内インフラ管理には、 kubectlをラップした kube-go という内製ツールが

    使われている • ほとんどのマニフェストは kube-go によって自動生成される ネーミングが安直(?)なのは御愛嬌
  15. © 2024 Wantedly, Inc. Selector vs. Toleration • 実は Selector

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

    • リモートビルダーでビルドする • プラットフォーム別にビルドして、あとで結合する Actionsだとビルダーの仕組みに乗るのが難しいので、あとで結 合する方式を選択 docker buildx imagetools create を使う
  17. © 2024 Wantedly, Inc. Multi-platform imageのビルド ビルド準備 amd64 runner イメージをビルド

    arm64 runner イメージをビルド イメージを結合 タグは :${SHA1}-amd64 タグは :${SHA1}-arm64 タグは :${SHA1}
  18. © 2024 Wantedly, Inc. ビルド手順の変更 • 複数のGitHub Actions jobを使ってビルドするため、 shared

    workflowを整備 • その影響で、 Dockerfile の外でビルド準備をするのが難しく なった ◦ チェックアウトした状態で docker build が通らないといけない • これは良い制約であるため、あえて対策しなかった
  19. © 2024 Wantedly, Inc. サービス固有の問題 • サービスごとに固有の依存関係が、amd64にしか対応して いない可能性を危惧 • 実際、いくつかのケースでは依存の更新が必要だった

    • しかし、大多数のサービスではそのまま移行できた 🎉 これは、アプリケーション開発者が日々の更新を続けてくれて いたから。 ◦ これも一種の基盤。 ……という科学的根拠があるわけではないが、そう思っている。
  20. © 2024 Wantedly, Inc. イメージの移行 • 最終的に、当初予定の 65% 程度の移行ができた。 ◦

    100% はさすがに厳しかった ◦ 進めば進むほど、細かくて移行が難しいものが残る ◦ 比率はコストへの寄与の推定値に基づく • 元々移行しない予定だったものを含めると、EC2コスト全体の 半分がarm化した。 50% (削減対象) × 20% (削減割合) = 10% の削減
  21. © 2024 Wantedly, Inc. arm64移行のその後 • 移行できた割合に応じて購入割合を調整し、今年分の移行は 完了になった。 • 来年はさらに移行を進めたい。

    ◦ できれば100%にしたい • Multi-platform imageはまだそのままになっている ◦ CIコストへの寄与がそこまで高くなかったため ◦ 理屈の上では、移行が完了したものから順に単一プラットフォームに戻せるはず