# Flickr 写真共有サービス。『ウェブオペレーション』3章の時点(2011年)では Yahoo! 傘下。ビジネスメトリクス(日次)・アプリケーション機能メトリクス(イベント単位)・システム/サービスメトリクス(Ganglia の RRD、15〜60秒間隔)という3層のメトリクス収集を運用し、6つのデータセンタから集約したリクエスト数の可視化、アプリケーションログ(Apache 応答時間等)のメトリクス活用、最終デプロイのタイムスタンプとメトリクスの突き合わせによる変更管理などを実践していた。 2007年、Yahoo! が Yahoo! Photos の閉鎖を決定した際、Flickr は移行先の選択肢の1つとなり、想定を大きく上回るユーザが移行した結果、ディスク消費量が急増する危機に直面した。メトリクス収集ツール(Ganglia)でストレージ消費率をリアルタイムに監視し、消費率に応じて移行キューの処理速度を動的に調整するフィードバックループを構築することで、ストレージを枯渇させずに移行を完了させた。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] §3.8) ## 開発と運用の協力(10章) 『ウェブオペレーション』10章([[Paul Hammond]] 執筆)は、Flickr の開発・運用協力の実践を詳述する。Web ベースのデプロイシステムは「ステージ」ボタン(リポジトリから最新コードをチェックアウトしビルドしてステージングへ配置)と「デプロイ」ボタン(ステージングのコードをプロダクションへ移動)の2つで構成され、1日10回以上のデプロイを実現していた。サーバ設定を Perforce、アプリケーションコードを CVS に別々に格納していたが、障害時に相互アクセスできないことが問題化し両者を SVN へ統合した。デプロイシステムの結果や Ganglia のアプリケーションレベルメトリクスは共有 IRC チャンネルへ通知され、開発者が本番の障害調整に直接関与できる仕組み(オンコール、admin 限定のライブデバッグ、フィーチャフラグ)を整えていた。写真サービス自体やメインデータベースとのやり取りを無効化するフィーチャフラグは意図的に持たない。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 10 開発と運用の協力と連携]] §10.1, §10.2, §10.4) ## コミュニティ管理(8章) 『ウェブオペレーション』8章は、編者ジョン・オルスポーが Flickr の元コミュニティディレクタ [[Heather Champ]] にインタビューする対談形式で、Flickr のコミュニティ運営の内側を語る。コミュニティマネージャは Flickrverse の編集・キュレーション、グローバルなオンラインイベントの主催、新機能ローンチ時のヘルプフォーラムでの告知、Abuse & Advocacy チームのサポートを担い、技術チームとコミュニティの間の情報の橋渡し役として機能していた。 2006年、保守作業中の事故でストレージに障害が発生し20 TBの写真がオフラインになった際、事前告知プロセスが無視されサイトが突然停止した。チャンプはメンテナンスページを Flickr のドット画像に置き換えて即興の塗り絵コンテストを開催し、3,000枚近いエントリを集めた。この経験を踏まえ、コミュニティマネージャとエンジニアで構成する事前確立のインシデントチームを持つこと、問題発生時にまず「認知し調査中である」事実を簡潔に伝え詳細は技術チームから共有可能な情報が来てから伝えること、コミュニティマネージャとカスタマケアチームを物理的に近い場所に置くことなどの実務が定着した。 新機能ローンチでは、プロダクト担当者・エンジニア・オペレーション・コミュニティマネージャが集まり起こりうる問題を事前に表計算ソフトで洗い出し、「最終決定会議(go or no-go meeting)」でローンチ日を全員の合意のもとに決定する(影響の大きいオペレーションチームが最終決定することが多い)。Flickr Video のローンチでは、ネットワーク障害の懸念から [[John Allspaw]](当時オペレーション)がローンチを5時間遅らせる判断をし、チャンプは「サイトが落ちる方が問題だ」としてこの判断を支持したというエピソードが語られる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]]) ## 継続的デプロイ(4章) 『ウェブオペレーション』4章(エリック・ライズ執筆)は、Yahoo!に買収される前からFlickrが継続的デプロイを行っていたと紹介し、[[John Allspaw]]の発言を引用する。専用の運用チームを持つことでMTTD(平均診断時間)が驚くほど短く、デプロイの変更が小さいため手戻りや意図しないパフォーマンス問題があってもすぐに原因を発見・修正でき、修正やロールバックが必要な変更も小さく限定されているためMTTR(平均復旧時間)も短い、という趣旨である。この例は、小さなバッチが問題を局所化するという同章の主張(→ [[バッチサイズ]])を裏付ける実例として引用されている。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.2) ## Velocity 2009講演(一次資料) 2009年6月、[[John Allspaw]]・[[Paul Hammond]] が O'Reilly Velocity 2009 で発表した「10+ Deploys per Day: Dev and Ops Cooperation at Flickr」は、『ウェブオペレーション』10章の元になった一次資料であり、2026年に wiki へスライド・音声込みで直接 ingest した([[@2009__Velocity2009__10+ Deploys Per Day - Dev and Ops Cooperation at Flickr]])。発表時点(2009年)の数値として「30億枚の写真を保有し毎秒4万枚を配信、6ペタバイトのストレージ」が挙げられており、これは10章・3章が扱う2011年前後の運用実態のおよそ2年前のスナップショットにあたる。(Source: [[@2009__Velocity2009__10+ Deploys Per Day - Dev and Ops Cooperation at Flickr]]) ## 関連 - ソース: [[@2009__Velocity2009__10+ Deploys Per Day - Dev and Ops Cooperation at Flickr]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 10 開発と運用の協力と連携]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 8 コミュニティ管理とウェブオペレーション]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] - 実体: [[Ganglia]] / [[Matthew L. Massie]] / [[Paul Hammond]] / [[Yahoo!]] / [[Heather Champ]] / [[John Allspaw]] - 概念: [[DevOps]] / [[フィーチャーフラグ]] / [[オンコール]] / [[コミュニティマネジメント]] / [[バッチサイズ]]