ニュース
グーグル・クラウドが「コンテナ技術」を振り返る――、なぜコンテナを使うのかなどを解説
2023年6月26日 06:15
グーグル・クラウド・ジャパン合同会社は20日、コンテナ技術についての報道関係者向け勉強会（プレスセミナー）をオンラインで開催した。
内容としては、コンテナ技術とはどのようなものか、どのように使うものかについての基礎を、グーグル・クラウド・ジャパン合同会社 技術部長（インフラ、アプリケーション開発）の安原稔貴氏が解説した。
ここではその中から、現代的なプラットフォームや開発運用プロセス、あるいはGoogleの活動に、コンテナ技術がどのように関連するかについての説明内容をピックアップして紹介する。
Docker以降のコンテナ技術が環境構築を自動化
安原氏はまず、コンテナがなぜ「今」必要とされるかについて、VUCA（Volatility（変動性）, Uncertainty（不確実性）, Complexity（複雑性）, Ambiguity（曖昧性））と言われる変化の多い時代にすばやく対応するためを挙げた。それに加えて、IT人材不足のうえ、開発により多くの人材を回すため、新しいサービスの運用に最初から多くの人員をさけないという状況も挙げた。
コンテナ技術はまるきり新しい技術というわけではないが、2013年に登場した「Docker」が開発者に支持されたことで重要な技術となった。
安原氏はDocker以降のコンテナ技術がアプリケーション実行環境の主流になった点として、軽量な仮想化、コードによるイメージ構築、標準化されたHTTP APIによるイメージ配布の3つを挙げた。いずれも、環境構築の自動化につながるものだ。
そして、コンテナを実運用していくうえで明らかになった課題に対応するために開発されたコンテナオーケストレーターの1つが、2014年に登場した「Kubernetes」だ。Google社内のコンテナオーケストレーターBorgを元に再実装されオープンソースで公開されたもので、現在はCNCF（Cloud Native Computing Foundation）が管理している。
安原氏はKubernetesの特徴の1つとして、YAMLで環境構築することを挙げた。YAMLという箇条書きに似たフォーマットで構成を定義し、たとえばPod（コンテナの動作単位）の数を指定すれば、適切なサーバーにその数のPodを割り振り、Podがダウンしたら指定された数になるようにPodを起動してくれる。これも自動化だ。
それによるメリットして、アプリケーション担当者にとっては自ら必要なインフラの構成を行えること、インフラの管理者にとっては個々のサービスの構成管理をする必要がなくなりプラットフォームレベルでの構成管理に集中できることを、安原氏は語った。
Googleの成長の成功要因はコンテナによる運用の自動化
Googleでは、GmailやYouTubeなどあらゆるサービスがコンテナで実行され、毎週40億以上のコンテナを立ち上げているという。
なぜGoogleがコンテナを使うのかについて、安原氏は3つの理由を挙げた。
1つめは、開発速度を上げて新機能を早くリリースしたいということ。Googleのビジネスはフリーミアムモデルなので、無料の期間に早く改修して品質を上げることにより、有償サービスにつなげるのだという。
2つめは、サーバーリソースを有効活用したい（使い切りたい）ということ。上述のようにフリーミアムモデルで無料で多くを提供するため、コストを絞りたいということだ。
3つめは、開発者は開発に集中したいということ。開発に人材を投入するため、開発人材をあまり多くさけないとのことだった。
ここで出てくるキーワードが、Googleが提唱したSRE（Site Reliablity Engineering）だ。運用業務において、安定的にサービスを提供するために、システムを運用するだけでなく、必要なソフトウェア開発をあわせて行う活動だ。
GoogleではSREチームにおいて、業務時間の50％以上をソフトウェア開発を含む安定化のための活動に使っており、「単なる運用ではない」と安原氏。その活動から作られた仕組みがBorgに集まり、そしてKubernetesにつながったというわけだ。
コンテナ基盤による運用の自動化の効果として、Googleの運用チームの人数を安原氏は紹介した。普通はサービス規模が大きくなると運用チームの人数も増え、それがサービスの成長のボトルネックになる。しかしGoogleでは自動化により、運用チームをそこまで大きくせず、その10倍の勢いでサービスを成長させることに成功したという。
コンテナによりマイクロサービスやCI/CDが実現
そのほか安原氏は、コンテナがもたらす仕組みとして、マイクロサービスやCI/CDについても触れた。
マイクロサービスは、1つのシステムを、単一の目的をもつ機能ごとに独立したアプリケーション（サービス）に分割するアーキテクチャだ。多くの場合、コンテナによるプラットフォームが使われる。
マイクロサービスのメリットとして安原氏は、モノリス（全体が1つのアプリケーションになっている通常の構成）では採用する技術スタックも1つだが、マイクロサービスではそれぞれ別の技術スタックで作れるため、技術選択や人を集めるのが柔軟になると語った。
また、システムをスケールさせるときに、マイクロサービスでは、たとえばECサイトのトランザクション部分だけスケールするといったことができるためコスト効率がよいと語った。
耐障害性の点については、モノリスでは1カ所の障害で全体が止まるが、マイクロサービスでは影響を受けないようにすることもできる（そのように設計すれば）とのことだった。
そのほか、更改にあたりマイクロサービスでは全体ではなくサービス単体で置き換えられるためデプロイが容易性になることを安原氏は挙げた。
CI/CD（継続的インテグレーション／継続的デリバリー）も、コンテナがあってこそだと安原氏は言う。
コンテナを使わずにCI/CDをやろうとすると、CIにおいては、環境が共有されるのでスケジュールの調整が必要となり、テストの頻度が下がる。また、CDにおいては、デプロイが環境によって違うので手動になり、切り戻しにも時間がかかる。
それに対してコンテナを利用すると、テストの環境をコンテナで無数に用意できる。デプロイもイメージ配布で統一され、ロールバックも容易になる、と安原氏は説明した。
