HULFT-HUBクラスタ対応版を管理するクラスタソフトをAWSサービスで代用してみた

この記事は、 セゾンテクノロジー Advent Calendar 2025 の記事です。
シリーズ2では HULFT・DataSpider の開発メンバーによる投稿をお届けします🕊️
23日目はHULFT-HUBの開発者が担当します🙌

はじめに

HULFT-HUB を冗長構成（Active / Standby）で運用する場合、HULFT-HUBクラスタ対応版があり、クラスタソフトと連携して利用することが想定されます。
あるPJの中でHULFT-HUBはクラウド上でクラスタソフトを使わずにクラウドサービスを構成することで、クラスタ構成をとれるのかという話が上がりました。そこではこの構成であれば出来るはずとなりました。出来るはずで終わらせたくないなと思い、AWSサービスの構築の実践もかねて実際に試してみることにしました。

前提条件・ゴール

前提条件

• HULFT-HUB を EC2 上で稼働
• Active / Standby 構成（各 HULFT-HUB 1台）
• クラスタソフトは使用しない

ゴール

• HULFT-HUBのヘルスチェックの実現
• Active 異常時に Standby へ切替できる

採用した AWS サービス

今回の構成では以下を利用しています。

役割	AWS サービス
サーバ	EC2
監視	Amazon CloudWatch
制御	AWS Lambda
EC2 内実行	SSM Run Command

全体的な流れ

実装

EC2の設定

管理するHUB Serverとして運用系ノード(Active)と待機系ノード(Standby)の2台を用意しました。
今回は実験用ということで同じサーバ内に2台用意しています。

外部から実行されるスクリプト配置

Lambda から SSM 経由でEC2上に起動中のHULFT-HUBの操作を実行するため、スクリプトは以下に配置しました。

/usr/local/bin/hub_start.sh
/usr/local/bin/hub_stop.sh
/usr/local/bin/hub_healthcheck.sh

hub_start.sh, hub_stop.shは環境変数を設定して、HULFT-HUBを起動、停止するスクリプトです。
そして、hub_healthcheck.shでHUBの運用系ノード(Active)の生存確認とCloudWatchへメトリクスを送信します。
中身としては以下のように設定しました。

#!/bin/bash
HULHUBETC={共有ディレクトリのパス}/etc
export HULHUBETC
HULHUBEXE={運用系ノードへのパス}/bin
export HULHUBEXE

$HULHUBEXE/hubcluster -status
RESULT=$?

aws cloudwatch put-metric-data \
  --namespace MyApp \
  --metric-name Alive \
  --value $([ $RESULT -eq 0 ] && echo 0 || echo 1)

hubcluster -statusはHUB Serverが稼動中(全デーモンの生存中)であるかどうかを確認するコマンドとして提供されています。この結果を利用して、HUB Serverが生存していることを確認します。
稼働中の場合は0、異常がある場合は0以外が返ってくるので、Amazon CloudWatchへ0(稼働中の場合は0, 0以外(異常発生)の場合は1を送信します。
このhub_healthcheck.shをcronで1分ごとに実行し、Amazon CloudWatchからHUB Serverが起動中であることの監視をします。

Amazon CloudWatchの設定

Amazon CloudWatchはリソースとアプリケーションの様々な値をモニタリングできるサービスとなります。今回はHUB Serverの運用系ノードが稼働中であることの監視を行います。
EC2で1分ごとにHUB Serverの状態を送信する設定を行ったので、CloudWatchのコンソールのメトリクスから値を確認することが出来るようになりました。

途中からkillでHUB Serverを落としてみた結果、正常時は0であり、異常時は1の値が取得できていることが分かります。
このメトリクスを利用して、アラームを設定し、異常値を検知したとき、AWS Lambdaを呼び出すように設定をします。
以下のように設定をしました。

値が0よりも大きい場合(値が1の場合)が5分間に2回あった場合というのを条件としました。
またEC2が落ちて生存確認結果を送ることが出来なくなり、結果が分からなくなった場合の判断として、欠損データの処理は欠損データを不正として処理に設定しました。つまり、データが送られてきていない場合は異常と判断するとしています。
そして、呼び出すAWS Lambdaとして、次に設定するAWS Lambdaを設定しました。
このアラームは以下の様に確認することができます。

値1を5分間に2回以上確認した場合、図のようにアラート状態となります。
正常からアラート状態に変化したとき、AWS Lambdaで設定された関数が実行されます。

AWS Lambdaの設定

AWS Lambdaではサーバーの管理・運用なしにコード（関数）を実行できるAWSのサーバーレスコンピューティングサービスです。
今回はこれを使用して、異常発生を検知した後、HUB Serverの待機系ノード(Standby)を起動するという操作を行います。
以下のコードを設定しました。

import boto3
import os

ssm = boto3.client('ssm')

ACTIVE = os.environ["ACTIVE_ID"]
STANDBY = os.environ["STANDBY_ID"]

def handler(event, context):
    ssm.send_command(
        InstanceIds=[ACTIVE],
        DocumentName="AWS-RunShellScript",
        Parameters={"commands": ["/usr/local/bin/hub-stop.sh"]}
    )

    ssm.send_command(
            InstanceIds=[STANDBY],
        DocumentName="AWS-RunShellScript",
        Parameters={"commands": ["/usr/local/bin/hub-start.sh"]}
    )

流れとしては

• 運用系ノード(Active)、待機系ノード(Standby)のEC2サーバのインスタンスIDを取得し、HUB Serverが配置されているサーバを特定する
• 運用系ノード(Active)を完全停止させるために停止スクリプト(hub-stop.sh)を実行する
• 待機系ノード(Standby)を起動するために停止スクリプト(hub-start.sh)を実行する
  という流れです。
  EC2上の操作を行うためにSSM RunCommandというサービスを利用しています。
  これにより、運用系ノード(Active)を停止し、待機系ノード(Standby)を起動することを実現しています。

結果

実装後、HUB Serverをkillで強制停止したとき、CloudWatchで確認してみると

以上のように、アラーム状態になると、今回実装したlambdaが実行され、待機系ノード(Standby)が起動されたことで、生存確認の結果も正常に戻ったことを確認できました。

さいごに

今回は同一サーバでActive-Standbyを起動してたり、Active-Standbyの切り替えの排他制御をしていなかったり、解決していない課題はありますが、クラスタソフトの機能の中で、生存監視からそれに基づいてActiveとStandbyを切り替える処理は実装することが出来ました。実際に実装してみるとやはり最初は想像していなかった詰まる部分が多く(サービスの理解不足や権限回り)実際に手を動かしてみることの大切さを感じました。
また気になったものがあれば、すぐ手を動かしてみるというのを実践していきたいと思います。