この記事では、Alibaba 「Dragonfly」のファイル配信システムが、年に一度のオンラインショッピングの祭典「Alibaba独身の日（W11）」のサポートにどのように役立っているかをご紹介します。
2017年のAlibaba独身の日（W11）オンラインショッピングフェスティバルでは、取引額が1秒あたり32万5,000件、決済額が1秒あたり25万6,000件、データベースリクエストが1秒あたり4,200万件のピークを迎え、再び新記録を更新しました。W11の期間中、AlibabaグループのインフラストラクチャコンポーネントであるDragonflyは、5GBのデータファイルを10,000台以上のサーバーに同時に送信しました。これにより、大規模なファイル配信を完璧に行うためにDragonflyシステムを利用することが可能になりました。
Dragonflyとは？
AlibabaのDragonflyは、インテリジェントなP2Pベースの画像およびファイル配信システムです。大規模なファイル配信において、配信に時間がかかる、成功率が低い、帯域が無駄になるなどの問題を解決します。また、配信の展開、データの予熱、大規模なコンテナイメージの配信などのビジネス機能を大幅に改善します。Alibaba社内では、Dragonflyはすでに月平均20億回の配信を超え、3.4PBのデータを配信し、Alibabaのインフラの一部となることに成功しています。コンテナ技術は、運用・保守（O&M）に利便性をもたらしますが、画像配信の効率化には大きな課題があります。Dragonflyは、DockerやPouchなど、さまざまなコンテナ技術に対応しています。Dragonflyを使用すると、イメージ配信が57倍も高速化され、データソースのネットワーク輸出トラフィックが99.5％以上削減されます。ドラゴンフライは、帯域幅のリソースを節約し、O&Mの効率を高め、O&Mコストを削減します。
質問のソース
Dragonflyは、Alibaba独自の研究成果であるP2Pファイル配信システムです。Alibabaの基本的なO&Mプラットフォームの重要な構成要素であり、クラウド効率°™スマートO＆Mプラットフォームのコアコンピタンスを形成します。また、クラウドコンテナサービスの重要な構成要素でもあります。
しかし、その始まりは15年前から議論されていました。
Alibabaのビジネスの爆発的な成長に伴い、15年の間にシステムの1日の配信量は2万件を超え、多くのアプリケーションの規模も1万件を超えるようになり、配信の失敗率も増加していきました。根本的な原因は、配信処理に大量のファイルの運搬が必要なことでした。ファイルサーバーは、その大量の要求に対応できなかったのです。もちろん、サーバーの増設といえば簡単ですが、サーバーを増設するとバックエンドのストレージがボトルネックになっていることがわかります。それ以外にも、多数のIDCクライアントからの大量のリクエストが、膨大なネットワーク帯域を使い、ネットワークの混雑を引き起こしていました。
同時に、多くの企業が国際化を進めており、大量のアプリケーションが海外に展開されていました。海外でのサーバーのダウンロードは、国内のBack-to-originでの動作に依存しているため、海外の帯域を大量に消費し、また速度も非常に遅くなります。また、大容量のファイルを配信する際に、失敗しても繰り返し送信する必要があり、ネットワーク環境が悪いと効率が極端に悪くなります。
そこで、自然とP2P技術が思い浮かびました。しかし、P2P技術は決して新しいものではないので、国内外のさまざまなシステムを検討しました。しかし、それらのシステムの規模や安定性は、私たちの期待に応えるものではありませんでした。そこで生まれたのが「Dragonfly」なのです。
設計目標
これらの欠点を解決するために、Dragonflyは設計の初期段階でいくつかの目標を設定しました。
1、ファイルソースが吹き飛んでしまう問題を解決するために、ホスト間でP2Pネットワークを組織し、ファイルサーバーへの負担を軽減し、IDCにまたがる帯域リソースを節約する。
2、ファイル配信速度を加速し、1万台以上のサーバーがダウンロードする場合と1台のサーバーがダウンロードする場合の変動が大きくならないようにする。
3、国境を越えたダウンロードの高速化と帯域の節約を解決する。
4、大容量ファイルのダウンロード問題を解決するには、停電時の送信継続にも対応する必要がある。
5、ビジネスに影響を与えないためには、ホスト側のコンピュータのディスクIOやネットワークIOを制御できることが必要。
システム構成
図1、 Dragonflyの全体的なアーキテクチャ
アーキテクチャ全体は3つの層に分かれています。最初の層はConfig Serviceです。このサービスは、すべてのクラスタマネージャを管理します。クラスタマネージャは、すべてのホストを管理します。ホストは端末です。Dfgetは、wgetに似たクライアントシーケンスです。
Config Serviceは主に、クラスタマネージャの管理、クライアントノードのルーティング、システム構成の管理、プリヒートサービスなどを担当します。簡単に言えば、ホストに最も近いクラスタマネージャのチームのアドレスリストをホストに通知し、このリストを定期的に維持・更新して、ホストが常に最も近いクラスタマネージャを見つけられるようにする役割を担っています。
クラスタマネージャの主な任務は2つあります。1つ目は、ファイルソースからパッシブCDNモードでファイルをダウンロードし、シードブロックデータのセットを生成すること、そして2つ目は、P2Pネットワークを構築し、各ピア間で相互に送信するために指定されたブロックデータをディスパッチすることです。
そして、DFGETはホストに格納されます。dfgetの構文はwgetとよく似ています。主な機能としては、ファイルのダウンロードやP2P共有などがあります。
Alibabaでは、StarAgentを使ってdfgetコマンドを下に配布し、複数のマシンで同時にファイルをダウンロードすることができます。ある種のシナリオでは、マシンの集合はAlibabaのすべてのサーバーになるかもしれません。そのため、非常に効率的に使用できます。クライアントとは別に、ドラゴンフライにはJava SDKがあり、一連のサーバーにファイルを「プッシュ」することができます。
下の図は、2台の端末が同時にdfgetを起動して同じファイルをダウンロードするというインタラクティブなシステムの模式図を詳しく説明したものです。
図2、DragonflyのP2Pネットワークの論理図
2台のホストと1台のCMでP2Pネットワークを形成します。まずCMは、ローカルエリアにキャッシュがあるかどうかを確認します。ない場合は、Back-to-originでキャッシュをダウンロードします。もちろん、ファイルはシャードに分けられます。CMはこのシャードを複数のスレッドでダウンロードします。同時に、CMはダウンロードしたシャードをホストに提供します。ホストはシャードをダウンロードした後、同時にそのシャードを仲間に提供してダウンロードさせます。すべてのホストに到達した時点で、全体のダウンロードが完了します。
ロケールでダウンロードが進行しているときは、シャードのダウンロードの状況がメタデータに記録されます。ダウンロードが突然中断された場合は、再度dfgetコマンドが実行され、停電でも転送が継続されます。
また、ダウンロードが終了すると、ダウンロードしたファイルがソースファイルと完全に同一であることを確認するために、MD5の比較検証が行われます。Dragonflyは、HTTPキャッシュプロトコルを用いてCM側のキャッシュ期間を制御します。もちろん、CM側でも定期的にディスクのクリーニングを行い、長期のサービスに耐えうる容量が確保されているかどうかを確認する機能を持っています。
Alibabaでは、ファイルを事前にCM側にプッシュする必要があるファイルプレヒートのシナリオも多くあります。コンテナイメージ、インデックスファイル、ビジネス最適化ファイルなどがそれにあたります。
最初のバージョンがオンラインになった後、一通りのテストを行い、その結果は以下のグラフのようになりました。
図3、 従来のダウンロードとDragonflyのP2Pダウンロードテストの結果の比較グラフ
X軸：クライアントボリューム。Y軸：ダウンロード時間。ファイルソース：テスト対象ファイル200MB（ネットワークアダプターカード：Gbps）。ホスト：100Mbpsのネットワークアダプターカード。CM：2台のサーバー（24コア、64G、ネットワークアダプターカード：Gbps）。
このグラフから2つの問題点が見えてきます。
1、トラディショナルモードは、クライアント数が増えるとダウンロード時間も長くなり、dfgetが7,000クライアントまで対応できるという点は、まだ改善されていません。
2、トラディショナルモードが1,200クライアントに達した後は、データソースが吹っ飛んでしまったため、データがありません。
毎年、W11の前の期間は配信がピークになります。DragonflyはW11 2015の時に完成度を超えました。
配信システムからインフラへ
W11 2015の後、Dragonflyは月間12万件のダウンロード数と4TBの配信量を達成しました。この間、Alibabaではwget、curl、scp、ftpなどの他のダウンロードツールが使われ、独自に構築した小規模な配信システムも使われていました。全面的な配信システムとは別に、小規模なプロモーションも行いました。2016年2月11日頃には、ダウンロード数が1億4千万/月、配信数が708TBに達しました。
2016年2月11日以降、私たちはさらに高い目標を提案しました。Alibabaの大規模ファイル配信、大容量ファイル配信ビジネスの90％をドラゴンフライが請け負うことを希望しています。Dragonflyがグループ全体のインフラになることを期待しています。
この目標によって、最高のP2Pファイル配信システムを磨き上げていきたいと考えています。また、グループ内のすべてのファイル配信システムを統合することも可能です。統合すれば、さらに多くのユーザーが恩恵を受けることができますが、統合が最終目的ではありません。
統合の目的は：
1、機器の重複を減らす
2、全体の状況を最適化する
Dragonflyのシステムが最適化されていれば、グループ全体にメリットがあります。例えば、システムファイルは毎日ネットワーク全体で配信されていますが、このファイルだけでも圧縮できれば、毎日9TBのネットワークトラフィックを削減できることがわかりました。国境を越えた帯域資源は特に貴重です。皆がそれぞれの配信システムを使っていれば、このような全体的な状況の最適化は議論するまでもないでしょう。
ですから、統合は絶対に必要なのです。
膨大なデータを分析した結果、グループ全体のファイル配信量は1週間で約3億5,000万件、当時の我々の割合は10％にも満たないという結論に達しました。
半年間の努力の末、2017年4月、ついにこの目的である「事業の90％以上のシェア」を達成しました。ビジネスのボリュームは、（基本的には以前の分析のデータ通りに）週に3億ファイルに成長しました。配信量は977TBでした。この数字は、半年前の月のボリュームを上回っています。
もちろん、これがAlibabaのコンテナ化と密接に関係していることは指摘せざるを得ません。画像配信は約1/2を占める。ここでは、ドラゴンフライが画像配信をどのようにサポートしているかをご紹介します。ただし、画像配信を語る前に、当然ながらAlibabaのコンテナ技術について語らなければなりません。
Alibabaのコンテナ技術：PouchContainer
コンテナ技術の強みは、当然ながら紹介するまでもないでしょう。世界的に見ても、コンテナ技術はDockerが最大のシェアを占めています。もちろん、Docker以外にも、rkt、Mesos Uni Container、LXCなどのソリューションが存在しますが、Alibabaのコンテナ技術は「Pouch」と呼ばれています。Alibabaは2011年の時点で、独自にLXCコンテナ「T4」を研究・開発していました。その時はまだイメージという概念ができていませんでした。T4はそれにもかかわらず、仮想マシンの役割を果たしていましたが、もちろんそれよりもはるかに軽量でなければなりませんでした。
2016年、AlibabaはT4をベースに大きなバージョンアップを行い、それが現在のPouchに進化しました。これはすでにオープンソースでした。現在、Pouchのコンテナ技術はすでにAlibabaグループのほぼすべての事業部をカバーしています。画像技術の価値がコンテナ技術の応用範囲を広げ、Alibabaの巨大な応用シーンにおいて、いかに高効率な「画像配信」を実現するかが大きな課題となっています。
画像のレベルに話を戻します。マクロ的に見れば、Alibabaには膨大な規模のコンテナアプリケーションのシナリオがあります。ミクロの視点では、各アプリケーションのイメージが形成される際に、その品質は不均一にマッチした状況にあります。
理論的には、イメージングや従来の「ベースライン」と呼ばれる方法では、アプリケーションのサイズに関する限り、極端に大きな差は出ないはずです。実際には、これはDockerfileの書き方が良いか悪いか、そしてイメージの重ね方が合理的かどうかに完全に依存します。ベストプラクティスは実際にAlibaba社内に存在しますが、各チームの理解度や受け入れレベルは異なります。良い使い方と悪い使い方の違いは確実にあります。特に最初の頃は、皆さん3～4GBの画像を出したりしますよね。これは非常によくあることです。
ですから、P2Pファイル配信システムであるDragonflyは、イメージの大きさや配信先のマシンの数に関わらず、その技術を利用する上で有利な立場にあります。たとえ極端に悪いイメージが作られたとしても、常に極めて高効率な配信を行います。ボトルネックになることはありません。このように、コンテナのO&M手法を誰もが理解できるように、十分な時間をかけてコンテナ技術を一気にアピールしています。
図4．画像ダウンロードのフローチャート
Alibaba Cloud Container Serviceを例にとると、従来の画像送信はグラフのようになります。もちろん、これは最も単純化されたタイプのアーキテクチャ方法です。実際の導入環境はもっと複雑で、認証やセキュリティ、高可用性なども考慮しなければなりません。
上のグラフからもわかるように、画像伝送とファイル配信には同じような問題があります。1万台のホストが同時にレジストリにリクエストすると、レジストリがボトルネックになってしまいます。また、海外のホストが国内のレジストリにアクセスすると、帯域の浪費、遅延の長期化、成功率の低下などの問題が発生します。
ここでは、Docker Pullの導入プロセスを紹介します。
図5. Dockerイメージレベルのダウンロード
Docker Daemonは、レジストリAPIのイメージ取得のためにマニフェストを呼び出します。マニフェストから、各レベルのURLを把握することができます。その後すぐに、Daemonはレジストリからホストのローカルデータベースへの画像レイヤーのダウンロードを並行して行います。
したがって、最終的には、画像送信の問題は、各画像レイヤーファイルの同時ダウンロードの問題になります。しかし、Dragonflyが得意とするのは、まさにP2Pモードを使って各レイヤーの画像ファイルをローカルデータベースに転送することです。
では、具体的にどうやって実現するのでしょうか？
実は、ホスト側でdfgetプロキシを有効にします。Docker/Pouchエンジンのコマンドやリクエストは、すべてこのプロキシを経由します。下のグラフを見てみましょう。
図6、Dragonfly P2Pコンテナイメージ配布図
まず、docker pullコマンドをdfgetプロキシがインターセプトします。次に、dfgetプロキシはCMにディスパッチリクエストを送信します。CMはリクエストを受け取ると、対応するダウンロードファイルがすでにローカルにキャッシュされているかどうかを調査します。キャッシュされていなければ、対応するファイルをレジストリからダウンロードし、シードブロックデータを生成します（シードブロックデータが生成されるとすぐに使用可能になります）。既にキャッシュされていた場合は、直ちにブロックタスクを生成します。リクエスタは対応するブロックタスクを解析し、他のピアやスーパーノードからブロックデータをダウンロードします。あるレイヤーのすべてのブロックのダウンロードが終了すると、そのレイヤーのダウンロードも終了します。同様に、すべてのレイヤーのダウンロードが終了すると、イメージ全体のダウンロードも終了します。
Dragonflyでサポートされているコンテナイメージの配布には、いくつかの設計上の目的もあります。
1、大規模な同時配信：10万レベルの同時引きの画像規模に対応できること。
2、コンテナ技術の内部コア（Docker Daemon、レジストリ）に侵入しないこと。言い換えれば、いかなるコンテナサービスコードも変更できないこと。
3、Docker、Pouch、Rocket、Hyperなど、すべてのコンテナおよび仮想マシン技術のサポート。
4、イメージのウォームアップをサポート（構築中のDragonflyクラスタCMへのプッシュ）。
5、大きなイメージファイル（最低30GB）のサポート。
6、セキュリティ
Native DockerとDragonflyの比較
全部で2セットの実験を行いました。
実験1：1クライアント
1、テストした画像サイズ：50MB、200MB、500MB、1GB、5GB
2、画像レポジトリの帯域幅：15 Gbps
3、クライアントの帯域幅：2倍の100Mbpsのネットワーク環境
4、スケールテスト：シングルダウンロード
図7、 シングルクライアントでの各方式の比較グラフ
NativeとDragonfly（クローズドスマート圧縮プロパティ）の平均経過時間は基本的に類似していますが、Dragonflyの方が若干長いです。これは、Dragonflyが、ダウンロードの過程で、データの各ブロックのMD5値をチェックし、ダウンロード終了後に、ファイル全体のMD5もチェックして、ファイルソースが同一であることを確認するためです。しかし、スマート圧縮を有効にすると、その経過時間はNativeモードよりも短くなります。
実験2：マルチクライアント・コンカレンシー
1、テストした画像サイズ：50MB，200MB，500MB，1GB，5GB
2、画像レポジトリの帯域幅：15 Gbps
3、クライアントの帯域幅：100Mbpsのダブルネットワーク環境
4、複数のコンカレンシー 10個同時、200個同時、1,000個同時
図8. 画像サイズとコンカレント性の比較グラフ
上のグラフから、ダウンロード規模の拡大に伴い、DragonflyモードとNativeモードの経過時間の差が大幅に拡大していることがわかります。最も可用性の高いものでは、最大で20倍もの高速化を実現しています。テスト環境では、ソースの帯域が非常に重要です。ソースの帯域幅が2Gbpsの場合、最大で57倍ものスピードアップが可能です。
下のグラフは、ファイル全体のトラフィック（同時実行数×ファイルサイズ）とバックトゥオリジンのトラフィック（レジストリ経由でダウンロードしたトラフィック）を比較したものです。
図9、Dragonflyの外向き配信トラフィックの比較グラフ
500Mのイメージを200ノードに配布するには、Dockerのネイティブモードよりも少ないネットワークトラフィックで済みます。実験データによると、Dragonflyを採用した後、外向きのレジストリトラフィックは99.5%以上減少し、1,000コンカレントの規模になると、外向きのレジストリトラフィックは約99.9%減少することが明らかになっています。
Alibabaグループへの実際の応用
Alibabaは、すでに約2年間ドラゴンフライの使用にコミットしており、その間にビジネスは急速に発展しました。配信数の統計によると、現在、月に20億回、3.4PBのデータを配信しています。コンテナイメージの配信量は、その半分近くを占めています。
図10、AlibabaでのDragonflyファイルとDragonfly配信のトラフィック傾向を示すグラフ
Alibabaで1回の配信で最大となったのは、実は今年のW11の時期でした。5GB以上のデータファイルを10,000台以上のサーバーで同時に配信しなければなりませんでした。
AlibabaのAIOpsへの初期対応は早かったわけではありませんが、今年は大規模な投資を行っており、多くの製品に応用されています。Dragonflyのアプリケーションの中には次のようなものがあります。
スマートトラフィックコントロール
交通管制は、道路交通でよく見られます。例えば、中国の道路の制限速度規制では、センターラインのない高速道路の制限速度は40km/hとなっています。同じく、自動車用の一般道路では、制限速度が70km/hのところが1つだけあります。高速道路では80km/h、フリーウェイの最高速度制限は120km/hです。このような制限は、すべての自動車に共通するもので、明らかに柔軟性に欠けています。つまり、道が非常にわかりやすい状況では、資源の浪費が激しく、全体の効率が非常に悪いのです。
そもそも信号機とは、交通をコントロールするためのものです。現在の信号機は、決められた時間に合わせて作動します。実際の交通の流れを見て賢く判断することはできません。昨年10月に開催された云栖会議で、王健博士は「世界で最も長い距離は北極と南極の間ではなく、信号機と交通監視カメラの間だ」と嘆いていました。同じ電柱に設置されていても、データで結ばれることはありません。信号機の動作が監視カメラのターゲットになることはありません。これでは、都市のデータリソースが無駄になり、ビジネス開発のコストも増えてしまいます。
Dragonflyのパラメータの1つに、ディスクとネットワークの帯域幅の使用量の制御があります。このパラメータでは、ユーザーが使用するディスクやネットワークIOの量を設定することができます。上述のように、この方法は非常に硬直化していました。そこで現在、私たちが考えている「スマート化」とは、この種のパラメータを「設定する」のではなく、「ビジネスの状況」と「システムの運用状況」を組み合わせたパラメータに応じて、「賢く設定する」ことだと考えています。 最初のうちは最適なソリューションではないかもしれませんが、一定期間の運用とトレーニングを経て、自動的に最適な状態になっていきます。これにより、安定した業務の遂行が保証され、ネットワークやディスクの帯域を最大限に活用し、リソースの無駄を省くことができます。iDSTチームとの共同プロジェクト）。
スマートスケジューリング
ブロックジョブのスケジューリングは、配信速度が高いか低いかを決める重要な要素です。状況に応じて、あるいはその他の固定的な優先順位のスケジューリングなど、単純なスケジューリング戦略だけで実行した場合、常にダウンロード速度の規則性に変動が生じ、簡単に過剰なダウンロードの不具合が発生し、同時にダウンロード速度も非常に悪くなります。私たちは、ジョブスケジューリングを最適化するために数え切れないほどの試行錯誤を繰り返し、最終的には多次元のデータ分析とスマートトレンドを採用して、リクエスト者の最適なフォローアップブロックのジョブリストを決定しました。多次元とは、マシンのハードウェア構成、地理的な位置、ネットワーク環境、過去のダウンロード結果や速度などです。データ分析には、主に勾配降下法やその他のフォローアップアルゴリズムが使用されました。
スマート圧縮
スマート圧縮は、ファイルの中で最も圧縮に適した部分に適切な圧縮戦略を導入することで、ネットワークの帯域資源を大量に節約することができます。
現在のコンテナイメージの平均的なデータでは、圧縮率は40％となっています。つまり、100MBのデータを40MBに圧縮することができます。1,000コンカレントの規模では、スマートコンプレッションを使用することで、トラフィックフローを60%削減することができます。
セキュリティについて
特定の機密ファイル（機密ファイルやアカウントデータファイルなど）をダウンロードする際には、配信のセキュリティを効果的に保証する必要があります。この点について、Dragonflyは2つの主要な役割を果たしています。
1、HTTPヘッダーデータをサポートすることで、ヘッダーによる検証が必要なファイルソースに対応する。
2、対称型の暗号化アルゴリズムを採用し、ファイルの内容を暗号化して送信します。
概要
Dragonflyは、P2P技術とスマート圧縮、スマートトラフィックコントロールなどの様々な革新的技術を同時に用いることで、ネットワークをまたいだ孤立した環境での大規模なファイルダウンロードや、あらゆる種類の困難なファイル配信の問題を解決します。これにより、データの予熱、大規模なコンテナ画像の配信、その他のビジネス機能が大幅に向上します。
Dragonflyは、さまざまな種類のコンテナ技術に対応しています。コンテナ自体に変更を加える必要はありません。ファイル配信は、ネイティブモードに比べて最大57倍まで高速化できます。レジストリネットワークの外向きのトラフィックは99.5％以上削減されます。PBグレードのトラフィックを運ぶDragonflyは、すでにAlibabaのインフラの重要な一部となっており、ビジネスの拡大や年に一度のオンラインショッピングの祭典「独身の日（W11）」をサポートしています。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ