AWS SAA 합격으로 가는 길 #8

안녕하세요, AWS SAA(Solution Architect Associate) 자격증을 준비하시는 여러분!

저는 넥스트클라우드에서 SA로 활동하고 있는 손유림이라고 합니다. 😊

 

문제는 세 가지 단계를 거치며 풀어나갈 거예요:

 

1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기

 

자, 그럼 첫 번째 문제부터 살펴볼까요?

---

문제

회사는 웹 사이트에서 항목의 검색 가능한 저장소를 유지 관리합니다.

데이터는 1,000만 개 이상의 행을 포함하는 Amazon RDS for MySQL 데이터베이스 테이블에 저장됩니다.

데이터베이스에는 2TB의 범용 SSD 스토리지가 있습니다.

회사 웹 사이트를 통해 매일 이 데이터에 대한 수백만 건의 업데이트가 있습니다.

회사는 일부 삽입 작업이 10초 이상 걸리는 것을 발견했습니다. 회사는 데이터베이스 스토리지 성능이 문제라고 판단했습니다.

이 성능 문제를 해결하는 솔루션은 무엇입니까?

선택지

1. 스토리지 유형을 프로비저닝된 IOPS SSD로 변경합니다.

2. DB 인스턴스를 메모리 최적화 인스턴스 클래스로 변경합니다.

3. DB 인스턴스를 버스트 가능한 성능 인스턴스 클래스로 변경합니다.

4. MySQL 기본 비동기 복제로 다중 AZ RDS 읽기 복제본을 활성화합니다.

---

요구사항에 맞는 서비스

1. 1000만 개 이상의 행을 포함하는 데이터베이스 테이블 관리

• Amazon RDS (Relational Database Service) : 관리형 관계형 데이터베이스 서비스로, MySQL을 포함한 여러 데이터베이스 엔진을 지원합니다. 1000만 개 이상의 행을 포함하는 대규모 데이터베이스를 효율적으로 관리할 수 있고, 데이터베이스의 자동 백업, 복원, 업데이트 등을 지원하여 운영 부담을 줄일 수 있어요.

2. 데이터베이스에 매일 수백만 건의 업데이트 처리

1. Amazon RDS with Provisioned IOPS (Input/Output Operations Per Second) : Amazon RDS에서 프로비저닝된 IOPS를 사용하면, 높은 성능이 요구되는 애플리케이션에서 매우 빠른 읽기/쓰기 작업을 지원할 수 있어요. 수백만 건의 업데이트가 이루어지는 환경에서 성능을 유지하기 위해 IOPS를 조정하여 처리량을 높일 수 있습니다.

3. 일부 삽입 작업이 10초 이상 걸림

• Amazon Aurora : MySQL과 호환되며, 높은 처리량을 제공하는 관계형 데이터베이스 서비스입니다. Aurora는 뛰어난 읽기/쓰기 성능을 제공하여 삽입 작업의 속도를 향상시킬 수 있습니다. 특히 복제 및 백업 작업에서 발생하는 지연 시간을 최소화하여 고성능 환경을 유지할 수 있어요.

4. 데이터베이스 스토리지 성능 문제 해결

• Amazon RDS with Provisioned IOPS : 프로비저닝된 IOPS는 스토리지 성능을 개선하여 대량의 읽기/쓰기 작업이 발생하는 환경에서 성능을 최적화합니다.
• Aurora with IO-Optimized : Amazon Aurora의 IO-Optimized 옵션을 사용하면, 입출력 작업에 최적화된 성능을 제공하여 스토리지 성능 문제를 해결할 수 있습니다.

최적의 정답 선택하기

선택지 1번은 “스토리지 유형을 프로비저닝된 IOPS SSD로 변경합니다.”입니다.

→ 이 선택지는 데이터베이스 스토리지 성능 문제를 직접적으로 해결할 수 있는 적절한 방법입니다. 프로비저닝된 IOPS SSD를 사용하면 데이터베이스의 I/O 성능을 크게 향상시킬 수 있으며, 이로 인해 삽입 작업의 지연 시간을 줄일 수 있어요. 따라서 이 선택지가 문제에서 제시된 성능 문제를 해결하는 데 가장 적합합니다.

 

선택지 2번은 “DB 인스턴스를 메모리 최적화 인스턴스 클래스로 변경합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 메모리 최적화 인스턴스는 데이터베이스의 메모리 사용을 최적화하는 데 도움이 되지만, 문제의 핵심인 스토리지 성능 문제를 해결하지는 못하기 때문입니다. 데이터베이스의 삽입 작업이 느려진 이유가 주로 스토리지 I/O 성능 문제라면, 이 선택지는 적절한 해결책이 되지 않습니다.

 

선택지 3번은 “DB 인스턴스를 버스트 가능한 성능 인스턴스 클래스로 변경합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 버스트 가능한 인스턴스 클래스는 CPU 성능에 집중되어 있으며, 지속적인 고성능을 제공하지 않기 때문입니다. 따라서 데이터베이스 스토리지의 I/O 성능 문제를 해결하는 데 적합하지 않으며, 삽입 작업의 지연 시간을 줄이는 데 효과적이지 않습니다.

 

선택지 4번은 “MySQL 기본 비동기 복제로 다중 AZ RDS 읽기 복제본을 활성화합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 다중 AZ 읽기 복제본은 주로 데이터베이스의 읽기 성능을 향상시키고 가용성을 높이는 데 사용되지만, 이 옵션은 데이터베이스 스토리지의 쓰기 성능 문제를 해결하지 못하기 때문입니다. 삽입 작업의 지연 시간을 줄이는 데는 적절한 해결책이 되지 않습니다.

 

 

문제에 대한 정답은 선택지 1번입니다!

자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 4가지의 요구사항이 존재해요. 

 

1. 1000만 개 이상의 행을 포함하는 데이터베이스 테이블 관리

2. 데이터베이스에 매일 수백만 건의 업데이트 처리

3. 일부 삽입 작업이 10초 이상 걸림

4. 데이터베이스 스토리지 성능 문제 해결

 

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 1000만 개 이상의 행을 포함하는 데이터베이스 테이블 관리

• Amazon RDS (Relational Database Service) : 관리형 관계형 데이터베이스 서비스로, MySQL을 포함한 여러 데이터베이스 엔진을 지원합니다. 1000만 개 이상의 행을 포함하는 대규모 데이터베이스를 효율적으로 관리할 수 있고, 데이터베이스의 자동 백업, 복원, 업데이트 등을 지원하여 운영 부담을 줄일 수 있어요.

2. 데이터베이스에 매일 수백만 건의 업데이트 처리

• Amazon RDS with Provisioned IOPS (Input/Output Operations Per Second) : 프로비저닝된 IOPS를 사용하면, 높은 성능이 요구되는 애플리케이션에서 매우 빠른 읽기/쓰기 작업을 지원할 수 있어요. 수백만 건의 업데이트가 이루어지는 환경에서 성능을 유지하기 위해 IOPS를 조정하여 처리량을 높일 수 있습니다.

3. 일부 삽입 작업이 10초 이상 걸림

• Amazon Aurora : Amazon Aurora는 MySQL과 호환되며, 높은 처리량을 제공하는 관계형 데이터베이스 서비스입니다. Aurora는 뛰어난 읽기/쓰기 성능을 제공하여 삽입 작업의 속도를 향상시킬 수 있습니다. 특히 복제 및 백업 작업에서 발생하는 지연 시간을 최소화하여 고성능 환경을 유지할 수 있어요.

4. 데이터베이스 스토리지 성능 문제 해결

• Amazon RDS with Provisioned IOPS : 프로비저닝된 IOPS는 스토리지 성능을 개선하여 대량의 읽기/쓰기 작업이 발생하는 환경에서 성능을 최적화합니다.
• Aurora with IO-Optimized : Amazon Aurora의 IO-Optimized 옵션을 사용하면, 입출력 작업에 최적화된 성능을 제공하여 스토리지 성능 문제를 해결할 수 있습니다.

 

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 “스토리지 유형을 프로비저닝된 IOPS SSD로 변경합니다.”입니다.

 

• 프로비저닝된 IOPS SSD: 높은 성능이 필요한 애플리케이션에서 일관된 I/O 성능을 제공합니다. 프로비저닝된 IOPS는 데이터베이스의 읽기 및 쓰기 작업의 속도를 높이는 데 매우 효과적입니다. 특히, 많은 수의 읽기 및 쓰기 작업을 빠르게 처리해야 하는 경우 유용해요.

이 선택지는 데이터베이스 스토리지 성능 문제를 직접적으로 해결할 수 있는 적절한 방법입니다. 프로비저닝된 IOPS SSD를 사용하면 데이터베이스의 I/O 성능을 크게 향상시킬 수 있으며, 이로 인해 삽입 작업의 지연 시간을 줄일 수 있어요. 따라서 이 선택지가 문제에서 제시된 성능 문제를 해결하는 데 가장 적합합니다.

 

선택지 2번은 “DB 인스턴스를 메모리 최적화 인스턴스 클래스로 변경합니다.”입니다.

 

• 메모리 최적화 인스턴스 클래스: 높은 메모리 용량을 제공하여 메모리 내 데이터베이스나 캐싱을 활용한 워크로드에 적합합니다. 그러나 스토리지 성능 문제를 직접 해결하는 데는 적합하지 않을 수 있습니다.

이 선택지가 정답이 아닌 이유는 메모리 최적화 인스턴스는 데이터베이스의 메모리 사용을 최적화하는 데 도움이 되지만, 문제의 핵심인 스토리지 성능 문제를 해결하지는 못하기 때문입니다. 데이터베이스의 삽입 작업이 느려진 이유가 주로 스토리지 I/O 성능 문제라면, 이 선택지는 적절한 해결책이 되지 않습니다.

 

선택지 3번은 “DB 인스턴스를 버스트 가능한 성능 인스턴스 클래스로 변경합니다.”입니다.

 

• 버스트 가능한 성능 인스턴스 클래스: 일시적으로 높은 CPU 성능이 필요한 워크로드를 처리할 수 있도록 설계되었습니다. 그러나 이러한 인스턴스는 일관된 고성능을 제공하지 않으며, 데이터베이스의 I/O 성능 문제를 해결하는 데는 적합하지 않습니다.

이 선택지가 정답이 아닌 이유는 버스트 가능한 인스턴스 클래스는 CPU 성능에 집중되어 있으며, 지속적인 고성능을 제공하지 않기 때문입니다. 따라서 데이터베이스 스토리지의 I/O 성능 문제를 해결하는 데 적합하지 않으며, 삽입 작업의 지연 시간을 줄이는 데 효과적이지 않습니다.

 

선택지 4번은 “MySQL 기본 비동기 복제로 다중 AZ RDS 읽기 복제본을 활성화합니다.”입니다.

• 다중 AZ RDS 읽기 복제본: 가용성을 높이고 장애 조치(failover) 시 고가용성을 제공하지만, 데이터베이스 스토리지 성능 문제를 직접적으로 해결하지는 않습니다. 이 설정은 주로 읽기 트래픽을 분산하는 데 유용해요.

이 선택지가 정답이 아닌 이유는 다중 AZ 읽기 복제본은 주로 데이터베이스의 읽기 성능을 향상시키고 가용성을 높이는 데 사용되지만, 이 옵션은 데이터베이스 스토리지의 쓰기 성능 문제를 해결하지 못하기 때문입니다. 삽입 작업의 지연 시간을 줄이는 데는 적절한 해결책이 되지 않습니다.

 

 

이어서 두 번째 문제 살펴볼게요.

---

문제

회사에서 UDP 연결을 사용하는 VoIP(Voice over Internet Protocol) 서비스를 제공합니다.

이 서비스는 Auto Scaling 그룹에서 실행되는 Amazon EC2 인스턴스로 구성됩니다.

이 회사는 여러 AWS 지역에 배포했습니다.

회사는 지연 시간이 가장 짧은 리전으로 사용자를 라우팅해야 합니다.

회사는 또한 리전 간에 자동화된 장애 조치가 필요합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

선택지

1. NLB(Network Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 리전에서 NLB를 AWS Global Accelerator 엔드포인트로 사용합니다.

2. ALB(Application Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 리전에서 ALB를 AWS Global Accelerator 엔드포인트로 사용합니다.

3. NLB(Network Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 NLB의 별칭을 가리키는 Amazon Route 53 지연 시간 레코드를 생성합니다. 지연 시간 레코드를 오리진으로 사용하는 Amazon CloudFront 배포를 생성합니다.

4. ALB(Application Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 ALB의 별칭을 가리키는 Amazon Route 53 가중치 레코드를 생성합니다. 가중 레코드를 오리진으로 사용하는 Amazon CloudFront 배포를 배포합니다.

---

요구사항에 맞는 서비스

1. 지연 시간이 가장 짧은 리전으로 사용자를 라우팅

• Amazon Route 53 : 고가용성과 확장성을 제공하는 DNS 웹 서비스로, 레이턴시 기반 라우팅(Latency-Based Routing) 기능을 통해 트래픽을 지연 시간이 가장 짧은 리전으로 라우팅할 수 있습니다. 이 기능은 사용자 요청을 가장 빠르게 처리할 수 있는 리전으로 보내어 VoIP 서비스의 성능을 최적화합니다.
• AWS Global Accelerator : 전 세계적으로 애플리케이션의 가용성과 성능을 개선하는 서비스로, AWS 글로벌 네트워크를 통해 사용자의 트래픽을 최적의 경로로 라우팅합니다. 이는 지연 시간을 최소화하고, 사용자를 가장 가까운 AWS 리전으로 연결하여 VoIP 서비스의 지연 시간을 줄이는 데 효과적입니다. 

2. 리전 간 자동화된 장애 조치 필요

• Elastic Load Balancing (ELB)
  • Network Load Balancer (NLB): 낮은 지연 시간을 요구하는 UDP 트래픽을 효율적으로 처리할 수 있는 로드 밸런서로, VoIP 서비스에 적합합니다. NLB는 각 리전에 걸쳐 트래픽을 분산시키고, 장애가 발생한 인스턴스를 감지하여 자동으로 트래픽을 다른 건강한 인스턴스로 라우팅합니다.
  • Application Load Balancer (ALB): 상태 확인을 통해 비정상적인 인스턴스를 자동으로 제거하고, 트래픽을 건강한 리전으로 라우팅합니다. ALB는 HTTP/HTTPS 기반의 트래픽에 최적화되어 있지만, UDP 트래픽을 사용하는 VoIP 서비스의 경우 NLB가 더 적합해요.
• AWS Auto Scaling : 자동으로 조정하여 트래픽 변화에 따라 리소스를 확장하거나 축소할 수 있습니다. 다중 리전에 걸쳐 Auto Scaling 그룹을 구성하면, 특정 리전에 장애가 발생하더라도 다른 리전에서 자동으로 인스턴스를 시작하여 서비스의 연속성을 유지할 수 있습니다. 이는 리전 간 자동화된 장애 조치를 구현하는 데 매우 효과적입니다.
• Amazon Route 53 : DNS 장애 조치(DNS Failover) 기능을 통해 특정 리전이나 가용 영역이 비정상적으로 작동하는 경우 트래픽을 다른 건강한 리전으로 자동으로 라우팅할 수 있습니다. 상태 확인을 통해 리전의 상태를 지속적으로 모니터링하고, 장애 발생 시 자동으로 다른 리전으로 트래픽을 재분배할 수 있습니다.
• AWS Global Accelerator : 단일 고정 IP 주소 세트를 제공하여, 애플리케이션이 중단되었을 때 다른 리전으로 트래픽을 자동으로 리디렉션합니다. 이는 장애 조치 시에도 사용자가 서비스에 지속적으로 접근할 수 있도록 보장해요.

최적의 정답 선택하기

선택지 1번은 “NLB(Network Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 리전에서 NLB를 AWS Global Accelerator 엔드포인트로 사용합니다.”입니다.

→ 이 선택지는 VoIP 서비스의 저지연 요구사항과 리전 간 자동 장애 조치를 모두 충족합니다. NLB는 UDP 트래픽을 효율적으로 처리하며, Global Accelerator는 전 세계 사용자에게 최적의 경로로 트래픽을 전달하여 지연 시간을 최소화하고 장애 발생 시 신속한 복구를 보장합니다. 따라서 VoIP 서비스에 가장 적합한 선택입니다.

 

선택지 2번은 “ALB(Application Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 리전에서 ALB를 AWS Global Accelerator 엔드포인트로 사용합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 ALB는 HTTP/HTTPS 기반의 트래픽에 최적화되어 있으므로, UDP 기반의 VoIP 서비스에는 부적합하기 때문입니다. VoIP와 같은 실시간 통신에는 TCP/UDP 트래픽 처리에 최적화된 NLB가 더 적합합니다.

 

선택지 3번은 “NLB(Network Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 NLB의 별칭을 가리키는 Amazon Route 53 지연 시간 레코드를 생성합니다. 지연 시간 레코드를 오리진으로 사용하는 Amazon CloudFront 배포를 생성합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 CloudFront는 주로 정적 콘텐츠 배포와 캐싱에 사용되며, 실시간 트래픽을 처리하는 데는 적합하지 않기 때문입니다. VoIP 서비스는 실시간 통신을 필요로 하므로, CloudFront를 사용하는 것은 부적절합니다. NLB와 Route 53의 조합은 적절하지만, CloudFront가 추가됨으로써 VoIP 서비스의 실시간 성능을 저하시킬 수 있습니다.

 

선택지 4번은 “ALB(Application Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 ALB의 별칭을 가리키는 Amazon Route 53 가중치 레코드를 생성합니다. 가중 레코드를 오리진으로 사용하는 Amazon CloudFront 배포를 배포합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 ALB와 CloudFront는 VoIP 서비스의 실시간 UDP 트래픽을 처리하기에 적합하지 않기 때문입니다. ALB는 HTTP/HTTPS 트래픽에 최적화되어 있고, CloudFront는 주로 정적 콘텐츠 배포에 사용되므로, VoIP 서비스와 같은 실시간 통신에는 적합하지 않습니다. 이 조합은 VoIP 서비스의 실시간 성능을 보장하지 못합니다.

 

 

문제에 대한 정답은 선택지 1번입니다!

자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 2가지의 요구사항이 존재해요. 

 

1. 지연 시간이 가장 짧은 리전으로 사용자를 라우팅

2. 리전 간 자동화된 장애 조치 필요

 

"리전"

→ 최소 2개 이상의 가용 영역(Availability Zone, AZ)으로 구성된 지리적 영역을 말해요.

"가용 영역"

→ 하나 이상의 개별 데이터 센터를 의미합니다.

 

쉽게 말해서, 사용자들이 항상 가장 빠른 응답을 받을 수 있도록, 그들의 위치에서 가장 가까운 데이터 센터로 자동으로 연결해 줘야 해요. 만약 어떤 지역의 데이터 센터에 문제가 생기면 즉시 다른 정상 작동 중인 데이터 센터로 서비스를 옮겨 사용자들이 중단 없이 계속 서비스를 이용할 수 있게 하는 시스템이 필요한 거예요.

 

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 지연 시간이 가장 짧은 리전으로 사용자를 라우팅

• Amazon Route 53 : 고가용성과 확장성을 제공하는 DNS 웹 서비스로, 레이턴시 기반 라우팅(Latency-Based Routing) 기능을 통해 트래픽을 지연 시간이 가장 짧은 리전으로 라우팅할 수 있습니다. 이 기능은 사용자 요청을 가장 빠르게 처리할 수 있는 리전으로 보내어 VoIP 서비스의 성능을 최적화합니다.
• AWS Global Accelerator : 전 세계적으로 애플리케이션의 가용성과 성능을 개선하는 서비스로, AWS 글로벌 네트워크를 통해 사용자의 트래픽을 최적의 경로로 라우팅합니다. 이는 지연 시간을 최소화하고, 사용자를 가장 가까운 AWS 리전으로 연결하여 VoIP 서비스의 지연 시간을 줄이는 데 효과적입니다. 

2. 리전 간 자동화된 장애 조치 필요

• Elastic Load Balancing (ELB)
  • Network Load Balancer (NLB): 낮은 지연 시간을 요구하는 UDP 트래픽을 효율적으로 처리할 수 있는 로드 밸런서로, VoIP 서비스에 적합합니다. NLB는 각 리전에 걸쳐 트래픽을 분산시키고, 장애가 발생한 인스턴스를 감지하여 자동으로 트래픽을 다른 건강한 인스턴스로 라우팅합니다.
  • Application Load Balancer (ALB): 상태 확인을 통해 비정상적인 인스턴스를 자동으로 제거하고, 트래픽을 건강한 리전으로 라우팅합니다. ALB는 HTTP/HTTPS 기반의 트래픽에 최적화되어 있지만, UDP 트래픽을 사용하는 VoIP 서비스의 경우 NLB가 더 적합해요.
• AWS Auto Scaling : 자동으로 조정하여 트래픽 변화에 따라 리소스를 확장하거나 축소할 수 있습니다. 다중 리전에 걸쳐 Auto Scaling 그룹을 구성하면, 특정 리전에 장애가 발생하더라도 다른 리전에서 자동으로 인스턴스를 시작하여 서비스의 연속성을 유지할 수 있습니다. 이는 리전 간 자동화된 장애 조치를 구현하는 데 매우 효과적입니다.
• Amazon Route 53 : DNS 장애 조치(DNS Failover) 기능을 통해 특정 리전이나 가용 영역이 비정상적으로 작동하는 경우 트래픽을 다른 건강한 리전으로 자동으로 라우팅할 수 있습니다. 상태 확인을 통해 리전의 상태를 지속적으로 모니터링하고, 장애 발생 시 자동으로 다른 리전으로 트래픽을 재분배할 수 있습니다.
• AWS Global Accelerator : 단일 고정 IP 주소 세트를 제공하여, 애플리케이션이 중단되었을 때 다른 리전으로 트래픽을 자동으로 리디렉션합니다. 이는 장애 조치 시에도 사용자가 서비스에 지속적으로 접근할 수 있도록 보장해요.

 

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 “NLB(Network Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 리전에서 NLB를 AWS Global Accelerator 엔드포인트로 사용합니다.”입니다.

 

• NLB (Network Load Balancer): 낮은 지연 시간과 높은 처리량을 제공하는 로드 밸런서로, TCP 및 UDP 트래픽을 처리하는 데 최적화되어 있습니다. VoIP 서비스와 같이 지연 시간이 중요한 UDP 트래픽을 안정적으로 처리할 수 있습니다.
• AWS Global Accelerator: 트래픽을 AWS 글로벌 네트워크를 통해 가장 가까운 리전으로 라우팅하여 지연 시간을 최소화합니다. 또한, 장애 발생 시 트래픽을 자동으로 다른 건강한 리전으로 리디렉션하여 고가용성을 보장합니다.

이 선택지는 VoIP 서비스의 저지연 요구사항과 리전 간 자동 장애 조치를 모두 충족합니다. NLB는 UDP 트래픽을 효율적으로 처리하며, Global Accelerator는 전 세계 사용자에게 최적의 경로로 트래픽을 전달하여 지연 시간을 최소화하고 장애 발생 시 신속한 복구를 보장합니다. 따라서 VoIP 서비스에 가장 적합한 선택입니다.

 

선택지 2번은 “ALB(Application Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 리전에서 ALB를 AWS Global Accelerator 엔드포인트로 사용합니다.”입니다.

 

• ALB (Application Load Balancer): HTTP 및 HTTPS 트래픽에 최적화된 로드 밸런서로, 7계층에서의 고급 라우팅 기능을 제공합니다. 그러나 ALB는 TCP/UDP 트래픽보다는 애플리케이션 계층 트래픽에 적합합니다.
• AWS Global Accelerator: 트래픽을 가장 가까운 리전으로 라우팅하고, 장애 발생 시 자동으로 다른 리전으로 트래픽을 리디렉션합니다.

이 선택지가 정답이 아닌 이유는 ALB는 HTTP/HTTPS 기반의 트래픽에 최적화되어 있으므로, UDP 기반의 VoIP 서비스에는 부적합하기 때문입니다. VoIP와 같은 실시간 통신에는 TCP/UDP 트래픽 처리에 최적화된 NLB가 더 적합합니다.

 

선택지 3번은 “NLB(Network Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 NLB의 별칭을 가리키는 Amazon Route 53 지연 시간 레코드를 생성합니다. 지연 시간 레코드를 오리진으로 사용하는 Amazon CloudFront 배포를 생성합니다.”입니다.

 

• NLB (Network Load Balancer): UDP 트래픽에 최적화된 로드 밸런서로, VoIP 서비스의 실시간 통신을 처리하는 데 적합합니다.
• Amazon Route 53: AWS의 관리형 DNS 서비스로, 지연 시간 기반 라우팅을 통해 사용자를 가장 가까운 리전으로 라우팅할 수 있습니다. 이는 VoIP 서비스의 성능을 최적화하는 데 도움이 됩니다.
• Amazon CloudFront: 전 세계에 분산된 엣지 로케이션을 통해 콘텐츠를 캐싱하고, 사용자가 요청한 콘텐츠를 제공하는 콘텐츠 배포 네트워크(CDN)입니다. 주로 정적 콘텐츠 배포에 사용되며, 실시간 트래픽 처리에는 적합하지 않습니다.

이 선택지가 정답이 아닌 이유는 CloudFront는 주로 정적 콘텐츠 배포와 캐싱에 사용되며, 실시간 트래픽을 처리하는 데는 적합하지 않기 때문입니다. VoIP 서비스는 실시간 통신을 필요로 하므로, CloudFront를 사용하는 것은 부적절합니다. NLB와 Route 53의 조합은 적절하지만, CloudFront가 추가됨으로써 VoIP 서비스의 실시간 성능을 저하시킬 수 있습니다.

 

선택지 4번은 “ALB(Application Load Balancer) 및 연결된 대상 그룹을 배포합니다. 대상 그룹을 Auto Scaling 그룹과 연결합니다. 각 ALB의 별칭을 가리키는 Amazon Route 53 가중치 레코드를 생성합니다. 가중 레코드를 오리진으로 사용하는 Amazon CloudFront 배포를 배포합니다.”입니다.

 

• ALB (Application Load Balancer): 애플리케이션 계층에서 고급 라우팅 기능을 제공하며, HTTP/HTTPS 트래픽에 최적화되어 있습니다.
• Amazon Route 53: 가중치 기반 라우팅을 사용하여 트래픽을 여러 리전으로 분산시킬 수 있습니다. 가중치 기반 라우팅은 트래픽을 특정 비율로 여러 엔드포인트로 분산하는 데 유용합니다.
• Amazon CloudFront: 전 세계적으로 콘텐츠를 배포하고, 엣지 로케이션에서 캐시된 콘텐츠를 제공하는 콘텐츠 배포 네트워크입니다. 주로 정적 콘텐츠 배포에 사용되며, 실시간 트래픽 처리에는 적합하지 않습니다.

이 선택지가 정답이 아닌 이유는 ALB와 CloudFront는 VoIP 서비스의 실시간 UDP 트래픽을 처리하기에 적합하지 않기 때문입니다. ALB는 HTTP/HTTPS 트래픽에 최적화되어 있고, CloudFront는 주로 정적 콘텐츠 배포에 사용되므로, VoIP 서비스와 같은 실시간 통신에는 적합하지 않습니다. 이 조합은 VoIP 서비스의 실시간 성능을 보장하지 못합니다.

 

 

마지막 문제 살펴볼게요.

---

문제

회사에는 매일 총 1TB의 상태 알림을 생성하는 수천 개의 에지 장치가 있습니다.

각 알림의 크기는 약 2KB입니다.

솔루션 설계자는 향후 분석을 위해 경고를 수집하고 저장하는 솔루션을 구현해야 합니다.

회사는 고가용성 솔루션을 원합니다.

그러나 회사는 비용을 최소화해야 하며 추가 인프라를 관리하기를 원하지 않습니다.

또한 회사는 즉각적인 분석을 위해 14일간의 데이터를 유지하고 14일보다 오래된 모든 데이터를 보관하기를 원합니다.

이러한 요구 사항을 충족하는 운영상 가장 효율적인 솔루션은 무엇입니까?

선택지

1. Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon S3 버킷에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.

2. 두 가용 영역에서 Amazon EC2 인스턴스를 시작하고 이를 Elastic Load Balancer 뒤에 배치하여 알림을 수집합니다. Amazon S3 버킷에 알림을 저장할 EC2 인스턴스에서 스크립트를 생성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.

3. Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 매일 수동 스냅샷을 생성하고 14일보다 오래된 클러스터에서 데이터를 삭제하도록 Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터를 설정합니다.

4. 알림을 수집할 Amazon Simple Queue Service(Amazon SQS) 표준 대기열을 생성하고 메시지 보존 기간을 14일로 설정합니다. 소비자가 SQS 대기열을 폴링하고 메시지 수명을 확인하고 필요에 따라 메시지 데이터를 분석하도록 구성합니다. 메시지가 14일이 지난 경우 소비자는 메시지를 Amazon S3 버킷에 복사하고 SQS 대기열에서 메시지를 삭제해야 합니다.

---

요구사항에 맞는 서비스

1. 수천 개의 에지 장치에서 매일 1TB의 상태 알림을 고가용성으로 수집 및 저장

• Amazon Kinesis Data Streams : 실시간으로 대규모 데이터를 안정적으로 수집, 처리, 분석할 수 있는 서비스입니다. 수천 개의 에지 장치에서 생성되는 대량의 데이터를 빠르고 신뢰성 있게 스트리밍할 수 있으며, 고가용성을 보장합니다. 데이터는 다양한 애플리케이션으로 스트리밍되어 실시간으로 처리될 수 있습니다.
• Amazon S3 (Simple Storage Service) : 확장 가능한 객체 스토리지 서비스로, 수집된 데이터를 안전하게 저장하고 고가용성을 제공합니다. 데이터를 S3에 저장함으로써, 쉽게 접근할 수 있고 다양한 AWS 서비스와 통합하여 분석 및 보관 작업을 수행할 수 있습니다. S3는 데이터의 내구성을 보장하며, 다양한 스토리지 클래스를 통해 비용을 효율적으로 관리할 수 있습니다.

2. 비용을 최소화하고 추가 인프라 관리를 피할 수 있는 솔루션 요구

• AWS Lambda : 서버리스 컴퓨팅 서비스로, 이벤트에 따라 코드를 자동으로 실행합니다. 인프라를 관리할 필요가 없고, 사용한 만큼만 비용을 지불하기 때문에 비용 효율적입니다. Lambda를 사용하면 Kinesis Data Streams에서 데이터를 처리하거나 S3에 저장된 데이터를 분석할 수 있습니다.
• Amazon S3 (Intelligent-Tiering 및 Glacier) : 비용 최적화를 위해 여러 스토리지 클래스를 제공합니다. Intelligent-Tiering을 사용하면 데이터 접근 패턴에 따라 자동으로 비용 효율적인 스토리지 클래스로 데이터를 이동시킬 수 있습니다. 14일 이상 된 데이터를 보관할 경우, 비용을 줄이기 위해 S3 Glacier로 데이터를 이동시킬 수 있습니다.

3. 14일간의 데이터를 즉각적인 분석을 위해 유지하고, 14일보다 오래된 데이터를 보관

• Amazon S3 with Lifecycle Policies : S3 수명 주기 정책(Lifecycle Policies)을 설정하여, 14일 동안의 데이터를 S3의 표준 스토리지 클래스에 유지하고, 14일 이후의 데이터를 S3 Glacier 또는 Glacier Deep Archive로 자동으로 이동시킬 수 있습니다. 이 기능은 데이터를 보관하고 비용을 최적화하는 데 도움이 됩니다.
• Amazon Athena : S3에 저장된 데이터를 직접 쿼리할 수 있는 서버리스 서비스입니다. 즉각적인 분석이 필요한 경우, 14일간의 데이터를 S3에 저장하고 Athena를 통해 SQL 쿼리를 실행하여 데이터를 분석할 수 있습니다. 이는 추가적인 인프라 관리 없이 데이터를 분석할 수 있는 매우 효율적인 방법입니다.

최적의 정답 선택하기

선택지 1번은 “Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon S3 버킷에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.”입니다.

→ 이 선택지는 Kinesis Data Firehose를 사용하여 알림을 효율적으로 수집하고, S3에 저장한 후 14일 후에 데이터를 자동으로 S3 Glacier로 이동시킴으로써 비용을 절감할 수 있습니다. 또한, 완전 관리형 서비스들을 활용함으로써 추가적인 인프라 관리가 필요하지 않으며, 고가용성을 보장합니다. 이 솔루션은 회사의 요구사항을 충족하는 가장 효율적인 방법입니다.

 

선택지 2번은 “두 가용 영역에서 Amazon EC2 인스턴스를 시작하고 이를 Elastic Load Balancer 뒤에 배치하여 알림을 수집합니다. Amazon S3 버킷에 알림을 저장할 EC2 인스턴스에서 스크립트를 생성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 고가용성을 제공할 수 있지만, EC2 인스턴스와 ELB를 관리해야 하므로 인프라 관리 부담이 크고 비용이 증가할 수 있기 때문입니다. 추가 인프라를 관리하지 않고 비용을 최소화하려는 요구사항에 적합하지 않습니다.

 

선택지 3번은 "Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 매일 수동 스냅샷을 생성하고 14일보다 오래된 클러스터에서 데이터를 삭제하도록 Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터를 설정합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 OpenSearch Service는 대규모 데이터의 실시간 검색과 분석에 적합하지만, 매일 수동 스냅샷을 생성하고 데이터를 관리하는 것은 추가적인 운영 오버헤드를 발생시키기 때문입니다. 이 솔루션은 비용을 최소화하고 인프라 관리를 피하려는 요구사항을 충족하지 못합니다.

 

선택지 4번은 “알림을 수집할 Amazon Simple Queue Service(Amazon SQS) 표준 대기열을 생성하고 메시지 보존 기간을 14일로 설정합니다. 소비자가 SQS 대기열을 폴링하고 메시지 수명을 확인하고 필요에 따라 메시지 데이터를 분석하도록 구성합니다. 메시지가 14일이 지난 경우 소비자는 메시지를 Amazon S3 버킷에 복사하고 SQS 대기열에서 메시지를 삭제해야 합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 SQS는 메시지 큐 서비스로서 데이터의 장기 보관보다는 일시적 보관에 더 적합하기 때문입니다. 또한, SQS 대기열에서 데이터를 수동으로 관리하고 이동하는 것은 운영 오버헤드가 크며, 14일이 지난 데이터를 수동으로 처리하는 방식은 비효율적일 수 있습니다. 이 솔루션은 고가용성과 비용 효율성을 동시에 달성하는 데 적합하지 않습니다.

 

 

문제에 대한 정답은 선택지 1번입니다!

자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 3가지의 요구사항이 존재해요. 

 

1. 수천 개의 에지 장치에서 매일 1TB의 상태 알림을 고가용성으로 수집 및 저장

2. 비용을 최소화하고 추가 인프라 관리를 피할 수 있는 솔루션 요구

3. 14일간의 데이터를 즉각적인 분석을 위해 유지하고, 14일보다 오래된 데이터를 보관

 

"가용성"

→ 시스템이나 서비스가 지속적으로 안정적인 서비스를 제공 가능한 상태를 유지하는 특성을 말해요. 시스템이 "항상 작동하는 상태"를 목표로 하는 거죠. 고가용성이란 장애가 발생하더라도 빠르게 복구되어 전체 시스템 운영에 미치는 영향을 최소화함으로써 사용자들이 서비스를 계속 원할하게 이용할 수 있도록 유지하게 하는 것입니다. 

 

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 수천 개의 에지 장치에서 매일 1TB의 상태 알림을 고가용성으로 수집 및 저장

• Amazon Kinesis Data Streams : 실시간으로 대규모 데이터를 안정적으로 수집, 처리, 분석할 수 있는 서비스입니다. 수천 개의 에지 장치에서 생성되는 대량의 데이터를 빠르고 신뢰성 있게 스트리밍할 수 있으며, 고가용성을 보장합니다. 데이터는 다양한 애플리케이션으로 스트리밍되어 실시간으로 처리될 수 있습니다.
• Amazon S3 (Simple Storage Service) : 확장 가능한 객체 스토리지 서비스로, 수집된 데이터를 안전하게 저장하고 고가용성을 제공합니다. 데이터를 S3에 저장함으로써, 쉽게 접근할 수 있고 다양한 AWS 서비스와 통합하여 분석 및 보관 작업을 수행할 수 있습니다. S3는 데이터의 내구성을 보장하며, 다양한 스토리지 클래스를 통해 비용을 효율적으로 관리할 수 있습니다.

2. 비용을 최소화하고 추가 인프라 관리를 피할 수 있는 솔루션 요구

• AWS Lambda : 서버리스 컴퓨팅 서비스로, 이벤트에 따라 코드를 자동으로 실행합니다. 인프라를 관리할 필요가 없고, 사용한 만큼만 비용을 지불하기 때문에 비용 효율적입니다. Lambda를 사용하면 Kinesis Data Streams에서 데이터를 처리하거나 S3에 저장된 데이터를 분석할 수 있습니다.
• Amazon S3 (Intelligent-Tiering 및 Glacier) : 비용 최적화를 위해 여러 스토리지 클래스를 제공합니다. Intelligent-Tiering을 사용하면 데이터 접근 패턴에 따라 자동으로 비용 효율적인 스토리지 클래스로 데이터를 이동시킬 수 있습니다. 14일 이상 된 데이터를 보관할 경우, 비용을 줄이기 위해 S3 Glacier로 데이터를 이동시킬 수 있습니다.

3. 14일간의 데이터를 즉각적인 분석을 위해 유지하고, 14일보다 오래된 데이터를 보관

• Amazon S3 with Lifecycle Policies : S3 수명 주기 정책(Lifecycle Policies)을 설정하여, 14일 동안의 데이터를 S3의 표준 스토리지 클래스에 유지하고, 14일 이후의 데이터를 S3 Glacier 또는 Glacier Deep Archive로 자동으로 이동시킬 수 있습니다. 이 기능은 데이터를 보관하고 비용을 최적화하는 데 도움이 됩니다.
• Amazon Athena : S3에 저장된 데이터를 직접 쿼리할 수 있는 서버리스 서비스입니다. 즉각적인 분석이 필요한 경우, 14일간의 데이터를 S3에 저장하고 Athena를 통해 SQL 쿼리를 실행하여 데이터를 분석할 수 있습니다. 이는 추가적인 인프라 관리 없이 데이터를 분석할 수 있는 매우 효율적인 방법입니다.

 

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 “Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon S3 버킷에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.”입니다.

 

• Amazon Kinesis Data Firehose: 실시간으로 데이터를 수집하고 변환하여 다양한 AWS 서비스(S3, Redshift, Elasticsearch 등)로 전달할 수 있는 완전 관리형 서비스입니다. Kinesis Data Firehose는 데이터를 자동으로 배치하고, 손쉽게 수집 및 전달할 수 있어 추가적인 인프라 관리가 필요하지 않습니다.
• Amazon S3: 확장성이 뛰어난 객체 스토리지 서비스로, 데이터를 안전하게 저장할 수 있습니다. 또한, S3는 다양한 스토리지 클래스를 제공하여 비용을 최적화할 수 있습니다.
• Amazon S3 Glacier: 장기 데이터 보관을 위한 저비용 스토리지 서비스입니다. S3 수명 주기 정책을 통해 데이터를 자동으로 Glacier로 이동시킬 수 있습니다. 

이 선택지는 Kinesis Data Firehose를 사용하여 알림을 효율적으로 수집하고, S3에 저장한 후 14일 후에 데이터를 자동으로 S3 Glacier로 이동시킴으로써 비용을 절감할 수 있습니다. 또한, 완전 관리형 서비스들을 활용함으로써 추가적인 인프라 관리가 필요하지 않으며, 고가용성을 보장합니다. 이 솔루션은 회사의 요구사항을 충족하는 가장 효율적인 방법입니다.

 

선택지 2번은 “두 가용 영역에서 Amazon EC2 인스턴스를 시작하고 이를 Elastic Load Balancer 뒤에 배치하여 알림을 수집합니다. Amazon S3 버킷에 알림을 저장할 EC2 인스턴스에서 스크립트를 생성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.”입니다.

 

• Amazon EC2: 클라우드에서 확장 가능한 컴퓨팅 용량을 제공하는 서비스로, 사용자가 직접 인스턴스를 설정하고 관리할 수 있습니다.
• Elastic Load Balancer (ELB): 여러 EC2 인스턴스에 트래픽을 자동으로 분산시켜 고가용성을 제공합니다.
• Amazon S3: 데이터를 안전하게 저장할 수 있는 확장성 있는 객체 스토리지 서비스입니다.
• Amazon S3 Glacier: 장기 데이터 보관을 위한 저비용 스토리지 서비스입니다.

이 선택지가 정답이 아닌 이유는 고가용성을 제공할 수 있지만, EC2 인스턴스와 ELB를 관리해야 하므로 인프라 관리 부담이 크고 비용이 증가할 수 있기 때문입니다. 추가 인프라를 관리하지 않고 비용을 최소화하려는 요구사항에 적합하지 않습니다.

 

선택지 3번은 "Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 매일 수동 스냅샷을 생성하고 14일보다 오래된 클러스터에서 데이터를 삭제하도록 Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터를 설정합니다.”입니다.

 

• Amazon Kinesis Data Firehose: 실시간 데이터 스트리밍 서비스로, 데이터를 다양한 AWS 서비스로 자동 전달할 수 있습니다.
• Amazon OpenSearch Service: Elasticsearch를 관리형으로 제공하여, 대규모 데이터의 실시간 검색, 분석 및 시각화를 지원합니다. OpenSearch는 데이터를 인덱싱하고 검색하는 데 최적화되어 있습니다.

이 선택지가 정답이 아닌 이유는 OpenSearch Service는 대규모 데이터의 실시간 검색과 분석에 적합하지만, 매일 수동 스냅샷을 생성하고 데이터를 관리하는 것은 추가적인 운영 오버헤드를 발생시키기 때문입니다. 이 솔루션은 비용을 최소화하고 인프라 관리를 피하려는 요구사항을 충족하지 못합니다.

 

선택지 4번은 “알림을 수집할 Amazon Simple Queue Service(Amazon SQS) 표준 대기열을 생성하고 메시지 보존 기간을 14일로 설정합니다. 소비자가 SQS 대기열을 폴링하고 메시지 수명을 확인하고 필요에 따라 메시지 데이터를 분석하도록 구성합니다. 메시지가 14일이 지난 경우 소비자는 메시지를 Amazon S3 버킷에 복사하고 SQS 대기열에서 메시지를 삭제해야 합니다.”입니다.

 

• Amazon SQS (Simple Queue Service): 분산된 애플리케이션 간 메시지를 전달하는 메시지 큐 서비스로, 데이터를 일시적으로 보관하고 처리할 수 있습니다.
• Amazon S3: 데이터를 안전하게 저장할 수 있는 객체 스토리지 서비스입니다.

이 선택지가 정답이 아닌 이유는 SQS는 메시지 큐 서비스로서 데이터의 장기 보관보다는 일시적 보관에 더 적합하기 때문입니다. 또한, SQS 대기열에서 데이터를 수동으로 관리하고 이동하는 것은 운영 오버헤드가 크며, 14일이 지난 데이터를 수동으로 처리하는 방식은 비효율적일 수 있습니다. 이 솔루션은 고가용성과 비용 효율성을 동시에 달성하는 데 적합하지 않습니다.

 

 

이제 곧 9월이네요. 저는 요즘 하루가 정말 금방 지나가는 것 같아요. 
시간이 빠르게 지나가는 걸 보면서 남은 올해를 어떻게 보내야 할지 생각하게 됩니다. 

여러분은 어떠신가요? 올해 남은 기간 동안 이루고 싶은 특별한 목표가 있으신가요? 

없으셔도 괜찮습니다! 저랑 SAA 공부 열심히 하고 계시니까요🔥 이번 주도 파이팅입니다!

오늘 글이 유익하셨길 바라며, 다음에는 또 다른 문제로 찾아뵙겠습니다.

 

감사합니다. 다음 글에서 만나요! 😊