발품팔이 2019. 1. 13. 18:32

https://reinvent.awsevents.com/

갔다온지 좀 되었는데 ^^; 어떻게 하다 보니 이제야 후기를 작성합니다.

이번에 회사 지원으로 AWS re:invent 2018 행사에 다녀오게 되었습니다.

AWS re:invent는 매년 말 아마존 주최로 라스베가스에서 일주일간 진행되는 세계적인 AWS 관련 행사입니다.

개발자로서 꼭 참가 해 보고 싶은 행사 중 하나였습니다. 다시 한번 회사에 감사를 드립니다. :)

5일동안 수천개 (이번엔 중복 세션 모두 포함해 약 2300개) 의 세션이 열립니다. 이번엔 약 5만명이 참가했다는 얘기를 들었습니다..

이렇게 많은 인원이 참여하기 때문에 라스베가스의 엄청나게 커다란 호텔들을 대부분 사용하게 됩니다.

이번에 행사를 다녀오면서 느낀점과 팁 위주로 간단히 후기를 작성 해 볼게요.

행사 전

사전 세션 신청

매우 중요합니다.

세션들이 엄청나게 많지만, 사람들도 그 만큼 많이 참여하기 때문에 인기 세션들은 순식간에 마감되어 버립니다.

1일 1~2개의 호텔 위주로 신청

맨 처음에 흥미 위주로만 시간표를 짰더니, 매 세션마다 호텔을 옮겨 다녀야 했습니다.

구글지도 상으로는 다닐 수 있을 것 같았는데 실제 가 보니 무리입니다. 나중에 시간표를 다 재 작성 했습니다.

사람들이 많이 몰리기 때문에 길도 막히고, 제공되는 셔틀도 사람이 많아 빨리 타기도 어렵습니다.

그리고 호텔이 엄청나게 커서 도착하더라도 내가 신청한 세션 룸에 도착하기까지도 한참 걸립니다.

세션 시작 10분 전에 모든 예약이 취소되기 때문에 기껏 도착하더라도 못 들어갈 확률도 매우 높습니다.

매일 가장 듣고 싶은 세션들을 몇 개 선정 해 두시고, 그 호텔 위주로 필터링하여 시간표를 작성하세요.

매우 편합니다.

그리고 호텔을 옮겨다닐 때는 1시간정도의 여유를 두고 움직이시는게 마음이 편합니다.

Workshop 세션 추천

실습 세션이라고 생각하시면 됩니다. 따라서 노트북이 필수입니다.

문서만 보고 직접 사용해 보지 않았던 서비스들을 워크샵 세션에서 다양하게 Integration하여 사용 해 볼 수 있습니다.

일부 세션의 경우 참여하기만 해도 경품을 나눠주기도 합니다.

이번에 저는 DeepRacer라는 자동차와 아마존 에코 버튼을 받았습니다.

아마존 직원들이 직접 제공하는 프로그램도 참여해 보고 외국 개발자들과 커뮤니케이션도 해 볼 수 있습니다.

그리고 짭짤한 콩고물(?)도 챙길 수 있으니, 영어에 두려워 하지 마시고 꼭 신청 해보세요.

Repeat & Overflow 세션 활용

Repeat 세션은 말 그대로 재방송입니다.

인기가 많은 세션인 경우 여러번 해 줍니다. 요일이 다를 수도 있고, 호텔이 다를 수도 있습니다.

Overflow의 경우 원격 세션입니다.

예를 들면, A호텔에서 진행되는 세션을 B호텔에서 실시간으로 원격으로 방송 해 줍니다.

직접 그 분위기를 느낄 수는 없지만, 자리도 널널하고 헤드셋을 쓰고 시청하기 때문에 내용을 알아듣기도 좋습니다.

위 두 가지를 잘 활용하시면 호텔을 많이 옮겨다니지 않고 원하는 세션들을 대부분 들어볼 수 있습니다.

기타

re:invent 앱을 사전에 설치해 가세요.

시간표 조회나 행사 장소 확인 시 필수입니다.

실시간으로 변동되는 행사 정보들도 업데이트 됩니다.

안드로이드는 마켓에서 바로 설치 가능하나, ios는 미국 계정이 필요했다고 하네요.

라스베가스에 도착해서

사전 동선 파악

도착한 호텔의 AWS 행사장이 어디 있는지 미리 파악 해 두시면 좋습니다.

주요 로비가 어디인지, 세션장이 모여있는 곳은 어디인지, 점심은 어디서 주는지 정도를 파악 해 두시면 됩니다.

기본적으로 라스베가스 호텔들이 매우 크기 때문에, 사전 지식이 없는 상태에서 행사장을 찾으려고 하면 혼란에 빠질 가능성이 꽤 높습니다.

시간이 남으시면 묵는 호텔 외의 호텔들도 가 보셔도 좋을 것 같습니다.

시간 활용을 잘 하자 (?)

<음악 분수>

도착 당일 저녁 시간대를 활용해서 음악 분수와 서커스를 봤는데, 낯선 라스베가스가 좀 더 친숙해 질 수 있는 좋은 시간이었습니다.

주위에 개발자로 느껴지시는 분들이 매우 많아서, 왠지 친숙한 기분도 드는 신기한 경험이기도 했습니다.

주요 행사 후기

Midnight madness

re:invent는 정식으로는 월~금까지 진행되는데요. 시작 전 일요일 밤~새벽에 진행되는 특별 행사입니다.

맥주와 간단한 안주도 제공하는 좀 편한 키노트라고 생각하시면 좋을 것 같습니다.

밴드가 노래를 불러주기도 하는데요, 신규 서비스를 발표 할 때 마다 그에 맞춰서 노래를 불러 주는게 매우 인상적이었습니다.

행사 시작 시간에 맞추어 입장하신 분들은 Midnight madness 전용 티셔츠를 받으셨다고 합니다.

저는 줄 서는게 싫어서 한참 후에 입장해서 못 받았는데 좀 아쉽네요.

Keynote

<키노트 전경>

<키노트 중 - 업계별 비교>

re:invent의 꽃 키노트입니다.

화, 수, 목 삼일에 걸쳐 아침 시간대에 키노트가 있었는데요.

화요일은 글로벌 파트너 서밋 키노트

수요일은 AWS CEO인 Andy Jassy의 키노트,

목요일은 AWS CTO인 Dr. Werner Vogels의 키노트가 있었습니다.

개인적으로 화요일은 파트너사와 어떻게 협업을 하고 있는지, 얼마만큼의 성공 또는 성장을 거두고 있는지에 대한 내용이 주이기 때문에 적당히 들으셔도 될 것 같습니다.

수요일은 CEO인 만큼 신규 서비스에 대한 내용이 많았고, 목요일도 비슷하나 좀 더 기술적인 내용을 얘기하고 있다는 점이 약간 차이가 있었습니다.

CEO와 CTO의 키노트는 꼭 들어보시기를 추천합니다.

그리고 한중일 고객을 위해 번역이 제공되고, 미리 자리가 예약되어 있습니다.

번역을 듣지 않더라도 그 자리에 앉으시는걸 추천 드립니다.

빨리 앉을 수 있고 나가기도 편리합니다.

Expo

<전리품>

AWS의 수많은 파트너사들의 주요 홍보가 이루어지는 엑스포입니다.

서드파티 업체들 뿐만 아니라 AWS에서도 참여하여 질문도 받고, 오픈 세션들도 진행합니다.

Snowball edge cluster를 동영상으로만 보고 참 신기해 했는데, 직접 보고 심지어 굴려볼 수 있도록(!) 바닥에 아무렇게나 배치해 두었더라구요.

저는 티셔츠를 총 11개 받았는데요.

좀 더 운 좋으신 분들은 티셔츠 외에도 아마존 에코나 헤드폰 등을 받으신 분들도 있으니 수집의 재미도 느껴보시면 어떨까 싶습니다.

DeepRacer Workshop

가장 인상깊었던 워크샵 중 하나인 딥레이서 워크샵입니다.

이 딥레이서는 이번 키노트에서 신규 발표한 서비스 중 하나인데, 여러 센서와 조작 가능한 구동계를 가진 작은 자동차를 딥러닝을 이용하여 더 빠르게 달리게 하는 것이 목표입니다.

딥러닝 중에서도 강화 학습인데요. 어떻게 하면 좀 더 즐겁게 강화 학습을 배울 수 있을지 고민한 결과라고 합니다.

학습을 할 때는 온라인에서 진행하고, 실제 자동차에 학습 결과를 넣어 그대로 달리게 해 볼 수 있었습니다.

그리고 실제 레이싱처럼 리더보드도 제공해 경쟁심을 부추기게도 했습니다.

나중에 정말 레이싱을 할 거라는 얘기도 들었습니다.

딥레이서 워크샵은매우 큰 인기를 자랑했는데, 이 세션을 들은 전원에게 실물 DeepRacer를 제공했기 떄문입니다.

저도 3시간을 기다린 끝에 워크샵에 참여하여 수령했습니다 :)

Re:play

<re:Play 안내판>

<re:Play 전경>

AWS의 대미를 장식하는 re:Play 축제입니다.

밴드 공연, EDM 클럽, 단체 게임 등

개발자도 이렇게 재밌게 놀 수 있어를 보여주는 행사라고 해도 과언이 아닐 정도로 즐거웠습니다.

세션 내용 정리

매일 세션을 들으며 직접 정리 한 내용들입니다.

정리를 못 한 세션들도 있고, 빠르게 작성 한 내용들이라 읽기는 좀 어려우니 참고 용으로만 봐 주세요.

월요일 세션 정리

#1 SaaS Reference Architectures

다양한 환경에서 SaaS 기반으로 서비스를 변경할 수 있다. (with Legacy!)
골은 같아도 방법은 많다.
Silo, Bridge, Pool Architectures.
Saas Key Challange
    variable tenant load
    Sameless tenant identity - minimally invasive
    Variable data footprint - storage bottleneck, cost
    Operational agility - 작게 시작해서 빠른 변경이 가능.

SaaS Monolith
MSA SaaS with containers
    - Faster scaling, better agility, distributed data model ..
Serverless SaaS
    - ( API Gateway - Lambda - Storage Services )
    - Logical MSA. Better cost optimization story.
    - Simplified zero downtime deployments
Monolith, MSA, Serverless 비교
Storage partitioning 패턴
Role based isolation
VPC Per tenant, Namespace per tenant, IAM role, Lambda per function
Auth 방법에 대한 다양한 얘기
    - 코그니토를 이용한 토큰 등 (사진 찍어 둠)
    - External provider를 이용한 인증. 역시
    - Multi region auth : tenant별 region routing 시스템에서 region 컨트롤 진행하게 할 수 있음.

#2. Red team vs. Blue team

공격자 (Red team)이 read만 가능한 key를 탈취했다고 가정.
이걸 가지고 aws cli로 sg이름도 알고, vpc 이름도 알아내어 여러 가지 작업을 함. 결국 어떤 어플리케이션인지 알아내어 CVE로 해킹 성공.
Blue Team은 이런걸 막기 위한 방법을 여러가지 소개함. 하드코딩 하지마라. MFA 써라. SG는 SG간에만 통신 가능하게 하고 꼭 필요하지 않다면 인터넷 연결은 다 끊어라 등

#3. On-ramp neptune

3개의 질문을 받겠음
- 넵튠이 날 편하게 할 지?
- SQL과 비교해서 퍼포먼스가 어떻게 되는지?
- popularity
migrating to amazon neptune - 화요일 11:30

neptune: fully managed graph db
optimized for storing and querying highly connected data. 보통 10ms 내에서 응답한다. 매우 빠르다.
gd는 knowledge graph use case와 맞을 것 같다.
complex domain model
connected queries
6 replica across threew AZs.
support data models
poperty graph : thinkerpop, gremlin traversal language
RDF: w3c rdf graph models, sparkql
Gremlin: 알고 있던 graph model. vertices, properties, vertex, edge 등
RDF: subject-predicate(meta data)-object로 이어지는 Data model.
property graph에 대해 스키마가 필요 없다.
ThinkerPop / RDF <-> NEPTUNE <-> Cloud-native Strogate Service 로 이루어져 있음.
Multiple Master, Multiple cluster를 가질 수 있다. 아직 Cross-region은 서포트하지 않는다. 좀 더 성능을 올린 뒤에 Feature할 것.

화요일 세션 정리

#1. Give REST a Rest: easily migrate

GraphQL
Rest: Everything is a resource. server driven selection. multiple round trips to fetch related resources. over fetching/under fetching/under
GraphQL: Single HTTP call, Fetch exactly, co-locate resources.
GraphQL은 Response Result에 대해 신경 쓸 필요가 없다.
Pattern
    Wrap Rest API with GraphQL
        2개의 endpoint를 모두 제공한다. 클라이언트는 이를 선택해서 사용한다. 서버 사이드에서는 GQL이 Rest를 호출하는 패턴? 왜 굳이? 잘 모르겠다.
    Brand new endpoint using GQL
Authorization 방식에 따라 신경을 잘 써야 한다.
애매하네...
AppSync, Lambda랑 엮여서 설명. Caching layer도 같이 관리해 줌.
WebSocket을 지원하지 않는 문제가 있다.
Rest는 그대로 놔 두고, 버저닝을 해서 옮겨가는 것읓 추천.
Rest level 0가 데이터만, 상위 레벨이 HATEOAS같은걸 추가한 모델이라면, 현재 graphql은 Rest의 Level 0와 비슷하다.
Graphql endpoint를 single 람다에서 처리하는게 좀 이상해 보이는데, 어떻게 생각하는지?
Paging 어떻게 하냐? -> paging 관련 데이터를 스키마에서 같이 받아서 처리할 수 있다. appsync에서는 지원하지 않는다.

#2. Front end monitoring Hands on

http://search-sa-log-solutions.s3-us-east-2.amazonaws.com/logstash/html/Lab_Guide_ABD326.html
CF 이용해서 웹서버 및 ES, Beats 생성.
영화 검색 해서 로그 쌓아서 Kibana로 그래프 그려보는 것. es template 부어넣는 부분만 눈여겨 봄. 나머지는 익숙한 것들

#3. NEPTUNE

Highly connected db
GraphDB 도입시
- Massive scale, High operate 를 넘어야 함. 넵튠이 이를 얼마 정도 도와줄 수 있다.
부정 탐지 예제 시현
Tom saweyer perspectives: graphdb 툴

#4. Serverless Monitoring

모니터링을 위해 람다를 다양하게 설계. 로직 람다 -> 로그 스트리밍 받아 aggregation해서 쌓는 람다 -> 이벤트 알려주는 람다 등
이렇게 메트릭 직접 수집해서 보여줌. 좀 빡센데 하고싶은대로 만들 수는 있어서 좋은 듯.
뉴렐릭 사용하는거 보여줌. 그럼 뉴렐릭을 사서 쓰라는 말인가?

#5. Deep dive aurora with MySQL

기존 DB는 샤드를 어떻게 해도 Monolitic이다. Application딴에서 묶이던가, 로그 레이어에서 묶이던가, 스토리지에서 묶이던가.
오로라는 로그 부분을 아예 분리하고, 스토리지도 Shared multi-az storage를 사용해 매우 빠르다. repica시에도 write 할 필요가 없다. 더 좋은건 Storage를 더 살 필요가 없어 돈 절약.
오로라는 4개 또는 6개 Qurom(샤드같은것)을 3개 이상의 az에 분리한다. fault tolerance 유지를 위해.
MySQL은 저장되거나 Replication될 때, 로그 빈로그 데이터 double-write를 모두 동기화 해야 한다. 오로라는 로그와 FIMM?? 만 하면 된다.
쿼럼이 여러개이고 분리되어 있기 때문에, 병렬적으로 쓰기 할 수 있다. 겹치지 않게 write 해서 light-weight 하다.
load 있는 상태에서 200배 이상 빠르기도 하다.
2015년 런칭 이후로 계속 빨라지고 있다. (read, write 모두)
write 성능과 recovery 시간은 보통 trade-off 했는데, aurora는 둘 다 매우매우 빠름. no more trade off.
Multi master 구조에서도 쿼럼으로 동작하기 떄문에 문제가 없음.

#6. CI/CD serverless and containerized application

Serverless로 시대가 변하고 있음 lambda, fargate (serverless conntainers)
CI/CD의 장점에 대해 설명. 빠른 배포, 실패율 감소 등
CodePipeline 얘기. CodeCommit, Github랑 S3지원... 뭐 아는 얘기들. -> NEW!! Docker tag 추가! Amazon ECR 반영. 새로 올라오면 바로 돌아가게 됨.
CodeDeploy
    ec2, lambda, on-premise 서버에 배포. 만약 실패하면 자동 롤백.
    canary deploy 됨. 다만 실시간으로 모니터링 하면서 변경할 수는 없는 듯 하고, 설정으로 박아야 햠.
    후킹도 됨.
    NEW!! ECS blue-green deplyoment 추가
CI/CD에 컨테이너까지 완전 통합 됐네...
배포 시에 immutable한 tag와 함께 배포.
CD의 목표
    - 변경 시 자동 테스트 및 배포
    - client 충격 없이 safe한 배포
    - 빠른 신기능 추가한
IaaC는?
    - IaaC도 도입되고 있으니 인프라 변경도 CI/CD로 하고싶어요 라는 니즈가 생김
    - Build stage에서 unit test, 취약점 찾기
    - Test stage에서 디펜던시 테스트나 로드 테스트, 침투 테스트 등
SAM 에서 serverless 배포 설정 가능 - NEW!!!] sam build 라는 명령 추가
    - CodePipeline에서는 그냥 가능. 젠킨스에서는 SAM Cli Plugin 추가 가능.
AWS CDK(cloud development kit)이 개발자 preview로 새로 추가 됨. typescript로 한다고 함. CF를 typescript로 하는건가?
    - template화 해서 원하는걸 stack으로 쌓아서 인프라를 개발 할 수도 있음. 와우.
CodePipeline에서 CloudFormation도 지원. 원래 됐었는지는 잘 모르겠음. 아마 CDK랑 연동해서 하는 것으로 보임.

수요일 세션 정리

#1. ELB Deep dive and best practices

ALB 설명
    layer 7 lb.
    content-based routing.
    support websockets, http/2
    deletion protection
ALB Deeper
    EC2, IP, ECS로 rule에 따라 balancing 하는 예제 보여 줌
    Routing
        - IP as a target - RFC6598, RFC1918, and private ip 대역에 있는 IP들이 타겟이다
        - Content-based routing - path, http header의 host field에 따라 라우팅 함.
        - Redirect 기능 소개 (http -> http, http -> https, https -> https)
        - Fixed response
        - Slow start - warm up 에 대해 소개. linear하게 증가. optimal performance를 위해 cache warming이 필요.
        - Native IPv6 서포트 - dual stack으로 지원한다고 함.
    보안
        - IAM을 이용해서 admin이 alb를 컨트롤 하는 모델, admin이 ACM을 이용해서 컨트롤 하는 모델.
        - predefined security policies
        - AWS WAF와 결합된 ALB 모델
        - SNI (Server Name Indication). 자동으로 여러 클라이언트간에 TLS 인증을 취적화하고 연결. - 어떻게 동작하는지는 잘 모르겠음. 찾아봐야 할 듯.
        - ALB에서 Cognito를 이용해서 타 업체의 인증(페북 등) 처리 가능
Netflix use case
    Netflix Identity Platform을 Identity-as-a-Service라고 얘기.
        OpenId, oAuth, SAML등 모든 것들과 통합.
        SSO도 잘 됨.
    왜 Application LB에서 이걸 해 주면 안될까?
    Spinnaker를 잘 쓰고 있다.
Tag 기반으로 한 Tag load balancers (?)
Availability
    cross-zone lb 얘기.
    health check 얘기.
Scailabity
    - Auto scale 가능. 다만 시간이 좀 걸린다.
    - ALB가 K8S랑도 가능. k8s ingress controller를 통합. ECS, EKS랑 통합할 시 매우 빠른 Auto scale이 가능.
Monitoring
    - cloudwatch, access log...
아키텍팅 모델 알려 줌.

#2. Pokemon's Battle Against the Bots

Are bots a problem?
    - 가짜 계정, 인증 문제, 유저들의 분노 등...
2017년 발표 - bit.ly/2IRCjGn
CF에 WAF, Shield까지 사용.
불법 계정이 너무 많았다.
시작부터 다시 시작했다.
CF 로그 -> Kinesis Firehose -> Kinesis Analytics / Athena 를 이용해서 serverless 데이터 분석.
    - amzn.to/2RFpGlL
봇은 대체 누구인가?
    - ip 대역이나 매칭으로 제거하기 시작함
    - 다음 도전: High touch, Shifting strategies, Audit trails 등
우리의 무기는?
    - 목표: 돈 줄이고, false positive 리스크 줄이고, 설정 후 잊을 수 있어야 함 (set and forget), audit trail 가능, All serverless, So much scale, Fast to implement
putting together the winning deck
    - kinesis analytics를 이용해 분석
    - dynamo에 timeseries와 함께 적재
    - WAF 로그를 쌓고, 블랙리스트 IP를 람다를 이용해 WAS IP List에 자동으로 업데이트 가능하도록 구성.
Scaling lambda
    - 변수 재사용: in memory cache를 사용할 수 있기 때문에 빨라진다.
    - Rule logic
Scaling DynamoDB
    - throuughput dilution ( 아까 on-demand 발표해서 이제 괜찮을 듯 함 )
    - 필요한 만큼만 데이터를 유지해라 (go TTL)

Second change
    무엇이 바뀌었나?
    - whitelist 아키텍처를 단순화 함.
    - 룰을 Dynamodb 테이블 형태로 변경.
    - Kinesis Data analytics 단순화
추가 예정
    - 상세 IP 정보 획득
    - 반복되는 공격은 더 센 처벌
    - 분, 시간, 일 단위 제한
bit.ly/2J2OfoJ - 블록 데모: 계속 요청하면 403 블록됨

#3 ElastiCache Deep dive. design patterns

What's new?
    Redis 5.0
    Memcached 1.5.10

Redis 5
    - redis stream의 추가
    - 설정 변경하면 application 수정이나 maual step 변경 없이 자동으로 진행 됨.
New! ElastiCache에 맞게 최적화 된 M5나 R5의 경우 약 2배가량의 성능 향상을 보임.
New! ElastiCache가 250개 node 서포트
커밍 순 - multi core 노드 퍼포먼스 부스트, 커맨드 리네임, 패치

Deep Dive
    redis
        - fast, ha, kv store, various data structures, backup/restore
        - self manage하기는 굉장히 도전적이다 - 미니지 힘듬, ha 구성 힘듬, scale하기 힘듬, 비쌈 (사람 포함)
        - cluster mode disabled : vertically scaled. 는 disabled 됨.
        - cluster mode enabled: Cluster Map을 가운데 둔 horizontally.

IoT 뒤에 연동하여 데이터 저장
Kinesis Data Stream 뒤에 decorate하거나 필터링 하여 데이터 저장
Mobile에서는 Geospatial 데이터를
Graph나 Search 데이터도 가능

캐싱 전략
    - Lazy loading
    - Redis Write back
    Cluster sizing best practices
        Storage
        - 필요메모리 + 25% 레디스 사용 메모리 + 10% 정도 여유분
        - TTL과 evict 정책 최적화 할 것
        Performance
        - read는 replica. write는 shard. network는 type바꾸던지 scale out (shard)
        - 파이프라인이나 벌크 잘 이용해라
        Cluster isolation
클라우드워치 모니터링에서 제공하는 메트릭들 쓸 만 하다.
    - 종류에 최적화 해라. scale up/out을 하던가, TTL을 취적화 하거나...
    - lambda가 할 수도 있음.

#4 Breaking observability Chaos: Best Practices to Monitor AWS Cloud Native apps

민첩성 -> 팀에 권한 부여 -> 발전 -> 고객의 행복
메트릭, 로그, 이벤트, Tracing 이게 다 Observability이다.
IoT 얘기인데, 그거에만 한정되어 생각하지는 않아도 될 듯.
github.com/aws-samples/aws-iot-core-acmebots-monitoring
bot이 publish하면 AWS IoT가 받아서 backend에 publish, custon event 발생, lambda에서 이벤트 받아서 cloudwatch에 적재
Operational Insights
    - 메트릭들을 당신 비즈니스에 맞게 조절하라
    - CloudWatch custom metric을 써라.
    - 개발 과정에서 대시보드를 미리 고려하고, 포함하라
Troubleshooting
    - Cloudwatch를 이용한 로깅 및 알람
    - X-Ray로 backend tracing하여 디버깅 및 사후 관리. dynamodb와 같은 AWS 서비스들도 잘 보여준다. Service Map도 잘 나온다.

Best Practices
    1. 비지니스 플랜에 맞춰서 모니터링 전략을 잘 세워라.
    2. 앱에서 모니터링 리소스들을 보내서 쌓아라
    3. 메트릭, 로그, 이벤트, 트레이싱 정보 이렇게 4개를 모아라.
    4. 모든 것을 모니터링하라: 서비스, limit, 비용, API 통신, 기타 등등.
    5. 더 잘 알기 위해 AWS 서비스들을 활용해라. cloudtrail, config, trust advisor 등등...

#5 S3 Batch Operations

S3 -> S3 IA -> Glacier
S3 -> S3 Intelligence -> Glacier
Intelligent-Tiering
    - Frequent tier, Infrequent tier
    - 자동으로 사용 패턴 분석해서 cost 감소시키게 해 줌.
S3 -> S3 Intelligent-Tiering -> S3 IA -> S3 One Zone IA -> S3 Glacier 로 이렇게 5개 티어가 됨. (Glacier Deep Archive가 더 추가될 예정이긴 함)
Intelligent-Tiering은 S3랑 S3 IA 사이의 가격 정책을 가짐. 그 아래로 가려면 직접 컨트롤 해 줘야 함.
S3 Inventory
Batch operations
    - Object 선택(S3 Inventory report or CSV list) -> Operation 선택 (copy, restore from glacier, acl put, replate tag set, run lambda functions) -> 진행률 보기 (object level, noti, complete)
    - 수십억 이상 object에도 문제없이 됨.
Glacier에서 다 restore하고 싶은데 어떻게해요 같은 경우 유용함
Batch operation - 자동 재시도, Scalability, Progress visibility, Mnagement, Notifications, Auditing
app을 유지하거나 따로 빌드 할 필요가 없음
Cron job 형태로도 제공
Lambda function을 이용해 customized job 추가할 수 있다고 함.
1000개 수행했는데 fail이 50% 이상 나면 중지 됨.

목요일 세션 정리

마치며

GraphQL과 Neptune, 그리고 기존 서비스의 Deep Dive 세션 위주로 들었는데요.

API를 개발하는 업무를 진행하고 있는 입장에서 굴지의 회사들이 Rest나 GraphQL에 대해 어떻게 생각하고 있는지, 그리고 이를 뒷받침하는 GraphDB나 Serverless와 같은 기술들이 어떻게 발전되고 있는지 들어볼 수 있었던 좋은 선택이었습니다.

또한 AWS에서 제공하는 서비스들을 어떤 생각을 가지고 설계했는지와 앞으로 어떻게 개발 할 것인지 등 그 자리에 있지 않으면 들을 수 없는 얘기들도 접해서 매우 인상 깊었습니다.

위의 세션 외에도 북적한 엑스포에 수십명의 사람들과 linux 강의를 듣거나 신규 서비스 발표가 흥겨워 맥주를 들고 옆 개발자와 함께 춤추던 기억은 쉽게 잊혀지지 않을 것 같습니다.

전세계 개발자들의 축제에 함께해서 즐거웠고, 굉장한 경험이었습니다.

혹시 re:Invent에 관심을 가지시는분들께 이 글이 좋은 참고가 되길 바라며 이만 글을 마칩니다 :)

저작자표시

'발품팔이' 카테고리의 다른 글

2010 인텔 소프트웨어 컨퍼런스 후기 (0)	2010.10.15
스타크래프트2 GSL 1회 결승 후기 (1)	2010.10.05
REMIX09/web 후기 (6)	2009.09.25

ABOUT ME