Amazon Web Services ブログ

こんにちは、ソリューションアーキテクトの石井です。 先日(2018/3/08)開催致しました AWS Black Belt Online Seminar 「Amazon SageMaker」の資料を公開いたしました。当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。

韓国語テキストの高精度な解析とマッチングを保証するために、Amazon Elasticsearch Service（Amazon ES）がSeunjeonプラグインをサポートするようになりました。このプラグインを使用すると、ユーザーにより良い結果をもたらすカスタムアナライザーを作成できます。 検索のためのアジア言語の処理 検索エンジンを使用するときは、検索ボックスに単語を入力します。その後に検索エンジンはそれらの単語を、索引付けした文書に出てくる単語とマッチングさせます。正しく一致させるには、検索エンジンがソース文字列から単語（言い換えれば、検索語句）を解析する必要があります。 エンジンは一連のステップでこれを行います。ステップに関するいくつかの例としては、空白をトークン化し、語幹を根本的な形にするためのステミングを適用し、ストップワード（頻繁で値の低い用語など）を削除することなどです。 多くの単語は複合語で、空白で区切れないため、アジア言語のテキストの処理は複雑です。同じ文字列は、複合的な文脈で異なることを意味することがあります。 Elasticsearchでのアジア言語の最もベーシックな処理は、cjkアナライザーを介して提供されます。このアナライザーは、空白を分割して、得られたテキストに文字のバイグラム—2文字のペア—を作成します。たとえば、文字列아마존으로は、次の用語をインデックスに追加します。 아마 마존 존으 으로 Elasticsearchは、クエリを実行したときと同じ分析を行います。インデックス内のバイグラムに一致する、クエリ内のバイグラムが多いほど、マッチングが良好になります。 残念ながら、バイグラムをマッチングさせると予期しない結果につながる可能性があります。例えば、아마존이、아마존은、아마존으로、아마존을などは、すべてAmazonを意味する単語です。空白で用語を抽出したりバイグラムを計算すると、結果が悪くなる可能性があります。もし、아마존を照会すると、空白解析の仕組みのために、아마존이、아마존은、아마존으로、そして아마존을を含むドキュメントが結果に含まれない可能性があります。または、そのような文書は、バイグラム分析の仕組みのために、検索結果に表示されるほど十分な高いスコアを示さないことがあります。ユーザーがクエリを書くとき、最も頻繁には、単純に아마존（Amazon）を含むすべての文を検索します。この例のように行うと、多くの結果が抜けてしまいます。 より良い韓国のアナライザー：Seunjeon 高精度のマッチングをサポートするには、空白に基づいた処理条件以上の処理を行う韓国語のアナライザーが必要です。また、バイグラムに分割することもできます。Seunjeonは広く使われているオープンソースの韓国語アナライザーで、現在Amazon ESで利用可能です。このアナライザーは、韓国語の辞書であるmecab-ko-dicに基づいています。この辞書はアナライザーの重要な部分であり、ソーステキストとそのテキストの正しい用語を入力します。Amazon ESは現在、mecab-ko-dic-2.0.1-20150920を提供しています。 プラグインがメモリー不足のインスタンスでうまく動作するように、内部データ構造と関数に対して複数の最適化を行い、コミュニティへの機能拡張に貢献しました。作成されたプラグインのメモリー占有量は59％より少なく、現在はbitbucketリポジトリ内の個別の最適化バージョンとしても利用できます。 Seunjeonプラグインを使ってマッピングを作成する方法 Amazon ESには、Seunjeonアナライザーがあらかじめパッケージ化されており、自動的に導入され管理されます。ソースフィールドにアナライザーを設定した後、韓国語のキーワードで検索を開始することができます。 次のコードは、韓国語アナライザーでインデックスを作成します。 PUT / myindex { “settings” : { “index”: { “analysis”: { [1] “analyzer”: { [2] “korean”: { “type”:”custom”, [3] “tokenizer”:”seunjeon_default_tokenizer” } }, “tokenizer”: { [4] “seunjeon_default_tokenizer”: { “type”: “seunjeon_tokenizer”, “index_eojeol”: false, […]

AWS Samurai 2017 の発表 先日、AWSユーザーグループのJAWS-UG(Japan AWS User Group)による1大イベント「JAWS DAYS 2018」が東京 五反田で開催されました。過去最高の1,900人を超える申込数、1,400名を超える参加者数を記録、日本国内の多くAWSユーザーによるセッションのみならず、海外のユーザーグループのメンバーや米国他の海外のテクニカルエバンジェリストもJAWS DAYSに参加いただきました。

クラウドに移行する際、組織が直面する課題の 1 つに挙げられるのは、限られたライセンスを持つ古いレガシーインフラストラクチャを、幅広い機能と従量課金制を提供できる環境に移行する、あるいはそのような環境に統合するための最善の方法があります。AWS には、分析や計画に役立つ多くのオプションが用意されています。それらに共通する 1 つのアプローチは、既存のデータセンターと AWS の間にハイブリッド環境を確立することです。 ハイブリッド環境では、データベース、アプライアンス機器、内部システムなどのオンプレミスリソースに関連するレイテンシーを軽減することが課題の 1 つです。これに対処できるソリューションは、数多くあります。このブログ記事ではそのうちの １ つ、キャッシングを使用してレイテンシーを短縮し、パフォーマンスを向上させ、同時に耐障害性を向上させる方法について説明します。 シナリオ : 顧客が主に使用しているアプリケーションで、高いレイテンシーがある 今回検討するシナリオでは、顧客が使用する主なアプリケーションで高いレイテンシーを経験しており、日々の操作に影響していました。このアプリケーションとは、データベースによって駆動する検索機能を備えたオンラインのメディカルライブラリーです。次の図は、元のアーキテクチャを示しています。確認の結果、検索エンジンからのクエリの数が多いことが原因の、過負荷データベースの問題であることが分かりました。さらに、クエリの結果が非常に大きいため、顧客の低速なネットワークリンクが飽和状態になり、応答時間に影響を与えたのでした。 この問題を解決するソリューションの 1 つは、この記事では説明していませんが、データベースを Amazon RDS に移行し、読み取り専用インスタンスを有効にすることです。しかし、顧客のデータベースのライセンス条件により、AWS への移行ができませんでした。データベースを移行する際の別の課題は、アプリケーションとデータベースの統合です。システムが稼働中であったため、アプリケーション全体をライセンス制限のない別のデータベースエンジンに書き換えることはできませんでした。 提案するソリューション : Amazon ElastiCache によるインメモリキャッシュ この問題にはバックエンドデータベースのレイテンシーが関係するため、Amazon ElastiCache　でのインメモリキャッシュを使用して、ネットワークのレイテンシーを軽減し、データベースの負荷を軽減します。このソリューションでは、データ取得レイテンシーを劇的に短縮できます。また、Amazon ElastiCache は 1 秒あたり 2000 万を超える非常に高い要求速度を実現できるため、要求量も大幅に増加します。次の図は、提案するアーキテクチャを示しています。VPC 内のキャッシュをウェブサーバーおよびアプリケーションサーバーと共に使用すると、アプリケーションは AWS からローカルデータセンターに常に移動する必要がなくなります。この変更により、サーバー間の物理的な距離は関係なくなります。 このソリューションの別の利点は、ワークロードの追加的可用性と規模です。このアーキテクチャーを使用すると、ソースデータベースに障害が発生しても、アプリケーションに対してクエリを継続して実行できます。これは、結果がキャッシュに格納され、キャッシュから検索されるためです。 この新しいアーキテクチャだと、顧客エクスペリエンスが大幅に改善するはずです。 ElastiCache の背景 Amazon ElastiCache は、Redis および Memcached と互換性のある、完全管理型で低レイテンシーのインメモリデータストアです。ElastiCache は Redis と Memcached の管理に関連する管理タスクがほとんどなくなるため、ビジネスとデータに集中することが可能となります。このサービスは、低速ディスクを使ったデータベースに完全に依存する代わりに、高速でかつ管理されたインメモリデータストアから情報を取得できるようにすることで、ウェブアプリケーションのパフォーマンスを向上させます。ElastiCache　では、障害の発生したノードを自動的に検出し置き換えるため、セルフ管理型のインフラストラクチャに伴うオーバーヘッドが減少します。したがって、ElastiCache […]

この記事は Nexmo, the Vonage API Platform の プロダクトディレクター、ボイスアンド RTC、Roland Selmer 氏によるゲストブログ記事です。彼は Nexmo についてこのように述べています。「テキストメッセージング、チャット、ソーシャルメディア、音声などを通じて、リアルタイムかつ容易にカスタマーと情報を共有するのに必要なツールを提供することで、デジタルカスタマーエクスペリエンスを再考できるようにします。」 ビジネスがアプリケーションにコミュニケーション機能を統合できるようにするクラウドコミュニケーションプロバイダーとして、Nexmo, the Vonage API Platform は、 当社のカスタマーために提供している合成音声ユースケースの多くに役立つテキスト読み上げ (TTS) ソリューションが必要でした。私たちの選ぶソリューションは、Nexmo のグローバル TTS 製品を強化するために、当社のテクノロジー要件と製品哲学に合致している必要がありました。 Amazon Polly はこれらの基準のすべてを完璧に満たしていました。このパワフルなサービスは、Nexmo の合成音声ユースケースの核となるメインエンジンとなっています。このサービスは言語と音声で幅広い分野を網羅しています。 Amazon Polly を活用した Nexmo ユースケース Nexmo では、アプリケーショントゥパーソン (A2P) コミュニケーションのインターフェイスとして音声に注目しており、当社のカスタマーがこの最も自然なコミュニケーション方法を第一に独自のアプリケーションに統合できるようにします。Amazon Polly はその屋台骨と言えます。 特に、様々な業界のお客様が次に示す主要なユースケースにおいて、より良いビジネス収益を上げるために、Amazon Polly を活用した TTS を利用することができました。 音声放送 重大な音声アラート 着信通話通知 2 要素認証 (2FA) による PIN コードのフェイルオーバー音声配信 音声放送: […]

Amazon EMR は多くのカスタマーに、Apache Spark、Apache HBase、Presto、およびApache Flink などの一般的な分散型フレームワークを使用して、ビッグデータ処理あぷロケーションを素早く、コスト効率良く構築するようにエンパワメントします。Amazon EMR の分析アプリケーションを作成している組織の場合、自動化された形式でデータ資産を整理する必要がますます大きくなります。データベースは指数関数的に成長する傾向があるため、カタログ作成ツールを使用することは、データ探索を自動化し、データ資産を整理するために重要です。 AWS Glue データカタログは、この重要な機能を備えており、中央レポジトリのデータストアに関してメタデータを自動的に探索してカタログ作成できます。Amazon EMR 5.8.0 以降、カスタマーは Amazon EMR で実行中の Apache Hive と Spark SQL アプリケーションにメタデータストアとして AWS Glue データカタログを使用してきました。Amazon EMR 5.10.0 から、AWS Glue を使用してデータセットをカタログ化し、Hue (Hadoop User Experience) と Apache Zeppelin UI から Amazon EMR で Presto を使用してクエリを実行できます。 Amazon EMR 上で Prestoを実行するにはどのようなシナリオが必要か、Amazon Athena（Presto を hood の下でクエリとして使用する）を選択するのはいつかを迷うことがあるかもしれません。大量のデータをクエリし、さまざまなニーズとユースケースにたいおうするために、両方とも素晴らしいツールであることを理解することが重要です。 Amazon Athena […]

多くの画像に対してリサイズを行ったり、新しいデザインレイアウトにウォーターマークを付与したり、ブラウザのサポートのためにフォーマットの最適化を行ったことはありませんか？ 画像毎に事前処理を行う必要なく、必要に応じてその場ですぐに画像を自動生成できないかとおもったことはありませんか？ Lambda@Edge はそれらを可能にし、ユーザーの利便性を向上させ、帯域使用量を削減します。

顧客は、複数の Amazon Elasticsearch Service (Amazon ES) ドメインを適切に作成および実行して、製品、注文、サポートドキュメントに対するビジネスユーザーの検索ニーズ、および増加している同様のニーズのサポートで成功しています。このサービスは、組織全体で頻繁に使用されています。  これにより、ピーク時に 100% の容量で動作するドメインがいくつか発生し、ストレージスペースが不足し始めたドメインもありました。このように使用量が増えたため、テクニカルチームはサービスレベル契約を守れなくなる危険性がありました。  彼らは私に支援を求めました。 この記事では、自動アラームを設定して、ドメインに注意が必要なときに警告する方法を示します。

AWS ML プラットフォームチーム担当製品マネージャーである Kumar Venkateswar は、Amazon SageMaker でオートスケールの発表の詳細を共有します。 Amazon SageMaker により、何千もの顧客が容易に Machine Learning (ML) モデルを構築、訓練、およびデプロイすることができました。当社は Amazon SageMaker のオートスケール対応により、本番稼働の ML モデルの管理をさらに容易にしました。インスタンスの必要があるスケールと照合するために数多くのインスタンスを手動で管理する代わりに、SageMaker に AWS Auto Scaling ポリシーに基づいてインスタンスの数を自動的にスケールさせることができます。 SageMaker は多くの顧客のために ML プロセスの管理を容易にしました。顧客がマネージド型 Jupyter ノートブックとマネージド型配布トレーニングを利用するのを見てきました。SageMaker は、マシン学習をアプリケーションに統合するため、顧客が推論のために SageMaker ホスティングにモデルをデプロイしたのを見てきました。SageMaker はこのことを容易にします。推論ホスト上でオペレーティングシステム (OS) または枠組みをパッチすることについて考える必要はなく、アベイラビリティーゾーン全体で推論ホストを設定する必要はありません。SageMaker にモデルをデプロイするだけで、残りの部分は処理されます。 今まで、エンドポイント (または本番バリアント) ごとのインスタンスの数とタイプを指定して、推論に必要なスケールを求める必要がありました。推論の容量が変更された場合、その変更に対応するために、ダウンタイムの発生なしに、各エンドポイントに対応するインスタンスの数またはタイプ、もしくはその両方を変更できます。プロビジョニングの変更が容易であることに加えて、顧客は SageMaker の管理機能をさらに容易にするために私たちが行っている方法を尋ねてきました。 Amazon SageMaker の Auto Scaling を使用して、SageMaker コンソールで、AWS Auto Scaling API と AWS […]

既存のエンタープライズ認証情報を使用して AppStream 2.0 へのシングルサインオンアクセスを提供したいですか？ Active Directory Federation Services (AD FS) 3.0 は SAML 2.0 を使用した Amazon AppStream 2.0 へのシングルサインオンを提供するために使用することができます。 既存の Active Directory や任意の SAML 2.0 準拠の認証サービスを使用してユーザーに AppStream 2.0 アプリケーションへのシングルサインオンアクセスをセットアップすることができます。SAML 2.0 を使用した ID フェデレーションは現在すべての AppStream 2.0 リージョンで利用可能です。 この記事では Windows Server 2012 R2 で使用できる AD FS 3.0 を使用して AppStream 2.0 への ID フェデレーションを構成する方法について説明します。記事の最後に追加で、Windows Server 2016 で使用できる AD FS 4.0 を使用する場合についても補足します。