編集

次の方法で共有

Azure 上の SAS アーキテクチャ

Azure Virtual Machines
Azure Virtual Network
Azure Files

このソリューションは、Azure で SAS 分析ワークロードを実行します。 このガイダンスでは、さまざまなデプロイ シナリオを対象にしています。 たとえば、複数のバージョンの SAS を使用できます。 SAS ソフトウェアは、自己管理型仮想マシン (VM) で実行できます。 Azure Kubernetes Service (AKS) を使用することで、コンテナー ベースのバージョンもデプロイできます。

アーキテクチャ

Azure に SAS 製品をデプロイする方法を示すアーキテクチャ図。

このアーキテクチャの Visio ファイル をダウンロードします。

ワークフロー

SAS Azure デプロイには、通常、次の 3 つのレイヤーが含まれます。

  • API または視覚化レベル。 このレイヤー内は次のとおりです。

    • メタデータ層を使用すると、クライアント アプリはデータ ソース、リソース、サーバー、ユーザーのメタデータにアクセスできます。
    • Web アプリは、中間層のインテリジェンス データへのアクセスを提供します。

  • SAS サーバーがデータを処理するコンピューティング プラットフォーム。

  • SAS が永続的ストレージに使用するストレージ層。 Azure での一般的な選択肢は次のとおりです。

    • Lustre
    • IBM Spectrum Scale
    • Network File System (NFS)

Microsoft Azure Virtual Network は、クラウド内のシステムを分離します。 そのネットワーク内は次のとおりです。

  • 近接配置グループを使用すると、VM 間の待機時間が短縮されます。
  • ネットワーク セキュリティ グループは、不要なトラフィックから SAS リソースを保護します。

前提条件

SAS ワークロードをデプロイする前に、次のコンポーネントが配置されている必要があります。

  • SAS サイズ設定チームからのサイズ設定に関する推奨事項
  • SAS ライセンス ファイル
  • リソースをデプロイするリソース グループへのアクセス
  • サイズ設定ドキュメントと VM の選択を考慮した 仮想中央処理装置 (vCPU) サブスクリプション クォータ
  • セキュリティで保護された LDAP (Lightweight Directory Access Protocol) サーバーへのアクセス

シナリオの詳細

このガイドでは、さまざまな実装について説明し、コスト、DevOps、回復性、スケーラビリティ、セキュリティの分野で優れた機能を実現するための Microsoft Azure Well-Architected Framework の考え方にも沿っています。 ただし、特定のユース ケースの追加検証については、このガイドを使用する以外に、SAS チームにお問い合わせください。

パートナーとして、Microsoft と SAS は、クラウドでイノベーションを起こしている組織のロードマップの開発に取り組んでいます。 両社は、Azure での SAS 製品とソリューションの高品質なデプロイを保証することに専心しています。

SAS の概要

SAS 分析ソフトウェアは、データから分析情報を引き出し、インテリジェントな意思決定を行うサービスとツールのスイートを提供します。 SAS プラットフォームは、データ管理、不正行為の検出、リスク分析、視覚化などの領域に対するソリューションを完全にサポートしています。 SAS は、Microsoft が検証した次の主要プラットフォームを提供します。

  • SAS Grid 9.4
  • SAS Viya

次のアーキテクチャがテストされています。

  • Linux 上の SAS Grid 9.4
  • SAS 9 Foundation
  • 対称マルチプロセッシング (SMP) と Linux 上の超並列処理 (MPP) アーキテクチャを備えた SAS Viya 3.5
  • AKS 上の MPP アーキテクチャを使用する SAS Viya 2020 以降

このガイドでは、プラットフォーム固有の情報ではなく、Azure で SAS を実行するための一般的な情報を提供します。 これらのガイドラインでは、独自のテナントを持ち Azure 上で独自の SAS ソリューションをホストしていると想定します。 SAS は、お客様に代わって Azure でソリューションをホストするのではありません。 SAS が提供する Azure ホスティング サービスと管理サービスの詳細については、SAS マネージド アプリケーション サービスに関するページを参照してください。

推奨事項

実装を設計するときは、次のセクションに示す項目を考慮してください。

SAS ドキュメントには、コアあたりの要件 (物理 CPU コアごとの要件) が用意されています。 ただし、Azure では vCPU の一覧が提供されます。 SAS での使用を推奨する VM では、物理コアごとに 2 つの vCPU があります。 その結果、vCPU 要件の値を計算するには、コア要件の値の半分を使用します。 たとえば、物理コア要件が 150 MBps である場合、vCPU あたり 75 MBps に換算されます。 Azure コンピューティングのパフォーマンスの詳細については、「Azure コンピューティング ユニット (ACU)」を参照してください。

注意

単一ノードの SAS デプロイ (かつ外部ファイル システムでない) でデータをスケールアップして保持する場合、 SAS ドキュメント では、少なくとも 150 MB/秒の帯域幅を推奨しています。 この帯域幅を実現するには、複数の P30 Premium (またはそれ以上) のディスクをストライピングする必要があります。

オペレーティング システム

Linux は、SAS ワークロードの実行に最適に動作します。 SAS では、次のオペレーティング システムの 64 ビット バージョンがサポートされます。

  • Red Hat 7以降
  • SUSE Linux Enterprise Server (SLES) 12.2
  • Oracle Linux 6 以降

特定の SAS リリースの詳細については、SAS オペレーティング システム サポート マトリックスを参照してください。 複数のマシンを使用する環境では、すべてのマシンで同じバージョンの Linux を実行するのが最善です。 Azure では、Linux 32 ビット デプロイはサポートされていません。

Azure との互換性と統合を最適化するには、Azure Marketplace のオペレーティング システム イメージから始めます。 追加の構成なしでカスタム イメージを使用すると、SAS のパフォーマンスが低下する可能性があります。

カーネルの問題

オペレーティング システムを選択する場合は、Red Hat 7.x シリーズ全体に影響するソフト ロックアップの問題に注意してください。 次のカーネルに発生します。

  • Linux 3.x カーネル
  • 4\.4 より前のバージョン

Linux と Hyper-V のメモリと I/O の管理 に関する問題が原因で、この問題が発生します。 これが発生すると、システム ログには、マスク不可能割り込み (NMI) を示す次のようなエントリが含まれます。

Message from syslogd@ronieuwe-sas-e48-2 at Sep 13 08:26:08
kernel:NMI watchdog: BUG: soft lockup - CPU#12 stuck for 22s! [swapper/12:0]

もう 1 つの問題は、以前のバージョンの Red Hat に影響します。 具体的には、次の条件を満たすバージョンで発生する可能性があります。

  • 3\.10.0 から 957.27.2 より前の Linux カーネルがある
  • NVMe (Non-Volatile Memory Express) ドライブを使用する

システムのメモリ負荷が高くなると、汎用 Linux NVMe ドライバーが書き込み操作に十分なメモリを割り当てられない可能性があります。 その結果、システムは、実際のデッドロックに由来するソフト ロックアップを報告します。

両方の問題を回避するには、カーネルをアップグレードします。 または、次の回避策を試してください。

  • 既定値 /sys/block/nvme0n1/queue/max_sectors_kb を使用する代わりに、 128 を 512 に設定します。
  • VM 内の各 NVMe デバイスと "各" VM ブートで、この設定を変更します。

次のコマンドを実行して、その設定を調整します。

# cat /sys/block/nvme0n1/queue/max_sectors_kb
512
# echo 128 >/sys/block/nvme0n1/queue/max_sectors_kb
# cat /sys/block/nvme0n1/queue/max_sectors_kb
128

VM のサイズ設定に関する推奨事項

SAS デプロイでは、多くの場合、次の VM SKU が使用されます。

Edsv5 シリーズ

Edsv5 シリーズの VM は、Viya と Grid の既定の SAS マシンです。 次の機能を提供します。

  • 制約されたコア。 このシリーズの多くのマシンでは、VM の vCPU 数を制限できます。
  • 高い CPU 対メモリ比。
  • 高スループットのローカル接続ディスク。 I/O 速度は、 SASWORK や、SAS が一時ファイルに使用する Cloud Analytics Services (CAS) のキャッシュである CAS_CACHE などのフォルダーにとって重要です。

Edsv5 シリーズの VM が使用できない場合は、前の世代を使用することをお勧めします。 Edsv4 シリーズ VM は、SAS ワークロードでテストされ、良好に機能します。

Ebsv5 シリーズ

場合によっては、ローカルに接続されたディスクに、 SASWORK または CAS_CACHE用の十分なストレージ容量がないことがあります。 より大きな作業ディレクトリを取得するには、Premium 接続ディスクを備えた Ebsv5 シリーズの VM を使用します。 これらの VM は、次の機能を提供します。

  • Edsv5 および Esv5 VM と同じ仕様
  • リモート接続ディスクに対する最大 4 GB/秒の高スループットにより、SAS の I/O ニーズに応じて、必要なだけ大きな SASWORK または CAS_CACHE が提供されます。

Edsv5 シリーズ VM で十分なストレージが提供されている場合は、コスト効率が高いため、そちらを使用することをお勧めします。

M シリーズ

多くのワークロードでは、次のような M シリーズの VM を使用します。

  • ソフトウェア アーキテクチャへの Viya アプローチを使用する SAS プログラミング ランタイム環境 (SPRE) の実装。
  • 特定の SAS Grid ワークロード。

M シリーズの VM は、次の機能を提供します。

  • 制約付きコア
  • 最大 3.8 TiB のメモリ (大量のメモリを使用するワークロードに適しています)
  • リモート ディスクに対する高スループット。ローカルに使用可能なディスクが不足している場合に、 SASWORK フォルダーに対して適切に機能します。

Ls シリーズ

特定の I/O 負荷の高い環境では、 Lsv2 シリーズ または Lsv3 シリーズ の VM を使用する必要があります。 特に、高速の待ち時間が短い I/O 速度と大量のメモリを必要とする実装は、この種類のコンピューターからメリットが得られます。 たとえば、 SASWORK フォルダーまたは CAS_CACHE を多用しているシステムがこれに含まれます。

注意

SAS は、Intel Math Kernel Library (MKL) で使用するサービスを最適化します。

  • 計算負荷の高いワークロードでは、Intel プロセッサを使用しない VM (Lsv2 と Lasv3) は避けてください。
  • AMD CPU を選択するときは、その CPU で MKL がどのように動作するかを検証します。

警告

可能な場合は、Lsv2 VM を使用しないようにしてください。 代わりに、Intel チップセットを搭載した Lsv3 VM を使用してください。

Azure では、必要に応じて SAS Viya システムをスケールアップして、期限に合わせることができます。

  • ノード プールのコンピューティング能力を増やします。
  • Azure Kubernetes Service クラスター オートスケーラー を使用してノードを追加し、水平方向に拡張します。
  • インフラストラクチャを一時的にスケールアップして、SAS ワークロードを高速化します。

注意

コンピューティング コンポーネントをスケーリングするときは、記憶域 I/O ボトルネックを回避するために、記憶域をスケールアップすることも検討してください。

Viya 3.5 および Grid ワークロードでは、Azure は現在、水平スケーリングまたは垂直スケーリングをサポートしていません。 Viya 2022 では、水平方向のスケーリングがサポートされています。

ネットワークと VM の配置に関する考慮事項

SAS ワークロードは、多くの場合に頻繁に発生します。 その結果、膨大な量のデータが転送される可能性があります。 すべての SAS プラットフォームで、次の推奨事項に従って Chatter の影響を軽減します。

  • SAS とストレージ プラットフォームを同じ仮想ネットワークにデプロイします。 このアプローチでは、ピアリング コストの発生を回避することもできます。
  • ノード間の待機時間を短縮するために、SAS マシンを 近接配置グループ に配置します。
  • 可能な場合は、SAS マシンと VM ベースのデータ ストレージ プラットフォームを同じ近接配置グループにデプロイします。
  • 複数のゾーンにまたがる待機時間を回避するには、SAS とストレージ アプライアンスを同じ可用性ゾーンに展開します。 ソリューション コンポーネントが同じゾーンにデプロイされていることを確認できない場合は、Azure サポートにお問い合わせください。

SAS には、VM に対して固有の完全修飾ドメイン名 (FQDN) 要件があります。 コンピューターの FQDN を正しく設定し、ドメイン ネーム システム (DNS) サービスが機能していることを確認します。 名前は Azure DNS で設定できます。 hosts 構成フォルダー内の etc ファイルを編集することもできます。

注意

SAS デプロイ内のすべてのノードで高速ネットワークを有効にします。 この機能をオフにすると、パフォーマンスが大幅に低下します。

VM で高速ネットワークを有効にするには、次の手順を実行します。

  1. VM の割り当てを解除するには、Azure CLI で次のコマンドを実行します。

    az vm deallocate --resource-group <resource_group_name> --name <VM_name>

  2. VM をオフにします。

  3. 次のコマンドを CLI で実行します。

    az network nic update -n <network_interface_name> -g <resource_group_name> --accelerated-networking true

Azure でデータを移行する場合、または SAS を操作する場合は、オンプレミスのリソースを Azure に接続するために、次のいずれかのソリューションを使用することをお勧めします。

Azure の運用 SAS ワークロードの場合、ExpressRoute は、これらの利点をサイト間 VPN よりも提供する、プライベートで専用の信頼性の高い接続を提供します。

  • より高速
  • より短い待機時間
  • セキュリティの強化

SAS アプリケーションと非 SAS アプリケーション間では、待機時間の影響を受けやすいインターフェイスに注意してください。 データ ソースとシンクを SAS の近くに移動することを検討してください。

ID 管理

SAS プラットフォームでは、ローカル ユーザー アカウントを使用できます。 また、セキュリティで保護された LDAP サーバーを使用してユーザーを検証することもできます。 ドメイン コントローラーは Azure で実行することをお勧めします。 次に、ドメイン参加機能を使用して、セキュリティ アクセスを適切に管理します。 ドメイン コントローラーをセットアップしていない場合は、 Microsoft Entra Domain Servicesの展開を検討してください。 ドメイン参加機能を使用する場合は、コンピューター名が 15 文字の制限を超えていないことを確認してください。

注意

環境によっては、オンプレミスと Azure でホストされている SAS 環境の間で、オンプレミスの接続または共有データセットのための要件がある場合があります。 このような状況では、Azure でドメイン コントローラーをデプロイすることを強くお勧めします。

Microsoft Entra Domain Services のフォレストは、Microsoft Entra デバイスに対して認証できるユーザーを作成しますが、オンプレミスのリソースに対してではなく、この逆もできません。

データ ソース

SAS ソリューションは、多くの場合、複数のシステムからのデータにアクセスします。 これらのデータ ソースは次の 2 つのカテゴリに分類されます。

  • SAS が SASDATA フォルダーに格納する SAS データセット
  • データベース。SAS は、多くの場合に大きな負荷を課す

パフォーマンスを最大限高めるためのヒントを示します。

  • SAS インフラストラクチャにできるだけ近い場所に、データ ソースを配置します。
  • データ ソースと SAS インフラストラクチャの間のネットワーク ホップとアプライアンスの数を制限します。

注意

SAS インフラストラクチャの近くにデータ ソースを移動できない場合は、これらに対して分析を実行しないでください。 代わりに、まず抽出、変換、読み込み (ETL) プロセスを実行し、後で分析を実行します。 負荷が高いデータ ソースにも同じ方法を使用します。

SAS データ用の永続的なリモート ストレージ

SAS と Microsoft は、SAS データセットをホストするために使用できる一連のデータ プラットフォームをテストしました。 SAS のブログには、パフォーマンス特性などの結果が詳細に記載されています。 テストには、次のプラットフォームが含まれます。

SAS には、Viya アーキテクチャと Grid アーキテクチャ用のパフォーマンス テスト スクリプトが用意されています。 SAS フォーラム では、これらのプラットフォームでのスクリプトを使用したテストに関するドキュメントを提供します。

IBM Spectrum Scale (GPFS) によって満たされる Sycomp Storage

IBM Spectrum Scale によって満たされる Sycomp Storage がパフォーマンスの期待値を達成する方法については、 SAS Grid に対する Sycomp の SAS レビューに関するページを参照してください。

サイズ設定については、Sycomp は次の推奨事項を挙げています。

  • コアあたり 150 MBps の構成を使用して、8 コアあたり 1 つの GPFS スケール ノードを提供します。
  • インスタンスごとに最小 5 つの P30 ドライブを使用します。
Azure Managed Lustre

Azure Managed Lustre は、ハイパフォーマンス コンピューティング (HPC) および AI ワークロード向けに作成されたマネージド ファイル システムです。 Managed Lustre は、SAS 9 と Viya のワークロードを並行して実行できます。 ファイル システムのパフォーマンスを最適化するには、次のレコメンデーションに従ってください。

  • Managed Lustre をデプロイするときは、すべてのクライアント ノードでチューニングを実行して、Lustre クライアントの先読みを増やし、SAS I/O パターンの同時実行性を最適化します。 このチューニングを実行するには、次のコマンドを実行します。

    lctl set_param mdc.*.max_rpcs_in_flight=128 osc.*.max_pages_per_rpc=16M osc.*.max_rpcs_in_flight=16 osc.*.max_dirty_mb=1024 llite.*.max_read_ahead_mb=2048 osc.*.checksums=0  llite.*.max_read_ahead_per_file_mb=256

  • すべての SAS VM で 高速ネットワーク を有効にします。

  • ネットワーク遅延を減らすには、Managed Lustre がデプロイされているのと同じ可用性ゾーンに SAS VM を配置します。

Azure Files プレミアム層

Azure Files プレミアム レベルは、NFS 4.1 プロトコルをサポートするマネージド サービスです。 コスト効率、弾力性、パフォーマンスに優れ、POSIX 準拠のファイル システムを提供します。 NFS 共有の IOPS とスループットは、プロビジョニングされた容量に合わせてスケーリングされます。 SAS は Azure Files のプレミアム レベルを徹底的にテストし、SAS インストールを実行するにはパフォーマンスが十分すぎることを発見しました。

nconnect を使用するとパフォーマンスが向上します。 このマウント オプションは、IO 要求を複数のチャネルに分散します。 詳細については、 NFS パフォーマンスを参照してください。

Azure Files で NFS Azure ファイル共有を使用する場合は、次の点を考慮してください。

  • パフォーマンス要件を満たすようにプロビジョニングされた容量を調整します。 NFS 共有の IOPS とスループットは、プロビジョニングされた容量に合わせてスケーリングされます。 詳細については、 NFS パフォーマンスを参照してください。
  • 最適なパフォーマンスの並列チャネル使用のために、マウント内で nConnect を nconnect=4 の設定で使用します。
  • 先読み設定を rsize と wsizeの 15 倍に最適化します。 ほとんどのワークロードでは、 rsize と wsize を 1 MB、 read-ahead を 15 MB に設定することをお勧めします。 詳細については、「先読みサイズの増加」を参照してください。
Azure NetApp Files (NFS)

SAS テストでは、 SAS グリッドに対して NetApp のパフォーマンスが検証されています。 具体的には、このテストでは、Azure NetApp Files は、複数のマシンにわたって最大 32 個の物理コアを持つ SAS Grid クラスターの有望なプライマリ ストレージ オプションであることが判明しています。 NetApp が提供する最適化と Linux 機能 を使用すると、Azure NetApp Files は、複数のマシンにわたる最大 48 個の物理コアのクラスターの主なオプションになります。

このサービスを使用するときは、次の点を考慮してください。

  • Azure NetApp Files は、Viya のデプロイに適しています。 Viya の CAS キャッシュには Azure NetApp Files を使用しないでください。書き込みスループットが不十分であるためです。 可能であれば、代わりに VM のローカル エフェメラル ディスクを使用します。
  • Grid 9.4 を備えた SAS 9 Foundation では、 SASDATA ファイルに SAS を使用した Azure NetApp Files のパフォーマンスは、最大 32 個の物理コアのクラスターに適しています。 チューニング を適用すると、コア数は 48 個に増加します。
  • パフォーマンスを向上させるには、Azure NetApp Files をデプロイするときに、少なくとも Premium または Ultra ストレージ層の サービス レベル を選択します。 非常に大きなボリュームの場合は、Standard サービス レベルを選択できます。 Premium レベルから開始し、後で Ultra または Standard に切り替えることを検討してください。 サービス レベルの変更はオンラインで実行でき、中断やデータ移行は不要です。
  • Azure NetApp Files では、読み取りパフォーマンスと書き込みパフォーマンスが 異なります。 SAS の書き込みスループットは約 1600 MiB/秒で限界に達しますが、読み取りスループットはそれを超えて約 4500 MiB/秒になります。 継続的に高い書き込みスループットが必要な場合、Azure NetApp Files は適していない可能性があります。
NFS 先読みチューニング

SAS ワークロードのパフォーマンスを向上させるには、NFS 共有のマウント方法に影響する read-ahead カーネル設定を調整することが重要です。 先読みが有効になっている場合、Linux カーネルはアプリケーションによる実際の I/O の前にブロックを要求できます。 その結果、シーケンシャル読み取りスループットが向上します。 ほとんどの SAS ワークロードは、さらなる処理のために多数の大きなファイルを読み取るため、SAS は大きな先読みバッファから大きなメリットを得ます。

Linux カーネル 5.4 以降では、デフォルトの先読みが 15 MB から 128 KB に変更されました。 新しいデフォルトでは、SAS の読み取りパフォーマンスが低下します。 パフォーマンスを最大化するには、SAS Linux VM の先読み設定を増やします。 SAS と Microsoft では、先読みを rsize と wsizeの 15 倍に設定することをお勧めします。 理想的には、 rsize と wsize は両方とも 1 MB で、 read-ahead は 15 MB です。

仮想マシンで先読みを設定するのは簡単です。 udev ルールを追加する必要があります。

Kubernetes の場合、このプロセスはポッドではなくホストで実行する必要があるため、より複雑になります。 SAS は、ポストの先読み値を自動的に設定する、AKS 上の Viya 用のスクリプトを提供します。 詳細については、「Kubernetes 上の SAS Viya で Azure Files の NFS Premium 共有を使用する」を参照してください。

その他のデータ ソース

SAS プラットフォームは、さまざまなデータ ソースをサポートしています。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

SAS ワークロードの出力は、組織の重要な資産の 1 つになり得ます。 SAS 出力は内部効率に関する洞察を提供し、レポート戦略において重要な役割を果たすことができます。 次は、SAS アーキテクチャへのアクセスをセキュリティで保護することが重要です。 この目標を達成するには、セキュリティで保護された認証を使用し、ネットワークの脆弱性に対処します。 暗号化を使用して、アーキテクチャに出入りするすべてのデータを保護します。

Azure は、サービスとしてのインフラストラクチャ (IaaS) クラウド モデルを使用して SAS を提供します。 Microsoft は、次のレベルでセキュリティ保護をサービスに構築します。

  • 物理データセンター
  • 物理ネットワーク
  • 物理ホスト
  • ハイパーバイザー

SAS のゲスト オペレーティング システムなど、ハイパーバイザーより上の領域に対して選択したサービスとテクノロジを慎重に評価します。 アーキテクチャに適切なセキュリティ コントロールを提供するようにしてください。

現在、SAS は Microsoft Entra ID を完全にはサポートしていません。 SAS の視覚化層での認証には、Microsoft Entra ID を使用できます。 ただし、バックエンド認証の場合は、オンプレミスの認証と同様の戦略を使用します。 IaaS リソースを管理する場合は、Microsoft Entra ID を使用して、Azure portal に対する認証と認可を行うことができます。 Microsoft Entra Domain Services を使用している場合、ゲスト アカウントを認証することはできません。 ゲストがサインインしようとすると失敗します。

ネットワーク セキュリティ グループ を使用すると、 仮想ネットワーク内のリソースとの間のネットワーク トラフィックをフィルター処理できます。 これらのグループを使用して、SAS サービスへのアクセスを許可または拒否するルールを定義できます。 たとえば、次のようになります。

  • オンプレミスの IP アドレス範囲から CAS ワーカー ポートへのアクセス権を付与します。
  • インターネットからの SAS サービスへのアクセスをブロックします。

オペレーティング システム内の暗号化には Azure Disk Encryption を使用できます。 このソリューションでは、Linux の DM-Crypt 機能を使用します。 ただし、現在は Azure Disk Encryption を使用しないことをお勧めします。 特に SASWORK ファイルをローカルで使用する場合、パフォーマンスが大幅に低下する可能性があります。

Azure Disk Storage のサーバー側暗号化 (SSE) では、データが保護されます。 また、組織のセキュリティとコンプライアンスのコミットメントを満たすのにも役立ちます。 Azure マネージド ディスクでは、SSE はデータをクラウドに永続化するときに、保存データを暗号化します。 この動作は、既定で OS とデータ ディスクの両方に適用されます。 マネージド ディスクを暗号化するには、プラットフォームで管理されたキーまたは独自のキーを使用できます。

インフラストラクチャを保護する

デプロイする Azure リソースへのアクセスを制御します。 Azure のすべてのサブスクリプションは、Microsoft Entra テナント との間に 信頼関係 があります。 Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、ご自分の組織内のユーザーに Azure リソースに対する適切なアクセス許可を付与します。 特定のスコープでユーザーまたはグループに Azure のロールを割り当てて、アクセス権を付与します。 スコープには、サブスクリプション、リソース グループ、または 1 つのリソースを指定できます。 インフラストラクチャに対するすべての変更を必ず監査してください。

Azure Bastion を介して VM へのリモート アクセスを管理します。 次のコンポーネントをインターネットに公開しないでください。

  • VM
  • Secure Shell プロトコル (SSH) ポート
  • リモート デスクトップ プロトコル (RDP) ポート

このシナリオのデプロイ

コードとしてのインフラストラクチャ (IaC) プロセスを使用してワークロードをデプロイすることをお勧めします。 SAS ワークロードは、手動デプロイで発生することがよくある設定によって影響を受けやすく、生産性が低下する可能性があります。

環境を構築するときは、 CoreCompete SAS 9 または Viya on Azureのクイックスタート リファレンス資料を参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

作業の開始に役立つ次のリソースを参照してください。

オートメーション プロセスの詳細については、SAS で提供される次のテンプレートを参照してください。