NOBTAの気ままにITブログ

2024-05-04T23:51:19+09:00

リモートワークの広がりに伴い、DaaS (Desktop as a Service) ソリューションの導入を検討されている方も多いのではないかと思います。

Azure、AWS、Google Cloud、OCI の各種クラウドサービスにおいても、

VMware サービス (VMware Horizon Cloud on Microsoft Azure, VMware Cloud on AWS, Google Cloud VMware Engine, Oracle Cloud VMware Solution)
Citrix サービス (Citrix Virtual Apps and Desktops for Azure, Citrix Virtual Apps and Desktops サービス on AWS)

などの DaaSを展開しています。

今回は、Azure で提供されている DaaS の一つである Azure Virtual Desktop (AVD) を構築する方法について、自分の整理も兼ねて、まとめてみようと思います。

【構築完成イメージ】

<構成>

Entra Connect による Active Directory - Entra ID 間の同期
Entra ID - Entra Domain Services 間の同期
Windows 10/11 マルチセッション
ユーザープロファイルの保管先は Azure ファイル共有 (FSLogix 利用)

※ 検証目的のため、Active Directory および Entra Connect サーバーを Azure 仮想マシン上に構築しています。

Azure Virtual Desktop (AVD) のメリット
Azure Virtual Desktop (AVD) 構築
まとめ

Azure Virtual Desktop (AVD) のメリット

Azure Virtual Desktop (AVD) とは、マイクロソフトが提供している仮想デスクトップ (VDI : Virtual Desktop Infrastructure) サービスであり、本サービスをクラウドで提供しているため、DaaS (Desktop as a Service) の一つとなります。

【メリット】

Windows 10/11 Enterprise マルチセッション機能
Windows 7 ESU（Extended Security Updates：拡張セキュリティ更新プログラム）の無償提供
Microsoft 365 E3/E5、Windows 10/11 Enterprise E3/E5 などのライセンスを保持している場合、すぐにAVDを使用可能
AVD上で動作する仮想マシンと Microsoft 365 はマイクロソフトのバックボーンネットワークで通信が行われるため、高速にアクセスが可能

※ 特に「Windows 10/11 Enterprise マルチセッション機能」は、DaaS の中で唯一、Azure Virtual Desktop ホストプール上に展開された Windows 10/11 (仮想マシン) を、複数ユーザーで共有することが可能となり、複数ユーザーで１台の仮想マシンを共有させることで、コンピュート費用を削減できるもようです。

また、 Citrix Virtual Apps and Desktops for Azure では、AVD ワークロードを制御する「AVD コントロールプレーン」機能を保有し、更に以下のメリットを享受することができるもようです。

【メリット (Citrix Virtual Apps and Desktops for Azure)】

Auto Scale 機能による適正仮想マシン起動数制御 (VMコスト軽減)
HDX（high definition experience）テクノロジーによる画面転送パフォーマンスの最適化 (アウトバウンドトラフィックの軽減)
完全な閉域接続の実現
※ AVDの場合、AVD コントロールプレーンとの通信でパブリックネットワークへの通信が必要となります。
ロケーションに応じた最適な接続
マスターイメージの更新機能

Azure Virtual Desktop (AVD) 構築

事前準備

Azure Virtual Desktop (AVD) を今回の構成で構築するために、以下を準備します。

Azure 無償／有償サブスクリプション

Azure サブスクリプションを保持していない場合は、以下の URL から Azure 無償サブスクリプションを発行します。

Microsoft 365 無償/有償サブスクリプション

本手順では「Microsoft 365 Business Premium」の試用版を使用します。

※「Microsoft 365 Business Premium」の試用版ライセンスの発行方法については、以下の URL を参照。

Microsoft Entra ID カスタムドメイン設定

Active Directory と Microsoft Entra ID (旧 Azure AD) 間を同期するため、今回は Active Directory (Azure 仮想マシン上にデプロイ) で構築したドメイン名と同じドメインを用意し、Microsoft Entra ID のカスタムドメインとして設定します。

独自ドメインは、「お名前.com」,「Freenom」などから取得できますが、今回は、Azure ポータル -「App Service ドメイン」から独自ドメインを取得することにします。

※ Microsoft Entra ID カスタムドメインの詳細な設定方法については、以下の URL を参照。

[補足]

「App Service ドメイン」以外から独自ドメインを取得した場合、Azure DNS でカスタムドメインをホストするために、ドメインレジストラー (ドメインの購入元) に対してドメインの委任作業を実施する必要があります。

※ 詳細なドメイン委任作業の設定方法については、以下の URL を参照。

構築

Entra Connect 同期設定

Entra Connect を使用することで、オンプレミス Active Directory と Entra ID 間でアカウントの同期をすることが可能となり、オンプレミス Active Directoryと同じアカウントを使用して、SaaS、PaaS、Azure Virtual Desktop (AVD) へアクセスすることができるようになります。

また、オンプレミス環境と Azure間を ExpressRoute, VPN などで結ぶことで、Entra Connect - Entra ID 間の同期処理をプライベート通信で実施することが可能になります。

※ 詳細な Entra Connect の設定手順については、以下 URL を参照。

Entra Domain Services 構築

Entra Domain Services (旧 Azure AD DS) では、Windows Server Active Directory と完全に互換性のあるマネージドドメインサービス (ドメイン参加、グループポリシー、LDAP、Kerberos 認証、NTLM 認証など) が提供されます。
今回は、Azure Virtual Desktop (AVD) のホストプールの仮想マシン (Windows 10/11) をドメインに参加させるために、Entra Domain Services を構築します。

※ 詳細な Azure AD DS の作成手順については、以下の URL を参照。

Azure Virtual Desktop (AVD) 用イメージの作成手順

※ AVD用イメージの詳細な作成方法については、以下の URL を参照。

Azure Virtual Desktop (AVD) ホストプール作成手順

[事前作業]

1) Azure Virtual Desktop (AVD) ホストプールの仮想マシンが Entra Domain Services (旧 Azure AD DS) のドメインに参加できるよう、AVD ホストプールの仮想マシンがデプロイされる仮想ネットワークの「DNS サーバー」設定を、Entra Domain Services で使用される IP アドレス (プライベート IP アドレス) に変更。

2) AVD ホストプールの仮想マシンがデプロイされる仮想ネットワークのサブネットから Entra Domain Services で使用されるサブネットに対してアクセスができるよう、ネットワークセキュリティグループ (NSG) などを適切に設定。

※ AVD ホストプールの仮想マシンがデプロイされる仮想ネットワークのサブネットに仮想マシンをデプロイし、Entra Domain Services のドメインに参加がすることができるか、事前に検証することをお勧めします。

※ 参考URL

[Azure Virtual Desktop ホストプール作成手順]

1) Azure ポータルに接続し、「Azure Virtual Desktop」を選択します。

2) 「概要」-「ホストプールの作成」を選択します。

3) 必要項目を入力後、「次へ : 仮想マシン」を選択します。

※ Azure Virtual Desktop ホストプールパラメータの詳細は、以下の URLを参照。

※ 2024年5月時点では、サービスメタデータについても「東倭国」を指定可能になっています。

4-1) 「仮想マシンの追加」:「はい」を選択し、「名前のプレフィック」などの必要項目を入力します。

※ 「名前のプレフィックス」に「avdhostje」と指定した場合、指定した「VM数」に応じて、ホストプール上に「avdhostje-0/avdhostje-1」といった仮想マシンが作成されます。

4-2) 「イメージの種類」:「ギャラリー」を選択し、「すべてのイメージを表示」から、「マイアイテム」-「マイイメージ」から、AVD用に作成した Windows 10/11 イメージを選択します。また、「VM 数」(ホストプール用に作成する VMの数) などの必要項目を入力します。

4-3) 「仮想ネットワーク」にドメインコントローラと通信可能な仮想ネットワークを指定後、「参加するディレクトリを選択する」：「Active Directory」、「AD ドメイン参加 UPN／パスワード」に、ドメインコントローラの管理者アカウントの資格情報、およびパスワードを入力後、「次へ:ワークスペース」を選択します。

※ 今回は、Entra Domain Services (旧 Azure AD DS) を使用するため、「参加するディレクトリを選択する」：「Active Directory」を選択し、「AD ドメイン参加 UPN／パスワード」に、Azure AD DC 管理者グループに属しているアカウント、およびパスワードを指定します。

※「参加するディレクトリを選択する」に「Azure Active Directory」を選択することも可能になっています。

5) 「デスクトップアプリグループの登録」:「はい」を選択し、「宛先のワークスペース」に任意の名前で登録後、「確認と作成」-「作成」を選択し、ホストプールを作成します。

[補足]

AVD用仮想マシンを Entra Domain Services ドメインに参加するフェーズ (joindomain) が失敗する場合は、「事前作業」で正しく設定できているかを確認すると良いかと思います。

デスクトップアプリケーショングループへ接続ユーザーの登録

Azure Virtual Desktop (AVD) 環境に接続するためには、デスクトップアプリケーショングループで接続を許可するユーザーを登録する必要があります。

以下に、デスクトップアプリケーショングループで接続を許可するユーザーを登録する方法を記載します。

1) Azure ポータルから「Azure Virtual Desktop」を選択後、「管理」:「アプリケーショングループ」より、作成されたアプリケーショングループを選択します。

2) 「管理」:「割り当て」-「+追加」を選択します。

3) Azure Virtual Desktop (AVD) 環境への接続を許可する「ユーザー／グループ」を選択し、「選択」を選択し、割り当てが完了したことを確認します。

Azure Virtual Desktop (AVD) 接続手順

Azure Virtual Desktop (AVD) 環境へ接続する方法として、大きく以下の２通りの方法があります。

Web クライアントからの接続
デスクトップクライアントからの接続

今回は、「Web クライアントからの接続」により、Azure Virtual Desktop (AVD) 環境へオンプレミスの環境から接続してみようと思います。

1) AVD Web クライアント「https://client.wvd.microsoft.com/arm/webclient/index.html」にアクセスし、ライセンスが付与され、接続が許可されている Entra ID アカウントでログインします。

2) 「SessionDesktop」を選択します。

3) 「ローカルリソースへアクセス」より許可するリソースを選択後、「許可」を選択します。

4) 「ローカルリソースへアクセス」より許可するリソースを選択後、「許可」を選択します。

5) AVD仮想マシンにログインできたことを確認します。

※ Entra Domain Services のグループポリシーを利用し、ポリシーを適用することも可能であるため、必要に応じて設定を実施されると良いかと思います。

[参考 URL]

セキュリティ設定

Azure Virtual Desktop (AVD) のセキュリティ設定

Azure Virtual Desktop (AVD) を既定の状態で利用した場合、ファイル転送ができたり、クリップボードの情報をリモートデスクトップ越しにコピーできたりと、セキュアな構成になっていません。

Azure Virtual Desktop (AVD) をよりセキュアに構成するため、「クリップボード」および「ファイル転送」などを禁止することもできます。

※「クリップボード」および「ファイル転送」などを禁止する詳細な手順については、以下の URL を参照。

まとめ

今回は、Azureで提供されている Azure Virtual Desktop (AVD) を構築し、Web クライアントを使用して、オンプレミス環境からAVD仮想マシンに接続する手順についてまとめてみました。

今後は、AVDのもう少し細かいパラメータなどについても確認していこうと思います。

※ 2024年5月更新

NOBTAの気ままにITブログ

2024-05-04T22:15:52+09:00

Microsoft Entra ID (以下 Entra ID) のテナントを新規作成した場合、"<ドメイン名>.onmicrosoft.com" という初期ドメイン名が付与されます。

初期ドメイン名を削除することはできませんが、任意のドメインをカスタムドメインとして Entra ID に登録することができます。

【ユースケース : 例】

企業で取得している任意のドメイン名でユーザーを管理したい。
Microsoft 365 (Teams, Exchange Online, SharePoint) で任意のドメイン名でアクセスさせたい。
オンプレミス上の Active Directory (以下 AD) と Entra ID 間を Microsoft Entra Connect (旧 Azure AD Connect) を使用して簡易に同期したい。
SAML認証により、他のSaaSサービスへの SSO (シングルサインオン) を実現したい。

Entra ID カスタムドメイン用ドメインの取得
Entra ID カスタムドメインの設定手順
まとめ

Entra ID カスタムドメイン用ドメインの取得

独自のドメインの取得は、「お名前.com」などから有償で購入したり、「Freenom」などのサイトから無償で取得することが可能です。

※ 基本的に企業で利用するドメイン (.com/.co.jp など) は有償での購入になるかと思います。

Entra ID、Azure 環境で利用する場合、「App Service ドメイン」からも独自のドメインを購入することができます。

今回は、「App Service ドメイン」から独自のドメインを取得する方法について紹介したいと思います。

【補足】

App Service ドメインで取得できるドメインは、com、net、co.uk、org、nl、in、biz、org.uk、co.in の何れかのみとなります。

1) Azure ポータルに接続し、「App Service ドメイン」を選択します。

2) 「+作成」を選択します。

3) 「ドメインの検索」に取得したいドメイン名を入力後、選択可能なドメイン名を選択し、「次: 連絡先情報」を選択します。

4) 「個人情報」、「電話番号と住所」などの必要事項を入力後、「確認および作成」を選択後、「作成」を選択します。

※ ドメイン取得後、自動的に DNS ゾーンが作成され、 Azure DNS でドメインの委任作業が自動的に完了します。

[補足]

「App Service ドメイン」以外からドメインを購入した場合、もしくは、既存のドメインを Entra ID のカスタムドメインとして使用するためには、ドメインの委任作業を実施する必要があります。

Entra ID カスタムドメインの設定手順

1) Microsoft Entra 管理センターにログインします。

Microsoft Entra admin center

2) ID - 設定 - ドメイン名を選択します。

3) 「+ カスタムドメインの追加」を選択します。

4) 取得した独自ドメインを「カスタムドメイン名」欄に入力後、「ドメインの追加」を選択します。

5) 「レコードの種類」：「TXT」、「宛先または参照先のアドレス」欄の値を控えます。

6) 「DNS ゾーン」を選択します。

※ Azure DNS を利用していない場合は、6) から 9) の手順をスキップし、独自ドメイン購入元のドメインレジストラーに TXT または MX レコードを作成し、5) で確認した情報を追加します。

7) 該当の DNS ゾーンを選択します。

8) 「+ レコードセット」を選択します。

9) 5) で確認した値を入力後、「OK」を選択します。

10) 再度、Microsoft Entra 管理センターに戻り、ID - 設定 - ドメイン名を選択します。

11) 「未確認」状態となっているドメイン名を選択します。

12) 「確認」を選択し、状態が「確認済み」に正しく変更されることを確認します。

13) 「プライマリにする」を選択し、追加したカスタムドメインをプライマリに変更します。

まとめ

今回、Azure ポータル -「App Service ドメイン」から取得した独自ドメインを Entra ID のカスタムドメインに設定する方法についてまとめてみました。

独自ドメインは、「お名前.com」,「Freenom」などからも安価／無料で取得 (.tk, .ml など) することが可能です。

企業で利用するドメインは、基本的に有償のドメインを取得することになるかと思いますが、Entra ID カスタムドメインの検証目的でドメインを取得したい場合には、無料のドメインを取得して利用しても良いのではないかと思います。

「App Service ドメイン」から独自ドメインを取得した場合、簡易に Entra ID カスタムドメイン設定が可能となりますが、"co.jp" などのドメインを取得できないため、「App Service ドメイン」で取得できないドメイン名を取得する必要がある場合は、別の方法でドメインを取得する必要がある点に注意が必要となります。

※ 2024年5月現在

NOBTAの気ままにITブログ

2024-04-24T01:45:52+09:00

前回、「Microsoft Fabric」の基本的な概念についてまとめてみました。

今回は、Microsoft Fabric を利用するうえで必要となるライセンスに関する内容を、自分の整理も兼ねて、まとめてみようと思います。

※ ライセンス購入前に、ライセンスに関する正確な内容については、ライセンス購買先ベンダー、Microsoft ライセンス窓口に確認ください。

Microsoft Fabric を利用するうえで必要となるライセンス
- 容量ライセンス
- ユーザー毎のライセンス
まとめ

Microsoft Fabric を利用するうえで必要となるライセンス

Microsoft Fabric を利用するためには、大きく2つのライセンスが必要になります。

容量ライセンス
ユーザー毎のライセンス

容量ライセンス

Stock Keeping Unit (SKU) 単位でサイズ (F2 ～ F2048) が指定されており、Microsoft Fabric ワークスペースに割り当てることで、リソースプール (Microsoft Fabric コンピューティングプール) を利用することが可能となります。

複数の Microsoft Fabric ワークスペースに1つの容量ライセンス (SKU) を割り当てることも、各ワークスペース単位で容量ライセンス (SKU) を割り当てることができます。

そのため、複数の容量ライセンスを所有することができます。

注意点として、SKUのサイズにより利用できない機能 (Microsoft Fabric Copilot 機能 : SKU F64 以上のみ利用可能) が存在するため、利用したい機能が選択した SKU のサイズで利用が可能となるか確認ください。

引用 : Microsoft Fabric の概念 - Microsoft Fabric | Microsoft Learn

また、Microsoft Fabric には 2種類の SKU が存在し、何れの SKU でも Microsoft Fabric を利用することができます。

Azure SKU
【特徴】
・従量課金制 (時間のコミットメント無し)
・Azure ポータルから容量をスケールアップ／ダウン可能
・課金は秒単位で行われ、最小課金時間は１分
Microsoft 365 SKU
【特徴】
・月単位、年単位の課金
・従量課金制よりも割安
※ 但し、各 Microsoft Fabricのワークロードはサーバーレスとして動作するため、24時間365日のほとんどの時間帯で稼働していない場合、従量課金制のほうが割安になる可能性がある。

ユーザー毎のライセンス

Microsoft Fabric を利用するユーザーが Microsoft Fabric ワークスペースで作業するために必要となるライセンス。

ユーザー毎に以下の何れかのライセンスが必要になります。

Power BI Pro
Premium Per User (PPU)

【補足】

Power BI Pro ライセンスは Microsoft 365 E5 ライセンスに含まれているため、既にライセンスを保持していないか、ライセンスを購入する前に確認したほうが良い。
Power BI Pro、Premium Per User (PPU) を保持しているユーザーのみ、Microsoft Fabric ワークスペースのコンテンツを共有することが可能。
Microsoft Fabric 無料ユーザーが共有された Microsoft Fabric ワークスペースのコンテンツを参照することは可能。但し、Microsoft Fabric 容量ライセンス (SKU F64 以上) が割り当てられた Microsoft Fabric ワークスペースに限定される。
※ つまり、Microsoft Fabric 容量ライセンス (SKU F64) 未満が割り当てられ、かつ、共有された Microsoft Fabric ワークスペースのコンテンツを参照するためには、参照側のユーザーにも Power BI Pro もしくは、Premium Per User (PPU) ライセンスが必要になる。

まとめ

今回は、Microsoft Fabric を利用するうえで必要となるライセンスに関する内容についてまとめてみました。

コストという意味では、今回紹介しました「容量ライセンス」、「ユーザー毎のライセンス」の他に、分析用のデータなどを保持するストレージ (One Lake) の費用 (従量課金 : 保存されたデータ量 x 保持期間 (時間) で算出) が必要になります。

なお、ライセンスの正確な内容については、ライセンスの購買元もしくは Microsoft ライセンス窓口になどに確認を実施してもらえればと思います。

※ 2024年4月時点

NOBTAの気ままにITブログ

2024-04-01T16:27:39+09:00

前回、「Microsoft Fabric」を利用するメリット (後編) として、Microsoft Fabric の更なるメリットについてまとめてみました。

今回は、Microsoft Fabric の基本概念について、自分の整理も兼ねて、まとめてみようと思います。

Microsoft Fabric 基本概念
まとめ

Microsoft Fabric 基本概念

テナント

Microsoft Fabric は Microsoft Entra ID テナント (旧 Azure AD) にデプロイされます。また、Microsoft Entra ID 上にはユーザー、グループなどのオブジェクトが存在し、Microsoft Fabric 管理ポータルへのログイン認証などで利用されます。

そして、Microsoft Entra ID には、特定の場所からのみアクセスを許可する条件付きアクセス機能、シングルサインオン、多要素認証(MFA)機能などの機能があり、簡易にセキュアな Microsoft Fabric 管理ポータルへのログインを実現することができます。

※ Microsoft Entra ID で条件付きアクセス機能、シングルサインオン、多要素認証(MFA)機能を利用する必要がある場合、ユーザー毎に Microsoft Entra ID P1 以上のライセンスを購入する必要があります。
※ Microsoft Entra ID P1/P2 ライセンスは、Microsoft 365 E3/E5 などのライセンスに含まれています。そのため、Microsoft Entra ID ライセンス購入前に、既に該当のライセンスを保有していないか確認することをお薦めします。

容量

Microsoft Fabric 容量はテナントに紐づいた、Microsoft Fabirc アイテムなどで使用可能なリソースプール (Microsoft Fabric コンピュートプール) となります。
容量のサイズ (SKU) により、使用可能な計算能力の量が決定されます。
一つの容量に複数のワークスペースを割り当てて使用することが可能となります。

ワークスペース

ワークスペースは、レイクハウス、ノートブック、セマンティックモデル、レポートなどの Microsoft Fabric アイテムを作成する場所になります。
ワークスペースおよび Microsoft Fabric アイテム毎にアクセス制御を設定することができます。
ワークスペース上の Microsoft Fabric アイテムは、該当ワークスペースに割り当てた「容量」のリソース (Microsoft Fabric コンピュートプール) を利用して実行されます。
ワークスペースには個人利用を目的とした「マイワークスペース」と、各ユーザーと共有可能な「ワークスペース」が存在します。

まとめ

今回は、Microsoft Fabric の基本概念について、まとめてみました。

Microsoft Fabric は Microsoft Entra ID を利用した認証が可能であり、Microsoft Entra IDの機能を利用することで、セキュアなMicrosoft Fabric 管理ポータルへのログインを簡易に実現することができるので、活用されると良いかと思います。

次回は、Microsoft Fabric を利用するうえで必要となるライセンスについて、まとめてみようと思います。

※ 2024年4月時点

NOBTAの気ままにITブログ

2024-03-29T15:41:54+09:00

前回、「Microsoft Fabric」を利用するメリット (前半) について、Microsoft Fabric のメリットについてまとめてみました。

今回は更なるメリットについて、まとめてみようと思います。

※ Microsoft Fabric に関するセミナーやエンジニアとの会話などで得た情報や実際に利用したみた経験をベースに、個人的にメリットと思われる点についてまとめています。

Microsoft Fabric メリット (後半)
Microsoft Fabric データ統合の全体像
まとめ

Microsoft Fabric メリット (後半)

Azure AI Studio, Azure OpenAI, Azure Databricks などのその他 Azureサービスから安全に OneLake 上のデータにアクセスすることが可能

DFS (分散ファイルシステム) API により、Azure Databricks, Azure Data Lake Storage Gen2 互換性アプリ (Azure HDInsight など) , Azure AI Studio から OneLake 上のデータにアクセスし、利用することが可能。
既存のデータ分析基盤も活用することが可能。
Azure AI Studio を利用し、Microsoft Fabric OneLake に保存されたデータを利用した AI アプリケーション開発が可能。

Microsoft Graph Data Connect により、Microsoft 365 のデータ (洞察データなど) を Dalta – Parquet 形式として OneLake に保存し、Microsoft Fabric に統合されたワークロードおよび、Azure Databricks、Azure Data Lake Storage Gen2 互換性アプリ (Azure HDInsight など) などの DFS (分散ファイルシステム) API からアクセス可能してデータ分析することが可能。

Copilot in Microsoft Fabric により各ワークロードの作業の効率化が可能 (コードの自動生成など)

現時点にてプレビュー機能となっているが、以下のワークロードで Copilot を利用することができ、データ分析作業の効率化を図ることが可能。

Copilot for Data Science and Data Engineering
Copilot for Data Factory
Copilot for Power BI
Copilot for Real-Time Analytics

【注意】

Microsoft Fabic で Copilot 機能を利用したい場合は、有償 (試用版では利用できない)、かつ、SKU で F64 もしくは P1 Capacity 以上を選択する必要があります。

OneLake を生成AI アプリケーションの RAG データソースとして利用可能

Microsoft Fabric OneLake にデータを統合することで、RAG アプリケーションから簡易に様々なデータに対してアクセスが可能。

Azure AI の各種サービス (Azure OpenAI、Text Analytics、Azure AI Translator など) の事前構築済み AI モデルを Microsoft Fabric 上 (Notebook など) で利用することが可能

事前構築済み AI モデルを Microsoft Fabric から簡易に利用することが可能。

Microsoft Fabric データ統合の全体像

Microsoft Fabric を中心としたデータ統合を実施することで、既存のデータおよび既存のデータ分析基盤を活用でき、かつ、効率的な AI 分析、RAG アプリケーションの開発ができるのも、Microsoft Fabric の魅力の一つかなと思います。

まとめ

今回は、「Microsoft Fabric」を利用するメリット (後半) について、まとめてみました。

Microsoft Fabric を中心としたデータ統合を実施することで、既存のデータおよび既存のデータ分析基盤を活用でき、かつ、効率的な AI 分析、RAG アプリケーションの開発ができ、かつ、ショートカット／ミラーリング機能を活用することでデータのサイロ化対策にも有効な良い SaaS サービスだと思います。

次回は、「Microsoft Fabric」を利用するうえの考慮点についてもまとめてみようと思います。

※ 2024年3月時点

NOBTAの気ままにITブログ

2024-03-29T12:03:00+09:00

前回、「Microsoft Fabric」の試用版 (60日間) を利用する方法についてまとめてみました。

今回は、「Microsoft Fabric」を利用するメリット (前半) について、まとめてみようと思います。

※ Microsoft Fabric に関するセミナーなどで得た情報や実際に利用したみた経験をベースに、個人的にメリットと思われる点についてまとめています。

Microsoft Fabric メリット (前半)
まとめ

Microsoft Fabric メリット (前半)

共通のインターフェースによるデータ分析が可能

データサイエンティスト、データアナリストなどの異なるロールのエンジニアが Microsoft Fabric 共通のインターフェース上でデータの取得、加工、分析、視覚化を実施することが可能。
異なるロールのエンジニア間で効率的にデータのやり取り、データ内容／分析に関する相談などを実施することが可能。

Microsoft Fabric に統合されたワークロードで Microsoft Fabric コンピューティングプールを共有して利用可能

Microsoft Fabric に統合された各ワークロードはサーバーレスで動作し、動作に必要なリソースは Microsoft Fabric コンピューティングプールから割り当てることが可能。(最小分単位の従量課金もしくはリソース予約)
Microsoft Fabric に統合された各ワークロード毎にコンピューティングリソースを購入する必要がないため、コストの最適化が可能。

OneLake によるデータの統合が可能

Microsoft Fabric OneLake は、OSS Delta Lake をベースにしており、OneLake上に配置されたデータは Delta-Parquet (デルタ - パーケイ) 形式という単一の共有フォーマットで保存される。
データが OneLake に保存されると、インポート／エクスポートをすることなく、Microsoft Fabric に統合されたワークロード、および、Azure Databricks、Azure Data Lake Storage Gen2 互換性アプリ (Azure HDInsight など) などからデータにアクセスすることが可能。

ミラーリング機能により Azure Cosmos DB, Azure SQL Database, Mongo DB, Snowflake からほぼリアルタイムで OneLake にデータを Dalta – Parquet 形式でデータ同期させることが可能。
※ 特に Snowflake がミラーリングのサポート対象になっている点が特徴的だと思います。
ミラーリングされた各データは同一データフォーマット (Dalta – Parquet 形式) で保存されるため、OneLake上にある既存のデータとを簡易に結合して分析、視覚化させることが可能。
※ 異なるデータソースのデータを分析のために簡易にデータ結合を伴うデータ分析が実施できるのは嬉しい点だと思います。
データサイエンティスト, データアナリストなどがほぼリアルタイムのデータを利用した分析が可能。
既存のデータを簡易に活用することが可能。

OneLake ショートカット機能によるデータアクセスが可能

OneLake ショートカット機能を利用することで、実データを OneLake にインポートする必要なく、Azure Data Lake Storage Gen2, Amazon S3, Dataverse, Google Storage に配置されたデータ(CSV, Parquet など) に直接アクセスすることが可能。
※ Google Storage へのショートカットについては、現時点 (2024年3月時点) でプレビュー機能。
既存のデータを簡易に活用することが可能。

まとめ

今回は、「Microsoft Fabric」を利用するメリット (前半) について、まとめてみました。

メリット (前半) だけでも、データのサイロ化を防ぎ、効率的なデータ分析、AI分析を実施するために Microsoft Fabric を利用するメリットがあると感じられた方はおられるのではないかと思います。

次回は、「Microsoft Fabric」を利用するメリット (後編) で更なる Microsoft Fabric を利用するメリットについてまとめてみようと思います。

【第4回】基本から始める Microsoft Fabric【メリット後半】へ

※ 2024年3月時点

NOBTAの気ままにITブログ

2024-03-26T18:27:15+09:00

Azure Marketplace から SQL Server がインストール済みの Azure 仮想マシン (以下 SQLVM) をデプロイした場合、英語版の SQL Server がインストールされます。

本環境の SQL Server を倭国語化したい場合、以下【SQLVM上の SQL Server 倭国語化手順】のような手順を実施する必要があります。

SQLVM上で倭国語化された SQL Server を上位バージョン (例えば SQL Server 2019 -> SQL Server 2022) にインプレースアップグレードしたい場合、どうすれば良いのかという質問をいただいたので、自分の整理も兼ねて、まとめてみようと思います。

【補足】

あくまで個人的な意見としては、SQL Server を上位バージョンにアップグレードする必要がある場合、インプレースアップグレードではなく、上位バージョンの SQL Server がインストールされた新しい SQLVM をデプロイし、既存SQLVMとの並行稼働＋データ同期を構成、そして、切り替えのタイミングでアプリケーション側の接続文字列を新しい SQLVMに接続するように変更したほうが、ダウンタイムが少ない、かつ、何か問題が発生した場合に即座に切り戻しができるなど、柔軟な移行計画を立てることができるのではないかと思います。

SQLVM上の SQL Server 倭国語化手順
SQLVM上の SQL Server インプレースアップグレード手順
まとめ

SQLVM上の SQL Server 倭国語化手順

SQLVM にインストールされている SQL Server および関連コンポーネットをすべてアンインストールします。
Windows OS のロケール設定を倭国語に変更します。
倭国語版の評価版 SQL Server (Evaluation Edition) をダウンロードし、SQLVM上の任意のパスに保存します。
SQLVM 上で「C:\SQLServerFull\x64\DefaultSetup.ini」をメモ帳などで開き、記載されている SQL Server のプロダクトキー(PID)を確認します。
倭国語版の評価版 SQL Server (Evaluation Edition)をインストール時、4. で確認したプロダクトキーを利用して SQL Server をインストールします。
SQL Server IaaS Agent 拡張機能の再登録を実施します。

詳細な手順は、以下の公開情報を参照。

SQLVM上の SQL Server インプレースアップグレード手順

【前提】　

SQLVM 上にインストールされている SQL Server 2019 を SQL Server 2022 にアップグレード
SQLVM 上にインストールされている SQL Server 2019 のエディションは Standard Edition

Azure Marketplace から上位バージョン (今回は SQL Server 2022 Standard Edition) がインストールされた SQLVM をデプロイします。
※ 既存SQLVM上にインストールされている SQL Server と同じエディションの上位バージョンを選択。
1. でデプロイした SQLVM 上で「C:\SQLServerFull\x64\DefaultSetup.ini」をメモ帳などで開き、記載されている SQL Server のプロダクトキー(PID)を確認します。
既存の SQLVM 環境上に倭国語版の評価版 SQL Server 2022 (Evaluation Edition) のセットアッププログラム (SQL2022-SSEI-Eval.exe) をダウンロードし、任意のパスに保存します。

SQL Server 2022 評価版 (Evaluation Edition)
3. でダウンロードした倭国語版の評価版 SQL Server 2022 (Evaluation Edition) のセットアッププログラム (SQL2022-SSEI-Eval.exe) を起動します。
インストールの種類「カスタム」を選択し、メディアのダウンロードパスを指定後、「インストール」を押下します。
「インストール」-「以前のバージョンの SQL Server からアップグレード」を選択します。
「プロダクトキーを入力する」を選択し、2. で確認したプロダクトキーを入力後、「SQL Server ライセンスのみを持っている」にチェックし、「次へ」を選択します。
「ライセンス条項と次に同意します」にチェックし、「次へ」を選択します。
アップグレード画面を進め、「インスタンスの選択」画面でアップグレードするインスタンスを選択し、「次へ」を選択します。
アップグレード画面を進め、「アップグレードの準備完了」画面で指定した内容が正しいことを確認後、「アップグレード」を選択し、SQL Server 2022 Standard Edition へのアップグレードを実行します。
正常にアップグレード作業が完了し、SQL Server のバージョンが上がっていることを確認します。

　　※ 1. で新規デプロイした SQLVM は必要に応じて削除します。

参考 URL

まとめ

SQLVM上で倭国語化された SQL Server を上位バージョンにインプレースアップグレードする方法についてまとめてみました。

上記でも記載しましたが、SQL Server を上位バージョンにアップグレードする必要がある場合、インプレースアップグレードではなく、上位バージョンの SQL Server がインストールされた新しい SQLVM をデプロイしデータベースを移行したほうが、ダウンタイムが少なく、安全に SQL Server のアップグレードを実施できるのではないかと思います。

※ 2024年3月時点

NOBTAの気ままにITブログ

2024-02-29T23:23:55+09:00

Azure Data Studio 1.48 がリリースされました。

新機能としては、以下の機能が追加されたようです。今回は各新機能について確認してみようと思います。

【Azure Data Studio 1.48 新機能】

リストアダイアログで Amazon S3 ストレージ URL 上に配置されたバックアップファイルからのデータベースリストアをサポート
クエリエディタタブに SPID (ユーザープロセスのセッション ID) を含めるように変更
コマンドラインから Azure Data Studio を起動する際、接続先を指定できるように変更
「データベースの作成」ダイアログからデータベースを作成する際、Ledger を有効できるように改良

リストアダイアログで Amazon S3 ストレージ URL 上に配置されたバックアップファイルからのデータベースリストアをサポート
クエリエディタタブに SPID (ユーザープロセスのセッション ID) を含めるように変更
コマンドラインから Azure Data Studio を起動する際、接続先を指定できるように変更
「データベースの作成」ダイアログからデータベースを作成する際、Ledger を有効できるように改良

リストアダイアログで Amazon S3 ストレージ URL 上に配置されたバックアップファイルからのデータベースリストアをサポート

1) Amazon S3 バケットに SQL Server データベースのバックアップファイル「testdb.bak」をアップロードします。

2) AWS 管理コンソール側で該当のAmazon S3 バケットに参照可能なアクセス権限が付与された IAM ユーザー (IAM グループ) を作成し、IAM ユーザーのアクセスキー、シークレットキーを取得します。

3) Azure Data Studio (1.48 以降) を起動後、データベース - 右クリック - データベースの復元 (プレビュー) を選択します。

※ 今回は、ローカル環境の SQL Server 2022 既定のインスタンスに接続しています。

4) 全般タブ - 復元元 -「S3 URL」を選択後、バックアップファイルのパス「…」を押下します。

5) バックアップファイルが保存された Amazon S3 バケットのエンドポイント、該当バケットにアクセス可能な IAM ユーザーの秘密鍵、アクセスキーを入力後、「資格情報の追加」を押下し、バックアップファイルが保存されたバケットを選択後、「追加」を押下します。

6) ターゲットデータベース欄にデータベース名を入力後、「復元」を押下します。

[補足]

倭国語訳が誤っていますが、ファイルタブ、オプションタブ (現在は「ファイル」となっている) は SQL Server Management Studio 同様に設定が可能になっているようです。

また、残念ながら本日時点 (2024/2/29) では、復元ボタンをクリック後、以下のエラーが発生し、データベースの復元作業が失敗してしまいました。

そのため、本日時点 (2024/2/29)で確認できた事象について、以下のフィードバックサイトにフィードバックを実施してみました。

https://github.com/microsoft/azuredatastudio/issues/25450

https://github.com/microsoft/azuredatastudio/issues/25451

クエリエディタタブに SPID (ユーザープロセスのセッション ID) を含めるように変更

クエリエディタタブに SPID (ユーザープロセスのセッション ID) が含まれるようになっています。

コマンドラインから Azure Data Studio を起動する際、接続先を指定できるように変更

コマンドラインのヘルプはまだ実装されていないようですが、Azure Data Studio の実行モジュール (azuredatastudio.exe) に「--command connect -- server <接続先SQL Server インスタンス>」引数を指定することで、Azure Data Studio の接続先を指定して Azure Data Studio を起動することができました。

※ 「--user <SQLログイン名> --command connect -- server <接続先SQL Server インスタンス>」と指定することで、SQL Server ログインを利用した接続も可能でした。

「データベースの作成」ダイアログからデータベースを作成する際、Ledger を有効できるように改良

Azure Data Studio からデータベースの新規作成を選択すると、「台帳データベース (Ledger)」を有効化するオプションが追加されています。

※ 2024年2月現在

NOBTAの気ままにITブログ

2024-02-28T13:37:55+09:00

前回、「Microsoft Fabric」の概要についてまとめてみました。

現在「Microsoft Fabric」は試用版 (60日間) として自由に動作検証などを実施することが可能になっています。

今回は、「Microsoft Fabric」を試用版として利用する方法について、まとめてみようと思います。

Microsoft Fabric 試用版を利用する前提条件
Microsoft Fabric 試用版を利用する方法
Microsoft Fabric を学ぶために参考になる Microsoft Learn
まとめ

Microsoft Fabric 試用版を利用する前提条件

Power BI ライセンス (無料版でもOK)

※ 「Microsoft Fabric 試用版を利用する方法」では、Power BI ライセンス (無償版) をセットアップする手順を含めています。

Microsoft Fabric 試用版を利用する方法

1) 以下の URL にアクセスします。

https://app.fabric.microsoft.com/home?experience=fabric

2) 試用版を利用したいアカウント (組織アカウント) を入力し、「次へ」を押下します。

※ 組織アカウントの作成方法については、以下の Microsoft サポートブログが参考になるかと思います。

jpazasms.github.io

3) アカウント作成に紐づける予定のメールアドレスが正しいことを確認後、「続ける」を押下します。

4)「国または地域」欄、「勤務先の電話番号」欄を入力後、「作業の開始」を押下します。

5)「作業の開始」を押下します。

6) Microsoft Fabric 管理ポータルが表示されたことを確認します。

6) Microsoft Fabric 管理ポータル右上の「アカウント」- 左クリック -「無料体験する」を押下します。

7) 「無料体験する」を押下します。

8) 「了解しました」を押下します。

Microsoft Fabric を学ぶために参考になる Microsoft Learn

Microsoft Fabric に対応した試験「DP-600 : Microsoft Fabric を使用した分析ソリューションの実装」のコレクションに登録された Microsoft Learn を学ぶことで、Microsoft Fabric を深く知ることができると思いますのでお勧めです。

learn.microsoft.com

まとめ

今回は、Microsoft Fabric を試用版として利用する方法および Microsoft Fabric を学ぶうえで参考になりそうな Microsoft Learn コンテンツを紹介しました。

次回以降で、Microsoft Fabric のメリット、OneLake についてもう少し詳しく整理してみようと思います。

【第3回】基本から始める Microsoft Fabric【メリット前半】へ

※ 2024年2月時点

NOBTAの気ままにITブログ

2024-02-26T23:50:16+09:00

Azure 分析基盤サービスとして以下のような様々なサービスが存在します。

Microsoft Fabric
Azure Databricks
Azure Synapse Analytics
HDInsight
Azure Stream Analytics
Azure Data Lake Analytics

今回は、その中の一つである「Microsoft Fabric」について、自分の整理も兼ねてまとめてみようと思います。

Microsoft Fabric とは
統合された各ワークロードについて
Microsoft Fabric メリット
まとめ

Microsoft Fabric とは

Microsoft Fabric は、データ活用、分析に必要となる複数のワークロードを一つにまとめた 統合データプラットフォーム (SaaS) となります。

統合された各ワークロードについて

Microsoft Fabric では、現時点(2024年2月時点)において、7個のワークロードが統合されています。

Microsoft Fabric メリット

Microsoft Fabric は以下の点でメリットがあるのではないかと思います。

共通のインターフェースによるデータ分析が可能
・データエンジニア、データサイエンティスト、データアナリスト、データスチュワードなどの異なるロールのエンジニアが共通のインターフェーズ上でデータの取得、加工、分析、視覚化を実施することが可能となり、効率的に各エンジニア間のやり取りを進めることが可能。
各ワークロードで Microsoft Fabric のコンピューティングプールを共有して利用が可能 (最小分単位の従量課金もしくは予約)
OneLake によるデータ統合が可能
・統合されたすべてのワークロードは、OneLake 上に配置されたデータを共有して利用可能。
・Microsoft 365 とも統合されており、Microsoft 365 上のデータ (洞察データなど) をシームレスに取得可能。
・ミラーリング機能により、Azure CosmosDB、Azure SQL Database、Mongo DB、Snowflake などのデータを OneLake 上に複製および自動同期させることで、ほぼリアルタイムのデータを分析可能。
OneLake ショートカット機能によるデータアクセスが可能
・Azure Data Lake Storage Gen2、Dataverse、Amazon S3、Google Storage 上のファイルを OneLake にコピーすることなくアクセスして利用することが可能。
Azure AI Studio、Azure OpenAI、Azure Databricks などのその他 Azure サービスから安全に OneLake 上のデータにアクセスすることが可能。
Copilot in Microsoft Fabric により各ワークロードの作業の効率化が可能 (コードの自動生成など)
OneLake を生成AI アプリケーションの RAG データソースとして利用可能。
Azure AI の各種サービス (Azure OpenAI、Text Analytics、Azure AI Translator など) の事前構築済みの AI モデルを Microsoft Fabric 上 (Notebook など) で利用することが可能。

まとめ

今回は、Microsoft Fabric の概要についてまとめてみました。Microsoft Fabric の OneLake にデータを統合することで、効率的なデータの取得、加工、分析、可視化が可能となったり、異なるロールを持つエンジニア間の連携がスムーズになったり、Azure AI (Azure OpenAI 含む)、Microsoft 365 と密に統合されているため、統合したデータの AI 分析などが簡易に実現できる点などの様々なメリットがあるのではないかと思います。

また、各ワークロードで利用されるコンピューティングリソースについても、Microsoft Fabric でプールされているリソースを共有して利用でき、かつ、最小分単位の従量課金で利用できる点も良い点だと思います。

次回以降で、OneLake についてもう少し詳しく整理してみようと思います。

【第2回】基本から始める Microsoft Fabric【試用版申し込み】へ

qtwy.bokepmobile.site

※ 2024年2月時点

NOBTAの気ままにITブログ

2024-01-03T01:03:59+09:00

Azure 分析基盤サービスとして以下のような様々なサービスが存在します。

Azure Databricks
Microsoft Fabric
Azure Synapse Analytics
HDInsight
Azure Stream Analytics
Azure Data Lake Analytics

今回は、その中の一つである「Azure Databricks」について、自分の整理も兼ねてまとめてみようと思います。

Azure Databricks とは
Azure Databricks の特徴
Azure Databricks のアーキテクチャ
- Azure Databricks コントロールプレーン
- Azure Databricks コンピューティングプレーン
まとめ
参考URL

Azure Databricks とは

Databricks はデータの取り込み (ETL)、分析、AI (生成AI)、機械学習 (Machine Learning)、BI (Business Intelligence) 、データガバナンスなどの機能が統合された分析基盤サービス (レイクハウスプラットホーム) になります。

そして、Azure Databricks は、Azure 基盤に最適化され、Azure サービスと簡易に連携可能なフルマネージドの Databricks サービスとなります。

Azure Databricks の特徴

データ分析に必要となる機能 (ETL、AI、DWH、ML、BI、データガバナンスなど)が一つの共通プラットホームに統合され、構造化、半構造化、非構造化、ストリーミングデータの分析が可能
OSS (Apache Spark, DELTA LAKE, Koalas, Redash など) 製品を SaaS としてラッピングすることで簡易に利用することが可能
※ Apache Spark についてはパフォーマンスチューニングが施されている。
データエンジニア、データアナリスト、データサイエンティストなどの異なる役割をもったチーム間で共同で作業が可能

Azure Databricks のアーキテクチャ

参考URL : Azure Databricks アーキテクチャの概要 - Azure Databricks | Microsoft Learn

Azure Databricks コントロールプレーン

Azure Databricks サービス Web アプリケーション、ノートブック、ジョブスケジュールのメタデータ、クラスタのメタデータを保持している。

Azure Databricks コンピューティングプレーン

Apache Spark、ノートブック、ジョブなどを実行するためのコンピューティングリソース、ストレージを保持している。

※ 但し、Databricks SQL サーバーレスなどについては、Azure Databricks コントロールプレーン側のコンピューティングリソースが使用されるようです。

Azure Databricks ワークスペースを独自のAzure 仮想ネットワークにデプロイすると、該当のAzure 仮想ネットワーク内に Azure Databricks ワークスペースがデプロイされます。

まとめ

今回は、「Azure Databricks」の簡易的なアーキテクチャについてまとめてみました。

「Azure Databricks」では、パフォーマンスチューニングされた Apache Spark を利用できたり、データ分析に必要となる機能 (ETL、AI、DWH、ML、BI、データガバナンスなど)が一つの共通プラットホームに統合され、構造化、半構造化、非構造化、ストリーミングデータの分析が可能なサービスとなっています。

また、OSS がベースになっているため、移植性 (ポータビリティ) という意味でも優位性があり、更にAzure 関連サービスとの柔軟な連携が可能となっている点に優位性があるのではないかと思います。

参考URL

※ 2024年1月時点

NOBTAの気ままにITブログ

2024-01-01T19:26:37+09:00

Ignite 2023 では、生成AI (LLM) , Copilot などの AI サービスで盛り上がりましたが、データプラットホーム (Data Platform) 分野でも新機能が発表されました。

今回は Azure Database for PostgreSQL の新機能について、自身の整理も兼ねてまとめてみようと思います。

Azure Database for PostgreSQL とは
Azure Database for PostgreSQL 新機能 (Ignite 2023)
まとめ

Azure Database for PostgreSQL とは

Azure Database for PostgreSQL は、オープンソースリレーショナルデータベースである PostgreSQL をベースとしたクラウドフルマネージドのリレーショナルデータベースサービスです。

Azure Database for PostgreSQL - フレキシブルサーバー (Linux 基盤) では、PostgreSQL 12以上のバージョンを利用かつ、可用性ゾーンにまたがる高可用性を構成することが可能です。また、サーバーを停止／起動する機能によるコストの最適化も実施することができるため、新たに Azure Database for PostgreSQL をデプロイする場合は、高可用性を構成しない場合においても、基本的には Azure Database for PostgreSQL - フレキシブルをデプロイすることになるかと思います。

Azure Database for PostgreSQL 新機能 (Ignite 2023)

Premium SSD v2 P80 (プレビュー)

ミリ秒以下のディスクレイテンシーかつ、IO集約型ワークロード向けに P80 (20,000 IOPS) がプレビュー機能として選択が可能となりました。

現時点 (2024年1月) の制約としては、以下の機能が利用できないようです。

ストレージの自動拡張機能が利用できない。
高可用性が利用できない。

そのため、現時点のユースケースとしては、データ移行などの一時的な処理時間の短縮などの利用が最適のようです。

Azure AI 拡張機能 (プレビュー)

本機能はプレビュー機能 (2024年1月時点) となりますが、Azure AI 用 Azure Database for PostgreSQL 拡張機能を有効化することで、データベース内で Azure OpenAI や Azure Cognitive Services などのサービスを読み出すことができるようになりました。

例えば、効率的な類似性検索を可能とする LLM ベースのベクトル埋め込みを生成したり、Azure AI Language を利用したセンチメント分析、言語検出、エンティティ認識などを利用することができるようです。

pgvector 0.5.1 サポート (GA)

最新のオープンソースバージョンの「pgvector」が Azure Database for PostgreSQL - フレキシブルサーバーで GA となったようです。

Near Zero ダウンタイムスケーリング (GA)

Azure Database for PostgreSQL - フレキシブルサーバーで、コンピュートやストレージのサイズを変更の際に、アプリケーションからのダウンタイムを30秒未満にするという機能が GA となったようです。

今までは 2～10分程度、スケーリングに時間を要していたので、可用性が大幅に向上する機能だと思います。

pg_azure_storage (プレビュー) および tds_fdw (GA) 拡張機能

Azure クラウドストレージとPostgreSQL間のデータのロード／エクスポートを簡素化するための拡張機能「pg_azure_storage」がプレビューとして、および、Microsoft SQL Server に保存されたデータをクエリするための外部データラッパーを利用可能とする拡張機能「tds_fdw」が GA となったようです。

まとめ

今回は Microsoft Ignite 2023 で発表された Azure Database for PostgreSQL の新機能についてまとめてみました。

AI サービスとの連携であったり、拡張機能の拡充、パフォーマンスの改善など様々なアップデートがあり、ますます便利になってきましたね。

オンプレミス PostgreSQL (Linux) の移行先としても、Azure Database for PostgreSQL は最適な移行先の一つになるかと思いますので、移行先として検討していきたいと思います。

※ 2024年1月時点

NOBTAの気ままにITブログ

2023-12-16T16:11:26+09:00

Ignite 2023 では、生成AI (LLM) , Copilot などの AI サービスで盛り上がりましたが、データプラットホーム (Data Platform) 分野でも新機能が発表されました。

今回は Azure Cosmos DB の新機能について、自身の整理も兼ねてまとめてみようと思います。

Azure Cosmos DB とは
Azure Cosmos DB 新機能 (Ignite 2023)
まとめ

Azure Cosmos DB とは

Azure Cosmos DB は、リレーショナル (PostgreSQL)、ドキュメント (MongoDB)、ベクトル (NoSQL/MongoDB/PostgreSQL)、キーバリュー (NoSQL/Cassandra )、グラフ (Gremlin)、テーブル (Table) を含む、すべてのオペレーショナルデータモデルに対応したフルマネージドのデータベースサービスです。

AI、IoT、予約管理などのクラウドネイティブなアプリケーションに最適なデータベースサービスとなります。

Azure Cosmos DB 新機能 (Ignite 2023)

リージョンごとおよびパーティションごとの自動スケーリング (プレビュー)

本機能はプレビュー機能 (2023年12月時点) となりますが、最も処理量が多いリージョンやパーティションに基づいて、自動的にワークロードをスケーリングする機能が登場しました。

この機能は、リージョン間やパーティション間でワークロードに大きな差異がある場合、例えば、ホットパーティションが頻繁に発生したり、特定のリージョンのみワークロードが高い状況が頻繁に発生する場合、特にコスト削減の効果があるようです。

現時点においてプレビュー機能であるため、本機能を利用するためには、Azure 管理ポータル - 該当 Azure Cosmos DB アカウント - 設定 - 機能より、「per Region and Per Partition Autoscale (preview)」を有効化する必要があります。

Microsoft Copilot for Azure機能 in Azure Cosmos DB (プレビュー)

本機能はプレビュー機能 (2023年12月時点) となりますが、Microsoft Copilot for Azure 機能を利用した Azure Cosmos DB のクエリ自動生成機能 が登場しました。

現時点において (2023年12月時点)、言語は英語のみがサポートされているようです。

「Show me all the name starting with DATA」という要求したところ、「SELECT c.name FROM c WHERE STARTSWITH(c.name, 'DATA')」というクエリが自動生成されました。AIを組み合わせることで開発効率が向上しますね。

本機能を利用する簡易手順を以下に記載します。

1) Azure 管理ポータル - サブスクリプション - 該当サブスクリプション - 設定 -「プレビュー機能」を選択後、「Microsoft Copilot for Azure in Cosmos DB」を選択し、「+ 登録」を押下します。

2) Azure 管理ポータル - Azure Cosmos DB - 該当アカウント -「データエクスプローラ」を選択し、「Query faster with Copilot」を選択します。

3) Copilot 欄に要求 (今回は「Show me all the name starting with DATA」) を記載して実行ボタンを押下します。

4) クエリが自動生成されたことを確認します。

Azure Cosmos DB for MongoDB 仮想コアベクトル検索

Azure Cosmos DB for MongoDB 仮想コアで、ベクトル検索のために別製品(サービス)にデータを転送することなく、高次元のベクトルデータの効率的な保存、インデックス付け、および、クエリを実行することができるようになりました。

但し、現時点 (2023年12月) において、Azure Cosmos DB for MongoDB 仮想コア (vCore cluster) のデプロイが可能なリージョンは限定されており、Japan East/West リージョンではデプロイすることは出来ません。

ベクター検索とは

プロパティフィールドの完全一致による検索ではなく、データ特性に基づいて類似の項目を検索することに便利な検索になります。

ユースケースとしては、類似したテキストの検索、お勧め候補の作成、異常検出などのアプリケーションで利用されることが多い検索になります。

MongoDBとは

NoSQLの中でも「ドキュメント指向データベース」という位置づけのデータベースとなり、JSON形式などの階層構造をもったデータをそのまま格納することが可能なデータベースになります。

まとめ

今回は Microsoft Ignite 2023 で発表された Azure Cosmos DB の新機能についてまとめてみました。

「Microsoft Copilot for Azure 機能を利用した Azure Cosmos DB のクエリ自動生成機能」や、「Azure Cosmos DB for MongoDB 仮想コアベクトル検索」など、続々と便利な機能が公開されています。アプリケーションに最適なデータストアを判断する材料として、Azure Cosmos DB を検証してみると良いかと思います。

※ 2023年12月時点

NOBTAの気ままにITブログ

2023-12-12T00:08:17+09:00

Ignite 2023 では、生成AI (LLM) , Copilot などの AI サービスで盛り上がりましたが、データプラットホーム (Data Platform) 分野でも新機能が発表されました。

今回は Azure SQL Managed Instance の新機能について、自身の整理も兼ねてまとめてみようと思います。

Azure SQL Managed Instance とは
Azure SQL Managed Instance 新機能 (Ignite 2023)
まとめ
参考URL

Azure SQL Managed Instance とは

Azure SQL Managed Instance は、オンプレミス SQL Server Enterprise Edition エンジンとほぼ100%に近い互換性をもつクラウドデータベースサービス (PaaS)であり、CLR統合機能(CLR関数)などの特殊な機能を使用している場合、オンプレミス SQL Server データベースを可能な限り手間を掛けずに Azure 上に移行したい場合に最適です。

オンプレミス SQL Server の完全バックアップからデータ移行したり、Azure Data Migration Service や Managed Instance リンクなどを利用することで、ダウンタイム無しにデータ移行を実現することも可能です。

Azure SQL Managed Instance 新機能 (Ignite 2023)

Azure SQL Managed Instance 無償トライアル

近日中、Azure SQL Managed Instance を Poc (概念実装) やアプリケーションテスト目的として、以下の範囲で 12ヶ月間無償で利用可能になることが発表されました。

【無料トライアルリソース】

仮想コア : 4 仮想コアもしくは 8 仮想コア (720 仮想コア時間/月まで)
データストレージ : 64 GB
バックアップストレージ : 64 GB

Azure SQL Managed Instance 開始／停止

Azure SQL Managed Instance の仮想コア利用料、SQL Server ライセンス利用料を節約するため、Azure SQL Managed Instance を自由に開始／停止できるようになりました。

Azure 管理ポータルや Azure CLI/PowerShell から簡単に Azure SQL Managed Instance の開始／停止を実施することが出来るようになっています。

※ 開始には 20分程度の時間を要する点には注意が必要そうです。

Azure SQL Managed Instance 高速デプロイ機能 (30分以内)

現時点においては、以下の制約がありますが、Azure SQL Managed Instance のデプロイが 30分以内に完了するという機能です。

今までは、初回仮想ネットワークの新しいサブネット上で Azure SQL Managed Instance デプロイ時、デプロイ完了までに 6時間程度の時間を要していたので、DR戦略としてバックアップ／リストア手法を選択することが難しかったのですが、今後はより柔軟なDR戦略を立てることができるのではないかと思います。

【制約】(2023/12月時点)

仮想コア : 4 仮想コアもしくは 8 仮想コア
サービスレベル : General Purpose
メンテナンス期間 : 既定のまま

Azure SQL Managed Instance ゾーン冗長機能

Azure SQL Managed Instance Business Critical でゾーン冗長が GA となり、General Purpose では本機能がパブリックプレビューとなったようです。

ゾーン冗長を構成することで、ゾーン障害 (Azure 東倭国リージョンでは 3つの可用性ゾーンが存在) が発生したとしても DR が発動することなく、同一リージョン内でデータベースサービスを継続できるなど、高可用性が求められる求められるシステムで採用しやすくなったと思います。

Azure SQL Managed Instance 分散トランザクション機能

Azure SQL Managed Instance で分散トランザクション(DTC : Distributed Transaction Coordinator) 機能が GA となったようです。

オンプレミスの SQL Server では MS DTC を利用した分散トランザクションを実装したアプリケーションを利用していた方もおられると思いますが、Azure SQL Managed Instance においても ODBC/JDBC ドライブの XA トランザクション、T-SQL や .NET ベースの分散トランザクションのすべてをサポートするようです。

分散トランザクションを利用したアプリケーションが動作する環境においても、Azure上の仮想マシンに SQL Server をインストールしなくても、クラウドデータベースサービス (PaaS) へ移行が可能となるため、より柔軟な Azure 移行が実現できるようになったと思います。

まとめ

今回は Azure SQL Managed Instance の新機能についてまとめてみました。Azure SQL Managed Instance は数年前と比べて、かなり利用しやすくなったと思います。

オンプレミス環境で SQL Server を利用しており、クラウドへ移行することを検討されている場合は、選択肢の一つとして Azure SQL Managed Instance を検討してみると良いかと思います。

参考URL

※ 2023年12月時点

NOBTAの気ままにITブログ

2023-11-30T15:52:25+09:00

プレビュー機能として Azure SQL Database 無料プランが登場しました。

Azure SQL Database を利用した PoC (概念実証) やアプリケーション開発が必要な人向けに設定されているとのことです。

今回は Azure SQL Database 無料プランで Azure SQL Database をデプロイする方法について、自身の整理も兼ねてまとめてみようと思います。

Azure SQL Database 無料プランについて
Azure SQL Database 無料プランでデータベース作成
まとめ
参考情報

Azure SQL Database 無料プランについて

Azure SQL Database 無料プランは、フルマネージド PaaS データベースエンジンである Azure SQL Database を毎月、無料プランの枠内で利用可能となるプランです。

つまり、1ヶ月の無料枠を使っても、次の月にはクリアされるため、毎月無料枠の範囲で Azure SQL Database が永続的に利用可能になります。

無料枠の内容、無料プランのオプションなどをまとめてみます。

無料プラン枠

Azure SQL Database General Purpose サーバーレス
100,000 仮想コア秒/毎月
最小仮想コア数 : 0.5、最大仮想コア数 : 4
最小メモリ : 2.1 GB、最大メモリ : 12 GB
最大データベースサイズ : 32 GB
ゾーン冗長機能 : 無
バックアップストレージ : ローカル冗長バックアップ
ポイントインタイムリストア (PITR) : 7日間
エラスティックプール : 利用不可
自動フェイルオーバーグループ機能 : 利用不可
Azure サブスクリプションに 1個のみデプロイ可能

※ 毎月 100,000 仮想コア秒の制限があるため、仮想コア数が高くなる処理を実施すると仮想コア秒が多く消費され、100,000 仮想コア秒の制限に早く到達することになります。

無料プランオプション

Azure SQL Database 無料プランでは2つのオプションを選択することができます。

無料枠到達時「来月までデータベースを自動一時停止する」
　無料枠到達後は来月までデータベースが利用できなくなります。
無料枠到達時「追加料金でデータベースの使用を続行する」
　無料枠到達後も追加料金が発生するがデータベースを利用することが可能になります。
※ 現時点において、一度「追加料金でデータベースの使用を続行する」を選択すると、「来月までデータベースを自動一時停止する」に戻すことが出来なくなる点に注意が必要です。

仮想コア秒の算出方法

仮想コア秒計算式 : (最小仮想コア数、使用された仮想コア数、最小メモリ GB * 1/3、使用されたメモリ GB * 1/3) の内、最も最大となる値 * 稼働時間

[例] 0:00-1:00 (1h) の Azure SQL Database サーバーレス稼働状況が以下の場合

最小仮想コア : 1

最大仮想コア : 4

最小メモリ : 2.1 GB

最大メモリ : 12 GB

使用された仮想コア数(1秒あたりの平均) : 3

使用されたメモリ(1秒あたりの平均) : 6 GB

仮想コア秒計算式 : (最小仮想コア数: 1, 使用された仮想コア数: 3, 最小メモリ*1/3: 0.7, 使用されたメモリ*1/3; 2) * 1時間 (3600秒)

※ 使用された仮想コア数: 3 が最も大きな値となるため、3 * 3600 = 10,800 と、本例の場合の 仮想コア秒は 10,800 秒となる。

仮想コア秒の使用量確認方法

Azure 管理ポータル - SQL データベース - 該当データベース - 監視 - メトリックで以下のメトリックを確認することで、無料枠の仮想コア秒の残り時間を確認することができます。

メトリック : Free amount remaining
集計 : 最小値

Azure SQL Database 無料プランでデータベース作成

1) Azure ポータル - SQL Server -「+ データベースの作成」を選択します。

2) Azure SQL Database 無料プランを利用するため、「Apply offer (Preview)」をまず初めに押下します。

3) 「Free database offer applied!」と無料プランが有効になったことを確認後、任意のデータベース名を入力後、「データベースの構成」を押下します。

4) 必要項目を入力後、「適用」を押下します。

Free database offer (Preview) : Applied
Behavior when free offer limit reached : 「来月までデータベースを自動一時停止する : Auto-pause the database until next month」or 「追加料金でデータベースの使用を続行する : Continue using database for additional charges」
※ 本例では「来月までデータベースを自動一時停止する : Auto-pause the database until next month」を選択します。
最大仮想コア数 : 1 - 4
最小仮想コア数 : 0.5 仮想コア (固定)

　※ 最小メモリ、最大メモリは、最大仮想コア数により自動的に増減します。(最大 12GB)

5) 「確認および作成」を押下後、作成するデータベース情報が正しいことを確認し、「作成」を押下して Azure SQL Database 無料プランデータベースをデプロイします。

6) Azure Data Studio などからデプロイした Azure SQL Database 無料プランデータベースにアクセスし、クエリ動作などを行えることを確認します。

まとめ

今回は Azure SQL Database 無料プランで Azure SQL Database をデプロイする方法について、まとめてみました。

無料枠という制限はありますが、Azure SQL Database を毎月、無料プランの枠内で利用可能となるのは嬉しいですね。

Azure SQL Database は、Azure PaaS データベースエンジンの中では最も機能が充実しているため、この機会に利用してみても良いかもしれません。

参考情報

※ 2023年11月現在

NOBTAの気ままにITブログ

2023-11-26T15:02:39+09:00

Azure 東倭国リージョンにデプロイした Azure Linux 仮想マシンをDR (ディザスタリカバリ) 目的などで別リージョンに複製(コピー) したいことがあるのではないかと思います。

今回は、Azure Linux 仮想マシンを複製して別リージョンでデプロイする方法について、自分の整理も兼ねてまとめてみようと思います。

【前提条件】

Azure Linux 仮想マシンがデプロイされている。
Microsoft Azure Storage Explorer がインストールされた環境より、複製元、複製先の Azure サブスクリプション (Azure Storage アカウント) へアクセスが可能となっている。

Azure Linux 仮想マシンの複製
まとめ

Azure Linux 仮想マシンの複製

Azure Linux 仮想マシン OS ディスクのスナップショット作成

1) Azure 管理ポータルから複製する Azure Linux 仮想マシンを停止し、状態が「停止済み (割り当て解除)」になっていることを確認します。

2) 設定 - ディスクを選択後、OS ディスク - 該当のOS ディスク (本例では「ubje001_OsDisk_1_****」) を選択します。

3) 「+ スナップショットの作成」を選択します。

4) 必要項目を入力後、「確認および作成」ボタンを押下し、スナップショットを作成します。

名前 : 任意のスナップショット名

スナップショットの種類 : フル

ストレージの種類 : 任意

スナップショットからの Azure Linux OS ディスクの作成

1) Azure 管理ポータルから「スナップショット」で検索を実施し、「スナップショット」サービスを選択します。

2) 新規マネージドディスク(Azure Linux OS ディスク) のベースとなるスナップショットを選択します。

※ 本手順では「ubje001-OsDisk-snap01」を選択します。

3) 「+ ディスクの作成」を選択します。

4) 必要項目を入力後、「確認および作成」ボタンを押下し、新規マネージドディスク(Azure Linux OS ディスク) を作成します。

名前 : 任意のマネージドディスク名

可用性ゾーン : 任意

5) 正常に新規マネージドディスク(Azure Linux OS ディスク) が作成されたことを確認します。

Azure 仮想マシン OS ディスクのリージョン間コピー

Azure 仮想マシン OS ディスクのリージョン間コピーを実施する方法として、「Azure CLI」を利用する方法、「Microsoft Azure Storage Explorer」を利用する方法などの複数の方法がありますが、今回は最も簡易的にコピーを実施することが可能となる「Microsoft Azure Storage Explorer」を利用したいと思います。

※ 詳細な手順については、以下「Azure 仮想マシン OS ディスクを別リージョンにコピーする方法について」を参照。

別リージョン上にコピーした Azure 仮想マシン OS ディスクから Azure 仮想マシンをデプロイ

1) Azure 管理ポータル - ディスクから別リージョンからコピーしてきた Azure 仮想マシン OS ディスクを選択します。

2) 概要 -「+ VM の作成」を選択します。

3) 必要項目を入力後、「確認および作成」を選択し、Azure Linux 仮想マシンのデプロイ作業を実施します。

仮想マシン名 : 任意のホスト名
※ 但し、Azure Linux 仮想マシン OS 上のホスト名は「複製元のホスト名」のままとなるため、ホスト名の変更が必要な場合は、OS 上から変更する必要有。
イメージ : コピーしてきた Azure Linux 仮想マシン OS ディスク
仮想ネットワーク : 該当リージョン上の任意の仮想ネットワーク

4) 複製した Azure Linux 仮想マシンを起動し、接続できることを確認します。(複製元の Azure Linux 仮想マシン接続時に使用していた pem ファイルを利用)

※ 以下の例では、複製元の Azure Linux 仮想マシンにインストールされていた PostgreSQL への接続テストを複製先で実施しています。

※ 複製の場合、Azure Linux 仮想マシンをデプロイ時に指定した「仮想マシン名」(本例では ubje001sa) は、 Azure Linux 仮想マシン OS の hostname には反映されず、複製元の hostname がそのまま引き継がれるため、変更が必要な場合は OS から変更を実施。

まとめ

今回、Azure Linux 仮想マシンを複製して別リージョンでデプロイする方法について、まとめてみました。

Azure 仮想マシン OS ディスクのリージョン間コピーを実施する方法として、「Microsoft Azure Storage Explorer」を利用してみましたが、本ツールを利用して、同一リージョン、別リージョンはもちろん、別のAzure サブスクリプションに対しても Azure Linux 仮想マシン OS ディスクのコピーを簡単に実施することが可能となります。

また、Azure Storage 上のファイルを管理したり、利用されているディスク容量なども簡単に確認できるため、積極的に利用してみると良いかと思います。

※ 2023年11月時点

NOBTAの気ままにITブログ

2023-11-09T23:55:32+09:00

Azure 東倭国リージョンにデプロイされた仮想マシンの複製を別リージョンでデプロイ

したいという状況があるのではないかと思います。

Azure 仮想マシンを別リージョンに複製する一つの方法として、Azure 仮想マシンの OS マネージドディスクを複製し、複製した OS マネージドディスクを別リージョンにコピーしたうえで、別リージョン上で複製した OS マネージドディスクを利用して Azure 仮想マシンをデプロイするという方法があります。

複製した OS マネージドディスクを別リージョンにコピーする方法として、「Azure CLI」を利用する方法、「Microsoft Azure Storage Explorer」を利用する方法などの複数の方法がありますが、今回は最も簡易的にコピーを実施することが可能となる「Microsoft Azure Storage Explorer」を利用する方法について、自分の整理も兼ねてまとめてみようと思います。

Azure OS マネージドディスクを別リージョンにコピーする方法
まとめ
参考情報

Azure OS マネージドディスクを別リージョンにコピーする方法

[前提条件]

Microsoft Azure Storage Explorer がインストールされている。
コピー元、コピー先の Azure Disks サービスに対して Microsoft Azure Storage Explorer からアクセスできる状態になっている。

1) Microsoft Azure Storage Explorer を起動します。

2) コピー元の OS マネージドディスクが配置された Azure サブスクリプション - Disks - リソースグループを選択し、コピー元の OS マネージドディスク (本例では「ubje001-OsDisk-dup」を選択後、「コピー」を押下します。

3) コピー先の Azure サブスクリプション - Disks - リソースグループを選択し、「貼り付け」を押下します。

※ 別サブスクリプション間、同一サブスクリプション間の別リソースグループ間、同一サブスクリプションの同一リソースグループ間でコピーが可能。

4) 必要項目を入力後、「貼り付け」ボタンを押下します。

ディスク名 : 任意の名前
場所 : OS マネージドディスクを配置したいリージョンを指定 (本例では「西倭国」を指定)
可用性ゾーン : 任意の可用性ゾーンを指定
アカウントの種類 : 任意のアカウントの種類を指定

5) 正常にコピーが完了し、OS マネージドディスクがコピー先(指定したリージョン)で作成されたことを確認します。

まとめ

今回は「Microsoft Azure Storage Explorer」を利用して、OS マネージドディスクを別リージョンにコピーする方法についてまとめてみました。

なお、Azure CLI を利用してコマンドで同様のことを実施することは可能です。

そのため、「Microsoft Azure Storage Explorer」が利用できない場合、OS マネージドディスクのコピーを大量に実施する必要がある場合、本処理を自動化処理の中に組み込む必要がある場合は、「az disk create」コマンドを利用することを検討されると良いかと思います。

参考情報

※ 2023年11月現在

NOBTAの気ままにITブログ

2023-11-06T21:16:51+09:00

Windows 環境からAzure Linux 仮想マシンに接続を実施した場合、正しい Azure Linux 仮想マシンへの接続情報および接続に必要なpemファイルを指定したとしても、「Permissions for '*********.pem' are too open.」というエラーで接続できない現象を経験したことがある人もいるのではないかと思います。

今回は本エラーの対処方法について、まとめてみようと思います。

エラー「Permissions for '*********.pem' are too open.」の意味
エラー「Permissions for '*********.pem' are too open.」の対処方法
まとめ
参考情報

エラー「Permissions for '*****.pem' are too open.」の意味

上記は、Windows 環境で起動した PowerShell から Azure Linux 仮想マシンへ接続しようとした際にエラー「Permissions for '*********.pem' are too open.」が発生しています。

エラー「Permissions for '*********.pem' are too open.」は、Azure Linux 仮想マシンへ接続した際に指定した pem ファイルのアクセス制御エントリ (ACE) に多数のユーザーアカウントが登録され、pem ファイルへのアクセスが可能となっている場合に発生するエラーとなります。

今回の例の場合、pem ファイルのアクセス制御エントリ (ACE) に Users ドメイングループおよび Authenticated Users が登録され、該当ファイルへの読み取りと実行権限が付与されています。

そのため、複数のドメインユーザーからpem ファイルにアクセスが可能となっているため、エラー「Permissions for '*********.pem' are too open.」の対象になっています。

エラー「Permissions for '*****.pem' are too open.」の対処方法

[前提]

「c:\pem\linuxadmin.pem」のアクセス制御エントリ(ACE)、アクセス制御 (ACL) は、C ドライブから継承されている。
Windows 環境に pem ファイルを配置し、Azure Linux 仮想マシンに接続している。

1) 該当のpemファイル - 右クリック - プロパティ - セキュリティタブを選択します。

2) 「詳細設定」を押下します。

3) 「継承の無効化」- 「継承されたアクセス許可をこのオブジェクトの明示的なアクセス許可に変換します。」を押下します。

4) アクセス制御エントリ(ACE) から Users ドメイングループおよび Authenticated Users を削除します。

5)「追加」を押下し、任意のドメインユーザー (Windows 環境にログインしているドメインユーザー) をアクセス制御エントリ(ACE)として登録し、アクセス制御 (ACL)として「読み取りと実行」権限を付与後、「適用」ボタン、「OK」ボタンを押下します。

6) PowerShell を起動し、Azure Linux 仮想マシンに正常に接続できることを確認します。

※ 本例では Azure Linux 仮想マシン (Ubuntu 20.04.6 に接続しています。)

まとめ

今回、エラー「Permissions for '*********.pem' are too open.」の意味、および、Windows 環境からAzure Linux 仮想マシンに接続した際に本エラーが発生した際の対処方法についてまとめてみました。

Linux 環境からAzure Linux 仮想マシンに接続する場合においても、同様に本エラーが発生する可能性があります。

詳細には、以下「参考情報」の公開情報を参照してもらえればと思います。

参考情報

※ 2023年11月時点

NOBTAの気ままにITブログ

2023-09-18T21:29:03+09:00

オンプレミス環境上の SQL Server を Azure へ移行することを検討する場合、Azure上で選択可能なSQL Sever関連のマネージドサービス (PaaS)の種類が多く、どのマネージドサービスが要件 (Fit & Gap) を満たす最適なサービスであるか、悩まれている方もいるのではないでしょうか。

今回、自身の整理も兼ねて、SQL ServerのAzure移行に向けたフローチャートを作成してみようと思います。

SQL ServerのAzure移行に向けたフローチャート
SQL ServerのAzure移行に関する参考情報
まとめ

SQL ServerのAzure移行に向けたフローチャート

[補足]

2023年9月時点の情報をベースにマイグレーションフローチャートを作成。
正確な各サービスのSLAについては、以下マイクロソフトの公式情報を確認。

Service Level Agreements (SLA) for Online Services

SQL ServerのAzure移行に関する参考情報

Azure への SQL Sever マイグレーションに関する参考情報、移行時の注意点、Fit＆Gap 分析に役立つ情報などをまとめた Microsoft Learn コレクションを作成してみました。

Azure への SQL Sever マイグレーション : Microsoft Learn コレクション

まとめ

今回、自身の整理も兼ねて、SQL ServerのAzure移行に向けたフローチャートの作成、および、移行に参考となる公開情報をまとめた Microsoft Learn コレクションの作成、共有を実施してみました。

SQL ServerのAzure移行を検討する際の参考になればと思います。

なお、各種クラウドサービスは日々進化していくため、移行を検討の際には、マイクロソフトが公開している最新の公開情報についても確認ください。

また、今回作成したSQL ServerのAzure移行に向けたフローチャートに不備がある場合は、お気軽にコメントをいただければと思います。

※ 2023年9月時点

NOBTAの気ままにITブログ

2023-09-04T16:57:30+09:00

Azure 仮想マシンに Windows Server 2022 をデプロイ後、倭国語化＋イメージとして登録する必要があったので、手順をまとめてみました。

Azure上で用意されているイメージで Windows Server をデプロイした場合、必ず言語が英語になります。そのため、倭国語化した Windows Server を複数台デプロイする必要がある場合は、Windows Server を倭国語化したうえでイメージを作成 (Sysprep)し、作成したイメージでAzure仮想マシンをデプロイすることで、大幅に環境構築の工数を削減することができます。

他の Windows OS の倭国語化方法については以下を参照。

Windows Server 2022 の倭国語化
イメージの作成

Windows Server 2022 の倭国語化

1) スタートボタン - 「Settings」を選択します。

2) 「Time & Language｣を選択します。

3) 「Language｣ - ｢Add a language」を選択します。

4) 「倭国語」を選択後、「Next」を選択します。

5) すべてのチェックボックス (「Set as my Windows display language」含む) にチェックし、「Install」を選択します。

※ 「倭国語」言語パックのダウンロード、インストールが開始されます。

6) 「倭国語」の言語パックのインストールが完了後、「Date & time」- Time zone 「(UTC+09:00) Osaka, Sapporo, Tokyo」を選択します。

7) 「Region」- Country or region 「Japan」を選択します。

8) 「Language」- 「Administrative language settings」を選択します。

9) 「Change system locale｣を選択します。

10) Current system locale : 「Japanese (Japan)」を選択し、「OK」を選択します。

※ 一旦「later」を選択します。

11) 「Copy settings」を選択します。

12) すべてのチェックボックスにチェックし、「OK」を選択します。

※ 「Restart now」を選択し、OSの再起動を実施します。

13) OS 再起動後、スタートボタン - 「設定」を選択後、「時刻と言語」を選択します。

14) 「言語｣ -「倭国語」-「オプション」を選択します。

15) 「ハードウェアキーボードレイアウト｣ -「レイアウトを変更する」を選択します。

16) 「倭国語キーボード (106/109 キー)」を選択後、「今すぐ再起動する」を選択します。

イメージの作成

1) イメージ化したい Azure 仮想マシンに接続します。

2) 管理者としてコマンドプロンプトを起動し、「%windir%\system32\sysprep」へパスを移動後、「sysprep.exe｣を実行します。

3) 以下のように設定後、「OK」を選択します。

※ sysprep 処理が実行された後、Azure 仮想マシンがシャットダウンされます。

---

システムクリーンアップアクション : 「システムの OOBE (Out-of-Box Experience) に入る」

「一般化する」にチェック

シャットダウンオプション : 「シャットダウン｣

---

4) Azure ポータルに移動して、sysprep 処理を実行した仮想マシンを選択します。

5) 「概要」- 「キャプチャ」を選択します。

6) 以下の必要項目を入力後、「確認および作成」を選択し、イメージを作成します。

・リソースグループ : 任意

・Azure コンピューティングギャラリーにイメージを共有する : 任意

※ 今回は、「いいえ、マネージドイメージのみをキャプチャします。」を選択します。

・名前 : 任意

・ゾーンの回復性 : 任意

※ Azure 可用性ゾーンの仮想マシンをイメージから作成する必要がある場合は、本項目にチェックします。

7) すべてのサービス - 「イメージ」を選択し、イメージが作成されていることを確認します。

※ 仮想マシンの作成からも作成したイメージを選択できます。

Azure Resource Manager (ARM) テンプレートにイメージを指定してAzure仮想マシンをデプロイすることも可能となります。また、コンテナ用イメージの場合も同様の方法で倭国語化することが可能であり、Windows Server OSの倭国語化は結構時間を要する作業であるため、倭国語化された Windows Serverをデプロイする必要がある場合は、事前に倭国語化したイメージを作成することで環境構築の時間を軽減することができるかと思います。

※ 2023年9月時点

NOBTAの気ままにITブログ

2023-03-16T01:52:06+09:00

第4回では、SQL Server 2022 の新機能の一つである包含可用性グループについてまとめてみました。

今回は、SQL Server 2022 の新機能の一つである分散型可用性グループ REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションについて、自分の整理も兼ねてまとめてみようと思います。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションについて
分散型可用性グループでREQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションを利用するメリットについて
まとめ

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションについて

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションは、SQL Server 2017 以降の Always On 可用性グループで利用可能となっているオプション設定です。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションにより、以下のような動作が行われます。

SQL Server 2022 では、分散型可用性グループに対しても REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションを利用することが可能になったようです。
※ 但し、本オプションは新規分散型可用性グループ作成時には指定できず、ALTER AVAILABILITY コマンドで後から変更する必要があるようです。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT : 0
Always On 可用性グループの可用性モードが同期コミットの場合、プライマリレプリカに対して発生したトランザクション (コミット) は、トランザクション情報がセカンダリレプリカのトランザクションログに書き込まれるまで待ち状態となる。
但し、設定した接続タイムアウト値 (既定 15秒) を超えてセカンダリレプリカからの応答がない場合、セカンダリレプリカを切り離して、プライマリレプリカ側でコミット処理を継続するという動作が行われる。
※ SQL Server 2016 Always On 可用性グループと同じ動作。
　
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT : 1 以上を設定
Always On 可用性グループの可用性モードが同期コミットの場合、プライマリレプリカに対して発生したトランザクション (コミット) は、トランザクション情報がセカンダリレプリカのトランザクションログに書き込まれるまで待ち状態になる。
但し、設定した接続タイムアウト値 (既定 15秒) を超えてセカンダリレプリカからの応答がない場合、セカンダリレプリカを切り離して、プライマリレプリカ側でコミット処理を継続するという動作が行われるという動作までは同じですが、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT の設定値により、プライマリレプリカでコミットするためにトランザクション情報の書き込み必要なセカンダリレプリカの最小数が設定されます。
例えば、本オプション設定値が「1」の場合、プライマリレプリカでコミットするためにトランザクション情報の書き込み必要なセカンダリレプリカの最小数が「1」となるようです。

なお、同期セカンダリレプリカが障害などでダウンし復旧した場合、本オプション設定値に指定した数の同期セカンダリレプリカとプライマリレプリカ間のデータ同期が完了するまで、プライマリレプリカへのトランザクション (コミット)が失敗するようなので注意が必要かと思います。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションの詳細については、以下の URL を参照

分散型可用性グループでREQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションを利用するメリットについて

意図しない障害発生時以外で分散可用性グループセカンダリ可用性グループへ手動フェールオーバーを実施する場合、確実にデータ損失を発生させずにフェールオーバーを実施させたいと考えるかと思います。

分散型可用性グループでREQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションを使用することで、確実にデータ損失を発生させず手動フェールオーバーを実施することが可能となるようです。

分散可用性グループのデータ損失を発生させない手動フェールオーバーの詳細については、以下の URL を参照。

まとめ

今回は、SQL Server 2022 の新機能の一つである分散型可用性グループ REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションについてまとめてみました。

分散型可用性グループで本オプションを利用することで、確実にデータ損失を発生させることなく手動フェールオーバーを実施することが可能になるようです。

しかしながら、本オプションを有効化した状態で分散可用性グループで障害発生し、障害が発生したレプリカノードが復旧した場合、レプリカ間のデータ同期が完了するまで可用性データベースにアクセスができない状況が発生するようなので、特に要件がなければ、分散型可用性グループで手動フェールオーバーを実施する際に一時的に有効にするなどの用途で利用することを検討されると良いかもしれません。

※ 2023年3月時点

NOBTAの気ままにITブログ

2023-03-14T00:20:54+09:00

第3回では、SQL Server 2022 の新機能の一つである Azure SQL Managed Instance へのリンク機能の拡充 (ディザスタリカバリ) についてまとめてみました。

今回は、SQL Server 2022 の新機能の一つである包含可用性グループについて、自分の整理も兼ねてまとめてみようと思います。

包含可用性グループについて
まとめ

包含可用性グループについて

SQL Server Always On 可用性グループは、シェアードナッシング (Shared Nothing) でSQL Server の高可用性を実現する機能となります。

※ 引用 : Always On 可用性グループとは

可用性グループに所属する各可用性レプリカ (ノード) にはシステムデータベース、ユーザーデータベースが配置され、可用性データベースに追加されたユーザーデータベースは、各可用性レプリカ間でデータの同期が行われています。

SQL Server Always On フェールオーバークラスターインスタンス (FCI) のように共有ディスクを保持する必要がなく、特定の可用性レプリカ(ノード)でディスク障害が発生したとしても他の可用性レプリカ(ノード)でサービスを継続させることが可能になるというメリットがあります。

しかしながら、SQL Server 2019 以前のバージョンでは、基本的にユーザーデータベースのみしか可用性データベースに追加できず、システムデータベース master に保持されているログイン情報、アクセス権限情報、システムデータベース msdb に保持されている SQL Server Agent ジョブ情報などについては、各可用性レプリカ (ノード) 上で手動で作成する必要がありました。

包含可用性グループは、システムデータベース master のログイン、ユーザー、アクセス許可のみを含む特殊なデータベースと、システムデータベース msdb の SQL Server Agent ジョブ関連情報を含む特殊なデータベースを可用性データベースに追加し、包含可用性グループがフェールオーバーして他の可用性ノードに移動したとしても、移動前の可用性ノードで利用できていたログイン、ユーザー、アクセス許可、SQL Server Agent ジョブを利用可能にしているようです。

包含可用性グループは、SQL Server Management Studio (SSMS) から新しい可用性グループウィザードを起動し、少しわかりづらいのですが「可用性グループオプション」で「含まれている」、「システムデータベースの再利用」にチェックを入れることで簡単に作成が可能です。

包含可用性グループを構成後、SSMS で該当可用性グループの可用性データベースを確認すると、可用性データベースの他に、<可用性グループ名>_master 、<可用性グループ名>_msdb という二つのデータベースが追加されていることが確認できます。

なお、<可用性グループ名>_master 、<可用性グループ名>_msdb へのアクセスは、包含可用性グループリスナー経由で該当包含可用性グループにアクセスした場合、master や msdb への接続が <可用性グループ名>_master 、<可用性グループ名>_msdb へリダイレクトすることで実現しているようです。

そのため、包含可用性グループを利用する場合は、ほぼ包含可用性グループリスナーが必須になるのではないかと思います。

包含可用性グループを利用するメリットがある一方で以下のような機能はサポートされていないようです。

SQL Server レプリケーション機能
分散可用性グループ
※ 一部抜粋

そのため、包含可用性グループを構築する場合は、メリット以上のデメリットがないかをしっかりと検討したうえで構築されると良いかと思います。

※ 包含可用性グループの詳細な考慮事項については、以下の URL を参照

まとめ

今回は、SQL Server 2022 の新機能の一つである包含可用性グループについてまとめてみました。

包含可用性グループを利用することで、各可用性レプリカ (ノード) 毎に設定が必要だったログイン設定、SQL Server Agent ジョブの設定が緩和されます。

しかしながら、SQL Server レプリケーション機能 (スナップショット、トランザクション、マージのすべての種類) が使用できないなどデメリットもあるようです。

【第5回 SQL Server 2022 新機能】分散型可用性グループ REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT オプションへ

※ 2023年3月現在

NOBTAの気ままにITブログ

2023-03-13T11:59:16+09:00

第2回では、SQL Server 2022 の新機能の一つである Azure Active Directory (Azure AD) 認証についてまとめてみました。

今回は、SQL Server 2022 の新機能の一つである Azure SQL Managed Instance へのリンク機能の拡充 (ディザスタリカバリ) について、自分の整理も兼ねてまとめてみようと思います。

Azure SQL Managed Instance へのリンク機能の拡充 (ディザスタリカバリ) について
Azure SQL Managed Instance へのリンク機能について
まとめ

Azure SQL Managed Instance へのリンク機能の拡充 (ディザスタリカバリ) について

Azure SQL Managed Instance へのリンク機能は、旧 SQL Server の一部のバージョン／エディションでも利用することができましたが、オンプレミス SQL Server AlwaysOn 可用性グループ -> Azure SQL Managed Instance への手動フェールオーバーを実施するとリンクが切れ、フェールバックすることが出来ませんでした。

【SQL Server 2019 以前で Azure SQL Managed Instance へのリンク機能がサポートされているバージョン、エディションについて】

SQL Server 2016 SP3 (KB5003279) + Azure Connect パック (KB5014242) Standard/Enterprise Edition
SQL Server 2019 Enterprise Edition CU15 (KB5008996)、Standard Edition CU17 (KB5016394)

SQL Server 2022 では、Azure SQL Managed Instance へのリンク機能が拡充され、ディザスタリカバリ機能として、オンプレミス SQL Server AlwaysOn 可用性グループ -> Azure SQL Managed Instance へ手動フェールオーバー後、Azure SQL Managed Instance -> オンプレミス SQL Server AlwaysOn 可用性グループへのフェールバックが可能 になったようです。

※ 2023年3月時点では、ディザスタリカバリ機能はまだプレビュー機能になっています。

Azure SQL Managed Instance へのリンク機能を利用することで、Azure SQL Managed Instance をディザスタリカバリ (DR) 環境として利用することが可能、かつ、オンプレミス SQL Server から Azure への移行のダウンタイムを最小限に抑えることが可能な点がメリットでしょうか。

Azure SQL Managed Instance へのリンク機能について

※ 引用 : Managed Instance のリンク機能の概要

Azure SQL Managed Instance へのリンク機能は、オンプレミス SQL Server AlwaysOn 可用性グループ - Azure SQL Managed Instance 間に分散型可用性グループ (SQL Server AlwaysOn 可用性グループ間でデータを同期する機能) を作成することで実現しているようです。

つまり、分散型可用性グループのテクノロジーを利用し、オンプレミス SQL Server AlwaysOn 可用性グループ側に発生した挿入、更新、削除のトランザクション情報を Azure SQL Managed Instance へ送信することで、オンプレミス SQL Server AlwaysOn 可用性グループ - Azure SQL Managed Instance 間の同期を準リアルタイム (near real-time) を実現しているようです。

【補足】

SQL Server Management Studio (SSMS) バージョン 19.0 以降を利用することで、SSMS上から Azure SQL Managed Instance link ウィザードにより、Azure SQL Managed Instance へのリンク機能を簡単に構成することが可能です。

但し、Azure SQL Managed Instance リンクに含めるオンプレミス側 SQL Server インスタンスでは、「Always On 可用性グループの有効化」、「推奨トレースフラグの有効化 (トレースフラグ 1800、9567)」、「データベースマスターキー作成」などの前提条件(推奨事項) を満たす必要があります。

また、事前に Azure SQL Managed Instance を Azure 上にデプロイし、オンプレミス環境から Azure SQL Managed Instance へ Azure VPN もしくは Azure Express Route 経由で接続できることを確認しておく必要があります。

次に分散可用性グループを構成するために必要なエンドポイント、証明書などの作成に関する情報、オンプレミス環境上で SQL Server AlwaysOn 可用性グループ、分散可用性グループを作成するための情報が必要となります。

証明書の有効期限は、要件がなければ可能な限り延ばしたほうが証明書の更新作業の手間が省くことができるかと思います。

Azure SQL Managed Instance link ウィザード完了後、オンプレミス SQL Server 環境側には、可用性グループおよび分散可用性グループの作成が行われていることが確認できます。

また、SSMS 可用性グループのダッシュボードからオンプレミス SQL Server から Azure SQL Managed Instance への分散可用性グループが作成され、正常にデータ同期がされている状況を確認することが可能です。

最後に、Azure SQL Managed Instance リンク機能を利用する上で Azure SQL Managed Instance のパブリックエンドポイント経由の通信は利用できないなどの制限事項が存在します。そのため、本機能を利用する前に制限事項をしっかりと確認したうえで構築することをお勧めいたします。

※ Azure SQL Managed Instance リンク機能の制限事項の詳細については、以下の URL を参照

まとめ

今回は、SQL Server 2022 の新機能の一つである Azure SQL Managed Instance へのリンク機能の拡充 (ディザスタリカバリ) についてまとめてみました。

Azure SQL Managed Instance へのリンク機能を利用することで、ディザスタリカバリ用途として利用する以外にも、オンプレミス SQL Server から Azure 環境への移行が最小のダウンタイムで可能となったり、オンプレミス SQL Server のワークロードの一部をAzure 側にオフロード (レポート、分析機能などの読み取り専用の処理を Azure SQL Managed Instance を利用して実装するなど) するなど、様々なシナリオに応用が可能となります。そのため、DXを推進するためにも本機能を積極的に検討してみても良いかもしれません。

【第4回 SQL Server 2022 新機能】包含可用性グループへ

※ 2023年3月時点

NOBTAの気ままにITブログ

2023-03-05T04:38:34+09:00

SQL Server 2022 より、オンプレミス環境においても Azure AD を利用した認証を実施することが可能となりました。

今回は、オンプレミス SQL Server 2022 上で Azure AD 認証用ログイン／ユーザーを作成する方法について、自分の整理も兼ねてまとめてみようと思います。

※ Amazon EC2、Google Cloud Compute Engine 上にインストールされた SQL Server 2022 についても、同様に Azure AD 認証設定を実施することが可能。

前提条件
Azure AD 認証用ログイン／ユーザー作成手順 (SQL Server 2022以降)
Azure AD 認証用ログインによるオンプレミス SQL Server 2022への接続方法
まとめ

前提条件

オンプレミス SQL Server 2022 上で Azure AD 認証用ログイン／ユーザーを作成するためには、以下の前提条件を満たす必要があります。

SQL Server 2022 および SQL Serverをインストールしているサーバー (Windows/Linux) が Azure Arc に登録されている必要がある。
Azure AD 上に認証用アプリケーションを登録する必要がある。
Azure KeyVault 上に認証用アプリケーション用の証明書を作成する必要がある。

参考URL

Azure AD 認証用ログイン／ユーザー作成手順 (SQL Server 2022以降)

1) SQL Server Management Studio (SSMS) を起動し、管理者権限(sysadmin)が付与されたログイン (saなど) で接続します。

2) 「新しいクエリ」を選択します。

3) 以下のコマンドを実行し、Azure ポータル - Azure Arc - インフラストラクチャ : SQL サーバー - 登録されている SQL Server 2022 インスタンス - 設定 : Azure Active Directory - Azure Active Directory 管理者に登録された管理者ログインに対して管理者権限 (sysadmin) を付与します。

※ 本手順では管理者ログインを「[email protected]」とします。

use master
go
ALTER SERVER ROLE sysadmin ADD MEMBER [[email protected]]
go

4) 以下のコマンドを実行し、新しいログインを作成します。

※ 本手順では Azure AD 上に存在する「[email protected]」ユーザーに紐づくログインを作成します。

※ Azure AD グループ、Azure ADに登録したアプリケーションに紐づくログインも作成可能となります。

use master
go
CREATE LOGIN [[email protected]] FROM EXTERNAL PROVIDER
go

<補足>

必要に応じて作成した新規ログインに対して、必要なロールを割り当てます。

[例] 「[email protected]」ログインに対して管理者権限(sysadmin) を付与する場合

use master
go

EXEC sp_addsrvrolemember @loginame='[email protected]', @rolename='sysadmin'
go

5) 以下のコマンドを実行し、4) で作成したログインが作成されていることを確認します。

use master
go
SELECT * FROM sys.server_principals
WHERE type_desc = 'EXTERNAL_LOGIN'
go

6) 以下のコマンドを実行し、4) で作成したログインに紐づくデータベースユーザーを作成します。

※ 本手順ではユーザーデータベース上で「[email protected]」ログインに紐づく、「[email protected]」という名前のデータベースユーザーを作成しています。

※ 本コマンド実行後、ユーザーデータベースに対して該当のログイン紐づくデータベースユーザーが作成されます。

use <ユーザーデータベース>
go
CREATE USER [[email protected]] FROM LOGIN [[email protected]];
go

<補足>

必要に応じてユーザーデータベース上に作成したデータベースユーザーに対して必要な権限を割り当てます。

Azure AD 認証用ログインによるオンプレミス SQL Server 2022への接続方法

1) SQL Server Management Studio (SSMS) を起動します。

2) 必要項目に入力後、「オプション」を選択します。

サーバー名 : SQL Server 2022のインスタンス名を指定 (Azure Arcに登録されているインスタンス名)

認証 : Azure Active Directory - パスワード

※ 「Azure Active Directory - MFAで汎用」、「Azure Active Directory - 統合」などによる認証も可能です。詳細は以下のURLを参照。

ユーザー名 : Azure AD認証用に指定したログイン名を指定

パスワード : ログインに紐づく Azure AD ユーザーのパスワードを指定

3) 必要項目に入力、選択後、「接続」を選択します。

データベースへの接続 : 接続するユーザーデータベース名を指定。

暗号化接続 : チェック

サーバー証明書を信頼する : チェック

4) オンプレミス SQL Server 2022 インスタンスに Azure AD認証により接続が確立されたことを確認します。

まとめ

今回は、オンプレミス SQL Server 2022 上で Azure AD 認証用ログイン／ユーザーを作成する方法についてまとめてみました。

本機能を利用するためには、前提条件としてオンプレミス上の SQL Server 2022 がインストールされたサーバーおよび SQL Server 2022 インスタンスが Azure Arc に登録されている必要があります。

Azure Arc への登録は若干の作業が必要になりますが、SQL Serverへの接続ログインを一元的に管理が可能となるため、SQL Server 2022 へのリプレースのタイミングなどで本機能を利用することを検討してみると良いかもしれません。

※ 2023年3月時点

NOBTAの気ままにITブログ

2023-02-26T12:07:03+09:00

第1回では、SQL Server 2022 の新機能の一つである SQL Serverを従量課金制 (pay-as-you-go) についてまとめてみました。

第2回では、SQL Server 2022 より利用可能となった Azure Active Directory (以下 Azure AD）認証について、自分の整理も兼ねてまとめてみようと思います。

SQL Server の Azure AD 認証について
SQL Server の Azure AD 認証の設定方法について
まとめ

SQL Server の Azure AD 認証について

Azure SQL Database では Azure AD を利用した認証がサポートされていましたが、SQL Server 2022 以降、オンプレミス上の Windows および Linux サーバーにおいても Azure AD 認証がサポートされるようになりました。

Azure AD 認証方法としては、以下のような方法がサポートされています。

Azure Active Directory パスワード
Azure Active Directory 統合
Azure Active Directory - 多要素認証(MFA) による Universal認証
Azure Active Directory アクセストークン

但し、オンプレミス上の SQL Server が Azure AD へ認証を実施するための前提条件として、以下の条件があるようです。

SQL Server 2022 および SQL Serverをインストールしているサーバー (Windows/Linux) が Azure Arc に登録されている必要がある。
Azure AD 上に認証用アプリケーション登録する必要がある。
Azure KeyVault 上に認証用アプリケーション用の証明書を作成する必要がある。
SQL Server 2022 上で Azure AD認証用のログイン、ユーザーを作成する必要がある。

※ オンプレミス SQL Server 2022 を Azure Arc の管理対象に追加する方法については、以下の URL を参照

[例] Azure Arc に登録されているオンプレミス上のSQL Serverインスタンス

SQL Server の Azure AD 認証の設定方法について

SQL Server の Azure AD 認証の設定方法については、以下のURLを参照

[注意点]

現時点 (2023年2月時点) において、既知の問題として、Azure AD 認証用に作成した証明書を更新した場合、自動的に証明書を反映することができない可能性が有り、証明書を更新するために以下の手順が必要になる可能性があるとのことです。

証明書が正しく適用されなければ Azure AD 認証が失敗するため、証明書を更新した場合、以下の暫定対処策を実施すること

+ 証明書更新手順 (暫定対処策)

1) Azure Arc - インフラストラクチャ : SQL サーバー - 登録されている SQL Server インスタンス - 設定 : Azure Active Directory -「管理者の削除」を実施後、「保存」を選択。

2) 「管理者の設定」を選択し、新しい証明書を使用した Azure AD 認証を再構成後、「保存」を選択。

まとめ

第2回では、SQL Server 2022 より利用可能となった Azure AD 認証についてまとめてみました。Azure AD 認証を利用することで、Azure AD の標準機能で利用可能な多要素認証(MFA) を利用した認証についても実施することが可能となります。

また、Azure Arc + SQL Server 2022 Azure AD 認証を利用することで、マルチクラウド (AWS, Google Cloud など) およびオンプレミス上の SQL Server 2022 の認証情報を一元管理することが可能となり、一貫したガバナンス、セキュリティを実現することが可能となります。そのため、SQL Server 2022 を新規導入、もしくはアップグレードする場合には、Azure Arc を利用することを検討してみても良いかと思います。

【第3回 SQL Server 2022 新機能】Azure SQL Managed Instance へのリンク機能の拡充 (ディザスタリカバリ) へ

※ 2023年2月現在

NOBTAの気ままにITブログ

2023-01-15T03:54:33+09:00

SQL Server を Azure Arc の管理対象に追加することで、Azure ポータルから SQL Server 環境全体の把握が可能となり、効率的に在庫管理を実施することが可能となるなど、様々なメリットがあります。

今回は、SQL Server を Azure Arc の管理対象にするメリット、および、SQL Server を Azure Arc の管理対象に追加する方法について、自分の整理も兼ねてまとめてみようと思います。

SQL Server を Azure Arc の管理対象にするメリット
SQL Server を Azure Arc の管理対象に追加する方法について
まとめ

SQL Server を Azure Arc の管理対象にするメリット

SQL Server を Azure Arc の管理対象にするメリットして、以下のような点があるのではないかと思います。

【メリット1】

Azure 管理ポータル上から登録されている SQL Server のインスタンス名、エディション、ビルド番号、作成されているデータベース情報などを確認できるなど、ライセンス管理などの資産管理を効率的に実施することが可能。

[Azure Arc : SQL サーバー情報]

[Azure Arc : SQL サーバーデータベース情報(インスタンス毎)]

[Azure Arc : SQL サーバーインスタンス情報(詳細)]

【メリット2】

登録されている SQL Server インスタンスのアセスメントを実施し、Azure 管理ポータル上からアセスメントレポートを表示することが可能。

※ SQL Assessment では、以下の項目のアセスメントを実施。

SQL Server の構成
データベースの設計
セキュリティ
パフォーマンス
Always On
エラーログの分析
オペレーショナルエクセレンス

[Azure Arc : SQL サーバーインスタンス環境正常性]

[Azure Arc : SQL Server Assessment レポート]

【メリット3】

Microsoft Defender for Cloud により一元的に SQL Server に対するセキュリティの異常、脅威を検知することが可能。

【メリット4】

SQL Server 2022 インスタンスの場合、Azure SQL Database などの PaaS、Azure VM 上にインストールされた SQL Server と同様に、オンプレミス上にインストールされた SQL Server でも Azure Active Directory 認証を利用することが可能。

[Azure Arc : SQL サーバー Azure Active Directory]

SQL Server を Azure Arc の管理対象に追加する方法について

SQL Server 2022 の場合、セットアッププログラム -「SQL Server 用 Azure 拡張機能」から Azure Arc に SQL Server を登録することができます。

SQL Server 2019 以前のバージョンについては、以下の手順にて手動で SQL Server を Azure Arc の管理対象に追加することができます。

1) Azure 管理ポータルから Azure Arc - インフラストラクチャ : SQL サーバーを選択します。

2) 概要 -「+追加」を選択します。

3)「サーバーの接続」を選択します。

4)「次へ: サーバーの詳細」を選択します。

5) 必要項目を入力後、「次へ: タグ」を選択します。

6) 必要に応じてタグ情報を入力後、「次へ: スクリプトの実行」を選択します。

7) 「ダウンロード」を選択し、SQL Server を Azure Arc の管理対象として登録するスクリプト (RegisterSqlServerArc.ps1) をダウンロードします。

8) 7) でダウンロードしたスクリプト (RegisterSqlServerArc.ps1) を Azure Arc の管理対象に登録したい環境上で実行し、SQL Server を Azure Arc の管理対象として登録します。

まとめ

SQL Server を Azure Arc の管理対象にするメリット、および、SQL Server を Azure Arc の管理対象に追加する方法についてまとめてみました。

SQL Server を Azure Arc の管理対象にすることで、様々なメリットがあると思います。また、SQL Assessment 情報、Microsoft Defender for Cloud で検査する情報は、Azure Monitor - Log Analytics のログ上に保存されるため、Log Analyticsのクエリ言語（Kusto Query Language, KQL）を利用した分析用のデータとして利用することもできます。そのため、個別にカスタマイズした監視を実施したい場合にも本データを利用してみると良いかと思います。

参考URL

※ 2023年1月現在

NOBTAの気ままにITブログ

2023-01-08T02:02:14+09:00

2022年11月16日、「SQL Server 2022 」の一般提供が開始されました。

今回は SQL Server 2022 の新機能の一つである SQL Serverを従量課金制 (pay-as-you-go) に関して、自分の整理も兼ねてまとめてみようと思います。

SQL Serverを従量課金制 (pay-as-you-go) について
SQL Serverを従量課金制 (pay-as-you-go) 設定方法について
まとめ

SQL Serverを従量課金制 (pay-as-you-go) について

SQL Server 2022では、新しい課金モデルとしてクラウド対応課金モデルである「従量課金制 (pay-as-you-go)」をオンプレミス環境上にインストールされた SQL Server、および、Azure以外のIaaS環境 (例えば AWS EC2、Google Cloud Comupte Engine など) にインストールされた SQL Server に対して適用可能になるようです。

クラウド対応課金モデルである「従量課金制 (pay-as-you-go)」の場合のメリットについて簡単にまとめてみようと思います。

[メリット]

従量課金制であるため、使用した分のみ料金を支払うことができ、初期投資(ライセンス購入費など)に必要となる費用を軽減させることができる。
ライセンス購入に要するリードタイムを軽減することができる。
ワークロードが多くなるタイミングのみ SQL Server を増強したり、不要になったタイミングで停止／削除することで、コスト効率化を図ることができる。
マルチクラウド、ハイブリッド環境にも対応しているため、SQL Server 2022 環境がどこの環境に存在していたとしても、一貫した課金を選択することができる。

なお、「従量課金制 (pay-as-you-go)」を SQL Server 2022 に適用するための前提条件があるようです。

[前提条件]

Azure サブスクリプションの契約が必要
※ 「Microsoft.AzureArcData」および「Microsoft.HybridCompute」リソースプロバイダーの有効化が必要。
「従量課金制 (pay-as-you-go)」を適用する SQL Server 2022 環境 (オンプレミスのサーバー、Azure以外のIaaS環境 (例えば AWS EC2、Google Cloud Comupte Engine など) を Azure Arc の管理対象に追加することが必要
※ Azure への通信が必要。

SQL Serverを従量課金制 (pay-as-you-go) 設定方法について

SQL Server 2022 の「インストール」もしくは「エディションアップグレード」より、「Microsoft Azure を通じて従量課金制の課金を使用します」を指定することで SQL Serverを従量課金制として利用することが可能になるようです。

Azure Arc の設定については、以下の URL を参照。

まとめ

今回は SQL Server 2022 の新機能の一つである SQL Serverを従量課金制 (pay-as-you-go) に関してまとめてみました。

従量課金制を適用する場合、SQL Server 2022 がインストールされた環境を Azure Arc の管理対象に追加することが必要となります。
しかしながら、Azure Arc で管理することで Azure ポータルから SQL Server 環境全体の把握が可能となり、在庫とライセンス管理を効率的に管理可能になります。

また、SQL Best Practice Analyzer を利用したパフォーマンス、スケーラビリティ評価、Microsoft Purview を使用したデータガバナンス、Microsoft Defender for Cloud を利用したセキュリティの強化 (脆弱性、攻撃の検出など) が可能になるため、Azure Arc を利用できる場合は利用することをお勧めします。

参考情報

【第2回 SQL Server 2022 新機能】Azure Active Directory (Azure AD) 認証へ

※ 2023年3月現在

NOBTAの気ままにITブログ

2022-12-04T03:17:18+09:00

Azure Arc とは、マルチクラウド(AWS、Google Cloud など)上のリソース、オンプレミス上のサーバーを一元的に管理することで、環境全体で一貫したインベントリ(資産管理)、ガバナンス、セキュリティを実現するための機能になります。

現時点 (2022年12月現在) において、以下のリソースを管理することが可能なようです。

サーバー (Windows, Linux 物理サーバー、Azure外部の仮想マシン)
Kubernetes クラスター
Azure データサービス (オンプレミス、マルチクラウド上に SQL Managed Instance、Azure Database for PostgreSQL サービスを展開可能)
SQL Server (Azure 外部のSQL Serverに対して Azure サービスを拡張可能)

今回は、Azure Arc の機能を簡単に検証するため、Azure 仮想マシン上で Azure Arc 機能を利用する方法について、自分の整理も兼ねてまとめてみようと思います。

Azure Arc を Azure 仮想マシンで利用するための事前準備 (Windows)
Azure 仮想マシンで Azure Arc に接続する方法 (Windows)
まとめ

Azure Arc を Azure 仮想マシンで利用するための事前準備 (Windows)

1) Azure 上に Azure 仮想マシンをデプロイします。

2) Azure ポータルに接続します。

3) 1) でデプロイした Azure 仮想マシン - 設定 -「拡張機能とアプリケーション」を選択します。

3) 拡張機能 - 拡張機能が存在している場合、各拡張機能をアンインストールします。

※ 本例では、「CustomScriptExtension」がインストールされているのでアンインストールしています。

4) 1) でデプロイした Azure 仮想マシンにリモートデスクトップ接続 (RDP) により接続します。

5) PowerShell を管理者として起動します。

6) 以下のコマンドを実行し、Azure VM ゲストエージェントを無効化します。

Set-Service WindowsAzureGuestAgent -StartupType Disabled -Verbose
Stop-Service WindowsAzureGuestAgent -Force -Verbose

6) 以下のコマンドを実行し、Azure Instance Metadata Service (IMDS) エンドポイントへのアクセスをブロックします。

New-NetFirewallRule -Name BlockAzureIMDS -DisplayName "Block access to Azure IMDS" -Enabled True -Profile Any -Direction Outbound -Action Block -RemoteAddress 169.254.169.254

※ Azure Instance Metadata Service (IMDS) は、現在実行中のAzure 仮想マシンの情報を取得するために利用されるサービスになります。

Azure 仮想マシンで Azure Arc に接続する方法 (Windows)

1) Azure ポータルに接続します。

2) Azure Arc - インフラストラクチャ -「サーバー」-「+追加」を選択します。

3)「単一サーバーの追加」-「スクリプトの生成」を選択します。

※ 複数のサーバーを追加する場合は、「複数のサーバーの追加」を選択します。

4) 必要項目を入力後、「次へ」を選択します。

サーバーの詳細

地域
オペレーティングシステム : Windows

接続方法

接続方法 : パブリックエンドポイント

　※ ExpressRoute を構成している場合は、プライベートエンドポイントを選択することで、Azure Arc と Azure Arc エージェント間の通信がプライベート通信にて行われます。

5) 必要項目を入力後、「次へ」を選択します。

6)「ダウンロード」を選択し、生成されたスクリプトをダウンロードし、Azure Arc を Azure 仮想マシンで利用するに事前準備を実施した Azure 仮想マシン上の任意のパスに保存します。

※「ダウンロード」されたスクリプトの内容が文字化けするようであれば、Azure ポータルで表示されているスクリプトの内容をコピーして、手動で PowerShell スクリプトを作成します。

7) Azure Arc を Azure 仮想マシンで利用するに事前準備を実施した Azure 仮想マシンにリモートデスクトップ(RDP) で接続します。

8) 管理者権限でPowerShellを起動し、6)で生成したPowerShellスクリプトを実行します。

> .\OnboardingScript.ps1

※ スクリプトの中では以下の操作が行われます。

Connected Machine エージェントのインストール
Azure Arc サービスへの接続構成 (エージェント)

※ スクリプト処理の中でAzure への認証が行われるため、Azure Arc でスクリプトを生成した Azure サブスクリプションへ必要な権限が付与されたアカウントにて認証を実施します。

9) Azure ポータルに接続後、Azure Arc - インフラストラクチャ -「サーバー」を選択し、Azure Arc に管理されたサーバーが追加されたことを確認します。

[補足]

Azure Arc に該当サーバーが登録されたため、ログ監視、Microsoft Defender for Cloud による脆弱性監視、ポリシーの適用などを Azure ポータル上から設定することが可能になります。

まとめ

今回は、Azure Arc の機能を簡単に検証するため、Azure 仮想マシン上で Azure Arc 機能を利用する方法についてまとめてみました。

Azure Arc を利用することで、マルチクラウド(AWS、Google Cloud など)上のリソース、オンプレミス上のサーバーを一元的に管理し、環境全体で一貫したインベントリ(資産管理)、ガバナンス、セキュリティを実現することが可能になります。

また、SQL Server 2022 の新機能として、Azure Arc 機能を利用した Azure Active Directory 認証がサポートされているため、次回は本新機能について確認してみようと思います。

[参考URL]

※ 2022年12月現在

NOBTAの気ままにITブログ

2022-11-07T02:07:47+09:00

第19回では、仮想ログファイルのアーキテクチャとトランザクションログを圧縮する際の注意点についてまとめてみました。

今回は、SQL Server トランザクションログファイルの圧縮方法について、自分の整理も兼ねてまとめてみようと思います。

[前提]

データベースの復旧モデルが「完全」であることを想定しています。

※ データベースの復旧モデルが「単純」の場合、トランザクションが完了後、自動的に仮想ログファイル内のログ情報の切り捨てが行われ、未使用の状態になります。

トランザクションログファイルを圧縮するためには
トランザクションログファイル圧縮方法
まとめ

トランザクションログファイルを圧縮するためには

トランザクションログファイル (LDF) の圧縮は、トランザクションログファイルの末尾のオフセットから連続した未使用の仮想ログファイルの領域が解放されることになります。

例えば、以下の状態の圧縮前のトランザクションログファイルがあったとします。

このトランザクションログファイルを圧縮すると、トランザクションログファイルの末尾のオフセットから「仮想ログファイル4」と「仮想ログファイル3」が未使用となっているため、「仮想ログファイル4」と「仮想ログファイル3」の領域が解放されます。

それでは、以下の場合はどうでしょう？

このトランザクションログファイルを圧縮すると、「仮想ログファイル4」、「仮想ログファイル2」、「仮想ログファイル1」が未使用となっていますが、トランザクションログファイルの末尾のオフセットから連続した未使用領域は「仮想ログファイル4」のみであるため、「仮想ログファイル4」の領域のみが解放されます。

それでは、未使用となっている「仮想ログファイル1」、「仮想ログファイル2」を解放したい場合は、どうすればよいでしょうか？

上記状態では、「仮想ログファイル3」が Current (現在利用されている) の仮想ログファイルとなります。

仮想ログファイルは循環的に利用されるため、「仮想ログファイル3」に保持可能なログ情報が一杯になる、もしくは Checkpoint (チェックポイント) を実施することで、Currentの仮想ログファイルがトランザクションログファイルの先頭のオフセットから可能な限り近い仮想ログファイルに移動されることになります。

しかしながら、上記の状態の場合、「仮想ログファイル3」にはログ情報が保持されており未使用状態になっていないため、「仮想ログファイル3」、「仮想ログファイル2」を解放することができません。

そのため、「仮想ログファイル3」を未使用状態にするため、トランザクションログのバックアップを実施します。

トランザクションログバックアップ後、「仮想ログファイル3」に保持されていたログ情報が解放され、未使用な状態になりました。

このトランザクションログファイルを圧縮すると、トランザクションログファイルの末尾のオフセットから「仮想ログファイル3」と「仮想ログファイル2」が未使用となっているため、「仮想ログファイル3」と「仮想ログファイル2」の領域が解放されます。

なお、トランザクションログバックアップを実施したとしても、トランザクションログファイルのオフセットの末尾の仮想ログファイルが未使用な状態にならない場合がああります。

その場合には、システムカタログビュー sys.databases の log_reuse_wait_desc 列 (トランザクションログの再利用ができない理由／切り捨てが出来ない理由) を確認してみると良いかと思います。

トランザクションログファイルの末尾の仮想ログファイルが未使用にならない場合の原因を確認したい場合は、以下の URL を参照ください。

トランザクションログファイル圧縮方法

実際にトランザクションログファイルを圧縮する方法についてまとめてみたいと思います。

[実行するコマンド]

use <データベース名>
go
checkpoint
go
backup log <データベース名> to disk = '<バックアップ作成パス>'
go
dbcc shrinkfile (<トランザクションログ論理名>,<圧縮後のサイズ (MB)>)
go

1) 以下のコマンドを実行し、トランザクションログファイルを圧縮したいデータベース (今回は「db1」) の仮想ログファイルの状況を確認します。

select DB_NAME(database_id) as 'database_name',* from sys.dm_db_log_info(DB_ID('DB1'))
go

今回の例 (「db1」)の場合、トランザクションログファイルの末尾のオフセットの仮想ログファイル (8行目) から先頭の仮想ログファイルまで「vlf_active」が ”1” とすべて利用中の状態であることが確認できます。

2) 以下のコマンドを実行し、トランザクションログファイルのバックアップを実施します。 (今回は「db1」)

use db1
go
checkpoint
go
backup log db1 to disk = 'c:\temp\db1.log'
go

※ 「checkpoint」コマンドは必須ではないのですが、仮想ログファイルを循環させ Current の仮想ログファイルをトランザクションログファイルのオフセットの先頭に明示的に移動させるために実行しています。

今回の例 (「db1」)の場合、トランザクションログファイルの末尾のオフセットの仮想ログファイル (8行目) から先頭の仮想ログファイルまで「vlf_active」が ”0” とすべて未使用の状態であることが確認できます。

3) 以下のコマンドを実行し、トランザクションログファイルを圧縮します。 (今回は「db1」)

dbcc shrinkfile (db1_log, 10)
go

※ dbcc shrinkfile に指定するトランザクションログ論理名は、システムカタログ sys.sysfiles の「name」列などから確認可能です。

※ dbcc shrinkfile に指定するサイズは MB単位で指定します。上記の例では「10」MBが指定されており、可能な限り 10MB に近づくようにトランザクションログファイルを圧縮する操作が行われます。

use <データベース名>
go
select * from sys.sysfiles
go

今回の例 (「db1」)の場合、可能な限り 10MB に近づくようにトランザクションログファイルを圧縮する操作が行われたため、トランザクションログファイルのオフセットの先頭から10MBに存在する仮想ログファイル (今回は「仮想ログファイル5」) を含むサイズまで圧縮されました。

つまり、トランザクションログファイルのオフセットの先頭から10MBに存在する「仮想ログファイル5」のサイズ（vlf_size_mb) が 16MB となっているため、「仮想ログファイル1」から「仮想ログファイル5」までの合計サイズが 24MB となり、トランザクションログファイルの圧縮後のサイズは 24MB になりました。

※ 本例の場合、dbcc shrinkfile に指定するサイズを 7MB に指定した場合は、トランザクションログファイルのオフセットの先頭から7MBに存在する仮想ログファイルが「仮想ログファイル4」となるため、トランザクションログファイルの圧縮後のサイズは 8MB になることが想定されます。

まとめ

今回は、SQL Server トランザクションログファイルの圧縮方法についてまとめてみました。

データベースの復旧モデルが「完全」である場合、一般的にはトランザクションログのバックアップを実施することでアクティブなログの切り捨てが行われ、仮想ログファイルが未使用な状態になります。

トランザクションログのバックアップを実施したとしてもアクティブなログの切り捨てが行われず、仮想ログファイルが未使用な状態にならない場合は、システムカタログビュー sys.databases の log_reuse_wait_desc 列 (トランザクションログの再利用ができない理由／切り捨てが出来ない理由) を確認してみると良いかと思います。

※ 2022年11月現在

NOBTAの気ままにITブログ

2022-10-31T04:06:55+09:00

トランザクションログ (LDFファイル) が肥大化した場合、ディスクの空き容量が枯渇するなど、肥大化したトランザクションログを圧縮し、ディスクの空き容量を確保したいという状況があるかと思います。

トランザクションログ (LDFファイル) の肥大化を解消する方法については、以下の URL を参照

トランザクションログを圧縮する際、意図したサイズまでトランザクションログを圧縮することができない場合があります。

今回は、トランザクションログの物理アーキテクチャ : 仮想ログファイル (VLF : Virtual Log File) について、自分の整理も兼ねてまとめてみようと思います。

※ 第18回では「SQL Server のライフサイクルポリシー」についてまとめています。

仮想ログファイルのアーキテクチャについて
仮想ログファイルのファイル数、サイズについて
トランザクションログの圧縮について
まとめ

仮想ログファイルのアーキテクチャについて

トランザクションログファイル (LDF) は内部的に仮想ログファイル (VLF : Virtual Log File) という論理的な単位で分割されています。

仮想ログファイルのサイズは、トランザクションログファイルの初期作成時、拡張時にSQL Server エンジンにより動的に決定されます。

仮想ログファイル (VLF : Virtual Log File) は、先頭からログレコードの書き込みが行われ、先頭の仮想ログファイルが一杯になれば、次の仮想ログファイルにログレコードの書き込みが行われます。

また、トランザクションログの切り捨ては仮想ログファイル単位で行われます。

例えば、仮想ログファイルが8個あり、先頭から4個目の仮想ログファイルがアクティブな状態でログレコードの書き込みが行われているとします。

上記の状態でトランザクションログの切り捨てが行われた場合、先頭から3個目までの仮想ログファイルが解放され再利用可能な状態になり、先頭から4個目の仮想ログファイルはアクティブのまま残ります。

その後、先頭から4個目の仮想ログファイルが一杯 (もしくはチェックポイント処理を実行) になった場合、先頭の仮想ログが再利用可能になっているため、先頭の仮想ログファイルがアクティブとなりログレコードの書き込みが行われていきます。

そして、先頭から4個目の仮想ログファイルはアクティブな状態ではなくなったため、次回トランザクションログの切り捨てが行われたタイミングで再利用な状態になります。

上記のように仮想ログファイルは循環的に利用されますが、以下のような状況の場合、トランザクションログの切り捨てが行われる前に大量のログレコードが仮想ログファイルに書き込み続けられることで、トランザクションログのファイルサイズ (仮想ログファイル数) が肥大化する可能性があります。

ロングトランザクションの中で大量のDML処理(UPDATE/INSERT/DELETE)が実行される。
トランザクションログのバックアップが実行される間隔内で大量のDML処理(UPDATE/INSERT/DELETE)が実行される。

仮想ログファイルのファイル数、サイズについて

仮想ログファイル数、サイズは、トランザクションログの初期作成時、拡張時にSQL Serverエンジンにより動的に決定されます。

仮想ログファイル数は、基本的に以下のルールによって決定されるようです。

初期作成／拡張サイズ	仮想ログファイル数
64MB未満の場合	4
64MB以上1GB未満の場合	8
1GB以上	16

※ 拡張サイズが現在のトランザクションログサイズの 1/8 未満の場合、仮想ログファイル数は 1 となる。

※ SQL Server 2022 の場合、拡張サイズが64MB未満では仮想ログファイル数は 1 となる。

また、仮想ログファイルサイズは、初期作成／拡張されたサイズを仮想ログファイル数で割ったサイズになっているようです。

例えば、トランザクションログの初期サイズ 10GB (1024MB) のデータベース (今回は「DB1」) を作成した場合、

仮想ログファイル数確認コマンド (例)

select DB_NAME(database_id) as 'database_name',* from sys.dm_db_log_info(DB_ID('DB1'))
go

仮想ログファイル数確認コマンド実行結果 (例)

仮想ログファイルが 16個 作成され、各仮想ログファイルサイズ (vlf_size_mb) は 639.93MB になっていることが確認できます。

トランザクションログの圧縮について

トランザクションログの圧縮では、トランザクションログファイルのオフセットの末尾から連続した再利用可能な仮想ログファイルサイズが解放されます。

以下の例の場合、2番目から16番目までの仮想ログファイルが再利用可能な状態になっています。

仮想ログファイル数 (例)

上記の状態で、トランザクションログを圧縮するコマンドを実行してみます。

トランザクションログ圧縮コマンド (例)

※ 本例では、10240 MBで作成したトランザクションログファイルを可能な限り 64MB まで圧縮するコマンドを実行。

DBCC SHRINKFILE (N'DB1_log' , 64)
go

結果、以下のように仮想ログファイルが2個残った状態になりました。

トランザクションログ圧縮後の仮想ログファイル数 (例)

仮想ログファイルは、最低でも 2個保持される動作になっているようです。

10240 MBで作成したトランザクションログファイルを可能な限り 64MB まで圧縮したかったのですが、結果として約 1 GB までしか圧縮することができませんでした。

なお、今回のデータベースの場合、トランザクションログファイルの初期サイズを 10240 MB で作成したため、各仮想ログファイルサイズが約 639 MBとなっています。

また、最低でも2個の仮想ログファイルを保持する動作になっているため、今回のデータベースの場合、仮想ログファイルサイズ＊2 = 約 1GB 以下のサイズに圧縮することができないということになります。

まとめ

今回は、仮想ログファイルのアーキテクチャとトランザクションログを圧縮する際の注意点についてまとめてみました。

トランザクションログの初期サイズを大きなサイズ (数百テラバイトなど) で作成した場合、一つ当たりの仮想ログファイル (VLF : Virtual Log File) が大きくなってしまいます。

また、トランザクションログファイルサイズは、最低でも二つの仮想ログファイルサイズよりも小さいサイズに縮小することができないため、トランザクションログの初期サイズはあまり大きなサイズに指定せず、必要に応じて後からトランザクションログファイルサイズを拡張することを検討してみても良いかと思います。

【第20回】基本から始める SQL Server【トランザクションログの圧縮方法について】へ

※ 2022年10月現在

NOBTAの気ままにITブログ

NOBTAの気ままにITブログ

Azure Virtual Desktop (AVD) のメリット

Azure Virtual Desktop (AVD) 構築

事前準備

Azure 無償／有償 サブスクリプション

Microsoft 365 無償/有償 サブスクリプション

Microsoft Entra ID カスタムドメイン設定

構築

Entra Connect 同期設定

Entra Domain Services 構築

Azure Virtual Desktop (AVD) 用イメージの作成手順

Azure Virtual Desktop (AVD) ホストプール作成手順

デスク トップ アプリケーション グループへ接続ユーザーの登録

Azure Virtual Desktop (AVD) 接続手順

セキュリティ設定

Azure Virtual Desktop (AVD) のセキュリティ設定

まとめ

NOBTAの気ままにITブログ

Entra ID カスタム ドメイン用ドメインの取得

Entra ID カスタム ドメインの設定手順

まとめ

NOBTAの気ままにITブログ

Microsoft Fabric を利用するうえで必要となるライセンス

容量ライセンス

ユーザー毎のライセンス

まとめ

NOBTAの気ままにITブログ

Microsoft Fabric 基本概念

テナント

容量

ワークスペース

まとめ

NOBTAの気ままにITブログ

Microsoft Fabric メリット (後半)

Azure AI Studio, Azure OpenAI, Azure Databricks などのその他 Azureサービスから安全に OneLake 上のデータにアクセスすることが可能

Copilot in Microsoft Fabric により各ワークロードの作業の効率化が可能 (コードの自動生成など)

OneLake を 生成AI アプリケーションの RAG データソースとして利用可能

Azure AI の各種サービス (Azure OpenAI、Text Analytics、Azure AI Translator など) の事前構築済み AI モデルを Microsoft Fabric 上 (Notebook など) で利用することが可能

Microsoft Fabric データ統合の全体像

まとめ

NOBTAの気ままにITブログ

Microsoft Fabric メリット (前半)

共通のインターフェースによるデータ分析が可能

Microsoft Fabric に統合されたワークロードで Microsoft Fabric コンピューティング プールを共有して利用可能

OneLake によるデータの統合が可能

OneLake ショートカット機能によるデータアクセスが可能

まとめ

NOBTAの気ままにITブログ

SQLVM上の SQL Server 倭国語化手順

SQLVM上の SQL Server インプレース アップグレード手順

まとめ

NOBTAの気ままにITブログ

リストア ダイアログで Amazon S3 ストレージ URL 上に配置されたバックアップファイル からの データベース リストア をサポート

クエリ エディタ タブに SPID (ユーザー プロセスのセッション ID) を含めるように変更

コマンドライン から Azure Data Studio を起動する際、接続先を指定できるように変更

「データベースの作成」ダイアログから データベース を作成する際、Ledger を有効できるように改良

NOBTAの気ままにITブログ

Microsoft Fabric 試用版を利用する前提条件

Microsoft Fabric 試用版を利用する方法

Microsoft Fabric を学ぶために参考になる Microsoft Learn

まとめ

NOBTAの気ままにITブログ

Microsoft Fabric とは

統合された各ワークロードについて

Microsoft Fabric メリット

まとめ

NOBTAの気ままにITブログ

Azure Databricks とは

Azure Databricks の特徴

Azure Databricks のアーキテクチャ

Azure Databricks コントロール プレーン

Azure Databricks コンピューティング プレーン

まとめ

参考URL

NOBTAの気ままにITブログ

Azure Database for PostgreSQL とは

Azure Database for PostgreSQL 新機能 (Ignite 2023)

Premium SSD v2 P80 (プレビュー)

Azure AI 拡張機能 (プレビュー)

Azure 無償／有償サブスクリプション

Microsoft 365 無償/有償サブスクリプション

デスクトップアプリケーショングループへ接続ユーザーの登録

Entra ID カスタムドメイン用ドメインの取得

Entra ID カスタムドメインの設定手順

OneLake を生成AI アプリケーションの RAG データソースとして利用可能

Microsoft Fabric に統合されたワークロードで Microsoft Fabric コンピューティングプールを共有して利用可能

SQLVM上の SQL Server インプレースアップグレード手順

リストアダイアログで Amazon S3 ストレージ URL 上に配置されたバックアップファイルからのデータベースリストアをサポート

クエリエディタタブに SPID (ユーザープロセスのセッション ID) を含めるように変更

コマンドラインから Azure Data Studio を起動する際、接続先を指定できるように変更

「データベースの作成」ダイアログからデータベースを作成する際、Ledger を有効できるように改良

Azure Databricks コントロールプレーン

Azure Databricks コンピューティングプレーン

Near Zero ダウンタイムスケーリング (GA)

Azure Cosmos DB for MongoDB 仮想コアベクトル検索

スナップショットからの Azure Linux OS ディスクの作成

別リージョン上にコピーした Azure 仮想マシン OS ディスクから Azure 仮想マシンをデプロイ

エラー「Permissions for '*****.pem' are too open.」の意味

エラー「Permissions for '*****.pem' are too open.」の対処方法