Slide 1
Slide 1 text
© LayerX Inc.
プロダクト間連携を支える非同期通信基盤
Encraft #16
Shota Iwamatsu (@shota8511_tech)
Slide 2
Slide 2 text
© LayerX Inc. 2
● LayerX
○ 2023/8〜
○ バクラク事業部 カード開発グループ
○ ソフトウェアエンジニア
● ex. Infcurion, Latona, Accenture
● 主に Go と React を書いています。
自己紹介
Shota Iwamatsu
@shota8511_tech
Slide 3
Slide 3 text
目次
Agenda
● バクラクの開発の特徴
● バクラクの開発の課題感
● 非同期通信基盤のアーキテクチャ
● 開発者がやること
● まとめ
Slide 4
Slide 4 text
© LayerX Inc. 4
バクラクの開発の特徴
発表内での用語の定義
● プロダクト
○ お客様に1つのパッケージとして価値を提供するソフトウェア製品
○ 「バクラクビジネスカード」など
● サービス
○ 論理的あるいは物理的に分けられた1つのサーバーアプリケーション
○ マイクロサービス・アーキテクチャにおける「サービス」と概ね同等
Slide 5
Slide 5 text
バクラクの開発の特徴
Slide 6
Slide 6 text
6
© LayerX Inc.
バクラクの開発の特徴
仕訳・支払処理効率化 法人カードの発行・管理
稟議・支払申請・経費精算
帳票保存・ストレージ 帳票発行
* 経費精算のSlack連携は申請内容の通知のみ
AIが領収書を５秒でデータ化
スマホアプリとSlack連携あり
領収書の重複申請などミス防止機能
AIが請求書を５秒でデータ化
仕訳・振込データを自動作成
稟議から会計までスムーズに連携
年会費無料で何枚でも発行可
インボイス制度・電帳法対応
すべての決済で1%以上の還元
AIが書類を5秒でデータ化
あらゆる書類の電子保管に対応
電子取引・スキャナ保存に完全対応
帳票の一括作成も個別作成も自由自在
帳票の作成・稟議・送付・保存を一本化
レイアウトや項目のカスタマイズも可能
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
Slide 7
Slide 7 text
© LayerX Inc. 7
バクラクの開発の特徴
● 複数のプロダクトを提供している (コンパウンドスタートアップ)。
● プロダクト同士がデータを中心に連携することで、様々な価値を提供している。
バクラクの特徴
Slide 8
Slide 8 text
© LayerX Inc. 8
バクラクの開発の特徴
● ビジネスカード は決済後の業務 (AfterPay) をバクラクにする機能を提供している。
○ 申請・経費精算 と連携して、カード明細に対して証憑を紐づける & 利用報告をする。
○ 請求書受取・仕訳 と連携して、カード明細に対して仕訳を作成する。
例えば・・・
これを実現するために、プロダクト間でデータを連携する必要がある。
Slide 9
Slide 9 text
© LayerX Inc. 9
バクラクの開発の特徴
各プロダクトはそれぞれ専用のサービスを持っている。
前提となるアーキテクチャ
請求書受取・仕訳
申請・経費精算
ビジネスカード
Service
Service
Service
データ参照・更新
データ参照・更新
データ参照・更新
※ 細かい構成は今回の話では重要ではないため仮のものです。
Slide 10
Slide 10 text
© LayerX Inc. 10
バクラクの開発の特徴
プロダクト間連携を実現するために、データを1つの DB に集約する必要がある。
前提となるアーキテクチャ
請求書受取・仕訳
申請・経費精算
ビジネスカード
Service
Service
Service
データ参照・更新
データ参照・更新
データ参照・更新
複数サービスのデータを紐づけて
検索・表示したい！
※ 細かい構成は今回の話では重要ではないため仮のものです。
Slide 11
Slide 11 text
© LayerX Inc. 11
バクラクの開発の特徴
AfterPay 専用サービスとして切り出し、各サービスから関連データを同期する。
前提となるアーキテクチャ
請求書受取・仕訳
申請・経費精算
ビジネスカード
Service
Service AfterPay Service
Service
データ同期
データ同期
データ同期
※ 細かい構成は今回の話では重要ではないため仮のものです。
データ参照・更新
データ参照・更新
データ参照・更新
Slide 12
Slide 12 text
© LayerX Inc. 12
バクラクの開発の特徴
各プロダクトから、サービス横断的なデータを参照できる。
前提となるアーキテクチャ
請求書受取・仕訳
申請・経費精算
ビジネスカード
Service
Service AfterPay Service
Service
データ参照
データ参照
※ 細かい構成は今回の話では重要ではないため仮のものです。
データ参照・更新
データ参照・更新
データ参照・更新
Slide 13
Slide 13 text
バクラクの開発の課題感
Slide 14
Slide 14 text
© LayerX Inc. 14
バクラクの開発の課題感
● プロダクト間連携において、サービス間の非同期通信が発生しやすい。
○ サービス同士を疎結合に保ちつつ、データを同期したい。
○ あるサービスのデータ更新をトリガーに、別サービスで処理を実行したい。
● プロダクトやプロダクト間連携は今後もどんどん増えていく。
● その度にサービス間の非同期通信の仕組みを用意するのは大変...
課題感
Slide 15
Slide 15 text
© LayerX Inc. 15
バクラクの開発の課題感
● プロダクト間連携において、サービス間の非同期通信が発生しやすい。
○ サービス同士を疎結合に保ちつつ、データを同期したい。
○ あるサービスのデータ更新をトリガーに、別サービスで処理を実行したい。
● プロダクトやプロダクト間連携は今後もどんどん増えていく。
● その度にサービス間の非同期通信の仕組みを用意するのは大変...
課題感
サービス横断的な非同期通信基盤を用意し、開発の手間を削減！
Slide 16
Slide 16 text
非同期通信基盤のアーキテクチャ
Slide 17
Slide 17 text
17
© LayerX Inc.
非同期通信基盤のアーキテクチャ
● AWS の EventBridge + SQS で非同期処理を実現している。
● EventBridge にイベントを送れば、対象の RPC が非同期で実行される。
全体像
Slide 18
Slide 18 text
18
© LayerX Inc.
非同期通信基盤のアーキテクチャ
● Publisher が Event Bus にイベントを送る。
● Event Bus は1つのみ存在し、あらゆるイベントを受け取る。
● イベントに含まれる主なパラメータは、イベント名・ペイロードなど。
Slide 19
Slide 19 text
19
© LayerX Inc.
非同期通信基盤のアーキテクチャ
● イベントごとに定義された Rule をもとに、対象の RPC を特定する。
● Rule に紐づく Input Transformer でイベントのパラメータを整形する。
○ メタデータとして対象の RPC 名を追加する。
Slide 20
Slide 20 text
20
© LayerX Inc.
非同期通信基盤のアーキテクチャ
● SQS (と DLQ) が RPC ごとに1つ存在する。
● 対象の RPC に対応する SQS へメッセージをエンキューする。
Slide 21
Slide 21 text
21
© LayerX Inc.
非同期通信基盤のアーキテクチャ
● Worker が全ての SQS をポーリングしている。
● 受信したメッセージをもとに対象の RPC を特定する。
● DynamoDB で冪等性を担保しており、メッセージが処理済みの場合は何もしない。
Slide 22
Slide 22 text
22
© LayerX Inc.
非同期通信基盤のアーキテクチャ
● Worker が対象の RPC を実行する。
● RPC から正常応答が返ってきたら SQS のメッセージを削除する。
● RPC は Connect (gRPC 互換フレームワーク) で実装されている。
Slide 23
Slide 23 text
© LayerX Inc. 23
非同期通信基盤のアーキテクチャ
● イベントの送信先が1つなので、Publisher が送信先を意識する必要がない。
● メッセージを一度 SQS に入れているので、リトライがしやすい。
● メッセージの受信処理は Worker に任せて、RPC のみ実装すれば良い。
嬉しいポイント
Slide 24
Slide 24 text
24
© LayerX Inc.
非同期通信基盤のアーキテクチャ
● SQS を経由せずとも、EventBridge から直接 RPC サーバーへリクエストを送ることはできる。
● ただし5秒タイムアウトがあるため、バクラクでは SQS を経由している。
補足
Slide 25
Slide 25 text
開発者がやること
Slide 26
Slide 26 text
© LayerX Inc. 26
開発者がやること
③ ルール定義 ② RPC 実装
① イベント定義
● イベントと RPC の紐づけを定義すると、必要なリソースが自動生成される。
● 開発者は RPC の実装に集中できる。
Slide 27
Slide 27 text
© LayerX Inc. 27
開発者がやること
1. イベント定義
① イベント定義
Slide 28
Slide 28 text
© LayerX Inc. 28
開発者がやること
1. イベント定義
● proto ファイルにイベントとそのペイロードを定義する。
enum Event {
EVENT_HOGE_UPDATED = 1;
…
}
message HogeUpdatedEvent {
string hoge_id = 1;
}
event.proto
Slide 29
Slide 29 text
© LayerX Inc. 29
開発者がやること
2. RPC 実装
② RPC 実装
Slide 30
Slide 30 text
© LayerX Inc. 30
開発者がやること
2. RPC 実装
● 非同期で実行したい RPC を定義 & 実装する。
● リクエストはイベントのペイロードを受け取る。
service NotificationService {
rpc NotifyHogeUpdated(NotifyHogeUpdatedRequest) returns (google.protobuf.Empty) {}
}
message NotifyHogeUpdatedRequest {
HogeUpdatedEvent event = 1;
}
notification.proto
Slide 31
Slide 31 text
© LayerX Inc. 31
開発者がやること
3. ルール定義
③ ルール定義
Slide 32
Slide 32 text
© LayerX Inc. 32
開発者がやること
3. ルール定義
● yaml ファイルにイベントと RPC の紐づけを定義する。
● この定義から EventBridge Rule と SQS の自動生成される (by Terraform)。
event:
- name: 'event_hoge_updated' # このイベントが発行されると
subscriber:
- id: 'NotificationService/NotifyHogeUpdated' # この RPC が実行される
…
event_router.yaml
Slide 33
Slide 33 text
© LayerX Inc. 33
開発者がやること
非同期で RPC が実行される！
イベントを発行すると
● Publisher がイベントを発行すれば、対象の RPC が非同期で実行される。
Slide 34
Slide 34 text
© LayerX Inc. 34
開発者がやること
● イベントと RPC の紐づけを定義すると、必要なリソースが自動生成される。
● 開発者は RPC の実装に集中できる。
● イベントと RPC の紐づけが一目でわかる。
嬉しいポイント
Slide 35
Slide 35 text
まとめ
Slide 36
Slide 36 text
© LayerX Inc. 36
まとめ
● バクラクの開発では、プロダクト間連携において、サービス間の非同期通信が発生しやすい。
● サービス横断的な非同期通信基盤を用意し、開発の手間を削減している。
● 開発者は RPC の実装に集中できる。
Slide 37
Slide 37 text
37
© LayerX Inc.
LayerX OpenDoor