オンプレで動いていた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/kibana は AWS ES の _plugin/kibana/app/kibana へ、
- それ以外は AWS ES の _plugin/kibana/ へ
という具合です。
こうすることで、オンプレElasticsearchで動かしていたURLのドメイン部分だけ、新たにApplicationLoadbalancer向けに設定したドメインに変更することで、同じダッシュボードが見られるようになり、URL変更されてダッシュボードを探しなおす。みたいな手間からは解放されています。
kibanaではなくElasticsearchそのものにアクセスしたいときは、redirectされたあと、URLを削って色々やる必要がでてしまいますが、直アクセスするようなケースであれば、わかりにくいドメイン名でも1度設定するだけでしょ。ということであきらめてもらってます。