ホーム
導入事例
株式会社ビズオーシャン様

G-genと「 One Team 」でのプロジェクト進行。オンプレミスから Google Cloud (GCP) への移行で月額コスト40%削減

東銀座駅の近くにオフィスを構えて、国内最大級の書式テンプレート配布サービス「bizocean（ビズオーシャン）」の運営など、幅広く事業を展開する株式会社ビズオーシャン。

オンプレミス環境での運用からの脱却とさらなる事業成長の実現に向けて、Google Cloud (GCP) 環境へのクラウド移行を決意。本プロジェクトについて、bizocean開発部／チーフエンジニア金氏、bizocean 開発部嶋坂氏の2名にお話を伺いました。

利用している Google Cloud (GCP) サービス：GCE、負荷分散、GCS、Stackdriver Monitoring、Stackdriver logging、Cloud Armor 他、関連するサービスとして GKE、BigQuery、Cloud SQL 等

顕在化していたオンプレサーバーでの課題を Google Cloud (GCP) へのクラウド移行で解決

2019年5月時点、bizocean はオンプレサーバーを採用していましたが、同サービスが2019年9月末でサービス停止となり、新環境への移行を迫られていました。加えて、オンプレ運用において複数の課題が顕在化していたこともあり、 Google Cloud (GCP) 環境への移行を決意。bizocean 開発部プロジェクトメンバー嶋坂氏は以下のように語ります。

オンプレの物理サーバーを借りて数年間も利用していたため、ハードウェア自体が老朽化していた点、サーバー運用における管理の煩雑さが課題となっていました。例えば、ファイアウォールの制御をするためには、専用の変更申請書にIPアドレスを記載し、都度依頼する必要がありました。さらにコストも割高になっており、バックアップを取得するためには、月額サーバー料金に加えて、オプション料金が別途必要になる状態でした。このような課題を解決するため、 Google Cloud (GCP) への環境移行を本格的に進めることを決意しました。

クラウド移行を決意したものの、bizocean 開発部プロジェクトマネージャー金氏の心中には不安が残っていました。当時を思い浮かべながら、金氏はこう振り返ります。

bizocean のオンプレシステムを構築した当時の担当者が退職してしまっていたため、既存環境のサービス仕様がブラックボックス化していました。そのため、「クラウド移行後に今までの機能を漏れなく実装できるのか？」「移行した後も同じものとして使えるか？」という点を不安に感じていました。

bizoceanでは、移行先の環境として複数のクラウドサービスを比較していましたが、検討の結果、 Google Cloud (GCP) の採用を決定。自社内で利用実績があった点、既に他システムでクラウド環境の検証が完了していた点、G-gen のフォロー体制についての他部署からの評判、低コストな点などが決め手になったと言います。

サービス選定の段階では、計4つのサービスを比較検討していました。それぞれ代理店さま経由で相見積もりをして、最もコストを抑えられるサービスが Google Cloud (GCP) でした。

Google Cloud の契約が、Googleさんとの直契約の部分とG-gen さん経由の部分がありましたので、G-genさん経由に一本化することでさらに、コストの圧縮をすることに成功しました。

実は弊社内で Google Cloud (GCP) の利用実績がありました。そのため、Google Cloud (GCP) による検証が2019年の11月くらいに自社で完了していた点も Google Cloud (GCP) の採用を後押しする材料となりました。同時に G-gen さんのサポートも受けており、そのフォロー体制が社内で高い評価を得ていた点が Google Cloud を採用した一番の理由です。

サポート体制を高く評価し、数あるパートナー企業の中で G-gen に依頼

Google Cloud のパートナー企業が数多く存在する中で、 G-gen のサポート体制が契約を決定づけた要因とのこと。 Google Cloud を活用していたビズオーシャン社内の他部署が、 G-gen のサポート体制を高く評価していたそうです。

今回は「構成変更なく、かつ、システムを止めずにクラウド環境へ移行する」という点が最大の要件でした。そのため完全に自社で対応する訳にもいかず、完全に外部委託するという訳にいかずG-gen さんにご相談をさせていただきました。

具体的にサポートいただいた部分は、ネットワークやVPN、ファイヤーウォール、ロードバランサーを始めとするクラウド固有の問題で自社では深い知見を持っておらず対処できなかった箇所です。

クラウド特有の課題に直面しながらも「Lift 」でクラウド環境への移行を実現

移行作業は「 Lift 」で進めました。現行サーバーにはできるだけ手を入れたくなかったため、P2V2Cでクラウド移行することを決めました。 VMware Converter を利用して、 P2V（※1）を行い、 VMware のイメージに変換しました。その後、 VMware のイメージを VMImport することで V2C （※2）を実行しました。

クラウド化を第一優先に置き、設定も含めてすべてを環境移行したため、現在も物理サーバー時代の名残が一部残って最近それが社内で話題になりました（笑）。

Shiftはまだ実行していませんが、現在CloudSQLとCloud Filestore(NFS)の利用を計画中です。

※1：P2V（ Physical to Virtual ：オンプレミスの物理サーバー上で稼働しているシステムを仮想マシンへ移行すること）
※2：V2C（ Virtual to Cloud ：オンプレミスの VMware vSphere 上で動いている仮想サーバーをそのままクラウドへ移行すること）

当初、複数サービスを移行先として検討していましたが、他のクラウドサービスにおいて移行するに当たっての課題が顕在化し、実質的に Google Cloud (GCP) のみが選択肢に残ったそうです。

クラウドベンダーの比較の話に戻りますが、相見積もり時に、パートナー企業さんとP2V2Cでのクラウド移行について会話している中で、「物理サーバーから仮想化したものをクラウドへインポートする場合、その部分はサポートができない。新規でいちから作成するのであればサポートできる。」と伝えられました。もちろん、いちから構築するわけにはいかないので、そのサービスは選択肢から外れました。

他のクラウドが公式で提供している移行ツールもあり、そちらも検討をしていました。ただ、ファイヤウォールで許可するネットワークの幅を広くしなくてはいけないということが判明したため、こちらも選択肢から外れたという経緯がありました。