일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Spring Data Redis
- 리팩터링
- Jenkins
- 카카오 화재
- 공변
- backend
- 부하테스트
- 웹캐시
- B+TREE
- 상태패턴
- lazyloading
- Ehcache
- 동시성
- nonclustered index
- JPA
- 재고 시스템
- 지연로딩
- JDK14
- java
- JAVA8
- GithubActions
- springboot
- ci/cd
- method area
- 트랜잭션
- Metaspace
- 제네릭
- 주문
- CaffeineCache
- Redis
- Today
- Total
NDM
카카오 화재의 발생 원인과 문제점 본문
카카오 사태 이후 문제점을 정리하는 포스팅이다
솔직히 면접에 나올까봐도 있고, 사람마다 다르지만 나는 백엔드 개발자도 인프라나 데브옵스 지식이 필수적으로 요구되는 때가 올거라고 생각하기 때문에 정리하기로 했다.
하지만 굳이 이런이유가 아니더라도 IT를 공부하는 학생으로써 자연스럽게 왜그런거지? 하는 궁금증이 들어 정리하게 되었다.
자연스럽게 궁금증이 생긴것을 보고 뿌듯한 마음도 있었으나 솔직히 DR이나 HW레벨에서의 이중화는 잘 모르는 분야였기에 조금은 좌절하게 되었던 것도 사실이다.
# 문제의 시발점
무정전 전원 공급 장치(UPS)
사실상 전원은 UPS에 연결되어있으며, UPS가 여러대의 서버와 연결되어있는 구조
무엇이고, 왜 이걸 쓰는가?
- 카카오 사태처럼 전원이 순간적으로 끊기면 서버는 갑자기 전원이 중지되어 예기치 못하게 데이터가 모조리 손실될 수도 있다.
- 때문에 UPS를 먼저 연결함으로써, 전원이 끊김을 UPS가 먼저 감지하고 UPS는 "전원이 끊겼으니 서버를 안전하게 ShutDown하라"라는 메세지를 보내게 된다.
- 이로써 데이터의 손실을 막고, 안전하게 서버를 종료할 수 있는 장치이다.
즉, 예기치 못한 사태로의 비정상적인 종료를 막고 서버가 안전하게 ShutDown할수 있도록 시간을 벌어주는 장치이다.
이번 카카오 사태의 문제점중 하나로 UPS에 문제가 생긴것이 아니냐 추정중
# 왜 대응이 미비했을까
백엔드를 공부하는 학생들은 보통 위처럼 SW레벨에서의 부하분산을 고민한다.
대용량의 트래픽이 하나의 서버에만 집중되는 것을 막기위해 서버를 Scale-out하고 여러 클라이언트의 요청을 로드밸런서를 통해 부하분산한다. 마찬가지로 DB에 가해지는 부하도 막기위해 CacheDB를 쓰거나, Replication을 하기도 한다.
위의 인터뷰 내용을 보면 데이터도 분산저장이 잘 되어있는 것 같고, 국내 인구의 4/5가 쓰는 서비스인 만큼 그 트래픽을 감당하기 위한 SW레벨에서의 분산은 잘 이루어지고 있는것으로 보인다. 하지만 여기서 문제는 SW가 아니라 HW서버를 보관하고 있는 IDC센터에 화재가 발생했다는 것이다.
이렇게 여러 대기업들은 한군데 데이터를 몰빵해놓지 않고 물리적으로 여러 지역에 데이터센터를 분산시킨다.
그래야 예기치못한 사태로 인해 한 IDC에 문제가 생겼다고 해도 속도는 느려지겠지만 다른 지역의 서버를 이용해 서비스를 지속할 수 있기 때문. 하지만 카카오는 이번 사태로 보았을 때 하나의 데이터센터에 서버를 거의 몰빵해놓은것으로 추정이 가능하다.
큰 사각형을 하나의 데이터센터로 보고, 왼쪽이 판교, 오른쪽이 카카오가 현재 짓고있는 한양대에리카의 데이터센터라고 가정하자. 왼쪽과 오른쪽이 거의 똑같다.
그리고 각 데이터 센터는 네트워크를 통해 서로 통신하며 혹시모를 사태에 대비한 대응체계를 구축해야 한다.
만약 카카오가 물리적인 이중화 시스템을 잘 구성해 놓았다면 왼쪽 판교 데이터센터에 문제가 생겼어도 한양대로 요청을 돌려 서비스가 지속되었어야 한다. 하지만 이번 사태로 보았을 때 카카오는 결국 하나의 데이터센터에 서버를 몰빵해두었고, 이에 대한 대응체계가 미흡했다고 볼 수 있을 것 같다.
서버 스냅샷이라도 떠서 클라우드로 관리했다면 더 빠르게 복구가 가능했겠지만 이것도 잘 되어있지 않은것으로 보인다.
위 인터뷰에서 보면 이중화는 했으나 전환 과정에 시간이 소요되었다고 하는데, 너무 오랜시간이 걸렸던 것이 문제였던것 같다.
즉, 정리하면
- Web Application이나 DB 등 부하분산을 위한 이중화는 제대로 되어있었으며, 데이터 실시간 백업 시스템도 잘 작동한것으로 보이지만, IDC센터 하나에 모든 물리적 서버가 밀집되어있었다고 추정 가능.
- 그게 불탔으니 HW위의 SW단의 이중화는 크게 의미가 없었음.
- 데이터센터 자체를 한군데 밀집시켜놓지 않고 서울, 대전, 대구, 부산 등 여러군데에 배치했다면 전 서비스가 먹통이 되는 상황도 방지할 수 있었을 것(속도는 느려질수도 있겠지만)
# 그럼 왜 해놓지 않은걸까
가장 큰 요인으로 "비용"이 꼽히고 있다.
이윤을 추구하는 기업의 입장에서 비용절감은 매우 중요한 요소다.
게다가 DR과 관련있는 보안산업의 경우, 최선의 결과가 현 상태 유지인 만큼 소홀히 하는 경향이 있다.
하지만 현재 러시아와 우크라이나의 전쟁상황을 뉴스로 접하면 알 수 있듯이, 러시아는 우크라이나의 기반 시설의 중심으로 타격하고있다. 만약 이번 사태의 원인이 화재가 아니라 타격이였다면 더 큰 혼란이 일었을 것이다.
실리콘밸리의 Microsoft는 탄소중립의 이유가 있다고 하지만 데이터센터를 심해에 넣는 노력까지 하고있다.
# 출처
https://www.youtube.com/watch?v=jg6r6_2lYr4&t=1s
'기타' 카테고리의 다른 글
Enum을 이용해 객체지향적으로 코드 관리하기 (0) | 2023.06.28 |
---|---|
상태 패턴(State Pattern)을 사용하는 방법 (0) | 2023.06.27 |
게시판을 만들어보자 1편 : 요구사항 분석과 ERD설계 (0) | 2022.06.21 |