こんにちは、品質向上の木下です。
この記事では、複数あるサービスサイトのリグレッションテストにAutifyとApp Runnerを活用した事例を紹介したいと思います。
App Runnerを採用するにあたって
Autifyを用いた自動テストでの弊社の課題
弊社では、サービスサイトのリグレッションテストに、Autifyを利用しています。
また弊社は、20を超える企業と提携し、企業の数だけサービスサイトがあります。
ユーザーのアカウントの状態も、お知らせの未読・既読、入金の有無、積立設定の有無など、数多くあります。
すべての組み合わせのテストを実現するためには、企業×ユーザーで想定されるすべてのユーザーを予め用意しておく必要があります。
しかし、テスト内の操作でユーザーの状態が変わる場合もあるため、テスト実施時に、テストに必要なアカウントを取得する方法が望まれていました。
課題に対する解決案としてApp Runnerに着目
そこで、Autifyに必要なアカウントを取得するAPIを作成することとしました。
弊社では、AWS Fargateを積極採用していたため、当初はFargate上に用意することを考えていました。
しかしAWSが、以下の大きなアップデートをAWS App Runnerに対して行ったことにより、弊社のインフラ要件を満たすことができるようになり、App Runnerを弊社で初めて採用することとしました。
- 2022年2月8日：App Runnerが、VPCをサポート
- 2022年9月16日：App Runnerが、クロスリージョンのAmazon ECRイメージを使用したデプロイのサポート ((弊社では、ECRのイメージをテストを実施できるステージング環境と違う別の環境に保管しているため、クロスリージョンが必須要件でした))
- 2023年1月6日：App Runnerが、Secrets Managerをサポート
- 2023年2月24日：App Runnerが、WAFをサポート
App Runnerを構成するまで
デプロイ方法の選択
弊社では、普段利用しているAWS Fargate(AWS ECR)へのデプロイに、以下のサービスを利用してデプロイしています。
一方、App Runnerへのデプロイ方法は、以下の2種類イメージベースまたはコードベースが用意されています。
今回は、Fargateでも利用しているECRを採用することで、管理すべき場所が集約されるため、ECRを採用しました。
ECRに限定することにより、FargateやApp Runner、Amazon EKSなどの複数のコンテナオーケストレーションを使っている場合にも、シングルソースとして集約できます。
インフラの構築
App RunnerとCIへの設定
本番環境に似せて作られたデータが入っている、Amazon Auroraがある環境へのアクセスを制限するため、WAF、VPCそしてSecrets ManagerをApp Runner上に設定します。
App Runnerは、以下図(全体の一部)の通り、AWSのコンソール画面上から、イメージ、サービス名、CPUとメモリ、オートスケール、ヘルスチェック、セキュリティ(WAFなど)、ネットワーキング(VPCやセキュリティグループなど)を指定するだけで、サービスが構築されます。
App Runnerのサービス作成
Fargateと違い、設定すべき項目は少ないです。
またAmazon ECRへのイメージプッシュは、OpenID Connect(OIDC)を用いて、gitリポジトリのCIを実行して行いました。
CodeBuildやCodePipelineの用意も必要なく、手軽にCI環境を構築できます。
CIで解決できなかった問題
弊社では、運用上の観点から、App Runnerのデプロイトリガーを自動ではなく、手動としています。
手動設定の場合、デプロイモジュールの差し替えは、App Runnerが参照するコンテナイメージのURIを変更することで実現できます。
しかし現在のApp Runnerでは、クロスアカウント((今回のクロスアカウントとは、App Runnerを編集できるアカウントとAmazon ECRを管理できるアカウントが違う場合です))の状態で、App RunnerとAmazon ECRを操作することができません。
そのためイメージの差し替えは、AWSのApp RunnerのGUI上で、App Runnerが参照すべきイメージのハッシュを手動で変更して、デプロイしています。
今後App Runnerのアップデートで、クロスアカウントの状態でもApp RunnerとAmazon ECRを操作できるようになった際には、gitリポジトリのCIでAWSコマンドを利用して、自動デプロイを実現するつもりです。
ただ 弊社で利用しているCIの問題として、標準イメージに内蔵された AWS CLI のバージョンが 1 であるため、App Runnerを操作できません。
そこでCIを利用する際には、以下のスクリプトをもって AWS CLI のバージョンを 2 を改めてインストールし、App Runnerを操作することでイメージを差し替え、デプロイを行います。
# 1. AWS CLIの差し替え
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
./aws/install
aws --version
# 2. イメージをビルド
docker build -t "タグ名" .
# 3. イメージをプッシュ
docker push "タグ名"
# 4. App Runnerのイメージを差し替え
aws apprunner update-service --service-arn "<APP RunnerのARN名>" --source-configuration '{"ImageRepository":{"ImageRepositoryType":"ECR","ImageIdentifier":"<新しいイメージ名(タグ含む)>"}}'
インフラの最終構成
最終構成は、以下の通りとなりました。
App Runnerの構成図
APIの準備からAutifyのシナリオに組み込み
APIは、Autifyだけでなく、社内での検証や開発に役立てるよう公開し、開発者でなくともアカウントを探せるよう、Swaggerを導入して、利用者の操作敷居を下げました。
Swagger
そして本題のAutifyのシナリオの修正です。Autifyのシナリオのテストに、必要なアカウントを取得するjsスニペットをケースの冒頭に入れます。
※ 以下例です
Autify
これで自動テストを何度実施しても、テストに必要なアカウントを取得できるようになりました。
テスト実施前にアカウントを事前に用意するなどの調整の必要がなくなり、リグレッションテスト実施にかかる工数を削減できました。
さいごに
最初の構想からリリースまで、インフラメンバーとの調整含め、2週間で実現できました。
短期間に実現できたのも、App Runnerが従来のデプロイハードルの低さを維持したまま、日々進化し業務に必要な機能を備える改善を行っているためです。
ぜひApp Runnerを業務に利用してみてください。
📣ウェルスナビは一緒に働く仲間を募集しています📣
著者プロフィール
木下智弘(きのした ともひろ)
2015年10月にウェルスナビに、エンジニアとして入社。
プライベートでは、Google Cloudを好んで利用しています。
Goのシンプルな考えが好きです。
Discussion