2 層ウェブ アプリケーションの Google Cloud への移行

この記事では、2 層ウェブ アプリケーションのクラウドへの移行に関して内部評価を行っている組織向けの Google Cloud Platform のオプションをご紹介します。

アプリケーションの種類

2 層ウェブ アプリケーションは、アプリケーションを実行するウェブサーバーと、アプリケーション データを保存するデータベースで構成されています。LAMP スタックと呼ばれる Linux、Apache、MySQL、PHP の実行は、2 層ウェブ アプリケーションの一般的な例です。Linux ディストリビューション、ウェブサーバー ソフトウェア、データベース、プログラミング言語のバリエーションは、すべての移行の詳細な技術情報に影響しますが、移行の概要と手順は一貫しています。

移行の各フェーズ

クラウドへの移行は、次の 4 つの段階を踏んで行われます。

評価

ワークロードのすべての特性を特定し、クラウドでワークロードを実行するために必要なリソースをリストし、すべての重要な依存関係と他のワークロードへの接続を把握します。特性のリストをすべて使用すると、どのアプリケーションとワークロードをどのような順序で移行すべきかを計画できます。

社内で利用されているアプリケーションは 1 種類ではありません。お客様が直接アクセスできるアプリもあれば、バックオフィスのアプリ、デベロッパー用のツール、試験運用中のアプリケーションもあります。これらのアプリケーションをすべて同時に移行することは、リスクがあって効率的ではありません。

一例として、アプリケーションを次の 3 つのグループに大きく分類します。

  • 簡単に移行できるアプリケーション。たとえば、依存度の低いアプリケーション、社内で最近作成したライセンス不要なアプリケーション、スケーリングやクラウド パターンに対する耐性の高いアプリケーションなどが該当します。
  • 移行が難しいアプリケーション。依存度が高く、スケーリングに対する耐性が低く、クラウド サービスでの実行が困難であり、ライセンス要件が複雑なアプリケーションが該当します。
  • 移行できないアプリケーション。特殊なハードウェアや古いハードウェアを必要とするアプリケーション、ビジネス上の要件や法規制が厳しくデータセンターに残す必要があるアプリケーション、ライセンスの関係でクラウドに移行できないアプリケーションなどが該当します。

上記は、アプリケーションを分類する一部の例です。アプリケーションには、すべてのアプリケーションの優先順位付けマトリックスを作成するために使用できる判断基準も多くあります。そのランキングから、移行する最初のアプリケーションを選択すると、Google Cloud 基盤の計画を開始できます。

基盤

具体的な詳細情報を設計および計画し、新しいクラウド環境をデプロイします。以下の内容が含まれます。

  • ワークロードにインフラストラクチャの基盤を提供するためのクラウド アーキテクチャとセキュリティ モデル。
  • アプリケーション間の安全で信頼性の高い通信を可能にするネットワーク リソース。Identity and Access Management(IAM)、Virtual Private Cloud(VPC)の設計、外部アクセス方法について広範に計画する必要があります。

  • ワークロードが実行される最終状態のテクノロジーとツール。

  • 依存関係管理、タイムライン、データ移行方法の説明。

移行

データを移行し、サービス、インフラストラクチャ、コードを目的の場所にデプロイします。自動処理とツールを使用すると、これらの操作をサポートできます。

最適化

評価フェーズと基盤フェーズで決定して仮定したことが、移行フェーズ後の実際の状況に対応しているかどうかを検証します。変更すべき事項があれば、すべて特定します。Infrastructure as a Service(IaaS)から Platform as a Service(PaaS)への移行、またはマネージド サービス パッケージの活用など、他のクラウド固有のオプションの調査についても検討してください。最適化フェーズの結果に応じて、サイクルをもう一度開始して変更や修正に対処します。常に評価段階から始めて、反復するにつれて経験を増やし、効率を高めます。

移行の種類

次のセクションでは、アプリケーションをクラウドに移行するための最も一般的な 3 つの移行戦略について説明します。

リフト&シフト

アプリケーションの機能をできるだけ変えずにアプリケーションを移行する場合は、リフト&シフトを使用します。これは、アプリケーションをすばやく移行することが優先事項である場合、ビジネス上の必要性が低く、変更の必要がない場合や、クラウド内で変更せずに実行できるアプリケーションに最適です。この移行では、インフラストラクチャおよびオペレーション担当者がサービスの基本的な変更をサポートする必要があります。コードを変更する必要がほとんどないため、開発者による作業は少なくなります。

たとえば、ウェブ アプリケーションの両方の層が VM でホストされている場合、Migrate for Compute Engine を使用してそれらをそのまま移行できます。これらの VM がクラウド上にある場合、さらなるメリットの獲得を目指して、よりクラウド ネイティブなコンピューティング プラットフォームへのアップグレードを検討できます。

改善して移行

アプリケーションをクラウドに移行する過程でアプリケーションを最新にしたい場合は、改善して移行を使用します。これは、アプリケーションがそのままの状態ではクラウドでサポートされない場合や、ソフトウェアやハードウェアの主な更新がすでに対象となり、計画されている場合によく使用されます。この移行では、インフラストラクチャ、オペレーション、デベロッパーが連携してクラウド内のアプリケーションの機能を改善する必要があります。また、アプリケーションは、ポータビリティ、スケーラビリティ、信頼性など、クラウド ネイティブである利点を活用できます。

この戦略の別のバリエーションは、改善と移行をまとめて行うことです。ウェブ アプリケーションの両方の層が VM でホストされている場合、Migrate for Anthos を使用してそれらの VM を Google Kubernetes Engine(GKE)で実行されるコンテナに自動的に移行および変換できます。

削除して置き換え

クラウドで新しいソリューションを構築したい場合は、削除して置き換えを使用し、現在のバージョンのオンプレミス ソリューションを終了します。これは、次の条件が当てはまる場合によく使用されます。

  • 既存のアプリケーションが、技術的にも経済的にもクラウドで維持する価値がない。
  • クラウドでソフトウェアのライセンスを取得することは、費用が非常に高く、非現実的である。
  • アプリケーションに業務上の必要性がみられなくなっている。

削除して置き換えではアプリケーションを一から書き直す必要があるため、この移行ガイドでは扱いません。

評価フェーズ

移行を開始する前に、出発点を十分に理解しておく必要があります。

未解決の問題があると、うまく移行できないことがあります。評価フェーズで時間を費やせば、円滑で安定した移行フェーズを実現できます。できるだけ時間をかけて、移行をサポートする関連情報をより多く取得してください。

アプリケーションのソフトウェア スタック

インフラストラクチャ、オペレーション、開発チームと協力して、次の詳細情報を特定します。

  • オペレーティング システム: 正確なディストリビューション、バージョン、パッチ、インストールされたパッケージ。
  • ウェブサーバー: 正確なソフトウェア パッケージ、バージョン番号、パッケージまたはその他のソフトウェアの修正、ウェブサーバー ソフトウェアのすべての構成ファイルとルール。
  • データベース: 正確なソフトウェア名、バージョン、スキーマ、レプリケーション戦略、バックアップ スケジュール。
  • ランタイム環境: すべてのバックエンド環境とフロントエンド環境の正確なバージョン。

システム ハードウェア リソース

ウェブサーバーとデータベースの層については、次のことを確認してください。

  • 現在いくつのサーバーが稼働していますか。
  • 世代、アーキテクチャの種類、速度なども含め、すべて合わせてどの程度の CPU が割り当てられていますか。
  • 各サーバーに割り当てられている RAM とディスクの容量はどのくらいですか。HDD または SSD を使用していますか。RAID は使用していますか。
  • CPU、RAM、ディスク スペースの、それぞれの現在の使用率、平均使用率、ピーク使用率はどれくらいですか。実際の使用環境での平均とピークを確認してください。たとえば、オリンピックをサポートしている会社は、過去 2 年分のデータについて、実際のピークを見る必要があるかもしれません。他のアプリケーションでは、稼働率はより安定しているかもしれません。最も一般的なユースケースのタイムラインと、ピーク時の最も負荷の高い使用タイムラインを見てください。また、週末、夜、就業日などの周期的な使用パターンも見てください。
  • データベースでは、どのようなバックアップ、レプリケーション、シャーディングの戦略がとられていますか。また、それによりディスク容量要件と必要なサーバー数は、どのような影響を受けますか。

ネットワーク リソース

アプリケーションを機能させるネットワーク アーキテクチャを分析します。アプリケーションをサポートするインフラストラクチャの論理および物理ネットワーク トポロジ図が、正確で最新のものになっていることを確認してください。図には、すべての接続、依存関係、ネットワーク サービスの概要が明記されている必要があります。

次のことを確認してください。

  • 顧客はどのようにしてアプリケーションにアクセスしていますか。ウェブブラウザからですか IP アドレスで直接アクセスしていますか。モバイルアプリからですか。仮想プライベート ネットワーク接続を使用していますか。
  • 利用される SSL / TLS 証明書と暗号鍵のリストをすべて持っていますか。
  • 利用される SSL / TLS 証明書はどこでホストされていますか。有効期限はいつですか。証明書はどのように更新していますか。新しい証明書をどのように入手していますか。現在の証明書すべてにアクセスできますか。
  • アプリケーションをサポートする利用可能なドメインのリストをすべて持っていますか。
  • ドメインはどこにホストされていますか。有効期限はいつですか。どのように更新していますか。登録の管理を行うアカウントにアクセスできますか。
  • DNS はどこでホストされ、管理されていますか。
  • DNS を管理するすべてのシステムとツールにアクセスできますか。各ドメインについて、現在の CNAME から IP へのマッピングはどのようになっていますか。バックアップはありますか。
  • DNS の有効期間(TTL)をどのように設定していますか。
  • ファイアウォールやその他のネットワーク アクセス制御デバイスは、アーキテクチャのどの部分に設置されていますか。どのようなルールでトラフィックを許可または拒否していますか。担当者は誰ですか。ルールの変更や更新のための手順書はありますか。
  • 外部ネットワーク サービスを利用していますか。たとえば、コンテンツ配信ネットワーク(CDN)プロバイダ、分散型サービス拒否攻撃(DDoS)保護サービスなどです。

基盤フェーズ

Google Cloud は、LAMP のような多層アプリケーションのためのコンピューティングおよびデータベース ワークロードを実行するための多くのオプションを提供します。このセクションではそれらのオプションを紹介し、どのオプションを選ぶべきかを説明します。

コンピューティング中心のオプション

Compute Engine

Compute Engine は Google Cloud 上で仮想マシン(VM)を稼働できる IaaS ソリューションです。ウェブ フレームワーク、サーバー ソフトウェア、データベース、オペレーティング システムがサポートするその他のソフトウェアをインストールできます。独自の LAMP アプリケーションをベアメタル、VM、データセンター、他のクラウド プロバイダで実行している場合、既存のサーバーをほぼ正確に複製できます。このオプションでは、オペレーティング システムの構成とウェブサーバー ソフトウェアの設定の大部分を制御できます。Compute Engine では、マシンの種類インスタンス グループストレージ オプションロードバランサなどを細かく制御できます。クイックスタートチュートリアルなどの詳細については、Compute Engine のドキュメント全体をご覧ください。

リフト&シフトで移行する際の最も一般的な方法は、アプリケーションを直接 Compute Engine に移行する方法です。オンプレミス リソースと Compute Engine のマッピングについては、Compute Engine への仮想マシンの移行に関するベスト プラクティスをご覧ください。

Cloud Deployment Manager

Google Cloud Marketplace では、Deployment Manager を介した簡単な LAMP インストールも提供されています。Debian Linux、Apache、MySQL、PHP、phpMyAdmin がすでにインストールされ、デフォルトの設定で構成されているサーバーを起動できます。ほんの数分で MySQL インストールのための、完全に機能するウェブサーバーと認証情報が入手できます。

Google Kubernetes Engine

GKE は、コンテナ化されたアプリケーションをデプロイするための、マネージド型の本番環境です。GKE を使用すると、ウェブサーバー ソフトウェアをコンテナ化することでオペレーティング システムの管理が不要になります。たとえば、Apache および NGINX ウェブサーバーが一般公開されているコンテナ リポジトリから入手できます。環境内でコンテナを使用してワークロードを実行するのであれば、GKE では LAMP ワークロードを Google Cloud に移行する際にそれまでと同様のデプロイおよびテスト ワークフローを維持できるため、効率的です。コンテナを使用しない場合は、デプロイとリカバリの高速化、リソースの使用効率の改善、基盤となるオペレーティング システムおよび VM の管理負担をなくす手段として GKE を検討してください。

コンテナ アプリケーションの大規模な管理の詳細については、GKE ドキュメントでクイックスタート、チュートリアル、コンセプト、入門ガイド、導入時の他の参考資料などをご覧ください。

オンプレミスの LAMP アプリケーションを GKE に移行するのは、改善して移行するケースにあたりますが、セルフマネージド コンテナベースのインフラストラクチャから移行するのはリフト&シフトでの移行に該当します。

App Engine

App Engine はスケーラビリティの高いアプリケーションを構築するための、サーバーレス プラットフォームです。実行するアプリケーションの種類に応じて、サーバー、コンテナ、デプロイの管理が不要になり、デベロッパーがコードの作成に集中できます。また、基盤となるインフラストラクチャの管理が容易になります。すべてのワークロードが App Engine への移行に適しているわけではありません。しかし、ワークロードによっては、スケーリングの速度と負荷のかかるアプリケーションの復元力を高めながら、費用と複雑さを軽減できる場合があります。

App Engine には、LAMP アプリケーションの PHP など、さまざまな言語に対応したスタンダード環境と、ランタイム、パフォーマンス、インフラストラクチャのカスタマイズが可能なフレキシブル環境があります。詳細については、選択した言語のドキュメントをご覧ください。

データベースのオプション

Compute Engine でのセルフマネージド

Compute Engine インスタンスでは、MySQL のインストールや、PostgreSQL、またはその他の SQL ベースのデータベースのインストールが可能です。これにより、MySQL をワークステーション上、データセンター内のサーバー上、または別のクラウド プロバイダ内の VM として実行したときと同じレベルの制御が可能になります。 データベースを VM 上で実行する場合は、フェイルオーバー、レプリケーション、パーティショニング、高可用性を構成、監視、保守する必要があります。

アプリケーションを実行するうえで十分なリソースを確保できるような CPU、RAM、ディスク領域を想定することで、データベースをコンピューティング ワークロードとして扱うことができます。

このアプローチは、コンピューティング ワークロードを Compute Engine に移行する場合と同様に、リフト&シフトで移行するケースに相当します。

Cloud SQL

Cloud SQL は、データベースのインストール、設定、メンテナンスを Google Cloud にオフロードする、フルマネージドのデータベース サービスです。バックアップ、レプリケーション、パッチ、アップデートを自動化するため、アプリケーションの作成に専念できます。Cloud SQL データベースは、Compute Engine、GKE、App Engine などの、Google のコンピューティング サービスで実行されるワークロードで使用できます。MySQL データベースを詳細に制御する必要がない限り、LAMP ワークロードを実行する手段として、Cloud SQL は設定が簡単で機能面で優れた方法になります。

Cloud SQL は、MySQL と PostgreSQL をネイティブに実行およびサポートできます。これらのデータベースの 1 つから Cloud SQL に移行する場合、リフト&シフトで移行するケースに相当します。レプリケーション、バックアップ戦略、インフラストラクチャ管理のシンプルな方法を検討している場合は、改善して移行のケースが適している可能性があります。

その他のストレージ オプション

Cloud Storage は、スケーラブル、フルマネージドのオブジェクト / blob ストアです。信頼性と費用効率が高く、イメージ、静的アセット、その他の非構造化データの保存に最適です。Cloud Storage は、静的ウェブサイトをホストするために使用できますが、アクティブなデータベース コンテンツを保存するようには設計されていません。バックアップや障害復旧のオブジェクト、ストリーミングに使用するデータを保存するのにも理想的な場所です。

移行中および移行後にデータベースのバックアップを保存する場所として Cloud Storage を使用することを検討してください。

Firestore

Firestore は、フルマネージドかつサーバーレスなクラウドネイティブ NoSQL ドキュメント データベースです。これを利用すると、モバイル、ウェブ、モノのインターネット(IoT)アプリケーションのデータを簡単にグローバル規模で保存、同期、照会できます。クライアント ライブラリの形でリアルタイム同期とオフライン サポートが提供され、さらにその充実したセキュリティ機能、Firebase および Google Cloud との統合により、真にサーバーレスなアプリの開発が促進されます。ユーザー プロフィール、プロダクト カタログ、ゲームの状態など、NoSQL の形式の場合に利便性の高いコンテンツがアプリケーションに含まれる場合は、移行の際の最適化フェーズでの Firestore の使用を検討してください。

Firebase

Firebase は、ストレージとデータベースのオプションを含む包括的なモバイル開発プラットフォームです。アプリケーションがモバイル ワークロードをサポートしている場合、最適化フェーズでの Firebase プラットフォームの使用を検討してください。

Cloud Spanner

Spanner は、グローバルに分散され、強整合性を備えたエンタープライズ クラスのクラウド専用データベース サービスです。リレーショナル データベース構造の利点と、非リレーショナル データベースの水平方向のスケーラビリティを兼ね備えています。アプリケーションで、管理性の強化、スケーラビリティ、強整合性トランザクションの導入が望ましい場合は、最適化フェーズで、データベースを Spanner に移行することを検討してください。

Google Cloud には、さまざまなワークロードをサポートする複数のストレージ オプションがあります。

移行フェーズ

評価を完了して移行を計画したら、データ、サービス、リソースを Google Cloud に移行する作業を開始できます。アプリケーションごとに独自のニーズがあります。このセクションでは、いくつかの例を紹介しながら、このフェーズの内容を説明します。

リフト&シフト: Compute Engine

リフト&シフトでの移行を開始するための最初のステップは、Compute Engine で互換性のある多層サービスを確立することです。これにはさまざまなアプローチがありますが、次の 3 つが最も一般的です。

  • 手動設定。必要なオペレーティング システムで VM を起動してから、手動でリポジトリを更新します。ソフトウェアをインストールして構成し、データベースとランタイム環境を手動でプロビジョニングして設定します。このアプローチは、概括的な制御が可能ですが、時間がかかり、エラーが発生しやすく、他の方法より再現性が低くなります。
  • 自動。Migrate for Compute Engine を使用して、VM のスタックを(指定された順序で)オンプレミスから Compute Engine の適切なサイズの自動的プロビジョニングされる構成された VM に移行します。
  • Cloud Marketplace。Google Cloud プロジェクトで事前構成された LAMP スタックを起動します。提供されているオペレーティング システムとソフトウェアのバージョンが、アプリケーションで動作することを確認してください。詳細については、Cloud Marketplace のドキュメントをご覧ください。
  • 自動デプロイ。継続的インテグレーション / 継続的デプロイメントのコンセプト、さまざまな構成管理ツール(Chef、Puppet、Ansible、Salt)、Infrastructure as Code ツール(Deployment Manager、Terraform)、自動化フレームワーク(Cloud Build)を使用して、本番環境に対応した VM を作成します。自動デプロイにより、検証可能性と再現性を備え、自動化された方法で、アプリケーションのニーズとガバナンスの要件を満たした VM およびソフトウェアがデプロイできます。

改善して移行: GKE と Cloud SQL

マネージド コンテナ ソリューションに移行するには、まず、クラスタとマネージド SQL ソリューションの基盤を確立する必要があります。

GKE クラスタの起動

GKE でクラスタを作成し、そのクラスタを管理することが最初のステップです。評価フェーズと基盤フェーズで得た情報を使用して、初期クラスタのサイズと構成を適切に設定し、セキュリティ強化のベスト プラクティスを取り入れます。

Cloud SQL 用起動オプション

評価フェーズと基盤フェーズで得られたデータベース情報を使用して、新しい Cloud SQL インスタンスを作成し、他の入門ガイドに沿ってアプリケーション用データベースを構築します。Google では、Cloud SQL のおすすめの方法高可用性設定のためのガイド、水平方向のスケーリングに関するチュートリアルのリストを提供しています。Google Kubernetes Engine から Cloud SQL 接続するためのオプションを確認し、アプリケーションの内容と経験の程度に応じたオプションを選択します。

改善して移行する(サーバーレス): App Engine と Cloud SQL

LAMP アプリケーションをサーバーレス フレームワークに移行する場合は、App Engine をサポートするようにアプリケーションを変更する必要があります。アプリケーションはそれぞれ異なり、さまざまな戦略があります。まず、次の項目を確認します。

所属組織や担当者のこれまでの経験や、サーバーレス環境でのコード実行に関する習熟度によっては、サーバーレス環境で改善して移行する場合の戦略は、リフト&シフトの場合よりも相当の時間がかかる可能性があります。ただし、サーバーレスを最大限に活用することは、組織にとって大きな資産となる可能性があります。

最適化フェーズ

アプリケーションを Google Cloud 上で実行している場合、前の 3 つのフェーズで想定して決定した内容の検証が可能です。完全移行には相当の時間がかかり、詳細な情報については、プロセス全体を通じて変化する場合があります。最適化フェーズでは多くの領域が対象となりますが、一般的なカテゴリもいくつかあります。

費用の最適化

オンプレミスからクラウドに移行すると、アプリケーション、サービス、インフラストラクチャに対する費用のかけ方が変わります。既存のオンプレミス サービスの評価を完了し移行した後に、最新のハードウェア、高速メモリ、新しい CPU アーキテクチャでサービスがより効率的に実行できることに気づかれるかもしれません。この場合は、VM が過剰にプロビジョニングされ、無駄に消費されている可能性があります。

Compute Engine でのプリエンプティブ VM インスタンスの使用も検討できます。想定した数のロードバランサが必要でなかったり、移行中にデータベースをクリーンアップしたりしたために、使用されていない空き領域が生じる場合があります。クラウドにおける費用やオペレーション工数の削減方法を見つけることは、専任の担当者をおくだけの効果が見込める作業です。Google Cloud では、クラウドの料金について把握するためのさまざまな費用管理ツールが用意されています。

自動化

クラウド内のコンピューティング ワークロードが適正に自動化されると、費用が削減され、より効率的になります。Deployment Manager は、シンプルなテンプレートを使用してクラウド リソースの作成および管理を行ううえで役立つように設計された Google Cloud プロダクトです。自動化の内容をカスタマイズする場合は、gcloud を使用してスクリプトを作成できます。自動化により費用面での利点が見込めますが、他にも次のような利点があります。

  • 標準プロセスと反復プロセスによりエラー率が下がる。
  • コンプライアンスやガバナンスの維持に役立つ監査証跡を保持できる。
  • アプリケーションの動作、不具合の発生要因、解決方法をより詳細に把握できる。

自動化により、アラートへの依存や手動対応時間が軽減されることで稼働時間が増加します。また、ワークフローを文書化することで技術的な負担も低下し、エンジニアがより良いプロダクト、ツール、サービスの構築に集中できるようになります。このような考え方は、サイト信頼性エンジニアリング(SRE)の中心となるものです。Google Cloud では、サイト信頼性エンジニアリングに関する無料のオンラインブックや、実用的な例とケーススタディが紹介された SRE ワークブックが用意されています。

インフラストラクチャとコードの分離

アプリケーションが大きくなるにつれて、サービスを分離する回数が増えます。接続されたサービスを独立させ、個別に拡張する方法を把握することで、アプリケーションの可用性と信頼性が向上します。このプロセスには通常、次の 3 つのステップがあります。

  • 場所を問わず、Infrastructure as Code(IaC)として実装します。IaC と構成管理プロセスを実装することで、インフラストラクチャ全体のプロビジョニングと構成を目的とした、追跡、監査、再現の可能なビルディング ブロックが得られます。
  • 既存のサービスをマイクロサービスに分離します。Pub/Sub などのメッセージ指向のミドルウェアを使用することで、それぞれのマイクロサービス自体が障害発生ドメインとなることができます。
  • Infrastructure as a Service から Platform as a Service へとサービスを移行します。さらに Functions as a Service または Serverless as a Service へと移行を進めます。「モノリシックなコードとインフラストラクチャ」から「IaaS 環境の全体に分散されて効率的に動作するマイクロサービス」へ移行するには、多くの時間と労力を費やす必要がありますが、それに見合うだけの価値が期待できます。

パフォーマンスの調整

パフォーマンスの調整を行うことで、システムの使用率とレスポンス時間の大幅な改善が見込まれます。パフォーマンス調整の方法には、ソフトウェア構成ファイルからカーネルフラグの調整など、ワークロードによっていくつかの方法があります。LAMP アプリケーションの場合、パフォーマンスの調整は、一般的に次の 3 つのカテゴリに分類されます。

次のステップ