さくらインターネット研究所での1年

さくらインターネット株式会社に昨年の2月に入社してから1年(と2ヶ月)が経過した。さくらインターネット研究所での研究員としての新しい働き方にも慣れてきた。論文や口頭発表などの締切も落ち着いてきたので、ここまでの1年を振り返ってみる。

やりたいことに集中できる

さくらインターネット研究所では、自分を取り戻してやりたいことに集中できる自由な研究環境がある。

さくらインターネット研究所では、テーマは与えられることはなく、自分がおもしろいと思うテーマを設定する。成果物の形態も自由だ。一般に研究というと成果物の形態として、論文を想像するが、論文でなければならないといった要求はない。

そうはいっても、本当にどんなテーマでもよいわけではなく、「さくららしさ」を求められる。この先のみえない時代では、未来において外的環境が大きく変化する可能性がある。したがって、「さくららしさ」は、あえて明確に定義されていない。*1

さくらインターネットは、データセンターやインターネットのインフラ事業を一貫して続けてきたことを踏まえると、コンピューティングのための基盤にまつわる多くの課題が、「さくららしさ」と言ってもよいかもしれない。さらに、これから人々の生活にICTが広く深く浸透していくことになることや、情報科学の学際的性質を踏まえると、「さくららしさ」は、多くの可能性に満ちているはずだ。

要するに自分がやりたいこと以外にやることがほとんどない状況を与えられている。エンジニアの知人にこのことを話すと羨ましいねと言われる。研究者の知人にこのことを話すと羨ましいと言われるか、それはそれで難しくないか?と言われる。難しくないか?、というのは、新規性がありかつ有用性のある問題設定を、自分でイチから考えるのは難しくないかという意味だ。

やりたいことを見つけて、なんらかの成果がでるまでやり続けるというのは、意外と難しい。僕が新卒でさくらインターネット研究所に入ったとしても、何をやったらいいかわからなくなるだろう。とりあえず取り組むことを決めても、それでいいのか、他のものでもいいんじゃないかとか、これは自分よりも得意な人がいるからもっとも別のことを、などと、考え込んでしまう。それが本当にやりたいことなのかを確信できない状態となる。

参考までに、所長の@ken_washikitaさんのブログ記事を紹介しておく。

あとは、僕の場合は、成果物の形の一つに学術論文やテックカンファレンスでの発表があり、それらには締め切りがある。昨年1年は、論文誌論文1本、国際会議論文1本、国内査読付き論文1本、査読なし2本、テックカンファレンス2件、4時間講義1件、その他発表7件の締め切りがあった(論文は、論文誌以外は発表もあり)。締め切りがなければ、無職とあまりかわらないかもしれない。

広範なインフラ技術

もともとWebサービス企業でSREをやっていたため、クラウド上で構築されたWebシステムという枠の外にあるコンピューティングやネットワークについて具体的に考える機会がなかった。

しかし、さくらインターネットは、Webサービスはもちろん、コンピューティング全般を対象とするデータセンター基盤をもっている。その結果、今では、クラウドの下側や、エッジコンピューティング、量子コンピューティングなど(後者2つについては@kikuzokikuzoさんが探索されている)に触れる機会が増えた。研究所以外では、FPGAモバイル回線の基盤PaaS開発などの話題が登場する。

さらに、研究所の同僚の@kumagalliumさんは、材料工学の博士でもあるため、物理・化学や、材料設計に情報科学のデータ解析手法を活用するマテリアライズインフォマティクスの話題も登場する。その流れで、機械学習やオープンサイエンスといった話題も頻繁に登場する。@tsurubeeさんも材料工学の出身かつ機械学習もやられているので、これらの分野の話題に事欠かない。

このように話題も幅がずいぶん広くなった一方で、SREやインフラの狭い範囲を深堀りして話す機会は、社内では前職と比べてずいぶん減った。もともとやっていた分野は、外部の技術系コミュニティでつながりがあるので、コミュニティを活用してカバーしようとしている。

今のところ、この広範なインフラ技術を直接の研究対象とはしていない。将来的には、Webサービス以外のシステムを対象としたSREをやっていきたい。これまで@kikuzokikuzoさんが提唱されているような世界観と、2日前に書籍『Learn or Die 死ぬ気で学べ プリファードネットワークスの挑戦』 を読んだ影響もあって、端末として大量のパーソナルロボットやセンサがいて、ロボットの制御のための分散システムをエッジやクラウドを利用して構築するようなインフラに興味がでてきた。

自身の研究テーマ

研究所のビジョンである「超個体型データセンター」を踏まえて、データセンターが集中と分散のハイブリッド構造をとるときに、どのようなSRE技術や分散アプリケーションの構成技術が必要だろうか、という観点で研究を進めている。

詳細は SRE NEXT 2020 IN TOKYOにて話をした。SRE NEXT基調講演を終えて - ゆううきブログ

以下は、入社当初の研究やっていきの表明。

実績や月単位での活動などの詳細は、年始の振り返りに書いている。

2019年振り返り - エンジニアから研究者へ - ゆううきブログ

日々の活動

研究者としての日々の活動は、その他の職種からは想像しにくいかもしれない。

さくらインターネット研究所では、各メンバーが必須で共通のスケジュールをもつことは少なく、日々何をやるかは個人の裁量に任されている。Web企業でシステムの開発や運用をやっていたときは、チームで立てた計画に基づいたタスクと、日々発生する割り込みタスクをこなしていくというのが基本だったので、ずいぶん異なる仕事の進め方になっている。

まずは、僕個人の話を書く。

論文やテックカンファレンスなどの登壇の締め切りに合わせて、研究を進めるのを基本の仕事としている。情報系の国内の学術研究では、次のように、研究の完成度に応じて、発表の場が用意されている。

  1. 査読なし国内研究報告
  2. 査読つき国内研究報告(研究会によっては存在しないこともある)
  3. 国際会議(査読ありなし含む)
  4. 国内外の論文誌(ジャーナルとも呼ばれる)

すべてのステップを強制されるわけではなく、いきなり国際会議や論文誌に投稿してもよいが、発表を重ねてフィードバックをもらいながら、研究を育てていくほうが、最終的に良い研究になると思う。

年のはじめに、今年はこれとこれに投稿しようと決めて、いつまでに何をやるかを逆算する。アカデミアの国内研究会や国際会議は、毎年締め切りの時期が例年と同じになることが多いので、計画は立てやすい。

勤務場所については、最寄りのオフィスは大阪のグランフロントにあるのだけど、京都市に住んでいて遠いので、オフィスにはあまり行かずに、在宅勤務している日が多い。オフィスに行く頻度は2週間に1回程度。

次に、研究所全体の話を書く。

さくらインターネットのオフィス拠点は大阪、東京、福岡の3つあり、研究所メンバーは各拠点に分散している。研究所の拠点とかエリアはなく、強いて言えばインターネットが拠点となっている。

非同期コミュニケーションは、SlackとGitHub Enterpriseが中心だ。Slackには #research-center というチャンネルが日々そこで会話している。しょっちゅう会話しているということもなく、全く発言が流れない日もあったりする。共同研究先ともなんらかのSlackチャンネルでつながっている。GitHub Enterpriseには、イベント登壇・参加を中心として共有をするためのリポジトリ(issueだけ使っている)と、論文のLaTexコードを置いてレビューするためのリポジトリがある。共著者が外部の方の場合は、GitHubにプライベートリポジトリを作って、そこに招待していることもある。

同期コミュニケーションは、zoomを使った、週1回の定例会と、毎日の雑談会がある。定例会では、研究に進捗があればその内容を議論したり、学会などのイベントに参加したときの感想を共有したりする。アジェンダも司会もあえて置いてなくて、雰囲気で誰かが主導したり、話題を提供したりしている。議論と情報共有が主体で、チームで決めなければいけない事項がほとんどないため、これでうまくいっているのだと思う。

むすび

おかげさまで余白のある充実した毎日を過ごせている。

もちろんすべてが良いことばかりではなく、会社全体でみればこれまで経験したことがなかった様々な問題があると聞いている。研究所が事業部から独立していることもあり、幸いにして、それらの問題は、僕自身に短期的に影響がないものばかりではある。しかし、知らぬ存ぜぬを突き通すのではなく、前職のはてなでの経験や昨年1年の間のSREに関するアウトプットをもとに、社内でのDevOpsやSREの実践について、たまにアドバイスを行ったりしている。

最後に、今後の話をして締めくくる。

昨年は、調子に乗って、締め切りをたくさんいれてしまって、締め切りをつけづらいソフトウェア開発と、論文や書籍からのインプットが思うようには進まなかった。今年は締め切りとそれに必要な日数を見積もって、それ以外にやりたいこともうまく進められるようにしたい。すでに、ソフトウェア開発については、昔やっていた毎日最低1コミット進めるという習慣を復活させて取り組んでいる。

そして、昨日、社会人博士として、京都大学大学院情報学研究科の博士課程へ入学した。博士課程入学の経緯やプロセスは、別途ブログ記事にまとめたいと思う。そういうわけで、あと数年は、博士号を取得することを当面の目標としている。それが終わるぐらいに、クラウド上のWebシステム以外のシステムを相手にSREを実践するための研究をする準備ができていればよいかなあとなんとなく考えている。

あわせて読みたい。

さくらインターネットに入社して1年が経ちました - 人間とウェブの未来

*1:詳細は、所長の@ken_washikitaさんの資料を参照してほしい。さくらインターネット研究所のミッションとビジョン

SRE NEXT基調講演を終えて

1月25日に開催されたSRE NEXT 2020 IN TOKYOにて、「分散アプリケーションの信頼性観測技術に関する研究」と題して、基調講演をさせていただきました。 これまで一環してWebオペレーション・SREに取り組んできて、今ではSRE Researcherと名乗っている身からすると、国内初のSREのカンファレンスで基調講演にお声がけいただいたことは大変名誉なことだと思っています。

基調講演について

カンファレンスの基調講演は実ははじめての経験で、どのような発表をするかについては、いくらか逡巡することになりました。 SRE NEXTのオーガナイザーをされている@katsuhisa__さんからは、現在僕が取り組んでいる研究内容や、その研究背景として考えていることを講演してほしいという期待をいただきました。 同時に、カンファレンスのタイトルに含まれる「NEXT」には、参加者の皆様とSREの次の役割を一緒に考えたいという願いを込めていると伺いました。

まず、基調講演の「基調」には、「作品・行動・思想などの根底を一貫して流れる基本的な考え方。」(スーパー大辞林より)という意味があるようです。 SREの定義は未だはっきりとは定まっていないことから、自分が考えるSREのあり方を述べることが、SREの「基調」として適切であろうと考えました。 そのSREのあり方とは、昨年のブログポストでも述べた*1ように、失敗を許容するという前提にたって、信頼性を制御対象としてみなし、変更速度(Agility、開発速度、リリース速度、Productivityなど)を高めていくというものです。 そうして実現した高い変更速度により、信頼性を脅かすリスクのサイズを小さくしていき、結果的には失敗を許容していても、信頼性も高くなっていくはずです。

次に、工学の研究というものは、世の中の未解決の問題を設定して解くものであるため、研究の話をすれば「NEXT」にはなります。 ただし、SRE全体の「NEXT」を客観的に示すことは容易ではなく、一人の人間が主観的に話してしまうにはすこし傲慢に聴こえてしまうでしょう。 しかし、ひとつの論文にまとまる具体的な研究の話では、「NEXT」というにはスケール不足です。

そこで、自分の取り組んできた複数の各研究とさくらインターネット研究所のビジョンである超個体型データセンターを統合する形で、「NEXT」の一部を示すという形をとりました。 その形とは、クラウドコンピューティングのような集中型のコンピューティングの次の形として、利用者の近傍にコンピューティングが近づく形で地理的に分散した構造をとるエッジコンピューティングやフォグコンピューティングの存在があります。 このような地理的に分散したコンピューティング自体は、過去にも研究されてきており、広域のネットワーク上にある計算資源を連携させてひとつの大きな計算機システムとしてみなすグリッドコンピューティングや、コンピューティングを遍在させるユビキタスコンピューティングなどが代表的です。 しかし、昨今の技術の変遷を踏まえて、現在主流のクラウドコンピューティングそのものや、クラウドを前提としたCloudNative技術のソフトウェア資産を活かす形で、地理分散アプリケーションを構成することに関心が移ってきているように感じています*2。 このような地理分散環境でアプリケーションを構成し、運用することを想定したときの、SRE視点の問題にアプローチするというのが、現在僕がさくらインターネット研究所で取り組んでいることになります。

最後には、より大きなNEXTの流れを示すために、このような地理分散環境に関わるクラウド以外のコンピューティング領域への拡張、人と組織に関わる経営学、人と機械に関わる認知システム工学などの分野との関わりを提示しました。 組織については、マイクロサービスやCloudNative技術の目的が組織パフォーマンスの向上であると言われるようになってきている流れから、ここ数年で無視できない要素になっています。 そこで、IT技術の学問であるコンピュータサイエンスを学ぶように、組織の学問である経営学を学び、それを活かした実践が必要となってくるのではないかと思います。 また、クラウド技術の発展により、すでにソフトウェアによる自動化は前提となっており、それによってシステムが複雑化したとしても、人間の認知負荷をうまく抑え込むための手法が今後は必要となってくると考えています。

f:id:y_uuki:20200127155657p:plain

基調講演かつ当日のトップバッターでもあったので、全参加者にとって、発表内容のすべてではないにしろ一部でも持ち帰るものがあること、後続のセッションに話をつなげることの2点を意識して、内容を構成しました。 発表後には、発表内容のいずれかのトピック(信頼性制御、地理分散全般、個別の研究内容、組織、人間中心の自動化など)に対して、別々の参加者の方々からまんべんなく言及いただいたことから、目論見はうまくいったと自己満足しています。 全参加者に向けて、個別の具体的な研究内容を、5分程度の短い時間で伝えるということが今回のチャレンジでしたが、そこはわからなかったという声もあり、課題が残りました。 とはいえ、一部のうまく前提を汲んでいただいた方々には、議論可能な状態まではもっていけたので多少の手応えはありました。

以下は講演のスライド資料へのリンクです。

内容に興味をもっていただいたのであれば、今回の講演のベースになった過去の僕の成果物が参考になるでしょう。

  1. 2019年SRE考 - ゆううきブログ
  2. SRE実践の手引 ─ 信頼性をどう制御するか? から始める、現実的な指標と目標の設計と計測 - エンジニアHub|若手Webエンジニアのキャリアを考える!
  3. SREの組織的実践 / Organized SRE - Speaker Deck
  4. Yuuki Tsubouchi, Asato Wakisaka, Ken Hamada, Masayuki Matsuki, Hiroshi Abe, Ryosuke Matsumoto, "HeteroTSDB: An Extensible Time Series Database for Automatically Tiering on Heterogeneous Key-Value Stores", Proceedings of The 43rd Annual IEEE International Computers, Software & Applications Conference (COMPSAC), pp. 264-269, July 2019. [paper] [slide]
  5. 坪内佑樹, 古川雅大, 松本亮介, "Transtracer: 分散システムにおけるTCP/UDP通信の終端点の監視によるプロセス間依存関係の自動追跡", インターネットと運用技術シンポジウム論文集, 2019, 64-71 (2019-11-28), 2019年12月. [論文] [発表資料]
    1. 坪内佑樹, 松本亮介, "超個体型データセンターにおける分散協調クエリキャッシュ構想", 情報処理学会研究報告インターネットと運用技術(IOT), No.2019-IOT-45, Vol.14, pp.1-7, 2019年5月. [論文] [発表資料]

セッションについて

最近は、アカデミアの学会参加や家に引きこもって研究する時間が支配的なので、テックカンファレンスに来たら人と話すように心がけていて、一部のセッションしか直接は聴けていません。 しかし、公開資料やTwitterの反応を眺めていると、組織的アプローチによる問題解決の話がずいぶんと増えてきていたように、SREの実践がすでに開始段階ではなく洗練段階にはいっているように感じました。

SRE Practices in Mercari Microservices / @deeeet

deeeeeeetくんの発表はひさびさに生で観た気がします。 SLI・SLOを決めても、タスク優先度などの意思決定に使わなければ意味はなく、そのためにスクラムを利用しているという考え方は、まさに僕も2年前に始めたことがあったので我が意を得たりという気持ちになりました。 あとは、SLI・SLOをリクエストベースのシステムへ適用する事例が多い中、リリースパイプラインシステム自体にSLI・SLOを設定するという事例は新鮮でした。 全体的に、グローバルで議論されている内容が発表のベースになっていて、deeeeetくんの普段のインプットの質の高さが伺えました。

基調講演 Webサービスを1日10回デプロイするための取り組み / @fujiwara

リバートを含むデプロイ処理自体の高速化、エラー検知の高速化、デプロイ時間と内容の記録など、リスクが顕在化したときにどれだけすぐに回復できるかという観点でどれも重要な実践であると感じました。 fujiwaraさんの取り組みやOSSはずっとウォッチしてきているのですが、取り組まれていることを学術的に整理するとおもしろい論文になりそうだなと今回の発表を聴いて改めて思いました。

fujiwaraさんから現場の話をしていただけそうだったので、運用の現場を離れた僕は安心してフィロソフィカルな議論と研究開発の話に専念できました。

むすび

SRE NEXTの運営スタッフの皆様、すばらしいイベントをありがとうございました。 SREどころか、Webオペレーション、インフラの分野のカンファレンスは昔から国内ではほとんどありませんでした。 このようなカンファレンスを日本で開催されるということが、国内でのSREの発展に大きく寄与するものだと信じています。

2019年振り返り - エンジニアから研究者へ

例年のように、昨年の活動を振り返る。

昨年は、それ以前の5年と異なり、働き方もエンジニアから研究者へ転向したことにより、自分を取り巻く環境は大きく変化した。 とはいえ、1年の研究活動を通じて、エンジニア時代と比較し、働き方は変わっても、自分が目指すものはあまり変わらないことも再確認した。

エンジニアであっても、研究者であっても、SREの分野において、相変わらず特定の環境に依存しない汎用的かつオリジナルの貢献を目指している。 エンジニアか研究者かというのは、自分にとっては、単に時間の使い方の差に過ぎない。 エンジニア時代は、企業の商用システムの開発・運用経験を通して、余暇時間でブログに知見をまとめたり、ソフトウェア化したりしていたが、研究者になってからは現場経験のウェイトをほぼゼロにして、学術論文の形で深く知見をまとめて、ソフトウェア化を進めている。

1月

昨年の12月に前職を退職したのち、1月いっぱいは無職期間だったこともあり、疲れをとるためにのんびりと過ごしていた。 睡眠サイクルが自由運動を始めて、深夜3時くらいに深夜食堂的なところで飲んでいた日もあった。

怠惰の限りをつくしていると思いきや、意外と活動していて、IEEE COMPSAC2019に向けて国際会議論文を書いていたり、次世代WebカンファレンスでSREをテーマとしたパネルディスカッションに登壇したり、福岡に遊びにいったときに体調を崩されたまつもとりーさんの代理で急遽発表したりした*1

次世代Webカンファレンスの流れから、SREとはつまり、「信頼性の制御」であると言語化できたので、ブログにまとめておいた。

2019年SRE考 - ゆううきブログ

2月

無職期間はあっという間に終わり、さくらインターネットに入社した。 所属はさくらインターネット研究所になる。 2月は特に締め切りもなかったので、これまでを振り返りつつ、研究方針を考えたり、 研究所のビジョンである超個体型データセンターを踏まえて、研究テーマを練ったり、超個体型データセンターのいち要素であるエッジコンピューティングについて調査していたりした。

ゆううきの研究開発まとめ (2019年2月版) / The summary of yuuki's research and development in 02/2019 - Speaker Deck

3月

徳島で開催されたIOT44と福岡で開催された情報処理学会 第81回全国大会に参加していた。

Hosting Casual #5で新しい研究の構想を紹介したり、機械学習のイベントでSREに機械学習を適用する研究のサーベイ結果を話していたりした。 機械学習そのものはそれ以降特に何もしていないけど、研究所の機械学習が得意なメンバーと話をするネタとして多少役に立った。

超個体的DBクエリキャッシング構想 - Speaker Deck

SREへの機械学習適用に関するサーベイ / A Survey for Cases of Applying Machine Learning to SRE - Speaker Deck

4月

IOT45の研究会論文を執筆したり、自分が主催しているウェブシステムアーキテクチャ研究会で発表したりしていた。

エッジコンピューティングに向けた分散キャッシュ技術の調査 / edge caching survey - Speaker Deck

大学院博士課程進学を想定して、京大の研究室に訪問したりしていたのもこの頃だった。

わたしの研究開発紹介 - 技術者から研究者へ - / Introduction to my research - Speaker Deck

石狩のデータセンターに出張する予定があったが、体調を崩してしまって行けなかった。

5月

GW明けに、SanSanさんの京都のオフィスで開催されたSREとエンジニアリング組織の会に声をかけていただいた。 これを機会に、これまであまり公開していなかった、2018年にSREと組織に関わる仕事をやっていたときに実践したことをまとめた。

SREの組織的実践 / Organized SRE - Speaker Deck

そのあと、DICOMO2019の研究会論文の執筆も進めていた。

月末には、大阪大学で開催されたIOT45でQuorumCacheネタで研究発表した。 阪大を中退して以来、はじめてキャンパスに足を踏み入れ、当時在籍していた研究室があった場所を苦々しい気持ちで眺めた。

6月

6月は特に締め切りがなくて、はじめてさくらの東京支社オフィスに行ったりしていた。

https://github.com/yuuki/transtracerの実装を進めていたのもこのころ。

7月

福島で開催されたDICOMO2019でTranstracerネタを発表してきた。 知らないうちに博士号を取得していて、研究室の助教となっていた高校時代の同級生と卒業以来はじめて会って話をした。

超個体型データセンターを目指したネットワークサービス間依存関係の自動追跡の構想 / A concept of superorganism tracing - Speaker Deck

IEEE COMPSAC 2019ではじめて国際会議で発表してきた。研究ネタは2018年に国内で発表したHeteroTSDB。

はじめて国際会議で論文発表して考えたこと - ゆううきブログ

8月

セキュリティ・キャンプ全国大会で「クラウド時代における大規模分散Webシステムの信頼性制御」という題目で講義をしてきた。 セキュリティ・キャンプの存在は、学生時代に聞き及んでいたものの、自分とは縁のない遠い世界の話だと思っていたのが、それから7年以上経って、講師の立場で参加することになるとは思わなかった。 自分がこれまで経験を積み上げてきたWebシステムアーキテクチャの基礎、Webシステムのスケーリングの基礎とケーススタディの話を4時間講義で218ページの大作スライド*2としてまとめた。 受講生の方々からは、内容はヘビーだったけど、おもしろかったと感想をいただいた。

Kyoto.なんかでエンジニア向けにTranstracerネタの話をした。

分散システム内の関係性に着目したObservabilityツール / Observability tool focused on relationship in distributed systems - Speaker Deck

9月

前月の中頃からIOTS2019の査読付き論文を執筆していた。

島根で開催されたAPNOMS 2019というネットワーク分野の国際会議に参加した。 APNOMS2019でよく出てきた話題は、5G、エッジ/フォグコンピューティング、SDN、MLによるトラフィック制御、ブロックチェーンのようなものだった。 それぞれが独立した話題というよりは、組み合わせる話もあり、エッジでSDNやるとか、エッジ側でオンライン学習するみたいな話もあった。

10月

前職から声をかけていただいたエンジニアHubのSRE記事を書いていた。 1月に書いたSRE考の発展版という位置づけで、いかにはやく信頼性の制御ループに入り込むかという話をまとめた。

SRE実践の手引 ─ 信頼性をどう制御するか? から始める、現実的な指標と目標の設計と計測 - エンジニアHub|若手Webエンジニアのキャリアを考える!

HeteroTSDBネタを完成させるために、情報処理学会の論文誌論文への投稿を準備もしていた。

11月

さくらの東京支社で研究所の@amsy810さんに2日がかりで研究所メンバー向けにKubernetesの講義をやっていただいた。 月末のCloud Native Days KANSAI 2019に向けてKubernetes熱が高まった。 ついでに、東京の汚染された大気では呼吸ができないとかいいながら、SRE仲間と会ったり、前職の同僚と合ったりしていた。

Cloud Native Days KANSAIは、登壇者の数が東京よりは少なく、それがかえって、登壇者同士で話をしやすくてよかった。 ここ1年は家でこもって研究をしているか、アカデミア系のコミュニティに顔をだすことのほうが多かったので、その分もあってかエンジニア同士で話をすることが楽しく感じられた。 従来インフラ系と呼んでいた分野のネタは、昔はYAPCなどのプログラミング言語系のカンファレンスに応募するしかなかったのが、最近は、Cloud Native DaysやSRE NEXTのようなカンファレンスが開催されるようになってきて、ありがたい状況になってきた。

分散システム内のプロセス間の関係性に着目したObservabilityツールの設計と実装 / Transtracer CNDK2019 - Speaker Deck

12月

15年ぶりに訪れる沖縄で開催されたIOTS2019でTranstracerネタを発表した。 データベース系よりもテーマの性質が研究会のテーマにマッチしたせいもあってか、前年のHeteroTSDBネタよりも質疑応答で盛り上がった。 幸いにも、最も優れている論文に与えられる優秀論文賞と、有用性を評価されて企業冠賞であるシー・オー・コンヴ賞をいただくことができ、早くも学術方面で実績をだすことに成功した。

その後は、年末まで博士課程進学の準備を粛々と進めていた。

むすび

知人に今の仕事はどう?と尋ねられたときに、冗談半分で「実質アーリーリタイア状態。締め切りが常に2,3個あるのを除けばね」という話をするようになったのが、今年の様子を端的に表している。 さくらインターネット研究所では、論文や発表の回数にノルマがあるわけではないので、締め切りの個数や日程は自分で制御可能になっている。 学術主体の研究会と実用主体のカンファレンスの両方にでていることもあって、ピンポイントで慌ただしいと感じることもあったが、休み休み無理なく継続して研究を進められた。

昨年から対外的に成果を公開することそのものが仕事になったので、当然ながらアウトプットの数と質は過去最高となった。 昨年の目標だった査読付き国際会議への採録と受賞を達成できたので首尾は上々といったところ。

今年以降は、所長の薦めもあって、自身の顔がみえるようなアーキテクチャを設計したり、ソフトウェアを開発したりするためのスキルを獲得することを目的に、情報学博士の学位取得を目標とすることに決めた。 現在、博士後期課程へ進む準備を進めており、無事審査に合格すれば、来年の4月から6年ぶりに学生となる。

また、昨年は論文執筆と発表に集中していたために、ソフトウェア開発がすこしおざなりになってしまった。 今年は、知人の現場環境に導入してもらうなどして、ソフトウェアとしての価値を高めていきたい。

2019年の研究成果リスト

受賞

  1. 情報処理学会インターネットと運用技術シンポジウム2019(IOTS2019)優秀論文賞 坪内佑樹, 古川雅大, 松本亮介, "Transtracer: 分散システムにおけるTCP/UDP通信の終端点の監視によるプロセス間依存関係の自動追跡", インターネットと運用技術シンポジウム論文集, 2019, 64-71 (2019-11-28), 2019年12月.
  2. 情報処理学会インターネットと運用技術シンポジウム2019(IOTS2019)冠賞: シー・オー・コンヴ賞 坪内佑樹, 古川雅大, 松本亮介, "Transtracer: 分散システムにおけるTCP/UDP通信の終端点の監視によるプロセス間依存関係の自動追跡", インターネットと運用技術シンポジウム論文集, 2019, 64-71 (2019-11-28), 2019年12月.

国際会議録(査読付き)

  1. Yuuki Tsubouchi, Asato Wakisaka, Ken Hamada, Masayuki Matsuki, Hiroshi Abe, Ryosuke Matsumoto, "HeteroTSDB: An Extensible Time Series Database for Automatically Tiering on Heterogeneous Key-Value Stores", Proceedings of The 43rd Annual IEEE International Computers, Software & Applications Conference (COMPSAC), pp. 264-269, July 2019. [paper] [slide]

国内会議録(査読付き)

  1. 坪内佑樹, 古川雅大, 松本亮介, "Transtracer: 分散システムにおけるTCP/UDP通信の終端点の監視によるプロセス間依存関係の自動追跡", インターネットと運用技術シンポジウム論文集, 2019, 64-71 (2019-11-28), 2019年12月. [論文] [発表資料]

国内会議録(査読なし)

  1. 坪内佑樹, 古川雅大, 松本亮介, "超個体型データセンターを目指したネットワークサービス間依存関係の自動追跡の構想", マルチメディア、分散、協調とモバイル(DICOMO2019)シンポジウム, 6A-2, pp. 1169-1174, Jul 2019. [論文][発表資料]
  2. 坪内佑樹, 松本亮介, "超個体型データセンターにおける分散協調クエリキャッシュ構想", 情報処理学会研究報告インターネットと運用技術(IOT), No.2019-IOT-45, Vol.14, pp.1-7, 2019年5月. [論文] [発表資料]
  3. 松本亮介, 坪内佑樹, 宮下剛輔, "分散型データセンターOSを目指したリアクティブ性を持つコンテナ実行基盤技術", 情報処理学会研究報告インターネットと運用技術(IOT), No.2019-IOT-45, Vol.12, pp.1-8, 2019年3月.

国内講演・講義

  1. 坪内佑樹, (基調講演) 分散アプリケーションの信頼性観測技術に関する研究, SRE NEXT 2020 IN TOKYO, 2020年1月25日 (to appear)
  2. 坪内佑樹, 分散システム内のプロセス間の関係性に着目したObservabilityツール, CloudNative Days Kansai 2019, 2019年11月28日
  3. 坪内佑樹, (講義) クラウド時代における大規模分散Webシステムの信頼性制御, セキュリティ・キャンプ全国大会2019, 2019年08月14日

国内口頭発表

  1. 坪内佑樹, Webシステムアーキテクチャの地図を描く構想, 第5回WebSystemArchitecture研究会, 2019年9月29日.
  2. 坪内佑樹, 分散システム内の関係性に着目したObservabilityツール, Kyoto.なんか #5, 2019年8月24日.
  3. 坪内佑樹, SREの組織的実践, エンジニリング組織の作り方 -マネジメントとSREの観点から考える-, 2019年5月9日
  4. 坪内佑樹, エッジコンピューティングに向けた分散キャッシュ技術の調査, 第4回ウェブシステムアーキテクチャ(WSA)研究会, 2019年4月13日
  5. 坪内佑樹, わたしの研究開発紹介 - 技術者から研究者へ -, 2019年4月10日
  6. 坪内佑樹, SREへの機械学習適用に関するサーベイ, MACHINE LEARNING Meetup KANSAI #4 LT, 2019年3月27日
  7. 坪内佑樹, 超個体的DBクエリキャッシング構想, Hosting Casual Talks #5, 2019年3月22日
  8. 坪内佑樹, ゆううきの研究開発まとめ (2019年2月版), さくらインターネット研究所 研究会 2019.02.13, 2019年2月13日
  9. 松本亮介(代理発表), アプリケーション実行環境におけるセキュリティの話, 福岡ゆるっとIT交流会 vol.9「セキュリティの話を聞こう」, 2019年1月25日

パネルディスカッション

  1. 坪内佑樹, SRE(#nwc_sre), 次世代Webカンファレンス 2019, 2019年01月13日 [動画]

学会誌・商業誌等解説

  1. 坪内佑樹, SRE実践の手引 ─ 信頼性をどう制御するか? から始める、現実的な指標と目標の設計と計測, エンジニアHub, 2019年12月4日
  2. 松本亮介, 坪内佑樹, 宮下剛輔, 青山真也, 研究員たちが考える、さくらインターネット研究所「これから」の10年, ASCII.jp, 2019年10月29日

*1:入社後に出張扱いにしていただいたので、交通費と宿泊費を経費で落とせてラッキーだった。

*2:講師がスライドの著作権をもつため公開しても問題ないものの、考えがあって非公開としている。みせてほしいという人にだけ渡している

はじめて国際会議で論文発表して考えたこと

先日、アメリカのウィスコンシン州ミルウォーキーで開催された国際会議 IEEE COMPSAC 2019で時系列データベースHeteroTSDBの論文を発表してきました。

f:id:y_uuki:20190729171845p:plain

IEEE COMPSACは、IEEE内のコンピュータソフトウェア分野の分科会IEEE Computer Societyのフラグシップカンファレンスとして開催されている国際会議です。 COMPSACが対象とする分野は、ソフトウェア、ネットワーク、セキュリティ、アプリケーションなど非常に幅広く、様々なテーマの発表がありました。 COMPSACは、メインシンポジウムと併設のワークショップにより構成されており、メインシンポジウムのregular paperの採択数は63本(24.5%)、short paperの採択数は50本となっています。 投稿時にregularとshortの区別はなく、今回の我々の論文は、メインシンポジウムのshort paperとして採択されました。 一般にアカデミアの国際会議にはランク付けがあり、COREのカンファレンスランキングによると、COMPSACはA*(4%)、A(14%)に次ぐB(26%)ランクとなっています。いわゆるトップカンファレンスとは呼ばないかもしれませんが、実績として十分に認められる会議であるというように自分は認識しています。

予稿

スライド

発表内容

投稿した論文の内容自体は、昨年に国内の学会で発表したものとほぼ同じ内容になります 時系列データベースの論文を書いた - ゆううきブログ。 日本語論文の時点でページ数は8で、そのまま英語化すると8ページ弱となり、最終的にはページ数6のshort paperに収める必要があるため、もともと日本語論文にあった冗長な記述を削減しました。 その結果、元の論文と比べて、すっきりした形になったかなと思います。

投稿論文の査読の中で、実環境の運用を基にした議論となっており、読者にとって有益であるというようなコメントをいただきました。 まさに実運用から出発している研究であるため、我が意を得たりというコメントでした。 その一方で、新規性や他手法と比較した有用性の記述が弱いとの指摘もありました。 もともとこの研究は、プロダクト開発から始まっているため、どうしても新規性を強く打ち出すことは難しくなります。 また、定量的な性能を追求する研究ではなく、拡張性や互換性といった定性的な観点にフォーカスした研究であるため、定量的な評価が難しく、他の手法と比べて有用であることを実験で示すことが難しいという性質があります。 このあたりは、難しいながらも記述を工夫し、研究のまとめとしてジャーナルへ投稿する予定です。

さて、会議での口頭発表ですが、昨年の国内の発表では、論文に記述した内容を全部含めようとした結果、分量が大きくなってしまい、要点を絞れていなかったという反省がありました。 そこで、今回は序盤のIntoroductionを時系列データベースが利用される背景 => 既存のチャレンジ(性能要求) => 新しいチャレンジ(拡張性) => 新旧チャレンジの内容を満たすアーキテクチャの概要といった流れで、4ページでコンパクトに研究をまとめるように工夫してみました。 さらに、提案手法の詳細の記述が、もともとの日本語のスライドではテキスト主体になっていたため、なるべく図で表現するように改善しました。 英語のスキルは残念ながらいきなり上がったりしないので、特定の言語に依存しない工夫により、英語スキルの不足を補うように努めました。 むしろ日本語の発表だとその場のアドリブで、なんとなくごまかしてしまえることも、英語だとそうはいかないため、スキルの低い英語で発表することで、結果的に論旨を明瞭にするスキルを鍛えるきっかけになることに気づきました。

f:id:y_uuki:20190729171443p:plain
発表の様子

当日の発表では、国内の研究会で見知っている方も多いこともあって、日本の学会とさほど緊張感は変わらず臨むことができました。 発表後に(英語の)発音がうまいと言っていただいたのはうれしく思いました。 そもそも自分は、普段の日本語の発表でさえ、抑揚がないと言われがちなので、強く抑揚が求められる英語では、めちゃくちゃ平坦に聞こえてしまうだろうなと危惧していました。 そこで、事前の発表練習で自分の声を録音して、USENIX FASTやLisaの発表音声と比較しつつ、抑揚がでていない部分を発見し、強引に抑揚をつける練習をしていたりしていました。 加えて、"database"、"datapoints"、"architecture"などの自分の発表で頻出する しかし、マイクにうまく声が乗っていたなかったようで、普段手に持っていたマイクをなぜか当日はマイクスタンドに置きっぱなしにしていたのは失敗でした。 質疑応答では、たどたどしくも質問にはしっかり答えられたかなと思います。 とはいっても、いずれも日本人の先生方からの質問であったため、質問文が聞き取りやすかっただけとも言えます。

会議の様子

開催地のマーケット大学は緑のあるゆったりとした美しいキャンパスでした。 学会会場には、コーヒーやクッキーが常備され、昼食時間にはランチボックスが積まれ、棟内で自由に食べることができました。 情報処理学会がCOMPSACのスポンサーとなっている関係で、日本の研究者の方々が数多く参加されているのも印象的でした。

f:id:y_uuki:20190729171512p:plain
マーケット大学の様子

学会の対象分野自体が広いため、リサーチセッションは自分の関心領域の内容を楽しむというよりは、普段関わりのない分野の発表を聴いて見識を広めたり、英語での発表スタイルや質疑応答での言い回しを学んだりする場として活用できました。 ずっと発表を聴いているとそれはそれで疲れるので、バルコニーのベンチに座って、発表の感想について談笑していたりしました。

キーノートや特別セッションは、Wireless AIという新しい研究分野の創出、A Smart World(COMPSAC 2019のテーマ)に向けてテクノロジーが何をもたらすか、表彰された3名のトップ研究者のパネルディスカッション、IEEE Computer Societyの歴代の会長によるパネルディスカッションといった内容でした。 いずれの内容も興味深く、テクニカルな内容を楽しむというよりは、研究のあり方を考えたり、他の分野とのコラボレーションを楽しむといったもので、いずれもそこでしか聴けないであろう内容でした。 普段ならはいはいっと聞き流しそうな内容でも、こういった場に来るとちゃんと聴こうとするので現金ですね。

会議期間中にずっと考えていたのは、"Is a Smarter World a Better World? Key Questions at the Intersection of Technology, Intelligence, and Ethics"というタイトルのキーノートの中で提起されていた、我々はテクノロジーにより自分たち自身を"enhance make-decision's capacity"*1できているかという問いについてでした。 日本語では、人間の意思決定能力を高めるという意味になりますが、例えば、AIの活用により、自分の過去の情報をもとに推薦される情報のみを拠り所にすると偏りが生じて、かえって人間の意思決定能力を低下させてしまうこともあり得るが、本当にそれでいいのかという問いを投げかけるような内容だったと思います。

抽象度の高い問いなのでそのまま考えてもなかなか思考はまとまらないので、僕が専門とするSREの分野に置き換えて考えました。 例えば、今業界で起きている大きな流れは、一部のメガクラウド事業者がマネージドサービスを提供することで、短期的には利用者の仕事を削減して、利用者は空いた時間で他のことをできるようにするというものです。 しかし、この流れの先にあるものは、中央集権による技術の寡占構造とみることもできます。 提供されているマネージドサービスがあまりにも便利なために、マネージドサービスを組み合わせてできることの範囲内でしか物事を徐々に考えなくなってしまい、結果としてコンピューティングとネットワークの技術が世の中全体としては失われていく可能性もあります。 そうすると、長期的には、却って技術が発展しなくなるという仮説も考えることができます。

別のキーノートセッションでも健康状態などの個人のプライバシーの情報をクラウドに格納しておくことや医者が情報を専有していることの是非を考える話がありました。そして,これらの問題を解決するのは,個人の情報はその個人が所有するということではないかとも。 このように複数の分野で、一時的な効率のために、長期的に犠牲にしているものがあるというパターンをみてとることができます。 そして、そのパターンの中にある共通の構造として、一時的な効率のための中央集権構造と、それに対抗する分散構造のトレードオフを帰納的に見出すことができます。 ここまで考えて、さくらインターネット研究所のビジョンである超個体型データセンターを連想しました。というのは、超個体型データセンターは、中央集権構造に対するインターネットの技術階層でのアンチテーゼになっているためです。 超個体型データセンターを突き詰めて考えていくと、プライバシー、倫理、哲学などの観点からも興味深いものとして捉えることができるかもしれません。

あとがき

エンジニアでもある僕が国際会議で発表して思ったこと - 人間とウェブの未来

今では同僚であるid:matsumoto_rさんが昨年のCOMPSACで発表されたことは、当時はもちろん知っていましたが、その翌年に自分が発表することになるとは思いもしませんでした。とはいうものの、イメージしていないことは実現しないともいうので、覚えていないだけでイメージはしていたのかもしれません。2年前のIPSJ-ONEで発表したときのことを思い出しました。

セッションプログラムをみるとちょうどHeteroTSDBとFastContainerの発表が並んでいて、感慨深いものがあります。 さくらインターネットの名前で2人続けて発表したので参加者の印象にも残ったのではないかと思います。

f:id:y_uuki:20190729171636p:plain:w400

大学院の学生だったころは、国際会議で発表することはなかったどころか中退してしまったため、国際会議への発表は初めてで、単に参加すること自体も初めてでした。 そもそも海外へ赴くのは、高校時代のホームステイ研修みたいな旅行以来だったこともあり、発表よりも現地に無事に到着して滞在できるかどうかのほうが気がかりなぐらいでした。 英語学習そのもののモチベーションが低く、TOEICのリスニングの点数で平均以下しかとったことがない自分でも国際会議で英語で発表できたことは、グローバルでのアウトプットへの心理的ハードルを下げてくれました。 また、さくらインターネット研究所では、出張費用を全額サポートされるのはもちろんのこと、少なくとも研究員自身が行う手続きには面倒なことがないので、参加のためのハードルを下げてもらっています。 どちらかというと、家からあまり動きたくなくてのんびりしたい自分であっても、こうやって活動の幅が広がることは純粋に楽しいものです。

*1:decision-making capacityだったかもしれない

2019年の展望

どうでもいいけど、今日から真の無職になった。年末は珍しく、毎日おいしい日本酒を飲んだり、バーに行ったり、新幹線に置き忘れたiPhoneを買い換えたり、10年ぶりのLinuxデスクトップ環境構築をしていたり、友人・知人とゆっくり話をしていた。連絡をもらえてうれしかったと言ってもらったことはうれしかった。最終出社日を過ぎたあとに、まだ秋冬ものの靴や服を、何か足りないと感づきはしつつも、一部だしていなかったことに気づいたりして、心にゆとりがなかったことに思いあたった。計算機からのアラートを受けることもなく、日々の喧騒から離れ、徐々に自分を取り戻すような感覚がある。今年は、自分を見失わずに、やりたいことを楽しんでやる、ということに注力したい。

 

昨年の大きな転機はやはりはてなを退職したことだ。1年前は退職するとは思ってもみなかったけど、1年前の自分に今を見せても、驚いたあとにああやはりそうなったかと感じると思う。同僚の方々からみても、やはりというような反応をいただくことも多く、客観的にみても納得感があるというのはおもしろい。はてなには強い帰属意識をもって、会社の名を背負う気持ちで自主的に活動していたし、それだけの魅力のある会社だったと思う。もう少し未練が残るかと思ったけど、今のところそうでもなく、良い意味で状態をリセットした気持ちになっている。これまでオープンに表現してきたものが自分を支えてくれているのだと思う。

 

もう一つの大きな出来事は、査読付き論文を投稿できたことで、これがあったために、次は研究開発を専門にやっていくという決意ができた。さすがに、休みの日だけで書くのはそれなりに大変で、1、2回書くだけなら一時的な気力でなんとかなっても、毎年継続的にやろうと思うと、仕事にしていかないといけないなと思った。

 

さて、今年何をやっていくか。

 

まずは、ずっと放置していた生活基盤を見直して、快適に暮らしやすい環境を作りたい。お金のないときになんとなくで買った家具を、今の自分がよいと思えるものに買い換えたりして落ち着きを取り戻したい。

 

次に、研究というものを志すことになるため、研究や科学というものについて深く考えていきたい。そのために、とりあえず、中谷宇吉郎著「科学の方法」を読みながら、情報システムのアーキテクチャとの対応を考えたりしている。こういうことをしていると、漠然と科学に興味があった中学生や高校生だったころを思い出す。

 

最後に、さくらインターネット研究所では、まだなにをテーマとするかを決めていないけど、これまでと変わらずウェブやインターネット基盤技術をやっていくことになる。感覚的には、2017年にアカデミアの場で登壇したときにもった熱量を思い出して、ソフトウェアとして実装していきたい。ちょうど先月まつもとりーさんが書かれた以下の記事から、10年先のインターネット基盤の展望が書かれ、それに必要な技術をつくっていくイメージができた。ウェブのコンテンツ事業者の範疇ではできない基盤技術に取り組めそうなので、ひさびさにワクワクしている。これまでの得意だったウェブサービスアーキテクチャ、モニタリング、データベース、コンテナ仮想化技術、GPGPU、ネットワークスタックなど全部応用できるし、諦めていたOSに近いレベルのシステムソフトウェアを開発していくこともできるだろうし、何より技術階層の意味でのインターネットの会社なので、ネットワーク技術を学ぶこともできそう。

 

 

そして、なんといっても、まつもとりーさんと一緒に働けることをとても楽しみにしている。また、師匠がやってきたことを模倣することに加え、師匠が目指すところを目指すことを意識していきたい。これは大学生のころからよく読んでいて、今も折にふれて読んでいる漫画に書かれている言葉になる。今読むと、バーの原点は茶室にあるとして、エピソードの端々から東洋哲学を想起させるところが、自分を落ち着いた気持ちにさせてくれることに気づいた。

 

“師を求めず 師の求めたるところを求めよ”(長友 健篩、城 アラキ著「バーテンダー 」21巻。元の言葉は、松尾芭蕉の ”古人の跡を求めず 古人の求めたるところを求めよ”)

 

今年もよろしくお願いします。

 

登壇

 

第2回WebSystemArchitecture研究会

 

 

第3回WebSystemArchitecture研究会

 

第11回インターネットと運用技術シンポジウム

 

ブログ

 

そのほかメモブログにいくつか。


過去の振り返り

 

株式会社はてなを退職しました

2018年12月21日の今日がはてなでの最終出社日となりました。 はてなには、2013年12月に新卒として入社し、その後5年間に渡りお世話になりました。

はてなとの出会いのきっかけは、2011年のはてなインターンに参加したことでした。 はてなインターンの特徴の一つに、ほとんどの参加者が参加したときの内容をブログ記事として書いていることがあります。インターン参加記事には、技術やWebに対する大きな熱量がこもっており、すっかり自分もWeb技術をやっていくのだと感化されました。 ダメ元で選考に望んだところ、運良く選考通過のお知らせをいただいてとてもうれしかったことを今もよく覚えています。 そこから毎年インターンの参加者をみてきていますが、とてもハイレベルで、よく自分が選考通過したものだと今でも思います。 この出来事が自身の人生にとって大きな転機だったと言えるでしょう。

インターンの1年後にアルバイトスタッフとして入社し、配属されたのは、はてなのITインフラを担当するシステムプラットフォーム部という部署でした。 今でこそ当たり前のようにSREのような基盤技術を専門としていますが、当時はサービス開発をするアプリケーションエンジニアを志望していました。 しかし、システムプラットフォーム部での仕事を通して、サーバがたくさんあってそれらが相互に通信してひとつの系をなすというWebシステムに魅せられ、研究もたまたまTCP/IPスタックとGPGPUに関するテーマを提案してやっていたこともあり、今でいうところのSREを志しました。はてなで大規模サービスのインフラを学んだ - ゆううきブログ の記事にて、志した結果、何を学んだかを書いています。 そこから新卒で内定をいただいたにも関わらず、大学院を中途退学してしまいましたが、その後も快く受け入れてくださったはてなにはとても感謝しています。

はてなでは、Webシステムの基盤という軸はかえずに、様々な仕事をさせていただきました。 サーバ監視サービスMackerelのリリースから、その後の運用、はてなブログ、はてなプラットフォーム系サービスの運用、仮想化基盤などの基盤システムの運用、レガシーOSの移行、データセンター移行、時系列データベースの開発、プロジェクトマネジメント、チームマネジメント、シニアエンジニアとしてのメンタリング、採用、技術広報などをやってきました。 このような直接の業務以外に、オープンにアウトプットをするということに力を注いできました。 ブログ、登壇、OSS、最後は論文というように複数の媒体で、エンジニアリングからアカデミアまで様々な場で、技術を自分なりに表現するということをやってきました。*1 大した特技のない自分が曲がりなりにもエンジニアとしてやれているのは、オープンネスの風土が根付いていたはてなにいられたこと、その風土に大きく影響を受け、はてなのエンジニアらしくあろうと実践してきたおかげであると思っています。 また、オープンにいろいろやっていると、副次的に社内のエンジニア職種以外の方からも覚えていただいたり、PR記事にて対談させていただいたり、様々な方々と関われたことをうれしく思います。

調子よく仕事をさせていただいていたおかげで、どんどん等級もあがり、給料もあがっていきました。 その一方で、入社前に思い描いていた仕事と実際の仕事の内容には乖離があり、入社後の5年間はこの乖離を埋めるために奔走してきました。 入社時期の2013年といえば、クラウドやdevopsといった新しい技術や考え方が浸透し、それまで他の人が作ったソフトウェアを動かすまでが主な仕事だったインフラエンジニアが自分でソフトウェアを書いていくぞという時代になってきたころだと思います。 そのような世の中の影響を受けているのか、入社面接で自分が用意したプレゼン資料を今みると、基盤のためのソフトウェア開発をやっていきたいという思いが垣間見えました。 しかし実際には、なかなかソフトウェアを書いて貢献していくという時間を業務内でつくることが難しく「スタートラインに立てていない」という思いが募っていきました。

そこで、状況を変えるために、業務として期待される以外に自主的に様々なことをやってきました。 入社1~3年目は、とにかく人数の問題だと捉えて、ブログ執筆や登壇を繰り返し、会社のWebオペレーションエンジニア(現SRE)のプレゼンスを向上させることに努めました。 このようなアウトプット活動は実を結び、最終的に自分だけでなく2016年はてなWebオペレーションエンジニアのアウトプット にまとめたようにチームメンバー全員で多くのアウトプットを生み出すことができました。*2 さらに、この頃から等級もエンジニアの主力クラスに上がり、シニアエンジニアやプロジェクトリーダーも任されるようになり、自分が制御できる範囲も徐々に増えてきました。 プロジェクトマネジメント、メンタリング、チームビルディングなどのスキルを学び、実践する機会が増えてきました。 その中には、多くの失敗があり、制御できないことを強引に制御しようとしてしまうなど、うまくいかないこともたくさんありました。 たくさんの失敗をしてきた中で「インフラオーナーシップ推進*3」、「本格的なシステム移行」、「基盤領域におけるプロジェクト推進のフレームづくり」の自分のなかでの3本柱が、様々な方々の協力の元に、この1年で所属部署や開発本部全体の取り組みとして扱われ、軌道に乗りつつあり、これからはてなのインフラが成長していくための種は残せたかと思います。 システムプラットフォーム部では、新メンバーもずいぶん増えて、新しいチームとしてどんどん進んでいるのをみて、非常に頼もしく思います。

じゃあそれで問題なしでいいじゃんということになりますが、自分自身について振り返ってみると、自分の仕事を管理・運用・開発・研究というような区分をしたときに、もともとは運用*4が支配的だったところに、人や組織など専門技術以外の管理に関する仕事も増えてきました。 それらの仕事は決して嫌いではなく、ものによってはむしろ率先してやっていたこともあります。 しかし、最もやりたいことであるはずの開発・研究*5については、業務時間の1割にも満たないという状況でした。 そして、自分の性質上、9割を占める業務を放り投げて、やりたいことをやるということはなかなかできませんでした。 となると、必然的にプライベート時間でどれだけ開発・研究をやっていくかという戦いになります。 また人の問題に関わるようになると、リフレッシュのための時間を多く必要とするようになりました。

このままではまずいなあと思っていたところに、僕の師匠であるところのまつもとりーさんが退職されるというご連絡をご本人からいただき、深く考えさせられることとなりました。 というのは、まつもとりーさんが退職される理由そのものが、あれほど高いレベルではないにしろ、自分が抱える問題意識とよく似ていたからです。 そこから内省した結果、いくつかのタイミングの問題もあり、転職することを決めました。

1ヶ月の無職期間を経て、2019年2月からは、さくらインターネット研究所で研究員として、インターネットやウェブ基盤技術の分野で研究開発に取り組んでいきます。 職種はSRE(Site Reliability Engineer)から研究員となり、業種はウェブコンテンツ事業者からホスティング・クラウド事業者へと変わり、新しい挑戦をしていきます。 ある日の休日に散歩していたら突然転職の選択肢が脳内に降ってきてすぐに、まつもとりーさんに声をかけさせていただき、快く相談に乗ってくださったことにとても感謝しています。 いきなり田中さんへつないでいただいたことにはびっくりしました。 お声がけさせていただいてからすぐにお時間を作っていただいた田中さんと鷲北さん、お話をさせていただく時間をつくっていただいた熊谷さん、@yamamasa23さん、@hnakamur2さんに感謝しています。(誤って@yamamoto_febcさんと書いており、申し訳ありません。ご確認いただいたhnakamur2さんありがとうございます。) さくらインターネットの本社が大阪のグランフロントにあり、京都から通勤可能かつ在宅勤務もやりやすい環境とのことなので、これまで通り、京都でのんびり過ごしていきます。

研究開発をやっていくことに決めた後に、印象的なできごとがありました。 先日のAWS re:Invent 2018にて、Amazon Timestreamというフルマネージド時系列データベースが発表されました。 時系列データベースの論文を書いた - ゆううきブログ にも書いたように、これまで時系列データベースの開発・運用を長くやってきて、学術の世界で、新しいアーキテクチャとして提案し、クラウドを新たな基盤として、これまで実効性の観点で採用しなかったであろうアーキテクチャを考えていくことについて書きました。 しかし、IoTの流行による後押しがあるとはいえ、Timestreamの登場により、AWSのようなグローバルの大手クラウド事業者は、ある程度アプリケーションに近いドメインの基盤ソフトウェアをサービス化してくることがわかりました。 最近のクラウド上のマネージドサービスの進化はとても興味深いものであり、AWSのアップデートは熱心に追いかけていますし、クラウド以外にインフラストラクチャに関するOSSプロダクトの進化もすさまじいものがあります。 しかし、それらを使うだけになってしまうという危機感も同時にありました。 そこで、これまでクラウド前提でやってきた頭を切り替えて、あえて自分たちでつくっていくという挑戦ができればと思っています。

はてなの皆様、5年間大変お世話になりました。はてなで得たことは間違いなく今後の人生のベースになるものばかりだと思います。そして、はてなの方々の優秀さをこれから相対的に知っていくのだと思います。これからも、引き続きよろしくお願い致します。

*1:実績ページ https://yuuk.io/のアウトプットはすべてはてなでの経験が元になっています。

*2:一方で、継続してチームでアウトプットしていくというところまでは届きませんでした。

*3:プロダクトオーナーシップという大きな取り組みのうちのインフラ領域に関する方針

*4:新規サービス構築も含む

*5:SREでいうところのソフトウェアエンジニアリング・システムエンジニアリング、論文執筆、アウトプット活動など

時系列データベースの論文を書いた

先週、第11回インターネットと運用技術シンポジウム (IOTS2018)にて、投稿した論文の発表をしてきました。 IOTSは査読付の国内の研究会であり、2年前に招待講演をさせていただいた研究会でもあります情報処理学会でウェブオペレーション技術について招待講演した話 - ゆううきブログ。 実は、そのときに、来年論文を投稿するぞと意気込んでいました。 実際にはそこから2年かかりましたが、この度論文を投稿することができました。

予稿

スライド

実務から研究へ

今回投稿した論文の内容は、Mackerelで開発した時系列データベースに関するものです。 これらはすでにAWS Summit Tokyo 2017Web System Architecture研究会で発表済みのものになります。

エンジニアリングの発表とは異なり、今回は学術論文ということで、「新規性」「有効性」「信頼性」「了解性」の4点を記述できていることが求められます。 学術的貢献の記述の仕方については、特にソフトウェアエンジニアが論文を書くのであれば、学生,若手研究者向けの論文の書き方術 ─システム開発・ソフトウェア開発論文編─の文献が参考になります。 もともと、要素技術の新しさがなければ論文にならないと思いこんでいましたが、こちらの文献を読んだことで、システム開発論文の場合、個別の要素が既知であっても、組み合せが新しく工夫があり、さらに他のシステムに応用可能であり、先行手法と比較して優れていることを主張できていることが重視されるということがわかりました。 ある前提条件の中で、他のシステムに応用可能なレベルで記述された要素技術の組み合わせの法則をアーキテクチャと呼び、新規性の観点では、アーキテクチャが新しいことを示し、有効性の観点では,実装が優れているのではなく、アーキテクチャが優れていることを示すことを目指すというのが自分の理解したろことになります。

当たり前ですが、あらゆる局面に適用可能な大統一アーキテクチャのようなものをいきなり提案できるわけはありません。 サーバモニタリングのための時系列データベースという強い制約条件下においても、あらゆる観点において優位となるアーキテクチャを提案することさえ難しいでしょう。 今回の論文では、Mackerelのようなモニタリングサービス向けの時系列データベースという立ち位置をとり、モニタリングサービスを成長させていくための拡張性をもつ時系列データベースがないという問題意識から、書き込みスケールアウト性、高可用性、書き込み処理効率、データ保存効率といった性能要件を満たしつつ、データ構造の拡張性をもたせるという要件を具体的に設定しました。 これらの要件に対して、分散KVSを利用することで、書き込みスケールアウト性と高可用性を解決し、書き込み処理効率とデータ保存効率、拡張性については、万能なDBMSはないことから単一のデータベース管理システム(DBMS)で対応するのではなく、異なる特性をもつDBMSを複数組み合わせるという時系列データベースの構成法を考えました。 DBMSを複数組み合わせるといっても、どのように組み合わせるのかは自明でないため、組み合わせのための手法として、キーバリューという単純な形式で時系列データ構造をどう表現するのか、DBMS間のデータ移動をどうやるのか、データ構造の拡張をどうやるのかを実装に依存しない手法として落とし込み提案しました。

新規性がどこにあるかについては、論文表題にあるHeteroTSDBというアーキテクチャ名に込めています。 つまり、異種混合(Heterogeneous)のDBMSを組み合わせて、各DBMSの特徴を活かしつつ、欠点は別のDBMSの特徴で補い、ひとつの疎結合な時系列データベースをつくるという考え方です。 異種混合のDBMSを組み合わせること自体は、大規模なWebアプリケーションを構成する上で、よく採用される考え方であり、Martin Kleppmann著「Designing Data-Intensive Applications」での原則になっています。 論文では、時系列データベースとして構成するための法則が世の中になかったために、新規性のあるアーキテクチャであると主張しています。

今回論文化する上で苦労したことは2点あり、先行手法に対する有用性をいかに示すかということと、分量を研究会指定の8ページに収めることでした。 まず、先行手法に対する有用性については、前提として、HeteroTSDBは、単純な性能では、密結合に構成され、処理効率に最適化されたアーキテクチャにはかないません。 当初、提案手法はサーバレスプラットフォームの活用により運用しやすいということを主張しようとしましたが、先行手法の一実装であるOpenTSDBやInfluxDBをサーバレスプラットフォームとして実装すればよいだけで、提案手法が有用ということにはならないと結論付けました。 となるとどのように有用であることを示すのかということについて、HeteroTSDBが疎結合な構成であることに着目し、一般に密結合なソフトウェアよりも疎結合なソフトウェアのほうが拡張しやすいという性質があるために、拡張性という後付けではあるものの、提案手法が有用となる要素を見出しました。 2つ目の分量については、もともとが実務の大きな開発プロジェクトであり、複雑に絡まりあった多くの要素があり、それらをよく知っている分、シンプルに書き上げることが難しく感じました。 例えば、論文では、いろいろ削った上で5つの要件を設定していますが、それでも読み手には負担のかかる数であるため、書き込みスケールアウト性と高可用性については、当たり前に必要ということで要件から外し、よりシンプルにみせるということができたと思います。

ここまで読むと、実務から研究に落とすのは大変なだけなように思います。 しかし、ソフトウェア開発や運用技術の研究では、実用足りうる実効性をもつことを重視されるようになってきていると聞いています。 実効性をもたせることは、実務での成果を直接担うエンジニアが得意とすることであるため、実効性の評価に関しては、記述の仕方について工夫が必要ではあるものの、エンジニアであることが大きなアドバンテージとなると感じました。 Facebookの時系列データベースであるGorillaの論文AmazonのAuroraの論文では、Lessons Learnedという章に、実環境での適用が書かれています。 IOTSの質疑応答の場においても、実効性の観点から生まれた質問がいくつもありました。

なぜ論文化したのか

4年前に書いた インフラエンジニア向けシステム系論文 - ゆううきブログ の記事を書いたころに、自分が得意なシステム系の分野について、数多くの論文が書かれていることを知りました。 このときから、自分が考えたり、作ったりしたものをいつか論文としてアウトプットできるとよいなあと漠然と思っていた気がします。

ソフトウェアエンジニアであれば、自分がつくったソフトウェアをOSSとして公開し、あわよくばいろんなところで使われることで世界に1石を投じるということを夢見ることがあるように思います。 ブログでのアウトプットに一通り満足してきたあるとき、僕はこれに近いモチベーションで論文を書こうと思い立ちました。 近いモチベーションなのであればOSSでいいんじゃないとなるかもしれません。 しかし、新規性があったり、有用性のあるソフトウェアを作るための明確なステップは存在しないようにみえますし、それができる人は高いセンスと努力により飛び越えていっているようにみえます。

そこで、論文として投稿することで、良いものなのかどうなのか客観的に評価を得ることができます。 学術の世界では、長い歴史の中で数多くの知見が蓄積されているために、前述したように評価の観点が整理され、査読というプロセスも確立され、国際会議やジャーナルなど場としてのランク付けもあるために、良いものをつくっていくための客観的ハードルが設けられているように思います。 これらのハードルを超えていくことで、自分を成長させ、最終的に新しいものを作り続けることができるようになることができるのではないか、と考えています。

その他、論文化する意義については、@matsumotoryさんの企業におけるエンジニアリングと研究開発 - GeekOutコラムエンジニアリングや研究開発について思うこと - 人間とウェブの未来 の記事を読むとよいと思います。

論文の裏にあるコンセプト

HeteroTSDBアーキテクチャでは、クラウド上で基盤ソフトウェアを開発していくための一つの考え方を示そうとしています。 基盤技術と一口に言っても、CPUのようにIntelとAMDが大勢を占める層から、Linux、Windows、BSD系などが主に利用されるOS層、その上のミドルウェア層やプログラミング言語処理系の層というように、技術の階層を登れば登るほど、要素技術とその組み合わせの数が多くなっていき、個々の事業固有の層まで達すると、基盤として吸収することは難しくなります。 いかにAWSと言えど、これらの組み合わせをサービスとして揃えていくことは難しいのではないかと考えています。 実際、AWSの個々のサービスは制約を強くかけることにより、スケーラビリティを確保し、AWS利用者は、各サービスを組み合わせ、やりたいことを実現していけるようにできているようにみえます。

これに加えて、HeteroTSDBでは、昨今のデータベース技術の文脈で、サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ では、次のように分解と再構築の考え方に従い、データベースを新しい要素技術の上に再構築しようと試みています。

Martin Kleppmann著、「Designing Data-Intensive Applications」の12章 The Future Of Data Systemsにて、データシステムを構築する上で、すべての異なる状況に適した1つのソフトウェアは存在せず、異なるソフトウェアを組み合わせアプリケーションを開発していく必要があるという趣旨の意見が書かれている。 Diamondアーキテクチャは、この考え方の延長線上にあり、インデックス、WAL、メモリ上のデータ構造、ディスク上のデータ構造など、古典的なデータベースエンジンの構成要素を、ヘテロジニアス環境で再構築したものになる。 そして、サーバレスアーキテクチャにより、分散システム上での複数箇所にまたがるデータの更新、移動を、信頼性のあるビルディングブロックの上に構築しやすくなった。

まとめると、クラウド事業者が吸収できる基盤の限界の外では、分解と再構築の考え方に従い、伝統的な要素技術をクラウド上で再構築し、クラウドを前提としたアーキテクチャを築いていくという考え方になります。 こうしたコンセプトが国外にだしても通用するのかということを問うべく、次は国際会議にだしていきたいと思います。

参考文献

あとがき

業務そのものに直接関係しないにも関わらずおつきあいいただいたはてなの共著者のみなさま(astjさん、itchynyさん、Songmuさん)ありがとうございました。 また、論文化するにあたって、matsumotoryさんとhirolovesbeerさんには、お忙しい中、時間をとっていただいて快く指導していただいたこと、指導いただかなければ論文として形にならなかっただろうということと、指導いただいている間に成長を実感できたことに大変感謝しています。