'Cloud Computing/AWS'에 해당되는 글 2건

  1. 2020.09.02 AWS 의 VPC 개념 설명
  2. 2018.12.04 AWS re:Invent 2018 - Keynote with Werner Vogels (CTO) 키노트 요약

어제 AWS VPC 네트워크의 개념에 대해서 배워서 정리해 봤습니다.

저는 OpenStack 을 오랫동안 해왔기 때문에 OpenStack 의 Neutron 로 비교하면 이해가 더 쉽게 되더라고요.

 

 

먼저 네트워크 대역을 만들기 위해서는 VPC 가 필요합니다. virtual 하게 만드는 것이기 때문에 10.0.0.0/16 과 같이 사설망 대역을 사용합니다.

그리고 외부와의 통신을 위해서는 Internet gateway (IGW)를 생성합니다. 이것은 software gateway 라고 생각이 들고 여기까지는 VPC 와 상관이 없습니다. 그래서 이해하기 쉽게 IGW 를 VPC 바깥에 그렸습니다.

IGW 를 VPC 와 연결 (associate) 하는 순간에 port 가 생성되어 연결될 것으로 보입니다.

 

VPC 내에는 subnet 을 만들어 Network 대역을 다시 나눌 수 있는데 subent 은 10.0.0.0/24 처럼 VPC 대역 내여야 하고, 하나의 subent 은 AZ 의 하나에만 할당될 수 있습니다. AZ 내에 하나만 할 당 할 수 있는 이유는 EC2 VM 을 만들면 VPC 내의 Subnet 을 선택하고, VM에 ip 를 할당하면서 해당 IP 에 대해서 s/w 적으로 연결이 될텐데 여러 AZ 에 대역이 펼쳐져 있으면 통신이 꼬일 수 밖에 없습니다.

그러므로 실제로 중요한 것은 VPC 라기 보다는 Subnet 입니다. Subnet 의 정보를 가지고 다 처리를 하는데 다만 통합적으로 관리할려고 VPC 라는 개념을 가져온 것 뿐입니다. 

 

Subnet 은 라우팅을 잡아야 하는데, 내부적으로는 VM 을 관리하는 Baremetal Host 서버에 라우팅을 세팅하기 위한 방법이 필요합니다. (혹은 Baremetal 에 떠 있는 software network switch 에서 라우팅을 세팅)

그래서 라우팅 테이블을 만들고 Subnet 에 연결(assocation) 해주면 그 라우팅 정보를 가지고 있다가 VM 이 생성될 때 세팅을 해줄 수 있습니다.

 

정리해보면 다음과 같습니다.

1. IGW 는 VPC 에 attach 하는 부분이 필요하다. (router 에서 인터넷으로 가는 GW port 를 연결하는 작업)

2. Route table 을 Subnet 에 association 하는 부분이 필요하다 ( VM 이 생성될 때 통신될 수 있도록 라우팅을 세팅해야 하므로 해당 정보를 이용)

 

AWS 가 내부적으로 어떻게 구성되어 있는 지는 모르겠습니다. 하지만 OpenStack Neutron 을 보면 저런 방법을 사용하고 있기 때문에 아마도 동작 방식은 비슷하지 않을까 생각합니다.

 

  

Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

처음에는 대충 볼려고 했는데 내용이 좋아서 끝까지 집중해서 봤네요. 전체 요약해 봤습니다.

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

Amazon Well-Architected



AWS Well-Architected Tool

  • Measure and improve your architecture using AWS Well-Architectured best practices


Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요