今日、DevOps は、人々の考え方と働き方の文化を変え、個人や組織が持続可能な仕事の実践を開発し、維持するのを支援することで、企業が価値を実現する速度を加速させました。 DevOps は開発と運用を組み合わせたものであり、多くの場合、継続的インテグレーション (CI) と継続的デリバリー (CD) プラクティスをサポートするソフトウェア エンジニアリング ツールに関連付けられています。 これらのツールとプラクティスには、ソース コード マネージャー (Git、Apache Subversion、Team Foundation Version Control など) と自動ビルドおよび配信マネージャー (Azure Pipelines や GitHub Actions など) が含まれます。
DevOps と可観測性を組み合わせることは、アジャイルでスケーラブルなプラットフォームを提供するための鍵です。 DevOps を使用すると、チームはソース管理、CI/CD パイプライン、コードとしてのインフラストラクチャ、ワークフロー、自動化を実装できます。 可観測性により、ビジネスオーナー、DevOps エンジニア、データ アーキテクト、データ エンジニア、サイト信頼性エンジニアは、自動化された方法で問題を検出、予測、防止、解決し、運用分析と AI を損なうダウンタイムを排除することを回避できます。
ソース管理
ソース管理により、コードと構成が保持され、変更が追跡およびバージョン管理されます。 また、ほとんどのソース管理システムには、コード リポジトリのさまざまなブランチでレビューと作業を行うプロセスも組み込まれています。 現在、最も一般的なソース管理の種類は Git です。これは、個人がオフラインで作業し、中央リポジトリに同期できるようにする分散バージョン管理システムです。 Git ベンダーは通常、ブランチも使用し、pull request ガイダンスに従って変更とレビューのフローをサポートします。
ブランチは、同時に発生する他の作業に影響を与えることなく、変更や機能開発を分離します。 ブランチの使用を促進して、機能の開発、バグの修正、新しいアイデアの安全な実験を行う必要があります。 プル要求は、1 つのブランチから行われた変更を既定のブランチにマージし、制御されたレビュー プロセスをサポートします。 セキュリティ上の理由から、メイン ブランチでは pull request を使用してコード レビューを確実に行う必要があります。
Important
クラウド規模の分析リポジトリについては、次のガイドラインに従ってください。
- ブランチとプル要求を適用してリポジトリのメイン ブランチをセキュリティで保護し、制御されたレビュー プロセスを確保します。
- ソース管理に 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 セクションにあり、個々のリソースの構成は プロパティ セクションで定義されます。 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')]"
}
}
]
}
Important
データ管理ランディング ゾーン、データ ランディング ゾーン、データ アプリケーション (データ製品を作成する) などのクラウドスケール分析のすべてのレイヤーは、Azure Resource Manager や Terraform などの宣言型言語で定義し、リポジトリにチェックインし、CI/CD パイプラインを介してデプロイする必要があります。 これにより、チームは Azure スコープのインフラストラクチャと構成に対する変更を追跡およびバージョン管理しながら、アジャイルな方法で自動化されるさまざまなアーキテクチャ レベルをサポートできます。 このガイダンスでは、チームが Git リポジトリを使用して、特定の Azure スコープの状態を常に可視化できるようにします。
ワークフローと自動化
Teams では、複数のステージで CI/CD パイプラインを使用して、開発されたコードにエラーがなく、運用の準備ができていることを確認する必要があります。 いくつかのベスト プラクティスは、開発環境、テスト環境、運用環境を用意することです。 これらのステージは、環境ごとに個別のサービスを使用して Azure にも反映する必要があります。
プラットフォーム チームは、組織内で迅速にスケーリングし、IaC に慣れていないチームのデプロイを簡略化するために、デプロイ テンプレートを提供および保守する役割を担います。 これらのテンプレートは、シナリオ内の新しい成果物のベースラインとして機能し、社内のベスト プラクティスと一般的な標準を表すために、時間の経過と同時に維持する必要があります。
テストと運用のデプロイは、共通のベスト プラクティス (Azure Resource Manager テンプレートなど) を適用するために、CI/CD パイプラインと管理者特権のアクセス許可を持つサービス接続を介してのみ管理する必要があります。
注意事項
データ アプリケーション チームは、テスト環境と運用環境への読み取りアクセス権のみを持つ必要があり、これらの環境へのデプロイは、昇格されたアクセス許可を持つ CI/CD パイプラインとサービス接続を介してのみ実行する必要があります。 運用環境へのパスを高速化するには、データ アプリケーション チームが開発環境への書き込みアクセス権を持っている必要があります。