マイクロサービスアーキテクチャはどこまで分割したら良いか
はじめに
こんにちは。株式会社ラキールで LaKeel DX コンサル3 Groupに所属する和知です。
普段はお客さまの課題解決に向けて、LaKeel DX上での設計や開発を行っています。
今回はLaKeel DXの特徴である「マイクロサービス」についてと私自身が開発して感じたことをご紹介しようと思います。
マイクロサービスについて
マイクロサービスアーキテクチャ(マイクロサービス)とは、ソフトウェアアプリケーションを独立して配置可能なサービスの組み合わせとしてシステムを設計する方法をいいます。
言い換えますと、アプリケーションが持ついくつかの機能をサービスごとに細かく分割し、それぞれのサービスをAPIなどネットワークで連携しシステムを動かすというものです。
この設計方法が今日のDX推進時代では広く認知されていると思います。
モノリシックサービスついて
またマイクロサービス以前に主流だった開発手法がモノリシックサービスアーキテクチャ(モノリシックサービス)になります。
モノリシックサービスはマイクロサービスとは異なり、システムを大きな一枚岩(モノリシック)で構成し、サービス全てが一つのコンポーネントとなります。お互いのサービスを呼び出すなどして連携しています。
マイクロサービスのメリット・デメリット
マイクロサービスには以下のメリット・デメリットがあります。
メリット
機能ごとの構築により、迅速な開発・改修が可能(アジャイル開発の適応性)
マイクロサービス同士が疎結合であるため機能追加や変更が容易
サービスごとにデプロイが可能で常に最新の状態を保てる
障害発生による影響範囲の限定が可能
特定の機能のみスケールするなど負荷の分散が可能
デメリット
分割した機能が後から容易に変更できないように、モノリシックサービスと比べシステム・アプリケーションの設計の要求レベルが高い
サービス間のテーブル結合不可などデータの一貫性が担保しづらい
API通信が増えることによる性能の低下
これらメリット・デメリットを見るとやはりメリットのほうが大きいように思えます。
LaKeel DX ではマイクロサービス(機能部品)ごとの開発、それらの蓄積によって部品の再利用が可能となり、高速な開発が可能となっています。
開発を通じた感想
現在LaKeel DX 上でマイクロサービスを活用して開発しているなかで感じているメリットまた失敗したと感じて改善していきたいことを紹介したいと思います。
開発・改修の容易さ
サービスの範囲が限定されている・サービス同士が疎結合であるため、やはり開発・改修にかかるコストは抑えられていると思います。上記図でいう注文サービスに改修が入ったとします、注文サービスは決済サービス・配送サービスには影響を受けません、反対に決済サービス・配送サービスも注文サービスの影響は受けないです。その分だけコストを抑え、開発範囲が限定されることで開発スピードの上昇にも繋がっています。
1サービスのデプロイが可能
あるサービスに改修が入った際に、そのサービスの改修後にシステム全体を止めることなく、そのサービスのみをデプロイできるというのは他サービスの開発・テストを止める必要がないため助かっております。
障害の検知が容易
障害が発生した際にはどのサービスかの特定ができ、かつマイクロサービス単位で構築されているためそこからの原因特定が容易となっています。また上記メリットで上げていますが、影響範囲を限定できるのは大きいと思います。
サービスの分割をしなかった
サービスAの追加機能としてBを追加する追加対応がありました。
サービスは機能ごとに分割されサービスと機能は1：1の関係ですが、サービスAの追加機能ということでサービスA内にサービスBを含める形で対応をしてしまいましたが、当たり前にAで障害が起きてしまった際にBのサービスも止まってしまうということがありました。
これについては実際に切り分けできたはずでしたが、設計段階でサービスBを切り出すなど分割の考慮が足りていませんでした。
マイクロサービスはどこまで分割したら良いか
上記でマイクロサービスとは「アプリケーションが持ついくつかの機能をサービスごとに細かく分割し、それぞれのサービスをAPIなどネットワークで連携しシステムを動かすというもの」と述べた通り、マイクロサービスで設計・開発するには「細かく分割するのが正解」と思い違いしていました。
ただサービスごとに分割する設計ではデメリットで述べたような「設計の要求レベルが高い」わけではないですし、他デメリットの「データの一貫性の担保」や「API通信増加による性能の低下」を真に受けてしまいます。
それらデメリットを抑えメリットを得るためにはサービスの分割をしない選択をし、その選択が「設計の要求レベルの高さ」だと思います。
私が担当した大量データのバッチ処理システムの案件ではサービスの分割をしない選択をしました。
大量データのバッチ処理では上記図の注文サービス・決済サービスから一意のデータを大量に取得するという場合に、それぞれ違うDBなのでデータの結合ができず、他サービスのテーブル取得に毎回APIを呼ぶとなるとデータ量の観点から好ましくないためです。
このため、大量データのバッチ処理には機能・サービスごとに細かく分割し、それぞれにデータベースをたてるというのはデータ量の観点から難しいと感じ分割をしない選択をしました。
注文サービス・決済サービスは分割しないが配送サービスは分割するというように、データの一貫性の確保やAPI通信の増加を抑えるために分割するしないを検討しました。
そのような検討を経て数機能を含んだ分割となりましたが、「バッチ処理」「移行処理」などと分割し最小単位での分割ではないですが、システム全体の分割としてはまとまっていると感じます。
マイクロサービスは細かく分割するのが正解と思っていましたが、設計・開発を通じてそのシステムに合わせて分割しない選択をとることでより最適なシステム・アプリケーションを作り上げることが出来ると感じました。
おわりに
マイクロサービスを概念だけを学ぶことと実務を通じて学ぶことでは考え方に差が生じると思いますし、実際にマイクロサービスを採用すると多大なメリットがあると実務を通じて学べました。
ただそのためには、やはり設計段階でのサービスの管理・データの整合性の維持などのためにサービスの機能の分割をどこまで行うかを十分に検討し、メリット・デメリットを明確にした上で設計が重要だと思っています。
ラキールでは豊富なマイクロサービスの実績の蓄積とナレッジの共有がされており、これから設計に深く関わる際にはこれらを意識し、最適なシステム・アプリケーションの提供を目指していきます。