こんにちは。インフラチームの高畑です。
今回は Elasticsearch (ES) を AWS に移行した際に導入した Embulk についてお話しします！
Embulkとは
Embulk とは、 Fluentd の開発者である古橋貞之氏によって開発された、 Fluentd のバッチ版のようなものです。 プラグインにより、インプットとアウトプットを柔軟に切り替えることが可能となっており、バルク処理に特化しています。
Fluentd
- データのストリーミング転送
- 既存の大量なデータは転送ができない
Embulk
- 定期実行によるデータ転送
- 分散処理により既存の大量なデータを転送できる
Embulkで利用できるプラグインは以下の通りとなっています。
| Input Plugin | RDS、S3、GA、ES・・・・・ | Output Plugin | RDS、S3、GA、ES・・・・・ | Filter Plugin | カラムを削ったり、再構成したり | File Parser Plugin | File Decoder Plugin | File Formatter Plugin | ファイル関係 | File Encoder Plugin | Executor Plugin | Hadoop上で実行させたり |
導入前
これまで、サービスで利用する ES を自前で構築し、JDBC ドライバを利用して RDS から ES に対しデータを転送していました。 また、ログ基盤として EFK (ES + Fluentd + Kibana) をAWS のマネージドサービスを用いて構築を行なっていました。
サービスで利用する ES を AWS ES に統一しようと考えていたのですが、AWS ES は JDBC を利用したデータ転送が出来ないという問題があり、サービス用の自前 ES とログ基盤用 AWS ES が混在するという無駄な状態となってしまいました。
そこで、これらを解決するため、JDBC での転送をやめ Embulk を利用してデータ転送を行うことにしました。
導入後
Embulk の設定ファイルはとてもシンプルな構造となっており、 RDS からデータを取得して ES へ送るだけであれば以下のように設定するだけで動作します。
（括弧で括っているところは環境に応じて変更する必要があります）
Embulkを活用して 1 日 1 回の同期処理をさせることにより、AWS ES に RDS のデータを流せるため、自前の ES は不要になり ES の混在状態を解消することができました。
またこれにより、自前で ES を管理する必要がなくなり運用コストの低下にもつながりました。
おわりに
Embulkを活用することにより、自前で構築していたESを使う必要がなくなり運用コストの削減に繋げることができました。
同様なことで悩んでいる方がいらっしゃいましたらぜひ活用してみると良いかと思います！
