AWS Fargateをx86からArm(Graviton)に移行しました

こんにちは、アスクルのかわいです。

LOHACOのバックエンドシステムのAWS Fargate上で稼働しているコンテナを、
x86_64(以下x86)ベースからArm(Graviton)ベースに移行したので、そのメリットや変更箇所などについて記述します。

1. x86からArm(Graviton)に移行するメリット

1.1 コスト削減

AWS GravitonベースのFargateを利用することで、従来のx86ベースに比べてコストが安くなる傾向があり、
オンデマンド料金で比較して、20％程度のコスト削減が可能とされています。

aws.amazon.com

1.2 省電力・環境負荷軽減

Armアーキテクチャは、一般的に消費電力が低いことでも知られており、
AWS公式のアナウンスでは、最大で60％の電力削減が可能とされています。

クラウド全体の電力消費を抑えることで、環境負荷の軽減にも寄与できる可能性があるため、サステナビリティの面でもメリットがあります。

aws.amazon.com

2. 経緯

当社では、Spring Bootを用いたアプリケーションを運用していますが、
Spring Boot 3.4からは、Armにデフォルトで対応したビルダーが使用されるようになりました。

github.com

そこでSpring Bootのアップデートを機に、x86からArmへ移行することにしました。

3. 変更箇所

実際にx86からArmへ移行した際の変更箇所を記述します。
当社ではTerraformを用いてインフラを管理しているため、変更箇所はTerraformのコードで記述します。

変更点は次の2点です。

CodeBuildのビルド環境をArm対応に変更
ECSタスク定義をArm対応に変更

3.1 CodeBuildのビルド環境をArm対応に変更

aws_codebuild_project の environment ブロックを次のように変更します。

変更前

resource "aws_codebuild_project" "this" {
  // 省略
  environment {
    image = "aws/codebuild/amazonlinux2-x86_64-standard:4.0"
    type = "LINUX_CONTAINER"
    // 省略
  }
  // 省略
}

変更後

resource "aws_codebuild_project" "this" {
  // 省略
  environment {
    image = "aws/codebuild/amazonlinux-aarch64-standard:3.0"
    type = "ARM_CONTAINER"
    // 省略
  }
  // 省略
}

3.2 ECSタスク定義をArm対応に変更

次に、aws_ecs_task_definition に runtime_platform を追加します。

resource "aws_ecs_task_definition" "this" {
  // 省略
     runtime_platform {
        operating_system_family = "LINUX"
        cpu_architecture        = "ARM64"
     }
  // 省略
}

これらの変更により、ECSのタスクがArmで稼働するようになります。

4. 移行における注意点

移行にあたって考慮した注意点は、主に次の2点です。

4.1 ベースイメージ

ベースイメージをDockerfileで独自に定義している場合、Arm対応のイメージに変更する必要があります。
たとえば、FROM paketobuildpacks/run-jammy-base のように記述している場合、
FROM paketobuildpacks/run-jammy-tiny のように変更する必要があります。