はじめに

以下のサービスがわからん

ブロックチェーン
グルー
バッチとSTEPファンクション
サーバレスアーキテクチャに出てくるコンポーネント系

来週16まで時間があるのでAWSを味わっていきます

学習

1

大規模な商社は、オンプレミスシステムを使用して取引データを分析しています。取引日の終了後、取引コスト、実行レポート、市場パフォーマンスなどのデータは翌日の取引予測のためのビッグデータ分析ツールを実行するHadoopサーバーに送信されます。データにはS3のクリックストリームやプロセスログなどの生データがあります。 EC2インスタンスはデータを他の形式に変換し、別のS3バケットに保存しています。その後、Amazon Redshiftによるデータ分析を行います。あなたはソリューションアーキテクトとして、このシステムにAWS Glueを導入してデータ処理を向上させるように依頼されました。

AWS Glueによりリファクタリングする方法を選択してください。

AWS Glueクローラーを利用してS3バケットを処理して、データをスキャンして、分類、スキーマ情報を抽出し、メタデータをAWS Glueデータカタログに保存してデータ分析前のETL処理を行うことができます。その後、このデータをRedShiftにおいて処理

AWS Glue

抽出、変換、ロード (ETL) を行う完全マネージド型のサービスで分析用データの準備とロードを簡単にします。

抽出元
- S3
  - ターゲットスキーマに自動的に一致するようにデータを変換することが可能
特徴
- AWS に保存されたデータを指定するだけで AWS Glue によるデータ検索が行われ、テーブル定義やスキーマなどの関連するメタデータが AWS Glue データカタログに保存されます。
  - AWS Glue データカタログは、データの場所、スキーマ、およびランタイムメトリクスへのインデックスです。Data Catalog 内の情報を使用して、ETL ジョブを作成し、監視します。Data Catalog の情報はメタデータテーブルとして保存され、各テーブルが 1 つのデータストアを指定します。
使用先
- redsfhit
  - さらにAWS Glueでのデータ処理後に、Data Catalogに保持したデータに対してRedShiftで即座に解析処理を実行することが可能です。

AWS再入門ブログリレー AWS Glue編

AWS GlueはフルマネージドなETL（抽出、変換、ロード）サービスです。
S3やRDS、Redshift等の各種AWSサービスとの連携を管理してくれるので、利用者は本来取り組むべき作業である、ETLジョブの作成や監視といった部分に注力出来るようになります。
各種AWSサービスの間を繋ぐ「糊(Glue)」として処理を構成・実行する形となります。

AWS Glueの概念・構成要素

1 データソースをクロールし、データカタログにメタデータテーブルを作成
- データストア（データソース）は、データを永続的に保存するリポジトリです。Amazon S3、リレーショナルデータベース等がそれにあたります。
- クローラ
  - データカタログにメタデータテーブルを作成するプログラムです。データストア（ソースまたはターゲット）に接続し、クロールしたデータは分類され、スキーマ情報を抽出します。
    - クロール可能なデータストアは、ファイルベース、テーブルベースのデータストアに対応しており、S3、DynamoDB、RDS、Redshift等をクロールすることができます。
2 データカタログの情報を元にジョブを定義
- カタログ
  - 永続的なメタデータストアです。各AWSアカウントで1つのデータカタログを持ち、ETLに必要なテーブル定義、ジョブ定義、およびその他の制御情報を保持します。
    - 本体であるデータに関する付帯情報が記載されたデータ
- ジョブ定義に基づいてETLの雛形コードが自動生成
3 ジョブ実行で、データソースからデータを抽出し、変換してデータターゲットにロード
- ETL作業を実行するために必要なビジネスロジックです。データカタログのデータを使用して、データを変換するジョブを定義できます。変換スクリプト、データソース、およびデータターゲットで構成され、サーバレスなApache Spark環境で実行されます。
  - Apache Sparkは巨大なデータに対して高速に分散処理を行うオープンソースのフレームワーク
  - なぜSparkは生まれたのか？ Hadoopとの違い

Hadoopの並列処理には下記のような欠点がありました。
・個々のコンピュータのメモリをうまく活用する設計ではなかった
・同じ処理を複数行う場合に、都度ストレージのアクセスが発生する
・同じデータを何回も扱う場合にストレージのアクセスが発生する
　最近、「機械学習」が人気ですが、まさに上記のような処理が必要です。機械学習の需要が高まるにつれて、上記の課題感も高まっていったと考えられます。
　Sparkはそのような課題を解決するために生まれました。「Resilient Distributed Datasets」という分散共有メモリの仕組みがあり、データはパーティション化され、複数マシンのメモリで管理されます。
　今まで、都度ストレージにアクセスしていたのが、インメモリで実行できるようになったわけです。

ジョブ詳細
- Spark
  - Sparkのクラスタを制御して大規模分散処理します。ジョブを起動すると1つのDriverと複数のExecutorが起動され、スクリプトはDriverで実行されます。
- Python Shell
  - 単にPythonスクリプトを実行する目的のジョブです。Python 2.7またはPython 3.6と互換性のあるスクリプトが実行可能です。

料金体系

データカタログ、クローラ、ジョブに対し料金が設定されていて、それらの合計

データカタログ
- データカタログは、オブジェクト数とアクセスリクエスト数に応じて月額料金
  - 100万オブジェクトの格納まで無料、以降10万オブジェクト毎に1ドル/月
  - 毎月100万リクエストまで無料、以降100万リクエスト毎に1ドル/月
クローラ
- 各クローラーには2DPUが割り当てられ、クローラーの実行で使用されたDPU時間が課金
- 1DPU 0.44ドル/時で、10分未満の処理は10分として計算
ジョブ
- ジョブの実行に費やしたDPU時間

Redshiftにデータをロード

デフォルトでは、AWS GlueからVPC内のリソースにアクセスすることはできません。VPC内のリソースにアクセスできるようにするには、ルーティング設定やセキュリティグループ等、追加の設定が必要

JDBC データストアに接続するための VPC の設定
- AWS Glueが、VPC内のリソースにアクセスする場合は、ENI経由でのアクセスとなり、すべての TCP ポートに対して自己参照のインバウンドルールを持つセキュリティグループが必要
- プライベートサブネット（のENI経由）からアクセスするために、S3へのVPCエンドポイントが必要

AWS Glue でジョブを追加

AWS Glue でのジョブは、作業を実行するビジネスロジックで構成されます。通常、ジョブは、抽出、変換、およびロード (ETL) スクリプトを実行します。ジョブ実行をモニタリングして、成功、継続時間、開始時間などのランタイムメトリクスを理解できます。ジョブの出力は変換されたデータで、指定された場所に書き込まれます。

ジョブ実行は、起動時にジョブを開始するトリガーによって開始されます。ジョブには、ソースデータに接続し、スクリプトのロジックを使用してデータを処理し、データターゲットに書き出すスクリプトが含まれています。ジョブは、複数のデータソースおよび複数のデータターゲットを持つことができます。AWS Glue によって生成されたスクリプトを使用してデータを変換することも、独自のスクリプトを提供することもできます。AWS Glue コードジェネレーターでは、ソーススキーマとターゲット位置またはスキーマを指定すると、Apache Spark API (PySpark) スクリプトを自動的に作成できます。このスクリプトを出発点として使用し、目標に合わせて編集できます。

ジョブプロパティの定義

このジョブが実行するスクリプト (生成またはカスタムス)
- ETL スクリプトのコードでジョブの手続きロジックを定義します。Python または Scala でスクリプトを記述
  - ジョブが実行するスクリプトを AWS Glue によって生成するのか、それとも自分で提供するのかを選択できます。
- スクリプトの名前と Amazon Simple Storage Service (Amazon S3) 内の場所を指定
Scala クラス名
- スクリプトが Scala で記述されている場合は、クラス名を指定する必要があります。AWS Glue 生成スクリプトのデフォルトのクラス名は [GlueApp]
一時ディレクトリ
- AWS Glue がスクリプトを実行するときに一時的な中間結果が書き込まれる Amazon S3 の作業ディレクトリの場所を指定
- パスの一時ディレクトリと同じ名前のファイルが存在していないことを確認します。このディレクトリは、AWS Glue から Amazon Redshift に読み書きするときに使用します。また、特定の AWS Glue 変換で使用

モニタリングオプション

連続ログ記録
- Amazon CloudWatch への連続ログ記録を有効にします。このオプションが有効になっていない場合、ログはジョブの完了後にのみ使用できます。

セキュリティ設定、スクリプトライブラリ、ジョブパラメータ

セキュリティ設定
- リストからセキュリティ設定を選択します。セキュリティ設定では、Amazon S3 ターゲットのデータの暗号化方法として、暗号化なし、AWS KMS で管理されたキー (SSE-KMS) を使用したサーバー側の暗号化、または Amazon S3 で管理された暗号化キー (SSE-S3) を使用したサーバー側の暗号化を指定
サーバー側の暗号化
- このオプションを選択すると、ETL ジョブが Amazon S3 に書き込むときに、データは SSE-S3 暗号化を使用して保管時に暗号化されます。Amazon S3 のデータターゲットと、Amazon S3 の一時ディレクトリに書き込まれるデータは、両方とも暗号化されています。
Python ライブラリパス、依存 jar パス、および参照ファイルパス
- これらのオプションはスクリプトで必要に応じて指定します。ジョブを定義するときに、これらのオプションのカンマ区切りの Amazon S3 パスを定義できます。ジョブ実行時にこれらのパスを上書きできます。
ワーカータイプ
- Standard
  - このタイプを選択する場合は、[最大キャパシティー] の値も指定します。最大キャパシティーは、このジョブの実行時に割り当てることができる AWS Glue データ処理ユニット (DPU) の数です。DPU は処理能力を相対的に測定するもので、4 個の vCPU のコンピューティング性能と 16 GB のメモリで構成されています。Standard ワーカータイプには、50 GB のディスクと 2 個のエグゼキュターがあります。
  - [ワーカー数] は [最大キャパシティー] の値から 1 を引いた数になります
- G.1X
  - タイプを選択する場合は、[ワーカー数] の値も指定します。各ワーカーは 1 DPU (4 vCPU、16 GB のメモリ、64 GB のディスク) にマッピングされており、ワーカーごとに 1 個のエグゼキュターがあります。メモリを大量に消費するジョブには、このワーカータイプをお勧め
- G.2X
  - このタイプを選択する場合は、[ワーカー数] の値も指定します。各ワーカーは 2 DPU (8 vCPU、32 GB のメモリ、128 GB のディスク) にマッピングされており、ワーカーごとに 1 個のエグゼキュターがあります。メモリを大量に消費するジョブには、ML 変換を実行するこのワーカータイプをお勧め
最大同時実行数
- このジョブで許可される同時実行の最大数を設定します。デフォルトは1です。このしきい値に達すると、エラーが返されます。指定できる最大値は、サービスの制限によって制御されます。たとえば、新しいインスタンスの開始時に前回のジョブがまだ実行されている場合、同じジョブの 2 つのインスタンスが同時に実行されないようにエラーを戻すことができます。
ジョブのタイムアウト
- 最大の実行時間 (分) を設定します。デフォルトは 2880 分です。この制限値をジョブ実行時間が超えると、ジョブ実行状態は「TIMEOUT」
遅延通知しきい値
- 遅延通知を送信するまでのしきい値 (分単位) を設定します。RUNNING、STARTING、または STOPPING ジョブの実行が想定時間 (分単位) を超えると通知を送信するように、このしきい値を設定
再試行回数
- 失敗した場合に AWS Glue がジョブを自動的に再起動する回数を 0〜10 の間で指定
ジョブパラメータ
- スクリプトに名前付きパラメータとして渡される一連のキーと値のペア。これらは、スクリプトの実行時に使用されるデフォルト値ですが、トリガーまたはジョブの実行時に上書きできます。キー名の前に -- を付ける必要があります (--myKey など)。AWS Command Line Interface を使用するときに、ジョブパラメータをマッピングとして渡します。
上書きできないジョブパラメータ

2

あなたの会社は、DevOps環境を構築する過程にあり、サーバーレスアーキテクチャと自動デプロイを使用して、社内リソースをすべてクラウドに移行しています。主な目的は、アプリケーションコードと同様にAWSリソースを管理できるようにすることです。様々なバージョンのインフラストラクチャを展開し、複数の環境に変更をステージングし、変数をアプリケーション環境に渡して、アプリケーションコードのようにインフラストラクチャをプログラムで管理できるシステムを構築することが求められています。

この要件を満たすソリューションを選択してください。

GITなどのバージョン管理システムと AWS CodeDeployとAWS CloudFormationを使用して、インフラストラクチャをデプロイおよび管理

AWS Elastic Beanstalk, AWS OpsWorks,AWS CodeDeploy, AWS CloudFormation を使った自動デプロイ

3

会社は複数のAWSアカウントによる管理を行っています。運用グループアカウントは2つの主要なEC2インスタンスを利用しています。開発グループアカウントでは、必要に応じて、運用グループアカウントが所有する２つのEC2インスタンスを随時開始/停止できることが求められています。現在、次のようなIAMの設定がされています。

・開発グループアカウントの IAMユーザーグループ：Development
・運用グループのEC2インスタンスを随時開始/停止することが可能なロール：EC2Admin
・開発グループアカウントではIAMグループDevelopmentにEC2Adminロールを引き受けるインラインポリシーが追加済み

２つのEC2インスタンスを随時開始/停止するためには、開発グループユーザーがログイン後に運用グループのEC2Adminを利用できる必要があります。

この要件を満たす最適な設定方法を選択してください。（2つ選択してください。）

ロールを切り替えるユーザーアクセス権限の付与

クロスアカウントアクセス用のロールを作成する場合、そのロールを所有するアカウントおよびリソース (信頼するアカウント) からユーザーを含むアカウント (信頼されるアカウント) への信頼を確立します。これを行うには、ロールの信頼ポリシーで信頼されるアカウント番号を Principal として指定します。これにより、信頼されたアカウント内のすべてのユーザーがロールを引き受けることができるようになる可能性があります。設定を完了するには、信頼されたアカウントの管理者がそのアカウント内の特定のグループまたはユーザーにロールを切り替えるアクセス権限を付与する必要があります。

ロールを切り替えるユーザーアクセス権限を付与するには、ユーザーの新しいポリシーを作成するか、既存のポリシーを編集して必要なエレメントを追加します。その後、詳細がすべてすでに入力されている [ロールの切り替え] ページへのリンクをユーザーに送信できます。または、アカウント ID 番号またはロールを含むアカウントエイリアスと、ロール名をユーザーに提供できます。これにより、ユーザーは [ロールの切り替え] ページに移動し、詳細を手動で追加できます。ユーザーがロールを切り替える方法について詳しくは、「ロールの切り替え (コンソール)」を参照してください。

ロールを切り替えることができるのは、IAM ユーザーとしてサインインしているときのみですのでご注意ください。AWS アカウントのルートユーザーとしてサインインすると、ロールを切り替えることはできません。

ロールの切り替え
- console
- cli
- api
- aws ps

4

開発者はEC2インスタンスとDynamoDBを連携させた決済アプリケーションを開発しています。DynamoDBテーブルとしてDataStockテーブルとAccountテーブルの２つを設定しています。このアプリケーションがデータを更新する際は、２つのDynamoDBテーブルを同時に更新するか、全く更新しないというデータ処理を実施する必要があります。

この要件に対応するために必要なDynamoDBの機能を選択してください。

DynamoDB トランザクションを利用することで、DynamoDBテーブル内およびテーブル間の複数の項目を調整したり、変更しないといった、開発者のエクスペリエンスを簡素化することができます。DynamoDB トランザクション読み取り/書き込み API を使用し、1 つのオースオアナッシングオペレーションとして複数の項目の追加、更新、または削除が必要となる複雑なビジネスワークフローを管理できます。
たとえば、ビデオゲーム開発者であれば、ゲーム内でのアイテム交換やゲーム内購入の際に、プレイヤーのプロファイル更新の正確性を確保できます。Amazon DynamoDB トランザクションを使用すると、複数のアクションをまとめてグループ化し、1 つのオールオアナッシングの TransactWriteItems または TransactGetItems オペレーションとして送信できます

DynamoDB のオンデマンドバックアップおよび復元

Amazon DynamoDB テーブルのオンデマンドバックアップを作成するか、ポイントインタイムリカバリによって連続バックアップを有効にすることができます。
- DynamoDB オンデマンドバックアップ機能を使用し、テーブルの完全なバックアップを作成して、規制やコンプライアンス要件を満たすために長期間の保存とアーカイブを行うことができます。
- テーブルのデータは、AWS マネジメントコンソールでワンクリックするか、単一の API コールを使用するだけで、バックアップおよび復元することができます。バックアップおよび復元アクションを実行しても、テーブルのパフォーマンスや可用性に影響を及ぼすことはありません。
- cli&console

オンデマンドバックアップ

AWS Lambda 関数を使用して、定期的バックアップまたは以降のバックアップをスケジュールできます。

スケジューリングスクリプトとクリーンアップジョブを作成したくない場合は、AWS Backup を使用して DynamoDB テーブルのスケジュールと保存ポリシーを含むバックアップ計画を作成できます。AWS Backup はバックアップを実行し、有効期限が切れると削除

復元

復元を実行するときに、次のテーブル設定を変更できます。

グローバルセカンダリインデックス (GSI)
ローカルセカンダリインデックス (LSI)
請求モード
プロビジョニングされた読み込みおよび書き込みキャパシティー
暗号化設定

復元されたテーブルで手動で設定する必要があります。

Auto Scaling ポリシー
AWS Identity and Access Management (IAM) ポリシー
Amazon CloudWatch メトリクスおよびアラーム
タグ
ストリーム設定
有効期限 (TTL) 設定

DynamoDB のポイントインタイムリカバリ

ポイントインタイムリカバリを使用することで、オペレーションによって DynamoDB テーブルが誤って上書きされたり削除されたりしないようにできます。ポイントインタイムリカバリを有効化すれば、オンデマンドバックアップの作成、維持、スケジュールを心配する必要はありません。テストスクリプトで、誤って本稼働環境の DynamoDB テーブルに書き込みを行ったとします。ポイントインタイムリカバリを使用すれば、過去 35 日間の任意の時点にテーブルを復元することができます。DynamoDB では、テーブルの増分バックアップが維持されます。

ポイントインタイムリカバリ: 仕組み

Amazon DynamoDB ポイントインタイムリカバリ (PITR) は、DynamoDB テーブルデータを自動バックアップする機能

ポイントインタイムリカバリは、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または DynamoDB API を使用して有効にできます。有効化されると、ポイントインタイムリカバリは、明示的に無効化するまで、連続バックアップを行います。

EarliestRestorableDateTime では、過去 35 日間の任意の時点にテーブルを復元できます。保持期間は、35 日間 (5 週間) に固定されており、変更することはできません。任意の数のユーザーが、特定のアカウントで最大 4 つの同時復元 (任意のタイプの復元) を実行

グローバルテーブル: DynamoDB を使用した複数リージョンレプリケーション

Amazon DynamoDB グローバルテーブルは、マルチリージョンにマルチマスターデータベースをデプロイするための完全マネージド型のソリューションです。独自のレプリケーションソリューションを構築および管理する必要はありません。グローバルテーブルを使用すると、そのテーブルの利用を許可する AWS リージョンを指定できます。DynamoDB では、これらのリージョンに同一のテーブルを作成するのに必要なすべてのタスクを実行し、変更中のデータをすべてのテーブルに伝達します。

DynamoDB トランザクションで複雑なワークフローを管理する

Amazon DynamoDB トランザクションは、テーブル内およびテーブル間の複数の項目を調整したり、変更しないといった、開発者のエクスペリエンスを簡素化します。トランザクションによって DynamoDB に不可分性、一貫性、分離性、耐久性 (ACID) が実現されるため、アプリケーション内でのデータの精度を維持することができます。

DynamoDB トランザクション読み取り/書き込み API を使用し、1 つのオースオアナッシングオペレーションとして複数の項目の追加、更新、または削除が必要となる複雑なビジネスワークフローを管理できます。たとえば、ビデオゲーム開発者であれば、ゲーム内でのアイテム交換やゲーム内購入の際に、プレイヤーのプロファイル更新の正確性を確保できます。

トランザクション書き込み API を使用して、複数の Put、Update、Delete、ConditionCheck の各アクションをグループ化できます。その後、アクションを単一の TransactWriteItems オペレーションとして送信できます。このオペレーションはユニットとして成功または失敗します。同じことが複数の Get アクションにも当てはまります。この場合、1 つの TransactGetItems オペレーションとしてグループ化し、送信できます。

DynamoDB テーブルのトランザクションを有効にするために、追加料金はかかりません。トランザクションの一部となっている読み取りまたは書き取りにのみ料金が発生します。DynamoDB は、トランザクション内の各項目の基になっている 2 つの読み取りまたは書き込みを実行します。1 つはトランザクションの準備用で、もう 1 つはトランザクションのコミット用です。これらの基になっている 2 つの読み取り/書き込みオペレーションは、Amazon CloudWatch メトリクスに表示されます。

Amazon DynamoDB トランザクション: 仕組み

Amazon DynamoDB トランザクションを使用すると、複数のアクションをまとめてグループ化し、1 つのオールオアナッシングの TransactWriteItems または TransactGetItems オペレーションとして送信できます。

[速報]待望のDynamoDBのトランザクションがリリースされました！ #reinvent

「トランザクション」とは何か？を超わかりやすく語ってみた！

5

証券会社A社ではオンプレミスシステムを使用して取引データを分析しています。実行レポートや市場パフォーマンスなどのデータは、翌日の取引予測向けのビッグデータ分析ツールを実行するRedhatサーバーに送信されます。データ分析ワークロードを実行するタイミングをスケジュールするために bashスクリプトを利用しています。会社の経営陣は、オンプレミス環境からAWSへとアプリケーションを移行することを決定したため、あなたは移行方法を検討しています。

このシステムを移行するための最適なソリューションを選択してください。

ビッグデータ解析用サーバーとして現在はRedhatサーバーを利用していますが、これをEC2インスタンスに移行してビッグデータ解析ソフトウェアごとAWS環境に展開します。次にデータ蓄積用にはS3 Standardクラスに取引データ蓄積することが最適です。S3は可用性が高く、耐久性があり、費用効率が高いため、取引データを保存するのに理想的な場所です。データ分析タスクのスケジュールに使用されるbashスクリプトをAWS Batchに移行して実行することが可能です。 AWS Batchスケジューラはbashスクリプトによるジョブをいつ、どこで、どのように実行するかを評価します。

他のバッチ機能との使い分け

AWS Batchは上記項目の対応範囲が広く、また細かく要件を詰められる為上記をゴリッゴリに弄りたい際には有用なサービス

ジョブが15分程度であればsqs lambdaが良い

6

独自のドメイン名と独自のSSL証明書を使用してHTTPS経由でコンテンツを配信する

カスタムSSL証明書を使用することが必要です。

AWSで利用するSSL証明書管理をIAMからACMに変更するべき理由

7

A社ではビデオ共有アプリケーションを開発しています。このアプリケーションではユーザー間で短いビデオを作成して公開したり、ビデオを特定ユーザーと共有することができます。アーキテクチャ要件としては、ビデオはAWS上にアップロードしたのち、ユーザーはモバイルアプリケーションを介して、HTTPライブストリーミング（HLS）形式を使用してオンデマンドまたはライブビデオを再生できるようにします。

この要件を達成するために、どのAWSサービスの組み合わせを使用する必要がありますか？（2つ選択してください。）

Kinesis Video Streams の HTTP Live Streaming (HLS) 機能を使用して、ライブ動画や録画したメディアを Kinesis Video Streams からお使いのブラウザまたはモバイルアプリケーションに簡単にストリーミングできます。

GetHLSStreamingSessionURL APIによりHLSストリーミングセッションURLを取得することができます。 HLSストリーミングセッションURLを取得したら、ビデオを再生できるビデオプレーヤーに提供します。

Amazon Kinesis ビデオストリーム: 仕組み

Amazon Kinesis ビデオストリームは完全マネージド型の AWS のサービスで、ライブ動画をデバイスから AWS クラウドにストリーミングし、永続的に保存できるようにします。その後、リアルタイムで動画を処理するために独自のアプリケーションを構築するか、バッチ指向の動画分析を実行できます。

Kinesis ビデオストリーム再生

GetMedia: GetMedia API を使用して、Kinesis ビデオストリームを処理する独自のアプリケーションを構築できます。GetMedia は低レイテンシーのリアルタイム API です。GetMedia を使用するプレーヤーを作成する場合は、自分で構築する必要があります。GetMedia を使用して Kinesis ビデオストリームを表示するアプリケーションを開発する
HLS: HTTP Live Streaming (HLS) は、業界標準の HTTP ベースのメディアストリーミング通信プロトコルです。HLS を使用して、ライブ再生またはアーカイブ済み動画の再生用に Amazon Kinesis ビデオストリームを表示できます。

HLS はライブ再生に使用できます。通常、レイテンシーは 3〜5 秒ですが、ユースケース、プレーヤー、およびネットワーク条件に応じて 1〜10 秒になる場合もあります。サードパーティー製のプレーヤー (Video.js や Google Shaka Player など) を使用して動画ストリームを表示するには、HLS ストリーミングセッション URL をプログラムまたは手動で指定できます。動画を再生するには、Apple Safari ブラウザまたは Microsoft Edge ブラウザのロケーションバーに HLS ストリーミングセッション URL を入力することもできます。

MPEG-DASH: Dynamic Adaptive Streaming over HTTP (DASH) (MPEG-DASH とも呼ばれる) は、従来の HTTP ウェブサーバーから配信されたインターネット経由で高品質のストリーミングを可能にする適応ビットレートストリーミングプロトコルです。

MPEG-DASH はライブ再生に使用できます。通常、レイテンシーは 3〜5 秒ですが、ユースケース、プレーヤー、およびネットワーク条件に応じて 1〜10 秒になる場合もあります。サードパーティー製のプレーヤー (dash.js や Google Shaka Player など) を使用して動画ストリームを表示するには、MPEG-DASH ストリーミングセッション URL をプログラムまたは手動で指定できます。

GetClip API: API GetClip を使用して、指定した時間範囲において、アーカイブされたオンデマンドメディアを含むクリップ (MP4 ファイル) を、指定したビデオストリームからダウンロードできます。

HLS を使用した動画再生

HLS を使用して Kinesis ビデオストリームを表示するには、まず、GetHLSStreamingSessionURL を使用してストリーミングセッションを作成します。このアクションにより、HLS セッションにアクセスするための URL (セッショントークンを含む) が返されます。次に、この URL をメディアプレーヤーまたはスタンドアロンアプリケーションで使用してストリームを表示できます。

MPEG-DASH を使用した動画再生

MPEG-DASH を使用して Kinesis ビデオストリームを表示するには、まず GetDASHStreamingSessionURL を使用してストリーミングセッションを作成します。このアクションにより、MPEG-DASH セッションにアクセスするための URL (セッショントークンを含む) が返されます。次に、この URL をメディアプレーヤーまたはスタンドアロンアプリケーションで使用してストリームを表示できます。

8

メディア企業は、自社のさまざまなオンプレミス製品とサービスをAWSプラットフォームに移行することに取り組んでいます。データセンターにおいてWEBサーバーとしてIBM WebSphereを利用して、データベースとしてIBM DB2サーバーを利用しています。会社はこれらのIBM製品ベースのアーキテクチャをAWSに移行することを決定しました。要件としては、ウェブサーバーはリホスト方式で、データベースはリプラットフォーム方式で実施することになります。

次の中から費用対効果が高いAWSへの移行方法を選択してください。

EC2インスタンスにソフトウェアをインストールする方式で、IBM WebSphereを移行することができます。その際にEC2インスタンスにELBとAuto Scalingグループをセットアップして、可用性の高いアーキテクチャとすることが望ましいです。データベースはAWSクラウドサービスへとリホストするため、AWS Database Migration Service（DMS）およびAWS Schema Conversion Tool（SCT）を使用し、Linux、UNIX、およびWindows（DB2 LUW）上のIBM DB2データベースを、DMSがサポートするターゲットに変換して移行できます。これにより、より多くのレガシーデータベースを移行できるため、クラウドへの移行を加速できます。したがって、オンプレミスのDB2ソースは、AWS Database Migration Service（DMS）およびAWS Schema Conversion Tool（SCT）を使用して、IBM Db2データベースをAmazon Auroraに変換および移行することができます。

rehost
- 構成変更なし
replatform
- 構成変更

9

B社のビデオアプリケーションは、単一のリージョンの複数のアベイラビリティーゾーンにデプロイされます。ワークロードの多くが超高速ディスクIOを必要とするため、ビデオプロバイダーはEC2インスタンスストアボリュームの大部分を利用して提供されています。一時データ領域としてインスタンスストアボリュームを利用していますが、インスタンスストアボリュームをバックアップするための適切な方法を検討する必要があります。

インスタンストアのバックアップソリューションとして最適な方法を選択してください。

インスタンスストアにバックアップされたLinux AMIを作成するには、既存のインスタンスストアにバックアップされたLinux AMIから起動したインスタンスを利用します。ニーズに合わせてインスタンスをカスタマイズしたら、ボリュームをバンドルし、これらのカスタマイズで新しいインスタンスを起動するために使用できる新しいAMIを登録します。インスタンスストアボリュームのAMI作成プロセスは、Amazon EBS-backed AMIとは異なり、コンソール画面から実行できません。 ec2-bundle-volやec2-upload-bundleなどのAMIツールが必要です。

10

製造業A社ではアプリケーションをAWSに移行することを計画しています。あるWebサービスでは、MongoDBを使用してユーザーサブスクリプション情報を保存していました。あなたはソリューションアーキテクトとして、Java AWS SDKを使用して、NoSQLデータベースをAWSのDynamoDBに移行しました。移行後、DynamoDBテーブルで多数のProvisionedThroughputExceededExceptionエラーが発生していることを発見しました。

次のProvisionedThroughputExceededExceptionを減らすために取るべき対処方法の中で、間違いである内容はどれでしょうか？

Amazon DynamoDB には、テーブルで読み込みおよび書き込みを処理するための読み込み/書き込みキャパシティーモードが 2 つあります。プロビジョニングモードのテーブルでは、読み込みキャパシティーユニット (RCU) と書き込みキャパシティーユニット (WCU) の観点でスループットキャパシティーを指定できます。リクエストスループットは、プロビジョニングされた容量を超えると調整され、リクエストが失敗します。その際にProvisionedThroughputExceededExceptionという例外エラー表示が発生します。

読み込み/書き込みキャパシティーモード

オンデマンドモード
- 使用した分だけ課金
プロビジョニングモードを選択した場合、アプリケーションに必要な 1 秒あたりの読み込みと書き込みの回数を指定します。Auto Scaling を使用すると、トラフィックの変更に応じて、テーブルのプロビジョンドキャパシティーを自動的に調整できます。これにより、コストの予測可能性を得るため、定義されたリクエストレート以下に維持されるように DynamoDB を制御することができます。

11

B社のビデオアプリケーションは、東京リージョン（ap-northeast-1）に複数のEC2インスタンスを展開しており、ユーザーアクティビティの監視を実施しています。あなたは運用担当者として、EBSライフサイクルポリシーを設定して、データ保護のために各EBSボリュームのスナップショットを毎日作成しています。スナップショットの保存期間は10日に設定しています。これらのスナプショットには重要なデータが含まれているため、別のリージョン（ap-northeast-2）にコピーする必要があります。

コピーされたスナップショットの保持期限はどのように設定されますか？

スナップショットのコピーはもともとの保持スケジュールの影響を受けません。

12

製造業A社ではアプリケーションをAWSに移行することを計画しています。総所有コスト（TCO）分析の後、Amazon S3をストレージに使用することが決定されました。A社ではAmazon S3を使用して法的文書やその他のメディアファイルを保存することを想定しています。ユーザーエクスペリエンスを向上させるために、シングルサインオンを実装し、ユーザーが既存のActive Directoryログインを使用してAWSリソースにアクセスできるように設定したいと考えています。各ユーザーのアクセスをバケット内の指定されたユーザーフォルダーに制限することが必要です。

これらの要件を満たすために、最適なアーキテクチャを選択してください。（2つ選択してください。）

13

あなたはサーバレスを得意とした開発者としてA社で勤務しています。現在、A社ではAWS CloudFormationを使用してLambdaをアップロードおよび更新するセットアップを準備しています。

CloudFormationでパラメーターを設定する方法を選択してください。（2つ選択してください。）

AWS::Lambda::Functionを利用して、Lambda 関数のデプロイパッケージをCloudFormationで参照します。すべてのランタイムに対して、Amazon S3 内のオブジェクトの場所を指定できます。

Node.js および Python 関数の場合で依存関係がない限りテンプレートにインラインで関数コードを指定できます。

Lambda リソースタイプのリファレンス

14

A社ではEC2インスタンスとEFSボリュームで構成されたアプリケーションを開発しています。あなたはソリューションアーキテクトとして、これらのEFSファイルシステムをEC2インスタンスにマウントするため、インスタンスにEFSマウントヘルパーをインストールしました。データは転送中に暗号化することが必要です。

EFSのマウントヘルパーの適切な使用方法はどれでしょうか？（3つ選択してください。）

Amazon EFS ファイルシステムを作成するには、マネジメントコンソールの設定画面の「VPC] でEFSボリューム向けにインスタンスがあるVPCにマウントターゲットを設定

コンソールまたは実行コードによって、EFSファイルシステムIDをEFS APIから取得して、EC2インスタンスからのアクセスの際に設定することが求められます。EFSファイルシステムIDを利用してEC2 インスタンスを起動し、EFS ファイルシステムをマウント

マウントヘルパーユーティリティのamazon-efs-utils パッケージには、マウントヘルパーおよび Amazon EFS の転送時のデータ暗号化の実行を簡単にするツールが用意されています。マウントヘルパーユーティリティを利用した際に、暗号化オプション「-o tls」を追加することが可能

AWS再入門 Amazon Elastic File System編

Amazon Elastic File System（以下、Amazon EFS）は、シンプルで、スケラーブル、伸縮自在なフルマネージドな共有ストレージサービスです。Amazon EC2やオンプレミスリソースから使用できます。NFSバージョン4.0または4.1使用して、VPC上に作成したAmazon EFSファイルシステムをマウントし、共通データの読み書きを可能にします。

Amazon EFS では、ファイルシステムで使用されるストレージに対してのみ支払いを行い、最低料金やセットアップ料金はありません。Amazon EFS には、スタンダードアクセスと低頻度アクセスの 2 つのストレージクラスがあります。

Amazon EFS が AWS Direct Connect と AWS マネージド VPN で動作する仕組み

オンプレミスサーバーにマウントされた Amazon EFS ファイルシステムを使用すると、オンプレミスのデータを Amazon EFS ファイルシステムにホストされている AWS クラウドに移行できます。バーストを活用することもできます。つまり、オンプレミスサーバーから Amazon EFS にデータを移動し、Amazon VPC のフリートの Amazon EC2 インスタンスのフリーとで分析することができます。その後、結果をファイルシステムに永続的に保存するか、結果をオンプレミスサーバーに戻すことができます。

Amazon EFS と AWS Backup の連携

ファイルシステムの包括的なバックアップの実装では、Amazon EFS と AWS Backup を使用できます。AWS Backup は、クラウドおよびオンプレミスの AWS サービス間でのデータバックアップの集中化と自動化を容易にする完全マネージド型バックアップサービスです。AWS Backup を使用すると、バックアップポリシーを集中的に設定し、AWS リソースのバックアップアクティビティを監視できます。Amazon EFS は常にバックアップオペレーションよりもファイルシステムオペレーションを優先します。

ストレージクラスとライフサイクル管理

スタンダード
- スタンダードストレージクラスは、頻繁にアクセスされるファイルを格納するために使用
低頻度アクセス
- 低頻度アクセス (IA) ストレージクラスは、低コストのストレージクラスで、アクセス頻度が低く長期間保存されるファイルをコスト効率よく格納するように設計

amazon-efs-utils

amazon-efs-utils パッケージは、Amazon EFS ツールのオープンソースのコレクションです。amazon-efs-utils は追加コストなしで使用でき、 https://github.com/aws/efs-utilsで、GitHub からこれらのツールをダウンロードできます。amazon-efs-utils パッケージは、Amazon Linux パッケージリポジトリで利用でき、他の Linux ディストリビューションのパッケージをビルドおよびインストールできます。

amazon-efs-utils パッケージには、マウントヘルパーおよび Amazon EFS の転送時のデータ暗号化の実行を簡単にするツールが用意されています。マウントヘルパーは、特定のタイプのファイルシステムのマウント時に使用するプログラムです。Amazon EFS ファイルシステムをマウントするために、amazon-efs-utils に含まれているマウントヘルパーを使用することをお勧めします。

15

あなたはS3に格納してある大量の顧客リストに対して、リストコマンドを実行しましたが、1,000 というデフォルトのページサイズが大きすぎて、エラーが発生してしまいました。対応として、使用するAPIコール数を最小限に抑えてページごとに100の結果をユーザーに表示させようと考えています。そのためには、S3から出力されるリスト結果をページ分割する必要があります。

どのCLIオプションを使用する必要がありますか？（2つ選択してください。）

AWS CLI 出力で一度に含める項目を少なくするには、--max-items オプションを使用

--page-size オプションを使用して、AWS CLI が AWS のサービスの 1 回の呼び出しで要求する項目数を少なくすることができます。その場合でも、CLI は完全なリストを取得しますが、多数のサービス API コールをバックグラウンドで実行し、1 回の呼び出しで取得する項目数が少なくなります。このため、個々の呼び出しがタイムアウトにならずに成功する可能性が高くなります。ページサイズを変更しても、出力には影響しません。出力を生成するために必要な API 呼び出しの数が変わるだけです。

16

B社では東京リージョンでEC2インスタンスとDynamoDBで構成された多層Webアプリケーションを展開しています。アプリケーションはリージョン内の複数のアベイラビリティーゾーンにまたがるクラスターで実行されている複数のAmazon EC2インスタンスにホストしています。あなたはソリューションアーキテクトとして、最高のネットワークパフォーマンスと、最低のアクセス遅延を担保するためにリファクタリングするようにマネージャーより依頼されました。

これらの要件を満たすために、最適なアーキテクチャを選択してください。（２つ選択してください。）

HVM AMI は、完全に仮想化された一連のハードウェアを備えており、イメージのルートブロックデバイスのマスターブートレコードを実行することによって起動します。この仮想化タイプでは、ベアメタルハードウェア上でオペレーティングシステムが動作するのと同様に、修正を行わなくても仮想マシン上でオペレーティングシステムを直接実行することができます。PV AMIとは異なり、HVM AMIは、ホストシステム上の基盤となるハードウェアへの高速なアクセスを可能にするハードウェア拡張を利用できます。

拡張ネットワーキングでは、シングルルート I/O 仮想化 (SR-IOV) を使用して、サポートされるインスタンスタイプにおける高性能ネットワーキング機能が提供されます。SR-IOV は、従来の仮想化ネットワークインターフェイスと比較し、I/O パフォーマンスが高く、CPU 利用率が低いデバイス仮想化の手法です。拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。

EC2をHVMに移行するモチベーション – AWS Advent Calendar 2014：9日目

17

A社ではWEBサーバーとアプリサーバーとして利用する20個以上のEC2インスタンスとデータ保存先としてS3で構成されたアプリケーションを開発しています。あなたは運用担当者として、AWS Systems Managerを使用して、すべてのEC2インスタンスが午前0:00になると定期的にログをS3バケットに送信する設定を実施しています。

この要件を満たすために、AWS Systems Managerの設定方法を選択してください。

AWS Systems Manager ステートマネージャーは、安全でスケーラブルな設定管理サービスであり、Amazon EC2 およびハイブリッドインフラストラクチャを、定義された状態に保つプロセスを自動化します。シェルスクリプトによって、午前0:00にCE2インスタンスからS3バケットにログを取得する設定が可能です。

AWS Systems Manager

共有リソース
- SSM Documents
  - 管理対象のインスタンスに対して実行するアクションを定義
- Parameter Store
  - Parameter Storeでは、設定データ管理と機密管理のための安全な階層型ストレージが提供されています。パスワード、データベース文字列、ライセンスコードなどのデータをパラメータ値として保存
- 有料のシークレットマネージャを使う
グループ化
- OpsCenter
  - Automation Documentと組み合わせることで、CloudWatch Events発生をトリガーとした自動復旧の機構を用意することも可能
- Resource Groups
  - AWSリソースのコレクションを管理
スケジューリング
- Maintenance Windows
  - スケジュール定義する機能
オペレーション
- Run Command
  - 事前に定義したSSM DocumentをSSM Agent導入済みの管理対象インスタンスに対して実行
- Automation
  - 自動化ワークフローを構築して、インスタンスおよびAWSリソースを管理
- Distributer
  - Distributerを利用すれば、独自のソフトウェアをパッケージ化したり、AmazonCloudWatchAgentなどのAWS提供のエージェントソフトウェアパッケージを見つけて、管理対象インスタンスにインストール(Run Commandで1回のみ/State Managerでスケジュール)することが可能
- Session Manager
  - インバウンドポートを開いたり、踏み台ホストを維持したり、SSHキーを管理したりすることなく、安全で監査可能なインスタンスの管理することを可能
構成情報の集約・監査
- State Manager
  - ポリシーに準拠したあるべき設定を維持する為に利用
  - あるべき姿をSSMドキュメントとして定義
  - 管理対象リソースとSSMドキュメントを関連付け
  - スクリプトを使う
- Inventory
  - Inventoryにより、管理対象上のアプリケーション一覧など構成情報を記録することができます。AWS Configに構成情報を送信して、Config Rulesと組み合わせて管理を行ったり、S3に保存した構成情報をAthena & QuickSightで可視化して分析することも可能です
- Patch Manager
  - windowsとlinuxで違う

18

C社はアートオークションプラットフォームを構築しているアートテック企業です。オークションはリアルタイムで価格決定処理を実施することが必要となるため、このプラットフォームでは、オークション処理において厳密な処理順序が要求されており、買い手からの価格決定トランザクションが、受け取った順序どおりに処理される必要があります。

このトランザクション処理を実装する方式を選択してください。（2つ選択してください）

メッセージグループID

FIFOキュー

Amazon SQS メッセージグループ ID の使用
https://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html

19

A社はAWSのサーバレスアーキテクチャを社内で新規採用することになり、AWS Lambda、API Gateway、およびDynamoDBを単一のスタックで構成した新しいサーバーレスアーキテクチャを実装することになりました。あなたはエンジニアとして、全APIリクエストへの認証を提供し、APIへのアクセスを制御する対応を要求されています。 OAuthまたはSAMLに類似した認証方式を実装することが必要です。

この要件を達成するため最適な方法を選択してください。

トークンベースの Lambda オーソライザー (TOKEN オーソライザーとも呼ばれる)

Lambda オーソライザーの認証の流れ

トークンベースの Lambda オーソライザー
- JSON ウェブトークン (JWT) や OAuth トークンなどのベアラートークンで発信者 ID を受け取ります。
リクエストパラメータベースの Lambda オーソライザー
- ヘッダー、クエリ文字列パラメータ、stageVariables、および $context 変数の組み合わせで、発信者 ID を受け取ります。

APIの管理

API管理は以下の四種類

リソースポリシー
- AWSアカウントのIAMユーザー
- ソースIP
- VPCまたはVPCエンドポイント
IAM認証
- ロールやポリシー
lmabdaオーソライザー
cognitoオーソライザー