サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<h2 id="はじめに">はじめに</h2>

<p>はじめまして、データ本部検索チームの小山です。</p>

<p>DMMでは検索エンジンのSolrを用いた検索システムを運用しています。検索チームでは主にこの検索エンジンの管理と、検索・更新のデータフローの管理を行っています。</p>

<p>今回、この検索システムのうち検索エンジンと、検索に関わるデータフロー部分をAWS上に移行しました。</p>

<p>そこでここでは以下の項目について紹介したいと思います。</p>

<ul>
	<li>既存のシステム構成</li>
	<li>なぜAWSへの移行を行ったか</li>
	<li>新しいシステムの構成</li>
	<li>今後の課題</li>
</ul>

<h2 id="既存のシステム構成について">既存のシステム構成について</h2>

<p>既存のシステムは全てオンプレ上で動作していました。</p>

<p>下図は検索チームの管理しているシステム群です。</p>

<p style="text-align:center"><img alt="" height="390" src="https://image.dmm-corp.com/xprskoo4le3iuzuqohs4m0vgnx0m" width="800" /></p>

<p>説明に必要な部分のみを抜粋したため、これが全体図ではなく、今回のAWS化に直接関わらない部分は簡略したものを載せています。</p>

<p>ここで特に大きな問題を挙げると以下のものが挙げられます。</p>

<ul>
	<li>検索チームで管理できないサーバがある</li>
	<li>検索エンジンのSolrのバージョンが古く、かつ複数バージョンのSolrの管理をしている</li>
	<li>テスト用の環境がなく、既存環境のスケールもできない</li>
	<li>SolrのデータのバックアップがDBにしか存在しない</li>
	<li>デプロイが全て手動で時間もかかっている</li>
</ul>

<p>以降、内容の補足をしていきます。</p>

<h3 id="検索チームで管理できないサーバ">検索チームで管理できないサーバ</h3>

<p>基本的なサーバはすべてインフラ部の管理化にあり、事業部から新たに検索システムを使用したいという依頼があった場合には検索チームからインフラ部にIP開放依頼を出し、そこで承認が下りればインフラチームに作業してもらい、事業部に連絡するという手順になっています。</p>

<p>この一連の流れには一週間ほどかかり、事業部は検索システムのテストをするだけでも時間を要してしまい、検索チームとしても複数の部署とのやり取りをすることに余計な時間を取られてしまい、開発効率が下がっていました。</p>

<p>サーバの管理をインフラ部のようなプロに任せることは大きなメリットではありますが、一方で部署をまたいで連絡をすることはそれだけで管理コストの増加につながってしまいます。</p>

<p>また、図には記載がありませんが、サーバ管理だけでなくDBからデータ管理用のHiveへのデータフローや辞書管理フローなども別事業部の管理システムに相乗りしています。</p>

<p>これらのシステムは今回の移行対象ではありませんが、いずれも管理コストの増加につながっています。</p>

<h3 id="複数バージョンのSolrの管理">複数バージョンのSolrの管理</h3>

<p>オンプレで管理・運用されているSolrはバージョン4/5/6の3つが動いている状況でした。また、構成も異なり、Solr4/6はSolrCloud構成で動いているのに対し、Solr5はmaster/slave構成で動いている状況でした。</p>

<p>そして、AWSへの移行検討時点ですでにSolrの最新バージョンは8であり、バージョンの大きな乖離がありました。</p>

<p>Solrのバージョンが低いこと自体は運用には大きく影響していませんでしたが、これでは、今後の検索改善などの際に最新の機能を使うこともできず、Solr単体の性能としても低いものを使い続けることになります。</p>

<p>また、Solrで何か問題が起きた時にドキュメントを見つけることが難しく、調査が困難ということもありました。</p>

<h3 id="テスト環境がなくスケールもしない">テスト環境がなく、スケールもしない</h3>

<p>検索エンジンのような大きなシステムはそれだけでも管理コストが大きくかかります。それを普段は使わないテスト環境のために常に用意しておくことは非常に難しく、同じように既存の環境のSolrをスケールアップ/アウトするということも難しいため、性能に大きく関わるような改修はできず、機能レベルのテストを開発環境で行っていました。</p>

<h3 id="SolrのバックアップがDBにしか存在しない">SolrのバックアップがDBにしか存在しない</h3>

<p>既存のシステムではSolrのバックアップを取っておらず、データ更新の際にDBにも一緒にデータを入れることでDBにバックアップデータを入れています。これはSolr4時点でSolrCloudにバックアップの機能が存在しないためです。</p>

<p>もしSolrのデータを失うようなことがあれば、バックアップのDBから大量のデータをFullDIHでSolrに戻す必要があり、この作業には数日というとてつもない時間がかかってしまいます。</p>

<h3 id="手動デプロイ">手動デプロイ</h3>

<p>スキーマやSolrの設定を変更する際にSolrの再起動を行うことがしばしばあります。基本的にはJettyでプロセスレベルでの再起動を行っているのですが、検索チームで管理しているSolrは全部で10台あり、それらを1つずつ前段のLBから外し、再起動してLBにつけ直すということをやっていました。</p>

<p>本番での作業はミスのないように2人以上で行っているため、Solr全台の再起動に1時間以上2人の開発者のリソースを割いて対応していたことになります。</p>

<p>途中からは、作業時間とミスを少しでも減らそうとシェルスクリプトでSolrのステータスを監視しながら順次デプロイをするようなものを作りました。しかし、それでもデプロイにかかるコストが大きすぎて、他作業に注力できないという問題を抱えている状況には変わりありませんでした。</p>

<p>以上のような問題から、チーム全体の開発効率の大きな低下を招いていたため、今後の検索改善を行いやすいよう、チーム管理のシステムをAWS上に構築し直すことになったわけです。</p>

<h2 id="最新のシステム構成について">最新のシステム構成について</h2>

<p>AWSに構築した検索システムは下図のようになっています。</p>

<p style="text-align:center"><img alt="" height="561" src="https://image.dmm-corp.com/scxw652g3bn5nolo49m5o2auscu2" width="800" /></p>

<p>AWS上のシステムは全てTerraformで構築しており、コード管理しています。これによってテスト環境を作りたい時にも簡単に構築でき、現行のシステムの把握もしやすくなっています。</p>

<p>EFSはSolrのバックアップの入れ先として利用しており、緊急時にすぐに復旧できるようにしています。Solr8のAPIを利用し、バックアップ・レストアは数分で完了します。</p>

<p>また、Solrの構築先にはEKSを選択しました。</p>

<ul>
	<li>StatefulSetを採用できるため、ステートを持つ検索エンジンにも適している</li>
	<li>コンテナ管理にすることで、想定外のアプリケーション停止の際などにセルフヒーリングで自動復旧可能</li>
	<li>よりモダンなデプロイ方法の採用</li>
</ul>

<p>などが理由として挙げられます。</p>

<p>今回Solrのバージョンは最新の8系を使用しており、今後はバージョン追従を定期的に行っていく予定です。</p>

<h3 id="StatefulSetとは">StatefulSetとは</h3>

<p>Kubernetesでは、ステートを持つシステムをコンテナ管理するためにStatefulSetというリソースが存在します。PersistentVolumeというストレージをPodにアタッチすることで、データの永続化を行います。EKSではEBSがPersistentVolumeにあたります。</p>

<h3 id="Solrのコンテナ管理">Solrのコンテナ管理</h3>

<p>上記のStatefulSetを使用することでSolrやZookeeperなどのステートを持つシステムもコンテナ管理でき、コンテナ運用の恩恵にあずかることができます。</p>

<p>例えば、先に記載した自動復旧などです。KubernetesではReadinessProbeやLivenessProbeという死活監視の仕組みが存在し、問題のあったPodを前段のServiceから自動的に切り離して再起動してくれます。これによって想定外のアプリケーション停止の際に自動で復旧してくれるため、耐障害性を向上できます。</p>

<p>また、StatefulSetはデプロイ時にローリングアップデートを行ってくれ、LBから切り離して再起動して、LBにつけ直す作業が全て自動化されました。これによって、本番作業におけるオペミスや2人体制でのデプロイ作業による開発効率の低下を防ぐことができます。</p>

<p>一方で、これまでプロセスレベルの再起動をしていた部分がOSレベルでの再起動となり、Solrのwarm upが必要になったため、再起動にかかる時間自体は長くなりました。ここは今後の課題となっています。</p>

<h3 id="新システムのまとめ">新システムのまとめ</h3>

<p>上記の新システムで、既存システムのいくつかの課題が解消されました。</p>

<p>まず、インフラ部に管理を任せていたサーバのうち、Solrと検索APIについては検索チームの管理となったため、事業部とのやり取りが円滑になりました。Solrのバージョンについても、オンプレ側のSolr4と6で運用されていたものをSolr8に統一したことで、最新のバージョンのSolrを1つ管理するだけとなりました。</p>

<p>テスト環境については、全てのリソースをコード管理し、使いたい時に使いたいスペックのシステムを簡単に構築できるようになったため、必要に応じて作成可能となりました。</p>

<p>バックアップからの復旧は、DBからのFullDIHをして数日かけなければいけなかったのが、Solrのバージョンを上げたことにより数分で完了するようになりました。</p>

<p>デプロイについては手動で行っていたものが、Githubにpushするだけ・slackで専用のデプロイコマンドを発行するだけとなっており、運用コストはかなり減りました。一方でデプロイにかかる時間はSolrについてはwarm upの時間もあり、改善には至っておりません。</p>

<h2 id="今後の課題">今後の課題</h2>

<p>ここまでAWS化に伴うシステムの変更とメリットについて主にお伝えしてきました。ここからは、現状の課題と今後の方針について説明します。</p>

<p>上に挙げたとおり、デプロイ方法自体はすごくシンプルになりましたが、Solrの再起動にかかる時間は改善していないため、この時間を短縮する方法は今後も考えていかなければいけません。</p>

<p>また、コンテナ管理化に置いてはいるものの、SolrCloud構成でクラスタを組んでいるためにネットワーク障害に非常に弱くなってしまっています。特定AZでの障害時、EBSを別AZのEC2ノードにアタッチできず、障害復旧が遅れるなどの課題が残っています。</p>

<p>これまで自分たちでサーバの管理を行ったこともなく、AWSやKubernetesの知見もなかったため、運用するだけでも分からないことも多く苦労しているのが現状ですが、1つ1つのシステムを少しずつ理解し、より良い運用を検討していくつもりです。</p>

<p>現在は、更新のデータフロー部分のAWS化を行っており、その後サジェストなど全てのシステムをAWSに移行する予定となっています。</p>

<h2 id="おわりに">おわりに</h2>

<p>今回は検索システムのうち、特に検索のデータフロー部分をAWSに移行した話をさせていただきました。今後も検索チームでは、引き続きAWS化とシステムの運用改善などを行っていく予定です。また、他にもDMMでは検索改善なども行っています。</p>

<p>今回の記事を読んで、技術的に気になった点や話を聞いてみたいことなどがあればぜひ気軽に聞きにきていただければと思います。</p>

<p>&nbsp;</p>

<p><a data-track-component="entry_title" href="https://dmm-corp.com/recruit" target="_blank">採用情報｜DMM Group</a></p>

<p><a href="https://dmm-corp.com/recruit" target="_blank">dmm-corp.com</a></p>


検索システムをEKSに移行した話

シェア

関連する求人

関連する記事