BUYMAの検索周りを担当しているエンジニアの伊藤です。BUYMAではSolrを利用した検索システムがいくつかあります。今回はデータボリュームが一番大きい検索システムをターゲットとして、インフラ周りを含め全面的にシステムの刷新を行いました。既存の検索システムがどういったものだったのかなぜシステム更改が必要だったのか(どういう課題があったのか)更改後の検索システムはどういったものか今後の課題について等々についてご紹介したいと思います。既存の検索システムについて既存の検索システムは下記の通り、シンプルという点ではとても素晴らしいものでした。下記のような問題を抱えている状況でした。スケールアウトしない構成であるスケールアップの限界Solrのバージョンが古い本番環境のデータを利用した検証が難しい開発担当者にもSolrの知識が必要とされる問題に気付けない以降でその内容について補足していきます。スケールアウトしない構成である検索システムはデータ増とアクセス増の2軸でスケールアウト構成を取る必要があります。アクセス増にはSolrサーバを追加することで対応できるようにはなっていましたが、該当の検索システムはアクセス数というよりデータが多いことが特徴でこのデータ増に追従出来なくなっていました。GCが頻発するようになっていたため、暫定対処としてAWS側に移行し、GCチューニングを行いました。この対応も一時的なもので、データ数自体は日々増加している状況の中で使用しているGCのアルゴリズム的に、メモリを増やしてどうこうできる状況ではなくなっていました。STWのインパクトが大きくなるという負のループに陥るSolrのバージョンが古い既存の検索システムで利用しているSolrのバージョンは3.2.0でしたバージョンが古くても通常時の運用にはそれほど支障はありませんが、何か問題があった場合の調査が大変でした(ドキュメントが見つからない)またSolrのバージョンupに伴いindexing/検索性能はupしていますので、性能面でのデメリットであったり以降のバージョンで提供された様々な機能が利用できない等のデメリットがありました本番環境のデータを利用した検証が難しい既存システムで本番環境相当のデータで検証する際にはindexing処理だけで数日かかるという状況で、環境構築自体がハードルとなっていました。開発担当者にもSolrの知識が必要とされるSolrへの検索時はphp、rubyといったクライアント側でSolrのクエリを組み立てて実行していました。クライアント側を担当する開発担当者はその時々で変わり、ある程度はSolrを知っている人もいれば、全く知らない人まで様々です。Solrのクエリは書き方によってはキャッシュを使えていなかったり、または逆にキャッシュを無駄に汚してしまったりと、同じ検索結果を得るにしてもある程度Solrの知識を必要とします。問題に気付けない必要なデータやログが適切に可視化され監視されていないため、サービス影響、ユーザ問い合わせがあって初めて問題に気付くケースがありました更改後の検索システム上記で挙げた課題感を解決するために設計したアーキテクチャが下記になります。耐障害性の向上プラットフォームにKubernetesを採用し、想定外のアプリケーション停止、ノードdown時にもセルフヒーリングで自動復旧可能マイクロサービス化(隠蔽化)アプリケーション〜Solr間に検索APIを新たに用意。これによりアプリケーション側はSolrの独自クエリを意識することなく、検索APIを介したシンプルなI/Fをベースとした開発が可能に。今回せっかくシステム更改するならCloudNativeなシステムにしたいという思いがありこのような構成にしました。監視、ログ運用周りも今回の対応と合わせて刷新したことで対応範囲が広くなり苦労した点も多くありました。ここではいくつかピックアップして紹介したいと思います。Solr/ZookeeperをKubernetes上に構築、運用した経験がないSolrに関してはあまり構築事例もなく問題に遭遇した際の解析に難航リソース設計、ログ周りなど、コンテナ/Kubernetesだからこそプラスαで考慮しなければ行けない点が多々あった監視、ログ運用基盤の検討コンテナ/Kubernetesベースのシステムをどう監視すべきか?ログはどう扱うべきか?検索APIの設計、開発I/F仕様どうするか?開発しながらSolr/Zookeeper周りの設定や問題対応をするのが辛いSolrバージョンアップによる未知の問題対応indexing処理周りで問題多発SolrCloudかつDIHで並列indexing処理を行うこと自体が事例がなく、色々とはまる今後に向けてシステム更改により当初挙げていた課題感というのは概ね解決することが出来ました。今回のようなシステムを構築、運用したことでてきた新たな課題や、まだまだ改善が必要だなと思えるところもあります。indexing処理などはクライアント側の処理と密になっている箇所がまだまだあり、今後もブラッシュアップが必要Solrのような複雑かつstatefulなアプリケーションは運用がやはり大変。operatorを利用するなどして運用をもっと楽にしつつ、属人性もなくしていきたい。パーソナライズサーチなど)や自然言語処理や機械学習を活用したサービス導入なども積極的に行っています。今回技術的なところにはほぼ触れませんでしたが、ここどうなってるの?など少しでも興味、関心を持たれたら是非お気軽にお話だけでも聞きにいただければと思います。こんにちは、初投稿になります。今年の1月からエニグ...2019-12-24Rubyでのデザインパターンの使用例を説明する!!こんにちは、サーバーサイドエンジニアの平井です。こちらは、...2019-12-22GitLabCI+ArgoCDを使って、「マージしたら5分でKubernetesへデプロイ」を実現す...こんにちは。インフラチームの夏目です。読者になるスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。