この記事はGroonga Advent Calendar 2015の15日目の記事です。
前の記事は、naoaさんのMroonga5.10ではノーマライザーをオプションで指定すると全文検索クエリ以外では利用されないでした。
私事ですが、気づけば、Mroongaを使い始めてから2年が経っていました。
その間、Groongaそのものについての技術情報は色んな所で語られているものの、Groongaを使ったシステムの構成や運用方法のベストプラクティスについては、ネット上であんまり情報が共有されてないなぁ、と思っていました。
なので、今日は、自社で運用している小規模な全文検索システムの構成を書いてみようと思います。
おそらく、(なんちゃって)冗長構成で運用している中では最小構成だと思うので、サービスを小さく作る際の参考になれば幸いです。
前提
- 全文検索を提供するのに用いています。
- 業務システム内の一機能です。
- 夜中に使う人が少ない。
- ユーザー数が少ない。
- マスタ情報の更新頻度が低く、日次で更新しておけばOK。
- データ量はそこそこ(数千万件)。
システム構成
ざっくりこんな構成で動いています。
(各インスタンスの台数は適当です)
見ての通り、とてもローテクですが、小規模システムなんてこんなもんですよね？
ポイントは、以下の２点です。
- 全文検索インスタンスは複数台構成となっており、WEB/APインスタンスからのアクセスはRoute53を使ったDNSラウンドロビンとしています。
- 別に普通のLBでも問題ないのですが、HealthCheck付きであることは運用上とても重要です(後述)。
- 全文検索インスタンスにはマスターデータは持たせておらず、必要に応じて、マスター(=DBインスタンス)からデータを洗い替えて使っています。
- これは運用当初、Mroongaがたまに謎のハングアップを起こしてデータを破壊したからです(と言っても、ここ1年以上は起きていませんが)。
- また、MySQLのレプリケーションを使っていないのは(以下同文
- 個人的に、 Mroongaをデータ保管用として信用しないのは、使う上でのコツだと思います。
データ更新について
システム構成もローテクなら、データの更新もとてもローテクなやり方をしています。
実は全文検索インスタンスではApacheを立てていて、Route53からはHTTPでHealthCheckをしています。
それを利用して、1台ずつ時間をずらして以下の作業を行っています。
- cronで起動される。
- DBインスタンスから事前に生成されたCSVデータを持ってくる。
- 自分のApacheを止める(ラウンドロビンから外れる)。
- 少し待つ。
- SQLのTRUNCATE/LOADコマンドでデータを更新。
- Apacheを立ち上げる(ラウンドロビンに戻ってくる)。
一応、エラーか何かでデータが更新出来なかったインスタンスが複数いる場合は、アラートメールが送られて、それを検知した人が全台がエラーで死ぬ前にcronを止めて耐えるという運用になっていますが、幸い、今のところ発動した事はないです。
拡張について
さて、ここまでMroongaを使った「なんちゃって冗長構成」のシステムを紹介してきました。
最後に、今後、このシステムが大きくなっていく際の拡張方針について記載しておきます。
- 全文検索インスタンスをAutoScalingにする。1日1回生まれ変わる運用。
- MroongaのDockerイメージもありますしね。
- 後、死活監視をもうちょっとまともに。
- 現在はマスタデータをCSVファイルで配布しているが、Mroonga配下の*.grnファイルを置き換えるだけでいいらしいという噂が…
- これが事実であれば、DBインスタンスでgrnファイルを作って配布すれば更新がラクチンに。
- 現在は
LOAD DATAにそれなりに時間がかかっているため、これを短縮して、別のインスタンスと更新タイミングが被る可能性を下げたい。
- 現在は
- これが事実であれば、DBインスタンスでgrnファイルを作って配布すれば更新がラクチンに。
このシステムもいつかその規模まで育てばいいなぁと願いつつ、この記事を結びます。