마이크로서비스 아키텍처에 대해 알아보기

현대적 애플리케이션은 독립적으로 구축되는 몇 가지 서비스를 구성하여 구축됩니다. 이를 통해 민첩성과 시장 출시 속도를 높여 문제를 해결하고 새로운 기능을 도입할 수 있습니다.

이 패러다임은 마이크로서비스 아키텍처라고 하지만, 완전한 애플리케이션을 위해 함께 제공되는 서비스의 수는 수백 개(마이크로 서비스) 또는 수십 개(매크로 서비스)에 있을 수 있습니다. 모듈리스(moduliths)라고 하는 모듈식 모놀리스(modular monoliths)에도 새로운 용어가 사용되고 있으며 스프링 모듈리스(Spring Modulith)도 이러한 예 중 하나입니다.

많은 조직이 이미 마이크로서비스 아키텍처를 보유하고 있지만, 마이크로서비스 배포는 복잡하고, 성공적인 배포는 여전히 대부분의 조직에서 진행 중입니다. 이 솔루션 플레이북은 Oracle Database를 사용하는 클라우드 인프라, 컨테이너, Kubernetes 및 Backend as a Service 플랫폼과 함께 인기 있는 Spring Boot 플랫폼으로 최신 마이크로서비스의 구축 및 배포를 간소화하려고 시도합니다.

다국어, 간편한 확장성, 유지 관리 및 배포 용이성, 고가용성, 장애 최소화 등의 애플리케이션을 설계하려는 경우 마이크로서비스 아키텍처를 사용하여 클라우드 애플리케이션을 설계 및 배포하십시오. 마이크로서비스 아키텍처에서 각 마이크로서비스는 간단한 작업을 소유하고, REST API 요청과 같은 경량 통신 메커니즘을 사용하여 클라이언트 또는 기타 마이크로서비스와 통신합니다.

다음 다이어그램은 여러 마이크로서비스로 구성된 애플리케이션의 아키텍처를 보여줍니다.

microservice_architecture.png 그림 설명

마이크로서비스를 사용하면 느슨하게 결합된 서비스의 모음으로 애플리케이션을 설계할 수 있습니다. 마이크로서비스는 공유가 필요 없는 모델을 따르며 Stateless 프로세스로 실행됩니다. 이 접근 방식을 사용하면 애플리케이션을 보다 쉽게 확장하고 유지 관리할 수 있습니다.

• API 계층은 마이크로서비스에 대한 모든 클라이언트 요청의 시작점입니다. 또한 이 API 계층을 통해 마이크로서비스는 HTTP, gRPC 및 TCP/UDP를 통해 서로 통신할 수 있습니다.
• 논리 계층은 단일 비즈니스 작업에 초점을 맞춰 다른 마이크로서비스에 대한 종속성을 최소화합니다. 이 계층은 각 마이크로서비스에 대해 다른 언어로 작성할 수 있습니다.
• 데이터 저장소 계층은 데이터베이스 저장 영역 엔진, 로그 파일 등과 같은 지속성 방식을 제공합니다. 각 마이크로서비스에 대해 별도의 영구 데이터 저장소 사용을 고려하십시오. Oracle은 마이크로서비스가 보안, HA 및 확장을 위해 데이터를 쉽게 격리할 수 있도록 여러 개의 플러거블 데이터베이스를 갖춘 데이터베이스 컨테이너를 제공합니다. 또한 SaaS 애플리케이션은 안전한 방식으로 다중 테넌시를 활용할 수 있습니다. 또한 컨버지드 데이터베이스는 데이터의 풍부한 인사이트를 얻기 위해 한 지붕 아래에 다양한 데이터를 제공합니다.

일반적으로 각 마이크로서비스는 경량 런타임 환경을 제공하는 컨테이너에서 실행됩니다.

마이크로서비스와 모놀리식 아키텍처의 차이점

마이크로서비스 아키텍처를 사용하여 애플리케이션을 설계하기 전에 이 아키텍처가 기존의 모놀리식 아키텍처와 어떻게 다른지 이해해야 합니다.

응용 프로그램 설계는 업무 요구 사항 해결 및 업무 논리 구현에 중점을 둡니다. 모놀리식 아키텍처에서 전체 애플리케이션은 모든 비즈니스 논리를 포함하는 단일 단위로 구축됩니다. 마이크로서비스 아키텍처에서 비즈니스 논리는 느슨하게 결합된 여러 서비스로 구성됩니다.

다음 그림은 모놀리식 및 마이크로서비스 아키텍처를 보여줍니다.

monolithic_vs_microservice.png 그림 설명

다음 표에는 마이크로서비스와 모놀리식 아키텍처의 차이점이 요약되어 있습니다.

특성	마이크로서비스 아키텍처	모놀리식 구조
장치 설계	응용 프로그램은 느슨하게 연결된 서비스로 구성됩니다. 각 서비스는 단일 업무 작업을 지원합니다.	전체 응용 프로그램은 단일 단위로 설계, 개발 및 배치됩니다.
기능 재사용	마이크로서비스는 모든 클라이언트에 기능을 노출하는 API를 정의합니다. 고객은 다른 응용 프로그램일 수도 있습니다.	애플리케이션 전반에서 기능을 재사용할 수 있는 기회는 제한적입니다.
응용 프로그램 내의 통신	응용 프로그램의 마이크로서비스는 서로 통신하기 위해 요청-응답 통신 모델을 사용합니다. 일반적인 구현에서는 HTTP 프로토콜을 기반으로 하는 REST API 호출을 사용합니다.	내부 프로시저(함수 호출)는 응용 프로그램의 구성 요소 간 통신을 용이하게 합니다. 내부 프로시저 호출의 수를 제한할 필요가 없습니다.
기술 유연성	각 마이크로서비스는 마이크로서비스가 해결하도록 설계된 문제에 가장 적합한 프로그래밍 언어와 프레임워크를 사용하여 개발할 수 있습니다.	일반적으로 전체 응용 프로그램은 단일 프로그래밍 언어로 작성됩니다.
데이터 관리	분산: 각 마이크로서비스는 자체 데이터베이스를 사용할 수 있습니다.	중앙 집중화: 전체 응용 프로그램이 하나 이상의 데이터베이스를 사용합니다.
배치	각 마이크로서비스는 애플리케이션의 다른 마이크로서비스에 영향을 주지 않고 독립적으로 배포됩니다.	작은 변화라도 전체 응용 프로그램을 재배치하고 재시작해야 합니다.
유지 관리 가능성	마이크로서비스는 단순하고, 집중적이며, 독립적입니다. 따라서 응용 프로그램을 유지 관리하는 것이 더 쉽습니다.	응용 프로그램 범위가 증가하면 코드 유지 관리가 더욱 복잡해집니다.
복원성	응용 프로그램 기능은 여러 서비스에 분산되어 있습니다. 마이크로서비스에 장애가 발생하면 다른 마이크로서비스에서 제공하는 기능을 계속 사용할 수 있습니다.	구성 요소의 장애가 발생하면 전체 응용 프로그램의 가용성에 영향을 줄 수 있습니다.
확장성	각 마이크로서비스는 다른 서비스와 독립적으로 확장할 수 있습니다.	비즈니스 요구 사항이 애플리케이션의 특정 부분만 확장하는 경우에도 전체 애플리케이션을 확장해야 합니다.

마이크로서비스 아키텍처 채택 고려 사항

새로운 애플리케이션을 설계할 때는 높은 수준의 확장성, 유연성 및 안정성이 필요한 애플리케이션을 위한 마이크로서비스 아키텍처를 고려해야 합니다. 다른 프로그래밍 언어와 프레임워크를 사용하여 각 구성 요소를 개발할 수 있습니다.

애플리케이션 기능을 제한된 범위로 포커스된 서비스로 나눌 수 있는 경우 모놀리식 애플리케이션을 마이크로서비스로 마이그레이션하는 것이 좋습니다. 마이크로서비스 아키텍처로 마이그레이션할 수 없는 복잡한 모놀리식 애플리케이션의 경우, 새로운 기능만 마이크로서비스로 개발하는 것이 좋습니다.

서비스 간의 상호 의존성은 서비스 재배치 중 응용 프로그램을 사용할 수 없는 정도에 영향을 줄 수 있습니다. 응용 프로그램 설계 중에 이러한 종속성 문제를 해결합니다.

모놀리식 애플리케이션 리팩토링은 어렵습니다. 마이크로서비스 아키텍처를 사용하려는 경우 프로젝트 시작부터 계획하십시오.

마이크로서비스를 개발할 때 분산 시스템의 복잡성을 고려하고 원격 호출이 느리고 실패할 수 있음을 기억하십시오. 사용 사례에 따라 일관성, 가용성 및 Partition 허용 한도 간의 균형을 유지해야 합니다.

마이크로서비스 아키텍처와 관련된 운영상의 복잡성에 대비하십시오. 모놀리식 애플리케이션을 마이크로서비스 아키텍처로 이동하기 전에 다음 필요 조건을 충족하는 것이 좋습니다.

• 신속한 프로비저닝: 서버를 신속하게 프로비저닝하는 기능
• 기본 모니터링: 서비스 문제 및 비즈니스 문제를 감지하는 기능입니다. 서비스 문제에는 서비스 가용성, 기능 오류 및 성능 문제가 포함됩니다.
• 신속한 애플리케이션 배포: 모든 서비스를 테스트 및 프로덕션 환경에 신속하게 배포할 수 있는 기능

마이크로서비스 아키텍처의 이점이 비용보다 큰지 확인하십시오.

마이크로 서비스 구조의 통신 방식 정보

마이크로서비스 아키텍처에서 서비스는 여러 서버에서 실행됩니다. 이러한 서비스 간의 통신은 HTTP, AMQP 및 TCP와 같은 프로토콜을 통해 발생합니다. HTTP/REST 및 비동기 메시징은 가장 널리 사용되는 프로토콜입니다.

웹 서비스용 REST API는 일반적으로 HTTP 프로토콜을 사용합니다. HTTP 메소드(예: GET, POST, PUT 및 DELETE)를 사용하면 클라이언트가 URL(Uniform Resource Locator)을 사용하여 응용 프로그램 리소스에 액세스하고 조작할 수 있습니다.

클라이언트는 애플리케이션 기능에 대한 시작점을 나타내는 REST API를 통해 서비스로 요청을 전송합니다. 클라이언트는 직접 또는 API 게이트웨이를 통해 마이크로서비스와 통신할 수 있습니다.

API 게이트웨이 패턴은 서비스에 대한 모든 요청에 대한 단일 시작점을 정의합니다. 클라이언트 요청이 도착하면 API 게이트웨이는 해당 서비스로 요청의 경로를 지정합니다.

API 게이트웨이 패턴의 변형은 프론트엔드용 백엔드 패턴으로, 각 종류의 클라이언트(예: 모바일 클라이언트용 게이트웨이 및 웹 애플리케이션용 게이트웨이)에 대해 별도의 API 게이트웨이를 정의합니다.

서비스 간의 통신을 최소화하는 것이 좋습니다. 통신이 필수적이면 비동기 통신이 선호됩니다. 요청을 전송하는 서비스는 응답을 기다리지 않고 작업을 계속할 수 있습니다.

메시징 대기열 및 스트리밍 시스템은 비동기 통신을 제공하는 이상적인 방법이며, 데이터베이스에 통합되면 데이터 작업 및 메시지 전송을 위한 트랜잭션 의미를 제공합니다. 따라서 마이크로서비스 배포가 더 간단하고 확장성이 뛰어납니다. REST API를 독점적으로 사용하면 마이크로서비스 간 통신이 동기식으로 이루어지며 일반적으로 확장이 제한됩니다.

필수 서비스 및 역할 정보

이 솔루션을 사용하려면 다음 서비스가 필요합니다.

• Oracle Cloud Infrastructure Database(Oracle Autonomous Database를 포함한 다양한 선택 사항)
• Oracle Cloud Infrastructure Container Engine for Kubernetes
• Spring Boot and MicroservicesOracle Backend for Spring Boot and Microservices용 Oracle Backend

각 서비스에 필요한 역할은 다음과 같습니다.

서비스 이름: 롤	필수...
Oracle Cloud Infrastructure Database: SYSTEM 또는 ADMIN	Oracle Backend for Spring Boot and Microservices를 구성할 때 프록시 데이터베이스 액세스 사용자를 생성합니다. SYSTEM 또는 ADMIN가 작동하지만 권한이 초과되어 운용 환경에서 사용해서는 안됩니다.
Oracle Cloud Infrastructure Container Engine for Kubernetes: CLUSTER_MANAGE	Oracle Cloud Infrastructure Container Engine for Kubernetes 클러스터와 작업자 노드 3개가 있는 노드 풀을 생성합니다.
Oracle Backend for Spring Boot and Microservices: ROLE_ADMIN	Oracle Backend for Spring Boot and Microservices를 설치합니다.

필요한 내용은 Oracle 제품, 솔루션 및 서비스를 참조하십시오.