第1回:HULFT-HUBの必要性

OrangeLab. 運営チーム
作成日時: - 更新日時:
Avatar
複数のHULFTを運用管理している担当者が何故こうも「HULFT-HUB」の導入を望むのか?
これから数回に渡り、「HULFT-HUB」の概要とその魅力を伝えます!

はじめに

はじめまして、HULFT Orange Lab.運営チームの高橋です。

「HULFTは詳しいよ!」という人でも、「HULFT-HUBも任せといて!」と言える人は意外と少ないのではないでしょうか?

そんな人に「HULFT-HUBも知ってるよ!」と言えるだけの知識をつけて頂きたく、これから数回に渡り、実際の活用シーンを交えながらHULFT-HUBのご紹介をします。

HULFTにも課題はある

突然ですが、HULFTの課題をご存知ですか?

質実剛健すぎて、面白味がない?
ミドルウェアなので、ITに関わっていない人に説明するとき困る?

それらも正解と言えば正解ですが(笑)、それは多数のHULFTを運用管理してみると分かります。

そうです、HULFTが増えすぎると、その管理が煩雑になってしまうのです。
(HULFTを信頼して、愛して(?)、たくさん導入している人こそ、この弱点に気付きやすいのが皮肉ですが…。)
当然と言えば当然の課題ですが、これ、結構深刻です。

HULFTはピアツーピア型の転送方式なので、転送するには送信元と受信元それぞれにモジュールが必要です。
ということは、何十、何百もの拠点をHULFTで連携している場合、その拠点と同じ数のHULFTが存在するということです。
なおかつ、ネットワークがメッシュ状になっていて、それぞれの拠点毎に複数の連携が存在すると、その全容を把握するだけでも一苦労です。

エラー復旧に時間が掛かってしまう



そんな状態で、ある拠点から「ファイルが届いてないよー」という電話が掛かってきたら!
想像するだけでも、「大変だ!」となりますネ!

あなたが運用管理担当者だとしたら、まずは、エラーが「どこ」で起こっているかを調査します。
電話が掛かってきた拠点のHULFTをHULFT-Managerで覗きに行って、転送履歴を確認します。

すると、昨日のログにも、今日のログにもエラーがない?

その拠点のジョブフローを引っ張り出してきて、しばらく睨めっこしたあなたは、そもそも転送自体が実施されていないことに気が付きます。
よくよく調べてみると、ファイル加工などしながらバケツリレーしているケースで、電話が掛かってきたのは、その最後の拠点だったんですね。
その拠点としては、そもそもファイルが転送元に届いていないから、転送自体が行われていない、と。
で、そのバケツリレーを繋げなかった原因となった拠点はエラーが起きていることに気付いていないから電話がない、と。

経験されている人なら分かると思いますが、ここまで調べるだけで結構な時間が掛かります。
その後に原因を取り除き、再試行しても問題ないか検証した上で再試行する訳ですから、最終的に復旧するまでに早くて半日、遅くて一日かかってしまうなんていうこともあります。

それだけに初動で原因特定できるか否かが、早期復旧の可否に大きく影響するのです。

HULFTの課題はHULFT-HUBで解決できる!

他にもHULFT単独では解決が難しい、下記のような課題もあります。
  • セキュリティルール上、社外ネットワークと直接接続できない
  • 受け手側のサーバが停止している場合でもファイル転送を行いたい
  • HULFTがたくさんあり、外字コードの管理が煩雑になってしまった
そのような課題を解決し、さらに高度な運用を実現するべく誕生した製品がHULFT-HUBとなります。
次回は、いよいよ「HULFT-HUBで実現できること」をご紹介いたします。
この記事は役に立ちましたか?
2人中2人がこの記事が役に立ったと言っています

コメント