モノリシックからマイクロサービスへ。あるいは、サービスベースアーキテクチャを考える。

こんにちは。さとうだいすけ(@dskst9)です。

LOHACOはMonolithic Architecture（以下、モノリシック）からの変革期にいます。
モノリシックからの変革 = Microservices Architecture（以下、マイクロサービス）と考えてしまうケースが多いようですが、本当にそれでよいのでしょうか。

本記事では、LOHACOがモノリシックとどう向き合っているのかをまとめていきます！

さいしょにまとめ

対象読者

• マイクロサービスへの移行過程にいる方
• モノリシックからの移行を検討している方
• レガシーなシステムとお付き合いしている方

記事要約

• マイクロサービスへのアプローチは、地道な道を進んでいくことになる
• サービスは境界定義が重要で、境界定義から組織も考えなければならい
• ECサイトLOHACOでの参考事例

マイクロサービスで何を解決したいのか

マイクロサービスがもたらすものは技術の多様性やシステムの回復性、スケーリング、デプロイの容易性、交換可能なシステムなどが挙げられますが、一方でデメリットも理解する必要があります。

パフォーマンスの劣化、トランザクションの分断、運用の複雑さ。
このような課題を理解して、どのようにマイクロサービスに向き合うべきなのでしょうか。
何を解決したくてマイクロサービスを採択するのでしょうか。

自分たちの課題からマイクロサービスを考えないとアンチパターンになっていきます。
目標はマイクロサービスを作ることではなく、課題を解決していった結果マイクロサービスになっていたという方が、成功するのではないかと考えています。

モノリシックの限界

我々、 LOHACOの課題は肥大化したモノリシックなシステムでした。

モノリシックなシステムではビルドの時間も長時間を要し、不具合も連鎖的に発生していました。
きれいにメンテされていたモノリシックであればいいのですが、スパゲッティソースも散見している状態です。
今の組織規模、開発量の場合、モノリシックのままでは開発のスピードが上がらないため、我々はモノリシックからの脱却を進めています。

モノリシックからの脱却を考える

LOHACOは数年かけて、徐々にモノリシックを切り出してきました。
もちろん、まだ手をつけられていないところもあり、今回は一番の肝になるカートから注文周りを進めています。

脱却を考えた時にマイクロサービスへの移行も検討しましたが、モノリシックなシステムをマイクロサービスにするというこは、かなりのチャレンジを要します。

少しずつサービス分割をするには、Strangler Application Patternで徐々に移行していくことがセオリーと言われています。
モノリシックアプリケーションだけならいいですが、さらには巨大なモノリシックデータベースを抱えているシステムはどのように考えればよいでしょうか。

データベースも同時に移行することは、Strangler Application Patternの "一度に適用しないこと" に反してしまいます。
では、データベースはそのままにするというのはありなんでしょうか？

Service-Based Architectureという考え方

そこでService-Based Architecture((SOA（サービス指向アーキテクチャ）ではありません。))（以下、サービスベースアーキテクチャ）を考えてみます。

サービスベースアーキテクチャとは

マイクロサービスと似ていますが、書籍「進化的アーキテクチャ((進化的アーキテクチャ 著者名:Neal Ford, Rebecca Parsons, Patrick Kua 著, 島田 浩二 訳, 発行年:2018年08月, 出版社:O'Reilly Japan, Inc.))」では以下の点が異なると定義されています。

1. より大きなサービス粒度
   純粋なドメイン概念を中心としたものより大きく、「モノリスの一部」のような粒度となる傾向がある。依然としてドメイン中心であるものの、サイズが大きくなるということは（開発、デプロイメント、結合を始めとる多くの要因から）変更の単位を大きくし、変更を容易に行う能力を低下させる。（進化的アーキテクチャ,2018:94）
   
   
2. データベーススコープ
   モノリシックなデータベースになる傾向がある。多くのアプリケーションでは、数年物（あるいは数十年物）の手に負えないデータベーススキーマをマイクロサービス用の細分化された固まりに再構築することは、現実的に難しい。（進化的アーキテクチャ,2018:94）
   
   
3. 統合ミドルウェア
   サービスバスのような Mediator を介した外部での調整にある。 〜中略〜 恐ろしいのは、多くの環境では依然として機能し続けるレガシーシステムがはびこっていることだ。エンタープライズバスのような統合ハブは、異なるプロトコルと異なるメッセージを持つ異種サービス間の接着剤になることに長けている。（進化的アーキテクチャ,2018:95）
   
   

簡単に言うと、サービスのサイズを大きくし、データベースの独立性を保ち、他レガシーシステムとうまく連携するということです。
これにより、"可能な限り共有の少ない"アーキテクチャとなります。

モノリシック、サービスベース、マイクロサービスを図にすると以下のようなイメージになります。

モノリシックアーキテクチャ

サービスベースアーキテクチャ

※データベースは分割しないパターンもあります。

マイクロサービスアーキテクチャ

※BFFが必須ではありません。

サービス分割=境界を考える

サービスの分割は境界定義が重要です。

サービスをビジネスの境界で切るのか、機能の境界で切るのかこれは悩ましい問題だと思います。境界の割り方はContext Mappingを適切に行なっても、その境界が正しいかはその組織にしかわかりません。

考えなければならないのは、マイクロサービス、またはサービスベースアーキテクチャで境界定義をするということは、それは組織にも影響するということ。
コンウェイの法則では「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」とあります。境界を定義するということは組織設計にも関わるのです。

LOHACOでの事例

では、我々はどのようにサービス分割を行ったのかをまとめます。

境界定義をどうするか

世の中のECサイトはたくさん存在しますが、境界定義の事例があまり多くは見つかりませんでした。
1つの事例として、GiltではAccount, Cart, Shippingにサービスが別れているのが見て取れます。

当初案

当初、 LOHACOを境界付けられたコンテキストを定義し分割を考えました。すると、数多くのサービスとなりたくさんの検討事項が発生しました。

こちらが当初考えた案です。危険な香りが漂ってますね。
ドメインでサービスを分割しようとするあまり、どんどんサービスが増えました。

• 適切なサービス分割ができているのだろうか
• サービスをまたぐトランザクションをどうするのか
• 全サービスから利用されるサービスのパフォーマンスをどうするのか
• この単位でデータベース分割をできるのか
• このサービス量を運用できるのだろうか

などなど、問題がてんこもりになりました。
検討した結果、現状このサービス境界では開発・運用はまだできないと判断しました。

改善案

サービスは少なくしました。
カート注文という少しファットなサービスを作って、そこにサービスを集めている状態です。内部的にはモジュールを分けて、将来的に分割しやすいようにと考えています。

このサービス規模であれば、運用もでき当初の課題も解決できるはずです。

データベーススコープをどうするか

LOHACOは年季の入ったモノリスデータベースが存在します。
トランザクションがガシガシ入っているのもあり、ビックバンリリースになってしまうなど、前述の要因から今はデータベースを分割はしないという選択をしました。

これからもよろしく、モノリスデータベース。
いつかさようならを言う日はかならず来るよ、それまでは。

いつかのさようならを言うために、 LOHACOではクリーンアーキテクチャを意識して再構築することで、データベースの入れ替えがしやすいように準備しています。

さいごにまとめ

マイクロサービスで幸せになることができるのか。
それは組織の成熟度やシステムの状況など、さまざまな課題があると思います。
そして、課題の数だけアーキテクチャが存在するということです。

ShopifyからはModular Monolithsという「単一のコードベースの中にドメインごとの境界作る」考え方も提唱されています。

ギルドワークスの増田亨さんはモノリスからマイクロサービスへの段階的移行を提唱しています。
[https://www.slideshare.net/masuda220/ss-137608652:embed:cite]

流行りに乗るのではなく自分たちの組織、サービスに適した最良のアーキテクチャ選定をすること。
課題から考えることを大事にしていきたいと思います。

「マイクロサービスはある日突然なるんじゃない。日々、課題を解決していて気づいたらマイクロサービスになっている。」という言葉を聞いたことがあります。LOHACOも、課題を解決していくことでいつかマイクロサービスに行きつくのかもしれません。課題を解決するということこそが、技術選定なのでしょう。

そんなLOHACOでは、一緒に課題を解決する仲間を募集しています！