안녕하세요, 잘 지내셨나요?

이번 에러데이나잇에서는 판교 데이터 센터 화재 사고를 다루었는데요. 아직까지도 여러 기사들이 쏟아져 나오고 있는 가운데 현재까지 나온 이야기를 모아 총정리하는 시간을 가져보았어요. 그럼 오늘의 에러데이나잇 시작합니다.

이번 사고는 판교 SK C&C 데이터 센터 지하 3층 배터리실에서 화재가 발생하면서 시작되었어요. 화재의 원인은 전기실 내 배터리 또는 랙 주변의 ‘전기적인 요인에 의한 발화’인 것으로 추정되었고요. 이 화재로 인해 3만 2000여 대의 카카오 서버가 불타면서 카카오톡을 비롯하여 다음, 이메일, 카카오페이 등 서비스 대부분이 장애를 일으켰어요. 다친 사람도 없고, 건물 외부는 멀쩡해 보일 정도로 큰 화재는 아니었으나 누전 위험으로 전체 전원을 차단했기 때문에 피해는 커졌어요.

해당 데이터 센터에는 카카오뿐만 아니라 네이버도 서버를 같이 쓰고 있어 화재 이후 네이버 쇼핑, 뉴스 등 일부 서비스에도 문제가 생겼어요. 하지만 비교적 빠르게 복구하였고, 카카오의 복구 시간(127시간 30분)과 대비가 되면서 논란은 커졌죠. 이렇게 복구 시간에 차이를 보인 것은 ‘데이터 이원화’ 때문인데요.

카카오는 자체 데이터 센터 없이 이곳을 임차해 3만 2000여대의 서버를 두고 서비스를 운영하고 있어요. 판교 데이터 센터가 메인 센터였던 셈이죠. 하지만 네이버는 2013년 강원도 춘천시에 자체 데이터 센터를 열어 메인 서버를 두었고, 여러 곳에서 데이터 센터를 가동하고 있어요. 이렇게 여러 개의 데이터 센터로 주요 서비스가 이중화돼 있었기 때문에 빠르게 복구할 수 있었죠. (카카오 데이터 센터도 2023년 완공을 앞둔 상황이라고 해요.)

카카오 측에 따르면, 판교를 비롯해 4개의 데이터 센터를 운영하고 있다고 하는데요. 9만 여대의 서버 중 판교 데이터 센터에는 30%의 서버가 있다고 밝혔어요. 그렇다면 다른 센터도 운영하고 있었지만 서비스 중단이 장기화된 이유는 무엇일까요? 데이터 센터 전체의 전원이 차단되는 셧다운 상황에 대비한 훈련이 없었다는 것과 서비스들의 복구 시점이 모두 달랐다는 점을 미루어 봤을 때 이중화 조치가 제대로 되지 않았다는 지적이 나와요.

사실 카카오는 2012년에도 전력 공급 문제로 4시간가량 서비스가 중단된 사건이 있었는데요. 당시 데이터 이원화를 하지 않았다는 질타를 받았지만 그 사건 이후에도 별다른 조치를 하지 않았기 때문에 10년째 제자리걸음이라는 지적을 받고 있어요. 정리해 보았을 때 이번 사건은 자체 데이터 센터가 없었고, 셧다운에 대한 훈련이 없었으며, 서버 이원화가 제대로 되지 못해 서비스 장애가 길어졌다고 할 수 있어요.

카카오 복구가 거의 완료된 시점인 10월 19일 카카오는 기자회견을 열어 장애 사태에 대해 사과를 했고, 남궁훈 대표는 사퇴 의사를 밝혔어요. 이어 24일 국회 과학기술정보통신위원회 종합감사 증인으로 출석하여 무료 서비스 가입자 약 4천500만 명에 대한 피해 보상은 지난 19일부터 접수를 시작하였고 11월 6일까지 피해 사례 접수 후 일괄보상도 검토하겠다고 말했어요.

이런 조치에도 이미 브랜드 이미지는 하락되었고 일부 기업들은 탈 카카오 플랫폼의 움직임을 보이고 있어요. 하지만 서비스가 재개되자 카카오톡에 익숙해진 사용자들은 돌아왔고 25일 기준 4099만 명까지 회복한 상태에요. 이에 카카오가 기업 신뢰도를 어떻게 회복할지 앞으로의 행보가 주목되는 가운데 카카오가 내놓는 보상안이 향후 플랫폼 서비스 장애 보상의 주요 기준이 될 전망이에요.

2대의 시스템을 같이 운영해요. 흔히 *부하 분산 모드(Load-Balancing)라고 불리기도 하며 서비스 단위를 나누어 분산시키기도 해요. 장애 발생 시 안정적인 상태를 유지하기 위해서는 Active-Standby 구성보다 더 높은 처리량을 갖는 서버나 더 많은 대수로 구성해야 해요.

장점

- 비용, 장애 대응 측면에서 가장 이상적인 방법이에요.

- 모두 활성화 상태로 실시간으로 동기화되기 때문에 다운타임 없이 처리 가능해요.

단점

- 초기 구성과 운영이 복잡하고 구축 시간과 비용이 많이 들어요.

- 아키텍처가 복잡하고 사이드 이펙트가 발생할 가능성이 커요.

2대의 시스템 중 하나는 가동이 되고, 하나는 장애를 대비해서 준비 상태로 대기시켜요. 장애가 발생하여 Active 장비가 죽게 되면 Standby 장비가 Active 상태가 되어 처리해요. 이렇듯 *failover를 위해 주로 사용하며 가장 많이 사용하는 구성이에요.

장점

 -아키텍처가 심플하여 간단한 구성 및 장애 대응이 가능해요.

단점

 - 하나의 시스템은 대기 상태로 Standby 장비에 대한 비용이 계속 나가기 때문에 비효율적이에요.

 - 다운타임이 1-2초(서버 운영 환경에 따라 다름) 발생하고 그때 발생한 데이터는 소실될 우려가 있어요.

Active-Standby 방식은 크게 3가지로 구분하는데요.

Hot이 failover 시간이 가장 짧으며 Warm, Cold 순으로 짧아요.

#Hot Standby Standby: 장비가 가동되었을 때 즉시 사용 가능해요.

#Warm Stanby Standby:  장비가 가동되었을 때 설정에 대한 준비가 필요해요.

#Cold Standby Standby: 장비를 평소에는 정지시켜두며 필요에 따라서 직접 켜서 구성을 해요.

하나의 서비스가 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율, 부하량, 속도 저하를 적절히 분산하여 해결하는 서비스예요.

여러분들은 Lambda에 대해 얼마나 알고 계시나요? Lambda는 프로그래밍 언어에서 사용되는 개념으로 익명 함수(Anonymous functions)를 지칭하는 용어에요.

대부분 Lambda를 컴파일된 class 파일을 리버싱하여 Java 코드로 보실 텐데요. 그렇기 때문에 class 파일 직접 보는 건 생소해서 어려울 수 있어요. 해당 포스트에서는 쉽게 접하기 어려운 Lambda가 컴파일된 class 파일로 쉽게 예시를 들어 차이점을 알아보았습니다.

Lambda가 동작하는 원리에 대해 자세히 알고 싶다면 꼭 읽어보시길 추천드립니다.

(이미지를 클릭하시면 상세 내용을 확인하실 수 있어요!)