APM（アプリケーションパフォーマンス監視）とは？

APMについて説明する場合、ログやインフラメトリックの"監視性"など、別の側面も考えるとよりわかりやすくなります。ログとAPM、インフラメトリックは監視の3大要素です。

3つの領域には重なり合う部分もあり、相互に関連付ける際に役立ちます。ログは、エラーが生じた痕跡を示すかもしれませんが、エラーの理由までは示しません。メトリックはサーバー上でCPU使用量にスパイクがあったことを示すかもしれませんが、何が原因だったかは示しません。しかし、うまく組み合わせて活用すれば、はるかに広い範囲の問題を解決できる可能性があります。

ログ

はじめにいくつかの定義について考えておきましょう。ログとメトリックには、わずかな違いがあります。通常、ログは何かが生じたときに発信されるイベントです。あるリクエストが受信されたとか、反応があったとか、ファイルを開いた、コードでprintfが生じた... といった出来事です。

たとえば、Apache HTTPサーバーのプロジェクトからくるよくあるログ形式はこんな感じです（フェイクデータ、短縮のため一部省略）。

264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "GET /ESProductDetailView HTTP/1.1" 200 6291
264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "POST /intro.m4v HTTP/1.1" 404 7352
264.242.88.10 - - [22/Jan/2018:16:38:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253

ログの情報は、アプリケーションの全体を把握するというより、コンポーネントレベルにとどまる傾向にあります。しかし人間が読む上では便利です。上の例では、IPアドレスと、明らかに設定のないフィールド、日付、ユーザーがアクセスしていたページ（とその方法）、いくつかの数字を確認することができます。私の経験から、一連の数字がレスポンスコード（200はよい、404は良くないが、500よりはマシ）であることと、データが返された量であることがわかります。

ログは通常、対応するアプリケーションやサービスが実行されているホスト/マシン/コンテナーインスタンス上で使用でき、この例のように人間が読める情報であるため、"便利"です。一方でログには、「コードを書いておかなければ、プリントされない」という本質的なデメリットもあります。Rubyでputsを使うか、Javaでsystem.out.printlnするか、あるいは類似の作業が必須です。またプリントする場合も、フォーマットが重要です。前出のApacheログに、見慣れない日付フォーマットが含まれています。たとえば"01/02/2019"という日付を考えてみましょう。米国に住む私にとっては2019年1月2日という意味ですが、世界の多くの仲間はこの日付を2019年2月1日と読みます。ロギングでstatementの形式を決定する際は、こうした点も考慮されることをお勧めします。

メトリック

一方、メトリックは周期的なサマリーやカウントの情報が主です。たとえばこの10秒間に、平均CPUは12％で、アプリケーションが使用したメモリ量は27MB、であるとか、プライマリディスクの容量は71％、といったことです（いま筆者のマシンのメトリックを確認してみました）。

上のスクリーンショットは、あるMacで実行されているiostatです。多くのメトリックがあることがわかります。メトリックは傾向や履歴を示したいときに便利であり、シンプルで予測可能、また信頼できるルールを作成してインシデントや異常を捉える場合に特に役立ちます。メトリックのデメリットとして、インフラレイヤーの監視や、コンポーネントインスタンスレベル（ホスト、コンテナー、ネットワークなど）のデータ捕捉が中心で、カスタムアプリケーションレベルのデータをあまり扱わない点があります。というのも、メトリックは一定の経過時間に対してサンプルされるため、わずかな外れ値が"平均化"されるリスクを伴うためです。

APM

メトリックとログのギャップに橋を架ける存在がアプリケーションパフォーマンス監視です。ログやメトリックは、インフラや複数のコンポーネントを扱う横断的なデータです。APMは特にアプリケーションに注目し、エンドユーザーエクスペリエンスを含むスタック中のアプリ層を、IT部門や開発者が監視できるようサポートします。

監視にAPMを追加するメリットとして、次のような点があります。

• サービス提供にかかる時間と、クラッシュの原因を把握できる
• サービスと他の要素の通信状況や、ボトルネックを可視化できる
• パフォーマンスのボトルネックやエラーの予防的な発見・修正に役立つ
  • 最良のシナリオは、多数のエンドユーザーが影響を受ける前の発見・修正
• 開発チームの生産性向上をサポート
• ブラウザー上でエンドユーザーエクスペリエンスを追跡可能

特に注目したいのが、"APMにはコードが通じる"という点です（この後詳しく取り上げます）。

ログとAPMで、得られる情報を比較してみましょう。先ほどこのようなログエントリがありました：

264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "GET /ESProductDetailView HTTP/1.1" 200 6291

先ほど見た通り、よい内容になっています。レスポンスに成功しており（200）、6,291バイトを返しました。しかし、レスポンスに16.6秒かかったことは示されていません。これは次のAPMスクリーンショットに表示されています。

その他にも豊富なコンテクストが見て取れます。最初のログには、このようなエラーもありました：

264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253

APMが捉えた内容はこうなります：

最終発生日時、発生頻度、アプリケーションで処理されたか否か、という情報が表示されています。たとえばNumberParseExceptionを使って例外処理の詳細を見ると、エラーが発生した回数の分布がウインドウで視覚的に表示されます。

パッと見て、一定の時間に数回起きているということ、一日中発生していることがわかります。ログで見ても、ログファイルの1つに対応するスタックの痕跡が見つかるはずです。しかしAPMのように、そのコンテクストやメタデータまで見つかる可能性は高くありません。

赤い長方形の部分はこの例外処理を実施したコード行を示し、APMが提供するメタデータが問題の正確な内容を伝えています。pythonプログラマーでない筆者のような人間が見てもどういう問題であるか正確に理解でき、チケットをオープンするために必要十分な情報があります。

スクリーンショットで見るAPMオプションツアー

Elastic APMについて一日中語ることもできる筆者ですが（よかったらTwitterで検索してください）、ここではスクリーンショットを使って、もう少し視覚的にご紹介したいと思います。早速ツアーをはじめましょう。

APMを開く

KibanaでAPMアプリケーションを開くと、Elastic APMに搭載されているすべてのサービスが表示されます：

サービスの詳細を見る

個々のサービスについて詳細を見ることができます。今回は"petclinic-spring"サービスを見てみましょう。各サービスとも、レイアウトは似ています：

左上にレスポンスタイムがあります。平均、95パーセンタイル、99パーセンタイルがあり、外れ値の部分を表示しています。さまざまな線グラフのエレメントを表示／非表示にして、外れ値がチャート全体に与える影響をわかりやすくすることもできます。右上はレスポンスコードです。時間に対してRPM（requests per minute／1分あたりリクエスト数）を詳しく表示しています。実際の画面では、各チャートの上でマウスを動かすとポップアップが現れ、特定の時間のサマリーを表示します。最初に得られるインサイトは、データを深堀りせずともすぐにわかります。すなわち、レイテンシの大きなスパイクに、"500"のレスポンス（サーバーエラー）がまったくありません。

トランザクションレスポンスタイムを詳しく見る

引き続きトランザクションサマリーを見ると、下の方にリクエストの詳細があります。各リクエストは、基本的には（さまざまなエージェントAPIを使用して初期設定を拡張可能できる）アプリケーション中の異なるエンドポイントです。リクエストは列見出しで並べ替えできますが、筆者が個人的に好んで使うのは"impact"列です。これは、そのリクエストのレイテンシと出現度を考慮します。今回の事例では、"getOwners"が最も問題を生じさせているように見えますが、それでも平均レイテンシは96ミリ秒に留まっています。このトランザクションを詳細にドロップダウンしていくと、先ほどと同じレイアウトが表示されます。

"ウォーターフォール作戦"

さて、最も遅いリクエストでも、1秒未満にレスポンスしていることがわかりました。下に向かってスクロールしてゆくと、トランザクション中のオペレーションが滝のように表示されています。

クエリ詳細表示

見ると確かに、大量のSELECT文があります。APMでは実行された実際のクエリを表示させることができます。

分散トレーシング

このアプリケーションスタックは、多層化されたマイクロサービスアーキテクチャーを扱っています。すべての層にElastic APMを組み込んであるため、[View full trace]ボタンを押してこのコールに関与する全要素が入るまでズームアウトすることが可能です。こうして、トランザクションに参加したすべてのコンポーネントの分散トレーシングを表示します：

多層的にトレーシングする

今回の事例で最初に見たのは、他の層がコールする"Spring"という層でした。いまこの画面で、"petclinic-node"が"petclinic-spring"層をコールしたことがわかります。これは2つの層でしたが、ブラウザー（React）層からはじまるより多層的な例もあります。

リアルユーザー監視

分散トレーシングの力を最大に引き出すためには、リアルユーザー監視（RUM）も含めて、できる限り多くのコンポーネントやサービスを組み込むことが重要です。サービスレスポンスタイムの早さが、必ずしもブラウザーでのすばやい動作を意味するわけではありません。つまり、ブラウザー上でのエンドユーザーエクスペリエンスを測定することこそが重要です。この事例で、分散トレーシングは4つの異なるサービスが同時に実行されていることを示しています。複数あるサービスの1つが、Webブラウザー（クライアント）です。53ミリ秒の時点でdomはインタラクティブでした。67ミリ秒では、domが完了していることがわかります。

UIにとどまらない魅力

Elastic APMは使いやすいAPM UIに加え、アプリ開発者に必要な機能を豊富にそろえています。そして、追跡データをUIで表示できるだけでなく、一歩深く活用できます。実は、Elastic APMデータは1つのインデックスとなっています。ログやメトリックから、事業データまでの情報が揃うことにより、サーバー遅延が収益に及ぼした影響を把握することも、影響の大きいリクエストを調べるなどして、次のコード拡張の計画策定にAPMデータを役立てることも可能です。

APMはデフォルトの可視化とダッシュボード機能を搭載しており、ログとメトリック、さらに事業データを組み合わせて可視化することができます。

Elastic APMを使いはじめる

Elastic APMは、LogstashやBeatsと似たデプロイトポロジーを使い、組み合わせて実行することができます：

APMサーバーはデータプロセッサーとして振る舞い、APMデータをAPMエージェントからElasticsearchに転送します。インストール手順もシンプルです。ドキュメントの"install and run"ページを参照いただくか、Kibanaで"K"ロゴをクリックしてホーム画面を表示し、"Add APM"オプションをクリックしてはじめることができます：

画面の案内にしたがって進むだけで、APMサーバーを稼働させることができます：

設定が完了したら、搭載させる各エージェントタイプについてKibanaのチュートリアルを参照することができます：

わずか数行のコードで、すべての設定が完了します。

Elastic APMの入口

新しいことを学ぶには、実際に手を動かしてみるのが一番です。また、その方法も1つではありません。実際のインターフェースをライブで、リアルに見てみたいという方はこちらのAPMデモ環境をクリックしてご覧ください。ローカルで実行してみたいという方は、APMサーバーダウンロードページの手順に沿って進めていただくことができます。

最も手軽な方法は、Elastic CloudのElasticsearch Serviceです。APMサーバー6.6、Kibanaインスタンス、機械学習ノードを含むすべてのElasticsearchデプロイが、SaaSで提供されており、1分ほどで使いはじめることができます（全サービスを2週間の無料トライアルでお試しいただけます）。クラウドサービスのため、デプロイインフラの保守/管理を行わなくて済むという大きなメリットがあります。

Elasticsearch ServiceでAPMを有効化する

APMクラスターを作成する（または既存のクラスターにAPMを追加する）には、クラスター設定の画面でAPM設定のセクションが表示されるまで下にスクロールします。既存のデプロイをアップデートする場合は[Enable]、[Save changes]の順にクリック、新規デプロイの場合は[Create deployment]をクリックします。

ライセンス

ElasticのAPMサーバーと、全APMエージェントはオープンソースとして提供されています。洗練されたAPM UIはElastic Stackでデフォルトの配布、また無料のベーシックライセンスより使用可能です。アラートや機械学習と統合する場合はベースとなるオプションのライセンスが必要になり、アラートにはゴールド、機械学習にはプラチナをご購入いただく必要があります。

まとめ

APMは、アプリケーションのあらゆる層で起きていることを表示します。機械学習やアラートと統合できるElastic APMなら検索機能を最大に活用でき、アプリケーションインフラの可視性が大きく向上します。トランザクションから痕跡、エラー、例外処理まで可視化でき、洗練されたAPMユーザーインターフェースがコンテクストも表示します。問題が発生していないときも、Elastic APMのデータを参考に修正内容の優先順位付けを行って、アプリケーションパフォーマンスの最大化と、ボトルネックの排除に取り組むことができます。

Elastic APMと監視に関するウェビナーも複数あります。併せてぜひご覧ください。

• Instrument and Monitor Java Applications using Elastic APM
• Using the Elastic Stack for Application Performance Monitoring
• Using Elasticsearch, Beats and Elastic APM to monitor your OpenShift Data
• Unifying APM, Logs, and Metrics for Deeper Operational Visibility
• Tracking your Infrastructure Logs & Metrics in the Elastic Stack (ELK Stack)

はじめてみませんか？ APMに関するトピックはディスカッションフォーラムでもご覧いただけます。チケットの送信や機能のリクエストは、APM GitHub reposにお寄せください。

Elasticsearch Serviceでは2018年8月、デプロイテンプレートや新インスタントタイプ、Hot-Warmアーキテクチャーのサポートといった多数の新機能を追加するとともに料金の大幅な引き下げを実施しました。 この引き下げには、スナップショットストレージとデータ転送の料金を使用量に応じて区分し、使用量と費用をよりコントロールしやすくするという変更も含まれていました。プロモーション期間中は料金が割引になっていたため、月々の請求書では0円の表示になる場合もありました。

このスナップショットストレージとデータ転送のプロモーション割引は2019年2月28日に終了します。本ブログ記事では、今後の料金体系の詳しい情報と、費用をコントロールするコツをお伝えします。

スナップショットストレージの料金体系

スナップショットストレージの料金は、基盤として使用するIaaSオブジェクトストア（例：AWSのS3、Google cloudのGCS）にバックアップスナップショットを格納する費用に関連付けられています。スナップショットストレージの費用はElasticsearchインデックスが稼働するディスクストレージの費用ではありません。ディスクストレージの費用はクラスター（または“デプロイ”と呼びます）の費用に含まれています。

多くのクラウドサービスプロバイダーと同様、Elasticのスナップショットとストレージ費用は2つの側面から算出されます。

• ストレージサイズ（GB/月）
• ストレージAPIリクエスト数（1,000リクエスト/月）

ストレージサイズは、アカウントに紐付けられたすべてのデプロイで生じる全スナップショットが占めるストレージ容量の測定値（GB）です。すべてのリージョンに同じユニット価格が適用されます。Elasticは料金計算のため、ストレージの容量を1時間毎に測定し、そこから1か月間の平均容量を求めています。その月の平均容量（GB/月）により、ご利用アカウントの請求月（カレンダーの月単位）の料金が決まります。

たとえば2019年4月に使用した容量が10日間は100GB、残り20日間が130GBだった場合、月の平均容量は(100×10 + 130×20)÷30で120GB/月となります。

ストレージAPIリクエストの費用は、アカウントに紐付けられたすべてのデプロイで実行されたスナップショットのバックアップ、または復元のリクエストの総数に基づいて計算されます。ストレージサイズとは異なり、リクエスト数はその請求月内に累積で加算した総数です。費用は1,000リクエストあたりの料金で算出します。

本記事の執筆時点（2019年2月1日）で、それぞれの価格体系は次の通りです。

• ストレージサイズ - 1GB/月あたり$0.033
• ストレージAPIリクエスト数 - APIリスエスト1,000回あたり$0.0018

すべてのアカウントのデプロイには、100GB/月の無料プランが提供されます。ストレージ使用量が100GB以下の場合は、費用がかかりません。100GB/月を超えると、100GBを超えて使用した部分のみ費用が発生します。

またすべてのアカウントのデプロイで、1か月あたり100,000回以下のAPIリクエストにも無料プランが適用されます。100,000回を超えた場合、100,000回を超えて使用した部分のみ費用が発生します。

注：単一のスナップショット操作は、単一のAPI呼び出しと同じではありません。複数のファイルが書き込まれたり、削除されたり、変更されたりすると、単一のスナップショット操作に関連する何千件ものAPI呼び出しが発生する可能性があります。当社が記載している価格は1000件のAPI呼び出しの価格です。つまり、1000回のAPI呼び出しで0.0018ドルの場合、100万回の呼び出しでは1.8ドルとなります。

データ転送の料金体系

データ転送料金は、Elasticsearchデプロイへの入力/出力、およびデプロイ内で転送されるデータ容量（ペイロード）に基づいて算出されます。

Elasticでは、次の3つの側面からデータ転送料金を算出・請求しています。

• 入力データ（無料）
• 出力データ
• デプロイ内データ

入力データは、クラスターに入るすべてのトラフィックです。データペイロードを伴うインデックスリクエストや、クラスターに送られるクエリ（サイズはかなり小さいですが）が含まれます。

出力データは、クラスターから出るすべてのトラフィックです。検索結果や、クラスターから出力される監視データがこれに含まれます。異なるリージョンやインターネット、同じリージョンの別のアカウントなど、データの出力先に関わらず同じ料金が適用されます。

デプロイ内データは、デプロイのコンポーネント間を移動するトラフィックです。主に、さまざまなアベイラビリティゾーンにまたがるクラスターのノード間のデータ同期（Elasticsearchクラスターシャーディングによる自動管理）が含まれます。この他に、クラスターの複数のノードにまたがって実行される検索クエリに関連するデータも含まれます。シングルノードのElasticsearchクラスターでも、Kibanaや機械学習、APMなどのノードとの間でデータが行き交うことによりクラスター内の費用が生じることがあり、注意が必要です。とはいえ、こうしたケースで生じる費用は非常に低額です。

ストレージAPIリクエストの計算方法と同様、データ転送の使用量計算はその請求月内に累積で加算されます。

本記事の執筆時点（2019年2月1日）で、それぞれの価格体系は次の通りです。

• 入力データ - 転送量/GBあたり$0（入力データは無料です）
• 出力データ - 転送量/GBあたり$0.032
• デプロイ内データ - 転送量/GBあたり$0.016

すべてのアカウントの全デプロイで、出力データとデプロイ内データにそれぞれ100GB/月の無料プランが提供されます。100GB/月の無料プラン容量を超えると、100GBを超えて使用した部分のみ費用が発生します。

FAQ

スナップショットストレージとデータ転送のコストを確認するには？

スナップショットストレージとデータ転送のコストは、請求書の内訳項目に記載されています。ユーザーコンソールからダウンロードしてご確認いただくことができます。さらに今後のアップデートで、ユーザーコンソールで費用を1日単位で表示できるようにする予定です。翌月の請求を予測しやすくなります。

請求書の例：

新しい料金体系はいつから適用される？

2019年2月1日の請求書（2019年1月のご使用分）より新方式での表示となりますが、請求は発生しません。翌月からのデータ転送とストレージの料金の目安として提示されます。2019年3月1日の請求書（2019年2月のご使用分）についても同じです。3月1日以降の使用がご請求対象となり、2019年4月1日の請求書（2019年3月のご使用分）から実際のご請求が発生します。

スナップショットストレージの費用をコントロールするには？

Elasticsearchのスナップショットは、スナップショットイベントのたびに増分データを保存します。したがって有効なスナップショットサイズは、現在のインデックスサイズよりも大きいということになります。クラスターで使用するデータが大きくなるほど、またデータの変更（追加/削除/修正）が頻繁なほどサイズは大きくなります。より細やかなコントロールのため、Elasticではただデータの変化を記録するスタイルから一歩進んだ機能も導入しています。Elastic Cloudのユーザーコンソールで、[Snapshot]のサブメニューにある[Snapshot count]という高度なパラメーターがその機能です。現在、デフォルトでは100スナップショット（ロールオーバー）に設定されていますが、2-100の間で数値を変更することができます。

注意点：スナップショットの数を減らすことで、インデックスの保持期間を効果的に短縮させることができます。つまり、直近の復元ポイントだけが残り、復元ポイントが消えるまでの時間が短くなります。

APIリクエストはスナップショットを取るたび、または復元が行われるたびに実行されます。復元は一般的に高い頻度で行われるものではありません。一方スナップショットは常に最新の復元ポイントを保つため、デフォルトでは30分おきに実施されます。Elasticは[Snapshot interval]というパラメーターを提供しています。このパラメーターを使用すると、スナップショット間隔を最長で24時間まで延長でき、APIリクエストを減らすことができます。

注意点：スナップショットの間隔を延長すると、部分的なデータロスを生じる可能性があります。スナップショットが古くなるため、復元操作を行う際、最後のスナップショット以降に変更されたデータが復元されません。

最後に、Elasticsearch APIを使用して何らかのスナップショット作成/復元のロジックを実装した場合は、過度の費用が発生しないようプロセスを確認することをお勧めします。

データ転送費用をコントロールするには？

デプロイ外部やクラスターのノード間のデータ転送については、容易にコントロールすることはできません。ユースケースにおいて、クラスターを使用する機能の設定を変えられるとは限らないためです。頻繁に実行されるバッチクエリがあるケースでは、設定を見直すことができる場合があります。

請求額にどのように影響する？

Elasticsearchはさまざまなユースケースで使用されており、ご利用のアカウントでスナップショットストレージやデータ転送コストを予測することは簡単ではありません。そのため今回2か月間にわたって、請求額をお伝えしますが、実際の請求は0になるというサービスを実施いたします。新しい料金体系での費用を把握する機会としてご活用いただければ幸いです。

ゴールド/プラチナの年間サブスクリプションがある場合、請求額への影響は？

スタンダード、ゴールド、プラチナで既に年間のご契約をいただいているお客様は、2019年1月1日以降に更新されたご契約に切り替わるまでご請求の増額や変更はありません。2019年1月1日以降に年間でサブスクリプションをご購入いただく場合、月々のご契約と同じ新しい料金体系でのご請求となります。

GCPにデプロイしている場合、料金体系は変更される？

はい。本ブログ記事の執筆時点では、Elasticsearch Serviceスナップショットストレージとデータ転送の新料金は、ご利用のすべてのクラウドプロバイダー様で同一の価格となります。

ECS（Elastic Common Schema）はElasticsearchのデータを一貫した方法で構造化し、カスタマイズにも対応する新しい仕様基準です。ECSの導入で、多様なソースのデータを分析することが可能になります。ECSを使用して、ダッシュボードや機械学習ジョブといった分析コンテンツをより広範に適用したり、検索をより厳密に設定することができ、フィールド名も覚えやすくなります。

Common Schemaを使う理由

インタラクティブな分析（例：検索、ドリルダウン、ピボット、可視化）を行う場合にも、自動化された分析（例：アラート、機械学習による異常検知）を行う場合にも、データは統一された方法で分析する必要があります。しかし同じソースから来るデータでない限り、フォーマットはバラバラになります。具体的には、次のような不統一です。

• 異なるデータタイプ（例：ログ、メトリック、APM、フロー、コンテクスチュアルデータ）
• さまざまなベンダーを使う混成環境
• 類似しているが異なるデータソース（例：Auditbeat、Cylance、Taniumといった複数のエンドポイントデータソース）

たとえば「複数のソースから取得されたデータで、特定のユーザーを検索する」という状況を考えてみましょう。たった1つのフィールドを検索するにも、user、username、nginx.access.user_name、loginといった複数のフィールド名を考慮する必要が生じます。このデータについてドリルダウンやピボットを実行するとなれば、さらに処理は複雑になります。さらに可視化やアラート、機械学習ジョブといった分析コンテンツを開発するとしたらどうでしょうか？新しいデータソースを取り込むたびに複雑になり、重複も生じてしまいます。

Elastic Common Schemaとは？

ECSはElasticsearchに投入されるデータ用に、一般的なドキュメントフィールドを定義するオープンソースの仕様基準です。ECSはデータモデリングの統一化をサポートし、双方向性と自動化の2つの手法で多様なソースから一元的にデータを分析できるように設計されています。

ECSの特長として、分類に特化した予測性と、カスタムユースケースに対応する包括的な仕様による汎用性の両方を兼ね備えていることがあります。ECSの分類基準は、フィールドのデータ要素を次の3つのレベルに配置します。

Elastic Common Schemaを活用する

活用事例1：パース

次のApacheログでECSを使用してみます。

10.42.42.42 - - [07/Dec/2018:11:05:07 +0100] "GET /blog HTTP/1.1" 200 2571 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"

このメッセージをECSにマッピングすると、ログのフィールドは次のように整理されます。

上に示されているように、生のログはECSのevent.originalフィールドに保存されて、監査ユースケースをサポートしています。説明をシンプルにするため、この事例では監視エージェント（ agent.*の下にあります）に関する詳細と、ホスト（host.*の下にあります）、その他いくつかのフィールドの情報の一部を省略しています。より完全な再現については、こちらのJSONイベント事例をご覧ください。

活用事例2：検索

特定のIPのアクティビティを、ある完全なWebスタック全体で調査してみます。このWebスタックの構成は、Palo Alto Networks Firewall、HAProxy（Logstashで処理）、Apache（Beatsモジュールを使用）、Elastic APM、さらにSuricata IDS（カスタム、独自のEVE JSONフォーマットを使用）です。

ECSを使用する前にこのIPを検索すると、次のように表示されるかもしれません。

src:10.42.42.42 OR client_ip:10.42.42.42 OR apache2.access.remote_ip:10.42.42.42 OR context.user.ip:10.42.42.42 OR src_ip:10.42.42.42

すべてのソースをECSにマッピングした後のクエリは、ずっとシンプルになります。

source.ip:10.42.42.42

活用事例3：可視化

ECSの実力は、複数の異なるデータソースからデータを統一された方法で正規化する場面で特に発揮されます。Webスタックの脅威を監視するとき、たいていの場合はネットワークデータの複数のソースを使用します。ここでは境界上のPalo Alto Next-Gen FirewallとSuricata IDSのイベントとアラートを使用しています。Kibanaで一元的に可視化でき、ベンダーを問わずドリルダウンとピボットを実行できるようなやり方でsource.ipとnetwork.directionフィールドから各メッセージを抽出するには、どうすればよいでしょうか？もちろん答えはECSです。ECSを使わない場合に比べて、一元化された監視を大幅に簡単に実現できます。

Elastic Common Schemaのメリット

ECSの導入により、検索、ドリルダウン、ピボット、データ可視化、機械学習ベースの異常検知、アラートを含む、Elastic Stackの分析全体の様式を統一することができます。完全に組み込めば、非構造化と構造化の両方のクエリパラメーター能力を活用して検索することが可能になります。またECSは、1つのベンダーを異なるデバイスで使用している、あるいはデータソースの種類が全く異なるといった条件にかかわらず、異なるデータソースのデータを自動的に関連付ける機能をスムーズに実現します。

さらにECSは、分析コンテンツの開発時間も短縮します。組織に新しいデータソースが加わるたびに検索やダッシュボードを新規に作成する必要がなくなり、既存の検索やダッシュボードを使用し続けることができます。ECSを使えば、Elasticやパートナー、オープンソースプロジェクトなど、ECSを使用する他のパーティーから環境に直接分析コンテンツを導入することも簡単になります。

インタラクティブな分析も手軽になります。ECSでは、データソースごとに異なる設定ではなく、1つの設定だけを使用するため、一般的に使用されるフィールド名を覚えておくことも簡単です。ECSでは（いくつかの例外はありますが）、シンプルで標準的な名付け方法に従った仕様基準なので、フィールド名を忘れる可能性も減少します。

ECSを導入したくない場合は？問題ありません。必要なときはいつでも使うことができ、必要なければ使わなくても大丈夫です！

Elastic Common Schemaを使いはじめる

ECSはGitHub repoに公開されており、レビュー可能です。現在はBeta2で、まもなく一般公開への移行を予定しています。Apache 2.0オープンソースライセンス下で公開されており、Elasticの広範なコミュニティで幅広く導入できるようになっています。

魔法みたいな機能なの？あらゆるスキーマと同様、ECSの実装も手軽ではありません。もしすでにElasticsearchのインデックステンプレートを設定して、LogstashやElasticsearchのIngestノードでいくつかの機能変換を記述したことがあれば、こちらの作業もイメージできるかもしれません。Elastic Beatsモジュールの今後のバージョンはデフォルトでECSフォーマットのイベントを提供するようになる予定です。これにより、移行もスムーズになります。第一弾として、こちらの新しいAuditbeat向けのシステムモジュールは新仕様となっています。

ECSについては、Elastic Common Schema（ECS）ウェビナーでも詳しくご紹介しています。ぜひご覧ください。今後のブログ記事では、データをECS（スキーマに定義されていないフィールドを含む）にマッピングする方法や、ECSの統合戦略についてお伝えする予定です。

昨年Elasticに入社して約半年が過ぎ、初めてのバレンタインデーを迎えようとしています。

「Elasticに入ってどう？」「どんな感じ？」と聞かれる機会も多く、
そんな時に私は、あるエピソードを話すようにしています。

それは12月のある日のことでした。
マーケティング担当としてお客様への感謝の気持ちを込めたイベントを企画し、開催前には当然のことながらさまざまな準備に追われていました。その一つがネームバッジの作成。お客様の名前を書いたカードを印刷して、それを透明なバッジに入れるという作業をしていました。
延々と続く単調な作業でした。カードをバッジに入れる、カードをバッジに入れる、カードをバッジに入れる。そして、その様子をみたオフィスの同僚達が、自発的に「手伝います」と私の作業を手伝ってくれたのです。
私はその時、「これがチームワークなんだな。これが仲間意識を築くということなんだ。」と、ひとり胸を熱くしていました。

そんな些細なこと、と思われるかもしれません。
でも、部署とか、役職とか、肩書きとか、性別とか、年齢とか、全く関係なく、自然とチームで仕事ができる。
上から言われるわけでもなく、自発的に助け合える。そんな理想的とも言える職場環境が実際に存在することは、あまり多くないかもしれないと感じています。

さて、話をバレンタインデーに戻しましょう。
バレンタインと言えば義理チョコ。日頃の感謝の気持ちを同僚達に伝えたいなと思い、どんな義理チョコを用意しようと悩みました。
初めは高級チョコでも買おうかなと考えていましたが、人と同じことをしたくないマーケター魂が疼き、ついに「そうだ！Elasticロゴでアイシングクッキーを作ろう！」と思い立ちました。Elasticロゴのステッカーは可愛くてお客様にも人気なので、きっと同僚達にも喜んでもらえるはず、と思ったのです。

でも、残念ながらお菓子作りは趣味ではなく、アイシングクッキーなんて一度も作ったことがありませんでした。
そこでまずはアイシングクッキー 作りを学ぶためのスクールに行きました。そしてこれが練習の作品です。

そして、スクールでElasticロゴのアイシングクッキーを作りたいことを伝えると、先生はとても親身に、ロゴの色をどうやって作り出すかについてまで懇切丁寧に教えてくれました。

また、Elasticロゴの形はユニークなので、クッキー型の特別オーダーが出来ることも教えていただき、これが特注したクッキー型です。

そして、バレンタイン前の三連休に、Elasticクッキー の制作に取り掛かりました。まずはElasticロゴの形をしたクッキーを焼いて。

それからElasticロゴの色のアイシングクリームを作りました。

次にクッキーにアイシングクリームをのせていきました。

完成！

Elastic的バレンタインデーの義理チョコを感謝の気持ちと共に。

本記事は最近のElastic{ON} Tourでの事例紹介セッションの要約です。Elastic{ON}のトークはアーカイブで多数公開中です。また、お近くの都市で開催されるElastic{ON} Tourのスケジュールもご覧ください。

世界最速のスーパーコンピューター「サミット」は、米国エネルギー省（DOE） のオークリッジ国立研究所（ORNL）にあります。ORNLの研究者の仕事は演算速度200ペタフロップスの能力に支えられており、このことが物質科学、中性子科学、エネルギー、国家安全保障、高機能演算といった幅広い分野の科学的発見を促進しています。

これらすべての研究で生み出されたデジタル情報を保護するために、ORNLのサイバーセキュリティチームはElasticsearchとElastic Stackをセキュリティ情報およびイベント管理（SIEM）に用いています。しかし、最初からそうだったわけではありません。ワシントンでのElastic{ON} Tourで、ORNLのサイバーセキュリティ部門のエンジニアにしてSIEM管理者のLarry Nichols氏は、ORNLが大規模なログ監視と異常検知にわたる約20,000のエンドポイントのセキュリティ管理能力を改善するために、SplunkからElasticsearchへと移行した理由について解説しました。

6年間にわたり、ORNLのサイバーセキュリティチームはSplunkをSIEMに使用していました。しかしORNLのニーズが高まり、ますます大量のデータを投入することや300億件を超えるドキュメントの莫大なインデックスに対してクエリーを実行することが必要になってくると、いくつかの課題に直面して、別のソリューションを追求せざるを得なくなりました。Splunkのライセンスは1日あたりの投入データ量をベースにしており、このために研究所はデータを追加することが制限されていました。スピードも障害となっていました。ORNLの主要目標は研究の促進ですが、Splunkクラスターでは検索に15分もかかることがあり、データ分析から貴重な時間を奪っていたのです。「Splunkによる処理は私たちが望むよりも長く時間がかかり、アナリストはデータ収集を待つ間に自分で分析できるほどでした」（Nichols氏）。

Elasticsearchへの切り替えという決断はORNLにとって有意義なものでした。投入できるデータ量の制限がなくなり、何分もかかっていた検索が数秒に短縮されたのです。「私達には拡張できるハードウェアもリソースもありましたが、データの投入に余分なお金をかけたくなかったので、Elasticは明らかに魅力的でした」とNichols氏は語り、「スピードは明らかに、Elasticsearchの方がはるかに上でした」とも付け加えました。

Elasticsearchで、ORNLはスピードとセキュリティを強化したSIEMを展開することが可能になりました。現在、研究所の実働アーキテクチャでは、25のElsaticsearchのノードが、すべてDocker内で25の仮想マシンにわたって実行されています。このシステムには1日あたり20億以上のドキュメント（データ量約1.5TB）が投入され、180日分のデータ（3千億以上のドキュメント）を10のホットノードと7つのウォームノードにわたり保持しています。3つの機械学習ノード、3つのマスターノード、2つのコーディネーションノードも、合計120TBのディスク容量で実行しています。開発アーキテクチャは保持するログがより少ない（30日分）だけで、ほとんど同じです。ORNLには、研究とテスト専用の3番目のクラスターがあります。日々約1.5TBのデータが投入されるこのクラスターでは、物理サーバーに6つのElasticsearchノードを備えています。最後のクラスターはシングルノードで、他の3つのクラスターの監視に使われています。

Elasticsearchに加えElastic Stackの他の部分によって、セキュリティ上の問題の特定と対処を強化しています。チームはKibanaを使用しており、ユーザーの一般的な使用状況をひと目で確認したり、必要に応じて特定のユーザーに注目したりすることができます。またグラフによって、さまざまなインデックスに基づく関連データを可視化することも可能です。この情報により、1台のマシンの感染が判明した場合には、その問題を食い止め解決するために、感染したデバイスと通信した他のマシンをすばやく特定することができます。さらに最近、チームはCanvasの使用を始めており、ダイナミックなインフォグラフィックスタイルのダッシュボードを作って研究所でのアクティビティに関するハイレベルな画面を管理者層に提供しています。

ORNLがElasticsearchをどのように使用し世界最速のスーパーコンピューター上で検索とセキュリティ管理を強化しているか、さらに詳しくはElastic{ON} TourでのNichols氏のセッション全体をご覧ください。

Elasticは優れたプロダクトを作り、その優れたプロダクトを基礎にコミュニティを築き、ユーザーを成功に導くことに重点を置いて活動しています。

私は2009年、Elasticsearchの最初の数行のコードを書き始め、そのコードをオープンソース化しました。当時の仕事を辞め、2年間を費やしてプロダクトを開発しながら、その周囲に広がってゆく素晴らしいコミュニティを支えました。そして2012年、私たちはコミュニティから会社を立ち上げ、Elasticが誕生しました。Elasticはユーザーコミュニティに投資し、そこから開発されるオープンソースプロダクトのエコシステムと手を携えて歩んできました。今となってはその数もわからないほど多くの機能をApache Luceneに追加し、あらゆるプロダクトに使える強固な土台にしました。さらにラシードが作ったKibanaや、ジョーダンによるLogstash、モニカとトゥドゥールのPacketBeatなど、数々のプロダクトも加わりました。私たちはプロダクトを開発し、その周囲にコミュニティを育み、ユーザーに最大の価値を提供することに重点を置いて歩んできました。今日、Elasticは数百人の開発者とともに、この重要な仕事に取り組んでいます。私たちが共有する成果に日々貢献するコミュニティメンバーの数は数十万人に達します。私は、このコミュニティを擁する企業を設立したことを誇りに思います。

ユーザーと共に確かな信頼を築いたことは私にとって誇りであると同時に、恐れ多いことにも感じられます。すべてはオープンソースとして公開したことからはじまりました。コミュニティとユーザーにすべての取り組みについて真実を伝えるという姿勢は、今も堅持しています。また私たちは、どのような存在によってもこの事実を奪われることのないよう尽力してきました。

設立以来何年もの間、ElasticはFUDの問題と戦っています。何か素晴らしいものが生まれたとき、この問題はかならず現れます。多くの場合FUDは、そのムーブメントがもたらす影響を恐れる（より）大きな企業が引き起こします。これはある種、自然なことです。「あんなプロダクトを使うな、ただのオモチャだ」、「数人の開発者しかいない小企業など、バスにひかれたら終わりだ」、「いわゆる"企業"のニーズをわかっていない」、「彼らはホンモノのXXXじゃない（XXXに流行のワードを挿入）」... 私たちは決してこうした雑音に耳を貸すことなく、影響されずにやってきました。こうしたFUDは、"ユーザーが愛する、優れたプロダクトとコミュニティを築く"というElasticやコミュニティの重要な目的を妨害するために行われます。これを野放しにすれば、私たちは頓挫させられることになります。でも、そうはさせません。

Elasticのプロダクトはこれまで、数えきれないほどのバージョン分岐、再分配、再パッケージ化を経験してきました。これは私たちの成功と、プロダクトのすそ野の広がりを意味します。中国の大企業から今ではAmazonまで、多数のベンダーからリリースされています。そこには常に"理由"があり、ニセの利他主義や博愛主義で隠されていることもあります。しかし、そうしたものが生き永らえることはありません。あくまで彼らのニーズに応えるために開発され、混乱を加速し、コミュニティを分裂させるためのものです。"ユーザーが愛する、優れたプロダクトとコミュニティを私たちのやり方で築く"、このコミットメントとフォーカスは私たちのユーザーの心に共鳴します。Elasticは確かな信頼を築き、期待されるペースのイノベーションと優れたコラボレーションを実現してきました。シンプルな事実であり、皆さんが目にしてきた通りです。

Elasticはオープンソースと、その力を信じています。同時に、一部の機能が有償で提供されることと、その理由についても当初からお伝えしてきました。私はこの"誠実さ"こそ、私たちが共に収めた成功の大きな理由だと信じています。私たちはElasticのオープンソースコードをほかのものと接続できるように、クリーンなやり方で実装できるように設計しました。私たちはスタートした時から一度もスタイルを変えることなく、何年もかけてユーザーとの信頼を築き、言葉によって、そしてユーザーの手によってそれを守ってきました。

これまでElasticの有償コードは他社にとって"インスピレーション"であり、さまざまな企業によって遠慮なくコピーされました。元をたどればあちこちに分散した特定の仲間だったこともわかり、たとえば最近Amazonでリリースされたもののように、悲しく、痛ましいことですが、致命的なバグを含んでいます。Elasticはユーザーに愛されるべく、優れたプロダクトとコミュニティ作りに専念してきました。私たちは誰にも邪魔させずにそれに専念していましたが、その10倍返しを受けました。

Elasticのブランドは幾度も使用され、乱用され、乗っ取られ、誤って表現されました。局所的に言えばAmazonのように、複数の企業がElasticと協働で作業しているという不誠実な表明を行ってきました。私たちは誰にも邪魔させずに専念し、Elasticはユーザーが愛する、優れたプロダクトとコミュニティ作りを続けてきました。企業にとって重点を希薄化するものは敵であり、私たちは決してその影響を受けることはありません。Elasticにとって大切なのは、あなたです。大切なのはElasticのユーザーであり、外部の雑音ではありません。

私たちは他の企業を合併する際、コードを公開しました。私たちはユーザーがプロダクトをAPMに使いはじめる様子を見て、ワクワクしました。私たちはOpBeatと呼ばれていたAPM分野の純粋なSaaS企業を合併しました。Elasticにとっては資金的に大きな投資でしたが、大部分をオープンソース化し、すべてを無償化しました。ユーザーが愛する、優れたプロダクトとコミュニティを重視するElasticにとって、その判断は簡単です。ユーザーは、つまりあなたは、この恩恵を受けるに値します。

他の企業が非公開化するとき、私たちは公開します。私たちはElasticのオープンソースコードを同じまま、同じライセンスの下に置き続け、会社として何倍にも成長を遂げました。既存の有償コードのライセンスをより寛容なものへ移行し、コードを公開しました。オープンソースコードから他のものまで、あらゆる活動に同じ水準のコラボレーションと透明性を育むよう取り組んできました。これは、ユーザーと重ねてきた多くのやり取りの中で生まれたリアクションであり、いま、皆さんがこれほど共鳴してくださっていることを心から嬉しく思います。その後Elasticのオープンソースへの投資水準は、上がることはあっても、下がることはありませんでした。より多くの無償機能や無料のエクスペリエンスを提供し、明らかに前進し、配布してきました。

Elasticの成功を目にした企業が私たちのところへ来て、コードについてコラボレーションし、Elasticユーザーよりも優遇されるサービスを開発するための特別な共同作業を提案するとき、私たちの答えは「いいえ」です。このやりとりは過去何年もわたって数えきれないほど繰り返され、ごく最近に限ったことですが、今回のAmazonでも同じでした。中には理解を示してくださり、Elasticやコミュニティーの素晴らしいパートナーとなっている企業もあります。その他の企業は、残念ながらそうではありませんでした。私たちは、プロダクトに貢献する1人の開発者に対して、他のコントリビューターと平等に、同じように接することを宣言しています。特定の人が優先されることはなく、そのような要求に対しては拒絶します。Elasticの回答は一貫しています。「プルリクエストを送信してください。他の皆さんがされているように」。品質は自明です。言葉による説明は必要ありません。

私がこの文章を書く背景には、いくつかの理由があります。第1に、どのような企業も時に、成功の内容と理由を自己分析し、歩むべき道から外れないように努める必要があります。あなた、つまりユーザーやコミュニティ、Elasticと共に歩む道です。第2に、外部の人たちに対して。私たちをこの道から逸らそうとするものは数多くあります。しかし私たちにとって大切なのは、"重要な点に集中し、忠実であり続けること"、それだけです。最後に、私たちが共有する取り組みは、"ユーザーが愛する、優れたプロダクトとコミュニティを作り続ける"ことなのだと表明するためです。これが私たちの羅針盤の"北"です。

Elasticでは毎日がDay 0です（多くの開発者のように、私たちも0からナンバリングします）。コードの最初の1行を書いた時からそのようにして、この10年をあなたと、ユーザーと共に歩んできました。そして、これから訪れるべき長い年月も同じです。私からすべての方に、:elasticheart:を。

データセンター間のレプリケーションは、Elasticsearch のミッション・クリティカルな用途では、しばらくの間は要件となってきましたが、以前は他のテクノロジーによって部分的に解決されていました。Elasticsearch 6.7 でのクロス・クラスター・レプリケーションの導入により、データ・センター、地理的にも、または Elasticsearch クラスター全体にわたって、情報をレプリケートするための追加のテクノロジーは不要になります。

クラスター横断複製 (CCR) は、1つの Elasticsearch クラスターから1つ以上の Elasticsearch クラスターへの特定のインデックスのレプリケーションを可能にします。データの局所性を含む複数のレプリケーション(ユーザー/アプリケーション・サーバへの近い場所にデータをレプリケートする、製品カタログのレプリケーションを、20個の異なるデータセンターに複製するなど) に加えて、CCR にはさまざまな使用例（本社のクラスターへの1,000の銀行の支店から報告を目的としてレプリケーションするなど）があります。

このチュートリアルでは、CCR を使用したデータセンター間のレプリケーションについて、私たちは CCR の基本を簡単に紹介し、アーキテクチャオプションとトレードオフを強調し、データセンターを使用しない展開のサンプルを構成して、管理コマンドを強調します。CCR の技術概要については、「リーダーをフォローする: Elasticsearch でのクラスター間レプリケーションの概要」を参照してください。

CCR は、プラチナレベルの機能であり、試用版の API を通じて有効にするか、または Kibana から直接有効化できる30日間の試用ライセンスを使用できます。

クロスクラスターレプリケーション (CCR) の基本事項

レプリケーションはインデックス・レベル (またはインデックスパターンに基づいて)で構成される

CCR は Elasticsearch のインデックスレベルで構成されます。レプリケーションをインデックスレベルで構成することにより、一部のインデックスを一方向にレプリケートする、他のインデックスを別の方向に複製する、複数のデータセンターアーキテクチャなど、レプリケーションに関する多数の戦略を利用できます。

レプリケートされたインデックスは読み取り専用である

インデックスは、1つ以上の Elasticsearch クラスターによって複製できます。インデックスをレプリケートしている各クラスターは、インデックスの読み取り専用コピーを保持しています。アクティブなインデックス書き込みを受信できるのはリーダーといいます。そのインデックスのパッシブな読み取り専用コピーは、フォロワーと呼ばれます。新しいリーダーには選挙の概念はなく、リーダーインデックスが使用できない場合 (クラスターやデータセンターの停止など)、別のインデックスは、アプリケーションまたはクラスターアドミニストレーター (多くの場合別のクラスターでも可) によって書き込みが行われるよう明示的に選択する必要があります。

CCR の既定値は、多種多様な高スループットの用途で選択可能

値を調整することがシステムに与える影響を完全に理解していない限り、既定値を変更することはお勧めしません。 ほとんどのオプションは、"max_read_request_operation_count" や "max_retry_delay" などのフォロワーの作成 API にあります。すぐに、独自の作業負荷に合わせて、これらのパラメーターを調整するための情報を今後公開します。

セキュリティ要件

CCR 入門ガイドで説明しているように、ソース・クラスターのユーザーは、"read_ccr" クラスター特権、"監視"、および "読み取り" インデックスの特権を持っている必要があります。ターゲット・クラスター内では、「manage_ccr」クラスタ権限、「monitor」、「read」、「write」、「manage_follow_index」インデックスの権限が必要です。LDAP などの集中認証システムも使用できます。

複数データセンター CCR アーキテクチャの例

本番および DR データセンター

2つ以上のデータセンター

チェーンレプリケーション

双方向のレプリケーション

データセンター間の導入に関するチュートリアル

1. セットアップ

このチュートリアルでは2つのクラスターを使用し、両方のクラスターはローカルコンピューター上にあります。どのような場所にいても、クラスターは自由に検索できます。

• 「us-cluster」: これは当社の「米国のクラスター」であり、ポート9200でローカルに実行します。ドキュメントは米国のクラスターから日本のクラスターに複製されます。
• ‘「japan-cluster」: 当社の「日本のクラスター」である、ポート8200でローカルに実行します。日本のクラスターでは、米国のクラスターからレプリケートされたインデックスを維持します。

2. リモートクラスターの定義

CCR を設定する場合、Elasticsearch クラスターは他の Elasticsearch クラスターを認識している必要があります。これは単一方向の要件であり、ターゲットクラスターはソースクラスターに対する単一方向の接続を維持します。他の Elasticsearch クラスターをリモートクラスターとして定義し、それらを説明するエイリアスを指定します。

日本のクラスターにおける「us-cluster」の認識を確保したいと思います。CCR でのレプリケーションはプルベースであるため、「us-cluster」から「japan-cluster」への接続を指定する必要はありません。

「japan-cluster」の API 呼び出しで 「us-cluster」 を定義します。

# From the japan-cluster, we’ll define how the us-cluster can be accessed
PUT /_cluster/settings
{
  "persistent" : {
    "cluster" : {
      "remote" : {
        "us-cluster" : {
          "seeds" : [
            "127.0.0.1:9300"
          ]
        }
      }
    }
  }
}

(APIベースのコマンドについては Kibana 内で Dev tools コンソールを使用することをおすすめしますが、これは Kibana-> Dev tools-> Console) から入手できます。

API の呼び出しでは、"127.0.0.1: 9300" でエイリアス "us-cluster" を持つリモートクラスターにアクセスできます。1つ以上のシードを指定できますが、ハンドシェイクフェーズ中にシードが使用できない場合には、一般に複数を指定することをお勧めします。

リモートクラスターの構成の詳細については、リファレンスドキュメントを参照してください。

また、「us-cluster」と接続するためにポート9300に注意しても重要なのは、elasticsearch がポート9200で HTTP プロトコルを耳にしていることです (これはデフォルトであり、「us-cluster」の yml ファイルで指定されています)。ただし、レプリケーションは、Elasticsearch のトランスポートプロトコル (ノード間通信のため) を使用して行われます。デフォルトはポート9300です。

Kibana 内では、リモートクラスターの管理 UI があり、このチュートリアルでは、ui と CCR の API を順を追って説明します。Kibana のリモートクラスター UI にアクセスするには、左側のナビゲーション・パネルで [管理] (歯車アイコン) をクリックし、Elasticsearch のセクションで「リモート・クラスター」に移動します。

Kibanaの Elasticsearch Remote Cluster Management UI

3. レプリケーションに使用するインデックスを作成する

「products」と呼ばれるインデックスを「us-cluster」に作成し、このインデックスをソース「 us-cluster」から「japan-cluster」に複製します:

"us-cluster" で、次のようになります。

# Create product index
PUT /products
{
  "settings" : {
    "index" : {
      "number_of_shards" : 1,
      "number_of_replicas" : 0,
      "soft_deletes" : {
        "enabled" : true      
      }
    }
  },
  "mappings" : {
    "_doc" : {
      "properties" : {
        "name" : {
          "type" : "keyword"
        }
      }
    }
  }
}

"soft_deletes" の設定にお気づきかもしれません。CCR のリーダーインデックスとして機能するインデックスには、論理削除が必要です (ご存知ない方はこちらを参照してください)。

soft_deletes: 論理削除は、既存のドキュメントが削除または更新されたときに発生します。これらの論理削除を構成可能な制限まで保持することで、工程の履歴をリーダーシャードに保持し、工程の履歴を再現することでフォロワーシャードの作業に使用できるようになります。

フォロワーシャードがリーダーから操作を複製すると、リーダーシャードにマーカーが残され、リーダーのフォロワーの位置がわかるようになります。これらのマーカーの下にあるソフト削除された操作は、破棄対象となります。これらのマーカーの上にあるリーダーシャードは、シャード履歴保持リースの期間 (デフォルトは12時間) これらの操作を保持します。この期間により、致命的が遅れてリーダーから再ブートストラップされるリスクが生じる前にフォロワーをオフラインにできる期間が決定されます。

4. レプリケーションの開始

リモートクラスターのエイリアスを作成し、レプリケートするインデックスを作成したので、次にレプリケーションを開始しましょう。

「japan-cluster」において:

PUT /products-copy/_ccr/follow
{
  "remote_cluster" : "us-cluster",
  "leader_index" : "products"
}

このエンドポイントには ' product-copy ' が含まれていますが、これは "japan-cluster ' クラスター内の複製さインデックスの名前です。前に定義した ' us-cluster ' クラスターからレプリケートしていますが、レプリケートしようとしているインデックスの名前は、' us-cluster ' クラスター上の ' product ' と呼ばれています。

重要なのは、レプリケートされたインデックスが読み取り専用であり、書き込み操作を受け付けることができないという点です。

これでElasticsearch クラスター間で複製を行うインデックスを構成しました！

インデックス・パターンのレプリケーションの開始

お気づきかもしれませんが、上記の例は時間ベースの使用法には十分なものではなく、日次インデックス、または大量データに関しては正しく動作しません。また、CCR API には、複製するパターンを自動で指定するパターン、つまり、レプリケートする必要があるインデックスものを定義するメソッドも含まれています。

CCR API を使用して、自動フォローパターンを定義できます

PUT /_ccr/auto_follow/beats
{
  "remote_cluster" : "us-cluster",
  "leader_index_patterns" :
  [
    "metricbeat-*",
    "packetbeat-*"
  ],
  "follow_index_pattern" : "{{leader_index}}-copy"
}

上記のサンプル API 呼び出しは、'metricbeat' または 'packetbeat' で始まるインデックスを複製します。

また、Kibana で CCR UI を使用して、自動フォローパターンを定義することもできます。

5. レプリケーションのセットアップのテスト

「us-cluster」から「japan-cluster」に製品を複製したので、今度はテスト用の文書を挿入し、それが複製されたことを確認してみましょう。

"us-cluster" クラスター上:

POST /products/_doc
{
  "name" : "My cool new product"
}

次に、「日本のクラスター」クエリして、ドキュメントが確実に複製されているか確認しましょう：

GET /products-copy/_search

1つのドキュメントが存在し、「us-cluster」に書き込まれて、「japan-cluster」に複製されるはずです。

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "products-copy",
        "_type" : "_doc",
        "_id" : "qfkl6WkBbYfxqoLJq-ss",
        "_score" : 1.0,
        "_source" : {
          "name" : "My cool new product"
        }
      }
    ]
  }
}

データセンター間管理に関する注意事項

CCR の管理上の API、チューニング可能な設定、およびレプリケートされたインデックスを通常のインデックスに変換する方法の概要について見てみましょう。

レプリケーションの管理 API群

CCR では、Elasticsearch に、便利な管理用 API がいくつかあります。これらは、レプリケーションのデバッグ、レプリケーション設定の変更、詳細診断の収集などに役立つ場合があります。

# Return all statistics related to CCR
GET /_ccr/stats
# Pause replication for a given index
POST /<follower_index>/_ccr/pause_follow
# Resume replication, in most cases after it has been paused
POST /<follower_index>/_ccr/resume_follow
{
}
# Unfollow an index (stopping replication for the destination index), which first requires replication to be paused 
POST /<follower_index>/_ccr/unfollow
# Statistics for a following index
GET /<index>/_ccr/stats
# Remove an auto-follow pattern
DELETE /_ccr/auto_follow/<auto_follow_pattern_name>
# View all auto-follow patterns, or get an auto-follow pattern by name
GET /_ccr/auto_follow/
GET /_ccr/auto_follow/<auto_follow_pattern_name>

CCR 管理 APIs の詳細については、Elasticsearch のリファレンスドキュメントを参照してください。

フォロワーインデックスを通常のインデックスに変換する

上記の管理 API群 の一部を使用して、フォロワーインデックスを Elasticsearch の通常のインデックスに変換し、書き込みを受け入れることができます。

# Pause replication
POST /<follower_index>/_ccr/pause_follow
# Close the index
POST /my_index/_close
# Unfollow
POST /<follower_index>/_ccr/unfollow
# Open the index
POST /my_index/_open

Elasticsearch の CCR (クロスクラスターレプリケーション) を引き続き探索する

このガイドは Elasticsearch での CCR の使用を開始するお手伝いをするために作成されたものですが、CCR を十分に理解していただき、CCR のさまざまな APIs (Kibana で使用できる UI を含む) について学習し、この機能を試していただければうれしいです。その他のリソースとしては、「クロスクラスターレプリケーションの概要」および「クロスクラスターレプリケーション API ガイド」を参照してください。

ディスカッションフォーラムにご意見やご感想をお寄せください。すべての質問については、できるだけ早く回答するように心がけています。

Kibana リリースの時間です! 6.5 のリリースには、スペース、ロールアップのサポート、およびCanvasなど、数多くの新しい影響の大きな機能が含まれています。また、新しいインスペクター機能やConsoleの改善など、中程度か小さな機能も備えています。

Kibana 6.5.0をダウンロード
Kibana 6.5.0 release notes
Plugin API changes

詳細については上記リリースノートに記載がありますが、中でも注目の機能は以下の通りです：

• スペースで作業を整理する
• データをCanvasに表示する
• Kibanaからロールアップジョブを作成する
• 2つの新しいサンプルデータセット
• Consoleの改善
• Spy パネルに代わる新しいインスペクター機能

スペースで作業を整理する

スペースは、最も要求の多かった機能の1つです。スペースを使用すると、保存されたオブジェクトを意味のあるカテゴリに整理できます。たとえば、sales の領域にはすべての sales のビジュアルを、ログ領域にはすべてのログ記録オブジェクトを入れます。スペースは必要に応じていくつでも作成でき、いつでもスペースを変更したり、保存したオブジェクトをスペース間で移動したりすることが可能です。セキュリティを有効にすると、どの役割およびユーザーがどのスペースにアクセスできるかを、RBAC を使用して制御できます。

スペースを作成、編集、および削除するには、Management > Spaces を使用します。または、プログラムで作成する場合は Kibana の Spaces API のように使用できます。

Canvasでプレゼンテーション（ベータ版）

Canvasは、データを1ピクセルの完璧なデザインで表示するための新しいスペースで、 Kibana、6.5 でテストすることができます。新しいワークパッドを使用すると、静的なコンテンツ （テキスト、イメージ、および図形） とデータ駆動型の要素 （グラフ、テーブル、画像など） を組み合わせることによって、データに関するストーリーを作成することができます。既定では、各動的要素はサンプルデータソースに接続されるので、独自のデータに接続する前に、実際にテストを試すことができます。Canvas はクエリの為に、Elasticsearch: es docs、SQL、およびTimelineの複数の言語をサポートしています。

Canvasツールには、リッチスタイル機能があり、ユーザーは静的要素と動的エレメントの両方の色とスタイルを変更できます。Canvas は、UI を使用して要素のコンテンツやスタイルを変更したり、要素の階層を深くしたり、css スタイルを作成する式を編集したりできるように設計されています。つまり、Canvasには、ライブデータの表示に必要なすべてのものが用意されています。

ロールアップジョブを作成および管理する

Kibana には、ロールアップジョブの作成、開始、停止、および削除を行うための新しい管理 UI があります。ロールアップは、Elasticsearch および ロールアップ を作成および管理するための API が6.4 以降で使用可能になっています。ロールアップインデックスは、履歴データを集計し、それを将来の分析のためにコンパクトにに保存するため、ストレージの一部を使用してこのデータをクエリ、集計、および視覚化できます。ロールアップジョブは、ロールアップインデックスのデータを集計する定期的なタスクです。UI に移動するには、Management に移動し、Elasticsearch のRollup Jobsをクリックします。

可視化におけるロールアップデータの表示 （ベータ）

Kibanaには、ロールアップされたデータを視覚化するベータ機能があります。ロールアップインデックスまたは混合ロールアップと生のインデックスを使用して、すべてのデータをまとめて視覚化するインデックスパターンを作成できます。ほとんどのビジュアル表示は、Timeline、Visual Builder、および Vega の視覚エフェクトを除いて、データのロールアップをサポートしています。また、ロールアップされたデータと未処理の情報に基づいて、視覚エフェクトを使用するダッシュボードを作成することもできます。最後に、ロールアップされた生データの両方が Discover で利用可能です。

2 つの新しいサンプルデータセット

新しいユーザーエクスペリエンスに合わせて調整された2つの新しいワンクリックのサンプルデータセットがあります。ビジネス分析に興味がある場合は、電子商取引のデータセットに、コスト、収益、価格など、製品に関連する情報を視覚化するものが含まれている場合は、それらをインストールします。web サイトのトラフィックを分析する場合は、web ログのサンプルデータセットを確認してください。

サンプルデータにアクセスするには、Kibana ホームページに移動し、[Load a data set and a Kibana dashboard] をクリックします。また、従来のダッシュボードには、各サンプルがCanvasワークパッドでパッケージ化されています。電子商取引のサンプルのワークパッドには、同じデータに対して2つの異なるスタイルがあります。ワークパッドは、新しいユーザーがCanvasを学習するための手段として便利です。

Consoleの強化

このリリースでは、Consoleのオートコンプリート機能が、テンプレートエンドポイントで利用可能なクエリの追加の DSL タイプ（#19178を参照）およびテンプレート（#20141を参照）に拡張されています。また、Tools ドロップダウンメニューの特定のエンドポイントのドキュメントへのリンクも追加しています。ドキュメントは、ショートカットキーの CTRL/CMD +/からも使用できます。#19715も参照ください。

最後に、構文を強調表示してGrokデバッガーを拡張しました（#18572を参照）.

Spy パネルに代わる新しいインスペクター機能

このリリースでは、以前の Spy パネルが新しいインスペクターツールに置き換えられています。新しいインスペクターでは常に、特定の要素の検査対象となる正しいデータが表示されます。古い Spy パネルとは対照的に、インスペクターの状態は一時ビューとして表示され、URL には格納されません。Spy パネルを使用して、基になるデータを表示する場合は、ビジュアル化と同じ集計を使用してテーブルを作成することをお勧めします。インスペクターは次のように開くことができます。

• ダッシュボード - パネルのコンテキストメニューを使用してインスペクターを表示します。
• ビジュアルエディター - 画面の最上部にある [Inspector] ボタンを使用します。

みなさん、楽しい毎日を過ごせますように。
Kibanaより

Kibanaの"space"で業務コンテンツ整理する

バージョン6.5より、新たに"space"機能が加わりました。"space"を使うと、ダッシュボードや可視化、その他の保存済みオブジェクトをカテゴリ別に整理することができます。各spaceは独立しています。1つのspaceに入れたオブジェクトが、他のspaceに出てくることはありません。

はじめて使う

Kibanaには自動で作成される"Default"というspaceがあります。以前のバージョンからアップグレードした場合、保存済みのオブジェクトはここに入っています。

Kibanaで開いているspaceは、いつでも画面左のナビゲーションバー下部に表示されます。ここから直接spaceの管理UIを操作して、新しいspaceを作成することもできます。 [Create space]ボタンをクリックします。

次に作成したspaceに名前をつけ、アバターを好みに応じて調整します。

URL識別子の注意点

このステップで作成する識別子は、Kibanaで使用するURLの一部になります。spaceを作成する際にURLをカスタマイズすることができますが、作成後は変更できません。

開いているspaceを把握する

Kibanaのナビゲーションバーを確認することで、現在開いているspaceをいつでも確認できます。spaceのアバターをクリックするとメニューが表示され、別のspaceに移動することもできます。

spaceを削除する

spaceを削除するには、メニューから[Management] > [Spaces]画面に進みます。次にこの画面で、削除するspaceの横のゴミ箱アイコンをクリックします。

spaceを削除すると、そのspaceに含まれるすべてのオブジェクトが削除され、復元することはできません。この点に注意してください。

space間でオブジェクトを移動する

import/export機能を使用して、spaceに保存したオブジェクトを別のspaceへ移動することができます。詳しい手順は、ブログ記事「spaceを移動する」をご参照ください。

spaceのアクセスを安全に保つ

ゴールドまたはプラチナライセンスでご利用の場合、各spaceのアクセス権を付与するロールを制御することができます。この機能を使うには、画面で[Management] > [Roles]に進みます。

spaceへのアクセス権限を定義する概念は"Minimum Privilege"と呼ばれ、3つのオプションがあります。

Minimum Privilegeを設定した後に、特定のspaceに対するアクセス権をカスタマイズすることができます。

spaceを安全に保つ活用事例

例：すべてのspaceに完全なアクセス権を付与する

Minimum Privilegeを"all"に設定することで、すべてのspaceに対するアクセス権が与えられます。この設定では、特定のspaceへのアクセス権をカスタマイズすることはできません。

例：すべてのspaceに読み取りのみのアクセスを設定し、"Marketing"spaceに完全なアクセスを付与する

Minimum Privilegeを"read"に設定すると、すべてのspaceに対して読み取りのみのアクセス権が与えられます。この設定では、必要に応じて特定のspaceに"all"アクセスを設定することができます。一方、特定のspaceに対してアクセスを禁止することはできません。

例："Executive"spaceだけに読み取りのみのアクセスを付与する

Minimum Privilegeを"none"にすると、すべてのspaceにアクセスできません。この設定では、"Executive"spaceに読み取りのみのアクセスを追加で付与することができます。

すべてのspaceの権限を表示する

あるロールがKibanaのspaceで持つすべてのアクセス権を表示するには、[View summary of spaces privileges]リンクをクリックします。

まとめ

Kibanaに加わったspaceは、パワフルな機能です。ダッシュボードや可視化を、これまでにない方法で整理できるようになりました。設計から新しくなったこのロール管理インターフェースをKibanaで活用することで、アクセスを安全に保つことができます。ブログ記事「Kibanaのspaceを移行する方法」もぜひ合わせてご覧ください。

Canvasは現在、workpadに追加できる約20の組み込みの要素（一覧についてはブログ「KibanaでCanvasを使い始める」を参照）を提供しています。このブログでは、そのうちの2つ、データ表およびデバッグ要素のみをご紹介します。

	データ表 高度に柔軟かつ動的な表です。初期状態のままで、スクロール、ページネーション、カスタムCSSがサポートされます。
	デバッグ 背後で動作するJSONデータへのアクセスを提供し、発生する問題をより正確に分析できます。

ここでは具体的に、非常に馴染みのあるデータ表である空港のフライト発着表を作成するためにCanvasを使用します。
下記がCanvasで作成する表の完成例です。

要件とレビュー

読者の環境が以下の条件を満たしていることを前提に、ブログ「KibanaでCanvasを使い始める」で説明した概念に基づき作成します。

1. ElasticsearchおよびKibanaが稼働中（バージョン6.4以降）
2. Canvasをインストール済み（CanvasはKibanaバージョン6.5以降に組み込み）

サンプルデータのインストール

このチュートリアルでは、Elastic提供のサンプルデータセット、具体的にはsample flight dataを使用します。

注：このデータセットはKibanaバージョン6.4以降でのみ使用できます。

Kibanaインスタンスにアクセスします。

1. サイドバーでメインの［Kibana］ホームページをクリックします
2. 「Add Data to Kibana」セクションの下部にあるリンク「Load a data set and a Kibana dashboard」をクリックします
3. ［Sample flight data］タイルで［Add］をクリックします

クイックリファレンス

下記の表は、先ほどインストールした、フライトのサンプルデータセットの情報を示しています。太字の下線が引かれている項目は、このアクティビティの後のほうで使用しますが、その他の項目については自由に使ってみてください。

空港の発着表の作成

作成

最初にworkpadを作成し、次にデータ表にデータを追加します。

Canvas Workpadの作成

1. Kibanaインスタンスにアクセスします
2. サイドバーの［Canvas］タブをクリックします
3. ［Create workpad］をクリックします
4. 新しいworkpadに一意の名前をつけます

データ表要素の作成

1. ［Add element］ボタンをクリックします
2. ［Data Table］要素を選択します
1. ヒント：初めて要素を作成すると、デモ用データが入った状態で表示されるため、すぐに各種の操作ができます。
3. 右の編集パネルで［Data］タブを選択します
4. ［Change your data source］をクリックします
5. ［Elasticsearch SQL］を選択します
6. SQLクエリエディターに、次のように入力します

SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights

注：このサンプルデータセットには空港のゲート番号のフィールドが含まれていません。このブログの後のほうで、ランダムに番号を生成し、その列を作成します。

7. ［Save］をクリックします
8. 以下のようなデータ表ができているはずです

コード

これでデータが入力されたデータ表ができましたが、望んでいる形式にはなっていません。背後で動作するコードを表示し、調整する必要があります。

Time列の形式の調整

1. データ表が選択されていることを確認します
2. 画面の右下隅にある［Expression editor］をクリックします
3. 式エディター内に次のコードが見つかるはずです

filters

| essql
  query="SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights"

| table

| render

分類 -- このコードには次の4つのメインセクションがあります。

1. フィルター： Time Filter要素をこのworkpadに追加すると、このデータ表要素に入力されたデータには最初に時間フィルターが適用されて、フィルターで除外されなかったデータのみが表示されることになります。この行を消去すると、データ表要素はworkpadに追加されるどのフィルター要素にも影響を受けることがなくなり、状況によっては便利です。
2. データソース： Elastic SQLデータソースを使用しているため、ここでもSQLクエリの表示と編集ができます。
3. 要素： この行は、workpadに表示する要素のタイプを定義します。試してみる場合は、「table」を「shape」に変更し、次に右下隅の［Run］をクリックして、どうなるか見てみましょう。元に戻すことを忘れないようにしてください。
4. レンダリング： 要素の表示の見た目をカスタマイズできます。このブログの後のほうで、データ表をよりスタイリッシュにするために、カスタムのCSSをレンダリング関数に追加します。
1. 「table」要素の関数で表示する前に、データを修正する必要があります。そのために、「essql」データソース関数と「table」要素の関数の間に、「mapColumn」という新しい関数を追加します。 この関数「mapColumn」は単に任意の列の値を修正するためのものです。ここで修正しようとしている列は「Time」列です。そのため、12列目に次のコードを追加します。

...
FROM kibana_sample_data_flights"
<b style="background-color:#ffae5b"><i>| mapColumn Time fn={}</i></b>
| table
...

5. Canvasには、「formatdate」関数など、利用可能な多くの組み込みの関数が用意されています。ここでは時間を「hh:mm A」の形式で表示します。そのために、コードの12行目に以下を追加します。

...
FROM kibana_sample_data_flights"
| mapColumn Time fn={ <b style="background-color:#ffae5b"><i>formatdate “hh:mm A”</i></b> }
| table
...

6. 式エディターの右下隅にある［Run］をクリックします
7. すると、エラーになりました。デバッグが必要です

デバッグの時間（この手順をスキップしないでください）

後ですぐにコードに戻りますが、まずはCanvasでのデバッグ方法を見てみましょう。

エラーの特定

1. 表要素の警告シンボルをクリックします。
2. 下図のように、エラーの原因が表示されるはずです。

3. 「mapColumn」関数がタイムスタンプデータを「number」にキャストしようとしているようです。これは、使用している「formatdate」関数が、数値形式のタイムスタンプ（UTCミリ秒など）を要求しているからです。
4. 実際には、どのようなタイムスタンプ形式になっているのでしょうか。それを解明するために、「debug」要素を追加しましょう。

デバッグ要素の追加

1. ［Add element］をクリックします
2. ［Debug］要素を選択します
3. 右の編集パネルで［Data］タブを選択します
4. ［Change your data source］をクリックします
5. ［Elasticsearch SQL］を選択します
6. SQLクエリエディターに、次のように入力します

SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights

7. ［Save］をクリックします
8. デバッグ要素では、［Time］フィールドのタイプが「date」になっており、最初のエントリーは次のようになっています：2018-11-05T00:00:00.000Z
   
9. ありがたいことに、Canvasには 「date」タイプをUTCミリ秒の数値に変換できる機能が組み込まれています。
10. データ表を再度選択し、下記のとおり式エディターでコードに「date」関数を追加します。

| mapColumn Time fn={<b style="background-color:#ffae5b"><i> date | </i></b>formatdate “hh:mm A” }

11. ［Run］をクリックします
12. データ表に適切な形式でタイムスタンプが表示されます。

ヒント：毎回、デバッグ要素を追加する必要はありません。どの要素の式エディターでも、コード | render as="debug"を追加して、その要素のJSONを見ることができます。ただし、作業中の参照用として、専用のデバッグ要素を準備しておくと便利です。

では、通常のプログラムに戻りましょう。

コードの続き

次に、「Gate」列を追加しましょう。このデータセットにはゲートのデータが含まれていないため、Canvasに組み込まれている強力な機能を使用してランダムに生成します。

ゲートのデータの追加

1. 列を追加する最も簡単な方法は、SQLクエリにエントリーを追加することです。単純に「FlightNum」データを追加し、新しい列の名称を「Gate」にします。
2. 右側のエディターパネルで［Data］タブをクリックし、SQLエディターで次の行を追加します。

SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  <b style="background-color:#ffae5b"><i>FlightNum AS Gate,</i></b>
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights

3. ［Save］をクリックします
4. 式エディターで、1行目の下にもう1つ「mapColumn」関数を追加します。今回は「Gate」列を修正します。

...
| mapColumn Time fn={ date | formatedate “hh:mm A” }
<b style="background-color:#ffae5b"><i>| mapColumn Gate fn={}</i></b>
| table
...

5. 実際のゲート番号を取得するには、1～100の間の数字をランダムに生成する必要があります。ありがたいことに、Canvasには活用できる数学関数がいくつか組み込まれています。 ここで「random」関数を使用しますが、この関数では小数点以下の桁数の多い数字をランダムに生成するため、求めているものにはなりません。そこで、2つ目の関数を追加します。ランダムに生成した数字を四捨五入する「round」関数です。コードは次のようになります。

| mapColumn Gate fn={ <b style="background-color:#ffae5b"><i>math "round(random(0,100),0)"</i></b> }

6. ［Run］をクリックします
7. これで、新しい「Gate」列にはすべて、ランダムに生成されたゲート番号が表示されるはずです。

列の結合

値が「true」のときは常に「Cancelled」ステータスが表示されるように、「Cancelled」列を「Status」列と組み合わせる必要があります。

1. データ表要素が選択されていること、および式エディターが開いていることを確認します
2. 「mapColumn」関数をもう1つ追加する必要がありますが、今回は「Status」列に追加します

...
| mapColumn Gate fn={math "round(random(1,100),0)"}
<b style="background-color:#ffae5b"><i>| mapColumn Status fn={}</i></b>
| table
...

3. 次に、「Cancelled」列のフィールド（または「cell」）が「true」になっているかどうかを確認する必要があります

| mapColumn Status fn={<b style="background-color:#ffae5b"><i>if {getCell "Cancelled" | eq true}</i></b>}

4. そして、条件がtrueの場合に「Status」列の値が文字列「Cancelled」になるように設定します

| mapColumn Status fn={if {getCell “Cancelled” | eq true}<b style="background-color:#ffae5b"><i> then=”Cancelled” </i></b>}

5. ここで［Run］をクリックすると、「Cancelled」を「Status」列にマッピングできます。ただし、true以外の場合については「Status」の値が「null」値になります。

6. 最後に必要な作業は、「Status」列の値が「Cancelled」ではない場合に、元の値を維持するようCanvasに指示することです。

| mapColumn Status fn={if {getCell “Cancelled” | eq true} then=”Cancelled”<b style="background-color:#ffae5b"><i> else={getCell "Status"}</i></b>}

7. ［Run］をクリックします
8. これで、「Status」列を「Cancelled」列と組み合わせることができました。

列の削除

これで「Status」列に、必要な情報をすべて含めることができたので、「Cancelled」列を表示する必要がなくなりました（背後では機能している必要があります）。そのため、「Cancelled」列を削除します。

1. データ表要素が選択されていること、および式エディターが開いていることを確認します
2. Canvasには、列を含めるまたは除外するのに使用する「columns」という関数があります。ここでは「Cancelled」列を除外します。次のとおり、コードを1行追加します。

...
| mapColumn Status fn={if {getCell “Cancelled” | eq true} then=”Cancelled” else={getCell “Status”}}
<b style="background-color:#ffae5b"><i>| column exclude=”Cancelled”</i></b>
| table
...

3. ［Run］をクリックします
4. 背後ではその列のデータを使用していますが、データ表要素に「Cancelled」列が表示されなくなっているはずです。

カスタマイズ

これで望むとおりのデータがすべて揃いました。次は、workpadの表示の見た目をカスタマイズしてみましょう。

背景色の設定

1. workpadで色が何も選択されていないことを確認します
2. ページ右側の編集パネルで［Page Background］カラーピッカーをクリックし、値を「#0276fd」に設定します

ページネーションの削除

1. データ表要素を選択します
2. ページの右側の編集パネルで、［Display］タブを選択します
3. ［Table Style］パネルの［+］ボタンをクリックします
4. ドロップダウンから［Pagination］を選択します
5. 切り替えボタンをクリックしてオフにします

表の行数の設定

1. 再度、［Table Style］パネルの［+］ボタンをクリックします
2. ドロップダウンから［Rows per page］を選択します
3. ページごとの行数を25に増やします
4. 実際には18行にするので、データ表要素の式エディターを開き、「perPage」の値を18に変更します

| table paginate=false perPage=<b style="background-color:#ffae5b"><i>18</i></b>

5. ［Run］をクリックします
6. 18行すべてが表示されるようにデータ表要素を広げます

表テキストのスタイル設定

1. 再度、［Table Style］パネルの［+］ボタンをクリックします
2. 今回は［Text Settings］を選択します
3. テキストを太字に、色をホワイトに設定します

表ヘッダーのスタイル設定

1. 表の他の行よりも目立つように、表のヘッダーのスタイルを設定します。すでに［Table Style］パネルでできることは見てきたので、ここではカスタムCSSを使います
2. そのためには、［Element Style］パネルの［+］ボタンをクリックします
3. ドロップダウンメニューから［CSS］を選択します
4. CSSエディターの内容を消去し、次のコードをCSSエディターにペーストします

canvasDataTable__th { text-decoration: underline; background-color: #d0e9ff; color: black;}

5. ［Apply stylesheet］をクリックします
6. これで表のヘッダーには、薄いブルーの背景色とブラックの下線が引かれたテキストが表示されるはずです

表の行のスタイル設定

1. 表の行の色が交互になるよう設定するために、ここでもカスタムCSSを使用します
2. 次のコードをCSSエディターにペーストします

.canvasDataTable__tbody>:nth-child(even) {
background-color: #2a2a50;
}

.canvasDataTable__tbody>:nth-child(odd) {
background-color: #5f67af;
}

3. ［Apply stylesheet］をクリックします
4. workpadの幅に合うようにデータ表要素の幅を調整します
5. 下図のように、行の色が交互になるように表示されるはずです

タイトルの追加

1. ［Add element］をクリックします
2. ［Markdown］要素を選択します
3. 画面右側の［Markdown content］エディターにあるすべてのテキストを削除します
4. ［Markdown content］エディターに「Departures」と入力します
5. ［Apply］をクリックします
6. ［Markdown］要素のサイズを調整し、画面の中央に揃えます
7. 右側の編集エリアにある ［Markdown］パネルで、［+］ボタンをクリックします
8. ドロップダウンメニューから［Text Settings］を選択します
9. テキストを次のとおりに設定します
1. サイズ：48
2. フォント：太字
3. アラインメント：中央揃え
4. 色：ホワイト
10. これで、実際に空港で見るものによく似たworkpadが完成したはずです。

完成したコード

下記は、式エディターでのデータ表の完全なコードです。

filters
| essql
  query="SELECT
  DestCityName AS Destination,
  timestamp AS Time,
  Carrier AS Airline,
  FlightNum AS Flight,
  FlightNum AS Gate,
  FlightDelayType AS Status,
  Cancelled
FROM
  kibana_sample_data_flights
"
| mapColumn "Time" fn={date | formatdate "hh:mm A"}
| mapColumn "Gate" fn={math "round(random(1,100),0)"}
| mapColumn "Status" fn={if {getCell "Cancelled" | eq true} then="Cancelled" else={getCell "Status"}}
| columns exclude="Cancelled"
| table paginate=false perPage=18
 font={font family="'Open Sans', Helvetica, Arial, sans-serif" size=14 align="left" color="#FFFFFF" weight="bold" underline=false italic=false}
| render
 css=".canvasDataTable__th { text-decoration: underline; background-color: #d0e9ff; color: black;}
.canvasDataTable__tbody>:nth-child(even) {
background-color: #2a2a50;
}
.canvasDataTable__tbody>:nth-child(odd) {
background-color: #5f67af;
}"

その他の便利なリソースリンク

お疲れ様でした。Canvasのデータ表要素およデバッグ要素を使用する例をいくつか見てきました。ぜひ他の要素もworkpadに追加して、Canvasのフル機能をお試しください。

Canvasのブログ記事はこの他にもあります。ぜひご活用ください。

• KibanaでCanvasを使いはじめる
• メトリック要素とマークダウン要素

バナー画像：MPD01605による「Miami Airport Screen」はCC BY 2.0 によって許可を得ています。

検索順位を決める要素

Elasticsearchは、スケーラブルで高速なリアルタイムの検索・分析エンジンです。文字列、数値、日時、地理情報など、指定された条件にしたがってインデックスされたドキュメントを検索し、一致するものを利用者に返します。数値、日時、地理情報であれば、「価格が1000円」以上、「今週入荷した商品」、「東京都庁から100km以内」などといった条件をもとに検索ができ、条件に一致するドキュメントのスコアは全て同一です。文字列を条件に指定した場合には、検索対象の文字列の長さや、条件に一致した句の数や頻度などに応じて、それぞれのドキュメントのスコアは異なり、順位付けがなされます。

ただ、検索機能をアプリケーションに実装する場合、検索順位を制御したい場合が多々あります。「1000円以上の商品を安い順」「今週入荷した商品を新しい順」「東京都庁から近い順」に並べるといった場合です。それらのうち、複数の条件を組み合わせたい場合もあるでしょう。Elasticsearchを使用して、どのように実装したら良いでしょうか。

フルーツのオンラインショッピングサイトを想定し、以下のような商品テーブルを用意します。

POST items/doc/_bulk
{"index":{}}
{"arrival_date":"2018-12-02","name":"Tsugaru Apple","origin":{"prefecture":"Aomori","location":"40.82,140.73"},"price":310,"promotion":2}
{"index":{}}
{"arrival_date":"2018-11-29","name":"Shinano Apple","origin":{"prefecture":"Nagano","location":"36.65,138.17"},"price":280,"promotion":10}
{"index":{}}
{"arrival_date":"2018-12-04","name":"Fuji Apple","origin":{"prefecture":"Akita","location":"39.69,139.78"},"price":150,"promotion":1}
{"index":{}}
{"arrival_date":"2018-12-04","name":"Mikkabi Mandarine Orange","origin":{"prefecture":"Shizuoka","location":"34.97,138.38"},"price":80,"promotion":1}

商品の「入荷日（arrival_date ）」、「商品名（name）」、「生産地（origin.location）」、「価格（price）」、「販促度（promotion）」フィールドを用意しました。利用者は「商品名」のみで検索しますが、「入荷日」が新しいもの、フラッシュセール用の「販促度」が高いものが、より上位に表示されるように試みてみます。

注意：本項に使用しているインデックスやクエリはこちらで入手できます。予期した通り動作させるためには、適切に「入荷日（arrival_date ）」などを調整する必要があります。クエリのnowを2018-12-06とすることもできます。

好ましくない方法 - スクリプトスコア(Script Score)

まずはじめに思いつくのは、ユーザが検索したキーワードに該当するドキュメントから、「入荷日（arrival_date）」と「販促度（promotion）」を要素としてスクリプトにより点数付けし、各ドキュメントのスコアを上書きするものです。これは、Function Scoreクエリの、Script Scoreを用いて実現できます。

アプリケーションは、Elasticsearchに以下のようなクエリをリクエストすることができます。

GET items/_search
{
  "query": {
    "function_score": {
      "score_mode": "sum",
      "query": {
        "match": {
          "name": "apple"
        }
      },
      "script_score": {
        "script": "doc['promotion'].value - (new Date().getTime() - doc['arrival_date'].value.toInstant().toEpochMilli()) / 1000000 / 60"
      }
    }
  }
}

script_scoreで、「入荷日（arrival_date）」から現在の経過日数を求め、「販促度（promotion）」から引いています。「販促度（promotion）」が高く、より新鮮な商品が上位に表示されることになります。

実際に多くElasticsearchユーザーが、このような方法を用いています。では、なぜ好ましくないのでしょうか。それは、Elasticsearchはスクリプトを実行するために、マッチクエリーで一致したドキュメント全ての、「入荷日（arrival_date）」フィールドと、「販促度（promotion）」にアクセスし、それぞれのドキュメントでスクリプトを用いて計算を行い、求められた値にしたがって検索順位を並べ替える必要があるからです。プロファイルAPIを用いて観察してみると、scoreに多くの時間（本例では267,863ナノ秒）が割かれていることがわかります。

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 3,
    "max_score" : 2.0,
    "hits" : [
      {
        "_index" : "items",
        "_type" : "doc",
        "_id" : "2",
        "_score" : 2.0,
        "_source" : {
          "arrival_date" : "2018-11-29",
          "name" : "Shinano Apple",
          "origin" : {
            "prefecture" : "Nagano",
            "location" : "36.65,138.17"
          },
          "price" : 280,
          "promotion" : 10
        }
      },
      {
        "_index" : "items",
        "_type" : "doc",
        "_id" : "3",
        "_score" : 0.0,
        "_source" : {
          "arrival_date" : "2018-12-04",
          "name" : "Fuji Apple",
          "origin" : {
            "prefecture" : "Akita",
            "location" : "39.69,139.78"
          },
          "price" : 150,
          "promotion" : 1
        }
      },
      {
        "_index" : "items",
        "_type" : "doc",
        "_id" : "1",
        "_score" : -2.0,
        "_source" : {
          "arrival_date" : "2018-12-02",
          "name" : "Tsugaru Apple",
          "origin" : {
            "prefecture" : "Aomori",
            "location" : "40.82,140.73"
          },
          "price" : 310,
          "promotion" : 2
        }
      }
    ]
  },
  "profile" : {
    "shards" : [
      {
        "id" : "[3AvCgesDSpqiSKQR2y_qPA][items][0]",
        "searches" : [
          {
            "query" : [
              {
                "type" : "FunctionScoreQuery",
                "description" : "function score (name:apple, functions: [{scriptScript{type=inline, lang='painless', idOrCode='doc['promotion'].value - (new Date().getTime() - doc['arrival_date'].value.toInstant().toEpochMilli()) / 1000000 / 60', options={}, params={}}}])",
                "time_in_nanos" : 366579,
                "breakdown" : {
                  "score" : 267863,
                  "build_scorer_count" : 7,
                  "match_count" : 0,
                  "create_weight" : 4120,
                  "next_doc" : 16184,
                  "match" : 0,
                  "create_weight_count" : 1,
                  "next_doc_count" : 6,
                  "score_count" : 3,
                  "build_scorer" : 78395,
                  "advance" : 0,
                  "advance_count" : 0
                }
              }
            ],
            "rewrite_time" : 3536,
            "collector" : [
              {
                "name" : "CancellableCollector",
                "reason" : "search_cancelled",
                "time_in_nanos" : 286452,
                "children" : [
                  {
                    "name" : "SimpleTopScoreDocCollector",
                    "reason" : "search_top_hits",
                    "time_in_nanos" : 275455
                  }
                ]
              }
            ]
          }
        ],
        "aggregations" : [ ]
      }
    ]
  }
}

減衰（Decay）関数を検討する

Function Scoreクエリでは、指定した値から遠ざかるほどスコアが下がる、Decay Functionを利用できます。指定した原点から遠ざかるほど、検索スコアが下がり、複数の条件を指定したり、減衰度を調整することができます。以下のようなクエリで実現することができます。

GET items/_search
{
  "query": {
    "function_score": {
      "score_mode": "sum",
      "query": {
        "match": {
          "name": "apple"
        }
      },
      "functions": [
        {
          "linear": {
            "arrival_date": {
              "origin": "now",
              "scale": "7d",
              "offset": "0d"
            }
          }
        },
        {
          "linear": {
            "promotion": {
              "origin": "10",
              "scale": "10",
              "offset": "0"
            }
          }
        }
      ]
    }
  }
}

まず、「商品名（name）」にappleが含まれるものを検索します。さらに「入荷日（arrival_date）」が現在より遠ざかるほど、直線的（Linear）にスコアが下がります。そして同様に、「販促度（promotion）」が10から遠ざかるに連れて、スコアが下がり、これら3つのスコアを足した（sum）ものをスコアとします。スコア自身はscript_scoreとは異なりますので、検索の順位は異なる可能性がありますが、「入荷日」が新しいもの、フラッシュセール用の「販促度」が高いものを上位にするという要件を満たせることがわかります。

さらに、プロファイルAPIを使用すると、より少ないコスト（計算時間）のscoreで（本例では24,824ナノ秒）、レスポンスが得られることが確認できます。

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 3,
    "max_score" : 0.58585125,
    "hits" : [
      {
        "_index" : "items",
        "_type" : "doc",
        "_id" : "2",
        "_score" : 0.58585125,
        "_source" : {
          "arrival_date" : "2018-11-29",
          "name" : "Shinano Apple",
          "origin" : {
            "prefecture" : "Nagano",
            "location" : "36.65,138.17"
          },
          "price" : 280,
          "promotion" : 10
        }
      },
      {
        "_index" : "items",
        "_type" : "doc",
        "_id" : "3",
        "_score" : 0.5511543,
        "_source" : {
          "arrival_date" : "2018-12-04",
          "name" : "Fuji Apple",
          "origin" : {
            "prefecture" : "Akita",
            "location" : "39.69,139.78"
          },
          "price" : 150,
          "promotion" : 1
        }
      },
      {
        "_index" : "items",
        "_type" : "doc",
        "_id" : "1",
        "_score" : 0.5164573,
        "_source" : {
          "arrival_date" : "2018-12-02",
          "name" : "Tsugaru Apple",
          "origin" : {
            "prefecture" : "Aomori",
            "location" : "40.82,140.73"
          },
          "price" : 310,
          "promotion" : 2
        }
      }
    ]
  },
  "profile" : {
    "shards" : [
      {
        "id" : "[3AvCgesDSpqiSKQR2y_qPA][items][0]",
        "searches" : [
          {
            "query" : [
              {
                "type" : "FunctionScoreQuery",
                "description" : "function score (name:apple, functions: [{org.elasticsearch.index.query.functionscore.DecayFunctionBuilder$NumericFieldDataScoreFunction@84ef9e63}{org.elasticsearch.index.query.functionscore.DecayFunctionBuilder$NumericFieldDataScoreFunction@7ed62d90}])",
                "time_in_nanos" : 148424,
                "breakdown" : {
                  "score" : 24824,
                  "build_scorer_count" : 7,
                  "match_count" : 0,
                  "create_weight" : 55157,
                  "next_doc" : 2485,
                  "match" : 0,
                  "create_weight_count" : 1,
                  "next_doc_count" : 6,
                  "score_count" : 3,
                  "build_scorer" : 65941,
                  "advance" : 0,
                  "advance_count" : 0
                }
              }
            ],
            "rewrite_time" : 3466,
            "collector" : [
              {
                "name" : "CancellableCollector",
                "reason" : "search_cancelled",
                "time_in_nanos" : 37957,
                "children" : [
                  {
                    "name" : "SimpleTopScoreDocCollector",
                    "reason" : "search_top_hits",
                    "time_in_nanos" : 30003
                  }
                ]
              }
            ]
          }
        ],
        "aggregations" : [ ]
      }
    ]
  }
}

減衰（Decay）関数を地理情報に応用する

減衰（Decay）ファンクションが適用可能なのは、数値や日付時刻だけに限らず、地理情報にも適用できます。ある地点から遠ざかるほどスコアが下がるという検索は、タクシーの配車やイベントのチケット販売、デーティングアプリケーションなど、様々なケースで容易に応用できます。フルーツのオンラインショッピングサイトにおいて、生産者直送の地産地消を推進するのであれば、以下のようなクエリで、購入者から地理的に近い商品を勧めることもできます。

GET items/_search
{
  "query": {
    "function_score": {
      "score_mode": "sum",
      "query": {
        "match": {
          "name": "apple"
        }
      },
      "linear": {
        "origin.location": {
          "origin": "35.68,139.69",
          "offset": "0",
          "scale": "300km"
        }
      }
    }
  }
}

まとめ

検索順位を柔軟に、かつ自在に制御するヒントは得られましたでしょうか。パフォーマンスの観点からは、なるべくスクリプトによるスコア計算は、避けることが望ましいですし、Elasticsearchが提供している減衰（Decay）ファンクションは、より低コストで検索順位を制御できる機会を提供しますので、第一の候補として検討してください。

また、アプリケーション検索に特化した当社のサービスである、Elastic App Searchを用いると、GUIを用いて関連性をチューニングすることができます。条件に応じた検索結果をその場でリアルタイムに確認できたり、アプリケーション開発者の手を煩わせることなく検索順位を制御することができます。この他にも便利なAPIや検索UIのリファレンスなども提供していますので、アプリケーション開発の工数を著しく削減します。ぜひお試しください。

Crimson Macawは英国を拠点とするコンサルティング企業です。本記事は、マンチェスター・エアポート・グループ向けに実施したプロジェクト事例をご紹介します。このプロジェクトはロンドン・スタンステッド空港のセキュリティオペレーション向けにリアルタイムダッシュボードを実装するというものでした。

ダッシュボードの目的は、乗客のフローとセキュリティパフォーマンスを制御室とセキュリティスタッフによりわかりやすく表示し、リアルタイムデータに基づいてすばやく判断を下せるようにすることです。そのため、複数のオンプレミスシステムと外部データソースからデータを投入し、いくつもの巨大なスクリーンに可視化して表示する必要がありました。

データ投入の課題

データのストレージレイヤーにElasticsearchを導入すると決まった後は、どのデータを、どのように投入するか決定する必要があります。この事例では、利用できる情報のソースが多岐にわたっていました。オンプレミスのデータベースシステムとAmazon S3バケットに頻繁に投入されるファイル、さらに外部のAPIデータソースがあります。一例が、英国の鉄道運行企業ナショナル・レールのデータです。このケースでは、STOMP（Streaming Text Oriented Messaging Protocol）インターフェイスを使用してデータをElasticsearchに読み込ませています。

そこには初期の段階で解決しなければならない課題がありました。

• データベースから取得するデータのを毎分1回以上の頻度でポーリングする必要がある
• STOMPから来るデータはgzipで圧縮されている

データベースを毎分1回以上の頻度でポーリングする

1つ目の課題は、既存のlogstash-input-jdbcプラグインに簡単なパッチをあてて解決することができました。パッチを作成するまで、スケジュールはcron形式でしか表現できませんでした。パッチにはrufus-schedulerという名称で知られるJob Schedulerを使用しました。Job Schedulerは供給スケジュールをcronと秒数のどちらでも表現できます。唯一の変更はcronに代わって反復メソッドを使用するための1行のコードです。

これを活用するためのパッチはGitHubで公開されています。

gzipで圧縮されたメッセージを処理する

STOMPインターフェースから来る圧縮済みメッセージを扱うには、データを解凍し、Logstashでデータをフィルターする必要があります。gzipで圧縮されたメッセージからデータ行を読み取る既存のcodecも存在しますが、このケースではgzipを解凍したメッセージが複数行のXMLとなります。これを克服するため、私たち実装チームは独自のプラグイン — logstash-codec-gzip — を作成しました。こちらもGitHubで公開されています。

Canvasを使用してデータを可視化する

チームはElastic Cloud上にあるマネージドのElasticsearchにあるデータをKibanaで可視化してみました。ところが、思うような表示になりません。より細やかなレベルでの制御が必要だろうと考えていた2018年5月、私たちはマンチェスター・エアポート・グループのBI責任者と共にロンドンで開催されたAWSサミットを訪れ、そこでCanvasの存在を知りました。Elasticの担当者によれば、Canvasは私たちが望んでいる表示により適しているという話でした。

「データをKibanaで可視化するのに、ローレベルで必要な制御がないので困っています」
「Canvasのことはご存知ですか？」
「いいえ」
「新しい可視化ツールです。今はテクニカルプレビューの段階ですが、そのケースに最適だと思いますよ」

Canvasのインストールとファーストインプレッション

CanvasはKibanaのプラグインとして利用でき、他のKibanaプラグインと同様にインストールできました。当時テクノロジープレビューだったCanvasはElastic Cloudでは利用できませんでした。私たちはTerraformを使用し、完全にスクリプト化してマンチェスター・エアポート・グループが使用するAWSにKibanaをホストさせました。

Canvasはシンプルな表現言語をもち、各要素の可視化方法を制御することができます。それは、1つのコマンドが次にパイプされ、部分式が括弧内の式で宣言されるような形で実行されるshellプログラミングに似ています。

何日か触ってCanvasに慣れたところで、私たちはスタンステッド空港に到着する列車の時刻を可視化することができました。このダッシュボードは、テキスト部分にマークダウン要素を、フッターのアイコンと画像にImage Repeatを使用して作成しています。

見栄えもよく、個々の要素も制御することができましたが、1つだけまだ足りない点がありました。このユースケースでは、より細かな制御が必要なのです。

• タイムゾーンに基づいてタイムスタンプをフォーマットする（データはUTCで格納されているが、夏時間に合わせる必要があるため）
• 既知のしきい値に基づいてテキストや画像の色を変更する

Canvasを拡張する

Canvas向けにプラグインを記述する方法は、Kibana向けプラグインの場合にかなり似ています。プラグインはNode.jsで記述されており、使用するレジストリに機能や新しい要素を追加して、Canvas UI内で選択することもできます。このケースでは、必要な制御水準を達成するため3つのプラグインを作成しました。

タイムスタンプのフォーマットにタイムゾーンを使用する

最初に作成したプラグインは、内蔵のformatdateを簡単に拡張したものです。

import moment from 'moment';
import 'moment-timezone/builds/moment-timezone-with-data';
export const formatdatetz = () => ({
  name: 'formatdatetz',
  type: 'string',
  help:'Output a ms since epoch number as a formatted string according to a given timezone',
  context: {
    types: ['number'],
  },
  args: {
    _: {
      types: ['string'],
      help:'MomentJS Format with which to bucket (See https://momentjs.com/docs/#/displaying/)',
      required: true
    },
    timezone: {
      types: ['string'],
      help:'The timezone',
      required: true,
      default:'UTC'
    }
  },
  fn: (context, args) => {
    if (!args._) return moment.utc(new Date(context)).tz(args.timezone).toISOString();
    return moment.utc(new Date(context)).tz(args.timezone).format(args._);
  },
});

このformatdatetz pluginはCanvasにインストールして使用するもので、GitHubで公開されています。インストールも簡単です：

./bin/kibana-plugin install https://github.com/crimsonmacaw/nodejs-canvas-plugin-formatdatetz/releases/download/v1.0.2/canvas-plugin-formatdatetz-1.0.2.zip

テキストと画像の色を制御する

このケースで、テキストと画像の色を制御にマークダウンを使用することはできませんでした（Canvas内にCSSを提供することはできますが、マークダウン構文はどのスタイルを適用するかについてHTMLクラス属性設定をサポートしていません）。

最もシンプルなアプローチは、HTMLで直接コーディングできて、マークダウン要素にも同様の方法を使用でき、ハンドルバー表現のデータバインディングができるプラグインを作成することでした。SVG画像は直接HTMLに埋め込むことができます。実装チームは同じレベルの制御を適用し、Elasticsearchから取得したデータに基づいて動的に画像を変更することができるようになりました。

可視化を作成する

必要なプラグインを作成すると細かな制御が可能になり、表の中で行ごとに色を変えるといったこともできるようになりました。

複数のデータを1つの画面に可視化できており、あとはプレースホルダにデータを入れるだけですが、何かしっくりこない感じがします。そしてこんなリクエストが届きました。

「もう少しおしゃれにできますか？」

即座にインターネットにインスピレーションを求めに行きました。"かっこいい"、"ダッシュボード"というキーワードでPinterestやDribbbleといったプラットフォームを検索したところ、良さそうなダッシュボードデザインのアプローチが見つかりました。そして方向性を修正した結果…

画面に多数の要素が追加されています。シンプルなHTMLと複雑なSVG画像を組み合わせて作成したプラグインが広い範囲で使われ、要素を動的に生成しています。

フィードバックはポジティブでした。しかし設計に参加しなかったユーザーは、ダッシュボードを見ただけでは各メトリックの意味がわかりませんでした。

「いい感じですね！でもこの棒グラフはどういう意味ですか？」

"空港セキュリティの現場ですばやく判断を下せるようにする"、という原点に立ち帰ってみると、デザインを美しくすることが情報を可視化する最適な方法であるとは限りません。何も説明がなくても、何が表示されているか瞬時にわかるようなダッシュボードにする必要があるのです。

インタラクティブなアプローチ

Canvasには豊かな表現言語が備わっています。私たちは関係者とダッシュボードのライブ編集について複数回のワークショップを開催し、方向性を探りました。こうしてCanvasついて説明する前や、以前使われていたレポートをベースにしたワイヤフレームから大きく前進し、ダッシュボードに最適に情報を表示するにあたり、新しい発想によるアプローチが見つかりました。ダッシュボードの最新バージョンをエンドユーザーに見せ、フィードバックをもらって修正する、という作業を続けました。

最終版のダッシュボード

関係者が力を合わせ、クリエイティブシンキングを実践して完成したダッシュボードが下の画像です。

「Crimson MacawがElasticsearchとCanvasを使って制作したスタンステッド空港のダッシュボードは、以前は別々のシステムに入っていたデータをリアルタイムに、モダンに一括表示してくれます。現場のプロセスは、かつては不可能だと思われた部分で大幅に効率化されました」– マンチェスター・エアポート・グループ、BI & Analytics責任者、スチュアート・ヒューストン

ダッシュボードはプレゼンテーション用にランダムなデータを表示しています。データのランダム化にあたり、Canvas向けのrandomise plugin（ランダム化プラグイン）を作成、使用しています。

セキュリティハブ

このダッシュボードは空港セキュリティを出入りする人の数が基準を満たしているかや、個々のレーンの情報など、空港セキュリティの現在の状況を示します。セキュリティレーンを示す図形は空港セキュリティの実際のレイアウトに基づいており、オペレーションスタッフはこのダッシュボードを見て実際のレーンをすぐに理解することができます。

セキュリティポッド

このダッシュボードはトレンド（傾向）情報を表示します。空港のさまざまなエリアで、事前に予測した搭乗者数と待ち時間に対し、実際にセキュリティエリアに進む人の数をプロットしています。

出発便情報

一般的なFIDS（フライト情報表示画面）によく似ていますが、今後のフライトについて事前予測された搭乗者数に対し、空港セキュリティに入場した人の数を比較した情報を追加表示しています。

到着列車情報

スタンステッド空港を利用する搭乗客の多くが電車を利用しており、電車の遅延は空港セキュリティに流入する人の数にも大きな影響を及ぼします。1本の列車が数百人の搭乗客を乗せており、一時的な運転見合わせや遅延の解消後には複数本の列車が一気に到着することもあります。

このためダッシュボードには通常の列車運行情報に加え、タイムラインで列車の到着時刻を表示しています。Canvasでの表現を手探りしていた最初のダッシュボードに比べると、大きく進歩していることがお分かりいただけると思います。

まとめ

Canvasはデータをリアルタイムに、美しく可視化する優れたツールです。（本稿執筆時点で）Canvasはベータであり、今後もいくつかの機能が追加される予定ですが、中核となる機能性をプラグインで拡張できる点はElasticプロダクトがソフトウェアに対してとるアプローチと共通しています（注：本稿はCanvasの一般公開前に執筆されました）。

多くのBIツールはグラフや表機能に限られ、ゲージやその他の可視化はまだあまりありません。さらにCanvasのダッシュボード作成手順はシンプルです。つまりデータエンジニアやデータ可視化スペシャリストのイマジネーションが及ぶ限り、自由にダッシュボードを作成することが可能です。

ロバート・ブルース | 英国マンチェスターを拠点とするクラウド/データITコンサルティング企業Crimson Macawの創業パートナー、エンジニアリングディレクター。データエンジニアリングとWeb業界で20年以上の経験を持ち、現在はクラウドテクノロジー分野を強みとする。

APM（アプリケーションパフォーマンス監視）とは？

APMについて説明する場合、ログやインフラメトリックの"監視性"など、別の側面も考えるとよりわかりやすくなります。ログとAPM、インフラメトリックは監視の3大要素です。

3つの領域には重なり合う部分もあり、相互に関連付ける際に役立ちます。ログは、エラーが生じた痕跡を示すかもしれませんが、エラーの理由までは示しません。メトリックはサーバー上でCPU使用量にスパイクがあったことを示すかもしれませんが、何が原因だったかは示しません。しかし、うまく組み合わせて活用すれば、はるかに広い範囲の問題を解決できる可能性があります。

ログ

はじめにいくつかの定義について考えておきましょう。ログとメトリックには、わずかな違いがあります。通常、ログは何かが生じたときに発信されるイベントです。あるリクエストが受信されたとか、反応があったとか、ファイルを開いた、コードでprintfが生じた... といった出来事です。

たとえば、Apache HTTPサーバーのプロジェクトからくるよくあるログ形式はこんな感じです（フェイクデータ、短縮のため一部省略）。

264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "GET /ESProductDetailView HTTP/1.1" 200 6291
264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "POST /intro.m4v HTTP/1.1" 404 7352
264.242.88.10 - - [22/Jan/2018:16:38:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253

ログの情報は、アプリケーションの全体を把握するというより、コンポーネントレベルにとどまる傾向にあります。しかし人間が読む上では便利です。上の例では、IPアドレスと、明らかに設定のないフィールド、日付、ユーザーがアクセスしていたページ（とその方法）、いくつかの数字を確認することができます。私の経験から、一連の数字がレスポンスコード（200はよい、404は良くないが、500よりはマシ）であることと、データが返された量であることがわかります。

ログは通常、対応するアプリケーションやサービスが実行されているホスト/マシン/コンテナーインスタンス上で使用でき、この例のように人間が読める情報であるため、"便利"です。一方でログには、「コードを書いておかなければ、プリントされない」という本質的なデメリットもあります。Rubyでputsを使うか、Javaでsystem.out.printlnするか、あるいは類似の作業が必須です。またプリントする場合も、フォーマットが重要です。前出のApacheログに、見慣れない日付フォーマットが含まれています。たとえば"01/02/2019"という日付を考えてみましょう。米国に住む私にとっては2019年1月2日という意味ですが、世界の多くの仲間はこの日付を2019年2月1日と読みます。ロギングでstatementの形式を決定する際は、こうした点も考慮されることをお勧めします。

メトリック

一方、メトリックは周期的なサマリーやカウントの情報が主です。たとえばこの10秒間に、平均CPUは12％で、アプリケーションが使用したメモリ量は27MB、であるとか、プライマリディスクの容量は71％、といったことです（いま筆者のマシンのメトリックを確認してみました）。

上のスクリーンショットは、あるMacで実行されているiostatです。多くのメトリックがあることがわかります。メトリックは傾向や履歴を示したいときに便利であり、シンプルで予測可能、また信頼できるルールを作成してインシデントや異常を捉える場合に特に役立ちます。メトリックのデメリットとして、インフラレイヤーの監視や、コンポーネントインスタンスレベル（ホスト、コンテナー、ネットワークなど）のデータ捕捉が中心で、カスタムアプリケーションレベルのデータをあまり扱わない点があります。というのも、メトリックは一定の経過時間に対してサンプルされるため、わずかな外れ値が"平均化"されるリスクを伴うためです。

APM

メトリックとログのギャップに橋を架ける存在がアプリケーションパフォーマンス監視です。ログやメトリックは、インフラや複数のコンポーネントを扱う横断的なデータです。APMは特にアプリケーションに注目し、エンドユーザーエクスペリエンスを含むスタック中のアプリ層を、IT部門や開発者が監視できるようサポートします。

監視にAPMを追加するメリットとして、次のような点があります。

• サービス提供にかかる時間と、クラッシュの原因を把握できる
• サービスと他の要素の通信状況や、ボトルネックを可視化できる
• パフォーマンスのボトルネックやエラーの予防的な発見・修正に役立つ
  • 最良のシナリオは、多数のエンドユーザーが影響を受ける前の発見・修正
• 開発チームの生産性向上をサポート
• ブラウザー上でエンドユーザーエクスペリエンスを追跡可能

特に注目したいのが、"APMにはコードが通じる"という点です（この後詳しく取り上げます）。

ログとAPMで、得られる情報を比較してみましょう。先ほどこのようなログエントリがありました：

264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "GET /ESProductDetailView HTTP/1.1" 200 6291

先ほど見た通り、よい内容になっています。レスポンスに成功しており（200）、6,291バイトを返しました。しかし、レスポンスに16.6秒かかったことは示されていません。これは次のAPMスクリーンショットに表示されています。

その他にも豊富なコンテクストが見て取れます。最初のログには、このようなエラーもありました：

264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253

APMが捉えた内容はこうなります：

最終発生日時、発生頻度、アプリケーションで処理されたか否か、という情報が表示されています。たとえばNumberParseExceptionを使って例外処理の詳細を見ると、エラーが発生した回数の分布がウインドウで視覚的に表示されます。

パッと見て、一定の時間に数回起きているということ、一日中発生していることがわかります。ログで見ても、ログファイルの1つに対応するスタックの痕跡が見つかるはずです。しかしAPMのように、そのコンテクストやメタデータまで見つかる可能性は高くありません。

赤い長方形の部分はこの例外処理を実施したコード行を示し、APMが提供するメタデータが問題の正確な内容を伝えています。pythonプログラマーでない筆者のような人間が見てもどういう問題であるか正確に理解でき、チケットをオープンするために必要十分な情報があります。

スクリーンショットで見るAPMオプションツアー

Elastic APMについて一日中語ることもできる筆者ですが（よかったらTwitterで検索してください）、ここではスクリーンショットを使って、もう少し視覚的にご紹介したいと思います。早速ツアーをはじめましょう。

APMを開く

KibanaでAPMアプリケーションを開くと、Elastic APMに搭載されているすべてのサービスが表示されます：

サービスの詳細を見る

個々のサービスについて詳細を見ることができます。今回は"petclinic-spring"サービスを見てみましょう。各サービスとも、レイアウトは似ています：

左上にレスポンスタイムがあります。平均、95パーセンタイル、99パーセンタイルがあり、外れ値の部分を表示しています。さまざまな線グラフのエレメントを表示／非表示にして、外れ値がチャート全体に与える影響をわかりやすくすることもできます。右上はレスポンスコードです。時間に対してRPM（requests per minute／1分あたりリクエスト数）を詳しく表示しています。実際の画面では、各チャートの上でマウスを動かすとポップアップが現れ、特定の時間のサマリーを表示します。最初に得られるインサイトは、データを深堀りせずともすぐにわかります。すなわち、レイテンシの大きなスパイクに、"500"のレスポンス（サーバーエラー）がまったくありません。

トランザクションレスポンスタイムを詳しく見る

引き続きトランザクションサマリーを見ると、下の方にリクエストの詳細があります。各リクエストは、基本的には（さまざまなエージェントAPIを使用して初期設定を拡張可能できる）アプリケーション中の異なるエンドポイントです。リクエストは列見出しで並べ替えできますが、筆者が個人的に好んで使うのは"impact"列です。これは、そのリクエストのレイテンシと出現度を考慮します。今回の事例では、"getOwners"が最も問題を生じさせているように見えますが、それでも平均レイテンシは96ミリ秒に留まっています。このトランザクションを詳細にドロップダウンしていくと、先ほどと同じレイアウトが表示されます。

"ウォーターフォール作戦"

さて、最も遅いリクエストでも、1秒未満にレスポンスしていることがわかりました。下に向かってスクロールしてゆくと、トランザクション中のオペレーションが滝のように表示されています。

クエリ詳細表示

見ると確かに、大量のSELECT文があります。APMでは実行された実際のクエリを表示させることができます。

分散トレーシング

このアプリケーションスタックは、多層化されたマイクロサービスアーキテクチャーを扱っています。すべての層にElastic APMを組み込んであるため、[View full trace]ボタンを押してこのコールに関与する全要素が入るまでズームアウトすることが可能です。こうして、トランザクションに参加したすべてのコンポーネントの分散トレーシングを表示します：

多層的にトレーシングする

今回の事例で最初に見たのは、他の層がコールする"Spring"という層でした。いまこの画面で、"petclinic-node"が"petclinic-spring"層をコールしたことがわかります。これは2つの層でしたが、ブラウザー（React）層からはじまるより多層的な例もあります。

リアルユーザー監視

分散トレーシングの力を最大に引き出すためには、リアルユーザー監視（RUM）も含めて、できる限り多くのコンポーネントやサービスを組み込むことが重要です。サービスレスポンスタイムの早さが、必ずしもブラウザーでのすばやい動作を意味するわけではありません。つまり、ブラウザー上でのエンドユーザーエクスペリエンスを測定することこそが重要です。この事例で、分散トレーシングは4つの異なるサービスが同時に実行されていることを示しています。複数あるサービスの1つが、Webブラウザー（クライアント）です。53ミリ秒の時点でdomはインタラクティブでした。67ミリ秒では、domが完了していることがわかります。

UIにとどまらない魅力

Elastic APMは使いやすいAPM UIに加え、アプリ開発者に必要な機能を豊富にそろえています。そして、追跡データをUIで表示できるだけでなく、一歩深く活用できます。実は、Elastic APMデータは1つのインデックスとなっています。ログやメトリックから、事業データまでの情報が揃うことにより、サーバー遅延が収益に及ぼした影響を把握することも、影響の大きいリクエストを調べるなどして、次のコード拡張の計画策定にAPMデータを役立てることも可能です。

APMはデフォルトの可視化とダッシュボード機能を搭載しており、ログとメトリック、さらに事業データを組み合わせて可視化することができます。

Elastic APMを使いはじめる

Elastic APMは、LogstashやBeatsと似たデプロイトポロジーを使い、組み合わせて実行することができます：

APMサーバーはデータプロセッサーとして振る舞い、APMデータをAPMエージェントからElasticsearchに転送します。インストール手順もシンプルです。ドキュメントの"install and run"ページを参照いただくか、Kibanaで"K"ロゴをクリックしてホーム画面を表示し、"Add APM"オプションをクリックしてはじめることができます：

画面の案内にしたがって進むだけで、APMサーバーを稼働させることができます：

設定が完了したら、搭載させる各エージェントタイプについてKibanaのチュートリアルを参照することができます：

わずか数行のコードで、すべての設定が完了します。

Elastic APMの入口

新しいことを学ぶには、実際に手を動かしてみるのが一番です。また、その方法も1つではありません。実際のインターフェースをライブで、リアルに見てみたいという方はこちらのAPMデモ環境をクリックしてご覧ください。ローカルで実行してみたいという方は、APMサーバーダウンロードページの手順に沿って進めていただくことができます。

最も手軽な方法は、Elastic CloudのElasticsearch Serviceです。APMサーバー6.6、Kibanaインスタンス、機械学習ノードを含むすべてのElasticsearchデプロイが、SaaSで提供されており、1分ほどで使いはじめることができます（全サービスを2週間の無料トライアルでお試しいただけます）。クラウドサービスのため、デプロイインフラの保守/管理を行わなくて済むという大きなメリットがあります。

Elasticsearch ServiceでAPMを有効化する

APMクラスターを作成する（または既存のクラスターにAPMを追加する）には、クラスター設定の画面でAPM設定のセクションが表示されるまで下にスクロールします。既存のデプロイをアップデートする場合は[Enable]、[Save changes]の順にクリック、新規デプロイの場合は[Create deployment]をクリックします。

ライセンス

ElasticのAPMサーバーと、全APMエージェントはオープンソースとして提供されています。洗練されたAPM UIはElastic Stackでデフォルトの配布、また無料のベーシックライセンスより使用可能です。アラートや機械学習と統合する場合はベースとなるオプションのライセンスが必要になり、アラートにはゴールド、機械学習にはプラチナをご購入いただく必要があります。

まとめ

APMは、アプリケーションのあらゆる層で起きていることを表示します。機械学習やアラートと統合できるElastic APMなら検索機能を最大に活用でき、アプリケーションインフラの可視性が大きく向上します。トランザクションから痕跡、エラー、例外処理まで可視化でき、洗練されたAPMユーザーインターフェースがコンテクストも表示します。問題が発生していないときも、Elastic APMのデータを参考に修正内容の優先順位付けを行って、アプリケーションパフォーマンスの最大化と、ボトルネックの排除に取り組むことができます。

Elastic APMと監視に関するウェビナーも複数あります。併せてぜひご覧ください。

• Instrument and Monitor Java Applications using Elastic APM
• Using the Elastic Stack for Application Performance Monitoring
• Using Elasticsearch, Beats and Elastic APM to monitor your OpenShift Data
• Unifying APM, Logs, and Metrics for Deeper Operational Visibility
• Tracking your Infrastructure Logs & Metrics in the Elastic Stack (ELK Stack)

はじめてみませんか？ APMに関するトピックはディスカッションフォーラムでもご覧いただけます。チケットの送信や機能のリクエストは、APM GitHub reposにお寄せください。

Elasticsearch Serviceでは2018年8月、デプロイテンプレートや新インスタントタイプ、Hot-Warmアーキテクチャーのサポートといった多数の新機能を追加するとともに料金の大幅な引き下げを実施しました。 この引き下げには、スナップショットストレージとデータ転送の料金を使用量に応じて区分し、使用量と費用をよりコントロールしやすくするという変更も含まれていました。プロモーション期間中は料金が割引になっていたため、月々の請求書では0円の表示になる場合もありました。

このスナップショットストレージとデータ転送のプロモーション割引は2019年2月28日に終了します。本ブログ記事では、今後の料金体系の詳しい情報と、費用をコントロールするコツをお伝えします。

スナップショットストレージの料金体系

スナップショットストレージの料金は、基盤として使用するIaaSオブジェクトストア（例：AWSのS3、Google cloudのGCS）にバックアップスナップショットを格納する費用に関連付けられています。スナップショットストレージの費用はElasticsearchインデックスが稼働するディスクストレージの費用ではありません。ディスクストレージの費用はクラスター（または“デプロイ”と呼びます）の費用に含まれています。

多くのクラウドサービスプロバイダーと同様、Elasticのスナップショットとストレージ費用は2つの側面から算出されます。

• ストレージサイズ（GB/月）
• ストレージAPIリクエスト数（1,000リクエスト/月）

ストレージサイズは、アカウントに紐付けられたすべてのデプロイで生じる全スナップショットが占めるストレージ容量の測定値（GB）です。すべてのリージョンに同じユニット価格が適用されます。Elasticは料金計算のため、ストレージの容量を1時間毎に測定し、そこから1か月間の平均容量を求めています。その月の平均容量（GB/月）により、ご利用アカウントの請求月（カレンダーの月単位）の料金が決まります。

たとえば2019年4月に使用した容量が10日間は100GB、残り20日間が130GBだった場合、月の平均容量は(100×10 + 130×20)÷30で120GB/月となります。

ストレージAPIリクエストの費用は、アカウントに紐付けられたすべてのデプロイで実行されたスナップショットのバックアップ、または復元のリクエストの総数に基づいて計算されます。ストレージサイズとは異なり、リクエスト数はその請求月内に累積で加算した総数です。費用は1,000リクエストあたりの料金で算出します。

本記事の執筆時点（2019年2月1日）で、それぞれの価格体系は次の通りです。

• ストレージサイズ - 1GB/月あたり$0.033
• ストレージAPIリクエスト数 - APIリスエスト1,000回あたり$0.0018

すべてのアカウントのデプロイには、100GB/月の無料プランが提供されます。ストレージ使用量が100GB以下の場合は、費用がかかりません。100GB/月を超えると、100GBを超えて使用した部分のみ費用が発生します。

またすべてのアカウントのデプロイで、1か月あたり100,000回以下のAPIリクエストにも無料プランが適用されます。100,000回を超えた場合、100,000回を超えて使用した部分のみ費用が発生します。

注：単一のスナップショット操作は、単一のAPI呼び出しと同じではありません。複数のファイルが書き込まれたり、削除されたり、変更されたりすると、単一のスナップショット操作に関連する何千件ものAPI呼び出しが発生する可能性があります。当社が記載している価格は1000件のAPI呼び出しの価格です。つまり、1000回のAPI呼び出しで0.0018ドルの場合、100万回の呼び出しでは1.8ドルとなります。

データ転送の料金体系

データ転送料金は、Elasticsearchデプロイへの入力/出力、およびデプロイ内で転送されるデータ容量（ペイロード）に基づいて算出されます。

Elasticでは、次の3つの側面からデータ転送料金を算出・請求しています。

• 入力データ（無料）
• 出力データ
• デプロイ内データ

入力データは、クラスターに入るすべてのトラフィックです。データペイロードを伴うインデックスリクエストや、クラスターに送られるクエリ（サイズはかなり小さいですが）が含まれます。

出力データは、クラスターから出るすべてのトラフィックです。検索結果や、クラスターから出力される監視データがこれに含まれます。異なるリージョンやインターネット、同じリージョンの別のアカウントなど、データの出力先に関わらず同じ料金が適用されます。

デプロイ内データは、デプロイのコンポーネント間を移動するトラフィックです。主に、さまざまなアベイラビリティゾーンにまたがるクラスターのノード間のデータ同期（Elasticsearchクラスターシャーディングによる自動管理）が含まれます。この他に、クラスターの複数のノードにまたがって実行される検索クエリに関連するデータも含まれます。シングルノードのElasticsearchクラスターでも、Kibanaや機械学習、APMなどのノードとの間でデータが行き交うことによりクラスター内の費用が生じることがあり、注意が必要です。とはいえ、こうしたケースで生じる費用は非常に低額です。

ストレージAPIリクエストの計算方法と同様、データ転送の使用量計算はその請求月内に累積で加算されます。

本記事の執筆時点（2019年2月1日）で、それぞれの価格体系は次の通りです。

• 入力データ - 転送量/GBあたり$0（入力データは無料です）
• 出力データ - 転送量/GBあたり$0.032
• デプロイ内データ - 転送量/GBあたり$0.016

すべてのアカウントの全デプロイで、出力データとデプロイ内データにそれぞれ100GB/月の無料プランが提供されます。100GB/月の無料プラン容量を超えると、100GBを超えて使用した部分のみ費用が発生します。

FAQ

スナップショットストレージとデータ転送のコストを確認するには？

スナップショットストレージとデータ転送のコストは、請求書の内訳項目に記載されています。ユーザーコンソールからダウンロードしてご確認いただくことができます。さらに今後のアップデートで、ユーザーコンソールで費用を1日単位で表示できるようにする予定です。翌月の請求を予測しやすくなります。

請求書の例：

新しい料金体系はいつから適用される？

2019年2月1日の請求書（2019年1月のご使用分）より新方式での表示となりますが、請求は発生しません。翌月からのデータ転送とストレージの料金の目安として提示されます。2019年3月1日の請求書（2019年2月のご使用分）についても同じです。3月1日以降の使用がご請求対象となり、2019年4月1日の請求書（2019年3月のご使用分）から実際のご請求が発生します。

スナップショットストレージの費用をコントロールするには？

Elasticsearchのスナップショットは、スナップショットイベントのたびに増分データを保存します。したがって有効なスナップショットサイズは、現在のインデックスサイズよりも大きいということになります。クラスターで使用するデータが大きくなるほど、またデータの変更（追加/削除/修正）が頻繁なほどサイズは大きくなります。より細やかなコントロールのため、Elasticではただデータの変化を記録するスタイルから一歩進んだ機能も導入しています。Elastic Cloudのユーザーコンソールで、[Snapshot]のサブメニューにある[Snapshot count]という高度なパラメーターがその機能です。現在、デフォルトでは100スナップショット（ロールオーバー）に設定されていますが、2-100の間で数値を変更することができます。

注意点：スナップショットの数を減らすことで、インデックスの保持期間を効果的に短縮させることができます。つまり、直近の復元ポイントだけが残り、復元ポイントが消えるまでの時間が短くなります。

APIリクエストはスナップショットを取るたび、または復元が行われるたびに実行されます。復元は一般的に高い頻度で行われるものではありません。一方スナップショットは常に最新の復元ポイントを保つため、デフォルトでは30分おきに実施されます。Elasticは[Snapshot interval]というパラメーターを提供しています。このパラメーターを使用すると、スナップショット間隔を最長で24時間まで延長でき、APIリクエストを減らすことができます。

注意点：スナップショットの間隔を延長すると、部分的なデータロスを生じる可能性があります。スナップショットが古くなるため、復元操作を行う際、最後のスナップショット以降に変更されたデータが復元されません。

最後に、Elasticsearch APIを使用して何らかのスナップショット作成/復元のロジックを実装した場合は、過度の費用が発生しないようプロセスを確認することをお勧めします。

データ転送費用をコントロールするには？

デプロイ外部やクラスターのノード間のデータ転送については、容易にコントロールすることはできません。ユースケースにおいて、クラスターを使用する機能の設定を変えられるとは限らないためです。頻繁に実行されるバッチクエリがあるケースでは、設定を見直すことができる場合があります。

請求額にどのように影響する？

Elasticsearchはさまざまなユースケースで使用されており、ご利用のアカウントでスナップショットストレージやデータ転送コストを予測することは簡単ではありません。そのため今回2か月間にわたって、請求額をお伝えしますが、実際の請求は0になるというサービスを実施いたします。新しい料金体系での費用を把握する機会としてご活用いただければ幸いです。

ゴールド/プラチナの年間サブスクリプションがある場合、請求額への影響は？

スタンダード、ゴールド、プラチナで既に年間のご契約をいただいているお客様は、2019年1月1日以降に更新されたご契約に切り替わるまでご請求の増額や変更はありません。2019年1月1日以降に年間でサブスクリプションをご購入いただく場合、月々のご契約と同じ新しい料金体系でのご請求となります。

GCPにデプロイしている場合、料金体系は変更される？

はい。本ブログ記事の執筆時点では、Elasticsearch Serviceスナップショットストレージとデータ転送の新料金は、ご利用のすべてのクラウドプロバイダー様で同一の価格となります。