BLOG
Smallpdf의 수석 소프트웨어 엔지니어인 Alexander Döring이 작성하였습니다.
마지막으로 세어봤을 때, 필자가 속한 PDF 변환 스타트업 회사인 Smallpdf는 약 1,300 만 명의 월간 방문자를 기록 하였습니다. 그렇다면 현재 웹 사이트를 운영하는 직원의 수는 백엔드와 인프라에 초점을 맞춘 단 두 명의 직원을 포함하여 10명입니다.
이러한 소규모 개발팀으로 processing 집중 웹사이트를 어떻게 운영하는지 궁금 할 것입니다. 우리의 작은 비밀은 자동화와 위임에 있습니다. 우리는 가능한 한 많은 일을 외주 서비스에 맡깁니다. 우리가 하는 방법은 다음과 같습니다.
Smallpdf에서는 전 세계 사용자가 무료로 PSD를 압축, 변환 및 편집 할 수 있습니다. 이를 위해 사용자는 추가 소프트웨어를 설치할 필요가 없습니다. 그들이 해야 할 일은 파일을 업로드하는 것 뿐입니다. 이후 자동으로 문서에 필요한 작업이 설명되고 대기열로 전송됩니다 (예: 업로드 된 PDF를 작게 만들거나 Word 문서로 변환). 그런 다음 “작업자”서버는 작업과 입력 파일을 처리하며 출력 파일을 작성한 다음 결과물을 다시 대기열로 보냅니다.
이 설정에서 Smallpdf의 성공을 위한 열쇠 중 하나는 처리에 필요한 “작업자” 서버의 개수 입니다. AWS를 사용하면 몇 시간(또는 며칠) 동안 기다릴 필요 없이 EC2 인스턴스를 몇 분 안에 시작할 수 있습니다.
우리는 AWS로의 마이그레이션을 결정하기 전에 파일을 업로드하고 다운로드하기 위해 몇 가지 전용 “파일”서버를 사용 했습니다. 매우 복잡하고 시간이 오래 걸리는 이 작업을 끊임없이 지켜봐야 했습니다. 충분한 대역폭을 가지고 있는지? 하드 디스크 공간이 부족한지? 등 AWS S3의 거의 무한한 저장능력은 이러한 우려를 완전히 대체하여 인프라를 간결하고 견고하게 유지하는 핵심 요소가 되었습니다. 우리는 AWS 전문가들에게 이러한 특정 도메인에서의 성능, 가동 시간 및 확장에 대해 신경 쓰도록 하고, 우리는 우리의 제한된 인력을 다른 부분에 사용 하도록 했습니다.
우리에겐 중추신경인 “대기열” 서버에도 유사한 조치가 취해졌습니다. “대기열” 서버가 없다면, “작업자” 서버는 아무런 처리도 할 수 없으며, 우리의 사용자들은 원하는 결과를 얻을 수 없습니다. 우리의 “대기열” 서버는 꽤나 잘 작동했지만 시간이 지남에 따라 모든 것이 어긋날 것을 우려하여 서버 변경에 대해 점점 더 꺼려지게 되었습니다. 그에 따라 우리는 보내기 작업은 SQS로 대체하고 결과물에 대해선 SNS로 대체하기로 결정 했습니다.
작업 종속성 및 상태 제거하기
우리는 이전에 큐를 SQS로 대체하려고 생각했었습니다. 새 EC2 인스턴스를 사용해야 하는 “대기열” 서버를 변경하려는 목표는 우리를 상당히 딜레마에 빠지게 했습니다. 이 과정은 우리가 생각한 것보다 훨씬 복잡했습니다. 많은 것들이 “대기열” 서버에 단단히 묶여 있었습니다. Frontend는 임의의 대기열에 작업을 보내고 결과물이 정확히 동일한 서버에 도착할 것으로 예상합니다. Downtime을 0으로 바꾸는 것은 매우 어렵고 시간을 많이 잡아먹을 것 입니다.
결국 우리는 SQS 및 SNS로 전환하고 “대기열” 서버 교체에 대한 예상과 필적하는 타임프레임 변경 사항을 구현하기로 결정했습니다. 이것이 우리가 서버 사이의 큰 의존성을 제거한 방법입니다. 이렇게 하면, 서버는 다른 서버의 존재를 알 필요가 없으며 모든 통신은 AWS를 통해 이루어지게 됩니다.
이와 함께 외부의 모든 연결에 대해 Elastic Load Balancer를 사용하고 시작 시간이 1초 미만인 Docker 컨테이너로 프로그램을 구축 했습니다. 이 방법은 많은 탄력성과 확장성을 제공합니다. 번거로움 없이 서버를 교체하고 몇 분 안에 자동으로 (또는 수동으로) 확장 할 수 있습니다. 프로세스가 실패하면 즉시 다시 시작되거나 교체 프로그램이 자동으로 시작됩니다.
우리의 트래픽과 작업량은 전 세계 사용자의 근무 시간에 크게 의존됩니다. 유럽인이 아직 사무실에 있으며 북미 지역 근로자가 하루를 시작하는 CET 4 p.m 경에 최고조에 달합니다. EC2 auto-scaling 그룹 및 auto-scaling ECS 서비스는 우리의 작업 부하를 다이내믹하게 처리하고 새로운 것을 시도 할 수 있게 합니다. 예를 들어, 새로운 분석 시스템을 구축 할 때 Redshift와 Kinesis Firehose가 우리가 살펴본 첫 번째 옵션이었고 결국 우리가 선택한 옵션 이었습니다. 우리의 실험은 작업량을 계속 최적화하는 방법의 중요한 부분이며, 현재는 Deep Learning 및 SageMaker를 실험하고 있습니다. 현재까지는 아주 좋은 징조를 보입니다.
원문 URL: https://aws.amazon.com/ko/blogs/startups/how-to-run-a-top-1000-website-with-a-devops-team-of-two/
** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.