GMOペパボが立ち上げた「ペパボ研究所」の主席研究員 松本亮介さん（id:matsumoto_r）と、はてなエンジニアの坪内佑樹（id:y_uuki）が対談しました。技術ブログにはてなブックマークを付け合う間柄だった2人の語りから、レンタルサーバーの運用技術を学術研究として突き詰めた松本さんの研究成果「高集積マルチテナント環境」（「ロリポップ！」の「次世代ホスティングサービス」の技術として適用）、そして生き物のようなシステムを目指す「なめらかなシステム」の構想が浮かび上がってきます。
（上写真、左より）GMOペパボ株式会社 ペパボ研究所 主席研究員 シニア・プリンシパルエンジニアの松本亮介さん（id:matsumoto_r）、株式会社はてな システムプラットフォーム部 シニアエンジニアの坪内佑樹（id:y_uuki）。構成はITジャーナリストの星暁雄です。
（※この記事は、GMOペパボ株式会社の提供によるPR記事です）
■ 修士課程を飛ばして博士課程に
──松本さんの経歴を拝見すると、修士課程を飛ばして博士課程から入学したとあります。どんな経緯が？
松本 話を始めると長くなるんですが……きっかけは、学部で留年したことです。他の学生に教える立場だったので、「自分はできる！」といい気になっていたんですが、提出したコードが古くて動かず、単位を落としてしまいました。ショックでした。
この1年をどう活用するか、どうやれば取り返せるのか考えた結果、レンタルサーバーの会社でアルバイトすることにしました。その頃、自分に対して猛烈に自信があったのですが、いざアルバイトに行ってみると周囲のエンジニアがみんなすごい。「このままではまずい」と実力差を感じました。
研究をしたいという気持ちはありましたが、このままでは井の中の蛙、良い研究者になれないと思い、就職してしばらく働いたら、研究に戻ろうと考えていました。研究の世界に戻る意思があったので、勤務先ではめちゃくちゃがんばりましたね。
松本亮介（まつもとりー）さん
松本 社会人3年目の2011年、東日本大震災があった直後に、ずっと行きたいと思っていた研究室（京都大学大学院情報学研究科の岡部研究室）にメールを送ったんです。
教授と3時間ぐらい話をさせてもらって、やっていることを説明したら「修士のレベルは十分にありそうだから論文をまとめてみよう」と言われました。
しかし、2011年7月に開催された1回目の資格審査では、「査読付き論文を通す必要がある」という理由から通過せず、翌年の2012年1月に再度審査があったので、それまでに査読論文を通して発表しました。同時にアイデアが生まれてきて、3～4本論文を出しました。
──短期間にそれだけ論文を通したのは大変なことだと思います。GMOペパボの次世代ホスティングサービスに取り入れた「高集積マルチテナントアーキテクチャ」や「スレッド単位の権限管理」のアイデアは、この頃からあったのですか？
松本 ありました。その頃からインターネットの運用技術を研究したい、という話をしていました。
──GMOペパボに入社したのは、どんないきさつでした？
松本 企業の事業として運用されているサービスに研究成果を実装し、サービスを良くしていく方が自分の性に合っていると思っていました。引き続き論文の執筆や研究をしたかったので、そういうことが許されるオープンな社風の会社に就職したいと思っていたタイミングでGMOペパボを知り、2015年4月に入社しました。
──GMOペパボではどんな仕事を？
松本 最初は技術基盤チームという、少人数のチームに入って、自分の研究成果を「ロリポップ！」の「次世代ホスティングサービス」に適用する仕事をしていました。
入社して1年経つか経たないかの頃に、あんちぽちゃん（GMOペパボ 執行役員CTO/ペパボ研究所長の栗林健太郎氏）と「研究開発もやっていかない？」という話をするようになりました。そこから2016年7月の「ペパボ研究所」設立につながっていきます。
──松本さんと坪内さんの出会いについて教えてください。
松本 はてな京都オフィスで2014年6月に開催された「Hosting Casual」というイベントに行ったら、僕の前にゆううきさん（坪内のこと）がいて、声をかけられました。
坪内 以前からはてなブックマークでの交流はあったのですが、直接お会いしたのはそのときが初めてでしたね。技術面ではコンテナ型仮想化技術が一番の接点です。2013年ぐらいにDocker（オープンソースのコンテナ管理ソフトウェア）が出てきて、自分もDockerを触っていたので勉強会で発表することがありました。そのうち、どちらかというとLinuxカーネルの要素技術に興味が出てきて、まつもとりーさんのブログ記事もよく読んでいました。
松本 Dockerが出てくる前から、権限分離やリソース管理の技術を研究していたんです。だからDockerが出てきたときは、他の人とは見方が違っていたと思います。それでゆううきさんの書いたDockerの記事を見て共感するところがありました。新しく出てきたものをただすごいと言うのではなく、どういうもので、どう良いのか、技術要素を分けて見ていたので。
■ 博士課程の研究成果を6ヶ月で実サービスに適用
──2015年4月にGMOペパボに入社して、その年の9月に「ロリポップ！」の「次世代ホスティングサービス」をリリース。ずいぶん早いですね。
松本 博士課程に在学中、Apacheの権限管理モジュールの開発など、システムを実装できるようにしていたんです。それまで約15年動いてきた「ロリポップ！」のサーバーを改善していく、そこに自分の博士論文の内容を全部適用するという仕事でした。
──見方によっては新入社員が6ヶ月でデプロイまで持っていった訳で、かなり異例なのでは？
松本 入社する際に、もともと博士課程での研究成果を生かすという前提があったので、本当は3ヶ月でサービスに入れるつもりだったんです。
坪内 すんなり進んだのですか？
松本 そうですね。自分の研究内容が運用を重視したやり方だったこともあって、うまく合意を取りながら進めることができました。インフラの現場に訳が分からない人がやってきて、急に「これをやる」と言い出すのは良くないやり方なので。
──あらためて、次世代ホスティングサービスではどんな課題を解決したのか教えてください。
松本 「どうやって高集積なマルチテナント環境でセキュリティを保ちながら性能を出すか」です。レンタルサーバーは多種多様なお客さまが使うものです。セキュリティを担保しないといけないけれど、そこでプロセスを使って分離すると、性能を落とさないといけない。プロセスをforkするのはめちゃくちゃ高コストですから。
例えば数万のホストをプロセスで分離して高集積な環境に収容しようとすると、設定だけで1プロセスで2Gバイト～4Gバイトのメモリを確保しちゃう。forkすると、プロセスの内容はCopy-On-Write（forkの動作であるプロセスのメモリ内容のコピーを遅らせることで性能を上げる仕組み）でうまくやるけれど、Page Table Entry（PTE。仮想アドレスと物理アドレスのマッピングを管理するテーブル上の個々の項目）に100万個ぐらいのエントリができて、それをコピーするだけでも重たい。4Gバイトのプロセスをforkすると1秒ぐらいかかる。プロセスを起動するためにexecすると、PTEを削除するのにまた1秒かかる。プロセスの生成と起動だけでシステムCPUを2秒占有することになります。
プロセスより軽量なスレッドを使えることができれば高速になります。そこで、スレッドで権限分離するアーキテクチャを考えて、実現しました。プロセスの生成や破棄をしなくて済むようになりました。
──集積度の度合は？
坪内佑樹（ゆううき）
松本 運用上は、メモリ32GBのサーバーで、10万ホストは収容できることが分かっています。今のところ、国際学会でもこれ以上の高集積は出ていません。これが一番新しい成果です。
坪内 はてなのようなWebサービスの場合、レンサバのようにたくさんのサイトをホストするということがないので、そこまで高集積にしようということがないですね。プロセスやスレッドのような細かい単位ではなく、VM（仮想マシン）レベルで分けています。
──検証はどのようにやったんですか？
松本 レンタルサーバーの条件を再現するのは難しいんです。非常に変わったプログラムが動く可能性もあるし、負荷をかける人もいる。極力ベンチマークはしますが、最終的には本番に入れてみないと分からないのです。
坪内 多種多様なユーザーがいるホスティングの場合は特に難しいですね。
松本 そこでカスタマーサポートがありとあらゆるアプリを動かして、人の手で検証しました。すごかったんですよ、全員やる気まんまんで！ レンタルサーバーの技術は枯れているし、ホスティングなので大きく変更できる余地はあまりなかったのに、「そこをもっと良くできる」ということで、非常に燃えていましたね。
■ 生き物をヒントにした「なめらかなシステム」
──現在のGMOペパボ研究所の研究テーマである「なめらかなシステム」とは、どのようなものですか？
松本 「なめらかなシステム」はWebサービスのシステム管理に関する常識を変えていくための取り組みです。もともと「Webシステムは生き物っぽい」という考え方を突き詰めるとすごいシステムができるんじゃない？という考えを持っていて、それを形にしたものです。
松本 アイデア自体は10年前からあったのですが、発表という形で整理したのは2016年2月ごろです。2016年3月のIPSJ-ONE（情報処理学会全国大会で開かれる研究者のライトニングトーク大会）で発表しています。IPSJ-ONEというのは情報処理学会の各研究会から代表で選ばれた専門家が“すごいこと”を考えて発表する場で、39分野の研究会から19人が採択されるというところです。ちなみに2017年3月のIPSJ-ONEでは、ゆううきさんに発表してもらいます。
──「なめらかな」という表現がユニークですね。
松本 名前を考えたのはあんちぽちゃんです。鈴木健さんの『なめらかな社会とその敵』（勁草書房）という本をヒントに考えました。
人が管理しなくても安定して活動し続けるけれど、人とシステムの関係がうまく成立するような、そういうシステムにしたいという思いがありました。さらに、システムが高度に発達すると、人とシステムとの関係が薄くなりがちですが、人にもシステムにも快適な世界にできないかと考えていました。
坪内 「なめらかなシステム」について勉強してきたんですが、自分が理解した範囲をお話しすると……。
システムにも、機嫌がいいときや調子がいいとき、その反対のときがある。例えばシステムの調子がおかしくて、理由は分からなくても再起動で直ることがある。実際のシステムの内容は複雑すぎて、人間の認知限界を超えてしまう。普通の考え方では、システムを完全に保とうとする方向に向かうけれど、そうではなく、不完全さを許容した上で、部分的には不完全でも全体としてうまく動いている。
……というのが「なめらかなシステム」なんでしょうか。
松本 まさにその通り。その感覚も、研究だけしていると分からなくて、サーバー運用の現場から来ています。
相手はコンピュータだから理屈があって、「なんか重たい」「再起動して直りました」では本当はだめなんですけど、OSカーネルを作っているような熟練者が手がけていたって、おかしくなるときにはおかしくなります。完璧を目指すより、不完全さを許容する仕組みの方がいいなと。それが最初の発想であり、GMOペパボではその発想をWebサービス基盤に応用したシステムの総称を、「Dimention-free Autonomous Operating System」、略してDAOSと呼んでいます。
■ 最新の考え方を全部取り入れないと「なめらかなシステム」を実現できない
──「なめらか」にするための技術的な内容はどのようなものでしょうか？
松本 僕らの体にある細胞は常に置き換わっていますよね。その細胞がサーバーだと考えると、1個1個の細胞じゃなくて体全体を健康に保ちたい。サーバーが死んだり生まれたりするのを繰り返して循環させて、サーバーの数を平衡状態に保ちたい。それが「なめらかなシステム」の一つの考えです。
坪内 サーバーの入れ替わりが30分かかるようだとダメで、高速に落として立ち上げたい、そこでコンテナ技術が必要になりますね。オートスケールやイミュータブルインフラストラクチャ、サーバーレスアーキテクチャといった考え方にも近いのでしょうか。
松本 なめらかなシステムはそのすべてに関連します。全部取り入れないと実現できないんです。
ゆううきさんが挙げたオートスケールもサーバーレスアーキテクチャも、クラウドサービスとして登場していますが、あれってエンジニア以外の人にとっては難しいじゃないですか。例えば、僕の妻がやろうとしてもできません。
GMOペパボでもオートスケールへの取り組みを考えたことがありますが、エンジニアでも難しい。これではWebコンテンツを作っている一般の人には使いこなせない。それを解決する「なめらかなシステム」を実現するアーキテクチャの一つを考えました。FastContainerと呼んでいます。
坪内 （松本さんからスライドを見せてもらいながら）これはGAE（Google App Engine）っぽいというか、Lambda（AWS Lambda）っぽいというか……。
松本 GAEは2008年からありますが、エンジニアでも使うのが難しいことがありますよね。シンプルな視点で運用しやすいものを作らないといけないと考えています。
坪内 近いものでKubernetes（Googleが発表したDockerを管理するフレームワーク）があります。あれはプロダクションレベルでは運用が大変です。Googleだからできるという側面がある。ということは、FastContainerはGAEのようなPaaSとは違う形で提供するということでしょうか。
松本 そうです。例え話をすると、古くからあるFastCGIは実はいいものなんですよ。モダンに考察すると、FastCGIではイベントドリブンにWebサーバーを起動できます。しかも、ある一定期間起動後に、勝手にプロセスが死んで（終了・解放して）くれるという、Webサーバーを使い捨てにするようなイミュータブルな処理をしている。それって、すごくmortalですよね。これまでのWebサーバーはimmortalさを求められてきて、逆にバッチ処理などはshort-livedでした。
坪内 CGIはリクエストごとに1回起動ですが、FastCGIは一定時間の間は立ち上がって使い回すんですね。
──「mortal」「immortal」「short-lived」の考え方を教えていただけますか。
松本 サーバーの性能面を保ちたいなら、ずっと起動させておくのが普通の考え方です。これがimmortalさですね。そうでなければ、毎回起動して終了する。これがshort-lived。
我々としては、なめらかなシステムの一つの実装であるDAOSにおいて、もっと各サーバーやプロセスにmortalさを持たせたかったんです。それをコンテナで実現できたら、というのがFastContainerです。そして、DAOSにおけるスレッドをMortalと名付け、その振る舞いはFastContainerアーキテクチャに基づく、と考えると我々としてはしっくりくるわけです。
▽ FastContainerアーキテクチャ構想 - 人間とウェブの未来
松本 immortalとshort-livedの中間のような、しばらくは動いていて快適に使えるけれども、用がなくなれば落ちるようなものがFastContainerであり、mortalなアーキテクチャといえます。例えばアプリケーションが動いている間だけ課金されるようなサービスにも応用できます。
坪内 そこはAWS Lambdaのイベント処理とも似ていますね。
──古い技術を新しい視点で読み直すわけですね。
松本 学術研究ではよく採用している「ものの見方」ですね。いろいろな技術に対してその見方をしていくと、昔は使えなかったものが、時代が経つと使えるようになります。ハードウェアのスペックなどが進んだ結果として今に生きてくるわけです。
■ エンジニア以外でもオートスケールを使いこなせるように
──「なめらかなシステム」でどういうことができるようになりますか？
松本 例えばインターネットを使う人はエンジニアだけじゃないですよね。アクセスが集中したとき、サーバーが落ちるのは嫌だというとき、スケールアウトもスケールアップも、エンジニアにはできても、普通の人には困難です。
そこでFastContainerのアーキテクチャを使うと、レンタルサーバーのように使っていると勝手にスケールアウト、スケールアップを自動で実現してくれます。例えばWordPressで書いた記事に対して、はてなブックマークがたくさん付いてアクセスが大量に来たとき、従来のレンタルサーバーだとリアルタイムでスケールアップできませんでした。それが、記事がバズったタイミングで、リアルタイムにスケールアウトもスケールアップもできます。
もちろん、データを保持する部分と、状態を持たない部分は明確に分けないといけません。まずは簡単なものからスケールできるようにします。
──いつごろできるんですか？
松本 1年以内にはサービスとして作れるかな、と思っています。
例えば、GoogleやAmazon、Facebookも学術論文は出しています。でも、僕らには手が出ないような大規模なデータセンターを完璧に管理していないとできないような内容が多いんです。僕の場合は運用技術の研究なので、限られたコストと制約の中で優れたことができる研究をしています。
坪内 よく現場で感じるのは、お金や人の制約がある中でどうやるか、という前提があることです。運用技術はそれを含めて進めているということですよね。
松本 GMOペパボの規模で研究所を作るメリットは、例えば悩んだときに、それをアウトプットすれば現場からフィードバックがもらえることですね。困ったことをコミュニティの力で解決できる。だから、こういう構想をアウトプットすることはプレッシャーに感じません。
坪内 なるほど。
松本 （FastContainerのスライドを見せて）コンテナが自動的に落ちるパラメータを設定します。コンテナ起動時に設定しておくんです。
坪内 専用デーモンがある？
松本 その役割をするのがhaconiwa（mrubyで実装された、Linuxコンテナ環境を制御するためのコンテナエンジン）です。
坪内 例えばこのコンテナを上げるとか下げるとかはDockerでもできなくないと思うんですけど、haconiwaの方がいいポイントは何ですか？
松本 Dockerは、コンテナのプロセスの各種状態に合わせて挙動をフックして細かく制御できません。例えば、自動で死んで（コンテナを終了・リソース解放して）くれる？
坪内 自動では死なないんじゃないかと。haconiwaはそこを積極的に殺しに（終了・解放しに）いくわけですか？
松本 あるコンテナについてホストをまたいで一時的に別のサーバーで動かしたいとき、CMDB（構成管理データベース）の収容先を変えた瞬間に全部別のサーバー側に移動して、元のサーバーの上のコンテナは知らない間に死んで（終了・解放されて）いく。管理しなくていいんですよ。スケールアップもhaconiwaで実装しているんですが、これもリアルタイムでできます。
さらに、haconiwaは単なるコンテナエンジンではなくて、ネットワーク上で連携してなめらかな状態を作るDAOSのシステムコールレイヤーと考えています。だからそういう意味でも、haconiwaというシステムコールから起動されるコンテナはDAOSにおけるスレッド、つまりMortalであると言えるわけです。
坪内 CMDBのスケールアウトは大変ではないですか？
松本 実は既に現行の「ロリポップ！」でもやっていて、問題ないです。DBはMySQLをベースに、キャッシュ用途でmemcachedやRedisを使っています。秒間1万から2万アクセスといった性能が出ています。
坪内 ところで「Apacheは捨てたい」なんてみんな言っていますよね。
松本 nginxは内部実装はさておき、使う用途においてはいろいろシンプルですからね。レンタルサーバーとしては、昔からある.htaccessの利用といったサービス仕様についてApacheじゃないと提供できないものがあるので、Apacheのサポートは必要です。
坪内 ngx_mrubyやhaconiwaのような、社内のいろいろな人が作ったソフトウェアをサービスとして組み合わせているのがいいですね。
松本 haconiwaもnginxも中身がよく分かっているので、後はフルスクラッチで作りつつ動かしています。データやデータベースの分散などにも今年は挑戦していきたいです。
──どうもありがとうございました。
[PR]企画・制作：はてな
取材・構成：星 暁雄
写真：小高 雅也
