백엔드 아키텍처는 웹 애플리케이션 백엔드가 구조화되는 방식을 나타냅니다. 백엔드 아키텍처는 수신 요청을 처리하고 응답을 만들기 위해 애플리케이션의 일부가 서로 통신하는 방식을 결정합니다. 웹 애플리케이션을 빌드할 때는 비용 (지속적 및 규모에 따른 비용), 애플리케이션의 복잡성, 확장 목표, 팀의 전문성과 같은 특정 요구사항과 요소를 기반으로 백엔드 아키텍처를 선택하세요.
특히 전자상거래, 신문, 블로그와 같은 콘텐츠 기반 웹 애플리케이션의 경우 특히 애플리케이션이 글로벌 규모로 성장하고 더 분산될 수 있으므로 데이터 및 성능의 일관성이 중요합니다. 콘텐츠 기반 웹 애플리케이션의 경우 애플리케이션에서 사용하는 데이터 저장소도 매우 중요하며, 이에 대해서는 데이터 저장소 가이드에서 자세히 설명합니다. 앱 성능을 최적화할 때는 일반적인 애플리케이션 아키텍처를 넘어 콘텐츠를 호스팅하고 액세스 가능하게 만드는 것이 중요합니다. 호스팅 가이드에서 올바른 호스팅 전략 선택 및 앱 최적화에 관해 자세히 알아보세요.
웹 애플리케이션의 기존 백엔드가 있는 경우 현재 아키텍처의 제한사항을 고려하세요. 예를 들어 애플리케이션이 확장되고 성능 및 안정성에 대한 수요가 증가함에 따라 애플리케이션의 일부를 리팩터링해야 하는지 또는 증가된 규모에 더 적합한 다른 아키텍처로 이동해야 하는지 고려하세요. 예를 들어 하이브리드 (또는 멀티 클라우드) 아키텍처를 사용하면 완전한 전환을 수행하기 전에 일부 워크로드를 클라우드로 이전할 수 있습니다. 이러한 마이그레이션과 관련된 비용, 시간, 위험을 고려하는 것도 필수적입니다.
모놀리식 아키텍처
모놀리식 아키텍처는 애플리케이션의 모든 구성요소가 단일 코드베이스에 긴밀하게 통합된 통합 구조를 갖습니다. 전체 애플리케이션은 하나의 독립된 유닛으로 빌드됩니다. 모놀리식 아키텍처는 애플리케이션의 여러 계층이 특정 작업을 수행하는 다중 계층입니다.
구조 레이어
- 애플리케이션의 기능을 표시하는 구성요소를 포함하는 사용자 인터페이스 (UI)는 일반적으로 사용자와 상호작용하는 웹 기반 또는 데스크톱 애플리케이션입니다.
- 애플리케이션 로직은 핵심 기능이 있는 곳입니다.코드베이스의 이 부분에는 애플리케이션의 작동 방식을 정의하는 규칙, 계산, 작업이 포함됩니다.
- 데이터 액세스 레이어에는 데이터를 읽고 쓰고 애플리케이션의 데이터 구조와 데이터베이스 스키마를 변환하는 함수가 포함되어 있습니다. 이 계층은 애플리케이션의 데이터베이스 또는 데이터 저장소와 상호작용을 담당합니다
- 데이터베이스는 애플리케이션이 데이터를 저장하는 곳입니다. 일반적으로 사용자 데이터, 구성 및 기타 정보를 포함하여 애플리케이션의 모든 데이터를 저장하는 단일 데이터베이스가 있습니다.
- 미들웨어 구성요소는 인증, 요청 라우팅, 데이터 유효성 검사와 같은 작업을 처리합니다. 이러한 구성요소는 데이터 및 요청의 흐름을 관리하는 데 도움이 됩니다.
- 일부 모놀리식 애플리케이션에는 외부 서비스나 API와의 통합 지점이 있습니다. 이러한 지점을 통해 애플리케이션은 서드 파티 서비스, 데이터 소스 또는 기타 시스템과 상호작용할 수 있습니다.
구조적 레이어는 일반적으로 단일 코드베이스의 일부입니다. 이 코드베이스는 전체 애플리케이션을 포함하며 일반적으로 디렉터리, 모듈, 클래스로 구성됩니다. 개발자는 코드베이스의 다양한 부분에서 애플리케이션을 빌드하고 유지관리합니다. 그러나 전체 애플리케이션은 일반적으로 단일 단위로 배포됩니다. 업데이트하거나 변경하면 전체 애플리케이션이 다시 배포됩니다.
잠재적 과제
- 모놀리식 애플리케이션이 성장함에 따라 코드베이스가 복잡해지고 유지 관리하기가 어려워지는 경향이 있습니다. 이로 인해 개발 주기가 길어지고 전체 코드베이스를 이해하기 어려울 수 있습니다.
- 모놀리식 애플리케이션에 변경사항을 배포하는 것은 위험할 수 있습니다. 코드의 한 부분에서 변경한 내용이 애플리케이션의 다른 부분에 의도치 않게 영향을 미칠 수 있기 때문입니다. 이로 인해 시간이 오래 걸리고 오류가 발생하기 쉬운 배포 프로세스가 생성될 수 있습니다.
- 모놀리식 애플리케이션은 단일 단위로 배포되므로 확장하기 어려울 수 있습니다. 구성요소 중 하나에서만 수요가 증가하더라도 전체 애플리케이션을 확장해야 합니다.
- 모놀리식 애플리케이션은 단일 기술 스택 또는 프로그래밍 언어에 의존하는 경우가 많으므로 애플리케이션 내의 특정 작업에 가장 적합한 도구를 사용하는 기능이 제한될 수 있습니다.
- 수요가 적은 기간에도 모놀리식 애플리케이션을 운영하려면 상당한 리소스가 필요합니다. 또한 회귀를 일으키지 않고 애플리케이션을 업데이트하고 패치하기가 더 어려워지므로 애플리케이션이 오래됨에 따라 유지보수 비용도 증가합니다.
- 모놀리식 애플리케이션을 개발하는 개발팀은 애플리케이션 전체를 중심으로 구성되는 경우가 많으므로 팀 규모가 커지고 팀원 간의 조정이 더 복잡해집니다.
권장 용도
모놀리식 아키텍처는 애플리케이션의 요구사항이 적고 개발팀의 규모가 작은 경우에 적합합니다. 애플리케이션의 복잡성과 규모가 커지거나 애플리케이션의 여러 부분에 다른 기술 또는 배포 전략이 필요한 경우 모놀리식 아키텍처는 유연성이 떨어지고 유지보수가 더 어려워질 수 있습니다.
Compute Engine에서 모놀리식 애플리케이션을 실행할 수 있는 가상 머신을 만들고 관리할 수 있습니다. 사용자는 이러한 가상 머신의 운영체제, 소프트웨어, 관리를 완전히 제어하여 모놀리식 애플리케이션을 실행할 수 있습니다.
App Engine과 같은 Platform as a Service(서비스형 플랫폼) 서비스를 사용하면 요청에 따라 자동으로 확장되는 완전 관리형 인프라에서 애플리케이션을 빌드하고 실행할 수 있습니다.
모놀리식 애플리케이션이 컨테이너화된 경우 Google Kubernetes Engine (GKE) 또는 Cloud Run을 사용하여 실행할 수 있습니다. Cloud SQL 또는 Cloud Spanner와 같은 서비스를 사용하여 모놀리식 애플리케이션의 데이터를 저장할 수 있습니다. 애플리케이션의 특정 요구사항에 따라 서비스와 시스템의 조합을 고려하세요.
서버리스 아키텍처
서버리스 아키텍처를 사용하면 물리적 또는 가상 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있습니다. 클라우드 제공업체가 인프라, 확장, 리소스 할당을 자동으로 관리하므로 개발자는 애플리케이션 코드 작성에 집중할 수 있습니다. 서버리스 아키텍처는 서버를 유지보수할 필요가 없으므로 개발을 간소화하고 운영 오버헤드를 줄이며 비용을 최적화할 수 있습니다. 또한 마이크로서비스, 실시간 데이터 처리, 워크로드가 가변적인 웹 애플리케이션, 이벤트 처리에 적합합니다.
이벤트 기반 서버리스 아키텍처
이벤트 기반 서버리스 아키텍처는 이벤트 또는 트리거를 사용하여 함수 또는 마이크로서비스의 실행을 시작하는 특정 유형의 서버리스 컴퓨팅 아키텍처입니다. 시스템 구성요소는 이벤트를 통해 통신하며, 이벤트는 이벤트에 대한 응답으로 호출됩니다. 이러한 함수는 종종 비동기 통신에 의존합니다. 함수가 이벤트에 의해 트리거된 후 독립적으로 처리되고, 후속 작업을 트리거하는 이벤트를 생성할 수 있기 때문입니다. 이 유형의 서버리스 아키텍처는 확장 가능하고 응답성이 높으며 느슨하게 결합된 시스템을 빌드하는 데 적합한 옵션입니다.
Google Cloud Functions 및 Firebase용 Cloud Functions를 사용하면 완전 관리형 서버리스 환경에서 이벤트 기반 함수를 빌드하고 배포할 수 있습니다. 인프라를 관리할 필요 없이 HTTP 요청, Cloud Pub/Sub 메시지, Google Cloud Storage 변경사항, Firebase 실시간 데이터베이스 업데이트 등 다양한 이벤트 및 트리거에 대한 응답으로 코드를 실행할 수 있습니다. 주요 기능에는 다국어 지원, 확장성, 세분화된 결제, 타사 통합, 강력한 로깅 및 모니터링, 다른 Google 및 Firebase 서비스와의 통합이 포함됩니다.
서버리스 아키텍처는 특히 다양한 워크로드, 신속한 개발 요구사항, 예측할 수 없는 트래픽을 가진 애플리케이션에 많은 사용 사례에서 비용 효율적일 수 있습니다. 안정성은 특정 성능 및 안정성 목표를 보장하기 위해 서비스수준계약 (SLA)을 체결한 클라우드 제공업체에 따라 달라집니다. 특정 사용 사례와 요구사항을 평가하여 서버리스 아키텍처가 최선의 옵션인지 결정해야 합니다.
컨테이너화
컨테이너화를 통해 애플리케이션과 그 종속 항목을 가볍고 이식 가능한 컨테이너로 패키징할 수 있습니다. 다양한 시스템과 플랫폼에서 개발 및 배포를 지원하는 일관된 애플리케이션 환경을 제공합니다. 일부 서버리스 플랫폼은 컨테이너화된 워크로드를 실행하는 기능을 제공합니다. 기본 함수로 표현할 수 없는 복잡하거나 스테이트풀(Stateful) 워크로드가 있는 경우 서버리스 환경 내에서 컨테이너를 실행하면 유용할 수 있습니다. 언어 지원 및 런타임 환경 측면에서 유연성을 제공합니다.
Cloud Run은 개발자가 완전 관리형 환경에서 컨테이너화된 애플리케이션을 배포하고 실행할 수 있는 서버리스 컴퓨팅 플랫폼입니다. 기본 인프라를 관리하지 않고도 애플리케이션을 빌드, 배포, 확장할 수 있는 직관적인 방법을 제공합니다. 특히 워크로드가 가변적이고 컨테이너화가 애플리케이션 패키징 및 일관성 측면에서 이점을 제공하는 광범위한 웹 및 마이크로서비스 애플리케이션에 적합합니다.
마이크로서비스 아키텍처
애플리케이션은 느슨하게 결합된 작은 부분으로 세분화되어 고유한 기능이나 기능을 구현합니다. 이러한 서비스는 비동기 메시지 또는 이벤트 기반 채널을 통해 통신하거나 인터페이스를 노출하여 직접 통신할 수 있습니다. 각 서비스는 컨테이너에서 독립적으로 개발, 테스트, 확장됩니다. 이러한 컨테이너는 종종 Kubernetes와 같은 조정 서비스를 통해 관리되거나 Cloud Run과 같은 관리형 플랫폼을 사용하여 배포됩니다.
마이크로서비스 배포는 일반적으로 중앙 집중식 서버에 의존하지 않으므로 서버리스 애플리케이션 패러다임을 활용합니다.
애플리케이션을 자율 서비스로 분리하면 복잡한 시스템을 간소화할 수 있습니다. 경계와 목표를 잘 정의하면 개발 속도를 높이고 유지보수를 개선할 수 있습니다. 각 마이크로서비스는 가장 효과적인 프레임워크 또는 도구를 사용하여 독립적으로 개발할 수 있습니다. 서비스 간의 통신은 주로 이벤트, 게시-구독 통신, 메시지 파이프라인 또는 gRPC와 같은 리모트 프로시져 콜을 사용하여 처리됩니다.
마이크로서비스 아키텍처 내에서 작업을 조정하려면 대상 플랫폼을 지원하는 프레임워크, 조정 중인 작업 및 워크플로 유형에 충분한 깊이, 오류 처리 및 원격 분석을 통한 문제 디버깅을 사용하는 것이 좋습니다. 가장 많이 사용되는 옵션에는 Conductor 또는 Google Workflows와 같은 클라우드 제공업체의 제품이 있습니다.
마이크로서비스 기반 애플리케이션은 분산된 특성과 서비스 내 통신의 필요성으로 인해 개발 및 유지 관리가 복잡할 수 있습니다. 따라서 배포, 모니터링, 로깅 관리는 다른 아키텍처 옵션보다 더 복잡합니다. 안정성은 개별 서비스의 아키텍처에 따라 달라지므로 분산된 특성은 특히 모니터링 및 원격 분석이 배포되고 필요한 경우 사용 설정된 경우 추가 복원력을 제공할 수 있습니다.
콘텐츠 기반 웹 애플리케이션 백엔드를 위한 다양한 아키텍처 비교
다음 표에서는 콘텐츠 기반 웹 애플리케이션의 백엔드에 대한 주요 요구사항과 아키텍처를 비교합니다.
| 모놀리식 아키텍처 | 서버리스 이벤트 기반 아키텍처 | 서버리스 마이크로서비스 아키텍처 | |
|---|---|---|---|
| 복잡성 및 유지보수 |
|
|
|
| 확장성 및 성능 |
|
|
|
| 복원력 및 대체 전략 |
|
|
|
| 개발 환경 |
|
|
|
| 비용 |
|
|
|
콘텐츠 기반 웹 애플리케이션을 위한 백엔드 아키텍처 자세히 알아보기
다음은 앱을 다른 아키텍처로 이전하는 방법을 포함하여 콘텐츠 기반 웹 애플리케이션용 아키텍처에 관해 자세히 알아볼 수 있는 리소스입니다.
- 계층형 모놀리식 및 서버리스 웹 애플리케이션을 포함하여 느슨하게 결합된 웹 앱 백엔드 아키텍처에 대해 자세히 알아보기