これまでのDockerとインフラ基盤のあらすじ
コンテナ技術の実装であるDockerと呼ばれる技術が世の中に出てきたのは2013年でした。当時はVMwareしかない仮想化基盤市場でしたが、このDockerによって新しい流れが生まれました。どうもDockerというものを使うと、開発者がアプリケーションの動作環境をパッケージでき、コンテナと呼ばれる実行環境を用意すれば、どこでも同じように動く、というふれこみでした。
私も含めてインフラエンジニアに戦慄が走りました。これまでは開発者に安定するインフラ基盤を提供することでご飯を食べていけていたのです。クラウド化がどんどん進んでいくとしても利用するうえでのインフラの知識は依然として必要であり、むしろクラウド分野で今後活躍できると考えていました。ところが、もしパブリッククラウド上にコンテナサービスが実装されてしまえば話が変わってきます。開発者は直接コンテナサービスに、自分が作ったイメージをデプロイしてしまえば動いてしまうというのです。この筋道であれば、インフラエンジニアは今後不要になってしまいます。
ところがそこから５年間、その通りにはなりませんでした。依然としてVMwareはハイパーバイザーを支配していますし、コンテナで動くサービスも多くはありません。一部の先進的な企業はマイクロサービスアーキテクチャという技術でコンテナでの本番運用を実施できているようですが、まだまだアーリーアダプターという状況でした。
一方で、Kubernetes（クーベネティス）というGoogleがオープンソース化したコンテナ管理ソフトウェアが市場でデファクトスタンダードとして2017年に認知されいよいよコンテナが本番環境でも使われるのかという状況になりました。このコンテナ管理が必要な理由としては、Dockerだけでは複数のホストに展開してスケールアウトし、ロードバランシングするのが非常に難しかったからです。
このKubernetesというソフトウェアを実装したサービスが、パブリッククラウド各社からリリースされ始めた状況です。
・Amazon EKS
・Kubernetes on Azure
・Google Kubernetes Engine
・IBM Cloud Container Service
戦々恐々とはしていますが、まだマイクロサービスなりKubernetesなりに日本国内のエンジニアがまだ追い付いていないのと、サービスがリリースされたばかりで様子見であるのとで2018年現在はまだ仕事としては少ない感じです。
さくらインターネットが独自のコンテナサービスをリリース
今日のニュースです。
「Arukas」では、「Docker Hub」で共有されているコンテナイメージを利用して、簡単にコンテナインスタンスを作成/起動することができます。直感的に操作できるシンプルなコントロールパネルで、複数台のコンテナインスタンスの管理も容易に行えるほか、サービス規模の拡張に合わせてすぐにリソースを増減できるため、個人・法人問わずあらゆる規模のお客さまにご利用いただけます。
なんと、個人ユースでは国内で最も実績のあるさくらインターネットから、コンテナ型のホスティングサービスがリリースされました。よく調べていくと、2016年からずっとベータテストを重ねられていたとのことで多分Kubernetesではないなと思いそのアーキテクチャを調べてみました。
中身についてはこのスライドで説明されていました。
特徴としては、「Apache MESOS + MARATHON + Apache Zookeeper」というものが、現在のKubernetesの役割を行っているということです。このOrchecstaratorと呼ばれるコンテナ管理については、2017年にかなり大きな動きがあり、MesosもKubernetesへ統合していく流れとなっているとのことです。
コンテナをたばねてクラスタ化し、そこへアプリケーションを展開して運用の自動化などを行うツールを一般に「コンテナオーケストレーションツール」と呼びます。
Mesosphere DC/OSは独自のコンテナオーケストレーションツールとして、以前から「Marathon」を搭載していました。これにより、Mesosphere DC/OSではコンテナのクラスタを指定するだけで仮想マシンのプロビジョニングからコンテナのクラスタ運用まで自動的に行えるプラットフォームとなっています。
Marathonは、Docker SwarmやKubernetesとともに主要なオーケストレーションツールのひとつとして知られていました。
そのMarathonの基盤となっていたMesosphere DC/OSがKubernetesをサポートしたことは、主要なオーケストレーションのなかでKubernetesがまたひとつ存在感を高めたと言っていいでしょう。
2018年の今、正式サービスとなったさくらインターネットのArukusがKubernetes化しているとは考えにくいのですが、将来的には標準化されていくものと思われます。
本番リリースするまでには乗り越えなければ行けない高い壁があった
で、上記のスライドはカッコいいスライドなのですが、半年前にコンテナサービスを運用することのトラブルシュートも存在していて、こちらが非常に興味深いものになっています。
こちらの44ページ移行「運用に伴う痛みについて」がポイントです。
・ビットコインを全力で掘られて収容ホストがフラップ
・Zookeeperのログが肥大化してクラスタ不安定化
・Zookeeper再起動後にクラスタ崩壊
・Dockerイメージを大量にダウンロードされてDisk Full
・アップデート作業後には大体動かなくなる
59ページ目に、「コンテナ基盤運用のリスク」とあり、これも重要です。
・突然のタイミングで動かなくなる可能性がある。
・すぐに直せる人材が近くに居るとは限らない。
・規模増大とともに運用負担が肥大化しやすい。
・冪等性（ある操作を1回行っても複数回行っても結果が同じであること）は過信できない。
今リリースされているコンテナサービスは、上記を全て乗り越えてきたというのですからすごいなと思います。一方で、もしコンテナサービスのインフラ基盤を担当することになったら、また新しい知識を得ないとマズいなと思いました。このあたり、Kubernetesが一気に業界のデファクトスタンダードに躍り出てきましたので、勉強するなら今からかな・・と思うところです。
将来的に、完全にパブリッククラウドにコンテナサービスを丸投げ・・となったらいいのかもしれませんが、何か起こった時には、オンプレでコンテナサービスを運用できる知識が必要になると思われます（パブリッククラウドの仮想基盤でも同様でした）。
結論としては、インフラ系システムエンジニアが不要になるかといえば、全くそんなことはなく、コンテナを操る技術担当として必要になりそうです。むしろコンテナサービスの特性やら仕組みやらを今のうちに身に着けて、「マイクロサービスやるぞー」と言われたときのために今からKubernetesでもやっとくか、と思った次第です。
