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

はじめに

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.

2019年SRE考

この記事では、自分が数年Site Reliability Engineering (SRE)を実践しつつ、SREについて考えてきたことをまとめる。 先月開催されたMackerel Drink Up #8 Tokyoと先日開催された次世代Webカンファレンス 2019では、SREについて集中的に議論する機会に恵まれたため、脳内メモリにキャッシュされているうちにを文章としてまとめておこうと考えた。

(以降では、SRE本の原著にならい、技術領域名を指すときはSRE、職種名を指すときにSREsと表記する。)

SREとの関わり

なぜSREに関心をもったのか

2015年にメルカリさんがSREチームを発足したときに、SREsの存在を知り、SREsはシステム管理者、Webオペレーションエンジニア、インフラエンジニアといった既存の職種を置き換えていくものだと理解した。 当時、自分が注目したのは、SREsの仕事領域にソフトウェアエンジニアリングが含まれることと、業務時間に対してソフトウェアエンジニアリングが占める割合だった。 2014年前後では、SREsの存在が知られる前から、Infrastructure As Codeなどの概念の登場により、これからのインフラエンジニアは単にオペレーションをする人ではなく、コードを書いていくのだという認識が広まっていたと思う。

しかし、頭の中ではコードを書くことを認識していても、実際にソフトウェアエンジニアリングをやれている理想の状態と現状ではギャップがあった。 そこで、理想の状態を体現しているであろうGoogleやFacebookなどの企業が具体的なソフトウェアエンジニアリング時間の割合にまで言及していたことが自分の印象に残っていた。

また、SREを調べているうちに、システムの信頼性を100%にはできないという前提に基づき、エラーバジェットという自分にとっては新しい考え方を発見した。 これにより、最初のSREの印象は、これまで定性的であったシステム運用に関する意思決定材料を、定量化するための方法論であるという印象ももったことも覚えている。

SRE本

しばらくして、2016年にはGoogleのSREsがSRE本の初版を出版した。 Web上の言説だけではSREをよく理解できていないと感じていたため、当時自分がもっていたソフトウェアエンジニアリングに集中するにはどうするかという問題意識を解決するために、主要な章を社内で輪読した。

輪読により、信頼性の具体的定義と指標であるSLI/SLO、SREsの日々のタスク分類(Software Engineering、System Engineering、Toil、Overhead)といった方法論を学んだ。 その結果、Googleのような先進的企業であっても、定常的な作業(Toil)をゼロにはできないし、ToilやOverheadが膨れ上がらないようにエンジニアリングに費やす時間を管理する組織的な方法論まで議論していることに親近感を覚えた。

さらにその翌年の2017年に日本語の翻訳書が出版された。 原書を読んだときは、答えを探すような気持ちで方法論をいかに自分の環境に適用できるかといった視点でしか読んでいなかった。 しかし、母語で読めたおかげか、見逃していたSREsの先人達の思いのようなものを感じ取れた。 特に序文、はじめに、1章では、なぜSREのような概念を構築するに至ったのかを知ることができる。

自分が考えるSRE

自分なりの問題意識とそれを解決するためのSREの概念の学習とその実践を通して、自分が考えるSREというものが徐々にできあがってきた。 以降では、自分が考えるSREとはなにかを書いていく。

SREとはなにか

SRE本の「はじめに」には、次のように書かれている。

それでは、サイトリライアビリティエンジニアリング(SRE)とはいったい何なのでしょうか。 この名前が、その内容をはっきりとは表現できていないことは認めざるをえません。

このあとに、説明が続いていくのだが、現時点では、一言で言い切るのは難しい。

もし自分が誰かにSREとはなにかと聞かれたら、今なら「サイト信頼性を"制御"するための技術」と答える。 ここでいう制御とは、信頼性を向上させることもできるし、維持することもできるし、低下させることもできることを指す。 過去にSREについて説明したときは、前者2つを説明することが多かった。

しかし、自分は、信頼性をあえて低下させることを前提とした方法論に着目した。 一般的な感覚でいえば、信頼性を下げるなんてありえないと思うかもしれないが、SRE本には、信頼性100%は基本的に達成不可能であるというドライな原則をもとに、4章ではSLOの過剰達成を避けるということが紹介されている。 実際、そんなに高い信頼性はいらないんじゃないかと思うことも正直あった。 信頼性と変更速度はトレードオフとなることがあり、障害の主な原因はヒューマンエラーであることを考えると、目先の信頼性をとりあえず向上させたければ、システムに変更を加えないほうがよいことになる。 これまでの自分の経験では、信頼性が低くて困るというよりはむしろ、暗黙的に信頼性100%を目指してしまい、システムを変更したいのに信頼性を低下させる過剰な恐れがあって万全を期すために変更が遅くなったり、そもそも変更しなかったりすることに困っていたことが多かった。 システムの変更には、そのあとの変更を速くするものも含まれるために、変更しないことにより、さらなる変更速度の低下をまねいてしまうことがある。

そうはいっても、ユーザーに明確に不便を感じさせるほど、信頼性を低下させるわけにはいかない。 システムの変更に対して、どこまで影響がでるかわからなかったり、問題があってもすぐに気づけない可能性があるなかで、変更を加えることは博打のようなものである。 しかし、変更影響が限られていたり、変更に対するテストがあったり、問題にすぐ気づけたり、問題があっても自動復旧できたり、その後の根本対策ができる体制があったりすることで、安心して変更できるようになる。 安心して変更できるのであれば、変更速度はあがっていくはずである。 このように、後述する信頼性の階層により信頼性を制御するための構造を構築しておくことで、信頼性を"制御"できている状態で、変更速度を高めていける。 100%の信頼性を構築することは難しいが、エラーを許容する前提があれば、あとは程度の問題ということになる。

信頼性とSLI/SLO

信頼性にはいくらかの定義のしようがある。 SRE本は、書籍"Practical Reliability Engineering"の定義である「システムが求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率」を採用している。

SLIとSLOを適切に設定することは、SREを実践する上で最も重要である。 しかし、SLIが妥当かどうかを確かめることとSLOを計測することが難しいこともある。 例えば、SRE本では、SLIの例としてサービスのレイテンシが挙げられている。 レイテンシと一口にいってもリクエスト数は膨大なので、統計的な値を用いる必要があり、平均値なのか、中央値なのか、95パーセンタイルなのか、99パーセンタイルなのかといった選択肢がある。 さらに、リクエストの中にはロードバランサからのヘルスチェックや、ウェブクローラーからのリクエストなど、種類の異なるリクエストがある。 加えて、エンドポイントによってレイテンシの差が大きい場合に、エンドポイントごとにレイテンシを計測するか、まとめてしまうのかといった選択肢がある。

SLI/SLOがないとSREは始まらないので、ターゲットとなるシステム単位で、時間ベースの可用性目標やMTTR(Mean Time To Recovery)、障害発生回数など計測が比較的簡単なものから計測しはじめるとよいと思っている。 そこから、四半期ごとなど定期的にSLI/SLOが適切かをプロダクトオーナーとSREsが見直していけばよい。 SLI/SLOの設計の具体的な例などは、書籍The Site Reliability Workbook*1が詳しい。

信頼性の階層

(Betsy Beyer et. al.編, "SRE サイトリライアビリティエンジニアリング", オライリージャパン, p108図III -1サービスの信頼性の階層)

信頼性を計画的に構築するには、上記のような信頼性階層を構築する必要がある。 まず、信頼性構築のための基盤となるのが、信頼性を測定する手法としてのモニタリングだ。 これがなければ、サービスがReliableな状態にあるのかがそもそもわからないし、監視項目にもれがあれば、ユーザーに影響があるのにそれに気づけていないことになる。 信頼性を高めたいもしくは安心して変更していきたいという問題意識がある場合、まずは、モニタリングから見直し、この階層の下から上で登っていくとよいと思う

信頼性と変更速度の両立

先に、信頼性と変更速度はトレードオフとなると書いたが、ソフトウェアエンジニアリングによりこれらを両立できることがある。 人間の動作時間は計算機の動作時間に比べて遅いため、復旧時間を短くするには、オペレーションをできるだけソフトウェアに任せるのが筋が良い。 仮にSLIとしてMTTRが設定されているとすると、ソフトウェアエンジニアリングにより信頼性が向上していると言える。 オペレーションが自動化されていると、普段の変更も高速化し、結果として信頼性と変更速度のそれぞれの向上を両立できると言える。

SREがエンジニアリングのなかでもソフトウェアエンジニアリングを重視しているのは、トレードオフの解決のためであると考えている。

変更速度の計測

信頼性が十分高い状態であれば、次は変更速度を計測する必要がでてくる。 変更速度が計測できていないと、信頼性を高くできているがそのために労力をかけすぎているケースに気づけない可能性がある。

そこで、SRE本に書かれているように、SREが、ソフトウェアエンジニアのチームが従来のシステム管理を再構成したものととすると、もともとソフトウェアエンジニアがやっているプロダクト開発のアプローチに着目した。 DevOpsの文脈においても、プロダクト開発(Dev)のアプローチである継続的インテグレーションなどがOpsにて採用されていった経緯もある。

変更速度を計測するために、アジャイル開発の手法をとりいれたことがある。 具体的には、プロダクト開発と同様に、ビジョンを設定し、機能開発のためのロードマップを設定し、スプリントごとにバックログを積み、プランニングポーカーによりバックログに見積もりポイントを設定し、ベロシティを計測するといったものだ。(僕は、書籍アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ だけを読んでアジャイル開発を勉強した。) 直接の経緯としては、SRE本にはToilの割合は50%以下に抑えよというプラクティクスがあり、Toilの割合がどの程度かを確認する必要があった。 しかし、Toilは短時間である、割り込みである、数が多い、またはToilとEngineeringの区別は実は難しいといったように計測が難しくなるような性質をもつ。 したがって、直接Toilを計測するのではなく、ベロシティを計測することにした。 ベロシティが低下したスプリントには、どんな要因があったかを確認し、その要因を取り除くようなタスクをバックログに積んだりもしていた。 要はやりたいことができていればよいので、それらを直接的に計測しようということである。

これらは横串のプラットフォームチームとしての取り組みだったが、サービス開発チームにおいても同様だと思う。 サービス開発チームにおいては、すでにプロダクトオーナーが存在し、オーナーがロードマップを決定していることもある。 そのときは、SREとしてのロードマップも、プロダクトのロードマップに組み込むという考え方になる。

信頼性と費用

変更速度以外にも、信頼性(レスポンスタイム)と費用のトレードオフがある。 例えば、インスタンスサイズを大きめにしたり、インスタンスの個数を大きめにしたりすると、突発的な負荷に耐えやすくなり、信頼性は向上する。 しかし、キャパシティを余分にもつことで費用は高くなってしまうということがある。

クックパッドさんの事例では、実験をした上で、ユーザー影響を定量化し、プロダクトオーナーとの協議の末、あえてGPUからCPUに移行されていた。 本番/ステージング環境GPUぼくめつ大作戦 - クックパッド開発者ブログ これは、信頼性を制御した上で、費用を削減するというSREの取り組みの例といえる。

技芸から工学へ

書籍「ウェブオペレーション」では、まえがきにて著者が次のように述べている。

ウェブオペレーションは技芸であり、科学ではない。 正規の学校教育・資格・標準は(少なくとも今はまだ)ない。 我々のやっていることは、学習にも習得にも時間がかかり、その後も自分自身のスタイルを模索しなければならない代物である。 「正しい方法」はどこにも存在しない。 そこにあるのは、(とりあえず今は)うまくいくという事実と、次はもっと良くするという覚悟だけだ。

一方で、SRE本では、序文にて著者の一人であるMark Burgess*2は次のように述べている。

Principles of Network and System Administration[Bur99]の導入部で、システム管理はヒューマンコンピュータエンジニアリングの形の一つだと私は主張しました。 レビューアの中には「まだそれはエンジニアリングと呼べるほどの段階には来ていない」と強く否定する人もいました。 この時点では、私はこの分野は見失われて、独自の魔術師的な文化にとらわれ、進むべき方向が見えなくなっていると感じていました。 しかし Google は明確に線を引き、来たるべきシステム管理の姿を現実の存在にしたのです。 そして見直された役割がSRE、すなわちSite Reliability Engineerと呼ばれるものでした。

"エンジニアリングと呼べるほどの段階には来ていない"、"独自の魔術的な文化"という言葉が指すのは、前述でいうところの技芸にあたると解釈している。 自身の経験においても、古いバージョンのMySQLクラスタの切り替え作業を曲芸のようなオペレーションで乗り切ることもあった。*3

SREの登場により、技芸(Art)から工学(Engineering)へと移り変わる兆しがみえてきたように思う。

工学と技術 | Adachi Lab.

最初は、工学ではなく科学と書いていたが、科学は文献によっては理学のみを指すこともあるようなので、工学とした。 SREのEはEngineeringなので、工学なのは当たり前なのだが、これまではエンジニアリングといいつつも、技芸やテクニックのみになりがちであったように思う。 とはいっても、技芸が不要ということではなく、これからは、工学と技芸の両輪で回していくことになると考えている。

まとめと今後

この記事では、自分がSREに関心をもった経緯と解釈の変遷、自分なりのSREのあり方をまとめた。 このように、信頼性を軸に据えることにより、我々のやっていること、やろうとしていることをずいぶん体系だてて説明できるようになったと感じている。 ウェブオペレーションでは、ネットワーク・ルーティング・スイッチング・ファイアウォール・負荷分散・高可用性・障害復旧・ TCPやUDPのサービス・NOCの管理・ハードウェア仕様・複数のUnix環境・複数のウェブサーバ技術・キャッシュ技術・データベース技術・ストレージインフラ・暗号技術・アルゴリズム・傾向分析・キャパシティ計画立案などの技術を組み合わせて、システムを運用する。 しかし、我々はデータベースの開発者ではないし、BGPオペレーターでもないし、OS開発者でもないし、ハードウェア技術者でもない。 では何をする人なのかというと、今ではSREの専門家といえばよい。*4

今後は、2019年の展望でも紹介した「故人の跡を求めず 故人の求めたるところを求めよ」という言葉でいうと、単に方法論を適用するだけに留めず、SREsの先人の求めたるところを求めていきたい。 組織としては、工学としてのアプローチをとりいれていくことになるだろうし、巨大クラウド事業者のサービスの発展により全員がSREをやっていくことになると思う。 そんな中で、今SREsである人たちは、要素技術がクラウド事業者に取って代わっていき、良くも悪くも仕事が減っていく中で、SREをどうやって楽しんでいくかというところが重要になってくるだろう。 ウェブの世界での技術の進化の方向性としては、ウェブシステムの運用自律化に向けた構想 - 第3回ウェブサイエンス研究会 - ゆううきブログに私見をまとめている。 他には、システムのすべてが機械により自律制御されるビジョンに対するアンチテーゼとして、あんちぽさんの なめらかなシステムを目指して が参考になる。 また、自分自身としては、分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから - 人間とウェブの未来に書かれているようなウェブの下の階層にて、分散型データセンターのような新しい基盤を前提にSRE Researcherをやっていくことになると思う。

最後に、SRE本の書評や読み方として、自分の考えに近いものをみつけたので以下にリンクを紹介しておく。

次世代Webカンファレンス2019での、@kanny@deeeetと議論した様子は 録画で視聴できる。

*1:まだ部分的にしか読めていない

*2:PuppetやChefの前身であるCFEngineの作者

*3:当時は同僚とMySQL4曲芸と呼んでいた

*4:それまでもウェブオペレーションの専門家と言えていたのではあるのだけども、ウェブオペレーションの中身を説明しようとするととたんに難しくなる

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さんには、お忙しい中、時間をとっていただいて快く指導していただいたこと、指導いただかなければ論文として形にならなかっただろうということと、指導いただいている間に成長を実感できたことに大変感謝しています。

TCP接続の追跡による簡略化したネットワーク依存関係グラフの可視化基盤

はじめに

ウェブシステムは,一般的に,分散したホスト上で動作するソフトウェアが互いにネットワーク通信することにより構成される. 相互にネットワーク通信するシステムにおいて,システム管理者があるネットワーク内のノードに変更を加えた結果,ノードと通信している他のノードに変更の影響がでることがある. ネットワーク接続数が多いまたはノードが提供するサービスの種類が多くなるほど,システム管理者が個々の通信の依存関係を記憶することは難しくなる. さらに,常時接続しておらず必要なタイミングで一時的に通信するケースでは,あるタイミングの通信状況を記録するだけでは通信の依存関係を把握できない. その結果,システムを変更するときの影響範囲がわからず,変更のたびに依存関係を調査しなければならなくなるという問題がある.

先行手法では,ネットワーク内の各ノード上で動作するiptablesのようなファイアウォールのロギング機構を利用し,TCP/UDPの通信ログをログ集計サーバに転送し,ネットワークトポロジを可視化する研究[1]がある. 次に,tcpdumpのようなパケットキャプチャにより,パケットを収集し,解析することにより,ネットワーク通信の依存関係を解析できる. さらに,sFlowやNetFlowのように,ネットワークスイッチからサンプリングした統計情報を取得するツールもある. また,アプリケーションのログを解析し,依存関係を推定する研究[2]がある. マイクロサービスの文脈において,分散トレーシングは,各サービスが特定のフォーマットのリクエスト単位でのログを出力し,ログを収集することにより,リクエスト単位でのサービス依存関係の解析と性能測定を可能とする[3].

しかし,ファイアウォールのロギング機構とパケットキャプチャには,パケット通信レイテンシにオーバーヘッドが追加されるという課題がある. さらに,サーバ間の依存関係を知るだけであれば,どのリッスンポートに対する接続であるかを知るだけで十分なため,パケット単位や接続単位で接続情報を収集すると,TCPクライアントのエフェメラルポート単位での情報も含まれ,システム管理者が取得する情報が冗長となる. 分散トレーシングには,アプリケーションの変更が必要となる課題がある.

そこで,本研究では,TCP接続に着目し,アプリケーションに変更を加えることなく,アプリケーション性能への影響が小さい手法により,ネットワーク通信の依存関係を追跡可能なシステムを提案する. 本システムは,TCP接続情報を各サーバ上のエージェントが定期的に収集し,収集した結果を接続管理データベースに保存し,システム管理者がデータベースを参照し,TCP通信の依存関係を可視化する. まず,パケット通信やアプリケーション処理に割り込まずに,netstatのような手段でOSのTCP通信状況のスナップショットを取得する. 次に,ネットワークグラフのエッジの冗長性を削減するために,TCPポート単位ではなく,リッスンポートごとにTCP接続を集約したホストフロー単位でTCP通信情報を管理する. さらに,ネットワークグラフのノードの冗長性を削減するために,ホスト単位ではなくホストの複製グループ単位で管理する. 最後に,過去の一時的な接続情報を確認できるように,接続管理データベースには時間範囲で依存関係を問い合わせ可能である.

提案システムを実現することにより,システム管理者は,アプリケーションへの変更の必要なく,アプリケーションに影響を与えずに,ネットワーク構成要素を適切に抽象化した単位でネットワーク依存関係を把握できる.

提案手法

システム概要

図1に提案手法の外観図を示す.

図1: 提案手法の外観図

提案システムの動作フローを以下に示す.

  1. 各ホスト上のエージェントが定期的にTCP接続情報を取得する.
  2. エージェントはCMDB(接続管理データベース)のホストフロー情報を送信する.
  3. システム管理者はアナライザーを通して,CMDBに格納されたホストフロー情報を取得し,解析された結果を表示する.

これらのフローにより,システム管理者が管理するシステム全体のネットワーク接続情報をリアルタイムに収集し,集中管理できる.

ホストフロー集約

個々のTCP接続情報は,通常<送信元IPアドレス,送信先IPアドレス,送信元ポート,送信先ポート>の4つの値のタプルにより表現する. ホストフローは,送信元ポートまたは送信先ポートのいずれかをリッスンポートとして,同じ送信元IPアドレスとを送信先IPアドレスをもち,同じリッスンポートに対してアクティブオープンしている接続を集約したものを指す. ホストフローの具体例は次のようになる.

Local Address:Port   <-->   Peer Address:Port     Connections
10.0.1.9:many        -->    10.0.1.10:3306        22
10.0.1.9:many        -->    10.0.1.11:3306        14
10.0.2.10:22         <--    192.168.10.10:many    1
10.0.1.9:80          <--    10.0.2.13:many        120
10.0.1.9:80          <--    10.0.2.14:many        202

接続管理データベース

CMDBは,ノードとホストフローを格納する. ノードは,ユニークなIDをもち,IPアドレスとポートが紐付けられる. ホストフローは,ユニークなID,アクティブオープンかパッシブオープンかのフラグ,送信元ノード,送信先ノードをもつ.

アナライザー

アナライザーがCMDBに対して問い合わせるパターンは次の2つである.

  • a) ある特定のノードを指定し,指定したノードからアクティブオープンで接続するノード一覧を取得する
  • b) ある特定のノードを指定し,指定したノードがパッシブオープンで接続されるノード一覧を取得する

実装

概要

提案手法を実現するプロトタイプ実装であるmftracerをGitHubに公開している.https://github.com/yuuki/mftracer mftracerの概略図を以下に示す.

+-----------+
| mftracerd |----------+
+-----------+          | INSERT or UPDATE
                       V
+-----------+         +------------+
| mftracerd |------>  | PostgreSQL |
+-----------+         +------------+
                       ^       | SELECT
+-----------+          |       |            +----------+
| mftracerd |----------+       | <--------- | Mackerel |
+-----------+                  v            +----------+
                          +--------+  
                          | mftctl |
                          +--------+

ロールと実装の対応表を以下に示す.

ロール名 実装名
agent mftracerd
CMDB PostgreSQL
analyzer mftracer

mftracerでは,予め各ホストをMackerelに登録し,サービス・ロール[4]という単位でグルーピングを設定しておくことにより,mftctlがホスト単位ではなく,サービス・ロール単位でノードを集約し,扱うことができる.

使い方

mftracerの使い方の例を以下に示す.mftracerはmftctlコマンドにより,CMDBに接続し,引数で指定した条件に応じてネットワークグラフを表示する.

$ mftctl --level 2 --dest-ipv4 10.0.0.21
10.0.0.21
└<-- 10.0.0.22:many (connections:30)
└<-- 10.0.0.23:many (connections:30)
└<-- 10.0.0.24:many (connections:30)
    └<-- 10.0.0.30:many (connections:1)
    └<-- 10.0.0.31:many (connections:1)
└<-- 10.0.0.25:many (connections:30)
...
$ mftctl --level 2 --dest-service blog --dest-roles redis --dest-roles memcached
blog:redis
└<-- 10.0.0.22:many (connections:30)
└<-- 10.0.0.23:many (connections:30)
└<-- 10.0.0.24:many (connections:30)
    └<-- 10.0.0.30:many (connections:1)
    └<-- 10.0.0.31:many (connections:1)
└<-- 10.0.0.25:many (connections:30)
blog:memcached
└<-- 10.0.0.23:many (connections:30)
└<-- 10.0.0.25:many (connections:30)
...

 ホストフロー

プロトタイプでは,netstatとssコマンドで利用されているLinuxのNetlink APIを利用して,TCP接続情報を取得している. TCP接続を集約表示するlstfでNetlinkにより実行速度が1.6倍になった - ゆううきメモ

各接続の方式がアクティブオープンかパッシブオープンかを判定する実装は次のようにになっている.

  1. Netlink APIによりTCP接続情報を取得する
  2. LISTENステートの接続のローカルポートのみ抽出
  3. 1.と2.を突き合わせ,接続先ポートがリッスンポートであればアクティブオープン,それ以外の接続はパッシブオープンと判定する.

CMDBのスキーマ

CBDBのスキーマ定義を以下に示す.

CREATE TYPE flow_direction AS ENUM ('active', 'passive');

CREATE TABLE IF NOT EXISTS nodes (
    node_id bigserial NOT NULL PRIMARY KEY,
    ipv4    inet NOT NULL,
    port    integer NOT NULL CHECK (port >= 0)
);
CREATE UNIQUE INDEX IF NOT EXISTS nodes_ipv4_port ON nodes USING btree (ipv4, port);

CREATE TABLE IF NOT EXISTS flows (
    flow_id                 bigserial NOT NULL PRIMARY KEY,
    direction               flow_direction NOT NULL,
    source_node_id          bigint NOT NULL REFERENCES nodes (node_id) ON DELETE CASCADE,
    destination_node_id     bigint NOT NULL REFERENCES nodes (node_id) ON DELETE CASCADE,
    connections             integer NOT NULL CHECK (connections > 0),
    created                 timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated                 timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

    UNIQUE (source_node_id, destination_node_id, direction)
);
CREATE UNIQUE INDEX IF NOT EXISTS flows_source_dest_direction_idx ON flows USING btree (source_node_id, destination_node_id, direction);
CREATE INDEX IF NOT EXISTS flows_dest_source_idx ON flows USING btree (destination_node_id, source_node_id);

nodesテーブルはノード情報を表現し,とflowsテーブルはホストフロー情報を表現する.

実装の課題

  • ネットワークトポロジの循環に対する考慮
  • クラウド事業者が提供するマネージドサービスを利用している場合,IPアドレスから実体をたどることの困難
  • パターンa)の実装
  • 時間範囲を指定した依存関係の取得

むすび

システムの複雑化に伴い,システム管理者が個々のネットワーク通信の依存関係を記憶することが難しくなっている. そこで,アプリケーションを変更せずに,アプリケーションに影響を与えることなく,適切な抽象度で情報を取得可能な依存関係解析システムを提案した. 実装では,Go言語で書かれたエージェントがLinuxのNetlink APIを利用し,RDBMSにホストフロー情報を格納し,Go言語で書かれたCLIから依存関係を可視化できた.

今後の課題として,問題の整理,サーベイ,評価がある. 問題の整理では,ネットワークの依存関係といっても,OSI参照モデルにおけるレイヤごとにシステム管理者が必要とする情報は異なるため,最終的にレイヤ4のTCP通信に着目する理由を明らかにする必要がある. サーベイについては,ネットワークの依存関係解析に関する先行研究は多岐に渡るため,調査し、本研究の立ち位置を明確にする必要がある. 評価については,先行手法となるファイアウォールロギングとパケットキャプチャによるレイテンシ増大による影響を定量評価し,提案手法の優位性を示す必要がある. また,実装では,すべての接続情報を取得できるわけではないため,接続情報の取得率を確認し,実運用において,十分な精度であることを確認する必要がある. さらに将来の展望として,同じような通信をしているホストをクラスタリング推定し,システム管理者がより抽象化された情報だけをみて依存関係を把握できるようにしたい. また,コンテナ型仮想化環境での依存関係の解析への発展を考えている.

参考文献

  • [1]: John K Clawson, "Service Dependency Analysis via TCP/UDP Port Tracing", Master thesis, Brigham Young University, 2015
  • [2]: Jian-Guang LOU, Qiang FU, Yi WANG, Jiang LI, "Mining dependency in distributed systems through unstructured logs analysis", ACM SIGOPS Operating Systems Review, 2010, vol 44, no 1, pp. 91
  • [3]: @itkq, "サービスのパフォーマンス数値と依存関係を用いたサービス同士の協調スケール構想", 第1回Web System Architecture研究会, https://gist.github.com/itkq/6fcdaa31e6c50df0250f765be5577b59
  • [4]: id:masayoshi, "ミドルウェア実行環境の多様化を考慮したインフラアーキテクチャの一検討", 第2回Web System Architecture研究会,https://masayoshi.hatenablog.jp/entry/2018/05/19/001806

発表スライド

質疑応答

発表時の質疑応答では,次のような議論をしました.

まず,接続が観測されたホストでも実はトラヒックはほとんど流れていなくて接続しているだけで,実際は利用していないホストであったりすることがある。提案手法は(分散トレーシングのようなより小さなリクエスト単位で追跡する手法と比較して)真の依存をみていないのではないか?という質問がありました.議論した結果の回答としては,どちらの手法が真かそうでないかというわけではなく,要件の違いにより,要件を満たす手法がかわってくるという話であると考えています.例えば,先行手法では,直接エンドユーザーへの影響のある接続を詳細に可視化することはできるが,システム管理のための接続(LDAP,SSHなど)を見落とすことがあります.

次に,UDPには対応しないのか?という質問がありました. UDPにはおそらく対応可能で,今の所はTCPのみサポートしています. ネットワーク層以下の依存関係可視化については,数多くの先行研究があります. アプリケーション層についても,ここ数年で多くの手法が提案されています. 一方で,トランスポート層に着目した依存関係の可視化の提案は少ないように思います. そこで,UDPに対応させ,トランスポート層の依存関係を満遍なく分析できる基盤という立ち位置を確保していくといいのではないかという議論をしました.

さらに,1日1回といった頻度で依存関係情報を収集するのではなく,リアルタイムに収集できるため,異常検知などに利用できるのではないかというアイデアもいただきました. あらかじめシステム管理者があるべき依存関係を設定しておき,その設定に反した通信を検知すると異常とみなすといった手法など,新しい監視手法を提案できるかもしれません.

また,Dockerのようなコンテナ環境であればリッスンポートが再起動するたびに変化していくため,ポート単位で追跡する手法は向いていないのではないかという質問もありました. 現在の提案手法では,IPアドレスとポートの組をノードとして扱っており,IPアドレスのほうはロールのようにグルーピングして扱えるようになっています. そこで,接続先のポート集合に名前をつけて管理するような仕組みが必要になってくるのではと考えています. エンドポイントの管理の課題として,他にもVIPのように実態のIPアドレスと異なるエンドポイントを利用することもあるため,仮想的には同じエンドポイントを参照していても,実態としてはエンドポイントが変化している問題を一般化して解くような提案を考えていくのが望ましいでしょう.

その他,エージェントをインストールするだけで使える導入の容易さも重要ではないかという指摘もいただきました.

あとがき

今回のWSA研も前回前々回と同様に,参加者の各種アイデアに対して,みんなで白熱した議論を展開するという流れになりました. みんな話をしたいことが多すぎて,いつも以上に,議論時間が長くなりました. 会場をご提供いただいたレピダムさんに感謝します.9人で議論するのにちょうどよいかつきれいな会議室で快適に過ごすことができました.

WSA研の特徴として,Web技術が主体でありながらも,隣接する技術領域の議論が飛び出してくることが挙げられます. 社内であったり,いつもの勉強会であれば,なんとなく要件が似通っていて,同じようなコンテキストで話をしていることが多いでしょう. 一方で,この研究会では,技術者と研究者が交わり,議論による創発を目指しているため,例えば,メールやIoTのような、いつものWebとは異なる要件をもつシステムに対しても,Webの技術を応用し,議論することにより,共通点や差異を理解し,新たなアイデアがでてくるといった場面があります. 僕自身はWSA研を開催するたびに,モチベーションがあがるということを体感しているため,これからも継続して開催していきたいと考えています.次回は4/13(土)で京都開催の予定です.