The Doppler Quarterly (日本語) 夏 2018 | Page 70
ルールの一部の基準を以下に示します。
グループとスケジュール設定
• ビジネスでの重要度 移行優先度スコア、移行速度と移行の優先日 ( または優先停
• カスタム開発 ( 社内 ) 電日 ) を設定したカレンダーが
• アプリケーション階層
いま した。すべての情報を用
意し、タイムテーブルにアプリケーションをレイアウトするため
• 複雑性 にグループとスケジュール設定ルールを使用します。
• 準備状況 アプリケーションのグループ分けでは、アプリケーション評価
• サーバーの数 中に集めた依存関係の情報が必要です。これは、多様なアプ
この特別な例では 30 あまりのルールが使用されました。技術、
ビジネス、機能アプリケーションの特性が含まれます。アプリ
ケーションの優先度判定では、重要とみなされる基本的な特
性をすべて集めることが重要です。移行プロジェクトの個別要
件に基づいて、ルールを変更することも、新しいルールを追加
することもできます。
一般ロジックは、ビジネスの優先設定を反映する必要がありま
す。たとえば、非準拠の OS のアプリケーションは移行に追加
作業が必要です。したがって移行プログラムの費用など、いく
つかのメリットを実現するため早期にアプリケーションを移行
する必要があります。
この作業の最後で、アプリケーションとそれらのスコアのリスト
が完成します。このリストをスコアでソートすると、移行の優先
順が得られます。
移行速度
移行速度はアプリケーションを移行できる速さです。移行速度
の決定と計画には多様な要素を考慮する必要があります。一
般に、ビジネスケースから導出されるプログラム期間が決定要
因となります。しかしほかにも、ビジネスサイクル、アプリケー
ションアップグレードサイクル、サポート契約サイクル、必須スキ
ルおよび利用可能なスタッフなどの要因もあります。たとえば、 1
つのアプリケーションと 3 つの環境を再ホスト移行パターンで
移行するには、指定のリソースセットで 2、
3 日かかることがあり
ます。CTP はワークベンチ ( 必要なすべてのノウハウを持ち、
特定の移行パターンに専念するスタッフで構成される自己完結
グループ ) のコンセプトを使用します。
10 台のサーバーと 3 つの環境 ( 開発、 QA、本稼働 ) がある 1
つのアプリケーションを 1 つのワークベンチで 3 日で移行でき
ると想定しましょう。
68 | THE DOPPLER | 2018 年夏号
リケーションが相互に持っている強力な依存関係に基づいて、
同時に移行するアプリケーショングループを定義するもので
す。依存関係があっても、アプリケーションを別々に移行する
ことは可能です。ただし、依存関係のタイプやレイテンシーの許
容時間などが決定プロセスに影響します。ここでは詳細を省略
します。強い依存関係があるアプリケーショングループは同時
に移行する必要があるという仮定で進めます。
反復プロセスにわたって、次のルールを使用してアプリケー
ションをグループに分け、ソートします。続いてウェーブスケ
ジュール設定プロセスを開始します。アプリケーションをグルー
プ分けし、ウェーブ (1 つの期間に収めるアプリケーションの論
理グループ ) に次のように入れます。
• V1 ウェーブスケジュール ( スコア )
• すべてのアプリケーションを優先度スコアの昇順
でソートする
• 実現可能な速度を基に特定期間に必要なアプ
リケーション数を決定する。期間は一般に、事業
部門、ビジネス機能などに基づいてアプリケー
ションをグループ分けするなど、多様な要素に基
づいた移行ウェーブです。
• 残りの期間で残りのサーバーに対してグループ化
を継続する。
• アプリケーションとウェーブをリストした、 V1
ウェーブスケジュールが完了しました。
• V2 ウェーブスケジュール ( スケジュール優先設定 )
• スケジュール優先設定が示す場合に、特定ウェー
ブにアプリケーションを移動する