Author: AWS Japan Staff


Amazon Rekognitionアップデート – 画像の節度

我々は昨年Amazon Rekognitionを発表し、私のブログポスト(Amazon Rekognition – 深層学習による画像検出と認識)でご紹介しました。その時ご説明した様に、このサービスは毎日数十億枚の画像を何年にも渡って解析を続けている我々のコンピュータビジョンチームによって作られました。

本日、我々はRekognitionに画像の節度の機能を追加致します。もしユーザにプロフィール写真やその他の画像をアップロードさせる様なウェブサイトやアプリケーションをお持ちでしたら、きっとこの新しいRekognitionの機能を気に入って頂けると思います。

Rekognitionはあなたのサイトに不適切な、いやらしさや露骨な内容を含む様な画像を特定することができます。節度ラベルは詳細なサブカテゴリを提供してくれるので、許容できるまたは不快と思う様な画像のフィルタリングを細かくチューニングすることができます。この機能を使って、画像共有サイト、フォーラム、デートアプリ、子供向けコンテンツプラットフォーム、eコマースのプラットフォームやマーケットプレイス等々を改善することができます。

この機能を使うためには、コードからDetectModerationLabrels関数を呼び出します。レスポンスの中には組み込み済みの分類の中からいくつかの節度ラベルが含まれます:

"ModerationLabels": [ 
  {
    "Confidence": 83.55088806152344, 
    "Name": "Suggestive",
    "ParentName": ""
   },
   {
    "Confidence": 83.55088806152344, 
    "Name": "Female Swimwear Or Underwear", 
    "ParentName": "Suggestive" 
   }
 ]

AWS Management Consoleではこの機能を実験するための画像節度デモを使うことができます:

画像の節度は今日からご利用可能です!

Jeff;

原文: Amazon Rekognition Update – Image Moderation (翻訳: SA岩永)

 

AWS サンフランシスコ Summit – 発表とお知らせの概要

私の同僚の多くは、本日の AWS Summit のため、サンフランシスコにいます。メインステージおよび休憩セッションで当社が発表した概要は次のとおりです。

新しいサービス

新たに利用可能

新機能

Jeff;

AWS X-Ray の更新 – Lamba 統合を含む一般提供の開始

AWS X-Ray を最初に紹介したのは AWS re:Invent での「AWS X-Ray – 分散アプリケーションの中を見てみよう (AWS X-Ray – See Inside Your Distributed Application)」というタイトルのブログ投稿でした。AWS X-RayAmazon EC2 インスタンス、Amazon ECS コンテナ、マイクロサービス、AWS データベースサービス、AWS メッセージングサービスをトラバースする実行として、アプリケーションに対して行われたリクエストをトレースできるようにします。これは開発および本番環境用に設計されており、シンプルな 3 層アプリケーションや何千ものマイクロサービスで形成されたアプリケーションを処理することができます。去年公開したブログでも説明しましたが、AWS X-Ray はリクエストのエンドツーエンドのトレースや、代表的なサンプルのトレースセットの記録、サービスのマップ表示、データのトレース、パフォーマンス問題やエラーの分析を行えるようにします。これにより、アプリケーションとその基盤サービスがどのように動作しているか把握することができるため、問題の根本的な原因を識別し対処することができます。詳細については、X-Ray の機能を詳しく説明した過去のブログをご覧ください。AWS X-Ray のプレビューバージョンは re:Invent でリリースし、興味を示した開発者やアーキテクトが使用できるようにご招待しました。本日より、同サービスの一般提供を開始しました。US East (Northern Virginia)US West (Northern California)US East (Ohio)US West (Oregon)Europe (Ireland)Europe (Frankfurt)South America (Brazil)Asia Pacific (Tokyo)Asia Pacific (Seoul)Asia Pacific (Sydney)Asia Pacific (Sydney)Asia Pacific (Mumbai) リージョンで今すぐご利用いただけます。

新しい Lambda 統合 (プレビュー)
本日よりご利用いただけるプレビューバージョンには、先のプレビュー実施時に行ったサービスの微調整と AWS Lambda 統合が含まれています。これにより、Lambda のデベロッパーが AWS X-Ray を使用して関数の実行やパフォーマンスの可視性を得ることが可能になりました。これまでは、Lambda のユーザーがアプリケーションのレイテンシーの詳細やスローダウンの原因を突き止めたい場合、またはタイムアウトをトラブルシュートしたい場合はカスタムロギングや分析に頼る必要がありました。この新しい統合を使用するには、対象となる関数に実行ロールを指定してください。この実行ロールは、関数が X-Ray に書き込むことを許可し、関数をベースにトレースすることを可能にします (コンソールを使用して新しい関数を作成した場合、適切な許可が自動的に指定されます)。次に X-Ray サービスマップを使用して Lambda 関数、EC2 インスタンス、ECS コンテナなどでどのようにリクエストが動作しているか確認します。興味のあるサービスやリソースを識別、拡大、タイミング情報を調査し問題を解決します。Lambda 関数への各呼び出しは 2 つ以上のノードを X-Ray マップで生成します。Lambda サービス – このノードは Lambda で使用した時間を表します。ユーザー関数 – このノードは Lambda 関数の実行時間を表します。ダウンストリームサービスの呼び出し – これらのノードは Lambda 関数による他のサービスへの呼び出しを表します。詳細については「Lambda で X-Ray を使用する (Using X-Ray with Lambda)」をご覧ください。

今すぐ利用可能
X-Ray の使用量に対する料金は 2017 年 5 月 1 日から開始します。料金は記録したトレース数と分析数に基づきます (各トレースはアプリケーションに対して行われたリクエストを表します)。毎月無料で記録できるトレース数は 100,000 件、また 1,000,000 トレースを取得またはスキャンすることができます。それ以上の場合は記録したトレース数 1 万件につき 5 USD、また分析用に取得したトレース数 1 万件につき 0.50 USD が課金されます。詳細は AWS X-Ray 料金表ページをご覧ください。記録済みまたはアクセスしたトレース数を確認するには AWS 請求コンソールをご覧ください (データ収集は 2017 年 3 月 1 日に開始しました)。AWS X-Ray と新しい Lambda 統合をぜひご覧ください。ご感想をお待ちしています!

Jeff;

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

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー 5 月の配信についてご案内させて頂きます。4 月に引き続き、5 月も AWSの基礎となるサービスを中心に開催します。AWS 認定試験の紹介や準備について、ゲーム開発者の方々向けのサービス群のご紹介といった、新しい切り口での開催を行います。

5 月の開催予定

サービスカット

5/10(水) 18:00-19:00 Amazon RDS
5/17(水) 18:00-19:00 Amazon Cognito
5/24(水) 18:00-19:00 EC2 Windows

ソリューションカット

5/11(木) 12:00-13:00 AWS for Game Developers
5/23(火) 12:15-12:45 AWS認定試験準備に向けて

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

発表: Amazon Athena が暗号化されたデータのクエリのサポートを追加

昨年 11 月に、当社は毎日膨大な量のデータに安全にアクセスして調べる必要があるお客様を支援するための重要なステップとなることを期待して、サービスをマーケットに投入しました。このサービスは Amazon Athena にほかなりません。私はこれを、オブジェクトストレージのクエリにより「1 回のジャンプで背の高いクエリを飛び越える」ことを試みるマネージド型サービスであると考えています。AWS のお客様が、Amazon S3 に保存された大量のデータを簡単に分析してクエリを実行できるようにするサービスです。

Amazon Athena は、ユーザーが標準 SQL を使用して Amazon S3 のデータを簡単に分析できるようにする、サーバーレスでインタラクティブなクエリサービスです。Athena の中核となるのは、ANSI SQL のサポートによりクエリを実行する分散 SQL エンジンの Presto と、Athena が CSV、JSON、ORC、Avro、Parquet などのよく使用されるデータ形式に対応できるようにし、create table、drop table、alter table などのよく使用されるデータ定義言語 (DDL) オペレーションを追加する Apache Hive です。Athena は、構造化されたデータ形式および構造化されていないデータ形式で Amazon Simple Storage Service (S3) に保存されたデータセットへのパフォーマンスの高いクエリアクセスを可能にします。Hive 対応 DDL ステートメントと ANSI SQL ステートメントは、AWS マネジメントコンソールから、または Athena JDBC ドライバーをダウンロードして利用することで SQL Workbench などの SQL クライアントから、Athena Query Editor で記述できます。さらに、JDBC ドライバーを使用することで、目的の BI ツールからプログラムでクエリを実行できます。Amazon Athena サービスの詳細については、11 月のサービスリリース時の Jeff のブログ投稿を参照してください。Athena チームは、Amazon Athena サービスの初期の機能をリリースした後で、お客様を中心に考えるという Amazon の伝統に従い、サービスのカスタマーエクスペリエンスを向上させるよう勤勉に努力してきました。これにより、チームは今回発表する機能を追加し、Amazon Athena Amazon S3 での暗号化されたデータのクエリをサポートするようになりました。この新機能により、Athena は Amazon S3 で暗号化されたデータのクエリのサポートを提供できるだけではなく、Athena のクエリ結果からデータの暗号化を可能にします。Amazon S3 に保存された機密データを暗号化する要件または規制がある業種やお客様は、Athena が暗号化されたデータで提供する、サーバーレスな動的クエリを活用できます。  暗号化のサポート Athena の新機能の使用について説明する前に、データの保護と暗号化の必要があるお客様向けに S3 と Athena がサポートする暗号化オプションについて時間をかけて見てみましょう。現在、S3 は AWS Key Management Service (KMS) を使用したデータの暗号化をサポートしています。AWS KMS は、データの暗号化に使用される暗号化キーの作成と管理のためのマネージド型サービスです。さらに、S3 は、お客様による独自の暗号化キーを使用したデータの暗号化をサポートします。S3 に保存されたデータセットに対して Athena がサポートする暗号化オプションを理解することが重要であるため、S3 と Athena でサポートされる暗号化オプションの詳細と、暗号化されたデータアクセスに新しい Athena テーブルプロパティ has_encrypted_data が必要となる場合を、次の表に示します。

AWS KMS または Amazon S3 の暗号化オプションを使用した Amazon S3 の暗号化の詳細については、AWS KMS 開発者ガイドの「Amazon Simple Storage Service (Amazon S3) が AWS KMS を使用する方法」および Amazon S3 開発者ガイドの「暗号化を使用したデータの保護」の情報をそれぞれ参照してください。  暗号化されたデータベースとテーブルの作成とアクセス 前に説明したように、Athena へのアクセス方法はいくつかあります。もちろん、AWS マネジメントコンソールを通じて Athena にアクセスできますが、SQL Workbench などの SQL クライアントや他のビジネスインテリジェンスツールで JDBC ドライバーを使用するオプションもあります。さらに、JDBC ドライバーでは、プログラムによるクエリアクセスもできます。十分に説明したので、データベースといくつかのテーブルを作成し、テーブルからクエリを実行してクエリ結果を暗号化することにより、Athena サービスのこの新機能について詳しく見てみましょう。これらの操作はすべて、Amazon S3 に保存されている暗号化されたデータを使用して行います。初めてサービスにログインすると、次に示すような [Amazon Athena Getting Started] 画面が表示されます。Athena Query Editor に移動するには、[Get Started] ボタンをクリックする必要があります。

Athena Query Editor に移動したので、データベースを作成しましょう。Query Editor を開くときにサンプルデータベースが表示される場合は、[Query Editor] ウィンドウでクエリステートメントの入力を開始してサンプルクエリを消去し、新しいデータベースを作成します。[Query Editor] ウィンドウ内で Hive DDL コマンド CREATE DATABASE <dbname> を発行して、データベース tara_customer_db を作成します。

Query Editor の [Results] タブで、クエリの実行が成功したことの確認が表示されたら、データベースは作成され、ドロップダウンで選択できる状態です。

ここで、ドロップダウンで選択したデータベースを、新しく作成したデータベース tara_customer_db に変更します。 データベースを作成したので、S3 に保存されているデータからテーブルを作成できます。私はさまざまな暗号化タイプでデータを暗号化しなかったため、製品グループが、S3 バケットに保存するサンプルデータファイルを渡してくれました。私が受け取った最初のバッチのサンプルデータは SSE-KMS で暗号化されていて、上記の暗号化テーブルマトリックスで示したように、この暗号化タイプは AWS KMS で管理されたキーによるサーバー側の暗号化です。私は暗号化されたデータのこのセットを、適切に名前を付けた S3 バケットである aws-blog-tew-posts/SSE_KMS_EncryptionData に保存しました。私が受け取った 2 番目のバッチのサンプルデータは CSE-KMS です。この暗号化タイプは AWS を使用したクライアント側の暗号化で、aws-blog-tew-posts/ CSE_KMS_EncryptionData S3 バケットに保存されています。私が受け取った最後のバッチのデータは、古き良きプレーンテキストで、このデータは S3 バケット aws-blog-tew-posts/PlainText_Table に保存しました。

S3 バケットのこのデータは Athena サービスからアクセスすることを覚えておいてください。各バケットとそこに保存されているデータへの Athena によるアクセスを許可するため、データバケットに正しいアクセス権限があることを確認する必要があります。さらに、AWS KMS で暗号化されたデータを操作するには、ユーザーには適切な KMS キーポリシーを含むロールが必要です。KMS で暗号化されたデータを正しく読み取るには、ユーザーには S3、Athena、および KMS にアクセスするための正しいアクセス権限が必要です。S3 と Athena サービスの間で適切なアクセス権限を提供するには、いくつかの方法があります。

  1. ユーザーポリシーを通じてアクセスを許可する
  2. バケットポリシーを通じてアクセスを許可する
  3. バケットポリシーとユーザーポリシーを通じてアクセスを許可する。

Amazon Athena のアクセス権限、Amazon S3 のアクセス権限、またはその両方の詳細については、Athena のドキュメントの「ユーザーおよび Amazon S3 バケットのアクセス権限の設定」を参照してください。S3 バケットでデータの準備と設定ができたので、後は Athena Query Editor に移動して、SSE-KMS 暗号化データから最初の新しいテーブルを作成するだけです。新しいテーブル sse_customerinfo を作成するために使用する DDL コマンドは次のとおりです。

CREATE EXTERNAL TABLE sse_customerinfo( 
  c_custkey INT, 
  c_name STRING, 
  c_address STRING, 
  c_nationkey INT, 
  c_phone STRING, 
  c_acctbal DOUBLE, 
  c_mktsegment STRING, 
  c_comment STRING
  ) 
ROW FORMAT SERDE  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' 
LOCATION  's3://aws-blog-tew-posts/SSE_KMS_EncryptionData';

sse_customerinfo テーブルを作成する DDL コマンドステートメントを Athena Query Editor に入力し、[Run Query] ボタンをクリックします。[Results] タブに、クエリが正常に実行されたことが示され、tara_customer_db データベースで利用できるテーブルの下に、新しいテーブルが表示されます。

このプロセスを繰り返して、CSE-KMS で暗号化されたデータのバッチから cse_customerinfo テーブルを作成し、S3 バケットに保存されている暗号化されていないデータソースから plain_customerinfo テーブルを作成します。cse_customerinfo テーブルを作成するために使用する DDL ステートメントは次のとおりです。

CREATE EXTERNAL TABLE cse_customerinfo (
  c_custkey INT, 
  c_name STRING, 
  c_address STRING, 
  c_nationkey INT, 
  c_phone STRING, 
  c_acctbal DOUBLE, 
  c_mktsegment STRING, 
  c_comment STRING
)
ROW FORMAT SERDE   'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION   's3://aws-blog-tew-posts/CSE_KMS_EncryptionData'
TBLPROPERTIES ('has_encrypted_data'='true');

ここでも、Athena Query Editor に上記の DDL ステートメントを入力し、[Run Query] ボタンをクリックします。cse_customerinfo テーブルの作成に使用された DDL ステートメントを注意深く確認すると、新しいテーブルプロパティ (TBLPROPERTIES) フラグ has_encrypted_data が、新しい Athena 暗号化機能に導入されたことがわかります。このフラグは、指定されたテーブルのクエリに使用する S3 のデータは暗号化されたデータであることを Athena に指定するために使用します。時間を取って、Athena と S3 暗号化オプションについて前に確認した暗号化マトリックステーブルをもう一度参照してください。このフラグが必要なのは、[Client-Side Encryption with AWS KMS–Managed Keys] オプションを使用するときだけであることがわかります。cse_customerinfo テーブルが正しく作成されると、の記号がテーブルの横に表示され、テーブルは暗号化されたデータテーブルであることが識別されます。

最後に、サンプルデータから最後のテーブル plain_customerinfo を作成します。前のテーブルに対して実行したのと同じステップです。このテーブルの DDL コマンドは次のとおりです。

CREATE EXTERNAL TABLE plain_customerinfo(
  c_custkey INT, 
  c_name STRING, 
  c_address STRING, 
  c_nationkey INT, 
  c_phone STRING, 
  c_acctbal DOUBLE, 
  c_mktsegment STRING, 
  c_comment STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION 's3://aws-blog-tew-posts/PlainText_Table';


よくできました。Athena を使用して S3 から暗号化されたデータを正常に読み取り、暗号化されたデータに基づいてテーブルを作成しました。ここで、新しく作成した、暗号化されたデータテーブルに対してクエリを実行できます。  クエリの実行 新しいデータベーステーブルに対するクエリの実行は、非常に簡単です。ここでも、一般的な DDL ステートメントやコマンドを使用して、Amazon S3 に保存されたデータに対してクエリを作成できます。クエリの確認のため、Athena のデータのプレビュー機能を使用します。テーブルの一覧で、テーブルの横に 2 つのアイコンが表示されます。1 つのアイコンはテーブルプロパティアイコンで、これを選択すると、選択されたテーブルプロパティが表示されます。もう 1 つのアイコンはの記号で表示され、テーブル用の単純な SELECT クエリステートメントを生成するデータのプレビュー機能です。

  Athena を使用したクエリの実行を紹介するため、テーブルの横にある目のアイコンを選択して、plain_customerinfo のデータのプレビューを選択しました。データのプレビュー機能により、次の DDL ステートメントが作成されます。

SELECT * FROM plain_customerinfo limit 10;

plain_customerinfo テーブルでデータのプレビュー機能を使用したクエリ結果が、Athena Query Editor の [Results] タブに表示され、オプションでファイルアイコンをクリックすると、クエリ結果をダウンロードできます。

Athena の新しい暗号化されたデータ機能では、クエリ結果の暗号化と、結果の Amazon S3 への保存もサポートされます。クエリ結果でこの機能を活用するため、クエリデータを暗号化し、選択したバケットに保存します。現在、選択したデータテーブルは暗号化されていません。最初に Athena の [Settings] メニューを選択し、クエリ結果の現在のストレージ設定を確認します。暗号化に使用する KMS キーがないため、[Create KMS key] ハイパーリンクを選択し、クエリ結果を Athena と S3 で暗号化するために使用する KMS キーを作成します。KMS キーを作成し、適切なユーザーアクセス権限を設定する方法の詳細については、http://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html を参照してください。

s3encryptathena KMS キーを正しく作成し、Athena 設定で使用するキー ARN をコピーしたら、Athena コンソールの [Settings] ダイアログに戻り、[Encrypt query results] テキストボックスを選択します。次に、[Query result location] テキストボックスを更新し、s3 バケット aws-athena-encrypted を指します。これは暗号化されたクエリ結果を保存する場所となります。残っている唯一のことは、暗号化タイプの選択と KMS キーの入力です。これを行うには、[Encryption key] ドロップダウンから s3encryptathena キーを選択するか、[KMS key ARN] テキストボックスに ARN を入力します。この例では、暗号化タイプに SSE-KMS を使用するよう選択しました。以下で、KMS キーを選択する両方の例を参照できます。[Save] ボタンをクリックすると、プロセスが完了します。

ここで、plain_customerinfo テーブルの現在のクエリを再実行します。このテーブルは暗号化されていませんが、クエリ結果に暗号化を追加するために行われた Athena の設定変更により、このテーブルに対して実行されたクエリ結果が、KMS キーを使用して SSE-KMS 暗号化により保存されるようにしました。

再実行の後で Amazon S3 コンソールに移動し、指定したバケット aws-athena-encrypted に保存した CSV データファイルと、バケットおよびファイルの SSE-KMS 暗号化を表示すると、作業の成果を確認できます。

 

概要 言うまでもなく、この Athena の発表には、暗号化によりデータを保護しながら、さまざまなデータ形式で保存されているデータのクエリと分析を実行する機能を維持したいお客様にとって複数の利点があります。さらに、このリリースにはこのブログ投稿で説明しなかった機能強化が含まれています。

  • 新しい暗号化機能とキーの更新をサポートする、JDBC ドライバーの新しいバージョン
  • ALTER TABLE を使用して列を追加、置換、変更する機能の追加。
  • LZO 圧縮データのクエリのサポートの追加。

詳細については、Athena ユーザーガイドのリリースドキュメントを参照してください。また、Athena ドキュメントの「暗号化オプションの設定」セクションを参照し、Amazon S3 に保存された暗号化されたデータのクエリを、Athena を利用して開始してください。AthenaAmazon S3 でのサーバーレスクエリの詳細については、Athena 製品ページを参照するか、Athena ユーザーガイドを確認してください。さらに、Athena の機能および S3 を使用したデータの暗号化の詳細については、AWS ビッグデータのブログ投稿「Amazon Athena を使用した S3 のデータの分析」および AWS KMS 開発者ガイドを参照できます。それでは、暗号化をご活用ください。- Tara

AWS Partner Network(APN) テクノロジーパートナー ATADATA: SAP on AWS移行時の強力な手助け

AWSパートナープログラム部門にてマイグレーション領域のグローバルプログラムリードを務めるKalpan Ravalによる記事です。

多くのエンタープライズのお客様は、AWSサービスの活用によりビジネスのイノベーションを促進し、以前よりもっと安全に環境を構築し、技術的負債を捨て、コストを削減しています。その結果、さらにお客様がAWSに移行しようとし、高度に自動化された移行作業の数が増えています。実績に基づく経験と高品質なツールを使用してリスクを軽減し、主要なワークロードの移行の実現を支援するために、お客様はますますAWS移行コンピテンシーパートナーを頼みにしていることが分かっています。

SAP環境は多くの場合に複雑であり、多くのビジネスワークフローにおいて中心的な役割を果たします。SAPワークロードのある様々なインフラストラクチャタイプによっては、さらに複雑さが増します。x86の観点からは、仮想マシンと物理マシンの両方でWindowsとLinuxのワークロードがあり、大量のCPUコアとRAMが実行されます。加えて、Oracle、SQL Server、またはSAP HANAなどのトランザクション性の高いデータベース用に数十台のディスクドライブもあります。ミッションクリティカルなSAPワークロードを移行する場合、その方法とベンダーを慎重に選択する必要があるという結論が導かれます。私たちは、SAP on AWSを評価いただくために参考となる多くのリソースを提供しています。また、AWS移行コンピテンシーパートナーのページとSAPコンピテンシーパートナーのページから、支援依頼が可能なAPNパートナーのリストをご覧ください。今日は、私たちのAPNアドバンスドテクノロジーパートナーで移行コンピテンシーを取得しているATADATA(アタデータ)について少しお話しし、同社のプラットフォームを使用してSAPワークロードをAWSに移行する方法を説明します。

大規模なSAPワークロードの移行

ATADATAには、SAPを含む大規模なエンタープライズワークロードの移行を可能にする総合的なプラットフォームとして機能する複数のエージェントレスな自動化モジュールがあります。これらのモジュールは、自動的なライブマイグレーションだけでなく、ディスカバリー、アプリケーションのマッピング、コスト予測、移動グループの作成と有効化、移行するワークロードの同期化のために、個別に、または統合製品として使用できます。総合的な移行プラットフォームであることに加えて、ソリューションセットは迅速に導入でき、完全に自己完結しており、エンタープライズ環境向けに設計されています。

自動化された移行の有効化と実行に必要な典型的なワークフロー:

 

    • ATAvisionディスカバリーモジュールによるアプリケーションの検出とマッピング

ディスカバリーと計画策定は、あらゆる移行において不可欠なフェーズです。アプリケーション全体を移行、あるいは変換することを目的とするかどうかに関わらず、対象領域の地図なしではプロジェクトの効率性とタイムラインが失われるでしょう。これは、SAPの移行において非常に重要です。SAPは非常に複雑で、多くのモジュールでは、接続先はオンプレミス環境の外に広がる複雑なサプライチェーンにまたがる多数のエンドポイントにまで及び、ビジネスラインに影響を及ぼす可能性があります。これらの依存関係を把握することは、どのサーバーを一緒に移動する必要があるのか​​、そのインフラストラクチャの依存関係を理解し​​、最も影響の少なく都合のよい移行時期を知る上で非常に重要です。

ATADATAプラットフォームが持つエージェントレスのATAvisionモジュールを使用することで、移行を最適にできるようSAPの依存関係が検出されます。移行アーキテクトは、相互に依存し合うアプリケーションとサーバーが密接に結びついているかどうかを知る必要があります。ATAvisionは、この目的のために設計されており、組み込まれたインテリジェンス機能を使用してアプリケーション通信によって関連するインフラストラクチャをグループ化します。

    • ATAvisionディスカバリーモジュールによる移行の移動グループの作成とコスト予測

ATAvisionは、移行の移動グループとそれを組み込んだ段階計画を策定するために必要な情報を提供するよう開発されました。ATAvisionは、スプレッドシートを手動で作業し、ピボットテーブルを使用してサーバーを移動グループに結びつける移行アーキテクトもまだありますが、SAPなどのシステムで特に役立つ移動グループの自動作成ができるようになりました。

ルールを定義するだけで、ロジックが引き継がれます。自動的な移動グループテクノロジーがもたらすインテリジェンスとスピードにより、膨大な作業時間を節約し、スプレッドシートに頼っていたときの人為的ミスのリスクを軽減できます。

さらに、移行前に、クライアントおよびアプリケーションチームは、個々の移動グループごとのAWS使用量を予測したり、収集された属性の数をフィルタリングしたりすることができます。

    • ATAmotion移行モジュールを使用したポイント・ツー・ポイントの移行とAWSへの同期

ATAmotionはATADATAのコア製品であり、独自のマルチスレッドクローンエンジンと高度なAWS APIとの統合ポイントによって可能になる、大規模なエンタープライズワークロードを移行するという使命を持って開発された堅牢なアーキテクチャを備えています。

ATAmotionのポイント・ツー・ポイントの定義とはどういうことでしょうか?データは中間ステージやイメージライブラリー、ストレージバケットを経由せずにソースマシンからVPC内で指定されたクライアントサブネットにあるAmazon Elastic Compute Cloud(Amazon EC2)上のターゲットインスタンスに直接流れます。このアーキテクチャでは、基盤となるOSやデータベースの種類に関係なく、数多くの稼働中のSAPワークロードの移行を同時にサポートできるため、複雑なSAP環境の場合でも移行期間を数週間から数時間に短縮できる可能性があります。

ATAmotionは、Windows Serverのバージョン2003 32bitから2016まで、Red Hat Enterprise Linux、SuSE Enterprise Linux、Debian、OpenSuSE、CentOS、Oracle Linux、Amazon Linux、Fedora、Ubuntuといったすべての一般的なLinuxディストリビューションをサポートしています。あらゆるクラウド環境またはオンプレミス環境からAWS(米国) GovCloudリージョンを含むすべてのAWSリージョンへの移行、あるいはリージョン間の移行をサポートしています。移行が大陸をまたがったり低帯域幅の場合、ATAmotionはコピーの遅延または中断を監視し、データコピーを正常に完了させる最も効果的な方法を見つけます。

ATAmotionソフトウェアは、サポートされているWindows / Linuxのいずれかで実行中のデータ集約型のSAPアプリケーションを、実質的にダウンタイムなしで移行することができます。これは主に、ATAmotionはクライアントホストのCPU使用率が非常に低く、数MBのメモリしか消費しないため、このような低いリソース使用率のおかげでサービスを中断しないからです。そして、ATAmotionはすべてのファイルシステムを移行します。オペレーティングシステムとそのデータがいくつかのLVM論理ボリュームと物理ボリュームに分割されているかどうかは関係なく、固定パーティションを使用して100個のディスクに格納されている場合であっても、ツールがターゲットサーバ上に同じデバイス構造を再作成するため同じままの構成になります。

さらに、その構造に基づいてデータを移動するための適切な方法を選択するインテリジェンス機能があります。データがファイルシステムに格納されている場合、ファイルベースのコピーアルゴリズムを使用してデータがコピーされます。しかし、ファイルシステムが存在しないデータベースの一般的なシナリオであるRAWデバイスに格納されている場合は、ブロックコピーアルゴリズムを使用してデータがコピーされます。

最後に、ATAmotionには、複数の自動化された同期手法が組み込まれているため、カットオーバー前、カットオーバー中に様々なカットオーバー戦略が取れます。

SAP on AWS移行時におけるATADATAプラットフォームのメリット

  • 単一のベンダー管理で、エンド・ツー・エンドのシームレスなAWS移行が可能になる
  • 検証済みのAWS移行パートナーソリューションによりリスクを削減し、SAPワークロードをAWSに移行できる
  • AWSへの移行を開始する前に既存のSAP環境を完全に把握できる
  • 数十のSAPワークロードを同時に移行するような予定を早められる(数週間ではなく数時間で検討)
  • レガシーなメソドロジーとテクノロジーに伴うコストの削減と人的ミスの軽減ができる
  • AWSへの旅の一環として高度な自動化を活用できる
  • リソース集中型のオンプレミスハードウェアを廃止できる

もしあなたが既存のSAPワークロードのAWS移行を検討しているエンタープライズのお客様またはサービスプロバイダーでしたら、今すぐATADATAの自動化と明確な専門技術を活用することができます。ATADATAの詳細については、www.atadata.com/awsをご覧ください。


このブログの内容や意見は著者のものであり、第三者の製品を保証するものではありません。AWSはこの記事の内容や正確さについての責任は負いません。

 

翻訳はPartner SA 河原が担当しました。原文はこちらです。

マネージメントコンソールからも、既存のEC2インスタンスにIAMロールを簡単にアタッチ、変更できるようになりました

AWS Identity and Access Management(IAM)ロールを利用すると、Amazon EC2上で動作するアプリケーションは一時的なセキュリティ資格を使用することにより安全に稼働することができます。また、アプリケーションが使用するAWSセキュリティ資格情報を利用者が管理する必要がないため、アプリケーションがインスタンスから安全にAPIリクエストが発行できます。先日、AWS CLI, AWS SDKを使用し、既存のEC2インスタンスにIAMロールを付加することで、アプリケーションに一時的なセキュリティ資格情報を使用できるようになりました。詳細は、「既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました」を確認下さい。

そして今日から、EC2コンソール(マネージメント コンソール)からも、既存のEC2インスタンスにIAMロールをアタッチできるようになりました。 EC2コンソールを使用して、既存のインスタンスにアタッチされたIAMロールを置き換えることもできます。 このブログ記事では、EC2コンソールから既存のEC2インスタンスにIAMロールを割り当てる方法を示します。

EC2コンソールから、既存のEC2インスタンスにIAMロールをアタッチする

EC2コンソールから既存のEC2インスタンスにIAMロールを添付するには:

1. EC2コンソールに移動します

2. ナビゲーションペインでInstancesを選択します。

RRI-1-A-finala 3. IAMロールをアタッチするインスタンスを選択します。 IAMロールがまだアタッチされていないことを確認するには、インスタンスの[Description]タブのIAMロールの値が空であることを確認します。

RRI-2-A

4. [Actions]を選択し、[Instance Settings]を選択して、ドロップダウンリストから[IAMロールのアタッチ/置換]を選択します。

RRI-3

5. [Attach / Replace IAM role]ページから、添付するロール(この例ではEC2Role1を選択します)をドロップダウンリストから選択します。

RRI-4

注意:”Create new IAM role (新しいIAMロールの作成)”を選択することで、新しいロールを作成することもできます。 詳細については、「IAMコンソールを使用してIAMロールを作成するには」を参照してください。

6. IAMロールを選択したら、「Apply」を選択して次のステップに進みます。

RRI-6-A-final

私の場合、次のスクリーンショットに示すように、IAMの役割はEC2インスタンスに正常にアタッチされました。

ロールが目的のEC2インスタンスに関連付けられていることを確認するには、インスタンスの詳細ページに移動します。次のスクリーンショットのようにEC2Role1がIAMロールであることが確認できます。

RRI-7

この投稿に関するコメントがある方は、下記の「コメント」セクションに投稿頂きますと助かります。 ご質問やご提案がありましたら、IAMフォーラムの新しいスレッドからお問い合わせください。

– Mari

翻訳はPartner SA 酒徳が担当しました。原文はこちらです。

Amazon AppStream 2.0でデスクトップアプリケーションのストリームをスケールする


Deepak Sury, Principal Product Manager – Amazon AppStream 2.0

デスクトップアプリケーションを書き換えることなくWebブラウザにストリーミングしたいですか?Amazon AppStream 2.0はフルマネージドの、セキュアなアプリケーションストリーミングサービスです。このサービスでなにができるかを知るためのかんたんな方法はエンドユーザーエクスペリエンスを無料で試してみることです。

この記事では、AppStream 2.0環境をスケールさせて、コストを最適化する方法について解説します。さらにセットアップとモニタリングについていくつか付け加えます。

AppStream 2.0 ワークフロー

Image Builderを使用して自分のアプリケーションをAppStream 2.0にインポートします。Image BuilderでAWS Management Consoleからデスクトップエクスペリエンスに接続して、自分のアプリをインストールしてテストすることができます。そして、Image Builderのスナップショットとしてイメージを作成します。

アプリケーションをふくむイメージを作成したあと、インスタンスタイプを選択してストリーミングインスタンスのフリートを起動します。フリートのそれぞれのインスタンスは1ユーザーだけで使用され、フリートで使用されるインスタンスタイプがアプリケーションパフォーマンスによる必要と適合するようにします。最後に、フリートをスタックにアタッチしてユーザーアクセスをセットアップします。以下の図はワークフローのなかでのそれぞれのリソースの役割を示しています。

図1: AppStream 2.0のワークフローを記述

appstreamscaling_1.png

AppStream 2.0のセットアップ

使いはじめるためには、コンソールのクイックリンクからサンプルのAppStream 2.0スタックをセットアップします。このサンプルでは、スタックにds-sampleという名前を付け、サンプルイメージを選択して、stream.standard.mediumインスタンスタイプを選んでいます。セットアップしたリソースはAWSコンソールまたは、以下のようにdescribe-stacksやdescribe-fleetsを使用して確認することができます:

図2: AppStream 2.0スタックの確認

appstreamscaling_1.png

図3: AppStream 2.0フリートの確認

appstreamscaling_2.43%20AM

ストリーミング環境へのユーザーアクセスをセットアップするには、既存のSAML 2.0準拠のディレクトリを使用することができます。ユーザーは既存の認証情報を使用してログインすることができます。別のやり方として、クイックにストリーミング接続をテスト、または自分のWebサイトからストリーミングセッションをスタートするには、ストリーミングURLを作成することができます。コンソールで、Stacks、Actions、Create URLを選択するか、以下のようにcreate-streaming-urlを呼び出します:

図4: ストリーミングURLの作成

appstreamscaling_3.png

ブラウザにストリーミングURLをペーストして、表示されたアプリケーションを開くことができます。

appstreamscaling_4.30%20PM

これでサンプル環境のセットアップができましたので、スケーリングに移りましょう。

AppStream 2.0のスケーリングとコスト最適化

インスタントオンのストリーミング接続を提供するために、AppStream 2.0フリートのインスタンスは常時稼働しています。稼働中のインスタンスに課金され、それぞれの稼働中のインスタンスは同時に1ユーザーのみを受け付けます。コストを最適化するには、インスタンスの稼働台数を同時にアプリをストリーミングしたいユーザー数にあわせます。このセクションではそのための3つのオプションを紹介していきます:

  • フリートのオートスケーリング
  • スケジュールをベースにした固定フリート
  • スケジュールによるフリートのオートスケーリング

フリートのオートスケーリング

インスタンスの稼働台数を動的に更新するには、フリートのオートスケーリングを使用することができます。この機能はフリートのサイズを自動的に最小値と最大値の間でオンデマンドにスケールさせることができます。これはコンスタントにユーザーの需要が変動し、需要に応じてフリートを自動的にスケールさせたい場合に便利です。スケーリングポリシーのセットアップと管理の方法については、Fleet Auto Scalingを参照してください。

フリートへの変更はAmazon CloudWatchメトリクスを利用してトリガすることができます:

  • CapacityUtilization – すでに使用されている稼働中のインスタンスのパーセンテージ
  • AvailableCapacity – 未使用でユーザーからの接続を受け付けることができるインスタンスの台数
  • InsufficientCapacityError – ユーザーのリクエストに応答できる稼働中のインスタンスが存在しないときにトリガされるエラー

AWS SDKまたはAWSマネージメントコンソールを使用してスケーリングポリシーの作成とアタッチができます。コンソールを使用してポリシーをセットアップするのが便利です。以下のステップになります:

  1. AWSマネージメントコンソールで、AppStream 2.0を開きます。
  2. Fleetを選んで、フリートを選択し、Scaling Policiesを選びます。
  3. Minimum capacityMaximum capacityで、フリートの値を入力します。

図5: スケーリングポリシーを設定するフリートタブ

appstreamscaling_5.png

  1. それぞれのセクションでAdd Policyを選んでスケールアウトとスケールインポリシーを作成します。

図6: スケールアウトポリシーの追加

appstreamscaling_6.png

図7: スケールインポリシーの追加

appstreamscaling_7.png

ポリシーを作成した後、フリートの詳細の一部として表示されます。

appstreamscaling_8.png

スケーリングポリシーはCloudWatchアラームによってトリガーされます。このアラームはコンソールを使用してスケーリングポリシーを作成したときに自動的に作成されます。CloudWatchコンソールからアラームの確認と変更ができます。

図8: フリートをスケーリングするためのCloudWatchアラーム

appstreamscaling_9.png

スケジュールをベースにした固定フリート

コストを最適化して予測可能な需要に対応するための別のやり方は時刻または曜日にもとづいて稼働するインスタンスの台数を固定することです。これはトレーニングクラス、コールセンターのシフト、学校のコンピュータラボなどのシナリオで異なる時刻に固定されたユーザー数がサインインする場合に便利です。AppStream 2.0のupdate-fleetコマンドを使用して稼働中のインスタンス数をかんたんに設定することができます。フリートのコンピュートキャパシティを希望する値にアップデートしてください。稼働中のインスタンス数は、以下のように設定した希望する値に応じて変動します:

図9: フリートの希望するキャパシティをアップデート

appstreamscaling_10.png

自動的にフリートサイズをアップデートするLambdaファンクションをセットアップします。以下の例にしたがって自分のファンクションをセットアップします。以前にLambdaを使用したことがない場合は、Step 2: Create a HelloWorld Lambda Function and Explore the Consoleを参照してください。

フリートサイズを変更するファンクションを作成するには

  1. Lambdaコンソールで、 Create a Lambda functionを選択します。
  2. Blank Functionブループリントを選択します。これは自分のコードを追加することができる空のブループリントを作成します。
  3. 今回はトリガーセクションをスキップします。あとで、時間を、または別のインプットをベースにしたトリガーを追加できます。
  4. Configure functionセクションでは:
    1. 名前と説明を入力します。
    2. Runtimeでは、Node.js 4.3を選択します。
    3. Lambda function handler and roleで、Create a custom roleを選択します。
    4. IAMウィザードで、例えばLambda-AppStream-Adminのようにロール名を入力します。デフォルトのままにします。
    5. IAMロールが作成されたあと、”AmazonAppStreamFullAccess”というAppStream 2.0のマネージドポリシーをロールにアタッチします。より詳細な情報は、Working with Managed Policiesを参照してください。これによりLambdaがあなたのかわりにAppStream 2.0 APIをコールすることができます。くわしくは、Controlling Access to Amazon AppStream 2.0を参照してください。
    6. のこりのフィールドではデフォルト値のままNext, Create functionを選択します。
  5. AppStream 2.0のフリートサイズを変更するには、Codeを選択して以下のようにサンプルコードを追加します:
    JavaScript
    'use strict';
    
    /** This AppStream2 Update-Fleet blueprint sets up a schedule for a streaming fleet **/
    
    const AWS = require('aws-sdk');
    const appstream = new AWS.AppStream();
    const fleetParams = {
      Name: 'ds-sample-fleet', /* required */
      ComputeCapacity: {
        DesiredInstances: 1 /* required */
    
      }
    };
    
    exports.handler = (event, context, callback) => {
        console.log('Received event:', JSON.stringify(event, null, 2));
    
        var resource = event.resources[0];
        var increase = resource.includes('weekday-9am-increase-capacity')
    
        try {
            if (increase) {
                fleetParams.ComputeCapacity.DesiredInstances = 3
            } else {
                fleetParams.ComputeCapacity.DesiredInstances = 1
            }
            appstream.updateFleet(fleetParams, (error, data) => {
                if (error) {
                    console.log(error, error.stack);
                    return callback(error);
                }
                console.log(data);
                return callback(null, data);
            });
        } catch (error) {
            console.log('Caught Error: ', error);
            callback(error);
        }
    };
  6. コードをテストします。Testを選択して”Hello World”テストテンプレートを使用します。はじめてこれを実行するには、Save and Testを選択します。以下のようにスケーリングのアップデートをトリガーするテストインプットを作成します。appstreamscaling_11.png
  7. update-fleetコールの結果がアウトプットのテキストとして表示されます。CLIを使用してLambdaファンクションの実行結果を確認することもできます。

つぎに、タイムベーススケジュールをセットアップするために、Lambdaファンクションを呼び出すトリガーをセットします。

Lambdaファンクションのトリガーをセットするには

  1. Triggers, Add triggerを選択します。
  2. CloudWatch Events – Scheduleを選択します。
  3. Schedule expressionでは、cronを選択します。cronの値はあとで編集することができます。
  4. トリガーが作成された後、weekday-9am-increase-capacityのイベントを開きます。
  5. CloudWatchコンソールで、イベントの詳細を編集します。平日の午前8時にフリートをスケールアウトするには、時間を00 17 ? * MON-FRI *になるように調整します。(シアトル(太平洋時間)ではない場合は、それぞれのタイムゾーンに変更してください)
  6. 平日の終わりにトリガーする別のイベントを追加することもできます。

appstreamscaling_12.png

これでセットしたスケジュール時刻に合わせて自動的にスケールアウトとスケールインするトリガーをセットアップしました。

スケジュールでのフリートのオートスケーリング

もっと複雑なシナリオをマネージするためにフリートスケーリングと時間ベースのスケジュールのアプローチを組み合わせて使用することができます。これは業務時間と業務時間外とで稼働するインスタンス数をマネージしながら需要の変更に対応するのに便利です。時刻または日付に基づいてフリートの最小および最大サイズをプログラムから変更し、デフォルトのスケールアウトおよびスケールインポリシーを適用することができます。これによってスケジュールをベースにした予測可能な最小の需要に応答することができます。

たとえば、平日のはじめに、同時に一定数のユーザーがストリーミング接続をリクエストすることが予測されます。フリートがスケールアウトして要求を満たすまで待っていたくはありません。しかしながら、一日のうちに、需要がスケールインまたはアウトすることが予測され、フリートのサイズを需要に合わせたいと思います。

これを実現するには、コンソールからスケーリングポリシーをセットアップして、スケジュールをベースにフリートの最小、最大および希望するキャパシティの変更をトリガーするLambdaファンクションを作成します。以前作成したLambdaファンクションのコードを以下のようなコードで置き換えます:

JavaScript
'use strict';

/** This AppStream2 Update-Fleet function sets up a schedule for a streaming fleet **/

const AWS = require('aws-sdk');
const appstream = new AWS.AppStream();
const applicationAutoScaling = new AWS.ApplicationAutoScaling();

const fleetParams = {
  Name: 'ds-sample-fleet', /* required */
  ComputeCapacity: {
    DesiredInstances: 1 /* required */
  }
};

var scalingParams = {
  ResourceId: 'fleet/ds-sample-fleet', /* required - fleet name*/
  ScalableDimension: 'appstream:fleet:DesiredCapacity', /* required */
  ServiceNamespace: 'appstream', /* required */
  MaxCapacity: 1,
  MinCapacity: 6,
  RoleARN: 'arn:aws:iam::659382443255:role/service-role/ApplicationAutoScalingForAmazonAppStreamAccess'
};

exports.handler = (event, context, callback) => {
    
    console.log('Received this event now:', JSON.stringify(event, null, 2));
    
    var resource = event.resources[0];
    var increase = resource.includes('weekday-9am-increase-capacity')

    try {
        if (increase) {
            //usage during business hours - start at capacity of 10 and scale
            //if required. This implies at least 10 users can connect instantly. 
            //More users can connect as the scaling policy triggers addition of
            //more instances. Maximum cap is 20 instances - fleet will not scale
            //beyond 20. This is the cap for number of users.
            fleetParams.ComputeCapacity.DesiredInstances = 10
            scalingParams.MinCapacity = 10
            scalingParams.MaxCapacity = 20
        } else {
            //usage during non-business hours - start at capacity of 1 and scale
            //if required. This implies only 1 user can connect instantly. 
            //More users can connect as the scaling policy triggers addition of
            //more instances. 
            fleetParams.ComputeCapacity.DesiredInstances = 1
            scalingParams.MinCapacity = 1
            scalingParams.MaxCapacity = 10
        }
        
        //Update minimum and maximum capacity used by the scaling policies
        applicationAutoScaling.registerScalableTarget(scalingParams, (error, data) => {
             if (error) console.log(error, error.stack); 
             else console.log(data);                     
            });
            
        //Update the desired capacity for the fleet. This sets 
        //the number of running instances to desired number of instances
        appstream.updateFleet(fleetParams, (error, data) => {
            if (error) {
                console.log(error, error.stack);
                return callback(error);
            }

            console.log(data);
            return callback(null, data);
        });
            
    } catch (error) {
        console.log('Caught Error: ', error);
        callback(error);
    }
};

注:このコードを実行するには、Lambdaファンクションで使用されるロールにIAMポリシーを追加する必要があります。このポリシーによってLambdaがあなたのかわりにアプリケーションオートスケーリングサービスを呼び出すことができます。

図10: Lambdaでアプリケーションオートスケーリングを使用するインラインポリシー

{
"Version": "2012-10-17",
"Statement": [
   {
      "Effect": "Allow", 
         "Action": [
            "iam:PassRole"
         ],
         "Resource": "*"
   }
]
}
{
"Version": "2012-10-17",
"Statement": [
   {
      "Effect": "Allow", 
         "Action": [
            "application-autoscaling:*"
         ],
         "Resource": "*"
   }
]
}

利用状況のモニタリング

フリートのスケーリングをセットアップした後、AppStream 2.0でCloudWatchメトリクスを使用して、モニタリングのためのダッシュボードを作成することができます。これは確認した利用量をもとに時間ベースのスケーリングポリシーを最適化するのに役立ちます。

例えば、初期セットアップが非常に保守的でリソースをオーバープロビジョンしていたら、フリートの利用率が低い状態が長く続くでしょう。一方で、フリートサイズが小さすぎる場合、高利用率またはユーザーの接続をブロックしているキャパシティ不足のエラーがみられるでしょう。最大15ヶ月までCloudWatchメトリクスを確認してフリートスケーリングポリシーを調整することができます。

図11: カスタムAmazon CloudWatchメトリクスのダッシュボード

appstreamscaling_13.53%20PM

まとめ

これらはAppStream 2.0をスケーリングしてコストを最適化するためのいくつかのアイデアです。これが役に立ち、同様の記事を観たいと思ったらお知らせください。サービスに関してコメントがあれば、AWS forum for AppStream 2.0にフィードバックを投稿してください。

翻訳は渡邉が担当しました。原文はこちら

New – AWS マネジメントツールのブログ

過去数年で AWS ブログのコレクションが拡大しました。右側のリストをご覧になれば分かるように、現在では実に幅広い様々なトピックや開発ツールに関するブログをご提供しています。また英語以外の言語でも、AWS ブログをご覧いただくことができます。コレクションに最近追加されたブログは AWS Management Tools Blog です。このブログでは AWS ツールを取り上げ、ユーザーがプロビジョン、設定、モニタリング、トラックのサポートや AWS のコスト管理、大規模なオンプレミスリソースの管理について説明しています。今後ブログで紹介予定のトピックには、機能の更新に関する技術的な詳細情報、ヒントやトリック、サンプルアプリ、CloudFormation テンプレート、ユースケースのディスカッションなども含まれています。ブログ開始当初の投稿をいくつか以下にご紹介します。

こうした便利な内容をお届けするコンテンツを毎回見逃さないようにするには、ブログの RSS フィードへの登録をご検討ください。

Jeff;

Pollexy – Amazon Polly と Raspberry Pi で構築した特別なニーズをサポートする音声アシスタント

4 月は Autism Awareness month (自閉症啓発月間) です。米国では 68 人中に 1 人の子供が自閉症スペクトラム障害 (ASD) と診断されています (2014 年 CDC 調査)。 今回のブログでは AWS のシニア DevOps クラウドアーキテクトの Troy Larson が、息子の Calvin をサポートするために取り組んでいるプロジェクトについて紹介します。これまでにも、AWS がどのようにしてこれほどたくさんの様々なアイデアを出し合えるのか聞かれたことがあります。場合によっては、とても個人的な理由で大切な誰かの役に立ちたいという願いからアイデアが浮かぶこともあるのですが、この Pollexy はまさにその例です。まずは Pollexy に関する記事を読んでから、こちらの動画をご覧ください。 -Ana


背景

私はここ何年もの間、自閉症で会話の少ない 16 歳のティーンエイジャーの親であるコンピュータプログラマーとして、どうにかテクノロジーを使ってより安全で幸せかつ快適な暮らしをつくることができないかと常に模索していました。このプロジェクトのチャレンジとなる根源は、人との交流におけるすべての基本、つまりコミュニケーションです。息子の Calvin は口頭による指示には反応しますが、責任を持って発言することができません。彼のこれまでの人生において、私達が会話をしたことは一度もないのです。自分の部屋で一人で遊んでいることはできても、すべてのタスクや一連のタスクをこなすには、他の誰かが口頭で彼に促す必要があります。我が家には他にも子供がおり、家庭内で担当するその他の役割もありますから、Calvin にかかりっきりになることで家庭内の雰囲気に負の影響が出てしまうことも否めません。

事の発端

去年開催された re:Invent で Amazon PollyAmazon Lex のことを初めて耳にしてから、すぐにこうした技術を活用してどのように息子をサポートできるか考え始めました。息子は人による口頭指示に対しては問題なく対応することができますが、デジタル音声を理解することはできるのだろうか? という疑問がありました。そこで、ある土曜日に Raspberry Pi を息子の部屋に設定し、ドアを閉め、息子に気付かれないように家族と一緒に様子をうかがってみることにしました。Raspberry Pi に接続し、聞き慣れた西海岸の発音による Joanna を選び Polly を介して息子に問いかけてみました。「Calvin、トイレ休憩の時間だよ。部屋から出てトイレに行きなさい。」すると、数秒後に息子の部屋のドアノブが回る音がしました。我々家族は思わず隠れていた場所から頭を出して覗いてみると、息子はよく分からないといった顔つきで私をちらりと見て、そのまま Joanna が指示したようにバスルームに向かっていったのでした。Calvin が聞いたことも見たこともない人物の声による指示を聞き、それに応えたことを目の当たりにした私達は驚きで顔を見合わせたほどです。この一件に関するアイデアを同僚達と話し合ったところ、そのうちの一人が、毎年恒例の AWS Sales Kick-Off ミーティングで開催される IoT と AI のサイエンスフェアに参加してみたらどうだろう、と提案してきました。Polly と Lex のリリースから 2 か月そして 3500 ものコードを作成後、Pollexy は (Calvin 同伴) サイエンスフェアでデビューを飾りました。

概要

Pollexy (“Polly” + “Lex”) は Raspberry Pi とモバイルベースの特別なニーズに応える音声アシスタントです。ヘルパーは Pollexy を使用して、音声によるタスクの指示や、定期的に行うスケジュールもしくはオンデマンドのスケジュールに関するメッセージを再生するように設定できます。たとえば、ヘルパーは定期的に服用する薬のリマインダーメッセージをスケジュールしたり、毎時間のトイレ休憩を促すメッセージを設定することができます。また、同時に Amazon Echo とモバイルデバイスを使用して特定のメッセージをすぐに再生するようにリクエストすることも可能です。ヘルパーは相手がメッセージを聞いたか確認するように設定することもできます。たとえば、Pollexy が最初に「青いボタンを押してください (Push the blue button)」と言わない限り、息子は Pollexy に反応しません。息子が青いボタンを押すまで、Pollexy はメインのメッセージを再生しないようになっています。また他の状況では Lex を使用して口頭で応答したり、確認が不要なユーザーもいるでしょう。どちらにしても、自分のニーズに適うように Pollexy をカスタマイズすることができるのです。そしてもっとも重要かつチャレンジとなるポイントは、大きな家に住んでいる場合、メッセージを再生する部屋に相手がいるか確認するにはどうしたらいいのか? という点です。特別なニーズのある大人が離れに住んでいる場合はどうでしょう?リビングにいるのかキッチンにいるのか分からない場合は?相手が複数人いる場合は?屋内にいる複数の人物がそれぞれ別の部屋にいた場合、各自にそれぞれ別のメッセージを送りたい場合はどうでしょう?では、次に基本的な要素と全容についてご説明します。

Pollexy の基本的要素

Amazon のリーダーシッププリンシプルは「Invent and Simplify (発明と簡素化)」です。Amazon では Pollexy アーキテクチャの複雑性を最小限に抑えたいと考えています。Pollexy で連係しているオブジェクトとコンポーネントは、簡単に説明できる方法でそれぞれ 3 つのタイプに分けることができます。

オブジェクト #1: ユーザー

Pollexy でサポートできるユーザー数には制限がありません。ユーザーは独自の特定できる名前です。「確認する」など基本的な事項を設定できます。さらに大きなポイントは場所をスケジュールで特定できることです。つまり、誰かがいる家の特定の場所に対して Outlook のようなスケジュールを作成することができるのです。

オブジェクト #2: 場所

場所はデバイスが物理的に設置されている独自の場所を識別します。ユーザーのロケーションスケジュールをベースに、Pollexy はどのデバイスを順次に使用して連絡するか把握することができます。必要に応じてデバイスを「消音」モードにすることもできます (お昼寝中など)。

オブジェクト #3: メッセージ

もちろん、これが本来の目的です。各メッセージには、ユーザーそして定期的に実行するスケジュールが連携されます (1 回限りのメッセージを除く)。Pollexy はメッセージの再生準備が整うと、ユーザーの場所を確認することができるのでメッセージには場所情報は保存されません。

コンポーネント #1: スケジューラー

メッセージはどれもスケジュールする必要があります。これはコマンドラインツールです。たとえば「Calvin に「午後 8 時までに歯を磨くこと」と伝えてください」と言った場合、このメッセージは DynamoDB に保管され、Lambda 関数のキューイングを待つことになります。

コンポーネント #2: キューイングエンジン

Lambda はスケジューラーを毎秒ごとに実行しチェックして、メッセージがあるか、また再生できるメッセージがあるか確認します。再生するメッセージがある場合、ユーザーの場所のスケジュールを確認してメッセージを再生またはその場所に SQS キューを送ります。

コンポーネント #3: スピーカーエンジン

Raspberry Pi デバイスでは毎分ごとにスピーカーエンジンが起動し、その場所の SQS を確認します。メッセージがある場合、スピーカーエンジンはユーザーの設定を確認しメッセージを再生するためにコミュニケーションを開始します。相手が応答しない場合、スピーカーエンジンはスケジュールでそのユーザーに別の場所が指定されているか確認し、その 2 番目の場所の SQS キューにメッセージを送ります。結果としてメッセージは再生されるか、タイムアウトになります (そのユーザーが 1 日中留守にしている場合など)。

ユーザーへの配慮と自由がキーポイント

私達は大方、個人のプライバシーや個人情報への配慮というものはごく普通のことだと捉えていると思います。特別なサポートを必要としている人達にとって、常に誰かに見られているということは、プライバシーや自由というものがどれだけ欠如している状況であるのか想像してみてください。自閉症と向き合っている人達にとっては、他者が個人のスペースに入り込むことを強く疎ましく思い、場合によってはそれが怒りや不満に繋がることもあります。Pollexy は不満をもたらすことがなく、穏やかな友達といった存在として日常におけるサポートを提供し、ユーザーに自信を持たせながら、誰もが望む個人のプライバシーや自由が尊重されていると思わせることができるツールです。

-Troy Larson