こんにちは。さとうだいすけ(@dskst9)です。
LOHACOはMonolithic Architecture（以下、モノリシック）からの変革期にいます。
モノリシックからの変革 = Microservices Architecture（以下、マイクロサービス）と考えてしまうケースが多いようですが、本当にそれでよいのでしょうか。
本記事では、LOHACOがモノリシックとどう向き合っているのかをまとめていきます！
さいしょにまとめ
対象読者
- マイクロサービスへの移行過程にいる方
- モノリシックからの移行を検討している方
- レガシーなシステムとお付き合いしている方
記事要約
- マイクロサービスへのアプローチは、地道な道を進んでいくことになる
- サービスは境界定義が重要で、境界定義から組織も考えなければならい
- ECサイトLOHACOでの参考事例
マイクロサービスで何を解決したいのか
マイクロサービスがもたらすものは技術の多様性やシステムの回復性、スケーリング、デプロイの容易性、交換可能なシステムなどが挙げられますが、一方でデメリットも理解する必要があります。
パフォーマンスの劣化、トランザクションの分断、運用の複雑さ。 このような課題を理解して、どのようにマイクロサービスに向き合うべきなのでしょうか。 何を解決したくてマイクロサービスを採択するのでしょうか。
自分たちの課題からマイクロサービスを考えないとアンチパターンになっていきます。
目標はマイクロサービスを作ることではなく、課題を解決していった結果マイクロサービスになっていたという方が、成功するのではないかと考えています。
モノリシックの限界
我々、 LOHACOの課題は肥大化したモノリシックなシステムでした。
モノリシックなシステムではビルドの時間も長時間を要し、不具合も連鎖的に発生していました。
きれいにメンテされていたモノリシックであればいいのですが、スパゲッティソースも散見している状態です。
今の組織規模、開発量の場合、モノリシックのままでは開発のスピードが上がらないため、我々はモノリシックからの脱却を進めています。
モノリシックからの脱却を考える
LOHACOは数年かけて、徐々にモノリシックを切り出してきました。
もちろん、まだ手をつけられていないところもあり、今回は一番の肝になるカートから注文周りを進めています。
脱却を考えた時にマイクロサービスへの移行も検討しましたが、モノリシックなシステムをマイクロサービスにするというこは、かなりのチャレンジを要します。
少しずつサービス分割をするには、Strangler Application Patternで徐々に移行していくことがセオリーと言われています。 モノリシックアプリケーションだけならいいですが、さらには巨大なモノリシックデータベースを抱えているシステムはどのように考えればよいでしょうか。
データベースも同時に移行することは、Strangler Application Patternの "一度に適用しないこと" に反してしまいます。 では、データベースはそのままにするというのはありなんでしょうか？
Service-Based Architectureという考え方
そこでService-Based Architecture*1（以下、サービスベースアーキテクチャ）を考えてみます。
サービスベースアーキテクチャとは
マイクロサービスと似ていますが、書籍「進化的アーキテクチャ*2」では以下の点が異なると定義されています。
より大きなサービス粒度
純粋なドメイン概念を中心としたものより大きく、「モノリスの一部」のような粒度となる傾向がある。依然としてドメイン中心であるものの、サイズが大きくなるということは（開発、デプロイメント、結合を始めとる多くの要因から）変更の単位を大きくし、変更を容易に行う能力を低下させる。（進化的アーキテクチャ,2018:94）
データベーススコープ
モノリシックなデータベースになる傾向がある。多くのアプリケーションでは、数年物（あるいは数十年物）の手に負えないデータベーススキーマをマイクロサービス用の細分化された固まりに再構築することは、現実的に難しい。（進化的アーキテクチャ,2018:94）
統合ミドルウェア
サービスバスのような Mediator を介した外部での調整にある。 〜中略〜 恐ろしいのは、多くの環境では依然として機能し続けるレガシーシステムがはびこっていることだ。エンタープライズバスのような統合ハブは、異なるプロトコルと異なるメッセージを持つ異種サービス間の接着剤になることに長けている。（進化的アーキテクチャ,2018:95）
簡単に言うと、サービスのサイズを大きくし、データベースの独立性を保ち、他レガシーシステムとうまく連携するということです。 これにより、"可能な限り共有の少ない"アーキテクチャとなります。
モノリシック、サービスベース、マイクロサービスを図にすると以下のようなイメージになります。
モノリシックアーキテクチャ
サービスベースアーキテクチャ
※データベースは分割しないパターンもあります。
マイクロサービスアーキテクチャ
※BFFが必須ではありません。
サービス分割=境界を考える
サービスの分割は境界定義が重要です。
サービスをビジネスの境界で切るのか、機能の境界で切るのかこれは悩ましい問題だと思います。境界の割り方はContext Mappingを適切に行なっても、その境界が正しいかはその組織にしかわかりません。
考えなければならないのは、マイクロサービス、またはサービスベースアーキテクチャで境界定義をするということは、それは組織にも影響するということ。
コンウェイの法則では「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」とあります。境界を定義するということは組織設計にも関わるのです。
LOHACOでの事例
では、我々はどのようにサービス分割を行ったのかをまとめます。
境界定義をどうするか
世の中のECサイトはたくさん存在しますが、境界定義の事例があまり多くは見つかりませんでした。 1つの事例として、GiltではAccount, Cart, Shippingにサービスが別れているのが見て取れます。
当初案
当初、 LOHACOを境界付けられたコンテキストを定義し分割を考えました。すると、数多くのサービスとなりたくさんの検討事項が発生しました。
こちらが当初考えた案です。危険な香りが漂ってますね。
ドメインでサービスを分割しようとするあまり、どんどんサービスが増えました。
- 適切なサービス分割ができているのだろうか
- サービスをまたぐトランザクションをどうするのか
- 全サービスから利用されるサービスのパフォーマンスをどうするのか
- この単位でデータベース分割をできるのか
- このサービス量を運用できるのだろうか
などなど、問題がてんこもりになりました。
検討した結果、現状このサービス境界では開発・運用はまだできないと判断しました。
改善案
サービスは少なくしました。
注文サービスという少しファットなサービスを作って、そこにサービスを集めている状態です。内部的にはモジュールを分けて、将来的に分割しやすいようにと考えています。
このサービス規模であれば、運用もでき当初の課題も解決できるはずです。
データベーススコープをどうするか
LOHACOは年季の入ったモノリスデータベースが存在します。
トランザクションがガシガシ入っているのもあり、ビックバンリリースになってしまうなど、前述の要因から今はデータベースを分割はしないという選択をしました。
これからもよろしく、モノリスデータベース。
いつかさようならを言う日はかならず来るよ、それまでは。
いつかのさようならを言うために、 LOHACOではクリーンアーキテクチャを意識して再構築することで、データベースの入れ替えがしやすいように準備しています。
さいごにまとめ
マイクロサービスで幸せになることができるのか。
それは組織の成熟度やシステムの状況など、さまざまな課題があると思います。
そして、課題の数だけアーキテクチャが存在するということです。
ShopifyからはModular Monolithsという「単一のコードベースの中にドメインごとの境界を作る」考え方も提唱されています。
ギルドワークスの増田亨さんはモノリスからマイクロサービスへの段階的移行を提唱しています。
流行りに乗るのではなく自分たちの組織、サービスに適した最良のアーキテクチャ選定をすること。 課題から考えることを大事にしていきたいと思います。
「マイクロサービスはある日突然なるんじゃない。日々、課題を解決していて気づいたらマイクロサービスになっている。」という言葉を聞いたことがあります。LOHACOも、課題を解決していくことでいつかマイクロサービスに行きつくのかもしれません。課題を解決するということこそが、技術選定なのでしょう。
そんなLOHACOでは、一緒に課題を解決する仲間を募集しています！
