[1편] AWS로 나만의 고가용성 보안 NAS 구축기 (feat. 아키텍처 설계)

안녕하세요! AWS 클라우드 환경을 활용하여 저만의 개인 NAS(Network Attached Storage)를 구축을 해보자 합니다.

단순히 '파일 서버를 만들어보자!'에서 그치는 것이 아니라, 실제 서비스 환경에서 가장 중요하게 여기는 보안(Security)과 고가용성(High Availability)이라는 두 가지 핵심 가치를 어떻게 녹여낼 수 있을지 깊이 고민하며 프로젝트를 진행했습니다.

저처럼 안정적인 클라우드 인프라를 직접 설계하고 구현해보고 싶은 분들께 작게나마 도움이 되었으면 좋겠습니다.

 최종 목표: 우리가 완성할 아키텍처

가장 먼저, 이 시리즈를 통해 우리가 완성하게 될 시스템의 최종 설계도를 공개합니다.

 왜 이렇게 설계했을까? 핵심 설계 원칙 3가지

효과적인 시스템을 구축하기 위해서는 명확한 설계 원칙이 필요합니다. 저는 이번 프로젝트에서 다음 세 가지 원칙을 가장 중요하게 생각했습니다.

1. 서비스는 멈추면 안 된다: 고가용성

"만약 내가 사용하던 서버가 갑자기 다운되어 파일에 접근할 수 없으면 어떻게 하지?" 라는 생각에서 출발했습니다. IDC 센터 한 곳에 물리적인 장애가 발생하더라도 서비스는 계속되어야 합니다.

• Multi-AZ:Multi-AZ: AWS의 가용 영역(Availability Zone)은 하나 이상의 독립된 데이터 센터로 구성된, 물리적으로 분리된 위치를 의미합니다. 저는 이 개념을 활용하여, 서울 리전의 서로 다른 두 가용 영역(ap-northeast-2a, ap-northeast-2c)에 시스템을 이중으로 구축했습니다. 이를 통해 하나의 데이터 센터 그룹 전체에 문제가 발생하더라도, 다른 쪽에서 서비스를 중단 없이 이어갈 수 있도록 설계했습니다.
• Auto Scaling Group & ALB: 서버(EC2)에 문제가 생겼을 때, 시스템이 스스로를 자동으로 복구하고(Auto Scaling) 중단 없이(ALB의 Health Check) 서비스를 이어갈 수 있도록 자동화 구조를 채택했습니다.

2. 데이터는 소중하다: 다계층 보안

"개인적인 파일들이 저장될텐데 외부에서 함부로 접근하면 어떻게 하지?" 라는 생각이 났습니다. 그래서 네트워크를 여러 계층으로 나누어 데이터를 안전하게 보호하는 구조를 설계했습니다.

• 네트워크 망 분리: 외부와 소통하는 Public Subnet과 중요한 자산을 숨겨두는 Private Subnet으로 네트워크를 분리했습니다.
• 역할 분담: Public Subnet에는 외부와 소통하는 '문지기'(ALB, Bastion Host) 역할만 배치하고, 실제 NAS 서버와 스토리지는 Private Subnet 깊숙한 곳에 두어 외부로부터의 직접적인 공격을 원천적으로 차단했습니다.

3. 미래는 대비해야 한다: 확장성

"지금은 개인적으로 혼자 쓰지만 서비스를 공유하게 되면 어떻게 할까?" 라는 생각으로 미래의 확장 가능성을 고려했습니다.

• EFS (공유 스토리지): 각 서버에 개별적으로 스토리지를 두는 대신, 모든 서버가 함께 사용하는 중앙 공유 스토리지(EFS)를 도입했습니다. 이를 통해 어떤 서버로 접속하든 동일한 데이터를 볼 수 있으며, 나중에 서버가 여러 대로 늘어나도 데이터 일관성을 유지할 수 있습니다.