Azure Functions で使用されるファイルのストレージについて

Azure Functions App Service Azure Web Apps

Functions にフォーカスしているが、基盤としている App Service も基本的な考え方は同じ。

App Service では用途によって、ファイルストレージが 2 種類用意されている。永続ファイル用と、一時ファイル用。

App Service は同一アプリ用のインスタンスが複数同時に実行される可能性があるため、アプリで使用する永続ファイル用のストレージは各 VM インスタンス毎ではなく、Azure ストレージ上に用意された共通のストレージを使用する。

逆に一時ファイル用のストレージについては共有しておらず、各 VM インスタンス毎に用意され、使用される。

  • 永続ファイル
    • 使用するパスは、d:\home
    • 従量課金の場合、Azure File Share 上に永続ファイル用のストレージを (自分で) 作成し、そこを使用する。当該ストレージ アカウントの File Share を見ると、KUDU で見れるストレージと同じものを見ることが出来る f:id:poke_dev:20180430160914p:plain f:id:poke_dev:20180430160924p:plain
    • App Service プランの場合も永続ファイルのストレージは Azure ストレージを使用しているらしい。ただ、App Service の場合はこの永続ストレージのサービスが App Service プランの一部に含まれており、App Service プランの作成と同時に内部で自動的に作成して使用するらしいので、自分で用意する必要はないし、従量課金プランのようにストレージ アカウントなどで状況を確認することはできない。状況を確認できる唯一の方法は、KUDU。
    • 名称の通り永続ファイル用のストレージなので、ファイルが自動的に削除されるようなことはない (VM インスタンスとは分離されているので、VM インスタンスを再起動とかしても問題ない)
    • 使用可能な容量は、プランによって異なる。従量課金は Azure File Share の最大サイズである 5TB (？ 詳細未検証。File Share なのでたぶん別途従量課金)、App Service プランは、当該 App Service プランの使用可能ストレージサイズに沿う (Standard だと 50GB など)
    • Function App 自体のファイルもここに配置されるし、プログラムからも通常のファイルストレージと同様に、追加削除、読み書きが可能
    • 同一 Function App が複数インスタンスで同時に稼働していたとしても、d:\home で全て同じ場所を参照する。そのため、ファイル操作方法によっては排他に気をつける必要がある。App Service プランで 1 インスタンスで使用している場合は結果的に排他は考慮不要だが、2 インスタンス以上で稼働している場合は必ず考慮必要だし、従量課金の場合もスケールアウトする可能性があるなら考慮必要
    • 当該 Function App の KUDU も同じ場所を参照するので、KUDU から Function App 用ファイルの追加削除編集を行うことが容易
    • ファイルが格納されている場所が VM インスタンス上ではなくリモートになるため、ファイル操作のパフォーマンスは悪いらしい
    • KUDU も動作しているインスタンスはアプリと異なるが、永続ストレージは共通の Azure ストレージを参照するため結果的に KUDU もアプリと同じストレージを参照・操作できる
  • 一時ファイル
    • 使用するパスは、d:\local
    • ストレージは各 VM インスタンス上に用意され、使用される。そのため、同じパスで参照してもインスタンスが異なれば参照している場所が異なる (= 共有できない)
    • 名称の通り一時ファイル用のストレージなので、あるタイミングで初期状態に戻る。例えば、インスタンスを再起動すると、一時ファイルのストレージは初期化される。そのため基本的には、ファイルの生存期間も操作範囲も、1 関数内に閉じた使い方を想定するべきと思われる
    • 使用可能な容量は、プランによって異なる。従量課金は 500MB (？ KUDU の Environment 上は 200GB とかに見えるが、詳細未検証)。App Service プランはプランによって異なり、B1, S1 系は全インスタンスでの合計が 11GB、B2, S2 は同 15GB、B3, S3 は同 58GB らしい。詳細は Understanding the Azure App Service file system を参照。
    • 当該 Function App の KUDU も KUDU 用インスタンス固有の一時ファイルストレージを使用するので、現在動作しているアプリの一時ファイルストレージを見る方法は、基本的にない (一応環境変数を書き換えて一時ファイル用ストレージを特定の 1 つに固定することで、KUDU でも見れるようになるらしいが・・・詳細不明)。
    • VM インスタンス上にストレージが存在するため、リモート ストレージの永続ファイルと比べてパフォーマンスが良いらしい

参考 URL

Azure Functions (App Service) が使用する通信用 IP について

Azure Functions App Service セキュリティ Azure Web Apps

Azure Functions、と言うよりはその基盤となる App Service の仕組みになるが、通信に使用する IP が、1 つだけ使用するとかの単純な構成ではない。

まず、受信と送信で、別の口が用意されている。受信は 1 つで、送信は 4 つから 5 つの複数個用意されている (スタンプと呼ばれる概念)。このスタンプの中に VM インスタンスを作成して実行する仕組みは、Functions の従量課金プランも App Service プランも同じ。

念の為それぞれの役割を簡単に説明すると、例えば、GET の REST API で処理を受け付け、SQL Database にクエリーを投げて、その結果を返すような Function があったとする。 この場合、まずクライアントからの REST API 呼び出しは受信用の IP で行い、SQL Database とのやり取りは、送信用の IP (複数あるうちのどれか) で行う。

上記のようなパターンで、セキュリティ強化のために SQL Database の IP 制限を行い、当該 Functions からのアクセスのみ許可したいとすると、当該 Functions の送信用 IP アドレスを全て SQL Database のファイアウォールで許可 IP に登録する必要がある。

（後述するが、従量課金プランの Functions の場合は使用スタンプが動的に変わる可能性がある為、ファイアウォール等の登録 IP としては使用不可）

App Service プランで注意する点としては、下記

  • 当該 App Service のプランを変更するレベルの作業を行わない限り、送信用 IP は基本的に変更されることはない (インスタンス再起動とかでは変わらない)。が、その場合でも変わる可能性はゼロではないらしく、大規模なメンテナンス等が発生した際に、変わる可能性があるらしい (数年に一度ぐらいのレベル？)
  • ファイアウォールの許可 IP 等で使用していた場合、送信 IP の変更発生後は、許可 IP も変更する必要がある
  • 上述した「スタンプ」と呼ばれる箱みたいな概念で受信の口と送信の口を分けて管理しているが、この「スタンプ」の箱に入るのは自分の App Service だけではなく、他ユーザーの App Service も含む複数の App Service がまとめて登録される。同じスタンプ内の App Service は、同じ受信口、送信口を使用する。上述したようなファイアウォールの許可 IP として設定できるのは App Service の IP ではなく、あくまでこの「スタンプ」の IP なので、制限できるのもこのスタンプレベルまでとなり、同じスタンプ内の別の App Service からの通信は、許可されることになる (IP 的には)

Functions の送信用 IP の確認方法は、以下の通り

  1. Azure ポータル画面を開く
  2. 当該 Functions の画面を開く
  3. [プラットフォーム機能] - [プロパティ] をクリックする
  4. [送信 IP アドレス] に複数の IP が表示されているので (表示されていない場合は次の手順に進む)、IP 制限を行いたい時はこの IP を全て登録する f:id:poke_dev:20180430111347p:plain
  5. (上記設定画面に [送信 IP アドレス] が表示されていない場合は、以降の作業を行う。因みに上記は Functions ではなく、Web Apps での例となっている)
  6. [プラットフォーム機能] - [リソース エクスプローラー] をクリックする f:id:poke_dev:20180430112825p:plain
  7. リソース エクスプローラーが別画面で開き、確認する必要がある JSON が自動的に表示される (はず)。[outboundIpAddresses] の IP が、送信 IP アドレスとなる。なお、そのすぐ下に表示されている [possibleOutboundIpAddresses] は気にしないで良いみたい (ドキュメントではこっちを見ると記載されているのもあるけど、詳細は不明) f:id:poke_dev:20180430114751p:plain

補足

  • 受信用 IP は、[プラットフォーム機能] - [カスタム ドメイン] - [IP アドレス] で確認できる
  • プランによらず、Functions の送信 IP を完全に固定するのは無理な様子。この問題に完全に対処しようとすると、スタンプを専有する App Service Environment (ASE) の利用が必要らしい (最低数十万からの使用料がかかる。大規模システム用らしく、単純に送信 IP 変更の問題を解決できるからとかそういう理由だけで使えるような代物ではないので、注意)
  • App Service プランを使用しても送信 IP が変わる可能性はゼロではないが、基本的には変わらず、大規模メンテナンスとかのタイミングで変わる可能性があるとか何とか。数年に一度あるかどうかのレベル（？）。計画が予定されている変更の場合は事前に通知があるらしいので、IP 制御に使っている場合はその通知を見て自分で手動で変更してくださいねというスタンスらしい (送信 IP アドレスの変更に備える方法)
  • MS ドキュメントでは、Azure データセンターの全 IP をホワイトリストに登録する方法もあるのではみたいな情報もあるが、ずっと固定とは思えないし凄い数だしで、正直現実的な方法とは思えない (Azure Functions の IP アドレス)

従量課金プランの Functions に関する補足

  • 従量課金プランの Functions では home と呼ばれるスタンプ (= スケール ユニット) が基本的に使用され、リソース エクスプローラーで確認できる outboundIpAddress も、この home スタンプのものとなる。 ただ、恒常的に home 以外のスタンプにインスタンスが作成される可能性があり、この場合、送信 IP も home スタンプのものとは異なる事になる (= IP を確定できない)。詳細は下記フォーラムを参照
  • Outbound IP Addresses

参考ドキュメント

Azure SQL Database のセキュリティ基礎

Azure SQL Database Azure セキュリティ

注：ここでは VNet (仮想ネットワーク) への接続は考慮していません

Azure SQL Database のセキュリティ制御として、以下がある (他にもあったらすいません。この辺り、あまり詳しくないです)

SQL 認証については、オンプレミスの SQL Server と基本は同様なので、説明しない。Azure AD 認証は詳しくないので、説明できない。 ここでは、ファイアウォールによる IP 制限についてもう少し詳しく説明する。

  • ファイアウォールの考え方について
  • 制御する通信の種類は下記 2 種類
    • Azure サービスからのアクセス (Azure 全体)
    • 個別 IP
  • SQL Database を立てた直後の状態について
    • 個別 IP は登録なし
    • Azure サービスからのアクセスは、既定で許可されている。そのため、Azure 上のサービス、例えば Azure Web Apps, Functions などのアプリや、Azure ポータルなどからは初期状態でアクセス可能な状態となっている
  • 個別 IP の登録方法について
    • 個別 IP、IP 範囲のどちらでも登録可能
    • 注意点としては、当たり前だが、SQL Database への接続に使用されるパブリック IP を登録する必要があるので、この IP を把握している必要がある
    • とは言うものの、SQL Server Management Studio (SSMS) や Azure ポータルで当該 DB に接続しようとしてファイアウォール ルールに弾かれると、弾かれた IP が表示されるので、その IP を Azure ポータル画面の [サーバー ファイアウォールの設定] から追加すれば良い
  • 使用ポート
    • ポートは TCP ポートの 1433 を固定で使うので、このポートが許可されている必要がある

  • Azure サービスからのアクセスに関する注意点

    • この制御を行うボタンは、画面上は [Azure サービスへのアクセスを許可] という名称のボタン
    • 上述したように、アプリやポータルも含め、純粋に Azure サービス全体を表していることに注意。そのため、Azure 上に構築したアプリであれば、自分以外のアプリでもその対象になる (はず)
    • 厳密に自分の把握しているアプリやサービスのみにアクセス許可を与えたい場合は、[Azure サービスへのアクセスを許可] はオフにする必要がある (ここでオフにしても、Azure ポータルからこの設定すら行えなくなるわけではないので、その点は心配する必要無い)。その上で、個別 IP を登録する
    • Azure サービスからの全体アクセスをオフにした時の注意点としては、Azure ポータルのクエリ エディター機能については、[Azure サービスへのアクセスを許可] がオンになっている必要がある様子
    • ファイアウォール設定の変更については基本的に即時行なわれるが、設定が有効になるまで 数十分かかる事もあるので、少し注意

  • Azure SQL Database は、VNet 内に配置することは出来ないようなので、注意。ただ、VNet への接続は出来て、その場合はプライベート IP で通信できる、らしい (未検証)

参考 URL

メール添付や共有ネットワーク上の PowerPoint ファイルを開こうとすると、問題が見つかった旨のメッセージが出て開けない時の対処法

Office PowerPoint

現象

メールに添付された、または共有ネットワーク上の PowerPoint ファイルを開こうとした際に、以下のメッセージが表示され、開けないことがある。

「～のコンテンツに問題が見つかりました。～発行元が信頼できる場合は、[修復] をクリックしてください。」

画面に従って [修復] ボタンをクリックしても、修復できず、開けない。

試すこと

  • ローカルドライブに保存して、ローカルから開く
  • 当該ファイルのプロパティを開き、[全般] タブの一番下に、[ブロックの解除] が表示されていないか確認。表示されてたら [ブロックの解除] にチェックを入れて閉じた後、ファイルを開いてみる
  • PowerPoint を開いて、[ファイル] - [オプション] - [セキュリティ センター] - [セキュリティ センターの設定] をクリック。セキュリティ センターダイアログが表示されたら、左のメニューから [保護ビュー] をクリックし、状況に応じて以下のチェックボックスのチェックを外す (下記設定はセキュリティ強化のための設定なので、チェックを外すとセキュリティ的に弱くなることは注意する必要がある。会社のポリシーによっては、変更できないかも)
    • (共有ネットワーク) インターネットから取得したファイルに対して、保護ビューを有効にする
    • (メール添付) Outlook の添付ファイルに対して、保護ビューを有効にする

システム設計時、説明図で使いたいアイコンのダウンロード先

設計書 Azure

Azure Functions と他サービスとの組み合わせ

Azure Azure Functions

自分がこれまで使った組み合わせについて簡単に記載

注：以下は、App Service Environment (ASE) を使用しない、通常の環境を想定しています

  • インターネットへのアクセス
    • 特に問題なし
  • ファイル
    • 特に問題なし。App Service で実行する Web Apps などと同様の使い方になる (Functions が App Service 上に構築されているため)。
    • 注意点としては、下記
      • ファイル保存場所として、永続ファイル用ディスクと一時ファイル用ディスクの 2 種類存在する。使い分けは、それぞれ名前の通り。一時ファイル用ディスクはインスタンス再起動時等に初期状態に戻ってしまうため、注意が必要
      • プログラムからは通常のファイル操作と同じ方法で操作でき、意識する必要はないが、ファイルの保存先は Azure Storage が使用される
      • Functions の仕様上、複数インスタンス (別プロセス) が同じ場所を使用する可能性があるので、その場合は排他などについて考慮が必要と思われる (詳細未検証。要動作確認)。実行インスタンスが単一で済んでいる場合は、同一 Function App 内の関数は同一プロセス上で実行されている様子 (動作を見る限りは)
  • メール
  • SQL DB
    • 特に問題なし。
  • Entity Framework
    • 考慮事項はあるが、使用可能。(考慮事項は別途記載予定)
  • PowerShell
    • ランタイムバージョンが決まっているので、その点だけ注意。現時点ではバージョン 4 で動作する
  • Azure PowerShell
    • 実行環境に既定でインストールされているバージョンが 1.4 と非常に古いので、恐らくこのモジュールについては古すぎて使えない
    • 使用したいバージョンのファイル一式をアップロードし、アップロードしたモジュールを明示的にロードして使用可能 。【参考】Question: Azure Powershell Scripts in a Function #294
  • Application Insights
    • 問題なし。インストルメンテーション キーを環境変数に設定するだけで連携可能

Azure Functions とは

Azure Functions Azure

Azure Functions とは

  • Azure 上で、サーバーレスでプログラムを実行させることができるサービス
  • サーバーレスとは言われてるけど、文字通りサーバー不要で動くというわけではもちろんなく、プログラムを動かす土台を Functions で提供しているので、開発者的には Web サーバーを立てたりとかが不要という意味でのサーバーレス
  • Windows や Web のように UI はないので、REST API やバッチ処理向けのサービス。対話する画面がないだけで、DB に繋いだりファイル保存したり、メール投げたりということも可能
  • 使用可能な言語は複数ある。C# とか JavaScript とか。他にもあるけど、試験中の言語も多いので、趣味で使うのでなければ注意する必要がある
  • 開発環境は Visual Studio が使える。Azure ポータル上でコードを直接書いて実行も可能だが、よほど簡単なプログラムでない限り、VS でローカル開発・デバッグして、最後に Azure に発行して実行確認する流れが良いと思う
  • 使用料については、選択するプランによって異なる。従量課金と App Service プランの 2 種類が選択可能。App Service プランはその名の通り App Service 上で動かすので、App Service の料金に従う。従量課金については基本的にほぼ無料。具体的には月 100 万回までの実行は無料 (もう一つの条件として、実行に費やした合計メモリ使用量もある)。永続ファイルの保存先に Azure File Share を使用するので、ストレージ操作でも使用料は発生するが、よっぽどの実行状況でなければ使用料の事はあまり気にしないで使える
  • 制限として、実行時間が最大 10 分までと言う制限がある (従量課金の場合)。一応、App Service プランを利用することで時間制限はなくなるが、Functions 自体が軽く短い処理の実行を想定しているようなので、長くて重い (大量の CPU・メモリリソースを使う) 処理は、やめた方が良いかも (原因はわからないが、以前重い処理で使った時は、例外も出さずに処理が途中で終了することとかがあった・・・)

注意点

  • 上述したように軽く短い処理を想定しているので、長く重い処理の実行はやめた方が良いかも
  • 従量課金の場合、暫く実行されていないと、当該 Functions が動作しているインスタンスがリソース節約のために落とされてしまう。次のリクエストが来た時に改めて Functions 実行用のインスタンスが生成され、生成後に当該 Functions が実行されることになる。当たり前だが、インスタンスの生成自体に時間がかかる (コールド スタート問題)。自分が確認した限りでは、大体 5 秒から 10 秒ぐらい、追加で時間がかかった。即応性が求められないスケジュールバッチなどでは問題になりづらいが、即応性が求められる REST API などだと、要件を満たせるのか考慮が必要かも
  • 実行環境が元から用意されているため、裏を返すと、実行環境自体はあまり好きにいじれない。例えば、使用する言語のランタイムのバージョンとか。PowerShell のランタイムは現時点では 4 なので、要件で PowerShell バージョン 5 以上の機能を使う必要があるとかだと、Functions ではどうにもならない
  • 実行環境の話と関連するが、ローカル開発時と Azure 上での実行時環境に開きがある可能性があるので、Azure 上でも期待した動作となるかは、早めに確認した方が良い (Functions に限った話ではないが)