アーキテクチャ比較:コンテナ化したREST APIを認証付きで公開[AWS,GCP,Azure]

この記事の内容

「コンテナ」には、場所を選ばずにどこでも同じようにアプリを動作させられるというメリットがあります。ですので、自分で開発したアプリをコンテナ化すれば、AWSでもGCPでもAzureでも同じように動くはずです。
今回はAWSとGCPとAzureそれぞれのサービスを使ってREST APIのコンテナを公開するアーキテクチャを、一例づつ紹介して比較します。

デプロイするAPIの要件

それぞれのクラウド毎に用意されているサービスや機能が違いますので、全ての条件を一致させるのは難しいです。一方で「VM上でdocker compose upしましょう」とかの何の比較にもならない記事を書いても意味がないので、下記の要件を満たすことを前提にします。

• Rest APIのコンテナを公開する
• DBはPostgreSQLとする
• DBはAPI以外からのアクセスを遮断する
• APIは認証されたユーザーのみがアクセス可能とする。ただしコンテナ内に認証処理は持たせずに、各クラウドのサービスを活用してコンテナの外で認証をかける
• ソースコードはGithubで管理し、CD(継続的デリバリー)を構築する
• EC2,GCE,VMは使わない

「最低限使えるレベルのセキュリティをつけて、なるべくマネージドサービスを活用してAPIをデプロイするぜ」って感じです。

AWSの場合

構成図(AWS)

使用した主なサービス(AWS)

• コンテナの実行
  • Amazon ECS (AWS Fargate)
• APIの公開
  • Amazon API Gateway
• 認証
  • Amazon Cognito
• データベース
  • Amazon RDS
• CD(継続的デリバリー)
  • AWS CodePipeline
• その他
  • AWS Amplify

コメント(AWS)

• Amplifyを使えばDB以外のほぼ全てを構築することが出来るので、Amplifyと仲良くできればかなり楽。
• DBは自力で作る必要があるので、そこは頑張るしかない。
• ECS(というかFargate)とRDSを同じVPC内に置けば、DB周りのセキュリティ設定は楽にできる
• ユーザーの認証周りの設定はAmplifyがやってくれる
  • Cognitoで認証したユーザーのみがAPI Gatewayを通れる仕組みになる
• CDもDockerfileやdocker-compose.yamlを書けば、あとはAmplifyにおまかせで構築してくれる

という感じで、AWSの場合はAmplifyを使いこなせれば楽に構築できると思います。ただし、Amplifyを使える程度のスキルは必要ですし、Amplifyでは対応出来ない要件が出てきた場合に全部個別に作ろうとすると結構苦労すると思います。あと、AWSはサービスが多すぎるので、そもそもどのサービスを使えばいいのかの判断が難しいのが結構ツライです。

GCPの場合

構成図(GCP)

使用した主なサービス(GCP)

• コンテナの実行
  • Cloud Run
• APIの公開
  • API Gateway
• 認証
  • Firebase Authentication
• データベース
  • Cloud SQL
• CD(継続的デリバリー)
  • Cloud Build

コメント(GCP)

• 見比べてもらうと分かりますが、GCPはAWSとかなり似た構成で作れます。
• AWSと違ってコンテナが実行されるCloud RunがVPCの外にあります。このためCloud RunからVPC内のCloud SQLに安全に接続するためにVPCアクセスコネクターを使っています。
• 認証はFirebaseです。一応GCPとは別サービス扱いにはなりますが、GCP側と同名でプロジェクトを作れば勝手に連携してくれるので、特に複雑な設定はありません。
• API Gatewayの定義をFirebase認証やCloud Runへの接続情報含めてSwaggerで記載する必要があります。Swaggerに慣れていないと、これが結構大変だと思います。
• CDはCloud Run構築時にDockerfileさえ指定すれば一通り構築してくれるので、特に苦労はないです。

全体像が描けていれば、構築はしやすいと思います。ですが、AWSのAmplifyと違って全部まとめては作れないので、構成が頭に入っていないと構築中に混乱するかも。あと、API GatewayのSwaggerをどう見るかで難易度が変わりそうです。慣れてないと間違いなく苦戦するポイントになります。

Azureの場合

構成図(Azure)

使用した主なサービス(Azure)

• コンテナの実行
  • Azure Web Apps　(Webアプリ)
• APIの公開
  • Azure Web Apps　(Webアプリ)
• 認証
  • Azure AD
• データベース
  • Azure Database for PostgreSQL
• CD(継続的デリバリー)
  • GitHub Actions
  • ACR

コメント(Azure)

• 大枠の構成はAWSやGCPと大きな差はありませんが、細かくみると結構な違いがあります。
• AWSやGCPのAPI Gatewayに相当するサービスを使っていません。理由としては、、、
  • ポジティブな理由 : Azure Web Appsで、Azure ADを使った認証を付けられるのでなくても要件を満たせる
  • ネガティブな理由 : API Gatewayに相当するAPI Managementは、お値段がちょっとアレなので個人的には積極的に使いたくない
• コンテナが動くWebAppsとデータベースの両方が、VNetの外にあります。直接繋ごうとするとDBに対するセキュリティが悲惨なことになるので、課金をしてVNet経由で接続させます。
• CDはGitHub Actionsでビルドしてコンテナ化してACRにプッシュするのが無難です。ACRからはWebhookを設定してWebAppsに自動Deployさせましょう。
  • AWSやGCPみたいに全部自動でいい感じに構築はしてくれないので自力で頑張りましょう。

AWSやGCPと結構違うので、他のクラウドに慣れていると苦戦します。Azureからその他も同様。悪く言えば閉鎖的な環境です。特にVNetを素通りさせる構成にしないとセキュリティが確保出来ないのは普通は分からないだろと言いたいですが、慣れていないだけと言われるとそうなのかもしれないです。ドキュメント読めば普通に書いてあります。

個人的な感想(全体)

• コンテナはどこででも動くので、特定のサービスに依存しない作りにしておけば、今回のようにAWSにもGCPにもAzureにも全く同じコンテナをデプロイ出来るので便利です。
• どのクラウドでも似たような構成には出来ますが、結局使うサービスは全部違うし構築方法もそれぞれ違うので「どのクラウドでもいいや」にはならないです。作りたいシステムにあったクラウドや学習コストが低いクラウドや開発者のモチベーションが上がるクラウドを選ぶのが良いと思います。
  • と言いつつ、AWSとGCPが思った以上に似た構成になったのは驚いた。
  • (Azureは、、、まぁ、、、頑張るしか無い）
• 開発者としてとっつきやすさでいうとGCPが分かりやすく、世の中の情報やエンジニアの数も含めて開発や運用のしやすさだとAWSが使いやすいように感じます。Azureは利用者が増えているというデータがあるにも関わらず世の中に情報が少なすぎることも含めて鎖国している感が強いです。

最後に

今回紹介した構成はあくまで一例です。各クラウドそれぞれに、もっとよい構成があるかもしれません。また、要件が変わってくれば当然ベストな構成も変わってきますし、コンテナにこだわる必要も無いと思います。
とはいえ、クラウドのサービスなんて多すぎて全部覚えられないですし、毎回イチから構成を考えるのは労力もかかるので、とりあえずこの構成で作ればAPIを公開できるぞ程度の参考になればと思います。