핵심 스타트업 스택 아키텍처

대기업에서 배운 많은 단원은 스타트업의 첫 번째 스택에 직접 적용되지 않습니다. 제품의 초기 탐색 단계에서는 속도, 비용 및 선택성을 위해 배포를 최적화해야 합니다. 선택성은 지정된 아키텍처 내에서 방향을 얼마나 빠르게 변경할 수 있는지를 나타냅니다.

제품 개발의 확장 또는 추출 단계의 비즈니스는 서비스 지향 또는 마이크로 서비스 아키텍처를 사용할 수 있습니다. 이러한 유형의 배포 아키텍처는 제품/시장 적합성 또는 상업적 견인력을 아직 찾지 못한 신생 기업에게는 거의 적합하지 않습니다.

핵심 시작 스택의 경우 간단한 모놀리식 디자인이 가장 좋습니다. 이 디자인은 인프라를 관리하는 데 소요되는 시간을 제한하는 동시에 스타트업이 더 많은 고객을 획득함에 따라 확장할 수 있는 충분한 기능을 제공합니다.

잠재적인 사용 사례

이 문서에서는 간단한 코어 시작 스택의 예를 제시하고 해당 구성 요소에 대해 설명합니다.

건축학

신생 기업인 Contoso는 Ruby on Rails 백 엔드와 TypeScript로 작성된 React 프런트 엔드를 사용하여 애플리케이션 프로토타입을 빌드했습니다. Contoso 팀은 노트북에서 데모를 실행하고 있습니다. 이제 첫 번째 고객 영업 회의를 위해 앱을 배포하려고 합니다.

앱은 야심차지만 아직 복잡한 마이크로 서비스 기반 아키텍처가 필요하지 않습니다. Contoso는 권장되는 시작 스택 구성 요소를 포함하는 간단한 모놀리식 디자인을 선택했습니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

데이터 흐름

이 핵심 시작 스택 아키텍처에서:

• Azure App Service 는 서버, 부하 분산 장치 또는 기타 인프라를 구성하지 않고 확장 가능한 애플리케이션을 배포하는 간단한 앱 서버를 제공합니다. App Service는 예제와 같이 컨테이너 배포를 지원하며 ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP 또는 Python에 대한 컨테이너 없는 배포도 지원합니다.

• Azure Database for PostgreSQL 은 선도적인 RDBMS(오픈 소스 관계형 데이터베이스 관리 시스템)를 위한 Azure 데이터베이스 서비스입니다. 데이터베이스 서버를 관리하는 대신 애플리케이션 개발에 집중할 수 있습니다.

  Azure에는 SQL, MySQL, MongoDB, Apache Cassandra, Gremlin 및 Redis에 대한 관리형 데이터베이스 서비스도 있습니다.

  관리되는 제품 외에도 Azure Marketplace에는 CockroachDB, Neon Serverless Postgres 및 SQLite와 같은 시작 아키텍처에 사용되는 데이터베이스도 포함되어 있습니다.

• Azure Virtual Network 는 네트워크 트래픽을 분할하고 인터넷 위협으로부터 내부 서비스를 보호합니다. 앱 서버는 가상 네트워크 통합 을 사용하여 인터넷에 노출하지 않고 데이터베이스와 통신합니다.

• GitHub Actions 는 소스 코드 관리에 CI/CD(지속적인 통합 및 지속적인 배포)를 빌드합니다. GitHub Actions는 다양한 언어에 대한 광범위한 지원과 Azure 서비스와의 강력한 통합을 제공합니다.

• Azure Blob Storage 는 정적 자산을 저장하고 앱 서버에서 부하를 이동합니다.

• WAF를 사용하는 Azure Front Door 는 CDN(글로벌 콘텐츠 배달 네트워크) 및 웹 애플리케이션 방화벽을 통해 사용자에게 콘텐츠 배달을 가속화하고 보호합니다.

• Azure Monitor 는 애플리케이션 인프라에서 발생하는 작업을 모니터링하고 분석합니다.

핵심 시작 스택 구성 요소

복잡한 스택은 지속적인 주의가 필요한 버그를 생성할 수 있습니다. 정교한 아키텍처는 제품 빌드를 방해할 수 있습니다. 버그는 복잡성으로 인해 발생하지 않지만 복잡한 스택을 사용하면 버그를 더 쉽게 배송할 수 있습니다. 모든 정교한 아키텍처가 에너지 낭비는 아니지만 제품/시장에 적합하지 않은 경우 리소스를 낭비합니다. 첫 번째 시작 스택은 간단해야 하므로 제품 개발에 집중할 수 있습니다.

다음 간단한 다이어그램에서는 권장되는 핵심 시작 스택을 보여 있습니다. 이러한 구성 요소는 제품을 처음부터 고객의 손에 맡기기에 충분합니다. 신생 기업의 80%의 경우 이 스택은 제품에 기본 제공된 기본 가설을 테스트하는 데 필요합니다. 기계 학습, IoT(사물 인터넷) 또는 규제가 높은 환경에서 작업하는 신생 기업에서는 더 많은 구성 요소가 필요할 수 있습니다.

CDN

처음에는 고객이 거의 없는 경우 CDN은 시기상조로 보일 수 있습니다. 그러나 프로덕션에 이미 있는 제품에 CDN을 추가하면 예기치 않은 부작용이 발생할 수 있습니다. CDN을 미리 구현하는 것이 가장 좋습니다. CDN은 고객에게 더 가까운 정적 콘텐츠를 캐시하고 API 및 아키텍처에서 반복할 수 있는 외관을 제공합니다.

앱 서버

코드는 어딘가에서 실행해야 합니다. 이상적으로 이 플랫폼은 최소한의 운영 입력을 요구하면서 배포를 쉽게 만들어야 합니다. 앱 서버는 가로로 크기를 조정해야 하지만 탐색 단계에 있는 동안 일부 수동 크기 조정 작업은 괜찮습니다.

대부분의 스택과 마찬가지로 앱 서버는 기본적으로 자체적으로 실행되어야 합니다. 일반적으로 앱 서버는 가상 머신이거나 운영 체제 미설치 서버에서 실행되는 웹 서버 인스턴스였습니다. 이제 위의 App Service 및 컨테이너와 같은 PaaS(Platform-as-a-Service) 옵션을 확인하여 운영 오버헤드를 제거할 수 있습니다.

정적 콘텐츠

앱 서버에서 정적 콘텐츠를 제공하면 리소스가 낭비됩니다. CI/CD 파이프라인을 구성하면 각 릴리스에서 정적 자산을 빌드하고 배포하는 작업은 간단합니다. 대부분의 프로덕션 웹 프레임워크는 CI/CD를 사용하여 정적 자산을 배포하므로 이 모범 사례에 맞게 시작하는 것이 좋습니다.

데이터베이스

앱이 실행되면 데이터베이스에 데이터를 저장해야 합니다. 대부분의 경우 관계형 데이터베이스가 가장 적합한 솔루션입니다. 관계형 데이터베이스에는 여러 액세스 방법과 시간 테스트 솔루션의 속도가 있습니다. 관계형 데이터베이스에는 Azure SQL Database 및 Azure Database for PostgreSQL이 포함됩니다. 일부 사용 사례에는 문서 데이터베이스 또는 MongoDB 또는 Azure Cosmos DB와 같은 NoSQL 데이터베이스가 필요합니다.

로그 집계

앱에 문제가 있는 경우 문제를 진단하는 데 최대한 적은 시간을 할애하려고 합니다. 로그를 집계하고 처음부터 애플리케이션 추적을 사용하면 팀이 문제 자체에 집중할 수 있습니다. 모니터링 데이터를 가져오기 위해 앱 서버의 파일에 액세스하고 로그를 통해 모공을 만들 필요가 없습니다.

CI/CD

반복 가능하고 신속한 배포의 부족은 제품을 반복할 때 속도를 저하시키는 최악의 장애물 중 하나입니다. 잘 구성된 CI/CD 파이프라인은 앱 서버에서 코드 배포 프로세스를 간소화합니다. 빠르고 쉬운 배포는 작업의 결과를 빠르게 볼 수 있음을 의미합니다. 자주 통합하면 병합 충돌로 이어지는 서로 다른 코드 베이스를 방지할 수 있습니다. 개념과 기술은 Dockerfile을 사용하여 빌드하는 대부분의 프로젝트에서 동일합니다.

기여자

Microsoft에서 이 문서를 유지 관리합니다. 그것은 원래 다음 기여자에 의해 작성되었습니다.

대표 저자:

• Andrew Harvey | CTO 및 Startup Advocate

기타 기여자:

• 닉 워드 | 클라우드 솔루션 설계자

다음 단계

• GitHub Actions를 사용하여 워크플로 자동화

관련 리소스

• 스타트업을 위한 아키텍처
• 클라우드 애플리케이션의 모범 사례
• CDN(콘텐츠 전송 네트워크) 사용에 대한 모범 사례
• Azure 애플리케이션을 위한 10가지 설계 원칙