Shopifyアプリの開発をしていると、セール期間中などはとくに、Shopifyから直接Webhookを受けてアプリをスケーリングすることが困難になりがちです。トラフィックの読み込みを管理するにあたって、オートスケールが思うような速度で機能せず、大規模サーバーはすぐ高額になるということもあります。
今年、わたしたちは新しいソリューションを導入しました。Amazon EventBridgeの統合機能です。これによりイベントバスを使用してShopify Webhookを受信できるので、スケーラブルなシステム構築においてEventBridgeはインフラコストを削減します。
では、実際にどうやって使用すればいいのでしょうか？
ShopifyアプリMechanicとLocksmithのクリエイターであるIsaac Bowenに話を聞きました。EventBridgeがShopify開発体験に及ぼした影響について教えてもらいます。
Webhookの課題
Webhookは、ショップでイベントが起こったときにアラートを送信してコードを実行できるようにするツールです。Webhookはユーザーのショップにおけるイベントを、レスポンスとしてアプリが実行する特定のアクションに結びつけます。
Webhookはサブスクリプションをベースとするため、特定のイベントカテゴリーをサブスクライブし、そのイベント関連のWebhookを受け取るためにHTTPエンドポイントを登録することになります。ユーザーのショップで特定イベントが発生すると、関連オブジェクトのコピーを含むJSONペイロードと一緒にWebhookを受け取ります。
ただし、ボリュームの大きいイベントが発生してアプリのインフラを凌駕するようになると、問題が起こります。大規模マーチャントがアプリを使用する場合や、ユーザーがフラッシュセールをおこなう際などに、こうした問題が生じやすくなります。データが集中するとアプリのインフラはトラフィックの猛攻に耐えることができず、アプリの機能が損なわれます。この問題に対抗するために、開発者はトラフィックの急増に対応できる強力なサーバーを運用したり、複雑なキューイングシステムを構築したりしています。
ここで暗に示されているWebhookの正しい運用方法の前提は、インフラがShopifyに追いつくことです。つまりWebhookを利用するなら、アプリがShopifyのアクティビティの潜在的なロードに追いつく必要があることを意味します。新規のアプリにとってはかなり困難なタスクです。
そこで、Amazon EventBridgeを活用します。EventBridgeは標準HTTPを介したWebhook受信の代替策であり、サーバーレスかつイベントドリブンです。EventBridgeとの統合により、トラフィックすべてを自分で処理するかわりにイベントデータを直接AWSに送信できます。
EventBridgeのようにイベントドリブンなアーキテクチャは、非常に大きなバッファをあなたと巨大スケールのShopifyの間に置きます。これによりイベント処理は技術スタックに適したレートで比較的楽におこなうことが可能になります。スケーラブルで弾力性が高く、インフラコストと複雑性を軽減しながら、Webhookトラフィックを多く受け入れることができます。
Amazon EventBridgeについてもっと詳しく：
チュートリアルでAmazon EventBridgeによるWebhookイベントの管理方法を学べます。イベントソースの設定、ルールの確立、Webhookサブスクリプションの作成方法を学習しましょう。
Webhookが心配で眠れない？
Isaac Bowenは10年にわたってShopifyと関わってきました。
「10年前、Gatekeeperというアプリの最初の行を書きました。2010年のことです。GatekeeperはShopifyアプリストアの最初のリスト100件のうちの1つでした」とIsaacは言います。
その後、IsaacのShopifyとの関わりは増えました。彼が立ち上げた会社、Lightwardは、今や2つのアプリをShopifyアプリストアに掲載しています。Gatekeeperの後継であるLocksmithとMechanicです。
「機能する仕組みを理解するのが好きです。それに、物事があるべき方向に進むのを見るのも嬉しいです」とIsaacは説明します。「それが、わたしが作ったりやったりすることの根底にあります。Mechanicはその好例でしょう。コンセプト自体は4年前からあり、アプリは2年前にリリースしました。どのようにあるべきか、どのように機能すべきかを探り出すことが全体のプロセスだったと言えます。今、Mechanicは開発者とマーチャントの関係を向上させるツールとなっています。ある種のオートメーションの問題を素早く解決できる能力を開発者にもたらし、コードのスキルを活用できます。最終プロダクトを手渡すのも簡単で、コードなしでマーチャントにもわかりやすくなっています。マーチャントがすぐに使える300ほどのビルトインのタスクも備わっています。」
MechanicのUI
Mechanicのアイデアについてブレストしたとき、Shopifyでワークフローを自動化する唯一の道はアプリを作ることでした。それは経験のある開発者にとっても大きな仕事であり、プロセスをいくらか楽にしたいと思っているマーチャントにとってはもちろん技術的なむずかしさがあります。
IsaacはShopify関連の作業をする人が、テンプレート言語のLiquidを使用する傾向にあることに気づきます。そこで、柔軟性を高めるために、MechanicはLiquidをイベントプロセスに使用し、ユーザーがイベントをLiquid変数として扱えるようにしたうえ、実行するアクションの定義をLiquidテンプレートでレンダリングするようにしました。
そのメリットは、開発者がLiquidを理解しているかぎり、思い通りのオートメーションを構築できる点にあります。またプログラミング言語になじみのないマーチャントがオートメーションを管理しやすくできます。Liquidを触る意欲のあるマーチャントには、オートメーションのコードがすぐ見られるようになっています。
Mechanicライブラリからタスクを追加する
Mechanicはユーザーのストアで起こる特定イベントをもとに自動で機能します。
「Mechanicではいくつかのイベントドメインがありますが、一番混雑しているのがShopifyです」とIsaacは説明します。「ShopifyのWebhookはどれでもMechanicのイベントになります。通常時は、1分で500ほどのShopify Webhookを処理しています。」
WebhookのアプローチはMechanicの目的に沿ったものですが、上昇するスケールは問題も引き起こすことになりました。
「Mechanicの利用数は急速に広がっています。大きいストアが使えば、ランダムで膨大なイベントが発生する機会が生じます。従来のWebhookはこうした問題の解決をイラつくほどむずかしくしていました。」
従来のWebhookのアプローチでは、ダウンタイムがいつでも起こり得ます。
「Webhookは一度設定すれば放置しておいていいのですが、それはランダムな10倍のWebhookトラフィックが突如起こってサーバーが飽和するまでの話です。日常的な業務に支障はないとはいえ、夜ぐっすり眠られるかどうかに大きく影響していたことも事実ですね。」
EventBridgeを使う
EventBridgeこそ、Isaacが探し求めていたソリューションでした。
「EventBridgeを最初に知ったとき、ああ、やっとこの問題をきちんと解決できるぞ、と思いました」とIsaacは言っています。
さらにボーナスとして、EventBridgeの導入はとても簡単でした。
「EventBridgeを使った最初のコミットでは、10のファイルの変更、147個の追加と54個の削除がありました。笑えるくらい小さなアップデートです。それでもそれまで以上のコード量があり、というのも従来のWebhookからEventBridgeにひとつずつ、ストアをスイッチできるようにしてあったためです。」
実装が簡単なだけでなく、EventBridgeはアプリがトラフィックを処理するための当初想定していた時間と労力を軽減しました。
「わたしはwebインフラを2つに分けようとしていました。通常のアプリトラフィック用とShopify Webhook用です。EventBridgeならその必要がありません。アプリのダウンタイムがあれば、良くてもWebhookのリトライ、悪ければWebhookを落とすことになる、とずっと思っていました。遅延は良くないことですし、データの喪失は本当にダメなことです。SQSにつないだEventBridgeにより、イベントの流入は突然AWS自体の安定性によって支えられることになったわけです。」
MechanicがEventBridgeと統合されたので、Isaacは増えるトラフィックを心配することなくアプリの成長に専念できるようになりました。
「EventBridgeを使用することで、なんのためらいもなくどんなスケールのイベントも消費できます。また、新しい容量のブートに、リクエストの待機や喪失になるほどの時間はかかりません。すべてのリクエストはSQSの待機イベントとなっています。わたしたちのSQSポーラーはwebサーバーより効率的に動き、またwebトラフィックの大半はWebhookなので、EventBridgeが入ったことで全体のオペレーションはタイトになっています。」
結果、アプリが成長するための安定基盤をIsaacは得られたわけです。
「Webhookはすでに信頼できます」と彼は言います。「EventBridgeを使用することで、その信頼性にふさわしい機能を獲得できます。それに、わたしは前より安心して眠れるようになりました。」
Mechanicで未来を見据える
Mechanicのアプリ掲載
EventBridgeのようなツールによって、Isaacは会社のビジョンを実現できるようになります。
「Lightwardのポイントは、運用しながら実験することです。オペレーションの選択をヒューリスティックな価値判断（”いい方向に向かっていると感じられる決断かどうか？”というような）によって決めていいのか？ ビジネスをそうやって運営できるか？ どうやらできそうなんです。」
この哲学はアプリ開発にも適用されます。Isaacはビジネスのローンチや拡張を考えている開発者たちに向け、次のようなアドバイスを共有しています。
「生まれたがっているものを作り出しましょう。利益になるとか、簡単だからということではなく（それらが両立することもありますが）。世界にあるべきものを作ってください。すでにそうしていることが明らかな人やプラットフォームとつながりましょう。Shopifyをわたしが最初に選択したのはそれが理由です。Shopifyのような視野をもって継続的にサービスを作り上げている会社はそう多くはありません。EventBridgeの統合機能を導入することは、そうしたプロセスを反映する長い決断の連鎖の一つにすぎません。毎日の決定を肯定できるように、コードやビジネスやその他の領域でも、とにかく全体的につながった選択をすることです。」
さらに実践的なアドバイスをもう一つ。
「それと、SQSキューにエイジモニタリングを設定しましょう。これもとても重要です。」
スケールのためのEventBridge
EventBridgeのサーバーレスでイベントドリブンなアーキテクチャにより、Isaacはインフラコストを削減してスケーリングすることを可能とする基盤からメリットを得られるようになりました。そして、アプリがダウンするのでは、という悩みからも解放されました。
アプリ開発者の観点から見ると、EventBridgeの統合は、スケーラブルでコスト効率の良い方法でアプリとビジネスの成長を促進し、トラフィックに影響されることなく素晴らしい体験をユーザーに提供し続けることを可能にします。
続きを読む
Shopifyパートナープログラムでビジネスを成長させる
マーケティング、カスタマイズ、またはWebデザインや開発など提供するサービスに関係なく、Shopifyパートナープログラムはあなたを成功へと導きます。プログラムの参加は無料で、収益分配の機会が得られ、ビジネスを成長させる豊富なツールにアクセスできます。情熱的なコマースコミュニティに今すぐ参加しましょう！
