御成門プログラマーの技術日記

Microsoft AzureやAngularなどの技術情報を発信します

Azure Communication Services のメール送信機能がGAしたので触ってみた

2023年4月5日にGAしたAzure Communication Services のメール送信機能の紹介&試してみた記事です。

Azure Communication Services のメール送信機能がGA

2023年4月5日にAzure Communication Services のメール送信機能がGAされました。今まで Azure でメール送信を実現しようとする場合、Azure Market Place 経由で Twilio SendGrid を経由する必要がありましたが、今回のGAでメール送信機能を Azure 上で完結して実装することが可能となりました。

本日、Azure Communications Servicesは、マルチチャネル通信APIの包括的なスイートを拡張する「Emailサービス」の一般提供を発表しました。このサービスを使えば、企業は顧客エンゲージメントアプリケーションにメール機能を組み込み、顧客のコミュニケーション体験を向上させることができます。この新しいEmailサービスは、Exchange Onlineを利用しており、企業のセキュリティとプライバシー要件を満たします。さらに、Azure Communication Services Emailは、Power PlatformやAzure Logic Appsを通じたローコード/ノーコード機能を提供しています。また、充実した分析とエンゲージメント追跡機能により、ビジネスは顧客エンゲージメントとコミュニケーション戦略を改善できます。

techcommunity.microsoft.com

Azure Communication Services メール機能 試してみた。実装手順を紹介。

Azure Communication Services メール機能 を利用するには下記のような手順が必要です。

  1. Email Communication Services の作成
  2. ドメインの設定
  3. Communication Services の作成、設定
  4. Communication Services と Email Communication Services の紐づけ
  5. 送信処理のコーデイング

まず最初にEmail Communication Services を作成します。

英語だと Email Communication Services ですが、日本語ですと「メール通信サービス」です。後程出てくる「Communication Service(通信サービス)」とは別物なので注意が必要です。


メール通信サービス作成画面。リージョンはグローバル固定。


データロケーションに日本がないのが気になります。

Email Communication Services の作成の設定は以上です。「確認と作成」を押して作成を行います。
Email Communication Services ができたら、次にドメインの設定を行います。

メール送信元ドメインの設定について(Azureマネージドドメイン)

メール送信を行うということは送信元のメールアドレスが必要になりますが、Azure Communication Service では「Azure マネージドドメイン」を使用するか、自分の所有する「カスタムドメイン」を設定することができます。

Email Communication Service の画面で「ドメインをプロビジョニングする」を選択します。

ドメインの追加で「Azureドメイン」もしくは「カスタムドメイン」を選択できます。
今回は簡単にお手軽な「Azure ドメイン」を使用してみようと思います。

「Azure ドメイン」を選択すると自動的にサブドメインが割り振られます。このドメインは認証済みのドメインとなるためそのまま自分の環境で使用することが可能です。

<ランダムな文字列>.azurecomm.net

今回はこのドメインを利用してメール送信を行ってみましょう。続いて、Azure Communication Service(通信サービス)本体のデプロイを行います。

Communication Services の作成、設定

続いて通信サービスのデプロイを行います。

リソースの作成は「リソース名」と「データの場所」を指定するだけです。ここで注意事項があり、データの場所は先ほど Email Communication Service で設定したデータの場所と同じ場所にする必要があります。こちらには日本があるのですが、メールサービス側に日本がないため仕方なく別のリージョンを指定します。

作成したら Communication Service と Email Communication Service を紐づけする必要があります。
Communication Service 側で左の「メール」の「ドメインを選択します。」
「ドメインを接続する」をクリックします。

メールドメインの接続設定を行います。 「サブスクリプション」、「リソースグループ」、「電子メールサービス」で作成した Email Communication Service、「確認済みのドメイン」で先ほど追加したAzureマネージドドメインを選択します。

紐づけが終わったらAzure 側の準備は完了です。

メール送信処理の実装

最後に作成した Azure Communication Service を使ってメールを送信するコードを紹介します。
基本的には下記ページのクイックスタートを参考にすれば実装できると思います。
learn.microsoft.com

//メール送信設定
string connectionString = "<接続文字列>";
EmailClient emailClient = new EmailClient(connectionString);

//メール内容の設定
var subject = "<件名を入力します>";
var htmlContent = "<html>htmlのコンテンツをここに入力</html>";
var sender = "<Azure側で設定した送信元メールアドレス>";
var recipient = "<宛先メールアドレス>";

// メール送信処理
Console.WriteLine("メール送信中....");
EmailSendOperation emailSendOperation = await emailClient.SendAsync(
    Azure.WaitUntil.Completed,
    sender,
    recipient,
    subject,
    htmlContent);
EmailSendResult statusMonitor = emailSendOperation.Value;
Console.WriteLine($"メール送信完了 Status = {emailSendOperation.Value.Status}");
string operationId = emailSendOperation.Id;
Console.WriteLine($"Email operation id = {operationId}");

実行するとメールの送受信が実際に行われます。
メール送信の実装が簡単に行えることがお分かりいただけましたでしょうか?

今回は長くなってしまったので、独自ドメインの実装や気になった機能などは別に紹介しようとおもいます。

(参考) Azure Communication Services メール機能のメール送信制限機能の引き上げ方法について

Azure Communication Services のメール機能には悪用されないよう、時間当たりの送信数や容量などに制限が設けられています。そのレート制限を引き上げる方法については下記の記事で紹介しておりますのでそちらをご参照ください。
onarimon.jp

時間単位の使用金額コミットで割引「Azure savings plan(Azure 節約プラン)」を試してみた

Azure コスト節約オプションの中でも新しい2022年10月にリリースした「Azure savings plan(Azure 節約プラン)」についての説明と実際に購入して使ってみた体験談を紹介します。

Azure savings plan(Azure 節約プラン) とは

Azure savings plan(Azure 節約プラン) とはどのような Azure コスト節約オプションなのか紹介していきます。まずは公式ページの説明を引用します。

コンピューティング用の Azure 節約プランは柔軟な価格モデルです。 1 年間または 3 年間、コンピューティング サービスに対して時間単位の固定金額を支払うことをコミットすると、従量課金制価格から最大 65% の割引が適用されます。 節約プランにコミットすると、使用するリソースに対して、時間単位のコミットメント額まで割引を受けることができます。 節約プランのコミットメントの価格は、MCA および CSP のお客様の場合は USD、EA のお客様の場合は現地通貨で設定されます。 節約プランの割引は、コミットメント額ではなく、メーターとコミットメント期間 (1 年または 3 年) によって異なります。 節約プランは課金割引を提供するもので、リソースの実行時の状態には影響しません。

節約プランは、前払いまたは月払いでお支払いいただけます。 前払いと毎月の節約プランの合計コストは同じです。

コンピューティングの Azure 節約プランとは - Microsoft Cost Management | Microsoft Learnより引用。

以前、私が作成した資料の図で説明すると下記のような感じです。

https://www.slideshare.net/ssuser62228c/azure-256965306より引用。

まとめると、コンピューティングリソースが対象で時間ごとのAzureリソース支払い額を年単位でコミットすることで割引を受けられるオプションです。以前からあった Azure予約 は使用するリソース、SKUをコミットしていたため、柔軟性がないことが欠点でした。その欠点を埋める形で出てきたのが Azure 節約プランとなります。

Azure savings plan 使用時の注意事項

節約プランは予約、交換ができない点とコミットした額を使用しなくても課金が発生する点に注意が必要です。
learn.microsoft.com

Azure savings plan の対象リソース

節約プランの対象リソースは Azure リソースの中でもコンピューティングリソースに限られますが、サイズによっても対応しているものとしていないものがあります。詳しい対象リソースを探す方法は公式ページに記載されていました。

節約プランの対象となる製品の完全なリストは、Azure portal からダウンロードできる価格シートで確認できます。 EA ポータルの価格シートには、節約プランの価格は記載されていません。 ファイルをダウンロードしたら、Savings Plan で Price Type をフィルター処理して、1 年間と 3 年間の価格を確認します。

コンピューティングの Azure 節約プランとは - Microsoft Cost Management | Microsoft Learn より引用。

私の環境で調べたところ下記のようなリソースとSKUが対象でした。※最新の対象リソースとSKUは環境によっても違うかもしれないので、実際の対象はご自身の環境でご確認ください。

  • Azure Virtual Machines ※一部SKUのみ
  • Azure App Service ※一部SKUのみ
  • Azure Container Instances ※一部SKUのみ
  • Azure Functions ※一部SKUのみ

Azure savings plan の対象契約


Azure savings plan は下記の契約で Azure を利用しているサブスクリプションでのみ適用可能です。対応していない従量課金プランなどは購入しようとすると上記の画像のようなエラーになります。

  • Enterprise Agreement (EA)
  • Microsoft Customer Agreement (MCA)
  • Microsoft Partner Agreement (MPA)

詳しい対象契約は下記公式ページをご覧ください。
learn.microsoft.com

実際に Azure Savings Plan を購入してみた

サービスから購入する方法と Azure Advisor から購入する方法がサービス側から購入する方法で紹介します。
検索で「Savings plans」を選択。

節約プランのページが表示されます。
「追加」もしくは「今すぐ購入」をクリック。

プラン追加画面が表示されます。

項目名 設定値
Name 購入するプランの名前を設定します。
Billing subscription 請求が発生するサブスクリプションを選択します。
Apply to any eligible resource 節約プランが適用されるリソースのスコープを選択します。サブスクリプション、選択サブスクリプション、選択リソースグループ、マネジメントグループ
Term length 購入期間を選択します。3 Years, 1Years
Hourly commitment in JPY コミットする1時間あたりの日本円を入力します。
Billing frequency 請求頻度を選択します。毎月 or 全額前払い

こちらで設定した内容をコミットすることになりますので、購入期間、コミット金額は特にお気をつけください。

ちなみにプラン追加画面で「View recommendations」をクリックすると、過去30日間の使用量に基づいた推奨コミット額を提示してくれます。

購入が決定しましたら「Buy now」を押して、確認ダイアログも「はい」を押せば購入完了です。

購入してすぐは購入保留中となっています。

購入した節約プランの状況を確認する

購入した節約プランで気になるのが、購入した分が全部適用されているか?ですね。Azure Portal から使用率は簡単に確認することができます。

購入した節約プランは一覧で表示されます。一覧には有効期限、購入日、契約期間、スコープ、コミットメント額、過去1日間の使用率、過去7日間の使用率が表示されています。

7日間の使用率で絞り込みができるのでここで使用率が足りないものを見つけることができますね。

一覧から選択して、詳細を確認することができます。こちらの画面では、各節約プランの「時間経過に伴う使用率」が確認できます。ちなみに最新日が100%になっていないのは使用率データの反映が最大24時間遅れる可能性があるからです。

これにて、購入後の状況確認は以上です。

最後に

節約プランは、Azure予約と同様でコンピューティングリソースを必ず使う環境では影響もなくコスト節約を受けることができるのでとてもありがたい機能なので検討を進めていいと思います。ただし、キャンセルできないリスクがありますので購入時はコミット額をよく考える必要があると思います。コミット額については購入時に実際のリソースに基づいた推奨額を提示してくれますのでそちらを参考に決めるのがいいと思います。

Azure コスト節約オプションについてもこうして日々アップデートされているので、より便利なものが提供されるのが楽しみですね。

参考ページ

コンピューティングの Azure 節約プランとは - Microsoft Cost Management | Microsoft Learn

2023年4月1日からの Azure サービス日本円価格 改訂についての情報と影響範囲をまとめてみた

2023年2月28日に日本マイクロソフトから Azure サービスが2023年4月1日から日本円価格の15%値上げするという案内が届きました。価格の改定については2022年11月2日時点で発表されている内容でしたが、改めてインパクトの大きさを感じました。
news.microsoft.com

今回はAzure 値上げの影響と 値上げした今だからこそやりたい Azure をコストを効率よく節約する手法を紹介します。

2024年4 月の価格改定についての記事はこちらから

2024年にも大きな価格改定のニュースが飛び込んできました。
2024年4月の価格改定に関しては下記の記事で情報をまとめていますので、そちらをご参照ください。
onarimon.jp

以下からの情報は2023年4月の価格改定の情報となります。

2023年4月1日からのサービス価格改定で Azure サービス価格が15%の引き上げへ

2022年11月2日 に日本マイクロソフトの候補部門から下記のようなMicrosoft 製品の価格改定に関するアナウンスがありました。

日本マイクロソフト株式会社は、日本円の為替変動に伴い、2023 年 4 月 1 日から、法人向けライセンスおよびサービスの価格を改定し、オンプレミス製品を 20%、オンラインサービスを 15% 引き上げます。新価格は、2023 年 4 月以降の契約更新や新規契約のお客様に適用されます。

マイクロソフトは、ソフトウェア製品およびオンラインサービスの現地価格の影響を定期的に評価し、地域間の合理的な整合性を確保しております。今回の変更はその評価の結果により、米ドル水準に近づいた実勢価格に調整した結果となります。

このアナウンスメントは、ハードウェア (Surface 等) またはコンシューマ向けに提供している Windows, Office 及び Microsoft 365 サービス等は対象としておりません。マイクロソフトの製品がリセラーを通じて販売される間接販売の場合、最終価格と販売通貨は引き続きリセラーによって決定されます。

本ページのすべての内容は、作成日時点でのものであり、予告なく変更される場合があります。正式な社内承認や各社との契約締結が必要な場合は、それまでは確定されるものではありません。また、様々な事由・背景により、一部または全部が変更、キャンセル、実現困難となる場合があります。予めご了承下さい。

日本マイクロソフト、法人向けライセンスおよびサービスの価格改定について - News Center Japan より引用。

Azure のコストが15%増えるということで、企業としても少し身構えることになりそうですね...

2023年4月1日のサービス価格改定での影響範囲について

2023年2月28日に Microsoft から日本円で請求されるサブスクリプションに関連してるユーザーに向けて「重要なお知らせ-Azureの日本円での価格調整を近日中に実施します」という件名で案内が来ております。

その案内の中でこの変更がユーザーにどのような影響があるかを説明してくれていたのでまとめます。ただし、ここに書いてあることはあくまで一般的な情報ですので、実際の価格の変動についてはMicrosoftの担当営業、もしくは販売代理店に確認することをおすすめします。

エンタープライズ契約(EA)またはエンタープライズサブスクリプション契約(EAS)、MPSA、サーバーおよびクラウド登録(SCE)

これらの契約で Azure を利用しているユーザーは、契約開始時点でのAzure価格でベースラインが決められていて、契約期間(1年または3年ごと)はベースラインを上回らない価格保護が適用されています。そのため、これらの契約では今回の値上げではベースラインまでの値上げとなります。
learn.microsoft.com
ただし、契約更新のタイミングでベースラインが見直されるため、今回の15%値上げした価格でベースラインが見直されることになると思います。

従量課金制のサブスクリプション(MOSP/Web-Direct)

従量課金のユーザーはベースラインはなく、そのまま価格変動の影響を受けるため2023年4月1日以降は値上げした価格でコストがかかります。
azure.microsoft.com

Azure の クラウドソリューションプロバイダープログラム(CSP)

CSP の場合は 販売代理店のパートナーによって価格がどうなるか決定されるため、価格の変更はパートナーごとに変わります。
azure.microsoft.com

Azure の新しいコマース

Azureの新しいコマースという価格形態を始めて聞いたので、よくわからないので書いてあることをそのまま載せておきます。

Azure の新しいコマース価格は米ドル建てであり、今回の変更には影響ありません。

こんな今だからこそ改めて Azure コストを効率よく節約しよう

上記で紹介したとおり、Azure の使用量は値上げしてしまいます。少しでもコストを減らすことができる Azure で割引を受けることができる仕組みを紹介しようと思います。

「Azure Spot VM」 余っているリソースを割引で使用する

Azure Spot VMは、Azure内で余ってるリソースを使用することでVMを割引を受けて使用することができる機能です。

需要が上がると削除や停止される可能性があるので、本番の環境では使いずらいですが、バッチなど必要な時だけ動かせばいいものやテスト環境ではお得にVMを使うことができると思います。

詳しくは下記の記事で紹介しているのでこちらをご参照ください。
onarimon.jp

「Azure Resavations」で予約購入することで割引を受ける

Azure Resavations は Reserved Instance とも呼ばれることがあるサービスですが、Azure リソース1年分、もしくは3年分の利用を確約することでその期間のコスト割引を受けることができる機能です。

スケールサイズも変更できなくなるので、本番で使っている環境のリソースでそのまま使い続けることが決まっているリソースをお得に使用することができます。

詳しくは下記の記事で紹介しているのでこちらをご参照ください。 onarimon.jp

「Azure Saving Plan」 時間単位の固定金額を支払うことをコミットすることで割引を受ける

Azure Saving Plan は2022年に新しくリリースされた割引サービスです。Azure Resavations がリソース単位に使用を確約するのに対して、Azure Saving Plan は時間ごとに使用する最低使用料金を確約するプランです。そのため、リソースやサイズを指定することなく、柔軟に割引を受けることができるメリットがあります。

詳しくは下記の記事で紹介しているのでこちらをご参照ください。
onarimon.jp

最後に

円安の影響でさまざまな値上げラッシュが来ていましたが、とうとうIT業界にも来てしまいました。現状、この状況は避けることはできないので、少しでも負担が少なくなるよう工夫して今までどおり自由にサービスを選択して、最良のアーキテクチャを築けるようになっていきたいですね。私も1ユーザーとしてこういった情報を公開することで使い控えが起きるのではなく、活性化できる方向に持っていけるよう尽力していきたいです。

Azure App Service プランでアプリを最大アプリ数の推奨値を超えて乗せると落ちるから気を付けよう

Azure App Service のアプリ最大数の制限事項を超えてやらかした運用話について紹介します。

こちらの記事は私が 第42回 Tokyo Jazug Night で発表した「Azure App Service 運用体験談 ~コスト節約しようとしてダウンした App Service~」の内容を記事に起こして補足を追加したものになります。

Azure App Service 運用体験談 ~コスト節約しようとしてダウンした App Service~

第42回 Tokyo Jazug Night で発表したときのスライドはこちらです。


今回はクリスマス、年末にふさわしい?Azure App Service のやらかし運用体験談についてでした。
やはり運用話って面白いよね。

Azure App Service とは


今回のお話の主役 Azure App Service についてです。「Web アプリケーションをデプロイするサービスを提供する PaaS フルマネージド プラットフォーム」です。
参考URL

App Service と App Service Plan の関係性。こちらが今回の肝となる部分ですね。App Service Plan は複数のアプリを載せることができ、いくつアプリを乗っけても費用は App Service Plan のサイズ、数で決まるというもの。
App Service Plan の価格についての参考URL

Azure App Service のアンチパターンとなるコスト節約策「1つのプランにアプリをたくさん乗せ続ける」


上述した Azure App Service の価格体系を見て思いつく悪いアイデア「1つのApp Service Plan にすべてのアプリケーション乗っけたらお得じゃない?」説。

最初は数個単位で乗っけていたアプリケーション。アプリが増えるたびにテスト環境、ステージング環境、検証用環境、本番環境関係なく乗っけていきました。

気づいたら、自主規制レベルまでアプリを積んでいました。言い訳になるんですが、最初の頃は Azure で使える予算も少なく、なかなかプランをもう一個作れる環境ではなかったのでしょうがなくやっていたのです。

アプリを乗せ続けた結果、発生し始める不具合。最終的にダウンタイムが発生...


そのような状況で数年は運用できてましたが、あるときからこの構成が原因ゆえの不具合が増えてきます。

  • オートスケールでインスタンス数が最大値に張り付き続ける

    • CPUが高負荷のままに
  • テスト環境の負荷が本番環境に悪影響を与える

    • テスト環境が何かやらかすと本番の環境の動作も一緒に悪くなる
  • スケールアップ、インスタンス最大数を増やすことになり、増え続けるコスト

このときからアプリの数怪しいなとは思ってはいたのですが、プランのSKUをスケールアップしたり、オートスケールのインスタンス数増やしてるし大丈夫だろうと思っていた状況です。それだけアプリ使ってるんだから、コストアップもしょうがないと思っていました。

そしてとうとうプランに乗っかっているアプリケーション自体が動かなくなる現象が発生します。

スライドでは Azure 正常性アラートの通知画面を紹介していましたが、これは設定しておいて本当に良かったと思います。後日正常性アラートについても記事書こうかな。

ちなみに発表では紹介しませんでしたが、一回プラン全体が完全に落ちてます。アプリケーションがアクセス不能になり下記のようなエラーを吐いてました。
「Our services aren't available right now We're working to restore all services as soon as possible. Please check back soon.」

ここから解決編。原因は App Service Plan にアプリ載せすぎだった。


記事のタイトルでもネタバレしてますが、上記のような不調の原因は一つの App Service Plan に対してアプリを載せすぎたことが原因でした。上記の画像のようにApp Service Plan のSKUごとに最大アプリ数が設定されていてそれを超える場合、新規や既存のアプリにダウンタイムが発生する恐れがあるようです。

詳しい最大アプリ数は下記の Microsoft 公式ページをご参照ください。
App Service プラン - Azure App Service | Microsoft Learn 「アプリを新しいプランと既存のプランのどちらに入れる必要があるか」
というわけでこのような状態に陥った App Service Plan はアプリを適切に新しい App Service Plan に分離していく必要があります。

ちなみにプランに現在乗っかっているアプリ数を確認するには Azure Portal の App Service プランの概要ページより確認することができます。「アプリ/スロット」の部分から確認することができます。

この画像ですとアプリが25個、スロットが21個乗っかっています。

解決策「App Service Plan を環境ごとに分割する」


App Service Plan の分割を考える際にどのような点を考慮して分割していくのか。分割戦略を紹介しました。
スライドでは環境ごとに App Service Plan を分割した例を紹介しましたが、それ以外にもアプリケーションを完全に独立させたい場合、アプリを別のリージョンに配置したい場合は別のプランに分割する必要があります。

上記の分割案のようにプランの分割を行い、各プラン内で推奨のアプリ数内に抑えたところ、無事問題は解決されていきました。アプリケーション停止の問題だけでなく、インスタンス数やCPUの上限張り付きもなくなり、いかにアプリ数の超過がプランに影響を与えていたかがわかります。

App Service Plan の分割したことにより、問題が解決するだけでなく、様々な副次的な効果がありました。一番大きかったのはプランを増やしたにも関わらずコストが最大半分近くまで下がったことです。
コストが下がった要因としては下記の理由が挙げられます。

  • 必要なプランにだけ高いSKUのプランを用いることができたこと
  • 高いSKUのプランの負荷がさがったことで高いプランのインスタンス数が上がらなくなったこと
  • 普段パフォーマンスを必要としない環境のプランのSKUを低くできたこと

コストダウンしただけでなく、本番環境のプランを分割することができたので本番環境のリソースに必要最小限の権限を振ることができるようになったため、ガバナンスを効かせやすくなりセキュリティ運用面での課題を解決することもできました。

結論「制限事項はしっかり守る」、「下手なコスト節約は逆効果」です


今回学んだこととして無理なコスト節約は逆にコストがかかってしまうこと。公式ドキュメントに書いてあること、特に制約事項はしっかりと見ておく必要があると実感しました。このような陥りやすいパターンはアンチパターンとして紹介されている場合も多いのでアーキテクチャを構築する際には気をつけようと思いました。

Azure App Service 小ネタ集

App Service Plan の再起動方法


App Serive Plan の再起動についてはこちらの記事で別で紹介していますのでそちらをご参照ください。
onarimon.jp

App Service Plan の変更方法について


今回App Serive Plan の分割に使用したApp Serive Plan の変更についても別記事で紹介していますのでそちらをご参照ください。詳しい方法や制限事項等をまとめております。
onarimon.jp

プランの違うステージングスロットをスワップするとプランごと入れ替わる


プロダクション環境とステージング環境でプランが違う場合、それらをスワップするとどうなるかと気になりますね。私もやってみてわかったのですが、図のようにプランごと入れ替わってしまうので注意が必要です。そのことからステージング環境は本番環境と同じプラン上に乗っけておく必要がありそうです。

第42回 Tokyo Jazug Night 動画の紹介

2022/12/22(木)開催の 第42回 Tokyo Jazug Night は毎年年末恒例のLT大会でした。詳細は下記のConpass ページをご参照ください。
jazug.connpass.com

第42回 Tokyo Jazug Night の発表動画はこちらです
youtu.be
私の発表は21:30ぐらいから始まります(このリンクからすぐに飛べるよ)

サブスクリプションやリソースグループのタグを子リソースに継承するAzureコスト新機能「タグの継承」を試してみた

2022年11月の Microsoft Cost Management アップデートに出てきたサブスクリプションやリソースグループに設定したタグを子リソースに継承するAzureコスト新機能「タグの継承」を試してみたので紹介します。

タグの継承を使用してサブスクリプションとリソース グループのタグでグループ化する機能がプレビューに

Microsoft Cost Management の2022年11月アップデートで面白い新機能を見つけました。

タグ付けはコストをグループ化するための効果的なメカニズムですが、すべてのリソースにタグを付け、リソース プロバイダーに依存して、課金パイプラインでの使用に関するタグをサポートおよび出力する必要があります。これらの制限を克服し、コスト レポートにタグを簡単に使用できるようにするために、Cost Management タグ継承プレビューを使用して、コストの詳細でリソース グループとサブスクリプションのタグをリソース使用状況に自動的に適用できるようになりました。

Microsoft Cost Management updates—November 2022 | Azure のブログと更新プログラム | Microsoft Azure より引用したものを翻訳。

今までコスト詳細で出力される明細の単位はリソース単位でしたが、そのリソースに登録されたタグしか表示されていなかったため、グループ化するためにはすべてのリソースにタグ付けをする必要があり管理が大変でした。

今回の機能が出てきたことでサブスクリプションやリソースグループに設定されたタグがその子リソースに継承されるため、その設定の手間が省ける機能となります。それでは実際に動きを見てみましょう。

タグの継承(プレビュー)を実際に試してみた

タグの継承を有効にする方法

Microsoft の公式ドキュメントにも載っていましたが、タグの継承の有効にするには下記のアクセス許可が必要なようです。

  • サブスクリプションの場合:Cost Management 共同作成者
  • EA 課金アカウントの場合:エンタープライズ管理者
  • MCA 課金プロファイルの場合:課金プロファイルの共同作成者

この権限を持ったアカウントで Azure Portal から設定を変更できます。 「Cost Management」→「課金アカウントの管理」→「Tag inheritance (preview)の編集」をクリックします。
タグの継承の設定画面が出てきます。

「Automatically apply subscription and resource group tags to new usage data. (サブスクリプションとリソース グループのタグを新しい使用状況データに自動的に適用する)」のチェックを入れます。  
「When the resource has a tag with the same name:」でリソースが同じ名前のタグを持っているときにどうするか確認されます。
「Keep the resource tag」の場合は既存のリソースのタグがそのまま残り、「Use the subscription or resource group tag」の場合はサブスクリプションやリソースグループのタグの値が優先されリソースのタグの値が上書きされます。詳しい上書きのルールの説明については公式ページに書いてあるのでそちらをご参照ください。


あとは適用するだけです。ここにも書いてあるように適用されるまで最大24時間ほどかかるようです。

ちなみにタグが継承される範囲ですが、月の途中に設定を行った場合その月の1日からの使用状況レコードが設定した日に存在していたタグを使用して更新されるみたいです。また、タグの継承設定を無効にした場合は、継承されて作られたタグは削除されるようです。

継承されたタグを確認する・活用する

24時間後に実施に確認してみました。今回の継承ですが、あくまでコスト状況で使われるタグのようで実際のリソースにはタグは付与されていませんでした。影響はあくまでコストの範囲ということです。

続いてコストの使用状況詳細を確認します。 ダウンロードはこちらからできます。使用状況詳細をAzure Portal からダウンロードする方法については別の記事で紹介しておりますのでご参照ください。

CSVファイルをダウンロードしてみると、タグ (Tags)列にリソースには設定していないリソースグループのタグが入ってました。どうやらタグの継承は成功しているようです。
これは便利そうな機能だ。また、公式ページにも書いてありましたが、Cost Management の画面からタグの値でグループ化して表示することもできるのでコスト分析がさらに捗りそうです。グループ化の部分でタグを選択するだけです。

AzureCostManagement(Microsoft Cost Management) 周りは以前は機能も少なく自分で管理用にシステムを構築しないと不便な部分もありましたが、Azure Portal で完結できるようになる時代が近づいている気がしますね。

参考ページ

Azure で発生した SLA返金や調整額の明細を知る方法

Azure で SLAが発生した場合の内訳や返金理由を調べる方法の備忘録です。

調整金額が発生しているか確認する方法

Azure Portal の「コスト管理と請求」→請求先を選択→課金欄の「クレジット + コミットメント」を選択すると月ごとのクレジットコミットメント状況を確認できます。

その中の「調整」という列にある金額が気になります。

リンクをクリックすると Service Level Agreement Credit や Usage Emission Credit と書いてありますが、何が起きて発生した調整金額なのかは全くわかりません。

実際に運用しているとあるかなと思うのですが、会社の上の人や経理の人からこの調整額ってなんなのって説明求められることありますよね。そんなときに調整額の内訳や発生理由を調べる方法ないかなーと疑問に思いました。

結論「現状はAzure課金サポートやパートナーに聞くしか方法はない」

調べてみたのですが、現状ですと発生した調整金額と↑で出てきた Service Level Agreement Credit や Usage Emission Credit レベルの情報ぐらいしか出てきませんでした。

そのため、調整額の詳細や内訳を確認するにはAzure課金サポート(Azure Enterprise Agreement サポート)や各社で契約しているパートナーに確認するしか方法はなさそうです。ちなみにパートナー経由で契約している場合で返金の内訳を知りたい場合はAzure課金サポートではなく、パートナーの担当者に聞いた方が良いみたいです。

問い合わせの際は 「請求先アカウントID」、「EA加入契約番号」、「発生した調整額の名称」、「発生した月」、「発生した金額」、「サブスクリプションID」など一緒に載せてあげると回答しやすいと思います。

発生した調整金額の扱いについて

余談ですが、発生した調整金額はその月の発生したリソースのコストから差し引かれるのではなく、クレジットに調整金額分追加されて次回クレジット使用時に使用されます。

Microsoft 「OpenHack DevOps」参加レポート

今回は Microsoft の主催する OpenHack に参加してきましたので参加レポートを書いてみました。意外と調べてみても情報はまだ少なかったのでこれから参加する方の参考になったら幸いです。

OpenHack とは

Microsoft Open Hack 概要

公式ページの説明を引用します。

Microsoft OpenHackは、開発チーム(Open)と専門家を結び、対面またはオンライン(Virtual)で実践的な実験(Hack)を通じて一連の実世界の課題に取り組む、開発者に焦点を当てた取り組みです。
OpenHackは、マイクロソフトの社員、顧客、パートナーに、ユニークで楽しいスキルアップの機会を提供します。参加者はチームで協力しながら、複雑さを増す課題をクリアしていきます。積極的に参加し、深いコラボレーションを必要としながら、共に学びます。

openhack.microsoft.com より引用
説明からもわかるとおり、ハンズオンとは違い手順書や答えがない状態でチームで協力しながら課題を解き進めていくイベントですね。

Microsoft Open Hack のトピックについて

Microsoft Open Hack には現在のところ、8種類のジャンルがあるようです。

  • AI-Powered Knowledge Mining
  • App Modernization with NoSQL
  • Containers
  • DevOps
  • Migrating Microsoft workloads to Azure
  • Serverless
  • Modern Data Warehousing
  • Security, Compliance, and Identity

それぞれのトピックの詳しい説明については公式ページをご参照ください。私は今回 DevOps に参加しました。

OpenHackの参加方法について

現在Webページ上では参加ページは公開されていないようです。私の場合、所属している会社の Microsoft の担当者の方から勧めていただき、参加しました。参加を検討している方は Microsoft の担当者の方に聞いてみた方が良さそうです。

ある達成点まで達することができたらとディジタルバッジがもらえる※


Open Hack では課題が与えられ、チームでそれを解いていくのですが、ある達成点までいくことができたらデジタルバッジをもらうことができます。
www.credly.com

OpenHack DevOps 参加レポート

OpenHack の流れ、進み方

今回の OpenHack は3日間で9:00~16:30(最終日は15:30まで)というスケジュールでした。

基本的な流れとしては課題が10問用意されていて、各チームでそれを解き進めていきます。チームには Microsoft のコーチの方がいて、悩んだ時にアドバイスをもらえます(直接的な答えはされないようです)。小休憩やお昼の休憩などは各チームで適宜取る形式です。

OpenHack 中はひたすら問題と向き合い続けます。

OpenHack DevOps の内容・難易度について

具体的な問題の内容は公開しないようにとのことなので控え、公開されている情報を元に OpenHack DevOps の内容を紹介します。

公式ページによると概要は下記のように書かれています。

DevOps OpenHackは、DevOpsの基本的なスキルアップと開発を可能にします。 ゼロダウンタイム・デプロイメント戦略は、本番環境での摩擦を減らし、システムのダウンタイムなしに新機能をより頻繁に、安全にデプロイできるようにします。

技術としては下記のような技術が挙げられていました。

GitHub or Azure DevOps (team choice), Azure App Service, Log Analytics, Application Insights, Azure Monitor, Azure SQL Database, Azure Container Registry, Key Vault, Bicep, Terraform

https://openhack.microsoft.com/ より引用

概要、必要技術から見てわかるとおり、GitHub もしくは Azure DevOps を中心に使った開発でした。大体、概要に書かれているイメージと相違ない内容だったと思います。

難易度としては公式ページの前提条件に書かれていたように Microsoft 独自の難易度指標でレベル300 のため、全くの初心者には難しい内容だったと思います。私の場合ですが、仕事で普段触っている部分はトライ&エラーで少しずつ良い感じに進められ、疎い分野のときは結構悩みながらも進められるような難易度だったと感じました。

最初にも書きましたが、全くの初心者の方には難しいと思うので、他の Microsoft が主催しているハンズオンセミナーに参加してみてからの方が良いかもしれません。

OpenHack に参加した感想

参加前はWeb上であまり詳細な情報を得られず、どんな感じなんだろうと思いながら参加したOpenHack でしたが、結果としては学びや発見があり、なにより楽しく開発をできたと思います。受講中に「このやり方は実際の仕事の方にも持ち帰ることができる技術だな」と思える学びも多く、大変勉強になりました。

今回は普段仕事をしているチームメンバーと一緒に参加したため、チームとしてワイワイガヤガヤしながらのモブプログラミングも盛り上がりましたね。チームとしてのレクリエーション的要素としても良かったなと思います。

他のトピックの Open Hack にも挑戦していきたいなと思っております。この記事を読んだ方も興味がございましたら是非、参加してみてください!!

参考ページ

openhack.microsoft.com

Azure Web App を別のリソースグループにある App Service Plan に移動する方法

Azure Web App が乗っかっている App Service Plan を変更する際に 別リソースグループにある App Service プランに移動する方法を紹介します。

解決方法は簡単

「App Service Plan のリソースグループの移動を使用する」 だけです。

詳細について下記で解説していきます。

Azure App Service アプリの移動についての制限事項

通常 Azure Apps Service のアプリを別の App Service Plan に移動させる場合、下記のような制限があります。

別の App Service プランへのアプリの移動は、移動元プランと移動先プランが "同じリソース グループおよび同じ地理的リージョン" に存在している場合に限り可能です。
App Service プランの管理 - Azure App Service | Microsoft Learn より引用

今回フォーカスしたいのはこの同じリソースグループ内に存在しているプラン間でのみ移動可能という点です。例えば同じプラン内に開発用環境のアプリと本番用のアプリを作っていたが、規模が大きくなったり、セキュリティ上の観点からリソースグループを分けたいという需要があると思います。
この場合、現状の同一リソースグループ間のみの制限があると App Service Plan は同一のリソースグループにしか置けなくなりますね。

アプリの移動後にプランを別のリソースグループを移動してしまえば別のリソースグループのプランを移動可能

簡単なことだったのですが、App Service Plan は比較的簡単に影響が少ない状態でリソースグループの移動が可能です。そのため、下記のような手順でApp Service のアプリを別のリソースグループにあるプランに移動可能です。

  1. 移動元のプランと同じリソースグループに移動先のプランを作成もしくは移動する
  2. アプリを移動先のプランに移動する
  3. 移動先のプランを別のリソースグループに移動する

こうすることで別のリソースグループにあるプランでもアプリを移動することが可能でした。
是非、皆さんもお試しください!!

Azure SignalR Service の価格形態を調べてみた【コスト見積・最適化】

Azure SignalR Service の課金形態や価格要素を調べてみました。

Azure SignalR Service とは

Azure SignalR Service の基本的な機能や使い方についての説明については別の記事で紹介しています。ぜひこちらをご参照ください。
onarimon.jp

Azure SignalR Service の価格形態について


Azure SignalR Service の課金形態について調べてみました。課金要素としては「価格レベル」、「ユニット数」、「メッセージ数」がキーになります。

まず「価格レベル」ですが、現在のところ Free, Standard (標準), Premium の3種類のレベルがあるようです。 価格レベルによって同時接続数(コンカレント接続数)やメッセージ数の制限、SLA、 最大ユニット数などが変わってきます。

続いて「ユニット数」ですが、Azure SignalR Service におけるインスタンス数みたいなものです。1ユニットごとに同時接続数や1日にやり取りできるメッセージ数が変わります。

最後に「メッセージ数」ですが、Standardレベル、Premiumレベルでは1ユニットごとに日単位で100万メッセージまでは費用がかかりません。1日でそれ以上のメッセージが必要な場合は使用した分追加で課金が発生します。

これらの課金要素により Azure SignalR Service の課金が決定します。自分は最初勘違いしていたのですが、接続数は間接的にはコストに影響しますが、直接接続した数での課金は発生しません。詳しくは下記の Microsoft 公式ドキュメントをご参照ください。
azure.microsoft.com

Azure SignalR Service の価格レベルを選定する方法

価格レベルを選定する方法についてです。ちょこっと試すなどテスト用の環境であればFreeレベルで大丈夫です。

本番の環境であれば StandardレベルかPremiumレベルを選択しましょう。 Standard と Premium の大きな違いはSLAと「可用性ゾーン」、「ユニットの自動スケーリング」、「カスタムドメイン」が使えるかの違いです。特に影響が大きいのが「ユニットの自動スケーリング」だと思います。自動スケーリングがないとボトルネックになるのが同時接続数ですね。使用するアーキテクチャで同時接続数が最大値を超える可能性があるなら Premium プランにして自動スケーリングを設定した方がよいと思います。

最後に

Azure SignalR Service の課金形態を紹介しましたが、シンプルでわかりやすい課金形態だったと思います。ぜひ、Azure SignalR Service をどんどん使ってみてもらえると幸いです。ご拝読ありがとうございました。

【Azure SignalR Service】Webアプリケーションにリアルタイムの通信機能を実装する【Azure SignalR Service 使ってみた】

Webアプリケーションにリアルタイムの通信機能を実装する Azure SignalR Service の紹介をします。
こちらの記事は私が Japan Azure User Group 12周年イベントで発表した「Azure SignalR Service 使ってみた」を記事に起こしたものになります。

Azure SignalR Service とは

Azure SignalR Service とはを簡単にまとめると下記のような機能を提供する Azure のサービスです。

  • リアルタイムに通信できる機能を提供
  • 通常の通信では少しめんどくさいサーバーからクライアントに向けての通信を簡単に実装できる
  • ASP.NET にもあった ASP.NET SignalR 機能のAzureマネージドサービス版
  • すべてのクライアントにブロードキャスト、個別のユーザーに送信、グループに送信など使い分け可能

Azure SignalR Service の利用例

Azure SignalR Service のリアルタイムな通信の機能を使うことでどのような利用用途があるか数例紹介します。
公式ページにはそのほかにもいくつかパターンが紹介されているのでそちらもご参照ください。

データのリアルタイム更新


グラフやチャートなどが表示されているダッシュボード、スポーツスコア中継速報のページなどをイメージします。

これらアプリケーションでは Azure SignalR Servie がない場合は、クライアント側からアクションを起こさないと最新のデータの取得ができませんが、Azure SignalR Service を使うことでデータに更新があったタイミングでサーバー駆動でクライアント側にデータをプッシュすることができるため、無駄な通信を行うことなく常に最新の情報を取得できます。

キュー処理の結果を送信する


長い時間のかかる処理などでAPIリクエスト中にAPIがキューに処理を投げるような動きを考えます。

その場合、リクエストのセッションはキューに投げて成功したというレスポンスが返却されて終了してしまいますが、クライアントとして処理が終わったことを検知できませんね。

処理が終わったタイミングで Azure SignalR Service を経由で処理を投げたクライアントに個別にレスポンスメッセージを返してあげることでクライアント側で処理の終了を検知した処理を実装することができます。

リアルタイムのチャットを提供する


複数のユーザーが Azure Signarl Service に接続していれば相互にメッセージをリアルタイムにやり取りするできます。

個別のクライアントやグループにだけメッセージを送信することも、接続を確立しているユーザーすべてに送信するブロードキャストも可能です。

Azure Signalr Service の利用フロー


Azure SignalR Service をアプリケーションの中で実装するときのフローを簡単に説明します。

  1. クライアントからAzure SignalR Service に対して Negotiate のリクエストを行います
  2. Azure SignalR Service で正しく認証が行われると、接続情報がリクエスト元に返却されます
  3. 返却された接続情報を使用してクライアントと Azure SignalR Service 間で Connection が確立されます
  4. 接続された状態でメッセージ送信のリクエストを送信すると、Azure SignalR側でリクエストされた送信先にメッセージがプッシュされます

上の図ではAzure SignalR に直接、接続や送信のリクエストを送っていますが、実際にはAPI として Azure Functions を間に経由していますAzure Functions の SignalR Service バインドを使用することで Azure SignalrR Service の認証や送信の処理を行ってくれるバックエンドを簡単に実装できました。
Azure Functions における SignalR Service のバインド | Microsoft Learn

ここら辺の実装方法については別のタイミングで紹介できたらと思っています。

ローカル開発で便利だった Azure SignalR Local Emulator

ローカルでの開発にて、Azure 上にある SignalR Service を使用することなく、エミュレーターで開発することでローカルでの開発をスムーズにします
Azure SignalR Local Emulator というエミュレータがあるのでそちらを使用すると便利です。こちらについても別のタイミングで紹介できたらと思っています。
github.com

実際に触ってみた感想

今回実際に Azure SignalR Service を使用してみて、思った以上の利用用途の多さにWebアプリケーションのできることの幅が広がる可能性を感じました。

そして、思ったより簡単にAzure SignalR Service を使用したアーキテクチャのアプリケーションが実装できた印象です。

試してみたいなアイデアも浮かぶので Azure SignalR Service を使ったアプリケーションをどんどん構築していきたいと思います。この記事を読んで頂いた方にも Azure SignalR Service に興味を持っていただいた方がいれば幸いです。ありがとうございました。

Japan Azure User Group 12周年イベント

JAZUGで Azure SignalR Service についてLT登壇した際の動画となります。
デモなども行っていますのでよろしければこちらもどうぞ。

「Azure SignalR Service 使ってみた」 3:17:07~です。トラブルで前半スライドが表示されてません。
youtu.be

発表資料はこちらです。

www.slideshare.net