{"id":"IL-0301","org":"37signals","date":"2022-06-27","docs":[],"title":{"en":"Basecamp 3's primary database went into total gridlock at the top of the hour and Basecamp 3 went down twice","ko":"Basecamp 3 의 주 데이터베이스가 정시 부하에 락 경합으로 30초 만에 완전히 막혔다"},"domain":["database"],"impact":{"scope":"Basecamp 3 was slow, showed errors and was down for 103 minutes in total between 13:00 and 15:49 UTC; HEY, Basecamp 2 and Basecamp Classic were not affected and no data was lost","users":"Basecamp 3 users","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A system running just past its limits can flip from stable to unstable without any particular trigger, and steady growth plus small regressions that raised no alarm had brought Basecamp 3's primary database to that point. Under lock contention, terminating queries does not relieve the database, because rolling back their transactions waits on the same locks. The team struggled to respond with confidence because there was no single clear cause and little visibility into the database's internals.","ko":"37signals 는 이번 장애에 원인 하나가 없었다고 밝혔다. 시스템이 한계를 조금만 넘어도 순식간에 안정에서 불안정으로 넘어가는 지점이 있고, 그 지점은 특별한 계기 없이 성장과 함께 서서히 다가온다. 막힌 쿼리를 종료하는 일은 트랜잭션 롤백 때문에 같은 락에서 다시 막혀 정체를 키울 수 있다. 37signals 는 이 시스템을 잘 알면서도 결정적인 단서가 없고 데이터베이스 내부를 깊이 들여다볼 수단이 없어 확신을 갖고 대응하지 못했다고 썼다. 그래서 문제 하나를 고치는 대신 위험을 줄이고 확신을 쌓아 가는 길을 택했다."},"related":[],"sources":[{"url":"https://updates.37signals.com/post/accounting-for-the-basecamp-3-outage-on-june-27-2022","kind":"blog","archived":"https://web.archive.org/web/20250401034223/https://updates.37signals.com/post/accounting-for-the-basecamp-3-outage-on-june-27-2022"}],"summary":{"en":"Basecamp 3's primary database runs at very high concurrency, with thousands of connections from the Rails application servers and hundreds of execution threads on a large many-CPU server. At 13:00 UTC on June 27, 2022, when scheduled notifications go out in massive batches, a rush of demanding queries caused heavy lock contention. Queries waiting on locks held database resources and sometimes their own locks, and new queries kept arriving and opening new connections and threads that waited on the same locks, until the server was overwhelmed. 37signals found no single trigger: Basecamp 3's steady growth had moved the primary database close to its limits, and a review of the past year of database metrics found several quiet performance regressions that had added load without setting off any alarm.\n\nThe team paused parts of Basecamp 3, which slowed the pile-up, and terminated thousands of queries, which made it grow faster because the rollbacks wait on the same locks. The team then failed over to a replica by the book. Basecamp 3 came back, and then the database tipped over again from a different mix of factors, again lock contention under high concurrency. The team put Basecamp 3 into maintenance mode and set hard limits on database query time, which let the congestion clear, and then brought features back step by step with the query limits in place. The all-clear came at 15:49 UTC, nearly three hours after the start, with 103 minutes of downtime. No data was lost, and HEY, Basecamp 2 and Basecamp Classic were not affected.","ko":"2022년 6월 27일 13:00 UTC, 30초 사이에 Basecamp 3 의 주 데이터베이스가 완전히 막혔다. 이 시각은 Basecamp 3 가 각종 예약 알림을 대량으로 묶어 보내는 때였고, 부하가 큰 쿼리가 몰리면서 락 경합이 연쇄로 번졌다. 막힌 쿼리 수천 개가 기다리는 동안 새 쿼리 수천 개가 새 연결과 새 실행 스레드를 만들며 같은 락에 쌓였다. 서버 하드웨어가 스레드에 짓눌려 데이터베이스는 사실상 아무 일도 하지 못했다. 37signals 는 원인 하나를 집어낼 수 없었다고 밝혔다. Basecamp 3 가 빠르게 성장하면서 주 데이터베이스가 한계에 점점 다가갔고, 이날 처음으로 그 한계를 넘었다는 설명이다. 지난 1년의 지표를 다시 보니 알림을 울리지 않은 채 주 데이터베이스 부하를 서서히 늘린 성능 저하가 여러 건 있었다.\n\n37signals 는 진행 보고 이메일을 늦추는 식으로 일부 기능을 멈췄지만 데이터베이스는 이미 감당할 수 있는 선을 넘어 있었다. 막힌 쿼리 수천 개를 종료하자 트랜잭션 롤백이 같은 락에서 막히면서 정체가 더 커졌다. 대기 중이던 복제본으로 페일오버하자 서비스가 돌아왔지만, 멈췄던 기능을 다시 켜는 동안 다른 요인이 섞인 같은 종류의 락 경합으로 다시 무너졌다. 그다음 Basecamp 3 를 유지보수 모드로 바꾸고 데이터베이스 쿼리 시간에 강제 상한을 걸자 정체가 풀렸다. 쿼리 시간 상한을 안전장치로 둔 채 기능을 하나씩 다시 켰고, 장애 시작 후 거의 세 시간 뒤인 15:49 UTC 에 정상화를 알렸다.\n\n누적 중단 시간은 103분, 곧 1.7시간이었다. 데이터는 잃지 않았고 HEY, Basecamp 2, Basecamp Classic 을 비롯한 다른 제품은 영향을 받지 않았다."},"trigger":{"en":"At 13:00 UTC, when Basecamp 3 sends scheduled notifications in massive batches, a rush of demanding queries reached the primary database and started a cascade of heavy lock contention.","ko":"13:00 UTC 에 예약 알림을 대량으로 묶어 보내는 시각에 맞춰 부하가 큰 데이터베이스 쿼리가 한꺼번에 몰려들었고, 이 쿼리들이 주 데이터베이스에서 락 경합을 연쇄로 일으켰다."},"severity":"unknown","symptoms":["lock-contention","database-overloaded","high-latency","high-error-rate","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":"2h 49m"},"date_kind":"incident","detection":{"en":"The team saw the Basecamp 3 primary database become completely congested within 30 seconds of 13:00 UTC and responded immediately.","ko":"37signals 는 13:00:00 과 13:00:30 UTC 사이에 Basecamp 3 의 주 데이터베이스가 완전히 정체되는 것을 보고 곧바로 대응을 시작했다."},"components":["database"],"root_cause":"capacity","remediation":[{"text":{"en":"Paused and disabled parts of Basecamp 3, such as delaying progress report emails","ko":"주 데이터베이스의 부하를 덜려고 Basecamp 3 의 일부 기능을 멈췄다. 진행 보고 이메일을 그날 늦게 보내도록 미룬 것이 그 예다."}},{"text":{"en":"Failed over from the primary database to a replica, which brought Basecamp 3 back until it tipped over again","ko":"막힌 주 데이터베이스에서, 이런 장애에 대비해 대기 중이던 복제본 데이터베이스로 절차대로 페일오버했다."}},{"text":{"en":"Put Basecamp 3 into maintenance mode","ko":"페일오버 뒤 데이터베이스가 다시 무너지자 Basecamp 3 를 곧바로 유지보수 모드로 바꿨다."}},{"text":{"en":"Set hard limits on database query time","ko":"데이터베이스 쿼리 시간에 강제 상한을 걸었다."}},{"text":{"en":"Brought features back online step by step with the query limits in place","ko":"쿼리 시간 상한을 안전장치로 두고 기능을 한 단계씩 다시 켜서 서비스를 모두 되살렸다."}}],"action_items":[{"text":{"en":"Keep hard limits on database query time so slow queries fail instead of piling up","ko":"데이터베이스 쿼리에 강제 시간 상한을 둔다. 평소 빠르던 쿼리가 일정 수준 넘게 느려지면 기다리며 쌓이게 두지 않고 실패하게 한다."}},{"text":{"en":"Tune the limits on concurrency","ko":"동시 실행 한도를 조정한다. 일정 수준을 넘으면 병렬로 도는 작업이 많을수록 시스템 전체가 느려지기 때문이다."}},{"text":{"en":"Treat top-of-the-hour database load spikes from scheduled batches as unacceptable","ko":"서비스 수준 기대치를 더 엄격하게 잡고, 예약 알림과 보고서를 몇 분 안에 대량으로 보내며 생기던 정시 데이터베이스 부하 급증을 더는 용인하지 않는다. 제품 설계부터 데이터베이스 내부까지 이 부분을 살핀다."}},{"text":{"en":"Reduce the number of parallel workers for some scheduled jobs","ko":"일부 예약 작업을 돌리는 병렬 워커 수를 줄여 동시 실행과 락 경합을 낮춘다."}},{"text":{"en":"Let some scheduled activities run over several minutes instead of all at once","ko":"일부 예약 작업을 한꺼번에 끝내지 않고 몇 분에 걸쳐 돌려 데이터베이스 부하를 시간에 나눈다."}},{"text":{"en":"Move bursty queries from the primary database to read-only replicas","ko":"한꺼번에 몰려드는 쿼리 다수를 주 데이터베이스에서 읽기 전용 복제본 데이터베이스로 옮긴다."}},{"text":{"en":"Fix the quiet performance regressions found in a review of the past year of database metrics","ko":"지난 1년의 데이터베이스 지표에서 찾은 성능 저하 여러 건을 하나씩 고친다. 이 저하는 알림을 울리지 않았지만 주 데이터베이스 부하를 서서히 늘렸다."}},{"text":{"en":"Find and spread out other bursty activities that concentrate load on the database","ko":"한꺼번에 몰려드는 다른 작업을 찾아 분산해, 데이터베이스의 특정 지점에 부하가 몰리지 않게 한다."}},{"text":{"en":"Tune the database for more predictable behaviour under heavy load and high concurrency","ko":"높은 부하와 높은 동시성에서 더 예측 가능하게 동작하도록 데이터베이스를 조정한다."}},{"text":{"en":"Add observability into the database's internal locking and transaction states","ko":"데이터베이스 내부의 락과 트랜잭션 상태를 더 잘 볼 수 있도록 관측성을 높인다."}},{"text":{"en":"Build tools to switch off high-load Basecamp 3 features selectively during an incident","ko":"장애 중에 부하가 큰 Basecamp 3 기능을 골라 끌 수 있는 더 쓰기 편한 도구를 만든다."}},{"text":{"en":"Run operational fire drills for a wedged database","ko":"멈춘 데이터베이스에 대응하는 운영 훈련을 잡아 대응을 연습하고 다듬는다."}},{"text":{"en":"Evaluate upgrading the database software and hardware","ko":"앞으로 몇 년의 Basecamp 성장에 맞춰 확장할 수 있도록 데이터베이스 소프트웨어와 하드웨어 업그레이드를 검토한다."}},{"text":{"en":"Set service level objectives for the components behind Basecamp 3","ko":"Basecamp 3 를 받치는 구성 요소에 서비스 수준 목표, 곧 SLO 를 정해 데이터베이스 성능 변화를 더 일찍, 더 분명하게 알아챈다."}},{"text":{"en":"Hold quarterly performance and load reviews to catch slow, subtle changes","ko":"분기마다 성능과 부하를 검토해 눈에 띄지 않게 진행되는 성능 변화를 찾는다."}}],"contributing":["no-capacity-planning","manual-action-worsened","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"At 13:00 UTC on Monday, June 27, 2022, Basecamp 3 became extremely slow, then showed error pages, and then stopped working altogether. Basecamp 2 and Basecamp Classic kept working normally.\n\nBetween 13:00:00 and 13:00:30 UTC the Basecamp 3 primary database went from normal to completely congested. Queries piled up behind locks, and new queries kept arriving, opening new database connections and threads that waited on the same locks, until the server hardware was overwhelmed by thousands of threads. The database had not crashed, but it could not make progress.\n\nThe outage came in waves. After a failover to a replica, Basecamp 3 came back and paused features were re-enabled, and then the database tipped over again with the same kind of lock contention under high concurrency. Basecamp 3 was back around 15:45 UTC, and the all-clear came at 15:49 UTC with 103 minutes of downtime in total.\n\nThe first countermeasures did not stop it. Pausing and disabling parts of Basecamp 3, such as delaying progress report emails, only slowed the growth of the pile-up. Terminating thousands of bottlenecked queries made it grow faster, because each terminated query rolls back its whole transaction, and the rollback waits on the same locks.","ko":"2022년 6월 27일 13:00 UTC 에 Basecamp 3 가 갑자기 아주 느려졌고 곧 오류 페이지를 보였다. 같은 30초 사이에 Basecamp 3 의 주 데이터베이스가 정상에서 완전한 정체 상태로 넘어갔다.\n\n사용자 쪽에서는 일부 기능이 동작하기는 했지만 응답이 한참 걸렸다. Basecamp 2 와 Basecamp Classic 은 정상이었다. 그 뒤 Basecamp 3 의 모든 기능이 멈췄고, 몇 분 뒤 돌아온 듯하다가 다시 느려지며 오류를 보였다. 15:45 UTC 무렵에야 Basecamp 3 가 돌아와 그 상태를 유지했다.\n\n데이터베이스 안에서는 13:00:00 과 13:00:30 UTC 사이에 락 경합이 연쇄로 번졌다. 수천 개의 쿼리가 락을 기다리며 막혀 있는 동안에도 수천 개의 새 쿼리가 계속 들어왔다. 새 쿼리 다수가 새 데이터베이스 연결을 열었고, 연결마다 새 실행 스레드가 생겨 같은 락에서 다시 막혔다. 서버 하드웨어는 수천 개의 실행 스레드에 짓눌렸다. 데이터베이스가 죽은 것은 아니었지만 동시 작업을 조율하는 비용에 묶여 사실상 아무 일도 진행하지 못했다.\n\n37signals 는 먼저 주 데이터베이스의 부하를 덜려고 Basecamp 3 의 일부 기능을 멈췄지만, 데이터베이스는 이미 감당할 수 있는 선을 한참 넘은 뒤였다. 막힌 쿼리 수천 개를 종료하자 상황이 더 나빠졌다. 쿼리를 종료하면 그 트랜잭션 전체를 롤백해야 하는데, 롤백 자체가 비싼 작업이고 같은 락에서 다시 막혔기 때문이다.\n\n대기 중이던 복제본 데이터베이스로 페일오버하자 Basecamp 3 가 돌아왔다. 37signals 는 조심스럽게 정상화를 알리고 멈췄던 기능을 다시 켰는데, 데이터베이스가 다시 무너졌다. 두 번째에는 다른 요인이 섞여 있었지만 결국 다시 높은 동시성에서 생긴 락 경합이었다."},"updated_at":"2026-11-14T12:33:55.492221Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0301","org_slug":"37signals"}