아키텍처 (Architecture)
아키텍처(Architecture)라는 단어가 있다.
사전적인 의미를 찾아보면 대략 “시스템의 구조, 동작, 상호작용 등을 정의한 개념적 모형”이라고 알려준다.
언뜻 봐서는 이해하기가 힘든데 간단하게 말하면 “해당 서비스가 동작하는 동작 원리”라고 생각하면 된다.
이 중에서 시스템을 구축하고 운영하는 방식에 대해서 알아보자.
모놀리식 아키텍처 (Monolithic Architecture)
정의
모놀리스 아키텍처는 하나의 애플리케이션에 모든 기능을 포함해서 개발 및 운영하는 방식이다.
그래서 프론트엔드, 백엔드, 데이터베이스, 비즈니스 로직이
하나의 애플리케이션으로 묶여 있는 결합도가 높은 방식이다.
특징
- 하나의 코드 베이스와 배포 단위
- 단일 프로세스로 실행
- 모든 기능이 한 프로젝트에 통합됨
장점
- 개발과 배포가 간단하다.
- 코드가 한 곳에 모여 있기 때문에 관리하기 쉽고, 초기 개발이 빠르다.
- 성능 최적화가 용이하다.
- 내부에서 모든 기능이 직접 호출되므로 네트워크 지연이 없다.
- 트랜잭션 관리가 쉽다.
- 단일 데이터베이스 사용으로 일관성 유지가 가능하다.
- 운영과 모니터링이 간편하다.
- 모든 기능이 하나의 애플리케이션 내에 존재하기 때문에 가능하다.
단점
- 확장성 문제
- 사용자가 특정 기능만 많이 사용한다면 어떨까?
- 해당 기능만 확장하고 싶어도 전체 시스템을 함께 확장해야 한다.
- 배포에 부담감이 크다.
- 사소한 변경 사항이 있어도 전체 애플리케이션을 다시 빌드하고 배포해야 한다.
- 점차 코드 복잡도가 높아진다.
- 서비스 규모가 커질 수록 하나의 프로젝트에 코드가 많이 쌓이면서 유지보수가 어려워질 수 있다.
- 기술 스택 제한이 생긴다.
- 하나의 언어나 프레임워크로만 개발해야 한다.
사용하기 좋은 경우
- 스타트업 또는 초기 개발 단계에서 빠르게 MVP(최소기능제품)를 개발해야 할 때
- 애플리케이션이 크지 않고, 팀 규모가 작아 관리가 용이할 때
- 높은 네트워크 비용이나 분산 환경이 필요하지 않을 때
모놀리스(Monolith)와 모놀리식(Monolithic)
사람들이 해당 아키텍처에 대해서 말할 때 모놀리식 아키텍처라 하기도 하고 모놀리스 아키텍처라고 하기도 하는데,
모놀리스 아키텍처라고 발음하는 경우가 주변에서는 좀 더 많았었다.
그런데 글로 적을 떄는 Monolithic Architecture라고 명시하는 경우가 많았다.
영문으로는 모놀리식이 맞는 것 같은데 어차피 뜻은 통하니
알아서 알아 들어면 될 것 같다.
마이크로서비스 아키텍처 (Microservice Architecture)
정의
마이크로서비스 아키텍처는 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발 및 운영하는 방식이다.
이름에서부터 알 수 있듯이 마이크로(micro, 미세한)한 단위로 서비스를 나눠서 관리한다.
각 서비스는 특정 기능만을 담당하며 각 서비스끼리는 주로 RESTful API나 메시지 큐를 통해서 서로 통신한다.
각 서비스는 서로 통신하기 위해 공통되는 통신 방식이 있긴 하지만 결국 서로 분리되어 있다.
그래서 마이크로서비스 아키텍처는 결합도가 낮다.
흔히 마이크로서비스 아키텍쳐를 줄여서 MSA라고 부른다.
특징
- 독립적인 서비스 구성 (Independently Deployable Services)
- 각 서비스는 독립적으로 개발, 배포, 운영이 가능하다.
- 단일 책임 원칙 (Single Responsibility Principle)
- 각 서비스는 특정 비즈니스 기능을 담당한다.
- API 기반 통신 (API-based Communication)
- REST API, GraphQL, gRPC 등을 통해 서비스 간에 통신한다.
- 개별 데이터 저장소 (Decentralized Data Management)
- 각 서비스는 독립적인 데이터베이스를 사용한다.
- 즉, DB 공유를 지양한다.
- 지속적 배포 및 자동화 (CI/CD & Automation)
- DevOps, 컨테이너(Docker), Kubernetes 활용
- 확장성(Scalability) 및 장애 격리 (Fault Isolation)
- 특정 서비스만 확장 가능하다. 장애가 전체 시스템에 영향을 주지 않음
- 다중 기술 스택 지원 (Polyglot Tech Stack)
- 서비스마다 다른 언어와 데이터베이스 사용 가능
- 이벤트 기반 아키텍처 (Event-Driven Architecture)
- Kafka, RabbitMQ 등을 활용한 비동기 메시징 시스템 적용 가능
장점
- 확장성이 좋다.
- 사용 빈도만 높은 특정 서비스만 확장할 수 있다.
- 전체 서비스가 아니라 일부 서비스만 확장하면 되니 비용을 절감할 수 있다.
- 유지보수가 용이하다.
- 각 서비스가 분리되어 있기 때문에 독립적으로 개발과 배포가 가능하다.
- 기술 스택이 유현하다.
- 각 서비스가 분리되어 있기 때문에 서비스마다 프로그래밍 언어와 데이터베이스를 다르게 선택할 수 있다.
- 예시
- 1번 서비스 : Java + Spring + MySQL
- 2번 서비스 : Python + Django + Oracle
- 3번 서비스 : JavaScript + NodeJS + MongoDB
- 고가용성(High Availability)
- 하나의 서비스에 장애가 발생해도 전체 시스템이 멈추지 않는다.
단점
- 운영 복잡도가 높다.
- 서비스가 많아지면 그만큼 모니터링, 로깅, 트랜잭션 관리가 어려워 진다.
- 네트워크 비용이 많이진다.
- 각 서비스끼리는 별도의 통신을 주고 받아야 하기 때문에 그만큼 네트워크 비용이 많아진다.
- 통신하는 것 또한 비용이라서 모놀리식 아키텍처에 비해서 성능이 저하될 수 있다.
- 데이터 일관성에 문제가 있을 수 있다.
- 각 서비스마다 개별 데이터베이스를 사용하면 동기화가 필요하다.
사용하기 좋은 경우
- 대규모 애플리케이션을 운영하면서 확장성과 유연성이 필요한 경우
- 여러 팀이 독립적으로 서비스를 개발하고 배포해야 하는 경우
- 다양한 기술 스택을 사용하고자 할 때
예시
- 모놀리스 아키텍처인 경우
- 쇼핑몰 서비스 (단일)
- 마이크로서비스 아키텍처인 경우
- 주문 서비스
- 결제 서비스
- 인증 서비스
- 배송 서비스
클라이언트-서버(Client-Server) 아키텍처
요즘에는 리액트나 뷰를 통해서 프론트를 담당하고,
스프링이나 장고를 통해서 API를 제공하는 백을 담당하는 경우가 흔한 편이다.
그런데 프론트와 백이 각각 개발되고 배포된다고 해서
무조건 MSA인 것은 아니다.
보통 이런 경우는 클라이언트-서버(Client-Server) 아키텍처에 가깝다.
물론 백쪽에서 여러 개의 서비스로 분리되어 있다면 그건 MSA겠지만,
만약 위 케이스에서 서버가 단일 서버거나 하나의 애플리케이션을 여러 개의 인스턴스로 제공할 뿐이라면
그건 클라이언트-서버 아키텍처라고 생각하면 될 것 같다.
클라우드 네이티브 아키텍처(Cloud Native Architecture)
정의
직접 서버를 구축한다는 것은 서버 장비를 구매하고, 네트워크를 연결하는 등 그 과정이 매우 힘들다.
그래서 최근에는 아마존의 AWS나, 구글의 Google Cloud, 마이크로소프트의 Azure같은
클라우드 환경에서 운영하는 추세다.
이러한 클라우드 환경에서 운영하는 것에 초점을 맞춰서
클라우드 환경에서 최적의 성능을 발휘하도록 설계된 아키텍처가
클라우드 네이티브 아키텍처다.
단순히 클라우드에서 실행하는 것이 아니라,
컨테이너, 마이크로서비스, 오토스케일링, DevOps 등
클라우드 친화적인 기술을 적극적으로 활용하는 방식이다.
특징
- 컨테이너 기반 (Containerization)
- Docker, Kubernetes를 활용하여 애플리케이션을 컨테이너 단위로 패키징 및 배포한다.
- 환경 독립성이 보장되어, 어디서든 실행이 가능하다.
- 마이크로서비스 (Microservices)
- 애플리케이션을 독립적인 서비스 단위로 나누어 개발 및 운영할 수 있다.
- API 또는 메시지 큐(Kafka, RabbitMQ)를 통해 통신한다.
- 오토스케일링(Auto-Scaling)과 탄력적 인프라(Elastic Infrastructure)
- 트래픽 변화에 따라 자동 확장 및 축소가 가능하다.
- 서버리스(Serverless) 환경을 활용할 수 있다.
- AWS Lambda나 Google Cloud Functions 등이 해당한다.
- DevOps 및 CI/CD
- Jenkins, GitHub Actions, ArgoCD 등을 활용한 자동화된 빌드 및 배포가 가능하다.
- 빠른 업데이트와 운영 효율성 극대화가 가능하다.
- 셀프 힐링(Self-Healing) 및 장애 복구(Auto-Recovery)
- Kubernetes의 헬스체크(Health Check) 기능을 활용하여 장애 발생 시 자동 복구가 가능하다.
장점
- 높은 확장성(Scalability)
- 오토스케일링을 통해 트래픽 증가에 따라 자동 확장
- 컨테이너 오케스트레이션(Kubernetes)으로 리소스 최적화
- 빠른 배포 및 운영 효율성
- DevOps, CI/CD를 활용하여 배포 시간 단축
- 마이크로서비스 기반으로 독립적인 기능 업데이트 가능
- 장애 발생 시 자동 복구(Self-Healing)
- 컨테이너 자동 재시작(Kubernetes Health Check)
- 서버 장애 시 자동으로 다른 서버에서 복구
- 비용 최적화(Cost Optimization)
- 필요한 만큼만 자원 사용하여 비용 절감
- 서버리스(Serverless) 아키텍처로 유휴 리소스 제거
- 클라우드 간 이동성(Multi-Cloud 지원)
- AWS, Google Cloud, Azure 등 여러 클라우드에서 운영 가능
단점
- 높은 복잡도(Complexity)
- 여러 개의 마이크로서비스와 컨테이너를 관리해야 한다.
- 서비스 간 통신(API Gateway, Service Mesh) 및 데이터 일관성 유지가 필요하다.
- 네트워크 비용(Network Overhead) 증가
- 서비스 간 API 호출이 많아져 네트워크 트래픽 증가한다.
- 트랜잭션 처리 속도 저하가 있을 수 있다.
- 보안(Security) 이슈
- 컨테이너 및 API 노출로 인해 보안 관리가 필요하다.
- 멀티 클라우드 환경에서는 클라우드 간 데이터 보호가 필요하다.
- 초기 설정 및 운영 부담
- Kubernetes, Terraform, CI/CD 파이프라인 등 복잡한 인프라 구축 필요하다.
- DevOps 및 SRE(Site Reliability Engineering) 전문가가 필요할 수 있다.
클라우드 네이티브 애플리케이션 (Cloud Native Application)
정의
클라우드 네이티브 아키텍처를 적용해 개발 및 운영하는 애플리케이션
12 Factors란?
- 클라우드 네이티브 애플리케이션을 개발하거나 운영할 떄 고려해야 하는 12가지 항목
- 2011년에 클라우드 서비스 전문 기업인 Heroku의 공동 창업자인 Adam Wiggins가 발표하였다.
12 Factors의 종류
- 코드베이스 (Codebase)
- 하나의 코드 저장소를 유지한다.
- 개발, 스테이징, 운영 등의 여러 배포 환경에서 같은 코드 저장소를 공유한다.
- 종속성 관리 (Dependencies)
- 모든 의존성을 명확히 선언하고, 시스템에 의존하지 않고 자체적으로 해결한다.
- 패키지 매니저 등을 통해 해결한다.
- 설정 (Config)
- DB URL, API 키같은 환경별 설정을 코드가 아닌 환경 변수로 관리한다.
- 백엔드 서비스 (Backing Services)
- DB, 메시지 브로커, 캐시 등의 외부 서비스를 독립적인 리소스로 취급하여 변경 가능하도록 유지한다.
- 빌드, 릴리스, 실행 (Build, Release, Run)
- 배포는 배포라는 하나의 단계가 아닌 3개의 단계로 분리하여 관리한다.
- 빌드(코드 컴파일) → 릴리스(설정 적용) → 실행(프로세스 실행)
- 프로세스 (Processes)
- 애플리케이션을 하나 이상의 독립적인 실행 가능한 프로세스로 구성한다.
- 무상태(Stateless) 방식을 권장한다.
- 포트 바인딩 (Port Binding)
- 특정 포트에 바인딩하는 포트 바인딩 방식을 통해 서비스를 공개한다.
- 여러 가지 케이스때문에 제시되었다.
- 스프링 부트같이 내장 서버에서 실행되는 경우
- 리액트처럼 별도의 서버를 연결하는 경우
- 동시성 (Concurrency)
- 여러 개의 독립적인 프로세스를 실행하여 확장성을 확보한다.
- 독립적으로 실행하기 때문에 수직 및 수평 확장을 지원한다.
- 폐기 가능성 (Disposability)
- 빠르게 시작하고 안전하게 종료될 수 있도록 설계한다.
- 시스템 충돌 시에도 신속한 복구가 가능해진다.
- 개발/운영 환경 일치 (Dev/Prod Parity)
- 개발, 테스트, 운영 환경을 최대한 유사하게 유지하여 배포 시의 문제를 최소화한다.
- 로그 (Logs)
- 로그를 파일이 아닌 스트림(Stream)으로 관리하여 중앙 집중식 로깅 시스템을 활용한다.
- 클라우드 네이티브 아키텍처에서 서버 인스턴스는 언제든지 새로 생성되거나 삭제될 수 있다.
- 언제 어떻게 될지 모르기 때문에 파일로 저장하지 않는다.
- ELK Stack나 Fluentd 등이 해당한다.
- 로그를 파일이 아닌 스트림(Stream)으로 관리하여 중앙 집중식 로깅 시스템을 활용한다.
- 관리자 프로세스 (Admin Processes)
- 배포, 마이그레이션, 관리 작업은 일회성 프로세스로 실행한다.
12 Factors의 순서
- 12 Factors의 순서는 중요도가 아닌 적용 순서나 개발 과정에 따른 자연스러운 흐름에 따라 나열됬다.
- 기본 원칙
- 1 ~ 4
- 배포 및 실행
- 5 ~ 7
- 확장성 & 복구
- 8 ~ 9
- 운영 및 관리
- 10 ~ 12
15 Factors란?
- 기존의 12 Factors에서 3가지 항목이 추가된 형태
- 클라우드 서비스 전문 기업인 Pivotal에서 발표하였다.
12 Factors에서 추가된 항목
- API 우선(API First)
- 서비스 간 통신을 위한 API를 먼저 설계하고 개발헤야 한다.
- REST, GraphQL, gRPC 등
- 텔레메트리(Telemetry, 관측 가능성)
- 애플리케이션의 상태를 모니터링할 수 있도록 로그, 메트릭, 트레이싱을 수집해야 한다.
- Prometheus, Grafana, OpenTelemetry 등을 활용
- 인증과 권한 (Authentication and Authorization)
- 모든 서비스와 데이터에 대해 보안 원칙을 적용해야 한다.
- 암호화, 인증, 권한 관리, 보안 패치 등
서비스 오리엔테이드 아키텍처 (Service Oriented Architecture, MSA)
정의
비즈니스 기능을 서비스 단위로 나누어 구성하는 아키텍처
특징
- 여러 개의 서비스가 ESB(Enterprise Service Bus) 같은 중앙 허브를 통해 통신하는 구조를 가진다.
- 서비스 간의 재사용성이 높다.
- 여러 애플리케이션에서 동일한 서비스를 사용할 수 있다.
- 표준화된 통신 방식을 사용한다.
- SOAP, XML, WSDL을 주로 사용한다.
MSA와의 차이점
MSA는 각 서비스가 독립적으로 실행되며 서비스마다 별도의 DB를 사용하지만,
SOA는 각 서비스가 공통적인 방식으로 구성되며 DB를 공유한다.
SOA와 MSA 모두 서비스 지향 설계 방식이긴 하나,
보다 민첩하고 유연한 구조가 필요한 환경에서는 SOA가 적합하다.
Spring Cloud란?
정의
MSA 환경에서 분산 시스템을 쉽게 구축하고 운영할 수 있도록
스프링 진영에서 지원하는 스프링 기반 프레임워크
역할
- MSA에서 공통적으로 필요한 기능 제공
- Netflix OSS, k8s, Spring Boot와 연동
- 클라우드 네이티브 애플리케이션 개발 지원
스프링 클라우드의 주요 컴포넌트
- 서비스 디스커버리 (Eureka)
- 마이크로서비스를 자동으로 등록하고 찾을 수 있도록 도와줌
- Netflix Eureka 사용 (Consul, Zookeeper도 가능)
- API Gateway (Spring Cloud Gateway)
- 클라이언트 요청을 적절한 서비스로 라우팅
- 필터 적용 가능 (인증, 로깅, 요청 변환 등)
- 분산 구성 관리 (Spring Cloud Config)
- 설정 파일을 중앙에서 관리하여 모든 서비스에 자동 배포
- Git 저장소와 연동하여 설정 변경 가능
- 로드 밸런싱 (Ribbon)
- 여러 인스턴스가 있을 때 자동으로 트래픽을 분배
- 장애 감지 및 복구 (Resilience4j)
- 회로 차단기(Circuit Breaker) 패턴 적용 → 장애 발생 시 빠른 복구 가능
- 분산 추적 (Sleuth + Zipkin)
- 마이크로서비스 간 호출을 추적하여 성능 분석 및 디버깅 가능
장점
- MSA 개발 속도 향상
- 필요한 기능을 쉽게 추가할 수 있다.
- Netflix OSS와 완벽한 통합
- 대규모 트래픽 처리가 가능하다.
- k8s와 연동 가능
- 클라우드 환경에서 유연한 운영이 가능하다.
단점
- 학습 곡선이 있다.
- 다양한 모듈들에 대해서 이해해야 한다.
- 운영 복잡도가 증가한다.
- 애플리케이션 규모가 커질 수록 관리가 어려워진다.