Pinterest、KubernetesとApache Helixで非同期コンピューティング・プラットフォームを刷新

Pinterestは次世代の非同期コンピューティング・プラットフォームであるPacerを開発し、大きくなり過ぎてスケーラビリティと信頼性の課題が生じた旧ソリューションであるPinlaterを置き換えた。新しいアーキテクチャは、ジョブ実行ワーカーのスケジューリングにKubernetes、クラスタ管理にApache Helixを活用している。

同社は以前、非同期ジョブ実行プラットフォームであるPinlaterを開発し、数年前にオープンソース化した。PinlaterはPinterestで長年にわたって本番環境で使用され、多くの重要な機能領域をサポートしてきた。同社はAWS EC2上で複数のPinlaterクラスタを運用し、毎分数百万のジョブを処理していた。

PinterestのソフトウェアエンジニアであるQi Li 氏とZhihuang Chen氏は、チームが新しいプラットフォームを構築するきっかけとなったPinlaterの課題を要約している。

ここ数年のPinterestの成長とPinlaterへのトラフィックの増加に伴い、スケーラビリティのボトルネック、ハードウェアの効率性、分離の欠如、ユーザビリティなど、Pinlaterの数々の制限が判明した。また、データストレージのスループットや信頼性に影響を与えるものなど、プラットフォームに関する新たな課題にも遭遇した。

チームは、特定されたすべての問題を既存のアーキテクチャーの中で解決は不可能であると結論づけ、その代わりに、Pinlaterの使用・運用経験を考慮し、次世代プラットフォームの構築に投資を決定した。

新しいアーキテクチャであるPacerは、ステートレスなThriftAPIサービス（Pinlaterと互換性がある）、データストア（MySQL）、ステートフルなデキュー・ブローカー・サービス、Kubernetes上で動作するジョブ実行ワーカープールで構成されている。Apache Helixと Zookeeperは、デキュー・ブローカーへのジョブ・キュー・パーティションの割り当てを管理するために使用される。

Pacerのハイレベル・アーキテクチャ（出典：Pinterest Engineering Blog）

デキュー・ブローカーはステートフルなサービスで、データ・ストアからジョブ・キュー・データをプリフェッチし、メモリにキャッシュしてレイテンシを削減し、エンキューとデキューのワークロードを分離する。各デキュー・ブローカーにはジョブ・キュー・パーティションのセットが割り当てられ、ジョブは単一のブローカーによって排他的にフェッチ・実行されるため、競合を回避できる。各ジョブキューには、Kubernetesでプロビジョニングされた専用のポッドプールがあり、異なるジョブタイプによるリソース消費の偏りの影響を排除する。

新しいデキューイングと実行モデルは、すべてのパーティションのスキャンを回避して、ホットパーティションからデータをフェッチする際のロック競合を緩和するなど、Pinlaterで発生した問題を軽減する。さらに、ジョブ・キュー用に構成された1つのパーティションで、エンキューイング順（FIFO）のジョブ実行をサポートする。

新しい設計では、Kafkaコンシューマーのトピック・パーティション割り当てと同様に、キュー・パーティションをデキュー・ブローカー・インスタンスに排他的に割り当てる必要がある。チームは、その機能を支援するためにApache Helixの使用を選択した。Apache Helixは汎用的なクラスタ管理フレームワークを提供し、クラスタを形成する一連のデキュー・ブローカ間でパーティションの割り当てを追跡するために使用される。HelixはApache Zookeeperを使用して、Helixコントローラーとデキュー・ブローカー・インスタンスに組み込まれたHelixエージェントの間でリソース設定を通信する。

Apache HelixとZookeeperによるデキュー・ブローカーの調整（出典：Pinterest Engineering Blog）

Helix Controllerは、クラスタへのデキュー・ブローカ・インスタンスの参加と退出、および設定されたジョブキューの変更を監視し、変更があれば、キュー・パーティションのブローカへの理想的な配分を再計算する。最新のパーティション割り当てがZookeeperに保存されると、個々のブローカー・インスタンスは内部状態を更新し、担当するキュー・パーティションのデータをフェッチする。