構成図
システムの前提
Eコマースサイト
背景
- あなたはNyanmethod社のソリューションアーキテクトです
- Nyanmethod社は先日、自社の主力事業であるEコマースサイトの運営システム基盤をオンプレミスからAWSへ移行しました
- 現在、Eコマースサイトのシステム開発を行うチームは4名でAWS有識者はインフラ担当として1名います
- Eコマースサイトの移行プロジェクトに携わっていたインフラ担当者がプロジェクト終了後に退職したため、新しくAWS有識者を運用プロジェクトに配属することにしました
- アプリ改修ではなくインフラ改修で課題解決を進めたいと考えています
- あなたは、Nyanmethod社内のAWS有識者として本プロジェクトに配属されたため、これから出される課題に記載された観点について改善案を検討し、その改善案を反映した構成図を作図してください
既存構成の使用リソースや要件
ネットワーク
- VPCは東京リージョンで1つだけ作成されています
- サブネットは、ap-northeast-1aに2つ、ap-northeast-1cとap-northeast-1dに1つずつ、合計4つのパブリックサブネットがあります
- ECサイト利用者は、HTTPSで
example.com
のドメインでアクセスします
- VPC内部で通信が必要な場合は、内部通信の暗号化は不要です
EC2
Webアプリサーバー
- ap-northeast-1aとap-northeast-1cのAZに作成されたパブリックサブネットにそれぞれ1台ずつ配置されています
- 2台ともパブリックIPが付与されています
- それぞれインスタンスタイプは
m6i.xlarge
です
- 平常時はCPU使用率が30%大
- セッション管理をクリアにするバッチ処理が稼働している
- サーバ内には各コンテンツが格納されています
- 静的コンテンツはApacheを活用しEC2内のストレージを活用
- 動的コンテンツ
- DBのID、PWはサーバ内にて管理している
DBサーバー
- ap-northeast-1aのAZに作成されたパブリックサブネットに1台配置されています
- インスタンスタイプは
m6i.xlarge
です
- 平常時はCPU使用率が30%程度使用しています
- DBはPostgreSQLのエンジンで稼働しています
- DBのテーブルには、顧客の個人情報(PII)や商品情報などのテーブルがあります
- RDBはセッション管理にも使用しています
監視サーバー
- ap-northeast-1dのAZに作成されたパブリックサブネットに1台配置されています
- インスタンスタイプは
t2.micro
です
- システム監視を統合するOSSで稼働しています
- 主要な監視項目は以下です
- CPU使用率
- メモリ使用率
- 外形監視
- 死活監視
- エラーログの監視
Route 53
example.com
のドメイン名を持つパブリックホストゾーンがあります
- ELBのFQDNがターゲットのエイリアスレコードがあります
ELB
- Application Load Balancer(ALB)を使用しています
- Internet FacingのALBに設定し、2つのAvailability Zone (AZ) にまたがったパブリックサブネットに設定されています
- HTTPSをリッスンしており、ACMで管理している証明書を使用しています
ACM
example.com
のドメイン検証済みのパブリック証明書を管理しています
S3
- アプリケーションサーバで使用される業務ファイルを連携するバケット
- 現在はアプリケーションサーバからインターネット経由でアクセスをしている
- 業務用ファイルには社外秘が含まれるためセキュアにしたい
共通の悩み
- AWSのベストプラクティスに沿ったアーキテクチャとなっていないので解消したい
お題
以下の課題の改善を目指すアーキテクチャを各チームで考える。
どの課題かはくじ引きで決める
各課題(3種類)
- 1. 高レベルなセキュリティ実装
- 本プロジェクトでは個人情報を扱うことからオンプレミスで運用していた際に下記観点でアーキテクチャを実装していました。極力運用負荷を下げつつAWS環境ではどのように実装すべきか提案してください。
- ネットワークセキュリティ
- システムセキュリティ
- データセキュリティ
- 2. 高トラフィックに強いアーキテクチャ
- 最近、自社で販売する製品がバズり新商品が出るたびにアクセスが集中します。下記課題を解消するために極力運用負荷を下げつつどのように実装すべきか提案してください。
- 直近のアクティブユーザー数は10万MAU(Monthly Active Users)
- アクセスが集中し、まれにサーバのCPU使用率が上昇し、サーバが停止し、注文処理がエラーとなる場合がある
- アクセスが集中した際に販売ページが一時的にダウンし機会損失が発生している
- 注文処理の遅延が発生している
- 3. 開発生産性
- 現在、リリース作業をEC2インスタンス上に直接ファイルをアップロードしている状況で人為的ミスが発生することがあるため、テスト・ビルド・デプロイの一貫したフローを確立したい
- ビルドに時間がかかっている
- OS管理(脆弱性対応等)の工数がかかっている
- テストコードがあるが自動化されいない、テストの実行漏れがしばしば発生する
- 障害時の切り戻しが困難、復旧作業に時間がかかっている
- 現在、アプリケーションログをサーバに直接入って参照しているため、手軽にAWS上で確認できるようにしたい
- パラメータシートをスプレッドシートで管理している