Amazon Web Services ブログ

Category: Amazon OpenSearch Service (successor to Amazon Elasticsearch Service)

Amazon Elasticsearch Service で PostgreSQL ログを分析する

バージョン 9.6.6 以降の Amazon RDS は、Amazon CloudWatch への PostgreSQL ログの発行をサポートしています。 Aurora PostgreSQL は、バージョン 9.6.12 以降、およびバージョン 10.7 以降の CloudWatch Logs へのログの発行をサポートしています。このデータを CloudWatch から Amazon Elasticsearch Service (Amazon ES) にライブストリーミングすることにより、RDS PostgreSQL DB ログの継続的な可視性を維持します。Kibana と簡単な検索構文を使用して、データをリアルタイムで視覚化、分析、検出できます。また、PostgreSQL ログのモニタリングを設定し、Kibana でアラームを設定して、ログに記録されたエラーまたは長時間実行されているクエリをタイムリーに検出できるようにすることもできます。 CloudWatch を使用すると、ログをクエリして視覚化を実行できますが、複数の AWS アカウントに複数のデータベースがある場合、これは困難な場合があります。この記事で使用するソリューションは理想的です。それはログを一元的にストリーミングし、各アカウントの複数のコンソールにログインせずに複数のデータベースのダッシュボードを視覚化するためです。 Amazon ES は完全マネージド型のサービスで、容易に、ダウンタイムなしで Elasticsearch を大規模にデプロイ、セキュリティ保護、運用することができます。ウェブサイト、モバイルデバイス、サーバー、センサーが生成した非構造化ログおよび半構造化ログを分析できます。これにより、運用インテリジェンス、アプリケーションモニタリング、根本原因の分析などが保証されます。このサービスは、オープンソース API、マネージド型のKibana を提供し、Logstash や他の AWS のサービスと統合して、任意のソースからデータを安全に取り込みます。Amazon ES を使用すると、リアルタイムで検索、分析、視覚化できます。 この記事では、RDS PostgreSQL データベースのログを CloudWatch に発行し、データを Amazon […]

Read More

UltraWarm for Amazon Elasticsearch Service を使用して少ないコストでより多くのデータを維持する

機械によって生成されたデータは、ソリューションを強化すると共に問題も引き起こします。これは今日の最新ソフトウェアアプリケーションで運用上の問題を特定するために必要不可欠ですが、それをリアルタイムで分析するには Amazon Elasticsearch Service のような柔軟でスケーラブルなツールが必要です。このログデータは極めて貴重であるため、ホットストレージから削除したくはないのですが、大量にありすぎるので削除するしかありません。ログ分析には、潜在的な価値と実費をてんびんにかけるという本質的な葛藤があります。 過去数日間からのログに価値があることは分かっています。最高のインデックスおよび検索パフォーマンスを提供するホットストレージに料金を支払うことは道理にかないます。6 週間前、または数か月前からのログには価値が出る可能性もありますが、これからどのくらいで価値が出るのでしょうか? その一方で、それらをホットストレージに維持するコストは正当化できるのでしょうか? Amazon Elasticsearch Service の新しいストレージ階層である UltraWarm は、この葛藤を取り除き、ホットストレージと比較してデータ保持期間を劇的に延長し、コストを最大 90% 削減することを可能にします。何よりも素晴らしいのは、インタラクティブな分析経験はそのまま変わらないところです。ウォームインデックスは、他のインデックスと同様にクエリしたり、それらを使用して Kibana ダッシュボードを構築したりします。 仕組み 従来のウォームストレージソリューションには制限がありました。オープンソースの Elasticsearch クラスターは高密度ストレージの D2 インスタンスを使用することができますが、これらのノードを追加しても同じ基本的な Elasticsearch アーキテクチャが維持されます。引き続きオペレーティングシステムオーバーヘッド、ディスクウォーターマーク、およびインデックスレプリカを考慮しなくてはなりません。使用分だけを支払うのではなく、プロビジョニングした分の料金を支払い続けます。 UltraWarm は違います。これは、Amazon S3 と AWS Nitro System 駆動のノードの組み合わせを使用して、集約と可視化にホットストレージのような経験を提供します。S3 は耐久性に優れた低コストのストレージを提供し、レプリカの必要性を排除します。S3 はまた、オーバーヘッドという概念を取り去るので、各 UltraWarm ノードは利用可能なストレージを 100% 使用することができます。これらのノードには、クエリ処理最適化、およびデータをプリフェッチする高度なキャッシングソリューションが含まれています。従来のウォームストレージソリューションと比較して、UltraWarm のパフォーマンスは通常それらと同様、またはそれらより優れています。 具体的な料金例について、3 つのultrawarm1.large ノードを検討しましょう。すべてのノードと同様に、各ノードには時間レートの料金を支払います。今回の場合のレートは 2.680 USD です。これらのノードを合わせると、毎月 GiB あたり 0.024 USD で最大 60 TiB の […]

Read More

Elasticsearch と Kibana を使って Amazon Connect のデータをリアルタイムに活用する

このブログポストでは、Amazon Elasticsearch Service (Amazon ES) と Kibana を使って、どのように Amazon Connect コンタクトセンターでリアルタイムなデータ分析を行うかを紹介します。問い合わせ対応時間やサービスレベル、問い合わせの効率具合、エージェントのパフォーマンス、顧客満足度など、様々なサービス・メトリクスを改善するためにコンタクトセンターのパフォーマンスをモニタリングできます。 加えて、Amazon ES を使って問い合わせ追跡レコード (CTR) 、エージェントのイベント・ストリーム、Amazon CloudWatch で取得できる問い合わせフローログを処理し、Kibana を使ってリアルタイムに近い形で可視化するソリューションも紹介します。Elasticsearch はオープンソースの、分散システムの検索と分析のエンジンで、ログ分析や全文検索に利用されています。Kibana はデータ集約と可視化のツールです。Amazon ES と Kibana を用いて、リアルタイムにデータを検索、可視化、分析、洞察することができます。 Amazon Connect は顧客とのやり取りで発生したイベントの詳細をリアルタイムに問い合わせフローログとして提供します。問い合わせフローとは顧客が問い合わせを行ったときの顧客体験を定義したもので、再生するプロンプトや顧客からの入力、問い合わせキューの転送などを定義します。 さらに、Amazon Connect は 分析用にデータをエクスポートするために CTR を Amazon Kinesis Data Firehose に、エージェントのイベントを Amazon Kinesis Data Streams にストリーミングできます。CTR は Amazon Connect インスタンスで発生するイベントや、属性、キュー、エージェントのやり取りをキャプチャーしたものです。エージェントのイベントは、Amazon Connect インスタンスにて起こる、ログイン、ログアウト、ステータスの変更といったエージェントのアクティビティを記録したものです。 ソリューション概要 以下の図は Amazon Connect からの問い合わせフローログや CTR、エージェントのイベントを処理し、Amazon […]

Read More

2018 年に最もよく読まれた AWS データベースブログ

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

Read More

【開催報告】AWS Data Lake ハンズオンセミナー 秋

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 9月21日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。前回行ったワークショップの3回目となります。前回も盛況でしたが、今回も80名近くのお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスであるAmazon S3を中心とした Data Lakeについて解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、AthenaやRedshiftのAWSサービスを駆使して実際にラムダアーキテクチャを構築してみる、というのがゴールです。とはいえすべてを構築し切るのはボリュームが大きいため、コース別に取り組めるようにハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回、参加者も多くいらっしゃいましたので、サポートするソリューションアーキテクトも4名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか?   次回は冬ごろに開催予定です。ご参加お待ちしております。

Read More

Amazon Elasticsearch Service エラーログの表示

本日、Amazon Elasticsearch Service(Amazon ES)は、Amazon CloudWatch Logs へのエラーログ出力のサポートを発表しました。 この新機能は、エラーログをキャプチャする機能が提供され、サービスの運用中に発生したエラーや警告に関する情報にアクセスできます。 これらの詳細な情報はトラブルシューティングに役立ちます。 この情報を使用して、Amazon ES の利用者と協力してドメイン上のエラーまたは警告を引き起こすシナリオのパターンを特定できます。 この機能へのアクセスは、ドメインが作成されるとすぐに有効になります。 ログを自由にオン/オフすることができ、支払いは CloudWatch の利用した分のみの料金です。 ドメインのエラーログの配信を設定する アクティブなドメインのエラーログを有効にするには、AWS Management Console にサインインし [Elasticsearch Service ]を選択します。 Amazon ES コンソールで、一覧からドメイン名を選択しダッシュボードを開きます。 次に[Logs]タブを選択します。 このペインでは、検索のスローログ、インデックススローログ、およびエラーログを CloudWatch Logs のロググループに出力するように Amazon ES ドメインを設定します。 スローログの設定に関する詳細は、AWS データベースブログのブログ記事Viewing Amazon Elasticsearch Service Slow Logsを参照してください。 エラーログの設定で、[セットアップ]を選択します。 新しいロググループを作成するか既存のロググループを使用するかを選択できます。 次のようなパスとしてロググループの名前を付けることをお勧めします。 /aws/aes/domains/mydomain/application-logs/ このようなネーミングのスキームを使用すると、CloudWatch アクセスポリシーを簡単に適用できます。このポリシーでは次のような特定のパスのすべてのロググループに権限を付与できます。 /aws/aes/domains CloudWatch ロググループにログを配信するには、Amazon ES が CloudWatch Logs […]

Read More

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

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

Read More

Amazon CloudWatch を使用して、自動アラーム付き Amazon Elasticsearch Service ドメインの運用効率を向上させる

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

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 IoT を用いた DeNA オートモーティブアーキテクチャ / DeNA Techcon 2018 Houchi Hiroyoshi 車載デバイスから車両管理情報を収集して、車両情報集約基盤へと連携している具体的なワークフロー デバイス認証にどのような実装を施して、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