天パは病気だと思うんですよ。だって29年間治らないんです。
約1年ぶりに登場して前回と同じ口上です。rinx2です。
はやくアバターで勤務できないかなぁ。
先日私が担当するシステムにて、Elasticsearchを7.4へバージョンアップしました。
本日はその際のできごとをいくつかご紹介できればと思います！
Elasticsearchとは
Elasticsearchは、Elastic社が提供するApache Luceneをベースに開発されたオープンソースの全文検索エンジンです。
全文検索とは、文字列に含まれるテキスト全体を対象とした検索をいい、
全文検索エンジンは、検索対象のテキストからインデックスを作成し、文字列による検索を行うソフトウェアのことを指します。
具体的な用途については、下記の公式リンクをご覧いただければと思います。
バージョン選定
バージョンは、Elasticsearchの操作を行うライブラリが対応するバージョンに合わせます。
ひとことで書くと端的ですが、ライブラリのプログラム言語のバージョンや、言語の動作環境をパッケージで扱うか等、SREチームと協力して進行します。
変更点の確認
今回のバージョンアップは5系→7系になります。
中でも大きな変更点は「type構造の廃止」と「joinによる親子関係」です。
従来のインデックスでは、type構造によって同一インデックス内に複数のインデックス構造を持てました。
これは単純にインデックスの種類であったり、インデックスの親子関係を築くものでした。
7系ではこれを廃止し、インデックスには単一の構造だけ持つようになりました。
代わりにjoinという構造を設け、インデックスの種類や親子関係を保持することができます。
これによりクエリパラメータのみで、欲しいドキュメントを扱えるようになります。
詳細については下記のリンクをご覧いただければと思います。
その他軽微な変更点は下記した感じです。
- Content−Type指定必須化
- boolean typeの設定値縮小（エイリアス廃止）
- string typeの廃止
インデックスの作り直しは必須ですので、これらは適宜修正しておけば問題ありません。
移行で見つかったこと
バージョン選定や変更点を確認した後は、いよいよ移行作業です。
SREチームに検証環境を用意してもらい、アプリの動作確認を行っていきます。
ドキュメントの種類を特定する
従来のインデックスはtype構造によりURLレベルで分かれていたため、アクセスすれば対象のドキュメントを取得できました。
今回の変更でインデックスは単一の構造になったため、join構造のnameを指定してドキュメントを特定します。
GET my_index/_count
{
"query": {
"match": {
"join": "my_child"
}
}
}
検索ヒット数を正しく取得する1
searchAPIの検索結果が1万件を越えている場合、レスポンスのヒット件数が1万件で頭打ちになってしまいます。
そのため、track_total_hitsを指定してクエリを発行します。
GET my_index/_search
{
"track_total_hits": true,
"query": {
"match": {
"join": "my_child"
}
}
上位の結果だけ必要な場合は計算がない分高速化できるため、悪いわけではないです。
検索ヒット数を正しく取得する2
from-sizeで1万件目以降を取得する場合、デフォルトのインデックス構造だとエラーが返却されます。
そのため、インデックス作成時に任意の値の「max_result_window」を指定します。
上限を十分に大きくすればエラーは出せんが、一度は指定の位置までデータを読み込むためコストが大きくなってしまいます。
ElasticsearchとしてはscrollAPIによる連続取得が一般的なため、そちらを検討した方が良いかも知れません。
正常なインスタンスを用意する
本番化リハーサルを実施した際、ドキュメントの登録件数が足りないという事象が発生しました。
アプリのエラー出力はなく、Elasticsearch（AWS SaaS）もエラー出力はありませんでした。
原因を確認する用材が見つからない中、Elasticsearchで400系のエラーが出ていたことがモニタリングにより分かりました。
そのため、別のインスタンスを用意して再登録したところ、正常に全件登録ができました。
インスタンスガチャと言うそうで、現実に起こりました。
ドキュメント登録速度に限界がある
情報量は少ないものの、登録件数が数百万件になるドキュメントの登録を行った際、非常に時間がかかるという事象が発生しました。
バッチサーバ、Elasticsearch共に負荷状況が高くないため、単純にリクエスト−レスポンスが遅いことが分かりました。
（一度に1件ずつ大量の登録を想定していないと考えられる）
今回は並列実行可能な処理であったため、screenコマンドを利用して速度を確保しました。
運用で見つかったこと
検証と課題解決が終わり、いよいよリリース、運用です。
SREチームに用意してもらった監視基盤で日々の状況を追っていきます。
現状、新たな課題は見つかっておらず、引き続き監視を続けていきます。
さいごに
今回のバージョンアップで受けた恩恵はElasticsearchのものだけではなく、Kibanaでの監視や運用で出来ることが増えた等もあります。
環境を最新にすることで、やれること、やりたいことが増えていくのは楽しさがありますね。
大事無くプロジェクトを終えられたのは、ひとえに堅実なメンバーと環境にあると思っています。
クイックの組織風土についてはいくつか記事がありますので、よろしければカテゴリからご覧いただければと思います。
以前私が投稿した記事をこっそり。
＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／
