はじめまして。SRE チームの細谷です。
弊社製品 intdash のサーバーサイドでは、intdash Server と呼ばれるミドルウェアが動作しており、intdash の多様なデータパイプラインの構築を実現しています。
intdash Server の構成要素の 1 つに時系列データベースがあり、弊社では InfluxDB OSS を採用しております。
InfluxDB OSS は、v1（1.X）と v2（2.X）のバージョンがリリースされており、現在運用している intdash では v1 を利用しています。
SRE チームでは v2 への移行を検討しており、v1 との比較などを含め検証を進めています。今回は InfluxDB v2 の導入や移行などをご紹介いたします。
導入手順
今回は Amazon Linux 2 の EC2 インスタンス上にインストールします。インストールするバージョンは以下になります。
- influxdb:
2.1.1 - influx-cli:
2.2.1
インストール
influxdb をインストールします。systemd で起動するため、rpm パッケージ経由でインストールします。
wget https://dl.influxdata.com/influxdb/releases/influxdb2-2.1.1-x86_64.rpm sudo yum localinstall influxdb2-2.1.1-x86_64.rpm
起動前に config を設定します。
/etc/influxdb/config.toml1 に記述するか、環境変数を介して渡すことができます。詳細オプションは、公式ドキュメントをご覧ください。
設定が完了したら、influxdb を起動します。
sudo service influxdb start
続いて CLI でのセットアップのため、influx-cli をインストールします。
wget https://dl.influxdata.com/influxdb/releases/influxdb2-client-2.2.1-linux-amd64.tar.gz tar xvzf influxdb2-client-2.2.1-linux-amd64.tar.gz sudo cp influxdb2-client-2.2.1-linux-amd64/influx /usr/bin/
セットアップ
デフォルトの User や Bucket2、Org を作成します。
influx setup -f \ --name default \ # 初期設定の名前 --username influx \ # 初期ユーザー名 --password influxpassword \ # 初期パスワード --token influxtoken \ # InfluxDB へ接続する API Token --org influx \ # 組織名 --bucket intdash \ # 初期バケット --retention 0 \ # Retention Policy --shard-group-duration 168h0m0s # Shard Group Duration
ここで、--token オプションより influxdb に接続するための API Token 値を指定することができます（指定しない場合はランダムな値になります）。
設定を完了すると、以下のコマンドよりデフォルトの config3 が作成されていることが確認できます。
$ influx config ls Active Name URL Org * default http://localhost:8086 aptpod
また、デフォルトの Bucket も作成されていることが確認できます。
$ influx bucket ls ID Name Retention Shard group duration Organization ID Schema Type 14aed3a5dcc5af35 _monitoring 168h0m0s 24h0m0s 06adc337029ceb21 implicit 58a8e876e4cf0bbf _tasks 72h0m0s 24h0m0s 06adc337029ceb21 implicit 61d8afb4a9e0413c influx infinite 168h0m0s 06adc337029ceb21 implicit
_monitoring、_tasks は System Bucket と呼ばれ、1 インスタンス毎にデフォルトで作成されます。
その他、必要な Bucket は以下のコマンドで作成できます。
influx bucket create \ --name influxdb2 \ # バケット名 --org influxdb \ # 組織名 --retention 0 \ # Retention Policy --shard-group-duration 168h0m0s # Shard Group Duration
v1 との互換性について
v2 では、主要言語にクライアントライブラリが提供されていますが、v1 クライアントライブラリとの互換性もあります。InfluxDB 側に v1 auth と v1 dbrp を作成することで、v1 クライアントライブラリを使用できます。
上記は influx-cli コマンドで作成可能です。（事前に必要となる Bucket を作成し、ID を控えておく必要があります。）
v1 auth
InfluxDB にBasic 認証で接続できる認証設定をします。--read-bucket、--write-bucket オプションにて、read/write 可能な Bucket を指定します。
influx v1 auth create \ --username <ユーザー名> \ --password <パスワード> \ --org <組織名> \ --read-bucket <Bucket ID> \ --write-bucket <Bucket ID>
v1 dbrp
Database と Retention Policy を、Bucket にマッピングする設定をします。
influx v1 dbrp create \ --bucket-id <Bucket ID> \ --db <DB 名> \ --rp <Retention Policy>
以上で v1 クライアントライブラリを使用可能な状態になります。
v1 からの移行手順
移行手順は「Automatically upgrade」と「Manually upgrade」の 2 通りがありますが、「Manually upgrade」で移行する手順をご紹介いたします。
こちらは時系列データを line protocol ファイルで書き出してマイグレーションするといった内容になっており、初期セットアップした InfluxDB v2 への移行を想定しています。
事前準備
移行前の準備として、/etc/influxdb/config.toml を作成します。
v1 で設定していた config を元に、v2 の config を作成します。詳しいマッピングは公式ドキュメントをご確認ください4。
時系列データのマイグレーション
InfluxDB v1 サーバー上で、各 DB ごとに以下のコマンドを実行します。
line protocol ファイル形式で時系列データをエクスポートしています。
influx_inspect export \ -datadir /var/lib/influxdb/data \ # datadir を指定 -waldir /var/lib/influxdb/wal \ # waldir を指定 -database influxdb \ # DB 名 -retention autogen \ # Retention Policy -out /var/tmp/influxdb.lp \ # line protocol ファイルを出力するパス -lponly
次に InfluxDB v1 をアンインストールして InfluxDB v2 をインストールします。5
その後、事前準備にて作成した /etc/influxdb/config.toml を配置して、上述した初期セットアップと Bucket 作成、v1 互換性の設定を実施します。
最後に、以下のコマンドから時系列データの書き込みを実行してマイグレーションは完了になります。
influx write \ --bucket influxdb \ # バケット名 --file /var/tmp/influxdb.lp # line protocol ファイルパス
クエリ言語について
v1 では クエリ言語として influxql が使用されていましたが、v2 では flux が使用されます。 （flux 言語自体は、時系列データベースだけでなく RDB や CSV などを扱うことができます。）
influxql も API から使用可能ですが、上述した v1 dbrp 設定をする必要がありサポートされているクエリが限られています。
また、Continuous queries は tasks という名前に置き換わり、flux での作成が必要です。詳細は公式ドキュメントをご覧ください。
Flux 言語によるクエリパフォーマンスの向上
Flux 言語では、Pushdowns という関数がサポートされています。
Pushdown とは 1 つ以上から成る関数であり、その関数はデータ操作をメモリ上で行わずデータソース上で実行します。
こちらを活用することで、CPU やメモリ使用率などの向上が期待できます。
実際に検証中のベンチマークテストにて InfluxQL と Flux の比較を実施しました。
参照するデータ量が大きいクエリを実行したところ、InfluxQL は OOM によって処理が止まってしまいましたが、Flux は正常に動作することが確認できました。
以下がメモリ使用率のグラフになります。
顕著に差が出たのは、Pushdowns によるものと思われます。
長期間のデータ参照が必要なユースケースなどにおいて、Flux が有効な選択肢の 1 つとなることに期待できそうです。
さいごに
InfluxDB のインストールや構成についてご紹介いたしました。
今回は検証向けの手順などがベースの内容となっておりますが、SRE チームでは運用環境に対する移行環境の整備など検証を進めています。
今後も引き続き進展あれば InfluxDB についてご紹介していきたいと思います。
-
json, yaml 形式でも記述可能です。↩
-
v2 では Database が Bucket として置き換わり、各 Bucket に Retention Policy / Shard Group Duration が設定されます。↩
-
ここでは Client 側（
influx-cli）の config を指しています。検証では同一インスタンスに CLI をインストールしましたが、別インスタンスからもセットアップなどができます。↩ -
v1 と v2 の config option は大幅に変更されており、v2 から使用不可のものもあります。↩
-
紹介した手順では、同一インスタンスを v2 に移行する内容を記載しています。運用中でダウンタイムなどを考慮して移行する場合は、Dual write などを活用することをお勧めします。↩
