はじめに
オンラインサロン開発部 開発グループ アーキテクトチームの赤石です。普段はアーキテクトチームのチームリーダーとして、今回ご紹介するシステム刷新プロジェクト「neon」の開発に従事しています。
DMMオンラインサロンでは現行のシステムにおける課題を解決し、ビジネス的な課題を抽出しつつリプレース・リアーキテクトを進めるプロジェクト「neon」を中期的に取り組んでいます。
今回は私達DMMオンラインサロンが注力している「neon」で解決する課題と取り組みについてご紹介します。
neonとはなんなのか
DMMオンラインサロンは2016年より開始したサービスで、今年で8年目になります。サービス開始当初は入会・オーナー管理画面のシステムを提供し、コミュニティはFacebookグループをお使いいただくといった内容のサービスでした。その後ニーズに合わせて2018年にオンラインサロンに特化した専用コミュニティサービスをリリースし、2020年にリアルタイムのコミュニケーションが楽しめるライブ配信サービス「SALON LIVE」をリリース。その時々の事業状況に合わせながら最適なアーキテクチャを選定し、プロダクトマーケットフィットを目指して模索してきました。
結果としてサービスを急成長させることができ、オンラインサロン市場シェアNo.1(※1)のプラットフォームとなりました。
しかしその過程の中で、優先順位の兼ね合いにより見過ごされ、課題となってしまったものもありました。
課題の積み重なりが多くなり、現行システムのリファクタリングのみでは解決できないことも増えてきたため、今後更に事業を成長させていくためにビジネス基盤刷新へ投資していこうという意思決定をしました。
その結果として始まったのが「neonプロジェクト」です。
neon が解決する課題
neon には大きく分けて「疎結合化によるリードタイムの短縮」と「ビジネスをよりスケールさせるプロダクト基盤の構築」という、技術的な課題とビジネス的な課題を解決する2つの目的があります。
疎結合化によるリードタイムの短縮は、システムの歪な構造を解消することを目的としたものです。前述の通りサービスの拡大に伴い、システムを都度拡充していったことで技術的な課題が蓄積していきました。結果分散モノリスとなり、複雑な処理の流れとデータの密結合によって、変更容易性がなく障害の発生しやすいシステムがリードタイムを徐々に悪化させるようになってしまっていました。
もう一方、ビジネスをよりスケールさせるプロダクト基盤の構築については、サービスの成長につれて施策や機能追加などやりたいことが増えてきましたが、前述のリードタイム悪化の影響もあり、現状多くの施策を捌ける状態になっていません。継続的に多くの価値提供を行うにはシステム的な改善が必要です。一方でシステムの最適化を行ったとしても、プロダクト施策においてやりたいことは常にやれる量を上回ってしまうもので、リソースには限界があります。そのためより効率的に価値提供ができるように他サービスとの連携を容易にするなどしていくことで、そのような問題も解決しやすくなるかと思います。
また現在もデータ基盤による数値計測を行ってはいますが、システムの設計・仕様上取得できていないデータも存在するため、さらに定量的な数値計測に基づく施策や挑戦を繰り返していけるScientificな環境を提供することも目的としています。
neonの由来
「neon」は「The Nexus of Onlinesalon」のいくつかの文字からきており、コミュニティサービスらしく「つながり」という意味になる言葉を使い、以下を目指しています。
- システム同士のつながりを疎結合化
- ビジネス的な価値へのつながり
- オンラインサロンの中心や主要な接点
方針
プロジェクトを進めるうえでコミュニケーションや役割、責任などを明確にし、高品質なアウトプットをするためにチームとしてのいくつかの方針を決めました。
アーキテクチャ戦略
アーキテクチャスタイルとしてMicroservices Pattern(以下：マイクロサービス)+ModularMonolith Pattern(以下：モジュラモノリス)を採用し、Back-endとの通信にはAPI Gateway Patternを用いています。
マイクロサービスやモジュラモノリスの一般的なPros・Consに関しては説明を省略しますが、解決する課題でお話した「ビジネスをよりスケールさせるプロダクト基盤」を構築するために、サブドメイン/境界づけられたコンテキストごとにシステムの責務を明確にするマイクロサービスを導入することで、将来の成長にも対応できるようにしようと考えています。
しかし理想的な形にすべて分割してしまうと、現在の開発者の人数やリソース状況ではコンウェイ/逆コンウェイで言われるような「システムに合わせた組織」の実現が難しく、アーキテクチャのメリットを活かしきることができないと考えました。その結果として、多すぎて複雑なシステムに時間が取られ本末転倒になってしまうことが想定されたため、決済や会員などの主要な機能のみをサービスとして分割し、その他はモジュラモノリスとして構成することで将来の事業状況に合わせて適切に分割ができるようなアーキテクチャにしました。
またマイクロサービスのアーキテクチャスタイルに正式な定義があるわけではないので、チームメンバー間での認識、齟齬を最小限に抑えるために、私達が目指すアーキテクチャについての定義を行いました。
マーティン・ファウラーとジェームス・ルイスによるマイクロサービスの特性として9つの特性が挙げられており、全ての特性を満たす必要はないとしています。その中で私達はアーキテクチャ戦略をもとにし、以下の特性を満たすアーキテクチャを目指すものと定義づけました。
- サービスのコンポーネント化 (Componentization via Services)
- プロジェクトではなく、プロダクト (Products not Projects)
- スマートエンドポイントとダムパイプ (Smart endpoints and dumb pipes)
- 分散データ管理 (Decentralized Data Management)
- インフラストラクチャ自動化 (Infrastructure Automation)
- 障害設計 (Design for failure)
- 進化的設計 (Evolutionary Design)
チーム体制
現在neonプロジェクトでは、開発グループ内にあるアーキテクトチームが主導してプロジェクトを進行しています。
元々開発チームは1チームのみで開発を行っており、プロジェクトを始めるにあたって現在のシステムの保守や機能開発なども並行で行う必要がありました。そのためチーム内でスクアッドという形でneonプロジェクトを進める役割を分けて対応を進めていました。
しかし同じチームでスクラム開発を進めていたため、ストーリーの優先度やスプリントゴール達成のために既存システム開発に関わるストーリーや不具合対応にヘルプが必要な場合もありました。スクラムというフレームワークの中では正しい形とはいえ、これによりコンテキストスイッチが多く発生するなど、neonプロジェクトの進行は芳しくありませんでした。
この状況を改善するため、neonプロジェクトを主導して進めるアーキテクトチームを新たに立ち上げ、既存の機能開発や保守を行うプロダクト開発チーム、両チームに横断的に関わるプロダクトオーナーやデザイナーが所属するプロダクトマネジメントチームとグループ内で役割ごとにチームを分けることにしました。チームが分割されることでコミュニケーションの分断やサイロ化が生じるのではないかという懸念がありましたが、それを避けるためにLeSSの踏襲とまではいかないにしても、似た形でそれぞれのチームでスクラムイベントを実施する部分と、一緒にスクラムイベントを実施する部分とをそれぞれ設けることにしました。これにより各チームがストーリーに集中しつつお互いに関心を持つ機会を設けることでこの問題を緩和しました。
チーム原則
アーキテクチャ戦略を実現するために以下の3つの行動を重要な原則としました。
- 組織・チームでのコラボレーションの重要性
- メンバーが自立し、考え続ける
- 最初から完璧を求めない、わからないうちは無闇に境界を分割しない
組織・チームでのコラボレーションの重要性
チーム全体で情報や課題を共有し、協働してプロジェクトを進めることが大切です。これにより、各個人の専門性を活かし、ペアプロやペア作業などを介してナレッジを伝搬していくことで複雑な課題を効率的に解決へと導くことが可能になると考えています。
メンバーが自立し、考え続ける
各メンバーが自立心を持ち、常に自分自身で考え続けることで自己組織化を目指しています。結果として自らが適切な方針を定め、問題解決を行い、必要な改善を実施する能力を培うことができ、柔軟に課題の対応ができるようになります。
最初から完璧を求めない、わからないうちは無闇に境界を分割しない
マイクロサービスやモジュラモノリスの理想を追求することも重要ですが、すべてを初めから細分化し過ぎると、その管理が複雑化し、全体の効率を損ねる可能性があります。ある程度の大まかな範囲で先に進め、理解が進むにつれて適切に境界を決めていくことが効率的だと考えています。
現状と今後について
neonプロジェクトでは、いくつかのフェーズに分けて対応を進めています。
その初期段階では、アカウントの移行と基盤構築に重点を置いて作業を行ってきました。
アカウント移行
最初期にリリースされた入会・オーナー管理画面と、それに続いてリリースされた専用コミュニティサービスでは、それぞれが独自のデータベースを保有し、その中でアカウント情報を管理していました。そのため一方でアカウント情報が生成されると、二つのデータベース間でデータの一貫性を保つための同期処理が必要となっていました。また、データによってはDMMアカウントに紐づいているアカウントと紐づいていない独自の認証情報をもったアカウントが存在するなどしてオペレーションのフローが複雑化していました。アカウント移行のフェーズではこれらの問題を解消するため、まず分散管理されていたアカウント情報を一つのデータベースに集約し、よりシンプルで一貫性のあるID基盤の構築を実現することとしました。
具体的には、CDC (Change Data Capture) を利用して既存のデータベースの変更を検知し、新しいデータベースにデータを移行する処理を行っています。詳細については、今後別の記事にしてご紹介したいと思います。
基盤構築
基盤構築のフェーズでは、neonの基盤となるマイクロサービスとモジュラモノリスの構築、そして分散システム間の認証認可の仕組みの実装を行いました。認可の仕組みとしては、Role-Based Access Control (ReBAC) をベースとしたシステムを導入しています。これにより、より柔軟性のあるアクセス制御を可能にしています。基盤構築についても別途記事にしてご紹介したいと思います。
今後について
今後は構築した基盤をもとにストラングラーフィグパターンで段階的に既存の機能を移行してneon基盤上に構築していくことを進めていきます。
段階的に移行していくことで、問題があった場合のロールバックや性能のモニタリングなどを容易に可能にしつつ、素早く価値を提供し続けていけたらと思っています。
おわりに
今回はneonプロジェクトについてご紹介させていただきました。
一定の規模感のあるサービスのリプレースは長く険しい戦いなのはもちろん、技術だけでなくコミュニケーションや事業に寄り添った開発やアーキテクチャが重要になりますが、その分やりがいの感じられる仕事かと思います。
DMMオンラインサロンでは開発グループのメンバーを募集しています。記事を読んでneonのことが気になった方には、ぜひ今回の記事では語りきれなかったことなどをご紹介したいと思っているので、気軽に話を聞きに来てください。
（※1）2021年2月現在の国内プラットフォームにおいて。ICT総研／DMMオンラインサロン調べ。
