<447 SES>
> 기타 서비스들은 전체적으로 가장 기본적인 개념에 대해 한두문제 가능
> SES : Simple Email Service, IAM 권한 필요
> 이메일 송신 가능
>> SMTP 인터페이스 혹은 AWS SDK 사용 가능
> 이메일 수신 가능
>> S3, SNS, 람다 등과 integrate
------------------------------------------
<448 AWS OpenSearch Service>
> ElasticSearch 의 후속작 (라이선싱 이슈 때문에 이름 바뀜)
> DD 와 비교해 보면, index, pk 등을 사용해서만 DB 데이터 쿼리가 가능했음
> OS 는 일부만 매칭되어도 모든 필드를 검색할 수 있음
>> OS 를 통해서 앱에 검색 기능 자주 제공, (complement-보충 to another db)
> 분석적 쿼리 (analytics) 로도 사용가능
> Managed Cluster / Serverless Cluster 가 있음
>> 전자는 실제 물리적 인스턴스가 프로비저닝 됨
>> 후자는 스케일링부터 운영까지 AWS 가 해줌
> 고유한 쿼리 언어가 있음, 태생이 SQL 을 지원하진 않지만, 플러그인으로 SQL 호환 가능
> KDF, AWS IoT, CW Log 등등 여러 소스로부터 데이터들을 받아 주입할 수 있다
> Cognito & IAM, KMS encryption 등등을 사용해서 보안을 강화함
> OS 데이터에 대한 대쉬보드를 만들 수도 있다
> OS 내부의 DB 를 만들고 그 안에서 쿼리하는 방식
< OS Pattern >
> DD 에 대한 CRUD, Stream 을 람다 함수가 수신, 람다에서 OS 에 데이터 INSERT
> 내 APP 은 DD로 한정된 쿼리만 할 수 잇는게 아니라, OS 로 많은 검색 능력을 더 갖게 됨
>> ex 항목 이름으로 부분 검색 등 ( DD는 안됨 이게)
>> OS 로 어떤 A 필드의 부분을 검색 -> 해당 Item ID 를 찾아올 수 있음 -> DD에 item 전체 반환 받는 SELECT 진행
< OS Pattern 2>
> CW Log 를 OS 에 저장할 수 있다
> 구독 필터 (Subscrition Filter) 를 통해 저장을 원하는 데이터들을 필터링 해서 전달, 람다가 이를 OS 에 꽂음 (실시간으로 진행됨)
> 아래 그림처럼 Lambda 가 아닌 KDF 로도 가능
> 이를 사용하면 [Near Real Time] 이라는 차이가 있음!!!
< OS Pattern 3 >
> KDS 의 데이터들을 KDF 가 받아서 OS 에 전달하는 그림
> 역시 KDF 이기 때문에 Near Real Time!
> KDF 에서 람다를 활용해서 데이터를 customizing 할 수도 있다
> KDS 의 데이터를 KDF 없이 그냥 바로 람다에서 Real Time 으로 전달할 수도 있다
------------------------------------------
<449 Athena>
> 서버리스 쿼리 서비스 : S3 버킷에 저장된 데이터 분석을 도와준다
> File 들을 쿼리하려면 standard SQL 을 사용함
> 아테나는 Presto Engie 으로 개발이 되었고, 여기서 SQL 언어를 사용함
> S3 버킷에 객체가 로딩되면 아테나는 이 데이터를 쿼리해서 그 자리에서 분석함
>> 지금까지 배웠던 것처럼 여기저기 객체 데이터를 옮길 필요가 없음!! S3 그 자리에서 함
> csv / json / orc / avro / parquet 등의 파일 형식을 지원한다
> 1TB 데이터 스캔마다 5달러 (서버리스이기 때문에 프로비저닝 비용은 없음)
> Amazon Quicksight 라는 다른 리소스와 자주 활용됨 (reporting / dashboards 등에 활용)
> Use Case : 쿼리, 비즈니스 intelligence(?), 데이터 분석, report & analyze, 여러 종류의 Log (VPC, ELB, CT Trails 등) 등등
> 만약에 serverless SQL 로 S3 데이터 분석 등등 이런 얘기는 거의 무조건 아테나임!!
<Athena 의 성능 향상>
> 스캔하는 데이터의 양에 따라 지불하므로, 스캔이 적게 일어나는 방향으로 해야함
1> columnar data (열 기반 데이터) 를 사용하면 비용을 아낄 수 있음 - 필요한 열만 스캔
>> ex: Apache Parquet / ORC 포맷이 권장됨
>> Huge 성능 개선, Glue 같은 서비스를 사용해서 Parquet / ORC 포맷으로 변환 가능
>>> Glue 로는 쉽게 ETL Job 으로 데이터 포맷을 변환할 수 있다 (곧 나옴)
2> 데이터 양을 줄이기 위해서 데이트를 압축해서 retrieve 하는 크기를 줄여야 함
3> 특정 column 에 대해서 집중적으로 쿼리를 때릴거면, Partition 해도 됨
>> 전체 경로 뒤에 / 를 붙이고 각 슬래시에 분할할 partition_column_name = Value 형태로 넣으면 됨 (활용할 걸 알고 설계)
>> S3 에서 이런식으로 구성하면, Athena 가 쿼리할 때 S3 내 정확히 어느 경로에 있는 어떤 폴더에서 데이터를 스캔하는지 알 수 있게 도와줌
>> ex: year=1990, year=1991 이런식으로 S3 를 구성
4 > Use Larger Files ! (128메가 이상) - overhead 최소화
>> S3 에 용량이 작은 파일 여러 개 있을 때보다, 128메가 이상의 큰 파일 하나로 있을 때 성능이 더 좋음
>> 사이즈가 큰 파일이 스캔하기도 쉽고 반환하기도 쉽기 때문
<Athena's Federated Query>
> Athena 는 S3 뿐만 아니라, 모든 곳의 데이터를 쿼리할 수 있음 (관계형, 비관계형, S3같은 객체들, on premise, custom data sources 등등)
> Data Source Connector 를 사용하는 것이 비결! Lambda 함수임
> 이 람다 함수는 Federated Query 를 실행한다 (CW Log, DD, RDS 등에 대해 쿼리 수행하도록)
> 위 그림처럼 ElastiCache, DocumentDB, DD, MySQL, Aurora, On-premise DB, SQL Server 등등 에 연결될 수 있다
> 한 Data Source 당 하나의 람다 Connector 가 필요!
> 실행한 쿼리의 결과는 추후 활용을 위해 S3 버킷에 저장된다
------------------------------------------
<450 Athena - 실습>
> Athena 이동, S3 르 설정해야함. Manage 로 이동해서 [Query 결과 위치] 를 지정
> 새로운 버킷 만들어서 지정함
> 기본으로 DataSource 가 AWSDataCatalog 이고, 여기서 제공되는 기본 DB 들이 좀 있음
> 우리는 예시로 S3 에 있는 S3 Access Log 를 쿼리하기 위해 Access Log 를 빼와서 DB 를 만들 것임
> 어떤 bucket 에 대한 Access Log 를 저장하는 bucket 을 만들어 듬 (로그 장기 저장을 위한 버킷)
>> 얘를 DAtaSource 로 활용해서, 아테나가 얘를 쿼리하고, Result 를 새로 만든 버킷에 저장할 것
> .sql 파일을 봐서 DB와 테이블들을 만듬 (내가 읽을 데이터를 기준으로 어떻게 저장을 할지를 짜긴 해야 하는 듯, 쪼금 헷갈리긴 함. 사실 이론적인거만 알고 있으면 될)듯
> (Athena S3 Access Log 를 치면 AWS 에 샘플 있음)
> 얘는 아테나 쿼리들인듯. 마지막에 Location 으로 S3 타깃 버킷 위치 설정하는 쿼리도 포함되어 있음
> 쿼리를 실행하면, 바로 TG 버킷을 읽어와서 설정한대로 log 를 읽고 테이블에 저장하게 됨
> 예시로 다양한 쿼리들을 보여줌 (S3 내의 데이터를 가지고 쿼리하는 서버리스의 강력함을 보여줌)
>> ex: Group by 를 사용해 S3에 대해 GET, PUT, POST 등의 operation 이 얼마나 일어났는지 집계해줌
>>
------------------------------------------
<451 Amazon MSK >
> Kafka 용 아마존 관리형 Streaming
> Kafka 는 아마존 Kinesis 같은거 (모두 데이터를 스트리밍하는데 사용)
> MSK 로 Fully Managed Kafka Cluster 를 즉시 구성 가능, crud 가능 (카프카 SU 은 매우 복잡하다. 큰 강점)
>> Kafka Broker Node & Zoo Keeper Node 를 create & manage 해줌 (카프카 쪽 개념인 듯)
> 최대 3 곳의 multi-AZ 로 클러스터를 VPC 내에 배포 가능 (HA)
> Failure 로부터 빠른 복구 & EBS Volume 에 데이터 영구 보관
> MSK Serverless 로 구성하면 서버 프로비저닝 용량 관리까지 다한다 (옵션)
<Apache Kafka 의 역할>
> 데이터 스트리밍에 사용됨
> 카프카 클러스터는 여러 Broker 들로 구성된다
> Producer 에서 데이터를 생산하기 때문에, Kinesis / IoT / RDS 등등의 데이터 보관 리소스와 연결이 됨
> Producer 는 이 데이터를 Kafka Topic 을 전송한다
> 그럼 해당 Topic 의 Broker 가 이를 받고, 모든 Broker 들에게 데이터를 복제한다
> Kafka Topic 은 이제 Producer 와 연결되므로 실시간 데이터가 스트리밍 되므로, Consumer 가 Topic 을 Polling 하여 데이터 자체를 가져온다 (데이터 스트리밍)
>> Process 하거나, 가공하거나, 원하는 목적지로 또 보냄
<Kinesis VS Kafka (MSK)>
> KDS 는 message limit 1MB / KK 에서는 1MB 는 기본, 10MB 정도 단위로 크게 할 수 있음
> KDS 는 Shard 로 스트리밍 함 / KK 는 Topic 으로 함 (Partition 활용) -> 둘은 사실 비슷함
> KDS 는 Shard Splitting & Merging 으로 규모 조정 / Kafka 에서는 Topic 규모 조정이 Partition 추가 뿐 (Partition 삭제 불가능)
> KDS MSK 모두 TLS 보안을 지원 / MSK 는 PLAINTEXT 로도 전송함
> At-Rest 에서는 둘다 KMS 암호화 함
> MSK 는 영구 보관 가능 (EBS Storage 비용은 당연히 발생)
<Amazon MSK Consumer>
> Kafka 로부터 데이터를 Polling 하여 소비하려면, Consumer 가 필요
> 1) KDA 사용 (for Apache Flink) : Flink App 을 실행해서 MSK 클러스터에서 직접 데이터 읽음
> 2) Glue 사용 : ETL 작업 스트리밍
> 3) 람다 함수 사용 : MSK 를 이벤트 소스로 사용
> 4) 직접 Consumer App 생성 : EC2, ECS, EKS 등 원하는 플랫폼에서 실행
------------------------------------
<452 ACM : Certificate Manager>
> SSL/TLS 인증서를 쉽게 provision / manage / deploy 할 수 있다
> HTTPS End Point 에 대해 in-flight encryption 을 제공
> ALB 외부에 HTTPS End Point 노출하려고 함
> ACM 을 사용할 수 있음, 도메인 연결하면 사용할 TLS 인증서를 provision / manage 해줌
>> 얘를 연계하면 ALB 와 자동으로 연동, HTTPS 엔드 포인트를 Client 에게 제공하게 된다
> 공용 / 사설 TLS 인증서 모두 지원, 공용 TLS 인증서에 대한 사용은 무료
> TLS 인증서 renewal 갱신 기능도 있음
> API Gateway, CF, ELB 등과 연계하여 TLS Certi 를 연동시켜 준다
> TLS 인증서를 생성 / 관리 하여 In-Flight Encryption 을 돕는 서비스 어쩌구 하면, 바로 ACM 생각하면 됨
--------------------------------------
<453 ACM 실습>
> 시험을 위해 기억할 것 : Public, Private Certificate 모두 연동 가능함 (Private 은 셤 범위도 아님)
> Public 은 Provision Certi 로 이동해야 함
>> 기존에 구입한 Certi 가 있다면 Import, 없다면 Request Public Ceritificate 진행
> Domain Name 에 주체 대체 이름 입력 (원하는 만큼 가능) / *.hello.com 가능
> DNS Validation 을 진행해 해당 도메인을 소유하고 있음을 검증해야 함
>> DNS 구성에 CNAME Record 를 추가하라고 함
>> Route 53 에 있으면 바로 생성해주긴 함
>> 그러면 검증하고, Certificate 을 발급해준다
> EBStalk 를 생성해서 실습으로 적용을 해봤음
> 추가 구성에 들어가서, Load Balancer Config 설정, ALB 선택, HTTPS 로 443 Listener 설정, 여기에서 SSL Certi 설정 (내가 만든 ACM 이 보임)
> ALB 를 구성하는데, ALB 가 ACM 의 Certi 를 사용하는 모델임
> 일단 EBS 로 발급받은 URL 은 당연히 http 상태고, EBS 에 직접 접근하는 상태임 (SSL 을 연계한 ALB 로 보내야 함)
> 우리는 Certi 에 A 도메인으로 접근하려는 상태이므로, Route 53 에 이 도메인을 EBS 와 연계 등록해서 DNS 업데이트를 해야한다
> 그래야 SSL 로 A 도메인 접근시 ALB 가 받고 EBS 로 전달해주게 될 것
>> CNAME 생성, SSL Certi 에 했던 도메인.a.com -> Value 는 EBS 의 http 경로 하면 된다
> 그럼 https://도메인.a.com 으로 이동시 정상적으로 이동하는 것을 알 수 있음
> 브라우저에서 Certi 정보를 보면 Amazon 으로 부터 발급되었음을 알 수 있음 (무료 Certi 라 좋은듯!)
--------------------------------------
<454 ACM Private CA>
> ACM 으로 Public Key 발급하는 거 봤음 (그냥 공개 인터넷이 아닐 때는 Private Certi 쓰고, 발급 가능하다 정도만 생각하면 될듯)
> Private Key 도 사실 발급 가능 - AWS Private CA (Certificate Authority) 를 구성해야 함
> create Root Certificate Authority or any subordniary CAs which are CA that depend on root 라고 하는데 뭔소린지 모르겠음 (생성할 수 있는건 맞고, Private CA 구성 필요 이정도 까지)
> end-entity X.509 Certificate 을 발급하고 사용할 수 있다 (사용하는 Certi, 이걸 통해 sub Certi 를 발급할 수 없음)
> Private 이기 때문에 Public Internet 이 아닌, Only by you Organization 으로만 신뢰된다 (공용 인터넷에 발급할 수 없음 (동작하지 않을 것)) - Private Certi 이기 때문, 차이를 좀 알면 좋을 듯
> ACM 과 연계되는 AWS 서비스들과 활용 가능 (ex : ALB, CF, Gateway, EKS 등)
> User / Computer / API / IoT Device 등에 대하여 발급될 수 있다
> Use Case of 사설 CA
>> 내부적으로 암호화된 TLS 통신 (공개 인터넷이 아닌경우에도). 코드에 암호 서명이 되어 있는 경우
>> User / Computer / API end point / IOT Device 등에 대한 인증을 위해
>> Enterprise 단위의 Public Key Infrastructure (PKI) 를 만들어야 할 떄
---------------------------------------
<455 Amazon Macie>
> Fully Managed 되는 Data Security & Data Privacy Service (데이터 보호 서비스)
>> 민감한 데이터들을 감지하고 보호하며, ML 과 Pattern Matching 을 사용
>> 이 민감한 데이터 중 하나는 PII 일 수 있다 (Personally Identifiable Info)
>> 가령, PII 가 S3 에 있으면, Macie 는 S3 를 분석하며 PII 로 구분할 데이터를 감지한다. 이 발견 결과를 EventBridge 로 Notify 를 해서, 알아서 추후 Integration 을 할 수 있다
> 민감한 데이터 감지하는 녀석이고, 활성화만 시키면 됨
---------------------------------------
<456 AWS AppConfig>
> 환경 변수 등을 사용해서 앱 내에서 Dynamic 하게 앱을 동작시킴
> 구성 데이터를 앱 외부에 두고 싶다면?
> AppConfig 를 사용, "코드 배포"와 독립적이며, 동적으로 앱의 구성을 변경하고 싶을 때 사용
>> 앱 재기동 불필요
> 앱 코드 변경, 재배포를 하지 않으면서 다음과 같은 기능들을 수행할 수 있다
>> Feature Flag (기능 플래그) 사용 가능 : 앱이 새로운 기능을 추가했는데, 당장은 비활성화하고 싶음
>>> 앱을 배포하고 AppConfig 에서 해당 기능에 대한 값만 꺼두면 (false) 됨. 실행 가능할 때 feature 만 바꾸면 해당 기능이 활성화 (true 로 변경) 된다
>> 많은 Configuration 을 변경해서 앱의 성능을 미세하게 조정할 수도 있음
>> IP Block / Allow 등에 대한 목록도 변경해서 AppConfig 에서 실시간으로 반영되게끔 할 수도 있다
>> 가끔, 변경되는 사항을 점진적으로 배포하고 싶을 때도 가능 (문제 발생을 확인하며)
> AppConfig 가 보관하는 Config 의 Source 들은 다음과 같음 (통합 관리 툴임, 하나의 Source 는 아님)
>> SSM Document, Param Store, S3 버킷 등등
> EC2 인스턴스 혹은 런닝 앱에서 AppConfig 로부터 Configuration 을 폴링하는 구조임
> Configuration 변경시, 앱이 이를 자동으로 Poll 함
> 그러면 CW 로 이를 모니터링해서, 오류 상황 발생시 Alarm 발생해서 Rollback 을 trigger 하게끔 설계할 수 있는 것!
> 배포될 때 잘못된 구성에 대한 기본적인 Validation 을 사용할 수 있음
>> JSON Schema : Syntatic Check, 구성 데이터의 형식 점검
>> Lambda Function : Semantic Check, Parameter 들을 적용하기 전 다양한 방식 (custom) 으로 점검시킬 수 있다 (코드를 실행함으로써)
---------------------------------------
<457 CW Evidently (분명한?)>
> 듣다 보니 제법 유용할 것 같은 기능!!
> 앱의 새로운 기능들을 안전하게 테스트 할 수 있도록 사용자 n% 에게만 기능을 제공해볼 수 있는 CW 의 기능
>> 새로운 기능을 배포하는데, risk 를 최소화 하고 싶어서 5% 만 먼저 사용해보고 오류를 검증하는 Use Case
>> 혹은 신규 기능에 대한 실험 데이터 수집, 해당 데이터 분석, 성능 관찰 등에도 활용될 수 있다
> 두가지 대표적인 Use Case
> Launches ( = feature flag)
>> 일부 사용자들에게 (subset of users) 새로운 기능을 활성화 / 비활성화 할 수 있다
>> ex : "일부 사용자들은 앱에 대한 리뷰를 쓸 수 있는데, 모두가 쓸 필욘 없다" 이런 경우, 혹은 테스트 적용. 일부만 리뷰 창을 볼거임
> Experiments ( = A/B Testing)
>> 같은 기능을 제공하는 다수의 버전들을 서로 비교하기 위함
>> 가령, 좋아요 버튼이 오른쪽에 있거나, 왼쪽에 있거나에 대한 활성화 비율 등등
> 새로운 기능을 개발하고 Evidently 에 제출하면, "Code Snippet" 을 돌려 받아서 앱에 내장한다
> 사용자들은 정상적으로 앱에 액세스 한다
> 그리고 우리는 Evidently 로 가서, "Snippet" 에 있는 기능을 제공받을 유저의 % 를 지정한다 (혹은 A/B 중 어떤 걸 봐야하는지에 대한 비중) -> 이거 대로 유저들에게 보여짐
> 이와 같은 방식으로 Launces / A/B Testing 을 할 수 있게 된다
> Evidently 의 데이터들은 CW Log, S3 에 저장할 수 있다
> 마지막으로 Override 에 대해 알아둬야 한다 (시험에 나올 수 있음!)
> Beta Tester 가 조직 내부에 있다고 해보자. 새 기능에 배타 테스터가 접근하여 테스트하길 원한다고 하자.
> 이 때는 Evidently 가 적용될 수 없는게, random 한 n% 에 베타 테스터가 적용될지에 대한 Random 이 있기 때문
> 이 때 Override 를 사용. CW Evidently 에서 명시적으로 정의
>> ex, 특정 user id 인 사용자에 대해서, 새로운 피처를 표시하라 or 새로운 버전 b 를 표시하라 등을 지정.
>> Evidently 가 베타 테스터를 감지 후 무조건 Code Snippet 기능을 명시된대로 제공하게 됨
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [AWS] Certified Developer - Associate (DVA-C02) 자격증 후기 (1) | 2025.01.25 |
|---|---|
| [CDA] 섹션 30 - AWS 보안 및 암호화 : KMS, SSM Param 스토어 (1) | 2024.10.23 |
| [CDA] 섹션 29 - 고급 자격 증명 (0) | 2024.10.21 |
| [CDA] 섹션 28 - 기타 서버리스 : Step Functions & AppSync & Amplify (0) | 2024.10.10 |
| [CDA] 섹션 27 - 유저가 누군지 알아보는 Cognito (0) | 2024.10.06 |
