| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- random
- thymeleaf
- 서버오류
- OVH
- 자료형
- Leetcode
- 자동완성
- 서버중단
- 논리학
- 코테
- 큐
- 명제
- github
- linux
- 코딩테스트
- springboot
- LiveTemplate
- char[]
- JAVA기초
- 백준
- github cli
- PR
- Intellij
- elasticbeanstalk
- AWS
- 데이터센터
- Queue
- 통신대란
- string
- Java
- Today
- Total
Midnight Coder's Lounge
카카오 서버 중단, 돌아보는 서버 사건사고들 본문
15일 저녁 판교 데이터 센터의 화재로 카카오의 모든 서비스가 중단되는 일이 발생했습니다.
화재 진압 과정에서 불가피하게 전력망을 차단한 것이 서버 중단의 직접적인 원인인 것으로 알고 있습니다.
제일 우려가 컸을 카카오톡은 최우선으로 복구가 된 것 같지만
티스토리는 서비스 복구가 늦어져 난감했는데,
21시 30분부터 티스토리 글쓰기 기능이 돌아온 것을 확인했고
그간 작성했던 게시글도 잘 남아있는 것 같습니다.
사실 서비스 중단이라는 사태가 처음 벌어지는 일이 아닙니다.
불의의 사고로 대규모 서비스가 중단된 사례도 있었고,
또 서비스의 중요성을 악용해 공격하는 사례도 있었지요.
그 때마다 기업들이 사고를 대비해서 서비스 중단을 예방해야 한다는 이야기도 수시로 있었습니다.
온라인 서비스와 관련된 사건사고 사례를 몇 가지 모아봤습니다.
‘exit’ 하나 때문에… KT 통신대란 사건 (‘21.10.25)
어느덧 사건 발생 1년째로 접어들고 있는 KT 통신대란 사건입니다.
부산 사상구 소재 KT 전화국에서 통신 장비를 교체하던 중,
전국적으로 1시간 반 가량 KT 인터넷 서비스 장애가 발생한 사건입니다.
사건의 규모도 규모였지만, 발생 원인이 고작 엑시트(exit)라는 단어 하나였다는 사실 때문에 충격적인 사건이었는데요.
사건의 발단은 라우터 장비를 교체한 후 설정을 입력하는 과정에 있었습니다.
KT 라우터는 외부 네트워크와 경로를 구성할 때에는 BGP프로토콜을,
KT 내부에서 경로를 구성할 때에는 IS-IS프로토콜을 사용합니다.
사건 당시에는 내부 경로와 연결되는 IS-IS 프로토콜 명령어를 입력하던 중이었고,
그 후 exit를 입력해 프로토콜을 종료했어야 하는데,
이걸 빠뜨리는 바람에 BGP프로토콜을 통해 외부와 연결되고 만 것이죠.
평소의 수십 배에 달하는 정보가 IS-IS프로토콜에 유입되고 말았고,
그 결과 경로 설정에 오류가 발생한 것입니다.
하필 그 당시 KT 라우터 장비들의 IS-IS프로토콜은 안전장치 없이 전국 단위로 연결되어 있었습니다.
그렇게 하면 라우터가 신속하게 최신 정보를 주고받을 수 있었기 때문인데요,
덕분에 지방의 한 라우터에서 발생한 설정 오류가
30초도 채 안 되는 시간에 전국의 모든 KT 서비스 지역에 퍼져나갔고,
그것이 전국적인 통신 장애를 일으키고 만 것입니다.
이 사건은 월요일 점심시간 직전에 벌어져
단순 사무 업무부터 식당의 카드 결제, 병원 진료까지 마비시키는 등 큰 타격을 낳았습니다.
이것이 원래 이용자가 적은 새벽 시간에 배정된 업무였으나 관계자들끼리 멋대로 주간으로 옮겼다는 점,
KT측 관리자는 장비 교체 현장에 있지도 않았고 협력업체 직원만 있었다는 점,
그 밖에 사전 예방 조치나 사후 대책도 허술했다는 점 등등이 속속 탄로나
국민의 공분을 크게 산 사건이었습니다.
[참고자료]
https://imnews.imbc.com/replay/2021/nwdesk/article/6311005_34936.html
https://www.chosun.com/economy/economy_general/2021/10/30/TVGA6W4XQRBPRPYXU5QU7PEFHY/
외국도 오타 때문에… AWS S3 서비스 중단 사건 (‘17.02.28)
KT 통신대란과 비슷한 사건으로,
AWS(Amazon Web Services)에서도 5년 전(’17.02.28) 서비스 중단 사태가 발생한 적이 있습니다.
사건 초기에는 정전 탓이라고 알려졌지만, 결국 원인은 명령어 오타였던 것으로 밝혀졌습니다.
당시 AWS 팀은 Simple Storage Service(S3) 결제 시스템의 속도가 늦어지는 원인을 파악하고 있었고,
원인 파악을 위해 S3의 일부 서버 작동을 중단하려 하였습니다.
바로 그 때 명령어 오타를 내는 바람에 건드리지 말아야 할 서버들까지 꺼 버리고 말았던 것이죠.
150,000개에 달하는 웹사이트를 위해 어마어마한 양의 파일들을 저장하고 있던 서버가 불시에 꺼져 버렸고,
유명 질의응답 사이트 Quora, 블로그 사이트 Medium,
그리고 Giphy, Slack을 포함한 AWS의 주 고객 사이트가 이 사건으로 피해를 입었습니다.
S3를 이용하는 웹사이트뿐만 아니라, S3 기반으로 동작하던 다른 서비스 이용자에게도 피해를 본 것은 마찬가지입니다.
사태를 수습하기 위해 AWS는 오랜 시간에 걸쳐 완전한 시스템 재부팅을 실시해야 했고,
최초 오작동 후 4시간 17분이 지나서야 전체 시스템이 복구되었다고 합니다.
당시 AWS 측에서 밝힌 입장문 전문은 다음 링크에서 확인할 수 있습니다.
https://aws.amazon.com/message/41926/
[참고자료]
https://www.engadget.com/2017-02-28-amazon-aws-outage.html
인터넷의 70%를 죽인다… AWS 데이터센터 폭파 미수 사건 (’21.04.08)
다시 AWS와 관련된 사건을 다뤄보겠습니다.
지난 2021년 1월 6일 일어난 미국 국회의사당 습격 사건을 기억하고 계실 겁니다.
바이든 미국 대통령의 대통령 당선에 반발한 극우 시위대가 일으킨 사건인데요.
당시 국회의사당 폭동에 가담한 어느 남성이 같은 해 4월,
또다시 미국을 뒤흔들 음모를 꾸미다가 덜미를 잡혔습니다.
미국 텍사스 주 출신인 세스 펜들리(Seth Pendley, 28)는
사건 당시 자차 트렁크에 돌격소총을 싣고 의사당 습격에 가담한 전력이 있습니다.
비록 의사당 건물 내부로 진입하진 못했다지만
평소에 무시무시한 사고방식을 가진 사람이란 건 틀림없어 보입니다.
세스 펜들리가 계획한 음모는 버지니아 소재 AWS 데이터 센터를 상대로 한 폭탄 테러였습니다.
의사당 습격 이틀 뒤, 펜들리는 자경단 커뮤니티 웹사이트 MyMilitia.com에서
디오니소스Dionysus라는 닉네임으로 테러를 암시하는 글을 게시했고,
같은 달 말엽에는 암호화 메신저 Signal을 통해
대화 상대에게 테러 계획을 털어놓으며 폭발물을 구할 방법을 물색하였습니다.
실제로 세스 펜들리는 Signal 대화 상대의 주선으로 폭발물 공급책과 접선할 기회를 마련할 수 있었습니다.
4월 8일, 펜들리는 공급책을 만나 폭발물 설치 방법과 격발 방법까지 안내를 받고 폭탄을 건네받았는데요,
폭탄을 차량에 은닉하려는 순간 FBI 요원들이 나타나 펜들리를 현장에서 체포하였습니다.
펜들리가 전달받은 폭탄은 사실 불활성 장치였고, 폭발물 공급책 또한 위장한 FBI 요원이었으며,
Signal에서 만난 대화 상대도 FBI와 내통하고 있던 것이었습니다.
의사당 습격 사건이 낳은 정치적 이슈는 안 그래도 아마존에게 골칫거리였던 모양입니다.
아마존은 미국 극우세력과 연관관계가 있는지 조사를 받게 되었으며,
습격 3일 후인 1월 9일에는 Parler라는 커뮤니티 사이트와 관계를 끊고
클라우드 서비스 제공을 중단하겠다고 선언한 터였죠.
정작 세스 펜들리 같은 극우파에게도 AWS는 눈엣가시였나 본데요.
펜들리가 Signal을 통해 밝힌 계획은
“C-4를 터뜨려 AWS의 데이터 센터를 공격하고, 인터넷의 70%을 죽여버리겠다”는 것이었는데,
그렇게 하면 FBI와 CIA를 비롯한 연방 기관의 서버도 마비될 것이고,
자기 손으로 미국을 지배하는 '과두 정권'을 무너뜨리게 될 것이라고 생각했다네요.
여러모로 21세기 테크 대기업이 갖는 막중한 정치적 입지를 실감하게 하는 사건입니다.
펜들리는 폭탄 테러에 대한 음모를 시인하고 법정에서 10년형을 선고받았습니다.
[참고자료]
https://www.justice.gov/usao-ndtx/pr/texas-man-sentenced-10-years-plotting-attack-data-centers
https://datacentremagazine.com/data-centres/aws-bomb-plot-how-has-it-impacted-data-centre-security
https://www.buzzfeednews.com/article/johnpaczkowski/amazon-parler-aws
센터가 4군데였지만… OVH 데이터 센터 화재 사건(’21.03.10)
이번 판교 데이터 센터 사건과 퍽 닮아 있는 또다른 데이터 센터 화재 사건입니다.
OVH(OVHcloud)는 1999년 옥타브 클라바Octave Klaba가 설립한 프랑스의 클라우드 서비스 회사입니다.
다소 생소할 수 있는 이름이지만, 유럽에서는 인기 있는 클라우드 서비스 업체입니다.
무려 AWS와 구글 클라우드, 마이크로소프트의 Azure와 대등하게 겨루고 있는 사이죠.
그런데 2021년 3월 10일, 프랑스 동부의 스트라스부르Strasbourg 지역에 있는
OVH 소유의 데이터 센터에서 화재 사고가 발생했습니다.
당시 시간은 자정을 갓 넘어선 직후였는데,
이 사건으로 수백만 개에 달하는 웹사이트가 정지되어 버렸고,
쇼핑몰과 뉴스, 은행과 정부 기관이 마비되는 사태가 벌어졌습니다.
CEO의 트윗에 따르면 당시 소방관이 즉각 현장에 출동하긴 했지만, 화재를 진압할 수는 없는 상황이었다고 합니다.
다만 OVH는 데이터 센터를 총 4곳으로 분산 관리하고 있었으며,
OVH의 데이터는 클라우드를 통해 백업이 되고 있었습니다.
다만 OVH 데이터 센터에서 자체 베어메탈 서버를 가동하던 사업주는 화재로 인해 복구 불가능한 타격을 입었습니다.
베어메탈 서버가 하드웨어 성능과 보안성은 좋았을지 몰라도,
클라우드 백업을 제공하지는 않았기 때문입니다.
한편 OVH 데이터 센터 시설의 안전성도 문제가 제기되었는데,
5층에 달하는 센터 건물 바닥이 목재로 되어있는가 하면,
자동소화설비가 제대로 갖춰져 있지 않다는 지적이 수차례 나타나기도 하였습니다.
공교롭게도 화재 당시에 러시아 지역에서 약 2시간 가량 구글과 유튜브 서비스가 중단되는 사건이 발생하여,
이것이 OVH 화재 사건과 연관된 것이 아니냐는 문의가 쏟아지기도 했지만 구글은 이를 공식적으로 부인했습니다.
OVH의 사고 당시 대처 상황은 다음 링크에서 확인할 수 있습니다.
https://us.ovhcloud.com/press/press-releases/2021/fire-our-strasbourg-site
[참고자료]
https://www.bbc.com/news/technology-56364490
마치며
한국에서 스마트폰 쓰면서 카카오톡은 안 쓴다는 사람이 있을까요?
상상하기가 어려울 겁니다.
그만큼 너무 당연하게 사용하는 서비스다 보니 자연히 의존도도 높아지게 되었고,
서버 중단으로 발생한 타격도 무척 크게 다가왔으며,
일각에서 우려하는 것처럼 우리가 특정 기업의 서비스에 과도하게 기대고 있지는 않았는지,
또 서비스를 제공하는 기업에서는 그 점유율만큼 책임감 있게 관리를 하고 있는지 잠시 돌아보게 된 듯합니다.
사고는 예고 없이 돌아옵니다.
서비스 관리자가 생각지도 못한 실수를 낸다면?
화재는 물론, 침수나 붕괴 같은 재해가 또 일어난다면?
연일 군사적 긴장이 고조되던 어느 날 핵심 서버가 불시에 습격을 당한다면?
서비스가 복구되기 전까지 많은 분들에게 시간이 무척 길고 지루하게 느껴졌을 것입니다.
긴 시간이었던 만큼 앞으로 어떤 변화가 필요할지 숙고하는 시간이 되었으면 합니다.