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

こんにちは投資ロウトです。

背景

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

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

https://zenn.dev/doshirote/articles/577d8bb31a152b

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

ロードバランサーの作成

①cloudformationでテンプレートを作成
②ACM証明書のリクエストを投げる
→ACM証明書に_CNAME名が確認できる※ALBと同じリージョンで証明書を発行する必要がある
③②で出てきたCNAME名を元に、Route53の対象のドメインの箇所から、CNAMEレコードを作成すると、ACM証明書が発行が少しの時間で、完了となる。
④③を行うことで、ACM証明書から、IDが取得できるようになるので、cloudformation経由で、ALBが作成できるようになるので、作成を行う。
※ACMの中身にて、ARNから始まるものを利用すること。
⑤④を行うことでA(エイリアス)レコードでレコードを作成し、作成したALBを指定する

ロードバランサーでの失敗

問題1

Resource handler returned message: "At least two subnets in two different Availability Zones must be specified (Service: ElasticLoadBalancingV2, Status Code: 400, Request ID: aaaa)" (RequestToken: xxxx1080-zzz-5yyye, HandlerErrorCode: InvalidRequest)

解決方法1

ロードバランサーには2つの異なるアベイラビリティーゾーンの2つの異なるサブネットを渡す必要があることを意味しているようです。

そもそもALBに2つの異なるアベイラビリティーゾーンの2つの異なるサブネットでないと作成できないという制約があると知りませんでした。

ということで、そもそもパブリックサブネットを2つ用意する頭がなかったので、一から作り直していきたいと思います。ただcloudformationがあるので、何度も作り直しする作業が楽になるのは、かなりチャレンジしてみてよかったなと思っております。

また補足ですが、このALBの仕様は、EC2は1台でもいいとのことでした。そもそもテスト環境なので、費用をなるべく抑えたいという思いがあったのですが、EC2が一台のみでいいのであれば、ALBはテスト環境でも設置しておいた方が後々楽になるかなとも思っております。

またpublicサブネットとアベイラビリティーゾーンがあるからといって、ALBが2つあるというわけではないので、注意になります。

誤認識していたこと

Elastic BeanstalkはEC2インスタンス上でコンテナを動作させることが想定されているため、自分の構成図の文言が誤っているということがわかりました。

正しくはElastic Beanstalkではなく、ECSの表記がでFargateを動かす上で正しいとのことです。

新たに理解したこと

ECSはコンテナを実行や管理をするためのもので、ECRはDockerイメージ等を格納する保存先とのこと。

新たに知ったこと

ACM証明書を発行するときに、＊.xxx.comなどのようにワイルドカードで発行ができるとのこと。
→そうすると何が嬉しいかというと、a.xxx.comでもb.xxx.comでもACM証明書の追加申請をしなくても、使用できるようになる。

注意点：「a.b」などのように追加でドットが入るのは、不可能。
またルールとして、、「※.※」という申請はできないということ。
(アスタリスクは消える文字なので※にしていますが、正しくはアスタリスクです)
また仮に複数ACM申請していたとしても、料金は無料なので他の証明書を消す心配も必要もありません。

新たに知ったこと

最近のシステム構成ではhttp(80)のポートを敢えて開けないというセキュリティー構成をしているところもあるとのことでした。

推奨構成のお話

2つの異なるアベイラビリティーゾーンの2つの異なるサブネットというトピックが出てきました、Natゲートウェイは各アベイラビリティーゾーン毎に作成する必要があるのか？というのは、AWS推奨は、各アベイラビリティーゾーン毎に作成するのがいいとのことです。

理由はアベイラビリティーゾーンで障害が起きてしまったときに、システムが動かせなくなるからというのがありました。

将来に向けての勉強トピック

Fargateで最終的に本番の構築を検討しております。いくつか勉強資料を連携頂いたので、まだ先になりますが、予習していきます。

・ECSをどの起動タイプで行うかについて

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/launch_types.html

・ECSにロードバランサーで分散する

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-load-balancing.html

・ECSサービスについて

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs_services.html

・流石に全部は見切れないですが、ECSのパラメータについてです。

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service_definition_parameters.html

・またFargateには、CloudWatchで監視する機能がついているとのことで、わざわざ監視を追加しなくても、良さそうでした。

[5] Amazon ECS CloudWatch メトリクス
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/available-metrics.html

[6] Amazon ECS Container Insights メトリクス
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html

繰り返し出るが、cloudformationのかんぺ

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html