Skip to content

MS_FaaSConfig

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

FaaS config

概要

FaaS での config は？（PaaS では埋め込まれたリソース化して使ってたケド...。

補足（FaaS で config の扱いが変わる理由）: 原文の疑問は的確で、
FaaS では「設定ファイルを置く」という前提が崩れる。

【オンプレ / IaaS】
   Web.config / appsettings.json を【ファイルとして配置】
     → デプロイ先のディスクに置ける
     → [.NET config](MS_DotNetConfig) の世界

【PaaS（App Service 等）】
   ファイルも置けるが、【アプリ設定（環境変数）】が主流に
     → ポータル / ARM テンプレートで設定
     → 再デプロイなしで変更できる

【FaaS（Functions / Lambda）】
   ・インスタンスが【使い捨て】（スケールイン/アウトが激しい）
   ・ローカル ディスクは【一時的】
   ・起動が速いことが要求される（設定読み込みも軽くしたい）
     → 【環境変数が基本】★
     → 秘密情報は【Key Vault / Secrets Manager】へ

**12 Factor App の「設定は環境変数に持つ」**という原則が、
FaaS では実質的に強制される、と理解するとよい。

詳細

取り敢えず、２大 FaaS（Azure Functions, AWS Lambda）を調査。

Azure Functions v2

.NET

.NET Core

※ 余談：Open棟梁、以下の API で設定可能と思われる。

public static void InitConfiguration(IConfigurationBuilder builder)

補足（v1 → v2 の変化が本節の主題）: 参考リンクのタイトルが示す通り、
v2 で設定の読み方が根本的に変わった。

Functions v1（.NET Framework） Functions v2 以降（.NET Core / .NET）
設定の読み方 ConfigurationManager.AppSettings IConfiguration（ASP.NET Core と同じ）
設定ファイル App.config 的な発想 local.settings.json（ローカルのみ）
本番の設定 アプリ設定（環境変数） 同左
DI なし あり（IOptions<T> が使える）★ 
// 最も単純な読み方（今も有効）
var conn = Environment.GetEnvironmentVariable("MyConnection");

// DI + IConfiguration（推奨）
public class MyFunction
{
    private readonly MyOptions _options;
    public MyFunction(IOptions<MyOptions> options) => _options = options.Value;
}

原文が挙げる InitConfiguration(IConfigurationBuilder builder) は、
IWebJobsStartup / FunctionsStartup による初期化の形である。

[assembly: FunctionsStartup(typeof(MyApp.Startup))]
namespace MyApp
{
    public class Startup : FunctionsStartup
    {
        public override void ConfigureAppConfiguration(IFunctionsConfigurationBuilder builder)
        {
            builder.ConfigurationBuilder
                .AddJsonFile("custom.json", optional: true)
                .AddEnvironmentVariables();
        }

        public override void Configure(IFunctionsHostBuilder builder)
        {
            builder.Services.AddOptions<MyOptions>()
                .Configure<IConfiguration>((o, c) => c.GetSection("My").Bind(o));
        }
    }
}

**local.settings.json は「ローカル実行専用」**である点が
最も誤解されやすい。

・【デプロイされない】（.gitignore に入れるのが既定）
・本番の設定は【アプリ設定（環境変数）】として別に登録する
・「ローカルでは動くのに Azure で動かない」の典型的な原因 ★

// local.settings.json（ローカルのみ）
{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "MyConnection": "..."
  }
}

補足（現在の Functions のモデル）: 原文の時代の v2 から、
実行モデルがさらに変わったため補足する。

モデル 内容 現況
In-process Functions ホストと同じプロセスで動く .NET 8 で終了（2026-11 サポート終了）★
Isolated worker 別プロセスで動く。ランタイム版に依存しない こちらへ移行が必要 
// Isolated worker モデル（現在の標準）— Program.cs
var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureAppConfiguration(cfg => cfg.AddEnvironmentVariables())
    .ConfigureServices(services =>
    {
        services.AddOptions<MyOptions>().BindConfiguration("My");
    })
    .Build();
host.Run();
【Isolated の利点】
   ・【.NET の版をホストと independently に選べる】
   ・通常の ASP.NET Core と同じ書き方（Program.cs、DI、ミドルウェア）
   ・[.NET Core における DI](MS_DotNetCoreDI) の知識がそのまま使える

AWS Lambda

.NET

.NET のサポートなし。

.NET Core

.NET Core のサポートあり。

内容を見ると、Azure Functions と同じ。

補足（「Azure Functions と同じ」の中身）: 原文の結論は正しい。
どちらも環境変数が基本である。差分だけ挙げておく。

Azure Functions AWS Lambda
設定の入口 アプリ設定（＝環境変数） 環境変数
ローカル設定 local.settings.json template.yaml / .env
秘密情報 Key Vault 参照（@Microsoft.KeyVault(...)） Secrets Manager / Parameter Store
ID マネージド ID IAM ロール
.NET 対応 .NET 8 / 9（Isolated） .NET 8（マネージド ランタイム）
設定サイズ上限 — 環境変数は合計 4KB ★

AWS Lambda の 4KB 制限は実務で当たる。
大きな設定は Parameter Store / S3 から起動時に取得する。

**.NET のサポートなし（＝ .NET Framework）**という原文の記述は
現在も正しい。Lambda は Linux 上で動くため、
.NET Framework は原理的に動かない
（.NETのクロスプラットフォーム対応）。

補足（FaaS での設定の実務指針）: 両クラウドに共通する要点をまとめる。

① 秘密情報を環境変数に直接置かない

✗ 接続文字列・API キーを環境変数の値として直書き
     → ポータルで誰でも見える
     → ARM テンプレート / IaC のコードに残る
     → ログに出る事故

○ 【Key Vault 参照】にする
     MyConnection = @Microsoft.KeyVault(SecretUri=https://xxx.vault.azure.net/secrets/conn/)
     → 値は Key Vault にあり、Functions は【マネージド ID で取得】
     → ローテーションも Key Vault 側で完結

② 接続文字列そのものをなくす（最善）

// ✗ 接続文字列にキーを含める
new BlobServiceClient("DefaultEndpointsProtocol=...;AccountKey=xxxx");

// ○ マネージド ID で認証する（キーが存在しない）★
new BlobServiceClient(new Uri("https://xxx.blob.core.windows.net"),
                      new DefaultAzureCredential());
【DefaultAzureCredential の利点】
   ローカル： Visual Studio / Azure CLI のログインを使う
   本番：     マネージド ID を使う
     → 【同じコードで動く】。開発者にキーを配らなくて済む

③ 起動のたびに設定を読み直さない

FaaS は【コールド スタート】が性能を左右する
  ・設定の取得（Key Vault 呼び出し等）は【静的初期化で 1 回】
  ・HttpClient / DB 接続も使い回す（IHttpClientFactory）
  ・関数の呼び出しごとに new しない ★

④ 環境ごとの切り替え

・環境ごとに【別のリソース（Function App）】を作るのが基本
   → dev / stg / prod でアプリ設定を分ける
・デプロイ スロットを使う場合、
  【スロット設定（スロット固定）】のチェックを忘れない ★
   → 忘れると、スワップで接続先が入れ替わる事故になる

参考

Microsoft Learn

Tags: 移行, .NET開発

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally