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

Webシステムアーキテクチャの地図を描く構想

この記事は第5回Webシステムアーキテクチャ研究会の予稿です。

はじめに

Webサービスにおいては、スマートフォンの普及によるアクセス増加に対してスケーラビリティを持ち、個人向けだけでなく企業向けサービスの可用性の要求に耐えられるようなシステム設計が必要とされている。 さらに、Webサービスが人々の生活に浸透したために、Webサービス事業者はサービスを長期間運用することが当たり前となっている。 その間、新機能開発、ソフトウェアの実行効率化、セキュリティ向上などを目的に、システム管理者は自身が管理するソフトウェア群を更新しつづける必要がある。

このような多様な要求を満たすために、Webサービスを開発・運用するエンジニアには、OSやデータベース、ネットワーク、分散システム、プログラミング言語処理系などの情報工学における広範囲の基礎知識と、ミドルウェア、オペレーション自動化のためのソフトウェア、クラウドサービスなどを駆使するための知識が必要となる。 さらに、これらの知識を組み合わせ1つのシステムを構築し、運用していくための技術が必要となる。 以上のように、大学の教科書にあるような古典的な情報工学の基礎知識と現場でのボトムアップな応用知識の両方とその組み合わせが必要となり、既存の教科書だけでは学べないため、体系立てて学ぶことが難しくなっている。 そこで、Webシステム開発・運用の現場の経験を踏まえつつ、生きた知識の地図をつくることが重要となる。

しかし、従来の情報工学の教科書では、情報工学における複数の分野の知識を組み合わせてシステムを構成する手法そのものは記述されていない。 また、Webサービス開発と運用の現場では、情報工学の知識があっても、未経験でも理解できるような形で現場の経験が言語化されていない。 言語化されていたとしても、Web上のブログ記事やスライド資料などでは、断片的であったり、特定の実装や個別の経験に依存した情報となっていることも多い。 類似の問題意識を書籍『Infrastructure As Code』1の冒頭で著者は次のように述べている。

コードとしてインフラストラクチャを管理するという考え方は、従来のインフラストラクチャ管理とは大きく異なる。 私は、この転換をどのように進めたらよいかがわからず苦労しているチームをたくさん見てきた。 しかし、これらのツールを効果的に使うためのアイデア、パターン、プラクティスは、カンファレンスの講演、ブログポスト、個別の論文に散らばっている。

このような問題意識を解決するために、今紹介した『Infrastructure As Code』、『SRE - サイトリライアビリティエンジニアリング』、『詳解システム・パフォーマンス』、『データ指向アプリケーションデザイン』などの、システム開発・運用の現場の経験を盛り込んだ上で体系化した書籍がある。 しかし、Webシステムアーキテクチャに必要な技術要素を網羅するためには,これらの複数の体系を組み合わせる必要がある したがって、どの体系がWebシステムアーキテクチャに必要かが自明でないという課題と、 既存の体系同士の関連性が自明でないという課題がある。

そこで、この研究では、Webシステムアーキテクチャの初学者が,経験による帰納的学習に加えて,体系からの演繹的学習が可能となることを目指す。 さらに、Webシステムアーキテクチャ分野で新しい技術を研究する場合に,体系から複数のアイデアの組み合わせを発見可能とする。 システム分野は、多数の既存知識を組み合わせることが前提となるため、既存の体系を無視して、新たに体系を組み上げることは、その知識の総量から現実的ではない。 そこで、既存の地図(体系)を描き、つなぎ合わせて、どの方向にどれだけ歩くと何にたどり着くかが分かればよい。 そのためには、次の手順で地図を描いていく。

  1. 地図の中心点をとる => 今回はyuukiの関心の中心点であるSRE、すなわち信頼性の制御を選択
  2. 既存の体系(基礎知識体系と応用知識体系)を地図に描く
  3. 地図の中心点からの関連性が不明であったり空白の領地を見つけてそれらを明らかにする

その結果、ソフトウェアアーキテクチャやネットワーク・プロトコル設計など隣の分野から、SREの中心点まで、どのような経路をたどり、どれぐらいの技術要素を超えた先に行き着くのかを知ることができる。

関連体系

Webシステムアーキテクチャに関連する体系として、伝統的な情報工学の教科書以外に、産業界における実践知をまとめた体系がこれまでに提案されている。

SRE(Site Reliability Engineering)

SREは、信頼性(Reliability)こそがあらゆるプロダクトの基本的な機能であると考え、信頼性を軸にこれまでの運用技術を1つの分野として確立した。 書籍2「SRE サイトリライアビリティエンジニアリング」では、信頼性の定義として、文献3の"システムが求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率"を採用している。 さらに、信頼性を定量的にSLO(Service Level Objective)として設定し、システムが求められる信頼性を達成しているかを四半期ごとなど定期的にチェックし続けることが推奨されている。 加えて、SLOと変更速度がトレードオフであることから、SLOを過剰達成せずに変更速度を向上させるために、エラーの発生量を予算消化に見たて、リスクのある変更を許容するエラーバジェットの考え方がある。 このような考え方からSREとは、コンピュータシステムの信頼性を制御し、変更速度を高める工学分野であると捉えることができる。

同書籍では、コンピュータシステムの信頼性制御するための基本要素として、次の6点が挙げられている。

  • モニタリング
  • インシデント対応
  • 変更管理
  • キャパシティプランニング
  • プロビジョニング
  • 効率とパフォーマンス

さらに、第3部にて次の図のようにシステムの信頼性をピラミッドとして組み立てることが提案されている。 モニタリングが最下層にあることから、信頼性の最も基本となるものはモニタリングであると解釈できる。 モニタリングは、対象を監視するというその特性上、対象となるシステムがある程度形になったのちに、始めて開始できる。 したがって、信頼性を構築するにはまず対象となるシステムの特性が明らかである必要があるといえる。

(Betsy Beyer, 2017, p108 図III -1サービスの信頼性の階層)

詳解システム・パフォーマンス

対象となるシステムは、Webシステムの場合は分散システムとなることがほとんどであり、Webシステムにおける分散システムは単一ホスト上のプロセスから構成される。 単一ホスト上の構成を理解するには、OSの原理とOS上で動作するアプリケーションのシステムモデルを理解する必要がある。 書籍「詳解システム・パフォーマンス」4では、OSおよびOSのコンテキストにおけるアプリケーションのパフォーマンス分析と向上手法が解説されている。

同書籍では、次の図のように、単一ホスト上のシステムソフトウェアスタックを整理した上で、オペレーティングシステム、アプリケーション、CPU、メモリ、ファイルシステム、ディスク、ネットワークの要素に分解し、システムのパフォーマンスモデルを解説している。

f:id:y_uuki:20190921181402p:plain (Brendan Gregg, 2017, p2. 図1-1 一般的なシステムソフトウェアスタック)

データ指向アプリケーションデザイン

Webシステムは演算指向のワークロードとデータ指向のワークロードの両方が求められ、とりわけソーシャルネットワークやIoTアプリケーションでは、多数の利用者やデバイスが生成する大量のデータを扱う必要がある。 書籍「データ指向アプリケーションデザイン」5では、分散システムにおける重要な3つの課題である信頼性,スケーラビリティ,メンテナンス性の3点に着目し、データ指向の分散システムを、ストレージエンジン、データを分散するときの配置手法、分散したデータの一貫性の担保手法などの観点で整理している。

Infrastructure As Code

Infrastructure As Codeは、ソフトウェア開発の実践知をITインフラストラクチャの自動化に活かすアプローチである。 書籍「Infrastructure As Code」[^4]では、Infrastructure As Codeのためのツールを次のように分類し、整理している。

  • ダイナミックインフラストラクチャプラットフォーム: インフラストラクチャの基本リソース、特に計算(サーバー)、ストレージ、ネットワークを提供、管理するために使われる。パブリック/プライベートクラウドインフラストラクチャサー ビス、仮想化、物理デバイスの自動構成/設定などが含まれる。
  • インフラストラクチャ定義ツール: サーバー、ストレージ、ネットワークリソースのアロケートや構成/設定を管理する。これらのツールは、高い水準でインフラストラクチャをプロビジョニング、構成設定する。
  • サーバー構成ツール: サーバー自体の細部を扱う。ソフトウェアパッケージ、ユーザーアカウントなど、さまざまなタイプの構成/設定が含まれる。Chef、Ansibleなどを含む。
  • インフラストラクチャサービス: インフラやアプリケーションサービスの管理を支援するツール、サービス。モニタリング、分散処理管理、ソフトウェアのデプロイなどがテーマになる。

関連体系のまとめ

これらの体系をすべて併せると、いずれもWebシステムを構成するために必要な知識の多くを網羅できる。 しかし、もともとこれらの体系はWebシステムアーキテクチャ向けではないため、単一の先行体系のみではWebシステムアーキテクチャの部分しかカバーできないことと、体系の一部が他の体系の一部と重複してしまうことが課題となる。

Webシステムアーキテクチャの分類

そこで、本研究では、Webシステムアーキテクチャを単一の体系として扱うために、関連体系を基にして、Webシステムアーキテクチャを構成する散らばった要素技術を整理し、新たな分類を提案する。 先行する各種体系から、Webシステムアーキテクチャを構成する大きなカテゴリを、次の4点に分類できる。

  • (1) アプリケーションの実行環境の構成手法: アプリケーションやミドルウェアが動作するための環境構築。ITインフラストラクチャなどとも呼ばれる。ネットワークルーティング、共有ストレージ、サーバープロビジョニング、コンテナ仮想化技術などを含む。
  • (2) 単一ホスト上のアプリケーションの構成手法: OSが提供する各種機能を利用し、アプリケーションを構成する手法。Webサーバアーキテクチャ、データベースのストレージエンジンなどを含む。
  • (3) 分散システムとしてのアプリケーションの構成手法: 可用性、スケーラビリティを確保するために複数のミドルウェアを組み合わせ、アプリケーション構成手法。3層構成、データベースの分散構成、マイクロサービス、サーバーレスアーキテクチャなどを含む。
  • (4) 構成されたアプリケーションの信頼性制御: 実行環境の上に構成されたアプリケーションの信頼性を制御し、運用するための手法。モニタリングなどを含む。

これらの分類は、それぞれが独立しているわけではなく、互いに関連している。 例えば、(4)の信頼性を制御するために、システム管理者がキャパシティプランニングを行うとすると、現在のキャパシティ消費量とこれまでの変化を知るためにモニタリングが必要となり、モニタリングをするためには、時系列データを格納するためのデータベースが必要となり、(2)と(3)の知識が必要となる。さらに、キャパシティプランニングの結果にしたがって、キャパシティを増減するためには、(1)の知識が必要となる。

今後の課題

まず、提案する体系を利用したときに,学習可能な範囲を明らかにする必要がある。 ソフトウェアアーキテクチャなどの情報工学の分野との関連性を明らかにする。 今回はWebシステムにおけるバックエンド層に着目したが、ブラウザアプリケーションなどのフロントエンド層との区別と関連性を明らかにする。 また、DevOpsに代表されるカルチャーや組織体系との関連性を明らかにする。

スライド

書誌情報

  • 著者: 坪内佑樹(*1)
  • タイトル: Webシステムアーキテクチャの地図を描く構想
  • 所属: (*1) さくらインターネット株式会社 さくらインターネット研究所
  • 研究会: 第5回Web System Architecture研究会

参考文献


  1. Kief Morris 著, 宮下剛輔 監訳、長尾高弘 訳, “Infrastructure as Code――クラウドにおけるサーバ管理の原則とプラクティス”, オライリー・ジャパン 2017.

  2. Betsy Beyer et al.編, 玉川竜司 訳, 澤田武男,et al. 監訳, “SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム”, オライリー・ジャパン, 2017.

  3. Patrick O'Connor, Andre Kleyner, Practical Reliability Engineering, Wiley, 2011.

  4. Brendan Gregg 著, 西脇靖紘 監訳, 長尾高弘 訳, “詳解 システム・パフォーマンス”, オライリー・ジャパン, 2017.

  5. Martin Kleppmann著, 斉藤太郎 監訳, 玉川竜司 訳, “データ指向アプリケーションデザイン――信頼性、拡張性、保守性の高い分散システム設計の原理”, オライリー・ジャパン, 2019.

サーバーレスアーキテクチャ再考

2014年にAWS Lambdaが登場し、Functionを単位としてアプリケーションを実行する基盤をFunction as a Service(以下、FaaS)と呼ぶようになった。 そして、同時にサーバーレスアーキテクチャ、またはサーバーレスコンピューティングと呼ばれる新しいコンセプトが普及するに至った。 当初、そのコンセプトが一体何を示すかが定まっていなかったために議論が巻き起こり、今現在では一定の理解に着地し、議論が落ち着いているようにみえる。 しかし、サーバーレスという名付けが悪いということで議論が着地したようにみえていることにわずかに疑問を覚えたために、2019年の今、これらの流れを振り返ってみて、サーバーレスアーキテクチャとは何かを改めて考えてみる。

サーバーレスとの個人的関わり

サーバーレスアーキテクチャという名を僕がはじめて耳にしたのはAWS Lambdaが登場した2015年だったと思う。 当初は、ご多分に漏れず、「サーバーレス?サーバーを使わないってことはフロントエンドの話か?クライアントサイドでP2Pでもやるのかな」と思いながら、解説記事を開くと、関数だとかイベント駆動だとリアクティブだとか書かれていてなにやらよくわからないけど、とりあえずサーバーあるやん!とつっこんでしまった。 その後、僕自身はサーバーレスアーキテクチャというものにさして興味をもたずに、どうやらFaaSを利用したシステムのことをサーバーレスと呼ぶらしいという話に一旦落ち着いたようにみえた。

その後、前職で機会があり、2016年後半あたりからサーバーレスアーキテクチャに基づいて時系列データベースアプリケーションを開発したことがあった時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ。 そこで、AWS LambdaやAmazon DynamoDBを使い倒し、具体的な開発や運用のノウハウを蓄積したのちに、論文にまとめることとなり、サーバーレスとは改めて何だったのかということを振り返るきっかけとなった時系列データベースの論文を書いた - ゆううきブログ

サーバーレスの既存の定義

まずここで第一に文献として挙げたいのが、CNCF(Cloud Native Computing Foundation)内のサーバーレスワーキンググループがまとめたサーバーレスコンピューティングのホワイトペーパーである。*1 このホワイトペーパーから、サーバーレスコンピューティングの定義を引用してみよう。

A serverless computing platform may provide one or both of the following:

  1. Functions-as-a-Service (FaaS), which typically provides event-driven computing. Developers run and manage application code with functions that are triggered by events or HTTP requests. Developers deploy small units of code to the FaaS, which are executed as needed as discrete actions, scaling without the need to manage servers or any other underlying infrastructure.

  2. Backend-as-a-Service (BaaS), which are third-party API-based services that replace core subsets of functionality in an application. Because those APIs are provided as a service that auto-scales and operates transparently, this appears to the developer to be serverless.

簡単にいうと、サーバーレスコンピューティングとは、FaaSとBaaSのいずれか一方か両方を指すという定義になっている。 BaaSというのは、データベースなどのアプリケーションが必要とする機能の一部をAPIを通じて利用可能なサービスとなっているものの総称である。 BaaSの例として、データベース系統であれば、Amazon DynamoDBやGoogle BigQuery、メール系統であればSendgrid、DNS系統であればAmazon Route53、認証系であればAuth0などがある。

次に、カリフォルニア大学バークレー校からArxivにて今年公開された論文"Cloud Programming Simplified: A Berkeley View on Serverless Computing"*2によると、次のように記述されており、ここでも、FaaS + BaaSの定義が採用されている。

Put simply, serverless computing = FaaS + BaaS. In our definition, for a service to be considered serverless, it must scale automatically with no need for explicit provisioning, and be billed based on usage.

さらに、AWSのサーバーレスの製品サイトによると、サーバーレスプラットフォームと称して、コンピューティングカテゴリのAWS Lambdaだけでなく、ストレージ、データストアなどのBaaSも含まれている。

既存の定義から、サーバーレスはFaaS+BaaSということでもういいじゃんということになるのだけれども、なぜこれらが「サーバーレス」といえるのかをここではもう少し掘り下げてみよう。

サーバーフルコンピューティング

まず、そもそも「サーバー」という用語が示す意味を考える。 サーバーは多義的な用語であり、少なくとも、ハードウェアとしてのサーバーとソフトウェアとしてのサーバーの2つの顔をもつ。 ここでは、データセンター内にある物理マシンと物理マシンを仮想化した仮想マシンを「マシンサーバー」とし、WebサーバーのようにOS上でネットワークソケット宛ての要求を処理するプロセスを「ネットワークサーバー」とする。

前者のマシンサーバーは、通常、コンピューティング機能としてCPU、RAMがあり、永続化機能としてのディスク、ネットワーク通信機能としてのNICといったモデル化されたハードウェアとして認識することが多い。 しかし、実際に抽象化の進んでいるWebアプリケーションのようなソフトウェアを開発していると、ハードウェアが隠蔽されているため、今書いているコードがどの程度メモリを消費して、どの程度のディスクIOPSになるのかといったことを知ることは難しい。 実際に動作させて計測しないとあたりもつけられないというところが実態だろう。 過去の経験では、アプリケーション開発者がコードを書き、SREがマシンサーバーのキャパシティを見積もるというような分担をしている場合に、SREはコードからではキャパシティの見積もりようがないので、ベンチマークして実験するか、すでに稼働している同じような性質のアプリケーションがあればそのアプリケーションがもたらすハードウェアリソース量を参考にしたりしていた。 加えて、高可用性やスケールアウトのために同一構成のサーバーを複数台用意したりする必要もある。 つまり、いくら抽象化されていても、ハードウェアを意識しないといけないということである。

後者のネットワークサーバーは常にプロセスが起動しており、特定のポート番号を占有して待ち受けている形態をとる。 常にプロセスが起動していれば、ソフトウェア開発者はメモリなどのリソースのリークを気にしなければならない。 また、ソケットを共有していない複数のネットワークサーバーが同一のポートを共有することはできないため、要求を処理しつづけながらネットワークサーバーのコードをデプロイするために、Graceful Restartのようなネットワークサーバー特有の仕組みが必要となる。 こちらも、ネットワークサーバーであることを意識する必要がある。

このように、サーバー上でソフトウェアを動作させることを意識して、プログラミングしたり、デプロイしたりすることを先程の"Cloud Programming Simplified"の論文ではサーバーフルコンピューティング(Serverful Computing)と読んでいる。

サーバーレスとはなにか

書籍「Serverlessを支える技術」 *3の表現を借りると、サーバーレスとは「サーバという単位を意識しない」ということになる。 これだけではまだちょっとよくわからないので、この考え方をマシンサーバーとネットワークサーバーのそれぞれに適用してみよう。

まず、マシンサーバーという単位を意識しないということは、マシンサーバーの個数やスペックを意識しないし、ハードウェアのリソースをどの程度消費するかということを意識しないということになる。 これは、DynamoDBやBigQueryの利用体験に近しいものがある。 DynamoDBについては、DynamoDBのインフラコストの構造と削減策 - ゆううきブログの記事で述べたように、インスタンスサイズによる課金モデルではなく、ストレージのデータ使用量とスループットを基にした課金モデルとなっている。 つまり、ハードウェアリソースの消費量ではなく、クエリの回数や保存データ量といったよりアプリケーションに近いモデルでキャパシティの見積もりが可能となる。 サーバーの個数やスペックも隠蔽されているため、自分でDynamoDB相当のデータストアを構築する場合と比べて、明らかにマシンサーバーを意識しなくてよくなっている。

次に、ネットワークサーバーを意識しないために、アプリケーションの実行単位をサーバーではなくFunctionとしたのがFaaSのアプローチである。 FaaSでは、様々なイベントをFunctionの入力として扱え、Functionプロセスがイベントを購読するモデルとなっている。 例えば、Webアプリケーションサーバー代わりに、Amazon API GatewayがHTTPリクエストを受け付けて、内部でLambda用のイベントに変換した上でLambda Functionに受け渡す。 その他、バッチサーバー代わりに、Amazon CloudWatch Eventsでイベントを発火する日にちや時刻を指定し、Lambda Functionを起動することもできる。 イベントの発火を契機にFunctionが起動するため、Function自体は通常のネットワークサーバーのように常時起動するわけではない。 Functionプロセスは一定時間起動し、連続してイベントを処理したのちに停止するため、毎回コンテナプロセスを起動するコストを低減させている。 Functionは必要なときに起動されるだけなので、事前にFunctionプロセスを何個起動するかといったキャパシティプランニングが不要である。 また、イベント駆動でのプロセス起動とイベント購読モデルであることから、イベントの流量が増加しても流量にあわせてひたすらFunctionプロセスを起動させていくだけなので、オートスケールが容易である。 これは、Functionプロセスがマシンサーバー上で動作することを意識しなくてよい点である。 ただし、現状では、Functionプロセスのメモリサイズを指定する必要があるため、マシンサーバーであることを完全に隠蔽できているわけではない。

蛇足だが、サーバーレスとはCGIであるという言説もSNS上でみたことがあるかもしれない。 CGIはWebサーバーが受け付けたHTTPリクエストを契機に任意のスクリプトを実行できるため、FaaSの特性のうち、イベントを契機にFunctionプロセスを起動するところがCGIと似ている。 ただし、CGIにはBaaSの性質は含まれないこと、扱えるイベントがHTTPのみといった当たり前のわかりやすい違いがある。 さらに、WebサーバーとCGIスクリプトは密結合であり同一ホスト上で実行されるため、CGI処理のみスケールさせるということはできない。 したがって、Webサーバーのホスト自体をスケールさせる必要があるため、マシンサーバーとして意識しなければならない。

サーバーレスにより単にサーバーを意識しないだけでなく、アプリケーション実行単位がFunctionとなった結果、Functionを糊として、各BaaSをつなぐピタゴラスイッチのような構成がとられるようになった。 例えば、BaaS上で発生するイベントをFunctionに入力し、そのFunction内で別のBaaSのAPIを叩き、さらにそのイベントを契機に別のFunctionが起動するといったものである。 そのような構成を指して、サーバーレスアーキテクチャと呼ぶこともある。 時系列データベースという概念をクラウドの技で再構築する - ゆううきブログの構成はまさにそのようになっている。 部分的に紹介すると、DynamoDBへの書き込み時にレコード単位でTTLを設定し、TTLが0になった時点で、Functionにレコード内容をイベントとして入力し、S3にPutするといった処理の流れになっている。 サーバーレスの名称からピタゴラスイッチ構成を直接想像することは難しいが、サーバーを意識しなくなった結果、少なくともWebアプリケーションのスコープでは新しい構成がみられるようになったことは、ここ数年で一番好きな技術変遷である。 ただし現状では、クラウドベンダーが独自にFaaSとBaaSを連携させているため、OSSを使って同様の構成をとることはとてもむずかしく、特定のクラウドベンダーに非依存でピタゴラスイッチ構成を実現するにはどうしたらいいかに興味を持っている。 FaaSについては基礎的なビルディングブロックを提供するKnativeや、まさにFaaSそのものを実現するOpenFaaSなどがあり、ベンダー非依存の環境が整ってきている。 しかし、FaaSとBaaSを連携するには、少なくとも、CloudEventsのようにイベントの表現を標準化することと、BaaS側ではOSSミドルウェアにイベントを発火できるように対応する必要があり、道のりは険しい。

サーバーレスの制約

さて、ここまででだいたいサーバーレスがなにかということの議論は終わったが、ではあらゆるアプリケーションをサーバーレスで設計するのがよいかというとそういうわけではない。 特にネットワークサーバーの形態をとらないことは、前述のようなメリットもある一方でデメリットもある。 その一例として、次の図に示すように、FaaSにおいて、同期的に応答しなければならないリクエストが都度やってくる場合、リクエストを1個ずつFunctionで処理することになるため、各リクエストを同一プロセスで並行処理できない。 Functionの処理のうちI/Oブロッキング時間が支配的であれば、I/Oブロッキング中にCPUは他のFunctionで利用できるがメモリは確保したままになるため、メモリ使用効率が悪く、コストが高くなってしまうという課題がある。 ちなみに、非同期の応答でよければ、FaaS内のキューにイベントを溜め込み、Functionが複数のイベントを同時に取得できるため、複数のリクエストを並行処理可能である。 この課題については、コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログの記事で具体的なアプリケーションを例にして紹介している。

"Cloud Programming Simplified"の論文では、その他の現状のサーバーレスプラットフォームの制約を整理してまとめられている。 このように従来のサーバーフルコンピューティングではなかった制約があるため、アプリケーションの特性を見極めて、アーキテクチャを選択する必要がある。

まとめ

このエントリでは、サーバーレスアーキテクチャが主観的にどのように見えていたかから始まり、サーバーレスの既存の定義を紹介したあとに、そもそもサーバーとはなにか、サーバーレスはサーバーという単位を意識しないという意味で捉えて、サーバーレスアーキテクチャとは何だったのかを再考した。 サーバーレスという名前付けがその意図とセットで普及しなかった結果、ミスリーディングな名前となってしまったが、一周回ってこの名前もそれほど悪くはないように思えてきた、というのがこのエントリを書いた動機となった。

このエントリの下書きをLINE OpenChatで先んじて公開したところ、@tzkbさんからデータベースの文脈だとサーバーレスはどうなんでしょうねという話題になり、伝統的なデータベースでは密結合になっているバッファプールとテーブルファイルなどのデータ構造を分解して、各データ構造をBaaS上で実装してFaaSでつないで、ユーザーが書いたFunctionをフックできたり、BaaS上に任意のインデックス構造を拡張できたりするアーキテクチャにしたらおもしろいよねといって盛り上がった。 昨年論文にしたTSDBのアーキテクチャではまさにそのような分解と再構築を行っていたのだった。 https://blog.yuuk.io/entry/2018/writing-the-tsdb-paper

*1:Sarah Allen, et al., CNCF Serverless Whitepaper v1.0, https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview, 2019.

*2:Eric Jonas, et al., Cloud Programming Simplified: A Berkeley View on Serverless Computing, arXiv preprint arXiv:1902.03383, 2019.

*3:Aki @ nekoruri, Serverlessを支える技術 第3版, BOOTH, 2019.

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

先日、アメリカのウィスコンシン州ミルウォーキーで開催された国際会議 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だったかもしれない

エッジコンピューティングに向けた分散キャッシュ技術の調査

はじめに

Webサービスの応答速度を向上させることにより,ユーザーの体験が向上することが知られている. 実際に,40%以上のWebサービスのユーザーはページの読み込みを3秒以上待てないという調査結果がある1. クラウドコンピューティングを利用し,Webサービスを提供する場合,読み込み遅延の要因は次の3つである.

  1. クラウドのデータセンター内での処理遅延
  2. エンドユーザーとデータセンター間のネットワーク転送遅延
  3. ブラウザ上でのコンテンツ表示遅延

(2)の遅延を削減し,より高速にエンドユーザーに応答を返すには,エンドユーザーの近傍で要求を処理する必要がある.

Webサービスを提供する企業は,Akamai,CloudFront,Fastlyなどの事業者が提供するCDN(Content Delivery Network)を以前より活用し,画像や動画などの静的コンテンツの配信を高速化してきた. 近年では,一度キャッシュされたデータを破棄するまでの処理時間が高速化したことにより,動的コンテンツのキャッシュにもCDNを利用することがある. さらには,単なるキャッシュを配信するだけでなく,CDNのエッジサーバ上で要求に対して任意の処理を実行できるように,エッジサーバに任意のアプリケーションを配置することが可能となるCDN Edge Workerと呼ばれるサービスが登場している. プログラミング言語処理系の制約があるものの,CDN Edge Workerとしては,AWS Lambda@Edge2,Cloudflare Workers3,fly.io4などがある.

しかし,動的コンテンツに対してCDNを適用する場合,すべてのエッジでキャッシュが無効化されるまでに遅延があり,キャッシュ間またはキャッシュとオリジンのデータとの間の一貫性が弱いという課題がある. CDN Edge Workerにおいても,アプリケーションの配置は可能であるが,データの一貫性については厳密に保証するデータストアが提供されているわけではない.

この記事では,Webアプリケーションの応答性能を向上させるために,各エッジ上でコンテンツ生成や配信に必要なデータのキャッシュをもつための分散キャッシュの関連技術を調査する.

エッジコンピューティング

CDN以外にも,エンドユーザーとクラウドのデータセンターの間に中間層を設けることにより,ネットワークレイテンシを最小化するエッジコンピューティング5が研究されている. エッジコンピューティングの研究分野では,IoT (Internet of Things),スマートシティ,仮想現実などの従来のPCやスマートフォン以外のエンドデバイスを活用するような新しいコンピューティングへの適用が主目的となっている.

エッジコンピューティング調査 - 動機と分類 - ゆううきメモ

分散キャッシュの関連技術

Webアプリケーションの読み出し性能を向上するためのキャッシュの要素技術を整理し,その特徴を述べる. 要素技術として,オブジェクトキャッシュ,クエリリザルトキャッシュ,HTTPキャッシュ,ICN(Information-Centric Networking)がある.

オブジェクトキャッシュ

オブジェクトキャッシュはアプリケーションが任意のオブジェクトをキャッシュするための機構である. オブジェクトキャッシュのためのデータストアとして,アプリケーションプロセスがネットワーク通信して利用するネットワーク型の分散キャッシュシステムと,アプリケーションプロセスと同一のメモリ空間にキャッシュデータを保持する組み込み型の分散キャッシュシステムがある.

ネットワーク型の分散キャッシュシステムとして,MemcachedやRedisが広く利用されている. これらのキャッシュシステムを複数のキャッシュノードへ負荷分散するために,ハッシュ法を利用することにより,オブジェクトのキーと分散先のキャッシュノードを紐づけし,オブジェクト単位で分散させてキャッシュノードへデータを配置する. この手法は,キャッシュノードの追加または削除時に,オブジェクトのキーとノードの紐づけが変更され,大部分のキーを再配置することにより,性能が低下するという課題をもつ. そこで,ノードの追加・削除時に,オブジェクトのキーとノードの割り当てをなるべくかえずに分散するためにコンシステントハッシュ法が利用される.

groupcache6は組み込み型のオブジェクトキャッシュであり,Go言語のライブラリとして実装されている. groupcacheは複数のノードが協調して一つのキャッシュ空間を作成可能であり,ローカルノードに当該キャッシュがなければ,ピアノードに対してフォールバックし,キャッシュを取得するようになっている. さらに,groupcacheはフォールバック後に確率的にローカルノードのキャッシュにデータを書き込み,次回以降当該オブジェクトのキャッシュはローカルノードで取得可能となる. また,ピアノードはコンシステントハッシュ法により選択されるため,ローカルでのキャッシュミス時にすべてのピアにフォールバックしなくてよい. groupcacheは更新と削除をサポートしておらず,LRUによりキャッシュが破棄されないかぎり,普遍のデータを格納する.

オブジェクトキャッシュをエッジコンピューティング上で展開するのであれば,低レイテンシでキャッシュを取得するために,近隣のエッジに配置されたキャッシュノードからデータ取得を完結したい. そのための手法として,エッジ群をエリアに区切り,エリアごとにキャッシュクラスタを用意する,または,キャッシュの参照パターンが同じエリアに偏ると考えて,コンシステントハッシュ法で分散するのではなく,なんらかの方法で距離が近いエッジ群を認識し,近傍エッジ内で完結してキャッシュを読み書きするようにする.

クエリリザルトキャッシュ

データベースミドルウェアの層でキャッシュする場合,データベースへのクエリの結果をキャッシュするクエリリザルトキャッシュを利用する.

MySQLのクエリリザルトキャッシュは,データベースサーバ自体がキャッシュ機構をもつため,追加のソフトウェアなしにクエリリザルトキャッシュを利用できる. テーブルに更新があれば,当該テーブルの変更が結果に影響するクエリのキャッシュを破棄するため,テーブルとキャッシュ間で一貫性を維持する.

ProxySQL7は,MySQLプロトコルを解釈するプロキシサーバであり,クエリリザルトキャッシュ8,クエリルーティング,MySQLサーバのフェイルオーバーといった機能をもつ. ProxySQLは独立したプロセスとして起動するプロキシであることから,ProxySQLのクエリリザルトキャッシュは,MySQLサーバよりもよりフロントエンドに近い位置に配置することが可能である. 例えば,アプリケーションサーバと同一のホスト上に配置することにより,アプリケーションサーバとMySQLサーバ間のRTTを削減できる. しかし,TTL(Time to Live)を利用してキャッシュを無効化するため,アプリケーションに対して古くなったデータを返す可能性がある. また,ProxySQLは,複数のピアノードと協調してキャッシュデータを同期したり,キャッシュプールを共有することはない.

DBProxy[^8]は,エッジ上に配置された各アプリケーションサーバが,中央のデータベースサーバに対するクエリ結果をキャッシュする. また,リレーションを基にしたキャッシュ表現を持つ. さらに,クエリ結果が他のクエリによりキャッシュされたデータによる構築できるのであれば,未キャッシュのクエリの結果を返すという巧妙なクエリ処理が可能である. DBProxyは,中央集権的に一貫性を管理することにより,各キャッシュは中央データベースに対してコヒーレントとなっている. しかし,クエリキャッシュを利用する複数のステートメントを含むトランザクションに対応できるようなトランザクションの観点での一貫性は保証されない.

Ferdinand9は,分散されたデータベースクエリリザルトキャッシングによる,動的コンテンツ配信のための協調動作するプロキシである. トピックベースのpublish/subscribeモデルにより,キャッシュの一貫性を維持し,DBProxyと同様に,複数のステートメントを含むトランザクション向けの一貫性を緩めている. 実験の結果,3倍程度の性能向上があった一方で,エッジ上のキャッシュノード間とキャッシュノードと中央データベースの間のRTTを大きくした環境では,RTTが増加すると急激にスループットが落ち込むという結果を示した.

DBProxyとFerdinandのような各アプリケーションサーバが一貫したキャッシュを持つアプローチでは,一貫性を保つためにキャッシュの更新時に同期が必要となる. エッジが地理的に張り巡らされているような環境を想定したときに,エッジ間のネットワークレイテンシが大きくなるため,エッジ間で同期を待つと,応答速度が低下するという課題がある. このような課題に対して,超個体的DBクエリリザルトキャッシング10で紹介しているような適応的なクラスタ制御により解決を試みていくつもりがある.

まとめ

この記事では,Webアプリケーションの読み出し性能を向上させるための分散キャッシュの要素技術を調査した. 今後は,この記事の調査内容を基に,超個体型DBクエリキャッシュ構想[^10]がどのような立ち位置にあるのかを明確にしていきたい.

スライド

参考文献


  1. Forrester Consulting, “eCommerce Web Site Performance Today: An Updated Look At Consumer Reaction To A Poor Online Shopping Experience”, 2019.

  2. Amazon Web Services, Inc., Lambda@Edge, https://aws.amazon.com/lambda/edge/.

  3. Cloudflare, Inc., Serverless Computing with Cloudflare Workers, >https://www.cloudflare.com/products/cloudflare-workers/>.

  4. Fly, JavaScript at the Edge, https://fly.io/.

  5. B Kashif, K Osman, E Aiman, K Samee U, “Potentials, trends, and prospects in edge technologies: Fog, cloudlet, mobile edge, and micro data centers.”, Computer Networks, vol.130, pp.94-120, 2018.

  6. Groupcache, https://github.com/golang/groupcache.

  7. ProxySQL: High-performance MySQL proxy with a GPL license, https://proxysql.com/.

  8. K Amiri, S Park, R Tewari, and S Padmanabhan, “DBProxy: A dynamic data cache for Web applications”, International Conference on Data Engineering, pp.821-831, 2003.

  9. C Garrod, A Manjhi, A Ailamaki, B Maggs, T Mowry, Christopher Olston and Anthony Tomasic, “Scalable query result caching for web applications”, VLDB Endowment, vol.1, no.1, pp.550-561, 2008.

  10. 坪内佑樹, 超個体型DBクエリキャッシュ構想, Hosting Casual Talks #5, https://speakerdeck.com/yuukit/chao-ge-ti-de-dbkuerikiyatusingugou-xiang.

エッジコンピューティングを活かしたウェブアプリケーションホスティング構想

さくらインターネット研究所では、超個体型データセンターというコンセプトに則り、あらゆるデバイスと場所がデータセンターとなり、各データセンターが有機的に結合した集中と分散のハイブリッド構造をもつコンピューティングを目指している。 超個体型データセンターにとって、重要な先行コンセプトに、エッジコンピューティングがある。 この記事では、エッジコンピューティング環境において、ウェブアプリケーションをホスティングするためのアーキテクチャを考察する。

エッジコンピューティング

Kashifらのサーベイ論文1によると、エッジコンピューティング技術を必要とする背景は、次のようなものになる。 スマートデバイス、ウェアラブルガジェット、センサーの発展により、スマートシティ、pervasive healthcare、AR、インタラクティブなマルチメディア、IoE(Internet of Everything)などのビジョンが現実化しつつあり、レイテンシに敏感で高速なレスポンスを必要とする。 従来のクラウドコンピューティングでは、エンドユーザーや端末とデータセンターとの間のネットワークレイテンシが大きいという課題がある。 そこで、この課題を解決するために、エッジコンピューティングでは、ネットワークのエッジやエンドユーザーとクラウドデータセンターの間の中間層を設けることにより、レイテンシの最小化とネットワークの中枢の下りと上りのトラフィックの最小化を目指す。 (エッジコンピューティング調査 - 動機と分類 - ゆううきメモ)

エッジコンピューティングは、ある一つの形態があるのではなく、複数のコンピューティング形態を内包する。 先のサーベイ論文は、エッジコンピューティング技術としてFogコンピューティング2、Cloudlets3、Mobile Edge Computing(MEC)4、Micro Data Centers5の4つが紹介されている。 エッジと呼ぶものの実態は、ルーターやアクセスポイントであったり、基地局に付随する小さなクラウド環境であったり、単独の小さなデータセンターであったりする。 エッジコンピューティングの典型構成は、端末 - エッジ - クラウドの3-tier構造であり、P2Pのような強い分散構造ではなく、端末とエッジの分散構造とクラウドの集中構造を併せ持つ。 エッジコンピューティングを利用したアプリケーションでは、エッジでは端末から収集した情報をフィルタリングしつつクラウドへ転送したり、アクチュエーターの制御のために端末の情報をもとに別の端末へ制御命令を送るといった処理フローが想定されている。

エッジコンピューティングでは、エッジコンピューティング調査 - アプリケーション - ゆううきメモで紹介したように、インタラクティブな動画コンテンツ、ウェアラブルコンピューティング、クラウドゲーミング、スマートリビング、スマートグリッド、医療モニタリング、5Gなど、現場にあるものをリアルタイムに制御する必要があるアプリケーションが想定されている。 これらのアプリケーションの端末までの想定応答時間は25-50ms程度であり、クラウドへ到達できないほどのシビアな要求となる。 これらのアプリケーションは、現場にある大量のデータを収集し、それらの情報をもとに分析をしたり、なんらかの制御を実行したりするデータインテンシブなアプリケーションといえる。

エッジコンピューティングは、このようなリアルタイムアプリケーションをメインターゲットとする一方で、これまでクラウド上でホスティングされてきた伝統的なウェブアプリケーションについて、エンドユーザーからみた応答速度を高める可能性がある。

エッジコンピューティングの目的であるエンドユーザーとのレイテンシの削減を達成するためには、ユーザーがどこにいても、近傍にデータセンターが存在しなくてはならないため、エッジが地理的に遍在している状況を仮定する。 そこで、クラウドとエッジを併用する環境を利用し、WordPressのようにデータをRDBMSに格納する伝統的なウェブアプリケーションの応答速度を向上させる手法を考察する。

エッジ環境におけるウェブアプリケーションホスティングの課題

ウェブアプリケーションの分類

エッジ環境にホスティングすることを前提に、ウェブアプリケーションを観点ごとに分類する。 まず、ウェブアプリケーションを処理の複雑さに応じて分類すると、最も簡単なものが静的サイト、その次にデータベースを用いない動的サイト、さらに単一のデータベースを用いた動的サイト、最後にNoSQLなど異種混合のデータベースを併用する動的サイトがある。 次に、ウェブアプリケーションをアクセスパターンにより分類すると、ブログシステムのような読み込み処理主体のRead Heavyアプリケーションと、ソーシャルゲームのような書き込み処理主体のWrite Heavyアプリケーションがある。 次の節では、単一のデータベースを用いた動的サイトがRead Heavyのアクセスパターンをもつアプリケーションを仮定し、構成パターンを議論する。

ウェブアプリケーションの構成パターン

伝統的なウェブアプリケーションは、ウェブサーバ、アプリケーションサーバ、データベースサーバの3-tier構造により構成される。 この3-tier構造をエッジコンピューティング環境で構成するパターンは次の3つである。

  • (a): 3-tier構造をすべてエッジに配置。
  • (b): ウェブサーバとアプリケーションサーバをエッジに配置し、データベースサーバをクラウドに配置。
  • (c): ウェブサーバをエッジに配置し、アプリケーションサーバとデータベースサーバをクラウドに配置。

図1に示すパターン(a)については、エッジ環境にてtier要素をすべて配置することにより、エッジ内で処理が完結するため、エンドユーザーへの応答時間を短縮できる。 しかし、データベースサーバを分散することになり、各データベースサーバの一貫性を維持するためのプロトコルが必要となる。 具体的に一貫性を維持する状況として、各アプリケーションサーバがローカルのデータベースに書き込むときに、他のエッジのデータベースとの間で書き込み競合がある。 または、書き込み競合を避けるために、図1の左の図のように、各エッジ上のアプリケーションサーバがクラウド上のデータベースサーバのみに書き込み、ローカルのデータベースから読み出すように構成し、読み込みクエリのみを高速化かつスケールする手法もある。 つまり、クラウド上のデータベースサーバを単一のリーダー(マスターとも呼ぶ)として、エッジ上のデータベースサーバをフォロワー(スレーブとも呼ぶ)とし、フォロワーには読み込みクエリのみを向ける。 しかし、この手法を適用すると、Read-after-write consistency6、Monotonic reads7などのレプリケーション遅延により引き起こされる異常が発生することがある。

エッジコンピューティングのように、クラウド内通信と比較し通信レイテンシの大きい環境では、書き込みが全ノードに伝搬する前に別のノードが次の書き込みを開始する可能性が高くなるため、一貫性を維持するためにキャッシュエントリの更新時に待ち時間を要するはずである。 強めの一貫性モデルを採用すると、全体のスループットが低下する恐れがあるため、性能を優先するのであれば、結果整合性などの弱い一貫性モデルを採用する必要がある。 このような一貫性と性能のトレードオフに対して、データベースミドルウェアのみで解決することは難しく、アプリケーション仕様やコードにて一貫性の考慮が必要となる。

f:id:y_uuki:20190227164806p:plainf:id:y_uuki:20190227164801p:plain
図1: 構成パターン(a) Leaderless構成とSingle Leader構成

図2に示すパターン(b)については、アプリケーションサーバとデータベースサーバ間のレイテンシが大きいという性質がある。 アプリケーションサーバが動的コンテンツを生成したり、API処理をするには、1回以上データベースに問い合わせすることになる。 したがって、ユーザーとウェブサーバ間でHTTPのリクエストとレスポンスを1往復する処理の間に、アプリケーションサーバからデータベースサーバへのクエリと結果取得の往復が少なくとも1回以上あるため、クラウドのみのパターンと比較し、却って応答が遅くなる可能性がある。

Webサービスをデータセンター移行するときに必要となる技術要素 - ゆううきブログでは、地理的に離れた複数のデータセンター間をまたいで、パターン(b)と同様にウェブアプリケーションを構成したときの応答時間の変化を紹介している。

図2: 構成パターン(b)

図3に示すパターン(c)については、ウェブサーバとアプリケーションサーバ間のレイテンシが大きいという性質がある。 HTTPリダイレクトや静的コンテンツの配信など、ウェブサーバのみで完結する処理については、ユーザーの近傍で処理が完結するため、パターン(c)は高速となる(ただし、パターン(b)も同様)。 また、ウェブサーバとアプリケーションサーバ間の接続を永続化することにより、TCPの3-wayハンドシェイクのためのラウンドトリップ時間を抑えられる。 ウェブサーバとアプリケーションサーバ間はHTTPの往復は1回となるため、パターン(b)のように却って応答が遅くなることはない。 しかし、アプリケーションサーバがウェブアプリケーションとしての処理の大部分を実行するという前提を置くと、エッジコンピューティングの利点を生かせていない構成といえる。

図3: 構成パターン(c)

アーキテクチャ設計

エッジコンピューティングがもつエンドユーザーとのレイテンシ最小化の利点を活かすには、Read Heavyアプリケーションに対して、構成パターン(a)または(b)を適用することになる。 データの複製、クエリの結果のキャッシュ、バッファプールを各エッジとクラウド間で協調して同期することにより、それぞれの構成の課題を解決する。

分散クエリキャッシュ

構成パターン(b)の課題であるアプリケーションサーバとクラウドのレイテンシ増大をクエリキャッシュにより削減することを考える。

分散クエリキャッシュの先行手法の一つにFerdinand8がある。 Ferdinandは、各アプリケーションサーバがキャッシュをローカルに持ち publish/subscribeにより、アプリケーションサーバ群が協調してキャッシュを同期する。これにより、アプリケーションコードを変更せずに、中央のデータベースサーバの負荷を削減し、スループットを向上させている。

エッジ環境では、エッジ数の個数の増加とエッジ間やエッジ・クラウド間のネットワークがレイテンシが大きいかつ不安定になることが想定される。 キャッシュの一貫性を維持しようとすると、最もレイテンシの大きいノードへのキャッシュの伝搬を他のアプリケーションサーバが待たねばならず、全体のスループットが低下する可能性がある。 そこで、古いキャッシュの読み込みを許した一貫性モデルを採用し、アプリケーションコードを極力変更せずにすむ手法を考える。

図4にHTTPメソッド単位でエッジかクラウドで処理するかを分岐するアーキテクチャ(HTTPメソッドフォワーディング)を示す。 HTTP POST/DELETE/PUTリクエスト処理は更新トランザクションを含むと仮定し、Read-after-write consistencyなどの異常を避けるために、クラウド側のアプリケーションサーバへリクエストを転送する。 HTTP GETリクエスト処理は参照トランザクションのみを含むと仮定し、データベースサーバの複製またはキャッシュが古くても一貫性に関する異常が起きないとして、HTTP GETをエッジのアプリケーションサーバへ転送する。 この手法により、HTTP POST/DELETE/PUTはこれまで通りクラウドで処理するため応答速度は向上は見込めない一方で、HTTP GETのみエンドユーザー近傍で処理可能となり、応答速度を向上できる。 ただし、エンドユーザーには古いデータを表示する可能性をアプリケーション仕様として組み込む必要がある。 また、ここまでHTTPリクエストとレスポンスの往復をひとかたまりのトランザクションとする前提を置いているが、エンドユーザーが操作するクライアント側で複数のHTTPの往復をトランザクションとして扱うようなアプリケーションの場合、一貫性を維持できない問題が発生する。

図4: HTTPメソッドフォワーディング

エッジ上の複製またはキャッシュをいかに同期するかについては、定期的にクラウド側の複製またはキャッシュをエッジへ転送し同期する素朴な手法がある。 しかし、クラウドから各エッジに転送するときに、完全な複製またはキャッシュをすべて転送するとネットワーク帯域を消費するという課題がある。 この課題に対して、エッジとクラウド間の差分のみを転送したり、P2Pファイル転送のようにエッジ間で転送することにより、クラウドのネットワーク帯域消費を軽減しつつ、同期速度を高速化できる可能性がある。

分散バッファプール

構成パターン(a)について、エッジ上のデータベースサーバをクエリ解析器とバッファプールのみを配置し、クラウド上にストレージファイルを配置することを考える。 バッファプールはRDBMSが内蔵するメモリ上のデータ構造であり、バッファプールを前段に配置することにより、バッファプール上に配置されているデータの参照をエッジ内で完結できる。

この手法の実装にはファイルシステムレベルとデータベースミドルウェアレベルの手段がある。 まず、ファイルシステムレベルでは、NFSまたはFUSEとHTTP(gRPC)により、クラウド上のストレージファイルをエッジ上のデータベースサーバがマウントする形で参照する実装がある。 次に、データベースミドルウェアレベルでは、MySQLのInnoDBストレージエンジンを改変し、バッファプールとストレージファイルアクセス部分をネットワーク分離できるようにする実装がありえる。

バッファプール上のデータの一貫性の維持についての議論は、バッファプールをキャッシュとみなすと、分散クエリキャッシュと同様になる。 したがって、エッジ間のバッファプールの一貫性をより強く維持しようとするとスループットが低下する可能性があるため、結果整合性モデルを採用し、HTTPメソッドフォワーディングによりスループットを向上できる。

適応的クラスタメンバー管理

これまで述べてきたように、結果整合性を採用すると、アプリケーション仕様やコードでの一貫性の考慮が必要となるため、アプリケーション開発者に負担を強いる。 そこで、より強い一貫性モデルを前提としつつも、全体のスループットの低下を軽減できないかを考える。 提案する手法は、他のエッジやクラウドとのネットワーク疎通が不安定であるかまたは、レイテンシが大きいエッジノードを自動でサービスアウトし、一貫性維持のための書き込み同期待ち時間を軽減し、スループットの低下を防ぐというものになる。

具体的には、サービスレベル目標(SLO)として、全体スループットまたはキャッシュエントリ更新時の待ち時間を設定し、システム運用時にSLOを下回ったときに、低下要因のエッジを検出し、当該エッジをサービスアウトする。 問題のあるエッジ検出のために、常にエッジ間のレイテンシをモニタリングし、サービスアウト候補をリストしておく。 ただし、この仕組みにより、エッジ数を減少させる方向に最適化された結果、エンドユーザーへの応答が結果的に遅くなるのでは本末転倒である。 そこで、エンドユーザーへの応答時間をモニタリングし、既定値を上回ることがあれば、最も応答時間の回復に適したエッジを選出し、サービスインするといったフィードバック制御をかけることを考えている。

適応的クラスタメンバー管理は、数多くのエッジが広域に分散しているためエッジを前提として、サービスアウトしてもユーザーとのレイテンシ以外の信頼性に影響がないことに着目している。 さらに、エンドユーザーとのレイテンシ、全体スループットといった信頼性に関わる複数の指標値があることに着目し、SRE(Site Reliability Engineering)の考え方を適用している。

まとめと今後の課題

本記事では、エッジコンピューティング環境を活かすためのウェブアプリケーションホスティング構成のパターンを考察し、課題を整理し、課題を解決するためのアイデアを示した。 提案したアイデアは、分散クエリキャッシュ、分散バッファプール、結果整合性のためのHTTPメソッドフォワーディング、より強い整合性のための適応的クラスタメンバー管理である。

本記事の内容を研究所内で発表したところ、エッジコンピューティング領域の用語について業界内で厳密に定義できていないこと、リアルタイムアプリケーションの応答時間目安、ウェブアプリケーション性質の分類(想定アクセスパターンの整理)、P2Pでの関連研究、超個体型データセンターに向けて、一箇所に書き込みを集中しなくてよいようなアプリケーション特性などについて議論した。 超個体型データセンターの観点では、データ一貫性という集中構造を要求する分散システムの原則と、エッジコンピューティングという分散構造への要求をいかに両立するかというところがこれから重要となってくる。 今後は、CDN、P2P、地理分散データベース、広域分散、ブロックチェーンなどの関連する分野の先行研究のサーベイを進め、研究開発の立ち位置を明確にしつつ、実装と評価を進めていく予定である。

参考文献


  1. Bilal Kashif, Khalid Osman, Erbad Aiman, Khan Samee U, “Potentials, Trends, and Prospects in Edge Technologies: Fog, Cloudlet, Mobile edge, and Micro data centers.”, Computer Networks, vol. 130, pp.94-120, 2018.

  2. Flavio Bonomi, Rodolfo Milito, Jiang hu, and Sateesh Addepalli, “Fog Computing and Its Role in the Internet of Things.”, first edition of the MCC workshop on Mobile cloud computing, pp.13-16, 2012.

  3. Mahadev Satyanarayanan, Paramvir Bahl, Ram'on Caceres, and Nigel Davies, “The Case for VM-based Cloudlets in Mobile Computing.”, IEEE Pervasive Computing, vol. 4, pp.14-23, 2009.

  4. Michael Till Beck, Martin Werner, and Sebastian Schimper Feld, Mobile edge computing: A Taxonomy, Sixth International Conference on Advances in Future Internet (AFIN), pp.48-55, 2014.

  5. V. Avelar, Practical Options for Deploying Small Server Rooms and Micro Data Centers, Revision 1, White Paper [online] Available: http://www.datacenterresearch.com/whitepaper/practical-options-for-deploying-small-server-rooms-and-micro-9014.html, 2016.

  6. Douglas B. Terry, Alan J. Demers, Karin Petersen, et al., “Session Guarantees for Weakly Consistent Replicated Data”, 3rd International Conference on Parallel and Distributed Information Systems (PDIS), 1994.

  7. Douglas B. Terry, “Replicated Data Consistency Explained Through Baseball,” Microsoft Research, Technical Report MSR-TR-2011-137, 2011.

  8. Charles Garrod, Amit Manjhi, Anastasia Ailamaki, Bruce Maggs, Todd Mowry, Christopher Olston, and Anthony Tomasic, “Scalable Query Result Caching for Web Applications”, VLDB Endowment, vol. 1, no. 1, pp.550-561, 2008.