InterCloud

ガイド · クラウド

現状評価から切り替えまで、企業のためのクラウド移行プレイブック

移行とは一連の意思決定であり、その大半はサーバーを1台も動かす前に行われます。このプレイブックでは、フェーズ、リージョンとデータレジデンシーの選択、そして切り替えの週末を平穏に終えるための実践をまとめています。

プレイブックの目的

企業が移行を一度で終えることはまれです。まず1つのシステムを移行して学び、次に10のシステムを移行します。プレイブックはその学びを記録し、第2波を第1波より速く安全に進められるようにするものです。システムをどう評価するか、ランディングゾーンをどう構成するか、切り替えをどう実施するか、そして「完了」とは何を指すのかをまとめます。このガイドは、当社がお客様と取り組む際の出発点としているものです。そのまま従うのではなく、貴社の組織に合わせて調整してください。

全体を通じて2つの原則があります。第一に、サーバーではなく業務機能を移行することです。問われるのは仮想マシンをどうコピーするかではなく、アプリケーションとそのデータがどのように利用者へのサービスを続けるかです。第二に、意図的に確定させる瞬間まで、すべてのステップを元に戻せる状態に保つことです。

フェーズ

各フェーズは、運営委員会が判断できる意思決定で締めくくります。フェーズは波をまたいで重なり、第1波の移行中に第2波の評価を行います。

  1. 1

    評価

    すべてのアプリケーションについて、オーナー、依存関係、データ分類、連携、ライセンス、現在のインフラを棚卸しします。依存関係とリスクに基づいてアプリケーションを波に分けます。それぞれの方針を決めます。リホスト（そのまま移行）、リプラットフォーム（マネージドデータベースへの移行など小規模な変更）、リファクタリング（コンテナ化または再設計）、置き換え（SaaS）、廃止のいずれかです。成果物：方針付きの移行計画（ウェーブプラン）と最初のビジネスケース。

  2. 2

    計画

    第1波について、移行先のアーキテクチャ、自社拠点からのネットワーク経路、ID（人にはSSO、ワークロードにはロール）、データ移行の方法、アプリケーションごとの切り替えパターンを設計します。受け入れ基準もこの段階で書き出します。どのテストを、どのユーザーが行い、どのレポートが一致しなければならないかです。成果物：アプリケーションごとの設計書とランブックの骨子。

  3. 3

    ランディングゾーンの構築

    ワークロードが移る前に、アカウント構成、ネットワーク、ID、ログ、セキュリティのベースライン、バックアップ、コスト管理をコードとして作成します。これは以降のすべての波を支える土台なので、一度しっかり作る価値があります。成果物：自らのコンプライアンスチェックに合格する、Terraformで管理された環境。

  4. 4

    波ごとの移行

    まず非本番環境、次に本番環境を、1波ずつ移行します。パターン上必要な場合はデータを継続的にレプリケーションし、移行先で実データを使って受け入れテストを行い、他の誰かに影響が出る前に不具合を修正します。成果物：旧システムを稼働させたまま、受け入れテストに合格した移行先環境。

  5. 5

    切り替え

    リハーサル済みのランブックを実行します。変更を凍結し、最終的なデータ同期を完了し、トラフィックを切り替え、検証し、告知します。移行元の環境には手を加えず、合意した期間はロールバックに備えておきます。成果物：移行先で稼働する本番環境と、明示的に通過したロールバック判断ポイント。

  6. 6

    最適化

    安定稼働後は、安全のために過剰に確保したリソースを適正化し、移行可能なワークロードをマネージドサービスやコンテナへ移し、利用量が予測できる部分には確約利用の料金を適用して、移行元を廃止します。成果物は、運用コストのベースラインと、次のウェーブに向けて移行手順書へ反映した教訓です。

リージョンの選定とデータレジデンシー

まずリージョンを選びます。国内リージョンがあれば、耐障害性のための複数のアベイラビリティーゾーンと、国内ユーザーへの低いレイテンシが得られます。AWSアジアパシフィック（バンコク）リージョン（ap-southeast-7）はその一例で、タイ国内にユーザーを持つ組織にとって、シンガポールからサービスを提供するのではない、クラウドの歴史の大半において存在しなかった選択肢となっています。レイテンシに敏感なシステムや、社内方針や規制当局がデータの国内保管を望む組織にとっては、国内リージョンが標準の出発点です。

注意点が2つあります。新しいリージョンでは、すべてのサービスが最初から提供されるわけではありません。設計に含まれる各マネージドサービスについて、確定前にリージョン別のサービス一覧を確認し、代替策（別のサービス、またはそのコンポーネントだけ別のリージョン）を用意してください。また、データレジデンシーは技術的な判断である前に方針上の判断です。PDPAなどの個人データ保護法は一定の条件の下で国外移転を認めており、金融サービスなど業界ごとの規制当局が独自の要件を持つこともあります。どのデータ区分を国内に留め、どれを災害復旧のために国外へ複製してよいかを書き出し、法務・コンプライアンス部門に確認してもらいます。そのうえで、それを組織のポリシーにリージョン制限として組み込み、誤った場所に作られたリソースを後から発見するのではなく、未然に防ぐようにします。

災害復旧にも同じ明確さが必要です。リージョン内では、複数のアベイラビリティーゾーンが施設単位の障害から守ります。リージョン全体に及ぶ事象に備えるには、バックアップやスタンバイに2つ目のリージョンを使ってよいか、それをどのリージョンにするか、そして事業としてどの程度の目標復旧時間と目標復旧時点に予算を割くかを決めます。

Terraform：コードとしてのランディングゾーン

ランディングゾーンのうちコードで定義できるものは、すべてコードで定義すべきです。アカウントと組織のポリシー、ネットワークとルーティング、IDとロール、ログと監査証跡、暗号鍵、バックアップポリシー、予算とアラートなどです。当社がTerraformを選んでいるのは、宣言型で、プロバイダーに依存せず、アプリケーションコードと同じプルリクエストの流れでレビューできるためです。

管理しやすく保つための実践がいくつかあります。ステートはロック付きでリモートに保存し、環境ごと、論理コンポーネントごとに分けて、ある場所のミスが別の場所を壊さないようにします。繰り返し作成するもの（コンテナ定義、ロードバランサーのルール、IAMロール、ロググループを備えたサービスなど）は、適切な名前を付けた小さなモジュールにしてバージョン管理します。後のコスト管理がこれに依存するため、すべてのリソースに、単一のタグ付けモジュールからオーナー、環境、アプリケーション、コストセンターのタグを付けます。変更のたびにplanを実行し、レビューを必須とし、ノートPCからではなくパイプラインから適用します。ドリフトは定期的に検出し、コンソールでの手作業による変更は、新しい標準としてではなく、調整すべきインシデントとして扱います。

その結果、第2波の環境はプロジェクトではなく、1件のプルリクエストで用意できるようになります。

切り替えパターンの比較

パターンはプログラム単位ではなく、アプリケーションごとに選びます。どのパターンが適するかは、許容できるダウンタイム、データ量、トラフィックがシステムに届く経路によって決まります。

パターン仕組み適したケースダウンタイムとロールバック
ビッグバン（オフライン）移行元を停止し、データをコピーし、移行先を起動して、DNSまたはエンドポイントを切り替えます。小規模なシステム、バッチ処理、メンテナンス時間を確保できる社内ツール。ダウンタイムはコピーにかかる時間と同じです。ロールバックは簡単で、手を加えていない移行元に向け直すだけです。
レプリケーション後に切り替え移行元を稼働させたまま、移行先へデータベースを継続的にレプリケーションし（マネージドのレプリケーションサービスを使うなど）、切り替え時に最終同期を行って切り替えます。長時間の停止は許されないが、短時間なら許容できるデータベースやERP。ダウンタイムは数分です。ロールバックには逆方向のレプリケーションが必要で、それがなければ切り替え以降のデータ損失を受け入れることになります。どちらにするかは事前に決めておきます。
ブルーグリーン移行先の環境を移行元と並行して完全に構築・テストし、ロードバランサーまたはDNSで一度にトラフィックを切り替えます。ステートレスなワークロードやWeb層のワークロード、データ層がすでに移行済みのアプリケーション。ほぼゼロです。データ層が共有または同期されている限り、ロールバックは同じ切り替えを逆に行うだけです。
カナリア／重み付けトラフィックの一部（重み、地域、ユーザーグループ単位）を移行先に送り、確信が高まるにつれて割合を増やします。多くのユーザーを抱える顧客向けアプリケーション。全員に影響が及ぶ前に問題を検出したい場合。設計上ゼロです。ロールバックは重みを下げるだけです。両側でのセッション管理とデータの整合性が必要です。
ストラングラー（段階的）機能を1つずつ移行先の新しいサービスにルーティングし、レガシーシステムを縮小して最終的に廃止します。リファクタリング中の大規模なモノリス、複数年にわたるモダナイゼーションプログラム。各ステップでゼロです。ロールバックは機能単位です。全体としては最も時間がかかりますが、変更ごとのリスクは最も低くなります。

ロールバックのリハーサル

どのランブックにもロールバックの章がありますが、実際に実行したことのあるチームはわずかです。非本番環境で、同じメンバー、同じチェックリスト、時間計測のもと、切り替え全体を少なくとも一度リハーサルし、続けてロールバックもリハーサルします。実施判断（Go/No-Go）の基準は当日より前に決めておき（どのテストに合格すべきか、どの関係者が確認すべきか、何時までか）、最終判断を下す担当者を1人指名します。後戻りできない時点も明示しておきます。これは、新しい取引が移行先にしか存在しなくなり、ロールバックすれば手作業でデータを突き合わせる必要が生じる時点です。

本番の切り替え中は、何かが起きたときではなく、決まった間隔で連絡します。順調であることを伝えるだけでも30分ごとに状況を報告すれば、業務部門は落ち着いて待つことができ、チームは作業に集中できます。終了後は、記憶が新しいうちに短い振り返りを行い、プレイブックを更新します。

初日からのコスト管理

クラウドの請求額は放っておけば増え続け、誰かが責任を持って初めて下がります。最初の本番ワークロードを移す前に、次の管理策を組み込んでください。

  • アカウントごと・アプリケーションごとのアラート付き予算。財務部門だけでなくアプリケーションのオーナーからも見えるようにします。
  • ポリシーで強制する必須タグ。すべての支出の帰属先を明らかにします。
  • 非本番環境は業務時間外に停止するようスケジュールするか、Terraformで必要なときに構築します。
  • 移行は効率よりも安全を優先してサイジングされるため、各波の1か月後に適正化のレビューを行います。
  • コミットメント型の料金（Savings Plansやリザーブドキャパシティ）は、利用状況が安定し、把握できてから適用します。
  • ストレージのライフサイクルルール：ログ、バックアップ、スナップショットを安価な層へ移し、スケジュールに沿って期限切れにします。
  • 運用上の節減効果が実際にある部分では、マネージドサービスとコンテナを使います。コスト削減に再設計は必須ではありません。
  • 可用性のレビューと同じ厳密さで、毎月コストをレビューします。

移行計画へのセカンドオピニオン

移行計画（ウェーブプラン）を共有いただければ、当社なら何を変えるかをお伝えします。当社のクラウド・インフラチームは、Terraformで管理されたAWS環境を構築し、AWSアジアパシフィック（バンコク）リージョンへの移行も含め、企業の移行を実施しています。

営業担当と話すデータ保護ガイドを読む