Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Next.js, Emotion, Storybook

Slide 31

Slide 31 text

Why Next.js?

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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