온라인 서비스를 하는 이상 장애는 피할 수 없는 재해입니다. 그리고 운전을 하다가 백미러가 부러졌을 때 일단 청테이프로 긴급 수리하고 정비사에게 가는 것처럼, 보통 이럴 때 사용하는 대응책(mitigation)이 있기 마련입니다. (hotfix는 대표적인 긴급 대응책이죠.) 그렇다면 과연 "일반적으로" 사용할 수 있는 긴급 대응책이 존재할 수 있을까요? 예를 들면 binary rollback은 가장 흔하게 사용하는 긴급 대응책입니다. auto-scaling은 폭발적인 트래픽 증가에 대응하기 위한 가장 쉬운 방법이죠. 다만 이를 일반적으로 사용하기 위해서 반드시 필요한 조건이 있는데, 바로 문제의 원인을 다 파악하지 못했다 하더라도 사용 가능해야 한다는 점입니다. 만약 긴급 대응책이 문제의 원인과 밀접하게 연관되어 있다면 문제를 상세히 이해할 때까지 서비스를 사용할 수 없게 됩니다. 문제를 이해하는데 필요한 시간을 줄이는 것은 매우 어렵고, 긴급 조치로 서비스를 일단 사용할 수 있도록 하는 편이 훨씬 쉽습니다. 일반적인 긴급 대응책은 아래와 같은 패턴으로 분류할 수 있습니다. - Rollback : 서비스를 과거의 가장 안정된 상태로 되돌립니다. 장애의 원인을 파악할 시간을 벌기 위해 안전한 롤백 프로세스를 갖출 필요가 있습니다. - Data Rollback : Rollback의 하위 사례로 데이터만 이전 상태로 돌립니다. 콘텐츠가 많은 서비스에 유용하게 쓸 수 있습니다. - Degrade : 서비스의 로드를 낮추기 위해 의도적으로 성능을 저하시킵니다. 일부 성능 저하가 일어나지만 서비스가 유지될 수 있도록 합니다. - Upsize : 스케일링은 비싸지만 대량의 트래픽에서 서비스를 지키는 댓가로 결코 비싸다고만 말할 수는 없습니다. - Block list : 일부 유저의 요청이 성능 저하를 일으키는 상황이라면 이들을 차단하여 서비스를 지킵니다. - Drain : 한 곳에 집중되는 트래픽을 여러 곳으로 분산시킵니다. 랜딩 홈이 여러 개 존재할 수 있는 경우 유용합니다. - Quarantine : 문제를 일으키는 부분을 서비스에서 격리시킵니다. 조회가 빈번한 DB의 특정 row, 스팸성 유저, 비정상적인 트래픽 등을 서비스가 아닌 다른 곳으로 흘러가게 합니다. 다만 아이러니하게도 이러한 긴급 대응책은 매우 구체적이라는 점이 문제입니다. 즉, "일반적인" 긴급 대응책의 일반적인 패턴은 있지만, 특정 서비스에 적합하도록 신중하게 조정할 필요가 있습니다. 또한 비상 상황에서 잘 작동할 수 있도록 평소에 연습해 보고, 자동화 테스트를 붙이고, 새로운 멤버도 쉽게 익숙해질 수 있도록 체크리스트를 작성하는 것이 필요합니다. 시스템은 갈수록 복잡해지기 때문에 주기적인 실행을 통해 이를 검증할 필요가 있습니다. 결국 목표는 쉽고 안전하며 부작용 없는 "패닉 버튼"을 만드는 것입니다. 사용자는 완벽하게 수정되기를 기다리는 상태보다 대부분의 기능이 그럭저럭 돌아가는 상태를 더 좋아합니다. 이를 구축하는 것은 결코 쉽지는 않지만, 장애 상황에서 원인 분석을 하는 동안의 길고 긴 서비스 불가능 상태를 견디는 것보다는 쉬울 것입니다. --- (🚀 채용 광고) '신상마켓'을 운영하는 딜리셔스에서는 동대문 패션 생태계를 기술을 통하여 더 나은 모습으로 디지털화하고 함께 성장하여 글로벌까지 연결하는 꿈을 갖고 있습니다.🚀 이런 분들을 찾고 있습니다. - Java / Ruby Developers - Android / iOS Developers - Web Developers (React.js / Vue.js) - Data Engineers on AWS - DevOps on AWS - Product Managers / Product Designers - Data Analysists - Ad Platform Developers / PMs b2b 뿐만 아니라 b2b2c/글로벌 등 다양한 제품군을 준비 중이고, 주도적으로 오너십을 갖고, 자율적으로 일하는 환경을 지향합니다 ☺️ 채용 더 알아보기 >> https://www.wanted.co.kr/company/3059