疎結合でスキーマ駆動開発を実現するイベントバスの設計

じゃあ始めさせていただきます
はい 素結合でスキーマ駆動開発を実現するイベントバスの設計というタイトルで
hacomonoのUedaが発表させていただきます どうぞよろしくお願いいたします
まず最初に本日の発表の流れについて説明をさせてください
最初に本発表について概要を説明させていただいた後 自己紹介をさせていただいて
株式会社hacomonoについて説明をさせていただきます
このhacomonoがなぜイベントバスを必要にしたのかという背景も含まれて説明をするので
ぜひ聞いていただければと思います
またイベントバスを導入した後 さらにその先 開発者が安心して利用できるイベントバスとは何か
そしてその実装 タイトルにもなっているスキーマ駆動イベントバスというものについて
その設計を説明させていただきます
そしてその後 段階的な導入プロセスについて説明した後 まとめとさせていただければと思います
それではまず最初に本発表について
皆さん多分こちらの記載を見ていただいた方が 多いのではないかなと思っております
そしてこの記載の中でおそらくキーワードとしてなっている部分
この辺りが多いのかなと私の方では想定しております
さて本の発表について 改めて説明させてください
今日の発表の内容について まずなぜイベントバスが必要になるのか
つまりAPIの密結合における問題点と合わせて イベントバスが必要になる背景を説明させてください
そしてその先 開発者が安心して利用できるイベントバスとはどういうものか ということについて説明をさせていただきます
それはスキーマ駆動開発で スキーマを信頼できる開発フローであったり
スキーマの破壊的変更が起きない環境であったり
あるいはバリデーションロジックの共通化であったり
そして不正なイベントが 実装ミスを防ぐ仕組みがあること
そしてカスケード障害の抑制ができること これらの点が含まれております
そして最後スキーマ駆動イベントバスの 段階的導入プロセスについて説明させていただきます
では改めまして自己紹介をさせていただきます
hacomonoでプリンシパル分散システムエンジニアを 名乗らせていただいているUedaと申します
オンラインではBOTJPという名前で やらせていただいております
hacomonoには2024年の9月 ちょうど1年くらいですかね
基盤本部というところで共通基盤を 設計開発しております
以前ですと大量配信 広告とか
あるいはラフトを用いた分散ストレージの 研究開発などを行っておりました
それでは我々hacomonoについて 少々説明をさせて下さい
hacomonoはウェルネス施設のあらゆる手続きを デジタル化するBtoBtoCサービスです
と言ってもちょっとピンとこないと思います
こちらに記載している通り 会員予約 会員管理や予約 振替 キャンセル 決済 請求管理 売上管理 債券管理等々あるんですけど
フィットネスクラブや運動スクール 公共運動施設 スポーツチームに導入いただいております
そして実際にちょっと導入いただいている 店舗様を見ていただくと
多分おそらく皆様 見たことがある店舗様 特に右上とかがあるのではないかなと
思っております
hacomonoがこれの一般的なサースと 大きく異なる点がここにございまして
hacomonoはIoTを用いた入体感を管理する つまり施錠を管理したりするシステムが入っている
というところが他のサースさんと 大きく異なる要素としてあるかと思います
言い換えるとこの入体感というシステムは 非常に高い可用性が求められるという背景があります
これらを踏まえてなぜイベントバスが 必要になったかというところをお話しさせていただければと思います
一部繰り返しになりますが hacomonoでは可用性が異なるコンポーネントが
複数あるという状況にあります
特別に高い可用性が要求されるコンポーネントとして 先ほど説明しました通り
IoTデバイスと通信する入体感システム そして売上に直接影響が出る
予約システムや決済というものがあります
そしてこれらのシステムの開発速度そして可用性を両立するために サービスの分割というのを推進しています
サービスを分割すると各サービス間で データ連携をする必要がございます
これが今回のイベントバスが必要になる背景の一つです
そしてそれとは別軸で マルチプロダクト展開というのを進めています
これは複数のプロダクトを展開して 相互に必要なデータを連携する必要があるという状況になります
この2つに共通して言えることとして 各サービス間でデータを連携するという必要があります
これがイベントバスが必要になる背景の一部となります
ではなぜイベントバスが必要なのか あるいはなぜイベントバスではならないのかのところについてお話をさせてください
必ずしもイベントバスが必要ではありません
見つけ都合 例えばデータを連携するというところを想像したときに
皆さんおそらくAPIを呼び出すということを 最初に思い浮かべるのではないかと思っております
もちろんAPIを直接呼び合う世界でも 少数であれば問題はないと思っております
一方でサービスが増えれば増えるほど 例えば1個のAPIエンドポイントを呼んで終わりではないので
1回の操作につき複数のAPIを呼ぶ必要があるかと思います
そうするとサービスが増えるごとに N対Mで経路が爆発的に増加していきます
そうすると開発者が他のサービスの使用を把握するコストは増大していき
開発速度の低下を招きます
またAPI回収時の影響範囲が不明瞭になります
どのサービスがこのAPIを利用しているか 明確ではないという状況が出てきます
もちろんこちらはメトリクスを取ることで どのサービスがというところを解決できるかと思います
一方でここのAPIに変更を加えたとき どこまで影響するかというのは
やはり実装に依存するのではないかと思っております
そうすると回収やデプロイや恐怖というところで やはり開発速度が低下していくのではないかと考えております
また同期的なAPI呼び出しは 計画メンテナンスの停止が不可能になります
これは先ほど申し上げたように 高可用性を実現するというところにおいて
非常に困難な問題として現れます
これは実際のhacomonoのAPI呼び出しではないんですが 似たような構造をとっていて
これを簡略化したものとして 見ていただければと思います
一番下に入体管システムというのがあるのですが
これは非常に高い可用性が要求されるにもかかわらず
他のサービスに直接依存しているという状況になっていて
やはり高可用性を実現するというのはなかなか難しい
そしてこれらを把握していく 開発フローというのはなかなか難しい
というのが課題としてあります
図を入れるとこんな感じです
これはうちの猫なんですが とても厳しいと
これちなみに眩しくて目を覆っているだけなんですけど
ではどこを目指すべきかという話で 目指すべきは素結合な世界だと
良くない事例としては ある出来事が起きたときに呼び出すAPIを把握している必要がある
あるいは仕様変更のたびに APIを呼び出し元に影響がないか確認しなければならない
もちろん APIに呼び出し元に影響がないか確認するということは
呼び出し元を把握してある必要がある
これはやっぱりしんどいですよね
ということで目指すべきは 自分に関連する出来事だけ知っていればいい
いわゆるパブリッシュサブスクライブのパターン
そしてある出来事のイベントを送ったら その後のことには関与しない
Find and Forgetと言われるパターンですね
こちらが理想的です
そしてこのパターンを取ることで ステートレスにすることができます
じゃあ理想的な世界の図ってどんなものですかっていうと
こんなイベントバスが真ん中にあって 各サービスはイベントを送ります
そして高読したイベントがあるんだったら 各イベントバスに高読状態をサブスクライブするということですね
これで解決出来たこととして サービスは各APIのエンドポイントを知らなくていいということが実現できました
一方でイベントを受信したいサービスは サブスクライブすればいいということが実現できました
ここまでが一般的なイベントバスを導入している会社さんでも 既に考えられていることなんじゃないかなと思っています
じゃあ開発者が安心して利用できるイベントバスとは何かを 運ぶものではさらに一歩踏み込んで考えています
これは一旦ここまでで解決できた事柄について 説明をさせてください
サービスがAPIの依存関係を管理しているというのは 一旦解決ができました
これはイベントとして発生した出来事を記録すること
発生した出来事に関心があるサービスが サブスクライブすることで解決しています
またサービスがAPIのエンドポイントを管理する あそこのAPI あそこのサービスのAPIはあれだからとか
こっちのサービスのAPIはあれだから という管理は不要になりました
イベントバスのエンドポイントにだけ イベントを送ればいいということになりました
そして計画メンテナンスが可能になりました これは呼び出し先がメンテナンス中であっても
イベントバスの特性上 再送される キューイングされて再送されるということで実現をしています
しかしまだやるべきことがある hacomonoではここから先にさらに一歩踏み込んで
これらのことを必要なんじゃないかとして 設計をしています
開発者がより安心できるためには 互換性のないスキーマ変更を発生させない仕組みが必要なんじゃないか
アプリケーションコードに異なる バリデーションロジックを減らす必要があるんじゃないか
イベントバスから送られるイベントを 正規のものに限定する必要があるんじゃないか
あるいは開発者が開発環境と本番環境を間違えても 安全である状況を作る必要があるんじゃないか
そして開発者のミスによるイベントループや 再送による障害を抑制する必要があるんじゃないか
この観点からさらに踏み込んで設計を行いました
一旦これらの問題について 少し深掘りをさせてください
互換性のないスキーマ変更って 一体どんなものでしょう
例えばフィールドの削除 フィールドの型変更
イベントの削除 これらは非常に危険ですね
一方でフィールドの名前変更とかも危険です
こういうのを一時開発者が これは安全かなって考慮しなきゃいけない状況そのものが良くないと考えています
理想的な状況としては CIによって破壊的変更を不可能にし
CIをパスしているので安全だと言える状況が 理想的な状況だと考えています
またアプリケーションごとに異なる バリエーションロジックが実際存在するかと思います
より柔軟に詳細にイベントを コントロールする必要があると考えています
良くない事例として あるサービスでユーザーIDはUUIDを想定していました
あるサービスではユーザーIDはハッシュ値を想定していました
これシンプルなスキーマだと ただの文字列なのでどちらも通ってしまうという問題があります
でも理想的にはユーザーIDの形式はUUIDです
施設の最大文字数は256文字です
電話番号は国際電話番号形式で プラス 日本だとプラス81で始まるものです
URLはRHC3986形式です
そういうような より詳細にコントロールするというのが必要になってきます
また先ほども説明しましたが イベントバスから送られるイベントが正規のもの
これはどちらかというと 信頼できるという意味で言っています
もちろん攻撃者によるイベントを 受け入れてしまうような構成は
とても望ましくないというか これはプロダクション環境で運用することすらできないですね
また開発環境から本番環境に 送信できてしまう
あるいはその逆ができてしまう これも防ぎたいです
これは仕組みとして 開発者の注意をするとかではなく
仕組みとして防ぎたいですね
そのために 署名検証に成功したイベントのみを配信
後ほど詳細に設計のところで出てくるので
一旦こんな感じの理解をしていただければ 結構なんですけど
署名に成功したイベントのみを配信する
そして異なる環境からのイベントをブロックする
そして開発者は イベントバスからのイベントは
きちんと何か追加のバリデーションロジック
信頼性を確認するイベントロジックを 必要とせず信頼できるという状況を作りたいです
また 開発者が安心して利用できるイベントバスというところで
開発者のミスによるイベントループや 採送による障害を抑制するというのがあると思います
例えばループしたイベント 実装ミスでループしたイベントが発生してしまう
設定ミスでループしたイベントが発生してしまうというのは
発生し得るという前提において設計をしています
同一イベントの大量発行によるサービスダウン
これも発生し得るとして設計段階で考慮しています
そして大量イベント発生 これは少し開発者のミスではないのですが
あるサービスが大量のイベントを発火したときに
カスケード障害を起こしてしまう
これも分散システムにおいては結構あり得る話だと思っています
それらを踏まえた上で理想的には
ドイツイベントの ドイツ送信元のドイツイベントは拒否し
レートリミットによる送信間隔制御
実はこれ予定って書いてある通り まだ実装はされてないんですけど
レートリミットによる送信間隔制御を設けることにより
カスケード障害を防ぐ必要があるんじゃないか
これらを踏まえて実装ミスがあっても
障害を抑制する仕組みに倒す必要があると箱門では考えています
それでは実際にスキーマ駆動イベントバスというものの
詳細について説明をさせていただければと思います
まずこれは概要図なので
こういうコンポーネントがあると思っていただければよくて
後ほど詳細なAWSの構成図を用いた詳細な図が出てきますが
各コンポーネントこういう要素があるという風に受け取ってください
左上の方にスキーマを管理している
スキーマの互換性チェックをしている箇所があります
真ん中にイベントバスがあって各サービス間でやり取りをしています
そしてイベントバスを通ったイベントは信頼できるイベント
今ではバリッドイベントって書いてある通り
信頼できるイベントのみが通過します
じゃあ互換性のないスキーマ変更を発生させない仕組みの話をさせてください
これはプロトコルバッファーを用いてスキーマ管理しています
ただしプロトコルバッファーそのものは
互換性を壊す破壊ができます
ではどうしているかというと
バフCLIというツールを用いています
これはプロトコルバッファーエコシステムで
ご存知の方も多いと思うんですけど
プロトコルバッファーのジェネレーションとかもできるツールとなっております
これのブレーキングチェンジディティクションという機能があって
今画像にもある通り
フィールドのこれはチェンジタイプイント
イントからストリングに型変更をしようとしたときに
CIが落ちている
CIというかCLIが落ちている
異常を検出しているという状態ですね
これをCIに組み込むことによって破壊的変更を不可能にしています
これが互換性のないスキーマ変更を発生させない仕組みです
そしてアプリケーションごとに異なるバリデーションロジックを減らすというところの説明をさせてください
これはプロトバリデートという
これも同じくバフという会社が開発しているものなんですけど
バリデーションロジックの共通化を行っています
ちょっと見えるかな
これだとユーザーというメッセージに対して
IDというフィールドが定義されていて
これはUUID形式であるということを指定しています
そして年齢は最大で150歳
EメールはEメールアドレス形式
これも同じくUUIDと同じくEメールアドレスというバリデーション形式が定義されています
そしてファーストネームラストネームは最大64文字
ここが一つ面白いんですが
これCELというところで自由にバリデーションロジックを記述できる機能があって
もちろんこのプロトバリデート自体もこれで記述されています
例えばこれで言うと
ファーストネームがない場合
ラストネームはあることを保証している
このような比較的柔軟なバリデーションロジックを書くことができて
これがプロトバフとともに管理することで共通化を図っています
それで
イベントバスから送られるイベントを正規のものに限定するというところで
サービスと環境ごとに異なる非対称鍵を用いて
ちょっと署名してますよという話ですね
これはサービスAの開発環境は
サービスA側は開発環境用の秘密鍵を持って署名します
そしてイベントバスはそのサービスAの開発環境用の公開鍵で検証します
同じく本番環境も本番環境用の鍵で署名し
本番環境用の鍵でイベントバスが検証します
このような形式を取ることによって
サービスをまたいでサービスAを語ることはできないですし
あるいは開発環境から本番環境に投げても
シグネチャインバリットでジョットの検証でこけるということを行います
これで環境を間違えたあるいはサービスを間違えた
イベントの発行を抑制しています
こちらもイベントループ採送による障害を抑制するというところで
DynamoDBに送信元とイベントIDの組み合わせを保存しています
重複するイベントが発行された場合拒否をしています
一方でこれはカスケード障害の抑制が目的で
ExactoryOnceは保証していません
実はExactoryOnceを保証する実装をしてみたんですが
これは2フェーズロックとかのロック機構がイベントバス本体に必要で
これをメンテナンスしていくのは厳しいということで
トレードオフとしてExactoryOnceは保証しないという方向になりました
全体エキテクチャとしてこのような図があります
まずコンポーネントの説明をさせてください
左側がReceiverと呼ばれているコンポーネントで
右側がDeliverと呼ばれているコンポーネントになります
左側のReceiverという処理は基本的に同期で処理していい
一方で反面Deliverというところは非同期的に処理します
実際にイベントを送るような
イベントを送る流れを追っていこうと思うんですが
例えばサービスABCからWebhookで
Webhookの先がイベントバスですね
API Gatewayから先がイベントバスなんですが
イベントを送信します
そしてこの辺は説明しなくても皆さんご存知だと思うので
ラムダが起動してそこでJOTの署名検証や重複排除
プロトバリデートを実行して
それらが全て通ったらSQSに保存します
保存ができたことをもってサービスにレスポンスします
つまりサービス側はこれが保存できたのか
あるいはエラーになったのかが即座にハンドリングすることができて
エラーになったらエラーになった処理を即座に実行できます
反面送信側は非同期的になっています
これはSQSのラムダトリガーを用いてラムダファンクションが起動します
このラムダファンクションはもちろんSQSのトリガーなどメッセージを読みますし
そしてメッセージの属性情報から宛先を取得し送信をするということをしています
宛先には他のアカウントのSQSであったり
別のサービスのWebhookに対して送信をすることをサポートしています
これらがスキーマ駆動イベントバスと弊社が呼んでいるものですね
ちなみにこの送信と受信のWebhook部分についてSDKが開発されていて
開発者は基本的に送信と受信についてはライブラリを呼び出すだけという状況を作っております
それでは段階的導入プロセスについて簡単に説明をさせてください
すいません少々宣伝になってしまって恐縮なんですが
弊社にはFitFitsという新規プロダクトがプレスリリースされました
これはパッと見てもよく分からないですよね
これを読んでもあんまりよく分からないと思います
例えばフィットネス施設この中で行かれている方どれくらいいるかあんまりよく分からないんですけど
私はあんまりちょっと続いていかない方なんですけど
たまに行きたいなどこどこの施設に行きたいなって思う時があって
それを実現するような仕組みになっています
例えば今日はヨガ行ってみたいなとか
友人とピラティス行ってみたいな
そういう都度利用するということができる仕組みを作っています
これはただの宣伝ではなくてですね
これを実現するためにはデータの連携が必要ですという話で
左がhacomonoで我々がSaaSとして提供しているもので
右がFitFitsという新たなサービスで
これらの店舗情報
予約枠情報
店舗様スタッフ情報
プログラム情報を
このFitFitsという新規プロダクトは予約を取れるようにするために
これらが必要です
ここに段階的に導入をしております
一方で
FitFitsから予約を書き出すという処理も必要になる
というのが想像できるかと思います
こちらは実はまだ
このイベントバスシステムには載っておらず
ステップファンクションを用いています
より詳細には
弊社にはジョブマネージャーという開発者も
本日いらしているんですけど
ジョブ実行や
サーガパターンを実現するための
社内のジョブ基盤があります
これを用いて
予約というオーケストレーションの
トランザクションシステムを
同期的に実行をしています
今後
hacomonoではこれらのスキーマを
このイベントバスと統合して
ジョットの認証も含めて
統合して
統合的に扱えるようにしていこうという計画はあるものの
現状はこのように
一部の非同期的な処理が行える部分の導入にとどまっております
それでは
ちょっと早いかな
まとめをさせていただければと思います
まずサービス間のAPI呼び出しは
依存関係や影響範囲の把握が困難というところがあります
そしてそこを解決するために
イベントバスを導入し解決しました
一方でイベントバスそのものだと
破壊的変更ができないスキーマ管理の仕組みや
バリデーションロジックの共通化
不正なイベントを弾く仕組みや
過剰なイベントを抑制する仕組み
これらは
ものによってですが
基本的に備わっていない
私どもが検討したときには
マネージドのものは
これを全てを見倒すものはございませんでした
なので自作をするという選択肢を取りました
そして段階的な導入というところでは
新規プロダクトで非同期化できる処理から
導入を開始いたしました
さてもう一個宣伝になって恐縮なんですが
hacomonoではエンジニアを募集しています
事業成長を加速させる深い問題解決ができる
エンジニアを探していて
技術との仕組み
そして背景の深い理解
技術のトレードオフの把握と
その限界に挑戦できる
ビジネスニーズに合わせた
最適な問題解決能力があるエンジニアを探しています
挑戦できる環境として
プラットフォームエンジニアリンググループという
チームがある通り
プラットフォームエンジニアリングを推進していたり
マイクロサービスマルチプロダクト化を推進しており
結構なかなかチャレンジングな環境で
開発ができるんじゃないかと思っています
また最初の方で申し上げたように
効果要請・高信頼性が要求されるシステムの設計
実装に挑戦できます
もしよろしければhacomonoの求人について
調べていただければと思います
本日の発表についての出典になります
こちらは後ほど資料で
もし拝見したい方がいらっしゃれば
見ていただければと思います
それではちょっと早いですかね
ご清聴いただきありがとうございました
はい発表ありがとうございました
質疑の方法の方を移らせていただこうと思います
3件ですね
来ております
まず上から順番に見ていこうと思います
複数のイベントを
一つのイベントバスとして管理していると
どのパブリッシュを何がサブスクライブしているか
全て把握するのは大変にならないですか
とのことです
こちらよろしくお願いします
これはどっちの観点かっていう話が多分ありまして
アプリケーション観点か
あるいはイベントバス観点かっていう
2つのところから話をさせてください
アプリケーション観点でいうと
できればその管理をしたくない
詳細でいうとサーガのコレオグラフィーパターンのような
自分に関連するイベント
もしくはそのイベントのレスポンスだけを
知っているという状態を管理したいので
どのパブリッシュが何をサブスクライブしているか
把握をすることをあまり目的としていないというのがございます
これで答えになっているのか分からないですけど
イベントバスとしては逆に
これらを全て把握する必要があり
それらを全て管理しております
というのが答えになりますかね
ありがとうございます
続きまして次の質問に行こうと思います
バリデーションロジックの共通化で
ユーザーIDはUUIDにするとありましたが
各サービスの都合で
イントがいい、ULIDがいい、UUIDがいい
などといった場合は動揺していますでしょうか
とのことです
こちらよろしくお願いします
こちらも同じく
イントであることを
例えば値のレンジを指定することはできて
そうですね
ユーザーIDを必ずしもUUIDにしなければならないということではなく
イントを用いることはできます
一方で途中から例えばイントに変えるなどは
結構破壊的変更になるので
もし途中からの変更の話をされているのであれば
別のフィールドで表現する必要があるのではないかなと思っております
そうですね
各サービスの都合でイントがUUID
なので必ずしもUUIDに限定せず
例えばイントも範囲を指定できる機能がありますし
その範囲の中に留まっているかというのを
バリデーションロジックとして記述することができます
はい
ありがとうございます
続いての質問に移らせていただこうと思います
処方的な質問ですが
例えばシステムAがため込んだ店舗一覧情報を
システムBが参照したくなった場合
どんなイベントが流れるのでしょうとのことです
なるほど
これはあれですね
途中からサブスクライブした場合ということですよね
おそらくきっと
システムAがため込んだ店舗一覧情報を
Bが参照したくなったというのは
おそらくそうですね
これは現状
新たな情報のみ参照になってしまうので
ご指摘いただいているような
大量にデータが流れてくるようなことはない
一方で別の方法でデータの連携が必要という課題がありますね
なので一旦今あるデータ
例えば新規のプロダクトの話で言わせてもらうと
新たにこの新規のプロダクトをオンにするという設定があるので
オンになったときにイベントが飛びます
なのでこの問題は解決しているんですが
今までのイベントを全てサブスクライブしたいとなった場合
今このシステムではちょっとそれは再現
行うことができないですね
はいありがとうございます
続いての質問
行かせていただこうと思います
イベントバスを導入すると
イベントバスがシングルポイントとなって
メンテナンスが難しくなるような気がします
何か工夫をされていますでしょうか
との答えです
よろしくお願いします
まさにこれはそうで
個々のサービスが信頼しあって
あるいはある種契約を結んで
APIを呼び出していた
その複雑さが全てイベントバスに集約されます
なのでイベントバスのメンテナンスというのは
非常に難しくて
落とせないサービスになるかと思います
もしこの工夫をしているというところで言うと
先ほどレシーバーが同期的に処理をするという話をしたと思います
もし例えば何か問題があって
イベントが保存できなかったとき
それをクライアント側にきちんとエラーとして返す
ということを行って
クライアント側が再送してもらう前提に立つと
そこに関しては少しメンテナンスが楽になります
またブルグリンデプロイであったり
テストコードを非常に多く書いているので
そういう意味で工夫をさせてはいただいてますが
おっしゃるようにシステムの複雑さが
ここに集約されるので
メンテナンスは難しくなっております
はいありがとうございます
次の質問を最後にさせていただこうと思います
こちら時間の都合ですね
イベントバスの設計実装まで
どれくらいの時間で完了しましたかとのことです
こちらよろしくお願いします
はいどれくらいだったかな
今年の1月2月とかから設計してちょうど今本番環境も動きているような状況なので
半年とちょっとですかね
9ヶ月くらいになるかなと思います
はいすいませんこれちらでよろしいでしょうか
はいありがとうございます
こちらの以上で質疑を終了させていただこうと思います
改めて発表ありがとうございました
ありがとうございました
ありがとうございました