こんにちは。ROBOT PAYMENTでエンジニアをやっております 牧野です。 今回は、NestJS を使って最速リリースを目指している話 こちらの記事の続編としてAWS関係やCI/CD周りの記事を書いていこうと思います。
結論として、インフラ側のアーキテクチャは以下のような感じになりました。
AWS App Runner
まずコンテナを運用する要のAWSアーキテクチャとして、AWS App Runnerを利用しています。 docs.aws.amazon.com
簡単に説明すると ざっくり面倒なインフラ設定（ネットワーク、オートスケーリング、ロードバランシング、SSL、CI/CDなど）これらをまとめて(隠蔽して)提供しているサービスです。
メリット
- ECRへのコンテナイメージのpushをトリガーに自動デプロイ
- 個別にELBやAutoScalingを組み合わせた設定が不要
- ロググループの自動作成
この辺りは実際に利用してメリットが大きいと感じました。
今回はデータベースにRDSを利用しているため、VPCコネクタを利用してVPCリソースにアクセスできるようネットワーク周りの個別設定は若干必要でした。 ネットワーク周りの設定ができれば、コンテナ上で動くアプリケーションを簡単にデプロイできるので、いかに早くプロダクトリリースに持っていくというフェーズであれば最適な選択なのではと思っています。
デメリット
セキュリティグループのインバウンドルールが設定できない
「セキュリティグループに関しては、VPC Connector はアプリケーションからのアウトバウンド通信にのみ使用されることに注意することが重要です。従って、セキュリティグループのインバウンドルールは使用されず、事実上無視されます。」と記載があります。 aws.amazon.com
例えばステージング環境など、社外からアクセスする必要がない環境に対して社内IPのみアクセス可能にしたいなどの設定が現状できないです。
リクエストタイムアウト 30秒
30秒以上リクエストが継続していると、HTTP 503エラーが返却される現象が発生します。
repost.aws 現状1リクエスト30秒以内に抑えることが必須なため、処理時間の長い実装ができない状況です。
他にも現在できないことに対する機能リクエストやその対応状況についてGitHub上でロードマップが公開されております。
GitHub Actions
バックエンド環境のデプロイフローはGitHub Actionsで構成しています。
App Runner側でフローは整備されているので、ECRへのコンテナイメージのpushのみをパイプラインに定義しました。
Environment 機能を利用し、Environment単位で環境変数と Protection rule を組み合わせ、向き先を変更するだけで環境ごとにデプロイできるようにしています。Required reviewersを指定することで、本番環境のみRun workflowをapprove必須に設定することも可能です。
Run workflow手動実行時に環境を選択する
name: Manual Deploy Backend
on:
workflow_dispatch:
inputs:
environment:
description: Deploy target
required: true
type: environment
まとめ
今回はクラウド環境の設計やCI/CDについて主に記載しましたが、App Runnerを採用することでより簡単かつ迅速にデプロイ環境を整えることをできたのが一番のポイントに感じています。よりマネージドなAWSのサービスを選定することでSREチームに依存することなく、自チーム内で完結してリリースできる環境を整えることができました。 プロトタイプとしてのα版リリースは約4ヶ月ほどかかった結果になりましたが、製品版に向けて非機能要件を今後対応していく予定なので、またブログネタになりそうなことがあれば書いていきます！
We are hiring！！
ROBOT PAYMENTでは一緒に働く仲間を募集しています!!!
speakerdeck.com
www.robotpayment.co.jp
