Upgrade to Pro — share decks privately, control downloads, hide ads and more …

P2Pファイル共有ネットワークを利用した フラッシュクラウド耐性のある協調型負荷分散手法

P2Pファイル共有ネットワークを利用した フラッシュクラウド耐性のある協調型負荷分散手法

P2Pファイル共有ネットワークを利用した フラッシュクラウド耐性のある協調型負荷分散手法

MATSUMOTO Ryosuke

July 23, 2013
Tweet

More Decks by MATSUMOTO Ryosuke

Other Decks in Technology

Transcript

  1. Cooperative Load Distribution
    for Addressing Flash Crowds
    Using P2P File Sharing Network
    P2Pファイル共有ネットワークを利用した
    フラッシュクラウド耐性のある協調型負荷分散手法
    京都大学 大学院情報学研究科
    知能情報学専攻 岡部研究室
    岡本 大樹 松本 亮介 岡部 寿男
    1

    View full-size slide

  2. フラッシュクラウド(FlashCrowd)
    Webサイト
    のサーバ
    特徴 • 継続時間は短い
    • 数十倍から数百倍のトラフィック
    • TVや有名なサイトからのリンクをきっかけに発生
    このWebサイトが
    面白い!!
    TVでWebサイトが
    紹介される
    Webサイトへ
    アクセス集中
    Webサイトが
    一時的に閲覧不能に
    2
    急激な負荷の増加によってWebサイトが一時的に閲覧不能になる問題
    1
    2
    3

    View full-size slide

  3. 負荷を予想して必要な設備を準備する
    FlashCrowdへの対応における従来手法の問題点
    3
    新たな管理/運用の労力
    導入/維持の費用
    低負荷時には費用が無駄
    新しい設備
    新しい設備


    従来の負荷分散手法では…
    非営利団体や個人の運営するWebサイトなどの
    小規模なWebサイトの運営者はフラッシュクラウドに対処できない
    フラッシュクラウドに対処するにはそれに合わせた設備の準備が必要

    View full-size slide

  4. 相互扶助による解決
    4
    Help!
    一部のサーバがフラッシュクラウドの時
    その他の多くのサーバには余裕がある
    WebサイトA
    のサーバ
    ♪ ♪
    • 小規模なWebサイトがフラッシュクラウドに対処するのためには…
    WebサイトB
    のサーバ
    WebサイトC
    のサーバ
    お互いのデータを持ち合い
    フラッシュクラウドの時は助け合う
    • 問題
    2台の場合 5台の場合
    台数が増えるとコピーの数が膨大になってしまう
    要求の多いデータのみコピーを増やす仕組みが必要
    Webサーバ同士がお互いに助け合って負荷分散

    View full-size slide

  5. Peer to Peer (P2P)
    • Peer to Peer
    o 多数の端末間で通信を行うアーキテクチャの一つ
    o サーバ/クライアントという区別がなく1つのピアはどちらの役割も担う
    o スケーラビリティや耐障害性が高い
    • P2Pファイル共有ネットワーク
    o Peer to Peer形式で通信を行い参加者同士でファイルを交換する
    5
    クライアントサーバ型
    P2P型
    • ファイルはサーバから取得
    • 端末数が増えるとサーバへ負荷が集中する
    • データは既にファイルをもつピアから取得
    • 需要が多いファイルほどコピーが増えていく
    • 特定のピアへ負荷が集中しない

    View full-size slide

  6. 本研究の提案
    • フラッシュクラウド耐性のある協調型負荷分散(静的コンテンツを対象)
    6
    Webサーバ同士が
    自動的に遊休資源を
    分け合う相互扶助
    の仕組み
    P2Pファイル共有
    ネットワーク
    を利用したクライアント
    への負荷分散とデータ拡散
    P2Pが使える
    クライアント
    P2Pが使えない
    クライアント
    P2Pファイル共有
    ネットワーク
    Webサーバ
    P2Pが使えるクライアント
    P2Pが使えないクライアント

    View full-size slide

  7. 関連研究
    1. プロキシサーバでクライアントへ負荷分散する手法 [Yokota et al. 2011]
    o リバースプロキシをWebサーバの前に設置
    o リバースプロキシでフラッシュクラウドを検知・クライアントへルーティング
    2. プロキシサーバ群へ負荷分散する手法 [C.Pan et al. 2006]
    o プロキシサーバのオーバレイネットワークへ負荷分散
    o フラッシュクラウド発生時に動的にオーバレイネットワークを構成
    o Webサーバがオーバレイネットワークへの指示や管理を担当
    7
    Webサーバ
    プロキシサーバ
    フラッシュクラウド
    前にアクセスしたク
    ライアント
    プロキシサーバの
    オーバレイネットワーク
    Webサーバ
    フラッシュクラウド

    View full-size slide

  8. 提案手法の概念図
    8
    P2Pが使える
    クライアント
    P2Pが使えない
    クライアント
    P2Pファイル共有
    ネットワーク
    P2Pが使えるクライアント
    P2Pが使えないクライアント
    ① P2Pが使えるクライアントとP2Pが使えないクライアント
    ② Webサーバは高負荷のとき他のサーバに助けを求める
    ③ 助けを求められたサーバはデータをP2Pからダウンロード
    ④ オリジナルのサーバに代わって提供する
    Help!
    1
    2
    3
    4
    OK!
    1
    助けを求められた
    サーバ
    オリジナルの
    Webサーバ

    View full-size slide

  9. 提案手法
    9
    • Webサーバ同士の相互扶助
    負荷が高まった際は協調サーバへリダイレクトする
    P2Pファイル共有
    ネットワーク
    P2Pが使えるクライアント
    P2Pが使えないクライアント
    Help!
    協調サーバ
    オリジナルサーバ
    協調サーバ
    HTTPリダイレクト
    P2Pダウンロード
    代理で提供開始

    View full-size slide

  10. 提案手法
    10
    WebサーバがP2Pファイル共有ネットワークに参加することにより
    要求の多いデータほどコピーが自動的に増える
    協調サーバ
    オリジナルサーバ
    P2Pが使えるクライアント
    協調サーバ
    • P2Pファイル共有ネットワークへの参加
    P2P経由のアクセス
    P2P経由のアクセス
    クライアントへコピーが拡

    View full-size slide

  11. 提案手法
    11
    P2Pファイル共有
    ネットワーク
    P2Pが使えるクライアント
    P2Pが使えないクライアント
    Help!
    協調サーバ
    オリジナルサーバ
    協調サーバ
    P2Pダウンロード
    フラッシュクラウド発

    混雑している
    協調サーバから取得する
    必要が無い
    サーバがダウンしても
    他のクライアントから
    直接取得
    • P2Pファイル共有ネットワークへの参加
    1
    2
    2
    3

    View full-size slide

  12. 提案手法の特徴
    • 協調サーバとの相互扶助
    o 自分の運営するサーバと他人が運営するサーバが協調関係を結ぶ
    o 協調関係とは、負荷が高まった時にお互いに助け合う契約
    o 協調関係を結ぶサーバは信頼できるサーバのみにする
    • P2Pファイル共有ネットワーク
    o P2Pファイル共有ネットワークへWebサイトを公開し、協調サーバとのデータ
    のやり取りをP2P経由で行う
    o ネットワーク参加による負荷が低いなどの利点からBitTorrentを用いる
    o 他のP2Pファイル共有ネットワークでも同様の役割を担うことができる
    12
    自分のサーバ 他人のサーバ

    View full-size slide

  13. システムの設計 - 全体の構成 -
    • 提案システムの構成要素
    ① 自身のWebサーバ
    ② 協調する他のWebサーバ
    ③ DNS
    13
    協調サーバ
    P2Pが使えないクライアント
    ④ クライアント
    ⑤ BitTorrentトラッカー
    オリジナルサーバ
    DNS
    BitTorrent
    トラッカー
    P2Pが使えるクライアント
    協調サーバ
    BitTorrentネットワーク
    の管理を担う
    1
    2 2
    3
    5
    4 4
    名前解決や
    DNSラウンドロビン

    View full-size slide

  14. システムの設計 – 相互扶助の仕組み -
    • フラッシュクラウドの検知
    o Webサーバ内部の情報
    o サーバの状態
    o Webサーバ同士の定期的な生存確認
    • Webサーバの状態遷移
    o 低負荷の状態
    o フラッシュクラウドの状態
    o 救援状態
    • リクエストの分散
    o HTTPリダイレクト
    o DNSラウンドロビン
    14
    • 同時接続可能なクライアント数
    • プロセス数・スレッド数
    • 保留状態のコネクション数
    • CPU使用率
    • メモリ使用量
    Webサーバ同士が
    自動的に遊休資源を
    分け合う相互扶助
    の仕組み

    View full-size slide

  15. システムの設計
    • クライアントがP2Pに参加できる場合
    15
    オリジナル
    サーバ
    協調サーバ
    以前アクセスしたP2P
    対応のクライアント
    新しくやってきた
    クライアント
    HTTP Request
    HTTP Redirect
    HTTP Request
    Return .torent file (HTTP response)
    BitTorrent Download
    BitTorrent Upload
    Help!

    View full-size slide

  16. システムの設計
    • クライアントがP2Pを使えない場合
    16
    オリジナル
    サーバ
    協調サーバ
    以前アクセスしたP2P
    対応のクライアント
    新しくやってきた
    クライアント
    HTTP Request
    HTTP Redirect
    HTTP Request
    Return contents data (HTTP response)
    BitTorrent Download
    BitTorrent Upload
    Help!

    View full-size slide

  17. システムの設計
    • 提案システムの動作例
    17
    フラッシュクラウドの状態 + 通常アクセス + オリジナルサーバが生きている
    オリジナル
    サーバ
    サーバ C
    サーバ A サーバ B サーバ D サーバ E
    協調サーバ
    DNS



    www IN A サーバ C
    ゾーンファイル
    協調サーバ
    BitTorrent
    トラッカー
    サーバ C
    クライアントB
    ピアリスト
    新しくやってきた
    クライアント
    2. HTTP
    3.
    リダイレクト
    7. レコード追加
    6. データ送信
    以前アクセスしたP2P
    対応のクライアント
    5. データ取得
    4. ピアリストを取得
    1. 名前解決

    View full-size slide

  18. まとめと今後の課題
    • まとめ
    o フラッシュクラウドに対応する場合の従来手法の問題点について考察した
    o Webサーバ同士の相互扶助とP2Pファイル共有ネットワークを利用してフラッシュ
    クラウドに対処する負荷分散手法を提案した
    o 提案手法を用いたシステムの設計を行った
    • 今後の課題
    o 設計の実装と評価
    o より実環境に近い条件での評価
    o 動的なコンテンツにたいしても負荷分散できるような仕組み
    o P2Pでクライアント上に拡散したコンテンツの削除
    18

    View full-size slide