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

Transcript

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

   View Slide

2. 自己紹介
   2020年10月入社
   DMMプラットフォーム事業本部エンジニア
   相席食堂にハマっている
   

   View Slide

3. テーマ: DMMアカウントサービスのフロントエンド改善
   半年ほど前からフロントエンドに対する技術的な改善プロジェクトがスタート
   どのような課題・理想があり、それに対してどう技術的なアプローチをしているのかを
   話します
   

   View Slide

4. アジェンダ
   アカウントサービスの理想
   アカウントサービスの課題
   既存の機能の担保する(守り)
   高速&安心なUI開発に変えてゆく(攻め)
   

   View Slide

5. プラットフォーム事業本部とは
   DMMの中でも横断的な機能を提供する部署
   トップページ、認証、決済、ヘッダー、フッター、etc
   アカウントサービスは認証認可を担当するアプリケーション
   いわゆるログイン・登録機能
   

   View Slide

6. プラットフォーム事業本部とは
   =>チームに閉じた効率化はもちろんだが、各事業部が簡単に機能を使
   えるようにすることで、組織全体の効率化につながるのが特徴
   

   View Slide

7. どういう状態が理想か？
   アカウントサービスのやりたいことはたくさん
   様々なアプリケーション: DMMには50以上の事業がある。DMMログインを使いたい
   が、「デザインはサービスに合うように変えて欲しい」のような要望がある
   様々なプラットフォーム: SPAで使いたい、PWAで使いたい、Electronで使いたい、TV
   で使いたい、PS5で使いたい、アプリで使いたい、独自ログインを提供したい、、
   様々なユースケース: SNSログインしたい、他社からDMMアカウントでOIDCしたい、多
   要素認証を実装してほしい
   =>これらに素早く対応できる、拡張性・ポータビリティの高いソフト
   ウェアにしておきたい
   

   View Slide

8. どういう状態が理想か？
   ソフトウェアとして
   変更がしやすい
   テスタビリティが高い
   ビジネスとして
   事業部に簡単に提供できる
   施策の素早い検証と改善が行える
   

   View Slide

9. どういう状態が理想か？
   =>変更容易性が高く、素早く安心してアプリケーションをデプロイで
   きる状態
   

   View Slide

10. 既存の技術スタック
    Node.js＋Expressのサーバーサイドアプリケーション
    もともと巨大なPHPモノリスから
    切り出されて再実装された
    基本はテンプレートエンジン。要所でReactを使用(webpack)
    Node.jsバックエンドをBFFとし、認証認可・会員・社内基盤等のサービス、APIとやり
    取り(Javaが多い)
    上記の事情から、Node.jsのバックエンドに多くのビジネスロジック
    ECS上で動く。要所でLambdaやRedisを使用
    

    View Slide

11. 既存の技術スタック
    =>Node.js＋Express
    =>フロントエンドの持ち物 = いわゆるフロントエンド＋BFF
    

    View Slide

12. 既存アプリケーションの技術的な課題を洗い出し
    例
    依存モジュールの更新ができていない(メジャーバージョンだけで50以上)
    使用しているテンプレートエンジン( ect
    )がメンテされていない
    CSSがスコープ化されておらず、また、影響範囲の大きな書き方がされている
    多くのユニットテストがリクエスト単位での大きなテストで書かれており、アーキテク
    チャとあわせてテスト設計されていない
    UIとロジックが密結合していて開発しづらく、テストもされていない
    E2Eテストが壊れやすくメンテもされていない
    ブラウザのエラーを拾えていない
    (歴史的経緯により)多くの独自 node_modules
    全体的に古い書き方のコード( cjs
    , Class Component
    , jQuery
    etc)
    

    View Slide

13. 既存アプリケーションの技術的な課題を洗い出し
    =>それぞれの課題同士に依存関係がありそう
    

    View Slide

14. 既存アプリケーションの技術的な課題の優先度付け
    

    View Slide

15. 既存アプリケーションの技術的な課題の優先度付け
    課題を洗い出し、優先度をつけて取り組むことに。
    例えば、
    [優先] 以降の開発効率やアーキテクチャに大きく影響するもの
    [後回し] Lintでカバーできない細かいコーディングスタイルなど(新た
    な仕組みに乗った上で修正したい)
    

    View Slide

16. 既存の機能の担保(守り)しながら
    高速&安心なUI開発(攻め)に変えてゆく
    ※
    時間の都合上さくさくと
    

    View Slide

17. 既存の機能の担保(守り)
    大きめの改善施策を進めていく上でプロダクトの機能を守る施策
    E2Eテスト刷新
    Jestの導入
    Datadogによる監視
    Renovateによるパッケージ更新自動化
    

    View Slide

18. E2Eテスト刷新
    課題; E2Eテストが壊れやすくメンテもされていなかった
    

    View Slide

19. E2Eテスト刷新
    =>メンテされていないE2Eを保守しやすく刷新する with QA部
    

    View Slide

20. Jestの導入
    課題; 多くのユニットテストがリクエスト単位での大きなテストで書か
    れている
    課題; アーキテクチャとあわせてテスト設計されていない
    

    View Slide

21. Jestの導入
    =>プログラムの適切な分解と、正しい責務のテストを効率的にに行う
    ための基盤として導入
    

    View Slide

22. Datadogによる監視
    課題; ブラウザのエラーを拾えていない
    

    View Slide

23. Datadogによる監視
    =>フロントエンドで起きた予期しないエラーを辿れるように
    

    View Slide

24. Renovateによるパッケージ更新自動化
    課題; 依存モジュールの更新ができていない
    (メジャーバージョンだけで50以上)
    

    View Slide

25. Renovateによるパッケージ更新自動化
    =>継続的にパッケージの更新を可能に
    =>更新されていないパッケージを可視化
    

    View Slide

26. 既存の機能の担保(守り)
    =>最低限リファクタリングを進められる状態を整備
    

    View Slide

27. 高速&安心なUI開発(攻め)
    

    View Slide

28. 高速&安心なUI開発(攻め)
    より高速かつ安心してプロダクト開発を行うための施策
    React, Next.js
    Emotion
    Storybook
    

    View Slide

29. 課題
    1. 画面とロジックが密結合していて開発効率が悪い
    2. UIの変更や崩れが検知できていない
    3. 使っているテンプレートエンジン( ect
    )がメンテされていない
    

    View Slide

30. Next.js, Emotion, Storybook
    

    View Slide

31. Why Next.js?
    

    View Slide

32. Why Next.js?
    =>我々だけのWhyがあるはず
    

    View Slide

33. アカウントサービスの前提
    前提#1
    アプリケーションは複雑
    ビッグバンリリースを避け、段階的にリリースしたい
    前提#2
    フロントエンドが既存のExpressサーバーと密結合している箇所がある
    既存のバックエンドのロジックをそのまま使いたい
    

    View Slide

34. アカウントサービスの前提
    =>既存のExpressにのせながらアーキテクチャを変更できるか？が重
    要
    

    View Slide

35. How Next.js?
    どうやる？
    Next.jsにも Subpath
    や Rewrites
    などルーティングベースで新旧のアプリケーション
    を切り替える機能がある
    =>アプリケーションは複雑で、すべてを書き換えるみちのりは長い
    =>段階的にリリースできて、大きな初期コストがかからない方法がいい
    =>パスの切り替えはExpress側でもできるし、Next.jsの Custom Server
    を使えば
    IncrementalにNext.js化していくことが可能
    

    View Slide

36. How Next.js?
    =>Expressを Custom Server
    としてNext.jsを動かすことに
    

    View Slide

37. (アカウントサービスとしての) Why Next.js?
    パワフルな機能を柔軟なアーキテクチャで実装できる
    既存のExpressアプリケーションをホストしつつReact化できる
    トランスパイラを抽象化でき、既存のビルドシステムの複雑さを吸収できる
    SSGが効果を発揮できそうなアプリケーション。将来的にNode.js環境をAPI化し、
    JAMStack化しやすい
    コンポーネントとしてUI設計することで、将来的にポータブルにできる
    (Why React)
    様々なプラットフォーム・アプリケーションに対して
    必要なUIを必要な分だけ
    適切なAPIで提供したい
    

    View Slide

38. 実際のリファクタ&開発フロー
    触ったらリファクタするという強い意志で、ページごとNext.jsに乗せる
    既存のReactコードがあった場合は適宜マイグレートしてSSR
    ビューに対するバックエンドロジックがあれば getServerSideProps
    へ & TS化
    テストはUIからバックエンドまで、適切な粒度と責務でリバランス
    

    View Slide

39. 高速&安心なUI開発(攻め)
    1.フロントエンドだけで完結する高速な開発が可能に
    2.再利用可能なUIコンポーネントを可視化
    3.段階的にReact,Next.js化
    4.段階的にEmotionでスタイルをスコープ化
    

    View Slide

40. 新たな課題
    共存することによるコスト
    チームで保守できる仕組み
    カナリアリリース、適切なモニタリング、負荷試験
    デザインの一貫性(プラットフォーム全体でも)
    =>改善は継続的に続ける必要がある
    

    View Slide

41. View Slide

42. どういう状態が理想か？
    =>事業部が簡単に導入できるような施策も進め、アジリティの高い組
    織へ
    

    View Slide

43. おわり
    マイクロサービス化するバックエンド、レガシー化・モノリス化するフ
    ロントエンド
    =>そうならないために、適切な課題解決と技術選定、どんな形でも提
    供できるポータブルなフロントエンドへ
    

    View Slide