OfferBoxの実行環境を概要図でまとめる

はじめに

はじめまして。SREチームの手崎です。

普段はi-plugで運用しているOfferBoxのインフラ面を中心とする開発・運用を行っています。

今回はOfferBoxのアーキテクチャについて概要図でまとめたいと思います。

細かな点まで書き始めるときりがないので今回は概要で、今後各項目ごとの詳細などを記載していきたいです。

OfferBoxのアプリケーションは全てAWS上で稼働しています。

概要図に表すと以下のような構成となります。

ネットワーキングとCDNは、Route 53、CloudFront、ALBを利用しています。また、WAFによる入口のセキュリティ対策も行っています。

アプリケーションはコンテナ化しており、ALB＋ECS＋RDSを中心とした一般的なWebアプリ構成です。スケーラビリティと柔軟性を維持して、開発者が素早く新機能をリリースできる環境を構築しています。

CIはGithub Actions、CDはGithub ActionsとCodeDeployを利用することで、開発からデプロイまでのプロセスを自動化しています。また、ECSへのデプロイはブルーグリーンデプロイメントを利用したロールバックしやすい構成です。

Datadog、Sentry、Cloudwatchを利用しています。各ツールの利点がそれぞれあり、なかなか一つにまとめることは難しいと感じています。これらのツールを組み合わせることで、アプリケーションのパフォーマンスと稼働状態をモニタリングしています。

バッチなどの非同期処理には、SQS、Lambda、EC2を利用しています。また、メール配信にはSESとEC2上のPostfixを利用しています。

上記以外にもAWS外と連携している機能は色々とありますが、これも多岐に渡るため別記事で書きたいと思います。

次にAWSのアカウント構成についてまとめます。

OfferBoxに関連するAWS環境は少し前にマルチアカウント構成へと変更しました。AWS Control TowerとAWS Organizationを使用して、アカウント管理を行っています。

以前は、検証環境も含めてすべてのリソースを単一のアカウントで管理していましたが、AWSをより効率的かつ柔軟に活用してくためにマルチアカウントへの移行を実施しました。

複数の環境を一元的に管理するためにTerraformでIaC化し、AWS Protonと組み合わせて運用しています。 AWS Protonによりブランチ単位に開発環境が起動される仕組みです。

また、各ビジネス部門が新しい施策を始める際に、Control Towerのポリシーが適用されたAWSアカウントを作成しています。これにより、AWS全体のセキュリティポリシーを維持しながら、工数をかけずに環境を提供しています。

各アカウントへの認証認可は全社で導入している別のIDPとAWS SSOを連携させた構成です。

今回はOfferBoxの実行環境についてAWSを中心にまとめました。できる限りAWSの提示するベストプラクティスに沿った構成とし、今後のサービス拡充や運用面の負荷とならないような構成を目指しています。

今後も継続的に改善を行っていきます🫡

以上