많은 스타트업이 이런 일을 겪었습니다. 매일 수많은 신규 사용자가 등록하고 개발팀은 서비스를 계속 실행하기 위해 고군분투합니다.

이는 좋은 문제이지만, 웹 애플리케이션을 아무것도 없는 상태에서 수십만 명의 사용자로 조심스럽게 확장하는 방법에 대한 명확한 정보가 웹에 거의 없습니다. 일반적으로 화재 해결 방법이나 병목 현상 해결 방법(종종 둘 다)이 있습니다. 따라서 사람들은 아마추어 프로젝트를 정말 진지한 프로젝트로 확장하기 위해 다소 진부한 기술을 사용합니다.

정보를 필터링하고 기본 공식을 적어 보겠습니다. 우리는 새로운 사진 공유 사이트 Graminsta를 사용자 1명에서 100명까지 단계적으로 확장할 예정입니다.

관객이 10명, 100명, 1000명, 10만명, 000만명으로 늘어날 때 구체적으로 어떤 조치를 취해야 하는지 적어보자.

사용자 1명: 머신 1대

웹사이트든 모바일 애플리케이션이든 거의 모든 애플리케이션에는 세 가지 주요 구성 요소가 있습니다.

• API
• 데이터베이스
• 클라이언트(모바일 애플리케이션 자체 또는 웹사이트)

데이터베이스는 영구 데이터를 저장합니다. API는 이 데이터에 대한 요청을 처리합니다. 클라이언트는 사용자에게 데이터를 전송합니다.

아키텍처 관점에서 클라이언트와 API 엔터티가 완전히 분리되면 애플리케이션 확장에 대해 이야기하는 것이 훨씬 쉽다는 결론에 도달했습니다.

처음 애플리케이션 구축을 시작하면 세 가지 구성 요소 모두 동일한 서버에서 실행될 수 있습니다. 어떤 면에서 이것은 우리의 개발 환경과 유사합니다. 한 명의 엔지니어가 동일한 시스템에서 데이터베이스, API 및 클라이언트를 실행합니다.

이론적으로는 아래와 같이 단일 DigitalOcean Droplet 또는 AWS EC2 인스턴스의 클라우드에 배포할 수 있습니다.

즉, 사이트에 두 명 이상의 사용자가 있는 경우 거의 항상 데이터베이스 계층을 전용으로 사용하는 것이 합리적입니다.

사용자 10명: 데이터베이스를 별도의 수준으로 이동

데이터베이스를 Amazon RDS 또는 Digital Ocean Managed Database와 같은 관리형 서비스로 분할하면 오랫동안 도움이 될 것입니다. 단일 머신이나 EC2 인스턴스에서 자체 호스팅하는 것보다 조금 더 비싸지만, 이러한 서비스를 사용하면 다중 지역 백업, 읽기 복제본, 자동 등 미래에 유용할 유용한 확장 기능을 즉시 사용할 수 있습니다. 백업 등이 있습니다.

현재 시스템의 모습은 다음과 같습니다.

사용자 100명: 클라이언트를 별도의 수준으로 이동

다행히 첫 번째 사용자는 우리 애플리케이션을 정말 좋아했습니다. 트래픽이 더욱 안정되고 있으므로 이제 클라이언트를 별도의 수준으로 이동할 때입니다. 주목해야 할 점은 분리 엔터티는 확장 가능한 애플리케이션 구축의 핵심 측면입니다. 시스템의 한 부분이 더 많은 트래픽을 수신하면 이를 분할하여 특정 트래픽 패턴에 따라 서비스가 확장되는 방식을 제어할 수 있습니다.

이것이 바로 제가 클라이언트를 API와 별개로 생각하고 싶은 이유입니다. 이를 통해 웹, 모바일 웹, iOS, Android, 데스크톱 애플리케이션, 타사 서비스 등 다양한 플랫폼에 대한 개발을 매우 쉽게 생각할 수 있습니다. 이들은 모두 동일한 API를 사용하는 클라이언트일 뿐입니다.

예를 들어, 이제 사용자는 모바일 애플리케이션 출시를 가장 자주 요청합니다. 클라이언트와 API 엔터티를 분리하면 이 작업이 더 쉬워집니다.

그러한 시스템은 다음과 같습니다.

사용자 1000명: 로드 밸런서 추가

상황이 좋아지고 있습니다. Graminsta 사용자들은 점점 더 많은 사진을 업로드하고 있습니다. 등록 건수도 늘어나고 있다. 우리의 단일 API 서버는 모든 트래픽을 따라잡는 데 어려움을 겪고 있습니다. 철분이 더 필요해요!

로드 밸런서는 매우 강력한 개념입니다. 핵심 아이디어는 API 앞에 로드 밸런서를 배치하고 개별 서비스 인스턴스에 트래픽을 분산시키는 것입니다. 이것이 수평적으로 확장하는 방법입니다. 즉, 동일한 코드로 더 많은 서버를 추가하여 처리할 수 있는 요청 수를 늘립니다.

웹 클라이언트 앞과 API 앞에 별도의 로드 밸런서를 배치할 예정입니다. 이는 API 코드와 웹 클라이언트 코드를 실행하는 여러 인스턴스를 실행할 수 있음을 의미합니다. 로드 밸런서는 로드가 적은 서버로 요청을 보냅니다.

여기서 우리는 또 다른 중요한 이점, 즉 중복성을 얻습니다. 한 인스턴스가 실패하면(아마도 과부하 또는 충돌) 들어오는 요청에 계속 응답하는 다른 인스턴스가 남습니다. 인스턴스가 하나만 작동하는 경우 오류가 발생하면 전체 시스템이 중단됩니다.

로드 밸런서는 자동 크기 조정도 제공합니다. 최대 부하가 발생하기 전에 인스턴스 수를 늘리고 모든 사용자가 잠자고 있을 때 인스턴스 수를 줄이도록 구성할 수 있습니다.

로드 밸런서를 사용하면 요청 수가 증가함에 따라 새 인스턴스를 추가하기만 하면 API 수준을 거의 무한정 확장할 수 있습니다.

메모. 현재 우리 시스템은 Heroku 또는 AWS의 Elastic Beanstalk와 같은 PaaS 회사가 기본적으로 제공하는 것과 매우 유사합니다(이것이 바로 인기가 있는 이유입니다). Heroku는 데이터베이스를 별도의 호스트에 배치하고 자동 확장 로드 밸런서를 관리하며 API와 별도로 웹 클라이언트를 호스팅할 수 있습니다. 이것이 초기 단계의 프로젝트나 스타트업에 Heroku를 사용하는 큰 이유입니다. 즉, 모든 기본 서비스를 즉시 사용할 수 있기 때문입니다.

사용자 10명: CDN

아마도 우리는 처음부터 이 일을 했어야 했을 것입니다. 요청을 처리하고 새 사진을 수락하는 것이 서버에 너무 많은 부담을 주기 시작했습니다.

이 단계에서는 이미지, 비디오 등의 정적 콘텐츠(AWS S3 또는 Digital Ocean Spaces)를 저장하기 위해 클라우드 서비스를 사용해야 합니다. 일반적으로 우리 API는 이미지 제공 및 서버에 이미지 업로드와 같은 작업을 처리하지 않아야 합니다.

클라우드 호스팅의 또 다른 장점은 CDN입니다(AWS는 이 추가 기능을 Cloudfront라고 부르지만 많은 클라우드 스토리지 제공업체가 이를 즉시 제공합니다). CDN은 전 세계 다양한 데이터 센터에 이미지를 자동으로 캐시합니다.

당사의 메인 데이터 센터는 오하이오에 있을 수 있지만 누군가 일본에 이미지를 요청하면 클라우드 제공업체는 이를 복사하여 일본 데이터 센터에 저장합니다. 일본에서 이 이미지를 요청하는 다음 사람이 훨씬 더 빨리 이미지를 받게 됩니다. 이는 다운로드하고 지구 전체로 전송하는 데 오랜 시간이 걸리는 사진이나 비디오와 같은 대용량 파일을 작업할 때 중요합니다.

100명의 사용자: 데이터 계층 확장

CDN은 많은 도움을 주었습니다. 트래픽이 최고 속도로 증가하고 있습니다. 유명한 비디오 블로거 Mavid Mobrick이 방금 우리에 등록했고 그들이 말하는 대로 그의 "스토리"를 게시했습니다. 로드 밸런서 덕분에 API 서버의 CPU 및 메모리 사용량은 낮게 유지되지만(XNUMX개의 API 인스턴스 실행) 요청에 대한 시간 초과가 많이 발생하기 시작합니다... 이러한 지연은 어디에서 발생합니까?

측정항목을 조금 살펴보면 데이터베이스 서버의 CPU가 80-90% 로드된 것을 볼 수 있습니다. 우리는 한계에 도달했습니다.

데이터 계층을 확장하는 것은 아마도 방정식에서 가장 어려운 부분일 것입니다. API 서버는 상태 비저장 요청을 처리하므로 더 많은 API 인스턴스를 추가하기만 하면 됩니다. 코 대부분의 사람들 데이터베이스는 이를 수행할 수 없습니다. 널리 사용되는 관계형 데이터베이스 관리 시스템(PostgreSQL, MySQL 등)에 대해 이야기하겠습니다.

캐싱

데이터베이스 성능을 높이는 가장 쉬운 방법 중 하나는 새로운 구성 요소인 캐시 계층을 도입하는 것입니다. 가장 일반적인 캐싱 방법은 Redis 또는 Memcached와 같은 메모리 내 키-값 레코드 저장소입니다. 대부분의 클라우드에는 AWS의 Elasticache와 Google Cloud의 Memorystore 서비스의 관리형 버전이 있습니다.

캐시는 서비스가 동일한 정보를 검색하기 위해 데이터베이스를 여러 번 반복적으로 호출할 때 유용합니다. 기본적으로 우리는 데이터베이스에 한 번만 액세스하고 정보를 캐시에 저장하며 다시는 건드리지 않습니다.

예를 들어 Graminsta 서비스에서는 누군가 스타 Mobrik의 프로필 페이지로 이동할 때마다 API 서버가 데이터베이스에 해당 프로필의 정보를 쿼리합니다. 이런 일이 계속해서 발생합니다. Mobrik의 프로필 정보는 요청할 때마다 변경되지 않으므로 캐싱에 탁월합니다.

Redis의 데이터베이스 결과를 키별로 캐시합니다. user:id 유효기간은 30초입니다. 이제 누군가 Mobrik의 프로필에 가면 먼저 Redis를 확인하고 데이터가 있으면 Redis에서 직접 전송하면 됩니다. 이제 사이트에서 가장 인기 있는 프로필에 대한 요청은 실제로 데이터베이스를 로드하지 않습니다.

대부분의 캐싱 서비스의 또 다른 장점은 데이터베이스 서버보다 확장이 더 쉽다는 것입니다. Redis에는 Redis 클러스터 모드가 내장되어 있습니다. 로드 밸런서와 유사1, 여러 시스템(필요한 경우 수천 대의 서버)에 Redis 캐시를 배포할 수 있습니다.

거의 모든 대규모 애플리케이션은 캐싱을 사용하며 이는 빠른 API의 절대적으로 필수적인 부분입니다. 더 빠른 쿼리 처리와 더 생산적인 코드가 모두 중요하지만 캐시가 없으면 서비스를 수백만 명의 사용자로 확장하는 것이 거의 불가능합니다.

복제본 읽기

데이터베이스에 대한 쿼리 수가 크게 증가한 경우 우리가 할 수 있는 또 하나의 작업은 데이터베이스 관리 시스템에 읽기 전용 복제본을 추가하는 것입니다. 위에서 설명한 관리 서비스를 사용하면 한 번의 클릭으로 이 작업을 수행할 수 있습니다. 읽기 전용 복제본은 기본 데이터베이스에서 최신 상태로 유지되며 SELECT 문에 사용할 수 있습니다.

현재 우리 시스템은 다음과 같습니다.

다음 단계

애플리케이션이 계속 확장됨에 따라 서비스를 계속 분리하여 독립적으로 확장할 것입니다. 예를 들어 Websocket을 사용하기 시작하면 Websocket 처리 코드를 별도의 서비스로 가져오는 것이 합리적입니다. 우리는 이를 자체 로드 밸런서 뒤의 새 인스턴스에 배치할 수 있으며, 이는 공개 웹소켓 연결을 기반으로 HTTP 요청 수에 관계없이 확장 및 축소할 수 있습니다.

우리는 또한 데이터베이스 수준의 제한에 계속해서 맞서 싸울 것입니다. 이 단계에서는 데이터베이스 파티셔닝과 샤딩을 연구할 때입니다. 두 접근 방식 모두 추가 오버헤드가 필요하지만 데이터베이스를 거의 무한정 확장할 수 있습니다.

또한 New Relic 또는 Datadog과 같은 모니터링 및 분석 서비스를 설치하려고 합니다. 이는 느린 쿼리를 식별하고 개선이 필요한 부분을 이해하는 데 도움이 됩니다. 규모를 확장하면서 우리는 병목 현상을 찾아 제거하는 데 집중하고 싶습니다. 종종 이전 섹션의 아이디어 중 일부를 사용합니다.

소스

이 게시물은 다음 중 하나에서 영감을 얻었습니다. 높은 확장성에 관한 내가 가장 좋아하는 게시물. 나는 프로젝트의 초기 단계에 대해 기사를 좀 더 구체적으로 작성하고 이를 하나의 공급업체로부터 분리하고 싶었습니다. 이 주제에 관심이 있다면 꼭 읽어보세요.

각주

1. 여러 인스턴스에 걸친 로드 분산 측면에서는 유사하지만 Redis 클러스터의 기본 구현은 로드 밸런서와 매우 다릅니다. [반품]

출처 : habr.com