2018/10/30 に開催された Microservices Meetup vol.9 (FiNC App & Frontend) のイベントレポートです。

●イベントのテーマ
　FiNCはヘルスケアのプラットフォームとして、様々なサービスを提供しています。そのビジネスを加速していくため、早い段階からマイクロサービスアーキテクチャを採用してきており、サービスの数は約30個になっています。
　その中心となるFiNCアプリは、iOS: Swift, Android: Kotlinで書かれており、機能もステークホルダーも多い非常に大規模なアプリです。また、法人向けサービスでは多くのビジネス機能を、主にReactを利用したWebアプリケーションとして提供しています。いずれも、マイクロサービスのエッセンスを開発に活かしながらも、ユーザーインターフェースを提供するために マイクロサービスを統合するレイヤー になるという難しさがあり、それぞれ様々な工夫をしながら開発しています。
　今回はFiNC Technologies社所属のエンジニアより、 クライアントサイド視点から見たマイクロサービス について、多くの実践例を紹介しながら論考を深めていきます。

■前回の開催レポート

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

@qsona

●マイクロサービスの良さ
・技術特異性
・回復性
・デプロイの独立
・小さく自立・独立した組織
→ サービスの疎結合からくるもの

●密結合になるとマイクロサービスの良さは消える
・事業計画w
・DB結合
　：
　→意識する必要がある

●結合の例1：マイクロサービスと営業
・「営業が一緒だったら動きやすい」は、机上の空論！
　マイクロサービスごとに営業とかありえない
→ まとめないといけないところは、まとめる

●結合の例2：マイクロサービスと横断ビジネス
・複数のマイクロサービスを横断的に利用するビジネスモデル
　特茶スマートアプリ
　　・実はFiNCアプリ
　　・Onboardingをカスタマイズできるようになっている
　→ビジネス間のコミュニケーションが複雑
　　全体を通すと抜けがあったり
・全マイクロサービスが疎結合が理想

●フロントエンドでの結合
フロントエンドエンジニアの役割は、統合された体験の提供

●FiNCが取り組んできたこと
APIのリソース思考、APIガイドライン
・BFF
・Micro Frontends

「ユーザの理想」と「開発者・組織の理想」を現実に落とし込む

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

@neonankiti

●マイクロサービスとクライアント
・クライアント側からみると実装コストは変わらない
・1画面で複数サービスを呼ぶから考慮が必要

●マイクロサービスの運用の課題と解決
・サービス間の差異
・サービス間でリソースの表現が違う
　→実質は同じモデルであるべき
　　DDDの共有カーネル
・外部に公開するAPIのガイドライン作成と運用で揃えた
　※DBを揃えたわけではない

●サービス間の差異の吸収
・サーバが同一リソースに違うjsonを返すことを想定していない
・境界づけられたコンテキストの存在を認識
→腐敗防止層を設置

・アプリはハブ
　　サーバ/クライアントはチームも分断されている
・クライアントドメイン内での実装者ごとの違い
　　→認識揃えましょ
　　　同一組織内のコンセンサスを形成

●iOS/Android間のドメインモデルのずれ
・ドメインモデルが違うと対応できることもずれる
・会議は両方のチームから参加しないといけない
　→お互いを知ろう！
　　クライアント全体定例
　　　リードが集まる
　　　課題を共有
　　即効性はないが、相手を気にするようになった
　　　→意思決定のスピードは落ちた
　　　→べき論が多いのでビジネス価値への考慮が減った
　　サービス集中型組織へ
　　　エンジニア、ディレクタ、デザイナーを含める

●マイクロアプリ化
・アプリの課題
　　webとアプリのシームレスな経験ができない
　　アプリサイズが大きい
・マイクロアプリ
　　インストールなし：Instant App
　　サイズ小さい
・マイクロアプリ≒マルチモジュール
　　近い未来に来る！ので備えましょう

マイクロサービスはクライアントの潜在的な問題を検知するきっかけ

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

@takasek

●テーマ
クライアント・サーバ間のコンテキスト境界をどこに置くか？

●境界はチーム編成の輪郭に従う
・同じチームでも、コミュニケーションで途切れる
・同じチームでも、バージョン間で崩れる

クライアントが必要とするのは既に存在するドメインオブジェクトへの参照
→集約ルートに対してのみリポジトリを提供

●FiNCアプリの構成
　View + ViewModel + Usecase + Domain + Repository
　BFF + MicroService

●コンテキスト境界をどこに置くか？
・BFFに置く
　分散コンピューティングの落とし穴 と戦う
　→BFFに全てを寄せるには細かすぎる

・Repositoryに置く
　太ってビジネスロジック化してしまう

・Usecaseに置く
　サーバのコンテキストをクライアントでどの様に扱うか
　クライアント開発では、自然にここに落ち着くことが多そう

・ViewModelに置く
　Viewとのやり取り、インタラクションの状態管理など役割が多すぎる

・Viewに置く
　これがMicroFrontend
　アプリの場合は独立してビルドできないので、単位にできない

クライアントのビジネスロジックはどこか？次第

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

@izmeal2000

●BFFの役割
・抱えていた課題
　・通信パフォーマンス
　　　モバイル回線への負荷軽減
　・集約ロジックの共有
　　　Android/iOSの挙動を集約
　・些細な挙動変更にも申請が必要
　　　集約していることでリリース申請なしで住む

●導入実践
・通信パフォーマンス
　ポイントを貯める、使うの経路が複数ある
　　→1画面で15リクエスト -> 6リクエストへ
　1本に集約したら
　　・遅いAPIに引きづられる
　　・個別リトライができない
　→ユーザが扱いやすい単位で画面を分割
　→画面の分割とAPIを合わせた

・集約ロジックの共有
　ポイントの付与判定など、かなり複雑
　　→BFFに集約
　Backendのデータ構造を、Frontend向けに変換している
　　仕様変更のリードタイムを短縮させるならBFF
　　ユーザインタラクションのリードタイムを短縮させるならクライアント

・些細な挙動変更にも申請が必要
　BFFで済む変更ならアプリの申請なしで済む

●今後の展望
通常BFFはUIチームによって開発、運用されるものである
by SamNewman

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

@nobuhikosawai

●Micro Frontendsとは
・フロントエンドまで提供するマイクロサービス
　　フロントエンドモノリス
　　UIがないとユーザに価値が提供できない
　　　→フロントエンドがボトルネックになってしまう
・例
　　micro-frontends.org
　　IKEAでもやっている
・技術スタック
　　Web Components

●経緯
・2年前のreact
・ピア・ボーナス機能やりたい
・railsでバックエンドが立ち上がる
　　新旧のreactでの違い
→web componentで提供

●課題
・ビルドの問題
　　SPAはビルドが必要
　　　ブラウザにキャッシュされるから毎回違う名前にしないとね
　　→manifest.jsonでchunkhashを紐づけできる
　　→いつ取得する？
　　　render後
　　　　遅すぎる。。。
　　　render前
　　　　index.htmlだけserver side rendering
・ユーザ体験
　　統合レイヤの方法に合わせる = localStorage
　　　各サービスでアクセスしたら共有カーネルだね
　　　→ windowにgetter関数を提供
・画面遷移
　　画面遷移もサービス持ちでは？
　　→ a tagなのにリンクらしくない挙動
　　→ routingは共有で良しとした
・連動するコンポーネント
　　CustomEvents
　　サービスドメインごと
・その他
　・polyfill入れた
　・reactのeventがshadowDOMを使う

■QAで挙がった話

・BFFに更新系の処理は持たせない方針
・Front/Backで扱うドメインは関心が別

■LT：マイクロサービス開発に分散トレーシングを導入してみた

Atsushi Tanaka

■感想

DDDやCDC、コンウェイの法則、ハスラー・ハッカー・デザイナー理論など、一般的な原則の話とつなげながら、ノウハウを聞かせていただけたので、とても理解しやすかったです。

「MicroFrontendsを導入するときのノウハウを聞かせてもらえれば」と思って参加しましたが、ネイティブアプリ、BFFのノウハウも併せて聞かせていただけて「なるほど！」と思えるポイントを沢山いただけるイベントでした。

「今後は活動をオープンにしていく」というお話だったので、どこかでノウハウを共有できたら素敵ですね。今後の活動も楽しみです！ありがとうございました。