Nishant Roy氏は、Pinterest Engineering Blogに、広告コーパスのスケーリング問題を克服するための戦略を書いている。彼らの既存のソリューションはスケーリングの限界に達していた。そのため、さらなる成長が必要であった。再設計により、広告インデックスがKey-Valueストアにオフロードされ、Goアプリケーションのガベージコレクションが最適化されて、広告コーパスのサイズが60倍に増加した。
Pinterestがプラットフォーム上でより多くの広告を扱える新しいパートナーシップを開始したとき、当時の基盤となる広告配信アーキテクチャが広告量の増加に対処できないことに気づいた。
アクティブな広告のインデックスは、数時間ごとにシステムに公開され、メモリに保持された。メモリの制約により、インデックスは9つのシャードに分割された。広告の量が増えると、メモリ要求も増え、システムのメモリが不足し始めた。
著者は、検討された最初の短期的な解決策として、シャードの数の増加と垂直スケーリングの適用（つまり、より大きな仮想マシンへの切り替え）をしたと報告している。著者によると、どちらも適切ではなかった。前者は、インフラストラクチャとメンテナンスのコストが増加することを意味するため、適切なソリューションではなかった。また、将来、より多くの再シャーディングが必要になる可能性もある。後者によって、サービスについて並行性の上限が問題であることがわかった。つまり、少数の仮想マシンでは以前と同じトラフィックを処理できなかった。
著者によると、将来を見据えた最善の解決策は、インデックスをメモリに保存するのをやめ、代わりに外部のKey-Valueデータストアを採用することであった。
著者は、この変更により、クラスタの自動スケーリング方法を時間ベースからCPUベースに切り替えることもでき、インフラストラクチャのコストを実際のトラフィックに沿ったものにできると述べている。このスイッチを使うと、より大きなクラスタが自動的にプロビジョニングされるため、トラフィックの増加に対するクラスタの復元力が高まる。移行のもう1つの利点は、起動のたびにインデックスを再作成する必要がないため、起動時間が「10分から2分[未満]に」短縮されたことである。
インデックスは現在外部データストアにあるため、著者は、インデックスデータをフェッチするために追加のリモートプロシージャコールを導入する必要があると述べている。独立したステップを並列化し、遅延時間の増加を補う短期間のローカルキャッシュを導入している。
著者によると、外部のKey-Valueストアに切り替えることで、インデックスのリアルタイム更新のメリットを享受できるようになった。
著者はさらに、彼らのシステムが大きな遅延スパイクにも苦しんでいると述べていた。Goアプリケーションでの過剰なガベージコレクションによって引き起こされたものである。短命のオブジェクトを優先する、オブジェクトプールを使う、未使用のフィールドを削除するなどの手法でメモリ使用量を最適化することで、テールレイテンシを大幅に削減した。
並列化とローカルキャッシングのバランスについては、一部のデータセンターのハードウェアとソフトウェアのアーキテクチャの調査で考察されている。