Flickrには膨大な写真データがあり、かつアクセス頻度は、超人気の写真から、ほとんど見られないプライベートな写真まで様々あり。よって、ユーザに快適な閲覧体験を提供するには、世界各地に適切にキャッシュを配置することが大切。今回はそれを一歩進めて、キャッシュウォーミングで配信スピードを更にアップさせています。ユーザのブラウザが特定の写真とサイズを米国のデータセンタにリクエストする。データセンタから、ユーザのブラウザにフィットする、指定されたサイズの写真の所在をURL情報で返す。キャッシュされていれば、一番近くの地域のデータセンタからキャッシュを読込む。キャッシュされてなければ、米国のデータセンタから読込む。短い時間での読込みを実現します。具体的には、キャッシュがないリクエストだとわかればすぐに、米国のデータセンタからユーザの近くの地域のデータセンタにリクエストされた写真をプッシュして、ユーザは米国のデータセンタではなく、一番近い地域のデータセンタから読込みます(概念図)。これをうまく活用するために、いくつかのチューニングをしています。Yahooはデータセンタ間の全ての通信を暗号化しているが、このために安全な接続をセットアップする時間がかかりすぎて、写真データをプッシュするアクションが期待よりも遅れるという問題がでる。Warmerサーバと各地域のデータセンタの接続を常に維持する仕組みとした。Warmerに指示をするメッセージは定型であり、かつ多少の不達はあまり問題にならない。TCPのソケット/接続機能も必要としない。よって、HTTPの替わりに、UDPを利用してシンプルなJSONフォーマットを送る仕組みとした。Warmerが利用できない、もしくは遅延している際も、APIが遅くならないようにしたかったため。アクセスが多い写真データのキャッシュを無駄に繰り返さないように、最近Pushされたリストを保持することで、重複を60%カットした。Warmerの処理が追いつかなくなることを防いでいる。当初は、PythonのThreadPoolでつくり、プロトタイプもすぐできてパフォーマンスも悪くはなかったが、処理時間のほとんどがソケットコールでかかってしまっていた。そこで、Javaでそのまま置き換えることで、10倍処理能力を増やすことができた。最初に導入したヨーロッパでは、配信時間の中央値で200ms、95%の写真が100ms短縮できたとのこと。従来は写真のクオリティ重視で、データの圧縮はあまりしてなかったが、ワイヤレス経由の接続が増えているので、そこは方針転換。ケースによっては、WebPの採用もテストしている。ユーザの閲覧クオリティは、間に介するインフラの状況により、突然変わることがある。動的にルーティングを変更する仕組みの導入を考えている。Flickrでは同じ写真でも指定するサイズが違えば、別途キャッシュしている。大きめのサイズの写真がキャッシュされていれば、キャッシュレイヤで小さめのサイズを生成することを検討している。#flickrワザノバTop200アクセスランキングBack。