4주차 과제 #5
Description
클라우드 인프라 구조와 서버 운영 방식(선택 과제)
우리가 사용 중인 클라우드 환경에서 인스턴스를 띄우고 서비스를 운영함에 있어서 실제로 그 내부 구조가 어떻게 생겼는지, 인스턴스 수가 늘어나면 어떻게 바뀌는지 등에 대한 정리가 꼭 필요합니다.
또한 서버 성능을 높이는 방법이나 CORS 같은 개념도 함께 알아둘 필요가 있습니다.
1. 인스턴스를 하나 띄웠을 때 구조는 어떻게 될까?
클라우드에서 인스턴스를 띄운다는 건, 우리가 웹 서비스를 올릴 수 있는 "가상의 컴퓨터"를 만드는 것과 같습니다.
이 인스턴스는 다음과 같은 구조 안에 포함되어 있습니다:
- VPC: Virtual Private Cloud의 약자로, 우리가 인스턴스를 띄우는 데 사용하는 "가상의 네트워크 공간"입니다. 다른 사람들과 완전히 분리된, 우리만의 독립된 네트워크라고 생각하면 됩니다.
- 서브넷(Subnet): VPC 안에서도 네트워크를 더 작게 나눈 구역입니다. 주로 퍼블릭(public)과 프라이빗(private)으로 구분되며, 어디에 위치하느냐에 따라 외부에서 접근이 가능한지 여부가 달라집니다.
- 보안 그룹(Security Group): 일종의 방화벽 역할을 하며, 어떤 요청을 받을 수 있고 어떤 포트가 열려 있는지 등을 설정합니다.
- 인터넷 게이트웨이 / NAT 게이트웨이: 이 인스턴스가 외부 인터넷과 연결될 수 있도록 돕는 통로입니다.
정리하자면, 인스턴스를 하나 띄우면 내부 네트워크(VPC → Subnet) 안에 들어가고, 보안 설정(Security Group)을 갖게 되며, 퍼블릭 서브넷이라면 인터넷 게이트웨이를 통해 외부에서 접근할 수 있습니다.
2. 인스턴스를 여러 개 띄우면 어떻게 될까?
만약 웹 서비스를 운영하는 인스턴스를 여러 개 띄운다면, 그때는 "여러 컴퓨터에 나눠서 일하게 하는 구조"가 됩니다.
이때 중요한 개념이 로드 밸런서(Load Balancer) 입니다. 로드 밸런서는 외부에서 들어오는 요청을 적절히 나눠서 여러 서버로 분산시켜주는 장치입니다.
예를 들어 사용자가 웹사이트에 접속하면 로드 밸런서가 요청을 받아서 준비된 여러 서버 중 하나에 전달해줍니다.
또한 서버 수를 자동으로 늘리고 줄이는 오토 스케일링(Auto Scaling) 도 함께 사용하는 경우가 많습니다. 사용량이 많을 땐 서버를 더 띄우고, 적을 땐 줄이는 방식입니다.
3. 퍼블릭 서브넷이 아닌 프라이빗 서브넷만 쓰면?
프라이빗 서브넷(private subnet) 에 있는 인스턴스는 인터넷에서 직접 접근할 수 없습니다. 보안이 더 강화된 공간이라고 생각하시면 됩니다.
이런 인스턴스들은 외부에서 직접 연결할 수 없기 때문에 다음과 같은 방법으로 접근합니다:
- 배스천 호스트(Bastion Host): 퍼블릭 서브넷에 있는 인스턴스를 하나 만들어서, 여기에 먼저 접속한 다음 프라이빗 인스턴스로 접속하는 방식입니다. 일종의 ‘중간 관문’ 역할을 합니다.
- NAT 게이트웨이: 프라이빗 인스턴스가 인터넷으로 나갈 수는 있게 해주는 통로입니다. 다만 외부에서 이 인스턴스로 들어오진 못합니다.
이런 구조는 주로 DB나 내부 전용 API 서버처럼 보안이 중요한 서버를 운영할 때 사용됩니다.
4. 데이터베이스(DB)를 추가하면 구조가 어떻게 달라질까?
웹 서비스에서는 사용자 정보를 저장하거나 게시글 목록을 불러오기 위해 DB가 꼭 필요합니다. 이 DB는 보통 RDS 같은 관리형 데이터베이스 서비스를 사용하거나, 직접 설치해서 운영하기도 합니다.
DB는 보안이 매우 중요하므로 대부분 프라이빗 서브넷에 위치시킵니다.
구성 예시는 다음과 같습니다:
- 웹 서버는 퍼블릭 서브넷에 있고, 외부에서 들어오는 요청을 받습니다.
- 웹 서버는 내부에 있는 애플리케이션 서버와 통신합니다.
- 애플리케이션 서버는 DB와 연결되어 데이터 처리를 합니다.
DB 서버는 외부에서 직접 접근할 수 없고, 반드시 내부 서버를 거쳐야만 접근 가능하도록 구성합니다.
5. 서버가 여러 개일 경우 달라지는 점은?
서버를 여러 대 운영하면 다음과 같은 점을 고려해야 합니다:
- 트래픽 분산: 로드 밸런서를 통해 요청을 여러 서버에 나눠서 처리합니다.
- 세션 관리: 로그인 상태 같은 정보가 서버마다 나뉘면 문제가 생길 수 있으므로, 세션 정보를 Redis 같은 외부 저장소에 따로 저장해서 공유하는 방식이 필요합니다.
- 배포 전략: 서버가 여러 대일 경우 서비스를 중단하지 않고 코드를 배포하는 기술(예: 블루그린 배포, 카나리 배포 등)을 고민해야 합니다.
- 모니터링 및 로그 수집: 어떤 서버에서 문제가 생겼는지 확인하기 위해 로그를 중앙에서 모아보는 시스템이 필요해집니다.
이런 요소들이 복잡하지만, 동시에 안정성과 확장성을 높여주는 핵심입니다.
6. 서버의 성능을 높이고 싶다면 어떤 방법이 있을까?
서버의 성능을 올리는 방법에는 두 가지가 있습니다:
-
스케일 업 (Scale-Up)
→ 지금 사용 중인 서버를 더 좋은 사양(CPU, 메모리 등)으로 바꾸는 방법입니다.
예: t3.micro → m5.large로 변경 -
스케일 아웃 (Scale-Out)
→ 똑같은 역할을 하는 서버를 여러 대 더 띄우는 방식입니다.
예: EC2 인스턴스를 1대에서 3대로 늘리고, 로드 밸런서로 분산 처리
대부분의 경우 트래픽이 많아지면 스케일 아웃을 먼저 고려합니다. 스케일 업은 단순하지만 서버 교체 시 중단이 발생할 수 있기 때문입니다.
7. CORS란 무엇이며 왜 알아야 할까?
CORS(Cross-Origin Resource Sharing)는 서로 다른 도메인 간의 자원 공유를 허용하기 위한 브라우저 보안 정책입니다.
브라우저는 기본적으로 다른 출처의 요청을 제한하는 Same-Origin Policy를 따릅니다.
예를 들어 frontend.example.com에서 api.example.com으로 요청을 보낼 경우, 서로 다른 origin이므로 CORS 설정이 없으면 브라우저가 차단합니다.
특별한 설정이 없다면 API 호출이 막혀서 프론트에서 아무리 잘 구현해도 작동하지 않습니다.
따라서 프론트와 백엔드가 분리되어 있는 경우 CORS 설정은 반드시 신경 써야 하는 부분입니다.