ハードウェアの推奨事項

開発やテストでは、etcdは通常、限られたリソースでも問題なく動作します。ノートPCや安価なクラウドマシンでetcdを使って開発することも一般的です。ただし、etcdクラスターを本番運用する場合は、適切に管理するうえでハードウェアの指針が役立ちます。ここでの提案は厳格な規則ではなく、堅牢な本番環境を構築する出発点です。どの環境でも、本番運用前に想定ワークロードを再現してテストすることを推奨します。

CPU

大きなCPU処理能力を必要とするetcd環境は多くありません。一般的なクラスターは、2〜4コアあれば円滑に動作します。 数千のクライアントや毎秒数万のリクエストを処理する高負荷のetcd環境では、etcdがメモリからリクエストを処理できるため、CPUがボトルネックになりがちです。このような高負荷環境では、通常8〜16個の専用コアが必要です。

メモリ

etcdのメモリ使用量は比較的小さいものの、性能を発揮するには十分なメモリが必要です。etcdサーバーはキー・バリューデータを積極的にキャッシュし、残りのメモリの大半をウォッチャーの追跡に使います。通常は8GBで十分です。数千のウォッチャーと数百万のキーがある高負荷環境では、状況に応じて16GB〜64GBのメモリを割り当ててください。

ディスク

高速なディスクは、etcd環境の性能と安定性を左右する最も重要な要素です。

低速なディスクはetcdのリクエストのレイテンシーを増加させ、クラスターの安定性を損なう可能性があります。etcdのコンセンサスプロトコルはメタデータをログに永続化することに依存するため、過半数のクラスターメンバーがすべてのリクエストをディスクに書き込まなければなりません。さらにetcdは、このログを切り詰められるよう、自身の状態をディスクに増分でチェックポイント保存します。これらの書き込みに時間がかかりすぎると、ハートビートがタイムアウトして選挙が発生し、クラスターの安定性が損なわれることがあります。ディスクがetcdに十分な速度かどうかは、通常fio などのベンチマークツールで確認できます。例はこちら を参照してください。

etcdはディスクの書き込みレイテンシーの影響を非常に強く受けます。通常、逐次50 IOPS（たとえば7200 RPMのディスク）が必要です。高負荷のクラスターには、逐次500 IOPS（たとえば一般的なローカルSSDや高性能な仮想ブロックデバイス）を推奨します。多くのクラウドプロバイダーは逐次IOPSではなく並行IOPSを公表しており、公表値が逐次IOPSの10倍になる場合がある点に注意してください。実際の逐次IOPSを測定するには、diskbench やfio などのディスクベンチマークツールを推奨します。

etcdに必要なディスク帯域幅はそれほど大きくありませんが、帯域幅が大きいほど、障害が発生したメンバーがクラスターに追いつく際のリカバリー時間を短縮できます。通常、10MB/sあれば100MBのデータを15秒以内にリカバリーできます。大規模なクラスターでは、1GBのデータを15秒以内にリカバリーするため、100MB/s以上を推奨します。

可能であれば、etcdのストレージにはSSDを使用してください。SSDは通常、回転式ディスクより書き込みレイテンシーが低く、その変動も小さいため、etcdの安定性と信頼性が向上します。回転式ディスクを使う場合は、できる限り高速なもの（15,000 RPM）を選んでください。回転式ディスクでもSSDでも、RAID 0はディスク速度を上げる有効な方法です。クラスターメンバーが3つ以上ある場合、etcdの整合性を保ったレプリケーションで高可用性を実現できるため、ミラーリングやパリティーを使うRAIDは不要です。

ネットワーク

複数のメンバーを持つetcd環境では、高速で信頼性の高いネットワークが役立ちます。etcdは一貫性と分断耐性を両立させるため、分断を伴う障害が起こる信頼性の低いネットワークでは、可用性が低下します。レイテンシーが低ければ、etcdメンバー間で素早く通信できます。帯域幅が大きければ、障害が発生したメンバーのリカバリー時間を短縮できます。一般的なetcd環境には1GbEで十分です。大規模なetcdクラスターでは、10GbEネットワークで平均リカバリー時間を短縮できます。

レイテンシーの増加を避け、分断の可能性を減らすため、可能であればetcdメンバーを1つのデータセンター内に配置してください。別のデータセンターに障害ドメインを置く必要がある場合は、既存のデータセンターに近い場所を選んでください。複数のデータセンターにまたがる配置については、チューニング のドキュメントも参照してください。

ハードウェア構成例

以下に、AWSとGCE環境でのハードウェア構成例を示します。繰り返しになりますが、運用担当者は本番運用前に、想定ワークロードを再現してetcd環境をテストすることを推奨します。

これらの構成は、マシンをetcd専用に使うことを前提としています。同じマシンでほかのアプリケーションを動かすと、リソース競合が発生し、クラスターが不安定になる可能性があります。

小規模クラスター

小規模クラスターは、クライアント数100未満、毎秒のリクエスト数200未満で、保存するデータは100MB以下です。

アプリケーションのワークロード例：50ノードのKubernetesクラスター

中規模クラスター

中規模クラスターは、クライアント数500未満、毎秒のリクエスト数1,000未満で、保存するデータは500MB以下です。

アプリケーションのワークロード例：250ノードのKubernetesクラスター

大規模クラスター

大規模クラスターは、クライアント数1,500未満、毎秒のリクエスト数10,000未満で、保存するデータは1GB以下です。

アプリケーションのワークロード例：1,000ノードのKubernetesクラスター

特大規模クラスター

特大規模クラスターは、クライアント数が1,500を超え、毎秒のリクエスト数が10,000を超え、1GBを超えるデータを保存します。

アプリケーションのワークロード例：3,000ノードのKubernetesクラスター