人間とウェブの未来

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

エンジニアや研究者からマネージャーや経営者になる時の不安について

自分は元々とにかく技術志向のエンジニアであり研究者であった。とにかくコードを書いたり論文を書いたりすることが生き甲斐であった。

そんな自分が数年前に色々考えた結果、マネージャーや経営者の道を志すようになったのだが、その際によく聞かれることがある。「技術を中心にやれなくなる不安や葛藤はなかったんですか?」と。

その答えとしては「その不安や葛藤はない」である。なぜかというと、マネージャーや経営者に強烈な専門性を感じているからだ。勉強すればするほど、あれ、これはエンジニアや研究者の時にやっていた学び方とほとんど変わらないのではないか、と思えているからである。

おそらく僕自身も、かつてはマネージャーや経営者に専門性を見出せておらず、エンジニアからそうなることは考えてもいなかった。むしろ、技術者としての諦めのような風に捉えていたかもしれない。しかし、自分がそこに身を置くにつれて、全くもって雰囲気で適当にやれるものではなく、考えのないたった一言でチームの生産性や成果が低下することもある。これもまたコードに似ている。

さらに、書籍や論文を読んで設計して試したりしながら、組織や会社を良くしていくプロセスは、限りなく自分が取り組んできたエンジニアリングや研究と似ているのだ。例えば、IBMやマイクロソフトがハーバードビジネスレビューなどで公開している最新の論文や記事を読めば、仮説検証に基づいて、いかに技術的かつ定量的に評価しているかがわかる。その中で、マネージャーや経営者も、自分にとってはエンジニアや研究者と変わらず、専門性の高い技術職のように認識できたのである。

あとは、じゃあマネージャーや経営者としてやっていく時に不安はないかという話だが、それはもちろん自分の力不足で何者にもなれず、成果も残せないかもしれないという不安は多少ある。しかし、エンジニアや研究者であった時から一貫しているのは、「学び続けていればそれで良い」と思っていることだ。そして、それが自分の拠り所でもあるのだ。努力をしているという感覚でもなく、キャリアの方向性を変えても学び続けていること、そして、とにかく継続して楽しむこと、それさえやっていれば成功しても失敗しても楽しい人生だったと思える気がしている。そこに何か結果が後からついてきたらお得だね、ぐらいであって、そこに努力の結果としての見返りは求めていない。

というわけで、最近よく質問されることについて自分なりにまとめてみた。ひょっとすると、エンジニアの人達もマネージャーや経営者を選択するタイミングが来た時に、何か不安を持つかもしれない。でも僕が思うのは、マネージャーも経営者ももはやエンジニアや研究者のように専門職であり、同じような感覚で学び続けたり、実践し続けたりできるかもしれない。領域が変わるだけで、案外楽しいと思えるかもしれない。

もしそのような考えで前向きにマネージャーや経営者としての道を選択することになったら、是非一緒にお話ししたり楽しくマネージメントや経営のことをお喋りしましょう。これもまた、コードや技術の話をワイワイするようなイメージです。どうやって学んでいるかなど、そういうコミュニティもこの業界でできていくと楽しいですね。

論文のrejectという希望

ここ2、3年で目標としていた、IEEE Computer SocietyのFlagship Conferenceの一つとされているCOMPSAC 2020のメインシンポジウムに、ファーストオーサの論文がフルペーパーで採録されました。

送られてきたメールによると、今回のメインシンポジウムのフルペーパ採録は24%以下ということで、昨年の250本程度の投稿論文があることを考えると、全体のフルペーパ採録は60本程度になるかと予想できます。去年はCOMPSACのメインシンポジウムにショートペーパとしてファーストオーサの論文が1本採録、ラストオーサの論文がショートペーパで1本、併設ワークショップに1本という実績でした。

さらに、2年前は未だに当時のショックを覚えているぐらいに、メインシンポジウムでの査読でフルボッコの査読結果を頂き、なんとか気を持ち直してワークショップに通すことができた、ぐらいの実績でした。その当時の話は以下のエントリにも書いています。

hb.matsumoto-r.jp

hb.matsumoto-r.jp

そういう意味で、自分のやり方を2年前に見つめ直し、国際会議に自分の論文を通すための方法論について模索し、論文の書き方、更には国際会議に通すための英語の論文を模索したのが昨年でした。その模索についての去年の夏の段階での考えは以下のエントリにまとめています。

hb.matsumoto-r.jp

レベルの高い国際会議からのrejectの理由と考察

さて、ここからが今日のエントリの本題です。去年の夏の段階でCOMPSACのレベルの国際会議にショートペーパとして採録するための自信とそのスキルはついてきていたように思いますが、やはりメインシンポジウムのショートペーパとフルペーパというのは歴然とした差があり、ショートペーパではページ数が6ページに対して、フルペーパでは最大12ページと、その分量からも国際会議で扱われる論文としての重要度に大きな差があります。CORE Ranking Portalというサイトで、学術コミュニティが協力して国際会議の難易度をスコアリングしており、さくらインターネット研究所はそれがすべてというわけではありませんが、ある程度参考にして戦略を練っています。ここでのRankingは概ねそのカンファレンスのメインシンポジウムのフルペーパーを指していると理解しています。

去年は夏以降に、COMPSACのショートペーパに通せたのだからといって、カンファレンスのレベルやランキングを定義しているCORE Rankに基づいて、Aランクや、所謂トップカンファレンスと呼ばれるA*ランクのカンファレンスに論文を書いて投稿していました。しかし、全ての投稿論文はrejectされ、厳しい指摘とともに査読結果が返ってきては、直視することができずに頭を抱え、数日間あいだをあけてなんとか査読結果を読むということを繰り返していました。

査読結果からは主に、

  1. あっと驚く新規性がない
  2. 論文の構成がまずくて伝えたいことが伝わらない内容になっている
  3. 実験のベースラインが明確でない

といったことが書かれていました。ただ、査読の段階では文面からは意味がわかりますが、なんとなく腑に落ちない感覚でした。なので、自分が所属するさくらインターネット研究所にお願いして、rejectされた国際会議に参加させてもらって、一体acceptされている論文はどういう内容で、どういう研究発表がなされているのかを実際に見てみたいと思い、rejectされた国際会議にすべて参加してみました。

すると、全ての発表に共通していたこととして、

  • 最新技術が今どこにあるか?(The state of the art)
  • 自分の研究が活きるユースケースはどこか?(リアルシステムでの効果)
  • 自分の研究は最新技術と比べてどういう面でどういう成果が上げられているか?(The state of the artと比べてどこが優れていてどこがnoveltyなのか)
  • 評価の際にどのレベルをクリアできれば、有効であるといえるか?(妥当なベースラインの設定がなされているか、そのベースラインに対してどう優れているか)

というポイントをほぼ全ての講演で満たされている事に気づきました。これに気づいた後に査読結果を思い直すと、まさに、トップカンファレンスで皆が当たり前に共通して述べていることそのものが欠けていると、新規性が見えず、内容が理解できず、有効かどうか信頼足りうるかがわからない、という上述した査読結果の3つの指摘の話になると腑に落ちたのでした。

また、それが腑に落ちたときに、査読結果にはそれを改善するための指摘やわからないことの主張、実際にどのように誤読させてしまっているかの議論、などを読むことができるので、これはすなわち、論文のrejectは自分の研究や論文を明確に改善できるチャンスであり、希望なのだと思えるようになりました。

reject, reject, reject, reject ..... accept!

そこで、今年の2月に投稿したCOMPSAC2020ではそれらの査読結果で指摘された内容を、新規性の主張、前提の一致、最新技術の立ち位置、最新技術と提案手法の多面的な比較と考察、評価のベースラインの明確化を意識して書き直して提出しました。すると、先週COMPSACのプログラム委員から査読結果が返ってきて、

「This paper is well written. The readability of this paper is good.」

「The proposed method is novel and feasible.」

「Congratulations on your paper being accepted for the conference! 」

という、いまだかつてないポジティブなメッセージとともに、査読についても、「私はこう思うけど、どう思う?」とか「こうやると多分もっとよくなると思う」などと、今までの指導的な査読ではなく、あくまで同じ目線で査読メッセージを書いてくれているような査読結果の通知が届きました。

自分は、昨年はほとんどのプロポーザルでrejectをされてしまったのですが、そのrejectと査読結果、そして、実際にrejectされた国際会議に参加してその違いを知ることは、自分の研究を明確に成長させることのできる希望である、と思います。博士課程を修了後は、自分がファーストオーサで、かつ、企業の研究所で指導的立ち位置でラストオーサとして論文を書く中で、ようやく「自分の良いと思える論文」そして「国際会議などに論文を通す書き方」を模索した上で、それが、COMPSAC2020メインシンポジウムのフルペーパacceptという形で結果を得られたことが、まるで自分のここ数年の取り組みが認められたかのように思えて、感慨深い気持ちになりました。そんな気持ちを忘れないように、このエントリを書いています。

rejectと査読結果は希望となる

最後に、これから国際会議の論文にどんどん挑戦していこうとしている研究者の皆様に、rejectというのは希望であるということお伝え、あるいは、rejectで悩んでいる人と共有できると良いなと思っています。実際にrejectされると落ち込むのですが、rejectされるということは改善の余地が明確にあるということを客観視できる機会であるといえます。研究していると、それを得るチャンスというのは意外となかったりします。

なので、何度rejectを受けたとしても、その査読結果をどうにか研究や論文に少しずつでも反映していけば、その研究は常に前進し続けることができます。前に進めるという希望は、きっと自分の研究を次の領域へと押し上げてくれるのではないかと思います。何度rejectされても、一歩ずつ進んで最終的にacceptされてしまえば、落ち込んだことも忘れられますし、きっと良い思い出になります。

僕もまだまだこれからrejectを繰り返しながら、研究者として前に進み続けたいと思います。rejectされる限り、研究し続ける希望があり続けるのだという気持ちで更にやっていきますし、rejectされて落ち込んで途方にくれている人がもしいたら、そんな人にこのエントリが届くと幸いです。

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

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

ウィッシュリスト

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の感想
続きを読む

ngx_mruby v1.20.0で動的listener設定をサポートしました

タイトルの通り、ngx_mrubyのhttpモジュールとstreamモジュール両方で、mrubyによる動的Listener設定をサポートしました。

動的Listenerとは、nginxのlistenの設定をmrubyで書いて、起動時に動的に設定を読み込めるようにできる機能です。以下の例を見た方が分かりやすいかと思います。

# $ ulimit -n 60000

worker_processes  1;

events {
    worker_connections  30000;
}

daemon off;
master_process off;
error_log logs/error.log debug;

stream {
  upstream dynamic_server {
    server 127.0.0.1:8080;
  }

  server {
      mruby_stream_server_context_code '
        (20001..30000).each { |port| Nginx::Stream.add_listener({address: port.to_s}) }
      ';

      mruby_stream_code '
        c = Nginx::Stream::Connection.new "dynamic_server"
        c.upstream_server = "127.0.0.1:#{Nginx::Stream::Connection.local_port * 2}"
      ';

      proxy_pass dynamic_server;
  }
}

http {
    server {
        mruby_server_context_handler_code '
          s = Nginx::Server.new
          (20001..30000).each { |port| s.add_listener({address: (port * 2).to_s}) }
        ';

        location /mruby {
          mruby_content_handler_code 'Nginx.rputs "#{Nginx::Connection.new.local_port} sann hello"';
        }
    }
}

このように書くと、nginxのTCPロードバランサが20001ポートから30000ポートまでListenした上で、接続のあったポート番号の数値の2倍のポート番号へTCPプロキシします。さらに、nginxのhttp側では20001ポートから30000ポートの2倍のポート番号でListenし、そのポート番号に応じてhelloを返します。

この設定でnginxを起動すると、これまでlistenディレクティブを沢山並べる必要があり、CRubyとerbなどを使ってプロビジョニング時にゴニョゴニョ書かなければいけなかった処理を、スッキリとmrubyで書くことができるようになります。また、ポート番号をデータベースやホストの状態に合わせていい感じにリッスンするような実装も可能でしょう。

$ netstat -lnpt | grep nginx | wc -l
20000

上記のような設定でcurlでアクセスすると、以下のようにレスポンスが返ってきます。

[ubuntu@ubuntu-xenial:~]$ curl http://127.0.0.1:20001/mruby
40002 sann hello
[ubuntu@ubuntu-xenial:~]$ curl http://127.0.0.1:20002/mruby
40004 sann hello
[ubuntu@ubuntu-xenial:~]$ curl http://127.0.0.1:29999/mruby
59998 sann hello

ふむふむなるほどべんり!

ということで皆様是非ngx_mruby v1.20.0の新機能をご活用ください。

github.com

1月から5月の技術関連の登壇資料まとめと振り返り

1月から上期がはじまり、昨年は出産関連などで9月を最後にあまり登壇できていなかったので、今年は頑張るぞ〜と意気込んでいたわけですが、怒涛のように登壇依頼がやってきて、やばいこれはきついぞ!と思いながらもなんとか一段落するところまでやり切れたのでちょっとどこかに旅にでたいです。

その前に、結構登壇して色々喋ったり資料作ったりしたので、時系列でまとめておきます。

今期は技術カンファレンスだけでなく、学術研究方面でも発表できたので、自分の立ち位置としてはわりと網羅的に発表できたかなと思います。

全体

まずは以下に1月から5月までの全体の発表実績をリスト化しました。

  1. 松本亮介, ロリポップ!で目指すPHPのためのセキュリティと性能要件を同時に満たすサーバホスティング技術, PHPカンファレンス福岡2016, 2016年5月.
  2. 松本亮介, なめらかなシステムのアイデアと概要設計: 生命の観点からWebシステムを解釈する, e-ZUKA Tech Night, 2016年5月.
  3. 松本亮介, セキュリティと性能要件を同時に満たすサーバホスティング技術の最新動向, 第39回インターネット技術第163委員会研究会 -ITRC meet39-, 2016年5月.
  4. 松本亮介, cgroupとLinux Capabilityの活用 - rcon and capcon internals, 第9回 コンテナ型仮想化の情報交換会@福岡, 2016年4月.
  5. 松本亮介, なめらかなシステム: 人工知能はホスティングサービスの暗闇も救う, GMO HosCon -Hosting Conference- @大阪, 2016年4月.
  6. 松本亮介, モデレータ:GMOグループトークセッション:国内シェア54%を支えるGMOホスティングの裏側, GMO HosCon -Hosting Conference- @大阪, 2016年4月.
  7. 松本亮介, なめらかなシステム: 人工知能はホスティングサービスの暗闇も救う, GMO HosCon -Hosting Conference- @渋谷, 2016年4月.
  8. 松本亮介, 登壇:GMOグループトークセッション:国内シェア54%を支えるGMOホスティングの裏側, GMO HosCon -Hosting Conference- @渋谷, 2016年4月.
  9. 松本亮介, エンジニアトークセッション「ペパボ福岡でたずさわる最高のエンジニアリング」, ペパボ福岡で働く~エンジニア・ディレクター向けトーク&相談会 in大阪~, 2016年3月.
  10. 松本亮介, 人工知能はWEBサーバーの暗闇を救う, IPSJ-ONE 2016, 2016年3月.
  11. 松本亮介, ペパボ福岡の技術的強み なぜ今エンジニアはペパボ福岡で働くべきなのか, 【人気都市・福岡で働く!】移住にまつわるエトセトラ〜エンジニア・ディレクター向けトーク&相談会〜, 2016年2月.
  12. 松本亮介, HTTP/2とmrubyの活用 HTTP/2時代のサーバ設定になぜmrubyが必要か, 第2回技術共有会, 2016年1月.
  13. 松本亮介, PFSを考慮したTLS終端とngx_mrubyによる大量ドメイン設定の効率化 nginxにおける大量ドメインの証明書を動的に処理する方法, 第1回技術共有会, 2016年1月.

ではそれぞれ1つずつ振り返っていきます。

続きを読む

ペパボ福岡の技術的強みと働くメリット

について、先日イベントで講演してきました。

ちょうど自分自身、福岡にきて1年程度で、講演時に福岡出身の方に手を上げていただくとほぼ9割以上が福岡、または、九州の方だったので、いきなり自分が福岡の良さを語って良いのかピンチに陥りましたが、なんとか福岡だけでなくペパボ福岡の魅力をお話できたかなと思っております。また、自分の新鮮な気持ちも伝えられたかなとも感じました。

続きを読む