さくらインターネット研究所所長・鷲北賢氏が語る、コンテナのこれまでとこれから

コンテナは次世代サービス開発の主流になるか？

鷲北賢氏：ご紹介いただきましたとおり、さくらインターネット株式会社で先端事業をやっております。さくらインターネットには研究所という部門がございまして、そこで所長をさせていただいております、鷲北と申します。よろしくお願いいたします。

（会場拍手）

ありがとうございます。今日は「コンテナは次世代サービス開発の主流になるか？」というテーマで45分から1時間お時間をいただいております。

今クラウドの時代と言われていますけれども、これからコンテナというものがどういうふうに発展していくのか？　今日はゲーム業界の方が来ていらっしゃるとうかがっているので、ゲームの開発、あるいはその他の開発の際にコンテナというのは主流になっていくのか？　ということをテーマにお話しさせていただきたいと思います。よろしくお願いいたします。

まず自己紹介をさせていただきます。鷲北と申します。

ちょっと変わった名前で、Googleで検索いただくと、いろいろヒットします。最近では六本木に（同じ名前の）お寿司屋さんがあるらしいので、そういうお店がありますね。あと水産業者さんもヒットするらしいんですけれども、人名ですとだいたい私がヒットすると思います。

さくらインターネットでは古参の社員になりまして、20年目になります。さくらインターネットは当初は7人で始まった非常に小さな会社だったんですけれども、現在は東京、大阪、最近震災に見舞われました北海道・石狩にありますデータセンターを構えており、さまざまなサービスを担当させていただいております。

レンタルサーバや、VPS、クラウドといった仮想のサーバサービス。専用サーバという物理のサーバサービス。それからデータセンターそのものでラックや設備を直接お借りいただけるサービス。最近始めましたIoTのモジュールを使っていただける"sakura.io”というサービス。

これが話題のコンテナのサービスで、Arukasというサービス。さらに専用サーバを発展させたGPUを使って非常に高速に……例えばディープラーニングなどといった高火力サーバサービスというものを提供させていただいている、そういう会社でございます。

私はごく初期からデータセンターで主にインフラの面倒を見させていただいたり、あるいはサーバサービスの開発、最近ではクラウドサービスの開発のリードをさせていただいておりました。

2009年に研究所の所長と兼務でやっていたんですけれども、今年度からはクラウドサーバサービスは後任に譲りまして、研究所所長を専任でさせていただいております。

過去にゲーム事業をやっていたことも

もう1つ、今日はゲーム関係ということでご紹介したいこととして、実はさくらインターネットは昔ゲーム事業をやっていたことがあるんですね。オンラインゲームとして、こちらの『DDO（Dungeons & Dragons Online STORMREACH）』と『ロード・オブ・ザ・リングスオンライン』の2つのタイトルを2年ほどやらせていただいていたことがございました。

私はこのプロジェクトの技術リーダーで、実はゲームのことはほとんどわからなかったんですが、ネットワークとサーバとスレージのお守りをやっていました。

さくらインターネットは、オンラインゲームで遊んで集まった仲間で作ったものですから、7人で始めた創業当初からゲーム事業をホスティングするのが夢でして。創業から6年目か7年目にアメリカから買い付けてきたオンラインゲーム事業を始めたんです。

やはりゲーム事業は難しいですね。素人が手を出して大火傷いたしまして、いろいろあって撤退をしました。そういう意味ではゲームの難しさというのはわかっているつもりでして、そういう過去もございます。

テクロス様とはクラウドサービスを使っていただいているというご縁もございまして、今回お呼びいただいたという経緯がございます。

コンテナの普及・啓蒙も

今回はコンテナについてお話しすることになっておりますが、コンテナのArukasというサービスも展開させていただいております。さくらインターネットはコンテナのサービスを展開する以外にもCLOUD NATIVE COMPUTING FOUNDATIONというところで、シルバーメンバーになって、さまざまな情報収集・情報展開をしております。

CLOUD NATIVE COMPUTING FOUNDATIONは、最近ではKubernetesの標準化に対してイニシアチブを取っている団体で、それに関する記事が世間を賑わせたりしているということでも注目を集めているかと思います。今日の後半では、Kubernetesに関する話題も少し取り上げたいと思っております。

さくらインターネットではこちらのシルバーメンバーになっているのと同時に、人的なリソースも出しております。弊社にはエヴァンジェリストの前佛（雅人）という者がいて、最近ではこのような資料がちょっと話題を集めております。はてなブックマークのホットエントリーにランクインしたこともある資料です。

このスライドはSlideShareに公開させていただいておりますので、のちほどURLをご紹介させていただきますが、このようなスライドも用意しておりまして、コンテナに関する技術の普及・啓蒙に努めています。

今日の内容をご紹介します。まずCLOUD NATIVEという考え方について、ここ10年くらいの状況をおさらいさせていただきながら、ちょっと意識合わせをということではないですけれども、今日お話ししたいトピックについてピックアップしたいと思っております。

そのうえで事例を2つご紹介させていただきながら、現在コンテナ技術がどのように使われているのか、あるいはどのように思われているのかということについて、私の個人的な視点が多分に入っているんですけれども、そういった事例を2つご紹介したいと思います。

最後にその事例やこれまでの経緯を踏まえて、サービス開発においてコンテナはどうなっていくのか、コンテナの意味について総括していきたいと思います。よろしくお願いいたします。

クラウドの歴史と影響

では最初に、CLOUD NATIVEとはどういうことなのかを、10年くらい過去を振り返りながらおさらいしてみたいと思います。

言うまでもないお話が続きますが、現代はもうクラウドが主流の時代と思っております。みなさんの中で今クラウドは使っていない、オンプレのサーバしか使っていないという方はいらっしゃらないと思うんですね。

今はもうクラウドなしでサービスは作れないと思っております。さくらインターネットも、さくらのクラウドあるいはVPSというサービスを作る以前は、物理のサーバにこだわってサービス作りをやっていました。

ですが、2011年にクラウドサービスを作って以降、クラウドの売上ばかりがどんどん伸びていきました。物理のサービスは減ることはないんですけれども、ずっと横ばいが続いているという状況です。

以前は物理のサーバサービスは、だいたい売上の3分の2を占めていたんですけれども、今はすっかり逆転しております。物理サーバサービスの割合は、だいたい40パーセントに減っていますが、全体の売上は幸いにして伸びています。

クラウドとVPSのサービスは増える一方でして、今はだいたい30パーセントくらいを占めるに至っております。おそらくこの調子でいけば40パーセント、50パーセントとなっていくのは間違いないと見込んでいるところです。

クラウドの登場がもたらしたもの

現在はクラウドなしではサービスはまったく成り立たないというのが実情だと思っています。クラウドが登場し、みなさんがクラウドを使うようになって状況がどのように変わったかというのをちょっとおさらいしてみます。

仮想サーバが出現したことでインフラの様相が大きく変わってきています。みなさんがクラウドを使ってクラウドの操作や利便性に慣れてきた結果、インフラの使われ方というのが大きく変わってきたんですね。

つまりボタン1つ押せばサーバがパッと生まれて、不要になればサッと消すことができるということで、インフラの利用様式が大きく変わったということなんです。

一例を挙げますと、サーバのライフサイクルがどんどん短くなっているということがあります。例えば10年前、オンプレのサーバが普通に使われていたころ……もちろん今もオンプレのサーバはあると思いますけれども。

やはり物理のサーバを購入すると、それはいわゆる固定資産として扱われます。そうするとだいたい償却というのが発生して、3年、5年、7年などという紐が付いてきてしまうんですね。

3年後、5年後になるとサーバというのはすぐ陳腐化してしまうものなんですけれども、資産なのですぐ捨てるわけにはいかないということで、嫌でも使い続けなければならない。そうしますといろいろ面倒を見て長生きさせないといけないということがありました。

ところがクラウドが登場しますと、先ほど申し上げたとおりボタン1つで生まれて、いらなくなればすぐ捨てるということが可能です。そのライフサイクルが、例えば1年、1ヶ月というように、どんどん短くなってくるわけです。

そして現在、どのようになっているかと言いますと、お客様のサーバの使い方というのは、どんどん短くなっています。今は1ヶ月未満でサーバをリフレッシュしてしまうことがごく当たり前になってきていて、極端な場合ですと1週間、3日、1日でリフレッシュしてしまうということも、わりと普通に行われています。

例えば、週末しか使わないとか。私どものお客様に土曜日に100台借りて日曜日の夜に解約してしまうという、週末だけ使うお客様がいらっしゃるんですね。何に使っているのかが興味深いんですけれども、電話をすると怒られてしまうので、何に使っているのかはぜんぜんわかりません。

最近はサーバレスという考え方も生まれてきています。FaaSと呼ばれていますね。FaaSの登場で最近は秒単位でサーバ課金されるようになってしまいました。30秒とか場合によっては5秒、ジョブ単位でサーバが生まれてジョブをキックしてすぐ終わってしまうという感じで、サーバのライフサイクルが極端に短くなっておりまして。

これで一体我々はどうやって稼いだらいいのかと、ちょっと頭を悩ませるような状況になってきています。

スケールアップではなく、スケールアウトする時代

もう1つ触れておきたいのがスケールアウトというお話です。やはりオンプレの時代にはスケールアップが普通に使われていたと思います。高い負荷に対してサーバの性能を強化することで対応するということが普通に行われていました。

でも、クラウドの時代になって……クラウドの時代ということだからではないんですけれども、最近は性能をアップすることがだんだん難しくなってきていると言えると思うんですね。

いわゆるインテルアーキテクチャのCPUは最近性能がどうしても頭打ちになってきてしまって。例えばCPUのクロックというのはどんなに速いものでも3ギガ、3.5とか……最近CPUのクロックに興味がなくなってしまったので見ていないんですけれども、「3.いくつ」とかだと思うんですね。

どうして4ギガとか5ギガとか極端に速いCPUが出てこないのかと思うんですけれども、もうCPUの性能は限界まで来てしまっているんですね。これ以上速いCPUはなかなか出てこない。今はコアの数を増やすという方向に進化していて、性能のアップの限界はすでに来てしまっているんですね。

そうなりますと、スケールアップではなくてスケールアウトをしないといけないという時代になってきています。スケールアウトというのは多数のサーバに処理を分散するという発想です。これには、例えばロードバランサーを配置しなければならない、アプリケーションを分散用に作り替えなければならないといった別の問題もございます。

ただスケールアップにはもう限界が来ておりますので、時代はスケールアウトになっている。スケールアウトの方法をなんとかして見つけ出さなければならないという状況になっていると思います。

Immutable Infrastructureとは何か？

ここでもう2つキーワードを示したいと思います。1つ目が"Immutable Infrastructure”。これはみなさんも馴染みのある言葉だと思うんですが、ちょっとおさらいさせていただきます。

Immutableという言葉は、直訳すると「不変」という意味ですが、ちょっとわかりづらいので、ここでは「使い捨て」と呼ばせていただきます。Immutableなサーバと言いますと、だいたい使い捨てにするという意味に捉えていただければと思っております。

どういうことかと言いますと、オンプレ時代でしたらサーバは「バッチが当たった」「セキュリティに問題が出てきた」となると、一生懸命修正をして大事に育てていく、修正してアップデートしていくというのが普通だったと思います。

ところがクラウドの時代になってサーバのライフサイクルがどんどん短くなっていきますと、もうアップデートは面倒くさいからやめてしまおうと。古くなったものは捨てて新しく作り直してしまえ、という発想になるんですね。そうすると作り直しになる、使い捨てになる、ということでImmutableと呼ぶようになったわけです。

これが、どんどん極端な方向に進んでいます。例えばPythonのライブラリがちょっと変更になった、アップデートされたというので、すぐその場で使い捨てにしてしまいます。あるいはみなさんがアプリケーションをアップデートしたら、デプロイし直すので、それもImmutableだから捨てて、もう1回新しく作り直します。そういう状況になっていると思います。

どうしてそんなことをやるのかというのを一言で言うと、冪等性はすばらしいという話になるわけですね。どこかで誰かがなにかをデプロイするときに、その結果が常に一定になるということは本当にすばらしいことなんですね。

でも、それを保証するのは非常に困難です。クラウドの時代になって10年くらいになるんですが、これがずっと続いてきた問題だと個人的には思っています。これを解決するのは、結局全部1から作り直してImmutableにしていくのが一番楽だというのが、たぶん今のベストプラクティスなのかなと思います。

アップデート、あるいはファイルの冪等性を保証するために照合する、コピーで上書きするといったことをやるよりは、全部捨てて作り直してしまったほうが手っ取り早いよというのが今の結論です。

結局作り直す……「新規のサーバを0から作り直すスピードをアップしよう」「どんどん短くしていこう」という方向へ進化しているというのがImmutable Infrastructureの方向性なのかなと感じています。

障害時のリカバリが楽である

実は大事な副作用が1個あります。障害時のリカバリがすごく楽ということなんですね。障害を避けては通れません。100パーセント落ちないサーバは残念ながら作れないもので、そうなりますと障害が起こったらとにかく短時間で復旧させようという発想になるんです。

そのときに、短い時間であっという間に元どおりにできるというのが大きなアドバンテージになっているんですね。冪等性も副作用で保証できるので、これはやったらすばらしいよね、という話になるんですね。

ちょっとジョークのページで、これは実は前佛が使っていたスライドが1枚あったので、拝借してきました。

Randy Biasという人がスライドで使っていたものです。Randy Bias自身もどうやらどこかのスライドを引用したようで、「スケールアウトせよ、スケールアップはやるな」というスライドなんですね。

以前はスケールアップと言いますと、「サーバはペットのようなものだ」と。なので病気になったら一生懸命看病してやりました。ところが今はスケールアウトの時代です。サーバは残念ながら家畜並みです。

だから「病気になったら撃ち殺しなさい」と言うんですね。最近豚コレラが発生して豚が全部屠殺されてしまいました、という悲しいニュースがあったので、ちょっとそれを思い出しました。

ただこれはいわゆる事業者、業界においては正しいアプローチだと思います。サーバを大事にしていくのには多大なコストがかかります。それをやるには相応の理由がないと、やるべきではないと思うんですね。

さくらインターネットはレンタル事業者で、ハードウェアを相手に事業をやっているので、やるべき理由があります。

ただ、みなさんのようなクラウドネイティブである事業者さんはやる必要はないと思うんですね。ぜひスケールアウトしてください。サーバを家畜のように扱うべきだと思っています。

Infrastructure as Code

Immutableのほかにもう1つ、キーワードとして挙げさせていただきたいのが"Infrastructure as Code”という言葉です。こちらはインフラをコードで記述しようというお話です。

これはImmutableと密接に関係があると思っていて、こちらはコードを実行するとインフラが構築されます、という発想のことです。

いわゆる"Infrastructure as Code”という発想そのものはそんなに新しいお話ではありません。いわゆるオンプレのころからこういった試みはありました。

例えばChef、Ansible、Terraformといったものが最近ではよく使われる実装かなと思います。Jenkinsとか、最近ですとCI/CDと呼ばれているものですね。いわゆるデプロイと呼ばれているような分野もここに相当するかもしれません。

ただ、いわゆる物理が絡むオンプレの時代には、なかなか難しいお話でした。例えば「サーバを物理的に設置する」「ネットワークを物理的に配線する」といったところは、コードではいくら記述しても実行されないので、人手がかかる。その間はぼんやり待っていないといけないという現実がありました。

ところがクラウドの時代になって、ネットワークそのものもAPIで実行でき、それはプログラム可能だということになりますと、これが配線なしで全部実行できるということになりました。

そうしますと、それはもう実用になったねということです。Chef、Ansible、Terraformというものが実用になったという流れだと思っております。サーバだけではなくて、ネットワークも記述できるようになって、ようやくInfrastructure as Codeというものが実用になったのかなと思います。

残念ながらChefやAnsibleの提供する冪等性にはまだ限界があるのかなと思います。もともとChefやAnsibleの発展の歴史を振り返ってみますと、カバーする領域がどうしても限られてしまっているのかなと。それが理由で、その限界が決まってしまっているのかなと思います。

Chefだけではどうしても手が届かないところ、Ansibleだけでは解決できない問題というのがどうしても絡んできてしまいまして、別のツールを使って補助しないといけないんですね。そのサービス、サーバを使ってフォローしなければいけないというのがありまして。

例えば、ドライバを含むカーネルからアプリケーションを実行する言語パッケージまで、すべて冪等性を維持しながらデプロイすると言っても、どうしても足りないわけですね。

そこまでいくと、CIツールというものがどうしても必要になってきまして。そこをサポートするようなサービスというのがまた栄えたんですね。

ChefやAnsibleの冪等性には限界がある

私が個人的に経験があるのはCircleCIといったツールで、あれもけっこうお値段が高かったりするんですよね。いわゆるクラウドサービスだけが対象だったりすると思いますが、そこにもやはり一定の限界というのがあります。

わりと些細な変更ごとに大きな時間をかけてデプロイしなければいけなかったり、カーネルの変更がだんだん煩わしくなってきます。カーネルも年々大きく複雑になってきていまして。これまたセキュリティパッチが次々とリリースされているんですね。

みなさんMacをお使いですか？　（会場を見回して）Windowsの方もいらっしゃいますね。Windowsアップデートも毎月あって「うざったいなぁ」と思っていると、最近、例えばCentOSのアップデートも2週間に1回くらい来るんですよね。もうなんとかしてくれという感じです。

あれもカーネルが大きくなると、どうしてもそういうことが起こってしまう。それに対抗するために、例えばライトウェイト・カーネルみたいなものが検討されてリリースされたりもしました。

ところが、これがぜんぜん流行りません。一時期すごく注目されたので、流行るかなと思ったのですが、案外流行らなかったです。中途半端なものは流行らないですね。どうしても「フル機能が欲しい」となってしまいます。

"Infrastructure as Code”は非常に有効です。みんながんばってなんとか実装しようとしていますが、どうしても規模の大きい、図体のでかいものになってしまいまして。どうにも使い勝手が悪いとなってしまっているのかなという印象を持っております。

みなさん、いかがでしょうか？　ぜひ後半のミートアップでご意見をいただければと思います。

Dockerの登場

さて、クラウドネイティブの最後を飾るのはDockerの話です。コンテナというのは実はクラウドの流れの中でまったく別のものではなくて、クラウドの流れの一部が延長として登場してきたというのがCLOUD NATIVE COMPUTING FOUNDATIONやクラウドネイティブの考え方のお話としてはあるんですね。

決してクラウド、VMとコンテナというのはぜんぜん別のものではありません。1つの流れの中にあるものです。Dockerは単なる仮想化技術としてコンテナを実装したというものではないです。"yet another Container implementation”ではないんですね。

Dockerが優れているのは、コンテナと周辺の環境を統合的に提供しているという点だと思います。具体的に何のことを言っているのかと言うと、例えばDocker Imageであったり、それをライブラリ化したDocker Hubであったり、そういったものを指していると思ってください。

それが現在のクラウドネイティブの時代の次の5年間であるとか、あるいは先の10年間に来る新世代の開発環境基盤を目指して、まさに開発が進んでいる部分だというふうにクラウドネイティブの考え方が取られています。

ただ、Dockerはまだ発展途上です。なにしろコンテナ界隈は、とくにこの2年の間、非常に荒波に揉まれていました。Dockerそのものも決して安泰ではなかったと思います。一時期は別勢力に押されて、本当に消えてしまうのではないかと心配した時期もありましたし。

あとはいわゆるオーケストレーションツール。今はKubernetesが制覇したわけですけれども、オーケストレーションツールも対抗勢力というのがあって、一時はそっちのほうが覇権を握るのではないかとハラハラした時期もありました。でも、去年ようやく、いわゆるデファクトスタンダードというものが決まりまして、Dockerがその地位を確立したと思うんですね。

ただ、それでも機能的にはまだまだいらない部分のほうが多いと思っています。非常に伸びていますが、変化がとにかく大きいです。Kubernetesの登場でスタンダードの道筋が付きましたが、不確定要素も多いのかなと思っております。

前半のまとめ

というわけで、ここまでの強引なまとめです。DockerがいわゆるImmutable Infrastructureを代表しているものなのかなと個人的には思っております。よくわからないという方は、そう思っていただけるといいかなと思います。

オーケストレーション、Infrastructure as Codeの部分は、ちょっと強引なんですけれども、Kubernetesが担うと思ってください。Kubernetesは決してコード環境ではないんですけれども、Infrastructure as Codeとしてコンテナ、Dockerをオーケストレーションするという意味では、Kubernetesがその役割を担うだろうと思っています。

ただKubernetesとDockerだけで全部済むというわけではなくて、結局今後大きな周辺ツール、周辺環境、いろんなサービスがこのあとどんどんできてくるようになってしまうと思います。

ただ、現在はこの2つがコアになっていまして、この周辺にどんどん新しいツールや便利なものが開発されて、将来のコンテナ開発を形作っていくんだろうなと思っています。ここまでクラウドネイティブのおさらいをさせていただきました。