글쓰는 감자

참고 1: https://realyun99.tistory.com/153

참고 2: https://realyun99.tistory.com/154

참고 3: https://realyun99.tistory.com/155

얼마 안남았다...! 마지막 lab!!

• S3 버킷

버킷을 생성한다.(나머진 default로 진행)

• Kinesis Data Firehose 생성

Browse를 눌러 위에서 생성했던 버킷 지정해준다.

위와 같이 추가 설정을 진행한 후 생성을 클릭

• IoT Core 규칙 생성

위와 같이 규칙 작업을 추가해준다.

• S3 버킷 확인하기

.gz 파일 객체 확인

→ 디바이스의 메시지가 S3 데이터 레이크에 저장되었음을 확인.

❗ 위의 설계도 처럼 사용하기도 하지만 보통 OpenSearch의 경우 비싸 많이 사용하지 않는다. 오히려 S3 뒤쪽으로 분석 쪽 서비스들을 더해 주로 사용하게 될듯! ❗

(S3 + Glue + Athena로 분석하고 QuickSight로 시각화)

참고: https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/with-s3-example.html

게임데이 준비하면서 해본 간단한 실습!

• S3 버킷 생성 및 샘플 객체 업로드

그냥 하고 싶은대로 설정 후 원하는 파일 아무거나 업로드하면 된다.

• Lambda 함수 생성

function blueprint를 사용해 생성할 예정..

샘플 코드를 활용한다고 생각하면 된다!

위에서 생성했던 버킷으로 트리거를 설정한다.

Amazon S3 가 함수를 호출할 수 있도록 함수의 리소스 기반 정책을 수정하자.

역할 문서를 확인해보자. S3 관련한 정책을 허용하는 내용이 잘 들어가있는지 확인한다.

트리거가 잘 잡혔는지 확인해보자..(나는 위처럼만 하면 트리거 추가가 안되서.. 따로 추가 다시 해줌..)

• Lambda Test

아래 JSON 코드에서 S3 버킷 이름(examplie-bucket)과, 객체 키(test%2Fkey)를 테스트 파일 이름(버킷 안 파일)으로 바꿔준다.

해당 이벤트로 설정 후에 테스트를 해보면

다음과 같이 결과를 얻을 수 있다.

• S3 Trigger Test

S3 버킷에 파일을 업로드할 때 함수를 호출한다.

따라서 파일 업로드를 몇 개 하고 Lambda의 모니터링을 확인해보면

Invocations 그래프의 숫자는 S3 버킷에 업로드한 파일의 수와 일치해야한다.

cloudwatch 로그에서도 확인 가능하다.

참고: https://www.youtube.com/watch?v=VDqToPfbuok 

이제 좀 실질적으로 필요한 실습을 진행해보자..(많이 사용할만 한걸로다가 😅)

• 버킷 생성

이름 알아서 고유하게 잘 설정한다.

이후에 로그 샘플 파일을 업로드 한다.

이와 같은 형태로 주욱 나열되어 있음(의미는 없음)

• Glue Crawler 생성

이름: Demo-Athena-log-crawler

Data store 추가(위에서 생성했던 버킷 경로로!)

IAM Role: 이름 적당히 해서 새로 생성 후 지정

Database는 새로 생성

실행 시키자!

로그 데이터 양에 따라 걸리는 시간이 달라질 것!

테이블을 확인해보면,

다음과 같이 로그 파일에 알맞는 스키마가 생성된 것을 확인할 수 있다.

• Athena로 쿼리

해당 버킷을 설정해주자.

테이블 미리보기를 누른 화면이다.. 아까 Glue에서 생성했던 테이블 결과를 확인할 수 있다.

원하는 쿼리로 실행해서 잘 이용하면 됨!!!

Athena 사용사례

- 여러 로그파일이 저장된 S3에서 필요한 데이터를 조회

- 정형화된 메타데이터 혹은 저장 데이터를 조회

- 이벤트 데이터에서 필요한 정보를 추출(A/B테스트) 등

❗ 지금은 로그 샘플 파일이라 적고 별거 없지만, 실제 프로젝트 로그의 경우 아주 많기 때문에 오류나 이런거 찾기에 좋을듯! ❗

CloudFront + S3 배포

• S3 버킷 생성

버킷 이름만 정해주고 버킷을 생성한다.(다른 옵션들은 나중에 다뤄볼 것!)

test page를 작성해 객체 업로드(진짜 간단하게 작성해도 괜찮다.)

• CloudFront 배포 생성

해당 원본 도메인을 방금 생성한 버킷 도메인으로 설정한다.

다음으로 S3 버킷 액세스는 OAI를 사용할 수 있도록 체크하고 제어 설정 생성을 해준다.

(왜 갑자기 S3 버킷 정책을 수동으로 업데이트 하게 되는지 모르겠지만... aws가 업데이트가 되었나?)

CloudFront와 S3는 HTTP 연결을 하고 있고 우리가 할 최종 목표는 사용자와 CloudFront의 HTTPS 연결이니까 프로토콜을 Redirect로 해주자.(상황에 맞춰서 설정해주면 된다.)

기본값 루트 객체를 써 넣으면, 도메인 뒤에 따로 써주지 않아도 처음 들어갔을 때 해당 객체로 들어간다.

배포 생성을 누르면 아래와 같이 정책을 업데이트 하라고 뜨는데 해당 정책 복사를 클릭하고 업데이트 해주면 된다.

• S3 버킷 정책 업데이트

버킷 권한에서 버킷 정책을 편집하면 된다. 아까 복사해뒀던 정책을 넣어주자.

배포가 완전히 적용될 때 까지 잠깐 기다렸다가 생성한 배포 도메인을 복사해 붙여주면 원하는 test page를 확인할 수 있다.

CloudFront + EC2 배포

• EC2 생성

원하는 웹페이지나 테스트 페이지를 넣고 EC2에 올린다.(이거는 가볍게 apache 서버 올려서 테스트를 진행했다.)

보안 그룹이나 이런 것들도 잘 열어줘야 한다..(HTTP(80), HTTP(443), TCP(8080), SSH(22))

해당 인스턴스의 퍼블릭 IPv4 DNS를 복사해두자. (어차피 테스트 용으로 만든 거라 삭제 예정)

• CloudFront 배포 생성

S3와 같이 원본 도메인에 해당 복사해둔 퍼블릭 IPv4 DNS를 넣어주자.

(현재는 테스트라 ec2로 했는데 이중화를 원하거나 가용성을 원하면 ALB 구성이 필요하다.)

프로토콜 역시 원하는대로 선택하고 그냥 배포 생성하면 된다.

이것 또한 배포 도메인으로 웹 페이지를 확인할 수 있다.

CloudFront + EC2 + S3 (Multi Origin) 배포

아까 생성했던 CloudFront + EC2 배포에 추가 해보자.

해당 배포로 들어가 원본을 추가하자.

• 원본 생성

아까 설정했던 대로 S3 버킷 정책 업데이트까지 진행하자.

• 동작 생성

경로 패턴의 경우 아까 난 S3 버킷에 test.html 파일을 넣어두었기 때문에 해당 경로로 설정했다.

상황에 맞게 경로를 설정하자.

해당 설정까지 마치면 원본 2개, 동작 2개가 있어야 맞다.

조금 기다린 후 배포도메인만 사용하면 ec2의 화면이, 배포도메인/test.html 로 들어가면 s3의 화면이 나온다.