Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用

Web上の画像や動画などを気軽にクリップしたり共有できるサービス「Pinterest」が大人気です。楽天が出資したことでも話題になっています。

Pinterest / Home

急速に人気が急上昇するWebサービスでは、どのようにスケールするアーキテクチャを構築し運用していくのかはサービスの成否を分けるほど重要です。Pinterestのように急成長してきたサービスのソフトウェア構成やリソース構成はどうなっているのでしょうか、Web上でいくつか情報が公開されているのでまとめてみました。

Pythonで開発し、Amazonクラウドで運用

1年ほど前なので少し古い情報ではあるのですが、Q&AサイトのQuoraにPinterestのco-founder Paul Sciarra氏が書き込んだソフトウェア構成の説明があります。

PinterestはPythonで開発されており、MemcachedやNginxなど高速なレスポンスに配慮した構成になっている様子がうかがえます。

「Pinterest: What technologies were used to make Pinterest? - Quora」の情報を整理して引用します。

• アプリケーションレイヤにはPythonと大きな変更を入れたDjango
• WebサーバにはTornadoとNode.js
• オブジェクトキャッシュ、ロジカルキャッシュにはMemcachedとMembase/Redis
• メッセージキューイングにRabbitMQ
• ロードバランシングと静的配信にはNginx、HAproxyとVarnish
• データストアにはMySQL
• マップリデュースにはAmazon EMRの上にMrJob
• そしてコード管理にgit

運用はAmazonクラウド上で行われているようです。Web層だけで150個以上のインスタンスを利用し、データの保存容量は410テラバイト。クラウドでないととてもこの成長を支えられませんね。

今週公開された記事「High Scalability - Pinterest Architecture Update - 18 Million Visitors, 10x Growth,12 Employees, 410 TB of Data」から、ポイントを整理して引用します。

• Web層には150個のAmazon EC2インスタンスを利用
• データベースへのロードを減らすために、90個のインスタンスをメモリキャッシュに利用
• 内部処理用に35個のインスタンス
• 8000万個のオブジェクトをAmazon S3に保存、総容量は410テラバイト
• 昨年8月と比較してS3の利用は10倍、EC2の利用は3倍に
• 70個のマスターデータベースと並列にバックアップ用のデータベースがあり、冗長性のために世界中のアベイラビリティゾーンに分散している
• もっともトラフィックが増大するのは午後から夕方なので、コスト削減のために夜にはEC2のインスタンスを40％まで減らしている。ピーク時には時間当たり52ドルのEC2の費用は、オフピーク時には15ドルにまで減少する
• Amazonクラウドの費用は、S3に3万9000ドル（約312万円）、EC2に3万ドル（約240万円）
• 昨年12月時点の従業員は12人、現在は31人の模様

この記事では「Pinterestの急成長、多数のユーザー、大規模データ、少人数はInstagramにとても似ている」と書いています。シリコンバレーではこのクラスの急成長サービスが複数存在し、そのためのノウハウも蓄積と共有されていっているのでしょう。

追記（2012/5/24）：オブジェクトシリアライザMessagePackの作者 古橋貞之氏から「Pinterestではmemcachedに「MessagePack」を組み合わせて使っているらしいですよ。（略）Pinterestのエンジニアから直接聞いたので間違いないです」とのコメントをいただきました。

関連記事

Publickeyでは、これまでも大規模なスケーラビリティを実現してきたサービスの仕組みを紹介してきました。よろしければあわせて以下の記事もお読みください。

• Facebookが大規模なスケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題
• Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
• グーグルが構築した大規模システムの現実、そしてデザインパターン（1）～MapReduce編
• グーグルが構築した大規模システムの現実、そしてデザインパターン（2）～BigTable編
• グーグルが構築した大規模システムの現実、そしてデザインパターン（3）～教訓編
• グーグルが構築した大規模システムの現実、そしてデザインパターン（4）～デザインパターン編
• Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側
• Twitterにおける大規模システム構築、3つの原則
• Twitterが、Ruby on RailsからJavaVMへ移行する理由