Amazon Web Services ブログ
AWS Mainframe Modernization の AWS Blu Age に於けるビルド、テスト、デプロイを自動化する
はじめに
ビルド、テスト、デプロイのプロセスを自動化することは、モダンなソフトウェア開発とデリバリーの基本的な要素です。継続的インテグレーション (CI)、継続的テスト (CT)、継続的デプロイ (CD) の強力なパイプラインを実装することで、組織は効率を高め、市場投入までの時間を短縮します。
このブログ記事では、柔軟な環境でコンパイルと機能同等性テストを自動化する継続的インテグレーション、継続的テスト、継続的デリバリー (CI/CT/CD) パイプラインを紹介します。これにより、本番環境にあるようなプレッシャーや制約を受けることなく、問題を特定し、アプリケーションのコア機能を検証することができます。検証後、パイプラインはマネージド環境にアプリケーションをデプロイし、受け入れテストや本番稼働前の動作確認を行います。
AWS Blu Age でリファクタリングされたアプリケーションに対する CI/CT/CD の実装
CI/CT/CD を実装すると、ソフトウェア開発とデプロイプロセスに付加価値が組み込まれます。その価値は、ソフトウェア開発ライフサイクルを速く回し、コード品質を向上させ、開発およびデプロイプロセスの全体的な効率と信頼性を高めることにあります。AWS Blu Age でリファクタリングされたアプリケーションは、Java Spring Boot (バックエンド) と Angular (フロントエンド) アプリケーションへの変換により、メインフレームアプリケーションをモダナイズしたものです。AWS Blu Age ツールを使用すると、COBOL、PL/I、RPG/400 で記述されたレガシーアプリケーションをモダンなアプリケーションに自動的に変換できます。このアプローチにより、既存のビジネスロジックへの投資を抑えながら、次のようなメリットが得られます。
- 新しいテクノロジーの使用によるアジリティの向上
- モダンスタックに精通した開発者から成る幅広い人材プールへのアクセス
- モダナイゼーションプロジェクトの加速
リファクタリングプロセスにより、基盤となるデータベースとデータモデルが最新の形式に変換され、アプリケーションの機能と互換性が強化されます。
継続的テストの実践により CI/CT/CD パイプラインを確立することは、モダナイズされたシステムの機能をレガシーシステムと同等に保つために不可欠です。テストはモダナイゼーションプロジェクトの労力と予算の 60 ～ 70% を消費する可能性があるため、ビジネス価値を迅速に実現するためにはテストの自動化が不可欠です。
CI/CT/CD パイプラインステージ
パイプラインは次の 5 つのステージで構成されています。
- アプリケーションソースコードの取得
- アプリケーションビルド
- アプリケーションの機能同等性テスト
- 手動承認
- マネージド環境でのデプロイ
CI/CT/CD パイプラインのアーキテクチャとデプロイ
図 1 は、AWS CodePipeline を使用してモデル化された CI/CT/CD パイプラインの 5 つのステージの概要を示しています。関連するインフラストラクチャは AWS CloudFormation によってプロビジョニングされます。
CloudFormation は、インフラストラクチャのプロビジョニング、再利用性、一貫性、信頼性を実現する強力な IaC (Infrastructure as Code) サービスです。これにより、アプリケーションの実行に必要なリソースをモデル化します。
AWS CodePipeline は、継続的インテグレーションと継続的デリバリーのサービスであり、ソフトウェアリリースプロセスをモデル化して自動化します。パイプラインはワークフローを定義し、開発段階とデプロイ段階でコード変更がどのように進行するかを記述します。パイプラインの各ステージは、コードのビルドやテスト環境へのデプロイなどの一連のアクションで構成されています。
図 1 — CI/CT/CD パイプラインのアーキテクチャ図
アーキテクチャ図に示されている各ステージのタスクについて、次のセクション以後で説明します。
ステージ 1 — アプリケーションコードの取得
前提条件
- 開発チーム用に Git リポジトリが作成され、設定されていること
- AWS Blu Age Transformation Center から生成されたアプリケーションソースコードが Git リポジトリにロード済であること
- AWS CodePipeline は、Git リポジトリのメインブランチへのコミット時にアクティブ化されるようセットアップと設定が完了していること
開発プロセス
- 開発者は Git リポジトリをローカルの開発環境に複製します。
- 開発者は機能やバグの修正用に新しいブランチを作成します。
- 開発者は、チームのコーディング標準とベストプラクティスに従って、必要なコード変更を行います。
- 開発者はローカルテストを実施してコードの品質と機能を確認します。
- 開発者は、コミットメッセージに説明を記述して、変更をローカルブランチにコミットします。
- 開発者はブランチを Git リポジトリにプッシュします。
AWS CodePipeline のアクティベート
メインブランチにマージすると、AWS CodePipeline が自動的にアクティベートされます。
ステージ 2 — アプリケーションのビルド
AWS CodePipeline は CI/CT/CD パイプラインの一部として AWS CodeBuild ステップを開始します。このステップでは、AWS CodeBuild は AWS Blu Age Build ツールを使用して、レガシー言語からの変換によってモダナイズされた Java アプリケーションをビルドします。
ビルドプロセス
- CodeBuild はパイプラインの前段のステージからソースコードを取得します。
- CodeBuild は AWS CodeArtifact に接続して、必要な AWS Blu Age ランタイムライブラリをダウンロードします。
- 2 つの異なる WAR (Web Application Archive) ファイルが生成されます。
- HTML、JavaScript、CSS ファイルなどの静的 Web サイトアセットで構成されるフロントエンドアプリケーション: この構造により、柔軟なデプロイオプションが可能になります。フロントエンドは Apache HTTP Server や Amazon CloudFront などのさまざまなコンテンツ配信ネットワーク (CDN) ソリューションでホストできるため、コンテンツ配信とユーザーエクスペリエンスが最適化されます。
- バックエンドアプリケーション
- CodeBuild は WAR ファイルを Amazon S3 に安全に保存します。
このアプローチにより、フロントエンドコンポーネントとバックエンドコンポーネントを明確に分離しやすくなり、各階層の独立したスケーリングと管理が可能になります。また、フロントエンドをエッジロケーションにデプロイしてレイテンシーを短縮し、バックエンドをより制御された環境でホストしてセキュリティとデータ管理を強化することもできます。
ステージ 3 — アプリケーションの機能同等性テスト
レガシーメインフレームアプリケーションと AWS クラウド上のモダナイズされたメインフレームアプリケーションが機能的に同等であることを検証するために、AWS Mainframe Modernization Application Testing が使われます。このテストフレームワークは、モダナイゼーションプロセス全体を通じて機能の一貫性を検証するように設計されています。
前提条件
テストチームは AWS Mainframe Modernization Application Testing 内で以下のアーティファクトを作成します。
- テストケース: テストアクションの最小単位です。テストケースを作成する際に、移行元のシステムと移行先のシステムの間の機能的な同等性を確認できるよう、ユーザーは比較対象のデータ型を識別します。
- テストスイート: 一連のテストケースを順番に実行します。
- テスト環境設定: これには、反復可能なテストを実施するために必要なすべてのパラメーターとリソースが含まれます。CloudFormation テンプレートは、テスト環境で反復可能なテストを実行するために必要な初期データおよび設定パラメーター (リソース) の設定に使用されます。このアプローチにより、テストを繰り返しても一貫性と再現性が保証されます。
テストプロセス
テストプロセスには主に 3 つの段階があります。
-
Record
- ユーザーは各テストケースの参照データをメインフレーム上に作成します。
- この参照データには、ソースメインフレームのアーティファクト、データセット、リレーショナルデータベースの Change Data Capture (CDC) ジャーナルが含まれます。
- Record ステージは通常、プロジェクトの開始時に 1 回実行して、必要な参照データをすべて収集します。
-
Replay
- 本機能により、移行先の環境でテストスイートを実行します。
- 個々のテストケースで生成されたデータセット、データベース変更、3270 画面をキャプチャします。
-
Compare
- 本機能は、移行元のテストの参照データと移行先のリプレイデータを一通り比較します。
- 結果は、同一データ、異なるデータ、同等データ、または欠損データとして分類されます。
- Compare の出力は Amazon S3 に保存され、指定された承認者による審査を受けます。
CI/CT/CD パイプラインは、Replay および Compare の各ステージを自動的に開始し、開発プロセス全体を通して一貫性のある反復可能なテストを保証します。
このテストの主な目的は、モダナイズされたアプリケーションがメインフレームアプリケーションと同じように動作することを検証することです。左記は、参照データとリプレイデータの不一致を綿密に特定することで達成されます。これにより、モダナイゼーションプロセスが確実に成功し、信頼できるものになります。
ステージ 4 — 手動承認
パイプラインの一時停止
機能同等性テストが完了すると、AWS CodePipeline は手動承認段階で自動的に停止し、本番前または承認環境にデプロイされます。
承認プロセス
- AWS CodePipeline は、プロジェクトマネージャ、品質保証 (QA) リーダー、個別に設定したレビュー担当者などの関係者に保留中のレビューを通知します。
- レビュー担当者は Amazon S3 に保存されている比較レポートにアクセスします。これらのレポートには次のものが含まれます。
- 参考データ
- 再生データ
- レビュー担当者はレポートを審査して承認します。これで AWS CodePipeline が再開されます。
ステージ 5 — マネージドランタイム環境でのアプリケーションの展開
最後のステージは、承認されたアプリケーションを AWS Mainframe Modernization Automated Refactor のマネージドランタイムにデプロイすることです。AWS CodeBuild は、AWS Cloud Development Script (AWS CDK) を活用したスクリプト (Python スクリプトなど) を呼び出すために使用されます。このスクリプトは次のシナリオに基づいてタスクを実行します。
シナリオ 1: AWS Mainframe Modernization 環境が存在しないことを、AWS Systems Manager (SSM) Parameter Store を使用して確認しました。このときの AWS CodeBuild のステップ:
- AWS Mainframe Modernization のマネージドランタイム環境を作成し、環境 ID を SSM に保存します。
- Mainframe Modernization アプリケーションを作成し、アプリケーション ID を SSM に保存します。
- アプリケーションをマネージドランタイムにデプロイします。
- アプリケーションを起動します。
シナリオ 2: AWS Mainframe Modernization 環境とアプリケーションは既に存在します。このときの AWS CodeBuild のステップ:
- 実行中のアプリケーションを停止します。
- アプリケーションを更新して、AWS Mainframe Modernization マネージドランタイム環境に新しいバージョンを作成し、新しいアーカイブファイルを反映します。
- アプリケーションを起動します。
環境とアプリケーションの可用性をほぼ 100% にするには、ブルー/グリーンデプロイメントを使います。ブルーは現在のアクティブなインスタンス、グリーンは新しいインスタンスを表します。テスト完了後、トラフィックはグリーンのインスタンスにリダイレクトされ、問題が発生した場合はブルーのインスタンスにトラフィックをリダイレクトしてロールバックできます。これは以下のように実装されます。
シナリオ 1: AWS Mainframe Modernization 環境が存在しないことを、SSM Parameter Store を使用して確認しました。このときの AWS CodeBuild のステップ:
- 2 つの AWS Mainframe Modernization マネージドランタイム環境 (ブルーとグリーン) を作成し、その環境 ID を SSM に保存します。
- Mainframe Modernization アプリケーションを作成し、アプリケーション ID を SSM に保存します。
- 作成したマネージドランタイム環境の 1 つにアプリケーションをデプロイします。これを (ブルー環境の) 環境 ID として SSM 内でマークします。
- アプリケーションを起動します。
シナリオ 2: AWS Mainframe Modernization 環境とアプリケーションは既に存在します。このときの AWS CodeBuild のステップ:
- 新しいアーカイブファイルを反映する新しい Mainframe Modernization アプリケーションを作成します。
- 新しいアプリケーションを、AWS Mainframe Modernization のグリーン環境にデプロイします。
- アプリケーションを起動します。
- Amazon Route 53 のアプリケーション参照を更新し、新しいアプリケーション属性を反映するようにバッチ実行することで、トラフィックをグリーン環境に切り替えます。
シナリオ 2 では、CI/CT/CD パイプラインを続行する前に手動承認が必要です。このステップにより、SSM では前のアプリケーションが停止/削除され、グリーンの環境がブルーに更新され、その逆の環境が更新されます。
AWS Mainframe Modernization サービス内で Infrastructure as Code (IaC) を使用するメリット
Infrastructure as Code には、開発者やビジネスオーナーに役立つ複数の機能があります。主なメリットは以下のとおりです。
- ネットワーク、コンピューティング、データベース管理などのインフラストラクチャーのプロビジョニングを自動化し、迅速化します。コードを使用して手順を簡素化し、チームの効率とスピードを向上させます。
- 手動によるインフラストラクチャーのプロビジョニングと構成における人為的ミスを軽減します。標準化され、文書化された手順とログが提供されるため、新メンバーのオンボーディングが容易になります。
- 人為的ミスや非互換性を減らし、リソースの浪費やダウンタイムを防ぐことで、導入と構成の一貫性を高めます。
- 繰り返し使用可能で、事前定義された環境仕様を維持することで、同じ構成での再導入が可能になり、構成のずれを自動的に修正できます。
- サービスのプロビジョニングとセキュリティ標準の導入を標準化し、自動化することによってセキュリティを強化し、頻繁なセキュリティレビューや承認の必要性を減らします。
まとめ
本ブログでは、既存のビジネスロジックを維持しながら、レガシーアプリケーションをモダンなアプリケーションにリファクタリングするサービスである AWS Mainframe Modernization を使用する利点について概説しました。左記のサービスを AWS Mainframe Modernization Application Testing および CI/CT/CD パイプラインと組み合わせて、ソフトウェアの開発とデプロイを加速します。CI/CD パイプラインは自動テストと統合されているため、レガシーシステムとモダナイズされたシステムの機能が同等であることが保証され、コア機能の効率的な検証とマネージド環境へのスムーズなデプロイが可能になります。このアプローチは俊敏性を高め、運用効率を高め、より幅広い開発者の人材プールへのアクセスを可能にし、モダナイゼーションプロジェクトの成功に貢献します。詳細については、AWS Mainframe Modernization のページをご覧ください。
著者