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

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

Data Intensive Caching Distributed Edge Computing

はじめに

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.↩