性能

性能を理解する

etcdは、高い性能を安定して持続的に提供します。性能を決める要素は、レイテンシーとスループットの2つです。レイテンシーは操作の完了にかかる時間で、スループットは一定期間内に完了する操作の総数です。etcdがクライアントのリクエストを並行して受け付ける場合、通常は全体のスループットが増えるにつれて平均レイテンシーも増加します。Google Compute Engine（GCE）の標準的なn-4や同等のAWSマシンタイプといった一般的なクラウド環境では、3メンバーのetcdクラスターは軽い負荷で1ミリ秒未満にリクエストを完了し、高負荷では毎秒30,000を超えるリクエストを完了できます。

etcdは、Raftコンセンサスアルゴリズムを使ってメンバー間でリクエストを複製し、合意に達します。コンセンサスの性能、特にコミットのレイテンシーは、ネットワークIOとディスクIOのレイテンシーという2つの物理的制約を受けます。etcdリクエストの完了に必要な最短時間は、メンバー間のネットワーク往復時間（RTT）と、fdatasyncがデータを永続ストレージにコミットする時間の合計です。データセンター内のRTTでも数百マイクロ秒かかる場合があります。米国内の一般的なRTTは約50msで、大陸間では400msほどかかる場合もあります。回転式ディスクの一般的なfdatasyncレイテンシーは約10msです。SSDでは、通常1ms未満です。etcdはスループットを向上させるため、複数のリクエストをまとめてRaftに渡します。このバッチ処理方針により、高負荷でも高いスループットを実現できます。

etcd全体の性能には、ほかのサブシステムも影響します。シリアライズされた各リクエストは、boltdbを基盤とするetcdのMVCCストレージエンジンを通る必要があり、通常は数十マイクロ秒かかります。etcdは、最近適用したリクエストの増分スナップショットを定期的に作成し、以前のディスク上のスナップショットにマージします。この処理によって、レイテンシーが急増する場合があります。SSDでは通常問題になりませんが、HDDでは観測されるレイテンシーが2倍になることがあります。同様に、実行中のコンパクションもetcdの性能に影響します。ただし、通常のリクエストとリソースを奪い合わないようコンパクションを分散して実行するため、その影響は多くの場合わずかです。RPCシステムのgRPCは、明確に定義された拡張可能なAPIをetcdに提供しますが、特にローカル読み取りでは追加のレイテンシーも生じます。

ベンチマーク

etcdに付属するbenchmark CLIツールで、etcdの性能を測定できます。

基準となる性能値を示すため、次のハードウェア構成の3メンバーのetcdクラスターを考えます。

• Google Cloud Compute Engine
• 8 vCPUs + 16GBメモリ + 50GB SSDのマシン3台
• 16 vCPUs + 30GBメモリ + 50GB SSDのマシン1台（クライアント）
• Ubuntu 17.04
• etcd 3.2.0、go 1.8.3

この構成でのetcdの書き込み性能は、およそ次のとおりです。

コマンド例は次のとおりです。

# write to leader
benchmark --endpoints=${HOST_1} --target-leader --conns=1 --clients=1 \
    put --key-size=8 --sequential-keys --total=10000 --val-size=256
benchmark --endpoints=${HOST_1} --target-leader  --conns=100 --clients=1000 \
    put --key-size=8 --sequential-keys --total=100000 --val-size=256

# write to all members
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \
    put --key-size=8 --sequential-keys --total=100000 --val-size=256

線形化可能読み取りリクエストは、最新のデータを取得するため、クラスターメンバーのクォーラムを通じてコンセンサスを得ます。直列化可能読み取りリクエストは、クォーラムではなく任意の単一etcdメンバーが処理するため、線形化可能読み取りより低コストですが、古いデータを返す可能性があります。etcdの読み取り性能は次のとおりです。

コマンド例は次のとおりです。

# Single connection read requests
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=1 --clients=1 \
    range YOUR_KEY --consistency=l --total=10000
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=1 --clients=1 \
    range YOUR_KEY --consistency=s --total=10000

# Many concurrent read requests
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \
    range YOUR_KEY --consistency=l --total=100000
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \
    range YOUR_KEY --consistency=s --total=100000

新しい環境に初めてetcdクラスターを構築する際は、十分な性能が得られることを確認するため、ベンチマークテストの実行を推奨します。クラスターのレイテンシーとスループットは、環境のわずかな違いにも影響されることがあります。