マイクロサービスアーキテクチャにおけるサービス分割の難しさ

大阪オフィスの移転を機に、生活リズムも絶賛見直し中の @kawanamiyuu です。

今回は昨年度から取り組んでいる、通称「かみせんプロジェクト」の今期の成果（の一部）についてご紹介します。

かみせんプロジェクトとは「開発の未来に先手を打つプロジェクト」の略称で、2017 年度に取り組みが始まりました。

ミッション

『継続的に新しいことに取り組み、組織要望に対して迅速にトレンド技術で応えることができるようになる』

目標

具体的には以下の実現のための技術検証や知見獲得を、社内システムのマイクロサービス化を題材に行っています。

社内システムの概要

かみせんプロジェクト開始前

2018 年 9 月現在

マイクロサービス化を進めるとバックエンドで複数のサービスが協調して動作することになり、これまではデータベースのトランザクション機能により担保されていたデータの一貫性について別のアプローチが必要になります。

かみせんプロジェクトの今期の取り組みの 1 つとして、マイクロサービスの結果整合性について調査や技術検証を行いました。

課題感

検証内容

検証結果（得られた知見）

サービスの分割は難しい

大前提としてサービスをまたぐトランザクションが発生しないようにサービスを分割すべき
今回のように同一トランザクションでデータ更新をしたい処理であれば、サービス同士が疎結合ではないということであり、そもそもサービス分割の粒度が正しくない可能性が高い
ドメインの知識が乏しい状態では適切なドメイン境界を認識することはきわめて難しい
ドメインの知識が増えた中盤になってから分割し直すことも、別の意味で難易度が高そう
- 自動テストなど品質担保の仕組みや、作り直しに対する組織の理解の度合いで実現可能性が大きく変わる

結果整合性の担保は難しい

今回のようにリトライ（有限回数）で整合性を担保する場合、すべて失敗する可能性もゼロではなく、最終的にログなどから手動リカバリーできる仕組みを考えておく必要がある
今回は時間の都合で検証していないが、メッセージキューを利用したイベントソーシングなアーキテクチャも検討したい
分散トランザクション（二相コミットなど）の手法を使う選択肢もあるが、システムの複雑さや難易度が一気に増加しそうで現実的ではなさそう

マイクロサービスの分割や結果整合性に関する知見は、情報としては世の中にありますが、実際に自分の手を動かして検証することで、改めてその課題感を実感するとともに、現実のサービス開発にマイクロサービスアーキテクチャを適用する難しさも明らかになりました
ラクスでは現在、HR（人事労務）領域を対象した新サービスの開発に取り組んでおり、この「かみせんプロジェクト」で得られた知見が現実のプロジェクトで活かされようとしています。例えば
- ラクスが提供するクラウドサービスとしては初めて全面的にクラウドネイティブなアーキテクチャを採用することが決定しました
- マイクロサービスアーキテクチャの採用についても検討しましたが、今回経験したサービス分割の難しさから、まずはモノリシックなアーキテクチャで最速でマーケットに参入するという選択をしました

ラクスでは現状に満足せず開発の未来に先手を打っていける仲間、HRTech に興味があるエンジニアを募集しています！

株式会社ラクスでは一緒に働く仲間を募集しています

マイクロサービスアーキテクチャにおけるサービス分割の難しさ

ラクス採用担当

株式会社ラクス / 採用課

Engineer