Amazon Web Services ブログ

Category: Amazon Elasticsearch Service*

【開催報告】AWS 上でのデータ活用ワークショップ

こんにちは。AWS ソリューションアーキテクトの上原誠 (@pioho07) です。 3月14日のホワイトデーに、AWS上でのデータ活用ワークショップを開催いたしました。 直前のご案内にもかかわらず80名ほどのお客様にご参加頂きました。   まずはソリューションアーキテクトの八木より、データ活用のための一般的なDataLakeの考え方について触れ、ラムダアーキテクチャの解説を行いその優位性を説明しました。その後でAWS上でこられらを実現するためのAWSの各サービス Amazon S3 や Amazon Elasticsearch Service や Amazon Kinesis などを紹介し、アーキテクチャー図と共に解説を行いました。     次に、私上原からラムダアーキテクチャーを使ったDataLakeを構築するハンズオンを実施しました。まだデータ量は大きくないが、今後増え続けるデータに対してデータ活用を始めていきたい!そんな方がすぐに実践で使えるようなサービスやサービスの組み合わせを意識した内容にいたしました。       また、ハンズオン後に実施したソリューションアーキテクトによる個別相談会にも多くのお客様にご参加頂きました。 アンケートでも励みになるお言葉を頂けました。 無料で受けたセミナーなのにとても充実していてすごいと思った 内容が事業会社のエンジニア向けと感じた 次回は夏ごろに開催予定です。ご応募是非お待ちしております。      

Read More

DeNA TechCon 2018 – AWS IoTを用いたDeNAオートモーティブアーキテクチャ

AWS IoTを用いたDeNAオートモーティブアーキテクチャ   先日、2018年2月7日に、渋谷ヒカリエにて開催された、DeNA TechCon 2018におきまして、「AWS IoTを用いたDeNAオートモーティブアーキテクチャ」と題した、DeNAの放地宏佳様による講演がありました。 AWS IoTをふんだんに活用して、Vehicle Architecture on AWSを実現されている舞台裏に関し、車両情報管理基盤の話を中心に、詳細な内容を発表いただきました。 車載デバイスから車両管理情報を収集して、車両情報集約基盤へと連携している具体的なワークフロー デバイス認証にどのような実装を施して、AWS IAMとのスムーズな連携を行なっているのかの詳細な解説 ビジネス要求の変化に柔軟に対応できるよう、拡張性を考慮したデバイスシャドウとルールエンジンの組み合わせによる利用の工夫 バックエンドのElasticsearchへのindexingのしやすさを考慮したデバイスシャドウのアトリビュート設計に対する工夫 もちろん、この他にも様々なAWSを活用いただいた事例を、Deep Learningや機械学習など、多くのセッションで触れていただいております。 ぜひ皆様にも、DeNA TechCon 2018のイベントページに訪れて、それぞれのセッションスライドに目を通していただきたいです。 DeNA様、放地様、素晴らしいカンファレンスと発表を、本当にありがとうございました!   ソリューションアーキテクト 半場光晴

Read More

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 ロードバランサをパススルーします。リクエストがどこに行くかに関わらず、インスタンスは […]

Read More

Amazon Elasticsearch Service が VPC をサポート

本日より、NAT インスタンスやインターネットゲートウェイを必要とせずに Amazon VPC から Amazon Elasticsearch Service ドメインに接続できるようになりました。Amazon ES の VPC サポートは設定も簡単で信頼性が高く、セキュリティをさらに強化することができます。VPC サポートでは、その他のサービスと Amazon ES 間のトラフィックはパブリックインターネットから分離されており AWS ネットワーク内で維持されます。既存の VPC セキュリティグループを使用してネットワークアクセスを管理できます。また、AWS Identity and Access Management (IAM) ポリシーを使って保護機能を強化することもできます。Amazon ES ドメインの VPC サポートは追加費用なしにご利用いただけます。 ご利用開始にあたって VPC での Amazon Elasticsearch Service ドメインの作成は簡単です。クラスター作成に使ういつもの手順を行い [VPC access] を選択します。 これだけです。その他の手順はありません。これで VPC からドメインにアクセスできるようになりました。 主要事項 VPC をサポートするにあたり、Amazon ES は少なくても 1 つの VPC サブネットにエンドポイントを配置します。Amazon ES はクラスター内の各データノードの […]

Read More

Kinesis Firehoseを使用してApache WebログをAmazon Elasticsearch Serviceに送信する

Elasticsearch、Logstash、および、Kibana(ELK)スタックを所有して運用する多くのお客様が、他の種類のログの中でもApache Webログを読み込んで可視化しています。 Amazon Elasticsearch Serviceは、AWSクラウドにElasticsearchとKibanaを提供しており、セットアップと運用が簡単です。 Amazon Kinesis Firehoseは、Amazon Elasticsearch ServiceにApache Webログ(またはその他のログデータ)をサーバーレスで確実に配信します。 Firehoseを使用すると、Firehose内のレコードを変換するAWS Lambda関数への自動呼び出しを追加できます。これらの2つのテクノロジーを使用すると、既存のELKスタックを効果的かつ簡単に管理することができます。 この記事では、最初にAmazon Elasticsearch Serviceドメインを設定する方法を説明します。次に、事前ビルドされたLambda関数を使用してApache Webログを解析するFirehoseストリームを作成して接続する方法を示します。最後に、Amazon Kinesis Agentでデータをロードし、Kibanaで可視化する方法を示します。

Read More

AWS上でApache Flinkを使用してリアルタイムストリーム処理パイプラインを構築する

今日のビジネス環境では、多様なデータソースが着実に増加していく中で、データが継続的に生成されています。したがって、このデータを継続的にキャプチャ、格納、および処理して、大量の生データストリームを実用的な洞察に素早く繋げることは、組織にとって大きな競争上のメリットになっています。 Apache Flinkは、このようなストリーム処理パイプラインの基礎を形成するのに適したオープンソースプロジェクトです。ストリーミングデータの継続的な分析に合わせたユニークな機能を提供しています。しかし、Flinkを基にしたパイプラインの構築と維持には、物理​​的なリソースと運用上の努力に加え、かなりの専門知識が必要になることがよくあります。 この記事では、Amazon EMR、Amazon Kinesis、Amazon Elasticsearch Serviceを使用してApache Flinkを基にした、一貫性のあるスケーラブルで信頼性の高いストリーム処理パイプラインの参照アーキテクチャの概要を説明します。 AWSLabs GitHubリポジトリは、実際に参照アーキテクチャを深く理解するために必要なアーティファクトを提供します。リソースには、サンプルデータをAmazon Kinesisストリームに取り込むプロデューサアプリケーションと、リアルタイムでデータを分析し、その結果をAmazon ESに可視化するためのFlinkプログラムが含まれています。

Read More

Amazon EC2インスタンスにホストベースの侵入検知システムアラートの監視方法

AWSリソースを安全に保護するためのアプローチとして、予防のための仕組み、検知のため仕組みといったそれぞれのレイヤーでのアプローチを検討頂くことを推奨しています。たとえば、Amazon EC2インスタンスにホストベースのコントロールを組み込むことで、アクセスを制限し、システムの動作やアクセスパターンに伴う適切なレベルの可視性を準備できます。これらのコントロールには、ホスト上のネットワークトラフィック、ログファイル、およびファイルアクセスを監視・分析するホストベースの侵入検知システム(HIDS)を含むことが一般的です。 HIDSは、通常、警告、自動修復ソリューションと統合され、攻撃、許可されていない活動、疑わしい活動、環境内の一般的なエラーを検出し対処します。 このブログ記事では、Amazon CloudWatch Logsを使用してオープンソースセキュリティ(OSSEC)HIDSからのアラートを収集、集約する方法を示します。 また、CloudWatch Logs サブスクリプションを組み合わせることで、Amazon Elasticsearch Service(Amazon ES)に分析データと可視化のアラートを配信し、一般的なオープンソースであるKibanaを使用し可視化まで行います。また皆さんが、すぐに試せるようにCloudFormationテンプレートを用意しましたので、ほとんどのデプロイメント作業を自動化させています。このソリューションを使用して、EC2 全体の可視性と洞察を向上させ、セキュリティ修復活動を促進することができます。たとえば、特定ホストがEC2インスタンスのスキャンを検知したらOSSECアラートをトリガーし、VPCネットワークACL(Access Control List)またはAWS WAFルールを実装して、送信元IPアドレスまたはCIDRをブロックすることができます。 ソリューションの概要 次の図は、この記事のソリューションの概要を示しています。 ソリューションの仕組みは次のとおりです。 1. ターゲットEC2インスタンスでは、OSSEC HIDSは、CloudWatch Logs エージェントがキャプチャするログに基づきアラートを生成します。 HIDSは、ログ分析、整合性チェック、Windowsレジストリ監視、ルートキット検出、リアルタイムアラート、およびアクティブな応答を実行します。詳細については、「OSSEC入門」を参照してください。 2. CloudWatch Logs グループはにアラートがイベントとして送信されます。 3. AWS Lambdaを介してイベントをAmazon ESに転送するために、CloudWatch Logs サブスクリプションがターゲットロググループに適用されます。 4. Amazon ESにはログに記録されたアラートデータがロードされます。 5. Kibanaはアラートをほぼリアルタイムで視覚化します。 Amazon ESはすべてのAmazon ESドメインにKibanaを標準でインストールした形で提供されます。 デプロイ時の考慮事項 この記事では、主なOSSEC HIDSのデプロイは、Linuxベースのインストールで構成されています。インストールでは、アラートが各システム内でローカルに生成されます。このソリューションは、デプロイの対象リージョンはAmazon ESとLambdaに依存します。 AWSサービスの可用性に関する最新情報は、Regionテーブルで確認できます。また、EC2インスタンスが必要なコンポーネントを適切にプロビジョニングするために、インターネットアクセスとDNS解決を持つAmazon VPC(Virtual Private Cloud)サブネットを識別する必要があります。 デプロイのプロセスを簡素化するために、テスト環境向けにAWS CloudFormationテンプレートを作成しました。このテンプレートを使用して、テスト環境スタックを既存のAmazon VPCサブネットに自動的にプロビジョニングできます。 CloudFormationを使用してこのソリューションのコアコンポーネントをプロビジョニングし、警告分析用にKibanaを設定します。このソリューションのソースコードはGitHubで入手できます。 Cloud […]

Read More

Amazon Elasticsearch Service が Elasticsearch 5.1 をサポート

Amazon Elasticsearch Service は、オープンソース検索および分析エンジンである Elasticsearch を容易にデプロイ、運用、拡張できるようにするマネージド型サービスです。このたび Amazon Elasticsearch Service で Elasticsearch 5.1 および Kibana 5.1 がサポートされるようになったことを、ここにお知らせいたします。Elasticsearch 5 は非常に多くの新機能と機能拡張を備えており、Amazon Elasticsearch Service をご利用のお客様はそれらを活用いただけるようになりました。今回の Elasticsearch 5 のリリースには、次のような内容が含まれています。 インデックス作成のパフォーマンス: ロックの実装の更新および非同期のトランザクションログ FSYNC による、インデックス作成のスループットの向上 取り込みパイプライン: 受信データは一連の取り込みプロセッサを適用するパイプラインに送信できます。これにより検索インデックスに必要なデータに正確に変換できます。単純な付加アプリケーションから複雑な正規表現アプリケーションまで、20 個のプロセッサが含まれています Painless スクリプティング: Amazon Elasticsearch Service は Elasticsearch 5 のための新しい安全でパフォーマンスに優れたスクリプト言語である、Painless をサポートします。スクリプト言語を使用すると、検索結果の優先順位を変更したり、クエリでインデックスフィールドを削除したり、検索結果を修正して特定のフィールドを戻したりすることができます。 新しいデータ構造: 新しいデータ型である Lucene 6 データ構造をサポートし、半精度浮動小数点、テキスト、キーワード、さらにピリオドが含まれるフィールド名を完全にサポートします 検索と集計: リファクタリング検索 API、BM25 関連性計算、Instant Aggregations、ヒストグラム集計と用語集計の機能強化、再設計されたパーコレーターと完了サジェスタ ユーザーエクスペリエンス: 厳密な設定、本文とクエリ文字列パラメーターの検証、インデックス管理の向上、デフォルトで廃止予定のログを記録、新しい共有割り当て API、ロールオーバーと圧縮 API […]

Read More

Amazon Elasticsearch Service をはじめよう: シャード数の算出方法

Dr. Jon Handler (@_searchgeek) は検索技術にスペシャライズした Amazon Web Services のプリンシパルソリューションアーキテクトです。 Elasticsearch および Amazon Elasticsearch Service(Amazon ES) のブログポストシリーズへようこそ。ここでは今後もAWS上でElasticsearchをはじめるにあたって必要な情報を提供していく予定です。 いくつのシャードが必要? Elasticsearchは、大量のデータを、シャードと呼ばれる細かいユニットに分割し、それらのシャードを複数のインスタンスに分散して保持します。Elasticsearchではインデックス作成の際にシャード数を設定します。既存のインデックスのシャード数を変更することは出来ないため、最初のドキュメントをインデックスに投入する前にシャード数を決定しなければなりません。最初はインデックスのサイズからシャード数を算出するにあたって、それぞれのシャードのサイズの目安を30GBにします。 シャード数 = インデックスのサイズ / 30GB インデックスのサイズ算出に関しては、AWS Solutions Architect ブログ: 【AWS Database Blog】Amazon Elasticsearch Service をはじめよう: インスタンス数の見積もり方法をご覧ください。 データの送信やクエリをクラスタに対して行っていく中で、クラスタのパフォーマンスを元に、継続的にリソースのユーセージを評価しながら、シャード数を調整していきます。 シャードとは? サーチエンジンには2つの役割があります: ドキュメントを元にしたインデックスの作成と、インデックスの中からマッチしたドキュメントを引き当てる検索です。インデックスが小さければ一つのデータ構造で一台のマシンで事足りるでしょう。しかし、大量のドキュメントにおいては、インデックスを保存するのに一台のマシンでは足りませんし、ピースに分割されたインデックスから検索結果を求めるためのコンピュート能力も足りません。Elasticsearchではこれらのピースのことをシャードと呼びます。それぞれのドキュメントは計算結果に基いてシャードにルーティングされます。デフォルトではドキュメントのIDのハッシュ値に基づいたルーティングになります。 シャードは ストレージ(storage) の単位であり、また 処理(computation) の単位でもあります。Elasticsearchはシャードを独立した形でクラスタ内のインスタンスにデプロイし、インデックスの処理をそれぞれで並列に行います。Elasticsearchという名前の通り”elastic”なものであると言えるでしょう。クラスタにインスタンスを追加する場合、Amazon Elasticsearch Serviceは自動的にシャードのリバランスを行い、クラスタ内のインスタンスにシャードを再配置します。 ストレージ(storage)においては、シャードはそれぞれ別のもの(distinct)です。シャード内のドキュメントは、他のシャードに重複して保持されることはありません。このアプローチによってシャード毎の独立性を保っています。 処理(computation)においても、シャードはそれぞれ別のもの(distinct)です。それぞれのシャードはドキュメントが処理されて生成されたApache Lucene indexのインスタンスです。インデックスには全てのシャードが含まれるため、クエリや更新リクエストのプロセスにおいて、それぞれのシャードはお互いに協調して機能する必要があります。クエリのプロセスにおいては、Elasticsearchはインデックス内の全てのシャードにクエリをルーティングします。それぞれのシャードはローカルで個別に処理を行い、それぞれの結果をアグリゲートして最終的にレスポンスします。書き込みリクエストにおいては(ドキュメントの追加、もしくは、既存のドキュメントの更新)、Elasticsearchはリクエストを適切なシャードにルーティングします。 Elasticsearchには2つの種類のシャードがある Elasticsearchには2つの種類のシャードがあります – プライマリシャードとレプリカシャードです。プライマリシャードは全ての書き込みリクエストを受け付けます。プライマリシャードは新しく追加されたドキュメントをレプリカにパスします。デフォルトでは、書き込みがレプリカに確認(acknowledge)されるのを待ってから呼び出し元に書き込み成功のレスポンスを行います。プライマリとレプリカシャードはデータの保存に冗長性をもたらし、データのロスを起こりにくくします。 この図の例では、Elasticsearchクラスタは3つのデータインスタンスを保持しています。緑と青の2つのインデックスがあり、それぞれ3つのシャードがあります。それぞれのシャードのプライマリは赤枠で囲われています。それぞれのシャードにはレプリカがあり、それらに枠はありません。Elasticsearchはいくつかのルールを元にシャードをインスタンスに配置します。最も基本的なルールとして、プライマリとレプリカのシャードを同じインスタンスに配置しない、というものが挙げられます。 最初にストレージにフォーカスする お客様のワークロードには2つの種類があります: シングルインデックスとローリングインデックス。シングルインデックスのワークロードは、全てのコンテンツを保持する”source of […]

Read More

AWSでの疎結合データセットの適合、検索、分析

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する(あるいは反論する)ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています(例えば、日時が間違っている、地理座標が間違っているなど)。 最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。 データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。 関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。 このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。 異なる3つのデータセットを適合させて索引付けし、検索可能にします。 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。 Amazon AthenaやAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

Read More