レガシーERPの限界を超える：リアルタイム分析アーキテクチャ構築の実践（Infor + Aurora + QuickSight）

はじめに：クラウドERP移行の隠れた課題

ERP（統合基幹業務システム）のクラウド移行は、多くの企業が目指すデジタルトランスフォーメーションの中核です。しかし、移行を進めてみると 「オンプレミスでは当然だったリアルタイムレポートがクラウドでは実現できない」 という皮肉な状況に直面することがよくあります。

北米建材市場の巨人Oldcastle APGも例外ではありませんでした。アスファルトやコンクリートなどの建築資材供給と舗装サービスを提供する同社は、150以上の施設を運営し、毎日数百名のユーザーがカスタマーサービス、財務、物流、製造部門で複雑なリアルタイムレポートに依存していました。

問題はInfor Cloud ERPへの移行後に顕在化しました。Inforの標準レポート機能では、オンプレミス環境で使用していた多次元分析やリアルタイムデータアクセスを満たせなかったのです。バッチ方式で1日1～2回生成されるレポートでは、意思決定のスピードが著しく低下しました。

核心的な問題: 「バッチレポートを待っている間に、私たちは競争優位を失っていた」 - Oldcastle ITチーム

本記事では、OldcastleがAWSソリューションアーキテクトと協力してこの問題をどのように解決したか、その アーキテクチャの核心と実務適用ポイント を詳細に分析します。（参考：この事例は AWS Architecture Blog に掲載された内容を基に再構成しています。）

アーキテクチャの中核：Infor Data Fabric → AWS リアルタイムパイプライン

Oldcastleが選択したアプローチは Infor Data Fabric Stream Pipelines を活用したリアルタイムデータストリーミングです。この構造は従来のETLバッチ処理を置き換え、データが生成された瞬間に分析システムへ届けられるよう設計されています。

全体ワークフロー概要

1. データ取り込み（Ingestion）： Infor ERPテーブル（販売注文、在庫、財務トランザクションなど）で変更が発生すると、Stream Pipelinesが即座にイベントをキャプチャします。INSERT、UPDATE、DELETE操作とタイムスタンプメタデータが含まれます。

2. 負荷分散（Load Distribution）： Inforが直接Private VPCにアクセスできないため、Network Load Balancer(NLB)をパブリックサブネットに配置し、安定したElastic IPを提供します。このIPはInfor側でファイアウォール許可リストに登録されます。

3. 接続管理（Connection Management）： Amazon RDS ProxyをPrivateサブネットに配置し、データベース接続をプーリングし、自動フェイルオーバーをサポートします。IAM認証を使用してセキュリティを強化しています。

4. データ保存（Storage）： Amazon Aurora PostgreSQL（Multi-AZ）を使用してリアルタイムデータを保存します。JSONBカラムを活用して柔軟なスキーマを維持しつつ、頻繁にクエリされるフィールドにはインデックスを作成してパフォーマンスを最適化しています。

5. 分析と可視化（Analytics）： Amazon QuickSightがダッシュボードとピクセルパーフェクトレポートを提供します。SPICE（Super-fast, Parallel, In-memory Calculation Engine）キャッシュを有効化し、複雑な分析でもサブセカンド応答時間を保証します。

6. 埋め込み統合（Embedded Integration）： Amazon API Gateway + Lambdaを介してQuickSightダッシュボードをInfor OS内部にiframeで埋め込みました。ユーザーはERP画面を離れることなくリアルタイム分析を確認できます。

コードで見る核心設定（Python例）

以下は、RDS Proxyを介した接続プーリング設定とQuickSight埋め込みURL生成を簡略化したコードです。

import boto3
from botocore.config import Config

# 1. RDS Proxyを介したデータベース接続
# 実際はSQLAlchemyやpsycopg2で接続しますが、ここでは概念を示します。
rds_proxy_endpoint = "oldcastle-proxy.proxy-xxxxxx.us-east-1.rds.amazonaws.com"

def get_db_connection():
    """RDS Proxyを介してAuroraに接続（IAM認証使用）"""
    # IAM認証トークン生成
    session = boto3.Session()
    client = session.client('rds')
    token = client.generate_db_auth_token(
        DBHostname=rds_proxy_endpoint,
        Port=5432,
        DBUsername='oldcastle_user',
        Region='us-east-1'
    )
    # 実際の接続ロジック（省略）
    return token

# 2. QuickSight埋め込みダッシュボードURL生成
quicksight = boto3.client('quicksight')

def get_embedded_dashboard_url(user_arn, session_token, dashboard_id):
    """ユーザー別Row-Level Securityが適用された埋め込みURLを生成"""
    response = quicksight.generate_embed_url_for_registered_user(
        AwsAccountId='123456789012',
        UserArn=user_arn,
        SessionLifetimeInMinutes=600,
        ExperienceConfiguration={
            'Dashboard': {
                'InitialDashboardId': dashboard_id
            }
        },
        AllowedDomains=['https://infor.oldcastle.com']
    )
    return response['EmbedUrl']

💡 実務のヒント: AuroraのJSONBカラムとSPICEキャッシュを併用する際は、頻繁にクエリされるフィールドを別カラムとして抽出しインデックスを張る戦略が効果的です。JSONBは柔軟性を提供しますが、複雑なJOINや集計が必要な場合はパフォーマンス低下が発生する可能性があります。

実務適用時の考慮点と限界

1. データ遅延（レイテンシー）に対する現実的な期待値

ストリーミングパイプラインは「ほぼリアルタイム（near real-time）」に近いですが、完全な同期トランザクションではありません。Infor Data Fabric Stream Pipelinesの遅延は通常 数秒から数分以内 です。ミリ秒単位の整合性が必要な金融取引などでは、追加のCDC（Change Data Capture）ソリューションの検討が必要です。

2. セキュリティ：Allow ListとIAM認証の二重防御

このアーキテクチャのセキュリティ核心は NLBの固定IPによるAllow List と RDS ProxyのIAM認証 の組み合わせです。Infor側はNLBのElastic IPのみを許可し、AWS側はIAMトークンなしではデータベースにアクセスできません。日本の金融機関や官公庁でもこのパターンを参考にできるでしょう。

3. コスト最適化戦略

• SPICEキャッシュ： 頻繁に参照されるデータはSPICEにキャッシュし、QuickSight SPICE容量コストとAurora読み取りトラフィックコストを削減します。
• Aurora Auto Scaling： 読み取りワークロードが増加すると自動的にリーダーインスタンスが追加されますが、予想ピーク時間に合わせて最小/最大インスタンス数を設定 することが重要です。
• API Gatewayキャッシュ： 埋め込みURL生成リクエストが多い場合は、API Gatewayキャッシュを有効にしてLambda呼び出しコストを削減できます。

4. 日本企業のクラウド環境での適用コンテキスト

日本の企業がこのアーキテクチャを参考にする際の注意点：

• Infor ERP国内導入事例： Inforは日本でも製造業や流通業で使用されていますが、Stream Pipelines機能はライセンスオプションによって制限される可能性があります。導入前にInforのアカウントチームと必ず確認してください。
• レガシーDBとの共存： 多くの日本企業はOracleやSQL Serverをオンプレミスに維持したままクラウドERPを導入します。この場合 AWS DMS（Database Migration Service）を活用したリアルタイムレプリケーション を検討できます。
• ネットワーク構成： 日本のIDC環境では専用線（Direct Connect）やVPNを介してAWSと接続するケースが多いです。NLBの代わりに PrivateLink を使用すると、パブリックサブネットを経由しないより安全な接続が可能です。

まとめ：ERPの未来は「開かれた分析」にかかっている

Oldcastleの事例は、クラウドERP移行が単なるインフラ移行ではなく、データアクセス性と分析能力を根本的に再定義する機会 であることを示しています。

核心的な教訓をまとめると：

1. バッチレポートはもはや選択肢ではない。 リアルタイムストリーミングパイプラインにより、意思決定の速度を飛躍的に改善できます。
2. 埋め込み分析がユーザー体験を変える。 ERP画面を離れずに分析結果を確認できるようにすることで、ツール切り替えのコストを排除しました。
3. クラウドネイティブサービスの組み合わせが鍵。 Aurora + QuickSight + API Gateway + Lambdaの組み合わせは、拡張性と保守性において大きな優位性を提供します。

今後このアーキテクチャを発展させる方向としては、Amazon Bedrockを活用した生成AIベースの自然言語クエリ（例：「今期の売上が最も高い地域は？」） や MLベースの需要予測モデル の統合が考えられます。

次のステップとしての学習方向：

• Infor Data Fabric Stream Pipelinesの公式ドキュメント熟読
• Amazon QuickSight SPICE容量とパフォーマンスモニタリングのハンズオン
• AWS Lambda + API Gatewayを活用したサーバーレスバックエンド構築の実践

合わせて読みたい記事

• React、Metaを離れる：Linux Foundation傘下のReact Foundation発足の意味
• Daggr公開：コードで書き、目で確認するAIワークフロービルダー