【AWS構成設計】AWS初心者がElastiCacheを含む3パターンのWebサイト構成を設計してみた
はじめに
本記事では、AWS上でWebサイト構成を設計した際の検討内容と学びをまとめます。
実際の構築ではなく、構成設計のみを行った段階での内容です。
基本構成の概要
Webサイト構成のベースとなる考え方
基本構成としては、Webサーバ（EC2） + DB（RDS） のシンプルな構成をベースにしました。
想定シーンは、一般的なWebサービス（ポータルサイトなど）をAWS上で構築するケースです。
設計時に意識したポイント
- 可用性：AZ冗長化を考慮
- スケーラビリティ：トラフィック増加に対応可能な構成
- セキュリティ：VPC内通信と適切なセキュリティグループ設計
３パターンの構成設計
パターン①：基本構成（EC2＋RDS）
最もシンプルな構成です。
RDSを採用し、アプリケーションサーバから直接DBへ接続する形を取りました。
- メリット：構成が単純で管理が容易
- デメリット：DBへのアクセス集中による負荷懸念、障害耐性の低さ
パターン②：ElastiCache導入構成（EC2＋ElastiCache＋RDS）
WebサーバとDBの間に ElastiCache を導入し、キャッシュによるパフォーマンス向上を狙いました。
読み取り頻度の高いデータをキャッシュ化し、DB負荷を軽減する構成です。
- メリット：レスポンス改善、DB負荷の軽減
- デメリット：キャッシュの整合性管理が課題
パターン③：冗長化構成（ALB＋複数AZ＋RDS Multi-AZ）
高可用性を重視した構成です。
複数AZにWebサーバを配置し、ALB（Application Load Balancer） でトラフィックを分散させています。
- メリット：障害耐性が高く、可用性が向上
- デメリット：コスト増加、構成がやや複雑
苦戦した２パターンの課題と対応
直面した課題と学び
<パターン①：基本構成（EC2＋RDS）>
-
サブネットグループの作成
- EC2を踏み台としてPrivateSubnetに存在するRDSに接続するため、RDS用サブネットグループをあらかじめ作成しておく必要があった
- AWSが冗長化構成を推奨しているため異なるAZの異なるSubnetに接続できるようにするため
- 2つ以上のサブネットを選択してRDS用サブネットを構築するが、シングル構成も可能（RDSを2つ配置しなければいい）
- EC2を踏み台としてPrivateSubnetに存在するRDSに接続するため、RDS用サブネットグループをあらかじめ作成しておく必要があった
-
セキュリティグループの作成
- RDS作成時に踏み台となるEC2を選択した際にセキュリティグループを自動作成することもできるが、複雑なセキュリティグループが作成されてしまう
- EC2、RDSでそれぞれセキュリティグループがInbound・Outboundごとに作成される（計4つ、Inbound・Outboundをまとめて2つでよい）
- サービス作成時にセキュリティグループが必要な場合にはセキュリティグループをあらかじめ作成しておく方がよい
- RDS作成時に踏み台となるEC2を選択した際にセキュリティグループを自動作成することもできるが、複雑なセキュリティグループが作成されてしまう
<パターン②：ElastiCache導入構成（EC2＋ElastiCache＋RDS）>
-
Elasticacheの作成
- ElasticaceとRDS間のデータのやり取り
- この部分に関してはまだ学習中だが、S3等を通してデータのやり取りを行う必要がある？？
- Elasticheをそもそも理解していなかった
- RDSを拡張してキャッシュしていると思っていたが、そんなことはなく別のサービスという認識（インメモリなのでRDSよりもアクセスが早いためキャッシュとして利用されている）
- ElasticaceとRDS間のデータのやり取り
<パターン②：ElastiCache導入構成（EC2＋ElastiCache＋RDS）>
-
ALB作成時のセキュリティグループの設定
- EC2のセキュリティグループ設定ではALBで設定されているInbound用セキュリティグループとOutbound用セキュリティグループをソースに設定することが必要
- EC2のセキュリティグループ（Inbound）：ALBで設定されているInbound用セキュリティグループ
- EC2のセキュリティグループ（Outbound）：ALBで設定されているOutbound用セキュリティグループ
- ALB使用目的にかかわらず、同Subnetに存在する2つ以上のEC2から一つのRDSに接続する際に1対1で制御可能か？？？（今回は構成するまでが対象だったので未検証）
- EC2のセキュリティグループ設定ではALBで設定されているInbound用セキュリティグループとOutbound用セキュリティグループをソースに設定することが必要
ElastiCacheの検討内容
ElastiChcheとは？
- インメモリ型データベースサービス
- 揮発性メモリを使用している
ElastiCacheを導入する理由
- RDSの読み込み負荷を分散
- レスポンス速度の改善（メモリ上で処理・保存するため）
- スケーラブルなキャッシュ層の確保
他のDB（RDS等）との比較
| 項目 | RDS | ElastiCache |
|---|---|---|
| データの永続性 | あり | 基本なし（設定次第） |
| 主な用途 | 永続データの保存 | キャッシュ・セッション管理 |
| スケール方法 | 垂直スケール中心 | 水平スケールが容易 |
ElastiCacheの2種比較（Redis / Memcached）
| 項目 | Redis | Memcached |
|---|---|---|
| 処理方法 | シングルスレッド | マルチスレッド |
| 永続化 | 可能（SnapShotを使用） | 不可 |
| データ構造 | 多様（リスト、セット、ハッシュテーブル、地理空間、ストリームなど） | シンプル（キーと値のみ） |
| マルチAZ | 対応 | 未対応 |
| レプリカ | RDSと同様に、PrimaryのデータベースとReplicaのデータベースを配置可 | 未対応 |
| 運用 | フェイルオーバー対応 | シンプル構成 |
選定理由と使用例
今回の設計では Redis を採用しました。
理由は以下の通りです。
- フェイルオーバー対応により高可用性を確保できる
- データ構造が柔軟で、セッションやランキング管理などにも対応可能
- 永続化オプションを利用できる
使用例：
- セッション管理
- キャッシュストア
- 一時的なデータの共有（例：一時計算結果）
- 位置情報を使用するアプリケーション（地理空間対応のため）
実装を行わず設計に集中した意図
設計のみを実施した理由
今回は企業環境の制約もあり、構成検討に特化しました。
構築よりも、構成要素間の関係理解と設計思想の整理を目的としています。
得られた気づき・学び
- サービス間の関連性を明確化できた
- 構築前にリスクと課題を整理できた
- 設計段階でも運用・拡張性を考慮する重要性を実感
- 構築段階でのセキュリティグループ設定やRDS用サブネット作成を理解できた
まとめ
- ３パターンの構成設計を通して、構成ごとの強みを明確化できた
- 設計段階でも十分に得られる学びがあると実感
- 実際の構築～開発に進む際の検討材料を整理できた
今後の展望
- 実際の構築・性能検証を行い、設計の有効性を検証・不明点の解消を行う
- 実際のユースケースに沿った設計～開発を行う