ネイティブアプリ用のBFFを作ったマスタカです。
作ったけど作り終わった後に、割とやらかしたなぁもっとこうすればよかったなぁと思うことがあったので備忘録として書いておく。
・システム構成
アプリ -> BFF -> BE API -> データソース
ここのBFFのクラスタをどうやって分けるかという話
・BFF作成前にやること
結論の内容を最初にやること。
見切り発車すると、ネイティブアプリなので後で叩き先を分けるのがしんどくなる。
・全部乗せ1クラスタBFF
BE APIが100種類あり、アプリの画面が別々で90ヶ所ある前提
90種類のリクエストを一つのBFFクラスが全部受ける。
アプリ -> BFF(1〜90) -> BE API(1〜100) -> データソース
・メリット
デプロイするコードが一種類のみになるので実装が楽。
・デメリット
負荷試験の実施が面倒
Aは負荷が多い
Bは負荷が少ない
そういうものをまとめて負荷試験を実施する必要がある。
理論上はできるんだけど、結構面倒
性能限界が不明なのでリリース後の判断が難しい
API一本だったら性能限界はhogehoge QPSって分かるんだけど
BFFの後ろに色々バックポストがあると
API1はhogehoge QPSで許容内
API2はfugafuga QPSで許容内
だけど
API3とAPI4は負荷が予定の3倍来てます。
果たしてこれ食えるんでしょうか？
しらねえwwwwwwwwwwwwwwwwwwwwwwwwwwwww
初心者あるあるだけど、アプリからBFFへのリクエストが1,000QPSだったら食える場合
API1とAPI2とAPI3とAPI4を足して常に1,000QPS食える訳じゃない。
例えば、API3が非常に遅いAPIだとAPI3に100QPS来たタイミングで食えなくなるかもしれない。
だから、どこのリクエストが増えるかで食える食えないは大きく変わるので性能限界は正直事前には測れない。
バックポスト先の障害でBFFが全部死ぬ
API4のレスポンスが遅くなった場合、それに引きずられBFF4のレスポンスも遅くなる。
その場合、BFF全体として食えるQPSが減り、最悪BFFが死にアプリの画面が全部表示できなくなる。
インフラ障害時のリスクが高い
拠点分散してると思うけど、ピンポイントに分散してるクラスタに障害が発生した場合アプリが動かなくなる可能性がある。
ようするにSPOF
・画面と1:1に対応するようにBFFクラスタを立てる
BE APIが100種類あり、アプリの画面が別々で90ヶ所あった場合、
BFFを90種類作り、画面ごとに経由するBFFクラスタを別とする。
アプリ -> BFF1 -> BE API1 -> データソース
アプリ -> BFF2 -> BE API2 -> データソース
アプリ -> BFF3 -> BE API3 -> データソース
アプリ -> BFF4 -> BE API3と BE API4 -> データソース
etc
・メリット
全部乗せ1クラスタBFFのデメリットの逆
・デメリット
全般的な話
全部乗せ1クラスタBFFのメリットの逆
クラスタを分けても無駄なことがある
BE API3が死んだ場合、BFF3とBFF4と同じ参照先なので両方死ぬ。
例だと以下二つが死ぬので分ける意味がない。
アプリ -> BFF3 -> BE API3 -> データソース
アプリ -> BFF4 -> BE API3と BE API4 -> データソース
また、アプリから直列に叩く必要がある画面もありそこも死ぬ。
アプリ -> BFF2
を叩いた結果から
アプリ -> BFF3
を叩く。
当然BFF3が死んでたらBFF2を叩く意味がない。
・結論
ありきたりだけどある程度の粒度でまとめたBFFを複数立てるのが正解だと思う。
問題はこの単位。
最初にやること
BFFに載せる予定のBEのAPIと画面を全部洗い出す。
次にやること
似たようなドメインは同じクラスタにする。
ドメインが同じであれば関連する画面になる。
なので関連するBE APIになるし、死ぬときは一緒に死んで問題ないと思う。
最後にグルーピングする
難しいのはここから、ドメインごとにバラバラにクラスタにするか似たようなドメインをまとめてクラスタにするか。
境界づけられたコンテキストと同じ考えになると思う。
正直正解がないのでマスタカの考え方だけ記載する。
・他に巻き込まれてユーザー影響が出ると困るものは別クラスタにする。
ユーザーに告知するものや、サービスとしての優先度が高いものは別クラスタにして他は一切載せない。
・QPSが多いやつは別クラスタにする。
多いやつに引きずられて小さいやつも一緒に死ぬのを避ける目的。
・BE APIが同じBFFは同じクラスタにする。
BEが同じであればおそらく同じドメインになるのでまとめた方が良い。さらに死ぬ時は一緒に死んで良い。
・QPSが少ないやつはまとめても良いと思う。
QPSが少ない=ビジネス上の価値が低い=改修の可能性が低いになるので、その他クラスタにまとめてコスト下げて良いと思う。
全部乗せ1クラスタBFFで途中まで行って割と失敗したなぁと思ったので皆様は同じ轍を踏まないように・・・w
