Azure ではリソースに対して 診断設定 を実施することで、リソースに対しての各種情報を指定した宛先に保存することができます。
取得する項目の取得については、カテゴリ グループとカテゴリを使用して選択することができるのですが、この設定について、いくつか理解度が低いところがあり、改めて情報を確認した内容についてまとめておきたいと思います。
Author Archive
SolarWinds Plan Explorer を使用した xml_deadlock_report の解析
SQL Server ベースの環境で実行プランのファイル (.sqlplan) の解析を行う際に SolarWinds Plan Explorer を使用することがあります。
SSMS でも実行プランの解析はできますが、複雑な実行プランになった場合は Plan Explorer を使用したほうが効率的に実行プランの解析を行うことができます。
Plan Explorer は実行プランのファイルだけでなく、デッドロックレポート (.xdl) についても解析を行うことができます。
Bicep を使用して Azure ストレージの静的な Web サイトを有効化する
Azure ストレージには静的な Web サイトの機能があり、静的コンテンツを Azure ストレージで公開する際に活用することができます。
この機能を Bicep で有効にしようとしたのですが、Bicep の定義として設定する機能が提供されていませんでした。
実施した対応としては Storage Account – Enable Static web site #10337 と同じですが、現状は deploymentSciprts で対応をする必要があるようですね。
レプリケーションを使用している環境のリンクサーバーの注意点
Unable to execute a remote stored procedure over a linked server で解説されている内容と類似のものとなりますが、レプリケーションを使用している環境でも同様の事象が発生する可能性があります。
Bicep でマネージドプライベートエンドポイントを承認する
Azure の Data Factory / Synapse / Data Explorer といったリソースでは、マネージド仮想ネットワーク内にプライベートエンドポイントを作成することができる、「マネージドプライベートエンドポイント」というリソースを作成することができます。
通常のプライベートエンドポイントは、仮想ネットワーク内に展開を行います。
しかし、上述のリソースは仮想ネットワーク内に展開することができないのですが、このようなリソースで、使用できるプライベートエンドポイントを作成する方法として、マネージドプライベートエンドポイントという機能が提供されています。
マネージドプライベートエンドポイントを作成することで、セキュリティで保護されている特定のリソースへのアクセスポイントを、仮想ネットワーク内に展開することができないリソースでも作成することができます。
Synapse についてはドキュメントが見つからなかったのですが、ADF と ADX については、マネージドプライベートエンドポイントをBicep で作成することが可能となっています。
- Microsoft.DataFactory factories/managedVirtualNetworks/managedPrivateEndpoints
- Microsoft.Kusto clusters/managedPrivateEndpoints
マネージドプライベートエンドポイントを作成する場合は、上述のキュメントの内容で Bicep を作成すればよいのですが、作成したエンドポイントの承認まで Bicep で実施しようとすると少し手間がかかったので、本投稿で承認をした際の内容をまとめておこうと思います。
今回はストレージアカウントの BLOB に対してプライベートエンドポイントを作成することを想定しています。
作成したサンプルについては https://github.com/MasayukiOzawa/bicep-sample/tree/main/managed-private-endpoint に置いてあります。
Microsoft MVP を再受賞させていただきました
今年も Microsoft Most Valuable Professionals (Microsoft MVP) を 再受賞 させていただくことができました。
今回の活動期間では、Azure Stack HCI の投稿もいくつか書くことができていたので、以前から受賞させていただいており、SQL Server が含まれる Data Platform の他に「Azure Hybrid & Migration」も申請させていただいたところ、こちらのカテゴリでも受賞をさせていただくことができ、今回の活動期間の審査では「Data Platform」と「Microsoft Azure の」2 つのカテゴリで受賞させていただくことができました。
今回の再受賞で 14 年目の受賞となりますが、2 つのカテゴリで受賞させていただくのは、今回の受賞が初めてでした。
Azure Stack HCI は 22H2 / 23H2 の調査をするタイミングと合致していたため、今回は記載できたのですが、次回の活動期間では同一の厚みで検証できるかが微妙なので、次回は、今回と同じアワードカテゴリ / テクノロジ領域での再受賞は厳しそうですね…。
(Azure Stack HCI は個人的な興味で小規模環境として触っていることもあり、専門に携わっている方と比較すると私のスキルレベルが数段下になってしまうということもありますし)
今回は、Azure Hybrid & Migration をテクノロジ分野として記載するため、Azure SQL を記載していなかったのですが、PaaS の SQL Server ベースの環境についても、継続して情報をキャッチアップしていきたいと思います。
最近は活動の幅が狭くなってしまっており、ブログでの情報発信しかできておりませんが、今後も当ブログで、SQL Server ベースの環境の情報を中心に、検証した内容を継続して投稿をしていければと思いますので、引き続きよろしくお願いいたします。
SQL Server ベースのデータベースからの Zero ETL について (2024/07 版)
SQL Server ベースのデータベースのデータをデータウェアハウス / データレイクに移行 / 同期をする際に使用する際に、従来からの ETL のパイプラインを作成することなく、Zero ETL (ゼロ ETL) を使用するというアプローチがあります。
Zero ETL を使用した場合、リッチな ETL のパイプラインを作成することなく、シンプルな設定ベースで、SQL Server ベースのデータベースからデータ同期を行うことが可能となります。
SQL Server ベースのデータベースでも Zero ETL を構築することができますが、その際に使用される機能 / 仕組みの特徴についてまとめておきたいと思います。
Bicep を使用して異なるモジュールで作成したリソースをシンボリック名として利用する
Bicep を使用して、Azure リソースの設定を行う際に、scope / parent で 拡張リソース を使用することで、設定を行うというケースがあります。
これらの属性にリソースを設定する際には、リソースの ID / 名称ではなく、Bicep 内で定義しているリソースのシンボリック名を指定する必要があります。
実際の設定例としては、診断設定のリソースとなる Microsoft.Insights/diagnosticSettings があります。
このリソースは Azure の「診断設定」を行うためのリソース定義となりますが、「どのリソースに対して診断設定を行うか」については、「scope」に対して、「resourceSymbolicName」を指定する必要があります。
Azure ストレージを例とすると、ストレージアカウントを作成するための Microsoft.Storage/storageAccounts の Bicep 内で診断設定を実施するのであれば、同一のファイル内にストレージアカウントを作成する定義があるため、ストレージ対しての診断設定のためのシンボリック名を指定することは容易です。
診断設定は様々なリソースに対して設定が可能なため「診断設定をまとめたモジュールを作成したい」というような場合には、診断設定を行うための Bicep のファイル内でシンボリック名を定義する必要があるのではないでしょうか。
本投稿では、異なるモジュールで定義されたリソースを、シンボリック名として作成するための方法について考えてみたいと思います。
サンプルとして作成した Bicep ファイルについては https://github.com/MasayukiOzawa/bicep-sample/tree/main/diagSetting で公開しています。
今回は作成したストレージアカウントに対して、診断設定を行うというシナリオを検討しています。
Azure の診断設定についてのメモ (2024/06 版)
Azure の診断設定について調べておく必要があったので、メモを残しておきたいと思います。
データ収集ルール (DCR) を使用した情報の取得を検討する必要があり、基本となる情報は次のドキュメントの内容となります。
Azure の廃止予定機能の確認方法
先日、Azure の 既定の送信アクセス廃止後の KMS によるライセンス認証について (2024/06/19 時点の動作) という投稿を書きました。
廃止予定の機能のアナウンスは Azure updates で実施されていますが、他にどのような方法があるのかが気にかかりましたので調べてみました。