포스트모템: 20 (새 탭에서 열림)

Figma의 2022년 6월 서비스 장애는 Cluster-Mode Enabled(CME) ElastiCache Redis 노드의 Engine CPU가 100%에 도달하면서 발생했다. AWS는 CME 클러스터에서 높은 Redis Publish/Subscribe 부하를 처리할 때 발생하는 드문 버그를 원인으로 확인했으며, 트래픽을 새 ElastiCache 클러스터로 전환해 서비스를 복구했다. 장애는 총 네 차례 발생했지만 데이터 손실은 없었다.

장애 범위와 사용자 영향

• 장애 시간은 2022년 6월 6일 오후 11시 34분부터 7일 오전 10시 43분까지였다.
• 총 네 차례의 서비스 중단이 발생했으며, 각 장애는 7분에서 최대 1시간 20분 동안 지속됐다.
• 이미 열려 있던 파일은 계속 편집할 수 있었지만 다음 기능을 사용할 수 없었다.
  • 새 파일 열기
  • 다른 사용자와 협업
  • 일부 웹 API 기능
• 오프라인 상태에서 변경한 내용은 로컬에 저장됐고, 서비스가 회복될 때 서버에도 저장되어 데이터 손실은 발생하지 않았다.

ElastiCache와 Redis 구성

• Figma는 AWS의 관리형 Redis 서비스인 ElastiCache를 다음 용도로 사용했다.
  • 자주 조회되는 데이터의 빠른 처리
  • 서비스 간 메시지 전달
• 당시 두 종류의 ElastiCache 인스턴스를 운영했다.
  • Cluster-Mode Disabled(CMD): 단일 Redis 클러스터 구조
  • Cluster-Mode Enabled(CME): 노드를 추가해 수평 확장 가능
• 장애가 발생하기 몇 주 전, Figma는 Redis Publish/Subscribe 트래픽을 CMD에서 CME 인스턴스로 이전했다.
• 이전 후 몇 주 동안은 문제가 없었고, 장애 직전 트래픽이나 Redis 사용량에도 뚜렷한 변화가 없었다.

CPU 100%를 유발한 CME 버그

• 장애의 직접적인 징후는 CME ElastiCache 노드 하나의 Engine CPU 사용률이 100%에 도달한 것이었다.
• AWS 조사 결과, CME 클러스터에서 높은 Publish/Subscribe 부하가 발생할 때 Redis 내부의 드문 버그가 이 포화 상태를 유발한 것으로 확인됐다.
• ElastiCache 기반 시스템에서는 하부 머신의 CPU 프로파일을 직접 확인할 수 없었기 때문에, 어떤 작업이 CPU를 소모하는지 즉시 파악하기 어려웠다.
• Figma는 수년간 Publish/Subscribe를 사용했지만, CME로 이전하기 전까지는 같은 문제가 발생하지 않았다.

초기 대응과 클러스터 확장

• Figma는 원인을 용량 부족 또는 장애 난 하드웨어로 추정했다.
• 대응을 위해 다음 조치를 동시에 수행했다.
  • 문제가 있는 노드의 failover 시작
  • 더 큰 노드 타입과 더 많은 노드로 구성된 새 ElastiCache 인스턴스 생성
• 기존 노드의 failover가 예상보다 오래 걸리자, 새 클러스터인 V2로 트래픽을 전환해 서비스를 복구했다.
• 그러나 이후 같은 CPU 포화 문제가 V2에서도 재발했다.
• 결과적으로 클러스터 규모를 키우는 것이 이 버그를 해결하지 못했고, 오히려 상황을 악화시킬 수 있다는 사실이 드러났다.

원인 조사 과정

• Figma는 다음과 같은 가능성을 차례로 검토했다.
  • 정기 백업이나 예기치 않은 스냅샷이 노드를 일시적으로 과부하시켰을 가능성
  • Redis 명령어 사용량이 갑자기 증가했을 가능성
  • 느린 명령어, 대형 키 등 비정상적인 Redis 사용
  • 장애 직전에 실행된 백그라운드 작업
• 백업이나 스냅샷과 관련된 징후는 발견되지 않았다.
• Redis 명령어 사용량도 이전 몇 주와 비슷하고 안정적이었다.
• 장애가 시작된 뒤에는 많은 명령어의 처리 시간이 길어졌지만, 이는 CPU가 이미 포화된 결과로 판단됐다.
• 처리 시간이 긴 Redis 요청을 일부 차단했지만 문제를 해결하지 못했다.
• 장애가 트래픽이 감소하던 시점에도 재발했기 때문에, 단순한 피크 트래픽이나 용량 부족만으로는 설명할 수 없었다.

Failover를 통한 일시적 복구

• 두 번째 장애에서는 문제가 있는 노드의 failover가 정상적으로 완료되어 더 빠르게 서비스를 복구할 수 있었다.
• 장애가 반복되는 동안 Figma는 Redis 요청, 백그라운드 작업, 클러스터 구성 등을 계속 비교하며 공통 패턴을 찾았다.
• 최종적으로 AWS의 ElastiCache 서비스 팀이 CME 환경의 높은 Publish/Subscribe 부하와 관련된 Redis 버그를 확인했다.
• AWS는 이후 CME 클러스터에서 Redis Publish/Subscribe 성능을 개선하는 작업을 진행했다.

실용적인 결론

Redis의 Publish/Subscribe를 CME ElastiCache로 이전할 때는 단순히 노드 수나 인스턴스 크기를 늘리는 것만으로 안정성이 보장되지 않는다. 관리형 서비스에서는 하부 시스템의 프로파일링이 제한되므로, CPU 포화·failover 지연·트래픽 우회 전략을 사전에 검증하고, 장애 시 다른 클러스터로 즉시 전환할 수 있는 구조를 마련하는 것이 중요하다.