요약
대형 배터리 저장장치가 매분 정각에 충전 상태를 점검해서 전력망 주파수가 60초마다 흔들립니다.
독일 최대 송전망 운영사 테네트 독일은 몇 년째 전력망 주파수가 약 60초마다 잠깐 떨어지는 현상을 관측해 왔습니다. 윌리히 연구센터의 디르크 비트하우트가 이끈 연구팀이 쾰른 대학교, 카를스루에 공과대학교와 함께 원인을 밝혀 Nature Energy에 발표했습니다.
왜 중요한가
- 기기 하나에는 사소한 설정도 수많은 기기가 같은 시각에 따르면 전력망 전체를 흔들 수 있음이 드러났습니다.
- 같은 흔적이 유럽 밖 전력망에서도 나타나 특정 지역만의 문제가 아닙니다.
- 해법은 점검 시각을 기기마다 무작위로 흩는 것이어서 설비를 바꾸지 않고도 고칠 수 있습니다.
핵심 내용
- 무정전 전원을 대는 대형 배터리 저장장치가 매분 시작마다 충전 상태를 점검하면서 소비 전력이 순간적으로 뛰었습니다.
- 연구팀은 윌리히 캠퍼스의 에너지 실증 단지 80곳에 계측 장치를 달아 대형 배터리가 있는 곳에서 같은 주기를 확인했습니다.
- 데이터센터가 전력 수요의 약 5분의 1을 차지하는 아일랜드에서는 2016~2021년 사이 이 신호의 진폭이 4배가 됐습니다.
- 주파수가 흔들리면 수력발전 터빈이 잠깐 느려졌다 다시 빨라지기를 되풀이해 마모가 늘어납니다.
- 점검 주기에 구속력 있는 표준이 없어서 제조사들이 1분 간격을 무난하다고 여겨 고른 것으로 연구팀은 봅니다.
HN 반응
- 많은 이용자가 크론(정해진 시각에 작업을 돌리는 유닉스 도구) 작업이 정각에 몰려 서버 부하가 튀는 현상과 같다며, 실행 시각에 무작위 지연을 주는 관행을 소개했습니다.
- 보도자료가 기기와 제조사를 밝히지 않았다는 지적에는, 조사한 무정전 전원 장치(UPS)의 제조사가 주기성을 없애는 업데이트를 냈다는 논문 내용이 보충으로 달렸습니다.
재미있네요, API 트래픽에서도 비슷한 패턴이 아주 흔하거든요. UTC 자정에 큰 스파이크가 있고, 매시간 그보다 작은 게 하나, 15분마다 더 작은 게 하나, 메트릭 해상도가 충분하다면 매분 작은 혹까지 보여요. 당연히 누가 API를 매분 호출한다면 스트리밍 같은 걸 고려해야 하고, 못해도 커서 같은 걸 요구해서 요청 자체를 가볍게 만들어야 하죠.
apt 같은 패키지 관리자는 이 문제를 피하려고 자동 업데이트를 무작위 시간만큼 늦춥니다.
https://wiki.debian.org/PeriodicUpdates#Modify_the_schedule_via_systemd
systemd 타이머에도 무작위화 기능이 있습니다. 아주 유용합니다.
맞아요, 제가 큰 CDN 회사에서 일할 때도 원격 요청을 하는 주기적 작업에 '지터'를 넣는 게 표준 절차였어요. 모든 서버의 모든 크론 항목이 서버 이름 해시를 기준으로 0초에서 59초 사이로 지연돼서 실행됐죠. 이렇게 하면 내부 인프라 용량이 사실상 60배가 되는 셈이에요(물론 요청 처리에 걸리는 시간이나 몇 가지 다른 요인에 따라 다르지만요).
이것과 지수 백오프, 그리고 CDN을 운영하는 데 필요한 외부 자원(설정 같은 것)의 로컬 캐시가 대규모 네트워크를 안정적으로 운영하는 토대였어요.
(> 메트릭 해상도가 충분하다면 매분 작은 혹까지 보인다)
재미있게도 메트릭 해상도가 충분하지 않을 때도 주기적인 혹이 보일 수 있습니다. 에일리어싱 효과가 신호를 지배하기 때문입니다(나이퀴스트 주파수를 어렴풋이 가리키며).
정의상 효과가 보인다면 메트릭 해상도는 충분한 겁니다.
구체적인 해상도 기준이 나이퀴스트 주파수라는 부분은 맞습니다.
메트릭 샘플링도 샘플링이라서 에일리어싱이 생깁니다.
마찬가지로 prometheus 같은 tsdb의 샘플 수나 간격 제한은 다운샘플링이 아닙니다. 그냥 샘플을 건너뛰는 거죠. 이것도 에일리어싱을 만듭니다. 특히 rate나 미분 함수와 함께 쓰면 아주 눈에 띌 수 있습니다.
논문에 더 자세한 내용이 있습니다: https://www.nature.com/articles/s41560-026-02144-0
보도자료에는 세부 내용이 꽤 부실하네요. 60초마다 발생한다는 건 알아냈고(당연하죠!), 발전기인지 뭔지 하는 것도 나오는데, 그래서 정확히 뭡니까? (제조사와 모델은요?)
정확한 제조사나 기기를 찾아내지 못했고, 그래서 펌웨어도 바꾸지 못했다는 얘기 같은데요?
논문에 조금 더 자세한 내용이 있습니다. 아래 인용문은 "제조사와 소통한 뒤, 조사 대상 UPS 시스템의 배터리 블록 하나에서 전류 피크의 엄격한 주기성을 없애는 소프트웨어 업데이트가 배포되었다"는 뜻입니다.
https://www.nature.com/articles/s41560-026-02144-0
이 문제가 국제적으로, 거의 모든 전력망에 영향을 줄 만큼 광범위하다는 점을 보면 여러 제조사가 비슷한 방식을 쓰고 있을 가능성이 큽니다.
크론 작업도 마찬가지예요. 다들 xx:00이나 xx:30에 스케줄을 잡잖아요. 서로 소통할 필요도 없이 그냥 자연스럽게 그렇게 돼요. 경력이 좀 있는 사람들은 이걸 알아채고 시작 시각에 무작위성을 넣거나 조금 비껴 가게 하죠.
저는 작업마다 어중간한 숫자를 쓰라고 늘 권합니다. 그러면 "시스템이 *:13분(아니면 17, 23, 42...)에 부하가 심하네. 그 크론 작업이겠구나" 하고 알아볼 수 있습니다.
저도 트래픽을 식별하려고 ping 페이로드 크기로 비슷한 짓을 합니다. 패킷 크기를 소수로 잡으면 크기가 합산돼도 감지할 수 있거든요.
그나저나 저 숫자 중에 하나는 다른 것들과 다릅니다(60을 나누어떨어뜨리는 소인수가 더 많습니다).
좋은 지적입니다. 7, 11, 13...은 한 시간마다 반복되지 않죠.
도구 탓인 경우가 많습니다. cron(그리고 다른 여러 OS의 대응물)에는 이런 기능이 제대로 없어요.
systemd 타이머에는 어느 정도 있습니다. 예를 들어 30분 주기 작업에 RandomizedOffsetSec=30m을 주면 깔끔하게 분산됩니다.
스케줄러에 "다른 작업들과 알아서 맞춰서, 실행 중인 다른 작업이 가장 적을 때 대략 이 주기로 실행해 줘" 같은 옵션이 있으면 좋겠습니다.
RandomizedDelaySec=xxx를 쓰셔야죠.
경우에 따라 다릅니다. 추적할 단서가 필요하면 소수를 쓰세요. 눈에 띄는 영향이 전혀 없길 바라거나, 나중에 해석하고 싶은 트래픽 혹이 생길 거라고 상상조차 안 된다면 무작위 오프셋을 쓰면 됩니다.
물 망치 효과, 이 경우엔 전자 망치 효과라고 해야겠네요. 이게 바로 데이터센터의 윈도 서버를 전부 새벽 2시 정각에 재부팅하지 않고 부하 이동을 시간에 걸쳐 분산시키는 이유입니다. 전력 쪽 사람들이 아마 수백 MW는 될 부하를 매분 정각에 넣었다 뺐다 하면 문제가 생긴다는 걸 몰랐다는 게 놀랍네요.
크론 작업으로 설정돼 있는 것 같네요. 저는 크론의 1분 단위 granularity가 늘 마음에 안 들었어요. 제가 생각해 낸 거라곤 thundering herd 문제를 피하려고 sleep(random()) 같은 줄을 넣는 것뿐이었죠.
구글 내부의 cron 대응물에는 스케줄 문법에 ? 플레이스홀더가 있어서, 스케줄러가 필드 범위 안에서 유효한 값 하나를 결정론적으로 임의 선택해요. 그래서 ? 2 ...라고 쓰면 02:00에서 02:59 사이의 어떤 분이든 고르죠(그 분 안의 초도 고를 것 같아요). 값은 작업 정의의 해시에서 나오기 때문에 전체적으로 크론 부하가 그 시간대 안에 퍼집니다.
물론 크론 작업마다 부하와 실행 시간이 같지 않고 시간대마다 사용량도 다르지만, 그래도 기사에 나온 것 같은 뻔한 스파이크는 막는 데 도움이 돼요(단서를 달자면, 최근에 반대 사례로 실험해서 증명한 건 제가 알기로 없지만 합리적인 가정이라고 생각해요).
결국 무작위 분 대신 무작위 초에 점검이 일어나게 될 텐데, 스파이크 크기가 60분의 1로 줄긴 해도 여전히 뾰족하겠네요.
그래도 분의 시작점에 걸리는데, 제가 알기로 연구자들이 찾아낸 패턴이 바로 그거잖아요.
네, 실제로 있는 효과예요. 저는 여러 작업에 오프셋을 그냥 하드코딩해 놨어요.
이런 식으로요.
이러면 작업마다 60초 주기는 일정하게 유지하면서(무작위로는 이게 안 되죠) 분의 시작점에 딱 맞춰 실행하지는 않게 돼요.
참고로 systemd 타이머는 이걸 기본으로 지원해서 하드코딩할 필요가 없어요. 제 생각엔 더 쓰기 편하기도 하고요.
하지만 systemd는 나쁘잖아요 :[
사람들이 서서히 익숙해지고 있어요. (journalctl은 덜하지만요)
익숙해졌다기보다는 선택지가 없어서 systemd를 억지로 쓰다가 포기한 거죠. SysVinit을 알 만큼 나이가 안 든 세대 전체도 있고요.
"systemd를 강제로 쓰게 됐다"는 밈은 묘하게 뒤집힌 얘기입니다. sysvinit밖에 선택지가 없던 시절에는 아무도 "강요당했다"고 불평하지 않았는데, 배포판들이 sysvinit 방식 서비스도 여전히 쓸 수 있는 systemd로 옮겨 가기 시작하니까 갑자기 선택의 자유를 침해했다는 식으로 포장됩니다.
journalctl은 좋은 아이디어를 형편없이 구현한 겁니다. 내장 데이터 형식은 엄청나게 낭비가 심하고, 원하는 데이터를 찾는 데도 시원찮아요(어차피 모든 파일을 다 뒤져야 하는 경우가 많습니다).
journalctl이 SQLite나 컬럼형 임베디드 데이터베이스를 썼다면 시스템 관리자에게 정말 좋았을 겁니다. 지금 형식은 완전히 쓸모없습니다.
BSD cron은 수십 년 전부터 지터를 지원했습니다. 이건 순전히 리눅스의 문제입니다.