Java 8은 지원이 종료되었으며 2026년 1월 31일에
지원 중단됩니다. 지원 중단 후에는 조직에서 이전에 조직 정책을 사용하여 레거시 런타임의 배포를 다시 사용 설정한 경우에도 Java 8 애플리케이션을 배포할 수 없습니다. 기존 Java 8 애플리케이션은
지원 중단 날짜 이후에도 계속 실행되고 트래픽을 수신합니다.
지원되는 최신 Java 버전으로 마이그레이션하는 것이 좋습니다.
모놀리식 앱에서 마이크로 서비스로 이전
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이전 모놀리식 애플리케이션으로 시작할 때는 따로 떼어내서 별도의 마이크로서비스로 이동할 수 있는 부분을 찾아야 합니다. 대개 체계적인 모놀리식 앱은 그 구성요소가 매우 자연스럽게 나누어져 있으며, 서비스 클래스가 데이터 저장소 및 비즈니스 로직의 레이어를 위한 인터페이스 역할을 이미 하고 있습니다.
이러한 클래스는 클라이언트 호출을 마이크로 서비스에 연결하기에 이상적인 곳입니다.
모놀리식 앱에서 기능 분리
다음과 같은 몇 가지 방법으로 앱을 분리할 수 있습니다.
- 애플리케이션에서 분리할 수 있는 비즈니스 로직을 찾습니다.
- 정적 코드 분석 도구를 사용하여 섹션을 식별하는 등의 방법으로 자연스럽게 격리되는 코드를 찾습니다.
- 애플리케이션의 나머지 부분과 다른 확장 구성 설정이나 메모리 요구사항을 적용할 때 유용하게 활용할 수 있는 로직을 애플리케이션에서 찾습니다. 이를 통해 비용을 절감하여 리소스 사용률을 향상시킬 수 있습니다.
부자연스러운 종속 항목을 삭제하기 위해 코드를 리팩터링해야 할 수 있습니다. 이전 코드 내에서 리팩토링을 수행하고 프로덕션 환경에 배포한 후에 앱을 별도의 서비스로 분리하려고 시도하는 것이 좋습니다.
마이크로 서비스의 일반적인 영역은 다음과 같습니다.
- 사용자 또는 계정 정보
- 승인 및 세션 관리
- 환경설정 또는 구성 설정
- 알림 및 통신 서비스
- 사진 및 미디어, 특히 메타데이터
- 작업 대기열 작업자
앱 이전 절차
마이크로 서비스에 적합한 클래스 집합을 식별한 후 다음 단계를 수행합니다.
- 롤백이 용이하도록 이전 애플리케이션에 기존 코드를 제자리에 작동 상태로 둡니다.
- 새 코드 저장소를 만들거나, 최소한 기존 저장소에 하위 디렉토리를 만듭니다.
- 클래스를 새 위치에 복사합니다.
- HTTP API 후크를 제공하고 응답 문서의 형식을 올바르게 지정하는 뷰 레이어를 작성합니다.
- 새 코드를 별도의 애플리케이션으로 작성합니다(
app.yaml
만들기).
- 새 마이크로서비스를 서비스 또는 별도의 프로젝트로 배포합니다.
- 코드가 올바르게 작동하는지 테스트합니다.
- 데이터를 기존 앱에서 새 마이크로 서비스로 이전합니다. 관련 설명은 아래를 참조하세요.
- 새 마이크로 서비스 애플리케이션을 사용하도록 기존의 이전 애플리케이션을 변경합니다.
- 변경된 이전 애플리케이션을 배포합니다.
- 모든 것이 예상대로 작동하고 이전 애플리케이션으로 롤백할 필요가 없는지 확인합니다.
- 이전 애플리케이션에서 모든 불필요한 코드를 삭제합니다.
실시간 애플리케이션에서 데이터 이전
실시간 애플리케이션에서의 데이터 이전은 까다로울 수 있으며 상황의 영향을 크게 받습니다. 대개 롤포워드 및 롤백을 용이하게 하기 위해 마이크로 서비스에서 임시 API를 사용하는 식으로 이전 및 새 Cloud Datastore 항목을 모두 채우는 코드를 작성한 다음 기존 데이터 세트를 이전하는 코드를 MapReduce 등으로 작성해야 합니다. 일반적으로 이 프로세스에는 어느 정도의 임시 코드와 중복 데이터가 사용됩니다. 구체적인 상황에 따라 출시 후에 후속 데이터 이전 작업을 수행해야 할 수도 있습니다. 최신 데이터를 이전 데이터로 덮어쓰지 않도록 주의하세요.
해야 할 작업이 많은 것처럼 보일 수 있지만 이것은 흔한 일이며, 새로운 마이크로 서비스로의 단독형 이전이 성공하지 못할 경우 롤포워드 및 롤백이 가능하도록 하는 데 있어서 중요합니다. 모든 것이 올바르게 이전되어 예상대로 작동하는지 확인한 후에만 임시 코드를 삭제하고 이전 저장소 위치에 있는 데이터를 삭제할 수 있습니다. 도중에 반드시 백업을 만드세요.
다음 단계
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 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 information, authorization, preferences, notifications, media, and task queue workers.\u003c/p\u003e\n"],["\u003cp\u003eMigrating to microservices involves leaving original code operational, creating new code repositories, formulating a separate application, deploying, testing, migrating data, and updating the legacy app to use the new microservice.\u003c/p\u003e\n"],["\u003cp\u003eData migration for live applications often requires temporarily populating both old and new data stores to facilitate rollback, along with potential catch-up migrations, and ensuring backups are made during the transition.\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/java/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/java/creating-separate-dev-environments).\n- Learn the [best practices for designing APIs to communicate between microservices](/appengine/docs/legacy/standard/java/designing-microservice-api).\n- Learn the [best practices for microservice performance](/appengine/docs/legacy/standard/java/microservice-performance)."]]