Aurora Serverless v2 사용 - Amazon Aurora

Aurora Serverless v2 사용

Aurora Serverless v2는 Amazon Aurora에 대한 온디맨드 방식의 자동 크기 조정 구성입니다. Aurora Serverless v2는 워크로드를 모니터링하고 데이터베이스의 용량을 조정하는 프로세스를 자동화하는 데 도움이 됩니다. 용량은 애플리케이션 수요에 따라 자동으로 조정됩니다. DB 클러스터가 사용하는 리소스에 대해서만 청구됩니다. 따라서 Aurora Serverless v2는 예산 범위를 벗어나지 않도록 하고 사용하지 않는 컴퓨터 리소스에 대한 비용을 지불하지 않도록 하는 데 도움이 됩니다.

이러한 유형의 자동화는 멀티테넌트 데이터베이스, 분산 데이터베이스, 개발 및 테스트 시스템, 가변적이고 예측할 수 없는 워크로드가 있는 기타 환경에 특히 유용합니다.

Aurora Serverless v2 사용 사례

다양한 종류의 워크로드가 Aurora Serverless v2로부터 이점을 얻을 수 있습니다. Aurora Serverless v2는 다음 사용 사례에 특히 유용합니다.

  • 가변 워크로드 – 작업의 증가가 갑작스럽고 예측할 수 없는 워크로드를 실행하고 있는 경우입니다. 비가 내리기 시작하면 활동이 급증하는 트래픽 사이트를 예로 들 수 있습니다. 또 다른 하나는 세일 또는 특별 프로모션을 제공할 때 트래픽이 증가하는 전자 상거래 사이트입니다. Aurora Serverless v2를 사용하면 애플리케이션의 피크 로드를 처리하는 데 필요한 용량을 충족하도록 데이터베이스가 용량을 자동으로 확장하고 활동이 급증하는 시점이 지나면 용량을 다시 줄입니다. Aurora Serverless v2를 사용하면 더 이상 피크 또는 평균 용량에 맞추어 프로비저닝하지 않아도 됩니다. 최악의 상황을 처리하기 위해 용량 상한을 지정할 수 있으며, 필요한 경우가 아니면 그 용량이 사용되지 않습니다.

    Aurora Serverless v2의 세분화된 크기 조정 덕분에 데이터베이스 요구 사항과 용량을 매우 비슷하게 일치시키는 데 도움이 됩니다. 프로비저닝된 클러스터의 경우 확장하려면 완전히 새로운 DB 인스턴스를 추가해야 합니다. Aurora Serverless v1 클러스터를 확장하려면 클러스터의 Aurora 용량 단위(ACU)의 수를 배로 늘려야 합니다(예: 16에서 32로, 32에서 64로). 대조적으로, Aurora Serverless v2의 경우 용량이 조금 더 필요할 때 ACU의 절반을 추가할 수 있습니다. 워크로드의 증가를 처리하는 데 필요한 추가 용량에 따라 ACU의 0.5, 1, 1.5, 2와 같이 0.5 단위로 ACU를 추가할 수 있습니다. 또한 워크로드가 감소하고 용량이 더 이상 필요하지 않을 때 0.5, 1, 1.5, 2와 같이 0.5 단위로 ACU를 제거할 수 있습니다.

  • 다중 테넌트 애플리케이션 - Aurora Serverless v2을 사용하면 플릿에서 각 애플리케이션에 대한 데이터베이스 용량을 개별적으로 관리할 필요가 없습니다. Aurora Serverless v2은 사용자를 대신하여 개별 데이터베이스 용량을 관리해 줍니다.

    테넌트별로 클러스터를 생성할 수 있습니다. 이렇게 하면 복제, 스냅샷 복구 및 Aurora 글로벌 데이터베이스와 같은 기능을 사용하여 각 테넌트에 적합하도록 고가용성 및 재해 복구를 향상시킬 수 있습니다.

    각 테넌트는 하루 중 시간, 연중 시기, 프로모션 이벤트 등에 따라 바쁜 기간과 유휴 기간이 있을 수 있습니다. 각 클러스터는 용량 범위가 넓을 수 있습니다. 다라서 활동이 적은 클러스터는 DB 인스턴스 요금이 최소화됩니다. 어느 클러스터든 높은 활동 기간을 처리하도록 빠르게 확장할 수 있습니다.

  • 새 애플리케이션 – 새 애플리케이션을 배포하는 중인데, 필요한 DB 인스턴스 크기를 잘 모를 경우입니다. Aurora Serverless v2를 사용하면 DB 인스턴스를 하나 이상 사용하여 클러스터를 설정하고 애플리케이션의 필요 용량에 따라 데이터베이스의 크기를 자동으로 조정할 수 있습니다.

  • 개발 및 테스트 - Aurora Serverless v2를 사용하면 T DB 인스턴스 클래스를 사용하는 대신 최소 용량이 낮은 Aurora Serverless v2 DB 인스턴스를 생성할 수 있습니다. 최대 용량을 충분히 높게 설정하여 해당 DB 인스턴스에서 메모리가 부족하지 않게 상당한 워크로드를 실행할 수 있습니다. 데이터베이스를 사용하지 않을 때는 불필요한 요금을 피하기 위해 모든 DB 인스턴스가 축소됩니다.

    작은 정보

    개발 및 테스트 환경에서 Aurora Serverless v2를 편리하게 사용할 수 있도록 AWS Management Console에서는 새 클러스터를 생성할 때 쉬운 생성(Easy create) 단축키를 제공합니다. 개발 및 테스트(Dev/Test) 옵션을 선택하면 Aurora는 Aurora Serverless v2 DB 인스턴스와 함께 개발 및 테스트 시스템에서 일반적으로 사용되는 용량 범위로 클러스터를 생성합니다.

  • 혼용 애플리케이션 - 온라인 트랜잭션 처리(OLTP) 애플리케이션이 있지만 쿼리 트래픽이 주기적으로 급증한다고 가정합시다. 클러스터에서 Aurora Serverless v2에 대한 승격 티어를 지정하면 리더 DB 인스턴스가 라이터 DB 인스턴스와 독립적으로 확장되어 추가 로드를 처리할 수 있도록 클러스터를 구성할 수 있습니다. 사용량이 줄어들면 리더 DB 인스턴스는 라이터 DB 인스턴스의 용량에 맞게 축소됩니다.

  • 용량 계획 - 클러스터에 있는 모든 DB 인스턴스의 DB 인스턴스 클래스를 수정하여 일반적으로 데이터베이스 용량을 조정하거나 워크로드에 가장 적합한 데이터베이스 용량을 확인한다고 가정해 보겠습니다. Aurora Serverless v2를 사용하면 이런 관리 오버헤드를 예방할 수 있습니다. 워크로드를 실행하고 DB 인스턴스가 실제로 얼마나 조정되는지 확인하여 적절한 최소 및 최대 용량을 결정할 수 있습니다.

    기존 DB 인스턴스를 프로비저닝에서 Aurora Serverless v2로 또는 Aurora Serverless v2에서 프로비저닝으로 수정할 수 있습니다. 이런 경우 새 클러스터나 새 DB 인스턴스를 생성할 필요가 없습니다.

    Aurora 글로벌 데이터베이스를 사용하는 경우 보조 클러스터는 기본 클러스터만큼 용량이 많이 필요하지 않을 수 있습니다. 보조 클러스터에서는 Aurora Serverless v2 DB 인스턴스를 사용하면 됩니다. 그러면 보조 리전이 승격되어 애플리케이션의 워크로드를 인계할 경우 클러스터 용량이 확장될 수 있습니다.

기존 프로비저닝된 워크로드에 Aurora Serverless v2 사용 시작작

프로비저닝된 클러스터에서 이미 Aurora 애플리케이션이 실행 중이라고 가정합시다. 기존 클러스터에 리더 DB 인스턴스로 하나 이상의 Aurora Serverless v2 DB 인스턴스를 추가하여 애플리케이션이 Aurora Serverless v2와 어떻게 작동하는지 확인할 수 있습니다. 리더 DB 인스턴스가 얼마나 자주 확장 및 축소되는지 확인할 수 있습니다. Aurora 장애 조치 메커니즘을 사용하여 Aurora Serverless v2 DB 인스턴스가 라이터가 되도록 승격하고 읽기/쓰기 워크로드를 어떻게 처리하는지 확인합니다. 그러면 클라이언트 애플리케이션이 사용하는 엔드포인트를 변경하지 않고도 가동 중지 시간을 최소화하면서 전환할 수 있습니다. 기존 클러스터를 Aurora Serverless v2로 변환하는 절차에 대한 자세한 내용은 Aurora Serverless v2 시작하기 섹션을 참조하세요.

Aurora Serverless v2의 장점

Aurora Serverless v2는 가변 또는 '급증' 워크로드를 위한 것입니다. 예측할 수 없는 워크로드로 인해 데이터베이스 용량을 변경하는 시기를 계획하는 데 어려움이 있을 수 있습니다. 또한 DB 인스턴스 추가 또는 DB 인스턴스 클래스 변경과 같은 익숙한 메커니즘을 사용하여 용량을 빠르게 변경하는 데 문제가 있을 수 있습니다. Aurora Serverless v2는 이러한 사용 사례에 도움이 되도록 다음과 같은 이점을 제공합니다.

  • 프로비저닝된 클러스터보다 간편한 용량 관리 – Aurora Serverless v2를 사용하면 워크로드 변경에 따라 DB 인스턴스 크기를 계획하고 DB 인스턴스의 크기를 조정하기 위한 노력이 줄어듭니다. 또한 클러스터에 속한 모든 DB 인스턴스에 일관된 용량을 유지하기 위한 노력도 줄여줍니다.

  • 활동이 많은 기간 동안 더 빠르고 쉽게 확장 – Aurora Serverless v2는 클라이언트 트랜잭션이나 전체 워크로드에 영향을 주지 않고 필요에 따라 컴퓨팅 및 메모리 용량을 확장합니다. 리더 DB 인스턴스 Aurora Serverless v2와 함께 사용할 수 있으므로 수직 크기 조정뿐만 아니라 수평 크기 조정도 활용할 수 있습니다. Aurora 글로벌 데이터베이스를 사용할 수 있으므로 여러 개의 AWS 리전에 Aurora Serverless v2 읽기 워크로드를 분산할 수 있습니다. 이 기능은 프로비저닝된 클러스터의 크기 조정 메커니즘보다 편리합니다. 또한 Aurora Serverless v1의 크기 조정 기능보다 빠르고 세분화되어 있습니다.

  • 활동이 적은 기간 동안 비용 효율적 – Aurora Serverless v2는 DB 인스턴스의 오버프로비저닝을 예방합니다. Aurora Serverless v2는 DB 인스턴스의 크기를 확장할 때 리소스를 세분화된 단위로 추가합니다. 사용한 데이터베이스 리소스에 대해서만 요금을 지불합니다. Aurora Serverless v2 리소스 사용량은 초 단위로 측정됩니다. 따라서 DB 인스턴스가 축소되면 리소스 사용량 감소가 즉시 등록됩니다.

  • 프로비저닝된 클러스터로 향상된 기능 패리티 - Aurora Serverless v1에서는 사용할 수 없었던 다양한 Aurora 기능을 Aurora Serverless v2에서는 사용할 수 있습니다. 예를 들어 Aurora Serverless v2를 사용하면 리더 DB 인스턴스, 글로벌 데이터베이스, AWS Identity and Access Management(IAM) 데이터베이스 인증, 성능 개선 도우미를 사용할 수 있습니다. 사용할 수 있는 구성 매개 변수도 Aurora Serverless v1보다 많습니다.

    특히 Aurora Serverless v2를 사용하면 프로비저닝된 클러스터로부터 다음과 같은 기능을 활용할 수 있습니다.

    • 리더 DB 인스턴스 – Aurora Serverless v2는 리더 DB 인스턴스를 활용하여 수평으로 확장할 수 있습니다. 클러스터에 하나 이상의 리더 DB 인스턴스가 포함된 경우 라이터 DB 인스턴스에 문제가 발생하면 클러스터가 즉시 장애 조치를 할 수 있습니다. 이 기능은 Aurora Serverless v1에서는 사용할 수 없는 기능입니다.

    • 다중 AZ 클러스터 - 한 클러스터의 Aurora Serverless v2 DB 인스턴스를 여러 개의 가용 영역(AZ)에 배포할 수 있습니다. 다중 AZ 클러스터를 설정하면 드물게 전체 AZ에 영향을 주는 경우가 발생해도 비즈니스 연속성을 보장할 수 있습니다. 이 기능은 Aurora Serverless v1에서는 사용할 수 없는 기능입니다.

    • 글로벌 데이터베이스 - Aurora 글로벌 데이터베이스와 Aurora Serverless v2를 결합하여 재해 복구 목적으로 다른 AWS 리전에 클러스터의 읽기 전용 복사본을 생성할 수 있습니다.

    • RDS 프록시 – Amazon RDS Proxy를 사용하면 애플리케이션이 데이터베이스 연결을 풀링하고 공유하도록 허용하여 확장 기능을 향상할 수 있습니다.

  • 더 빠르고, 세밀하며, 중단이 적은 크기 조정Aurora Serverless v1 – Aurora Serverless v2는 더 빠르게 확장 및 축소할 수 있습니다. ACU 수를 두 배로 늘리거나 절반으로 줄이는 대신 0.5 단위로 ACU 용량을 변경하여 크기를 조정할 수 있습니다. 크기 조정은 일반적으로 처리를 일시 중지하지 않고 수행됩니다. 크기 조정에는 Aurora Serverless v1에서처럼 주의해야 할 이벤트가 포함되지 않습니다. 사용률이 낮은 시점을 기다릴 필요 없이 SQL 문이 실행 중이고 트랜잭션이 열려 있는 동안 크기 조정이 가능합니다.