🙆

テスト環境を構築検討していく⑥【ロードバランサー作成の続き】

2024/06/02に公開

AWS

loadbalancer

tech

背景

ある程度NestJSでAPIの作成も進んできたので、Postmanによる単体テストではなく、アプリからのAPI呼び出しで動作を確認していきたいという思いも進めていくと出てくると思います。

ただなるべくコストを抑えていきたいため、本番環境よりもコストを抑えた類似環境でテスト環境を構築していきます。
※ECSなどはリソースだけで費用がかかるので、EC2などのインスタンスを止めながら開発コストを抑えたい。

そのため本番環境を簡易で構築し、テストを行う環境を整備していきます。

ロードバランサーの作成の続き

※作成方法は前回のページの方法変わらず

ロードバランサーの作成が完了しました。

またAレコードも忘れずに設定。

ロードバランサー作成時のエラー

問題1

Resource handler returned message: "Instance ID 'IPアドレス' is not valid (Service: ElasticLoadBalancingV2, Status Code: 400, Request ID: xxxxxea9-yyyy-zzzz-aaaa-bbbbb35e60dd)" (RequestToken: abcdecf7-hijk-yyyy-zzzz-aaaabbbb57dd, HandlerErrorCode: GeneralServiceException)

解決方法1

AWS::ElasticLoadBalancingV2::TargetGroupがインスタンスを指定している際は、インスタンスIDを設定する必要があった。

新たに知ったこと１

ECR・・・DockerイメージやOCIイメージを保管するサービス

ECSの構築の流れ・・・Dockerfile等をもとにDockerイメージを作成し、ECRへ保管、その後ECSタスクにてECRのイメージを使用するよう設定する

新たに知ったこと2

Aurora MySQLで一番安く構成するには小さなインスタンスクラスを選択すればいいとのことでした。

Aurora MySQL2(MySQL5.7)では、「db.t2.small」か「db.t3.small」を選ぶのがよく、
Aurora MySQL3(MySQL8.0)では、「db.t3.medium」か「db.t4g.medium」を選ぶのがいいとのことでした。

またそのスペック表は下記で確認できるとのことです。

新たに知ったこと3

Aurora MySQLでなるべくコストを抑えるために、使用しないときにAuroraクラスターを停止すれば、DBインスタンス自体の料金は発生しないのですが、連続7日間まで停止が可能で、それ以上止めている際は、自動で立ち上がる仕様になっているとのことです。
※以下、その解説資料

新たにわかったこと1

EC2やAurora MySQLを自動起動でまとめて起動させたいときは、AWS Lambdaを使えばいいとのことでした。またEC2インスタンスを起動したのちに、AWS Lambdaは15分まで実行待機ができるというお話もあったので、EC2インスタンスを起動後に、webサーバーの起動コマンドもAWS Lambdaで行ける可能性があることもわかってきました。

また補足ですが、AWS LambdaでEC2インスタンスを起動させる際に、AWS Lambdaの実行権限さえあれば、起動させるインスタンス(EC2やAurora)の起動等の権限がなかったとしても、実行が可能ということもわかってきました。

新たにわかったこと2

Auroraクラスターのストレージの容量は、データベースのデータ量が増えると自動的に増加すること。
そのため、Auroraクラスター作成時は、容量を記載する必要がなく、aws calculatorでは、使用する予定の容量をかけばいいことがわかってきました。

テスト環境構築に向けての学習

MySQL プロキシーについて

将来に向けての学習

・AWS Fargate での Linux コンテナの開始方法

別のECSで22のsshポートが空いており、なぜsshを開けるか気になっていましたが、そちらはECSでEC2を構築する場合の構成でした。そのため、Fargateではsshを開けることはないとのことです。

・Dockerイメージをローカルでビルドする方法

・Docker イメージを ECR にプッシュする方法