AWS Summit Seoul 2019

시간이 지날 수록 얻어가는 insight가 점점 늘어가는게 느껴져서 뿌듯했던 summit

 

2019.04.18  Day2 참석

 

지속적인 성능과 확장을 보장하는 마이크로 서비스 패턴 데이터베이스 구현하기★★★

결론 : Multi Datastore를 구축해라

1. Multi Datasore의 예시

롯데에서 강연했는데 lotte 쇼핑몰?의 경우

Massive Scale Transactional : Amazon DynamoDB (ex : Product Item Details)

Real-Time Cache : Amazone ElastiCache (ex : Real time product list display)

Reporting : Amazon Redshift (ex : BI reporting based on S3 Data lake)

Relational User Data : Amazon Aurora MySQL (ex : Admin, Orders, Product catalog)

 

2. Rdb - 익숙함이 주는 고통

#1 relation(정규화) - 설계 이후 추가 되는 업무에 따른 잦은 설계 변경

#2 단일 SQL 문으로 튜닝 - 복잡한 로직을 단일 쿼리로 몇 초 만에(수백라인 쿼리)

#3 로직을 담은 Stored Procedure & Function으로 대체 - 개발 편의 call만하면 끝, 장애 또는 로직 오류시 전체로 확산

#1-3의 반복으로 많은 비용이 소모됨

 

3. Multi Datastore 선택이 아닌 필수, Multi datastore를 위한 기준

managed service 중심 architecture 설계

Architecture 중심이 아닌 서비스 중심 architecture 설계

* managed service

데이터 in/out을 위한 비지니스 본질만 관리

* 서비스 중심 architecture(Serverless Architecture)

업무 성격에 따라 다양한 저장소 및 architecture 적용

데이터 로직 중심이 아닌 MSA 기반 서비스 중심으로 무게중심 변화

* 목적에 맞는 다양한 Data sotre / Data lake

SQL, Procedure, Functino 중심적인 설계/개발 X

Nomalization -> DQM

2PC - transaction 분리 / API 레벨에서 데이터 무결성 관리

 

목적에 맞게 분리(Tier-0, Tier-1, Data lake) 및 다양한 Data store 사용

데이터 특성(HOT/WARM)에 따른 적합한 저장소 후보

고려사항	Hot Data		Warm Data				Cold Data
	Amazon ElasticCache	Amazon DynamoDB	Amazon Aurora(MySQL)	Amazon Elasticsearch	Amazon EMR / Athena / RedShift	Amazon S3	Amazon Glacier
Average Latency	* 발표 자료 참고
Data Volume
Item Size
Request rate
Durability

전통적인 데이터액세스(RDB)

- 단순 CURD

- simple query(N건)

- 적은 양읭 range data access

- not scalability

다량의 정형/비정형 데이터 집계

- S3 Data lake 기반의 Athena or EMR

- Redshift

DynamoDB

- 낮은 latency를 보장해야 하는 업무 : 주문, 이벤트(~ms)

- 잦은 스키마 변경이 에상되는 업무 : 상품 상세(Schema Free)

- 다량의 컨텐츠 데이터가 발생 되는 업무 : 게시판, 상품평(Scale-Out)

 

4. Database 에서 Data Store가 되기위한 check point

데이터 중심적인 사고에서 서비스 중심적인 사고

- SQL 문장으로 모든것을 해결하고자하는 노력 배척

- API / Eventual Consistency

데이터 동기화의 개념 ETL -> Data stream process template 적용

- data stream pipe line API 방식 공통 서비스로 제공(CDC로 ETL 사용 X)

데이터 스토어 용도에 따른 철저한 분리

- 대고객 업무에 있어 RDB > NoSQL로 전환 적극 고려

- 메모리 데이터 저장소 주류로 진입

==> 베이스가 아닌 단순 데이터 저장소로의 변화

 

nosql - API단에서 데이터무결성을 관리해야함 
RDB에서의 정규화는 현 비지니스의 정규화, 그런데 비지니스는 계속바뀜 
MSA란 비지니스 중심적 관점을 가지는 것
목적에맞는다양한 data store, data lake - 데이터레이크부분 데이터인아웃부분 구분하겠음 
쇼핑몰에서 상품상세, 이벤트, 상품평 같은 대량 및 스키마가 자주 변경되는 것은 다이나모디비

다이나모디비는 잘 받아들이는게 목적 꺼내쓰는게 쉽지는않아- 조회가 어려움, group by등.. 
message broker로 다이나모디비사용 

 

*ETL

Enterprise Architecture 에서 중요한것중의 하나가 ETL (Extract Transformation Loading)이다. 쉽게 이야기 하면, 비동기적으로 파일이나 DB간에 데이타를 동기화 해주는 솔루션인데 기업 아키텍쳐에서 흔히 Near Real Time이라는 형태의 Async로 구현되거나 또는 Batch성 작업으로 분류
출처: https://bcho.tistory.com/325 [조대협의 블로그]

*oltp

* message broker

 

<eunhye's>

1. 요구사항을 받고 DB 설계를 할 때 개발자들은 이 데이터를 뽑기 위해 쿼리를 어떻게 할 수 있을까를 생각하는데 SQL 문장으로 모든 것을 해결하고자 하는 노력을 배척해야한다라는 말

2. 데이터중심 적인 사고에서 서비스 중심 적인 사고를 해야한다.

3. database가 아니라 data just store가 되어야한다. DB를 정말 데이터 저장소로만 생각하고 서비스를 중심으로 생각해야한다는 점!!

 

 

스폰서 세션 | SAP, 아마존 클라우드에서 어떻게 하면 잘한다고 소문이 날까? AWS 클라우드 환경에서 ISMS-P(정보보호 관리체계) "인싸"가 되는 핵심 Point

ciso,sap
주제: 어떤부분을 먼저 클라우드로 옮길까
least critical한것부터 - 근데 사람마다 leat critical이 다름
log collector와 log 분석을 aws 서비스사용- appstream2.0,elastic search,
인증심사원이랰ㅋㅋㅋ
2019년부터 isms-p 도입 : isms+pims
asset관리, id acess mngt, patch및config에 대해
1. asset : 분류체계를 on prem과 다르게해야함, 기존은 물리 자산단위였다면 클라우드에서는 서비스단위로 ex customer infra admin infra
2. id& access mngt : 
idaas casb(cloud access security ....)
3. patch&config mngt :miss config..
4. event logging &monitoring:

 

 

클라우드 네이티브 환경에 맞는 IT 운영 원칙과 모범사례

 

cloudformation template -> awslabs깃허브에올려져있음
aws cdk
서비스 카탈로그 - 
lambda workflow
좋은 dashboard 란 간결한거 딱봐서 이거문제있네?이거이상하네?를 확인할수있는것
개별 ec2 인스턴스의 cpu util보다는 오토스케일링그룹의 cpu util을 확인
내가 관리하고있는 aws resource에 어떤 변경사항이있는가?(가시성확보)-멀티리전멀티어카운트.. 그래서 어려워ㅜㅜ 이때
aws config&config rule - action까지 가능
명시적으로 enable 시켜야함
aws config advanced query
aws rdk(rule develop kit)
태그에 cost가 포함되어있는지 이런 룰도 만들 수 있음
aws systems manager documents - 서버또는 ec2,on prem연동가능,agent설치필요
compliance as a code