ブログまとめ枠を逃して通常参加だったけど、最速目指してまとめます。

速報版です。誤字脱字、情報漏れは順次保管していきます。

Connpassイベントページ
https://microservices-meetup.connpass.com/event/52516/

Twiiterタイムライン
https://twitter.com/search?q=%23microserv

Togetterまとめ
https://togetter.com/li/1095919

@wenbose さんのまとめ
Microservices Meetup vol.5 に行ってきたので雑にまとめる

レポート

「APIのことはすべてシーマンが教えてくれた。」 by @charlier_shoe さん

Oracle 早川さん

（到着遅れたので途中からです……orz）

backend for frontend

クライアント最適化した形式に変換

API Platform Cloud Service（宣伝）

近日公開予定

APIライフサイクルをサポートする機能群をすべて揃える
環境を選ばずに利用可能
- オンプレ、クラウド
Apiary機能統合

直接APIを作るものではなく、APIのライフサイクルをサポートするもの

APIドキュメントをSwagger/API Blueprintで記述して
ワンクリックで開発者ポータルに公開されてモックが生まれる

Documentation-Driven Contracts

MarkdownとJSON混ぜたような記法で記述するとドキュメントが出来る

Oracle Code

開発者向けイベントやります！ 5月開催予定

「step by step BFF」 by @yosuke_furukawa さん

日本Node.jsユーザグループ会長
リクルートテクノロジーズ古川さん

レガシーソフトウェア改善ガイド
Re-Architecte

モノリス的なアーキテクチャでスケールしないと感じたら、フロントエンドとバックエンドと分けて考える

BFFとは

マイクロサービスがBackendsにあって、BFFがあって、Frontendsがある。

Sam Newmanさんが多分最初に提唱したっぽい。

ユースケース1つめ

APIまとめる君

複数のAPIをBFFで呼んでフロントエンドのほしい形にJSONにして返す

ユースケース2つめ

セッション管理

セッションストアとのやり取りをしたうえで、APIを呼ぶ

ユースケース3つめ

SSR

HTMLのレンダーをしてHTMLを返す

ユースケース4つめ

ファイルアップロード

大きいファイルを投げるのはAPIは使いにくい、FileChunkedUpload使いたい

BFFで受けっとったチャンクをS3などに1つのファイルに戻してから、バックエンドのAPIをファイルパスをパラメタにしてリクエストする

5つめ

リアルタイム処理 WebSocket/LogPolling/SSE

フロントはWebSocketなど、バックエンドとPub/Subする

BFF以前

90年代まで3層C/Sシステムだった
90年台半ばからはWEBシステム
2010年はSPA
2013年はSPA with Microservices

どんどんクライアント側にロジックが寄っている&サーバが薄くなっている

でもフロントエンドはUIに注力したい

この流れをバランスさせるためにBFFはあるのではないか？

BFFをNode.jsにすると、FrontendsとBFFをロジック共通化が図れる

BFFとは

ドメイン特化のサービスとリッチなクライアントをつなぐ調停役

Twitterの例

モバイルTwitterを移行したよ

Scalaでマイクロサービス作って、BFFをNode.jsで作成

最初はRails
途中からScala化してMicroServices化
最近Node.jsでモバイル用のフロントエンドを差替えた

WEBシステムの変遷を辿っているのが興味深い

Netflix

Netflixはバケモノ

内部APIを再設計した

デバイスが異常に多い＝APIも異常に多い

間に調停役BFFを置く（当時はクライアントアダプタコードと呼ばれていた）
デバイスごとに適切なレスポンスを返すBFFがいる

2012年の話

OSFA(One Size Fit All)しないほうが作りやすい＝1つで全てに対応しない

リクルートテクノロジーズ

SSRをBFFでやってる

BFFを導入するとき

フロントエンド、バックエンドを分業させてエンハンス速度を上げる
レガシーなシステムをリアーキテクトする

BFFを導入しないとき

フルスタックが多い
モノリシックで速度を取る
SEOいらない、リアルタイムいらない

step by step BFF

既存システムとフロントエンドの間にBFFを挟む（タダのProxyとして）

「Webサービスの初期開発とマイクロサービス・BFF」 by @shimpeiws さん

アカツキ高松さん

ライブなエクスペリエンスを提供するサービス

リアルタイム性を求められる

技術要素

SPA(React+Redux)
Isomolphic Architecture
Rails

など

開発初期の選択と集中と課題

立ち上げ期

フルスタック４人

アーキテクチャ、設計指針決定

開発初期

フルスタック５人

開発中期

4チームに分割
- ユーザ系、サービス基盤系、インフラ系……

専門性が必要な業務が増えてきた

グロースハック
MW,デプロイとか

コード比率

rails 15,000行
JS/JSX 60,000行
JS 25,000行

反省点

「後から考えられるようにしておくのと、何も考えていないのは完全に別だし、やってはいけない」

立ち上げ期

SPA + SSRは最初から確定していた

ちょっと要件重いかもという自覚はあったが要件として必要だった

Pros

ダイナミックなWEBフロントエンドを作りやすい
SPAの構成で一本化

Cons

開発工数はかかった
Node.jsのフロントサーバが増えて、デプロイ、管理が複雑化した

API設計を単純化

ドメイン設計に時間が掛けられなかった
画面ベッタリなAPIだと保守性下がるのでしたくない

細かい粒度で作るようにした

設計・実装が楽になった

クライアントサイドの実装に負荷がかかるようになってしまった

ここでBFF！

レイヤーをたせるようにしておくのはリアーキテクチャしやすい

API関連のアーキテクチャの決定をペンディングすることが出来ていた

BFFに求めるもの

レスポンスが低下するのは避けたい
フロントエンドと密結合するため更新頻度が上がる

言語、フレームワークの選定大事

フロントエンドからのハンドリングが減った

BFF実装は難しくないけど複雑
ジェネレータとか使わないと面倒くさいかも

ウェルネスタイム

体側伸ばし
- 片腕を伸ばして、もう片腕で手首をつかむ
- 伸ばした腕側の体側を伸ばすように体を傾ける
- 傾けたまま体をひねって、下を向くように
ワイドスクワット
- 足は肩幅以上に開く
- 椅子にお尻が少しつくくらいに腰を落として立ち上がる
ふくらはぎ伸ばし
- かかとを付けて、足先を30度くらいに開く
- かかとを付けたまま背伸び
- 5秒キープ

「Railsで作るBFFの功罪」 by @shotat_jp さん

ホットペッパービューティ HPB
2007年からサービス

リクルートはココ数年でシステムの内製化を始めてる

１０年運用したシステムは密結合＆レガシーだった

課題

View/Logicが混在
そもそもMicroservices化いるのか？

どうしたか

バックエンドとBFFを切り離した
サービスの分離（マイクロサービス化はしなかった）

Strangler Application
『マクロサービスアーキテクチャ』に書いてある

API呼び出し回数が増えないようにする
かといって全部入りAPIは作らない
BFFからのAPI呼び出し回数は７回くらい

仕組み

APIサーバはSpring Boot
- 既存コードと同じJavaだったので
DocはSwagger
BFFはRails
- 開発者が多い
- Sinatraとかも考えたが主流から離れそうという懸念
Node.js/Goの方が良いのではないかという検討はあった
- 開発効率優先
- パフォーマンス、SPAは優先度低かった

BFFの役割

API Caching
SSR

Rails

ActiveRecord削る
削りすぎないように注意した

MVC + R

One Repository : One EndPoint

性能面

API直列呼び出しは遅い
NWは意外とボトルネックにならない
フルレンダリングは重い

でもとりあえず十分な性能が出たので保留

BFFのチューニング

RackをPumaにする
IO wait でスレッドを切り替える
CPUが振り切れてしまうのでこのケースでは効果が上がらなかった

BFFを薄くする
Rubyコードのチューニング
効果が大きかった

APIの並列リクエストを使う

APIキャッシュを使う
考えること多い

BFFの後ろにBatch専用のAPIGatewayを立てる
APIGatewayの多段化

120ms -> 75msに短縮

スループット
- BFF薄くする
レスポンスタイム
- 必要になるまでは後回しで良いかも

パネルディスカッション

API GatewayとBFFの違いは何か

API GatewayはBFFに包含される概念
- 1つの使い方
- 流量制御や認証もBFFでやると良さそう

API Gateway製品のカバー範囲

製品名にAPI Gatewayって使われることが多い。自動でやってくれるとか。BFFっていうと自分たちでコード書かないと行けないイメージ。
API Gatewayってどこまでやってくれる感じ？
- OAuthなどのRESTに近い部分は含まれそう
- WebSocketとかRESTと直接関係ない部分は当面含まれないのではないか

KongなどのAPIまとめるようなことをしてくれるけど、Oracle API Cloudではやってくれる？

Service Fallout?という返す情報に必要なAPIを更に呼ぶ機能がある？

BFFがバックエンドに近いところをどこまで持つ

BFFにロジックをどこまで持たせるか？指針などあるか
- 前提としてバックエンドはRESTfulになってるとしてDDD的な意味でドメイン層になるのでビジネスロジックはすべて持つ
- BFFでビジネスロジックの解決はしない
  - フロントエンドが要件を伝えてバックエンドがビジネスロジックを組む
- バックエンドにSQLをパラメタとして投げるような設計はしない
BFFがポストオーケストレーションみたいなことはしない？
- ポストオーケストレーションはドメインロジックなのでBFFのしごとじゃない

BFFの担当はフロント？バック？独立？

フロントエンドエンジニアがやっている
"for Frontend"なのでフロントエンドが責務を持つべき

RPCかクエリか？（聞き損ねた）

GitHubはRESTfulとGraphQLを提供している
- RESTfulだけだと効率悪いからGraphQLを提供している
  - これはコンシューマに利用してほしいから
RPCにするのかGraphQLにするのかという話は利用者が誰かによって判断

フロントとバックエンドだけで分けた理由

速度が必要だった
フロントに負荷が行くのはわかっていた
- 今後GraphQLを入れるか、BFFを入れるかは検討していく

「マイクロサービスはバックエンドエンジニアにワクワクを与えてくれるアーキテクチャ、BFFはフロントエンドエンジニアにワクワクを与えてくれるものと思っている」

感想

リアーキテクトの実例が出始めた（マジで感謝！）
リアーキテクトのためにBFFを入れるところから段階的にすすめる手法に希望を感じた
やっぱり最初は少数精鋭で始めるのが良さそう
アーキテクチャレイヤー追加の余地を残すなどの冗長さは必要