チャイナライフのXiaobin氏は、Dubboがどのようにアーキテクチャを変更したのか、Alibaba Cloudへの移行を検討しているのかについて共有しています。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
Dubboについて
2013年、中国生命保険では、ビジネスデータベース全体を変革するためのRPCフレームワークを探していました。当時、市場には成熟した製品はほとんどなく、Spring CloudやDubboなど数多くの製品が出回っていました。私たちが探していたのは、実運用環境で大規模に適用されているフレームワークでした。Dubboはタオバオでも以前から導入されており、アリババのビジネスモデルは当社のビジネスモデルに匹敵するものでした。例えば、当社のビジネスモデルでは、海外の複数の地域からの依頼に対応する必要があり、それぞれに業務要件があります。
そういったことを考慮して、2013年にもDubboの利用を開始しました。2016年には香港とマカオ、2019年5月にはインドネシアでも業務システムを開始しました。今後は、Dubboを利用していることもあり、シンガポールをはじめとする東南アジア全域にも業務システムを急速に展開していく予定です。
展開の効率化とコスト削減という点で、Dubboのおかげでかなり助けられています。この記事では、多くの伝統的な保険会社に共通するDubbo以前のアーキテクチャについて説明した上で、Dubboをどのように利用したか、そしてアーキテクチャがどのように変化したかについてお話したいと思います。
保険会社が過去にしてきたこと
サーバーのハードウェアに関しては、他の多くの伝統的な保険業務システムが使用しているように、私たちが使用していたのは、通常IBMやHPのミニコンピュータでした。当時利用可能だったのはこの2つのシステムだけで、どちらもUNIXベースのOSが動作していました。
ビジネスアーキテクチャについては、これまでのソフトウェア開発では、主にクライアント／サーバアーキテクチャが用いられていました。このようなアーキテクチャの下では、Tuxedoという強力なミドルウェアが分散トランザクション管理に利用されており、優れた一貫性と高カレンシー性能を提供していました。では、そもそもなぜTuxedoをリプレースする必要があるのでしょうか？第一の理由は価格が高いこと、第二の理由は関連するO&M要員が不足していること、第三の理由は業務の統合性が高くなり、分散型やクロスプラットフォームのシナリオではパフォーマンスやスケジューリングが悪くなることです。第四の理由は、Tuxedo がモノリシックなアプリケーション向けに設計されていることです。その結果、あえて分割することはありません。
基幹業務システムをどのように変革するか
この図は、モノリシックアプリケーションと比較した場合のマイクロサービスの利点を示しています。Dubboは、異なるコンポーネント間の相互作用のための役割を果たし、これはレゴのおもちゃの凸部と凹部に似ています。これは、通信管理とサービスガバナンスを実装しています。この設計に支えられて、大型の伝統的なコアアーキテクチャを打破します。
OneLifeは、当社のビジネス支援プラットフォームです。その名の通り、1つのプラットフォームですべての保険業務を処理し、社内エコシステムを形成し、画像、新サービス、保存、クレーム決済など、いくつかの異なる領域をサポートすることができます。また、ワークフロー、商品エンジン、引受エンジン、メッセージエンジンなどのエンジンも提供しています。これらの業務機能は、どの保険会社にとっても必要不可欠なものです。
Dubboで開発された保険業務処理プラットフォーム
Dubboの支援を受け、「シックスマルチ」の保険業務処理を実現するための新しい保険業務処理プラットフォームを構築しました。シックスマルチとは、複数の業務システム、商品ラインアップ、従うべき規制、エンジン、通貨言語を持つという考え方を表しています。例えば、保険証券を生成するには、英語で生成するのか、中国語で生成するのか、インドネシア語で生成するのかを判断する必要があります。もちろんそのためには、各事業部との連携も必要ですし、適切な処理プラットフォームの設計・開発も必要になります。
OneLife分散システムの形成
図に示すように、以下の4つの部分でクローズドループを形成することができます。Dubboベースのマイクロサービスコール、Jenkinsベースの継続的インテグレーション、Rancherベースのクラウド展開アプリケーション、Pinpointベースのチェーン監視です。インドネシア版のクラウド展開については、アリババクラウドと協議を重ねてきました。将来的には、インドネシアのシステムが真っ先にAlibaba Cloudに移行する可能性があります。ピンポイントチェーンの監視という点では、表示されているトポロジーが非常にわかりやすいのですが、このトポロジーをベースにすると、フォーメーションが途切れたり、通話が失敗したりと、いくつかの問題点が見えてきます。今年は、Pinpoint chain monitoringの助けを借りて、100以上のバグを確認することができました。Pinpointチェーン監視とDubboの組み合わせは秀逸です。
香港とマカオでのDubboの分散方法
Dubboは150以上のサーバー、210以上のアプリケーション、2,100以上の消費者、1,300以上のプロバイダーが香港とマカオに分散しています。保険会社、特に自社の業務システムでは、高頻度の取引はあまりありません。高頻度取引のほとんどはフロントエンドで発生します。業務システムが常に高頻度な状態にあるわけではありませんが、それでもすべての業務システムが安定して正確に出力されることが重要です。これがDubboを選んだ理由の一つです。
Dubboの仕組み 中国生命保険（海外）有限公司
弊社の業務の約7割は初期のDubboバージョン（具体的には2.4.9）を使用しています。以前、分散トランザクションの補償など、Dubboをベースにいくつかのコード修正を行っていました。その後、大幅なコード修正を行ったため、バージョンアップができないことがわかりました。では、残りの3割の業務に使われているフレームワークは何なのか、と思われるかもしれません。あえて最新版を周辺機器で試しているだけなのですが。また、このバージョンは、実用化して実現可能であることが証明されてから、基幹業務アーキテクチャに適用しています。現在、中国生命保険(海外)有限公司のDubboは1日に2100万回以上の呼び出しを受けており、Dubboを導入してからシステムクラッシュが発生したことはありません。
Dubboの構成構造
ここでは構成を共有します。2つの問題点が強調されています。第１の問題点は、リトライ機構である。これの問題点は、サービスが中断した場合、制御プラットフォームを利用して手動で介入したり、サービスが重要なものであればトランザクションを繰り返すことで代替的に補償したりすることです。第二の課題は、ZooKeeper登録センターを利用すると、ピーク時のネットワーク消費量が膨大になるため、デメリットがあることです。Dubboバージョン2.7のメタデータコンセプトは有望です。今後、Dubboのバージョン2.7以降を利用して、ZooKeeperの欠点を克服できるか、あるいはZooKeeperを最適化できるかを試してみたいと思います。
Dubboマイクロサービスの応用シナリオ
上図は、Dubboマイクロサービスのアプリケーションを示しています。アプリケーションは、オンライン・サービス・ページから始まり、新しいサービス・コンポーネントに移動します。その後、ワークフローが起動し、引受結果が照会されます。引受結果に基づいて、保険料計算結果が自動的に照会され、フロントエンドに戻される。インドネシアで基幹業務システムと営業システムを導入する場合、低コストは必須条件です。また、事業単位を分離する必要があります。これには、Base開発モデルが関わってきます。Base開発モデルとはなんでしょうか？
ビジネスが複数の地域に分散している場合、地域ごとに固有のバージョンを持つ必要があります。公開されている基本バージョンが同じであれば、業務の効率化を図ることができます。例えば、本社には基本的なサービスがありますが、インドネシアには独自の規制があります。将来的に香港にもこのような需要があれば、基本版がある一定の審査を通過したら、基本版をロールバックして、地域ごとに異なる基本版をリリースします。つまり、複雑な状況では、基本版は異なるビジネスロジックの階層的な分離、階層的なコード管理、階層的・地域的なサービスガバナンスをサポートしています。
提案
第一に、視覚的な管理を強化します。
第二に、サービスグリッドを導入してパッケージ化し、ネットワーク呼び出し、トラフィック制限、回線遮断、サービス間の監視など、マイクロサービスシステムでより多くの機能を提供します。
第三に、複数の言語をサポートすることです。Dubboは現在、PHP、Node.js、Python、Goクライアントを提供していますが、将来的にはさらに多くのクライアントをサポートする予定です。
4つ目は、Dubboが分散トランザクション管理をサポートすることを推奨しないことです。最初にDubboを使用したとき、分散トランザクションをサポートする必要があると判断しました。そのため、Dubboをベースにコードを変更しました。アプリケーションの処理はスムーズで、コードはプラットフォームをまたいでもトランザクションの一貫性を確保することができました。しかし、サービスに障害が発生すると、送信するトランザクションがすべて崩れてしまい、データベースに致命的なリスクをもたらしました。
そこで、Dubboにメッセージ機構のサポートを増やしてもらい、分散トランザクションを補償しながらビジネス開発をしていくことが望ましいと考えています。以上が実用化を通じて思いついたいくつかのアイデアと提案です。
よくある質問
Q1: モノリシックアプリケーションをマイクロサービスコンポーネントに置き換えるプロセスは、ステップバイステップなのか、それとも一括して行うのか？また、置き換えプロセスを完了させるためには、どのくらいの人手とリソースが必要ですか？
A1: まず、既存の構造はモジュール化されており、モジュール同士は独立しています。最も重要なデータ構造については、ビジネスロジックを分離する必要があります。その後、データベースのシャードやパーミッションを設定し、モジュールを段階的に置き換えていきます。開発前には、全体の置き換えプロセスをしっかりと計画しておく必要があります。最初のモジュールを立ち上げたときは5人しかいませんでしたが、全員が技術力があり、それぞれの業務分野に精通していました。経営陣の支持を得ることが最優先でした。
Q2：システム内で分散トランザクション制御が利用できない場合、データの不整合をどのようにして検出することができるのでしょうか？また、この問題はどのように解決できるのでしょうか？
A2: ピンポイントベースのチェーン監視により、O&M担当者は問題を迅速に検出し、障害を修正した後、手動介入を行うことができます。キーサービスにはMQの仕組みを利用しています。しかし、このメカニズムは多くの時間とマンパワーを消費します。大規模な分散トランザクション制御は避けた方が良いと考えています。
Q3：社内のデータ量が多い場合、旧システムから新システムへデータを移行する際に、Oracleデータベースをどのようにリプレースすればよいでしょうか？この質問にお答えいただけますか？
Ａ３：データベースレベルでは、Oracleデータベースのテーブル構造やデータが他のデータベースと一致していることを確認する必要があります。比較にはETLなどのツールを利用することができます。アプリケーションレベルでは、2つのステップを踏むことができます。最初のステップは、処理を自動化することです。セルフコンパイルツールを使用して、両方のデータベース上でアプリケーションのSQL文を実行し、タイムリーにエラーを修正することができます。3回目の実行では、ほぼすべてのSQL文が正常に実行できるようになります。次のステップでは、キーとなるアルゴリズムやインターフェースをスポットチェックし、新しいインターフェースが出力するデータと業務データを比較します。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ