お久しぶりです。スターフェスティバル株式会社エンジニアのsoriです。
6/3にGitHubからArm64環境のGitHub Actions Runnerが発表されました！
まだこのRunnerはPublic betaであり、Team/Enterprise planでしか使えませんが、Silicon Macの普及やAWSでもGravitonインスタンスが使われるようになり、コストにもパフォーマンスにも寄与する良い感じの流れになってきましたね。
そんな流れが来たので自社のサービスの動作環境をarm64に対応させてみました。
ちなみに、既存の環境はGitHub Actionsでdocker buildでイメージをビルドし、AWS ECRのリポジトリにアップロードし、Amazon ECS Fargateな環境にタスク定義をレンダリングさせて動作させるといった状況です。
社内向けにメモをしたためたのですが、せっかくなのでzennに公開してみました。参考にしていただけると嬉しいです。
arm64ビルドを使うためのメモ
arm64ビルドを使うことのメリット
- Amazonのインスタンスでarm64 gravitonインスタンスを使うと約20%のインスタンス使用料削減効果が得られる
- GitHub ActionsのLarger arm64 runnerを使ってもたとえば2 coreのインスタンスならStandard Runnerの$0.008/minから$0.005/minと安い
- ただし、standard runnerと比較してはじめの1分から課金されるので、無料利用分に含まれないので注意
- より大きなランナーって名前なのに実は安い
- パフォーマンスも向上している
- ただし、稼働させる内容による。たとえばphpは遅いらしい（参考サイト参照）
ECSで使う場合の対応手段のメモ
ecsタスク定義の記述を追加する
"runtimePlatform": {
"cpuArchitecture": "ARM64",
"operatingSystemFamily": "LINUX"
},
必要に応じてDockerfileの記述を修正する
- 同じnode-slimイメージでも、amd64のイメージと比較して足りないパッケージがある可能性がある
- APIの検証ではDockerfileで下記のパッケージを追加した
RUN apt-get install -y python3 && apt-get install -y make && apt-get install -y g++
ビルドコマンドを修正する
- docker buildコマンドに
--platform linux/arm64オプションをつける- マルチステージビルド（amd64,arm64など両方対応できる）のイメージを作りたい場合は、docker buildxコマンドを使う必要がある。単一環境なら不要
- GitHub Action上でビルドする場合は、Larger Runner（より大きなランナー）が必要
- これを使う場合は、Actionsのyaml内の
runs-on: ubuntu-latest記述のある場所をruns-on: ubuntu-22.04-2core-arm64のように、作成したランナーの名前に変更する - ランナーの起動時間があるので、slack投稿などシンプルなstepの場合、jobを分離して
ubuntu-latest(standard runner)のまま使ったほうが早くて良さそう - より大きなランナーを使わないで、qemuを使ってやる方法もある
- ただし、qemuを使うとめちゃめちゃ重い。仮想環境なので（arm64 runnerが来る前の検証で5倍ぐらいかかった）
- これを使う場合は、Actionsのyaml内の
Discussion