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

この記事では、2 層ウェブアプリケーションのクラウドへの移行に関する内部評価を実施している組織に、Google Cloud のオプションを紹介します。 ## アプリケーションの種類 2 層 Web アプリケーションは、アプリケーションを実行する Web サーバーと、アプリケーションデータを格納するデータベースで構成されます。一般に LAMP スタックと呼ばれる Linux、Apache、MySQL、および PHP の実行は、2 層 Web アプリケーションの一般的な例です。 Linux ディストリビューション、Web サーバーソフトウェア、データベース、またはプログラミング言語のバリエーションは、移行の技術的な詳細に影響しますが、移行の概要と手順は一貫しています。 ## 移行フェーズクラウドへの移行は、次の 4 つのフェーズで行われます評価ワークロードのすべての特性を特定し、クラウドでワークロードを実行するために必要なリソースを一覧表示し、すべての主要な依存関係と他のワークロードへの接続を呼び出します。次に、特性の完全なリストを使用して、どのアプリケーションとワークロードをどのような順序で移動するかの計画を開始できます。現代の企業には、顧客向けアプリからバックオフィスアプリ、開発者ツール、実験的アプリケーションまで、さまざまな種類のアプリケーションがあります。これらすべてのアプリケーションを同時に同じ方法で移動することは、危険で非効率的です。 1 つの例は、アプリケーションを次の 3 つの広範なバケットに分類することです。 - 移動しやすいアプリケーション。これらは依存関係が少なく、より新しく、内部で記述されているためライセンスに関する考慮事項がなく、クラウド設計パターンのスケーリングとサポートに対してより寛容です。 - 移動が困難なアプリケーション。これらは依存性が高く、スケーリングに対する許容度が低く、クラウドサービスでの実行が困難であり、ライセンス要件が複雑です。 - 移動できないアプリケーション。一部のアプリケーションは、特殊なハードウェアや古いハードウェアで実行するのに適していない可能性があり、データセンターに留まらなければならないビジネス要件または規制要件があるアプリケーションや、複雑なライセンス要件が必要なアプリケーションには適していません。 Â クラウドへの移行を許可しないこれらは、アプリケーションを並べ替える方法のほんの一例です。アプリケーションには、すべてのアプリケーションの優先順位付けマトリックスを作成するために使用できる、より多くの決定要因がある可能性があります。そのランキングから、移行する最初のアプリケーションを選択し、Google Cloud 基盤の計画を開始できます財団新しいクラウド環境を展開するための具体的な詳細を設計および計画します。これらには以下が含まれます： - ワークロードのインフラストラクチャ基盤を提供するクラウドアーキテクチャとセキュリティモデルアプリケーション間の安全で信頼性の高い通信を可能にするネットワークリソース。これには、Identity and Access Management (IAM)、Virtual Private Cloud (VPC) 設計、および外部アクセス方法に関する広範な計画が必要です。ワークロードが実行される最終状態のテクノロジーとツール依存関係の管理、タイムライン、およびデータ移動の方法の説明移行データを移動し、サービス、インフラストラクチャ、およびコードを目的の場所にデプロイします。これらの操作をサポートするには、自動化とツールを使用する必要があります最適化評価フェーズと基盤フェーズで行った決定と仮定が、移行フェーズ後の現実と一致するかどうかを検証します。必要な変更を特定します。サービスとしてのインフラストラクチャ (IaaS) からサービスとしてのプラットフォーム (PaaS) への移行や、マネージドサービスの活用など、他のクラウドネイティブオプションを検討する方法を検討してください。最適化フェーズの結果によっては、変更や修正に対処するためにサイクルを再度開始する場合があります。常に評価段階に戻り、経験を活かして反復ごとに効率を高めます。 ## 移行の種類以下のセクションでは、アプリケーションをクラウドに移行するための最も一般的な 3 つの移行戦略について説明します。リフト＆シフト使用 *リフトアンドシフト* として変更しながらアプリケーションを移動したい場合それらがどのように機能するかをできるだけ少なくします。これは、次のアプリケーションに最適です。アプリケーションをすばやく移動する必要がある場合は、クラウド内で変更せずに実行できます。優先度が低い場合、またはビジネスにほとんど意欲がない場合や変更の必要性がある場合。これ移行には、インフラストラクチャおよび運用担当者によるより多くの作業が必要です。サービスが実行される場所の基本的な変更をサポートし、作業を減らしますコードを変更する必要があるとしてもごくわずかであるため、開発者からたとえば、Web アプリケーションの両方の層が VM でホストされている場合、Migrate to Virtual Machines を使用してそのまま移行できます。これらの VM がクラウド上にある場合は、追加の利点を得るために、よりクラウドネイティブなコンピューティングプラットフォームへのアップグレードを検討できます。改善して動く使用でアプリケーションをモダナイズしたい場合は、*改善して移動*します。それをクラウドに移行するプロセス。これは、アプリケーションの場合に一般的に使用されます。クラウドでそのままサポートされていないか、ソフトウェアまたはハードウェアはすでにスコープが設定され、計画されています。この移行にはインフラストラクチャが必要です。運用、開発者が協力して機能を改善するクラウド内のアプリケーション、およびアプリケーションが利用できるようにします移植性、スケーラビリティ、信頼性の向上など、クラウドネイティブの利点この戦略のもう 1 つのバリエーションは、1 つの動作で改善して移動することです。ウェブアプリケーションの両方の層が VM でホストされている場合、Migrate to Containers を使用して、これらの VM を自動的に移動し、Google Kubernetes Engine (GKE) で実行されるコンテナに変換できます。切り取って交換使用クラウドで新しいソリューションを構築する場合は、*総入れ替え*します。オンプレミスソリューションの現在のバージョンを廃止します。これは一般的に使用されます次の条件に該当する場合。 - 既存のアプリケーションは、技術的または財政的にクラウドで維持する価値がない - クラウドでソフトウェアのライセンスを取得することは、法外または非現実的です。 - アプリケーションがビジネスニーズを完全に満たさなくなったリップアンドリプレースではアプリケーションを一から書き直す必要があるため、この移行ガイドでは扱いません。 ## 評価段階移行を開始する前に、出発点を完全に理解する必要があります未回答の質問は、移行の成功にリスクをもたらします。評価フェーズに時間を費やすことで、スムーズで問題のない移行フェーズを確保できます。移行をサポートするために、できるだけ多くの関連情報を取得するために、できるだけ多くの時間を費やしてくださいアプリケーションソフトウェアスタックインフラストラクチャ、運用、および開発チームと協力して、次の詳細を特定します。 - オペレーティングシステム: 正確なディストリビューション、バージョン、パッチ、インストールされているパッケージ - Web サーバー: 正確なソフトウェアパッケージ、バージョン番号、パッケージまたはその他のソフトウェアの変更、および Web サーバーソフトウェアのすべての構成ファイルとルール - データベース: 正確なソフトウェア名、バージョン、スキーマ、レプリケーション戦略、およびバックアップスケジュール - ランタイム環境: すべてのバックエンドおよびフロントエンド環境の正確なバージョンシステムハードウェアリソース Web サーバー層とデータベース層については、次の質問に答えてください。 - 現在稼働しているサーバーの数は? - 世代、アーキテクチャタイプ、速度を含む CPU の合計割り当ては? - 各サーバーに割り当てられている RAM とディスク容量は? HDD または SSD は使用されていますか?レイド？ - CPU、RAM、およびディスク領域の現在の使用率、平均使用率、およびピーク使用率は?特定のビジネス用途における平均とピークを見てください。たとえば、オリンピックをサポートする企業は、真のピークがどのようなものかを確認するために 2 年前を振り返る必要があるかもしれませんが、他のアプリケーションはより安定した稼働率を持っているかもしれません。最も典型的なユースケースのタイムラインを平均的に見て、最も頻繁に使用するタイムラインをピークに見てください。週末、夕方、平日などの周期的な使用パターンも探します- データベースについて、どのバックアップ、レプリケーション、またはシャーディング戦略が使用されているか、どのようにディスク容量の要件と必要なサーバーの数に影響を与えるものは何ですか?ネットワークリソースアプリケーションの機能を可能にするネットワークアーキテクチャを分析します。アプリケーションをサポートするインフラストラクチャの正確で最新の論理および物理ネットワークトポロジダイアグラムがあることを確認します。図では、すべての接続、依存関係、およびネットワークサービスを明確に概説する必要があります次の質問に答えてください:- 顧客はどのようにアプリケーションにアクセスしますか?ウェブブラウザ経由？IPアドレスから直接？モバイルアプリ経由？仮想プライベートネットワーク接続を使用していますか?- 適用可能なすべての SSL/TLS 証明書と暗号化キーのリストはありますか?- 適用可能なすべての SSL/TLS 証明書はどこでホストされていますか?有効期限はいつですか?証明書をどのように更新しますか?新しい証明書を取得するにはどうすればよいですか?現在のすべての証明書にアクセスできますか?- アプリケーションをサポートする適用可能なすべてのドメインのリストがありますか?- これらのドメインはどこでホストされていますか?有効期限はいつですか?どうやって更新するの?登録を制御するアカウントにアクセスできますか?- DNS はどこでホストおよび管理されていますか?- DNS を制御するすべてのシステムとツールにアクセスできますか?各ドメインの現在の CNAME から IP へのマッピングは?バックアップはありますか?- DNS の存続可能時間 (TTL) の設定は?- ファイアウォールやその他のネットワークアクセスおよび制御デバイスは、アーキテクチャのどこに適合しますか?トラフィックを許可または拒否するためのルールは?誰が責任を負い、それらのルールを変更または更新する手順は?- 外部ネットワークサービスを使用していますか?たとえば、コンテンツ配信ネットワーク (CDN) プロバイダー、または分散型サービス妨害 (DDoS) 保護サービスですか?## 基盤フェーズGoogle Cloud は、LAMP のような多層アプリケーションのコンピューティングワークロードとデータベースワークロードを実行するための多くのオプションを提供します。このセクションでは、これらのオプションを紹介し、どのオプションを選択するかについて説明しますコンピューティング中心のオプションCompute EngineCompute Engine は IaaS ですGoogle Cloud で仮想マシン（VM）を実行できるサービス。Web フレームワーク、サーバーソフトウェア、データベース、およびオペレーティングシステムがサポートするその他のソフトウェアをインストールできます。ベアメタル、VM、データセンター、または別のクラウドプロバイダーで独自の LAMP アプリケーションを実行している場合、このオプションを使用すると、既存のサーバーを厳密に複製することはできません。このオプションでは、オペレーティングシステムの構成と Web サーバーソフトウェアの設定を最大限に制御できます。Compute Engine では、マシンタイプ、インスタンスグループ、ストレージオプション、ロードバランサ、その他多数の詳細を詳細に制御できます。クイックスタート、チュートリアルなどの詳細については、Compute Engine の完全なドキュメントを参照してくださいアプリケーションを Compute Engine に直接移行することは、最も一般的なリフト＆シフト移行です。オンプレミスリソースを Compute Engine にマッピングする方法については、「仮想マシンを Compute Engine に移行するためのベストプラクティス」を参照してくださいCloud Deployment ManagerGoogle Cloud Marketplace も参照してくださいは、Deployment Manager を介して簡単な LAMP インストールを提供します。Debian Linux、Apache、MySQL、PHP、および phpMyAdmin がすでにインストールされ、デフォルトのセットアップで構成されているサーバーを起動できます。MySQL をインストールするための完全に機能するウェブサーバーと資格情報をわずか数分で取得できますGoogle Kubernetes EngineGKE は、本番環境に対応したマネージド環境ですコンテナ化されたアプリケーションをデプロイするため。GKE を使用すると、ウェブサーバーソフトウェアをコンテナ化することで、オペレーティングシステムの管理を停止できます。たとえば、Apache および NGINX Web サーバーは、すべてのパブリックコンテナーリポジトリから利用できます。コンテナを使用して環境内でワークロードを実行する場合、GKE は、LAMP ワークロードを Google Cloud に移行する際に同様のデプロイとテストのワークフローを維持するための効率的なサービスです。コンテナを使用しない場合は、デプロイとリカバリを高速化し、リソースの使用効率を高め、基盤となるオペレーティングシステムと VM を管理する必要がない GKE を検討することを検討してくださいFor大規模なコンテナアプリケーション管理の詳細については、クイックスタート、チュートリアル、コンセプト、ハウツーガイド、および開始に役立つその他のリソースについて GKE ドキュメントを参照してくださいオンプレミス LAMP アプリケーションの移動GKE への移行は改善と移行の移行ですが、自己管理型のコンテナベースのインフラストラクチャからの移行はライフアンドシフトの移行ですApp EngineApp Engine はスケーラビリティの高いアプリケーションを構築するためのサーバーレスプラットフォーム。実行しているアプリケーションの種類によっては、App Engine を使用すると、サーバー、コンテナ、またはデプロイを管理する必要がなくなるため、開発者はコードの記述に集中し、基盤となるインフラストラクチャの管理の複雑さを軽減できます。すべてのワークロードが App Engine への移行に適しているわけではありませんが、スケーリングの速度と負荷がかかった状態でのアプリケーションの回復力を向上させながら、コストと複雑さを軽減できるワークロードもありますApp Engine には 2 つの種類があります。スタンダード環境はさまざまな言語 (LAMP アプリケーション用の PHP を含む) をカバーし、フレキシブル環境はランタイム、パフォーマンス、インフラストラクチャをよりカスタマイズできます。詳細については、選択した言語のドキュメントを参照してくださいデータベースオプション Compute Engine で自己管理 MySQL、PostgreSQL、またはその他の SQL ベースのデータベースを Compute Engine インスタンスにインストールできます。これにより、MySQL をワークステーション、データセンターのサーバー、または別のクラウドプロバイダーの VM として実行する場合と同じレベルの制御が提供されます。 VM でデータベースを実行する場合、フェイルオーバー、レプリケーション、パーティショニング、および高可用性を構成、監視、および維持するのはユーザーの責任です。アプリケーションを確実に実行するための十分なリソースがあることを確認するために、CPU、RAM、およびディスク容量を考慮して、データベースをコンピューティングワークロードとして扱うことができます。コンピューティングワークロードを Compute Engine に移行するのと同様に、このアプローチはリフトアンドシフト移行を表します。クラウド SQL Cloud SQL は、データベースのインストール、セットアップ、メンテナンスを Google Cloud にオフロードするフルマネージドデータベースサービスです。バックアップ、レプリケーション、パッチ、および更新を自動化し、アプリケーションに集中できるようにします。 Cloud SQL データベースは、Compute Engine、GKE、App Engine など、Google のコンピューティングサービスで実行されるワークロードで使用できます。 MySQL データベースを詳細に制御する必要がない限り、Cloud SQL はセットアップが簡単で、LAMP ワークロードを実行するためのフル機能のオプションです。 Cloud SQL は、MySQL と PostgreSQL をネイティブに実行してサポートできます。これらのデータベースのいずれかから Cloud SQL に移行する場合、これはリフト＆シフト移行です。レプリケーション、バックアップ戦略、またはインフラストラクチャ管理の簡素化のための新しい方法を検討している場合、これは改善と移行の移行になる可能性があります。その他のストレージオプション Cloud Storage は、スケーラブルで完全に管理され、信頼性が高く、コスト効率に優れたオブジェクトまたはブロブストアであり、画像、静的アセット、その他の非構造化データの保存に最適です。 Cloud Storage は静的なウェブサイトをホストするために使用できますが、アクティブなデータベースコンテンツを保存するようには設計されていません。また、バックアップとディザスタリカバリオブジェクト、およびストリーミングに使用するデータを保存する理想的な場所でもあります。移行中および移行後にデータベースのバックアップを保存する場所として Cloud Storage を使用することを検討してくださいファイアストア Firestore は、モバイル、ウェブ、モノのインターネット (IoT) アプリケーションのデータの保存、同期、クエリをグローバル規模で簡素化する、フルマネージドでサーバーレスのクラウドネイティブな NoSQL ドキュメントデータベースです。そのクライアントライブラリはライブ同期とオフラインサポートを提供し、そのセキュリティ機能と Firebase および Google Cloud との統合は、真のサーバーレスアプリの構築を加速します。アプリケーションに、ユーザープロファイル、製品カタログ、ゲームの状態など、NoSQL 形式のメリットが得られるコンテンツがある場合は、移行の最適化フェーズで Firestore を検討する必要があります。ファイアベース Firebase は、ストレージとデータベースのオプションを含む包括的なモバイル開発プラットフォームです。アプリケーションがモバイルワークロードをサポートしている場合は、最適化フェーズで Firebase プラットフォームを検討する必要があります。クラウドスパナ Spanner は、クラウド向けに構築された、グローバルに分散された強力な一貫性を備えたエンタープライズグレードのデータベースサービスです。リレーショナルデータベース構造の利点と、非リレーショナルデータベースの水平方向のスケーラビリティを組み合わせています。アプリケーションが強化された管理性、スケーラビリティ、強力な一貫性を備えたトランザクションからメリットを得られる場合は、最適化フェーズでデータベースを Spanner に移行することを検討してください。 Google Cloud は、さまざまなワークロードをサポートするために、他の多くのストレージオプションを提供しています ## 移行フェーズ評価を完了して移行を計画したら、データ、サービス、リソースを Google Cloud に移行する作業を開始できます。各アプリケーションには独自のニーズがあります。このセクションでは、このフェーズの内容を示すのに役立ついくつかの例について説明しますリフト＆シフト: Compute Engine リフト＆シフト移行を開始するための最初のステップは、Compute Engine で互換性のある多層サービスを確立することです。これには多くのアプローチがありますが。最も一般的なのは次の 3 つです。 - 手動セットアップ。必要なオペレーティングシステムで VM を起動し、リポジトリを手動で更新し、ソフトウェアをインストールして構成し、データベースとランタイム環境を手動でプロビジョニングして構成します。このアプローチは高レベルの制御を提供しますが、他の方法よりも時間がかかり、エラーが発生しやすく、再現性が低くなります。 - 自動化。 Migrate to VMs を使用して、VM のスタックを (指定された順序で) オンプレミスから Compute Engine 内の適切なサイズで自動的にプロビジョニングおよび構成された VM に移行します。 - クラウドマーケットプレイス。 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 をサポートするようにアプリケーションを変更する必要がある場合があります。すべてのアプリケーションは異なり、多くの戦略があります。以下を確認することから始めます。 - App Engine のマイクロサービスアーキテクチャの概要を理解する - App Engine でマイクロサービスを使用して開発、テスト、QA、ステージング、本番環境を作成し、名前を付ける方法を理解する - マイクロサービス間で通信するための API を設計するためのベストプラクティスを学ぶ - マイクロサービスパフォーマンスのベストプラクティスを学ぶ組織的および個人的な経験と、サーバーレスコードの実行に慣れているかどうかによっては、サーバーレスの改善と移行の戦略は、リフトアンドシフトのオプションよりも大幅に時間がかかる可能性があります。ただし、サーバーレスを最大限に活用することは、組織にとって大きな資産になる可能性があります ## 最適化フェーズアプリケーションが GCP で実行された後、前の 3 つのフェーズからの仮定と決定を検証できます。完全な移行には時間がかかる可能性があり、プロセス全体で多くの詳細が変更される可能性があります。最適化は多くの領域をカバーしますが、一般的なカテゴリをいくつか紹介しますコストの最適化オンプレミスからクラウドに移行すると、アプリケーション、サービス、およびインフラストラクチャにお金を使う方法が変わります。レガシオンプレミスサービスの評価を完了し、移行後に、最新のハードウェア、より高速なメモリ、および新しい CPU アーキテクチャがより効率的に実行されることを発見する場合があります。これは、VM が過剰にプロビジョニングされ、お金が無駄になっていることを意味している可能性があります Compute Engine でプリエンプティブル VM インスタンスを使用して調査することもできます。おそらく、思ったほど多くのロードバランサーが必要なかったか、移動中にデータベースをクリーンアップできて、使用していないスペースができたのでしょう。クラウドでお金を節約し、運用コストを削減する方法を見つけることは、元が取れるフルタイムの仕事になる可能性があります。 Google Cloud には、クラウドの料金を理解するのに役立つ多くのコスト管理ツールがありますオートメーションクラウドでコンピューティングワークロードを正しく自動化すると、コストが発生する可能性があります節約と効率のメリット展開マネージャークラウドの作成と管理を支援するために設計された Google Cloud プロダクトですシンプルなテンプレートを使用したリソーススクリプティング gcloud 独自の自動化を作成したい場合は、オプションです。金融ながら自動化には次の利点がありますが、その他の利点には次のようなものがあります。 - エラー率を下げるための標準的で反復可能なプロセス - コンプライアンスとガバナンスのための監査可能な追跡 - アプリケーションがどのように機能するか、どのように壊れるか、どのように修正するかについての理解が深まる自動化により、アラートや人間の反応時間への依存度が低下することでアップタイムが増加し、ワークフローを文書化することで技術的負債が削減され、エンジニアは光を当て続けることよりも、より優れた製品、ツール、およびサービスの構築に集中できるようになります。これらの概念は、Site Reliability Engineering (SRE) の中核です。Google Cloud では、サイト信頼性エンジニアリングに関する無料のオンラインブックと、実用的な例とケーススタディを提供する SRE ワークブックを提供していますインフラストラクチャとコードの分離アプリケーションが大きくなるにつれて、何度もサービスを分離します。接続されたサービスを分割し、それらを個別にスケーリングする方法を知ることで、アプリケーションの可用性と信頼性が向上します。このプロセスには通常 3 つのステップがあります:- コードとしてのインフラストラクチャ (IaC) をあらゆる場所に実装します。IaC と構成管理プロセスを実装することで、インフラストラクチャ全体のプロビジョニングと構成のための追跡可能、監査可能、および再現可能なビルディングブロックを取得します- 既存のサービスをマイクロサービスに分離します。Pub/Sub などのメッセージ指向のミドルウェアを使用して、すべてのマイクロサービスを独自の障害ドメインにできるようにする- Infrastructure as a Service から Platform as a Service へのサービスの移行を開始する、またはサービスとして、またはサービスとしてのサーバーレスとして機能することさえあります。「モノリシックなコードとインフラストラクチャ」から「IaaS スペクトル全体で効率的に実行される分離されたマイクロサービス」への道のりは、時間、労力、および献身を要する貴重な目標ですパフォーマンスチューニングパフォーマンスチューニングにより、システムの使用率と応答時間が大幅に向上する可能性があります。すべてのワークロードには、ソフトウェア構成ファイルからカーネルフラグのチューニングまで、さまざまなパフォーマンスチューニング方法があります。LAMP アプリケーションの場合、通常、パフォーマンスチューニングは次の 3 つのカテゴリに分類されます:- クラウド、ネットワーク、およびオペレーティングシステムのチューニング: - Google Cloud ネットワークのパフォーマンスを向上させるための 5 つのステップは、Google Cloud Networking を最大限に活用する方法を理解するのに役立ちます - 特定の TCP レイテンシ要件がある場合は、Google Cloud でのネットワークパフォーマンスの TCP 最適化が役立ちます - 永続ディスクとローカル SSD のパフォーマンスを最適化することで、IOPS の負荷の高いワークロードの設計について学ぶことができます - Compute Engine のパフォーマンスを改善すると、他の Google Cloud API やサービスとやり取りする際の API アプリケーションのパフォーマンスが向上します。 - Web サーバーのチューニング: - Apache パフォーマンスチューニングと NGINX パフォーマンスチューニング、または「Web サーバーパフォーマンスチューニング」の一般的な Google 検索が正しい方向に導きますデータベースのチューニング: ＃＃次は何ですか - Compute Engine で LAMP を設定する - LAMP スタックをデプロイする - Compute Engine または GKE でコンピューティングワークロードを実行する方法の詳細 GKE を Cloud SQL に接続する VM への移行とコンテナへの移行について調べる App Engine を使用して、フルマネージドサーバーレスプラットフォーム上で高度にスケーラブルなアプリケーションを構築する Google Cloud のデータベースオプションの詳細 Google Cloud に関するリファレンスアーキテクチャ、図、チュートリアル、ベストプラクティスをご覧ください。クラウドアーキテクチャセンターをご覧ください。

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

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