スポンサーリンク

YouTubeを支えるアーキテクチャと高いスケーラビリティについて。
より大きい、速く、信頼できるウェブサイトの構築。

YouTubeは信じられないほど速く成長し、1日あたりのビデオ再生回数が10000万(1億)ある。一握りの人々がサイトスケールのための責任を負う。すべての彼らのユーザにどのように配信を管理しているのか?そして、Googleによって獲得されたあと、どのように進化したか?

YouTube ArchitectureHigh Scalability

情報ソース

http://video.google.com/videoplay?docid=-6304964351441328559

プラットフォーム
  • Apache
  • Python
  • Linux (SuSe)
  • MySQL
  • psyco, ダイナミック python → Cコンパイラ
  • ビデオのためのapacheの代わりにlighttpd
PV
  • 一日に10000万のビデオを転送している
  • 2006年3月 3000万 ビデオピュー/日
  • 2007年3月 10000万 ビデオピュー/日
  • 2人のシステム管理者と2人のスケーラブリティソフトウェアアーキテクト
急成長に対処するための方法

ボトルネックの特定と修正、そして新しいボトルネックに気付く、の無限ループ。

Web サーバ
  • NetScalarは、ロードバランシングと静的コンテンツのキャッシュに使う
  • mod_fast_cgiとApacheで動かす
  • Pythonアプリケーションサーバによって、処理のためのリクエストが送られる
  • アプリケーションサーバは、すべてのデータを得るためにさまざまなデータベースやその他の情報元と話し、htmlページをフォーマットする。
  • たいてい、マシンを追加することでスケールすることができる
  • python webコードは、たいていボトルネックにならず、多くの時間はRPCのブロックの時間に費やされる
  • pythonは、短時間のフレキシブルな開発と配置ができる。競争するうえで重要だ。
  • たいてい、ページのサービス時間は100ms未満である
  • psycoを使う、内部ループ最適化のためにJITコンパイラアプローチを使う動的python→Cコンパイラ。
  • 暗号化のような激しくCPUを使う場合には、Cのエクステンションを使う。
  • ブロックを返すための高価なHTMLのキャッシュをいくつかプリジェネレイトしている
  • データベースの列レベルのキャッシュをする
  • 完全なpythonオブジェクトは、キャッシュされる
  • いくつかのデータは計算され、それぞれのアプリケーションに送られる値は、ローカルメモリにキャッシュされる。これはあまり使われない戦略だ。早いキャッシュは、あならのアプリケーションサーバにおかれ、前処理したデータをすべてのサーバに送るのに多くの時間がかからない。変更、前処理、送信を関しするためのエージェントを持ちなさい。
ビデオ配信

  • シンプルかつ安価であることを保ちなさい
  • シンプルなネットワークパスを保ちなさい。コンテンツとユーザの間にたくさんのデバイスはあってはならない。ルータ、スイッチ、そして他のアプリケーションは、そのような負荷に耐えられないかもしれない。
  • 消耗品ハードウェアを使いなさい。高価なハードウェアは、多の高いものすべてを得るよりも高くつく(サポート契約)。あなたは、ネットでヘルプをあまり見つけられない。
  • シンプルな一般的なツールを使いなさい。多くのLinuxで作られたツールを使い、それらの上に層をなす。
  • ランダムなシークをよく処理する(SATA、tweasks)。
サムネイル配信

  • 驚くほど効率的にすることは難しい
  • それぞれのビデオに対し、4つのサムネイルがある、ビデオよりもたくさんサムネイルがある
  • サムネイルは、ごくわずかのマシンで配信している
  • のこぎり問題は、たくさんの- 驚くほど効率的にすることは難しい
  • それぞれのビデオに対し、4つのサムネイルがある、ビデオよりもたくさんサムネイルがある
  • サムネイルは、ごくわずかのマシンで配信している
  • のこぎり問題は、たくさんの小さなオブジェクトの配信を連想する
    • たくさんのディスクはシークし、OSレベルのinocdeキャッシュやページキャッシュに関連する問題があある
    • Ext3特有のディレクトリごとのファイル制限に衝突する。より階層的な構造に移行した。最近の2.6kernelの改善は、100回までのExt3ラージディレクトリハンドリングはよくなった、けれども、ファイルシステムのたくさんのファイルは、よい考えはまだない。
    • Webページのたくさんのリクエスト/秒は、ページに60のサムネイルを表示できる
    • そのような高い負荷ではApacheのパフォーマンスは悪い
    • Apacheの前にsquid(リバースプロキシ)を使う。これはしばらくの間、機能したが、負荷が増えることにより結局パフォーマンスが下がった。300リクエスト/秒から20に行った。
    • lighttpdの使用を試みたが、シングルスレッドは行き詰まった。マルチプロセスモードで問題に出くわした。それは、それぞれがわけられたキャッシュを持つからだ。
    • 画像があまりにも多いので、新しいマシンの増設は24時間以上もかかった
    • ディスクに行かせず、キャッシュで動くためのマシンのリブートには、6-10時間かかる。
  • それらの問題を解決するために、GoogleのBigTable(分散データストア)を使い始めた。
    • 氏諫なファイル問題を避ける。なぜなら、それはファイルを固まりにする。
    • 最初に、フォールトトレラント(耐故障)。信頼できないネットワークで機能すると仮定する。
    • 低い待ち時間のため、分散された多段階のキャッシュを使う。このキャッシュは、ことなったコレクションサイトを超えて機能する。
    • BigTableについてのより多くの情報は、Google Architecture、GoogleTalk ArchitectureとBigTableを見なさい。
データベース

  • 最初の年
    • ユーザ、タグ、説明のようなメタデータのためにMySQLを使う
    • 10のディスクでモノリシックのRAID10ボリュームでデータを配信
    • ハードウェアのリースをクレジットカードで養う。数日でロードをハンドルするためのより多くのハードウェアが必要になる。
    • それは、一般の進化によって行った。シングルサーバは、複数の読み出し専用スレーブと1つのマスター、それからデータベースの分割(パーティション)、そして共有アプローチに決めた。
    • レプリカ遅延で悩む。マスターはマルチスレッドで、たくさんの処理のハンドルするために大きなマシンで動作する。スレーブは、シングルスレッドで、たいてい劣ったマシンで実行され、非同期にレプリケーションし、スレーブはマスターに後れて、大きな遅延ができる。
    • アップデートによりキャッシュミスは、ディスクにいき、遅いI/Oの原因でレプリケーションが遅くなる。
    • 書き込みパフォーマンスの増加は、たくさんのお金が必要になる。
    • それらのソリューションの1つは、データを2つのクラスタに分割することによって、トラフィックの優先順位を決めること。機能は、大部分のリソースを得なければならないように、人々はビデオを見ることを望んでいる。彼らが結うようでないクラスタへ送られることができるように、YouTubeのソーシャルネットワーキングの特徴は、重要ではない。
  • 最後の年
    • データベースの分割(パーティショニング)
    • ユーザが割り当てた共有に異なった共有に分ける
    • ライトとリードを拡張する
    • IOを減らす意味でよりよいキャッシュの場所
    • 結果的に、30%のハードウェアの縮小
    • 今、ほとんど任意にデータベースをスケールすることができる
データセンター戦略

  • 最初にホスティング提供管理を使う。クレジットカードをやめる唯一の方法だった。
  • ホスティング管理は、スケールすることができない。ハードウェアをコントロールすることができないか、有益なネットワークの取り決めを作れない。
  • 彼らはコロケーションの準備を望む。彼らはすべてをカスタマイズすることができ、自身で協議して交渉する。
  • CDNを使用する5か6のデータセンター
  • ビデオは、いくつかのデータセンターから出て行く。もっとも近くないマッチか、なにか。もしビデオが十分に人気があれば、CDNが機能する。
  • ビデオ帯域幅依存、本当の待ち時間依存ではない。coloからくることができる。
  • 画像遅状況のため、特に、1つのページに60の画像を持つ。
教訓を学んだ

  • 時間稼ぎ。独創的や危険なトリックは、長い期間かかる問題を解決するために、短い間うまくいく処理は、助けとなる。
  • 優先順位。あなたのサービスの本質的要素を何か知り、あなたのリソースと優先により効果を優先順位つける。
  • あたなの戦いを選びなさい。必要不可欠なサービスのアウトソースをおそれてはいけません。YouTubeは、もっとも普及したコンテンツ配信にCDNを使ってる。自身のネットワーク構築は、あまりに長い時間を必要とするだろう。あなたのシステムによく似た機会を持つだろう。より多くのアイデアのためにサービスととしてソフトウェアを取りなさい。
  • シンプルであることを保ちなさい。単純さは、あなたにより緊急の再構築を許すため、問題に対応することができる。誰も、ほんとうに、単純さが何であるかについて知らないというのは本当だ。しかい、あなたが変更することをおそれないなら、それは単純さが引き起こしたよい兆候だ。
  • 共有。共有は分離を助け、ストレージ、CPU、メモリ、IOを制約する。それは、より書き込みパフォーマンスを得るためではない。
  • 不変繰り返しのボトルネック
    • ソフトウェア: DB、キャッシング
    • OS: ディスクI/O
    • ハードウェア: メモリ、RAID
  • あなたはチームとして成功しています。システム全体を熟知する訓練されたチームとよい交流を持ちなさい。人々は、プリンタ、マシンをセットアップすることができ、ネットワーク、その他をインストールする。 よいチームとともに、すべてのものは可能だ。

注意

日本語は保証されません...。

元ネタ

http://highscalability.com/youtube-architecture
参照しているページ (サイト内): [2007-08-07-1]

スポンサーリンク
スポンサーリンク
 
いつもシェア、ありがとうございます!


もっと情報を探しませんか?

関連記事

最近の記事

人気のページ

はてなの人気のブックマーク

スポンサーリンク
 

過去ログ

2019 : 01 02 03 04 05 06 07 08 09 10 11 12
2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12
2003 : 01 02 03 04 05 06 07 08 09 10 11 12

サイト

Vim入門

C言語入門

C++入門

JavaScript/Node.js入門

Python入門

FreeBSD入門

Ubuntu入門

セキュリティ入門

パソコン自作入門

ブログ

トップ


プライバシーポリシー