Clever Geek Handbook

モノリシックにノーと言う：CPAプラットフォームをどのように行ったのか









カットの下には、Fuse Fabricの通信事業者向けにコンテンツプロバイダーアクセスCPAプラットフォームのモジュラーアーキテクチャを実装した方法に関するストーリーがあります。 同時に、なぜこの決定をし、モノリシックアプリケーションを作成するために標準のJ2EEテクノロジースタックを使用しなかったのかを説明します。



CPAとは何ですか？



CPAは、パートナーの加入者である通信事業者にさまざまなサービスを提供するコンテンツプロバイダーとのやり取りを整理するためのプラットフォームです。



簡単なシナリオとして、加入者が明日の天気を知りたい状況を見てみましょう。





このシナリオは、さまざまなモジュールの相互作用の連鎖に基づいてさまざまなプロセスを構築する方法をよく示しています。 具体的には、SMSセンターと対話するためのモジュール、サービスカタログ、パートナーのカタログ、課金システムを操作するためのモジュール、ビジネスオペレーションを記録するためのモジュール、パートナーと対話するためのモジュールなどが含まれます。



この最も単純なシナリオでさえ、12を超える操作で構成されています。 同時に、通信事業者は、さまざまなシステムが相互作用する、より多くのはるかに複雑なシナリオを持つことができます。 たとえば、USSDセンター、IVRセンター、Webポータルなどからのリクエストがあります。 また、これは1回限りのリクエストではなく、サービスへのサブスクリプション（分割払いを含む）、サービスからのサブスクリプション解除などです。



アプローチの選択



CPAシステムを作成するプロジェクトを開始したとき、プラットフォームアーキテクチャのいくつかのオプションから選択しました。 この規模のアプリケーションを設計するときは、最初に次の側面を考慮する必要があります。





これらすべてを念頭に置いて、従来のモノリシックJ2EEアーキテクチャは必要な柔軟性を提供せず、すべての顧客ニーズをカバーしていないため、私たちには適していないことにすぐに気付きました。 そのため、Fuse Fabric構成ではOSGi -Red Hat Jboss Fuseに基づいたモジュラーアーキテクチャを選択しました。



アーキテクチャは、明確に定義されたインターフェイスに基づいて相互作用する自律モジュールに基づいている必要がありました。 今日では「マイクロサービスアーキテクチャ」という用語で説明されていますが、CPAプラットフォームが発売された時点では、「マイクロサービス」という言葉を知っている人はほとんどいませんでした。



このレベルのシステムのアーキテクチャの選択を間違えると、開発と運用の段階、およびシステムをさらに開発して機能を拡張する段階の両方で、文字通り壊滅的な結果を招く可能性があることに注意してください。 しかし、できるだけ早くプロトタイプを顧客に見せ、選択したアイデアの実行可能性を証明する必要がありました。 そしてここで、OSGiのモジュール性サポートが助けになりました。



システムを設計するとき、私たちはそれを構成するAPIモジュールとBPMプロセス（標準のBPMN表記を使用して記述されたビジネスプロセス）に依存していました。 これらのプロセスは、APIモジュール呼び出しを通じて、CPAプラットフォームが実行するビジネスシナリオを説明しました。 つまり、初期段階では、実際にはプリミティブ操作を実行する「スタブ」マイクロサービスであるモジュール（OSGiセット）と、OSGiサービスの呼び出しシーケンスを可能な限り通信事業者のビジネスシナリオに近い形で記述するBPMプロセスがありました。望ましい結果を達成するため。



同時に、作成したOSGiセットはBPMスクリプトと他の場所の両方から呼び出されることを理解しました。 たとえば、サービスカタログを操作するサービスは、BPMプロセスから直接呼び出されるだけでなく、コンテンツマネージャーがサービスを開始、削除、編集できるようにバックオフィスシステムでも使用されます。 サービスカタログAPIは、通信事業者のWebサイトでサービスのリストを提供するためにも使用されます。 課金システムサービスは当初CPAプラットフォームでのみ使用されていましたが、現在はRESTサービスとしても利用できるため、通信事業者のインフラストラクチャの他のシステムでも使用されています。



実装



明確に定義されたAPIを使用してモジュールの形でアーキテクチャを作成すると、すぐにその有効性と操作性に納得しました。



OSGiセットAPIが合意および承認されたため、異なる開発チームによる個々のOSGiセットの開発プロセスを並列化することができました。 同時に、すべてのチームがコードベースとサブジェクトエリアで作業したため、チームはお互いに影響を及ぼしませんでした。 主なことは、一貫したAPIセットに違反しないことです。 あるチームはアフィリエイトカタログの開発に専念し、別のチームはビジネスログサービスの開発などに専念できます。 同時に、アーキテクトは一貫したAPIに基づいてシステムの整合性を監視しました。



APIの変更の追跡を容易にするために、OSGiスイートのセマンティックバージョニングを採用しました。 これは、Xがメジャーバージョン、Yがマイナーバージョン、ZがパッチバージョンであるXYZ形式のコンポーネントのバージョン管理を意味します。 バージョンは、次の規則に従って反復されます。





これにより、システム全体のAPIサービスへの変更を簡単に追跡し、サービスのコラボレーションを構築するときにそれらを正しく管理しました。



複雑なシステムを開発する場合、実装された機能のテストを作成する必要があります。 OSGi環境のコンポーネントはインターフェイスを呼び出すことで相互作用するため、ユニットテストが大幅に簡素化されます。 アプリケーション内のサービスが別のサービスを参照している場合、テスト段階で、アクセスされているサービスを「スタブ」に簡単に置き換えることができます。 また、各モジュールをテストするときは、その動作の詳細を考慮する必要があります。



負荷の大きいシステムでは、負荷の性質に応じて、すべてのサービスがアプリケーション全体のボトルネックになる可能性があることがわかりました。 そのため、OSGiセットの各API呼び出しについて、JMXインターフェースを介して利用可能なメトリックが削除されました。 これにより、サービスメソッドの呼び出しの最大期間、一定期間の平均値、およびメトリックの変化のダイナミクスを記録することができました。 記録されたデータは、負荷テスト中にアプリケーションのボトルネックを即座に特定するのに役立ち、オンラインモードで運用システムを監視することも可能にしました。 そのため、パフォーマンスが低下した場合、システムを安定させるための対策を迅速に講じることができました。 たとえば、サービスをランタイム環境の別のノードに転送したり、別のJVMに移動したりできます。 同時に、OSGiを使用すると、残りのアプリケーションコンポーネントに影響を与えることなく、実行中のシステムでこれらすべてのアクションを実行できます。



既存のシステムに新しい機能を追加する場合、コードベースの変更（新しいセットまたは新しいバージョンのセット）を明示的に追跡し、テストプロセスを最適化できます。 次回の配信でコンポーネントのバージョンが変更されていない場合、新しいテストを開発して徹底的に再テストする必要はありません。 システムに追加された新しい機能に集中することをお勧めします。



もちろん、実稼働環境で発生する可能性のあるエラーの影響を受けません。 ただし、OSGiを使用すると、稼働中のシステムにすばやく変更を加えることができます。 コンポーネントのエラーを修正し、パッチバージョンをインクリメントし、OSGiランタイムにインストールするだけで十分です。 これは、システムのダウンタイムが提供されるサービスの品質と会社の利益の両方に大きな影響を与える状況での重要な利点です。



また、モジュール式アーキテクチャとは異なり、モノリシックアーキテクチャでエラーが検出された場合、アプリケーション全体を再構築して再起動する必要があることにも注意してください。 また、従来のJ2EEアプリケーションの再起動には通常、多くの時間がかかりますが、これは会社の経済的損失に匹敵します。



Jet Infosystemsのソフトウェアソリューションセンターの開発部


More articles:


All Articles