Author: AWS Japan Staff


Amazon Sumerianの紹介:簡単な方法で VR、AR、3D体験を作成

私の過去のブログの投稿を読んだり、様々なカンファレンスで行ったセッションに出席したことがあれば、私がGeekな女の子だと分かっているかもしれません。クラウド、人工知能、IoT、Makerスペースなどの技術分野で行われた最新の進歩、そしてバーチャルリアリティ(VR)と拡張現実(AR)には大変興味を持っています。私の考えでは、Geekになるのはすばらしい時期です。スターウォーズやスタートレックを見て驚いたアルゴリズムや離散数学のクラスや技術を汗ばみながらビルドを夢見ていたことのすべてが今や成果を上げています。うまくいけば、私が宇宙の他の銀河に超光速移動できるようになるまでは時間の問題に過ぎません、しかし、それまでは好きな番組やショーの中に登場するようなキャラクターや画像の3Dバーチャルリアリティや拡張現実を構築することができます。

Amazon Sumerianは誰でも簡単に拡張現実(AR)、仮想現実(VR)、3Dアプリケーションを作成し実行できるツールとリソースを提供します。Sumerianを使用すると、Oculus 、HTC Vive 、iOSデバイスなどのハードウェアでWebVR互換のブラウザを使用し、Androidデバイス上でARCoreをサポートできるマルチプラットフォームエクスペリエンスを構築できます。

現在プレビュー中のこのエキサイティングな新サービスは、ブラウザから非常に没入型でインタラクティブな3D体験をデザインできるようにする機能を提供します。これらの機能の一部は次のとおりです。

  • Editor: クロスプラットフォームパブリッシングを使用して、3Dシーンを構築し、アセットをインポートし、インタラクションや特殊効果をスクリプティングするWebベースのエディタ。
  • Object Library: 事前にビルドされたオブジェクトとテンプレートのライブラリ。
  • Asset Import: シーンで使用する3Dアセットをアップロードします。SumerianはFBX、OBJをインポートし、すぐにUnityプロジェクトを導入することをサポートしています。
  • Scripting Library:高度なスクリプト機能を提供するために、3Dエンジンを介してJavaScriptスクリプトライブラリを提供します。
  • Hosts: 性別、声、言語に合わせてカスタマイズ可能な、生き生きとしたリアルなアニメーション3Dキャラクター。
  • AWS Services Integration:Amazon PollyとAmazon Lexとの統合され、スピーチや自然言語をSumerian hostsに追加します。さらに、AWS Lambdaでスクリプトライブラリを使用すると、AWSサービス全般を使用することができます。

Amazon Sumerianでは、リッチでインタラクティブなVRおよびARシーンを構築するために3Dグラフィックスやプログラミング体験を必要としないため、Sumerian Dashboardをすぐに実行して見てみましょう!


Sumerian Dashboardから、ボタンを押して新しいシーンを簡単に作成できます。

新しいシーンのデフォルトビューが開き、Sumerian Editorが表示されます。EditorでTara Blog Sceneを開いて、自分のシーンにアセットを簡単にインポートできます。

Import Assetボタンをクリックしてアセットを選択して、View Roomを選択してシーンにインポートします。開きたいアセットを選択した状態で、[Add]ボタンをクリックしてインポートします。

素晴らしい!持っていたアセットはSumerian Editorに正常にインポートされ、Asset panelに表示されます。さて、View RoomオブジェクトをView Roomで選択し、それをEditorのキャンバスにドラッグすることで、View Room objectをシーンに追加することができます。

インポートアセット処理を繰り返し、今度はマネキンアセットをシーンに追加します。

さらに、Sumerianでは、エンティティにScriptComponentを追加してスクリプトを作成し、シーンをさらにエキサイティングにするために、Entityアセットにスクリプトを追加することができます。提供された組み込みのスクリプトを使用するか、独自のカスタムスクリプトを作成することができます。新しいカスタムスクリプトを作成すると、下のコードに似た基本のJavaScriptコードを含む空白のスクリプトが表示されます。

'use strict';
/* global sumerian */
//This is Me-- trying out the custom scripts - Tara

var setup = function (args, ctx) {
// Called when play mode starts.
};
var fixedUpdate = function (args, ctx) {
// Called on every physics update, after setup().
};
var update = function (args, ctx) {
// Called on every render frame, after setup().
};
var lateUpdate = function (args, ctx) {
// Called after all script "update" methods in the scene has been called.
};
var cleanup = function (args, ctx) {
// Called when play mode stops.
};
var parameters = [];

Very cool! Amazon Sumerianを使用してほんの数分で3Dシーンを作成し、表面をほんの少しい触っただけです。

まとめ

Amazon Sumerianサービスを使用すると、仮想現実(VR)、拡張現実(AR)、および3Dアプリケーションを容易に作成、構築、実行できます。没入感のあるシーンや体験を構築するために、3Dグラフィックスや専門的なプログラミング知識は必要ありません。 SumerianにFBX、OBJ、およびUnityプロジェクトをインポートしたり、シーンで使用する独自の3Dアセットをアップロードしたりすることができます。さらに、デジタルキャラクターを作成してあなたのシーンにキャラクターの出現、発言、行動の選択してデジタルアセットを使用してナレーションを追加できます。

Amazon Sumerianの詳細を知り、限定プレビューにサインアップして、製品ページの新しいサービスを開始することができます。皆さんが豊かな経験を積み重ねていくのを私は待つことはできません。

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

DNS を使って AWS Certificate Manager の検証を簡単に

Secure Sockets Layer/Transport Layer Security (SSL/TLS) 証明書はインターネット越しのネットワーク通信を安全にし、Web サイトの身元を確認するのに使われています。アマゾンは証明書を発行する前に、そのドメイン名をあなたが管理している事を検証しなければなりません。今回、あなたが管理しているドメイン名について SSL/TLS 証明書の発行リクエストを AWS Certificate Manager (ACM) にした際に、Domain Name System (DNS) 検証を使えるようになりました。これまで、ACM はEメール検証のみをサポートしており、ドメインの所有者は証明書発行リクエストのつどEメール受け取り、確認して承認する必要がありました。

DNS 検証では、そのドメインをあなたが管理している事を証明するために CNAME レコード を DNS 設定に書き込む必要があります。CNAME レコードの設定後は、DNS レコードが変更されない限り、有効期限切れ前には ACM は自動で DNS 検証した証明書を更新します。Amazon Route 53 で DNS を管理している場合は、ドメインの検証がより簡単になるよう ACM が DNS 設定の更新も行うことができます。このブログ記事では、DNS 検証を使って Web サイトの証明書リクエストを行う方法を紹介します。同等のステップを AWS CLI、AWS API、AWS SDK を使って行うには、AWS Certificate Manager in the AWS CLI ReferenceACM API Reference を御覧ください。

SSL/TLS 証明書を DNS 検証を使ってリクエストする

このセクションでは、インターネットで Web サイトの身元を確認するのに必要な SSL/TLS 証明書を ACM を使って発行するのに必要な 4 ステップを順番に行っていきます。SSL/TLS は、通信における重要データの暗号化、Web サイトの身元を証明する証明書を使った認証、ブラウザ、アプリ、Web サイト間の接続の安全性を実現します。DNS 検証や SSL/TLS 証明書は ACM を通じて無償で提供されます。

ステップ 1: 証明書をリエクストする

始めるにあたって、AWS マネージメントコンソール にログインして、ACM コンソールを開きます。証明書をリクエストするには Get started / 今すぐ始める を選んで下さい。

Screenshot of getting started in the ACM console

もしこれまでに ACM で証明書を管理していた場合は、代わりに証明書一覧と新しい証明書をリクエストするボタンが表示されます。新しい証明書をリクエストするには Request a certificate / 証明書のリクエスト を選んで下さい。

Screenshot of choosing "Request a certificate"

Domain name / ドメイン名 のテキストボックスにドメイン名を入力し、Next / 次へ を選んで下さい。この例では、
www.example.com と入力しています。あなたが管理しているドメイン名でなければいけません。あなたが管理していないドメイン名の証明書をリクエストすることは、AWS サービス条件 に違反することになります。

Screenshot of entering a domain name

ステップ 2: 確認方法を選択する

DNS 検証 (DNS validation) では、DNS 設定に CNAME レコードを書き込むことでドメイン名の管理をしている事を検証します。DNS validation / DNS 検証 を選んで、Review / 確認 を選びます。

Screenshot of selecting validation method

ステップ 3: リクエストを確認する

リクエストを確認して、証明書をリクスとするには Confirm and request / 確定とリクエスト を選びます。

Screenshot of reviewing request and confirming it

ステップ 4: リクエストを送信する

ACM がドメイン検証の情報を反映するのに少し経った後、▼ を選択して検証情報の全てを表示させます。

Screenshot of validation information

証明書リクエストしたドメイン名を管理していることを検証するために、DNS 設定に追加が必要な CNAME レコードが表示されます。Route 53 以外の DNS サービスを使っていたり、他の AWS アカウントで Route 53 を使っている場合、検証情報から DNS CNAME 情報をコピーするかファイルにエクスポート (Export DNS configuration to a file / DNS 設定をファイルにエクスポート を選びます) して、DNS 設定に書き込みます。DNS レコードを追加・削除する方法については、お使いの DNS サービスを確認指定下さい。DNS に Route 53 をお使いの場合は、Route 53 ドキュメント を確認して下さい。

同じ AWS アカウントの Route 53 でドメインの DNS レコードを管理している場合、ACM で DNS 設定を更新するために Create record in Route 53 / Route 53 でのレコードの作成 を選択して下さい。

DNS 設定を更新した後、Continue / 続行 を選択して ACM の証明書一覧に戻ります。

ACM は全ての証明書の一覧を表示します。リクエストした証明書も表示され、リクエストのステータスを確認することができます。DNS レコードの書き込みを行った後、(TTL設定によりますが) 一般的にレコードが反映されるまで 30 分程度かかり、さらに Amazon が検証して証明書を発行するまで数時間かかります。ACM はこの期間 Validation status / 検証状態Pending validation / 検証保留中 と表示します。ACM がドメイン名の検証をした後は、Validation status / 検証状態Success / 成功 と表示します。証明書の発行後、証明書のステータスは Issued / 発行済み となります。もし 72 時間経っても ACM が DNS レコードを検証できず証明書を発行できなかった場合は、リクエストはタイムアウトし、検証状態は Timed out / タイムアウト と表示されます。やり直すには、新たにリクエストを作成する必要があります。検証や発行についてトラブルシューティングする手順については、ACM ユーザガイドトラブルシューティングを参照下さい。(訳注:11/27 現在、日本語のユーザガイドはまだ DNS 検証について反映されてないため、英語版を参照下さい。)

Screenshot of a certificate issued and validation successful

これで ACM の証明書は発行されたので、Web サイトを安全にするのに使用できます。証明書を他の AWS サービスにデプロする方法については、それぞれのドキュメント
Amazon CloudFrontAmazon API GatewayApplication Load BalancersClassic Load Balancers を参照して下さい。なお、CloudFront で証明書を使用するには 米国東部(バージニア北部)リージョンに証明書が作成されている必要があります。

ACM は証明書が他の AWS サービスで使用されており、CNAME レコードが残っている限り証明書を自動的に更新します。ACM の DNS 検証についてさらに詳しく知るには、ACM FAQACM ドキュメント を御覧ください。

このブログ記事にコメントがる場合、(原文の)記事のコメントセクションに記載して送って下さい。もしこの記事について質問がある場合は ACM forum に新しいスレッドを作成して質問するか AWS サポート
にお問い合わせ下さい。

– Todd (翻訳は SA 辻 義一 が担当しました。原文はこちら)

Amazon Lex を使った Bot の作成

Jeff Barr がブログでの紹介の投稿でご説明したように、Amazon Lex は、開発者が音声とテキストを使用してアプリケーションで対話式のインターフェイスを構築できるようにするサービスです。Amazon Lex を使うと、すべての開発者が Amazon Alexa に採用されている深層学習技術と同じ技術を利用し、自然言語での高度な対話ボット (チャットボット) を短時間で簡単に構築できるようになります。Amazon Lex では、自動音声認識 (ASR) という音声をテキストに変換するための高度な深層学習テクノロジーと、テキストの意図を理解するための自然言語理解 (NLU) を利用できます。これにより、ユーザーにとって使いやすく魅力的なアプリケーションを構築できます。

では、Amazon Lex で機能的なチャットボットを開発するには、どうすればいいでしょうか。ドキュメント内の例の 1 つを利用すれば、1、2 分でチャットボットを使用してやり取りを開始することができます。もちろん、これはきっかけにはなりますが、まったく十分とはいえません。では、チャットボットを構築するために、何をする必要があるかを見てみましょう。

基本

チャットボット設計は、確立基準がほとんどない発生期の領域です。実際のユーザーとやり取りしなければ、何が面倒で何が快適かを理解することはできません。このセクションは、ボット設計のガイドではなく、設計上の考慮事項を探るものとして扱うことをお勧めします。以下は、Amazon Alexa との何百万回ものやり取りから学んだことです。

Simon Sinek はチャットボットがなぜ存在するかという疑問から始めることを奨励しています。優れた設計は明確な目標から始まります。それにはまず、ユーザーがどんな人か、何を達成しようとしているのかを理解する必要があります。

また、モダリティとミディアムのことも考える必要があります。音声インターフェイスは確かに便利ですが、ユーザーが注意を払っていなかったり、単に聞こえていなかったりすることも想定して、最後のプロンプトを繰り返したり、「何?」とか「どこまでいったっけ?」といった反応にも適切に対応できなければなりません。テキストのインターフェイスでは、これは不要でしょう。一部のテキストインターフェイスでは、画像とボタンの付いたレスポンスカードもサポートされています。

インターフェイスを設計する者にとって、強調は不可欠な手法です。これは、情報を提示したり、特定の選択肢を推奨する基準となります。明確性を実現するための規則はモード (ウェブ UI かチャットか音声か) によって異なります。目標とモードに応じて、強調のためのツールは異なる可能性があります。次の例を見て、3 つのそれぞれのモードにおける注文方法について検討してみてください。

 o_bots_1 これで注文してよろしいですか。 (はい/いいえ) ____ を注文したいとのことですが、それでよろしいですか。 
ウェブ (ポイントアンドクリック) チャット (テキスト) 言語 (音声認識)

ウェブの場合、「注文を確定する」を強調することで、それが推奨される選択肢であることを明確化し、このアクションによって顧客が注文にコミットすることを確認する必要があります。チャットでは、オプションを括弧で囲むことで、ユーザーに何が期待されているかを示すのが慣例となっています。また、テキストの配置や空白文字、大文字などで強調することもできます。

音声操作では、このような慣例に代わって、注文がいつ実行されるかをユーザー自身がコントロールしていることを保証する新しい基準が必要となります。たとえば、注文に大幅な変更がある場合は、確認することができます。さらに、音声の場合、強調のためにゆっくりと話すなど、話す速度をコントロールすることも可能です。他の方法が使用できない場合は、単に繰り返すだけでもかまいません。以下の例を見てみましょう。

ご注文の合計額は 55 ドルです。

この注文を実行して、このアカウントに登録されているカードに 55 ドル課金してよろしいですか。

 
  音声 – 強調のための繰り返し  

CoffeeBot の構築

ボイスボットを使用して、あまり一般的に使用されることのない言葉を含む会話 (たとえば、カフェラテを注文するときの「トリプルモカをお願いします」など) をサポートする必要があるとします。もちろん、ボットに命令するのがお好きな方は、「トリプルモカ、頼む」と言ってもかまいません。

ここでは、Amazon Lex コンソールを使用してカスタムボットを作成してみましょう。これを「CoffeeBot」と呼んで、Amazon Lex を呼び出すための適切なアクセス許可を持つ IAM ロールを使用します。この実行手順については、『Amazon Lex 入門ガイド』を参照してください。

 

Lex の用語

Jeff がブログで説明したように、Amazon Lex ではインテントやスロットタイプ、スロットが使用されます。再利用可能性を促進するために、インテントとスロットタイプは AWS アカウントに関連付けられ、複数の Amazon Lex ボットによって使用されます。変更を実行するに従い、Amazon Lex がそれらリソースのバージョンを自動的に追跡することがわかると思います。そのため、テストしている特定のバージョンのボットに何が使用されているかを正確に把握できます。これは一見、それほど大事でないことのように感じられるかもしれませんが、並列開発と継続的開発の両方をサポートすることは極めて重要なことです。

会話の流れ

新しいボットを開始する際には多くの場合、1 つのタイプのリクエストで通常どのような会話が行われるかを録音し、それらのリクエストを分析して、より広範なリクエストの場合を推定することが有効です。CoffeeBot では、人々がコーヒーショップでどのようにモカを注文するかに焦点を当てることにします。

実際の会話 会話のフェーズ インテントと代替案

いらっしゃいませ。ご注文はお決まりですか。

> えっと、ノンファットモカをお願いします。

挨拶と最初のリクエスト

– 飲み物のタイプ: モカ

– 飲み物のサイズ: ラージ

– クリーマー: ノンファット

飲み物のタイプのみから始めることも別の組み合わせから始めることも可能。

アイスにしますか。

いいえ、いいです。

設定

– 飲み物の温度: ホット

ホットかアイスだけか。他の値はあり得るか。

チョコレートはどうなさいますか。

ダークで。

設定

– チョコレートのタイプ: ダーク

すべての飲み物にチョコレートが必要なわけではない。モカだけか。

ホイップクリームはどうなさいますか。

いいです。

設定

– ホイップクリーム: いいえ

ホイップクリームにはいくつかの種類があるか。

他の飲み物やサイズに変更する可能性は?

かしこまりました。ラージ、シングルダーク、ノンファットモカ、ホイップクリームなしですね。

> あっ、トフィーを 1 ポンプ追加してもらえますか。

確認 → 設定

– フレーバー: トフィー 1 ポンプ

ここで承認することもできた。フレーバーを 2 種類に増やすことは可能か。制限はあるか。

かしこまりました。ラージ、シングルダーク、ノンファットモカ、ホイップクリームなしで、トフィーを 1 ポンプですね。お名前は?

ジェニーです。

確認 → ラベル

– 名前: ジェニー

優先客として名前をアプリに保存

ありがとうございました。ご用意でき次第、そちら右側のカウンターでお渡しいたします。4 ドル 17 セントになります。他はよろしいですか。

いいです。

清算 このための課金オプション。

5 ドル、お預かりいたします。83 セントのお返しです。どうもありがとうございました。

> どうも。

清算 → 完了

placeOrder:  name, beverageConfig

– バックエンドで注文を実行

– 確認メールを送信?

– ポイント獲得?

実際の注文は、このモカの例よりずっと複雑で、10 万種類以上のコーヒー飲料が存在する可能性があります。自然な会話は決まった順序に進まないし、会話の途中でユーザーの気が変わったり、ユーザーが会話の一部をスキップする可能性もあります。このような流れの柔軟さが自然な会話の特徴です。

ではここで、CoffeeBot が「ダブルショートモカ」と聞いた場合を考えてみましょう。この場合、ユーザーは「エスプレッソダブルのショート (8 オンス) モカ」を頼んだのでしょうか。それとも実際にはサイズには触れずに「ダブルショットモカ」を頼んだのでしょうか。今一度、入力を憲章する必要があります。このシリーズの次の投稿では、入力の検証についてお話しします。

会話のインターフェイスを設計する際、的を絞ることが重要です。これまでにお話しした複雑性の一部は、ユーザーが誰かを「認識」し、支払いを処理できるアプリから始めることで自然と解消されます。特に寒い日や雨の日などには、天気の話を会話のトピックに含めてもいいでしょう。このようなたわいもない話をモデル化することは楽しいかもしれませんが、時間を最も有効に使っているとはいえないでしょう。あればいいなと思うものではなく、ユーザーエクスペリエンスを大幅に強化する開発作業に焦点を当てましょう。

会話: 情報

上記のような分析は、会話の構造を明らかにするものです。情報の断片は個別に共有することも一緒に共有することもできます。また、多数の可能な順序の 1 つとして共有することもできます。さらには、一定の飲み物のアドオンをオプションとして追加することも可能です。しかし最終的には、モカを注文するために認識されなければならない特定の値セットがあります。これまでに解明した情報の重要なサブセットに対応し、これらのスロットがフィードバックループを使用し時間をかけて洗練されていくのだということを理解したうえで、まずは CoffeeBot の一部のスロットタイプから開始します。

開発チームは共有リソースを検出しやすいように独自の規則を作成しますが、ここでは「cafe」をプレフィックスとして使用します。

スロットタイプ スロット値
cafeBeverageType コーヒー; カプチーノ; ラテ; モカ; チャイ; エスプレッソ; スムージー
cafeCreamerType 2 パーセント; ノンファット; ソイ; アーモンド; ホールミルク; ハーフアンドハーフ
cafeStrength シングル; ダブル; トリプル; クアッド; クアドラプル
cafeFlavor バニラ; アーモンド; フレンチバニラ; キャラメル; ヘーゼルナッツ
cafeBeverageSize キッズ; スモール; ミディアム; ラージ; エクストララージ; ショート; 6 オンス; 8 オンス; 12 オンス; 16 オンス; 20 オンス
cafeBeverageTemp キッズ; ホット; アイス
cafeBeverageExtras ハーフスイート; セミスイート

会話: 目標

次に、Amazon Lex の用語で「インテント」として知られる目標を定義します。ボットは最終的には複数のインテントを使用する可能性がありますが、まずは 1 つから始めましょう (複数のボットが同じインテント、および同じインテントの異なるバージョンを使用することができます)。

ユーザーが実際に言うと予想される内容をいくつか例として提示することが重要です。Amazon Lex では、これらの例は「発話」と呼ばれます。これが重要なのは、Amazon Lex が機械学習モデルのトレーニングを行い、正しいインテントを認識するようにするためです。このテキストは、ユーザーの言うことに完全に一致している必要はありません。また、小さいセットから始めて、その後変形を追加していくのが最良です。

各発話は 1 つ以上のスロットを参照しますが、これらのスロットは定義されている必要があります。各スロットは、ユーザーから値を引き出すために Amazon Lex が使用する 1 つ以上のプロンプトと関連付けることができます。Amazon Lex ダイアログマネージャーはスロット値を追跡します。また、以下のように、それぞれの必要なスロットの優先度を使用して、次に求めるスロットを決定することもできます。

o_bots_2

この時点で、ボットはコーヒーを注文できる状態になります。フルフィルメントについては、パート 2 の投稿でお話しします。

会話: テスト

次に、ボットを構築してテストします。モバイルアプリができてからでは他の多くの要素がからんでくるため、この段階で、できているものをテストしてエラーを検出し修正することは非常に有効です。テストは Amazon Lex コンソールに表示されるオーバーレイで実行できます。

Test_bot_text

何が起こったのでしょうか。発話としてはこのとおりのテキストを設定していませんでしたが、「I want a mocha (モカをお願いします)」という入力テキストは、作成された cafeOrderBeverageIntent と照合され、発話が I want a {BeverageType: mocha} ({BeverageType: モカ} をお願いします) として解釈されました。続いて、Amazon Lex は BeverageSize が必要であると判断し、このスロットのデフォルトのプロンプト、つまり What size?  tall, medium, large? (サイズはどうなさいますか?  トールとミディアム、ラージがございますが?) というプロンプトを表示しました。

最後に、すべての必要なスロットが満たされたら、Amazon Lex はリクエストどおりに値を表示します (クライアントにパラメーターを返す)。

会話: 流れ

では、Lex が理解できなかった場合はどうでしょうか。この場合は、コンソールにあるインテントエディタの明確化プロンプトを使用して、何か別の内容を引き出そうと試みることができます。他のすべてが失敗した場合、安全に終了します。

o_bots_4

この設定では、Amazon Lex は 3 回まで他の明確化プロンプトを使用し、その後、中断フレーズの 1 つを使用して断念していることがわかります。では、なぜ複数のプロンプトを使用するのでしょうか。確かに、必要なのは 1 つだけかもしれませんが、複数のプロンプトが存在することで、Amazon Lex は選択することができ、自発性を維持できるのです。

A_bird_text

また、ユーザーが注文を確定する直前にボットがプロンプトを表示するように設定することもできます。確認プロンプトは、コンソールのインテントエディタにリストされています。

確認プロンプトは、セットアップしたすべての単一スロット、特に、他のスロットが満たされた場合にのみ必要となるスロットに含める必要はありません。必要なスロットをプロンプトに含めることは良い考えですが、コードフックを使用してプロンプトをカスタマイズすることもできます (詳細は次回の投稿でお伝えします)。

o_bots_6

確認プロンプトには、スロット値を含むことができます。どうように使用するか、見てみましょう。

Can_I_get_text

予想どおり、Amazon Lex は必要なスロットが満たされたことを判断し、確認プロンプトを表示しました。また、「nope (ううん)」を正確に解釈し、中断しました。2 回目では、Amazon Lex は「yep (うん)」を肯定表現として正確に解釈し、値を表示しました。

May_I_have_text

これは何を示しているのでしょうか。追加設定がない場合、Amazon Lex は確認プロンプトから、ユーザーがサイズの変更を希望していることを正確に解釈しました。

まとめ

この投稿では、ボット設計に関連する基本的な決定事項についてお話ししました。ここでは、会話の流れを実際に観察することから始め、特定の取引に的を絞り、いくつかのデフォルト値のあるインタラクティブなボットをすばやく構築しました。その後、テストコンソールで、ボットが予想どおりに動作することを確認しました。

パート 2 では、さらなる検討事項についてお話しするとともに、この基本的なボットが音声を認識できるように開発を進めます。

注意: パート 1 とパート 2 のコード は Github リポジトリにあります。

ご不明の点またはご提案があれば、下記までコメントをお寄せください。


今回のブログの投稿者について

niranjanNiranjan Hira はソリューションアーキテクトとして、お客様がビジネス上の課題に対処するために最適な構成要素を組み立てるのをお手伝いしています。時間があるときには、いろいろな物を分解して、元に戻せるかどうか試しています。

harshal_pimpalkhute_100Harshal Pimpalkhute は、Amazon Lex チームのプロダクトマネージャーとして機械が人と (うまく) やり取りするための取り組みに献身しています。

 

AWS ディープラーニング AMI を使用してディープラーニングを開始

ディープラーニングの初心者、また高度なディープラーニングプロジェクトをクラウドで構築したい方でも、AWS を使えば簡単に始められます。

AWS ディープラーニング AMIs は Ubuntu と Amazon Linux バージョンでの利用が可能になっており、いかなるスケールでもクラウドでディープラーニングアプリケーションを実行できるようにします。Amazon マシンイメージ (AMIs) には、Apache MXNet、TensorFlow、Microsoft Cognitive Toolkit (CNTK)、Caffe、Caffe2、Theano、Torch、Keras を含むオープンソースのディープラーニングフレームワークがプリインストールされています。

AMIs では、カスタムの AI モデルをトレーニングしたり、新しいアルゴリズムを試したり、新たなディープラーニングのスキルやテクニックを学ぶことができます。AMIs に追加料金はかかりません。アプリケーションを保存し実行するために必要な AWS のリソースに対してのみお支払いいただきます。

また、AMIs は事前設定されている CUDA や cuDNN ドライバー、Intel Math カーネルライブラリ (MKL) を介して GPU に加速度を提供しています。AMIs には人気の Python パッケージや Anaconda プラットフォームも含まれています。

そのシンプルさ、使いやすさ、コスト節約など、開発者へのメリットは明らかです。そしてコンピューティングインスタンスの起動も簡単です。次の手順に従うと、数分でディープラーニングを開始することができます。 

AMI の起動

AWS マネジメントコンソールにアクセスし、アカウントにサインインするか新しいアカウントを作成します。

(more…)

Amazon EC2 Systems Manager による Microsoft VSS を使用したスナップショットサポート

私たちはここでWindows AMIを稼働させるAmazon EC2におけるMicrosoftボリュームシャドウコピー(VSS)のサポートをアナウンスできることを嬉しく思います。VSSはMicrosoft Windows(主要なSQL ServerやExchange Serverなどのマイクロソフトアプリケーションを含む互換性のある)環境における非常に一般的なボリュームバックアップ技術です。VSSはファイルの書き込みなどのディスク処理をバックアップ処理実行中も適切に管理するため、アプリケーション一貫性を持ったバックアップが可能となります。 アプリケーション一貫性バックアップは、マシンまたはインスタンスに接続されたボリュームのバックアップと同時に実行され、メモリ内のすべてのデータと処理中のすべてのトランザクションをキャプチャします。

VSSが有効なAmazon EBSボリュームのスナップショット(以降、”VSS有効化スナップショット”と表記) は、Amazon EC2 Systems ManagerのRun Commandから使用可能です。AWSEC2-CreateVssSnapshot コマンドによってWindowsインスタンスのEC2にアタッチされたEBSボリュームを、バックアップ処理の間トランザクションデータの一貫性を失うことなく、アプリケーション一貫性を持ったスナップショットを取得可能です。この機能によってSQL Backupや、カスタムスクリプトなどによって提供されたアプリケーション固有のバックアップソリューションは不要となります。さらに、イメージレベルバックアップにおけるアプリケーション一貫性を維持するためのサードパーティ製ツールも不要になります。

AWSEC2-CreateVssSnapshotの使用方法

VSS有効化スナップショットは、Windowsが稼働するEC2インスタンスに対してAWSEC2-CreateVssSnapshotコマンドをEC2 Systems Manager Run Commandから呼び出すことで実行します。AWS管理コンソールやAWS CLIから実行したり、PowerShellスクリプトやLambda関数から呼び出すことも可能です。本ブログではEC2コンソールからコマンドで実行する例を示します。

AWSEC2-CreateVssSnapshot Run Command

EC2管理コンソールで、AWSEC2-CreateVssSnapshotコマンドのドキュメントを選択し、VSS有効化スナップショットを取得したいEBSボリュームを持つインスタンスを選択します。 インスタンスを選択した後、スナップショットに追加したい説明やタグを設定します。ブートボリュームをスナップショット処理から除外することも可能です。

Calling AWSEC2-CreataeVssSnapshot Run Command

起動されるとRun CommandはVSSコンポーネント(詳細については後述)に対して、EC2 Windowsインスタンス上のVSS対応アプリケーションのすべての処理中のI/Oをコーディネーションするよう指示します。これによってI/OバッファはEBSボリュームに対してフラッシュされ、すべてのI/Oはスナップショット取得が完了するまでフリーズされます。この結果アプリケーション一貫性が維持されます。スナップショットが取得された後、I/Oフリーズが解除され通常処理に復帰します。

Run Commandやスクリプトから取得したスナップショットは、EC2コンソール左側のEBSスナップショットメニューで確認できます。 このプロセスで正常に取得された全てのVSS有効化スナップショットには “AppConsistent:True”というタグが付与されます。本機能についてのより詳細についてはこちらAWSEC2-CreateVssSnapshot のドキュメントを参照してください。

VSS有効化スナップショットを取得するためのEC2インスタンスの準備

  • インスタンスへのスナップショット許可 : IAMコンソールを開き、”Amazon EC2″サービスに対する以下の権限を許可する新しいポリシーを作成します。
    1. DescribeInstances
    2. CreateTags
    3. CreateSnapshot

またIAMコンソールからAmazon EC2ロールAmazonEC2RoleForSSMに対して上記で作成したポリシーを適用します。さらにこのロールを直接EC2 Windowsインスタンスにアタッチします。

IAM permissions to take VSS-enabled EBS snapshots

  • VSSコンポーネントのインストール : 2017年11月以降のMicrosoft Windows Server AMIイメージにはVSSコンポーネントはプリインストールされています。もし使用しているWindowsインスタンスのパッケージが最新でない場合は、VSSコンポーネント(AwsVssComponents)をAWS-ConfigureAWSPakageコマンドをSystems ManagerのRun Commandから呼び出してインストールする必要があります。

AWS-ConfigureAwsPackage to install VSS components

より詳しいVSS有効化スナップショット取得のためのEC2インスタンスのセットアップについてはこちらAmazon EC2 ドキュメントを参照ください。

Installing VSS components on EC2 instances

AWSEC2-CreateVssSnapshot使用する際には、対象のEC2インスタンスに対してEBSスナップショット作成およびタグ書き込み許可のIAM許可が必要となります。コンプライアンスやポリシーの理由から追加のIAM許諾をインスタンスに付与したくない場合には、カスタム可能なサンプルのスクリプトを活用可能です。このスクリプトの詳細についてはこちらAWSEC2-ManageVssIOに関するドキュメントを参照して下さい。

VSS有効化スナップショットのリストアプロセスは通常のEBSスナップショットと同様です。こちらのリストアのサンプルスクリプトも使用できます。このリストア用スクリプトで、指定されたEBSスナップショットからEC2 Windowsインスタンスにリストアすることが可能です。

About the Author

Purvi Goyal is a Senior Product Manager with the Amazon EC2 team, where she strives to enhance the cloud experience of AWS Enterprise customers. Outside of work, she enjoys outdoor activities like hiking and kayaking.

 

(翻訳:SA松崎, 元の記事はこちらです)

AWS CodeCommitのプルリクエストを使用してコードレビューをリクエストし、コードについて議論する

シニアクラウドアーキテクトのMichael Edge氏のCodeCommitのプルリクエストに関する素晴らしいブログに感謝します。

~~~~~~~~~~~~~
AWS CodeCommitは、プライベートGitリポジトリを安全にホスティングするフルマネージドなサービスです。CodeCommitは今ではプルリクエストをサポートするようになりました。これによってリポジトリのユーザは、コードの変更に対するレビュー、コメント、対話的なイテレーションが可能になります。チームメンバー間のコラボレーションツールとして使用されるプルリクエストは、CodeCommitリポジトリに対する変更の可能性を、リポジトリにそれらの変更をマージする前に確認するのに役立ちます。各プルリクエストは、次のように単純なライフサイクルを通じて実行されます:

  • マージされる新機能は、featureブランチに1つ以上のコミットとして追加されます。コミットは、宛先のブランチにマージされません。
  • プルリクエストが通常は2つのブランチの差異から作成されます。
  • チームメンバーはプルリクエストをレビューし、コメントします。プルリクエストは、追加のコミットで更新される可能性があります。これにはコメントに対応して行われる変更や宛先ブランチとの差分から発生する変更が含まれます。
  • チームメンバーがプルリクエストに満足すれば、それは宛先ブランチにマージされます。 コミットは、プルリクエストに追加されるのと同じ順序で宛先ブランチに適用されます。

(more…)

AWS Shield Advancedを使用してAmazon EC2インスタンスとNetwork Load Balancerを保護できるようになりました

11月22日から、AWS Shield Advancedは、インフラストラクチャレイヤの分散サービス拒否(DDoS)攻撃からAmazon EC2インスタンスとNetwork Load Balancerを保護できるようになりました。 AWS Elastic IPアドレスに対してAWS Shield Advancedを有効にし、インターネットに接続されたEC2インスタンスまたはNetwork Load Balancerにアタッチすることで利用可能です。 AWS Shield Advancedは、Elastic IPアドレスの背後にあるAWSリソースの種類を自動的に検出し、DDoS攻撃を緩和します。

AWS Shield Advancedは、Amazon VPCネットワークアクセスコントロールリスト(ACLs)をAWSネットワークのエッジにあるAWS Shield上で自動的に実行し、追加の帯域幅とスクラビング容量を利用することで、大量のDDoS攻撃を軽減します。また、AWS DDoS対応チームと協力し、事前に軽減策を設定したり、発生したインシデントに対応したりすることで、AWS Shieldの追加の軽減策をカスタマイズできます。AWS Shield Advancedによって検出されたすべてのインシデントについては、Amazon CloudWatchのメトリックを通じて、ほぼリアルタイムに可視化されます。インシデントの詳細についても、攻撃の地理的な起点や送信元IPアドレスなどが確認いただけます。

Elastic IPアドレスに対応したAWS Shield Advancedは、DDoSコスト保護の適用範囲を拡大します。DDoSコスト保護により、DDoS攻撃の結果として利用リソースが増加した場合に、Elastic Load BalancingAmazon CloudFrontAmazon Route 53、およびEC2インスタンス時間についてサービスクレジットを要求できるようになりました。

EC2インスタンスとNetwork Load Balancer保護の開始

開始方法:

  1. AWS Management Consoleにサインインし、AWS WAFおよびAWS Shieldコンソールに移動します。
  2. 「AWS Shield Advancedを有効にする」を選択、条件をご確認いただき、AWS Shield Advancedを有効化します。
  3. ナビゲーションペインで「Protected resources」に移動します。
  4. 保護するElastic IPアドレスを選択します(これらはEC2インスタンスまたはネットワークロードバランサを指し示します)。

AWS Shield AdvancedがDDoS攻撃を検出した場合、CloudWatchを確認するか、AWS WAFおよびAWS Shieldコンソールの「Incidents」タブを調べることで攻撃の詳細を取得できます。 この新機能とAWS Shield Advancedの詳細については、AWS Shieldのホームページを参照してください。

この投稿に関するご意見やご質問は、(原文)記事の「コメント」セクションにお寄せいただく、またはAWS Shieldフォーラムで新しいスレッドを開始いただくか、AWSサポートにお問い合わせください

– Ritwik

原文:Now You Can Use AWS Shield Advanced to Help Protect Your Amazon EC2 Instances and Network Load Balancers(翻訳:SA安司)

 

Amazon Elasticsearch Service へのアクセスコントロールの設定

Dr. Jon Handler (@_searchgeek) は、検索技術を専門とする AWS ソリューションアーキテクトです。

Amazon Elasticsearch Service (Amazon ES) ドメインを保護することで、権限のないユーザーがデータにアクセスしたり変更したりすることを防ぐことができます。ほとんどのお客様は、IP アドレスベースまたは ID ベースのアクセスポリシーのセキュリティを望んでいますが、利便性からオープンアクセスを選択しています。オープンアクセスのドメインは、インターネット上の任意の当事者から Amazon ES ドメインへのデータの作成、表示、変更、および削除の要求を受け入れるため、このオプションはほとんどのお客様にとって適切なものではありません。

以前のブログ記事「Amazon Elasticsearch Service ドメインのアクセスをコントロールする方法」では、アクセスコントロールについて詳細に説明しました。このブログ記事では、ドメインの IAM ポリシーを開始する簡単な方法をいくつか紹介します。AWS Identity and Access Management (IAM) ポリシーを設定するにはいくつかの作業が必要ですが、この「予防的対策」により後で大量の作業が発生するのを防ぐことができます。

Amazon Elasticsearch Service における主要なアクセスコントロールの概念

Amazon ES が作成するドメインには、Elasticsearch クラスタ内のノードと複数の AWS サービスのリソースが含まれます。Amazon ESがドメインを作成すると、ドメインはサービス制御された VPC でインスタンスを起動します。これらのインスタンスの前面には Elastic Load Balancing (ELB) があり、ロードバランサーのエンドポイントはRoute 53 を通じて発行されます。ドメインへのリクエストは、ドメインの EC2 インスタンスにルーティングする ELB ロードバランサをパススルーします。リクエストがどこに行くかに関わらず、インスタンスは IAM にコンタクトしてリクエストが承認されているかどうかを判断します。承認されていないリクエストはブロックされ、破棄されます。

IAM ポリシーがどのように適用され、解決されるかを理解するための鍵は、次の点にあります。

  • ポリシーの場所: IAM ポリシーは、ドメインまたは個々のユーザーまたはロールに付加できます。ポリシーがドメインに付加されている場合は、リソースベースのポリシーと呼ばれます。ユーザーまたはロールに関連付けられている場合は、ユーザーベースのポリシーと呼ばれます。
  • ポリシーの解決: IAM は、リクエストが承認されているかどうかを判断するために、リクエストに適用されるすべてのユーザーベースおよびリソースベースのポリシーを収集します。詳細については、ブログ記事「Amazon Elasticsearch Service ドメインのアクセスコントロールを設定する方法」を参照してください。

リソースベースのポリシー、ユーザーベースのポリシー、またはそれらの組み合わせを作成するかどうかにかかわらず、IAM は特定のリクエストに対してすべてのポリシーを尊重します。

Amazon ES コンソールのウィザードを使用してドメインを作成すると、Amazon Elasticsearch Service はさまざまな種類のアクセスに対していくつかのテンプレート IAM ポリシーを提供します。

  • [1 つ以上の  AWS アカウントまたは IAM ユーザーにアクセスを許可、または拒否する] を選択した場合: ドメインにアクセスする必要がある IAM ユーザーまたはロールを指定します。ドメインへのすべてのリクエストは、AWS 署名バージョン 4 署名で署名する必要があります。リクエストがドメインに到達すると、署名検証とアクセスコントロールのためにリクエストが IAM に転送されます。
  • [Allow access to the domain from specific IP(s) (特定の IP からのアドメインへのアクセスを許可する)] を選択した場合: IP または CIDR ブロックを指定します。その IP アドレス範囲からの匿名 (署名なし) リクエストは許可されます。
  • [Deny access to the domain (ドメインへのアクセスを拒否する)] を選択した場合: 署名付きまたは署名なしにかかわらず、リクエストは許可されません。
  • [Deny access to the domain (ドメインへのアクセスを拒否する)] を選択した場合: 署名付きまたは署名なしにかかわらず、リクエストは許可されません。このテンプレートを選択すると、Amazon ES からポップアップ警告が表示されます。

シンプルな IP アドレスベースのセットアップ
Amazon Elasticsearch Service を使い始めたばかりのときは、データをすばやく読み込んだり、いくつかのクエリを実行したり (コマンドラインから、または Kibana を使用して)、コマンドラインからより詳細な検査と監視を行いたいものです。オープンアクセスポリシーは、ネイティブの Elasticsearch クライアント、curl、ウェブブラウザなどのツールがクラスタとやりとりすることを可能にするため、最も早く始める方法となります。

その性質上、オープンアクセスは安全ではありません。オープンアクセスポリシーはお勧めできません。IP アドレスベースのアクセスコントロールを使用すると、ドメインを保護することができます。不正な訪問者やポートスキャナは、次のようなメッセージで拒否されます。

{“Message”: “User: anonymous is not authorized to perform: es:ESHttpGet on resource:<domain ARN>”}

開発を EC2 インスタンスから行う場合は、VPC を設定してパブリック IP アドレスまたは Elastic IP アドレス (EIP) を割り当てることができます。

この簡単なセットアップで、[Allow access to the domain from specific IPs] オプションを選択すると、次のようなポリシーを生成できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "111.222.333.444/0"
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }

 

IPアドレス、アカウント ID、ドメイン名(赤で表示) を必ず自分の値に置き換えてください。

この設定は、開発およびテストのために必要な基本アクティビティをサポートします。curl のようなツールを使ってコマンドをクラスタに直接送ることができます。その EC2 インスタンスで Kibana を実行できます。IP アドレスベースのアクセスポリシーはフルアクセスを許可します。署名されていても匿名であっても、異なる IP アドレスからのドメインへのその他のすべてのリクエストは、IAM によって拒否されます。

Kinesis Firehose、Amazon CloudWatch ログ、または AWS IoT で使用するためのセットアップ
Amazon Elasticsearch Service を開始するには、別の AWS サービスからデータを送信するのが簡単です。Kinesis Firehose ストリームを作成するか、CloudWatch ログデータを Amazon ES にストリーミングするには、これらのサービスがドメインに書き込むことを許可するロールを作成する必要があります。IAM のポリシー解決により、他のサービスからのアクセスが許可され、ドメインにデータを書き込むことができるようになります。IP アドレスベースのポリシーによって、コマンドと Kibana のための EC2 インスタンスへのアクセスが許可されます。他のすべてのリクエストへのアクセスは拒否されます。

AWS IoT の安全なアクセスを設定する方法については、IP アドレスベースのポリシーを使用する方法について説明しているブログ記事「Analyze Device-Generated Data with AWS IoT and Amazon Elasticsearch Service (AWS IoT および Amazon Elasticsearch Service によるデバイス生成データの分析)」を参照してください。

IP アドレスがわからない場合のセットアップ
多くの場合、リクエスト元の静的 IP アドレスはわかりません。データセンター内のノードのセット、モバイルアプリケーションのサポート、または自動スケーリングされた一連のウェブサーバーまたは Logstash インスタンスからのリクエストの送信で、Kibana を実行することができます。

このような場合、VPC の既知の IPアドレスでリバースプロキシを使用して、Kibana から Amazon Elasticsearch Service サービスドメインにリクエストを転送し、ユーザーベースの認証で署名バージョン 4 の署名を使用してアプリケーションサーバーからリクエストを送信できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/webserver "
      },
      "Action": ["es:ESHttpGet"],
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "111.222.333.444/0",   <-- プロキシの IP アドレス
            "112.223.334.445/0"    <-- インスタンスの IP アドレス
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }

  ]
}

 

プロキシサーバーの IP アドレスを IP アドレスベースのポリシーに置き換えて、プロキシからのロクエストを許可します。ポリシーに別の IP アドレスを追加して、コマンドラインと Kibana のためのアクセスを開くこともできます。

前述のポリシー例では、ウェブサーバーのロールに許可されているアクションを HTTP GET 呼び出しに制限しています。作成する IAM ポリシーでは、さまざまなコマンドと HTTP メソッドを許可しているため、さまざまなアクターのアクセスコントロールを設定できます。詳細については、ブログ記事「Amazon Elasticsearch Service ドメインのアクセスをコントロールする方法」を参照してください。

プロキシを使用してリクエストの署名を簡素化する
プロキシを作成すると、プロキシの IP アドレスをアイデンティティのソースとして使用して、ドメインへのアクセスをコントロールできます。プロキシから許可されたリクエストのみを発信することによって、アクセスをコントロールします。署名バージョン 4 のリクエスト署名を使用して、リクエストの背後にあるアイデンティティ情報を提供することもできます。Amazon ES は IAM を使用してこれらのリクエストを認証し、許可または拒否します。

リクエストの署名を実装するには、コードを記述する必要があります。これは、コマンドラインまたは Kibana のアクセスのための開発の追加ハードルになります。リクエストを受け取り、署名バージョン 4で署名し、AWS に転送する小さなアプリケーションを提供するオープンソースプロジェクトがあります。

そのような署名プロキシがここにあります: https://github.com/abutaha/aws-es-proxy。この小さなアプリケーションはポート 9200 でリッスンし、署名されたリクエストを Amazon Elasticsearch Service に転送します。

注意: この署名プロキシは、AWS ではなくサードパーティによって開発されたものです。これは開発やテストには適していますが、本番稼働用ワークロードには適していません。AWS は外部コンテンツの機能または適合性について責任を負いません。この署名プロキシを使用すると、1 つ以上の AWS アカウントまたは IAM ユーザーにアクセスを許可、または拒否する テンプレートを使用して、ドメインのポリシーを次のように設定できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/susan"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }
  ]
}

 

ユーザー ARN と赤のドメイン ARN を生成されたポリシーからのものに置き換えます。プロキシを実行し、127.0.0.1:9200 でリッスンします。次に、curl を使用して Elasticsearch API 呼び出しを http://127.0.0.1:9200/ に送信すると、それらが使用するドメインに転送されます。開発マシン上で Kibana をローカルで実行する場合は、kibana.yml のhttp://127.0.0.1:9200/ を参照してください。

CloudTrail を使用してアクセスポリシーの変更を監視する
Amazon CloudTrail は、さまざまなサービスと対話するときに AWS に送信されるリクエストのログを提供します。Amazon Elasticsearch Service は、ドメインの作成、ドメイン設定の更新、タグの追加など、すべての管理アクションに対して CloudTrail イベントを送信します。CreateElasticsearchDomain および UpdateElasticsearchDomainConfig API 呼び出しの CloudTrail イベントを監視して、組織内のユーザーがドメインを作成または変更するときにアクセスポリシーを検証することをお勧めします。これらのログを使用して、すべてのアクセスポリシーを確認し、前述のプラクティスに準拠していることを確認できます。

まとめ
これで、テストと開発の際にニーズに合ったアクセスポリシーを簡単に設定できることを示すことができたと考えています。ご質問、コメント、ご提案があれば、コメントに投稿してください。

Scaling Your Amazon RDS Instance Vertically and Horizontally

Marie Yap はアマゾン ウェブ サービスのソリューションアーキテクトです。

Amazon RDSは、マネージド型サービスとして、リレーショナルデータベースのスケーリングを処理し、データベースがアプリケーションやアプリケーションの増加する要求に対応できるようにします。

このブログ記事では、RDS インスタンスを縦横に拡大縮小する方法について説明します。ほぼ同じ数の読み取りと書き込みを使用するアプリケーションの増加する要求に対応するために、垂直方向に拡大縮小することができます。また、読み取りが重いアプリケーションの場合は、水平方向に拡大縮小することもできます。

垂直スケーリング
データベースの高い負荷を処理するために、ボタンを押すだけでマスターデータベースを垂直方向にスケールアップできます。現在、RDS MySQL、PostgreSQL、MariaDB、Oracle、または Microsoft SQL Server インスタンスのサイズを変更する際に、18 種類以上のインスタンスサイズを選択できます。Amazon Aurora では、5 つのメモリ最適化インスタンスサイズを選択できます。インスタンスタイプを幅広く選択することで、データベースサーバーに最適なリソースとコストを選択できます。

以下は、RDS インスタンスをスケールアップする際の考慮事項です。

  • スケールを変更する前に、商用エンジン (SQL Server、Oracle) の正しいライセンスを取得していることを確認してください (特に、ライセンス持ち込み (BYOL) が必要な場合)。重要なことは、商用エンジンの場合はライセンスによって制限されていることです。ライセンスは、通常 CPU ソケットまたはコアに関連付けられています。
  • 変更をいつ適用するかを決めます。変更をすぐに適用するか、インスタンスで指定されたメンテナンス期間中に変更を適用するかを選択できます。
  • ストレージとインスタンスのタイプは切り離されています。データベースインスタンスを上下にスケールしたときは、ストレージサイズは同じままで、変更の影響を受けません。DB インスタンスを個別に変更して、割り当てられたストレージスペースを増やすか、ストレージタイプを変更して (一般目的 SSD からプロビジョニング IOPS SSD などに) パフォーマンスを向上させることができます。
  • スタンバイデータベースが最初にアップグレードされた後で、新しくサイズの変更されたデータベースでフェイルオーバーが発生するため、Multi-AZ 環境でスケールアップする場合のダウンタイムは最小限に抑えられます。シングル AZ インスタンスは、スケール操作中は使用できません。

インスタンスのタイプを変更するには、RDS コンソールの [インスタンスの操作] メニューから [変更] を選択します。

次に、新しい DB インスタンスクラスを選択します。

最後に、変更をすぐに適用するかどうかを決定します。変更をすぐに適用するには、[変更] ページの一番下にある [すぐに適用] チェックボックスを選択します。変更をすぐに適用しないと、定義した優先メンテナンスウィンドウ中に変更がスケジュールされます。

水平スケーリング
マスターデータベースを垂直方向に拡張するだけでなく、読み取りレプリカを使用してデータベースを水平方向に拡大することによって、読み取りが重いデータベースのパフォーマンスを向上させることもできます。RDS MySQL、PostgreSQL、MariaDB には最大 5 つのリードレプリカがあり、Amazon Aurora には最大 15 のリードレプリカがあります。

リードレプリカを使用すると、マスターデータベースと同期する読み取り専用コピーを作成できます。より良いパフォーマンスを得るために、リードレプリカをユーザーにより近い別の AWS Region に配置することもできます。また、リードレプリカをマスターに昇格させることで、リードレプリカを使用してデータベースの可用性を高め、災害時の迅速なリカバリーを行うことができます。ただし、リードレプリカは、Multi-AZ が提供する高可用性と自動フェイルオーバー機能の代替となるものではありません。

現在、RDS リードレプリカは、クエリまたは接続の透過的なロードバランシングをサポートしています。各レプリカには固有のドメインネームサービス (DNS) エンドポイントがあり、アプリケーションはレプリカエンドポイントに接続してロードバランシングを実装できます。では、アプリケーションで RDS リードレプリカを認識させる方法のオプションを見てみましょう。

アプリケーションがネイティブの MySQL ドライバを使用している場合は、アプリケーションに大きな変更を加えることなく、読み取り/書き込み分割と読み取り専用のエンドポイントロードバランシングを実行できる MySQL Connector があります。たとえば、PHP アプリケーションをお持ちの場合は、MySQL ネイティブドライバの PHP Mysqlnd レプリケーションとロードバランシングプラグインを使用できます。

MySQL Connector を使用することに加えて、アプリケーションとデータベースサーバの間にロードバランサを追加することができます。アプリケーションに単一のデータベースエンドポイントが表示されるように、この追加を行います。このアプローチでは、アプリケーションのデータベース接続文字列を絶えず更新することなく、ロードバランサの背後にあるリードレプリカを透過的に追加または削除できるより動的な環境が可能になります。また、スクリプトを使用してカスタムヘルスチェックを実行することもできます。

図に示すように、トランスポートまたはレイヤ 4 ロードバランサを MySQL Connector とともに使用できます。現在、Elastic Load Balancing (ELB) ロードバランサは、RDS インスタンスへのトラフィックのルーティングをサポートしていません。したがって、多くの人が使用するオープンソースのソフトウェアベースのロードバランサである HAProxy などのオプションを検討することもできます。このソリューションでは、1 つのポートで読み込みクエリを受信し、もう 1 つのポートで書き込みクエリを受信するように HAProxy を構成できます。

もう 1 つの選択肢は、レイヤ 7 の SQL 対応ロードバランサを使用することです。複雑なルールを使用してデータベースにクエリを転送することができます。このタイプのロードバランサは、マルチステートメントで読み書きスプリットを適切に実行する方法を理解する、MySQL Connector よりも洗練された機能を備えています。このソリューションは、分散データベース環境でスケーリングの問題を処理するため、アプリケーション層のスケーリングを処理する必要がないため、アプリケーション自体にはほとんど変更が加えられません。これを実現するには、MaxScale、ProxySQL、MySQL Proxy などのオープンソースソリューションと商用ソリューションがあります。そのうちのいくつかは AWS Marketplace にあります。

まとめ
要約すると、アプリケーションの増加するニーズに対応するために、RDS 構成を拡張または縮小することができます。RDS はデータベースのスケーリングに大いに役立つため、お客様はアプリケーションやアプリケーションにより集中できるようになります。

 

Amazon QuickSight の更新 – 地理空間の可視化、プライベートVPCアクセス、その他

AWSでは記念日を敢えて祝うことはあまりしません。100近いサービスによって、週に何度もアップデートを展開するのが当たり前になっています。(まるで週に何度もケーキを食べて、 シャンパンを飲んでいるようなものです。)それは楽しそうに聞こえますが、我々はむしろ、お客様に耳を傾け、イノベーションを起こすことに多くの時間を費やしています。とは言うものの、 Amazon QuickSight は一般提供開始から1年が経ちましたので、簡単にアップデートを紹介したいと思います!

QuickSight の事例

本日、数万のお客様(スタートアップからエンタープライズまで、交通や法律、鉱業、医療などの様々な業界)がお客様のビジネスデータの分析とレポートのためにQuickSightを利用されています。

幾つか例を上げましょう。


Gemini は負傷した労働者を弁護するカリフォルニア弁護士に法的根拠の調達サービスを提供しています。彼らは、カスタムレポートの作成や一度限りのクエリの実行から、ドリルダウンとフィルタリングを使用した動的なQuickSightダッシュボードの作成と共有までを行っています。QuickSightは、販売パイプラインの追跡、注文のスループットの測定、注文処理パイプラインでのボトルネックの特定に使用されています。

Jivochat はウェブサイト訪問者とウェブサイトの所有者とを繋ぐ、リアルタイムメッセージングプラットフォームを提供しています。QuickSightを使用して、彼らはインタラクティブなダッシュボードを作成・共有しながら、元となるデータセットへのアクセスも提供しています。これにより、静的なスプレッドシートを共有するにとどまらず、誰もが同じデータを見ていることを保証し、現時点でのデータに基づいてタイムリーな決定を下すことを後押ししています。

Transfix は、小売業、食品・飲料、製造業およびその他の業種のFortune 500に名を連ねるリテールの荷送主に、荷物にマッチする配送業者を選択でき、ロジスティクスの可視性を高める、オンライン貨物市場です。QuickSightはBIエンジニアと非技術系ビジネスユーザーの両方に分析環境を提供しています。彼らはQuickSightを通じて、輸送ルート、運送業者効率性、プロセス自動化などのビジネスの鍵となる事柄や運営指標を吟味しています。

振り返り / 先読み
QuickSightに対するフィードバックはとても役に立っています。お客様は、自社のBIインフラを設定または実行することなく、従業員がQuickSightを使用してデータに接続し、分析を実行し、データに基づいた高速な決定を下すことができていると教えてくれます。我々は頂いたフィードバックをすべて歓迎し、それを使用してロードマップを推進し、1年で40を超える新機能を導入してきました。以下はその要約です:

今後のことを考えると、お客様に興味深い傾向が見られます。データの分析方法やレポート方法を詳しく見ていくうちに、サーバーレスのアプローチがいくつかの目に見えるメリットをもたらすことに気づき始めるのです。彼らは、Amazon Simple Storage Service (S3) をデータレイクとして使用し、QuickSight と Amazon Athena のコンビネーションによってクエリを実行することで、静的なインフラストラクチャ無しに迅速で柔軟な分析環境を手にしています。また、QuickSightのダッシュボード機能を活用し、ビジネスの結果や運用メトリクスを監視し、数百人のユーザーと彼らの洞察を共有しています。もしこのようなアプローチに興味がある場合は、Building a Serverless Analytics Solution for Cleaner Cities のブログポストや、 Severless Big Data Analytics using Amazon Athena and Amazon QuickSight  のスライドを御覧ください。

新しい機能の追加と拡張
我々は、QuickSightが今後もお客様のニーズを満たすことを確認するために、お客様の声を聞き、それを学ぶことにベストを尽くしています。そして以下の7つの大きな機能をアナウンスできることを幸福に思います:

地理空間の可視化 – 位置情報データセットを地理空間に可視化することが可能になります。

プライベートVPCアクセス – VPC内、またはオンプレミスデータに対し、パブリックなエンドポイント無しにセキュアに接続できる新しい機能のプレビューに参加することができます。

フラットテーブルのサポート – ピボットテーブルに加えて、表形式レポート用のフラットテーブルを使用することができます。詳しくは Using Tabular Reports を参照ください。

SPICE上のデータに対して計算フィールドを適用する – SPICE上のデータに対して計算フィールドを適用することができます。詳しくは 分析への計算フィールドの追加 を参照ください。

ワイドテーブルのサポート – テーブルあたり1000カラムまで使用することができます。

「その他」をまとめて表示 – カーディナリティの高いロングテールデータを、「その他」としてまとめて表示することができます。詳しくは Amazon QuickSight でビジュアルタイプを使用する を参照ください。

HIPAA コンプライアンス – QuickSightでHIPAAコンプライアンス準拠のワークロードに対応できます。

地理空間の可視化
お待たせしました!地理的な識別子(国、都市、州または郵便番号)を含むデータから、数回のクリックで美しいビジュアルを作成できるようになりました。QuickSightはそれらのデータをマップ上の位置情報に変換しますし、緯度/経度にも対応しています。この機能を使用して、州ごとの売上を視覚化したり、店舗を配送先にマップしたりすることができます。視覚化のサンプルは次のとおりです。

詳しくは、Using Geospatial Charts (Maps) , と Adding Geospatial Data を参照ください。

プライベートVPCアクセスのプレビュー
もしあなたがAWS上(もしかすると Amazon RedshiftAmazon Relational Database Service (RDS)  、または EC2上かもしれません)または、パブリック接続の無いオンプレミス上のTeradataやSQL Serverにデータを保持している場合、この機能はあなたのためにあります。QuickSightのプライベートVPCアクセスは、ENIを使用してセキュアに、プライベートにVPC内のデータソースにアクセスします。AWS Direct Connect を使用してセキュアに、オンプレミス上のリソースにプライベートリンクを貼ることもできます。以下のような形です。

プレビューに参加する準備ができている場合、本日からサインアップ可能です。 

Jeff;

(翻訳:SA八木、元の記事はこちらです)