この記事は HowTelevision Advent Calender 2023 の3日目の記事です。2日目は根本さん (
id:masa5555how) の「フロントエンドのlinter/formatterをxoに統一し、ルールの議論から解放される - ハウテレビジョン開発者ブログ」でした。
初めまして、ソフトウェアエンジニアの川原 (
id:rrih) です。
外資就活ドットコムの PHP で作られた検索システムは元々 Groonga を使用していました。一方で、一部のバックエンドを Go で別リポジトリに移行する中、検索処理の一部に Elasticsearch (OpenSearch)を導入しました。しばらくの間 Groonga とElasticsearch が混在している状態が続いていました。これはそれぞれの保守・運用コストが高いままで、新規の開発メンバーにとっても学習コストがついて回ることになっていました。技術負債解消の文脈で、既存の Groonga による実装を廃止し、Elasticsearch に移行することにしました。
移行のメリット
Groonga と Elasticsearch の混在による保守コストの削減
Groonga に関連するリポジトリの数は10あり、関連ファイルは100程度ありました。そして Elasticsearch に関連するリポジトリ、関連ファイルも同程度ありそれぞれで同等の処理を行っていました。そのため検索処理周りの実装の認知負荷も高まっていたと思われます。
OpenSearch の利用による AWS マネージドサービスへの統一
弊社では AWS で統一していく方針があり、Groonga から OpenSearch に変更することで AWS にさらに寄せられることになります。既存の AWS サービスに合わせて管理がより容易になり、保守性、セキュリティ面でも AWS の恩恵を受けられるようになります。
Groonga に関連する実装の削除
前述した内容と一部重複しますが、Groonga 関連の処理を行うファイルが削除されるためおおよそ半分削除できることになります。これにより保守コスト、学習コストが削減されることになります。
移行手順
Groonga からデータを参照している箇所を Elasticsearch に変更する
- 外資就活の検索画面のバックエンドに Groonga が使用されているため、Elasticsearch で置き換えて実装
- 既存の Go のリポジトリで一部 Groonga を呼び出している箇所があるため、それぞれ Elasticsearch で同等の処理に置き換える
元のコードは CakePHP の Controller から Groonga を呼び出していましたが、これを Go の WebAPI 経由で Elasticsearch にクエリを投げるように変更します。企業、募集、コラム、特集コラムそれぞれに応じて必要な情報を各種テーブルから取得し、データを加工するようにしています。
Groongaへデータ変更を行っている箇所を Elasticsearch に移行する
- 管理画面から行われるデータ変更を Groonga へ連携している部分を Elasticsearch に置き換える
- バッチ処理でデータを Groonga へ定期的に連携している部分を Elasticsearch へ移行する
Groonga 自体を削除する
動作確認後に Groonga を削除します。
苦労した部分
技術的な部分
私自身、Groonga と Elasticsearch の経験がなかったため、このプロジェクトは私にとって大きな学習機会でした。Elasticsearch のクエリの基本的な操作や AWS のマネージドサービスの使い方など学ぶことになりました。
プロジェクト管理
移行中に予期していなかった既存の Elasticsearch を利用したシステムのエラーや障害の対応が必要でした。これらのトラブルのためにタスクの優先順位を変更する必要がありました。これにより計画通りに進めることには一定の難しさがありました。
まとめ
移行を通じて元の処理のロジックと RDB の周辺テーブル、ドメインについて知ることができました。また、Groonga、Elasticsearch それぞれの API、クエリ操作等で使用するライブラリについてキャッチアップすることができたと思います。 これらのタスクは参照、変更の依存関係が広く、取り組む順序については注意深く意識する必要があります。
最後に
弊社ではソフトウェアエンジニア募集中です。
