Author: AWS Japan Staff


New – Amazon Simple Queue Service (SQS) でサーバー側の暗号化を導入

AWS シリーズの中でも尊敬に値するサービスの 1 つ、Amazon Simple Queue Service (SQS) は多くのアプリケーションにおいて欠かせない一部を担っています。「Amazon SQS でより優れたアーキテクチャを実現 (Amazon SQS for Better Architecture)」や「Amazon SQS と Amazon DynamoDB で大量のメッセージを処理する (Massive Message Processing with Amazon SQS and Amazon DynamoDB)」などのプレゼンテーションは、SQS をどのように使用すれば復元力とスケーラブルが高いアプリケーションを構築できるのか説明しています。そして今回、サーバー側の暗号化をサポートすることでその SQS がさらに便利になりました。今後は AWS Key Management Service (KMS) による暗号化キーを使用して、スタンダードと FIFO キューの両方で SQS 暗号化済みメッセージを保存するオプションが提供されます。このオプションはキューの作成時に選ぶことができます。また、同時に既存のキューで設定することも可能です。SSE はメッセージ本文を暗号化しますが、キューのメタデータやメッセージのメタデータまたはキューごとのメトリクスは対象外になります。既存のキューに暗号化を追加しても、過去のメッセージは暗号化の対象にはなりません。同様に、暗号化を解除しても過去のメッセージの暗号化がキャンセルされることはありません。

暗号化したキューを作成
新しいバージョンの AWS Management Console では、便利なグラフィックを使用してスタンダードと FIFO キューのどちらかを選択できます。

キューとオプションの Dead Letter Queue に属性を設定することができます。

Use SSE を確認し希望のキーを選択できるようになりました。

各顧客やリージョン独自の AWS マネージド型カスタマーマスターキー (CMK) を使用したり、ご自分のキーを作成して管理することができます。ご自分のキーを使用する場合は、メッセージの暗号化や複合化を許可するため、KMS キーポリシーを必ず更新してください。データ再利用期間を設定することもできます。この間隔は SQS がどれだけ頻繁に KMS からの暗号情報を更新するか、1 分から 24 時間の範囲でコントロールすることができます。間隔を短くすると、セキュリティプロフィールを向上させることができますが、KMS のコストは上昇します。詳細は「SQS SSE のよくある質問 (SQS SSE FAQ)」や「サーバー側の暗号化 (Server-Side Encryption)」のドキュメントをご覧ください。

今すぐ利用可能
サーバー側の暗号化は US West (Oregon) リージョンと US East (Ohio) リージョンで今すぐご利用いただけます。その他でも今後リリース予定です。暗号化の使用は無料となりますが、SQS が KMS に向けたコールを発信する場合は有料になります。詳細は「カスタマーマスターキー (CMK) 使用料の料金を推定するには (How do I Estimate My Customer Master Key (CMK) Usage Costs)」をご覧ください。

Jeff;

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

春到来に伴い Tina Barr のスタートアップ企業を紹介するブログです。お楽しみください!

-Ana


今月も引き続き、AWS を利用しているホットなスタートアップ企業を紹介していきます。今回は 3 つの新しいスタートアップ企業を紹介します。

  • Beekeeper – 社員同士のコミュニケーションをよりシンプルに
  • Betterment – 誰でも簡単に投資をスタート
  • ClearSlide – 業界をリードするセールスエンゲージメントプラットフォームを提供

3 月のホットスタートアップを見逃しましたか? 大丈夫、こちら からご覧いただけます。

Beekeeper (スイス、チューリッヒ) Beekeeper のロゴ
チューリッヒ工科大学 (ETH Zurich) 卒業の Flavio Pfaffhauser
Christian Grossmann は、人々を結び付けるためのテクノロジーを構築することに熱心です。学生のソーシャルコミュニティから始まったそれは、すぐに Beekeeper になりました。Beekeeper は、仕事場において社員がどこからでもコミュニケーションを取り合うことを可能にするプラットフォームです。Flavio と Christian は自分達の目的に適った方法で、人々がエンゲージするソーシャルプラットフォームの構築方法を学びました。すると、様々なビジネスから各社の特別なプロセスとニーズに対応できるプラットフォームをリクエストされるようになりました。このプラットフォームは、デスクに向かっていたり出先にいたとしても、まるですぐ隣に相手が座っているかのように感じられるものを作りたいというコンセプトから始まりました。2012 年に創設された Beekeeper は、情報交換、コミュニケーション、ピアコラボレーションの改善に焦点を当てています。そして組織にとって、社員の声に耳を傾けることが非常に大切であると考えています。「まずはモバイル、デスクトップも OK (“Mobile First, Desktop Friendly”)」なプラットフォームは、シンプルかつ直観的なインターフェイスで、複数のオペレーティングシステムを簡単に 1 つのエコシステムにすることができます。インターフェイスは企業のブランドやアイデンティティに合わせてスタイルしたりカスタマイズすることができます。社員はいつでもどこにいても、プライベートチャットやグループチャット、ビデオ、ファイル共有、フィードバックに関するアンケート調査などを通じて同僚とコミュニケーションを取り合うことができます。Beekeeper の分析ダッシュボードで、リーダーシップチームはディスカッションで何がトレンディングトピックになっているのか確認したり、社員のエンゲージメントやアプリ使用をリアルタイムでトラッキングすることができます。Beekeeper は現在 137 か国に渡り、サービス業や建設業、運送業そしてその他の業界で利用されています。Beekeeper は同社のエンジニア達が顧客サービスの問題に集中できるようにする AWS を好んで使用しています。同社はそのインフラストラクチャ構築に Amazon EC2Amazon S3Amazon RDS などのサービスを使用しています。これらはすべてテクニカルチームが管理タスクに煩わされることなく作業を進行できるようにしています。Amazon Elastic TranscoderAmazon QuickSight は、分析ダッシュボードの構築やデータウェハウスを実行するための Amazon Redshift で使用されています。最新情報については Beekeeper の公式ブログをご覧ください。

Betterment (ニューヨーク州、ニューヨーク)
Betterment のロゴ
Betterment は個人のファイナンシャルゴールにかかわらず、誰もが簡単に利用できる投資方法の提供を目標としています。2008 年、Jon Stein は業界に新たなイメージを与え、自らが経験したミスを将来の投資家達が回避できるようにすることを目的として同企業を設立しました。当時、資金を投資する方法としては自分で行うか別の誰かに依頼するといったように、一般的にあまりオプションがありませんでした。そして残念ながら、ファイナンシャルアドバイザーというのは、実際にはクライアントにとってベストではなくても特定の投資を勧めるように報酬を受け取っている場合もあります。Betterment は顧客にとって最善の利益となり個人のファイナンシャルゴールに適った投資だけを選択します。そして現在、同社は 240,000 人の顧客を抱え資産 80 億ドル以上を管理する、インディペンデントで最大規模のオンライン投資アドバイザーとなりました。Betterment はテクノロジーを使用して投資をより簡単そして効率的にしながら、確定申告後の利益を増やせるように顧客をサポートしています。同社は幅広いファイナンシャルプランニングサービスを提供し、顧客のライフゴールにフィットするようにプランを立てるようにしています。投資プランを開始するには、まず顧客は年齢、年金口座の状況、年収を入力します。すると Betterment が推奨投資額やその個人に適したアカウントタイプをお勧めします。従来の投資サービスが低コストでは提供できない方法で、同社は顧客の投資を管理しています。Betterment のエンジニア達は常にできる限り早急に顧客の資金を最大限に活用できるようにするため、業界で変化し続けるテクノロジーの構築に取り組んでいます。AWS は Betterment のプロビジョンインフラストラクチャを容易にしたり、これまでチーム全体が管理する必要のあった様々なサービス機能のオフロードを可能にする柔軟性を提供しています。クラウドを始めたばかりの頃、Betterment は Amazon EC2Amazon RDS Amazon S3 のスタンダード実装を使用していました。完全に AWS の使用を開始してからは Amazon RedshiftAWS LambdaAWS Database Migration ServiceAmazon KinesisAmazon DynamoDB などのサービスを活用するようになりました。そして現在では開発、テスト、機能のデプロイ、機能強化において 20 種類以上の AWS サービスを日常的に使用しています。Betterment の詳細はこちらをご覧ください。

ClearSlide (カリフォルニア州サンフランシスコ)
ClearSlide はセールスエンゲージメントプラットフォーム業界をリードし、すべてのカスタマーインタラクションに問題のないよう完全な統合ツールを提供しています。2009 年の設立以来、ClearSlide はカスタマーエクスペリエンスを改善する方法を模索し、セールスリーダーやチーム、マーケティング、カスタマーサポートチームなどに向けて数々のツールを開発してきました。このプラットフォームは顧客がすぐにコンテンツ、コミュニケーションチャネル、詳細情報にアクセスできるようにすることで、顧客がより良い決断を下し管理できるためのサポートを提供しています。ClearSlide は Comcast、The Sacramento Kings、The Economist など何千社という企業に同サービスを提供し、これまでに毎分 7.5 億件のエンゲージメントを生成してきました。ClearSlide はセールスプロセスにおけるすべての面でソリューションを提供しています。ClearSlide はセールスリーダーに向けてエンゲージメントダッシュボードを提供し、取引上の可視性やコーチング、販売数を正確に予測する方法を改善できるようにしています。マーケティングやセールスチームにおいては、販売者を適切なコンテンツに正確なタイミングで正しい関連性に向けて導き、コンテンツの ROI を最大限にするための情報を提供します。セールス担当においては、ClearSlide を使用することでコミュニケーション、コンテンツ、分析を 1 つのプラットフォームエクスペリエンスで統合することができます。メール、直接の会話、オンラインミーティング、ウェブ、ソーシャルなどを使用してコミュニケーションを取ることができます。現在、ClearSlide の顧客は成功した取引の割合が 10 – 20% 上昇したことを報告しています。また、新しい担当者のオンボーディングに費やす時間を 25% 削減し、販売費 50-80% の削減に成功したことが分かっています。ClearSlide は幅広い AWS サービスを使用していますが、Amazon EC2Amazon RDS がもっとも大きな影響を同社のビジネスにもたらしました。EC2 を使用することで、成長過程にあるスタートアップ企業にとって重要なポイントとなるコンピューティング性能のスケールが簡単にできます。また、開発から統合そしてステージングから本稼働まで、デプロイメント時に一貫性を提供します。RDS はオーバーヘッドを削減し ClearSlide がデータベースインフラストラクチャをスケールできるようにします。AWS は時間のかかるデータベース管理タスクを行うことができるので、ClearSlide は運用費を削減し顧客に対してより計画性をもって対応することが可能になります。ClearSlide を使用することで 22% も販売サイクルを短縮した LiveIntent のビデオをご覧ください。最新情報については同社の Twitter をフォローしてください。今月も AWS を利用している素晴らしいホットスタートアップをご覧いただき、ありがとうございました。

-Tina

ローカルのMosquitto MQTT BrokerをブリッジにAWS IoTを使う

AWS SDKまたはAWS IoT Device SDKを使用して、数百万のオブジェクトをAWS IoTに安全に接続できます。
製造業におけるIoTの場合、オブジェクトは複数の理由でゲートウェイに接続されます。
センサーは非常に制約され、クラウドに直接接続できないことや、センサーはプロトコルとしてMQTTが使えないまたは、 ゲートウェイ上でローカルに分析と処理を実行する必要があります。

ローカルMQTTブローカーの1つの機能は「ブリッジ」と呼ばれ、MQTTメッセージを交換できるように、ローカルMQTTブローカーをAWS IoTに接続することができます。 これにより、オブジェクトがAWS IoTと双方向で通信し、AWSクラウドの恩恵を受けることができます。

この記事では、この機能が非常に便利で、実装方法を示すユースケースについて説明します。

 

MQTTブローカーをAWS IoTにブリッジする理由

IoTではセキュリティが最も重要であり、AWS IoTブローカーには、クライアント証明書付きのTLS 1.2などに基づいてデバイスを認証および認可する高度なセキュリティビルトインが組み込まれています。

従来のIoTデプロイメントを使用している場合は、MQTTブローカーにユーザー名やパスワードなどの他の認証メカニズムを使用してオブジェクトをすでに接続している可能性があります。 MQTTブローカーは、センサーがデプロイされる非常に近い場所(ローカルMQTTブローカー)もしくはクラウドの中に構築されています。

現在のセキュリティ標準をAWS IoTのものに合わせてアップグレードする予定で、AWS IoTのスケーラビリティとルールエンジンの恩恵を受けるには、従来のMQTTブローカーをAWS IoTにブリッジすることができます。これは、現在のシステムのアップグレードを待たずにすばやく導入できる簡単な一時的なソリューションです。単一のブローカーを超えるスケーリングはこの記事の範囲には含まれていませんが、Mosquitto MQTT Brokerのブリッジ機能に焦点を当てます。

MosquittoのようなオープンソースのMQTTブローカーは、Linuxのような多くのオペレーティングシステムにインストールすることができます。ローカルデバイスにMosquittoをインストールすると、Mosquitto bokerの機能(ローカルでのメッセージの永続化、ローカルでのログのアクティビティ)をローカルで有効にするだけでなく、ローカルデバイスにMosquittoをインストールすることで、AWS IoTにデータを送信するための特別なコードを開発する必要がありません。

(more…)

AWS Storage Gateway でファイルインターフェイス

AWS re:Invent のレビュー」といったブログカテゴリを追加した方がいいかもしれませんね。去年の 11 月、AWS Storage Gateway に重要な機能を追加しましたが、忙しすぎてその調査やブログを書く時間を取れずにいました。Storage Gateway は既存のアプリケーションと AWS Cloud の間に位置するマルチプロトコルストレージアプライアンスです。お使いのアプリケーションやクライアントオペレーティングシステムは (設定によりますが) ゲートウェイをファイルサーバー、ローカルディスクボリュームまたは仮想テープライブラリ (VTL) と見なします。その背景でゲートウェイはコスト効率が良く耐久性のある安全なストレージに Amazon Simple Storage Service (S3) を使用しています。Storage Gateway はデータをローカルでキャッシュし、帯域幅の管理機能を使用してデータ転送を最適化します。Storage Gateway はインストールや設定そして実行が簡単な自己完結型の仮想アプライアンスとして提供されています (詳細は「Storage Gateway のユーザーガイド (Storage Gateway User Guide) 」をご覧ください)。既存の環境でクラウドストレージのスケールや耐久性そしてコスト面におけるメリットを活用できます。既存のファイルやディレクトリを S3 に移動するプロセスを減らし、ドラッグアンドドロップ (または CLI ベースのコピー) でシンプルに移動できます。その他多くの AWS サービスと同様に、2012 年にリリースされてから Storage Gateway にいくつもの機能が追加されてきました (「AWS Storage Gateway – AWS クラウドストレージと既存のオンプレミスアプリケーションを統合 (The AWS Storage Gateway – Integrate Your Existing On-Premises Applications with AWS Cloud Storage)」)。Storage Gateway をリリースした時点で、ストレージボリュームの作成や iSCSI デバイスにアタッチできたほか、ボリュームすべてを保存したり、ゲートウェイでもっとも頻繁にアクセスされているデータのキャッシュを保存するオプションを提供します。そして、これらはすべて S3 でサポートされています。そしてその後、仮想テープライブラリのサポートを追加しました (「AWS Storage Gateway で仮想テープライブラリを作成 (Create a Virtual Tape Library Using the AWS Storage Gateway)」)。今年に入ってからは読み取り専用のファイル共有、ユーザーアクセス権限のスカッシュ、および追加/削除されたオブジェクトのスキャンを追加しました。新しいファイルインターフェイス AWS re:Invent で 3 つめのオプションをリリースしました。今回はそれについてご紹介します。オンプレミスサーバーやデスクトップにマウントできる仮想ファイルサーバーとして Storage Gateway を使用できるようになりました。データセンターまたはクラウドでセットアップが完了すると、設定済みのバケットを NFS マウントポイントとして利用できるようになります。アプリケーションは NFS 上でファイルの読み取りや書き込みを行うだけです。背景ではゲートウェイがネイティブにアクセスできる S3 バケットでこうしたオペレーションをオブジェクトレベルにします。ファイルゲートウェイを作成するには Storage Gateway コンソールにアクセスし [Get started] をクリックしてから [File gateway] を選択します。

VMware ESXi または Amazon EC2 のホストプラットフォームを選択します。

プレミスで Storage Gateway をホストし、永続的または一時的なクラウドへのブリッジとして使用するお客様が多くなるのではないかと思います。このオプションのユースケースには、バックアップ、移行、アーカイブ、分析、ストレージ階層化、大量のコンピューティングを伴うプロセスの簡略化が含まれています。クラウドにデータが入り次第、複数のストレージ階層化 (不定期なアクセスや Glacier はアーカイブに最適です)、ストレージ分析、タグ付けなど様々な S3 の機能を活用できるようになります。私のオンプレミスにはあまりデータがないので、このブログ用として EC2 インスタンスで Storage Gateway を実行します。インスタンスを起動し画面に表示される手順ごとに設定します。適切なインバウンドセキュリティグループルールを作成します (HTTP アクセスのポート 80 と NFS のポート 2049)。キャッシュとして使用するために汎用目的の SSD ストレージ 150 GiB を追加しました。

インスタンスが起動したら、そのパブリック IP アドレスを取得し、新に開始したゲートウェイと繋げるために使用します。

タイムゾーンを設定しゲートウェイの名前を指定したら [Activate gateway] をクリックします。

次にローカルストレージをキャッシュとして設定し [Save and continue] をクリックします。

ゲートウェイが実行され、コンソールでも表示されています。

次に [Create file share] をクリックし、NFS シェアを作成して S3 バケットと関連付けます。

ご覧のように、ここでストレージクラスを選択することができます (自分のニーズまたはユースケースに合わせて Standard または Standard – Infrequent Access を選択)。この時点でゲートウェイはバケットにファイルをアップロードする必要があります。[Create a new IAM role] をクリックすると、ロールとポリシーを作成できます (詳細は「Amazon S3 Destination にアクセス権限を付与する (Granting Access to an Amazon S3 Destination)」をご覧ください)。設定を確認し [Create file share] をクリックします。

ところで Root スカッシュは AWS Storage Gateway の機能で野菜の名前ではありません (念のため)。これが有効になっていると (デフォルトでは有効) root (user id 0) が所有するものとして到着したファイルは user id 65534 にマップされます (従来は nobody)。新しいファイルと新しいディレクトリにデフォルト権限をセットアップすることもできます。新しいシェアがコンソールで表示され、数秒で利用が可能になります。

コンソールに Linux、Microsoft Windows、macOS の適切なマウントコマンドが表示されます。このコマンドはインスタンスのプライベート IP アドレスを使用します。大方の場合、その代わりにパブリックアドレスの使用をおすすめします (説明の必要もないと思いますが、パブリック NFS シェアを作成する場合は慎重に行ってください。そして接続を許可している IP アドレスを詳細に管理することもお忘れなく)。S3 コンソールでバケットを調べます (jbarr-gw-1)。予想どおり空でした。

次に EC2 インスタンスでシェアをマウントし、いくつかのファイルをコピーします。

コンソールに戻ると、予想どおりバケット内に新しいフォルダ (jeff_code) を見つけることができます。その中にはシェアにコピーしたファイルがあります。

お分かりのように、ファイルは S3 に直接コピーされ、通常の S3 オブジェクトになっています。つまり、既存の S3 ツール、コード、分析を使用してプロセスできることを意味しています。以下の例をご覧ください。

  • 分析 – 新しい S3 メトリクスと分析を使用して、バケット全体またはその中のディレクトリツリーを分析することができます。
  • コードAWS LambdaAmazon Rekognition はイメージのアップロードをプロセスする場合に使用できます。アイデアやコードについては「サーバーレスの画像認識について (Serverless Photo Recognition)」をご覧ください。Amazon Elasticsearch Service を使用していくつかまたはすべてのファイルをインデックスしたり Amazon EMR で大量のデータをプロセスすることができます。
  • ツール – バケット内にある既存のオブジェクトをプロセスしたり、S3 API を使用して新しいオブジェクトを作成することができます。作成または削除を行うコードまたはスクリプトが RefreshCache 関数を呼び出し、バケットに関連しているゲートウェイのコンテンツを同期するようにします (同じバケットで複数の読み取り専用ゲートウェイにポイントすることで、マルチサイトデータディストリビューションワークフローを作成できます)。また、バックアップの送信先としてシェアを使用することで、ファイル中心のバックアップツールを活用することもできます。

ゲートウェイはファイルのメタデータすべてを S3 メタデータとして保存します (所有者、グループ、権限など)。

Storage Gateway リソース Storage Gateway の詳細については次をご参照ください。プレゼンテーション – 「AWS Storage Gateway の詳細について (Deep Dive on the AWS Storage Gateway)」: ホワイトペーパー – 「ハイブリッドアーキテクチャのファイルゲートウェイ – 概要とベストプラクティス (File Gateway for Hybrid Architectures – Overview and Best Practices)」: 最近のビデオ:

今すぐ利用可能
この優れた AWS 機能は去年の 11 月よりご利用可能になっています。

Jeff;

新しい Samsung DeX と Samsung Galaxy S8/S8+ で Amazon WorkSpaces を使用

テクノロジーの進化とその改良を見るのは実に面白いものです。たとえば、最近の携帯電話にはハイエンドなデスクトップが備えるほどの解像度を持つ画面が使用されているほか、接続性や携帯性においても複数のオプションが提供されています。今週初めに、最新の Samsung Galaxy S8+ スマートフォンと、独自の新しいコンパニオンデバイス、Samsung DeX Station を試す機会に恵まれました。まず、スマートフォンに Android 向けの Amazon WorkSpaces クライアントをインストールし、WorkSpace の登録コードを入力してログインしてみました。これら一連の操作は、こちらの新しいビデオでご覧いただけます。

DeX にはキーボードとマウス用の USB コネクターが含まれています。Bluetooth で操作することもできます。冷却ファン、時間を短縮できるスマートフォンの充電器、HDMI とイーサネットポートも含まれています (スマートフォンのデータ通信または Wi-Fi 接続の使用も可)。すべて一緒にすれば、どこにいてもクラウドベースのデスクトップにアクセスできます。滞在先のテレビやモニターを使用すれば、企業ネットワークのフルアクセスでファイルやその他のリソースにアクセスできるので、旅先の荷物も軽くなります。

Jeff;

PS – 私の WorkSpace についてもう少し詳しく知りたければ「Amazon WorkSpace が大活躍 (I Love my Amazon WorkSpace)」をご覧ください。

Now Available – Lumberyard Beta 1.9

本日、最大リリースであるLumberyard Beta 1.9がリリースされたことをお知らせします。

473以上に及ぶ改良、修正、および機能のリリースには、30分以下でプレーヤー認証を実装するための新しい Player Account  Cloud Gemが含まれ、複雑なコンテンツをより迅速に構築するためのComponent Entity workflow のアップデート、particle editorの新しいGPU機能とエミッタタイプ、視覚的に素晴らしい効果でゲーム世界を満たすことができ、そしてより多くの機能が追加されました。Lumberyard Beta 1.9 はこちらからダウンロードできます。

これらの改善は皆様の直接のフィードバックのお陰です。以前、私たちのチームの中核的哲学の1つである「continuous improvement(継続的改善)」の日本語であるカイゼンについて話しました。先月のGDCの素晴らしい提案とアイデアのおかげで、我々はLumberyardのいくつかの主要分野でのカイゼンへのコミットメントを強化することができました。ここにいくつかあります:

New Player Account Cloud Gem

私たちがGDCで得た最も一般的なリクエストの1つは、より多くのCloud Gemsを提供することでした。2月にリリースされた当社独自のCloud Gems Frameworkにより、開発者は、1人のエンジニアとわずか30分で、ネットワーク通信が必要なゲーム要素(dynamic content、leaderboards、live messagesなど)を構築し、起動することが簡単になりました。今回のリリースでは、Player Account Cloud GemをLumberyardの成長し続けるGemコレクションに追加し、プレイヤーの認証と管理のためのカスタマイズ可能なスタンドアロンのソリューションを提供しています。プレイヤーがゲームに登録したときにゲームキーを要求したり、クラウドのプレーヤーのために追加のメタデータを保存したい場合、Player Account Cloud Gemを利用するとその時間と労力を節約できます。

理由は次のとおりです。これまではプレーヤーアカウントシステムを自分で実装するには、アカウント情報を保存するデータベースサービスをセットアップし、プレーヤー情報を安全なハッシュで保護をするための実装をし、サービスと電子メールシステムを実装する必要があります。 ID。また、ログイン・フロー、アイデンティティ・キャッシング、および期限切れの認証トークン更新プロセスをゲーム・クライアントでセットアップする必要があります。2〜3人のエンジニアがこの作業を行うには数カ月かかることがあります。何か間違ったことがあれば、プレイヤーがゲームに参加できないという危険性があります。Player Account Cloud Gemを使用すると、ほんの数ステップで実行できるように簡略化されているので、1人のエンジニアは約30分ですべてを実行できます。その結果、Cloud Gem Portal dashboardからプレーヤーのデータを管理し更新することができます。

Component Entity Workflows

また、今年はGDCでComponent Entityシステムの最新のワークフローをデビューしました。皆様のご意見のおかげで、このリリースでゲームとエンジンの要素を構築するためのモジュラーで直感的な方法を提供する、いくつかの重要な改善を行う事ができました。新しいComponent Entityシステムの目標は、小規模なゲーム、カジュアルゲーム、大規模なAAAエクスペリエンスのいずれを構築しているかに関係なく、複雑で実用的なエンティティを短時間で最小限の労力で作成するのに役立てます。私たちが最近Component Entityシステムを改善したいくつかの方法を見てみましょう。
第1に新しいComponent Entityシステムでは、リフレクション、シリアライゼーション、およびメッセージングを使用して、エンジニアリングを必要とせずにコンポーネントの機能をデザイナーに自動的に公開します。これは、Lumberyard Editorでコンポーネントのプロパティをドラッグ&ドロップして編集できることを意味し、わずか数回のクリックで「スライス」と呼ばれる完全にカスケード化されたプレハブを作成します。
第2に、努力を減らしイテレーションを加速するために、働かないエンティティを作成することは困難でした。たとえば、同じエンティティ(複数の静的メッシュなど)に重複するコンポーネントを追加しようとすると、システムは間違いを犯さないようにします。コンポーネントが機能するために別のコンポーネントを必要とする場合(単純なアニメーションコンポーネントではスキンメッシュが機能する必要があります)、依存関係を自動的に追加し、そうする必要はありません。
第3に、新しいComponent Entityシステムが欠落した構成や誤った構成をどのように処理するかについて、より柔軟に作成したいと考えました。エンティティに無効なコンポーネントや互換性のないコンポーネントが含まれるようになったときに、新しい警告システムでサービスの問題が表示されます。この警告は、問題を修正し、不足している依存関係をすばやく解決するのに役立ちます。たとえば、最初にシェイプを追加せずにプリミティブコライダーを追加すると、プリミティブコライダーはシェイプを追加することを提案します。ワンクリックで必要なシェイプのタイプを選択できます。シェイプが追加されるまで、プリミティブコライダーは登録されないため、シェイプを選択する前にゲームを実行すると実行時の問題を防ぐことができます。
最後に、皆様のフィードバックのおかげで、エンティティインスペクタの新しい使いやすさが改善されました。インスペクタでコンポーネントが追加された順序を覚えることができ、右クリックメニューからコンポーネントをより簡単に並べ替えることができます。(今後のリリースでドラッグ&ドロップを追加する予定です)また、エンティティ間でコンポーネントの切り取り、コピー、貼り付けを可能にし、検索機能を改善して大量のコンテンツをナビゲートし、コンポーネントのUIを見直して読みやすくしました。



Particle Editor

particle editorも今月大きな更新をおこないました。このリリースのプレビュー以降、particle editorには数多くの新機能、使い勝手の向上、モバイルプラットフォームのサポートの強化などが含まれ、ゲームの視覚効果をより簡単に作成できるようになりました。シンプルでフレキシブルなエミッタハンドリングを望んでおり、壮大なスケールのパーティクルエフェクトを実現することができました。さらに特殊なエミッタタイプを使用して、より高速にイテレーションすることができます。このリリースによって、それをすべて実現できました。Lumberyard Beta 1.9には、エミッタの親子関係を簡単に管理するための再構成可能なエミッタ階層、エフェクト内の数十万個の粒子をプッシュするためのGPU機能追加、および新しい5つのエミッタタイプが含まれています。

And More

Lumberyard Beta 1.9にはさらに多くの機能がありますので、ここで全リリースノートを確認できます。その他の特長としては、新しいワンステップの迅速なインストールプロセス、FBXインポータでのZ-upとY-upの両方のワールド座標のサポート、Asset Browserの検索機能の改善、UIエディタとTwitch MetastreamのコンポーネントエンティティとLuaサポート、バージョン管理されたGemsのサポートなど

もちろん、ここ6週間でGDCで頂いたすばらしいフィードバックのすべてに対処することは不可能でした。私たちは、エンジン性能の向上、新しいクラウド機能の統合、最も野心的で最高品質のマルチプレイヤー、ライブ、コミュニティ主導のゲームの構築を支援など、積極的にワークフローをイテレーションしカイゼンを続けています。フォーラムやeメールでのフィードバックや提案をください。チームは皆様からのご意見を聞くことが大好きです。

Amazon Lumberyardを使い始めるには、Lumberyardのウェブサイトでエンジンをダウンロードしてください。  チュートリアルをお試し頂き、 フォーラムを訪問し、ドキュメントを読んでLumberyardの新機能についてのさらなる詳細を得ることができます。

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

AWS でコンソーシアムサイエンスを活用し科学的発見を促進

同僚の Mia Champion は科学者 (彼女が発表した記事) であり、AWS 認定ソリューションアーキテクト そして AWS 認定開発者でもあります。今回は、彼女が大量なデータのデータセットリサーチを行っている際に、バイオインフォマティクスにおけるクラウドコンピューティングの価値に気付いた時のことについてブログを投稿いただきました。

Jeff;


科学研究における技術の進歩は、そのコンテンツにおいても複雑性を増し、日々急増しているデータセットのコレクションに可能性を与えています。世界中で加速化するイノベーションは、最近のクラウドコンピューティング革命によっても活気付けられ、一見したところ無限でスケーラブルそして迅速なインフラストラクチャを研究者に提供しています。現在では、研究者が独自のシーケンサー、マイクロスコープ、コンピューティングクラスターなどを所有するための障害を排除しています。クラウドを使用することで、科学者はギガバイトにも及ぶ何百万人という患者のサンプルのデータセットや各患者のその他の情報を簡単に保存、管理、処理そして共有することができます。アメリカの物理学者である John Bardeen はこのように言っています。「科学というものは協同して取り組むものです。数人の科学者が共に努力し出し合った結果を組み合わせることで、1 人の科学者が行うよりも効率よく研究を進めることができるのです (Science is a collaborative effort. The combined results of several people working together is much more effective than could be that of an individual scientist working alone)」

再現性のイノベーション、一般化、データ保護の優先
これまでにないスケールで、安全性を備えたクラウドを有効にしたデータ共有を活用する研究者や組織は日々増え、AWS クラウドを使用して革新的でカスタマイズした分析ソリューションを作り出しています。しかし、そうしたスケールの共同作業環境において、対象分野そして科学における従来の方法を根本的に変え、安全なデータ共有と分析を行うことは可能でしょうか?クラウドを有効にしたリソースの共同体を構築することで、研究結果の説明やその影響において問題となり、再現性の下落に繋げた分析変動性を排除することはできるのでしょうか? こうした疑問への答えは「イエス」です。Neuro Cloud Consortium、The Global Alliance for Genomics and Health (GA4GH)、The Sage Bionetworks Synapse プラットフォームのようなイニシアティブは (これは、いくつものリサーチコンソーシアムをサポートしています)、DREAM challenges も含み、プラクティスモデルのクラウドイニシアティブを取り入れ始めています。そして、これらは神経科学、感染病、癌などにおいても大きな発見を提供しているだけでなく、科学研究の在り方についても根本的な変化をみせています。

クラウドで開発するモデル、アルゴリズム、機能をデータに取り入れる
従来、共同プロジェクトでは研究者が相対的な配列分析や医用画像データでディープラーニングアルゴリズムのトレーニングにて使用されるデータセットをダウンロードするようになっていました。そしてダウンロード後に、研究者は組織のクラスター、ローカルワークステーション、ノートパソコンを使用して独自の分析を開発し実行することができます。

この方法で行う共同作業は問題となるいくつもの理由があります。まず、データセキュリティが最初の懸念です。データセットをダウンロードする方法では、その情報が何人もの受信者に渡り「連鎖したデータ共有」を許可してしまうことになるからです。そして次に、何らかの段階でテンプレートを使用せずにコンピューティング環境で行った分析は変数解析のリスクを伴い、それ自体を別の研究者が再現することはできません。また、同じ研究者が別のコンピューティング環境を使用した場合も同様です。さらに、必須とされるデータのダンプ、プロセスそして共同作業のグループへの再アップロードやディストリビューションは効率的とは言えず、各個人のネットワーキングやコンピューティング能力に依存することになります。全体的に見て、従来の科学的な共同作業を行う方法にはセキュリティ問題や科学的発見に費やす時間において障害を伴います。AWS クラウドを使用することで、共同作業を行う研究者達は Identity and Access Management (IAM) ポリシー制限をユーザーのバケットアクセスや、S3 バケットポリシー、アクセスコントロールリスト (ACL) で利用することにより、簡単かつ安全にデータセットを共有することができます。データソースに分析を移動するリソースを使用したり、リモート API リクエストを利用して共有データベースやデータレイクにアクセスする方法を取り入れることで、多くの研究者達はデータセットをダウンロードする必要性を排除し、分析を効率化してデータセキュリティを確保しています。この達成方法の 1 つとして、当社のお客様は共同作業を行うユーザー達にアルゴリズムを送信または共有したデータセットをホストするシステムで実行するモデルを提供することで、コンテナベースの Docker テクノロジーを利用しています。

Docker コンテナイメージにはアプリケーションへの依存関係すべてが含まれています。そのため、レベルの高い多彩性や可搬性を提供することができ、これは他の実行可能ベースのアプローチの使用に比べ、大きなメリットになっています。機械学習の共同プロジェクトにおいては、各 Docker コンテナにアプリケーション、言語ランタイム、パッケージとライブラリ、その他にも MXNetCaffeTensorFlowTheano など、研究者達が一般的に使用している人気のディープラーニングフレームワークが含まれています。こうしたフレームワークで一般的に見られる機能は、機械学習の計算に関与するマトリックスやベクトルオペレーションホストマシンのグラフィック処理ユニット (GPU) があります。こうした目的を持つ研究者達は EC2 の新しい P2 インスタンスタイプを利用して、送信された機械学習モデルを実行しています。さらに NVIDIA Docker ツールを使用して、GPU を追加デバイスとしてシステムレベルに見せてコンテナに直接マウントすることができます。Amazon EC2 Container ServiceEC2 コンテナレジストリを利用することで、共同作業を行っている研究者達は同僚が再現可能な方法でプロジェクトリポジトリに送信した分析ソリューションを実行することができます。また、既存の環境で引き続き構築することも可能です。研究者は継続的なデプロイパイプラインを設計することで、Docker を有効にしたワークフローを実行することもできます。つまり、クラウドを有効にしたコンソーシアムイニシアティブは、幅広いリサーチコミュニティで精密医療分野における科学的発見を促進させながら、プロジェクトを実施する上でデータセキュリティや再現性を持つ、科学的発見が自然に必要とするプラットフォームをサポートすることも可能にしたモデルの役割を担っているのです。

Mia D. Champion, Ph.D.

Kinesis Firehoseを使用してApache WebログをAmazon Elasticsearch Serviceに送信する

ElasticsearchLogstash、および、Kibana(ELK)スタックを所有して運用する多くのお客様が、他の種類のログの中でもApache Webログを読み込んで可視化しています。 Amazon Elasticsearch Serviceは、AWSクラウドにElasticsearchとKibanaを提供しており、セットアップと運用が簡単です。 Amazon Kinesis Firehoseは、Amazon Elasticsearch ServiceにApache Webログ(またはその他のログデータ)をサーバーレスで確実に配信します。

Firehoseを使用すると、Firehose内のレコードを変換するAWS Lambda関数への自動呼び出しを追加できます。これらの2つのテクノロジーを使用すると、既存のELKスタックを効果的かつ簡単に管理することができます。

この記事では、最初にAmazon Elasticsearch Serviceドメインを設定する方法を説明します。次に、事前ビルドされたLambda関数を使用してApache Webログを解析するFirehoseストリームを作成して接続する方法を示します。最後に、Amazon Kinesis Agentでデータをロードし、Kibanaで可視化する方法を示します。

(more…)

AWS上でApache Flinkを使用してリアルタイムストリーム処理パイプラインを構築する

今日のビジネス環境では、多様なデータソースが着実に増加していく中で、データが継続的に生成されています。したがって、このデータを継続的にキャプチャ、格納、および処理して、大量の生データストリームを実用的な洞察に素早く繋げることは、組織にとって大きな競争上のメリットになっています。

Apache Flinkは、このようなストリーム処理パイプラインの基礎を形成するのに適したオープンソースプロジェクトです。ストリーミングデータの継続的な分析に合わせたユニークな機能を提供しています。しかし、Flinkを基にしたパイプラインの構築と維持には、物理​​的なリソースと運用上の努力に加え、かなりの専門知識が必要になることがよくあります。

この記事では、Amazon EMRAmazon KinesisAmazon Elasticsearch Serviceを使用してApache Flinkを基にした、一貫性のあるスケーラブルで信頼性の高いストリーム処理パイプラインの参照アーキテクチャの概要を説明します。 AWSLabs GitHubリポジトリは、実際に参照アーキテクチャを深く理解するために必要なアーティファクトを提供します。リソースには、サンプルデータをAmazon Kinesisストリームに取り込むプロデューサアプリケーションと、リアルタイムでデータを分析し、その結果をAmazon ESに可視化するためのFlinkプログラムが含まれています。

(more…)

Amazon Inspector の更新 – 評価レポート、プロキシサポートなど

Amazon Inspector は当社の自動セキュリティ評価サービスです。このサービスは AWS で実行するアプリケーションの動作を分析し、セキュリティ問題を識別する上で役立ちます。Inspector については 2015 年の後半にこのブログで紹介し、その使い方についてご説明したことがあります (「Amazon Inspector – 自動セキュリティ評価サービス (Amazon Inspector – Automated Security Assessment Service)」)。同サービスを使うには、まずタグを使用してアプリケーションを生成する AWS リソースのコレクションを定義します。次に、セキュリティ評価テンプレートを作成し評価の一部として実行したい一連のルールを特定します。

評価ターゲットとセキュリティ評価テンプレートを作成したら、クリック 1 つでターゲットリソースに対して実行することができます。この評価は Linux と Windows ベースの EC2 インスタンスで実行するエージェントを活用します (詳細については「AWS エージェント (AWS Agents)」をご覧ください)。評価は手動で実行したり、AWS Lambda を使用して既存の発券システムに結果を転送することができます (手順については「Amazon Inspector でセキュリティ脆弱性テストをスケールする (Scale Your Security Vulnerability Testing with Amazon Inspector)」をご覧ください)。実行するインスタンスが 1 件または何千件とある場合でも、定期的かつ頻繁に評価を行うことをおすすめします。デプロイや統合インスタンスといった DevOps パイプラインの一部として実行できます。そうすることで、セキュリティ評価テンプレートの作成時に選択したルールパッケージによる条件に見合った本稼働環境で、コードやシステムを安心してデプロイすることが可能になります。また、設定ドリフトを回避するため、本稼働システムに対しても頻繁に評価を実行することをおすすめします。Amazon Inspector には、次の強力な新機能を追加したばかりです。

  • 評価レポート – 新しい評価レポートはエグゼクティブサマリーから始まり、評価の総合的な概要を提供します。このレポートはチームやリーダーシップとの共有そしてコンプライアンス監査のドキュメントとしても使用できるように作成されています。
  • プロキシのサポート – プロキシ環境内で実行するようにエージェントを設定できるようになりました (これについては多くのお客様からリクエストいただきました)。
  • CloudWatch メトリクス – 長期に渡り変更をトラックして確認できるように、Inspector が Amazon CloudWatch にメトリクスを発行するようになりました。
  • Amazon Linux 2017.03 のサポートAmazon Linux AMI の新しいバージョンを本日リリースしました。Inspector もこれに対応しています。

評価レポート
評価の実行が完了したら、HTML 形式または PDF 形式で評価レポートの詳細をダウンロードすることができます。

レポートはカバーページとエグゼクティブサマリーで始まります。

評価ルールとテストしたターゲットを要約します。

各ルールパッケージの結果を要約します。

このレポートはコンプライアンス監査のドキュメントであるため、各結果と解決方法のヒントなど詳細情報を含んでいます。

レポートの全文は、すべてのターゲットインスタンスでどのルールがチェックされパスしたかを示します。

Proxy のサポート
Inspector エージェントが HTTP プロキシを介して Inspector と通信できるようになりました。Linux インスタンスでは HTTPS プロキシを、Windows インスタンスでは WinHTTP プロキシをサポートしています。AWS エージェントのプロキシサポート設定に関する手順については「Amazon Inspector ユーザーガイド (Amazon Inspector User Guide)」をご覧ください。

CloudWatch メトリクス
Amazon Inspector が各実行の後において Amazon CloudWatch にメトリクスを発行するようになりました。メトリクスはターゲットとテンプレート別に分類されています。AWS アカウントで実行されてきた評価の実行数を表示する集計メトリクスもご利用いただけるようになりました。これまでのように CloudWatch コンソールでメトリクスを確認できます。

ターゲットごとに発行したメトリクスの例は次をご覧ください。

テンプレートごとのメトリクスの例は次をご覧ください。

Amazon Linux 2017.03 のサポート
AWS の多くのお客様が Amazon Linux AMI をご利用されており、新しいバージョンが利用可能になり次第、自動アップグレードをされています。こうしたお客様に引き続き Amazon Inspector をご利用いただくため、AMI の現状バージョンだけでなく今後のバージョンでも、リリース当日に Amazon Inspector で必ずサポートされるようにしました。

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

料金はエージェント、評価ベースごとに定められます。毎月 45,000 以上の評価を実行する場合は、各評価 0.30 USD からスタートします。(詳しくは「Amazon Inspector の料金表 (Amazon Inspector Pricing)」をご覧ください)。

Jeff;