検索システムの運用コストについて

検索システムのAWS化において一番意識したのは、運用を楽にするという点です。元々オンプレで動いており、Jenkinsを使って検索エンジンの再起動をしていましたが、これがかなり運用上の負担になっていました。これについては記事の中でも言及していますが、ALBから外して再起動してALBにつけ直すという作業を10台分順番に実施するのに1時間以上の手オペが発生するというのが運用上の一番の負担になっていたため、特にデプロイコストを楽にするという点を考えました。

AWS化するときに何を使えば運用コストを減らせるかを考えたときに、EC2・ECS・EKSという選択肢の中でEKSを使用することにしました。理由としては検索エンジンというステートを持つシステムを取り扱えるシステムであること、その上でコンテナベースのシステムを使うことで、デプロイ作業を自動化させることができるからです。

システム構成については記事の中に記載していますが、実際の運用上のデプロイの流れとしては、GHEでのマージをトリガーにCCIが走り、CCIで kubectl apply コマンドを実行することでデプロイが走ります。CIツールのみで実装し、CDツールを使用していないのはこの時点で実際に自分たちがデプロイ時に実施する作業自体には大きな違いがないこと、その上で障害発生時などロールバックしたいときにCDツールによって自動デプロイが動いてしまうことなどが負担になると考えたためです。導入しようと考えたCDツールがfluxcdであり、GHEのコードをpullすることで、実際のアプリケーションと差分がある場合に自動でデプロイをするというものになります。障害発生時にはクラスタに直接入って手作業することが想定され、そのときの作業がfluxcdによって巻き戻ってしまうことが特に重たいと考えました。検索エンジンがJVM系のシステムであり、再起動時には暖気のためにかなりの時間を要してしまうというデメリットを持っているため、障害発生時など緊急に作業において自動でデプロイが動いてしまうというのを許容せず、CIツールのみでのデプロイに完結させることにしました。また、この記事の中にはないシステムですが、その後のAWS化作業で、更新システムもEKSに乗せており、更新システムの停止のために意図的にPod数を0にするという作業も想定されたのも要因の一つになっています。

この記事の中で今後の課題として上げている更新システムやサジェスト機能のAWS化などは現時点で全て完了しており、現在検索サービスはすべてがAWS上で稼働しています。その上で一番ネックであるSolrCloudというクラスタ構成自体の運用の難しさを軽減するために、今は全く新しいシステム構成での検索システム開発を実施しています。何もわからない状況で1から作ったAWSシステムで、運用コストは減ったものの多くの負債が残ってしまっている現状のシステムをまた新しく刷新することでより運用コストを減らせるように取り組んでいます。