Google Cloud:クラウド移行の種類と特徴について

オンプレミスからクラウドへの移行

クラウドファーストなどと言われる今日、オンプレミスのみの運用からクラウドを活用した運用に切り替えようとする企業も多いでしょう。

世間的にもオンプレのみでの開発/運用をしている企業はあまりいないのではないでしょうか。（もちろん業種や所持しているサービスなどによりますが）

ただ、昔から自社で全てを賄っている企業様については、クラウドを使用することで現れるリスクなどを懸念している場合も少なくないかと思います。

今回は、オンプレミスからクラウドへの移行方法についてアウトプットしていきます。あくまでも座学的な知識での解説になりますので、ご容赦ください。

なお、今回の内容は下記2つを参考にお伝えします。

エンタープライズのためのGoogle Cloud（書籍）
Google Cloud への移行: 移行パスの選択（公式HP）

移行の種類

それぞれ企業の意向でどの程度クラウドを活用したいか、などにより選定も変わってきます。
1~4と数字が若いほど移行による変更や最適化が小さくなります。（リフト＆シフトの方が簡単に移行できる）
次からはそれぞれの特徴について解説していきます。

↓この後解説する全体的なイメージです。

リフト&シフト

おそらく、とりあえずクラウドを使用したい、というときに選ぶのがこのリフト&シフトです。
ただ、クラウドのメリットを享受するという点では1番小さくなってしまうため、移行計画を立てる段階でそれを理解して進めましょう。

いわゆるIaaSという仮想OSより上を管理する必要のある種別になり、Google CloudではBare Metal SolutionやVMware Engineなどが該当します。（それぞれについてはリンクから詳細をご確認ください。）

イメージでいうと、物理サーバーなどのインフラストラクチャをクラウドに置き換えて、アプリケーションやプログラムなどの根本的なサービスに繋がるソリューションについては変更を加えない、といった具合です。
よって、ラックとサーバー周りの予算が削減できるといったものが最大のメリットになるでしょう。

また、クラウドに移行することでBig Queryなどのデータ分析基盤との連携もしやすくなるといったメリットも存在します。

具体的なメリット

リフト＆シフトイメージ図

リフト&最適化

リフト&シフトよりもう１段階クラウドの利点を活用出来るようになるのがこちらのリフト&最適化です。
使用するリソースの代表としてはCompute Engineなどになります。

アプリケーション自体は変更せずに、実行するプラットフォームを変更するという形を取ります。よって、データベースをCloud SQLなどのマネージドサービスに移行する事も最適化に入ります。

リフト&シフトよりもクラウド業者により広い範囲のインフラストラクチャを任せられるので、変更作業を少なくかつクラウドのメリットが享受できる最初のクラウド移行としては選ばれる事も多そうです。

具体的なメリット

リフト＆最適化のイメージ図

改良

アプリケーションそのものの機能は変更させることはなく、レガシーアプリケーションをクラウドネイティブに書き換えます。

PaaSサービスであるApp EngineやGKE、Cloud Functionsを使用できるようにすることで、よりクラウドを活用する環境を構築していきます。

具体的なメリットについてはリフト&最適化で紹介したメリットのレベルがぐんっと上がるようなイメージです。（コストメリット、可用性、セキュリティ...etc）

ただ、冒頭で紹介した通り移行の難易度が高くなり、その分の初期コストが増加します。本書では、「レガシーアプリケーションとネイティブアプリケーションの差異を埋めるアプローチが必要」と紹介されています。

改良を選択する理由

では、どのような時に改良を選択するのか？

解説してきた順番の通り、リフト＆最適化と次に紹介する再構築の中間を取れるのがメリットですが、60%~80%のクラウド化といったイメージでしょうか。

再構築

次は最もクラウドネイティブに環境を移行する再構築です。
既存のアプリケーションを廃止して、同等のアプリケーションをクラウドネイティブとして生まれ変わらせる移行となります。

よって、よりクラウドに移行した時のメリットをしっかりと受けさせてもらいます！といった感じです。
ただ、前述してきた通り移行コストと既存のオンプレミスにあるリソースの移行に伴う制約がつきまとうので、簡単ではありません。

改良との違い

じゃ何が改良と違うの？？、と疑問に思うかもしれません。

まとめると、クラウド移行に対応するために一部のコード変更という作業で対応する、というのが改良、サービス自体の用件定義まで遡り、サービス自体の質やレベルを上げるための変更が再構築といった具合の違いでしょか。

移行以外にかかるコスト

さらに、そのクラウド（今回はGoogle Cloud）の知識と幅広い実務経験を要した人材がいなければならず、育成コストや必要であれば採用コストも追加されます。

また、クラウドで主要なシステムやアプリサービスをほぼ100%運用するとなるとサポートサービスにもお金を払わないと運用はかなり難しくなります。
実際にGoogle Cloudにはカスタマーケアという3種類の有料サポートが存在します。

再構築は、移行以外のコストもかさむため、場合によってはメリットのみではないかもしれません。
ただ、オンプレミスで管理する、サーバー/サービス周りの環境（場所、メンテナンス、人員、減価償却費...etc）はほぼ無くなるので、企業によって享受できるメリットは変わってきます。

少しシビアな言い方をすると、「今後もクラウドで長く運用し続けられ、利益を伸ばしていけるサービス」が前提になるかなと思いました。

再構築を選択する理由

では、最後にどのような時に再構築を選択するのか？下記にまとめます。

再構築する際の移行には時間がかることが多いため、徐々に移行するにしても計画の策定や期限を考慮しなければなりません。

まとめ

今回は、エンタープライズのためのGoogle Cloud（書籍）の内容を参考にクラウド移行の種類と特徴を解説しました。
個人的に感じたことは、必ずしも100%クラウドへ移行することが正解ではない、ということです。

その企業で運用しているサービスやサーバーの種類にもよりますし、例えばMySQLやPostgreSQLを使用しているDBであれば、簡単にマネージドサービスであるCloud SQLに移行し、それによりクラウドネイティブなDBを構築出来ますが、Oracleを使用している場合はベアメタルソリューションを選択す必要が出てきます。

この場合、Oracleのまま移行するのか？、またはMySQLやPostgreSQLに作り直してCloud SQLに移行するのか？
どちらが最適化は実際にその企業でコスト試算をしてみないとわかりません。

クラウド移行はかなり奥が深いので、今回は頭出しくらいの紹介になりましたが、オンプレミス→クラウドへの移行に伴う課題やメリットのイメージ持てたのではないでしょうか？?

最後に

前職が元パーソナルトレーナーであったため、ダイエット情報や筋トレ情報を積極的に配信したいと思っています！！IT＝脳＝運動＝体調管理⇒全ては繋がっています。

【神回：必ず痩せる方法をご紹介（食事のみの場合）】

今回は必ず痩せる方法をご紹介します！
ただし、かなり極端な内容なので、この方法を基本と考え、自分なりに数字を変えて実施するというものが理想です！！
P→タンパク質のg、F→脂質のg、C→炭水化物のg（実際は糖質のgだが、まあその辺は大雑把で良いです）
また、今回の想定は一般的な会社員ですが、その辺は自身の生活に置き換えてください。
食事メニューはあくまでも例です。なるべくPFCが同じ食品やコンビニ商品に置き換えてください。
酒にもカロリーがありますので、飲む人は間食の時間帯でCの摂取は最後です。
緑黄色野菜は計算しなくて良いです（ドレッシングは別）。
ただし、キャベツなどのある程度糖質を含むものは食べ過ぎ注意（Cの摂取に置き換えるならOK）。
下記スケジュールでは、Pの摂取が朝のプロテインを含むと120gを超えてしまいますが、その辺は調整orそのままでもOK（タンパク質増えるのは許容範囲）
Cについては50g×4で200gとしているが、40gでもまあOK（数gの誤差は大雑把に考えてOK）。
基本的に低カロリーの設定のため、ふらつきやめまい、違和感がある場合にはすぐにダイエットを中止してください。（あくまでも自己責任です）

1週間実施して減らない場合は、食事の計算を見なおすor100kcal下げるを検討してください。

基本的に、基礎代謝と同じカロリーを想定しているため、もし基礎代謝がわかるなら基礎代謝と同じカロリーにして置き換えてください！！

トータルのカロリーをそれぞれの食事回数により分割しています。
PFCはその日のトータルで摂取できていれば、毎度の数値は変動して問題ないです。