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

サーバーレス 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 パス パラメーターで不要なパーティションを削除できるかどうか、または外部テーブルがある場合は、インデックスを追加作成すると役立つかどうかを確認します。

Reliability

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

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

セキュリティ

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

セキュリティを確保するために、次の点を評価します。

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

その他の考慮事項

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

次のステップ

Azure Synapse success by design シリーズの次の記事では、Spark プールの設計を評価して問題を特定し、それがガイドラインと要件を満たしていることを検証する方法について説明します。