マルチアーキテクチャの Amazon EKS クラスターに Spring Boot アプリケーションをデプロイする

この記事は、Deploy a Spring Boot application on a multi-architecture Amazon EKS clusterを翻訳したものです。

本投稿は、Senior Cloud Technical Consultant の Andrew (Qingjie) Ren により寄稿されました。

はじめに

ARM ベースと AMD ベースのインスタンスの両方を使用して、マルチアーキテクチャの Amazon Elastic Kubernetes Service (Amazon EKS) クラスターにアプリケーションをデプロイすることを検討する理由は何でしょうか?

コストの最適化は、お客様にとって重要なビジネスの推進要因であることがよくあります。また、Well-Architected デザインの重要な柱でもあります。通常、コンピューティングリソースのコストを削減するには、いくつかの方法があります。例えば、Savings Plans、オンデマンドインスタンス、スポットインスタンスなどの購入オプションを組み合わせたり、コンピューティングリソースのサイズを適切に設定するなどの方法です。

AWS Graviton2 (ARM ベース) は様々なワークロードに対して、同等の現行世代の AMD ベースのインスタンスに比べて最大 40 ％のコストパフォーマンスを提供します。2019 年 12 月に Graviton2 インスタンスが最初に登場されて以来、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Relational Database Service (RDS)、Elasticache、AWS CodeBuild などの AWS サービスとの統合が増えており、Graviton2 も広く適用できるコスト削減策となっています。

ARM と AMD のハイブリッドデプロイでは、コスト削減のために Graviton2 インスタンスを活用すると同時に、AMD から ARM への移行を一斉に行うリスクを低減します。互換性がテストされているので、コードを変更することなく、既存のコードをマルチアーキテクチャの EKS クラスターにコンパイル、ビルド、デプロイすることができます。

この記事では、以下の方法を紹介します。

マルチアーキテクチャの ARM と AMD の EKS バックエンドを構築します。
Java Spring Boot アプリケーションコードを ARM 版と AMD 版の両方にコンパイルし、EKS バックエンドにデプロイする自動デプロイパイプラインを構築します。
AWS Cloud Development Kit (CDK) を使用して、AWS リソースのデプロイを自動化します。

このブログ記事で展開されているリソースをデフォルトの設定で稼働させた場合の 1 時間当たりのコストは 1 ドル以下です。完了したら必ずクリーンアップのステップを完了させてください。

ソリューションの概要

Spring Boot アプリケーションバックエンドの概要

エンドユーザーは、パブリックな Application Load Balancer (ALB) にリクエストを送ります。
ALB は、EKS クラスターにリクエストを送信します。EKS クラスターには 2 つのマネージド型ノードグループがあり、1 つは AMD インスタンス、もう 1 つは Graviton2 (ARM) インスタンスが配置されています。
リクエストは、Ingress リソースで定義されたルールに従い Spring Boot アプリケーションサービスにルーティングされます。Spring Boot アプリケーションサービスには、AMD と ARM の両方のノードで動作する Pod が含まれています。
Spring Boot の Pod は、Amazon Aurora、Amazon ElastiCache for Redis と通信し、レスポンスを生成します。

(訳注)
上記「ソリューションの概要」における箇条書き部分と図の、Kubernetes における Ingress の動作概念については、こちらをご参照ください。

デプロイパイプラインの概要

AWS CodeCommit にコードをコミットします。
コードのコミットによって AWS CodePipeline が起動し、ビルドフェーズが開始されます。ビルドフェーズでは、AWS CodeBuild 上で 2 つのタスクが並行して実行されます。1 つは AMD インスタンス上でソースコードをコンパイルし、AMD Docker イメージをビルドします。もう 1 つは Graviton2 インスタンス上で、ARM Docker イメージをビルドします。どちらもタスクの最後に Docker イメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュします。
ビルドフェーズの両方のタスクが成功すると、ビルド後のフェーズが起動されます。ビルド後のタスクは、ARM および AMD Docker イメージの上に、コンテナイメージの manifest を作成します。manifest エイリアスは、リクエスタ (要求者) のアーキテクチャに基づいて ARM または AMD のコンテナイメージイメージにルーティングされます。
ビルド後のタスクでは、manifest を ECR にコミットします。
さらにビルド後のタスクでは kubectl を実行し、Kubernetes の設定変更を適用して Spring Boot サービスイメージを新しく作成した manifest alias に更新します。
Spring Boot サービスが設定の変更を受けて、Pod は manifest alias を介して、ホスティングノードのアーキテクチャに一致するイメージをダウンロードします。

ソリューションの手順

前提条件

前提条件とインストールのガイダンスに従って、CDK をインストールします。CDK は、アプリケーションバックエンドとデプロイパイプラインスタックをデプロイするために使用されます。
Docker Hub にて Docker Hub アカウントとアクセストークンを作成します。このユーザー名とトークンは、コードのビルドフェーズで Docker Hub からイメージをプルするために使用されます。
インストール手順に従って kubectl をインストールします。kubectl は EKS クラスターとの通信に使用されます。

Step 1: Console で AWS Systems Manager Parameter Store を作成する

サービスから Systems Manager を検索します。
左のパネルにある パラメータストア をクリックします。
Docker Hub のユーザー名とアクセストークンを用意します。
パラメータの作成 をクリックして新しいパラメータを作成し、「名前」に /springboot-multiarch/dockerhub/username、「値」に Docker Hub のユーザー名を入力します。データを保護するために、「タイプ」は必ず SecureString を選択してください。

その他はデフォルトのまま、パラメータの作成 をクリックします。

Step 2: CDK を使って Spring Boot アプリケーションバックエンドとデプロイパイプラインの両方を AWS 上にデプロイする

# Checkout the code
git clone https://github.com/aws-samples/multiarch-eks-springboot-deployment-pipeline-with-cdk.git
# Prepare envcd multiarch-eks-springboot-deployment-pipeline-with-cdk/cdk
python3 -m venv .env
# Run cdk to deploy both springboot application backend and deployment pipeline# Please make sure CodeBuild ARM support(https://thinkwithwp.com/codebuild/pricing/) # is available in the chosen region # e.g. ./bootstrap.sh 12345678 us-east-1
./bootstrap.sh {AWS ACCOUNT ID} {REGION}
# Don't forget to note down the CDK outputs# i.e.# backend.EKSConfigCommandxxxx# pipeline.CodeCommitOutput

Step 3: パイプラインのトリガーとなるコードを CodeCommit にコミットする

# Checkout the new codecommit respository created by CDK in step 2
# i.e. value of pipeline.CodeCommitOutput
#   (make sure you are in the same filepath as in step 2 where you checkout the code)
#   e.g. #   ~/environment/multiarch-eks-springboot-deployment-pipeline-with-cdk/cdk (main) $ cd ../..
#   ~/environment $
git clone https://git-codecommit.{REGION}.amazonaws.com/v1/repos/springboot-multiarch test

# Copy source code to the new codecommit repositorycd test
cp -r ../multiarch-eks-springboot-deployment-pipeline-with-cdk/* .

# Commit source code to trigger deployment pipeline
git add *
git commit -m "trigger commit"
git push

Step 4: Application Load Balancer (ALB) のアドレスを取得し、確認する

# Config kubectl to connect to the EKS cluster created by CDK in step 2
# Check CDK output backend.EKSConfigCommandxxxx
# e.g. aws eks update-kubeconfig --name {EKS CLUSTER NAME} --region {REGION} --role-arn {EKS MASTER IAM ROLE}# get ALB address from kubernetes cluster
kubectl describe ingress | grep Address

期待される結果

1. 前のセクションの Step 4 で出力した ALB のアドレスにアクセスします。注：ALB が正常にプロビジョニングされるまで約 1 分待つ必要があります。

2. ブラウザに次のような出力が表示されることを確認します。

{"RDS Test":"passed","Node Name":"ip-10-xx-xxx-xx.ap-northeast-1.compute.internal","Redis Test":"passed"}

3. 何度かページを更新して、Node Name の切り替えを確認します。ノードは AMD と ARM (Graviton) が対応して動作しています。

クリーンアップ

環境を破棄するには、以下のコマンドを実行します。

cd cdk
./cleanup.sh {AWS ACCOUNT ID} {REGION}

まとめ

この記事では、マルチアーキテクチャの EKS クラスターを構築する方法と、既存の Java Spring Boot アプリケーションコードを EKS クラスターにデプロイするための自動デプロイパイプラインを作成する方法について説明しました。

このサンプルを使って、あなたの組織で Graviton2 インスタンスを活用し、コスト削減を始めてみてください。

Gravitonについて詳しく知りたい方は、こちらの製品ドキュメントをご覧ください。また、EKS についての詳細は、こちらの製品ドキュメントをご覧ください。

翻訳はソリューションアーキテクト杉本晋吾が担当しました。原文はこちらです。

Amazon Web Services ブログ