いびつなアプリケーション構造がビジネスの足を引っ張る　3年後、5年後につなぐDMMサロンのマイクロサービス化計画

マイクロサービスとモノリス

萩原圭市氏：「いびつ（歪）なモノリシックアプリケーションをマイクロサービスパターンで未来につなげる話」をお話しします。

簡単に自己紹介をします。エンターテインメント本部オンラインサロン事業部の萩原と申します。私は2020年5月に中途で入社して、オンラインサロン事業部に配属となって、主にバックエンドの開発に従事しています。

本日はこのアジェンダでお話しします。マイクロサービスについて、オンラインサロンが抱えている課題、オンラインサロンが目指したい姿、今やっていること、まとめです。

まずマイクロサービスについてお話しします。マイクロサービスとはアプリケーションを構築するためのアーキテクチャアプローチの1つです。サービスを疎結合に構造化して、各サービスは個別のタスクを担当しながらAPIを介して他のサービスと通信することで、変化するビジネスニーズに対応しやすくなります。右図のようにクライアントからゲートウェイサービスを通して各サービスに通信するかたちです。

次にモノリスとは何かについてお話しします。モノリスとは複数のコンポーネントが集まってできた単一の大きなサービスです。右図のようにクライアントからモノリスな1つのサービスにアクセスして、各コンポーネントで処理する構造です。

従来のモノリスでは何がいけないのかですが、最初は小さくキレイに作っていたアーキテクチャも、変化するビジネスニーズにスピード感をもって対応していくうちに、徐々に歪なアプリケーション構造になってしまう問題がよく発生します。

このように従来のモノリシックなアプローチはアプリケーションが大きく複雑になるにつれて、アプリケーションの品質やリードタイムが悪化して問題が大きくなります。

マイクロサービスにするメリットとデメリット

マイクロサービスにすることで次の恩恵を受けられます。1つ目は「リリースサイクルを早くできる」ということです。サービスを小さく分割していくので、一つひとつのサービスのリリースサイクルは早くできます。2つ目が「サービスごとに適切な技術選定ができる」ということです。サービスを分割できるので、そのサービスごとに適切な技術選定ができます。

3つ目が「障害の影響範囲を小さくできる」ということです。サービスを小さくするので、一つひとつのサービスで障害が起きても全体には影響を及ぼしません。4つ目は「コードの結合度を小さくできる」で他にもいろいろとメリットがあります。

もちろんマイクロサービスにもデメリットがあります。1つ目は「分散システムであることの難しさ」です。サービスの分割はどのようにやるか、サービス間のテストはどうするかなどです。2つ目が「組織開発の難しさ」です。ビルドが大変だったり、サービスごとにサーバーやCI/CDを用意しなければならなかったりします。このように考えることがいっぱいありますが、サービスの規模感が大きければ大きいほど費用対効果は高いと考えています。

いびつな構造がビジネスの足を引っ張る可能性

次にオンラインサロンが抱えている課題についてお話しします。サロンのシステムは数年に及ぶ改修・改善を重ね、2018年に専用コミュニティサービス、2019年にライブ配信機能をリリースしたことにより、ユーザーに数多くの価値を提供してきた一方で、このようにいびつなモノリシックアプリケーション構造に進化してきました。

サロンにはスタッフ、オーナー、会員、DMM運営というロールが存在していて、それぞれが各サービスにアクセスする結果いびつなかたちの構造となってしまっています。このいびつな構造によって開発チームのリードタイムが年々悪化したり、仕様把握も困難になったり、新規の開発にも手が出しにくくなったりしています。

ビジネスが前に進んでもこのままではシステムが足を引っ張ってしまう。このタイミングでサブドメインごとにシステムの責務を明確にするマイクロサービスパターンを導入することで3年後、5年後の未来につなげていきます。

マイクロサービスを目指すチームのモットー

次にオンラインサロンが目指したい姿についてお話をします。現時点で最終的に目指す姿は右図を考えています。各クライアントは各ゲートウェイサービスを通してgRPCで通信して、各マイクロサービスに通信します。ゲートウェイサービスはNode.jsで実装して、各マイクロサービスはGoで実装しようと考えています。

マイクロサービスに向けて目指すチームの姿勢ですが、「組織・チームでのコラボレーションの重要性」「チームメンバーが自立し、考え続ける」「最初から完璧を求めない、わからないうちはむやみに境界を分割しない」「マイクロサービスの理想を追求しすぎない」をモットーに考えています。

チームの構成を紹介します。チームの構成は右図のように開発スクラムチームで、エンジニアリングマネージャーが1名、プロダクトオーナーが1名、iOSエンジニアが3名、フロントエンドエンジニアが2名、バックエンドエンジニアが3名のチーム構成になっています。一応の職域の区切りはありますが、各々が職域を気にせずチームとしてスプリントの達成を目指しています。

3年後、5年後のために取り組んでいること

実現していくための取り組みについてお話をします。「輪読会・5パーセントルールの実施」。これはチームの技術力の底上げを目的としてやっています。輪読会では課題図書を決めてチームで読み合わせをしています。5パーセントルールは、スプリントの中で5パーセントの時間を使って各自勉強したり、興味につながるようなツールを作ったりなど自由にやっています。

次に徹底したスクラム開発です。これはチームワークを目的としています。ほかにも社内のマイクロサービス化事例や事業部開発支援の活用などがあります。これはDMMならではの膨大な資産活用を目的としています。

次に今やっていることについてお話をします。まずは直近の開発予定の機能からマイクロサービスにする予定です。現在はゲートウェイサービス、Authサービスなどを作っています。クライアントはゲートウェイを通して各サービスに通信して、既存のレガシー基盤は残しつつ、徐々にマイクロサービスにしていく構想です。

そしてマイクロサービス化に備えてアプリ側もReactNativeのアプリをモダンSwiftに置き換えています。

まとめです。これまでのサロンはユーザーファーストとスピード感を大事にしてきたことで大きく成長してきました。一方で3年先、5年先の大きな成長のためにはシステムの見直しや作り直しが必要なフェーズです。やらなきゃいけないことがいっぱいです。それだけにやりがいも大きいフェーズだと思います。

以上です。ご清聴ありがとうございました。