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的バレンタインデーの義理チョコを感謝の気持ちと共に。

農業従事者に対する多くの人の認識は、昔から変わっていません。John Deere社のインテリジェントソリューショングループ（ISG）のシニアオペレーションエンジニアであるTim Arp氏は、「ビブオーバーオールを来た男の人がトラクターを運転している」イメージだと言います。「しかし実際は、データを駆使する時代になっているのです」。 自己運転する機器の稼働に使われるGPS情報、機械のパフォーマンスに関するメトリック、作物を植える方法に関するデータなど、どのようなデータであるかは問わず、それらすべてのデータがJohn Deere社のシステムに流れ込む大量の情報となります。

John Deere社については、至る所で見られる有名な「緑色のトラクター」を思い浮かべる人が多いでしょう。しかし、そのトラクターと同様に、データをベースとした同社のアプリケーションは農業専門家にとって非常に重要です。現在、John Deere社は、農業従事者による収穫の最大化とコスト管理に役立つ機械および農学テレマティックアプリケーションで農業運営をサポートしています。

Arp氏は、そのような取り組みを同社初のモバイルアプリケーションであるJDLinkを使用してどのように開始したかについて、Elastic{ON} Tour Chicagoで共有しています。当初、25台のサーバーで構築されていたJDLinkは、コンバインや刈り取り機などの農業設備のデータ（地理的な位置や機械の状態のメトリックなど）を簡単に収集する手段を農業従事者に提供するものでした。しかし、アプリケーションが拡大するにつれてさらに多くのサーバーの導入が必要になり、ISGはスケーリングの課題に直面し、最終的には障害が発生していました。直ちに明らかになったのは、アプリケーションを常時稼働させられるようにすることが、アプリケーションを利用する農業従事者のために重要であるということです。システムを包括的に可視化できるように、ログを集約しデータを統合するための方法がISGには必要でした。

そして2013年、ISGはソリューションを見つけました。それがElastic Stackです。Arp氏は同僚とともにElasticsearchの試用を開始し、バージョン0.98で実用的なデモをまとめました。ほどなくして、4つのノードを使用した最初の本稼働クラスターをバージョン1.4上で構築しました。

「Webサーバーのログ、アプリケーションのログ、システムのログ、ロードバランサーのログなど、すべての種類のログを収集することから始めました。すぐに実現したのは、これらのログを使用したあらゆる分析です。サーバーを個別に監視する必要がなくなり、システムを見るだけで済むようになりました」 Tim Arp氏、シニアオペレーションエンジニア、インテリジェントソリューショングループ（ISG）、John Deere社

Arp氏とチームはKibanaも使用して、エラーとApache Webページを監視し、サーバーごとのレスポンスコードとヒット数を視覚化する便利なダッシュボードを作成しました。

その後数年間にわたって、John Deere社のアプリケーションはさまざまな重要分野の農業従事者を支援するように拡張されました。現在はデータ管理だけでなく、遠隔管理、ガイダンス、可変レートアプリケーション、農場および水の管理をサポートするアプリケーションを提供しています。その製品の拡大とともに、同社のElasticsearchの使用も拡大しています。 

同社の現在の環境であるLogcentral@Deereは、ISGアプリケーション開発チームのすべてにロギングフレームワークを提供するために、4ノードから25ノードにスケールアップされています。Elastic Stack 6.3を実行するこのシステムは、11テラバイトのストレージを使用して180億件ものドキュメントを処理しています。システムにはおよそ14の異なるアプリケーションが同時にログを実行しており、毎秒2万イベントがストリーミングされています。また、John Deere社は、8つのElasticsearchクラスターを使用してLogcentralをクラウドに拡張しています。100を超えるアプリケーションがログを実行している最も大きなクラスターには、51ノードが含まれています。

現在John Deere社は、サポート、統合された認証および認可、Elastic Stackのアラート機能（Watcher）による監視およびアラート、クラスター間検索、シームレスなアップグレード、機械学習などの機能に関して、Elastic Cloud Enterprise（ECE）を活用しています。今後は、お客様である農業従事者の成果を最大化するために、ロールアップおよびデータ集計などの新しい機能を活用できることを期待しています。

Elastic{ON} TourでのTim Arp氏によるセッションの全体は、こちらでご覧いただけます。重要なデータを世界中の農業専門家が活用できるように、John Deere社がElasticsearchを利用した方法の詳細をご確認ください。

本記事は最近の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:を。

Aginic社は、オーストラリアの大手データ分析コンサルティングエージェンシーです。Aginic社はElasticのパートナーとして、両社共通のお客様が実用的な「変化のためのインサイト」を得られるように支援しており、健康、教育、エネルギー、エンターテインメント、防衛、金融セクターなどの主要なプロジェクトに、Aginic社のアナリスト、エンジニア、開発者、設計者、デリバリコーチが取り組んでいます。

最近開催されたElastic Brisbaneの会合において、Aginic社のチームはElastic Stackの新しい画期的なCanvasおよびSQL機能を紹介するために、オーストラリアのニューサウスウェールズ州における自転車シェアリングサービスの改善に役立つ可能性のある一連のダッシュボードについて仮説を立て、それに基づいて実際に作成することにしました。

チームはまずいくつかのオープンデータソースと過去のユースケースを掘り下げ、Kibanaの新しいアプリケーションであるCanvasをすばやく操作し、NYC CitiBike System¹の既存の通勤シナリオデータを1つのエレガントなビジュアライゼーションに統合しました。そこから、ニューサウスウェールズ州の自転車のレンタル料、レンタル用自転車の在庫の監視、通勤者の全体的な満足度、自転車の全体的なユーザビリティの向上をサポートする方法を模索し始めました。 

その方法は以下のとおりです。

まず、CanvasダッシュボードでNYC CitiBike Systemのデータの一部を表しました。具体的には、トランザクションから得られた通勤データと、各時点での駅の状態のメトリックを活用できるようにデータセットを選択しました。この2つの異なるタイプのデータを使用することで、Canvasの新しい機能を最も的確に紹介できると考えたからです。

通勤データソースは、S3にホストされている履歴データを利用しました。プレゼンテーション時には、シンプルな一括Logstash CSVインポートパイプラインを使用しました。これにより、簡単に拡張して結果を自動的かつ定期的にダウンロードすることも可能になるため、Elasticsearchのデータを常に最新の状態に維持できるようになります。

一方、駅の状態に関するデータフィードは、頻繁に更新されるJSON URLで構成されています。そのURLには、各駅で利用可能な自転車の台数など、さまざまなメトリックが含まれています。このURLへのリクエストの結果は、次の形式の最上位のJSONオブジェクトです。

{"last_updated":1549188861,"ttl":10,"data":{"stations":[]}}

ここでのリアルタイムフィードの鍵となるのは、 last_updatedおよびttl (time to live)フィールドです。ttlフィールドは、このフィードが再びアップデートされるまでの残り時間を示しているため、last_updatedにttlフィールドを足すと、次にフィードがアップデートされる時間が分かります。データをできる限り最新の状態に維持できるように、フェッチ/スリープのループに留まるようカスタムのPythonアプリケーションを記述します。

これでデータはElasticsearch内にあるので、Kibanaに移動してビジュアライゼーションを試せるようになりました。元来、ダッシュボードには、ユースケースによっていくつかの目的があります。

• 情報を効率的に伝える
• ドリルダウンおよびフィルター機能によってセルフサービスで発見できるようにする 
• 特定のビジネス部門のレポートの生成を自動化する

フィルターを使用したセルフサービスによるインタラクティブなディスカバリワークロードには、Kibanaに組み込まれたダッシュボード機能が最適です。ユーザーはすばやく簡単に、提示されたデータを操作できるからです。これまでは、非インタラクティブなユースケースのために、（たとえばd3をベースとした）カスタムアプリケーションを構築するというケースがよくありました。それらのカスタムアプリケーションは、開発時間の観点、および組み込みのダッシュボードが影響を受けないように継続的にサポートするという観点から投資が必要でした。

Canvasでは、従来のグリッドレイアウトのダッシュボードからオブジェクト中心のシームレスなレイアウトへと移行することで、この課題を解消します。そのような移行によって、自由形式でビジュアライゼーションのスタイルを作成することが可能になり、創造の自由がさらに高まります。しかしそれよりも重要なことは、デザイナーが各オブジェクト/グラフィックに関するさらなる制御性を得たことです。データビジュアライゼーションとデータの間のインタラクションをグラフィックオブジェクトで表現することで、これまでよりも意味がさらに一目瞭然になります。 

ただしここで注意が必要なのは、データプレゼンテーションツールは、オーディエンスを理解している場合にのみ役立つということです。つまり、意味（定義）と（簡単に理解できる形式になっている）データをペアリングする能力が鍵となります。この要件はCanvasの使いやすさによって軽減されます。ユーザーは、そのニーズを満たすため、およびそのビジュアライゼーションが全体として、見ている人に情報をすばやく伝えるための十分なコンテキストを提供しているかどうかをチェックするために、迅速にバージョンを繰り返すことができます。つまり、デザイン思考の可能性と、BIのコンテキストにおける迅速な繰り返し作業の可能性を真に実現することができるプラットフォームとなっています。

最初のCanvas Workpadは、単純にページの隅にロゴを付けるのではなく、ダッシュボード自体にブランディングを統合するという前提で構築されました。このアプローチにより、アニメーション化されたリアルタイムのインフォグラフィックを低い開発コストで作成するなど、特定の可能性が生まれます。 

このダッシュボードはCanvasのテクノロジーを示す以上のものではありませんが、システムの保守担当者にとっては概要ダッシュボードとなり、また自転車を利用する可能性のある人が自分の利用する駅に自転車があるかどうかを一目で把握できる一般向けの画面として機能します。どちらのシナリオでも、目を引くダッシュボードを使用することによって、それを見る人は主要なメトリックまたは興味のある情報をすばやく特定できます。

結局のところ、Canvasダッシュボードが私たちの仕事に役立つ用途は、きわめて多数あるということが分かります。このようなソリューションは、既存のユースケースにおけるダッシュボードの使いやすさを改善することができ、結果として、得られる情報やユーザーによるインタラクションを増やすことにつながります。Canvasは新しい製品ではありますが、従来のダッシュボード/BIソフトウェアで置き去りにされていたギャップを埋めます。私たちは、お客様のビジュアライゼーションに関する問題に対して、Canvasを使用して独自のソリューションを提示できるようこれからも取り組んでいきます。

¹Aginic Pty Ltd社は、今回取り上げた自転車シェアリングサービスとは提携しておらず、同サービスからの承認、支持、後援も受けていません。

Ruben Slabbert
Ruben Slabbert氏は、Amazon Web Services (AWS)、Microsoft Azure、およびGoogle Cloudのエンタープライズデータパイプラインを専門とするクラウドデータエンジニアおよびアプリケーション開発者です。Aginic社での在職中には、主にパイプラインアーキテクチャの責任者として、複数の部門にまたがるチームを管理し、信頼できるバッチおよびリアルタイム処理を本番システムからクラウド内のデータレイクおよびウェアハウスに提供していました。

Andrew Li
Andrew Li氏は、データサイエンスおよび全文検索に関する広範な知識を備えた分析コンサルタントであり、分析を活用した成果の向上に熱心に取り組んでいます。 機械（医用生体）工学の学士号を取得後にそのキャリアをスタートさせ、健康、政府、オーストラリア証券取引所における上位企業など、さまざまな業界の公的および民間セクターのクライアントのコンサルタントを担当しています。

データセンター間のレプリケーションは、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 ガイド」を参照してください。

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

マイクロサービスの世界

マイクロサービスアーキテクチャを採用する企業はますます増えています。それらの企業では毎日、マイクロサービスを開発し、デプロイしています。そのようなサービスは多くの場合、異なるプログラミング言語で開発され、個別のランタイムコンテナーにデプロイされ、さまざまなチームおよび組織によって管理されています。Twitterのような大企業では何万ものマイクロサービスを持ち、それらのすべてを活用してビジネス目標の達成に取り組むことができます。Twitterが同社のブログ投稿で述べているとおり、多様なサービストポロジーの健全性とパフォーマンスに対する可視性は、同社が問題の根本原因を迅速に判断し、Twitterの全体的な信頼性と効率性を向上させるためにきわめて重要です。

そのために役立つのが分散トレーシングです。分散トレーシングはマイクロサービスが直面する次の2つの根本的な課題に役立ちます。

1. レイテンシの追跡
   1人のユーザーのリクエストまたはトランザクションは、異なるランタイム環境のさまざまなサービスを経由します。特定のリクエストに対する各サービスのレイテンシを把握することは、システム全体としての総合的なパフォーマンス特性を理解し、改善の可能性に関する貴重なインサイトを得るために不可欠です。
2. 根本原因の分析
   根本原因の分析は、マイクロサービスの大規模なエコシステム上に構築されているアプリケーションにとって、さらに大きな課題です。どのような問題がどのサービスで、どのようなタイミングで発生するか分かりません。分散トレーシングは、そのようなシステムにおける問題をデバッグする際にきわめて重要です。

客観的に見た場合、トレーシングは可観測性の3本の柱の1つに過ぎません。3本の柱とは、ロギング、メトリック、トレーシングです。後で手短に説明しますが、Elastic Stackは可観測性の3つの柱すべてに対応する統合プラットフォームです。ログ、メトリック、およびAPMデータが同じリポジトリに保存され、分析され、相関付けられていれば、ビジネスアプリケーションおよびシステムに関する最もコンテキストが豊富なインサイトを獲得することができます。このブログでは、トレーシングのみに焦点を当てます。

Elastic APMでの分散トレーシング

Elastic APMは、Elastic Stack上に構築されたアプリケーションパフォーマンス監視システムであり、ソフトウェアサービスとアプリケーションのリアルタイムでの監視、受信リクエストへの応答時間に関する詳細なパフォーマンス情報の収集、データベースに対するクエリ、キャッシュの呼び出し、外部HTTPへのリクエストなどが可能です。Elastic APMのエージェントが、すぐに使える機能豊富な自動インストルメンテーション機能（タイミングデータベースクエリなど）を、サポートされているフレームワークおよびテクノロジーに提供します。また、独自の目的のためにカスタムインストルメンテーションを使用することもできます。これによって簡単にパフォーマンスの問題を迅速かつ正確に特定し、修正できます。

Elastic APMは分散トレーシングをサポートし、OpenTracingに準拠しており、単一のビューでマイクロサービスアーキテクチャ全体のパフォーマンスを分析できます。Elastic APMは、すべてのリクエストを最初のWebリクエストからフロントエンドサービスまで、そしてバックエンドサービスに実行されるクエリまで追跡することで、それを達成します。これにより、さらに簡単かつ迅速に、アプリケーション全体におけるボトルネックの可能性を見つけることが可能になります。APM UIでのタイムラインのビジュアライゼーションでは、トレースに接続されている各サービスからのすべてのトランザクションのウォーターフォールビューが表示されます。

また、Elastic Stackはログの集約とメトリック分析にも適したプラットフォームです。ログ、メトリック、およびAPMトレースのすべてをElasticsearch内に保存およびインデックスすれば非常に強力です。インフラストラクチャメトリック、ログ、トレースなどのデータソースを素早く相関付けできれば、より迅速に根本原因をデバッグできます。APM UIでトレースを表示すると、[Actions]メニューをクリックして素早くホストまたはコンテナーメトリックおよびログにアクセスできます（メトリックおよびログも収集されている場合）。

誰もがElastic APMを使用してアプリケーションとサービスのインストルメンテーションを実行していれば素晴らしいのですが、Elastic APMは現在利用できる唯一の分散トレーシングソリューションではありません。ZipkinやJaegerなど、他にも人気のあるオープンソーストレーサーがあります。マイクロサービスの世界では、ポリグロット（多言語）プログラミングやポリグロットパーシステンスのような概念がよく知られており、広く受け入れられています。それと同様に、「ポリグロットトレーシング」がより一般的になっていくでしょう。独立、分離といったマイクロサービスの性質により、異なるサービスの責任者は異なるトレーシングシステムを使用する可能性があります。

開発者にとっての課題

さまざまなトレーシングシステムが利用できるため、開発者はまさに課題に直面しています。結局のところ、トレーサーはアプリケーションコード内に存在します。一般的な課題には次のようなものがあります。

1. どのトレーシングシステムを使いますか？
2. トレーサーを変更したい場合はどうなるのでしょうか？ソースコード全体を変更したくはありません。
3. 異なるトレーサーを使用している可能性のある共有ライブラリについてはどうすればよいですか？
4. サードパーティのサービスが異なるトレーサーを使用している場合はどうなるのでしょうか？

当然のことながら、これらの懸念事項に対処するには標準化が必要です。現在の私たちが標準化のどの段階にいるかを考える前に、少し前に戻り、アーキテクチャ面から包括的に分散トレーシングについて見てみましょう。そして、分散トレーシングの「最高の状態」を達成するために何が必要かについて理解します。

分散トレーシングのアーキテクチャコンポーネント

最新のソフトウェアシステムは、いくつかの高レベルのコンポーネントに分解されます。それらは通常、異なる組織によって設計および開発され、次のような異なるランタイム環境で実行されます。

• 独自のアプリケーションコードとサービス
• 共有されたライブラリとサービス
• 外部サービス

そのようなシステムを分散トレーシングで包括的かつ統合的に監視するためには、4つのアーキテクチャコンポーネントが必要です。

1. 標準化された分散トレーシングAPI。ベンダー非依存型の標準化されたトレーシングAPIにより、開発者は標準化された方法でコードのインストルメンテーションを実行できます。実行時にどのトレーサーの使用を選択しても問題はありません。これがすべての最初のステップになります。
2. トレーシングコンテキストの標準化された定義と伝達。トレースが1つのラインタイムから別のランタイムに移る場合、その両者がトレーシングコンテキストを理解する必要があり、そのコンテキストを伝達する標準化された方法が必要です。コンテキストには少なくとも、トレースIDが含まれます。
3. トレーシングデータの標準化された定義。1つのトレーサーからのトレースデータを別のトレーサーが理解し、使用する場合には、トレースデータに標準化された拡張可能なフォーマットが必要です。
4. 相互運用可能なトレーサー。最後に、100%のランタイム機能を達成するには、さまざまなトレーサーが、別のトレーサーからトレースデータをオープンな方法でエクスポートおよびインポートするメカニズムを提供する必要があります。理想としては、Jaegerなどのトレーサーでインストルメンテーションされた共有のライブラリまたはサービスがそのトレーシングデータを、設定変更を通じてJaegerエージェント経由で直接Elastic APMまたはその他のトレーサーに送信できることです。

では、OpenTracingに進みましょう。

OpenTracingの仕様

OpenTracingの仕様の定義は、分散トレーシング向けのオープンなベンダー非依存型APIです。そのためユーザーは、OpenTracingの実装をいつでも変更することができ、ベンダーへのロックインを回避できます。また、フレームワークおよび共有ライブラリの開発者は、標準的な方法ですぐに使えるトレーシング機能を提供することができます。これにより、フレームワークおよびライブラリに対するより優れたインサイトを獲得できるようになります。UberやYelpなどのWebスケールの企業は、OpenTracingを使用して、会社の高度に分散した動的なアプリケーションに対する詳細な可視性を得ています。

OpenTracingデータモデル

OpenTracingの基本的な概念と基盤となるデータモデルはGoogleのDapperです。主要な概念はトレースとスパンです。

1. トレースは、分散システムを通過するトランザクションを表します。スパンの有向非巡回グラフと考えることができます。
2. スパンは、作業の論理的ユニットです。名前、開始時間、継続時間を持ちます。関係をモデル化するために、スパンはネストされ、順序付けられます。スパンは、キー/値タグと、特定のスパンインスタンスに付加されタイムスタンプが付いた細かい構造ログも受け入れます。
3. トレースコンテキストは、分散トランザクションを伴ったトレース情報です。その情報には、ネットワークまたはメッセージバスでサービスからサービスに渡された時間が含まれています。コンテキストには、トレース識別子、スパン識別子、およびトレーシングシステムがダウンストリームのサービスに伝達する必要があるその他のデータが含まれます。

それらの全体像

さまざまな組織が開発し、稼働させているカスタムアプリケーションコード、共有ライブラリ、共有サービスからのトレーシング情報は、標準化によって、交換可能でランタイム互換性があることが理想的です。それらの各コンポーネントがどのトレーサーの使用を選択するかは問題ではなくなります。

しかしOpenTracingは、前述の4つのアーキテクチャコンポーネントのうちの最初のコンポーネントにしか対応しません。そこで、他のコンポーネントに関して現在の私たちはどのような状態であり、今後はどうなるのでしょうか。

現在の状態

前述のとおり、OpenTracingは、異なるトレーサー向けのトレーシングAPIの標準セットを定義し、実装します。これは優れた開始点であり、役立つものです。しかし、トレーシングコンテキスト、およびトレーシングデータに互換性があり、交換可能なものになるには、やはりそれらの標準化が必要です。

1. OpenTracing APIはAPIの標準セットを提供する。これが現在の私たちにとってほぼ唯一の標準化です。仕様にも制約があります。たとえば、すべてのプログラミング言語をカバーしていません。とは言え、これは素晴らしい取り組みであり、さらに勢いを増しています。
2. トレーシングコンテキストの標準化された定義はまだない。W3C Distributed Tracingワーキンググループでは、現在、トレーシングコンテキストの定義の標準化に取り組んでいます（ W3C Trace Context仕様）。この仕様は、分散システム内でのコンテキストおよびイベント相関付けに対する統合アプローチを定義しており、異なる監視ツール間に渡って、分散アプリケーション内でエンドツーエンドのトランザクショントレーシングが可能となるものです。Elastic APMは、分散トレーシングのためのHTTPヘッダーフォーマットの標準化に向けたW3C Trace Contextワーキンググループの取り組みをサポートしています。当社のエージェント実装はTrace Contextドラフトの仕様にほぼ従っており、最終的に決定した仕様を完全にサポートする予定です。
   
   現在のトレーシングコンテキストの非互換性の例として、Elastic APMとJaegerがトレースIDとして使用しているHTTPヘッダーを以下に示します。ご覧のとおり、IDの名前とエンコーディングの両方が異なっています。異なるトレーシングヘッダーが使用されていると、各トレーシングツールの境界を越えたときにトレースは破損します。
   
   Jaeger：
   uber-trace-id：118c6c15301b9b3b3:56e66177e6e55a91:18c6c15301b9b3b3:1
   
   Elastic APM：
   elastic-apm-traceparent:00-f109f092a7d869fb4615784bacefcfd7-5bf936f4fcde3af0-01
   
   定義自体以外にも課題はあります。たとえば、HTTPヘッダーのすべてがサービスインフラやルーターなどによって自動的に転送されるわけではないことです。ヘッダーがドロップすると常にトレースは破損します。
3. トレーシングデータの標準化された定義はまだない。W3C Distributed Tracingワーキンググループによると、トレースの相互運用性に関する2つ目の問題は、「トレース全体またはトレースの断片などのトレースデータを、さらなる解釈のためにさまざまなツールに共有できる標準化された拡張性のあるフォーマット」です。ご想像のとおり、多数のオープンソースおよび営利企業が関与し、標準のフォーマットに合意することは簡単なことではありません。近いうちに実現することを願っています。
4. トレーサーはランタイム互換性がない。前述の理由のすべてと、システムをオープンにし、世界との互換性を持つようにすることにさまざまな動機があることによって、トレーサーは現在、実行時にお互いの互換性がありません。自信を持って言えることは、これは近い将来においても変わらずそのままだろうということです。

Elastic APMによる現在の他のトレーサーとの連携方法

現在、トレーサー間の完全な互換性の実現が近づいているとは言えませんが、落胆する必要はありません。 そのような現状でも、Elastic Stackはいくつかの異なる方法で他のトレーサーと連携できます。

1. Elasticsearchを他のトレーサー向けのスケーラブルなバックエンドデータストアとして使用する。
   
   驚くことではありませんが、ElasticsearchはZipkinやJaegerなど、他のトレーサー向けのバックエンドデータストアとして使用されています。Elasticsearchにはきわめて高いスケーラビリティと豊富な分析機能があるからです。ZipkinまたはJaegerのトレーシングデータをElasticsearchに送信することは、両方とも簡単な設定で済みます。トレーシングデータをElasticsearchに送信すれば、Kibanaの強力な分析およびビジュアライゼーション機能を使用してトレーシング情報を分析し、アプリケーションパフォーマンスに対する詳細なインサイトを提供する魅力的なビジュアライゼーションを作成できます。
2. Elastic OpenTracingブリッジ
   
   Elastic APM OpenTracingブリッジにより、OpenTracing APIを使用してElastic APMトランザクションおよびスパンを作成できます。つまり、OpneTracing APIの呼び出しをElastic APMに変換し、それによって既存のインストルメンテーションを再利用することが可能になります。たとえば、Jaegerによって実行された既存のインストルメンテーションを、コードのいくつかの行を変更することでElastic APMに単純に置き換えることができます。
   
   Jaegerによる最初のインストルメンテーション：
   
   

   import io.opentracing.Scope;
   import io.opentracing.Tracer;
   import io.jaegertracing.Configuration;
   import io.jaegertracing.internal.JaegerTracer;
   ...
   private void sayHello(String helloTo) {
       Configuration config = ...
       Tracer tracer = config.getTracer();
       try (Scope scope = tracer.buildSpan("say-hello").startActive(true)) {
           scope.span().setTag("hello-to", helloTo);
       }
       ...
   }
       

   JaegerをElastic OpneTracingブリッジに置き換える：
   
   

   import io.opentracing.Scope;
   import io.opentracing.Tracer;
   import co.elastic.apm.opentracing.ElasticApmTracer;
   ...
   private void sayHello(String helloTo) {
       Tracer tracer = new ElasticApmTracer();
       try (Scope scope = tracer.buildSpan("say-hello").startActive(true)) {
           scope.span().setTag("hello-to", helloTo);
       }
       ...
   }
       

   
   
   このシンプルな変更によって、その他のトレーシングコードを変更することなく、トレーシングデータを正常にElastic APMに送信できます。これこそがOpenTracingの力です。

Elastic APMリアルユーザー監視

トレーシングおよびコンテキストの伝達などを語る際には、バックエンドサービスに注目することがほとんどですが、クライアント側でトレースをブラウザで開始することには大きな価値があります。これを実行すると、ユーザーがブラウザで何かをクリックした瞬間に、トレース情報を得ることができます。このトレース情報は、パフォーマンスの側面からアプリケーションの「リアルユーザーエクスペリエンス」を表していることになります。ここでも残念なことに、現在ではその情報を転送する標準化された方法はありません。もちろんW3Cグループは今後、トレースコンテキストをブラウザまで拡張する予定です。

Elastic APMリアルユーザー監視（RUM）は、まさにその機能を現在提供します。RUM JSエージェントはクライアント側アプリケーション内のリアルユーザーエクスペリエンスを監視します。TTFB（Time to First Byte）、domInteractive、およびdomCompleteなどのメトリックを計測できるため、クライアントアプリケーション内のパフォーマンス問題、およびサーバー側アプリケーションのレイテンシに関連する問題を見つけるのに役立ちます。弊社のRUM JSエージェントはフレームワークに依存しません。つまり、JavaScriptベースの任意のフロントエンドアプリケーションで使用できます。

<p?</p?

まとめ

このブログが、分散トレーシングの現状の理解に少しでも役立ち、また、OpenTracingの現状に関するいくつかの誤解についても明確化できていることを願っています。最後に、このブログの内容をまとめます。

1. 分散トレーシングは、マイクロサービスに関するきわめて貴重なパフォーマンスインサイトを提供します。
2. OpenTracingは、業界における分散トレーシングの標準化に向けた最初の一歩です。完全な互換性を達成するまでには、まだ長い道のりが残されています。
3. Elastic APMはOpenTracingに準拠しています。
4. Elastic OpenTracingブリッジにより、インストルメンテーションの再利用が可能です。
5. Elastic Stackは、現在完全なランタイム互換性はないものの、ZipkinやJaegerなどの他のトレーサーにとってスケーラブルかつ長期対応の優れたストレージです。
6. Elasticは、Elasticのトレーシングデータかどうかに関わらず、豊富な分析機能を提供します。ZipkinまたはJaegerのトレーシングデータは簡単な設定でElasticsearchに送信できます。
7. Elastic APMリアルユーザー監視（RUM）は、クライアント側アプリケーション内のリアルユーザーエクスペリエンスを監視します。
8. 全体としてElasticは、可観測性の3つの柱（ロギング、メトリック、トレーシング）に対応するきわめてスケーラブルで機能豊富な統合分析プラットフォームです。

ディスカッションを開始する場合またはご質問がある場合は、Elastic APMフォーラムをご利用ください。ご希望通りのトレーシングが実行できることを願っています。

Elastic Stackはログを保存する用途に広く使われています。

おそらく多くのユーザーはログを構造化せず、タイムスタンプをパースアウトし、フィルター用の簡単なタグをつけたりするだけで保存を開始しています。Filebeatのデフォルトの挙動もそのようになっています。ログをテイルし、まったく構造化せずに、できる限り早くElasticsearchに送る仕様です。KibanaのLogs UIも特にログの構造を想定していません。“@timestamp”と“message”のシンプルなスキーマだけで十分動作します。Elasticでは、この方法をロギングのミニマルスキーマアプローチと呼びます。このアプローチでは、簡単な手順でディスクに保存することができます。しかし、シンプルなキーワード検索や、タグベースのフィルタリング以上のことをやろうとする場合にはあまり便利ではありません。

収集したログについて一通りのことがわかったら、大抵の場合、より多くのことをやりたくなります。たとえば複数のログとステータスコードに関連性があると気付いた場合、次は、過去1時間の間に発生した5xxレベルのステータスコードの数を可視化したくなるかもしれません。Kibanaのスクリプテッドフィールドでは、検索時にログに対してスキーマを適用し、このようなステータスコードを抽出してアグリゲーションや可視化、その他の操作を実行することができます。ロギングにおけるこのようなアプローチは、schema on readと呼ばれます。

アドホックな探索には便利ですが、このアプローチには欠点もあります。継続して使用するレポートやダッシュボードに適用すると、検索や可視化の再レンダリングを実行するたび、フィールドからの抽出も再実行しなければなりません。では、はじめに必要なフィールドを構造化しておくとどうでしょうか？バックグラウンドで再インデックスプロセスを開始して、永続するElasticsearchインデックスの構造化されたフィールドにスクリプテッドフィールドを“存続”させておくことができます。またElasticsearchへのデータストリーミングにはLogstashまたはを設定し、dissectあるいはgrokプロセッサーで前もって上述のフィールドを抽出するようにします。

ここから、3つ目のアプローチも考えることができます。すなわち、書き込み時点でログをパースし、上述のフィールドを前もって抽出するというアプローチです。このようにして構造化されたログを分析するアプローチでは、複数のメリットがあります。後からフィールドを抽出する要件について悩む必要がなく、クエリを高速化でき、ログデータから得られる価値も高まります。“schema on write”でログ分析を一元化するこのアプローチは、多くのElastic Stackユーザーに支持されています。

このブログ記事では2つのアプローチの短所も説明し、ロギングの計画を立てる際の考え方もご紹介します。以下では、あらためてログを事前に構造化することの本質的な価値と、事前の構造化を行わずにはじめたケースでも、ロギングのデプロイに習熟するにつれてこのアプローチに自然と行き着く理由をご説明します。

Schema on writeの長所と短所

一元的なロギングクラスターに書き込む際に、ログを構造化する理由やメリットは何でしょうか？

クエリのエクスペリエンスを向上させるため。 情報を求めてログを検索する場合、普通は“error”のようなシンプルなキーワードで検索を開始するはずです。この場合、転置インデックス内で各ログ行を1つのドキュメントとして扱い、全文検索を実施することでクエリの結果を返すことができます。しかし、「my_fieldがNであるすべてのログ行を表示する」など、複雑な問いの場合はどうでしょうか？ まずmy_fieldというフィールドをあらかじめ定義しておかなければ、このような質問を直接することはできません（自動入力はありません）。たとえログにこの情報があるとわかっていても、期待値との比較を行うには、このフィールドを抽出するクエリでパースするルールを書く必要があります。Elastic Stackでは事前に構造化されたログに対し、Kibanaの自動入力機能がフィールドや値を自動的に提案してクエリの構築をサポートします。分析の生産性に大きく貢献することがおわかりいただけると思います。構造化しておくことで、あなたも同僚も、どのフィールドがどうなっているか悩んだり、フィールドを抽出するために複雑なパースのルールを書くことなく、直接クエリを実施することが可能になります。

時系列クエリとアグリゲーションが速くなる。 Elastic Stackで構造化したフィールドをクエリすると、大量の時系列データで実施する場合でも、ミリ秒単位で結果が返されます。典型的な“schema on read”型のシステムでは数分から数時間もかかる処理です。このような差が付く理由は、数学的に考えるとわかりやすくなります。つまり、フィールドの抽出と操作のためにすべてのログ行でregexを実行するよりも、構造化したフィールドを抽出し、かつ事前にインデックスしてから統計的なアグリゲーションをフィルタリング/実行する方がはるかに高速です。アドホックなクエリを実施するユースケースでは特にこの点が重要です。調査でどのようなクエリを実行するか事前にわからなければ、事前に準備することは不可能だからです。

ログをメトリックとして扱える。 上記の内容にも関連しますが、構造化されたログから数的な値を抽出した結果は、意外にも時系列ログ、あるいはメトリックのように見えます。運用の観点では、データポイント上ですばやくアグリゲーションを実行できることに、大きな価値があります。フィールドを構造化することで、大規模なログ中の数的なデータポイントをメトリックとして扱うことが可能になります。

時間とともに変化するソースで「正解」を見つける。 ホスト名を求めるためにIPアドレスのようなフィールドを解決する場合、クエリ時ではなく、インデックス時のログで解決する必要があります。後から解決しても、トランザクションが行われた（より早い）時点で有効ではなかった可能性があるからです。そのIPアドレスも、1週間後には完全に異なるホスト名にリンクされているかもしれません。このメリットが当てはまるのは、マッピングにおいて最新のスナップショットのみ提供する外部ソースを参照する場合です。たとえばID管理システムに対するユーザー名解決や、CMDBに対するアセットタグなどが該当します。

リアルタイムな異常検知とアラートを可能にする。 アグリゲーションと同様、大規模なデータでのリアルタイムな異常検知と通知は、構造化されたフィールドを使用するとき最も効率的に動作します。事前に構造化しない場合、クラスター上で継続的な処理を実施する要件は非常にややこしくなります。「検索時のフィールド抽出を必要なアラート数の規模に拡張させることができず、アラートの作成と異常検知を導入できていない」というお客様も多くいらっしゃいます。こうなると、収集しているログデータが大規模にリアクティブなユースケースにしか適さず、プロジェクトの投資利益率を押し下げているということになります。

可視性の取り組みにログを活用できる。 可視性の向上に取り組んでいる方は、「ログの収集と検索だけでは不十分」であることにすでにお気づきかもしれません。本来ログデータはメトリック（例：リソース使用状況）やアプリケーション追跡データと関連付けられるべきものです。関連付けることで、データポイントを問わず、運用者はサービスで何が起きているか包括的に把握することが可能になります。このような関連付けも、構造化されたフィールドで最適に行うことができます。構造化されていない場合、大規模なデータではルックアップが遅くなり、実用的ではありません。

データの質を確保できる。 事前の処理を前提とするイベントでは、無効、重複、不足しているデータを確認し、問題のデータを訂正する機会があります。一方、schema on readアプローチを使用すると、データ自体の有効性や完全性を事前に検証していないため、正しく返された結果なのかがわかりません。有効でないデータから、不正確な結果や誤った結論を導いてしまう可能性があります。

アクセスを細やかに制御できる。 構造化されていないログデータに、フィールドレベルの制限といった細かなセキュリティルールを適用することは簡単ではありません。検索でアクセスするデータを制限するフィルターは役立つかもしれません。しかし、フィールドのサブセットからなる部分的な結果を返すことができないなど、検索に大きな制約を課すことになってしまいます。Elastic Stackが提供するフィールドレベルのセキュリティ機能では、一部のフィールドのみ閲覧でき、データセット全体のほかの部分を閲覧できないようにユーザーの権限を制限することができます。これにより、ログ中の個人情報データを保護しながら多数のユーザーに他の情報データの操作を許可するといった設定も、柔軟かつ簡単に行うことができます。

ハードウェア要件

“schema on write”アプローチに関する一般的な認識の1つに、「ログをパースしたり、パースしていないフォーマットとパースされた（あるいはインデックスされた）フォーマットの両方を保存することになり、クラスターがより多くのリソースを必要とする」というものがあります。この認識が正しいかどうかは、状況によります。ここでは、ユースケースごとに検討してみます。

一度限りのパースvs継続的なフィールド抽出： ログを構造化したフォーマットにパースして保存する処理は、Ingest側の容量を消費します。しかし、構造化されていないログで継続的にクエリを実行し、フィールドを抽出するために複雑なregexステートメントを実行すれば、長期的にはその方がはるかにRAMとCPUを消費します。保存するログの検索はごくたまにしか行わないというユースケースを予定している場合、事前の構造化に容量を消費する必要はないと言えます。一方、頻繁にログをクエリしたり、ログデータをアグリゲーションすることが予測されるユースケースでは、投入時の一度限り投資することで、長期的には運用コストを節約できる可能性が高くなります。

投入要件： 何もしない場合に比べ、事前に追加処理を行うことで投入のスループットが下がる可能性があります。そこで、ElasticsearchのIngestノード、またはLogstashインスタンスを独立にスケールさせて、負荷を管理する投入インフラストラクチャーを追加することができます。最適なリソースも揃っており、具体的なアプローチもブログ記事で紹介されています。またElastic CloudでElasticsearch Serviceをご利用の場合は、"投入対応"ノードを追加するだけでスケールさせることができるので非常に簡単です。

ストレージ要件： すぐにはピンとこないかもしれません。実はログの構造を事前に把握するために何らかの作業を行う場合、ストレージ要件はより低くなります。これは、ログが冗長で、多くのノイズを含む傾向があるためです。こうしたログを事前に調査することにより（すべてのフィールドを完全にパースしない場合でも）、どのログ行や抽出済みフィールドを検索用に一元化したログクラスターに入れるか、何をアーカイブするか決定することができます。この作業が、ログを保存するディスク要件を引き下げることにつながります。Filebeatにはこうした目的に最適なdissectプロセッサーやdropプロセッサーがあります。

「法令や規制に準拠するためすべてのログ行を保存する必要がある」という場合も、“schema on write”でストレージコストを最適化する複数の方法があります。まず、ログの構造化はユーザーが自由に制御できるもので、必ずしも完全に構造化する必要はありません。重要な部分にだけ構造化したメタデータを追加し、残りのログ行はパースしないでおく、ということも可能です。一方、ログを完全に構造化すれば、ストレージ上でも重要なデータのあらゆる部分が構造化されます。したがってログをインデックスした同じクラスターに“source”フィールドを保つ必要がなく、安価なストレージにアーカイブすることが可能になります。

それでもストレージについて懸念がある場合、デフォルトのElasticsearchをさまざまな方法で最適化することができます。わずかな作業で、圧縮比を確認することができるようになります。また、保存期間が長く、アクセス頻度が乏しいデータを分離してストレージの効率を高めるHot-Warmアーキテクチャーやフローズンインデックスを活用することもできます。Hotデータに関しては、必要なクエリの結果を数分も待つことを考えれば、高速なストレージを使用する費用は決して高くありません。その点も心に留めておきましょう。

事前に構造を定義する

もう1つ、schema on writeアプローチに関する一般的な認識に「ログの事前構造化は難しくて大変」というものがあります。この認識は果たして正しいでしょうか？検証してみましょう。

すでに構造化されたログ： 多くのログがすでに構造化されたフォーマットで生成されています。多くの一般的なアプリケーションはJSONへのロギングを直にサポートしています。この場合、ログを一切パースせずElasticsearchに直接投入するだけで、構造化されたフォーマットで保存できるということになります。

プリビルトのパースルール： Elasticがオフィシャルにサポートするプリビルトのパースルールは多数存在します。たとえば一般的なベンダーのログを構造化するFilebeatモジュールや、Logstashに含まれる拡張可能なgrokパターンライブラリなどがあります。コミュニティが開発・提供するプリビルトのパースルールも日々増えています。

自動生成のパースルール： カスタムログからフィールドを抽出するルールを定義する際、パースの方法を自動で提案するKibana Data Visualizerなどのツールが役立ちます。ログサンプルをコピーペーストしてgrokパターンを取得し、IngestノードやLogstashで使うことができます。

ログフォーマットの変更に対応する

schema on writeアプローチに関するよくある認識として、最後に「schema on writeアプローチではログフォーマットの変更の際に大変になる」というものを取り上げたいと思います。平たく言って、この認識は誤りです。ログを使用して単なる全文検索以上のインテリジェンスを取得するには、どのアプローチを使う場合でも誰かがログフォーマットの変更に対応する必要があります。インデックス時にログをgrokするIngestノードパイプラインを使用している場合でも、検索時に同じ処理を行うKibanaスクリプテッドフィールドを使用している場合でも、ログフォーマットが変更になればフィールドを抽出するロジックにも修正が必要です。Elasticが公開するFilebeatモジュールについて、Elasticはアップストリームのログベンダーが公開する新しいバージョンを確認し、互換性テスト済みモジュールを更新しています。

書き込み時に、ログ構造の変更に対応する方法は複数あります。

パースロジックを事前修正する： ログフォーマットの変更があらかじめわかっている場合は、並列な処理パイプラインを作成して両方のログバージョンをサポートできるようにし、移行の期間中はそれらを使用するようにします。通常、ログのフォーマットを社内で制御できる場合に用いる方法です。

パースのフェイルでは、ミニマルスキーマを書き出す： 事前に変更を把握できるケースばかりではありません。ログを外部で制御している場合、変更の事前通知がないこともあります。その場合、早いタイミングでログパイプラインから変更を把握することができます。grokパースがフェイルした場合、タイムスタンプとパースされていないメッセージのミニマルスキーマを書き出し、運用者にアラートを送信します。その時点で、新しいログフォーマット用にスクリプテッドフィールドを作成することが可能になります。これにより、分析ワークフローの障害を回避し、その後のパイプラインを修正することができます。さらに、パースロジックに障害が生じていた短い期間のために、フィールドの再インデキシングを検討します。

パースがフェイルしたイベントの書き出しを遅らせる： ミニマルスキーマを書き出す方法が使えない場合、パースロジックでエラーが生じている間はログ行の書き出しを行わないというやり方もあります。イベントを一時的に“dead letter queue”（Logstashですぐに使いはじめることができる機能です）に入れ、運用者にアラートを送ります。その後運用者がロジックを修正し、新しいパースパイプラインでdead letter queueのイベントを再実行するという方法です。分析には障害が起きますが、スクリプテッドフィールドや再インデックスを扱う必要がありません。

うまい喩えで学ぶ

この記事も長くなってきました。ここまで読んでくださった方に... ありがとうございます！さて、新しいコンセプトを学ぶとき"ぴったりの比喩"が役立つことがよくあります。最近、Elasticの同僚でセキュリティスペシャリストのネイル・デサリのスピーチに“schema on read”と“schema on write”に関する素晴らしい喩えがあったのでご紹介しましょう。

おわりに – 最適解はユースケース次第

冒頭でもご説明しましたが、一元的なロギングのデプロイで“schema on write” vs “schema on read”を考えるとき、「あらゆるユースケースににフィットする正解」を考える必要はありません。実際のところ、“schema on write”と“schema on read”の中間のようなデプロイも多くあります。たとえば一部のログは高度に構造化し、ほかの部分は最も基本的なスキーマ（@timestampとmessage）のままにする、といったことです。ログで何をするかや、構造化したクエリのスピードや効率をどの程度重視するか、あるいは事前に何も設定せずできるだけ早くディスクに書き出しはじめることにどの程度価値を見出すかによって最適な解は変わります。Elastic Stackはどちらのアプローチもサポートしています。

Kubernetes Operatorパターンに基づいた新しい制御プロダクト、Elastic Cloud on Kubernetes（ECK）がリリースされました。ECKを使って、KubernetesでElasticsearchを設定、管理、運用することができます。

Kubernetesはここ数年で、コンテナーとアプリケーション制御のデファクトスタンダードフレームワークとなっています。Elasticsearchコミュニティでもこのトレンドは例外ではありません。Elastic Cloud on Kubernetesはあらゆるユーザーの環境に適応するというElasticのポリシーを体現し、またユーザーが選んだプラットフォームでElasticプロダクトをデプロイ・運用する際の最高のソリューションとなります。

以前からElasticsearchとKibana向けのDockerオフィシャルイメージのリリースや、podやDaemonSetからログとメトリックを収集するためBeatsの変更など、ElasticとKubernetesの関わりは長く続いてきました。昨年12月にはCNCFへの参加とHelm Chartsのリリースもあり、ますますコミットメントを深めています。ですから、ElasticのユーザーにKubernetes環境でのデプロイ・運用を簡単にする取り組みやソリューションの提供は自然な流れでした。

Operatorにとどまらないメリット

ECKはKubernetes Operatorパターンを用いて開発されており、ユーザーのKubernetesクラスターにインストールして使用します。KubernetesでElasticsearchやKibanaのデプロイする手順をシンプル化するだけでなく、多くのメリットをもたらします。デプロイ後の運用では、次のようなタスクをスムーズに行うことが可能です。

• 複数のクラスターを管理、監視
• Elastic Stackの新しいバージョンへのアップグレード容易に
• クラスター容量のスケールアップ/スケールダウン
• クラスター設定の変更
• ローカルストレージ（ローカルストレージドライバーのElastic Local Volumeを含む）の動的なスケール
• 定期的なバックアップ

ECKは単なるKubernetes Operatorではありません。運用とクラスター管理タスクを自動化するだけでなく、Kubernetes上のElasticsearchのエクスペリエンス全体がスムーズになるよう設計されています。ECKの開発ビジョンは、Kubernetes上でSaaSのようにElasticのプロダクトやソリューションを提供することです。

デフォルトでセキュアに

ECKで立ち上げるすべてのElasticsearchクラスターはデフォルトで安全に保たれています。すなわち、作成された時点から通信の暗号化が有効で、デフォルトの強力なパスワードで保護されています。これにより、従来よりElastic Cloudで提供されるElasticsearch Serviceと一貫した、安全なエクスペリエンスを実現しています。

デフォルトでセキュアなエクスペリエンスをシームレスに提供することは、それほど簡単ではありませんでした。別のブログでもご紹介していますが、これはElastic Stackのセキュリティ機能の変更で可能になりました。長いので三行にまとめると：バージョン6.8および7.1より、TLS暗号化、ロールベースアクセス制御、ファイルとネイティブ認証を含むElasticsearchの主要なセキュリティ機能が無料でデフォルト搭載されます。

Canvas、Maps、Uptime

ECKでデプロイするすべてのクラスターは、ベーシックサブスクリプションに含まれる各種のパワフルな機能（フローズンインデックス、KibanaのSpaces、Canvas、Elastic Mapsほか）を搭載しています。さらにElastic LogsやElastic Infrastructureアプリを使用してKubernetesのログとインフラを監視することも可能です。Kubernetesでの完全なElastic Stackエクスペリエンスであり、現在はElasticだけが提供するサービスです。

Hot-Warm-Coldデプロイとカスタムトポロジー

Hot-Warm-Coldは、ロギングやメトリック、その他の時系列データのユースケースでパワーを発揮するElasticsearchクラスタートポロジーです。ストレージの保存期間とパフォーマンスの最適なバランスを、リーズナブルな方法で実現するアーキテクチャーパターンとして広く使用されています。ECKのユーザーはKubernetesでHot-Warm-Coldクラスターをデプロイし、インデックスライフサイクル管理（ILM）を使用してデータライフサイクルのポリシーを手軽に設定して、古くなったデータをノード間で移動させることができます。

たとえエクスペリエンスに圧縮アルゴリズムがなくても

ソフトウェアをデプロイするとき、Day1はそれほど大変ではありません。ところが、Day2となると話は別です。Kubernetesのように動的なオーケストレーションフレームワーク内でElasticsearchのようなステートフルなシステムの運用を最適化するには、多くの要素を考慮する必要があります。動的にスケール可能で、持続可能なローカルストレージを構築するには、一体どうすればよいでしょうか？そこでElasticはECKで使えるKubernetes向けの統合ストレージドライバー、"Elastic Local Volume"を開発しました。スケールダウンの前にノードを空にしておく、スケールアップに伴ってシャードの再バランス化を図るなど、多数のベストプラクティスを詰め込んでいます。

Elastic Cloud on Kubernetesは、何年にもわたるElasticsearchとElastic Cloud Enterpriseの開発や運用の知見とElasticsearch Serviceのフィードバックを活かして開発されました。KubernetesでElasticsearchやKibanaのデプロイを制御・運用する経験をすべてコード化したとも言えます。

設定変更でデータロスが生じないことや、スケールのダウンタイムがゼロになるなど、ECKの安全な運用のためにあらゆる手を尽くしています。

永久に無料提供

Elasticsearchの初期の頃から、私たちの目標は変わっていません。つまり、「パワフルな機能を無料で、デフォルトの配布で新しいユーザーに提供し、導入の瞬間から優れたエクスペリエンスにすること」です。ECKもこの例外ではありません。

デフォルトのECKは永久に無料で配布されます。オープン性と透明性を掲げるElasticは、ECKの全ソースコードを一般に公開しています。Elastic Licenseに基づき、cloud-on-k8s GitHub repositoryでライセンス提供されています。

エンタープライズサブスクリプション（有償）では、フィールドとドキュメントレベルのアクセス制御、Machine Learning、Graph分析をはじめ、高度な有償オプションを使ったクラスターのデプロイが可能になっています。今後、エンタープライズサブスクリプションにはさらに高度な制御機能の追加提供が予定されています。

オフィシャルGKEのサポートと、今後の追加予定

初回、そしてアルファ版となる今回のECKは、Google Kubernetes Engine（GKE）とvanilla Kubernetes version 1.11以降をサポートしています。ECKの今後のリリースでは、この他のバージョンのKubernetesへもサポートを拡大する予定です。

今すぐ使いはじめる

下のKubernetesクラスターを実行して、今すぐ使いはじめることができます。詳しい情報を記載したクイックスタートページもありますので、ご活用ください。

Elastic Stackの主要なセキュリティ機能は、無料になります。一例として、ネットワークトラフィックの暗号化、ユーザーの作成と管理、インデックスとクラスターレベルのアクセスを保護するロール定義、Spacesを使ってKibanaをより安全にする機能などをお使いいただけるようになります。Elasticコミュニティにも嬉しい進化です。無料となった機能について、Elasticは昨年コードを公開していました。今回あらためて無料提供を開始したことで、すべてのユーザーは全面的に安全なクラスターをストレスなく実行できるようになります。

主要なセキュリティ機能は、バージョン6.8.0および7.1.0以降で無料に

多くのユーザーにできる限り早くこの変更をお届けするためにも、Elasticは本日Elastic Stackバージョン6.8.0と7.1.0をリリースいたします。どちらのバージョンにも新機能は登場しません。今回はElastic Stackの主要なセキュリティ機能を無料で配布するためのリリースです。

• TLSによる通信暗号化
• ユーザー作成と管理にファイルおよびネイティブのレルム認証を使用可能
• クラスターAPIとインデックスに対するユーザーアクセスの管理にロールベースのアクセス制御を使用可能、またSpaces機能でKibanaのマルチテナンシーの安全性を向上

従来のバージョンで、これらの主要なセキュリティ機能はゴールドサブスクリプションのユーザーに提供されていました。今後はベーシックのサブスクリプションに含まれます。また、シングルサインオン認証/LDAP、Active Directory認証/フィールドおよびドキュメントレベルのセキュリティなど、より高度な機能は引き続き有償オプションの"セキュリティ"として提供される点にご注意ください。サブスクリプションに含まれる機能の一覧は、こちらの表でご確認いただけます。

オフィシャル＆マネージドのElasticsearchを提供するElastic CloudのElasticsearch Serviceでは今回も、リリース日に変更が反映されます。

Kubernetesで快適にデプロイ

上記の変更は、もう1つのリリースと関連があります。Elasticは、ElasticsearchとKibana向けのオフィシャルなKubernetes OperatorとしてElastic Cloud on Kubernetes（ECK）のアルファ版をリリースします。ECKは、KubernetesでElasticsearchのデプロイと運用を自動化し、シンプルに保つよう設計されています。

共有かつマルチテナントとなるKubernetesのような環境において特に、セキュリティはクラスターの運用に深く関わっています。Elastic Stackがデフォルトで主要なセキュリティ機能を配布することにより、ECKでローンチおよび管理されるすべてのクラスターを作成時から安全に保つことができ、管理者の負担も増えません。Elastic CloudのElasticsearch Serviceは従来よりデフォルトで安全なエクスペリエンスを提供してきました。ECKの仕様は、このエクスペリエンスを今後も継続して提供できるよう設計されています。

アップグレードしたり利用するには？

今回のリリースバージョンは、Elastic Stackの最新のバージョンをダウンロードしてインストールするか、お使いのクラスターを6.8または7.1にアップグレードして使いはじめることができます。

これから導入される方に役立つリソースもあります。併せてご覧ください： 

• Elasticsearch Securityの導入に関するブログ記事
• Elasticsearch Securityの導入向け紹介ビデオ

Elasticsearch Securityについてさらに深く学習したいという方には、期間限定で無料提供されているElasticsearchを安全に保つオンデマンドの基礎コースもお勧めです（通常価格200米国ドル）。

Elasticで可観測性担当製品リードを務めている私は、「可観測性」という言葉に対するいくつかの異なる反応を見てきました。未だに圧倒的に多い反応は、「可観測性って何ですか？」というものです。 また、最近よく聞くようになったのは、「「可観測性イニシアティブ」を始めたところなのですが、どう具体的に取り組めばいいのか未だに考えています」といった言葉です。 そしてようやく、協業させていただいたいくつかの組織が、「可観測性」は製品やサービスの設計および構築に欠かせないものであると捉えるようになっています。

この言葉はまだまだ理解が必要なため、Elasticでどのように「可観測性」を捉えているか、ソートリーダーであるお客様から学んだこと、Elastic Stackをオペレーションのユースケース向けに進化させるために製品の観点から考えていることについて、この記事で分かりやすく説明することが役立つのではないかと考えました。

「可観測性」とは

私たちが「可観測性」という言葉を発明したわけではありません。この言葉はユーザーの皆様から聞くようになりました。主にSite Reliability Engineering（SRE）コミュニティ内からです。この言葉の起源に関しては、Twitterのようなシリコンバレーの巨大企業からSREの企業へと広まったとする説がいくつかあります。影響力のあるGoogle SRE Bookでは、この言葉に触れてはいないものの、「可観測性」に関連する原理の多くを提示しています。

「可観測性」は、ベンダーがボックスに入れて提供するものです。つまり、構築するシステムの属性であり、使いやすさや高い可用性、安定性などに似ています。「観測可能な」システムの設計および構築の目標は、本番環境で実行したときに担当のオペレーターが、好ましくない振る舞い（サービスのダウンタイム、エラー、反応の遅延など）を検知し、根本原因を特定するための効果的な方法（詳細なイベントログ、リソース使用に関する細かい情報、アプリケーションのトレースなど）で実用的な情報を得られるようにすることです。 このような明確に思える目標の達成を阻む一般的な課題には、十分な情報を収集していないこと、あまりにも多くの情報を収集しているのにそれらを実用化していないこと、その情報へのアクセスが分断されていることなどが挙げられます。

最初のポイント、つまり好ましくない振る舞いの検知は通常、サービスレベル指標（SLI）およびサービスレベル目標（SLO）を設定することから始まります。 これらは観測性を認識している組織が本番環境のシステムを判断するための、社内における成功の尺度です。契約上の義務としてこれらの目標を満たす場合、SLI/SLOはサービスレベル契約（SLA）とも呼ばれることがあります。SLIの最も一般的な例は、システムのアップダイムです。99.9999%のSLOとして設定することがあります。システムのアップタイムは外部の顧客に提供する最も一般的なSLAでもあります。ただし、社内のSLI/SLOはよりきめ細かい場合があり、本番環境システムの振る舞いの最も重要な要因を監視およびそれらに関するアラートを通知することは、可観測性イニシアティブの基盤となります。可観測性のこの側面は、「監視」という言葉としても知られています。

2つめのポイント、つまり本番環境の問題を迅速かつ効率的にデバッグするためのきめ細かい情報をオペレーターに提供することについては、多くの動きや変革が見られます。よく話題に上っているのは、「可観測性の3つの柱」であるメトリック、ログ、アプリケーションのトレースですが、それと同時に認識されているのは、ツールの寄せ集めを使用してそのような細かいデータを単純に収集することは必ずしも実用的ではなく、多くの場合、費用対効果が低いということです。 

可観測性の「柱」

このデータ収集の側面について詳細に見ていきましょう。現在、私たちがよく見るのは、メトリックを1つめのシステム（通常は時系列データベース、またはリソース監視用のSaaSサービス）に収集し、ログを2つめのシステム（想像どおり、多くの場合はELKスタック）に収集し、リクエストレベルのトレースはアプリケーションを調整する3つめのツールを使用して提供するという方法です。サービスレベルの違反を示すアラートが発行されると、オペレーターはシステムに駆け寄り、できる限り最高の「回転椅子の範囲での統合」を実行します。つまり、1つめのブラウザーウィンドウでメトリックを確認し、それを別のウィンドウでログに手動で関連付け、必要な場合は3つめのウィンドウでトレースを引き出します。

このアプローチにはいくつかの欠点があります。まず、同じストーリーを伝えているさまざまなデータソースを手動で関連付ける作業は、サービスの低下時または停止時の貴重な時間を浪費します。2つめは、3つの異なるオペレーション用データソースの維持にかかる運用コストが負担となります。ライセンスコスト、異種の運用ツールに関する個別の管理者の必要性、各データソースの一貫性のない機械学習機能、アラート用のさまざまなセマンティックを考える労力が必要になり、私が話したことのある組織はすべて、これらの課題に悩まされています。

そこで認識が高まってきているのが、これらの情報のすべてを、直感的なユーザーインターフェースで自動的に関連付ける機能を持った単一の運用ストアに格納することの重要性です。私たちのお客様にとっての理想は、アプリケーションからの長文のデータ、計装から生じるトレースデータ、時系列のメトリックで示されるリソース使用状況データなど、サポートしているサービスに関連するすべてのデータを、統一された方法でオペレーターに提供することです。要件としてお客様が強調しているのは、ソースに関係なくこれらのデータに均一かつその場ですぐにアクセスし、検索からフィルタリング、集計、ビジュアライゼーションまでできることです。メトリックから開始して、ログの詳細確認からトレースまで、コンテキストを切り替えることなく数回のクリックでできれば迅速に調査できます。同様に、構造化されたログから数値を抽出することはメトリックに驚くほど似ており、横に並べて視覚化することは運用の観点から見て大きな価値があります。

前述したように、単純にデータを収集するだけではあまりにも多くの情報をディスクに格納することになり、インシデントが発生したときに十分な実用的情報を持っていないことになる場合があります。ますます期待されるようになっているのは、運用データを収集しているシステムが自動的に、時系列のパターンと比較して「興味深い」イベント、トレース、異常を提供してくれることです。これによってオペレーターは、根本原因に焦点を当てながらより迅速に問題を調査できるようになります。これらの異常検知機能は、「可観測性の4つめの柱」と呼ばれることもあります。アップタイムデータ、リソースの使用状況、ログパターンにおける例外、最も関連性の高いトレースなどにわたる異常を検知することは、可観測性チームが出している新しい要件です。

可観測性... そしてELKスタック

では、可観測性とElastic Stack（運用サークル内ではELK Stackと呼ばれています）はどう関係しているのでしょうか？

ELK Stackは、運用システムからのログを一元管理する事実上の方法として広く知られています。その前提は、Elasticsearch（「検索エンジン」）はフリーテキスト検索のためにテキストベースのログを格納する最適な場所である、というものです。実際に、「error」（エラー）という語句を検索、または良く知られているタグを基にしてログをフィルタリングするために、テキストベースのログを検索することは非常に強力な方法であり、しばしばほとんどのユーザーがこれを開始点とします。

しかし、ほとんどのELK Stackユーザーは知っていますが、 データストアとしてのElasticsearchは、転置インデックス以外にも、効率的な全文検索およびシンプルなフィルタリング機能のための多くの方法を提供します。また、ELK Stackには高密度の時系列数値データの格納と運用に最適化された列ストアもあります。列ストアは、文字列と数値の両方について、解析ログから抽出された構造データを格納するのに使用されます。実際、効率的な数値の格納と取得を実現するために、最初にElasticsearchの最適化を推し進めたのは、ログをメトリックに変換するユースケースに対応するためでした。

そのうち、ユーザーは時系列数値データを直接Elasticsearchに投入し始めたため、Elasticsearchはレガシーの時系列データベースに取って代わりました。このニーズに後押しされ、Elasticは最近、メトリックの自動収集のためのMetricbeatを導入しました。これは自動ロールアップのコンセプトを備えており、データストアおよびUIの両方に関するメトリック固有の機能もあります。結果として、さらに多くのユーザーがログのためにELK Stackを採用するようになっており、これらのユーザーはリソース使用状況などのメトリックデータをElastic Stackに投入し始めています。Elasticsearchが魅力的である理由は、前述した運用コストの削減に加えて、数値の集計の対象となるフィールドのカーディナリティに制約がないことです（これは既存の多くの時系列データベースに関してよく聞かれる不満です）。

メトリックと同様、アップタイムデータはログとともに重要度の高いデータタイプとなっており、監視機能によるSLO/SLIアラートの重要なソースとなっています。アップタイムデータにより、通常はユーザーが影響を感じる前に、サービス、API、Webサイトのパフォーマンスの低下に関する情報を提供できます。さらなるメリットとして、アップタイムデータは格納要件の観点からは非常に小さいため、少しの追加コストで大きな価値をもたらします。

昨年、Elasticはスタックにアプリケーショントレーシングおよび分散トレーシングを追加するElastic APMも導入しました。すでにいくつかのオープンソースプロジェクトや有名なAPMベンダーがElasticsearchを使用してデータを格納、検索していたため、これは私たちにとって自然な進化でした。従来のAPMツールの現状は、APMトレースデータをログおよびメトリックとは別に維持し、運用データのサイロを永続させるものです。Elastic APMは、サポートされた言語およびフレームワークからトレースデータを収集する一連のエージェントを提供し、OpenTracingをサポートします。このトレースデータは自動的に、メトリックおよびログと関連付けられます。

これらすべてのデータ入力の共通のスレッドは、それぞれがElasticsearchの別のインデックスです。これらすべてのデータに実行する集計、Kibanaでの可視化方法、各データソースへのアラートおよび機械学習の適用方法について、制約はありません。その実際の操作については こちらのビデオをご覧ください。

観測可能なKubernetesとElastic Stack

コンテナーのオーケストレーションにKubernetesを採用しているユーザーグループのコミュニティでは、可観測性の概念が会話のトピックとして注目されています。これらの「クラウドネイティブ」（Cloud Native Computing Foundation（CNCF）から有名になった用語）のユーザーたちは、独自の課題に直面しています。Kubernetesによるコンテナーオーケストレーションプラットフォーム上に構築（またはそのプラットフォームへと移行）されたアプリケーションとサービスを大規模に一元化するということと、モノリシックなアプリケーションを「マイクロサービス」に分割するというトレンドに直面しているのです。これまで、インフラストラクチャー上で実行されているアプリケーションへの必要な可視性を提供するのに使用していたツールや方法は、今や役に立たなくなりました。

Kubernetesの可観測性に関してはそれだけで別の記事が必要ですが、その詳細については観測可能なKubernetesに関するウェビナーおよびElastic APMでの分散トレーシングに関するブログ記事をご覧ください。

次のステップ

このような記事の場合は、参照できるいくつかのリソースをご紹介しておくのが適切でしょう。

可観測性のベストプラクティスの詳細を学ぶには、先に触れたGoogle SRE Bookから開始されることをお勧めします。本番環境の重要なアプリケーションを完璧に運用することに、事業の存続がかかっている企業もあります。それらの企業によるブログ記事は非常に示唆に富んでいます。たとえば、Salesforceのエンジニアよって最近投稿されたブログは、可観測性の状態を繰り返し改善するための実用的で役立つガイドとなっています。

観測に関する取り組みにElastic Stackの機能を試す場合は、Elastic Cloud上で最新バージョンのElasticsearch Serviceを実行するか（最終的にセルフマネージドとしてデプロイした場合でも優れたサンドボックスとなります）、またはElastic Stackのコンポーネントをローカルにダウンロードしてインストールしてください。一般的な可観測性ワークフロー専用に構築されたKibanaの新しいログ、インフラストラクチャー監視、APM、およびアップタイム（6.7で搭載）UIをご確認ください。また、ご質問に関しては遠慮なくディスカッションフォーラムにお知らせください。私たちがお手伝いいたします。

Wordpressは世界でもっとも有名なオープンソースのコンテンツ管理システムです。世界の上位1,000万のWebサイトのほぼ3分の1で使用されています。どうしてそこまでになったのでしょうか？それは、インストール、使用、保守が簡単だからです。結果として、Wordpressには何万もの便利なプラグインや堅牢なテーマを提供する活発なコミュニティとエコシステムができています。そしてうれしいことに、この度、Elastic Site Search Wordpressプラグインが利用できるようになりました。これを使用すれば、どなたでもWebサイトで優れた検索エクスペリエンスを実現できます。

Wordpressでの活用

Wordpressにはデフォルトで検索機能があり、サイドバー、ヘッダー、フッターに追加したり、またはウィジェットとして追加できます。Site Search WordpressプラグインはデフォルトのWordpress検索エクスペリエンスを置き換えるものであり、オープンソースの優れた検索エンジンであるElasticsearchによって実現する堅牢で設定機能の豊富な検索エクスペリエンスを提供します。

いくつかの手順を実行するだけで使い始めることができます。すでに有効なアカウントをお持ちの場合は、Site SearchダッシュボードからAPIキーを取得します。お持ちでない場合は、14日間の無料トライアルに登録し、一部の機能をお試しください。

Wordpress管理画面にログインし、Pluginsをクリックします。

Add Newをクリックし、Site Search Plugin for WordPressプラグインを見つけます。

インストールすると、Site Searchが表示されます。

APIキーが要求された場合は入力し、Authorize*をクリックします。

APIキーを入力することで、プラグインが自動的に必要な作業を実行します。最初に作成されるのは検索エンジンです（短縮してエンジンと呼ばれることもあります）。エンジンの名前を入力し、13言語から選択します。

プラグインがSite Searchアカウントとの同期を実行します。これで、作成済みのすべてのコンテンツが検索エンジンにインデックスされることになります。インデックスとはコンテンツをドキュメントに変換することであり、これによってきわめて便利で迅速に検索と分析ができるようになります。

同期を開始するために、Synchronizeをクリックします。

同期が完了したことが表示されます。

この後に実行する調整はすべて自動的に同期されます。コンテンツを追加、削除、編集すると更新されます。Wordpressで変更を実行すると、Site Search内に反映されます。

同期が完了すると、楽しい作業が待っています。

Site Searchでは、設定する必要なくそのままの状態で、誤字の許容機能、語句の部分一致、同義語、フレーズ一致、バイグラム一致、ステミングなどの最先端の高度な機能によって、洗練された検索関連性を提供します。

この機能が特に便利なのは、洗練されたSite Search UIでチューニングを実行できることです。

次のことが可能です。

• クエリのためのファセットの作成
• 結果セットの順番を選択する結果ランキングの設定
• 自分独自の同義語の作成
• タイトル、説明、またはその他のフィールドの一致率に対する重みづけおよびスケール の管理

最後に重要なのは、Site Searchは豊富な検索分析機能を備えていることです。分析がキャプチャおよび同期され、実用的なインサイトとなります。これらのインサイトを活用することで、望みどおりの検索エクスペリエンスを実現するための関連性ツールを適用することができます。

まとめ

Elastic Site Search Wordpressプラグインは、デフォルトのWordpress検索エクスペリエンスからの大きな変化を実現します。オンラインストア、出版、ナレッジベース、パンフレットスタイルのWebサイトなど、どのようなWebサイトを作成するかに関係なく、ワールドクラスの検索エクスペリエンスを実現できます。コードを変更する必要はありません。

14日間の無料トライアルでElastic Site Searchの使用を開始しましょう。

まずはコンテキストの説明

ハードウェアを最大限活用する場合によく使用されるのが、Hot-Warmアーキテクチャーです。これは特に、ログ、メトリック、APMデータなど、時間ベースのデータが存在する場合に便利です。このアーキテクチャーがセットアップされるのは、、それらのデータが読み取り専用（投入後）であり、インデックスが時間ベース（またはサイズベース）の可能性がある場合がほとんどです。このため、希望する保持期間に基づいて簡単にデータを削除することが可能です。このアーキテクチャーでは、Elasticsearchノードを「Hot」と「Warm」の2つのタイプに分けます。

Hotノードは、最も直近のデータを保持しているため、すべてのインデックス負荷を処理します。通常、最近のデータは最も頻繁にクエリされるため、Hotノードはクラスター内で最も強力なノード（高速ストレージ、高メモリ、高CPU）とします。そのような機能は高価なため、あまり頻繁にクエリされない古いデータを格納することは合理的ではありません。

一方、Warmノードは、よりコスト効果の高い方法による長期保存を目的としたものです。Warmノードに格納されるのはあまり頻繁にクエリされない可能性が高いデータであるため、クラスター内のデータは計画されている保持期間に基づいてHotノードからWarmノードへと移動させることになります（シャードの割り当てのフィルターによって可能になります）。Warmノードに移動してもそのデータはオンラインでのクエリが可能です。

Elastic Stack 6.3以降では、Hot-Warmアーキテクチャーを強化する新機能を構築しており、時間ベースのデータに関する作業が簡素化されています。

ストレージを節約するためにバージョン6.3で初めて導入されたのが、データのロールアップです。時系列のデータでは、直近のデータに関してきめ細かい詳細情報が必要になります。しかし、それが履歴データに必要になることはほぼありません。通常、履歴データはデータセット全体として見るからです。ここで必要になるのがロールアップです。バージョン6.5からはKibanaでロールアップデータを作成、管理、可視化することができるようになっています。

その後すぐに、ソースのみのスナップショットの機能が追加されました。この最小限のスナップショットにより、スナップショットのストレージの大幅な削減が可能になります。ただし、復元してクエリを実行する場合にはデータの再インデックスが必要になります。これはバージョン6.5以降で利用できます。

バージョン6.6では2つの強力な機能、インデックスライフサイクル管理（ILM）とフローズンインデックスがリリースされました。

ILMは、長期的なインデックス管理を自動化する手段です。HotノードからWarmノードへのインデックスの移動が簡素化され、インデックスが古くなった場合に削除されるように、または自動的にインデックスが1つのセグメントに強制的にマージされるように設定できます。

ここからはフローズンインデックスについて説明します。

インデックスを凍結する理由

「古い」データの最大の難点の1つは、その古さに関係なく、インデックスによってかなりのメモリ領域が消費されることです。それらのデータをColdノードに移動しても、ヒープが使用されます。

解決策となる可能性があるのは、インデックスを閉じることです。インデックスを閉じるとメモリは不要になりますが、検索を実行するためにはそのインデックスを再び開くことが必要になります。インデックスを再び開くと運用コストが発生し、また、そのインデックスが閉じられる前に使用していたヒープが必要になります。

各ノードには、ノードごとに使用できるストレージ容量を制限する、メモリ（ヒープ）対ストレージの比率があります。その比率は、メモリ負荷の高いシナリオに適した1対8（メモリ対データ）から、メモリ要求の低いユースケースに適した1対100に近いものまで、さまざまです。

ここで役立つのがフローズンインデックスです。インデックスを開いたままにしても（つまり検索可能な状態を維持しても）、ヒープを消費しないとしたらどうでしょうか？検索が遅くなる可能性があるという欠点を承知の上で、フローズンインデックスを保持するデータノードにさらにストレージを追加して、1対100の比率を破ることも可能です。

インデックスは、凍結すると読み取り専用となり、その一時的なデータ構造はメモリからドロップします。その代わり、フローズンインデックスにクエリを実行する場合は、そのデータ構造をメモリにロードする必要が生じます。フローズンインデックスの検索は必ずしも遅くなるとは限りません。Luceneはファイルシステムのキャッシュに大きく依存します。このキャッシュに、インデックスのかなりの部分をメモリに保持するのに十分な容量がある場合には、検索の速度はシャード使用時の速度と同程度になります。ただし、フローズンインデックスにはまだ制約があります。現状では、各ノードにおいて一度に1つのフローズンシャードにしか検索を実行できません。この点において、凍結されていないインデックスと比較すると、検索には時間がかかる可能性があります。

フローズンインデックス関連の仕組み

フローズンインデックスの検索には、専用のsearch_throttledスレッドプールが使用されます。シングルスレッド（デフォルト）によって、フローズンインデックスが一度に1つずつメモリにロードされます。同時検索が発生すると、それらはキューに入れられます。これは、ノードのメモリ不足を防止するための追加の保護機能です。

要するに、Hot-Warmアーキテクチャーでは、インデックスをHotノードからWarmノードへと移し、それらをアーカイブする前または削除する前に凍結させることができるようになっているのです。これによってハードウェア要件を軽減することができます。

フローズンインデックスが利用できるようになる以前には、データのスナップショットを取り、そのデータをアーカイブしてインフラコストを削減していましたが、これには相当なオペレーションコストが発生します。再び検索が必要になった場合は、それらのデータを復元する必要がありました。現在では、大きなメモリオーバーヘッドを発生させることなく、履歴データを検索可能な状態で維持することができます。また、フローズンインデックスに再度書き込みを行う必要がある場合は、それを解凍するだけで書き込めます。

Elasticsearchインデックスを凍結させる方法

フローズンインデックスはクラスター内で簡単に扱うことができます。ここからはFreezeインデックスAPIの使い方とフローズンインデックスの検索方法について見ていきましょう。

まず、テスト用のインデックスにサンプルデータを作成することから開始します。

POST /sampledata/_doc
{
    "name":"Jane",
    "lastname":"Doe"
}
POST /sampledata/_doc
{
    "name":"John",
    "lastname":"Doe"
}

そして、データが投入されたことを確認します。2つのヒット結果が返されるはずです。

GET /sampledata/_search

ベストプラクティスとして推奨されるのは、インデックスを凍結する前にまずforce_mergeを実行することです。これにより、ディスク上の各シャードには1つのセグメントのみが存在していることを保証できます。また、圧縮効率が高まり、フローズンインデックスに対してアグリゲーションまたはソート検索のリクエストを実行するときに必要なデータ構造が簡素化されます。複数のセグメントがあるフローズンインデックスに検索を実行すると、最大で数百倍ものパフォーマンスオーバーヘッドが生じる可能性があります。

POST /sampledata/_forcemerge?max_num_segments=1

次に、FreezeインデックスAPIエンドポイントを使用してインデックスを凍結させます。

POST /sampledata/_freeze

フローズンインデックスの検索

インデックスが凍結され、フローズンインデックスとなりました。こうなると通常の検索は実行できません。ノードごとのメモリ消費が制限されており、フローズンインデックスには制約があるからです。 誤ってフローズンインデックスを検索対象としてしまうこともあるため、リクエストに明示的に ignore_throttled=falseを追加することで、予想外のスローダウンを避けることができます。

GET /sampledata/_search?ignore_throttled=false
{
 "query": {
   "match": {
     "name": "jane"
   }
 }
}

ここで、下記のリクエストを実行することで、新しいインデックスのステータスをチェックできます。

GET _cat/indices/sampledata?v&h=health,status,index,pri,rep,docs.count,store.size

下記に類似した結果が返されます。インデックスのステータスが「open」となっています。

health status index      pri rep docs.count store.size
green  open   sampledata   5   1          2     17.8kb

先に述べたとおり、メモリ不足にならないようにクラスターを保護する必要があるため、検索のためにノードに同時にロードできるフローズンインデックスの数は制限されています。search_throttledスレッドプール内のスレッド数はデフォルトで1、キューの数はデフォルトで100です。つまり、2つ以上のリクエストを実行すると、最大100までキューに入れられることになります。スレッドプールのステータスは監視できます。以下のリクエストで、キューや拒否についてチェックできます。

GET _cat/thread_pool/search_throttled?v&h=node_name,name,active,rejected,queue,completed&s=node_name

下記に類似した結果が返されるはずです。

node_name             name             active rejected queue completed
instance-0000000000   search_throttled      0        0     0        25
instance-0000000001   search_throttled      0        0     0        22
instance-0000000002   search_throttled      0        0     0         0

フローズンインデックスに関するプロセスは遅くなる可能性がありますが、事前にきわめて効率的にフィルタリングすることが可能です。リクエストのパラメーターの pre_filter_shard_sizeを1にすることも推奨されます。

GET /sampledata/_search?ignore_throttled=false&pre_filter_shard_size=1
{
 "query": {
   "match": {
     "name": "jane"
   }
 }
}

こうすることで、クエリに相当なオーバーヘッドが生じることはなく、通常のシナリオと同様の作業ができます。たとえば、時系列のインデックスで特定の日付範囲を検索する場合は、すべてのシャードが一致するわけではありません。

凍結されたElasticsearchインデックスに書き込む方法

すでに凍結されているインデックスに書き込もうとするとどうなるでしょうか？試してみましょう。

POST /sampledata/_doc
{
  "name":"Janie",
  "lastname":"Doe"
}

どうなったでしょうか？フローズンインデックスは読み取り専用のため、書き込みはブロックされます。これはインデックス設定で確認できます。

GET /sampledata/_settings?flat_settings=true

以下が返されます。

{
 "sampledata" : {
   "settings" : {
     "index.blocks.write" : "true",
     "index.frozen" : "true",
     ....
   }
 }
}

UnfreezeインデックスAPIを使用して、インデックスの解凍エンドポイントを呼び出す必要があります。

POST /sampledata/_unfreeze

ここで、3つ目のドキュメントを作成して検索することができます。

POST /sampledata/_doc
{
 "name":"Janie",
 "lastname":"Doe"
}
GET /sampledata/_search
{
 "query": {
   "match": {
     "name": "janie"
   }
 }
}

解凍は、例外的な状況においてのみ実行するべきです。また、インデックスを再度凍結する前には必ず「force_merge」を実行して、最適なパフォーマンスを確保するようにしてください。

Kibanaでのフローズンインデックスの使用

まずは、サンプルのフライトデータをロードする必要があります。

「Sample flight data」の［Add］ボタンをクリックします。

［View data］ボタンをクリックすると、ロードされたデータを見ることができるはずです。下記に類似したダッシュボードが表示されます。

これでインデックスの凍結をテストできます。

POST /kibana_sample_data_flights/_forcemerge?max_num_segments=1
POST /kibana_sample_data_flights/_freeze

ダッシュボードに戻ると、データが「消えた」ように見えます。

フローズンインデックスに対する検索を許可するようにKibanaに指示する必要があります。これはデフォルトでは無効化されています。

［Kibana Management］にアクセスし、［Advanced Settings］を選択します。［Search］セクションで「Search in frozen indices」が無効化されています。［On］にして、この変更を保存します。

フライトのダッシュボードでは再度、そのデータが表示されます。

まとめ

フローズンインデックスは、Hot-Warmアーキテクチャーでの非常に強力なツールです。これによって、オンライン検索ができる状態を維持しながら保持期間の延長に対応できる、コスト効果の高い解決策が実現します。フローズンインデックスの最適なサイジングと検索レイテンシを知るために、ハードウェアおよびデータを使用して検索レイテンシをテストすることをお勧めします。

FreezeインデックスAPIの詳細については、Elasticsearchのドキュメントをご確認ください。そしていつものとおり、ご質問がある場合はDiscussフォーラムをご活用ください。フローズンインデックスのご利用をお勧めします。

Elastic Stackのすべての機能を活用

ソリューションアーキテクトである私は、ElasticデプロイメントをAmazon Elasticsearch Service（AWS ES）からElasticsearch Serviceに移行する方法についてよく尋ねられます。 その質問の主な理由は、Elasticsearch Serviceに移行すると、Amazonでは利用できないElasticの機能、操作に関する専門知識、およびサポートのすべてを活用できるからです。このプラクティショナー向けのガイドでは、よく言われている「リフト&シフト」方式でElasticのElasticsearch Serviceに移行する方法を説明します。

無料の14日間のトライアルでデプロイメントを作成し、Elasticsearch Serviceの利用を開始することができます。クラウドプロバイダー（AWSまたはGCP）を選択し、Elasticを実行するデプロイメントのリージョンを選択します。 AWSユーザーは、AWSマーケットプレイスから直接、Elasticsearch Serviceを追加できます（AWSからの請求に含まれます）。

これにより、オープンソースのディストリビューションで利用可能な機能以外にも、たとえばCanvas、APM、教師なしの機械学習、フローズンインデックス、SQL、セキュリティ（基本的なIAMポリシーおよび境界のみのセキュリティ以上の機能）、および導入テンプレートなど、Elasticsearch Service on Elastic Cloud独自の多数の機能を利用できます。このような独自の機能は今後も常時追加されていきます。AWS ESとの違いについては、AWS Elasticsearch比較ページを定期的にご確認ください。

AWS ElasticsearchからElasticsearch Service on Elastic Cloudへの移行

この記事は、AWS ESからElasticsearch Service on Elastic Cloudへの移行に関するかなり技術的なガイドであり、理解するには多少のプログラミング経験が必要になります。AWS ESクラスターは一般的にVPCにプロビジョニングされますが、公開されているエンドポイントにプロビジョニングすることも可能です。この記事では、両方のシナリオに対応できるようにするためにPython AWS SDKを使用します。AWS SDKが含まれている言語（Java、Ruby、Goなど）ならどれでも使用できますが、ここではPythonの例のみを提示します。

このガイドは次の2つのパートで構成されています。

• パート1：AWS ESクラスターのスナップショットをS3に保存
• パート2：S3からElastic Cloudアカウントに復元

注：すでにAWS ESクラスターのスナップショットを手動で取ってS3に保存している場合は、パート2に進んでください。

開始する前に、次に説明するIAMセキュリティの手順について理解しておくことが重要です。まず、AWS ESクラスターのスナップショットをS3に保存するためには、AWS ESクラスターにプライベートのS3バケットへの書き込み許可が必要です。これには、必要な権限を持つIAMロールおよびポリシーが必要です。また、IAMユーザー（作成していない場合は作成する必要があります）にIAMポリシーをアタッチすることが必要です。IAMユーザーは、スクリプトでAWS ESクラスターと通信するために使用され、またElasticが管理するデプロイメントでS3バケットからスナップショットを読み取るために使用されます。

パート1 - スナップショットをS3に保存

このガイドの最初パートでは、AWS ESクラスターのスナップショットをS3に保存するために、IAMロール、IAMポリシー、およびIAMユーザーを設定する手順について説明します。このプロセスについてのAWSのドキュメントはこちらです：Amazon Elasticsearch Serviceインデックススナップショットの使用。これは不明点が生じたときの参照資料として役立ちます。

また、手順を進めていく中で使用するいくつかの変数を書き留めておく必要があります。下記の表をコピーし、メモ帳などのファイルにペーストして、このガイドを読み進めながら参照できるようにしてください。そうすることで、移行に固有の値を簡単に入力できます。

SNAPSHOT_REPOおよびSNAPSHOT_NAMEの値を変更するか、または提示してある例（「my-snapshot-repo」および「my-snapshot」）を使用することができます。

ステップ1 - AWS ESの情報を取得する

AWS ESクラスターのスナップショットをS3に保存するためには、AWS ESクラスターに関する基本情報がいくつか必要です。

1. AWSコンソールでElasticsearch Serviceを選択します
2. スナップショットを取るクラスターのドメインを選択します
3. 「ドメインARN」の値をメモ帳ファイルにコピーします（DOMAIN_ARN）
4. 「エンドポイント」URLの値をメモ帳ファイルにコピーします（ES_ENDPOINT）
5. AWS ESクラスターのAWSリージョン（例：us-east-1）をメモしておきます（ES_REGION）

これらの情報は後でIAMポリシーを作成する際、およびクラスターにコマンドを発行する際に使用します。

ステップ2 - AWS S3バケットを作成する

スナップショットを保存するためにS3バケットを作成する必要があります。

重要： S3バケットはAWS ESクラスターと同じリージョンである必要があります。そのS3バケットから、Elasticが管理するデプロイメント（任意のリージョン）またはクラウドプロバイダー（AWSまたはGCP）への復元が可能です。

1. AWSコンソールでS3サービスを選択します
2. プライベートのS3バケットを作成します
   注： デフォルトのままにすると、バケットはプライベートとなり、安全です
3. バケット名をメモ帳ファイルにコピーします（S3_BUCKET_NAME）
4. バケットのリージョンをメモ帳ファイルにコピーします（S3_REGION_NAME）

これらの情報は、スナップショットリポジトリをElasticsearchに登録する際に使用します。

ステップ3 - IAMロールを作成する

次に、スナップショットをS3に保存する権限をAmazon Elasticsearch Serviceに委任するロールを作成します。

1. AWSコンソールでIAMサービスを選択します
2. ［Roles］を選択します
3. ［Create role］を選択します
4. この新しいロールを使用するサービスとして［EC2］を選択します（後で変更します）
5. ［Next: Permissions］を選択します
6. ここではロールのポリシーを空のままにします
7. ［Next: Tags］を選択します
8. ［Next: Review］を選択します
9. ロールの名前をTheSnapshotRoleにします
10. ［Create role］を選択します
11. ロールのリストから、今作成したロールのTheSnapshotRoleを選択します
12. ［Trust relationships］を選択します
13. ［Edit trust relationship］を選択します
14. 下記の内容をコピーして、信頼関係にペーストします（該当箇所を下記の内容に置き換えます）
    
    

    {
     "Version":"2012-10-17",
      "Statement": [{
        "Effect":"Allow",
        "Principal": {
          "Service": "es.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }]
    }
    

15. ［Update Trust Policy］を選択します
16. ［Permissions］を選択します
17. ［Add inline policy］を選択します
18. ［JSON］タブを選択します
19. 下記のJSONをコピー&ペーストします（該当箇所を下記の内容に置き換えます）
20. S3_BUCKET_NAMEを正しい値に置き換えます（2か所）
    
    

    {
      "Version":"2012-10-17",
      "Statement": [{
          "Action": [
            "s3:ListBucket"
          ],
          "Effect":"Allow",
          "Resource": [
            "arn:aws:s3:::S3_BUCKET_NAME"
          ]
        },
        {
          "Action": [
            "s3:GetObject",
            "s3:PutObject",
            "s3:DeleteObject"
          ],
          "Effect":"Allow",
          "Resource": [
            "arn:aws:s3:::S3_BUCKET_NAME/*"
          ]
        }
      ]
    }   

21. ［Review policy］を選択します
22. ポリシーの名前をTheSnapshotS3Policyにします
23. ［Create policy］を選択します
24. 「ロールARN」の値をメモ帳ファイルにコピーします（ROLE_ARN）

IAMロールと、S3バケットへの書き込みと読み取りが可能なインラインポリシーを作成しました。

ステップ4 - IAMポリシーを作成する

スナップショットリポジトリを登録するには、上記のロールを引き受ける権限を持つ新しいIAMポリシーを作成する必要があります。

1. AWSコンソールでIAMサービスを選択します
2. ［Policies］を選択します
3. ［Create policy］を選択します
4. ［JSON］タブを選択します
5. 下記のJSONをコピー&ペーストします（該当箇所を下記の内容に置き換えます）
6. ROLE_ARNを正しい値に置き換えます
7. DOMAIN_ARNを正しい値に置き換えます
8. S3_BUCKET_NAMEを正しい値に置き換えます（2か所）
   
   

   {
     "Version":"2012-10-17",
     "Statement": [
       {
         "Effect":"Allow",
         "Action": "iam:PassRole",
         "Resource":"ROLE_ARN"
       },
       {
         "Effect":"Allow",
         "Action": "es:ESHttpPut",
         "Resource":"DOMAIN_ARN/*"
       }
     ]
   }
   

9. ［Review policy］を選択します
10. ポリシーの名前をTheSnapshotPolicyにします
11. ［Create policy］を選択します

IAMポリシーを作成しました。これでIAMロールはAWS ESドメインと通信できます。

ステップ5 - IAMユーザーを作成する

まだIAMユーザーを作成していない場合は作成して、プライベートのS3バケットへのアクセス権を付与します。すでにIAMユーザーが存在する場合は、それに以下のIAMポリシーをアタッチすることができます。

1. AWSコンソールでIAMサービスを選択します
2. ［Users］を選択します
3. ［Add user］を選択します
4. ユーザーの名前をTheSnapshotUserにします
5. ［Programmatic access］ボックスにチェックマークを入れます
6. ［Next: Permissions］を選択します
7. ［Attach existing policies directly］ボックスを選択します
8. 「TheSnapshot」と入力してポリシーをフィルターします
9. ポリシー「TheSnapshotPolicy」の横のチェックボックスを選択します
10. ［Next: Tags］を選択します
11. ［Next: Review］を選択します
12. ［Create user］を選択します
13. 「Access key ID」の値をメモ帳ファイルにコピーします（ACCESS_KEY）
14. ［Secret access key］の下の［Show］を選択します
15. 「Secret access key」の値をメモ帳ファイルにコピーします（SECRET_KEY）
16. ［Close］を選択します
17. ユーザーのリストから、今作成したロールのTheSnapshotUserを選択します
18. ［Add inline policy］を選択します
19. ［JSON］タブを選択します
20. 下記のJSONをコピー&ペーストします（該当箇所を下記の内容に置き換えます）
21. S3_BUCKET_NAMEを正しい値に置き換えます（2か所）
    
    

    {
      "Version":"2012-10-17",
      "Statement": [{
          "Action": [
            "s3:ListBucket"
          ],
          "Effect":"Allow",
          "Resource": [
            "arn:aws:s3:::S3_BUCKET_NAME"
          ]
        },
        {
          "Action": [
            "s3:GetObject",
            "s3:PutObject",
            "s3:DeleteObject"
          ],
          "Effect":"Allow",
          "Resource": [
            "arn:aws:s3:::S3_BUCKET_NAME/*"
          ]
        }
      ]
    }
    

22. ［Review policy］を選択します
23. ポリシーの名前をTheSnapshotUserS3Policyにします
24. ［Create policy］を選択します

IAMユーザーを作成しました。これによって、手動でスナップショットを取り、そのスナップショットから読み取ることが可能になります。

ステップ6 - Python AWS SDKを設定する

手動でスナップショットを取る前に、デプロイメントにスナップショットリポジトリを登録する必要があります。そのためには、AWS ESクラスターに署名済みリクエストを送信する必要があります。その最も簡単な方法の1つは、Python AWS SDKを使用する方法です。別のAWS SDK（Java、Ruby、Goなど）を使用することもできますが、下記の例ではPython AWS SDKを使用します。

PythonのパッケージインストーラーのPIPを使用してインストールします（pip3）。これを実行するにはPython v3がインストールされている必要があります。Python v3をインストールしていない場合は、pip3をインストールするだけでPython v3がインストールされます。Python v3はpip3に依存しているため、オペレーティングシステムのパッケージマネージャーが自動的にPython v3をインストールします。問題が発生した場合は、Pythonのインストールに関するドキュメントを参照してください。

pip3のインストール

pip3をRed Hatとその派生物にインストールするには、yumを使用します。

$ sudo yum -y install python3-pip

または、Fedoraディストリビューションの一部ではpip3パッケージの記述が異なります。

$ sudo yum -y install python36-pip

どちらのパッケージ名を使用してもインストールできない場合は、次のようにしてパッケージ名を検索することができます。

$ yum search pip

Ubuntuなど、Debianの派生物の場合は、apt-getを使用します。

$ sudo apt-get -y install python3-pip

Python AWS SDKのインストール

pip3のインストールが完了したら、 boto3という名前のPython AWS SDKをインストールできます。

$ pip3 install --user boto3 requests_aws4auth
Collecting boto3
...
Successfully installed boto3-1.9.106 requests-aws4auth-0.9 ...

注： --userフラグを指定した場合、rootアクセスは必要ありません。

AWS credentialsを保持するために、~/.awsディレクトリを作成する必要があります。下記のコマンドを実行してディレクトリを作成します。

$ mkdir ~/.aws

お好みのエディターでcredentialsという名前のファイルを作成します。シンプルにするためにnanoを使用します。

$ nano ~/.aws/credentials

次の内容をファイルにコピー&ペーストし、大文字の2つの変数を置き換えます。

[default]
aws_access_key_id = ACCESS_KEY
aws_secret_access_key = SECRET_KEY

Ctrl+Xを使用してnanoを終了し、プロンプトに従ってファイルを保存します。

次に、必要なタスクを実行するいくつかのPythonスクリプトを記述します。

ステップ7 - AWS ESのスナップショットを手動で取る

まずは簡単なテストを実行しましょう。Pythonスクリプトを使用してAWS ESクラスターのインデックスをリストします。これでAWSクレデンシャルが有効であり、クラスターと通信できることが証明されます。

お好みのエディターでindices.pyという名前のファイルを作成します。シンプルにするためにnanoを使用します。

$ nano indices.py

次の内容をコピー&ペーストし、大文字の2つの変数を自分の値に置き換えます。

import boto3, requests
from requests_aws4auth import AWS4Auth
host = 'ES_ENDPOINT'
region = 'ES_REGION'
creds = boto3.Session().get_credentials()
auth = AWS4Auth(creds.access_key, creds.secret_key, region, 'es', session_token=creds.token)
print("Listing Indices from AWS ES ...")
req = requests.get(host + '/_cat/indices?v', auth=auth)
print("HTTP Response Code: " + str(req.status_code) + '\n' + req.text)

Ctrl+Xを使用してnanoを終了し、プロンプトに従ってファイルを保存します。

Pythonスクリプトを実行します。

$ python3 indices.py

その出力は下記に類似したものになるはずです。

Listing Indices from AWS ES ...
HTTP Response Code:200
health status index     uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   testindex yME2BphgR3Gt1ln6n03nHQ   5   1          1            0      4.4kb          4.4kb

次に、お好みのエディターでregister.pyという名前のファイルを作成します。

$ nano register.py

次の内容をコピー&ペーストし、大文字の7つの変数を自分の値に置き換えます。

import boto3, requests
from requests_aws4auth import AWS4Auth
host = 'ES_ENDPOINT'
region = 'ES_REGION'
repo_name = 'SNAPSHOT_REPO'
snapshot_name = 'SNAPSHOT_NAME'
s3_region_name = 'S3_REGION_NAME'
s3_bucket_name = 'S3_BUCKET_NAME'
role_arn = 'ROLE_ARN'
creds = boto3.Session().get_credentials()
auth = AWS4Auth(creds.access_key, creds.secret_key, region, 'es', session_token=creds.token)
headers = {"Content-Type": "application/json"}
payload = {
        "type": "s3",
        "settings": {
                "region": s3_region_name,
                "bucket": s3_bucket_name,
                "role_arn": role_arn
        }
}
print("Registering Snapshot with AWS ES ...")
url = host + '/_snapshot/' + repo_name
req = requests.put(url, auth=auth, json=payload, headers=headers)
print("HTTP Response Code: " + str(req.status_code) + '\n' + req.text)

Ctrl+Xを使用してnanoを終了し、プロンプトに従ってファイルを保存します。

Pythonスクリプトを実行します。

$ python3 register.py

その出力は下記に類似したものになるはずです。

Registering Snapshot with AWS ES ...
HTTP Response Code:200
{"acknowledged":true}

次に、お好みのエディターでsnapshot.pyという名前のファイルを作成します。

$ nano snapshot.py

次の内容をコピー&ペーストし、大文字の4つの変数を自分の値に置き換えます。

import boto3, requests
from requests_aws4auth import AWS4Auth
host = 'ES_ENDPOINT'
region = 'ES_REGION'
repo_name = 'SNAPSHOT_REPO'
snapshot_name = 'SNAPSHOT_NAME'
creds = boto3.Session().get_credentials()
auth = AWS4Auth(creds.access_key, creds.secret_key, region, 'es', session_token=creds.token)
print("Starting Snapshot with AWS ES ...")
url = host + '/_snapshot/' + repo_name + '/' + snapshot_name
req = requests.put(url, auth=auth)
print("HTTP Response Code: " + str(req.status_code) + '\n' + req.text)

Ctrl+Xを使用してnanoを終了し、プロンプトに従ってファイルを保存します。

Pythonスクリプトを実行します。

$ python3 snapshot.py

その出力は下記に類似したものになるはずです。

Starting Snapshot with AWS ES ...
HTTP Response Code:200
{"accepted":true}

注： スナップショットを取るための時間は、AWS ESドメインのサイズに比例して増えます。AWSのドキュメントによると、スナップショットのオペレーションが長時間に及ぶと「504 GATEWAY_TIMEOUT」が表示される場合があるとのことです。このエラーは無視し、スナップショットが正常に完了するまで待機するようにと記載されています。

最後に、スナップショットの状態を確認します。status.pyという名前のファイルを作成します。

$ nano status.py

次の内容をコピー&ペーストし、大文字の4つの変数を自分の値に置き換えます。

import boto3, requests
from requests_aws4auth import AWS4Auth
host = 'ES_ENDPOINT'
region = 'ES_REGION'
repo_name = 'SNAPSHOT_REPO'
snapshot_name = 'SNAPSHOT_NAME'
creds = boto3.Session().get_credentials()
auth = AWS4Auth(creds.access_key, creds.secret_key, region, 'es', session_token=creds.token)
print("Getting Status of Snapshot with AWS ES ...")
url = host + '/_snapshot/' + repo_name + '/' + snapshot_name + '?pretty'
req = requests.get(url, auth=auth)
print("HTTP Response Code: " + str(req.status_code) + '\n' + req.text)

Ctrl+Xを使用してnanoを終了し、プロンプトに従ってファイルを保存します。

Pythonスクリプトを実行します。

$ python3 status.py

その出力は下記に類似したものになるはずです。

Getting Status of Snapshot with AWS ES ...
HTTP Response Code:200
{
  "snapshots" : [ {
    "snapshot" : "my-snapshot",
    "uuid" :"ClYKt5g8QFO6r3kTCEzjqw",
    "version_id" :6040299,
    "version" :"6.4.2",
    "indices" : [ "testindex" ],
    "include_global_state" : true,
    "state" :"SUCCESS",
    "start_time" :"2019-03-03T14:46:04.094Z",
    "start_time_in_millis" :1551624364094,
    "end_time" :"2019-03-03T14:46:04.847Z",
    "end_time_in_millis" :1551624364847,
    "duration_in_millis" :753,
    "failures" : [ ],
    "shards" : {
      "total" :5,
      "failed" :0,
      "successful" :5
    }
  } ]
}

「"state":"SUCCESS"」が表示されていれば、スナップショットは正常にS3に保存されています。これでパート2に進む準備が整いました。

パート2 - S3からの復元

このガイドの2つ目のパートでは、S3にある手動スナップショットから、Elasticが管理するデプロイメントに復元する手順について説明します。

このパートの内容を実行するために、Elasticが管理するデプロイメントをAWSまたはGCPにプロビジョニングできます。

ステップ1 - デプロイメントのサイズを指定する

Elasticsearch Service on Elastic Cloudに作成したデプロイメントのリソースの量は、AWS ESクラスターのリソースの量と同じはずです。AWS ES内のクラスターのサイズを反映するために、スライダーを使用してデータノード数を増やします。保存してから次に進みます。

ステップ2 - カスタムリポジトリを追加する

Elasticが管理するデプロイメント（AWS ESクラスターではなく）で、Kibanaを開いて［Dev Tools］にアクセスします。

下記のAPIコールをコピーしてDev Toolsにペーストし、5つの変数を置き換えます。

PUT /_snapshot/SNAPSHOT_REPO
{
  "type": "s3",
  "settings": {
    "bucket":"S3_BUCKET_NAME",
    "region":"S3_REGION_NAME",
    "access_key":"ACCESS_KEY",
    "secret_key":"SECRET_KEY",
    "compress": true
  }
}

リクエストを実行します。

下記の応答になるはずです。

{
  "acknowledged": "true"
}

あと少しで完了です。

ステップ3 - S3から復元する

最後に、先ほど登録したスナップショットリポジトリから復元します。

下記のAPIコールをコピーしてDev Toolsにペーストし、2つの変数を置き換えます。

POST /_snapshot/SNAPSHOT_REPO/SNAPSHOT_NAME/_restore

下記の応答になるはずです。

{
  "accepted": "true"
}

復元の進捗状況は下記によって確認できます。

GET /_snapshot/SNAPSHOT_REPO/SNAPSHOT_NAME/_status

「"state":"SUCCESS"」が表示されていれば、復元が正常に完了しています。

{
  "snapshots": [
    {
      "snapshot": "my-snapshot",
      "repository": "my-snapshot-repo",
      "state":"SUCCESS",
      ...
    }
  ]
}

これで、「リフト&シフト」方式による、AWS ESからElasticsearch Serviceへの移行が完了しました。

まとめ

これでElasticsearch Service on Elastic Cloudへの移行が完了したため、AWS ESでは利用できない機能を活用できるようになるだけでなく、Elastic Stackを作成した専門家によってデプロイメントが管理されているという安心感を得ることもできます。使用中に問題が発生した場合は、Elasticのサポートチームの専門家が支援します。 まだElasticsearch Service on Elastic Cloudを利用していない場合は、14日間の無料トライアルで試用してみることをお勧めします。ご質問がある場合は遠慮なくご連絡ください。

多くの人が必要とするもの

Elasticsearchクラスター間でネイティブに複製できる機能は、最もリクエストが多かった機能であり、ユーザーの皆さんが長く待ち望んでいたものです。必要な基盤を築き、基本となる新しいテクノロジーをLuceneに構築し、初期の設計を繰り返すとともにさらに洗練するために、数年に渡ってエンジニアリングに取り組んだ結果、 Elasticsearch 6.7.0ではクラスター横断レプリケーション（CCR）がネイティブで利用できるようになり、本番環境で使えるようになりました。連載の第1回目となるこの記事では、実装内容の簡単な紹介とCCRの技術的背景について説明します。CCRの具体的なユースケースの詳細については、今後の記事で取り上げる予定です。

Elasticsearchのクラスター横断レプリケーションでは、ElasticsearchおよびElastic Stack内でミッションクリティカルなさまざまなユースケースが可能になります。

• 災害復旧（DR）/ 高可用性（HA）：ミッションクリティカルなアプリケーションには、データセンターや地域の停電に対する耐性が必須です。この要件についてはすでに、Elasticsearchでは追加のテクノロジーを使用することで解決していますが、このやり方では複雑さが増し、管理オーバーヘッドが増大します。そこで今回、Elasticsearchで実現したのは、追加のテクノロジーを使わずに、CCRを使用することで複数のデータセンター全体のDR/HA要件をネイティブで満たすことです。

• データのローカル性：Elasticsearchのデータを複製し、ユーザーまたはアプリケーションサーバーに近い場所に配置することで、コストのかかるレイテンシを削減できます。たとえば、データとアプリケーションサーバーの間の距離を最小化するために、製品カタログまたは参照データセットを世界中の20以上のデータセンターに複製する場合が該当します。または、株を扱う企業で、ロンドンとニューヨークにオフィスを構えるのも、この例の1つです。ロンドンオフィスでのすべての取引がローカルに書き込まれ、ニューヨークオフィスに複製されます。そしてニューヨークオフィスでのすべての取引がローカルに書き込まれ、ロンドンオフィスに複製されます。こうすることで、両方のオフィスがすべての取引の全体像を把握できます。

• レポートの一元化：多数の小さいクラスターから、一元化されたレポートクラスターにデータを複製します。これは、大規模なネットワーク全体でクエリを効率的に実行できない可能性がある場合に便利です。たとえば、世界に展開している大手銀行の場合は、世界に100のElasticsearchクラスター（各支店に1つ）を持っている可能性があります。CCRを使用することで、世界中の100の支店すべてからイベントを複製することができ、それらのイベントをローカルで分析および集計できます。

Elasticsearch 6.7.0よりも前のバージョンでは、このようなユースケースにはサードパーティのテクノロジーによって部分的に対処することが可能でしたが、面倒な作業が必要であり、大幅な管理オーバーヘッドが生じるとともに多くの欠点がありました。クラスター横断レプリケーションはElasticsearchにネイティブで統合されているため、ユーザーは複雑なソリューションの管理に伴う負荷や欠点に悩まされることがなくなります。さらに、既存のソリューション以上の利点（包括的なエラー処理など）を活用できるようになり、Elasticsearch内でAPIを、またKibana内でUIを使用して、CCRを管理および監視できます。

今後の記事ではそれらの各ユースケースについて詳細に説明します。ぜひご注目ください。

クラスター横断レプリケーションの使用の開始

ダウンロードページにアクセスして、ElasticsearchおよびKibanaの最新リリースを入手し、 開始ガイドを参照して使用を開始しましょう。

CCRはプラチナレベルの機能であり、30日間のトライアルライセンスで利用可能です。このライセンスはトライアルAPIを使用して、またはKibanaから直接、有効化することができます。

クラスター横断レプリケーションの技術的概要

CCRはアクティブ/パッシブのインデックスモデルを中心に設計されています。Elasticsearchクラスターのインデックスは、別のElasticsearchクラスターのインデックスからの変更を複製するように設定できます。変更の複製先となるインデックスは「フォロワーインデックス」と呼ばれ、複製元となるインデックスは「リーダーインデックス」と呼ばれます。フォロワーインデックスはパッシブです。つまり、読み取りリクエストと検索には対応しますが、直接の書き込みはできません。直接の書き込みが可能なのはリーダーインデックスのみです。CCRはインデックスレベルで管理されるため、クラスターにはリーダーインデックスとフォロワーインデックスの両方を含めることができます。このようにして、一部のインデックスを一方向（例：米国のクラスターから欧州のクラスター）に複製し、その他のインデックスを逆方向（欧州のクラスターから米国のクラスター）に複製することで、一部のアクティブ/アクティブのユースケースを解決できます。

複製はシャードレベルで実行され、フォロワーインデックスの各シャードは、対応するリーダーインデックスの各シャードから変更を取得します。つまり、フォロワーインデックスのシャード数は、対応するリーダーインデックスのシャード数と同数ということになります。すべてのオペレーションがフォロワーによって複製されるため、ドキュメントの作成、更新、変更が複製されることになります。複製はほぼリアルタイムに実行されるため、シャードのグローバルチェックポイントの時点からさらにオペレーションが実行されるとすぐに、フォロワーシャードによる複製対象となります。オペレーションはフォロワーシャードによって一括で効率的に取得およびインデックスされるため、変更を取得するための複数のリクエストを同時に処理することが可能です。このような読み取りリクエストは、プライマリシャードまたはそのレプリカによって処理され、シャードからの読み取りを除いては、リーダーシャードに追加の負荷はかかりません。このような設計により、CCRは本番環境の負荷に合わせて拡張できるため、Elasticsearchで高く評価されている（そして期待されている）高スループットのインデックス作成スピードが継続的に維持されます。

CCRは、新たに作成されたインデックスと既存のインデックスの両方をサポートします。フォロワーを最初に設定する際、リーダーインデックスの基盤となるファイルをコピーすることで、フォロワーはリーダーインデックスからブートストラップされます。これは、レプリカがプライマリから復元されるのと同様のプロセスです。この復元プロセスが完了すると、CCRは追加のオペレーションをリーダーから複製します。マッピングおよび設定の変更は、必要に応じてリーダーインデックスから自動的に複製されます。

CCRがエラー状況（ネットワーク障害など）に陥ることがあります。CCRはそのようなエラーを、回復可能なエラーおよび致命的なエラーに分類します。回復可能なエラーが発生した場合、CCRは、障害の原因となった状況が解決されるとすぐに複製を再開できるようにリトライを繰り返します。

複製のステータスは専用のAPIで監視できます。このAPIを使用することで、フォロワーがリーダーのどのくらい近くまで追跡できているかを監視し、CCRのパフォーマンスに関する詳細な統計を確認できるとともに、注意が必要なエラーを追跡できます。

私たちは、CCRをKibana内の監視および管理アプリケーションと統合しました。監視UIにより、CCRの進捗およびエラーレポートに関するインサイトを得ることができます。

Kibana内のElasticsearch CCR監視UI

管理UIにより、リモートクラスターとフォロワーインデックスの構成が可能になり、自動フォロワーパターンの管理によってインデックスの自動複製が可能になります。

Kibana内のElasticsearch CCR管理UI

船長さんの命令：現在のインデックスに従いましょう

ユーザーの多くは、定期的に新しいインデックスを作成するというワークロードを抱えています。たとえば、Filebeatからプッシュされるログファイル、またはインデックスライフサイクル管理によるインデックスの自動ロールオーバーを基に、インデックスを日々作成しています。それらのインデックスをソースクラスターから複製するために手動でフォロワーインデックスを作成するのではなく、CCRに直接、自動フォロー機能を構築しました。この機能を使用してインデックスパターンを設定し、ソースクラスターから自動的に複製されるようにすることができます。CCRがソースクラスターを監視してそれらのパターンに一致するインデックスを検出します。そして、一致するリーダーインデックスを複製するフォロワーインデックスを作成します。

また、CCRとILMを統合しました。これにより、時間ベースのインデックスをCCRで複製し、ILMによってソースクラスターとターゲットクラスターの両方で管理できます。たとえば、ILMはCCRがリーダーインデックスを複製するタイミングを把握しているため、CCRが複製を完了するまで、インデックスの縮小や削除などの破壊的なオペレーションを慎重に管理することが可能です。

履歴を把握できない場合

CCRが変更を複製するためには、リーダーインデックスのシャードのオペレーション履歴が必要です。また、複製対象のオペレーションを把握するためのポインターが各シャードに必要です。オペレーション履歴はシーケンスIDによって管理されており、ポインターは グローバルチェックポイントと呼ばれているものです。ここで注意が必要なのは、複雑な要素が関係してくる場合があることです。ドキュメントが更新または削除される場合、Luceneでは、ドキュメントが削除されたことを記録するためにビットがマークされます。その後のマージオペレーションによってマージされるまで、その削除対象のドキュメントはディスク上に維持されます。削除がマージされる前に、CCRがこのオペレーションを複製した場合は問題ありません。しかし、マージは固有のライフサイクルによって実行されるため、CCRがオペレーションの複製を実行する前に、削除ドキュメントのマージが実行される可能性があります。削除ドキュメントがマージされるタイミングを制御できる機能がないと、CCRがオペレーションを複製する機会を逃してしまう可能性があり、完全なオペレーション履歴をフォロワーインデックスに複製できない場合があります。CCRの初期設計時には、それらのオペレーション履歴のソースとしてElasticsearch Translogを使用しようと計画していました。これによって問題を回避できると考えていたのです。しかし、TranslogはCCRの効果的な実行に必要なアクセスパターンを検出するために設計されたものではないということに、すぐに気づきました。そこで、必要なパフォーマンスを達成するために、Translog自体に、およびTranslogと併用できるように、追加のデータ構造を構築することを考えました。しかし、このアプローチには制約があります。その制約の1つは、システムの最もクリティカルなコンポーネントの1つの複雑さが増すことです。これは単純に、私たちのエンジアリング哲学に反します。さらに、私たちの今後の変更に縛りをかけるものになってしまいます。つまり、オペレーション履歴の上に構築することで、オペレーション履歴に対して実行可能な検索のタイプを制限すること、またはTranslogの上にLuceneのすべてを再実装すること、これらのどちらかが強制されることになります。このインサイトを基に、私たちはLuceneの機能としてネイティブで組み込む必要があることに思い至りました。そうすることで、削除ドキュメントのマージのタイミングを制御でき、オペレーション履歴をLuceneに効果的にプッシュできます。私たちはこの技術を「Soft Deletes（ソフトな削除）」と呼んでいます。Luceneへのこの投資は、この先何年にも渡って効果をもたらすことになります。それを基にCCRを構築しただけでなく、現在、Soft Deletesを基にして複製モデルを構築するように取り組んでいます。また、今後の変更API もこれらをベースとすることになります。このSoft Deletesはリーダーインデックス上で有効化される必要があります。

あとは、リーダー上でSoft Deleteが実行されたドキュメントのマージのタイミングに対して、フォロワーが影響を与えることができるようにすることです。そのために、シャード履歴維持リースを導入しました。これにより、フォロワーは現在履歴上のどこにいるかについて、リーダー上のオペレーション履歴にマークすることができます。これにより、そのマーカーの下にあるオペレーションについてはマージしても問題ないこと、およびマーカーの上にあるオペレーションについてはフォロワーに複製する機会が与えられるまで維持する必要があることを、リーダーは認識できます。このマーカーにより、リーダーはフォロワーが一時的にオフラインになっても、まだ複製されていないオペレーションを維持することができます。この履歴を維持するにはリーダーに追加のストレージが必要になるため、これらのマーカーは限られた期間のみ有効となります。 その期間が終了するとマーカーは期限切れとなり、リーダーシャードは履歴をマージできるようになります。この期間の長さは、フォロワーがオフラインになったときに備えてその維持のためにどの程度のストレージを割いても良いかに基づいて、またフォロワーのオフライン時間（リーダーから再度ブートストラップする必要が生じるまでの時間）の許容範囲に基づいて調整できます。

まとめ

皆様にはぜひCCRを試用していただき、その機能についてフィードバックをいただければと思います。皆様の役に立つことを願いながらこの機能を構築いたしました。このシリーズの今後の記事もぜひご覧ください。CCRの機能およびCCRの使用を想定しているユースケースの詳細について、分かりやすく説明する予定です。CCRについてご質問がある場合は、ディスカッションフォーラムをご活用ください。

この記事で使用されているサムネイル画像の著作権はNASAに帰属しており、CC BY-NC 2.0ライセンスによってその使用が許可されています。この基準で使用されているバナー画像の著作権はRawpixel Ltdに帰属しており、 CC BY 2.0ライセンスによってその使用が許可されています。この記事では、オリジナルのものからトリミングされています。

Elastic Stackバージョン6.8と7.1より、TLS暗号化、ロールベースのアクセス制御（RBAC）をはじめとするセキュリティ機能が通常の配布パッケージに含まれ、無料で提供されています。このブログ記事では、現在お使いのElasticsearchクラスターで新たにこのセキュリティ機能を使いはじめる方法をご紹介します。

実装済みのElastic Stackにセキュリティ機能を導入する事例を取り上げることができるよう、この記事ではローカルのマシンに2ノードのElasticsearchクラスターを作成して準備します。ますはじめに、2ノード間にTLS通信を設定します。次に、クラスター中のデータの分析・可視化に使うKibanaインスタンスでSecurityを有効化します。その後、Kibanaにロールベースのアクセス制御を設定することにより、各ユーザーが確実に許可されたデータのみ閲覧できるようにします。

Securityには高度な設定や動作も多数ありますが、この記事では新たに導入する方法だけをご紹介します。こちらの記事をご覧いただいた後は、参考事例やElastic Stackを安全に保つためのドキュメントもお役立てください。また、この記事はローカルのクラスターへの導入を想定しています。セキュリティ機能はバージョン6.8と7.1より無料で配布され、同時にElasticsearch Serviceでは標準搭載となります。

ElasticsearchとKibanaをインストールする

こちらのデモンストレーションは、OSがLinuxのノートPCで実施します。以下の手順を実施される際は、ご利用の環境に応じて適宜調整してください。

手順1：ElasticsearchとKibanaをダウンロードする

はじめにElasticsearchとKibanaのバージョン6.8以降、または7.1以降をデフォルトの配布パッケージでダウンロードします。"Security"はバージョン6.8および7.1以降でデフォルトの配布に追加されています。6.8または7.1以前のバージョンをお使いの場合はアップグレードが必要です。

手順2：ElasticsearchとKibanaを抽出する

この事例でダウンロードしたファイルはelasticsearch-7.1.0-linux-x86_64.tar.gzとkibana-7.1.0-linux-x86_64.tar.gzです。ダウンロード完了後は、コンテンツを抽出する必要があります。

手順3：Elasticsearchノードを2つ作成する

2本のノードを持つクラスターを作成するには、Elasticsearchディレクトリのコピーを2つ作成し、1つにmaster、もう1つにnodeと名前をつけます。この手順を完了すると、以下のようなファイルとフォルダが存在しています。

elasticsearch-7.1.0                      elasticsearch-7.1.0-node
elasticsearch-7.1.0-linux-x86_64.tar.gz  kibana-7.1.0-linux-x86_64
elasticsearch-7.1.0-master               kibana-7.1.0-linux-x86_64.tar.gz

TLSと認証を設定する

最初に証明書を生成し、ノードが安全に通信できるようにします。エンタープライズ証明機関（CA）で証明書を生成することもできますが、このデモではelasticsearch-certutilというコマンドを使用する手順で進めます。よくある証明書の混乱を招くことなく実施できる手順です。

手順1：ElasticsearchマスターのTLS

cdコマンドでmasterディレクトリに移動してから、次のコマンドを実行します。

bin/elasticsearch-certutil cert -out config/elastic-certificates.p12 -pass ""

次に、お好みのテキストエディターでconfig/elasticsearch.yamlファイルを開きます。ファイルの末尾に、以下の行をコピー＆ペーストします。

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

ファイルを保存すると、マスターノードを使いはじめることができます。コマンドbin/elasticsearchを実行してください。この実行ファイルは引き続き実行させておく必要がありますが、こちらのターミナルはしばらく操作する必要がありません。

手順2：Elasticsearchクラスターパスワード

マスターノードが稼働しはじめたら、クラスターのパスワードを設定します。新しいターミナルにcdコマンドを入力し、マスターノードディレクトリに移動してからコマンドbin/elasticsearch-setup-passwords autoを実行します。この操作で、スタックを使用する各種ユーザー向けにランダムなパスワードが生成されます。またはautoパラメーターを使用せず、interactiveパラメーターを使い手動でパスワードを定義することもできます。生成したパスワードはこの後の手順で使用するので、わかるようにしておきます。

手順3：ElasticsearchノードのTLS

再度新しいターミナルを開き、cdでノードディレクトリに移動します。このデモでは、elasticsearch-7.1.0-nodeという名前がついています。

ここで最も簡単なのが、マスターのconfigディレクトリを全部ノードのconfigディレクトリにコピーするという手順です。

cp ../elasticsearch-7.1.0-master/config/* config/

さらに構成オプションのnode.master: falseをconfig/elasticsearch.ymlファイルに追加します。この手順の背景についての説明は省きますが、クラスターのドキュメントで詳細な情報をご覧いただくことができます。configファイルをすべてコピーする方法の他に、証明書ファイルをコピーしてからxpack.security.*キーをマスターノードと同様に設定するというやり方もあります。

その後、bin/elasticsearchを実行してノードを開始すると、クラスターに加わっていることを確認することができます。またマスターノードのターミナルウインドウでも、ノードがクラスターに加わったことを通知するメッセージを確認できます。これでノード2本のクラスターを立ち上げることができました。

手順4：KibanaのSecurity

最後にKibanaを設定します。再び別のターミナルウインドウを開き（これで最後です、頑張って！）、Kibanaユーザー用のパスワードを追加するという手順です。パスワードは、setup-passwordsコマンドで生成したものをそのまま使用できます。

まずcdコマンドでKibanaディレクトリに移動し、テキストエディターでconfig/kibana.ymlファイルを開きます。次のようなリンクを見つけてください。

#elasticsearch.username: "user"
#elasticsearch.password: "pass"

行頭の#を削除して、usernameとpasswordフィールドをアンコメントします。"user"を"kibana"に、"pass"をsetup-passwordsコマンドが生成したKibanaパスワードに変更します。ここでファイルを保存し、bin/kibanaを実行してKibanaを立ち上げます。

Kibanaにロールベースのアクセス制御（RBAC）を設定する

Kibanaが立ち上がったら、今度はWebブラウザに切り替えてhttp://localhost:5601を開きます。ログインを促す画面が表示されたら、setup-passwordsで生成したパスワードのスーパーユーザー、elasticを使用します。

新規インストールの場合、Kibanaはサンプルデータを読み込むよう促すメッセージを表示します。

ここでは飛行機のフライトとWebに関するサンプルデータを読み込ませてみます。読み込みを完了したら、設定用の歯車アイコンをクリックしてください。

次に、ロールを作成しましょう。ロールのメニューをクリックします。

[ロールを作成]をクリックします。

このデモでは、1つ目のロールにread_logsという名前をつけてみます。

下にスクロールして[インデックス]と[権限]フィールドが表示されたら、ログのインデックスを選択します。今回は読み込み権限を付与します。

Securityのさまざまな機能のうち、特にspaceが気になるという方も多いかもしれません。この記事では都合上割愛しますが、spaceはKibanaで安全にデータを整理する優れた機能です。詳しくは、Kibanaのspaceに関するドキュメントや、Kibanaのspaceを取り上げたブログ記事をご覧ください。

さて次に、read_flightという名称で別のロールを作成しましょう。

飛行機のフライトに関するインデックスの読み込み権限を割り当てます。

それでは2人のユーザーを作成し、これらのロールを割り当ててみましょう。左のメニューで[ユーザー]リンクを選択し、[新規ユーザーの作成]ボタンをクリックします。

このユーザーをflight_userと名付け、パスワードを設定ます。フルネームやメールアドレスの設定は必須ではありません。このユーザーがKibanaでデータを表示できるようにするためには、read_flightロールとkibana_userロールの両方を付与する必要があります。

作成できたら、log_userでも同様の手順を実施します。こちらにはread_logsとkibana_userの2つのロールを付与します。

これで2名のユーザーの設定が完了しました。ここまで来たら、elasticユーザーからログアウトすることができます。

log_userでログインしてみましょう。ダッシュボードアイコンをクリックすると、フライトとログの2つのダッシュボードがあることがわかります。

まとめ

Elastic StackのSecurityは、今回の記事で紹介しきれないほど幅広い用途に利用することができます。この記事では導入時の設定手順に絞ってお伝えしましたが、今後は導入済みのユーザー向けに、Securityの多様な機能と使い方をご紹介していく予定です。次回の記事更新までの間、以下のコンテンツもご覧いただけます。Elastic Stack Securityの仕組みやSecurityでできることなど、ご活用のヒントとしてお役立てください。

• 「Elasticsearchを安全に保つ：基礎」コース
• Elasticsearch Securityドキュメント
• TLSの構成に関するブログ記事
• Kibanaの"Space"に関するブログ記事

質問やディスカッション用の公開フォーラムもあります。

快適な検索エクスペリエンスをお楽しみください。