토이프로젝트 CHPO AWS 인프라 아키텍처 개선

chpo는 Check Your Position으로 GitHub 아이디를 통해 현재 포지션을 확인하고 취업관리를 진행할 수 있는 토이 프로젝트입니다.
지인이 구축한 본 토이프로젝트 chpo는 인프라 측면에서 많은 개선사항이 요구 되었으며, 실제 서비스를 운영함에 있어 사용자로 속도 측면에서 많은 피드백이 들어온 상태입니다. 본 글에서는 현재 아키텍처 분석을 통해 TO-BE 구성 아키텍처를 살펴보도록 합니다.

---

AS-IS

토이 프로젝트 chpo의 AS-IS 아키텍처는 위 그림과 같습니다. EC2, RDS를 퍼블릭 서브넷에 두고, 보안그룹을 통해 접근제어를 하고 있습니다. 해당 아키텍처는 AWS Well-Architected 및 6대 원칙에 어긋나는 아키텍처 이기 때문에 구성상태에 있어 큰 문제가 있다고 할 수 있습니다.
단적으로 EC2, RDS를 퍼블릭 서브넷에 두는 행위는 보안적으로 큰 위험을 일으킬 수 있기 때문입니다.

AWS Well-Architected 및 6대 원칙

AWS Well-Architected는 클라우드 설계자가 다양한 애플리케이션 및 워크로드를 위한 안전하고 고성능의 탄력적이며 효율적인 인프라를 구축할 수 있도록 지원합니다. 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속 가능성이라는 6가지 원칙을 중심으로 구축된 AWS Well-Architected는 고객과 파트너가 아키텍처를 평가하고 확장 가능한 설계를 구현할 수 있도록 일관된 접근 방식을 제공합니다.

운영 우수성 원칙

• 시스템을 실행 및 모니터링 하고 프로세스와 절차를 지속적으로 개선하는데 중점을 둡니다.
• 변경 자동화, 이벤트 대응 및 일상적인 작업 관리를 위한 표준 정의가 포함됩니다.보안 원칙
• 정보와 시스템을 보호하기 위해 데이터의 기밀성 및 무결성, 사용자 권한 관리, 보안 이벤트를 감지합니다.안정성 원칙
• 의도한 기능을 수행하는 워크로드와 요구사항을 충족하기 위해 실패로 부터 신속하게 복구합니다.
• 분산 시스템 설계, 복구 계획 및 변화하는 요구 사항에 대한 적응이 포함됩니다.성능 효율성 원칙
• IT 및 컴퓨팅 리소스의 구조화되고 간소화를 위해 워크로드 요구 사항에 최적화된 리소스 유형 및 크기 선택, 성능 모니터링, 비즈니스 요구 사항 변화에 따른 효율성 유지가 포함됩니다.비용 최적화 원칙
• 불필요한 비용 발생을 방지하기 위해 시간 경과에 따른 지출 이해 및 자금 할당 제어, 올바른 유형 및 수량의 리소스 선택, 초과 지출 없이 비즈니스 요구를 충족하도록 확장이 포함됩니다.지속 가능성 원칙
• 클라우드 워크로드 실행이 환경에 미치는 영향을 최소화하여 지속 가능성을 위한 공동 책임 모델, 영향 이해 및 활용을 극대화하여 필요한 리소스를 최소화하고 다운스트림 영향을 줄이는 방법입니다.

TO-BE

 

위의 아키텍처는 기존의 구성 아키텍처의 문제점을 보완하고 앞으로 지속 가능한 서비스 운영을 위해 구성된 아키텍처 입니다. 간단한 아키텍처 이지만 해당 아키텍처로 변경 구성하는 것 만으로도 AWS Well-Architected 및 6대 원칙에 거의 부합하는 인프라 구조도를 가질 수 있고 개발자와 유저간의 문제점을 상당 부분 해결합니다.
다음은 아키텍처 구성에 대한 설명을 진행합니다.

• Bastion
  • Bastion 은 보루, 요새라는 뜻으로 중세 시대에 영주나 왕이 살고 있는 중요한 기지인 성을 둘러싸고 있는 방어막을 의미합니다.
  • WAS 나 DBMS 서버등은 외부에 노출하면 안 되므로 사설 IP를 할당해서 운영해야 합니다.
  • 회사내의 개발자 PC 등 정해진 곳에서 사설망 내의 서버에 개발이나 관리를 위해 SSH 등으로 원격 접속이 필요하며 네트워크를 분할할 경우 사설망내의 서버들은 공용 IP 가 없으므로 외부에서 바로 접근 불가한 문제가 있습니다.
  • Bastion 구성을 통해 Public subnet 에 위치시키고 운영 서버에 SSH 로 원격 접근 권한은 Bastion Host 만 가능하도록 내부의 방화벽 및 보안 정책을 적용하면 보안과 편의성을 가질 수 있습니다.
• NAT Gateway
  • 프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용할 수 있습니다.
  • 이를 통해 프라이빗 서브넷에 있는 AWS 리소스가 인터넷 접근을 허용하면서 동시에 외부 접속을 차단하여 보안 및 접근성을 향상 시킬 수 있습니다.
  • 단, RDS의 경우 별도의 서브넷을 분리 시켜 NAT 게이트웨이를 통한 인터넷 접속도 차단하여 완전히 격리된 서브넷에서 운영합니다.
• ALB (Application Load Balancer)
  • 웹 서비스에 걸리는 부하를 분산해주는 로드 밸런서입니다.
    • 고가용성 지원
    • 사용자 인증과 같은 보안 향상
    • 다양한 레벨의 부하에 대한 유연한 응답
• 애플리케이션 밀착 모니터링 및 검수
  • 갑작스런 트래픽 증가하더라도 각 EC2에 로드되는 부하를 줄여 안정적으로 운영 될 수 있도록 합니다.
    • 단, 현재 서비스는 사용자가 많지는 않기 때문에 별도의 오토스케일링은 진행하지 않았습니다.
• ElastiCache for Redis
  • Refresh Token 저장 및 크롤링 데이터 저장용으로 사용합니다. 

PROD는 이중화 방식을 통해 각 AZ로 분리된 환경에서 문제가 발생하더라도 다른 AZ를 통해 서비스가 될 수 있도록 구성하였고, DEV 환경에서는 비용 절감을 위해 단중화 구성을 진행했습니다.
이외에도 AWS WAF, Route53, ACM, CodeDeploy 서비스를 구성하여 AWS 환경에서 보안과 관리를 통합적으로 할 수 있도록 구조를 개선하였습니다.

기타 궁금하신 점이 있다면 댓글 부탁드립니다.