こんにちは、技術3課の城です。

これまでにいくつかElasticsearch Serviceに関するブログを書きましたが、ほぼほぼ初心者の状態からなんとか運用するところまでこぎつけました。初めからこのドキュメントをきちんと読んでおけば、、、というものが多々あったので簡単ではありますが、まとめておきます。

ついでですが、これまで私が書いたAmazon Elasticsearch Service関連のブログです。【Amazon Elasticsearch Service】CloudTrail、VPC Flowlogsを集約する【Amazon Elasticsearch Service】VPC FlowlogsのRejectをアラート検知、Slack通知してみました【Amazon Elasticsearch Service】Lambdaによるインデックスローテーション

1.サイジング

サイジングについては、次のドキュメントを確認しておきましょう。 https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/sizing-domains.html

大まかなところでは下記の流れで設計、構築していきます。

1.ストレージ要件の確認
2.シャード数の検討
3.インスタンスタイプ、インスタンス数の検討
4.構築後、テスト、アラート設定

では、以下詳細説明していきます。

1.1 ストレージ要件

ストレージ要件を算出する際にレプリカシャード数を考慮する必要がありますが最低１以上が推奨です。ドキュメントの記載にもあるとおり、レプリカシャード数を増やすことで検索パフォーマンスを改善することができますが、インデックス全体と同量のディスク容量が必要とされます。レプリカシャード数の上限は[データノード数 -1]となり、越えている場合は書き込みできずにクラスターステータスが黄色となるので注意しましょう。私も当初疑問に思っていたのですが、データノード数1のドメインのクラスターステータスが黄色となるのは、デフォルトのレプリカシャード数が1に設定されているためです。

ストレージ要件についてはドキュメントに下記計算式の記載がありますので、計算してみましょう。

ソースデータ x (1+ レプリカの数) x (1 + インデックス作成オーバーヘッド) ÷ (1 - Linux 予約スペース) ÷ (1 - Amazon ES のオーバーヘッド) = 最小ストレージ要件

※各項目の詳細については前述のサイジングについてのドキュメントをご覧ください。

1.2 シャード数

プライマリシャード数についてはシャードのサイズが10-50GiBにすると良いと記載があります。大きすぎても障害となりますし、小さすぎるとパフォーマンスの問題やメモリ不足のエラーが発生する可能性があると記載されています。デフォルトはプライマリシャード数：５、レプリカシャード数：1となっていますので、ローリングインデックスの場合は検討した内容でテンプレート設定をしておきましょう。【Amazon Elasticsearch Service】CloudTrail、VPC Flowlogsを集約するにて「2. Elasticsearchのインデックステンプレートの設定」として紹介していますが、テンプレートのjsonファイルに下記例（プライマリシャード数:10,レプリカシャード数:2）のように記載することで設定できます。

{
  "settings": {
    "number_of_shards": 10,
    "number_of_replicas": 2
  }
}

1.3 インスタンスタイプ、インスタンス数

インスタンスタイプやインスタンス数については、まずはAmazon Elasticsearch Serviceには制限がありますので、確認しましょう。 https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/aes-limits.html

インスタンスタイプによりEBSサイズの制限が異なるので、注意しましょう。データノード数については、専用マスターノードを使う場合は2以上、使わない場合は３以上が推奨です。シングル構成にて障害が発生した場合、すぐには自動復旧しないのでサービスダウンやデータロストの可能性もあります。また、下記トラブルシューティングのドキュメントには障害が1日以上自動復旧しない場合、AWSサポートに問い合わせをしてくださいとの記載もあるので、可用性確保の意味で複数台構成を強く推奨します。 https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-yellow-cluster-status

また、よりパフォーマンスとクラスターの信頼性を向上させたい場合は専用マスターノードを利用しましょう。 https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-managedomains-dedicatedmasternodes.html

1.4 テスト、及び、Cloudwatchアラームの設定

マネージドサービスではあるのですが、障害の発生などはきちんと押さえておく必要があります。下記のドキュメントに推奨アラート設定が記載されているので、こちらを設定しておきましょう。 https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/cloudwatch-alarms.html

CloudWatchのメトリクスが正常であり、クエリなどを実行してみてパフォーマンスに問題がなければテストは成功となります。サイジングのドキュメントに記載があるとおり、大規模なクラスターからスケールダウンしていく方が容易です。実際、私は逆を実施してしまってスケールアップしていったのですが、相当苦戦してしまいました。

2. ローテーションの実装

ローリングインデックス（継続的にデータを投入し、保存期間などを決めてローテーションする）の場合、インデックスのローテーションが必要となります。こちらについては、AWS ドキュメント【Curator を使用した Amazon Elasticsearch Service でのデータの更新】を参考にLambdaにて実装したブログを書いていますので、こちらもご参考いただければと思います。【Amazon Elasticsearch Service】Lambdaによるインデックスローテーション

3. スナップショットからの復元について

Amazon Elasticsearch Serviceでは自動でスナップショットが作成されますが、下記のドキュメントではスナップショットからの復元方法や手動でのスナップショット取得について紹介されています。緊急時に備えて、こちらについても目を通しておくべきでしょう。 https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html

最後に

Elasticsearch Serviceを運用するにあたり確認したこと、ドキュメントについてまとめてみました。マネージドサービスがゆえに障害が発生したからと言ってサービス再起動やインスタンスの停止起動などは自身の手ではできません。そういった事情から、より可用性を考慮して設計すべきところ、監視すべきところがあるので気を付けたいところです。

どなたかの助けになれば幸いです。