반응형
처음에는 대충 볼려고 했는데 내용이 좋아서 끝까지 집중해서 봤네요. 전체 요약해 봤습니다.
AWS re:Invent 2018 - Keynote with Werner Vogels
2004-12-12 Amazon Oracle 장애 Lessons learned
- SOA (Service Oriented Architecture) 로 서비스를 Flexible 하게 구성하였으나 Database Oracle의 로깅 코드 버그로 장애 발생, 12시간 동안 크리스마스 시즌 주문을 받지 못함
- Oracle 은 SPOF (Single Point of Failure) 이고, Black Box 라 scale, reliability 를 높일 수 있는 방법이 없었음.
- 1차 변경: Sharding 을 통해 데이터를 분산하여 performance 와 reliability 를 높힘
- Reducing your blast radius : 장애가 발생하면 모든 면에서 영향을 최소화 해라.
- 2차 변경: Cell based architectures 로 변경 (cell 단위 독립적으로 구성, 한 곳에 문제가 생겨도 영향도를 최소화함)
- Cell based Architectures: AWS 는 모두 Cell 단위로 구성되어 있음 (심지어 AZ (Availability Zone) 안에서도 Cell 단위로 구성되어 영향도 최소화 했음) → 근데 왜 한국 Region 은 장애가....???)
- AZ 서비스에서 DynamoDB 는 Cell 단위로 구성되어 DB 장애가 일어나도 최소화 됨.
- Relational databases: not designed for the cloud (Sharding 을 하더라도 결국 Database 로 인해 서비스가 종속되게 됨)
- Decompose the system into fundamental building blocks -> 그래야 multi tenant, fault tolerant, self healing 서비스를 구현 가능
Amazon Aurora: Scaled-out distributed architecture (Database aware storage service)
- AWS 에서 가장 빠르게 성장하는 서비스 중에 하나임
- AZ 단위로 분산이 가능하고 Cell based Architectures 로 mission critical 한 서비스 구현이 가능
- On quorums and failures 를 적용하였기에 이런 서비스를 구현 가능했음 (AZ 단위로 분산)
- AZ 마다 2개의 인스턴스를 띄우고 AZ 가 하나 죽고 다른 AZ 에서 인스턴스 1개가 죽어도 read 는 가능, 하지만 쓰기는 못함
- 10G 링크로 되어 있어 click 만으로 빠르게 복구되어 MTBF(Mean time between failures) 와 MTTR(Mean time to repair) 를 줄일 수 있음
- Aurora 는 log 만 복사하기 때문에 복제 및 복구가 빠름 (storage node 에서 복사가 이루어짐)
- AWS Aurora 는 Cloud native database as a foundation for innovation 이다.
ASW 유형별 Databases 종류
- Relational - Amazon Aurora, Amazon RDS
- Key Value - Amazon DynamoDB
- Document - Amazon DynamoDB
- In-Memory - Amazon ElasticCache
- Graph - Amazon Neptune
- Time-Series (New) - Amazon Timestream
- Ledger (New) - Amazon QLDB
How to migrate Oracle to DynamoDB
- Amazon item master service : sharding 된 Oracle databases 24개로 구성 (6,000억 레코드가 있으며, 50억 update 가 1day 에 일어남), 1년에 30~40% 정도 증가함
- Oracle 을 DynamoDB 로 변경 (schema 변경 및 Database Migration 진행)
- Database Migration Service (6,000억 레코드 migration을 live 로 진행)
AWS S3 - Mai-lan Tomsen Bukovec (Vice President, Amazon S3 and Glacier)
- 전체 10 Trillions objects 가 저장되어 있음
- 한개의 리전에서 최대 1초에 60 Terabytes 를 관리함
- 초기에 8개의 microservices 로 구성됨, 현재는 235개 이상의 분산 mircroservices 로 구성됨
AWS Redshift
- 2018년 11월 1일 아주 큰 Oracle data warehouse 를 Redshift 로 옮김 (올해 가장 기쁜 순간)
- 성능 향상을 이룸
- 지난주 (11월 4째주) Redshift concurrency scaling 기능 새로 소개
AWS Lambda
고객들이 serverless 로 가려고 하는가?
- No Infrastructure provisioning, no management
- Automatic scaling
- Highly available and secure
- Pay for value
- 2014년 Preview 공개 후 2015년 GA 로 오픈
- Worker: 고객의 function 코드가 로딩되고 실행되는 환경
Firecracker (New): serverless computing을 위한 안전하고 빠른 microVMs
- KVM hardware virtualizations
- 실행되는데 125ms 소요 (1개의 호스트에서 1초에 150 microVMs 실행 가능)
- 1개의 microVM 당 5MB 메모리 사용 (1개의 호스트에 수천개의 microVM 을 띄울 수 있음)
- Lambda runtime 환경
AWS 의 기능과 서비스의 95% 고객의 피드백으로 부터 개발된 것임
AWS Toolkits 새로운 IDEs
- PyCharm
- IntelliJ
- VS Code
AWS Lambda 신규 기능
- 사실상 모든 언어 지원 가능해 졌음
- 기존 지원 언어: NodeJS, JavaScript, Python, Java, .Net, Go
- 신규 지원 언어: Ruby
- Lambda 에 Custom Runtime 적용 가능 (Ruby 도 그렇게 구현한 것으로 C++, Erlang 등 다른 언어 들도 적용하여 쓸 수 있음)
- Lambda Layers: Lambda 를 라이브러리 형태의 함수로 만들어 재사용 가능
- Nested Applications using Serverless Application Repository (New)
AWS Step Functions
- 기존에는 workflow 를 Sequential steps, Parallel steps, Branching steps 로 지원
- Step Functions service Integrations (New): Step Functions 을 AWS 의 8개 서비스와 함께 쓸 수 있게 지원
- Step Functions 함께 쓸 수 있는 AWS 8개 서비스: Batch, ECS, Fargate(컨테이너 배포 서비스), Glue(ETL서비스), DynamoDB, SNS, SQS, SageMaker
AWS API Gateway 에서 WebSocket 지원
- WebSocket 을 통해 Stateful 지원 가능
AWS ALB 에서 Lambda 지원
- ALB (Amazon Load Balancer) 뒷단에 Lambda 를 바로 연결 가능
Amazon Managed Streaming for Kafka
- Fully managed and highly-available Apache Kafka service
AWS Well-Architected site
AWS Well-Architected Tool
- Measure and improve your architecture using AWS Well-Architectured best practices
반응형
