type
status
date
slug
summary
tags
category
icon
password
 

理論

3層アプリケーションとは、典型的に以下のように分離されたアーキテクチャを指します。具体的な技術スタック(例: Apache, Python, MySQL)は利用する環境によりますが、基本的な構成は以下の通りです。

1. プレゼンテーション層(Web層)

  • 役割: ユーザーがアプリケーションと対話するインターフェースを提供します。
  • :
    • ApacheNginx: Webサーバー
    • フロントエンドフレームワーク: HTML, CSS, JavaScript, React, Angularなど
  • 動作: ユーザーリクエストを受け取り、アプリケーション層に渡す。

2. アプリケーション層(ビジネスロジック層)

  • 役割: アプリケーションのビジネスロジックや処理を担当します。
  • :
    • Python: Django, Flaskなど
    • Java: Spring Framework
    • Node.js: Expressなど
  • 動作: プレゼンテーション層からのリクエストを処理し、データ層とやり取りする。

3. データ層(データベース層)

  • 役割: データの保存、取得、更新を担当します。
  • :
    • MySQL, PostgreSQL: リレーショナルデータベース
    • MongoDB, DynamoDB: NoSQLデータベース
  • 動作: アプリケーション層から受け取ったクエリを処理し、必要なデータを返す。

3層アプリケーションの特長

  1. スケーラビリティ: 各層を個別に拡張可能。
  1. モジュール性: 各層が独立しており、変更が容易。
  1. 高可用性: 層ごとに冗長化を行える。

具体例: Apache + Python + MySQL

この技術スタックで3層アーキテクチャを実装すると以下のようになります。
  • プレゼンテーション層: Apacheがリクエストを受け取る。
  • アプリケーション層: Python(DjangoやFlask)がロジックを処理。
  • データ層: MySQLがデータを管理。
ただし、現代のシステムではこれらの技術スタックに限らず、AWSサービス(例: API Gateway, Lambda, DynamoDB)や他のフレームワークも利用されます。

AWSでの高可用性と災害復旧の重要ポイント

  1. 高可用性の設計
      • Auto Scalingグループ + 複数AZ: アプリケーションやウェブサーバーを複数AZに展開して障害に備える。
      • 予約インスタンス + オンデマンドインスタンス: コストと柔軟性を両立。
  1. 迅速な災害復旧(DR)
      • DynamoDBグローバルテーブル: リージョン間でデータを自動レプリケーションし、高速な切り替えを実現。
      • Route 53フェイルオーバー: TTLを短く設定(例: 30秒)して自動切り替えを迅速化。
  1. 効率的なデータレプリケーション
      • S3クロスリージョンレプリケーション: 静的データやバックアップの効率的なレプリケーション。
      • RDSリードレプリカ: 他リージョンでのDBデータ保持と迅速な昇格。
  1. コスト効率とパフォーマンスのバランス
      • 必要最低限のインスタンスは予約、急激な増加にはオンデマンドまたはスポットインスタンスで対応。

ベストプラクティス

  • DynamoDBグローバルテーブル + Route 53: 迅速なフェイルオーバーが必要なシナリオに最適。
  • S3やRDSのレプリケーション: コスト効率を重視したバックアップ設計に有効。

実践

一問道場

質問 #240

トピック 1
ソリューションアーキテクトは、Web、アプリケーション、NoSQLデータの3層アプリケーション向けの参照アーキテクチャを定義する必要があります。この参照アーキテクチャは、次の要件を満たさなければなりません:
  • AWSリージョン内での高可用性
  • 災害復旧のために1分以内に別のAWSリージョンにフェイルオーバー可能
  • ユーザーエクスペリエンスへの影響を最小限に抑えつつ、最も効率的なソリューションを提供
以下のステップの組み合わせでこれらの要件を満たすものを選択してください(3つ選択)。

A. 2つの選択されたリージョン間でAmazon Route 53の加重ルーティングポリシーを使用し、比率を100/0に設定する。TTL(Time to Live)は1時間に設定する。
B. Amazon Route 53のフェイルオーバールーティングポリシーを使用して、プライマリリージョンから災害復旧リージョンへのフェイルオーバーを設定する。TTLは30秒に設定する。
C. Amazon DynamoDBのグローバルテーブルを使用して、2つの選択されたリージョンでデータにアクセスできるようにする。
D. プライマリリージョンのAmazon DynamoDBテーブルから60分ごとにデータをバックアップし、そのデータをAmazon S3に書き込む。S3のクロスリージョンレプリケーションを使用して、データをプライマリリージョンから災害復旧リージョンにコピーする。災害復旧シナリオでは、スクリプトを使用してDynamoDBにデータをインポートする。
E. ホットスタンバイモデルを実装し、複数のアベイラビリティゾーンにまたがるリージョンで、Web層とアプリケーション層にAuto Scalingグループを使用する。最小限のサーバー数にゾーン予約インスタンスを使用し、追加リソースにはオンデマンドインスタンスを使用する。
F. Web層とアプリケーション層にAuto Scalingグループを使用し、複数のアベイラビリティゾーンにまたがるリージョンで動作させる。必要なリソースにはスポットインスタンスを使用する。

解説

この問題では、3層アプリケーションのための参照アーキテクチャを設計する必要があります。要件に基づき、高可用性と迅速な災害復旧を実現する効率的なアプローチを選択します。

正解: B, C, E

B. Amazon Route 53のフェイルオーバールーティングポリシー

  • フェイルオーバー時にプライマリリージョンからバックアップリージョンにトラフィックを迅速に切り替える必要があります。
  • TTLを30秒に設定することで、ユーザーの影響を最小限に抑え、フェイルオーバーを迅速に行います。

C. Amazon DynamoDBのグローバルテーブル

  • DynamoDBのグローバルテーブルを使用すると、選択した複数のリージョンでデータのレプリケーションとアクセスを自動化できます。
  • 手動でバックアップと復元を行う必要がなく、フェイルオーバー時もデータはすぐに利用可能です。

E. ホットスタンバイモデル(Auto Scalingグループ + 複数AZ)

  • 複数のアベイラビリティゾーンにわたるAuto Scalingグループを設定することで、高可用性を実現します。
  • 最小限のリソースには予約インスタンスを使用し、スパイク時にはオンデマンドインスタンスを利用してコスト効率を高めます。

不正解の理由

A. Route 53の加重ルーティングポリシー

  • 加重ルーティングはフェイルオーバーを迅速に行うための適切な選択ではありません。TTLが1時間と長いため、切り替えに時間がかかります。

D. 手動バックアップとS3のクロスリージョンレプリケーション

  • DynamoDBのバックアップを手動で行い、S3でレプリケーションする方法は効率が悪く、1分以内の迅速なフェイルオーバーには適していません。

F. スポットインスタンスの使用

  • スポットインスタンスはコストが低いものの、中断される可能性があるため、高可用性が求められる本ケースには不向きです。

まとめ

この設計では、DynamoDBのグローバルテーブルでデータのレプリケーションを自動化し、Route 53のフェイルオーバーポリシーで迅速な切り替えを実現。さらに、ホットスタンバイモデルで高可用性を確保します。これにより、効率的かつユーザーへの影響を最小限に抑えるソリューションを提供します。
相关文章
クラウド技術の共有 | AWS Site-to-Site
Lazy loaded image
EKSでのWordPressデプロイ:KCNA-JP試験対策 (Kubernetes実践編)
Lazy loaded image
初心者向け!コンテナ化WordPressサイト構築ガイド(超詳細版)
Lazy loaded image
EFSを活用!AWS EC2でDockerを使ったWordPressサイト構築
Lazy loaded image
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
Lazy loaded image
528-AWS SAP AWS 「理論・実践・一問道場」Migration Evaluator
Lazy loaded image
241-AWS SAP AWS 「理論・実践・一問道場」AWS IoT Core239-AWS SAP AWS 「理論・実践・一問道場」Amazon Kinesis Data Streams
Loading...
みなみ
みなみ
一个普通的干饭人🍚
最新发布
02-生成AIパスポート試験対策:第2章「生成AI」
2025-2-1
01-生成AIパスポート試験対策:第1章「人口知能」
2025-2-1
究極のAWS認定 AI 実践者 AIF-C01 - 学習メモ
2025-1-27
不要再傻傻的直接买NISA啦
2025-1-27
Kubernetes、仮想マシンとコンテナの概念を超簡単に解説!
2025-1-24
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
2025-1-22
公告
🎉欢迎访问我的博客🎉
- 感谢您的支持 --
本站点于2024/09/01建立
👏主要分享IT相关主题👏
系统管理:
Redhat…
容器和编排:
Kubernetes、Openshift…
云计算:
AWS、IBM…
AI入门
以及技术笔记和考证经验
定期更新,欢迎互动。
感谢访问!
快速浏览相关标签