인프라 설계 설명-(12)(우리 지금 만나)

 

 

클라이언트 상호작용 레이어

 

1. 사용자/클라이언트:

최종 사용자가 브라우저를 통해 시스템에 접근합니다.

 

2. 브라우저 통신:

사용자 요청과 응답이 브라우저를 통해 전달되어 백엔드 인프라와 상호작용합니다.

 

AWS 인프라

 

퍼블릭 서브넷:

 

1. 인터넷 게이트웨이:

퍼블릭-facing 자원과 인터넷 간의 통신을 제공합니다.

 

2. 애플리케이션 로드 밸런서(ALB):

들어오는 트래픽을 적절한 백엔드 서비스로 분산시켜 확장성과 장애 허용성을 보장합니다.

 

3. 배스천 호스트:

개인 서브넷 자원에 SSH로 안전하게 접근할 수 있도록 지원합니다.

 

프라이빗 서브넷-1 (서비스 계층):

 

1. 모니터링 및 시각화 스택:

Kibana, Logstash, Grafana, prometeus

로그 집계, 성능 모니터링, 실시간 시각화를 제공하여 시스템 운영 상태를 파악하고 디버깅을 지원합니다.

 

2. 매칭 서비스:

RabbitMQ와 Spring 애플리케이션:

1:1 매칭이나 이벤트 기반 트리거를 처리하는 비동기 메시징 관리.

 

3. 메인 서비스:

Spring Boot 애플리케이션 (WebSocket 및 STOMP 포함):

채팅이나 알림과 같은 실시간 통신을 포함한 핵심 애플리케이션 로직을 처리합니다.

 

프라이빗 서브넷-2 (데이터 계층):

 

1. Redis:

자주 접근하는 데이터를 캐싱하여 지연 시간을 줄이고 성능을 향상시킵니다.

Gathering 조회수 저장, Gathering 조회수 랭킹 저장, Gathering 다건 목록, Event 다건 목록, Websocket 유저 세션 저장, 주변 추천 장소 저장 

 

2. MongoDB:

비정형 데이터를 저장하는 NoSQL 데이터베이스.

채팅 메세지, 알람 내역 저장

 

3. Amazon RDS (MySQL):

사용자 정보, 트랜잭션 등 구조화된 데이터를 저장하는 관계형 데이터베이스.

매칭, 유저, 결제, 로컬, 댓글, 멤버, 소모임, 이벤트, 채팅방, 광고, 첨부파일 정보를 저장한다.

 

CI/CD 파이프라인:

 

1. GitHub 및 GitHub Actions:

소스 코드를 관리하고 빌드 및 배포 프로세스를 자동화합니다.

-> 매칭 서버, 메인 서버 각각 파이프라인 구축완료

 

2. Amazon ECR (Elastic Container Registry):

Docker 이미지(컨테이너)를 저장하여 EC2 인스턴스나 컨테이너로 배포합니다.

-> GitActions에서 이미지화 된 후 ECR로 푸쉬하여 저장함.

 

3. Amazon S3:

애플리케이션 파일, 백업, 또는 사용자 업로드 파일 등을 위한 확장 가능한 스토리지. 

-> Gathering 프로필 이미지, User 프로필 이미지 파일 스토리지로 사용.

 

워크플로우 개요:

 

1. 사용자 요청:

사용자가 브라우저를 통해 요청을 보내면, ALB가 이를 적절한 서비스로 라우팅합니다.

 

2. 메인 서비스 (EC2 인스턴스):

요청을 처리하고 RabbitMQ를 통해 메시징을 수행하며, MongoDB, MySQL, Redis와 상호작용합니다.

t4g.large 사용

 

3. 매칭 서비스 (EC2 인스턴스):

매칭 관련 기능을 처리하며, RabbitMQ를 통해 메시지 처리를 지원합니다.

t4g.medium 사용

 

4. 데이터 흐름:

영구 데이터는 RDS 또는 MongoDB에 저장되며, 자주 사용하는 데이터는 Redis를 통해 캐싱됩니다.

 

5. 로그 및 모니터링:

시스템 로그는 Kibana, Logstash, Grafana를 통해 수집 및 시각화됩니다.

 

보안 특징:

 

1. 퍼블릭과 프라이빗 서브넷 분리:

민감한 자원을 프라이빗 서브넷에 격리하여 보안을 강화합니다.

 

2. 배스천 호스트:

SSH를 통해 프라이빗 서브넷 자원에 안전하게 접근할 수 있습니다.

 

3. ALB 통합:

HTTPS 종료 및 요청 라우팅을 처리하여 보안을 추가로 강화합니다.

 

주요 특징:

 

1. 확장성:

ALB, RabbitMQ, Redis를 통해 높은 트래픽과 비동기 작업을 효과적으로 처리할 수 있습니다.

 

2. 실시간 기능:

WebSocket 및 STOMP 통합은 채팅, 알림 등 실시간 통신 기능에 중점을 둡니다.

 

3. 모니터링 및 디버깅:

강력한 모니터링 도구를 통해 시스템 가시성과 문제 해결 능력을 제공합니다.

 

4. 데이터 관리:

MySQL, MongoDB, Redis의 조합을 통해 구조화된 데이터, 반구조화 데이터, 캐싱 데이터를 유연하게 처리할 수 있습니다.

 

Private Subnet하고 Public Subnet를 분리 해놓은 이유가 있나요?

Private Subnet과 Public Subnet을 분리하는 이유는 보안, 성능, 그리고 효율적인 리소스 관리를 위해서입니다. 이를 통해 네트워크를 구조화하고 민감한 데이터와 애플리케이션을 안전하게 보호할 수 있습니다. 주요 이유를 정리하면 다음과 같습니다:

 

1. 보안 강화

 

• Public Subnet은 인터넷과 연결되어 외부에서 접근 가능한 리소스(예: 로드 밸런서, 웹 서버 등)가 배치됩니다.
• Private Subnet은 외부에서 직접 접근할 수 없는 리소스(예: 데이터베이스, 내부 애플리케이션 서버 등)가 배치됩니다.
• 이렇게 분리하면 민감한 데이터와 애플리케이션을 인터넷으로부터 격리할 수 있어 보안 위협을 최소화할 수 있습니다.

 

2. 외부 공격 위험 감소

 

• Public Subnet은 인터넷에 노출되므로 공격에 노출될 가능성이 높습니다.
• 반면, Private Subnet은 인터넷과 직접 연결되지 않아 외부에서 접근이 불가능합니다.
• 따라서 중요한 리소스(예: 데이터베이스, 캐싱 서버 등)를 Private Subnet에 배치하여 공격 표면을 줄일 수 있습니다.

 

3. 역할 기반 리소스 관리

 

• 각 Subnet에 특정 역할을 담당하는 리소스를 배치하여 네트워크를 더 명확하고 효율적으로 관리할 수 있습니다.
• Public Subnet: 클라이언트와 통신이 필요한 리소스(예: 로드 밸런서, 배스천 호스트 등).
• Private Subnet: 외부와 통신이 필요하지 않은 내부 리소스(예: 데이터베이스 서버, 캐시 서버 등).

 

4. 비용 절감

 

• Private Subnet의 리소스는 인터넷 연결이 필요하지 않으므로, NAT 게이트웨이 또는 퍼블릭 IP 비용을 절약할 수 있습니다.
• 예를 들어, 데이터베이스나 내부 애플리케이션 서버는 외부 인터넷에 연결될 필요가 없으므로, 인터넷 사용 비용이 발생하지 않습니다.

 

5. 아키텍처의 확장성과 유연성

 

• Subnet을 분리하면 네트워크 아키텍처를 더 쉽게 확장할 수 있습니다.
• Public Subnet에는 로드 밸런서나 프록시 서버를 추가하여 트래픽을 처리할 수 있습니다.
• Private Subnet에는 데이터베이스, 내부 API 서버 등 비즈니스 로직을 추가적으로 배치할 수 있습니다.

6. 네트워크 접근 제어

 

• Public Subnet: 인터넷 접근이 필요하므로 방화벽과 보안 그룹 규칙을 세분화하여 허용할 IP와 포트를 제한합니다.
• Private Subnet: 인터넷 접근이 불필요하므로 외부 접근은 차단되고, 내부적으로만 통신하도록 설정합니다.
• 외부에서 Private Subnet에 접근하려면, Public Subnet에 있는 배스천 호스트를 통해 접근해야 하므로 추가적인 보안 계층이 생깁니다.

 

7. 규제 준수 및 데이터 보호

 

• 금융, 의료, 또는 기타 민감한 데이터를 다루는 시스템에서는 데이터가 외부와 연결되지 않는지 보장해야 할 때가 많습니다.
• Private Subnet에 민감한 데이터를 저장하고 외부 접근을 차단함으로써 규제 요건을 충족할 수 있습니다.

 

Private Subnet과 Public Subnet의 활용 예시

 

Public Subnet:

• 애플리케이션 로드 밸런서(ALB)
• 배스천 호스트
• 인터넷과 통신이 필요한 웹 서버

 

Private Subnet:

• 데이터베이스 서버(MySQL, MongoDB 등)
• 캐시 서버(Redis)
• 내부 애플리케이션 서버(Spring Boot 등)

 

8. 트래픽 흐름의 효율적 관리

 

외부 요청은 Public Subnet의 로드 밸런서로 들어오고, 이 요청은 Private Subnet에 있는 내부 애플리케이션 서버로 전달됩니다.

내부 서버는 Private Subnet 내에서 데이터베이스와 통신하며, 민감한 데이터가 외부로 노출되지 않도록 보호됩니다.

 

결론

 

Private Subnet과 Public Subnet을 분리함으로써 보안, 효율성, 비용, 확장성을 모두 강화할 수 있습니다. 특히 민감한 데이터나 내부 비즈니스 로직이 포함된 애플리케이션의 경우, Subnet 분리는 필수적인 아키텍처 설계 방식입니다.

 

추가로, NAT 게이트웨이와 같은 요소를 활용해 Private Subnet의 리소스가 외부로 나가는 트래픽을 허용하면서도 외부로부터 접근은 차단하는 방식도 구현할 수 있습니다.

 

 

Bastion Host를 사용하는 이유가 있나요?

Bastion(배스천) 호스트를 사용하는 이유는 보안을 강화하고 AWS 내 프라이빗 서브넷의 리소스에 안전하게 접근하기 위해서입니다. 구체적으로 아래와 같은 이유가 있습니다:

 

1. 프라이빗 서브넷의 보안 강화

 

• 프라이빗 서브넷에 있는 리소스(예: 데이터베이스 서버, 내부 애플리케이션 서버)는 직접 인터넷에서 접근이 불가능하도록 설정되어 있습니다.
• 이를 통해 외부 공격자가 프라이빗 리소스에 접근하는 것을 방지할 수 있습니다.
• 하지만 개발자나 운영자가 프라이빗 서브넷에 접근해야 할 때, 이를 위한 안전한 경로가 필요합니다. 이 역할을 배스천 호스트가 수행합니다.

2. SSH 접근 통제

 

• 배스천 호스트는 인터넷과 연결된 퍼블릭 서브넷에 위치하며, 관리자만 SSH를 통해 접근할 수 있도록 제한됩니다.
• 개발자나 운영자가 배스천 호스트에 SSH로 접속한 후, 프라이빗 서브넷의 리소스에 SSH를 통해 접근할 수 있습니다.
• 이렇게 하면 한정된 한 개의 진입점을 통해 접근을 통제할 수 있으므로 보안 관리가 용이합니다.

3. 접근 로깅 및 모니터링

 

• 배스천 호스트를 통해 모든 SSH 접근이 이루어지므로, 접근 로그를 남기고 이를 모니터링할 수 있습니다.
• 이를 통해 누가, 언제, 어떤 리소스에 접근했는지 확인할 수 있어 보안 감사 및 문제 해결이 용이합니다.

 

4. 네트워크 설정 최소화

 

• 배스천 호스트 없이도 각각의 프라이빗 서브넷 리소스에 접근할 수 있도록 설정할 수 있지만, 이는 보안 그룹과 방화벽 규칙을 복잡하게 만들고, 관리 부담을 증가시킬 수 있습니다.
• 배스천 호스트를 사용하면 하나의 진입점만 허용하도록 설정하면 되기 때문에, 네트워크 설정을 간소화할 수 있습니다.

 

5. VPN 대안

 

• VPN을 구성하지 않은 경우, 배스천 호스트는 간단한 대안이 될 수 있습니다.
• VPN처럼 내부 네트워크로 완전히 연결하지 않아도, 배스천 호스트를 통해 특정 리소스에만 접근할 수 있기 때문입니다.

 

배스천 호스트가 필요한 주요 시나리오

 

• 개발 환경 접근: AWS에서 운영 중인 데이터베이스, 로그 서버 등 프라이빗 리소스에 개발자가 접근해야 할 때.

• 운영 환경 디버깅: 배포된 애플리케이션의 문제를 조사하거나 긴급하게 리소스를 점검해야 할 때.

• 보안 요구 사항 충족: 외부 접근을 최소화하고, 접근 기록을 관리해야 할 때.

 

배스천 호스트 사용 시 주의사항

 

1. IP 접근 제한:

SSH 접근은 반드시 특정 IP(운영자/관리자 IP)만 허용해야 합니다.

-> 22 포트 그리고 IAM 접근 권한을 운영자 관리자만 가능하게 제한.

 

2. 키 기반 인증:

SSH 접근은 암호가 아닌 SSH 키 기반 인증을 사용해야 안전합니다. (aws .pem)

 

3. IAM Role 및 보안 그룹 설정:

배스천 호스트는 IAM Role을 통해 최소한의 권한만 갖도록 설정하고, 프라이빗 서브넷 리소스에 필요한 보안 그룹 규칙을 구성해야 합니다.

 

4. 접근 로그 저장:

배스천 호스트에 대한 모든 SSH 접근 기록을 CloudWatch Logs 또는 S3에 저장하여 모니터링합니다.

 

배스천 호스트는 AWS 환경에서 프라이빗 리소스 접근에 있어 보안성과 관리 효율성을 높이는 필수적인 구성 요소입니다. VPN 사용이 불가능하거나, 간단한 접근 방식이 필요한 경우 특히 유용합니다.