YouTube アーキテクチャハイスケーラビリティ

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

一日に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)。

サムネイル配信

驚くほど効率的にすることは難しい
それぞれのビデオに対し、４つのサムネイルがある、ビデオよりもたくさんサムネイルがある
サムネイルは、ごくわずかのマシンで配信している
のこぎり問題は、たくさんの- 驚くほど効率的にすることは難しい
それぞれのビデオに対し、４つのサムネイルがある、ビデオよりもたくさんサムネイルがある
サムネイルは、ごくわずかのマシンで配信している
のこぎり問題は、たくさんの小さなオブジェクトの配信を連想する

たくさんのディスクはシークし、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を使う
１０のディスクでモノリシックのRAID１０ボリュームでデータを配信
ハードウェアのリースをクレジットカードで養う。数日でロードをハンドルするためのより多くのハードウェアが必要になる。
それは、一般の進化によって行った。シングルサーバは、複数の読み出し専用スレーブと１つのマスター、それからデータベースの分割（パーティション）、そして共有アプローチに決めた。
レプリカ遅延で悩む。マスターはマルチスレッドで、たくさんの処理のハンドルするために大きなマシンで動作する。スレーブは、シングルスレッドで、たいてい劣ったマシンで実行され、非同期にレプリケーションし、スレーブはマスターに後れて、大きな遅延ができる。
アップデートによりキャッシュミスは、ディスクにいき、遅いI/Oの原因でレプリケーションが遅くなる。
書き込みパフォーマンスの増加は、たくさんのお金が必要になる。
それらのソリューションの１つは、データを２つのクラスタに分割することによって、トラフィックの優先順位を決めること。機能は、大部分のリソースを得なければならないように、人々はビデオを見ることを望んでいる。彼らが結うようでないクラスタへ送られることができるように、YouTubeのソーシャルネットワーキングの特徴は、重要ではない。

最後の年

データベースの分割（パーティショニング）
ユーザが割り当てた共有に異なった共有に分ける
ライトとリードを拡張する
IOを減らす意味でよりよいキャッシュの場所
結果的に、３０％のハードウェアの縮小
今、ほとんど任意にデータベースをスケールすることができる

データセンター戦略

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

教訓を学んだ

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

ソフトウェア: DB、キャッシング
OS: ディスクI/O
ハードウェア: メモリ、RAID

あなたはチームとして成功しています。システム全体を熟知する訓練されたチームとよい交流を持ちなさい。人々は、プリンタ、マシンをセットアップすることができ、ネットワーク、その他をインストールする。　よいチームとともに、すべてのものは可能だ。

注意

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

元ネタ

http://highscalability.com/youtube-architecture

参照しているページ (サイト内): [2007-08-07-1]

いつもシェア、ありがとうございます！

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

過去ログ

2020 : 01 02 03 04 05 06 07 08 09 10 11 12
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