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 ウェーブスケジュール ( スケジュール優先設定 ) • スケジュール優先設定が示す場合に、特定ウェー ブにアプリケーションを移動する