PHP 5 はサポートが終了しており、2026 年 1 月 31 日に
非推奨になります。非推奨になると、過去に組織のポリシーを使用して以前のランタイムのデプロイを再度有効にしていた場合でも、PHP 5 アプリケーションをデプロイできなくなります。既存の PHP 5 アプリケーションは、
非推奨になる日付以降も引き続き実行され、トラフィックを受信します。
サポートされている最新バージョンの PHP に移行することをおすすめします。
モノリシック アプリからマイクロサービスへの移行
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
以前のモノリシック アプリケーションから始める場合、切り分けて、別のマイクロサービスに移行できる部分を見つける必要があります。多くの場合、適切に構成されたモノリシック アプリは非常に自然に区分され、サービスクラスはデータ ストレージおよびビジネス ロジックのレイヤへのインターフェースとしてすぐに機能します。このようなクラスは、クライアントの呼び出しをマイクロサービスに接続する場所として理想的です。
モノリシック アプリでの機能の分離
アプリをどのように分割するかについては、次のように、いくつかのアプローチをとることができます。
- アプリケーション内で分離できるビジネス ロジックを探します。
- 静的コード解析ツールを使用してセクションを特定するなどの手法で、自然に分離されているコードを見つけます。
- アプリケーション内の他の部分とは異なるスケーリング構成設定やメモリ要件を使用するメリットがあると考えられるロジックを探します。これにより、コストが削減され、リソース利用率が向上することがあります。
不自然な依存関係を取り除くため、コードのリファクタリングが必要になることがあります。アプリを別個のサービスに分割する前に、従来のコードでリファクタリングを実行し、本番環境にデプロイしてみることをおすすめします。
マイクロサービスの共通部分には次のようなものがあります。
- ユーザーまたはアカウント情報
- 承認およびセッション管理
- 設定または構成設定
- 通知および通信サービス
- 写真とメディア(特にメタデータ)
- タスクキュー ワーカー
アプリの移行手順
一連のクラスがマイクロサービスの候補として特定されたら、次の手順を実施します。
- ロールバックを容易にするため、既存のコードはそのままにし、以前のアプリケーションで運用できる状態にしておきます。
- 新しいコード リポジトリを作成するか、既存のリポジトリに 1 つ以上のサブディレクトリを作成します。
- クラスを新しい場所にコピーします。
- HTTP API フックを提供し、レスポンス ドキュメントを正しい方法でフォーマットするビューレイヤを記述します。
- 新しいコードを別のアプリケーションとして定式化します(
app.yaml
を作成する)。
- 新しいマイクロサービスをサービスまたは別のプロジェクトとしてデプロイします。
- コードをテストして、正しく機能することを確認します。
- 以前のアプリケーションから新しいマイクロサービスにデータを移行します。後述の説明をご覧ください。
- 新しいマイクロサービス アプリケーションを使用するように以前のアプリケーションを変更します。
- 変更した以前のアプリケーションをデプロイします。
- すべてが想定どおりに動作し、以前のアプリケーションにロールバックする必要がないことを確認します。
- 不要になったコードを以前のアプリケーションから削除します。
ライブ アプリケーションでのデータ移行
ライブ アプリケーションでのデータ移行には注意が必要で、ユーザーの状況に大きく依存します。多くの場合、ロールフォワードとロールバックを容易にするため、以前の Cloud Datastore エンティティと新しい Cloud Datastore エンティティの両方に値を入力するコードを記述し(マイクロサービスでテンポラリ API を使用して実行できる場合があります)、その後、既存のデータセットを MapReduce などとして移行するコードを記述する必要があります。一般的に、このプロセスには一定量のテンポラリ コードと冗長データが含まれます。状況の詳細によっては、リリース後にキャッチアップのためのデータ移行も実行しなければならない可能性があります。新しいデータを古いデータで上書きしないように注意してください。
大変な作業であるように感じられるかと思いますが、これは普通のことであり、新しいマイクロサービスへのカットオーバーが失敗した場合にロールフォワードおよびロールバックを実行できるようにしておくことが重要です。すべてが正しく移行され、すべてが想定どおりに動作することを確認して初めて、テンポラリ コードを削除したり、古い保存場所からデータを削除したりすることができます。途中で必ずバックアップを作成してください。
次のステップ
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-09-04 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eWhen transitioning from a monolithic application to microservices, identify and separate logical business units, naturally isolated code, or parts that require different scaling configurations.\u003c/p\u003e\n"],["\u003cp\u003eRefactor legacy code within the monolithic application and deploy those changes before extracting it into microservices to ensure a smoother transition.\u003c/p\u003e\n"],["\u003cp\u003eCommon microservice candidates include user data, authorization, preferences, notifications, media, and task queues, as these often represent independent functionalities.\u003c/p\u003e\n"],["\u003cp\u003eThe microservice migration process involves leaving existing code operational, creating a new code repository, developing an HTTP API layer, and subsequently testing and deploying the microservice.\u003c/p\u003e\n"],["\u003cp\u003eMigrating data in a live environment requires populating both old and new data storage simultaneously, often with temporary code and data redundancy, to enable both roll-forward and rollback capabilities.\u003c/p\u003e\n"]]],[],null,["# Migrating to Microservices from a Monolithic App\n\nWhen starting with a legacy, monolithic application, you must find parts that\ncan be carved off and moved to separate microservices. Often, a well-structured\nmonolithic app will have very natural divisions, and a service class will\nalready function as an interface to a layer of data storage and business logic.\nSuch classes are the ideal place to connect the client calls to the\nmicroservice.\n\nSeparating functionality in a monolithic app\n--------------------------------------------\n\nYou could take a couple approaches for how you separate your app:\n\n- Look for business logic in your application that can be separated.\n- Find code that is naturally isolated, such as by using static code analysis tools to identify the sections.\n- Examine your application for logic that you might benefit from different scaling configuration settings or memory requirements than the rest of your application. This could possibly result in cost savings that might lead to better resource utilization.\n\nYou might need to refactor your code to remove unnatural dependencies. We\nrecommend that you perform refactoring within your legacy code and deploy it to\nproduction before attempting to separate the app into separate services.\n\nCommon areas for microservices include the following:\n\n- User or account information\n- Authorization and session management\n- Preferences or configuration settings\n- Notifications and communications services\n- Photos and media, especially metadata\n- Task queue workers\n\nSteps for Migrating an App\n--------------------------\n\nAfter a set of classes has been identified as a candidate to become a\nmicroservice, the next steps include:\n\n- Leaving the existing code in place and operational in the legacy application to facilitate rollback.\n- Creating a new code repository, or at least a sub-directory in your existing repository.\n- Copying the classes into the new location.\n- Writing a view layer that provides the HTTP API hooks and formats the response documents in the correct manner.\n- Formulating the new code as a separate application (create an `app.yaml`).\n- Deploying your new microservice as a service or separate project.\n- Testing the code to ensure that it is functioning correctly.\n- Migrating the data from the legacy app to the new microservice. See below for a discussion.\n- Altering your existing legacy application to use the new microservices application.\n- Deploying the altered legacy application\n- Verifying that everything works as expected and that you don't need to roll back to the legacy application.\n- Removing any dead code from the legacy application.\n\nMigrating data on a live application\n------------------------------------\n\nData migration on a live application can be tricky and highly dependent on your\nsituation. Often, to facilitate roll-forward and rollback, you will need to\nwrite code that populates both the old and new Cloud Datastore entities,\npossibly by using a temporary API on the microservice, and then write code that\nmigrates\nthe existing set of data, for example as a MapReduce. This process will usually\ninvolve some amount of temporary code and redundant data. Depending on the\nspecifics of your situation, you may also need to execute a catch-up data\nmigration after you release. Be careful not to overwrite newer data with older\ndata.\n\nWhile this seems like a lot of work, it's a common occurrence and is important\nto allow for rolling forward and rolling back in the event that the cutover to\nthe new microservice does not succeed. You can remove your temporary code and\ndelete the data from the old storage location only after you have verified that\neverything is migrated correctly and everything is operating as expected. Be\nsure to make backups along the way.\n\nWhat's next\n-----------\n\n- Get an overview of [microservice architecture on App Engine](/appengine/docs/legacy/standard/php/microservices-on-app-engine).\n- Understand how to [create and name dev, test, qa, staging, and production environments with microservices in App Engine](/appengine/docs/legacy/standard/php/creating-separate-dev-environments).\n- Learn the [best practices for designing APIs to communicate between microservices](/appengine/docs/legacy/standard/php/designing-microservice-api).\n- Learn the [best practices for microservice performance](/appengine/docs/legacy/standard/php/microservice-performance)."]]