はじめに
今回初めて記事を投稿するにあたり、インプットした内容をアウトプットして学習した内容が理解できているか関連性があるかを確認するために記載しております。
この記事の目的
今回はAWS初学者向けに基本的なソリューションアーキテクチャとCI/CD周りをAWSというサービスを用いながら説明していき、より理解を高めていこうというのが狙いです。
自分と同じようにAWSを触りながら学習してみたい方、AWSを使用したサービスを考えている方は参考にしていただけると幸いです。
AWSを用いたインフラ構築
AWSでは数多くのサービスを提供しています。最近では生成AIやLLMの急速な人気によりクラウドサービスの需要も年々増加しています。そのため、AWSは今でも国内で最もシェアされているクラウドサービスとなっております。AWSを使用することでエンジニアとしてのキャリアアップも期待でき、今後も引き続きホットなテクノロジーとなり、急速な進化が期待できるため、早いうちにクラウドへの理解を深めておくことは自分自身のポテンシャルを底上げする大きなポイントとなってくると感じています。
そこで今回例題として、一般的なWebアプリケーションのインフラをAWSを用いて構築していき、皆さんの理解に貢献していければと思います。まず以下に図を示した上でそれぞれのサービスの特徴やベストプラクティス等を説明する形で進めていきます。
今回のアーキテクチャ例
今回はクライアント側がWebアプリにアクセスし記事の投稿や閲覧など基本的な動作ができるものを参考に作成しております。
まず初めにRoute53を使用してドメイン名を取得した後、CloudFrontを用いて様々なAWSサービスと連携するような構造になっていることがわかります。ここにRoute53を用いる目的はドメイン名の登録と管理ができるサービスであり、トリフィックウェイト(weights)や地理位置情報(Geolocation)などのルーティングポリシィ(Routing Policy)を決めることができ、要件や仕様によりカスタムしやすいサービスとなっています。ここでさらにCloudFrontを用いることでより高速なアクセスを期待することができ、Route53とCloudFrontのコンビは相性が良いと言えます。またCloudFrontの特徴として一度アクセスしたものはEdge Locationの中にキャッシュとして一時的にアクセス可能となっているため、わざわざサーバを介すことなく、クライアントのリクエストに返すことができます。Amazon S3やAWS Lambda、この後にも紹介するALBやECSに使用されCDN(Content Delivery Network)として使用されています。今回ここで使用されているAWS LambdaはOGP表示で使用されるもので、CloudFrontとの連携ではLambda@Edgeを使用することが推奨されており必然的に'us-east-1'のN. Virginiaリージョンでのみ使用が可能となっています。そのため図のように記載してあります。
続いて、中身の方について説明していきます！
今回は'ap-northeast-1'と呼ばれる東京リージョンの中にVPCを設けて、disaster recoveryのために2つのアベイラビリティゾーン(AZ)を用意しています。このどちらのprivate subnetにリレーショナルデータベース(RDS)を用意することで、今稼働中のプライマリーAZに何らかの障害が起きた際には別のAZに同期していたRDSを用意しておくことで、データ損失を防ぐことができ、可用性のあるインフラを構築することができます。
今回のアーキテクチャではApplication Load Balancer(ALB)を用いてHTTP/HTTPSによるアクセスを可能にしています。ALBでは複数のターゲットグループを決めることができます。制約としてターゲットグループにはEC2、ECS, AWS Lambda、IPアドレスとなっています。加えてトラフィックのため静的なドメイン名を提供する必要があるため、Route53、CloudFront、ALBは基本的なWebアプリケーションにおけるネットワーク構築をする上で必要最低限であることがわかります。
ここでECSから別のトラフィックを確認することができると思います。ECS自体がコンテナのサービスであるため、Docker Imageが保存されているAmazon ECRとのトラフィックを結ぶ必要があります。しかしながらセキュリティ上の観点により、ECSがprivate subnetに位置しているため、private subnetからインターネットへのアクセスを可能にする必要があります。そこで今回使用するのが、Internet GatewayとNAT Gatewayです。Internet Gateway自体はインターネットとのアクセスを可能にする役割を持ち、インバウンドとアウトバウンド両方のトラフィックを受け入れてくれます。そのためVPC上に位置しています。これだけではprivate subnetとのやりとりができないため、NAT Gatewayと呼ばれる、public subnetで使用されるサービスを用います。これはアウトバウンドのトラフィックのみを受け入れています。そのため、private subnetにあるECSがインターネットに位置するAmazon ECRへアクセスすることができ、セキュアなインフラを構築することができます。Internet GatewayとNAT Gatewayの間にVPC-Routerを使用しており、disaster recovery時にも対応することができます。
以上で今回の例に関する説明と基本的なベストプラクティスに基づくソリューションアーキテクトとなってるので、それぞれのサービスや機能を理解したい方は、それぞれのリンクに飛んでいただけるとより理解しやすいものになると感じています。
CI/CD構築
上記のインフラ整備に加えてCI/CDの部分も押さえておこうと思います。今回の例を用いて以下に図式しておきます。
上記はデプロイ完了後の様子を表しています。大まかな構造としては、GitHubをレポジトリとして使用し、BuildとしてGitHub Actionsを使用する特徴になっています。Buildに成功した後AWS CodeDeployで更新されたECS Taskを元にBlue/Greenによるtarget groupの更新を行なっています。これにより、新しく更新したものをリリースすることができ、CI/CDを担うことができています。
ここでBlue/Greenとは古いバージョンから新しいターゲットグループにトラフィックを変更し、デプロイ完了時には完全に新しいバージョンを使用することができるようになっています。デプロイに失敗した際には元の古いバージョンにトラフィックに対してロールバックしてくれるため、問題なく開発を進めることができます。ここでこのトラフィックを実現するにあたりALBは必要不可欠なので、実際に仕様を決める際にはターゲットグループを決め、ECS taskの中にも記載することを忘れないようにしてください。このほかにもIn-placeなどがありますがこれは今動いているサーバーに対して直接アップーデートを行うものなのでダウンタイムが生じますがBlue/Greenと異なり、別途サーバーを用意することがないため、コスト面で優れているという特徴があります。
ここでAWSではCI/CD構築時に使用できるAWS CodePipelineやGitHub Repositoryの代わりにAWS CodeCommitを使用したり、AWS CodeBuildというテスト時に使用されるサービスなどこれ以外にもAWS CodeArtifactなど様々なサービスが提供されているので仕様によって目的に合ったカスタマイズを変更することが可能になっています。
さいごに
これ以外にもサーバーレスによる構築やbuild時失敗の通知などより便利で使いやすいインフラを整備することも可能なので、まだまだ奥が深いと感じました。自分は以下のコースを参考に学んでAWS Certified Developer - Associateと呼ばれる資格に挑戦し、合格することができたので初めにサービスを理解したいという方は勉強してみるのも良いのかもしれません。より専門的でサービスも限定されている方は、ハンズオン形式で学んでいきわからない箇所はリファレンスを読むなどして対策する手が良いかと思います。