마이크로 서비스 구조에 대해 알아보기

다국어로 확장할 수 있는 애플리케이션을 디자인하려는 경우, 손쉽게 유지보수를 유지하고 배포하며 장애를 최소화한 다음 마이크로 서비스 아키텍처를 사용하여 클라우드 애플리케이션을 디자인하고 배포합니다.

마이크로 서비스 아키텍처에서 각 마이크로 서비스는 간단한 작업을 소유하며, REST API 요청과 같은 경량 통신 방식을 사용하여 클라이언트 또는 기타 마이크로 서비스와 통신합니다.

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

microservice_architecture.png 에 대한 설명은 다음과 같습니다.
microservice_architecture.png 그림에 대한 설명

마이크로 서비스를 사용하면 응용 프로그램을 유연하게 결합된 서비스 모음으로 설계할 수 있습니다. 마이크로 서비스는 공유 프로세스 모델을 따르며 상태 비유지 프로세스로 실행됩니다. 이 접근 방식을 사용하면 애플리케이션을 보다 쉽게 확장 및 유지 관리할 수 있습니다.

  • API 층은 모든 클라이언트 요청에서 마이크로 서비스로 보내는 시작점입니다. API 층을 통해 마이크로 서비스는 HTTP, gRPC 및 TCP/UDP를 통해 서로 통신할 수 있습니다.
  • 논리 층은 단일 비즈니스 작업에 중점을 두어 다른 마이크로 서비스에 대한 종속성을 최소화합니다. 이 층은 각 마이크로 서비스에 대해 다른 언어로 작성될 수 있습니다.
  • 데이터 저장소 층은 데이터베이스 저장 엔진, 로그 파일 등과 같은 지속성 방식을 제공합니다. 각 마이크로 서비스에 대해 별도의 영구 데이터 저장소를 사용하는 것이 좋습니다.

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

마이크로 서비스와 일체형 아키텍처 간의 차이

마이크로 서비스 구조를 사용하여 응용 프로그램 디자인을 시작하기 전에 이 구조가 기존 모니터링 구조와 어떻게 다른지 이해해야 합니다.

애플리케이션 디자인은 비즈니스 요구사항 해결 및 비즈니스 논리 구현에 중점을 둡니다. Monolithic 구조에서는 전체 응용 프로그램이 모든 비즈니스 논리를 포함하는 단일 단위로 빌드됩니다. 마이크로 서비스 아키텍처에서 비즈니스 논리는 느슨하게 결합된 서비스로 구성됩니다.

다음 그림은 Monolithic 및 microservices 아키텍처를 보여줍니다.

monolithic_vs_microservice.png 에 대한 설명은 다음과 같습니다.
monolithic_vs_microservice.png 그림에 대한 설명

다음 표는 마이크로 서비스와 모니터링 아키텍처 간의 차이점을 요약합니다.

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

이러한 특성에 대한 자세한 내용은 마이크로 서비스 (Martin Fowler 및 James Lewis, 2014) 를 참조하십시오.

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

새 애플리케이션을 디자인할 때는 높은 레벨의 확장성, 유연성 및 안정성이 필요한 애플리케이션의 마이크로 서비스 구조를 고려합니다. 다른 프로그래밍 언어와 프레임워크를 사용하여 각 구성요소를 개발할 수 있습니다.

애플리케이션의 기능을 초점이 있는 서비스로 나눌 수 있고 각각 제한된 범위를 가진 경우 Monolithic 애플리케이션을 마이크로 서비스로 마이그레이션하는 것이 좋습니다. 마이크로 서비스 아키텍처로 이전할 수 없는 복합 Monolithic 애플리케이션의 경우 새로운 기능만 마이크로 서비스로 개발해 보십시오.

서비스 간 상호 종속성은 서비스 재배치 중 사용할 수 없는 응용 프로그램의 양에 영향을 줄 수 있습니다. 애플리케이션 설계 시 이러한 종속성 문제를 해결하십시오.

일체형 애플리케이션을 리팩토링하는 것은 어렵습니다. 마이크로 서비스 아키텍처를 사용하려는 경우 프로젝트 시작 시 계획합니다.

마이크로 서비스를 개발할 때 분산 시스템의 복잡성을 고려하고 원격 호출이 느리며 실패할 수 있음을 기억합니다. 사용 사례에 따라 일관성, 가용성 및 분할 영역 토큰 간에 균형을 조정해야 합니다.

마이크로 서비스 구조와 관련된 운영 복잡성이 준비되어 있습니다. Martin Fowler에 따르면 monolithic 응용 프로그램을 마이크로 서비스 구조로 이동하기 전에 다음 필요 조건을 이행해야 합니다.

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

마이크로 서비스 아키텍처의 이점이 비용을 초과하지 않는지 확인합니다.

자세한 내용은 Microservice 필요 조건 (Martin Fowler, 2014) 을 참조하십시오.

마이크로 서비스 아키텍처의 통신 방식 정보

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

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

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

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

API 게이트웨이 패턴의 변형은 각 유형의 클라이언트에 대해 별도의 API 게이트웨이를 정의하는 프론트엔드 패턴에 대한 백엔드입니다 (예: 모바일 클라이언트에 대한 게이트웨이 1개, 웹 애플리케이션에 대한 게이트웨이 1개).

서비스 간의 통신을 최소화하는 것이 좋습니다. 통신이 필수인 경우 비동기 통신을 사용하는 것이 좋습니다. 요청을 전송하는 서비스는 응답을 기다리지 않고 계속 작동할 수 있습니다.

필수 서비스 및 롤 정보

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

  • Oracle Cloud Infrastructure Database
  • Oracle Cloud Infrastructure Container Engine for Kubernetes

최소한 사용자 그룹이 구획에서 instance-family, volume-family, virtual-network-family, cluster-family, object-familydatabase-family 리소스 유형을 관리하도록 허용하는 정책을 정의합니다. 또한 테넌시에서 repos 리소스 유형에 대한 액세스 권한을 부여합니다.

필요한 클라우드 서비스를 얻을 수 있도록 Oracle 솔루션용 Oracle Cloud 서비스를 얻는 방법을 알아봅니다 .