計画が完了したら、開発環境でソリューションをビルドして構成します。 ベスト プラクティスに従い、テストを通じて品質を確保します。 クラウドネイティブ ソリューションでは、スケーラブルで回復性があり、監視可能なアーキテクチャ パターンを使用して、Azure サービスの利点を最大化します。 強力なテストと自動化のプラクティスを使用して非運用環境で構築することで、運用環境のデプロイの品質と準備が保証されます。
新しいクラウドネイティブ ソリューションを開発する
クラウドネイティブの開発には、最初から品質プラクティスを統合する構造化されたアプローチが必要です。 このガイダンスは、実証済みの開発プラクティスを通じて、信頼性の高い、セキュリティで保護されたスケーラブルなソリューションを構築するのに役立ちます。
開発中 Well-Architected フレームワークの原則を適用する
クラウドネイティブ ソリューションでは、Well-Architected Framework (WAF) の原則を適用するとメリットがあります。 Well-Architected Framework には、効果的なクラウドネイティブ開発の原則が用意されています。 これらの 5 つの柱を統合して、運用環境で優れたパフォーマンスを発揮する堅牢なアプリケーションを作成します。
非運用環境でのソリューションの開発
運用環境の構成をミラーリングする開発環境を作成します。 運用環境を厳密にミラーリングする非運用環境 (開発、テスト、QA) を設定します。 テスト環境が運用環境に近いほど、リリース時に動作する自信が高くなります。 このアプローチは、既存のワークロードに新機能を追加する場合に特に重要です。
実稼働データボリュームを表す現実的なデータセットを使用します。 運用ワークロードのサイズと複雑さに一致するデータを使用してテストします。 大規模なデータセットでは、小規模なテスト データセットで見逃されるパフォーマンスのボトルネックとスケーリングの問題が公開されます。 実稼働データを匿名化するか、実際のデータの統計的特性を保持する合成データを生成します。
非運用環境のコスト管理を実装します。 Azure DevTest Labsまたはリソース スケジュールを使用して、リソースを使用していないときに自動的に開始および停止します。 開発ワークロードに適切なサービス レベルを適用し、使用制限を実装して、テストの有効性を維持しながら、予期しないコストを防ぎます。
詳細については、「WAF で テスト環境を構成する」を 参照してください。
ソース管理と CI/CD を使用して変更を実装する
すべてのコードと構成を Git リポジトリに格納します。 アプリケーション コード、インフラストラクチャ テンプレート、デプロイ スクリプト、および構成ファイルをバージョン管理で追跡します。 このプラクティスは、変更の完全な履歴を提供し、チーム メンバー間のコラボレーションを可能にします。
開発作業を小さな頻繁なコミットに分割します。 小さなインクリメントで機能開発を完了し、個別にマージおよびテストできるようにします。 この方法により、統合の競合が軽減され、問題の発生元を簡単に特定できます。
コードの変更ごとにビルドとテストを自動化します。 変更がコミットされたときにコードを自動的にコンパイルし、テストを実行し、非運用環境にデプロイする CI/CD パイプラインを構成します。 高速フィードバック ループは、開発者が問題をすばやくキャッチして修正するのに役立ちます。
機能フラグを使用して、新機能のリリースを制御します。 機能の切り替えを実装して、ユーザーの準備ができるまで新機能を無効にしたまま、コードを運用環境にデプロイできます。 この戦略では、デプロイをリリースから分離し、より安全でより制御されたロールアウトを可能にします。
開発中に監視を実装する
Azure Monitorと Application Insights をアプリケーション コードに統合します。 監視データ収集を追加して、主要なパフォーマンス メトリック、ユーザー操作、システム正常性インジケーターを追跡します。 運用環境のデプロイ前にこれらのツールが正しく動作するように、開発中にこれらのツールを構成します。
アプリケーション全体に構造化ログを実装します。 一貫性のあるログ形式を使用し、ユーザー ID、要求 ID、ビジネス プロセス識別子などのコンテキスト情報を含めます。 ログを JSON オブジェクトとして構造化して、強力なクエリと分析機能を有効にします。
主要なメトリックとエラー状態のアラートを構成します。 エラー率の増加、応答時間の低下、またはビジネス メトリックが予想範囲外になった場合に通知するプロアクティブ監視を設定します。 サービス レベルの目標とビジネス要件に基づいてアラートのしきい値を定義します。
システム パフォーマンスを可視化するダッシュボードを作成します。 アプリケーション、インフラストラクチャ、ビジネス プロセスの正常性を示す監視ダッシュボードを構築します。 データドリブンの意思決定を可能にするために、技術チームとビジネス利害関係者の両方にとって重要なメトリックを含めます。
詳細については、「 監視システムの設計 」および「WAF での アプリケーションのインストルメント化」を 参照してください。
テストを使用してクラウドネイティブ ソリューションを検証する
包括的なテストでは、ソリューションがビジネス要件を満たし、実際の条件下で確実に実行されることを検証します。 各種類のテストは、ソリューションの品質を確保するための特定の目的に役立ちます。
エンドツーエンドの機能テストを実行して、ビジネス ワークフローを検証します。 現実的なデータと対話を使用して、認証からトランザクション完了までの完全なユーザー シナリオをテストします。 新しい機能が正しく機能し、変更後も既存の機能がそのまま残っていることを検証します。 回帰テストを実行して、意図しない副作用をキャッチします。
ビジネス利害関係者に対してユーザー受け入れテストを実施する。 実際のユーザーまたはビジネス担当者が、ソリューションがニーズと期待を満たしていることを検証します。 UAT 環境で主要なシナリオをテストし、使いやすさと機能に関するフィードバックを提供します。 運用環境の展開に進む前に、利害関係者から正式な承認を得る。
現実的な条件下でロード テストを実行して、パフォーマンスを検証します。 Azure Load Testing を使用して、予想されるユーザー ボリュームとデータ スループットをシミュレートします。 ピーク時の負荷レベル以降でテストして、パフォーマンスのボトルネックとスケーリングの制限を特定します。 応答時間、スループット、リソース使用率を測定して、ソリューションがパフォーマンス要件を満たしていることを確認します。
セキュリティとコンプライアンスのテストを実行して脆弱性を特定します。 アプリケーション コード、コンテナー イメージ、インフラストラクチャ構成に対して自動セキュリティ スキャンを実行します。 Microsoft Defender for Cloudを使用して、セキュリティの構成ミスとコンプライアンス違反を確認します。 展開前にリスクの高い脆弱性に対処し、受け入れ可能なリスクに対する補正コントロールを実装します。
運用環境のデプロイ前に重大な問題を解決します。 テスト フェーズは、続行する前に合格する必要がある品質ゲートとして扱います。 サービス レベル アグリーメントの会議を妨げるパフォーマンスの問題を修正し、重大なリスクを引き起こすセキュリティの脆弱性を解決します。 コア ビジネス プロセスに影響を与える機能上の欠陥に対処します。 将来の解決のための計画に関する既知の優先度の低い問題を文書化します。
自動化された単体テスト スイートと統合テスト スイートを維持します。 個々のコンポーネントとその外部依存関係との相互作用を検証する包括的な自動テストを作成します。 これらのテストを CI/CD パイプラインの一部として実行し、バグ修正のたびに回帰を防ぎます。 堅牢な自動テスト スイートにより、クラウドネイティブ環境での確実な継続的デリバリーが可能になります。
再利用可能なインフラストラクチャを作成する
最新化されたソリューションが非運用環境のすべてのテストに合格したら、インフラストラクチャのセットアップと構成をコードとしてキャプチャして、運用環境および将来の環境で簡単にレプリケートできるようにする必要があります。 再利用可能なインフラストラクチャとは、一貫性と速度のためにコードとしてのインフラストラクチャ (IaC) テンプレートと自動化を使用することです。
実績のある構成用の IaC テンプレートを作成します。 テスト環境の最終的なアーキテクチャ (prod で必要なものを反映) を取得し、体系化します。 インフラストラクチャを定義するには、Bicep、 Teraform、または Azure Resource Manager テンプレート を使用します。 これらのテンプレートをパラメーター化して、開発、テストなどのさまざまなステージに再利用できるように、名前やサイズなどの小さな調整を行います。 このセットアップにより、作成した運用環境がテストした環境と一致します。 手動でAzureポータルをクリックしてリソースを作成する際の人的エラーを回避します。 また、ディザスター リカバリーや新しいリージョンへのデプロイなど、環境を再作成する必要がある場合は、インフラストラクチャをデプロイする準備ができていることも意味します。 詳細については、「 CAF の管理 - コードベースのデプロイの管理」を参照してください。
バージョン 管理にテンプレートを格納します。 (アプリケーション コードと共に、または別のリポジトリで) インフラストラクチャ コードを Git リポジトリにチェックインします。 適切なバージョン管理で IaC 資産を管理するには、GitHub または Azure DevOps を使用します。 バージョン管理により、コード レビューが可能になり、チームのコラボレーションがサポートされ、プロジェクト間でのテンプレートの再利用が促進されます。 この方法では、インフラストラクチャの変更を完全に追跡でき、問題が発生した場合のロールバック機能がサポートされます。
依存関係のインストールと構成を自動化します。 これらのテンプレートをデプロイし、必要な構成またはシード処理タスクも処理するスクリプトまたはパイプライン タスクを作成します。 Azure Pipelines、GitHub Actions を使用して、IaC テンプレートを取得し、ターゲット サブスクリプション/リソース グループにデプロイするデプロイ ジョブを実行します。 アプリの依存関係のインストール、設定の構成、 シークレット管理を自動化します。 目標は、ワンクリック (または 1 コマンド) 環境のセットアップです。何もしない環境から、テストした環境と一致する完全に実行されている環境までです。
IaC と自動化をエンドツーエンドでテストします。 サンドボックスとして別のAzure サブスクリプションまたはリソース グループを使用し、テンプレートとスクリプトを使用して環境全体をゼロからデプロイする練習を行います。 IaC テンプレート、パイプライン、およびスクリプトが、何もない場所から完全なインフラストラクチャ スタックを作成できることをテストします。 初期デプロイ、構成の更新、ロールバック手順など、さまざまなデプロイ シナリオをテストして、自動化が正しく動作することを確認します。
詳細については、「WAF でのコードとしてのワークロード開発サプライ チェーンとインフラストラクチャの設計」を参照してください。
デプロイに関するドキュメントを作成する
自動化を使用する場合でも、デプロイに関する適切なドキュメントを用意することは、監査、新しいチーム メンバーのオンボード、および将来のメンテナンスのために不可欠です。 展開のドキュメントでは、構成、手順、ロールバック手順を人間が判読できる形式で説明する必要があります。
ドキュメントの構成設定と手順。 環境固有のすべての設定、接続文字列、サービス エンドポイント、およびセキュリティ構成をアクセシビリティ対応のドキュメントに記録します。 詳細なデプロイ手順、前提条件、デプロイ後の検証手順を含めます。 このドキュメントでは、一貫性のあるデプロイを可能にし、問題が発生した場合のトラブルシューティングをサポートします。 新しいエンジニアがデプロイする際には、このドキュメントを読み、パイプラインの出力を理解するか、順を追って従うことができます。
ロールバックと回復の手順を更新します。 テストを完了したら、デプロイの問題が発生したときに変更を元に戻す手順を形式化します。 ロールバック トリガー、データのバックアップと復元の手順、回復の検証手順を含めます。 ロールバックと復旧の手順を定期的にテストして、必要に応じて正常に動作することを確認します。 この準備により、ダウンタイムが短縮されます。
このドキュメントをすべて中央の場所に収集します。 この情報を格納するには、SharePoint、GitHub、または wiki を使用します。 チームとサポート担当者が見つける場所を把握していることを確認します。 ストレスの高いインシデントでは、明確なドキュメントを手元に持つことはライフセーバーです。