はじめに
こんにちは、アプリケーションチームの小沼です。
LANSCOPE EMクラウド版（以下、EMクラウド）は現在、多くのデバイスの情報を管理しています。取得情報の中で、IT資産情報の管理にはAWSの「Amazon OpenSearch Service（以下、OpenSearch Service）」を利用しています。
これまで、OpenSearch Service の負荷軽減について多くの取り組みを実施してきましたが、AWS のサポートケースや弊社を担当頂いているSolutions Architectさんから一番推されていた「シャードサイズの見直し」については、まだ取り組めていませんでした。今回、このシャードサイズ見直しに取り組むことができましたので、そのアプローチと結果についてご紹介します。
シャードサイズ見直し以外の取り組みについては、以下の記事をご参照ください。
シャードサイズ見直しのアプローチの種類
シャードサイズを見直すアプローチは大きく2つあります。
- 保存するデータ量を見直す
- シャード数を増やす
EMクラウドでは「1. 保存するデータ量を見直す」を採用しました。
「1. 保存するデータ量を見直す」の実施
このアプローチの大まかな流れは以下の通りです。
- 検索に使う項目と使わない項目の洗い出し
- 自動インデックス作成を無効にした新しいインデックスの作成
- ReIndex の実行
1. 検索に使う項目と使わない項目の洗い出し
OpenSearch Service のデフォルト設定では、書き込まれたデータに対して自動でインデックスが作成され、検索可能な項目として保存されます。そこで、EMクラウドが検索に使う項目と使わない項目を精査しました。注意点として、OpenSearch Serviceに保存する際にインデックスを無効にすると、その項目は検索にヒットしなくなります。そのため、現在検索に使っている項目だけでなく、将来検索に使う可能性のある項目も考慮して調査を行いました。
具体的な流れとしては、
- AWS 構成図からOpenSearch に読み書きを行っているLambdaの一覧を作成
- シャードサイズを見直す対象のインデックスに対して、GETの処理を行っている処理の一覧を作成
- GETに使っているキーの一覧を作成
- PLにGETに使っているキーを共有し、今後のロードマップにGETに使いたいキーを増やす計画がありそうかを確認
- 残すべき検索可能項目を決定
のように行いました。
2. 自動インデックス作成を無効にした新しいインデックスの作成
検索に必要な項目の精査が終わり次第、新しいインデックスを作成します。以下のように、mappings で検索に使わないフィールドのインデックス作成を無効化する設定を行います。
{ "mappings": { "properties": { "hoge": { "index": false, "type": "text" } } } }
3. ReIndex の実行
新しいインデックスを作成できたら、ReIndexを実行し、新しいインデックスにデータをコピーします。
{ "source": { "index": "old_index" }, "dest": { "index": "new_index" } }
ここで注意する点として、ReIndexでコピーされる範囲は、ReIndex を実行した時点までのデータです。データをコピーしている最中にも、EMクラウドはデバイスのIT資産情報を受信し、OpenSearch Serviceへの書き込みを継続します。OpenSearch Serviceに保存されているIT資産情報はTB単位のため、コピーするだけでも数時間要します。
EMクラウドはIT資産管理ツールのため、IT資産情報が数時間とはいえデグレ（過去に巻き戻る）を抑える必要があります。そこで、収集したデータの完全性を担保するために一時的に資産情報の更新を止め、その期間にReIndexの作業を行うことにしました。メンテナンスリリースで資産情報の更新を一時的に止めるという動きは、製品としても初めての試みでした。
リリース後にシャードサイズを確認すると、およそ10分の1まで減らせることができました。 「どれだけ不要な情報を保存していたんだ」と思うと同時に、「やってよかった」と心から思える取り組みでした。
「2. シャード数を増やす」を採用しなかった理由
シャードサイズの見直しには、シャード数を増やすというアプローチもあります。1シャードあたりの容量は30~50GiBが推奨されており、以下の計算式でプライマリシャードの概数を求めることができます。
(ソースデータ + 拡張の余地) * (1 + インデックス作成オーバーヘッド) / 必要なシャードサイズ = プライマリシャードの概数
EMクラウドでは、シャード数を増やすアプローチを採用しませんでした。その理由は以下の通りです。
メンテナンスコストの増加
一度に大きな「拡張の余地」を設けることで、定期的なシャードサイズのメンテナンスを回避できるように思えます。しかし、その場合、拡張直後はシャードサイズが大幅に減少します。シャードサイズが小さいシャードが大量に存在すると、OpenSearch Serviceのパフォーマンスが低下します。そのため、1シャードあたり30~50GiBを維持することが重要です。結果として、定期的なメンテナンスが必要となります。データノードの見直し
シャード数が増えると、それに伴ってデータノードも見直す必要があります。ベストプラクティスとして、データノード数はシャード数の倍数であることが推奨されています。これにより、AWSの維持コストも増加し、長期的な運用コストが高くなります。
これらの理由から、EMクラウドでは「1. 保存するデータ量を見直す」アプローチを採用しました。
おわりに
今回、シャードサイズの見直しに取り組み、その結果をリリースすることができました。この記事では、具体的にどのようなアプローチを取ったのか、そしてその過程で直面した課題について詳しくご紹介しました。
特に、ReIndexを実行する際にReIndexを実行した時点までのデータしかコピーされない動きに対して、新しいインデックスに切り替える際のデータの完全性に懸念がありました。そのため、綿密な事前調査を行い、データの完全性を担保する最適な方法を模索しました。最終的には、サーバーの一時停止を含む対策を講じることで、この課題を克服しました。
データの移行部分以外は比較的シンプルで、気軽に試すことができる内容です。ただし、自動インデックス作成の機能を無効にすると、OpenSearch Serviceで検索のキーとして使用できなくなる点には注意が必要です。
今回の取り組みが、OpenSearch Serviceの負荷軽減に悩んでいる方々の参考になれば幸いです。
