카카오 장애와 DR센터에 관한 생각

카카오 장애발생

2022년 10월 15일 오후 3시 30분 카카오 장애 발생

13:30 카톡 전송안됨. 뭔가 쎄한 느낌을 받음.
13:40 회사 Slack에 카카오 서비스 접속 안되는 증상에 대한 Alert 발생 확인
13:50 회사 직원이 카카오측과 통화하여 화재발생 및 서비스 장애 확인

저는 금융관련 IT 업계에서 인프라 담당 엔지니어로 근무하고 있습니다.
이번 카카오 장애 발생할때 딱 두가지가 걱정되었습니다.

첫번째. 카카오 직원들 개고생 하겠구나.
IT 업계에서 이런 대규모 장애가 발생하면 퇴근은 고사하고 잠도 한숨 못자고 복구될때까지 죽도록 일해야 하는걸 누구보다 잘 알고 있기 때문에 카카오 직원들 걱정이 많이 됐습니다.

두번째. 월요일에 회사 출근하면 나도 힘들겠구나.
이런 일이 발생하면 비슷한 업종의 회사들은 "우리 회사는 이런일에 잘 대응할 수 있느냐? 대응 방법을 마련해 놔라"라는 미션이 항상 주어집니다.
다행이 우리회사는 2015년에 Active-Active DR센터를 제가 직접 설계 및 구축을 해 놨기 때문에 조금 걱정은 덜었지만 그래도 업무적인 스트레스를 많이 받게될께 뻔하기 때문입니다.

DR 센터 구축 경험담

이번 카카오 장애 때문에 IT 업계는 DR센터에 대해 관심이 많아지기 시작했습니다. 그에 따라 제가 생각하는 DR센터에 대해 간단히 끄적여봅니다.

DR 센터 개념 잡기 (생각의 단순화)

2015년에 데이터센터 이전을 해야 했습니다. 제가 근무하는 회사는 24시간 365일 단 1분도 서비스가 중단되면 안되는 회사입니다. 신용카드 결제 관련 서비스를 하고 있기 때문입니다.
이런 서비스를 제공하는 회사 입장에서 데이터 센터를 이전해야 한다는 자체가 참 어려운 일입니다.
우리 회사 입장에서 데이터 센터를 이전한다는 것은 무중단 이전이어야 하고, 무중단 이전이란 DR 센터를 완벽하게 구축한다는 것과 다름 아니었습니다.

DR 센터를 구축한다는게 매우 어려운 일이지만 저는 생각보다 쉽게 설계를 진행할 수 있었습니다.

물론 저는 데이터센터 규모가 대기업처럼 큰 규모가 아닌 환경에서 DR센터를 구축한 것이다 보니 실제로 설계가 쉬웠을 수도 있습니다.
저는 DR 센터를 설계할때 DR 센터가 외부에 있는것이 아니라 같은 데이터 센터에 있다라는 생각으로 진행했습니다.

예를들면 같은 데이터센터 안에 전산장비가 10개의 랙에 구성되어 있다면, 이것을 확장하여 총 20개의 랙에 동일하게 전산장비를 구현합니다. 그리고 확장한 10개의 랙에 구성된 서비스로 테스트를 완벽하게 진행한 뒤 DR센터로 이전한다는 생각입니다.

여기서 확장된 10개의 랙을 DR센터로 이전하고 이 장비들을 어떤 방식의 네트워크로 연동할지에 대한 고민만 해결하면 됩니다.

 

아래 그림은 제가 설명하는 개념과 유사한 그림을 구글검색에서 찾은 그림입니다.

데이터 센터간 L2 확장 (구글이미지검색)

데이터센터 확장 (네트워크 연동)

사실 이 부분이 가장 어려운 부분이긴 하지만 위에서 추가된 10개의 랙에 구성된 서비스가 완벽하게 동작하는것을 확인했다면 생각보다 수월하게 진행할 수 있습니다.

DR 센터와 네트워크를 연동하기 위해선 네트워크 회선이 필요할텐데 이 회선 종류는 크게 두가지로 구분할 수 있습니다. 인터넷 회선과 전용회선입니다.

인터넷회선을 이용하는 것이 저렴하긴 하지만 인터넷은 공유네트워크이기 때문에 제한적으로 사용되고 대부분은 전용회선을 이용하게 됩니다. 전용회선 비용이 기가급으로 설치되면 비용이 좀 많이 발생하기는 하지만 DR센터를 고민하는 기업입장에선 그리 큰 금액은 아닐거라 생각이 듭니다.

이쯤되면 네트워크에 대한 지식이 있으신 분들은 여러가지 의문점이 생기실것 같은데요...

가령 L2, L3 트래픽은 스위치나 라우터로 비동기 처리를 해도 무관하지만 방화벽 및 L4 같은 경우 세션 문제가 생길 수 있습니다. 이때는 클러스터링 개념이 필요하긴 한데 원격지에 있는 네트워크 장비를 클러스터하기 위해선 Multichassis Etherchannel(MEC) 기술이 있습니다. 대표적으로 Cisco VSS(Virtual Switching System) 또는 vPC(Virtual Port Channel)등이 있습니다.

또한 L4 레이어를 핸들링 하는 방화벽 또는 L4스위치 같은장비는 과감하게 세션 공유는 포기하고 고가용성만 구성하는 방법도(HSRP, VRRP) 있습니다. 이때는 해당장비가 DR센터로 Failover 되면 Failover 당시에 연결되어 있는 세션은 잃어버리게 됩니다.

그리고 원격지 HSRP, VRRP, IBGP등은 제가 DR센터 구축할때까지만 해도 국내사례를 찾아볼 수 없었는데요, 직접 테스트 하고 구축하고 현재까지 운영하면서 이슈가 된적은 없었습니다.

 

추진전략

네트워크 엔지니어가 리딩

제가 2015년에 이 일을 하면서 느꼈던 점은 이런일은 네트워크 엔지니어가 주도해야 한다는 것입니다.
네트워크 엔지니어가 DR 센터 개념을 동일 데이터센터 안에서 네트워크만 확장된 형태로 구성해준다면 서버엔지니어 및 개발엔지니어는 생각보다 쉽게 DR센터 구성을 할 수 있게 됩니다.

워크플로우 분석

그리고 또하나 중요한 것은 주요서비스에 대한 워크 플로우를 정확히 알고 있어야 한다는 것입니다.

모든 서비스를 리스트업하여 관련된 서비스가 어떻게 흐르는지 정확히 찾아내야 합니다. 여기서 문제가 발생하는데요 대부분의 개발자는 본인이 개발한 APP에 대해서만 알지 이 트래픽이 어떤방식으로 네트워크에 흘러가게 되는지 제대로 알고 있는분이 많지 않습니다.

또한, DR 센터를 구축하게 되면 모든 서비스를 완벽하게 DR에 구성하지는 않습니다. 비용때문입니다.
꼭 필요한 필수 서비스 위주로 구축하게 되고, 당장 하루이틀 지연되도 괜찮은 서비스는 DR에 포함하지 않게 됩니다. 물론 나중에 여력이 생기면 이런것들도 하나하나 포함해야 겠지요. 저희도 그렇게 하고 있구요...
그런데 이렇게 주요 서비스 위주로 DR센터를 구축하다 보면 워크플로우를 제대로 이해하지 못해 서비스에 문제가 생기는 경우가 많게 됩니다. 
예를들어 DR 센터로 모든 서비스를 넘기고 메인센터를 전부 셧다운 했는데 워크플로우상에 메인센터를 경유해야 하는 서비스가 있다던가 하는 것들이 생기게 됩니다.

끝맺음

말은 쉽지만 저도 DR센터 구축 프로젝트 진행하는데 1년정도 시간이 걸렸습니다. 테스트도 많이 해야하고 연결해야 하는 네트워크 오브젝트 수량이 일반인이 생각하는것보다 어마어마하게 많기는 합니다.

다만 구조를 정확히 파악하고 빠짐없이 차근차근 진행하면 오래걸릴수는 있으나 생각보다 기술적으로 어렵지 않게 DR 센터를 구축할 수 있지 않을까 생각이 듭니다.