1.はじめに
既存のWindows Server 2016上で稼働する業務アプリケーションのファイル保存先として、AWS S3 Filesを利用できるか検証しました。
当初はWindows Server 2016からAWS S3 Filesを直接利用する構成を検討しましたが、検証環境の制約を踏まえ、LinuxサーバにAWS S3 Filesをマウントし、Samba経由でWindows Serverへ共有する構成を採用しました。
本記事では、Linux（Samba）経由でWindows Server 2016からAWS S3 Filesを利用する構成の構築手順および動作検証結果について紹介します。
2.構成検討
当初想定していた構成
AWS S3 Filesを既存システムのファイル保存先として利用するにあたり、当初はWindows Server 2016からAWS S3 Filesを直接利用する構成を想定していました。
Windows Server 2016から直接利用しなかった理由
Windows Server 2016にはNFSクライアント機能が用意されていますが、AWS S3 FilesはNFS v4.1以降を利用するサービスであり、Windows Server 2016環境から直接利用する構成は採用しませんでした。
そこで、Amazon LinuxへAWS S3 Filesをマウントし、Sambaを介してWindows Server 2016へ共有する構成を採用しました。
採用した構成
Windows Server 2016からAWS S3 Filesを直接利用する構成は採用せず、Amazon Linuxを経由して利用する構成としました。
Amazon Linux上でAWS S3 Filesをマウントし、Sambaを利用してSMB共有を提供することで、Windows Server 2016からは通常のファイルサーバと同様にアクセスできるようにしています。
冗長化構成の検討
高可用性を考慮し、複数のAmazon LinuxサーバでSamba共有を提供し、NLB（Network Load Balancer）を経由してアクセスする構成についても検証を実施しました。
今回の検証では、AWS S3 FilesをマウントしたAmazon Linuxサーバを2台構築し、各サーバでSamba共有を提供しました。
Windows Server 2016からはNLBのDNS名を利用して共有フォルダへ接続する構成とし、Linuxサーバ障害時の継続利用を考慮した冗長化構成の動作を確認しました。
3.AWS S3 Filesの構築
前提
- VPC、EC2、Directory Bucket等のAWSリソースは作成済みであること
- AWS S3 Filesを利用するために必要な権限設定が実施可能であること
- Windows Server 2016およびAmazon Linuxへ管理者権限でアクセス可能であること
- Amazon Linuxサーバの構築は完了していること
S3 Filesの作成
対象のDirectory Bucketを選択し、「ファイルシステム-新規」タブをクリックします。
「ファイルシステムを作成」ボタンをクリックします。
対象のWindows Server 2016があるVPCを選択し、ファイルシステムを作成します。
数分で作成されます。
4.Amazon Linuxからの接続設定
EC2 IAMロールの設定
Amazon LinuxからAWS S3 Filesへアクセスするため、EC2インスタンスに必要なIAM権限を付与します。
- 対象EC2インスタンスを選択
- 「セキュリティ」タブからIAMロールをクリック
- IAMコンソールで「許可」タブを開く
- 「許可を追加」→「ポリシーをアタッチ」を選択
-
AmazonS3FilesFullAccessを検索して追加
設定後、EC2インスタンスからAWS S3 Filesへアクセスできるようになります。
マウントポイントの作成
Amazon Linux上で、S3 Filesをマウントするためのディレクトリを作成します。
sudo mkdir -p /mnt/s3/fs1
S3 Filesのマウント
作成したマウントポイントにS3 Filesをマウントします。
S3 FilesのIDは、S3 Filesの「プロパティ」タブから確認できます。
以下のコマンドを実行してS3 Filesをマウントします。
sudo mount -t s3files <S3 Files ID>:/ /mnt/s3/fs1 -v
S3 Filesのマウント確認
Directory Bucketに事前にテストファイルを配置しておきます。
S3 Filesのマウント後、マウントポイントへアクセスし、Directory Bucket内のデータが参照できることを確認します。
ls -la /mnt/s3/fs1
実行結果として、Directory Bucketへ配置した test.txt が表示されていることを確認できました。
Sambaのインストール
Amazon LinuxへSambaをインストールします。
sudo dnf install samba -y
Sambaの設定
S3 Filesをマウントしたディレクトリを共有するため、Samba設定ファイルを編集します。
sudo vi /etc/samba/smb.conf
[S3Files]
path = /mnt/s3/fs1
browseable = yes
writable = yes
read only = no
guest ok = no
Sambaユーザーの設定
Windows Server 2016から共有フォルダへアクセスするため、Sambaユーザーを設定します。
本検証では、Amazon Linuxのデフォルトユーザーである ec2-user を利用しました。
以下のコマンドを実行し、ec2-user をSambaユーザーとして登録します。
sudo smbpasswd -a ec2-user
Sambaサービスの起動
Sambaサービスを起動し、自動起動を有効化します。
sudo systemctl enable --now smb
設定後、サービスが正常に起動していることを確認します。
sudo systemctl status smb
実行結果として Active: active (running) が表示され、正常に起動していることを確認できました。
ec2-userの権限設定
S3 Filesをマウントしたディレクトリへアクセスできるよう、所有者を ec2-user に変更します。
※ 必要に応じて、マウントポイントの所有者を変更します。
sudo chown ec2-user:ec2-user /mnt/s3/fs1
Windows Server 2016からの接続確認
Windows Server 2016から共有フォルダへ接続します。
接続時には、Sambaユーザーとして設定した ec2-user とパスワードを利用します。
共有フォルダへ接続後、S3 Files上のファイルおよびディレクトリが参照できることを確認します。
\\<Amazon LinuxのIPアドレス>\S3Files
事前にDirectory Bucketへ配置した test.txt が表示されていることを確認できました。
これにより、Windows Server 2016 → Samba → S3 Files の経路でアクセスできることを確認できました。
5. NLBによる冗長化構成
冗長化構成の概要
Amazon Linuxサーバ1台でSamba共有を提供する構成でもAWS S3 Filesを利用できますが、サーバ障害が発生した場合はWindows Server 2016から共有フォルダへアクセスできなくなります。
そのため、高可用性を考慮し、複数のAmazon LinuxサーバでSamba共有を提供し、NLB（Network Load Balancer）を経由してアクセスする構成についても検証を実施しました。
今回の検証では、2台のAmazon LinuxサーバにAWS S3 Filesをマウントし、それぞれでSamba共有を提供する構成を構築しました。
Windows Server 2016からはNLBのDNS名を利用して共有フォルダへ接続できます。これにより、利用者は接続先サーバを意識することなく共有フォルダを利用できます。
Amazon Linuxサーバの追加
1台目と同様の設定を実施したAmazon Linuxサーバを追加で構築します。
以下の設定を実施し、2台のAmazon Linuxサーバで同一の共有を提供できる状態としました。
- AWS S3 Filesのマウント
- Sambaのインストール
- Samba設定
- Sambaユーザー設定
- セキュリティグループ設定
ターゲットグループの設定
ターゲットグループの作成
NLBの接続先として利用するターゲットグループを作成します。
EC2コンソールから「ターゲットグループ」を選択し、「ターゲットグループの作成」をクリックします。
本検証では、以下の設定でターゲットグループを作成しました。
- ターゲットの種類：インスタンス
- ターゲットグループ名：任意
- プロトコル：TCP
- ポート：445
- IPアドレスタイプ：IPv4
- VPC：Amazon Linuxインスタンスが配置されているVPC
- ヘルスチェックプロトコル：TCP
設定後、「次へ」をクリックします。
ターゲットの登録
作成したターゲットグループへAmazon Linuxサーバを登録します。
本検証では、Sambaを構成した2台のAmazon Linuxサーバをターゲットとして登録しました。
登録するインスタンスを選択し、「保留中として以下を含める」をクリックします。
登録内容を確認後、「次へ」をクリックします。
確認と作成
設定内容および登録するターゲットを確認します。
本検証では、2台のAmazon Linuxサーバが登録されていることを確認しました。
内容に問題がないことを確認し、「ターゲットグループの作成」をクリックします。
NLBの作成
Windows Server 2016から共有フォルダへアクセスする際の接続先を統一するため、Network Load Balancer（NLB）を作成します。
EC2コンソールから「ロードバランサー」を選択し、「ロードバランサーの作成」をクリックします。
基本的な設定
本検証では以下の設定でNLBを作成しました。
- タイプ：Network Load Balancer
- スキーム：内部
- IPアドレスタイプ：IPv4
ネットワークマッピング
NLBを配置するVPCおよびサブネットを選択します。
本検証では、Amazon Linuxインスタンスが配置されているVPCおよびサブネットを選択しました。
セキュリティグループとリスナーとルーティング
Windows Server 2016からのSMB通信を受け付けるため、セキュリティグループおよびリスナーを設定します。
本検証では、SMBで使用するTCP 445を許可し、受信した通信を前項で作成したターゲットグループへ転送するよう設定しました。
- セキュリティグループ：TCP 445 を許可
- プロトコル：TCP
- ポート：445
- ターゲットグループ：前項で作成したターゲットグループ
確認
ここまでの設定内容を確認します。
本検証では、以下の設定でNLBを構成しました。
- スキーム：内部
- IPアドレスタイプ：IPv4
- VPC：Amazon Linuxインスタンスが配置されているVPC
- リスナー：TCP 445
- 転送先：作成したターゲットグループ
設定内容に問題がないことを確認し、「ロードバランサーの作成」をクリックします。
NLBの作成完了
NLB作成後、ロードバランサーの詳細画面を確認します。
リスナーに TCP 445 が設定されていること、および先ほど作成したターゲットグループへ転送される設定になっていることを確認できます。
以降の接続確認では、NLBのDNS名を利用して共有フォルダへアクセスします。
ターゲットの状態確認
ターゲットグループ作成後、登録したAmazon Linuxサーバの状態を確認します。
ヘルスチェック完了後、登録した2台のAmazon Linuxサーバが正常（Healthy）状態となることを確認しました。
NLBは正常状態のターゲットへトラフィックを転送するため、この状態になっていることを確認してから接続確認を実施します。
Windows Server 2016からの接続確認
Windows Server 2016からNLBのDNS名を指定して共有フォルダへ接続します。
\\<NLBのDNS名>\S3Files
接続後、共有フォルダ内のファイルおよびディレクトリが参照できることを確認しました。
これにより、Windows Server 2016 → NLB → Amazon Linux(Samba) → AWS S3 Files の経路で正常にアクセスできることを確認できました。
フェイルオーバー確認
NLBによる冗長化構成が正常に機能するか確認するため、Amazon Linuxサーバを1台停止した状態で動作確認を実施しました。
ターゲットグループの状態を確認すると、2台のAmazon Linuxサーバのうち1台が Unhealthy となり、もう1台が Healthy 状態を維持していることを確認できました。
この状態でWindows Server 2016から共有フォルダへアクセスを実施したところ、引き続き共有フォルダを利用できることを確認しました。
また、共有フォルダ内のファイル参照および更新についても問題なく実施できることを確認しました。
これにより、片系障害発生時でも正常なAmazon Linuxサーバを経由して共有フォルダへのアクセスを継続できることを確認できました。
6. 検証結果
今回の検証で確認できた内容を以下に示します。
- Amazon LinuxへAWS S3 Filesをマウントできること
- Samba経由でWindows Server 2016から共有フォルダとして利用できること
- ファイルおよびフォルダの作成、更新、削除が実施できること
- NLBを利用した冗長化構成を構築できること
- Amazon Linuxサーバ1台停止時でも共有フォルダへのアクセスを継続できること
7. まとめ
本記事では、Windows Server 2016からAWS S3 Filesを利用する構成について検証しました。
当初はWindows Server 2016からAWS S3 Filesを直接利用する構成を検討しましたが、Amazon LinuxおよびSambaを経由する構成を採用することで、既存環境への影響を抑えながらAWS S3 Filesを利用できることを確認しました。
また、NLBによる冗長化構成を組み合わせることで、Amazon Linuxサーバ障害時でも共有フォルダへのアクセスを継続できることを確認できました。
一方で、AWS S3 Filesではファイルシステム上の変更が即座にS3バケットへ反映されるのではなく、一定時間（60秒）の非アクティブ期間経過後にS3バケットへエクスポートされる仕様となっています。今回の検証でも、S3 FilesへアップロードしたファイルがDirectory Bucketへ反映されるまで約1分程度かかることを確認できました。
参考:
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-files-synchronization.html
今後は、Webアプリケーション利用時のキャッシュ挙動やファイル更新の反映タイミング、複数クライアントからアクセスした場合の挙動について、さらに検証を進めたいと考えています。