Intercom의 스태프 엔지니어는 Rails 애플리케이션에서 32비트 정수형 primary key 오버플로우로 인해 대규모 서비스 중단이 발생한 사례와 그로부터 얻은 교훈을 설명합니다. 2월 22일 오전 8시, `conversation_part` 테이블의 primary key가 32비트 정수 한계(약 21억 4천만)를 초과하며 `ActiveModel::RangeError` 예외가 급증했습니다. 이는 신규 대화 생성을 불가능하게 하여 서비스 핵심 기능이 마비되는 심각한 상황을 초래했습니다.
사고 인지 후 conversation_part 테이블의 BIGINT 마이그레이션을 시작했으나 장시간이 예상되어 임시 해결책이 필요했습니다. 긴급 대응팀은 모델 접근자 몽키 패치 및 다른 관계를 통한 ID 우회 방식으로 주요 서비스 흐름을 복구했으나, 다른 모델에서도 유사 문제가 발견되어 일부 기능은 임시 비활성화했습니다.
BIGINT 마이그레이션 완료 후에도 서비스 재활성화 시 예외가 재발했는데, 이는 수만 개의 Rails 프로세스들이 이전 스키마를 캐싱하고 있었기 때문이었습니다. 전체 서비스 재배포 후에야 비로소 정상화되었습니다.
이번 사고는 과거 성공 경험이 학습 시스템화를 저해하고, foreign key 종속성을 누락한 불완전한 런북이 직접적인 원인이었음을 드러냈습니다. Intercom은 재발 방지를 위해 CI 환경에서 32비트 정수 오버플로우 자동 감지 메커니즘을 구현하고, `ActiveModel::RangeError` 예외 메시지에 필드 이름을 포함시켜 디버깅 효율성을 높였습니다. 궁극적으로, 인시던트 교훈을 체계적으로 문서화하고, 런북에 충분한 컨텍스트를 포함하며, 자동화된 검증 시스템을 구축하는 것이 서비스 안정성 유지에 필수적임을 강조합니다.