Microservices Meetup Vol.5 (API Gateway & BFF) を開催しました
こんにちは、qsona (twitter) です。弊社FiNCでは Microservices Meetup という技術勉強会を開催しており、今回で5回目の開催になりました。毎度盛況でありがたい限りです。
今回も主催として全編じっくり参加させていただきましたが、4人の方の発表、そしてパネルディスカッションの議論は、とても重みがありました。本稿ではこのイベントの発表や議論の内容について振り返りながら、考えたことを記していきたいと思います。
毎回サブのテーマを変えておりますが、今回は API Gateway & BFF (Backends For Frontends) をテーマにしました。これらがどんなものかは、特に前半2つの早川さん・古川さんの資料にも多く触れられていますので、初見の方はぜひご参照ください。
ご登壇していただいたのは、以下の四人の方々です。
- 早川さん (twitter: charlier_shoe, 日本オラクル株式会社)
- 古川さん (twitter: yosuke_furukawa, 株式会社リクルートテクノロジーズ, Node.js日本ユーザーグループ代表)
- 高松さん (twitter: shimpeiws, 株式会社アカツキ)
- 寺下さん (twitter: shotat_jp, 株式会社リクルートライフスタイル)
いずれの方も、打診を二つ返事で快諾いただき、当日素晴らしい発表をしていただいたことを非常に感謝しております。この場を借りてお礼いたします。
当日のtwitterタイムラインの様子を togetter にまとめました。そちらに資料やまとめ記事へのリンクもあるのでご利用ください。盛り上げてくださった参加者の方々、また、本イベントのまとめ記事を書いて下さった方々にも感謝いたします。
発表
この4つの発表を、個人的な感想を付加しながら振り返りたいと思います。
早川さん 「APIのことはすべてシーマンが教えてくれた。」
シーマンの名言から良いAPI設計の話につなげるという、コミカルな話でした。チーム間の距離感、あるいは疎結合の度合についての非常に本質的な話題に、シーマンが斬り込んでいました(笑)。
その良い距離を維持するためにも、コンシュマーにとって使いやすいAPI設計が重要です。そういった観点を含め、API Gateway の役割について論じていただきました。このAPI Gatewayは、一面では流量制御やキャッシュなどバックエンドのためでもありますが、もう一面のコンシュマーにとっての意味も大きく、どのような状態が「使いやすい」のかを考えて技術選定していくのは確かに重要だと感じました。
また、OracleのAPI Gatewayの新製品、 API Platform Cloud Service についても話してくださいました。基本的に、マイクロサービスをやろうとすると種々の面倒ごとが伴うため、それらに対処してくれるものが欲しくなります。API Gatewayの製品としては Kong (github) が有名ですが、Kongにはマイクロサービスで欲しくなる「1リクエストで複数のAPIを叩く」機能はありません。パネルディスカッションでこの件に触れたところ、このOracleの製品ではそれもやってくれるということでした。
今回の勉強会ではあまり深く触れられませんでしたが、様々な製品の仕様を比較することは一度やってみたいと思っています。自分が使う使わないにかかわらず、それらがなにを成し遂げたいかを理解したいからです。
早川さんには vol.1 の時にも API Gatewayの話 という発表をしていただいており、その時も興味深い話をいただいていました。
古川さん 「Step by Step BFF」
BFFに関する基調講演のような位置付けで、その役割や導入方法について幅広く話していただきました。
まず、BFFのユースケースの例を5つ挙げられています。
個人的には、ファイルアップロードのユースケースは考えたことがありませんでした。画像のような静的ファイルは、例えばAmazon S3のようなストレージに保管することが多く、(特にマイクロサービスの)バックエンドサービスはあまり画像のアップロードの仲介役を受けたくありません。そのためにクライアントでS3にダイレクトアップロードする手法もありますが、これはこれで認証などの面倒な問題が発生します。この役割をBFFが持ち、S3にアップロードしつつ、バックエンドとはアップロード後のURLでやりとりをする、というのがこの問題の一つの解になります。
次に、koichikさんの Isomorphic Survival Guide そして古川さん自身の Why we need Rich web application framework という発表資料から引用しつつ、歴史を見ながらBFFのアーキテクチャ上の役割を論じられています。
ことマイクロサービスに関しては、歴史に学ぶことは重要だと思います。例えばSOA(サービス指向アーキテクチャ)の失敗を理解し同じ失敗をしないようにする、という具合です。
BFFの実例の紹介もありました。Twitter, Netflix, そして古川さん自身のリクルートテクノロジーズの例です。Netflixのように「対応デバイスが非常に多い」時に一つずつにBFFを置いていく例は、マイクロサービスの本領発揮という感じがします。また、リクルートテクノロジーズのbooking tableの事例は、昨年末のNode学園祭での yoshidan さんの発表 (資料) からもわかるとおり、本格的なServer-Side Renderingなど先を行っている様子が伺えます。
最後に、タイトルにもある step-by-stepでBFFを導入していくための手順を示されました。キーワードは「リアーキテクト」です。一旦Proxyから始めるというのは非常に納得感があり、新しいアーキテクチャを導入していく上での考え方という意味でもとても参考になりました。
高松さん 「Webサービスの初期開発とマイクロサービス・BFF」
高松さんは直接の面識はなかったのですが、BFFに関する発表資料や記事をお読みし、より深くお聞きしたいと思い、お声がけしました。
高松さん自身が担当したWebサービスの新規開発について、要件とこれまでのストーリー、BFFを必要とするモチベーション、そしてプロトタイプ実装を示すところまで話してくださいました。
まず @joker1007 さんのツイートを紹介しながら、この開発での「選択と集中」について話されました。スピードが求められる新規開発ながら、最初からSPAのサーバサイドレンダリングを選択しているのは特筆的です。
また、特に新規案件では画面にかなり沿ったAPIを作ってしまうことが起こりがちですが、それを避け、リソース粒度を細かくしたRESTful API設計に寄せたということです。
個人的には、開発の初期からリソースを見定めていくのは結構な力量(経験)が必要だと思っています。
ただ、あとで高松さんにお伺いしたところ、それ自体はさほど難しくなく、逆にそうせずにAPIが画面に寄る辛さだけは避けたかったと話されていました。この辺りは、高松さんやチームの開発力の高さを感じさせられます。
その分の、APIを複数呼び出すなどの複雑さが必然的にクライアントに移るわけですが、それに対処する層としてBFFがあります。高松さんの事例で重要なポイントは、初期開発にBFFの実装は含めていないながら、BFFというアーキテクチャ上解決できる余地を残す、ということは最初期から考慮されていることです。
最後に、GoでのBFFプロトタイプ実装を示されています。一つ前の古川さんの事例ではBFFをNode.jsにしてServer-side Renderingの役割も兼ねていますが、高松さんの例ではそこは分けているのは一つの特徴だと思います。本番運用が始まったらぜひまた深く聞かせていただきたいです。
寺下さん 「Railsで作るBFFの功罪」
ちょうどこの勉強会のテーマをBFFにしようかと考えていたときに、タイミングよく目に飛び込んできたのが寺下さんの記事 「Spring + Railsによるサービス分割の取り組み」 でした。ホットペーパービューティーという大きなプロジェクトでの事例ということで、詳しく聞いてみたいと思い、お誘いさせていただきました。
やはり興味深いのは、BFFのレイヤにRailsを選択されたことです。資料の中でも触れられているとおり、Railsはそれ自体そこまで速くはないのと、Rubyが特段並列処理に向いていないこと、またフルスタックな機能(とくにActiveRecord)が生かせないため、積極的にRailsを採用する理由はないように思えます。
しかし実際には、並列処理なし・キャッシュなしの最もナイーブな実装でも、パフォーマンスは要件に対して十分であったとのこと。
また、ActiveRecordそのものは使わないが、代わりにRepository層をはさむなどの工夫でControllerからの使い方は普通のRailsとほぼ変わらないようにしたとのこと。Sinatraのような薄いフレームワークの採用も考えたが、その場合に結局Railsのような何かが出来てしまう、それよりはRailsを採用して書き方を安定させる、というのは納得できる考え方でした。
その後にパフォーマンスチューニングの話がありました。全体的に、「推測するな、計測せよ」を地で行くような進め方で、技術選定や改善の進め方として非常に参考になる発表でした。
パネルディスカッション
早川さん、古川さん、高松さんのお三方にパネリストとして参加いただき、私が司会進行させていただきました。その内容をいくつか取り上げて紹介します。
BFFでPOST系のリクエストのオーケストレーションも行う?
複数のGETリクエストの集約はBFFの大きな役割になります。では、POSTなど更新処理を伴うエンドポイントを複数呼び出すことは行うのでしょうか?
この質問に対しては、基本的に「行わない」という意見で一致していました。BFFのレイヤに本来バックエンドが持つべきロジックが流出してしまう懸念がある、というのが大きな理由です。
取得を複数叩くのはUIの都合ですが、更新系を複数叩くのはふつうどこかのサービスが担当すべきロジックになるでしょう。
BFFの開発はどのチームが担当する?
フロントエンド、サーバ、それともBFF開発チームを別に置くなどいくつか考えられるところです。ここの議論ではほぼ「フロントエンドのチームが担当する」という意見で一致しました。BFFは ”For frontend” 、フロントエンドのためのものだからです。
ただ、その後色々聞いてみて、その組織の構造や特有の事情によっても変わってきそうだな、とも思いました。いずれにしても、フロントエンドのエンジニアが積極的に関与すべき、ということは変わらなそうです。それだけフロントエンドに幅広いスキルが求められるようになっているとも言えます。
BFFにGraphQLのようなクエリー型APIを利用するのはどう思う?
この質問に対しては、古川さんから明瞭な回答がありました。例えば昨年末ごろにGitHubがGraphQLのAPIを提供しましたが、これは非常にいい例で、GraphQLの自由にリソースを取得しやすい特徴から、デベロッパーが使いやすい状態になっています。GitHubのAPIを利用するデベロッパーは世界中におり、どんな利用のされ方をするかはGitHub側には分からないので、このような柔軟に取得できるAPIの価値が高くなります。
一方で、通常のアプリケーションの開発のように、APIを提供する側と利用する側の距離が近ければ、基本的にはその目的の沿ったAPIがあればよいので、柔軟に取れる必要性はそこまでなく、GraphQLのようなものを採用する必要性は低いのではないか、ということでした。
この議論は、単に「公開APIかそうでないか」ではなく、例えばFacebookのような大きな組織では、チームが疎結合になり汎用的なAPIを提供する必然性が出てくるものと思います。組織の作り方と採用する技術が連動する例としても面白いと感じました。
懇親会
技術的な話を中心に、様々な話題に花が咲いていました。今回はフロントエンドに近い話題だったため、WebフロントやiOS, Androidのエンジニアの割合が普段に比べると多かったように感じています。
遅くまで楽しんでいって頂ける方も多く、嬉しい限りでした。
おまけ
この翌日には同じく弊社で Node学園 24時限目 が開催されました。そちらで弊社のBFF事例についてLTしました。
総括
Microservices は根底の思想こそシンプルですが、それを実際に運用していくにはエンジニアとしての総合力のようなものが必要になると感じています。今回はテーマがAPI Gateway & BFFというアーキテクチャの概念的なものだったこともあり、登壇者の方々やその製品・チームの思想を色々聞くことができ、このイベントを通して自分自身の考え方が広がるのを感じました。銀の弾丸は存在しないながら、過去の経験や他者の事例から学び、その時それぞれの状況に対しての解を求めていくことの重要さを改めて感じました。
Microservices Meetupは今後も開催していきます。興味のある方は、ぜひ connpassのグループに参加してください(通知を受け取ることができます)。
https://microservices-meetup.connpass.com/
最後に
株式会社FiNCでは、積極的にエンジニアを採用しています。
FiNCはヘルスケアを手がけるベンチャー企業です。本イベント中では、発表の合間に、参加者がストレッチをする時間「ウェルネスタイム」がありました。これは、弊社のトレーナーが実際に指導しています。
また、懇親会では料理が振る舞われました。弊社の管理栄養士のメンバー達が栄養バランスの良いメニューを考案し、調理しています。
FiNCには、一人ひとりの心身の健康をサポートするため、エンジニアだけでなく多くの分野の専門家が集結しています。このような技術イベントにも、部署の垣根などなく多くの人が協力してくれて、まさに家族のようなチームだと感じています。
そんな我々とビジョンを共にしてくださる方、マイクロサービスの開発に魅力を感じる方、試行錯誤しながらのBFFの開発に興味がある方、などなど、ぜひ一度お声がけください。
