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

こんにちは。さとうだいすけ(@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」では以下の点が異なると定義されています。

  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という「単一のコードベースの中にドメインごとの境界を作る」考え方も提唱されています。

ギルドワークスの増田亨さんはモノリスからマイクロサービスへの段階的移行を提唱しています。

www.slideshare.net

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

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

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

*1:SOA(サービス指向アーキテクチャ)ではありません。

*2:進化的アーキテクチャ 著者名:Neal Ford, Rebecca Parsons, Patrick Kua 著, 島田 浩二 訳, 発行年:2018年08月, 出版社:O'Reilly Japan, Inc.

ASKUL Engineering BLOG

2019 © ASKUL Corporation. All rights reserved.