ROBOT PAYMENT Engineers Blog

株式会社ROBOT PAYMENTのテックブログです

AWS App Runnerを使って簡単にデプロイできました

こんにちは。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.com

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ヶ月ほどかかった結果になりましたが、製品版に向けて非機能要件を今後対応していく予定なので、またブログネタになりそうなことがあれば書いていきます!