背景・目的

デプロイ戦略（手法）について、調べていたらAWSのDevOps入門のホワイトペーパーを見つけたので、AWSが定義しているDevOpsを整理します

まとめ

下記に特徴をまとめます。

特徴	説明
DevOpsとは	組織がアプリケーションとサービスを高速かつ高品質で提供できるようにする下記を組み合わせたもの・文化哲学・プラクティス・ツール
継続的インテグレーション	開発者がコード変更を定期的に中央コードリポジトリにマージ・自動テストとテストを実行するソフトウェア開発手法バグをより迅速に発見し対処し、ソフトウェアの品質を向上させて、新しいソフトウェア更新の検証とリリースにかかる時間を短縮するのに役立つ AWSでは、下記のサービスを提供している・AWS CodeCommit ・AWS CodeBuild ・AWS CodeArtifact
継続的デリバリー	コード変更が本番へのリリースに向けて自動的に準備されるソフトウェア開発手法現代のアプリケーション開発の柱であるCDは、ビルド段階のあとにすべてのコード変更をテスト環境や本番にデプロイすることで、CIを拡張する適切に実装されていれば、開発者は常に標準化されたテストプロセスを通過したデプロイ可能なビルド成果物を手にする事ができる CDにより、開発者は単体テストだけではなくテストも自動化出来る。これにより顧客展開する前に複数の側面からアプリの更新を検証できるこれらのテストには、UIテスト、負荷・テスト、統合テスト、API信頼性テストなどが含まれる AWSでは、CDのために下記を提供している・AWS CodeBuild ・AWS CodeDeploy ・AWS CodePipeline
デプロイ戦略	ソフトウェアの提供方法を定義する。デプロイ戦略は、組織のビジネスモデルにより異なる完全にテスト済みのソフトウェアを提供する場合もあれば、開発中の機能についてユーザからの評価やフィードバックを求める場合もある下記のようなものがある・In-place deployments ・Blue/green deployment ・Canary deployment ・Linear deployment ・All-at-once deployment
デプロイ戦略 In-place deployments	各リソース上のアプリの以前のバージョンが停止され、最新のアプリケーションがインストールされ、新しいバージョンが起動される新しいインフラは作らない。しかし可用性が影響を受ける可能性がある。その反面、新しいリソースの作成に関連するインフラコストと管理オーバヘッドも最小限に抑えられる LBを使用することで、各インスタンスがデプロイ中に登録解除され、デプロイ完了後にサービスに復元される。
デプロイ戦略 Blue/green deployment	異なるバージョンのアプリケーションを実行している2つの同一環境間でトラフィックをシフトすることでアプリケーションをリリースする手法アプリケーションの更新中のダウンタイムを最小限に抑え、ダウンタイムやロールバック機能に関連するリスクを軽減するのに役立つトラフィックを再ルーティングする前に新しい、バージョンを監視およびテストし、問題検出時にロールバックできる
デプロイ戦略 Canary deployment	ワークロードに影響を与える新しいバージョンを展開するリスクを軽減する新しいバージョンを段階的に展開し、新しいユーザにゆっくりと表示されるようにする展開に自身が持てるようになったら、現在のバージョンを置き換える
デプロイ戦略 Linear deployment	トラフィックが均等な増分でシフトされ、各増分間の分数が均等であること各増分でシフトされるトラフィックの割合と各増分間の分数を指定する
デプロイ戦略 All-at-once deployment	すべてのトラフィックが元の環境から置換環境に一度に移行すること
Infrastructure as code	DevOpsの基本原則は、開発者がコードを扱うのと同様にインフラを扱うことアプリコードと同様の厳密さをインフラのプロビジョニングに適用することすべての構成は宣言的に定義する
Automation and tooling	自動化は、インフラとそのうえで実行されるアプリのセットアップ、構成、展開、サポートに重点を置いている自動化により、標準化された繰り返し可能な方法で環境をより迅速にセットアップできる
Monitoring and observability	コミュニケーションとコラボは、DevOps哲学の基本。フィードバックが不可欠
Communication and Collaboration	Amazonでは、Two-Pizza Teamsのコンセプトを採用チームは小さいほどコラボレーションは良くなる
Security	DevOpsプロセスに統合されたセキュリティについて考える必要がある

概要

下記を基に整理します。

今日、企業はこれまで以上にデジタル変革の旅に乗り出し、顧客とのより深いつながりを構築し、持続可能で永続的なビジネス価値を実現しています。あらゆる形態や規模の組織が、かつてないほど迅速に革新することで競合他社を破壊し、新しい市場に参入しています。これらの組織にとって、革新とソフトウェアの破壊に重点を置くことが重要であり、ソフトウェア配信の合理化が不可欠です。アイデアから実稼働までの時間を短縮し、スピードと俊敏性を優先する組織は、明日の破壊者になる可能性があります。

次世代のデジタルディスラプターとなるには考慮すべき要素がいくつかありますが、このホワイトペーパーでは、DevOps と、アプリケーションとサービスを高速で提供する組織の能力を高めるのに役立つ Amazon Web Services (AWS) プラットフォームのサービスと機能に焦点を当てています。

導入

DevOps は、組織がアプリケーションとサービスを高速かつ高品質で提供できるようにする文化哲学、エンジニアリングプラクティス、ツールを組み合わせたものです。時間の経過とともに、DevOps を導入する際には、継続的インテグレーション (CI)、継続的デリバリー (CD)、Infrastructure as Code (IaC)、監視とログ記録といったいくつかの重要なプラクティスが生まれました。

DevOps
- 組織がアプリケーションとサービスを高速かつ高品質で提供できるようにする下記を組み合わせたもの
  - 文化哲学
  - プラクティス
  - ツール

このホワイトペーパーでは、DevOps の取り組みを加速するのに役立つ AWS の機能と、DevOps の適応に関連する差別化につながらない重労働を AWS サービスがどのように解消できるかについて説明します。また、サーバーやビルドノードを管理せずに継続的な統合と配信機能を構築する方法、および IaC を使用して一貫性と反復性のある方法でクラウドリソースをプロビジョニングおよび管理する方法についても説明します。

継続的インテグレーション:開発者がコード変更を定期的に中央リポジトリにマージし、その後自動ビルドとテストを実行するソフトウェア開発手法。

継続的デリバリー:コードの変更が自動的に構築、テストされ、本番環境へのリリースに向けて準備されるソフトウェア開発手法。

Infrastructure as Code:バージョン管理や継続的インテグレーションなどのコードとソフトウェア開発手法を使用してインフラストラクチャをプロビジョニングおよび管理する方法。

監視とログ記録:組織は、アプリケーションとインフラストラクチャのパフォーマンスが製品のエンドユーザーのエクスペリエンスにどのように影響するかを確認できます。

コミュニケーションとコラボレーション:ワークフローを構築し、DevOps の責任を分散することで、チーム間の連携を強化するためのプラクティスが確立されます。

セキュリティ:横断的な懸念事項です。継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインと関連サービスは保護され、適切なアクセス制御権限が設定されている必要があります。
これらの各原則を調べると、AWS から提供されるサービスと密接な関係があることがわかります。

Continuous integration

継続的インテグレーション (CI) は、開発者がコード変更を定期的に中央コードリポジトリにマージし、その後、自動ビルドとテストを実行するソフトウェア開発手法です。CI は、バグをより迅速に発見して対処し、ソフトウェアの品質を向上させ、新しいソフトウェア更新の検証とリリースにかかる時間を短縮するのに役立ちます。
AWS は継続的インテグレーションのために以下のサービスを提供しています。

CIは、開発者がコード変更を定期的に中央コードリポジトリにマージ・自動テストとテストを実行するソフトウェア開発手法
バグをより迅速に発見し対処し、ソフトウェアの品質を向上させて、新しいソフトウェア更新の検証とリリースにかかる時間を短縮するのに役立つ
AWSでは、下記のサービスを提供している
- AWS CodeCommit
- AWS CodeBuild
- AWS CodeArtifact

AWS CodeArtifact

AWS コードアーティファクトは、組織がソフトウェア開発プロセスで使用するソフトウェアパッケージを安全に保存、公開、共有するために使用できる、完全に管理されたアーティファクトリポジトリサービスです。CodeArtifact は、パブリックアーティファクトリポジトリからソフトウェアパッケージと依存関係を自動的に取得するように構成できるため、開発者は最新バージョンにアクセスできます。

ソフトウェア開発チームは、アプリケーションパッケージで一般的なタスクを実行するために、オープンソースパッケージにますます依存するようになっています。ソフトウェア開発チームにとって、ソフトウェアに脆弱性がないことを保証するために、オープンソースソフトウェアの特定のバージョンに対する制御を維持することが重要になっています。CodeArtifact を使用すると、これを強制するための制御を設定できます。

CodeArtifact は、Maven、Gradle、npm、yarn、twine、pip などの一般的に使用されるパッケージマネージャーやビルドツールと連携し、既存の開発ワークフローに簡単に統合できます。

組織がソフトウェア開発プロセスで使用するソフトウェアパッケージを安全に保存、公開、共有するために使用できる、完全に管理されたアーティファクトリポジトリサービス
パブリックアーティファクトリポジトリからソフトウェアパッケージと、依存関係を自動的に取得するように構成できる
ソフトウェアに脆弱性がないことを保証するために、OSSの特定バージョンに対する制御を維持することが重要
下記などのパッケージマネージャー、ビルドツールと連携し、既存の開発ワークフローに簡単に統合できる
- Maven
- Gradle
- npm
- yarn
- twine
- pip

Continuous delivery

継続的デリバリー (CD) は、コード変更が本番環境へのリリースに向けて自動的に準備されるソフトウェア開発手法です。現代のアプリケーション開発の柱である継続的デリバリーは、ビルド段階の後にすべてのコード変更をテスト環境や本番環境にデプロイすることで、継続的インテグレーションを拡張します。適切に実装されていれば、開発者は常に、標準化されたテストプロセスを通過した、デプロイ可能なビルド成果物を手にすることができます。

継続的デリバリーにより、開発者は単体テストだけでなくテストも自動化できるため、顧客に展開する前に複数の側面からアプリケーションの更新を検証できます。
これらのテストには、UI テスト、負荷テスト、統合テスト、API 信頼性テストなどが含まれます。これにより、開発者は更新をより徹底的に検証し、問題を事前に発見できるようになります。クラウドを使用すると、オンプレミスではこれまで困難だった、テスト用の複数の環境の作成とレプリケーションを簡単かつコスト効率よく自動化できます。
AWS は継続的デリバリーのために以下のサービスを提供しています。

AWS コードビルド

AWS コードデプロイ

AWS コードパイプライン

コード変更が本番へのリリースに向けて自動的に準備されるソフトウェア開発手法
現代のアプリケーション開発の柱であるCDは、ビルド段階のあとにすべてのコード変更をテスト環境や本番にデプロイすることで、CIを拡張する
適切に実装されていれば、開発者は常に標準化されたテストプロセスを通過したデプロイ可能なビルド成果物を手にする事ができる
CDにより、開発者は単体テストだけではなくテストも自動化出来る。これにより顧客展開する前に複数の側面からアプリの更新を検証できる
これらのテストには、UIテスト、負荷・テスト、統合テスト、API信頼性テストなどが含まれる
AWSでは、CDのために下記を提供している
- AWS CodeBuild
- AWS CodeDeploy
- AWS CodePipeline

Deployment strategies

デプロイ戦略では、ソフトウェアの提供方法を定義します。組織が使用するデプロイ戦略は、その組織のビジネスモデルによって異なります。完全にテスト済みのソフトウェアを提供する場合もあれば、開発中の機能 (ベータリリースなど) についてユーザーからの評価やフィードバックを求める場合もあります。次のセクションでは、さまざまなデプロイ戦略について説明します。

ソフトウェアの提供方法を定義する
デプロイ戦略は、組織のビジネスモデルにより異なる
完全にテスト済みのソフトウェアを提供する場合もあれば、開発中の機能についてユーザからの評価やフィードバックを求める場合もある
下記のようなものがある
- In-place deployments
- Blue/green deployment
- Canary deployment
- Linear deployment
- All-at-once deployment

In-place deployments

この戦略では、各コンピューティングリソース上のアプリケーションの以前のバージョンが停止され、最新のアプリケーションがインストールされ、アプリケーションの新しいバージョンが起動されて検証されます。これにより、基盤となるインフラストラクチャへの影響を最小限に抑えてアプリケーションのデプロイメントを進めることができます。インプレースデプロイメントでは、新しいインフラストラクチャを作成せずにアプリケーションをデプロイできますが、これらのデプロイメント中にアプリケーションの可用性が影響を受ける可能性があります。このアプローチでは、新しいリソースの作成に関連するインフラストラクチャコストと管理オーバーヘッドも最小限に抑えられます。ロードバランサーを使用すると、各インスタンスがデプロイメント中に登録解除され、デプロイメントの完了後にサービスに復元されます。インプレースデプロイメントは、サービス停止を想定して一度にすべて実行することも、ローリングアップデートとして実行することもできます。AWS CodeDeploy とAWS Elastic Beanstalk一度に 1 つずつ、半分ずつ、すべて一度に展開する展開構成を提供します。

各リソース上のアプリの以前のバージョンが停止され、最新のアプリケーションがインストールされ、新しいバージョンが起動される
新しいインフラは作らない。しかし可用性が影響を受ける可能性がある
新しいリソースの作成に関連するインフラコストと管理オーバヘッドも最小限に抑えられる
LBを使用することで、各インスタンスがデプロイ中に登録解除され、デプロイ完了後にサービスに復元される
ローリングアップデートも、一度にすべて停止することも可能

Blue/green deployment

ブルー/グリーンデプロイメント(レッド/ブラックデプロイメントとも呼ばれる) は、異なるバージョンのアプリケーションを実行している 2 つの同一環境間でトラフィックをシフトすることでアプリケーションをリリースする手法です。ブルー/グリーンデプロイメントは、アプリケーションの更新中のダウンタイムを最小限に抑え、ダウンタイムやロールバック機能に関連するリスクを軽減するのに役立ちます。

ブルー/グリーンデプロイメントを使用すると、アプリケーションの新しいバージョン (グリーン) を古いバージョン (ブルー) と並行して起動し、トラフィックを再ルーティングする前に新しいバージョンを監視およびテストし、問題検出時にロールバックすることができます。

異なるバージョンのアプリケーションを実行している2つの同一環境間でトラフィックをシフトすることでアプリケーションをリリースする手法
アプリケーションの更新中のダウンタイムを最小限に抑え、ダウンタイムやロールバック機能に関連するリスクを軽減するのに役立つ
トラフィックを再ルーティングする前に新しい、バージョンを監視およびテストし、問題検出時にロールバックできる

Canary deployment

カナリアデプロイメントの目的ワークロードに影響を与える新しいバージョンを展開するリスクを軽減します。この方法では、新しいバージョンを段階的に展開し、新しいユーザーにゆっくりと表示されるようにします。展開に自信が持てるようになったら、それを展開して現在のバージョン全体を置き換えます。

ワークロードに影響を与える新しいバージョンを展開するリスクを軽減する
新しいバージョンを段階的に展開し、新しいユーザにゆっくりと表示されるようにする
展開に自身が持てるようになったら、現在のバージョンを置き換える

Linear deployment

線形展開とは、トラフィックが均等な増分でシフトされ、各増分間の分数が均等であることを意味します。各増分でシフトされるトラフィックの割合と各増分間の分数を指定する、定義済みの線形オプションから選択できます。

トラフィックが均等な増分でシフトされ、各増分間の分数が均等であること
各増分でシフトされるトラフィックの割合と各増分間の分数を指定する

All-at-once deployment

一括展開とは、すべてのトラフィックが元の環境から置換環境に一度に移行することを意味します。

すべてのトラフィックが元の環境から置換環境に一度に移行すること

Infrastructure as code

DevOps の基本原則は、開発者がコードを扱うのと同じようにインフラストラクチャを扱うことです。アプリケーションコードには、定義された形式と構文があります。コードがプログラミング言語のルールに従って記述されていない場合、アプリケーションを作成することはできません。コードは、コードの開発、変更、およびバグ修正の履歴を記録するバージョン管理システムまたはソースコントロールシステムに保存されます。コードがコンパイルされるかアプリケーションに組み込まれると、一貫性のあるアプリケーションが作成され、ビルドが繰り返し可能で信頼できるものになることが期待されます。

インフラストラクチャをコードとして実践するということは、アプリケーションコード開発と同じ厳密さをインフラストラクチャのプロビジョニングに適用することを意味します。すべての構成は宣言的に定義し、AWS CodeCommitなどのソース管理システムに保存する必要があります。アプリケーションコードと同じです。インフラストラクチャのプロビジョニング、オーケストレーション、およびデプロイメントでも、インフラストラクチャをコードとして使用できるようにサポートする必要があります。

インフラストラクチャは、従来、スクリプトと手動プロセスの組み合わせを使用してプロビジョニングされていました。これらのスクリプトは、バージョン管理システムに保存されていたり、テキストファイルやランブックに手順ごとに文書化されていたりすることがありました。ランブックを作成した人と、これらのスクリプトを実行したり、ランブックに従って作業を行ったりする人は、多くの場合同じではありません。これらのスクリプトやランブックが頻繁に更新されないと、展開の妨げになる可能性があります。その結果、新しい環境の作成は、必ずしも繰り返し可能、信頼性が高く、一貫性があるとは限りません。

対照的に、AWS は DevOps に重点を置いたインフラストラクチャの作成と保守の方法を提供します。ソフトウェア開発者がアプリケーションコードを書く方法と同様に、AWS はプログラム的、記述的、宣言的な方法でインフラストラクチャの作成、展開、保守を可能にするサービスを提供します。これらのサービスは厳密さ、明確さ、信頼性を提供します。このホワイトペーパーで説明する AWS サービスは DevOps 方法論の中核であり、多数のより高レベルの AWS DevOps の原則と実践の基盤を形成します。

DevOpsの基本原則は、開発者がコードを扱うのと同様にインフラを扱うこと
アプリコードと同様の厳密さをインフラのプロビジョニングに適用すること
すべての構成は宣言的に定義する

Automation and tooling

DevOps のもう 1 つの中核となる哲学と実践は、自動化です。自動化は、インフラストラクチャとその上で実行されるアプリケーションのセットアップ、構成、展開、サポートに重点を置いています。自動化を使用すると、標準化された繰り返し可能な方法で環境をより迅速にセットアップできます。手動プロセスを排除することが、DevOps 戦略を成功させる鍵です。歴史的に、サーバー構成とアプリケーションの展開は主に手動プロセスでした。環境は非標準になり、問題が発生した場合に環境を再現することは困難です。

クラウドのメリットを最大限に引き出すには、自動化を活用することが重要です。AWS は内部的に、弾力性と拡張性というコア機能を提供するために自動化に大きく依存しています。

手動プロセスはエラーが発生しやすく、信頼性が低く、俊敏なビジネスをサポートするには不十分です。多くの場合、組織は、ビジネス内の他のより重要で価値の高いアクティビティのサポートに時間を費やす方がよいのに、手動構成を提供するために高度なスキルを持つリソースを拘束することがあります。

現代のオペレーティング環境では、手動による介入や実稼働環境へのアクセスを排除するために、完全な自動化が一般的に採用されています。これには、すべてのソフトウェアのリリース、マシンの構成、オペレーティングシステムのパッチ適用、トラブルシューティング、バグ修正が含まれます。さまざまなレベルの自動化手法を組み合わせて使用することで、より高度なエンドツーエンドの自動化プロセスを実現できます。

自動化には、次のような主な利点があります。

Rapid changes

Improved productivity

Repeatable configurations

Reproducible environments

Elasticity

Automatic scaling

Automated testing

自動化は、インフラとそのうえで実行されるアプリのセットアップ、構成、展開、サポートに重点を置いている
自動化により、標準化された繰り返し可能な方法で環境をより迅速にセットアップできる

自動化は AWS サービスの基盤であり、すべてのサービス、機能、およびオファリングで内部的にサポートされています。

Amazon CodeGuru

Amazon コードグルコード品質を改善し、アプリケーションの最もコストのかかるコード行を特定するためのインテリジェントな推奨事項を提供する開発者ツールです。CodeGuru を既存のソフトウェア開発ワークフローに統合すると、アプリケーション開発中のコードレビューを自動化し、運用中のアプリケーションのパフォーマンスを継続的に監視して、コード品質、アプリケーションパフォーマンスを改善し、全体的なコストを削減する方法に関する推奨事項と視覚的なヒントを提供できます。CodeGuru には 2 つのコンポーネントがあります。

Amazon CodeGuru Reviewer — Amazon CodeGuru Reviewer は、 Java および Python コードの重大な欠陥やコーディングのベストプラクティスからの逸脱を特定する自動コードレビューサービスです。プルリクエスト内のコード行をスキャンし、主要なオープンソースプロジェクトや Amazon コードベースから学んだ標準に基づいてインテリジェントな推奨事項を提供します。

Amazon CodeGuru Profiler — Amazon CodeGuru Profiler は、アプリケーションのランタイムプロファイルを分析し、コードの最も重要な部分のパフォーマンスを向上させる方法を開発者にガイドするインテリジェントな推奨事項と視覚化を提供します。

CodeGuruは、コード品質を改善、最もコストの掛かるコード行を特定するためのインテリジェントな推奨事項を提供する開発者ツール
既存のソフトウェア開発ワークフローに統合するとアプリケーション開発中のコードレビューを自動化し、運用中のアプリのパフォーマンスを継続的に監視し、下記の推奨事項と視覚的なヒントを提供できる
- コード品質
- アプリケーションパフォーマンスの改善
- 全体的なコストを削減する方法
コンポーネントは2つある
- Amazon CodeGuru Reviewer
- Amazon CodeGuru Profiler

Monitoring and observability

コミュニケーションとコラボレーションは、DevOps 哲学の基本です。これを促進するには、フィードバックが不可欠です。このフィードバックは、当社の監視および観測サービススイートによって提供されます。

コミュニケーションとコラボは、DevOps哲学の基本。フィードバックが不可欠

Communication and Collaboration

組織で DevOps 文化を導入する場合でも、DevOps 文化の変革を進める場合でも、コミュニケーションとコラボレーションはアプローチの重要な部分です。Amazon では、チームの考え方を変える必要があることに気づき、Two-Pizza Teamsのコンセプトを採用しました。

「我々はピザ2枚で賄える人数以下のチームを作るようにしています」とベゾス氏は言う。「我々はそれを『ピザ2枚チームルール』と呼んでいます。」

チームが小さいほど、コラボレーションは良くなります。ソフトウェアのリリースがかつてないほど速くなっているため、コラボレーションは非常に重要です。また、ソフトウェアを提供するチームの能力は、競合他社に対する組織の差別化要因になる可能性があります。新しい製品機能をリリースする必要がある、またはバグを修正する必要がある状況を想像してください。これをできるだけ早く実行して、市場投入までの時間を短縮する必要があります。変革をゆっくりとしたプロセスにすることは望ましくありません。変化の波が影響を与え始めるアジャイルなアプローチが必要です。

共有責任モデルに移行し、サイロ化された開発アプローチから脱却し始めると、チーム間のコミュニケーションも重要になります。これにより、所有権の概念がチームにもたらされ、プロセスをエンドツーエンドのベンチャーとして見るという視点に変わります。チームは、実稼働環境を、可視性のないブラックボックスとして考えるべきではありません。

共通の DevOps チームを構築したり、チーム内に DevOps に重点を置いたメンバーがいる可能性があるため、文化の変革も重要です。これらのアプローチは両方とも、チームに責任の共有を導入します。

Amazonでは、Two-Pizza Teamsのコンセプトを採用
チームは小さいほどコラボレーションは良くなる

Security

DevOps 変革を進めている場合でも、DevOps の原則を初めて実装する場合でも、DevOps プロセスに統合されたセキュリティについて考える必要があります。これは、ビルド、テスト、展開の各段階にわたる横断的な懸念事項です。
AWS 上の DevOps のセキュリティを検討する前に、このホワイトペーパーでは AWS 共有責任モデルについて説明します。

DevOpsプロセスに統合されたセキュリティについて考える必要がある

考察

最近、DevOpsについて再学習しています。概念的な理解はおおむねできていましたので、特段大きな発見はありませんでしたが、デプロイ戦略については、具体的な実装方法を検討していきたいと考えています。

参考