Shopify Webhook：BFCM時期に向けてアプリを準備しよう

※2020年9月のアップデート

下記の情報は現在でも有効ですが、いまwebhookを管理する最良の方法はAmazon EventBridgeを使うことです。サーバーレスでイベントドリブンなEventBridgeのアーキテクチャは、インフラコストを削減しながら拡張性の高いシステムを実現します。

詳しくはこちらのブログをご覧ください。

---

信じられないかもしれませんが、ホリデーシーズンがもう間近に迫っています。Shopifyアプリ開発者のみなさんも準備が必要です。この一年でもっとも大変な繁忙期に、アプリの障害や中断を起こしている余裕などありません。注文の殺到に対応し、顧客情報や商品情報の絶え間ない更新に備える必要があります。

多くのShopify開発者は、webhook（Shopify内で発生したイベントに応じて送信される通知メッセージ）を利用しています。Shopifyのwebhookは、eコマースプラットフォームにおける変更を追跡する効率的な方法であり、アプリはShopifyで何かが発生するとプッシュ通知によって知ることができます。

実際にある程度の規模でwebhookを受け取るまでは、webhookがいつどれくらい送信されるのか予期するのはむずかしいです。わたしたちが最初のアプリRewindをローンチしたとき、毎日真夜中に多数のストアからwebhookが送信されているのを見て驚いたものです。

顧客から聞いてわかったことは、これらのwebhookはサードパーティのシステムがShopifyデータと同期するときに送られるということでした。たとえば、デイリーで同期をおこなう在庫システムは、なんの警告もなしに数千から数万のwebhookをアプリに送ることになるのです。

今回の記事では、webhookをオフラインで扱い、アプリがShopifyからの負荷を処理できるようにするシステムの構築について解説します。これにより、あなたのチームがwebhookを可能なかぎり速く処理することが可能になります。このシステムはサーバーレスのアーキテクチャで構築されるため、費用が高額になることなく大規模な負荷を自動で処理できます。

 

Shopifyのwebhookをさばけるシステムの構築

Shopifyがアプリに対して要求しているのは、webhookに迅速にレスポンスすることです。それができない場合は削除されます。Shopifyのwebhookが発生したときにインラインで処理する場合、大きな問題となることもあります。送信される可能性のあるwebhookに対応するため、アプリは強力なサーバーを必要とするからです。いつwebhookが送信されるかわからないわけですから、強力なサーバーを24時間稼働させることになり、かなり高額になり得ます。

たくさんの大規模サーバーを稼働させても、迅速なレスポンス、webhookデータの喪失、Shopifyの将来的なwebhookのキャンセルという点では、まだリスクがあるのです。

これらの問題に対処する良い方法は、システムをセパレートして、Shopifyに迅速にレスポンスする設定をあらかじめしておくことです。Shopifyのwebhookをすぐに認知し、どこか別の場所にデータを保存しておけば、webhookはキャンセルされませんし、そのデータを将来的に処理することも可能になります。webhookデータを見逃すことはなくなり、アプリは送られたデータを喪失することもありません。

「Shopifyのwebhookをすぐに認知し、どこか別の場所にデータを保存しておけば、webhookはキャンセルされませんし、そのデータを将来的に処理することも可能になります」

このブログ記事では、わたしたちが アマゾンウェブサービス（AWS）を利用してRewindのために構築したシステムについて解説します。ここではAPIゲートウェイ、Lambda、SQSキューを使用しています。ShopifyがwebhookをRewindに送信すると、それがAPIゲートウェイとLambdaで処理されます。この2つはAWSの「サーバーレス」なサービスで、需要に合わせて自動的にスケールします。メッセージは、webhookからのデータを記憶するSQSキューに保存されます。サーバーは、あなたが管理するレートによってwebhookキューを処理します。このために必要なステップは、以下のとおりです。

1 SQSキューの設定

プロセスの最初のステップは、SQSキューの設定です。SQSには2つのタイプのキューがあります。ファーストイン／ファーストアウト（FIFO）キューと、標準キューです。webhookの順序を維持したい場合はFIFOキューを使います。または、標準キューを使用してメッセージのupdated_atを参照することもできます。どちらも機能するので、利用ケースに応じてどちらを取るか決めることになります。

SQSキューをAWSで設定する。

2 Lambda functionの設定

AWS Lambdaを使用すると、自分でサーバーを管理することなく、コードをAWSサーバーで実行できます。これは一般的に「サーバーレス」といわれる仕組みです（とはいえ、実際にはサーバーはクラウドにあるのですが）。LambdaのサーバーはAmazonが運営していて、負荷の上昇に合わせて自動でスケールします。コードの実行に必要な分だけ課金されるので、運用はとても安く済みます。

Lambdaを始めるには、まず新しいfunctionを作成します。このコードは、入ってくる情報をAPIゲートウェイ（次のステップで設定します）から得ています。そしてwebhookのセキュリティを確認（Shopifyから送信されていることを確認）したら、それを最初のステップで作成したSQSキューに付加します。

コードを見てみましょう。

Lambda functionの設定。

3 APIゲートウェイの設定

Lambdaが設定できたら、次はAPIゲートウェイを設定します。APIゲートウェイは、APIを特定する方法を提供し、サーバーなしでAWSで実行されます。サーバーを使う代わりに、webhookはこのAPIゲートウェイを経由します。この方法により、サーバーの運用を心配することなく、webhookのボリュームに合わせてスケールできます。

APIゲートウェイの設定。

APIゲートウェイのために、まず下記のスキーマで新規モデルを作成します。

統合リクエストには、以下のマッピングテンプレートを設定します。

4 Elastic Beanstalkワーカーの設定

最後のパートは、Elastic BeanstalkワーカーによるSQSキューの処理です。Elastic BeanstalkワーカーはSQSキューから自動でアイテムを抽出し、マシンのlocalhostにPOSTします。

わたしたちのワーカーはRubyで書かれているシンプルなRubyアプリケーションです。コードはGitHubで簡単に見つかります。このサーバーレスなwebhookシステムのコードはオープンソースになっていますので、改良のためにみなさんからのコントリビュートを歓迎します。

webhookを処理するコードはオープンソースでGitHubにあります。

結果の確認

わたしたちは実際にこのシステムをShopifyアプリで使用し、大きな成功をおさめました。webhookをいつ、どれくらいのスピードで処理するかをコントロールしながら、毎日数十万件のwebhookをさばくことができます。この方法なら、アプリへの影響を心配することなく、データベースの管理タスクを容易にするという自由が得られます。

Elastic Beanstalkワーカーは効率的に素早くSQSメッセージを処理します。キューサイズの増加に合わせてワーカーを追加できるため、データベースが制限ファクターとなるでしょう。規模のわりにお金もかかりません。10,000件のwebhookあたり、約0.01ドルです。

BFCMでwebhook対策は必須

マーチャントがアプリを効果的に使用できるようにするためには、BFCMにおける注文の急上昇に備えることが重要です。もしあなたのアプリがShopifyのwebhookの処理に困っているなら、今回のシステムは出費をおさえながら大量の負荷を扱うのに役立つでしょう。

原文：Mike Potter 翻訳：深津望