HULFTのコンテナ/Fargate化：EC2起動タイプとFargate起動タイプの選び方

「HULFTをコンテナで動かしたい」——そう相談を受けたとき、最初に決めるべきはツールの使い方ではなく、Amazon ECSの起動タイプです。HULFT10 for Container Servicesには、EC2ノードを持ちEFSでファイルを共有する「EC2起動タイプ」と、サーバレスでストレージをS3に置く「Fargate起動タイプ」の2つがあり、両者は永続化の考え方が根本から異なります。本記事では、構成の違いと選び方、そして検証段階で先に潰しておくべき落とし穴を、オンプレミス〜AWSのHULFT連携を手掛けてきた実務の視点で整理します。

01なぜいまHULFTを「コンテナで」動かすのか

HULFT10 for Container Servicesを使うと、HULFTをAmazon ECS上のコンテナとして運用できます。EC2を1台立ててHULFTをインストールする従来のスタンドアロン構成と比べ、転送負荷に応じたスケール、障害時の自動復旧、インフラのコード化がしやすくなるのが利点です。利用にはAWS Marketplaceでのサブスクライブが必要で、既存のオンプレミス〜AWS間ファイル連携を、より運用しやすい形へ寄せていけます。まず押さえるべきは、この製品にAmazon ECSの「EC2起動タイプ」と「Fargate起動タイプ」という2つの土台があり、選択によって永続化ストレージの設計が変わるという点です。

02全体構成：管理コンテナ＋転送コンテナ

HULFT10 for Container Servicesは、管理コンテナ（hulft-control-container）と転送コンテナ（hulft-transfer-container）の2種類で構成されます。管理情報や転送履歴はAurora MySQLに保持し、パスワードなどの資格情報はSecrets Manager、外部・内部トラフィックの振り分けはALB、オンプレミスのHULFTとの接続はNLBが担います。周辺ではACM、CloudWatch、Route 53、IAM、NAT Gateway、Auto Scaling Groupなどを組み合わせます。転送負荷に応じて転送コンテナを自動で起動し、障害が起きたコンテナは再起動される仕組みで、転送の前後に任意のWeb APIを呼び出すこともできます。

現場のコツ：管理コンテナは「頭脳」、転送コンテナは「手足」と割り切って考えると設計が整理できます。スケールで台数が増減するのは基本的に転送コンテナ側です。管理情報の実体がAurora MySQLにある以上、コンテナ自体は極力ステートレスに寄せ、DBとストレージ（後述）に状態を逃がしておくのが安定運用の勘所です。

03EC2起動タイプ：EFS＋S3、起動時にEFSをマウント

EC2起動タイプは、ECSのタスクを自前のEC2ノード上で動かす構成です。ストレージはEFSとS3の二層で、EC2の起動時にEFSをマウントし、複数の転送コンテナ間で共有するファイルの格納先としてEFSを使います。監査ログはS3に出力します。EC2ノードを自分で保有するため、ノードの増減はAuto Scaling Groupで管理します。「どの転送コンテナからも同じ共有ファイルを参照したい」という要件に、EFSの共有ファイルシステムが自然に噛み合うのがこのタイプの持ち味です。

04Fargate起動タイプ：v10.1.0〜、S3・サーバレス・CloudFormation

Fargate起動タイプは、バージョン10.1.0（2024年6月）で対応しました。EC2ノードを保有しないサーバレス構成で、ストレージは標準構成ではS3を前提とします（Fargateも別途ECSからEFSをマウントできるよう設定すればEFSを利用できます）。配備はCloudFormationテンプレートで行い、OSやノードのパッチ運用を持たずに済むのが大きな魅力です。転送コンテナのスケールもFargate側に委ねられるため、運用チームは「サーバの面倒を見る」作業から解放されます。ここで重要なのは、EC2起動タイプの共有ストレージがEFSだったのに対し、Fargate起動タイプの永続化はS3が中心になるという、設計思想の切り替えです。

05どちらを選ぶか：永続化モデルで分かれる

選定の軸は突き詰めると「ノード運用を持ちたいか」と「永続化をどのストレージで設計するか」の2点に集約されます。サーバレスで運用負荷を極小化したい、CloudFormationでまるごとコード化したいならFargate起動タイプ。EFSでの共有を前提とした既存の連携設計を踏襲したい、あるいはEC2レイヤーでのきめ細かい制御が要るならEC2起動タイプが向きます。共通基盤（Aurora MySQL・Secrets Manager・ALB／NLB）は同じでも、ファイルの置き場所の考え方が根本から違う——ここを最初に決めるのが失敗しないコツです。

EC2起動タイプ（EFSで共有＋S3に監査ログ）とFargate起動タイプ（サーバレス／永続化は標準でS3、EFSは追加設定で利用可）の構成比較。共通基盤は同じでも、永続化ストレージの考え方が分かれる。

06落とし穴：Fargate版は既定でS3前提（EFSは要追加設定）

コンテナ化の設計でつまずきやすいのが、まさにこの永続化ストレージです。私たちはPoC・検証の段階で、Fargate起動タイプは標準構成ではEC2起動タイプのようなEFS共有を前提とせず、S3ベースの永続化になること（EFSを使うにはECSからマウントできるよう別途設定が必要なこと）を先に確認しました。当初は「EFSに共有ファイルを置く」前提で描いていた図を、本番の設計に入る前にS3ベースへ見直し、あわせてコンテナがステートレスに動くようセッション（状態）の持たせ方も整理しました。検証で先に踏み抜いておいたことで、本番では永続化まわりの手戻りをゼロにでき、当社が続けている重大障害ゼロを維持しています。

現場のコツ：EBS／EFS／S3を「集配信先」として安易に同列に並べないでください。スタンドアロン（非コンテナ）のHULFTをEC2で動かす場合、集配信ファイルの格納先は基本的にインスタンスのローカルディスク＝EBSです。EFSを集配信ターゲットにするにはHULFTの「ネットワークファイル対応」機能が前提で、NFS上のバイト範囲ロックによる排他制御やクライアント属性キャッシュの無効化といった条件があり、単一ファイルへの複数プロセス・複数インスタンスからの同時アクセスは避ける必要があります。EFSが「標準構成」に登場するのはコンテナ版のEC2起動タイプ（複数コンテナ間の共有）であり、Fargate起動タイプは既定ではS3です（FargateもプラットフォームバージョンPV1.4.0以降EFSに対応しており、別途ECSからEFSをマウントする設定を加えればEFSを利用できます）。まず「スタンドアロンEC2＝EBS／コンテナのEC2起動タイプ＝EFS共有／Fargate起動タイプ＝既定はS3（EFSは要追加設定）」と分けて覚えるのが安全です。

07ライセンスとオンプレミス接続

HULFT10 for Container Servicesの利用にはAWS Marketplaceでのサブスクライブが必要です。オンプレミス側の既存HULFTとの接続はNLBを介して行い、経路はVPNやDirect Connectで閉域化するのが定石です。これにより、オンプレミスに残したHULFT資産や既存の集配信定義はそのまま活かしつつ、AWS側だけをコンテナ化する、という段階的な移行が取りやすくなります。当社では、小規模で低コストな構成から最大規模まで、大手飲料メーカー様や大手冷凍倉庫事業者様、中堅の営業専門企業様といった幅広い規模のオンプレミス〜AWS連携を、匿名化してご紹介できる範囲で手掛けてきました。

08Kubernetesという選択肢とまとめ

ECSではなくKubernetesを基盤に使いたい場合は、HULFT10 for Container Platformという選択肢があります。Kubernetes上で動作し、Red Hat OpenShiftに対応（Red Hat Operator認定）しています。管理コンテナ＋転送コンテナという考え方は共通で、基盤の思想に合わせて選べます。まとめると、HULFTのコンテナ／Fargate化における起動タイプ選定は、そのまま永続化モデルの選定です。EC2起動タイプならEFS共有＋S3、Fargate起動タイプなら標準はS3（EFSは追加設定で利用可）——この違いをPoC・検証で早期に固め、永続化とセッション設計を先に潰しておくことが、本番での事故を未然に防ぐ最短ルートになります。