type
status
date
slug
summary
tags
category
icon
password
书籍
理論
三層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インスタンス付き構成に移行する。
解説
この質問では、アプリケーションの信頼性を向上させるための適切なソリューションを選択する必要があります。アプリケーションの現状の課題を整理すると以下の通りです：
課題の整理
- データベースの読み取り負荷がピーク時に処理できない。
→ データベースをスケーラブルなサービスに移行し、読み取り負荷を分散させる必要があります。
- 静的コンテンツの管理が非効率。
→ 静的コンテンツを複数のEBSボリュームにコピーする代わりに、共有ストレージを活用する必要があります。
- アプリケーションの負荷変動への対応。
→ スケーリング機能を活用して動的なリソース管理を行う必要があります。
各選択肢の解説
A. AWS Lambda + Amazon RDS for MySQL Multi-AZ
- メリット: Lambdaはサーバーレスでスケーラブル。RDSのMulti-AZ構成により高可用性を確保。
- デメリット: LambdaがEBSボリュームを直接読み取るのは不可能。また、サーバーレスは長時間のリクエスト処理には不向き。
- 評価: 静的コンテンツの要件を満たさないため不適。
B. AWS Step Functions + Amazon Aurora MySQL Serverless v2
- メリット: Aurora MySQL Serverless v2はスケーラブルなリーダーレプリカをサポート。EFSで静的コンテンツを共有可能。
- デメリット: Step Functionsはワークフローオーケストレーション向けで、アプリケーション全体をホストするのには適さない。
- 評価: アプリケーションの性質に合わないため不適。
C. ECS（Fargate） + Amazon RDS for MySQL Multi-AZ
- メリット:
- アプリケーションをコンテナ化し、Fargateを使うことで管理負担を軽減。
- RDS Multi-AZ構成はデータベースの可用性を確保。
- Auto Scalingにより、負荷変動に対応可能。
- デメリット: EBSボリュームは共有ストレージとして複数タスクで使用できない。
- 評価: 静的コンテンツの要件を満たさないため不適。
D. ECS（Fargate） + Amazon Aurora MySQL Serverless v2
- メリット:
- FargateとAuto Scalingでアプリケーションの負荷変動に対応。
- Aurora MySQL Serverless v2はリーダーレプリカをサポートし、読み取り負荷を分散可能。
- EFSを使用することで静的コンテンツを簡単に共有可能。
- デメリット: 特になし。
- 評価: すべての要件（データベースのスケーラビリティ、静的コンテンツの共有、負荷変動への対応）を満たしているため適切。
正解: D
理由:
選択肢Dは以下のように、アプリケーションの信頼性を向上させるためのすべての課題を解決します。
- データベースの読み取り負荷: Aurora MySQL Serverless v2はスケーラブルで、リーダーレプリカを使って読み取り負荷を分散可能。
- 静的コンテンツの共有: EFSは複数のコンテナ間で簡単に共有可能で、EBSよりも管理が容易。
- 負荷変動への対応: FargateとAuto Scalingでリソースを動的に調整可能。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/177d7ae8-88e2-8084-b357-d940217822d5
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
