Tagged: AWS

AWS ECS, Service 생성 오류 디버깅

AWS ECS 에서 Cluster 를 생성하고 난 후에 Service 를 생성해야 한다. AWS ECS 는 Cluster, Service 생성시에 CloudFormation 으로 생성하게 되는데, 문제는 오류가 발생했을때다.

“Circuit Breaker” 라고 되어 있어서 그냥 CloudFormation 이 실행하면서 예기치못한 오류가 발생한 것으로 착각할 수 있다. 하지만, 이것이 문제가 아닐 수도 있다.

Service 생성 Event 확인

CloudFormation 에서 “CREATE_FAILED” 라고 되어 있어도 AWS ECS 에 Service 에는 service 가 생성되어 있다. Service 를 클릭하고 들어가서 Events 탭을 클릭하면 생성이 진행되었던 과정을 볼 수 있다.

여기서 task 로 시작하는 해쉬값 링크를 볼 수 있다. 이것을 클릭하고 들어가본다.

이제 뭐가 문제인지를 확실하게 보인다. “pull image mainfest has bean retried 1 time(s)” 로 되어 있고 ECR 에서 이미지를 못가지고 오고 있음을 알 수 있다.

AWS CloudFront 인증서는 ACM eu-east-1 에서 해야 한다

AWS CloudFront 인증서는 ACM eu-east-1 (N. Virginia) 에서 발급 받아야 한다. 왜냐하면 CloudFront 때문인데, CloudFront 의 메인 리즌이 eu-east-1 로 되어 있어서 다른 리즌에 발급받은 인증서는 CloudFront 에서 사용할 수 없게 된다.

Q: 어느 리전에서 ACM을 사용할 수 있나요?

AWS 서비스를 사용할 수 있는 현재 리전을 확인하려면 AWS 글로벌 인프라 페이지를 참조하세요. Amazon CloudFront에서 ACM 인증서를 사용하려면 미국 동부(버지니아 북부) 리전에서 ACM 인증서를 요청하거나 가져와야 합니다. CloudFront 배포와 연동되어 있는 이 리전의 ACM 인증서는 해당 배포에 대해 구성된 모든 지리적 위치에 배포됩니다.

Amazon MSK 2-AZ

Kafka 를 보게 되면서 Amazon MSK 를 보고 있는데, 문서를 보기에는 운영 환경에서 3-AZ 를 권장하고 있다. 성능 문서를 보았을때에도 3-AZ 를 권장하고 있고 Kafka 의 일반적은 환경에서도 3개의 브로커를 사용하도록 하고 있다.

하지만 Amazon MSK 에서는 2-AZ 로도 얼마든지 가능하다고 한다. 2019년 10월 16일 문서에 다음과 같이 되어 있다.

You can now expand your Amazon MSK clusters and deploy new clusters across 2-AZs

The new capability to expand allows your Amazon MSK cluster to scale out as your business grows by dynamically increasing the number of brokers within a cluster. The use of 2-AZ clusters is a good option for customers who already run Apache Kafka brokers in two AZs or use a replication factor of 2 by default.

Replication Factor 를 2로 할 경우에 얼마든지 2-AZ 로 할 수 있다고 되어 있다.

AWS Athena 를 위한 S3 버킷 정책

AWS ELB 와같은 로그를 AWS S3 에 버킷 저장하는데, 이것을 Athena 에서 읽어서 분석을 하게 된다. 보통 이를 위해서 AWS S3 이 정책을 지정하지 않는 경우가 많은데, 보안상 좋지 않다. 다음과 같이 정책을 지정해주면 된다.

AWS Athena 는 AWS Glue 를 이용함으로 이와함께 정책을 지정해줘야 한다.

AWS S3 에서 직접 다운로드 금지하기

AWS S3 의 객체를 직접 다운로드를 보안상 금지해야 하는 경우가 있다. 이를 위해서 AWS S3 에 정책을 다음과 같이 하면 된다.

s3:GetObject 액션에 대해서 거부 정책을 적용하고 Referer 를 이용해서 특정 URL 을 지정해주면 된다.

AWS S3 HTTPS 강제

AWS S3 와 통신을 하는 방법으로 HTTP, HTTPS 두가지 방법이 있다. 하지만 HTTPS 만으로 통신을 하기 위해서는 다음과 같이 정책을 지정해 줘야 한다.

참고: AWS Config 규칙 s3-bucket-ssl-requests-only를 준수하려면 어떤 S3 버킷 정책을 사용해야 합니까?

AWS ATHENA 로 VPC FLOW LOG 분석하기 – 2

이전 글에서 AWS 의 Athena 를 이용한 VPC Flow Log 를 어떻게 분석하는지에 대해서 이야기 했다. VPC Flow Log 생성부터, S3 버킷 생성, Athena 데이터베이스와 테이블 그리고 Lambda 를 이용한 파티션 추가까지 비교적 많은 부분을 손봐야 했다.

이 방법은 파티션 작업을 Lambda 를 이용하는 방법으로 하루에 한번 실행시키도록 하고 있다. 하지만, AWS 에서는 이마져도 필요 없는 방법을 제공하는데, 그것이 바로 파티션 프로젝션(Partition Projection) 이다.

AWS 메뉴얼 주의사항

파티션 프로젝션을 하기 위해서 AWS 메뉴얼을 보고 따라했는데 되지 않는다. 정확히는 테이블 생성이 되지만 Athena 에서는 보이지 않는다.

Athena 의 데이터베이스는 Glue 를 이용한다. AWS Glue 가 가보면 Athena 의 테이블을 볼 수 있는데, AWS 메뉴얼대로 파티션 프로젝션을 생성하면 Glue 에는 나오지만 Athena 에는 안나온다. 이는 Glue 에서 S3 저장소를 인식하지 못해 나오는 문제다.

다음의 메뉴얼에는 문제가 있다.

일단 위 메뉴얼에는 파티션 프로젝션이 무엇인지를 설명하고 있다.

위 내용을 요약하면 버킷의 구조가 다음과 같다는 것이다.

이런 구조에서 파티션 프로젝션을 걸어주면 자동으로 날짜시간으로 파티션이 형성된다.

VPC Flow Log 의 파티션 프로젝션

그렇다면 이제 VPC Flow Log 에 파티션 프로젝션을 걸어 테이블 생성해 보자.

위 쿼리문으로 테이블을 생성하면 AWS Glue 에서는 테이블이 생성되지만 Athena 에는 나오지 않는다. 그리고 AWS Clue 에서 테이블 속성을 보면 S3 저장소와 연결되어 있지 않다.

왜 그럴까?

파티션 프로젝션을 연결할때에는 S3 저장소에 저장된 위치는 물론이고 S3 에 저장된 값의 속성도 지정해 줘야 한다. 대표적인 것이 다음과 같은 것이다.

  • Row format delimited
  • Stored as inputformat
  • outputformat

파티션 프로젝션 없이 테이블을 생성할때에는 이 옵션을 지정해 주지 않았다. 그러면 Default 값이 지정되는데, 대부분 잘 맞는 것이였다.

하지만, 파티션 프로젝션을 할 경우에 속성들을 지정해주지 않으면 아무것도 안된다. 다음과 같이 파티션 프로젝션 테이블을 생성해준다.

위와같이 할 경우에 파티션 프로젝션 테이블이 잘 생성된다. 이렇게 생성하고 난 후에 AWS Glue 에서 테이블의 속성을 보게 되면 정상적으로 S3 버킷과 연결이 되어 있고 각종 속성들이 설정되어 있는 것을 볼 수 있다.

AWS Athena 로 VPC Flow Log 분석하기 – 1

AWS Athena 는 로그 분석 서비스로 Hive 와 같다. 가장 많이 쓰이는 부분이 VPC Flow Log 를 분석하는데에 Athena 를 이용하는 방법이다. 이 글에서는 어떻게 VPC Flow Log 를 Athena 를 통해서 분석하는 알아 본다.

VPC Flow Log 설정

VPC Flow Log 설정은 간단하다. VPC 에서 Flow logs 탭에서 설정하면 그만인데, 다음과 같은 파라메터를 필요로 한다.

  • Destination Type: S3
  • Destination Name: S3 로 지정했을 시에 S3 Bucket 이름.
  • Log record format: AWS default format
  • Log file format: Text (default)
  • Partition logs by time: Every 24 hours (default)

여기서 중요한 것은 밑에서 3가지 정도다. Log record format 을 바꿀 경우에 Athena 테이블 생성시에 맞춰야 한다. Partition logs by time 을 24 시간으로 하면 S3 버킷 안에서 2022/08/29 형식으로 폴더가 생성되면서 VPC 로그가 전송 된다. 하루에 한번 폴더를 생성하면서 로그가 쌓인다는 뜻이다. 만일 Every 1 hours (60 minutes) 으로 할 경우에 2022/08/29/09 폴더가 생성되면서 로그가 쌓인다. 이 폴더의 구조는 나중에 Athena 에서 파티션 프포젝션(Partition Projection) 을 설정할때에 참고하게 된다.

또, S3 버킷으로 전송할 경우에 S3 의 암호화를 SSE_S3 로 할 것을 권장한다. CMK 로 할 경우에 로그가 쌓이지 않을 가능성이 있다. 또, 향후에 권한지정에서 CMK 권한을 함께 줘야하는 복잡함이 있을 수 있다.

S3 버킷 확인

필자의 VPC Log 설정으로 인해서 S3 에는 다음과 같은 형태로 S3 에 로그가 쌓이고 있다.

버킷 이름만 지정해주면 그 안에 AWSLogs/계정ID/vpclfowlogs/ap-northeast-2/ 가 자동으로 생성되며 그 안으로 year/month/day 순으로 생성된다.

앞에서 VPC Flow Logs 설정할때에 Partition logs by time 에서 Every 24 hours (default) 로 지정했기 때문에 날짜별로 생성된다.

Athena 작업

작업그룹(Workgroups) 생성

먼저 Athena 에서 필요한 것이 작업그룹(Workgroups) 이다. 기본적으로 Primary 가 기본 생성되어 있지만 하나 생성한다. 생성할때에 필요한 것은 다음과 같다.

쿼리 결과를 받을 S3 를 지정해야 한다. 만일 암호화가 필요하다면 SSE_S3 를 권장한다. CMK 도 가능하지만 Role 설정을 잘 해줘야 한다.

데이터 사용량을 적절하게 조절해 주길 권장한다. 덮어놓고 좋다고 No limit 로 하는 순간 돈이 술술 나갈 것이다. 이 데이터 사용량은 얼마든지 설정을 변경할 수 있다.

Database 생성

Query Editor 로 이동해 화면 오른쪽 상단에서 앞에서 생성한 작업그룹(Workgroup) 으로 변경해 준다.

그러면 Workgroup 이 변경 된다. 이제 다음과 같이 Database 를 생성해 준다.

위 쿼리문은 화면안에 쿼리입력창에 입력하고 ‘Run’ 을 클릭해주면 된다.

이렇게 하면 데이터베이스가 생성이 된다. 그리고 왼쪽에 Database 부분에서 새로 생성한 데이터베이스를 선택해 준다.

위와같은 상태가 된다면 이제 테이블을 생성해야 한다.

Table 생성

이제 Table 을 생성해야 한다. 테이블을 생성할때에 중요한 것이 VPC Flow Log 의 S3 저장소와 데이터 컬럼들이다. 다음과 같다.

테이블을 생성할때에 컬럼을 지정해 줘야 하는데, VPC Flow Log 설정할때에 record format 을 AWS Default Format 을 지정했는데, 그 포맷은 위와 같다. 이 컬럼들은 S3 에 저장된 파일을 열었을 때에 맨 처음 나오는 행에 컬럼헤더 값들이다. 정확히는 ‘_’ 가 ‘-‘ 로 보면 정확하다. Athena 테이블은 ‘-‘ 를 ‘_’ 로 변환된다.

중요한 것은 Partitioned BY 부분에 date 부분이다. 테이블을 파티셔닝을 하기 위한 기준이 되는 컬럼을 추가하는 것이다. 이 파티션 컬럼은 S3 에 저장되는 VPC Flow Log 에는 없는데 파티셔닝 테이블을 생성할때에 이름처럼 생성된다.

위 쿼리문을 실행해 테이블을 생성한다.

파티션 생성

만일 파티션이 없다면 쿼리 시간이 길어진다. VPC Flow Log 의 경우 날짜로별로(yyyy/MM/dd) 쌓이는 것에 창안해 파티션을 날짜별로 생성하도록 할 것이다. 다음과 같이 파티션을 생성해준다.

이렇게 하면 2022/08/29 에 해당하는 버킷에 내용이 파티션으로 입력 된다.

파티션을 이용하면 데이터 조회시에 그 범위가 줄어든다. 정확하게는 데이터 스캔(Data Scan) 범위를 줄일 수 있어서 쿼리 속도를 높여줄 뿐만 아니라 스캔 범위가 줄어들기 때문에 데이터를 긁어오는 양도 줄게되어서 비용을 아낄 수 있다.

앞에서 만든 테이블의 경우 date 컬럼은 date 테이터 타입임으로 다음과 같은 쿼리가 가능하다.

date 타입이기 때문에 문자열을 date 타입으로 해줘야 한다.

파티션 생성 문제

파티션을 생성하면 문제가 하나 있다. 날짜별로 하나하나 다 생성해 줘야 한다. 시간은 흐르고 날짜는 변경될 것이다. 내일이 되면 다른 날짜로 S3 에 폴더가 만들어지고 거기에 데이터가 쌓일 것이다. 그러면 Athena 에서 그 날짜에 맞는 S3 저장소의 파티션을 생성해줘야 한다.

매일매일 하루에 한번 이것을 해야 한다고 생각하면 힘들다.

이것을 자동으로 하는 방법은 존재한다. Lambda 를 이용하는 것이다.

Lambda 작성하기

Lambda 실행을 위한 Role 생성

Lambda 를 작성해 자동으로 매일매일 하루에 한번 파티션을 생성하도록 해보자. Lambda 를 실행하기 위해서는 먼저 Lambda 실행을 위한 Role 이 필요하다.

Lambda 실행을 위한 Role 을 위와같이 생성해 준다.

Lambda 생성

Lambda 는 여러가지 언어로 작성될 수 있는데, 여기서는 Python 을 이용했다.

Lambda 를 실행하는 Roles 는 앞에서 작성한 Roles 를 지정해 준다.

EventBridge Rule 생성

EventBridge 에서 Rule 를 생성해 매일 자정 0시 0분에 람다를 실행하도록 설정해 준다.

KST 를 위한 Athena 테이블 View 생성

Athena 에 vpc_flow_logs 테이블에 start, end 컬럼은 unixtime 이지만 UTC 기반이다. 이것을 KST 기반으로 보기 위해서는 연산이 필요한데, 그것을 아예 View 만들어 놓으면 좋다.

이제는 vpc_flow_logs_kst 뷰(view) 에 질의를 하면 start, end 컬럼의 데이터가 KST 시간으로 표신된다.

결론

지금까지 VPC Flow Log 생성에서부터 Athena 를 이용하는 방법, 더 나가 자동으로 파티션을 생성하도록 Lambda 까지 작성해봤다.

하지만, Lambda 작성도 필요없는 방법이 있다. 파티션 프로젝션(Partition Projection) 이라고 불리는 방법인데, 이것은 처음 테이블을 생성할때에 S3 의 날짜 폴더 구조를 기반으로 자동으로 파티션을 인식시키는 방법이다. 이렇게 하면 Lambda 를 이용해 파티션을 수동으로 생성해줄 필요가 없게된다.

AWS S3 PreSigned URL 설정하기

AWS S3 PreSigned URL 설정에 대해서 알아 본다. AWS S3 는 저장된 객체에 대해 HTTP 를 통해서 다운로드를 제공 한다. 문제는 이렇게 객체를 다운로드 하도록 주소를 공개할 경우에 누구나 다운로드 할 수있게 되서 보안상 좋지 않다. 그래서 AWS S3 는 인증 과정을 통해서 특정 시간 동안만 URL 에 다운로드 권한을 부여하는 PreSigned URL 기능을 제공하는데 이에 대해서 알아 본다.

AWS 사용자

먼저 PreSigned URL 에 인증 과정에서 사용할 Signiture 생성을 위해서 accesskey, secretkey 가 필요하다. 이것은 결국 AWS 사용자가 필요하다는 것과 같다.

사용자를 추가할때는 “AWS 액세스 유형 선택” 에서 “액세스 키- 프로그래밍 방식 액세스” 유형으로 계정을 생성해야 한다. AWS 콘솔로 로그인이 불필요한 사용자 이기 때문인데, 이렇게 생성을 진행하면 마지막에 accesskey, secretkey 가 발급되어 진다. 이것을 잘 보관 하자.

IAM Role, Policy

AWS S3 Presigned URL 을 위해 생성한 AWS 계정에는 그 어떤 IAM Role, Policy 가 필요하지 않다. 이것은 사용자에 S3 권한 설정을 IAM 을 통해서 할지 아니면 AWS S3 의 Permission Policy 로 할지에 따라 다를 수 있다. AWS S3 에서도 Permission Policy 를 설정할 수 있고 이 설정에서 특정 사용자에게 정책을 부여할 수 있다.

AWS S3 Presigned URL 만을 위한 계정이기 때문에 IAM 에서 권한을 부여하지 말고 AWS S3 에서 권한을 부여 방법을 선택 했다.

AWS S3 생성

AWS S3 는 글로벌 한 서비스이지만 생성할 리전을 선택할 수 있다. 생성할때에 S3 버킷에 대해서 별다른 설정을 하지 않고 그냥 기본값으로 생성한다. 나중에 설정을 얼마든지 변경할 수 있는데, 단 Presigned URL 을 한다고 해서 “Block Public Access settings for this bucket” 을 손대서는 안된다.

PreSigned URL 을 한다고 버킷의 공개 접근 설정을 변경해서는 절대로 안된다. 혹자는 URL 자체를 제공해줘야 하기 때문에 공개설정을 해줘야 한다고 하지만 특정 사용자에게 URL 을 제공하는 방식이기 때문에 버킷의 공개 접근 설정은 불 필요 하다.

AWS S3 Bucket Policy

여기서 핵심인데, 앞에서 AWS 계정에 아무런 권한 설정을 하지 않았다. 이제 그 권한 설정을 AWS S3 버킷에서 해주면 된다. Permission 탭에서 Bucket Policy 를 볼 수 있는데, 여기서 다음과 같이 해주자.

Principal 에 앞에서 생성한 AWS 계정이다. Resource 에는 Bucket 의 arn 을 주면 된다.

테스트

이제 테스트를 해보자. 테스트는 간단하게 Python 코드를 작성해 해보면 된다.

access key id 와 secret key id, Bucket Name 에 본인에 맞게 수정해 준다. 거기다 ‘utils/putty.exe’ 는 AWS S3 버킷에 있는 객체다.

위 코드를 실행하면 Presigned URL 이 출력이 된다. 유효기간은 expiration 변수에 값을 수정하거나 인자로 주면 된다. 기본값은 60초 이다.