いま一度、再考してみる「コンテナ技術」 - Google Cloudが解説

グーグル・クラウド・ジャパンは6月20日、オンラインでコンテナに関するメディア向けの勉強会を開催した。なお、今回は第1回目となり、7月中に第2回目を予定している。

冒頭、グーグル・クラウド・ジャパン技術部長(インフラ、アプリケーション開発)の安原稔貴氏は、なぜ今コンテナの必要性に迫られているのかについて説明した。同氏によると、VUCA(不確実性)の時代においては変化に対応するために素早さや、さまざまな機能に対する同時並行の開発が求められているという。加えて、日本のIT業界においては人材不足に伴い、新しいシステム・サービスに対して、少ない人員で運用できる体制が必要になっていると指摘する。

グーグル・クラウド・ジャパン技術部長(インフラ、アプリケーション開発)の安原稔貴氏

安原氏は「コンテナはマイクロサービスやDevOps、CI/CD(継続的インテグレーション/継続的デリバリー)の領域にも関連性がある。そもそも、コンテナとはアプリケーションと、その依存性(アプリ実行に必要なライブラリ、ランタイムなど)を1つのユニットとしてパッケージングし、実行する技術であり、Dockerを指すことが多い」と話す。

Dockerを前提としたコンテナの概要

コンテナ技術「Docker」が持つ3つの特徴

そして、同氏は「Dockerを前提とすれば『Build / Ship / Run Anywhere』として1回利用すればどこでも実行でき、廃棄容易性を有し、コードでの定義、高速な起動ができる。コンテナがアプリケーション実行環境の主流となった技術的特徴としては『軽量な仮想化』『コードによるイメージ構築』『標準化されたHTTP APIによるイメージ配布』の3点が挙げられる」と説く。

軽量な仮想化については、コンテナの前にベアメタル、仮想マシン(VM)という技術の変遷があり、両技術の異なる点はハードウェア共有の有無だったが、VMとコンテナの場合はOS共有の有無にある。コンテナはOSが共有されるため起動時間が短く、イメージのサイズが小さいといったメリットがある。

ベアメタル、仮想マシンと比較してコンテナは軽量だという

コードによるイメージ構築に関しては、VMの場合はOSをインストールしてコマンドを叩いてパッケージをインストールし、コンフィグレーションファイルの書き換えなどを経て、実行していた。しかし、コンテナはベースイメージの指定(ランタイムの選択)、依存ライブラリのインストール、必要なコード、バイナリのコピーなどをDockerfileに書き込めば環境の構築が自動化できる。

安原氏は「VM作成や依存関係のインストール、ビルドしたアプリの配置、アプリ自動機能などの設定をDockerfileに記述して、ビルドのコマンドを実行すればコードにしたがって環境が構築できる」と話す。

コード定義の概要

定義されたDockerfileであるコンテナイメージはコンテナレジストリからHTTP APIにより配布されることから、どのような言語・パッケージを利用してもデプロイ方法は同一であり、スケールする際もコンテナレジストリからイメージをダウンロードして実行できる。

HTTP APIによる配布でデプロイ方法は同一になる

このような特徴を持つコンテナだが決して新しい技術ではない。さかのぼれば1979年に発表されたUNIX系のコマンド「chroot」にその源泉がある。

2000年に「FreeBSD jail」、2005年に「OpenVZ」、そして2006年にGoogleが開発した「cgroups」でブレークスルーが起き、現在のコンテナの基礎技術が成長し、メモリ、CPUなどのリソースをプロセスグループ単位で制限できるようになった。その後、2008年に「lxc」、2013年にDocker、2014年に「Kubernetes」と続いている。

同氏は「cgroups以降は、Dockerで大きなブレークスルーが起き、開発者による圧倒的な支持を受けた。開発者が使いやすいコンテナ技術として痒い所に手が届く技術として成長してきた。ファイルの変更履歴をGitライクな変更管理を可能とし、変更が分かりやすくなった」と述べている。

Dockerの概要

コンテナの管理面の課題を解決する「Kubernetes」

ただ、一方で複数のノードに対するコンテナのデプロイ、ノードやコンテナの障害発生時、アプリケーションのアップグレードなど管理面での課題もある。

そこで、管理面の課題を解決するものとして登場したのがコンテナオーケストレーションを行うKubernetesだ。2003年にGoogleが開発し、内部で運用してきたクラスタマネージャ「Borg」をベースとしており、必要なリソースを必要な分だけ利用し、自律回復するインフラとなっている。

KubernetesはBorgをベースとしている

安原氏は「KubernetesはYAMLというファイル形式でコードを記述する。Dockerはコンテナの中のアプリケーションの仕組みやコンフィグレーションなどを設定する。しかし、KubernetesはYAMLで設定するものがコンテナの外側にあり、アプリケーション開発者はリソース数や使用するコンテナ、ロードバランサを指定するだけで動作する。そのため、インフラストラクチャをコードで設定できるようになっている」と強調した。

KubernetesはYAMLで構成するインフラストラクチャとなっている

また、ワークロードのCPUやメモリの消費量などに応じて、自動的にPod(Kubernetes内で作成・管理可能なコンピューティングの最小単位)数を増減させる機能として「Horizontal Pod Autoscaler」を備える。同ツールはCPUやメモリ以外にもカスタム指標、外部指標を用いたオート助0ryもサポートし、複数のメトリクスを利用する場合は各メトリクスで算出されたレプリカのうち、最大値を選択するというものだ。

同氏は「YAMLでインフラストラクチャを構築できると、ロードバランサなどのネットワーク機能や、オートスケール機能といったアプリケーション担当者が必要なインフラを自ら構成することを可能としている。また、インフラ管理者は個々のサービスの構成管理の必要がなくなり、プラットフォームレベルでの構成管理に集中できる。そのため、アプリ開発者がYAMLで定義できる商用レベルのアプリケーション実行環境をKubernetesはもたらしている」との見解を示した。

現在、GmailやYouTbe、検索をはじめ、Googleの全サービスはコンテナで実行しており、週あたり40億以上のコンテナを立ち上げているという。

コンテナで解決できるユースケースとしてはライブラリ、ツール、サーバなどを一緒にイメージ化し、そのほかのアプリやOSのライブラリに影響を与えない。そのため、アプリ開発者がコーディングし、インフラ管理者が管理するという責任分離が可能になることから、意図しない問題が発生しづらくなるとのことだ。

コンテナによりアプリ開発者とインフラ担当者の責任分離が可能になる

さらに、コンテナのポータビリティを活かして、開発・ステージング・本番で同じイメージを利用でき、環境差分が起きにくくなっているほか、ノード自体も複雑な設定の必要がなく、バージョン管理による復元性を有する。

従来の開発環境とコンテナの開発環境の比較

加えて、独立した隔離環境、リソース制限も可能なため、同一システム(ホスト)上で異なる種類のアプリケーションを安全に実行できる。

VMと異なり、同一システムで安全にアプリを実行できる

モノリシックなアプリケーションを負荷分散が可能な適当な大きさのコンテナに分割して、Kubernetesクラスタ上で動かすことで、平均稼働率を従来の2～3倍に高められるとともに、複数システムの集合を稼働させるクラスタ全体のサイジングに注力できるという。

マイクロサービスとCI/CDも実現できるコンテナ

一方、冒頭でも安原氏が触れたように、マイクロサービスやCI/CDなどモダンなアプリケーション開発の基盤としてコンテナを利用することで、効果を最大化することを可能としている。マイクロサービスは機能ごとに独立したアプリケーション(サービス)に分割し、各サービスは単一の目的を持ち、分散システム、サービス間は疎結合、軽量なAPIなどでやり取りを行う。

OSで分割されていない単一のモジュールで構成されたアプリケーション構造を持つ、いわゆるモノリシックアーキテクチャと比較して、マイクロサービスは各サービスごとに異なる技術スタックの適用が可能。また、モノリシックアーキテクチャは全体でしかスケールできないが、マイクロサービスは各サービスごとにスケールすることが可能だ。

マイクロサービスは各サービスごとにスケールすることが可能

耐障害性では、モノリシックアーキテクチャは一部のミスが全体に影響するが、マイクロサービスは他のサービス停止の影響を受けないように設計することができ、影響を限定的にすることができる。そのほか、デプロイはモノリシックアーキテクチャは全体を置き換えなければならないが、マイクロサービスはサービス単体の置き換えを可能としている。

CI/CDに関しては、VMで実施する場合、単体テストやテスト環境へのデプロイ、インテグレーションテストアドは共用の開発環境で実施するため、スケジュールの調整が必要となる。さらに、本番環境へのデプロイはデプロイ方法が環境ごとに異なり、手動でのデプロイのケースが多く、問題が発生した際の切り戻しにも時間を要するといった課題がある。

その点、コンテナを活用すれば、テストのための環境を無数に準備することができるためコードの更新ごとに単体、インテグレーションテストが実施でき、問題の早期発見を可能としている。

本番環境へのデプロイもデプロイの方法がHTTP APIによるイメージ配布に統一されており、自動化が容易なほか、問題発生時もコンテナを前のバージョンに戻すだけでいいという利点がある。