그래프
사례2건
2건 중 1~2번째
- 증상
2024년 12월 15일 03:53 UTC 에 OpenStreetMap.org 에 접속할 수 없게 됐고, 04:01 UTC 에 StatusCake 모니터링이 장애를 잡아 SMS 알림을 보냈다. 웹사이트와 지도 API 가 완전히 내려갔다.
- 촉발
2024년 12월 15일 03:53 UTC 에 HE.net 의 암스테르담 라우팅 장비가 예기치 않게 고장 났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
04:01 UTC 에 StatusCake 모니터링이 장애를 잡아 SMS 알림을 보냈고, 곧바로 운영 팀에 알려졌다.
- 조치
- 11:31 UTC 에 더블린에 있는 OpenStreetMap.org 의 읽기 전용 백업 인스턴스를 켜 일부 기능을 되살렸다. 사이트에는 편집 내용을 저장할 수 없다는 점검 안내를 띄웠다.
- 12월 17일 12:21 UTC 에 HE.net 을 거치지 않는 새 Equinix Internet 회선을 암스테르담에서 개통해 OpenStreetMap.org 와 API 의 모든 기능을 되살렸다.
- 12월 18일 00:29 UTC 에 HE.net 이 암스테르담 서비스가 복구됐다고 확인했고, HE.net 경로가 정상으로 돌아와 OpenStreetMap.org 의 모든 네트워크 경로를 다시 쓸 수 있게 됐다.
- 후속 조치
- 한 사업자가 고장 나도 다른 사업자로 거의 끊김 없이 넘어가도록 여러 ISP 를 쓰는 구성으로 옮긴다.
- 암스테르담 서버의 예비 ISP 후보를 대역폭, 신뢰성, 비용으로 비교한다. 2025년 2월 Karlsruhe Hack Weekend 에서 BGP 를 쓰는 방안과 HE.net 을 예비 ISP 로 남기는 방안을 포함해 실제 선택지를 논의한다.
- 경로와 지연 시간을 더 깊이 모니터링해 ISP 문제를 빨리 잡고, 자동 에스컬레이션 절차를 만든다.
- ISP 사이 트래픽 전환을 시험하는 페일오버 훈련 일정을 정하고, 복제 과정이 최신이며 믿을 만한지 확인해 사이트 페일오버를 부담 없이 쓸 수 있는 선택지로 만든다.
- HE.net, Equinix Internet 과 계약상 SLA 를 협의하고, 정해진 에스컬레이션 절차와 응답 시간을 계약에 넣는다.
- 대역 외 접속에 쓰는 Raspberry Pi 4 와 4G 모뎀을 ISP 장애 때 수동 예비 업링크로 쓸 수 있게 미리 설정한다. 이 회선으로 서버에 접속하고 Postgres 복제 데이터를 보조 사이트로 동기화한다. 대역 외 장비는 견고하고 이중화되도록 업그레이드한다.
- 장애 소식을 알리는 일을 맡을 이해관계자와 각자의 책임, 권장 소통 채널을 정리한 문서를 만든다. 운영 팀은 소통을 다른 사람에게 맡기고 복구에 집중한다.
- OpenStreetMap.org 의 "rails-port" 유지 관리자가 OAuth 서비스를 분리해, 사이트가 흔들릴 때도 제3자 서비스의 인증이 계속 동작하게 할 수 있는지, 그 방법이 현실적인지 조사한다.
- 교훈
암스테르담 서버가 HE.net 하나에만 기대고 있어 단일 장애 지점이 생겼고, 앞으로는 상위 사업자를 여럿 둔다. 4G 예비 회선을 쓴 대역 외 접속이 아주 쓸모 있었으므로, 데이터 동기화까지 할 수 있게 신뢰성과 기능을 넓힌다. 읽기 전용 백업으로 일부 서비스는 됐지만, 복제가 이어지고 있었다면 편집 기능을 더 빨리 되살렸을 것이다. ISP 와 자주 연락해도 쓸 만한 복구 예상 시각을 받지 못했으므로, SLA 를 더 잘 이해하고 ISP 에 더 투명하게 알려 달라고 요구해야 한다. 상위 연결의 알림을 다듬고 여러 모니터링 출처의 데이터를 한데 모아야 문제를 더 빨리 짚을 수 있다. OpenStreetMap.org 가 읽기 전용이 되면 새 토큰을 저장하지 못해, 장애와 무관한 community.openstreetmap.org 같은 서비스에도 로그인할 수 없게 된다.
- 증상
2022년 6월 11일 20:18 UTC 부터 OpenStreetMap.org 에 접속할 수 없었다. Equinix 가 암스테르담 데이터센터 AM6 의 전원 A 계통 점검을 시작하고 18분 뒤였고, 암스테르담에 있는 www, API, wiki, planet 서비스가 모두 인터넷과 끊겼다.
- 촉발
2022년 6월 11일 20:00 UTC 에 Equinix 가 암스테르담의 OpenStreetMap 서버에 전원을 대는 전원 A 계통의 5년 주기 점검을 시작했다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 운영 팀은 더블린으로 페일오버하거나 업링크를 Switch-2 로 옮기지 않고 Equinix 전원 점검 시간이 끝날 때까지 기다렸다. 장애는 6월 12일 03:45 UTC 에 끝났다.
- 후속 조치
- 진행 중인 장애를 알리는 데 걸리는 시간을 줄인다. 장애 알림은 https://twitter.com/OSM_Tech 로 낸다.
- 스위치의 PSU 와 팬 상태를 모니터링하고 알림을 건다.
- Cisco SG550X-48 스위치 Switch-1, Switch-2 와 Cisco Redundant Power System 을 이중 전원을 갖춘 Juniper EX4300 스위치로 바꾼다. 부품 공급 부족으로 설치가 늦어졌고, 2022년 7월 19일 기준 모든 부품이 현장에 도착해 설치를 기다린다.
- 이중 전원을 받는 대역 외 접속 장비인 4G 모뎀 시리얼 콘솔 서버를 암스테르담에 둔다. 2022년 6월 20~22일 현장 방문 때 설치를 마쳤다.
- 이중 업링크를 설치한다. 2022년 7월 19일 기준 아직 설치되지 않아 운영 팀이 계속 챙기고 있다.
- 지금은 실수하기 쉬운 수동 절차인 사이트 페일오버를 더 쉽고, 손이 덜 가고, 덜 위험하게 만든다.
- 운영 SRE 를 위한 당번 호출 시스템을 들인다. 2022년 7월 19일 기준 업체와 협상 중이다.
- 한 사람이 24시간 내내 당번을 설 수 없으므로 장기적으로 SRE 팀을 늘린다.
- 전원, 네트워크, 상위 링크, 서비스 장애에 대비한 장비 페일오버 시험을 계속하고 정식 절차로 만든다.
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스 복제, 데이터센터 전력·냉각. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.