技術者のためのHULFT-HUB入門【HULFT-HUBの基本的な仕組み】（2/7）

# はじめに
こんにちは、よろず相談担当 すぎもんです。

技術者のためのHULFT-HUB入門シリーズは全7回を予定しており、今回は第2回目となりHULFT-HUBの基本的な仕組み、アーキテクチャを中心にご紹介します。少しマニアックな内容になるかもしれませんが、HULFT-HUBの正体がよくわかると思います。




なお、本シリーズの記事はHULFTの基本的な使い方（設定方法や運用方法）をご存知な方向けに書いていますので、HULFTを触ったことが無い方は一部理解しにくい点がありますがご容赦ください。

## HULFT-HUBの基本的なアーキテクチャ
### アーキテクチャから考えよう
なぜアーキテクチャを最初の押さえるのかというと、製品の設計思想や成り立ちが見えてくるからです。これがわかると、多数ある機能のうちどれが幹の部分で、どれが枝葉の部分かが理解できてきます。製品を利用する場合は、一般的には幹にあたる機能をベースに使うと、使い勝手・パフォーマンス・品質が良いので満足度が高くなります。一方で、枝葉にあたる機能に期待しすぎると、使い勝手が悪かったり、期待した効果が得られにくく満足度が低くなることがあります。
自動車に例えると、市内の買い物などが主な利用用途だと軽自動車やコンパクトカーが小回りも効き維持費も安いからマッチすると思います。この用途でキャンピングカーを購入すると、小回りが利かず運転しにくいし維持費用も高いので満足度が下がると思います。キャンピングカーは山や海などレジャーに出かけたときに真価を発揮するので、街中での性能はそんなに期待しませんよね？
つまり、HULFT-HUBの設計思想や仕組みを理解しておくと、HULFT-HUBはどのように使って欲しい製品なのか、どのような使い方をすると効果がでやすいのかがわかってくると思います。

### HULFT-HUBの最もコアな仕組みとは
結論からいうと、**HULFT-HUBはプロキシサーバ** です。Webブラウザなどに設定するプロキシ（HTTP PROXY）と全く同じでHULFT版のプロキシサーバです。
下図がWindowsのプロキシの設定イメージです。皆さんご存知のようにWebブラウザで特定のURLにアクセスする場合、Webブラウザはプロキシサーバだけにアクセスし実際にはプロキシサーバがURL先のサーバとの通信を代理で行ってくれます。
![010_PROXY（Win）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/2d4c9b87-ffcc-f041-9ab0-c6373c6a9d4d.png)
下図がHULFTの詳細ホスト情報のプロキシの設定イメージです。
![011_PROXY（HULFT）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/4d58fdb1-7d9d-4ef8-2e02-ded73c1d19e8.png)
HULFTをお使いの方でも詳細ホスト情報の**PROXYサーバ**タブを使ったことのない方が多いと思います。ここにHULFT-HUBのIPアドレス（またはホスト名）とポート番号を設定すると、HOST-Aに配信するときにHULFT-HUBを中継してファイルを転送される、というのが最もベースとなるHULFT-HUBの仕組みになります。

### 設定情報とプロキシ動作の仕組み
下図は、HULFT-HUBがプロキシとして動作するために必要な最低限の設定情報と相関関係になります。要するに、HOST-A ⇒ HUB ⇒ HOST-B というファイル連携をするための設定情報になります。
![012_設定情報の相関関係（PROXY）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/0ddc7cc2-5935-4386-538a-61a6cf3971e1.png)

設定情報のポイントは、次の2つです。
* HULFT-HUBも自ホスト名とHUBポート番号を持つ。
* HUBには、中継元、中継先のHULFTホスト情報を事前に登録する必要がある。（これを「**収容クライアント**」と呼びます）

**収容クライアント** はHULFT-HUB特有の設定情報になります。この登録が無いとHULFT-HUBは見知らぬホストの中継を拒否します。
ここまで情報がそろうと、HULFT-HUBのプロキシとしての動作の仕組みが見えてきたと思います。HULFT-HUBは中継要求を受信したときの動作は次のようになります。
1. 要求元ホスト名をチェックする（収納クライアントとして存在するか？）
1. 転送先ホスト名をチェックする（収納クライアントとして存在するか？）
1. ルーティングする（ルーティング先は転送先の収納クライアントに定義されている「ホスト名＋集信ポートNo」）

以上が、HULFT-HUBの最もベースとなる動作になります。

## HULFT-HUBの機能の拡張
HULFT-HUBの機能はプロキシ機能をベースにしており、**HULFTの通信をHUBを中継させることでさらに利便性を高めよう** という趣旨で機能を充実させていくことになります。その大きなポイントが次の2つです。
* HUBで転送データを蓄積させたい
* HUBでルーティング先を制御したい

![013_設定情報の相関関係（転送情報）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/c5bd2c6f-97f8-ec1f-cb2f-44d4d650cba4.png)
こういった機能を追加するには、ファイルID単位にきめ細かい設定情報がHULFT-HUB上に追加で必要になります。これを **転送情報**(*1) と呼びます。HULFT-HUBでは、**転送元ホスト名＋ファイルID** の組み合わせをユニークなI/Fと識別し、このユニークなI/F単位で転送情報として定義します。
転送情報の主な項目は次の2つになります。
* 該当I/Fの蓄積方法を指定する
* 該当I/Fの転送要求を受けたときのルーティング先を指定する（複数宛先を指定すれば同報も可能）

このような仕組みで、単純にファイル転送を中継するだけでなく、中継タイミングでHULFT-HUBが追加処理を行うような付加機能が拡充されてきました。

::: note notice
**HULFT-HUBのポイント**
HULFTはユニークなI/FをファイルIDとして識別します。
HULFT-HUBはユニークなI/Fを配信元ホスト名＋ファイルIDの組み合わせで識別します。
この違いは、HULFTが自ホストが扱うI/Fだけを管理すれば良いのに対してHULFT-HUBは複数ホストのI/Fを統合的に管理する必要があるためです。ですから、異なるホストが同一のファイルIDを使っている場合でもHULFT-HUBは別々のI/Fとして識別して管理することができます。
:::

::: note warn
**注意ポイント**
*1 ここでは「転送情報」と呼びましたが、実際には4つの管理情報で構成されておりもう少し複雑です。HULFT-HUBの基本的な仕組みを理解しやすくするためにHULFT-HUBの転送関連の制御に関わる管理情報をまとめて「転送情報」として扱います。
:::

::: note warn
**注意ポイント**
ここまでは、HULFT-HUBの基本的な動作原理をわかりやすくするため「転送情報」が無い場合の動作をベースに説明してきました。ただし、特定の条件では「転送情報」が無い場合に注意が必要なケースもございます。特に注意するケースとして、
①HULFT8-HULFT7間の転送で暗号化する場合
②HULFT for MainframeまたはHULFT for IBMiをご利用でコード変換機能を利用する場合
詳細は、[HULFT-HUBマニュアル](https://www.hulft.com/help/ja-jp/HUB-V3/index.htm)の［HULFT-HUBの運用時の留意点］->［ファイル転送に関する留意点］->［転送情報が存在しない場合の留意点］をご覧ください。
:::

### なぜHULFT管理の機能が必要になったのか？
これまではHULFT-HUBの中継機能の基本的な仕組みについて解説してきましたが、HULFT-HUBのもう一つの大きな機能としてHULFT管理機能があります。一見、中継機能の管理機能は関係無いように見えますが、中継機能を拡充したことで各HULFTとHULFT-HUBの設定情報が増加し、またそれらの相関関係も複雑化したことで、個別に管理することが非常に困難になってきました。そこでHULFTとHULFT-HUBの設定をより簡単に管理する仕組みが必要になってきました。
![014_設定情報の相関関係（管理）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/8c0dde91-2f82-a537-9e08-b1c2d40748fd.png)
つまり、タイトルの「なぜHULFT管理の機能が必要？」の答えは、**複雑になったHULFTとHULFT-HUBの設定を簡単に実現するための手段としてHULFT管理の機能も不可欠となった**、ということになります。その手段＝実装方式について、これから解説していきます。

### HULFTとHULFT-HUBの設定を簡単にするHULFT-HUB Manager
HULFT-HUBでは、①配信側HULFT、②HULFT-HUB、③集信側HULFTの転送に関わる管理情報を一元管理できる仕組みを作りました。それがHULFT-HUB Managerの転送定義画面になります。転送定義画面は、I/F（配信側ホスト＋ファイルID）ごとに1画面で設定することができ、次の管理情報を**一括で登録できる**とともに、各設定情報の**相関関係の整合性についても保証**されます。
* ①配信側HULFT（配信管理情報、転送グループ情報、詳細ホスト情報）
* ②HULFT-HUB（転送情報）
* ③集信側HULFT（集信管理情報、転送グループ情報、詳細ホスト情報）
![015_MG（転送定義）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/a8b0c1a8-2c01-e04f-db1f-279fc9a54daf.png)

### 整合性を保つための手段としてHULFTの統合管理
HULFT-HUB Managerで3つ（①配信側HULFT、②HULFT-HUB、③集信側HULFT）のホストの管理情報の整合性を保証するには、**HULFT-HUB上にこれらの管理情報を全て保持しマスタ管理する**ことが実装上必要になりました。つまり、HULFT-HUB上に各HULFTとHULFT-HUB自身の管理情報をデータベースとして保持し、転送定義を作成するときに配信側と集信側の整合性をチェックしながら矛盾の無い**設定情報を自動生成**する仕組みがHULFT-HUB Managerの転送定義画面なのです。これを実現することで、複雑になったHULFTの管理情報を誰でも簡単に設定できるようにしました。
ただし、HULFT-HUB上にHULFT管理情報を全て保持しマスタ管理する必要性から、HULFTの管理方法を大きく変える必要が出てきました。これまでは、各HULFTを**ホスト単位で管理する**必要がありましたが、HULFT-HUB導入後はHULFT-HUB Managerから**全てのHULFTを統合管理する**ことが必須となります。
![016_HULFT管理アーキテクチャ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/d6a1bc5a-b6b6-d975-2888-3361302b930c.png)

::: note warn
**注意ポイント**
HULFT-HUB導入後は、**HULFTから管理情報を直接設定することは禁止**となります。理由は、HULFT-HUBとHULFTの管理情報に不整合が発生すると正常に転送処理が行えなくなるためです。ですから、HULFTからの設定変更した場合は動作保障はされなくなります。
:::

以上が、HULFT-HUBの基本であるプロキシ機能を拡張した結果、HULFT管理機能が不可欠になっていきましたが、HULFT管理が必須であればHULFT統合管理に便利な機能を拡充させるに越したことはありません。このような経緯でHULFT管理機能がHULFT-HUBの主要機能となり、HULFT管理に特化したグレード（Lグレード）も製品ラインナップとして提供されることになりました。


---
以上、いかがだったでしょうか？

次回は、今回紹介したHULFT管理機能をさらに深堀した内容になります。

---
技術者のためのHULFT-HUB入門 全7回シリーズで公開を予定しています。

1. [HULFT-HUBを利用するメリットって何？](https://qiita.com/sugimon/items/59a8e36560344bff918d)
2. **HULFT-HUBの基本的な仕組み**（本記事）
3. HULFT-HUBの管理機能の仕組み
4. HULFT-HUBの中継機能の仕組み
5. HULFT-HUBの便利な使い方 その１ -HULFT設定の標準化-
6. HULFT-HUBの便利な使い方 その２ -外接Gatewayの設定のコツ-
7. HULFT-HUBの便利な使い方 その３ -非同期型連携の設定のコツ-

---
本記事は、[HULFT-HUBマニュアル](https://www.hulft.com/help/ja-jp/HUB-V3/index.htm)、および[HULFT8マニュアル](https://www.hulft.com/help/ja-jp/HULFT-V8/index.htm)を参考にしています。