【AWS】AWS Batchコンピューティング環境のEOLに対処した時のお話

こんにちは。しげぞうです。

弊社開発のプロダクトで、AWS Batch を活用してバッチ処理を稼働させているのですが、先日AWSからコンピューティング環境に関して以下の内容のメールが届きました。

お客様の AWS Batch コンピューティング環境は、 Batch 提供の Amazon Linux AMI を使用しています。
こちらの Amazon Linux AMI は2023年12月31日にサポートが終了し、該当のコンピューティング環境のステータスが 無効 となり使用不可になります。

コンピューティング環境を更新または変更し、代わりに Amazon Linux 2 を使用することをお勧めします。

。。。

コンピューティング環境が使用不可になる(ワークロードが実行されなくなる)のは困るので、AWS BatchにおけるAmazonLinux AMIのEOL対応を行いました。

今後もAMIのサポート終了はついてまわると思いますので、対応の中で気をつけたことを掲載します。

移行計画の検討

移行対応を進めるにあたって、以下のポイントを明確にしました。

  • 対象となるコンピューティング環境の調査
  • 移行方法/移行手順の検討
  • テスト観点の洗い出し

対象となるコンピューティング環境の調査

今回移行対象となるAWS Batchのコンピューティング環境はマネジメントコンソールから確認できますが、CLIコマンドで一覧出力しておくと見落としも無くて良いと思います。

computeResources.ec2ConfigurationimageTypeECS_AL1となっているものが今回サポート切れになるコンピューティング環境になります。

aws batch describe-compute-environments --query 'computeEnvironments[?computeResources.ec2Configuration[0].imageType==`ECS_AL1`]'

移行方法/移行手順の検討

移行の方法ですが、computeResources.ec2ConfigurationimageTypeを直接編集できなかったので、既存コンピューティング環境のJSON定義から新たにコンピューティング環境を構築して、後から差し替える方式にしました。

コンピューティング環境のJSON定義は上記コマンド(aws batch describe-compute-environments)で確認できます。

JSON定義からのコンピューティング環境の構築はCLIコマンドで行います。

aws batch create-compute-environment --compute-environment-name 'コンピューティング環境の名前' --type MANAGED --cli-input-json file://xxxxx.json

ここで注意しないといけないことが1つ。
CLIコマンドでコンピューティング環境を構築するには、読み込むJSONに加工が必要です。

以下の項目を削除しましょう。(消しておかないと構築に失敗します)

  • computeEnvironmentArn
  • ecsClusterArn
  • status
  • statusReason
  • uuid

上記項目を削除したサンプルを記載します。

{
  "computeEnvironmentName": "newComputeAL2",
  "tags": {},
  "type": "MANAGED",
  "state": "ENABLED",
  "computeResources": {
    "type": "EC2",
    "allocationStrategy": "BEST_FIT_PROGRESSIVE",
    "minvCpus": 0,
    "maxvCpus": 256,
    "desiredvCpus": 0,
    "instanceTypes": [
      "c5"
    ],
    "subnets": [
      "subnet-xxxxxxxx"
    ],
    "securityGroupIds": [
      "sg-xxxxxxxx"
    ],
    "ec2KeyPair": "dummy",
    "instanceRole": "arn:aws:iam::xxxxxxxxxxxx:instance-profile/xxxxxInstanceRole",
    "tags": {},
    "ec2Configuration": [
      {
        "imageType": "ECS_AL2"
      }
    ]
  },
  "serviceRole": "arn:aws:iam::xxxxxxxxxxxx:role/xxxxxServiceRole"
}

テスト観点の洗い出し

移行におけるテストですが、以下観点での検証が必要かなと考えました。

コンピューティング環境の変更による影響

  • 設定したロール(サービスロール、インスタンスロール)に不備がないか
  • EC2を起動させるVPCサブネットやセキュリティグループの指定は適切か

プラットフォームの変更による影響

  • AmazonLinux2 AMIで起動したEC2内のミドルウェアがコンテナの起動/実行に影響してないか(主にDocker

なんですが、プラットフォームの変更による影響 に関する検証は今回は省きました。

というのは、弊社が使用しているコンピューティング環境のEC2設定はAmazonLinux2 AMIを紐付けた 起動テンプレート で指定しているため、実際のワークロードではAmazonLinuxではなくAmazonLinux2のEC2が起動しています。

今回新しく構築するコンピューティング環境でも同様の起動テンプレートを使用するため、AmazonLinux AMIAmazonLinux2 AMIによる影響箇所の検証は省いてもいいのではと判断しました。

AWSからアナウンスのあったAWS Batchで使用不可になるコンピューティング環境はcomputeResources.ec2ConfigurationimageTypeを見て判定しているようでした。

移行作業完了!

デモ環境で移行手順をもとに移行検証を行い、本番環境での移行も無事完了。
今回は、AWS BatchでのワークロードをAmazonLinux2 AMIの起動テンプレートで運用していたため、EOL対応にあまり手を焼かずに済みました。

今回の投稿が誰かにとって有意義なものになってくれれば幸いです。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です