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 で実施されていますが、他にどのような方法があるのかが気にかかりましたので調べてみました。
Azure の 既定の送信アクセス廃止後の KMS によるライセンス認証について (2024/06/19 時点の動作)
※2024/06 時点の情報 / 環境で確認をしているため、今後動作は変わっている可能性があります。
2023/09/29 に Default outbound access for VMs in Azure will be retired? transition to a new method of internet access というアナウンスがありました。(2023/10/19 に Default outbound access for VMs in Azure will be retired? updates and more information 追加情報のアナウンスが行われています)
現状は、既定の送信アクセス が有効となっているため、明示的なインターネット送信接続の設定が行われていない場合、「既定の送信パブリック IP アドレス」が割り当てられ、インターネットへの送信接続が可能となっています。
2025/09/30 以降に新しくデプロイされたリソースについてはこの既定の送信アクセスが廃止され、これ以降にデプロイした VM については、既定の送信アクセス以外の方法 (パブリック IP アドレスの付与 / NAT ゲートウェイをサブネットに割り当て / パブリック IP アドレスを持つロードバランサーに割り当て) でインターネット送信接続の経路を確保する必要があります。
(期限日以降に展開した VM と VNET のどちらが対象となるのかが判断できていないため「リソース」という記載をしています)
今まで既定の送信アクセスを使用して、Windows のライセンス認証のための KMS にアクセスしていた VM について、既定の送信アクセスが廃止された後はどのような挙動になるのかが気になり試してみました。
スタンドアロン環境の SQL Server インスタンスで診断ログ (SQLDIAG ログ) を取得する
FCI (フェールオーバークラスターインスタンス) 環境の SQL Server では、デフォルトの設定で診断ログが取得されています。
グディレクトリに SQLDIAG ログが拡張イベントのファイルとして出力されており、問題が発生した場合にはこのファイルの内容の解析を行うことがあります。
スタンドアロン環境の SQL Server インスタンス (非 FCI の単一サーバー環境) では診断ログは出力されていないのですが、設定を行うことでスタンドアロンインスタンスでも取得を行うことができます。
検証環境には FCI も構築している環境はあるのですが、スタンドアロンインスタンスのほうが検証を実施しやすい内容があるため、本投稿ではスタンドアロンインスタンスで診断ログを取得する方法についてまとめておきたいと思います。
パイプラインによるデータコピーで ADL Gen2 をステージングアカウントとして使用した場合にディレクトリが残る問題についての対応方法
Data Factory のコピーアクティビティーを使用したデータコピーでは、ステージングコピー を使用することができます。ステージングは、DWH に対してデータコピーを行う際に使用されるケースがあるのではないでしょうか。
ステージング コピーのしくみ には次の記載があります。
コピー アクティビティの実行後に一時データをクリーンアップできるように、ステージング ストレージ内の Azure Data Factory に削除アクセス許可を付与する必要があります。
コピーアクティビティにより格納されたステージングデータですがアクティビティ内のクリーンアップで自動的に削除が行われます。
しかし、Azure BLOB ストレージを使用している場合は問題ないのですが、ADL Gen2 をステージングアカウントとして使用した場合、コピーアクティビティが実行されるたびに、指定したステージングデータを格納するコンテナー内にファイルは存在しないのですが、GUID のディレクトリが残った状態となるという事象が発生します。
本事象ですが、ADL Gen2 をステージングアカウントととして指定した場合に必ず発生するわけではなく、コピー先によって発生有無が変わってくるようです。今回は、Fabric の Data Warehouse に対してデータのコピーを実施する際に発生しましたが、Synapse DWH でも発生するはずです。
この動作は現時点では想定された動作となり (SR で確認済み) 、ディレクトリの削除をパイプライン内で実行するためには本投稿のような対応を検討する必要がありますので、対応方法を残しておきたいと思います。