Zillow 사례 연구

매일 수천만 명의 잠재적 주택 구매자, 판매자 및 임차인 뿐만 아니라 중개사와 부동산 자산 관리사가 Zillow 웹 사이트를 사용하여 주택과 아파트 매물을 살펴보고, 대출을 알아보고, 미국 전역의 1억 1천만 개의 주택에 대한 정보를 찾습니다. 널리 사용되는 이 사이트는 가장 큰 부동산 및 주택 관련 브랜드 포트폴리오를 온라인으로 제공하는 Zillow Group에서 소유하고 있습니다. Zillow Group은 Zillow 외에도 Trulia, HotPads 및 StreetEasy를 운영합니다.

Zillow는 Zillow Digs 사이트에서 매물 사진, 임대인과 중개사의 프로필 사진, 주택 프로젝트 이미지를 비롯하여 매일 3백만 개가 넘는 새로운 이미지를 처리합니다. "피크 트래픽 동안에는 데스크톱과 모바일 클라이언트 양쪽에서 초당 17,000개의 이미지 요청을 수신합니다."라고 Zillow Group의 Unix 시스템 엔지니어링 책임자인 Nick Michal은 말합니다.

Zillow의 인기가 높아지고 중개사가 더 높은 해상도의 매물 사진을 올리기 시작함에 따라, 회사의 레거시 이미징 시스템이 수요를 따라갈 수 없었습니다. 시스템은 호스팅된 데이터 센터에 상주하며, 이미지는 하나의 대기열에서 다운로드되고, 네트워크 연결 스토리지(NAS) 디바이스에 피라미드 TIFF 형식으로 저장되며, 로컬 Squid 서비스를 통해 콘텐츠 전송 네트워크(CDN)로 제공됩니다. "이런 방식의 작업은 비용이 많이 들었고, CDN의 캐시 적중률이 높기를 기대할 수밖에 없었습니다. 적중률이 낮은 경우, 이미지를 효율적으로 제공할 수 없었습니다. 우리는 매일 최대 용량에 가깝게 사용하고 있었습니다."라고 Michal은 말합니다.

또한, 대량 피드에서 다른 이미지가 다운로드되는 동안 일부 이미지가 수동으로 업로드됨에 따라 Zillow는 이미지 처리 성능 문제로 씨름하고 있었습니다. 대량 피드에서 수신되는 새로운 이미지의 비율은 예측할 수 없는 경우가 많았으며, 일부 이미지 소스는 다른 이미지 소스보다 좀 더 많은 수를 동시에 처리하고 더 빠르게 다운로드할 수 있었습니다. 이에 따라 대기열 앞부분에 있는 느리거나 문제가 있는 이미지가 다른 이미지의 다운로드를 방해했습니다. "사용자가 사이트를 방문했는데 이미지가 없다면, 매물을 들여다보지 않을 것이므로, Zillow에서는 대역폭 문제가 있어서는 안 됩니다. 사용자에게 불편을 주게 될 것입니다."라고 Zillow Group의 선임 소프트웨어 개발 엔지니어인 Feroze Daud는 말합니다.

Zillow가 피라미드 TIFF 형식의 스토리지용으로 이미지를 처리하는 데 사용하던 도구가 노후해가고 있었고 쉽게 확장할 수 없었습니다. Daud는 "단색의 경계선을 제거하는 등 이미지 품질을 개선하기가 쉽지 않았습니다."라고 말합니다. 재해 복구도 또 다른 주요 문제 중 하나였습니다. Michal은 "모든 것이 하나의 데이터 센터에 호스팅되어있는 것 자체에 위험이 있었습니다."라고 말합니다.

이미지 시스템의 확장성, 성능 및 재해 복구 문제를 해결하기 위해 Zillow는 클라우드 기반 인프라로 이전을 결정했습니다. "전반적인 비용과 관리의 용이성 측면에서 클라우드는 적절한 선택이었습니다."라고 Michal은 말합니다. 다양한 클라우드 기술을 평가한 후, Zillow는 Amazon Web Services(AWS)를 선택했습니다. Michal은 "AWS는 가장 오래된 공급업체이고 클라우드 분야에서는 독보적이었습니다. 또한, 우리가 인수한 여러 회사가 이미 AWS를 사용하고 있었습니다."라고 말합니다.

Zillow는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 이미지 객체 스토리지로 Amazon Simple Storage Service(Amazon S3)를 사용하여 이미지 호스팅 및 배포를 물리적 코로케이션 시설에서 AWS로 마이그레이션했습니다. 현재 Zillow는 3억 개의 이미지와 10억 개 이상의 객체를 비롯하여 Amazon S3에 100TB에 가까운 데이터를 저장하고 있습니다. Michal은 "기존 파일 시스템으로 수십억 개의 객체 수를 유지 관리하기가 쉽지 않습니다. 이러한 객체를 여러 개의 파일 시스템으로 나누어야 할 것이고 이는 관리 부담을 가중시키게 됩니다. Amazon S3의 확장성은 우리에게 적합한 기술로 생각되었습니다."라고 말합니다.

또한, Zillow는 웹 애플리케이션 및 서비스를 배포하고 확장하는 서비스인 AWS Elastic Beanstalk를 사용하기 시작했습니다. 개발자가 Elastic Beanstalk에 코드를 업로드하면, 용량 프로비저닝에서부터 로드 밸런싱, 자동 크기 조정, 애플리케이션 상태 모니터링에 이르기까지 배포를 자동으로 처리합니다. Zillow는 Elastic Beanstalk 작업자 환경을 사용하여 사용자 정의 코드로 Python Imaging Library를 실행합니다. "거대한 작업량을 모두 한 번에 시스템에 던지는 피드를 실행하여 닥치는 대로 데이터를 수집하므로, 이미지 변환기 제품군을 확장해야 합니다. 여러 개의 정적 인스턴스를 실행하거나 자체 자동 조정 구성을 작성하는 것과는 대조적으로 AWS Elastic Beanstalk는 가장 간단하게 이를 확장할 수 있는 방법입니다."라고 Daud는 말합니다.

조직에서는 그런 다음 CDN 워크로드 대부분을 Akamai에서 Amazon CloudFront, 즉 Zillow 웹 사이트 콘텐츠를 사용자에게 더 가까운 위치에서 배포하는 콘텐츠 전송 웹 서비스로 이전했습니다. "AWS CloudFront는 Akamai보다 상당히 저렴하고, Amazon S3와도 원활하게 통합됩니다."라고 Michal은 말합니다. 또한, Zillow는 일부 클라우드 리소스를 모니터링하는 데 Amazon CloudWatch를 사용하고 있습니다.

Zillow는 데이터 센터에 있는 다운로드 서버(DLS)를 사용하여 매물 피드에서 수신되는 이미지 다운로드 요청을 관리하고, Amazon Elastic Beanstalk REST API를 DLS를 위한 클라우드의 프론트 엔드 서비스로 사용합니다. 이 서비스는 각 이미지 다운로드 요청을 받아 이를 피드별 Amazon Simple Queue Service(Amazon SQS) 메시지 대기열 서비스에 넣습니다. "SQS를 사용하면서 인프라를 우리가 지원해야 할 필요 없이 대기열 시스템을 갖추게 되었습니다."라고 Michal은 말합니다.

조정 다운로더는 Zillow가 각 피드 소스에서 이미지를 다운로드하는 속도와 동시성을 제어함으로써, 빠른 다운로드를 지원하지 않는 이미지 공급자에는 영향을 주지 않으면서 빠른 다운로드를 지원하는 이미지 공급자를 활용할 수 있게 해줍니다. 이미지 다운로드가 성공하면, Zillow는 이미지 처리에 사용할 수 있도록 원본 이미지를 Amazon S3에 저장합니다.

이미지 처리의 경우, Zillow는 S3에 저장된 원본 이미지를 가져와서 각 이미지에 대한 표준 크기 세트를 생성하면서 다양한 이미지 품질 메서드를 통해 이미지를 처리합니다. 모든 이미지는 Amazon S3에서 제공되며 Amazon CloudFront에 캐시됩니다. Zillow는 초당 평균 15,000개의 이미지를 지원합니다.

AWS를 사용하면 Zillow는 잠재적인 주택 구매자와 임차인, 부동산 중개사 및 기타 사이트 방문자에게 좀 더 나은 경험을 제공할 수 있습니다. "AWS로 이전함으로써 더 이상 캐시 플러시나 용량 문제를 걱정할 필요가 없습니다. 고품질 부동산 이미지를 제공하는 데 필요한 확장성과 성능을 갖추었습니다. 이는 Zillow 사용자 경험에 매우 중요합니다."라고 Daud는 말합니다. Zillow는 온종일 다양한 수준의 수신 이미지를 처리하도록 이미지 다운로딩 및 처리 용량을 확장할 수 있습니다. 각 피드 소스에서 이미지를 다운로드하는 작업이 이제 독립적이므로, Zillow는 고대역폭과 동시성을 지원하는 소스를 활용하면서 그렇지 않은 소스를 조절할 수 있습니다. 또한, Amazon S3는 Zillow에 거의 무제한의 객체 스토리지를 제공하여 용량을 증가하기 위해 추가 서버나 드라이브를 주문 및 설치할 필요가 없습니다.

Amazon S3와 더불어 Amazon CloudFront를 사용하면서 Zillow는 이미징 시스템의 성능에 좀 더 확신을 하게 되었습니다. Michal은 "전보다 훨씬 더 많은 대역폭을 보유하게 되어 더 이상 대역폭에 대해 생각할 필요도 없게 되었습니다. 물론 S3의 용량이 부족하지는 않은지 걱정할 필요도 없습니다."라고 말합니다.

Zillow는 이미지 처리 및 전송 시스템을 AWS로 마이그레이션함으로써 운영 비용도 절감했습니다. "Amazon CloudFront를 사용하면서 이전에 CDN에 대해 지불했던 월별 비용의 절반도 안 되는 비용을 지불하고 있습니다. 더 이상 NAS 디바이스로 대규모로 업그레이드하는 데 비용을 지출하지 않아도 됩니다."라고 Michal은 말합니다.

Zillow는 Amazon S3와 Amazon CloudFront를 사용함으로써 이미징 시스템의 가용성을 높였습니다. "S3에서는 리전 내에 3가지 방식으로 객체를 복제합니다. 따라서 가용 영역에 장애가 발생하더라도 우리의 개발 노력 없이 사용자에게 여전히 트래픽을 제공할 수 있습니다."라고 Michal은 말합니다.

재해 복구 또한 개선되었습니다. "우리는 지리적으로 분산된 AWS를 충분히 활용할 수 있습니다. AWS 리전이 여러 개이며 해당 리전에는 가용 영역이 있습니다. 따라서 사용자에게 가까운 위치에서 동적 콘텐츠를 생성할 수 있을 뿐만 아니라 재해 복구 역량도 강화할 수 있습니다."라고 Michal은 말합니다.

확장성 요구에 대응하는 부분에 있어 Zillow는 이제 좀 더 민첩해졌습니다. "메이저 애플리케이션 버전을 변경하고자 할 때는 언제든 Amazon EC2 인스턴스를 구동할 수 있고, 클릭 몇 번으로 새로운 Amazon CloudFront 배포를 생성할 수도 있습니다. 전체적으로 AWS 덕분에 더 빠르게 움직일 수 있게 되었습니다."라고 Daud는 말합니다.

또한, 조직의 시스템 성능에 대한 가시성이 향상되었습니다. "일부 이미지 처리가 지연되기도 했었고, 클라우드 앱의 초기 버전은 충분한 지표를 제시하지 않아 파이프라인의 어느 구성 요소로 인해 지연이 발생하는지 파악할 수 없었습니다. Amazon CloudWatch를 사용해 지연 시간을 추적한 이후로, 원인을 훨씬 더 명확히 파악하고 이를 제거하기 위한 조치를 취하게 되었습니다."라고 Michal은 말합니다.

Zillow는 서비스를 클라우드로 이전할 추가적인 기회를 계속해서 모색할 것입니다. Michal은 "우리가 처음 AWS로 마이그레이션했을 때 CloudFront는 상대적으로 새로운 서비스였습니다. 우리가 위험을 감수하고 있다고 생각했습니다. 하지만 서비스 자체가 그렇지 않음을 입증했습니다. 앞으로 새로운 프로젝트와 서비스를 진행할 때는 AWS를 고려할 것입니다. AWS와의 경험은 훌륭했습니다."라고 말합니다.