The import and export framework AGEIPort (GEI) is officially open source

AGEIPort とは

AGEIPort は、デジタルサプライチェーンによってインキュベートされ、Alibaba Group 内で幅広く活用されているデータインポートおよびエクスポートソリューションのセットです。優れたパフォーマンス、安定性、信頼性、豊富な機能、容易な拡張性、エコシステムの完全性を備え、Excel/CSV データファイルのアップロードやダウンロードといった複雑な ToB ビジネスシナリオにおいて、開発者が高性能で優れたユーザー体験を実現し、保守性の高いデータインポートおよびエクスポート機能を迅速に提供できるよう支援することに注力しています。

現在、Alibaba Group では、Hema、Cainiao、Local Life、Alibaba Health、Nai Nai、Taoshi などの部門での利用がますます広がっており、複数の技術コンポーネントの基盤となっています。618 や独身の日の多くの試練を乗り越え、毎月 300〜400 億件のデータを安定的にインポートおよびエクスポートしています。

AGEIPort が解決するペインポイントとは

業務システムのデータインポートおよびエクスポート機能に以下のペインポイントがある場合、AGEIPort が最良の選択肢となります。

1. ユーザーは Excel を使ってデータをバッチでインポートまたはエクスポートすることが多く、そのデータ量は数千件から数万件、数十万件から数百万件にまで及びます。システムの処理速度が遅く、ユーザーから不満の声が上がることも少なくありません。

2. ページ上の非同期操作タスクの進捗はモックです。タスクの 99% はまるでシュレーディンガーの猫のようなもので、次の瞬間に実行が終了するかもしれないし、10 分以上かかるかもしれません。いずれにせよ、いつ終わるのか誰にも確信が持てないのです。

3. ファイル読み書きのユーティリティクラスとデータ処理のインターフェイス/抽象クラスは、各アプリケーションで何度も書き直され、何層にもラップされていますが、より複雑なビジネスシナリオには決して対応できません。これらのユーティリティクラスや抽象クラスが十分な数のクラスから参照されるようになると、パブリッククラスの修正が全体に影響を及ぼします。賢いプログラマーは刃の上を歩くように慎重に新しいコピーを作成して使い回しますが、アプリケーションのあちこちに変更が及んでおり、少しの油断が問題を引き起こします。

4. インポート/エクスポート関連のコードは具体的すぎて再利用できず、抽象的すぎて理解と保守が困難です。インターフェイスや抽象クラスの入出力を十分に汎用的な JSON オブジェクトや Map として定義してしまうと、次にそのコードを引き継ぐ開発者は自分が宝くじに当たった（不幸な目に遭った）と悟るでしょう。

5. アプリケーションごとにコードの書き方が異なります。新しいアプリケーションで同じ機能のコードを書くときは、変化を受け入れ、視野を広げる必要があります。

6. 日常的なビジネス開発において、パフォーマンス、スタイル処理、データ読み書き、マッピング、インタラクションなど、ビジネスとは関係のない問題に悩まされることがよくあります。ビジネス開発に集中してビジネス上の問題を解決し、非機能の問題はフレームワークに任せたいものです。

7. ToB の複雑なビジネスシナリオでは、PaaS/SaaS プロダクトを構築する必要があります。コードには十分な拡張性と設定可能性を持たせ、同じコードであらゆるシナリオのカスタマイズ要件を満たせるようにする必要があります。

8. 集中型ミドルウェアに依存してインポート/エクスポート機能を実装しています。プロモーションの保証が完了した後でも、共有リソースの影響を受けます。ビジネス規模が急増すると、インポート/エクスポートのパフォーマンスは依然としてミドルウェアの処理性能に制限されます。

9. コンソールや Nacos の設定に依存してインポート/エクスポートタスクを追加・修正しています。ロールバックしたいときにはいつも慌てることになります。ロールバックをサポートできないコンソールを二度と使わずに済むよう願っています。

AGEIPort の利点

全体のフレームワークはイベント駆動アーキテクチャに基づいて設計され、先進的な設計コンセプトに従っています。

1. クラスター/スタンドアロンの実行、シリアル/パラレル実行が透過的に切り替わり、データ処理のパフォーマンスを大幅に向上できます。開発者はビジネスロジックの処理に集中するだけで済みます。

2. リアルタイムなタスク進捗の計算とフィードバックをサポートし、データ処理進捗のモックを排除してユーザー体験を向上させます。

3. ToB の複雑なビジネスシナリオにおいて、多様な方法（宣言的定義、動的定義）とディメンション（設定、プラグイン、ポリシー、SPI）で各種シナリオの個別ニーズを満たすことができ、プラットフォームベースや PaaS/SaaS プロダクトの基盤として活用できます。

4. 複数のコンポーネント、複数のシナリオ、複数の機能をすぐに使える形で提供します。

5. GitOps の設計思想に基づき、関連するイミュータブルインフラをアプリケーションの Git リポジトリにカプセル化することで、デリバラブルのリリースとロールバックをより迅速、安定、安全に行えます。

6. 分散型アーキテクチャにより、ビジネスアプリケーションが自律的にクラスターリソースを組織化し、ビジネス機能の高い分離性、スケーラビリティ、可用性を保証します。

7. タスク処理のフローとコード記述を標準化し、データ処理タスクの各プロセス間およびユーザーとのインターフェイスを定義して責任を分離します。ユーザーのインポート/エクスポートコードの記述を標準化し、コードの保守性を向上させます。

8. ビジネスドメインオブジェクトを定義し、汎用インターフェイスの設計を通じてドメインモデルをインポート/エクスポートコードに導入します。これにより、ビジネスコードにおける Map や JSON パラメータの過度な使用を避け、コードの保守性を向上させます。

9. ビジネスコードの実行プロセスを記録し、ビジネスコードのパフォーマンス最適化を支援します。

AGEIPort のアーキテクチャ設計

AGEIPort のアーキテクチャと機能設計を以下の図に示します。

イベント駆動

AGEIPort はイベント駆動アーキテクチャに基づいて全体のフレームワークを設計し、タスクのパフォーマンスと完全な非同期実行を保証するとともに、処理ロジックを切り離してスケーラビリティを高めています。

スタンドアロンモードでメインタスクを実行する場合、アプリケーションクラスターからランダムに 1 つのノードを選択し、メインタスクおよびメインタスクの分解後のサブタスクを実行します。

クラスターモードでメインタスクを実行する場合、アプリケーションクラスターからランダムに 1 つのノードをメインタスクのマスターノードとして選択します。メインタスクはサブタスクに分解され、アプリケーションクラスター内の他のノードに配布されます。他のノードはメインタスクのスレーブノードとして機能します。

フレームワークには LocalEventBus（スタンドアロン EventBus、スタンドアロンタスクを処理）と RemoteEventBus（分散 EventBus、マルチマシンタスクを処理）が組み込まれています。EventBus は現在のコンテキストルーティングに基づいて、イベントをマスターノードのリスナーに配信します。モニターはタスクの進捗を計算し、現在の状態を判定して、次のイベントを送信するか、何もしないかを決定します。

イベント駆動プロセスの例を以下の図に示します。

1) 1 つのサブタスクが実行に失敗し、もう 1 つのサブタスクが正常に実行され、メインタスクが実行に失敗する

2) すべてのサブタスクが正常に実行された後、メインタスクがマージされる

並列性と非同期性

並列性と非同期性は、主にインポート/エクスポート機能のパフォーマンス、ユーザー体験、開発効率の問題を解決するために使用されます。

スタンドアロンモードでメインタスクを実行する場合、アプリケーションからランダムにノードを選択し、サブタスクスレッドプールでサブタスクを並列実行します。

マルチマシンモードでメインタスクを実行する場合、アプリケーションから複数のスレーブノードを選択し、各スレーブのサブタスクスレッドプールでサブタスクを並列実行します。

フレームワークは Reactor スレッドモデルを採用しています。マスターノードでタスクが実行される際、まずタスクをバックプレッシャキューに投入し、その後バックプレッシャキューからタスクを取り出してメインタスクスレッドプールで実行します。メインタスクはサブタスクに分割されて配布されます。サブタスクはスレーブノードに配布され、スレーブノードのサブタスクスレッドプールで実行されます。

また、フレームワークの並列性と非同期性は開発者にとって透過的です。開発者はパフォーマンスの問題を気にする必要はありません。フレームワークのコールバックインターフェイスを実装して、ページ処理やデータ返却（ファイルのエクスポートはページングクエリの実装）を行うだけで済みます。フレームワークは開発者のコールバックインターフェイスをマルチスレッドで同時に並列に呼び出します。

インポートのコアインターフェイス：

BizImportResult write(BizUser user, QUERY query, List data) throws BizException;

エクスポートのコアインターフェイス：

List queryData(BizUser user, QUERY query, BizExportPage bizExportPage) throws BizException;

分散型設計

分散型設計は、主にインポート/エクスポート機能の可用性と柔軟性を向上させ、インポート/エクスポートクラスターがビジネス規模に応じてスケールすることでパフォーマンスを向上させ、アプリケーション間のリソース分離を保証し、インポート/エクスポート機能の安定性を高めるために使用されます。

主な解決策は、分散型設計によりビジネスアプリケーションのノードが自律的にクラスターを組織化し、アプリケーションが外部システムに依存しないようにすることです。アプリケーションクラスターは内部で相互に通信し、タスクのスケジューリング、配布、実行を行います。

最終的な効果として、ビジネスアプリケーションに Jar パッケージを 1 つ導入するだけで、自動的にクラスターが形成されます。クラスター内で実行されるインポート/エクスポートタスクは外部ミドルウェアやサービスに依存せず、インポート/エクスポートタスクの実行において完全なクローズドループを実現できます。クラスター内のノードは相互に登録、サブスクライブ、通信が可能です（クラスター内でのメインタスク/サブタスクのスケジューリングと進捗同期を保証するため）。クラスターにマスターノードは存在しません。各ノードは対等の関係にあり、1 つのノードが利用可能であれば、全体として機能が利用可能です。

この方式では SideCar メカニズムを採用し、サービス検出と通信の仕組みを導入することで、アプリケーションが自律的にクラスターを組織化し相互に通信できるようにし、アプリケーションクラスター内のタスクスケジューリングとタスク進捗報告を完結させます。インポート/エクスポートタスクの実行時、アプリケーションのどのノードもマスターノードとスレーブノードの両方として機能でき、分散化を実現します。1 つのインポート/エクスポートタスクのクラスターにおいて、そのタスクの処理を担当する固有のマスターノードが存在します。

一方では、この分散型で自律的に組織化されたクラスターによるタスク配布と実行により、インポート/エクスポートクラスターがビジネスアプリケーションの規模に応じて弾力的にスケールし、アプリケーションクラスターリソースの使用率が向上します。もう一方では、アプリケーション間のクラスターは互いに分離され、外部システムに依存しないため、アプリケーションの SLA が向上します。最後に、どのノードもマスターとして機能できる設計により、アプリケーション全体の可用性が向上します。すべてのクラスターノードが停止した場合にのみ、インポート/エクスポートタスクが利用不可となります。

GitOps

GitOps は、Git を使用してインフラとアプリケーション設定を管理する開発・運用プラクティスです。GitOps はクラウドネイティブ向けの継続的デリバリー手法であり、コアとなる考え方は、アプリケーションシステムの宣言型イミュータブルインフラとアプリケーションを Git バージョン管理リポジトリに保存し、Git を宣言型インフラとアプリケーションの唯一の信頼できる情報源とすることです。主なメリットは、開発効率の向上、リリース制御の強化、信頼性、安定性、一貫性の向上、リリースの自動化、継続的デリバリー、クラウドネイティブ対応に有利であることです。

ロールバックは、Git リポジトリの前のバージョンのコードを再公開またはロールバックするだけで済み、設定管理の整合性を考慮して複数のコンソールの設定を変更する必要がないことを想像してみてください。ずっと簡単だと思いませんか。

フレームワークは GitOps の配信方式をサポートし、開発と配信の効率、およびインポート/エクスポート機能の SLA を向上させます。GitOps では、インポート/エクスポートタスクの実行に必要なインフラと、ユーザーが開発したインポート/エクスポートのビジネスコードの両方がユーザーアプリケーションの Git リポジトリに保存され、自由なレビューとバージョン管理が可能で、パイプラインを通じた自動デプロイが可能です。

非 GitOps のインポート/エクスポート機能の開発、公開、ロールバックプロセス

GitOps のインポート/エクスポート機能の開発、公開、ロールバックプロセス

標準化されたプロセスとドメイン指向モデルのコーディング

Map や JSON を大量に関数の入力パラメーターとして使用する「威力」を目の当たりにしたことがあるでしょう。これらはドメインモデルを簡単に排除し、新しい開発者を苦しめ、慎重にさせます。

ジェネリックインターフェイスを使用することで、他のフレームワークが Map/JSON インターフェイスを使用する代わりに、インターフェイスでドメインオブジェクトを定義できるようにします。開発者はビジネスドメインモデルを直接コーディングでき、最終的にコードの可読性と保守性を向上させます。

フレームワークは標準化されたタスク処理フローを提供します。つまり、開発者は標準インターフェイスを実装するだけでインポート/エクスポート機能を完成できます。主に構造化された開発者がインポート/エクスポートコードを記述し、コードの可読性と保守性を向上させ、すべての開発者のコード構造とロジックを一貫させ、フレームワークのセマンティクスによる制約を適用するために使用されます。これにより、開発者は異なるアプリケーションやチームでインポート/エクスポート機能を開発する際のコンテキストスイッチを避けることができます。

また、標準化されたタスク処理フローは CPU 集約型と IO 集約型のプロセスを区別できるため、フレームワークの透過的なパフォーマンス向上につながります。