2025/01/12 時点の Azure Local 23H2 の SSH キーと kubeconfig の取得について情報をまとめておこうかと。
私の使用している環境 / 投稿時点の内容となるため、環境依存 / 今後変更される可能性があります。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
2025/01/12 時点の Azure Local 23H2 の SSH キーと kubeconfig の取得について情報をまとめておこうかと。
私の使用している環境 / 投稿時点の内容となるため、環境依存 / 今後変更される可能性があります。
SQL Server で取得されたロックの情報を確認する方法として lock_aquired / lock_released イベントを拡張イベントで取得する方法があります。
取得されているロックを確認する方法としては sys.dm_tran_locks を参照する方法もあります。
この DMV から情報を取得した場合は、次の画像のように、resource_description から、どのロックリソース (%%lockres%%) のキーに対してロックが取得されているのかを確認することができます。
しかし、DMV の参照はトレースとして情報を時系列で取得することは難しく、ロックのような短時間で取得される内容が細かに変わっていくような特性のある情報については DMV を連続でダンプしても解析することは難しいです。
本投稿を各モチベーションとなったのは「キーに対してどのような順序でロックが取得されているか」を確認したかったのですが、このような情報については DMV で取得することは難しく、拡張イベントのようなイベント駆動のトレースの情報を取得する必要があります。
しかし拡張イベントで「取得されるロック」の情報を確認した場合 、上述の DMV のような resource_description のような可視性の高い情報が無く、次の画像のように、「resource_x」「associated_object_id」を使用して、情報を確認する必要があります。
これらの情報を使用して「どのキーに対してロックが取得されたのか?」を確認する方法を考えてみました。
Azure Kubernetes Service (AKS) では、機密コンテナー (Confidential Container: CC) として、コンテナーを起動することができる機能が、2025/01 時点でプレビューとして提供されています。
AKS では 機密ノードプール という機能も提供されており、こちらについては既に GA しています。
機密ノードプール / 機密コンテナーともに AMD EPYC プロセッサが利用されており、AMD SEV-SNP (SEV: Secure Encrypted Virtualization / SNP: Secure Nested Paging) を使用し、高信頼実行環境 (TEE: Trusted Execution Environment) で VM を実行するものとなるかと思います。
機密ノードプールの場合は、DCasv5 シリーズ、機密コンテナーの場合は、DCas_cc_v5 シリーズが使用され、使用する VM サイズが異なっています。
DCasv5 シリーズはハードウェアベースの VM のメモリ暗号化が行われますが、DCas_cc_v5 シリーズでは「AMD SEV-SNP で保護された子 VM を作成できます。」という特徴があります。
AKS で使用する場合は、VM 上で動作するコンテナーを SEV-SNP で保護された子 VM として起動できる構成となるということになり、機密ノードプールを使用した場合とは異なる構成でコンテナーを起動することになるのかと思います。
機密ノードプール / 機密コンテナーは Azure Confidential Computing の VM (Confidential VM: CVM) が基盤となっていると思いますので、以下の記事も参考にさせていただいています。
ちょいちょい調べなおすのでメモを。
WSL を新規にインストールし、Azure CLI を実行したところ、「cli.azure.cli.core.azclierror: Operation returned an invalid status ‘Bad Request’」や他のエラーが発生し、実行することができないという事象が発生しました。
SQL Database で T-SQL で Vector データ型用の埋め込みを作成する際には、sp_invoke_external_rest_endpoint で Azure Open AI の 埋め込みのモデル を使用して、ベクトルデータを作成するという方法があります。
SQL Database の Vector データ型 の次元の最大数は「1998」となっており、これを変更することはできません。
Azure Open AI の埋め込みのモデルとしては、次のモデルを使用することができます。
ada / embedding-3-small であれば、1536 の次元となるため、Vector データ型にはそのまま登録することができるのですが、text-embedding-3-large については、単純に呼び出しただけでは 3072 の次元となるため、Vector データ型に登録することができません。
Azure Local 22H2 から 23H2 へのアップグレードについては、当初は Private Preview でしたが、現時点では一般公開されており次のドキュメントで情報が公開されています。
まだ、最後までアップグレードを完了できていないのですが、アップグレードを調査する中でいろいろと分かった内容がありますので、得られた知見を Tips その 1 としてまとめておきたいと思います。
生成 AI (Generative AI) を使用した SQL Server の最適化としては次のような機能があります。
これらの機能は DB から情報を直接取得して解析を行う方法となります。
SQL Server 以外の環境も含まれますが、これ以外の方法としては次のような記事の活用があります。
DBA に関しての作業についても今後は生成 AI を使用して、専門的なスキルが無くても一定のレベルで自動化 / 効率化を行う必要が出てくるのではないでしょうか。
スロークエリの原因を見つけて対処する方法の記事で、SQL Server ベースの環境のクエリチューニングについて触れられていますが、ChatGPT を使用して、実行プランをベースとして、どのようなプロンプトを記載すればクエリチューニングの一助となる提案を得ることができるかを自分なりに考えてみました。
Azure Local 22H2 から 23H2 へのアップグレードについて、Azure Arc ブログで Upgrade from Azure Stack HCI, version 22H2 to Azure Local という記事が公開されました。
検証のため Nested Hyper-V の環境で 22H2 からのアップグレードを試してみたのでその際のメモを。
2024/12/09 時点では、私の使用している環境ではソリューションアップグレードのインストールのロールアウトが行われていなかったため、最後までアップグレードを完了することはできませんでした。
.NET9 で Guid.CreateVersion7 がサポートされたことで、.NET から UUID v7 のフォーマットの GUID を作成することができるようになりました。
SQL Server ベースのデータベースエンジンで UUID v7 フォーマットの GUID を格納するとどのような格納となるのかをまとめておきたいと思います。
SQL Server の UUID v7 サポートについては、すでにフィードバックが Support UUID v7 でフィードバックが上がっていますので、v7 サポートについては、こちらのフィードバックへの Vote も検討いただければと思います。
なお、本投稿では「SQL Server にデータを格納した際の挙動」をメインテーマにしており、格納するためのデータプロバイダーの挙動については触れておりませんので、その点は留意してください。
のいえさんの CysharpのOSS Top10まとめ / Ulid vs .NET 9 UUID v7 / MagicOnion もとても参考になりますのでこちらも確認していただければ。(この話題から本投稿をまとめようと思ったので)