Micro Service Architecture로 개발을 진행해보면 어떨까해서 이 글을 씁니다..
클라우드 네이티브가 무엇일까요?
클라우드 환경에서 잘 운영되도록 설계된 소프트웨어 개발 방법을 말한다
현재 정부 차원에서 클라우드 네이티브를 지원하고 있다.
왜 지원?
- 효율적인 자원 관리: 필요한 자원을 필요할 때만 사용하므로 낭비를 줄이고 비용을 절감할 수 있음, 정부는 세금으로 운영되기 때문에 이런 효율을 높이는 것이 중욯요함.
- 유연한 시스템: 클라우드 네이티브는 시스템을 유연하게 확장하거나 축소가 가능하다. 특정 서비스가 인기 있어지면 더 많은 자원을 제공하고, 덜 사용되면 자원을 줄여서 환경에 대응 가능.
- 고객 요청이 몰리는 시간대에서는 서버를 자동으로 늘리고 한가한 시간에는 줄일 수 있다.
예시: 전자상거래 플랫폼에서 블랙 프라이데이 같은 대규모 할인 이벤트 중 트래픽 급증-> 트래픽 급증 시 서버를 자동으로 늘려서 성능을 유지할 수 있다.
- 고객 요청이 몰리는 시간대에서는 서버를 자동으로 늘리고 한가한 시간에는 줄일 수 있다.
- 빠르고 안전한 서비스 제공: 자동화된 배포와 빠른 업데이트를 통해 시스템을 최신 상태로 유지 가능.
- 국가 경쟁력 강화 : 기술 혁신에 뒤쳐지지 않도록 정부가 최신 기술인 클라우드 네이티브를 적극적으로 도입하고 지원하는 것임.
애플리케이션을 클라우드 환경에서 최적화된 방식으로 설계하고 운영하는 접근 방식이다.
클라우드 인프라의 유연성과 확장성을 최대한 활용할 수 있도록 애플리케이션을 설계한다.
클라우드 네이티브의 핵심 요소
- 마이크로서비스 아키텍처(MSA)
- 컨테이너화
- 자동화 및 오케스트레이션
- 탄력성
- CI/CD
- DevOps
클라우드 네이티브 정의를 MSA, Container, CI/CD 기술요소로 하고 있다.
MSA가 뭔데요?
마이크로서비스 아키텍처를 의미합니다. 큰 애플리케이션을 작고 독립적인 서비스들로 나누어서 개발하는 아키텍처를 의미한다.
즉 MSA는 단일 애플리케이션을 여러 개의 자율적이고 작은 서비스들로 분리하는 방식이다.
신세계에서 했던 것은?
펫토피아 예시에서처럼 하나의 모듈 안에 Order, Ship 등을 패키지를 나누고 Controller, Repo, Service는 각각 분리한 것은 서비스를 나눈 것 같지만, 여전히 하나의 애플리케이션으로 배포되기 때문에 이는 모놀리식 아키텍처에 해당한대.
정리하자면 서비스가 나누어져 있더라도 하나의 애플리케이션으로 배포되면, 이 애플리케이션은 여전히 단일 배포 단위로 취급된다. 또한 MSA는 서비스가 독립적으로 배포되고 운영되는 구조를 말하는데, 이 경우 모든 서비스가 하나의 서버에서 실행되므로 모놀리식에 해당한다.
(또는 코드를 변경하면 전체 애플리케이션을 재배포를 해야되고 나 펫토피아 할 때 마지막에 계속 내 껏만 수정하는데 다시 배포하고 그동안 실행 안되고 기억나지 그러니까 독립적인 배포가 불가능해)
모놀리식의 단점
우리 프로젝트할때 애플리케이션이 하나의 큰 덩어리로 개발 되고, 또 고정된 서버환경을 사용했었잖아 이렇게 되면 트래픽이 증가했을떄 서버 하드웨어를 업그레이드 하거나 서버를 더 구매를 해야해
또한 이러한 기능들이 같은 JVM이나 같은 서버 인스턴스에서 실행되고 또한 데이터베이스도 같은 DB테이블에 접근하잖아
그럼 이건 굉장히 의존성이 강한 아키텍처야 즉 하나를 수정하면 다른 기능에 영향을 줄 수 있다는 말이야
따라서 장애가 발생하면 전체 시스템에 영향이가 만약 우리가 APP 돌리는데 내꺼에 오류 있으면 애초에 전체 애플리케이션이 중단되잖아
이는 각 기능이 독립적으로 실행되지 않기 때문이야
-> 따라서 이로인한 단점은 코드 관리나 유지 보수가 어려워져
코드베이스가 점점 커지면 Order, Ship 간의 코드 의존성을 관리하는 것이 점점 더 어려워 질거야
근데 마이크로 서비스라면?
(MSA의 장점)
1. 독립적으로 실행이 돼
Order나 Ship은 각각 독립적인 애플리케이션으로 실행돼 즉 서로 다른 프로세스나 서버에서 동작한다는 말이야
2. 독립적으로 배포가 가능해
Order와 Ship이 있을 때 별도로 배포가 가능해
3. 각자 데이터 베이스를 가져
Order와 Ship은 독립된 데이터베이스를 가질 수 있어
이로 통해서 데이터 베이스간의 의존성을 최소화할 수 있지
하지만 여기에도 단점이 있는데 모놀리식은 초기 개발은 굉장히 쉽지만 초기 설정이 굉장히 복잡해질 수 있다는 단점이 존재해
그래서 비교를 하자면
| 항목 | 기존 방식 | 클라우드 네이티브 |
| 설계 방식 | 모놀리틱 아키텍처 | 마이크로서비스 아키텍처 |
| 운영 환경 | 고정된 서버, 물리적 하드웨어 의존 | 클라우드 환경에 맞춰 최적화 (AWS, GCP등) |
| 확장성 | 서버 하드웨어 추가 필요 | 자동 확장(스케일 아웃/인) 가능 |
| 배포 속도 | 느림(전체 재배포 필요) | 빠름(부분적 배포 가능) |
| 리소스 효율성 | 리소스 낭비 가능 | 필요한 만큼만 리소스 사용 |
| 장애 복구 | 장애 발생 시 전체 시스템 중단 가능 | 장애 발생 시 다른 서비스는 정상 동작 |
서비스마다 어떻게 독립적으로 서버를 가지고 통신할 수 있을까..? 좀 알아보니까
API 스타일이 RESTful API 보다는 gRPC를 사용해야 된다고 하더라고 차이점이 뭐냐면 RESTful은 URL과 메서드를 사용해서 자원에 접근 했잖아 @GetMapping 같은 방식으로 간단하게 정의하고 요청에 응답받고 그런데 gRPC는 원격 프로시저 호출 방식을 사용해야 해
서버의 메서드를 직접 호출하는 방식이야 -> 서비스간 더 빠르고 효율적인 통신이 필요한 경우에 유용하대
따라서 RESTful API와 gRPC 서로 다른 목적에 따라 사용하는건데 MSA에서는 gRPC를 통한 통신이 훨씬 적합할 수 있대
왜냐면 MSA에서는 여러 개의 독립적인 서비스들이 서로 통신을 해야하잖아 그러면 효율적이고 빠른 통신이 필요해
그래서 RESTful도 쓰일 순 있겠지만 gRPC가 더 적합하다고 하더라고
간단하게 설명을 하면 gRPC는 HTTP/2 프로토콜 기반, Protocol Buffeers를 사용하여 데이터를 직렬화 한대.
이 방식은 JSON을 사용하는 REST보다 더 작은 크기와 빠른 속도를 제공해
그런데 단점은 이제 브라우저에서 직접 호출하는데 어려움이 있대 이 말은 우리가 평소에 사용하던 Postman으로 값이 요청되고 응답되는 것을 확인할 수 없다는 것이야.. gRPC-Web 을 사용하거나 별도의 클라이언트를 구축해야한대
RESTful은 훨씬 상대적으로 빠르게 구현할 수 있겠지
그래서 대한민국에서 클라우드 네이티브로 개발하는 대기업?
1. 네이버(NAVER)
- NAVER Cloud Platform: 자체 클라우드 네이티브 플랫폼 운영
- MSA로 다양한 네이버 서비스 (NAVER Pay, NAVER Webtoon등)를 운영
- 방식: Docker, Kubernetes, Spring Boot 등 다양한 기술 스택을 활용하여 MSA 환경을 구축하고 있으며, Naver Cloud Platform(NCP)를 통해 인프라를 관리합니다.
2. 카카오(Kakao)
- 카카오 클라우드 플랫폼을 통해 내부 서비스에 클라우드 네이티브 기술을 적극 도입하고 있대
- 대규모 데이터 처리와 MSA 구조를 통해 안정적이고 유연한 서비스를 제공
- 방식: Spring Boot, Kubernetes, Docker 등을 사용하여 MSA 기반 아키텍처를 구축
3. 라인
- 방식: Docker, Kubernetes, AWS, Spring Boot 등을 사용하여 MSA 환경을 구성
4. 쿠팡(Coupang)
- 방식: Kafka, Docker, Spring Boot, Kubernetes, AWS 등을 활용하여 MSA 기반 아키텍처를 구축
5. 배달의 민족
- 방식: Docker, Kubernetes, Spring Boot, AWS 등을 사용하여 MSA 환경을 구축
6. 당근 마켓
- 방식: Docker, Kubernetes, AWS, Spring Boot 등을 사용하여 MSA 환경을 구축
7. 토스
- 방식: Spring Boot, Docker, Kubernetes, AWS 등을 사용하여 MSA 기반 아키텍처를 구축
8.삼성전자
- 클라우드 네이티브를 통해서 글로벌 데이터 운영 효율화
- 삼성 스마트폰, IoT 기기 관리 시스템에 클라우드 네이티브 기반 아키텍처 적용
9. SK텔레콤
- AI 및 IoT 플랫폼(T전화, 누구(NUGU) 등)을 클라우드 네이티브로 개발
- 컨테이너 기반 인프라와 MSA를 활용하여 실시간 서비스 대응
10. LG GNS
- 공공기관 및 민간기업 대상으로 클라우드 전환 프로젝트 수행
- 자체 클라우드 플랫폼에서 Kubernetes와 DevOps 기술 활용
11. KT
- KT 클라우드에서 클라우드 네이티브 기술을 통해 대규모 네트워크 관리 및 5G 서비스 지원
- 공공 데이터센터 사업에도 클라우드 네이티브 지원
굳이 소규모 프로젝트를 진행하는 우리가 이 패턴을 이용할 필요가 있을까..?
물론 MSA는 대기업에서 주로 사용되는 아키텍처이다.
특히 대규모 트래픽 처리와 유연한 확장성을 제공하기 때문에 대기업에 유리한데 요즘에는 중소기업이나 스타트업에서도 MSA를 채택하는 경우가 많아지고 있다고 한다.
MSA를 프로젝트에서 경험해보면 좋은 이유
- 대규모 시스템 아키텍처에대한 이해
- 독립적인 서비스 관리 경험
- 클라우드 환경 활용 배양
- 배포 자동화와 CI/CD 경험
- API 설계 및 문서화 경험
- 장애 대응 및 복구 전략 경험
- 팀워크 및 협업
- 복잡한 시스템 관리 및 모니터링 경험
- 트렌드에 맞는 최신 기술 습득
- 애자일 및 DevOps 문화 경험
그래서 경험해보고 싶은 기술, 패턴?
(이건 상황에 맞춰서 적용해야할 것 같다)
DDD(Domain-Driven Design)
: 설계 철학이나 소프트웨어 개발 방법론이다. 도메인 지식과 기술적 설계를 조화롭게 결합하는 접근 방식이다.
우리가 했던 것과 차이점?
- 데이터 중심 설계
- 엔티티(Entity)가 데이터베이스 테이블과 1:1 매핑되어 데이터 구조를 기반으로 설계가 진행됩니다.
- 비즈니스 로직이 도메인 객체(Entity) 안에 포함되지 않고, 주로 Service 계층에서 처리됩니다.
- 서비스 계층 중심 로직
- 비즈니스 로직이 Entity가 아닌 Service 계층에 집중되어 있습니다.
- 엔티티는 데이터를 저장하거나 가져오는 역할만 하고, 도메인 개념이 약합니다.
(이런 설계를 **빈약한 도메인 모델(Anemic Domain Model)**이라고도 합니다.)
- 모놀리식 특징
- 모든 기능이 하나의 모듈 또는 애플리케이션에 통합되어 배포됩니다.
- 도메인 단위로 나눈 것처럼 보여도, 실제로는 모든 것이 하나의 애플리케이션으로 동작하기 때문에 모놀리식 아키텍처에 해당합니다.
전통적인 방식의 장점
- 간단한 프로젝트에 적합: 학습곡선이 낮고, 빠르게 개발 가능.
- 구조가 직관적: 계층별로 역할이 명확해 이해하기 쉽습니다.
- 빠른 CRUD 개발: 대부분의 로직이 데이터베이스 중심으로 동작하므로, CRUD 중심 작업에서 생산성이 높습니다.
한계점
- 응집도와 결합도 문제:
- 서비스 계층이 여러 엔티티와 의존성을 가지면, 변경 시 다른 부분에 영향을 미치기 쉽습니다.
- 비즈니스 로직이 여러 서비스 계층에 분산되면서 관리가 어려워집니다.
- 확장성의 어려움:
- 새로운 비즈니스 요구사항이 추가되면 기존 구조를 변경해야 하는 경우가 많습니다.
- 특히, MSA로 전환하려면 많은 리팩토링이 필요합니다.
| 구분 | 우리가 했던 방식 | DDD |
| 설계 중심 | 데이터베이스 또는 트랜잭션 중심 | 도메인(비즈니스 로직) 중심 |
| 비즈니스 로직 위치 | 서비스 계층에 산발적으로 존재 | 엔티티와 값 객체 중심 |
| 응집도 | 낮음 | 높음 |
| 유지보수 | 구조 변경 시 전체 영향 | 도메인 중심으로 영향 최소화 |
| 초점 | 데이터 및 작업 흐름 | 비즈니스 규칙과 도메인 이해 |
MSA에서 각 서비스는 독립적으로 배포되고 실행되는 애플리케이션 모듈이기 때문에 각 서비스는 자신만의 데이터 베이스를 가지고 자기 역할에 맞는 책임을 져야한대. 이런 맥락에서 서비스 간 경계를 명확히 하는 것이 매우 중요하다.
느슨한 결합(Loose Coupling)과 높은 응집(High Cohesion)
- 느슨한 결합: 다른 서비스들 간의 결합을 최소화하여 각 서비스가 독립적으로 변경될 수 있도록 합니다.
- 높은 응집: 같은 서비스 내에서 관련된 기능과 데이터를 최대한 밀접하게 묶어 유지합니다.
따라서 MSA에서 DDD로 설계하는 것은 중요한 요소라고 볼 수 있다.
1. 서비스 간 통신 문제
gRPC, 메시징 시스템(Kafka,RabbitMQ )
MSA에서 서비스간 통신 문제를 해결하기 위해 사용된다. MSA는 서비스를 독립적으로 개발하고 배포할 수 있는 장점이 있지만, 데이터 전달과 통신이 주요한 과제로 남음.
서비스간 강한 결합 해소, 서비스 A는 메시지를 브로커에 전달하고 서비스 B는 브로커로부터 메시지를 읽어온다.
2. 서비스 배포 및 관리
kubernetes, Docker
1. Docker 필요한 이유
Docker는 애플리케이션과 의존성을 묶어서 컨테이너로 실행하는 도구.
문제점
- 환경 차이로 "내 로컬에선 잘 되는데 서버에선 안 돼"라는 상황 발생.
- 라이브러리 버전 충돌이나 설치 문제로 애플리케이션 실행 안 됨.
- 서버에 배포하려면 설치하고 설정하는 데 시간 걸림.
Docker가 해결하는 것
- 일관된 환경 제공
- 로컬, 테스트, 프로덕션 환경 동일하게 작동.
- 빠른 배포
- 컨테이너 이미지로 몇 초 만에 새로운 환경 배포 가능.
- 가벼움
- VM보다 훨씬 가볍고 빠름.
2. Kubernetes 필요한 이유
Docker만으로는 대규모 시스템 관리가 어려움. Kubernetes는 여러 컨테이너를 관리하는 도구.
문제점
- 컨테이너 100개, 1000개를 수동으로 관리하려면 힘듦.
- 컨테이너 장애 발생 시 자동 복구 안 되면 서비스 중단 위험.
- 트래픽 많아지면 수동으로 컨테이너 늘리거나 줄여야 함.
- 요청을 컨테이너로 균등 분배하는 로드밸런싱 작업 필요.
Kubernetes가 해결하는 것
- 자동 관리
- 컨테이너 자동 배포, 시작, 중지, 재시작.
- 확장성
- 트래픽 변화에 따라 컨테이너 자동으로 늘리거나 줄임.
- 로드밸런싱
- 요청을 적절히 분산 처리.
- 자원 관리
- CPU, 메모리 효율적으로 사용.
Docker와 Kubernetes 관계
- Docker: 하나의 컨테이너를 실행.
- Kubernetes: 여러 컨테이너를 조율하고 관리.
둘이 같이 쓰면 대규모 애플리케이션 운영에 필수적.
활용 예시
- Docker로 개발자가 애플리케이션과 의존성을 컨테이너로 묶어 빌드.
- Kubernetes가 여러 서버에 컨테이너 배포하고 관리.
- 트래픽 따라 컨테이너 자동으로 늘리거나 줄이고 장애 발생 시 자동 복구.
3. 서비스의 상태 관리 및 장애 복구
서비스가 분산 환경에서 여러 인스턴스로 실행되거나 장애가 발생할 수 있을 때, 상태 관리와 장애 복구가 중요 하다.
문제를 해결하려면 서비스 디스커버리, 로드 밸런싱, 장애 복구등을 관리해야 한다.
Spring Cloud 는 이러한 문제를 해결하기위해 Hystrix(서킷 브레이커), Eureka(서비스 디스커버리), Spring Cloud Config 등을 제공
4. 데이터 일관성 및 트랜잭션 문제
MSA는 데이터가 여러 서비스에 분산될 수 있기 때문에, 데이터 일관성과 트랜잭션 관리가 핵심 문제임.
여기에 사용될 수 있는 패턴들이다.
Event Sourcing, CQRS Pattern(성능 최적화와 읽기/쓰기 분리), Saga Pattern(분산 시스템에서 트랜잭션 관리)
5. 서비스간 보안 문제
OAuth 2.0 & JWT
MSA 환경에서 서비스 간에 보안을 관리하는 문제는 매우 중요함. 특히 서비스들이 네트워크를 통해 서로 통신하므로, 서비스 간의 인증과 권한 부여가 반드시 필요함.
API Gateway (Spring Cloud Gateway)
API Gateway는 모든 서비스에 대한 중앙 관리 지점을 제공하며, 요청을 라우팅하고 인증, 권한 관리, 트래픽 제어 등을 처리한다. Spring Cloud Gateway는 이를 위한 강력한 도구로, 인증/인가를 API 수준에서 관리할 수 있다.
6. 서비스간 로깅 및 트래킹
ELK Stack
Zipkin & Jaeger
'개발' 카테고리의 다른 글
| [공부] 공부하면서 왜 필요한지 생각해보기 (왜?).. @Transactional.. (0) | 2024.12.03 |
|---|---|
| Spring Cloud..? (0) | 2024.11.27 |