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;

SPICEデータのスケジュールリフレッシュがAmazon QuickSightに追加されました

Amazon QuickSightにSPICEデータのスケジュールリフレッシュ機能が追加されました。以下はAWS Bigdata Blogに掲載されたブログの翻訳です。


Jose KunnackalはAmazon QuickSightのシニアプロダクトマネージャ

2016年11月に私達はAmazon QuickSightローンチしました。これはクラウドのパワーで稼働し、お客様のデータをクイックかつ簡単に分析するビジネスアナリティクスのサービスです。QuickSightはSPICE (Super-fast, Parallel, In-Memory Calculation Engine)というフルマネージドのデータストアを持っており、これにAWSやオンプレミス、クラウドサービスのデータを格納することで超高速なビジュアライゼーションを可能にします。SPICEに格納したデータはQuickSight上にあるボタンをクリックするだけでいつでもリフレッシュ(新しいデータの取り込み)を行うことが可能です。

本日、リフレッシュのスケジュール実行機能をローンチいたします!

SPICEデータセットをスケジュールリフレッシュする

schedule refresh
SPICEデータセットを選択し、スケジュールリフレッシュを指定します。その後、タイムゾーン、リフレッシュ頻度、およびスケジュールの開始日時を指定します。

スケジュールを適切に設定することで、SPIPCEのデータセットや分析、ダッシュボードを元のデータソースに同期させることが可能になります。

スケジュールリフレッシュはサポートされるすべてのデータソース、つまりAWS、クラウドサービス、およびオンプレミスにあるデータに対して有効であり、全サポートリージョンのすでに作成済のデータセットについても利用可能です。手動でのリフレッシュと同様に、データセットのリフレッシュ状況のサマリを確認することが可能です。

データのスケジュールリフレッシュによって高いパフォーマンスを発揮するインタラクティブなダッシュボードをQuickSightとSPICEでシンプルに実現可能です。データリフレッシュのために所定の時間にQuickSightにログインする必要もありませんし(もしくはうっかり忘れることもなくなります)、QuickSightを活用して高速でインタラクティブなビジュアライゼーションを多くのユーザに提供することにフォーカスできます。

QuickSightのパワーをぜひ今日から体験してみてください – 無料枠がありますのでぜひサインアップを!もしご質問などがありましたら、コメントを残してください。
(訳注:QuickSightには全機能を60日間試せるFree Trialがあります。また、機能は制限されますが無料でずっと利用できるFree Tierも用意されています。詳しくはこちらをご確認ください。)


原文:https://aws.amazon.com/jp/blogs/big-data/scheduled-refresh-for-spice-data-sets-on-amazon-quicksight/

翻訳:下佐粉 昭 (@simosako)

 

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

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー3月の配信についてご案内させて頂きます。今月は2月にリリースされたばかりの「Amazon Chime」をはじめとして、初登場となるサービスが多数あります!

201703_BB

3月の開催予定

サービスカット
3/1(水) 18:00-19:00 Amazon Athena
3/8(水) 18:00-19:00 Amazon Chime
3/15(水) 18:00-19:00 Auto Scaling
3/22(水) 18:00-19:00 Developer Tools (CodeX シリーズ)
3/29(水) 18:00-19:00 Amazon AI

ソリューションカット
3/14(火) 12:00-13:00 Well-Architected Framework
3/28(火) 12:00-13:00 動画配信 on AWS

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

Amazon EBSのアップデート – 新機能エラスティックボリュームが全てを変える

お客様からビジネスのダイナミックさと、それを実現するためのアプリケーションがブロックストレージに求めるものについてご意見をうかがうことは、いつも興味深いものです。ビジネス状況の変化に伴ってブロックストレージへの要求も変化し、容量を追加したり、性能特性の異なるボリュームが必要になったりすることもあるはずです。今日では、24時間運用され続けるシステムも珍しくはありません。結果として、ダウンタイムやシステム運用への影響なく変更作業を行えることがお客様にとって重要な要素となってきます。

我々は長年にわたり、お客様の様々なユースケースをカバーするために、EBSに新機能を追加し続けてきました。例えば、2016年にはスループット最適化HDD(st1)とコールドHDD(sc1)という2種類のボリュームタイプをリリースしました。これらのボリュームをシステム運用への影響なく、パフォーマンス特性の変更やコスト削減を行うことで、階層化ストレージのように利用したいと考えるお客様がいらっしゃいます。言い換えると、お客様はEBSがより柔軟になることを望んでいるのです!

エラスティックボリューム
本日、EBSの新機能としてエラスティックボリュームをリリースいたしました。これは現行世代のEC2インスタンスにアタッチされた、全ての現行世代のEBSボリュームで利用可能です。お客様はボリュームサイズの拡張、パフォーマンスの調整、ボリュームタイプの変更を利用中に行うことができます。変更処理はオンラインで行われますので、お客様のアプリケーションは引き続き利用可能でダウンタイムはありません。

この新機能はリソース計画やチューニング、空き容量の管理といった作業を劇的にシンプル化してくれます。あるいは作業自体が不必要になるかもしれません。従来のやり方はダウンタイムを伴うため、変更の完了までプランニングやシステム停止の調整を含めると数週間から数ヶ月にわたる時間が必要でした。しかしこれからは、利用しているストレージインフラストラクチャをシンプルなAPIコールで簡単に変更することが可能になります。

  • ワークロードの変化 – インフラ構築を急ぐ必要があり、汎用SSDボリュームを採用することにしました。システムをリリースし、運用を行っていくにつれて、スループット最適化HDDボリュームが最適であることに気づいたとしましょう。エラスティックボリュームの機能により、単純にボリュームタイプを変更するだけで対応が完了します。
  • 突発的な需要への対応 – プロビジョンドIOPSボリューム上に構築したリレーショナルデータベースで、1ヶ月のほとんどの期間にわたり問題なく処理を行えるシステムがあります。ただし月末処理の関係で各月終わりの3日間は10倍のトラフィックを処理する必要があったとします。この場合は、エラスティックボリュームを利用して月末の3日間だけIOPSを高く設定し、処理が終わったら元に戻すという運用が可能です。
  • ストレージの増加 – 100GBのボリュームで運用してきたシステムで、ディスク使用率が90%を超過したというアラームが発報しました。あらかじめ設定を行っておけば、ボリュームとファイルシステムの拡大を自動的にダウンタイム無しで行うこともできます。

エラスティックボリュームの利用

お客様はこれら全ての操作をAWSマネジメントコンソールやAPIコール、AWSコマンドラインインタフェース(CLI)で実行できます。これに加えて、AWS CloudFormationのスタック更新機能を利用することも可能で、対象のボリュームに必要な変更を行ってくれます。コンソールを利用する場合は、対象のボリュームを選択してアクションメニューから「Modify Volume」を選択するだけです:
ebs1

ポップアップするウィンドウの中で、ボリュームタイプやサイズ、IOPS値(プロビジョンドIOPSボリュームの場合)を変更してください。これは75GBの汎用SSDボリュームを、20,000IOPSで400GBのプロビジョンドIOPSボリュームに変更する例です:
ebs2

変更ボタンをクリックしたら、確認ウィンドウが表示されるので問題が無ければ「YES」をクリックします:
ebs3

ボリュームの「状態」に変更処理の進捗状況(modifying、optimizing、completed)が表示されます:
ebs4

次のステップは追加されたストレージ領域を利用できるようにするために、ファイルシステムを拡張することです。作業の詳細についてはLinuxでEBSボリュームのストレージ領域を拡張するWindowsでEBSボリュームのストレージ領域を拡張するを参照してください。ボリュームの状態が最適化中に変わったら(通常数秒で変わります)、ファイルシステムの拡張作業を行うことができます。新しいボリュームの容量やタイプはすぐに利用可能になりますが、最適化の処理は最大で24時間を要する場合があります。コストについて補足すると、ボリュームの状態がoptimizingになったタイミングで新構成を基準に計算されることになります(変更自体のコストはかかりません)。

エラスティックボリュームの自動オペレーション
手動オペレーションでの変更も充分に魅力的ですが、自動化を行うたくさんのチャンスがあります。いくつかのアイデアをお見せしてみましょう:

  • 正しいサイジング – IOPS上限か、それに近いレベルに到達しているかをCloudWatchで監視しアラームを上げるよう設定します。アラームが上がったらIOPS値の増加や、ボリュームタイプの変更を行うための承認プロセスを開始し、変更作業の準備を進めます。同様にCloudWatchのカスタムメトリクスを利用して空き容量をモニタリングして、拡張のための承認プロセスを開始することもできます。
  • コストの削減 – CloudWatchメトリクスや予め設定したスケジュールに従ってIOPSの削減やボリュームタイプの変更を行います。(背景:先週、大学のセキュリティ管理者と会話する機会がありました。彼は学内の全てのサーバから1日に10GBのログを収集し、60日間に渡って保持するという仕事をしています。ほとんどのファイルは参照されることはなく、参照が必要になったときでもアクセス速度はそれほど求められません。この場合、1日分のログを書き込むための汎用SSDボリュームを作成し高速な書き込みを実施し、完了したらスループット最適化HDDに変更することでコストを最適化することができます。)

先にお伝えしたように、新たに追加された領域を利用できるようにするためにはファイルシステムをリサイズする必要があります。この手順をお見せするために、私の同僚がCloudWatch Events、AWS Lambda、EC2 Systems Managerを利用したPythonとPowerShellのサンプルスクリプトを提供してくれました。このルールはEBSから送信される情報に基づきmodifyVolumeというイベントにマッチし、logEventsというLambdaファンクションを起動します:
ebs5

このファンクションは対象となるボリュームを特定し、これがEC2 Systems Managerで管理されるインスタンスにアタッチされていることを確認したうえでメンテナンス用のタグ情報を付与します:

def lambda_handler(event, context):
    volume =(event['resources'][0].split('/')[1])
    attach=ec2.describe_volumes(VolumeIds=[volume])['Volumes'][0]['Attachments']
    if len(attach)>0: 
        instance = attach[0]['InstanceId']
        filter={'key': 'InstanceIds', 'valueSet': [instance]}
        info = ssm.describe_instance_information(InstanceInformationFilterList=[filter])['InstanceInformationList']
        if len(info)>0:
            ec2.create_tags(Resources=[instance],Tags=[tags])
            print (info[0]['PlatformName']+' Instance '+ instance+ ' has been tagged for maintenance' )

 

その後に、EC2 Systems Managerがメンテナンス用のタグが付与された全てのインスタンスでPowerShellスクリプトを起動します。このスクリプトはインスタンスのディスクとパーティションの情報を参照し、拡張を必要とする全てのドライブとファイルシステムについて、許容可能な最大サイズまで拡張を行います。以下がスクリプトの抜粋です:

foreach ($DriveLetter in $DriveLetters) {
	$Error.Clear()
        $SizeMax = (Get-PartitionSupportedSize -DriveLetter $DriveLetter).SizeMax
}

自動化について詳しく知りたい場合は、こちらを参照してください。(訳注:翻訳時点では英語版のみですが、随時翻訳を進めて参ります)

本日からご利用頂けます
エラスティックボリュームの機能は本日今すぐにご利用頂くことができます!特殊なケースにおける例外や、制約についてはドキュメント(本記事執筆時点では英語版)をご確認ください。

— Jeff;
(日本語版はSA小林が翻訳しました。原文はこちら)