私事ですが、気づけば、Mroongaを使い始めてから2年が経っていました。
その間、Groongaそのものについての技術情報は色んな所で語られているものの、Groongaを使ったシステムの構成や運用方法のベストプラクティスについては、ネット上であんまり情報が共有されてないなぁ、と思っていました。

なので、今日は、自社で運用している小規模な全文検索システムの構成を書いてみようと思います。
おそらく、(なんちゃって)冗長構成で運用している中では最小構成だと思うので、サービスを小さく作る際の参考になれば幸いです。

前提

システム構成

ざっくりこんな構成で動いています。

(各インスタンスの台数は適当です)

見ての通り、とてもローテクですが、小規模システムなんてこんなもんですよね？

ポイントは、以下の２点です。

全文検索インスタンスは複数台構成となっており、WEB/APインスタンスからのアクセスはRoute53を使ったDNSラウンドロビンとしています。
- 別に普通のLBでも問題ないのですが、HealthCheck付きであることは運用上とても重要です(後述)。
全文検索インスタンスにはマスターデータは持たせておらず、必要に応じて、マスター(=DBインスタンス)からデータを洗い替えて使っています。
- これは運用当初、Mroongaがたまに謎のハングアップを起こしてデータを破壊したからです(と言っても、ここ1年以上は起きていませんが)。
- また、MySQLのレプリケーションを使っていないのは(以下同文
- 個人的に、 Mroongaをデータ保管用として信用しないのは、使う上でのコツだと思います。

システム構成もローテクなら、データの更新もとてもローテクなやり方をしています。

実は全文検索インスタンスではApacheを立てていて、Route53からはHTTPでHealthCheckをしています。
それを利用して、1台ずつ時間をずらして以下の作業を行っています。

一応、エラーか何かでデータが更新出来なかったインスタンスが複数いる場合は、アラートメールが送られて、それを検知した人が全台がエラーで死ぬ前にcronを止めて耐えるという運用になっていますが、幸い、今のところ発動した事はないです。

さて、ここまでMroongaを使った「なんちゃって冗長構成」のシステムを紹介してきました。
最後に、今後、このシステムが大きくなっていく際の拡張方針について記載しておきます。

全文検索インスタンスをAutoScalingにする。1日1回生まれ変わる運用。
- MroongaのDockerイメージもありますしね。
- 後、死活監視をもうちょっとまともに。
現在はマスタデータをCSVファイルで配布しているが、Mroonga配下の*.grnファイルを置き換えるだけでいいらしいという噂が…
- これが事実であれば、DBインスタンスでgrnファイルを作って配布すれば更新がラクチンに。
  - 現在はLOAD DATAにそれなりに時間がかかっているため、これを短縮して、別のインスタンスと更新タイミングが被る可能性を下げたい。

このシステムもいつかその規模まで育てばいいなぁと願いつつ、この記事を結びます。