flickr アーキテクチャ

flickrは主なフォト共有サイトです。flickrには、すばらしい挑戦があり、ますます拡大する新しいコンテンツ、増え続けるユーザ、新しい機能が絶えない状態の漫々たる海を処理しなければならず、素晴らしいパフォーマンスを提供する。それをどう実現するか？

flickr architecture

情報源

flickrとPHP (初期のドキュメント)
LAMPのためのキャパシティプランニング
Federation at Flickr: Flickrアーキテクチャツアー
FlickrのCal HendersonによるBuilding Scalable Web Sites
Database War Stories #3: FLickr by Tim O'Reilly

プラットフォーム

PHP
MySQL
Shards
キャッシングレイヤーのためのMemcached
HTMLが画像のためのSquid リバースプロキシ
Linux(RedHat)
テンプレートのためのSmarty
Perl
XMLとEメールのパーシングにpear
画像処理にImageMagick
ノードサービスにJava
Apache
デプロイのためにSystemImager
分散システムモニタリングにGanglia
Subconは、クラスタのマシンへの簡単な配布のためにsubversionリポジトリに必要不可欠なシステムコンフィグレーションファイルを格納します。
ネットワークを横切ったファイルの配布とアップデートにcvsup

どうなっているか?

統計

1日に40億を超えるクエリ
squidのキャッシュに〜35M photo
squidのRAMに〜2M photo
〜470M photo、それぞれ 4 か 5のサイズ
memcachedへの秒間リクエストは、38k (3.8万) (12M オブジェクト)
2PBのストレージ(日曜日にだいたい〜1.5TB 消費する)

静的コンテンツのためのだけのサーバを使う
unicodeを支えるための話
共有のないアーキテクチャを使用している
すべて(写真をのぞく)は、データベースに格納される
無国籍は、人々を近くのサーバに跳ね返すことができ、それはAPIを簡単にする。
最初にレプリケーションでスケールした、しかし、readの助けにしかならない
サーチしたちデータベースのパーティションをレプリケーションすることでサーチファームを作った
水平のスケールをするには、多くのマシンを追加する必要がある
ユーザからの写真のEメール処理は、PHPに渡される。Emailは、いくつかの写真にパースされる。
最初に、マスター - スレーブの遅延に悩んだ。過度のロードとシングルポイント障害が起きた。
サイトダウンをせずに、ライブメンテナンス、データ修復が必要だ。
キャパシティプランニングの素晴らしい教材がたくさんある。詳しくは、情報ソースをよく見なさい。
将来、はるかにスケールすることができるように、連合アプローチを進めなさい:

Shards: 私のデータは、私のShardに格納される。あなたのコメントのアクションを起こすレコードは、あたなのShardの上にあります。
Global Ring: DNSようなもの。あなたがどこに行くべきか、そして、誰があなたがどこにいくかについてコントロールするかわかっている必要がある。すべてのページビューは、あなたのデータの計算、時間のその瞬間。
PHPロジックは、Shardに接続し、データの一貫性を保たなければならない(10行のコメント付きコード)。

Shards:

メインデータベースのスライス
アクティブマスター - マスターリングレプリケーション: MySQL 4.1は少しの欠点があるが、マスター - マスターで機能することの名誉をたたえる
オートインクリメント IDは、それをアクティブにしておくことを自動化する。
Shardの割り当ては、新しいアカウントのためのランダムな数値からなる
マイグレーション(移動)はときどき行われるため、特定のパワーユーザを移動することができる。もしたくさんのフォトを持つならバランスをとることが必要だ、、、192.000の写真、700,000のタグ、約3-4分の時間がかかる。マイグレーションは手動で行われる。

お気に入りのクリック(Clicking a Favorite):

Shardの場所を得るために、キャッシュから写真のオーナアカウントを取り出す(syard-5でいう)
Shardの場所を得るために、キャッシュから私の情報を取り出す(shard-13でいう)
問いに答えるため分散トランザクションを開始する。誰が写真をお気に入りにしたか？私のお気に入りは何か？

どんなShardからでも質問することができ、データを復元する。完全に冗長だ。 - レプリケーションの遅延を取り除くために

すべてのページロードに、ユーザはバケツに割り当てる
ホストがダウンしたら、リストの次のホストに行く; すべてのホストがダウンしたら、エラーページを表示する。パーシスタントコネクション（永続的な接続）は使わない、コネクションを作り、すぐに切る
だからすべぺのページ読み込みは、接続をテストする。

すべてのユーザのreadとwriteは、１つのshardにとどめておく。レプリケーションの遅延の考えは、なくなる。
それぞれのサーバにあるshardの負荷は50%だ。それぞれのshardの半分のサーバをシャットダウンする。だから、1サーバのshardは、フルロードで使うことができるので、shardのサーバがダウンしたり、メンテナンスモードにすることができる。アップグレードするために、半分のshardをシャットダウンしなければならい。そして、そのプロセスを繰り返す。
激しい負荷の間、５０％ルールを破る。高負荷時は、秒間6,000-7,000の問い合わせがある。現在、秒間4,000の問い合わせのときに負荷が50%であるように設計されている。
ページあたりの平均問い合わせは、27-35SQLステートメントだ。お気に入りのカウントは、リアルタイムでやる。APIのデータベースへの問い合わせはすべてリアルタイムだ。リアルタイムの要求をやり遂げ、不都合はない。
秒間36,000を超える問い合わせ - キャパシティの基準内の実行。爆発的なトラフィックは36k/qpsを2倍にしなさい。
それぞれのshardは、400k以上のユーザデータを持つ

多くのデータは2倍格納される。例えば、コメントは、コメントした人とコミュニティの関係の1部である。コメントはどこに格納されるか？両方の場所はどうか？ｔランザクションは、データの同期がずれることを避けるために使われる: トランザクション 1のオープン、書き込みコマンド、トランザクション2のオープン、書き込みコマンド、最初のトランザクションがコミットされるならすべてうまくいく、もし最初のトランザクションがコミットがコミットされたなら、2番目のｔランザクションをコミットする。しかし、最初のコミットをしている間にボックスがダウンしたときの失敗のために可能性を鎮める。

検索、

２つの検索バックエンド: いくつかのshardとYahoo(独自仕様)のウェブ検索で35k qpsをshardsする
オーナのシングルタグ検索か、バッチタグ変更(Organizerを通して)は、Shardsへ行き、リアルタイム要求ですることになっている。他のすべては、ヤフーのエンジンに行く(おそらく、リアルタイムの良さの後ろ約90%)。あなたがLuceneのような検索を考えてください

ハードウェア

EMT64 w/RHEL4, 16GB RAM
6-disk 15k rpm RAID-10
16TBのユーザメタデータ(写真ではない。innodb ibdataファイル - 写真は非常に大きい)
2Uのボックス。それぞれの shardは、120GB程度のデータを持つ。

バックアップの手順

ibbackupはcron jobで行われる。ことなった時間に多種のshardを超えて実行される。スペアへのホットバックアップ。
スナップショットは、毎晩、全部なデータベースのクラスタを横断して取る
いくつかの大きなバックアップファイルの書き込みや削除はすぐに
一気にレプリケーションのfailstoreのいくつかの大きなバックアップファイルへの書き込みや削除は、ここ数時間のレプリケーションバックアップファイルをの実行を破壊することができる。プロダクションのフォトストレージのファイル整理をおこなうことは、間違った考えだ
しなしながら、あなたのデータをすべてバックアップするのに数日のコストをかけなければならない。これは価値がある。時差的なバックアップを保つことは、数日後に悪くなったことを気付くのによい。だいたい、1,2,10,30日のバックアップ。

写真はファイラに格納される。アップロードされ、写真は処理され、複数のサイズを与え、これで完成だ。
メタデータやファイラへのポインタは、データベースに格納される
データを集計すること: 非常に速い、それは、shardごとに行うから。tableに突き刺して、もしくは、他のユーザshardから他をコピーしてデータを復元する。
shardごとのmax_connections = 400、または、サーバごとに 800 コネクション。たくさんのキャパシティとコネクション。スレッドキャッシュは、45にセットする、それは、同時にアクティブな45ユーザ以上をもったことがないから。
タグ:

タグは伝統的な正規化されたRDBMSスキーマデザインにフィットしない。非正規化か、重いキャッシュは、何億ものタグからミリ秒でタグクラウドを生成する唯一の方法だ。
いくつかのデータビューは、オフラインでMySQLに結果を保存するための専用処理クラスタによって計算される。それは、関係を計算を完了させるのに、すべてのデータベースのCPUサイクルを消費するからだ。

学んだこと

あなたのアプリケーションをより多くのものと見なしてください。あたなは、REST API、SOAP API、RSS feed、Atom feed、などを持つ。
国籍をなくす。簡素化は、尻込みすることなくアップグレードを取り扱う強いシステムにします。
あなたのデータベースを再アーキテクト
キャパシティプラン。早期にプロダクトのキャパシティプランを議論に持って行きなさい。何かを見るための $$$ 人達(とエンジニアマネージメント)から任せろと引き受けてください。
ゆっくり始めてください。あなたのサイトを爆発させる恐れ/幸せになる間際に、あまりにたくさんの機材を買わないでください。
現実を評価しなさい。キャパシティプランニング計算は、現実に基づかなければならない、抽象的ではない。
ロギングと測定基準を作りなさい。
サーバベースの統計値を使った現実界を測定したカスタムな測定基準を組み込みなさい。
キャッシュ。キャッシングとＲＡＭはすべての答えだ。
要約。データベース作業、ビジネスロジック、ページロジック、ページマークアップ、プレゼンテーション層の間で抽象概念の明確なレベルを作りなさい。
レイヤー(層)。レイヤーは、開発者にページレベルのロジックを作らせ、デザイナーにユーザエクスペリエンスの構築をすることを許す。デザイナーは、必要に応じて、ページロジックを求めることができる。- レイヤー(層)。レイヤーは、開発者にページレベルのロジックを作らせ、デザイナーにユーザエクスペリエンスの構築をすることを許す。それは2人のメンバー間で交渉する。
頻繁にリリースしなさい。30分毎にさえ。
小さな効果を忘れなさい、時間の97%について。時期尚早なオプティマイズ（最適化）はすべての諸悪の根源だ。
プロダクションでのテスト

アーキテクチャメカニズム(設定フラグ、ロードバランシング、など)の組み込み

ベンチマークを忘れなさい。ベンチマークは、スケーラビリティの基本的なアイデアのために最適であるが、計画には賛成ではない。人工のテストは、人工の結果を与える。そして、時間は実際にテストでよりよく使われる。
上限を見つけなさい。

すべてのサーバが稼働する最大値はなにか？
あなたは、最大値にどれぐらい近いか、そして、どのように、それは傾いているか？
MySQL(ディスクI/O?)
SQUID(ディスクI/O?)
memcached(CPU?かネットワーク?)

アプリケーションのタイプのパターンの使い方に敏感にしてください。

イベントに関連した成長はあるか？例えば、災害、ニュースイベント
flickrは、元旦 1日目に前のピークの20-40%以上のアップロードを受ける。
あとの週より、平均して、日曜日に40-50%以上のアップロード
指数関数的な成長の要求にたいして、敏感でいなさい。
より多くのユーザは、より多くのコンテンツを意味し、より多くのコンテンツは、より多くのコネクションを意味し、より多くのコネクションは、より多くの使用を意味する。

ピークに対して、計画を立てなさい

ピーク時の負荷を処理できるようにし、スタックを減らしなさい。

元ネタ
http://highscalability.com/flickr-architecture

サイト
http://www.flickr.com/

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

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

過去ログ

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