フェーズ 8: コンピュート構成の設計

このフェーズでは、パフォーマンス、コスト、セキュリティを最適化するためにコンピュート リソースとワークスペースの設定を設計します。

Databricks 、サーバーレス コンピュートを主なオプションとして使用することをお勧めします。 設定不要で、常に利用可能で、ワークロードに応じて数秒で自動的にスケーリングします。 サーバレスがあなたのユースケースをサポートしていない場合にのみ、クラシック コンピュートを手動で設定してください。

クラスターサイズ決定戦略の設計

クラシックなコンピュート ワークロードの場合は、クラスター サイズ設定のベスト プラクティスに従って、ワークロードの適切な開始点を見つけます。

クラスターのサイズ決定に関する考慮事項

• ワークロードの種類 ：バッチ処理には、より大規模なクラスターが必要です。インタラクティブなワークロードはオートスケールの恩恵を受けます。
• データ量 ：サイズは、想定されるデータ量と並列処理の要件に基づいて決定されます。
• パフォーマンス要件 ：コストとクエリ遅延のバランス。
• オートスケール : 需要が変動するワークロードに対してオートスケールを有効にします。
• インスタンスタイプ ：CPU、メモリ、I/Oの要件に基づいてインスタンスタイプを選択します。

クラスターサイズパターン

• 小規模クラスター （2～8ノード）：開発、テスト、小規模データセット向け。
• 中規模クラスター (8 ～ 32 ノード): 本番運用ETLおよびアナリティクスのワークロード。
• 大規模クラスター （32ノード以上）：大規模バッチ処理および機械学習トレーニング。

クラスターサイジングのベストプラクティス

• ベースライン構成から開始し、パフォーマンス メトリクスに基づいて反復します。
• オートスケールを使用して、変動するワークロードを効率的に処理します。
• クラスターの使用率メトリクス (CPU、メモリ、I/O など) を監視して、クラスターのサイズを適切に調整します。
• コスト削減のため、耐障害性の高いワークロードにはスポットインスタンス／プリエンプティブインスタンスを使用してください。
• クラスターのサイジングに関する決定とパフォーマンスのベースラインを文書化します。

クラスターのサイジングに関する詳細なガイダンスについては、 「コンピュート構成の推奨事項」を参照してください。

SQLウェアハウスのサイジング戦略を設計する

データサイエンスチームは通常小規模だが、ビジネスインテリジェンス（BI）のユースケースでは、数千人ものアナリストが関わることが多い。これほど多くのユーザーをサポートするために、Databricks SQLは、次の3つの主要な要素に基づいてクラスターを追加または削除する自動スケーリングメカニズムを使用しています。

• クエリスループット ：現在実行中のクエリの数はいくつですか？
• キューサイズ ：処理待ちのクエリはいくつありますか？
• 予測需要 ：今後2分間の推定作業負荷。

基本的に、Databricksは、現在のハードウェアでは既存および今後のクエリを十分に高速に処理できないと判断した場合、クラスターを追加します。

適切なSQLウェアハウス構成を選択してください

適切なセットアップを選択するには、コンピュート サイズ (電力) とコンピュート カウント (同時実行性) のバランスをとる必要があります。

サイズの選択（XS～XL）

クラスターの「T シャツ サイズ」によって、クエリごとにどの程度のコンピュート パワーが利用できるかが決まります。

• 小規模ティア（XS、S） ：シンプルで高速なクエリに最適です。基本的なダッシュボードには最も費用対効果が高い。
• 大規模ティア（L、XL） ：大規模なデータセットを処理する複雑で負荷の高いクエリにおいて、パフォーマンスのボトルネックを防ぐために必要です。

カウントの選択（同時実行）

コンピュート リソースの数によって、サポートできる同時ユーザーの数が決まります。

• 経験則 : クラスタごとにおよそ 10 個のライブラリ クエリを計画します。
• 高同時実行性 ：小さなクエリを実行するユーザーが多数いる場合は、多数の小さな…を使用します。
• 同時実行数が少ない場合 ：少数のユーザーが大規模なクエリを実行している場合は、少数の大きな を使用します。

要約 ：サイズを大きくすることで、個々のクエリの処理速度を向上させます。同時接続ユーザー数を増やす。

SQLウェアハウスのサイジングに関するベストプラクティス

• サーバーレスSQLウェアハウスから始めます (サイジングは必要ありません)。
• クラシックなSQLウェアハウスの場合は、中程度のサイズから始めて、クエリ パターンに基づいて調整します。
• クエリのパフォーマンスとキューイングのメトリクスを監視します。
• 異なるユースケース（アドホックな利用とレポート作成）に応じて、複数のデータウェアハウスを使用する。
• 異なるユーザーグループ向けのパフォーマンスSLAを文書化する。

クラスターポリシー戦略の設計

クラスターポリシーを使用することで、Databricksの管理者は起動されるクラスターの多くの側面を制御できます。クラスターポリシーはすべての組織に推奨されます。 一般的なパターンは以下のとおりです。

クラスターポリシーの使用例

• ユーザーを規定の設定に制限する ：利用可能なインスタンスタイプ、Databricksのバージョン、インスタンスサイズなど。
• ユーザーインターフェースを簡素化する ：一部の値を固定または非表示にする。
• コスト管理 ：クラスターごとの最大コストを制限することによって。
• コンプライアンスを強制する : 外部メタストアまたは特定のクラスタータグに企業ポリシーに準拠することを要求します。

クラスターポリシーのパターン

• 開発ポリシー : 開発とテストのための、小規模でコスト効率の高いクラスター。
• 本番運用ポリシー : 特定のインスタンス タイプとタグを備えた、より大規模で強力なクラスター。
• MLポリシー : MLランタイムを備えた GPU 対応クラスター。
• スポット/プリエンプティブポリシー ：耐障害性の高いワークロードにはスポットインスタンスを使用します。

クラスターポリシーのベストプラクティス

• チームやユースケースごとに個別のポリシーを作成する。
• クラスターポリシーを使用して、コスト管理とリソース制限を強制します。
• コスト配分のため、すべてのクラスターにタグを必須とする。
• 不要な設定オプションを非表示にして、ユーザーインターフェースを簡素化します。
• クラスターポリシーの目的と制限を文書化します。

クラスター ポリシーの詳細な構成については、 「コンピュート ポリシーの作成と管理」を参照してください。

予算ポリシー戦略の設計

予算ポリシーは、ポリシーに割り当てられたユーザが発生したサーバレス コンピュート アクティビティに適用されるタグで構成されます。 タグは請求レコードに記録されるため、選択したサーバレスの使用量を特定の予算に関連付けることができます。

予算ポリシーの使用例

• サーバレス コンピュートのコストを特定の部門またはプロジェクトに帰属させます。
• さまざまな環境 (開発、ステージング、本番運用など) のコストを追跡します。
• 予算上限に対して支出を監視する。
• 事業部門別またはコストセンター別にコストレポートを作成する。

予算ポリシーのベスト プラクティス

• 部門やプロジェクトごとに予算ポリシーを作成します。
• すべてのコンピュート リソースにわたって一貫したタグ スキームを使用します。
• システムテーブルとダッシュボードを通じて予算の使用状況を監視します。
• 予算の上限値に関するアラートを設定する。
• 予算配分を四半期ごとに見直し、調整する。

ポリシーがノートブック、ジョブ、またはLakeFlow Spark宣言型パイプライン パイプラインに適用されると、ポリシーに含まれるタグはすべて、 system.billing.usageシステムテーブルのcustom_tags列に伝播されます。

使用状況とコストを監視する

事前に構築された使用状況ダッシュボードをワークスペースにインポートして、アカウントおよびワークスペースレベルの使用状況を監視します。

使用状況モニタリングのベスト プラクティス

• 事前に作成された使用状況ダッシュボードをインポートしてカスタマイズします。
• ワークスペース、ユーザー、コンピュートタイプごとの使用傾向を監視します。
• 異常な支出パターンを検知するアラートを設定してください。
• 財務チームと毎月、利用状況レポートを確認する。
• システムテーブルを使用して、カスタムの使用状況分析を行ってください。

使用状況ダッシュボードのテンプレートについては、 「システムテーブルを使用してアカウントのアクティビティを監視する」を参照してください。

アクセス制御戦略の設計

Databricksのデフォルトインストールでは、管理者がワークスペースへのアクセス制御を有効にしない限り、すべてのユーザーがワークスペースオブジェクトを作成および変更できます。ワークスペース内でアクセス制御の分離を実装したい組織は、ワークスペースのアクセス制御を有効にすることができます。

アクセス制御パターン

• 許可（デフォルト） ：すべてのユーザーがクラスター、ジョブ、ノートブックを作成できます。
• 制限あり ：ワークスペースオブジェクトを作成するには、ユーザーに明示的な権限が必要です。
• 分離型 ：異なるチームがそれぞれ異なるワークスペースリソースにアクセスできます。

ワークスペースアクセス制御のベストプラクティス

• 本番運用環境のワークスペースのアクセス制御を有効にします。
• 権限管理には、個々のユーザーではなくグループを使用してください。
• 最小権限アクセスを実装する（必要な権限のみを付与する）。
• ワークスペースのアクセス許可を定期的に確認し、監査する。
• アクセス制御ポリシーを運用マニュアルに文書化してください。

アクセス制御の詳細な設定については、 「アクセス制御リスト」を参照してください。

ワークスペースの設定を確認する

管理コンソール内の設定ページには、多数の重要な設定項目が含まれていますが、その多くはAPIsでカバーされていないため（自動化できません）。 ワークスペースを本番運用の準備が整う前に、これらすべての設定を確認してください。

セキュリティのベストプラクティスガイドは、 https://www.databricks.com/trust/security-features/best-practicesからダウンロードできます。そして、提案内容を適切に実施する。

確認すべき重要なワークスペース設定

• アクセス/表示制御 ：デフォルトで有効になっています。ワークスペース、クラスター、プール、およびジョブの可視性を制御します。

• テーブルアクセスコントロール : 安全により無効になっています。 きめ細かなテーブルACLが必要な場合は、この機能を無効にしてUnity Catalogを使用することを検討してください。

• ユーザー分離の強制 ：デフォルトでは無効になっています。有効にすると、「分離なし」クラスターの使用を回避できます。

• コンテナサービス ：デフォルトでは無効になっています。カスタムDockerコンテナを許可するには、これを有効にします。

• Repos Git許可リスト : 安全により無効になっています。 ユーザーがアクセスできるリポジトリを制限する機能を有効にすることを検討してください。

• データ 漏洩防止対策 ：データ漏洩を防ぐために、以下の機能を無効にすることを検討してください。

  • ノートブック結果のダウンロードボタン
  • UIを使用してデータをアップロードする
  • ノートブックのエクスポート
  • ノートブック テーブル クリップボード機能
  • MLflow実行アーティファクトのダウンロード

• インタラクティブノートブックの結果保存 ：結果を顧客アカウントに保存できるようにします。

ワークスペース設定のベストプラクティス

• 本番運用を展開する前に、すべてのワークスペース設定を確認してください。
• セキュリティおよびコンプライアンス要件に基づいて機能を有効化します。
• 機密性の高いワークスペースにおいて、データ漏洩につながる可能性のある機能を無効にしてください。
• ワークスペースの設定と根拠をランブックに文書化します。
• 可能な限り、IaC（Terraform）を使用してワークスペースの設定を管理してください。

ワークスペースコンピュートの推奨事項

推奨

• SQL 、ノートブック、ジョブ、およびLakeFlow Spark宣言型パイプライン パイプラインの主なオプションとして、サーバレス コンピュートを使用します。
• クラスターとSQLウェアハウスの初期構成を作成し、その後、現実的な負荷に基づいて構成を調整します。
• 容量設計を行う際には、コストと性能のトレードオフを念頭に置いてください。
• クラスターポリシーを使用してアクセス許可を制限し、適切なクラスターサイズを適用します。
• 予算ポリシーを使用して、サーバーレスのコストを部門またはプロジェクトに割り当てます。
• システムテーブルと事前構築済みのダッシュボードを通じて使用状況を監視できます。
• 本番運用環境のワークスペースのアクセス制御を有効にします。
• 本番運用を展開する前に、ワークスペースの設定を慎重に確認してください。

これらのパターンを避けてください

• 本番運用では、クラスターポリシーを使用せずにクラスターを手動で作成しないでください。
• コントロールなしで無制限のクラスター サイズまたはインスタンス タイプを許可しないでください。
• クラスターサイズを最終決定する前に、現実的なワークロードを用いたテストを必ず実施してください。
• セキュリティレビューを受けずに、データ漏洩につながる可能性のある機能を有効にしないでください。
• すべてのワークスペース設定を確認せずに本番運用に展開しないでください。

第8相試験の結果

フェーズ8を完了すると、以下のものが得られます。

• 定義されたコンピュート戦略 (さまざまなワークロードに対するサーバーレスとクラシック コンピュート)。
• 従来のコンピュート ワークロード向けに設計されたクラスター サイジング戦略。
• BIおよびアナリティクスのワークロード向けに設計されたSQLのサイジング戦略。
• クラスターポリシー戦略は、さまざまなチームやユースケースに対応したポリシーで設計されています。
• サーバーレスのコスト帰属のために設計された予算ポリシー戦略。
• ダッシュボードとアラートで定義された使用状況モニタリング アプローチ。
• ワークスペースオブジェクト向けに設計されたアクセス制御戦略。
• 本番運用の展開に向けてワークスペースの設定を確認し、文書化しました。
• 定義されたコスト最適化戦略 (スポット インスタンス、オートスケール、適切なサイジングなど)。

次のフェーズ ：フェーズ9：設計可観測性戦略

実装ガイダンス : コンピュート構成を実装するための段階的な手順については、 「コンピュート」を参照してください。