お仕事 | 星と月と太陽と

AzureマルチリージョンでのDR構成をAzure Front Doorにアップグレードしてみる。

sei — Sun, 27 Jul 2025 06:39:14 +0000

どーも。seiです。久々の技術系ネタｗｗｗ

以前の投稿では、Azure Traffic Managerを使ってマルチリージョンのDR（ディザスターリカバリー）構成を構築しました。

ちわ。seiです。タイトルの通りです。DR（ディザスターリカバリー、災害復旧）構成、あるいは、冗長構成とかHA（高可用性）構成っていうのもほぼ同義かと思いますが、クラウドサービスを利用するとそんな構成が、あっという間に簡単に構築できます。オ...

コスパ重視でTraffic Managerをかませていましたが、今回はその構成をAzure Front Doorに置き換える手順を提示していきたいと思います。

Azure Front Doorとはなんぞや？という方は以下のサイトでご確認ください。

Azure Front Door の概要

この記事では、Azure Front Door の概要を示します。

今回のゴール&前提条件
Azure Front Doorの構築手順
Azure Front DoorでのDR構成が機能しているか確認
さいごに

今回のゴール&前提条件

今回のゴールは以下の構成図のような感じです。前回のDR構成を構築したところとの違いはTraffic ManagerがAzure Front Door(以降AFD)に置き換わるだけですので、それ以外の部分は今回は割愛させていただきます。前回の投稿を元に構築ください。

また、Azure Static Web Appsをフロントエンドとして追加しています。これはプライマリーリージョンにリソース作成していますが、グローバルに展開されるリソースなため既定でリージョン障害に対応しているので、リソースをプライマリーリージョンに1つだけデプロイします。

今回デプロイするAzure Functionsも自身のリソース名を返すだけの単純なものにして実行させます。ご自由に振る舞いを実装していただければと思います。

簡単に説明すると、クライアントからのリクエストをまずAFDが受けてトラフィックを振り分けます。サイトへのアクセス（/*）の場合はフロントエンドに振り分けます。フロントエンドはバックエンドに対してリクエストを投げますが、AFDを介してバックエンドのAzure Functionsにリクエスト(/api/*)が送信される感じになります。その時、プライマリーリージョンで障害が発生している場合は、フェールオーバーを行い、セカンダリーリージョンのAzure Functionsにリクエストが自動的に送信される構成を実現していきたいと思います。

【前提条件】

フロントエンドリソース（Azure Static Web Appsとか）がデプロイ済み
バックエンドAzure Functionsが2つのリージョンにデプロイ済み
（Azure Functionsの認証方法＝Functionの場合）2つのリージョンにデプロイしたAzure Functionsの関数キー（ホストキー）が共通化されている。
DNSレコード編集可能なカスタムドメインを保持している

上記のような前提条件のもと進めていきたいと思います。

Azure Front Doorの構築手順

AFDリソースの作成

まずはAzure Front Doorリソースをデプロイしていきます。マーケットプレイスから「Front Door」あたりで検索してもらえば出てくるはずの「Front Door and CDN profiles」を選択します。

Front Door and CDN profilesの「作成」ボタンをクリックします。

以下の画面が表示されます。本当は空っぽのところにいろいろ追加していこうと思ったのですが、なんかうまくできなかったので、上段の「Azure Front Door」を選択（これはマストですね）し、下段は「カスタム作成」を選択後、「フロントドアの作成を続行する」をクリックします。

以下の画面で、サブスクリプション、リソースグループなどを選択したら名前を入力し課金レベルを選択します。今回は「Standard」ティアを選択します。「次へ：シークレット」ボタンをクリックします。ちなみにStandardとPremiumの違いは、ボット対策やプライベートリンクなど追加のセキュリティ機能があるかないかとかですかね。

以下の画面では、持ち込みのSSL/TLS証明書を追加することができますが、Azure Front Doorが用意して自動で更新してくれる無料のマネージド証明書が利用できますので今回はパス。「次へ：エンドポイント」をクリックします。

Azure Front Doorでは、HTTPS通信を構成する際に「シークレット」という概念を使います。これは、Azure Key Vaultに格納されたSSL/TLS証明書をFront Doorが安全に参照するための設定情報です。シークレットを通じて証明書のバージョン管理や自動更新が可能となり、セキュリティと運用性の両立が図れます。

エンドポイントの作成

ここからがAFD設定の本番です。AFDの設定は「エンドポイント」、「ルート」、「配信元グループ」がキモとなってきます。

エンドポイントとルート、配信元グループは以下のような関連性になっています。一例です。

今回はリソース作成時に設定していこうと思いますが、あとで設定することも可能です。まずはエンドポイントを作成していきますので、「エンドポイントの追加」ボタンをクリックします。

「エンドポイントの追加」パネルが表示されるので、エンドポイント名を入力します。今回は「dr-demo」というエンドポイント名にします。すると自動的にエンドポイントのホスト名が生成されます。よろしければ「追加」をクリックしましょう。

ルートの作成

エンドポイントが作成されると以下の画面になります。作成されたエンドポイントのホスト名は赤下線で示す場所に表示されます。エンドポイントの配下にルートを追加していきましょう。「ルートの追加」をクリックします。

カスタムドメインの割り当て

ルートの追加ブレードが表示されます。まずはAFDにカスタムドメインを追加したいと思うので、「新しいドメインの追加」をクリックします。ここでカスタムドメインを追加する必要はなく、もちろん後から設定可能です。

ドメインの追加ブレードが表示されるので、以下の表のとおり設定して「追加」をクリックしましょう。ちなみに今回はエックスサーバーで管理している当サイトのドメインにサブドメインを追加してAFDのカスタムドメインとして利用するテイで進めます。

設定項目	設定値
ドメインの種類	Azure以外の検証済みドメイン
DNSの管理	その他すべてのDNSサービス
カスタムドメイン	（自身で管理しているAFDに割り当てるドメインを入力）
証明書の種類	AFDマネージド（推奨）
TLSポリシー	よしなに。最新でいいと思う。。。

すでにAzure Static Web Appsなどの別リソースにカスタムドメインを割り当てている場合、[ドメインの種類]で「Azureの事前検証済みドメイン」を選択すると、［事前検証済みのカスタムドメイン］にその設定済みのドメインがでてくるので、簡単だ～とつい選びたくなってしまうのですが、その場合、AzureマネージドSSL証明書の更新はカスタムドメインを割り当てたリソースに依存します。

【参考リンク】https://learn.microsoft.com/ja-jp/azure/frontdoor/domain#rotate-own-certificate

ですのでAFDにカスタムドメインを割り当てたあと、もう不要だとSWAのカスタムドメインを削除しようものならSSL証明書の更新が出来ず、サイトは停止します。この一文（「Azure マネージド証明書は、ドメインを検証する Azure サービスによって自動的にローテーションされます。」）で理解するのはちょっとハードル高すぎますが、（せめて「AFDは他のリソースで割り当てたカスタムドメインの証明書まで更新はせんよ！！」くらい書いてよ・・・自分の理解力のなさ？）極力AFD側で証明書の更新が可能なように「AFDマネージド」証明書を利用するのがよいのではないでしょうか。（ちなみにリソース正常性アラートもしっかり確認しましょうよｗｗｗ）

カスタムドメインの追加が完了すると、ルートの追加ブレードに戻ってくるので、ルート名を入力し、先ほど追加したカスタムドメインにチェックを付け、デフォルトのドメインは利用しないのでチェックを外しましょう。カスタムドメインはあとの手順で検証作業が必要になります。次に配信元グループを追加するので、「新しい配信元グループを追加する」をクリックします。

配信元グループの作成

［配信元グループの追加］パネルが表示されるので、適当な名前を入力しましょう。今回はフロントエンドの配信元とするので、「drdemo-frontend-group」としました。次に「配信元の追加」をクリックします。

［配信元の追加］パネルが表示されます。フロントエンドのアプリを配信元として設定していくので、［配信元の種類］を「静的WEBアプリ」、［ホスト名］にフロントエンドアプリとして利用するSWAリソースを指定し、「追加」ボタンをクリックしましょう。

［配信元グループの追加］パネルに戻り、配信元のホスト名としてフロントエンドアプリが表示されて有効になっていればOKです。「追加」をクリックしていきましょう。

［ルートの追加］ブレードに戻ってきます。配信元グループとして先ほど作成した配信元グループ名がセットされていることを確認します。あ、「一致するパターン」ですが、フロントエンドアプリとしてすべてSWAに流すので、ここでは「/*」のままでOKです。ご自身の環境に合わせてご対応ください。また、CDNとしてキャッシュを利用する方も「キャッシュを有効にする」をよしなに。「追加」ボタンをクリックします。

［Front Doorプロファイルの作成］画面まで戻ってきました。作成したルート、配信元グループ、ドメインが表示されているのが確認できます。フロントエンドとしての設定は完了したので、あとはバックエンドのルートを追加しようと思ったのですが、なぜか更なる「ルートの追加」が出来んかった・・・(。´･ω･)?なぜ？ちょっとわからないので、バックエンド用のルートはリソース作成後の画面から行っていきたいと思います。あ、あと今回はWAF機能は利用しませんので割愛します。「確認および作成」ボタンをクリックしましょう。

「作成」をクリックすればリソースの作成が始まります。

無事AFDリソースのデプロイが完了しました。それではリソース作成時にはできなかったバックエンド用のルート作成を追加で行っていきましょう。「フロントドアマネージャー」を選択します。

フロントドアマネージャーからのルート追加

［フロントドアマネージャー］ブレードが開きます。基本的な操作はフロントエンド用ルートを作成したリソース作成時の操作と一緒です。エンドポイントに対して「ルートの追加」を行っていきます。

ルートを追加していきます。バックエンド用ルートということがわかるような名前を付けましょう。あ、ルートのスペル間違ってますね。正しくはrouteですね。お気になさらずｗ

ドメインはリソース作成時に追加したカスタムドメインを選択します。

以下のエラーが表示されます。要するに「どっちのルートに行くかの判断ができない同じURLパターンが設定されているよ」とのことですので、フロントエンド用ルートで設定済みの「/*」を削除して、Azure Functionsのエンドポイントとなる「/api/*」を追加しましょう。（直接「/*」を「/api/*」に変更してももちろんOK）

次にバックエンド用の配信元グループをこのルートに追加します。「新しい配信元グループを追加する」をクリックします。

名前を入力して「配信元の追加」をクリック。

［配信元の追加］パネルが表示されるので、バックエンドAzure Functionsを設定するので、［配信元の種類］を「App Services」、［ホスト名］にまずはプライマリーリージョンのAzure Functionsリソースを指定し、「追加」ボタンをクリックしましょう。

プライマリーリージョンのAzure Functionsが配信元として追加されました。同様に「配信元の追加」を行い、今度はセカンダリーリージョンのAzure Functionsを配信元として追加しましょう。

［配信元の種類］を「App Services」、［ホスト名］にセカンダリーリージョンのAzure Functionsリソースを指定します。また、優先順位をプライマリーリージョンで設定されている優先順位より大きな値（今回は「2」）に変更後、「追加」ボタンをクリックします。

配信元グループとして２つのリージョンにあるAzure Functionsが追加されました。優先順位値が小さいホストに優先的にトラフィックが割り当てられる形で負荷分散が行われます。

ルートの追加ブレードに戻ってきました。バックエンド用の配信元グループが設定されているのを確認し、「追加」をクリックしましょう。

フロントドアマネージャーに戻ってきました。エンドポイントにフロントエンド用とバックエンド用の２つのルートが存在するようになっていればOKですね。最後に追加したカスタムドメイン追加に関する手順を行っていきたいと思います。「ドメイン」をクリックしてください。

カスタムドメインの所有権確認＆エンドポイントのリダイレクト設定

カスタムドメインは追加しただけではそのまま利用できません。ご自身が所有するドメインであるかどうかの検証と、カスタムドメインでアクセスされたときにAFDエンドポイントへリダイレクトされるようにDNSレコードにCNAMEレコードの追加が必要です。

カスタムドメインの所有権確認

［ドメイン］ブレードで［検証の状態］を確認すると、所有権の検証が済んでいないと「保留中」となっていると思います。「保留中」をクリックします。

以下のパネルが表示されるので、「レコード名」、「レコードの値」を、ドメインを管理しているDNSプロバイダーのDNSレコード管理画面で追加してください。自分はエックスサーバーですので、エックスサーバーサーバーパネルの［ドメイン］－［DNSレコード設定］よりTXTレコードとして追加しました。

DNSレコードを追加した後、しばらく（結構待つと思う・・・）すると検証の状態が「承認済み」になればカスタムドメインの所有権の確認はOKです。ですがまだ「DNSの状態」が「CNAMEまたはエイリアスレコードが検出されていません」となっているのでこれを解決してAFDの導入が完了します。

カスタムドメインとAzure Front Doorエンドポイントとの関連付け

最後の手順です。カスタムドメインでアクセスされたときにAFDにリダイレクトされるように設定していきたいと思います。

まずはAFDのフロントドアマネージャーにアクセスし、AFDのエンドポイントをコピーします。

次にドメインのDNSプロバイダーの管理画面よりCNAMEレコードとしてコピーしたAFDのエンドポイントを登録してください。自分はエックスサーバーですので、こんな感じ。

こちらもそこそこ結構な時間かかると思いますが、DNSの状態が「トラフィックは安全に配信されます」になれば無事Azure Front Doorのセットアップ完了です。お疲れさまでした！！

Azure Front Doorはグローバルなサービスであるため、DNSレコードの検証も世界中のエッジノードから行われます。DNSレコードが一部の地域で反映されていても、他の地域ではまだキャッシュが残っている可能性があり、これが「承認済み」や「トラフィックは安全に配信されます」になるまでの遅延につながるようです。

Azure Front Doorのセットアップが完了しました。これが今回の最終形態です。

Azure Front DoorでのDR構成が機能しているか確認

それでは最後に稼働確認を行っていくのですが、まずはバックエンドAzure FunctionsのCORS設定をカスタムドメインを受け入れるように忘れずに変更しておきましょう。プライマリー、セカンダリー、両方ともね。また、プライマリーとセカンダリーのAzure Functionsの認証がFunctionsの場合はアプリキーの共通化も忘れずに行っておいてください。

では、まずは通常パターン。プライマリーリージョンがピンピンしている場合。ちゃんと「primary」が返ってきているのでプライマリーリージョンのAzure Functionsが呼び出されているのが確認できます。

それでは次にリージョン障害が発生したシチュエーションを。プライマリーリージョンのAzure Functionsを停止させます。

プライマリーリージョンのバックエンドが停止しました。

この状態でフロントエンドStatic Web Appsを起動してリクエストをバックエンドに送信してみます。おお！「secondary」が返ってきているのでちゃんとセカンダリーリージョンのバックエンドにフェールオーバーされたことが確認できました！素晴らしい(*^^)v

最後に停止させていたプライマリーリージョンのAzure Functionsを再開させてもう一度フロントエンドを実行します。OK！！ちゃんとプライマリーリージョンのバックエンドにフェールバックされました。いいね～～～～。

さいごに

Azure Front Doorの構築は、一見複雑に見えるかもしれませんが、エンドポイント・ルート・配信元グループの関係性をしっかり把握していれば、実は非常にシンプルかつ論理的です。今回の投稿ではCDNやWAFなどのセキュリティ・高速化機能には触れていませんが、AFDはそれらを必要に応じて柔軟に組み合わせられる点が大きな魅力です。

価格面ではTraffic Managerより大分お高めですが、WAFによるセキュリティ強化、CDNによる高速配信、Private Linkによる安全なバックエンド接続など、トラフィック分散だけにとどまらない多機能性がAFDの強みです。さらに、AFD経由以外のアクセスを遮断する制御も可能で、

バックエンドをパブリックに晒すことなく、安全な構成を実現できる！すごくいいっ！！

おまけに、Cookieを扱っているのならサードパーティCookieとして最近のブラウザーのCookie規制強化の影響も受けることなくバックエンドとフロントエンドのカスタムドメインを統一する手間も省ける！！ディ・モールト、ディ・モールト、良いぞッ！！

グローバルな可用性、セキュリティ、パフォーマンスを一手に担えるこのサービスは、モダンなWebアーキテクチャの中核として非常に優秀だと感じています。

以上、DR構成時におススメのAzure Front Doorに変えてみた編でした！！

システムエンジニアランキング

にほんブログ村

The post AzureマルチリージョンでのDR構成をAzure Front Doorにアップグレードしてみる。 first appeared on 星と月と太陽と.

Azure Functions .NET6インプロセスモデルから.NET8分離ワーカーモデルへの移行

sei — Sun, 07 Apr 2024 03:54:17 +0000

こんにちは。seiです。桜の花の開花がこんなにも遅くなってるのは久々な気がする今日この頃。これが普通の状態なのか異常なのか、もうよくわかんなくなってきますね。

さて、今日は2024年11月にサポート終了が迫っている.NET6のAzure Functionsアプリケーションを、その次のLTS（長期サポート）リリースである「.NET8」へアップグレードすべく、事前に検証してみましたので、その手順を投稿していこうと思います。

.NET および .NET Core の公式サポートポリシー | .NET

ランタイム、ASP.NET Core、Entity Framework Core など、いくつかのテクノロジを指す .NET と .NET Core のサポートポリシーについて説明します。

ちなみに、以前は.NET8ではインプロセスモデルはサポートされず、分離ワーカーモデルのみになると思っていましたが、ここにきてインプロセスモデルも利用可能と理解しました。しかしながら、結局はインプロセスモデルは廃止の方向のようなので、もう.NET8への移行と同時にインプロセスモデルから分離ワーカーモデルへの移行も併せて行ってしまおうというのが今回の趣旨です。

Azure Functions インプロセスモデルのサポート終了について(追跡 ID FVN7-7PZ)

Azure Functions をお使いいただいております .NET のインプロセスモデル環境において、追跡 ID FVN7-7PZ として以下のアナウンスメントが行われています。今回はこのアナウンスメントに関して、多数のお問い合わせをい...

はじめに
Azure Functions .NET8 分離ワーカーモデルへの移行手順
さいごに

はじめに

基本的には、MSさんのLearnにあるこの情報を元ネタとして実施しています。が、この手順ですと、ASP.NETCore統合としてAzure Functionsを構成しますが、今回は「組み込みの Functions HTTP 型」っていうの？つまりASP.NETCore統合不使用（HttpRequestDataとかHttpResponseData使うヤツ）での移行を行っていきます。

C# アプリをインプロセスから分離ワーカーモデルに移行する

インプロセスモデルの.NETで実行されている既存の C# 関数アプリを分離ワーカーモデルに移行する方法について説明します。

Azure Functions .NET8 分離ワーカーモデルへの移行手順

移行対象とするのは、下記の.NET6インプロセスモデルのAzure Functionsコードになります。

このコードでは、HTTPトリガーでクライアントからのHTTPリクエストを受け取り、Queue出力バインドで複数の値をQueue出力を行うというものです。

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace DotNet8MigrationFunctionApp
{
    public static class Function1
    {
        [FunctionName("Function1")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            [Queue("my-queue-items"), StorageAccount("AzureWebJobsStorage")] ICollector outputQueues,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            for (int i = 0; i < 3; i++)
            {
                outputQueues.Add($"{i}：{name}");
            }

            return new OkObjectResult($"Hello,{name}!");
        }
    }
}

実行するとこんな感じ。

HTTPリクエストを受け取り、URLパラメーターで受け取った内容を出力する。

そして、QueueにURLパラメーターで受け取った内容を3回出力する。

それでは早速移行していきますが、おおまかな手順としては以下の感じになっています。

csprojファイルの編集
パッケージ参照の変更
Program.csファイルの追加
関数アプリコードの変更

それではひとつづつ順番に行っていきましょ～。

csprojファイルの編集

まずはC#のプロジェクトファイルのcsprojファイルを変更します。

以下が変更前のcsprojファイル。


  
    net6.0
    v4
  
  
    
    
    
  
  
    
      PreserveNewest
    
    
      PreserveNewest
      Never

変更内容は以下のとおり。

①の値を「net6.0」→「net8.0」に変更します。

②ExeをPropertyGroup内に追加します。

③ItemGroupの「Microsoft.NET.SDK.Functions」へのパッケージ参照を以下の内容に書き換えます。

④「Microsoft.Azure.WebJobs」や「Microsoft.Azure.Functions.Extensions」名前空間のパッケージがある場合は削除します。

※削除する！！

⑤以下のItemGroupを追加します。

最終的に変更されたcsprojファイルは以下のような感じになると思います。


  
    net8.0
    v4
    Exe
  
  
    
    
    
    
    
    
  
  
    
      PreserveNewest
    
    
      PreserveNewest
      Never

パッケージ参照の変更

続いて、パッケージ参照を変更していきます。基本的には「Microsoft.Azure.WebJobs」や「Microsoft.Azure.Functions.Extensions」名前空間のパッケージで利用していた拡張機能を「Microsoft.Azure.Functions.Worker.Extentions」名前空間のパッケージとしてインストールしなおす感じです。

①NuGetパッケージマネージャーを開きます。コンソールがお好みの方はよしなに。

②利用するバインドなどのパッケージをインストールします。ここではQueue出力バインドを利用していますので、「Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues」パッケージをインストールします。

詳しくは以下のリンクにて。

C# アプリをインプロセスから分離ワーカーモデルに移行する

インプロセスモデルで .NET で実行されている既存の C# 関数アプリを分離ワーカーモデルに移行する方法について説明します。

Program.csファイルの追加

Program.csファイルを追加して以下のコードを記述していきます。すでにDIなど利用している場合はFunctionsStartup属性のついたStartup.csをProgram.csにリネームしていく感じでしょうか。必要であればDIも記述します。また、JSONシリアル化設定なども必要であれば追記します。

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using System;
using System.Text.Encodings.Web;
using System.Text.Json;
using System.Text.Unicode;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
        // JSONシリアル化オプションを設定する
        services.Configure(options =>
        {
            options.AllowTrailingCommas = true;                                         // 末尾のカンマを無視する
            options.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;       // nullのフィールドはシリアル化時に含めない
            options.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;                  // camelケースで出力
            options.Encoder = JavaScriptEncoder.Create(UnicodeRanges.All);              // 漢字可
            options.PropertyNameCaseInsensitive = true;                                 // 逆シリアル化時に大文字小文字を区別しない
            options.WriteIndented = true;                                               // JSONを整形
        });
    })
    .Build();

host.Run();

関数アプリコードの変更

あとは実際に関数アプリコードを書き換えていくだけです。変更前のAzure Functions .NET6インプロセスモデルのコードを再掲します。

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace DotNet8MigrationFunctionApp
{
    public static class Function1
    {
        [FunctionName("Function1")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            [Queue("my-queue-items"), StorageAccount("AzureWebJobsStorage")] ICollector outputQueues,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            for (int i = 0; i < 3; i++)
            {
                outputQueues.Add($"{i}：{name}");
            }

            return new OkObjectResult($"Hello,{name}!");
        }
    }
}

変更ポイントは以下の通り。

[FunctionName]属性を[Function]属性に変更する
DIでIloggerを受け取り、コード内のlogインスタンスと置換する
usingの書き換え
staticクラス・メソッドをインスタンスクラス・メソッドに変更
トリガーやバインディングの変更
local.settings.jsonファイルの「FUNCTIONS_WORKER_RUNTIME」値を「dotnet-isolated」に変更

それでは一つ一つ見ていきます。

[FunctionName]属性を[Function]属性に変更する

public static class Function1
{
    [FunctionName("Function1")]
    public static IActionResult Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
        [Queue("my-queue-items"), StorageAccount("AzureWebJobsStorage")] ICollector outputQueues,
        ILogger log)

となっているのを

public static class Function1
{
    [Function("Function1")]　// ←ここ
    public static IActionResult Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
        [Queue("my-queue-items"), StorageAccount("AzureWebJobsStorage")] ICollector outputQueues,
        ILogger log)

と[Function(関数クラス名)]に書き換えるだけです。

ILoggerのDI

①まずは以下のコードを関数クラスのメンバーとして宣言します。

private readonly ILogger _logger;

②関数クラスのコンストラクターを宣言し、ILoggerオブジェクトを受け取って①で宣言した変数に代入します。

public Function1(ILogger logger) {
    _logger = logger;
}

③次に関数メソッドが受け取っているILoggerインスタンスを削除します。

[Function("Function1")]
public static IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
    [Queue("my-queue-items"), StorageAccount("AzureWebJobsStorage")] ICollector outputQueues,
    ILogger log)　// ←削除

こうなります。

[Function("Function1")]
public static IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
    [Queue("my-queue-items"), StorageAccount("AzureWebJobsStorage")] ICollector outputQueues)

④そして、コード内のlogオブジェクトを_loggerオブジェクトに変更します。

log.LogInformation("C# HTTP trigger function processed a request.");

を

_logger.LogInformation("C# HTTP trigger function processed a request.");

って感じに直します。

usingの書き換え

不要な「using Microsoft.Azure.WebJobs;」をすべて削除し、「using Microsoft.Azure.Functions.Worker;」を追加します。

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;　// ←削除
using Microsoft.Azure.WebJobs.Extensions.Http;　// ←削除
using Microsoft.Azure.Functions.Worker;　// ←追加
using Microsoft.Extensions.Logging;

こうなります。

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

staticクラス・メソッドをインスタンスクラス・メソッドに変更

public static class Function1  // ←staticを削除
{
    private readonly ILogger _logger;

    public Function1(ILogger logger)
    {
        _logger = logger;
    }

    [Function("Function1")]
    public static IActionResult Run(  // ←staticを削除
        [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
        [Queue("my-queue-items"), StorageAccount("AzureWebJobsStorage")] ICollector outputQueues)

を

public class Function1
{
    private readonly ILogger _logger;

    public Function1(ILogger logger)
    {
        _logger = logger;
    }

    [Function("Function1")]
    public IActionResult Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
        [Queue("my-queue-items"), StorageAccount("AzureWebJobsStorage")] ICollector outputQueues)

に変更します。

トリガーやバインディングの変更

この手順はちょっと癖あります。基本的にはトリガーはそのまま、入力バインドはインプロセスモデル時の属性値に「Input」を付けましょうとあります。例えば、[Blob(“sample/fileName”, FileAccess.Read, Connection = “MyStorageConnection”)]だったとしたら、[BlobInput(“sample/fileName”, Connection = “MyStorageConnection”)]に変わります。Accessプロパティは不要です。

そして、出力バインドですが、入力バインドと同様に通常は「Output」を付与するとあります。ですが、今回の例では、Httpトリガーとして、クライアントにHttpレスポンスを返しつつ、Queueストレージにエンキューを行う必要があります。要するに複数の出力バインドがあるというシチュエーションを実装してみます。

元ネタはここです。

分離されたワーカープロセスで C# Azure Functionsを実行するためのガイド

.NET分離ワーカーモデルを使用して Azure で C# 関数を実行する方法について説明します。これにより、現在サポートされているバージョンの .NET および .NET Framework で関数を実行できます。

①新しいクラスを追加します。今回はCustomResponseというクラス名で追加します。そして、そこにHttpResponseを返すプロパティとQueue出力バインド用のプロパティを追加しておきます。Queue出力バインドを返すプロパティには[QueueOutput(“my-queue-items”, Connection=”AzureWebJobsStorage”)]といった感じで属性を設定しておきます。また、Queue出力バインドは1度に複数の値をエンキューしているので、Listオブジェクトといったコレクションや配列で用意する必要があります。

public class CustomResponse
{
    public CustomResponse()
    {
        OutputQueue = new List();
    }

    public IActionResult Response { get; set; }

    [QueueOutput("my-queue-items", Connection = "AzureWebJobsStorage")]
    public List OutputQueue { get; set; } 
}

②次に、メソッド宣言を変更し、CustomResponseを返すようにし、Queueのバインドを削除します。

[Function("Function1")]
public IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
    [Queue("my-queue-items"), StorageAccount("AzureWebJobsStorage")] ICollector outputQueues)

これを

[Function("Function1")]
public CustomResponse Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req)

このように変更します。

③最後に、メソッド内でIActionResultを返しているコードを①で追加したCustomResponseオブジェクトで返すように変更します。

var response = new CustomResponse();

response.Response = new OkObjectResult($"Hello,{name}!");

for (int i = 0; i < 3; i++)
{
    response.OutputQueue.Add($"{i}：{name}");
}

return response;

local.settings.jsonファイルの「FUNCTIONS_WORKER_RUNTIME」値を「dotnet-isolated」に変更

最後にlocal.settings.jsonに分離ワーカーモデルを利用することを明示していきます。

FUNCTIONS_WORKER_RUNTIMEの値を「dotnet」から「dotnet-isolated」に変更します。

local.settings.jsonですので、言うまでもなく、ローカルデバッグでの設定です。この値が有効になるのはデバッグ時ですので、Azure実行環境でも同様の変更が必要ですが、後述します。

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"       // ← dotnetからdotnet-isolatedに変更
    }
}

.NET8分離ワーカーモデル(ASP.NET Core統合)移行後のコード全体像

Azure Functionsの.NET6インプロセスモデルから、.NET8分離ワーカーモデル（ASP.NETCore統合）移行後のコード全体像は以下の通りです。

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
using System.Collections.Generic;

namespace DotNet8MigrationFunctionApp
{
    public class CustomResponse
    {
        public CustomResponse()
        {
            OutputQueue = new List();
        }

        public IActionResult Response { get; set; }

        [QueueOutput("my-queue-items", Connection = "AzureWebJobsStorage")]
        public List OutputQueue { get; set; } 
    }

    public class Function1
    {
        private readonly ILogger _logger;

        public Function1(ILogger logger)
        {
            _logger = logger;
        }

        [Function("Function1")]
        public CustomResponse Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            var response = new CustomResponse();
            
            response.Response = new OkObjectResult($"Hello,{name}!");

            for (int i = 0; i < 3; i++)
            {
                response.OutputQueue.Add($"{i}：{name}");
            }

            return response;
        }
    }
}

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"       
    }
}

それではデバッグ実行してみます。無事Fucntionsホストが立ち上がりました。が、分離ワーカーかどうかははっきりわかりませんが、インプロセスの時と表示が若干違うのはわかります。

それではHTTPトリガーにリクエストを投げてみます。

あれ？レスポンスの文字列が返ってこない・・・orz

でも、Queueにはちゃんとエンキューされてる。

いろいろ調べたがどうしてもわからなかった。けど、単体のHTTPトリガーなんかはうまくいくのでもしかして、マルチレスポンスでHTTPとQueueを出力してるのが悪いのかなぁと憶測。

2024/06/11追記

Microsoft.Azure.Functions.Worker.Sdkのバージョン1.17.3-preview2以降かつ、Microsoft.Azure.Functions.Worker.Extensions.Http拡張機能のバージョン3.2.0以降かつ、Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCoreのバージョン1.3.0以降をインストールして、IActionResultに[HttpResult]属性をつけることで解決しました。

public class CustomResponse
{
    public CustomResponse()
    {
        OutputQueue = new List();
    }

    [HttpResult]
    public IActionResult Response { get; set; }

    [QueueOutput("my-queue-items", Connection = "AzureWebJobsStorage")]
    public List OutputQueue { get; set; } 
}

ちゃんとマルチレスポンスで返ってくるのを確認。いぇいv

ってことでASP.NETCore統合でいい方はここまででコードの移行は完了ですかね。

~~試しに、ASP.NET Core統合をやめて実装しなおしてみます。~~

ASP.NETCore統合ではなく、組み込み型モデルに書き換える方は引き続き次の手順をどうぞ。

Azure Functions .NET 8 IsolatedをASP.NET Core統合なしに書き換え

ということで、~~うまくレスポンスが返ってきませんでしたので、~~ASP.NET Core統合をやめ、非ASP.NET Core統合（組み込みFunctionsHTTP型）に書き換えていきます。

①NuGetパッケージマネージャーから「Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore」パッケージをアンインストールします。

②NuGetパッケージマネージャーから「Microsoft.Azure.Functions.Worker.Extensions.Http」パッケージをインストールします。

③Program.csのコードを変更し、ASP.NET Core統合を削除する。

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using System;
using System.Text.Encodings.Web;
using System.Text.Json;
using System.Text.Json.Serialization;
using System.Text.Unicode;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()  // ←このコードを変更
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
        // JSONシリアル化オプションを設定する
        services.Configure(options =>
        {
            options.AllowTrailingCommas = true;                                         // 末尾のカンマを無視する
            options.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;       // nullのフィールドはシリアル化時に含めない
            options.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;                  // camelケースで出力
            options.Encoder = JavaScriptEncoder.Create(UnicodeRanges.All);              // 漢字可
            options.PropertyNameCaseInsensitive = true;                                 // 逆シリアル化時に大文字小文字を区別しない
            options.WriteIndented = true;                                               // JSONを整形
        });
    })
    .Build();

host.Run();

これを、

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using System;
using System.Text.Encodings.Web;
using System.Text.Json;
using System.Text.Json.Serialization;
using System.Text.Unicode;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()  // ←このように変更
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
        // JSONシリアル化オプションを設定する
        services.Configure(options =>
        {
            options.AllowTrailingCommas = true;                                         // 末尾のカンマを無視する
            options.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;       // nullのフィールドはシリアル化時に含めない
            options.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;                  // camelケースで出力
            options.Encoder = JavaScriptEncoder.Create(UnicodeRanges.All);              // 漢字可
            options.PropertyNameCaseInsensitive = true;                                 // 逆シリアル化時に大文字小文字を区別しない
            options.WriteIndented = true;                                               // JSONを整形
        });
    })
    .Build();

host.Run();

④以下のようにコードを変更します。（変更箇所はコメントにて記述）

using Microsoft.AspNetCore.Http;    // ←不要になるので削除
using Microsoft.AspNetCore.Mvc;     // ←不要になるので削除
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;    // ←追加
using Microsoft.Extensions.Logging;
using System.Collections.Generic;
using System.Threading.Tasks;       // ←非同期なら追加

namespace DotNet8MigrationFunctionApp
{
    public class CustomResponse
    {
        public CustomResponse()
        {
            OutputQueue = new List();
        }
                
        public HttpResponseData Response { get; set; }      // ←IActionResultからHttpResponseData型に変更

        [QueueOutput("my-queue-items", Connection = "AzureWebJobsStorage")]
        public List OutputQueue { get; set; } 
    }

    public class Function1
    {
        private readonly ILogger _logger;

        public Function1(ILogger logger)
        {
            _logger = logger;
        }

        [Function("Function1")]
        public async Task Run(      // ←今回はAsyncにした。よしなに。
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequestData req)        // ←HttpRequestからHttpRequestData型に変更
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            var response = new CustomResponse();

            response.Response = req.CreateResponse();       // ←HttpRequestDataオブジェクトのCreateResponseメソッドからHttpResponseDataを取得する
            response.Response.StatusCode = System.Net.HttpStatusCode.OK;        // ←Httpステータスコードをセットする
            response.Response.Headers.Add("Content-Type", "text/plain; charset=utf-8");     // ←レスポンスヘッダーをセットする
            await response.Response.WriteStringAsync($"Hello,{name}!");     // ←レスポンスボディに書き込む

            for (int i = 0; i < 3; i++)
            {
                response.OutputQueue.Add($"{i}：{name}");
            }

            return response;
        }
    }
}

それでは、実行してみます。

今度は、ちゃんとHTTPレスポンスも帰ってきました。

Queueへの書き込みもばっちりです。ひとまずコードの移行は問題なさそうです。

Azure実行環境への反映

最後に、.NET8分離ワーカーモデルへと移行したAzure FunctionsコードをAzure実行環境にデプロイしていきましょう。シチュエーションとしてはAzure実行環境は.NET6インプロセスモデルで稼働しているという前提でデプロイを行ってみます。

ランタイムスタックが.NET6のAzure Functions本番系リソースを用意します。そして移行前のAzure Functionsコードがデプロイ済みです。

また、上記Azure Functionsのデプロイスロットを用意し、ステージング環境とします。もちろんこちらも.NET6インプロセスモデルのAzure Functionsです。

そして、local.settings.jsonで行ったのと同じことをAzure実行環境でも行います。[設定]－[環境変数]から、[アプリ設定]にアクセスし、ステージング環境のスロットの「FUNCTIONS_WORKER_RUNTIME」の値を「dotnet」から「dotnet-isolated」に変更し、保存を行います。

環境変数のUI、変わったんですねぇ・・・。というかいろんなところ変わってますが。

それではAzure Functionsリソースにコードをデプロイしていきます。パイプラインを組んでいる方がほとんどだと思いますが、パイプライン経由でAzure Functionsのバージョンアップまで行ってくれるか検証してないので、今回はLearnにある通り手動デプロイ時の自動アップグレードで行ってみます。

Azure Functionsアプリの公開プロファイルを作成します。

プロファイルができたら「発行」ボタンをクリックします。

以下のランタイムバージョン更新ダイアログが表示されるので、「はい」ボタンを押下しましょう。

デプロイが完了したら、Azure Functionsステージングスロットのリソースを確認してみます。ランタイムスタックが「.NET 8」に更新されているのが確認できました！

全般設定を見れば「.NET 8 Isolated」となっているので、分離ワーカーモデルとして動いていることも確認できました。

さいごに

ステージングにデプロイを行って稼働確認がOKになったら、後は本番スロットにスワップを行えば、晴れて.NET 8 分離ワーカーモデルへの移行が完了になります。

スワップしてステージング環境に移った旧本番系に再度手動デプロイを行って.NET 8へのアップグレードを行わないと次回おかしなことになっちゃいますかね？そこまでは試してないですが。「dotnet-isolated」の変更を忘れずに。

実際移行してみて、今回のHTTP＆Queue出力といったような複数の出力を行うのにわざわざクラス定義しなきゃとか、ぶっちゃけめんどいですね。さらに、分離ワーカーというか、HttpRequestData、HttpResponseDataがモックしづらいので、UTコードがちょっとやばいです。というか実装してません。なんとかしてくれることを期待するのみです・・・。その辺も考慮に入れたうえでインプロセスのまま、まずは.NET8への移行だけしていくというが選択肢でもいいのかなぁと思います。今回は移行しちゃいましたが。

コード量多いとさすがに対応負担大きいので計画的に移行していきましょう。

以上、Azure Functionsを.NET8分離ワーカーモデルに移行してみました。

システムエンジニアランキング

にほんブログ村

The post Azure Functions .NET6インプロセスモデルから.NET8分離ワーカーモデルへの移行 first appeared on 星と月と太陽と.

Azure Communication Servicesを利用してメール送信してみる

sei — Sat, 03 Feb 2024 10:42:09 +0000

こんにちわ。今日はAzure Communication Services（以下ACS）を利用したメール送信を行ってみたいと思います。また、ACSにカスタムドメインとして当ドメインを設定し、当ドメインからのメールとして迷惑メールとならずにクラウドメールを利用する方法をエックスサーバーへの設定方法として実施していきます。

Azure Communication Servicesとは？
1. なぜAzure Communication Services？
Azure Communication Servicesを利用したメール送信
1. ACSリソースの作成
  1. Communication Services Emailリソースの作成
  2. Communication Servicesリソースの作成
2. ACSでのメール送信をC#で実装する
Azure Communication Services Emailにカスタムドメインを設定する
さいごに

Azure Communication Servicesとは？

「Azure Communication Servicesとは、マイクロソフトのクラウドプラットフォームであるAzureが提供する統合通信サービスです。このサービスを利用すると、音声やビデオでの通話、チャット、SMS、メールなどのリアルタイム通信機能を簡単にアプリケーションに組み込むことができます。」とCopilotさんが言っています。

https://azure.microsoft.com/ja-jp/products/communication-services/

なぜAzure Communication Services？

Azureに限らないかもしれませんが、クラウドサービスで送信メールサーバーを立てることは推奨されておらず、クラウドからメールを送信したい場合は基本的にはSendGridなどのリレー方式のメール送信サービスを利用するのが定石かと思います。

SendGrid | クラウドメール配信サービス・メルマガ配信システム

世界中のマーケターや開発者が使っているメール配信サービス「SendGrid」。月間1,000億通以上の配信実績、高いメール到達率！豊富なAPIでシステム連携も簡単に！

SendGridは到達率が高く、いろいろといいサービスなんですが、如何せん価格が高い・・・。Proの最安プランで月額13,000円超で10万通まで送信可能。ただ、月間送信数が少ないと大分無駄になってしまっています。月間送信通数が少ない方はACSメールサービスにリプレイスすればごっそり支払い料金を節約できるという感じ。

そして、昨今の迷惑メール対策として、SPFやDKIM認証がSendGridでも必須化されていくことに伴い、いっそのことカスタムドメインではSPF・DKIMマストなACSに乗り換え検討してみようかというのがことの発端です。

さらに今まで国内でのデータ保持が担保されていなかったのが、ロケーションとして日本も追加されたのが大きいかな。

ってことでACSを利用したメール送信を検証していきましょう。

Azure Communication Servicesを利用したメール送信

ACSリソースの作成

まずは、Azure Communication Servicesリソースを追加していきます。メール送信を行うためには「Communication Services」というリソースと、「Email Communication Services」の二つのリソースを追加する必要があります。

Communication Services Emailリソースの作成

まずはCommunication Services Emailリソースを追加してみます。

Email Communication Servicesを検索し、「作成」をクリックします。

サブスク、リソースグループを選択し、リソース名を入力します。リージョンはグローバルなので選択はできませんが、データを保持するロケーションを選択します。以前は日本国内は選択できませんでしたが、しっかり「Japan」が選択できるようになりました。やったね！

「確認と作成」をクリックします。

「作成」をクリックします。

リソースができあがりました。が、このままでは空っぽのリソースですので、メール送信用のドメインを準備する必要があります。[設定]にある「ドメインをプロビジョニングする」を選択します。

以下の画面で、「ドメインの追加」から「Azureドメイン」を選択します。お手軽にメールを実装するにはAzure側で用意してくれるAzureドメインを選択でよいのですが、後述しますが、ちょっといただけない理由があります。ひとまずAzureドメインで進めていきます。

あっという間にメール送信用のドメインの準備が完了しました。Emailリソースはひとまずここまで。

Communication Servicesリソースの作成

次にCommunication Servicesリソースをデプロイしていきます。リソースを検索し、以下の画面で「作成」をクリック。

こちらでも同様にサブスク、リソースグループを選択し、リソース名を入力します。注意点は「データの場所」ですが、Emailサービスで選択したロケーションと同一のものを選択しましょう。今回は「Japan」が選択できるようになっていますのでもちろん「Japan」で。「出逢いは億千万」ですので。「タグ」はお好みで。「レビューと作成」をクリックします。

確認画面で「作成」をクリックします。

Communication Servicesリソースができました。

次に作成したACSリソースにEmailリソースで追加したドメインを紐づけてあげる必要があります。[メール]の「ドメイン」をクリックします。

以下の画面になるので、「ドメインを接続する」をクリックします。

「メールドメインの接続」が表示されるので、前手順で追加したAzureドメインを選択し、「接続」をクリックします。

ドメインが「接続済み」になればACSとEmailリソースを利用してメール送信を行うことができる状態です。

ACSでのメール送信をC#で実装する

今回はVisual StudioでC#コンソールアプリとしてメール送信を試してみたいと思います。基本はMSのLearnサンプル通りです。

Azure Communication Services を使用してメールを送信する - An Azure Communication Services article

この記事では、Azure Communication Services を使用して電子メールメッセージを送信する方法について説明します。

まずは準備として、送信元メールアドレスの確認です。AzureポータルからEmailサービスリソースに遷移し、プロビジョニングされたドメイン名をクリックします。そして、「MailFrom address」を選択すると以下の画面が表示されるので、対象メールアドレスの横三点リーダーから「Copy MailFrom address」で送信元メールアドレスを取得しておきます。追加したり修正したければ「＠の前」と「Display Name」に関しては編集できます。

次もAzureポータルからACSリソースにアクセスし、[設定]－「キー」を選択します。接続文字列をコピーしておきます。この後利用します。

したらば、VisualStudioに移ります。まずはNugetパッケージマネージャーで「Azure.Communication.Email」パッケージをインストールします。

実装するソースコードサンプルは以下の感じです。{Azure Communication Servicesの接続文字列}にはACSリソースから取得した接続文字列、{送信元メールアドレス}にはEmailリソースで取得したMailFrom addressを入力します。

ちなみに毎度当たり前のことですが、接続文字列はコード内にべた書きせず、セキュアな場所に保持して参照するようにしておくのが定石です。今回はメール送信ができるか確認するだけですのでべた書きしてますが、よい子のみんなはマネしちゃだめだぞ～ｗｗｗ

using Azure;
using Azure.Communication.Email;

string connectionString = {Azure Communication Servicesの接続文字列};
EmailClient emailClient = new EmailClient(connectionString);

// タイトル
var subject = "ACSメール送信テスト";
// 本文
var htmlContent = "Azure Communication Serviceからメール送信をしてみました。
届きましたかね？";
// 送信元メールアドレス
var sender = {送信元メールアドレス};
// 送信先メールアドレス
var recipient = "xxxxx@example.com";

try
{
    Console.WriteLine("メール送信中...");

    EmailSendOperation emailSendOperation = await emailClient.SendAsync(Azure.WaitUntil.Completed,
                                                                        sender,
                                                                        recipient,
                                                                        subject,
                                                                        htmlContent);

    EmailSendResult statusMonitor = emailSendOperation.Value;

    Console.WriteLine($"メール送信しました。ステータス = {emailSendOperation.Value.Status}");

    string operationId = emailSendOperation.Id;

    Console.WriteLine($"オペレーションID = {operationId}");
}
catch (RequestFailedException ex)
{
    Console.WriteLine($"メール送信失敗: {ex.ErrorCode}, メッセージ: {ex.Message}");
}

あとは実行するだけです。コードを実行すれば、指定のアドレスにメールが送信されているのが確認できると思います。あ～ら簡単ｗ

しかしながら以下の画像で表示しているように、お手軽Azureドメインを利用しているメールドメインですので、表示されているドメインの長さときたら・・・。これではユーザーに怪しまれてしまいそうですよね。

ってことでメールアドレスにカスタムドメインを当てていきたいと思います。

Azure Communication Services Emailにカスタムドメインを設定する

ってことで、Azure無料ドメインは、迷惑メール対策としてのSPF・DKIM認証設定などはしっかりされていますが、送信元メールアドレスがいただけないので、カスタムドメインを当てていこうと思います。

今回、所有するドメインがエックスサーバーのサーバーにあたっているという前提で進めていきます。カスタムドメインを当てる場合、レンタルサーバーや自社サーバー側のDNSレコードを編集する必要がありますが、海外有名どこのレジストラでの設定方法はいくつかMS Learnに載っていましたが・・・。

カスタム検証済みメールドメインを追加する - An Azure Communication Services article

この記事では、Azure Communication Services でカスタム検証済み電子メールドメインを追加する方法について説明します。

エックスサーバーに関してはもちろん載っていませんでしたので、ハマりポイントなんかも記述していきます。

ACS Emailにカスタムドメインの追加＆ドメイン所有権の検証

そいでは初めにAzureポータルに行き、Emailリソースを開きます。[設定]－「ドメインをプロビジョニングする」から、「ドメインの追加」－「カスタムドメイン」を今度は選択します。

以下の画面で自身の所有するドメインを入力し、「確認する」をクリックします。

「追加」をクリック。

ドメインの追加ができると画面が変化します。「ドメインの確認」をクリックします。

追加したカスタムドメインの所有権を有しているのかをチェックする必要があります。以下の画面の「TXT値」をコピーしましょう。そしたらこの画面はこの後使うのでそのまま放置で。

この後はエックスサーバー側で作業します。エックスサーバーのサーバーパネルにサインインし、対象ドメインの「DNSレコード設定」をクリックします。

以下の画面で、「DNSレコード追加」タブをクリックします。

DNSレコード編集画面になるので、種別に「TXT」、内容にAzureポータルでコピーした値を設定し、「確認画面へ進む」をクリックします。ホスト名はサブドメインなどあればよしなに。TTLの値はおそらくデフォルトで3600で一致してると思いますが違ったらAzure側に合わせましょう。

確認画面で「追加する」をクリックします。

これでDNSレコードの追加がうまくいきました。Azureポータルに戻りましょう。

先ほどの画面で、「次へ」をクリックします。

この画面で「完了」をクリックします。

ドメイン所有権の検証が始まります。「閉じる」をクリックします。

Domain statusが「検証済み」になりカスタムドメインの所有権の検証に成功しました。検証後は、先ほどエックスサーバー側に追加したTXTレコードは削除できます。次に、SPF statusの「構成」をクリックして次のステップを行っていきましょう。

SPF・DKIＭ認証レコードをエックスサーバーに設定

次にAzureポータル側で表示されたSPF、DKIMの値をエックスサーバー側に設定していきます。ちなみにエックスサーバーではSPFレコードがすでに登録済みのため、以下のレコードをそのまま追加してはうまくいきません。

以下の赤枠で囲んだ部分、「include:spf.protection.outlook.com」をコピーしておきます。

DKIMレコードはそのままコピーして使います。

エックスサーバーのサーバーパネルからDNSレコード設定を開き、DNSレコード一覧をクリックします。すでに「v=spf1～」で始まるTXTレコードが登録済みだと思いますので、「変更」をクリックすると以下の画面に遷移します。ここの内容にAzureポータルでコピーしたSPFレコードの値を既存の内容を保持したまま追加します。

実はここにハマリポイントがありました。エックスサーバー側のDNS設定の最後は「~all」で終わっているんで、間にAzure側が指定している値を入れただけなんですが、実はこれだとこの後のAzure側での検証が失敗します。~~なぜこんなこと起こるのかよくわかってないのですが~~「~all」を「-all」（ハイフン + all）に変えたらうまく検証が通りました。じゃぁ変えられてしまったエックスサーバー側で大丈夫かは未確認ですが、今のところ不都合は見つかってません。

ちなみに複数のSPFレコードを設定するときに使える構文「+」も検証NGになります。他のSPFレコードが使う分にはいいですが、「+include:spf.protection.outlook.com」としてしまうと検証NGになるのでご注意を。サポートに問い合わせました。ACSの検証プロセス側の制限によりエラーとなっているそうだ…（2024年3月時点）

ちなみに上記に関してよくわからなかったのでCopilotに聞いてみました。

SPFレコードの「~all」と「-all」は、どちらもSPF認証が失敗した場合の処理方法を指定するものですが、その扱い方に違いがあります。

「-all」はハードフェイル（Hard Fail）を意味し、SPFレコードにリストされていないIPアドレスからのメールは完全に拒否されるべきだと示します。つまり、そのメールは配信されず、スパムとして扱われるか、削除される可能性があります。
「~all」はソフトフェイル（Soft Fail）を意味し、SPFレコードにリストされていないIPアドレスからのメールは疑わしいものとしてマークされるべきだと示しますが、それでも配信はされることが多いです。
最近では、多くのメールサービスプロバイダーは「-all」と「~all」を同じように扱い、どちらもSPF認証の「NOT PASS」を意味するとしています。しかし、実際のメール処理においては、プロバイダーによって異なる扱いをすることがあります。そのため、ドメインの評判を守りつつ、メールの配信性を確保するためには、DMARCポリシーと合わせて適切に設定することが重要です

要するに「-all」の方がより厳しめということですかね。無知ですみません。

TXTレコードを編集出来たら「変更する」をクリックします。

SPFレコードが登録できました。

今度はDKIMレコードを追加していきます。ホスト名をAzure指定の「CNAMEレコード名」、種別は「CNAME」を選択し、内容にコピーした「DKIM値」を入力します。入力後、「確認画面へ進む」をクリック。

確認画面で「追加する」でDKIMレコードの追加が完了です。

同様の手順でDKIM2レコードの追加も行いましょう。

サブドメインの場合は若干ホスト名の入力を変更する必要ありますが、その辺もLearnに記載されています。

カスタム検証済みメールドメインを追加する - An Azure Communication Services article

この記事では、Azure Communication Services でカスタム検証済み電子メールドメインを追加する方法について説明します。

今度はAzureポータル側に戻ります。以下の画面で「Next」をクリックします。

以下の画面で「Done」をクリックするとSPF、DKIMの検証が開始されます。

「Close」をクリックして、しばし待たれよ。

DKIMは速攻で検証OKになります。

前述の「~all」のまま進めると、以下の画面のようにエラーになってしまします。「-all」にエックスサーバー側を変更後、もう一度検証を実行しましょう。

以下のようにすべてオールグリーンになればカスタムドメインの追加は完了です。次に送信元メールアドレスを追加するので、ドメイン名をクリックしましょう。

カスタムドメインの送信元メールアドレス追加

カスタムドメインの送信元メールアドレスを追加します。「MailFrom addresses」を選択し、「Add」をクリックします。

以下の画面で、表示名と送信元アドレスを入力します。「Save」をクリックし、設定を保存しましょう。

ばっちり送信元メールアドレスが追加されました。

カスタムドメインのAzure Communication Servicesへの接続

最後の手順ですが、追加したカスタムドメインをACSに接続する必要があります。Azure Communication Servicesリソースにアクセスし、[メール]の「ドメイン」をクリックします。ACSに接続できるのは１つのメールサービスだけなので、初めに接続したAzureドメインを一度切断しましょう。

「ドメインを接続する」をクリックし、追加したカスタムドメインを入力します。その後、「接続」をクリックしましょう。

「接続済み」となれば無事ACSとカスタムドメインが関連付けられました。

カスタムドメインを設定後のメール送信

それでは、ソースコードの送信元メールアドレスを変更して、もう一度アプリを実行してみます。

以下のようにしっかりGmailにも迷惑メールとならずにメールが届いていることが確認できます。すごくいい！

さいごに

Azure Communication Servicesを利用することで、なんとも簡単にメール送信を行うことができました。カスタムドメインを使うのは若干手間がかかりますが、それでも高コスパなので使わない手はないですね。今回は触れていませんが、メトリックなどを活用してメールの到達確認もできるようです。

Azure Functionsでの実装ですが、SendGridでは出力バインドでメール送信できていたので、ACSは現時点で出力バインドがないので、そこの変換がちょっと手間かなという感じです。カスタムバインドって言う手もあるようですね。

まぁ、出力バインドでSendGrid出力バインドをQueue出力バインドにリプレースしつつ、1本QueueトリガーFunction噛ませてメール送信を集約してそこで行うように検討しようかなぁ・・・。

以上、Azure Communication Servicesを利用したメール送信でした。

最後までご覧いただきありがとうございました。

システムエンジニアランキング

にほんブログ村

The post Azure Communication Servicesを利用してメール送信してみる first appeared on 星と月と太陽と.

Azure Key Vaultを利用したシークレットの管理

sei — Sun, 15 Oct 2023 22:57:01 +0000

どーもです。本日は技術系ネタです。

最近ガンプラ作ってないので作ってから投稿したいと思いますが、いかんせんやりたいことありすぎて時間が・・・。最近はバイクばっかですね。

本日は、最近の様々なセキュリティを高める潮流に合わせちょこちょことパスワードとかをより安全な場所に保管していくように意識を変えていければなぁとAzure Key Vaultに触れてみたいと思います。

Azure Key Vaultとは？
本日のゴール
Azure Key Vaultからのシークレット取得手順
Azure FunctionsからKey Vaultのシークレット取得を実行

Azure Key Vaultとは？

一言でいうと、「シークレットや証明書を安全に保管しておくAzureが提供するクラウドサービス」です。Vault（ボールト）とは金庫とか保管庫のことで、要するに貴重品入れる金庫ということですね。

この金庫に重要なシークレットなんかを保管しておけば、情シスやセキュリティ担当者にしてみれば、暗号化された安全な環境で機密情報の一元管理や監視ができ、開発者にとっては、アプリに機密情報を含める必要がなくなったり証明書の管理や更新を自動化できたりと開発に注力できるようになります。

Key Vault | Microsoft Azure

Microsoft Azure Key Vault を使用すると、クラウドアプリおよびサービスが使用する暗号化キーおよびその他の秘密情報をセキュリティ保護できます。今すぐお試しください。

本日のゴール

Azure Functions内で利用するアカウントID、パスワードをAzure Key Vault内に保持し取得することで、Azure Functions内からの機密情報の排除シナリオを実装してみます。

本当は、接続文字列とかアプリシークレットとかだと思うのですが、まぁそこは読み替えていければKey Vault内に保管するものは何でもOKって感じです。

さらに、おまけとして、Azure Key Vaultの価格が「秘密情報の操作」として4.485円／10,000トランザクション(2023年10月現在)かかるので、これをバックエンドAPIとの連携で利用してWEBサービスの課金が跳ね上がらないか？の検証、課金タイミングもちょい気になったので・・・。

価格 - Key Vault |　Microsoft Azure

Azure Key Vault の価格を表示します。クラウドアプリおよびサービスで使用される暗号化キーおよびその他の秘密情報をセキュリティで保護します。

ってことで、

Azure Functionsコード内部からAzure Key Vault SDKでアクセスし、シークレットを取得する。
Azure Functionsの環境変数にKey Vault参照としてシークレットを取得する。

この2パターンで呼び出し回数の変化を見てみます。

まぁ、自明かもしれませんが念のため。あんまりはっきりした情報が見つからなかったのもあるので。

Azure Key Vaultからのシークレット取得手順

Azure Key Vaultリソースの作成

それでは早速ですが、Key Vaultリソースを作成していきます。

リソース追加から、「Key Vault」を選択します。

「作成」をクリックします。

以下の画面はよしなに。重要なのはKey Vault名と価格レベルくらいかな。Key Vault名はURLに組み込まれるので、グローバルで一意である必要あります。入力できたら「次へ」をクリックします。

アクセス構成ではデフォの「Azureロールベースのアクセス制御（推奨）」でいきましょう。ネットワーク、タグもデフォでいいので「確認および作成」をクリック。

確認画面で「作成」をクリックします。

デプロイが完了しました。早速リソースに移動しまそ。

KeyVaultコンテナーへのユーザーアクセス権の設定

KeyVaultのアクセス制御はRBACで行います。たとえ、リソースを作成できても、適切な権限がなければ「この操作は RBAC で許可されていません。」となってシークレットなどを設定することができません。

ですので、まずはユーザーにアクセス許可を設定してみます。

KeyVaultリソースの「アクセス制御（IAM）」をクリックします。

ここでは「ロール割り当ての追加」をクリックします。（RBACの制御はお好みの方法でどうぞ。）

ロール割り当ての追加では、「キーコンテナー管理者」を選択してみます。ロールはご自身の環境に合わせて設定ください。

Azure RBAC を使用してAzureキーコンテナーにアクセスするためのアクセス許可をアプリケーションに付与する

ロールベースのアクセス制御を使用して、キー、シークレット、証明書へのアクセスAzure提供する方法について説明します。

次の画面で、アクセスの割り当て先に「ユーザー、グループ、またはサービスプリンシパル」を選択し、「メンバーを選択する」をクリックします。右のブレードで対象のユーザーを選択し、「次へ」をクリックしましょう。

確認画面で「レビューと割り当て」をクリックすればユーザーへのアクセス権設定は完了です。

Azure FunctionsマネージドID発行とKeyVaultコンテナーへのアクセス権の設定

Key VaultにアクセスするにはAzure Functionsも認証される必要があります。これには前回投稿した便利機能「マネージドID」を利用します。これでAzure Functionsが認証されます。

マネージドIDを利用したAzure SQL Databaseへのアクセスを実装する

こんばんは。まだまだ暑い日が続いていますが、皆様いかがお過ごしでしょうか？そういえば、Azure Active Directory、今後は「Microsoft Entra ID」と名称が変更されましたね。Azure ADとかAADと言って長...

そして、認可はRBACで設定します。

それでは「Azure FunctionsへのマネージドID発行」→「マネージドIDへのアクセス権設定」の手順を実施していきましょう。

まずはAzure Functionsリソースにアクセスします。

次に設定の「ID」をクリックします。

したらば、システム割り当てマネージドIDの画面になるので、スイッチを「オン」に切り替え、「保存」をクリックします。

システム割り当てマネージドID有効化の確認が出ますので「はい」をクリックします。

簡単にマネージドIDが有効化されましたね。そしたら、次にAzure FunctionsにAzure Key Vaultリソースへのアクセス権を設定していきます。ひとまず1つ目のAzure FunctionsはマネージドID有効化した画面にある「Azureロールの割り当て」から行ってみましょう。

以下の画面になるので、「＋ロール割り当ての追加」をクリックします。

右のブレードでスコープに「Key Vault」、サブスクリプション、対象のKeyVaultリソースを指定し、役割に「キーコーンテナーシークレットユーザー」を指定します。このロールを設定すれば対象KeyVaultリソースに設定されているシークレットの値を読み取ることができると思います。最後に「保存」をクリックしましょう。特に一覧にも反映されず設定完了してました。プレビューだからかなｗｗｗ

Azure Functions、もう一つあるので、そっちはKey Vaultリソースの方からアクセス権設定していってみますね。お好きな手順でいいと思います。マネージドIDの有効化を忘れずに。

Azure Key Vaultリソースに移動し、「アクセス制御（IAM）」をクリックします。

以下の画面で、「ロースの割り当ての追加」をクリックします。

ロール一覧がでますので、「キーコンテナーシークレットユーザー」を選択し、「次へ」をクリックします。

アクセスの割り当て先を「マネージドID」にします。そして、「メンバーを選択する」をクリックすると、右ブレードにマネージドIDを有効化したAzure Functionsが表示されるので対象となるAzure Functionsリソースを選択してください。「次へ」をクリックします。

Azure Functionsが表示されない場合は、もう一度マネージドIDを有効化したか確認しましょう。

確認画面で「レビューと割り当て」をクリックすれば完了です。

Azure Key Vaultへのシークレットの保存

やっとこさAzure Key Vaultへのシークレットの保存になります。

Key Vaultリソースにアクセスし、[オブジェクト]－「シークレット」をクリックしましょう。

以下の画面を表示します。「＋生成／インポート」をクリックします。

「この操作は RBAC で許可されていません。」警告が表示される場合はもう一度ユーザーのKeyVaultリソースへのアクセス制御（IAM）を確認しましょう。

シークレットの作成画面を表示するので、「名前」にシークレット名を、「シークレット値」にその値、つまり、機密情報を入力します。あとはデフォルトでOK。「作成」をクリックします。

ここでは、名前に「accountid」、値に「hoge」という値を設定しました。例がややこしいですがアプリで利用するaccountidという変数へセットする値がhogeです。

なので、もう1つ追加した例です。

「password」というキー（シークレットの名前）で「password12345」という値を取得できるようにシークレットを追加しました。こちらも「作成」で保存します。

二つのシークレットが登録されたのが確認できます。したらば、ここで登録した設定をクリックします。

以下の画面を表示します。現在のバージョンをクリックします。

次の画面で、「シークレット識別子」の値をコピーしましょう。あとで利用します。

Azure FunctionsにKey Vaultシークレット取得の追加

最後の手順です。前の手順でKey Vaultに追加したシークレットをAzure Functionsから取得できるようにしましょう。といっても、今回はAzure Functionsリソースを2つ作成していますが、この手順を行うのは環境変数、つまり、アプリケーション設定にKey Vaultへの参照を保持する場合のみです。というか、Azure Functionsで利用するならこれ一択といっても言い過ぎではないかもしれません。

対象のAzure Functionsリソースにアクセスします。

[設定]の「構成」をクリックします。

アプリケーション設定の画面で「＋新しいアプリケーション設定」をクリックします。

アプリケーション設定の追加／編集ブレードが表示されるので、名前にKeyVaultに追加したシークレットの「名前」、値には前の手順の最後でコピーした値を「@Microsoft.KeyVault(SecretUri=シークレット識別子)」といった形式で入力します。ちなみに「@Microsoft.KeyVault(VaultName=KeyVaultリソース名;SecretName=シークレットの名前)」でもOKです。

Key Vault参照をアプリ設定として使用する - Azure App Service

Azure Key Vault参照を使用するようにAzure App ServiceとAzure Functionsを設定する方法について説明します。 Key Vaultシークレットをアプリケーションコードで使用できるようにします。

アプリケーション設定を追加したら「保存」をクリックします。追加した設定のソースは「App Service」となっていますが・・・

Key Vault内のシークレットへのアクセスがうまくいけば「キーコンテナーの参照」に変化します。やったね！以上でKey Vaultに保存したシークレットを取得する環境の準備は整いました。

Azure FunctionsからKey Vaultのシークレット取得を実行

さて、ここからはKey Vaultに設定したシークレットをAzure Functionsから利用していくんですが、冒頭でもお話しした通り、Azure Functionsは二つ用意します。

一つは、コード内でAzure Key Vaultライブラリ実装を利用し、Key Vaultにアクセスする方法。

もう一つは、前手順で行ったAzure Functionsアプリケーション設定からKeyVault参照を利用し取得する方法です。

コード（.NET6 分離ワーカープロセス）を以下に提示しておきます。

こちらはコード内にKey Vaultへのアクセスをゴリゴリ書く方法。

「Azure.Identity」ライブラリ、および、「Azure.Security.KeyVault.Secrets」ライブラリのインストールが必要です。お好きな方法でどうぞ。ちな、自分はNuGetパッケージマネージャーからです。

どーでもいいんですが、Value.Valueってブルっちゃいますよね・・・ｗ

using System.Net;
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;

namespace KeyVaultUsingIncodeFunctionApp
{
    public class Function1
    {
        private readonly ILogger _logger;

        public Function1(ILoggerFactory loggerFactory)
        {
            _logger = loggerFactory.CreateLogger();
        }

        [Function("Function1")]
        public async Task Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            var containerUri = "https://sei-keyvault-example.vault.azure.net";

            var client = new SecretClient(new Uri(containerUri), new DefaultAzureCredential());

            // シークレットの取得
            var accountId = await client.GetSecretAsync("accountid");
            var password = await client.GetSecretAsync("password");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"AccountId:{accountId.Value.Value},Password:{password.Value.Value}");

            return response;
        }
    }
}

こちらは、KeyVault参照を利用する方法。

なんてことはない、KeyVault使っていようが普通のアプリケーション設定にアクセスするのと同様に環境変数にアクセスしているだけです。アプリケーション設定側でよしなにしてくれているのでとっても楽♪KeyVault参照すごくいい！！

using System.Net;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;

namespace KeyVaultUsingEnvSettingsFunctionApp
{
    public class Function1
    {
        private readonly ILogger _logger;

        public Function1(ILoggerFactory loggerFactory)
        {
            _logger = loggerFactory.CreateLogger();
        }

        [Function("Function1")]
        public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"AccountId:{Environment.GetEnvironmentVariable("accountid")},Password:{Environment.GetEnvironmentVariable("password")}");

            return response;
        }
    }
}

ってことでそれぞれのAzure Functionsを10回ずつ呼び出してみます。シークレットは2つ。

KeyVaultコード内実装のパターン。ちゃんとシークレットを取得できているのがわかります。

こちらはKeyVault参照のパターン。こちらもちゃんとシークレットを取得できていますね。

ってことでそれぞれ10回ずつ呼び出したのでメトリックを見てみます。

結果は、コード内実装の場合は予想通り2シークレット×10回で計20リクエストがsecretで発生しているのが確認できました。まぁ予想通りですが、KeyVaultの取得をバックエンドAPIに書いちゃこうなるわなぁ・・・。

で、KeyVault参照のAzure Functionsの方なんですが、ごっそりリクエスト数がなかったです。これはAzure Functions、というかAppServiceの仕組みに詳しい方に言わせれば当然の結果なのかもしれませんが、KeyVaultの値はキャッシュされ、フェッチはAzure Functions起動時や定期的に行われているそうです。（自明すぎた？）

Key Vault参照をアプリ設定として使用する - Azure App Service

ってことで安心してKeyVaultをAzure Functionsに組み込む算段がつきました。それにしてもKey Vault参照うぃいねぇ～～～！

システムエンジニアランキング

にほんブログ村

The post Azure Key Vaultを利用したシークレットの管理 first appeared on 星と月と太陽と.

マネージドIDを利用したAzure SQL Databaseへのアクセスを実装する

sei — Mon, 18 Sep 2023 11:41:33 +0000

こんばんは。

まだまだ暑い日が続いていますが、皆様いかがお過ごしでしょうか？

そういえば、Azure Active Directory、今後は「Microsoft Entra ID」と名称が変更されましたね。Azure ADとかAADと言って長年慣れ親しんできましたが、全然よくわからない名称に変わりちょっと寂しい気分です。それにしてもMSさん、名称変更好きですよね・・・。

本日は、以前アップしたマルチリージョンでのDR構成構築手順で、データベースへのアクセスに手を抜いてSQL認証を利用しており、いろいろと突っ込まれそうな感じでしたので、別建てとしてマネージドIDを利用したSQL Databaseへのアクセスにして、セキュリティを高めていきたいと思います。

今回のゴール
Azure SQL DatabaseにマネージドIDを利用してアクセスする手順
さいごに

今回のゴール

上記図を簡単に説明すると、変更前は、SQL DatabaseへのアクセスにSQL認証を利用しています。つまり、接続文字列をAzure Functionsの環境変数やKey Vaultなどから利用することでAzure SQL Databaseとの認証を行っています。

「SQL認証のどこが問題なのか」というと、接続文字列内にSQL認証用のIDとパスワードを保持しているということです。接続文字列（IDとパスワード）が漏洩するだけで、Azure SQLへの不正アクセスリスクが一気に増大するわけです。

では、どうするか。それが今回のゴールです。マネージドIDというメカニズムを利用し、Azure SQLへのアクセスからIDとパスワードを廃棄し、許可されたAzureリソースのみがアクセスできるようにしていくわけです。

手順としては以下の通りです。

Azure FunctionsのマネージドIDを発行する。
Azure Active Directory（以下AAD）のグループにAzure SQL Databaseへのアクセス専用グループを追加し、発行したAzure FunctionsマネージドIDを追加する。
Azure SQL DatabaseにAzure SQLアクセスグループのユーザー追加＆権限設定
Azure Functionsの接続文字列変更
Azure SQL Databaseへの認証を「Azure Active Directory認証のみ」に設定

上記5ステップを行っていきます。

ちょっと手順が多そうですが、そんなに難しい作業でもないため慣れれば5～10分程度でできるのではと思います。

それではレッツゴ～～～ｗ

Azure SQL DatabaseにマネージドIDを利用してアクセスする手順

本投稿でこの手順を進めていく上での前提条件です。

Azure Functionsリソースが存在する。
Azure SQL Databaseリソースが存在する。
Azure FunctionsからAzure SQL Databaseへアクセスを行うことができる。

Azure FunctionsとAzure SQL Databaseの連携実装に関しては以下をご参考にしていただければ、その続きから当手順を実施可能です。

「Azure FunctionsでもEntityFrameworkのコードファーストで開発を行いたいんじゃ！」の巻

最近Entity Frameworkを知りました。いまさらです。生きててすみません。聞いたことはありましたが、いままでのやり方に固執・執着・思考停止（※ほんと良くないですよね・・・）し、あまり気にもとめてなかったのですが、実際いろいろやって...

Azure FunctionsのマネージドID発行

まずは今回の主役、マネージドIDを発行していきます。

対象のAzure Functionsにアクセスし、[設定]の「ID」をクリックします。

「システム割り当て済み」タブの[状態]を「オン」に変更し、「保存」をクリックします。

マネージドID有効化の確認画面がでるので「はい」をクリックします。

システム割り当てマネージドIDの発行ができました。簡単。

登録したマネージドIDはAzure Active Directoryの[エンタープライズアプリケーション]－[すべてのアプリケーション]から、「アプリケーションの種類」フィルターを「マネージドID」にすると確認することができます。この後利用するので、「名前」を覚えておいてください。基本的にはAzure Functionsのリソース名になっていると思います。

Azure Active Directoryグループの作成＆マネージドIDをグループに追加

続いてAADにAzure SQL Databaseへのアクセス用グループを追加していきます。AADにSQLアクセス用のグループを追加し、そのグループにAADユーザーやマネージドID、つまりアプリを登録してあげるだけで、Azure SQL Databaseへの認証をAADで一元管理することができるようになります。

実際はアプリ（マネージドID）がアクセスする場合と、ユーザーがアクセスする場合でグループを分けてあげると、Azure SQL側でロールを分離することができるので便利かと思います。こんなイメージです。

今回はSqlAccessGroupというグループを追加し、マネージドIDをそのグループに追加していきます。

まずはAADにアクセスし、「グループ」を選択します。

「新しいグループ」をクリックします。

以下の画面でグループの種類に「セキュリティ」を選択し、グループ名を入力します。その後、メンバーの部分の「メンバーが選択されていません」をクリックしてください。

メンバーの追加ブレードが表示されるので、検索欄で検索を行うか、「エンタープライズアプリケーション」タブを選択し、マネージドIDを生成したAzure Functionsにチェックを付け、「選択」をクリックします。

画面が戻るので「作成」をクリックしましょう。

グループを追加し、Azure SQLにアクセスするAzure FunctionsのマネージドIDをグループに追加することができました。

Azure SQL Databaseのユーザー＆ロール追加

次に、Azure SQL Databaseのユーザーとして、前手順で追加したAADグループを追加していきます。また、追加したユーザーにデータベースへの読取／変更権限を設定していきます。

この手順ではAzure SQL Databaseにアクセスを行って実施していきます。ここではSSMSを利用していきますが、クエリーが実行できればAzureポータルからでも可能です。

以下のクエリーを対象のデータベースに対して実行します。（データベース単位に実行する必要があります。）

-- AADグループをユーザーとして追加
CREATE USER [作成したAADグループ名] FROM EXTERNAL PROVIDER;

-- AADグループにデータベースの読取／変更権限を設定
ALTER ROLE db_datareader ADD MEMBER [作成したAADグループ名];
ALTER ROLE db_datawriter ADD MEMBER [作成したAADグループ名];

今回のグループ名「SqlAccessGroup」を例にすると以下のクエリーを実行する感じです。

-- AADグループをユーザーとして追加
CREATE USER [SqlAccessGroup] FROM EXTERNAL PROVIDER;

-- AADグループにデータベースの読取／変更権限を設定
ALTER ROLE db_datareader ADD MEMBER [SqlAccessGroup];
ALTER ROLE db_datawriter ADD MEMBER [SqlAccessGroup];

こんな感じでユーザーにAADグループ名が追加されていればOKです。

Azure Functionsの接続文字列変更

もうひと踏ん張りです。現在、Azure Functionsに保持しているAzure SQL Databaseへの接続文字列をID＆パスワード保持の接続文字列から、マネージドIDアクセスの接続文字列へと変更する必要があります。

Azure Functionsの環境変数、Key Vaultなど、接続文字列を保持しているところを以下の例をご参考に書き換えてみてください。

変更前（例：ADO.NET SQL認証）	Server=tcp:xxxxxxxx.database.windows.net,1433;Initial Catalog={your_database};Persist Security Info=False;User ID={your_userid};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
変更後	Server=tcp:xxxxxxxx.database.windows.net,1433;Initial Catalog={your_database};Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Authentication=Active Directory Managed Identity;

「Authentication=Active Directory Managed Identity;」がポイントかと。

変更したら、Azure Functionsを実行してみます。

マネージドIDを利用して、無事Azure SQL Databaseへのアクセスが確認できました。

Azure SQL Databaseへの認証を「Azure Active Directory認証のみ」に設定

最後の手順です。マネージドIDでのアクセスを設定して、AADにSQLアクセス用グループも設定して、そのグループにAADユーザーを当てがったのであれば、そもそもSQL認証用のID、パスワードを保持している必要性はありません。ですので、認証をAAD認証のみに変更していきましょう。

Azure SQL Databaseのサーバーリソースにアクセスし、[設定]の「Azure Active Directory」をクリックします。

「このサーバーのAzure Active Directory認証のみをサポートする」にチェックをつけ、「はい」をクリックします。

最後に、「保存」をクリックすれば、AAD認証のみに設定したAzure SQL Databaseの完成です。

さいごに

とっても簡単な手順でAzure FunctionsのマネージドIDを利用して、Azure SQL DatabaseへIDとパスワードを利用せずアクセスする環境が整いました。

Azure Functionsに限らず、マネージドIDを利用すればデータベースやストレージなど、対応する様々なリソースのセキュリティを高めてくれます。

Azure リソースのマネージド ID - Managed identities for Azure resources

Azure リソースのマネージド ID の概要。

マネージドID、利用しない手はないですね。

システムエンジニアランキング

にほんブログ村

The post マネージドIDを利用したAzure SQL Databaseへのアクセスを実装する first appeared on 星と月と太陽と.

AzureマルチリージョンでのDR構成を構築してみる。

sei — Sun, 26 Mar 2023 21:22:18 +0000

ちわ。seiです。タイトルの通りです。

DR（ディザスターリカバリー、災害復旧）構成、あるいは、冗長構成とかHA（高可用性）構成っていうのもほぼ同義かと思いますが、クラウドサービスを利用するとそんな構成が、あっという間に簡単に構築できます。オンプレだとサーバーラック内を冗長構成にするのすら、長い時間と労力と金がかかってたのに嘘のようです。しかも、サーバーラック内の冗長化だけじゃ地理的災害時のメリットが全くなしという・・・。

今回は、仮想ネットワークを利用しデータを全力で保護しつつ、データセンター障害やリージョン障害が発生しても「なんとか」（←ここ大事）稼働するWEBアプリを構築していきたいと思います。

今回のゴール
DR（ディザスターリカバリー）構成の構築手順
稼働確認

今回のゴール

基本的にはMSさんLearnからの「データベースへのプライベート接続を使用したマルチリージョン Web アプリ」のオマージュ？となります。アーキテクチャー自体は理解できるんですが、「じゃあその構築手順は？」と言われると、なかなかに手間取ったので備忘録として。（まぁスキル不足でしかないっていう話ではあるんですが）。若干構成を変えてお財布に優しくしたつもりですが、金額算出したわけではないのでよくわかりません。悪しからず。

データベースアーキテクチャ設計の始め方 - Azure Architecture Center

テクノロジの選択、ソリューションのアイデア、ワークロードの参照アーキテクチャなど、Azure でのデータベースアーキテクチャの設計について説明します。

構成図は以下のようになります。

Azure Front Door、WAFはオミットしてます。必要ならば入れていただければ。代わりにTraffic Managerがリクエストを振り分ける形になります。実際はTraffic Managerの前にAzure Static Web Appsとかのフロントエンドを配置しないとWEBアプリとしては機能しないと思いますが、今回はDR構成の検証という感じですので、こんなので行かせていただきます。

※トークンの管理やAPIキーなどの考慮も行っていません。

また、各リソースの詳細な作成方法は一部省略させていただきます。

追記：Azure Front Doorを利用したDR構成例も投稿してみましたのでご参照ください。

AzureマルチリージョンでのDR構成をAzure Front Doorにアップグレードしてみる。

どーも。seiです。久々の技術系ネタｗｗｗ以前の投稿では、Azure Traffic Managerを使ってマルチリージョンのDR（ディザスターリカバリー）構成を構築しました。コスパ重視でTraffic Managerをかませていましたが、...

DR（ディザスターリカバリー）構成の構築手順

リソースグループの作成

まずはリソースグループを作成していきます。災害対策として2つのリージョンに分散してリソースを作成していく必要があるでしょう。プライマリーリージョンとして「東日本」、セカンダリーリージョンとして「東南アジア」にそれぞれリソースグループを作っていきます。

本当は西日本をセカンダリーリージョンとして作成したかったのですが、2023年3月現在AppServiceがデプロイできない現象が発生しており、仕方なく海外のリージョンを利用しています。ハードウェアなどのリソース不足の影響でしょうか。

~~“This region has quota of 0 instances for your subscription. Try selecting different region or SKU.”っていうエラーで最後のステップで怒られます。~~

~~※西日本にAzuer SQLのデプロイができることは確認済みです。~~

~~海外のリージョンを利用するにあたっては、組織のデータ保存場所ポリシー等に従っていただければと思います。~~

→2023年6月現在、Azure西日本リージョンでもApp Serviceがデプロイできることを確認しています。一安心です。

はい、このように「primary-rg」として「Japan East」に、「secondary-rg」として「Southeast Asia」それぞれにリソースグループを作成しました。それではリソースをぶっこんでいきましょう。

Azure SQL Databaseの作成＆フェールオーバーグループ設定

まず、Azure SQL Databaseを用意していきましょう。プライマリーリージョンにはSQLサーバーとデータベースを作りますが、セカンダリーリージョンには論理SQLサーバーのみ作ります。その後、二つのリージョンをフェールオーバーグループに設定するとプライマリーに用意したデータベース内容が自動的にセカンダリーにレプリケートされます。

まずはプライマリーリージョンにSQL Databaseサーバーを新規で作成します。SQL認証を選択した場合は、プライマリーリージョンとセカンダリーリージョンのサーバー管理者ログインアカウント、パスワードを一致させた方がよいでしょう。一致していない場合、フェールオーバー後にAzure Functionsから恐らくアクセスできません。

引き続きデータベースを作成します。

サーバー、データベースのデプロイが完了しました。

そうしたら、データベースに簡単なテーブルを作成しておきましょう。IdフィールドとNameフィールドのみ保持するUserテーブルを作成します。サーバーのファイアウォールルールにクライアントのIPアドレスを追加してあげるのを忘れずに。クエリエディターでサクッと作りました。

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[User](
	[Id] [int] IDENTITY(1,1) NOT NULL,
	[Name] [nvarchar](max) NULL,
 CONSTRAINT [PK_User] PRIMARY KEY CLUSTERED 
(
	[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

これでプライマリーリージョンのデータベースは完了です。次にセカンダリーリージョンに論理SQLサーバーを用意します。マーケットプレイスで「SQL server(logical server)」を選択します。

もう一度言います。SQL認証を利用するならプライマリーリージョンで作成した管理者ログインアカウントとパスワードと同じものをセカンダリーリージョンのSQLサーバーで入力して必ず一致させましょう。

セカンダリーリージョンにサーバーのデプロイが完了しました。

次にフェールオーバーグループを設定して、データベースのGeoレプリケーションを可能にします。

プライマリーリージョンのAzure SQL Databaseサーバーを選択し、「フェールオーバーグループ」を選択します。

「グループの追加」をクリック。

「フェールオーバーグループ名」を入力し、サーバーにはセカンダリーリージョンのAzure SQL サーバーを選択します。その後、グループ内のデータベースで「データベースの構成」をクリックします。

レプリケーション対象のデータベースにチェックをつけ「選択」をクリックしましょう。

前の画面に戻り、「作成」をクリックするとフェールオーバーグループがデプロイされます。

ちゃんとセカンダリーと同期しているのが確認できます。

しばらくするとサーバーしか配置しなかったセカンダリーリージョンに、自動的にデータベースが同期されると思います。

SQL認証ではなく、マネージドIDを利用したAAD認証の場合は、以下の投稿をご参考に。SQL認証である必要はありませんので。

マネージドIDを利用したAzure SQL Databaseへのアクセスを実装する

Azure Functionsの作成&コードのデプロイ

次にAzure Functionsを用意していきます。

プライマリー、セカンダリーそれぞれに作成していきますが、注意点です。この後、プライベートエンドポイントと仮想ネットワーク統合を行っていくのですが、その場合、AppServiceプランならBasic以上の価格プランが必要です。Premiumなら言うことなし。さらに、Traffic Managerとの連携も必要な場合、Standard以上である必要があります。ですので今回は「Standard S1」プラン一択でリソースを作っていきます。

その他の構成は今のところなんでもOKです。

リソースのデプロイが完了したらソースコードを用意していきましょう。

コードは以前作成したEFCoreのコードファーストで作成したものを使ってみます。データベースにアクセスするコードがあればなんでもいいです。

以前の内容はこちらから。

「Azure FunctionsでもEntityFrameworkのコードファーストで開発を行いたいんじゃ！」の巻

今回使うコードは以下のような感じです。HTTPリクエストからnameパラメーターを受け取り、データベースのUserテーブルにIDを採番して新規登録するコードです。

using System;
using System.IO;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using CodeFirstExampleFunctionApp.Models;

namespace CodeFirstExampleFunctionApp
{

    public class Function1
    {
        private readonly MyContext dbContext;
        
        public Function1(MyContext context)
        {
            dbContext = context;
        }

        [FunctionName("Function1")]
        public async Task Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            await dbContext.AddAsync(new User() { Name = name });
            await dbContext.SaveChangesAsync();

            // 自動採番された最後のIDを取得する
            int id = dbContext.User.Max(x => x.Id);

            return new OkObjectResult($"ユーザーを登録しました。ID={id}、ユーザー名={name}");
        }
    }
}

コードができたら、プライマリー、セカンダリーの両リージョンのAzure Functionsにデプロイします。今回はパイプラインは組まず、VisualStudioから手動でデプロイします。二つのリージョンのAzure Functionsリソースにデプロイするのを忘れずに。

最後に、前の手順で作成したフェールオーバーグループの「読み取り／書き込みのリスナーエンドポイント」をデータベースアクセスの接続文字列として設定しておきましょう。

通常のデータベース接続文字列は

Server=tcp:drdemo-server-primary.database.windows.net,1433;Initial Catalog=drdemo-database;Persist Security Info=False;User ID=drdemo-admin;Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

ですが、フェールオーバーグループを設定し、フェールオーバー後もアプリケーションに保持した接続文字列を変更せずにデータベースにアクセスするには以下のように接続文字列を設定します。

Server=tcp:drdemo-failovergroup.database.windows.net,1433;Initial Catalog=drdemo-database;Persist Security Info=False;User ID=drdemo-admin;Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

違いは、Server指定の場所ですね。ここにフェールオーバーグループの「読み込み／書き込みのリスナーエンドポイント」を設定します。ちなみにこのフェールオーバーグループのドメイン名（＝読み込み／書き込みのリスナーエンドポイント）、「どこにあるの？」って話ですが、Azure SQL Databaseサーバーのフェールオーバーグループ設定内の以下のページの下部にあります。どこにあったか忘れてなかなか躓きます。

これをAzure Functionsのアプリケーション設定に値として設定してあげましょう。プライマリーAzure FunctionsもセカンダリーAzure Functionsも同じ値で設定してください。そうすることでAzure SQLでフェールオーバーが発生してもAzure Functions側では接続文字列の変更を行うことなく、アクティブなデータベースにアクセスできます。

仮想ネットワーク、プライベートリンク、グローバルVNetピアリングの設定

この時点でAzure SQL DatabaseのファイアウォールルールにAuzre FunctionsのIPアドレスを設定して、リクエストを投げればデータベースに書き込まれると思います。余裕がある方は試してみては。

ひとまず、ここでは仮想ネットワーク（VNet）を構築し、データベースへのパブリックアクセスを無効化します。

プライマリーリージョンにVNetを構築します。（セカンダリーもIPが変わるくらいで手順は一緒です。）

次にAzure SQL Databaseのサーバーにアクセスしてプライベートエンドポイントを作成していきます。作成したプライベートエンドポイントを先ほど作成したPrivateLinkSubnetに紐づけることでそのサブネットからのみデータベースにアクセス可能になります。

ネットワークを選択し、「プライベートアクセス」－「＋プライベートエンドポイントを作成します」を選択します。

名前を指定します。

自動的に対象サブリソースに「sqlServer」が設定されていると思います。

どのサブネットに配置するかを指定しましょう。今回は構成図の通りVNet作成時に追加したPrivateLinkSubnetに配置します。以外はデフォルトでOK。

自動的にプライベートDNSを構成してくれます。そのまま次へ。タグもそのまま次で「作成」を行いましょう。

プライベートエンドポイントがデプロイされました。

次にAzure FunctionsのVNET統合を行っていきます。

Azure Functionsにアクセスし、ネットワークから送信トラフィックの「VNET統合」をクリックします。

「VNetの追加」をクリックし、仮想ネットワーク、サブネットを指定してOKをクリックしましょう。

これでAzure FunctionsからVNET内へアクセスすることができます。

プライベートリンクの設定の最後にAzure SQL Databaseのファイアウォールルールを変更しましょう。パブリックアクセスを「無効にする」を選択することでデータベースへのアクセスをVNET統合したAzure Functionsのみに制限することができます。

VNET、プライベートリンク、VNET統合の設定がプライマリーもセカンダリーも終わり、パブリックアクセスを無効化した環境ができたら、次に仮想ネットワークピアリングを設定していきます。VNETピアリング、ここでは、リージョンをまたいだVNET同士の通信を可能にしますので、グローバルVNETピアリングを設定していきます。これによりプライマリーリージョンとセカンダリーリージョンでフェールオーバーが発生してもアクティブなデータベースへのアクセスを可能にします。

プライマリーリージョンに設定した仮想ネットワークにアクセスし、「ピアリング」を選択します。「追加」をクリックしてください。

以下のようにピアリングを設定します。要はお互いのVNETを指定するだけです。

これでリージョン間のVNET同士が通信できるようになったので、フェールオーバーが発生しても相互にアクセスが可能な状態になります。

この段階でほぼほぼDR環境は出来上がっているのですが、Azure SQLをフェールオーバーさせてバックエンドAzure Functionsからリクエストを投げると「Failed to update database “データベース名” because the database is read-only.」というメッセージ出して落ちます。これに対処するためにもう一工夫必要です。

プライベートDNSゾーンにプライマリー、セカンダリーの各データベースのプライベートリンクIPアドレス設定を追加します。

SQLをフェールオーバーさせます。

Azure Functionsにアクセスするとフェールオーバーしても、無事データベースにアクセスできたのが確認できました。

Azure Traffic Managerでのエンドポイント切り替え

疲れましたね。ここまで書いてて自分でも分割すればよかったって後悔してます。が、これで最後の手順です。

Traffic Managerを設定して、バックエンドAzure Functionsのリクエスト先を切り替えられるようにしましょう。これにより、プライマリーリージョン自体の災害時にセカンダリーリージョンのAzure Functionsやその先のデータベース、ストレージを利用したままサービスを継続できる？のではないでしょうか。

Traffic Managerプロファイルを追加します。

名前を設定し、ルーティング方法に「優先度」を設定して「作成」をクリックしましょう。

Traffic Managerリソースに移動し、エンドポイントを選択し、「追加」をクリックします。

エンドポイントの追加画面でまずはプライマリーリージョンに振り分けるエンドポイント設定を行っていきます。特に種類は「Azureエンドポイント」、ターゲットリソースの種類は「App Service」、ターゲットリソースにプライマリーリージョンのAzure Functionsバックエンドリソース名を指定します。そして、優先度に「1」を設定しましょう。優先度は値が小さいほど優先して実行されるエンドポイントになります。優先度１のエンドポイントの正常性が担保できないとTraffic Managerにより判断された場合は、その次の優先度の値のエンドポイントにトラフィックが振り分けられます。

同様に、セカンダリーリージョンに振り分けるエンドポイントも設定しましょう。

プライマリー、セカンダリーともにエンドポイント追加ができました。ただ、モニターの状態が両リージョンとも「低下」になっています。これはすべてのバックエンドAzure Functionsの正常性が確認できないためトラフィックマネージャーは機能していない状態です。これを解決していきます。

Traffic ManagerはデフォルトでHTTPで正常性チェックを行います。ですのでその構成を変更してあげて、HTTPSでトラフィックマネージャーがAzure Functionsと疎通できるようにします。

トラフィックマネージャーの構成設定に移動し、エンドポイントモニターの設定でプロトコルを「HTTP」から「HTTPS」に、ポートを「80」から「443」に変更しましょう。変更したら「保存」をクリックします。正常性チェックのカスタムコードなどがある場合はパスに記述します。Azure Functionsとかでしたら、healthcheckという関数を追加したとしたらapi/healthcheckと入れる感じですかね。200を正常として扱い、それ以外のステータスコードを使うようなら「状態コードの範囲が必要です」に定義してあげます。今回は特に行いません。ルートへのGETリクエストで200が返ってくれば正常と扱います。

この状態でモニターの状態を確認すると、ばっちりオンラインになってました。OKです。

一度、これでアクセスしてみます。トラフィックマネージャー経由のアクセスはAzure Functionsのエンドポイントのホスト名をトラフィックマネージャープロファイル作成時に指定した「名前.trafficmanager.net」にするだけです。が、「この接続ではプライバシーが保護されません」が出てSSLでAzure Fucntionsと疎通できません。さすがにAzure Functions側で「HTTPSのみ」をオフにするっていうのも気が引ける・・・。

これに対処するためには、無料のAppServiceマネージド証明書を利用していきます。いいですよね「無料」っていう響き。とっても助かります。ありがとうAzure。ありがとうMSさん。

まずはAppServiceマネージド証明書を追加していきます。Azure Functionsの証明書に移動し、「証明書の追加」をクリックします。カスタムドメインにはTrafficManagerのホスト名、証明書のフレンドリ名を入力し検証、追加を行いましょう。

※ちなみにカスタムドメインからAppServiceマネージド証明書の新規作成もできるのでそちらで行えば一手少なくできますね。

簡単にマネージド証明書が追加できました。

次にAzure Functionsにカスタムドメインを設定していきます。設定のカスタムドメインを選択すると以下のような画面になります。「バインディングの追加」を選択します。

もし、TrafficManagerの設定を行って上記のように「バインディングなし」のドメインが表示されない場合はAzure Functionsの価格プランが「Standard」以上になっていない可能性があります。もう一度価格プランを見直し「Standard」以上のプランになっていることを確認してください。

TLS/SSLバインドの追加で証明書として先ほど作成したAppServiceマネージド証明書を選択し、追加を行いましょう。

無事トラフィックマネージャーのドメインがカスタムドメインとして追加され、セキュリティ保護されました。忘れずにセカンダリーの証明書、カスタムドメインの設定もお願いしますね。

で、セカンダリーの証明書作成時に以下のエラーが出ました。

ホスト名が App Service マネージド証明書の作成に適していません。ドメイン drdemo.trafficmanager.net で、アクティブな CNAME レコードが drdemo-secondary-backend.azurewebsites.net に設定されていることをご確認ください。

TrafficManager上からプライマリーエンドポイントの優先順位を一時的にセカンダリーより落としてあげてから、セカンダリーAzure Functionsのカスタムドメイン＆証明書の追加を行ったらうまくいきます。

もう一度、トラフィックマネージャー経由のエンドポイントでAzure Functionsを呼び出してみます。無事プライバシーエラーで怒られることもなくトラフィックマネージャー→Azure Functions→VNET→プライベートエンドポイント→Azure SQL Databaseの呼び出しまで完了したことが確認できました。うぇ～～～～いｗｗｗ

稼働確認

最後にDR構成がうまくいっているか稼働確認していきましょう。

※レスポンスが正しく返ってくるかのみを検証します。

シチュエーションは以下の4パターンかなと。

パターン	Azure Functions	Azure SQL Database
パターン1:通常運用	プライマリー	プライマリー
パターン2:SQL障害	プライマリー	セカンダリー
パターン3:バックエンド障害	セカンダリー	プライマリー
パターン4:プライマリーリージョン障害	セカンダリー	セカンダリー

パターン1：通常運用

バックエンドもデータベースもプライマリーリージョンの通常運用パターン。

これはいいでしょ。

パターン2：SQL障害発生

バックエンドは問題ないが、プライマリーのAzure SQLに障害が発生してセカンダリーにフェールオーバーしたパターン。

これもOK。問題なし。

パターン3：バックエンド障害

バックエンドに障害発生でセカンダリーのバックエンドにトラフィックが振り分けられ、データベースはプライマリーに書き込まれるパターン。

※Azure Functionsの認証対策してないので関数キーはセカンダリーのものを使用します・・・。

おぉ。バッチリ。TrafficManagerもちゃんと働いています。

パターン4：プライマリーリージョン障害

最後は東日本リージョンがごっそり災害等で使えなくなった場合。すべてセカンダリーで稼働を想定。

パーフェクト！！バッチリセカンダリーのリソースで稼働しました。

ひとまず、DR構成でのWEBアプリ出来上がりましたが、~~トークンの件とか関数キーの課題がありますのでその辺まで~~フルスケールで行うにはAPIゲートウェイとかFront Doorやっぱ必要なんですかね。

追記：Azure Front Doorを利用したDR構成例も投稿してみましたのでご参照ください。

AzureマルチリージョンでのDR構成をAzure Front Doorにアップグレードしてみる。

~~まぁ再認証かませればこの構成でもなんとか行けなくはないのかなぁと。~~

2024/08/17追記

Azure Functionsのアプリキーって自動生成されるものしか利用できないと勘違いしてましたが、新規で追加することできましたね。なので、「新しいホストキー」でプライマリー、セカンダリー共通のホストキーを用意しておいてあげればフェールオーバーしても共通のアプリキーを利用してシームレスにAzure Functionsを利用できそうな気がしますね。まぁ設計によるとおもいますが。にしても、以前からホストキーの追加ってできましたっけ・・・？

→さらに追記。アプリキーを新規で作成するまでもなく、既存のアプリキーを編集することができるので、プライマリーとセカンダリーで同一のアプリキーに統一することは簡単にできますので、お試しください。

プライベートエンドポイントかませてストレージなんかも入れてあとはよしなに。

東日本がいっちゃったときに本当にオレら平気なの？っていうのはあるんですがね。。。対策してるのとしてないのでは気持ちのあり方が全然違いますよねぇ。

ってことで大分長丁場になってしまいましたが、無事DR構成を構築することができました。めでたしめでたしｗ

システムエンジニアランキング

にほんブログ村

The post AzureマルチリージョンでのDR構成を構築してみる。 first appeared on 星と月と太陽と.

Azure FunctionsのBLOBトリガー利用時の罠2選

sei — Sun, 26 Feb 2023 06:51:09 +0000

AzureFunctionsでBLOBトリガーを利用してたんですが、今回はそんなBLOBトリガーでの罠とも言えるハマりどころの解決策を記述していきたいと思います。

あまりネット上に情報が無くて解決までに時間を要したので、同じ現象で悩んでいる方の少しでも手助けになれば幸いです。

もっといい解決策があるようなら教えてください。

問題１：プロキシ環境×ローカル環境でのBLOBトリガーがエラーを吐く
1. 解決策：プロキシ×ローカル環境でBLOBトリガーなAzure Functionsを動かす方法
問題2：Microsoft Defender for Cloudの課金が高額になっている
1. Microsoft Defender for Storageの高額課金の原因
2. 解決策：BLOBトリガーで処理したファイルを削除する

問題１：プロキシ環境×ローカル環境でのBLOBトリガーがエラーを吐く

プロキシ環境に限った話かと思います。おそらく。

BLOBトリガーなAzure Functionsがプロジェクトに含まれている状況で、ローカルストレージエミュレーター環境、つまり、local.settings.jsonのストレージアカウントへのアクセスに「UseDevelopmentStorage=true」を指定して、Azure Functionsをデバッグ実行したとたんに以下のエラーメッセージが出てAzure Functionsのホストが落ちます。

The listener for function ‘Function1’ was unable to start.

The listener for function ‘Function1’ was unable to start. Azure.Storage.Blobs: Service request failed.

Status: 403 (Forbidden)

Content:

（中略）

An unhandled exception has occured. Host is shutting down.

Microsoft.Azure.Storage.Common: Forbidden.

こいつのせいで長らくlocal.settings.jsonにはAzureクラウド環境の実ストレージアカウントを指定してローカル実行を行っていました。そうするとFunctionsホストはエラーにならずにBLOBトリガーは実行できました。が、local.settings.jsonに実環境のストレージアカウントへの接続文字列を保持しなくてはならず悪手であることは間違いありません。

解決策：プロキシ×ローカル環境でBLOBトリガーなAzure Functionsを動かす方法

解決策としては、ローカルPCのシステム環境変数に以下の値を設定することです。※要PC再起動

変数名	変数値
no_proxy	localhost,127.0.0.1

これでプロキシ環境下でもUseDevelopmentStorage=trueでAzuriteに接続し、ローカル環境でBLOBトリガーを機能させることができました。

また、PCのシステム環境変数に設定せずに、local.setting.jsonに「no_proxy: localhost,127.0.0.1」を指定しても403(Forbidden)が発生して機能しませんでした。

なぜなのかはよくわからんｗ

問題2：Microsoft Defender for Cloudの課金が高額になっている

クラウドセキュリティ態勢管理ツール（CSPM）として、とっても優れていると思われるMicrosoft Defender for Cloudですが、その中のストレージアカウントの保護を司る「Microsoft Defender for Storage」の請求がとっても高額になって困り果てた件。

Microsoft Defender for Cloud | Microsoft Security

Explore Microsoft Defender for Cloud, a security solution and CNAPP that protects cloud‑native application development a...

Storage のMicrosoft Defenderとは - Microsoft Defender for Cloud

データとワークロードを保護するための Microsoft Defender for Storage の利点、機能、およびセキュリティ機能について説明します。

数百MBのBLOBストレージへのファイル保管のみなのに想定では2,000円程度のはずが、なぜか7,000円オーバーの請求となっていた。

コスト分析 (プレビュー)でサービスごとの課金額を確認すると、「Advanced Threat Protection」サービスとして、Microsoft Defender for Storageの課金として発生しておる。やっちまったなぁ。。。

Microsoft Defender for Storageの高額課金の原因

なぜ、こんなに高額課金になったのかを調査した結果、「GetBlobProperties」というAPIが数秒単位に呼び出されていた。

したがってMicrosoft Defender for Storageの方でもこの操作を監視対象のトランザクションとして課金が発生したのかと想定される。

ちなみにこのGetBlobPropertiesがなんのBLOBに対して呼び出されていたかというと、Azure FunctionsのBLOBトリガーで処理したファイルに対して呼び出されていた。

解決策：BLOBトリガーで処理したファイルを削除する

BLOBトリガーなAzure Functionsの処理が完了して不要になった百数十のファイルをコンテナー内にそのまま放置しており、そのすべてのファイルがGetBlobPropertiesのスキャン対象となっているっぽいので、すべて削除を行って様子見を行いました。

結果、Advanced Threat Protectionの課金額は一気に下がりました。めでたしめでたし♪

ちなみに、他の解決策としては、

BLOBトリガーなAzure Functionsで処理した後、対象BLOBファイルを別コンテナーに移す。
BLOBトリガーなAzure Functionsを、EventGridトリガーやQueueトリガーに置き換える。

という解決策でもOKかと。

以上、BLOBトリガーなAzure Functionsのハマりどころ二点でした。

システムエンジニアランキング

にほんブログ村

The post Azure FunctionsのBLOBトリガー利用時の罠2選 first appeared on 星と月と太陽と.

「Azure FunctionsでもEntityFrameworkのコードファーストで開発を行いたいんじゃ！」の巻

sei — Sat, 07 Jan 2023 09:51:17 +0000

最近Entity Frameworkを知りました。いまさらです。生きててすみません。

聞いたことはありましたが、いままでのやり方に固執・執着・思考停止（※ほんと良くないですよね・・・）し、あまり気にもとめてなかったのですが、実際いろいろやってみたら「あーこれは楽だ。きっと実務がはかどる。」とちょっと感動を覚えましたので投稿したいと思います。

それにしてもEntityFramework、.NET Framework 3.5 SP1の頃から実装されていたなんてちょっとビックリしました。初期の頃は今の使い勝手とはだいぶ違うかもしれませんが、もったいないことしたなぁと・・・。まぁ過去を悔やんでても仕方ないので前向いていきましょう。

はじめに
1. 本日のゴール
2. 環境とか
実装

はじめに

本日のゴール

Azure FunctionsでEFCoreのコードファースト開発を行う最初の一歩を実装します。

EntityFrameworkのより深く広い機能やコードファーストでリレーショナルなモデルを構築するような部分には触れてません。

環境とか

開発環境：Microsoft Visual Studio 2022 Community

データベース：Microsoft SQLServer 2019 Express

Azure Functionsランタイム：.NET 6(LTS)

実装

新規Azure Functionsプロジェクトの作成

①まずはVisualStudioを起動し、Azure Functionsを新規プロジェクトとして作成していきます。「新しいプロジェクトの作成」を選択します。

②テンプレートとして「Azure Functions」を選択します。

③プロジェクト名や保存場所を指定したら「作成」ボタンを押下します。

④ランタイムとして「.NET 6.0(LTS)」を選択し、トリガーは「Http trigger」を選択します。「作成」ボタンを押下しましょう。Azure Functionsのテンプレコードが作成されると思います。

NuGetパッケージマネージャーからパッケージをインストール

EntityFrameworkCore（＋DI（依存性注入））を利用する上で必要となるパッケージをインストールします。

必要なパッケージは以下の通りです。

Microsoft.EntityFrameworkCore
Microsoft.EntityFrameworkCore.Design
Microsoft.EntityFrameworkCore.SqlServer
Microsoft.EntityFrameworkCore.Tools
Microsoft.Azure.Functions.Extensions

①「ツール」メニューから「NuGetパッケージマネージャー」－「ソリューションのNuGetパッケージの管理」を選択します。

②参照タブで「EntityFramework」と検索し、表示された「Microsoft.EntityFrameworkCore」パッケージをプロジェクトにインストールします。この時、Azure Functionsのランタイムバージョンが.NET6ならば、バージョンを「6.X.X」に指定するのを忘れないようにしましょう。「インストール」ボタンを押下します。

②同様に「Microsoft.EntityFrameworkCore.Design」、「Microsoft.EntityFrameworkCore.SqlServer」、「Microsoft.EntityFrameworkCore.Tools」をバージョンを考慮してインストールします。「Microsoft.Azure.Functions.Extensions」は最新版のインストールでOKです。

EntityFrameworkCoreのコードファースト用コードを追加

次に対象のテーブルとマップするエンティティクラスを用意していきます。今回は簡単な例として作るので、IdフィールドとNameフィールドを保持するUserテーブルが出来上がるようにコーディングしていきます。

①まずはエンティティをフォルダーに整理したいのでModelsフォルダーを追加します。プロジェクトを右クリックし、「追加」－「新しいフォルダー」を選択しましょう。

Modelsフォルダーが追加されました。

②Modelsフォルダー内にUserエンティティクラスを追加します。Modelsフォルダーを右クリックし、「追加」－「新しい項目」を選択します。

③「クラス」を選択し、名前に「User.cs」を指定して、「追加」ボタンを押下します。

④追加したUser.csを以下のように実装します。ちなみにIdというフィールド名を指定すると自動的にオートナンバーのプライマリーキーで構築されます。自動採番したくない場合は、DatabaseGenerated属性のDatabaseGeneratedOption.Noneを指定することで実現可能です。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace CodeFirstExampleFunctionApp.Models
{
    [Table("User")]
    public class User
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }
}

⑤同様にDbContextクラスもModelsフォルダー内に追加しましょう。こちらも「クラス」を選択し、名前は任意の名前を指定して、「追加」ボタンを押下します。今回は「MyContext.cs」とします。名前を「DbContext.cs」にはしないほうがいいと思います。多分だめです。

⑦追加したMyContextクラスもコードを記述します。基本的にはDbContextを継承したクラスを実装していく感じです。DbSet型はコレクションなので複数形にするのがいいようです。ただ、前項のUserオブジェクトで[Table]属性を省略した場合はおそらく実テーブルもUsersと複数形で構築されると思います。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.EntityFrameworkCore;

namespace CodeFirstExampleFunctionApp.Models
{
    public class MyContext : DbContext
    {
        public MyContext(DbContextOptions options) : base(options)
        {

        } 

        public DbSet Users { get; set; }
    }
}

コンテキストのファクトリークラスコードの追加

DbContextインスタンスを生成してくれるファクトリークラスコードを追加します。なぜ必要かなんですが、どうもこのファクトリークラスを経由してDbCotnextオブジェクトを生成しないと、後述のコマンド実行時に接続文字列を引き渡すことができなかったからです。

①場所はどこでもいいと思いますが、今回はModelsフォルダー内に「MyContextFactory.cs」の名前でクラスを追加します。

②追加したクラスに以下のコードを実装します。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Design;

namespace CodeFirstExampleFunctionApp.Models
{
    public class MyContextFactory : IDesignTimeDbContextFactory
    {
        public MyContext CreateDbContext(string[] args)
        {
            var optionsBuilder = new DbContextOptionsBuilder();
            string connectionString = Environment.GetEnvironmentVariable("SqldbConnection");
            optionsBuilder.UseSqlServer(connectionString);

            return new MyContext(optionsBuilder.Options);
        }
    }
}

DIパターンの実装

EntityFrameworkCoreでDbContextを扱うときはDI（依存オブジェクト注入）パターンを使うのがベストです。DIを実装していきます。

①プロジェクトを右クリックし、「追加」－「新しい項目」を選択します。

②「クラス」を選択し、名前を「Startup.cs」とし、「追加」ボタンを押下します。

③追加したStartup.csにコードを記述します。以下の通りにコードを追加してください。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;
using CodeFirstExampleFunctionApp.Models;

[assembly: FunctionsStartup(typeof(CodeFirstExampleFunctionApp.Startup))]
namespace CodeFirstExampleFunctionApp
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            string connectionString = Environment.GetEnvironmentVariable("SqldbConnection");

            builder.Services.AddDbContext(options => options.UseSqlServer(connectionString));
        }
    }
}

local.settings.jsonにSQLServer接続文字列の追加

local.settings.json、つまり、環境変数にSQLServerの接続文字列を追加しておきます。前項で追加したStartup.cs内で環境変数から接続文字列の読み取りが行われ、DbContextに渡される流れです。

①local.settings.jsonに以下のコードを追加します。サーバー名やデータベース名は自信の環境に合わせ読み替えてください。

"SqldbConnection": "Server=localhost\\SQLEXPRESS;Database=ExampleDB;Trusted_Connection=True;"

接続文字列追加後のlocal.settings.jsonは以下のような感じになるかと思います。

{
    "IsEncrypted": false,
    "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "SqldbConnection": "Server=localhost\\SQLEXPRESS;Database=ExampleDB;Trusted_Connection=True;"
  }
}

マイグレーションの実行

マイグレーション、日本語に訳すと、移行と言ったりしますが、マイグレーションを行うことでその時点でのデータベースへの変更内容をマイグレーションファイルに記録しておき、随時データベースに反映させることができます。

まずはマイグレーションファイルの追加を行っていきます。

①「ツール」メニューの「NuGetパッケージマネージャー」から今度は「パッケージマネージャーコンソール」を起動します。

②パッケージマネージャーコンソールウインドウが表示されるので、まずは環境変数に接続文字列をセットします。「$env:SqldbConnection=”(SQLServer接続文字列)”」と入力し、Enterキーを押下します。

ちなみに環境変数のセットを忘れた場合は、以下のようなエラーメッセージが表示されます。

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
—> System.ArgumentNullException: Value cannot be null. (Parameter ‘connectionString’)
at Microsoft.EntityFrameworkCore.Utilities.Check.NotEmpty(String value, String parameterName)
at Microsoft.EntityFrameworkCore.SqlServerDbContextOptionsExtensions.UseSqlServer(DbContextOptionsBuilder optionsBuilder, String connectionString, Action1

（中略）
Exception has been thrown by the target of an invocation.

③次に、「add-migration (任意のバージョン管理名)」と入力し、Enterキーを押下しましょう。今回は初回の移行なので、「add-migration InitialCreate」としています。

「add-migration : 用語 ‘add-migration’ は、コマンドレット、関数、スクリプトファイル、または操作可能なプログラムの名前として認識されません。名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してください。」エラーが発生したときはおそらく「Microsoft.EntityFrameworkCore.Tools」パッケージのインストールが行われていない可能性があるのでもう一度確認してみてください。

ちなみに、コンテキストクラスの生成にファクトリークラスを追加して行いましたが、local.settings.jsonに設定した接続文字列はあくまで、Azure Functions実行時にロードされるが、マイグレーションコマンド実行時には別の方法で渡す必要があるのかなぁという感じです。ファクトリークラスを経由しないでadd-migrationを実行すると以下のエラーメッセージが表示されます。

Unable to create an object of type ‘MyContext’. For the different patterns supported at design time, see https://go.microsoft.com/fwlink/?linkid=851728

リンク先を見ると、「デザイン時ファクトリーを利用して」とあるのでひとまず他のやり方はおいておいてファクトリークラス経由でコンテキストクラスオブジェクトを生成するのが無難そうです。

Design-time DbContext Creation - EF Core

Strategies for creating a design-time DbContext with Entity Framework Core

④うまくマイグレーションが成功すると、以下の画面のようになり、Migrationsフォルダーとファイルが追加されると思います。

⑤マイグレーションファイルができたら、その内容をもとにデータベースに変更を反映させます。パッケージマネージャーコンソールから「update-database」と入力し、Enterキーを押下しましょう。

以下の画面のように表示され、最後にDoneとなっていたらデータベースへの反映は完了です。

⑥SSMSからデータベース内容を確認すると、データベースとUserテーブルが作成され、IDフィールドとNameフィールドが存在するのが確認できると思います。

Azure FunctionsからEFCoreを利用してDBアクセス

EFCoreのコードファースト、初回構築はうまくいきました。ひとまずコードファーストとしてはここまでですが、最後にAzure FunctionsからUserテーブルに書き込みができるかを確認してみます。

①まずはテンプレで作成されたAzureFunctionsコードをDIでDbContextを受け取れるように修正します。また、URLパラメーターで受け取ったNameパラメーターでUserテーブルに追加するようにし、登録内容（自動採番されたIDとユーザー名）をブラウザーに返すように実装します。以下、そのコードです。

using System;
using System.IO;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using CodeFirstExampleFunctionApp.Models;

namespace CodeFirstExampleFunctionApp
{
    public class Function1
    {
        private readonly MyContext dbContext;
        
        public Function1(MyContext context)
        {
            dbContext = context;
        }

        [FunctionName("Function1")]
        public async Task Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            await dbContext.AddAsync(new User() { Name = name });
            await dbContext.SaveChangesAsync();

            // 自動採番された最後のIDを取得する
            int id = dbContext.Users.Max(x => x.Id);

            return new OkObjectResult($"ユーザーを登録しました。ID={id}、ユーザー名={name}");
        }
    }
}

②Azure Functionsをデバッグ実行します。表示されたURLをコピーしましょう。

③コピーしたURLをブラウザーのアドレスバーに貼り付け、後ろに「?name=(任意の名前)」を付加し、Enterキーを押下します。

④正常にデータベースへ更新されれば以下のようにレスポンスメッセージが返ってくると思います。

SSMSでUserテーブルの中を確認すると、ちゃんとIDが自動採番されレコードが登録されたのではないでしょうか。

以上、Azure FunctionsでもEntityFrameworkCoreのコードファーストでがっつり開発できそうなことが確認できました。

システムエンジニアランキング

にほんブログ村

The post 「Azure FunctionsでもEntityFrameworkのコードファーストで開発を行いたいんじゃ！」の巻 first appeared on 星と月と太陽と.

Braveブラウザー、はじめました。

sei — Wed, 29 Jun 2022 11:58:11 +0000

ある時の会社での一コマ。

パイセン

ブレイブって言うブラウザ知ってる？

広告表示もされないで快適にWEBサイトを閲覧できるんだで！

sei

しらん。

っていうか、ブラウザはChromeしか使わん。

なんてったってGoogle信者だから。

（心の声：広告表示ないとか、広告表示提供してる

身からしたら脅威でしかないな・・・）

パイセン

おまけにバットっていう仮想通貨がそのブラウザ使ってれば

どんどん貯まってくんよ？どうよ？使ってみんよ？

sei

は、はぁ・・・。

（心の声：いや、聞いたことねぇブラウザの上、

仮想通貨貯まるとか怪しさ満点だんべ。ぜってー使わんわｗ）

What’s Brave？
Brave Rewardsクリエイター登録を行ってみた
さいごに

What’s Brave？

そんなこんなでまったくもって導入する気はなかったのだが、パイセンのあまりの勧め具合と、最近ちょっと仮想通貨が気になり、口座開設しようか悩んでいたのもあり、軽い気持ちでBraveに関して調べてみました。

進化したユーザーファーストのブラウザ | Brave

Braveブラウザは、PC、Mac、モバイル端末で使用できる高速でプライベートかつ安全なWebブラウザです。今すぐダウンロードして、トラッキングソフトウェアのブロックによるデータとバッテリーを節約した、より高速な広告のないブラウジング体験を...

Braveブラウザーの特徴は、

Chromiumをベースとした無料のオープンソースWEBブラウザー
あらゆる広告をデフォルトでブロック
広告を遮断するため、ページの読み込みを高速化でき、通信データも節約できる。
Braveが提供する信頼された広告を表示することで仮想通貨「Basic Attention Token」、通称BATを取得することができる。
bitFlyerと提携しており、取得したBATはbitFlyerの口座で受け取れる。
Brave Rewardsと呼ばれるコンテンツ制作者への応援機能、つまり匿名でのBATによる投げ銭機能を提供している

しかも調べていて、入れてみよう！となった理由に、Braveブラウザーの開発者がJavaScriptの開発者として知られるブレンダン・アイクというビッグネームであるというのが大きなポイントでした。

sei

怪しいとか言ってごめんちゃい。

私の認識不足です。。。

ってことでBraveブラウザー入れてみました。導入方法は割愛。なんも難しいこともなく、他のブラウザーからのブックマークなどのインポート機能もあるため、あっという間に完了です。

ちなみにこのサイトをChromeとBraveで表示して違いを見てみました。

Chromeでの表示。赤枠で囲ったところのようにばっちりアドセンス広告が表示されています。

そしてこちらがBraveで表示したサイトの内容。広告が表示されていないことが一目瞭然かと思います。

bitFlyerアカウントとの連携も可能ですので、bitFlyerに口座を開設している方は連携を行うことができると思います。自分はこのためにbitFlyer口座の新規開設を行いました。

BraveとbitFlyerアカウントの連携方法は以下の動画で確認できます。

Brave Rewardsクリエイター登録を行ってみた

今回の一番のミッションはBraveブラウザーを利用することではなく、実はBrave Rewardsクリエイター登録を行うことです。

Brave Rewardsのクリエイター登録を行うことで、サイト訪問者からBATでの投げ銭を受け取ることができます。

つまり、広告をサイトに表示することで収益化をはかっていた形から、サイト訪問者からのBATによる応援で収益化をはかるビジネスモデルへと変わっていくわけです。今までになくサイトコンテンツの質が重要になることと、定期的にBATを得るためには常連さん、要するにリピーターのサイト訪問者がどれだけいるかが重要になってくるような気がします。

まぁオレのサイトに投げ銭してくれる人がいるとは思えませんが、微かな望みに期待してBrave Rewardsクリエイター登録やっていきたいと思います。

Brave Rewardsクリエイター登録

まずはややこしいのですがBrave Rewardsクリエイター向けサイトに行き、「登録」をクリックします。

Earn more for content you publish to the web - Brave Creators

Viewers who use the Brave Browser may have contributed money to you while surfing the web through Brave Creators. Simply...

以下の画面になるので、メールアドレスを入力し、規約に同意したうえで「新規登録」をクリックします。

以下の画面が表示されたら、あとは届いたメールにしたがい認証を行うだけです。MFAの設定を行うか否かの選択があると思うのでなるべくMFAを設定しましょう。自分は認証アプリとしてMicrosoft Authenticatorを利用しているのでスマホでMicrosoft Authenticatorを起動しQRコードを読み取ってMFAを設定しました。

自サイトをBrave Rewardsに登録

登録が完了したらBrave Rewardsクリエイターサイトへサインインします。サインインは登録したメールアドレスを入力すると、サインイン用のURLリンクが毎回生成されそのリンクからのみサインインが可能となる仕組みです。MFA設定した方は認証アプリのコードを確認し画面に入力すればサインインできます。

クリエイター向けサイトのダッシュボードです。

まだ自分のサイトが登録されていないのでサイトを登録していきましょう。「＋チャンネルを追加」をクリックします。

何を追加するのかを選択する画面になるので、今回はブログサイトを追加するので「ウェブサイト」をクリックします。

ドメイン情報の入力画面が表示されます。自サイトのドメイン（http://やhttps://は不要）を入力し、「ページ内でBraveの広告を配信することを許可する」にチェックをつけて、「続ける」をクリックしましょう。

サイトの追加に成功すると、認証方法の選択画面が表示されます。つまり、登録しようとしているサイトが本当に自分のサイトかアクセス権の確認を行う手順です。今回は一番簡単と書いてあったので「認証ファイルを使って認証する」で行います。

認証ファイルを使った認証方法の詳細な手順が表示されます。まずは「ダウンロード」をクリックし、認証用ファイルをダウンロードしておきます。ダウンロードした認証用ファイルはこの後の手順でサーバーの「.well-known」フォルダーに配置することになります。

サーバーに認証用ファイルの配置

先ほどダウンロードした認証用ファイルを自分のサイト上に「.well-known」フォルダーを作成し、配置していきます。自分はエックスサーバーで契約しているのでエックスサーバーのファイルマネージャにアクセスし、自サイトドメインの「public_html」フォルダー内に「.well-known」フォルダーを作成しました。

「.well-known」フォルダーができたら、先ほどダウンロードした認証用ファイル「brave-rewards-verification.txt」をそのままの名前でアップロードしましょう。

エックスサーバーの方であれば、以下のようになればOKかと。

登録サイトの所有権の認証

認証用のファイルの配置ができたら、再度Brave Rewardsクリエイターサイトの認証ファイルを使った認証方法の詳細な手順の画面に戻りましょう。「認証」ボタンがあるのでプッシュ！

以下の画面に戻り、上部に「Channel verified!」が表示されればサイト所有権の認証は無事OKです。

以下の画面のように、自サイトドメインが表示されているのも確認できます。

サイト登録が完了したら、「.well-known」フォルダーおよび、認証用ファイルとも不要となるので削除しても大丈夫そうです。おそらく。

ちなみに、常時SSL化されているにもかかわらず上のように「HTTPSが有効になっていませんでしたドメインでHTTPSを有効にするか、別の確認方法を選択してください。」といったエラーが出た場合は、「.well-known」フォルダーや認証用ファイルの配置ディレクトリが正しいか確認しましょう。

自分は、ドキュメントルート（エックスサーバーであればpublic_html）の配下に「.well-known」フォルダーを作成するところを、ドメインのルートに配置してしまっていたため以下の認証エラーとなっていたっぽいです。正しく配置したらさらっと認証通りました。

Brave RewardsクリエイターアカウントとbitFlyerアカウントの連携

さぁこれで無事BATを受け取れる環境が整ったかいなぁと思って自サイトを開いてみてみると、「このクリエイターはまだ登録していません。」と表示されています。何かが足らないようです。１日ぐらい放置したが変化なしだったので、再度クリエイターサイトで確認してみます。

なんかヘルプ見たりいろいろ調べると、BATを受け取るウォレットの登録が必要なようです。おそらくこの赤枠で囲ったところで何かするんだろうなぁ・・・とは思って、右上のアカウントのところから設定やらセキュリティやらのところをいじくっていて戻ってみると・・・

BAT受け取り用ウォレットのところが「bitFlyerに接続」に変化しました！！ないす。bitFlyerアカウントならもちろん持ってるｗｗｗそれにしてもどんな仕様・・・。ってことで「bitFlyerに接続」をクリックしていきます。

bitFlyerのログイン画面が表示されるので、bitFlyerのアカウントでログインしましょう。

以下の画面で「許可する」をクリックします。

Brave Rewardsクリエイターの画面に戻り、無事bitFlyerウォレットと連携していることが確認できると思います。

自サイトを確認してみると無事「認証済」に代わりました。

※認証済になっていない場合はその右の「更新」ボタンをクリックしてみてください。

さいごに

Braveブラウザー、広告をブロックし、BAT付与といった付加価値もありこれから利用者増えそうな気配がします。

Braveの利用者が増えればBATの価値も上がっていくでしょうか・・・。

ただ、サイトとしてGoogleアドセンスを提供していながら、Braveの広告ブロック機能を紹介する矛盾。難しいですね。サイト配信者としてはアドセンスの恩恵を受けている部分はありますが、１ユーザーとして広告がないブラウジングの快適さは目を見張るものがあります。

パーソナライズされた広告などとても便利な時もありますが、世の流れとしてはプライバシーを守るということが大前提になってきている流れなのかなとBraveを使っていても感じます。

それでも！Braveもいいですが、Googleも好きですから。

システムエンジニアランキング

にほんブログ村

The post Braveブラウザー、はじめました。 first appeared on 星と月と太陽と.

ThinkPad X1 Carbon 2018(6Gen)のSSDをSATAからNVMeに換装した件

sei — Sun, 17 Apr 2022 12:20:05 +0000

こんにちは。seiです。

以前当サイトでも触れていましたが、我が愛機ThinkPad X1 Carbon2018年モデル、500GBのSSDを搭載していますがディスク容量不足気味となってきましたので新規SSDへ換装してみようと思い付き、決行しましたのでその時のことを書いてみます。

SSDをSATA→NVMeへ交換
おまけ：余ったM2 SSDを有効活用
1. SSDケース組み立て
2. ケースに格納したSSDをフォーマット

SSDをSATA→NVMeへ交換

SSDは新規購入直後にWD Blue500GBSATAのSSDに換装しましたが今回は容量アップと速度アップも兼ねてNVMeタイプのSSDに換装しようと思います。購入したのはWD Black 1TB、16000円程度。2018年当時はSN750が主流でしたが、その後廉価版のSN750SEが登場しさらにその後継として、SN770が登場したとのこと。だいぶ安くなってます。

※現在はさらに後継のSN7100に代わっていますかね・・・。

Western Digital｜ウエスタンデジタル WD BLACK SN7100 シリーズゲーミング向け M.2 2280 NVMe接続SSD 1TB WDS100T4X0E

Joshin web 家電とPCの大型専門店

Amazon

楽天

Yahoo!ショッピング

パッケージもかっちょよくやる気がみなぎっています。

開封していくぅ。久々にM2SSD見ましたが、こんなに小さかったっけって感じ。

片面実装タイプですのでThinkPad X1 Carbonの薄いボディにも問題なく収まります。

早速交換していきます。ThinkPad X1 CarbonのSSD交換に関して、詳しくは以前の投稿をご覧ください。

ThinkPad X1 Carbon 購入日記（第三部～SSD換装編～）

こんばんわ。せーです。暑さも和らいできた今日この頃。皆様、いかがおすごしでしょうか？さっそくですが、ThinkPad購入日記、今回もお付き合いください。前回はLenovoのノートPC、第6世代ThinkPad X1 Carbon（2018年...

あっという間に完了。交換作業自体は数分で終わるんでないかいな。

お決まりのベンチマークです。

単純比較はできないかもしれませんが、なっからパフォーマンスアップしていることは一目瞭然かと。

また、SN770はPCIe Gen4ですので、シーケンシャルリード5150MB/sが公称値ですが、そこまで出てないのはおそらくThinkPad X1 Carbon 2018がPCIe Gen3だからなのかな。

とはいえ今回の目的は容量不足に陥ったSSDの容量アップで、おまけでのパフォーマンスアップなのでその数字としてはとても満足。熱問題なんかは詳しく調べてません。

交換前：WD Blue SATA 500GB

交換後：WD Black NVMe 1TB

おまけ：余ったM2 SSDを有効活用

SSDケース組み立て

ということで1TBのM2 NVMe SSDへの換装が終わり、結果として500GBのM2 SATA SSDが余ります。

そんな未来が見えていたので今回はこれも購入しました。はい、USB接続のSSDケースです。一応SATA・NVMe両対応。このSSDケースに余ったWD Blue SATA 500GB SSDをぶっこんでいきたいと思いま～す。

玄人志向　M.2対応 /NVMe　GWM.2NVMe-U3G2CCA

コジマ楽天市場店

Amazon

楽天

Yahoo!ショッピング

付属品はこんな感じです。USBタイプAとタイプCの両方に対応してくれているところが地味にうれしい。工具は特殊なトルクスドライバーが付属してます。

まずはケースの裏蓋を外します。内部に基盤が入っているので外します。

外した基盤にThinkPad X1 Carbonから取り外したSATA SSDを装着します。なにも難しいことはないです。

次に付属しているスペーサーで基盤とSSDをネジで固定します。

そうしたら付属のチューインガム、もとい、冷却シート？熱伝導シート？を透明フィルムを剥がしてSSDに貼り付けましょう。貼り付けたら反対側の透明フィルムも剥がします。

そうしたらケースに基盤を戻します。

最後にネジで裏蓋を固定すれば完成です。チョー簡単。

ケースに格納したSSDをフォーマット

で、ケースに収納したSSDですが、初期化もせずケースに収納したのでそのままでは以前のデータが残ってしまっているので初期化していきます。

まずは、「ディスクの管理」を起動します。オレはいつも、Windowsボタン右クリックから起動してます。

SSDケースをPCに接続すると一応認識されるでしょう。が、Bitlocker暗号化がかかっている場合はそのままではアクセスできないと思います。今回は不要なデータなのでまっさらにしていきます。下の画像で「ディスク１」を初期化していく感じですね。

いろいろなやり方あるかと思いますが、Windowsならばお手軽にコマンドプロンプロやPowerShellから「DISKPART」コマンドを使って初期化していきます。

手順は、

PowerShellを起動する。
「diskpart」と入力しEnterキー
「list disk」と入力しEnterキー
PCで認識されているディスク（SSD）が表示されるので初期化を行うSSDのディスク番号を確認する。（今回はディスク1）
「select disk {初期化するディスク番号}」と入力しEnterキー
「clean」と入力しEnterキー
「DiskPartはディスクを正常にクリーンな状態にしました。」と表示されればOK。

「ディスクの管理」画面に戻るとディスクが「初期化されていません」と表示されていると思います。

対象のディスクを選択し「右クリック」－「ディスクの初期化」を選択しましょう。

ディスクの初期化ダイアログが表示されます。パーティションスタイルをお好みで選択し「OK」ボタンをクリックします。2TBより小さいディスク容量ならMBRでいいんでないでしょうか。

初期化が完了するとオンラインになりますが、まだ利用できません。ディスクをフォーマットする必要がありますので、対象のディスクを右クリックし、「新しいシンプルボリューム」を選択します。あとはウィザードが起動するのでドライブレター設定したりNTFS指定したりすればいいんではないでしょか。

フォーマットが完了すれば以下のように表示され、外付けUSBSSDドライブの完成です。

一応、ベンチマークとってみました。USBですからね。こんなもんなんでしょう。それにしてもHDDやUSBメモリーよりは俄然高速なんじゃないでしょか。

以上、ThinkPad X1 CarbonをSATA SSDからNVMe SSDへの換装を行ってみました。

※現在は後継のSN7100に代わってます。

Western Digital｜ウエスタンデジタル WD BLACK SN7100 シリーズゲーミング向け M.2 2280 NVMe接続SSD 1TB WDS100T4X0E

Joshin web 家電とPCの大型専門店

Amazon

楽天

Yahoo!ショッピング

玄人志向　M.2対応 /NVMe　GWM.2NVMe-U3G2CCA

コジマ楽天市場店

The post ThinkPad X1 Carbon 2018(6Gen)のSSDをSATAからNVMeに換装した件 first appeared on 星と月と太陽と.

お仕事 | 星と月と太陽と

AzureマルチリージョンでのDR構成をAzure Front Doorにアップグレードしてみる。

今回のゴール&前提条件

Azure Front Doorの構築手順

AFDリソースの作成

エンドポイントの作成

ルートの作成

カスタムドメインの割り当て

配信元グループの作成

フロントドアマネージャーからのルート追加

カスタムドメインの所有権確認＆エンドポイントのリダイレクト設定

カスタムドメインの所有権確認

カスタム ドメインとAzure Front Doorエンドポイントとの関連付け

Azure Front DoorでのDR構成が機能しているか確認

さいごに

Azure Functions .NET6インプロセスモデルから.NET8分離ワーカーモデルへの移行

はじめに

Azure Functions .NET8 分離ワーカーモデルへの移行手順

csprojファイルの編集

パッケージ参照の変更

Program.csファイルの追加

関数アプリコードの変更

[FunctionName]属性を[Function]属性に変更する

ILoggerのDI

usingの書き換え

staticクラス・メソッドをインスタンスクラス・メソッドに変更

トリガーやバインディングの変更

local.settings.jsonファイルの「FUNCTIONS_WORKER_RUNTIME」値を「dotnet-isolated」に変更

.NET8分離ワーカーモデル(ASP.NET Core統合)移行後のコード全体像

Azure Functions .NET 8 IsolatedをASP.NET Core統合なしに書き換え

Azure実行環境への反映

さいごに

Azure Communication Servicesを利用してメール送信してみる

Azure Communication Servicesとは？

なぜAzure Communication Services？

Azure Communication Servicesを利用したメール送信

ACSリソースの作成

Communication Services Emailリソースの作成

Communication Servicesリソースの作成

ACSでのメール送信をC#で実装する

Azure Communication Services Emailにカスタムドメインを設定する

ACS Emailにカスタムドメインの追加＆ドメイン所有権の検証

SPF・DKIＭ認証レコードをエックスサーバーに設定

カスタムドメインの送信元メールアドレス追加

カスタムドメインのAzure Communication Servicesへの接続

カスタムドメインを設定後のメール送信

さいごに

Azure Key Vaultを利用したシークレットの管理

Azure Key Vaultとは？

本日のゴール

Azure Key Vaultからのシークレット取得手順

Azure Key Vaultリソースの作成

KeyVaultコンテナーへのユーザーアクセス権の設定

Azure FunctionsマネージドID発行とKeyVaultコンテナーへのアクセス権の設定

Azure Key Vaultへのシークレットの保存

Azure FunctionsにKey Vaultシークレット取得の追加

Azure FunctionsからKey Vaultのシークレット取得を実行

マネージドIDを利用したAzure SQL Databaseへのアクセスを実装する

今回のゴール

Azure SQL DatabaseにマネージドIDを利用してアクセスする手順

Azure FunctionsのマネージドID発行

Azure Active Directoryグループの作成＆マネージドIDをグループに追加

Azure SQL Databaseのユーザー＆ロール追加

Azure Functionsの接続文字列変更

Azure SQL Databaseへの認証を「Azure Active Directory認証のみ」に設定

さいごに

AzureマルチリージョンでのDR構成を構築してみる。

今回のゴール

DR（ディザスターリカバリー）構成の構築手順

リソースグループの作成

Azure SQL Databaseの作成＆フェールオーバーグループ設定

Azure Functionsの作成&コードのデプロイ

仮想ネットワーク、プライベートリンク、グローバルVNetピアリングの設定

Azure Traffic Managerでのエンドポイント切り替え

稼働確認

パターン1：通常運用

パターン2：SQL障害発生

パターン3：バックエンド障害

パターン4：プライマリーリージョン障害

Azure FunctionsのBLOBトリガー利用時の罠2選

カスタムドメインとAzure Front Doorエンドポイントとの関連付け