Why use a microservices approach to building applications

소프트웨어 개발자에게 애플리케이션을 컴포넌트 단위로 분해하는 것은 새로운 일이 아닙니다. 일반적으로 백엔드 저장소, 중간 계층 비즈니스 로직, 프론트엔드 사용자 인터페이스(UI)로 구성된 계층형 접근 방식을 사용합니다. 지난 몇 년 동안 변화된 점은 개발자들이 클라우드용 분산 애플리케이션을 구축하고 있다는 것입니다.

다음은 변화하는 비즈니스 요구 사항입니다.

• 새로운 지리적 지역의 고객에게 도달하기 위해 대규모로 구축 및 운영되는 서비스.
• 고객 요구에 민첩하게 대응하기 위한 기능 및 역량의 빠른 제공.
• 비용 절감을 위한 향상된 리소스 활용.

이러한 비즈니스 요구 사항은 우리가 애플리케이션을 구축하는 방식에 영향을 미치고 있습니다.

 

Monolithic vs. microservices design approach

애플리케이션은 시간이 지나면서 진화(Evolve)합니다.
성공적인 애플리케이션은 사용자들에게 유용하기 때문에 지속적으로 발전 합니다.
반면, 실패한 애플리케이션은 더 이상 발전하지 않고 결국 폐기(Deprecated)됩니다.

💡 중요한 질문:

• 현재 요구사항(Requirements) 에 대해 얼마나 잘 알고 있는가?
• 미래에는 어떻게 변화할 것인가?

예를 들어:

• 사내 부서를 위한 리포트 애플리케이션 을 개발한다고 가정합니다.
  • 이 애플리케이션은 회사 내부에서만 사용 될 것이 확실합니다.
  • 보고서가 오랫동안 보관되지 않을 것 이므로 확장성 요구사항이 낮습니다.
• 반면, 수천만 명의 고객에게 동영상 콘텐츠를 제공하는 서비스 를 개발하는 경우:
  • 전 세계적인 확장성(Scalability) 과 고가용성(High Availability) 이 필수적입니다.

🚀 초기 개발과 확장성을 고려한 접근 방식

✅ 빠르게 프로토타입을 출시(Proof of Concept)하는 것이 중요한 경우,

• 애플리케이션을 나중에 다시 설계할 수 있음을 알고 있다면,
• 과도한 설계(Over-engineering)는 피하는 것이 좋습니다.
  ✅ 반면, 클라우드 환경을 고려한 확장 가능 애플리케이션을 구축 한다면,
• 성장과 사용량 증가를 예상해야 합니다.
• 린 스타트업(Lean Startup) 접근법 을 사용하여,
  • 빠르게 개발(Build), 측정(Measure), 학습(Learn), 반복(Iterate) 하는 방식이 적합합니다.

🛠 모놀리식 애플리케이션 (Monolithic Application)

과거 클라이언트/서버(Client/Server) 시대 에는

• 각 계층(Tier)에 특정 기술을 적용하여 계층형 애플리케이션(Tiered Applications)을 구축 했습니다.
• 이후, 이를 모놀리식 애플리케이션(Monolithic Application) 이라 부르게 되었습니다.
• 인터페이스는 주로 계층 간(Tier-to-Tier)에서 정의 되었으며,
  • 각 계층 내부의 컴포넌트들은 강하게 결합(Tightly Coupled)된 설계를 따랐습니다.
• 개발자들은 라이브러리(Library)를 설계하고 컴파일하여 실행 파일(Executable)과 DLL로 배포 했습니다.

✅ 모놀리식 아키텍처의 장점

• 설계가 상대적으로 단순(Simple Design)함
• 컴포넌트 간 호출이 빠름 (대부분 IPC(Inter-Process Communication) 을 사용)
• 모든 팀원이 단일 제품을 테스트 하므로 테스트 효율성이 높음

⚠️ 모놀리식 아키텍처의 단점

• 계층 간 강한 결합(Tight Coupling) 으로 인해 개별 컴포넌트의 확장(Scalability) 어려움
• 수정 또는 업그레이드를 진행할 때, 다른 팀의 테스트 완료를 기다려야 함
• 애자일(Agile) 개발 방식 적용이 어려움

🛠 마이크로서비스 (Microservices)

마이크로서비스는 모놀리식 아키텍처의 단점을 해결하기 위해 등장 했습니다.

✅ 마이크로서비스의 장점

• 각 서비스는 단순한 비즈니스 기능(Business Functionality)을 캡슐화
• 각 서비스는 독립적으로 확장 가능(Scalable)
• 테스트, 배포(Deployment), 운영(Management)이 개별적으로 수행 가능
• 팀이 비즈니스 요구사항(Business Scenarios)에 기반하여 개발하도록 유도
• 소규모 팀(Small Teams)이 고객 시나리오(Customer Scenario)에 맞게 서비스 개발 가능
• 각 팀은 원하는 기술 스택(Technology Stack)을 자유롭게 선택 가능

⚠️ 마이크로서비스의 단점

• 각 서비스가 독립적이므로, 관리해야 할 엔터티(Entity) 개수가 증가
• 배포(Deployment) 및 버전 관리(Versioning) 복잡성이 증가
• 마이크로서비스 간 네트워크 통신 증가 → 네트워크 지연(Network Latency) 문제 발생 가능
• 과도하게 작은 서비스(Chatty, Granular Services)로 인해 성능 문제 발생 가능
• 각 서비스 간의 종속성(Dependencies)을 추적하기 어렵고, 전체 시스템을 한눈에 파악하기 어려움

🔗 마이크로서비스 성공을 위한 표준화 (Standardization)

• 마이크로서비스 아키텍처는 표준화(Standardization)가 핵심 요소입니다.
• 마이크로서비스는 독립적으로 업데이트되므로, 서비스 간의 통신 방식과 API 계약(Contract)을 사전에 명확히 정의해야 합니다.
• 불필요한 종속성을 피하고, 각 서비스가 필요한 기능만 제공하도록 설계해야 합니다.

💡 이런 이유로 마이크로서비스 아키텍처를 "세분화된 서비스 지향 아키텍처(Fine-Grained SOA, Service-Oriented Architecture)" 라고도 합니다.

간단히 말해서, 마이크로서비스 설계 방식은 각 서비스에 대한 독립적인 변경과 합의된 통신 표준을 가진 분리된 서비스 연합에 관한 것입니다.
더 많은 클라우드 애플리케이션이 제작됨에 따라, 사람들은 전체 애플리케이션을 독립적이고 시나리오 중심적인 서비스로 분해하는 것이 더 나은 장기적인 접근 방식이라는 것을 발견했습니다.

 

Comparison between application development approaches

1. 모놀리식 애플리케이션은 도메인 특정 기능을 포함하며 일반적으로 웹, 비즈니스, 데이터와 같은 기능적 계층으로 나뉩니다.
2. 모놀리식 애플리케이션은 여러 서버/가상 머신/컨테이너에 복제하여 확장합니다.
3. 마이크로서비스 애플리케이션은 기능을 별도의 더 작은 서비스로 분리합니다.
4. 마이크로서비스 접근 방식은 각 서비스를 독립적으로 배포하고, 서버/가상 머신/컨테이너에 걸쳐 해당 서비스의 인스턴스를 생성하여 수평 확장합니다.

📌 모놀리식 애플리케이션 (Monolithic Application)

1️⃣ 모놀리식 애플리케이션은 도메인별 기능을 포함하며, 일반적으로 웹(Web), 비즈니스(Business), 데이터(Data)와 같은 기능 계층(Layers)으로 구성됩니다.

2️⃣ 모놀리식 애플리케이션을 확장(Scaling)하는 방법:

• 여러 서버/가상 머신/컨테이너에 동일한 애플리케이션을 복제(Cloning)하여 배포합니다.

📌 마이크로서비스 애플리케이션 (Microservices Application)

3️⃣ 마이크로서비스 아키텍처에서는 기능을 개별적인 작은 서비스들로 분리(Decoupling)합니다.

4️⃣ 마이크로서비스의 확장(Scaling) 방식:

• 각 서비스를 독립적으로 배포(Deploy)할 수 있으며,
• 여러 서버/가상 머신/컨테이너에 걸쳐 서비스 인스턴스를 동적으로 생성(Scaling Out)합니다.

📌 마이크로서비스 설계 접근 방식

• 모든 프로젝트에 마이크로서비스 접근 방식이 적합한 것은 아닙니다.
• 하지만 이전에서 논의한 비즈니스 목표(Business Objectives)와 더 잘 맞는 경우가 많습니다.

💡 언제 모놀리식에서 시작할 것인가?

• 만약 향후 코드를 마이크로서비스 구조로 변경할 기회가 보장된다면,
  • 초기에 모놀리식 아키텍처로 시작하는 것이 합리적일 수 있습니다.
• 일반적으로, 모놀리식 애플리케이션을 먼저 구축한 후, 점진적으로 마이크로서비스로 전환하는 경우가 많습니다.
  • 특히, 더 높은 확장성(Scalability)이나 유연성(Agility)이 필요한 기능 영역부터 분리하는 방식이 일반적입니다.

✅ 마이크로서비스 아키텍처에서는:

• 애플리케이션을 작은 독립적인 서비스(Microservices)로 구성 합니다.
• 이러한 서비스들은 클러스터화된 머신(Cluster of Machines)에서 컨테이너(Container)로 실행됩니다.
• 소규모 팀(Small Teams) 이 각 서비스를 개발하며,
  • 독립적으로 테스트, 버전 관리, 배포, 확장 가능하도록 설계합니다.
• 이를 통해 전체 애플리케이션이 지속적으로 발전(Evolve)할 수 있도록 지원합니다.

 

What is a microservice?

마이크로서비스에 대한 다양한 정의가 있습니다. 하지만 대부분의 마이크로서비스 특성은 널리 받아들여지고 있습니다.

• 고객 또는 비즈니스 시나리오를 캡슐화합니다. 어떤 문제를 해결하고 있습니까?
• 소규모 엔지니어링 팀에서 개발합니다.
• 어떤 프로그래밍 언어, 어떤 프레임워크를 사용하든 작성할 수 있습니다.
• 코드와 선택적으로 상태를 포함하며, 둘 다 독립적으로 버전 관리, 배포 및 확장됩니다.
• 잘 정의된 인터페이스 및 프로토콜을 통해 다른 마이크로서비스와 상호 작용합니다.
• 위치를 확인하는 데 사용되는 고유한 이름(URL)을 갖습니다.
• 실패가 발생하더라도 일관성과 가용성을 유지합니다.

요약하자면 다음과 같습니다.

마이크로서비스 애플리케이션은 잘 정의된 인터페이스를 갖춘 표준 프로토콜을 통해 서로 통신하는 작고 독립적으로 버전 관리되고 확장 가능한 고객 중심 서비스로 구성됩니다.

 

Written in any programming language, using any framework

개발자로서, 우리는 서비스를 개발할 때 자신의 기술과 서비스의 요구사항에 맞는 언어 및 프레임워크를 자유롭게 선택할 수 있기를 원합니다.

• 일부 서비스에서는 C++의 성능(Performance) 이점이 가장 중요할 수 있습니다.
• 다른 서비스에서는 C# 또는 Java가 제공하는 편리한 관리형 개발(Managed Development)이 더 중요할 수 있습니다.
• 경우에 따라, 특정 파트너 라이브러리(Partner Library), 데이터 저장 기술(Data Storage Technology), 또는 클라이언트에 서비스를 노출하는 방식(Method for Exposing the Service) 을 사용해야 할 수도 있습니다.

✅ 기술을 선택한 후에는,

• 서비스의 운영(Operation), 라이프사이클 관리(Life-Cycle Management), 확장성(Scaling)도 고려해야 합니다.

 

Allows code and state to be independently versioned, deployed, and scaled

마이크로서비스를 어떤 방식으로 개발하든,
코드와 상태(State)는 독립적으로 배포(Deploy), 업그레이드(Upgrade), 확장(Scale) 가능해야 합니다.

📌 이 문제는 기술 선택(Choice of Technologies)에 따라 해결 난이도가 달라집니다.

• 확장성(Scaling) 을 고려할 때,
  • 코드와 상태를 어떻게 분할(Partition) 또는 샤딩(Sharding)할 것인지 결정하는 것이 어려운 과제입니다.
• 오늘날에는 코드와 상태가 서로 다른 기술을 사용하는 경우가 많기 때문에,
  • 마이크로서비스의 배포 스크립트(Deployment Scripts)는 둘 다 확장할 수 있어야 합니다.

📌 이러한 분리는 애자일(Agility)과 유연성(Flexibility)을 제공하는 핵심 요소입니다.

• 일부 마이크로서비스만 업그레이드하고, 나머지는 그대로 유지할 수 있도록 합니다.
• 모든 서비스를 한 번에 업그레이드해야 하는 부담을 줄여줍니다.

✅ 이제, 모놀리식과 마이크로서비스 접근 방식의 상태 저장 방식(State Storage) 차이를 살펴보겠습니다.

 

State storage for the two approaches

📌 모놀리식 아키텍처(Monolithic Approach)에서의 상태 저장

• 모놀리식 아키텍처(왼쪽) 에서는 하나의 단일 데이터베이스(Single Database)를 사용 하며,
  • 특정 기술 스택(Tiered Technologies)에 기반한 계층 구조 로 구성됩니다.

✅ 단일 데이터베이스를 사용하는 장점:

• 모든 데이터가 한 곳에 위치 하므로 배포가 용이 함
• 각 컴포넌트가 자신의 상태(State)를 저장할 수 있는 개별 테이블을 가질 수 있음

⚠️ 단일 데이터베이스의 문제점:

• 팀이 각 상태를 엄격하게 분리해야 하는 어려움이 있음
• 시간이 지나면서,
  • 누군가 기존 테이블에 새로운 컬럼을 추가하거나, 테이블 간 조인(Join)을 수행하여 데이터 종속성(Dependency)을 생성할 가능성이 높음
• 이런 종속성이 생기면, 개별 컴포넌트를 독립적으로 확장(Scale)할 수 없게 됨

📌 마이크로서비스 아키텍처(Microservices Approach)에서의 상태 저장

• 마이크로서비스 아키텍처(오른쪽) 에서는 각 마이크로서비스가 자체적인 상태(State)를 관리하고 저장 합니다.
• 서비스마다 별도의 데이터 저장소를 사용 하며, 각 서비스는 코드와 상태를 함께 확장(Scaling)할 책임을 가짐

✅ 마이크로서비스에서 상태 저장을 분리하는 장점:

• 각 서비스가 독립적으로 확장 가능
• 각 서비스는 자신에게 적합한 데이터 저장 기술을 사용할 수 있음

⚠️ 마이크로서비스에서 상태 저장을 분리할 때의 단점:

• 애플리케이션의 데이터를 조회(View)하거나, 쿼리(Query)를 수행할 때 여러 개의 데이터 저장소를 조회해야 하는 문제 발생
  • 이 문제는 별도의 마이크로서비스(View Aggregation Service)를 만들어 해결 할 수 있음
  • 특정 마이크로서비스가 여러 개의 마이크로서비스의 데이터를 집계하여 단일 뷰를 제공
• 데이터 분석을 위해 여러 마이크로서비스의 데이터를 한꺼번에 조회해야 하는 경우,
  • 각 마이크로서비스의 데이터를 데이터 웨어하우스(Data Warehousing Service)에 저장하여 오프라인 분석 수행을 고려해야 함

📌 마이크로서비스의 버전 관리(Versioning)

• 마이크로서비스는 버전(Versioning)이 적용 가능
• 다른 버전의 마이크로서비스를 동시에 실행 가능(Side-by-Side Deployment)
  • 신규 버전이 배포되었을 때 문제가 발생하면, 이전 버전으로 롤백(Rollback) 가능
  • A/B 테스트에 활용 가능 → 특정 고객 그룹에만 새로운 기능을 먼저 배포하여 테스트
  • 예: 일부 고객에게만 새로운 마이크로서비스를 제공한 후, 안정성이 검증되면 전체 사용자에게 확대 적용

 

Interacts with other microservices over well-defined interfaces and protocols

지난 10년 동안, 서비스 지향 아키텍처(Service-Oriented Architecture, SOA)에서의 통신 패턴 에 대한 다양한 정보가 공유되었습니다.

✅ 일반적으로, 마이크로서비스 간의 통신은 다음과 같은 방식으로 이루어집니다.

• REST 기반 접근 방식 을 사용
• HTTP 및 TCP 프로토콜 활용
• XML 또는 JSON 을 직렬화(Serialization) 형식으로 사용

✅ 인터페이스 관점에서 보면, 이는 웹(Web) 디자인 접근 방식과 유사합니다.

• 즉, API를 통해 마이크로서비스 간의 데이터 교환을 수행하는 방식 입니다.

⚠️ 그러나, 바이너리 프로토콜(Binary Protocols)이나 자체적인 데이터 형식(Custom Data Formats)도 사용할 수 있습니다.

• 하지만, 이러한 프로토콜과 데이터 형식이 공개되지 않으면, 다른 사람들이 해당 마이크로서비스를 사용하기 어려울 수 있습니다.

 

Has a unique name (URL) used to resolve its location

✅ 마이크로서비스는 실행 위치와 상관없이 주소 지정이 가능해야 합니다.

• 특정 머신에서 어떤 마이크로서비스가 실행되는지를 직접 관리하려 하면 복잡성이 증가하고 장애 가능성이 높아질 수 있습니다.

✅ DNS가 특정 URL을 특정 머신으로 매핑하는 것과 같은 원리로,

• 마이크로서비스는 현재 실행 위치를 식별할 수 있는 고유한 이름(Unique Name)을 가져야 합니다.
• 인프라와 독립적인 주소(Independent Addressable Names) 가 필요합니다.

✅ 서비스 등록(Service Registry) 필요성

• 마이크로서비스의 배포 방식과 서비스 검색(Service Discovery) 방식은 밀접하게 연결됩니다.
• 머신이 장애(Failure)로 인해 다운되었을 때, 서비스 레지스트리(Service Registry)는 해당 서비스가 어디로 이동했는지 알려주어야 합니다.

 

Remains consistent and available in the presence of failures

✅ 예기치 않은 장애(Failure)를 처리하는 것은 분산 시스템에서 가장 어려운 문제 중 하나입니다.

• 개발자가 작성하는 코드의 상당 부분은 예외 처리(Exception Handling) 를 위한 것입니다.
• 테스트에서도 예외 처리 및 장애 대응 테스트 에 가장 많은 시간을 할애합니다.
• 하지만, 단순히 장애를 처리하는 코드만으로는 충분하지 않습니다.
  • 마이크로서비스가 실행 중인 머신이 다운되면 어떻게 될까요?
  • 이를 감지(Detect)하고, 해당 마이크로서비스를 다시 시작(Restart)해야 합니다.

✅ 가용성(Availability)을 유지하기 위한 요구 사항:

• 마이크로서비스는 장애에 대해 회복력(Resiliency)을 가져야 하며, 다른 머신에서 자동으로 재시작 가능해야 합니다.
• 이러한 복원력 요구 사항을 충족하는 동시에, 데이터 손실이 없어야 하며, 데이터의 일관성(Consistency)이 유지되어야 합니다.

✅ 애플리케이션 업그레이드 중 장애 발생 시의 문제점

• 업그레이드 중 장애가 발생하면, 마이크로서비스는 단순히 복구하는 것이 아니라,
  • 신규 버전으로 계속 진행할 수 있는지 판단해야 합니다.
  • 혹은 이전 버전으로 롤백(Rollback)하여 일관성을 유지해야 합니다.
• 이를 위해 고려해야 할 사항:
  1. 현재 가용한 머신 수가 충분한가?
  2. 이전 버전의 마이크로서비스를 어떻게 복구할 것인가?

✅ 이러한 결정을 내리기 위해서는, 마이크로서비스가 "헬스(Health) 정보"를 지속적으로 제공해야 합니다.

 

Reports health and diagnostics

✅ 마이크로서비스는 자신의 건강 상태(Health)와 진단 정보(Diagnostics)를 보고해야 합니다.

• 이것은 당연해 보이지만, 자주 간과되는 요소 중 하나입니다.
• 운영(Operation) 관점에서 마이크로서비스의 상태를 알 수 없다면, 문제를 파악하기 어렵습니다.

✅ 마이크로서비스에서 진단 이벤트(Diagnostic Events) 분석의 어려움

• 독립적인 여러 개의 마이크로서비스에서 발생하는 이벤트를 연관 지어 분석하는 것 은 어려운 작업입니다.
• 머신 간의 시계 불일치(Clock Skew) 로 인해 이벤트 발생 순서를 정확하게 파악하는 것도 도전 과제입니다.
• 마이크로서비스 간의 통신이 표준화된 프로토콜과 데이터 형식을 따르는 것처럼,
  • 헬스 체크(Health Check) 및 진단 로그(Diagnostic Logging)도 표준화해야 합니다.
• 결국, 이벤트 스토어(Event Store)에서 쉽게 조회하고 분석할 수 있도록 로그 형식을 정해야 합니다.
• 다른 팀들이 동일한 로깅 형식을 사용하도록 합의하는 것이 중요합니다.

✅ 건강 상태(Health) vs. 진단(Diagnostics)

• 건강 상태(Health):
  • 마이크로서비스가 현재 상태(Current State)를 보고하여 적절한 조치를 취할 수 있도록 합니다.
  • 예를 들어, 업그레이드 및 배포 과정에서 가용성을 유지하는 데 중요한 역할 을 합니다.
• 진단(Diagnostics):
  • 마이크로서비스의 이전 이벤트 및 실행 기록을 분석하여 문제를 해결하는 데 도움을 줍니다.

✅ 건강 상태 이벤트(Health Events)의 중요성

• 서비스가 일시적으로 비정상적인(Unhealthy) 상태 일 수 있습니다.
  • 예: 프로세스 충돌(Process Crash) 또는 머신 재부팅(Machine Reboot)
• 그러나 이 상태가 운영에 즉각적인 영향을 주지는 않을 수도 있습니다.
  • 단순히 현재 비정상적인 상태라고 해서 즉시 업그레이드나 복구 작업을 수행하는 것이 최선이 아닐 수도 있습니다.
  • 무리하게 업그레이드를 시작하면 상황을 더욱 악화시킬 수도 있습니다.
• 가장 좋은 접근 방식은 먼저 상황을 조사하고(Monitoring & Investigation), 서비스가 스스로 복구할 시간을 주는 것입니다.
• 마이크로서비스의 헬스 이벤트는 "자가 치유(Self-Healing) 서비스"를 만드는 데 중요한 역할을 합니다.

 

출처 : https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices