クラウド規模の分析を管理する

[アーティクル]
07/11/2023

現在、DevOps によって、人々の考え方や働き方が文化的に変化し、個人や組織が持続可能な作業方法を開発して維持するのを支援することで、企業が価値を実現する速度が加速しています。 DevOps により開発と運用が組み合わされ、多くの場合、継続的インテグレーション (CI) と継続的デリバリー (CD) のプラクティスをサポートするソフトウェアエンジニアリングツールに関連付けられています。これらのツールとプラクティスには、ソースコードマネージャー (Git、Apache Subversion、Team Foundation Source Control など) や自動ビルドおよび配信マネージャー (Azure Pipelines、GitHub Actions など) が含まれます。

DevOps と監視を組み合わせることは、アジャイルでスケーラブルなプラットフォームを提供する上で重要です。 DevOps は、ソース管理、CI/CD パイプライン、コードとしてのインフラストラクチャ、ワークフロー、自動化を実装する能力をチームに提供します。監視により、ビジネスオーナー、DevOps エンジニア、データアーキテクト、データエンジニア、およびサイト信頼性エンジニアは、自動化された方法で問題を検出、予測、防止、解決し、生産分析と AI を損なう可能性があるダウンタイムを解消することができます。

ソース管理

ソース管理により、コードと構成が保持され、変更が追跡およびバージョン管理されます。ほとんどのソース管理システムには、コードリポジトリの異なるブランチでレビューおよび作業を行うためのプロセスも組み込まれています。現在、最も一般的なソース管理の種類は Git です。これは、個人がオフラインで作業して中央リポジトリと同期できる、分散バージョンコントロールシステムです。通常、Git のベンダーはブランチも使用し、pull request のガイダンスに従って変更とレビューのフローをサポートします。

ブランチにより、同時に発生する他の作業に影響を与えることなく、変更や機能の開発が分離されます。機能の開発、バグの修正、新しいアイデアの安全な実験のため、ブランチの使用を促進する必要があります。 pull request によって、あるブランチで行われた変更が既定のブランチにマージされ、制御されたレビュープロセスがサポートされます。セキュリティのため、メインブランチで pull request を使用してコードレビューを確認する必要があります。

重要

クラウド規模の分析のリポジトリに関する以下のガイドラインに従ってください。

ブランチと pull request によって制御されたレビュープロセスが行われるようにすることで、リポジトリのメインブランチをセキュリティで保護します。
Azure DevOps または GitHub リポジトリをソース管理に使用して、ソースコードへの変更を追跡し、複数のチームメンバーが同時にコードを開発できるようにする必要があります。
アプリケーションコードとインフラストラクチャの構成を、リポジトリにチェックインする必要があります。

CI/CD パイプライン

CI を使用すると、チームはソースコードを自動的にテストしてビルドし、繰り返しとフィードバックループを迅速に行って、CD での高いコード品質を実現できます。パイプラインは、変更の CI (ソフトウェアコードまたはインフラストラクチャコード) とパッケージ化またはコンパイルされた変更の CD を構成するための手段です。これは、"ビルドとリリース" とも呼ばれています。 CD では、1 つ以上の環境へのアプリケーションの自動デプロイが記述されています。通常、CD は CI プロセスの後で行われ、統合テストを使用してアプリケーション全体が検証されます。

パイプラインは、さまざまなタスクから成る複数のステージを含むことができ、単純なものから複雑なものまで、コンプライアンスと検証を確保するための承認フローを備えることができます。ユーザー設定に基づき、さまざまな自動トリガーを使用してパイプラインを構成することもできます。エンタープライズ規模と AI のデプロイの場合、運用手順には常に人間による事前承認が必要であり、これは運用モデルに組み込まれます。 CI/CD パイプラインは、GitHub Actions または Azure Pipelinesを使用して構築する必要があり、自動的にトリガーされる必要があります。

コードとしてのインフラストラクチャ

IaC での "コード" という言葉は、多くの場合、開発者の背景を持たない IT スタッフに不安をもたらしますが、IaC では、一般的なソフトウェア開発者が行うようなコード記述方法のことではありません。そうではなく、ソフトウェア開発プロセスと同じツールと原則の多くを採用して、予測可能な形式でインフラストラクチャが提供されます。

IaC は、完全な変更制御、監査履歴、テスト、検証、承認プロセスを備えた DevOps パイプラインの一部としてインフラストラクチャをプロビジョニング、構成、管理するのに役立ち、セキュリティとコンプライアンスを損なうことなく、プロジェクトの適切なロールにタスクを委任できます。

IaC に対する 2 つのアプローチは宣言型と命令型です。

宣言型では、インフラストラクチャの望ましい状態を指定し、目的の状態を実現するために必要なアクションをオーケストレーションエンジンで実行します。 Azure では、これは Azure Resource Manager テンプレートを使用して行われます。 Terraform のようなサードパーティの抽象化レイヤーも、このアプローチに使用できます。
命令型のアプローチでは、特定のコマンドが定義された順序で実行されます。 Azure の場合、これはコマンドラインインターフェイスまたは PowerShell で実現できますが、統合ソリューションが必要な場合は、ネイティブプログラミング言語ソフトウェア開発者キット (.NET、Python、Java など) も使用できます。

Azure Resource Manager テンプレートでは、コアプロビジョニングは resources セクション内にあり、個々のリソースの構成は properties セクションで定義されています。 Azure Data Lake Storage Gen2 の場合、構成は次のようになります。

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.MachineLearningServices/workspaces/datastores",
            "name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
            "apiVersion": "2020-05-01-preview",
            "location": "[parameters('location')]",
            "properties": {
                "DataStoreType": "adls-gen2",
                "SkipValidation": "[parameters('skipValidation')]",
                "ClientId": "[parameters('clientId')]",
                "ClientSecret": "[parameters('clientSecret')]",
                "FileSystem": "[parameters('fileSystem')]",
                "AccountName": "[parameters('accountName')]",
                "TenantId": "[parameters('tenantId')]",
                "ResourceUrl": "[parameters('resourceUrl')]",
                "AuthorityUrl": "[parameters('authorityUrl')]"
            }
        }
    ]
}

重要

クラウド規模の分析のデータ管理ランディングゾーン、データランディングゾーン、データ製品を作成するデータアプリケーションなどのすべてのレイヤーは、Azure Resource Manager や Terraform などの宣言型言語で定義され、リポジトリにチェックインされて、CI/CD パイプラインによりデプロイされる必要があります。これにより、チームは、さまざまなアーキテクチャレベルをアジャイルな方法で自動化しながら、Azure スコープのインフラストラクチャと構成の変更を追跡およびバージョン管理できます。このガイダンスにより、チームは Git リポジトリを使用して、特定の Azure スコープの状態を常に見ることができます。

ワークフローと自動化

チームは、複数のステージで CI/CD パイプラインを使用して、開発されたコードにエラーがなく、運用の準備ができていることを確認する必要があります。いくつかのベストプラクティスでは、開発環境、テスト環境、運用環境を使用するようになっています。これらのステージは、環境ごとに異なるサービスを使用して Azure にも反映する必要があります。

プラットフォームチームは、組織内でスケーリングを迅速に行い、IaC に慣れていないチームのためにデプロイを簡略化するため、デプロイテンプレートを提供および保守する必要があります。これらのテンプレートは、シナリオ内の新しい成果物のベースラインとして機能し、会社内のベストプラクティスと一般的な標準を表すように経時的に維持する必要があります。

テストと運用へのデプロイは、CI/CD パイプラインと、一般的なベストプラクティス (例: Azure Resource Manager テンプレート) を適用するための昇格されたアクセス許可を持つサービス接続によってのみ管理する必要があります。

注意事項

データアプリケーションチームは、テスト環境と運用環境に対する読み取りアクセス権のみを持つ必要があります。これらの環境へのデプロイは、CI/CD パイプラインと、昇格されたアクセス許可を持つサービス接続を通じてのみ実行する必要があります。運用環境へのパスの時間を短縮するには、データアプリケーションチームが、開発環境への書き込みアクセス権を持っている必要があります。

次のステップ

プラットフォームの自動化

次の方法で共有