Amazon Web Services ブログ

S3 ストレージ管理アップデート – 分析、オブジェクトのタグ付け、インベントリ、メトリクス

by AWS Japan Staff | on | in Amazon S3 |

本日、皆様がお持ちのストレージとそのアクセスパターンを詳しく知るための 4 つの S3 機能についてご説明したいと思います。何をどのくらい保管しているのか、どのように使用しているのかを知ることができ、その結果として、S3 ストレージクラスの使用に関する情報に基づいた意思決定を行うことができます。これらの機能は、バケットに何十万、何千、何百万、何十億というオブジェクトを持っていても、S3 を使用するすべての人にとって価値があります。

以下が概要です:

S3 分析 – オブジェクトの格納状況と取得パターンを分析し、その結果を使って、最適なストレージクラスを選択することができます。あなたは S3 コンソールで表示される分析の結果を検査したり、お好みの BI ツールにロードし深掘りしても良いでしょう。そうすることで、ストレージの利用傾向を見て、それらが使い方や成長度合いにどのように関連しているのかがつかめます。

S3 オブジェクトのタグ付け – 複数のキーと値のペア(タグ)をそれぞれの S3 オブジェクトに関連付けることができ、いつでも変更することができます。タグは、アクセスの管理と制御、S3 ライフサイクルポリシーの設定、S3 分析のカスタマイズ、CloudWatch メトリクスのフィルタリングに使用できます。バケットをデータレイクと考えることができ、タグを使用してそのデータレイクの中のオブジェクトの分類を作成できます。これは、バケットとプレフィックスを使用するよりも柔軟性があり、オブジェクトの名前を変更、移動、またはコピーせずに意味付けの変更を行うことができます。

S3 インベントリ – S3 インベントリを使用して、ビジネスワークフローやビッグデータのジョブを加速できます。この機能は、毎日または毎週の単位で、バケットの全部または一部の内容(プレフィックスによって識別される)の CSV 形式のフラットファイル表現を提供します。

S3 CloudWatch メトリクス – 13 種類の Amazon CloudWatch メトリクスを監視やアラームを設定することで、S3 を活用するアプリケーションのパフォーマンスを向上させる可能性があります。

詳細を見てみましょう。

S3 分析
S3 のユーザは、標準、標準 IA (標準低頻度アクセス)、Glacier と 3 つのストレージクラスを選択することができます。S3 のオブジェクトライフサイクル管理を使用して、オブジェクトが期限切れになるか、標準 IA もしくは Glacier に移行するかを指定することができます。

S3 分析機能は、オブジェクトについて、標準と標準 IA のどちらを選択したら良いのかの必要な情報を提供します。多くの顧客は、処理を容易にするために、複数の異なるタイプまたはカテゴリの情報を 1 つのバケットに格納するため、バケット内のオブジェクトのサブセット(共通のプレフィックスまたはタグ値によって定義)で分析を実行できます。各サブセットはフィルタによって定義されます。各バケットは最大 1,000 のフィルタを持つことができます。私の jbarr-public バケットのフィルタは次のとおりです:

プレフィックスが www で始まるオブジェクトを分析する簡単なフィルタを定義する方法は次のとおりです:

代わりにタグ名と値でフィルタリングすることができます。type という名前のタグに page という値を持つオブジェクトを分析する方法は次のとおりです:

各フィルタは、任意の好みの数のタグが付いた、多くとも1つのプレフィックスを指定することができます。分析内容を毎日ファイルにエクスポートすることもできます:

1 つ以上のフィルタが配置されると、分析は毎日実行され、フィルタをクリックするだけで分析を表示できます。たとえば、私の Archive と設定したフィルタをクリックすると、次のように表示されます:

この分析から、多くの良い情報が読み取れます!以下のようなことがわかります。

  • 127 日を振り返ってみると、30 日以上経過したオブジェクトのほとんどはアクセス頻度が低いことがわかります。私は、これらのオブジェクトを標準 IA のストレージに移行するライフサイクルルールを作成することで、コストを削減できます。
  • この時点で、私のストレージの大半(6.39 PB)は標準ストレージにあり、ほんの少しだけが標準 IA にあります(実のところ、私のバケットにはあまりデータがありませんでした。S3 チームは、私のアカウントにいくつかのテスト用メトリクスをロードしてくれました。非常に寛大です!)。
  • 127 日間の観測期間にわたって、標準ストレージの 16 %から 30 %くらいのデータが 1 日単位で、リトリーブされました。
  • 30 〜 45 日後、45 〜 60 日後、60 〜 90 日後、90 〜 180 日後、180 日以上後のオブジェクトは、まれにしかアクセスされず、標準 IA に配置するのに適しています。

ストレージクラス分析は、コンソール、CLI、または S3 API を使用して設定できます。

詳細は、Amazon S3 分析 – ストレージクラス分析 をご覧ください。

S3 オブジェクトのタグ付け
既存のロケーションベースの S3 オブジェクト管理モデル(バケットとプレフィックス)加えて、タグ付けは、そのオブジェクトは何か?という観点に基づいてストレージを管理する機能を提供してくれます。たとえば、部門の名前でオブジェクトをタグ付けし、そのタグに基づいてアクセスを許可する IAM ポリシーを構築することができます。これにより、単にタグを変更するだけで変更を反映させることができるなど、多くの柔軟性が得られます。

オブジェクトのライフサイクルのどの部分でも、それらを作成、更新、または削除することができます。タグは、IAM ポリシー、S3 ライフサイクルポリシー、および先ほど紹介した分析フィルタで参照できます。各オブジェクトは最大 10 個のタグを持つことができ、オブジェクトの各バージョンは異なるタグセットを持ちます。タグを利用して、ライフサイクルポリシーにてオブジェクトの有効期限を管理したり、特定のタグに関するアクティビティを反映する CloudWatch メトリクスを設定しても良いでしょう。

各オブジェクトのプロパティページには、現在のタグセットが表示され、それらのタグを編集できます:

また、CLI または S3 API からタグを設定してアクセスすることもできます。これら 2 つの方法のいずれかを使用する場合は、常に完全なタグセットの単位で設定する必要があります。たとえば、オブジェクトに 4 つのタグがあり、5 つ目のタグを追加する場合は、現在のセットを読み込み、新しいセットを追加してから、セット全体を更新する必要があります。

タグは、クロスリージョンレプリケーションを介してリージョン間で複製できますが、ソース側の IAM ポリシーでは s3:GetObjectVersionTagging 及び s3:ReplicateTags アクションを有効にする必要があります。

タグの費用は、10,000 個のタグにつき月額 0.01 ドルです。タグを追加または更新するリクエスト(それぞれ PUT および GET)は、通常の料金で課金されます。

詳細は、S3 オブジェクトのタグ付け を参照してください。

S3 インベントリ
S3 の LIST 操作は同期的で、一度に 1,000 個までのオブジェクトと、2 回目の LIST を開始するために使用するキーを返します。これは小規模から中規模のバケットやシングルスレッドのプログラムでは効果的ですが、大規模なバケットや複数のスレッドと組み合わせて使用するのは難しくなるかもしれません。

S3 インベントリを使用すると、バケットのインベントリレポートを毎日または毎週という形で受け取ることができます。プレフィックスを使用してレポートをフィルタリングしたり、サイズ、ストレージクラス、およびレプリケーションステータスなどをオプションのフィールドとして含めることができます。レポートは、ご自身のアカウントの S3 バケットに送信することも、適切な権限設定を使用して別のアカウントに送信することもできます。

以下は、www で始まるすべてのオブジェクトに対して、WebStuff という名前の、毎日のインベントリレポートをリクエストする方法の例です:

また、宛先のバケット(jbarr-s3-inventory)に書き込むための S3 権限を与える必要があります。使用したポリシーは次のとおりです(詳細は、Amazon S3 インベントリおよび Amazon S3 分析に対するアクセス権限の付与 を参照):

このインベントリのメカニズムは、マニフェスト、マニフェストのチェックサム、およびデータファイルの 3 つのファイルを作成します。マニフェストには、データファイルの場所とチェックサムが格納されています:

{
   "sourceBucket":"jbarr-public",
   "destinationBucket":"arn:aws:s3:::jbarr-s3-inventory",
   "version":"2016-11-30",
   "fileFormat":"CSV",
   "fileSchema":"Bucket, Key, Size, LastModifiedDate, ETag, StorageClass",
   "files":[
      {
         "key":"jbarr-public/DailyInventory/data/cf1da322-f52b-4c61-802a-b5c14f4f32e2.csv.gz",
         "size":2270,
         "MD5checksum":"be6d0eb3f9c4f497fe40658baa5a2e7c"
      }
   ]
}

解凍された後のデータファイルの外観は次のとおりです:

インベントリレポートを使用して毎日または毎週の処理ワークフローを強化する場合は、S3 通知機能の設定を忘れないでください!チェックサムファイルは他の 2 つのファイルの後に書かれていますので、安心して活用することができます。また、ライフサイクルポリシーを使用して、累積されていくインベントリファイルのコレクションを管理することを忘れないでください。

補足として、毎日または毎週のレポートを使用すると、複数の LIST 操作を何度も行うことと比較して最大 50 %節約できます。この機能の詳細については、Amazon S3 ストレージインベントリを参照してください。

S3 CloudWatch メトリクス
S3 は、ストレージ、リクエスト、およびデータ転送のメトリクスを CloudWatch に公開できるようになりました。ストレージメトリクスについては毎日レポートされ、追加料金なしで利用できます。リクエストとデータ転送のメトリクスは 1 分間隔で(処理待ち時間の後に)利用可能で、いつもの CloudWatch 課金レートで請求されます。 S3 分析の場合と同様に、CloudWatch メトリクスは、バケット全体でレポート化できますし、プレフィックスまたはタグを介して選択されたサブセットについて収集してレポート化することもできます。

メトリクスのフルセットは次のとおりです:

Storage Requests Data Transfer
  • Bucket Size Bytes
  • Number Of Objects
  • GET
  • LIST
  • PUT
  • POST
  • DELETE
  • ALL
  • HEAD
  • 4xx Errors
  • 5xx Errors
  • Total Request Latency
  • First Byte Latency
  • Bytes Uploaded
  • Bytes Downloaded

このメトリクス、S3 および CloudWatch コンソールで利用できます。私のバケットの S3 コンソールでの Total Request Latency の外観は次の通りです:

View in CloudWatch (CloudWatch で表示)をクリックし、任意のメトリックの CloudWatch アラームを設定することもできます。こちらは、私のバケットが 100 MB より大きくなった場合、通知を受けようと設定しているところです:

詳細は、S3 バケットにリクエストメトリクスを設定する方法 をご覧ください。

今すぐ利用可能
昨年末に、これらの機能にアクセスできるようになりました。アップデートされた S3 Console からアクセスできます。他にも多くの新機能が含まれています(詳しくは Introduction to the New Amazon S3 Console をご覧ください)。

– Jeff ; (原文:S3 Storage Management Update – Analytics, Object Tagging, Inventory, and Metrics / 翻訳: SA 焼尾)

 

Amazon Auroraアップデート: クロスリージョン・クロスアカウントサポートの拡張、T2.Small DBインスタンス、リージョンの追加

by AWS Japan Staff | on | in Amazon Aurora, Amazon RDS |

Amazon Auroraの最近のアップデートを振り返ってみたいと思います。Amazon AuroraはMySQL互換のハイパフォーマンスなデータベースです(間もなくPostgreSQL互換のAuroraもリリース予定です)。Amazon Auroraの紹介は、【AWS発表】Amazon Auroraをご利用頂けるようになりました!や【AWS発表】Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!!をご覧ください。

最近Auroraへ追加された機能は以下のとおりです

  • クロスリージョンスナップショットコピー
  • 暗号化されたデータベースのクロスリージョンレプリケーション
  • 暗号化されたスナップショットのアカウント間の共有
  • US West (Northern California)リージョンのサポート
  • T2.smallインスタンスサポート

 

クロスリージョンスナップショットコピー

Amazon Auroraのスナップショット(自動・手動取得に関わらず)リージョン間でコピー出来るようになりました。スナップショットを選択し、Snapshot ActionsからCopy Snapshotを選択します。その後、リージョンを選択後、新しいスナップショットの名前を入力します。

au_copy_snap

この操作の中で、暗号化済みスナップショットも選択可能です。詳細はドキュメントをご覧ください。

 

暗号化されたデータベースのクロスリージョンレプリケーション

Amazon Aurora DBを作成する際に暗号化オプションを設定出可能です。

au_enable_encr

数クリックで他のリージョンにリードレプリカを作成することが出来るようになりました。この機能を利用することで、マルチリージョン、ハイアベイラビリティなシステムが構築可能になりますし、ユーザに近い位置にデータを移動することも可能です。クロスリージョンリードレプリカを作成するには、既存のDBインスタンスを選択し、メニューからCreate Cross Region Read Replicaを選択するだけです。

au_ccrrr_menu

その後、Network & Securityからリージョンを選択し、Createをクリックします。

au_pick_dest_reg

レプリケーション先のリージョンには必ず2つ以上のアベイラビリティゾーンを含んだDB Subnet Groupが必要です。

このパワフルな新機能について詳細は、ドキュメントをご覧ください。

 

暗号化されたスナップショットのアカウント間の共有

Amazon Aurora DBインスタンスを作成する際に、定期的に自動でスナップショットを行う設定が可能です。この他にも、数クリックで任意のタイミングでスナップショットを作成することも可能です。

au_take_snapshot

DBインスタンスが暗号化されている場合はスナップショットも暗号化されます。

AWS間で暗号化されたスナップショットを共有出来るようになりました。この機能を使うためには、DBインスタンスはdefault RDS keyではないマスターキーで暗号化されている必要があります。まず、スナップショットを選択し、Snapshot ActionsメニューからShare Snapshotを選択します。

au_share_snap_menu

そして、共有先のAWS Account IDを入力し(それぞれのアカウント毎にAddをクリックします)、Saveを選択します。

au_share_snap

この他にも、スナップショットの暗号化で使用したキーも共有する必要があります。この機能の詳細はドキュメントをご覧ください。

 

US West (Northern California)リージョンのサポート

Amazon Aurora DBをUS West (Northern California) リージョンでご利用頂けるようになりました。Auroraをご利用頂けるリージョンのリストは以下の通りです。

  • US East (Northern Virginia)
  • US East (Ohio)
  • US West (Oregon)
  • US West (Northern California)
  • Canada (Central)
  • EU (Ireland)
  • EU (London)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Sydney)
  • Asia Pacific (Seoul)
  • Asia Pacific (Mumbai)

それぞれのリージョンでの価格については、こちらをご覧ください。

 

T2.smallインスタンスサポート

t2.small DBインスタンスをご利用頂けるようになりました。

au_launch

これらの経済的なインスタンスは、開発環境とテスト環境、および負荷の少ないプロダクションワークロードに最適です。また、Amazon Auroraの経験を積むこともできます。これらのインスタンス(昨年11月にリリースしたt2.mediumを含む6つのインスタンスと同様)は、Auroraが利用できるすべてのAWSリージョンで利用可能です。

t2.small DBインスタンスのオンデマンド価格はUS East (Northern Virginia)リージョンでは、1時間あたり$0.041からご利用いただけ、3年のAll Upfrontリザーブドインスタンスをご利用頂くと、1時間あたり$0.018となります。さらに詳細な価格についてはAmazon Auroraの料金ページをご覧ください。

Jeff; (翻訳は星野が担当しました。原文はこちら)

Amazon Athena のパフォーマンスチューニング Tips トップ 10

by AWS Japan Staff | on | in Amazon Athena |

Amazon Athena は、S3 に保存されたデータに対して標準 SQL で簡単に分析を行える、インタラクティブクエリサービスです。Athena はサーバーレスのためインフラ管理の必要がなく、また実行したクエリのぶんだけ料金を支払うかたちになります。Athena は簡単に使えます。Amazon S3 上のデータに対してスキーマを定義し、標準 SQL でクエリを投げるだけです。

このブログポストでは、クエリパフォーマンスを改善するための 10 個の Tips をご紹介します。Tips には、Amazon S3 に置かれたデータに関するものと、クエリチューニングに関するものがあります。Amazon Athena は Presto を実行エンジンとして使用しているため、ここでご紹介する Tips のうちのいくつかは、Amazon EMR 上で Presto を動かす際にも当てはまります。

このポストは、読者の方が Parquet, ORC, Text files, Avro, CSV, TSV, and JSON といった、さまざまなファイルフォーマットについての知識を持っていることを前提としています。

ベストプラクティス: ストレージ

このセクションでは Athena を最大限に活用するために、どのようなデータ構造にするべきかについて議論します。ここで議論する内容は、Amazon EMR 上の Spark, Presto, Hive で Amazon S3 のデータを処理する場合にも、同様に当てはまります。

1. データをパーティションに分ける

パーティショニングとは、テーブルをいくつかに分割し、日付や国、地域といったカラムの値単位でまとめることをさします。パーティションは仮想カラムとして動作します。パーティションをテーブルの作成時に定義することで、クエリでスキャンするデータ量を減らすことができ、その結果パフォーマンスが向上します。パーティションに基づいてフィルタを指定することで、クエリで読み込むデータ量を制限することができます。より詳細については、Partitioning Data を参照してください。

Athena では Hive のパーティショニングをサポートしており、以下のいずれかの記法を使用します。

  1. カラム名のあとに = 記号をつけ、そのあとに値を記述する
    s3://yourBucket/pathToTable/<PARTITION_COLUMN_NAME>=<VALUE>/<PARTITION_COLUMN_NAME>=<VALUE>/

    データセットがこの形でパーティションわけされている場合には、テーブルにパーティションを一括で認識させるために、MSCK REPAIR TABLE を実行します

  2. もしデータの “Path” が上記のフォーマットでない場合には、個々のパーティションに対して、ALTER TABLE ADD PARTITION コマンドを実行することで、パーティションを認識させることができます
    s3://yourBucket/pathToTable/YYYY/MM/DD/
    Alter Table <tablename> add Partition (PARTITION_COLUMN_NAME = <VALUE>, PARTITION_COLUMN2_NAME = <VALUE>) LOCATION ‘s3://yourBucket/pathToTable/YYYY/MM/DD/’;

    注意: このやり方を用いることで、S3 上のどの場所にあるオブジェクトに対してでも、パーティションを認識させることができます

以下の例は、S3 バケットに置かれたフライトテーブルが、year でパーティションわけされているものになります。

$ aws s3 ls s3://athena-examples/flight/parquet/
PRE year=1987/
PRE year=1988/
PRE year=1989/
PRE year=1990/
PRE year=1991/
PRE year=1992/
PRE year=1993/

year カラムに対して ‘WHERE’ 句を用いることで、読み込むデータ量を制限できます。

SELECT dest, origin FROM flights WHERE year = 1991

パーティションキーには、複数のカラムを指定することができます。同様に、そのカラムが特定の値のものだけをスキャンすることができます。

s3://athena-examples/flight/parquet/year=1991/month=1/day=1/
s3://athena-examples/flight/parquet/year=1991/month=1/day=2/

パーティション対象のカラムを決める際には、以下の点を考慮してください:

  • フィルタとして使われるカラムは、パーティションの有力候補になります
  • パーティショニング自体にコストがかかります。テーブル内のパーティション数が増えるにつれ、パーティションのメタデータを取得して処理するためのオーバーヘッドが大きくなり、かつ 1 パーティションあたりのデータサイズは小さくなります。過剰に細かくパーティショニングすると、パフォーマンス上の利点が失われます
  • データが特定パーティションに偏っており、かつ多くのクエリがその値を使う場合には、同様にパフォーマンス上の利点が失われます

例:

以下のテーブルでは、パーティション分けされたテーブルと、そうでないテーブルのクエリ実行時間を比較しています。両テーブルには、無圧縮のテキストフォーマットデータが 74GB 含まれています。パーティション分けされたテーブルは、l_shipdate カラムによって 2526 個のパーティションに分けられています。

クエリ パーティション分けされていないテーブル コスト パーティション分けされたテーブル コスト 削減度合い
実行時間 スキャンされたデータ量 実行時間 スキャンされたデータ量
SELECT count(*) FROM lineitem WHERE l_shipdate = '1996-09-01' 9.71 秒 74.1 GB $0.36 2.16 秒 29.06 MB $0.0001

99% 価格削減

77% 速度向上

SELECT count(*) FROM lineitem WHERE l_shipdate >= '1996-09-01' AND l_shipdate < '1996-10-01' 10.41 秒 74.1 GB $0.36 2.73 秒 871.39 MB $0.004 98% 価格削減
73% 速度向上

ただし以下に示すように、パーティショニングにはペナルティもあります。過剰にパーティション分けしないように気をつけてください。

クエリ パーティション分けされていないテーブル コスト パーティション分けされたテーブル コスト 削減度合い
実行時間 スキャンされたデータ量 実行時間 スキャンされたデータ量
SELECT count(*) FROM lineitem; 8.4 秒 74.1 GB $0.36 10.65 秒 74.1 GB $0.36 27% 速度低下

2. ファイルを圧縮・分割する

各ファイルが適切なサイズ(詳しくは次のセクションを参照)であるか、ファイルが分割可能であれば、データの圧縮によってクエリの実行速度は著しく向上します。データサイズが小さいほど、S3 から Athena へのネットワークトラフィックが軽減されます。

分割可能なファイルの場合には並列実行性を増すために、Athena の実行エンジンがファイルを分割して、複数のリーダーで処理します。単一の分割不可能なファイルを扱う場合には、単一リーダーのみがファイルを読み込むことができ、そのほかのリーダーは待機状態のままです。すべての圧縮アルゴリズムが分割可能なわけではありません。一般的な圧縮フォーマットとその属性について、以下のテーブルにまとめました。

アルゴリズム 分割可能か否か 圧縮の度合い 圧縮 + 解凍速度
Gzip (DEFLATE) いいえ 高い 普通
bzip2 はい 非常に高い 遅い
LZO いいえ 低い 速い
Snappy いいえ 低い とても速い

一般的に、アルゴリズムの圧縮率が高くなるほど、圧縮および解凍に必要な CPU リソースが増えます。

Athena の場合は、デフォルトでデータ圧縮が行われ、かつ分割可能な Apache Parquet や Apache ORC といったファイルフォーマットの利用をおすすめします(訳注: ここでは、ファイルフォーマットと圧縮フォーマットが混ざっている点に注意してください。Parquet や ORC はファイルフォーマットであり、圧縮フォーマットではありません。ですが、Parquet や ORC はデフォルトのエンコーディング法の中に、辞書エンコーディングという簡単な圧縮処理が含まれています。ここの記述は、そのことを表しています。また Tips の 4 番目で述べているように、Parquet/ORC に対して、さらに Snappy のような圧縮アルゴリズムを指定することが可能です)。もしそれらを利用できない場合には、適切なサイズに分割した BZip2 や Gzip を試してください。

3. ファイルサイズを最適化する

データ読み込みが並列で行われ、データブロックがシーケンシャルに読み込まれる場合に、クエリが効率的に実行されます。分割可能なファイルフォーマットであるようにしておくことで、ファイルの大きさに関わらず並列処理が行われます。

ただしファイルサイズが非常に小さい場合、特に 128MB 未満の場合には、実行エンジンは S3ファイルのオープン、ディレクトリのリスト表示、オブジェクトメタデータの取得、データ転送のセットアップ、ファイルヘッダーの読み込み、圧縮ディレクトリの読み込み、といった処理に余分な時間がかかります。その一方で、ファイルが分割不可能でサイズが非常に大きいときには、単一のリーダーがファイル全体の読み込みを完了するまで、クエリ自体の処理は行われません。この場合、並列性が下がってしまいます。

細切れファイル問題に対する解決法のひとつとして、EMR の S3DistCP ユーティリティがあります。これを使うことで、小さなファイル群を大きなオブジェクトへとまとめることができます。S3DistCP は、大量のデータを最適なやり方で HDFS から S3、S3 からS3 、S3 から HDFS へと移動させる際にも利用できます。

大きなファイルにまとめるのは、複数の利点があります:

  • 高速な一覧表示
  • S3 へのリクエスト数の削減
  • 管理するメタデータの削減

:

以下では、単一の大きなファイルのテーブルと、5000 個の小さなファイルのテーブルとで、クエリ実行時間を比較しています。データはテキストフォーマットで、サイズは 7GB です。

クエリ ファイル数 実行時間
SELECT count(*) FROM lineitem 5000 files 8.4 秒
SELECT count(*) FROM lineitem 1 file 2.31 秒
実行速度 72% 向上

4. 列指向データの作成を最適化する

Apache Parquet と Apache ORC はポピュラーな列指向データフォーマットです。両者には列方向圧縮、さまざまなエンコーディング、データ型に合わせた圧縮、プレディケイトプッシュダウン(訳注: プレディケイトプッシュダウンとは、WHERE 句や GROUP BY 句などの処理を効率的に行うための手法です。例えば GROUP BY に対するプレディケイトプッシュダウンでは、各リーダーで読み込んだデータについて、全データで GROUP BY を行う前に、各ワーカー内であらかじめ GROUP BY をしておき、その結果を集約ワーカーに転送する、といったプロセスをとります。各ワーカーで先に集約を行うことでデータの転送コストが下がり、結果的にパフォーマンスが向上します。このように、クエリの実行パイプラインの最後で行う処理を、効率化のためにあらかじめ各プロセスでおこなっておく(= プッシュダウン)のが、プレディケイトプッシュダウンの役割となります)といった、データを効率的に持つための機能があります。両者はともに分割可能です。一般的に、高い圧縮率やデータブロックのスキップによって、S3 から読み込むデータが減り、その結果よりよいクエリパフォーマンスが得られます。

チューニング可能なパラメーターのひとつとして、ブロックサイズまたはストライプのサイズがあります。Parquet におけるブロックサイズ、 ORC におけるストライプサイズというのは、バイトサイズ単位で表されるもので、単一ブロックで保持できる最大行数を意味します。ブロックまたはストライプのサイズが大きいほど、単一ブロックで格納できる行数も多くなります。デフォルトでは Parquet のブロックサイズは 128MB で、ORC のストライプサイズは 64MB になります。テーブル内に大量のカラムがある場合は、各カラムのブロック単位で効率的にシーケンシャル I/O を行えるように、より大きなブロックサイズにすることをおすすめします。

そのほかのパラメーターとして、データブロックの圧縮アルゴリズムが挙げられます。Parquet のデフォルト圧縮フォーマットは Snappy ですが、それ以外に圧縮なし、 GZIP、そして LZO も使用可能です。ORC のデフォルトは ZLIB ですが、それ以外に圧縮なしと Snappy が利用可能です。デフォルトの圧縮アルゴリズムからはじめて、10GB 以上のデータサイズになった場合には、それ以外の圧縮アルゴリズムを試してみることをおすすめします。

Parquet/ORC ファイルフォーマットは、ともにプレディケイトプッシュダウン(プレディケイトフィルタリングとも呼ばれます)をサポートしています。Parquet/ORC はともに、ブロック内にカラムの値を保持するだけでなく、最大値/最小値のようなブロックごとの統計データも持っています。クエリが実行される際に、統計情報によって当該ブロックを読み込む必要があるか、スキップしてよいかを判断します。スキップするブロック数を最適化するための一つの方法として、Parquet や ORC で書き出す前に、よくフィルタされるカラムでデータをソートしておくやり方があります。これによって、各ブロックにおける最小値と最大値の差分が、全体としてもっとも小さくなることが保証されます。これによって、フィルタ効率を向上させることができます。

Amazon EMR 上で Spark や Hive を実行することで、既存のデータを Parquet や ORC に変換できます。 詳細については、S3のデータをAmazon Athenaを使って分析する のブログポストを参照してください。また以下のリソースもあります:

ベストプラクティス: クエリ

Athena ではクエリの実行エンジンとして Presto を使用しています。クエリ実行時に Presto がどのように動いているか理解することで、クエリの最適化方法について把握することができます。

5. ORDER BY を最適化する

ORDER BY 句はクエリの実行結果をソートして返します。ソートを実行するために、Presto はデータのすべてのレコードを単一のワーカーに送り、それからソートを実行します。この処理は Presto のメモリを大量に消費するため、クエリの実行時間が非常に長くなります。最悪の場合には、クエリが失敗します。

トップ N の値をみるために ORDER BY 句を使用する場合には、単一ワーカーでソートを実行するのではなく、LIMIT 句によって各ワーカーにソートとリミットの処理をプッシュし、ソートにかかるコストを大きく削減してください。

:

データセット: 7.25GB、無圧縮、テキストフォーマット、6000万行

クエリ 実行時間
SELECT * FROM lineitem ORDER BY l_shipdate 528 秒
SELECT * FROM lineitem ORDER BY l_shipdate LIMIT 10000 11.15 秒
速度 98% 向上

6. JOIN を最適化する

2 つのテーブルを結合する際には、両者のうち大きなほうを左側に、小さなほうを右側に指定してください。Presto は JOIN 句の右側で指定されたテーブルを各ワーカーノードに転送して、左側のテーブルを順になめていくことで結合を行います。右側のテーブルを小さくすることで、メモリ消費量を少なく、クエリを高速に実行することができます。

:

データセット: 74GB、無圧縮、テキストフォーマット、6億200万行

クエリ 実行時間
SELECT count(*) FROM lineitem, part WHERE lineitem.l_partkey = part.p_partkey 22.81 秒
SELECT count(*) FROM part, lineitem WHERE lineitem.l_partkey = part.p_partkey 10.71 秒
価格削減 / 速度向上 53% 速度向上

例外として、複数のテーブルをまとめて結合する場合と、クロス結合が行われる場合があります。Presto は結合の実行順序の最適化をサポートしていないため、が左側から右側に対して結合処理が行われます。そのためテーブルを左側から大きい順に並べることにより、結合条件に合わせたテーブルの並びにならない場合、クロス結合が実行されてしまいます(訳注: 以下の例の上側のクエリの場合、まず lineitem と customer とで結合処理が行われます。しかし結合条件にあるのは lineitem と orders、ccustomer と orders のため、lineitem と customer の間ではクロス結合が行われてしまいます。その結果得られた巨大なテーブルと orders の間で,次の結合処理が行われます。クロス結合は非常にコストの高い処理のため、この場合は 30 分以内にクエリが完了せず、タイムアウトしてしまっています)。

:

データセット: 9.1GB、無圧縮、テキストフォーマット、7600万行

クエリ 実行時間
SELECT count(*) FROM lineitem, customer, orders WHERE lineitem.l_orderkey = orders.o_orderkey AND customer.c_custkey = orders.o_custkey Timed Out
SELECT count(*) FROM lineitem, orders, customer WHERE lineitem.l_orderkey = orders.o_orderkey AND customer.c_custkey = orders.o_custkey 3.71 seconds

7. GROUP BY を最適化する

GROUP BY 演算子は、指定されたカラムの値に応じてレコードを各ワーカーノードに分散し、各ノードはメモリ内に対象の値を保持します。レコードが追加されると、メモリ内の GROUP BY 対象のカラムを比較します。一致した場合には、対象となる値を集約します。

クエリ内で GROUP BY を使う際には、カーディナリティ(訳注: カラム内のユニークな値の個数)が高い順にカラムを並べてください(これはユニークな値の数が多いほど、データが各ワーカーに均等に分散するためです)。

SELECT state, gender, count(*) 
           FROM census 
GROUP BY state, gender;

もうひとつの最適化方法は、可能ならば GROUP BY の対象を文字列でなく数字にすることです。数字は文字列に比べて必要とするメモリが少ないため、高速に処理することができます。

またその他の方法として、SELECT の中で扱うカラム数を制限することによって、レコードをメモリに確保したり、GROUP BY で集約する際に必要とするメモリ総量を減らすやり方があります。

8. LIKE 演算子を最適化する

文字列のカラムに対して、複数の値でフィルタリングする際には、一般的に LIKE よりも RegEx を使う方が望ましいです。LIKE を使う回数が多いほど、また文字列カラムのサイズが大きいほど、RegEx の効果も大きくなります。

:

データセット: 74GB、無圧縮、テキストフォーマット、6億行

クエリ 実行時間
SELECT count(*) FROM lineitem WHERE l_comment LIKE '%wake%' OR l_comment LIKE '%regular%' OR l_comment LIKE '%express%' OR l_comment LIKE '%sleep%' OR l_comment LIKE '%hello% 20.56 秒
SELECT count(*) FROM lineitem WHERE regexp_like(l_comment, 'wake|regular|express|sleep|hello') 15.87 秒
速度向上 17% 向上

9. 近似関数を使う

大規模なデータセットを処理する際の典型的なユースケースとして、COUNT(DISTINCT column) を使って、特定のカラムのユニークな値ごとのレコード数を求めるというものがあります。例として挙げられるのは、ウェブサイトを訪れたユニークユーザーを求めるというものです。

もし正確な値が必要ない場合、例えばサイト内のどのウェブページを突っ込んで調べるべきか判断するといったケースでは、approx_distinct() の使用を検討してみてください。この関数は、全文字列を捜査するかわりに、ユニークなハッシュの数をカウントすることで、メモリ使用量を最小限におさえます。この手法の欠点は、得られた値に 2.3% の標準誤差を持つことです。

:

データセット: 74GB、無圧縮、テキストフォーマット、6億行

クエリ 実行時間
SELECT count(distinct l_comment) FROM lineitem; 13.21 秒
SELECT approx_distinct(l_comment) FROM lineitem; 10.95 秒
速度向上 17% 向上

詳しくは Presto ドキュメントの Aggregate Functions を参照してください。

10. 必要なカラムだけを読み込む

クエリを実行する際に、すべてのカラムを使用するかわりに、最後の SELECT 句で必要なカラムだけに絞ってください。処理対象のカラム数を減らすことで、クエリの実行パイプライン全体で処理しなければいけないデータ総量を削減できます。これは特に、大量のカラムがあるテーブルや、文字列ベースのカラムが主体のテーブルにクエリを投げるときに有効です。

:

データセット: 7.25GB、無圧縮、テキストフォーマット、6000万行

クエリ 実行時間
SELECT * FROM lineitem, orders, customer WHERE lineitem.l_orderkey = orders.o_orderkey AND customer.c_custkey = orders.o_custkey; 983 秒
SELECT customer.c_name, lineitem.l_quantity, orders.o_totalprice FROM lineitem, orders, customer WHERE lineitem.l_orderkey = orders.o_orderkey AND customer.c_custkey = orders.o_custkey; 6.78 秒
価格削減 / 速度向上 145 倍速度向上

結論

このポストでは、Amazon Athena および Presto エンジンにおけるインタラクティブ分析を最適化するための、ベストプラクティスについて述べました。これらは Amazon EMR 上で Presto を動かす際にも、同様に適用可能です。

原文: Top 10 Performance Tuning Tips for Amazon Athena (翻訳: SA志村)

4 月の AWS Black Belt オンラインセミナーのご案内

by AWS Japan Staff | on | in General |

こんにちは。ソリューションアーキテクトの焼尾です。AWS Black Belt オンラインセミナー4月の配信についてご案内させて頂きます。4,5月は組織変更などがあった方も多く、基本に立ち返り、AWSの基礎となるサービスを中心に開催します。また、AWS re:Invent 2016 にて発表された新モバイルサービスの一つ、Amazon Pinpoint も開催します。

speakers
4月の開催予定

サービスカット
4/5(水) 18:00-19:00 Amazon EC2
4/12(水) 18:00-19:00 Amazon VPC
4/19(水) 18:00-19:00 Amazon S3
4/26(水) 18:00-19:00 Amazon Pinpoint

ソリューションカット
4/11(火) 12:00-13:00 初心者向け クラウドコンピューティング はじめの一歩
4/18(火) 12:00-13:00 サーバレスによるアーキテクチャパターンのご紹介

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。

Amazon AppStream 2.0 の新機能 – Fleet Auto Scaling、Image Builder、SAML、メトリクス、フリート管理

by AWS Japan Staff | on | in Amazon AppStream |

昨年終わりに私の同僚 Gene Farrell が紹介したのは Amazon AppStream 2.0 です。そのゲスト投稿で、彼は AppStream 2.0 を使用することにより HTML5 ウェブブラウザを快適に使いながら、どのデバイスでも安全にデスクトップアプリケーションを実行できる方法について説明しました (詳しくはこちらのブログをご覧ください)。たとえば、起動時に AppStream 2.0 Try it Now ページを使用したところ、すぐに Siemens Solid Edge を使い始めることができました。Try it Now ページで好きなアプリケーションを選んだだけです。

数秒後には Solid Edge を実行していました。インストールや設定の必要もありません。

 

皆様からのリクエスト – Enterprises、SMB、ISV の新機能を追加
re:Invent でリリースしてから、皆様からのリクエストにお応えするため AppStream 2.0 の微調整を行い、いくつかの機能を追加しました。こうした新機能は、今まで以上に簡単にアプリケーションをデプロイ、アクセス、管理、トラックできるようにし、AppStream で利用できます。すでに大方の新機能をリリースしていますが、各機能に関するブログは公開していなかったので、今回はこうした新機能について簡単にご説明します。では最新機能をご紹介します。Fleet Auto Scaling – この新機能は CloudWatch メトリクスを使用してデマンドの変化に対応すべく、フリートのスケールアップやスケールダウンを可能にします。これにより瞬時のアクセスを実現しながら、できる限り安価にアプリケーションを提供することができます。Image Builder – 自分が選んだアプリケーションを含む AppStream 2.0 イメージを構築できます。SAML 2.0 認証 – AppStream 2.0 と既存の SAML 2.0 に準拠したディレクトリを使用できます。ユーザーは既存の認証情報でログインすることができます。フリート管理 – アプリケーションを実行するインスタンスの管理オプションを追加しました。CloudWatch メトリクス – サイズやフリート全体の使用率を含む 7つの Amazon CloudWatch メトリクスを観察しモニタリングすることができます。では詳しく見てみましょう。

Fleet Auto Scaling
この新機能は新しい CloudWatch メトリクスにサポートされています。各フリートにスケーリングポリシーを関連付けることができるようになりました。様々なタイプのユーザーからの要求に応えたりコスト管理に利用できます。ユーザーに生産性アプリケーションを提供するために AppStream 2.0 を使用している場合は、営業時間中にキャパシティーがオンラインになっていることを確実にしたり、ユーザーの就業時間終了後はそれに合わせられるようにスケーリングポリシーを使用できます。スケールアウト (キャパシティー追加) そしてスケールイン (キャパシティー削除) ポリシーを持つフリートについては、次をご覧ください。

この機能を活用するにはフリート作成時にキャパシティーの最小値と最大値を設定しておきます。

これによりデフォルトポリシーを作成することができます。後日にポリシーを編集、追加、削除することができます (各フリートにつき 50 件までのポリシーを作成できます)。詳細は AppStream Fleet Auto Scaling をご覧ください。

Image Builder
この機能ではお好きな商用アプリケーションやプロプライエタリアプリケーションを含むカスタムイメージを作成することができます。これを行うには image builder というインスタンスを起動します。次にインスタンスにログインし、お好きなアプリケーションをインストールして設定、インスタンスの状態をイメージとしてキャプチャします。ログインやカスタマイズのプロセスはすべてお使いのウェブブラウザ内で行われます。キーのダウンロードやパスワードを覚える必要はありません。アプリケーションはイメージレジストリで表示され、ユーザーが利用できます。AppStream 2.0 コンソールから image builder を起動できます。

次に開始点 (既存のイメージ) を選びます。

名前を指定し、インスタンスのサイズを選び VPC をセットアップすることでビルダーを設定します。

[Review] をクリックして設定を確認し、ビルダーが起動するのを待ちます。

image builder に接続できるようになったら、アプリをセットアップしイメージを作成します。接続時には管理者とテストという 2 つの選択肢があります。

[ImageBuildAdmin] を選び (パスワード入力がリクエストされたら) [Log me in] を Admin Commands で見つけてクリックします。

ログイン後、Image Assistant アプリを起動しアプリのインストールやテストに使用します。

詳細については Image BuildersAppStream 2.0 Image Builder のチュートリアルをご覧ください。

SAML 2.0 認証
この機能は SAML 2.0 をサポートするあらゆる外部 ID プロバイダーの使用を許可します。これは Active Directory フェデレーションサービスPingFederate サーバーOktaShibboleth を含みます。

Setting Up SAML の手順を完了すると、ユーザーは既存の ID や認証情報を使用して AppStream 2.0 にログインすることができます。ユーザーやグループを管理したり、ユーザーの ID または場所をベースにアプリケーションへのアクセスを管理することができ、Multi-Factor Authentication (MFA) を使用できます。詳細については SAML 2.0 を使用して AppStream 2.0 でシングルサインオンアクセスを有効にするをご覧ください。すでに AWS マネジメントコンソールにフェデレーションアクセスをセットアップしている場合は、すでにご存知の情報を大方適用できます。

フリート管理
この機能はフリート (ユーザーのアプリケーションを実行しているインスタンスのグループ) をさらにコントロールできるようにします。1 つの画面で自分のフリートをすべて見ることができます。

フリートを 1 つ選び、それに対応することができます。

フリートのプロパティにはいつでも編集できるものもあります。VPC プロパティを含むその他においては、フリートが停止した場合のみ編集することができます。詳細についてはスタックとフリートをご覧ください。

CloudWatch メトリクス
AppStream は 8 つのメトリクスを各フリートの CloudWatch に発行します。

  • RunningCapacity – 実行中のインスタンス数
  • InUseCapacity – 使用中のインスタンス数
  • DesiredCapacity – 実行中または保留中のインスタンス数
  • AvailableCapacity – 使用可能なアイドル中のインスタンス数
  • PendingCapacity – プロビジョニング中のインスタンス数
  • CapacityUtilization – 使用中のフリートの割合 (%)
  • InsufficientCapacityError – キャパシティー不足により拒否されたセッション数

AppStream 2.0 コンソールでこうしたメトリクスを見ることができます。

こうしたメトリクスはフリートのサイズを微調整する場合に全体の使用状況を把握する上で便利です。どの CloudWatch メトリクスでも同じ様に、アラートを生成しメトリクスが希望範囲外にある場合に警告を発することができます。AWS Lambda 関数を使用して環境を変更したり、専用の通知を生成することもできます。詳細については Amazon AppStream 2.0 リソースのモニタリングをご覧ください。

今すぐ利用可能
これらのすべての機能は今すぐご利用いただけます。

Jeff;

 

サーバレス JavaScript アプリケーションで SAML: Part I

by AWS Japan Staff | on | in Amazon Cognito, AWS IAM, General, Serverless, セキュリティ |

このブログ記事は AWS の Richard Threlkeld, Gene Ting, Stefano Buliani によって AWS Compute Blog に投稿された「SAML for Your Serverless JavaScript Application: Part I」の翻訳記事です。

このブログ記事に掲載したコードや SAM テンプレートの全体は samljs-serverless-sample GitHub レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。


SAML 認証連携を実現したくありませんか? AWS プラットフォームで使うことができる一時的なセキュリティ認証情報の発行を、短期間の SAML アサーションを交換で実現できます。

エンタープライズ Web アプリケーションを構築する時は、認証や認可が一貫して行われ業界のベストプラクティスに沿っている事が必須事項です。AWS では、ユーザに一意のIDを作成し、AWS のサービスにアクセスできる短期間の認証情報を使えるようにできる Amazon Cognito と呼ぶサービスを構築しました。これらの認証情報は、IAM ポリシーに基づくロールと関連付けて、異なるリソースへのアクセスを許可や拒否する事ができます。

この記事では、Amazon Cognito で SAML プロバイダと認証連携を行う異なる方式を紹介していきます。応用すると、異なるタイプの認証プロバイダ (IdP) と連携させることができます。Facebook、Twitterやその他のサードパーティのソーシャルメディアを IdP にする事もできます。Amazon Cognito のユーザプールと認証連携させ、独自のマネージドユーザディレクトリを作成することもできます。

例えば、ユーザが Active Directory Federation Services (ADFS) で認証する事ができる JavaScript アプリケーションを構築したいかもしれません。ユーザは AWS 認証情報で許可された範囲で API を呼び出して得た情報をアプリケーションに表示させたり、DynamoDB テーブルに書き込むことができます。AWS Mobileブログの記事「Announcing SAML Support for Amazon Cognito」では、新しい SAML 機能について Java、Android、iOS のサンプルコード付きで紹介しました。この記事では、ADFS フローのカスタマイズについて JavaScript のサンプルを交えて詳細に紹介します。

シナリオ

この記事では、クライアント側のフローを紹介します。SAML アサーションは Amazon API Gateway 経由で渡され、ブラウザ上のコードは Amazon Cognito Identity から直接認証情報を受け取ります。次回のブログ記事では、バックエンド側の処理を紹介します。SAML アサーションと認証情報は、AWS Lambda ファンクション内で処理でき、ビジネスロジックを実現するようカスタマイズしたり監査履歴を取ったりする事ができます。

このシナリオの全コードは SAM テンプレート含め、GitHub の samljs-serverless-sample レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。

サーバレスのアーキテクチャとなっていますが、ADFS との連携は従来のコンピュート サービスである EC2 インスタンスのようなコンポーネントで置き換えることもできます。ADFS の用語や定義については「Claims-based identity term definitions」を参考にして下さい。

前提条件

このブログ記事では、ADFS が動作している環境が必要です。以下の事を実施して下さい。:

  1. AWS コンソールで ADFS との認証連携を設定。「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」を AWS CloudFormation テンプレートと共に参考にしてください。
  2. サインインページ(https://localhost/adfs/IdpInitiatedSignOn.aspx)からユーザ example\bob が ADFS-Dev と ADFS-Production の両方のグループとして認証出来ることを確認します。
  3. Amazon Cognito Identity のプールを作成します。

ADFS 設定の概要

チュートリアルを始める前に、幾つか AWS と SAML の設定を確認しましょう。まず、前提条件にある通り IAM ロールが作成されているかから確認して下さい。アプリケーション用に新しく IAM ロールと AD グループを作成してもかまいません。この記事では、「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」の記事の通り ADFS-Dev と ADFS-Production を利用します。

  1. IAM コンソールで、ロールを選択し ADFS-Ddev を選択し、信頼関係 (Trust Relationships) のタブを開き、以下のコードのようになっている事を確認します。:
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::YOURACCOUNTNUMBER:saml-provider/ADFS"
          },
          "Action": "sts:AssumeRoleWithSAML",
          "Condition": {
            "StringEquals": {
              "SAML:aud": "https://signin.aws.amazon.com/saml"
            }
          }
        }
      ]
    }

このポリシーは “ADFS” という SAML IdP で認証されたユーザがロールを引き受ける事を許可しています。また、ポリシーには条件が含まれており、SAML アサーション内の AudienceRestriction が https://signin.aws.amazon.com/ である事となっています。SAML アサーションは ADFS から AWS に HTTP POST で SAMLResponse というヘッダとして送られて来ます。前提条件に記載されている設定が実施済みであれば、ADFS コンソールでは以下のように設定されており、利用者(Ralying Party)の URL として AWS メタデータ URL が指定されています。詳細については、「認証レスポンスの SAML アサーションを設定する」を確認して下さい。



認証後、ADFS は利用者のアプリケーションに自動的にリダイレクトします。

上記のスクリーンショットでは、認証後の SAMLResponse の値を見るために Chrome を利用しました。「トラブルシューティングのためにブラウザで SAML レスポンスを表示する方法」に記載されているとおり、他のブラウザでも同様のことを行えます。SAMLResponse を貼り付ければ、Audience、Roles や Destination などの値を見ることができる “SAML Decoder” がインターネット上にあります。パート 2 のブロク記事では、これをプログラムで行う方法を紹介します。

ADFS からサーバレス Web サイトにリダイレクトし、Amazon Cognito に繋げる

この1つ目のブログのシナリオの方が難しくありません。多くの組織での要件にベストな流れとなっています。ユーザは ADFS で認証して Amazon Cognito から AWS 認証情報を受け取り、アプリの中でアクションを行えます。このサンプルアプリケーションは:

  1. ADFS で認証するログイン メカニズムを変更して取り出すことで、SAMLResponse ヘッダを取り出します。ユーザが S3 上に配置されたウェブサイトを訪問した際に、自動的にこの仕組みが行われます。
  2. ADFS-Dev ロールの信頼ポリシーを変更し、Active Directory の AWS-gDev グループのメンバであれば Amazon Cognio から一時的な認証情報を受け取れるようにします。
  3. ユーザのロールを選択するコードをアプリケーションの中に組み込みます。このブログ記事では、ADFS-Dev ロールを選択します。

参考までに、AWS Console への認証連携の場合 #3 と同様の内容は、ADFS のウェブページ IdpInitiatedSignOn.aspx からリダイレクトされた後にラジオボタンでロールをクリックして選択する事で実現されます。より詳しい内容については、セキュリティブログの「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」をご覧下さい。もしユーザが 1 つの Active Directory グループのメンバだけであれば、SAMLResponse には複数のロールが含まれておらず、その場合は #3 は省略されます。構成は以下の図のとおりとなります。

チュートリアル: ADDFS からサーバーレス Web サイトにリダイレクトし、Amazon Cognito に繋げる

まず、サーバレス Web サイトをセットアップし、認証情報を取得するログインフローを開始させます。シングル Web アプリを配置するのには S3 を使用します。

S3 バケットの作成

  1. S3 のコンソールで、「バケットを作成」を選択して一意なバケット名を入力します。以下の例では “serverlessweb” としますが、皆様は何か他の名前として下さい。
  2. バケットを作成後、詳細設定のページで「プロパティ」を選び、「バケットポリシーの編集」をクリックします。
  3. 以下のポリシーを設定して下さい。YOURBUCKETNAMEGOESHERE は置き換えて下さい。このポリシーは、バケットに入っている HTML や JavaScript などのファイルを誰でも GET リクエストを行えるようにします。Web サイトにアクセスすると Web ブラウザは GET リクエストを発行し、このポリシーがリソースの読み込みをユーザに許可します。
    {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Sid": "PublicReadForGetBucketObjects",
              "Effect": "Allow",
              "Principal": "*",
              "Action": "s3:GetObject",
              "Resource": "arn:aws:s3:::YOURBUCKETNAMEGOESHERE/*"
          }
      ]
    }
  4. 「静的ウェブサイトホスティング」を選択し、「ウェブサイトのホスティングを有効にする」とします。フォームに「index.html」と「error.html」を入力します。

  5. 次に、HTML ファイルをバケットに追加して、https://YOURBUCKETNAME.s3-website-REGION.amazonaws.com をブラウザで開きページが見れるか確認します(YOURBUCKETNAME と REGION は読み替えて下さい。)。まずは以下の HTML をテンプレートとして使って下さい。
    <!DOCTYPE html>
    <html>
     <head>
      <title>
       Amazon Cognito SAML Example
      </title>
      <script src="aws-sdk.min.js">
      </script>
     </head>
     <body>
      <h1>
       Testing SAMLResponse
      </h1>
     </body>
    </html>
      
  6. JavaScript SDK から圧縮(Minify)されたバージョン aws-sdk.min.js をダウンロードして、HTML ファイルと同様にバケットに保存し、エラー無くロードできることを確認します。

(オプション) CloudFront ディストリビューションのセットアップ

次に進める前に、さらにもう1つセットアップしたいと思います。CloudFront ディストリビューションです。S3 静的 Web ホスティングに CloudFront やその他の CDN を使用することで、独自ドメイン名で SSL を使用することができるようになります。

API Gateway から HTTP サイトにリダイレクトする事もできるため強制ではありませんが、Web サイトや認証や認可のシステムはエンドツーエンドで HTTPS を使うべきです。以下がセットアップで行う内容です。

  1. CloudFront コンソールで、Web タイプのディストリビューションを作成します。
  2. 「Viewer Protocol Policy」には、「HTTPS Only」を選択します。
  3. 「Origin Domain Name」には S3 バケットを選択します。
  4. ベストプラクティス通り、「Restrict Bucket Access」を選択します。こうすることで、バケットが直接アクセスされることから守ることができます。これで CloudFront ディストリビューションのドメイン名で、サイトにアクセスできるようになると思います。

ログイン メカニズム

次に、ログイン メカニズムを構築します。

ウェブサイトではログインさせるために、ボタンを押させることも出来ますし、自動的に認証情報が有効かどうか確認してからログインのフローにリダイレクトをさせる事もできます。

この例では、2 つ目のアプローチを取ります。ユーザがページを訪れると JavaScript を使ってすぐに状態を確認し、初回の訪問であれば認証情報を入手するためにリダイレクトさせます。このページにはログインの流れの中で API Gateway から再度リダイレクトされても来るため、ログインの進捗に合わせ ADFS のログインページにリダイレクトさせるのと同様に、届いた SAMLResponse のデータをキャプチャする事も必要です。今回の例では、以下のような流れになります。:

function loginWorkflow(){
    var activelogin = sessionStorage.getItem('activelogin');
    if (activelogin=='inProgress'){                                   //ADFS login redirect from API Gateway
        var samlResponse = getParameterByName('SAMLResponse');
        sessionStorage.removeItem(‘activelogin’);
        if (samlResponse != null){
            getSamlCredentials(samlResponse.replace(/\s/g, ''));
        }
    }
    else if (activelogin === null) {                                 //First page visit. Redirect to ADFS login.
        var RPID = encodeURIComponent('urn:amazon:webservices');
        var result = 'https://localhost/adfs/ls/IdpInitiatedSignOn.aspx' + "?loginToRp=" + RPID;
        sessionStorage.setItem('activelogin', 'inProgress');
        window.location = result;
    }
    else {//Credentials exist, page refresh, etc.
        console.log('activelogin already exists in session and the value is ' + activelogin);
    }
}

上記では、ADFS IdP への呼び出しを始める時にセッション変数を設定し、SAMLResponse (getParameterByName() で取り出せる)と一緒にWeb サイトに戻って来た時には getSamlCredentials() 関数を呼び出します。

AWS が必要とする SAMLResponse 値は POST binding のみがサポートされていますが、S3 の静的ウェブサイトは、GET リクエストしか受け取ることができません。このため、JavaScript アプリケーションが ADFS からの SAMLResponse を受け取るために API Gateway を利用します。Lambda をプロキシとして利用し、SAMLResponse をクエリ文字列に入れて静的ウェブサイトにリダイレクトで戻ってこさせます。

Lambda 関数の設定

  1. Lambda のコンソールで、GitHub レポジトリにある /Scenario1/lambda/redirect/index.js を使って samlRedirect という名前の関数をランタイムは Node.js 4.3 で作成します。実行ロールにはログ保存のために CloudWatch Logs の権限だけが必要です。
  2. 基本的な実行ロールが既になければ、関数作成時に新しいロールを Lambda のコンソール上で作成する事ができます。
  3. LOG_LEVELREDIRECT_URL という名前の環境変数を作成し、LOG_LEVEL には info を REDIRECT_URL には S3 の静的ウェブサイトの URL(静的ウェブホスティングを有効にしている場合にはバケットのプロパティに表示されているエンドポイント、あるいは先程記載したオプションの CloudFront ディストリビューション設定をした場合はドメイン名)を設定します。

API Gateway 設定

  1. API Gateway のコンソールで、SAMLAuth あるいは何か似た名前を付けた API を作成します。
  2. リソース」 を選択し、「SAML」という名前の子リソースを作成します。
    lambdasamlone_7.png
  3. POST」メソッドを作成します。「統合タイプ」には「Lambda」を選択し、「samlRedirect」関数を指定します。「メソッドリクエスト」の「HTTP リクエストヘッダー」に「SAMLResponse」を設定します。
    lambdasamlone_8.png

先ほど作成した samlRedirect 関数では、クエリ文字列に SAMLResponse を付けた静的ウェブサイトの URL を location プロパティに設定します。リダイレクトが実行されるように、API Gateway が 302 ステータスコードを返すように設定します。

  1. メソッドレスポンス」でステータスコード 200 を削除し、302 を追加します。「レスポンスヘッダ」に「Location」を設定し、「レスポンス本文」には「コンテンツタイプ」に「application/json」、「モデル」に「Empty」と設定します。
    lambdasamlone_9.png
  2. 「統合レスポンス」で「メソッドレスポンス」のステータスが 200 のものを削除し、302 のものを追加します。レスポンスヘッダ「Location」の「マッピングの値」には「integration.response.body.location」を設定します。
    lambdasamlone_10.png
  3. Lambda 関数が SAMLResponse と RelayState を受け取れるように、「統合リクエスト」で「コンテンツタイプ」が 「application/x-www-form-urlencoded」の「本文マッピングテンプレート」を以下のように追加します。:

    {
    "SAMLResponse" :"$input.params('SAMLResponse')",
    "formparams" : $input.json('$')
    }
  4. 変更を保存します。
  5. /saml リソースで「アクション」から「CORS の有効化」を選択します。「CORS を有効にして既存の CORS ヘッダを置換」を行いします。

  6. アクション」から「API のデプロイ」を選択します。「ステージ」には「Prod」や似た名前を使用します。「ステージエディター」で、「SDK 生成」を選択します。「プラットフォーム」には「JavaScript」を選択し、「SDK の生成」を行い、どこかのフォルダに保存します。ADFS の設定に必要になるため、トップに表示されている「URL の呼び出し」をメモします。

ADFS リダイレクト設定

  1. ADFS のコンソールで、「利用信頼関係」にある Amazon Web Services のプロパティを開き、「利用者を自動的に更新する」の項目を無効(チェックしない)にします。
    lambdasamlone_11.png
  2. エンドポイント」のタブを開き、既にあるエンドポイントを編集します。「バインディング」は「POST」のままで、「URL」には API Gateway でデプロイした API の「URL の呼び出し」を入力します。URL の最後に 「/saml」を追加します。
    lambdasamlone_12.png
    これまで構築してきたことを復習します。:

    • Web ページはユーザが認証情報を持っていなければ、ADFS のログインページにリダイレクトします。
    • 認証に成功したら、ADFS は SAMLResponse を付けて Web ページにユーザを戻します(API Gateway 経由)。
    • SAMLResponse は元の Web ページにクエリ文字列の一部として渡されます。

    Amazon Cognito から認証情報を取得するには、JavaScript コードでこのクエリ文字列を取り出し getCredentialsForIdentity 呼び出しのパラメータの一部として渡す必要があります。

  3. Amazon Cognito の Federated Identities のコンソールで、前提条件でセットアップした認証プールを開きます。認証プールの ID を確認し、以下の JavaScript コードの先頭に利用するリージョン名と同様に記載します。
    const identityPool = 'YOURCOGNITOPOOLID';
    AWS.config.region = 'COGNITOREGION'; // Region
    
    AWS.config.credentials = new AWS.CognitoIdentityCredentials({
        IdentityPoolId: identityPool
    });
    
    var identityId = localStorage.getItem('cognitoid');
    if (identityId != null){
        console.log('Identity ID: ' + identityId);
        loginWorkflow();
    } else {
        console.log('Calling GetID');
        AWS.config.credentials.get(function(){
            console.log('Identity ID: ' + AWS.config.credentials.identityId);
            localStorage.setItem('cognitoid', AWS.config.credentials.identityId);
            identityId = localStorage.getItem('cognitoid');
            loginWorkflow();
        });
    }

このコードは、アプリケーションでユーザに Amazon Cognito で生成した一意の ID を付与する最初の部分です。その上で、クエリ文字列に SAMLResponse の値を入れて返させるために loginWorkflow() を呼び出します。

以下は Stack Overflow で紹介されているサンプルのユーティリティ関数で、クエリ文字列から特定の項目を取り出すためのものです。

function getParameterByName(name, url) {
    if (!url) {
      url = window.location.href;
    }
    name = name.replace(/[\[\]]/g, "\\$&amp;");
    var regex = new RegExp("[?&amp;]" + name + "(=([^&amp;#]*)|&amp;|#|$)"),
        results = regex.exec(url);
    if (!results) return null;
    if (!results[2]) return '';
    return decodeURIComponent(results[2].replace(/\+/g, " "));
}

これで Web ページは ADFS から BASE64 エンコードされた SAMLResponse を取得しました。これを Amazon Cognito に渡せば AWS 認証情報を取得することが出来ます。Cognito の getSamlCredentials() 関数は以下のコードで、loginWorkflow() から呼び出されます。:

function getSamlCredentials(samlResponse) {
    var role = 'arn:aws:iam::ACCOUNTNUMBER:role/ADFS-Dev';
    var params = {
        IdentityId: identityId,
        CustomRoleArn: role,
        Logins: {
            'arn:aws:iam::ACCOUNTNUMBER:saml-provider/ADFS' : samlResponse,
        }
    };

    cognitoidentity.getCredentialsForIdentity(params, function(err, data) {
        if (err) console.log(err, err.stack);
        else {
            console.log('Credentials from Cognito: ');
            console.log(data.Credentials);
        }
    });
}

ARN にある ACCOUNTNUMBER は2つとも書き換える必要がある事に注意して下さい。今回は使用するロールがソースに直書きされています。もし、SAML クレームに複数のロールが入って返されないのであれば、このパラメータは省略することもできます。引き受けるロールを何かしらのロジックで選択するようにしたい場合もあると思います。このブログ記事のパート II ではクライアント側ではなくバックエンドでこれをできるようにする内容を含める予定です。

また、logins map にあるキーは IAM コンソールで作成した ADFS の IdP 登録の ARN で、値は samlResponse です。これもアカウント番号に書き換える必要があります。この情報により Amazon Cognito は SAMLResponse の値が信頼している対象の ADFS からのものであるか検証できます。

この時点でこのコードを試しても動作しません。Amazon Cognito の認証プールで、認証プロバイダとして SAML IdP を有効にする必要があります。

  1. Amazon Cognito の Federated Identities のコンソールで、プールを選択し、Authentication Providers までスクロールし、SAML を選択します。ADFS の IdP を示すチェックボックスを選択します。
  2. Save Changes をクリックします。
    lambdasamlone_13.png

次に、Amazon Cognito が有効な SAMLResponse アサーションを受け取った時に、ユーザがロールを引き受けられるように信頼ポリシーを変更します。Amazon Cognito は STSAssumeRoleWithWebIdentity API を呼び出してこれを実現します。

IAM のコンソールで、ADFS-Dev ロールの信頼ポリシーを以下のポリシーに編集します。(JavaScript コードのように適切な位置に Amazon Cognito のプール ID を挿入します。):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "YOURCOGNITOPOOLID"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}

これで Amazon Cognito の信頼ポリシーは設定できました。Web ページをテストして下さい。AWS サービスのリクエストへの署名に使える認証情報はコンソールログに (AccessKey, SecretKey, Token) の 3 つが含まれる形で “data” オブジェクトで出力されます。アプリケーションの共通のシナリオは、AWS_IAM 認証に設定された API Gateway のメソッド呼び出しを行うことです。認証情報は SDK のリクエストを使うことで渡す事ができます。上記の呼び出して指定したロールにその API を呼び出す権限があれば、メソッド呼び出しは成功します。

例えば、API Gateway で API を作成した場合、メソッドに AWS_IAM 認証を有効にできます。上記で指定されたロール(logins mapで指定)に、メソッド呼び出しの権限があることを確認して下さい。より詳しいことは、「API Gateway へのアクセスを IAM アクセス権限で制御する」をご覧下さい。API をデプロイした場合、SDK の生成を使ってそのステージの JavaScript SDK を生成してダウンロードできます。これからのメソッド呼び出しを Web ページに組み込む事ができます。より詳しいことは、「API Gateway で生成した JavaScript SDK を使用する」をご覧下さい。トピックの最後に、apigClientFactory.newClient コンストラクタにアクセスキーシークレットキーをどうやって渡すことができるか確認しましょう。

Amazon Cognito Identity は短期間だけ有効な認証情報(1 時間で無効になる)を利用するため、一時的なアクセスキー、シークレットキー、セッショントークンを、apigClientFactory.newClient コンストラクタに渡します。:

        var apigwClient = apigClientFactory.newClient({
        accessKey: data.Credentials.AccessKeyId,
        secretKey: data.Credentials.SecretKey,
        sessionToken: data.Credentials.SessionToken
    });

機能の動作確認ができる Web ページのコードは、GitHub レポジトリ内の /scenario1/website/index.html にあります。同じディレクトリにある configs.js ファイルを更新します。リージョン、Cognito Identity のプール ID、SAML IdP の ARN、ADFS-Dev ロールの ARN を変更します。SAM テンプレートを使って API Gateway に AWS_IAM 認証の MOCK エンドポイントを作成する事もでき、連携された認証情報が機能するか Web ページ上のテストボタンで確認する事ができます。

lambdasamlone_14.png

最後に

チュートリアルを通じて SAML 認証や Amazon Cognito を使った AWS 認証について深いレベルで理解する手助けになる事を願っています。まだ完了していなければ、少し時間をかけて頂き、GitHub レポジトリの samljs-serverless-sample にあるコードを実際に動かし確認して下さい。また感想についても教えてください。

このシナリオは最初のステップとして十分かもしれませんが、組織によってはより多くのことをする必要があるかもしれません。例えば、ロールの選択をユーザに任せたいやビジネスロジックに基づき独自の IAM 範囲を実装したい事もあるかと思います。このシリーズのパート 2 ではこれらをどのようにしたら実現できるかを見ていきたいと思います。

[訳注] このブログで紹介している方法では、ADFS におけるデフォルトの AWS の証明書利用者設定を変更します。そのため、同じ ADFS 環境で AWS のマネージメントコンソールへ認証連携してアクセスさせる事とは同時に実現できません。

原文: SAML for Your Serverless JavaScript Application: Part I (翻訳: SA 辻 義一)

R で Amazon Athena を活用する

by AWS Japan Staff | on | in Amazon Athena |

データサイエンティストはしばしば、R から SQL クエリを投げるときに、その裏側のビッグデータ基盤のインフラ管理を気に掛けなければなりません。Amazon Athena はインフラ管理の必要がなく、標準 SQL で簡単に S3 上のデータを直接分析できる、インタラクティブクエリサービスです。R と Amazon Athena の連携によって、データサイエンティストはインタラクティブな分析ソリューションのための、強力なプラットフォームを手に入れることができます。

このブログポストでは、Amazon EC2 インスタンス上で動作する R/RStudio から Athena に接続します。

事前準備

Athena との連携を開始する前に、以下のステップを完了してください。

  1. AWS アカウントの管理者に依頼して、Athena にアクセスするのに必要な権限を、Amazon の Identity and Access Management (IAM) コンソール経由で、自身の AWS アカウントに付与してもらってください。具体的には、IAM にあるデータサイエンティストのユーザーグループに対して、関連する Athena のポリシーをアタッチしますRAthena_1
  2. Amazon S3 バケットに、ステージングディレクトリを作成してください。Athena はクエリする対象のデータセットと、クエリ結果を置く場所として、このバケットを利用します。このポストでは、ステージングバケットを s3://athenauser-athena-r とします

注意: このブログポストでは、すべての AWS リソースは us-east-1 リージョンに作成します。ほかのリージョンでも Athena が利用可能かどうか、製品およびサービス一覧で確認してください。

EC2 上での R と RStudio の起動

  1. AWS上でRを実行する” のインストラクションにしたがって、EC2 インスタンス(t2.medium かそれ以上のサイズ)で Amazon Linux を動かし、R のセットアップを行います。始める前に、以下のステップを確認しておいてください
  2. このブログポストの “高度な詳細” の記述で、ステップ 3 まできたら、最新バージョンの RStudio をインストールするため、以下の bash スクリプトを実行してください。必要であれば、RStudion のパスワードも修正してください
#!/bin/bash
#install R
yum install -y R
#install RStudio-Server
wget https://download2.rstudio.org/rstudio-server-rhel-1.0.136-x86_64.rpm
yum install -y --nogpgcheck rstudio-server-rhel-1.0.136-x86_64.rpm
#add user(s)
useradd rstudio
echo rstudio:rstudio | chpasswd

Java 8 のインストール

  1. EC2 instance に SSH でログインします
  2. 古いバージョンの Java を削除します
  3. Java 8 をインストールします。これは Athena を動かすために必要です
  4. コマンドライン上で、以下のコマンドを実行します
#install Java 8, select ‘y’ from options presented to proceed with installation
sudo yum install java-1.8.0-openjdk-devel
#remove version 7 of Java, select ‘y’ from options to proceed with removal
sudo yum remove java-1.7.0-openjdk
#configure java, choose 1 as your selection option for java 8 configuration
sudo /usr/sbin/alternatives --config java
#run command below to add Java support to R
sudo R CMD javareconf

#following libraries are required for the interactive application we build later
sudo yum install -y libpng-devel
sudo yum install -y libjpeg-turbo-devel

.Renviron のセットアップ

R の環境変数 .Renviron に対して、必要となる Athena のクレデンシャルを追加します。

  1. AWS 管理者から、必要なクレデンシャルを AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY の形式で取得します
  2. Linux のコマンドプロンプトから以下のコマンドを打ち込んで、vi エディタを立ち上げます
    sudo vim /home/rstudio/.Renviron
    
    Provide your Athena credentials in the following form into the editor:
    ATHENA_USER=< AWS_ACCESS_KEY_ID >
    ATHENA_PASSWORD=< AWS_SECRET_ACCESS_KEY>
  3. 編集結果をセーブして、エディタを終了します

RStudio にログイン

続いて、EC2 上の RStudio にログインします。

  1. EC2 のダッシュボードからインスタンスのパブリック IP アドレスを取得して、ブラウザのアドレス欄に貼り付け、後ろに :8787(RStudio のポート番号)を付けます
  2. EC2 インスタンスに関連付けられたセキュリティグループm設定で、アクセス元の IP アドレスから 8787 ポートへのアクセスが許可されていることを確認してください
  3. 先ほど設定したユーザ名とパスワードで、RStudio にログインします

R パッケージのインストール

続いて、必要な R パッケージをインストールして、ロードします。

#--following R packages are required for connecting R with Athena
install.packages("rJava")
install.packages("RJDBC")
library(rJava)
library(RJDBC)

#--following R packages are required for the interactive application we build later
#--steps below might take several minutes to complete
install.packages(c("plyr","dplyr","png","RgoogleMaps","ggmap"))
library(plyr)
library(dplyr)
library(png)
library(RgoogleMaps)
library(ggmap)

Athena への接続

以下の R のスクリプトで、Athena ドライバーのダウンロードと、コネクションの設定を行います。アクセスしたいリージョンの JDBC URL に接続してください。

#verify Athena credentials by inspecting results from command below
Sys.getenv()
#set up URL to download Athena JDBC driver
URL <- 'https://s3.amazonaws.com/athena-downloads/drivers/AthenaJDBC41-1.0.0.jar'
fil <- basename(URL)
#download the file into current working directory
if (!file.exists(fil)) download.file(URL, fil)
#verify that the file has been downloaded successfully
fil
#set up driver connection to JDBC
drv <- JDBC(driverClass="com.amazonaws.athena.jdbc.AthenaDriver", fil, identifier.quote="'")
#connect to Athena using the driver, S3 working directory and credentials for Athena 
#replace ‘athenauser’ below with prefix you have set up for your S3 bucket
con <- jdbcConnection <- dbConnect(drv, 'jdbc:awsathena://athena.us-east-1.amazonaws.com:443/',
s3_staging_dir="s3://athenauser-athena-r",
user=Sys.getenv("ATHENA_USER"),
password=Sys.getenv("ATHENA_PASSWORD"))
#in case of error or warning from step above ensure rJava and RJDBC packages have #been loaded 
#also ensure you have Java 8 running and configured for R as outlined earlier

これで RStudio から Athena に接続する準備ができました。

サンプルクエリでテスト

# get a list of all tables currently in Athena 
dbListTables(con)
# run a sample query
dfelb=dbGetQuery(con, "SELECT * FROM sampledb.elb_logs limit 10")
head(dfelb,2)

RAthena_2

インタラクティブなユースケース

次に、分析と可視化のために R から Athena に対してインタラクティブなクエリを行ってみましょう。S3 上にあるパブリックデータセットの GDELT を使います。

GDELT データセットに対して、R から Athena のテーブルを作成します。このステップは “Amazon Athena – Amazon S3上のデータに対話的にSQLクエリを” で紹介されているように、AWS のマネジメントコンソール上からも実行することができます。

#---sql  create table statement in Athena
dbSendQuery(con, 
"
CREATE EXTERNAL TABLE IF NOT EXISTS sampledb.gdeltmaster (
GLOBALEVENTID BIGINT,
SQLDATE INT,
MonthYear INT,
Year INT,
FractionDate DOUBLE,
Actor1Code STRING,
Actor1Name STRING,
Actor1CountryCode STRING,
Actor1KnownGroupCode STRING,
Actor1EthnicCode STRING,
Actor1Religion1Code STRING,
Actor1Religion2Code STRING,
Actor1Type1Code STRING,
Actor1Type2Code STRING,
Actor1Type3Code STRING,
Actor2Code STRING,
Actor2Name STRING,
Actor2CountryCode STRING,
Actor2KnownGroupCode STRING,
Actor2EthnicCode STRING,
Actor2Religion1Code STRING,
Actor2Religion2Code STRING,
Actor2Type1Code STRING,
Actor2Type2Code STRING,
Actor2Type3Code STRING,
IsRootEvent INT,
EventCode STRING,
EventBaseCode STRING,
EventRootCode STRING,
QuadClass INT,
GoldsteinScale DOUBLE,
NumMentions INT,
NumSources INT,
NumArticles INT,
AvgTone DOUBLE,
Actor1Geo_Type INT,
Actor1Geo_FullName STRING,
Actor1Geo_CountryCode STRING,
Actor1Geo_ADM1Code STRING,
Actor1Geo_Lat FLOAT,
Actor1Geo_Long FLOAT,
Actor1Geo_FeatureID INT,
Actor2Geo_Type INT,
Actor2Geo_FullName STRING,
Actor2Geo_CountryCode STRING,
Actor2Geo_ADM1Code STRING,
Actor2Geo_Lat FLOAT,
Actor2Geo_Long FLOAT,
Actor2Geo_FeatureID INT,
ActionGeo_Type INT,
ActionGeo_FullName STRING,
ActionGeo_CountryCode STRING,
ActionGeo_ADM1Code STRING,
ActionGeo_Lat FLOAT,
ActionGeo_Long FLOAT,
ActionGeo_FeatureID INT,
DATEADDED INT,
SOURCEURL STRING )
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t'
STORED AS TEXTFILE
LOCATION 's3://support.elasticmapreduce/training/datasets/gdelt'
;
"
)

dbListTables(con)

上記のステートメントを実行すると、RStudio のコンソールに ‘gdeltmaster’ というテーブルが新しく作成されたのを確認できます。

RAthena_3

2015 年に US で開かれた CAMEO イベントの回数をカウントするクエリを、Athena テーブルに投げましょう。

#--get count of all CAMEO events that took place in US in year 2015 
#--save results in R dataframe
dfg<-dbGetQuery(con,"SELECT eventcode,count(*) as count
FROM sampledb.gdeltmaster
where year = 2015 and ActionGeo_CountryCode IN ('US')
group by eventcode
order by eventcode desc"
)
str(dfg)
head(dfg,2)

RAthena_4

#--get list of top 5 most frequently occurring events in US in 2015
dfs=head(arrange(dfg,desc(count)),5)
dfs

RAthena_5-300x140

上記の R の出力結果から、CAMEO イベントは 42 回という高頻度で行われたことがわかります。CAMEO のマニュアルから、このイベントの概要が “会議やその他のイベントのための、他の地域への出張” となります。

次に、この分析から得られる知見を使い、この特定のイベントに関連したすべての地域の座標リストを、Athena テーブルから取得します。

#--get a list of latitude and longitude associated with event “042” 
#--save results in R dataframe
dfgeo<-dbGetQuery(con,"SELECT actiongeo_lat,actiongeo_long
FROM sampledb.gdeltmaster
where year = 2015 and ActionGeo_CountryCode IN ('US')
and eventcode = '042'
"
)
#--duration of above query will depend on factors like size of chosen EC2 instance
#--now rename columns in dataframe for brevity
names(dfgeo)[names(dfgeo)=="actiongeo_lat"]="lat"
names(dfgeo)[names(dfgeo)=="actiongeo_long"]="long"
names(dfgeo)
#let us inspect this R dataframe
str(dfgeo)
head(dfgeo,5)

RAthena_6

続いて、アメリカ合衆国の地図を生成します。

#--generate map for the US using the ggmap package
map=qmap('USA',zoom=3)
map

RAthena_7

これで、Athena テーブルから得られた地理データが、地図上にプロットされました。これにより、2015 年に US でひらかれたすべての当該イベントについて、開催場所を可視化することができました

#--plot our geo-coordinates on the US map
map + geom_point(data = dfgeo, aes(x = dfgeo$long, y = dfgeo$lat), color="blue", size=0.5, alpha=0.5)

RAthena_8

結果を可視化することによって、あるイベントの開催場所が US の北東部に極めて集中していることを把握できました。

結論

この記事では Athena と R を使って、簡単なインタラクティブアプリケーションを構築する方法を説明しました。Athena は標準 SQL を用いて、ビッグデータを保存し、それに対してクエリをかけるのに使うことができます。またその一方で、R の持つ強力なライブラリ群を活用することで、Athena に対してインタラクティブにクエリを投げ、分析のインサイトを得ることができます。

質問やアドバイスなどがありましたら、コメント欄にフィードバックをお願いします。

原文: Running R on Amazon Athena (翻訳: SA志村)

新機能 – Amazon EMR インスタンスフリート

by AWS Japan Staff | on | in Amazon EMR |

今日は、インスタンスフリートと呼ばれる Amazon EMR クラスターの新機能をご紹介します。インスタンスフリートは、インスタンスのプロビジョニングに広範囲な選択肢やインテリジェンスをもたらします。対応する加重容量やスポット入札価格 (スポットブロックを含む) を最大 5 つのインスタンスタイプのリストに追加できるようになりました。EMR は、クラスター作成時にこれらのインスタンスタイプの間でオンデマンドおよびスポット容量を自動的にプロビジョニングします。そのため、これまでよりも簡単かつ低コストに、希望のクラスター容量をすばやく取得して管理することができます。また、アベイラビリティーゾーンのリストを指定することもでき、EMR は、このうちのいずれかの AZ で最適にクラスターを起動します。また、EMR は、インスタンスをフリートの利用可能ないずれかのタイプに置換することで、スポットインスタンスの中断に備えてクラスターの再分散を続けます。その結果、クラスター容量全体を容易に管理できます。インスタンスフリートは、インスタンスグループの代わりに使用することもできます。グループと同様、クラスターには、マスター、コア、タスクフリートが作成されます。コンソールのアップデートを確認し、フリートの動作について詳しく調べてみましょう。EMR コンソールを開き、[クラスターの作成] ボタンをクリックします。なじみのある EMR プロビジョニングコンソールが表示されたら、左上隅付近にある詳細オプションに移動します。最新の EMR バージョン (インスタンスフリートは、5.0.x を除く 4.8.0 以上の EMR バージョンで使用可能) を選択し、[次へ] をクリックします。これで正常に表示されます。ハードウェアオプションの新しい [インスタンスフリート] を選択します。

Screenshot 2017-03-09 00.30.51ここで、コアグループを変更して、クラスターのニーズを満たす一組のインスタンスタイプを選択します。CoreFleetScreenshot

EMR は、最もコスト効率の高い方法で要件を満たせるように、各インスタンスフリートとアベイラビリティーゾーンの容量をプロビジョニングします。EMR コンソールでは、インスタンスタイプごとに vCPU を加重容量と簡単にマッピングできるため、vCPU を容量ユニットとして使用しやすくなります (コアフリートに合計 16 個の vCPU が必要)。vCPU ユニットが、インスタンスタイプの分量指定に関する条件に一致しない場合は、[Target capacity] セレクタを変更して、任意のユニットを追加し、容量を定義します (API/CLI によるキャパシティーユニットの消費量も変更されます)。クラスターがプロビジョニングされており、ユーザー定義のタイムアウト内に希望のスポット容量を入手できない場合は、オンデマンドインスタンスを終了またはフォールバックして、残りのキャパシティーをプロビジョニングできます。また、インスタンスフリートで使用されるこれらの機能はすべて、「AWS SDK」および「CLI」より入手できます。インスタンスフリートをプロビジョニングする方法を詳しく見てみましょう。まず、my-fleet-config.json に configuration json を作成します。

[
  {
    "Name": "MasterFleet",
    "InstanceFleetType": "MASTER",
    "TargetOnDemandCapacity": 1,
    "InstanceTypeConfigs": [{"InstanceType": "m3.xlarge"}]
  },
  {
    "Name": "CoreFleet",
    "InstanceFleetType": "CORE",
    "TargetSpotCapacity": 11,
    "TargetOnDemandCapacity": 11,
    "LaunchSpecifications": {
      "SpotSpecification": {
        "TimeoutDurationMinutes": 20,
        "TimeoutAction": "SWITCH_TO_ON_DEMAND"
      }
    },
    "InstanceTypeConfigs": [
      {
        "InstanceType": "r4.xlarge",
        "BidPriceAsPercentageOfOnDemandPrice": 50,
        "WeightedCapacity": 1
      },
      {
        "InstanceType": "r4.2xlarge",
        "BidPriceAsPercentageOfOnDemandPrice": 50,
        "WeightedCapacity": 2
      },
      {
        "InstanceType": "r4.4xlarge",
        "BidPriceAsPercentageOfOnDemandPrice": 50,
        "WeightedCapacity": 4
      }
    ]
  }
]

これで、設定が完了し、AWS CLI の「emr」サブコマンドを使用して、この構成で新しいクラスターを作成できるようになりました。

aws emr create-cluster --release-label emr-5.4.0 \
--applications Name=Spark,Name=Hive,Name=Zeppelin \
--service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile="EMR_EC2_DefaultRole,SubnetIds=[subnet-1143da3c,subnet-2e27c012]" \
--instance-fleets file://my-fleet-config.json

 

追加料金をかけずに、今すぐこの機能を使用する場合は、「開始に役立つドキュメントはこちら」で詳細を確認できます。本記事を寄稿するにあたりご協力いただいた EMR サービスチームの皆様にこの場を借りて御礼申し上げます。

発表: Amazon ElastiCache で Redis バックアップおよび復元を実現、クラスターのサイズ変更も可能に

by AWS Japan Staff | on | in Amazon ElastiCache |

インメモリキャッシュは、アプリケーション設計時またはソリューション構築時の大規模なパフォーマンス強化やコスト削減と同等に扱われます。ここで、サービスが 1 つのみの場合は、スケーリングする機能を強化しながら、継続的にクラウド内のインメモリキャッシュをより簡単にデプロイおよび活用できるようにします。冗談はさておき、この優れた機能を実現するクラウドサービスとは、もちろん Amazon ElastiCache です。Amazon ElastiCache は、パフォーマンスの高いインメモリデータストアまたはキャッシュをクラウドで実現する AWS マネージドサービスです。I/O 集約型または計算量の多いデータの低レイテンシー、安全性、アクセスを実現するための分散環境を作成、スケール、管理する簡単な方法を提供します。また、ElastiCache では、Amazon CloudWatch を通じて、キャッシュシステムのノードの主要なパフォーマンスメトリクスの可視性を強化すると同時に、障害が発生したノードを検出して置換することで、インメモリデータ構造サーバやキャッシュのインフラストラクチャを管理するオーバーヘッドを抑えることができます。この優れたサービスで、Redis バックアップおよび復元とクラスターのサイズ変更を実現しました。

Amazon ElastiCache に精通している方であれば、ElastiCache で次の 2 つのインメモリキー値エンジンがサポートされていることをご存じでしょう。

  • Memcached: パフォーマンスの高いオープンソースの分散メモリオブジェクトキャッシュシステム。データベースの負荷を軽減して動的なウェブアプリケーションを高速化することを当初の目的として 2003 年に開発されました。
  • Redis: オープンソースのインメモリデータ構造ストア。Redis クラスターを使用して、組み込みレプリケーション、アトミックオペレーションサポート、さまざまなレベルのオンディスクの永続性、高可用性を実現しながら、キャッシュ、メッセージング、データベースのブローカーとして開発され、2009 年に発表されました。

2016 年 10 月、Redis 3.2.4 使用の Redis クラスターがサポートされるようになり、ElastiCache Redis のユーザーは Redis クラスターを活用できるだけでなく、次のことが行えるようになりました。

  • クラスターレベルのバックアップの作成
  • バックアップ内のクラスターのシャード単位でのスナップショットの生成
  • 最大 15 シャードの間で 3.5TiB のデータのワークロードのスケール

ElastiCache や関連する機能を活用した Redis の使用については、「Amazon ElastiCache for Redis」の製品ページを参照してください。Redis バックアップおよび復元とクラスターのサイズ変更機能が発表され、ElastiCache は、マネージド型の Redis クラスター経験に確実に移行できるように Redis のサポートをますます強化しています。この機能には、ElastiCache と Redis ユーザーのどちらにとっても、次のような利点があります。

  • シャード数やスロット配置が異なる Redis クラスターにバックアップを復元可能
  • ユーザーによる Redis ワークロードのサイズ変更が可能
  • シャードされた Redis クラスターを作成する入力として、Redis データベースファイル (RDB) スナップショットを使用可能
  • シャードされた Redis クラスターの作成に必要なデータ入力として、EC2 実装 (Redis クラスターと単一シャード Redis の両方) で Redis のスナップショットを使用可能

これらのタスクを実現するために、ElastiCache は、バックアップの各スナップショット間で Redis キー空間を解析し、要求されたシャードやハッシュスロットの数に応じて、新しいクラスター内にキーを再分散します。RDB スナップショットを作成して、S3 に格納し、ElastiCache で希望のシャードおよびスナップファイルの数を指定します。Redis データストアを Redis クラスターに格納する面倒な作業も ElastiCache で行うことができます。中には、ElastiCache の「Redis バックアップおよび復元とクラスターのサイズ変更」機能を本当に簡単に活用できるのか、と考える方がいるかもしれません。検証している時間はありません。AWS マネジメントコンソールに移動し、ElastiCache を用いて外部の RDB スナップショットを新しいクラスターで復元し、新たにリリースされた拡張を使用します。まず、AWS マネジメントコンソールで、「Amazon S3 コンソール」に移動します。ElastiCache への外部の Redis スナップショットの復元をテストするために、AWS の一部ピアから受け取った Redis .rdb スナップショットファイルがいくつかあります。ElastiCache Redis クラスターの入力としてスナップショットにアクセスできるように、これらのファイルを Amazon S3 に配置します。

S3 コンソールで、テストおよび開発の目的で作成した S3 バケット、aws-blog-tew-posts に移動します。提供された .rdb スナップショットファイルをこの S3 バケットにアップロードします。

S3 バケットの名前は DNS 標準に準拠しなければなりません。DNS 標準に準拠するために、バケット名は 3 文字以上で、小文字の英文字、数字、ハイフンのみを使用し、先頭と末尾の文字は小文字の英文字または数字でなければなりません。当たり前かもしれませんが、バケット名は IP アドレスフォーマットにすることはできません。S3 バケットの制約の詳細については、「こちら」を参照してください。.rdb ファイルが正常に aws-blog-tew-posts バケットにアップロードされたら、これらのバックアップファイルへの S3 パスをメモします。上記のファイルの場合、パスは、aws-blog-tew-posts/dump_1.rdb または aws-blog-tew-posts/dump_10.rdb になります。ファイルをフォルダに配置する場合は、フォルダ名をこのパスに含む必要があります。例: thebucketname/thefoldername/thefilename

ElastiCache からこれらのファイルにアクセスするには、該当サービスに各ファイルの読み取り権限があることを確認します。アクセス権限を付与するには、被付与者を対象リージョンの正規化 ID として割り当てることで各 .rdb ファイルの読み取り権限をアップデートしてから、開く/ダウンロードのアクセス権限をこのユーザーに付与します。中国 (北京)、AWS GovCloud (米国) を除くすべてのリージョンの正規化 ID は次のとおりです。

540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353

[Save] ボタンをクリックすると、ElastiCache Redis クラスターの入力としてこれらのファイルを使用するように設定されます。

次に、ElastiCache コンソールに移動します。ここで、新たに ElastiCache Redis クラスターを作成し、このクラスターを S3 バケット内のファイルに配置された RDB スナップショットのいずれかのデータに追加します。dump_1.rdb スナップショットファイルを選択して、この新しいクラスターを追加するデータ入力として使用します。今年 10 月に Redis Cluster 3.2.4 のサポートによって追加された ElastiCache Redis 機能や、クラスターのサイズ変更に対応した新しいバックアップおよび復元機能について説明するため、Redis クラスターを新たに作成し、クラスターモードが有効であることを確認します。この時点で、Redis (クラスターモードが有効) クラスターを使用して作成されたバックアップから Redis (クラスターモードが無効) クラスターに復元することはできません。まず、ElastiCache コンソールダッシュボードの [今すぐ始める] ボタン、またはコンソールビューの [作成] ボタンをクリックします。

[Amazon ElastiCache クラスターの作成] ダイアログウィンドウで、キャッシュの [Redis] を選択し、[有効なクラスターモード (スケールアウト)] のチェックボックスがオンになっていることを確認します。新しいクラスターの名前は、tew-rediscluster となり、クラスターモードを有効にしているため、ElastiCache Redis のエンジンバージョンは、3.2.4 です。このクラスターの Redis ポートは、デフォルトの 6379 のままにしておきます。

ElastiCache 拡張の Redis バックアップおよび復元機能の主な利点は、元々バックファイルで使用されていた数と異なるシャード数で新しいクラスターを構築することができるクラスターのサイズ変更機能です。新しい Redis クラスターを構成するために、唯一の RDB スナップショットファイルである dump_1.rdb を使用します。このファイルは、シャードが 1 つのみの小さな Redis インスタンスバックアップです。ただし、新しい tew-rediscluster を作成する際、1 つのシャードに 2 つのレプリカを含む 3 つのシャードを選択しました。さらに、RDB スナップショットより、元のインスタンスとは異なるサイズの新しいクラスターのノードタイプを指定することもできます。前述の通り、dump_1.rdb は、以下に示した tew-rediscluster 向けに選択したノードタイプより大幅に小さい Redis インスタンスのバックアップです。

他にも、ElastiCache Redis クラスターを作成するために必要なオプションやデータ入力がありますが、このブログ投稿には記載していません。ただし、ElastiCache Redis クラスターの作成に必要な各ステップを行う場合は、『クラスターを起動する』の「AWS ElastiCache の開始」のドキュメントで詳細を確認してください。ElastiCache Redis クラスターの作成に必要な情報をすべて入力したら、ElastiCache で S3 バケットのファイル場所を指定して、クラスターに .rdb ファイルを追加する方法を指定します。作成ダイアログの「クラスターへのデータのインポート」セクションにおいて、「シードする RDB ファイルの S3 の場所」テキストボックスdump_1.rdb への S3 パスを入力します。S3 ファイルパスの命名法は、Bucket/Folder/ObjectName が適用されるため、S3 内の RDB ファイルへのパスとして、aws-blog-tew-posts/dump_1.rdb を入力します。最後に、[作成] ボタンをクリックします。

これで完了です。ElastiCache で新しい Redis クラスターを作成できるようになりました。間もなくすると、新しい Amazon ElastiCache Redis クラスターが ElastiCache コンソールで選択できるようになります。外部の RDB スナップショットファイルより復元されたデータでこのクラスターを作成することができました。

外部の RDB スナップショットを用いて ElastiCache Redis クラスターを作成する方法を説明しましたが、既存の ElastiCache Redis クラスターのバックアップを使用してバックアップを作成または復元することもできます。新たにリリースされた本機能の詳細をお知りになりたい場合は、『Amazon ElastiCache User Guide』の「バックアップからの復元とクラスターのサイズ変更」を参照してください。Amazon ElastiCache を使用したアプリケーションのパフォーマンス強化の詳細については、「AWS Amazon ElastiCache」の製品の詳細、リソース、お客様の声を参照してください。

Tara

発表: Amazon GameLift がすべての C++ と C# ゲームエンジンをサポート

by AWS Japan Staff | on | in Amazon GameLift |

すべてのゲーム開発者の方にお知らせします。数週間前にサンフランシスコで行われた GDC 2017 は大人気でした。そのため、クールなゲームの学習と構築に刺激を受け、情熱を注ぐには今が最適なタイミングです。ここで、Amazon GameLift がすべての C++ と C# ゲームエンジンで利用可能になったことをお知らせします。これには、Amazon Lumberyard、Unreal Engine、Unity が含まれ、そのすべてでゲームセッションのマッチング機能が向上しています。Amazon GameLift に詳しくないお客様向けに、ゲーム開発者が楽しく革新的なオンラインゲーム体験を提供できるよう支援するために設計された、このマネージド型サービスについてご紹介します。

Amazon GameLift は、専用ゲームサーバーをホストするためのマネージド型の AWS のサービスで、ゲーム開発者が簡単にゲームのキャパシティーをスケールし、利用可能なゲームセッションでプレイヤーをマッチングできるようにします。Amazon GameLift を使用すると、サーバーのホスト、ゲームの可用性の追跡、分散サービス拒否 (DDoS) 攻撃からのゲームサーバーの防御が可能なほか、ゲームをオフラインにすることなくアップデートをデプロイできます。Amazon GameLift サービスは Amazon Game Studios の専用ゲームサーバーや外部のゲーム開発顧客に役立ち、指定された時間内に開始、終了するゲームループで、セッションベースのゲームをサポートするよう設計されています。最新の Amazon GameLift リリースではサービスの最新機能が強化されているほか、開発者向けにゲームの開発とデプロイの簡略化を支援する優れた新機能が追加されています。Amazon GameLift サービスのクールな機能のいくつかについて見てみましょう。

  • 複数エンジンのサポート: 当初、Amazon GameLift サービスは Amazon Lumberyard ゲームエンジンのみで使用できました。現在、このサービスは強化され、Unreal EngineUnity のような一般的なゲームエンジンをはじめ、カスタム C# と C++ ゲームエンジンと統合されます。
  • 新しいサーバー SDK 言語のサポート: より多くのお客様と開発者をサポートするため、このサービスでは C# と C++ で利用できる Amazon GameLift Server SDK が提供されます。これには、Amazon GameLift 用の Unreal Engine API と互換性のある、カスタマイズされたバージョンの C++ Server SDK である Unreal Engine プラグインが含まれています。
  • クライアント SDK 言語サポートの拡張: Amazon GameLift Client SDK は 多数の言語で提供されている AWS SDK にバンドルされました。これにより、ゲーム開発者は選択した言語で Amazon GameLift サービスが統合されたゲームクライアントを構築できます。
  • マッチメーキング: Amazon GameLift は世界中の利用可能なゲームサーバーを継続的にスキャンし、プレイヤーのリクエストにマッチングしてゲームに参加させます。低レイテンシーのゲームサーバーが利用できない場合は、プレイヤーの周囲にキャパシティーを自動的に追加するようサービスを設定できます。Amazon GameLift は新しいゲームが開始されるか新しいインスタンスが起動するまで待機中のプレイヤーのキューを維持してから、待機中のプレイヤーを最もレイテンシーが低いゲームに配置します。
  • プレイヤーデータの処理: ゲーム開発者はカスタムプレイヤー情報を保存し、ゲームサーバーに直接渡せるようになりました。これにより、ゲームサーバーまたは API を持つその他のゲームエンティティは、Amazon GameLift からプレイヤーデータを取得できます。
  • コンソールのサポート: Amazon GameLift は、XBox One および PS4 用に開発、作成されたゲームをサポートします。

Amazon GameLift はセッションベースのマルチプレイヤーゲームの作成に必要であった手間のかかるタスクを、ゼロからのインフラストラクチャの構築に関連する時間、コスト、リスクを減らしつつ、ゲームサーバーのデプロイ、スケーリング、維持のプロセスを簡略化することで実行します。Amazon GameLift を利用するゲームソリューションのリファレンスアーキテクチャを次に示します。

 

ゲームへの Amazon GameLift の統合
ゲームビルドへの Amazon GameLift の統合はいくつかの簡単なステップに分割できます。

  1. Amazon GameLift Server SDK を使用してゲームサーバープロジェクトを設定し、プロジェクトに通信コードを追加して、ゲームサーバーで Amazon GameLift のホスティングを準備します。
  2. ゲームデプロイの対象とした AWS リージョンに対してゲームサーバービルドをパッケージ化し、アップロードします。
  3. ゲームをホストするための複数のコンピューティングリソースを作成、構築します。
  4. AWS SDK と Amazon GameLift API を使用して Amazon GameLift によって維持されるゲームセッションに接続するようゲームクライアントを準備し、Amazon GameLift サービスへの呼び出しのゲームクライアント用のコードを追加して、プレイヤーのリージョンを識別します。
  5. Amazon GameLift でホストされたゲームセッションに接続し、ゲームセッションを作成中であることを確認して、Amazon GameLift の統合をテストします。

Unreal ゲームエンジンを使用して簡単なゲームサーバープロジェクトで Amazon GameLift Server SDK をセットアップして、これらのステップの実行を開始しましょう。Unreal Engine (UE) Epic の Unreal ゲームエンジンから開始します。分かりやすいように、オンラインマルチプレイヤー機能が組み込まれたサンプルの Shooter Game プロジェクトを作成し、コンピュータにローカルに保存します。

マルチプレイヤー Shooter Game のサンプルをダウンロードし、マシンでローカルに開いたので、C++ コードを操作して、Amazon GameLift サービスを UE オンラインサブシステムに追加し、オンラインゲームセッションを管理する必要があります。Shooter Game サンプルは Unreal Engine の Blueprints Visual Scripting システムを利用します。Blueprints システムは UE エディタのノードベースのインターフェイスに基づくゲームプレイスクリプティングシステムです。これにより、ゲーム設計者とコンテンツ作成者は UE エディタ内でゲームプレイ要素と機能を作成できます。私の目標は Amazon GameLift C++ SDK を使用して Amazon GameLift サービスをゲームに含め、ゲームコードを変更することなので、ゲームと結び付ける Visual Studio プロジェクトソリューションを作成し、Shooter Game のソースコードとバイナリをプロジェクトに関連付ける必要があります。これを達成するため、コンテキストメニューに移動して、[File] メニューオプションを選択します。メニューのドロップダウンで、[Generate Visual Studio Project Files] オプションを見つけて選択します。

プロジェクトが生成されたら、コンテキストメニューに戻って [File] を選択し、プロジェクトを開いてソースコードを表示するために [Open with Visual Studio] を選択します。

Amazon Game Lift サービスをゲームサービスとして Shooter Game に追加する準備として、またゲームセッションの管理のため、プロジェクトで OnlineSubSystem モジュールを有効にする必要があります。これを行うには、Visual Studio プロジェクトでゲームビルド設定ファイルを開きます。このゲームプロジェクトの名前は ShooterGame であるため、ビルドファイルの名前は ShooterGame.Build.cs になり、次に示すように Source/ShooterGame フォルダにあります。

ビルドファイルを開き、OnlineSubsystemNull モジュールの行のコメントを解除します。既にマルチプレイヤーオンラインシステムを利用しているサンプルを使用しているため、ビルドオプションは適切に設定され、コードは次のようになります。

public class ShooterGame : ModuleRules
{
	public ShooterGame(TargetInfo Target)
	{
		PrivateIncludePaths.AddRange(
			new string[] { 
				"ShooterGame/Classes/Player",
				"ShooterGame/Private",
				"ShooterGame/Private/UI",
				"ShooterGame/Private/UI/Menu",
				"ShooterGame/Private/UI/Style",
				"ShooterGame/Private/UI/Widgets",
            		}
		);
       PublicDependencyModuleNames.AddRange(
			new string[] {
				"Core",
				"CoreUObject",
				"Engine",
				"OnlineSubsystem",
				"OnlineSubsystemUtils",
				"AssetRegistry",
             			"AIModule",
				"GameplayTasks",
			}
		);
       PrivateDependencyModuleNames.AddRange(
			new string[] {
				"InputCore",
				"Slate",
				"SlateCore",
				"ShooterGameLoadingScreen",
				"Json"
			}
		);
		DynamicallyLoadedModuleNames.AddRange(
			new string[] {
				"OnlineSubsystemNull",
				"NetworkReplayStreaming",
				"NullNetworkReplayStreaming",
				"HttpNetworkReplayStreaming"
			}
		);
		PrivateIncludePathModuleNames.AddRange(
			new string[] {
				"NetworkReplayStreaming"
			}
		);
	}
}

これで Shooter Game プロジェクトを設定したので、Amazon GameLift SDK に再び注目しましょう。C++ SDK を Unreal Engine のプラグインとして利用したいので、このゲームエンジン用のバイナリを構築するコンパイルディレクティブを使用して SDK をコンパイルする必要があります。SDK ソースをダウンロードした状態で、オペレーティングシステムに基づいてソースから SDK をコンパイルできます。このプロジェクトには Windows マシンを使用しているため、次のステップを完了します。

  • コードのコンパイルから生成されたバイナリを保持する out ディレクトリを作成します。

mkdir out

  • 前に作成したディレクトリに移動します。

cd out

  • CMake を使用して、VS 2015 Win x64 のビルドシステムジェネレーターを指定し、UE コンパイルフラグを設定します。

cmake -DBUILD_FOR_UNREAL=1 -G “Visual Studio 14 2015 Win64” <ソースディレクトリ>

  • 選択したビルドシステム (このプロジェクトの場合は MS Build) を使用してバイナリを作成する C++ プロジェクトを構築します。

msbuild ALL_BUILD.vcxproj /p:Configuration=Release

ライブラリをコンパイルしたので、Amazon GameLift Unreal Engine プラグインを使用するために次のバイナリファイルが必要です。

Linux:

* out/prefix/lib/aws-cpp-sdk-gamelift-server.so

Windows:

* out\prefix\bin\aws-cpp-sdk-gamelift-server.dll

* out\prefix\lib\aws-cpp-sdk-gamelift-server.lib

次に示すように、私は Windows を使用しているため、コンパイルされた Amazon GameLift ライブラリ aws-cpp-sdk-gamelift-server.dll および aws-cpp-sdk-gamelift-server.lib はそれぞれ prefix\bin および prefix\lib フォルダにあります。

GameLiftSDK Unreal Engine プラグインフォルダにバイナリをコピーすると、Amazon GameLift プラグインフォルダが設定され、Unreal Engine ゲームプロジェクトに追加する準備が整います。これを踏まえて、Unreal Engine の ShooterGame プロジェクトに Amazon GameLift プラグインを追加します。Unreal Engine Editor を使用してプラグインを追加できますが、その代わりに、Visual Studio プロジェクトに留まり、ゲームディレクトリとプロジェクトファイルを更新してプラグインを追加します。

Windows エクスプローラーで、Plugins というフォルダを ShooterGame ディレクトリに追加し、準備した GameLiftServerSDK フォルダを、Unreal Engine のプラグインに関するドキュメントに示されているように、このディレクトリにコピーします。

ここで、ShooterGame.Build.cs ファイルを開きます。これはゲームの依存関係に関する情報を保持する C# ファイルです。

ファイル内で次のコードを追加します。

PublicDependencyModuleNames.AddRange(
            new string[] {
                "Core",
                "CoreUObject",
                "Engine",
                "InputCore",
                "GameLiftServerSDK"
            }
       );

これまでに行った変更とすべてが同期されていることを確認するため、Visual Studio を閉じ、UE Editor に戻って [Refresh Visual Studio Project] を選択します。

完了したら、[Open Visual Studio] を選択します。ShooterGame ディレクトリに追加した Plugins フォルダがプロジェクトに含まれていて、Solution Explorer で表示できます。

次に、ソリューション全体を再構築して、Amazon GameLift SDK バイナリをプロジェクトに統合します。

UE Editor に戻り、ツールバーの [Build] を選択して、Amazon GameLift プラグインの側面が ShooterGame に含まれていることを確認します。コンパイルが完了したら、[Settings] ツールバーを簡単に確認します。[Plugins] オプションには Amazon GameLift プラグインが追加されていて、プロジェクトで認識されていることがわかります。[Enabled] チェックボックスを選択します。これにより、UE Editor の再起動が求められます。[Restart Now] を選択し、Unreal Engine がゲームコードファイルを再構築できるようにします。

ビルドが完了すると、エディタが再起動し、ShooterGame がもう一度開かれます。

これで ShooterGame プロジェクトで Amazon GameLift SDK の使用に関する設定が完了しました。Unreal エディタを開いた状態で、[Open Visual Studio] メニューオプションに移動し、ShooterGame コードに戻ります。これにより、Visual Studio およびゲームコードが開きます。Visual Studio を開いた状態で、ShooterGameMode.cpp ファイルに移動し、コードを追加して Amazon GameLift SDK を初期化します。Shooter Game プロジェクト内で Amazon GameLift に正しくコードを追加するために実行する必要がある主要なことは、次のとおりです。

  1. フラグ WITH_GAMELIFT=1 を使用してプリプロセッサ条件内で Amazon GameLift コードを囲みます
  2. 対象のサーバー OS (Linux など) 用に、Unreal Engine で専用サーバーを構築します
  3. ビルドの対象がゲームサーバータイプであることを確認します (Type == TargetRules.TargetType.Server)

Unreal Engine プロジェクトで Amazon GameLift を追加するために必要なコードの例は、こちらのドキュメントに記載されています。さらに、Unreal Engine wiki で提供されている Windows および Linux 向けの専用サーバーガイドに従って、Unreal Engine の専用サーバーを構築する方法を参照できます。これらの資料を利用すると、Amazon GameLift をゲームプロジェクトに首尾よく統合できます。Unreal Engine ゲームエンジンへの Amazon GameLift SDK の組み込みについて簡単に説明しましたが、Amazon GameLift SDK を Unity など C# エンジンに追加するオプションもあることを忘れないでください。Amazon GameLift Server SDK をダウンロードし、.Net framework 3.5 ソリューションをコンパイルすることで、GameLiftServerSDKNet35.sln になります。GameLiftServerSDKNet35.sln ソリューションを使用すると、Amazon GameLift ライブラリを Unity3D プロジェクトに追加することができます。Amazon GameLift C# Server SDK プラグインのセットアップと使用の詳細については、Amazon GameLift SDK ドキュメント「Unity での C# サーバー SDK の使用」を参照してください。

要約
Amazon GameLift マネージド型サービスに追加された新しい側面の 1 つのみを説明しましたが、このサービスは開発者やゲームスタジオに対してさらに多くの機能を提供しています。Amazon GameLift は、DDoS 攻撃からゲームを防御しながら、インフラストラクチャの管理、キャパシティーのスケーリング、利用可能なゲームセッションへのプレイヤーのマッチングを簡単にして、分散型ゲームを構築できます。

Amazon GameLift サービスの詳細については、Amazon GameLift のドキュメントと Amazon GameLift 開発者ガイドを参照してください。また、Amazon GameDev チュートリアルページの Amazon GameLift チュートリアルを確認して、Amazon GameLift サービスを使用したゲーム開発を本格的に開始することができます。どうぞゲームをお楽しみください。

Tara