Ltech#21 コピー&アンドカスタマイズできるSolr

コピー&カスタマイズできるSolr環境の ためにEC2 Image Builderを活用した話 株式会社LIFULL テクノロジー本部 事業基盤ユニット プラットフォームグループ 加藤 宏脩

自己紹介 デプロイフロー変更の経緯 EC2 Image Builderについて 目次 結果 実装した感想 まとめ

自己紹介 加藤 宏脩 ソフトウェアエンジニア 2018年に新卒でLIFULLに入社 Solrの環境周りの開発、外部公開APIの開発を担当

今回の概要 コピーやカスタマイズした環境を素早く作れるようにしたかった SolrのデプロイフローにEC2 Image Builderを使うようにした 導入の結果、良かった点や苦労した点について話す https://lifull.com/news/22847/

• https://lifull.com/news/22847/

資料内の用語解説 Apache Solr: OSSの検索エンジン AMI: Amazonマシンイメージ EC2 Image Builder: AMIやコンテナイメージを自動で作成するAWSの サービス

デプロイフロー変更の経緯

目的 - 不確実性の高い領域において実験的なユーザー体験の提供とその検証 を素早く繰り返し行えるようにしたい - 開発者がSolrの環境を用意して検証を行えるようにしたい

課題 現行のデプロイフローを使って、それを実現しようとすると。。。 検証環境が増えると 管理しきれない 今のデプロイフローは 学習コストが高い 検証環境A 検証環境B 検証環境C プラグイン？ バージョン? スキーマ？ プラグイン？ バージョン? スキーマ？ プラグイン？ バージョン? スキーマ? どこを修正するの？ 動作確認のやり方は？ 開発者A https://lifull.com/news/22847/

• https://lifull.com/news/22847/

EC2 Image Builderについて

Image Builderを構成する要素 Build component: パッケージのインストールやAMIを構成する処理の定義 Recipe: イメージに必要な構成を生成するBuild componentを定義 Infrastructure: AMI構築時の実行環境の設定を定義 Distribution: 出力するAMIの設定(region、公開範囲の設定等) Image pipelines: AMIを構築するためのオートメーションの設定

Image Builderを構成する要素 Pipeline Infrastructure Distribution Recipe 処理開始 Component 1 Instance Component 2 Recipeに書かれた処理を 上から順番に実行する AMI出力 AMI

結果

Image Builderを導入した結果 - Solrを含む全てのプラグインをコンポーネント化することで自由に組み替えら れるようになった リソースの一覧性が高くなった AMIを使ってインスタンス建てるだけで動作確認が可能になった - AWS TOEでローカルでの動作確認もできる https://lifull.com/news/22847/

• https://lifull.com/news/22847/

以前のデプロイフロー(まだ使われてるけど) デプロイ実行 AMI用 インスタンス 起動 プラグインのインストール ファイルダウンロード テスト AMI作成 インスタンス 起動

Image Builder導入後のデプロイフロー Image Builder AMI デプロイ実行 AMI IDの選択 インスタンス 起動

実装した感想

良かった点 1. 環境のコピーがしやすくなった - 現行のSolrと同じAMIを利用してデプロイするだけでコピーできる 2. Solrのカスタマイズをしやすくなった - Solr本体、プラグイン、exporter等自由に入れ替えてバージョンの上げ下げ もできるようになった 3. 環境構築の高速化 - AMIを構築するだけで20~30分かかるのが、先にAMI作っておくだけでその 分時間が減る

苦労した点 1. バージョン管理 2. テスト 3. schemaやクラスタごとに異なる設定

苦労した点 1. バージョン管理 Image Builderはバージョンで悩みやすい - Componentのバージョン Solr、Pluginのバージョン Recipeのバージョン

苦労した点 1. バージョン管理 > Solr v8.8.2専用のRecipeを作って、それ用のComponentを作る？ > ComponentのバージョンはSolrのバージョンと一致したほうがいい？ > Infrastructure,pipeline,distributionはレシピのバージョンごとに作り直 す？

苦労した点 1. バージョン管理 > Solr v8.8.2専用のRecipeを作って、それ用のComponentを作る？ Recipeの数だけ無限にComponentを作らなくちゃいけなくて、 無限にComponentが増えちゃう ComponentのパラメーターにSolrのバージョンを渡したら、 そのバージョンのSolrをインストールするComponentを作った

苦労した点 1. バージョン管理 > ComponentのバージョンはSolrのバージョンと一致したほうがいい？ これをやるとComponentの処理内容を書き換えるときに破綻する Component名はSolrとしてバージョンはパラメーターで渡すか、 Solr882のような名前で作るのが良さそう

苦労した点 1. バージョン管理 > Infrastructure,pipeline,distributionはレシピのバージョンごとに作り直す？ Infrastructureはインスタンスタイプとか引きづられちゃうので一つのプロジェクトごとく らいがちょうどよさそう pipelineは出力イメージの表示を見ていると、Solrというくくりではなくプロジェクトごと がよさそう distributionもAMIの名前になるので、プロジェクトごとがよさそう

苦労した点 1. バージョン管理(ファイル構成) Component側 _sample_component └── 0.0.1 ├── files/config.txt └── template.yaml Application側 _sample_application ├── distributions │ └── 0.0.1.yaml ├── infrastructures │ └── default.yaml ├── pipeline.yaml └── recipes └── 0.0.1.yaml

苦労した点 2. テスト Image Builderには動作を保証する処理のフェーズが３つある - build componentのvalidate - build componentのtest - test component 実行の順番 build > validate > test > test component(testとtest componentは同時だっ たかも)

苦労した点 3. schemaやクラスタごとに異なる設定 イミュータブルなAMIを作って汎用的になったけど、クラスタごとの設定ファイ ルは置けなくなった - インスタンス起動時やメインのアプリケーション起動前などのイベントに発火 してスクリプトを実行する機能をAMIに追加 - インスタンスを起動するときに、UserDataにスクリプトがs3 bucket名等設定 を渡してダウンロードするようにする

今後の展望 - Solrのバージョンアップをトリガーに自動で最新バージョンAMIを作る - 性能テスト、回帰テストの自動化までできると最高 - コンテナ化 - EC2 ImageBuilderの出力をDocker imageにすることもできるみたい（試し てない）

まとめ - SolrのデプロイにEC2 Image Builderを使ってみたけど結構良かった - パーツを組み替えるみたいに、設定をいじることができる - EC2 インスタンスからコンテナに移行するみたいなこともしやすいかも - バージョン管理はちょっと苦労するかも

参考資料 - https://aws.amazon.com/jp/image-builder/

• https://aws.amazon.com/jp/image-builder/

ありがとうございました