コンテナ技術とスケールするWebサービス ─ ペットから「ポスト家畜」の時代へ

こんにちは。ブックマークチームWebアプリケーションエンジニアのid:yigarashiです。

はてなの技術グループでは「技術のアップデート」を目標に掲げ、チーム横断でさまざまな取り組みを行っています。そのひとつとして、週に1回、若手エンジニアが集まってモダンなWebアプリケーションの要件を整理する会があります。これは技術面の未来を担うという意味でtech-futureと呼ばれ、毎回テーマに沿った調査や議論が活発に行われています。

この記事では「コンテナ」をテーマとして開催された回の議事録を整理し、いわゆる「ペットから家畜へ」という言葉で語られるWebアプリケーションの実行環境の変遷と、コンテナ技術がもたらした2軸のスケーラビリティについてまとめます。そして最後に、コンテナ技術によって「ポスト家畜」とも呼べる新たな時代が到来したことを論じます。

コンテナ以前を振り返る
- サーバーの複雑な状態管理から解放される
- ハードウェアリソースの柔軟な割り当て
コンテナ技術と2軸のスケーラビリティ
コンテナの集合を管理する「ポスト家畜」の時代
まとめ

コンテナ以前を振り返る

ここ20年ほどで、Webアプリケーションの実行環境は著しい変化を遂げました。物理サーバー上でサービスが動いていた時代から、サーバーの仮想化、そして現在進行形で起こっているクラウド化といった変遷です。実行環境の変化に伴って、考え方も大きく変わりました。物理サーバー上で直接サービスを動かしていた時代は、サーバーをどれだけ長く安定して稼働させるかが重要で、一台一台、人の手によって丁寧にメンテナンスするのが普通でした。

しかし、仮想化やクラウド化によって実行環境の作成が容易になるにつれて、うまく動かなければホスト（ないしインスタンス）を作り直すという考え方が生まれました。こうしたサーバーの扱い方の変化を指して「ペットから家畜へ」という言葉がよく使われます。一台一台のサーバーをペットのように可愛がるのではなく、家畜のように簡単に処分したり増やしたりするということです。

サーバーの複雑な状態管理から解放される

こうした変化にはいくつか動機があります。ひとつは、サーバーの複雑な状態管理から解放されることです。各サーバーを手動でメンテナンスしようと思うと、インストールされているミドルウェアやライブラリ、そのバージョンといった複雑な状態を人間が管理する必要があります。すると、サーバーごとにバージョンが違ってバグが発生するといった事故が容易に起こり得ます。サービスが増えるにつれて管理コストもどんどん高まっていきます。

こうした問題を解決するために、Chefのような構成管理ツールが台頭し、冪等性がベストプラクティスとして議論されるようになりました。サーバーがどんな状態であれ、構成を適用して同じ状態になることが保証されていれば、状態管理に関する問題は緩和されるだろうという考え方です。こうしたツールによる構成管理は一定の成果を挙げましたが、それでも、時折だれかが手動でサーバーの状態を変更してしまったり、そもそも冪等なスクリプトを書くのが難しいといった問題が依然としてありました。

こうした流れで登場したのが「Immutable Infrastructure」の考え方です。一度作ったサーバーの状態は不変（immutable）、つまりサーバーの状態は一切管理せず、変更を加える際は作り直そうというものです。これはまさにペットから家畜への変遷と言えるでしょう。

ハードウェアリソースの柔軟な割り当て

もうひとつ主要な動機を挙げるとすれば、ハードウェアリソースの柔軟な割り当てがあります。現代のWebサービスは、時間や口コミ、その他さまざまな要因によって負荷がダイナミックに変化します。そのスピードに、ペットとして扱われた実行環境で対応するのは大変です。アクセスが増えてきたのを確認したのち、インフラエンジニアに依頼してホストを作成、何らかのツールや手順書に従ってライブラリをインストール……などとしているうちにサーバーはエラーを返し、ユーザーはいなくなってしまいます。

そうした状況にスマートに対応するには、より複製しやすく削除しやすい、まさに家畜のように扱える実行環境が必要です。Amazon EC2の登場に代表されるクラウド化はこの先駆けと言えるでしょう。従量課金という新しい計算能力の買い付け方式を土台に、AMIからインスタンスを容易に複製したり、コンソールからクリックひとつでインスタンスを削除したりといった使い方が可能になりました。

これをもって家畜的な運用が主流になったというわけではないでしょうが、要素技術としては可能になり、ペットから家畜への変遷が少しずつ進行していたことが見て取れます。

コンテナ技術と2軸のスケーラビリティ

コンテナ以前の実行環境をふりかえり、技術発展の様子や根底にある考え方を整理した我々は、いよいよコンテナ技術に関する議論へと進みました。これまでの技術との差分を丁寧に議論しまとめていくと、コンテナ技術がもたらす恩恵を2軸のスケラービリティとして整理できそうなことがわかりました。

2軸のスケーラビリティとは、ひとつが計算能力のスケーラビリティ、もうひとつがサービスの複雑さのスケーラビリティです。この節では、この2軸のスケーラビリティについて詳しく見ていくことで、コンテナ技術に関する議論を深めたいと思います。

なお、本記事では「コンテナ技術」と抽象的な書き方をしていますが、コンテナプラットフォームとしてはDockerを、コンテナオーケストレーターとしてはKubernetesとAmazon ECSを、それぞれデファクトスタンダードと仮定して進めます。

計算能力のスケーラビリティ

まずは、計算能力のスケーラビリティです。そもそも、コンテナ以前のクラウド環境でも、インスタンスの自動複製でスケーラビリティを実現することは不可能ではありませんでした。しかし、その複製単位は仮想マシンのインスタンスという重厚なもので、起動の遅さが問題でした。

コンテナ技術はそうした問題を見事に解決しました。コンテナ技術における複製単位はプロセスなので、複製してサービスを提供できるようになるまでの時間が圧倒的に短くなったのです。さらに、コンテナオーケストレーターが各コンテナのリソースを監視し、自動でコンテナ数をコントロールするのが当たり前になっています。

もちろん、実際には物理マシン上でコンテナプロセスが動いているわけなので、何も考えずに無尽蔵にコンテナを複製できるわけではありません。とはいえAWS ECSの例で見れば、EC2バックエンドの場合はオートスケーリングの設定が可能であったり、そもそもバックエンドのリソースを考慮しなくてよいAWS Fargateが提供されていたり、ハードウェアリソースを気にぜずにすむさまざまな技術が生み出されています。

こうした技術発展が積み重なった結果、現代のWebサービスは異次元のスケーラビリティを獲得するに至りました。

余談ですが、コンテナオーケストレーターが実行コンテナの数を自動でメンテナンスすると考えると、オートヒーリングも近い話題として捉えられるでしょう。コンテナ技術の台頭により、単に計算能力をスケールさせるだけでなく、可用性を維持する能力が高まっていると考えられます。

サービスの複雑さのスケーラビリティ

もうひとつは、サービスの複雑さのスケーラビリティです。この点について議論を深めるには、まずは現代のWebサービスをめぐる複雑さについての事情を押さえる必要があるでしょう。「実行環境」という文脈で特に問題になるのは、マイクロサービスアーキテクチャを採用した際の複雑さです。

現代のWebサービスはどんどん巨大化し複雑になり、モノリシックなアーキテクチャでは管理しきれないケースが生まれています。ひとつのサービスの中で、大量のリクエストが来るコンポーネントや、機械学習タスクを行うコンポーネント、数値計算を行うコンポーネントなど、全く異なる特徴を持ったコンポーネントが必要になることも珍しくありません。複数コンポーネントを大人数で一挙に管理するのは大変ですし、実装に適した言語やミドルウェアがコンポーネントごとに異なる場合もあります。

そうした状況の解決策として、サービスを機能ごとに小さく分割するマイクロサービスアーキテクチャが台頭してきました。マイクロサービスアーキテクチャでは、ひとつの大きなサービスを動かすために、マイクロサービスごとに異なる実行環境がいくつもいくつも必要になります。Pythonがインストールされたサーバー、JVMが動くサーバー、例はいくらでも挙げられます。これまでのペット的なサーバー管理では、この複雑さに対応するコストは莫大なものとなるでしょう。

さらに、本番サーバーに実行環境を整えるだけでなく、手元の開発環境でも同様に実行環境を整える必要があります。現代のWebサービス開発では、いくつものサーバー構成を管理し、それをさまざまな環境に展開できる必要が生じているのです。

サービスの複雑さとコンテナ技術

コンテナ技術は、こうした需要に見事に応えます。まず、コンテナイメージのエコシステムによって実行環境の構築が極めて簡単になります。Docker Hubをはじめとしたイメージレジストリから汎用的なイメージを数多く利用することができ、DockerfileとCLIツールを組み合わせてイメージをカスタマイズすることも容易です。また、そうして構築したイメージはあらゆる環境で実行することができます。コンテナという抽象化を挟んだことで、高いポータビリティが実現されたのです。

また、前述のように計算能力のメンテナンスが容易になったことで、それぞれのサービスを管理するコストはどんどん小さくなっています。さらに、Istioといったサービスメッシュを実現するソフトウェアの発達により、サービス間の連携を管理するコストすら小さくなり始めています。

こうしたコンテナ関連技術の発展によって、我々はマイクロサービスアーキテクチャを上手く扱う手段を獲得し、サービスの複雑さをスケールさせることが可能になったと言えるでしょう。

また、コンテナ技術の発展が、ペットから家畜への変遷と地続きになっていることを忘れてはいけません。Dockerfileというコードによる構成管理と、可搬性が高くて取り回しのよいコンテナという実行単位は、まさにImmutable Infrastructureそのものです。適切にコンテナを運用すれば、我々がサーバーの状態に悩まされることはまずないでしょう。

加えて、コンテナの複製や削除が容易であることから、いわゆる家畜的な扱いがさらに進行し、計算能力の柔軟なコントロールが簡単になっています。

コンテナの集合を管理する「ポスト家畜」の時代

このように「ペットから家畜へ」という文脈に沿ってコンテナ技術について議論した我々は、コンテナ技術が既に「家畜」という扱いすら通り過ぎているのではないか、という考えに至りました。

我々が「家畜」として想定するのは、たかだか各サーバーが複製しやすく捨てやすい状態になっていて、それを人間が管理する程度のことです。しかし、コンテナオーケストレーションが発達した今、もはや我々がひとつひとつのコンテナに手を下すことはありません。コンテナの集合としてのサービスと、それぞれのサービスの相互作用さえ定義しておけば、あとはその状態が維持されるように勝手にコンテナが操作されます。

あるコンテナがハードウェアリソースをどれくらい使っているか、そのIDが何であるかといったことはそれほど重要ではなく、コンテナの集合の振る舞いが重要になります。Amazon ECSのCloudWatchメトリクスを見ても、タスクの集合に関するメトリクスが充実しており、そうしたメンタルモデルが構築されていることが見て取れます。

もはや我々は、各サーバー個体に対するオペレーションからは解放され、コンテナの集合さえ管理すれば良くなったのです。

こうした状態をもって「ポスト家畜」の時代がやってきていると我々は考えました。この言葉自体は特に出典もなく、単なる言葉遊びといえばそこまでですが、コンテナ技術によってパラダイムが変化したことを端的に表すもので、理解を深めるための道具として非常に有用であったと思います。