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

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

Edge Computing Data Intensive

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

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

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