データ ワークロード用の Azure Well-Architected フレームワーク
このシナリオのプラン方法論では、データ資産の合理化、技術的な取り組みの優先順位付け、およびデータ ワークロードの識別を行うためのプロセスの概要を説明します。 名前付きワークロードの多くでは、一連のアーキテクチャの原則に従うことが重要です。 これらの原則は、ワークロードの開発と最適化に役立ちます。 5 つのアーキテクチャ コンストラクトは、Azure Well-Architected フレームワークで詳細に説明されています。 このガイダンスでは、これらの原則をデータ ワークロードの管理に適用する方法の概要について説明します。
コストの最適化
適切なソリューションに適したツールで設計することが重要です。 このプリンシパルは、時間の経過と共に支出を分析するのに役立ちます。 また、必要に応じてスケールアウトとスケールインの機能を分析するのにも役立ちます。 データ ワークロードについては、再利用性、オンデマンドのスケーリング、データ重複の削減を検討し、Azure Advisor サービスを利用します。
詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
パフォーマンス効率
ユーザーは、ワークロードのパフォーマンスがよいと満足します。 パフォーマンスは、外部要因によって異なる場合があります。 パフォーマンス テレメトリを継続的に収集し、できるだけ迅速に対応することが重要です。 管理と監視のための共有環境制御を構築して、ワークロードのパフォーマンスに固有のアラート、ダッシュボード、通知を作成します。 主な考慮事項は次のとおりです。
- ストレージとコンピューティングの抽象化
- 動的スケーリング
- パーティション分割
- ストレージのクリーンアップ
- 拡張ドライバー
- 多層キャッシュ
詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
オペレーショナル エクセレンス
データ ワークロードの運用管理には、イベントに迅速に対応する機能を向上させる高度な自動化を含めることができます。 ワークロード固有のプロセス自動化、自動テスト、一貫性により、一元化されたデータ操作に基づいて構築します。 AI の場合は、通常のリリース サイクルの一部として、共有 MLOps フレームワークを使用することを検討します。
詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
セキュリティ
すべてのアプリケーションとワークロードについて、レイヤーでのアーキテクチャプロセスにセキュリティとデータ管理を組み込む必要があります。 クラウド規模の分析では、セキュリティの基盤の確立を重視します。 この基盤は Azure ランディング ゾーンを構成するときに構築され、ワークロードとは別に管理します。 ただし、ワークロード チームは、その場合でも次の最小要件を検証する必要があります。 必要に応じて、環境の構成を強化するためにワークロード固有のソリューションが必要になる場合があります。
- 特権管理、データ プライバシー、適切なコントロールの確立など、データの機密性と整合性を確保します。
- プラットフォーム レベルで、適切なネットワーク分離とエンドツーエンドの暗号化、監査、およびポリシーを実装します。
- シングル サインオン (SSO) 統合、多要素認証でサポートされた条件付きアクセス、および管理サービス ID を使用します。
- ロールベースのアクセス制御 (RBAC) を適切に適用し、可能な場合は属性ベースのアクセス制御 (ABAC) を使用して、コントロール プレーンとデータ プレーンのような、問題の分離に従います。
- ワークロード チームが、通常または継続的な脆弱性の評価、脅威の保護、コンプライアンスの監視に関与していることを確認します。
- データをセキュリティで保護する
詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
[信頼性]
すべてのものは中断する可能性があり、データ パイプラインも例外ではありません。 このため、可用性と回復性を考慮した優れたアーキテクチャが設計されています。 重要な考慮事項は、変更をすばやく検出できる速度と、操作を再開できる速度です。
データ環境では、回復力のあるアーキテクチャ、リージョン間の冗長性、サービス レベル、サービス レベル アグリーメント (SLA)、およびクリティカル サポートを検討する必要があります。 また、既存の環境には、統合された監視と通知フレームワークを使用した監査、監視、アラートも含まれている必要があります。
これらの環境制御に基づき、ワークロード チームは次の点を考慮する必要があります。
- サービス レベルの SLA を向上させるためのアーキテクチャの変更
- ワークロード固有のアーキテクチャの冗長性
- クラウド運用チームが提供するものを超える監視と通知のプロセス
詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。