342-AWS SAP AWS 「理論・実践・一問道場」三層Web

type

status

date

slug

summary

理論

三層Webアーキテクチャ（Three-Tier Architecture）の「三層」とは、アプリケーションを3つの機能層に分割した構造を指します。これにより、各層が役割に応じて分離され、開発・運用の効率化やスケーラビリティの向上が図られます。

三層の構成

プレゼンテーション層（Presentation Tier）

役割: ユーザーインターフェース（UI）を提供し、ユーザーとアプリケーションの間でやり取りを行う層。

技術例:

Webブラウザ
HTML、CSS、JavaScript
フロントエンドフレームワーク（React, Angular, Vue.jsなど）

特徴:

ユーザーに見える部分を担当。
サーバーからデータを取得し、ユーザーに表示。

アプリケーション層（Application Tier）

役割: ビジネスロジックやアプリケーションの処理を担当。

技術例:

サーバーサイドフレームワーク（Django, Spring, Express.jsなど）
プログラミング言語（Java, Python, Node.js, Rubyなど）

特徴:

データの処理、検証、ルールの適用を行う。
プレゼンテーション層とデータ層の橋渡しを行う。

データ層（Data Tier）

役割: アプリケーションが利用するデータを保存・管理する層。

技術例:

データベース（MySQL, PostgreSQL, MongoDBなど）
クラウドストレージ（Amazon S3, Azure Blob Storageなど）

特徴:

データの保存、取得、更新を担当。
アプリケーション層からのリクエストを受けてデータを提供。

三層構造の利点

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

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

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

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

実装例

ショッピングサイトの場合:

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

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

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

このように、三層アーキテクチャはWebアプリケーションの基盤となる重要な設計思想です。

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. アプリケーションの設計パターン

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

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

結論

AWSで信頼性の高いアプリケーションを設計するには、スケーラビリティ、負荷変動への対応、静的コンテンツ管理を最適化することが重要です。

特に以下の技術が有効です：

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

静的コンテンツ: Amazon EFS

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

実践

略

一問道場

質問 #342

ある企業がアプリケーションをAWSクラウドに移行しました。このアプリケーションは、Application Load Balancer（ALB）の背後にある2つのAmazon EC2インスタンス上で動作しています。

アプリケーションデータは、追加のEC2インスタンス上で稼働するMySQLデータベースに保存されています。このアプリケーションのデータベースの使用はリード（読み取り）に偏っています。

アプリケーションは、各EC2インスタンスにアタッチされたAmazon Elastic Block Store（Amazon EBS）ボリュームから静的コンテンツを読み込んでいます。この静的コンテンツは頻繁に更新され、各EBSボリュームにコピーされる必要があります。

アプリケーションの負荷は1日のうちで変動します。ピーク時には、アプリケーションがすべてのリクエストを処理できません。トレースデータによると、ピーク時にデータベースが読み取り負荷を処理できないことが判明しています。

このアプリケーションの信頼性を向上させるには、どの解決策が最適でしょうか？

A. アプリケーションを一連のAWS Lambda関数に移行する。Lambda関数をALBのターゲットとして設定する。静的コンテンツ用に新しい単一のEBSボリュームを作成する。Lambda関数を構成して新しいEBSボリュームから読み取るようにする。データベースをAmazon RDS for MySQLのマルチAZ DBクラスターに移行する。

B. アプリケーションを一連のAWS Step Functionsステートマシンに移行する。ステートマシンをALBのターゲットとして設定する。静的コンテンツ用にAmazon Elastic File System（Amazon EFS）ファイルシステムを作成する。ステートマシンを構成してEFSファイルシステムから読み取るようにする。データベースをAmazon Aurora MySQL Serverless v2のリーダーDBインスタンス付き構成に移行する。

C. アプリケーションをコンテナ化する。アプリケーションをAmazon Elastic Container Service（Amazon ECS）クラスターに移行する。アプリケーションをホストするタスクにはAWS Fargate起動タイプを使用する。静的コンテンツ用に新しい単一のEBSボリュームを作成する。この新しいEBSボリュームをECSクラスターにマウントする。ECSクラスターにAWS Application Auto Scalingを構成する。ECSサービスをALBのターゲットとして設定する。データベースをAmazon RDS for MySQLのマルチAZ DBクラスターに移行する。

D. アプリケーションをコンテナ化する。アプリケーションをAmazon Elastic Container Service（Amazon ECS）クラスターに移行する。アプリケーションをホストするタスクにはAWS Fargate起動タイプを使用する。静的コンテンツ用にAmazon Elastic File System（Amazon EFS）ファイルシステムを作成する。このEFSファイルシステムを各コンテナにマウントする。ECSクラスターにAWS Application Auto Scalingを構成する。ECSサービスをALBのターゲットとして設定する。データベースをAmazon Aurora MySQL Serverless v2のリーダーDBインスタンス付き構成に移行する。