Azure Arcを活用したSQLサーバの管理

SQLサーバ環境のコストや運用効率は、多くのIT担当者にとって大きな課題です。
本記事では、Azure Arcを活用したSQLサーバの管理パターンの技術検証を行い、Azure Arcの特長を活かした効率的な運用手法をご紹介します。

1. Azure Arcとは

Azure Arcは、オンプレミスや各社クラウドのサーバをAzure Portalから一元管理し、Azure MonitorやLog Analyticsによるログ収集・アラート運用を統合することで運用負荷の削減を実現するとともに、コストとリスクの予見性向上を実現するプラットフォームです。

2. Azure Arcで従量課金のSQL Serverを実装すべきケース

以下のようなケースでは、 Azure Arcで従量課金のSQL Serverを実装するのが有効です。

• サーバコストや台数の増減が予想される場合など、年数契約や初期一括購入リスクを抑えたいプロジェクト
• セキュリティ監査やポリシーを全リソースで一元的に徹底したい場合
• 分散した拠点やエッジ環境の集約など、クラウド移行の過渡期に統一の運用基盤を先行整備したい場合など

3. SQLサーバの構成例、Azure Arc活用時の比較

従来のライセンス購入方式

SQL Serverライセンスを購入し長期間利用する場合、総コストは安くなりますが、ソフトウェア更新やバックアップなどの運用もすべて自社で実装・管理する必要があります。

費用イメージ（16 vCPU/128GB RAM クラス想定）

サーバ費 (AWS)	SQLライセンス (Azure)	月額計 (1台*730h換算)	備考
約$736/月	0（初期一括）	約$736/月	・買い切り価格は16コア分で約$28,688 ・完全自己管理

Azure ArcでのSQLサーバの管理方式

Azure ArcはAWS EC2のようなバーチャルマシンやオンプレサーバも一元管理可能なため将来的な拡張性や安定運用に期待できます。

費用イメージ（16 vCPU/128GB RAM クラス想定）

サーバ費 (AWS)	SQLライセンス (Azure)	月額計 (1台*730h換算)	備考
約$736/月	約$1,151/月	約$1,887/月	Azure Arcライセンスでセキュリティとコストを柔軟管理

4. SQLサーバ管理におけるAzure Arcの技術検証

検証のシナリオ

• Azure Arcをサーバ（検証ではAWS EC2）に接続します。
• Azure上でサーバ監視の設定を行います。
• サーバへの不正アクセスを模倣します。
• Azure Arc上でセキュリティの監視ができることを確認します。

検証手順

1.Azure Arcの設定を作成します。
Azure PortalでSQL Server – Azure Arcを選択します。

以下の情報を入力します。
・サブスクリプション：ご利用のサブスクリプションを選択します。
・リソース グループ： 新規作成または既存のリソースグループを選択します。
・リージョン： Azure Arcと同じリージョンを選択することを推奨します。
・オペレーションシステム：接続対象のOSを選択します。

ライセンスの種類でPAYGを選択することでSQL Serverの利用料金がAzureでの従量課金となります。

設定のページを進めていくと「スクリプトの実行」タブが出てくるのでスクリプトをコピーします。

2.サーバPC（検証ではAWS EC2）でAzureへの接続を行います。リモートデスクトップでサーバPCにアクセスし、PowerShellにコピーしたコードを実行することでサーバPCとAzureの連携作業が自動でスタートします。

途中でAzureへ接続するための認証があります。
表示されるリンクを開くとコード入力を求められる画面が開くのでコード（下図赤線塗りつぶし部分）をコピーしてログインします。

認証が成功すれば続きの作業が続けられ、下記メッセージが表示されれば完了です。

3.Azure上でサーバ監視の設定を行います。
再度Azure Portalを確認するとサーバPCとSQLサーバの項目が自動で作成されます。

Azure Portalで「Log Analytics ワークスペース」を検索し、「＋作成」ボタンを選択します。

以下の情報を入力します。
・サブスクリプション：ご利用のサブスクリプションを選択します。
・リソース グループ：新規作成または既存のリソースグループを選択します。
・名前：ワークスペースに一意の名前を付けます。(例：my-log-analytics-workspace)
・リージョン：Azure Arcと同じリージョンを選択することを推奨します。

データ収集ルール (DCR) を作成します。
Azure Portalで「監視」を選択し、「設定」「データ収集ルール」「＋追加」を選択します。

「基本」タブで以下の情報を入力します。
・ルール名： ルールを識別するための名前を入力します。(例： dcr-windows-event-collection)。
・サブスクリプション：ご利用のサブスクリプションを選択します。
・リソース グループ：DCR を保存するリソースグループを選択します。
・リージョン：Log Analytics ワークスペースと同じリージョンを選択します。
・プラットフォームの種類：監視対象のプラットフォームを選択します。

「リソース」タブに移動し、「+ リソースの追加」でイベントデータを収集するマシンを選択します。

「収集と配信」タブで「+ データ ソースの追加」をクリックします。
「データ ソースの種類」を選択し、収集したいログレベルを選択します。

「次へ： 宛先」で次に進み、作成したLog Analytics ワークスペースを選択します。

設定を進めてデータ収集ルールの作成を完了させます。
作成したLog Analytics ワークスペースを開き、「ログ」「テーブル」の「LogManagement」「Event」の右端の実行をクリックします。
※データ収集ルールを作成してからLogManagementが出てくるまで数分かかります。

ログが表示されます。

KQL モードを使うと取得するログデータをフィルタリングできます。

参考

Event
| where Computer == "EC2AMAZ-1QBA56O"
| where EventLog == "Application"
| where EventID in ("18454", "18456")
| extend TimeJST = datetime_add("hour", 9, TimeGenerated)
| project TimeJST, EventID, RenderedDescription
| order by TimeJST desc

EventID “18454”はSQL認証によるログイン成功、EventID “18456”はログイン失敗のIDです。

Log Analytics ワークスペースをPower BIのデータソースとしても設定できます。

4.サーバへの不正アクセスを模倣します。
クライアントPCでPowerShellを開き、今回作成した検証用のSQLサーバに簡易的な辞書攻撃を仕掛けてみます。

5.Azure Arc上でセキュリティが監視できることを確認します。
再度ログを確認すると特定のユーザーでログイン失敗が頻発していることが確認できます。

今回の検証ではEventID “18456”で監視していますが他のEventIDもAzure Arc経由で一括監視が可能です。

5. まとめ

今回ご紹介したAzure Arc従量課金SQLによる構築・運用の技術検証によりサーバ導入のコストメリットと柔軟な運用性を両立できることが確認できました。
これまで複雑になりがちだったSQLサーバのライセンス管理や運用面、セキュリティもAzure Arcを利用することで効率化が期待でき、実際の現場でもスムーズな管理が可能です。
Azure Arcによるサーバの一元管理にご興味がある方、今後のSQLサーバの構成や運用方法に課題をお持ちの方は、ぜひシステムエグゼまでお気軽にお問い合わせください。