Pinterestが6人のエンジニアで1,100万人のユーザー規模まで拡大できた方法

Pinterestのスケーリングの歩み

Pinterestのスケーリングの過程は4つの段階に分かれます。

1. 自己発見の時代: 少人数のエンジニアチームが迅速なプロトタイピングと、変化し続けるプロダクト要件に対応。
2. 実験の時代: ユーザー数の急増によって迅速なスケールが必要になったものの、複雑で脆弱なシステムを招いた。
3. 成熟の時代: MySQL、Memcache、Redisのような成熟していてスケーラブルな技術を使ってアーキテクチャを単純化。
4. 回帰の時代: 適切なアーキテクチャを整えた後、水平方向にスケールして成長を継続。

中核技術

Pinterestは、信頼性、理解しやすさ、スケーラビリティを重視する技術を優先しました。

• MySQL: 安定していて保守しやすいリレーショナルデータベース。
• Memcache: 頻繁にアクセスされるデータをメモリにキャッシュし、データベースの読み取り負荷をオフロード。
• Redis: 多様なデータ構造を扱える柔軟なデータストア。
• Solr: すぐに使える検索プラットフォーム。

データベースのスケーリング: クラスタリング vs シャーディング

Pinterestは、データベースを分散処理するために2つのアプローチを検討しました。

クラスタリング

• データが到着すると最適なノードを決定し、データを複数ノードに複製。
• 自動スケーリング、設定の容易さ、データ可用性の確保といった利点がある一方で、複雑さ、成熟度不足、アップグレードの難しさといった欠点も存在。

シャーディング

• データを小さなチャンクに分割し、各チャンクを独立したサーバーに配置。
• シンプルなアーキテクチャ、独立したスケーリング、明確なデータ所有権といった利点がある一方で、データベースレベルの結合やトランザクションができないこと、アプリケーションの複雑性が増すことなどの欠点も存在。

Pinterestは、クラスタリングでの否定的な経験からシャーディングを選択しました。

シャーディングアーキテクチャへの移行

Pinterestは機能凍結の期間中、段階的にシャーディングへ移行しました。

1. JOINの排除: MySQLのJOINをすべて取り除き、データの非正規化とキャッシュを活用。
2. IDベースのシャーディング: 64ビットIDを基準にシャーディングし、データルーティングを単純化。

シャーディングの欠点と解決策

• マイグレーションスクリプト: データをシャーディング基盤へ移す過程に多くの時間がかかった。
• アプリケーションロジック: データベースレベルの結合やトランザクションがないため、データ整合性を維持する必要があった。
• スキーマ変更: すべてのシャードに対するスキーマ変更を計画し、適用。
• レポート生成: 複数のシャードを統合してレポートを生成。

教訓

Pinterestのスケーリングの歩みから得られた主な教訓。

• シンプルさが重要: 理解しやすい技術を選ぶことが、問題解決とリスク低減に役立つ。
• スケーラビリティを優先: 急成長する環境では、データベース機能を多少犠牲にしてでもスケーラビリティを優先。
• 水平スケールを前提に設計: ユーザーベースの拡大に応じてリソースを追加できるアーキテクチャを選ぶ。