Rethinking latency-sensitive DynamoDB apps for multicloud, multiregion deployment 광고를 전달하는 전체 프로세스는 200~300밀리초 이내에 이루어집니다.우리의 데이터베이스 검색은 1자리 밀리초로 완료해야 합니다.매일 수십억 개의 트랜잭션을 수행하면 데이터베이스가 빠르고 확장 가능하며 신뢰할 수 있어야 합니다. - Todd Coleman, 기술 공동 설립자 및 Yieldmo의 최고 건축가 광고를 전달하는 전체 프로세스는 200~300밀리초 이내에 이루어집니다.우리의 데이터베이스 검색은 1자리 밀리초로 완료해야 합니다.매일 수십억 개의 트랜잭션을 수행하면 데이터베이스가 빠르고 확장 가능하며 신뢰할 수 있어야 합니다. - Todd Coleman, 기술 공동 설립자 및 Yieldmo의 최고 건축가 Yieldmo의 온라인 광고 사업은 매일 수십억 개의 광고 요청을 subsecond latency 응답으로 처리하는 것에 의존합니다. 회사의 서비스는 처음에는 DynamoDB에 의존했으며 팀은 단순성과 안정성을 높이 평가했습니다.그러나 DynamoDB 비용은 규모가 불안정해지고 팀은 Yieldmo가 새로운 지역으로 확장함에 따라 다중 클라우드 유연성을 필요로했습니다.인프라 선택은 비즈니스 제약이 될 위협이되었습니다. 최근에 한 대화에서 Todd Coleman, Yieldmo의 기술 공동 설립자이자 CEO는 회사가 직면 한 기술적 도전과 ScyllaDB의 DynamoDB 호환 API로 팀이 궁극적으로 앞으로 나아가는 이유를 공유했습니다. 몬스터 스케일 정상회담 당신은 아래의 그의 전체 토론을 볼 수 있습니다 또는 리뷰를 위해 계속 읽을 수 있습니다. https://youtu.be/sk0mIiaOwM8?embedable=true Lost Business = 잃어버린 사업 Yieldmo는 게시자와 광고주를 페이지 로드로 실시간으로 연결하는 온라인 광고 플랫폼입니다.거의 모든 광고 요청은 기계 학습 통찰력과 장치 정체성 정보를 검색하는 데이터베이스 쿼리를 촉발합니다.이 쿼리는 광고 서버가 다음을 수행 할 수 있습니다. 효율적인 경매 파트너가 제안을 할지 여부를 결정하는 데 도움 광고주가 주파수를 관리하고 광고 배달을 최적화할 수 있도록 장치에 이미 표시된 광고를 추적하십시오. 전체 광고 파이프라인은 단지 200 ~ 300 밀리 초 만에 완료되며, 그 시간의 대부분은 파트너가 거래를 평가하고 배치하는 데 소비됩니다. 사용자가 웹사이트를 방문하면 Yieldmo에 광고 요청이 전송됩니다. Yieldmo의 플랫폼은 요청을 분석합니다. 그것은 파트너로부터 잠재적 인 광고를 요청합니다. 그것은 우승 제안을 결정하기 위해 경매를 실시합니다. 데이터베이스 검색은 파트너에게 전화를 걸기 전에 이루어져야 합니다. 그리고 이러한 검색은 단일 숫자 밀리초 지연 시간으로 완료되어야 합니다. Coleman은 “매일 수십억 개의 거래로 데이터베이스는 빠르고 확장 가능하며 신뢰할 수 있어야 합니다. DynamoDB 성장 통증 Yieldmo의 생산 인프라는 AWS에서 실행되므로 DynamoDB는 팀이 앱을 구축했을 때 논리적 인 선택이었습니다. 첫째, DynamoDB는 비즈니스 확장에 따라 점점 더 비싸고 있었고, 둘째, 회사는 AWS 이외의 클라우드 공급자에서 광고 서버를 실행할 수 있는 옵션을 원했습니다. Coleman은 "일부 지역에서는 예를 들어 미국 동부 해안, AWS 및 GCP [Google Cloud Platform] 데이터 센터가 최소한의 지연 시간에 충분히 가깝습니다.GCP에서 실행되는 광고 서버에서 DynamoDB 데이터베이스에 도달하는 것은 아무런 문제가 없습니다.그러나 다블린에서 DynamoDB에 액세스하는 동안 암스테르담에서 GCP 기반 광고 서버 클러스터를 시작하려고 시도했을 때 지연 시간은 너무 높았습니다.우리는 진정한 멀티 클라우드 유연성을 원한다면 어디서나 배포할 수 있는 데이터베이스가 필요하다는 것을 빨리 깨달았습니다." DynamoDB 대안 Yieldmo의 팀은 매우 읽기 힘든 데이터베이스 워크로드에 적합한 DynamoDB 대안을 탐구하기 시작했습니다.Their writing operations fall into two categories: 파트너로부터 실시간 데이터의 지속적인 흐름은 Yieldmo의 데이터를 그들의 데이터와 일치시키는 데 필수적입니다. 그들의 역사적 데이터로부터 유래된 기계 학습 통찰력에 의해 구동된 배치 업데이트 높은 주파수 읽기와 구조화 된 쓰기의 이 균형을 감안할 때, 그들은 성능의 악화없이 동시에 업데이트를 효율적으로 관리하면서 대규모, 낮은 지연 액세스를 처리 할 수있는 데이터베이스를 찾고있었습니다. 팀은 먼저 DynamoDB와 함께 머물고 캐시 레이어를 추가하는 것을 고려했습니다.그러나, 그들은 캐시가 지리적 지연 문제를 해결할 수 없다는 것을 발견했으며이 옵션으로 캐시 실패가 훨씬 느려집니다. 그들은 또한 속도와 크로스 클라우드 지원을 제공하는 Aerospike를 탐구했습니다.그러나 Aerospike의 메모리 인덱싱은 Yieldmo의 소규모 데이터 객체를 다루기 위해 엄청나게 크고 비싼 클러스터가 필요했을 것이라는 것을 알게되었습니다. ScyllaDB는 속도와 크로스 클라우드 지원을 제공했지만 DynamoDB 호환 API (Alternator)와 저렴한 비용을 제공했습니다. Coleman은 "ScyllaDB는 크로스 클라우드 배포를 지원하고 관리 가능한 수의 서버를 필요로하며 경쟁력있는 비용을 제공했습니다. 가장 좋은 점은 API가 DynamoDB 호환이었기 때문에 최소한의 코드 변경으로 마이그레이션할 수 있었습니다. ScyllaDB 평가, 마이그레이션 및 결과 ScyllaDB가 환경에서 어떻게 작동하는지 평가하기 위해 팀은 한 지역에 광고 서버의 하위 집합을 마이그레이션했습니다.이 작업은 실시간 업데이트를 유지하면서 여러 테라바이트를 마이그레이션하는 것을 포함했습니다. 프로세스 방식으로, ScyllaDB의 Spark 기반 마이그레이션 도구가 역사 데이터를 복사하고 ML 배치 작업을 중단하고 카프카 아키텍처를 사용하여 최근 글을 ScyllaDB로 재생했습니다. ~28 억 개체 (~3.3 TB)가있는 단일 DynamoDB 테이블을 이동하는 데 약 10 시간이 걸렸습니다. 다음 단계는 다섯 개의 AWS 지역에 걸쳐 모든 데이터를 마이그레이션하는 것이 었습니다.이 단계는 약 2 주가 걸렸습니다.성능을 평가 한 후 Yieldmo는 ScyllaDB를 기본 상태로 승진시켰고 대부분의 지역에서 DynamoDB로 쓰기를 중단했습니다. 거의 1년 후 마이그레이션에 대해 생각하면서 콜먼은 “최고의 이점은 멀티 클라우드 유연성이지만, 그 없이는 마이그레이션이 가치가 있었다.데이터베이스 비용은 DynamoDB에 비해 대략 절반으로 절감되었으며, 예비 용량 가격으로도 겸손한 지연 개선을 보였습니다. ScyllaDB는 신뢰성이 입증되었습니다: 그들의 팀은 우리의 클러스터를 모니터링하고, 문제에 대해 우리에게 경고하고, 확장에 대해 조언합니다. ScyllaDB가 DynamoDB와 비교하는 방법
