Practical experience of local microservices in low fault tolerance business scenarios

2014 年に設立された Helian Health は、健診シーンに特化したヘルスケアマネジメントサービス企業です。病院向けには、検査前・検査中・検査後をカバーする一連の SaaS サービスを提供しています。企業向けには、団体健診とヘルスケアマネジメントを提供しており、Li Jinji や PwC などが Helian の顧客です。ファミリー向けには、ヘルスケアマネジメントアプリを提供しています。現在、Helian は全国 200 以上の都市と 2,000 以上の病院をカバーしています。

Helian Health はどのような技術発展の段階を経験してきたのでしょうか。

第 1 段階：マクロアプリケーション。0 から 1 への立ち上げで、反復スピードは速いものの、失敗も多数ありました。ビジネスは Helian に迅速な反復と検証を求めていました。どうすれば迅速に実現できるか。当時、Alibaba Cloud Jushita が提供するコンテナ管理サービスも利用しており、これがコンテナ化のプロトタイプとなりました。まとめると、スピードを重視した結果、技術的負債が多く、障害も頻発し、ビジネスの期待に応えられない場面もありました。

第 2 段階：マイクロサービス。Helian に接続する病院が増えるにつれて障害が増加し、顧客からの苦情も多くなりました。当時、開発者は终日障害対応に追われていました。その後、Helian はモジュールのデカップリングとサービス分割に取り組み、Dubbo と Nacos を導入しました。しかし、当時のビジネス理解はまだ十分ではなく、サービス分割に問題があり、サービス間の相互呼び出しが頻発しました。ほぼすべてのインターフェイスから呼び出されるスーパーサービスが存在し、安定性に悪影響を及ぼしました。まとめると、ビジネスを深く理解しないままマイクロサービスを分割しても、対症療法にしかならず、根本的な解決にはなりません。

第 3 段階：マイクロサービス再構築。横断的なオーダ、注文、データ同期に焦点を当て、モジュールとサービスを再編成し、デプロイメントアーキテクチャを K8s に置き換え、サービスガバナンスに使用していた一部のミドルウェアを Alibaba Cloud Microservices Engine (MSE) などのクラウドサービスに置き換えました。この時点で、システム全体の安定性が向上しました。まとめると、ビジネスを中心にマイクロサービスを構築し、クラウドの利点と組み合わせることで、開発・運用効率が向上し、オンラインの安定性も改善されました。

フォールトトレランスの低さがもたらす医療サービス特有の技術的課題とは何でしょうか。

フォールトトレランスの低さは Helian のビジネス特性です。たとえば、ユーザーが健診のために病院を訪れた際、IT 上の理由で検査項目を完了できない場合、ユーザー体験に大きな影響を及ぼします。健診だけでなく、医療業界全体がフォールトトレランスの低い特性を持っています。さらに、多くの人にとって健診の頻度は年 1〜2 回と極めて低く、非常にトラフィックの低いシーンです。トラフィックが低いと、カナリアリリースはほぼ無効で、フルリリースでもバグを発見できないことがあります。コードのリリースから 1 年後にようやく見つかるバグもあります。

そのため、Helian はまず複雑なロジックを整理し、モジュール化とデカップリングを徹底する必要があります。

ただし、ビジネスのデカップリングだけであれば、モジュール化で十分です。たとえば Java を使用している場合、Java モジュールを JAR パッケージに分割し、Maven で異なる依存関係を管理できます。しかし、初期の技術アーキテクチャの多くは単一パッケージで異なるビジネスをサポートしており、ビジネスモジュールが多く、ビジネス間の分離がありませんでした。マイクロサービスが分割されていない状態では、エンタープライズ向けビジネスコードに問題が発生すると、フォールトトレランスの低い病院ビジネスの障害につながり、ビジネスとして許容できません。

そこで、Helian はサービスを直接実装し、サービスを明確に分離しました。呼び出し可能な共通の基本サービスがあり、異なるビジネス間で影響を及ぼし合うことはありません。サービス化はビジネスのデカップリングだけでなく、サービスの階層化とパフォーマンスの重要なコアサービスの保護も実現します。たとえば、フォールトトレランスが極めて低いビジネスに対しては、問題のシナリオに特化したサポートサービスを構築できます。同時に、サービス単位で独立した品質検査も実施できます。これらが一緒にパッケージ化されていると、独立した品質検査は行えません。

サービス分割には主に 2 つのモードがあります。1 つはビジネス単位での分割、もう 1 つは機能単位での分割です。異なるビジネス間で相互呼び出しも可能です。最終的な Helian のアーキテクチャは前述の図の通りです。主に機能別に分割し、ビジネスを補足的に位置づけています。たとえば、フロントエンドは Web サービス、青いブロックはビジネスコアの反復開発を担当するビジネスサービス、下層は注文、決済、メッセージサービスを機能別に分割しています。さらに下層はビジネスから離れたサービスで、病院データ同期サービスや手動契約履行サービスなどは自社構築の独立サービスです。

反復頻度の高いビジネスサービスと相対的に安定したサービスを分離し、両者を HTTP で接続しています。ビジネスクラスタ内では Dubbo を RPC として使用し、Nacos をサービス登録・設定センターとして、RocketMQ を非同期メッセージとして使用しています。

マイクロサービス進化の実践経験

マイクロサービスにおいて、Helian は Dubbo+Nacos の技術スタックを使用しています。

Dubbo は Java インターフェイスベースの RPC フレームワークです。Java プログラマーにとって、シンプルなアノテーションを追加するだけでマイクロサービス化できるため、チーム内で推广されました。同時に、呼び出しはコードをほとんど侵しません。@Autowire を @DubboReference に変更してサービスをインジェクションするだけです。Dubbo 内での Nacos の統合は非常に完璧で、数行の設定だけで使用できます。コントロールパネルはシンプルで使いやすいです。Dubbo と同様に中国のコミュニティベースなので、プログラマーにとってのハードルが低いです。

初期の段階で、Helian は Nacos のコミュニティ版を自社構築していましたが、大きなパフォーマンスボトルネックに直面しました。当時の Dubbo2 サービスモデルはインターフェイスベースで、1 つのインターフェイスに 1 つの機能が 1 つのサービスとして対応し、トラフィックが非常に大きくなりました。Alibaba Cloud の Microservices Engine (MSE) が Helian の Dubbo の負荷を乗り越えるのに役立ちました。優れた互換性を持っていました。その後、Helian はコミュニティに従って Dubbo 3 にアップグレードし、Dubbo 2 のサービスモデルの問題を解決しました。さらに、メモリの観点から、MSE は優れたチューニング機能を備えており、ビジネスパフォーマンスを 4 倍に向上させ、リソースコストを削減しました。

Helian は多数の病院にサービスを提供しています。各病院の要件は不確実でそれぞれ異なり、大量の機能スイッチが存在します。こうしたスイッチの操作は非常に危険で、通常は開発者が設定を行います。MSE はこの問題をうまく解決しています。MSE の機能スイッチはアプリケーションを再起動せずに動的に設定できます。同時に、Key Management Service (KMS) と組み合わせてデータを暗号化して保存でき、ユーザーは暗号化を意識する必要がありません。

HTTP ゲートウェイは主にプロトコル変換の問題を解決しています。Helian のアプリフロントエンドはビジネスロジックが重く、結果のカプセル化は不要で、サービスケイパビリティを公開するだけで済みます。そこで、Apache ShenYu をベースにオープンソースで改造を加え、HTTP プロトコルを Dubbo に変換し、POST/GET をサポートし、認証と権限付与のロジックをゲートウェイ側に委譲しました。

DevOps 面では、K8s+イメージリリースのロールバックで Container Service for Kubernetes (ACK) を使用し、継続的インテグレーションには Cloud Effect CI を使用しており、Helian に高いリリース効率をもたらしています。最大で週あたり 20〜30 回リリースし、1 回あたりのリリース時間は 2〜3 時間から 8 分に短縮されました。さらに、Helian は Dubbo をベースにしたサービスの分離を実現しています。たとえば、同じサービスの 2 つのバージョンをデプロイでき、同じコードと使用法でありながら異なるインスタンスで動作します。2 つのサービスは独立したメモリを持ち、片方のサービスに障害が発生しても、もう一方のサービスには影響しません。ただし、このケイパビリティはまだ不十分な点があり、制御機能の強化が今後の発展方向です。

マイクロサービスの将来計画

今後、Helian は Service Mesh (ASM) のコントロールプレーンを実現したいと考えています。

前述の図のように、サービスリクエストが届いた際、もし req * であれば、ServiceA * の特定のバージョンにルーティングしたいとします。リクエスト経由で送信されたメッセージは Service message では受信できず、Service * で受信されるべきです。これにより、リンク全体のルーティングケイパビリティを実現します。現在、Alibaba Cloud ASM は上記のケイパビリティを持つ Istio のホスティングを提供しており、Dubbo の基本的なガバナンスケイパビリティも提供しています。今後、ASM 内での統合と進化を探っていきます。

Service Mesh を実装する目的は、テスト環境のコスト削減です。現在、Helian の大規模クラスターには各ビジネスグループ用に 7〜8 組のテスト環境があり、各グループが 1 組ずつ使用して相互に干渉しませんが、コストが過大です。フルリンクルーティングを実現できれば、各開発チームがマーキングトラフィックを使用して、サービスのテスト環境を公開できます。

業界の現在のベストプラクティスを参照すると、フルリンクのカナリアルーティングはゲートウェイレベルでトラフィックを識別・ラベリングし、各テスト環境には独立したラベルを付与します。各ホップのサービス呼び出しでトラフィックラベルを伝播し、各ホップの呼び出しで、トラフィックラベルとピアマシンのラベルに基づいて異なるポリシーでルーティングマッチングを行います。最終的に、各環境が修正済みサービスをデプロイするだけで、ベースライン環境のサービスを最大限に再利用でき、全体のコストを削減できます。

さらに、Helian は包括的な HTTP ゲートウェイを実装する予定です。将来のトレンドから見ると、フロントエンドはますます重くなっており、バックエンドが Web 層になる必要はなく、バックエンドサービスを直接フロントエンドに公開する方がよいです。そのため、Helian はすべての Web 層を BFF ゲートウェイに置き換えることを検討しており、クラウドネイティブコミュニティのペースに追随し、共に発展していくことを期待しています。