사례24건

24건 중 23~24번째

1. IL-0590 Rackspace ORD 재부팅 뒤 Mailgun 연결이 간헐적으로 실패하고 이벤트 유실과 이메일 중복 발송이 났다

   Mailgun2014

   증상

   2014년 9월 27일 토요일 18:50 UTC 에 Mailgun 은 모든 데이터베이스 복제와 모든 리전의 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 알아챘다. 그때 Mailgun 은 Rackspace 의 ORD 재부팅을 앞두고 트래픽을 다른 환경으로 옮길 준비를 하고 있었다.

   간헐적 연결 실패간헐적 타임아웃패킷 손실

   촉발

   Rackspace 가 시카고 데이터 센터 ORD 의 클라우드 인스턴스를 재부팅한 유지 보수가 Mailgun 의 F5 서버에 오류 상태를 일으켰다.

   원인

   DNS·네트워크 장애

   구성 요소

   클라우드 로드 밸런서데이터베이스 복제

   기여 요인

   –

   감지

   9월 27일 18:50 UTC 에 ORD 트래픽 전환을 준비하던 Mailgun 이 모든 데이터베이스 복제와 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 발견했다.

   조치

   • Rackspace 네트워크 팀이 Mailgun 의 F5 와 일부 Rackspace 전용 고객의 F5 에서 캐시를 지웠다.
   • Rackspace 네트워크 팀이 Mailgun 서비스용 새 virtual IP 를 만들었다.
   • Mailgun 이 DNS 설정을 바꿔 원격 F5 의 캐시가 강제로 비워지게 했다.

   후속 조치

   • Rackspace 와 함께 F5 문제의 근본 원인을 계속 조사한다.
   • 근본 원인 분석을 마치면 클라우드 인프라 유지 보수가 Mailgun 고객에게 영향을 주지 않도록 조치한다.

   사례 보기
2. IL-0537 사쿠라 클라우드의 호스트 서버와 스토리지 장치 사이 연결이 몇 달 동안 되풀이해 끊겼다

   Sakura Internet2012

   증상

   사쿠라 클라우드에서 사용자 서버를 수용한 호스트 서버와 스토리지 장치 사이의 통신이 되풀이해 끊겼다. 포트 전환 때문에 끊길 때는 한 번에 5분 정도 끊겼다. 이 끊김은 2011년 12월부터 간헐적으로 되풀이됐다.

   스토리지 연결 끊김패킷 손실

   촉발

   2011년 11월 15일 서비스를 시작한 뒤 12월 중순부터 호스트 서버와 스토리지 장치 사이의 트래픽이 늘었고, 스토리지 장치의 네트워크 인터페이스에서 패킷 손실이 나기 시작했다.

   원인

   용량 한계

   구성 요소

   클라우드 블록 스토리지InfiniBand 패브릭

   기여 요인

   자동화 증폭스테이징 불일치디버그 접근 제한

   조치

   • 1월 초 스토리지 장치 네트워크 인터페이스의 감시 방식을 ICMP 에서 LINK 상태 확인으로 바꿔, 물리적으로 링크가 내려갔을 때만 예비 포트로 전환되게 했다.
   • 1월 초 Subnet Manager 의 확인 방식을 보통 모드에서 heavy sweep 모드로 바꿔 스토리지 장치가 네트워크에서 떨어지는 문제를 없앴다.
   • 3월 19일 스토리지 장치의 펌웨어를 업데이트해 장치의 패킷 손실을 없앴다.
   • 스토리지 부하를 줄이려고 3월 12일 두 번째 스토리지 장치를 더했고, 옮길 수 있는 서버를 두 번째 장치로 옮겨 부하를 나눴다.

   후속 조치

   • 기존 스토리지를 자체 개발한 전혀 다른 새 스토리지 장치로 바꾼다.
   • 새 스토리지는 장치의 최대 수용 대수에 맞는 테스트 환경을 준비해 실제로 부하를 걸어 시험했다. 유료 정식 서비스 전에 다시 무료 베타 테스트 기간을 두고, 사용자가 만족할 때까지 시험을 되풀이한다.
   • 새 스토리지의 네트워크 인터페이스 드라이버 같은 부품은 지금까지 운영에서 문제가 없던 호스트 서버와 같은 것을 썼다.
   • 새 스토리지는 사쿠라인터넷이 직접 관리하고 운영할 수 있도록 자사 엔지니어가 개발했다.

   교훈

   사쿠라인터넷은 스토리지 장치의 선정과 검증 과정에 큰 문제가 있었다고 돌아봤다. 검증 때는 설계 사양에 맞는 최대 수용 대수만큼 서버를 준비하지 못하고, 예측으로 만든 부하로 성능을 확인했다. 그래서 성능 한계에서 하는 시험이 부족했고, 실제 운영에서 난 문제에 빠르고 정확하게 대응하지 못했다. InfiniBand 포트의 패킷 손실은 펌웨어 업데이트로 풀렸지만 대응을 마치기까지 석 달이 걸렸다. 자사 엔지니어가 스토리지 장치의 사양과 동작을 다 파악하지 못해서, 제조사와 긴밀히 협력했어도 조사와 확인에 오랜 시간이 걸렸다.

   사례 보기

원인별9