次の方法で共有

Synapse 実装成功の技法: サーバーレス SQL プールの設計を評価する

  • [アーティクル]

注意

この記事は、「設計による Azure Synapse 実装の成功」シリーズの記事の一部です。 シリーズの概要については、設計による Azure Synapse 実装の成功に関する記事を参照してください。

サーバーレス SQL プールの問題を特定し、ガイドラインと要件を満たしていることを検証するためには、その設計を評価しなければなりません。 ソリューション開発を開始する前に設計を評価することで、欠陥や予期しない設計変更を回避できます。 これにより、プロジェクトのタイムラインと予算を保護できます。

最新のデータ、分析プラットフォーム、サービスのストレージとコンピューティングのアーキテクチャの分離は、トレンドであり、頻繁に使われるパターンとなっています。 ストレージとコンピューティングの独立したオンデマンド スケーリングが可能となり、コストを削減し、柔軟性を向上させます。 Synapse SQL サーバーレスでは、データ レイク データへのクエリを直接実行する機能を追加することで、このパターンを拡張します。 セルフサービスの種類のワークロードを使う場合は、コンピューティング管理について懸念する必要はありません。

フィット ギャップ分析

Azure Synapse 内での SQL サーバーレス プールの実装を計画する場合は、まず、サーバーレス プールがワークロードに適していることを確認する必要があります。 コストの最適化、オペレーショナル エクセレンス、パフォーマンス効率、信頼性、セキュリティを考慮する必要があります。

オペレーショナル エクセレンス

オペレーショナル エクセレンスについては、次の点を評価します。

  • ソリューション開発環境: この技法には、 ソリューション開発環境の評価があります。 ソリューション開発をサポートするように環境 (開発、テスト、生産) がどのように設計されているかを特定します。 通常、生産環境と非生産環境 (開発およびテスト用) があります。 Synapse ワークスペースはすべての環境に存在します。 ほとんどの場合、生産用と開発/テスト用のユーザーとワークロードを分離する必要があります。
  • Synapse ワークスペースの設計: この技法には、Synapse ワークスペース設計の評価があります。 ソリューション用にワークスペースがどのように設計されているかを特定します。 設計について理解し、ソリューションが 1 つのワークスペースを使うのかどうか、また、複数のワークスペースがソリューションの一部を形成するのかどうかを確認します。 なぜ 1 つまたは複数のワークスペースデザインが選択されたのかを把握します。 厳格なセキュリティ境界を適用するために複数ワークスペースの設計が選択されることが多くあります。
  • 展開: SQL サーバーレスは、すべての Synapse ワークスペースでオンデマンドで使用できるため、特別なデプロイ アクションは必要ありません。 サービスと、それが接続される Azure Data Lake Storage Gen2 (ADLS Gen2) アカウントとの地理的な近さを確認します。
  • 監視: 組み込みの監視で十分かどうか、および履歴ログ データを保存するために外部のサービスを配置する必要があるかどうかを確認します。 ログ データにより、パフォーマンスの変化が分析でき、特定の状況に対してアラートまたはトリガーされるアクションを定義できます。

パフォーマンス効率

従来のデータベース エンジンとは異なり、SQL サーバーレスは独自に最適化されたストレージ レイヤーに依存しません。 そのため、そのパフォーマンスは、データが ADLS Gen2 でどのように編成されているかに強く依存します。 パフォーマンス効率を見るためには、次の点を評価します。

  • データ インジェスト: データがどのようにデータ レイクに保存されるかを確認します。 ファイル サイズ、ファイルの数、フォルダー構造、これらはすべてパフォーマンスに影響します。 一部のファイル サイズは、SQL サーバーレスで動作する可能性がある一方で、他のエンジンやアプリケーションによる効率的な処理や使用における問題を引き起こす可能性があることに注意してください。 SQL サーバーレスやソリューションの一部を形成するその他のデータ ツールを含むすべてのデータ コンシューマーに対して、データ ストレージの設計を評価し、検証する必要があります。
  • データの配置: 設計において、データ配置のための共通パターンが統一して定義されているかどうかを評価します。 ディレクトリの分岐がセキュリティ要件をサポートできることを確認します。 時系列データを整理するのに役立つ共通のパターンがいくつかあります。 どれを選んだとしても、他のエンジンやワークロードでも動作することを確認します。 また、Spark アプリケーションと外部テーブルに対して、パーティションの自動検出に役立つかどうかを検証します。
  • データ形式: ほとんどの場合、SQL サーバーレスは Parquet 形式を用いることにより、機能面で最適なパフォーマンスと優れた互換性を提供します。 パフォーマンスと互換性の要件を確認します。Parquet は、(分析に必要な列のみを読み取ることにより) IO の圧縮と削減が向上するため、パフォーマンスを向上させますが、より多くのコンピューティング リソースが必要になります。 また、一部のソース システムでは、エクスポート形式として Parquet がネイティブにサポートされていないため、パイプラインやアーキテクチャ全体の依存関係における変換手順が増える可能性があります。
  • 探索: 業種によってさまざまです。 しかし、多くの場合、最も頻繁に実行されるクエリには、共通のデータ アクセス パターンがあります。 通常、パターンには、フィルター処理と、日付、カテゴリ、または地理的地域による集計が含まれます。 最も一般的なフィルター条件を特定し、最も頻繁に実行されるクエリによって読み取り/破棄されるデータの量に関連付けます。 データ レイクの情報が、探索の要件と期待に応えるように編成されているかどうかを検証します。 設計および評価で特定されたクエリについては、OPENROWSET パス パラメーターで不要なパーティションを削除できるかどうか、または外部テーブルがある場合は、より多くのインデックスを作ることが役立つかどうかを確認します。

[信頼性]

信頼性を見るためには、次の点を評価します。

  • 可用性: 評価ステージ中に特定されたすべての可用性要件を検証します。 SQL サーバーレスには特定の SLA はありませんが、クエリの実行には 30 分のタイムアウトがあります。 評価結果から実行時間が最も長いクエリを特定し、サーバーレス SQL 設計を照合して検証します。 30 分のタイムアウトは、ワークロードの期待を破り、サービスの問題として表示される可能性があります。
  • 一貫性: SQL サーバーレスは、読み取りワークロードを主目的として設計されています。 そのため、データ レイク データのプロビジョニングと形成プロセス中にすべての一貫性チェックが実行されたかどうかを検証します。 トランザクションに対して ACID (原子性、整合性、分離性、持続性) の保証のサポートを提供する Delta Lake オープンソース ストレージ レイヤーなどの新しい機能を常に把握してください。 この機能により、効果的な ラムダまたはカッパ アーキテクチャ を実装して、ストリーミングとバッチの両方のユース ケースをサポートできます。 プロジェクトのタイムラインやコストを犠牲にすることなく、新しい機能を適用する機会について設計を評価してください。
  • バックアップ: 評価中に特定されたディザスター リカバリー要件について確認します。 復旧のための SQL サーバーレス設計に対して検証をおこないます。 SQL サーバーレス自体には独自のストレージ レイヤーがないため、データのスナップショットとバックアップ コピーの処理をおこなう必要があります。 サーバーレス SQL によってアクセスされるデータ ストアは外付け (ADLS Gen2) です。 これらのデータセットについて、プロジェクトのリカバリー設計を確認します。

セキュリティ

柔軟なセキュリティ基盤を構築するには、データの編成が重要です。 ほとんどの場合、プロセスとユーザーが異なると、データ レイクまたは論理データ ウェアハウスの特定のサブ領域に対して、異なるアクセス許可とアクセス権が必要になります。

セキュリティについては、次の点を評価します。

  • データ ストレージ: 評価ステージで収集した情報をもとに、一般的な Raw、Stage、およびキュレーションされたデータ レイク領域を、独立したストレージ アカウントではなく同じストレージ アカウントに配置する必要があるかどうかを特定します。 後者は、ロールとアクセス許可の観点から柔軟性が向上する可能性があります。 また、アーキテクチャで負荷の高い同時読み取り/書き込みワークロード (リアルタイムや IoT シナリオなど) をサポートする必要がある場合に必要になる可能性がある、1 秒あたりの入出力操作 (IOPS) 能力の向上にもつながります。 サンドボックス領域とマスター データ領域を別々のストレージ アカウントに保持して、さらに分離する必要があるかどうかを検証します。 ほとんどのユーザーはデータの更新まや削除をおこなう必要がないため、サンドボックス領域とプライベート領域を除き、データ レイクへの書き込みアクセス許可は必要ありません。
  • 評価情報から、Always Encrypted、 動的データ マスク、 行レベルセキュリティなどのセキュリティ機能に依存している要件がないかを特定します。 OPENROWSET 関数と共に使われる場合など、特定のシナリオにおけるこれらの機能の可用性を検証します。 必要とされる可能性のある回避策を予測します。
  • 評価情報から、最適な認証方法を特定します。 Microsoft Entra サービス プリンシパル、共有アクセス署名 (SAS) について、また、認証パススルーをいつどのように使って、顧客が選択した探索ツールに統合できるかを検討してください。 設計を評価し、設計の一部として最適な認証方法であることを検証します。

その他の考慮事項

設計を確認し、ベスト プラクティスと推奨事項が設定されているかどうかを確認します。 述語のプッシュダウンが正しく機能することを確実にするために、フィルターの最適化と照合順序に特に注意してください。

次の手順

''Azure Synapse の設計上の成功'' シリーズの次の記事では、Spark プールの設計を評価して、問題の特定や、ガイドラインと要件を満たしていることの検証を行う方法について学習します。