HULFTのS3アップロード機能を試してみた (2019年10月版)

HULFTのS3アップロード機能を試してみた (2019年10月版)

Clock Icon2019.10.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。
今年の頭にHULFTのS3アップロード機能を試した記事を書きましたが、今回この機能に変更が入ったとの事で、新しくなったS3アップロード機能を試してみました。

https://dev.classmethod.jp/server-side/network/huflt-s3-upload-01/

https://dev.classmethod.jp/server-side/network/huflt-s3-upload-02/

HULFT クラウドストレージオプション(仮)

前の記事では「クラウド直結型HULFT(仮称)」と紹介しましたが現在は機能名が「クラウドストレージオプション(仮)」変わっています。
こちら最終的なデータの保存先がS3等のクラウドストレージになる点は変わらないのですが、配信(データ送信)で直接クラウドストレージにデータを送信する方式から集信(データ受信)先をクラウドストレージにする様に方針が改められました。
集信先サーバーがオンプレミス環境にあるかクラウド環境にあるかによって大きく以下の2パターンに分かれています。

  • Clientlessパターン : オンプレミス環境で集信されたデータをクラウドストレージにオンメモリ中継
  • Write Proxyパターン : クラウド環境で集信されたデータをクラウドストレージにオンメモリ中継

今回はこのうち「Clientlessパターン」を試していきます。

試してみた

ここから早速試していきます。

検証環境

今回の検証環境として、オンプレミス環境(自宅)に2台のHULFT 8.4をインストールしたWindows Server 2016を用意し、配信側ホスト名をHULFT01、集信側ホスト名をHULFT02としてHULFT01からHULFT02にデータを送信してみます。

AWS側環境設定

AWS側環境としては前回同様に最終的なデータ保存先となるS3バケットとHULFTがAWSにアクセスするためIAMユーザー(アクセスキー)を用意します。

S3のバケット名は前回同様にtakuya-shibata-hulftとしました。
こちらすべて初期設定で問題ないため構築手順は省略します。(前回と全く同じです)

IAMポリシーは前回と少し異なり、

  • s3:PutObject
  • s3:ListBucket

の権限が必要となります。
今回はポリシー名は前回と同様にHULFTS3PutPolicyとしつつも下図の様に構成しました。

JSONだと以下になります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::takuya-shibata-hulft",
                "arn:aws:s3:::takuya-shibata-hulft/*"
            ]
        }
    ]
}

そしてこのポリシーを持つユーザーhulft-s3-userを作成します。
こちらも手順としては前回同様なのでスクリーンショットの一覧だけ記載しておきます。

これでAWS側環境設定は完了です。

オンプレ側環境設定

オンプレ環境のHULFT01HULFT02にそれぞれ現在最新のHULFT 8.4をインストールし、集信側のHULFT02にS3連携する専用のプラグインをインストールします。
インストール手順は前回同様なので詳細は割愛します。

集信側(HULFT02)にS3アップロードで使用するための__システム環境変数__の設定が必要なので前回同様にこちらも設定しておきます。

# 要管理者権限
[Environment]::SetEnvironmentVariable('AWS_ACCESS_KEY_ID', '<アクセスキーID>', 'Machine')
[Environment]::SetEnvironmentVariable('AWS_SECRET_ACCESS_KEY', '<シークレットアクセスキー>', 'Machine')
[Environment]::SetEnvironmentVariable('AWS_DEFAULT_REGION', '<リージョン名>', 'Machine')

# 設定の反映には再起動が必要
Restart-Computer

ここまでで環境構築は完了です。

HULFTの設定

続けてHULFTの設定について説明します。
今回の機能を試す前提としてHULFT01からHULFT02にデータを送信できる環境を用意しておく必要があります。
本記事では詳細の手順までは説明しませんが、各サーバーに以下の設定を仕込んでおきます。

HULFT01の設定 (配信)

設定項目 設定値 備考
詳細ホスト HULFT01, HULFT02 設定値は基本デフォルトのまま
配信グループ : グループ名 HULFT02
配信グループ : 宛先ホスト HULFT02 単一の宛先設定
配信管理 : ファイルID FILES3
配信管理 : 物理ファイル C:\Temp\send\sample.txt 単純なテキストファイルを送信
配信管理 : 配信グループID HULFT02 HULFT02へ送信
  • その他
  • OSのHOSTSファイルに HULFT01, HULFT02 の定義を追加
  • C:\Temp\send\sample.txtに適当なテキストファイルを配置

配信管理の設定は下図の様にしています。

ちなみに配信グループ、ホスト情報の詳細は以下としHULFT02に送信される様にしています。

HULFT02の設定 (集信)

設定項目 設定値 備考
詳細ホスト HULFT01, HULFT02 設定値は基本デフォルトのまま
配信グループ : グループ名 HULFT01
配信グループ : 宛先ホスト HULFT01 単一の宛先設定
集信管理 : ファイルID FILES3
集信管理 : ファイル名 s3://takuya-shibata-huflt/sample.txt 受信先をS3に設定
集信管理 : 異常時の処置 復元
  • その他
  • OSのHOSTSファイルに HULFT01, HULFT02 の定義を追加

集信管理の設定は下図の様にしています。

受信ファイル名を s3://takuya-shibata-huflt/sample.txt とS3バケット+ファイル名の形式にしているのがポイントです。
現時点では機能制約により異常時の処置、集信形態、世代管理は「復元」「単一集信」「しない」のみ選択可能、登録モードは「新規作成」「置き換え」のみ選択可能となっています。

これですべての準備が整いました。

ファイル送信

それではHULFT01C:\Temp\send\sample.txtに配置したテキストファイルを送信してみます。
HULFT01でHULFT管理画面を起動、「配信管理情報一覧」画面を開いて当該ファイルFILES3を右クリックして「配信要求」を選択します。

配信要求ダイアログが表示されるので、そのまま「配信要求」ボタンをクリックします。

設定に問題なければ配信要求が正常に終了します。

配信状況一覧画面から結果を確認すると下図の様になり、正常終了していれば「完了コード」が000000(00000)になります。
こちらはHULFTの通常の配信と同じです。

受信側の状況はHULFT02の集信状況一覧画面から確認でき、こちらも正常終了していれば「完了コード」が000000(00000)になります。
HULFTの通常の集信と同様ですが、ファイル名がS3のバケット指定になっているのが今回の特徴となります。

最後にAWSマネジメントコンソールよりS3バケットを確認してみるとsample.txtがきちんとアップロードされていました。

最後に

以上となります。

今回の変更により前回以上にS3を意識する箇所が少なくなり、利用者にとってはS3を全く意識せずに利用する形となっています。
普段通りHULFTを利用していたらシームレスにS3等のクラウドストレージにデータが保存されるのは非常に便利だと感じました。

注意事項

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.