こんにちは。ヘルスケア開発室のJongcheol Chungと申します。

 LINEヘルスケア事業のいろんなサービスの中、LINEドクターというオンライン診療サービスがあります。LINEドクターは2020年のリリース以後、現在もMicro Service Architecture（以下MSA）でコンポーネントを構築して運用しています。今回この記事ではMSAでサービスの開発と運用を経験して感じた、MSAのメリット・デメリットを簡略に紹介したいと思います。

LINEドクターのコンポーネント構成

 MSAは一つのサービスの中、コンポーネント達を小さく分けて小規模で構成する設計スタイルを意味します。 つまり、コンポーネント間の依存を減らし、コンポーネントをそれぞれ独自で運用することが目的であります。 LINEドクターの場合も、このような形でコンポーネントが分離されています。LINEドクターもこのようにコンポーネントを分離して、依存を最小化しています。

LINEドクターは、LINEのビデオ通話を通じた医師の診療、お薬の処方、配送までワンストップで受ける事ができるオンライン診療サービスです。病院検索、予約、診療、決済の流れで診療が行いますが、この流れ通りにドメイン単位を分け、それに伴うコンポーネントとDB Schemaを分離しました。 また、ただコンポーネントを分離することだけではサービスの運用ができないため、実際のユーザーが使用する画面仕様に合わせて、Backend For Frontend（以下BFF）というコンポーネントを挟んで、データ層とフロントエンド層を中継するように構築しました。

メリット : 明確な役割分担、リリース対象の最小化実現

 コンポーネントを細かく分けて、一番のメリットは、役割分担が明確に分けられることです。BFFを除いて、コンポーネント達が分離されているため、作業が重なることがなくなりまして、それぞれのコンポーネント担当者がスケジュールを決めて案件に必要な開発を進めることができました。 コンフリクトが発生する可能性もなくなって、それによる作業損失も少なくなりました。 もちろん、すべてのコンポーネントが同じボリュームの開発を毎回進めるわけにはないので、スケジュールに余裕があるコンポーネントの場合はBacklogの作業を進んだりして開発の空白が発生しないようにしています。 その結果、ほとんどの案件を計画通りに開発することができましたし、Backlogも解決することで、それぞれのコンポーネントが継続的に管理しながら運用することができました。

 このようにコンポーネントを分けることによるもう一つのメリットは、機能別リリースが可能であることです。 リリース作業はサービスに異常が発生する可能性があるリスクがあります。 リリースによって既存になかった問題点が発生する可能性もあり、様々な理由でリリースに失敗すると、サービス障害になる可能性があります。MSAの場合は案件開発の際にどのコンポーネントに修正が必要か明確になって、案件に関与した特定のコンポーネントのみ修正とリリースが可能になり、リリース対象外のコンポーネントはサービスインのまま継続的に運用が可能になりました。このような部分は、サービスの安全な運用面でいい影響を与えたと思います。

デメリット : ドメイン分離の難しさとコンポーネントの巨大化

 MSAを長く運用して見て、デメリットの部分も一つずつ見え始めました。そのうち一つがAPIのリクエストが増える部分です。ドメイン別コンポーネントが分離されているため、一気に複数のデータを表示する必要があるときは、たくさんのAPIをリクエストする必要が発生します。一つのDBインスタンスでデータを管理する場合は、Joinを利用して簡単に複数のテーブルのデータを一度に取得が可能ですが、MSAではコンポーネントが分離されているのでJoinが利用不可能な状況です。場合によってはこの方が性能的に良いかもしれませんが、コネクションがたくさん発生するのは確かです。

 もう一つのデメリットとしては、コンポーネントの分離基準の難しさです。明確に分離しようとしても、境界が曖昧なドメインも存在します。 例えば、患者の問診票情報の場合、患者が入力した情報という立場から考えるとAccountコンポーネントのドメインですが、診療情報の立場から考えると、Treatmentコンポーネントのドメインと考えられます。観点によってドメインを分類する基準がそれぞれなため、メンバー内の適切な合意が必要です。このような部分は新しい機能が追加されるとき、悩みが深くなります。LINEドクターは2022年12月から処方薬の配送サービスを開始しましたが、その時、薬の情報や配送情報をどうコンポーネント分けるか深く議論したことがあります。結果的にドメイン分離のために追加のコミュニケーションコストが発生したり、妥協的な判断が必要になったりするケースもありました。

 

 あと、管理対象コンポーネントがますます多くなることもデメリットの一つです。 LINEドクターが管理するコンポーネント数はバッチなど含めてバックエンドサイドだけで16個で、サーバー台数はその倍以上です。 エンジニアリソースは限られているため、一人が複数のコンポーネントを担当しなければならない状況です。 現在、少しでもサーバ管理の負担を軽減するため、既存のVMサーバをKubernetesなどオーケストレーションツールの導入を検討しています。

まとめ

 アーキテクチャ(Architecure)という言葉は、もともと建築設計の意味を持つ単語です。建築物を設計する際、要件、周辺の環境、オーナーのニーズなど複合的な要素を考慮しないといけないように、プログラミング世界のアーキテクチャも同じく考慮が必要なものだと思います。 それぞれアーキテクチャのメリットとデメリットがあるので、サービス要求とチームの状況を見ながらどの方針で構築すれば良いか決めることが正解だと思います。以上、LINEドクターのMSA経験談でした。この記事が今後のアーキテクチャ投入でお悩みのエンジニアの方々に少しでもお役に立てたら幸いです。