Amazon Web Services ブログ

【AWS Database Blog】AWS Database Migration Service におけるイベント通知

こんにちは。ソリューションアーキテクトの江川です。本日は、AWS のプロダクトマネージャーである Eran Schitzer が、AWS Database Blogに投稿したEvents and Notifications in AWS Database Migration Service を翻訳してご紹介します。


先日、AWS Database Migration Service (AWS DMS) に新機能が追加され、Amazon Simple Notification Service (Amazon SNS)を介して、Email や テキストメッセージ、HTTP エンドポイントへの通知といった形で、DMS のイベント通知を受け取れるようになりました。

お客様は2種類のイベント(DMS インスタンスに関連するイベントと、レプリケーションタスクに関連するイベント)をサブスクライブし、通知を受信できます。DMS インスタンスに関連するイベントには、可用性、設定変更、作成、削除、メンテナンスに関するイベントが含まれます。例えば、DMS インスタンスがメンテナンスにより停止すると、通知がトリガーされます。

レプリケーションタスクに関連するイベントには、タスクの開始、停止、終了、Full Load の完了、CDC の開始などのイベントが含まれます。例えば、移行タスクとしてすべてのデータを移行し終えると、“Full Load completed” という通知がトリガーされます。もし、タスクが Full Load に続けて、CDC を実行する(つまり、Full Load が開始してからのデータの変更をレプリケーションする)設定となっていた場合は、続けて “CDC started” という通知がトリガーされます。

さらに、AWS DMS ではイベントが様々なカテゴリに分類されており、ユーザーは AWS DMS コンソール、AWS DMS API を使って、そのカテゴリをサブスクライブできます。サブスクライブすることにより、そのカテゴリに関するイベントが起きた際に、通知されます。例えば、特定のレプリケーションインスタンスについての “creation(作成)”カテゴリをサブスクライブした場合、レプリケーションインスタンスが作成されているなどのような、レプリケーションインスタンスに影響を与える creation に関連したイベントが起きた際はいつでも通知がなされます。

下記の一覧は、現時点で DMS レプリケーションインスタンスについてサブスクライブできるカテゴリを示しています。

  • Configuration change(設定変更)—レプリケーションインスタンスの設定が変更されています
  • Creation(作成)—レプリケーションインスタンスが作成されています
  • Deletion(削除)—レプリケーションインスタンスが削除されています
  • Maintenance(メンテナンス)—レプリケーションインスタンスのオフラインメンテナンスが実行中です
  • Low storage—レプリケーションインスタンスの空きストレージが少なくなっています
  • Failover(フェイルオーバー)—Multi-AZ インスタンスのフェイルオーバーに関連するイベント。フェイルオーバーの有効化、開始、完了など。
  • Failure(失敗)—レプリケーションインスタンスで、ストレージ障害やネットワーク障害が発生しました

下記の一覧は、現時点で DMS レプリケーションタスクについてサブスクライブできるカテゴリを示しています。

  • State change— レプリケーションタスクが開始もしくは停止されました
  • Creation(作成)—レプリケーションタスクが作成されました
    Deletion(削除)—レプリケーションタスクが削除されました
  • Failure(失敗)—レプリケーションタスクが失敗しました

AWS DMS によるイベントとイベントカテゴリの一覧は、ドキュメントのイベントと通知の使用を参照してください。

AWS DMS イベントをサブスクライブするには、以下の通り行います。

  1. Amazon SNS トピックを作成します。このトピックには、どんなタイプの通知を受け取りたいか、受け取るアドレスや電話番号を設定します。
  2. AWS マネジメントコンソール、AWS CLI, もしくは AWS DMS API を通じて、AWS DMS イベント通知のサブスクライブを行います。
  3. AWS DMS のイベント通知を受け取るための承認メールもしくは SMS メッセージを受け取り、E メール、SMS メッセージ内のリンクをクリックして、サブスクライブの確認を行います。

サブスクライブしたことを確認すると、AWS DMS コンソールの Event Subscriptions セクションにて、お客様のサブスクリプションのステータスが更新されます。

そして、イベント通知の受信が開始されます。

コンソールを使ったテーブルマッピングについての詳細は、DMS ドキュメントを参照ください。

AWS Database Migration Service 全般に関する詳細は、こちらのウェブサイトを参照ください。

AWS HIPAA 対応サービス発表についての詳細情報

AWS では、HIPAA 対応サービスの発表がいくつかありました。AWS ヘルスケアおよびライフサイエンスグローバルテクニカルリーダーの Patrick Combes、および AWS ヘルスケアおよびライフサイエンスパートナーソリューションアーキテクトの Aaron Friedman が、その全貌についてお知らせするためにこの投稿を書いています。

-Ana


ここ数週間の間に、次の AWS のサービスが BAA に追加されたことをお知らせいたします。 Amazon API GatewayAWS Direct ConnectAWS Database Migration ServiceAmazon SQS。これら 4 つのサービスはすべて AWS へのおよび AWS を通じてのデータの移動を容易にするため、お客様がこれらのサービスを使用してヘルスケアにおけるソリューションをどのように促進できるか楽しみです。これらのサービスのそれぞれのユースケースは膨大なので、お客様が Protected Health Information (PHI) でこれらのサービスを使用できるいくつかの方法を取り上げます。

AWS の事業提携の追補 (BAA) の適用を受けるすべての HIPAA の対象サービスと同様に、PHI は、保管時または転送時に暗号化される必要があります。HIPAA のホワイトペーパー を参照することをお勧めします。これは、PHI を保存、処理、および転送するための AWS の HIPAA 対応サービスの設定方法について説明しています。そしてもちろん、PHI に該当しないアプリケーション部分については、90 以上のサービスを使用して、ユーザーに最適なエクスペリエンスを提供することができます。HIPAA のアーキテクチャに関するアイデアは、ウェブサイトでご覧いただけます。

Amazon API Gateway
Amazon API Gateway は、ウェブサービスで、開発者はこれを利用することにより、あらゆる規模で、簡単に API の作成、配布、監視、保護が行えます。PHI を使用して、API Gateway を安全に通過することができるようになりました。患者/プロバイダディレクトリ、患者ダッシュボード、医療機器レポート/テレメトリー、HL7 メッセージ処理などのアプリケーションは、AWS またはクライアントプレゼンテーションレイヤー内で実行している任意の数と種類のアプリケーションに情報を安全に受け入れ配信できます。特に楽しみなのは、ヘルスケア情報を交換するうえで Amazon API Gateway をお客様がどのように活用するかです。Fast Healthcare Interoperability Resources (FHIR) 仕様は、エンティティ間で医療情報を共有する方法に関する次世代の標準となりそうです。RESTful アーキテクチャを強力にサポートすることにより、FHIR は、Amazon API Gateway の API 内で簡単に体系化することができます。FHIR の詳細については、AWS 医療コンピテンシーパートナーである Datica に、優れた入門書があります。

AWS Direct Connect
Johnson & Johnson のような当社のヘルスケアおよびライフサイエンスのお客様の一部は、ハイブリッドアーキテクチャを活用し、オンプレミスインフラストラクチャを AWS クラウドに接続する必要があります。AWS Direct Connect を使用すると、AWS とデータセンター、オフィス、またはコロケーション環境間にプライベート接続を確立することができます。これにより、多くの場合、ネットワークのコスト削減、帯域幅のスループットが向上し、インターネットベースの接続よりも均質なネットワーク体験を提供できます。ハイブリッドアーキテクチャ戦略に加えて、AWS Direct Connect は、AWS への安全なデータ移行を支援することができます。これは Amazon S3 や Amazon EMR など、PHI の保管と処理に HIPAA の対象サービスを幅広く使用するための第一歩です。さらに、サードパーティー/外部でホストされたアプリケーションやパートナー提供のソリューションに接続したり、エンドユーザーをクラウドベースの電子カルテシステムなどの同じヘルスケアアプリケーションに安全かつ確実に接続することができます。

AWS Database Migration Service (DMS)
現在までに、お客様は、AWS Database Migration Service を通じて 20,000 を超えるデータベースを AWS に移行しました。お客様は、クラウド移行戦略の一環として DMS を使用することが多く、今やそれを PHI を含むコアデータベースを安全かつ容易に AWS クラウドに移行するために使用することもできます。DMS を使用した移行中でもソースデータベースは完全に利用可能な状態に保たれるので、データベースを AWS に移行する際に、ビジネスクリティカルなアプリケーションのダウンタイムは最小限に抑えられます。このサービスは、患者ディレクトリ、支払い/トランザクションレコードデータベース、収益管理データベースなどのアイテムを AWS に安全に転送するために利用できるようになりました。

Amazon Simple Queue Service (SQS)
Amazon Simple Queue Service (SQS) は、あらゆる規模での、分散されたソフトウェアコンポーネントおよびマイクロサービス間での信頼性の高い通信のためのメッセージキューイングサービスです。想定されるお客様による PHI での SQS の使用方法は、HL7 または FHIR メッセージをアプリケーションの他の部分に渡すアプリケーションコンポーネント間の要求をバッファすることです。PHI を含むメッセージが、受信した順に渡され、受信した順に配信され、使用者が処理して削除するまで使用できるように、SQS FIFO などの機能を活用できます。これは、病院での患者記録の更新または支払い情報の処理を行うアプリケーションにとって重要です。

では、始めましょう。
ヘルスケアアプリケーションの一環として、新しい HIPAA 対応サービスをお客様がどのように使用されるのか、とても楽しみです。あなたが一番楽しみにしているのはどんな点ですか。下にコメントを残してください。

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…)