こんにちは。
私が携わっているプロジェクトで、Azure App Service（以降 App Service と表記）で大容量かつ大量のファイルを取り扱いたいケースに直面しました。
通常であれば、Azure Storage Account（以降ストレージ アカウントと表記）の一部である Blob ストレージとの連携が想定されますが、
今回のケースではそのファイル群を移動したり、リネームしたり、はたまた圧縮解凍したりと諸々の操作ができるよう要件が定められています。
Blob ではファイルに対する CRUD 操作はまだしも、圧縮解凍といった操作まではサポートされていないので、別のソリューションを検討する必要が生じました。
通常、App Service では、そのサービスが稼働している App Service Plan の SKU で決められた容量以上のファイルは取り扱うことができません。
また、App Service は PaaS であるため、アプリの裏側で動いているインフラ側には干渉しづらい側面があります。
具体的には、App Service が動作する仮想マシン上の OS や ファイルシステムは Azure 側から提供されるものなので、
イチから仮想マシンを構築する場合と異なり、開発者がコントロールできる範囲には制限があります。(それが PaaS のメリットでもあるのですが)
そんな App Service でも、Azure Files との連携機能を使えば、
あたかも仮想マシンにドライブを追加するかのように簡単にファイルストレージを追加することできます。
元々は App Service の OS が Linux の場合のみ対応する機能でしたが、2023/01に Windows でも対応した旨が GA されました。
今回は、その方法と注意点についてご紹介します。
Azure Files について
Azure Filesとは、クラウドベースのファイル共有ストレージを提供するサービスです。
ストレージ アカウントが提供する機能の一部です。ストレージ アカウントを作成してあれば追加の設定ですぐに利用することができます。
最もメジャーな利用方法としては、オンプレミスのファイルサーバの移行先やバックアップが挙げられます。
Azure Files の App Service へのマウント
早速 Azure Files を作成し、App Service へマウントしてみましょう。
なお、ストレージ アカウントと App Service は既に作成されているものとします。
ストレージ アカウントの管理ポータルを開き、「ファイル共有」ブレードをクリックします。
"+ファイル共有"リンクをクリックし、詳細情報を入力後、作成が完了します。
↓
マウント先の App Service の、「構成」ブレードをクリックします。
「パスのマッピング」タブの、"+新しい Azure Storege マウント"をクリックします。
必要情報を入力しOKボタンをクリックします。
名前は任意で構いません。
ストレージ アカウントには、ファイル共有を作成したストレージ アカウントを設定します。
ストレージ コンテナ―には、作成したファイル共有を設定します。
マウント パスは、/mounts/[任意のディレクトリ名]を設定します。
なお、/mounts/foo/barのように、サブディレクトリまで指定することはできません。
ちなみに、マウント先のフルパスはC:\mounts\[任意のディレクトリ名]となります。
これでマウントが完了しました！疎通してみましょう。
まずは作成した Azure Files に適当なファイルをアップロードします。
今回はストレージ アカウントのクライアントツールであるAzure Storage Explorerを使用します。
Azure Files に"sample.png"をアップロードしました。
マウントが上手くいっていれば、AppServiceが稼働するマシンのC:\mounts\[任意のディレクトリ名]に"sample.png"があるはずです。
AppServiceが稼働するマシンのファイルシステムを覗くには、Kuduを使います。
マウント先 App Service の「高度なツール」ブレード をクリックし、「移動→」リンクから使用できます。
画面上部の「Debug console」タブから CMD(コマンドプロンプト) もしくは PowerShell お好きなコンソールを選択してください。
"sample.png"がありました！
これで、App Service で稼働するアプリから自由にファイル共有先のアイテムを操作することができます。
また、dir コマンドを実行した際にマウント先の空き容量も確認できます。
こちらの個所にご注目ください。
5,497,558,073,344 バイト ≒ 5 テラバイト の容量が確保されているのが分かると思います。
この App Service のプランは F1 であり、SKU 上のストレージ容量は 1GB ですが、ファイル共有をマウントすることで大幅に容量を拡張することができました。
まとめ
想像していたよりも非常に簡単な手順で実現できて驚きました！
Azure をはじめとしたクラウドサービスは、各リソースの組み合わせ次第で色々なソリューションが得られるのが面白いですね。
一つ注意点ですが、App Service がVNET統合されている場合、環境変数に特定の値を追加する必要があるなど
今回ご紹介した手順に+αした作業が必要となります。
詳細はベストプラクティスをご確認ください。
おわりに
KENTEMでは、様々な拠点でエンジニアを大募集しています！
建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。
https://hrmos.co/pages/kentem2211/jobs/A0008hrmos.co
hrmos.co
hrmos.co
hrmos.co
hrmos.co
hrmos.co
hrmos.co
hrmos.co
