[和訳]Docker SwarmとKubernetesの比較 #docker

本稿は Docker Swarm Exceeds Kubernetes Performance at Scale (2016/3/9) の和訳です。

コンテナのオーケストレーションについては既に結論が出ていると、コミュニティで話す人が何人かいます。
現実 は真実を越えられません。500人以上を対象に行ったDevOpsとマイクロサービス、パブリッククラウドに関する最近の調査によって、Docker Swarm、Google Kubernetes、そして Amazon EC2 Container Service (ECS)の間でのオーケストレーションに関する競合の存在が明らかになりました。

あなたは今どのコンテナ・オーケストレーションツールとマネージメントツールを使っていますか？
回答数：501、無回答数：0

どのオーケストレーションツールが自分の環境にあっているかを考えるためには、次の三つのキーポイントを検討する必要があると考えています。

・パフォーマンス：コンテナを立ち上げたりスケールで作動させたりするのにかかる時間はどれくらいか？また、高負荷状態でどれくらい反応が良いか？
・使いやすさ：セットアップの学習曲線はどうなっているか？また、日々のメンテナンスにはどれくらいの負荷が掛かるか？可動式のパーツはどのくらいあるか？
・柔軟性：自分の現在の環境やワークフローにあっているか？また、開発段階から商用テストに至るまでアプリは問題なく作動するか？何かのプラットフォームにロックインされていないか？
Docker Swarmはこれら三つの条件のすべてにおいて、一番優れているのです。

スケールでのパフォーマンス
私たちがSwarmの最初のベータ版をちょうど1年前にリリースして以来、私たちは目覚ましい進歩を遂げてきました。ここ１ 年弱で、Swarm 1.0 の発表と(2015年11月）、1,000ノードが動く商用環境のスケールをSwarmがサポートする表明と、それを私たちの内部テストでも証明しました。
以前にKubernetesも100のノードのクラスターでパフォーマンスをテストした結果を詳しく載せたブログを公開しました。しかし、テストの方法論が根本的に異なっており、皆さんは 二つの処理結果を実際に比較できない問題がありました 。
オーケストレーション ツールのパフォーマンスを正確に評価するためには、統一された枠組みが必要です。
このためDocker は 独立した技術コンサルタントのJeff Nickoloffと契約しました。Jeff Nickoloff　はパフォーマンス評価のフレームワーク の作成を支援し、多くの コンテナコミュニティが独自で評価するために利用できるようにしました。
今回 JeffはDocker Swarm と　Google Kubernetes　がスケールするパフォーマンスを比較した独自調査の結果を発表しました。この調査と報告書 はDockerが依頼したものです。両方のプラットフォームで1,000ノードにわたる30,000コンテナを動かすパフォーマンスをテストしました。

テストでは次の二点を調査するよう設計しました。
1．コンテナの起動にかかる時間：新しいコンテナが実際にオンライン状態になるまでかかる時間は、単純に起動する時間と比べてどれくらい速いか。
2．高負荷状態での応答性：高負荷 状態で演算処理にどれくらい速く反応するか（今回はすべてのコンテナを 実行した）。

このテスト用ハーネス（装置） はクラスター構築時の３つの条件を調べます。最も負荷を与えるクラスターは、1,000ノードで30,000コンテナ（一つのノードに30コンテナ）を使用します。ノードがクラスターに加えられるとき、ハーネスは処理を停止して、コンテナの起動時間とシステムの応答性を測定します。中断ポイントはクラスターが10%、 50%、90%、99%、そして 100%になったそれぞれのタイミングです。それぞれの負荷レベルのときに1,000単位のテストを繰り返し実行します。

つまり、例えばクラスターが10％の状態（100ノード、3,000コンテナ）に到達すると、ハーネスは新しいノード追加の中断を意味します。ノード を追加する代わりに、ハーネスは新しいコンテナを起動するのにかかった時間を測定し（この時点のコンテナは3,001番目）、更にすべての作動中のコンテナ（3,001ある）を一覧するのにかかった時間を測定します。この個々の処理を1000回行います。3001番目のコンテナを作り、起動と一覧にかかった時間を測定し、コンテナを削除する。これを1000回行います 。

このテストの結果、Swarmはコンテナの起動が平均で5倍速いと分かりました。 また、商用レベルのクラスターでスケールする場合、必要な環境を準備するのにかかる時間は7倍速いと分かりました。

コンテナ起動時間の測定結果を更に詳しく見てみましょう。クラスターのどの負荷レベルにおいても、Swarmのパフォーマンスが優れているのは明らかです。

Jeffのブログより：
たいていの場合、Swarmはクラスター上で、コンテナの90％以上を0.5秒以内で起動します。一方Kubernetesは、たいていクラスターが50％以上になると、コンテナを2秒以上かけて起動します。

Docker Swarm は５倍速い

大切なのは、今回のテストはコンテナのスケジューリングに関するものではなく、コンテナを実行して処理するためのものです。

コンテナの作動が本当にスケジュールされていたかどうかなどということは重要ではありません。コンテナが実際に作動するのが重要なのです。これをわかりやすく例えると、例えば外食したとき自分の注文が厨房まで伝えられることも大切ですが、本当に重要なのは料理が作られて運ばれてくるまでどれだけ速いかでしょう。

コンテナが約束するものの１つは俊敏性と反応性です。リアルタイムの反応が求められる分散アプリケーションにおいて、起動が5倍遅いのは致命的な問題です。
リアルタイムの反応が必要ない場合でも、インフラの起動に余計な時間がかかるのはイヤなものです。
オーケストレーションを継続的インテグレーションワークフローの一部とする場合、コンテナの起動時間が長くなるとテスト時間もそれだけ長くなります。

クラスターを30,000のコンテナにスケールすることと、能率的にその環境を管理できるかということとは全くの別物です。高負荷下でのシステムの反応性は良いマネジメントにとって欠かせないものです。コンテナがほんの数分しかもたない世界では、リアルタイムの環境を準備するのが遅れれば、それはその瞬間に自分のインフラストラクチャーの 中で何が起きているのか何もわからなくなってしまうということを意味します。

高負荷下でのシステムの反応性を正確に測るために、テストハーネスはすべての作動中のコンテナを一覧するのにかかった時間を様々なクラスターの負荷レベルにおいて測定しました。

測定結果：クラスターの負荷率がほぼ100％であったとき、Kubernetesは全ての作動中のコンテナを一覧するのにかかった時間は2分以上で、これはSwarmがかけた時間の7倍でした。そのうえ、クラスターの形成状態が10％～100％に到達するまでの間は、Kubernetesでは98倍の時間がかかりました。（98％の間違いではなく98倍です）

スケジューリングが始まってからのコンテナリストの反応時間は98倍

使いやすさ
具体的になぜKubernetesはSwarmに比べてそんなに遅く反応も鈍いのでしょうか。これはシステムのアーキテクチャーに関係があります。Jeffのテストからのグラフをちょっと見るとわかりますが、SwarmはKubernetesに比べて連動部分が少ないのです。

これらのパーツはすべてプロセスをセットアップするため複雑で、呼び出し時間にコマンドの実行を行うため修復や調整が難しいのです・・・。下のグラフを見ると、Kubernetesの部品の数がSwarmに比べ多く影響しあっているのがわかります。「run」 や「list」といったコマンドを処理するのに8倍も"飛び跳ねる"ため、余計に呼び出し時間がかかり、その結果重要なオーケストレーション機能が7倍も遅くなるのです。この影響で別の問題もあります。コマンドの処理に失敗したとき、どのポイントで失敗したのかを推定するのが難しいということです。

Kubernetes はGoogle内部のBorgプロジェクトからうまれたものなので、クラウドのスケーリングで使いやすいように設計されていると考えている人が多数います。今回のテストの結果によって、KubernetesはBorgとは全く異なるものであることが証明されました。ただしKubernetesとBorgの共通点が一つだけあります。それは、あまりに複雑すぎて毎日普通に使うだけでもクラウドエンジニアチームが必要だということです。
これに比べてSwarmは複雑なクラウドのテクノロジーを誰にとってもわかりやすいものにするという。Dockerの一番重要な方針に準拠しています。Swarmは初期のころから、全てのサイズのコンテナオーケストレーションをエンジニアチームなしで行うことにかけては一番でいようという目標を掲げていました。

使いやすくさえあれば、クラスターのテストはデータセンターにテストサーバーをセットアップする場合でも、自分のラップトップで行う場合でも、製品のクラウドインフラストラクチャーで行う場合でも同じでしょう。
Jeffが述べているように、「Kubernetesは部品が密集しているのに比べ、Docker Swarmは部品の数からしても使いやすくサポートしやすい」のです。

Kubernetesの作りが複雑なのは、それだけできることが多いのだという人がいるかもしれません。しかし、「できることが多い」ということが必ずしも求められているとは限りません。むしろ実際は、「やることが多い」ために余計なミスのリスクを増やし、サポートのコストを増やし、不必要にインフラストラクチャーへの投資を増やしてしまうので結局はデメリットにしかならないでしょう。

あるいはJeffはこうも言っています
「…Kubernetesは大きなプロジェクトだ。可動式のパーツも多いし、学ぶ面も多い。そして失敗も多い。Kubernetesのアーキテクチャーはよく知られた問題を多少防ぐが、Swarmのアーキテクチャーはより奥深い問題や微妙なニュアンスの差異に対応するのだ。」

柔軟性
この記事の最初で述べた通り、オーケストレーションツール同士を比較するときに見るべきポイントは、パフォーマンスと使いやすさの二つだけです。三つ目の重大な要素は柔軟性で、これは様々な意味があります。

以前の調査結果から、企業が使用中もしくは検討中のオーケストレーション ツールは主にDocker Swarm、 Google Kubernetes、Amazon EC2 Container Service (ECS)の３つだと分かりました。

この３つのうち、全てのインフラストラクチャー（開発段階からテスト段階、プラットフォームでのデプロイの段階に至るまで。そしてラップトップでもプライベートなデータセンターでもクラウドのプロバイダーでも）においてアプリが自由に使えるようになるまでの広範囲を完璧に対応したのはDockerだけでした。そして Docker Swarm は、ホストをクラスター化し、コンテナのオーケストレーションを可能とします。
Dockerの特徴は、パブリックのインフラストラクチャーとプライベートのインフラストラクチャー間でワークロードを持ち運べるようにすること以上に、そのプラグイン式のアーキテクチャーにあります。プラグインのおかげでDockerに対応したアプリケーションはネットやストレージなどの既存のテクノロジーと一緒に使うことができ、アプリケーションのコードを変えずに異なるネットワークやストレージのプロバイダーに移して使うことができるのです。

結局、コンテナのオーケストレーション ツールを比較するのはContainer as a Service (CaaS)、すなわちサービス環境のコンテナ化に必要なパートの一つです。実はオーケストレーションとはプラットフォームではなく、もっと大きなテクノロジーのほんの一部でしかありません。

これは以前に行われた同じ調査でも、ユーザーが求めているのは幅広い種類の開発ツールのサポートだけでなく、アプリケーションのライフサイクルを完全に取り扱い、オペレーションエンジニアにとってのツールと開発者にとってのツールが統合されたツールだという結果が出たことからも明らかです。

Docker SwarmによってDocker CLIやAPIの本来のパワーを十分に使うオーケストレーションが可能になります。これによって開発者はアプリケーションをどこで開発し、どこで実行するかに左右されず、一貫した開発が可能になります。Dockerは投資済みのインフラ環境と一緒に動作します。異なったプロバイダーにも今日からスムーズに移行できます。私たちの設計哲学は「ユーザ」である皆さんとアプリケーションを第一に考えています。

・Jeff Nickooloffの記事を読む
・テストハーネスにアクセスして自分で試してみる
・すべてのテストの結果のデータを参照する
・スケールでのパフォーマンスにおいてDocker SwarmがKubernetesを上回ったというニュースをシェアする

Docker Swarm のリソース
・Docker Swarmをダウンロードしドキュメントを読んでスタートする
・Docker Datacenterを試用する

Dockerに関してさらに学ぶには

・Docker初心者は、10分のオンラインチュートリアルをご覧ください。
・画像、自動構築などを無料のDocker Hubアカウントでシェアしてみましょう。
・Docker 1.10リリースノートを読んでみましょう。
・Docker Weeklyを購読してみましょう。
・次に予定されているDockerオンラインMeetupに登録してみましょう。
・次に予定されているDocker Meetupに参加してみましょう。
・DockerCon 2016に登録してみましょう。
・DockerCon EU 2015のビデオを見てみましょう。
・Dockerコミュニティへの貢献を始めましょう。