DMMアカウントサービスのフロントエンド改善

Transcript

1. DMMアカウントサービスのフロントエンド改善
2. 自己紹介 2020年10月入社 DMMプラットフォーム事業本部エンジニア 相席食堂にハマっている
3. テーマ: DMMアカウントサービスのフロントエンド改善 半年ほど前からフロントエンドに対する技術的な改善プロジェクトがスタート どのような課題・理想があり、それに対してどう技術的なアプローチをしているのかを 話します
4. アジェンダ アカウントサービスの理想 アカウントサービスの課題 既存の機能の担保する(守り) 高速&安心なUI開発に変えてゆく(攻め)
5. プラットフォーム事業本部とは DMMの中でも横断的な機能を提供する部署 トップページ、認証、決済、ヘッダー、フッター、etc アカウントサービスは認証認可を担当するアプリケーション いわゆるログイン・登録機能
6. プラットフォーム事業本部とは =>チームに閉じた効率化はもちろんだが、各事業部が簡単に機能を使 えるようにすることで、組織全体の効率化につながるのが特徴
7. どういう状態が理想か？ アカウントサービスのやりたいことはたくさん 様々なアプリケーション: DMMには50以上の事業がある。DMMログインを使いたい が、「デザインはサービスに合うように変えて欲しい」のような要望がある 様々なプラットフォーム: SPAで使いたい、PWAで使いたい、Electronで使いたい、TV で使いたい、PS5で使いたい、アプリで使いたい、独自ログインを提供したい、、 様々なユースケース: SNSログインしたい、他社からDMMアカウントでOIDCしたい、多 要素認証を実装してほしい =>これらに素早く対応できる、拡張性・ポータビリティの高いソフト ウェアにしておきたい
8. どういう状態が理想か？ ソフトウェアとして 変更がしやすい テスタビリティが高い ビジネスとして 事業部に簡単に提供できる 施策の素早い検証と改善が行える
9. どういう状態が理想か？ =>変更容易性が高く、素早く安心してアプリケーションをデプロイで きる状態
10. 既存の技術スタック Node.js＋Expressのサーバーサイドアプリケーション もともと巨大なPHPモノリスから 切り出されて再実装された 基本はテンプレートエンジン。要所でReactを使用(webpack) Node.jsバックエンドをBFFとし、認証認可・会員・社内基盤等のサービス、APIとやり 取り(Javaが多い) 上記の事情から、Node.jsのバックエンドに多くのビジネスロジック ECS上で動く。要所でLambdaやRedisを使用
11. 既存の技術スタック =>Node.js＋Express =>フロントエンドの持ち物 = いわゆるフロントエンド＋BFF
12. 既存アプリケーションの技術的な課題を洗い出し 例 依存モジュールの更新ができていない(メジャーバージョンだけで50以上) 使用しているテンプレートエンジン( ect )がメンテされていない CSSがスコープ化されておらず、また、影響範囲の大きな書き方がされている 多くのユニットテストがリクエスト単位での大きなテストで書かれており、アーキテク チャとあわせてテスト設計されていない UIとロジックが密結合していて開発しづらく、テストもされていない E2Eテストが壊れやすくメンテもされていない ブラウザのエラーを拾えていない (歴史的経緯により)多くの独自 node_modules 全体的に古い書き方のコード( cjs , Class Component , jQuery etc)
13. 既存アプリケーションの技術的な課題を洗い出し =>それぞれの課題同士に依存関係がありそう
14. 既存アプリケーションの技術的な課題の優先度付け
15. 既存アプリケーションの技術的な課題の優先度付け 課題を洗い出し、優先度をつけて取り組むことに。 例えば、 [優先] 以降の開発効率やアーキテクチャに大きく影響するもの [後回し] Lintでカバーできない細かいコーディングスタイルなど(新た な仕組みに乗った上で修正したい)
16. 既存の機能の担保(守り)しながら 高速&安心なUI開発(攻め)に変えてゆく ※ 時間の都合上さくさくと
17. 既存の機能の担保(守り) 大きめの改善施策を進めていく上でプロダクトの機能を守る施策 E2Eテスト刷新 Jestの導入 Datadogによる監視 Renovateによるパッケージ更新自動化
18. E2Eテスト刷新 課題; E2Eテストが壊れやすくメンテもされていなかった
19. E2Eテスト刷新 =>メンテされていないE2Eを保守しやすく刷新する with QA部
20. Jestの導入 課題; 多くのユニットテストがリクエスト単位での大きなテストで書か れている 課題; アーキテクチャとあわせてテスト設計されていない
21. Jestの導入 =>プログラムの適切な分解と、正しい責務のテストを効率的にに行う ための基盤として導入
22. Datadogによる監視 課題; ブラウザのエラーを拾えていない
23. Datadogによる監視 =>フロントエンドで起きた予期しないエラーを辿れるように
24. Renovateによるパッケージ更新自動化 課題; 依存モジュールの更新ができていない (メジャーバージョンだけで50以上)
25. Renovateによるパッケージ更新自動化 =>継続的にパッケージの更新を可能に =>更新されていないパッケージを可視化
26. 既存の機能の担保(守り) =>最低限リファクタリングを進められる状態を整備
27. 高速&安心なUI開発(攻め)
28. 高速&安心なUI開発(攻め) より高速かつ安心してプロダクト開発を行うための施策 React, Next.js Emotion Storybook
29. 課題 1. 画面とロジックが密結合していて開発効率が悪い 2. UIの変更や崩れが検知できていない 3. 使っているテンプレートエンジン( ect )がメンテされていない
30. Next.js, Emotion, Storybook
31. Why Next.js?
32. Why Next.js? =>我々だけのWhyがあるはず
33. アカウントサービスの前提 前提#1 アプリケーションは複雑 ビッグバンリリースを避け、段階的にリリースしたい 前提#2 フロントエンドが既存のExpressサーバーと密結合している箇所がある 既存のバックエンドのロジックをそのまま使いたい
34. アカウントサービスの前提 =>既存のExpressにのせながらアーキテクチャを変更できるか？が重 要
35. How Next.js? どうやる？ Next.jsにも Subpath や Rewrites などルーティングベースで新旧のアプリケーション を切り替える機能がある =>アプリケーションは複雑で、すべてを書き換えるみちのりは長い =>段階的にリリースできて、大きな初期コストがかからない方法がいい =>パスの切り替えはExpress側でもできるし、Next.jsの Custom Server を使えば IncrementalにNext.js化していくことが可能
36. How Next.js? =>Expressを Custom Server としてNext.jsを動かすことに
37. (アカウントサービスとしての) Why Next.js? パワフルな機能を柔軟なアーキテクチャで実装できる 既存のExpressアプリケーションをホストしつつReact化できる トランスパイラを抽象化でき、既存のビルドシステムの複雑さを吸収できる SSGが効果を発揮できそうなアプリケーション。将来的にNode.js環境をAPI化し、 JAMStack化しやすい コンポーネントとしてUI設計することで、将来的にポータブルにできる (Why React) 様々なプラットフォーム・アプリケーションに対して 必要なUIを必要な分だけ 適切なAPIで提供したい
38. 実際のリファクタ&開発フロー 触ったらリファクタするという強い意志で、ページごとNext.jsに乗せる 既存のReactコードがあった場合は適宜マイグレートしてSSR ビューに対するバックエンドロジックがあれば getServerSideProps へ & TS化 テストはUIからバックエンドまで、適切な粒度と責務でリバランス
39. 高速&安心なUI開発(攻め) 1.フロントエンドだけで完結する高速な開発が可能に 2.再利用可能なUIコンポーネントを可視化 3.段階的にReact,Next.js化 4.段階的にEmotionでスタイルをスコープ化
40. 新たな課題 共存することによるコスト チームで保守できる仕組み カナリアリリース、適切なモニタリング、負荷試験 デザインの一貫性(プラットフォーム全体でも) =>改善は継続的に続ける必要がある
42. どういう状態が理想か？ =>事業部が簡単に導入できるような施策も進め、アジリティの高い組 織へ
43. おわり マイクロサービス化するバックエンド、レガシー化・モノリス化するフ ロントエンド =>そうならないために、適切な課題解決と技術選定、どんな形でも提 供できるポータブルなフロントエンドへ