{"id":"IL-0520","org":"cloud.gov","date":"2016-07-05","docs":[],"title":{"en":"logs.cloud.gov trapped users in a login redirect loop because its full Redis session store stopped saving sessions","ko":"logs.cloud.gov 로그인이 리디렉션 루프에 빠지고 로그 검색 서비스가 하루 넘게 멈춤"},"domain":["database","observability"],"impact":{"scope":"Users could not log in to the logs.cloud.gov log search service from 7:12pm Eastern Time on 5 July 2016 until it was restored after 8:00pm Eastern Time on 6 July","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://github.com/cloud-gov/cg-postmortems/issues/6","kind":"github","archived":null}],"summary":{"en":"logs.cloud.gov is the log search service of cloud.gov. Its session management saves user login sessions to a Redis database, and the same Redis pushes data on to an Elasticsearch cluster. In July 2016 the Elasticsearch cluster was failing because of insufficient memory limits and because of a configuration error introduced when hardening scripts were applied to it. Redis could not push its data to Elasticsearch and ran out of space, its capacity hard-coded to use 1GB instead of 86% of available memory, so it stopped saving login sessions, and from 7:12pm Eastern Time on 5 July users of logs.cloud.gov were caught in a login redirect loop.\n\nThe team reconfigured Redis on the logsearch service to use a much larger memory instance, through cg-deploy-logsearch, so that logs were kept while the Elasticsearch cluster was down. It corrected the Elasticsearch memory setting and the hardening problem, which had set /tmp to noexec so that the JVM could not JIT jars and the instances would not restart, and redeployed the cluster. A disk encryption step made the redeployment slow. At 8:00pm Eastern Time on 6 July the cluster deployment was complete; the team redeployed the Kibana instance, checked the logs and logs.cloud.gov was restored.","ko":"미국 동부 시각 2016년 7월 5일 오후 7시 12분, cloud.gov 의 로그 검색 서비스 logs.cloud.gov 에 로그인 리디렉션 루프가 생겨 사용자가 로그인하지 못했다. 세션 관리 시스템이 사용자 세션을 Redis 에 저장하지 못한 것이 직접 원인이었다. Redis 는 Elasticsearch 클러스터로 데이터를 넘기지 못해 용량이 가득 찬 상태였고, Redis 의 용량은 가용 메모리의 86% 대신 1GB 로 하드코딩돼 있었다. Elasticsearch 클러스터는 메모리 한도가 모자랐고, 하드닝 스크립트를 적용하면서 들어간 설정 오류도 있었다.\n\n팀은 Elasticsearch 설정의 메모리 문제와 하드닝 문제를 고쳐 클러스터를 다시 배포했다. 처음에는 하드닝이 /tmp 를 noexec 로 바꿔 둔 탓에 JVM 이 jar 를 JIT 컴파일하지 못했고, 클러스터가 다시 시작하지 못했다. 그 뒤에는 디스크 암호화 단계 때문에 재배포가 오래 걸렸다. 클러스터가 천천히 재배포되는 동안 팀은 cg-deploy-logsearch 를 고쳐 Redis 를 훨씬 큰 메모리 인스턴스로 옮기고 로그를 계속 받아 두게 했다. 7월 6일 오후 8시에 클러스터 배포가 끝났고, 팀이 Kibana 인스턴스를 다시 배포하고 로그를 확인한 뒤 서비스가 복구됐다."},"trigger":null,"severity":"unknown","symptoms":["service-unavailable","writes-rejected"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["cache","elasticsearch-opensearch"],"root_cause":"capacity","remediation":[{"text":{"en":"Moved Redis on the logsearch service to a much larger memory instance so it could keep logs while Elasticsearch was down","ko":"logsearch 서비스의 Redis 를 훨씬 큰 메모리 인스턴스로 바꿔, Elasticsearch 클러스터가 내려가 있는 동안에도 로그를 계속 받아 두게 했다."}},{"text":{"en":"Corrected the Elasticsearch memory limits and the /tmp noexec hardening setting and redeployed the cluster","ko":"Elasticsearch 설정에서 메모리 설정과 하드닝 스크립트 문제를 고치고 클러스터를 다시 배포했다."}},{"text":{"en":"Redeployed the Kibana instance and verified the logs once the cluster deployment was complete","ko":"클러스터 배포가 끝난 뒤 Kibana 인스턴스를 다시 배포하고 로그를 확인해 서비스를 되살렸다."}}],"action_items":[{"text":{"en":"Add a failure alert that checks whether logs are coming through","ko":"로그가 계속 들어오고 있는지 확인하고, 끊기면 울리는 장애 알림을 만든다."}},{"text":{"en":"Make Redis auto-scaling or highly available so that failures in more fragile downstream components do not cause data loss","ko":"Redis 에 오토스케일링이나 고가용성을 갖춰, Redis 다음 단계에 있는 더 취약한 구성 요소가 실패해도 데이터를 잃지 않게 한다."}},{"text":{"en":"Extend the incident response plan to start with events that are not security-specific","ko":"보안 사고가 아닌 사건도 다루도록 사고 대응 계획을 넓힌다."}},{"text":{"en":"Create a chaos bot for the logs.cloud.gov service","ko":"logs.cloud.gov 서비스에 카오스 봇을 만든다."}}],"contributing":["overlapping-failures","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"At 7:12pm Eastern Time on 5 July 2016, logs.cloud.gov, the cloud.gov log search service, sent users into a login redirect loop, so they could not log in to the service.\n\nThe loop came from the service's session management, which failed when it tried to save the user's login session data to the Redis database. Redis was not saving the sessions because it had run out of space: it could not push its data on to the Elasticsearch cluster, and the Elasticsearch cluster was failing too.\n\nRecovery ran into two more problems. After the Elasticsearch configuration was updated and the cluster redeployed, the instances would not restart, because a hardening setting had made the /tmp directory noexec and the JVM could not JIT jars. Once the instances restarted, the disk encryption step made the redeployment slow, and the cluster deployment completed only at 8:00pm Eastern Time on 6 July.","ko":"미국 동부 시각 2016년 7월 5일 오후 7시 12분, cloud.gov 의 로그 검색 서비스 logs.cloud.gov 에서 로그인 리디렉션 루프가 발견됐다. 사용자는 서비스에 로그인할 수 없었다.\n\n로그인 세션을 관리하는 시스템이 사용자 세션을 Redis 데이터베이스에 저장하지 못했다. 세션이 저장되지 않아 로그인한 사용자가 계속 로그인 과정으로 되돌아가는 리디렉션 루프가 생겼다.\n\n조사해 보니 Redis 는 용량이 가득 차 있었다. Redis 는 Elasticsearch 클러스터로 데이터를 넘기지 못해 데이터가 쌓여 있었고, Elasticsearch 클러스터도 메모리 한도가 모자라 실패하고 있었다. Redis 의 용량은 가용 메모리의 86% 가 아니라 1GB 로 하드코딩돼 있었다.\n\n엔지니어들이 Elasticsearch 클러스터 설정을 고쳐 다시 배포했지만 클러스터는 다시 시작하지 못했다. 하드닝 과정에서 /tmp 디렉터리가 noexec 로 설정돼 JVM 이 jar 를 JIT 컴파일하지 못했기 때문이다. 이 문제를 해결해 인스턴스를 다시 시작한 뒤에도 디스크 암호화 때문에 복구 시간이 더 길어졌다."},"updated_at":"2026-11-14T12:34:16.327496Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0520","org_slug":"cloud-gov"}