대기업에서 배우는 많은 교훈을 스타트업의 첫 번째 스택에 직접 적용할 수는 없습니다. 제품의 초기 탐색 단계에서는 속도, 비용 및 옵션에 맞게 배포를 최적화해야 합니다. 선택 가능성은 지정된 아키텍처 내에서 방향을 얼마나 빠르게 변경할 수 있는지를 나타냅니다.
제품 개발의 확장 또는 추출 단계에 있는 비즈니스는 서비스 지향 또는 마이크로 서비스 아키텍처를 사용할 수 있습니다. 이 유형의 배포 아키텍처는 아직 제품/시장 적합성 또는 상업적 견인력을 찾지 못한 스타트업에 거의 적합하지 않습니다.
핵심 스타트업 스택의 경우 간단한 모놀리식 디자인이 가장 적합합니다. 이 디자인은 인프라 관리에 소요되는 시간을 제한하면서 스타트업이 더 많은 고객을 획득함에 따라 스케일링할 수 있는 충분한 기능을 제공합니다.
잠재적인 사용 사례
이 문서에서는 간단한 핵심 스타트업 스택의 예를 제시하고 해당 구성 요소를 설명합니다.
아키텍처
스타트업인 Contoso는 TypeScript로 작성된 Ruby on Rails 백 엔드와 React 프런트 엔드를 사용하여 애플리케이션 프로토타입을 빌드했습니다. Contoso 팀은 노트북에서 데모를 실행하고 있습니다. 이제 첫 번째 고객 영업 회의를 위해 앱을 배포하려고 합니다.
참고 항목
Ruby, React 및 TypeScript의 기술 선택은 설명에 불과합니다. 이 시작 아키텍처는 다른 많은 언어 및 프레임워크에도 동일하게 적용됩니다.
앱은 야심차지만 아직 복잡한 마이크로 서비스 기반 아키텍처가 필요하지 않습니다. 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, MariaDB, MongoDB, Apache Cassandra, Gremlin 및 Redis에 대한 관리형 데이터베이스 서비스도 있습니다.
- 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 및 Azure Database for MariaDB가 포함됩니다. 일부 사용 사례에는 MongoDB 또는 Azure Cosmos DB와 같은 문서 데이터베이스 또는 NoSQL 데이터베이스가 필요합니다.
로그 집계
앱에 문제가 발생하는 경우 문제를 진단하는 데 최대한 적은 시간을 할애하려고 합니다. 로그를 집계하고 처음부터 애플리케이션 추적을 사용하면 팀이 문제 자체에 집중할 수 있습니다. 모니터링 데이터를 얻기 위해 앱 서버의 파일에 액세스하고 로그를 자세히 조사할 필요가 없습니다.
CI/CD
반복 가능하고 신속한 배포가 없다는 것은 제품을 반복할 때 속도에 대한 최악의 장애물 중 하나입니다. 잘 구성된 CI/CD 파이프라인은 앱 서버에서 코드 배포 프로세스를 간소화합니다. 빠르고 쉬운 배포는 작업의 결과를 신속하게 볼 수 있음을 의미합니다. 자주 통합하면 병합 충돌로 이어지는 분기된 코드베이스를 방지할 수 있습니다. 개념과 기술은 Dockerfile을 사용하여 빌드하는 대부분의 프로젝트에서 동일합니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Andrew Harvey | CTO 및 Startup Advocate
기타 기여자:
- 닉 워드 | 클라우드 솔루션 설계자