사례2건

2건 중 1~2번째

1. IL-0527 OpenStreetMap.org 의 복제 diff 생성이 invalid memory alloc request size 오류로 16시간 멈춤

   OpenStreetMap Foundation2025

   증상

   2025년 6월 25일 21:33 UTC 부터 OpenStreetMap.org 의 minutely, hourly, daily 복제 diff 가 새로 만들어지지 않았다. 21:40 UTC 에 Alertmanager 가 운영 팀에 "minutely replication feed delayed - 6m 2s" 라는 첫 알림을 보냈다.

   복제 지연

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스 복제데이터베이스

   기여 요인

   온콜 호출 미전달

   감지

   Alertmanager 가 이 일과 관련된 알림을 여러 번 보냈고, 첫 알림은 21:40 UTC 의 "minutely replication feed delayed - 6m 2s" 였다. 호출기나 SMS 로 가는 알림은 울리지 않았다.

   조치

   • 6월 26일 06:08 UTC 에 osmdbt 타이머를 멈췄다.
   • 12:56 UTC 에 OpenStreetMap.org 를 읽기 전용 점검에 들여 지도 편집을 막았다.
   • osmdbt 의 fakelog 도구를 손으로 써서 실패를 일으킨 PostgreSQL 복제 상태를 건너뛰었고, 13:13:47 부터 13:17:04 UTC 까지 replication/minute/006/658/640 부터 673 까지 diff 를 만들었다.
   • 13:21:10 UTC 에 osmdbt 타이머를 다시 켜 minutely diff 생성을 되살렸다.
   • 13:22 UTC 에 약 25분 동안의 읽기 전용 점검을 끝냈다.

   후속 조치

   • PostgreSQL 을 17.x 로 업그레이드한다.
   • PostgreSQL 개발자에게 이 문제를 이슈로 올린다.

   교훈

   osmdbt 개발자와의 소통이 우회 계획을 세우는 데 결정적이었다. 운영 팀은 osmdbt 를 충분히 이해하지 못하고 있었다.

   사례 보기
2. IL-0526 HE.net 암스테르담 라우팅 장비 고장으로 OpenStreetMap.org 의 이중 광 회선이 모두 끊김

   OpenStreetMap Foundation2024

   증상

   2024년 12월 15일 03:53 UTC 에 OpenStreetMap.org 에 접속할 수 없게 됐고, 04:01 UTC 에 StatusCake 모니터링이 장애를 잡아 SMS 알림을 보냈다. 웹사이트와 지도 API 가 완전히 내려갔다.

   네트워크 도달 불가서비스 중단

   촉발

   2024년 12월 15일 03:53 UTC 에 HE.net 의 암스테르담 라우팅 장비가 예기치 않게 고장 났다.

   원인

   의존성 장애

   구성 요소

   ISP·트랜짓 망데이터베이스 복제

   기여 요인

   단일 장애점런북 부재

   감지

   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 같은 서비스에도 로그인할 수 없게 된다.

   사례 보기

원인별2