この記事は、”Taking a comprehensive perspective to mainframe application modernization with a disposition strategy” を翻訳したものです。 はじめに メインフレームのお客様は、モダナイゼーションの選択肢が無数にあります。現在、多くの組織は、人材不足や、高額なコストとその上昇、レガシー環境ではビジネスアジリティに制限が掛かることで、モダナイゼーションが急務となっています。また、お客様自身も、モダナイゼーションの複数のパターン、ツール、戦略を自ずと模索しています。 配置戦略 (disposition strategy) には、メインフレームの複雑なモノリシックアプリケーションや大規模なコードベースへの対処に役立つ指針が含まれます。お客様は、レガシーアプリケーションを管理しやすい部分に分解し、ターゲットとなる移行パターンを開発し、移行の順序付けを行い、メインフレームに残るワークロードとの連携機能を構築します。この作業は、アプリケーションが密結合な状態から完全に切り離されるまで繰り返されます。 配置戦略とは、メインフレームモダナイゼーションに対する複数のパターンを複合的に組み合わせるアプローチです。ビジネス目標と IT 目標の優先順位とワークロードの特性に基づいて、個々のワークロードに適した適切なパターンが選択されます。配置戦略は、メインフレームモダナイゼーションを個々のプロジェクトとばらばらの移行フェーズの集まりと見なすのではなく、全体を包括的に見る視点を持つことを推奨します。これには、メインフレームからクラウドネイティブに至る長い道のりの最初から最後までの全行程を定義したロードマップが含まれます。このアプローチは、移行を加速し、リスクを軽減し、お客様が許容できる期間内にビジネス目標と技術目標を達成できるよう支援するのに役立ちます。 指針として目指す北極星を定義する メインフレーム資産は、地域、業界、顧客によってさまざまであり、まったく同じメインフレームアプリケーションは 2 つとありません。レガシーテクノロジー、ビジネス目標、将来の要件、リスクへの関心は、お客様によって非常に多様です。多くの大企業では、複数の事業部門がメインフレーム上で稼働するアプリケーションによってサポートされています。また、これらの事業部門には、メインフレーム処理に依存する多数のビジネスリーダー、アプリケーションオーナー、およびステークホルダーが組織全体に存在しています。このダイナミクスにより、組織がメインフレームの将来の状態に関する明確な戦略を欠いているというシナリオがしばしば生じます。モダナイゼーションの初期段階では、メインフレームのさまざまなステークホルダーが独自に活動し、それぞれ別個に戦略を導入または計画しているお客様をよく見かけます。その結果、モダナイゼーションへのアプローチがばらばらになります。このようなときのモダナイゼーションには、組織のモダナイゼーションの道しるべとなる北極星のようなビジョンが明確になっていない可能性があります。 メインフレームモダナイゼーションプログラム (※1) を成功させるための第一歩は、北極星 (North Star: 目指すべき指針) を定義することです。この北極星は、経営幹部、そして多くの場合、組織の取締役会にも共有されます。お客様は、メインフレームを使い続けることで増大するリスク、コスト、競争上の不利益を認識しています。レガシーアプリケーションのモダナイゼーションを経営幹部が指示することで、より迅速かつ緊急に職務を遂行し、成果を上げているお客様を我々は目にして来ました。明確なミッションが無いため、一連のばらばらで戦術的なモダナイゼーションプログラムに参加することになったお客様も見て来ました。ばらばらなプログラムでは、メインフレームプラットフォームのワークロードの移行には成功しても、モダナイゼーションのメリットを最大限に引き出すには苦労するかもしれません。場合によっては、メインフレームに課せられた制約が原因で MIPS の使用量が増加することさえあります。このような状況を避けるため、お客様には主に 3 つの質問に答えて北極星を定義することをおすすめします。 なぜ私たちはモダナイゼーションを進めているのか? 私たちはどこに向かっているのか? それはいつ実現するのか? これらの質問に答えることで、メインフレーム移行プログラムを成功させるための基礎を確立し、組織が共有する共通のビジネス目標と技術目標を定義しやすくなります。 (※1) 訳注: ここでのプログラムは、共通の戦略的目標を持つ複数の関連プロジェクトを統合・管理することにより、単独プロジェクトの成功を目指す部分最適では無く、全体最適による価値を創出する手法としてのプログラムマネジメントの文脈で使われています。レガシーコードのプログラムを指すものではありません。 モダナイゼーションのビジネス基準: ビジネス要件と技術的現実のバランス ビジネス目標は、組織内の部門によって大きく異なる場合があります。ビジネスユニットによっては、レガシーアプリケーションの機能を早急に変更しなければならない場合もあれば、確立されたプロセスやユーザーエクスペリエンスの変更に抵抗しているビジネスユニットもあります。大まかに言うと、ビジネスの優先事項は次の 2 つのカテゴリに分類されます。 カテゴリー 1: ビジネス機能は変わらないが、ビジネスの俊敏性にはテクノロジーのモダナイゼーションが不可欠 機能的な変化が望まれていない場合。 このシナリオでは、レガシーアプリケーションがサポートする既存のビジネス機能に、ビジネスユーザーはとても満足しています。現行のビジネス機能やワークフローは変更する必要がなく、ビジネスユーザーは機能変更という考えに反対しています。これは、ユーザーが端末エミュレーターの黒画面を操作しているお客様にも当てはまる可能性があります。端末エミュレーターを長年使い続けているユーザーは、操作に熟練しているので作業効率が非常に高く、最新の UX に置き換えると生産性が低下する可能性があります。 お客様はメインフレームワークロードの大部分が一般にこのカテゴリに入ると想定する必要があります。メインフレームアプリケーションは何十年も組織で使われてきました。これらのアプリケーションは、個別のビジネスロジックが何年にもわたって使われてきたビジネスに適しているかもしれません。大企業と各業界で差別化されたビジネスのやり方に合わせてカスタマイズされている可能性があります。すべてのアプリケーションに機能的なトランスフォーメーションが必要なわけではありません。安定性と予測可能性が最優先されるシステムの場合は、以下の選択肢を考慮することが重要です。 リファクタリング (Refactor) : レガシーアプリケーションを最新のプログラミング言語とリレーショナルデータベースに変換します。たとえば、 AWS Transform for mainframe を使うと、お客様は AWS の専門的な AI エージェントを使用して COBOL アプリケーションを AWS 上の Java にリファクタリングできます。 リプラットフォーム (Replatform) : 既存の機能を維持し、レガシーテクノロジースタックを維持しながら、よりモダンなインフラストラクチャに移行します。たとえば、AWS Mainframe Modernization には、クラウド内のメインフレーム互換ランタイムにリプラットフォームするためのオプションが用意されています。 これらのアプリケーションのモダナイゼーションでは、機能以外のモダナイゼーションのメリット (耐障害性、影響範囲の縮小、可用性、俊敏性) にフォーカスしてコミュニケーションします。 カテゴリー 2: 技術的な負債を取り除いたり、新しい機能を追加したり、モノリスを分解してプロダクトを調整したりするには、ビジネス機能の変更が必要 機能強化の要件がある場合。 ビジネス部門がアプリケーションの機能を強化する必要があるのはこの場合です。一般に、お客様はメインフレームワークロードの一部だけがこのカテゴリに該当すると予想しています。このような状況では、企業はモダンな UI、リアルタイム機能、またはより高速なバッチ処理を望んでいる可能性があります。また、お客様は、モノリス化した現行アプリケーションをプロダクトに合わせたビジネス機能に分割したいという目標を持っているかもしれません。このアプローチにより、マイクロサービスアーキテクチャを構築し、疎結合化することによってアジリティとイノベーションを促進されます。 ニアリアルタイムの機能に対するエンドカスタマーの期待の高まりに直面するお客様が増えています。メインフレーム上のモノリス化したアプリケーションにこのような機能を導入するのは困難です。さらに、新しい市場や業界への進出、あるいは顧客基盤の拡大を目指すお客様にも会うことがあります。成長目標を積極的に掲げているお客様は、メインフレームアプリケーションを維持することが、成長や新規ビジネスの獲得を阻害していると気付くことがよくあります。 成長の可能性 : モダナイズすることで、新しい収益源を開拓したり、事業拡大を支援したりできるアプリケーションはどれか? カスタマーエクスペリエンスへの影響 : 顧客とのやり取りや顧客満足度に直接影響するアプリケーションはどれか? 市場への対応力 : 現在、市場の変化への対応能力を制限しているのはどのシステムか? イノベーションの可能性 : 最新の開発手法や最先端技術との連携から最も恩恵を受けるのはどのアプリケーションか? 一般的に、強化すべき機能要件が明確に示されているビジネスユニットは、より優先されるはずです。新機能、ユーザーエクスペリエンスの向上、連携機能など、個々のニーズが具体的な目標を提示し、それによってモダナイゼーションの取り組みが推進され、目に見える価値が示されます。 Reimagine パターン とは、メインフレームアプリケーションのアーキテクチャを最新のテクノロジースタックに合わせて設計し直し、コードを書き直すことと定義されています。このモダナイゼーションの目標は、アプリケーションに機能的な変更を導入することです。ビジネスが新しい機能を必要とする場合、reimagine パターンが望ましいアプローチです。 モダナイゼーションのための技術的基準 メインフレームモダナイゼーションの配置戦略には、組織レベルとアプリケーションレベルの両方で評価された技術的基準も組み込む必要があります。 組織レベルでの技術的考慮事項の評価: データセンターから出て行くための戦略や緊急性が高い移行期限 データセンターの撤退を迫られている組織は、移行の期限が迫っているため、スピードとリスクの軽減を優先する必要があります。コードを変更せずにメインフレームのワークロードをパートナーが管理するデータセンターに移動することを意味するリホスト (rehost) パターンは、実践的な第一歩となる可能性があります。多くの場合、リホストアプローチは、他の移行パターンのように長いサイクルを通ることなく、数ヶ月で完了できます。リホストは事業継続につながります。また、将来のモダナイゼーションの基礎を築き、組織がより高度なパターンを徐々に適用するのにも役立ちます。これらのパターンは、時間とリソースの制約の中で、リファクタリングや reimagine などのモダナイゼーションのニーズに対応できます。 ニッチなメインフレーム技術: プログラミング言語、トランザクションモニター、データベース 既存のメインフレームアプリケーションで使用されている特定のプログラミング言語、トランザクションモニター、データベーステクノロジーは、モダナイゼーションの取り組みの実現可能性と複雑さに大きな影響を与えることがあります。これは、メインフレームモダナイゼーションの配置戦略を検討する際に、重要な技術的考慮事項です。 Natural/Adabas、IDMS などの特定のメインフレームテクノロジーは、リプラットフォームやリファクタリングなどの一部のモダナイゼーションパターンでは直接サポートされていなかったり、完全にはサポートされていない場合があります。これらのレガシーメインフレームテクノロジーの可用性と保守性のスキルも、考慮点の 1 つです。これにより、利用できるモダナイゼーションの選択肢が制限される可能性があり、実行可能な選択肢はリプレース (replace) (※2) や reimagine などのパターンだけかもしれません。 組織は、使用されているメインフレームのテクノロジースタックと、それがさまざまなモダナイゼーションアプローチの実現可能性や複雑さにどの程度合致するかを注意深く評価する必要があります。この技術的評価は、適切な配置戦略を決定するうえで重要なインプットとなります。 (※2) 訳注: 本ブログ内のリプレース (replace) は、パッケージソフトウェア製品の購入や SaaS のサブスクリプション契約等を指すリパーチェス (repurchase) と同義で使われています ベンダーによる更新のタイムライン メインフレームモダナイゼーションの配置戦略を評価する際、ベンダーの更新スケジュールは重要な技術的検討事項になり得ます。組織には、ソフトウェアライセンス契約が異なるさまざまなメインフレームベンダーが存在することがよくあります。契約条件の評価にあたっては、更新時期が迫ることでリスクが高まります。この場合、中には、それらのベンダーのテクノロジーからできるだけ早く撤退することが最も価値ある結果になると判断するお客様もいます。このタイムラインの速さは、選択するモダナイゼーションアプローチにも影響します。 たとえば、ライセンス契約の終了期限が迫っている場合は、リプレースアプローチや reimagine アプローチよりも、リファクタリングパターンの方が適している場合があります。リファクタリングは、コア機能を維持しながらアプリケーションをモダナイズするのに役立ちます。多くの場合、全面的な書き直し (full rewrite) や再実装 (reimplementation) よりも短時間で完了できます。 ただし、すべてのリファクタリングソリューションがすべてのメインフレームテクノロジーをサポートしているわけではない点に注意することが重要です。使用中の特定のテクノロジーに適したリファクタリングソリューションの評価を完了する必要があります。場合によっては、明白なリファクタリングソリューションや実証済のリファクタリングソリューションがないこともあります。必要な期限までにベンダーのテクノロジーから撤退するには、reimagine またはリプレースのアプローチしか実行できない場合があります。 最良のモダナイゼーション戦略を決定する際には、全体的な技術評価の一環として、メインフレームベンダーの契約と更新スケジュールを評価することが重要です。これにより、選択したアプローチを、特定のベンダーのテクノロジーから撤退する緊急性に合わせることができます。 動員可能なメインフレームスキルセット メインフレームのスキルセットに制約があるために企業が人材リスクに直面している場合、そのスキルへの依存度が低いメインフレームモダナイゼーションの選択肢を選ぶことが重要です。このような場合、メインフレームアプリケーションのリファクタリングや reimagine などの戦略が効果的なアプローチになり得ます。 逆に、組織内に有能なメインフレーム人材プールがある場合は、リプラットフォームアプローチがモダナイゼーションに適した戦略となり得ます。既存の専門知識を活用して、ワークロードをよりモダンなプラットフォームに移行することができます。 アプリケーション/ワークロードの技術的な複雑さと依存関係の評価 適切なパターンの選択は、ビジネス上の考慮事項と技術的要件の両方に基づいて行う必要があります。各ワークロードまたはアプリケーションの特定の特性を考慮する必要があります。 さまざまなアプリケーションやワークロードを徹底的に技術評価して、それぞれに最適なモダナイゼーションアプローチを決定することが重要です。この評価フェーズでは、以下の要素を考慮します。 移行元のテクノロジー : プログラミング言語と既存のソースコードの量を評価します。一部の言語とフレームワークは、他の言語とフレームワークよりも自動化されたトランスフォーメーションとモダナイゼーションに適しています。これは、特定のモダナイゼーションパターンの実現可能性と複雑さに影響する可能性があります。 データに関する考慮事項 : メインフレームで使われているデータストア技術 (Db2、IMS/DB、VSAM など) を評価します。データ量、データ構造の複雑さ、データエンティティ間の関係を評価します。データの性質と複雑さが、適切なモダナイゼーションアプローチに影響する可能性があります。 結合度 : さまざまなアプリケーションとワークロード間の結合レベルを特定します。たとえば、トランザクションコンテキストの伝播を含むアプリケーションは、密結合されている可能性があります。この場合、疎結合の場合やサービス境界が明確な場合よりも、モダナイゼーションの課題が大きくなります。モダナイゼーションの過程において、密結合された機能の相互依存関係に順次対処し、具体的に管理する必要があるためです。 連携の複雑さと依存関係 : アプリケーションとワークロードの間のさまざまな連携ポイントを評価します。共有リソース、データ依存関係、全体的な連携の複雑さを特定します。これにより、既存の連携を維持できる適切なモダナイゼーションパターンを判断したり、リスクを抑えて移行を行ったりするのに役立ちます。 外部インターフェース : 選択したモダナイゼーションパターンによっては、外部インターフェースを介してメインフレームにアクセスするメインフレームの外部のクライアントアプリケーションの一部が変更されることがあります。選択したパターンが、すべての外部接続ポイント、API 操作、および外部システムとのデータ交換メカニズムに必要なインターフェースをサポートしていることを確認します。 この詳細な技術評価では、次のような要素を考慮する必要があります。 読み取り/書き込みモードで同じデータにアクセスするアプリケーションをグループ化し、それらのグループに同じ移行パターンを選択する 結合度が高いワークロードには同じ移行パターンを選択する 移行元のプログラミング言語がさまざまな移行パターンの実現可能性に与える影響を考慮する 外部インターフェースや連携への変更を可能な限り最小限に抑える移行パターンを選択する アプリケーションとワークロードの分析は、全体的な配置戦略の重要なインプットです。ワークロード固有の技術的特徴と依存関係に基づいて、ワークロードに適したモダナイゼーションパターンとソリューションを追加できます。 移行戦略の策定 ビジネス成果駆動型プログラムの構築 モダナイゼーションを純粋に技術的な課題として扱うのではなく、次のようなプログラムを確立します。 組織の北極星から逆算して考える : 冒頭で述べたように、お客様はメインフレーム資産に関する組織的な戦略とアプローチを必要としています。成功するメインフレーム移行プロジェクトは、経営陣が設定した変動要素(予算や期間、体制等)の枠組みの中で実施されます。なぜモダナイゼーションを行っているのか、どこに向かっているのか、いつモダナイゼーションを実現するのか、といった点を見失わないようにします。 戦略的ビジネス目標との連動 : モダナイゼーションは、俊敏性の向上、カスタマーエクスペリエンスの向上、新しい機能など、特定のビジネス成果をサポートするものでなければなりません。 ポートフォリオ全体を最初から検討する : モダナイゼーションが段階的なアプローチとして定義されている場合でも、新しいテクノロジーのサイロ化を避けるため、計画はアプリケーション全体を対象とする必要があります。 戦術的な成果と戦略的目標のバランスを取る : 包括的なモダナイゼーションに向けて取り組みながら、段階的な価値をもたらすプログラムを設計します。 成功の明確な指標を確立する : ビジネス面と技術面の両方で、進捗状況をどのように測定するか定義します。 経営幹部レベルで戦略が設定されていないと、個々のチームが異なるアプローチを採用したり、「様子を見る」という考えに陥ったりする可能性があります。これにより、モダナイゼーションが遅れ、複雑さが増す可能性があります。 「すべてを再構築」という落とし穴の回避 私たちの経験から、80:20 の原則はメインフレーム資産にも一般的に当てはまることがわかっています。メインフレームアプリケーションの約 80% は機能変更を必要とせず、約 20% のアプリケーションでは reimagine が必要です。 お客様には、大幅な脱メインフレームを含むモダナイゼーションのアプローチを検討することをお勧めします。Transamerica や Goldman Sachs などのお客様は、リファクタリングやリプラットフォームパターンを利用して、ミッションクリティカルなメインフレームワークロードを AWS に移行することに成功しています。アプリケーションごとに個別のアプローチを取るだけだと時間がかかり過ぎて、ビジネス上の必要性を満たせない場合があります。ビジネス目標と技術目標に基づいて、複数のモダナイゼーションパターンを組み込むことを検討します。 大規模なリファクタリング : AWS Transform for mainframe には、レガシーアプリケーションをモダンな Java フレームワークにモダナイズするのに役立つリファクタリング機能が備わっています。このパターンは、決定論的ツールによってもたらされる移行スケジュールの短縮の恩恵を受けながら、レガシーテクノロジーへの依存を減らしたい場合に使用できます。 リプラットフォーム : リプラットフォームでは、エミュレーションテクノロジーを使用して、メインフレームアプリケーションをそのまま移行します。これはしばしば「COBOL から COBOL への移行」と呼ばれます。この場合、リプラットフォームパターンにより、COBOL の人材不足の状況に対処し、脱メインフレームを加速させることができます。 大規模なモダナイゼーションアプローチと戦略的な reimagine を組み合わせることで、お客様はプラットフォームからの撤退に向けて前進しながら、技術的成果とビジネス上の成果を一致させる機会を得ることができます。複数のパターンを社内の戦略で検討しているお客様は、組織内のより多様な目標に取り組むことができます。これは、同じ期間内に運用コスト削減目標を達成しながら行われます。 まとめ: 今こそ行動の時です 今日、メインフレームアプリケーションのモダナイゼーションが強く求められています。人材不足、ソフトウェアコストの上昇、組織の非効率性といったよく挙げられる課題のほかに、新たな要因が浮かび上がってきました。それは、生成 AI がソフトウェア開発に与える影響の増大です。生成 AI コーディングアシスタントがモダンな言語の生産性に革命をもたらすにつれ、モダンテクノロジーとメインフレームテクノロジーの間の開発スピードと生産性のギャップはさらに悪化するでしょう。COBOL や Assembler、PL/I 言語のアプリケーションを使用する組織は、価値創出のスピードという点で競争上の不利な点に直面するケースが増えています。同業他社が運用する基幹システムは、開発スピードがますます速くなるモダンなテクノロジーで書かれた基幹システムを運用しているかも知れません。 メインフレームモダナイゼーションに「特効薬」はありません。成功するには、具体的な成果に基づいて IT 目標とビジネス目標を一致させる、ビジネス駆動型のマルチパターンアプローチが必要です。自動化を行い、段階的に反復することで、コスト削減以外の価値に集中できます。 配置戦略は、各アプリケーションポートフォリオの微妙な違いを認識した、このジャーニーの枠組みとなります。このアプローチでメインフレームアプリケーションをモダナイズすることで、組織は数十年にわたって構築された貴重なビジネスロジックを維持しながら、将来のイノベーション需要に備えることができます。 Tim Gray Tim は AWS の Worldwide Go-to-market Specialist で、AWS Transform for mainframe のリードを担当しています。 Tim は、お客様が AWS Transform を活用して基幹システムを reimagine し、モダナイズすることによる AWS への移行を支援するべく、市場開拓戦略に注力しています。現在、Tim は、大規模なモダナイゼーションプログラムをこれまでにない時間枠で加速させる生成 AI およびエージェンティック AI サービスをデプロイするための再現可能なパターンの構築に注力しています。 Sunil Divvela Sunil Divvela は、AWS の Mainframe Modernization 担当 Worldwide Specialist Solutions Architect です。お客様やパートナーと緊密に連携して、生成 AI やエージェンティック AI を活用したポートフォリオ評価から移行後のサポートに至るまで、メインフレームモダナイゼーションの取り組みを革新し加速させています。AWS 入社前、Sunil は Infosys の Senior Technology Architect として、複数のメインフレームトランスフォーメーションプロジェクトをリードしていました。 Yann Kindelberger Yann Kindelberger は、Amazon Web Services の Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

レガシーメインフレームアプリケーションは、企業全体の重要な事業運営のバックボーンの一部ですが、これらのシステムにはモダナイゼーションに関する重大な課題があります。メインフレームは何十年にもわたって信頼性が証明されてきましたが、多額の技術的負債を蓄積し、専門知識の需要はますます少なくなり、迅速なイノベーションと機能の導入を妨げています。AWS Mainframe Modernization with Rocket Software は、お客様が切望していたこれらのレガシーアプリケーションの知的財産を元のソースコードのまま維持するための戦略的ソリューションを組織に提供します。このソリューションにより、企業は貴重な既存のビジネスロジックを維持し、運用の継続性を維持しながら、運用コストを削減し、開発サイクルを加速し、最新の開発ツールと方法論を活用できます。AWS でモダナイズすることで、企業はレガシーインフラストラクチャを、将来の成長とイノベーションをサポートするアジャイルなクラウドネイティブシステムに変えることができます。このガイドでは、ビジネス目標、リスク評価、ROI タイムラインに基づいて、AWS で Rocket Software を使ったリプラットフォームの実装に焦点を当てています。ワークロードの計画、移行、検証を最初から最後まで成功させるための 7 つの具体的なベストプラクティスを紹介します。このブログ記事では、標準化された環境、Field-Developed Solutions (FDS) の特定、コード互換性の修正、データ移行戦略、AWS での包括的なテスト手順などのベストプラクティスを紹介します。 ベストプラクティス 1: 移行先アーキテクチャの定義 システム分析および設計文書（System Analysis and Design Document: SA&DD）は、スコープ漏れの管理、テスト作業の軽減、市場投入までの時間の短縮に役立つ重要なプロジェクト成果物です。SA&DD は、以下をマッピングして包括的なターゲットソリューションを定義します。 ハードウェアの仕様と要件 システムサービスと構成 プログラミング言語と開発ツール サードパーティーのアプリケーションおよび連携 (以下はその一例です) データベース管理システム (セルフマネージドシステムと Amazon RDS の両方: Db2 LUW、PostgreSQL) ジョブスケジューリングツール レポート生成ソフトウェア ファイル転送ユーティリティ (SFTP、FTP) メールシステム (SMTP) 開発サーバーとエンタープライズサーバー構成 データ移行戦略と計画 コンプライアンスおよび規制要件 セキュリティ管理と監視アプローチ ソースコードのインベントリと可用性の評価 外部システムとの連携ポイント パフォーマンス要件とサービスレベル契約 (SLA) SA&DD は移行プロジェクトの設計図の役割を果たすため、すべてのステークホルダーが移行先アーキテクチャと技術要件を明確に理解できます。プロジェクトライフサイクルの早い段階で潜在的なリスクと技術的ギャップを特定し、積極的な緩和戦略を立てるのに役立ちます。SA&DD の作成の一環として、完全な静的分析を行い、すべてのコンポーネントのインベントリを作成します。コンパイラおよびコンパイラ指令(ディレクティブ)の互換性を検証して文書化し、リスクがあれば文書化します。専任チームを割り当て、発見事項に対処し、コードベース全体に体系的に修正を適用します。これらのステップにより、コーディング標準への準拠が保証され、メンテナンスの必要性が軽減され、下流でのデプロイメントの問題が防止されます。 ベストプラクティス 2: 標準化された Development 環境と Enterprise Server 環境の構築 標準化された開発環境の目標は、すべての開発者に一貫したテンプレートを提供することです。標準化された環境では、ディレクトリ構造とコンパイラ指令を含むプロジェクトプロパティの両方が定義されるため、すべての開発者が同じ条件で作業し、コードが一貫してコンパイルされます。 Rocket Enterprise Developer (ED) と Rocket Enterprise Server (ES) の標準セットアップ AWS 上の Rocket Enterprise Developer (ED) と Enterprise Server (ES) 向けに、バージョン管理されたゴールデンセットアップを作成します。Amazon EC2 イメージで特定のバージョンを指定し、標準構成として環境を構築します。 ソースコントロールのコンパイラ指令 (例: DIALECT/ARITH/TRUNC、コードページ) や、リンクオプション、およびビルドステップはそのまま使用します。これにより、CI が構成のずれを検出しても、一貫したツールチェーン設定が可能になります。 マスター Enterprise Server (ES) リージョンの作成 Rocket Directory Server と Enterprise Server Common Web Administration 用の Infrastructure as Code を使用してマスター ES リージョンを作成し、すべての CICS/IMS/JES リソース、データセット、セキュリティ、ミドルウェアを定義します。環境固有の設定には AWS Systems Manager と AWS Secrets Manager を使用して、このテンプレートを QA (Quality Assurance) / UAT (User Acceptance Test) 環境に複製します。トラフィック管理用に Network Load Balancer を実装します。一貫性のある環境を確保し、更新を簡素化できるようにするため、メンテナンスに Amazon CloudWatch を AWS Systems Manager を使います。 ベストプラクティス 3: 要件を識別して Field Developed Solutions (FDS) を活用する FDS (Field Developed Solutions) は、Rocket Software Enterprise Server とサードパーティ製品間の技術ギャップを解消することで、他社製品とをつなぐ架け橋となるソリューションです。分析中、チームはこれらのプラットフォーム間の適切な統合を可能にするためにどの特定の FDS が必要かを特定します。特定すると、該当の FDS を購入し、インストールし、ターゲット環境で一通りテストし、正しく機能することを確認します。カスタムプリンタソリューションなど、標準の FDS が存在しない特別な状況では、Rocket Software のアーキテクトがデリバリーチームと直接協力して、独自の要件を満たす新しいカスタム FDS を開発するためのオプションを検討し、評価することがあります。 ディスカバリーフェーズで FDS を特定するメカニズム 棚卸しとディスカバリー (Enterprise Analyzer (EA) の標準レポートを使用) プログラムの量、使用されているテクノロジー、複雑さなど、全体的なポートフォリオを把握するには、Application Inventory や Application Summary などの Executive Reports から始めてください。特殊なテクノロジーや例外値の指標は、自社開発のコンポーネントを示している可能性があります。 Inventory Reports を確認すると、COBOL、PL/I、ジョブ制御言語 (JCL) などの言語間で検証済みのファイル数とコード行数 (LOC) を比較できます。JCL が参照している内容と EA が検証できる内容との間に相違がある場合、カスタムユーティリティやコピーブックがベースラインから除外されているケースがよく見られます。 Verification and Reference Reports、特に Missing Files と Unresolved References を使って、解決されないコピーブック、呼ばれているプログラムや JCL プロシージャ (PROC) を一覧表示します。頻繁に参照される未解決の項目は最優先項目として扱います。 JCL Support がプロシージャ、コントロールカード、ユーティリティエイリアスを解析できるようにします。レポートをスキャンして、非標準のユーティリティ名、カスタムプロシージャの命名パターン、データセット識別子に着目し、社内で開発された固有のジョブやライブラリを示す兆候が無いか調べます。 EA で Portability Assessment を実行して、プログラミング言語の方言特有の特徴や標準外の構成要素など、所見や注目ポイントを指摘します。これらの調査結果は、特別な処理を必要とするカスタムルーチンと相関している可能性があり、FDS の強力な指標となります。 Enterprise Analyzer の Code Search を使用したパターンベースの検索 Enterprise Analyzer の Code Search を使用すると、検証済みのソースファイルをすべてスキャンして FDS が必要なパターンがないかどうかを確認できます。あらかじめ定義されたカテゴリから始めて、カスタムクエリを追加します。 Analyzer ワークスペースから Code Search を実行するか、ポートフォリオ全体で繰り返し検出できるように複数のクエリをまとめた Custom Code Search Report を作成します。詳細については、 “Analyzing Programs – Staging Program Analysis with Code Search” を参照してください。たとえば、どの SORT パラメータが使用されているかを調べてください。これは、たとえば SORT パラメータに IFTHEN や JOINKEYS が含まれている場合に役立ちます。 ステークホルダーのインプット 社内ツールについて、開発者と運用チームにヒアリングします。 可能な場合は、社内ツールを補完する Rocket Enterprise Developer の同梱ツールや新機能を活用します。 社内で開発されたカスタムユーティリティについては、変更管理履歴を確認して参照します。 一般的な FDS の例: SORT : Rocket Software の外部 SORT を拡張して、追加の DFSORT オプションと Syncsort オプションをサポートできるようにします。 Simple Mail Transfer Protocol (SMTP) : JCL と SMTP を連携してメール送信機能を提供します。 Secure FTP (SFTP) : JCL にほとんどまたはまったく変更を加えずに、メインフレーム JCL FTP ステップを SFTP にマッピングするために必要なサポートを提供します。 Rocket Software には、SAS などのサードパーティ言語を統合した FDS がいくつか用意されています。Rocket Software の すべての FDS の一覧 をご覧ください。 ベストプラクティス 4: 移行を成功させるためのソースコードの準備 コードデプロイメントは、メインフレームからアプリケーションのソースコードを取り出し、ターゲットの Rocket Software ランタイム環境でビルド、デプロイ、テストするプロセスです。これには、COBOL コードの再コンパイルと、Enterprise Server でサポートされていない言語 (アセンブラなど) のコード変換が含まれます。再コンパイルする前にソースコードの完全性をチェックし、アプリケーションモジュール、コピーブック、JCL/PROC、マクロ、ユーティリティを含むすべてのソースコードが使用可能であることを確認します。 ソースに埋め込まれた 16 進数 チームは 16 進リテラルを使用してバイナリフラグとビットマスク (COMP、COMP-5、BINARY) の設定、パック 10 進数 / COMP-3 フィールドの初期化、レコード分離用の非表示制御文字の挿入、コードページ固有の表示値の表現を行います。移行の課題は、メインフレーム (EBCDIC) とターゲット環境 (ASCII) のコードページの違いから生じます。たとえば、数字の 0 は EBCDIC では X’F0’、ASCII では X’30’ なので、COBOL ステートメント MOVE X’F0F1′ TO ALPHA-FIELD はメインフレームに 01 と表示されますが、正しい ASCII 表示には読み替えが必要です。同様に、EBCDIC レコードセパレータ X’15’ は ASCII ラインフィード X’0A’ とは異なります。すべての環境のエンコーディング標準を SA&DD に文書化します。 ターゲットとなるエンコーディング戦略を決定して文書化します。EBCDIC をそのまま使用する場合は、データセットとリテラルを EBCDIC に保存し、ファイルハンドラーまたは CCSID を明示的に設定します。ASCII または Unicode を採用する場合は、明確に定義された I/O 境界でのみ変換し、表示テキストを表す 16 進数をポータブルリテラル (たとえば 01) または共有コピーブックのエンコーディング対応定数に書き換えます。 16 進数は真のバイナリデータおよびパック形式データ (フラグ、ビットマスク、COMP-3) に限定し、コードコメントや設計成果物にその意図を文書化します。Kiro CLI を使用して、バイナリの可能性があるフィールドを特定し、そのフィールドに関するユニットテストを生成または更新し、Rocket Enterprise Server ランタイムの数値動作がメインフレームのベースラインと一致することを検証します。 16 進数の検出と分類を自動化します。Kiro CLI によるリポジトリ全体にわたる検索を使用して X’.. ‘ などのパターンを特定し、エージェントに使用パターン (表示、パック形式、制御文字) ごとに出現箇所をグループ分けさせ、直接読み替え (テキスト用) または現行のまま維持 (バイナリ用) のいずれかを提案させます。正しい結果が得られるとわかっている小さな入力ファイルを使用して翻訳経路を end-to-end で検証します。表示フィールドが一度だけ翻訳されるのに対し、バイナリフィールドはプラットフォーム間でバイトが同一であることを確認します。 翻訳経路を反復可能なワークフローとしてテストします。データセットとコードページの設定、コピーユーティリティ、ミドルウェアを検証して、二重翻訳や翻訳スキップがないことを確認します。Kiro CLI エージェントは、コマンドラインから既存のユーティリティと比較ツールを呼び出し、ログや差分をキャプチャして、リグレッションやカットオーバーのリハーサル中に再実行できる反復可能なレシピにパッケージ化することで、これらのチェックを調整できます。 緩いコーディング基準で実装されたソースコード レガシーアプリケーションが寛容なメインフレームコンパイラの動作 (またはショップ固有の拡張機能) に依存していて、より厳しい Rocket コンパイラでは拒否されることがよくあります。コンパイル時によくある問題には、スコープターミネーターの欠落、固定形式の間違い、一貫性のない符号処理、非標準動詞、MOVE CORRESPONDING、未解決の COPY REPLACING、TRUNC/ARITH の違いなどがあります。 これらの問題を軽減するには、メインフレームの動作をエミュレートするようコンパイラーディレクティブの組み合わせをプロファイルとして確立し、コンパイル時に適用します。スコープ、フォーマット、PIC のチェック用の整形ルールと継続的インテグレーション (CI) ルールを追加します。非標準構成を移植可能な同等の構成に置き換えます。数値フィールドとパックフィールドのユニットテストを実装して、回帰事象を早期に検出します。 COBOL 標準の進化 COBOL 言語標準は時間の経過とともに進化し、新しい構文や予約語が次々と追加されてきました。たとえば、ANSI COBOL 85 が組み込み関数を導入したことで、「FUNCTION」は予約語になりました。場合によっては、コンパイルディレクティブを調整することでこれらの違いを緩和できることがあります。Rocket Software の「REMOVE」ディレクティブでは、予約語をデータ項目として使用できます。たとえば、「REMOVE (FUNCTION)」を使用すると、期待どおりの機能を維持しながらコンパイルできます。 コマンドライン (Kiro CLI) で Kiro を使用して作業を加速 Kiro CLI を活用して、自動化されたコード取得、変換、デプロイのワークフローをコマンドラインから直接調整することで、メインフレームのモダナイゼーションを加速します。Kiro CLI は、再コンパイル作業を効率化し、非互換性 (サポートされていないアセンブラ呼び出しなど) を早期に明らかにし、Rocket Softwareのランタイムを一貫してターゲットにすることで、移行の各スプリントをすぐにデプロイ可能なソースコードから開始できるようにします。追加情報については、Kiro CLI (旧 Amazon Q CLI) によるコンパイルの高速化に関する記事 Revolutionizing Mainframe Replatforming with Amazon Q CLI を参照してください。 ベストプラクティス 5: 広範囲にわたるテストが成功のカギ 包括的な統合テストとシステムテストを実行しながら、正確なトポロジ、セキュリティ構成、データエンコーディング、ミドルウェアコンポーネントの機能を再現することで、本番環境を反映した AWS 環境を開発します。 メインフレームのベースラインの確立 定常状態とピーク状態の両方を網羅した、現在のシステムの動作とパフォーマンス指標の包括的なベースライン測定値を確立します。すべてのコンポーネントのスループット、レイテンシー、ストレージの物理 I/O の正確な測定値を文書化します。このベースラインには、メインフレームシステムの詳細な指標を含める必要があります。具体的には、システム管理機能 (SMF) レコード、バッチ処理件数の合計値、クリティカルパスジョブのタイミング、I/O ボリューム、インターフェイスレイテンシーの収集などです。この情報は、AWS への移行が成功したかどうか検証するための決定的な基準となります。ベースラインテストでは、運用範囲全体をカバーする end-to-end の検証を実施します。すべてのジョブ制御言語（JCL）プロシージャを含むバッチスケジュール全体を実行し、すべてのオンライン画面とサービスをテストし、インバウンドとアウトバウンドの両方のインターフェイスを検証し、サードパーティコンポーネント連携（印刷サービス、電子メールシステム、メッセージキュー、スケジューラーを含む）を検証し、Enterprise Server (ES) のセキュリティコントロールを確認し、包括的なデータ移行を実行してタイミングベースラインを確立します。ピーク負荷状態やエッジケースを含め、すべての結果を統計的に有意な形で文書化して、AWS の実装と比較できるように完全なパフォーマンスプロファイルを確認します。自動テストフレームワークを使用して測定の一貫性と再現性を確保し、パフォーマンスメトリクスに影響を与える可能性のあるすべてのテスト条件と環境要因の詳細な記録を維持します。 統合テスト 共用の統合テスト用 Enterprise Server (ES) リージョンまたはローカルの開発用 ES 環境でテストを実行します。エンコーディング選択 (EBCDIC / ASCII)、データセットカタログ、接続設定など、本番環境の設定を正確に複製します。欠陥に対処する際は、可能な限り、標準化された COBOL コンパイラ指令プロファイルを通じて修正を実施してください。これにより、それ以降のビルドでは、数値セマンティクスや符合ルールなどの重要な要素にわたって一貫した動作が維持されます。標準化すべきその他の重要な要素には、想定される CCSID、ファイル編成、レコード区切り文字の処理などがあります。この標準化されたアプローチは、環境特有の問題を防ぎ、すべての環境で再現可能な動作を保証します。 一般的な課題の例 データ形式: メインフレームが別のメインフレームとの間でデータを送受信する場合、可変長ブロック化 (VB) ファイルを直接送信できます。メインフレームが VB ファイルを分散プラットフォームに送信しても、Rocket Software が処理できる VB 形式では届きません。これには、Rocket Field-Developed Solution (FDS) のレコード形式変換ソリューション、もしくは、ETL (Extract, Transform, Load) ツールのカスタム開発が必要です。 文字セットの変更: 分散プラットフォームがメインフレームにデータを送信すると、メインフレーム上の FTP サーバーによって文字セットが ASCII から EBCDIC に自動的に変換されます。同じファイルが ES 環境に送信されても、この文字セット変換機能はありません。Rocket FTP FDS は、組み込みの文字セット変換機能を使用してアウトバウンドデータ転送を処理します。ただし、外部プラットフォームからのインバウンド転送には、文字セット変換のための追加の処理ステップが必要です。 機能的同等性テスト システムテストでは、統合テストの完了後に機能的同等性を大規模に検証する必要があります。本番レベルのデータ量を使用して、AWS でそのままバッチポートフォリオを実行します。機能的に同等になり、SLA を満たすまで、すべてのアウトプットをベースラインのメトリックスと比較します。カレンダー、依存関係、タイムゾーンルールを明記した詳細な計画文書を作成しましょう。リスタートの手順、リランする際の作業順序、および文書化された移行手順を含めます。移行前後の違いに合わせた最適化を開始する前に現状のままテストを実行することで、環境の違い、エンコーディングの問題、I/O のばらつきを特定するのに役立ちます。スケジューラーの移行には早期に対処し、初期テストではレガシースケジューラーと連携するブリッジ機能またはプラグインを使用して AWS ワークロードを連携動作します。安全な接続経路や、カレンダー機能、リスタート機能がレガシープラットフォームにない場合は、早期の移行を検討します。シャドウ実行または並列実行により、スケジューラーの同等性を検証します。カットオーバー前にモニタリング、アラート、リカバリの手順を練習します。運用が安定したら、機能的な変更を実施せずプラットフォーム移行から切り離したままで、ジョブフローを合理化して重複を排除します。 パフォーマンステスト パフォーマンステストでは、移行したアプリケーションが移行元システムのベースラインメトリクスを満たしているか、上回っているかを検証する必要があります。テストは、スループット率、レスポンス遅延、リソース使用量という 3 つの主要分野に焦点を当てます。すべてのテストは、実稼働規模のデータ量とワークロードパターンを使用して実行し、正確なパフォーマンス比較を行います。 ベースライン指標 メインフレームの SMF/RMF レコードとジョブアカウンティング指標を使用してパフォーマンスベースラインを確立する クリティカルパスのタイミングと I/O 量を参考ベンチマークとして文書化する ピーク時のワークロードパフォーマンス特性とトランザクション応答時間を把握する ストレージパフォーマンス ワークロードパターンに基づいて Amazon EFS スループットモード (Elastic / Provisioned) を設定する Amazon EBS io2/io1 ボリュームを I/O 負荷の高いバッチ処理に活用する EFS メトリクスの監視: TotalIOBytes, PermittedThroughput, BurstCreditBalance EBS メトリクスのトラッキング: IOPS, Throughput, Queue Length, Volume Status 詳細については、「 AWS Mainframe Modernization のファイルシステム選択 」を参照してください。 コンピュートパフォーマンス EC2 メトリックス (CPU 使用率、ネットワーク I/O、メモリ使用量) の監視と取得 ワークロードの特性 (コンピューティング最適化 / メモリ最適化 / ストレージ最適化) に基づいてインスタンスタイプを最適化する ストレージを大量に消費する運用の場合は EBS 最適化インスタンスのパフォーマンスを追跡する 詳細については、 Scaling for performance with AWS Mainframe Modernization and Micro Focus をご覧ください。 検証プロセス 完全な JCL プロシージャを含む包括的なバッチスケジュールテストを実行する 確立された SLA に照らしてパフォーマンスを監視し、検証する ジョブの完了時間、リソース使用率、スループット率を追跡する 自動化されたパフォーマンス回帰テストを実施して、一貫した評価を行う 対象分野の専門家 (Subject Matter Expert: SME) による承認 SME は、重要なアウトプットと例外パスを検証する必要があります。さらに、承認が迅速に行われ、透明性があり、監査可能になるよう、照合結果のレポートや、そのタイミング、差分は自動的に提供されるべきです。 ベストプラクティス 6: 一般的なツールを活用して移行を加速 Mainframe Access ツール (MFA) Rocket Software の MFA は、ユーザーフレンドリーなドラッグアンドドロップインターフェイスと、メインフレームと他のシステム間で複数のデータセットをプルおよびプッシュできるバッチ処理システムの両方を提供します。これにより、FTP ジョブを実行してメインフレームから移行先プラットフォームにファイルをプッシュする必要がなくなります。たとえば、MFA を使用して区分データセット (PDS) ライブラリ、JCL、コントロールカードにアクセスし、インベントリを取得できます。さらに、テスト用のデータセットのダウンロードにも使用できます。 MFA は双方向で動作するため、テスト出力ファイルをメインフレームに送り返して、メインフレームが生成した出力と比較することができます。プロジェクトチームは使い慣れたメインフレームの SuperC ユーティリティを引き続き使用して、即時の検証を実施しつつ、移行先環境で新しいツールを徐々に習得できます。 Data File Converter (DFCONV) Rocket Software のバッチデータファイルコンバーターである DFCONV は、EBCDIC と ASCII 間の変換など、さまざまな形式間のファイル変換に使用されます ※ 。これにより、移行したデータセットを ES で使用できるようになります。ワークフローは MFA のバッチまたはコマンドラインインターフェイスを使用してメインフレームからソースデータセットをダウンロードし、DFCONV を使用して必要な形式に変換します。 (※) 訳注: IBM 日本語文字セット (コードページ 930, 939, 1390, 1399) は直接扱う場合に制約がある可能性あり 統合開発環境 (IDE) Eclipse は、特に Linux プロジェクトの開発とテストのための主要なプラットフォームです。社内標準によって、開発者はマイクロソフトの Visual Studio または VS Code を選択することもあります。Rocket Enterprise Developer と Visual COBOL はどちらも Eclipse や VS Code とシームレスに統合されています。これらの開発者ツールは、Windows 環境と Linux 環境での編集、コンパイル、デバッグをサポートします。 ベストプラクティス 7: 包括的なデータ移行戦略の策定 統合テストデータおよびシステムテストデータを特定する (テスト可能で反復テスト可能なものにする) 統合テストと end-to-end のシステムテストをサポートするために必要なすべてのデータは、できるだけ早く特定する必要があります。現新照合テストを容易にするためには、システムテスト環境をメインフレームと何度か同期させる場合が多いです。 EBCDIC もしくは ASCII いずれでデータを保持するか早い段階で判断する (そしてその方針を変えない) EBCDIC と ASCII のどちらを選択するかは、データ変換プロセス、アプリケーションの互換性、潜在的なパフォーマンスオーバーヘッドに影響します。EBCDIC を維持することで移行の複雑さを軽減し、正確なデータ表現を維持できますが、ASCII を採用することで最新のプラットフォームやツールとの統合が容易になります。この決定を下す際には、組織固有のアプリケーション要件、データ特性、長期的なモダナイゼーション目標を考慮して、これらの要因を慎重に検討する必要があります。 データレプリケーション計画とカットオーバータイムライン (「移行ウィンドウ」が意味するものを念頭に) この目標設定は変動が大きく、カットオーバーがいつ行われるかに大きく依存します。データが特定されたら、データの移行に必要な時間の見積もりを行う必要があります。その結果、カットオーバーで利用できる許容可能なダウンタイムを超える時間が発生する可能性があります。その場合は、データカットオーバーの開始日と実際の稼働日に基づいて、静的データと動的データを判断します。静的データは、メインフレーム上で変更されるリスクなしに、本番稼働までの数日または数週間で移行できます。動的データは、本番稼働日に移行する必要がある残りのデータです。end-to-end の移行リハーサルを 2 回以上実行し、移行ウィンドウに対して 20 ～ 30% のバッファーが得られるまで計画を調整します。 履歴データの保存とアクセス (事前移行と事後移行 — いずれにするか選ぶ方法) 多くのお客様が、長年にわたる履歴データを維持することが規制上または法律上の要件となっています。このような履歴データはターゲット環境に移行する必要があります。履歴データの量が多い場合は、運用開始の前または後に履歴データを移行することを検討します。 物理ファイルの移行 (フォーマット、ハンドラー、ツール) — 知っておくべきこと テキスト以外のデータを含むファイル (COMP や COMP-3 フィールドを含むファイルなど) には、構造ファイルと呼ばれるものが必要です。これはデータファイル内のデータを解釈して表示する方法を定義するもので、Rocket の構造ファイルエディタを使用して作成されます。構造ファイルはコピーブックとコンパイルされたプログラムに基づいて作成されますが、同じ物理ファイル内に複数のレイアウトを含むファイルでは構造が条件付きになるため、複雑さが増します。これらの構造は EBCDIC から ASCII への変換時に使用されます。 データベース移行 (カットオーバーのリスクを最小限に抑えるための戦略的な選択肢) 移行対象のデータベースエンジンを選択するときは、互換性の重要度、コストに関する考慮事項、チームスキル、および長期的な柔軟性のニーズに基づいて、選択肢を慎重に評価します。機能マッピング、データ型変換、コードページを漏れなく文書化し、移行の整合性を確保するために検証クエリを開発することが不可欠です。Db2 LUW (Linux, UNIX, and Windows) は、ベンダーへの依存と柔軟性の低下を伴いますが、メインフレーム Db2 に最も近い動作を実現し、コード変更が少なくて済み、移行リスクも軽減されます。一方、PostgreSQL には、ライセンス料ゼロ、強力な SQL 標準準拠、JSON サポートなどの最新機能、優れたクラウド柔軟性など、大きな利点があります。ただし、Db2 固有の機能のマッピング、潜在的なチームスキルの向上、動作が異なるアプリケーションの変更が必要になります。他に実行可能なマイグレーションパスとしては、Microsoft SQL Server 用や Oracle 用の Host Compatibility Option を使って Db2 スキーマ/データ移行とメインフレーム動作エミュレーションを実現する方法もあります。他に利用できるデータベースオプションについては、Rocket Software に確認してください。 検証とガバナンス 効果的な検証とガバナンスを行うには、エンコーディングを考慮したファイル比較、行単位の比較、コントロール全体の比較、対象を絞ったビジネスクエリ、タイミングデルタの注意深い分析など、移行プロセス全体にわたる統制チェックが必要です。組織は、包括的なマニフェスト、チェックサム、詳細なレポートを保存し、導入前に何度も移行リハーサルを行う必要があります。最も重要なのは、検証ゲートが満たされないまま本番稼働することが無いよう明確な基準を確立し、データの整合性とシステムの信頼性を確保することです。 結論 リプラットフォームしましょう。メインフレームから AWS へのリプラットフォームによる移行は、単なる技術的な移行ではなく、戦略的な進化を表しています。本ブログで紹介した 7 つのベストプラクティスに体系的に従うことで、組織はリスクを最小限に抑え、事業継続性を確保しつつ、メインフレームから AWS へのインフラストラクチャのトランスフォーメーションを成功させることができます。 著者 Mastan Shaik Mastan Shaik は、企業のクラウド移行と分散システムアーキテクチャを専門とする、AWS の Senior Solutions Architect です。アナリティクス、生成 AI の実装、クラウドネイティブソリューションの専門知識を活かし、金融サービス全体で Fortune 500 のクライアントに戦略的ガイダンスを提供しています。Mastan は、セキュリティとコンプライアンスの基準を維持しながら、組織がクラウドインフラストラクチャを最適化できるよう支援することに重点を置いています。経営幹部にクラウド変革戦略や生成 AI の導入フレームワークについて定期的に助言し、AWS のベストプラクティスに関する技術ワークショップをリードしています。 Cheryl du Preez Cheryl du Preez は、メインフレームとレガシーモダナイゼーションに関する AWS の World Wide Senior Specialist Solutions Architect です。Cheryl は、世界中のお客様を対象としたメインフレームのモダナイゼーションとトランスフォーメーションの取り組みにおいて、20 年以上にわたって技術的リーダーシップを発揮してきました。現在の役職では、AWS 独自の方法で生成 AI を活用したメインフレームのモダナイゼーションについて、お客様やパートナーに対して助言を提供しています。 Soham Tillu Soham Tillu は、金融サービスの AWS Senior Customer Solutions Manager です。Soham は主要なエンタープライズアカウントにおける戦略的技術イニシアチブを率いています。クラウドトランスフォーメーション戦略と AI のユースケースについて、上級エグゼクティブに対して定期的に助言しています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

本ブログは 2024 年 9 月 10 日に公開された Amazon Science Blog “ Better-performing “25519” elliptic-curve cryptography ” を翻訳したものです。 自動推論と CPU マイクロアーキテクチャ固有の最適化により、パフォーマンスと実装の正当性の保証がともに向上します。 暗号アルゴリズムはオンラインセキュリティに不可欠です。Amazon Web Services (AWS) では、Google の BoringSSL プロジェクトのコードをベースにしたオープンソースの暗号ライブラリ AWS LibCrypto (AWS-LC) に暗号アルゴリズムを実装しています。AWS-LC は、セキュリティと AWS ハードウェアへの最適化を両立した暗号アルゴリズムの実装をお客様に提供しています。 近年利用が広がっている暗号アルゴリズムに x25519 と Ed25519 があります。どちらも Curve25519 として知られる 楕円曲線 に基づいています。これらのアルゴリズムの実装をさらに改善するため、AWS では最近 AWS-LC における実装の見直しに取り組みました。本記事では以降、x25519 および Ed25519 をまとめて x/Ed25519 と表記します。 2023 年、AWS は AWS-LC における x/Ed25519 のアセンブリレベルの実装を複数リリースしました。 自動推論 と最先端の最適化技術を組み合わせることで、従来の AWS-LC 実装と比べてパフォーマンスが向上し、正当性の保証も強化されています。 具体的には、自動推論を用いて機能的正当性を証明するとともに、命令セットアーキテクチャ (ISA) の x86_64 および Arm64 において、特定の CPU マイクロアーキテクチャをターゲットとした最適化を行っています。また、実行時間の差異から秘密情報を推測するサイドチャネル攻撃を防ぐため、アルゴリズムの 定数時間 実行にも細心の注意を払っています。 本記事では、自動推論による正当性の証明プロセス、マイクロアーキテクチャ ( μ arch) の最適化技術、定数時間コードに関する考慮事項、パフォーマンス向上の定量的な評価など、この取り組みのさまざまな側面を紹介します。 楕円曲線暗号 楕円曲線の例 楕円曲線暗号は、公開鍵と秘密鍵のペアを使用する公開鍵暗号の一手法です。最もよく知られた公開鍵暗号方式の 1 つが RSA で、その公開鍵は非常に大きな整数であり、対応する秘密鍵はその整数の素因数です。RSA はデータの暗号化/復号とデータの署名/検証の両方に使用できます。(2024 年 9 月に、AWS チームのメンバーが Amazon Science ブログにて、自動推論を活用した Amazon Graviton2 チップ上の RSA 実装の 高速化とデプロイの容易化 について紹介しています。) 楕円曲線は、公開鍵と秘密鍵を数学的に関連付ける別の手法です。この手法により、暗号方式をより効率的に実装できる場合があります。楕円曲線の数学理論は広範かつ奥深いものですが、暗号で使用される楕円曲線は通常、 y 2 = x 3 + ax 2 + bx + c ( a、b、 c は定数) の形の方程式で定義されます。この方程式を満たす点は 2 次元グラフ上にプロットできます。 楕円曲線には、2 点で曲線と交わる直線は他に高々もう 1 点でしか曲線と交わらないという性質があります。この性質を利用して曲線上の演算を定義します。例えば、曲線上の 2 点の加算は、最初の 2 点を通る直線が曲線と交わる第 3 の点そのものではなく、その第 3 の点を対称軸に関して反転した点として定義されます。 楕円曲線上の加算 ここで、曲線上の点の座標をある整数を法としてとると、曲線は平面上の離散的な点の集合になります。しかし対称性は依然として保たれるため、加算演算は引き続き矛盾なく定義できます。Curve25519 は大きな素数 (具体的には 2 255 – 19) にちなんで名付けられています。この素数を法とする数の集合と、同じ素数を法とする乗算などの基本算術演算を組み合わせることで、楕円曲線演算の基盤となる 体 (field) が定義されます。 楕円曲線の加算を繰り返し行うことをスカラー倍算と呼び、スカラーは加算の回数を表します。暗号で使用される楕円曲線では、スカラー倍算の結果のみがわかっている場合、スカラーが十分に大きければ元のスカラーを復元することは計算上困難です。このスカラー倍算の結果が公開鍵の基礎となり、元のスカラーが秘密鍵の基礎となります。 x25519 と Ed25519 暗号アルゴリズム x/Ed25519 の各アルゴリズムにはそれぞれ異なる目的があります。x25519 は鍵共有アルゴリズムであり、2 つのピア間で安全に共有シークレットを確立するために使用されます。一方、Ed25519 はデジタル署名アルゴリズムであり、データの署名と検証に使用されます。 x/Ed25519 アルゴリズムは TLS や SSH などのトランスポート層プロトコルで広く採用されています。2023 年には、NIST が Ed25519 の追加を含む FIPS 185-6 Digital Signature Standard の更新を発表しました。また、x25519 アルゴリズムはポスト量子暗号ソリューションにおいても重要な役割を果たしており、TLS 1.3 や SSH のポスト量子鍵共有ハイブリッド方式において、古典的アルゴリズムとして仕様に組み込まれています。 マイクロアーキテクチャの最適化 特定の CPU アーキテクチャ向けにアセンブリコードを記述する際には、その ISA を使用します。ISA は、利用可能なアセンブリ命令とそのセマンティクス、プログラマがアクセスできる CPU レジスタなどのリソースを定義するものです。ここで重要なのは、ISA はあくまで CPU の抽象的な定義であり、ハードウェアとしてどのように実現するかを規定するものではないという点です。 CPU のハードウェアレベルの詳細な実装はマイクロアーキテクチャと呼ばれ、各 μ arch には固有の特性があります。例えば、AWS Graviton 2 CPU と AWS Graviton 3 CPU はどちらも Arm64 ISA に基づいていますが、 μ arch の実装は異なります。AWS では、この μ arch の違いを活用することで、AWS-LC の既存実装よりもさらに高速な x/Ed25519 実装を実現できるのではないかと考えました。実際に、この仮説は正しいことが確認されました。 ここでは、 μ arch の違いをどのように活用したかを詳しく見ていきましょう。Curve25519 上にはさまざまな算術演算を定義でき、これらの演算を組み合わせて x/Ed25519 アルゴリズムが構成されます。概念的には、必要な算術演算は以下の 3 つのレベルに分けて考えることができます。 体の演算: Curve25519 の素数 2 255 – 19 で定義される体における演算 楕円曲線群の演算: 2 点 P1 と P2 の加算など、曲線上の要素に対する演算 トップレベルの演算: スカラー倍算など、楕円曲線群の演算を繰り返し適用して実現される演算 各レベルにおける演算の例。矢印はレベル間の依存関係を示しています。 各レベルにはそれぞれ独自の最適化の余地があります。AWS ではレベル 1 の演算に μ arch 固有の最適化を集中させ、レベル 2 と 3 については既知の最先端技術を採用しており、異なる μ arch 間でほぼ同一の実装となっています。以下に、x/Ed25519 の実装で採用した μ arch 固有の選択の概要を示します。 最新の x86_64 μ arch では、MULX、ADCX、ADOX 命令を使用しています。これらは、一般に BMI および ADX と呼ばれる命令セット拡張に含まれる命令で、標準アセンブリ命令 MUL (乗算) および ADC (キャリー付き加算) の変形です。これらの命令の特長は、組み合わせて使用することで 2 つのキャリーチェーンを並列に維持できる点にあり、最大 30% のパフォーマンス向上が確認されています。これらの命令セット拡張をサポートしない旧世代の x86_64 μ arch では、従来のシングルキャリーチェーンを使用しています 整数乗算器が改良された AWS Graviton 3 などの Arm64 μ arch では、比較的単純な筆算方式の乗算でも良好なパフォーマンスが得られます。一方、AWS Graviton 2 は乗算器が小さい Arm64 μ arch であるため、乗算を再帰的に分解する減算形式の カラツバ乗算 を採用しています。これは、この μ arch では 128 ビットの結果を生成する 64×64 ビット乗算のスループットが他の演算と比べて大幅に低く、カラツバ最適化がより小さな数値サイズでも有効になるためです すべての μ arch に共通するレベル 1 の演算についても最適化を行いました。その一例が、バイナリ最大公約数 (GCD) アルゴリズムによる モジュラー逆元 の計算です。AWS ではバイナリ GCD の 「divstep」形式 を採用しています。この形式は効率的な実装に適している一方、もう一つの目標である正当性の形式的な証明はより困難になります。 バイナリ GCD は 2 つの引数を持つ反復アルゴリズムで、最大公約数を求めたい数を初期値として使用します。各イテレーションで引数は明確に定義された方法で縮小され、いずれか一方がゼロになるとアルゴリズムは終了します。 n ビットの 2 つの数に対しては、標準的な実装では各イテレーションで合計少なくとも 1 ビットが除去されるため、2 n 回のイテレーションで十分です。 しかし divstep の場合、基底ケースに到達するために必要なイテレーション回数を解析的に決定するのは困難と考えられています。この上界に対する最も扱いやすい証明は、引数値に対応する点を含む 2 次元空間の領域を証明可能な形で過大近似する精巧な「stable hull」に基づいており、入念な帰納法の議論が展開されています。x25519 と Ed25519 の発明者の一人である Daniel Bernstein 氏は、本記事の著者の一人である John が開発した HOL Light 対話型定理証明器を使用して、この上界の 形式的な正当性 を証明しました。(HOL Light の詳細については、先述の RSA に関する記事 をご覧ください。) パフォーマンスの結果 ここでは、パフォーマンスの向上について紹介します。簡潔にするため、AWS Graviton 2、AWS Graviton 3、Intel Ice Lake の 3 つの μ arch に焦点を当てます。パフォーマンスデータの収集には、各 CPU μ arch に対応する EC2 インスタンス (それぞれ c6g.4xlarge、c7g.4xlarge、c6i.4xlarge) を使用しました。各アルゴリズムのベンチマークには AWS-LC speed tool を使用しました。 以下のグラフでは、単位はすべて 1 秒あたりの演算回数 (ops/sec) です。「before」列は AWS-LC の既存の x/Ed25519 実装のパフォーマンスを、「after」列は新しい実装のパフォーマンスを表しています。 Ed25519 の署名演算では、3 つの μarch 全体で、新しい実装により 1 秒あたりの演算回数が平均 108% 向上 Ed25519 の検証演算では、3 つの μarch 全体で、1 秒あたりの演算回数が平均 37% 向上 最も大きな改善が見られたのは x25519 アルゴリズムです。なお、以下のグラフにおける x25519 の演算には、x25519 鍵共有に必要な 2 つの主要な演算である基底点乗算と可変点乗算の両方が含まれています。 x25519 では、新しい実装により、3 つの μarch 全体で 1 秒あたりの演算回数が平均 113% 向上 AWS Graviton 2、AWS Graviton 3、Intel Ice Lake の 3 つの μ arch 全体で、平均 86% のパフォーマンス向上を達成しました。 正当性の証明 AWS では、AWS-LC における x/Ed25519 実装のコア部分を s2n-bignum で開発しています。s2n-bignum は、暗号アプリケーション向けに設計された AWS が所有する整数演算ルーチンライブラリです。s2n-bignum ライブラリでは、 HOL Light を使用して実装の機能的正当性も証明しています。HOL Light は、高階論理 (Higher-Order Logic、略して HOL) のための対話型定理証明器です。名前の「Light」が示すとおりシンプルさを重視して設計されており、構成による正しさ (correct by construction) のアプローチで証明を行います。このシンプルさにより、「証明された」とされるものが本当に厳密に証明されたものであり、証明器のバグによる誤りではないという高い確信が得られます。 実装をアセンブリで記述する際にも、同じシンプルさの原則に従っています。アセンブリでの記述はより困難ですが、正当性の証明においては明確な利点があります。コンパイラに依存しない証明が可能になるためです。 下の図は、x/Ed25519 の正当性の証明プロセスを示しています。このプロセスには 2 種類の入力が必要です。1 つ目は評価対象のアルゴリズム実装、2 つ目はアルゴリズムの正しい数学的挙動と CPU の挙動をモデル化した証明スクリプトです。証明は HOL Light 固有の関数列として記述され、証明戦略とその適用順序を定義します。証明の記述は自動化されておらず、開発者の創意工夫が求められます。 HOL Light は、アルゴリズム実装と証明スクリプトを入力として受け取り、実装が正しいと判定するか、判定できない場合は失敗を返します。HOL Light はアルゴリズム実装をマシンコードのバイト列として扱い、CPU 命令の仕様と証明スクリプト内に開発者が記述した戦略を用いて、実行の正当性を検証します。 CI 統合により、正当性の形式的証明に合格しない限り、アルゴリズム実装コードの変更を s2n-bignum のコードリポジトリにコミットできないことが保証されます。 正当性の証明のこのステップは自動化されており、s2n-bignum の継続的インテグレーション (CI) ワークフローにも組み込まれています。CI がカバーするワークフローは、図中の赤い点線で示されています。CI 統合により、正当性の形式的証明に合格しない限り、アルゴリズム実装コードの変更を s2n-bignum のコードリポジトリにコミットできないことが保証されます。 CPU 命令の仕様は、正当性の証明において最も重要な要素の 1 つです。証明が実際に正しいものであるためには、仕様が各命令の実際のセマンティクスを正確に捉えている必要があります。この信頼性を高めるため、AWS では実際のハードウェア上で命令仕様に対するランダム化テストを実施し、ファジングによって不正確さを検出しています。 定数時間 AWS では、セキュリティを最優先事項として実装と最適化を設計しました。暗号コードは、権限のないユーザーが秘密情報を抽出できるような サイドチャネル を排除するよう努める必要があります。例えば、暗号コードの実行時間が秘密の値に依存する場合、攻撃者は実行時間からその値を推測できる可能性があります。同様に、CPU キャッシュの動作が秘密の値に依存する場合、キャッシュを共有する権限のないユーザーがその値を推測できる可能性があります。 x/Ed25519 の実装は、定数時間を念頭に置いて設計されています。入力値にかかわらずまったく同じ基本 CPU 命令シーケンスを実行し、データ依存のタイミングを持つ可能性のある CPU 命令は使用しません。 アプリケーションでの x/Ed25519 最適化の活用 AWS では、さまざまな AWS サービスのサブシステムにおける暗号処理に AWS-LC を広く使用しています。本記事で紹介した x/Ed25519 の最適化は、アプリケーションで AWS-LC を使用することで活用できます。アプリケーションへの AWS-LC の統合方法については、 GitHub の AWS-LC をご覧ください。 開発者がより簡単に統合できるよう、AWS は AWS-LC から複数のプログラミング言語へのバインディングを作成しました。これらのバインディングは、明確に定義された API を通じて AWS-LC の暗号機能を提供するため、高水準プログラミング言語で暗号アルゴリズムを改めて実装する必要はありません。現在、AWS は Java 向けの Amazon Corretto Cryptographic Provider ( ACCP ) と Rust 向けの AWS-LC ( aws-lc-rs ) のバインディングをオープンソースとして公開しています。さらに、 CPython が AWS-LC に対してビルドし、Python 標準ライブラリのすべての暗号処理に AWS-LC を使用できるようにするパッチも提供しています。以下に、暗号処理に AWS-LC を採用しているオープンソースプロジェクトの一部を紹介します。 暗号処理に AWS-LC を採用しているオープンソースプロジェクト 取り組みはこれで終わりではありません。AWS は引き続き x/Ed25519 のパフォーマンス改善に取り組むとともに、s2n-bignum と AWS-LC がサポートする他の暗号アルゴリズムの最適化も推進しています。最新情報については、 s2n-bignum と AWS-LC の GitHub リポジトリをご確認ください。 著者について Torben Hansen Torben Hansen は AWS Cryptography のアプライドサイエンティストです。 John Harrison John Harrison は Amazon Automated Reasoning Group のシニアプリンシパルアプライドサイエンティストです。s2n-bignum と HOL Light 定理証明器のメンテナーを務めています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。