歪なモノリシックアプリケーションをマイクロサービスパターンで未来につなげる話

歪なモノリシックアプリケーションをマイクロサービスパターンで未来につなげる話エンターテイメント本部オンラインサロン事業部萩原圭市

- マイクロサービスについて - オンラインサロンが抱えている課題 - オンラインサロンが目指したい姿 - 今やっていること - まとめ

マイクロサービスとは？

アプリケーションを構築するためのアーキテクチャアプローチの一つ。サービスを疎結合に構造化・各サービスは個別のタスクを担当し APIを介して他のサービスと通信することで、変化するビジネスニーズに対応しやすくなる。

モノリシック（モノリス）とは？

複数のコンポーネントが集まってできた単一の大きなサービス

モノリスではいけないのか？

最初は小さく綺麗に作っていたアーキテクチャも変化するビジネスニーズにスピード感を持って対応していくうちに・・・

いつの間にか歪なアプリケーション構造に・・・

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

マイクロサービスにすることで次のような恩恵を受けられる

- リリースサイクルを早くできる - サービス毎に適切な技術選定ができる - 障害の影響範囲を小さくできる - コードの結合度を小さくできる etc...

もちろんマイクロサービスにもデメリットはある

- 分散システムであることの難しさ - サービス分割はどのようにやる？ - サービス間のテストはどうする？ - 組織開発の難しさ - ビルドが大変
- サービス毎にサーバーや CICDを用意しなければならない etc...

考えることはいっぱいでもサービスの規模感が大きければ大きいほど費用対効果は高い

サロンのシステムは数年に及ぶ改修・改善を重ね、さらに 2018年から専用コミュニティサービス、2019年にはライブ配信機能をリリースしたことによりユーザーに数多くの価値提供を実現してきた一方で・・・

歪なモノリシックアプリケーション構造に進化してきた

この歪な構造によって - 開発チームのリードタイムが年々悪化し - 仕様把握も困難になりつつあり - 新規の開発も手が出しにくくなる

ビジネスが前に進んでもこのままではシステムが足を引っ張ってしまう・・・

よって、このタイミングでサブドメインごとにシステムの責務を明確にするマイクロサービスパターンを導入することで3 年後・5年後の未来につなげる

現時点での最終的に目指す姿

マイクロサービスに向けて目指すチームの姿勢

- 組織・チームでのコラボレーションの重要性 - チームメンバーが自立し、考え続ける - 最初からカンペキを求めない、わからないうちはむやみに境界を分割しない(マイクロサービスの理想を追求しすぎない)

チームの構成 - エンジニアリングマネージャー 1名 - プロダクトオーナー 1名 - iOSエンジニア 3名
- フロントエンドエンジニア 2名 - バックエンドエンジニア 3名一応の職域の区切りはあるが各々は職域を気にせずチームとしてスプリントの達成を目指しています

実現していくための取り組み

- 輪読会・5%ルールの実施（チームの技術力の底上げ） - 徹底したスクラム開発（チームワーク） - 社内のマイクロサービス化事例や事業部開発支援の活用（DMMならではの膨大な資産活用）

まずは直近の開発予定の機能からマイクロサービスにする（現在Gatewayサービス、Authサービスなどを作っています）

そしてマイクロサービス化に備えてアプリ側も ReactNativeのアプリをモダンSwiftに置き換えてます（このあとの発表で話します）

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

以上

歪なモノリシックアプリケーションをマイクロサービスパターンで未来につなげる話

歪なモノリシックアプリケーションをマイクロサービスパターンで未来につなげる話

hagyyyy

Other Decks in Technology

Featured

Transcript