How to realize the continuous release of applications?

01 継続的リリースの概要

リリースのプロセスでは、多くの問題に直面することがあります。

1. 手動デプロイでは、リリースに時間がかかりすぎるためエラーが頻繁に発生し、リリースの問題を手動で修正する必要があります。

2. 環境が分離されている場合、各環境間の差異が大きく、本番環境に近い環境が存在しないため、環境に関する問題が顕在化します。環境の不安定性により、最初のデプロイ時に本番環境での状況を判断できません。

3. クラスターへのリリースでは、各環境の設定が異なるため手動で修正する必要があります。この時点ではノードの設定はほぼ制御不能であり、本番環境の設定を直接変更する場合は比較的高いリスクを伴います。

4. 複数の開発者が協力し、リリース中に頻繁な更新が行われる場合、お互いにブロックが発生します。このため、運用保守、開発、テストの連携コストが非常に高くなります。

継続的リリースのプロセスでは、複数人での開発、シンプルなデプロイ、安定した環境、継続的な自動検証、機能の高速イテレーション、リリース方式の設定をサポートし、機能の安定性を確保できることが求められます。リリース中に問題が発生した場合は、安定したバージョンに素早くロールバックし、問題を迅速にフィードバックできる必要があります。

測定指標はチームの行動に直接的な影響を与えます。コード行数を開発者の指標として選択すると、開発者はパフォーマンスのために簡潔なコードを書かなくなります。この現象をホーソン効果と呼びます。

デリバリープロセスでは、サイクルタイムを測定指標として選択できます。サイクルタイムとは、開発開始から最終デリバリーまでの時間を指します。

たとえば、リソース準備において、環境リソースの準備から環境が完全に利用可能になるまでの期間がリソース準備のサイクルタイムです。現在クラウド上では、予算申請後にオンラインで直接購入できるため、リソース調達サイクルを大幅に短縮できます。

リリース有効性とは、機能の開発検証、リリース準備から顧客へのデリバリーまでの期間を指します。リリースの準備時間、リリース環境の設定時間、段階的リリースの時間、リリースに関するフィードバックの速度などが含まれます。

02 継続的リリースの構築パス

サイクルタイムを短縮するには、プロセス全体の自動化を実現する必要があります。環境、ソフトウェアパッケージ、ネットワーク設定、インフラストラクチャ、外部サービスなどを、構築、デプロイ、テスト、リリースの各側面からバージョン管理に組み込みます。

アプリケーションをリリースする際は、ソフトウェアに必要な実行環境を準備し、必要なインフラストラクチャや外部サービス依存関係などを設定する必要があります。ソフトウェアをインストール環境で実行し、必要なデータと状態を設定することで、ソフトウェアのデリバリーを完了できます。

バージョン管理では、要件定義書、テストスクリプト、自動化テストケース、ネットワーク設定、データベースの作成、アップグレード、初期化、ロールバックなど、すべてをバージョン管理下に置く必要があります。

また、チーム内で合意形成を図る必要があります。継続的リリースのプロセスでは、チームはリリース仕様に従い、プロセス全体を継続的に改善し、リスクを管理可能な状態に保つ必要があります。

03 クラウド上での継続的リリースの実践

次に、継続的リリースの手順について説明します。環境準備では、入力テンプレートを使用し、既存のテンプレートまたはカスタムテンプレートでクラウド環境を記述します。入力パラメーターを指定して自動デプロイを実行します。最後に、リソースデプロイの完了を確認し、後続の管理を行います。

このリソース準備プロセスは、企業の迅速なクラウド移行、オンデマンドでのバッチデプロイ、アプリケーションに必要なリソースの迅速な複製、既存リソースを活用したアプリケーションの迅速な構築に適しています。

継続的ビルドでは、サービスコードのパッケージを作成して OSS にアップロードします。ユーザーは関連する環境パラメーターを入力して、対応するソフトウェアパッケージを取得します。次に、運用保守のオーケストレーションを通じて、対応するパッケージ情報を ECS にプルします。クラウドアシスタントが対応するデプロイスクリプトを実行し、アプリケーションを起動して外部サービスを提供します。

ビジネスが拡大し、現在のマシンでサービスを処理できなくなった場合は、Auto Scaling によりマシンのスケールアウトとスケールインを迅速に行い、自動デプロイを実現できます。

継続的リリースでは、主に Auto Scaling をベースにしたローリングアップグレードを採用します。まずスケーリングアクティビティを停止し、インスタンスをグループ化してスタンバイ状態にします。対応するインスタンスはリリースプロセス中に外部サービスを提供しません。リリース完了後、インスタンスはスタンバイ状態を終了し、外部サービスを提供します。

ローリングアップグレードは、カナリアリリース、ブルーグリーンリリース、バッチリリースなどのシナリオに適しています。運用保守オーケストレーションでソフトウェアパッケージを作成し、スケーリンググループを作成して ECS インスタンスを追加してから、ローリングアップグレードタスクを実行します。

04 アプリケーションの継続的リリース

次に、継続的リリースの原則について説明します。アプリケーションリリースは、低リスク、高頻度、低コスト、迅速かつ予測可能なプロセスであるべきです。

このプロセスでは、スクリプト化、バージョン管理、リプレイ、フィードバックが必要です。自動化の面では、自動デプロイ、自動テスト、自動フィードバックを実現する必要があります。

管理の面では、バージョン管理、依存関係管理、環境管理、設定管理を強化する必要があります。迅速なロールバック、迅速な再リリース、トレーサビリティを実現します。問題が発生した場合は、継続的に改善し、高頻度にイテレーションし、迅速にフィードバックし、生産サイクルを短縮できます。

ライフサイクルデリバリーのトレーサビリティと可観測性を向上させることで、より効果的なリリースが可能になります。

上の図に示すように、継続的リリースに関連するサービスには、主にクラウド、環境準備、コードビルド、自動デプロイ、継続的リリースがあります。

環境準備では、ROS、Terraform、ECS、ACS、OSS などのクラウドリソース製品を通じて準備できます。コードビルド中は、ACMS や RDC Cloud Effect を通じてアプリケーション設定管理を行えます。

自動デプロイでは、EDAS や OSS を通じてデプロイとビルドを実行できます。継続的リリースでは、RDC Cloud Effect を通じてデプロイパイプラインをカスタマイズし、Auto Scaling による継続的リリースを実施できます。

Q&A セクション、ユーザー Q&A

Q1 ホーソン効果は、研究対象が自分が研究されていることを自覚することで生じる人為的な効果です。クラウド自動化後、この状況を完全に回避できますか？

回答：継続的リリース時にどの測定方法が適切かを判断する必要があります。測定指標が誤った指標であると仮定すると、ホーソン効果により結果に偏差が生じます。測定指標が信頼できるものであれば、ホーソン効果により指標はますます良くなります。

Q2 パイプラインデプロイには、リソース関連、データ関連、アクセス制御関連などの問題が関わります。発生する可能性のある問題を効果的に解決するにはどうすればよいですか？

回答：パイプラインデプロイは一般的にアプリケーション単位で実施されます。アプリケーションを設定する際に、リソースデータの権限を設定する必要があります。さらに、クラウド上のアクセス制御機能を活用して、セキュリティを強化することもできます。