layerx-bakuraku-how-to-handle-incoming-webhooks-with-difference-specifications-in-unified-way

by shnjtk

Slide 1

Slide 1 text

複数の外部接続環境で仕様の異なるIncoming Webhookを統一的に扱うためのアーキテクチャ 2023.3.9 @shnjtk 株式会社LayerX

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© 2023 LayerX Inc. 3 バクラクシリーズラインナップ * 経費精算のSlack連携は申請内容の通知のみ稟議・支払申請・経費精算・ワークフロー・AIが領収書を５秒でデータ化・承認はチャットアプリから・シームレスな内部統制構築仕訳・支払処理効率化・AIが請求書を５秒でデータ化・仕訳データを自動学習、手入力ゼロへ・改正電子帳簿保存法に対応・利用料無料・即時追加発行・1億円以上決済可能法人向けクレジットカード・無料で始められる・手入力ゼロで証憑管理・改正電子帳簿保存法に対応帳票保存・ストレージ

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2023 LayerX Inc. 5 アーキテクチャ設計時の検討事項 ● サービスの不具合でWebhookを処理できなかった場合に、自社のタイミングでリトライできるようにしたい ○ 初めて接続するサービスであるため、本番運用時にどのようなメッセージが届くか事前に全てを把握することは不可能 ○ 特に決済サービスについては、メッセージの内容や送信パターンは加盟店次第であるため、運用開始時点の処理ロジックでは対応できないケースが発生する可能性がある ○ 仮に不具合があった場合に、修正してリリースした後、手動でリトライをかける仕組みが欲しい

Slide 6

Slide 6 text

© 2023 LayerX Inc. 6 アーキテクチャ処理順序 1. API Gateway経由でLambdaでメッセージを受信 2. LambdaでメッセージをS3に保管し、ジョブを作成してSQSに送信 3. 上記処理が成功したらLambdaはレスポンスとして200 OKを返す 4. workerでSQSからジョブを受信し、S3からメッセージを取得して処理を実行設計のポイント ● workerの処理が失敗した場合、ジョブがSQS（ソースキュー）からDLQに移される ○ 手動でソースキューに戻せばリトライ可能 ● メッセージはそのままS3に保管されているため、デバッグの際に実データを見ながら調査・検証できる

Slide 7

Slide 7 text

Confidential © 2022 LayerX Inc. 7 メリット・デメリットメリットデメリット ● リトライを任意のタイミングで実行できる ● Webhookのメッセージが失われないため、サービスに不具合があっても修正をリリースした後にリトライできる ● Webhookが大量に届いた場合でも一旦Lambdaで受けてキューイングするため、結果的にスロットリングになりworkerの処理能力に合わせてメッセージを処理できる ● Webhookを受けた時にDBなどのデータを照合・検証して200 OK以外のレスポンスを返す必要がある場合、ソースコードやリリースの管理が複雑になる ○ 例) Lambdaとworkerでモデルを共通化するためにmonorepoを導入するなど ○ 今回は外部サービスのWebhook仕様として常に200 OKを返せばよいシンプルなものであったため、Lambdaとworkerは別リポジトリで独立して管理している