mastodonの事例
鷲北賢氏：続きまして、事例に移っていきたいと思います。今日持ってきた事例は、"mastodon”です。
今日、どうして突然mastodonの話を持ってきたのかというのを、ちょっとわかるように説明したいと思います。まずmastodonを知っていますという方はいらっしゃいますか？
（会場挙手）
ありがとうございます。mastodonというのは、もうみなさんご存知ですが、Twitterライクなコミュニケーションツールですね。
その前にdocker-composeの説明をいたします。
最近、実はmastodonもそうなんですけれども、アプリケーションパッケージを配布するのにdocker-composeを付けて配っているという方が多いんですね。ご存知ですよね。
レガシーなインストーラですと、だいたいconfigureしたあとmake allしてmake installするというのが10年前、僕みたいなオールドタイプには普通だったんです。
でも、最近docker-composeが入っていてDockerでボンッと起動すると、全部がゾロゾロゾロッと動きだして。パッと……例えばmastodonが動き出して、あとはWebでアクセスするだけという。それはそれで便利です。
mastodonもご多分に漏れずその通りの動きをしております。mastodonが去年の4月に突然ブームになりまして。当時大学生のぬるかるさん、ピクシブとドワンゴさん、ニコニコ動画のような、個人のサイトと企業サイトに突然大規模なユーザー集約が起こりまして、すごく話題になりました。最近ブームもちょっと落ち着いたんですけれども。
イベントが多数開催され、さくらインターネットがどういうところに関わっているかと言いますと、この個人の方にサーバ支援をさせていただきまして、それ以来ちょっとお付き合いがございます。今こんな状況です。
mstdn.jpは個人でやっていらっしゃっていて、先月末に調べたら17万8,000人オーバーですね。たぶんまたちょっと増えていると思います。けっこうなユーザーが付いているんですね。
ピクシブはやっぱりすごいです。今40万人を超えていると。friends nico（ニコニコ動画）は、6万4,000人ちょっとという感じになっています。ゲーム事業者さんだと多いか少ないかというのは議論の的かもしれません。
mastodonのシステム構成
実は3サイトともインストールの時点でコンテナから剥がしてしまっているんですね。docker-composeをパッと見て何が入っているかを調べたら、systemdに全部書き換えて、インストールし直しているんです。だからDockerを使っていないんですね。
いわゆるレガシーなサーバ構成と分散技術でスケールアウトしてしまっているというのが実情です。これは公開情報なので、ぜひピクシブのスライドで説明したいと思います。
mastodonのシステム構成。これは、ピクシブのハッカソンのスライドをそのままお借りしてきています。
モダンなRuby on Railsアプリケーションとなっていまして、Webサーバがあって、Railsのコアがあって、Postgreサーバがあって。
node.js、Redis、Sidekiq。このあたりがメッセージのキューになっていると思ってください。クライアントがトゥートをバンバン投げると、ここにすごく負荷がかかって、メッセージがガーッとキューニングされます。
ピクシブさんにこのあたりのことを聞いたら、喜んでお話ししてくれると思います。こんな感じの構成です。
docker-composeではこれらの周辺サーバをポコポコッと立ち上げて、パパパッとつないで、ポーンと立ち上げてくれるというのを実装してあるだけです。
なぜピクシブはDockerから剥がしたのか
でも、ピクシブさんはAWSを選んでいて、これは模式図です。その（AWSの）上に、パパッと……これはたぶんA系、B系かな……2つに分けて実装されたということです。非常に典型的なWebサービスの構成だと思います。
なんでDockerから剥がしたか？ ということをきちんとコメントしていただいたので、これを引用させていただきます。
全部systemdサービスに置き換えましたと。これはもう去年の話ですが、「そのまま使うのは難しい」とコメントされています。
デプロイのことなどを考えると、ちょっと余裕がなかったと。なにしろデプロイして初日で何万人というお客様を受け入れられたそうで、とにかく短時間で信頼できるサーバ環境を作らないといけないというプレッシャーがあったとお聞きしておりまして。短時間でDockerのことを全部1から勉強してその環境を作るには、不安があったというのが本音だと思います。
Dockerですぐやるならホットデプロイやリソース配分の仕組みをあらかじめ用意しておかないといけません。「そのうちやりたい」とコメントされておりますが、たぶん今もそのままの構成になっていると思います。
最近アップデートいただいていないのでわかりませんが、たぶん今も同じだと思います。ということで、残念ながらピクシブさんもおそらくドワンゴさんもDockerでは運用されていないんですね。
コンテナ運用に不安を抱くエンジニアは少なくない
実はこういうケースが多いんじゃないかなと想像しています。最近は配布のときにdocker-composeを付けているパッケージが非常に多いと思うんですけれども、運用のときに剥がしてしまうんですね。受け取っているエンジニアのほうでは「Dockerで本当に運用できるかしら？」と不安に思うケースが非常に多いと思います。
なぜかと言うと、やっぱりスケールアウトさせるにはどうすればいいかという経験の問題なのかなと思っています。私自身も、実は受け取ったらどうしたらいいのかなと不安に思うところがあるんですね。
例えばどの程度サーバを用意すれば、これくらいのロードをさばけるのかという見積もりがぜんぜん立たないんですね。そうなりますと、例えばトラブル時にどういう対応をしたらいいのかということもわかりませんし、結果としてやむを得ずレガシーな構成で、自分が信頼のおけるやり方で処理しなければならないということにどうしてもなってしまうわけですね。
やっぱり不安を上回るメリットがないと、導入は難しいという話になってしまうと思うんですね。不安を上回るメリットは何だろう？ という話になると思います。
大きなメリットがあれば、例えば「インフラに問題がある」「インフラに不安がある」というような問題も、メリットのためにがんばって克服しようという気になると思うんですけれども。どういうメリットがあればそれを克服できるかという話になると思うんですね。
それは事例2でご紹介できるかと思いますが、残念ながら事例1は、採用できませんでしたという話です。大規模Mastodonインスタンスは結局Dockerに戻るでしょうか？ ということだと、たぶん戻れないと思います。1度運用が始まってしまったサービスは、やはりなかなか変更できないだろうというのが残念ながら事実だと思います。
個人でやられているmstdn.jpは、今でもふだんからどういう体制でやられているかをお話しさせていただいていますが、Dockerにする気はまったくないとおっしゃっていました。運用主体がそれを望んでいるように見えない。やはり運用が優先だからではないかなと思います。
Netflixの事例
では続いて、こちらは成功事例ということになると思います。Netflixの例をここで挙げたいと思います。
大規模コンテナを活用している事例としてググると1番目がやっぱりこれなんですね。わかりやすいということで、今日はNetflixを取り上げました。
Netflixさんの公開資料があります。読めないくらい小さな字なので、あとで公開資料を参照していただけたらと思います。Netflixさんは非常に良い使い方を公開されているので、興味のある方はぜひご覧いただければと思います。基本的にはスライドの要約になっています。
Netflixは、たくさんの映画やビデオをお客さんに配信しているサイトです。最近は独自ドラマや独自映画も制作して、Netflixオリジナルとしてどんどん配信されていることでも有名だと思います。映画賞を取ったものもありますよね。
基本的にはコンテンツはムービーファイルで、それをお客さんにビューっとストリーム配信するのがメインのサービスです。これも有名なところで、NetflixはAWSでサービスを構築されています。基本的にはEC2、VMで構成されています。
実はNetflixのスライドを読むと、VMでも十分満足していたと書かれています。VMでも、例えば可用性が非常に高く、マイクロサービス化していて、クラウドネイティブであり、CI/CD DevOpsもきちんと運用できていて、スケーラブルだったと。とくに不満はないと書いてあるんですね。
Netflixはもう1つ、Chaos Monkeyというものでも非常に有名です。これもみなさんはご存知ですね。わざと障害を起こしてどうなるかを見るという実験をどんどんやっています。これはちょっと羨ましい話です。
Netflixがコンテナを導入した理由
それでもNetflixはコンテナを導入したいと書いているんですね。その理由として、絶え間ない開発と継続的なリリースを実装するためには、コンテナが最適だというわけです。
例えばエンコード研究では、VMよりもコンテナのほうが有利だというような研究結果があるそうです。このあたりはあまりにも専門的すぎて意味がよくわからなかったので、直訳してしまいました（笑）。
Netflixさんがこれを導入されたのは2015年くらいの時期だったそうで、いわゆるコアになるコンテナ技術にはDockerを使っているんですが、オーケストレーションツールは自作なんですね。
その理由が、Titusというシステムを作られたからだそうで。当然巷にあるツールを入れようとしたそうなんですが、それはNetflixの要求にマッチしないということで採用されませんでした。
これはすごく共感するんですが、例えばスケーリングのレベルが十分でなかったと言うんですね。Netflixのスケーリングはものすごいレベルで。例えば同時接続数なんて何百万というので、うちでは想像もできないような話です。
さくらのクラウドも基盤は自作なんです。例えばOpenStackを使ってクラウドを作らなかった理由は、OpenStackはやっぱりスケールしないんですね。VMを1万台、10万台作ろうと思ったら、OpenStackではダメだったので、オーケストレーションツールを自作したわけです。
Netflixが必要とするクラウドプラットフォームに、Dockerあるいはコンテナ環境をスケールさせる必要があったのでTitusを自作しました、と書いてありました。これ、かっこいいなと思いました。
Titusの実体
Titusの実体。どういうワークロードのコンテナになっているかという説明です。先ほど申し上げたとおり、基本的にはビデオストリームをどんどん配信する、ビデオストリームを準備する、というのがワークロードの実体です。
基本的にはビデオのソースがあって、それをチャンクに切り分けたあとにエンコードしてインポートして、それをテストしてというようなことをやっているそうです。これをVMではなくコンテナですると性能が上がるよ、というのがNetflixさんの言い分です。
それからもう1つが「Watermarking」。透かしを入れるというものですね。透かしを入れながらビデオをどんどんコピーしたり、PDFをどんどんコピーしたり、といったワークロードが大量にあると。
それをなぜかNetflixさんはバッチだと言うんですね。Titusは基本的にはAWSのEC2、VMの上に自分で作ったDockerコンテナの基盤。Dockerコンテナもとにかくどんどん作ると書かれています。
Container Executionと呼ばれている、いわゆる物理層に近いものですね。AWSのインフラ層にリソースマネージャーと配置を最適化する最適化層を受けまして、ジョブマネージャー層、ここがTitusのコントロール部分で、基本的にはバッチとサービス、2つしかマネージャーがいないんです。
バッチがすべてだとスライドには書いてあります。やたらバッチが出てきて、1970年代のタイムシェアリングの論文を読んでいるような気分になってきます。なんでそんなにバッチと言うんだろうと思っていたら、こんなスライドが出てきたんですね。
「サービスとは長時間動いているバッチに過ぎない」と。もう意味がよくわからない。笑いを取っているつもりらしいので、僕は大笑いさせていただきました（笑）。もちろん実際はもう少し複雑です。
サービスは常に変化しているもので、永遠に動き続ける必要があります。例えばオートスケーリングというのが不可欠です。
「オートスケーリング」の罠
オートスケーリングというのもマジックワードです。よくお客様から「オートスケールが必要だ」と言われるんですけれども、実際にはワークロードがあらかじめ予測できているときにしかオートスケールはうまく動かないというトリックがあります。ですので、それを実装しないといけないという難題があります。
それから基盤となるホストをアップグレードするのは難しいと書いてあります。これはどういう意味かと言うと、先ほどコンテナはImmutableだからどんどん捨てられるという面白い話をしました。
ところがコンテナを乗っけるホストがImmutableではないんですね。というのは、一旦コンテナを乗っけてしまうと、なにかのワークロードを持っているコンテナをうっかり捨てられないという状況になってしまうんですね。
そこにはお客様がムービーを見ているかもしれない。そういう大事なバッチが動いているかもしれませんし、なにか大事な実験あるいは大事なワークロードを抱えているコンテナがいるかもしれない。
そうなると、一旦作ってしまったベースのホストはうっかり捨てられないという状況が生まれてしまうんですね。そして、アップグレードするのが難しいというロックがかかってしまう。これはやっぱり単純な問題ではないと主張しています。
サービスは状態を持っている
もう1つ、サービスはステート（状態）を持っています。トラフィックに対処することと、単に起動・停止することは対立関係にあると主張しています。これもちょっと読み解くのが難しくて。
たぶんこうじゃないかなという解釈なんですが、例えばサーバをオートスケールであるとか、なにかのワークロードに対応するために起動しておくということは、単純にオンするという意味ではないという主張だと思うんですね。
ただサーバをオンにするだけでは足りなくて、あたためておくということが必要なんですね。あたためておくと言うとたぶん理解していただけると思います。例えばトラフィックを擬似的にでもかけておいて、キャッシュにデータを溜めておかないといけないんですね。そういうことだと思います。
それがステートを持っているという意味なんですね。ただ起動しているサーバをポンと投げ込んだだけでは役に立たないんです。5分、10分待ってトラフィックを十分吸い込んだあとでないと、実際には役に立たないということがあり得ます。
総合すると、これまたアップグレードが難しいという話になってしまうんです。せっかくあたたまったサーバを何かの都合でまたポンと落とすんですね。一気に性能がダウンしてしまうということが起こり得るという議論。
そういうことがあって、例えば既存の開発体制やリリース体制、ランタイムや運用ツールうんぬん……すごく大きなスライドで、とにかく大変でしたということが書いてありました。
運用のためではなく、開発のためにコンテナを導入した
このNetflixの事例も大変注目を集めまして、とくに大きな注目を集めたのは1週間あたりで300万個のコンテナをバーンと立ち上げた経験があります、と公表されたことです。やはりスケールの大きさが、一番驚きが大きかったのかなと思います。
Netflixさんは、運用のためではなく開発のために、すごく大きな困難を乗り越えてこれを導入したというのが一番大きな動機だったんじゃないのかなと思います。大きな動機があったからこそ、未知なるコンテナ開発に取り組んだのかなと思いますね。クラウドネイティブにおいては、コンテナ導入は自然な流れになるんじゃないかなと。その最もいい事例ではないかなと思います。
ただ、実はTitusを自作されたということになっておりまして。基本的にこれはNetflixのワークロードに合っていると言うか、たぶんNetflix以外のワークロードにはぜんぜん役に立たないのではないかと想像しています。なにしろバッチだって主張されていますから。
巨大なサービスにおいて顧客を満足させ続けるためには、どんどん開発する。どんどん捨てていく。デプロイは1日30回だ！ というような考え方は不可避だと言えるかもしれません。
サービス開発におけるコンテナの意味
最後、サービス開発におけるコンテナの意味ということでいきたいと思います。現代のサービス開発における課題。このあたりは実はおさらい感覚になっておりまして。スケーラビリティ、高い可用性・信頼性、容易な保守・運用。ごく当たり前の話を挙げています。
ずばり言うと「コンテナはこれらを解決するか？」ということだと思います。コンテナがこれを解決するというわけではないと思ってください。例えばスケールに関して言うと、スケールアウトはクラウドネイティブの時代には必須のテクニックです。スケールアウトできないサービスは、残念ながら生き残れないということになっております。
なぜならスケールアップにはもう限界がきてしまっているので、これ以上スケールアップはできないという状況です。スケールアウトできないなら、それ以上大きなサービスは作れませんという状況に、残念ながらなってしまっています。
ただスケールアウトも簡単ではありません。「コンテナだから簡単だ」というのも、これは残念ながら正しくないですね。「コンテナだから簡単だ」というわけではありません。
それからもう1つ、これがまた困った話で、スケールアウトできない要素も実はたくさんあります。例えばデータベースのような恒常性が必要なもの。いわゆるコンテナには向いていないような要素が実はたくさんあるんですね。
ロードバランサなどもそうです。これはどうしてもスケールアップするか、あるいはサービスに頼るしかないという要素があります。データベースに関してはいろんなテクニックがありまして、今日扱うのは荷が重いので省略させていただきます。
サービスに頼ると、今度はロックインされてしまって、ちょっと困るんですね。これはこのあとも別の議論をさせていただきます。
信頼性を担保するために
信頼性もそうです。絶対に落ちない1台のサーバというのは残念ながら幻想ですね。これはもうやめて、例えば100台あるうちの30台落ちても平気だという冗長性の高いシステムを作る。これがクラウドネイティブの考え方です。そうするとスケールアウトが、先ほどのスケーラビリティの向上と同時に、可用性・信頼性の向上につながる。お互いに補完関係にあるので、これはぴったりです。
それから、コンテナはより適したソリューションになり得る。コンテナはとにかく起動が速いんですね。VMの起動もわりと速かったです。さくらのクラウドで2分と言っているように、コンテナは2秒とかで起動できるんですね……ロードが終わればという話ですが。ロードを勘案すると15秒くらいですかね。ネットワークの性能やキャッシュの具合にもよりますが、速くしようと思えば2秒くらいで立ち上がります。
Immutableかつコード化されたインフラストラクチャーとしてがっつり管理するとなれば、コンテナのほうが圧倒的に有利です。ところがこちらも、繰り返しますが、アプリもちゃんと対応して作らないといけないということで。必ずしもコンテナにすれば全部ハッピーというわけではありません。
Infrastructure as Codeは運用を楽にするか？
それから保守の容易性ですね。「Infrastructure as Codeは運用を楽にしますか？」と言うと、例えば駆けつけはないよねとか、コード化されたことのメリットは大きいと思います。
ただし、実は運用・保守の本質はそこではありません。安定して動作させるということは、コード化されているから安定だということとイコールではないんです。例えば監視業務があると思います。Immutableなコンテナを監視するというのは、実は以前の監視業務より難しいという状況になってしまっていると思います。
というのは、なにしろImmutableですから寿命が極端に短い。そうすると生きている間にちゃんと見張るということが極端に難しいんですね。外から見張るのがほとんど不可能です。なにしろあるコンテナは30秒で死んでしまうという速さなので、それはそもそも正常に終わったのか異常終了したのか、もう判断できないような勢いですからね。
そうすると外形監視ではなくて、コンテナ自身から「俺は健康だ」「俺は今、正常に終了した」と言わせないといけません。従来の監視業務は全部スタイルを変えてコンテナ用に作り直さないといけないということになると思います。
そこで、例えばFluentdのように、新しいスタイルの監視ツールや監視業務みたいなかたちでどんどん生まれているわけですが、従来のものは捨てないといけないとなると、これはまたちょっと大変ですよね。
障害対応も大きく変わると思います。なにしろ状態を保存するというのが難しいです。さっき言ったとおり、サーバはとにかく死んで生き返るという状態ですから。「何月何日の何時の時点で、何回サーバが動いていたの？」という話になると、そのときのスナップショットを取るのも一苦労です。
それで障害対応をしよう、あるいはダンプを取ろうというような話になると、とっても難しいと思います。これは新しいテクニックが必要になってくると思いますが、残念ながら僕はこの分野についてほとんどわからないですね。もし知見のある方が今日いらっしゃいましたら、のちほどぜひご意見をいただければと思います。
コンテナは時代の流れである
これは前佛のスライドからの丸パクリで、コンテナはもう時代の流れです。
「コンテナはサーバ仮想化技術の延長ではない」と書いてあります。どういうことかと言うと、クラウドネイティブによるさらなる活用のためにコンテナはあるのです、という主張です。
ですので、コンテナがポコッとまったく別の領域にあるのではなくて、クラウドネイティブという時代の流れの中に次のステップとして存在するのがコンテナだとご理解いただきたいという主張です。
コンテナは、プロセスをアイソレートして動かす複数の技術だと書いています。これはいきなりポッと出てきたので、ちょっと説明が長くなってしまうことから、前佛のスライドをぜひご覧いただくということにして、ご紹介だけにとどめたいと思います。ぜひまた時間のあるときに、この3つのキーワードをご覧いただければと思います。
どのコンテナマネジメントサービスを使うべきか？
最初にKubernetesに触れると言っておきながら、ほとんど触れられていないですね（笑）。このあと、このあたりからちょっとご紹介差し上げます。
みなさん、いわゆるコンテナを試している、あるいは試そうとしている方はいらっしゃいますか？
（会場挙手）
もう実際に運用されている方？
（会場挙手）
ありがとうございます。これから試そうという方にまずお話をさせていただきますと、どのサービスを使おうかというのが、迷いのポイントになるのかなと思います。いわゆるマネージドサービスから話をしてみたいと思います。今、いわゆるメガクラウドはマネージドサービスをどんどん出しています。
これがちょっとややこしい話で……AWS、Azure、Googleは独自のコンテナマネジメントサービスを最初にパッとリリースしました。もう何年も前ですかね。そのあと、いわゆる標準化の流れがありまして、そのあとにKubernetesを使ったサービスを出し直したんですね。
その結果、サービスがぐっちゃぐちゃになってしまいまして。私はきれいなリストを作ろうとしたんですが、うまくいかなくて、ちょっと失敗しましたので（笑）。本当にわかりづらくて恐縮なんですが。
クラウドベンダー独自規格は一定の水準にある
例えばAWSはElastic Container Serviceというのを独自に出していましたが、ECS for Kubernetesというのを最近出し直しまして、それをEKSと呼んでいます……なんでECS for KubernetesがEKSになるのかまったく理解できないですけども。
これはECSのいわゆるマネジメントをKubernetesで包んだ、というものだと思ってください。AzureはAzure Kubernetes Serviceというものを持っていまして、これはKubernetesがマネージャーになってAzureの上でコンテナを作れるというものです。
実際、KubernetesはGoogleが作ったんですね。ですので、わりとKubernetesネイティブですが、Googleはちょっとズルをしておりまして（笑）。Kubernetesをまた独自拡張したりしているんですよね。Google Kubernetes Engineと言いまして、いろいろなサービスを展開されています。
サービスのレベルも内容も、実は微妙に違っています。例えばKubernetesのマネージャーはホスティングマネージドだけれども、ノードは自分でサーバを借りてノードとしてガッチャンコしないといけなかったり。ノードもコンテナもマネージドで料金は全部込み込みというサービスもあって、けっこうバラバラです。
それから機能がKubernetesの標準のものなのか、そのクラウドベンダー独自のものなのか、ちょっとわかりづらいんですね。なにがどうなっているかここではお話しできないくらい、正直、僕自身がちょっと混乱しています。
クラウドベンダー独自規格は一定の水準にあると思っているんですが、業界標準のKubernetesに今はどんどんシフトしている。そういう状況です。というのは、ユーザーのみなさんはやはりロックインが嫌なんですね。みなさんもどうですか？ AWSでしか使えないと言われたら、ちょっと嫌ですよね。
例えばバックアップではないですが、なにかがあったら他所へ移行したり、安いほうへ引っ越したいというようなこともあると思います。そうすると業界標準がKubernetesだからKubernetesでデプロイしたいなと思われるのではないですかね。
ですので、どのサービスを使うかというのは非常に悩みどころ。慎重に選ばないといけないポイントなのかなと思います。
マネージドか、セルフホスティングか
それからセルフホスティングという考え方もあるのかなと思います。つまり自分でマスターノードを立てて、ノードを含めてさくらのクラウドを使っていただいたり、AWSのEC2上に自分でノードを作ってしまうといったことですね。
セルフホスティングであれば全権利を自分でコントロールできますので、スケールの調整、マスターのコントロール、あるいは冗長度の確立であるとか、そういったものが全部自分でコントロールできます。
一方で、ノウハウが活かせないということもあります。メガクラウドが提供しているマネージドなマスターのマネージャーは事業者のノウハウがある程度入っていますので、お任せできるというメリットもあるんですけれども。
別の意味ではブラックボックスがあるということなので、自分で全部をコントロールしたいということでしたら、自分で立ててみるというのもありだと思います。もしこれから試そうと思っている方がいらっしゃいましたら、こちらも1つのチョイスかなと思います。
コンテナは銀の銃弾ではない
最後にまとめです。すでにクラウドネイティブでコンテナ導入を検討している、あるいは実装されている方は、これからコンテナの利点と課題を精査して経験を積んでいけば強力な基盤として活用できると思います。
コンテナは転換するものではないと思います。100パーセントコンテナというのはあり得ないので、VMとの併用があり得るところかなと思います。
これからだという方に、ちょっと気をつけていただきたいのは、コンテナは銀の銃弾ではないということですね。コンテナは黎明期ですので、火傷する恐れが多分にあると思います。
ただ、もしまだまだうちは未成熟なところがあるなと思っていらっしゃるのでしたら、今がクラウドネイティブに追いつくチャンスだと思います。ぜひ取り組んでいただけたらなと思います。
コンテナはサービス開発の主流になる
最後、タイトルに対する答えとして、ここからはちょっと研究所っぽい予言で終わらせたいと思います。
今日はコンテナについて、いろいろ問題があるという話もさせていただきましたが、たぶん5年程度で解決されるんじゃないかなというのが個人的な予想です。
なぜかと言うと、実は10年前にクラウドで言われていたいろんな悪口が、今、コンテナに対しても同じように言われていると感じるんですね。
10年前のクラウド……EC2が初めて日本に来たときはいろんなエンジニアがEC2に対してすごく悪口を言っていました。Dockerに対する悪口として、10年前にEC2に向かって言っていたのとだいたい同じようなことを、今言っているんですね。
でも、たぶん5年くらいするとそういった問題は全部解決されて、普通にみなさんがコンテナを使うようになっていると思います。10年後、たぶん2028年くらいには20歳くらいの若い子が僕みたいなおじさんに「2018年ごろはコンテナなしでどうやって開発していたんですか？」と言うんですね。たぶんそうなっているんじゃないかなと思います。
コンテナを使わずにサービスを構成するというのは、たぶんもう趣味の問題になってしまっているのではないかと思います。今でもオンプレが大好きで「オンプレじゃないと作らない！」と言っていただいている、我々にとっては大変ありがたいお客様がいらっしゃるので、大事にしていきたいと思っています。それはある意味、ちゃんと理由があってそうされているというお客さんもいらっしゃいます。
たぶん10年後は、コンテナを使わないチョイスがそういう意味合いになっているんじゃないかなと思います。嫌でも、コンテナはサービス開発の主流になってしまうというのが私の結論です。
長々とお話ししてしまいましたが、講演は以上とさせていただきます。ご清聴ありがとうございました。
（会場拍手）
