目次


サービスの継続性を提供することによって継続的デリバリー・プロセスを管理する

Comments

はじめに

この記事では、IBM UrbanCode Deploy を構成することで、顧客にサービスの継続性を提供する方法を説明します。そのために、IBM Workload Automation の実際のプロジェクトを使用して、クラウド環境で製品の高可用性を保証するように設計および実装されたアップグレード・プロセスを取り上げます。

IBM Workload Automation 環境は、「オファリング・インスタンス」と呼ばれる多くのサブ環境で構成されます。各オファリング・インスタンスは、オペレーティング・システムの仮想イメージである 2 つのノード (プライマリー・ノードとセカンダリー・ノード) で構成されます (図 1 を参照)。

Workload Automation のコンポーネントは、高可用性を実現するために両ノードのマシンにインストールされます。

図 1. 継続的デリバリー・ソリューションのアーキテクチャー
継続的デリバリー・ソリューションのアーキテクチャーの図
継続的デリバリー・ソリューションのアーキテクチャーの図

インストールされる Workload Automation (WA) コンポーネントは、サーバー・コンポーネントである WA マスターと、ユーザー・インターフェース・コンポーネントである動的ワークロード・コンソール (Dynamic Workload Console: DWC) です。

各コンポーネントには、高可用性を実現するための独自のメカニズムがあります。

  • WA マスターは高可用性を実現する手段として、処理を 2 番目のノード (バックアップ・マスター) で行うように切り替えるためのスイッチ・マスターを使用します。
  • DWC は高可用性を実現するために、共通のリモート・データベース・リポジトリーでデータを共有します。

この記事では、WA マスター・コンポーネントのアップグレード・プロセスに注目します。アップグレード・プロセスを設計する際には、以下の制約を考慮します。

  1. サービスの中断を避ける上で、プライマリー・ノードとセカンダリー・ノードのコンポーネントのアップグレードを同時に実行することはできません。
  2. 更新処理を環境全体に実行しなければなりません。また、同じサブ環境にあるプライマリー・ノードとセカンダリー・ノードを同期させなければなりません。

制約 1 を考慮すると、アップグレード・プロセスを 1 つのステップで実行することはできません。この例では、アップグレード・プロセスは 4 つのフェーズで行われます。

  • フェーズ 1: このフェーズにおいて、すべてのセカンダリー・ノードがアップグレードされます。セカンダリー・ノードはアクティブではないため (プライマリー・ノードがアクティブ・ノードです) アップグレード処理によってサービスが中断されることはありません。
  • フェーズ 2: このフェーズにおいて、プライマリー・ロールがプライマリー・ノードからセカンダリー・ノードへと切り替えられます。この切り替えによって、セカンダリー・ノードがアクティブ・ノードになります。
  • フェーズ 3: このフェーズにおいて、すべてのプライマリー・ノードがアップグレードされます。フェーズ 2 の終了後、プライマリー・ノードはアクティブではありません。そのため、この操作によってサービスが中断されることはありません。
  • フェーズ 4: このフェーズで、プライマリー・ロールがセカンダリー・ノードからプライマリー・ノードへ切り戻されます。

各フェーズは、前のフェーズが完了するまで開始することができません。

制約 2 は、各サブ環境の 2 つのノードが、他のどのサブ環境にも影響を及ぼすことなく同期するメカニズムを実装する必要があることを意味します。

ここに記述した方法を使用することで、フェーズ 1 における更新プロセスがいくつかの環境で失敗したとしても、他の環境ではプロセスが継続されて、正常にアップグレードが行われます。

UrbanCode Deploy を使用してソリューションを実装する

Workload Automation のシナリオでは、制約 1 を実装するために UrbanCode Deploy を使用します。4 つのアプリケーション・プロセスは、バージョンのステータス (状況) を使用して同期が取られます。4 つのプロセスが確実に正しい順番で処理されるようにするために、各フェーズの終わりでは、インストールされるバージョンに対し、プロセスによってステータス (状況) が追加されます。このバージョンのステータス (状況) は、次のフェーズで必要になります。

制約 2 は、同じサブ環境にあるプライマリー・ノードとセカンダリー・ノードの間で共有されるリソース・プロパティーによって実装されます。

このシナリオでは、以下のステップに従ってソリューションを実装します。

  • 環境を定義します。すべてのオファリング・インスタンスを単一の UrbanCode Deploy 環境として定義し、同じサブ環境のノードをグループ化します。環境は多くのサブ環境で構成され、各サブ環境はいくつかのノードで構成されます。環境の定義では、命名規則を適用することで、同じサブ環境に属するノードを識別します。
  • バージョンのステータス (状況) を定義します。アプリケーション・プロセス間の同期に使用する UrbanCode Deploy のバージョンのステータス (状況) を構成します。
  • フェーズ 1 のアプリケーション・プロセスを定義します。すべてのセカンダリー・ノードを更新するプロセスを実装し、フェーズ 1 が完了したため、フェーズ 2 を開始できることを示すバージョンのステータス (状況) を設定します。
  • フェーズ 2 のアプリケーション・プロセスを定義します。処理を行うノードをプライマリー・ノードからセカンダリー・ノードに切り替えるプロセスを実装し、フェーズ 2 が完了したため、フェーズ 3 を開始できることを示すバージョンのステータス (状況) を設定します。
  • フェーズ 3 のアプリケーション・プロセスを定義します。すべてのプライマリー・ノードを更新するプロセスを実装し、フェーズ 3 が完了したため、フェーズ 4 を開始できることを示すバージョンのステータス (状況) を設定します。
  • ェーズ 4 のアプリケーション・プロセスを定義します。処理を行うノードをセカンダリー・ノードからプライマリー・ノードに切り戻すプロセスを実装します。

環境を定義する

環境は、自動入力のメカニズムを通じて UrbanCode Deploy で定義されています。自動入力のメカニズムは、記事「Manage continuous delivery in the dynamic cloud environment using IBM UrbanCode Deploy」で説明しています。

環境は、プライマリー・ノードおよびセカンダリー・ノードという 2 つのグループで構成されています。図 2 に示すように、最初のグループには、プライマリー・ノードにインストールされているすべてのエージェントが含まれており、2 番目のグループにはセカンダリー・ノードにインストールされているすべてのエージェントが含まれています。

図 2. UrbanCode Deploy での本番環境定義
UrbanCode Deploy 環境タブのスクリーン・ショット
UrbanCode Deploy 環境タブのスクリーン・ショット

各グループには、プライマリー・ロールとセカンダリー・ロールに関係するプロパティーのセットが定義されています。以下の命名規則に従ってエージェント名を設定します。

 <ENV_TYPE>_<NODE_TYPE>_<ENV_ID>
  • ENV_TYPE: 環境タイプ (例えば、QA または本番) の識別子
  • NODE_TYPE: プライマリー (P) または セカンダリー (S) のいずれか
  • ENV_ID: 個々のオファリング・インスタンスの識別に使用される英数字の ID

同じ環境に関連付けられているプライマリー・ノードとセカンダリー・ノードには、NODE_TYPE 識別子 (P または S) の部分を除いて同じ名前が付けられています。例えば、環境 001 に関係するプライマリー・ノードとセカンダリー・ノードは、PROD_P_001 および PROD_S_001 という名前になります。

プロセスのフェーズを同期させるためにバージョンのステータス (状況) を定義する

4 つのフェーズは 4 つ別々の UrbanCode Deploy アプリケーション・プロセスで実装されます。

4 つのプロセスが確実に正しい順番で行われるようにするために、各フェーズの終わりでは、インストールされるバージョンに対して、特定のステータス (状況) がプロセスによって追加されます。アプリケーション・プロセスは、図 3 に示すようにバージョンのステータス (状況) が適切な場合にのみ開始されるように構成されています。したがって更新プロセス全体は、バージョンのステータス (状況) が適切な場合にのみ開始することができます。ここで説明されているケースでは、バージョンのステータス (状況) は環境ゲートの役割を果たします。

図 3. 各フェーズの完了時に設定されるバージョンのステータス (状況)

この構成は以下のステップで実装されます。

  1. バージョンのステータス (状況) を構成する。
  2. 環境ゲートを構成する。
  3. アプリケーション・プロセス内でバージョンのステータス (状況) の制約を構成する。
  4. バージョンに対してステータス (状況) の追加と削除を行うプロセスを実装する。

バージョンのステータス (状況) を構成する

バージョンのステータス (状況) を定義するには、図 4 で示すように「Settings (設定)」 > 「Plugins (プラグイン)」 > 「Status (状況)」の順にクリックします。

図 4. バージョンのステータス (状況) の定義
バージョンのステータス (状況) タブのスクリーン・ショット
バージョンのステータス (状況) タブのスクリーン・ショット

環境ゲートを構成する

フェーズ 1 で始まる更新プロセス全体を、特定の環境で実行可能なのは、その環境のバージョンのステータス (状況) が適切な場合のみです。この制約はアプリケーション・レベルで指定されます。

「Application (アプリケーション)」 > 「Configuration (構成)」 > 「Environment Gates (環境ゲート)」の順にクリックし、具体的な環境で必要となるステータス (状況) を指定します。環境ゲートでは、コンポーネント・バージョンのステータス (状況) が、ゲートで指定されたステータス (状況) と同じでなければ、そのコンポーネント・バージョンを環境にデプロイすることができないようにするメカニズムを提供しています。例えば、図 5 ではバージョンのステータス (状況) が Staging_OK である環境のみを本番環境で使用することができます。

図 5. 環境ゲートの定義
ステージング環境と本番環境の環境ゲートを表示する画面のスクリーン・ショット
ステージング環境と本番環境の環境ゲートを表示する画面のスクリーン・ショット

アプリケーション・プロセス内でバージョンのステータス (状況) の制約を構成する。

フェーズ 1 の終わりで、新しいステータス (状況) がコンポーネント・バージョンに追加されます。ステータス (状況) は <ENVIRONMENT>_Phase1_OK です。例えば、本番環境フェーズの終了時点でのバージョンのステータス (状況) は Production_Phase1_OK です。

フェーズ 2 を開始するには、コンポーネント・バージョンのステータス (状況) が <ENVIRONMENT>_Phase1_OK でなければなりません。図 6 に示すように、この制約はアプリケーション・プロセス・レベルで指定されます。

図 6. アプリケーション・プロセスの定義
PROD_PHASE1 の基本設定を表示する画面のスクリーン・ショット
PROD_PHASE1 の基本設定を表示する画面のスクリーン・ショット

このフェーズの完了時に、コンポーネント・バージョンからステータス (状況) <ENVIRONMENT>_Phase1_OK が削除され、ステータス (状況) <ENVIRONMENT>_Phase2_OK がコンポーネント・バージョンに追加されます。

同様の方法で、フェーズ 3 では <ENVIRONMENT> _Phase2_OK というバージョンのステータス (状況) が必要となります。完了すると、このステータス (状況) は削除され、<ENVIRONMENT> _Phase3_OK というステータス (状況) が追加されます。

最終フェーズでは <ENVIRONMENT> _Phase3_OK というステータス (状況) が必要となります。このフェーズの終わりでは、バージョンにはステータス (状況) <ENVIRONMENT>_OK が設定され、その環境タイプの更新が完了したことを示します。

図 7 に示すように、「Component (コンポーネント)」 > 「Versions (バージョン)」の順にクリックすることによって、バージョンに関連付けられたステータス (状況) をモニターすることができます。

図 7. 各バージョンに関連付けられたステータス (状況)
コンポーネント・バージョンのステータス (状況) パネルのスクリーン・ショット
コンポーネント・バージョンのステータス (状況) パネルのスクリーン・ショット

バージョンに対してステータス (状況) の追加と削除を行うプロセスを実装する

バージョンに対するステータス (状況) の関連付けを実装するために、図 8 に示すようにステータス (状況) の変更のそれぞれに対するコンポーネント・プロセスを定義します。

図 8. コンポーネント・プロセスの定義
ステータス (状況) の変更に関するコンポーネント・プロセスを定義するワークフロー
ステータス (状況) の変更に関するコンポーネント・プロセスを定義するワークフロー

アプリケーション・プロセスのフェーズ 1 を定義する

フェーズ 1 では、すべてのセカンダリー・リソースに対するマスター・コンポーネントのアップグレードが実行され、その後、コンポーネント・バージョンの新しいステータス (状況) が関連付けられます (図 9 を参照)。

図 9. アプリケーション・プロセスのフェーズ 1 の定義
バージョンのステータス (状況) の更新ワークフロー
バージョンのステータス (状況) の更新ワークフロー

最初のステップでは、セカンダリー・ノードのマスター・コンポーネントを更新するプロセスが実行されます。このプロセスでは、更新が正常に完了し次第、最新のバージョンが正常にインストールされたことを示すプロパティーがエージェント・レベルで設定されます。

: このプロパティーが設定されるエージェントは、正常に更新されたセカンダリー・ノードにインストールされているエージェントではなく、対応するプライマリー・ノードにインストールされているエージェントです。

プロパティー名は secondaryVersionLevel で、対応する値は、現在インストールされているコンポーネント・バージョンの ID になります。プロパティーの設定は、コンポーネント・プロセスの 2 つのステップで実行されます。

最初のステップでは、現在プロセスが実行されているセカンダリー・ノードに対応するプライマリー・エージェントの名前を推測します。図 10 にステップの定義を示します。

図 10. コンポーネント・プロセスのステップの定義
コンポーネント・プロセスの新しいステップを定義する画面のスクリーン・ショット
コンポーネント・プロセスの新しいステップを定義する画面のスクリーン・ショット

後処理のステップ SetOutputProperty は、前のステップで推測した名前を変数に設定し、次のステップで使用できるようにします。この変数を定義するには、リスト 1 のスクリプトを使用します。

リスト 1. 後処理スクリプトの例
properties.put("result", "default");
if (properties.get("exitCode") != 0) {
	properties.put(new java.lang.String("Status"), new 		java.lang.String("Failure"));
 }
 else {
 properties.put("Status", "Success");
 scanner.register("^Output", function(lineNumber, line) {
 var temp=line.split("=");
var out=temp[1];
 properties.put("result",out);
 });
 scanner.scan();
   }

2 番目のステップで設定するエージェント・プロパティーには、前のステップで推測したエージェント名を指定します (図 11 を参照)。

図 11. エージェント・プロパティーの設定
エージェント・プロパティーを設定する画面のスクリーン・ショット
エージェント・プロパティーを設定する画面のスクリーン・ショット

このステップの終わりでは、アップグレード・プロセスを正常に完了したセカンダリー・ノードに関して、対応するプライマリー・ノードにインストールされているすべてのエージェントが、プロパティー secondaryVersionLevel の値として、現在インストールされているコンポーネント・バージョンの ID を持つようになります。

アプリケーション・プロセスの 2 番目のステップでは、ステータス (状況) がコンポーネント・バージョンに変更されます。この変更により「プロセスのフェーズを同期させるためにバージョンのステータス (状況) を定義する」セクションの中で定義された関連コンポーネント・プロセスが実行されるようになります。ステータス (状況) の変更に関連するアプリケーション・プロセスのステップは、そのポイントに最初に到達したリソース上のみで実行されなければなりません (図 12 を参照)。

図 12. ステップ・プロパティー
アプリケーション・プロセスのステップの設定画面のスクリーン・ショット
アプリケーション・プロセスのステップの設定画面のスクリーン・ショット

アプリケーション・プロセスのフェーズ 2 を定義する

2 番目のフェーズでは、サーバーがプライマリー・ノードからセカンダリー・ノードへ切り替えられた後、新しいステータス (状況) がコンポーネント・バージョンに関連付けられます (図 13 を参照)。

図 13. アプリケーション・プロセスのフェーズ 2 の定義
切り替えとバージョンのステータス (状況) 更新のワークフロー
切り替えとバージョンのステータス (状況) 更新のワークフロー

このプロセスはプライマリー・ノードで実行されますが、フェーズ 1 が正常に完了したサブ環境のみで実行されなければなりません。

対応するセカンダリー・ノードが正常に更新され、フェーズ 1 が正常に完了していることを確認してください。アップグレード処理を実行する前に、secondaryVersionLevel が現在インストールされているコンポーネント・バージョンの ID を値に持つことを確認してください。この確認をするには、3 つのコンポーネント・ステップを使用します (図 14 を参照)。

図 14. コンポーネント・プロセスの一部
アップグレードが成功しているかどうかを確認するためのワークフロー
アップグレードが成功しているかどうかを確認するためのワークフロー
  1. 最初のステップでは、プロパティーの値を取得します (図 15 を参照)。
図 15. コンポーネント・プロセスのステップ構成
コンポーネント・プロセスでプロパティーの値を取得する画面のスクリーン・ショット
コンポーネント・プロセスでプロパティーの値を取得する画面のスクリーン・ショット
  1. 2 番目のステップでは、プロパティーの値が現在インストールされているコンポーネント・バージョンの ID と一致することを検証し、その結果を result プロパティーに true または false という値で設定します (図 16 を参照)。
図 16. プロパティーを確認するステップ
出力を確認する後処理ステップの画面のスクリーン・ショット
出力を確認する後処理ステップの画面のスクリーン・ショット
  1. 最後のステップでは、ステップ 2 で設定されたプロパティーの値を利用します。プロパティーが false の場合、プロセスは実行されません (図 17 を参照)。
図 17. 切り替えステップの定義
切り替えを定義する「Edit Properties (プロパティーの編集)」画面のスクリーン・ショット
切り替えを定義する「Edit Properties (プロパティーの編集)」画面のスクリーン・ショット

アプリケーション・プロセスのフェーズ 3 を定義する

3 番目のフェーズでは、プライマリー・ノードを更新し、適切なバージョンのステータス (状況) を設定します。

: サーバーがセカンダリー・ノードに切り替えられているため、プライマリー・ノードは、現在、非アクティブ・ノードになっています (図 18 を参照)。

図 18. アプリケーション・プロセスのフェーズ 3 の定義
サーバーの切り替えを行うためのワークフロー
サーバーの切り替えを行うためのワークフロー

このプロセスは、以下の条件を満たしているときにのみ開始することができます。

  • プライマリー・ノードがアクティブではない。例えば、サーバーがセカンダリー・ノードに切り替えられている。
  • セカンダリー・ノードの更新が正常に完了し、プロパティー secondaryVersionLevel が現在インストールされているコンポーネント・バージョンに設定されている。

プライマリー・ノード上でアップグレードが正常に完了し次第、エージェントのプロパティーが設定されます。

このプロパティーが設定されるエージェントは、正常に更新されたプライマリー・ノードにインストールされているエージェントではなく、対応するセカンダリー・ノードにインストールされているエージェントです。プロパティー名は primaryVersionLevel で、対応する値は、現在インストールされているコンポーネント・バージョンの ID になります。

アプリケーション・プロセスのフェーズ 4 を定義する

4 番目のフェーズでは、サーバーはセカンダリー・ノードからプライマリー・ノードへ切り戻されます。

この操作は、前の 3 つのフェーズが正常に完了しているサブ環境のみで実行されなければなりません。このチェックが実行され、プロパティーの値が primaryVersionLevel であることが検証されます。

このプロセスの終わりでは、ステータス (状況) <Environment>_OK がバージョンに関連付けられます (図 19 を参照)。

図 19. アプリケーション・プロセスのフェーズ 4 の定義
プロセスを環境に関連付けるワークフロー
プロセスを環境に関連付けるワークフロー

まとめ

この記事では、複雑な環境におけるさまざまなレベルのアップグレード・フェーズでの同期について説明しました。ここで取り上げたメカニズムは、本番環境でのサービスの継続性を確保する上で極めて重要です。このアプローチは、同じような特徴を持つすべての「アクティブ ― アクティブ」構成および「アクティブ ― パッシブ」構成を対象として拡張すること、または一般化することができます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=982945
ArticleTitle=サービスの継続性を提供することによって継続的デリバリー・プロセスを管理する
publish-date=09252014