次世代ホスティングの話

第1話
福岡から支えるサービスインフラ
第2話
次世代ホスティングの始まり
第3話
技術で世界と繋がる楽しさ

次世代ホスティングの話

第1話  福岡から支えるサービスインフラ
第2話  次世代ホスティングの始まり
第3話  技術で世界と繋がる楽しさ

今回の登場人物

松本 亮介

松本 亮介
技術基盤チームのアドバンスド・シニアエンジニア。2015年春から福岡生活を開始し、すっかり九州グルメと温泉の虜に。OSS開発、革製品やゲーム、ミニ四駆など、実は幅広い趣味の持ち主。

高岡 修一
ホスティング事業部インフラチームのサブマネージャー。IngressではまもなくLv16に手が届く、国内屈指のエージェントの一人。九州のおすすめスポットは鹿児島の桜島と大分のやまなみハイウェイ。

渡邉 潔
ホスティング事業部インフラチームのエンジニア。福岡支社では釣り部に所属。ホークスファン。IngressではLv11の通勤エージェントとして活動している。九州のおすすめスポットはびっくり亭。

原口 宗悟
ホスティング事業部インフラチームのシニアエンジニア。好きな九州名物は『炭寅』のつくね、おすすめイベントは370年以上続く伝統芸能・長崎くんち。趣味は読書で、おすすめ作家は小路幸也

緻密な構成管理とAPIの開発

松本
僕がペパボに入社する前から、周りで「ペパボはすごい」と噂になっていたことがあるんです。それはロリポップ!の構成管理がすごく緻密に組まれていること、内部での処理をAPI化していることなんですが、その実現に関わった高岡さんと渡邉さんに経緯をお話しいただきたいと思います。
渡邉
きっかけは、最初にお話ししたとおり、ゆるゆるの運用体制をどうにかしなきゃいけない!と思い立ったのがきっかけです。昔はサーバーが納品されるたびにテキストベースの構築手順書を参照して構築していました。もちろん時期によってOSのバージョンが違うから、新しくなっていた部分は作り直して、書き足していって…という方法をとっていて、完全に秘伝のタレになっていたんです。でも、サービスの規模はどんどん大きくなっていて、このままではいけない、お客さんに質の高いサービスを提供するために、もっときちんと構成管理をしようという話になって導入に向けて動き始めて、6年前からPuppetでサーバー構築できるようになっています。
松本
着手から導入までの道のりはかなり体力の要るものだったと思いますが、今振り返ってみてどうですか?
渡邉
ものすごく役に立ってます。昔はサーバー1台分のテキスト手順書を読み流すだけで半日終わってたのですが、今では慣れた人だと1日10台構築が当たり前にできる。今のスピード感で構築できるようになったのは構成管理あってこそなので、絶対に必要だったと言えますね。
松本
新しくサーバーを構築するときだけでなく、既に運用されているものに新しい機能の追加や変更を加える場合にも使える仕組みなんですか?
渡邉
その仕組みはまだできていないんです。本当はやりたいんですけどね。
松本
やりたくてもできない理由はどこにあるんでしょうか?
渡邉
既に運用されているものに手を加えるということは、本番環境を変更することになるので、新しく構築する場合に比べて導入の敷居が高いんです。ただ少しずつ導入に向けて動き始めていて、今はPuppetを流すと全台に適用される仕組みを、希望する部分にだけ変更を加えられるような書き方に変更しているところです。メンテナンスもPuppetでやるという時代が、近いうちにくると思いますね。
松本
Puppet自身もそれぞれの役割に応じて細分化させていけば、実現できそうですね。では次に、APIについても伺いましょう。まず、ここで言うAPIというのは、どういう役割を果たしているものなのでしょうか?
渡邉
新規申し込みユーザーのセットアップは、すべてAPIで行っています。お客さんが申し込むと同時にアカウントを作り、ディレクトリを作り、メールアドレスも作ります。簡単インストール機能もAPIで実行しています。一番最近だと、ユーザーさんのサーバー間移設がAPI経由で簡単にできるようになったという大きな動きがありました。
松本
それがすごいですよね。ホスティングサービスって、お客さんのコンテンツがサーバーにひもづくものなので、あるお客さんが高負荷になってしまったときには単純に利用を制限して負荷を抑えるという場当たり的な対応になってしまうんです。でもロリポップ!はそのお客さんの領域を丸ごと別のサーバーに移動して、制限をかけずに負荷を解消するということが簡単にできる。一般的には共有ストレージのような大きなストレージにまずデータを置いて…といういくつもの工程を踏まなくてはいけないんですが、ロリポップ!はAPIと綿密な構成管理のおかげで、普通のサーバーにお客さんが置いてるデータを、そのまま別のサーバーにボタン一つで簡単に移設することができる。これにはほんとうに驚きました。
渡邉
APIの導入のきっかけは、ペパボにあるたくさんのホスティングサービスのセットアップスクリプトのインターフェイスを一つにまとめたかったのが最初です。以前は開発側が実行しているセットアップ処理がサービスごとに別だったので、それぞれ異なる設定が必要でしたが、APIを導入した今は開発側がサーバー側を意識しなくてもセットアップが完了するようになりました。
松本
そのおかげでインフラ側の開発もウェブアプリ側の開発も、抽象化するレイヤーがAPIとしてあるので、すごくやりやすくなった。このサーバー側のAPIは、インフラチームが開発してるんですよね。先ほどの話に出てきた、サービス品質を向上させるための開発。福岡インフラチームの業務には、そういうところも含まれているんですね。

いま明かされる次世代ホスティングの姿

松本
ロリポップ!を中心にペパボのホスティングサービスの歴史と現状についてお話を聞いたところで、福岡インフラチームが今取り組んでいる次のステップ『次世代ホスティング』と銘打ったプロジェクトについても聞いていきたいと思います。
原口
もともとサービスの品質を向上させて、お客さんにもっと快適な環境を提供できる、まさに『次世代ホスティング』とも呼べる仕組みをどうにか実現したいということはCTOのあんちぽくんも交えて以前から話をしていました。でも、運用の体制を徐々に整えて一部は自動化してきたものの、現在でも作業ボリュームは大きくて、品質向上にリソースが割けない状態が続いていたんです。気持ちはあっても身動きがとれないもどかしさを抱えていたところに、この春、技術力が高いのはもちろん、ウェブアプリにもインフラにも造詣が深いキーパーソンが福岡支社に入社されまして。今、目の前にいる松本さんという方なんですけど。本格的にプロジェクトが動き始めたのは、松本さん入社からですかね。
渡邉
すごく大きなきっかけでしたよ。ホスティング業界は安定志向だと思われる方もいるかもしれないんですが、中にいるわれわれとしては、安定稼働させるだけではなくて、新しい技術の開拓も新規顧客の獲得もどんどん提案して実行していきたいのに、手一杯でほとんど実現できない。そんな状況がずっと続いていたので、すごく悶々としていました。その閉塞感をすぱっと取り払ってくれたのが、松本さんでしたね。
松本
ありがとうございます。たくさん名前が出てきたので、モデレーターとしての調子が狂いそう(笑)。じゃあ、運用の自動化も前進して、新しい技術や情報がどんどん吸収できるようになって、もっとロリポップ!をよくできるんじゃないかっていう気持ちは強くなってきましたか?
原口
気持ちというか、「絶対できる」っていう確信を持ちました。ハードウェアのリソースの向上だけではなくて、ソフトウェアで課題解決できるはずだということは最近身に沁みて感じていることなんですが、そこに導いてくれる人がいなかった状況だったんです。松本さんと話をすると目からうろこの発見が次々にあって、先が見通せるようになったのが嬉しいですね。
松本
実はホスティングやインフラ技術の道筋を見せるというのは技術基盤整備エンジニアとしての僕の役割のひとつなので、伝えることができてよかったです。
では次に、次世代ホスティングの具体的な取り組みについて聞いていきましょう。まずは、ロリポップ!のような共用サーバーで、お客さんごとに最適なリソース配分をコントロールするという点について。これはとても重要ですし、運用の労力も、品質そのものも左右される部分だと思うんですけど、原口さんはこのプロジェクトの中で、既存のロリポップ!のリソース制御よりもっと柔軟な制御方法の実装に取り組んでいるようですが、それについて教えていただけますか。
原口
Linuxの機能のひとつであるcgroupを使って、常に快適にサービスを利用してもらえる仕組みを作ろうとしています。共用サーバーではあるお客さんの領域が攻撃を受けてしまうと、そのサーバーのリソースを100%使ってしまって、他のお客さんが全く使えなくなってしまうという状況が起こる。ユーザー一人あたりが使えるリソースを臨機応変に分配して、使いたい人が使いたいときにリソースを使うことのできる仕組みをcgroupで実装しようとしています。
松本
すごいですね。
原口
Apache経由でリソース制御をするので、mruby、mod_mrubyを使ってcgroupをコントロールして、ユーザー単位のリソース制御の仕組みを構築してます。
松本
cgroup単体を使おうという方向にならなかったのはなぜですか?
原口
cgroup単体で使うと開発工数が大きくなって使いづらくなってしまう懸念があったんです。なので、より簡単にモジュール開発のできるmruby を使っています。
松本
Apacheでやりたいことを実現するためにはC言語でプログラムを書く必要があって敷居が高くなってしまうという問題に対して、mod_mrubyは、簡単にRubyで書くことができるので、運用するインフラエンジニアとしても、工数を減らして開発して、本当にやりたいことができるというメリットがあるわけですね。
原口
インフラエンジニア全員が運用も開発もバンバンできるというわけではないので、かなり敷居が下がった感じがします。
松本
高岡さんもmrubyを書いてみたということを聞いたんですが、どうでしたか?
高岡
私はスクリプトを書くくらいしか開発をやったことがないし、Rubyもそもそも書いたことないので、本当にmrubyが書けるのか?という思いで始めましたが、書けてしまったというのが結果です。自分のやりたいことができた。
松本
設定のミドルウェアの運用知識があると、その延長で書けてしまうんですね。
高岡
まさにそういう感じでした。設定を書く感覚で書いてみたら、自分の思った通りに動くっていう印象。
原口
ApacheやNginxの設定ファイル、各パラメータについては、普段から.confファイルなどを見る習慣があるので理解できるんですけど、実際にそれを動的に制御したい場合にどうすればいいのかということが、以前は全然わからなかったんです。mrubyの導入によって、その辺のコントロールはすごく簡単になりました。
渡邉
インフラエンジニアにとってはすごくメリットが高いような気がします。
松本
Rubyの基本的な文法は学ぶことになるので、それをきっかけに、逆にアプリに近いところの知識も増えていって、スキルの幅が広がる感じはしますね。
原口
まさに開発とインフラをつなげるって感じですね。
松本
構成管理やAPIのくだりでサービスの歴史的な経緯をお聞きしたんですが、渡邉さんは次世代ホスティングでさらなる改善に着手されているんですよね。具体的にお話を伺えますか?
渡邉
先ほど軽く話は出たんですけど、現状だとPuppetが本番に流せないという問題がありました。それを解決するために、自動的にPuppetを流して、自動的にテストをする仕組みを作っています。テスト結果が担保できていれば本番でもPuppetが流せる、というところをゴールにして取り組んでいます。まだ開発途上ではあるんですが、だんだん形になってきたので、今後も継続的に手を動かしていきたいと思っているところです。
松本
構成管理とAPIでは対応しきれていない、稼働中のサーバに対してどう変更を加えていくか、どうテストして自動化を進めていくのかという点に今後取り組んでいくと思うんですけど、現時点での設計はどう考えていますか?
渡邉
GitHub EnterpriseにPuppet修正のPull Requestがあがった時点で、Puppetをテストサーバーに自動で流したいなと。流したサーバーに対して、Serverspecと呼ばれる本番サーバーの設定の静的なテストをするモジュールを自動で流すというところまで実現させたいという構想があります。本当のことを言うと、その先の本番でPull Requestがマージされるとメンテナンスを行うというところまでやりたいんですが、そこまでいくにはハードルが高いので、まず検証環境でPuppetを流し、Serverspecを流すというところまではもっていきたいと思っています。本番でPuppetのメンテができない問題を解消したいと思ってます。
松本
Serverspec以外で追加したいテストのアイディアがあれば聞いてみたいんですが、どうですか?
原口
Serverspecはサーバー内部から見た状態をチェックできるんですが、品質やパフォーマンス、ベンチマークなど、外から見た品質のテストをどうするのかというところですね。
渡邉
外部からの視点として、Nagiosでコマンドを叩いてやっているテストを自動で流せるといいですよね。
松本
監視や負荷テストを充実させていくと、サーバーの挙動を整備していくことで、より安心感のあるテストの自動化環境を作れると思います。品質の高さも担保できる。どうやって実現するのかという点は、また別の難しさがありますが。
原口
難しいですね。新しい技術を吸収しつつ自分たちで開発しつつ、やっていくという感じですね。
松本
高岡さんも立場はサブマネージャーではありますが、技術者としてお客さんから見たときにパフォーマンスにすごく影響のあるウェブプロキシというコンポーネントをより高速化させる取り組みに携わっているんですよね。ウェブプロキシとはどういう仕組みで、どういう働きをしているんでしょうか?
高岡
実際にお客さんがFTPなどを使ってデータを送る場所であるusersサーバーをバックエンドとすると、フロントエンドと呼べるのがウェブプロキシというところで、複数台のロードバランサの下にぶら下がって、お客さんのウェブサイトへのアクセスを分散してさばいているところです。お客さんのドメインがどのサーバーにいるのかという情報をデータベースで管理していて、アクセスが来たらウェブプロキシがそのデータベースに情報を参照しにいって、もらった結果をもとにして、そのドメインの入っているusersサーバーに、そのパケットを渡す仕組みになっています。
松本
現状、そのウェブプロキシはどういうふうに作られているんですか。
高岡
現状のウェブプロキシはApacheです。
松本
すごく複雑なことをやっていると思うんですが、Apacheの標準機能ではないですよね。
高岡
そうですね。自社で開発したApacheモジュールを使ってます。C言語で書かれてますね。
松本
それを高速化するために、今新たな取り組みをされてるんですよね。
高岡
まずはApacheをNginxに置き換えるというところから始めています。独自モジュールはmod_mrubyに書き換えました。メンテナンスも、今後その項目に書かれたRubyを見れば誰でもその動きが理解できるし、変更もしやすくなると思います。
松本
キャッシュが残っていないときDBに問い合わせる部分についても、原口さんが効率的なアイディアを提案してくれましたよね。
原口
高岡さんが実装しようとしていたのは、DBを参照して、一度参照したものは高速化のためにキャッシュに乗せ、そのキャッシュデータを基に振り分けを行うという実装だったんですけど、DBの更新と同時にキャッシュも更新しないといけないので、MySQLのデータが更新されたタイミングでmrubyを実行して、そのままキャッシュの更新まで行うという機能を提案しました。
松本
そうすることで、これまではAPIを使って制御していた、外部にあるデータベースの変更を検知してキャッシュ更新するという処理を、一つのサーバ内部で完結することができるようになったんですね。
原口
そうですね。今回はmrubyという仲介役がいることで、かなり簡単に効率的にできる実装になりました。インフラエンジニアにとってはかなり使いやすいプログラムですね、mruby。
高岡
実際にウェブプロキシのパフォーマンスも、安定性も上がりました。既存のウェブプロキシだと、負荷をかけすぎると不安定になっていた部分が、安定してレスポンスを返せるようになった。
松本
サービス品質がよくなっていく手応えを感じますね。それぞれが取り組んでいることをどんどんサービスに導入することで、お客さんにとってもよりよい環境を提供できるようになると思います。
渡邉
次世代ホスティングプロジェクトは、リソース制御やテストの自動化によって業務を効率化する一方で、お客さんがやりたいことを実現できるような新たなサーバー構成の開発など、サービス価値を向上させるために時間を割いていくものだと思っています。それをふまえて、ホスティングサービス全体の未来を見据えて新しい形を探っていく姿勢も忘れず持ち続けたいですね。
松本
以前のインタビューでも言及したんですが、今はVPSとかクラウドとか、お客さんにルート権限を渡して開発者が自由度高くいろいろなものを作れるサービスが普及して、このままいくとホスティングは旧時代の技術として埋もれてしまう可能性もある。でもその一方で運用コストはどんどん高くなっていて、開発者が頭を抱えるという問題も出てきています。
ホスティングの勝機はまさにここにあると思うんです。ホスティングサービスの運用・開発者はお客様のコンテンツそのものを予測・管理できない中で、どれだけOS・ミドルウェアといった抽象化レイヤーで運用の問題を解決するかに長年取り組んできました。VPSをはじめとする、いわゆるレンタルサーバーよりも自由度の高い環境で生じる運用の問題を、ホスティングに関わるエンジニアはコンテンツに左右されずに解決できる非常に高いスキルとノウハウを持っているわけです。だからこそ、ホスティングサービスの基本として提供している質の高い運用を、困っている人のためになる次世代のホスティング基盤として提供できる仕組みが実現すれば、もう一度ホスティングの時代が来るんじゃないかと考えています。
そういう問題を解決するために、我々ペパボのインフラエンジニアはすでに次世代ホスティング基盤の設計に取り組んでおり、来たる時代に様々なシステムの運用コストの問題を解決するための受け皿になるサービスをリリースしたいと思っています。それはホスティングサービスに関わるエンジニアだからこそ実現できると確信しています。


~第3話へつづく~