한 회사에서 AWS WAF 로그를 Amazon Kinesis Data Firehose를 통해 Amazon S3로 보냅니다. Amazon Athena 쿼리는 매일 한 번 실행되어 지난 24시간 동안의 WAF 로그를 검색합니다. 일일 로그 볼륨은 안정적이지만, 쿼리 실행 시간이 시간이 지남에 따라 점진적으로 길어지고 있습니다. 운영 오버헤드를 최소화하면서 쿼리 실행 시간이 계속 증가하는 것을 방지해야 합니다. 다음 중 어떤 솔루션이 이러한 요구 사항을 충족합니까?

정답은 Kinesis Data Firehose 구성과 Athena 테이블 정의를 수정하여 데이터를 날짜 및 시간별로 파티셔닝하고 관련 파티션을 보려면 Athena 쿼리를 변경하는 것입니다. Athena 쿼리 성능 저하의 주요 원인은 스캔하는 데이터 양이 증가하기 때문입니다. 데이터를 날짜 및 시간별로 파티셔닝하면 Athena는 전체 데이터 세트를 스캔하는 대신 쿼리에 필요한 특정 파티션만 스캔하여 쿼리 실행 시간을 크게 단축할 수 있습니다. 이는 운영 오버헤드를 최소화하면서 쿼리 성능을 최적화하는 가장 효과적인 방법입니다. 다른 옵션들은 다음과 같은 이유로 적절하지 않습니다. 매일 AWS WAF 로그를 하나의 로그 파일로 통합하는 AWS Lambda 함수를 생성하는 것은 쿼리 성능을 향상시키지 않으며, 오히려 단일 파일 크기를 증가시켜 Athena가 더 많은 데이터를 스캔하게 만들 수 있습니다. AWS WAF가 매일 다른 S3 버킷으로 로그를 보내도록 구성하는 것은 파티셔닝과 유사한 효과를 얻을 수 있지만, S3 버킷 관리가 복잡해지고 Athena 테이블 정의를 별도로 관리해야 하므로 비효율적입니다. Kinesis Data Firehose 구성을 업데이트하여 Amazon S3의 데이터를 날짜 및 시간별로 파티셔닝하고 Amazon Redshift용 외부 테이블을 생성하고 Amazon Redshift Spectrum을 구성하여 데이터 소스를 쿼리하는 것은 불필요하게 복잡하며, 이미 Athena를 사용하고 있는 상황에서 Redshift Spectrum을 도입하는 것은 추가적인 비용과 관리 오버헤드를 발생시킵니다.