Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
네트워크 / 보안

아틀라시안의 클라우드 장애에서 배운 4가지 네트워크 베스트 프랙티스

David Strom | Network World 2022.05.09
지난 4월 소프트웨어 툴 제공업체 아틀라시안(Atlassian)이 2주 동안 중대한 네트워크 중단을 경험했고, 20만 명이 넘는 고객사 중 400곳 이상이 영향을 받았다. 네트워크 중단으로 인해 자이라(Jira), 컨플루언스(Confluence), 아틀라시안 액세스(Atlassian Access), 옵스지니(Opsgenie), 스테이터스페이지(Statuspage) 등 여러 제품에서 문제가 발생했다. 
 
ⓒ Getty Images Bank

클라우드 장애는 사이버 공격이나 악성코드가 아니라 아틀라시안의 직원에 의한 일련의 불운한 내부적 오류의 결과였다. 수 분 이상의 데이터 트랜잭션을 잃은 고객사는 없었으며 대부분은 다운타임이 전혀 발생하지 않았다. 2주 동안 영향을 받은 고객사는 일부였지만, 아틀라시안 소속 엔지니어들이 발견하지 못한 문제의 깊이와 문제를 찾아 해결하는 데 소요된 시간 측면에서 클라우드 장애는 중대한 사건이었다. 

아틀라시안 클라우드 장애 사태에서 흥미로운 부분은 회사의 대응이다. 아틀라시안은 사건 발생 초기에는 고객사에 공지를 제대로 전달하지 못했으나 그 이후 사고에 대한 매우 자세한 내용이 담긴 장문의 블로그 게시물을 공개했다. 이런 대규모의 공개적인 네트워크 중단을 겪은 제공업체가 상황과 이유를 사려 깊게 설명하고 다른 기업도 배울 수 있는 로드맵을 제공하기 위해 노력하는 경우는 드물다. 

게시물에서 아틀라시안은 기존의 IT 인프라를 신중하게 설명하고 재난 복구 프로그램의 문제를 지적한 뒤, 미래의 중단 사태를 예방하기 위해 문제를 해결하는 방법을 설명하고 프로세스를 개선 일정과 워크플로우, 방법을 설명했다.

이 문서는 솔직하고 사실에 기반하고 있으며 중요한 관련 사항이 가득하므로 모든 엔지니어링 및 네트워크 관리자에게 읽어 보기를 권한다. 유사한 실수를 찾아 해결하기 위해 소프트웨어에 의존하는 모든 기업은 이를 템플릿으로 활용해야 하며, 자체적인 재난 복구 각본을 솔직하게 평가하는 논의 프레임워크로 활용해야 한다. 


사고로부터 배운 교훈

문제는 아틀라시안이 기능적으로 유사한 소프트웨어를 구입하며 중복된 구형 앱을 삭제하기로 결정하면서 시작됐다. 이 과정에서 아틀라시안은 서로 연관된 개별 업무를 2개의 팀에 각각 할당하는 실수를 저질렀다. 한 팀은 중복된 앱의 삭제를 요청했고, 다른 팀은 실제로 해당 작업을 수행하는 방법을 파악해야 했다. 이로 인해 적신호가 울렸다.

두 팀은 같은 언어와 파라미터를 사용하지 않았으며, 그 결과 즉각적인 의사소통에 문제가 있었다. 예를 들어 한 팀은 앱 ID를 사용하여 삭제할 소프트웨어를 확인했는데, 다른 팀은 그들이 앱이 위치한 클라우드 인스턴스 전체의 ID에 관해 이야기하고 있다고 생각한 것이다.


교훈 1 : 내·외부 의사소통을 개선하라

네트워크 변경을 요청하는 팀과 변경을 실제로 구현하는 팀은 하나의 팀이어야 한다. 그렇게 하지 못할 경우에는 각 팀들이 동기화되고 같은 언어를 사용하며 절차가 정확하도록 탄탄한 의사소통 도구를 마련해야 한다. 잘못된 의사소통으로 인해 아틀라시안의 엔지니어들은 며칠 동안 실수가 미칠 영향을 파악하지 못했다.

팀 간 의사소통은 문제의 일부에 불과했다. 아틀라시안은 여러 관리자 및 고객 사이의 의사소통을 분석한 뒤 24시간 안으로 세부 사항을 자체 모니터링 시스템에 게시했지만, 일부 고객사에는 직접 연락할 수 없다는 사실을 발견했다. 구형 사이트가 삭제될 때 연락처 정보가 상실되었고, 다른 정보는 매우 오래되었기 때문이었다.

게다가 삭제된 데이터에는 고객들이 유효한 지원 요청 티켓을 작성하기 위해 필요한 정보가 포함되어 있었다. 따라서 아틀라시안 개발자들은 이 문제를 해결하기 위해 지원 티켓 프로세스를 새로운 구축하여 배포해야 했다. 또한 아틀라시안은 복구 프로세스의 범위를 전체적으로 파악할 때까지 기다리지 않고 네트워크 중단 초기에 연락을 취했어야 했음을 인정했다.

중단 초기에 연락을 했었더라면 고객사들은 구체적인 시한이 없더라도 사고에 대한 더 나은 계획을 수립할 수 있었을 것이다. 아틀라시안 측은 “우리는 신속한 사이트 복구 날짜 제공이 불확실한 것을 인정하고 직접 논의에 더 일찍 참여하여 고객들이 이에 따라 계획을 수립할 수 있도록 해야 했다. 우리는 중단에 관해 파악한 내용과 파악하지 못한 내용을 투명하게 공개해야 했다”라고 말했다. 


교훈 2 : 고객 데이터를 보호하라

재난 복구와 관련하여 고려해야 할 또 다른 사항이 있다. 고객 데이터를 신중하게 취급하고 최신 상태로 정확하게 여러 개의 분리된 장소에 백업되도록 해야 한다. 재난 발생 시 고객 데이터가 보호되도록 하고 각본에 구체적인 확인 사항을 포함하는 것도 중요하다.

4월 중단 사태 중, 아틀라시안은 목표하던 복구 시기를 놓쳤지만, 중단 사태 몇 분 전의 데이터는 복구할 수 있었기 때문에 복구 지점 목표는 충족할 수 있었다. 다만 일련의 고객 사이트를 선택하고 백업에서 제때 복원하는 자동화된 방식이 없었기 때문에 상호 연결된 모든 제품을 사고 이전의 순간까지 복구하지는 못했다.

아틀라시안 측은 “4월에 발생한 사이트 수준의 삭제는 이 이벤트의 규모에 맞춰 신속하게 자동화할 수 있는 설명서가 없었다. 단일 사이트를 복구할 능력은 있었지만, 대규모 사이트 배치를 복구할 역량과 프로세스는 구축하지 않았다”라고 밝혔다. 아틀라시안은 해당 블로그에서 과거의 대규모 사고 관리 프로세스를 차트로 공개했는데, 유동적인 부분이 많고 4월 사고의 깊이와 비용, 기간에 대응하기에는 무리가 있었음을 알 수 있다.


교훈 3 : 복잡한 재난 복구 시나리오를 테스트하라

재난 복구 프로그램과 각본, 절차를 확인하고 재확인하여 다양한 목표를 충족하는지 확인하고 모든 규모의 고객 인프라에 걸쳐 시나리오를 테스트해야 한다. 즉, 대규모 사건에 구체적으로 대응하고 예측하며, 다양한 제품을 사용하거나 상호 연동된 애플리케이션 시리즈와 시퀀스에 의존하는 고객들의 복잡한 관계를 이해해야 한다.

자동화를 사용하고 있다면 API가 적절히 작동하고 그렇지 않을 때 적절한 경고 신호를 보내는지 확인해야 한다. 아틀라시안은 중단 사태가 지속한 며칠간 상황에 따라 이런 문제를 확인해야 했다고 밝혔다.


교훈 4 : 구성 데이터를 보호하라

마지막으로, 전체 중단 사태가 시작된 데이터가 삭제된 방식에 관한 문제가 있다. 이제 아틀라시안은 사이트 전체의 데이터를 삭제하지 못하도록 해야 한다는 사실을 깨달았다. 아틀라시안은 정의된 시스템 롤백을 면밀히 분석하고 여러 안전 조치를 통과할 때까지는 데이터를 삭제하지 않는 이른바 ‘소프트 삭제(soft delete)’로 전환하고 있다.

아울러 아틀라시안은 모든 시스템에서 ‘포괄적 소프트 삭제(universal soft delete)’ 전략을 수립해 일련의 표준을 개발하고 내부 검토를 거치고 있다. 소프트 삭제는 단순한 선택지가 아니다. 구성 데이터는 인프라 전반에 걸쳐 테스트할 때까지 삭제하지 않는 것이 좋다.
editor@itworld.co.kr
 Tags 아틀라시안 보안 클라우드장애

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.