デブサミ2020【13-E-5】Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜 #devsumiE #devsumi
- Web3層アーキテクチャ - クライアント - Webサーバ - Appサーバ - マイクロサービスWebアーキテクチャ - クライアント - reverse proxy - BFF - 同期系サービス(n個) - 非同期系サービス(n個) #devsumi #devsumiE
2020-02-13 14:29:11「マイクロサービスwebアーキテクチャ」 Viewはクライアント側でやる(SPA) BFFが生のマイクロサービスを束ねてJSONを返す。 #devsumiE
2020-02-13 14:29:42マイクロサービスWebアーキテクチャ (今は大体こんな感じ@中井さん) View:JSでクライアントにやらせる BFF(Backend for Frontend):外部公開APIとサービス実装を分離 サービス:同期系と非同期系を分離 #devsumi #devsumiE
2020-02-13 14:30:12一般的なマイクロサービスアーキテクチャ ・クライアントとViewはjsonだけのやりとり ・クライアントロジックの複雑化やセキュリティの難題化が起こる ・BFFがアグリゲートして必要な機能をAPIとして公開 #devsumiE
2020-02-13 14:30:21マイクロサービスWebアーキテクチャ まぁ名前的にはしっくり来るというか、そうなるよねという名前。むしろBFFってもっといい名前ないのかなw #devsumiE
2020-02-13 14:30:26「マイクロサービスwebアーキテクチャ」は結局web三層と本質的には変わらない #devsumiE
2020-02-13 14:31:02なるほど APIから後ろが同期・非同期Jobでデータパイプラインに処理を任せるみたいなことをやってるわけね #devsumiE
2020-02-13 14:33:59Google的マイクロサービス基盤要素 先と、違うところ ・他のサービスと共有しているLB(共有型) ・マイクロサービスのためのミドルが豊富に用意されている #devsumi #devsumiE
2020-02-13 14:34:24googleもマイクロサービスwebアーキテクチャと変わらない 違う点としては、 1) LBでいうとくそでかいLBが一個あるだけだったり、共有型である。 2) ミドルウェアやツールがふんだんにある。 バッチ処理用のデータパイプラインや、ログ管理サービスなど。 #devsumiE
2020-02-13 14:34:46マイクロサービスのためのミドルウェアが多いので、「~~を考えないといけない」「~~を考慮しないと」という考えが省けるため作業に集中できる #devsumi #devsumiE
2020-02-13 14:35:19企業がモノリシックからマイクロサービスへ移行するための課題 ・モノリシックな現状に悲観 ・PoCレベルで終わり やってほしいこと ・スクラッチ開発ではなく既存アプリのマイクロサービス化 #devsumiE
2020-02-13 14:37:48マイクロサービスで開発する利点・目的 スケーラビリティの実現、サービス単位の開発 ⇒ 新機能をすばやく ・想定外をへらす ・チーム間依存関係を減らす ・スケーラブルなインフラを活用 SREはサービス単位の粒度でアプリアーキテクチャーが把握できるので問題時の切分けが迅速 #devsumi #devsumiE
2020-02-13 14:40:55Google SREはマイクロサービスの用意と連携を頭にいれ、特定サービスに特化したメンバーに必要に応じて割り振る 内部コンポーネントの粒度は上手く切り分けることでトラブルシューティングが早まる #devsumiE
2020-02-13 14:43:39想定外:多数のサービスにまたがる依存関係を気にせずに改修に集中できる 依存関係:チームの独立性をもたせて機能ごとのパラレル開発・リリースを可能に スケーラブル:実装プラットフォームがオートスケール機能を提供 #devsumi #devsumiE
2020-02-13 14:43:41