人間とウェブの未来

「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。

GMOペパボ株式会社を退職しました

本日、2018年9月28日が最終出社日でした。正式には10月末をもって、チーフエンジニアとして務めたGMOペパボ株式会社、また、主席研究員として務めたペパボ研究所を退職します。

現職には2015年4月に入社後、実際には入社前から関わりがあったため、それも含めると約4年間、本当に様々な取り組みを行ってきました。チーフエンジニア兼主席研究員として取り組んできた仕事の中で、社外にアウトプットして伝えてきたこと以外の、より社内業務的な内容はなかなか言語化する機会がなかったので、それらを振り返りつつ、転職に至った経緯をお話ししてみます。


2015年入社当時のペパボ福岡の雰囲気は今でもよく覚えており、良くも悪くも様々なところで血気盛んなメンバーによる争いの絶えない雰囲気がありました。

レンタルサーバ、所謂ホスティングサービスという歴史あるサービスを運営していることもあり「Webサービスに関する知見やアウトプットで世が盛り上がる中で、枯れたサービスとも思えるホスティングサービスを中心に開発運用させられていて、我々は世間からプロダクトとしても技術的にも取り残されているのではないか」というような雰囲気さえありました。そこでまずは、ペパボ福岡においてその雰囲気を大きく変革し、成長の軌道に乗せ、いかに「いるだけで成長できる環境」を作り上げるか、そして、その環境からいかに「事業を差別化する技術」を生み出すかが自分の仕事であると考えました。

そこから、主要メンバーの教育と採用、ペパボのプレゼンス向上を中心として、新しいホスティングのあり方やレンタルサーバの知見を活用したクラウドサービスの提案、サービスの全体アーキテクト、コア技術の研究開発のリード、ビジネス判断のサポート、継続的広報、エンジニアや研究者の教育、採用の強化、エンジニア組織のマネージメント、研究所の立ち上げ、研究開発実績の強化、研究開発とプロダクトの連携、アカデミアとの連携、共同研究、福岡市との取り組み、個々のメンタリングやコーチング、技術的解決の楽しみ方…などなど、書き出すときりがないのですが、上述した雰囲気を変え、会社をより良くするために、あらゆることを達成すべく4年間走り回りました。

特に、次世代ホスティングやマネージドクラウドのように、技術的にチャレンジなプロダクトやコア技術を0から提案し、初期段階の技術的な全体設計やマネージメントを行ったり、全社的なHTTPS化や動的インフラに必要なコア技術などの研究開発を通じて、必要となる新しい技術を作り上げつつ、汎用化したアーキテクチャを提供し、プロダクト化に向けても皆を巻き込むようにしました。

ディレクションから開発運用まで、皆を巻き込みつつ、寛容であることを意識しながら裁量を持たせて仕事を任せるようにしました。皆がプロダクトや技術開発・運用を通して、やりたいという思いを僕が妨げないようにすることを意識しながら、皆が楽しみ、悩み、時には失敗し、思考を深めながら、内省し、振り返って改善していくサイクルを自分たちで回し続けられるように、様々な問いかけをしながらサポートしました。同時に、皆がしっかり既存技術を調査しつつも、既存技術にとらわれずに自分達で新しいアイデアやプロダクトを作り上げる自信を促すような「プロダクトのフレーム」を僕の技術力で提供することを意識しました。

その上で、僕はエンジニアと研究者の専門職でペパボ最上位の職位であるチーフエンジニア兼主席研究員として、事業を意識しつつも中長期目線での技術的・組織的な成長に投資できるように経営と技術の間に入り、バランスをとるようにしました。技術的にチャレンジなプロダクトのフレームを通じて、エンジニアの強い内発的動機付けが生じるように促し、各々が限界を超えられるような技術開発に取り組む中で、全体の技術力や組織力が成長するようにフレームを調整しながら、部分最適と全体最適を並行しながら底上げしていく、すなわち「いるだけで成長できる環境」を実現すべく取り組みました。

このように、僕が意図的戦略を持ってプロダクトやコア技術、基盤となるアーキテクチャを設計・実装しつつも、その後の組織的開発において、意図的に「創発的戦略」を維持し続けられるように取り組むことが、「いるだけで成長できる環境」から「事業を差別化する技術」を継続的に作るための、僕の考えついたひとつの答えでした。

その結果、もちろん自分だけの成果だとは全く思いませんが、仲間に恵まれたこともあり、今となってはペパボ福岡にも職位の高いメンバーが充実し、随分と色々なことを技術的に解決可能になってきました。技術的にもチャレンジで面白いプロダクトの開発運用を通じて、皆がオーナーシップを持って切磋琢磨し、売り上げも意識しつつも楽しんで技術力を高めて、成功体験を積み重ねていく姿は、まさに自分が目指したエンジニア組織のあり方でした。僕が入社した当時の雰囲気はもはやほとんど残っておらず、新しく入ってきたメンバーはそんな雰囲気があったことすら想像もできないレベルにペパボ福岡は変わってきました。そのようにエンジニア組織をうまくマネージメントできるメンバーも増えてきており、組織として連鎖的に多くの技術的挑戦や新しいサービス、面白い機能のリリースを楽しく取り組めるようになってきました。

特に身近なメンバーの成長と活動の幅の広がりから、社外からも「ペパボ福岡に開発拠点を集中させているのですか?」と何度も聞かれるぐらいプレゼンスも向上し、技術的にも強力な環境になってきました。実際にそのような環境で共に働きたいと言ってくださるエンジニアも増え、今もなお強力な仲間が増え続けています。今のペパボは全社的にもとても良い状態になってきており、今後更に良くなっていくでしょうし、僕も社外のエンジニアに強くオススメできる会社であると心から思っています。


以上のように、一見自分で定めた仕事をいい感じで進められているという意味でとても良い状況ではありましたが、一方で、ずっと僕の中にはある種のくすぶった感情がありました。今走り回って取り組んでいることは自分の得意なことで、ある程度雰囲気でやれてしまいます。その成果が会社に認められ、評価され、あっという間に職位も上がり、給料も上がりました。生活も楽になっていきましたし、今後も給料は順調に上がっていきそうです。仲間にも恵まれ、ああ居心地が良い、もうこのままでいいんじゃないか、そう思うことも何度もありました。むしろ、適切に評価され、日々忙しく走り回っていたこともあり、そのくすぶった感情すら、もはや無かったことにできそうなところまで来ていました。

しかし、気がつくと、自分の研究に割く時間は全体の1割も満たしていませんでした。むしろ、自分が博士課程時代までに溜め込んだネタ帳から研究をただ引き出すだけで、そこに新たな研究開発を追加していくことはほとんどできていませんでした。そんな状態の今の自分は、決して過去の自分が望み、目指してきた自分ではなく、送りたかった人生でもありません。その状況を見過ごすことはどうしてもできませんでした。

大学でインターネットに出会い、その可能性やインターネット技術にただ魅了され、サーバが大好きで自分のマンションをデータセンターのようにして、その技術領域の中でいかに世界に技術、ひいては科学で一石投じるか、自分にしかできないことをどこまで追求できるかに全力を尽くしていきたいと思ってきました。それが結果的に日の目を見なくても、そういう生き方に自信を持ち、情熱を持って楽しむこと、やりたいと思ったことをやることこそが自分の目指した人生であるはずでした。

同時に、今得意でやれていることは、何人かで役割分担すれば、僕でなくてもおそらく実現できることです。また、それぞれの内容は、専門的に取り組んでいればもっと適切にやれる人がいるでしょう。このままでは、僕は僕でなくなる、そんな気持ちをごまかし続けることはできませんでした。気がつけば、時は無情にもあっという間に過ぎていきます。現時点で何者でもない自分が、本当に何者にもなれないまま人生を終えてしまいそうに思えてなりませんでした。僕は、僕にしかできないこと、何人集まっても僕にしか実現できない技術を、コードと論文を通じて科学的に作り上げることを夢見てきたはずです。

「技術は勝負ではない」と言われることも多々ありますが、僕にとってそれは技術的に成長することへの妥協にしかならないし、なにより競争がないなんて面白みも刺激もないと思っています。さらには、競争の中でそれぞれがベストを尽くすことで物事が洗練され、発展していくものであるし、それが健全なことだと考えています。また、僕は日本の文化をとても好んでいますし、福岡もすごく気に入っていて、まだまだ子供も小さいので、福岡に腰を据えて家族とゆっくりと暮らしたいとも思っています。

その上で、自分自身は技術に全力で投資し、グローバルな水準で自分の専門分野の技術で日本から世界と勝負して、現時点で僕より優れた研究者やエンジニアと同じ土俵で議論し、世界を支える技術を生み出し、最終的には世界すら大きく変える技術を作りたいのです。そしてなにより、その過程を自由に楽しみながら全力を尽くし続けたい、研究開発の中で新規性や有効性、信頼性、さらには実用足りうる実効性を追求しながら技術で勝負することを楽しみたい、そう思いました。

僕にとっては、プログラミングや研究開発、ひいては技術や科学、深く思考することそれ自体が目的であり、それを好きな環境で家族を大切にしながら、目的を達成し続けるためにお金を稼ぐ、そんな生き方があってもいいんじゃないでしょうか。その純粋な活動が、社会や会社への貢献に重なるような居場所探すことも一つの生き方なのだと思います。そうやって課題解決を超えた新たなストーリーから生み出される技術や、それを実現する技術力を持つ自分を高めることこそが、結果的に会社、ひいては社会に価値を還元できるようになるという考え方もありえるのではないかと思います。

「いるだけで成長できる環境」にすべく様々なプロダクトやアーキテクチャのフレームを作り、その中で自律的に成長していく皆を見ていて、僕ももう一度その流れをより広い領域で自ら作り出し、次はさらに自分の技術力を高め、科学するために、その流れに身を任せてみたいと思った面もあります。そのためにも、居心地の良い今の環境を一度リセットし、良くも悪くも出来上がってしまった自分の立ち位置や関係性、甘えや制限を取り払ってしまおうと思いました。ペパボは今でも大変良い会社だと思っていますし、沢山のことを学ぶことができました。一方で、自分が本来、別の方向性で自由にやりたかったことをようやく実現できるところまで来れたようにも思います。そして、転職を決意しました。

ペパボは今、新しい時代に突入しつつあります。近くで一緒に困難に立ち向かってきたメンバーは本当に優秀ですし、彼らが次の時代を作っていくほうが「もっとおもしろくできる」だろうとも思います。これからのペパボは、次の時代を担う彼らに任せて、さらなる高みを目指し、これまでにない新たな色を作っていって頂きたいと思います。また、共に数々の困難に立ち向かった、心から信頼する彼らの新たな取り組みを外から見てみたいという気持ちもあります。

そういう考えもあって、僕はもう一度、優秀な皆に負けないように、OSSと論文を通じて自分の技術力の限界に挑戦すべく全力を尽くしていこうと思います。僕、そして僕の専門分野の場合、それがきっと、会社、業界やコミュニティ、ひいては社会に「僕の価値」を還元する最も生産性の高い生き方であると信じているし、経験的にもそうであると理解しているからです。その生き方に自信を持ち、情熱を絶やすことなく楽しんでいきたいです。

年齢ももう気がつけば34歳、「技術で世界を変えたいし、勝負もしたいし、なによりその過程を自由に楽しみたい」という理由で、自分にとってたったひとつしかない人生の歩み方を決めてみるのも良いでしょう。ただ素直に情熱を強く感じられる人生を送ること、僕にとってはそこに大きな価値があり、そして、それが僕の人生観だからです。大学時代にただサーバが大好きで、自分のマンションをデータセンターのようにしてプログラミングしていたあの頃のように、もう一度やりたいことをやるために一歩ずつ踏み出していく勇気こそが、今の自分には必要だったのです。


このような僕の個人的な決断について、応援してくれた上司と同僚、そして家族に心から感謝します。この4年間で得たスキルや考え方は、さらに自分の取り組み方をも押し上げてくれると確信しています。

2018年11月からは、さくらインターネット研究所の上級研究員として、また、福岡オフィスでの初のエンジニア・研究者として、さくらインターネットの膨大なインフラやデータ、プロダクトを通じて、しっかり腰を据えてOSSと論文を書きながら、特に世界に向けて、グローバルな水準でクラウド・ホスティングに関わるインターネット基盤技術の研究開発に専念することを使命に頑張っていきます。

これまで通り実用性というものを強く意識しつつも、短期的な単なる工夫による技術の先細り、あるいは、机上の空論になりかねないように、エンジニアとしての強みを活かして、普遍的で結合容易なインターネット基盤技術の研究開発をしていきます。研究者兼エンジニアとして、研究開発で社会を前に進めるためにも「アイデアだけでもだめ、実装だけでもだめ、周りを巻き込みそれをきちんと実践できる所まで作り上げないといけない」というスタイルは変えません。

その上で、しっかりと世の中にアウトプットしながら、中長期目線で会社や社会に技術をもって価値を還元していきます。その活動を通じてもちろん、さくらインターネットの新しい顔にもなれるように頑張ります。

「話をしてみたい」と油井さんにメッセージを送った次の日には「こういう時のために余白の時間を設けてるんですよ」と笑顔で仰って福岡まで飛行機ですぐに飛んで来てくださった田中社長をはじめ、面談では僕の博士論文の踏み込んだ内容を沢山聞いて頂いた鷲北所長、そして、このような考えを持つ僕を全面的に肯定して下さり、裁量を持って受け入れて頂いたさくらインターネットの皆様に感謝いたします。

ということで、相変わらずこんな感じの自分勝手な僕ではありますが、皆様、よろしければ変わらず今後ともどうぞよろしくお願いいたします。いつでもお声がけ下さい。

また開発合宿やりましょう。

f:id:matsumoto_r:20180922195911j:plain

ペパボの皆さま、大変お世話になりました。

ウィッシュリスト

エンジニアでもある僕が国際会議で発表して思ったこと

2018年7月23日から5日間に渡って開催された、COMPSAC 2018(The 42nd IEEE International Conference on Computers, Software & Applications Staying Smarter in a Smarting World)において併設で開催されたADMNET 2018(The 6th IEEE International COMPSAC Workshop on Architecture, Design, Deployment and Management of Networks and Applications)で、研究発表をしてきました。研究内容については、以下の研究所のブログに書いていますので、本エントリでは自分の思いを中心に述べたいと思います。

rand.pepabo.com

僕はこれまで何度か大学時代に国際会議で発表しているのですが、ペパボ研究所としてははじめてになります。残念ながらCOMPSAC2018のメインシンポジウム(毎年採択率20%前後のトップカンファレンスクラス)において、acceptには至りませんでしたが、併設の国際ワークショップに登壇するという、ペパボ研究所初の国際会議での発表となりました。この件については以下のエントリで述べました。

hb.matsumoto-r.jp

ペパボ研究所として国際化を進めながら、我々が単なる机上の理論ではなく、プロダクトを見据えて研究開発している新しい技術の正しさと広がり、そしてその普遍性をグローバルな水準で問うという意味では、我々にとっての大きな一歩になりました。

エンジニアとして、久しぶりにきちんと英語で論文を書いて査読を通し、英語で発表をしながら全ての質疑を英語で行えたということはとても良い経験になりました。質疑の中では、プロダクションにおける従来手法の実験で、証明書数がほとんど増えていない理由や、提案手法がTLSハンドシェイク単位で証明書を読み込んだ後のメモリ保持期間やその扱いにおける議論が行われました。とはいえ、まだまだ正しい英語ですばやく回答をできていなかったので、セッション終了後にも質問頂いた先生に改めて説明するなどしました。これらの経験からも、明確に英語で議論を行うスキルが、研究の成長に対して足かせになっていることは明白なので、これからもっと論文を英語で書いて英語で発表し、最も重要である英語の質疑応答を積極的に行っていきたいと思います。

5日間参加する中で最も印象に残ったセッションは、IEEEの歴代Presidentによるパネルディスカッションでした。その中で「IEEEコミュニテイの良いところは、会社や大学、あるいは一般的な社会においては、何かと立場や役職等があるけれど、COMPSACのようなカンファレンスに世界中から研究者や技術者が集まった時には、彼らは皆平等で何の壁もなく、立場など気にせず自由に研究開発に対して議論し、研究を育て、研究を広げていくことができる。自分たちはそういうコミュニティが好きだし、だから自分はここにいる。」と仰っていて、ああ、なんて自分は小さな世界にいたんだ、と改めて思わされ、非常に感銘を受けました。

もっともっと、そのような壁を気にすることなく、グローバルな水準でコンピュータ・サイエンスに関する技術、ひいては科学を育てていく場所が今ここに、目の前にあって、自分はそこにいるんだ、ということを身をもって実感することができました。英語で論文さえ書けば、こんな簡単にこういう場に居られるんだと、改めてその価値を認識しました。

とはいえ、やっぱり悔しい気持ちがとても大きいです。COMPSACには、大学だけでなく沢山の企業やエンジニアもいて、僕と同じような土俵で学び続けている人達が沢山いました。さらには、C++の開発者であるBjarne Stroustrup先生をはじめ、明らかに技術によって今の時代を作ってきた研究者・エンジニアの存在がそこにありました。国際化に向けての大きな一歩を踏み出したと述べましたが、自分はその土俵にすら立つことすらできず、COMPSAC2018のメインシンポジウムにおいてはrejectされたことを、今も昨日のことのように覚えていて悔しい気持ちしかありません。また、COMPSACのメインシンポジウムで登壇している皆さんの研究内容の高度さ、そして質疑応答での高度な掛け合いは、その思いを更に強くさせられました。

例えば、特に中国から若い人が沢山メインシンポジウムで発表されていたのですが、質疑応答も含めて堂々とした圧巻のやり取りは、英語も含めて自分の勉強の足りなさを反省するばかりでした。また、先生であっても、英語を頑張って絞り出しながら議論されている方も沢山いらっしゃって、結局のところこういう場にちゃんと出てきて頑張って英語で議論をする努力をどれだけするか、というだけの話であって、僕は自分ができないということが恥ずかしいからその場を避けているだけで、それはただ格好つけているだけとも言えて、とにかく頑張っている人たちと比べて、そんな自分の姿勢が何よりも恥ずかしいと思えました。そういった勉強に対する姿勢すら、まだまだ自分は足りていませんでした。

ペパボ研究所の国際化に向けて、ペパボのプロダクトをグローバルな水準でより素晴らしいものにするべく、事業を差別化する技術の正しさと広がりを進めていくためには、僕自身の今のスキルが上限になってしまってはペパボ研究所の先なんてありえません。もっと正確に英語で論文を書けるようにし、もっと学び、もっと手を動かし、もっと深く思考し、我々の技術をトップカンファレンスのようなグローバルな水準で問い続け育てていく、これらを進めるためにも、これからもただひたすら自分のエンジニア・研究者としてのスキルを高めていくと改めて心に誓うきっかけになりました。

本当に世界は広い。でも、ようやくそこに一歩踏み出せそうな気がします。もっと、もっとグローバルに広がった世界で、壁を作ることなく学び続け、プロダクトを見据えた我々の研究開発の正しさと広がり、そして普遍性を問うていきたい。それがプロダクトに更なる価値をもたらし、いずれ社会に還元されていく、そのためにも、エンジニアとして、研究者として、もっとこの活動を進めていかねばならない、改めてそう思えた国際会議でした。

マルチプロセッサのタスクスケジューリングに基づいたWebシステムにおけるコンテナのハードウェアスケジューリングのシミュレーション構想

データフローグラフ(タスクの依存関係をグラフ化したもの。タスクは処理の特性等の違いもある)をいかに効率良くマルチコアCPUにタスクスケジューリングするかという研究がある。マルチプロセッサシステムのタスクの割り当てとスケジューリングはTASとも呼ばれる。

効率的なTASを実現するための研究開発において、例えば任意のデータフローグラフがあった場合に、自分たちが考えたTASアルゴリズムに対してデータフローグラフを流し込んだ結果、CPUコアに適切にタスクスケジューリングできて従来のアルゴリズムよりも速く処理ができた、電力の面で効率よく処理ができた、といったシミュレーションと定量評価を手元で行うことが多い。

また、CPUコアの特性の違いも含めて適切にスケジューリングするヘテロジーニアスコアに最適なスケジューリングアルゴリズムの研究もある。

この考え方をWebシステムに当てはめると、例えばコンテナの再配置がリクエスト単位で動的に行われる場合、コンテナの収容ホストは、TASにおけるCPUコアと言える。また、ホストの収容率によってホストの処理性能に違いが出た場合、それはヘテロジーニアスコアと同様、動的に変化するとはいえ、ホストの処理性能が違う特性をもつコア、あるいはプロセッサである、とみなすことができる。

このように考えると、コンテナに対するHTTPリクエストとコンテナの再配置が、TASのタスクスケジューリングにおけるタスクとみなすこともできる。つまり、コンテナに基づいたWebシステムのハードウェアスケジューリングの問題、つまり、どの特性を持つホストにどのようにタスクであるリクエストを振り分け、コンテナに仕事をさせるか、という問題は、CPUコアのタスクスケジューリングの問題とほぼ同じように解釈可能になる。

では、タスクの性質と依存関係を示すデータフローグラフとは、Webシステムに置き換えた場合どういうものになりうるか?ここはまだ言語化するほどには答えは出ていないが、定義できそうな気がしている。

もしこれが定義できれば、これまで歴史的にも取り組まれていたマルチプロセッサのタスクスケジューリング問題と同様に、その資産を利用して、Webシステムのハードウェアスケジューリングを手元で定量的にシミュレーション可能となり、コンテナによる複雑なWebシステムにおける「いれてみないとわからない」というステージから、シミュレーションによってハードウェアスケジューリングアルゴリズムの定量評価か可能な時代となり、そのような状況から脱却できる可能性もある。

さらに、手元でシミュレーションできるということは研究開発効率も上がり、複雑なWebシステムに対して、様々なスケジューリングアルゴリズムを容易に確かめることもできる。

FastContainerのようにリクエストとコンテナの状態遷移が紐付くシステムのハードウェアスケジューリングを考える中で、まずこの複雑なWebシステムのハードウェアスケジューリングのシミュレーションを、TASの研究を参考に確立したいと思った。そうすれば、ハードウェアスケジューリングという難解ではあるが収容設計に準ずる重要な研究に対して、我々の目的にあったハードウェアスケジューリングを研究開発することが容易になり、また一歩システムにおけるなめらかさに近づくことができそうだ。

DevOpsの文脈でのDevelopment ResearchすなわちDevResについて

DevOpsについては多くが語られてきました。一方で、開発者と研究者の関係をDevOpsの文脈、いわゆる、Development ResearchすなわちDevResとしたときの関係性についてはあまり語られていません。これからの企業、ひいては、社会における開発者と研究者のあり方についてはDevOpsという名の元に解決しようとされてきたことの多くがまた繰り返されるように思えます。むしろ、DevOpsとして取り組んできた歴史よりも、技術者と研究者との関係性やその分断は、古くから続く課題といえるかもしれません。

続きを読む

ngx_mruby v2のHTTPクライアントをv1よりも最大90倍高速にした

写真のような感じでRubyKaigi2018で登壇し、RubyKaigiを経て、ようやくngx_mrubyのv2をリリースしました。基本的にv1と互換性がありますので、今後はv2を開発していくことになります。

github.com

ngx_mruby v2の目玉機能としては、Rubyスクリプトからノンブロッキングのsleepとhttp[s]クライアントを使えるようになったことです。実装的には、nginxのsub requestという機能をうまく使って、ノンブロッキングのhttp[s]クライアントを汎用的なsub_requestメソッドとして実現しています。

では、本エントリではそのノンブロッキングhttpクライアントがどの程度高速処理可能になったかを実験してみましょう。また最後には、RubyKaigi2018の感想も述べます。

  • 実験
    • proxyサーバのblockingとnon-blockingのhttpクライアントの設定
    • apiサーバの設定
  • 実験結果
    • レスポンスタイムを変化させたベンチマーク
    • 同時接続数を変化させたベンチマーク
  • まとめとRubyKaigi2018の感想
続きを読む

第二回 #wsa研 でHTTPリクエスト単位でコンテナを再配置する仮想化基盤の高速なスケジューリング手法について発表しました

第二回Web System Architecture研究会で、タイトルの内容について発表してきましたので、そのスライドと予稿を以下に公開します。

speakerdeck.com

英文タイトルは以下の通り。

Fast Scheduler for a Cloud Platform to Relocate Containers at Each HTTP Request

クラウドサービスの普及に伴い,個人のWebサイトでもクラウドサービスに類する機能を利用して,突発的なアクセス集中に耐性があり,かつ,利用したリソース使用量に応じて課金するサービスの提供が求められている. 我々はその要求に応じるために,Webサイトをコンテナ上に構築し,コンテナの起動や停止,複製やリソース割り当てといった状態の変更を素早く実行できるコンテナ管理アーキテクチャFastContainerを提案した. 一方で,単一のコンテナが特定のサーバに収容されている状態で,サーバが過負荷に陥ったり停止したりするような状況においては,障害時にコンテナの収容サーバ情報の変更を手動で構成管理データベースに反映させる必要があった. 本研究では,HTTPリクエスト処理時において,収容サーバ,および,その経路までの状態に応じて,自動的にコンテナを収容するサーバを決定し,サービスを継続させる,HTTPリクエスト単位でのコンテナスケジューリング手法を提案する. 提案手法では,FastContainerの状態変化の高速性に基づいて,コンテナが頻繁に収容サーバを変更されてもサービスに影響がないことを利用する. それによって,プロキシサーバから収容サーバに1個のICMPパケットで応答速度を計測し,少ないパケット数と応答速度に基づいた短いタイムアウトで収容サーバの反応時間を計測できる. そのことで,単一のコンテナであっても,HTTPリクエスト単位でのコンテナスケジューリングを実現し,可用性を担保する.

  • 1. はじめに
  • 2. Webサービス基盤の負荷分散と可用性
    • Webホスティングサービス
    • クラウドサービス
    • FastContainerアーキテクチャ
  • 3. 提案手法
  • 4. 実験
    • 予備実験
      • ICMPタイムアウトに関する予備実験
      • Apacheコンテナの起動時間に関する予備実験
    • 再配置時のレスポンスタイムの本実験
  • 5. まとめ
    • 接続待ちソケット生成前のプロセスイメージを利用したWebサーバの汎用的な起動時間短縮手法
    • 参考文献
続きを読む

OSレイヤでWebサーバが起動時に実行するシステムコールを監視し起動完了直前のプロセスをイメージ化する

今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法(PoC)について紹介します。

続きを読む