こんにちは。Tomoyuki（@tomoyuki65）です。
バックエンドエンジニアとして極めていくにあたり、アプリケーション周りだけでなく、インフラ周りの知識を身につけていくのも大事になります。
特に近年では生成AIの普及により、コードはAIが書いてくれるようになったため、身につけるべきスキルの重要度的にもアーキテクチャ周り（設計部分）の比重が高くなってきています。
ということでこの記事では、Webサービスにおけるクラウドの基本インフラ構成図パターンについてご紹介します。
Webサービスにおけるクラウドの基本インフラ構成図パターン【Google Cloud/AWS】
Webサービスにおけるクラウドを利用した基本的なインフラ構成の種類としては以下のようなものがあります。
作るものや資本（開発資金や人材など）、そしてサービスリリース後の運用コストなども考慮しながら、適切なインフラ構成を決めましょう。
・JAMstack（JavaScript・API・Markup）のインフラ構成
・動的サイトのインフラ構成
・非同期処理のインフラ構成
・マイクロサービスのインフラ構成
・リアルタイム処理が必要なインフラ構成
モノリスアプリケーションのインフラ構成
開発コストやリソースが少なく、開発スピードを重視するスタートアップ企業などでは、Ruby on Rails（Ruby）、Laravel（PHP）、Django（Python）といった一つのフルスタックフレームワークでモノリスアプリケーションを開発することが多いです。
一つのフレームワークだけでアプリケーションを作れるメリットがありますが、サービスが成長した際にはパフォーマンス面などでボトルネックがでるため、将来的にリプレイス等が必要になる可能性があります。
Google Cloudの場合
インフラがGoogle Cloudの場合は、Dockerコンテナを利用するCloud Runを主軸に使って構築することになります。
※CI/CDでセキュリティ重視ならCloud BuildやCloud Deployを使うこともできます。フロントエンド部分でキャッシュが必要ならCloud CDNも使えます。
AWSの場合
インフラがAWSの場合は、Dockerコンテナを利用するフルマネージドサービスとしてはApp Runnerを利用すると比較的楽に構築できます。（より細かい制御や柔軟な構成が必要なら後述のECSを利用する。）
※CI/CDでセキュリティ重視ならCodeBuildやCodePipelineを使うこともできます。App Runnerにはロードバランサーも含まれています。フロントエンド部分でキャッシュが必要ならCloudFrontを利用しますが、不要ならWAFをApp Runnerに設定することも可能です。
JAMstack（JavaScript・API・Markup）のインフラ構成
React.jsなどを使ったリッチなフロントエンド画面が必要な場合は、フロントエンドとバックエンドを分けて開発しますが、その際にフロントエンドが静的サイトのみで構築できるものをJAMstack（JavaScript・API・Markup）と呼びます。
この場合はフロントエンドの静的ファイルをストレージサービスに保存し、CDN（Content Delivery Network）サービスでキャッシュして配信できるため、フロントエンド部分を低コストで運用できるのが特徴です。
ただし、フロントエンドとバックエンドが分かれるため、バックエンド側にはJWT認証などの何らかの認証機能が必須になります。
Google Cloudの場合
インフラがGoogle Cloudの場合は、フロントエンドの静的ファイルをCloud Storageに保存し、それをCloud CDNで配信します。
バックエンド部分はモノリスアプリと同様にCloud Runを利用しますが、認証部分にAPI Gatewayを使うこともあります。（API毎にミドルウェアで認証機能を付けるか、認証部分をAPI Gatewayに寄せて共通化する）
※バックエンド部分にはセキュリティ対策としてWAF（Web Application Firewall）が必須ですが、フロントエンド部分が静的サイトの場合はWAFは任意（必要なら付ける）です。
AWSの場合
インフラがAWSの場合は、フロントエンドの静的ファイルをS3に保存し、それをCloudFrontで配信します。
※バックエンド部分にはセキュリティ対策としてWAF（Web Application Firewall）が必須ですが、フロントエンド部分が静的サイトの場合はWAFは任意（必要なら付ける）です。
動的サイトのインフラ構成
Next.jsやRemixといったReact系フレームワークを利用すると、フロントエンドを動的サイト（内容がリアルタイムに変化・生成されるWebサイト）として構築できます。
例えばECサイトなどで表示している商品のSEO対策（Googleなどの検索からアクセスを増やす施策）をしたい場合はSSR（リクエストに応じてサーバー側でJavaScriptを実行してHTMLを生成）が必要なため、その場合は動的サイトである必要があります。
Google Cloudの場合
インフラがGoogle Cloudの場合は、モノリスアプリと同様にCloud Runを利用して構築しますが、一部が静的サイトになっているハイブリット構成もあり、その場合はJAMstackのフロントエンドと同様にCloud StorageとCloud CDNも使います。
※動的サイトならWAFは必須です。
AWSの場合
インフラがAWSの場合は、モノリスアプリと同様にApp Runnerを利用して構築できますが（より細かい制御や柔軟な構成が必要なら後述のECSを利用する。）、一部が静的サイトになっているハイブリット構成もあり、その場合はJAMstackのフロントエンドと同様にS3とCloudFrontも使います。
※動的サイトならWAFは必須です。
非同期処理のインフラ構成
何らかのイベントなどを検知し、それをトリガーに非同期処理を実行させたい場合、Pub/Sub（メッセージの送り手と受け手を分離して通信）サービスを利用して構築します。
Google Cloudの場合
インフラがGoogle Cloudの場合は、Pub/SubサービスとしてはCloud Pub/Subを利用します。
そして、後続の処理部分については、処理内容に応じてCloud Run Functions、Cloud Run、GKE（Google Kubernetes Engine）を使い分ける必要があります。
特に常時起動が必要な処理や、重い処理などはGKEでAPIを構築する必要があります。
※非同期処理でエラーが発生した場合、リトライ処理が必要になり、かつそのリトライ処理で結果が変化しないような作り（正常終了したら必ず同じ結果になる）になっていることが大事です。
AWSの場合
インフラがAWSの場合は、非同期処理における最小構成としてはSQSを利用し、軽い処理であればLambdaを連携させて構築します。
ただし、常時起動が必要な重い処理等をさせたい場合は、SQSをポーリングするような形でECS（フルマネージド型のコンテナオーケストレーションサービス）を構築する必要があります。
※イベント駆動アプリケーションにしたい場合はSQSの前にEventBridgeを置いたり、1対nの処理をさせたい場合はSQSの前にSNSを置いたりします。
マイクロサービスのインフラ構成
バックエンド側が新規機能追加によって複雑になった場合や、利用者数の増加やトラフィック増加によって一部のAPIにパフォーマンスの影響がでるようになった際は、APIを分割してマイクロサービス化が必要になります。
ただし、マイクロサービス化ではドメイン毎に独立したAPIに分割（DBも分割）が必要になり、それはそれで管理コストなども増加するので注意しましょう。
Google Cloudの場合
インフラがGoogle Cloudの場合は、APIの分割数が5個ぐらいまでであれば、Cloud Runを使って分割すればいい（DBは必要に応じて分割有無を決める）ですが、それ以上に分割が必要になったりする場合はGKEの利用を検討する必要があります。
また、ちゃんとしたマイクロサービスとして分割する際にはそれぞれのAPIを独立させるため、非同期処理にする場合はCloud Pub/Subを利用して構築します。
AWSの場合
インフラがAWSの場合、まずはECSを利用してマイクロサービス化を行えます。
※ECSを利用する場合は、CI/CDでCodeDeployを使うこともできます。
そしてより大規模になる際は、Kubernetes（k8s）のサービスであるEKS（Elastic Kubernetes Service）を利用してマイクロサービス化を行えます。
※EKSを使うかどうかの判断については、マイクロサービスの数が10を超えてくる場合や、開発チーム数が多くなってきた場合、Kubernetesのエコシステムを使いたい場合、ベンダーロックを防ぎたい場合（Google Cloudなどに移しやすい）などに検討し始めましょう。
リアルタイム処理が必要なインフラ構成
チャット系アプリなどでリアルタイム処理が必要な場合は、WebSocketサーバーを常時起動させる必要があったり、リアルタイム更新に強いNoSQLなどのDBが必要になります。
Google Cloudの場合
インフラがGoogle Cloudの場合は、常時起動が必要なWebSocketサーバーはGKEを利用し、リアルタイム更新が必要なメッセージの保存にはNoSQLであるCloud Firestoreを利用すると構築できます。
ただし、コスト面を考慮してWebSocketサーバーをGCE（Google Compute Engine）で構築したり、より大規模なら別のDBを利用する必要がある可能性もあったりするのでその点は注意しましょう。
AWSの場合
インフラがAWSの場合は、常時起動が必要なWebSocketサーバーはECSやEKSで構築（または条件次第でEC2を利用）し、リアルタイム更新が必要なメッセージの保存にはNoSQLであるDynamoDBを利用します。
また、過去メッセージの検索や分析にはOpenSearch（ElasticsearchからフォークしたOSS）を利用したりします。
その他のシステムやアプリの監視・分析サービスの導入について
その他、例えばドメイン単位のより詳しいメトリクス情報を取得したい場合などは、無料のOSSならOpenTelemetry、有料サービスならDatadogやNew Relicなどを導入したりします。
特にマルチクラウド環境（Google Cloud + AWSなど）の場合は、Datadogを導入することで統合ダッシュボードによる分析が可能（相性がいい）です。
また、エラー監視や例外追跡に特化したサービスにSentryがあり、これを導入することでJAMstackのフロントエンドも含めてエラー監視が可能です。
関連記事
最後に
今回はWebサービスにおけるクラウドの基本的なインフラ構成図のパターンについてご紹介しました。
作るものや資本（開発資金や人材など）、そしてサービスリリース後の運用コストなども考慮してインフラ構成を決める必要があります。
まずは基本的なパターンを覚えておくとよいので、よければぜひ参考にしてみて下さい。
コメント