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

予稿

HeteroTSDB: 異種混合キーバリューストアを用いた自動階層化のための時系列データベースアーキテクチャ

スライド

実務から研究へ

今回投稿した論文の内容は、Mackerelで開発した時系列データベースに関するものです。これらはすでにAWS Summit Tokyo 2017、Web 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として公開し、あわよくばいろんなところで使われることで世界に１石を投じるということを夢見ることがあるように思います。ブログでのアウトプットに一通り満足してきたあるとき、僕はこれに近いモチベーションで論文を書こうと思い立ちました。近いモチベーションなのであれば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さんには、お忙しい中、時間をとっていただいて快く指導していただいたこと、指導いただかなければ論文として形にならなかっただろうということと、指導いただいている間に成長を実感できたことに大変感謝しています。