理論

三層の構成

1. プレゼンテーション層（Presentation Tier）
• 役割: ユーザーインターフェース（UI）を提供し、ユーザーとアプリケーションの間でやり取りを行う層。
• 技術例:
• Webブラウザ
• HTML、CSS、JavaScript
• フロントエンドフレームワーク（React, Angular, Vue.jsなど）
• 特徴:
• ユーザーに見える部分を担当。
• サーバーからデータを取得し、ユーザーに表示。

2. アプリケーション層（Application Tier）
• 役割: ビジネスロジックやアプリケーションの処理を担当。
• 技術例:
• サーバーサイドフレームワーク（Django, Spring, Express.jsなど）
• プログラミング言語（Java, Python, Node.js, Rubyなど）
• 特徴:
• データの処理、検証、ルールの適用を行う。
• プレゼンテーション層とデータ層の橋渡しを行う。

3. データ層（Data Tier）
• 役割: アプリケーションが利用するデータを保存・管理する層。
• 技術例:
• データベース（MySQL, PostgreSQL, MongoDBなど）
• クラウドストレージ（Amazon S3, Azure Blob Storageなど）
• 特徴:
• データの保存、取得、更新を担当。
• アプリケーション層からのリクエストを受けてデータを提供。

三層構造の利点

1. モジュール性: 各層が独立しているため、機能の変更や追加が容易。

2. スケーラビリティ: 特定の層（例: データ層やアプリケーション層）だけをスケールアップ・スケールアウト可能。

3. 保守性: 問題が発生した際に、影響範囲を限定しやすい。

4. 再利用性: 各層を他のアプリケーションやシステムでも利用可能。

実装例

1. プレゼンテーション層: 商品一覧やカートを表示するWebページ。

2. アプリケーション層: 在庫状況の確認、注文処理ロジック。

3. データ層: 商品情報、ユーザー情報、注文履歴を保存するデータベース。

AWSアプリケーション設計における信頼性向上のポイント

1. データベースのスケーラビリティ

• 課題: 高い読み取り負荷に対応できないデータベースはアプリケーションのボトルネックになる。

• 解決策:
• リーダーレプリカ: 読み取り負荷を分散するために、Amazon AuroraやAmazon RDSでリーダーレプリカを活用。
• サーバーレスデータベース: Amazon Aurora Serverless v2は自動スケーリング機能を備え、変動する負荷に対応。

2. 静的コンテンツの管理

• 課題: EBSボリュームを複数のインスタンスで共有できないため、同期が煩雑になる。

• 解決策:
• Amazon Elastic File System (EFS): 複数のEC2インスタンスやコンテナから同時にアクセス可能な共有ストレージ。動的にスケールし、管理負担を軽減。

3. 負荷変動への対応

• 課題: リソースが不足するとアプリケーションが過負荷になり、信頼性が低下。

• 解決策:
• オートスケーリング: Amazon ECS（特にFargate）やAuto Scalingを活用して、負荷に応じてリソースを動的に調整。
• サーバーレスアプローチ: AWS LambdaやAurora Serverlessを使用して、リソース管理をAWSに任せる。

4. コンテナ化とオーケストレーション

• メリット:
• 柔軟性: アプリケーションをコンテナ化することで、AWS FargateやECSで効率的に管理可能。
• スケーラビリティ: Auto Scalingと連携して負荷に応じた調整が可能。

• 関連サービス:
• Amazon ECS: コンテナ化されたアプリケーションの管理を簡略化。
• AWS Fargate: サーバーレスでコンテナを実行するためのマネージドサービス。

5. アプリケーションの設計パターン

• ステートレスアーキテクチャ: アプリケーションをステートレス（状態を持たない）に設計することで、スケーリングを容易にする。

• 分散設計: 各コンポーネント（アプリケーション層、データベース層、静的コンテンツ管理など）を分離して負荷分散を最適化。

結論

• データベース: Amazon Aurora MySQL Serverless v2

• 静的コンテンツ: Amazon EFS

• アプリケーション層: Amazon ECS + Fargate + Auto Scaling

実践

一問道場