개발자공부일기
백엔드 아키텍처 본문
백엔드 아키텍처의 중요성
현대의 소프트웨어 개발에서 백엔드 아키텍처는 시스템의 성능, 확장성, 유지보수성을 결정짓는 핵심 요소입니다. 왜냐하면 백엔드 아키텍처가 잘 설계되어 있지 않으면, 애플리케이션의 성능 저하, 확장 곤란, 유지보수 어려움 등의 문제가 발생할 수 있기 때문입니다.
현대적인 백엔드 아키텍처는 이러한 문제들을 해결하기 위해 모듈성, 재사용성, 테스트 용이성을 고려하여 설계됩니다. 이는 애플리케이션의 신속한 개발과 효율적인 운영을 가능하게 합니다.
백엔드 아키텍처를 설계할 때는 시스템의 요구 사항과 목표를 명확하게 이해하는 것이 중요합니다. 왜냐하면 아키텍처는 이러한 요구 사항과 목표를 충족시키기 위한 해결책을 제공하기 때문입니다.
또한, 현대적인 아키텍처 설계는 지속적인 변화와 기술의 진화에 유연하게 대응할 수 있어야 합니다. 따라서, 변경 용이성과 기술 독립성도 중요한 설계 원칙 중 하나입니다.
백엔드 아키텍처는 애플리케이션의 기술적 토대를 이루기 때문에, 설계 초기 단계부터 철저한 계획과 고민이 필요합니다. 이는 프로젝트의 성공을 좌우하는 결정적인 요소가 됩니다.
현대적인 백엔드 아키텍처의 특징
현대적인 백엔드 아키텍처는 마이크로서비스, 서버리스, 컨테이너화와 같은 패러다임을 포함합니다. 이러한 아키텍처들은 각각의 장단점을 가지며, 프로젝트의 요구 사항에 따라 적절히 선택되어야 합니다.
마이크로서비스 아키텍처는 시스템을 작고 독립적인 서비스 단위로 분할하여 각 서비스가 하나의 비즈니스 기능을 담당하도록 하는 것입니다. 이는 시스템의 복잡성을 관리하고, 개발 및 배포의 효율성을 높일 수 있습니다.
서버리스 아키텍처는 인프라의 관리를 클라우드 서비스 제공자에게 위임하여 개발자가 애플리케이션 로직에 더 집중할 수 있게 하는 것입니다. 이는 운영 비용을 절감하고 확장성을 높일 수 있는 장점을 가집니다.
컨테이너화는 애플리케이션과 그 종속성을 컨테이너로 패키징하여, 어떤 환경에서도 일관된 실행을 보장하는 것입니다. 이는 개발, 테스트, 운영 환경의 일관성을 제공하고, 이식성을 향상시킵니다.
데이터 관리와 보안도 현대적인 백엔드 아키텍처 설계에서 중요한 요소입니다. 분산 시스템에서의 데이터 일관성, 보안 및 개인 정보 보호는 필수적으로 고려되어야 합니다.
이러한 특징들은 현대적인 백엔드 아키텍처를 구성하는 주요 요소이며, 시스템의 성능과 안정성, 개발 및 운영의 편리성을 결정짓습니다.
잘 설계된 백엔드 아키텍처의 이점
잘 설계된 백엔드 아키텍처는 개발의 속도와 효율성을 높여줍니다. 왜냐하면 각 컴포넌트가 명확한 역할과 책임을 가지며, 코드의 재사용성과 테스트 용이성이 향상되기 때문입니다.
또한, 시스템의 확장성과 유연성도 크게 증가합니다. 마이크로서비스와 같은 아키텍처를 채택함으로써, 시스템은 변화하는 비즈니스 요구 사항에 빠르게 대응할 수 있습니다.
재해 복구와 운영의 복잡성 관리 측면에서도 이점을 제공합니다. 컨테이너화와 클라우드 기반 인프라를 활용하여 시스템의 안정성을 높이고, 운영의 복잡성을 줄일 수 있습니다.
보안 측면에서도 현대적인 백엔드 아키텍처는 중요한 역할을 합니다. 안전한 데이터 처리와 전송, 접근 제어 등 다양한 보안 요구 사항을 충족시키도록 설계됩니다.
결론적으로, 잘 설계된 백엔드 아키텍처는 비즈니스의 성공을 위한 견고한 기반을 제공합니다. 이는 애플리케이션의 성능, 확장성, 유지보수성을 극대화하며, 개발 및 운영 비용을 절감할 수 있습니다.
백엔드 아키텍처의 종류
1️⃣ 마이크로서비스 아키텍처 (Microservices Architecture)
작동 원리:
마이크로서비스 아키텍처의 핵심은 분해입니다. 거대한 모놀리식 애플리케이션을 만드는 대신, 특정 작업을 처리하는 독립적인 작은 서비스로 애플리케이션을 분리합니다.
각 서비스는:
- 자신의 데이터베이스를 가집니다. 데이터 관리의 분산을 강조하며, 각 서비스는 서비스별 데이터베이스 패턴을 따릅니다.
- API를 통해 상호작용합니다 (일반적으로 HTTP/REST, gRPC 또는 메시징 큐 사용). 이러한 상호작용은 무상태로, 각 서비스는 이전 요청에 대한 정보를 유지하지 않습니다.
- 독립적으로 배포됩니다. 각 마이크로서비스는 다른 기술을 사용할 수 있어 필요한 도구를 선택할 수 있는 유연성을 제공합니다 (예: Node.js는 API, Java는 비즈니스 로직).
구성 요소:
- 서비스 레지스트리: 모든 마이크로서비스가 등록되고 서로를 발견하는 장소입니다.
- API 게이트웨이: 클라이언트가 모든 마이크로서비스에 접근할 수 있는 단일 진입점입니다. 로드 밸런싱, 인증, 요청 라우팅 등을 처리합니다.
- 이벤트 버스 (optional): 서비스들이 비동기적으로 통신할 수 있도록 이벤트를 전달합니다.
예시 워크플로우 (전자상거래 플랫폼):
- 사용자 서비스(마이크로서비스 1)는 사용자 정보를 관리합니다. 사용자가 로그인하면 API 게이트웨이가 요청을 사용자 서비스로 라우팅합니다.
- 주문 서비스(마이크로서비스 2)는 주문을 처리합니다. 사용자가 주문을 하면 주문 서비스는 재고 서비스(마이크로서비스 3)에 호출하여 재고를 확인합니다.
- 결제 서비스(마이크로서비스 4)는 결제를 처리하고, 결제가 성공하면 알림 서비스(마이크로서비스 5)를 호출하여 사용자에게 확인 이메일을 보냅니다.
- 각 서비스는 독립적으로 확장할 수 있습니다. 예를 들어, 주문이 급증하면 주문 서비스만 확장하면 됩니다.
2️⃣ 계층형 아키텍처 (Layered Architecture, N-Tier Architecture)
작동 원리:
레이어드 아키텍처는 애플리케이션을 레이어로 나누어 각 레이어가 명확한 책임을 가지고 인접한 레이어와만 상호작용하게 구성됩니다:
- 프리젠테이션 레이어: 사용자 상호작용을 처리하고 정보를 표시합니다 (UI).
- 비즈니스 로직 레이어: 애플리케이션의 핵심 기능을 포함하며 데이터를 처리하고 비즈니스 규칙을 실행합니다.
- 데이터 접근 레이어: 애플리케이션과 데이터 저장소(예: 데이터베이스) 사이의 인터페이스 역할을 합니다. 이 레이어는 애플리케이션이 데이터에 접근할 수 있도록 돕고, 데이터베이스와의 직접적인 상호작용을 추상화하는 역할을 합니다.
- 퍼시스턴스 레이어:데이터의 영속성을 담당하는 레이어로, 데이터가 어디에 저장되고 어떻게 관리되는지에 대한 세부 사항을 다룹니다. 이 레이어는 데이터가 실제로 어디에 저장되고 어떻게 읽고 쓰이는지에 대한 구체적인 구현을 포함합니다.
각 레이어는 독립적이며, 상호작용은 위에서 아래로 또는 아래에서 위로 이루어집니다. 이를 통해 시스템이 잘 구조화되어 각 레이어가 특정 역할을 담당하게 됩니다.
예시 워크플로우:
콘텐츠 관리 시스템(CMS) 예시:
- 사용자가 페이지를 요청하면 프리젠테이션 레이어(웹 브라우저)가 요청을 보냅니다.
- 프리젠테이션 레이어는 비즈니스 로직 레이어에 요청을 보내어 페이지의 데이터를 처리합니다.
- 비즈니스 로직 레이어는 필요한 데이터를 데이터 접근 레이어에서 가져옵니다 (예: 데이터베이스에서 기사나 사용자 정보를 조회).
- 데이터 접근 레이어는 데이터베이스와 상호작용하여 결과를 비즈니스 로직 레이어로 반환하고, 이 데이터는 다시 프리젠테이션 레이어로 전달됩니다.
- 프리젠테이션 레이어는 데이터를 사용자에게 표시합니다.
실제 예시:
- 은행 시스템:
- 프리젠테이션 레이어는 웹 또는 모바일 앱일 수 있습니다.
- 비즈니스 로직 레이어는 잔액 확인, 송금 유효성 검사 등의 규칙을 처리합니다.
- 데이터 접근 레이어는 은행의 데이터베이스와 상호작용하여 계좌 잔액이나 거래 내역을 조회합니다.
3️⃣ 서버리스 아키텍처 (Serverless Architecture)
작동 원리:
서버리스 아키텍처에서 애플리케이션은 stateless 함수(일명 serverless 함수)로 구성됩니다. 이러한 함수는 이벤트에 의해 실행되며, 클라우드 제공업체가 인프라 관리(서버 프로비저닝, 스케일링, 유지 관리 등)를 처리합니다.
- stateless : 함수는 실행 후 상태를 유지하지 않습니다. 함수가 실행을 마치면 종료되고 다시 실행할 때 상태는 초기화됩니다.
- 이벤트 기반: 함수는 HTTP 요청, 파일 업로드, 데이터베이스 변경, 예약된 작업 등 다양한 이벤트에 의해 트리거됩니다.
- FaaS(Functions as a Service): 서버리스 함수는 클라우드에 배포되며 서버 관리를 할 필요가 없습니다.
- 관리형 서비스: 클라우드 제공업체가 인프라, 스케일링, 가용성 등을 관리합니다.
예시 워크플로우:
사진 공유 애플리케이션 예시:
- 사용자가 Amazon S3에 이미지를 업로드합니다.
- 업로드가 완료되면 AWS Lambda(서버리스 함수)가 트리거됩니다.
- Lambda 함수는 이미지를 처리(크기 조정, 압축 등)합니다.
- 처리된 이미지는 다시 S3에 저장되고 사용자의 프로필이 업데이트됩니다.
- 다른 서버리스 함수가 호출되어 사용자에게 알림을 보냅니다 (예: AWS SNS 사용).
핵심 개념:
- 함수 호출: 클라우드 제공업체가 특정 이벤트에 따라 자동으로 함수를 호출합니다.
- 사용한 만큼 지불: 함수 실행 시간에 대해서만 비용을 지불합니다.
4️⃣ 이벤트 기반 아키텍처 (Event-Driven Architecture)
작동 원리:
이벤트 기반 아키텍처(EDA)에서 시스템은 이벤트(상태의 변화나 업데이트)에 맞춰 설계됩니다. 구성 요소들이 비동기적으로 이벤트를 발행하고 소비합니다. 이는 실시간 업데이트나 구성 요소의 분리를 요구하는 시스템에서 사용됩니다.
- 이벤트 생성자: 이벤트를 발생시킵니다 (예: 사용자가 버튼을 클릭).
- 이벤트 소비자: 이벤트를 수신하고 반응합니다 (예: 데이터베이스 업데이트, 알림 발송).
- 이벤트 브로커: 이벤트 생성자와 소비자 간의 중개 역할을 하며, 이벤트를 소비자에게 전달합니다 (예: Kafka, RabbitMQ, AWS SNS).
예시 워크플로우:
전자상거래 플랫폼 예시:
- 사용자가 웹사이트에서 주문을 하면 주문 서비스(생성자)가 ORDER_PLACED 이벤트를 발행합니다.
- 결제 서비스와 재고 서비스(소비자)는 ORDER_PLACED 이벤트를 수신하고 각각 결제를 처리하거나 재고를 업데이트합니다.
- 배송 서비스(소비자)는 PAYMENT_SUCCESSFUL 이벤트를 수신하여 제품을 발송합니다.
실제 예시:
- Slack 또는 Discord: 이들 플랫폼은 이벤트 기반 시스템을 사용합니다. 사용자가 메시지를 보내면, 메시지가 여러 서비스(알림 시스템, 저장소, 검색 인덱싱 등)로 전달됩니다.
5️⃣ 모놀리식 아키텍처 (Monolithic Architecture)
작동 원리:
모놀리식 아키텍처에서는 애플리케이션의 모든 부분(UI, 비즈니스 로직, 데이터 접근 등)이 하나의 코드베이스로 묶여 있고, 하나의 단위로 배포됩니다. 구성 요소들은 서로 직접적으로 상호작용하며, 서버 간의 통신이나 복잡한 라우팅이 필요하지 않습니다.
- 단일 코드베이스: 모든 것이 하나의 프로젝트로 포함됩니다.
- 강한 결합: 구성 요소들 간에 의존성이 강하며, 하나의 모듈을 변경하면 다른 모듈도 수정해야 할 수 있습니다.
- 단일 배포 단위: 전체 애플리케이션은 함께 배포되며, 확장도 전체 애플리케이션을 대상으로 합니다.
예시 워크플로우:
블로그 애플리케이션 예시:
- 사용자가 프론트엔드 UI(프리젠테이션 레이어)를 통해 요청을 보냅니다.
- 프론트엔드는 직접적으로 백엔드 비즈니스 로직(비즈니스 로직 레이어)과 상호작용하여 포스트를 생성합니다.
- 백엔드는 직접적으로 데이터베이스(데이터 접근 레이어)와 상호작용하여 블로그 포스트를 조회하거나 생성합니다.
- 모든 것이 하나의 코드베이스로 패키징되어 배포됩니다.
실제 예시:
- 레거시 시스템: 은행 소프트웨어나 고객 관리 시스템과 같은 오래된 엔터프라이즈 애플리케이션들은 초기에는 모놀리식 애플리케이션으로 구축되었습니다. 이러한 앱들은 일반적으로 하나의 서버나 서버 세트에서 배포되고 모든 것을 처리합니다.
- 마이크로서비스는 애플리케이션을 작은 서비스로 나누어 API를 통해 상호작용합니다.
- 레이어드는 애플리케이션을 명확한 레이어로 나누어 각 레이어가 특정 역할을 담당합니다.
- 서버리스는 서버 관리 없이 이벤트 기반으로 작동하는 상태 없는 함수들로 시스템을 구성합니다.
- 이벤트 기반은 구성 요소들이 비동기적으로 이벤트를 통해 상호작용하도록 설계됩니다.
- 모놀리식은 모든 기능을 하나의 큰 단위로 묶어 관리합니다.