[클라우드] MSA 개념 및 용어 정리

마이크로서비스와 비즈니스 민첩성

1. 비즈니스 민첩성 확보

• 사용자 피드백을 실시간으로 반영하여 서비스를 끊임없이 개선하는 것이 핵심임
• 아마존은 초당 1.5번 배포할 정도로 빠른 민첩성을 보유하고 있음
• 클라우드 인프라의 등장으로 과거 몇 주씩 걸리던 서버 구축이 클릭 몇 번으로 가능해짐

2. Cloud Friendly와 Cloud Native

• 시스템을 하나의 큰 덩어리로 만들어 클라우드에 올리는 방식을 Cloud Friendly라고 함
• 서비스별로 독립적으로 분리되어 배포되는 방식을 Cloud Native라고 정의함

Monolithic과 Microservice 비교

1. Monolithic 아키텍처

• 전체 애플리케이션을 하나의 단위로 개발하며, 아주 작은 변경사항에도 전체를 다시 빌드하고 배포해야 함
• 특정 기능만 확장할 수 없어 시스템 사용량 증가 시 전체 인스턴스를 복제해야 하는 비효율이 발생함
• 통합 데이터베이스를 사용하므로 데이터베이스 용량 증설 시 스케일 업(Scale-up)에 의존해야 함

2. Microservice 아키텍처

• 서버 측이 여러 조각으로 나뉘어 각 서비스가 별개의 인스턴스로 로딩됨
• 서비스마다 독립적인 저장소를 가지며, 업무 단위로 모듈 경계가 명확함
• 각 서비스별로 최적화된 언어를 선택하는 폴리글랏(Polyglot) 구현이 가능함
   

마이크로서비스 구현을 위한 변화

1. 조직 및 관리 체계의 변화

• 기술별 팀이 아닌 업무 기능 중심으로 다양한 기술 인력이 모인 다기능 팀(Cross-functional Team)을 구성함
• "You build it, you run it" 모토 아래 개발팀이 직접 운영까지 책임지는 자율적인 거버넌스를 추구함

2. 개발 생명 주기와 인프라 자동화

• 한시적인 프로젝트가 아닌 지속적으로 개선되는 제품(Product) 관점에서 애자일(Agile) 방식을 채용함
• 수많은 서비스를 효율적으로 배포하기 위해 CI/CD 파이프라인과 인프라를 코드로 관리하는 IaC(Infrastructure as Code) 자동화가 필수적임

1. 배포 파이프라인의 단계별 활동 (검증 중심)

서비스의 품질을 보장하기 위해 수행하는 소프트웨어 공학적 테스트 절차임.

• 컴파일 및 유닛테스트(빌드): 소스 코드를 실행 파일로 만들고 가장 작은 단위의 기능을 자동으로 검증하는 단계임.
• 기능 테스트(개발환경 배포): 개별 마이크로서비스가 설계된 비즈니스 로직에 따라 정상적으로 동작하는지 확인하는 과정임.
• 통합 테스트(테스트 환경 배포): 분리된 각 서비스들이 서로 연계되어 전체 시스템 흐름에 문제가 없는지 검증함.
• 인수 테스트(스테이징 환경 배포): 실제 운영 환경으로 넘어가기 전, 사용자의 요구사항과 비기능적 요건을 모두 만족하는지 최종 확인하는 절차임.

---

2. 배포 파이프라인의 환경 구성 (인프라 중심)

코드가 실제 운영 서버에 도달하기까지 거치는 물리적/논리적 서버 환경의 흐름임.

• 소스코드 빌드: 개발자가 작성한 코드를 빌드 도구(Maven, Gradle 등)를 통해 배포 가능한 상태로 패키징함.
• 개발 환경 배포 (Dev): 개발팀이 자유롭게 코드를 배포하고 기능을 테스트하며 의사소통하는 기초적인 실행 환경임.
• Staging(스테이징) 배포: 운영 환경과 거의 동일한 환경을 구축하여 운영 이전 단계에서 Security(보안), 성능, 장애 대응 등 비기능적 부분을 정밀하게 검증함.
• 운영 환경 배포 (Production): 모든 검증이 완료된 서비스를 실제 최종 사용자에게 서비스하는 실서버 환경임.

3. 데이터 일관성과 장애 대응

• 분산 트랜잭션 대신 메시지 큐를 활용한 결과적 일관성(Eventual Consistency)으로 데이터 정합성을 맞춤
• 서비스 장애가 전체로 확산되지 않도록 서킷 브레이커(Circuit Breaker) 패턴을 적용하여 시스템의 탄력성을 높임
   

Kafka를 이용한 메시징 인프라 구축

1. Kafka의 주요 특징

• 링크드인에서 개발한 중앙 집중형 데이터 스트림 관리 시스템임
• 소스 애플리케이션과 타겟 애플리케이션 간의 의존도를 낮춰 결합도를 완화함
• 높은 처리량, 무중단 확장성, 파일 시스템 기반의 데이터 영속성이 장점임

2. Docker 기반 설치 및 설정

• docker-compose를 통해 Zookeeper와 Kafka 컨테이너를 함께 구동함
• server.properties 설정에서 리스너(listeners) 주석을 해제하고 토픽 자동 생성 옵션을 활성화함
• 호스트와 컨테이너 간 설정 파일 복사를 통해 설정을 영구적으로 적용함

---

 

1. 애플리케이션 아키텍처 유형

• Monolithic(모놀리식): 전체 애플리케이션을 하나의 단위로 개발하는 일체식 구조이며, 작은 변화에도 전체를 빌드 및 배포해야 하는 단점이 있음
• Cloud Friendly: 전체 시스템을 하나의 덩어리로 만들어 클라우드 인프라에 올린 형태임
• Cloud Native: 서비스가 독립적으로 분리되어 개별적으로 배포될 수 있는 최적화된 형태임
• Microservice(마이크로서비스): 서버 측을 여러 조각으로 구성하여 업무 단위로 모듈 경계를 명확히 하고 각기 다른 저장소를 사용하는 방식임

2. 개발 및 운영 핵심 용어

• olyglot(폴리글랏): 각 서비스의 성격에 따라 서로 다른 언어와 데이터 저장 기술을 자율적으로 선택하여 사용하는 방식임
• You build it, you run it: 개발팀이 서비스의 생성부터 운영까지 전체 생명주기를 직접 책임진다는 아마존의 운영 모토임
• IaC(Infrastructure as Code): 인프라 구성을 소프트웨어처럼 코드로 처리하여 효율적으로 관리하고 복제하는 방식임
• DevOps: 개발 환경, 지원 환경을 자동화하여 개발과 운영을 동시에 수행할 수 있도록 하는 환경임

MSA 설계 패턴 및 기술 스택

1. 리액티브 선언(Reactive Manifesto)의 4대 속성

• Responsive(응답성): 사용자에게 신뢰성 있는 응답을 빠르고 적절하게 제공함
• Resilient(탄력성): 장애 발생 시에도 시스템 전체가 고장 나지 않고 빠르게 복구함
• Elastic(유연성): 트래픽 변화에 따라 자원을 늘리거나 줄여 균일한 응답성을 유지함
• Message Driven(메시지 기반): 비동기 메시지 전달을 통해 느슨한 결합과 논블로킹 통신을 지향함

2. 장애 및 데이터 관리 패턴

• Circuit Breaker(서킷 브레이커): 특정 서비스 장애 시 연쇄 파급을 막기 위해 호출을 차단하고 대응하는 패턴임
• Eventual Consistency(결과적 일관성): 데이터가 일시적으로 불일치하더라도 비동기 이벤트를 통해 결국 정합성이 맞춰지는 개념임
• Compensation Transaction(보상 트랜잭션): 오류 발생 시 이전 상태로 되돌리기 위해 수행하는 취소 작업임

3. 주요 모니터링 및 관리 도구 (Telemetry)

• Logging: 서비스별 로그를 수집하는 ELK, EFK 스택을 사용함
• Trace: 서비스 간 호출 경로를 추적하는 Sleuth, Zipkin 등을 활용함
• Monitoring: 시스템 상태를 실시간 확인하는 Prometheus, Grafana가 대표적임

Kafka 핵심 인프라 용어

1. 카프카의 구조와 특징

• Producer(프로듀서): 큐(Queue)에 데이터를 보내는 역할을 수행함
• Consumer(컨슈머): 큐에서 데이터를 가져가서 소비하는 역할을 수행함
• Broker(브로커): 카프카 클러스터 내의 서버를 의미하며 데이터를 안전하게 저장함
• Zookeeper(주키퍼): 카프카 분산 처리를 관리하고 조정하는 도구임

2. 카프카 사용의 이점

• High Throughput: 대용량 데이터를 실시간으로 빠르게 처리할 수 있음
• Persistence: 전송받은 데이터를 파일 시스템에 저장하여 재부팅 시에도 데이터를 유지함
• Decoupling: 소스 앱과 타겟 앱 사이의 의존도를 낮춰 시스템 간 결합을 완화함