MFT のエキスパートが必要ですか？
当社のエキスパート MFT システムインテグレーターのネットワークにお繋ぎいたします。
パートナーを探す
高可用性 & DR
B2B 連携のための高可用性 & ディザスタリカバリ
ノード障害、メンテナンスウィンドウ、インフラストラクチャイベントが発生しても、EDI とマネージドファイル転送を止めません。クラスター化された Arc インスタンス、一元化されたログ、ファーム全体で一貫した処理を実現します。
ロードバランスクラスタリング · 共有アプリケーションデータ + 共有監査ログ · EDI の信頼性を支える設計
レジリエンス
EDI チームが安心して任せられる運用レジリエンス
高可用性とディザスタリカバリは、連携チームが最も大切にしている要素 — 予測可能な処理、完全な監査証跡、フェイルオーバー時のスムーズな引き継ぎ — を守れてこそ意味があります。
障害が発生してもアップタイムを維持
同一サーバーファーム内の複数システムで Arc を実行し、その前にロードバランサーを配置してインバウンドトラフィックを分散します。ノードが利用できなくなった場合、正常なノードへトラフィックが自動的にルーティングされます。
複数ノードでも一つの監査証跡
各ノードが同じアプリケーションデータベースを使用するよう設定することで、トランザクション履歴、エラー、アクセスログが一元化されます。ワークロードがスケールアウトしても、監査やトラブルシューティングは常に一箇所で行えます。
一貫した処理動作
共有アプリケーションデータディレクトリを使用することで、各ノードが同じファイルを処理し、同じ設定を使用します。環境の拡大に伴う「特定のサーバーでは動いた」という設定のドリフトを防止します。
アーキテクチャ
Arc が実現する HA の仕組み
Arc は、2つの具体的な要件 — インバウンドトラフィックの分散と、すべてのノード間でのデータ＋ログの同期 — に注力することで、ロードバランスおよび高可用性デプロイメントをサポートします。
1
2
3
4
複数の Arc インストールの前にロードバランサーを配置
受信したパートナー接続がサーバーファーム全体にルーティングされます。ヘルスチェックにより Arc の受信エンドポイントが応答していることを検証し、正常なノードにのみトラフィックが送られます。
大量 EDI の場合：トランザクション量やリソース上限（CPU/RAM/ディスク/ネットワーク）に達した場合、単一エンドポイントの負荷を上げるよりも、水平スケーリングの方が効率的です。
クラスター全体で同じアプリケーションデータベースを共有
Arc はトランザクション履歴やエラーをデータベースに記録します。クラスター構成では、すべてのノードが同じアプリケーションデータベースを参照するため、運用の可視性と監査性が完全かつ一貫して維持されます。
同じアプリケーションデータディレクトリを共有
Arc は設定とアプリケーションデータをデータディレクトリに保存します。クラスタリングでは、各ノードが同じディレクトリを使用することで、一貫した設定と共有処理ロケーションを確保します。
ロック機構で二重処理を防止
Arc はロックを使用して、複数インスタンスが互いに干渉したり、同じファイルを二重に処理したりすることを防ぎます。クラスター環境でのスループットと正確性の維持に不可欠です。
Arc では、ファイルシステムのレイテンシがロック効率に影響する可能性がある、複数サーバーファームにまたがるクラスタリングは推奨していません。
機能
HA & DR 対応の EDI 運用を支える主要機能
運用モデルをゼロから再構築することなく、「止まらない」B2B 連携を設計するためのビルディングブロックです。
1つのシステムのように動作するクラスター化された Arc ノード
適切に構成されたクラスターでは、Arc ノードは設定を共有し、同じディスクロケーションへのデータ処理を行い、同じデータベーステーブルに書き込みます。クラスター全体が1つの Arc インスタンスのように動作します。
スケールとフェイルオーバーのためのロードバランシング
ロードバランサーを使用して、Arc ノード間でインバウンドトラフィックを分散します。個々のノードに障害が発生した場合やメンテナンスのためにオフラインになった場合にも、水平スケーリングと高可用性の両方を実現します。
監査性を確保する一元化されたログ
共有アプリケーションデータベースにより、トランザクションステータス、エラー履歴、アクセスログが統合されます。トラブルシューティング、コンプライアンスの証跡、運用レポートがシンプルになります。
共有設定とパートナーアーティファクト
共有アプリケーションディレクトリを使用することで、パートナー設定と運用アーティファクトがノード間で一貫して維持されます。設定のドリフトを抑え、インシデント発生時の予測可能な対応を支えます。
ディザスタリカバリ
アップタイムだけでなく、ディザスタリカバリも見据えた設計
クラスタリングはアプリケーション層の単一障害点を排除します。完全な DR 体制には、共有依存リソース（ファイルストレージとデータベース）自体も高可用性を確保する必要があります。
単一障害点の排除
ロードバランサーの背後に複数の Arc ノードを配置することで、サーバー障害が EDI 障害にならないようにします。
共有サービスも HA 化
Arc を共有ファイルロケーションと共有データベースに接続し、それらのサービス自体も HA 対応（クラスター化されたファイルサービスやデータベース HA など）にすることで、弱点を残しません。
インシデント時の運用明確性
一元化されたログとノード間の一貫した設定により、プレッシャー下での不確実性を軽減します。チームはより迅速に診断・封じ込め・復旧が可能になります。
FAQ
高可用性 & ディザスタリカバリ
-
ロードバランシング用ですか？それとも高可用性用ですか？
どちらにも対応しています。ロードバランシングはスループット向上のためにトラフィックを分散し、高可用性は障害時に正常なノードへトラフィックをルーティングします。アーキテクチャの基盤は同じで、複数の Arc インストール、ロードバランサー、共有状態（データ＋ログ）で構成されます。
-
クラスター内でのファイルの二重処理はどう防止しますか？
Arc はロックを使用して、複数のインスタンスが互いに干渉したり、同じファイルを二重に処理したりすることを防ぎます。共有アプリケーションディレクトリへのアクセスにより、ノード間でロックが確実に適用されます。
-
ノード間で何を共有すべきですか？
クラスタリングでは、各ノードが同じアプリケーションデータベース（トランザクション/エラー/アクセスのログ用）と同じアプリケーションデータディレクトリ（設定とアプリケーションデータ用）を使用するよう設定します。
-
どこから始めればよいですか？
HA チュートリアルを参考に、実践的なサーバーファーム＋ロードバランサー構成を導入し、ノード間で共有アプリケーションディレクトリとデータベースを設定してみてください。