オンプレで管理しているサービスをGCPへシフトする際に検討するべき項目について


こんにちは。株式会社レスキューナウ システム部の坂本です。
レスキューナウで新規プロダクトの開発など行なっておりますが、
既存サービスのクラウド化と言った案件にもアーキテクチャレビューとして入る事もあります。

そこで今回はGoogle Cloudにおけるクラウド化についてコンピューティングサービスの選定基準について記載しようと思います。

最初に既存サービスのクラウド化にあたって確認するべき内容ですが以下の三つになります。

既存サービスの可能な抽象化レベルについて

抽象化レベルとはプロダクトをどこまで細分化できるのかといった意味合いとなります。
ここで言う細分化というのは単体で稼働し、システムテストが実施可能な粒度で考えてください。
「アプリケーション」>「コンテナ」>「コード」
3単位がクラウド上でコンピューティングサービスを選定する際に意識するべき内容となります。
基本的に粒度が細かければ細かいほどクラウドネイティブな構成となりますが、細かくなればなるほどインスタンスが増える傾向にあります。

技術要件について


Google Cloudではいくつかコンピューティングサービスがあります。
クラウド化と言った面からオンプレとの連携などのサービスは省きますと、
Google Cloudサービス内で完結するコンピューティングサービスは6つあります。
各サービス得意不得意があるため、使用するサービスは目的にあわせて選定する必要があります。

Cloud Run

コンテナをサーバレスで提供するマネージドコンピューティングプラットフォーム。
リクエストまたはイベント経由で稼働するコンテナを実行可能でマネージドであるためスケーリングを含めて一切インフラ設定をせずとも実行可能であることが特徴となります。 また、1コンテナ1インスタンスと言った割り当てで稼働しているためモニタリングがシンプルに行えることもメリットとなります。
デメリットとしてはインスタンスリソースとしてストレージリソースの定義ができない事とマネージドサービスのためインスタンスが落ちた際にメモリ上のデータなどもリセットとなります。 データをローカルストレージに保管して運用するアプリケーションでは活用が厳しいと言った面があります。

Cloud Function

関数/クラス単位で実行可能なマネージドコンピューティングプラットフォーム
リクエストまたはイベント経由で関数を呼び出すサービスとなっており、インフラの設定などが必要なく なおかつ一番粒度の細かいサービスとなっているため小規模な処理の提供に向いております。
Cloud Functionで構成したアプリケーションは設計の優劣に関わらず疎結合な構成となる点が特徴となります。
デメリットとしてはサーバレスであるためCloud Runと同じデメリットを持っていることと、 関数毎にリソースを分離するため大規模なアプリケーションを構築しようとした場合、管理/運用が煩雑になる可能性がある点です。

Google App Engine

Google Cloud初のサーバレスマネージドサービスです。
「スタンダード環境」「フレキシブル環境」の二つの起動モードが用意されており、 スタンダード環境の場合最低限の言語設定の記述のみでアプリケーションサーバーを起動可能でありコンテナも必要ありません。
フレキシブル環境の場合、コンテナとインフラ設定を行うことでアプリケーションサーバの構築が可能になります。
また、サーバレスですがメモリをストレージとして使用すると言った運用も可能なサービスとなっています。
スタンダード環境のデメリットは使用できる言語に制限がある点となります。
また、独自のインフラ構成yamlの記載が必要といった点でアプリケーションがApp Engine以外に流用ができないといった束縛もあります。
フレキシブル環境の場合、言語制限はありませんがyamlの束縛とは別でコンテナを用意する必要があります。
そのためインフラの構成を自分で最適化した上で運用しなくてはならないため、インフラパフォーマンスに担保がない点が挙げられます。
上に書いたメリットを享受したい場合を除き、Cloud Runと比較した場合最近は採用されるケースは多くありません。

Google Compute Engine

Google Cloudで最も自由度の高いコンピューティングサービスです。 CPU や OS などを組み合わせることで、柔軟な環境を作り上げることができるコンピューティングです。
OS は Debian や Windows など、様々な選択肢から選ぶことができ、バージョンも数多くのものを取り揃えています。 また、 OS だけではなく CPU や ディスクなども豊富な選択肢が用意されており、要件に合わせた希望通りの環境を構築可能です。 実態としてはVMに近いものとなります。 デメリットとしてはインフラの構成自由度が高すぎるためにオンプレでのVM構築と同等の手間がかかるといった点があります。

VMware Engine

クラウド上で VMware vSphere 環境を実行するためのソリューションです。 VMware をベースとした既存アプリケーションについて、リファクタリングや書き換えを行うことなくシームレスにクラウド化できます。
こちらのデメリットもCompute Engineと同様です。

Google Kubenetes

Kubernetes 環境を利用するためのコンピューティングです。 Kubernetes とは、オープンソースのコンテナーオーケストレーションツールであり、コンテナを動かすためのデファクトスタンダードになっているシステムです。
インスタンスリソースからコンテナの使用リソース、負荷分散からネットワークまで管理することができるためコンテナを用いた大規模なアプリケーション開発の場合に向いています。
デメリットとしてはkubenetes特有の概念の学習コストやpod内での操作などの特定リソースへの操作が煩雑になる点が挙げられます。
基本的には手動でコンテナ操作をするといった開発手法が取りずらいものとなっております。

料金モデルについて

各リソース毎に料金形態が変わります。
インフラを構成する上で料金は外せないため料金表や料金計算ツールを使用して実際の運用費用を事前に検討する必要があります。
料金についてはgoogleの以下の公式ページから確認することが可能です。

料金計算ツールについては以下になります。
https://cloud.google.com/products/calculator?hl=ja

まとめ

上記の内容から特徴を表にすると以下のようになります。

*月額課金については24時間稼働している前提で記載しています。

今回ご紹介した内容はコンピューティングサービスのみの検討になりますので、実際のクラウド化といった点ではセキュリティ要件やサービスレベル、ネットワーク制限などの要件も出てくると思います。そういった点でアプリケーション毎に検討する必要があるため自社のサービスについて詳細な理解が必要となります。

最後に

現在、レスキューナウでは、災害情報の提供、災害情報を活用した安否確認サービスなどのWebサービスの開発エンジニアを募集しています!
社員・フリーランスに関わらず、参画後に安心してご活躍できることを目指し、応募された方の特性・ご希望にマッチしたチームをご紹介します。
ちょっと話を聞いてみたい、ぜひ応募したい、など、当社にご興味を持っていただけましたら、お気軽にエントリーください!!