信頼できるデプロイ
 予測可能性を備えた配置の望ましい状態に到達します。 |
|---|
ワークロードのホスティング プラットフォーム、アプリケーション、データ、構成リソース全体にわたって、すべての環境で予測可能性の目標を一貫して達成できるようにするワークロード サプライ チェーンを構築します。 自動化、テスト、監視、バージョン管理の機能を持つデプロイ メカニズムにする必要があります。 モジュール化され、オンデマンドで実行できる状態になっている必要があります。 これをモノリシックなエンド ツー エンド プロセスとして表さないでください。 サプライ チェーンは、必ずしも実行の高速化が目的ではなく、複数の反復にわたって一貫性と自己文書化を実現するためのものです。
ワークロード チームは、自身のワークロードに関連するサプライ チェーンに対して責任を持ちます。
サンプル シナリオ
Contoso Manufacturing は、製造工程の監視と最適化に使用する Java ベースのアプリケーションを開発しました。 ワークロードは最近 Azure に移行され、現在は Azure Spring Apps、Azure Database for MySQL、Azure IoT Hub で実行されています。
コードを使用してインフラストラクチャを配置する
コードとしてのインフラストラクチャ (IaC) を使用して、実稼働可能なサプライ チェーンの反復可能な側面を定義します。 命令型メソッドよりも宣言型のアプローチを優先します。
宣言型 IaC テクノロジは、自動化と再利用性を念頭に置いて設計されています。 インフラストラクチャの配置を個人からツールにオフロードすると、一貫した品質を実現できます。
インフラストラクチャの観点からは、テクノロジの選択肢が少ないことにより、ツールのばらつきがなくなり、構成のドリフトを検出しやすくなります。 メンテナンスも容易になります。 選択肢をチームの既存のスキル セットに合わせれば、チームは簡単にそれを採用できます。
"Contoso の課題"
- オンプレミス バージョンのワークロードでは、スクリプトと手動の手順を組み合わせて使用してインフラストラクチャを構築し、複数の環境にアプリケーションを配置しました。 Azure への移行プロセスの早い段階で、チームは既存の自動化コードベースをできるだけ再利用できるように、既存の命令型スクリプトに変更を加えて新しいプラットフォームをターゲットにしました。 このアプローチを採用したのは、Azure や Bicep などの IaC テクノロジに関する専門知識がないためでもありました。
- 移行が進み、チームがプラットフォームにさらに慣れてくると、彼らは、Bicep で IaC アプローチを使用することが長期的により優れたソリューションになると確信するようになりました。
"アプローチと結果の適用"
- 社内に知識がなかったため、チームはワークロードの配置自動化スクリプトの移行および拡張作業を経験豊富な請負業者に委託しました。彼らはプロジェクトの初期段階で開発チームと一体となって作業すると同時に、チームの他のメンバーに知識の移転を行いました。
- 結果として得られる Bicep ベースの実装により、Azure でインフラストラクチャをプロビジョニングするための、より信頼性が高く、管理しやすく、効率的な方法が提供されます。 コードはより読みやすく、保守しやすくなり、VSCode での優れたツール サポートも備えています。 また、完全にべき等であり、状態管理も簡素化されます。これらを完全に実現することは、以前のまたは命令型のバージョンでは決してできませんでした。
アプリケーション コードと同様に IaC を扱う
IaC の開発とメンテナンスに関するソフトウェアの次の推奨事項に従います。適度にモジュール化し、カスタムまたは低価値の抽象化を避けて、さまざまなライフサイクルを反映する階層化されたアプローチに従います。 下位レイヤーが一定のままで、上位レイヤーが必要に応じて変化する基本レイヤーを形成します。
アプリケーション バイナリ、IaC テンプレート、パラメータなどの配置成果物は、攻撃面の一部です。 シークレットの管理、アクセス制御、セキュリティの柱のその他の原則など、保証を適用します。
成果物には、アプリケーション コードと同じレベルのエンジニアリングの厳密さが適用されます。 ピア レビューとテストを用いた品質管理により、配置に自信を持つことができます。
階層化されたアプローチにより、メンテナンスが容易になり、責任の明確な線引きを設定する境界が作成されます。
成果物にセキュリティ コントロールを追加すると、配置プロセス中にシステムを強化できます。
"Contoso の課題"
- プロジェクト チームは移行作業の開始時に、豊富な予算を持っていたため、高品質かつ短期間でサービスを提供する経験豊富な請負業者を雇いました。 請負業者は開発用に別のリポジトリを使用しました。そのリポジトリは定期的なセキュリティの監査が行われていませんでしたが、メインのアプリケーション コード リポジトリでは行われています。
- チームはソリューションの大規模な再設計をリリースする準備を整えており、配置コードでは大幅な変更が必要になります。 開発リソースが不足しているため、最新の一連の変更は 2 人のインターンによって行われています。 チームのシニア開発者の 1 人がインターンを支援するために呼ばれたとき、彼は、API キーのようなアプリケーション シークレットがコードベースにハードコーディングされているなど、チームの開発標準と同等ではない複数のコミットがリポジトリにあることに気付きました。
"アプローチと結果の適用"
- チームは、ビルドと配置のコードベースを、アプリケーション コードに使用されているのと同じリポジトリに移動し、コードベースの他の領域と同じレベルのエンジニアリングの厳密さを適用し始めることにしました。 コードは、最初のコミットの前にチームの標準に合致するようになり、アプリケーション シークレットが削除され、チームの他のすべての品質標準とツールが適用されます。
- その結果、チームはコードベースのこのセクションをセキュリティで保護しながら、コードの品質を高めることができました。 今後、コードベースのこの領域に対する変更では、コア アプリケーション コードベースに使用されるのと同じ標準に従い、同じツールを利用します。これには、ピア コード レビューや、品質とセキュリティのツールを使用したコードの自動スキャンなどが含まれます。
1 つのマニフェストで配置を標準化する
すべての環境で使用される共通の配置マニフェストを開発します。 そのマニフェストを、グリーンフィールド プロジェクト、増分ワークロード更新、またはディザスター リカバリーの既定のメカニズムとして使用します。
この方法を適用すると、複数の資産を管理する際のオーバーヘッドを取り除くことができます。
障害が発生した場合、即席の環境を作成するのではなく、十分にテストされたマニフェストを配置できるため、迅速かつ信頼性の高い復旧が可能になります。
"Contoso の課題"
- Contoso Manufacturing は、完全に自動化されたパイプラインを使って、インフラストラクチャ、アプリケーション コード、構成の変更を開発および運用環境に配置します。 アプリケーションは、1 つのリージョンで高可用性を実現するように構成されています。 MySQL データベースを除き、ほとんどのアプリケーション コンポーネントはステートレスです。 データベースは、設定された RTO/RPO に従ってバックアップされ、バックアップはセカンダリ リージョンにレプリケートされます。
- プライマリ リージョンで重大または致命的な障害が発生した場合、チームはセカンダリ リージョンでアプリケーションをホストする新しい環境を構築する予定です。 DR 手順をテストするための計画された訓練中に、セカンダリ リージョンに環境を再作成しようとすると、複数のリソースが利用できないなどのサービス制限が原因で、配置スクリプトが失敗します。
"アプローチと結果の適用"
- チームは、セカンダリ リージョンでプロビジョニングしようとしたときに発生した問題を軽減するために、いくつかのリソースの使用を両方のリージョンで使用できる同等の SKU に置き換えて、いくつかのオプションを構成可能にすることで、異なっているが有効な値をセカンダリ リージョンで使用できるようにしました。
- この演習により、インフラストラクチャの大規模な障害から復旧する能力に対するチームの信頼度が高まりました。