포스트모템: 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 지연·트래픽 우회 전략을 사전에 검증하고, 장애 시 다른 클러스터로 즉시 전환할 수 있는 구조를 마련하는 것이 중요하다.