Twitter
Facebook
Hatena
Google Cloudを活用したクラウド移行(富士ソフトによる伴走支援)

富士ソフトはGoogle CloudのInfrastructure Modernization支援パートナーです

VUCA時代と呼ばれる多様化する時代において、「デジタルトランスフォーメーション」という言葉はもはやビジネスシーンにおいて当たり前のものとなりました。企業には、日々変化するお客様のニーズや市場環境に対応するため、迅速かつ柔軟なビジネス展開が求められています。
このような状況下で、企業のITインフラには、業務やアプリケーションのニーズに素早く対応できる高い柔軟性と拡張性が求められています。従来のレガシーシステムでは、新しい技術やサービスの導入に時間がかかり、ビジネスの俊敏性を阻害してしまう可能性があります。
そこで重要となるのが、ITインフラのモダナイズです。インフラをモダナイズするとは、単に新しいハードウェアやソフトウェアを導入することではありません。それは、ビジネスの成長を支える基盤として、より柔軟かつスケーラブルなIT環境を構築することなのです。

Google Cloud Japanは、2024年4月に開催した 「Modern Infra Summit Tokyo ‘24」で、クラウドへのインフラストラクチャ移行(Lift & Transform)に課題を抱えるお客様を支援するため、新たに「Infrastructure Modernization 支援パートナー」との連携を発表しました。
富士ソフトは上記パートナーに選定されています。本コラムでは、当社のGoogle Cloudを活用したクラウドへのインフラストラクチャ移行支援についてご紹介します。

参考リンク: https://cloud.google.com/blog/ja/topics/partners/overcoming-the-cloud-migration-obstacle-with-google-cloud-partner/

Infrastructure Modernization支援パートナーの目的

Google Cloud JapanのInfrastructure Modernization支援プログラムは、クラウドへのインフラストラクチャ移行を検討されているお客様、現在のクラウド環境の運用に課題を感じられているお客様に対して、クラウドジャーニーの成功を共に目指す、ニーズに迅速かつ柔軟に対応できるインフラストラクチャを目指すための「伴走型支援」を提供することを目的としています。クラウド移行/運用における技術的な課題や、組織的な障壁など、お客様が抱える具体的な課題をヒアリングし、最適な解決策を共に模索していきます。
お客様からのヒアリング、コミュニケーションを重ねながら、お客様のビジネス課題を深く理解し、最適なクラウド設計を支援します。同時に、クラウドの特性を最大限に活かした基盤設計・運用設計を共に考えることで、お客様のビジネス目標を見据えた、継続的に成長可能な基盤の実現に貢献します。

富士ソフト流Infrastructure Modernization支援の進め方

当社がどのようにお客様のInfrastructure Modernization支援を行なっているのか、ステップ別にご紹介します。
当社は、お客様の状況やニーズに応じて最適な支援を行います。長くクラウド環境を運用していくためにも、お客様の現状をつまびらかにするための最初のステップはとても重要です。進め方の全体像については、️下図をご参照ください。

それでは各ステップで実施する内容についてご説明します。

ステップ1:ビジネス要件確認

まずは、お客様のインフラストラクチャ環境における課題を抽出します。これはオンプレミス環境、クラウド環境問わず、現行インフラ環境におけるもの全てです。お客様にはブレインストーミングを行なって頂き、一定の時間を掛けて、システム構成、運用、各種制約、組織面等における課題を抽出して頂きます。そしてその課題を分類別に仕分けし整理しながら、なぜ今そのようになっているのかをつまびらかにし、本来目指したいもの、目指すべきものは何なのかを、ディスカッション形式で検討していきます。これは次のステップで、To-be像を検討するためのインプット情報となるとても重要なステップです。
また、合わせてTo-be像も最初のステップの中で検討します。クラウド移行を目指して、またはクラウド環境の改善を目指して、どのような姿になりたいのかを検討します。会社の中で求められているミッションと照らし合わせるのもいいかと思います。ここではまず、漠然としていても構わないので、仮説としてのTo-be像を一緒に考えていきます。

ステップ2:技術・運用要件検討

ここではステップ1で抽出した各課題に対して、次のプラットフォームではどのように対応していくのか、移行後の運用イメージを具体化しながら議論します。各課題を以下のような対応に分類します。

  • システム的に対応するもの
    • ツールの導入やシステム構成の工夫によって対応する
    • 自動化によって対応する
  • 運用で対応するもの
    • 運用ルールやガバナンスで対応する
    • 組織の役割を明文化(再定義)して対応する
  • 棚上げにするもの(検討時点では諦めるもの、と言ってもいいかもしれません)
    • 検討時点では対応が難しい
    • 将来、対応を目指す

ここで大事なのは、ステップ1で仮置きしたTo-be像に重ねて検討することです。これにより、目指したいTo-be像をより具体化させながら、検討に加わるメンバー間で深く共有することができ、このあとに続くステップで行き詰まった際に原点に立ち戻ることができるようになります。アーキテクチャを検討する際にその時点では何を優先するのか、先を見据えてどのような考え方をするのか、という根拠になります。

ここまで整理すると、次のプラットフォームではどのようなアーキテクチャを目指すべきなのか、基盤としての基本コンセプトが定まってきて、関係者間で深く共有されます。これを元に、アーキテクチャを検討していきます。

ステップ3:基礎知識習得

本支援ではGoogle Cloudを活用しますので、ステップ3ではGoogle Cloudに関する基礎知識をワークショップ形式でお客様に習得して頂きます。これは次のステップで一緒にアーキテクチャを検討するために、必要最低限のGoogle Cloudに関する知識を身につけて頂くことが第一目的です。
さらに、目指すプラットフォームにおいてクラウドの利点を活かしていくためには、お客様自身で「できるようになる」ことが重要です。日々の運用に限らず、新しく何かを作るにも、お客様が自分で「できる」ということが、柔軟かつ迅速にビジネスニーズ、業務ニーズ、アプリケーションニーズに対応できるインフラストラクチャになるからです。
これらを踏まえて、本ステップでは以下のような内容をテーマに約2時間のワークショップを行います。

  • Google Cloudのリソース管理とID管理について
    • Google Cloudリソースの階層管理について(組織、フォルダー、プロジェクトの関係性)
    • Google CloudリソースとGoogleアカウントの関係について
    • IAM、サービスアカウントについて
    • Google Cloudのネットワーク基礎
  • Google Cloudにグローバルネットワークインフラ
    • VPC、サブネット、ルート
    • グローバル、リージョン、ゾーン
    • ファイアウォールポリシー
  • その他(お客様に合わせて必要な項目を追加)

お客様の要望に応じて検証用の環境もこのステップの中で準備することも可能です。

いよいよ次のステップではアーキテクチャを検討します。

ステップ4:概要設計

ここまでの各ステップで議論した課題と対応方針、To-Be像と基礎知識を踏まえて、次に目指すプラットフォームのアーキテクチャを策定します。まず大枠のアーキテクチャを定めてから、その時点で見えているニーズや、オンプレミスや他の環境から移行してくるものを踏まえてアーキテクチャを検討する進め方が一般的です。課題への対応方針の中で、システム的に対応すると分類したものをどのように実装するのかも踏まえて検討します。ここまでのステップで十分にコミュニケーションを図りTo-be像が関係者間で深く共有されていると、目指すアーキテクチャは検討しやすくなります。

ここで重要なのは、検討段階の構成を決め打ちにしないことです。迅速かつ柔軟なプラットフォームにするためには、後々の変化を前提としたアーキテクチャの検討が必要です。最低限守るべきガバナンスをシステム的に実装しつつ、可変の幅を持たせたアーキテクチャを前提に検討します。また、クラウドは日々様々なアップデートがあり、大小様々な機能が追加されて進化します。検討時点では実現できなかった構成が、将来的には実現できる可能性があります。
参考:Google Cloud リリースノート

移行計画に関しては次のステップで検討していきますが、オンプレミス環境からの移行を検討する場合、Google Cloud VMware Engineを利用することを前提としたアーキテクチャにしておくことをオススメします。移行に費やせる時間が少なくなり、Re:hostのみで移行が可能な環境が必要になるケースがあるためです。Google Cloud VMware Engineへの移行は複数の方法がありますが、仮想マシンのダウンタイムを極力少なくするためにマイグレーションを行うには、オンプレミスのvSphere環境の構成を見直す必要があるケースがあります。具体的には以下のポイントです。

  • オンプレミスのvSphere、vCenterのバージョン
  • オンプレミスの仮想スイッチ方式(vDS)
  • オンプレミス環境からGoogle Cloudへのネットワーク接続方法

これらは準備に時間がかかるため、Google Cloud VMware Engineを利用する可能性が高いのであれば、検討を開始する時点で確認しておく必要があります。

アーキテクチャが確定したら、次のステップに進みます。

ステップ5:移行

移行を検討する段階においては、一般的なプロジェクト管理同様、スケジュール(マイルストン)とリスクを考慮して移行計画を立案します。本支援ではそれらを加味して、以下の移行パターンで移行計画を協議していきます。 

※オンプレミスのvSphere環境からの移行を前提としています

  • 短期:Rehost
    • 既存のアプリケーションや仮想マシンに手を入れず、そのままクラウドに移行します
    • Google Cloud VMware Engineへの移行を想定します
  • 中期:Replatform
    • クラウドのメリットを活用して一部のワークロード、機能をマネージドサービスに移行します
    • Google Compute EngineやCloud SQLなどのサービスを想定します
  • 長期:Refactor
    • コンテナやサーバレスを活用したインフラに依存しない環境に移行します
    • Google Cloud Kubernetes EngineやCloud Runなどのサービスを想定します

お客様のオンプレミス環境、仮想マシンの台数、ステークホルダー、そしてスケジュール(マイルストン)とリスクを踏まえて上記の移行パターンに照らし合わせます。さらに、前段のステップまでで検討してきた内容を踏まえることで、お客様に最適な移行計画を完成させることが本支援のゴールです。
実際の移行に向けた支援もご提供しております。ぜひお気軽にご相談ください。

まとめ

本コラムが、これからクラウド移行を検討するお客様、クラウド移行を実施しているがなかなか思うようにいかないお客様、クラウド移行後の運用で課題を感じているお客様のヒントになれば幸いです。
多様化する時代に迅速かつ柔軟に対応可能なインフラストラクチャを実現していくために、ぜひ、本Infrastructure Modernization支援をご活用ください。

Infrastructure Modernization支援についてはこちらまでお問い合わせください
富士ソフトのGoogle Cloud関連サービスについてはこちら

この記事の執筆者

清水 歩Ayumu Shimizu

ソリューション事業本部
インフラ事業部
インフライノベーション部
部長

Google Cloud