FSxを使用したAutoScaling構成を作りたい

# Amazon FSx for Windows File Server使い方を勉強する


##### はじめに

AWSのファイルストレージサービスには様々なものがあります。

Linux環境におけるEFS（Amazon Elastic File System)の活用をしたことはありましたが、Windows Server環境でのファイルストレージサービスであるAmazon FSx for Windows File Serverを活用した経験は少ないので検証してみました。結構ハマったのでまとめてみます。


##### やりたかったこと
不特定多数の利用者が使用するWebシステムを想定します。
負荷に応じてEC2の台数を変動させるAutoScaling構成としましょう。

Windows ServerなのでWebサーバとしてIISを使います。
IISのコンテンツディレクトリにFsXを指定することで、AutoScalingによるスケールアウトが行われた際に、 スケールアウトしたサーバは常に最新のコンテンツを応答できるよう出来るんじゃないか。という検証です。


#### 構成図
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/c2bd2871-fb3d-bc3c-28e9-2157be6a3239.png)


##### 何にハマったか
Windowsの経験が浅いこともありますが、Webで情報を調べてもAmazon FSx for Windows File Server（毎回書くのは長いので、以下FSxと表記します）の情報が思った以上に少ないんですよね。AWSを触る際は、Web上の情報を色々参考にさせてもらうんですが、情報が少ないことが一番辛いです。

※FSxは他にも種類があります。公式ページ　https://aws.amazon.com/jp/fsx/

#### FSx利用時の制約
ドメイン参加が必須である
・AutoScaling後にAD参加が必要
・その後EC2を再起動する必要がある

AD参加後にFSxへ接続する必要がある

思ったよりも制約が多く、結構大変そうです。


##### 検証
AutoScaling後に自動で最新のコンテンツを参照できるようにするということの実現性を確かめます。大きくは以下の流れとなります。



①オートスケーリング時にAD参加する
②EC2を再起動する
③EC2起動時にFSxに接続する
④EC2でIISを起動する

FSx上のコンテンツを応答できる・・はず！

これが出来ると、起動後に毎回コンテンツをコピーしてローカルのディスク（EBS）に配置するという手間が削減できるという考えです。。





##### 検証その１　ドメイン参加していないとどうなるか？
ドメイン参加する前にIISの物理パスにFSxを指定する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/0878e37c-f414-8770-2648-df719f96a379.png)

これは当然ダメですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/84ee5b72-a3f1-e93c-691f-2903e3f1d460.png)


##### 検証その２　ドメイン参加後にFSxへ接続する
ドメイン参加

検証用インスタンスを起動する際に、ドメイン結合ディレクトリの指定と、FSxを使用するためのロールを割り当ててあげます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/61abc8f8-0873-0dc8-8409-bbe3c923759f.png)


この指定をすることで、起動直後にドメイン参加され起動されます。これは便利ですね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/0e9cfd9d-f842-b7c5-2f13-50094c2cccba.png)


デフォルト状態のIISのサイトの編集からユーザの指定と、物理パスの指定をします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/1bd2bf88-3a94-f491-9330-48b68414b567.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/12ede7a6-9628-936f-bb54-0dd408e62a40.png)

FSx上に置いたファイルをIISから参照することが出来ました！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/cf6f167e-0392-859d-7fc5-4e2fc0a80388.png)

思ったより簡単に使えますね！

ここまでは順調に進んだものの、気になる点が・・。
ブラウザに表示されたものがキャッシュじゃないことも確認しようと思い、FSx上のファイルを編集して確認をしようとしたところ・・FSxが見えない？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/2bd978c5-ae18-a409-4a14-e358929c233e.png)

ログインしているユーザでも自動でFSxに接続されているように見えないと、本当は繋がってないんじゃないの？とあらぬ疑いをかけられてしまう可能性もあります。
スケールアウトしてきて起動したサーバにログインした際に、FSxのドライブが見える状態になっていると安心できるはず。せっかくなので、ここも対応してしまいましょう。


##### 検証その３　OS起動時にFSxへ接続する

OS起動時にnet useコマンドで接続すればいいはず。簡単なpowershellスクリプトでも作ってタスクスケジューラで起動時に実行するタスクとして仕込んでおきましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/56ac72d5-4f1f-a1c9-622c-68230cc702ed.png)

文字化けしていますが、FSx上のファイルに追記できました。問題なさそうです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/477f6808-eac2-6a2c-de19-5b355f8c27ab.png)


あれ？FSxに×がついていますね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/099491e6-4021-b7c5-4dbf-94f4fc48d11b.png)

接続できていないのになんで書き込めるんだろう？
コネクションを確認してみると

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/eb8f8cdc-9274-d26e-7946-8077d4034dc3.png)


ESTABLISHEDになっています。
タスクスケジューラに登録したユーザじゃないから切断されたように見えてしまっているのか？

色々試しているうちに、IISからもFSx上のコンテンツを参照できなくなっているなど、いろいろうまく行っていないところが見えてきます。



だいぶ長い日数試行錯誤して、行きついたのはコレ！

**SMB グローバルマッピング**

>リモート SMB 共有を、(コンテナーを含む) ローカル ホスト上のすべてのユーザーがアクセスできるドライブ文字にマップします。


https://learn.microsoft.com/ja-jp/windows-server/storage/file-server/file-server-smb-overview#features-added-in-windows-server-2019-and-windows-10-version-1809




試しに検証用のスクリプトを作ってみると、FSxをZドライブとして認識させることが出来ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/3d89852f-c2d6-cd3d-04b5-a70df1f311ab.png)

IISからもZドライブ指定とできるので、IISにはFSxの接続情報を設定も不要となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3677642/25891dc6-3279-0ed4-b765-9525d95efe68.png)



##### まとめ
ここまでで、スケールアウト後に自動でIISからFSxを参照するための仕組みの一部を検証することが出来ました。SMB グローバルマッピングはWindows経験が豊富であれば当たり前のように知られている機能なのかもしれませんが、情報も少なくかなりハマりました。

そもそもAutoScaling構成をするのであればEC2は使い捨てとなり、スケールアウトしたサーバへログインする必要性もないので、サーバにログインしてまで確認することはないのかもしれませんね。

実際にWindows ServerでAutoScaling＋FSxの構成を行う場合はsysprepを行う必要があったり、ADへの自動参加・スケールイン時の仕組みを考える必要があるなどまだまだ考慮すべき点はあります。

LinuxサーバでEFSを使うときに比べて大分ハードルが高いなという印象ですが、非常に便利な使い方ができるサービスでもあるので、しっかり使い方を理解していければと思います。





##### 参考記事
https://aws.amazon.com/jp/blogs/containers/use-smb-storage-with-windows-containers-on-aws-fargate/

https://learn.microsoft.com/en-us/powershell/module/smbshare/new-smbglobalmapping?view=windowsserver2022-ps

https://dev.classmethod.jp/articles/fsx-for-windows-file-server-walkthrough/

https://blog.serverworks.co.jp/tech/2020/05/29/post-86082/

https://cloud5.jp/amazon-fsx-ec2-file-share/