要約

  • Google Cloud Modernize は、コスト評価、コードと依存関係の分析、移行ツール、Google Cloud の移行先を一つの製品群にまとめた。新しい Agentic Quick Estimator は、VMware の資産一覧とインフラ情報を使い、Compute Engine の総保有コストを予測する。
  • 予測は資産データ、サイズ設定、リージョン、ライセンスなどの前提に左右される。移行完了、本番受け入れ、移行全体の費用、顧客の実現済み節約を示すものではない。
  • 商業上の検証には、確認済みの移行元台帳、顧客が承認した移行先と費用前提、切り替え成功、ワークロードの受け入れ、同条件の基準との移行後請求額の照合が必要だ。

Google Cloud が10月6日に発表した Modernize の訴求は明快だ。評価、コード分析、移行をAI支援の製品群でつなぎ、複数年に及びうる近代化計画を短縮する。商業的な筋は通っている。サーバーを早く棚卸しし、依存関係と移行先を比較できれば、何を動かすかを決める時間は縮むだろう。だが、最も難しい経済性の問いはその後に残る。試算は個々のアプリケーションの条件に耐えるか。受け入れられたシステムは、移行全体を終えた後に本当に安く運用できるのか。

発表には、混同すべきでない複数の機能が含まれる。Googleによると、Migration Center の Agentic Quick Estimator は一般提供となり、RVTools などのVMwareインベントリーとインフラ入力から Compute Engine 環境のTCOを予測する。新しい Modernization Hub は、Java、.NET、メインフレームのアプリケーションについて、コード分析と依存関係のマッピングを行う。一方、EKS-to-GKE 移行エージェントはパブリックプレビューで、発見、Kubernetesマニフェスト変換、ストレージとネットワークのマッピングを担い、人間の承認を残すと説明されている。試算、理解、変換、検証は別々の段階であり、どれも単独では本番への切り替えを意味しない。(Google Cloudの10月発表)

試算には入力の前提が引き継がれる

TCOが意思決定に役立つかは、移行元の把握と移行先の選択にかかっている。Googleの文書では、VM、vCPU、メモリー、ストレージの合計を手入力するか、RVToolsのファイルを取り込める。次に移行先リージョン、マシン系列、ストレージ種別などを選ぶ。レポートは入力された移行元と、モデル化した Google Cloud の構成を比較する。性能データがない場合、Migration Center は選択されたサイズ方針から推奨値を出し、実測ではなく推定した資産を区別する。計画には有用だが、実際の利用量を請求した結果ではない。(Quick TCO Estimatorの文書；TCOレポートの文書)

この違いは買い手の交渉力にも影響する。予測は、調査や試験導入に予算を出すかを判断する材料になる。しかし、それだけでピーク負荷に対する容量の適正さ、依存関係の網羅、移行後の運用コスト低下を証明できない。同じサービス水準と負荷期間で比較し、顧客に関係する費目をそろえる必要がある。移行元と移行先の利用料、ソフトウェアライセンス、ネットワークとストレージ、移行作業、並行稼働、運用サポート、退出手段などだ。利用者の入力次第でレポートが含む項目は変わり得る。見出しの一つの数字が全費用を表すと思い込まず、実際のレポートを確かめたい。

Migration Center 自身の文書も、技術適合性の判定を商業上の受け入れ証明とはしていない。「適合」は収集データに対する条件で技術的障害が見つからなかったという意味で、「作業を要する適合」は追加作業の可能性を示す。Googleはさらに、クラスターとワークロードの棚卸し、依存関係と運用手順の評価、移行方針と日程の決定、計画の検証を勧めている。形式的な手順ではない。推奨を安全に実行でき、費用を算定できる変更へ変える実務だ。(Migration Centerの適合性評価；EKSからGKEへの移行ガイド；移行計画ガイド)

一段階の短縮が、移行全体の完了ではない

EKS-to-GKE エージェントは境界を示す。Googleは Kubernetes マニフェストの変換とストレージ・ネットワークの対応付けを挙げ、人間の承認とメモリー上の認証情報保護を残す。反復作業を減らし、移行経路を確認しやすくする可能性はある。ただしパブリックプレビューは、個別ワークロードのテストに代わる万能手段ではなく、発展途上の機能として扱うべきことも示す。ネットワークポリシー、ストレージの意味、監視、ID、信頼性目標、データ転送、リリース手順は、引き続きサービスの移行可否を左右する。Googleは本番移行の件数、エラー・ロールバック率、顧客ごとの時間・費用削減を開示していない。

発表に載る顧客事例は背景情報であり、今回の新製品の証明ではない。Googleによると、NetEase Games は以前、GKE 上でサービスをコンテナ化し、ピーク時のサーバー拡張を数時間から5分に短縮、サーバー費用を40%削減した。ブログはその結果を Google Cloud Modernize や新しいEKSエージェントに結び付けていない。これは、あるGKE導入について顧客が述べた効果であり、10月発表のツール群の測定結果ではない。

メインフレーム、VMware、アプリケーション近代化にも同じ証拠の線引きが必要だ。コード分析は構造と依存を明らかにし、二重稼働は切り替え前の出力を照合し、移行先は容量を提供する。価値が生じるのは必要な動作が保たれ、運用費が下がるか、新機能が追加費用を正当化したときだ。「ロードマップ短縮」はエンジニアリング時間に関する仮説であって、総費用の実績低下ではない。

切り替え後も残る台帳が必要

Googleは試算器と移行先サービスを用意し、顧客はインベントリー、ワークロードの優先順位、承認の多くを担う。導入パートナーが作業を請け負うこともある。責任が明確なら効率的な分担だ。しかし、移行先を試算する会社が推奨容量も販売し、顧客が前提を再現できなければ、評価は難しくなる。利益相反や誤った見積もりの証拠という意味ではない。入力、版管理された前提、独立した基準を保存すべき理由である。

計測は導入後も続く必要がある。各ワークロードについて、移行元の需要プロファイル、移行先構成、ライセンス扱い、移行と並行稼働の費用、受け入れ基準、サポート範囲、実際のクラウド請求を残す。可能な範囲で需要、遅延、可用性、ストレージ、リージョンをそろえて比較する。移行でサービスが変わるなら、その変化も報告し、請求差をすべて基盤の効果にしない。計算費が下がってデータ、ネットワーク、サポート費が上がる場合もある。直接請求が同程度でもリリースが速くなれば価値はあり得る。台帳があれば両方を見分けられる。

Google Cloud Modernize は、判断と準備にかかるコストを下げる可能性がある。しかし発表は、それがどの程度、本番移行の成功やより良い経済結果になるかを示していない。検証済みの移行元基準、受け入れられたワークロード、実現した費用がつながるまでは、新ツールは仮説へ早くたどり着く道であり、移行が得だという証明ではない。

出典