2023 AWS re:Invent — Safe Migration at Netflix
안녕하세요, 스푼라디오 Service Platform Team의 백엔드 개발자 Elliott입니다. 개발자로서의 커리어에서 처음으로 AWS re:Invent에 참여하게 되었는데요, 이번 행사에서 다양한 키노트와 세션들을 경험하며 많은 인사이트를 얻을 수 있었습니다. 여기서 제가 가장 인상 깊었던 세션과 그 내용에 대해 소개해드리고자 합니다.
AWS re:Invent
AWS re:Invent는 아마존 웹 서비스가 주최하는 대규모 기술 컨퍼런스로, 클라우드 컴퓨팅과 관련된 최신 트렌드와 기술을 공유하는 장입니다. 매년 라스베가스에서 열리며, 전 세계의 개발자, 엔지니어, IT 전문가들이 모여 새로운 아이디어와 기술을 나눕니다.
KeyNote
최근 산업계 전반의 패러다임이 인공지능(AI)을 중심으로 전환되면서, AWS re:Invent의 발표 내용 대부분은 AI 관련 신규 서비스와 기존 서비스의 업데이트, 새로운 버전 등에 집중되었습니다. 특히 주목할 만한 부분은, 엔비디아(NVIDIA)의 CEO인 젠슨 황이 연사로 초청되어 현재 AWS와 엔비디아 간의 협업에 대해 발표한 점입니다. 이 협업은 AI와 관련된 기술 개발에 중요한 역할을 하고 있으며, 이번 행사에서 중요한 하이라이트 중 하나로 다뤄졌습니다.
Technologies
세션 내용을 소개하기 전에, 먼저 세션에서 다룬 주요 기술들에 대해 간략히 설명드리겠습니다.
Cassandra
Apache Cassandra는 고성능, 분산형 NoSQL 데이터베이스 관리 시스템으로, 뛰어난 확장성과 가용성을 제공합니다. Cassandra는 대규모 데이터셋을 다루는 빅데이터 애플리케이션에 적합하며, 특히 많은 양의 데이터를 쓰고 읽는 작업에 최적화되어 있습니다.
- 분산 아키텍처: Cassandra는 데이터를 여러 노드(서버)에 걸쳐 분산시키며, 이는 높은 확장성과 장애 내성을 보장합니다.
- 스케일 아웃: 수평적 확장이 가능해, 데이터양이 증가함에 따라 더 많은 노드를 추가할 수 있으며, 이는 시스템의 성능을 균일하게 유지합니다.
- 마스터리스 아키텍처: 모든 노드가 동일한 역할을 하므로, 단일 장애 지점(Single Point of Failure)이 없습니다.
- 복제: 데이터는 자동으로 여러 노드에 복제되어, 어느 하나의 노드가 실패해도 데이터의 손실이 없습니다.
- 고성능: 특히 대량의 데이터를 빠르게 쓰고 읽는 데 최적화되어 있습니다.
Cassandra Thrift
Cassandra Thrift는 Apache Cassandra의 초기 데이터베이스 인터페이스 중 하나입니다. Thrift는 아파치 소프트웨어 재단에서 개발한 크로스-플랫폼 및 언어 간 서비스 개발 프레임워크로, 여러 프로그래밍 언어를 지원합니다. Cassandra Thrift 인터페이스는 Cassandra의 초기 버전에서 클라이언트 애플리케이션과 데이터베이스 간의 통신을 위해 사용되었습니다.
- 언어 중립성: Thrift는 여러 프로그래밍 언어를 지원하여, 다양한 언어로 작성된 클라이언트 애플리케이션들이 Cassandra 데이터베이스와 통신할 수 있도록 해줍니다.
- IDL(Interface Definition Language): Thrift는 IDL을 사용하여 데이터 구조와 서비스 인터페이스를 정의합니다. 이를 통해 클라이언트와 서버 간의 계약을 명확히 할 수 있습니다.
- 다양한 프로토콜 지원: Thrift는 바이너리, JSON 등 다양한 프로토콜을 지원하여, 네트워크 통신의 유연성을 제공합니다.
Dynomite
Netflix Dynomite는 Redis와 Memcached를 위한 분산 시스템 레이어입니다. 기존의 인메모리 키-값 저장소를 확장하여 높은 가용성과 크로스 리전 복제 기능을 제공합니다.
- 데이터 복제: 데이터의 여러 복사본을 관리하여 장애 내성을 강화합니다.
- 크로스 리전 복제: 다른 지역에 데이터 센터가 있는 경우에도 데이터를 복제할 수 있습니다.
- 확장성과 성능: 대규모 분산 환경에서도 높은 성능을 유지합니다.
- 호환성: Redis와 Memcached와의 호환성을 제공합니다.
EVCache
EVCache는 Netflix에서 개발한 분산 인메모리 캐싱 솔루션입니다. 이는 멀티-리전, 고가용성을 제공하며, 주로 대규모 웹 애플리케이션의 데이터 캐싱에 사용됩니다.
- 고가용성: 여러 데이터 센터에 걸쳐 데이터를 캐싱하여 가용성을 높입니다.
- 대규모 분산 시스템: 대용량의 데이터를 효율적으로 처리할 수 있습니다.
- 빠른 데이터 액세스: 메모리 기반의 데이터 저장으로 빠른 액세스를 제공합니다.
- 유연성: Redis나 Memcached와 함께 사용할 수 있으며, 다양한 환경에 적응할 수 있습니다.
Session
Problem of state
넷플릭스는 글로벌 서비스를 제공하는 기업으로, 4개의 리전에서 운영되는 서비스를 각각 3개의 가용성 영역에 12개의 데이터 복사본으로 유지하고 있습니다. 이러한 대규모 운영으로 인한 트래픽은 다양한 도전을 야기합니다.
개발자들은 한 자릿수 밀리초(ms) 단위의 빠른 응답 시간을 기대하지만, 이는 항상 달성하기 어렵습니다. 이에 따라, 저장소와 시스템 구조 변경에 따른 마이그레이션 능력의 중요성이 강조됩니다.
넷플릭스는 다양한 마이크로서비스를 운영하며, 이 서비스들은 각각 다른 요구사항을 가집니다. 이는 서비스마다 필요한 데이터베이스, 스토리지, 프로그래밍 언어 등에서 다양한 구성 요소의 조합을 필요로 한다는 것을 의미합니다.
마이그레이션 과정에서 정적인 데이터 상태는 상대적으로 관리하기 쉽지만, 동적인 상황(무중단 마이그레이션)에서는 문제가 복잡해질 수 있습니다. 개발자들은 초기 서비스 개발 당시에 더 나은 솔루션이나 데이터 구조를 선택했으면 어땠을까 하는 생각을 종종 합니다.
이러한 고민은 넷플릭스뿐만 아니라 우리에게도 해당되는 것 같습니다.
AWS는 지속적으로 새로운 기능을 출시하고 있습니다.
DynamoDB Global Tables, Aurora Global DB, S3의 strong read-after-write와 같은 기능들은 서비스 확장에 따라 Managed-service와 Self-managed service 간의 비용 차이가 시간이 지남에 따라 커지는 것을 보여줍니다.
넷플릭스 내에서는 Managed-service의 비용 부담을 줄이기 위해 Self-managed service로의 전환 가능성과 방법에 대한 고민이 자주 이루어지는 것으로 보였습니다.
운영 시간이 길어짐에 따라 비용 효율성에 대한 고려가 필요해지면서, 다양한 자체 개발 솔루션이 지속적으로 등장하는 추세였습니다. 그럼에도 불구하고 가능한 한 데이터베이스 마이그레이션을 피하는 것이 더욱 바람직하다는 의견이 제시되었습니다.
이와 관련된 전략을 나누는 세션(NFX305)도 있다고 하니, 참고할 만합니다. 만약 마이그레이션이 불가피하다면, 아래의 주요 내용들을 충분히 숙지하고 이해한 상태에서 진행하는 것이 중요하다고 강조되었습니다.
Techniques to migrate state
마이그레이션 실행을 위한 스테이지는 아래와 같습니다.
- Setup: 게이트웨이 기반 마이그레이션 진행을 위한 기반 코드 작업
- Shadow: 다른 데이터베이스로 접근을 구현한 다음 프록시 레이어
- Backfill: 원본 서비스에서 생성된 데이터를 신규 데이터베이스로 이전
- Promote: 다른 데이터베이스로 접근을 구현한 곳으로 프록시하는 과정
- Decom: 기존 데이터베이스로 접근하는 구현을 제거
Migration setup (API)
마이그레이션을 진행하기 전에 읽기, 쓰기 작업에서 신규 데이터베이스로 데이터를 처리하기 위한 기본적인 작업들을 진행합니다.
위 작업 과정 중 'Last-write-wins tokens' 처리 과정은 흥미롭게도 시간 기반 토큰 생성을 활용합니다. 이 방식은 토큰의 유일성을 높이기 위해 시간 인자를 사용하나, 분산 시스템에서는 권장되지 않는 접근법으로 여겨집니다. 일반적으로 사용되는 커널의 타임스탬프 정확성이 현대 클라우드 시스템에 적용되기에는 높지 않기 때문입니다. 이는 커널 타임스탬프가 현대 클라우드 시스템을 고려해 개발되지 않았다는 것을 의미합니다.
그러나, EC2 환경을 Nitro 기반으로 전환했을 때, 이러한 문제가 상당히 개선되었다고 합니다. Nitro 시스템에서는 최신 커널을 사용하며, AWS의 원자 시계와 GPS를 활용할 수 있기 때문에 더 높은 정확성을 제공합니다. 이는 분산 시스템에서의 타임스탬프 사용과 관련하여 새로운 가능성을 열어주는 사례로 볼 수 있습니다.
Traffic shadowing and backfill
마이그레이션 시 트래픽 조정 방식은 라이브러리와 게이트웨이를 이용한 방식이 있는데 라이브러리를 이용한 방식의 특징은 아래와 같습니다.
위와 같은 특징중 단점들 때문에 넷플릭스에서는 가능하면 게이트웨이를 이용한 마이그레이션을 주로 진행한다고 합니다.
Idempotent backfill
Backfill 과정에서는 여전히 운영 중인 기존 시스템에서 생성된 데이터를 새로운 데이터베이스로 이전하고 복제하는 작업이 필요합니다.
이 과정을 수행하기 위해 backfill 프로세스를 활용합니다.
Backfill 시, 반드시 기존 데이터베이스를 조회할 필요는 없습니다. 예를 들어, S3에 저장된 백업본을 활용하여 데이터를 처리할 수도 있으며, 필요에 따라 기존 데이터베이스를 조회하여 backfill 처리하는 방식으로 쓰기 작업의 부하를 조절할 수 있습니다. 이러한 접근 방식은 효율적인 리소스 관리와 시스템 부하 최소화에 도움이 됩니다.
Verification
Backfill 과정이 완료되면, 이전된 데이터의 유효성 검증이 필수적입니다. 이 검증 과정은 온라인(Online)과 오프라인(Offline) 비교 방식으로 나뉩니다.
온라인 검증은 두 데이터베이스 간의 데이터를 직접 비교하는 방식입니다. 이 방식에서는 소스 데이터베이스의 스캔 기능을 활용하는데, 이는 대규모 데이터 검색에 효율적이기 때문입니다. 그러나 타깃 데이터베이스의 경우, backfill 중 데이터 순서가 보장되지 않기 때문에 스캔보다는 데이터 단위의 검증(Get 방식)이 더 효율적이라는 것이 밝혀졌습니다.
이와 같은 비효율성을 개선하기 위해 오프라인 방식의 데이터 비교를 도입했습니다. 검증 과정에서는 테스트 단계에서 상대적으로 적은 양의 데이터에 대해서만 온라인 검증을 진행하고, 페타바이트(PiB) 수준의 데이터 세트 크기에 대해서는 오프라인 검증을 수행합니다. 이렇게 하여 실제 서비스에 영향을 주지 않으면서도 데이터의 정확성을 보장할 수 있습니다.
Migration Metrics
마이그레이션을 테스트 및 진행 시 발생할 예외적인 케이스, 버그 및 성능 모니터링을 위해서 CPU profile, Canary를 이용하여 데이터 정합성 등을 확인 했다고 합니다.
마이그레이션 전체 Stage의 대략적인 플로우는 아래의 이미지와 같습니다.
Shadow로 시작하여 Backfill을 진행하고 동작 상황을 모니터링 하고 문제가 발생하는 경우 버그를 픽스 후에 모니터링을 합니다.
버그가 해결된 이후에 두 번째 구현체로 Promote를 진행하고 모니터링 이후에 Decom을 하거나 Rollback 하는 방식으로 스텝을 변경합니다.
넷플릭스에서는 최종적으로 2023년에 250개가 넘는 데이터베이스를 마이그레이션 했고 이에 의해서 300개 이상의 애플리케이션에 영향을 미치고 수천 테라바이트의 데이터를 처리하고 최종적으로 12개의 마이그레이션 경로가 생성 되었다고 합니다.
Case studies
넷플릭스에서 이 세션에 해당하는 마이그레이션을 진행하면서 생긴 몇가지 케이스들에 대한 소개입니다.
Cassandra major version upgrade
- Migration: Apache Cassandra 3.0 to 4.1
- Why: 3.0 지원이 종료되었고 4.1에 좋은 기능이 많이 추가 되었기 때문
- Concerns: 잘못된 설정과 작업 부하 변동
- Strategy: Shadow sample, then in-place
Cassandra를 새 버전으로 업그레이드 했지만 새 버전이 성능이 더 낮다는 것을 확인했고, 쓰기 지연시간이 거의 두배 가까이 증가함을 알 수 있었음.
신규 버전의 성능 저하 원인 분석
최근 성능 저하 문제를 겪고 있는 Cassandra 4.1 버전에 대한 분석을 진행했고, 이 과정에서 몇 가지 주요 구성 오류가 밝혀졌다고 합니다.
- 잘못된 가비지 컬렉터 설정: CPU 프로파일링 결과, Cassandra 4.1에서 실행되는 노드가 G1GC가 아닌 CMS 가비지 컬렉터를 사용하도록 설정되어 있었습니다.
- 보안 설정의 문제: 넷플릭스 환경에서는 Java 8에서 성능이 떨어지는 Sun Security가 사용되고 있었습니다. 이는 Java Crypto의 성능 저하에 큰 영향을 미쳤습니다.
- 다른 버전과의 비교: 반면, Cassandra 3.0에서는 성능이 더 우수한 Amazon Corretto crypto를 사용하고 있었습니다.
- 힙 메모리 사용량 차이: Cassandra 4.1은 힙 메모리 사용량이 더 높았으며, 힙 설정에서도 차이가 있었습니다.
- 데이터 전송 속도 제한: 이 버전에서는 데이터 전송 속도가 제한되어 있었기 때문에 JVM의 힌트 처리에 밀려 있는 상황이었습니다.
성능 개선 조치 및 결과 이러한 구성 문제들을 수정한 후, 프로파일 정보를 통해 신규 버전의 성능이 크게 개선된 것을 확인할 수 있었습니다. 이는 시스템 성능 최적화에 있어 정확한 구성과 설정의 중요성을 잘 보여줍니다.
Cassandra Thrift to CQL Migration
- Migration: Apache Cassandra 2.1 Thrift to 3.0 CQL
- Why: Thrift deprecated 2016
- Concerns: 스토리지 엔진이 재개발 된 수준으로 바뀌었다.
- Strategy: Shadow, backfill, parity checks
마이그레이션 진행 시 버그 및 문제들은 아래와 같이 발생 했다고 합니다.
- Multi-partition read regression
- Pagination inefficiencies
- Scan partitioner differences
위와 같은 문제점이 생긴 이유는 마이그레이션의 대상이 되는 두 솔루션 간의 내부 구현 차이점에 의한 이슈였습니다.
Cassandra Thrift
- Random partitioner
- MD5 Hash
- 128-bit hash token
CQL
- Murmur3 partitioner
- Murmur hash
- 64-bit hash token
위와 같은 문제를 해결하기 위한 솔루션은
- Scan에 대한 Shadow를 반복 처리하고 토큰을 정규화 했습니다.
- Promotion을 지나서 스캔할 때는 라우팅 헤더를 사용하도록 변경했습니다.
Dynamite to KeyValue
- Migration: Netflix Dynomite to KeyValue
- Why: Dynomite 보다 Cassandra + EVCache가 성능적으로 더 낫다는 것을 확인
- Concerns: 개발자들이 빠른 레이턴시를 기대하기 때문
- Strategy: Shadow, backfill via writes(TTL)
이 마이그레이션에서는 놀랍게도 버그가 없었다고 하네요.
Conclusions
- 마이그레이션이 복잡하고 시간이 많이 걸릴 수 있지만 적절한 자동화를 통해 마이그레이션을 단순화 할 수 있다.
- 새버전에는 정확성 및 성능 버그가 있을 수 있지만 적절한 평가를 진행하는 것은 우리에게 달렸다.
- API와 데이터 마이그레이션을 함께 수행하는 것을 항상 피해야한다.
- 이기종 마이그레이션보다 동종 마이그레이션을 진행해야한다.
My Insights
이번 세션을 통해, 큰 기업들이 성능 개선에 상상 이상의 많은 리소스를 투입하고 있다는 사실을 알게 되었습니다.
이들은 단순히 성능을 향상시키는 것에 그치지 않고, 효율성을 높이기 위한 자동화까지 고려하고 있었습니다.
이러한 접근 방식은 매우 인상적이었습니다. 마이그레이션을 일회성 이벤트로 보지 않고, 비슷한 마이그레이션을 앞으로도 계속 진행할 것을 염두에 두며 자동화가 가능한 영역에 대해 고민합니다.
결과적으로, 향후 투입될 리소스를 고려하여 전반적인 효율성을 증가시키려는 노력이 세션에서 뚜렷하게 드러났습니다.
스푼라디오에서 근무하며, AWS re:Invent라는 큰 행사에 참여할 기회를 주신 것에 대해 깊이 감사드립니다. 이번 참여를 통해 분야에 대한 더 넓은 시야를 갖게 되었으며, 큰 배움과 새로운 경험을 할 수 있었다고 생각합니다.
