EdgemenshがP2Pアクセラレーションサービスを運用向けにロールアウト

Edgemeshは、WebRTCプロトコルスイートをベースとした、P2PのWebアクセラレーションサービスである。従来ならばCDNで処理されるようなトラフィックの一部を、P2Pネットワーク上で共有されるブラウザベースのキャッシュにオフロードする機能を提供する。数ヶ月前に運用レベルでのリリースが行われたことで、体験の共有が可能になった。

Edgemeshが技術面で依存するのは、エンドユーザのブラウザがWebRTCプロトコルスイートを使用して作成する“オーバーレイ”ネットワークである。従来のCDNでは、世界中にエッジロケーションを持ち、ユーザに最も近接したロケーションからコンテンツを提供することでレイテンシを低減している。これに対してEdgemeshでは、ユーザのブラウザが一般的に使用するコンテンツキャッシュを二次キャッシュとして使用することで、CDNのエッジロケーションからではない、ブラウザ同士の通信によるコンテンツの提供を実現している。Edgemeshを有効にするには、WebページにJavaScriptのスニペットを含めておく必要がある。従って運用時には、Edgemeshのクライアント用JavaScriptが、複数の地域にわたって、潜在的に数千のブラウザ上に存在していることになる。このオーバレイネットワークが“メッシュ(mesh)”なのだ。

Edgemeshは、デプロイメントの基本ユニットとしてDockerコンテナを使用する。インフラストラクチャは仮想マシン上ではなく、SmartOSゾーンのJoyentパブリッククラウド上で、物理的なハードウェアを使って動作する。コンテナ管理にはJoyentのAutopilotパターンを使用して、コンテナの高度な操作自律性を実現している。Tritonを使えば、データベースシステムをコンテナ内で実行することも可能だ。データベースファイルやログファイルなどの状態情報は、Joyent Manta経由で安定的なストレージに保管されると同時に、セカンダリバックアップとしてGoogle Storage Platformを使用している。

4月1のサービス提供開始を前にしたエンジニアリングチームは、いくつかの主要な課題を特定していた。その中には、クライアントの入力を必要としない運用エラーのデバッグ機能、時間指定によるアップデートの自動リリース、500ネットワークにわたるメッシュ、最大1TBのデータのメッシュへのオフロード、50ヶ国への展開などが含まれていた。5月26日には、メッシュへの完全なトラフィック流入が可能になった。同じ週内にはクライアントのオリジナルサーバから0.5テラバイトのデータがメッシュにオフロードされ、ユーザの平均ページロード時間の33%削減を達成している。メッシュのサイズや個々のページの読み込み時間といったメトリックは、継続的に測定され、監視されている。Edgemeshクライアントがエラーを起こした場合には、フォールバックして、ブラウザの通常操作への復帰を可能にする。エラーから収集されたデータは、分析のためにEdgemeshに報告される。

その背景でチームは、自分たちのソフトウェアを運用段階に導入するための指針として、３つのポイントを設定していた – ひとつは自動化であり、もうひとつはインフラストラクチャの定期的な再構築によって、悪意のあるエンティティからの攻撃面を削減し、一貫性を維持することだ。そして第３は、おもに他の２つの結果としての、最小インフラからの開始による経済的なスケーリングである。

InfoQはEdgemesh CorporationのCEOであるJacob Loveless氏から、運用に向けてのDevOpsの課題について詳しく聞いた。Edgemeshが使用するDockerインフラストラクチャ用の監視ツールに関する質問に、Loveless氏は次のように答えてくれた。

システム統計にはPrometheusを使用しています。また、エラーやメッセージタイプの記録(クライアントからのWebRTC統計値など)を発行する内部システムも用意されています。これらのメトリクスは、各アプリケーションがスケールアップイベントを要求するタイミングを判断するために利用されています。

コードの大部分をクライアント側に持つというEdgemeshの分散的な性質から、運用前試行(pre-production)による健全性の確保は大きな課題となる。Lovelsess氏が特に挙げたのは、ステージング(運用前試行)の設定だ。

当社では、Dockerの構築と開発環境へのデプロイを行なうための、標準的なCI/CDプラットフォームを用意しています。“ステージング”に到達したイメージはそのようにタグ付けされ、クリーンスレート(clean slate)に転送されます。当社はひとつのデータセンタを用意して、ステージングの実行と、全体のトラフィックのおよそ10%の処理を行なっています。リリースのタグ付けが可能な状態になれば、そのDockerイメージのタグを“マスタ”に変更した上で、全データセンタで運用を開始します。ロールバックが必要な場合は、単にレジストリ内のDockerイメージのタグを変更しておけば、次のクリーンスレートが実行される時にリセットされます。基本的にデプロイメントは毎日行なっていますが、ほとんどは新リリースではありません。フルリリースを運用に投入する作業は、５～10日の周期で行なっています。

ここで言うクリーンスレートとは、データセンタコンテナを毎日再生成するEdgemeshの方法である。これにより、デプロイメントに関する３原則の堅持が可能になる。

ステージングのセットアップで運用データを吸収できることと、変更のロールバックが容易なメカニズムによって、Edgemeshでは、運用時に見られるようなプロダクションロードとトラフィックパターンを部分的にシミュレートすることができる。ただし、これだけでは不十分なので、“ソフトウェアバージョンの運用への迅速な移行を可能にする”戦略を合わせて採用しているのだ、とLoveless氏は言う。

クリーンスレートの戦略のひとつとして、ベースサイズから自動的にスケールアップされたインスタンスのサイズを毎日リセットすることがある。この操作はデータセンタ単位で実行される。高いトラフィックが発生していて、リセット後のベースライン(ステージング)ステートでは処理できないような場合には、クライアントにエラーが発生しないことを確認する必要がある。Edgemeshがこれをどのように実現しているのか、Loveless氏は次のように説明する。

データセンタAがクリーンスレートを開始したとき、まず最初に行なうのは、DNSエントリから自身の登録を解除することです。DNSレコードを低TTL(30秒)で実行し、トラフィックがBとCに確実にリダイレクトされるまで5分間停止した上で、5分後にAのクリーンスレートを開始します。その後オンラインに復帰したら、DNSへの再登録を行います – トラフィックの受信を開始すれば、次にデータセンタBのクリーンスレートを実行します(Aがオンラインに復帰してトラフィック受信を開始したことをBに通知すると、Bが処理を開始します)。移行中には、負荷の上昇に備えるため、BとCをスケールアップしておくことも少なくありません。