평균 스택 - 서버를 분리해야합니까?

Question

저는 MEAN 스택으로 개인 프로젝트를 진행 중이며 서버 아키텍처를 설정할 때 어떤 경로를 택해야하는지 조언 해 주실 것입니다. 앞으로 기업 차원의 웹 앱을 제작하고 싶기 때문에 성능과 확장 성은 중요합니다.

이 프로젝트는 프런트 엔드, 비공개 API 및 파일 저장 시스템을 포함하는 이미지 호스팅 응용 프로그램입니다.

옵션 1 : 동일한 서버에 프런트 엔드 및 개인 API : 동일한 서버

옵션 2의 모든. 별도의 서버에 파일 저장 공간이 있습니다.

옵션 3 : 프런트 엔드, 비공개 API 및 파일 저장소는 모두 자체 서버에 있습니다.

나는 옵션 2가 최선의 선택일지도 모른다고 생각하지만 비슷한 아키텍처를 가진 앱을 구축 한 경험이있는 사람들로부터 배우고 싶습니다.

감사합니다.

Answer 1

예상되는 규모와 서버 인프라 스트럭처에 지출하려는 양에 따라 다양한 경우가 적합합니다. 나는 두 세계의 장점을 설명하려고 노력할 것입니다.

• API 기반 서비스의 경우 확장 가능한 인프라가 있어야합니다. 이러한 이유로 대부분로드 밸런서 뒤에있는 서버 형태입니다. 확장은 트래픽 유형 및 지역에 따라 위치를 결정합니다. 이를 위해 현재 업계에서 선호하는 것은 고정식 마이크로 서비스입니다. 또 하나의 비교 가능한 솔루션은 Google App Engine입니다.
• 모든 프런트 엔드/UI 기반 항목의 경우 최적의 전달을 위해 CDN에 저장해야합니다. CDN을 사용하면 비공개 API 기반 서비스가 느린 경우에도 최종 사용자가 응용 프로그램의 UI를 항상 사용할 수 있습니다. CDN은 저렴하며 최종 사용자에게 큰 영향을 미칩니다.
• 이미지/파일 저장소의 경우 Blob 저장소 기반 솔루션을 사용해야합니다. 요즘 서버의 HDD는 대부분 SSD이며 비용이 많이 든다. 또한이 디스크는 서버에 연결되어있어 오류나 보안 문제가 발생하기 쉽습니다. blob 저장소를 사용하면 어떤 형태의 보안과 함께 중복되고 확장 가능한 저장소를 관리하므로 유용합니다.

이 모델을 사용하면 핵심 서비스가 느릴 때도 최종 사용자가 웹 응용 프로그램에 액세스 할 수 있고 파일/API 서비스를 매우 쉽게 관리 할 수 ​​있습니다. 기반 규모.

Answer 2

서버 아키텍처를 올바르게 구축하면 안됩니다. 그러나 길을 따라 측정하고 원하는 부족한 기능을 개선하십시오.

따라서과 동일한 서버 접근 방식을 사용하면 이됩니다.

하지만 프런트 엔드를 서버리스 아키텍처으로 디자인하십시오.

읽기/쓰기를위한 개인용 API 및 별도의 파일 저장 영역 API 을 작성하십시오. 필요한 경우 확장 할 준비가 된 마이크로 서비스가 될 수 있습니다.

다른 구름에 조각을 호스팅하거나 자신을 수직/수평 또는 지리적으로 확장 할 수 있습니다.

스케일링 파트를 디자인에 베이킹하지만 필요할 때만 비율을 조정합니다.

은 기본적으로 당신이 당신의 아키텍처 조각으로 분리되어, 이제 관리을 에 필요로하는 유일한 것은 그래서 당신은 필요할 때 확장 할 준비가되어 있습니다.

주 다음 주제에 대한 두 개의 좋은 읽기는 다음과 같다 : 제시된 Infrastructure as Code, Building microservices