「これから始める Amazon Elasticsearch Service セミナー」に参加してきました

AWS公式のオンラインセミナー「これから始める Amazon Elasticsearch Service セミナー」に参加してきたのでそのレポート記事です。

参加動機

私の所属している部署で Amazon Elasticsearch（Amazon ES）の利用が増えてきており、そろそろちゃんと押さえておきたいと思ったところに案内がきたので参加する運びとなりました。

アジェンダ

4つのアジェンダから構成されていました。

1. Introduction to Amazon Elasticsearch Service
2. Amazon Elasticsearch Service Best Practice
3. Dive Deep into Amazon Elasticsearch Service
4. Amazon ES まわりのアップデート

以下は私のメモ書きの一部です。すべて書くとスライドの写しに近くなってしまうので一部だけに留めます。

Introduction to Amazon Elasticsearch Service

Elasticsearch の概要、Elasticsearch のユースケース、Amazon ES の概要、特徴についてのパートでした。

Elasticsearch とは

• 論理的データの持ち方
  • インデックス/ドキュメント/フィールド
    • DBにおける Table/Record/Column に近い概念
• 物理的データの持ち方
  • クラスター構成が一般的
    • マスターノード
      • メタデータが格納
    • データノード
  • インデックスは内部的にシャードというデータブロックに分割される
  • インデックス作成時に、シャード数とレプリカ数を指定する
    • プライマリシャード
    • レプリカシャード
    • 複数のノードに渡って保存されることで可用性・耐久性を高く保つ

Amazon ES の概要

• フルマネージド
  • ポチポチして数分間でクラスターをデプロイして利用可能
• コスト効率
  • 起動しているだけ課金
  • RI を活用してコスト最適化
• 可用性
  • 24×7でモニタニング
  • マルチAZに対応
• スケーラビリティ
  • クラスターのバージョンアップ
• 主なユースケース
  • 検索
    • RDS・DynamoDBから取得した情報を構造化されたJSON形式でElasticsearchに格納
    • _search APIを通してデータ検索、マッチした検索結果をスコア順にソートして返す
  • ログ分析
    • ストリーミング
      • （１）Fluentd or Logstash
      • （２−１）Kinesis Streams
        • Lambdaを経由して格納
        • VPC内
      • （２−２）Kinesis Firehose
        • 直接格納
        • VPC外
    • バッチインポート
      • S3のイベント通知でLambda発火、Bulk API でインポート

Amazon Elasticsearch Service Best Practice

Amazon ES を使うにあたって、シャード数やレプリカ数、インスタンスタイプをどのように決めればいいのかといった悩みどころに対するベストプラクティスを解説しているパートです。

アーキテクチャ

• Elasticsearchクラスタ = （Amazon ES）ドメイン
  • ドメインに対して、ノードの追加、インスタンスタイプの変更、ストレージ追加が可能
• マスターノード
  • 専用マスターノード
    • マスター候補ノードから選出される
    • アクティブになってAmazon ESドメインの状態を管理しているノード
    • 1つのクラスタに1ノードだけ存在
  • マスター候補ノード
    • マスターノード障害時にマスターに昇格
    • マスターノードと合わせて3台以上必要
• データノード
  • インデックスデータを保持
  • データの追加・削除・検索のときにアクセスされる
  • Amazon ESで最大ノード数が200
  • 3つのAZに分散して配置するのが推奨されている
• シャード
  • インデックスのデータを分割
  • 各シャードは複数のレプリカを持つことができる
  • マルチAZ構成にしておくと、レプリカは自動的に別AZのノードに分散して配置される
    • レプリカ数を1以上にすることを推奨
• マスターノードとデータノードは同居可能だが、データノードの負荷があがるとマスターノードが不安定になるため、分けるのが推奨
• VPC接続する場合、各サブネットにはAZに割り当られたデータノード数の3倍のIPアドレスが必要
  • Blue/Green Deploymentで利用するために予約される

サイジング

• 最小ストレージ要件 = ソースデータサイズ × (1 + インデックス作成オーバーヘッド) × (1 + レプリカ数） / (1 - Linux 予約スペース）/ (1 - Amazon ES のオーバーヘッド）
  • 例）30GB/日増加するログを2週間保持、レプリカ数 2、ストレージサイズ 80GB/ノード
    • (30GB×14days) × (1+0.1) × (1+2) / (1-0.05) / (1-0.2) ≒ 1,823.7GB
• ソースデータサイズ
  • 長期保存インデックス
    • 通常方式
    • ソースデータをすべて同じインデックスに格納
    • 物件情報などデータ量が急激に増えないデータに向いている
  • ローリングインデックス
    • 日次・週次など一定間隔で新しいインデックスに切り替え
    • 古いインデックスはレプリカ数を減らしたり削除
    • ログなど逓増するデータに向いている
• インデックス作成オーバーヘッド
  • 元のソースデータよりも一般的に10%程度大きくなる
  • _cat/indices API で返ってくる pri.store.size が該当する
• シャードのレプリカ数
  • どのぐらいレプリカ数が必要かはユースケースによる
  • レプリカ数が多いほど可用性・耐久性を高める & 読み込みがベビーな場合、検索パフォーマンスが改善
  • 最低でも1が推奨されている
• Linux の予約スペース
  • ストレージ容量の5%
• Amazon ESのオーバーヘッド
  • ノード1台あたり20%（最大20GB）
    • 500GB/ノード × 3台 ⇒ MIN(20GB, 500GB × 0.2) × 3 = 60GB
    • 50GB/ノード × 30台 ⇒ MIN(20GB, 50GB × 0.2) × 30 = 300GB
• シャード数
  • シャード数はインデックス作成後に変更できないので余裕をもたせる
  • シャードを管理するにCPUとメモリを消費するため、マスターノードの負荷があがる
  • 一般的にシャードあたりのサイズは 10〜50GB
  • プライマリシャード数 = （ソースデータ + 拡張の余地）× （1 + インデックス作成オーバーヘッド）/ シャードあたりのサイズ
    • 例）30GB/日増加するログを2週間保持、最大20%程度ログ量が増える可能性がある
    • (30GB×14days + 30GB×14days×0.2) × (1+0.1) / 30GB = 18.48 ⇒ 19シャード
  • プライマリシャードサイズ = ソースデータ × （1 + オーバーヘッド）/ シャード数
    • 例）(30GB×14days) × (1+0.1) / 19シャード = 24.3GB
• インスタンスタイプ
  • 専用マスターノード
    • データノード数と最大シャード数に応じてインスタンスタイプがおおよそ決まる
    • T2系インスタンスは本番環境では非推奨
  • データノード
    • インスタンスタイプごとに最小・最大 EBS サイズが設定されている
    • データノードのヒープメモリ1GBあたり20未満のシャード数が推奨
    • パフォーマンステストを実施する

運用監視

• ドメイン更新時にBlue/Green デプロイが行われる
  • インスタンスタイプの変更、マルチAZの有効・無効、バージョンアップ etc
  • Blue/Green デプロイはノード数が倍になる、マスターノードの負荷があがる
• 監視項目
  • CPU Utilization（データノードのCPU使用率）
  • JVM Memory Pressure（データノードのJVMメモリ負荷）
  • Cluster Status Yellow
    • 1つ以上のレプリカシャードがノードに割り当てられていない
  • Free Storage Space
  • Master CPU Utilization（マスターノードのCPU使用率）
  • Master JVM Memory Pressure（マスターノードのJVMメモリ負荷）
• スナップショット
  • 自動スナップショット
    • 1時間ごとに作成され、14日間保持（ES 5.3以降）
    • 追加課金なし
  • 手動スナップショット
    • S3にスナップショットを保存
    • S3保存料金がかかる

Dive Deep into Amazon Elasticsearch Service

最近 GA になった UltraWarm と OSS である Open Distro for Elasticsearch についてのパートです。

UltraWarm

• 2020年4月にGA
• Amazon ESの新しいストレージ層
• ペタバイトの大規模なデータ分析等に最適
• ホットデータノード
  • 通常のデータノード
  • Read/Write
  • 頻繁に読み書きするデータ用途
• UltraWarmデータノード
  • Read Only
  • あまり読み込みしないデータ用途
  • データはS3に保存され、クエリでデータを取得
• 特徴
  • S3にデータを保存
    • 100%ストレージの料金を活用
      • EBSベースだと余剰分（使わない部分）も料金がかかる
  • Kibanaなどからはシームレスに利用可能
    • API、クエリの変更なし
    • クエリはホットとUltraWarmにまたがることができる
  • パフォーマンス
    • Nitroシステムによる高帯域幅のS3アクセス
  • ストレージコスト削減
    • ホットデータからUltraWarmにデータを移してストレージコスト削減

Open Distro for Elasticsearch

• オープンソース
  • Elastic社が公開しているElasticsearchをベースに開発
• エンタープライズグレード
  • セキュリティ、アラート機能などの機能提供
• コミュニティ主導

セキュリティ

• Kibanaにおける認証・認可
  • Basic認証
  • LDAP、AD、SAML（Amazon ESに取り込まれていない）
• Kibanaマルチテナント
  • グループごとにダッシュボードとインデックスを分けることができる
• 監査ログ
  • 現在、Amazon ESに取り込めていないが、将来的に取り込む予定

アラーティング

• モニターの作成（クエリ）、アラート条件（しきい値、重要度）
• 通知（Webhook、SNS、Slack etc）

インデックス管理

• Kibanaからインデックスを管理
  • インデックスのサイズ・数を管理
• 読み取り専用にする、ロールオーバー（ローテーション）など

SQL

• SQLでクエリが書ける
  • _opendistro/_sql API でSQLをPOSTする
• Explain ができるのでクエリがどのように使われるのかを知ることができる
  • _opendistro/_sql/_explain API
• SQLをJSONに変換される
• JDBCドライバが提供されているので既存ツールとの連携が可能

k-NN サーチ

• 教師なし機械学習アルゴリズム
• 類似検索
  • 画像認識アプリなど
• 近接
• Mapper plugin
  • knn_vector データ型
    • ドキュメント内のベクトルを表示
• Search plugin
  • knn クエリ句
    • カスタムクエリ句の定義

Amazon ES まわりのアップデート

• Kinesis Data Firehose から VPC内のAmazon ESに流し込めるようになった
• ユーザ辞書ルールによるカスタム辞書の使用
  • カスタム辞書に固有名詞やドメイン用語などを登録することで正しく判別できるようになる
• カスタムパッケージによるカスタム辞書ファイルの使用
  • 大規模なカスタム辞書を登録する際に使用

まとめ

2時間セミナーでしたが、充実した内容だったのであっという間に終わった感じがしました。Elasticsearch そのものの説明はあまりなかったので何も知らない人にとっては難しいかもしれません。逆に Elasticsearch についてはおおよそ分かるけど、Amazon ES について聞きたい人にとっては十分すぎる内容ではないでしょうか。
シャード数やストレージ量に公式があるのは知りませんでした。これは使えそうです。Amazon ES はセキュリティや監査ログなどまだまだ欲しい機能があるので、Open Distro for Elasticsearch の機能をどんどん取り込んでほしいなぁと思いました。

実際に Amazon ES と他の AWS サービスとの連携について知りたい人はワークショップが公開されていますので、GitHub リポジトリを読んで手を動かしながら進められるとよいのではないでしょうか。

aws.amazon.com