Category: General


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八木、元の記事はこちらです)

【変更版】11 月の AWS Black Belt オンラインセミナーのご案内

※11/20追記

直前のお知らせとなり申し訳ありません。11/21(火) 12:00-13:00に開催を予定しておりました「AWS上の位置情報」ですが、講師の都合により延期となりました。事前登録いただいておりました皆様、申し訳ございませんでした。また、改めて開催予定日を案内させていただきます。

 

こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー11月の配信についてご案内させて頂きます。初めてご紹介するNLB (Network Load Balancer) を中心としたELBのセッションをはじめ、今月も様々なテーマを取り扱います。

また今年もAWS re:Inventの開催期間中に現地からの生中継で最新アップデートをお伝えする回を予定しておりますので、こちらもぜひご登録いただければと思います。

 

 

 

 

 

 

 

 

 

11月の開催予定

サービスカット
11/1(水) 18:00-19:00 Amazon EMR
11/15(水) 18:00-19:00 ELB Update – Network Load Balancer(NLB)と関連サービス
11/22(水) 18:00-19:00 AWS WAF – OWASP Top10脆弱性緩和策 –

ソリューションカット
11/9(木) 12:00-13:00 Amazon Pinpoint で始めるモバイルアプリのグロースハック  ※ 通常の開催曜日と異なりますのでご注意ください
12/1(金) 12:00-13:00 AWS re:Invent 2017 Report  ※ 通常の開催曜日と異なりますのでご注意ください。また12月開催ですが先行告知させて頂きます

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

 

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

こんにちは。プロフェッショナル サービスの宮本です。AWS Black Belt オンラインセミナー12月の配信についてご案内させて頂きます。サービスカットは、10/24 に Generally Available を迎えた Amazon Aurora with PostgreSQL Compatibility をはじめ、今月も様々なテーマを取り扱います。また、ソリューションカットは、「AWSサービスを利用したアプリケーション開発を始めよう」と題して、AWSにおけるアプリケーション開発に活用できる様々なサービスについてご紹介や、AWSにおけるIPv6のサポート状況についてご紹介します。

 

 

 

 

 

 

 

 

 

 

 

 

12月の開催予定

サービスカット
12/6(水) 18:00-19:00 Amazon Elasticsearch Service
12/14(木) 18:00-19:00 Amazon ElastiCache ※ 通常の開催曜日と異なりますのでご注意ください。
12/20(水) 18:00-19:00 Aurora PostgreSQL

ソリューションカット
12/1(金) 12:00-13:00 AWS re:Invent 2017 Report  ※ 通常の開催曜日と異なりますのでご注意ください。
12/5(火) 12:00-13:00 AWSのIPv6対応
12/12(火) 12:00-13:00 AWSサービスを利用したアプリケーション開発を始めよう

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

Amazon Aurora Under the Hood: クオーラムメンバーシップ

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。

この記事は、Amazon Auroraがどのようにクオーラムを使用するのかをお話する4回シリーズの最後です。最初の記事では、障害が発生した場合に必要なクォーラムのメリットとメンバの最小数について説明しました。2回目の記事では、読み書きを行う際に利用するネットワーク帯域の増加を避けるために、ロギング、キャッシュの状態、および非破壊的な書き込みを使用する方法について説明しました。3回目の記事では、より高度なクォーラムモデルを使用して複製コストを削減する方法について説明しました。クォーラムに関するこの最後の記事では、クォーラムメンバーシップの変更を管理する際にAmazon Auroraが問題を回避する方法について説明します。

クオーラムメンバーシップの変更を管理するテクニック
マシンは故障します。クオーラムメンバの1つが破損すると、ノードを交換することによってクオーラムを修復する必要があります。これは複雑な決定になります。 クォーラムの他のメンバーは、障害のあるメンバに一時的なレイテンシーの増加が発生したか、再起動のための短期間の可用性低下が発生したか、または永久にダウンしたかどうかを判断できません。 ネットワークパーティションにより、複数のメンバーグループが同時にお互いに隔離を実行出来ます。

ノードごとに大量の永続状態を管理している場合、クォーラムを修復するための状態の再複製には長い時間がかかります。 そのような場合、障害のあるメンバーが復帰できる場合に備えて修復を開始することについて慎重に行う必要があります。 多くのノードで状態をセグメント化することで、修復時間を最適化することができます。 しかし、これは失敗の可能性を高めます。

Auroraでは、データベースボリュームを10GBのチャンクに分割し、3つのアベイラビリティゾーン(AZ)に分散した6つのコピーを使用します。 現在の最大データベースサイズが64TBなので、プロテクショングループは6,400個、セグメント数は38,400個です。 このスケールでは破損は一般的に発生する可能性があります。 メンバーシップの変更を管理する一般的な方法は、一定期間リースを使用し、各リースでメンバーシップを確保するためにPaxosなどのコンセンサスプロトコルを使用することです。 しかし、Paxosは処理負荷のかかるプロトコルであり、最適化されたバージョンでは多数の障害が発生します。

障害を管理するためにクオーラムセットを利用する
Auroraはメンバーシップの変更を管理するために、ロギング、ロールバック、コミットなどのクォーラムセットとデータベース技術を使用します。 A、B、C、D、E、Fの6つのセグメントを持つプロテクショングループを考えてみましょう。この場合、書き込みクォーラムはこの6組のうち4つのメンバーであり、読み取りクォーラムは3つのメンバーです。 前回の記事でご紹介したように、Auroraのクオーラムはこれよりも複雑ですが、今は単純に考えてみることにします。

Auroraの読み書きはそれぞれ、メンバーシップエポックを使用します。これは、メンバーシップの変更ごとに単調に増加する値です。 現在のメンバーシップエポックよりも古いエポックにある読み取りと書き込みは拒否されます。そのような場合、クオーラムメンバーシップの状態をリフレッシュする必要があります。 これは、概念的には、REDOログ内のlog sequence numbers(LSN)の概念に似ています。 エポックナンバーおよび関連する変更記録は、メンバーシップに順序付けられたシーケンスを提供します。 メンバーシップエポックを変更するには、データ書き込みと同様に書き込みクォーラムを満たす必要があります。 現在のメンバーシップの読み込みには、データの読み込みと同様のリードクオーラムが必要です。

ABCDEFのプロテクショングループの話を続けましょう。セグメントFが破損した可能性があるとし、新しいセグメントGを導入する必要があると考えてください。一時的な障害に遭遇する可能性があり、迅速に復帰する可能性があります。またはリクエストを処理しているかもしれませんが、なんらかの理由で検出出来ない可能性があります。また、Fが復活したかどうかを確認するのを待ちたくはありません。クオーラムが損なわれて2回目の障害が発生する可能性が増加だけです。

これを解決するためにクォーラムセットを使用します。 私たちはABCDEFからABCDEGに直接メンバーシップの変更をすることはありません。代わりに、メンバーシップのエポックを増やし、クォーラムセットをABCDEFとABCDEGに移動します。書き込みはABCDEFの6つのコピーのうち4つから正常に行われなければならず、またABCDEGの6つのコピーのうち4つからackが返る必要があります。 ABCDEのどの4つのメンバーは両方とも書き込みクォーラムを満たしています。 読み取り/修復クォーラムは同じように動作し、ABCDEFからの3つのackとABCDEGから3つのackが必要です。ABCDEからの3つのいずれかが両方を満たします。

データがノードG上に完全に移動され、Fを取り除くと決定した場合、メンバーシップエポックの変更を行い、クォーラムセットをABCDEGに変更します。エポックの使用は、コミットLSNがREDO処理のために行うのと同様に、これをアトミックに行います。このエポックの変更は、現在の書き込みクォーラムが満たされている必要があり、他のアップデートと同様に、ABCDEFの6つのうち4つと、ABCDEGの6つのうちの4つからのackが必要です。Gが利用可能になり前に再びノードFが利用可能になると、変更を元に戻しメンバーシップエポックの変更をABCDEFに戻します。完全に健全なクオーラムに戻るまで、いかなる状態やセグメントも破棄しません。

このクォーラムへの読み書きは、メンバーシップの変更中に、変更前または変更後と同じように行われることに注意してください。 クォーラムメンバーシップへの変更は、読み取りまたは書き込みをブロックしません。失効したメンバーシップ情報を持つ呼び出し元は、状態をリフレッシュして正しいクォーラムセットに要求を再発行します。また、クオーラムメンバーシップの変更は、読み取り操作と書き込み操作の両方に対して非ブロッキングです。

もちろん、Fの代わりにGへデータを移動しクオーラムを修復している間にABCDEGのいずれかが破損する可能性もあります。多くのメンバーシップ変更プロトコルはメンバーシップの変更中に障害を柔軟に処理しません。クォーラムセットとエポックでは、簡単です。Eも破損してHに置き換えられる場合を考えてみましょう。ABCDEFとABCDEGとABCDFHとABCDGHのクオーラムに移動するだけです。単一障害と同様に、ABCDへの書き込みはこれらのすべてを満たします。メンバーシップの変更は、読み取りと書き込みの失敗と同じ範囲になります。

まとめ
クォーラムセットをメンバーシップの変更に使用することにより、Auroraは小さなセグメントを使用することができます。これにより、Mean Time To Repair(MTTR)および複数の障害に対する可能性を削減することで、耐久性が向上します。また、お客様のコストを削減します。Auroraのボリュームは必要に応じて自動的に増加し、小さなセグメントでは少しずつ増加します。クォーラムセットを使用することで、メンバーシップの変更が行われている間も読み取りと書き込みが継続できるようになります。

メンバーシップの決定を元に戻すことができれば、積極的にクオーラムを変更することができます。障害のあったメンバーが返ってくると、いつでも変更を元に戻すことができます。いくつかの他のシステムでは、リースが期限切れとなり、クオーラムメンバシップを再確立する必要があるため、定期的な停止が発生します。Auroraは、リースが期限切れになるまでメンバーシップの変更操作を延期するという耐久性の犠牲を払わず、クオーラムメンバシップが確立されている間に読み込み、書き込み、またはコミットを遅らせるというパフォーマンス上のペナルティも発生しません。

Auroraは、さまざまな分野で進歩を遂げています。データベースと分散システムを統合するアプローチは、これらの多くの中核を成しています。クォーラムをどのように使用するかについてのこの連載をご覧いただき、ご自身のアプリケーションやシステムを設計する方法について考えるときに役立てて頂けると思います。今回使用した手法は広く適用可能ですが、スタックの多くの要素にに対して適用する必要があります。

もしご質問などありまししたら、コメントもしくは aurora-pm@amazon.comにご連絡下さい。

翻訳は星野が担当しました (原文はこちら)

AWSの自社認証局への移行に備える方法

AWS Certificate Manager image

TLS (Transport Layer Security, 以前は SSL と呼ばれていました) はインターネットでやりとりされる情報を暗号化するために不可欠です。例えば、Amazon.com ではウェブサイト上の全トラフィックに TLS を使用していますし、AWS は AWS サービスへの安全な呼び出しに使用しています。

証明書と呼ぶ電子ドキュメントは、暗号化した接続を行う際にサーバのアイデンティティを証明します。アドレスバーに入力した Web サイトとブラウザが安全に通信しているかを検査するのに証明書は役立ちます。CA としても知られている 認証局 は、特定のドメイン名に対して証明書を発行します。ドメインが信頼された認証局から発行された証明書を提示すると、ブラウザやアプリケーションは通信を行っても安全だとわかります。

2016年 1月、AWS は AWS Certificate Manager (ACM) の提供を開始しました。このサービスは、AWS サービスで使用できる SSL/TLS 証明書を簡単に作成、管理できるようにします。証明書にはアマゾンの自社認証局 Amazon Trust Services から発行されたものを追加料金無しで利用できます。ブラウザやその他のアプリケーションが証明書を信頼するには、証明書の発行者がブラウザなどが信頼している認証局一覧である 信頼ストア に含まれている必要があります。もし信頼ストアに発行した認証局が含まれていない場合は、ブラウザはエラーメッセージ(参考例)を表示したり、アプリケーションは独自のエラーを表示します。AWS は Amazon Trust Services 認証局 があらゆるところで確実に使えるようにするために、2005年以降のほとんどのブラウザで信頼されているルート認証局である Starfield Services の認証局の一つを購入しました。これは Amazon Trust Services で発行された証明書を使うために何もする必要が無いことを意味しています。

AWS は Amazon Trust Services 認証局 からお客様に無料の証明証を提供してきました。これより AWS は Amazon EC2Amazon DynamoDB などのサービスにも Amazon Trust Services からの証明書を使用するよう移行して行きます。このブログ記事では、Amazon Trust Services 認証局を使う準備ができているか検証する方法について説明します。

証明書ストアに Amazon Trust Services の認証局群が含まれているか確認する

次の表は Amazon Trust Services の証明書一覧です。これらの証明書が使用しているブラウザの信頼ストアに含まれているか確認するには、表にあるそれぞれの Test URL をクリックして正常に表示されるか確認して下さい。問題がある場合は、この例 のようにエラーが表示されます。

識別名 (DN) サブジェクトの公開鍵 SHA-256 ハッシュ Test URL
CN=Amazon Root CA 1,O=Amazon,C=US fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2 Test URL
CN=Amazon Root CA 2,O=Amazon,C=US 7f4296fc5b6a4e3b35d3c369623e364ab1af381d8fa7121533c9d6c633ea2461 Test URL
CN=Amazon Root CA 3,O=Amazon,C=US 36abc32656acfc645c61b71613c4bf21c787f5cabbee48348d58597803d7abc9 Test URL
CN=Amazon Root CA 4,O=Amazon,C=US f7ecded5c66047d28ed6466b543c40e0743abe81d109254dcf845d4c2c7853c5 Test URL
CN=Starfield Services Root Certificate Authority – G2,O=Starfield Technologies\, Inc.,L=Scottsdale,ST=Arizona,C=US 2b071c59a0a0ae76b0eadb2bad23bad4580b69c3601b630c2eaf0613afa83f92 Test URL
Starfield Class 2 Certification Authority 2ce1cb0bf9d2f9e102993fbe215152c3b2dd0cabde1c68e5319b839154dbb7f5 Test URL

証明書ストアに Amazon Trust Services の認証局群が含まれていなかった時に何をすべきか

Test URL の確認がどれか 1 つでも失敗した場合は、信頼ストアをアップデートする必要があります。信頼ストアをアップデートする最も簡単な方法は、使用している OS や ブラウザをアップグレードすることです。以下の OS では Amazon Trust Services の証明書群が含まれています。:

  • Microsoft Windows Vista, Windows 7, Windows Server 2008 以降のバージョン(2005年 1月以降のパッチがインストールされていること)
  • Mac OS X 10.4 with Java for Mac OS X 10.4 Release 5, Mac OS X 10.5 以降のバージョン
  • Red Hat Enterprise Linux 5 (2007年3月), Linux 6, and Linux 7 and CentOS 5, CentOS 6, and CentOS 7
  • Ubuntu 8.10
  • Debian 5.0
  • Amazon Linux (全バージョン)
  • Java 1.4.2_12, Jave 5 update 2 以降のバージョン、Java 6, Java 7, Java 8 含む

全ての最新ブラウザはアマゾンの認証局を信頼しています。単にブラウザをアップデートする事で、ブラウザの証明書バンドルをアップデートすることができます。ブラウザをアップデートする手順はそれぞれの Web サイトで確認する事ができます。:

もしアプリケーションが独自の信頼ストアを使用している場合は、アマゾン ルート認証局群 をアプリケーションの信頼ストアに登録頂く必要があります。登録手順はアプリケーションやプラットフォームによって異なります。使用しているアプリケーションやプラットフォームのドキュメントを参照して下さい。

AWS SDK や CLI

ほとんどの AWS SDK や CLI は Amazon Trust Services 認証局への移行の影響を受けませんが、もし 2013年 10月 29日 より前にリリースされた Python の AWS SDK や CLI を使用している場合は、アップグレードする必要があります。.NET, Java, PHP, Go, JavaScript, C++ の SDK や CLI には証明書は含まれておらず、基礎となる OS から証明書が来ています。Ruby SDK では 2015年 6月 10日以降 は必要な認証局の少なくても1つが含まれています。それより前の Ruby V2 SDK には証明書が含まれていません。

証明書ピンニング

証明書ピンニング (certificate pinning) と呼ばれる手法を使ってドメインごとに信頼する認証局を限定している場合、ピンニングを調整して Amazon Trust Services 認証局を追加する必要があります。証明書ピンニングは、不正な証明書を使いアプリケーションを騙して違法ななりすましサイトへ接続させようとする攻撃への防御に役立ちます。特定の固定された証明書への制限は、送られてきた証明書が期待される証明書であることを確認することによって行われます。これは、サーバから受信した証明書の公開鍵のハッシュがアプリケーションが対象ドメインについて保存し期待しているハッシュと一致するかどうかをチェックすることによって行われます。もしハッシュが一致しなければ、アプリケーションは接続を中止します。

AWS は、証明書ピンニングの使用は将来的な可用性リスクを招くため、推奨していません。もしピンニングしている証明書が置き換えられると、アプリケーションは接続が行えなくなってしまいます。ピンニングが必要なユースケースの場合は、個々の証明書ではなく認証局をピンニングすることを推奨します。Amazon Trust Services 認証局をピンニングする場合、このブログ記事記載の全ての認証局全てをピンニングすべきです。

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

– Jonathan

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

※本記事を公開した2017/11/7の際、AWS CLIやPython SDK は 2015年2月5日 より古いバージョンを使っている場合に更新が必要としていましたが、2013年10月29日より古いバージョンが更新必要と修正させていただきます。

アプリ内にボイスインターフェースを開発する方法 Astro Technology

今回のブログは Astro Technology, Inc. の CTO である Roland Schemers 氏より寄稿いただきました。Astro は同社について次のように説明しています。「当社はユーザーやチーム向けに開発した人工知能を使用する Mac や iOS および Android 用のメールアプリを製作しています。アプリ内のメールボイスアシスタント、Astrobot Voice を使えば、Astro アプリを終了せずにメールを読んだり返信することができます。」

そして最近では Astrobot Voice という初のアプリに組み込まれているメールボイスアシスタントをリリースしたばかりです。これにより、iOS 向け AstroAndroid 向けアプリを終了する必要なく、メールの読み取り、管理、返信が可能になりました。

Astro が 6 月に Amazon Alexa スキルをリリースしてから、我々はより多くのユーザーが音声でメール管理をできるようにしたいと考えました。そこで、今回のブログではなぜ我々がこうした選択を取ったのか技術面から説明し、どのようにこれを実現しどういったテクノロジーを使用したのかご説明します。

アプリ内ボイスを構築する理由は?

当社では Amazon Echo を愛用しています。実際、Astro の新入社員には「ようこそ」という意味はもちろん、我々の Alexa スキルを社内で試験運用することを兼ねて、各自に Echo Dot を提供しています。結果として私達のスキルが上々であることが分かり、より多くのユーザー、そしてさらに様々な場所で取り入れられる方法を新たに見つけることもできました。そこでアプリ内ボイスを構築できるか、その可能性を探ってみることにしたのです。

ソフトウェアの選択

アプリ内ボイスの構築方法を決定する上で、我々はいくつものオプションを検討しましたが、その上でいくつかのポイントを念頭に置きました。

  1. まず、当社のテキストベースアシスタント (api.ai で実行) または Alexa スキルからできるだけ多くのコードやロジックを再使用することです。
  2. そして、正確な音声認識を使用してスムーズなユーザーエクスペリエンスを製作すること。
  3. さらに、手間の掛かる作業はサーバーに任せることです。

我々のタイムラインとエンジニアリングのリソースを考えると最初のポイントは重要でした。当社は小規模のスタートアップ企業なので、そうした時間の節約は大いに役立つからです。

そして、2 つめのポイントであるスムーズなユーザーエクスペリエンスを作ることは特にチャレンジでした。スケールといった点で Amazon Alexa の自然言語処理のレベルは明らかに優勢でした。そのため、正確性を伴うエクスペリエンスを作ろうとする上で、AWS サービスやそのディープラーニングテクノロジーを活用したいという点は我々にとって明白でした。

そして 3 つめのポイントにおいては、Astrobot Voice に OS レベルの API とサーバー側における開発の組み合わせが必要であることが分かっていました。初期導入では、コストを抑えながら大方の手間が掛かる作業をサーバーが行うようにしました。大方の作業をサーバーに任せることのメリットには、iOS と Android アプリ両方で共有するコード、そしてアプリストアに Astro アプリの更新したバージョンをプッシュする必要なく、サーバーでフロー変更を行えるようにするといった点があります。

スタック

iOS

音声認識の iOS API には AVSpeechSynthesizerSFSpeechRecognizer を使用しました。SFSpeechRecognizer は iOS 10+ でのみ利用することが可能なので、Astrobot Voice は iOS 10 および 11 でのみ使用できます。そのためアプリ開発者にとってこれが制限の要因になることもあるかもしれませんが、当社においては問題ありませんでした。

Android

Android では音声認識にスタンダード Android API を使用しました。これには Speech RecognizerText To Speech が含まれています。

iOS そして Android のどちらにおいても、サーバーが記録したテキストまたはテキストストリングを送信できるオプションもありました。コスト、時間的制約、レイテンシーを考慮した上で、当社では後者のオプションを選ぶことにしました。

サーバー

サーバー側では Amazon Lex を使用しました。api.ai ではなく Amazon Lex を選んだことで、すでに Alexa と同じロジックの多くを再使用し共有することができました。テキストベースバージョンの Astrobot と同じロジックをいくつか再使用することもできましたが、最終的には時間節約と、より良いエクスペリエンスを提供できる Amazon Lex を使用することにしました。そうすることで開発者 1 人あたり約 2~4 週間ほど時間を節約できました。Astrobot Voice の開発そして我々の Alexa スキルを磨いていく上で、今後も時間を節約していくことができるでしょう。

この先、Astro の有料バージョンを提供する際には (現在、当社アプリは無料)、音声入力には Amazon Lex そして音声出力には Amazon Polly を当社のオンデバイス音声認識と置換することで、さらに AWS サービスを活用して行きたいと考えています。そうすることでボットエクスペリエンスの質を改善することができます。

次に Astrobot Voice エクスペリエンスを作成するために、こうしたサービスがどのように連動するのか、その流れとアーキテクチャを図で示しました。

(more…)

Cost allocation tagsについて

AWS リソースにタグを付け、タグごとにコストの内訳を確認する機能は、以前から提供されていました。コスト配分の機能は 2012 年に開始され (「お客様の請求のための AWS コスト配分」を参照)、当社はその他のサービスのサポートを安定して追加してきました。最も最近では DynamoDB (「Amazon DynamoDB 用のコスト配分タグの概要」)、Lambda (「AWS Lambda がタグ付けとコスト配分をサポート」)、EBS (「新規 – AWS Snapshots 用のコスト配分」) が追加されました。

本日は、Amazon Simple Queue Service (SQS) 用のタグベースのコスト配分を発表いたします。これにより、キューにタグを割り当て、それを使用して、アプリケーション、アプリケーションステージ (キューを介して通信する疎結合アプリケーション用)、プロジェクト、部署、開発者など、目的とするあらゆるレベルでコストを管理できます。キューにタグを付けたら、AWS Tag Editor を使用して、対象のタグが付けられたキューを検索できます。

私のキューの 1 つに 3 つのタグ (appstagedepartment) を追加する方法をご覧ください。

この機能はすべての AWS リージョンで今すぐご利用いただけます。タグ付けの詳細については、「Amazon SQS キューにタグを付ける」を参照してください。タグを使用したコスト配分の詳細については、「コスト配分タグの使用」を参照してください。メッセージキューを使用して最新のアプリケーション用の疎結合マイクロサービスを構築する方法については、当社のブログ投稿 (「Amazon SQS および Amazon SNS による疎結合のスケーラブルな C # アプリケーションの構築」) を参照するとともに、当社の最近のウェビナー (「Amazon SQS and Amazon SNS を使用したアプリケーションの切り離しとスケール」) をご覧ください。

AWS re:Invent に参加される方は、「ARC 330: How the BBC Built a Massive Media Pipeline Using Microservices」というセッションにご出席ください。この話の中で、BBC がどのように SNS と SQS を使って BBC iPlayer アーキテクチャの伸縮性と信頼性を改善したかがわかります。

Jeff;

Getting Ready for AWS re:Invent 2017

AWS re:Invent の開催まで後わずか 40 日となったので、私の同僚と私は、お客様がラスベガスでの時間を有効に活用するためのヒントをいくつかご紹介します。いつもどおり、トレーニングと教育に重点を置き、それ以外の時間にはお楽しみイベントやレクリエーションも用意されています。

場所、場所、場所
re:Invent Campus はラスベガス商業地全体にわたって行われ、MGM Grand、Aria、Mirage、Venetian、Palazzo、Sands Expo ホール、Linq Lot、Encore でイベントが開催されます。各施設では、特定のトピック専用のトラックをホストします。

MGM Grand – ビジネスアプリ、エンタープライズ、セキュリティ、コンプライアンス、アイデンティティ、Windows。

Aria – Big Data & Analytics、Alexa、コンテナ、IoT、人工知能 & 機械学習、サーバーレス。

Mirage – ブートキャンプ、認証 & 認定試験。

Venetian / Palazzo / Sands Expo ホール – アーキテクチャ、AWS Marketplace & Service Catalog、コンピューティング、コンテンツ配信、データベース、DevOps、モバイル、ネットワーキング、ストレージ。

Linq Lot – Alexa ハッカソン、Gameday、ジャムセッション、re:Play パーティー、講演者との交流 & 挨拶。

Encore予約可能な会議会場

複数のトピックにご関心をお持ちの場合は、施設間を往復する re:Invent シャトルバスの活用を計画してください。

数多くのコンテンツ
re:Invent Session Catalog が利用できるようになり、関心のあるセッションの選択を今すぐ行うことができます。

アジェンダには 1100 以上のセッションがあるため、計画は不可欠です。最も人気の高いいくつかの「詳細」セッションは複数回行われ、その他のセッションは他の会場のあふれた部屋にストリーミングされます。当社は多くのデータを分析し、いくつかのシミュレーションを実行して、アクション満載のスケジュールを作成するための複数の機会をお客様に提供するため最善を尽くしています。

お客様のセッションの席をまもなく予約できるようになります (Twitter で@awscloud、またはその両方をフォローして、お知らせをお待ちください)。過去のフィードバックに基づいて、席の予約モデルを微調整しました。今年は、各セッションの席の 75% が予約され、その他の 25% が事前予約なしの参加者用に提供されます。事前予約なしの参加者に対しては、セッション開始の 10 分前から入場を開始します。

ラスベガスは眠ることはありません。お客様もそれに合わせてください! 今年は、深夜のセッション、ワークショップ、チョークトーク、ハンズオンラボにより、夜も忙しくなります。

セッションやコンテンツの詳細については、re:Invent 2017 のコンテンツに備えるための概要ビデオをご覧ください。

お楽しみイベント
1 日のトレーニングや学習を十分に行った後は、パブ巡りre:Play パーティーTatonka チャレンジ (今年は 2 会場)、ハンズオン LEGO アクティビティHarley Ride への参加をご検討ください。また、4K ランスピニングチャレンジフィットネスブートキャンプブルームホール (Amazon の長期にわたる伝統行事) で健康を維持してください。

ベガスでお会いしましょう
いつもどおり、可能な限り多くの AWS ユーザーとブログの読者にお会いできることを楽しみにしています。どうか遠慮なく私を呼び止めて話しかけてください。

Jeff;

データウェアハウスをエクサバイト級に拡張するAmazon Redshift Spectrum

(補足:本記事は2017年7月にAWS Bigdata Blogにポストされた記事の翻訳です。一部の記載を現時点の状況に合わせて更新してあります)

何年も前、最初にクラウドベースのデータウェアハウスを構築する可能性について検討を始めた際、我々は、我々の顧客が増え続ける一方の大量のデータを持つ一方で、そのごく一部のデータのみが既存のデータウェアハウスやHadoopシステムに投入され分析に利用されているという事実に直面しました。同時に、これがクラウド特有の特殊事情ではないこともわかりました。エンタープライズストレージ市場の成長率がデータウェアハウス市場のそれを大きく上回る様々な業界においても、状況は同じだったのです。

我々はこれを“ダークデータ”問題と名付けました。我々の顧客は、彼らが収集したデータに利用されていない価値があることに気づいていました。そうでなければなぜそれを保管するコストをかけるでしょうか?しかしながら、彼らが利用できるシステムは、これらのデータ全てを処理するには遅すぎ、複雑すぎ、高すぎたため、データのサブセットのみを利用することになりました。彼らはいつか誰かが解決策を見出すことへの楽観的な期待とともに、これらのデータを保持し続けました。

Amazon Redshift はダークデータ問題の解決に寄与することから、AWSサービスの中でも最も成長の速いサービスの一つとなりました。このソリューションは大半の代替案に比べ、少なくとも一桁は安価で、かつ高速でした。また、Amazon Redshiftは当初からフルマネージドのサービスで、ユーザーはキャパシティやプロビジョニング、パッチ対応、監視、バックアップ等を始めとする様々なDBA課題について頭を悩ませる必要がありませんでした。 VevoYelpRedfin,Edmunds, NTTドコモなどの多くの顧客が、Amazon Redshiftに移行して、クエリー性能の改善、DBAオーバーヘッドの削減、そして分析コストの低減を実現しました。

我々の顧客のデータは、極めて速いペースで増え続けています。おしなべて、ギガバイトのデータはペタバイトとなり、平均的なAmazon Redshift顧客が分析するデータ量は毎年二倍になっています。我々が、増加するデータを扱う上でお客様の手助けとなる機能群を実装してきた理由はここにあります。例えばクエリースループットを二倍にする、圧縮率を三倍から四倍に改善する、といったことです。これらは、お客様がデータを破棄したり分析システムから削除したりすることを考慮せざるを得なくなる時期を遅らせることができます。しかしながら、ペタバイトのデータを日々生成するAWSユーザーが増えており、こうしたデータはわずか3年でエクサバイトの水準に達します。このようなお客様のためのソリューションは存在しませんでした。もしデータが毎年倍々になるのであれば、コスト・性能・管理のシンプルさに革新をもたらす、新たな、破壊的なアプローチを見付けることを強いられるまで、そう長い時間はかからないでしょう。

今日利用可能な選択肢に目を向けてみましょう。お客様は、Amazon EMRを用いて、Apache HiveなどのHadoopベースの技術を利用することができます。これは実際のところ、非常に素晴らしいソリューションです。抽出と変換のステップを経ることなく、Amazon S3上のデータを簡単かつ低コストで直接操作できるようになるからです。クラスターは必要な時に起動することができ、実行対象となる特定のジョブに合うよう適切にサイジングすることができます。こうしたシステムは、スキャンやフィルター、集計といったスケールアウト型の処理には最適です。一方で、これらのシステムは複雑なクエリー処理には向いていません。例えば、結合処理ではノード間でデータをシャッフルする必要が生じます。巨大なデータと多数のノードが存在する場合、この処理は極めて低速になります。そし結合処理は、重要な分析課題の大半において本質的に重要なものです。

Amazon Redshiftのような、列指向かつ超並列型のデータウェアハウスを利用することもできます。こうしたシステムは、巨大なデータセットに対する結合や集計といった複雑な分析クエリーを、単純かつ高速に実行することを可能にします。特に、Amazon Redshiftは、高速なローカルディスクと洗練されたクエリー実行、そして結合処理に最適化されたデータフォーマットを活用します。標準SQLを用いるので、既存のETLツールやBIツールを活用することもできます。一方で、ストレージとCPU双方の要件を満たすようにクラスターをプロビジョニングする必要があり、データロードも不可欠となります。

いずれのソリューションも強力な特長を備えていますが、お客様はどちらの特長を優先するかの判断を強いられます。我々はこれを「ORの抑圧(※)」と見做しています。ローカルディスクのスループットとAmazon S3のスケーラビリティは両立できない。洗練されたクエリー最適化と高度にスケールするデータ処理は両立できない。最適化されたフォーマットによる高速な結合処理性能と、汎用的なデータフォーマットを用いる様々なデータ処理エンジンは両立できない、などです。しかし、この選択は本来迫られるべきではありません。この規模においては、選択する余裕など到底ないからです。お客様が必要とするのは「上記の全て」なのです。

※ジム・コリンズが著書「ビジョナリー・カンパニー」で提示した概念。一見矛盾する力や考え方は同時に追求できない。

Redshift Spectrum

Redshift Spectrumは、こうした「ORの抑圧」に終止符を打つべく開発されました。Redshift Spectrumによって、Amazon Redshiftを利用されているお客様はAmazon S3上のデータに対し

簡単にクエリーを実行できるようになります。Amazon EMRと同様に、お客様はオープンなデータフォーマットと安価なストレージの恩恵を享受できます。データを抽出し、フィルターし、射影し、集計し、グループ化し、ソートするために、何千ものノードにスケールアウトすることも可能です。Amazon Athenaと同様に、Redshift Spectrumはサーバーレスであり、プロビジョニングや管理は必要ありません。単に、Redshift Spectrumを利用したクエリーが実行されている間に消費中のリソースに対してお支払いいただくだけです。Amazon Redshift自身と同様に、洗練されたクエリーオプティマイザー、ローカルディスク上のデータへの高速アクセス、そして標準SQLの恩恵を得ることができます。そして、他のどのようなソリューションとも異なり、Redshift Spectrumはエクサバイト級ないしはそれ以上のデータに対して、高度に洗練されたクエリーを、わずか数分で実行することが可能です。

Redshift SpectrumはAmazon Redshiftの組み込み機能の一つであり、お客様の既存のクエリーやBIツールはシームレスにご利用いただくことができます。背後では、我々は複数のアベイラビリティゾーンに跨がった何千ものRedshift Spectrumノードのフリートを運用しています。これらのノードは、処理する必要があるデータに基づいて透過的にスケールし、クエリーに割り当てられます。プロビジョニングや利用の確約は不要です。Redshift Spectrumは同時実行性にも優れています。お客様は任意のAmazon S3上のデータに対して、複数のAmazon Redshiftクラスターからアクセスすることができます。

Redshift Spectrumクエリーのライフサイクル

Redshift Spectrumクエリーのライフサイクルは、クエリーがAmazon Redshiftクラスターのリーダーノードに送信された時に始まります。リーダーノードはクエリーを最適化し、コンパイルし、その実行命令をAmazon Redshiftクラスターのコンピュートノード群に送ります。次に、コンピュートノード群は外部テーブルに関する情報をデータカタログから取得し、当該クエリーのフィルターと結合に基づいて、無関係なパーティションを動的に取り除きます。コンピュートノードはまた、ノード上でローカルに利用可能なデータを精査して、Amazon S3内の関連するオブジェクトだけを効率的にスキャンするようプレディケイトプッシュダウンを行います。

Amazon Redshiftコンピュートノードは、続いて、処理する必要のあるオブジェクトの数に基づいて複数のリクエストを生成し、それらをRedshift Spectrumに一斉に送ります。Redshift Spectrumは、AWSリージョンごとに何千ものAmazon EC2インスタンスをプールしています。Redshift SpectrumのワーカーノードはAmazon S3上のデータをスキャン、フィルター、集約し、処理に必要なデータをAmazon Redshiftクラスターにストリーミングします。その後、最終的な結合とマージの処理がクラスター内でローカルに実行され、結果がクライアントに返されます。

Redshift Spectrumのアーキテクチャーはいくつかのアドバンテージをもたらします。第一に、コンピュートリソースをAmazon S3のストレージレイヤーとは独立した形で、弾力的にスケールさせることができます。第二に、Amazon S3上の同一データに対して複数のAmazon Redshiftクラスターを起動しクエリーを実行できるため、(単一のAmazon Redshiftクラスターに比べて)ずっと高い同時実行性能を提供します。第三に、Redshift SpectrumはAmazon Redshiftのクエリーオプティマイザーを利用して効率的なクエリープランを生成します。これは複数テーブルの結合やWindow関数を伴う複雑なクエリーでも同様です。第四に、ソースデータをそれらのネイティブなフォーマット(Parquet、RCFile、ORC、CSV、TSV、Sequence、Avro、RegexSerDe、Grok等、さらに多くのフォーマットが今後追加される予定です)で直接操作することが可能です。このことは、データロードやデータ変換処理が不要であることを意味します。また、データを重複して保有することや、それに伴う追加のコストも不要にします。第五に、オープンなデータフォーマットを用いることで、単一のAmazon S3データを元に、様々なチーム間で他のAWSサービスや実行エンジンを柔軟に利用し協働することを可能にします。お客様はこれらのアドバンテージ全てを享受することが可能です。また、Redshift SpectrumはAmazon Redshiftの一機能であることから、Amazon Redshiftと同じレベルでのエンドツーエンドセキュリティ、コンプライアンス、および認定を得ることができます。

性能とコストパフォーマンスを目的とした設計

Amazon Redshift Spectrumでは、実際に実行したクエリーでスキャンされたデータ量の分のみ、お支払いいただきます。ファイル分割、列指向フォーマット、データ圧縮を利用してAmazon S3から読み取るデータ量を最小化することをお勧めします。これらはクエリー性能を大幅に改善しコスト削減にも寄与するため、データウェアハウスでは重要なファクターとなります。Amazon S3上のデータを日、時、およびその他のカスタムキーで分割することで、Redshift Spectrumは無関係なパーティションを動的に取り除き、処理対象のデータ量を最小化することができるようになります。データがParquetのような列指向フォーマットで保管されている場合には、Redshift Spectrumは行全体を処理する代わりに、当該クエリーによって必要とされる列だけをスキャンします。同様に、データがRedshift Spectrumでサポートされている圧縮アルゴリズムで圧縮されている場合は、スキャンされるデータはより少ない量で済みます。

Amazon RedshiftおよびRedshift Spectrumでは、両者のいわゆる「いいとこ取り」が可能となります。もし同一データに対する頻繁なクエリーを実行する必要があるなら、Amazon Redshiftにデータを保存することで、フル機能を持ち、構造化されたデータを定額で保存およびクエリーできるデータウェアハウスの利便性を享受できるでしょう。同時に、それが過去のデータであるか直近のデータであるかに関わらず、さらなるデータを複数のオープンフォーマットの形式でAmazon S3に保持して、Amazon Redshiftのクエリー機能をAmazon S3データレイクへと拡張することも可能です。

そしてもうひとつ、データロードが不要になること – これにより、Amazon Redshift Spectrumはデータウェアハウスをエクサバイト級にまで拡張します。Redshift Spectrumは「ORの抑圧」を終わらせます。お客様が、データを望む場所に望むフォーマットで保存し、必要な時に標準SQLを用いて高速に処理できる状態に置くことを、現在と将来にわたって可能にするのです。

 

参考文献

Amazon Redshift Spectrum 10 のベストプラクティス

著者について

Maor Kleider はAmazon Redshiftのシニアプロダクトマネージャーです。Amazon Redshiftは、高速、シンプルかつコスト効率のよいデータウェアハウスです。Maorはお客様およびパートナーの皆様と協働し、彼らの特有なビッグデータユースケースに付いて学び、その利用体験をよりよくすることに情熱を傾けています。余暇では、家族とともに旅行やレストラン開拓を楽しんでいます。

(翻訳はAWS プロフェッショナルサービス仲谷が担当しました。)

AWS支払の円払いへの切り替え方法について

先日のCloud Roadshow 2017 広島、名古屋、大阪では、KeyNoteの中でAWSの円払い対応および日本準拠法対応についてみなさんにご案内いたしました。本ブログの中で2回連載という形でそれぞれ、支払方法の円対応、日本準拠法切り替えについてご案内をいたします。

実は、AWSの支払い通貨変更機能は、2015年2月にお客様からのご要望受けて実現してる機能ですが、新しくAWSのご利用をご検討いただいている皆様に改めてお伝えしたいこと、また管理者画面のデザイン変更などで過去ブログで記載された手順と少し変更が入っているため、改めてみなさんにその特徴・注意点と手順を共有させていただきます。

[特徴]

  • 管理者画面での変更だけで切り替え作業が完了します
  • 対応しているクレジットカードはVISAとMasterカードです
  • MarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます
  • AWS内部ではドルで計算され、月末の利用料集計時に、その時点でのAWSが定めるレートをもとに円に自動計算されます
  • 月額のAWSご利用額がドル換算で過去3か月平均が2000ドル以上、もしくは2000ドルを超えるご予定がある場合は、請求書切り替えも可能となります。
  • 請求書払いもクレジットカードと同様にMarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます

[手順]

それでは手順についてみていきましょう。まず管理者画面にログインしてください。トップページがでてきます。

右上のアカント名が、みなさんが設定を行おうとしているアカウント名が正しく表示されていることを確認してください。なお、AWSマネージメントコンソールはアカウント開設時期や設定状態などで異なるデザインが表示される方もいらっしゃいますが、エラーではありませんので安心してください。

右上のアカウント名を選択してください。

アカウントを選ぶと以下の画面が出てきます。

オレンジ色の箇所にはみなさんのアカントに登録された情報が出てきます。左側の「お支払方法」を選択してください。

お支払いに使用されているクレジットカード情報が表示されます。その右上にUSDとなっている箇所がありますのでそちらをクリックしてください。

「お支払通貨の設定」の右側にある「編集」を選んで通貨を選んでください。

全部で13種類の通貨が選べるようになっています。日本円の場合はJPYを選んでください。以上で切り替えは終わりです。作業を行った月のAWS利用分から支払通貨変更が反映されます。

[請求書払いへの切り替えについて]

請求書払いへの切り替えの場合、AWSの月額ご利用額がドル換算で過去三か月の平均が2000ドル以上であれば、サポートセンターで「新規ケースの作成」をクリックし、「アカウントおよび請求サポート」まで変更をご依頼ください。

2000ドルに満たないが、今後ご利用予定がある場合は、担当アカウントマネージャへのご連絡、もしくはこちらからご連絡ください。

-プロダクトマーケティング エバンジェリスト 亀田