クラウドネイティブ ソリューションは、新しいワークロード (アプリケーション) を構築するか、既存のワークロードに新機能を追加することで、新しいビジネス価値を生み出します。 まったく新しいアプリケーションを開発する場合でも、既存のシステムに新機能を追加する場合でも、クラウドネイティブ開発は、ワークロードの計画、構築、デプロイ、最適化を行う過程です。 このフレームワークでは、クラウドネイティブ アプリケーションがビジネス目標に合わせ、適切に設計され、最小限のリスクで提供されるように、エンドツーエンドのガイダンスを提供します。
前提条件:Azure ランディング ゾーン
クラウドネイティブ ソリューションのビジネス目標を定義する
明確なビジネス目標から始めます。 新しいデジタル製品の有効化、新しい市場への参入、カスタマー エクスペリエンスの向上、運用コストの削減など、クラウドネイティブ ソリューションが実現する必要がある具体的な結果を定義します。 収益の増加、市場投入までの時間の短縮、サポート チケットの量などの測定可能なインジケーターを使用して、成功を定量化します。 新機能については、カスタマー エクスペリエンスの向上、運用コストの削減、システムのスケーラビリティの向上などの目標を定義します。
制約と成功条件を特定します。 予算、コンプライアンス、配信タイムラインなどのビジネス上の制約を文書化します。 各目標の成功の外観を定義します。 たとえば、"Q4 で新しい顧客ポータルを起動する" や "チェックアウトの待ち時間を 40%減らす" などです。これらの基準は優先順位付けをガイドし、計画中のトレードオフの評価に役立ちます。
利害関係者の配置を検証します。 すべての利害関係者 (ビジネスと技術) が、目標、制約、成功の内容について合意することを確認します。 この調整には、ワークショップや正式なサインオフが含まれる場合があります。 早期配置により、後で間違ったコミュニケーションが行われなくなり、コストのかかるやり直しが回避され、全員が最初から同じ期待を共有できるようになります。
クラウドネイティブ ソリューションの要件を定義する
機能要件を文書化します。 ユーザーのニーズを満たすためにシステムが提供する必要がある機能を文書化します。 各要件はビジネス目標に結び付け、開発作業が目的の結果を直接サポートするようにする必要があります。 利害関係者のインタビューとビジネス戦略ドキュメントを使用して、価値の高い結果を特定します。 ビジネス価値と技術的な実現可能性に基づいて機能に優先順位を付けます。 各要件を測定可能なビジネス目標にトレースし、その包含を正当化します。
機能しない要件を確立します。 非機能要件は、機能要件とガバナンスを満たす技術的要件を定義します。 これらの機能をサポートするために必要な品質属性と技術的な目標を確立します。 アップタイム、復旧ポイント目標 (RPO)、目標復旧時間 (RTO) のサービス レベル目標 (SLO) などのターゲット 信頼性メトリック を定義します。 セキュリティ ベースラインを確立します。 コスト モデルを作成します。 パフォーマンス目標を設定します。
クラウドネイティブ ソリューションのスコープを制御します。 初期リリースのスコープ内とスコープ外の内容を明確に定義します。 魅力的な「付加価値的な」機能を追加したくなりますが、スコープが膨張することによって、タイムラインや予算が危険にさらすおそれがあります。 ソリューションの境界を文書化し、新しい要求の変更制御プロセスを実装します。 定義された目標を直接サポートし、スケジュールや予算を損なうことなく配信できる変更のみを承認します。 優先順位の低いアイデアを将来のバックログに延期します。 スコープを厳密に管理することで、チームは制約内で最初に最も価値のある機能を提供することに集中できます。
クラウドネイティブ アーキテクチャを計画する
適切に計画されたアーキテクチャは、目標と要件を満たす上で不可欠です。 アーキテクチャの主要な決定には、スケーラビリティ、複雑さ、コスト、機敏性のトレードオフが含まれます。 次の手順と決定ポイントは、ベスト プラクティスに沿ったクラウドネイティブ設計を作成するのに役立ちます。
検証済みのクラウドネイティブ アーキテクチャを調べる
アーキテクチャの基礎とベスト プラクティスを確認します。 アーキテクチャをゼロから発明する前に、 Azure アーキテクチャ センターから検証済みの参照アーキテクチャと基礎を確認してください。 使い慣れたアーキテクチャ スタイルには、一般的なワークロードの検証済みの参照アーキテクチャを調べる方法が含まれます。 これらのアーキテクチャは、設計上の意思決定を加速し、リスクを軽減するのに役立ちます。
適切なアーキテクチャ スタイルを選択します。 ワークロードの特性とチームの機能に基づいて アーキテクチャ スタイル を選択します。 アーキテクチャ スタイルには、N 層 (モノリシック)、マイクロサービス、イベント ドリブン (メッセージ ベース)、Web キュー ワーカーが含まれます。 たとえば、比較的単純なアプリケーションの迅速な開発が必要な場合は、適切に構造化された N 層モノリスで十分な場合があります。 異なるドメインを持つ大規模または急速に進化するアプリケーションの場合、マイクロサービスまたはイベント ドリブン アプローチは柔軟性を提供します (複雑さを犠牲にして)。 実際には、多くのシステムは最終的にハイブリッド スタイルになります。 たとえば、一部の共有サービスやイベント ドリブン サブシステムを備えたマイクロサービス コアがあります。 重要なのは、各スタイルのトレードオフを理解し、スケーラビリティ、回復性、機敏性の要件を最適に満たすアプローチを選択することです。
設計のベスト プラクティスとして適用する。 選択したスタイルに関係なく、クラウド アーキテクチャの基礎 と ベスト プラクティスに従います。 Azure アーキテクチャ センターには、分散ワークロードの一般的な課題に対処する クラウド設計パターン (再試行、サーキット ブレーカー、CQRS) のカタログが用意されています。 これらのパターンを設計に統合することで、信頼性とパフォーマンスを向上させることができます。
5 つの柱を設計上の決定に統合します。 Well-Architected Framework を使用して、信頼性、セキュリティ、パフォーマンス効率、コストの最適化、オペレーショナル エクセレンスに関する決定を導きます。 これら 5 つの柱は、すべての設計の意思決定を導く必要があります。 たとえば、データベースを選択する場合は、信頼性 (冗長性、バックアップ)、パフォーマンス、コストをまとめて考慮し、適切なバランスを取ります。 パフォーマンスを向上させるためにコストを増やすなど、柱間のトレードオフを行う場所を文書化します。 これらのメモは、将来のガバナンスとレビューに有用です。
既存のシステムとの統合を計画する
すべての依存システムとサービスのインベントリを作成します。 初期のスタートアップでない限り、新しいクラウドネイティブ ソリューションが単独で動作することはめったにありません。 新しいワークロードまたは機能が環境にどのように適合するかを検討します。 データ フローをマップし、標準との互換性を確保します。 ワークロードが対話するすべてのシステムの包括的な一覧を作成します。 この一覧には、内部 API、データベース、ID プロバイダー (Microsoft Entra ID)、監視ツール、CI/CD パイプライン、VPN または ExpressRoute 経由でアクセスされるオンプレミス システムが含まれます。 アーキテクチャ ダイアグラムと依存関係マップを使用して、これらのリレーションシップを視覚化します。
統合の種類とプロトコルを分類します。 各統合ポイントを、種類 (認証、データ交換、メッセージング) とプロトコル (REST、gRPC、ODBC、SAML、OAuth2) ごとに分類します。 この分類は、互換性の要件と潜在的なボトルネックを特定するのに役立ちます。
ID とアクセスの統合を検証します。 ソリューションが組織の ID プロバイダーと統合されていることを確認します。 たとえば、新しい ID システムを導入する代わりに、認証と承認に Microsoft Entra ID を使用します。 シングル サインオン (SSO)、ロールベースのアクセス制御 (RBAC)、条件付きアクセス ポリシーのサポートを確認します。
ネットワーク接続とセキュリティを評価します。 ワークロードが他のシステムに接続する方法を確認します。 ファイアウォール規則、DNS 解決、およびルーティング パスを検証します。 ハイブリッド シナリオの場合は、ExpressRoute または VPN 構成が設定され、テストされていることを確認します。 Azure Network Watcher を使用して、接続の監視とトラブルシューティングを行います。
データ フローの互換性とコンプライアンスを確保します。 システム間のデータ フローをマップします。 データ形式、スキーマ、および変換の要件を確認します。 データ所在地、暗号化、および保持ポリシーに準拠していることを確認します。
統合ポイントを早期および継続的にテストします。 開発の初期段階で統合テストを実行します。 利用できないシステムに対してはモックまたはスタブを使用します。 Azure DevOps や GitHub Actions などのツールを使用して、CI/CD パイプラインでこれらのテストを自動化します。 待機時間、スループット、エラー率を監視します。 たとえば、アプリが必要な負荷やサービスをブロックするネットワーク ファイアウォールをサポートしないことに依存する API を回避したいとします。
統合コントラクトと SLA を文書化します。 各統合ポイントの予想される動作、可用性、パフォーマンスを定義して文書化します。 再試行ロジック、タイムアウト設定、フォールバック メカニズムを含めます。 依存システムのサービス レベル アグリーメント (SLA) に合わせます。
適切な Azure サービスとサービス レベルを選択する
意思決定ガイドを使用して、ワークロードの要件に一致するサービスを選択します。 Azure には、アプリケーション コードを実行するための複数のオプションが用意されています。それぞれに長所と短所があります。 テクノロジの 選択の概要 を確認して、機能要件と非機能要件に合ったサービスを特定します。 サービスとしてのプラットフォーム (PaaS) オプションに優先順位を付けます。これらのサービスは、インフラストラクチャの管理、修正プログラムの適用、スケーリングを自動的に処理することで運用上のオーバーヘッドを削減するためです。
サービス レベルを選択するための使用パターンとパフォーマンス要件を定義します。 サービス レベルの選択は、コストと機能の両方に影響します。 予想されるトランザクション ボリューム、同時ユーザー読み込み、ストレージ要件、および応答時間やスループットなどのパフォーマンス ターゲットを文書化します。 これらのメトリックを使用して、大幅な過剰プロビジョニングなしでベースライン要件を満たす初期サービス レベル (SKU) を選択します。 デプロイ後の実際の使用パターンに基づいて階層を調整することを計画します。
選択したサービス レベル間の機能の互換性を検証します。 高度なセキュリティ機能、高可用性オプション、統合 API などの重要な機能は、サービス レベルによって異なります。 必要な機能を使用可能な SKU にマップする機能マトリックスを作成します。 後でコストのかかる移行やアーキテクチャの変更を回避するために、選択したレベルで必要なすべての機能がサポートされていることを確認します。 サービス固有のドキュメントを参照して、機能の可用性と制限を確認します。
使用するリージョンの数を選択する
複数リージョンデプロイのトレードオフを評価します。 単一リージョンアーキテクチャはシンプルで安価ですが、リージョンの停止によってアプリがダウンします。 複数リージョンのデプロイでは、高可用性を実現でき (1 つのリージョンで障害が発生し、ユーザーが別のリージョンから提供される場合があります)、最も近いリージョンのユーザーにサービスを提供することでパフォーマンスを向上させることもできます。 トレードオフにより、デプロイとデータ同期の複雑さが増します。 潜在的な整合性の問題、グローバル トラフィック ルーティング、コストの高いリージョン間のデータ レプリケーションを処理する必要があります。 信頼性の要件に基づいてこの決定を行う方針です。
信頼性目標を使用して、地域戦略をガイドします。 リージョンの要件を決定するために、サービス レベル目標 (SLO)、回復ポイント目標 (RPO)、復旧時間目標 (RTO) を定義します。
データ所在地の規制への準拠を確認します。 法律およびコンプライアンス チームと協力して、地域の選択が規制上の義務を満たしていることを確認します。
ドキュメント アーキテクチャ
詳細なアーキテクチャ図と設計ドキュメントを作成します。 ドキュメントでは、実装、レビュー、および将来のメンテナンスがサポートされています。 選択した Azure サービス、SKU、データ フロー、ユーザー操作を含めます。 この図では、実装とレビューをサポートするためのアーキテクチャが明確に視覚的に表現されていることを確認します。
主要な設計上の決定事項とトレードオフを記録します。 信頼性、セキュリティ、パフォーマンスなどの非機能要件など、アーキテクチャの選択の背後にある根拠を文書化します。 競合する優先順位のバランスを取るために行われたトレードオフを強調表示します。
クラウドネイティブデプロイ戦略を計画する
クラウドネイティブ ソリューションを運用環境にデプロイする場合は、アドホック プッシュではなく、計画された戦略に従います。 堅牢な展開計画では、ユーザーへの影響を最小限に抑え、問題が発生した場合に回復する方法を提供します。
開発とデプロイのプラクティスを計画する
開発とデプロイのプラクティスにより、環境間で一貫した配信と運用の準備が保証されます。 これらのプラクティスにより、展開リスクが軽減され、チームの調整が改善されます。
デプロイの自動化のための DevOps プラクティスを確立します。 DevOps プラクティスは、自動化、バージョン管理、CI/CD パイプラインを通じて開発チームと運用チームを調整します。 Azure DevOps や GitHub Actions などのツールを使用して、ビルド、テスト、デプロイのワークフローを自動化します。 この方法では、手動エラーを減らし、リリース サイクルを高速化し、環境間で一貫したデプロイ プロセスを提供します。
展開アクティビティをサポートするための 運用準備を 計画します。 運用の準備には、デプロイ シナリオの監視、アラート、インシデント対応手順が含まれます。 ロールバック手順、正常性チェック、トラブルシューティング手順に対応するデプロイ Runbook と自動化スクリプトを文書化します。 デプロイ アクティビティ中のアクセシビリティを確保するために、これらのリソースを Azure DevOps Wiki や GitHub などの中央の場所に格納します。
信頼性の高いデプロイをサポートする 開発プラクティス を定義します。 コーディング標準、ピア レビュー、自動テストを使用して、コードの品質とデプロイの準備を確保します。 これらのプラクティスを CI/CD パイプラインに統合して、デプロイ前に品質ゲートを適用します。 統合テスト、スモーク テスト、パフォーマンス検証などのデプロイ固有のテストを含めて、運用環境のシステムの準備を確認します。
新しいワークロードのデプロイを計画する
プログレッシブ 露出を使用して影響を制限します。 既存のユーザーがいない新しいアプリケーション (グリーンフィールド) の場合は、ソフト起動を行う必要があります。 運用環境にデプロイしますが、最初は内部ユーザーまたはパイロット グループにのみ公開します。 この手法は、新しいワークロードのカナリアデプロイメントです。 真に新しく分離された場合は、完全な運用環境への 1 回限りのデプロイが可能ですが、制御された方法で問題をキャッチするには、段階的な露出を引き続きお勧めします。 実際の検証を最初に行わずに、1 日目に 100% のユーザーにシステムを解放しないでください。 詳細については、「 WAF - プログレッシブ 露出モデルの採用」を参照してください。
運用手順とエスカレーション パスを文書化します。 サービスの再起動、ログへのアクセス、一般的な問題の処理、インシデントのエスカレートに関する明確なドキュメントを作成します。 このドキュメントを SharePoint や GitHub などの共有リポジトリに保存して、サポート チームの可用性を確保します。
新機能のデプロイを計画する
変更管理を使用して新機能の統合を計画します。 組織の変更管理プロセスに従って、運用環境の変更を制御および文書化します。 アプリケーションのバージョンを元に戻す、データベース バックアップを復元するなどのロールバック手順を定義します。 展開前に利害関係者の承認をセキュリティで保護し、ビジネス目標との整合性を確保します。 詳細については、「CAF での 変更の管理 」を参照してください。
マイナー変更や下位互換性のある変更には、その場での更新を行います。 ローリング 更新プログラムまたは機能フラグを使用して、運用環境に更新プログラムを直接デプロイします。 ユーザーまたはインスタンスのごく一部から始めます。 完全なロールアウトの前に、システム メトリックとログを監視して安定性を検証します。
大規模または高リスクの変更には、並列 (ブルーグリーン) デプロイを使用します。 新しいバージョンを別の環境にデプロイします。 動作を検証するために、ライブ トラフィックのごく一部を新しいバージョンにルーティングします。 成功した場合は、すべてのトラフィックを新しいバージョンに移行します。 問題が発生した場合は、トラフィックを元のバージョンに戻して、継続性を確保します。
新しいワークロードの運用上の引き継ぎを計画します。 デプロイ後のソリューションの運用とサポートを担当するチームを特定します。 サポート モデル (24 時間 365 日のオンコールまたは営業時間内のサポート) を定義し、すべての関係者がその役割を確実に理解できるようにします。
所有権を定義し、責任をサポートします。 運用チームが新しい機能をサポートする準備ができていることを確認します。 ドキュメントとエスカレーション パスを更新して、新しい責任を反映し、迅速なインシデント対応を確保します。
クラウドネイティブ ソリューションのロールバック計画を定義する
ロールバック計画を使用すると、デプロイが失敗したりリスクが発生したりしたときに、チームは変更をすばやく元に戻すことができるようになります。 明確に定義された計画により、ダウンタイムを最小限に抑え、ビジネスへの影響を制限し、システムの信頼性を維持します。 移行またはデプロイを開始する前に、ロールバック条件と手順を常に確立してください。
失敗したデプロイを定義します。 ビジネス利害関係者、ワークロード所有者、運用チームと共同作業を行い、失敗したデプロイとみなす基準を決定します。 たとえば、正常性チェックの失敗、パフォーマンスの低下、セキュリティの問題、未解決の成功メトリックなどがあります。 この定義により、ロールバックの決定が組織のリスク許容度と一致します。 デプロイ 計画にロールバックをトリガーする特定の条件 (CPU 使用率の制限、応答時間のしきい値、エラー率など) を含めます。 この評価により、ロールバックの決定が明確になり、インシデント中に一貫性が得られます。
CI/CD パイプラインのロールバック手順を自動化します。 Azure Pipelines や GitHub Actions などのツールを使用して、ロールバック プロセスを自動化します。 たとえば、正常性チェックが失敗した場合に以前のバージョンを再デプロイするようにパイプラインを構成します。
ワークロード固有のロールバック手順を作成します。 ワークロードの種類、環境、デプロイ方法に一致するロールバック手順を開発します。 たとえば、コードとしてのインフラストラクチャのデプロイでは、以前のテンプレートを再適用する必要があります。 アプリケーションのロールバックには、前のコンテナー イメージの再デプロイが含まれます。 ロールバック スクリプト、構成スナップショット、およびコードとしてのインフラストラクチャ テンプレートをロールバック 計画にアタッチします。 これらの資産を使用すると、迅速な実行が可能になり、手動による介入への依存を減らすことができます。
ロールバック プロシージャをテストします。 実稼働前環境でデプロイエラーをシミュレートし、ロールバックの有効性を検証します。 自動化、アクセス許可、または依存関係のギャップを特定して解決します。 ロールバックによってシステムが安定した既知の正常な状態に復元されることを確認します。
ロールバック戦略を改善する 各デプロイまたはロールバック イベントの後、振り返りを実行して、何が機能し、何がうまくいかなかったかを評価します。 学習した教訓、アーキテクチャの変更、または新しいツールに基づいて、ロールバックの条件、手順、自動化を更新します。 ロールバック戦略を最新かつ効果的な状態に保つためのドキュメントを維持します。