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

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

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

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

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

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

f:id:kawanamiyuu:20180925154624p:plain

f:id:kawanamiyuu:20180925144057p:plain

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

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

ある機能を 2 つのサービス (図中の project-service と function-service) として切り出す
- モノリシックなアプリケーションを、複数（社内での利用実績がない、あるいは少ない）の言語やフレームワークを利用して分割することも技術検証の一環
あるリソースを新規登録する際に、従来 1 トランザクションで行っていた処理 (SQL) の一部を、今回切り出したサービスの API 呼び出しに置き換える
データの整合性はリトライ処理で担保する

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

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

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

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

エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。

https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gle
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com