Medium上のPinterest Engineeringに... ノート

Medium上のPinterest EngineeringによるRSSストーリー

Medium上のPinterest Engineeringは、人気のある視覚的な発見プラットフォームを駆動する技術的なイノベーションを裏側から紹介します。技術者が、スケーラビリティ、機械学習、データインフラストラクチャーなどに関する彼らの仕事の洞察を深く掘り下げています。出版物は、協力、実験、複雑な問題を解決する熱情を強調するPinterestのエンジニアリング文化を強調します。読者は、レコメンデーションシステムの構築、検索機能の最適化、データ分析のためのツールの開発など、多くのトピックを探検できます。この内容は、Pinterestのような大規模なプラットフォームの複雑さに興味のある技術者やテック愛好者にとって非常に有益です。画像認識の課題やインフラストラクチャーの進化など、愛されるオンラインの目的地の技術的な側面を覗くことができます。

ノートのスレッド

Pinterestの基盤モデルは、レコメンデーションシステムにとって極めて重要であり、毎日何百万人ものユーザーに影響を与えています。当初、これらの大規模モデルのマルチノードトレーニングはパフォーマンスが悪く、マシンの追加はプロセスを劇的に遅くしていました。ネットワーク改善のためにAWS Elastic Fabric Adapter(EFA)を使用しても、スケーリングは非効率なままでした。プロファイリングにより、分散埋め込みルックアップが重大な通信ボトルネックを引き起こし、GPUがデータの到着を待っていることが明らかになりました。チームは、この通信オーバーヘッドに対処するためにいくつかの最適化を実装しました。Quantized Communications(QComms)は、埋め込みテンソルを圧縮することでデータペイロードを削減しました。Balanced shardingは、GPU間のワークロード分散を改善しました。Bandwidth-aware embedding optimizationは、埋め込み次元を半分にすることでデータ移動を削減しました。重要なブレークスルーは、当初AllReduceを最適化するために実装された2D Parallelismであり、ローカル通信を改善しました。最終的に、2D ParallelismのトポロジーをAll-to-Allを最適化するように反転させ、高コストな操作をノード内で維持し、ノード間の同期にはより安価なAllReduceを使用しました。これにより、ほぼ線形のスケーリングが実現し、2ノードで2.0倍、4ノードで3.9倍、そして8ノードで印象的な7.5倍のスケーリングを達成しました。これらの進歩により、より大きなモデルのトレーニングが可能になり、Pinterestのレコメンデーションサーフェスでのユーザーエンゲージメントの大幅な向上と、より迅速な実験サイクルが実現しました。
CdXz5zHNQW_MsiwuAmomZ.png
Pinterestは、KafkaベースのCDCインジェストプラットフォームのために、堅牢な自動スキーマ進化フレームワークを開発しました。スキーマの変更は、重要なクロスシステム契約であり、チェックされていない進化はパイプラインの故障やデータの不一致につながる可能性があります。彼らの解決策は、スキーマの進化を安全、繰り返し、スケーラブルにすることに焦点を当てており、多段階の収束プロセスとして扱います。アーキテクチャには、CDCソース、Kafka、Flinkによる変換、Icebergテーブルへのupsert用のSparkが含まれます。コアコンポーネントの1つは、安定した数値識別子を持つスキーマ定義ファイルを真実の源として使用する信頼性の高いオンボーディングモデルです。更新は、バージョニングと監査を伴うPRベースのロールアウトを介して、Kafka、Flink、Spark、Iceberg全体に自動的に伝播します。システムは、後方互換性を維持し、複雑さを最小限に抑えるために、主に加法的なスキーマ変更をサポートしています。型の変更は、数値精度の拡大などの意味の保証を伴うものに厳密に制限されています。スキーマの進化は、パイプラインの可用性を維持するために、3段階の収束モデルで管理されます。フェーズ1ではIcebergスキーマを更新し、フェーズ2では更新されたFlinkとSparkコードをデプロイし、フェーズ3ではデータの収束を確保します。この段階的なアプローチにより、スキーマの伝播とデータの正確性が切り離され、定義されたSLA内で一時的な乖離が許容されます。Pinterestは、スキーマの進化のためにSLAベースのモデルを採用しており、予測可能性と運用の安全性を優先しています。デプロイ戦略は、特にFlinkの場合、データの損失を防ぐために慎重に管理されます。デフォルト値やプライマリーキーの変更などのサポートされていない、またはあいまいなケースには、特定の手動での復旧パスがあります。CREATE TABLEのあいまいな差分は、テキストの変更から意図を推測するのではなく、データベースの実際のDDL履歴と比較して解決されます。同時に発生するスキーマの変更は、競合状態を防ぐために順番に処理され、シリアル化された収束が保証されます。列の変換は、必要な変換をスキーマに注釈付けし、それらをインジェストパイプラインに注入することで管理されます。エラーの処理と復旧メカニズム、特にSparkの故障の場合、処理が最後の成功したウォーターマークから再開されることを保証します。
CdXz5zHNQW_srAU1TSiiq.png
このテキストは、Pinterestにおけるユーザーシーケンスプラットフォームの再設計について説明しており、MLモデルのためのユーザー行動データを取得するための堅牢で効率的なシステムを提供することを目的としています。コアゴールは、トレーニング、分析、サービング全体で、一貫性があり、新鮮で、完全で、コスト効率の高いシーケンスを提供することです。プラットフォームは、ユーザーシーケンスを、最近の、エンリッチされたイベントの順序付けられたリストとして定義します。対処された主な課題には、さまざまなユースケースやチーム全体でのデータ鮮度、完全性、一貫性、スケーラビリティの確保が含まれます。このソリューションは、「1つの定義、複数のランタイム」アプローチを採用しており、コンフィギュレーション・アズ・コードと共有実行エンジンを使用して、イベントをリアルタイムおよびバッチで処理します。プラットフォームは、現在のデータと履歴データの両方を管理するためにラムダアーキテクチャを実装しています。この設計により、新しいイベントタイプやエンリッチメントのオンボーディングが容易になり、コードレビューが改善され、リアルタイム処理とバッチ処理間のドリフトが削減されます。3つの重要な設計上の決定は、シーケンスとエンリッチメントのためのコンフィギュレーション・アズ・コード、共有実行エンジン、およびシーケンスのためのラムダアーキテクチャです。その結果、社内のさまざまなMLタスクのためのユーザーシーケンスの構築、保守、および利用プロセスを簡素化するプラットフォームが実現しました。
CdXz5zHNQW_ofSjTVKPmX.png
AIエージェントの使用において、特にカスタムスキルを呼び出す必要がある場合に、エンジニアは信頼性の問題を経験しています。これを解決するために、特定のiOSアーキテクチャスキルを使用したエージェントのテストが実施されました。目標は、スキルの呼び出し信頼性を定量化し、最適化手法を特定することでした。Bashスクリプトに基づいたコアテストツールが構築され、プロンプトを使用した自動テストのオーケストレーション、ログのキャプチャ、結果の確認が行われました。スキルの呼び出し能力を評価するために、ポジティブおよびネガティブなテストケースが定義され、使用されました。ログ解析手法が実装され、JSON出力パターンに基づいてスキルの呼び出しを検出しました。成功率や精度などの主要なパフォーマンス指標が計算され、エージェントのパフォーマンスが評価されました。初期テストにより、両方のエージェントが不完全なスキル呼び出し率を示し、特に曖昧なプロンプトの場合に顕著であることが明らかになりました。スキルの説明の強化、積極的な言語の使用、スキルテーブルの追加など、いくつかの最適化が発見されました。複数の手法を組み合わせることで、特にCodexエージェントにおいて、改善された結果が得られました。結論として、スキルの呼び出しプロセスのテストと改善の重要性が強調されました。開発者は、AIエージェントの効果を最大化するために、高品質で徹底的なプロンプトを使用する必要があります。
CdXz5zHNQW_AFL9DXaCyE.png
著者らは、Pinterestにおける広告レコメンデーション、特にRelated Pinsのようなコンテキスト固有のサーフェスを改善するために、Contextual Sequential Two Tower Modelを開発しました。初期のモデルはリアルタイムのコンテキストが欠如しており、過去のユーザー行動のみに依存していたため、その効果が妨げられていました。これを解決するために、モデルのアーキテクチャにコンテキスト層を統合し、モデルがユーザーの現在の活動からの情報を組み込めるようにしました。学習中には、コンバージョンイベントから派生した疑似コンテキストを注入した合成データを使用して、モデルを学習させました。ハイブリッドサービングフローが採用され、ユーザータワー処理のほとんどはオフラインで行われますが、コンテキスト層はオンラインで処理されます。これにより、リアルタイムのコンテキストに影響される動的なユーザー埋め込みが可能になり、関連性が向上します。オフライン評価では、以前のプロダクションモデルと比較してRecall@Kが大幅に改善されました。新しいモデルは、候補の生存率を向上させ、特にRelated Pinsサーフェスでの広告の関連性を改善しました。これにより、特にReturn on Ad Spend (ROAS) において、コンバージョン関連のビジネス指標が測定可能な増加を示しました。今後の作業には、Searchのような他のサーフェスへのモデルの拡張や、クロスアテンションのような高度なフュージョン技術の実験が含まれます。この研究は、広告の関連性とユーザーエクスペリエンスを向上させるために、リアルタイムのコンテキストを組み込むことの重要性を示しています。
CdXz5zHNQW_rmxcXIRNOK.png
Pinterest のオンライン ML サービングシステムは、クライアントサービスが Pin のスコアをリクエストするルートリーフアーキテクチャを使用しています。ルートコンポーネントは特徴量の取得と前処理を処理し、リーフはモデル推論を実行します。これは多くの場合 GPU 上で行われます。この設計は、新しいモデルのオンボーディングを簡素化し、CPU と GPU のワークロードを分離することでリソース利用率を最適化します。しかし、多くの特徴量を渡すことによるルートとリーフパーティション間のネットワークボトルネックが生じました。当初、ネットワーク使用量を削減するために lz4 圧縮が実装され、帯域幅の大幅な節約につながりましたが、CPU 使用率とレイテンシがわずかに増加しました。これは良いスタートでしたが、不要な特徴量を送信するという根本的な問題は残っていました。この問題に対処するために「Send What You Use」アプローチが開発され、特定のモデルが必要とする特徴量のみを送信するようにしました。モデルの入力と出力を定義するモデルシグネチャは、特徴量要件の信頼できる情報源として機能します。モデルはトレーニングおよびエクスポートされる際に、そのシグネチャが一緒に保存されます。Leaften はこれらのシグネチャをロードして、必要な特徴量のみを処理する特徴量コンバーターを構築します。ルートとリーフ間で特徴量要件を同期するために、モデルシグネチャは軽量なアーティファクトとして公開されます。これらのシグネチャはバンドルレベルのマッピングに集約され、既存の設定とともにルートにデプロイされます。このデプロイは、モデルのロールアウトと同じ段階的な配信プロセスに従い、一貫性を確保し、円滑なロールバックを可能にします。この統合により、Feature Trimmer はルート上の特徴量許可リストを動的に更新でき、必須の特徴量のみが送信されることを保証します。システムは、バージョン管理されたルックアップとフォールバックメカニズムを使用して、頻繁なモデル更新と段階的なロールアウトを処理するように設計されています。これにより、ルートの特徴量要件ビューが、リーフにデプロイされた実際のモデルと同期した状態に保たれます。不要な特徴量をトリミングすることにより、Pinterest はネットワークトラフィックを大幅に削減し、インフラストラクチャの効率を向上させました。
CdXz5zHNQW_Pr67hugpQp.png
Pinterestは、オフサイトのコンバージョンデータが疎でノイズが多いという課題に対処するため、コンバージョン広告専用の候補生成モデルを開発しました。このモデルは、従来のエンゲージメントベースのシステムとは異なり、ファネルの下位にあるコンバージョンに焦点を当てています。2023年の最初のローンチでは、クリック率の向上など、コンバージョンとエンゲージメントの両方の指標において大幅な改善が見られました。2025年のさらなる反復では、コンバージョン価値がさらに向上し、広告主の広告費用対効果が向上しました。データ疎性を解消するため、このモデルはマルチサーフェスアプローチを使用して、すべてのショッピングサーフェスでトレーニングされています。主要なコンバージョンシグナルをオンサイトのエンゲージメントデータで補完し、ノイズを軽減するためにクリックデータを期間に基づいて再重み付けします。エンゲージメントのない広告インプレッションなどのより厳しいネガティブサンプルは、より堅牢な対照学習に使用されます。このモデルには、リアルタイムの意図と長期的な好みを捉えるユーザー側の特徴と、セマンティックな理解とパフォーマンス追跡のためのPin側の特徴が組み込まれています。DCN v2とMLPを並列に配置した2つのタワーアーキテクチャは、特徴の相互作用モデリングと検索品質を向上させます。このモデルは、マルチヘッド設計から統合されたマルチタスクアーキテクチャに進化し、サービング中にマルチタスク最適化から直接的な恩恵を受けることができるようになりました。広告主レベルの損失関数が導入され、コンバージョンシグナルに対してより安定した粒度を提供し、大幅なリコール改善につながりました。この新しいモデルは、ショッピングのコンバージョン量を増やし、広告主のパフォーマンスを向上させると同時に、ユーザーのショッピング体験を向上させることに成功しました。
CdXz5zHNQW_iZkUUBsGZ2.png
Pinterestは、コンテンツ理解を活用して配信とエンゲージメントを促進しており、画像と外部リンクに関する洞察が必要です。中心的な問題はURL正規化であり、追跡パラメーターのために同一の商品ページが異なるURLで表示されることです。この冗長性により、繰り返しのフェッチと処理を通じて計算リソースが無駄になります。アイテムの正規化は、異なるURLで表現される同一のアイテムを統合することを目的としており、ショッピングカタログにとって不可欠です。アイテムIDが存在しない場合、高度なURL正規化は重複排除に不可欠です。MIQPS(Minimal Important Query Param Set)アルゴリズムは、コンテンツの同一性に影響を与えるURLパラメーターを自動的に学習します。これは、ページコンテンツに影響を与えない中立的なパラメーターと、影響を与える非中立的なパラメーターを区別します。既知のプラットフォームでは静的なルールが機能しますが、Pinterestの広範なドメインセットには、動的でデータ駆動型のアプローチが必要です。MIQPSアルゴリズムは3つのステップで動作します。まず、Pinterestの取り込みパイプラインから、ドメインごとに観測されたURLのコーパスを収集します。次に、URLはクエリパラメーターパターンによってグループ化され、パラメーターが特定のコンテキストで分析されるようにします。これにより、異なるURLタイプに基づいてパラメーターを誤分類することを防ぎます。最後に、パターン内の各パラメーターについて、アルゴリズムはその重要性を経験的にテストします。異なるパラメーター値を持つURLをサンプリングし、元のURLと変更された(パラメーターが削除された)URLの両方についてコンテンツIDを計算します。パラメーターを削除すると、サンプルのかなりの割合でコンテンツIDが変更される場合、それは非中立として分類され、保持されます。そうでない場合、それは中立と見なされ、正規化のために安全に削除できます。各マーチャントドメインは独自のMIQPSマップを受け取り、ドメイン固有のパラメーターの意味を考慮に入れます。
CdXz5zHNQW_WVip85jMBw.png
PinterestのMLプラットフォームチームは、断続的なネットワーク接続の問題によりRayベースのトレーニングジョブがクラッシュするという問題に直面し、PinComputeチームが調査に乗り出しました。3ヶ月にわたる調査の結果、この障害はAWS EC2インスタンス上のENAネットワークドライバーのリセットと相関していることが明らかになりました。CPUの枯渇によって引き起こされるこれらのリセットは、高いシステムCPU使用率と関連していました。当初、チームはヒュージページやメモリ割り当て器の使用など、さまざまな解決策を試しましたが、いずれも問題を解決できませんでした。奇妙なことに、問題はPinterestのAWSアベイラビリティゾーンのうちの1つでしか発生していませんでした。perfとmpstatを使用したプロファイリングにより、単一CPUコアの飽和が発生しているインスタンスが特定されました。perfを使用した時間的プロファイリングにより、断続的に高いCPUリソースを消費するプロセスが原因であることが判明しました。そのプロセスはゾンビプロセスであることが特定されました。ゾンビの発見とそのCPU使用率およびネットワークドライバーのパフォーマンスへの影響は、システムボトルネックのより深い理解につながりました。
CdXz5zHNQW_ETi1Y6sqJq.png
CdXz5zHNQW_P4rt7zsLFA.png
モバイルアプリにとってパフォーマンスは、時計の時刻表示のようなデフォルト機能と同じくらい重要です。Pinterestは、主要なユーザーエクスペリエンス全体でパフォーマンスを測定、保護、改善することに重点を置いています。ユーザーがコンテンツを待つ時間を反映するユーザー体感レイテンシは、重要なパフォーマンス指標です。このレイテンシ、特にビジュアルコンプリートタイムの測定は、以前は複雑で時間がかかるものでした。ビジュアルコンプリートは大きく変動するため、カスタム測定ロジックが必要であり、パフォーマンス作業の妨げとなっていました。Pinterestのパフォーマンスチームは、プロダクトエンジニアがレイテンシデータに簡単にアクセスできるソリューションを求めていました。その結果、ビジュアルコンプリートロジックをベースUIクラスに統合し、あらゆるUIサーフェスのレイテンシを自動的に測定できるようになりました。このシステムは、ビューツリーをトラバースし、レンダリングの進捗状況を把握するために重要なメディアビューを特定して追跡することで機能します。この統合システムは、60以上のAndroidサーフェスでレイテンシデータを提供し、パフォーマンス監視を支援します。これにより、短命な機能を含むさまざまな機能間で公平なパフォーマンス比較が可能になります。この簡素化されたアプローチにより、パフォーマンスがすべてのエンジニアにとって可視化され、ユーザー体感レイテンシの最適化が促進されます。同様の実装は、iOSおよびWebプラットフォームにも拡張されています。
CdXz5zHNQW_E0CjwHBss6.png
「Pinterestのフィードレコメンデーションは、アイテムの選択と表示にカスケードシステムを使用しています。最終段階では、エンゲージメント、新しいユースケースの採用、ビジネス目標のバランスを取る多目的最適化に焦点を当てています。チームは、アルゴリズムとインフラストラクチャのアップグレードを通じて、この段階を時間をかけて改善しました。当初は、フィードの多様化のために決定点過程(DPP)アルゴリズムを使用し、ユーザーエンゲージメントの大幅な改善を示しました。その後、計算複雑性が低く柔軟性のあるスライディングスペクトル分解(SSD)を実装しました。SSDにより、品質目標を組み込むことが可能になり、特に注意が必要なコンテンツに対して「ソフトスペーシング」ペナルティを導入しました。このフレームワークは、制限的なフィルタリングを回避し、より良いユーザーエクスペリエンスを生み出します。システムインフラストラクチャは進化し、ロジックをモデルサーバーに移行することで、実験が容易になりました。多様性シグナルも改善され、より優れたピン類似性計算のために、視覚、テキスト、グラフの埋め込みが組み込まれています。コンテンツ品質シグナルを導入し、リアルタイムでの改善のために視覚的埋め込みをアップグレードしました。その後、セマンティックIDを追加して、より効果的な多様性制御のためにセマンティックな重複を管理しました。」
CdXz5zHNQW_DU2kVthyel.png
CdXz5zHNQW_qKc4D1jJuD.png
Pinterestは、AIエージェントを可能にするために、モデルコンテキストプロトコル(MCP)エコシステムを開発しました。MCPは、大規模言語モデルが統一されたプロトコルを使用してツールやデータと対話することを可能にします。このアーキテクチャは、複数のドメイン固有のクラウドホスト型MCPサーバーで構成されています。中央レジストリがこれらのサーバーを管理し、発見と認証を提供します。エンジニアはツールを記述でき、プラットフォームがデプロイメントを処理します。プラットフォームは、内部AIチャットなど、既存のワークフローにMCPを統合しました。セキュリティは最優先事項であり、専用の標準と、JWTとメッシュIDを使用した2層認証が採用されています。ビジネスグループベースのアクセスゲーティングは、機密性の高いアクションのリスクを軽減します。安全のために、機密性の高い操作には人間による承認が必要です。このシステムは、影響分析のために、入出力のログを記録することで、可観測性を備えています。MCPエコシステムは、エンジニアの時間を大幅に節約しており、月間66,000回以上の呼び出しがあります。Pinterestは、サーバーを追加し、ガバナンスを洗練させることで、MCPの使用を拡大する計画です。
CdXz5zHNQW_HIoRCChfU2.png
Pinterestは膨大なデータウェアハウス向けのテキストからSQLへの機能向上のためにAnalytics Agentを開発しました。彼らはデータの規模と複雑さ、多数のテーブルと多様な分析ニーズという課題に直面しました。エージェントは統一されたコンテキスト意図埋め込みを活用し、クエリの意味を捉え、意味的理解を保証します。同時に、構造的・統計的なパターンを抽出し、ガバナンスのメタデータを取り入れて結果をランク付けします。データウェアハウスは当初、クリーンアップと標準化が必要であり、それが段階的な分類を含むテーブルガバナンスプログラムにつながりました。分析的知識はクエリ履歴から符号化され、単純なキーワードマッチングを超えています。SQLクエリは自然言語の記述に翻訳され、3段階のプロセスを経て元の分析意図を捉えます。一般化可能な記述や分析的な質問が再利用可能な知識ベースを作り出します。この自然言語記述は、意図ベースの検索のためにベクトル表現に埋め込まれます。構造的および統計的パターンも抽出され、結合パターンや集約パターンも含まれます。これらのパターンはガバナンスのメタデータと組み合わさり、ガバナンス意識の高いランキングシステムに情報を提供します。エージェントはこれら二つの次元を活用し、分析の質問に対する回答を生成し検証するために必要な情報を提供します。
CdXz5zHNQW_RcLxSqw9JO.png
Pinterestは、ユーザーの長期的な目標を理解し、インスピレーションから実現までのプラットフォームになることを目指しています。そのために、興味、意図、コンテキストによって定義される「ユーザー Journey(旅)」を導入します。これらのJourneyは、単純なコンテンツのレコメンデーションを超えて、ユーザーのインタラクションを分析することで推測されます。このシステムは、「リーン」なアプローチで構築されており、ユーザーデータからキーワードをクラスタリングしてJourneyを特定します。動的なキーワード抽出と階層的クラスタリングを使用して、柔軟でパーソナライズされたJourneyを生成します。その後、Journeyの命名、拡張、ランキング、多様化を適用して、ユーザーエクスペリエンスを向上させます。ステージ予測モデルは、適切な通知のためにJourneyのライフサイクルを決定します。出力は、名前、キーワード、ステージ、信頼度スコアを持つ、明確なユーザーJourneyのリストです。LLM(大規模言語モデル)は、Journeyの関連性を評価し、システム改善を導くために使用されます。Journeyを意識した通知に関する実験では、ユーザーエンゲージメントが大幅に向上しました。さらに、PinterestはLLMを積極的に活用して、Journeyの推論全体を簡素化および改善しています。同社は、LLMのファインチューニングと、効率的な実行のためのスケーラブルなバッチ推論の実装を積極的に行っています。
CdXz5zHNQW_jljfgPqEKe.png
PinterestのMLトレーニングプラットフォームであるMLEnvは、PyTorchのバージョンアップ後、著しいパフォーマンス低下に見舞われました。この問題は、トレーニングスループットを50%以上も減少させました。デバッグプロセスは、GPUの屋根型スループットの調査から始まりました。この測定では、データローダーを除外しても20%のパフォーマンス低下が明らかになりました。さらに、個々のモデルモジュールに焦点を当て、遅延の原因を特定するための分析が行われました。特定のTransformerモジュールであるモジュールAが、主な原因として特定されました。PyTorchプロファイラーは、以前は存在していたCompiledFunctionsが、アップグレードされたバージョンではこのモジュールに対して存在しなくなっていることを示しました。torch.compileの調査では、非インフラストラクチャPyTorchディスパッチモードが存在し、torch.compileがそれをサポートしていないことを示すログが発見されました。最小限の再現可能なスクリプトは、この問題がトレーナークラス内で具体的に現れることを確認しました。問題のあるコンポーネントは、デフォルトで有効になっているFLOPsカウントに使用されるコンテキストマネージャーであることが特定されました。このコンテキストマネージャーを無効にすると、torch.compileの問題が解決し、CompiledFunctionsが復元されました。しかし、この修正はエンドツーエンドのスループットを改善しませんでした。焦点はデータローディングと分散トレーニングの側面に再び移り、Ray.dataが原因ではないことが、ネイティブPyTorchアプリケーションとして実行した場合でも同じGPU屋根型スループットの問題が観察されたことから除外されました。いくつかの観察結果は、断続的な遅いイテレーション、同期中のストラグラー効果、そしてNvidiaのNsight Systemsプロファイラーを有効にすると遅延が解消されるという奇妙な動作を指摘しました。単一GPUでのテストにより、分散トレーニングが根本原因ではないことが確認されました。Rayセットアップでtorch.compileを完全に無効にすると、元のスループットが回復し、torch.compile内のグラフブレイクが遅延に関連していることが示唆されました。広範なグラフブレイクを持つ最小限の再現可能なモデルを作成した結果、遅いイテレーションが繰り返し発生することが観察されました。Nsight Systemsトレースは、これらの遅いイテレーション中にメインのトレーニングスレッドがグローバルインタプリタロック(GIL)を保持していることを明らかにしましたが、これはすべてのポーズを説明するものではありませんでした。Linuxのperfツールを使用したさらなる分析と、chrome://tracingによるトレースの可視化により、疑わしいPythonプロセスが浮き彫りになりました。このプロセスは、高コストな計算、具体的には仮想メモリ統計を収集するsmap_gather_statsというLinuxカーネルコールを実行していました。
CdXz5zHNQW_ahqFK2Jga1.png
Pinterestは、老朽化したHadoopベースのシステムを置き換えるために、次世代データ処理プラットフォームであるMokaを開発しています。このプラットフォームは、AWS Elastic Kubernetes Service (EKS) 上にデプロイされ、テスト、開発、ステージング、本番の4つの環境で稼働しています。EKSクラスターのデプロイは、カスタムAWSモジュールとHelmチャートで拡張されたTerraformによって管理されています。Mokaの重要なコンポーネントは、そのロギングインフラストラクチャであり、Fluent Bitを使用して、EKSコントロールプレーン、Sparkアプリケーション、およびシステムポッドからAmazon S3にログを収集し、エクスポートしています。Fluent Bitは、SparkアプリケーションのログをユニークなジョブIDでグループ化し、YuniKornのログを解析してリソース使用量の概要を把握するように設定されています。可観測性のために、PinterestはPrometheus互換のフレームワークを使用してメトリクスを収集しています。彼らは、既存のTSDBベースのStatsboardシステムとPrometheusメトリクスをブリッジするために、カスタムサイドカーであるkubemetricsexporterを開発しました。OpenTelemetry Collectorは、テレメトリデータの受信、処理、エクスポートに使用され、Prometheusメトリクス用に特定のパイプラインが構成されています。この堅牢なインフラストラクチャは、Pinterestの大規模なデータ処理を効率的かつ信頼性の高いものにすることを目指しています。
CdXz5zHNQW_slhDyOmW2y.png
Pinterestは、ユーザーベースの拡大に伴う技術的複雑性の増大により、エンジニアリングの速度に課題を抱えていました。同社は、分散型のツール導入戦略がボトルネックを生み、新しいエンジニアにとって圧倒的な状況を作り出していることを認識していました。この課題に対処するため、PinterestはPinConsoleという内部開発者プラットフォームを構築することで、開発者体験を再構築することを決定しました。PinConsoleは、オープンソースのBackstageプラットフォーム上に構築された統合開発者ポータルです。このプラットフォームアプローチは、一貫した抽象化レイヤーを作成することを目的としており、エンジニアがインフラストラクチャではなくビジネスロジックに集中できるようになります。様々なソリューションを評価した後、Pinterestは、強力なコミュニティでの採用、拡張性の高いプラグインアーキテクチャ、そして活発な開発を理由にBackstageを選択しました。PinConsoleは、Pinterestの内部認証システムおよびLDAPと統合されており、統一されたエンティティモデルを実現しています。アーキテクチャは、データストレージにPostgreSQLデータベースを使用し、UIの一貫性のためにPinterestのGestaltデザインシステムを適用しています。主要なコンポーネントの1つはPinComputeプラグインであり、これはPinterest固有の抽象化を使用してワークロードの管理を簡素化するカスタムKubernetes統合です。GitHub統合のようなパーソナライズされたホームページウィジェットは、コンテキストスイッチを減らし、関連情報を提供することで、開発者体験をさらに向上させます。
CdXz5zHNQW_JMlsyqEFEB.png
Pinterestの検索インフラストラクチャであるManasはKubernetesに移行されましたが、100万回の検索リクエストに1回、通常よりも100倍時間がかかるというパフォーマンスの問題が発見されました。この問題は調査され、原因は監視プロセスであるcAdvisorであることが判明しました。cAdvisorは、プロセスが参照するメモリの合計バイト数を計算するために30秒ごとにページテーブル全体をスキャンしており、Manasのメモリ集約的なリーフ処理との競合を引き起こしていました。これが検索リクエストのレイテンシスパイクの原因となっていました。調査には、検索システムのプロファイリング、パフォーマンス問題のデバッグ、Linuxカーネルの機能、メモリ管理が含まれていました。根本原因は、デフォルトで有効になっておりメモリ競合を引き起こしていたcAdvisorのワーキングセットサイズ(WSS)推定であることが特定されました。この問題は、すべてのPinComputeノードでcAdvisorのWSS推定を無効にすることによって解決されました。この修正はPinterestのKubernetesプラットフォームにとって大きな成果であり、他のオンラインサービスをプラットフォームに移行できるようになりました。この調査は、リソース分離、問題空間の絞り込み、ブラックボックスデバッグ戦略の重要性を浮き彫りにしました。この経験から、時には十分な解決策で十分であり、前進するために正確な解決策を見つける必要はないことも示されました。
CdXz5zHNQW_dc6w46JhEJ.png
Pinterestのデータエンジニアリングチームは、現在のHadoopベースのプラットフォームであるMonarchを置き換えるための、新しい大規模データ処理プラットフォームを構築しています。チームは、ビッグデータコミュニティでの人気と採用の増加により、Kubernetesベースのシステムを代替として検討しました。新しいプラットフォームは、コンテナの広範なサポート、PinterestのカスタムSparkフォークの実行、および運用・保守コストの削減といった特定の基準を満たす必要がありました。チームは、さまざまなプラットフォームでSparkを実行するための包括的な評価を実施し、コンテナベースの分離とセキュリティ、デプロイの容易さ、組み込みフレームワークといった利点から、Kubernetes中心のフレームワークに傾倒しました。Kubernetesは、他のシステムよりもコンテナ管理とデプロイに対して、よりきめ細かなサポートを提供しますが、データ管理、ストレージ、処理の組み込みサポートは不足しています。チームの現在のHadoopでのデプロイモデルは煩雑であり、Terraform、コンテナイメージ、Helmを使用した、よりシンプルなアプローチに移行しています。新しいプラットフォームは、Monarchを置き換えるためにKubernetesとEKSを活用しますが、EKSを既存のPinterest環境に統合することや、Hadoopコンポーネントの代替を見つけることなど、いくつかの課題があります。チームは、機密性のないデータのみにアクセスするバッチSparkワークロードを処理できる新しいプラットフォーム「Moka」を構築しており、将来的にはさらに機能を追加する予定です。Mokaの初期のハイレベル設計には、Spinner、Archer、Spark Operatorなどの一連のコンポーネントを通じて、ジョブが提出・処理されるバッチSparkワークロードを処理できるシステムが含まれています。チームは、次のブログシリーズでプラットフォームのコアアプリケーション中心の側面について、さらに詳細を提供する予定です。
CdXz5zHNQW_bbfzbQhJcm.png
Pinterestでは、MLエンジニアが、遅いデータパイプライン、コストのかかるフィーチャーイテレーション、および非効率的なコンピュート使用によるフィーチャー開発、サンプリング戦略、およびラベル実験の最適化に挑戦しています。 これらの課題に対処するために、Pinterestは、Rayの機能をトレーニングの範囲を超えてフィーチャー開発、サンプリング、およびラベルモデリングに拡張しました。 伝統的なMLインフラストラクチャーは、遅いデータパイプライン、コストのかかるフィーチャーイテレーション、および非効率的なコンピュート使用によって制限されていました。 Pinterestは、4つの主要な改善に焦点を当てて、RayネイティブのMLインフラストラクチャースタックを導入しました。 それは、Ray DataネイティブのパイプラインAPI、Iceberg Bucket Joinsによる効率的なデータジョイン、データの永続化による効率的なイテレーション、および大きなワークロードに対するRay Dataの最適化です。 新しいRayパワーのMLワークフローは、MLイテレーションの時間を10倍短縮しながら、インフラストラクチャーのコストを大幅に削減しています。 Ray DataネイティブのパイプラインAPIは、Ray内でフィーチャー開発、サンプリング、およびラベル変換をネイティブに実現し、Sparkのバックフィルを必要としません。 Iceberg Bucket Joinsは、異なるソース間での高速かつ効率的なフィーチャージョインを可能にします。 データの永続化は、変換されたフィーチャーをキャッシュし、適用可能な場合に再使用することで効率的なイテレーションを実現します。 Ray Dataの最適化は、異なるパイプラインで2-3倍のスピードアップを達成し、Pinterestではよりスケーラブル、効率的、およびコスト効果的なMLインフラストラクチャーを実現しています。
CdXz5zHNQW_vBYaC4X7rO.png
ピンタレストは、広告の取得にオンライン近似最近傍探索(ANN)を使用していますが、オフラインANNも、大規模なデータ処理やコスト効率の良い運用に役立ちます。オフラインANNは、オフラインで候補を事前に計算するため、高スループットと低遅延のクエリ応答、および比較的静的なクエリコンテキストのシナリオに適しています。ピンタレストはオンラインANNを成功させましたが、広告在庫の拡大に課題を抱えています。階層型ナビゲーション可能な小世界(HNSW)から逆ファイル(IVF)アルゴリズムへの移行により、より大きな階層インデックスを実現できますが、コストが増加します。オフラインANNは、豊富な計算リソースと遅延許容度の利点があり、静的なクエリコンテキストを持つ候補生成器に効果的です。オンラインとオフラインのアプローチの主な違いは、ANN検索のタイミングです。オフラインANNには、コスト効率と拡張性などの利点がありますが、リアルタイムの制限や固定近傍などの欠点もあります。ピンタレストは、類似アイテム広告や視覚的埋め込みなどのいくつかのユースケースで、オフラインANNベースの取得を評価しました。オフラインANNは、より良いエンゲージメントとコンバージョン性能を示しており、ピンタレストは将来の進歩のために独自のオフラインANNフレームワークとプラットフォームを積極的に開発しています。
CdXz5zHNQW_OYKi1HZH8r.png
ピンタレストのホームフィードは、ユーザー エンゲージメントと発見のために不可欠であり、ユーザーの関心とパーソナライズされたピン関連性に基づいてピンをランク付けする2段階のプロセスを使用しています。 Pinnability モデルは、ニューラル ネットワークを使用して、さまざまなピン、コンテキスト、およびユーザー信号を消費しますが、生涯のユーザー行動をモデル化するには限界があります。 TransActV2 モデルは、これらの課題に対処するために、長いユーザー シーケンスを活用し、Action Loss 関数を統合し、スケーラブルなデプロイメント ソリューションを採用しています。 TransActV2 は、最大 16,000 のユーザー アクションをモデル化し、明示的なアクション フィーチャーを統合し、アクション ロスレスに int8 量子化を適用します。 モデルは、広いスタック上のマルチ ヘッド、ポイント ワイズ マルチ タスク ネットワークを使用し、Next Action Loss 関数を導入して、ユーザー アクションの予測を強化します。 NAL 関数は、モデルに、エンゲージメントの確率だけでなく、ユーザーが次に行うアクションも予測することを課題としています。 モデルは、オフライン メトリックとオンライン メトリックの両方で、トップ 3 リピン ヒットの 13.31% の増加とリピンの 6.35% の増加を達成します。 モデルの工業規模のエンジニアリングにより、効率的なサーブとデプロイメントが実現され、p99 モデル ラン ラテンシーの 75-81% の低下と、エンド トゥ エンド インフェレンス ラテンシーの 103-338 倍の低下を達成します。 TransActV2 の実世界での影響は大きく、数百万のより意味のあるエンゲージメントとユーザー エクスペリエンスの改善を実現しています。
CdXz5zHNQW_kxoAAaP5LS.jpeg
ピンタレストの大規模データインフラストラクチャーは、AWS上のYARN on Hadoopを使用し、Auto Scaling Groups(ASGs)を使用して大量のデータを処理しています。同社は、クラスターの作成と管理のためにTerraformを使用していますが、スケーリングイン(ダウンサイジング)は複雑なプロセスであり、手動でのステップが必要です。 このプロセスを簡略化するために、ピンタレストはHadoop Control Center(HCC)を導入しました。これにより、クラスターの自動スケーリングインとアウトが可能になりました。HCC以前は、スケーリングインには、ノードを選択して除外ファイルに追加し、最後に終了するという退屈でエラープローンなプロセスが必要でした。HCCは、このプロセスを簡略化することで、ユーザーが望むASGサイズを指定するだけで、ツールが残りの作業を処理します。HCCは、クラスター管理のための他の有用ツールも統合しています。これには、ノードのステータスを表示、YARNアプリケーションのレポート、サブネットとセキュリティグループの情報を示すことが含まれます。HCCのアーキテクチャーは、マネージャーノードとワーカーノードで構成されており、マネージャーが中間者としてキャッシュを保持しています。Hadoop Operations Server(HOS)はHCCのコアであり、JMXキャッシュの更新、ファブリック接続の維持、除外ファイルの更新などの重い作業を処理しています。HCCは、JMXデータを定期的に照会し、統合して、ノードの廃棄プロセスを管理しています。
CdXz5zHNQW_GmhHD5ubWA.png
Pinterestの社内開発者アンケートによると、技術ドキュメントが最大の課題であり、その問題は品質と発見可能性に集約されていることが明らかになりました。ドキュメント作成マラソンや、上級リーダーからの熱心な呼びかけといった従来の解決策は、持続的な改善をもたらしていません。2021年、Pinterestは新たなアプローチを試み、ドキュメントツールとプロセスを強化するためのさまざまな戦略を探求することにしました。その中でも「docs-as-code」戦略に焦点を当てました。このイニシアチブはPDocsと呼ばれ、技術ドキュメントの品質を向上させ、Pinterestにおけるドキュメンテーションの文化を変革することを目的としました。「docs-as-code」の理念は、マークアップ言語、ソース管理、コードレビューツール、静的サイトジェネレーターなどを使用して、コードと同じプロセスでドキュメントを作成することを含みます。この戦略を採用することにより、Pinterestはドキュメントの問題を解決し、優れたドキュメンテーションの実践、品質管理、および発見可能性を促進することを目指しました。PDocsは、さまざまなファイルパスとリポジトリからドキュメントプロジェクトを自動的に配置し、単一の中央集中型ドキュメントサイトを生成するために開発された、カスタムビルドの静的サイトジェネレーターです。PDocsは、エンジニアがシンプルな設定ファイルとMarkdownファイルを任意のリポジトリにドロップし、マージされると中央集中型ドキュメントサイトに表示されるような、開発者エクスペリエンスを実現します。PDocsのUIはプロジェクト中心に設計されており、お気に入り、最近閲覧した項目、および「公開」または「ドラフト」設定などの機能を備え、読者の信頼を維持しています。
CdXz5zHNQW_I5dnAJn3pO.png
Pinterestは、Pinnersと呼ばれるユーザーが人生の様々な側面に関するインスピレーションやアイデアを見つけに集まるユニークなプラットフォームです。プラットフォームの目標は、ユーザーの興味や検索に関連するコンテンツを表示し、パーソナライズされた体験を提供することです。Pinterestのパーソナライゼーションに対するアプローチは、プラットフォーム上での滞在時間よりも質の高い時間を優先するため、他のプラットフォームとは異なります。同社は、コンテンツランキングに対するさまざまなアプローチのバランスが必要であると考えており、明示的なエンゲージメントシグナル、コミュニティガイドライン、およびアンケートベースのパーソナライゼーションを組み込んでいます。Pinterestは、ユーザーからのフィードバックを収集し、より健康的でインスピレーションに満ちた体験を生み出すためにアンケートを使用しています。プラットフォームのアンケートは、厳格かつ効果的に設計されており、専門家チームがアンケートが適切に設計され、役立つようにしています。これらのアンケートは、Pinterestがユーザーにとってポジティブでインスピレーションに満ちた体験を生み出す上で非常に重要な役割を果たしており、最近の調査では、ユーザーのウェルビーイングへの影響という点で、Pinterestが業界をリードしていることが示されています。Pinterestのパーソナライゼーションへのアプローチは、「インスパイアされたインターネット誓約」の原則に導かれており、これは企業がユーザーのウェルビーイングを優先し、より健全なインターネット体験を生み出すことを求めています。アンケートを使用し、ユーザーのウェルビーイングを優先することで、Pinterestは、より安全で健全なオンライン体験を生み出すことが可能であることを証明しています。全体として、Pinterestのユニークなパーソナライゼーションへのアプローチとユーザーのウェルビーイングへのコミットメントは、他のソーシャルメディアプラットフォームとは一線を画しています。
CdXz5zHNQW_xMjUEWeEAQ.png
ピンタレストのホームフィードのレコメンデーションは、マルチステージデザインを採用し、洗練されたプリランキングレイヤーでビジネスメトリクスを改善した。初期のデザインには、デプロイメントの努力、モデル自動再トレーニングの挑戦、アイテムの相互作用を効果的に学習できないツインタワーアーキテクチャーの制限があった。チームは、プリランキングレイヤーの近代化のために基礎的な改善を行い、新しいシステムデザイン、ログパイプライン、サーブアーキテクチャーを実施した。新しいデザインには、リクエストレベルのサブコンポーネントとアイテムレベルのサブコンポーネントが共同トレーニングされ、サーブ中には切り離される。チームは、プリランキングとランキングを区別し、バイアスのかからないデータをトレーニングに導入するために、早期の漏斗型ログパイプラインを実施した。サーブアーキテクチャーのデザインには、CPUとメモリーのオーバーヘッドを緩和するルートリーフアーキテクチャーを含む。チームは、L2ランカーとのプリランキングモデルのより良いアラインメントのために、モデルディスティレーションを実施した。オンラインの実験では、重要なエンゲージメントの勝利を示し、チームは、新しいエンゲージメントデータを活用するための自動再トレーニングフレームワークを設定した。チームは、モデリングイノベーション、データサンプリング、モデルアーキテクチャーの改善、ロスエクスプロレーション、サーブの最適化について継続的に作業を進めている。
CdXz5zHNQW_P7QrX8S0r6.png
Pinterestでは、最新のレコメンデーションおよび広告モデルを、数十ペタバイトのデータに基づいてトレーニングし、ユーザーが愛する生活をカーケートすることをミッションとしています。これらのモデルは、ユーザーの関心に合ったコンテンツを提示するパーソナライズドレコメンデーションを駆動しています。新しい機能の実験は一般的なタスクであり、最初のステップは、新しい機能をトレーニングデータセットに統合することです。最も直接的な方法はForward Loggingですが、この方法には、高いカレンダー日コスト、高い開発時間コスト、分離の不足、リソースの無駄と不安定という課題があります。Feature Backfillは、これらの課題を解消するために一般的に使用される代替手段です。このブログポストでは、著者たちは、コストと反復時間を最大90倍削減するためのFeature Backfillソリューションの作成方法を探索しています。著者たちは、Sparkを使用してトレーニングテーブル内の機能を実体化する初期のバックフィルソリューション。これは、オンデマンドのMLエンジニアによってトリガーされる再利用可能なAirflow DAGとして運営します。ただし、このソリューションには、同時バックフィルがない、高いコンピュートコスト、手動パーティション管理という課題があります。これらの課題を解消するために、著者たちは、2段階のバックフィルアプローチを採用したv2バージョンを開発しました。このアプローチは、プロセスを2つの主要ステージ、Feature StagingとFeature Promotionにストリームライン化しています。
CdXz5zHNQW_YKhzxUkvad.png
ピンタレストの実験プラットフォーム、ヘリウムは、製品の決定とビジネス戦略のためのインサイトを日々生成しています。ただし、実験の規模が拡大すると、上流のデータインジェストの遅延、スキップされたメトリックのバックフィル困難、頻繁なスケーラビリティの問題となったため、ピンタレストは、ユニファイド・ダイナミック・フレームワーク(UDF)を開発しました。UDFは、実験メトリックの計算を変革するためのスケーラブルかつ堅牢なソリューションです。UDFは、100倍のメトリックをサポートし、将来的には500倍のスケールアップを目指しています。これにより、メトリックの配信を加速し、エンジニアリングの労力を月単位から日単位に削減しています。フレームワークは、メトリックの処理を標準化し、インフラストラクチャーの課題やパイプラインの作成の複雑さを解消しています。UDFは、上流の依存関係、バックフィル複雑さ、スケーラビリティの問題を解消し、実験の速度化とイノベーションを可能にしています。フレームワークは、開発者の速度、フレキシビリティ、スケーラビリティ、スピード、信頼性を向上させ、イノベーションやビジネスアウトカムを推進しています。メトリックの計算の標準化は、実験プラットフォーム全体にわたり大きな改善をもたらしており、実験を強化し、ユーザーに価値を提供しています。UDFは、ピンタレストにおける実験メトリックの計算を革命化し、将来的にはその影響がさらに拡大する予定です。
CdXz5zHNQW_HsQvhLZ0Fu.png
マルチゲート ミクスチャー オブ エクスパート(MMoE)モデルのアーキテクチャーは、専門のサブネットワーク(エクスパート)に動的にリソースを割り当てることで、広告エンゲージメント モデリングを改善します。これにより、単一のモデルよりも効率、汎化、およびマルチタスク ラーニングが改善されます。MMoE は、DCNv2、MaskNet、FinalMLP などの異なるアーキテクチャーのエクスパートを、パフォーマンスとコストに基づいて戦略的に選択しています。モデルはまた、インフラストラクチャー コストを削減するために混合精度推論と軽量ゲート レイヤーを利用しています。既存の生産モデルから新しいモデルへの知識の移転により、知識蒸留がモデルをさらに改善します。これにより、データ保持期間の制限によるパフォーマンスギャップを緩和し、新しいモデルが歴史的なデータから学習することができます。蒸留は、オフラインおよびオンラインのメトリックを大きく改善し、ベースラインの DCNv2 モデルを超えています。この技術は、バッチ トレーニングやモデル再トレーニングのシナリオ、例えば機能アップグレードの際に有益です。ただし、インクリメンタル トレーニング中には過学習を防ぐために蒸留を削除します。MMoE と知識蒸留の組み合わせアプローチにより、プラットフォーム上での広告マッチングの質とユーザー エクスペリエンスが大幅に向上します。これにより、より関連性の高いレコメンデーションとユーザー エンゲージメントの向上を実現します。
CdXz5zHNQW_Eh609KFgJk.png
CdXz5zHNQW_u2LVnNpu5X.png
Pinterestはビジュアル検索エンジンとしてAWS上で稼働しており、コンピューティング基盤にはAmazon EC2インスタンスを使用しています。同社は、EC2インフラストラクチャ、特にオンラインストレージシステムの管理において、EC2のネットワークパフォーマンスとそのアプリケーションの信頼性とパフォーマンスへの影響に関する明確な洞察が不足しているという大きな課題に直面していました。この問題に対処するため、PinterestはEC2フリートのネットワークパフォーマンス監視を開発し、ネットワークバーストを管理するための手法を実装することで、重要なオンラインサービスワークロードの信頼性の高いネットワークパフォーマンスを確保しました。同社は、ユーザーシーケンスの提供において問題を抱えており、これは大きなユーザーエンゲージメントの向上をもたらしましたが、同時にサービスレイテンシとアプリケーションタイムアウトを引き起こしました。EC2インスタンスの移行中、Pinterestは多くのクラスタでパフォーマンスの著しい低下を経験し、アプリケーションタイムアウトが発生しました。同社は、ネットワーク許容量を超えるマイクロバーストが原因で、EC2インスタンスがネットワークスロットリングを受けていることを発見しました。EC2ネットワークスロットリングの動作をより透明にするため、Pinterestはethtoolなどのツールを使用して、EC2インスタンスで生のカウンターにアクセスできるようにインスタンスをアップグレードしました。同社は内部メトリクス収集エージェントを修正し、これらのカウンターをスクレイピングしてメトリクスストレージに取り込みました。これらのENAメトリクスをEC2フリート全体に展開することで、PinterestはAWSトラフィックシェーピングに関する前例のない可視性を獲得し、ネットワークスロットリングを軽減するための様々な最適化を実装しました。同社はまた、きめ細かいS3レート制限、データバックアップチューニング、ネットワーク圧縮など、ネットワークバーストを処理するための手法も検討しました。
CdXz5zHNQW_DGfWhUSLvs.jpeg
ピンタレスト検索は、ユーザーが自分の情報ニーズに合ったインスピレーションを得ることができる重要な機能であり、検索の関連性は、検索結果が検索クエリとどれだけ一致するかを測定します。検索の関連性モデルを改善するために、クエリとピン(画像)の関連性を測定するための5段階のガイドラインが使用されています。クロスエンコーダ言語モデルを使用して、ピンの関連性を予測し、ピンテキストとともに、タスクはマルチクラス分類問題として定式化されています。モデルは、人間が注釈をつけたデータを使用して、クロスエントロピー損失を最小化することでファインチューンされています。各ピンを表現するために、ピンのタイトルと説明、合成画像キャプション、エンゲージメントの高いクエリトークン、ユーザーが作成したボードのタイトル、リンクのタイトルと説明など、さまざまなテキスト機能が使用されています。ただし、クロスエンコーダLLMベースのクラシファイアーは、ピンタレスト検索のリアルタイム遅延とコストの考慮により、拡大するのが難しいです。したがって、知識の蒸留を使用して、LLMベースの教師モデルを軽量な生徒関連モデルに蒸留しています。生徒モデルは、クエリレベルの機能、ピンレベルの機能、およびクエリとピンの相互作用機能を使用して、5段階の関連性スコアを予測します。知識の蒸留と半教師あり学習を使用して、生徒モデルを訓練し、初期にラベル付けされていない大量のデータを効果的に活用し、世界中のさまざまな言語にデータを拡大しています。オフライン実験では、言語モデルの比較、テキスト機能の豊富化の重要性、蒸留を通じてトレーニングラベルの拡大などの各モデリングの決定の有効性が実証されています。オンライン結果では、nDCG@20によって測定された検索フィードの関連性が+2.18%改善され、世界中で検索の充実率が大幅に増加しました。提案された関連性モデリングパイプラインは、トレーニング中に遭遇しなかった言語にも効果的に一般化し、マルチリンガルLLMベースの関連性教師モデルは、見られない言語にも一般化します。将来的には、提供可能なLLM、ビジョンと言語のマルチモーダルモデル、およびアクティブラーニング戦略の統合を探求して、トレーニングデータの品質を動的に拡大して改善することを目指しています。
CdXz5zHNQW_lGLj8VappE.png
CdXz5zHNQW_KWYxv46AiQ.png
ピンタレストは、ホームフィードにモジュールを導入し、ユーザーにさらなるコンテキストとトピックの探索方法を提供しました。モジュールは、トピック、ボード、ショッピングの関心など、異なる要因に基づいてUIとコンテンツが異なる、異種のものです。モジュールには、ランディングページモジュールとカラウスルモジュールの2種類があります。ホームフィードの体験を最適化するために、モジュールの関連プラットフォームが開発され、モジュールとピンを動的にブレンドすることになりました。このプラットフォームには、モジュールの疲労、モジュールのランキング、モジュールのブレンドなどの複数のコンポーネントが含まれています。モジュールの疲労は、ユーザーが何度も見たモジュールを隠すために初期的に使用されました。しかし、このアプローチには、フィード内でのモジュールの表示方法や場所を指定できない、リアルタイムに対応できないなどの制限がありました。これらの制限を克服するために、モジュールのランキングモデルが開発され、モジュール同士をランク付けすることになりました。このモデルは、モジュールとユーザーの包括的なフィーチャーセットを使用し、タップ、クリック、保存などのモジュールのアクションを最適化するためにユーザーのエンゲージメントデータをトレーニングしています。モジュールのブレンドは、モジュールとピンを動的にブレンドしてフィードを生成する方法を決定します。初期のアプローチでは、順序付けられたモジュールを静的な固定スロットに配置していましたが、これは、予測されたエンゲージメントスコアに基づいてピンとモジュールを動的にブレンドする「スキップスロット」アプローチに置き換えられました。このアプローチでは、比較関数を使用して、モジュールとピンの予測されたエンゲージメントスコアに基づいて、モジュールがピンを置き換えるかどうかを決定します。モジュールの関連プラットフォームは、生産環境に展開され、リアルタイムの監視メトリクスが開発されました。将来的には、magnitude-based ranking and blending、Pin displacement-based blendingなどのコンポーネントを繰り返し、関連性をさらに改善する予定です。
CdXz5zHNQW_MhpJYPzJiz.png
PinterestのインフラストラクチャーVP、マドゥリ・ラチェルラは、AWS ReInvent 2024カンファレンスで、パフォーマンスの最適化とコスト削減のための会社の旅程を共有しました。Pinterestのミッションは、553万人以上の月間アクティブユーザーにインスピレーションを与え、愛する生活を創造することであり、プラットフォームはアイデアやクリエイティビティのハブです。会社のインフラストラクチャーは、数十万のEC2インスタンスの上に構築され、Amazon S3では約1エクサバイトのデータを保持し、ユーザーのコンテンツを安全かつアクセス可能に保証しています。成長に追いつくために、Pinterestは、フレキシビリティ、信頼性、およびコスト効果のためのインフラストラクチャー戦略を洗練しています。会社は、AMD M7aインスタンスにEPYC Genoa CPUを採用し、コンピュート・バウンド・マイクロサービス・パフォーマンスを改善し、最大40%のコスト削減を実現しました。M7aインスタンスへの移行は、Pinterestのインフラストラクチャーイノベーションとスケーラビリティに対するコミットメントを示しています。マドゥリは、移行の戦略的ステップ、ワークロード分析、インスタンス選択、および包括的なテストを行ったことを詳しく説明し、サービス・レベル・オブジェクティブに影響なく、スピーディーに移行を完了しました。Pinterestの強化は、パフォーマンスとコスト効果を高めるという会社の献身を示し、現在および将来のニーズに合わせたインフラストラクチャーを整備しています。マドゥリのプレゼンテーションは、エンジニアに境界を超えることを呼びかけ、将来の成功の舞台を整える戦略的選択を促すものでした。今日の賢明な決定によって、Pinterestは、未来のより大きな可能性の基盤を整えています。
Pinterestは、指標の変動を理解するための根本原因分析(RCA)プラットフォームを開発した。 このプラットフォームは、スライス&ダイス、一般的類似性、実験効果という3つの主要なアプローチを採用している。 スライス&ダイスは、様々な次元のメトリクスセグメントを分析し、変化の重要な要因を突き止める。 この手法はリンクトインのThirdEyeからヒントを得ており、ツリー構造を使ってメトリクスセグメントを整理し、その重要性をスコアリングする。 一般的な類似性は、類似性を測定するために相関とダイナミックタイムワーピングを使用して、類似した動きのパターンを持つメトリクスを特定する。これは、パフォーマンスやコンテンツ配信のような、一見無関係に見えるメトリクス間の関係を明らかにするのに役立つ。 実験効果 実験がメトリクスに影響を与えたかどうかを判断するために、A/Bテストの結果を調べます。 ウェルチのt検定と調和平均p値を用いて、ノイズや不均衡のフィルタリングを行いながら、実験の影響を評価する。 これら3つのアプローチは、包括的な分析のために繰り返し使用することができる。 将来的な改良点としては、ユーザーからのフィードバック機構と、より強力な因果推論のための因果発見の活用がある。 より多くのデータ・プラットフォームやユーザー・インターフェースとの統合も計画されている。 このプラットフォームの成功は、ユーザーからのフィードバックと継続的な改善にかかっている。 チームは、このプラットフォームの開発におけるPinterestのエンジニアとデータサイエンティストの貢献に謝意を表する。
CdXz5zHNQW_ydRcPLqWkc.png
ピンタレストのホームフィードでは、埋め込みベースの検索が高度にパーソナライズされたコンテンツを取得するための主要な候補ジェネレーターです。チームは、2つのタワーモデルに高度なフィーチャークロッシングとID埋め込みを導入して、モデルのパフォーマンスを改善しました。フィーチャークロッシングはモデルの主要なコンポーネントであり、チームは、MaskNetやDHENなどの異なるテクニックを実験してアーキテクチャーをスケールアップしています。MaskNetは、フィーチャーベースの乗算テクニックであり、モデルアーキテクチャーを簡略化し、広範囲のフィーチャークロッシングによる高学習性を実現します。DHENは、複数の異なるフィーチャークロッシングレイヤーを系列および並列方式でアンサンブルするフレームワークであり、モデルのさらなる改善をもたらします。チームはまた、クロスサーフェス的大ウィンドウデータセット上での対比的学習によるプリトレンドID埋め込みを採用しています。ただし、埋め込みを直接ファインチューニングするとオーバーフィッティングが生じるため、チームは、埋め込みテーブルを固定し、アグレッシブドロップアウトを適用することでこの問題を緩和することを発見しました。チームはまた、時間減衰和を使用してPinのスコアを決定し、トレーニングデータとサーブコーパスのギャップを埋めるためにサーブコーパスを改修しました。さらに、チームは、マルチ埋め込み検索や条件付き検索などの最新のモデリングテクニックを探索し、埋め込みベースの検索モデルのパフォーマンスをさらに向上させています。これらのテクニックは、ユーザー エンゲージメントとレコメンデーションフンネル効率の改善に大きな影響を与えています。
CdXz5zHNQW_nRsW3jGDPy.png
Pinterestでは、ユーザーが愛する生活を創造することをミッションとしており、オンライン上での適切なコンテンツの発見がこのミッションにとって非常に重要です。同社のレコメンデーションシステムは、ユーザーに適切なコンテンツを提供するために、複数のステージ、つまり検索とランキングを含みます。ランキングモデルは、ユーザーの長期的および短期的なエンゲージメントを捉える強力なトランスフォーマーベースのモデルですが、検索システムは以前はヒューリスティックアプローチに基づいておりました。同社は、この改善のために、ログされたユーザーエンゲージメントイベントから学習された内部の埋め込みベースの検索システムを構築し、ホームフィードと通知に展開しています。このシステムは、2つのタワーアプローチを使用し、1つのタワーがクエリーの埋め込みを学習し、もう1つのタワーがアイテムの埋め込みを学習することで、オンラインでの効率的な近傍検索を可能にします。モデルは、人気バイアスを補正するためにサンプルドソフトマックスアプローチを使用してトレーニングされ、ユーザーの長期的なエンゲージメント、プロフィール、およびコンテキストが入力としてエンコードされます。システムデザインでは、アイテムの埋め込みをオンラインでの提供とオフラインでのインデックスに分割し、自動的な再トレーニングワークフローを使用してユーザーの最新のトレンドを捉えます。モデルバージョンの同期を確保するために、各ANN検索サービスホストにモデルバージョンのメタデータが付与され、モデル名から最新のモデルバージョンへのマッピングを保持します。学習された検索候補ジェネレーターは、トップユーザー覆盖率とトップ3のセーブ率を達成し、サイト全体のエンゲージメントの勝利に大きく貢献しています。
CdXz5zHNQW_jl6TXRt0LH.png
PinterestのAPIプラットフォーム、NGAPIは、高いリクエスト成功率を確保するために最適化されたシステムパフォーマンスを必要とする。チームは、メモリー管理をストリームライン化し、効率を向上させるためにLightning Memory-Mapped Database(LMDB)を実装した。これにより、メモリー使用量が4.5%削減され、各ホストでより多くのプロセスを実行でき、CPUの利用率も向上した。マルチプロセスアーキテクチャーでは、プロセスごとのメモリー使用量が重要な要因であり、設定管理されたデータのロードも大きな影響を与える。チームは、各プロセスでの設定管理されたインメモリーのデータをホストごとに単一のコピーに切り替えることでメモリー圧力を低減することを目指した。3つのmmapベースのソリューションを評価し、LMDBを選択した。LMDBは、トランザクション内で生成されたファイルを更新することができるメモリー・マップド・ファイルに基づくエンベデッド・キーバリューデータ・ストレージ・ライブラリである。チームは、各設定管理されたデータ用のローカル・データベースを作成し、軽量のPythonサイドカーを開発してLMDBデータベースを更新した。APIプロセスは、LMDBに永続的な読み取り専用の接続を維持した。結果として、メモリー使用量が4.5%削減され、各ホストでより多くのプロセスを実行でき、ホストの総数も削減された。この最適化により、システムのレイテンシに影響を与えることなく、全体的なパフォーマンスと安定性が向上した。
CdXz5zHNQW_ZQ6PvJQHxR.jpeg
PinterestのコンバージョンAPIとタグは、広告キャンペーンの最適化とROIの分析に不可欠ですが、それらを実装することは複雑になる可能性があります。 2つの新しいNPMパッケージ、pinterest-conversions-serverpinterest-conversions-clientは、開発者にとってこのプロセスを簡素化します。 サーバーパッケージは、コンバージョンAPIを使用したサーバーサイドイベントトラッキングを容易にし、ハッシュ化されたユーザーデータなどの機能をサポートします。 クライアントパッケージは、Pinterestタグを使用したクライアントサイドトラッキングを、ブラウザから直接実行できるようにします。 両方のパッケージには、生産環境へのデプロイ前に検証するためのテストイベント機能が用意されています。 また、既存のプロジェクトへの簡単な統合を可能にする、クリーンで再利用可能なインターフェイスを提供します。 インストールはnpmを使用して簡単に行え、ドキュメントには使用例が含まれています。 機密データは適切にハッシュ化され、データ収集のための法的同意を取得する必要があります。 両方のパッケージは、MITライセンスの下でオープンソースであり、コミュニティからの貢献を歓迎します。 これらのツールは、コンバージョントラッキングを簡素化し、キャンペーンの最適化とROIを向上させます。 Pinterestエンジニアリングの詳細については、ブログ、ラボ、キャリアページをご覧ください。
CdXz5zHNQW_dIw0eAnzaq.png
ピンタレストは、既存の分離されたソリューションにおける不一致に対処するために、汎用のChange Data Capture(CDC)ソリューションを実装しました。この新しいシステムは、Red Hat Debeziumを利用しており、信頼性、スケーラビリティ、低遅延性を実現するように設計されています。アーキテクチャは、システム状態と構成を管理するコントロールプレーンと、変更を処理してKafkaに送信するデータプレーンを分離しています。KafkaはCDCデータを保存し、ユーザーはそれを使用できます。実装では、スケーラビリティの問題、リバランスタイムアウト、重複タスクなどのいくつかの課題を克服しました。解決策には、ブートストラップ、レート制限、タイムアウト構成の調整、Kafkaのアップグレードが含まれていました。これらの改善により、安定したシステムパフォーマンスと、フェイルオーバー回復時間の大幅な短縮が実現しました。将来的には、スケーラビリティの向上、CDCを使用したディザスタリカバリーの実装、リアルタイムデータベースインジェストシステムの作成が予定されています。このプロジェクトの成功には、ピンタレストの複数のチームが貢献しました。最後に、ブログ投稿には、商標に関する免責事項が含まれています。
Apache Kafkaは、Pinterestでペタバイト単位のデータを処理する一般的なPubSubソリューションとなっています。成長するストレージの需要に対応するために、Tiered Storageが登場し、ブローカーの高価なディスクから安価なリモートストレージにデータをオフロードするデザインパターンです。Kafka 3.6.0+のネイティブTiered Storageは、機能をブローカープロセスと緊密に結びつけるため、柔軟性が制限されます。Pinterestのブローカーと分離されたTiered Storageの実装は、ストレージとコンピュートを分離し、コスト削減、リソースの最適化、簡単な採用など、様々な利点を提供します。分離されたアプローチでは、完了されたログセグメントをリモートストレージにアップロードするSegment Uploader、データ消費のためのTiered Storage Consumer、単位あたりのストレージコストが低いリモートストレージシステムが使用されます。Segment Uploaderは、ブローカーのファイルシステムを監視し、完了されたセグメントを検出し、ZooKeeper(新しいKafkaバージョンではKRaft)を通じてリーダーシップの変更を検出し、データの連続性を確保するために耐久性を処理します。Tiered Storage Consumerは、ブローカーのローカルディスクとリモートストレージの両方からデータを読み取り、ブローカーがデータを提供するコストを削減します。この分離された実装は、2024年5月以降、ブローカーディスクから安価なオブジェクトストレージに約200 TBのデータを日々オフロードしています。これにより、Tiered Storageの採用と機能の更新において、ブローカーのパフォーマンスに影響を与えることなく、柔軟性が提供されます。PinterestがApache Kafkaのために開発したブローカーと分離されたTiered Storageのオープンソース実装が今、利用可能です。
Pinterestのインターンシップ・プログラムは、メンターとインターンをペアリングし、キャリアの発展を促進します。メンターは、インターンの職業的な旅を導くために、サポートと専門知識を提供します。ソフトウェア・エンジニアのIrena Leeは、彼女が受けたメンターシップを返すためにメンターになった。彼女のインターンに対するポジティブなオンボーディング・エクスペリエンスを育むことを目的としています。iOSエンジニアのRicardo Casilimasは、彼の変革的なインターンシップ・エクスペリエンスをインターンたちに与えることを目指し、自信とスキルを与えることを願っています。シニア・データ・サイエンティストのLily Liuは、メンターシップが彼女の仮定を疑わせ、新鮮な視点を彼女のメンティーたちから学ぶことができるようにするため価値があります。マシン・ラーニング・エンジニアのSujay Khandagaleは、メンターシップが個人的かつ職業的な成長を可能にすると信じています。マシン・ラーニング・エンジニアのDavid Xueは、彼のインターンシップ・メンターが彼を力づけたと述べ、インターンたちとのメンターシップが相互の学びを可能にするため楽しんでいます。Leeの最も記憶に残る瞬間は、彼女のインターンと会った時で、メンターシップの絆を強めることができました。Casilimasは、彼のインターンの成長と、自分の過ちから学びなおす決意に感銘を受けました。Liuは、彼女のインターンの進捗と、独立して課題に立ち向かう能力を楽しんでいました。Khandagaleは、彼のインターンがマシン・ラーニング・モデルを構築し、デプロイするプロセスを導くことが最も報酬的でした。Xueは、彼のインターンたちが彼を驚かせるアイデアとプロジェクトの実行方法を大切にします。
グーグー、Pinterestの時系列データベースは、グーグー・ショート・ターム(グーグーS)、グーグー・ロング・ターム(グーグーL)、グーグー・コンパクター、グーグー・ルートのサブコンポーネントで構成されています。Pinterestは、観察可能性チームのために2つの機能を実装し、コスト削減を実現しました:メトリクス・ネームスペースは、異なるメトリクス・ファミリーに対する柔軟なストレージ・コンフィギュレーションを許可し、Top Write Heavy Metricsの提供は、ブロックされるメトリクスを特定し、グーグーSに格納されるデータを削減します。グーグーS、コンパクター、インジェスターのアーキテクチャー変更は、リソース・フットプリントの削減を目的としています。メトリクス・ネームのインデックス改善は、メトリクス・ネームのストレージを最適化し、プロセス・メモリーの消費を大幅に削減しました。コンパクション改善は、メトリクス・ネームを辞書エンコーディングで表現し、メモリー使用量を削減しました。プロセス・メモリーの分析とクラスター・マシン・ハードウェアの評価は、適切なインスタンス・タイプの決定に役立ちました。グーグーSのメトリクス・ネームのメモリー消費量が、インデックス改善後、ホストあたり約9GB削減しました。観察可能性チームは、グーグーの機能を使用して、グーグーSに格納される時系列データを37%削減しました。グーグーLホストのディスク使用量が、約27%削減しました。これらの最適化により、Pinterestは大量のメトリクス・データをコスト効果的に格納し、処理することができます。