1. 개요
1.1 들어가기에 앞서 도란도란
개인적으로 사용할 스토리지 서비스를 만들고 있습니다. 사실 외부 스토리지 서비스를 구독해서 쓴다면 훨씬 저렴하게 쓸 수 있지만... 거기에 돈쓰기는 싫고 ㅜ, 지인들이나 가족에게 무료로 서비스를 풀어보고 싶어서 직접 스토리지 서비스를 만들고 있습니다.
다만, 언제나 문제가 되는 지점은 비용입니다. 그래서 비용을 최소한으로 설계하려고 했습니다.
1.2 중요한 건, 데이터가 소실되지 않는 것
스토리지 서비스를 구축할 때, 가장 중요하게 생각했던 부분은 데이터의 내구성을 보장하는 것이었습니다. 다시말해서 데이터가 갑자기 없어져버리는 불상사를 막는 것입니다! 사용자가 저장한 데이터가 DISK 고장 등의 이유로 없어진다면, 다시는 서비스를 사용하지 않을 것 같습니다. (상상만해도 끔찍하네요.) 이러한 이유로 내구성을 위해 분산 스토리지를 도입하기로 하였고, 설계의 과정을 글로 정리하였습니다.
이 글에서는 디스크 개수와 Node 개수를 어떻게 결정했는지, 그리고 비용적인 부분과 안정성 사이에서 어떤 판단을 내렸는 지를 작성하였습니다
2. 내구성 보장 : DISK 개수 선택
현재 Azure를 사용하여 서비스를 구축하고 있습니다. Azure를 선택한 가장 큰 이유는 비용이었고, Azure에 무료 크레딧이 남아있어 Azure를 선택하였습니다.
그래서 Azure의 자료를 바탕으로 DISK 고장 상황을 예상하여 개수를 선택하는 과정을 작성하였습니다.
2.1 단일 DISK 고장으로 인한 데이터 유실
하나의 DISK에 데이터를 저장하면, DISK가 고장났을 때, 데이터를 복구할 수 없습니다. 그래서 DISK의 고장 확률이 중요합니다. Azure에는 Managed DISK를 제공하는데, 해당 DISK는 99.999…% (11 nines) 내구성을 보장합니다. (3개의 복제본을 운용한다고 합니다.) 사실 저렴한걸 쓰고 싶어서 복제본이 없는 DISK를 사용하고 싶었는데, 그런건 제공하지 않는다고 합니다. (어차피 복제본 없는걸 써도 안정성을 위해 3개는 쓸 생각이었어서 별 차이는 없었겠지만요 ^^;)
Azure Managed DISK의 내구성
https://learn.microsoft.com/ko-kr/azure/virtual-machines/managed-disks-overview
따라서 Managed DISK를 1개만 사용하더라도, 데이터의 내구성을 충분히 보장 할 수 있다고 생각하였습니다.
그러면 'DISK 1개만 쓰면 되느냐?' 그건 아니었고, 아래 상황도 고려했습니다.
2.2 재해 복구로 인한 데이터 유실
하지만 DISK 고장이 아닌, 정전, 화재로 인한 DISK 데이터 손실은 Manged DISK 만으로 내구성을 보장할 수 없습니다. 실제 1년간 재해 확률은 약 0.1% ~ 1%라고 합니다. (사실 재해확률은 예측할 수가 없습니다) 화재로 인한 데이터 손실이나, 정전으로 인해 서비스가 내려가면 큰일이기에 DISK를 1개 더 두어, 안전하게 99.99% ~ 99.9999% 를 갖는 내구성 서비스를 구축하기로 하였습니다.
여타 다른 서비스처럼 3개를 둔다면 좋겠지만, 클라우드 서비스 대여 비용 문제와 AZ가 재해로 인해 데이터가 모두 소실되는 경우는 극히 드물다고 판단하여 2개로 설계를 진행하였습니다.
3. 아키텍처 구조 설계
3.1. 구조 설계
3.1.1 초기 설계
처음에는 1개의 인스턴스 위에 Node server를 띄우고, 각 DISK에 연결하는 방식으로 구상 하였습니다. (상황에 따라, 서버를 1개를 띄울 수도 있고 여러개를 띄울 수도 있을 것 같습니다)
위와 같은 구조를 구상한 가장 큰 이유는 인스턴스 대여 비용 때문입니다. 이를 줄이기 위해 1개의 컴퓨터에서 여러 서버를 사용하여 해결하려고 하였습니다. 하지만 이 방식은 몇가지 문제가 있었습니다.
- DISK는 인스턴스와 동일한 AZ에 두어야한다는 제약
- 인스턴스가 예상치 못한 상황으로 종료되는 경우에 서비스 전체가 마비되는 문제
3.1.2 수정안
따라서 아래와 같이 인스턴스 서버를 1개 더 추가하여 설계하였습니다.
하지만 이렇게 2개를 쓸 경우, 인스턴스 비용이 많이 발생합니다.
3.2 비용 문제 해결 방안
그래서 최대한 낮은 가격의 인스턴스를 사용하려고 합니다. 이러한 인스턴스에서 돌리기 위해, Java Spring 처럼 무거운 서버가 아닌, FAST API나 Fastify 처럼 가벼운 프레임워크를 사용하는 방향으로 진행하려고 합니다.
4. 결론
이런저런 이야기를 길게 적었지만, 핵심은 데이터 내구성입니다. 몇 년 전에 카카오에서 불이 난것도 그렇고, 데이터센터에 화재가 난 것도 그렇고 재해 발생을 고려할 수밖에 없었습니다.
그래서 2개의 DISK를 사용하여 다음 내구성을 보장하도록 설계하였습니다.
- DISK 데이터 내구성 : 99.999… % (22nines)
- 재해 발생 내구성 : 99.99% (4nines)
Azure Managed DISK가 기본적으로 높은 내구성을 제공하지만, 디스크 고장 외에도 인스턴스 장애나 AZ 단위 문제까지 고려해서 판단하였고, 이에 따라 인스턴스 2개와 DISK 2개 구조로 설계하였습니다. 현재의 비용 제약 안에서 안정성을 최대한 확보하려고 하였습니다.
여담
VM이 약 $30/월 이고, SSD DISK가 $6/월 이어서, 월에 36 * 2 = $72 정도 들어갈 듯 합니다. 생각보다 너무 비싸서, 라즈베리 파이를 사용하는 것도 고려해보아야겠습니다. (사실 이미 있지만, 네트워크 대역폭도 문제고 VPC도 안되서 고민입니다.)
