Cloud Native Fineract と可擴展性の実踐

はじめに

Fineract は Apache Foundation が管理するオープンソースの金融アプリケーションフレームワークであり、クラウドネイティブアーキテクチャを採用することで高スケーラビリティと柔軟な運用を実現しています。本記事では、Fineract におけるクラウドネイティブ技術の導入と可擴展性の実踐方法について詳しく解説します。

可擴展性の定義と三維モデル

可擴展性は、システムが増加する負荷や要件に対応できる能力を指します。Fineract では、以下の三つの軸を軸にしたアプローチが採用されています。

1. X軸（水平拡張）：複數のインスタンスを並列に実行し、データベースのレプリケーションや複數データベースインスタンスの接続をサポートします。
2. Y軸（機能分離）：機能をモジュール化し、獨立して動作・拡張可能な構造を実現します。
3. Z軸（テナント隔離）：テナントごとに個別に実行されるシステムインスタンスを構築し、リソースの効率的な利用を図ります。

実裝改善

Kubernetes 部署の最適化

• Deployment と StatefulSet の利用：

  • 無狀態サービスには Deployment を、有狀態サービス（例：バッチマネージャー）には StatefulSet を使用し、自動スケーリングを実現します。
  • バッチ処理アーキテクチャでは、バッチマネージャーとバッチワーカーを分離し、コントローラーによってワークロードを分配します。

• Liquibase の構成ファイル：

  • データベースアップグレード後、インスタンスを停止する専用構成ファイルを導入し、データベースロック競合を低減します。
  • HAM Chart と統合し、プレアップグレードHookでLiquibaseスクリプトを実行し、跨可用區のデプロイを支援します。

インスタンスモデルの進化

• 2020年の計畫：

  • 読み取り/書き込みAPI、読み取り専用API、バッチ処理、専用フロントエンドインスタンスをサポート。
  • データベースには読み取り/書き込みレプリケーションと読み取り専用レプリケーションを組み合わせる。
  • メッセージシステム（Kafka/ActiveMQ）を用いてインスタンス間の通信を調整。

• 実際の実裝変更：

  • 読み取り/書き込みAPIを維持し、バッチマネージャーAPIを獨立したインスタンスに分離。
  • Ingressソリューションを導入し、HTTPメソッド（GET/HEAD）を読み取り専用インスタンスに、特定URIをバッチマネージャーインスタンスに、デフォルトAPIを読み取り/書き込みインスタンスにルーティング。
  • フロントエンドインスタンスをAPIインスタンスから分離し、フロントエンドリクエストがバックエンドの安定性に影響を與えないようにする。

性能と可用性の最適化

• リソース割當戦略：

  • Podリクエストに基づいてCPUコア數を設定（例：100m CPUは1つのCPUに相當）。
  • G1 GC（インタラクティブリクエスト）とParallel GC（バッチ処理）のハイブリッド戦略を採用。

• 可用性の向上：

  • Max Qパラメータを設定し、可用區間でのPod數の差を1以內に保ち、単一可用區の障害によるサービス中斷を防ぐ。
  • DNS解決戦略を調整し、DNSキャッシュを無効化し、定期的にデータベースアドレスを再解析することで、障害切り替え時の中斷時間を數秒に短縮。

管理プラットフォームの概念

• Jenkins を基盤とした集中管理：

  • 環境構成とデプロイフローをサポート。
  • インフラ構造の変更後もサービスの継続性を自動化。

• クライアントの適応：

  • 一部の企業クライアントは獨自のAWSアーキテクチャを使用しており、獨立して管理が必要。
  • ファールオーバー（データベース移行）の安定性を検証するシステムテストを実施。

技術的制限と実裝

• Kubernetes Ingress の制限：

  • HTTPメソッドのルーティング機能が內蔵されていないため、AWS Load Balancer Controller を使用して特定のルーティングを実現。

• HAM Chart の構成：

  • 読み取りバッチ、バッチマネージャー、フロントエンド、Liquibase などのインスタンスプールをサポートする500行以上の構成。
  • 現在はAWS EKSに限定され、クロウドサービスのデプロイを可能にする。

今後の計畫と機能

• Guard Rails の設計：

  • Terraform と Jenkins によるコードで制限を設定し、異なるデプロイ方法のインフラストラクチャの一貫性を確保。
  • 環境タイプ（生産/非生産）とデータタイプ（生産/非生産）を分離し、混合構成（例：非生産環境に生産データを保存）をサポート。

• アーカイブ機能の議論：

  • 貸し出しデータの処理方法（削除、他テナントへの移動、エクスポート後の再インポート）を検討。
  • クライアントのニーズとコミュニティとの協議の結果で最終的な解決策を決定。

• オープンソース貢獻の進捗：

  • 一部の改善はまだ Apache リポジトリに提出されていない（例：HAM Chart は AWS 依存で未クリーンアップ）。
  • 今後の目標は、改善をオープンソースプロジェクトに提出し、非機能的要件（可用性、スケーラビリティ）を向上させること。
  • 現在進行中：アーカイブ機能の開発、生産環境の検証と移行テスト。

結論

Fineract におけるクラウドネイティブアプローチは、スケーラビリティと可用性の向上を実現するための重要な要素です。Kubernetes の活用、Liquibase の構成管理、インスタンスモデルの進化を通じて、柔軟で信頼性の高いシステム構築が可能になります。今後の開発では、オープンソースコミュニティとの協力により、さらなる改善と拡張が期待されます。