Hacker News 의견

• 이 글을 보면 수동 장애 조치(failover) 중에도 애플리케이션이 평소처럼 쓰기 트래픽을 유지하려 하면 항상 실패하는 것처럼 보임
  하지만 몇 가지 의문이 생김. 다른 Aurora 사용자들은 왜 이런 문제를 항상 겪지 않는지, AWS가 모를 리가 있는지, 만약 알고 있다면 왜 P0급 긴급 이슈로 다루지 않는지 궁금함
  혹시 진행 중인 트랜잭션 상태나 타임아웃 같은 미묘한 조건이 작용하는 걸지도 모른다는 생각이 듦

  • Azure에서 비슷한 문제를 다뤄본 경험상, 많은 사람들이 겪지만 재시작으로 해결되니 그냥 넘어가는 경우가 많음. 근본 원인을 찾기 어렵고, 벤더와 함께 분석하는 과정이 너무 고통스러워서 대부분 포기함
  • 우리도 AWS와 협업하면서 같은 문제를 확인했음. 트래픽 패턴이 특별하지 않았고, 다른 리전에서는 재현되지 않았음. 이건 Aurora의 근본적인 장애 조치 메커니즘 결함일 가능성이 높음
  • 예전에 Python + MySQL 조합에서 SELECT ... FOR UPDATE가 조용히 실패하고 트랜잭션이 autocommit 모드로 전환되는 버그를 겪은 적이 있음. 아무도 관심을 안 가져서 혼자 떠들었는데, 몇 달 뒤 다른 사람도 같은 문제를 겪었다고 연락이 옴. 결국 수정되긴 했지만 이미 관심을 끊은 뒤였음
    관련 링크: Stack Overflow 질문
  • AWS는 내부 정보를 거의 공개하지 않음. API 수준 이상의 세부 내용을 알려주지 않기 때문에, 이런 문제를 희귀 케이스로 치부하고 넘어가는 듯한 느낌을 받음
  • 문제의 일부는 애플리케이션이 되돌려진 장애 조치(reverted failover) 에 반응하는 방식 때문일 수도 있음. 캐시가 깨져 잘못된 프라이머리로 계속 쓰기를 시도한 듯함. 이런 실패가 종종 일어나도, 재시도하면 성공하니 사용자들이 AWS에 신고하지 않아 AWS가 인지하지 못했을 가능성도 있음

• Aurora PostgreSQL에서 예상치 못한 동작을 여러 번 봤음
  특히 Zero Downtime Patching(ZDP) 중 세션 상태가 잘못 유지되어, 간단한 쿼리조차 statement_timeout보다 훨씬 빨리 취소되는 현상을 겪었음
  내 추측으로는 클라이언트가 재연결될 때, Aurora가 이전 세션의 오래된 타이머 상태를 그대로 이어받아 쿼리가 즉시 취소되는 것 같음

• 우리도 쓰기 트래픽이 매우 높은 환경에서 정기적으로 장애 조치를 수행하지만, AWS JDBC wrapper를 사용해 자동화된 프로세스로 안정적으로 운영 중임

  • 실제로는 Aurora의 스토리지 계층이 ACID 위반을 막아줬음, 즉 데이터 무결성은 지켜졌음

• Aurora가 이런 기본적인 불변성을 유지해줄 거라 믿고 돈을 내는 건데, 이런 문제가 생기다니 놀라움

  • 하지만 스토리지 계층 자체는 동시 쓰기를 차단해 올바르게 동작했음

• 로그와 AWS의 설명을 보면, 원글 작성자의 가설은 틀린 듯함
  프로모션 실패 후 외부 감시 프로세스가 클러스터 상태 불일치를 감지하고 강제 종료(kill -9) 한 것으로 보임. 스토리지 서브시스템 관련 메시지는 그 이후에 발생한 것임

• Aurora와 RDS Postgres의 성능 비교에 대해 묻고 싶음.
  멀티 AZ나 빠른 장애 조치가 필요 없다면, RDS에서 gp3 64k IOPS 구성으로 더 나은 성능을 낼 수 있을까? Aurora는 특히 insert 성능이 느리고 비용이 높아 보임. 벤치마크들도 RDS 설정을 명확히 밝히지 않아 신뢰하기 어려움

  • 우리는 Aurora PG 14에서 1 writer + 1~2 reader 구성으로 더 나은 성능과 낮은 비용을 얻었음. Aurora는 인스턴스별이 아닌 클러스터 단위 스토리지 과금이라 유리함.
    또한 IOPS를 직접 프로비저닝할 필요가 없고 약 80k IOPS를 제공함.
    IO 과금 방식도 두 가지가 있는데, pay-per-IO는 저부하 환경에, 고정 요금 모드는 IO가 많은 워크로드에 유리함.
    참고로 Serverless는 거의 항상 비경제적이었음. 짧은 피크 타임이 있는 경우에만 유용함
  • 우리 팀은 Aurora Postgres RDS에서 I/O 비용 폭증을 겪었음. 단 몇 개의 fuzzy query로 월 $3,000 이상이 나왔고, 원래는 $100 이하였어야 했음
  • Aurora의 비용, 성능, 지연시간 모두 실망스러워 결국 온프레미스 PostgreSQL로 이전했음
  • Aurora MySQL 기준으로는, 같은 IOPS를 RDS에서 맞추려면 훨씬 비싼 비용이 들었음
  • Aurora는 EBS를 사용하지 않으며, 스토리지 타입이나 지연시간을 선택할 수 없음. 단지 IO 과금 방식을 고를 수 있을 뿐임

• AWS 엔지니어들이 말하는 “레고 블록 모델” 이 잘 드러남
  스토리지 계층을 완전히 독립적으로 설계해, 상위 서비스가 실패해도 데이터 일관성은 보장되었음. AWS 엔지니어링의 좋은 사례라고 생각함

• AWS가 “장애 조치 중에는 쓰기를 멈추라”는 권고를 했다고 하는데, 관련 케이스 번호를 공유받을 수 있는지 궁금함

  • 우리도 Aurora MySQL을 쓰고 있어서, 이 권고가 MySQL에도 적용되는지 확인하고 싶음

• 이런 문제를 겪은 게 나만이 아니라는 걸 알아서 다행임

  • AWS Support는 처음엔 복제 지연(replication lag) 때문이라며 반박했지만, 24시간 전의 오래된 메트릭을 보고 판단했음. 어떤 실패를 겪었는지, 다른 리전에서는 왜 재현되지 않았는지 정말 알고 싶음

• Aurora의 컴퓨트-스토리지 분리 아키텍처가 흥미로움
  MSSQL의 Hyperscale도 비슷한 구조인데, Azure 서비스 중 내가 실제로 써볼 만하다고 생각하는 거의 유일한 제품임