34-AWS SAP「理論・実践・10問道場」

type

status

date

slug

summary

341-AWS SAP AWS 「理論・実践・一問道場」Aurora Serverless

理論

1. Auroraのスケーラビリティとコスト最適化

Aurora MySQLは、高可用性とパフォーマンスを提供するリレーショナルデータベースサービスですが、トラフィックが不規則で、負荷に応じた自動スケーリングが必要な場合、Aurora Serverlessが最適です。

Aurora Serverlessは、負荷に応じて自動的にスケールアップ・スケールダウンが可能で、通常の使用時間帯には自動的にリソースを拡張し、使用が少ない時間帯には縮小します。これにより、コストが無駄なく最適化されます。

2. Aurora Serverless v1とv2の違い

Aurora Serverless v1は、低負荷または変動する負荷を処理するために設計されています。自動的にスケールイン・スケールアウトしますが、起動時間に若干の遅延があります。

Aurora Serverless v2は、より短期間でのスケーリングを実現し、より継続的なパフォーマンスを提供します。特に変動の激しいワークロードに適しています。

3. AWSのコスト最適化のアプローチ

セービングプランやリザーブドインスタンスは、長期間にわたって予測可能なリソース使用を前提にコスト削減を実現しますが、トラフィックの変動が激しい場合は、使用するインスタンスやリソースの変更に柔軟に対応できるソリューションを選択することが重要です。

4. AWSのスケーラブルなサービス

Amazon ECS + AWS Fargate：コンテナ化されたアプリケーションにおいて、トラフィックの増減に応じて自動的にスケールするFargateは、無駄なリソースを排除し、コスト最適化に寄与します。

AWS Lambda：サーバーレスコンピューティングで、リクエストに応じて処理が実行され、使用した分だけ課金されるため、スケーリングに最適です。

5. AWSのデータベースのスケーリング戦略

書き込みが多く、不規則なトラフィックを持つアプリケーションには、Aurora Serverlessが理想的です。特に、データベースの容量やリソースの使用量を動的に調整できるため、ピーク時の負荷にも柔軟に対応可能です。

これらを理解しておくことで、アプリケーションのスケーリングに最適な選択肢を選び、コストを最適化できます。

実践

略

一問道場

質問 #341

ある企業が、AWSでのアプリケーションのコストを最適化する必要があります。このアプリケーションは、AWS Lambda関数とAmazon Elastic Container Service（Amazon ECS）のコンテナを使用しており、これらはAWS Fargate上で実行されています。アプリケーションは書き込みが多く、データはAmazon Aurora MySQLデータベースに格納されています。アプリケーションの負荷は一定ではなく、長時間使用されない時期があり、その後、トラフィックが急激に増加したり減少したりします。データベースはメモリ最適化されたDBインスタンスで実行されていますが、その負荷に対応できません。

ソリューションアーキテクトは、トラフィックの変動に対応できるスケーラブルなソリューションを設計する必要があります。

どのソリューションが最もコスト効果が高いですか？

A. データベースに追加のリードレプリカを追加する。インスタンスのセービングプランとRDSリザーブドインスタンスを購入する。

B. データベースを、複数の書き込みインスタンスを持つAurora DBクラスターに移行する。インスタンスのセービングプランを購入する。

C. データベースをAuroraグローバルデータベースに移行する。コンピュートセービングプランとRDSリザーブドインスタンスを購入する。

D. データベースをAurora Serverless v1に移行する。コンピュートセービングプランを購入する。

解説

この問題では、アプリケーションの負荷に応じたコスト効果の高いデータベースのスケーリングを求めています。アプリケーションの負荷が不規則であり、トラフィックが急激に増減するため、スケーラブルで費用対効果の高いソリューションが必要です。解説は以下の通りです：

A. データベースに追加のリードレプリカを追加する。インスタンスのセービングプランとRDSリザーブドインスタンスを購入する。

不適切: リードレプリカは読み取り専用で、書き込みが多いアプリケーションには効果的ではありません。また、リザーブドインスタンスは使用量が一定である場合にコスト削減を見込めますが、アプリケーションのトラフィックが不規則である場合には柔軟性が欠けます。

B. データベースを、複数の書き込みインスタンスを持つAurora DBクラスターに移行する。インスタンスのセービングプランを購入する。

不適切: 複数の書き込みインスタンスを持つAurora DBクラスターは高可用性を提供しますが、書き込みが多い場合でもトラフィックの変動に柔軟に対応するには不十分です。インスタンスのセービングプランはコスト削減には有効ですが、トラフィックの急増に対する対応力が限られています。

C. データベースをAuroraグローバルデータベースに移行する。コンピュートセービングプランとRDSリザーブドインスタンスを購入する。

不適切: Auroraグローバルデータベースは複数のリージョンにまたがるデータベースを提供し、災害復旧やグローバルなアクセス向けには有効ですが、トラフィックの急増に対してはスケーリングの柔軟性が不足しており、コスト効果が悪化します。

D. データベースをAurora Serverless v1に移行する。コンピュートセービングプランを購入する。

適切: Aurora Serverlessは、負荷に応じて自動でスケールアップおよびスケールダウンできるため、トラフィックの変動に柔軟に対応できます。特に書き込みが多い場合でも、リソースを必要なときだけプロビジョニングするため、コストを最適化できます。また、コンピュートセービングプランを購入すれば、固定のリソースを予測する場合にコスト削減が期待できます。

結論:

最もコスト効果が高いのはDです。Aurora Serverless v1は、アプリケーションのトラフィックの急激な変動に対応できるスケーラブルなソリューションを提供し、無駄なコストを削減できます。

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

理論

三層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でリソースを動的に調整可能。

343-AWS SAP AWS 「理論・実践・一問道場」AWS_IAM 認証 + AWS X-Ray

理論

1. API Gateway でのアクセス制御

IAM 認証（AWS Signature）:

AWS の API Gateway では、IAM ユーザーやロールによる認証を行うことができます。IAM の権限を使って、API のリソースへのアクセスを制御できます。
具体的には、execute-api:Invoke の権限を持つ IAM ユーザーやロールに対してアクセスを許可します。

AWS Signature:

API Gateway へのリクエストは、AWS Signature を使用して署名されることが多いです。これにより、リクエストが正当なものであるかどうかを確認できます。

2. リクエストの追跡と分析

AWS X-Ray:

AWS X-Ray は、分散アプリケーションのリクエストをトレースし、パフォーマンスのボトルネックや遅延を特定するためのツールです。これを使用することで、API Gateway へのリクエストのフロー全体を可視化し、遅延の原因を特定できます。
X-Ray は、リクエストが API Gateway を通過し、バックエンドサービスに到達する過程を追跡し、全体的なパフォーマンスを分析するのに役立ちます。

Amazon CloudWatch:

CloudWatch はログやメトリクスを収集し、システム全体のパフォーマンスや状態を監視するために使用されます。API Gateway のレスポンス時間やエラーなどのメトリクスを監視できます。

3. API Gateway のアクセス制御方法

CORS 設定:

API Gateway で CORS（クロスオリジンリソース共有）を設定することができます。これにより、異なるオリジンからのリクエストを許可または制限できます。特にブラウザでのアクセスを制御する場合に有用です。

カスタムオーソライザー:

Lambda 関数をカスタムオーソライザーとして使用し、リクエストに含まれるトークンや認証情報を検証できます。これにより、柔軟な認証ロジックを実装可能です。

4. 適切なサービスの選定

API Gateway と Lambda の組み合わせ:

AWS Lambda をバックエンドで使用する場合、API Gateway と連携してサーバーレスアーキテクチャを構築することができます。これにより、高いスケーラビリティと効率的なリソース管理が可能になります。

API Gateway と ECS（Fargate）:

コンテナ化されたアプリケーションを Amazon ECS（Fargate）で実行し、API Gateway をフロントエンドとして使用するアーキテクチャもあります。これにより、スケーラブルで柔軟なバックエンドシステムを構築できます。

まとめ

API Gateway でのアクセス制御は IAM 認証や CORS 設定、カスタムオーソライザーなどで行います。

リクエストの追跡には AWS X-Ray や CloudWatch を利用し、遅延やエラーの原因を可視化します。

適切なサービスを選ぶことで、スケーラブルで効率的なシステムを構築できます。

これらの知識を組み合わせて、セキュアでスケーラブルな API を設計することが可能です。

実践

略

一問道場

質問 #343

ソリューションアーキテクトは、新しい Amazon API Gateway エンドポイントにアクセスできるのが、適切な権限を持つ AWS ユーザーまたはロールに限定されるようにしたいと考えています。ソリューションアーキテクトは、各リクエストのエンドツーエンドのビューを取得してリクエストの待ち時間を分析し、サービスマップを作成したいと考えています。

ソリューションアーキテクトは、API Gateway のアクセス制御をどのように設計し、リクエストの検査を行うことができますか？

A. API Gateway のメソッドで認証を AWS_IAM に設定します。その後、REST API リソースに対して IAMユーザーまたはロールに execute-api:Invoke 権限を付与します。エンドポイントにアクセスする際に、API 呼び出し元が AWS シグネチャを使用してリクエストに署名できるようにします。AWS X-Ray を使用して、API Gateway に対するユーザーリクエストをトレースおよび分析します。

B. API Gateway リソースで CORS を有効化し、Access-Control-Allow-Origin ヘッダーに会社のドメインだけを返すように設定します。その後、REST API リソースに対して IAM ユーザーまたはロールに execute-api:Invoke 権限を付与します。Amazon CloudWatch を使用して、API Gateway に対するユーザーリクエストをトレースおよび分析します。

C. AWS Lambda 関数をカスタムオーソライザーとして作成し、API クライアントに呼び出し時にキーとシークレットを渡すよう依頼します。そして、Lambda を使用して IAM システムに対してキー/シークレットペアを検証します。AWS X-Ray を使用して、API Gateway に対するユーザーリクエストをトレースおよび分析します。

D. API Gateway 用のクライアント証明書を作成します。この証明書をエンドポイントにアクセスする必要がある AWS ユーザーおよびロールに配布します。エンドポイントにアクセスする際に、API 呼び出し元がクライアント証明書を渡せるようにします。Amazon CloudWatch を使用して、API Gateway に対するユーザーリクエストをトレースおよび分析します。

解説

この問題の主なポイントは、以下の2つの要件を満たす解決策を選択することです：

API Gateway のアクセス制御

API Gateway に対するアクセスを、適切な権限を持つユーザーまたはロールのみに制限する方法を設計します。これには、認証・認可の仕組みが必要です。

リクエストの追跡と分析

各リクエストのエンドツーエンドの視点を取得し、リクエストの遅延を分析したり、サービスマップを生成することで、システムの依存関係とパフォーマンスを可視化します。

各選択肢の解説

A. AWS_IAM 認証 + AWS X-Ray の使用

アクセス制御: API Gateway のメソッドに AWS_IAM 認証を設定することで、AWS の IAM ユーザーまたはロールのアクセスを制限します。

IAM ユーザー/ロールに execute-api:Invoke 権限を付与することで、API の実行を許可します。
API 呼び出し元はリクエストに AWS シグネチャ（AWS Signature）を付与する必要があります。

リクエストの追跡: AWS X-Ray を使用して、API Gateway に対するリクエストをトレースし、エンドツーエンドでリクエストを可視化します。

評価: IAM 認証と X-Ray の組み合わせにより、アクセス制御とリクエスト追跡の両方を実現する最適な選択肢です。

B. CORS 設定 + CloudWatch の使用

アクセス制御: CORS（クロスオリジンリソース共有）を有効化し、特定のオリジン（例: 会社のドメイン）のみリソースにアクセス可能にします。IAM ユーザー/ロールに execute-api:Invoke 権限を付与します。

リクエストの追跡: Amazon CloudWatch を使用してリクエストをトレースしますが、CloudWatch は X-Ray のような詳細なサービスマップや依存関係分析を提供しません。

評価: CORS はオリジン制御を提供しますが、認証の仕組みが不十分であり、X-Ray の代わりに CloudWatch を使用するため、追跡機能が限定的です。

C. カスタムオーソライザー（Lambda 関数） + AWS X-Ray の使用

アクセス制御: Lambda をカスタムオーソライザーとして使用し、API クライアントが渡すキーとシークレットを検証します。

カスタムオーソライザーは柔軟性が高いですが、IAM 認証より設定や管理が複雑になります。

リクエストの追跡: AWS X-Ray を使用して、リクエストをトレースします。

評価: カスタムオーソライザーは柔軟性がありますが、IAM 認証を使ったよりシンプルなソリューションと比較すると複雑で、運用負荷が増します。

D. クライアント証明書 + CloudWatch の使用

アクセス制御: API Gateway のクライアント証明書を使用し、エンドポイントへのアクセスを制御します。証明書をユーザーやロールに配布する必要があります。

リクエストの追跡: Amazon CloudWatch を使用してリクエストをトレースします。

評価: クライアント証明書は認証手段として有効ですが、証明書の管理や配布が煩雑です。また、CloudWatch は X-Ray のような詳細な追跡機能を提供しません。

結論

正解: A

理由:

アクセス制御において、IAM 認証を使用することで、AWS の標準的な認証機能を活用できます。これは、設定が簡単で安全性が高いです。

リクエストの追跡において、AWS X-Ray はサービスマップの作成や遅延分析に最適なツールです。

全体的に、シンプルで効率的なソリューションを提供します。

リクエストの流れを簡単に説明します：

1. クライアントがリクエストを送信

クライアント（ブラウザやアプリケーション）が API Gateway のエンドポイントにリクエストを送ります。

リクエストには AWS Signature（IAM 認証情報） を含める必要があります。

2. API Gateway が認証を実施

API Gateway はリクエストを受信すると、以下を確認します：

認証情報の有効性（IAM ポリシーで権限があるか）。

エンドポイントへのアクセス権限があるか（execute-api:Invoke）。

3. 認証後、リクエストを処理

認証が成功すると、API Gateway はバックエンドサービス（例えば Lambda や EC2）にリクエストを転送します。

API Gateway はリクエスト処理の詳細（遅延、レスポンス時間など）を収集します。

4. AWS X-Ray でリクエストを追跡

API Gateway はリクエストの情報を AWS X-Ray に送信します：

クライアントから API Gateway への通信時間。

API Gateway からバックエンドへの通信時間。

全体の遅延やエラーの原因。

5. クライアントにレスポンスを返す

バックエンドがリクエストを処理し、API Gateway を通じてクライアントにレスポンスを返します。

AWS X-Ray にはレスポンスに関するデータも記録されます。

まとめたリクエストの流れ

クライアント → API Gateway（認証チェック）。

API Gateway → バックエンド（リクエスト処理）。

バックエンド → API Gateway → クライアント（レスポンス返却）。

X-Ray でリクエスト全体の追跡と分析。

この流れを通じて、セキュアなアクセス制御とリクエストの詳細な可視化が可能になります。

344-AWS SAP AWS 「理論・実践・一問道場」変更セット

理論

1. CI/CDパイプライン

*CI（継続的インテグレーション）とCD（継続的デリバリー/デプロイメント）**は、ソフトウェア開発における自動化されたプロセスで、コードの変更が迅速かつ確実に本番環境に反映されるようにします。

CI: コードの統合とビルドを自動化するプロセス。コードがリポジトリにプッシュされるたびに、ビルドとテストが自動で実行されます。

CD: テストが成功したコードを自動的に本番環境にデプロイするプロセス。これにより、変更がすぐに本番環境で反映され、迅速に機能追加やバグ修正を行えます。

2. AWS CloudFormation

CloudFormationは、AWSリソースをコードで定義するためのサービスです。インフラストラクチャをテンプレートとして管理し、テンプレートに基づいてリソースを自動的に作成・更新できます。

リソースの依存関係: CloudFormationは、リソース間の依存関係を自動的に解決し、適切な順序でリソースを作成します。しかし、変更の際に適切な評価を行わないと、予期しないダウンタイムが発生することがあります。

3. 変更セット（Change Sets）

変更セットは、CloudFormationでリソースを変更する際に、新しい変更がどのように既存のリソースに影響を与えるかを事前に確認する機能です。これを使用することで、デプロイ前にリソースの変更を検証し、誤った変更が本番環境に影響を及ぼさないようにできます。

4. Blue/Greenデプロイメント

Blue/Greenデプロイメントは、アプリケーションの新しいバージョンを安全に展開する方法です。2つの環境（青と緑）を用意し、青環境が現在の本番環境、緑環境が新しいバージョンをホストします。

青環境（Blue）: 現在稼働している本番環境
緑環境（Green）: 新しいバージョンを展開した環境

新しいバージョンが緑環境でテストされ、問題がなければトラフィックを緑環境に切り替えます。問題が発生した場合は、即座に青環境にロールバックできます。この手法はダウンタイムを最小化し、リスクを軽減します。

5. AWS CodeDeploy

AWS CodeDeployは、アプリケーションの自動デプロイを管理するサービスで、EC2インスタンス、オンプレミスサーバ、Lambda関数、さらにはECS（コンテナ）のデプロイにも対応しています。Blue/Greenデプロイメントやローリングデプロイメントなど、さまざまなデプロイメント戦略をサポートしています。

Blue/Greenデプロイメントパターンでは、新しいバージョンを一度に全てのインスタンスに展開するのではなく、特定のインスタンスにだけ展開し、テストを行いながら本番環境に反映させることができます。

6. 自動テストとステージング環境

自動テスト: CI/CDパイプラインの一環として、コードが本番環境にデプロイされる前に自動テストを実行することは、エラーや不具合を早期に発見するために非常に重要です。

ステージング環境: 本番環境とほぼ同じ設定の環境でテストを実施することにより、本番環境での問題を事前に検出できます。特にCloudFormationのようなインフラ構成管理ツールを使用している場合、リソースが実際に作成される前に仮想環境で変更の影響を確認できます。

7. 監視とロギング

Amazon CloudWatch: AWSサービスの監視とロギングを行い、CI/CDパイプラインにおけるデプロイの状態やアプリケーションの動作をリアルタイムで追跡します。問題が発生した場合には、CloudWatchアラームで通知を受け取ることができます。

結論

CI/CDパイプラインにおける変更のリスク管理や安全なデプロイメントには、CloudFormationテンプレートの適切な管理、テスト環境での事前検証、そしてBlue/Greenデプロイメントなどの戦略を活用することが重要です。これらを組み合わせることで、予期しないダウンタイムを減らし、効率的かつ安全にアプリケーションの更新を行うことができます。

実践

略

一問道場

質問 #344

ある企業は、アプリケーションのCI/CDにAWS CodePipelineを使用しています。すべてのAWSリソースはAWS CloudFormationテンプレートで定義されており、アプリケーションのアーティファクトはAmazon S3バケットに格納され、インスタンスのユーザーデータスクリプトを使用してAuto Scalingグループにデプロイされています。アプリケーションが複雑になるにつれて、CloudFormationテンプレートのリソース変更が原因で予定外のダウンタイムが発生しています。

テンプレートの変更がダウンタイムを引き起こす可能性を減らすために、ソリューションアーキテクトはCI/CDパイプラインをどのように改善すべきでしょうか？

A. デプロイスクリプトを適応させて、デプロイ時にCloudFormationのエラー条件を検出し、報告できるようにする。変更を本番環境に承認する前に、テストチームが非本番環境でテスト計画を実行するようにする。

B. AWS CodeBuildを使用してテスト環境で自動化テストを実行する。CloudFormation変更セットを使用して、デプロイ前に変更を評価する。AWS CodeDeployを使用して、評価と変更の取り消しが可能な青/緑デプロイメントパターンを活用する。

C. 統合開発環境（IDE）用のプラグインを使用してテンプレートのエラーをチェックし、AWS CLIを使用してテンプレートが正しいかどうかを検証する。デプロイコードを適応させて、エラー条件をチェックし、エラー時に通知を生成する。テスト環境にデプロイして手動テスト計画を実行し、本番環境への変更を承認する。

D. AWS CodeDeployと青/緑デプロイメントパターンを使用して、CloudFormationでユーザーデータデプロイスクリプトを置き換える。オペレーターが実行中のインスタンスにログインし、アプリケーションが期待通りに動作しているかを手動で確認する。

解説

この問題は、CI/CDパイプラインの改善方法についての質問です。特に、CloudFormationテンプレートの変更が原因で発生した計画外のダウンタイムを減らす方法を問われています。

シナリオの概要

CI/CDツール: AWS CodePipeline

インフラ: EC2 Auto Scalingグループにデプロイ

リソース管理: すべてAWS CloudFormationテンプレートで管理

アプリケーションのアーティファクト: Amazon S3に格納、EC2インスタンスのユーザーデータスクリプトを使用してAuto Scalingグループにデプロイ

問題: アプリケーションが複雑化する中で、CloudFormationテンプレートの変更により予期せぬダウンタイムが発生している

問題の本質

CloudFormationテンプレートに変更が加わると、それに基づいたリソースの作成・変更が自動で行われます。この自動化の過程で、リソースの依存関係や変更が正しく処理されない場合、ダウンタイムが発生するリスクがあります。

目指すべき改善点

テンプレート変更によるリスクを最小化し、ダウンタイムを減らすためには、テンプレートの変更を事前に評価し、テストを実施し、問題があればすぐに回避できる仕組みを作ることが必要です。

各選択肢の解説

A. テスト計画の作成とエラーチェック

選択肢Aでは、デプロイスクリプトを修正してCloudFormationのエラーを検出し、テストチームに事前にテストを行ってもらうという方法です。これも有効ですが、手動での検証が必要なため、完全な自動化には不十分です。

B. 自動テストとCloudFormation変更セット、AWS CodeDeployの利用

選択肢Bは、AWS CodeBuildで自動テストを行い、CloudFormation変更セットを使用して事前に変更を評価し、AWS CodeDeployを使ったBlue/Greenデプロイメントを導入する方法です。これにより、変更が本番環境に影響を与える前にテストでき、問題があれば簡単にロールバックできるため、ダウンタイムを減らすことができます。

C. IDEプラグインとAWS CLIによるエラーチェック

選択肢Cでは、IDEプラグインを使ってテンプレートを検証し、AWS CLIでエラーをチェックする方法です。これも一部のエラーを事前に見つけるのに役立ちますが、テスト環境での検証を行わないため、リスクを完全には減らせません。

D. AWS CodeDeployと手動テスト

選択肢Dは、AWS CodeDeployを使ってBlue/Greenデプロイメントを行うという方法です。これにより、新しいバージョンをリリースする際に手動テストを行うことが求められますが、自動化の利点を生かしきれていないため、ダウンタイムを減らすためには少し不完全です。

正解の選択肢

選択肢Bが最も適切です。理由は以下の通りです：

AWS CodeBuildを使った自動テストにより、デプロイ前に問題を検出でき、リスクを最小化できます。

CloudFormation変更セットを使って、変更の影響を事前に評価できるため、予期しないエラーを防げます。

AWS CodeDeployのBlue/Greenデプロイメントにより、新しいバージョンを安全に展開し、問題が発生した場合には迅速に回避できます。

このアプローチは、CI/CDパイプラインを改善し、アプリケーションのダウンタイムを最小限に抑えるための効果的な方法です。

345-AWS SAP AWS 「理論・実践・一問道場」アクティブ・アクティブ

理論

1. Amazon EC2 Auto Scaling とアプリケーションのスケーリング

Auto Scalingは、EC2インスタンスの数を動的に変更することで、アプリケーションのトラフィック需要に応じてリソースをスケールする仕組みです。これにより、トラフィックの急増にも柔軟に対応できます。

スケーリングポリシーを設定して、EC2インスタンスを増減させるタイミングを調整できます。

2. 高可用性のための多AZ展開

複数の**Availability Zone（AZ）**にまたがってリソースを展開することで、可用性が向上します。たとえば、ALBやEC2インスタンスを複数のAZに展開することで、単一のAZがダウンしても、別のAZでサービスを継続できます。

3. Route 53 とフェイルオーバールーティング

Amazon Route 53は、DNSサービスを提供し、トラフィックを複数のリソースに分散できます。フェイルオーバールーティングポリシーを使うことで、片方のリージョンが障害を起こした際に、トラフィックを別のリージョンに自動的に切り替えられます。

ヘルスチェックを設定することで、リソースの健康状態を監視し、問題が発生した場合に他のリージョンへトラフィックをルーティングできます。

4. アクティブ・パッシブ構成

アクティブ・パッシブ構成では、1つのリージョンが「アクティブ」な運用を行い、もう1つのリージョンが待機状態（パッシブ）となります。Route 53のフェイルオーバー機能を活用することで、アクティブリージョンがダウンした際に、パッシブリージョンにトラフィックが切り替えられます。

5. AWSリージョン間の通信

異なるリージョン間でのリソース通信が必要な場合、VPC Peeringを使って、2つのリージョンにまたがるリソースを接続できます。ただし、ALBが複数のリージョンに跨ることはできないため、フェイルオーバーを目的とした設計では、Route 53のフェイルオーバー機能を活用し、各リージョンに個別のALBを設置します。

6. 災害復旧（DR）戦略

災害復旧には、アクティブ・アクティブまたはアクティブ・パッシブの構成が一般的です。アクティブ・アクティブでは両方のリージョンで稼働しており、トラフィックを分散させます。アクティブ・パッシブでは、通常は1つのリージョンが運用され、もう一方は障害時に切り替え用として待機しています。

まとめ:

この問題は、アプリケーションの可用性と災害復旧の要件を満たすための設計に関するもので、EC2 Auto Scaling、Route 53のフェイルオーバールーティング、ALB、およびVPC Peeringを使ったリージョン間の接続方法が重要です。

実践

略

一問道場

問題

北米の企業が、us-east-1リージョンで実行される新しいウェブアプリケーションを展開しています。このアプリケーションは、ユーザーの需要に応じて動的にスケールし、レジリエンシーを維持する必要があります。さらに、このアプリケーションは、アクティブ-パッシブ構成でus-west-1リージョンにディザスタリカバリ機能を持っている必要があります。

us-east-1リージョンにVPCを作成した後、ソリューションアーキテクトはどのステップを実行するべきですか？

A. us-west-1リージョンにVPCを作成し、インターリージョンVPCピアリングを使用して両方のVPCを接続します。us-east-1リージョンのVPCに複数のアベイラビリティゾーン（AZ）にまたがるアプリケーションロードバランサー（ALB）を展開します。各リージョンの複数のAZにわたるEC2インスタンスをAuto Scalingグループの一部として展開し、ALBによってサービスを提供します。

B. us-east-1リージョンのVPCに複数のアベイラビリティゾーン（AZ）にまたがるアプリケーションロードバランサー（ALB）を展開します。複数のAZにわたるEC2インスタンスをAuto Scalingグループの一部として展開し、ALBによってサービスを提供します。同様のソリューションをus-west-1リージョンに展開します。Amazon Route 53でフェイルオーバールーティングポリシーとヘルスチェックを有効にしたレコードセットを作成し、両リージョンでの高可用性を提供します。

C. us-west-1リージョンにVPCを作成し、インターリージョンVPCピアリングを使用して両方のVPCを接続します。両方のVPCにまたがるアプリケーションロードバランサー（ALB）を展開します。複数のアベイラビリティゾーンにわたるEC2インスタンスをAuto Scalingグループの一部として各VPCに展開し、ALBによってサービスを提供します。ALBを指すAmazon Route 53レコードを作成します。

D. us-east-1リージョンのVPCに複数のアベイラビリティゾーン（AZ）にまたがるアプリケーションロードバランサー（ALB）を展開します。複数のAZにわたるEC2インスタンスをAuto Scalingグループの一部として展開し、ALBによってサービスを提供します。同じソリューションをus-west-1リージョンに展開します。各リージョンのALBを指す別々のAmazon Route 53レコードを作成します。Route 53ヘルスチェックを使用して、両リージョンでの高可用性を提供します。

解説

この問題では、北米の企業がアプリケーションをus-east-1リージョンで展開し、us-west-1リージョンでディザスタリカバリを実現するために、どのようにして可用性を確保するかを問われています。以下、各選択肢を解説します。

A.

間違いです。

インターリージョンVPCピアリングを使ってVPCを接続する方法は、異なるリージョン間でリソースを直接接続する手段ですが、アプリケーションの高可用性や災害復旧にはあまり向いていません。

また、ALBを複数のAZにまたがって展開するのは、同一リージョン内での可用性確保に有効ですが、他リージョンにわたるフェイルオーバーには不向きです。

B.

正解です。

Amazon Route 53のフェイルオーバールーティングポリシーを使用して、2つのリージョン間でのトラフィックの切り替えを実現できます。

ALBを複数のAZにまたがって展開し、Auto Scalingグループでスケーリングを実施することで、高可用性を確保します。

Route 53のヘルスチェックを使用することで、アクティブなリージョンにトラフィックを自動的にルーティングし、障害が発生した場合に別のリージョンに切り替えられるため、災害復旧の要件にも対応できます。

C.

間違いです。

ALBが両方のVPCにまたがって展開されるというのは技術的にサポートされていません。ALBは同一VPC内の複数のAZに展開できますが、複数のVPCにまたがることはできません。

そのため、この構成は実現不可能です。

D.

間違いです。

この選択肢では、2つのリージョンにおいて同様のインフラを展開していますが、Route 53で複数のレコードを作成するだけでは、フェイルオーバーを実現するためのロジックが不足しています。

高可用性を確保するためには、Route 53のヘルスチェックを使ったフェイルオーバールーティングが必要です。この選択肢ではヘルスチェックの設定がないため、問題の要件を満たしません。

正解の理由:

選択肢 B は、Route 53のフェイルオーバールーティングを使用して2つのリージョン間で自動的にトラフィックを切り替え、アプリケーションの可用性と災害復旧の要件を満たします。さらに、Auto ScalingやALBを活用することで、トラフィックの増減に柔軟に対応でき、スケーラブルかつ高可用性を維持できます。

結論:

正解は B です。

346-AWS SAP AWS 「理論・実践・一問道場」MSMQ SQS

理論

1. コンテナ化されたアプリケーションのオーケストレーション

Amazon ECS (Elastic Container Service) や Amazon EKS (Elastic Kubernetes Service) は、コンテナ化されたアプリケーションを管理するためのサービスです。これらのサービスは、コンテナのデプロイ、スケーリング、管理を簡素化し、複雑なアプリケーションのオーケストレーションを実現します。

ECS (Fargate) はサーバーレスオプションで、インフラ管理を不要にし、リソース管理を抽象化しますが、複雑な設定や完全な制御を必要とする場合は ECS (EC2) が適しています。これにより、インフラやネットワークの設定をフルコントロールできます。

2. データベースの選択

Amazon RDS (Relational Database Service) は、フルマネージドなリレーショナルデータベースサービスで、SQL Server、MySQL、PostgreSQL などのデータベースエンジンをサポートしています。レガシーの Microsoft SQL Server を使用している場合、AWS での移行をサポートするために RDS for SQL Server が適しています。

Amazon Aurora は、MySQL と PostgreSQL の互換性があり、高速でスケーラブルなリレーショナルデータベースです。Aurora は大規模なデータベースアプリケーションに最適で、従来の SQL Server の要件に合致する場合があります。

3. メッセージング

Amazon SQS (Simple Queue Service) は、非同期メッセージングのためのフルマネージドサービスで、メッセージキューにメッセージを送信し、処理を分散させることができます。MSMQ（Microsoft Message Queueing）の代替として広く使用されます。

SNS (Simple Notification Service) は、パブリッシュ/サブスクライブ型のメッセージングサービスで、リアルタイムの通知やメッセージングに使用されます。MSMQ の代替には不適切な場合が多いですが、通知型のメッセージングシステムに有用です。

4. AWS Fargate vs. EC2

Fargate はコンテナの実行基盤を抽象化し、インフラストラクチャの管理を不要にします。簡単にコンテナをスケールできる一方で、細かいネットワーク設定やホスト管理が必要な場合は EC2 が有利です。特に、ネットワークの完全な制御やホストのカスタマイズが求められる場合、EC2 上で ECS を使うほうが適切です。

5. AWS のアーキテクチャ設計

分散アーキテクチャ を設計する際、データベースの選択やコンテナのオーケストレーションに加えて、アプリケーションのスケーラビリティや可用性を確保するために、負荷分散や自動スケーリング、フェイルオーバーの設計が重要です。例えば、ALB (Application Load Balancer) と Auto Scaling を組み合わせることで、アプリケーションの耐障害性を高め、負荷に応じて自動的にスケールします。

これらの概念を理解し、適切なAWSサービスを選択することが、効果的なアーキテクチャ設計に繋がります。

実践

略

一問道場

問題 #346

ある企業は、複数の .NET Framework コンポーネントで構成されたレガシーアプリケーションを運用しています。これらのコンポーネントは、同じ Microsoft SQL Server データベースを共有し、Microsoft Message Queueing (MSMQ) を使用して非同期に通信します。企業は AWS に移行するために、コンテナ化された .NET Core コンポーネントにアプリケーションをリファクタリングすることを計画しています。.NET Core コンポーネントには複雑なオーケストレーションが必要です。企業はネットワーキングとホストの設定に完全な制御を持つ必要があります。アプリケーションのデータベースモデルは強いリレーショナルです。

どのソリューションがこの要件を満たすでしょうか？

A. .NET Core コンポーネントを AWS App Runner でホストします。データベースを Amazon RDS for SQL Server でホストします。非同期メッセージングには Amazon EventBridge を使用します。

B. .NET Core コンポーネントを Amazon Elastic Container Service (Amazon ECS) で AWS Fargate 起動タイプを使用してホストします。データベースを Amazon DynamoDB でホストします。非同期メッセージングには Amazon Simple Notification Service (Amazon SNS) を使用します。

C. .NET Core コンポーネントを AWS Elastic Beanstalk でホストします。データベースを Amazon Aurora PostgreSQL Serverless v2 でホストします。非同期メッセージングには Amazon Managed Streaming for Apache Kafka (Amazon MSK) を使用します。

D. .NET Core コンポーネントを Amazon Elastic Container Service (Amazon ECS) で Amazon EC2 起動タイプを使用してホストします。データベースを Amazon Aurora MySQL Serverless v2 でホストします。非同期メッセージングには Amazon Simple Queue Service (Amazon SQS) を使用します。

解説

この問題は、企業がレガシーの .NET Framework アプリケーションを AWS に移行し、コンテナ化された .NET Core アプリケーションとしてリファクタリングする際の最適なアーキテクチャを選択するものです。

要件として、以下が挙げられています：

.NET Core コンポーネントの複雑なオーケストレーション：コンテナ化とそのオーケストレーションが必要。

ネットワーキングとホスト設定の完全な制御：ネットワークやインフラの設定に対する柔軟な制御。

リレーショナルなデータベースモデル：既存の Microsoft SQL Server データベースのモデルに基づいた解決策が求められています。

各選択肢についての評価：

A. AWS App Runner + RDS for SQL Server + EventBridge

AWS App Runner はコンテナ化されたアプリケーションを簡単にデプロイできますが、複雑なオーケストレーションに対応するためには、AWS ECS の方が適しています。また、EventBridge はイベント駆動型アーキテクチャに適していますが、非同期メッセージングには他の選択肢がより適しています。

このオプションは要件に完全には合致しません。

B. ECS (Fargate) + DynamoDB + SNS

Amazon ECS (Fargate) はコンテナオーケストレーションに非常に適していますが、DynamoDB はリレーショナルデータベースではなく、ノーSQLデータベースであるため、既存の Microsoft SQL Server の強いリレーショナルモデルには合いません。SNS は非同期メッセージングには使えますが、同様に MSMQ の代替としては不適切です。

この選択肢も適していません。

C. Elastic Beanstalk + Aurora PostgreSQL + MSK

Elastic Beanstalk は簡単にアプリケーションをデプロイできますが、Aurora PostgreSQL はリレーショナルデータベースとして適しているものの、既存の SQL Server との互換性や要件を満たすかが疑問です。Amazon MSK はストリームデータに特化しており、MSMQ による非同期メッセージングには不向きです。

このオプションは不適切です。

D. ECS (EC2) + Aurora MySQL + SQS

Amazon ECS (EC2) は、ネットワーク設定やホスト構成に完全な制御を持ち、複雑なオーケストレーションにも対応します。また、Aurora MySQL はリレーショナルデータベースとして適切で、既存の SQL Server の要件を満たします。Amazon SQS は、非同期メッセージングに適しており、MSMQ の代替として問題なく使用できます。

この選択肢は、すべての要件を満たし、最適な解決策となります。

結論：

最適な解決策は D. ECS (EC2) + Aurora MySQL + SQS です。

347-AWS SAP AWS 「理論・実践・一問道場」プレースメントグループ

理論

プレースメントグループとは？

Amazon EC2のプレースメントグループは、EC2インスタンスを配置するための方法を定義する機能で、次の3つのタイプがあります：

クラスタープレースメントグループ（Cluster Placement Group）

インスタンスを同じ物理ホストに配置し、高速なインスタンス間通信を実現するために使用されます。低レイテンシの通信が必要な場合に有効ですが、インスタンス数が増えると物理リソースの制約により容量不足になることがあります。

用途: 高性能なコンピューティングや、大規模なデータ処理に最適です。

スプレッドプレースメントグループ（Spread Placement Group）

インスタンスを異なる物理ホストに分散して配置します。これにより、単一のハードウェア障害がシステム全体に影響を与えるリスクを最小限に抑えます。

用途: 可用性を高めるために、インスタンスを複数の物理ホストに分散して配置したい場合に適しています。特に単一障害点を排除したいシステムに向いています。

パーティションプレースメントグループ（Partition Placement Group）

同じリージョン内でインスタンスを複数のパーティションに分割し、各パーティション内でインスタンスを配置します。これにより、パーティション内での障害が他のパーティションに影響を与えないようにすることができます。

用途: 大規模な分散データベースや、複数のインスタンスが同時に故障するリスクを減らしたいシステムに向いています。

プレースメントグループの容量不足の問題

プレースメントグループで「容量不足」のエラーが発生する場合、主に次のような原因が考えられます：

リソースの制約: クラスタープレースメントグループでは、同じ物理ホストにインスタンスを配置するため、ホストのリソース（CPU、メモリ、ネットワーク帯域など）の上限に達すると、新しいインスタンスを追加できなくなります。

インスタンス数の制限: 特定のプレースメントグループでは、インスタンス数に制限があります。特に、クラスタープレースメントグループでは、一部のインスタンスタイプにおいて、特定のホストに配置できるインスタンス数が制限されています。

トラブルシューティング方法

インスタンスの再起動:

インスタンスを停止して再起動することで、物理ホスト上のリソースが解放され、他のインスタンスを追加できる場合があります。クラスタープレースメントグループ内のインスタンスが別のホストに配置されることにより、新しいインスタンスを追加するための容量が確保されることがあります。

スプレッドプレースメントグループの利用:

容量不足がクラスタープレースメントグループに関連している場合、スプレッドプレースメントグループに変更することで、インスタンスを複数のホストに分散させることができ、リソース不足を回避できます。

インスタンスタイプの変更:

容量不足が発生している場合、使用するインスタンスタイプを変更することで、より多くのリソースを利用できる可能性があります。また、異なるインスタンスタイプを選択することで、リソースの最適化が図れる場合があります。

まとめ

EC2のプレースメントグループに関する知識を深め、インスタンスの配置方法や制限を理解することは、システムをスケールさせる際に非常に重要です。特に、クラスタープレースメントグループを使用している場合、リソースの制約によって容量不足のエラーが発生することがあるため、インスタンスを再起動するか、プレースメントグループの種類を変更することで、問題を解決することができます。

実践

略

一問道場

ソリューションアーキテクトは、単一のアベイラビリティゾーン内で複数のAmazon EC2インスタンスをプレースメントグループに展開しました。システムへの負荷が増加したため、ソリューションアーキテクトはプレースメントグループに新しいインスタンスを追加しようとしましたが、容量不足のエラーが発生しました。

この問題をトラブルシューティングするためにソリューションアーキテクトは何をすべきですか？

A. スプレッドプレースメントグループを使用する。各アベイラビリティゾーンに対して最小8インスタンスを設定する。

B. プレースメントグループ内のすべてのインスタンスを停止して再起動し、その後、再度インスタンスを起動してみる。

C. 新しいプレースメントグループを作成し、新しいプレースメントグループを元のプレースメントグループと統合する。

D. 追加のインスタンスをプレースメントグループ内の専用ホストとして起動する。

解説

この問題は、プレースメントグループ内で新しいインスタンスを追加しようとした際に「容量不足」のエラーが発生した場合のトラブルシューティングについてです。

プレースメントグループとは？

Amazon EC2のプレースメントグループは、インスタンスの配置方法を制御する機能で、以下の3種類があります：

クラスタープレースメントグループ: 低レイテンシのインスタンス間通信を実現するために、同じ物理ホスト上にインスタンスを配置します。リソースに対する需要が高くなると、インスタンス追加時に容量不足のエラーが発生する可能性があります。

スプレッドプレースメントグループ: インスタンスを異なる物理ホストに分散させることで、ハードウェア障害に対する耐障害性を高めます。リソース不足のエラーを回避しやすいです。

リムーバブルプレースメントグループ: 主にインスタンスを削除可能なハードウェアで展開するため、リソースのフレキシビリティを提供します。

トラブルシューティング

容量不足のエラーが発生する理由としては、クラスタープレースメントグループに新しいインスタンスを追加する際に、同じ物理ハードウェア上にインスタンスを配置するため、リソースが足りなくなることが考えられます。このような場合には、以下の解決策が有効です：

正解: B - プレースメントグループ内のすべてのインスタンスを停止して再起動し、その後、再度インスタンスを起動してみる

説明: インスタンスを停止して再起動することで、リソースが再調整され、新たに追加するインスタンスに対して利用可能な容量を解放できる可能性があります。再起動後にインスタンスが別の物理ホストに配置される場合があり、これによってリソース不足の問題が解消されることがあります。

他の選択肢について

A: スプレッドプレースメントグループを使用することは、クラスタープレースメントグループでリソースが不足している場合の解決策として有効です。これによりインスタンスが複数の物理ホストに分散され、容量不足の問題が解決される可能性があります。しかし、最低8インスタンスを設定するという記述は不必要です。

C: 新しいプレースメントグループを作成して統合することはできません。プレースメントグループは、インスタンスの起動時に設定するものであり、すでに起動しているインスタンスを別のプレースメントグループに移動することはできません。

D: 専用ホストでインスタンスを起動することは、物理ホストに対するより細かい制御を提供しますが、必ずしも容量不足の問題を解決するわけではありません。専用ホストは特定の使用ケース（例えば、ライセンス要件がある場合など）で有効ですが、プレースメントグループ内のリソース不足問題には直接対応しません。

まとめ

Bが最も適切な解決策です。インスタンスを再起動することで、新しいインスタンスを追加するためのリソースを解放できる可能性が高くなります。

348-AWS SAP AWS 「理論・実践・一問道場」ALB

理論

1. Auto Scalingとインスタンスの置き換え

Auto Scalingグループは、負荷に応じてインスタンスの数を自動的に増減させます。新しいインスタンスが必要な場合、Auto Scalingは定義された**AMI（Amazon Machine Image）**を使用して新しいインスタンスを起動します。

セキュリティパッチを適用したAMIを利用することが重要で、もし元のAMIが古い場合、新しいインスタンスに適用されない場合があります。

2. Elastic Load Balancer (ALB) とヘルスチェック

ALBはアプリケーションレベルの負荷分散を行い、インスタンスの健康状態を監視します。ターゲットグループに設定されたインスタンスが正常に動作していない場合、ALBはそのインスタンスをターゲットグループから外し、正常なインスタンスにトラフィックを送ります。

ヘルスチェックは、通常、HTTPレスポンスコードや指定したパス（例えば、/healthcheck）で判断します。これにより、インスタンスがトラフィックを受け入れられる状態かを確認できます。

3. セキュリティパッチの管理

インスタンスのセキュリティパッチが必要な場合、手動で適用することもできますが、自動化されたプロセスを設定することが推奨されます。AWS Systems Managerなどを利用して、定期的にインスタンスのパッチを適用する自動化スクリプトを作成できます。

セキュリティパッチを適用する際、インスタンスの再起動が必要な場合があり、その際にインスタンスが置き換えられ、未パッチのインスタンスが削除されることを避けるために、インスタンスのリフレッシュやAMIの更新が重要です。

4. インスタンスの更新とリフレッシュ

Auto Scalingインスタンスの更新には、インスタンスリフレッシュを活用できます。これにより、指定された間隔で新しいインスタンスが起動し、古いインスタンスが削除されます。これを定期的に行うことで、常に最新の状態を保ちながら、ダウンタイムを最小限に抑えられます。

Launch ConfigurationまたはLaunch Templateの変更がある場合、新しいAMIを指定して、それに基づく新しいインスタンスをデプロイすることが重要です。

5. Auto Scalingの戦略

Auto Scalingグループでは、インスタンスの停止と再起動が発生することがありますが、特にセキュリティ更新に関しては、手動でのパッチ適用がリスクを伴うことがあるため、事前にスケジュールされたメンテナンスウィンドウを設定し、インスタンスの更新が円滑に行われるようにします。

インスタンスのロールアウトとロールバックがスムーズに行えるように、ターゲットグループのヘルスチェックや、AMIのパッチ適用手順を整えることが重要です。

これらの知識を使って、アプリケーションの可用性やセキュリティを確保しながら、リソースの管理を効率的に行うことができます。

実践

略

一問道場

企業は、インフラストラクチャをコード（IaC）で利用して、2つのAmazon EC2インスタンスのセットをプロビジョニングしています。これらのインスタンスは数年間変更されていませんでしたが、企業のビジネスはここ数ヶ月で急成長しました。それに対応するため、オペレーションチームは急激なトラフィックの増加を管理するためにAuto Scalingグループを実装しました。企業のポリシーでは、すべてのオペレーティングシステムに毎月セキュリティ更新をインストールする必要があります。最近のセキュリティ更新では再起動が必要で、その結果、Auto Scalingグループはインスタンスを終了し、新しいパッチが適用されていないインスタンスで置き換えられました。

この問題が再発しないようにするために、ソリューションアーキテクトが推奨するべき手順の組み合わせはどれですか？（2つ選んでください。）

A. Auto Scalingグループを変更し、更新ポリシーを設定して最も古い起動設定を置き換え対象に設定する。

B. 次のパッチメンテナンス前に新しいAuto Scalingグループを作成します。メンテナンスウィンドウ内で、両方のグループをパッチしてインスタンスを再起動します。

C. Auto Scalingグループの前にElastic Load Balancerを作成し、ターゲットグループのヘルスチェックがAuto Scalingグループが終了したインスタンスを置き換えた後に正常な状態を返すことを確認するモニタリングを設定します。

D. 自動化スクリプトを作成してAMIをパッチし、起動設定を更新してAuto Scalingインスタンスリフレッシュを呼び出します。

E. Auto Scalingグループの前にElastic Load Balancerを作成し、インスタンスに対して終了保護を設定します。

解説

この問題の解説をします。

問題は、会社が自動スケーリンググループ（Auto Scaling Group）を使ってトラフィックの増加に対応している際に、最近のセキュリティ更新によりインスタンスが再起動された結果、セキュリティパッチが適用されていない新しいインスタンスが置き換えられてしまうという事態が発生したことについての対応策を問うものです。

問題の背景：

セキュリティ更新の一環としてインスタンスを再起動する必要がありました。

その結果、Auto Scalingグループがインスタンスを終了し、新しいインスタンスを起動したところ、新しいインスタンスにパッチが適用されていない状態でした。

会社のポリシーでは、毎月セキュリティ更新が必要であり、それによるダウンタイムを避ける必要があります。

選択肢の分析：

C. Auto Scalingグループの前にElastic Load Balancer（ELB）を作成し、ターゲットグループのヘルスチェックが正常に戻ることを確認するように監視を構成する

ELB（Elastic Load Balancer） は、インスタンスの負荷分散を行い、複数のインスタンスが正常に動作していることを確認します。Auto Scalingグループがインスタンスを置き換えた際、ELBは新しいインスタンスのヘルスチェックを行い、正常に機能しないインスタンスはトラフィックを受け取らないようにします。

ヘルスチェックは、新しいインスタンスが正常に動作しているかを確認するために重要です。これにより、セキュリティパッチが適切に適用されたインスタンスのみがサービスを提供し、問題が発生した場合には自動的に異常を検出して対処できるようになります。

D. AMIにパッチを適用し、起動設定を更新し、Auto Scalingインスタンスの更新を呼び出す自動スクリプトを作成する

AMI（Amazon Machine Image） にパッチを適用することで、常に最新のセキュリティパッチがインスタンスに反映された状態で起動されるようにします。Auto Scalingグループのインスタンスが新しく起動される際に、常に最新のAMIを使用して起動されるため、セキュリティ更新を手動で適用する必要がありません。

自動スクリプトを使用して、パッチを適用した後にAMIを更新し、Auto Scalingインスタンスの更新をトリガーすることで、定期的なパッチ適用と新しいインスタンスへの適用を自動化できます。この自動化により、手動での管理やミスが減少します。

まとめ：

これらの手順を組み合わせることで、セキュリティ更新を管理し、ダウンタイムを避けつつ、常に最新の状態でインスタンスを運用することができます。

Cの選択肢は、ヘルスチェックとELBを利用することで、新しいインスタンスが正常に機能していることを確認し、問題があれば早期に対応できるようにします。

Dの選択肢は、AMIの自動更新を行い、常に最新のパッチが適用された状態でインスタンスを運用できるようにする方法です。

これらの方法を実施することで、セキュリティパッチを効率よく適用し、Auto Scalingグループのインスタンスが常に最新のセキュリティ更新を反映した状態で運用されることを保証できます。

349-AWS SAP AWS 「理論・実践・一問道場」AWS CodeArtifact

理論

1. VPC エンドポイントの利用

VPC エンドポイントは、インターネット経由ではなく、プライベートな AWS ネットワーク経由でサービスにアクセスするための方法です。これにより、セキュリティを強化し、インターネット接続が不要な環境を維持できます。以下の AWS サービスで VPC エンドポイントが利用可能です:

S3: オブジェクトストレージへのアクセスをインターネットを介さずに行える。

DynamoDB: NoSQL データベースへのアクセスをインターネット経由せずに行える。

SageMaker: マシンラーニング関連のサービスにプライベートな接続が可能。

2. AWS CodeArtifact

AWS CodeArtifact は、ソフトウェア開発用のパッケージ管理サービスで、Java、Python、JavaScript などのパッケージを管理できます。CodeArtifact は、PyPi や npm などの外部パッケージリポジトリと接続でき、これにより、インターネットから隔離された環境で、公開リポジトリのパッケージを安全に使用できます。具体的には、以下の利点があります:

パッケージのプライベートリポジトリ管理: 開発チームが必要とするパッケージを AWS 内で管理でき、セキュリティリスクを減らせます。

外部接続設定: CodeArtifact では外部の公開リポジトリ（例: PyPi）と接続でき、インターネットからの隔離を維持しつつ、必要なパッケージを利用可能にします。

3. セキュアなネットワークアーキテクチャ

インターネットアクセスを制限することはセキュリティのベストプラクティスとされています。特に、以下の方法でセキュリティが強化されます:

VPC の隔離: VPC でインターネットゲートウェイや NAT ゲートウェイを使わずに、サービス間の通信をプライベートに保つ。

ネットワーク ACL とセキュリティグループ: これらを使って、必要なサービスだけが通信できるように制限します。

プライベートリンクと VPC エンドポイント: インターネットアクセスなしで外部 AWS サービスにアクセスするための方法として利用されます。

4. パッケージ管理と依存関係の管理

多くのアプリケーションは、開発や運用の中で外部の依存パッケージを利用します。これらのパッケージは、インターネット経由で取得されることが多いため、インターネットにアクセスできない環境では、パッケージの取得方法を工夫する必要があります。AWS CodeArtifact や CodeCommit などを使用することで、プライベートで安全なパッケージ管理が可能になります。

5. インターネット接続なしで外部リポジトリを利用する

インターネット接続が不要な環境でも、外部リポジトリ（例えば PyPi）を利用するために AWS 内でプライベートなリポジトリを作成し、外部リポジトリからパッケージを同期する方法が有効です。これにより、開発環境が外部と接続しなくても必要なパッケージを利用でき、セキュリティリスクを最小限に抑えられます。

結論:

インターネット接続なしで外部パッケージを利用するためには、AWS CodeArtifact のようなパッケージ管理サービスと VPC エンドポイント を活用することが重要です。この方法を使用すると、インターネット経由ではなく、AWS 内でプライベートにパッケージを利用できるため、安全かつ効率的に管理できます。

実践

略

一問道場

問題 #349

データサイエンティストのチームは、Amazon SageMaker インスタンスと SageMaker API を使用して機械学習（ML）モデルをトレーニングしています。SageMaker インスタンスはインターネットへのアクセスがない VPC に展開されています。ML モデルのトレーニングに使用するデータセットは Amazon S3 バケットに保存されています。インターフェイス VPC エンドポイントを使用して Amazon S3 と SageMaker API にアクセスしています。

データサイエンティストは、Python パッケージインデックス（PyPi）リポジトリにアクセスして、ワークフローの一部として使用する Python パッケージを更新する必要があります。ソリューションアーキテクトは、SageMaker インスタンスがインターネットから隔離されたまま、PyPi リポジトリへのアクセスを提供しなければなりません。

どの解決策がこの要件を満たすでしょうか？

A. 必要なパッケージごとに AWS CodeCommit リポジトリを作成し、PyPi リポジトリと CodeCommit リポジトリ間でコード同期を設定します。CodeCommit のために VPC エンドポイントを作成します。

B. VPC に NAT ゲートウェイを作成し、インターネットへのアクセスを許可するために VPC ルートを設定します。ネットワーク ACL を設定して、PyPi リポジトリエンドポイントへのアクセスのみを許可します。

C. VPC に NAT インスタンスを作成し、インターネットへのアクセスを許可するために VPC ルートを設定します。SageMaker ノートブックインスタンスのファイアウォールルールを設定して、PyPi リポジトリエンドポイントへのアクセスのみを許可します。

D. AWS CodeArtifact ドメインとリポジトリを作成し、CodeArtifact リポジトリに対して外部接続（public:pypi）を追加します。Python クライアントを設定して CodeArtifact リポジトリを使用するようにします。CodeArtifact のために VPC エンドポイントを作成します。

解説

この問題では、SageMaker インスタンスがインターネットアクセスなしで VPC 内で動作しており、PyPi リポジトリにアクセスする必要があるという要件です。SageMaker インスタンスがインターネットから隔離されたまま PyPi リポジトリにアクセスする方法を考える必要があります。

正解は D です。

解説：

AWS CodeArtifact は、パブリックの Python パッケージリポジトリ（PyPi）にアクセスできるプライベートなリポジトリを提供します。この方法では、PyPi リポジトリを直接インターネット経由でアクセスせず、AWS 内の CodeArtifact リポジトリを通じて PyPi のパッケージを取得できます。

外部接続（public:pypi） を設定することで、PyPi リポジトリへの接続が CodeArtifact を通じて行われ、インターネットアクセスが不要になります。

VPC エンドポイントを使うことで、インターネットを経由せずに AWS 内部での通信が可能となり、セキュリティ要件を満たしつつ、PyPi パッケージの利用ができます。

他の選択肢の解説:

A. AWS CodeCommit を使って、必要なパッケージごとにリポジトリを作成するというアプローチですが、PyPi のリポジトリ全体を同期するわけではなく、また CodeCommit はあくまでソースコード管理用のサービスです。パッケージ管理には適していません。

B. NAT ゲートウェイを使ってインターネット接続を許可する方法ですが、SageMaker インスタンスがインターネットアクセスを持つことになり、隔離された環境という要件を満たしません。

C. NAT インスタンスを使う方法も、NAT ゲートウェイと同様にインターネットアクセスを許可してしまうため、セキュリティ的な要件を満たさない可能性があります。また、ファイアウォールルールでアクセスを制限する手段は実装が煩雑になりがちです。

まとめ:

SageMaker インスタンスをインターネットから隔離したままで PyPi リポジトリを利用するために最適な方法は、D のように AWS CodeArtifact を利用することです。

350-AWS SAP AWS 「理論・実践・一問道場」DLM

理論

1. Amazon Elastic Block Store (EBS) スナップショットとは

EBS スナップショットは、EBS ボリュームの状態を保存したバックアップです。スナップショットを利用することで、ボリュームの復元や複製が可能になります。これらは Amazon S3 に保存されますが、EBS ボリュームとは異なり、オブジェクトストレージとして管理されます。

2. 災害復旧要件

災害復旧では、通常、システムが稼働し続けるために、重要なデータのバックアップを複数の場所に保存することが求められます。AWS では、バックアップデータを異なるリージョンに保持することができ、これにより一つのリージョンに障害が発生しても、他のリージョンでデータを復旧できるようになります。

3. Amazon Data Lifecycle Manager (DLM)

Amazon DLM は EBS スナップショットを自動化するツールです。スナップショットの作成、保存、削除のライフサイクルを管理でき、定期的なバックアップの実行やリージョン間でのスナップショットのコピーが可能です。

DLM を使用して、指定したポリシーに基づいてスナップショットを作成し、そのスナップショットを他のリージョンにコピーすることができます。

4. Amazon S3 クロスリージョンレプリケーション (CRR)

S3 CRR は、S3 バケット間でデータを自動的にコピーする機能ですが、EBS スナップショットに対して直接使用することはできません。EBS スナップショットはオブジェクトではないため、S3 CRR は適用できません。

5. 災害復旧のための運用最適化

災害復旧要件を満たすためには、できるだけ運用オーバーヘッドを減らす必要があります。AWS では、Amazon DLM や AWS Backup などのサービスを使用してバックアップを自動化し、最小限の管理作業で復旧を行えるようにすることが推奨されています。

6. AWS Backup と他のサービス

AWS Backup はバックアップサービス全般を提供しますが、EBS スナップショットのコピー機能に特化しているわけではありません。また、AWS Backup の主な目的はバックアップのポリシー管理であり、リージョン間のスナップショットのコピーに関しては他のサービス（例: DLM）が適しています。

7. バックアップ戦略

災害復旧を確実に行うためには、以下の戦略が考えられます：

リージョン間バックアップ：EBS スナップショットを複数のリージョンに保存することで、障害時に迅速に復旧できるようにする。

バックアップの自動化：DLM などのツールを使用して、バックアッププロセスを自動化し、定期的なバックアップを管理する。

最小運用オーバーヘッド：手動での管理作業を減らすため、すべてのバックアップと復旧のプロセスを自動化する。

まとめ：

災害復旧のためには、AWS で EBS スナップショットを複数のリージョンに保存することが重要です。Amazon DLM を利用することで、スナップショットの自動化とリージョン間コピーを効率的に管理でき、運用オーバーヘッドを最小限に抑えつつ、要件を満たすことができます。

実践

略

一問道場

質問 #350

あるソリューションアーキテクトが、厳格な災害復旧要件がある政府機関で働いています。この機関では、すべての Amazon Elastic Block Store (Amazon EBS) スナップショットを少なくとも2つの追加の AWS リージョンに保存する必要があります。また、運用上のオーバーヘッドはできるだけ低く抑える必要があります。

どのソリューションがこれらの要件を満たしますか？

A. Amazon Data Lifecycle Manager (Amazon DLM) でポリシーを設定し、毎日1回 EBS スナップショットを追加のリージョンにコピーする。

B. Amazon EventBridge を使用して、AWS Lambda 関数をスケジュールし、EBS スナップショットを追加のリージョンにコピーする。

C. AWS Backup を設定して EBS スナップショットを作成し、Amazon S3 クロスリージョンレプリケーションを使用して EBS スナップショットを追加のリージョンにコピーする。

D. Amazon EC2 Image Builder をスケジュールして、毎日1回 AMI を作成し、その AMI を追加のリージョンにコピーする。

解説

この問題の要点は、政府機関の災害復旧要件に従って、Amazon Elastic Block Store (EBS) スナップショットを少なくとも2つの追加リージョンに保存する方法を求めています。さらに、運用オーバーヘッドを最小限に抑えることが求められています。

選択肢を見ていきましょう：

A. Amazon Data Lifecycle Manager (Amazon DLM) でポリシーを設定し、毎日1回 EBS スナップショットを追加のリージョンにコピーする。

理由： DLM (Data Lifecycle Manager) は EBS ボリュームのスナップショットの作成、管理、削除を自動化するサービスです。これを使ってスナップショットの保存を自動化し、スナップショットを複数のリージョンにコピーするポリシーを設定できます。これにより、最小限の運用オーバーヘッドで要件を満たすことができます。

最適解： 運用の効率化と自動化を重視しているため、こちらが最適な選択肢です。

B. Amazon EventBridge を使用して、AWS Lambda 関数をスケジュールし、EBS スナップショットを追加のリージョンにコピーする。

理由： EventBridge と Lambda を使ってスナップショットをコピーすることも可能ですが、これには Lambda 関数の作成と運用が必要で、DLM に比べて管理がやや複雑になります。

運用オーバーヘッドが増えるため、最適な選択肢ではありません。

理由： AWS Backup はバックアップの管理には優れていますが、EBS スナップショットの直接的なリージョン間コピーをサポートするものではありません。S3 クロスリージョンレプリケーションは主にオブジェクトストレージに使用される技術であり、EBS スナップショットには適用できません。

不適切なソリューションです。

D. Amazon EC2 Image Builder をスケジュールして、毎日1回 AMI を作成し、その AMI を追加のリージョンにコピーする。

理由： EC2 Image Builder を使って AMI（Amazon Machine Image）を作成する方法もありますが、これは主に EC2 インスタンスのイメージを管理するためのものです。EBS スナップショットの要件を満たすためには、適切な方法ではありません。

不適切な選択肢です。

結論：

最も運用オーバーヘッドを低減し、災害復旧要件を満たすのは A の選択肢です。Amazon DLM は EBS スナップショットの管理を自動化し、ポリシー設定により追加リージョンへのコピーも容易に行えます。