はぜにっき

日記です。（毎日更新ではない）

Microservices Meetup vol.9 (FiNC App & Frontend)に参加した！ときのメモとか感想レポート

Enginnering

microservices-meetup.connpass.com

FiNC Technologies社が主催するMicroservices Meetup の9回目に行ってきた、ときに学んだこととか、話したこととか、わからなかったことのメモ。
間違った点とかあったら優しくマサカリを投げてくれると嬉しい。

（関係者のツイートを無許可で埋め込んでいます。駄目であればお伝えください。消します）

自分の立ち位置

主にバックエンドエンジニアをやっている人。
Microserviceはちょっとだけ。（？）
最近フロントエンド界隈のことに興味を持ってきてReactの勉強を始めたけどまだ全体像を理解できていなくて苦しんでいる。
最近はエンジニア組織全体での開発効率の向上、コミュニケーション、長期的な開発部隊の経営、みたいなことを一エンジニアとして考えていることが多い。

各発表についてのメモ、と思ったこと

ウェルカムトーク「マイクロサービスとクライアント: 理想と現実の狭間で」

主催の @qsona sanのウェルカムトーク。
Meetupの主題である「マイクロサービス」そのものの利点と注意点を説明してくださった。
マイクロサービスにすればサービスが全て疎結合になるわけではない という話がなるほど、となった。
「どこで結合させるか？」「どこで動作を確認するか？（責任の位置）」ということを考えて作っていく必要がある。
で、その結合させる点がフロントエンドで、ユーザ体験を作るために複数のマイクロサービスを使う という感じになる。（＝ハブ）

後半ではFiNC社で取り組んできた内容についての紹介と、重要な概念であるBFFとMicro Frontendsについての説明。

最後のスライドが好き。

https://speakerdeck.com/qsona/ideal-and-reality-of-microservices-from-the-client-side?slide=21

ウェルカムトークだからのんびり聞くかと思ったらめちゃくちゃ濃い内容でびっくりしてしまった。これだけでも考えさせられるお話で有意義でした

「クライアントサイドから考えるマイクロサービス」

FiNC Technologiesのクライアントアプリ開発者の @neonankiti san のクライアントアプリケーションから見たマイクロサービスについてのお話。

マイクロサービスによってリソースの表現が違っていて、それを統合させることが難しい、というリアルな課題と、それに対する解決策としての腐敗防止層の流れ。
APIガイドラインとかの考え方もとても参考になる。「コンセンサスを取った上で開発する」ことが明示的になり、重要性が増して、安定した開発フローになる。

腐敗防止層については質問したら細かい定義と必要性について答えてくださった。
（👇のツイートだけじゃなくて上下のスレッドを見ていただけると。）

あと、 次の発表者である@takasek sanと一緒に "iOSアプリ設計パターン入門" という本を書いている @ktanaka117 san からも補足をもらった。ありがとう。

次の話。
リソースの表現の差異と似たような話が別レイヤで起こっている件としてiOS/Android間での実装や設計の違いがあるという問題があった。
iOS/Androidはチームが違っていて、かつ使う技術も違うということで分断しやすそう、という印象は確かにある
で、それを定期的なコミュニケーションを取ったり情報共有をすることで解決した という話だった。

最後にはビジネスインパクトを踏まえた組織構造についての説明。
エンジニアだけで固まるのは確かに良くない（と haze も感じている）。ビジネスを考えた上でのべき論だったり組織構造を考えていくことは重要だと感じた。

「マイクロサービスとクライアントとコンテキスト境界」

FiNCでiOS Appを作っている @takasek sanのコンテキスト境界をどこに置くか、というお話。
境界はチーム編成の輪郭に従う という重要な概念をさらっと説明されていた。

その後の話は自分にDDDの理解が無さすぎて正しく理解できなかった。つらい。
（そもそも今回のMeetupのサブタイトルがApp & Frontendなので理解しておけという自戒）

DDDをはじめとした設計手法について理解がかなり薄くて、結構最近の悩みだったりする。
と思ってたらslackでdanboさんに本を勧められたので買って読んでみることにする。みなさんもぜひ（？）

f:id:hazeblog:20181031112028p:plain:w600

peaks.cc

実践、BFF ~ BFFはFiNCのアプリで何を解決したのか ~

FiNCでAndroid Appを作っている @izmeal2000 san のBFFに重きを置いたお話。
BFFの説明がめちゃくちゃわかりやすいので読んでみてください。

FiNCでBFFを入れたことによる恩恵は3つあって、
- 通信量を減らすことによるパフォーマンスの向上
- 集約ロジックをBFFに集中させることで、クライアントが異なっても挙動を安定させられた
- BFF側にロジックを一部移譲することで、Appの申請をせずに挙動を変更させられるようになった
というもの。

後半はそれの具体的な説明をされていた。と同時に、集約することでのデメリットについてもお話されていた。
完全に一本に集約させると、マイクロサービスが一つ死んだら全てに影響が出てしまったり、一つレスポンスが遅いものがあるとそれに引きずられるといった問題についてはなるほど、となった。

最後にBFFの開発者は誰か、という話について。
一般的に「BFFはクライアント・フロントエンド側の責務で管理するもの」となっているらしく、今はまだアプリ開発者がBFFをガンガンいじれるようになっていないとのこと。
これについては"BFFはその組織にあっているか？"という一つの大きな問題に関わってくる部分。

これを聞いていて、「簡単に言うけどこれ実現するのくそむずくない？？」とずっと思っていて、懇親会で聞いたらなんかそうでもない感があって驚いた。
具体的な実装のイメージがついていないんだけど、レイヤをうまく分けて一部レイヤをBFFに渡すことでできるみたいな感じのことを言っていた（わかってない）。

DDD含めて、レイヤの感覚もいまいちちゃんと持ててなくてそれを実装に落とし込めないので追いつきたい。。。

「お礼ポイント投票機能をSPAに実装してMicro Frontendsを実践している話」

FiNCでフロントエンドエンジニアをやっている@nobuhikosawai san の発表。
資料見つからなかった。見つけたら追記予定。

Micro Frontendsに焦点を当てたお話。
そもそもMicro Frontendsとは？ から、具体的にどんな技術を使っていてどんな実装なのか？をソースコードレベルで説明してくださっていた。

Reactのeventハンドリングに負債があるらしく、 React Fire というプロジェクトで返済をしようとしている話とかが出てきて、知らないことずくめで面白かった。

github.com

なんか日本語で説明しているQiitaもあった

qiita.com

説明されていたソースコードはあんまりちゃんと読めなかった。つらい。（2回目）

スポンサートーク

finc.com

「健康に気を使っているレベル」の段階に合わせてサービスを考えているっていうのが印象に残っている。

健康...健康になりてえ...

飛び入りLT 「マイクロサービス開発に分散トレーシングを導入してみた」

Wantedlyのインフラエンジニアの @bgpat_ san の飛び入りLT。すごい。
Distributed Tracingをどう実現したか、という話。Open Censusという分散トレーシングの仕組み（規約？みたいなものっぽい）を使って実現しているとのこと。
社内共有ライブラリでシュッと入れられるものがあるの強い。

https://opencensus.io/opencensus.io

Rails + Datadog APMであれば、Distributed Tracingはかなり簡単に導入できる。

docs.datadoghq.com

Wantedlyでは、Application MonitoringはDatadog APMとStackdrive Traceを併用しているとのこと。 併用をするとなると確かにOpen CensusとかOpen Tracingを使う選択肢になる。なるほどなあ

話はずれるけどKubernetesに全サービス乗ってる話も聞きたい。

懇親会

食べ物が一瞬でなくなって笑った
FiNCの方々やWantedlyの方、それ以外にも様々な方と話をして有意義でした。聞いた内容は大体このエントリに散らばって書いている。はず。

iOSの設計周りについて議論コーナーがあって、さらっと聞こうとしたけどさっぱりわからなかったのでBFF周りの話を他の方としてました。にゃーん

ハッシュタグ

twitter.com

話している内容をまとめてくれている人とか、発表資料とか、懇親会で話されていた話を書いてくれている人がたくさんいました。よかった。

概念について、考察 等

腐敗防止層について

  • Microservicesを束ねて、リクエストをクライアントから受け付ける役割のもの。
  • 集約することでリソースの表現を（クライアントから見て）統一することができる、投げるレスポンスの内容の変更をしやすくする、リクエスト数を減らすことでのパフォーマンス改善が実現できる。
  • 腐敗防止層＝BFF というわけではない（そういう場合もあるけど）

BFFを誰が運用するのか？及び導入するかの論点

前述した通り、一般的にはBFFはクライアントサイドのエンジニアが開発・運用するものらしい。
FiNCの場合、iOS/Android Engineerがエンジニア全体でも割と多いように見えていて、だからこそ運用できている感がある。
どういうことかというと、組織の状況・人数構成によってBFFが正しく運用されるかどうかが決まる。

バックエンドが多くて、かつサービスが別れまくっていない場合は恐らく自分が質問に書いたようにリソース定義を完璧に作る方が実現可能性は高くて、
BFFを作るコストのほうが高くなる。

で、バックエンドが多くて、サービスが大きく別れている場合はどうするか、となると、BFFとはまた別のバックエンド側で管理するリバースプロキシみたいなものが必要になるような気がしている。
それか、BFFまでにはならないけどAPI Gatewayに集約するとか、諸々。

あとは、ネイティブアプリが存在していないケース。
提供するサービスがWebアプリケーションしかない場合だと、「クライアント間で要求する内容が変わる」みたいなことがなくなる。

BFFを複数個用意する話

冗長化ではなく、役割の違うBFFを用意していく、という話。
ツリー構造っぽい感じになる。現時点でこれやっている事例ってどれぐらいあるんだろう？

コンウェイの法則・組織構造

「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")

引用: メルヴィン・コンウェイ - Wikipedia

職能横断 / 事業部型 の組織構造かによって採用する技術も、開発する体制も、必要な人員も変わってくる。
前述している「BFFを導入するか？」の話にも被るんだけど、組織ごとによって必要となる様々なリソースは変わるので、他社事例とかは参考にすべきだけど、それをそのまんま社内に導入するのは待ったをかけたほうが良い、という話。

FiNCの場合はこういう前提だった。弊社はどうだろう？を必ず考える必要がある。

他　参考資料

公式の参加レポート。

クライアントサイドとマイクロサービスの難しい関係 — Microservices Meetup Vol.9 (FiNC App & Frontend) 登壇内容レポート #microserv

ウェルカムトークでも紹介されていた、Microservices Meetup の2回前（ vol.7 Micro Frontends）に関するエントリ。

medium.com

と、そこで行われたパネルディスカッションのレポート。

medium.com

あと何人か既にレポートを書いているっぽいので、ハッシュタグをさらって見てみると良いかもしれません。
※この記事は @haze_it_ac の色眼鏡を通して書かれています。

おわりに

microservices-meetup.connpass.com

ウェルカムトークから発表、懇親会まで全てが濃い時間でとても楽しかったです。
全ての内容を理解して吸収できなかったことがとても悔しいので、これから概念とか用語とかを理解していきたい。勿論実装も。

自分たちでも知見を作って共有できる側になりたいので、がんばっていきたいぞい

主催・運営の方々、発表者や話してくださった方々、ありがとうございました！