00. 오리엔테이션
01. 개발자는 무엇에 집중해야 할까 ?
- 개발자가 할 것은 서비스 및 기능에 집중!
- 프로젝트는 기획자, 운영자 , 개발자, 서버관리자, 영업
- 협력 및 AI사용 많이 하기!
02 . 이런것들도 항상 고민하면 좋아
- 나의 기술을 공유하고 긍정적 생각 가지기
- 나를 알려야 나의 가치가 올라가듯 다양한 정보를 접할 수 있다.
03 . AI의 사용
- 다양한 AI 툴 많이 사용해보기
- GPT를 통해 답변을 받을 수 있는 프롬프트들을 잘 사용하여 생산성을 올리고 더 나은 결과물을 가져올 수 있는 개발자
- 단, GPT의 사용은 때로 독이 된다. (사용하면서 무엇제 집중해야 하는지, 어떤 문제가 발생할지 생각해봐야 한다.!)
MSA에 들어가기 앞서 간단하게 알아가기
아키텍처(Architecture)란
- 소프트웨어나 시스템을 어떤 방식으로 설계하고 구성할지를 정의하는 구조
SW아키텍처 핵심 요소
- 구성 요소(Components) → 시스템을 이루는 주요 부분 (예: 서비스, 데이터베이스)
- 연결 방식(Connections) → 구성 요소들이 어떻게 통신하는지 (예: API, 메시지 큐)
- 데이터 흐름(Data Flow) → 데이터가 어떻게 이동하고 저장되는지
- 비즈니스 로직(Business Logic) → 시스템이 수행해야 할 핵심 기능
아키텍처 선택 방법
- 작은 프로젝트 ➝ 모놀리식 아키텍처
- 모든 기능이 하나의 애플리케이션으로 구성됨
- 장점: 개발 및 배포가 쉬움
- 단점: 시스템이 커지면 유지보수 어려움
✅ 하나의 애플리케이션이 웹 서버 + 비즈니스 로직 + 데이터베이스를 모두 포함
✅ Spring Boot 단일 프로젝트로 운영되는 구조
- 확장성이 필요한 서비스 ➝ 마이크로서비스 아키텍처
- 기능별로 서비스가 나누어져 있으며, 각각 독립적으로 운영됨
- 장점: 확장성과 유지보수가 쉬움
- 단점: 서비스 간 통신이 필요하여 복잡함
✅ 주문 서비스, 결제 서비스, 유저 서비스가 각각 분리됨
✅ 서비스 간 통신은 REST API, gRPC, Kafka 등을 사용
- 일반적인 웹 애플리케이션 ➝ 레이어드 아키텍처
- 애플리케이션을 Presentation(표현), Service(비즈니스 로직), Repository(데이터 접근) 3계층으로 나눔
- 장점: 구조가 명확하고 유지보수가 쉬움
- 단점: 계층이 많아질수록 성능이 저하될 수 있다
✅ Controller → Service → Repository → Database 순으로 데이터 처리
01 . MSA - 마이크로서비스 아키텍처(MicroService Architecture)
- 하나의 애플리케이션을 여러개의 독립 서비스로 분리하여 개발, 배포, 유지보수에 용이하게 하는 소프트웨어 아키텍처 스타일
- 서비스 간 서버 통신은 HTTP. HTTPS, 메시지큐 등을 통해 이루어진다.
주요 특징
(밑에서 한번 더 언급예정)
독립적인 배포 가능성
- 각 서비스는 독립적으로 배포할 수 있으며, 다른 서비스에 영향을 주지 않고 업데이트할 수 있다.
- 각각의 애플리케이션, 데이터베이스 (Order, Product, User)을 가진다.
소규모 팀 구성
- 각 서비스는 소규모 팀이 독립적으로 개발하고 관리할 수 있다.
기술 스택의 다양성
- 각 서비스는 적절한 기술 스택을 자유롭게 선택할 수 있다.
모놀리틱 아키텍처 (Monolithic Architecture) 와 MSA(MicroService Architecture) 비교
모놀리틱 아키텍처 구조
모놀리틱 아키텍처 장단점
| 장점 | 단점 |
| 간단한 배포 - 하나의 코드베이스에 모든 코드가 들어있어서 배포가 단순하다. 단일 데이터베이스 - 하나의 데이터베이스를 사용하여 데이터 일관성을 유지가 쉽다. |
확장성 부족 - 특정기능 하나 확장하려면 전체 애플리케이션을 확장 긴 개발 주기 - 작은 변경 사항으로 전체 애플리케이션을 다시 배포 유연성 부족 - 새로운 기술 도입이 어렵다, 특정 모듈에 종속적이다. |
마이크로서비스 아키텍처 구조
마이크로서비스 아키텍처 장단점
| 장점 | 단점 |
| 확장성 - 특정 서비스만 확장하여 성능 최적화할 수 있다. 독립적 배포 - 각 서비스는 독립적으로 배포 가능 소규모 팀 구성 - 각 서비스는 작은 팀이 독립적으로 개발하고 관리할 수 있다. 기술 스택의 다양성(유연성) - 각 서비스는 적절한 기술 스택을 자유롭게 선택할 수 있다. |
복잡성 - 서비스가 많아지면 관리할게 많아진다.(배포, 장애처리 등) 운영 비용 증가 - 각 서비스마다 DB, 서버, 모니터링 도구가 따로 필요 데이터 관리 어려움 - 여러 서비스에 데이터 일관성 유지가 힘들다.(분산 트랜잭션 문제) 네트워크 지연 - 서비스 간 통신이 많아져서 API호출 속도 저하 |
처음 개발을 한다면 모놀리틱 아키텍처를 추천한다.
애플리케이션의 대규모 확장을 해야될 정도로 커진다면 MSA를 추천하지만 처음부터 MSA로 시작한다면 많은 자원을 필요로 하여 운영 비용이 증가하게 되고, 구현하는데 있어서 많은 시간이 지체하게 된다.
모놀리식으로 시작해서 프로토타입 애플리케이션을 잡고, MSA로 하나씩 기능을 쪼개는 방식을 대부분 기업에서 하고 있다고 한다.
(유광열 튜터님 조언)
'인프라 기술 및 아키텍처' 카테고리의 다른 글
| 04. MSA - 클라이언트 사이드 로드 밸런싱 (FeignClient와 Ribbon) (0) | 2025.03.13 |
|---|---|
| 03. MSA - 서비스 디스커버리(Eureka) (0) | 2025.02.12 |
| SQL Query 문법 (0) | 2025.02.11 |
| 02. MSA - Spring Cloud (0) | 2025.02.08 |