Amazon Elasticsearch Service, Amazon CloudSearch
# Amazon Elasticsearch Service, Amazon CloudSearch
https://d1.awsstatic.com/webinars/jp/pdf/services/20200623_aws_blackbelt_amazon_es.pdf
https://d1.awsstatic.com/webinars/jp/pdf/services/20160323_AWS-BlackBelt-CloudSearch_AmazonES.pdf
## 全文検索とは
## Elasticsearch とは
- ログ分析や検索に関する様々なスースケースで利用できる、分散型RESTful 検索/分析エンジン
- コンポーネント
- 可視化
- Kibana
- 分析/検索
- Elasticsearch
- 収集
- Log stash
- beats
- データ挿入から活用までの流れ
- データの持ち方
- 論理的なデータの持ち方
- Index の中にDocument を持つ。Documentの中にフィールドとしてアイテムが格納される
- 物理的なデータの持ち方
- マスターノードとデータノードに分かれる
- データノードではプライマリーシャードとレプリカシャードが作成され、可用性を向上させている
## Amazon CloudSearch 概要(2011-)
- 自動拡張するフルマネージド検索サービス
- Auto Scaling
- Auto Partitioning
- Apache Solr のマネージドサービス
- Indexing
- 全ての喉にELB経由で均等にアップロード
- ファイルをS3に保存
- メタデータはDynamoDBに保存
## Amazon Elasticsearch Service の概要
- 概要
- Elasticsearch と Kibanaを簡単にデプロイ・管理・スケールさせることが可能なフルマネージドサービス
- エンタープライズグレードのセキュリティ、アラート、SQLなどにより強化されたElasticsearch のディストリビューションであるOpen Distro を採用
- 利点
- フルマネージド
- 柔軟性
- コスト効率
- RIも選択できる
- 高可用性
- セルフヒーリング
- モニタリング
- マルチAZ
- 自動バックアップ
- スケーラブル
- スケール
- バージョンアップ
- パッチ適用
- セキュア
- VPC内へのデプロイ
- Cognito によるログイン
- API
- サポートするインスタンスサイズ
- インスタンスサイズによって最大EBSサイズやHTTPリクエストペイロードの最大値がことなる
- 世代が古いと古いESバージョンが利用できるが、データ暗号化や詳細アクセスコントロールが設定できないなど制約も多い
- 推奨アーキテクチャ
## ログ分析
- データ投入
- ログ分析の場合、Kinesis Data Firehose 経由でストリームデータを直接ESに入れるのが定番（別アカウントからのインプットにも対応）
- CloudWatch Logs サブスクリプションにより、Lambdaを経由したストリームデータ投入も行える
- Lambda等からElasticsearch のBulk API を叩いてS3のデータを定期的にインポートするといったことも可能
- SQLインターフェースのサポート
- Ultrawarm ノード
- 大規模ログ分析を低コストで実現するためのノードタイプ
- S3に保持したデータに対してクエリを実行
- 読み取り専用
- クラスタ横断でのクエリ実行
## 検索
- 日本語全文検索用のプラグイン
- ユーザ辞書ルールによるカスタム辞書の使用
- Kuromoji で形態素解析をする時にユーザ登録の固有名詞を教えておく場合に利用
- カスタムパッケージによるファイルベース辞書の使用
- kNNによる最近傍探索
## 管理
- Indes State Management(ISM) でインデックス管理の自動化
- ISM機能により、日・週・月単位で新しく作られるインデックスの管理を自動化、従来Curator で行う必要があったものをAmazon ES 側で設定可能に
- Kibana 上でインデックス管理ポリシーを設定・管理
- _template API と併用することで新しいインデックスうにポリシーを自動で反映
- ロギング
- Elasticsearch API のログ
- 以下をCloudWatchに出力
- インデックススローログ（ドキュメントの追加・削除・更新）
- 検索スローログ（検索クエリ）
- エラーログ
- デフォルトでは無効になっている
- 設定APIのログ
- APIコールのログをCloudTrailに出力
- 検索APIベースのアラート
- Elasticsearch のクエリを指定して、一定の閾値を超えた場合にアラートをあげることが可能
- Slack 等に通知を飛ばす
- Anomary Detection をトリガーにしたアラートの実行
- Random Cut Forest アルゴリズムを用いた時系列の異常検知機能
- 設定変更
- ドメイン変更時にはBlue/Green デプロイによって行われる
- 一時的に倍のノードになりデータノードとマスターノードに負担がかかる
- 深夜帯に行うことを推奨
- スナップショット
- クラスターのバックアップ
- 自動スナップショット
- バックアップ
- １時間ごと14日間作成
- 手動スナップショット
- バックアップ / データ移行
- S3にデータを保存するため料金に入れる
運用のベストプラクティス
## セキュリティ
- 認証と認可
- IAMベースのAmazon ESドメインに対するアクセスポリシー
- Logstash のAWSプラグインを利用することでAWSのクレデンシャルを利用してデータ投入できる
- Open Distro ベースのドメインないサブリソースに対する詳細なアクセス権限管理
- ユーザー
- ES内部で管理
- Cognito 連携
- 詳細な権限管理
- インデックスレベル
- ドキュメントレベル
- フィールドレベル
- Kibanaのマルチテナンシー
- 暗号化
- VPC からAmazon ES にプライベート接続
## Amazon CloudSearch と Amazon ES の比較
- CloudSearch
- 検索エンジン
- Solr
- CloudSearch API を利用して検索
- AutoScaling でスケールする
- インスタンスストアにデータを保持するため大量データ保存は厳しい
- ログの可視化はできない
- リアルタイムデータ取り込みは制限がある
- Amazon ES
http://dev.classmethod.jp/cloud/elasticsearch-service-vs-cloudsearch/
- 決まった仕様のCloudSearch か 高いカスタマイズ性のElasticsearch
- 1対多のデータ構造対応ならElasticsearch
- 運用で楽がしたい場合はCloudSearch
## 雑感
AWS のマネージドElasticsearch。IAMによる制御に加え、OSS自体についている認証・認可の仕組みを利用して、ドメイン・ドキュメント・インデックスレベルで細かく制御をすることができる。
料金がノード間の転送料金はかからないが、Amazon ES からのin/out がかかるのでアプリの仕組みによってはお金がかかるようにも思える。
そもそも運用コストがElasticsearch が高いので、Amazon ESを利用することで運用コストをかなり減らすことができると思う。
それよりも仕様が決まっていて、運用で楽がしたいのであればCloudSearch を利用することが選択肢となると思う。
