この記事では、AIX ワークロードをクラウドに再プラットフォーム化するための移行方法について説明します。 サーバーレス アーキテクチャには Azure Functions を使用することも、Azure Virtual Machines を使用してサーバーフル モデルを保持することもできます。
レガシー アプリケーションを Azure に移行するときに投資収益率 (ROI) を最大化するために、AIX ワークロードの再プラットフォーム移行戦略を検討します。 再プラットフォーム移行には最小限の変更が必要ですが、リファクタリング移行に似たクラウドネイティブの利点があります。
再プラットフォーム移行の利点は次のとおりです。
- 総保有コストの削減 (TCO)。
- ビジネスの機敏性の向上
- 運用の回復性の向上。
アーキテクチャ (再プラットフォーム化)
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
このワークフローは、上記のアーキテクチャに対応しています。
ユーザー要求と受信 API 統合は、WEB アプリケーション ファイアウォール (WAF) 機能を提供する TCP/443 (HTTPS) 上の Azure Application Gateway に転送されます。 Application Gateway は、要求をリバース プロキシ要求として、Red Hat JBoss Enterprise Application Platform (EAP) でホストされているさまざまなサービスに送信します。
Java Web Services は、Oracle データベース (TCP/1521) に問い合わせを行います。 同期 Web 要求の応答時間は 50 ミリ秒 (ms) 未満です。
バッチ タスクのスケジュールなどの非同期要求は、アプリケーション レイヤー内のキューとして機能するデータベース テーブルにレコードを配置します。
Note
将来的には、Azure Queue Storage によってデータベース テーブルが置き換えられるため、常に実行中の分析ジョブにアクセスできます。
KornShell (ksh) スクリプトで記述された cron ジョブは Bash に移植され、Azure Virtual Machine Scale Sets 内の別の Red Hat Enterprise Linux (RHEL) サーバーで実行されます。 cron ジョブは、システムの起動時を含めて 15 分ごとに実行され、Oracle データベース内のキューに対してクエリを実行します。 ジョブはホストごとに 1 つずつ実行されます。 Virtual Machine Scale Sets は、実行時間の長い分析ジョブを並列化します。 このソリューションでは、業務時間中のシステム パフォーマンスへの影響を制限するために、オフピークでのバッチ処理は必要ありません。
Azure Communication Services は、Azure CLI ツール (ドキュメント) を介して E メール アラートを送信します。 Azure のシステム割り当てマネージド ID (
az login --identity、仮想マシン (VM) の認証など)。分析ジョブの結果は、セキュリティで保護された SMBv3 (TCP/445) を介して Azure Files 共有に移動します。これは、システム割り当てマネージド ID も使用します。
コンポーネント
Microsoft Entra ID は、ネットワークベースの信頼を排除し、システム割り当てマネージド ID を提供します。これにより、セキュリティが向上します。
Azure App Service で、オペレーティング システムとサーバーを管理する必要がなくなり、運用効率とビジネスの機敏性が向上します。
Application Gateway は、Web Application Firewall とリバース プロキシ機能を提供する、フル マネージドでスケーラブルなサービスです。
Azure Files には、マネージド サービスを介して発行されるデータ レポートが用意されています。
Azure Functions は、指定されたプログラミング言語でコードを効率的に開発するために使用される、イベント駆動のサーバーレス コンピューティング プラットフォームです。
Azure VM は、Oracle データベースと SAS 分析ノードが使用します。
Azure Compute Gallery は、Oracle データベースと SAS 分析ノードのイメージをビルドして格納します。 プライマリ リージョンと障害復旧リージョンの 2 つのギャラリーがあります。
Communication Services は 、CLI ユーティリティを使用して E メールを送信します。 このサービスは AIX の
mailxコマンドを置き換えます。
代替
別の方法として、すべてのミドルウェア コンポーネントをそのまま保持する完全なサーバーフル アーキテクチャがあります。
このソリューションは、元のアーキテクチャに似ています。このアーキテクチャは、多くの IT 組織が運用する同等の義務を果たします。 この代替ソリューションは、元のアーキテクチャと同程度のコストがかかりますが、再プラットフォーム化されたアーキテクチャが提供するような利点はありません。 次に例を示します。
ライセンスの節約: 代替ソリューションは WebSphere を保持し、さらに RHEL ノードを追加します。
運用効率: 代替ソリューションでは、維持するサーバーと同じ数のサーバーを保持します。
ビジネスの機敏性: 代替ソリューションにより、レポートは、夜間のみに制限され、オートスケールを使用した終日分析はありません。
シナリオの詳細
既存のアプリケーションの移植性と、チームのワークフローの優先順位とテクノロジ ロードマップに応じて、サーバーレスモデルまたはサーバーフル モデルを選択します。
元のアーキテクチャと同様に、再プラットフォーム化されたアーキテクチャには Oracle データベースがありますが、Azure Virtual Machines 上の RHEL オペレーティング システムに再プラットフォーム化されます。 再プラットフォーム化されたアーキテクチャのフル マネージド Azure App Service では、Red Hat JBoss EAP によって WebSphere Java アプリケーションが置き換えられます。
アーキテクチャ (元)
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
このワークフローは、上記のアーキテクチャに対応しています。
ユーザー要求と受信 API 統合は、TCP/443 (HTTPS) 上のオンプレミスの F5 ロード バランサーに転送された後、リバース プロキシをさまざまな IBM WebSphere ホスト型 Java Web サービスに転送します。
Java Web Services は、TCP/1521 経由で Oracle データベースに問い合わせます。 ほとんどの場合、同期 Web 要求の応答時間は 1 秒未満ですが、テストと Web ログ分析に従って 300 ミリ秒を超えます。
バッチ タスクのスケジュールなどの非同期要求は、アプリケーション レイヤー内のキューとして機能する Oracle データベース テーブルにレコードを配置します。
ksh スクリプトで記述された cron ジョブは、Oracle データベース内のキューに対してクエリを実行し、実行する SAS 分析ジョブを取得します。 営業時間中のシステム パフォーマンスへの影響を制限するには、夜間にバッチ処理を行う必要があります。
E メール アラートは、SMTP (TCP/25) 経由でジョブの開始時刻と完了時刻、成功または失敗の結果をユーザーと管理者に通知します。
分析ジョブの結果は、SMBv3 (TCP/445) 経由で収集するために NFS (TCP+UDP/111,2049) 経由の共有ドライブに移動します。
シナリオの詳細
この元のアーキテクチャでは、IBM WebSphere で実行される単一Java アプリケーションを評価し、ksh スクリプトが調整する SAS からのバッチ処理を評価します。 別個の AIX ホスト上で実行される Oracle データベースは、両方のアプリケーション・ワークロードをサポートします。
AIX 上で実行される元のワークロードを検討して、再プラットフォーム移行戦略が移行予算に適しているかどうかを判断します。 目的の結果からさかのぼって、クラウドへの変換的なアプリケーション中心の移行パスを決定します。 ほとんどのアプリケーション コードが、サーバーレス アーキテクチャやコンテナー オーケストレーターなどのクラウドネイティブ サービスがサポートする言語で記述されていることを確認します。
このシナリオでは、Tidal Accelerator が Java アプリケーション コードを分析し、JBoss EAP との互換性を決定しました。 プロジェクトの初期段階では、Azure Pipelines または GitHub Actions を使用して、パイロットとしてアプリケーションを再構築します。 その後、お客様は、Azure App Service などのマネージド サービスの継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインから機敏性を確立できます。 お客様は、オンプレミスの WebSphere 環境でこの機能を利用できません。
この例では、分析フェーズ中に Tidal Accelerator が検出した PL/SQL の量が原因で、Oracle データベースがこのフェーズで保持されます。 お客様の今後の取り組みには、RHEL 上の Oracle データベースからフル マネージド Azure Database for PostgreSQL データベースへの移行、Azure Queue Storage の導入、完全なオンデマンド SAS ジョブの実行が含まれます。 これらの取り組みは、アプリケーション所有者のインタビューで決定されたお客様のテクノロジ ロードマップ、開発サイクル、およびビジネスの方向性に合わせて調整されます。 次のスクリーンショットは、Tidal Accelerator のインタビューを示しています。
考えられるユース ケース
このアーキテクチャは、データ分析、顧客関係管理 (CRM)、ハイブリッド クラウド構成のメインフレーム統合レイヤー、およびインベントリおよびウェアハウス管理シナリオのその他のカスタム ソフトウェア ソリューションをカバーする AIX から Azure への移行に使用できます。
このアーキテクチャは、次のようなテクノロジを使用して、従来のアプリケーション ワークロードに使用できます。
- Oracle Siebel
- Oracle E-Business Suite
- SAS
- IBM BPM
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
このアーキテクチャは、Azure リージョン全体で障害が発生した場合にジン族なフェールオーバーと障害復旧を行うために、Azure Site Recovery を使用して、データベース Azure VM をセカンダリ Azure リージョンにミラーリングします。 同様に、Azure Files では geo 冗長ストレージが使用されます。
データ処理ノードでは、ゾーン冗長 (RA-ZRS) マネージド ディスクを使用して、ゾーンの停止時に回復性を提供します。 リージョン全体の停止中に、冗長 Azure Compute Gallery 内の VM イメージとは異なるリージョンのデータ処理ノードを再プロビジョニングできます。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
このアーキテクチャでは、アプリケーションのデプロイに不変のインフラストラクチャ アプローチを採用し、Azure パイプラインのコードを事前にスキャンして、運用環境の機密データをセキュリティで保護します。 セキュリティ スキャンのためにシフトレフト アプローチが組み込まれており、CI/CD パイプライン対応のデプロイを頻繁に実行して、ソフトウェアの現在の準拠性を向上させ、技術的負債を削減します。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
このソリューションでは、サーバーフル コンポーネントをできるだけ多く削除し、運用コストを 70% 以上削減します。 このアーキテクチャにより、コンピューティングとソフトウェアのライセンス コストが削減されます。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
製品チームは Azure で自身をサポートしているため、報告されるインシデント チケットの解決時間が短縮されます。 さらに、1 つの製品チームが Azure のアプリケーション スタック全体をサポートしているため、チケットのバウンス数、またはグループ間で割り当てられるチケットの数は 0 になります。
パフォーマンス効率
パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
お客様は可能な限り Azure App Service を採用しているため、アプリケーションの需要に合わせてコンピューティング要件を自動的にスケールアップおよびスケールアウトできます。 この順応性により、ピーク時に一貫したアプリケーション パフォーマンスが保証されます。 この方法は、コスト効率も高くなります。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
リチャード・ベリー | シニア プログラム マネージャー
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
Tidal Accelerator ソリューションの使用の詳細については Microsoft Tidal Cloud チームにお問い合わせください。
Azure への移行の詳細については、Legacy Migrations Engineering チームにお問い合わせください。