자동화된 소프트웨어 시스템을 구축한다는 것은 수년 동안 전용 CPU 구성, 메모리, 스토리지 및 기타 리소스를 갖춘 여러 서버를 설정하는 것을 의미했습니다. 다음으로 이러한 시스템을 관리하기 위해 관리자 팀이 구성되었습니다. 그런 다음 개발 팀이 인프라를 인수하고 서버를 연결하는 프로세스를 만들기 시작했습니다.
이 프로세스는 공통의 목표를 향해 함께 일하는 여러 그룹이 관련되어 있기 때문에 복잡할 수 있습니다. 이러한 이해 상충은 문제가 될 수 있습니다.
비용이 많이 들 수도 있습니다. 이를 위해서는 급여에 관리자가 있어야 합니다. 지속적으로 실행되는 서버는 사용하지 않음에도 불구하고 리소스를 소비합니다.
시간이 지나도 최상의 성능을 유지하려면 서버 자원을 자동으로 스케일링하는 오토스케일링 솔루션이 필요합니다.
클라우드 플랫폼에는 한 가지 장점이 있습니다. 서버 클러스터를 설정할 필요 없이 종단 간 아키텍처를 만들 수 있습니다. 관리 관점에서 유지 관리할 것이 없습니다.
이는 신생 기업 및 프로젝트의 최소 실행 가능 제품(MVP) 단계를 위한 비용 효율적인 옵션입니다. 향후 생산 부하 및 사용자 활동을 예측하기 어려운 경우 좋은 출발점입니다. 여기에서 클러스터 서버의 구성을 결정하기 어려울 수 있습니다.
서버리스 클라우드 서비스를 통한 프로세스 자동화는 서버리스 아키텍처를 돋보이게 합니다. 서비스를 연결하고 기존 클러스터 서버와 유사한 결과를 생성합니다.
이는 네이티브 AWS 서비스만을 사용하여 이러한 아키텍처를 구축한 예입니다.
목차
서비스 서버리스 흐름 선택
일부 구체적인 자산 인프라(제조 또는 유틸리티 자산일 수 있음)의 다양한 데이터 및 사진(또는 사진)을 수집하는 플랫폼을 만들고 싶다고 상상해 보십시오.
- 향후 분석을 가능하게 하려면 수신 데이터를 먼저 수집해야 합니다.
- 비즈니스 규칙을 적용한 후 백엔드 프로시저는 계산된 출력을 관계형 데이터베이스에 정규화된 정보로 저장합니다.
- 정규화된 클린 데이터를 표시하는 애플리케이션 프런트 엔드를 통해 사용자는 결과를 볼 수 있습니다.
어떤 구성 요소 아키텍처가 포함될 수 있는지 살펴보겠습니다.
AWS S3 버킷
출처: aws.amazon.com
Amazon S3 버킷은 AWS 클라우드에 파일이나 사진을 저장하는 좋은 방법입니다. S3 버킷의 스토리지 가격은 매우 저렴합니다. 또한 S3 버킷 수명 주기 정책을 도입하면 이 가격이 더욱 낮아집니다.
이러한 정책은 오래된 파일을 아카이브 또는 심층 아카이브 액세스와 같은 다른 클래스의 S3 버킷으로 자동으로 이동합니다. 클래스는 액세스 시간 속도에 따라 다르지만 오래된 데이터의 경우 문제가 되지 않습니다. 표준 운영 요구가 아닌 긴급 이벤트의 경우 보관된 데이터에 액세스하는 데 주로 사용됩니다.
- 하위 폴더에 데이터를 구성할 수 있습니다.
- 적절한 권한 제한을 설정해야 합니다.
- 동적 S3 버킷 정책 내에서 쉽게 식별하고 사용할 수 있도록 버킷에 태그를 추가합니다.
- 버킷은 기본적으로 서버리스입니다. 단순히 데이터를 저장하는 공간입니다.
S3 버킷은 기본적으로 서버리스입니다. 단순히 데이터를 저장하는 공간입니다.
AWS 아테나 데이터베이스
출처: aws.amazon.com
Athena를 사용하면 AWS 기본 데이터 레이크를 쉽게 생성할 수 있습니다. S3 버킷을 사용하여 데이터를 저장하는 서버가 없는 데이터베이스입니다. 데이터 구성은 쪽모이 세공 또는 CSV(쉼표로 구분된 값) 파일과 같은 구조화된 파일 형식으로 유지됩니다. S3 버킷은 파일을 보관하며 Athena는 프로세스가 데이터베이스에서 데이터를 선택할 때마다 해당 파일을 참조합니다.
Athena는 표준으로 간주되는 다양한 기능(예: 업데이트 문)을 지원하지 않는다는 점에 유의하십시오. 이것이 Athena를 매우 간단한 옵션으로 봐야 하는 이유입니다.
그러나 인덱싱 및 파티셔닝을 지원합니다. 또한 인프라에 새 버킷을 추가하는 것만큼 복잡하기 때문에 매우 쉽게 수평으로 확장할 수 있습니다. 간단하면서도 기능적인 데이터 레이크 생성의 경우 대부분의 경우 이 정도면 충분합니다.
좋은 성능을 위해서는 향후 사용에 중점을 둔 최상의 데이터 디자인을 선택하는 것이 필수적입니다. 데이터를 선택하려는 방식을 매우 명확하게 지정하는 것이 중요합니다. 이미 존재하고 많은 데이터로 채워진 테이블을 나중에 다시 생성하는 것은 어렵습니다.
Athena DB는 시간이 지남에 따라 쉽게 수평으로 확장할 수 있는 단순하고 변경 불가능한 데이터 풀을 생성하려는 경우 훌륭한 선택이며 목표에 적합합니다.
AWS 오로라 데이터베이스
출처: aws.amazon.com
Athena DB는 정리되지 않은 데이터를 저장하는 데 탁월합니다. 이것이 결국 나중에 재사용을 극대화하기 위해 원본 콘텐츠를 저장하려는 방법입니다. 그러나 프런트 엔드 앱에 선택한 결과를 제공하는 것은 느립니다.
주로 실행하기 쉬운 설정의 관점에서 가장 좋은 옵션 중 하나는 서버리스 모드에서 실행되는 Aurora 데이터베이스입니다.
Aurora는 기본 데이터베이스와는 거리가 멉니다. AWS에서 가장 발전된 기본 관계형 데이터베이스 솔루션 중 하나입니다. 또한 모든 릴리스에서 개선되는 매우 복잡한 기본 관계형 데이터베이스 솔루션입니다.
Aurora는 서버리스 모드에서 실행할 수 있어 다른 관계형 서비스와 차별화됩니다. 모드 작동 방식은 다음과 같습니다.
- Aurora 클러스터를 구성하려면 AWS 콘솔을 사용하십시오. 표준 CPU 및 RAM 수준과 자동 크기 조정 기능의 최대 간격을 지정해야 합니다. 이것은 Aurora 클러스터가 동적으로 추가하거나 제거할 수 있는 성능에 영향을 미칩니다. 데이터베이스의 현재 사용률에 따라 AWS는 확장 또는 축소를 결정합니다.
- 사용자 또는 프로세스가 실제 요청을 시작하지 않으면 Aurora 클러스터가 시작되지 않습니다. 예를 들어 예약된 일괄 처리가 시작되는 경우입니다. 또는 애플리케이션이 백엔드 API 호출을 수행하여 데이터베이스에서 데이터를 검색하는 경우. 데이터베이스는 자동으로 열리고 요청 프로세스가 완료된 후 미리 결정된 시간 동안 활성 상태를 유지합니다.
- 데이터베이스에 더 이상 작업이 없으면 Aurora 클러스터가 자동으로 종료됩니다.
다시 한 번 강조하자면 서버리스 Aurora DB는 실제 작업이 필요한 경우에만 실행됩니다. 자동으로 시작된 클러스터는 작업을 처리하지 않으면 다시 종료됩니다. 실제 작업은 유휴 시간이 아니라 지불하는 것입니다.
서버리스 Aurora는 AWS에서 완전히 관리하며 관리자가 필요하지 않습니다.
AWS 증폭
Amplify는 JavaScript 및 React 라이브러리로 만든 프런트 엔드 애플리케이션의 신속한 배포를 위한 서버리스 플랫폼을 제공합니다. 클러스터 서버를 설정할 필요가 없습니다. AWS 콘솔을 사용하여 코드를 직접 배포하거나 자동화된 DevOps 파이프라인을 사용하십시오.
백엔드 API를 호출하여 데이터베이스에 저장된 데이터에 접근할 수 있습니다. 이러한 호출을 통해 프런트 엔드 애플리케이션의 실제 데이터에 액세스할 수 있습니다. 백엔드 성능의 주요 최적화는 팀에서 수행해야 합니다. API 호출 내에서 직접 효과적인 선택 문을 설계하면 UI에서 응답이 느려질 가능성을 더욱 줄일 수 있습니다.
AWS 단계 기능
출처: aws.amazon.com
시스템의 모든 주요 구성 요소가 서버리스이지만 이것이 완전한 서버리스 아키텍처를 보장하지는 않습니다. 이는 구성 요소 간의 모든 배치 프로세스가 서버리스인 경우에만 가능합니다.
AWS Step Functions은 AWS 클라우드에서 최상의 솔루션을 제공합니다. AWS Lambda 함수의 연결된 목록이 단계 함수를 구성합니다. 이러한 함수는 명확한 시작 및 종료 상태가 있는 순서도를 만듭니다. 일반적으로 Python 또는 Node JS 언어로 작성된 람다 함수는 필요한 모든 것을 처리하는 실행 가능한 코드 비트입니다.
다음은 단계 함수를 실행할 수 있는 방법의 예입니다.
이 서버리스 흐름에는 한 가지 주요 단점이 있습니다. 각 람다 함수는 최대 15분 동안만 실행할 수 있습니다. 따라서 흐름을 더 작은 람다 함수로 분할하면 문제가 덜 발생할 수 있습니다.
한 단계에서 여러 람다 함수를 동시에 호출할 수 있습니다. 이는 기본적으로 동시에 실행되는 여러 람다로 단계를 병렬화하는 것을 의미합니다. 계속하기 전에 모든 병렬 람다 처리가 완료될 때까지 기다리십시오. 그런 다음 다음 람다 처리를 진행합니다.
마지막 말
서버리스 아키텍처는 전체 시스템 환경을 포괄하는 클라우드 플랫폼을 만들 수 있는 고유한 기회를 제공합니다. 이 플랫폼은 수평 확장이 가능하며 운영 비용이 낮습니다.
예산이 제한된 프로젝트를 위한 완벽한 솔루션입니다. 일반적으로 아무도 생산 부하의 현실을 알지 못하는 경우 훌륭한 탐색 옵션입니다. 이는 모든 사용자를 성공적으로 온보딩한 후에 특히 중요합니다. 프로젝트 팀은 여전히 시스템 작동 방식에 대한 전반적인 관점을 얻을 수 있습니다. 이러한 모든 이점을 누릴 수 있으며 여전히 타협을 받아들일 필요가 없습니다.
이 적용 범위는 모든 경우, 특히 CPU 사용량이 많은 경우에 적합하지 않습니다. 그러나 AWS 클라우드는 서버리스 사용 사례 측면에서 지속적으로 발전하고 있습니다. 일반적으로 다음 AWS 클라우드 프로젝트를 위한 서버리스 옵션을 결정하기 전에 철저한 조사를 수행하는 것이 좋습니다.
다음으로 최신 애플리케이션을 위한 최고의 서버리스 데이터베이스를 확인하십시오.