モノリシックサービスをマイクロサービス化している話

はじめのあいさつ

こんにちは！アプリケーション技術推進チームの宮下です。
私のチームでは、BEENOSの主力サービスであるBuyeeを数年前からリプレイスをしております。

※Buyeeとは、海外にお住まいのお客様が日本やアメリカのECサイトから商品を購入するサポートをし、世界中にお届けするサービスです。サービス自体は10年以上前から動き続けています。
https://buyee.jp/

リプレイスはまだ完成しておらず、現在も行っている途中となりますが、今回はリプレイスについてお話しようと思います！

リプレイスに至った背景

Buyeeは10年以上続くサービスで、その基盤を担うシステムは継続的に機能追加や改修を行っています。しかし、システムの運命の常ではありますが、経年による変更容易性の低下が無視できない状態だったためです。

リプレイスの方法について

リプレイスの元となる、既存サービスは継続して稼働させたままリプレイスを行います。
まず、一部の機能（機能A）を既存サービスから切り出してマイクロサービス化させます。そして、既存サービスで機能Aを停止したと同時タイミングで、マイクロサービス側で機能Aが動作するようにします。これを機能B、機能Cと続けていく流れです。

こうすることで、リプレイス元の既存アプリケーションと、リプレイス後のマイクロサービスが共存する状態でサービスを継続させています。

アーキテクチャについて

元々Buyeeは1つの大きなモノリシックサービスでした（図1）。

それを最終的に、約20個弱のマイクロサービスに分ける計画で現在リプレイスを進めています。サービスの分け方としては、基本的にドメインごとに独立できるかどうかを基準に考え、Bagagge（荷物）、Order（注文）のように分けました。

現在は、既存のアプリケーションは止めることなく図2のようになっています。
マイクロサービス化が完成しているアプリケーションは、まだ数個しかありません。
それぞれのアプリケーションの通信には主に、REST APIを用いています。

最終的には既存のアプリケーションは無くなって、図3の様になる予定です。

今回やらなかったこと

DBのリプレイス/再設計

先ほどのアーキテクチャを見て、ピンと来た方もいるかもしれません..！
マイクロサービス化する上で、基本的にDBはそれぞれのサービス毎に独立するものだと思います。しかし弊社では、サービス毎に独立せず既存のDBをそのまま用いる手法を選択しました。

DB分割をするとなると、今回20個弱のマイクロサービスに分けるため、無論同じ数のDBの設計が必要となります。また、サービス自体は成長しているので、ドメイン群に変更がある度にDB設計の修正が必要を余儀なくされるのは想像できました。変更があれば、各DB間でデータの整合性の問題が発生する可能性も考えられます。

もしDBの分割が必要となった場合、コード部分のマイクロサービス化後にDB分割をすることで、上述したようなリスクや問題を局所化・極小化できると考えています。多かれ少なかれ、リプレイスで最初からサービス毎にDBを独立させないメリットもあると思います。

前述したリスクを回避するためにもDB分割には現在取り組んでおりません。今回のリプレイスの大きなゴールは、コード部分のマイクロサービス化が主となります。

リプレイスで意識していること

1 ドキュメントの整備

特に設計書は注力して作成していて、レビューも手厚く行われています。（それゆえ、時間もかかってしまいますが...
各APIごとや、各バッチごとに設計書を作成しています。1つのアプリケーションを20個弱に分けるので、ドキュメントが整備されないとどのサービスの何の機能を使えばいいか分からなくなるのは容易に想像できます。このような事態を避けるためにもドキュメントは完備するようにしています。

2 コードの品質 / 保守性

リプレイスをして、機能の改修や新規追加が以前と比べてし易くなることで、リプレイスの価値の1つが顕著に出てくると思います。そのためにもコードの品質への意識は欠かせません。

コードレビューの強化や、静的解析ツールの導入はまず初めに行われました。また、Clean codeやアーキテクチャの勉強会なども適宜行われています。
加えて、リプレイス前は満足な状態ではなかった自動テストも強化しています。バックエンドではUnitテストとFeatureテストを抜け目なく書くようにしています。一方、フロントではseleniumを導入してE2Eテストをしています。

また、保守性を高く維持するために複数のアプリケーションでは、ドメイン駆動設計（Domain-Driven Design: DDD）で開発が進められています。

3 技術選定

アーキテクチャや技術等は最適でなるべく新しいものを採用しています。特に開発言語やフレームワークは適宜バージョンアップするようにし、最新の便利なモジュールやライブラリを使用できるようにしています。
バージョンアップはサポート期限を考慮して行っており、フレームワークについてはLTSバージョンがリリースされる毎に行うようにしています。

最後に

マイクロサービス化にどのように向き合っているかを紹介させていただきました。これからマイクロサービス化を検討されている方々に少しでも有益な情報となれば幸いです。

リプレイスは、既存システムの品質改善にフォーカスする取り組みで、今までしたことがない貴重な経験をさせてもらっています。
また、今まで10年以上も稼働しているアプリケーションを、高い拡張性と保守性をもったサステナビリティなシステムへ変化させることに携われているのも素敵な経験だと思います。

まだリプレイスは完成していないので、一日でも早く完成させられるように引き続き努めていきたいと思います！

Wanted!

BEENOSグループでは一緒に働いて頂けるエンジニアを強く求めております！
少し気になった方は、社内の様子や大事にしていることなどをThe BEENOSにて発信しておりますので、是非ご覧ください。
とても気になった方は、まずはオンラインで弊社のエンジニアとざっくばらんにお話をさせて頂ければと思います！

世界で戦えるサービスを創っていきたい人は是非是非ご連絡ください。よろしくお願い致します！！