Closed1

AWS 信頼性

445445

信頼性

S3削除防止

  • S3バケットに対してMFA認証を有効化:ユーザーは削除処理を実施しようとすると毎回MFA認証が求められるため、操作ミスによる削除を防ぐことができます。
  • バージョニング機能を有効化: 削除されたファイルを戻すことが出来ます。
  • S3バケットは初期設定でオブジェクトを削除できない設定が可能ですが、これは初期設定時のみに利用可能です。既に利用しているS3バケットの設定を変更することはできません。

リクエストメッセージ

「保留中のデータベースへの書き込みリクエスト」を、SQSキューに格納して非同期に処理することができます。DynamoDBのデータ処理実行にはLambdaと連携しつつキューによるDB処理を実行することも可能です。これにより、リクエストメッセージが失われることはないため、書き込み処理がどのような状況下でも失われないようにする要件に合致しています。したがって、オプション3が正解となります。

DynamoDBの書込処理に対してSQSキューだけでは、分散処理プロセスを実行できません。SQSをトリガーにしたLambda関数が必要不可欠です。

セキュリティグループ変更

セキュリティグループの変更と新規設定は全てのEC2インスタンスに即座に反映されます。

業務解析システム&並列処理

あなたはソリューションアーキテクトとして、業務解析システムを構築しています。このシステムでは初期ストレージ容量が8 TBの高可用性リレーショナルデータベースが必要です。要件として データ量が毎日10 GBずつ増加することが予測されています。また、予想トラフィック量に対処するためには、データ処理向けに並列処理が必要があります。

  • 業務解析システム用のデータベースにはRedshiftが最適です。Redshiftは大量データの保存や並列処理によるパフォーマンス向上が可能であり、要件を満たすことができます。Redshiftはクラウド内で完全に管理されたペタバイト規模のリレーショナルデータベース型のデータウェアハウスサービスです。 Redshiftは数百ギガバイトのデータからペタバイト以上に拡張できます。 Redshift はテーブルの行をコンピューティングノードに分配するので、データを並列処理できます。 Redshift は各テーブルに対して適切な分散キーを選択することにより、データの分配を最適化して、ワークロードを分散し、ノード間のデータの移動を最小限にできます。

  • DynamoDBはNoSQL型データベースであり、高可用性リレーショナルデータベースという要件に合致していません。

  • RDSはリレーショナルデータベースですが、業務解析システムとして利用できません。RDSはリードレプリカを構成することで、読込処理を並列化することはできますが、データ解析を並行分散処理ができません。

  • Aurora MySQL 並列クエリは、データ集約的なクエリの処理に関連する I/O と計算の一部を並列処理することができます。しかしながら、業務解析システムという要件を鑑みると、AuroraよりもRedshiftが最適であるため、そちらが優先されるシナリオとなります。

ビジネスインテリジェンスアプリケーション

ビジネスインテリジェンスアプリケーション(BIアプリケーション)はデータウェアハウスと連携して業務データ解析などを実行するシステムです。AWSでDWHを実現する際は、Amazon Redshiftが最適です。

EC2の配信要求増加

あなたはEC2インスタンスを利用したWebサーバーをAWSにホストしています。最近になってアプリケーションへの画像取得要求が増加して、これがCPUの大部分を占有することで、アプリケーションの応答パフォーマンスが低下しています。
画像取得リクエストの増大に対してユーザビリティを向上させるためには、Auto Scalingではなく、CloudFrontを設定して画像配信を任せることが望ましい対応です。CloudFront は低レイテンシーの高速転送により視聴者に安全にコンテンツを配信する高速コンテンツ配信ネットワーク (CDN) サービスです。CloudFront はAWS のグローバルインフラストラクチャならびにその他の AWS サービスと直接接続されます。

オプション1は不正解です。Auto Scalingグループの設定によりEC2インスタンスを増加させることで、WEBサーバー側の処理を向上させることは可能ですが、WEBアプリケーションのコンテンツ配信処理の向上にはCloufFrontを設定することが推奨されています。

オプション2は不正解です。ロードバランシングと画像の高速配信処理とは無関係です。

オプション4は不正解です。画像配信の高速化にはDynamoDBは利用できません。DynamoDBはセッションデータやメタデータなどの管理や高速処理などのKVSデータ処理に向いています。

リレーショナルデータベースランダムI/O遅延

ある企業において、リレーショナルデータベースのストレージレイヤーをAWS上で構築しています。このデータベースソリューションでは多数のトランザクション処理が発生することが予想されており、ランダムI/O遅延が発生することが懸念されています。あなたはソリューションアーキテクトとして、データベース設定によって性能を向上させるように依頼を受けました。なるべく運用負荷をかけないことが求められます。

RDSのインスタンスタイプにおいてIOPS性能が高いタイプを選択して高性能な処理が行えるように設定することで、ランダムI/O遅延を防ぐことができます。また、必要に応じてリードレプリカを増強させるのも良いでしょう。

ElastiCacheは高速データ処理に向いていますが、NoSQL型のデータベースの代表的なAWSサービスです。こちらもリレーショナルデータベースとして利用することはできません。

DynamoDBのスループットが低下

現在DynamoDBに発生している障害に対応しています。このDynamoDBでは、顧客のセッションデータを大量に処理しています。現在、一時的にセッションデータ処理量が大きくなっており、DynamoDBのスループットが低下していることが分かっています。

オプション3が正解となります。DynamoDBのAuto Scalingを導入して、テーブルとグローバルセカンダリインデックス(GSI)の容量増加を自動化できます。DynamoDB Auto Scalingはテーブルとインデックスを監視して、アプリケーショントラフィックの変化に応じて自動的にスループットを調整します。 これにより一時的な負荷増加に対して、DynamoDBテーブル処理パフォーマンスの管理が容易になり、アプリケーションの可用性を最大化しつつ、DynamoDBのコストを削減することができます。

オプション1は不正解です。DynamoDBはそのままではリードレプリカを増やすことができません。後述するDAX を有効化することで、DAXクラスターは、1 つのみのプライマリノードと、0~9 個のリードレプリカノードを構成することができます。

オプション2は不正解です。DynamoDB Accelerator(DAX) を有効化することで、DynamoDBテーブルはミリセカンドからマイクロセカンドへの最大 10 倍のパフォーマンス向上を実現します。DAXはキャッシュを利用しているため特定のデータへの処理が高い場合などに中長期的な性能向上のために対策としては正しいです。しかしながら、キャッシュDBは高コストであるため、コスト最適という要件に合致させるためには、本件ではAuto Scalingによる処理負荷に対するスケーリングを優先して実行します。

オプション4は不正解です。DynamoDB グローバルテーブル は、マルチリージョンにマルチマスターデータベースをデプロイするための完全マネージド型のソリューションです。これにより、高い冗長化を実現することができますが、DynamoDB テーブルのパフォーマンスが向上するわけではありません。

DBの別リージョンデータ利用(回復性)

当該データベースに保存されているデータは業務上で非常に重要であるため、災害発生時に別リージョンでデータを利用できるようにする必要があります。そのため、毎月の請求期間における月間稼働率が99%以上で使用できるようにするSLAが設けられています。

最も回復性が速い方式で、この要件を達成するための方法を選択してください。

  • AuroraはソースDBクラスターとは異なるリージョンにリードレプリカを作成することができます。 この方法を採用すると、障害回復機能を向上させ、読み取り操作をユーザーに近いリージョンに拡張しつつ、あるリージョンから別のリージョンへの移行を容易にすることができます。

セッションデータ高速処理

このWEBアプリケーションでは高速でセッションデータを格納して、そのデータを出来る限りに高速で処理するためのデータストアが必要とされています。
ElastiCacheは高スループットで待ち時間の短いインメモリデータストアからデータを取得することで、データ集約型のアプリケーションを構築するか、既存のアプリケーションのパフォーマンスを向上させます。ユースケースとして、セッションデータの高速処理には最適なデータベースです。
AuroraはリレーショナルデータベースとしてSQLを利用した業務データなどのデータベース構築に用いられます。RDSの中でも高性能ではあるものの、やはりセッションデータの高速処理には向いていません。

膨大なデータを蓄積したうえで、後続のデータ解析処理ができる仕組みを構築する

ログ解析は後続処理で実行するため、まずはKinesis FirehoseでS3へのログ配信を実施して蓄積した上で、ログ解析処理を後続処理で実施することが望ましい
「DynamoDBにDAXクラスターを準備してリアルタイムに高速処理」は、リアルタイム処理を必要としていないため、今回の要件にあっていません。
Kenesis Analyticsだけではデータを蓄積して分析ができないため、処理が不十分となります。

データのリアルタイム分析

データは、顧客がサイトをクリックするときに広告のクリックスルーを増やすべく、ページレイアウトを変更するためにリアルタイムで利用されます。
Amazon Kinesis Data Streamsを使用すると、特別なニーズに合わせてストリーミングデータを処理または分析するカスタムアプリケーションを構築できます。
RedshiftはDWHとして蓄積されたデータのBI処理に利用するため、リアルタイム分析には不適切

要件としては別サイトにバックアップとなるDBを別で用意して、かつメインのDBが停止した際に即座に切り替えて、予備のDBを利用できるようにする必要があります。
マルチAZ構成を有効にすることで、別AZにセカンダリーDBを構築することができ、フェイルオーバー構成を作ることが出来ます。フェイルオーバーによって、プライマリーDBが停止しても即座にセカンダリーDBへと移行することができます。
リードレプリカを別AZに生成は可能ですが、それがセカンダリーDBとなるわけではありません。

EBSボリュームにおいて不具合や破損が発生してもデータ消失しないようにデータ保持する仕組みが必要となりました。1つのボリュームで消失したデータは即時に利用できる最も回復性が高い方法が必要となります
2つ以上のEBSボリューム間でミラーリングすることで回復性が高いデータ冗長化を達成することが可能です。これにより、EBSボリュームにおいて不具合や破損が発生してもデータ消失しないようにデータ保持することができます。EBSボリュームのレプリケーションという機能はありません。

Amazon VPC VPN 接続

カスタマーゲートウェイに静的ルートテーブルを構成することでVPN接続を設定できます。

Amazon VPC VPN 接続では、データセンター (またはネットワーク) を Amazon VPC 仮想プライベートクラウド (VPC) にリンクします。カスタマーゲートウェイは、その接続の作業者側のアンカーです。物理的アプライアンスにすることも、ソフトウェア的アプライアンスにすることもできます。VPN 接続の AWS 側のアンカーは、仮想プライベートゲートウェイと呼ばれます。

読み込み処理向上

  • DynamoDB
    OK: SQS(キューイングによって処理負荷を下げる) & Auto Scaling(処理性能をスケーリングすることで高負荷に対応) (費用効果が高くスケーラブルなアーキテクチャを提供する構成)
    NG: 書き込みキャパシティ増強(一時的なアクセス集中に対応可能だが高額)& マルチAZ構成(DynamoDBにマルチAZ機能はない。ただしDAXではあり)
  • RDS
    OK: リードレプリカ&Sharding(水平分割(horizontal partitioning)とも)& 高性能なインスタンスタイプに変更(高額)
    (データ層を拡張&アクセス分散構成)
    NG: Auto Scaling(あくまでのストレージ容量のスケーリング)&マルチAZ構成(一方のAZのRDSが停止した際にもう一方のRDS DBに移行することが出来るという冗長化構成)

バックアップ

スナップショット:EC2のEBS(他のリージョンへコピーすることはできるが、他リージョンで使用することはできない)&RDB&Redshiftクラスターのクロスリージョンスナップショットすることで、プライマリクラスターがダウンした場合に備えて即座に利用できる構成を維持することができます。自動スナップショットがクラスターに対して有効にするという設定が必要です。有効にすると実施的にはS3に保存されることになりますが、S3に保存するという操作や設定をユーザー側で実施することはできるわけではないため、設定方法としては誤りになります。
レプリケーション:S3(クロスリージョンレプリケーション)&RDB(リードレプリカ:非同期。RDSの読み取りキャパシティを向上させる)
スケールアップ:RDB高性能なインスタンスタイプに変更してスケールアップすることで処理向上
AutoScaling:EC2&RDB(Auto Scalingはデータ容量を増加させるだけ。高負荷に対応することはできない)&DynamoDBにAuto Scalingを設定することで、一時的な負荷に対して処理性能をスケーリングすることで高負荷に対応することができます。
マルチAZ:DynamoDB&Redshift をマルチAZ構成で起動する機能はない
AMI(ゴールデンイメージ):EC2(他のリージョンへコピーすることはできるが、他リージョンで使用することはできない)
バージョニング:S3&Lambda。EFSとEBSにはバージョニング機能はありません。
Redshiftの拡張VPCルーティングを設定することでVPC内にデータ移動を制御することが可能です。また、VPCエンドポイントを利用したS3アクセスもVPC内のみにデータ移動を制御できます。

ELB

ヘルスチェック
負荷分散
SSLサポート
スティッキーセッション(セッション中に、同じユーザから来たリクエストを全て、同じEC2インスタンスに送信する機能)
Connection Draining(インスタンスに異常がある場合、そのインスタンスに新しいリクエストが行かないようにする)
S3へログ保管

ELB の種類

アプリケーションロードバランサ:CLB&ALB
ネットワークロードバランサ:NLB
CLB: L4&L7 に対応。全て同一の機能を持っているインスタンスを配下に持てる
ALB: L7 に対応。URLのパスに基づいてインスタンスを振り分けるパスベースルーティング可能
NLB:L4に対応。大規模アクセスでも、Pre-warming申請不要(CLB&ALBでは必要)。大量のリクエストを高速で処理できる(秒間何百万リクエストを処理)

ELBの設定

アプリケーションロードバランサの作成 -> 二つのパブリックサブネットを指定 -> ターゲットグループを作成(IPやインスタンスを選べる)-> ターゲットに対するヘルスチェックの閾値を設定(異常を何回検知したら異常とみなすか)-> ロードバランサが作成される(DNSが発行される。ここにアクセス)

AutoScaling

垂直スケーリング:スケールアップ&ダウン(メモリやCPUの追加削除)
水平スケーリング:スケールアウト&イン(インスタンスの追加削除)

AutoScaling group

スケールするインスタンスの最大数&最小数
起動台数をAZでバランシングする

AutoScaling configulation

スケーリング時のインスタンスの設定(AMIやインスタンスタイプなど)

AutoScaling plan

手動スケーリング、スケジュールベース、動的スケーリング(スケーリングポリシーによって、負荷の状況などによってスケーリング)、スケジュールベースと動的の組み合わせなど。

ターみネーションポリシー

スケールインの際、どのインスタンスを先に終了させるか
デフォルト設定:OldestLaunchConfiguration(最も古い起動設定のインスタンス)からClosestToNextInstanceHour(課金が始まるのがもうすぐのインスタンス)の順番に適用。

AutoScalingの設定

AutoScaling configulationで起動するインスタンスの設定を行う -> AutoScaling groupを設定(AutoScaling configulationを選択、パブリックサブネットを複数選択、ロードバランシングの有効化でALBのターゲットグループ指定、スケールするインスタンスの最大数&最小数、スケールポリシー(CPU70%以上でスケールアウトなど))-> AutoScaling groupの終了ポリシーをNewestInstanceにする -> 既存のインスタンスのアクションでAutoScalingをアタッチ

RDS

レプリカや、S3を使用したスナップショットで耐障害性UP
インスタンスサイズを拡大縮小できる
インスタンスタイプを変更できる
ストレージは一度拡大したら縮小できない
インスタンスと自動バックアップとレプリカとスナップショットを暗号化できる

インスタンスタイプ

汎用:T2、T3、M4(バランス型)、M5(バランス型)
メモリ最適化:R4< R5 < X1 < X1e < Z1d 高性能!!

ストレージタイプ

汎用:SSD
プロビジョンドIOPS:SSD。I/O高速
マグネティック:HDD。I/Oあまり発生しない(データを溜めるだけ)の場合使用

AutoScaling

垂直スケーリング:スケールアップ&ダウン(メモリやCPUの追加削除)
水平スケーリング:スケールアウト&イン(RDSの追加削除)

レプリカ

リードレプリカ(参照用)を最大5台(Auroraは15)マルチAZにスケールアウト
高可用性(読み取りが高速になる)

スナップショット

S3に保存。ある時点でのスナップショットを取得し、復元できる

RDSスケーリング

サブネットグループ作成(プライベートサブネット複数登録)-> DB作成(ここでマルチAZ設定する。サブネットグループを登録)-> SSHでパブリックEC2インスタンスアクセス-> mysql コマンドでDBのエンドポイントを指定して、DBにアクセス
RDSはAuto-Scalingによるパフォーマンス拡張は実施出来ません。代わりにデータベース容量を拡張することができます。

フェイルオーバー

フェイルオーバーして再起動 -> 別AZで新しいRDBが起動

問題

Question 1:
WEBアプリサービスを開発しているC社ではELBを利用して負荷分散を検討しています。アプリの登録ユーザー数は数万人で頻繁に利用されます。正しいELBタイプを選択をしてください。
アプリケーションのユーザー数が1万人ということは、一般的にいうと小規模のアプリケーションとなります。ユーザー数が1万人いることは、実際の同時アクセスユーザーはかなり少ないと考えてください。したがって、通常のWEBアプリケーション向けにALBを利用することが正解となります。Aplication Load Balancerは、開放型システム間相互接続 (OSI) モデルの第 7 層であるアプリケーションレイヤーで機能します。
Question 2:
ALBの特徴として間違っているものを選択してください。
HTTP/HTTPSとTCP/SSLプロトコルのL4とL7に対応しているのはCLBの特徴です。Application Load Balancerは、開放型システム間相互接続 (OSI) モデルの第 7 層であるアプリケーションレイヤーで機能します。
Question 3:
NLBの特徴として間違っているものを選択してください
毎秒数百万のリクエストに対応できる性能があります。
Question 4:
ロードバランシングしたいサーバーとしていくつかの機能別サーバー群を有しています。あなたはソリューションアーキテクトとして機能別にバランシングを実施したいと考えています。選択すべき方式として正しいものはどれですか?
ALBを利用したパスルーティングを実施することで、機能別にグループ分けしたEC2インスタンス群において、グループ毎にそれぞれバランシングを実施することが可能です。
Question 5:
大規模アクセスが予測されるケースについて、次の「ELBタイプと必要な対応」のセットのうち、「適切ではない内容」を選択してください。
NLBはPre-warming申請は必要ありません
Question 6:
次のうちELBの機能と説明が正しい組合せのものを選択してください。
スティッキーセッションはセッション中に、同じユーザから来たリクエストを全て、同じEC2インスタンスに送信する機能です。
Question 7:
スケーリングのタイプと説明の組合せで正しいものを選択してください。
スケールダウンはメモリやCPUを削減することです。
Question 8:
既存のEC2インスタンスに対して後からAuto-Scalingを設定する予定です。既存のインスタンスを活かして利用するために、どのターミネーションポリシーを設定するべきでしょうか。
AutoScalingによって新しく設置されたインスタンスから削除される設定です。
Question 9:
Auto-Scalingグループで設定する内容について間違っているものを選択してください。
インスタンスタイプの選択は起動設定で実施する内容です。
Question 10:
Auto-Scalingの設定において正しいものを選択してください。
ELBのターゲットグループを設定すれば、ELB構成を利用してELBのヘルスチェックによりAutoScalingを実行することができます。
Question 11:
Auto-Scalingのターミネーションポリシーのデフォルト設定の動作について正しい内容を選択してください。
OldestLaunchConfigurationからClosestToNextInstanceHourの順番に適用していきます。
Question 12:
RDSで選択できないDBソフトウェアは次のうちどれでしょうか
RDSではDB2は利用できません。Amazon RDS は、メモリ、パフォーマンス、または I/O に最適化されたいくつかのデータベースインスタンスタイプで利用でき、Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle データベース、SQL Server など、6 つの使い慣れたデータベースエンジンから選択できます。
Question 13:
C社では現在PostgreSQLを利用してデータベースを構築しているが、AWSクラウドサービスに移行したいと考えている。次に示す既存データベースの要件を踏まえた場合にどのように移行するべきか検討しなさい。

・PostgreSQL10.6を利用

・ファイルシステムとの連携が必要

・CRMとの連携が必要

・WEBサーバーとの連携が必要
RDSにはファイルシステムとの連携はサポートされていないため、EC2インスタンスを利用してデータベースを構成する必要があります。
Question 14:
RDSのリードレプリカの構築について間違っている内容を選択してください。
リードレプリカは別AZに構築が可能です。
Question 15:
RDSのスナップショットについて間違っている内容を選択してください。
RDSのスナップショットはリージョン内のS3に保存されます。
Question 16:
RDSを利用したスケーリングについて正しい内容を選択してください。
途中でインスタンスタイプを縮小するなど変更することが可能です。
Question 17:
RDSの暗号化対象として間違っている対象を選択してください。
RDSはそもそもオブジェクトは利用していないため、暗号化対象として不適切です。Amazon RDS リソースの暗号化オプションを有効化すると、AES-256 暗号化アルゴリズムにより DB インスタンス、 自動バックアップ、 リードレプリカ 、スナップショット、 ログを暗号化します。
Question 18:
RDSの暗号化方式として利用できないものを選択してください。
クライアントサイドの暗号化方式はRDSには利用できません。
Question 19:
RDSを利用したフェイルオーバ構成について正しい内容を選択してください。
フェイルオーバは手動で実施することができます。
Question 20:
RDSを利用するべき判断ポイントとして間違っているものを選択してください。
パッチ当てはAWS側が実施する管理内容です。パッチ当てなどを社内でコントロールする必要がある場合はEC2インスタンスをデータベースとして利用する必要があります。

このスクラップは2021/06/24にクローズされました