オンプレのElasticsearchをAWS ElasticsearchSerivceへ移設した話。

オンプレで動いていたElasticsearchが遅い(HDDだったため)、負荷が高まると取りこぼす。などの事情があり、いっそマネージドなサービスを利用しようとAWS ESへの移設を行うことになりました。

fluentdあたりの話

もともとの構成は、各ノードにfluentdが存在し、aggregatorとなるfluentdを経由したり経由しなかったりして Elasticsearchにデータを送るようになっていました。

そのおかげで、どこからElasticsearchにデータを送っているのか。というのを探すだけで大変な思いをしたため、aggregatorとなるfluentdを経由しないルートをまず、なくすところから始めました。

移行中は、古いデータはオンプレのElasticsearchにしかなく、それをAWS ESに移す積極的な理由もなかったのと、正常動作することを確認する意味もあり、aggregatorから2つのElasticsearchへデータを送るよう設定しました。 一通り、データの整合性が確認でき段階で、オンプレElasticsearchへの送信を止めて、AWS ESを利用するようにする計画で。

ここで問題が一つおきました。AWS ESのほうがデータが多いのです。しかも、ドキュメント数が多いindexであるほどその割合が大きいという状態。

これについては調べた結果、fluentdからAWS ESに送る際に、時間がかかりすぎてリトライ処理をした際、二重にデータが挿入されていることがわかりました。

fluentd側でidを付与していないため、同じデータを何度も送ると毎回別のドキュメントとして認識され、取り込まれてしまうのが原因です。ログ側に一意となるidを付与すれば解決しそうだけれど、さしあたってダブっているだけであれば問題ないということで、足りないドキュメントがないことを確認し、いったん放置することになりました。

次の問題は、aggregatorのfluentdが0.12系で、一部Elasticsearchに直接送っていたfluentdの中に1系のものがあったことです。

これについては 公式ドキュメント に記載がある通り、 1系からaggregatorに送るところに time_as_integer を設定して解決しました。

あとは特に問題もなく、すすみ、kibanaにもcognito認証を追加して会社のIdPからのSAML連携を利用することで、ついでにセキュリティ的にもよくなりました。

AWS ESのドメイン名がひどい

問題が一つあって、AWS ESでは、独自ドメインの証明書が利用できず、とても分かりにくいドメイン名になってしまうというところです。

こちらについては、AWS ELBのApplicationLoadbalancerを利用して解決しました。

といってもApplicationLoadbalancerの後段には、割り当てたSubnet内のIPアドレスにしかforwardできないので、単純に redirectさせる形にしてます。

具体的には

  • /plugin/kibana/* は AWS ES の plugin/kibana/* へ転送
  • /app/kibanaAWS ES の _plugin/kibana/app/kibana へ、
  • それ以外は AWS ES の _plugin/kibana/ へ

という具合です。

こうすることで、オンプレElasticsearchで動かしていたURLのドメイン部分だけ、新たにApplicationLoadbalancer向けに設定したドメインに変更することで、同じダッシュボードが見られるようになり、URL変更されてダッシュボードを探しなおす。みたいな手間からは解放されています。

kibanaではなくElasticsearchそのものにアクセスしたいときは、redirectされたあと、URLを削って色々やる必要がでてしまいますが、直アクセスするようなケースであれば、わかりにくいドメイン名でも1度設定するだけでしょ。ということであきらめてもらってます。