{"id":"IL-0333","org":"Buildkite","date":"2016-08-22","docs":["http://docs.aws.amazon.com/autoscaling/latest/userguide/as-suspend-resume-processes.html"],"title":{"en":"A downsized RDS PostgreSQL database maxed out its CPU at US peak and failing ELB health checks took buildkite.com down","ko":"사양을 낮춘 RDS PostgreSQL 인스턴스가 피크 부하를 못 버텨 헬스 체크가 실패하고 Buildkite 대시보드가 몇 시간 동안 내려갔다"},"domain":["database","aws"],"impact":{"scope":"buildkite.com dashboard down: no login, no build logs, no documentation; builds kept running and pull request statuses kept updating; slow responses and dropped requests from 22:28 to 23:10 UTC","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Buildkite listed six lessons. Watch AWS credits, because billing reports show $0 while credits are spent, so the real cost is hidden and big changes end up rushed. Load test after significant infrastructure changes. Think about what a health check should do and what happens when every server behind an ELB fails it. Do not make new servers look up the deployed revision from the service they are replacing. Make sure every on-call member has the right PagerDuty and phone settings before going on call. When servers churn in AWS, stop health checks and autoscaling, for example with the Auto Scaling feature to suspend and resume processes, so the EC2 request limit is not used up.","ko":"AWS 크레딧을 미리 지켜봐야 짧은 기간에 큰 인프라 변경을 서두르지 않는다. 크레딧을 쓰는 동안 AWS Billing Reports 는 0달러 청구서를 보여 줘서 실제 비용을 알기 어렵다. 큰 인프라 변경 뒤에는 부하 시험을 해야 한다. 헬스 체크가 실제로 무엇을 확인해야 하는지 다시 생각해야 한다. 의존하는 서버에 모두 접속되는지 확인하던 헬스 체크는 ELB 의 모든 서버가 실패할 때 어떻게 되는지 고려하지 않았다. 새 서버가 배포할 리비전을 자기 서비스에 물어보는 방식은 쓰면 안 된다. 온콜에 들어가기 전에 모든 팀원의 PagerDuty 와 iPhone 설정이 맞는지 확인해야 한다. AWS 에서 서버가 계속 떴다 내려가면 헬스 체크와 오토스케일링 규칙을 멈춰 EC2 요청 한도에 걸리지 않게 해야 한다. 팀은 사후 분석을 쓰면서 AWS 에서 Auto Scaling 프로세스를 일시 중지하고 재개할 수 있다는 것을 알았다."},"related":[],"sources":[{"url":"https://buildkite.com/resources/blog/outage-post-mortem-for-august-22nd/","kind":"blog","archived":"https://web.archive.org/web/20260119031008/https://buildkite.com/resources/blog/outage-post-mortem-for-august-22nd/"}],"summary":{"en":"Buildkite had grown on AWS Activate credits by adding hardware. About two weeks before the incident the team found the credits were about to run out and set out to cut the bill quickly. The largest cost was an m4.10xlarge Multi-AZ RDS PostgreSQL database, which was downgraded during a weekend maintenance window to an r3.2xlarge Multi-AZ instance. Because the new instance had less memory, connection pooling was moved from pgbouncer on each host to one centralised pgbouncer. Neither change was load tested. The database looked fine over the weekend and into what the team took for the start of the US peak, and the team went to bed.\n\nAt about 16:00 UTC the database CPU maxed out. Buildkite runs three ELBs with Auto Scaling Groups, for the dashboard, the REST API and the Agent API, and the health check behind them tested both SQL databases, Redis and Memcached. Health checks returned HTTP 500, the dashboard ELB removed its servers, and buildkite.com went offline at 17:21 UTC. Replacement servers deployed themselves from a baked AMI and looked up the current revision from buildkite.com itself; when that failed they ran the AMI's old code, whose health check referenced a decommissioned database, so they failed and were terminated in a loop. The PagerDuty alerts from New Relic, Pingdom, Datadog, Calibre and CloudWatch did not wake anyone: the on-call engineer's \"Immediately phone me\" notification rule had dropped out of his settings, so only silent push notifications arrived, and the other team members, reached by escalation, had their phones on silent.\n\nThe team woke at 21:00 UTC. An AWS IAM issue blocked the database upgrade and the launch of a fixed AMI in the AWS Console, so at 22:28 UTC servers were taken from the Agent API and added to the dashboard ELB, bringing buildkite.com back with slow responses. When IAM recovered, the EC2 request limit, used up by the server churn, forced the team to wait. The team switched the Auto Scaling Groups to EC2 health checks and locked their desired counts, then used the aws-cli to upgrade the database to an instance type that could handle the load and roll out servers whose self-deploy worked, and went back to pgbouncer on each host. Buildkite fully recovered at 23:10 UTC.","ko":"Buildkite 는 AWS Activate 프로그램에서 받은 크레딧이 곧 떨어진다는 것을 약 2주 전에 알고 AWS 비용을 서둘러 줄이려 했다. 가장 큰 비용은 m4.10xlarge Multi-AZ RDS PostgreSQL 데이터베이스였고, 팀은 이를 r3.2xlarge Multi-AZ 인스턴스로 낮추기로 했다. 팀은 시간에 쫓겨 새 데이터베이스가 큰 부하를 버틸지 확인하지 않았고 부하 시험도 하지 않았다. 주말 유지 보수 시간에 사양을 낮춘 뒤 성능은 괜찮아 보였다. 새 데이터베이스는 메모리가 적어서, 연결 하나당 메모리를 줄이려고 서버마다 두던 pgbouncer 를 중앙 pgbouncer 하나로 바꿨다. 가장 큰 고객들은 미국에 있었고, 팀은 미국 피크가 시작된다고 생각한 시간까지 지켜본 뒤 잠자리에 들었다.\n\n2016년 8월 22일 16:00 UTC 무렵 데이터베이스의 CPU 사용률이 최대치에 머물렀다. 데이터베이스까지 확인하던 헬스 체크가 HTTP 500 을 내자 대시보드용 ELB 가 서버를 뺐다. 17:21 UTC 부터 로그인, 빌드 로그, 문서가 모두 막혔다. 새 서버는 https://buildkite.com/_secret/version 엔드포인트에서 배포할 리비전을 받지 못해 AMI 에 든 옛 코드로 떴다. 그 코드의 헬스 체크가 폐기된 데이터베이스를 가리켜, 새 서버는 몇 시간 동안 떴다 종료되기를 반복했다. 그동안 PagerDuty 알림은 아무도 깨우지 못했다. 온콜 담당자의 설정에서 \"Immediately phone me\" 규칙이 빠져 소리 없는 푸시 알림만 갔다. 에스컬레이션을 받을 다른 팀원들은 휴대폰을 무음으로 두었다.\n\n팀은 21:00 UTC 에 깨어 문제를 파악했다. 데이터베이스 사양을 올리려 했지만 AWS 의 IAM 문제로 AWS Console 이 변경을 받지 않았고, 새 AMI 도 띄울 수 없었다. 팀은 Agent API 서버 일부를 대시보드용 ELB 로 옮겨 22:28 UTC 에 buildkite.com 을 다시 올렸지만 응답은 느렸다. IAM 문제가 풀린 뒤에는 서버가 계속 떴다 내려간 탓에 EC2 요청 한도에 걸려 기다려야 했다. 결국 aws-cli 로 데이터베이스를 부하를 감당할 인스턴스 유형으로 올렸다. 스스로 배포하는 문제를 고친 새 서버도 내보냈다. 그리고 중앙 pgbouncer 를 없애고 호스트마다 pgbouncer 를 두던 구성으로 되돌렸다. 23:10 UTC 에 완전히 복구했다."},"trigger":{"en":"Over a weekend maintenance window, Buildkite downgraded its m4.10xlarge Multi-AZ RDS PostgreSQL database to an r3.2xlarge Multi-AZ instance to cut its AWS bill, and moved to a centralised pgbouncer to pool connections. The first US weekday peak after the change pushed the new instance's CPU to its maximum at about 16:00 UTC.","ko":"AWS 크레딧이 곧 떨어질 상황이라 비용을 줄이려고, 주말 유지 보수 시간에 m4.10xlarge Multi-AZ RDS PostgreSQL 데이터베이스를 r3.2xlarge 로 낮췄다. 연결 하나당 메모리를 줄이려고 중앙 pgbouncer 로도 옮겼다. 월요일 미국 피크 시간에 이 데이터베이스가 부하를 버티지 못했다."},"severity":"unknown","symptoms":["service-unavailable","database-overloaded","readiness-probe-failures","cloud-api-rate-limited"],"timeline":{"detected_after":"3h 39m","resolved_after":"5h 49m"},"date_kind":"incident","detection":{"en":"New Relic, Pingdom, Datadog, Calibre and CloudWatch raised PagerDuty alerts, but the on-call phone call never came and only silent push notifications arrived. The team noticed at 21:00 UTC when they woke to emails, tweets and Slack messages from users.","ko":"New Relic, Pingdom, Datadog, Calibre, CloudWatch 가 문제를 감지하면 PagerDuty 알림이 온콜 개발자에게 전화를 건다. 하지만 온콜 담당자의 PagerDuty 설정에서 \"Immediately phone me\" 규칙이 빠져 소리 없는 푸시 알림만 갔다. 에스컬레이션을 받을 다른 팀원들은 휴대폰을 무음으로 두어 아무도 깨지 않았다. 팀은 21:00 UTC 에 깨어 이메일, 트윗, Slack 메시지로 장애를 알았다."},"components":["database","cloud-load-balancer","health-probe","launch-template"],"root_cause":"capacity","remediation":[{"text":{"en":"Moved servers from the Agent API to the dashboard ELB to bring buildkite.com back online","ko":"Agent API 서버 일부를 빼서 대시보드 요청을 받는 ELB 에 연결해 buildkite.com 을 다시 올렸다. 데이터베이스가 여전히 부하에 눌려 있어 요청은 느렸다."}},{"text":{"en":"Switched the Auto Scaling Groups to EC2 health checks and locked in desired counts","ko":"EC2 요청 한도에 걸린 뒤 Auto Scaling Group 의 헬스 체크를 EC2 헬스 체크로 바꾸고 원하는 서버 수를 고정했다."}},{"text":{"en":"Upgraded the database to an instance type that could handle the load, using the aws-cli","ko":"AWS Console 이 여전히 문제가 있어 aws-cli 로 데이터베이스를 부하를 감당할 수 있는 인스턴스 유형으로 올렸다."}},{"text":{"en":"Built a new AMI that did not depend on buildkite.com/_secret/version and rolled out servers that could self-deploy","ko":"https://buildkite.com/_secret/version 을 참조하지 않는 새 AMI 를 만들고, 스스로 배포하는 문제를 고친 새 서버를 aws-cli 로 내보냈다."}},{"text":{"en":"Removed the centralised pgbouncer and went back to pgbouncer on each host","ko":"중앙 pgbouncer 서버를 없애고, 잘 동작하던 이전 구성대로 호스트마다 pgbouncer 를 다시 두었다."}}],"action_items":[{"text":{"en":"Plan load testing after significant infrastructure changes without affecting other users of the system","ko":"다른 사용자에게 영향을 주지 않고 큰 인프라 변경 뒤 부하 시험을 하는 방법을 계획한다."}},{"text":{"en":"Make the ELB health check return OK when the app answers, without checking database connectivity","ko":"헬스 체크가 애플리케이션에 닿기만 하면 \"OK\" 를 내도록 바꿨다. 이 요청에서는 더 이상 데이터베이스 연결을 확인하지 않는다."}},{"text":{"en":"Consider a separate health check endpoint for Pingdom that checks the database and other dependencies","ko":"애플리케이션이 데이터베이스와 의존 서비스에 접속되는지 확인하는 헬스 체크 엔드포인트를 따로 두고 Pingdom 이 호출하게 하는 방안을 검토한다."}},{"text":{"en":"Store the latest deployed revision as a file on S3 for newly launched servers to self-deploy from","ko":"최근 배포된 리비전을 S3 의 파일에 저장하고, 새로 뜬 서버가 스스로 배포할 때 그 파일을 참조하게 바꿨다."}},{"text":{"en":"Test by hand that PagerDuty calls reach every on-call team member","ko":"팀원 모두가 PagerDuty 전화가 실제로 오는지 수동으로 시험했다."}},{"text":{"en":"Investigate regular company-wide tests of everyone's paging setup","ko":"모든 팀원의 설정이 맞는지 정기적으로 확인하는 회사 전체 시험을 할 수 있는지 알아본다."}},{"text":{"en":"Ask PagerDuty about calling members when they go on call or requiring an immediate phone rule","ko":"팀원이 온콜에 들어갈 때 PagerDuty 가 전화를 걸게 하거나, 모든 Notification Rules 에 \"Immediately phone\" 규칙을 두도록 요구하는 방안을 PagerDuty 에 문의한다."}}],"contributing":["assumption-unverified","probe-depends-on-dependency","automation-amplified","circular-dependency","paging-failed","overlapping-failures"],"recurrence_of":null,"symptoms_text":{"en":"On 22 August 2016 at 17:21 UTC buildkite.com went offline: nobody could log in, view build logs or read the documentation, although builds kept running and GitHub and Bitbucket pull request statuses kept updating. The Buildkite team in Melbourne was asleep and woke at 21:00 UTC, almost 4 hours later, to emails, tweets and Slack messages saying Buildkite was down.\n\nAt about 16:00 UTC, during US peak load, the RDS PostgreSQL database that had been downgraded over the weekend could no longer keep up and its CPU maxed out. The health check endpoint behind each Elastic Load Balancer ran SELECT 1 against both SQL databases and pinged Redis and Memcached, so it began returning HTTP 500 errors saying it could not connect to the database. The ELB in front of the dashboard had the lowest failed health check threshold and marked its servers OutOfService; the ELBs for the REST API and the Agent API had problems but kept their servers.\n\nThe Auto Scaling Group launched replacement servers, but every one of them failed its health check and was terminated, and this launch-and-terminate cycle went on for hours. New servers were built from an AMI with an old version of the code baked in and found the current Git revision by requesting https://buildkite.com/_secret/version, which could not answer while buildkite.com was down. The baked-in code's health check still referenced Job::Log::Chunk::Shard::One, a database that had been decommissioned.\n\nRecovery was slowed by AWS. An IAM problem at AWS stopped the team from upgrading the database in the AWS Console, and when the team tried to launch a fixed AMI for testing, the IAM role selector did not work and the AWS Console kept showing \"Internal server error\". Once IAM recovered, new EC2 servers could not be launched because the launch-and-terminate cycle had used up the EC2 request limit. After a partial recovery at 22:28 UTC, responses stayed very slow and some requests were dropped.","ko":"2016년 8월 22일 17:21 UTC 부터 buildkite.com 에 아무도 로그인하지 못했고 빌드 로그와 문서도 볼 수 없었다. 빌드는 계속 돌았고 GitHub 와 Bitbucket 의 Pull Request 상태도 계속 갱신됐다.\n\n멜버른에 있던 팀은 자고 있었다. 팀은 약 4시간 뒤인 21:00 UTC 에 깨어 Buildkite 가 내려갔다는 이메일, 트윗, Slack 메시지로 가득 찬 휴대폰을 봤다.\n\n16:00 UTC 무렵부터 사양을 새로 낮춘 데이터베이스가 부하를 따라가지 못했고 CPU 사용률이 최대치에 머물렀다. 이 성능 문제가 다른 문제를 줄줄이 일으켰다.\n\nELB 는 30초마다 애플리케이션에 HTTP 요청을 보내 헬스 체크를 한다. 헬스 체크 엔드포인트는 SQL 데이터베이스 두 개와 Redis, Memcache 를 확인한다. 이 엔드포인트가 데이터베이스에 접속하지 못해 HTTP 500 을 내기 시작했다. 대시보드 요청을 받는 ELB 는 실패 기준이 훨씬 낮아 서버를 자동으로 빼고 \"OutOfService\" 로 표시했다. Agent API 와 REST API 의 ELB 도 문제가 있었지만 서버는 남아 있었다.\n\n빠진 서버를 대신할 새 서버도 헬스 체크를 통과하지 못했다. 새 서버는 https://buildkite.com/_secret/version 에서 최신 Git 리비전을 받아 스스로 배포한다. 그런데 buildkite.com 이 내려가 있어 리비전을 받지 못했고, AMI 에 들어 있던 옛 코드로 떴다. 옛 코드의 헬스 체크는 이미 폐기한 데이터베이스 Job::Log::Chunk::Shard::One 을 가리켰다. 몇 시간 동안 새 서버가 떴다가 헬스 체크 실패로 곧바로 종료되기를 반복했다.\n\n팀이 데이터베이스 사양을 올리려 하자 AWS 의 IAM 문제로 AWS Console 이 변경을 받아 주지 않았다. 새 AMI 를 시험하려고 띄울 때는 IAM 역할 선택기가 동작하지 않았고 AWS Console 에 \"Internal server error\" 가 계속 떴다. IAM 문제가 가라앉은 뒤 EC2 서버를 띄우려 했지만, 서버가 계속 떴다 내려간 탓에 이미 EC2 요청 한도에 걸려 있었다.\n\n22:28 UTC 에 임시 조치로 buildkite.com 이 다시 올라왔지만, 데이터베이스가 여전히 부하에 눌려 응답이 매우 느렸고 일부 요청은 버려졌다."},"updated_at":"2026-11-14T12:33:58.702371Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0333","org_slug":"buildkite"}