UCloud Elasticsearch が再度アップグレードされ、LBS シナリオを完全にサポートするようになりました

ご存知のとおり、Elasticsearch (ES) はログ分析のための ELK ソリューションの重要な部分であり、全文検索にも役立ちます。実際、ES は LBS (位置情報サービス) シナリオでも非常に役立ちます。 ES は、全文検索、構造化検索、分析を組み合わせることで、基本的に地理的位置に基づいてさまざまな情報をリアルタイムで提供できます。

UCloud Elasticsearch (UES) は、Elasticsearch と Kibana をベースにしたログ管理および分析サービスです。 LBS シナリオをサポートするために、UCloud は最近、16 コア 64G 構成をサポートし、より頻繁な位置情報クエリに対応できるパフォーマンスを備えた UES 大容量メモリ モデルをリリースしました。

UES機能がさらにアップグレード

UES はクラスターを作成してサービスを作成します。クラスターは優れた構成と豊富なプラグインを自動的に初期化し、ユーザーに迅速な作成、簡単な管理、線形拡張を提供します。さらに、UES は豊富なパフォーマンス指標の監視および視覚化管理プラットフォームも提供し、高性能 SSD ディスクにより、大量のログ データの保存、取得、分析の処理効率が効果的に向上します。この機能アップグレードにより、LBS シナリオが完全にサポートされるようになりました。

LBS の応用シナリオは数多くあり、ソーシャル アプリケーションにおける「近くにいる人」や、ローカル サービス アプリケーションにおける「近くのレストラン」など、生活のあらゆる場所で見ることができます。あまり注目されていないもう 1 つのシナリオは、小売業界の広告とマーケティングにおけるロケーション ベース マーケティング (LBA) です。 LBA は最初の 2 つとは少し異なり、技術的な実装も少し複雑です。以下では、「近くのレストラン」のシナリオを例に、ES が地理位置情報インデックスを構築する方法と、ES が提供する REST API を使用して位置情報クエリを実行する方法を説明します。

（図：現在地から500メートル以内のレストランを検索）

簡単に言えば、ES の役割は 2 つのステップに分かれています。最初のステップは、レストランの経度と緯度の座標を格納するための場所インデックスを作成することです。クライアント ユーザーがクエリを開始すると、ES によって提供される geo_distance を使用して、特定の距離内のすべてのレストランがクエリされます。

この例では、UES サービスを基本サービス サポートとして使用し、メモリ最適化インスタンス構成を選択します。データ量が大きい場合や地理的位置のクエリが頻繁に行われる場合、クラスター タイプは、UES が提供する「マスター ノード分離」タイプを選択できます。

(図: UES クラスターを作成するための UCloud コンソール インターフェース)

マッピングを作成する

ES は、geo_point と geo_shape という 2 種類の地理的位置データ構造をサポートしています。経度と緯度の座標を使用して場所を表す場合は、geo_point フィールドを使用できます。複雑な地形を保存および照会する場合は、geo_shape フィールドを使用できます。このクエリ「近くのレストラン」のアプリケーション シナリオでは、geo_point の方が適しています。コード例は次のとおりです。

 PUT /インデックス名 
 {  
 「マッピング」 : {  
 「タイプ名」 : {  
 「プロパティ」 : {  
 "位置" ： {  
 「タイプ」 : 「geo_point」    
 }  
 }  
 }  
 }  
 }

インデックスを作成する

場所フィールドを geo_point として宣言すると、緯度と経度の情報を含むドキュメントをインデックス化できるようになります。緯度と経度の情報は、文字列、配列、またはオブジェクトの形式で表すことができます。たとえば、レストランの座標 (経度 121.457、緯度 31.215) をインデックスに格納する場合のコード例は次のようになります。

 PUT インデックス名/インデックスタイプ/1  
 {  
 "位置" ： {  
 「緯度」 : 31.215,  
 「経度」 : 121.457  
 }  
 }

距離クエリ

ユーザーが場所 (経度 121.453、緯度 31.216) から 2000 メートル以内にあるすべてのレストランを検索する場合、内部サービスは、距離 2000 メートルとユーザーの経度と緯度 [121.453, 31.216] を含むクエリ パラメータを使用して、ES サービスに対して geo_distance クエリを開始できます。 ES サービスは、前のステップの経度と緯度 [121.457, 31.215] にあるレストランを含め、基準を満たすレストランを返します。

この時点で、UES を使用してクライアント ユーザーの近くの特定の範囲内にあるレストランのニーズを照会する手順が完了しました。クエリの実行中は、サービスを展開したり、2 つの地理的ポイント間の距離を計算するアルゴリズムを理解したりする必要はありません。 UES にリクエストを送信するだけです。この記事で説明するシナリオは、位置情報ベース サービス (LBS) シナリオにおける ES サービスのほんの一例です。実際のアプリケーションでは、マップ SDK と組み合わせた地形の比較や位置の集約などの機能がさらに多く存在し、さらに検討する価値があります。

データからさらなる価値を発見

ほぼ 1 年にわたる製品の反復と最適化を経て、UES はパフォーマンスと機能性においてさらに優れたものになりました。主なアップグレードは次のとおりです。

• 自動障害回復が可能なため、サービス停止を心配する必要がありません。
• ノードアップグレード機能を提供し、ユーザーに複数の拡張オプションを提供します。
• Elasticsearch バージョン 6.2.1 を追加し、x-pack プラグインを完全にリリースしました。ユーザーはコンソールでワンクリックでインストールできるため、Kibana をより安全に使用できます。インストール後は、Elasticsearch サービス自体の監視指標をさらに Kibana で確認することができ、使いやすいです。
• 海外アベイラビリティゾーンは、海外に進出するユーザーのビジネスニーズをさらにサポートするために開始されました。

現在、UES は UCloud の他のデータ分析製品とも接続されています。たとえば、ユーザーはデータのセキュリティを確保するために、UES データを UHadoop にバックアップできます。将来的には、UES は UKafka などのさらに多くの UCloud データ分析製品に接続され、ユーザーにデータマイニング、データ分析、視覚化の完全なソリューションセットが提供される予定です。 UES を使用すると、企業は導入と保守のコストを削減し、データからより多くの価値を引き出すことができます。