PubSubの使用例

レシピの分離

以下の例を考えてみましょう。 私たちの組織は、WebToLead HTTPリクエストを受け取った後にSalesforceにリードを作成するレシピを持っています。このレシピは、オンラインでフォームに記入したリードの連絡先データを取得するために作成されました。リードを作成した後、レシピはPostgresの分析データベースを更新します。

オンラインフォームからSalesforceとPostgreSQLにリードを移動するレシピ

もし私たちの組織がPostgreSQLからRedShiftにデータベースを変更し、メーリングリストアプリケーションとしてMailChimpを使用し始める場合、次のアプローチのいずれかを取ることができます。

• PubSubコネクタを使用せずに元のレシピを変更する
• PubSubコネクタを使用する

PubSubコネクタを使用せずに元のレシピを変更する

次のようにレシピを更新する必要があります。

PostgreSQLの代わりにRedshiftに行を追加し、MailChimpに購読者を追加するための変更後のレシピ

元のレシピの変更には、レシピの開発ライフサイクルの追加のイテレーションが必要となります。レシピは変更され、後方互換性がテストされ、本番環境にプッシュされる必要があります。QAを通過したバグがあれば、本番レシピのダウンタイムが発生します。

PubSubコネクタを使用する

PubSubトピックを利用すると、元のレシピを次のように構築し、Salesforceのリードを作成してからリードデータをトピックに公開します。このレシピは、そのコンシューマーについて気にする必要がなく、したがってダウンストリームのレシピが変更されていることを知る必要もありません。

Salesforceにリードを作成し、リードデータをトピックに公開するパブリッシャーレシピ

リードデータを使用してRedshiftの行を作成する対応するコンシューマーレシピは、次のようになります。

トピックからリードデータを消費し、リードデータでRedshiftの行を作成するコンシューマーレシピ

リードデータを使用してMailChimpのリードを作成する対応するコンシューマーレシピは、次のようになります。

トピックからリードデータを消費し、リードデータでMailChimpのリードを作成するコンシューマーレシピ

リアルタイムイベントからバッチを作成する

例えば、同じシナリオではリードが非常に高い速度で生成され、SalesforceとPostgreSQLへのAPI呼び出しの数を最適化する予定です。WebToLeadは1つずつリードを公開するため、単一のレシピではそれを実現することはできません。

PubSubトピックを使用すると、新しいリードを集約し、一定の時間間隔でバッチとして公開することができます。元のレシピは、新しいリードをPubSubトピックに一度に1つずつ公開するだけです。

WebToLeadから新しいリードを受け取り、PubSubに公開するパブリッシャーレシピ

対応するコンシューマーレシピは、新しいメッセージのバッチトリガーを使用し、1時間ごとに実行されます。それから、1回のAPI呼び出しでSalesforceとPostgreSQLにバッチ全体を公開します。

新しいリードのバッチを受け取り、SalesforceとPostgreSQLに公開するコンシューマーレシピ