この記事は、 セゾンテクノロジー Advent Calendar 2025 の記事です。
シリーズ2では HULFT・DataSpider の開発メンバーによる投稿をお届けします🕊️
4日目はHULFT10 for Container Servicesの開発者が担当します🙌
はじめに
HULFT10 for Container Services は、ファイル転送ミドルウェア「HULFT」のコンテナ版で、Amazon ECS で動作するクラウドネイティブなソリューションです。従来のオンプレミス環境でのファイル転送機能を、AWS のマネージドサービスを活用してクラウド上で実現できます。
本記事では、HULFT10 for Container Services をマルチAZ構成に対応させる際に検討・実装した内容について、技術的な観点から紹介します。
マルチAZ対応の背景
HULFT10 for Container Services は、当初「まずは小さく作ろう」という開発方針のもと、シングルAZ構成での CloudFormationテンプレートから提供を開始しました。コンテナレベルでの冗長性は考慮していたものの、サービスレベルでの冗長性は将来課題としていました。
ありがたいことに、ミッションクリティカルな業務での利用を検討されているお客様から高可用性に関するご要望をいただき、マルチAZ構成に対応した CloudFormationテンプレートの開発に着手することになりました。
システム構成の概要
HULFT10 for Container Services は以下のコンポーネントで構成されています。
- 転送コンテナ：外部の HULFT との通信を担当
- 管理コンテナ：設定値や履歴の管理を実施
ネットワーク構成の設計
マルチAZ 対応では、すべてのネットワークリソースを2つの AZ に展開する必要があります。
主要な変更点
- サブネット：ECS、ALB、NLB、RDS 等、すべてのリソースのサブネットをそれぞれ 2AZ 分作成（サブネット数 11→16）
- NAT Gateway：各AZ に 1台ずつ配置
- VPCエンドポイント：インターフェースエンドポイントを 2AZ に展開
ルーティング設計の考慮事項
VPCエンドポイントは名前解決により自動的に最適な経路が選択されるため、特別なルーティング設定は不要です。
一方、NAT Gateway は明示的なルートテーブル設定が必要です。
AZ-A のプライベートサブネット → AZ-A の NAT Gateway
AZ-B のプライベートサブネット → AZ-B の NAT Gateway
この設定により、各AZ のリソースが同じ AZ内の NAT Gateway を使用し、AZ障害時の影響を局所化できます。
2025年11月に発表されたリージョナルNAT Gateway を使用すると、マルチAZ に NAT Gateway を導入した際のサブネット、ルートテーブルの管理がシンプルになります。開発前に発表されていれば、ぜひ使用を検討したかったです。
コストは従来と同等のため、CloudFormationテンプレートを使用して導入する場合は影響ありません。
ECS の構成
サブネット配置の変更
ECS のサブネット設定を 2つの AZ に拡張し、コンテナが複数の AZ にデプロイされるように構成しました。これにより、単一AZ障害時でもサービス継続が可能になります。
可用性ゾーンバランシング
AvailabilityZoneRebalancing を有効化することで、以下の効果を実現しています。
- コンテナデプロイ先 Fargate の AZ間での均等分散
- 障害発生時の自動的な負荷再分散
- サービス継続性の向上
コンテナ配置戦略
各コンテナタイプの配置は以下の方針で決定しました。
| コンテナ種別 | デフォルト起動数 | 配置方針 |
|---|---|---|
| 転送コンテナ | 2台 | 可用性重視（外部連携に必須） |
| 管理コンテナ | 1台 | コスト重視（ライセンス料金考慮） |
転送コンテナ は外部 HULFT からの通信に応答する必要があるため、障害時の迅速な復旧を重視して2台構成としています。
管理コンテナ は起動台数に応じてライセンス料金が発生するため、1台構成で運用しています。コンテナの初期化時間は短く（通常1分未満）、障害時でも迅速に復旧可能です。
ロードバランサーの構成
Application Load Balancer（ALB）
ALB は仕様上、マルチAZ構成でのみ動作するため、基本的な冗長性は既に確保されていました。マルチAZ対応では以下の設定を追加しています。
ARC（Application Recovery Controller）対応
LoadBalancerAttributes:
- Key: zonal_shift.config.enabled
Value: "true"
この設定により、ARC を使用したゾーンシフト機能が利用可能になります。
📖 参考：ARC とゾーンシフトの詳細はAWS公式ドキュメントをご確認ください。
基本的には障害発生時は AWS のマネージドなフェイルオーバーに任せる方針ですが、いわゆるグレー障害の発生時にユーザーが通信を制御できるようにするため、ARCの設定を有効にしました。
クロスゾーン負荷分散の判断
NLB との動作統一を検討し、クロスゾーン負荷分散の無効化も検討しましたが、以下の検討結果により現状維持としました。
| 項目 | 検討事項 | 判断 |
|---|---|---|
| デフォルト動作 | ALB ではクロスゾーン負荷分散が標準で有効 | ✅ 現状維持 |
| 既存動作との整合性 | シングルAZ構成でも既に AZ間通信が発生 | ✅ 影響なし |
| コスト | ALB の AZ間通信は課金対象外 | ✅ コスト増なし |
Network Load Balancer（NLB）
NLB では2つの AZ のサブネットにそれぞれノードを作成し、冗長性を確保しています。
基本設定
Subnets:
- !Ref PrivateSubnetAZA
- !Ref PrivateSubnetAZB
LoadBalancerAttributes:
- Key: zonal_shift.config.enabled
Value: "true"
クロスゾーン負荷分散の検討
冗長性向上のため、クロスゾーン負荷分散の有効化を検討しましたが、以下の検討結果により無効のままとしました。
| 項目 | 検討事項 | 判断 |
|---|---|---|
| コスト | AZ間通信で課金が発生 | ❌ コスト影響大 |
| レイテンシ | AZ間通信でレイテンシが増加 | ❌ 性能影響が懸念 |
| 可用性 | 一方の AZ障害時も継続可能 | ✅ メリットあり |
ファイル転送という用途特性上、コストとパフォーマンスへの影響を重視し、クロスゾーン負荷分散は無効としています。AZ障害時は該当AZのターゲットIPが自動的に Route 53 の応答から除外されるため、可用性は確保されます。
Amazon RDS（Aurora）の構成
マルチAZ デプロイメント
データベースの高可用性確保のため、Amazon Aurora クラスターを2つのAZに展開しています。
構成概要
Aurora クラスター
├── プライマリインスタンス（AZ-A）
└── リードレプリカ（AZ-B）
デプロイ時にどちらの AZ をプライマリインスタンスにするかは制御できませんでした。
制御したい場合は、起動後に手動フェイルオーバーを実施することで、切り替えることができます。
自動フェイルオーバー機能
障害発生時は以下のように自動フェイルオーバーが実行されます。
| 障害パターン | フェイルオーバー時間 | 動作 |
|---|---|---|
| インスタンス障害 | 60秒未満 | リードレプリカがプライマリに昇格 |
| AZ障害 | 60秒未満 | リードレプリカがプライマリに昇格 |
📖 参考：詳細はAmazon Aurora の高可用性をご確認ください。
構成検討の経緯
代替案：シングルインスタンス構成
コスト削減のため、1台構成での運用も検討しましたが、以下の検討結果により2台構成を採用しました。
| 項目 | シングル構成 | マルチ構成 | 判断 |
|---|---|---|---|
| インスタンス障害時 | 10分未満で復旧 | 60秒未満で復旧 | ✅ 大幅な時間短縮 |
| AZ障害時 | 手動復旧が必要 | 自動フェイルオーバー | ✅ 運用負荷軽減 |
| コスト | 1台分 | 2台分 | ❌ 増加するがSLA重視 |
ミッションクリティカルな用途を考慮し、可用性を優先した構成としています。
フェイルオーバー時の接続対応
Aurora のフェイルオーバー時に発生する特殊なケースに対応しました。
問題：フェイルオーバー中、リードレプリカがプライマリに昇格する前に管理コンテナが接続すると、読み込みは可能だが書き込みが失敗する状態に。
# エラー内容
Error 1792 (25006): Cannot execute statement in a READ ONLY transaction.
-- エラー内容から判断した、この状態の再現クエリ
SET GLOBAL TRANSACTION READ ONLY;
対策：書き込み失敗を検出した場合、自動的に再接続して書き込み可能なトランザクションを取得するようにコンテナの動作を修正しました。
AWS FISを活用した検証
障害シミュレーションテスト
マルチAZ構成の動作検証には AWS Fault Injection Simulator（FIS） を使用しました。FIS により、実際の障害状況を安全に再現し、システムの耐障害性を検証できます。
検証シナリオ
検証に使用したシナリオは製品マニュアルで公開しています。
📖 AWS Fault Injection Service (FIS)による動作検証
これらのテストにより、想定したシナリオでは5分以内にフェイルオーバーが動作することを確認できました。
コスト影響
コストが増加したリソース
マルチAZ化により以下のリソースでコストが増加します。
- ECS：転送コンテナの起動台数が2台に増加（Fargate起動台数が増加）
- NAT Gateway：各AZに1台ずつ配置（1台→2台）
- VPCエンドポイント：インターフェースエンドポイントのノードを各AZ に作成（サービス毎 1→2）
- RDS（Aurora）：DBインスタンスが2台構成
コストに変化なしのリソース
以下のリソースはマルチAZ化してもコストに影響しません。
- ALB/NLB：ノード数に依存しない料金体系
- VPC/サブネット：追加課金なし
NLB のクロスゾーン負荷分散を有効化した場合、AZ間通信による追加コストが発生するため注意が必要です。本構成では無効化してコストを抑制しています。
固定IPアドレスでの接続課題
背景
HULFT10 for Container Services は、オンプレミス環境との連携で使用されるケースが多く、特にレガシー環境との接続に利用されます。
クラウド環境では DNS による名前解決が一般的ですが、長年運用されているレガシーシステムでは、設定変更の制約や運用上の理由から固定IPアドレスでの接続が必要となる場合があります。
接続要件と課題
想定される接続環境
- 接続元：z/OSやIBM iなどのレガシーシステム
- 接続先：AWS上のNLB
- 要求：固定IPアドレスでの接続
技術的な課題
| 項目 | AWS標準 | レガシー環境の要求 |
|---|---|---|
| 名前解決 | Route 53による動的解決 | 固定IP設定が前提 |
| 冗長化 | DNS切り替えベース | VIPベース |
| 設定変更 | 柔軟に対応可能 | 設定変更が困難 |
検討中の対応策
AWS接続でVIP（仮想IP）に相当する動作を実現する方法を検討中です。レガシー環境に新たなDNS設定を導入することが困難な場合の代替手段として、アプリケーション側でできることがないか、解決策を模索しています。
まとめ
HULFT10 for Container ServicesのマルチAZ対応では、以下の設計で高可用性の確保を実装しました。
- ネットワーク層：全リソースを2AZ に展開、NAT Gateway や VPCエンドポイントも冗長化
- アプリケーション層：ECS でのコンテナデプロイ冗長化、AZバランシング有効化
- データ層：Aurora のマルチAZ構成で自動フェイルオーバー
このマルチAZ対応により、HULFT10 for Container Servicesはエンタープライズ環境で求められる高可用性を実現し、ミッションクリティカルな業務での安心した利用が可能になりました。
今後の展望
マルチリージョン対応
さらなる高可用性実現のため、マルチリージョン構成も検討していきたいと考えています。
課題
現在利用している AWS Marketplace Metering API が大阪リージョンに対応していないため、大阪リージョンへの展開が難しい状態です。
AWS様、大阪リージョンでのAPI対応お待ちしております！🙏
終わりに
HULFT10 for Container Services は AWS の Marketplace で公開中です。ぜひ触ってみてください！