카카오 장애로 생각해보는 서버 이중화

금일 사상 초유의 카카오 서비스 전면 장애가 발생했습니다. 현재 보도된 뉴스에 따르면 판교 데이터센터의 화재로 운영중이던 서버의 전원을 내려서 발생한 장애라고 하는데요, 사실 이건 카카오의 문제라기보단 재난에 가까운 사건이긴 합니다. 이런 재난에 가까운 사건을 막을 수 있는 방법은 없을까요? 사실은 서버 이중화 혹은 고가용성(High Availability) 이란 주제로 다양한 방법이 존재합니다. 간단하게 다음과 같은 몇가지 전략들이 있습니다. 1. Active-Standby 평소에는 특정 서버에서 서비스를 운영하고 해당 서버가 장애가 발생하면 대기중인 서버를 투입하여 대응하는 방법입니다. Active 서버는 변경되는 데이터가 있을때마다 Standby 서버로 전달하여 데이터를 동기화함으로써 장애가 발생할 경우 그 즉시 투입이 가능한 상태가 되어야 합니다. 아키텍쳐가 심플하여 간단한 구성 및 장애대응이 가능하지만 장애가 발생하지 않는다면 사용하지 않는 Standby 서버에 대한 비용이 계속 발생한다는 문제가 있습니다. 2. Active-Active 서로 다른 서버가 모두 서비스를 운영하는 형태입니다. 비용과 장애 대응 측면에서 가장 이상적인 방법이지만 아키텍쳐가 복잡하고 자칫 다른 사이드 이펙트가 발생할 가능성이 큰 형태입니다. 데이터 변경이 발생할 수 있는 요청들이 각 Active 서버에 분산되서 전달할 경우 이 데이터 변경들에 대한 순서를 보장하는게 쉽지 않기 때문입니다. 물론 불가능한건 아니지만 그만큼 많은 고민과 구축하는데 시간이 오래 걸릴 수 있는 형태입니다. 3. Sharding 데이터를 여러곳의 서버에 분산시키고 사용자의 요청을 받았을때 데이터가 있는 서버로 전달하도록 구축하는 방식입니다. 이렇게 하면 특정 서버가 장애가 나더라도 전면 장애가 발생하는걸 피할 수 있습니다. 또한 위에서 언급한 Active-Standy 를 적용하면 특정 서버에 장애 발생시 Standby 쪽을 활성화시켜 빠른 장애 대응이 가능할 수 있습니다. Active-Active 형태처럼 복잡하지 않으면서 간단한 장애 복구가 가능한 구조인데요, 단점을 꼽자면 분산된 데이터가 어디있는지에 대한 메타데이터를 잘 관리해야하고 자칫 잘못하면 이부분이 SPOF 가 될 가능성이 높습니다. 물론 카카오가 위와 같은 이중화 전략을 안해서 이번 장애가 발생했다고 보진 않습니다. 카카오 같은 대규모 서비스의 경우 아키텍쳐가 복잡하고 이를 위한 이중화 대응에 많은 고민과 노력이 필요했을텐데요, 그러다보니 일부 코어 서비스의 이중화 작업상에 이슈가 있었거나 이를 복구할때 예상치 못한 이슈가 발생하여 이번 장애가 발생한게 아닐까 조심스럽게 추측해 봅니다. 주말에 고생하고 계실 카카오 관계자분들 모두 힘내시고 장애 복구가 빨리 되길 기원합니다. 이번 장애를 발판삼아 카카오가 서버 이중화 및 고가용성에 대한 best practice 를 보여주면 좋겠습니다.

다음 내용이 궁금하다면?

또는

이미 회원이신가요?

2022년 10월 15일 오후 12:31

 • 

저장 222조회 18,457

댓글 10

  • 이중화가 안되어 있지는 않을겁니다. 다만 DR구축등을 위해서 GSLB를 어디에 두었는지.. 그리고 이중화 및 DR구성된 서비스들이 정말 설계대로 잘 전환이 되며 그 전환 과정속에 Data 손실은 없는지등 수 많은 체크 포인트가 있고 수 많은 기업들이 정부나 업계의 룰에 의해서 DR과 HA구성은 하지만 실제 운영횐경에서 장애대응 훈련을 하는 경우는 거의 없습니다. 즉 훈련이 안되어 있으니 실제 상황에서 판단을 주저하게 되고 실행을 못하게 되는거죠.. 카카오 장애를 보면서 피가 마를 엔지니어와 직원분들이 걱정이 되더라구요.. 잘 복구되어 이번일을 계기로 좋은 서비스 견고한 서비스가 되길 빕니다. . 쓰다보니 쫌 과하게 쓴거 같아서 정정합니다 규정상 DR 구성과 HA구성 및 년 1회 이상의 전환 훈련을 해야 하기때문에 구성 및 훈련을 할겁니다. 다만 그 훈련과 구성이 얼마나 진정성이 있는지는 의문 입니다. 원인은 비용때문이겠죠.. 충분한 인력과 자원이 투여되지 못했으니.. DR은 최소로 유지 하고 HA도 중요 서비스만 구성을 하니 이게 장애 상황에서 아무 문제 없이 정상서비스가 될지는 미지수 니깐요..

    당연히 이중화 100% 되어 있습니다. 장애를 100% 막을 수 있는 수단은 없습니다, 그냥 근접하게 대비를 하는거죠

    삼디는 삼화에서 하던데 DR테스트 잘하고 있네요

  • 이건 이중화 문제가 아니라 DR 일거 같은데요. 서버 이중화는 기본적으로 다 되어 있을 겁니다. 근데 찾아보니 DR 구축도 다 되어 있는거 같네요. https://n.news.naver.com/article/138/0002134672?sid=105 그래도 카카오 엔지니어팀이 기본적인 걸 구축 안해놓지는 않았을 거예요 ISMS-P 심사 같은거만 진행해도 다 충족해야하는 조건들이여서요

    넵 구성은 되어 있을겁니다 규정상 년 1회 이상의 전환 훈련도 할거고.. 쓰다보니.. 너무 과하게 썼네요.. ㅜㅜ 운영환경에서( 사용자들이 사용하는 일과 시간대.. )가 아닌 야간등 최소 서비스 운영 시간대에 DR전환 훈련을 하다보니 전환 초기에 과부하등에 대한 대응이나 전환 후 정상 기동 및 역전환응 정상으로 할 수 있을지에 대한 확신이 없다보니 쉽지 않을거라는 얘기를 하고자 했는데 오해소지가 있게 쓴거 같네요. ㅜㅜ

    예전 저희 회사도 IDC 파워 나가서 맨붕온 적 있었는데 수일동안 복구하느라 겁나 빡쌨죠. 카카오 앤지니어분들 심정이 어떨지... ㅜㅜ.

  • 다들 좋게 말씀하셨는데 같은 엔지니어 입장에서 많이 헤아려주셔서 그런듯 합니다. 전 개인적으로 엄청 실망했습니다. 예전 아현에서의 사태도 있었는데 반면교사 삼지 못한건지 안한건지... 대한민국의 IT가 보안관련 부분에 신경도 많이 안쓰고 비용도 아끼려하고 취약하다는 것은 많은분들이 알고 있을겁니다. 대한민국 최고IT기업 중 하나로 꼽히는 카카오가 이런 모습을 보일거라고는 상상도 못했는데.... 어쨌든 이번일을 교훈삼아 데이터의 중요성 백업 리커버리 등등 높은 수준도 아닌 기본적인 대처에 투자 및 관심을 갖는 계기가 되기를 바라며 두서없이 혼자 끄적여봅니다.

    주말에도 뼈빠지게 일하고 계실 카카오다니시는분들 응원합니다

  • 데이터센터 한곳에 불났다고 전체 서비스가 다운되는건 솔직히 이해해주기 어렵습니다. Reliability라는 주제에 거의 투자를 안한게 아닌가 싶네요

  • 몇 기업의 HA를 보며 든 생각입니다. 사견이고 매우 범위가 좁으니 설마... 하는 생각이긴 한데, HA를 같은 DC 안에 구성하는 경우가 있었습니다. 그것도 제가 맡았던 곳은 다 그랬죠...ㅎㅎ DC 하나가 통째로 이번같은 화재/전원 차단 이슈가 발생한다면 필수적으로 해당 DC에 연결된 모든 서비스가 HA를 구동중이라고 해도 날아갈 수 밖에 없는 구조였습니다....두둥!

함께 읽은 게시물


꿈을 찾는 사람에게 보내는 158 번째 편지

... 더 보기

퇴사 부검 : 네이버를 떠나며

... 더 보기

퇴사 부검 : 네이버를 떠나며

taetaetae.github.io

퇴사 부검 : 네이버를 떠나며

 • 

저장 28 • 조회 4,955


요구사항 변화에 따른 프로젝트 구조 확장 ⛏

... 더 보기

요구사항 변화에 따른 프로젝트 구조 확장_Bradley 멘토님

F-Lab : 상위 1% 개발자들의 멘토링

요구사항 변화에 따른 프로젝트 구조 확장_Bradley 멘토님

 • 

저장 35 • 조회 3,482


넷플릭스는 왜 WebFlux를 사용하지 않을까?

... 더 보기

넷플릭스는 왜 WebFlux를 사용하지 않을까?

kr.linkedin.com

넷플릭스는 왜 WebFlux를 사용하지 않을까?

첫 회사보다 중요한 것

... 더 보기

- YouTube

undefined

 - YouTube