Author: AWS Japan Staff


新機能 – TTL(Time to Live)機能を利用したDynamoDBアイテムの管理について

AWSを利用頂いている多くのお客様にDynamoDBは使用されています。速度と柔軟性がその理由で、Ad Tech( リファレンスアーキテクチャ )、Gaming( リファレンスアーキテクチャ )、IoT( リファレンスアーキテクチャ )、そして一貫した一桁のミリ秒のレイテンシを実現しアプリケーションを構築されています。また、DynamoDBはフルマネージドのデータベースで、テラバイトサイズのテーブルに対して毎秒何百万というリクエストを処理することができます。
多くのDynamoDBユーザーは、利用する時間が限られている、または時間の経過とともにアクセス頻度が低くなるデータを格納しています。 直近のログイン、試用版のサブスクリプション、アプリケーションのメトリックなどへの利用がそうです。 他にも保管できる期間に関する規制または契約上の制限の対象となるデータを保管します。 これまで、これらを実現するには独自の時間ベースのデータ管理を実装していました。 大規模なシステムでは、DynamoDBアイテムのスキャン、期間を管理するための日付属性の確認、および不要になったアイテムの削除要求を行う為のAmazon Elastic Compute Cloud(EC2)インスタンスを構築するなどの必要があり、これによりアプリケーションのコストと複雑さが増加していました。

新しいTime to Live(TTL)管理 について
この普及した重要なユースケースを合理化するため、新しくTTL(Time to Live)機能の提供を開始しました。 アイテムの有効期限を属性で指定する事により、テーブル単位でこの機能を有効にすることができます。
属性が指定され、TTL管理が有効になると(1回のAPI呼び出しで両方の操作が処理されます)、DynamoDBは期限切れのアイテムを見つけて削除します。 この処理は、自動的かつバックグラウンドで行われ、テーブルへの読み取りまたは書き込みトラフィックには影響しません。

DynamoDBストリームを使用することで(詳細は、「 DynamoDBアップデート – トリガ(Streams + Lambda)+クロスリージョンレプリケーションアプリケーション」を参照)。実際の削除を処理またはアーカイブすることができます。 ストリーム内の他の更新レコードと同様に、削除は24時間単位で行われます。 AWS LambdaおよびDynamoDB Triggersを使用して、期限切れのアイテムをコールドストレージに移動したり、ログに記録したり、他のテーブルを更新したりすることができます。

テーブルのTTLを有効にして、必要な属性を指定する方法は次のとおりです。

指定する属性はDynamoDBのNumber型かつ、 UNIX時間でTTLの指定を行います。
上のスクリーンショットからわかるように、DynamoDB Streamsを有効にすることもできます。また、TTLを有効にすると削除されるアイテムのプレビューを見ることもできます。

また、コードからUpdateTimeToLive関数を呼び出しテーブルにTTLの有効化設定することも、 AWSコマンドラインインターフェイス(CLI)からupdate-time-to-liveコマンドを使用しテーブルでTTLを有効化設定することもできます。

TTL の利用事例(TUNE様)

 AWSのお客様であるTUNEは既に、この機能をHasOffers製品の一部として活用しています。

HasOffersは、マーケティングキャンペーンの効果を分析し、大量の広告エンゲージメントデータをプロセスに保存するのに役立ちます。 キャンペーンの顧客定義の時間枠が過ぎると、データは不要になり、削除することができます。 TTL機能をTUNEで使用できるようにする前は手動で期限切れアイテムを識別し、古いデータを削除しました。 これは労力と激しく計算を必要とし、テーブルのプロビジョニングされたスループットの一部も消費する必要がありました。

今は各アイテムの有効期限を設定し、あとはDynamoDBに任せます。 失効したデータは自動的に消え、使用可能なスループットには影響しません。 その結果、TUNEは85テラバイトの古いデータを削除することができ、年間200,000ドル以上のコストを削減し、アプリケーションロジックも簡素化しました。

知っておくべきこと
あなたのアプリケーションにTTLを使用することを検討する際、留意すべきことがいくつかあります。

TTL属性 – TTL属性は索引付けまたは投影することができますが、JSONドキュメントの要素にすることはできません。 前述したように、Numberデータ型を持つ必要があります。 他の属性と同様に、IAMを使用してこの属性へのアクセスを制限することができます。 指定されたTTL属性を持たない項目は削除対象とはみなされません。 誤ったTTL値による誤った削除を避けるため、5年以上経過しているように見えるアイテムは削除されません。

テーブル – 新しいテーブルまたは既存のテーブルにTTLを適用できます。 テーブルのTTLを有効にするプロセスには最大1時間かかります。一度に1つのテーブルへの変更しか行うことはできません。

削除のバックグラウンド処理について – スキャンと削除はバックグラウンドで行われ、プロビジョニングされたスループットにはカウントされません。 削除時間は、期限切れアイテムの数と性質に応じて異なります。 期限切れの後、実際に削除が行われる前にはアイテムはまだテーブルに残り 、 読み取りとスキャンに表示されます。

インデックス – アイテムは、ローカルのセカンダリインデックスからすぐに削除され、グローバルセカンダリインデックスからは、最終的に一貫した方法で削除されます。

価格 – 内部スキャン操作、削除操作には費用は掛かりません。 アイテムが実際に削除されるまではストレージの支払いが発生します。

今すぐ利用可能
この機能は現在利用可能で、今すぐ使用することができます! 詳細は、「DynamoDBデベロッパーガイド」の「 TTL (訳注:翻訳時点では英語版のみです)」を参照してください。

 

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

(速報) 2016年AWS Partner Network(APN) Award発表!

みなさん、こんにちは。Partner SA 酒徳です。

本日、東京ミッドタウン カンファレンスホールにてAWS Partner Summit 2017 – Japan が開催され、昨年2016年の功績を讃え、APN Awardの授与式も同時に行われました。
APN Awardは一年を通し、各分野において最もパフォーマンスを発揮されたAPNパートナー様が受賞されるアワードで、今年は下記5つの分野において受賞パートナー様が選出されました。

APN Awardを授与されましたパートナー様とその授与内容についてご紹介させて頂きます。

– APN Partner of the Year 2016
年間を通じて営業・技術・マーケテイング分野等のパートナーとしての総合力で判断し、 AWSのビジネスに最も貢献いただいたAPNパートナー様が受賞

– APN Rising Star of the Year 2016
APNに加入して頂き1年目にして、AWSビジネスに最も高く貢献頂いたAPNパートナー様が受賞

– APN Cloud Business of the Year 2016
AWSが企業のビジネスに大きく貢献いただき、市場に大きな影響を与えたAPNパートナー様が受賞

– APN Architecture of the Year 2016
AWSの利用アーキテクチャがクラウド利用上優れているものの中から、最も先進的、実用的、チャレンジングなものをAWS のソリューションアーキテクトが選定。同システムを構築したAPNパートナー様が受賞

– APN Reference of the Year 2016
お客様公開事例において、AWSが企業ビジネスに大きく貢献する事を示し、市場に大きな影響を与えたAPNパートナー様が受賞

それでは、早速受賞パートナー様をご紹介させて頂きます。

– APN Partner of the Year 2016
受賞パートナー:アイレット株式会社

 

logo_cloudpack500

 

受賞理由:昨年に引き続き、多くのAWS関連ソリューション、多数の顧客事例のリリースや 積極的なメディア活動を通じて、メディア、エンターテイメント、スタートアップ企業のみならず、企業や教育機関(大学)のAll‐in移行を手掛けるなど更なるAWSビジネスの拡大に貢献されました。 新サービスも積極的に採用して成功させる一方で、エンタープライズ案件も推進してきた結果、著しい売り上げ伸び率を示されました。

 

– APN Rising Star of the Year 2016
受賞パートナー:日本事務器株式会社
logo-NJC-M-01c
受賞理由:自社製の中堅企業/団体向け各種業務パッケージをAWS上で構築されました。日本中にAWSユーザーを拡大いただいただけではなく、自社のワークスタイル革新の一環としてAmazon WorkSpacesを導入。自社がモデルケースとなり、その知見をお客様に届けることを推進いただきました。結果として、この1年の売り上げ伸び率が新規パートナーの首位を記録されました。

 

– APN Cloud Business of the Year 2016
受賞パートナー:株式会社ソラコム

 

soracom

 

受賞理由:IoT通信プラットフォーム「SORACOM」を、AWSの機能をフル活用してAWS上にソフトウェアで構築し、IoT/M2Mに最適化された通信プラットフォームを日本発でグローバルに展開されています。AWS KinesisなどAWSの各種サービスとの親和性も高く、AWS IoTコンピテンシーの認定も受けられました。既に多くのユーザーがIoTの様々なシーンで活用する中で機能の追加、拡張を続けていらっしゃいます。

 

– APN Architecture of the Year 2016
受賞パートナー:株式会社野村総合研究所

 

logo_NRI

 

受賞理由:高速処理、高可用性、高セキュリティを求められる金融業界の証券トレードシステム領域に対して、AWS Lambda を始めとするAWSのマネージドサービスを活用したクラウドネイティブアーキテクチャを構築されました。またお客様の長期的なクラウドジャーニーを策定した上で、本プロジェクトをその第一歩として定義し、レガシーシステムからクラウドらしいアプリケーションへの移行と、クラウドネイティブの圧倒的な開発スピードと効率性を実証した点を高く評価させていただきました。

 

– APN Reference of the Year 2016
受賞パートナー:株式会社オージス総研
OGISRI
受賞理由:AWSを活用した国内最大規模の優れたIoTの成功例として、大阪ガス様のエネファーム事例を公開いただきました。さらに、AWSの各種イベント等でのご登壇のみならず各種メディアでの露出も多く、AWSビジネスに大きく貢献いただきました。ユーザー、事業者の双方に多大なメリットを提供しながら、全国への普及を含め国の燃料電池発電に関する目標達成をサポートする社会的公益性の高い事例でもあります。

 

受賞パートナーの皆様、本当におめでとうございます!
昨年は多くのパートナー様のお力沿いを得られ、AWS Japanとして飛躍の年となりました。今年も昨年以上にエコシステムの拡大、充実をテーマに更なるSuper Powerの原動力にAWSをご活用頂けますと幸いです。
2017年も引き続き、ご支援のほど宜しくお願い申し上げます。

pic_award

 

AWS Alliance一同

シャーディングされたシステムをAuroraに集約してリソースの消費を削減

リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。一方スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。

難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。もし4つのシャードを持っているとすると、4つのデータベースを管理する必要があります。しかし、たとえそうだとしてもスケールアウトはスケールアップよりコスト効率がいい場面が多かったのです。特にAmazon RDSの様なマネージドデータベースの登場によりリレーショナルデータベースの管理を軽減することが出来るようになったのがその1つの要因です。

しかし、なぜ過去形なのでしょうか? Amazon Auroraの登場によりスケールアップという選択肢が戻ってきたのです。Amazon Auroraは非常にスケールし、MySQL互換のマネージドデータベースサービスです。Auroraは2 vCPU/4 GiBメモリというスペックのインスタンスから、32 vCPU/244 GiBメモリ搭載のインスタンスまでを提供しています。Amazon Auroraは需要に応じてストレージが10 GBから64 TBまで自動的に増加します。また、将来のリードキャパシティの増加に備えて15インスタンスまで低遅延のリードレプリカを3つのアベイラビリティーゾーンに配置することが可能です。この構成の優れている点は、ストレージがリードレプリカ間でシャーディングされている点です。

シャーディングされたシステムを1つのAuroraインスタンスに集約、もしくは少数のシャードに集約しAuroraで稼働させることで多くのコストを節約する事が可能です。これがこのブログポストでお話したいことの全てです。

シャーディングされたシステムをAuroraに集約するために – まずはじめに –

多くのシャーディングされたシステムは標準的な方法で行うことが可能です。データはカスタマーIDなどの特定のキーを元に分割されており、何かしらマッピングを行う機能を用いてシャードに分割されています。この方法には様々な種類があり、1例として参照用のデータを別のシステムか1つのシャードに格納したり、全てのシャードに参照用のデータを配置するなどがあります。どのようにデータを分割しても、シャーディングの複雑さは通常、アプリケーションレイヤーにあり、シャードの統合は比較的容易に行えます。

多分皆さんは今、”利点はわかった。ではどうやってAuroraにデータを移行するのか”という疑問をお持ちかと思います。今回の例では、MySQLを利用して4つのシャードを持つシステムを利用していると仮定したいと思います。また、各シャードは他のシャードが持っているデータを持っていないものとします。また1つのシャードが参照用のデータを持っている前提とします。現在の構成は以下の図の様な構成になっていると思います。mapは各シャードへのアプリケーショントラフィックを表しています。

ShardMap

MySQLを運用しているため、Aurora documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。しかし、どのシャードを最初に移行するかはそれほど重要ではありません。 移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。

ShardMap1

残りのデータを移行する

この時点で、Auroraが特定のワークロードをどれくらいうまく処理しているか評価し、必要な調整を行う必要があります。設定に問題がなくなれば、他のデータを移行する準備は完了です。では、シャード2をAuroraインスタンスに移行しましょう。しかし、どうやって?

 

AWS Database Migration Service (AWS DMS)を是非ご活用下さい!AWS DMSはこのようなマイグレーションにも対応するように作られました。シャード2からAuroraインスタンスへデータをコピーするためにDMSをご利用になれます。更に、シャード2にとランアクションを実行しながらこれらの作業が可能です。DMSは初期データのロードが完了すると、それらのトランザクションデータをシャード2から収集しAuroraインスタンスに適用します。DMSは継続的にシャード2からAuroraインスタンスへデータを移行し、シャード2の代わりにAuroraインスタンスの利用を開始させるまで同期させます。シャード2からAuroraインスタンスへ切り替える準備が出来たら、シャード2へのトランザクションを停止し、DMSが最後のトランザクションをAuroraインスタンスへ適用するまで待ち、mapの設定を、シャード2に向いていたトラフィックを直接Auroraインスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。

ShardMap2

この時点から、Database Migration Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。

ShardMap3

 

複雑なシャードの扱い方

これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました!しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。もしこれらの仮定にそぐわない場合はどうでしょうか?

それでは、シャードがクリーンな状態でない場合を見ていきましょう。例えば、システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。 リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。 結果は次のようになります。

AppTier

この図は状況が複雑であるように見えます。 理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。 しかし、必ずしも必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。 この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。 これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。

何をすべきか? シャードの統合を行う前に、利用していない行を削除することができます。 しかし、特にマッピング関数がID値のハッシュ(一般的な方法の1つ)で構成されている場合、利用していない行を特定するのは難しいかもしれません。

諦めないで下さい! 別のオプションがあるかもしれません。 各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。 次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。 この例では、Auroraインスタンスは次のようになります。

ShardMap4

MySQL以外のデータベースを利用している場合

他の仮定として、データベースエンジンとしてMySQLデータベースを利用をしている前提がありました。もしそうでなければ? OracleまたはMicrosoft SQL Serverを使用する場合はどうなるでしょうか? 大丈夫です! AWS Schema Conversion Tool が役立ちます!

ドキュメントの最初で「AWS Schema Conversion Toolは、ソースデータベースのスキーマとカスタムコードの大部分をターゲットデータベースと互換性のあるフォーマットに自動的に変換することで、異種データベースの移行を容易にします」と述べています。シャーディングされたシステムでは、ストアドプロシージャとトリガを使用してデータベース内に組み込まれた多くのビジネスロジックは、通常すでにアプリケーション側に移動されています。 AWS Schema Conversion Toolで、ソースデータベースとしてサポートされているデータベースエンジンでシャーディングされたシステムを利用している場合、Auroraへの変換と統合が可能かどうかを調べる価値があります。 統合の恩恵を受けるだけでなく、オープンソースプラットフォームへの移行のメリットも得られます。

さらに踏み込んで

さらに詳細に興味がありますか? AWS Database Migration Service を使用して、シャーディングされたデータベースを1つ以上のAuroraインスタンスに統合する方法を説明する資料をまとめはじめました。 この例では、DMSチームが提供するMySQLサンプルデータベースのシャーディングバージョンを使用しています。 私たちはこのシャーディングされたバージョンをRDSスナップショットとして利用できるようにしました。 スナップショットは公開されているため、こちらの説明に従って試すことが可能です。それぞれ、説明中でmysql-sampledb-master-shard、mysql-sampledb-shard1、mysql-sampledb-shard2と呼ばれていたものです。

 

— Ed Murray (manager at Amazon Web Services) (翻訳は星野が担当しました。原文はこちら)

 

 

 

 

 

 

AWS ホットスタートアップ – 2017 年 2 月

2 月を終わるにあたって、Tina Barr が再びすばらしいスタートアップ企業をいくつかご紹介します。

-Ana


今月は、5 社の革新的でホットなスタートアップ企業をご紹介します。

  • GumGum – イメージ内広告という分野を作成、一般化。
  • Jiobit – 保護者が子供を追跡するためのスマートタグ。
  • Parsec – PC ゲーマー用のハードウェアと場所の柔軟性を向上。
  • Peloton – 家庭でのインドアサイクリングとフィットネス教室を変革。
  • Tendril – 自宅所有者のエネルギー消費を減らす。

1 月のスタートアップをすべてお読みになっていない場合は、ぜひこちらからご確認ください。

GumGum (カリフォルニア州サンタモニカ)
GumGum logo1GumGumイメージ内広告という分野を開発し、一般化したことでよく知られています。Ophir Tanz 氏によって 2008 年に設立された同社は、ソーシャルメディア、論説、さまざまな業界のブロードキャストを通じて毎日作成される膨大なコンテンツ内に留まっている価値を解放するという目標を掲げています。GumGum は 2,000 以上の大手出版社でキャンペーンを行っており、4 億人以上のユーザーがこれを見ています。イメージ内広告は GumGum によって開発され、顧客の注目が既に集まっている場所に、非常に目立つ広告を配信するプラットフォームを企業に提供してきました。GumGum は画像認識技術を使用して、関連するイメージの状況に応じたオーバーレイ、あらゆる画面サイズに適応するバナー、または周囲のコンテンツにシームレスに融合するフィード内プレースメントとして、対象を絞り込んだプレイスメントを配信しています。GumGum は、Visual Intelligence を使って、ブランドに関連するあらゆるイメージや動画についてソーシャルメディアやブロードキャスト TV を検索し、視聴者についてと、視聴者がソーシャルメディアでそのブランドにどのようにかかわっているかをより良く理解できるようにしています。GumGum はイメージ処理と広告配信オペレーションに AWS を利用しています。現在、AWS のインフラストラクチャを使って、世界中で 1 分あたり 1300 万件のリクエストを処理し、毎日 30 TB の新しいデータを生成しています。同社は、Amazon EC2Amazon S3Amazon KinesisAmazon EMRAWS Data PipelineAmazon SNS など (これらに限られません) のサービスのスイートを使用しています。GumGum は、AWS エッジロケーションにより米国、欧州、オーストラリア、および日本の顧客に対応しており、今後はオーストラリアおよび APAC リージョンにインフラストラクチャを拡大する計画です。GumGum のスタートアップカルチャの詳細については、最初のハッカソンをご覧ください

Jiobit (イリノイ州シカゴ)
Jiobit Team1

Jiobit
は、混雑したシカゴの公園で発生した現実の出来事に影響を受けました。何年か前の夏に、John Renaldi 氏は保護者にとって最悪の悪夢を経験しました。つまり、都市公園で当時 6 歳の息子を約 30 分にわたって見失ったのです。John は、このような問題を経験したのは自分だけではないと知りました。何か月かの調査の後、保護者の 50% 以上が同じような経験をしており、さらに多くの保護者が行方不明を防止するための方法を積極的に探していることがわかりました。Jiobit は、屋内外を含むあらゆる場所で子供を追跡できるようにする、世界最小で最も長持ちのスマートタグです。この小型のデバイスは軽量で耐久性があり、水にも強く、子供にも安全して使用できます。Bluetooth、Wi-Fi、複数の携帯ネットワーク、GPS、センサーを組み合わせて使用する仮想的な「安全装具」として機能し、リアルタイムで正確な場所を知らせます。Jiobit は自動的にルートや場所を学習し、子供が時間どおりに目的地に到着しない場合は、保護者にアラートを送信します。経験豊富なエンジニア、設計者、マーケッター、および保護者の優秀なチームが 150 以上の特許を取得し、数多くのハードウェアおよびソフトウェア製品を世界中に出荷しています。Jiobit チームは製品の開発にあたって数多くの AWS のサービスを利用しています。製品の全体的な体験にはセキュリティが重要であり、AWS の支援により、ハードウェアとソフトウェアの両面で十分以上のセキュリティを持たせています。また、Jiobit は Amazon Echo デバイスを通じて Alexa Skill を実装する初めての子供用モニタリングデバイスを開発中です (デモについてはここをクリック)。これらのデバイスは AWS IoT を使用して、MQTT プロトコル経由で Jio Cloud からデータを送受信します。データを受信すると、AWS Lambda を使用して受信データを解析し、適切なアクション (Amazon DynamoDB を使用した該当データの保存、Amazon Machine Learning 処理ジョブへの場所データの送信など) を実行します。詳細については、Jiobit のブログをご覧ください。

Parsec (ニューヨーク州ニューヨーク)
Parsec ロゴ large1
Parsec は、技術へのアクセスにより無限の機会が生まれるため、すべての人が世界最高のコンピューティングにアクセスできるべきである、という考えに基づいて運営されています。Benjy Boxer 氏と Chris Dickson 氏によって 2016 年に設立された Parsec は、クラウド上のコンピュータをいつでもどこでも利用可能にする技術を構築することで、ユーザーが頻繁に経験するハードウェアのアップグレードという負担をなくすことを目指しています。現在、同社はその技術を使って、PC ゲーマーがお気に入りのゲームをプレイするために選択するハードウェアと場所の柔軟性を高めています。当社のスタートアップチームと Benjy とのこのインタビューで、Parsec の仕事についてご確認ください。Parsec は、最初の製品を構築してゲーム体験を強化しました。ゲーマーは、お気に入りのエンターテインメントにアクセスするために、コンソールや高価な PC を購入する必要はなくなりました。その低レイテンシーのビデオストリーミングとネットワーキング技術により、ゲーマーはゲームリグにリモートにアクセスし、あらゆる Windows、Mac、Android、または Raspberry Pi デバイスでプレイすることができます。AWS の世界展開により、Parsec は米国および欧州の平均的なユーザーに、30 ミリ秒以下というネットワークレイテンシーでクラウドゲームを提供することができます。現在、Parsec はクラウドリソースでゲームを開始するために使用できる 2 つのオプションを提供しています。リージョンで Parsec AMI により独自のマシンをセットアップするか、すべての管理を Parsec に任せてシームレスな体験を得ることができます。いずれの場合も、Parsec は g2.2xlarge EC2 インスタンスタイプを使用しています。Parsec は Amazon Elastic Block Storage を使用してゲームを保存し、スケーラビリティのために Amazon DynamoDB を、ウェブサーバーとさまざまな API 用に Amazon EC2 を使用しています。また、大量のログを扱い、Amazon Elasticsearch Service を利用してデータを分析しています。最新情報については、Parsec のブログをご覧ください。

Peloton (ニューヨーク州ニューヨーク)
Peloton イメージ 3
Peloton のアイデアは、2012 年に創立者であり CEO の John Foley 氏とその夫人 Jill 氏が仕事、子育て、健康維持のバランスを取るという課題に気付いたことにより生まれました。これは人々がよく直面する課題です。つまり運動はしたいが、いろいろと障害があるというものです。Peloton は、いつでもどこでも屋内のサイクリングとフィットネス教室に参加できるようにするソリューションを提供しています。Peloton は、毎日 14 時間ライブ教室をストリーミングし、4,000 以上のオンデマンド教室を持つ最新鋭のインドアバイクを作成しました。ユーザーは自宅やジムから世界クラスのインストラクターによるライブ教室にアクセスできます。このバイクは詳細な走行メトリクスにより進捗状況を追跡し、同じ条件で他のユーザーとリアルタイムで競争することができます。ライブ教室では、ユーザーのモチベーションを保つために、一流の DJ による最新プレイリストの演奏もあります。注目度の高い TV 広告を含む積極的なマーケティングキャンペーンにより、Peloton はプラットフォーム全体をクラウドで実行する決定を下しました。最も最近では、NFL プレイオフゲーム中に広告を流し、サイトへの 1 分あたりのリクエストのレートは 60 秒以内に ~2k /分から ~32.2k / 分に増えました。同社の成長と多様化につれて、アーカイブされた数千時間のオンデマンドビデオコンテンツに Amazon S3、データウェアハウスに Amazon Redshift、インテリジェントなリクエストのルーティングに Application Load Balancer を利用しています。Peloton のエンジニアリングチームの詳細については、こちらをご覧ください

Tendril (コロラド州ボルダー) Tendril logo1
Tendril
は 2004 年に、自宅所有者がエネルギー消費を管理し、減らすことができるよう支援することを目的に設立されました。現在、電力会社やガス会社は 1.4 億以上の世帯で Tendril のデータ分析プラットフォームを使って、世界中の消費者向けに個人設定されたエネルギー体験を提供しています。Tendril は決定科学と分析に最新の技術を使用することで、エネルギー消費者とその世帯に関するリアルタイムの絶えず変化しているデータにアクセスでき、顧客の獲得、エンゲージメントの増加、ホームエネルギー体験の調整を可能にしています。同様に、Tendril は顧客がエネルギーの取引から真の価値を引き出せるよう支援しています。AWS は、Tendril が必要に応じてリアルタイムでキャパシティーを増減し、サービスをグローバルに提供できるようにしています。これは Tendril の最新ソリューションである Orchestrated Energy のサポートでは特に重要でした。Orchestrated Energy は家庭の熱質量を計算し、消費者の行動を予測して、スマートサーモスタットやその他の接続されたホームデバイスと統合される連続的な要求管理プラットフォームです。このソリューションにより、数百万人の消費者が、個々のニーズに基づいて自宅用に個人設定されたエネルギー計画を作成することができます。Tendril は Amazon EC2 インスタンスで実行されるオープンソースツールでそのほとんどのインフラストラクチャサービスを維持していますが、Elastic Load BalancingAmazon API GatewayAmazon CloudFrontAmazon Route 53Amazon Simple Queue ServiceAmazon RDS for PostgreSQL などの AWS のサービスも併せて利用しています。詳細については、Tendril のブログをご覧ください。

— Tina Barr

新機能 – Time to Live (TTL) を使用した DynamoDB 項目の管理

AWS のお客様は Amazon DynamoDB を十分に活用しています。お客様は、その速度と柔軟性を気に入り、一貫性がある数ミリ秒台のレイテンシーを活かした広告技術 (リファレンスアーキテクチャ)、ゲーム(リファレンスアーキテクチャ)、IoT (リファレンスアーキテクチャ)、およびその他のアプリケーションを構築しています。また、DynamoDB はマネージ型のサーバーレスデータベースとして、数テラバイトというサイズのテーブルに対する 1 秒あたり数百万件ものリクエストを処理するようにスケールできる点も好評です。多くの DynamoDB ユーザーは、有効期限があるデータや、時間とともにアクセス頻度が低くなるデータを保存している場合があります。最近のログイン、トライアルのサブスクリプション、またはアプリケーションのメトリクスを追跡する場合もあります。保存期間が規制または契約で制限されるデータを保存している場合もあります。このような場合、これまでは独自の時間ベースのデータ管理を導入していました。大規模なケースでは、DynamoDB 項目のスキャン、データ属性のチェック、不要になった項目の削除リクエストの発行などを行うためだけに、数個の Amazon Elastic Compute Cloud (EC2) インスタンスを実行することもありました。これに伴って、アプリケーションのコストと複雑さが増大しました。

新しい Time to Live (TTL) による管理
この一般的で重要なユースケースを効率化するため、当社は本日から、新しい Time to Live (TTL) 機能の提供を開始します。この機能をテーブルごとに有効にし、項目の有効期限を含む項目属性を指定できます。項目属性を指定して TTL 管理を有効にすると (1 回の API コールで両方のオペレーションを実行できます)、DynamoDB が、有効期限が切れた項目を見つけて削除します。この処理は自動的にバックグラウンドで実行され、テーブルに対する読み取りまたは書き込みトラフィックに影響を与えることはありません。DynamoDB ストリーム(詳細については、「Sneak Preview – DynamoDB Streams」を参照) を使用して、実際の削除を処理またはアーカイブできます。削除は、ストリームの他の更新レコードのように、ローリング期間の 24 時間ベースで使用できます。有効期限が切れた項目については、AWS Lambda および DynamoDB トリガーを使用してコールドストレージへの移動、ログへの記録、または他のテーブルの更新を行うことができます。テーブルに対して TTL を有効にし、必要な属性を指定する方法を次に示します。

属性は DynamoDB の数値データ型とする必要があり、UNIX エポック時間形式に従って秒数として解釈されます。上記のスクリーンショットからおわかりのように、DynamoDB ストリームを有効にして、TTL を有効にしたときに削除される項目のプレビューを表示することもできます。また、コードから UpdateTimeToLive 関数を呼び出すか、 update-time-to-live コマンドを AWS Command Line Interface (CLI) から使用することもできます。

TUNE での TTL
AWS のお客様である TUNE は、既にこの機能を自社製品である HasOffers の一部として十分に活用しています。

HasOffers-Dashboard-Phone

HasOffers を使用すると、顧客はマーケティングキャンペーンの効果を分析し、そのプロセスで大量の広告エンゲージメントデータを保存できます。顧客が定義したキャンペーンの時間枠が経過すると、データは必要なくなり、削除できます。当社が TUNE に対して TTL 機能を提供する前は、古くなったデータを手動で識別して削除していました。これは大量の作業と演算を伴う作業であり、テーブル用にプロビジョニングされたスループットの一部を消費していました。現在では、各項目の有効時間を設定するだけで、後は DynamoDB に任せることができます。古くなったデータは自動的に消え、利用可能なスループットに影響はありません。その結果、TUNE は古くなった 85 テラバイトのデータを消去し、アプリケーションロジックを簡略化しながら、年間 20 万 USD を超えるコストを節約しています。

主要事項 お客様のアプリケーションで TTL の利用を検討する際は、以下のことを念頭に置いてください。TTL 属性 – TTL 属性はインデックス化または射影できますが、JSON ドキュメントの要素とすることはできません。前に示したように、数値データ型が必要です。その他の属性と同様に、IAM を使用してこの属性へのアクセスを制御できます。TTL 属性が指定されていない項目は、削除対象とは見なされません。TTL の値が正しい形式ではないために誤って削除される可能性を避けるため、5 年より古いと思われる項目は削除されません。テーブル – 新しいテーブルまたは既存のテーブルに TTL を適用できます。テーブルに対して TTL を有効にするプロセスは最大で 1 時間かかり、一度にテーブルに対して行うことができる変更は 1 つのみです。バックグラウンド処理 – スキャンと削除はバックグランドで実行され、プロビジョニングされたスループットに対してはカウントされません。削除時間は、期限切れの項目の数と特性によって異なります。項目は、有効期限が切れてから実際に削除されるまでテーブルに残り、読み取りやスキャンで表示されます。インデックス – 項目はローカルセカンダリインデックスから直ちに削除され、グローバルセカンダリインデックスからは結果的に整合性のある形式で削除されます。料金 – 内部スキャンオペレーションまたは削除に対して料金は発生しません。項目が実際に削除されるまでのストレージ分のみ、お支払いいただくだけです。

今すぐ利用可能
この機能は今すぐ使い始めることができます。詳細については、DynamoDB 開発者ガイドの「Time to Live」を参照してください。

Jeff;

AWS Organizations – 複数の AWS アカウントのポリシーベースの管理

複数の AWS アカウントを管理しているお客様が少なくありません。いくつかの理由が考えられます。AWS を徐々に導入して全体に広げている組織では、個別のチームや部門が一元管理されることなくクラウドコンピューティングに移行している場合があります。合併や買収を通じて成長している組織では、既存のアカウントを引き継ぐ場合があります。厳格なコンプライアンスのガイドラインに従うため、またはアプリケーション間に強い隔離障壁を設けるための通常の対策として複数のアカウントを作成する場合もあります。さらに開発、テスト、実稼働の目的別に異なるアカウントを使用する場合もあります。アカウント数が増大すると、全体をスケーラブルに管理する方法が必要になります。お客様は、チーム、部門、アプリケーションごとのアカウントを個別に扱わずに、アクセスコントロールポリシーを定義して全体、一部、または個別のアカウントに簡単に適用する方法を求めています。このようなお客様は、さらに請求やコスト管理にも関心が高い場合が多く、ボリュームディスカウントやリザーブドインスタンスなどの AWS の料金面でのメリットを、より広範囲にアカウントに反映できることを希望しています。

AWS Organizations がプレビューから一般公開へ
このユースケースの重要性が増していることから、本日より、AWS Organizations のプレビューを終了して一般提供を開始します。AWS Organizations では複数の AWS アカウントを一元管理できます。組織単位 (OU) の階層構造を作成して各アカウントを OU に割り当て、さらにポリシーを定義して階層構造の全体、特定の OU、または特定のアカウントに適用できます。また、既存の AWS アカウントを招待して組織に追加できます。新規アカウントを作成することもできます。以上のすべての機能は、AWS Management ConsoleAWS Command Line Interface (CLI)、および AWS Organizations API から利用できます。AWS Organizations の理解に役立つ重要な用語と概念をいくつか紹介します (ユーザーが組織の AWS アカウント全体に対して全権を持ち、マスターアカウントを担当する管理者であることを前提とします)。

組織は、管理対象の AWS アカウントの統合セットです。新しい組織を作成して、サービスコントロールポリシーなどの高度なアカウントレベルのコントロールを実装できます。組織の管理者は、アカウント別に許可および拒否する AWS API 関数やリソースのリストを管理できます。たとえば、先端 R&D チームには広範な AWS のサービスへのアクセス権を与え、メインストリームの開発およびテストアカウントにはアクセス権を一部制限できます。または、実稼働環境では、HIPAA の準拠に該当する AWS のサービスに限ってアクセスを許可できます。AWS の既存のお客様は、一括請求 (コンソリデーティッドビリング) と呼ばれる AWS の機能を利用している場合があります。この機能で支払いアカウントを選択すると、複数の AWS アカウントのアカウントアクティビティを 1 つの請求書にまとめてコストを一元管理できます。今回のリリースで、現在一括請求をご利用のお客様は、AWS Organizations を通じて一括請求のすべての機能を利用できます。ただし、本日から提供開始される新しい機能 (サービスコントロールポリシーなど) はデフォルトでは利用可能になりません。この場合、AWS Organizations のすべての機能は簡単に有効にすることができます。まず、組織のマスターアカウントから AWS Organizations のすべての機能を使用可能にして、次に、この変更を各メンバーアカウントに認証してもらいます。最後に、当社では一括請求機能のみをサポートする組織の新規作成を今後もサポートします。今後も一元化された請求機能のみを使用できます。その場合は、マスターアカウントの管理者が組織のメンバーアカウントに詳細なポリシーコントロールを適用することを許可しません。AWS アカウントは、AWS リソースのコンテナです。マスターアカウントは、組織の管理ハブであり、組織のすべての AWS アカウントの支払いアカウントでもあります。また、マスターアカウントは、既存のアカウントを招待して組織に追加できます。新規アカウントを作成することもできます。メンバーアカウントは、組織のマスターアカウント以外のアカウントです。組織単位 (OU) は、AWS アカウントのセットのコンテナです。OU は、最大 5 階層で構成される階層構造内に配置できます。OU の階層構造の最上位は、管理ルートとも呼ばれます。サービスコントロールポリシー (SCP) は、組織のマスターアカウントが組織、選択された OU、または選択されたアカウントに適用できるコントロールのセットです。OU に適用すると、SCP は当該の OU と階層構造でそれより下位にある他のすべての OU に適用されます。メンバーアカウントの有効な SCP では、そのアカウントのルートユーザーに付与するアクセス許可を指定します。アカウント内では、IAM ユーザーおよびロールを通常どおりに使用できます。ただし、ユーザーやロールのアクセス許可の内容にかかわらず、有効なアクセス許可のセットが SCP で定義されている範囲を超えて適用されることはありません。これを利用して、アカウントレベルで AWS のサービスや API 関数へのアクセスを細かくコントロールできます。招待は、AWS に対して組織への参加をリクエストする際に使用します。招待の承諾期限は 15 日間ですが、メールアドレスまたはアカウント ID を使用して延長できます。未承諾の招待は同時に最大 20 件まで保持できます。招待ベースのモデルでは、マスターアカウントから既存のアカウントを招待できます。招待が承諾されると、アカウントが組織に追加され、すべての該当するポリシーが有効になります。組織に追加されたアカウントは、適切な OU に移動できます。AWS Organizations は、管理対象の AWS アカウント間に強力な隔離障壁を設ける場合に有効です。ただし、AWS リソース (EC2 インスタンス、S3 バケットなど) は特定の AWS アカウント内にあり、アカウント間では移動できないことに注意してください。さまざまなクロスアカウントの AWS 機能にはアクセスできます。たとえば、VPC ピア接続AMI の共有EBS スナップショットの共有RDS スナップショットの共有クロスアカウントの E メール送信IAM ロールによるアクセス委任クロスアカウントの S3 バケットのアクセス許可AWS マネジメントコンソールでのクロスアカウントアクセスなどの機能は利用できます。一括請求と同じように、EC2 および RDS リザーブドインスタンスの使用についても、AWS Organizations にはいくつかの利点があります。請求目的においては、組織のすべてのアカウントが 1 つのアカウントであるかのように扱われ、同じ組織の他の任意のアカウントで購入された RI の時間単位のコストメリットを受けることができます (このメリットが想定どおりに適用されるためには、RI のアベイラビリティーゾーンおよび他の属性が EC2 または RDS インスタンスの属性と一致する必要があります)。組織の作成 コンソールから組織を作成し、複数の組織単位を作成して、さらに複数のアカウントを作成してみましょう。まず、[Create organization] をクリックします。

次に [ENABLE ALL FEATURES] を選択して、[Create organization] をクリックします。

組織が数秒で作成されます。

新しいアカウントを作成するには、[Add account] をクリックして、[Create account] を選択します。

次に、詳細を指定します (IAM ロールを新しいアカウントで作成し、作成した IAM ロールからアカウントのカスタマイズに必要なアクセス許可を付与します)。

Dev アカウント、Test アカウント、Prod アカウントの作成後のコンソールは以下のようになります。

この時点では、すべてのアカウントが階層構造の最上位にあります。

下位構造を追加するには、[Organize accounts] をクリックして、[Create organizational unit (OU)] を選択し、名前を入力します。

2 つ目の OU にも同じ操作を行います。

次に Prod アカウントを選択し、[Move accounts] をクリックして、Operations OU を選択します。

次に、Dev アカウントと Test アカウントを Development OU 内に移動します。

この時点で 4 つのアカウント (最初の 1 つおよび先ほど作成した 3 つ) と 2 つの OU があります。次のステップとして、サービスコントロールポリシーを作成します。[Policies] をクリックして [Create policy] を選択します。ここで Policy Generator を使うか、既存の SCP をコピーしてカスタマイズするかを選択できます。Policy Generator を使うことにします。ポリシーに名前を付けて、Allow ポリシーとして指定します。

次に、Policy Generator を使用して EC2 と S3 への完全なアクセスと Lambda 関数を実行する (呼び出す) ことを許可するポリシーを構築します。

このポリシーでは、アカウント内の実行可能なアクションのフルセットを定義するだけであることに注意してください。これらのアクションをアカウント内の IAM ユーザーが使用することを許可するには、さらに適切な IAM ポリシーを作成してユーザーにアタッチする必要があります (すべてに操作はメンバーアカウント内で行います)。[Create policy] をクリックしてポリシーを作成します。

次に開発およびテスト用として 2 つ目のポリシーを作成します。このポリシーでも、AWS CodeCommitAWS CodeBuildAWS CodeDeploy、および AWS CodePipeline へのアクセスを許可します。

ここまでで、アカウントを作成して OU 内に配置しました。さらに OU のためのポリシーを作成しました。次にポリシーを使用可能にし、ポリシーを OU にアタッチする必要があります。ポリシーを使用可能にするには、[Organize accounts] をクリックして [Home] を選択します (ホームはルートと同じではありません。Organizations は複数の独立した階層構造をサポートするように設計されています)。さらに Root OU のチェックボックスをオンにします。次に、右側の [Details] セクションを展開し、[Enable] をクリックします。

これで、すべての要素が揃いました。Root OU をクリックして階層構造内に移動し、Operations OU のチェックボックスをオンにします。次に、右側の [Details] セクションを展開し、[Attach policy] をクリックします。

次に [OperationsPolicy] を見つけて [Attach] をクリックします。

最後に、[FullAWSAccess] ポリシーを削除します。

また、Development OU に DevTestPolicy をアタッチできます。上で説明したすべてのオペレーションを行うには、AWS Command Line Interface (CLI) を使用するか、以下の関数を呼び出すこともできます。 CreateOrganizationCreateAccountCreateOrganizationalUnitMoveAccountCreatePolicyAttachPolicy、および InviteAccountToOrganization。CLI を使用する方法については、「AWS Organizations を発表: 複数の AWS アカウントの一元管理」を参照してください。

AWS Organizations を使用するためのベストプラクティス
最後に、AWS Organizations を使用するためのベストプラクティスを紹介します。マスターアカウント – マスターアカウントには、オペレーション用の AWS リソースを (1 つを例外として) 関連付けないことをお勧めします。これにより、適切なコントロールを判断しやすくなり、AWS の請求内容を理解しやすくなります。CloudTrail – メンバーアカウントでのすべての AWS 使用状況を一元的に追跡するには、マスターアカウントで AWS CloudTrail (これが例外) を使用します。最少の特権 – OU のポリシーを設定する場合は、割り当てる特権をできるだけ少なくします。組織単位 – ポリシーはアカウントにではなく OU に対して割り当てます。これにより、組織構造および必要な AWS アクセスレベルがより適切にマッピングされます。テスト – スケールアップする前に 1 つのアカウントで新規ポリシーと変更されたポリシーをテストします。自動化 – API と AWS CloudFormation テンプレートを使用して、すべての新規作成されたアカウントが適切に設定されていることを確認します。テンプレートで IAM のユーザー、ロール、およびポリシーを作成できます。ログ記録の設定、VPC の作成と設定などを行うこともできます。

詳細
以下は、AWS Organizations の使用を開始するために役立つリソースです。

 

主要事項
AWS Organizations は、China (Beijing)AWS GovCloud (US) を除くすべての AWS リージョンで本日から無料で公開されます (より正確には、サービスエンドポイントが US East (Northern Virginia) にあり、SCP はすべての該当リージョンで適用されます)。すべてのアカウントの販売者は同一でなければならず、同じ組織内で AWS と AISPL (インドで AWS のサービスアカウントのリセラーとなっている現地インド法人) を合わせて使うことはできません。AWS Organizations は今後大きく拡張される予定であり、複数の支払いアカウント、リザーブドインスタンス割引の割り当てのコントロール、複数の階層構造、その他のコントロールポリシーなどに対するサポートの追加が現在検討されています。今回も、皆さまからのご意見やご提案をお待ちしております。

Jeff;

週刊 AWS – 2017 年 2 月 20 日

お客様からのご要望にお応えして、この「マイクロ」版の週刊 AWS を作成しています。当社からのすべてのお知らせ、当社のすべてのブログのコンテンツ、およびコミュニティで作成された AWS コンテンツをできるだけ多く含めました。今後、ツールや自動化の準備が整い次第、他のセクションもご紹介していきたいと思っています。

月曜日

2 月 20 日

火曜日

2 月 21 日

水曜日

2 月 22 日

木曜日

2 月 23 日

金曜日

2 月 24 日

土曜日

2 月 25 日

Jeff;

Now Available – Lumberyard Beta 1.8, Cloud Gems Frameworkの紹介

beaver-air-2-1-300x188 Lumberyard Beta 1.8のリリースを発表します。ここからダウンロードすることができます。このリリースには234以上の新機能、修正、機能が含まれており、1人のエンジニアでわずか30分で一般的なクラウド接続機能を構築するための新しいフレームワークのCloud Gems Frameworkが導入されています。

AWSのように、SupercellZyngaのようなモバイルとソーシャルの初期のパイオニアから、Cloud ImperiumやLeslie BenziesのEverywhereのような銀河系の野望を持つPCやコンソール開発者まで、業界で最も優れたゲームスタジオの多くと協力できて幸運です。開発者は、イノベーションと成長のためにクラウドを活用し、以前は不可能だった規模でプレーヤー同士を結びつけ、新しい形の競争とゲームプレイを可能にし、ゲームについてのプレーヤーが好き、好きではない等よりディープにリアルタイムに情報を得ることができるようになりました。

お客様から、クラウドの膨大なコンピュートとストレージが今日の成功したゲームにとって重要であると同時に、クラウドは次世代ゲームの創造性とスケールにとってさらに重要なものになると教わりました。グローバルオーディエンスを結びつけるための開発者の需要、マスコンピューティングによる創造性の推進、より多くの社会的マルチプレイヤー機能の構築は”AWSと深く統合され”Lumberyardの基盤となりました。

我々は2つの方法で”深く統合”されたものを定義します。 1つは、マルチプレイヤー、ソーシャル機能、ダイナミックでライブで行えるコンテンツアップデートなど、共通の接続要素をゲームにできるだけ簡単に作成することです。熟練したバックエンドエンジニアを雇わず、未分化のインフラストラクチャを構築するために何ヶ月も何年も費やさずに、偉大なゲームプレヤーにフォーカスすることを望みます。次に、大規模なオンデマンドやグローバルなコンピュートとストレージによって可能になる、素晴らしい新しいタイプのゲームプレイとリアルタイムインタラクションを作成することをお手伝いします。ここでは、手続き型のゲームプレイ、複雑な人工知能、巨大かつ信憑性の高いゲームを考えているゲームチームからインスピレーションを得ています。

Lumberyard Beta 1.8の新しいCloud Gems Frameworkを使用すると、動的コンテンツ、リーダーボード、ライブメッセージなどのコネクティッドなゲーム要素を簡単に作成して起動できます。 Cloud Gems Frameworkを使用すると、1人のエンジニアが30分以内にゲームにコネクティッドな機能を追加することができ、残りのチームエンジニアがイノベーションとプレイヤー体験について考えるようになります。

Cloud Gems Frameworkは、チームの誰もがクラウドの機能を視覚的に管理できるWebアプリケーション(メッセージのスケジュール設定、動的コンテンツのリリース、または不正なリーダーボードスコアの削除など)であるCloud Gem Portalと開発者がバックエンドやクライアントの機能を含め、その機能をプロジェクトに組み込むために必要なすべてを含む個別機能と資産のモジュールパッケージであるCloud Gemsで構成されています。Cloud Gemは、本番環境ですぐに使用でき、様々な方法で動作をカスタマイズしたい場合に備えて完全なソースコードが付属しています。

cloud-gem-portal-1024x504

Lumberyard Beta 1.8には、3つのサンプルのCloud Gemsが含まれており、すぐに始めることができます。

Dynamic Content Cloud Gem
今日の成功したゲームの多くはサービス中で常に”常時オン”になっています。チームはできるだけ開発チームに苦労することなく、頻繁にコンテンツを追加したり変更したりすることで、プレイヤーの関与を深めたいと考えています。ダイナミックコンテンツバックエンドを使用すると、プレイヤーが更新された実行ファイルをダウンロードしてインストールする必要なく、チームはプレーヤーのフィードバックに迅速に応答したり、特殊文字やA / Bテストゲームプレイ機能を提供したり、新しいキャラクタやレベルをゲームに追加してゲームの寿命をのばすことができます。

ダイナミックコンテンツシステムを自分で構築するには、コンテンツをホストするサーバーを立ち上げ、利用可能な動的コンテンツを指定するスキームを作成し、コンテンツのバージョン管理を行い、サーバーにコンテンツをアップロードするツールを作成し、サーバーに照会してコンテンツがいつ変更されたかを確認するエンジンを書き、堅牢なダウンロードおよび検証システムを構築し、最終的にはゲームを動かすインスタンスにホットロードするコードを記述すします。この作業には2〜3人のエンジニアが数ヶ月かかることがあります。このシステムが失敗すると、プレーヤーはあなたのチームが作成した内容を決して見ることができません。

Dynamic Content Cloud Gemを使用すると、わずか7ステップでコンテンツをパッケージ化、アップロード、および配信することができます。

  1. Lumberyard Project ConfiguratorでDynamic Content Gem を有効にする
  2. Cloud Canvas Resource Managerから[Upload Resources]をクリックします。
  3. エディタのAWSメニューからDynamic Content Managerを開きます
  4. 動的コンテンツをリストするマニフェストを作成する
  5. 動的コンテンツマネージャから「New Package」をクリックします。
  6. アップロードするアセットをドラッグ&ドロップする
  7. 動的コンテンツマネージャから[Upload Packages]をクリックします。これにより、コンテンツがクラウドに置かれ、プライベートとしてマークされます。

コンテンツをクラウドにアップロードしたら、 Cloud Gem Portalを使用してコンテンツを即座にリリースするか、後でリリースするようにコンテンツをスケジュールすることができます。新しいコンテンツがプレーヤーによってダウンロードされると、ダイナミックコンテンツジェムは自動的に新しいコンテンツをロードし、ゲーム内で利用可能にできます。

Leaderboards Cloud Gem
競争はプレーヤーコミュニティを育成する素晴らしい方法です –  1月に、Twitchで見られたトップ10のゲームのうち8つが競い合うマルチプレイヤーゲームでした。ゲームにリーダーボードを追加することは、コミュニティの競争を促進するための一般的な方法です。従来、リーダーボードを設定するには、高得点データを格納し、スコアを収集するためにRESTエンドポイントを作成し、配備し、Webベースのコンソールまたは他のアプリケーションを管理して管理するために、スケーラブルな方法でデータベースサーバーを準備する必要があり、クライアント側の開発者に、RESTエンドポイントにプレーヤーのスコアを送信するための適切なネットワークコールを行う方法を教得る必要がありました。Leaderboard Cloud Gemを使用すると、これは約30分でエンジニアが達成できる4つのステップに単純化されています

  1. Project ConfiguratorでLeaderboard Cloud Gemを有効にする。
  2. Cloud Canvas Resource Managerから[Upload Resources]をクリックします。
  3. Cloud Gem Portalでは、選手の順位を決定する統計に基づいて、必要な数のリーダーボードを作成します。
  4. スクリプトやC ++からLeaderboardコンポーネントへの簡単な呼び出しを使用して、適切な間隔でプレーヤーのスコアやその他のデータをクラウドに送信します。

Cloud Gem Portalは、リーダーボード上のプレーヤーを管理するためのコンソールも提供し、管理者は不正なスコアを削除し、システムを悪用するプレーヤーを禁止することができます。

Message of the Day Cloud Gem
エンゲージメントを促進するもう一つの方法は、特別なオファーや新しいコンテンツの更新を通知するか、必要に応じて他のタイムリーなコミュニケーションを送るかどうかにかかわらず、あなたのプレーヤーにメッセージを送信することです。従来は、スケーラブルなデータベース・サーバーのセットを準備および構成し、メッセージ・コンテンツの入力、変更、削除およびスケジューリングを管理するWebベースのアプリケーションを作成し、メッセージ・コンテンツを提供するRESTエンドポイントを作成し、メッセージを要求して表示するためのクライアントサイドのゲーム・コードを作成する必要がありました。Day Cloud Gem のメッセージを使って、4ステップで約30分でこれらを実行することができます:

  1. Project ConfiguratorでDay Cloud Gemのメッセージを有効にします。
  2. Cloud Canvas Resource Managerから[Upload Resources]をクリックします。
  3. Cloud Gem Portalで、必要な数のメッセージを作成してスケジュールします。
  4. スクリプトまたはC ++からの単純な呼び出しを使用して、メッセージの Day componentからのアクティブなメッセージのリストを照会します。

より多くのCloud Gemが開発されているので、次に見たい特定のクラウド機能があれば、フォーラムでお知らせください。また、来週GDCに来る場合は、LumberyardブースでCloud Canvasチームに会い、Cloud Gemsのデモを体験したり、GDCのdevdayにサインして、ゼロからクラウドにリアルタイムで接続されルノを見ることができます。また、AWSクラウドが新しいタイプのゲームプレイやリアルタイムの通信を可能にする方法について、将来のビジョンにもいくつかの垣間見ることができます。

Lumberyard Beta 1.8にはさらに多くのものが含まれています。 Lumberyard Editorのメニューの合理化された情報アーキテクチャ、FBXインポーターのルートモーションアニメーションのサポート、マルチプレイヤーサンプルのモバイルとコンソールのサポート、メッシュのマルチUVサポート、UIエディタの言語サポートなどがあります。このリリースの新機能の詳細については、リリースノートを参照してください。

Amazon Lumberyardを使い始めるには、Lumberyardのウェブサイトでエンジンをダウンロードしてください。 Lumberyardの新機能について詳しくは、チュートリアルフォーラムドキュメントを参照してください。

(翻訳はSA 森が担当しました。原文はこちら)

最新リリース: AWS Elastic Beanstalk でカスタムプラットフォームのサポート開始

うれしいお知らせです。AWS Elastic Beanstalk でカスタムプラットフォームを作成できるようになりました。この最新リリースの AWS Elastic Beanstalk により、開発者やシステム管理者は、AWS Elastic Beanstalk のカスタムプラットフォームイメージを独自に作成して管理し、インスタンス設定を完全にコントロールできます。ご存じのように、AWS Elastic Beanstalk は、一般的なウェブプラットフォームでウェブアプリケーションやサービスをデプロイ、スケーリングするためのサービスです。このサービスでは、ユーザーがコードをアップロードするだけで、デプロイメント、容量のプロビジョニング、負荷分散、Auto Scaling が自動的に処理されます。

これまでの AWS Elastic Beanstalk で提供していたのは、事前設定済みのプラットフォームのセットです。さまざまなプログラミング言語、Docker コンテナ、上述した用途別のウェブコンテナの設定が複数用意されていました。Elastic Beanstalk では、選択された設定に従って、1 つ以上の Amazon EC2 インスタンスで対象のアプリケーションを実行するためのソフトウェアスタックやリソースをプロビジョニングしていました。この最新リリースでは、独自のカスタマイズした Amazon Machine Image (AMI) からプラットフォームを作成できます。カスタムイメージは、サポートされているオペレーティングシステム (Ubuntu、RHEL、Amazon Linux) のいずれかで構築できます。これらの特化された Elastic Beanstalk プラットフォームの作成作業は、マシンイメージ作成ツールの Packer で簡素化できます。Packer は、すべての主要オペレーティングシステムで実行するオープンソースツールであり、1 つの設定から複数のプラットフォームのマシンイメージやコンテナイメージを作成できます。カスタムプラットフォームでは、Elastic Beanstalk 環境全体にわたり、標準化とベストプラクティスを適用して管理できます。たとえば、Ubuntu や Red Hat Enterprise で独自のプラットフォームを作成し、Elastic Beanstalk で現在サポートされていない言語やフレームワーク (Rust、Sinatra など) を使用してインスタンスをカスタマイズできます。

カスタムプラットフォームの作成
カスタムプラットフォームを作成するには、最初に Packer テンプレートを作成します。Packer テンプレートを作成したら、プラットフォーム定義ファイルの platform.yaml ファイル、プラットフォームのビルダータイプを定義するプラットフォームフック、およびスクリプトファイルを作成します。これらのファイルが準備できたら、プラットフォーム定義アーカイブと呼ばれる zip アーカイブファイルを作成して、これらのファイル、関連するスクリプト、その他 Amazon Machine Image (AMI) の構築に必要な追加のアイテムをパッケージ化します。プラットフォーム定義アーカイブを構築するための基本的なフォルダ構造は以下のとおりです。

|– ビルダー カスタムプラットフォームを作成するために Packer で使用するファイルを収容
|– custom_platform.json Packer テンプレート
|– platform.yaml プラットフォーム定義ファイル
|– ReadMe.txt サンプルの説明

Elastic Beanstalk の新しいカスタムプラットフォーム機能を詳しく知るには、実際に試してみるのが最善です。Packer を使用してカスタム AMI とプラットフォームを構築してみましょう。まず、カスタム Packer テンプレートを構築します。Packer サイトにアクセスし、Packer ツールをダウンロードして、このバイナリが環境パスに追加されたことを確認します。

次にテンプレートを構築しましょう。Packer テンプレートは、構築するイメージを定義するための JSON 形式の設定ファイルです。Visual Studio を開いて、これを IDE として使用し、Packer テンプレートを構築するための新しい JSON ファイルを作成します。

Packer テンプレート形式には、イメージのさまざまなコンポーネント用に設計されたキーのセットがあります。以下のキーが提供されています。

  • variables (オプション): ユーザー変数を定義する 1 つ以上のキーと値の文字列
  • builders (必須): マシンイメージおよび各イメージの設定を作成するためのビルダーを定義する配列
  • provisioners (オプション): マシンイメージのソフトウェアをインストールおよび設定するための provisioner を定義する配列
  • description (オプション): テンプレートの説明としての文字列
  • min_packer_version (オプション): テンプレートの解析に必要な最小の Packer バージョンを示す文字列
  • post-processors (オプション): イメージの構築の完了後に行う後処理ステップを定義する配列

カスタム Elastic Beanstalk プラットフォーム用のカスタムイメージを作成する際に利用できるサンプルの Packer テンプレートについては、Elastic Beanstalk ドキュメントで有効な Packer テンプレートのサンプルを参照してください。テンプレートで、スクリプトの場所とスクリプトの実行に必要なコマンドの情報を指定し、ビルドスクリプトを実行するための provisioner を追加して Node をインストールします。完成した JSON ファイル、tara-ebcustom-platform.json は、以下のとおりです。

次に、構築した Packer テンプレートをコマンドラインで検証します。

幸いなことに、この Packer テンプレートはエラーになります。テンプレートに指定したスクリプト、eb_builder.sh がビルダーフォルダにあるとしたことが原因です。しかし、ビルダーフォルダは作成していません。また、シェルスクリプトを Packer テンプレートに指定してもいません。ファイルがエラーになって幸いだとは不信に思われるかもしれません。これが幸いだという理由は、Elastic Beanstalk サービスにテンプレートをアップロードする前に、テンプレート内のエラーやマシンイメージの構築に必要なファイルの不足を検出できるからです。ビルダースクリプトのフォルダとファイルを作成して、これらのエラーを修正することにします。Elastic Beanstalk ドキュメントに提供されているサンプルスクリプトを使用して、上記構造の Dev フォルダを作成します。カスタム Elastic Beanstalk プラットフォームの作成に関する限り、このサンプルスクリプトはプラットフォームフックと呼ばれます。プラットフォームフックは、ライフサイクルイベント中、および管理オペレーションに応じて実行されます。このカスタムプラットフォームの実装で使用したビルダースクリプトのサンプルを以下に示します。

このビルダーフォルダ構造には、カスタムプラットフォームを構築するためのビルダースクリプト、プラットフォームフック、その他の (プラットフォームスクリプトと呼ばれる) スクリプトが入っています。プラットフォームスクリプトは、環境変数や他のプラットフォームフック内の情報を取得するために使用できるシェルスクリプトです。プラットフォームフックは、ビルダーフォルダのサブフォルダ内にあり、その構造は以下のとおりです。

以上の Packer テンプレート、platform.yaml、ビルダースクリプト、プラットフォームフック、setup ファイル、config ファイル、プラットフォームスクリプトのすべてが、以下に示すビルダーフォルダ内のプラットフォーム定義を構成します。

サンプルの .yaml ファイルに提供されている platform.yaml を利用し、これを適切に変更してカスタム Elastic Beanstalk プラットフォームの実装に使用します。その結果として完成した platform.yaml ファイルは以下のとおりです。

version: "1.0"

provisioner:
  type: packer
  template: tara-ebcustom-platform.json
  flavor: amazon

metadata:
  maintainer: TaraW
  description: Tara Sample NodeJs Container.
  operating_system_name: Amazon linux
  operating_system_version: 2016.09.1
  programming_language_name: ECMAScript
  programming_language_version: ECMA-262
  framework_name: NodeJs
  framework_version: 4.4.4
  app_server_name: "none"
  app_server_version: "none"

option_definitions:
  - namespace: "aws:elasticbeanstalk:container:custom:application"
    option_name: "NPM_START"
    description: "Default application startup command"
    default_value: "node application.js"

この Packer テンプレートを再度コマンドラインで検証します。

後は EB CLI を使用してプラットフォームを作成するだけです。この機能は、EB CLI バージョン 3.10.0 以降で利用できます。EB CLI は、こちらからインストールできます。Elastic Beanstalk 開発者ガイドの指示に従ってください。EB CLI を使用してカスタムプラットフォームを作成するには、プラットフォーム定義アーカイブから抽出したファイルが含まれているフォルダを選択します。このフォルダについては、以下のステップを実行する必要があります。

  1. EB CLI を使用してプラットフォームリポジトリを初期化し、プロンプトに従う
    • eb platform init または ebp init
  2. テンプレートおよびスクリプトを使用して Packer 環境を起動する
    • eb platform create または ebp create
  3. IAM ロールがインスタンスに対して正常に作成されたことを検証する。このインスタンスプロファイルロールは、EB create プロセスを通じて自動的に作成されます。
    • aws-elasticbeanstalk-custom-platform-ec2-role
  4. プラットフォームの作成ステータスを検証する
    • eb platform status または ebp status

次にコマンドラインに移動し、eb platform init コマンドを実行して EB CLI コマンドでプラットフォームを初期化します。

次のステップとして、EB CLI を使用してカスタムプラットフォームを作成します。そのために、プラットフォームフォルダの短縮コマンド、ebp create を実行します。

成功! カスタム Elastic Beanstalk プラットフォームが作成されました。このプラットフォームをウェブソリューションとしてデプロイできます。カスタムプラットフォームを作成する際に重要な点は、Packer を実行する EIP を使用せずに、単一のインスタンス環境を起動することです。この環境は、必要に応じて複数のプラットフォームおよび各プラットフォームの複数のバージョンに再利用できます。さらに、カスタムプラットフォームはリージョン固有です。Elastic Beanstalk を複数のリージョンで使用する場合は、リージョンごとに別個のプラットフォームを作成する必要があります。

カスタムプラットフォームのデプロイ
カスタムプラットフォームを作成したら、AWS CLI または AWS Elastic Beanstalk コンソール経由でアプリケーションをデプロイできます。作成済みのカスタムプラットフォームを使用して環境を作成することは、Create New Environment ウィザードでのみ可能です。[Create a new environment] ウェブページで、[Platform] の [Custom Platform] ラジオボタンをオンにすると、作成済みのカスタムプラットフォームを選択できます。表示されるカスタムプラットフォームのリストから、前に作成したカスタムプラットフォームを選択します。

EB CLI で最新バージョンのカスタムプラットフォームをデプロイすることもできます。作成済みのカスタムプラットフォームをデプロイするためのコマンドラインは、以下のようになります。

  • eb deploy -p tara-ebcustom-platform

 

まとめ
Elastic Beanstalk のカスタムプラットフォームの構築は今すぐ開始できます。Elastic Beanstalk またはカスタムプラットフォームの詳細については、AWS Elastic Beanstalk 製品ページまたは Elastic Beanstalk 開発者ガイドを参照してください。

Tara

新サービス – 要求が厳しく入出力量が多いアプリケーション向けの I3 インスタンス

AWS re:Invent の初日に、私は EC2 インスタンスの更新に関する投稿で、入手次第、皆様に追加情報をお知らせすることを約束しました。本日は、15 か所の AWS リージョンで 6 つのサイズの新しい I3 インスタンスの提供を開始したことをお知らせします。このインスタンスは入出力量が多いワークロード用に設計されており、きわめて効率が高い NVMe SSD ストレージを備えています。4 KB ブロックで最大 330 万の IOPS を配信し、最大 16 GB/秒のシーケンシャルディスクスループットを実現します。このため、リレーショナルデータベース、NoSQL データベース、検索エンジン、データウェアハウス、リアルタイム分析、ディスクベースのキャッシュなど、高スループットと低レイテンシーを必要とするあらゆるワークロードに最適です。I3 インスタンスは、I2 インスタンスと比較すると、低コストで高密度のストレージを提供し、CPU コアあたりの IOPS とネットワーク帯域幅も大幅に増えます。

仕様
インスタンスサイズと関連仕様は次のとおりです。

インスタンス名 vCPU カウント
メモリ インスタンスストレージ (NVMe SSD) 料金/時間
i3.large 2 15.25 GiB 0.475 TB 0.15 USD
i3.xlarge 4 30.5 GiB 0.950 TB 0.31 USD
i3.2xlarge 8 61 GiB 1.9 TB 0.62 USD
i3.4xlarge 16 122 GiB 3.8 TB (2 ディスク) 1.25 USD
i3.8xlarge 32 244 GiB 7.6 TB (4 ディスク) 2.50 USD
i3.16xlarge 64 488 GiB 15.2 TB (8 ディスク) 4.99 USD

上記の料金は US East (Northern Virginia) リージョンでのオンデマンドインスタンスの場合です。詳細については、EC2 料金表ページを参照してください。I3 インスタンスは、US East (Northern Virginia)US West (Oregon)US West (Northern California)US East (Ohio)Canada (Central)South America (Brazil)Europe (Ireland)Europe (London)Europe (Frankfurt)Asia Pacific (Singapore)Asia Pacific (Tokyo)Asia Pacific (Seoul)Asia Pacific (Mumbai)Asia Pacific (Sydney)、および AWS GovCloud (US) リージョンで、オンデマンド、リザーブド、およびスポット形式でご利用できます。また、これらを専有ホストおよびハードウェア専有インスタンスとして使用することもできます。これらのインスタンスはハードウェア仮想化 (HVM) AMI のみをサポートしており、仮想プライベートクラウド内で実行する必要があります。NVMe ストレージによって可能になったパフォーマンスの利点を得るには、次のいずれかのオペレーティングシステムを実行する必要があります。

  • Amazon Linux AMI
  • RHEL – 6.5 以降
  • CentOS – 7.0 以降
  • Ubuntu – 16.04 または 16.10
  • SUSE 12
  • SP3 を使用する SUSE 11
  • Windows Server 2008 R2、2012 R2、および 2016

I3 インスタンスでは最大 8 個の NVMe SSD が提供されます。最善のスループットを実現し、可能な限り多くの IOPS を取得するには、複数のボリュームを一緒にストライプ化するか、別の方法で I/O ワークロードをボリューム間で分散します。各 vCPU (仮想 CPU) は、2.3 GHz で実行する Intel E5-2686 v4 (Broadwell) プロセッサ上のハードウェアハイパースレッドです。このプロセッサは、Turbo Boost と NUMA とともに、AVX2 手順をサポートします。

提供開始
I3 インスタンスは 15 か所の AWS リージョンで利用可能になり、今すぐ使用を開始できます。

Jeff;