GDSC 세션에서 발표한 내용을 포스트로 재구성했습니다.
만약 내가 운영하는 프로젝트를 서비스하다가 문제가 생기면 어떻게 해야할까? 하는 궁금증을 가지고 있었는데,
최근 있었던 일을 겪으며 '고가용성' 서비스를 어떻게 하면 제공할 수 있을 지 직접 알아보게 되었습니다.
고가용성이란, 장애가 생기더라도 빠르게 복구할 수 있는, 시스템을 최대한 중단 시간 없이 운영할 수 있는 성질을 말합니다.
하나의 시스템에서 서비스가 불가한 장애 발생 시 다른 시스템으로 옮겨 서비스의 중단을 최소화하는 기술입니다.
사실상 완전히 중단을 막을 순 없으며, 서비스 중단을 막기 위한 최선의 방법을 선택하는 것이 고가용성입니다.
일반적으로 가용성에 따른 서비스 제공 시간은 아래와 같습니다.
| Availability | Downtime per year |
| 90% | 36.5일 |
| 99.99% | 52.6분 |
| 99.999% | 5분 26초 |
이중화 전략을 통해 고가용성을 제공한다고 할 수 있는데,
일반적인 시스템 설계는 보이는 그림과 같습니다.
하드웨어 관점에서 이중화해주고, 부하 분산 처리해주고 하는 등 머리아픈 여러 개념이 있는데,
상세한 내용보다 큰 틀에서 어떻게 이중화하는지를 살펴보도록 하겠습니다.
서버 이중화 전략
서버 이중화 전략은 크게 2가지로 나눌 수 있습니다. Active Standby, Active Active가 바로 그 둘입니다.
보통 DB 서버를 이중화할 때 쉽게 접할 수 있는 개념이지만, 웹 서버도 전부 설정 가능하고, 접속자가 많은 서비스는 실제로 그렇게 이중화 구성을 해두고 이용하는 경우가 많다고 합니다.
DB, WAS나 다른 S/W도 이중화로 구성할 수 있는 상용 솔루션도 많아서 솔루션을 통해 이중화 구성을 하는 경우도 많다고 합니다
Active Standby
먼저 Active Standby란, 다음 그림에서 볼 수 있듯이 평소엔 특정 서버에서 서비스를 운영하고, 해당 서버가 장애 발생 시 대기 중이던 서버를 사용하여 대응하는 전략입니다. active 서버는 데이터의 업데이트가 있을 때마다 standby서버로 전달하여 데이터를 동기화하고 장애 발생 시 그 즉시 투입 가능한 상태를 유지합니다.
Active Active
다음으로 Active Active는 서로 다른 서버가 모두 서비스를 운영하는데 어느 하나에 장애가 발생하면 나머지가 서비스를 제공하게 되는 구조입니다. Active Standby보다 높은 처리량과 고가용성을 제공하고, 비용이 더 많이 들어갑니다.
의문점
여기서 만약 100명의 사용자가 이용하는 서비스를 a-s로 구성한다면 각각의 서버가 100명을 감당할 수 있는 스펙으로 구성해야하는 반면에 a-a 로 구성한다고하면 모든 서버가 동시에 운영되기 때문에 서버 하나당 50명만 부담해도 되는거 아니야? a-s 보다 왜 더 비용이 많이 들어가지? 하고 생각할 수 있는데
장애 발생 시 한쪽이 100명을 모두 감당해야하기 때문에 결국 100명을 부담할 수 있는 스펙으로 두 대를 구성해야합니다.
어? 그럼 결국 a-s와 같은 스펙의 서버 2대가 아닌가?하고 생각할 수 있지만,
standby 서버는 a-a 구성에서와 달리 down 상태이기 때문에 비용이 덜 드는 것입니다.
완전한 다중화
이런 다중화는 모든 레이어에 잘 갖춰져 있어야 완전한 고가용성을 제공할 수 있게 됩니다.
이 부분은 최근 if kakao 개발자 컨퍼런스에서 공개한 발표에서 많은 정보를 참고했습니다.
인프라
우선 인프라 영역은 상면, 전력, 네트워크 등 물리적인 공간으로 인터넷 서비스를 위한 근간이 되는 영역입니다. 예상치 못한 크고 작은 사고가 많이 발생합니다. 실제로 데이터 센터에 복무할 때 포트 하나가 살짝 빠지는 탓에 서비스에 문제가 생긴 적도 있습니다. 그렇기 때문에 다양한 failover 설계를 잘 해두어야 하는 영역입니다. failover라는 건 문제가 생겼을 때 예비 시스템으로 자동 전환되는 기능을 말합니다.
데이터
다음으로 데이터 레이어입니다. 데이터를 다루는 영역으로, 서비스의 신뢰에 근간이 되는 영역입니다. 웬만한 기업들은 실시간 이, 삼중화를 통해 데이터를 백업하고 데이터 무결성과 정합성이 유지되고 또 유실이 일어나지 않도록 가장 신경쓰고 있다고 합니다.
데이터 무결성 : 데이터 값이 정확한 상태
데이터 정합성 : 어떤 데이터들이 값이 서로 일치함.
운영 및 관리 도구
운영 및 관리 도구는 실제 서비스 트래픽을 받는 부분은 아니지만 서비스 운영에 필요한 여러가지 기술적 도구들을 말합니다. 배포에 관한 도구, 모니터링 관련 도구, 이런 툴들을 사용하기 위한 권한 관리 도구, 소스 코드를 관리하는 도구 등입니다. 이런 부분은 자칫 중요치 않다고 생각될 수 있지만 장애 발생 시 복구 작업을 하는 과정에서 전체적인 서비스 복구 시간을 지연시키는 요인이 될 수 있으므로 운영 및 관리 도구들 또한 언제 어디서든 사용 가능하도록 다중화를 해두어야 합니다.
이상적으론 다중화 구성만으로 장애 시 대응이 되어야 하지만 현실은 그렇지 않고, 예상치 못한 여러 상황이 벌어지기 때문에 배포 도구와 같은 운영관리 도구가 중요한 역할을 하는 이유입니다.
서비스 플랫폼
서비스 플랫폼은 서비스가 공통적으로 사용하는 플랫폼을 분류한 영역입니다. 보안키 저장소, 미디어 저장소, 레디스, 카프카 등 공용 솔루션을 말합니다.
어플리케이션
어플리케이션 레이어는 실제 사용자에게 서비스하기 위한 구성과 소프트웨어 영역입니다. 여러 시스템에 복잡한 의존성을 띄는 부분인 만큼 여러 부분에서 병목이 발생할 수 있고, 작은 장애가 전체로 번질 수 있기 때문에 전략적으로 다중화를 진행해야 합니다.
서비스가 이중화되지 못한 경우
그러나 항상 100% 이중화를 구성하는 것은 쉽지 않은 일인데,
대표적인 경우를 한번 나열해봤습니다.
- 서비스 구성 후 장시간 장애가 발생하지 않은 경우
- 이중화를 진행 중이었던 경우
- 서비스가 파편화되어 체계적으로 완벽하게 이중화 구성이 어려웠던 경우
- 현실적으로 한정된 자원 탓에 이중화를 구성할 수 없었던 경우
먼저 서비스를 구성한 후 장시간 장애가 발생하지 않아서 필요성을 느끼지 못했던 경우,
이중화를 구성하는게 쉬운 일이 아니기 때문에 시간이 꽤 소요되는 경우가 있는데, 이렇게 작업하는 도중에 장애가 발생하는 경우.
그리고 서비스가 파편화되어서 체계적으로 이중화 구성이 어려워서 놓친 부분이 있는 경우,
현실적으로 이중화할 자원을 확보하지 못해 이중화를 해두지 못한 경우가 있다고 합니다.
재해 복구 전략이 필요한 이유
백업 및 이중화 요소를 갖췄다면 자연스레 장애 발생 시 대처가 되는거 아닌가?
고가용성 서비스를 제공할 수 있도록 준비하고도 DR 전략이라는 것을 또 수립하는 이유는 뭐지? 뭐가 다른거지? 하고 헷갈릴 수 있습니다.
재해 복구 전략이라는 건 훨씬 큰 개념인데, 만약 HA를 구성한 데이터 센터에 화재와 같은 큰 재해가 발생하게 된다면, 그 데이터 센터 내에 아무리 백업 서버를 두고 이중화를 잘 해놨다고 해도 아무 소용이 없어지므로
- DR 센터를 구축하거나,
- 소산 백업을 하는 전략
정도로 보통 재해에 대비한다고 합니다.
DR 센터란, 서로 전혀 다른 지역에 재해 시 복구할 수 있도록 동일한 센터를 하나 더 만드는 것을 의미합니다. 그리고 소산 백업이란 데이터만 백업하되, 그 백업 데이터가 같은 데이터 센터에 위치해 있으면 재해 시 유실되는 건 결국 똑같으니까 물리적으로 다른 곳에 백업데이터를 두는 백업 방식입니다.
물론 이런 재해 복구 전략을 미리 준비하기엔
현실적으로 한정된 자원의 문제를 피할 수 없습니다.
그래서 장애 스케일에 따라 복구 전략을 적절하게 선택하는 것이 중요합니다.
- 서버가 장애났을 경우를 대비해서 HA 이중화 구성
- HA 구성한 서버가 모두 장애났을 경우를 대비해서 데이터 백업
- 백업데이터까지 날라갈 경우를 대비해서 소산백업
- 재해 발생 시 빠르게 복구해야하는 경우 실시간으로 바로 서비스 재개가 가능한 DR 센터 구축
이렇게 단계별로 적절하게 복구 전략을 수립해야하는데, 물론 쉽지 않을 것 같습니다.
if kakao 세션 페이지에서 더 많은 정보를 얻으실 수 있습니다.
'Dev' 카테고리의 다른 글
| [JS] Call by reference가 없는 Javascript (2) | 2023.04.23 |
|---|---|
| where 대신 join을 사용하는 경우 (0) | 2023.04.15 |
| Docker timezone 설정하기 (0) | 2022.10.19 |
| github action을 통한 ci cd 자동화(feat. shell script) (0) | 2022.10.17 |
| Intellij 단축키 정복하기 (0) | 2022.05.22 |