마이크로 서비스란?

클라우드는 오늘날의 애플리케이션 개발 및 IT 시스템 관리를 주도합니다. 최신 클라우드 애플리케이션은 빠르고 민첩하며 스케일링 성능이 뛰어나고 안정적이어야 합니다.

컨테이너를 사용하면 이러한 모든 요구 사항을 충족하는 애플리케이션을 배포하는 데 도움이 될 수 있습니다. 그러나 전략적인 디자인 패턴을 따르지 않고 애플리케이션을 컨테이너에 넣는 것은 처음 가는 도시를 지도나 GPS 없이 차를 운전해 찾아가는 것과 같습니다. 목적지에 도착할 수는 있지만 직행 경로 또는 가장 효율적인 길이 아닐 수 있습니다.

마이크로 서비스 아키텍처는 이러한 시나리오에서 유용합니다. 마이크로 서비스는 최신 클라우드 애플리케이션의 민첩성, 확장성, 안정성 요구 사항에 완벽하게 적합한 소프트웨어 개발 및 배포 방법을 제공합니다.

마이크로 서비스 아키텍처란?

마이크로 서비스 아키텍처에서는 대규모 애플리케이션이 더 작은 서비스 세트로 분할됩니다. 각 서비스는 자체 프로세스에서 실행되며 HTTP/HTTPS, WebSocket 또는 AMQP(Advanced Message Queuing Protocol)와 같은 프로토콜을 사용하여 다른 프로세스와 통신합니다. 각 마이크로 서비스는 특정 컨텍스트 경계 내에서 특정 엔드투엔드 도메인이나 비즈니스 기능을 구현합니다. 각 마이크로 서비스는 자율적으로 개발되고 독립적으로 배포될 수 있어야 합니다. 마지막으로 각 마이크로 서비스는 관련 도메인 데이터 모델 및 도메인 논리를 소유해야 합니다. 마이크로 서비스는 다양한 데이터 스토리지 기술(SQL, NoSQL)과 다양한 프로그래밍 언어를 기반으로 할 수 있습니다.

마이크로 서비스의 몇 가지 주요 특징은 다음과 같습니다.

마이크로 서비스는 작고, 독립적이며, 느슨하게 결합되어 있습니다.
각 마이크로 서비스에는 소규모 개발팀이 관리할 수 있는 개별 코드 베이스가 있습니다.
마이크로 서비스는 독립적으로 배포됩니다. 팀은 전체 애플리케이션을 다시 빌드하고 다시 배포하지 않고도 기존 마이크로 서비스를 업데이트할 수 있습니다.
데이터 또는 외부 상태를 각각의 데이터베이스에 유지합니다. 모놀리식 아키텍처에서와는 달리 마이크로 서비스는 데이터베이스를 공유하지 않습니다.
잘 정의된 API를 사용하여 서로 통신합니다. 각 서비스의 내부 구현 세부 정보는 다른 서비스에서 숨겨집니다.
마이크로 서비스는 다국어 프로그래밍을 지원합니다. 예를 들어 웹 애플리케이션을 구성하는 마이크로 서비스가 동일한 기술 스택, 라이브러리, 프레임워크를 공유할 필요가 없습니다.

마이크로 서비스 아키텍처를 사용하여 개발하는 이유는 무엇인가요?

마이크로 서비스는 일반적으로 더 간단한 고객 요구 사항 기능을 캡슐화하며, 사용자는 이를 스케일 아웃 또는 스케일 인 할 수 있습니다. 이를 독립적으로 테스트, 배포 및 관리할 수 있습니다. 마이크로 서비스 접근 방식의 한 가지 중요한 이점은 팀이 특정 기술의 사용보다는 고객 시나리오에 더 초점을 맞추게 된다는 점입니다. 각 소규모 개발팀은 고객 시나리오를 기반으로 마이크로 서비스를 개발합니다. 팀은 사용할 기술을 선택합니다.

마이크로 서비스는 장기적인 민첩성을 제공합니다. 마이크로 서비스를 사용하면 각각 세부적이고 자율적인 수명 주기가 있으며 개별적으로 배포할 수 있는 다수의 서비스를 기반으로 애플리케이션을 만들어 확장성이 뛰어난 복잡한 대규모 시스템에서 유지 관리할 수 있습니다.

뿐만 아니라 마이크로 서비스를 독립적으로 스케일 아웃할 수 있습니다. 단일 모놀리식 애플리케이션을 한 단위로만 스케일 아웃하는 대신 특정 마이크로 서비스를 스케일 아웃할 수 있습니다. 애플리케이션에서 처리 능력이나 네트워크 대역폭이 더 많이 필요한 기능 영역만 확장하고 기타 영역은 확장할 필요 없이 수요를 지원할 수 있습니다. 즉, 하드웨어를 적게 사용하기 때문에 비용이 절감됩니다.

가상 머신 전체에서 마이크로 서비스의 크기를 조정하는 방법을 보여 주는 다이어그램.

마이크로 서비스 접근 방식을 사용하면 복잡하고, 크고, 확장성 있는 애플리케이션에서 작은 특정 영역만 변경할 수 있으므로 각 마이크로 서비스에서 민첩한 변경과 신속한 반복이 가능합니다.

세분화된 마이크로 서비스 기반 애플리케이션을 구축하는 작업은 연속 통합 및 지속적인 업데이트 사례를 사용합니다. 또한 애플리케이션이 새 기능을 사용하도록 가속화합니다. 서비스 간에 명확한 계약을 유지하면서도 마이크로 서비스를 독립적으로 실행하고 테스트하고 독자적으로 발전시킬 수 있습니다. 인터페이스 또는 계약을 변경하지 않으면 다른 마이크로 서비스를 중단하지 않고 마이크로 서비스의 내부 구현을 변경하거나 새 기능을 추가할 수 있습니다.

컨테이너는 어떤 역할을 하나요?

컨테이너화는 애플리케이션 또는 서비스, 이에 해당하는 종속성 및 (배포 매니페스트 파일로 일반화된) 구성이 컨테이너 이미지로 패키지되는 소프트웨어 개발 방법입니다. 컨테이너화된 애플리케이션을 하나의 단위로 테스트하고, 이를 컨테이너 이미지 인스턴스로 호스트 운영 체제에 배포할 수 있습니다.

소프트웨어 컨테이너는 다양한 코드와 종속성을 포함할 수 있는 표준 소프트웨어 배포 단위로 작동합니다. 이는 전송 컨테이너가 배, 학습, 트럭으로 모든 종류의 상품을 전송하는 방식과 유사합니다. 개발자와 IT 전문가는 컨테이너화된 소프트웨어를 사용하여 코드 및 종속성을 거의 또는 전혀 수정하지 않고 환경 전체에 배포할 수 있습니다.

애플리케이션 컨테이너화는 마이크로 서비스 아키텍처 패턴을 구현하는 좋은 방법일 수 있습니다. 컨테이너 사용의 이점은 마이크로 서비스 아키텍처 사용의 이점과 거의 정확하게 일치합니다.

단일 호스트에서 실행되는 여러 컨테이너를 보여 주는 다이어그램.

참고 항목

애플리케이션 컨테이너화는 마이크로 서비스를 배포하는 유일한 방법이 아닙니다. 마이크로 서비스를 Azure App Service에서, 가상 머신에서, 또는 여러 다양한 방식으로 개별 서비스로서 배포할 수 있습니다. 컨테이너는 이 모듈의 나머지 부분에서 마이크로 서비스에 사용할 배포 도구입니다.

컨테이너화의 또 다른 이점은 확장성입니다. 단기 작업에 사용할 새 컨테이너를 만들어 빠르게 스케일 아웃할 수 있습니다. 애플리케이션의 관점에서 볼 때 이미지 인스턴스화(컨테이너 생성)는 서비스 또는 웹앱과 같은 프로세스 인스턴스화와 비슷합니다.

즉, 컨테이너는 전체 애플리케이션 수명 주기 워크플로에서 격리, 이식성, 민첩성, 확장성, 제어에 대한 이점이 있습니다.

이 모듈에서 빌드하는 마이크로 서비스는 .NET CLI를 사용하여 게시된 Docker 컨테이너에서 실행됩니다.

.NET SDK 컨테이너 게시

.NET 7에서 .NET SDK는 dotnet publish 명령을 통해 컨테이너 이미지를 만드는 기능을 얻었습니다. 이러한 도구는 프로젝트의 속성과 결과를 기반으로 많은 유추를 수행합니다. 그런 다음 .NET은 Dockerfile이 만드는 것과 동일한 이미지를 만듭니다. 새 애플리케이션을 만들고 이를 이미지로 게시하려면 두 개의 명령만 필요할 수 있습니다.

dotnet new webapi
dotnet publish --os linux --arch x64 /t:PublishContainer -c Release

위의 .NET CLI 명령은 새 웹 API를 만들고 앱을 컨테이너로 게시합니다.

Linux를 OS로 지정(--os linux).
x64 아키텍처 지정(--arch x64)
릴리스 구성 사용(-c Release)

MSBuild 속성을 통해 생성된 컨테이너의 여러 측면을 제어할 수 있습니다. 일반적으로 Dockerfile의 명령을 사용하여 일부 구성을 설정할 수 있는 경우 MSBuild를 통해 동일한 작업을 수행할 수 있습니다.

.NET에서 마이크로 서비스를 빌드하는 이유는 무엇인가요?

.NET Core부터 시작하여 현재 반복을 계속하는 .NET은 클라우드 네이티브 우선으로 빌드됩니다. .NET은 플랫폼 간에 실행되므로 Docker 이미지는 Linux 버전을 기반으로 할 수 있으며 .NET 코드는 계속 실행됩니다. Microsoft는 이미 Docker용 .NET 이미지를 만들었습니다. 또한 .NET은 매우 빠릅니다. ASP.NET Kestrel 웹 서버는 일상적으로 다른 웹 서버를 능가합니다.

도커

Docker는 클라우드 또는 온-프레미스에서 실행할 수 있는 이식 가능한 자급자족 컨테이너로 애플리케이션 배포를 자동화하는 데 사용할 수 있는 오픈 소스 플랫폼입니다. Docker는 이 기술을 홍보하고 발전시키는 회사이기도 합니다. 조직으로서 Docker는 Microsoft를 비롯한 클라우드, Linux 및 Windows 공급업체와 협력합니다.

Docker 컨테이너는 고객 데이터 센터의 온-프레미스, 외부 서비스 공급자, 클라우드 등 어디서나 실행할 수 있습니다. Docker 이미지 컨테이너는 Linux 및 Windows에서 기본적으로 실행할 수 있습니다.

이미지란?

개발자가 Docker를 사용하면 앱이나 서비스를 만들 수 있습니다. 그런 다음 앱이나 서비스와 해당 종속성을 컨테이너 이미지로 패키지합니다. 이미지는 앱 또는 서비스와 그 구성 및 종속성을 정적으로 표현합니다.

이미지가 실행되면 컨테이너가 됩니다. 컨테이너는 이미지의 메모리 내 인스턴스입니다.

컨테이너 이미지는 변경할 수 없습니다. 이미지를 빌드한 후에는 이미지를 변경할 수 없습니다. 이미지를 변경할 수 없으므로 앱 또는 서비스 및 해당 종속성을 변경해야 하는 경우 새 이미지를 만들어야 합니다. 이 기능은 프로덕션에서 사용하는 이미지가 개발 및 테스트에 사용되는 것과 동일한 이미지가 되도록 보장합니다.

Dockerfile이란?

Dockerfile은 Docker 이미지를 빌드하는 방법에 대한 지침이 포함된 텍스트 파일입니다. Dockerfile은 이미지를 빌드하고 구성하기 위해 설계된 최소 스크립팅 언어로 작성됩니다. Dockerfile은 또한 기본 이미지부터 시작하여 이미지를 빌드하는 데 필요한 작업을 문서화합니다.

애플리케이션을 포함하는 Docker 이미지를 만들려면 일반적으로 기본 이미지를 식별하는 것부터 시작합니다. 그런 다음 기본 이미지에 파일과 구성을 더 추가합니다. 적합한 기본 이미지를 식별하는 프로세스는 일반적으로 Docker Hub에서 검색하는 것으로 시작됩니다. Ubuntu나 Alpine과 같은 Linux 배포판의 모든 유틸리티와 도구와 애플리케이션 프레임워크가 이미 포함되어 있는 기성 이미지를 검색합니다. 예를 들어 컨테이너에 패키징하려는 ASP.NET 애플리케이션이 있는 경우 Microsoft는 이미 ASP.NET 런타임을 포함하고 있는 mcr.microsoft.com/dotnet/aspnet 이미지를 게시합니다.

기본 이미지로 컨테이너를 시작한 후 이미지를 사용자 지정한 다음 이를 변경할 수 있습니다. 변경은 주로 로컬 파일 시스템의 컨테이너에 파일을 복사하고, 다양한 도구와 유틸리티를 실행하여 코드를 컴파일하는 등의 작업이 포함됩니다.

Docker 파일은 애플리케이션 자체를 포함하여 애플리케이션을 실행하는 데 필요한 정확한 소프트웨어를 사용하여 Docker 이미지를 만드는 일련의 지침입니다.

피드백