이중화로 인한 네트워크 생각지도 못한 장애.

여러 서비스들이 서비스 안정화를 위하여 어플리케이션을 가동시키는 인스턴스를 동일한 서버가 아닌 여러 서버에 분산해서 관리합니다.

1000만원 짜리 장비하나를 사용하는 것보단 200만원짜리 장비 5대를 사용하는게 여러모로 효율적이기 때문이죠.

 

 

하지만 이러한 구조도 물리적으로 서버가 한곳에 있어서 불이난다거나, 전기가 꺼진다거나 하는 재난의 상황에서는 서비스들이 중단될 위험이 있습니다. 이러한 상황을 방지하기위해서 서버자체를 하나 더 사용합니다...

 

 

naver 도메인을 통하면 gslb에서 적절한 트래픽으로 분산된 vip로 트래픽을 보내고 이후 IDC나, AWS같은 서버 내부에서 LB를 통해 트래픽을 분산시켜 처리한다.

 

GSLB란

GSLB(Global Server Load Balancing)는 전 세계 여러 위치에 분산된 서버 간에 트래픽을 분산시키는 기술을 말합니다. 이 기술은 사용자가 어느 위치에서 접속하든 가장 가까운 또는 성능이 가장 좋은 서버로 트래픽을 라우팅해줍니다. 이를 통해 웹사이트나 애플리케이션의 가용성, 성능, 속도를 최적화할 수 있습니다.

 

 

좀 더 살을 보태서 제주도 IDC, 부산 IDC가 있고 다음과 같은 구성이라고 해보자.

 

여러가지 이유때문에 각각의 IDC 물리적으로 가까운곳에 DB를 두고 서로다른 IDC존과 동기화를 해서 사용한다.

 

IDC 존 안에는 또한 DMZ존이라는 녀석도 존재한다.

in out상관없이 dmz존을 거쳐 방화벽을지나 트래픽이 도달한다.

 

 

본론

 

이러한 상황속에서 부산 IDC에서 매일 오후2시에 부산 IDC A DataBae 에서 부산 IDC B DataBase로 한달치 데이터가 dump 된다고 했을 때 서비스에 문제가 있을까?

 

결론은 아니다. 하나의 slave db에서 연결할수 있는 커넥션 수 는 감소하겠지만 큰 서비스들은 여러개의 slave 디비를 가지고 있고 문제가 되지않는다.

 

문제

dump를 하는 인원은 DB인프라가 하고 있고 신규 장비 발급을 위해 테스트를 위해서 제주도 IDC에 DB장비가 들어가있는 상태였다.

근데 이때 테스트를 위하여 하필이면 dump대상이었던 domain 명이 제주도 IDC안의 DB vip 연결되었다.

 

따라서 dump요청이  DB -> 부산 IDC -> DMZ -> GSLB -> VIP -> DMZ -> 제주도 IDC -> DB 이런식으로 네트워크가 이동하게된다.

 

dmz내에서 방화벽은 상당한 자원을 소모하는 처리방식이고 해당 처리량이 몰리니 기존 제공해야할 트래픽들이 대기상태가되고 connection이 끊겨 connection timeout 이 발생.

 

결론

예상하지도 못한 장애는 언제든지 발생할 수 있다. 장애 발생시간 동일시간대의 배포가 있었는지 또한 인프라의 작업이 있는지를 검토하여 빠르게 문제되는 지점을 파악하는게 중요하다.

 

이번 장애는 어떻게보면 누구의 잘못도 아닌 장애이지만 재발방지를 위해서는 dump같은 큰 작업을 할시에는 담당 개발자에게 사전에 공지하는것도 좋아보인다.