SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
直近で Bicep を使用する機会があったのですが、その際に得られた知見についてまとめておきたいと思います。
Bicep と書いていますが、ARM でも共通する内容となるかと思います。
2024/07/29 追記
本投稿について X でコメントをいただいていたので、そちらを追記させていただきました。
素晴らしいbicepの記事を発見、いくつかコメントhttps://t.co/7ObOpZoRXb
— OMI Takekazu (@takekazuomi) July 28, 2024
miteta // Bicep の Tips (2024/07 版) at SE の雑記https://t.co/u1B3Yyp5lH
— guitarrapc_tech (@guitarrapc_tech) July 28, 2024
Azure ではリソースに対して 診断設定 を実施することで、リソースに対しての各種情報を指定した宛先に保存することができます。
取得する項目の取得については、カテゴリ グループとカテゴリを使用して選択することができるのですが、この設定について、いくつか理解度が低いところがあり、改めて情報を確認した内容についてまとめておきたいと思います。
SQL Server ベースの環境で実行プランのファイル (.sqlplan) の解析を行う際に SolarWinds Plan Explorer を使用することがあります。
SSMS でも実行プランの解析はできますが、複雑な実行プランになった場合は Plan Explorer を使用したほうが効率的に実行プランの解析を行うことができます。
Plan Explorer は実行プランのファイルだけでなく、デッドロックレポート (.xdl) についても解析を行うことができます。
Azure ストレージには静的な Web サイトの機能があり、静的コンテンツを Azure ストレージで公開する際に活用することができます。
この機能を Bicep で有効にしようとしたのですが、Bicep の定義として設定する機能が提供されていませんでした。
実施した対応としては Storage Account – Enable Static web site #10337 と同じですが、現状は deploymentSciprts で対応をする必要があるようですね。
Unable to execute a remote stored procedure over a linked server で解説されている内容と類似のものとなりますが、レプリケーションを使用している環境でも同様の事象が発生する可能性があります。
Azure の Data Factory / Synapse / Data Explorer といったリソースでは、マネージド仮想ネットワーク内にプライベートエンドポイントを作成することができる、「マネージドプライベートエンドポイント」というリソースを作成することができます。
通常のプライベートエンドポイントは、仮想ネットワーク内に展開を行います。
しかし、上述のリソースは仮想ネットワーク内に展開することができないのですが、このようなリソースで、使用できるプライベートエンドポイントを作成する方法として、マネージドプライベートエンドポイントという機能が提供されています。
マネージドプライベートエンドポイントを作成することで、セキュリティで保護されている特定のリソースへのアクセスポイントを、仮想ネットワーク内に展開することができないリソースでも作成することができます。
Synapse についてはドキュメントが見つからなかったのですが、ADF と ADX については、マネージドプライベートエンドポイントをBicep で作成することが可能となっています。
マネージドプライベートエンドポイントを作成する場合は、上述のキュメントの内容で Bicep を作成すればよいのですが、作成したエンドポイントの承認まで Bicep で実施しようとすると少し手間がかかったので、本投稿で承認をした際の内容をまとめておこうと思います。
今回はストレージアカウントの BLOB に対してプライベートエンドポイントを作成することを想定しています。
作成したサンプルについては https://github.com/MasayukiOzawa/bicep-sample/tree/main/managed-private-endpoint に置いてあります。
今年も 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 ベースのデータベースのデータをデータウェアハウス / データレイクに移行 / 同期をする際に使用する際に、従来からの ETL のパイプラインを作成することなく、Zero ETL (ゼロ ETL) を使用するというアプローチがあります。
Zero ETL を使用した場合、リッチな ETL のパイプラインを作成することなく、シンプルな設定ベースで、SQL Server ベースのデータベースからデータ同期を行うことが可能となります。
SQL Server ベースのデータベースでも Zero ETL を構築することができますが、その際に使用される機能 / 仕組みの特徴についてまとめておきたいと思います。
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 の診断設定について調べておく必要があったので、メモを残しておきたいと思います。
データ収集ルール (DCR) を使用した情報の取得を検討する必要があり、基本となる情報は次のドキュメントの内容となります。
