사례 연구: 내 제품에 AWS 클라우드 인프라를 사용하는 이유

게시 됨: 2022-03-11

복잡하고 까다로운 소프트웨어 제품을 실행하기 위한 플랫폼인 AWS는 필요할 때 필요한 규모로 리소스를 활용하여 유연성을 제공합니다. 온디맨드 방식으로 즉시 실행되므로 실행 환경을 완벽하게 제어할 수 있습니다. 이러한 클라우드 아키텍처 솔루션을 클라이언트에 제안할 때 프로비저닝된 인프라 및 가격은 미리 설정해야 하는 요구 사항에 크게 좌우됩니다.

이 기사에서는 사용자가 자신이 속한 카드 프로그램, 소유한 물건 또는 장소에 대해 얻을 수 있는 모든 이점을 찾아 적용하는 통합 안면 결제 기능이 있는 소셜 네트워크인 LEVELS를 위해 제안 및 구현된 AWS 클라우드 인프라 아키텍처 중 하나를 제시합니다. 그들은 살고 있습니다.

요구 사항

클라이언트는 제안된 솔루션이 충족해야 하는 두 가지 주요 요구 사항을 가지고 있었습니다.

보안
확장성

보안 요구 사항 은 외부뿐만 아니라 내부로부터의 무단 액세스로부터 사용자 데이터를 보호하는 것이었습니다. 확장성 요구 사항 은 제품 성장을 지원하고 증가하는 트래픽과 간헐적인 급증에 자동으로 적응하고 서버 오류가 발생할 경우 자동 장애 조치 및 복구를 통해 잠재적 가동 중지 시간을 최소화하는 인프라 능력에 관한 것이었습니다.

AWS 보안 개념 개요

자체 AWS 클라우드 인프라를 설정하는 주요 이점 중 하나는 클라우드에 대한 완전한 네트워크 격리 및 완전한 제어입니다. 이것이 견고한 보안 기본값을 제공하지만 완벽하고 세분화된 제어가 부족한 다소 단순한 PaaS(Platform as a Service) 환경을 실행하는 대신 IaaS(Infrastructure as a Service) 경로를 선택하는 주된 이유입니다. AWS를 사용하여 자신의 클라우드를 설정합니다.

LEVELS는 AWS 컨설팅 서비스를 위해 Toptal에 접근할 당시 신생 제품이었지만 사용자 데이터 및 개인 정보 보호에 대해 매우 우려하기 때문에 AWS에 기꺼이 전념하고 인프라에 최첨단 보안을 원한다는 것을 알았습니다. 또한 향후 신용 카드 처리를 지원할 계획이므로 어느 시점에서 PCI-DSS 준수를 보장해야 한다는 것을 알았습니다.

가상 사설 클라우드(VPC)

AWS의 보안은 AWS 리소스를 호스팅하고 AWS 클라우드의 다른 가상 네트워크와 논리적으로 격리된 전용 가상 네트워크인 자체 Amazon Virtual Private Cloud (VPC)를 생성하는 것으로 시작됩니다. VPC는 자체 IP 주소 범위, 완전히 구성 가능한 서브넷, 라우팅 테이블, 네트워크 액세스 제어 목록 및 보안 그룹(효과적으로 방화벽)을 얻습니다.

LEVELS를 사용하여 개발, 테스트 및 QA 환경에서 프로덕션 환경을 분리하는 것으로 시작했습니다. 첫 번째 아이디어는 각각을 애플리케이션에 필요한 모든 서비스를 실행하는 완전히 격리된 자체 VPC로 실행하는 것이었습니다. 약간의 고려 끝에 3개의 비프로덕션 환경에서 리소스 공유를 허용할 수 있어 비용을 어느 정도 절감할 수 있었습니다.

따라서 우리는 프로덕션 환경을 하나의 VPC로, 개발, 테스트 및 QA 환경을 다른 VPC로 설정했습니다.

VPC 수준에서 액세스 격리

2-VPC 설정은 프로덕션 환경을 네트워크 수준의 나머지 3개 환경과 분리하여 우발적인 애플리케이션 구성 오류가 해당 경계를 넘지 못하도록 합니다. 비프로덕션 환경 구성이 데이터베이스나 메시지 큐와 같은 프로덕션 환경 리소스를 잘못 가리켜야 하는 경우에도 액세스 권한을 얻을 수 있는 방법이 없습니다.

동일한 VPC를 공유하는 개발, 테스트 및 QA 환경에서는 구성이 잘못된 경우 경계 간 액세스가 가능하지만 이러한 환경에서 테스트 데이터를 사용하기 때문에 격리 부족으로 인한 실질적인 보안 문제는 없습니다.

자산 저장소 보안 모델

자산은 Amazon Simple Storage Service(S3) 객체 스토리지에 저장됩니다. S3 스토리지 인프라는 VPC와 완전히 독립적이며 보안 모델이 다릅니다. 스토리지는 각 환경 및/또는 자산 클래스에 대해 별도의 S3 버킷으로 구성되어 적절한 액세스 권한으로 각 버킷을 보호합니다.

LEVELS를 사용하여 사용자 업로드, LEVELS에서 제작한 콘텐츠(프로모션 비디오 및 유사 콘텐츠), 웹 애플리케이션 및 UI 자산(JS 코드, 아이콘, 글꼴), 애플리케이션 및 인프라 구성, 서버 측 배포 번들과 같은 여러 자산 클래스가 식별되었습니다.

이들 각각은 별도의 S3 버킷을 얻습니다.

애플리케이션 비밀 관리

AWS에는 암호를 안전하게 유지하도록 설계된 관리형 키-값 서비스인 암호화된 AWS Systems Manager Parameter Store 또는 AWS Secrets Manager 가 있습니다(Linux Academy 및 1Strategy에서 자세히 알아볼 수 있음).

AWS는 기본 암호화 키를 관리하고 암호화/복호화를 처리합니다. 비밀 자체에는 인프라와 사용자(각각 서버 및 개발자) 모두에 대해 키 접두사를 기반으로 적용되는 읽기 및 쓰기 권한 정책이 있을 수 있습니다.

서버 SSH 액세스

완전히 자동화되고 변경할 수 없는 환경에서 서버에 대한 SSH 액세스는 전혀 필요하지 않습니다. 로그를 추출하여 전용 로깅 서비스로 보낼 수 있으며 모니터링도 전용 모니터링 서비스로 오프로드됩니다. 그러나 구성 검사 및 디버깅을 위해 가끔 SSH 액세스가 필요할 수 있습니다.

서버의 공격 표면을 제한하기 위해 SSH 포트는 공용 네트워크에 노출되지 않습니다. 서버는 외부 SSH 액세스를 허용하는 전용 머신인 배스천 호스트를 통해 연결되며 방화벽에서 허용된 IP 주소 범위만 화이트리스트에 추가하여 보호됩니다. 사용자의 공개 SSH 키를 해당 상자에 배포하여 액세스를 제어합니다(암호 로그인은 비활성화됨). 이러한 설정은 악의적인 공격자가 통과할 수 있는 상당히 탄력적인 게이트를 제공합니다.

데이터베이스 액세스

위에서 설명한 것과 동일한 원칙이 데이터베이스 서버에 적용됩니다. 이것은 확실히 권장되는 방법이 아니며 서버 SSH 액세스가 보호되는 것과 같은 방식으로 이러한 액세스를 보호해야 하지만 데이터베이스에서 직접 데이터를 연결하고 조작해야 하는 경우가 있습니다.

SSH 터널링과 동일한 배스천 호스트 인프라를 활용하여 유사한 접근 방식을 사용할 수 있습니다. 이중 SSH 터널이 필요합니다. 하나는 배스천 호스트에 연결되고 다른 하나는 데이터베이스에 액세스할 수 있는 서버에 연결됩니다(배스천 호스트는 데이터베이스 서버에 액세스할 수 없음). 두 번째 터널을 통해 사용자의 클라이언트 시스템에서 데이터베이스 서버로의 연결을 사용할 수 있습니다.

AWS 확장성 개념 개요

순전히 서버에 대해 이야기할 때 확장성은 AWS보다 간단한 플랫폼에서 오히려 쉽게 달성됩니다. 주요 단점은 데이터가 공용 네트워크를 가로질러 이동하고 보안 경계를 깨는 것을 의미하는 플랫폼의 외부 서비스에서 특정 요구 사항을 다루어야 할 수도 있다는 것입니다. AWS를 사용하면 모든 데이터가 비공개로 유지되는 반면, 확장 가능하고 탄력적이며 내결함성이 있는 인프라를 달성하려면 확장성을 엔지니어링해야 합니다.

AWS에서 확장성에 대한 최상의 접근 방식은 플랫폼을 사용하는 수천 명의 클라이언트에 대해 전투 테스트를 거친 모니터링 및 자동화와 함께 관리형 AWS 서비스를 활용하는 것입니다. 데이터 백업 및 복구 메커니즘을 혼합에 추가하면 플랫폼 자체에 의존함으로써 테이블에서 많은 우려를 피할 수 있습니다.

이 모든 것을 오프로드하면 더 작은 운영 팀이 가능하여 플랫폼 관리 서비스의 더 높은 비용을 어느 정도 상쇄할 수 있습니다. LEVELS 팀은 가능한 한 기꺼이 그 길을 선택했습니다.

Amazon Elastic Compute Cloud(EC2)

EC2 인스턴스 를 실행하는 검증된 환경에 의존하는 것은 컨테이너 실행의 추가 오버헤드와 복잡성 또는 아직 젊고 빠르게 변화하는 서버리스 컴퓨팅의 아키텍처 개념에 비해 여전히 상당히 합리적인 접근 방식입니다.

EC2 인스턴스 프로비저닝은 완전히 자동화되어야 합니다. 자동화는 다양한 서버 클래스에 대한 사용자 지정 AMI를 통해 이루어지며 Auto Scaling Group은 현재 트래픽에 따라 집합에서 실행 중인 서버 인스턴스의 적절한 수를 유지하여 실행 중인 동적 서버 집합을 관리합니다.

또한 Auto-Scaling 기능을 사용하면 실행할 EC2 인스턴스 수의 하한 및 상한을 설정할 수 있습니다. 하한은 내결함성을 지원하여 인스턴스 장애 시 가동 중지 시간을 잠재적으로 제거합니다. 상한선은 비용을 통제할 수 있도록 하여 예상치 못한 극한 상황에서 가동 중지 시간의 위험을 허용합니다. 그런 다음 Auto-scaling은 해당 제한 내에서 인스턴스 수를 동적으로 확장합니다.

Amazon 관계형 데이터베이스 서비스(RDS)

팀은 이미 Amazon RDS for MySQL을 실행하고 있지만 적절한 백업, 내결함성 및 보안 전략이 아직 개발되지 않았습니다. 첫 번째 반복에서 데이터베이스 인스턴스는 자동 장애 조치를 지원하는 마스터 및 읽기 전용 복제본으로 구성된 각 VPC의 2개 인스턴스 클러스터로 업그레이드되었습니다.

다음 반복에서는 MySQL 버전 5.7 엔진을 사용할 수 있게 되면서 인프라가 Amazon Aurora MySQL 서비스로 업그레이드되었습니다. 완전 관리형이지만 Aurora는 자동으로 확장되는 솔루션이 아닙니다. 자동 스토리지 확장을 제공하여 용량 계획 문제를 방지합니다. 그러나 솔루션 설계자는 여전히 컴퓨팅 인스턴스 크기를 선택해야 합니다.

확장으로 인한 가동 중지 시간은 피할 수 없지만 자동 복구 기능을 통해 최소화할 수 있습니다. 더 나은 복제 기능 덕분에 Aurora는 원활한 장애 조치 기능을 제공합니다. 확장은 원하는 컴퓨팅 성능으로 읽기 전용 복제본을 생성한 다음 해당 인스턴스에 대한 장애 조치를 실행하여 실행됩니다. 그런 다음 다른 모든 읽기 전용 복제본도 클러스터에서 제거하고 크기를 조정한 다음 클러스터로 다시 가져옵니다. 약간의 수동 저글링이 필요하지만 실행 가능한 것 이상입니다.

새로운 Aurora Serverless 제품은 컴퓨팅 리소스의 일정 수준의 자동 확장도 가능하게 하며, 이는 미래에 확실히 살펴볼 가치가 있는 기능입니다.

관리형 AWS 서비스

이 두 가지 구성 요소를 제외하고 나머지 시스템은 완전 관리형 AWS 서비스의 자동 확장 메커니즘을 활용합니다. 바로 Elastic Load Balancing(ELB), Amazon Simple Queue Service(SQS), Amazon S3 객체 스토리지, AWS Lambda 함수, Amazon Simple Notification Service(SNS)로 설계자의 특별한 조정 노력이 필요하지 않습니다.

변경 가능한 인프라와 변경할 수 없는 인프라

우리는 서버 인프라를 처리하는 두 가지 접근 방식을 알고 있습니다. 및 서버가 프로비저닝된 후 수정되지 않고 구성 수정 또는 서버 업데이트가 공통 이미지 또는 설치 스크립트에서 새 서버를 프로비저닝하여 이전 서버를 교체하는 방식으로 처리되는 불변 인프라입니다.

LEVELS를 사용하면 현재 위치 업그레이드, 구성 변경 또는 관리 작업 없이 변경할 수 없는 인프라 를 실행할 수 있습니다. 유일한 예외는 제자리에서 발생하는 애플리케이션 배포입니다.

변경 가능한 인프라와 변경 불가능한 인프라에 대한 자세한 내용은 HashiCorp의 블로그에서 확인할 수 있습니다.

아키텍처 개요

기술적으로 LEVELS는 REST API 백엔드 및 일부 백그라운드 서비스가 포함된 모바일 앱 및 웹 앱입니다. 오늘날에는 다소 일반적인 애플리케이션입니다. 이와 관련하여 다음과 같은 인프라가 제안 및 구성되었습니다.

가상 네트워크 격리 - Amazon VPC

이 다이어그램은 VPC에 있는 한 환경의 구조를 시각화합니다. 다른 환경은 동일한 구조를 따릅니다(ALB(Application Load Balancer) 및 Amazon Aurora 클러스터가 VPC의 비프로덕션 환경 간에 공유되지만 네트워킹 설정은 정확히 동일함).

VPC는 내결함성을 위해 AWS 리전 내 4개의 가용 영역에 걸쳐 구성됩니다. 네트워크 액세스 제어 목록이 있는 서브넷 및 보안 그룹을 사용하면 보안 및 액세스 제어 요구 사항을 충족할 수 있습니다.

추가 내결함성을 위해 여러 AWS 리전에 걸쳐 인프라를 확장하는 것은 비즈니스 및 해당 제품의 초기 단계에서 너무 복잡하고 불필요했을 것이지만 미래에는 옵션입니다.

컴퓨팅

LEVELS는 백그라운드에서 발생하는 애플리케이션 로직을 위해 일부 백그라운드 작업자와 함께 전통적인 REST API를 실행합니다. 이 두 가지 모두 Auto Scaling Groups를 통해 완전히 자동화된 일반 EC2 인스턴스의 동적 집합으로 실행됩니다. Amazon SQS 관리형 서비스는 백그라운드 작업(작업) 배포에 사용되므로 자체 MQ 서버를 실행, 유지 관리 및 확장할 필요가 없습니다.

이미지 처리와 같이 나머지 애플리케이션과 공유되는 비즈니스 로직이 없는 유틸리티 작업도 있습니다. 이러한 유형의 작업은 AWS Lambda 에서 매우 잘 실행됩니다. Lambda는 수평으로 무한히 확장 가능하고 서버 작업자와 비교할 수 없는 병렬 처리를 제공하기 때문입니다.

부하 분산, 자동 크기 조정 및 내결함성

로드 밸런싱은 Nginx 또는 HAProxy를 통해 수동으로 달성할 수 있지만 Amazon Elastic Load Balancing(ELB) 을 선택하면 로드 밸런싱 인프라가 본질적으로 자동으로 확장 가능하고 고가용성이며 내결함성을 갖게 되는 이점이 추가됩니다.

ELB의 ALB(Application Load Balancer) 특징이 사용되어 로드 밸런서에서 사용할 수 있는 HTTP 계층 라우팅을 사용합니다. 플릿에 추가된 새 인스턴스는 AWS 플랫폼의 메커니즘을 통해 ALB에 자동으로 등록됩니다. 또한 ALB는 항상 인스턴스의 가용성을 모니터링합니다. 비정상 인스턴스를 등록 취소하고 종료하여 Auto Scaling을 트리거하여 새 인스턴스로 교체하는 기능이 있습니다. 둘 사이의 이러한 상호 작용을 통해 EC2 집합 자동 복구가 달성됩니다.

애플리케이션 데이터 저장소

애플리케이션 데이터 스토어는 마스터 인스턴스와 여러 읽기 전용 복제본 인스턴스로 구성된 Amazon Aurora MySQL 클러스터 입니다. 마스터 인스턴스가 실패하는 경우 읽기 전용 복제본 중 하나가 자동으로 새 마스터 인스턴스로 승격됩니다. 이와 같이 구성되어 요청된 내결함성 요구 사항을 충족합니다.

읽기 전용 복제본은 이름에서 알 수 있듯이 데이터 읽기 작업에 대한 데이터베이스 클러스터 로드를 분산하는 데 사용할 수도 있습니다.

데이터베이스 스토리지는 Aurora를 사용하여 자동으로 10GB 단위로 확장되며 백업도 AWS에서 완벽하게 관리되어 기본적으로 특정 시점 복원을 제공합니다. 필요에 따라 데이터베이스 컴퓨팅 성능을 확장하는 것을 제외하고는 데이터베이스 관리 부담을 거의 모두 줄여줍니다.

자산 저장 및 제공

LEVELS는 저장해야 하는 사용자의 업로드된 콘텐츠를 허용합니다. Amazon S3 객체 스토리지는 예상대로 해당 작업을 처리하는 서비스입니다. 클라이언트 앱에서 사용할 수 있도록 해야 하는 애플리케이션 자산(UI 요소 - 이미지, 아이콘, 글꼴)도 있으므로 S3에도 저장됩니다. 내부 저장소 복제를 통해 업로드된 데이터의 자동 백업을 제공하는 S3는 기본적으로 데이터 내구성을 제공합니다.

사용자가 업로드하는 이미지는 크기와 무게가 다양하며 직접 제공하기에는 종종 불필요하게 크고 과체중이어서 모바일 연결에 부담을 줍니다. 다양한 크기로 여러 변형을 생성하면 각 사용 사례에 대해 보다 최적화된 콘텐츠를 제공할 수 있습니다. AWS Lambda 는 해당 작업과 만일의 경우에 대비하여 업로드된 이미지 원본의 복사본을 별도의 백업 버킷으로 만드는 데 활용됩니다.

마지막으로 브라우저 실행 웹 애플리케이션은 정적 자산의 집합이기도 합니다. 지속적인 통합 빌드 인프라는 JavaScript 코드를 컴파일하고 각 빌드도 S3에 저장합니다.

이러한 모든 자산이 S3에 안전하게 저장되면 S3에서 공개 HTTP 인터페이스를 제공하거나 Amazon CloudFront CDN을 통해 직접 제공할 수 있습니다. CloudFront는 자산을 지리적으로 분산시켜 최종 사용자의 지연 시간을 줄이고 정적 자산 제공을 위한 HTTPS 지원도 가능하게 합니다.

인프라 프로비저닝 및 관리

AWS 인프라 프로비저닝은 네트워킹, AWS 관리형 리소스 및 서비스, 베어 EC2 컴퓨팅 리소스의 조합입니다. 관리형 AWS 서비스는 잘 관리됩니다. 적절한 보안을 프로비저닝하고 적용하는 것 외에는 할 일이 많지 않지만 EC2 컴퓨팅 리소스를 사용하면 구성 및 자동화를 자체적으로 처리해야 합니다.

압형

웹 기반 AWS 콘솔을 사용하면 "레고 브릭과 같은" AWS 인프라를 관리하는 것이 간단하고 모든 수동 작업과 마찬가지로 오류가 발생하기 쉽습니다. 그렇기 때문에 해당 작업을 자동화하기 위해 전용 도구를 사용하는 것이 매우 바람직합니다.

그러한 도구 중 하나는 AWS에서 개발 및 유지 관리하는 AWS CloudFormation 입니다. 또 다른 하나는 HashiCorp의 Terraform 입니다. 여러 플랫폼 공급자를 제공함으로써 약간 더 유연한 선택이지만 여기서 주로 Terraform의 불변 인프라 접근 철학으로 인해 흥미롭습니다. LEVELS 인프라가 실행되는 방식에 맞춰 Terraform은 기본 AMI 이미지를 제공하기 위한 Packer와 함께 매우 적합한 것으로 판명되었습니다.

인프라 문서

자동화 도구의 또 다른 이점은 조만간 구식이 될 상세한 인프라 문서가 필요하지 않다는 것입니다. 프로비저닝 도구의 "코드로서의 인프라"(IaC) 패러다임은 실제 인프라를 항상 최신 상태로 유지한다는 이점이 있는 문서로 더빙됩니다. 상위 수준의 개요가 있고 변경될 가능성이 적고 최종 변경 사항에 대해 상대적으로 유지 관리가 용이하며 측면에 문서화되어 있으면 충분합니다.

마지막 생각들

제안된 AWS 클라우드 인프라는 미래의 제품 성장을 대부분 자동으로 수용할 수 있는 확장 가능한 솔루션입니다. 거의 2년 후 24시간 연중무휴로 근무하는 전담 시스템 운영 팀 없이 클라우드 자동화 에 의존하여 운영 비용을 낮게 유지합니다.

보안과 관련하여 AWS Cloud는 동일한 클라우드 내부의 사설 네트워크 내의 모든 데이터와 모든 리소스를 유지합니다. 공용 네트워크를 통해 이동할 때 기밀 데이터가 필요하지 않습니다. 외부 액세스는 신뢰할 수 있는 지원 시스템(CI/CD, 외부 모니터링 또는 경고)에 대한 세분화된 권한으로 부여되어 전체 시스템에서 해당 역할에 필요한 리소스로만 액세스 범위를 제한합니다.

올바르게 구성되고 설정된 이러한 시스템은 유연하고 탄력적이며 안전하며 제품 성장을 위한 확장 또는 PCI-DSS 규정 준수와 같은 고급 보안 구현과 관련된 모든 미래 요구 사항에 응답할 준비가 되어 있습니다.

Heroku나 유사한 플랫폼이 제공하는 제품이 다루는 일반적인 사용 패턴에 맞는 한 잘 작동하는 제품화된 제품보다 반드시 저렴하지는 않습니다. AWS를 선택하면 인프라에 대한 더 많은 제어 권한, 제공되는 AWS 서비스 범위를 통한 추가적인 유연성, 전체 인프라의 미세 조정 기능을 통한 사용자 지정 구성을 얻을 수 있습니다.

Amazon 파트너 네트워크(APN)의 고급 컨설팅 파트너인 Toptal은 기업에 클라우드 솔루션을 제공하고 기업 여정의 모든 단계에서 협력합니다.

Toptal 엔지니어링 블로그에 대한 추가 정보:

숙제하기: 7 AWS 공인 솔루션스 아키텍트 시험 팁
Terraform 대 CloudFormation: 최종 가이드
AWS SSM을 사용한 SSH 로깅 및 세션 관리
TypeScript 및 Jest 지원 작업: AWS SAM 자습서