type
status
date
slug
summary
tags
category
icon
password
书籍
141-SQSの可視性タイムアウト
理論
AWSでのメッセージ処理における重要な知識
1. SQSの可視性タイムアウト
- メッセージが処理中の間、他のコンシューマーがそのメッセージを受信できない時間。
- 設定のポイント：
- 処理時間 + バッファ時間を考慮する。
- 短すぎると処理中のメッセージが再配信され、無駄な処理やエラーを引き起こす。
2. デッドレターキュー (DLQ)
- 処理できなかったメッセージを格納するキュー。
- 主な設定：
maxReceiveCount：メッセージをデッドレターキューに送るまでの再試行回数。- 高すぎると不要な処理が増加し、低すぎると正常な処理が妨げられる。
3. Auto Scalingとスケールイン保護
- Auto Scalingは負荷に応じてインスタンスを追加・削除。
- スケールイン保護：
- 処理中のインスタンスがスケールインで終了しないように保護。
- 長時間の処理タスクには必須。
4. トラブルシューティングの基本
- CloudWatch Logsやメトリクスで以下を確認：
- インスタンスのスケールイン/アウトのタイミング。
- メッセージの再試行履歴とDLQへの移動状況。
- アプリケーションログでの処理エラーの有無。
実践的な設定ポイント
- 可視性タイムアウトを処理時間に適した値（通常1.5倍程度）に設定。
- スケールイン保護を有効化し、処理中のインスタンスが終了しないようにする。
- DLQの監視を行い、問題が発生したメッセージを分析して根本原因を特定。
一問道場
問題 #141: AWSでのビデオ処理に関する問題
ある会社がAWSクラウドで動画を処理するため、Auto Scalingグループ内のAmazon EC2インスタンスを使用しています。
1本の動画の処理には30分かかり、Amazon Simple Queue Service (Amazon SQS)キュー内の動画数に応じてEC2インスタンスがスケールインおよびスケールアウトします。
設定内容
- SQSキューにリドライブポリシーを設定し、ターゲットのデッドレターキューと
maxReceiveCountを1に指定。
- SQSキューの可視性タイムアウトを1時間に設定。
- デッドレターキューにメッセージがある場合、Amazon CloudWatchアラームが開発チームに通知を送信。
発生している問題
1日に数回、デッドレターキューにメッセージが入り、動画が正常に処理されていないと通知が送られる。
しかし、アプリケーションのログにはエラーが記録されていない。
解決策を選択してください：
A. EC2インスタンスの終了保護を有効にする。
B. SQSキューの可視性タイムアウトを3時間に更新する。
C. 処理中のインスタンスにスケールイン保護を設定する。
D. リドライブポリシーを更新し、
maxReceiveCountを0に設定する。解説
背景となる問題
- 動画の処理には 30分 かかる。
- SQSキューの 可視性タイムアウト は 1時間 に設定されている。
- リドライブポリシーでは
maxReceiveCount= 1 が指定されている。
- デッドレターキューにメッセージが送られる条件は以下の通り：
- メッセージが指定回数（
maxReceiveCount）以上再処理された。 - メッセージが可視性タイムアウトの間に適切に処理されなかった。
現象：
- メッセージがデッドレターキューに移動しているが、アプリケーションログにエラーは記録されていない。
可能性：
- メッセージが正常に処理されず、再度受信される前に可視性タイムアウトが切れてしまう。
- スケールイン時に、処理中のEC2インスタンスが終了してしまい、動画の処理が中断される。
各選択肢の評価
A. EC2インスタンスの終了保護を有効にする
- 効果： EC2インスタンスの終了を防ぐ設定。
- 問題点： デッドレターキューの問題は、特定のインスタンスが終了することが原因とは断定できない。したがって、この選択肢は不十分です。
B. SQSキューの可視性タイムアウトを3時間に更新する
- 効果： 可視性タイムアウトを延長することで、処理が完了するまでメッセージが他のインスタンスに渡されるのを防ぐ。
- 問題点： 処理時間は30分であるため、1時間のタイムアウトは十分です。これ以上の延長は不要で、別の根本的な原因を特定する必要があります。
C. 処理中のインスタンスにスケールイン保護を設定する
- 効果： 処理中のEC2インスタンスがスケールインによって終了されるのを防ぐ。
- 適切性： 動画の処理中にインスタンスが終了すると、メッセージが再処理対象となり、デッドレターキューに移動する可能性が高まります。この設定は問題の原因を直接解決します。
D. リドライブポリシーを更新し、maxReceiveCountを0に設定する
- 効果： メッセージをデッドレターキューに即座に移動させる。
- 問題点： この設定では、動画が処理される前にメッセージがデッドレターキューに移動してしまうため、問題を悪化させます。
正解：C. 処理中のインスタンスにスケールイン保護を設定する
理由：
- スケールインによって処理中のインスタンスが終了し、動画の処理が中断されることで、メッセージが再処理されてデッドレターキューに移動する可能性があります。
- スケールイン保護を有効にすることで、処理中のインスタンスが誤って終了するのを防ぎ、問題を解決できます。
補足情報
- デッドレターキューの問題が完全に解消されない場合は、CloudWatch Logsでインスタンスの終了履歴やアプリケーションの状態を確認することで、さらなる原因特定を行う必要があります。
142-API
理論
AWSでのAPIセキュリティとプライベートアクセスに関する知識
AWSでAPIをセキュアかつ効率的に運用するには、適切な設計と設定が必要です。このセクションでは、特にAPI Gatewayを使用したプライベートAPIの構築に関連する重要な知識を解説します。
1. API Gatewayのエンドポイントタイプ
API Gatewayは以下の3種類のエンドポイントタイプを提供します：
- エッジ最適化 (Edge-Optimized):
- グローバルに分散されたCloudFrontエッジロケーションを利用。
- 世界中のユーザー向けに最適化。
- リージョナル (Regional):
- 特定のAWSリージョン内でエンドポイントを提供。
- 高速なレスポンスが必要な地域での使用に適している。
- プライベート (Private):
- VPC内からのみアクセス可能。
- 重要：完全にパブリックアクセスを排除し、セキュアなネットワーク環境での運用が可能。
2. VPCエンドポイントを使用したプライベートAPI
プライベートAPIをVPC内で利用するには、VPCエンドポイント (Interface VPC Endpoint) を設定します。
設定手順
- API Gatewayエンドポイントタイプの変更:
- API Gatewayのエンドポイントタイプを「プライベート」に設定。
- VPCエンドポイントの作成:
- AWSマネジメントコンソールまたはCLIを使用してVPCエンドポイントを作成。
- API Gatewayのエンドポイントサービスを選択。
- リソースポリシーの追加:
- 特定のVPCまたはサブネットからのアクセスを許可するポリシーを設定。
メリット
- APIへのアクセスをVPC内部に限定。
- パブリックインターネットを介さないため、セキュリティが向上。
- ネイティブな認証機能 (IAM, Cognito) と組み合わせ可能。
3. API認証と認可
すべてのAPIリクエストを認証されたユーザーに限定するため、以下のAWS認証メカニズムを活用します：
- AWS IAM:
- ロールやポリシーを使用してアクセス制御。
- APIキーや署名付きリクエストでセキュアに管理。
- Amazon Cognito:
- ユーザープールで認証を管理。
- アクセストークンをAPI Gatewayに渡して認証を実施。
- リソースポリシー:
- 特定のVPCやIPアドレス範囲にアクセスを制限。
- JSON形式で柔軟なポリシーを設定可能。
4. トラブルシューティングとベストプラクティス
- ネットワーク接続の確認:
- VPCエンドポイントとサブネットのルーティング設定を適切に構成。
- モニタリングとログ記録:
- CloudWatch Logsを有効化して、APIリクエストの詳細を確認。
- AWS X-Rayを使用して、APIのパフォーマンスやエラーの分析を行う。
- セキュリティの強化:
- 必要最低限のアクセス許可を付与（最小権限の原則）。
- SSL/TLSを必ず有効化。
まとめ
AWS API GatewayのプライベートエンドポイントとVPCエンドポイントを組み合わせることで、APIを完全にセキュアかつ内部専用に設計することが可能です。これにより、外部からの不要なアクセスを排除しつつ、認証されたユーザーによる利用を確実に管理できます。このアプローチは、セキュリティと効率性を両立させたい場合に非常に有効です。
一問道場
質問 #142
トピック 1
ある会社が、Regionalエンドポイントを使用したAmazon API GatewayでAPIを開発しました。これらのAPIは、API Gatewayの認証メカニズムを使用するAWS Lambda関数を呼び出します。デザインレビューの結果、いくつかのAPIがパブリックアクセスを必要としないことが判明しました。ソリューションアーキテクトは、これらのAPIをVPC内からのみアクセス可能にするソリューションを設計する必要があります。すべてのAPIは、認証されたユーザーによって呼び出される必要があります。
最小限の労力でこの要件を満たすソリューションはどれですか？
A. 内部のApplication Load Balancer (ALB) を作成します。ターゲットグループを作成し、呼び出すLambda関数を選択します。ALBのDNS名を使用してVPCからAPIを呼び出します。
B. API GatewayのAPIに関連付けられたDNSエントリを削除します。Amazon Route 53でホストゾーンを作成し、ホストゾーン内にCNAMEレコードを作成します。API GatewayのAPIをCNAMEレコードで更新し、VPC内からこのCNAMEレコードを使用してAPIを呼び出します。
C. API GatewayでAPIエンドポイントをRegionalからプライベートに更新します。VPC内にインターフェイスVPCエンドポイントを作成します。リソースポリシーを作成し、それをAPIにアタッチします。このVPCエンドポイントを使用して、VPC内からAPIを呼び出します。
D. Lambda関数をVPC内にデプロイします。EC2インスタンスをプロビジョニングし、Apacheサーバーをインストールします。このApacheサーバーからLambda関数を呼び出します。EC2インスタンスの内部CNAMEレコードを使用して、VPC内からAPIを呼び出します。
解説
正解: C
理由:
このシナリオでは、API GatewayのAPIをVPC内からのみアクセス可能にし、認証されたユーザーによる呼び出しを確保する必要があります。以下は選択肢の評価です。
選択肢 A: ALBを使用した方法
- 手順: 内部のApplication Load Balancer (ALB)を作成し、ターゲットグループとしてLambda関数を指定。ALBのDNS名を使用してAPIを呼び出す。
- 問題点: ALBをLambda関数のフロントエンドとして動作させるには、設定が複雑で追加のコストが発生する可能性があります。また、API Gatewayの機能を活用せず、APIの認証を簡単に処理することが難しくなります。
- 労力: 高い。LambdaとALBの統合設定が必要。
選択肢 B: Route 53を使用した方法
- 手順: API GatewayのDNSエントリを削除し、Route 53でCNAMEレコードを作成してAPIを呼び出す。
- 問題点: APIをVPC内部専用にすることはできません。この方法では、DNSレコードをVPC内でのみ利用可能にする機能がなく、APIのパブリックアクセス制限が不十分です。
- 労力: 中程度。
選択肢 C: プライベートエンドポイントを使用した方法 (正解)
- 手順: API GatewayのエンドポイントをRegionalからプライベートに更新し、VPCエンドポイントを作成してAPIにアクセス。認証やリソースポリシーで制限を追加。
- 利点:
- API Gatewayのネイティブな機能（認証やスケーラビリティ）を活用可能。
- プライベートエンドポイントを使用することで、APIへのアクセスをVPC内部に制限可能。
- 効率的かつ設定が比較的簡単。
- 労力: 最小限。API Gatewayの設定変更とVPCエンドポイントの作成のみ。
選択肢 D: EC2インスタンスを使用した方法
- 手順: Lambda関数をVPC内にデプロイし、EC2インスタンスから呼び出してAPIを構築。
- 問題点: EC2インスタンスの管理やApacheの設定が必要で、インフラストラクチャが複雑化する。また、API Gatewayの機能を十分に活用できない。
- 労力: 非常に高い。
結論
選択肢 C は、要件を満たすための最も簡潔かつ効果的なソリューションです。プライベートエンドポイントとリソースポリシーを使用することで、VPC内部からのみアクセス可能なAPIを簡単に設定できます。また、API Gatewayの認証機能もそのまま利用可能です。
143-Lambda@EdgeS3クロスリージョンレプリケーション
理論
AWSでのパフォーマンス最適化に関連する知識
1. クロスリージョンレプリケーション（S3 Cross-Region Replication）
- 目的: データを別のAWSリージョンに同期し、地理的に近い場所からアクセスを可能にすることで、レイテンシを削減。
- 特徴:
- データの冗長性向上（災害復旧対策としても有効）。
- パフォーマンス向上（ユーザーの地理的な位置に基づくデータ提供）。
- 前提条件:
- バージョニングを有効化する必要がある。
- S3バケット間でIAMロールを使った権限設定が必要。
2. Lambda@Edgeを使ったリクエストルーティング
- 目的: CloudFrontディストリビューション内でリクエストを動的にルーティングし、最適なオリジンやエンドポイントに接続。
- 活用例:
- 地域別に最適なS3バケットを選択。
- 認証やカスタムレスポンスの実装。
- 利点:
- グローバルユーザーに対してパフォーマンスを向上。
- エッジロケーションでのリアルタイム処理によりレイテンシ削減。
3. CloudFrontのキャッシュとエッジ最適化
- 役割: 静的コンテンツ（HTML、画像、動画など）をエッジロケーションにキャッシュし、ユーザーに迅速に配信。
- 適用例:
- 頻繁に更新されない静的データはCloudFrontキャッシュで高速化。
- 動的リクエストはバックエンドにルーティングし、Lambda@Edgeで処理をカスタマイズ。
4. ユーザーの地理的位置に基づくアプローチの選択
- 地理的に分散したユーザーがいる場合：
- クロスリージョンレプリケーションでデータを近くのリージョンに配置。
- CloudFrontでリクエストをキャッシュし、エッジ最適化を活用。
- 高頻度で更新されるデータの場合：
- CloudFrontとLambda@Edgeを組み合わせて動的ルーティングを実現。
5. AWSでの効率的なデザインの基本原則
- ユーザーの地理的な分布を考慮する。
- 必要に応じてリージョン間のデータ同期を活用する。
- エッジサービス（CloudFrontやLambda@Edge）を活用してレイテンシを最小化。
- 費用対効果とパフォーマンスのバランスを考慮してソリューションを選択する。
一問道場
Question #143
Topic 1
ある気象サービスが、AWSの eu-west-1 リージョンでホストされているWebアプリケーションを通じて、高解像度の気象地図を提供しています。
気象地図は頻繁に更新され、静的HTMLコンテンツとともにAmazon S3に保存されています。WebアプリケーションはAmazon CloudFrontでフロントエンドを構成しています。
最近、この会社は us-east-1 リージョンでのサービス提供を拡大しましたが、新しいユーザーは、それぞれの気象地図の表示が時折遅くなると報告しています。
us-east-1でのパフォーマンス問題を解決するためのステップの組み合わせを選択してください。（2つ選択してください）
A. eu-west-1 にあるS3バケット用にAWS Global Acceleratorエンドポイントを設定します。us-east-1 でTCPポート80と443のエンドポイントグループを設定します。
B. us-east-1 に新しいS3バケットを作成します。S3クロスリージョンレプリケーションを設定して、eu-west-1 にあるS3バケットと同期します。
C. Lambda@Edgeを使用して、北米からのリクエストを us-east-1 のS3転送加速エンドポイントに変更します。
D. Lambda@Edgeを使用して、北米からのリクエストを us-east-1 のS3バケットに変更します。
E. us-east-1 のAWS Global AcceleratorエンドポイントをCloudFrontディストリビューションのオリジンとして設定します。Lambda@Edgeを使用して、北米からのリクエストを新しいオリジンに変更します。
解説
B. us-east-1 に新しいS3バケットを作成します。S3クロスリージョンレプリケーションを設定して、eu-west-1 にあるS3バケットと同期します。
D. Lambda@Edgeを使用して、北米からのリクエストを us-east-1 のS3バケットに変更します。
解説
- 選択肢B（S3クロスリージョンレプリケーション）
- クロスリージョンレプリケーションにより、us-east-1 にあるS3バケットにデータを複製することで、北米ユーザーが地理的に近いリージョンからデータを取得できます。これにより、レイテンシを大幅に削減可能です。
- 選択肢D（Lambda@Edgeでリクエストのリダイレクト）
- Lambda@Edgeを使用して、北米（us-east-1）のユーザーがS3データにアクセスする際、us-east-1 のバケットにリクエストをリダイレクトすることで、効率的にパフォーマンスを向上させることができます。
その他の選択肢について
- A. AWS Global Acceleratorの使用は、S3バケットへの直接アクセスには適していません。この構成では、CloudFrontを適切に活用できません。
- C. S3転送加速はファイルアップロードやダウンロードの高速化に役立ちますが、このシナリオではS3クロスリージョンレプリケーションのほうが適しています。
- E. CloudFrontとAWS Global Acceleratorを組み合わせる必要性はこのケースでは低く、Lambda@Edgeを使ったリクエスト処理が効率的です。
144-Amazon FSx for Windows File Server
理論
Amazon FSx for Windows File Serverの容量管理の本質
Amazon FSx for Windows File Serverは、企業向けにWindowsベースのファイルシステムを提供し、特に仮想デスクトップ環境（例えばAmazon WorkSpaces）やWindowsアプリケーションのストレージとして利用されます。ファイルシステムの容量管理は、ストレージのパフォーマンスと可用性を保つために非常に重要です。
容量のスケーリングと問題解決の本質
- ストレージ容量の拡張
FSx for Windows File Serverは、必要に応じて容量をスケールアップ（増加）できる機能を持っています。ユーザーが大量のデータを扱う場合やプロファイルストレージの容量が逼迫する場合、このスケーリング機能が役立ちます。容量を増加するには、
update-file-systemコマンドを使用し、ファイルシステムのサイズを動的に変更することができます。- 容量管理と監視の自動化
容量不足を未然に防ぐためには、ファイルシステムのストレージ使用状況を常に監視することが重要です。Amazon CloudWatchを利用することで、FSxのストレージ容量や使用状況をリアルタイムで監視できます。特に、
FreeStorageCapacityメトリクスを監視することで、容量不足が発生する前にアラームを設定し、適切に対処できます。- 自動的な容量増加の実現
CloudWatchアラームを設定し、それに基づいてAWS Lambdaを起動することで、容量が不足しそうになった際に自動的にストレージ容量を増加させることができます。これにより、手動での介入なしに、システムが自動的に最適化され、ダウンタイムを避けることができます。
- 容量増加の優先順位と効果
容量の不足は、ストレージが満杯になることでシステム全体のパフォーマンス低下を招きます。したがって、予防的な容量管理が重要です。容量を増加させる手段として、FSxの動的スケーリングを利用することが、最もシンプルで効果的な解決策です。他の方法（例: 複数のFSxファイルシステムを導入するなど）は運用が複雑になり、管理の手間が増えます。
本質的なアプローチ
ストレージ容量不足の問題に対して最も効果的なアプローチは、容量を適切にスケールアップすることです。また、リアルタイムで容量使用状況を監視し、容量が逼迫する前に自動的にスケーリングする仕組みを組み込むことが重要です。このようにして、システムの可用性とパフォーマンスを確保することができます。
結論
FSx for Windows File Serverにおける容量管理は、ストレージの自動スケーリング、CloudWatchによる監視、および自動化された容量増加の実装を通じて、効率的に行うことができる。この本質的なアプローチにより、将来の容量不足問題を防ぎ、安定した運用を実現することが可能です。
一問道場
質問 #144
トピック 1
ソリューションアーキテクトが、Amazon Workspacesで新しいセッションを確立できない問題を調査しています。初期分析によると、問題はユーザープロファイルに関係していることが判明しました。Amazon Workspaces環境は、プロファイル共有ストレージとしてAmazon FSx for Windows File Serverを使用するように設定されています。このFSx for Windows File Serverファイルシステムは、10 TBのストレージ容量で構成されています。
ソリューションアーキテクトは、ファイルシステムが最大容量に達していることを発見しました。ソリューションアーキテクトは、ユーザーが再びアクセスできるようにし、この問題が再発しないようにする必要があります。
要件を満たすソリューションはどれですか？
A. 古いユーザープロファイルを削除して空き容量を作成します。ユーザープロファイルをAmazon FSx for Lustreファイルシステムに移行します。
B.
update-file-system コマンドを使用して容量を増やします。Amazon CloudWatchのメトリクスで空き容量を監視します。Amazon EventBridgeを使用してAWS Lambda関数を呼び出し、必要に応じて容量を増加させます。C. Amazon CloudWatchで
FreeStorageCapacityメトリクスを使用してファイルシステムを監視します。AWS Step Functionsを使用して必要に応じて容量を増加させます。D. 古いユーザープロファイルを削除して空き容量を作成します。追加のFSx for Windows File Serverファイルシステムを作成します。50%のユーザーが新しいファイルシステムを使用するように、ユーザープロファイルのリダイレクトを更新します。
解説
解説
この問題では、Amazon FSx for Windows File Serverが最大容量に達し、新しいセッションを作成できなくなっているため、ストレージの不足を解決し、将来の再発を防ぐ必要があります。それぞれの選択肢について解説します。
A.
- 古いプロファイルを削除し、Amazon FSx for Lustreに移行する方法です。
- 問題点: FSx for Lustreは主に高速なデータ処理や分析用に設計されており、Workspacesのプロファイルストレージには適していません。また、移行作業は時間がかかり、ユーザーに即時のアクセスを提供できない可能性があります。
- 結論: 不適切。
B.
update-file-systemコマンドで容量を増やし、CloudWatchとEventBridgeで自動的に容量を監視・増加させる方法です。
- 利点: FSx for Windows File Serverはスケーリングが可能で、このアプローチは容量不足の根本的な原因を解消し、将来的な問題の再発を防ぐことができます。
- 結論: 適切。
C.
- CloudWatchの
FreeStorageCapacityメトリクスで容量を監視し、Step Functionsで必要に応じて容量を増加させる方法です。
- 問題点: Step Functionsを使用することで複雑性が増加しますが、FSxのスケーリングには直接関係しません。より直接的な方法が存在します。
- 結論: 不適切。
D.
- 古いプロファイルを削除して空き容量を作成し、新しいFSxファイルシステムを追加してユーザーを分散させる方法です。
- 問題点: 新しいファイルシステムの作成とユーザーのリダイレクトには手間がかかり、運用が複雑になります。また、現行のファイルシステムのスケーリング機能を活用していません。
- 結論: 不適切。
正解:
B.
この解決策は最も直接的かつ効率的であり、容量不足の問題を即座に解決し、将来的な再発を防ぐことができます。Amazon FSx for Windows File Serverのスケーリング機能を利用するのが最適です。
145-AWS Transfer Family FTP
理論
1. スケーラビリティの重要性
スケーラビリティとは、システムが増加するトラフィックやデータ量に対して、効率的にリソースを追加できる能力のことです。特に、トラフィックの増加やユーザー数の増加が見込まれるシステムでは、スケーラビリティを意識して設計することが非常に重要です。
- 単一のEC2インスタンスに依存する設計は、負荷が高まるとボトルネックが発生し、接続の遅延や失敗、システムダウンの原因となります。EC2インスタンスのスケーリングが不足するため、負荷が集中し、リソース消費が急増します。
- Auto Scalingグループを使うことで、需要に応じてインスタンスを自動的に増減させ、システム全体が拡張可能な設計にすることができます。
2. 耐障害性と冗長性
耐障害性は、システムが部分的な障害が発生した場合にも機能し続ける能力です。障害が発生した際に迅速に対応できる仕組みが必要です。
- FTPサーバーのような中央集権的なシステムは、単一障害点(SPOF: Single Point of Failure)となりやすいです。接続が切れるとファイルのアップロードに支障をきたし、システム全体が停止してしまう可能性があります。
- 分散型アーキテクチャ（例えば、S3やAWS Transfer Family）は冗長性が高く、障害発生時にもサービスが継続的に動作します。これにより、サービスの可用性が向上します。
3. ストレージの最適化と管理
ストレージは、アプリケーションのパフォーマンスに大きな影響を与える要素です。適切なストレージ設計を行うことで、効率的にデータを管理し、アクセス速度や可用性を向上させることができます。
- S3はスケーラブルで高可用性のあるオブジェクトストレージサービスであり、アップロードされるファイルが急増しても、自動的にリソースを増強して対応できます。
- FTPサーバーに依存すると、ストレージの容量や接続数の制限に直面します。これに対し、S3とイベント駆動型アーキテクチャ（例えば、S3イベント通知やAWS Lambda）を使用することで、ストレージ管理が効率化され、ファイル処理やメタデータの追加が自動化されます。
4. イベント駆動アーキテクチャ
イベント駆動型アーキテクチャは、アプリケーションの一部が特定のイベント（例えば、ファイルのアップロード）をトリガーとして、他の処理を自動的に実行する仕組みです。
- S3イベント通知を使用することで、ファイルがアップロードされるたびに自動でLambda関数を呼び出し、メタデータを追加したり、データベースを更新したりすることができます。これにより、手動での処理やエラーの発生を減らし、効率的なデータ処理が可能になります。
5. 運用の自動化と効率化
手動による運用はミスや遅延を引き起こすリスクが高いため、可能な限り自動化すべきです。AWSの各サービスは自動化のためのツール（例えば、LambdaやS3イベント通知）を提供しており、これを活用することで、システムの管理負担を軽減できます。
結論
- システム設計の本質的な考え方は、「スケーラビリティ」「耐障害性」「効率的なリソース管理」にあります。特に、ユーザー数の増加やデータ量の急増に備え、自動化と分散型アーキテクチャを活用することが求められます。
- FTPサーバーの代わりにS3とAWS Transfer Familyを使用することで、ストレージのスケーラビリティやデータ管理の効率化、障害発生時の耐性を向上させることが可能になります。また、Lambdaを活用したイベント駆動型の処理も、システム全体の効率化を実現します。
一問道場
質問 #145
トピック 1
ある国際配送会社がAWS上で配送管理システムをホストしています。ドライバーはシステムを使って配達確認をアップロードします。確認内容には受取人の署名または受取人と荷物の写真が含まれます。ドライバーのハンドヘルドデバイスは、FTPを通じて単一のAmazon EC2インスタンスに署名と写真をアップロードします。各ハンドヘルドデバイスは、サインインしたユーザーに基づいたディレクトリにファイルを保存し、ファイル名は配送番号に一致します。その後、EC2インスタンスは中央データベースにクエリを送信して配送情報を取得し、ファイルにメタデータを追加します。その後、ファイルはアーカイブ用にAmazon S3に配置されます。
会社の拡大に伴い、ドライバーはシステムが接続を拒否していると報告しています。FTPサーバーは切断された接続とメモリの問題により問題が発生しています。この問題に対処するため、システムエンジニアはEC2インスタンスを30分ごとに再起動するためのcronタスクをスケジュールしました。しかし、請求チームはファイルが常にアーカイブに保存されていないことと、中央システムが常に更新されていないことを報告しています。
ソリューションアーキテクトは、アーカイブが常にファイルを受け取り、システムが常に更新されることを確保するために、スケーラビリティを最大化するソリューションを設計する必要があります。ハンドヘルドデバイスは変更できないため、新しいアプリケーションの展開はできません。
どのソリューションがこの要件を満たすか？
A. 既存のEC2インスタンスのAMIを作成し、EC2インスタンスのオートスケーリンググループをアプリケーションロードバランサーの背後に作成します。オートスケーリンググループの最小インスタンス数を3に設定します。
B. AWS Transfer Familyを使用してFTPサーバーを作成し、ファイルをAmazon Elastic File System (Amazon EFS)に配置します。EFSボリュームを既存のEC2インスタンスにマウントし、EC2インスタンスに新しいパスを指し示すようにします。
C. AWS Transfer Familyを使用してFTPサーバーを作成し、ファイルをAmazon S3に配置します。S3イベント通知をAmazon Simple Notification Service (Amazon SNS)を通じて設定し、AWS Lambda関数を呼び出します。Lambda関数はメタデータを追加し、配送システムを更新します。
D. ハンドヘルドデバイスを更新して、ファイルを直接Amazon S3に配置します。S3イベント通知をAmazon Simple Queue Service (Amazon SQS)を通じて設定し、AWS Lambda関数を呼び出します。Lambda関数はメタデータを追加し、配送システムを更新します。
解説
この問題の解説をします。
背景
企業がデリバリー管理システムを使用して、ドライバーが配達確認書類（サインや荷物の写真）をアップロードします。ドライバーの手持ちデバイスがFTPを使って、これらのファイルをAmazon EC2インスタンスにアップロードし、後でS3にアーカイブされます。しかし、システムがスケーラビリティの問題に直面し、接続の切断やメモリの問題が発生しており、ファイルが必ずしもアーカイブされていないといった問題が発生しています。この問題を解決するために、スケーラビリティと信頼性を最大化する方法を選ぶ必要があります。
解決策の選択肢
以下の解決策から最適なものを選ぶ必要があります。
A. EC2インスタンスのAMIを作成し、Auto Scalingグループを設定して、最小3インスタンスを維持する。
B. AWS Transfer Familyを使ってFTPサーバーを作成し、Amazon EFSにファイルを保存する。EC2インスタンスでそのEFSをマウントし、新しいパスでファイルを処理する。
C. AWS Transfer Familyを使ってFTPサーバーを作成し、ファイルをAmazon S3に保存する。S3イベント通知を使って、Lambda関数を呼び出し、メタデータを追加して配達システムを更新する。
D. ハンドヘルドデバイスを更新して、直接Amazon S3にファイルを保存する。S3イベント通知を使って、SQSを呼び出し、Lambda関数を使ってメタデータを追加し配達システムを更新する。
正解は C です。
解説
- A. EC2インスタンスをスケーリングする方法は、システムのスケーラビリティに貢献しますが、根本的な問題である「FTPサーバーの接続問題」や「メモリの問題」を解決する方法ではありません。また、EC2インスタンスに依存することは、スケーラビリティや可用性を制限する可能性があります。
- B. EFSを使用する方法は、ファイルストレージのスケーラビリティを改善しますが、根本的にFTPサーバーを使っている問題を解決するわけではありません。また、EFSはネットワーク経由でアクセスされるため、FTPに依存するという構成に留まることになり、完全な解決には至りません。
- C. AWS Transfer Family を使用してFTPサーバーをAmazon S3に変更する方法は、FTPサーバーの可用性やスケーラビリティの問題を解決する最適な方法です。S3にファイルを直接保存し、S3イベント通知を使ってLambda関数を呼び出し、メタデータの追加と配達システムの更新を行います。このアプローチにより、システムがスケールし、ファイルの処理が自動化され、信頼性も向上します。
- D. ハンドヘルドデバイスを更新して、直接S3にアップロードさせる方法も一つの選択肢ですが、ハンドヘルドデバイスを変更できないという制約があるため、選択肢としては不適切です。
結論
最も適切な解決策は C です。AWS Transfer Familyを利用してFTPの代わりにS3を使用し、S3イベント通知とLambdaを組み合わせて自動的にメタデータを追加することで、システムの信頼性、スケーラビリティ、可用性を確保できます。
146-Auroraレプリカ
理論
Amazon Aurora MySQLのクロスリージョンレプリケーション
Amazon Auroraは、高可用性と耐障害性を提供するマネージド型リレーショナルデータベースサービスです。Auroraは、クロスリージョンレプリケーション機能を利用して、異なるAWSリージョンにリアルタイムでデータを複製できます。この機能は、災害復旧とデータ損失防止のために重要です。
ポイント：
- クロスリージョンレプリケーションにより、別のリージョンにデータベースのレプリカを自動的に作成し、リアルタイムでデータを同期させます。これにより、災害発生時に迅速な復旧が可能になります。
- データ損失の防止：Auroraは、書き込み操作の整合性を保ちながら、異なるリージョンでデータのコピーを管理します。
- 運用オーバーヘッドが少ない：Auroraのレプリケーションはフルマネージドであり、手動での管理や設定が最小限で済みます。
使用シナリオ：
- 災害復旧: 主要なリージョンで障害が発生した場合に、別のリージョンで運用を継続できます。
- 高可用性: 複数リージョンでのデータベース運用により、ダウンタイムのリスクを低減できます。
Auroraのクロスリージョンレプリケーションは、データ損失を防ぎ、迅速な復旧を実現するための最適な方法です。
一問道場
問題 #146
トピック 1
ある企業がAWSクラウドでアプリケーションを実行しています。このアプリケーションは、Amazon Elastic Container Service（Amazon ECS）クラスターでコンテナとして実行されています。ECSタスクはFargate起動タイプを使用しています。アプリケーションのデータはリレーショナルデータで、Amazon Aurora MySQLに保存されています。規制要件を満たすために、アプリケーションは障害発生時に別のAWSリージョンに復元できる必要があります。障害が発生した場合、データは失われてはいけません。
どのソリューションが最小の運用オーバーヘッドでこれらの要件を満たしますか？
A. 別のリージョンにAuroraレプリカをプロビジョニングする。
B. AWS DataSyncを設定して、データを別のリージョンに継続的にレプリケーションする。
C. AWS Database Migration Service（AWS DMS）を設定して、データを別のリージョンに継続的にレプリケーションする。
D. Amazon Data Lifecycle Manager（Amazon DLM）を使用して、5分ごとにスナップショットをスケジュールする。
解説
この問題の最適な解決策は、A. 別のリージョンにAuroraレプリカをプロビジョニングするです。
解説：
要件：
- データ損失なしでアプリケーションを別リージョンに復元する。
- 最小の運用オーバーヘッドで実現する。
選択肢の詳細：
A. 別のリージョンにAuroraレプリカをプロビジョニングする
- Aurora MySQLのクロスリージョンレプリケーション機能を使用することで、データベースのレプリケーションが自動的に行われ、アプリケーションのデータは異なるリージョンに複製されます。この方法はデータ損失を防ぎ、Auroraは耐障害性を提供するため、可用性の向上と復旧を簡単に実現できます。
- 最小限の管理で、リージョン間でのデータ複製が可能です。
B. AWS DataSyncでデータを別のリージョンに継続的にレプリケーションする
- DataSyncはファイルベースのデータ転送に適していますが、Aurora MySQLのようなリレーショナルデータベースには最適ではありません。MySQLのデータベースレベルのレプリケーションには、RDSのレプリケーション機能を使う方が効果的です。
C. AWS Database Migration Service (AWS DMS)を設定してデータを別のリージョンに継続的にレプリケーションする
- DMSはリレーショナルデータベースのレプリケーションに使えるツールですが、通常は移行のために使います。運用環境の継続的なレプリケーションには他のサービス（Auroraのレプリケーション）が適しており、DMSを使用する場合の管理オーバーヘッドが増加します。
D. Amazon Data Lifecycle Manager（Amazon DLM）を使用してスナップショットをスケジュールする
- DLMはスナップショットの管理に使いますが、スナップショットは手動で復元が必要なため、継続的なレプリケーションや自動復旧には適しません。スナップショットを利用する方法では、データの整合性を保ちながらの迅速な復旧が難しい場合があります。
結論：
Auroraのクロスリージョンレプリケーションは、最も運用負担が少なく、必要なデータ整合性と可用性を提供します。
147-ETL
理論
データ処理と変換の本質的知識：AWSを活用するための基本原理
比較: EMR vs Glue
特徴 | Amazon EMR | AWS Glue |
主な用途 | ビッグデータ処理、カスタム分析 | ETL、データ統合と変換 |
運用負荷 | 高い（クラスター管理が必要） | 低い（完全にマネージド） |
スケーリング | 手動または自動でノードをスケール可能 | 自動スケーリング |
適応データ量 | 超大規模データ | 小規模から中規模データ |
コスト効率 | 長時間処理が必要な場合に適している | 短時間処理に適している |
柔軟性 | カスタム処理や特殊フレームワークに最適 | コードレスで簡単なETL処理に最適 |
2. AWSサービス選定の基本
AWSは複数のサービスを提供していますが、それぞれの目的と特徴に応じて適材適所で選択する必要があります。
- 小規模・リアルタイム処理:
- AWS Lambda: 短時間で軽量なタスクに最適。トリガーベースで自動実行。
- 大規模・バッチ処理:
- AWS Glue: ETL（抽出、変換、ロード）に特化し、大量データに対応。
- Amazon EMR: 分散処理（Hadoop、Spark）を使用して高度なデータ変換。
- 非同期メッセージ処理:
- Amazon SQS: データを一時保管して非同期処理を実現。
- Amazon SNS: 通知を複数のターゲットに配信可能（リアルタイム性が求められる場合に使用）。
- データストレージと変換:
- Amazon S3: データの保存とトリガーイベントの発生源。
- Athena: データクエリとオンデマンド分析。
3. データ処理で重要な概念
- データ脱敏化（マスキング）:
- セキュリティとプライバシーを保護するため、機密情報を隠蔽する技術。
- 例: クレジットカード番号の一部を「****-1234」とする。
- データ変換:
- 形式変換（例: CSV → JSON）。
- 不要フィールドの削除や、必要なフィールドの統合。
- 拡張性:
- データ量が増加しても、システムが適切に対応できる設計。
4. この知識が問題にどう応用されるか
- 要件の分解:
- データを受け取る、処理する、保存する各ステップを明確に定義。
- 処理の柔軟性（新しいデータ形式への対応）を確保。
- 最小限の運用負荷:
- AWSのマネージドサービス（Glue、Lambda、S3）を活用し、自動化と運用負担の軽減を目指す。
- 安全性と規制遵守:
- PANデータをマスキングし、適切な保存形式（JSON）に変換。
AWSサービスの選択と活用方法を理解することで、柔軟かつスケーラブルなデータ処理パイプラインを構築できます。この知識が、問題解決の鍵となります。
一問道場
質問 #147
ある金融サービス会社は、クレジットカードサービス提供パートナーから定期的にデータフィードを受け取っています。約5,000件のレコードが15分ごとに平文で送信され、HTTPSを介して直接Amazon S3バケットに格納され、サーバーサイド暗号化が施されています。このフィードには、センシティブなクレジットカードの主アカウント番号（PAN）データが含まれています。同社は、別のS3バケットにデータを送信する前に、自動的にPANをマスクする必要があります。また、特定のフィールドを削除し、マージした後、レコードをJSON形式に変換する必要があります。さらに、将来的に追加のフィードが加わる可能性があるため、設計は容易に拡張できる必要があります。
どのソリューションがこれらの要件を満たすか？
A. ファイル配信時にAWS Lambda関数を呼び出して各レコードを抽出し、それをAmazon SQSキューに書き込む。新しいメッセージがSQSキューに到着すると、別のLambda関数を呼び出してレコードを処理し、その結果をAmazon S3の一時的な場所に書き込む。SQSキューが空になったら、最終的なLambda関数を呼び出してレコードをJSON形式に変換し、結果を別のS3バケットに送信して内部処理を行う。
B. ファイル配信時にAWS Lambda関数を呼び出して各レコードを抽出し、それをAmazon SQSキューに書き込む。AWS Fargateコンテナアプリケーションを設定し、SQSキューにメッセージが含まれているときに自動的に単一インスタンスにスケールアップする。アプリケーションは各レコードを処理し、JSON形式に変換する。キューが空になったら、結果を別のS3バケットに送信して内部処理を行い、AWS Fargateインスタンスをスケールダウンする。
C. AWS Glueクロウラーを作成し、データフィード形式に基づくカスタム分類器を作成して、データ定義を一致させる。ファイル配信時にAWS Lambda関数を呼び出して、AWS Glue ETLジョブを開始し、全レコードを処理および変換して必要な処理を行う。出力形式をJSONとして定義する。完了後、ETLジョブは結果を別のS3バケットに送信して内部処理を行う。
D. AWS Glueクロウラーを作成し、データフィード形式に基づくカスタム分類器を作成して、データ定義を一致させる。ファイル配信時にAmazon Athenaクエリを実行して、Amazon EMR ETLジョブを開始し、全レコードを処理および変換して必要な処理を行う。出力形式をJSONとして定義する。完了後、結果を別のS3バケットに送信して内部処理を行い、EMRクラスターをスケールダウンする。
解説
問題の解説：AWSを使ったデータ処理システムの設計
問題の背景
- シナリオ: 金融サービス会社が定期的に受け取るクレジットカードデータ（PAN情報を含む）を、適切にマスキング・変換し、内部処理のために別のS3バケットに保存したい。
- 要件:
- PANデータをマスキングしてプライバシーを保護。
- 不要なフィールドを削除し、必要なフィールドを統合。
- データ形式をJSONに変換。
- 将来、新しいデータフィードにも対応できる柔軟性。
各選択肢の分析
- 選択肢A: Lambda + SQS を使った段階的なデータ処理
- Lambda を使用して処理のトリガーを管理し、SQS で非同期メッセージ処理を実現。
- メッセージがキューに格納されるたびにデータを処理し、最終的な結果をS3に保存。
- メリット:
- 非同期処理でスケーラブル。
- 各段階を独立して管理可能。
- デメリット:
- 処理ステップが複雑化。
- 運用管理が煩雑になる可能性。
- 選択肢B: Lambda + Fargate を利用したスケール可能な処理
- Fargate を活用してスケール可能なコンテナベースのデータ処理を実現。
- Lambda がトリガーとなり、Fargate インスタンスが必要に応じてスケール。
- メリット:
- スケールに優れ、大量データにも対応可能。
- デメリット:
- Fargate のセットアップやコストが発生。
- 選択肢C: Glueを利用したETL処理
- Glue を使ってデータをETL処理（抽出・変換・保存）し、JSON形式でS3に保存。
- メリット:
- Glue はフルマネージドで運用負担が少ない。
- 将来的なデータフォーマットの変更にも柔軟に対応可能。
- ETLジョブで複雑な処理を一括管理。
- デメリット:
- Glue のセットアップがやや複雑。
- 選択肢D: Glue + EMRを利用したETL処理
- Glue を使ってデータを定義し、EMRで変換処理を実行。
- メリット:
- 大量データを効率的に処理可能。
- デメリット:
- EMR クラスターのセットアップとスケーリングが必要。
- 運用負担が増加。
最適な選択肢
- 選択肢C: AWS Glueを利用したETL処理
- 理由:
- 運用負荷が最小限: フルマネージドサービスで手動作業を削減。
- 柔軟性が高い: データフォーマットの変更や新しいフィードにも対応可能。
- 要件に最適: 複雑な変換処理をGlueジョブで一括実行し、データをJSON形式でS3に保存。
補足知識
- Glue ETLとは:
- AWS GlueはETL（抽出・変換・ロード）作業を簡素化するためのマネージドサービス。
- 複数のデータソースからデータを取り込み、統合、変換、保存が可能。
- ETLの利点:
- データ処理を自動化。
- コードレスで柔軟な変換ルールを定義可能。
- 将来対応:
- Glueのスクリプトを更新することで、新しいデータフィードや要件にも柔軟に対応可能。
この選択肢は、規模の拡大や新しい要件への適応を考慮した最も効果的な解決策です。
148-AWS Disaster Recovery
理論
災害復旧 (Disaster Recovery) と ビジネス継続性 (Business Continuity) に関するAWSのソリューションの理解。これを実現するための技術的な選択肢と、最適な選択を行うための基礎的な知識を解説します。
1. 災害復旧 (Disaster Recovery) の概要
災害復旧（DR）は、組織がシステム障害、自然災害、サイバー攻撃などの危機的な状況に対して、最小のダウンタイムとデータ損失で業務を再開できるようにするための戦略です。AWSでは、災害復旧のためにいくつかの方法とツールが提供されています。代表的な方法には以下があります：
- バックアップとリストア: 定期的にデータをバックアップし、災害時にバックアップから復元する。
- レプリケーション: データやシステムを別の場所に複製し、障害発生時に迅速に切り替える。
- フェイルオーバー: 主システムが障害を起こした場合に、自動的にバックアップシステムに切り替える。
2. AWSの災害復旧ソリューション
AWSでは、災害復旧を効率的に実現するための各種サービスを提供しています。
- AWS Elastic Disaster Recovery (AWS DRS):
- AWS DRSは、オンプレミス環境をAWSクラウドに簡単にレプリケートし、災害時に迅速にフェイルオーバーするためのサービスです。システム全体を自動的に復旧させることができます。
- 特徴: このサービスは、最小の運用負担でレプリケーションとフェイルオーバーが可能で、災害復旧のテストも容易に実施できます。
- 利点: オンプレミスからAWSへのレプリケーションを簡単にセットアップでき、災害発生時には短時間で復旧できます。
構成フロー：
- ソースインスタンス：これはあなたのローカルサーバーで、AWS DRSエージェントをインストールして、データをクラウドに複製します。
- コントロールインスタンス：AWSはこのインスタンスを自動的に作成し、災害復旧プロセスの管理を担当します。
- ターゲットEC2インスタンス：これはAWS上で作成するインスタンスで、災害発生時にサービスを復元するためのインスタンスです。
したがって、クラウド上には少なくとも以下の2台が必要です：
- 1台の コントロールインスタンス（AWSが自動的に作成）
- 1台の ターゲットEC2インスタンス（サービス復元用）
この説明で、全体のアーキテクチャが理解しやすくなることを願っています！
- AWS Database Migration Service (DMS):
- DMSは、データベースの移行とレプリケーションを実現するサービスです。異なるデータベースエンジン間でデータを移行することができ、変更データキャプチャ（CDC）機能を使用してリアルタイムでデータを同期することも可能です。
- 特徴: 主にデータベースの移行やレプリケーションを目的としており、全体のアプリケーション復旧には関与しません。
- AWS Storage Gateway:
- Storage Gatewayは、オンプレミスのストレージをAWSに接続するためのサービスで、データのバックアップやリストアをクラウド上で行うことができます。ボリュームゲートウェイやファイルゲートウェイなど、さまざまなオプションがあります。
- 特徴: スナップショットからの復元を行う場合に便利ですが、データベースやアプリケーション全体の復旧には追加の手順が必要となります。
3. 災害復旧の手法の選定基準
災害復旧戦略を選択する際には、以下の要素を考慮する必要があります：
- 可用性: どの程度システムを可用に保ちたいか。例えば、RPO（Recovery Point Objective）とRTO（Recovery Time Objective）を定義し、それに見合った復旧手段を選ぶ必要があります。
- コスト: 高可用性を実現するためのコスト（例えば、複数のリージョンへのデータレプリケーションや常時起動しているバックアップインスタンスなど）。
- 運用の手間: 復旧手順や定期的なテストがどれほど自動化されているか。運用負担が少ないソリューションを選ぶことが重要です。
4. AWS DRSの利用
AWS DRSは、災害復旧戦略において非常に有用な選択肢です。主に以下の利点があります：
- 低運用負荷: システムのレプリケーションとフェイルオーバーが自動化されており、復旧テストも簡単に行えるため、手動の操作が少なくなります。
- 迅速な復旧: AWSクラウドへのレプリケーションにより、障害発生時には迅速に切り替えが可能です。
- 拡張性: AWSクラウド上で環境を簡単にスケールアップ・ダウンできるため、ビジネスの成長に合わせて柔軟に対応できます。
結論
この問題において、**AWS Elastic Disaster Recovery (AWS DRS)**が最も適した選択肢です。AWS DRSは、オンプレミスのシステムをAWSにレプリケートし、災害時に迅速に復旧するための最小限の運用負荷で利用可能なサービスです。その他の選択肢（DMSやStorage Gateway）は主にデータ移行やバックアップに特化しており、アプリケーション全体の災害復旧には不向きです。
一問道場
会社は、主要なオンプレミスアプリケーションが失敗した場合に備えて、AWSを使用して事業継続ソリューションを作成したいと考えています。このアプリケーションは物理サーバー上で実行されており、他のアプリケーションも同じサーバー上で実行されています。移行を計画しているオンプレミスアプリケーションでは、MySQLデータベースがデータストアとして使用されています。オンプレミスのすべてのアプリケーションは、Amazon EC2と互換性のあるオペレーティングシステムを使用しています。
会社の目標を最小限の運用負荷で達成するには、どのソリューションが適切でしょうか？
選択肢：
A.
AWS Replication AgentをMySQLサーバーを含むソースサーバーにインストールします。すべてのサーバーのレプリケーションを設定します。定期的にテストインスタンスを起動して訓練を実施します。障害が発生した場合はテストインスタンスに切り替えます。
B.
AWS Replication AgentをMySQLサーバーを含むソースサーバーにインストールします。ターゲットのAWSリージョンでAWS Elastic Disaster Recoveryを初期化します。起動設定を定義します。定期的に最新の時点からフェイルオーバーとフェイルバックを実施します。
C.
AWS Database Migration Service（AWS DMS）のレプリケーションサーバーと、データベースをホストするターゲットのAmazon Aurora MySQL DBクラスターを作成します。既存のデータをターゲットDBクラスターにコピーするためにDMSレプリケーションタスクを作成します。データを同期するためにローカルのAWS Schema Conversion Tool（AWS SCT）で変更データキャプチャ（CDC）タスクを作成します。互換性のあるベースAMIから開始して、残りのソフトウェアをEC2インスタンスにインストールします。
D.
AWS Storage Gatewayのボリュームゲートウェイをオンプレミスにデプロイします。すべてのオンプレミスサーバーにボリュームをマウントします。新しいボリューム上にアプリケーションとMySQLデータベースをインストールします。定期的にスナップショットを取得します。互換性のあるベースAMIから開始してすべてのソフトウェアをEC2インスタンスにインストールします。EC2インスタンス上でボリュームゲートウェイを起動します。最新のスナップショットからボリュームを復元します。障害が発生した場合は新しいボリュームをEC2インスタンスにマウントします。
解説
この問題では、会社がAWSを使ってビジネス継続性ソリューションを構築する方法を問われています。会社は、オンプレミスで動作しているアプリケーションが故障した際に、できるだけ手間をかけずにAWS上でアプリケーションの復旧をしたいと考えています。このアプリケーションは、MySQLデータベースをデータストアとして使用しています。
選択肢のそれぞれを見ていきましょう。
A: AWS Replication Agentを使用する
- 概要: AWS Replication Agentを使用して、オンプレミスのサーバー（MySQLを含む）に対してレプリケーションを設定します。その後、定期的にテストインスタンスを起動して、フェイルオーバーテストを実行します。
- 解説: これは、災害復旧の準備を整えるために有効な方法ですが、設定や管理の手間がかかる可能性があります。定期的なテストと切り替え操作が必要です。
B: AWS Elastic Disaster Recoveryを使用する
- 概要: AWS Elastic Disaster Recoveryを使用して、オンプレミスサーバーのレプリケーションを行い、定期的にフェイルオーバーテストを実施します。
- 解説: こちらは、業務継続性を確保するための最小限の操作負荷で復旧が可能です。Elastic Disaster Recoveryは、AWSでの災害復旧を効率的に実現でき、設定も比較的簡単です。実際にAWSで障害が発生した際に、最もスムーズに復旧ができる方法です。
C: AWS DMSを使ってデータ移行
- 概要: AWS Database Migration Service (DMS)を使って、MySQLデータベースをAurora MySQL DBに移行します。データはCDC（変更データキャプチャ）を使って同期されます。
- 解説: DMSを使用する方法は、主にデータベースの移行にフォーカスしているため、アプリケーション自体の復旧に関する要件には完全には対応していません。特に、データベースのレプリケーションを行うだけで、アプリケーションの完全な復旧をカバーするわけではありません。
D: AWS Storage Gatewayを使ってボリュームのバックアップ
- 概要: AWS Storage Gatewayを使用してオンプレミスのサーバーにボリュームをマウントし、定期的にスナップショットを取ります。故障時にスナップショットから復元し、EC2インスタンス上でアプリケーションを再起動します。
- 解説: Storage Gatewayはファイルのバックアップには便利ですが、データベースやアプリケーションの完全な復旧には追加の手順が必要です。スナップショットからの復元は、手動の設定や管理が多くなるため、最小限の運用負担にはならない可能性があります。
正解：
Bが最も適切な選択です。
- 理由: AWS Elastic Disaster Recoveryは、オンプレミスのサーバーのレプリケーションをAWSで管理し、必要なときに簡単にフェイルオーバーを実行できるため、最小の運用負担で災害復旧を実現できます。また、定期的にフェイルオーバーと復旧テストを実施することで、万が一の障害時にも迅速に対応できます。
149-外部ID
理論
簡単に言うと…
外部IDは、AWSが誰がアクセスしようとしているのかを確認するための鍵のようなものです。これにより、許可された人だけがアクセスできるようになります。
例えるなら…
想像してみてください。あなたの家にセキュリティシステムがあって、誰かが家に入ろうとする時に、鍵だけではなく、特別なコード（外部ID）も必要なんです。このコードがないと、どんなに鍵を持っていても家には入れません。
なぜ必要か？
もし外部IDがなければ、他の誰かが許可された人のアクセス情報を使って、不正にリソースにアクセスできてしまう可能性があります。外部IDを使うことで、それを防ぐことができます。
まとめ：
- 外部IDはアクセスを許可するための特別なコードです。
- パスワードは認証（本人確認）のため、外部IDは誰がアクセスしているかを確認するために使います。
これが外部IDの役割です！
外部IDは、AWSリソースへのアクセスを制御するための特別なコードです。この外部IDは、監査員に提供する必要があり、安全な方法で渡すことが重要です。
外部IDの送信方法：
- 暗号化された通信手段を使う：例えば、暗号化されたメールや安全なメッセージングツールを使用して外部IDを送信します。
- 公開のチャネルで送らない：普通のメールやソーシャルメディアなど、公開される可能性のある方法では送信しないようにします。
- 受信者が適切な監査員であることを確認する：外部IDを送る前に、受信者が本当に必要な監査員であることを確認しましょう。
このように、安全に外部IDを送信することで、AWSリソースへのアクセスを正当な監査員にのみ許可できます。
一問道場
問題 #149
トピック 1
ある会社は、財務情報の規制監査を受けています。外部監査人は1つのAWSアカウントを使用して、会社のAWSアカウントにアクセスする必要があります。ソリューションアーキテクトは、監査人に会社のAWSアカウントへの安全な読み取り専用アクセスを提供する必要があります。このソリューションは、AWSのセキュリティベストプラクティスに準拠していなければなりません。
どのソリューションがこれらの要件を満たしますか？
A. 会社のAWSアカウントで、リソースポリシーを作成して、すべてのリソースに対して監査人のAWSアカウントにアクセスを許可します。リソースポリシーに一意の外部IDを割り当てます。
B. 会社のAWSアカウントで、監査人のAWSアカウントを信頼するIAMロールを作成します。必要な権限を持つIAMポリシーを作成し、そのポリシーをロールにアタッチします。ロールの信頼ポリシーに一意の外部IDを割り当てます。
C. 会社のAWSアカウントで、IAMユーザーを作成し、必要なIAMポリシーをIAMユーザーにアタッチします。IAMユーザーのAPIアクセスキーを作成し、そのアクセスキーを監査人と共有します。
D. 会社のAWSアカウントで、必要な権限を持つIAMグループを作成します。会社のアカウントで各監査人のためにIAMユーザーを作成し、IAMユーザーをIAMグループに追加します。
解説
この問題では、外部監査員にAWSアカウントへの読み取り専用アクセスを提供する方法が求められています。セキュリティのベストプラクティスを守りながらアクセスを提供する方法を選ぶ必要があります。
解説：
- *最適な方法（B）**は、IAMロールを使って監査員にアクセス権を付与する方法です。
- 外部IDを使用することで、監査員のAWSアカウントへのアクセスが他の人によって不正に使用されるのを防ぎます。
- 外部IDは、一度設定した信頼関係が正当なものであることを確認するために使われます。
なぜBが最適か？
- ロールと外部IDを使うことで、監査員に一時的で安全なアクセスを提供でき、セキュリティが強化されます。
- 他の方法（A、C、D）は、管理が難しく、セキュリティのリスクが高くなります。
要するに、Bは最も安全で柔軟な方法であり、セキュリティのベストプラクティスに従っています。
150-DAX
理論
1. Amazon DynamoDBの概要
Amazon DynamoDBは、フルマネージドのNoSQLデータベースサービスで、非常に高速でスケーラブルなデータ処理を提供します。特に、オンデマンドキャパシティモードは、トラフィックの変動に自動で対応し、容量の管理を手間なく行える点が特徴です。DynamoDBは、スケーラブルで高可用性のあるデータベースで、データの読み書きの速度が非常に速いため、リアルタイムなデータ処理が求められる取引プラットフォームにも適しています。
2. レイテンシを最小化するためのDAX
取引プラットフォームでは、レイテンシ（応答時間）を最小化することが最重要です。これに対して、DynamoDB Accelerator (DAX)は、インメモリキャッシュを提供し、DynamoDBの読み取り性能を大幅に向上させるためのサービスです。
DAXは、DynamoDBに対してキャッシュレイヤーとして機能し、データの読み取りを高速化します。特に、頻繁にアクセスされるデータに対して効果的で、データベースにアクセスする際の時間を大幅に短縮します。
3. DAXクラスターの設定
- DAXのノード数：DAXクラスターは1つ以上のノードで構成できますが、通常は3ノード以上のクラスターを使用することが推奨されます。3ノード以上の構成により、高可用性と耐障害性が向上します。1ノードでは単一障害点（SPOF）が生じやすいため、プロダクション環境では少なくとも3ノードでの運用が推奨されます。
- 書き込みと読み取りの動作：
- DAXは読み取りの速度を大幅に向上させることができますが、書き込みは直接DynamoDBに行われるため、DAXは主に読み取りパフォーマンスの向上を目的とします。
- 書き込みをDAXを通じて行う場合、書き込みがDAXクラスター内のキャッシュに反映され、その後DynamoDBに同期されますが、DAXは読み取りキャッシュ専用であるため、書き込み操作に関してはDynamoDBに直接行う必要があります。
一問道場
質問 #150
トピック 1
ある企業がレイテンシに敏感な取引プラットフォームを運営しており、Amazon DynamoDBをストレージバックエンドとして使用しています。この企業はDynamoDBテーブルをオンデマンドキャパシティモードで構成しています。ソリューションアーキテクトは、取引プラットフォームのパフォーマンスを改善するソリューションを設計する必要があります。新しいソリューションは、取引プラットフォームの高可用性を確保し、最小のレイテンシである必要があります。
どのソリューションが最も適切ですか？
A. 2ノードのDynamoDB Accelerator (DAX)クラスターを作成し、アプリケーションを構成してDAXを使用してデータの読み書きを行う。
B. 3ノードのDynamoDB Accelerator (DAX)クラスターを作成し、アプリケーションを構成してDAXを使用してデータの読み取りを行い、DynamoDBテーブルに直接データを書き込む。
C. 3ノードのDynamoDB Accelerator (DAX)クラスターを作成し、アプリケーションを構成してDynamoDBテーブルから直接データを読み取り、DAXを使用してデータを書き込む。
D. シングルノードのDynamoDB Accelerator (DAX)クラスターを作成し、アプリケーションを構成してDAXを使用してデータの読み取りを行い、DynamoDBテーブルに直接データを書き込む。
解説
この問題は、レイテンシに敏感な取引プラットフォームのパフォーマンスを向上させ、高可用性を維持する方法に関するものです。DynamoDBのオンデマンドキャパシティモードを使用しているため、パフォーマンスを改善するために**DynamoDB Accelerator (DAX)**を導入する必要があります。
解説：
- DAXは、DynamoDBのインメモリキャッシュとして機能し、読み取り性能を大幅に向上させます。
- レイテンシを最小限に抑え、高可用性を確保するためには、3ノード以上のDAXクラスターを使用するのが最適です。これにより、高可用性と耐障害性が強化されます。
- Bの選択肢は、DAXを使って読み取りを高速化し、書き込みはDynamoDBに直接行うという最適な構成です。
最適な解答：B
- 3ノードのDAXクラスターを使用し、読み取りをDAXで、書き込みをDynamoDBに直接行うことで、パフォーマンスを最大化し、高可用性を保つことができます。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/16fd7ae8-88e2-800b-b3d7-ca0fcc5fa60a
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
