Google Cloud Japan 公式ブログ: [GCP] コンテナクラスターを構成するものとは？

[GCP] コンテナクラスターを構成するものとは？

2015年2月4日水曜日

* この投稿は、米国時間 1 月 22 日、Senior Staff Engineer and Kubernetes Cofounder の Joe Beda によって投稿されたものの抄訳です。
先週は、Miles Ward、Google Cloud Platform ソリューションのグローバルヘッドに、コンテナに関する連載のキックオフとして、コンテナに Docker、それに Kubernetes、これらの全体コンセプトをポストしてもらいました。まだ読んでいなければ、まずはそこから読んでおきましょう。今回のポストに必要な知識を得られますよ！今週は、Joe Beda、シニアスタッフエンジニアで Kubernetes プロジェクトを立ち上げたメンバーの 1 人です。Google のコンテナ運用を支える中心となっているテクニカルコンセプトについて、さらに深く、詳細に話してくれます。それが Kubernetes の開発を告げることになり、また今後の連載の基礎にもなってきます。コンテナクラスターを構成するものは何か？ Docker のようなコンテナシステムが最近盛り上がってきたことは (当然ですが) 興奮しますよね。アプリケーションコードをパッケージ化して転送し、異なるいろいろな環境で動かすことができる、まさにアプリケーションの運用が新しいレベルに至っているという状況です。でも、プロダクションレベルにまででコンテナ利用を広げていこうとすると、どこでどのコンテナを動かすのかや、膨大なコンテナの扱いであったり、ホストをまたいだコンテナ間をうまくコミュニケーションさせる方法であるとか、新たに運用面の問題が持ち上がってきます。そこで Kubernetes の登場です。Kubernetesは、こういった問題を解決できる Google 発のオープンソースツールキットです。先週のポストを思い出してください、私たちは、Kubernetes を “コンテナクラスターマネージャー” である、としています。この分野では、多くの皆さんが “オーケストレーションシステム” と呼んでいますが、それは違うかな、と思っています。オーケストラの音楽は綿密に計画されていて、決められた楽譜があらかじめ演奏家に配られますが、Kubernetes クラスターの制御はむしろ、即興のジャズ演奏。リアルタイムに、今の状況や入っていくるデータに反応するダイナミックなシステムなのですから。そこで、コンテナクラスターの構成するものは何か？という疑問です。複数のコンテナと、コンテナ間のコネクションを配備して統制するダイナミックなシステム？そうですね、それにノード（物理サーバーであっても、仮想マシンであっても）も含めて。このポストの残りは、3 つのことを見ていきます: コンテナクラスターを構成している要素は何かと、それらを動作させる方法、それから相互に接続させた要素を協調させて動かす方法。それに、これまでの Google での経験的から、コンテナクラスターには運用のためのレイヤーが含まれるべきで、それがどういうことなのかも掘り下げていきます。なぜコンテナクラスターが必要なのか？ Googleでの、コンテナクラスター構築の要件となっているのは、常時使用可能であること、パッチ当てやアップデートが可能であること、必要なときにスケールできること、簡単に計測できてモニター可能であることなど、ごく一般的なものです。コンテナは、アプリケーションを簡単に速くデプロイできるようにし、細かいレベルでの制御を可能にしてくれますが、このような目標を達成するには、コンテナ自体を制御するソリューションがまだ足りません。この 10 年の経験から、Google ではコンテナクラスターマネージャーを置くことで、こういった要件を満たせると同時に、多くの利点があることがわかりました:

変動するパーツを制御可能にするマイクロサービス。クラスターマネージャーが、アプリケーションを小さなパーツに分解し、個別に制御、スケールできるようにします。それが、小人数のエンジニアチームの間に明確な境界を持たせることになり、Google の組織的なスケールアップに繋がりました。

障害時に自己修復するシステム。クラスタマネージャーは障害が起きたマシンの受け持っていた処理を、別のマシン上で自動的に再開します。

簡単な水平スケール。コンテナクラスターには水平スケール用に、設定 (レプリケーション数) を変更するくらい簡単に、処理能力を加えていけるツールがあります。

高い利用効率。Google では、コンテナへの移行後から、リソース利用の効率が劇的に改善されています。

クラスターとアプリケーションのオペレーションチームの特殊な役割。開発者はサービスを動かすインフラストラクチャーよりも、サービスの構築にフォーカスできるようになります。たとえば、GMail の開発とオペレーションをしているチームはクラスターオペレーションのチームと直接話すことはほとんどありません。このように関心が別れることで（強制的にではなく）、オペレーションチームをより広い範囲で活用できるようになります。

このいくつかは私たちに固有のことだろうと理解しつつ、さて、すばらしいコンテナクラスターマネージャーに必要な要素と、クラスターの中でコンテナを動かす理由を知るために、皆さんがフォーカスすべきことを見て行きましょう。
要素 1：コンテナのダイナミックな配置クラスターの構築を成功させるには、ジャズの即興のような感じがちょっとだけ必要です。ワークロードをコンテナイメージにパッケージ化したら、それをどこでどう動かしていくのか、その意図を宣言的に指定にしていきます。そして、実際にどこで実行するのかは、クラスター制御システムが判断します。これを私たちは “クラスタースケジューリング” と呼んでいます。これは勝手に配置されるということではありません。それどころか、コンピューターサイエンスの観点から見て、クラスタスケジューリングに興味深くも難しい課題を生じさせるいろいろな制約があります。スケジューリングの際、スケジューラは、VMまたは十分に余裕のある（CPU、RAM、I/O、ストレージなどに）物理マシンにワークロードを配置していきます。しかし、信頼性という観点から見ていくと、連鎖的な障害を避けるために複数のマシンやラックにジョブを分散する必要も出てきます。あるいは、マシンのいくつかには特殊なハードウェア (たとえば、GPU、Local SSDなど) を持たせることもあるでしょう。スケジューラーは、このように変化する状況に対応しながら、障害、クラスタの増大/縮小、処理効率の向上に対処するために、スケジュールし直すことも求められます。そのため、コンテナを特定のマシンに固定しないように推奨しています。”このコンテナはこのマシンに” としなければならないこともありますが、滅多にありません。次の問いは、何をスケジューリングするのか？ということです。簡単な答は、それぞれのコンテナです。でも、同一ホストで複数のコンテナを実行させたいこともありますよね。データサーバーとデータローダーであったり、ログの圧縮/保存プロセスをサーバーとペアにするようなときであるとか。そういったコンテナはいっしょに配置されるべきもので、ダイナミックに配置される中でも分断されないようにしたいわけです。このために、Kubernetes ではポッド (pod) というコンセプトを導入しました。ワーカーコンピューター（Kubernetes ノードとも呼びます）上で複数のコンテナをポッドという単位としてまとめ、いっしょに配置してスケジューリングします。そして、ポッドをグループ化して配置することで、Kubernetes はノード上に多くの処理を、信頼できる方法でまとめることができるのです。

要素 2：セットで考える 1 つの物理ノードで作業をしているなら、ツールでコンテナの一括操作はあまり行いませんが、コンテナクラスターを使い始めたら、ノード間で簡単にスケールアウトできないかと思うでしょう。そのためには、単体ではなくモノのセットという単位で動かす必要があります。そのときそのセットは同じように構成しておきたいです。そこで Kubernetes では、さらに 2 つのコンセプト、ラベルとレプリケーションコントローラーをポッドのセットの処理に使います。 Kubernetes のすべてのポッドには、1 組のキー/バリューペアが設定されています。それをラベルと呼びます。このラベルをクエリーに使い、ポッドのセットを選択します。Kubernetes にはポッドを構成する ”正しい” 方法というものはないので、目的にによってどうポッドを構成するのかは皆さん次第です。例えば、アプリケーションの階層や、地理的な場所、開発環境で構成するのもいいかもしれないですね。実際のところ、ラベルは階層化されたものではないので、同時に複数の方法でポッドを構成することもできます。例：たとえば、フロントエンドとバックエンドからなるシンプルなサービスがあるとします。そのサービスのテスト環境、ステージング環境、プロダクション環境とある中で、プロダクション環境のフロントエンドで使うポッドに env=prod tier=fe、バックエンドには env=prod tier=be というラベルを付け、テスト環境やステージング環境にも同様にラベルを付けるとしてます。そうすると、クラスタを運用したり調査するとき、フロントエンドとバックエンドの両方を見るには env=prod のポッドに絞ればよく、同じようにテスト、ステージング、プロダクションの全体にわたって、すべてのフロントエンドを調べることもできるわけです。さらに多くの階層や環境が増えていったとしても、どう適応したらいいのかは想像できますよね。

図 1 - ラベルを使ポッドをフィルタリングスケールさて、同じように構成されたマシンのプールを特定し維持管理していけるやり方を手にしたところで、今度は、この機能を水平スケール（つまり、スケールアウト）させるために使っていきます。Kubernetes には、それを簡単にするレプリケーションコントローラー（Replication Controller）と呼ぶヘルパーオブジェクトがあります。これは、希望するレプリケーション数、ポッドテンプレート、ラベルのセレクタ / クエリに応じてポッドのプールを維持管理します。これを理解するのはとても簡単です。次の擬似コードを見てください。object replication_controller { property num_replicas property template property label_selector runReplicationController(num_desired_pods, template, label_selector) { loop forever { num_pods = length(query(label_selector)) if num_pods > num_desired_pods { kill_pods(num_pods - num_desired_pods) } else if num_pods < num_desired_pods { create_pods(template, num_desired_pods - num_pods) } } } } たとえば、php のフロントエンド層を 3 つのポッドで動かそうとするなら、それに適したポッドテンプレート（php のコンテナイメージを指している）と、num_replicas を 3 に設定し、レプリケーションコントローラーを作成します。作成したレプリケーションコントローラーは、ラベル env=prod tier=fe を使ってクエリーを行い、どのポッドのセットを処理するのかを特定します。そしてレプリケーションコントローラーは、望まれている状態（num_desired_pods) であるかを見て、その状態になるように作業し続けます。また、スケールイン/アウトしたいなら、レプリケーションカウントを変更するだけでレプリケーションコントローラが残りをやってくれます。システムの望まれている状態、ここにフォーカスすることで、その判断が容易になるわけです。

図 2 – レプリケーションコントローラによる望ましい状態の維持要素 3：クラスター内への接続これまでに取り上げた要素で、たくさんの興味深いことができるようになります。高度な並列処理が可能なレベルに処理を分散できること（継続的インテグレーションシステム、ビデオエンコーディングであるとか) では、個々のポッド間での大量のコミュニケーションがなくても動作します。ですが、最近の優れたアプリケーションはむしろ、お互いにコミュニケーションする小さなサービス (マイクロサービス) のネットワークであることが多いのです。従来のアプリケーションアーキテクチャにおける階層は、実際にはグラフの中のノードです。クラスター管理システムには、これまでに出てきた要素と動作する名前解決システムが必要です。DNS がドメイン名を IP アドレスに名前解決するように、このネーミングサービスは、いくつかの追加要件も込で、サービス名からターゲットへの名前解決を行います。特に、何かが起動したり移動されたりすると、直後にそれが伝わって ”サービス名” は、ターゲットへと解決されます。そのときターゲットに関する追加のメタデータ（たとえば、シャードへのアサイン情報）が含まれることもあります。Kubernetes の API では、ラベルセレクタとウオッチ API パターンの組み合わせで行われ、とても軽量なサービスディスカバリーを提供しています。新しいネーミング API にはこういったアドバンテージがあるものの、それにあわせて書き直されるクライアントプログラムは、すぐには (あるいはずっと) 出てこないでしょう。大抵のプログラムは別の階層とコミュニケーションするために、通信先のアドレスとポートを求めます。このギャップを埋めるするために、Kubernetes ではサービスプロキシの考え方を導入しています。これはシンプルなネットワークロードバランサー/プロキシで、代わりに名前を問い合わせ、ネットワーク上の単一の IP アドレスとポート（DNSを使用して）として見えるようにします。今のところ、このプロキシはラベルセレクタで特定されるすべてのバックエンドに、単純にラウンドロビンで振り分けているだけですが、今後ドメインに応じて的確な決定ができる、カスタムプロキシ/アンバサダーとなることを見越して計画しています（Kubernetes のロードマップにコミュニティが詳細を定義しているので、引き続き注目していてください)。私が個人的にも期待している 1 つの例は、MySQL を使っているときに、write のトラフィックならマスターへ、read のトラフィックならスレーブへと、トラフィックに応じて判断してくれるアンバサダーです。 Voila!（できあがり）これでクラスタ管理システムの主要な 3 つの要素（コンテナのダイナミックな配置、コンテナをセットで考える、クラスター内への接続）がどう組み合わさるのかわかってきたのではないかと思います。冒頭で ”コンテナクラスタは何からできているのか？” と問いました。これまでに説明した内容から、今なら回答できると期待しています。とても単純に言ってしまうと、コンテナクラスタは、システムのあらゆる接続方法や通信方式にあわせて、コンテナの配置と管理をし、ポッドの中にコンテナをグループ化、そしてノード上で動作させるダイミックなシステムです。最初に Google でコンテナを運用してきた経験を形にしていく、という目標で Kubernetes をはじめたとき、最初はただスケジューリングと動的な配置にフォーカスしていました。しかし、リアルなアプリケーションを構築するために絶対に必要なこと、それを様々なシステムから考えて、考えぬいた結果、それが今までに見てきた、ポッド、ラベル、レプリケーションコントローラといった、追加の要素を必要なことが直ぐにわかりました。ですが、私の考えとして、これらも使用できるレベルのコンテナクラスターマネージャーを構築するために最低限必要なものに過ぎません。 Kubernetes はまだオーブンで焼かれているような状態ですが、うまくいっています。最近 v0.8 をリリースし、ここからダウンロード可能です。引き続き機能を追加したり、改良している中、v1.0 へのロードマップも発表しました。プロジェクトは、コントリビュートしてくれるパートナー（Red Hat、VMware、Microsoft、IBM、CoreOSなど）や、Kubernetes を使用している皆さんの参加で、直ぐに大きなコミュニティーとなり、さらに成長しています。私たちは、この分野で多くの経験があるものの、Google がすべての答を持っているわけではありません。Google の中にはない必要条件であったり、検討事項があります。それをふまえて、私たちが構築しているものを確かめて、そしてプロジェクトに参加してください！まずは試して、バグがあればレポート、わからないことは聞いて、あるいはプルリクエスト(PR) を送ってください。 -Posted by Joe Beda, Senior Staff Engineer and Kubernetes Cofounder

Japan 公式ブログ

[GCP] コンテナクラスターを構成するものとは？

0 件のコメント :

コメントを投稿

Labels

Archive

Feed

Useful Links

Company-wide

Products

Japan 公式ブログ

[GCP] コンテナ クラスターを構成するものとは？

0 件のコメント :

コメントを投稿

Labels

Archive

Feed

Useful Links

Company-wide

Products

[GCP] コンテナクラスターを構成するものとは？