[Amazon Webservices] Amazon Webservice 기초 개념

Amazon Webservice 기초 개념

EC2 Autoscale

• 수요에 따라 인스턴스를 추가, 불필요한 인스턴스는 폐기
  • 24시간 내내 적절한 인스턴스만 유지 가능
• 두 가지 접근 방식(함께 사용 가능)
  • 동적dynamic 조정: 수요 변화에 즉각적으로 대응함
  • 예측predictive 조정: 예측된 수요에 따라 자동으로 EC2 인스턴스를 예약함

• EC2 Auto Scaling 구성 예시
  • Auto Scaling의 최소 그룹의 크기: 1
    • (적어도 하나 이상의 인스턴스는 항상 실행 중이어야 함)
  • 희망 용량 그룹: 최소 용량과 별개로 희망 용량 지정, 미지정시 최소 용량
  • 최대 용량 그룹: 수요 증가에 따른 최대 용량 지정

• 수직 확장과 수평 확장
  • 수직vertical 확장: 인스턴스의 성능을 높임(인스턴스 패밀리 변경)
  • 수평horizontal 확장: 인스턴스의 개수를 늘림(Autoscaling, 수요 폭주 시 아주 유용)
  • 시스템 분리: 프로세스 각 부분마다 개별적으로 확장 가능
    • (ex: 캐셔 3명, 바리스타 2명)
  • 처리 후 필요 없는 인스턴스를 제거해도 됨

Elastic Load Balancing (트래픽 리디렉션)

• Load Balancing
  • 트래픽을 여러 인스턴스(리소스)로 분산시켜 주는 것
    • (쉽게 말해 어느 한 EC2 인스턴스가 대량의 워크로드를 처리할 필요가 없도록 분산(라우팅)시킴)
  • 고성능, 비용 효율성, 고가용성, 자동 확장 가능한 시스템을 구현할 수 있게 됨
  • Load Balancer를 통해 Load Balancing을 구현한다

• ELB (Elastic Load Balancing)
  • Elastic Load Balancing 및 EC2 Auto Scaling은 별도의 서비스이지만, 서로 연동 가능
  • Auto Scaling은 수요에 따른 인스턴스 수를 자동으로 조정하고, ELB는 (Auto Scaling이 조정한 인스턴스들에 대해) 트래픽을 골고루 분배한다 (차이 알아 두기)
  • Regional Construct (리전 구조, 추후 학습) > 사용자의 작업 없이 자동으로 고가용 서비스 구축 가능

• ELB의 작동 방식
  • 외부 트래픽에서의 작동
  • • 트래픽 증가 > ELB의 자동 확장 기능으로 트래픽 전부 수렴 > Autoscaling 작동하여 추가 EC2 작동 > 추가 EC2가 온라인이 되면 Autoscaling은 ELB에 준비됨을 알림 > ELB는 추가 EC2를 포함한 전체 EC2에 균일하게 트래픽 분배
    • 트래픽이 감소 > ELB는 이미 들어온 요청이 완료될 때까지 신규 트래픽을 중지 > 기존 요청이 완료되면 Autoscaling은 추가 EC2를 종료 > Autoscaling은 기존 트래픽의 중단 없이 필요 없는 인스턴스(EC2)를 종료할 수 있게 됨
• 내부 트래픽(Backend-Frontend 사이)에서의 작동
• ->
  • autoscaling only -> use ELB
  • 기존의 경우: 모든 Frontend는 모든 Backend를 인지하고 있어야 함(효율적인 인스턴스 유지 불가)
  • ELB 사용 시: 트래픽 관리를 알아서 조정해 줌, Frontend는 실행 중인 Backend를 인지할 필요 없음
    • 백엔드/프론트엔드가 완전히 분리된 아키텍처를 구현할 수 있다(Regional Construct 구조)
• Backend규모 조정(증가) > 새 Backend 인스턴스가 준비됨 > ELB는 추가 인스턴스를 포함한 전체 EC2에 균일하게 트래픽 분배 > 효율적인 규모 조정 성공
• ELB는 효율적인 Backend 통신 방법 중 하나일 뿐임

리전과 가용 영역

• AWS Region
  • 데이터센터의 근본적인 문제
    • 자연 재해가 발생했을 때, 큰 리스크
    • 백업 데이터 센터 구축: 추가 비용이 지나치게 많이 듦
  • AWS의 Region: 지리적으로 격리된 영역
    • 트래픽 수요 지점과 가장 가까운 곳에 데이터센터를 구축함
    • 각 리전에는 장비가 구비된 데이터 센터 존재
    • 각 리전은 광섬유 네트워크를 통해 다른 리전과 연결되지만, 명시적 허용 없이는 서로 격리되어 있음
  • 각 Region은 해당 국가/지역의 법률이 적용됨
    • 정부 규정으로, 데이터의 국가 반출이 불가능한 경우가 있기 때문
    • 명시적으로 허용하지 않은 한, 다른 리전의 사용자가 유입되지 않음
    • (자격 증명, 권한을 통해 데이터 내보내기를 요청해야 함)
      ex) 상하이 리전의 정보가 중국 밖으로 벗어나지 않게끔 해 준다

• 리전 선택 시 고려해야할 4가지 비즈니스 요인
  1. 법정 요구사항 준수 (compliance)
     다루는 데이터가 국가 반출이 불가능한 경우, 해당 국가의 리전을 선택한다(제일 중요)
     ex) 회사의 모든 데이터는 영국 내에서만 저장되어 있어야 한다는 규정
  2. 근접성 (proximity)
     속도가 중요하기 때문에 고객 기반의 근접성을 고려한다
     ex) 일본 고객이 많으면 일본 리전을 택함
     
  3. 기능 가용성 (feature availability)
     특정 지역별로 제공하는 서비스가 없을 가능성이 있다
     ex) 중국 리전은 Braket을 사용하는 물리적 하드웨어가 준비되어 있지 않음
     
  4. 요금 (pricing)
     동일한 서비스를 제공하더라도, 특정 지역은 운영 비용이 비쌈
     ex) 브라질의 경우 세금이 비싸서, 동일한 워크로드를 쓰더라도 50%정도 더 비싸다)
     비용이 중요하다면, 주 고객층이 브라질이어도 미국 리전이 더 나을 것임
     

• 가용 영역(Availability Zone, AZ)
  • 가용 영역: 리전 내의 단일 데이터 센터 또는 데이터 센터 그룹
  • 재난을 제대로 대비하려면, 리전 내부에서도 데이터 센터(가용 영역)가 붙어 있으면 안 됨
    -> 가용 영역은 (광속이 허락하는) 최대한 멀리 떨어져 있음
  • 하나의 리전에서, 2개 이상 가용 영역에서 실행
    • EC2를 하나를 생성하면, 하나의 가용 영역에서 실행됨
    • 따라서 적어도 2개 이상의 EC2를 중복 생성한 뒤, 각각 다른 가용 영역에서 구동해야 안전함
    • 이 모든 것은 AWS가 알아서 처리해 준다(ELB, SQS, SNS 등)

• 에지 로케이션(Edge Location)
  • Amazon Route 53: 아마존의 Domain Name Service(DNS)
    -> 짧은 지연 시간으로 고객을 올바른 웹 위치에서 서비스되게끔 함
  • AWS Outposts: 사용자의 데이터센터 내부에서 작동하는 소형 리전
    -> AWS가 소유하고 관리하며, AWS의 모든 기능을 사용할 수 있다
  • Amazon CloudFront: 아마존의 콘텐츠 전송 네트워크(Contents Delivery Network, CDN)
    -> 콘텐츠를 전 세계에 짧은 지연 시간으로 빠르게 전달하는 서비스
• 에지 로케이션: Amazon CloudFront가 더 빠른 콘텐츠 전송을 위해 고객과 가까운 위치에 콘텐츠 사본을 캐시해 준다
  • 리전에 있는 콘텐츠를 전 세계 에지 로케이션에 캐시 가능
  • ex) 브라질의 데이터를 중국에 서비스하는 경우
    모든 데이터를 이동할까? NO
    중국과 가까운 “에지 로케이션”에 데이터 사본을 캐시한다 -> 더 빠르게 데이터 제공 가능
    

• 내가 그린 그림으로 한눈에 이해해 보자

아마존 웹 서비스의 네트워크

• Amazon Virtual Private Cloud (VPC)
  • AWS 리소스에 경계를 설정하는 데 사용할 수 있는 네트워킹 서비스
    (논리적으로 격리된 가상 프라이빗 네트워크)
  • 서브넷
    • VPC 내부에서 IP 주소의 모음, 리소스를 그룹화(바리스타/계산), 리소스를 public/private할지 결정함
  • VPC으로의 트래픽을 제어하는 두 가지 방법
    • 공개 서브넷: 대중이 접근할 수 있는 인터넷 연결 리소스(공개 웹사이트)
    • 프라이빗 서브넷: 로그인을 통해 접근해야만 하는 리소스(백엔드 서버 등 내부 서비스)

• 인터넷 게이트웨이(IGW)
• • VPC에 공개 트래픽이 출입하도록 하려면 게이트웨이가 필요
  • 인터넷 게이트웨이가 없다면, 아무도 VPC 안의 리소스에 접근할 수 없다
  • 대중에게 공개된 접속 출입구(카페 정문)

• 가상 프라이빗 게이트웨이
• • VPC에 승인된 사람만 허용(비공개 출입구)
  • 비공개, 암호화 기능
  • 사내 네트워크 같은 VPC에 VPN 연결을 만들 수도 있다

• AWS Direct Connect
• • 가상 프라이빗 네트워크만 쓰면, 여전히 퍼블릭 트래픽과 같은 대역폭 연결을 쓰게 됨
    -> 다른 사람과 공유되지 않는 전용 연결이 필요
  • 짧은 지연 시연과, 높은 수준의 보안, 대역폭 문제 해결, 규정 준수 사항 충족
  • 물리적인 광섬유 회선을 제공하여 완전한 비공개 연결을 구축 가능
  • 하지만 엄청 비싸겠지?

• 단일 VPC에 여러 유형의 리소스를 위한 여러 유형의 게이트웨이가 존재할 수도 있다
• • 왜냐하면 VPC 내부에 다양한 서브넷이 존재하거든

보안 그룹, ACL

• 서브넷의 보안
  • Network Access Control List (네트워크 액세스 제어 목록, ACL)
  • 서브넷으로 들어오는/나가는 패킷(트래픽)을 검사함
  • Stateless(상태 비저장) 패킷 필터링: 패킷에 대해 기억하지 않음, 매번 검사를 진행
    모든 인바운드 트래픽 허용 (들어오는 것, 거부 규칙 지정 가능)
    모든 아웃바운드 트래픽 허용 (나가는 것, 거부 규칙 지정 가능)
    
  • ACL의 한계: 서브넷을 지나친 패킷이 인스턴스에 도달했는지는 알 수X

• (서브넷 내부에서)인스턴스의 보안
• • 보안 그룹(Security Group)
  • 인스턴스에 들어오는 패킷(트래픽)을 검사함
  • Stateful(상태 저장) 패킷 필터링: 한번 들어온 패킷에 대해 기억해 둠
    모든 인바운드 트래픽 거부(들어오는 것, 허용 규칙 지정 가능)
    모든 아웃바운드 트래픽 허용(나가는 것 자유, 거부 규칙 지정 가능)
    
  • ex) HTTP 보안 그룹: 웹 기반 트래픽만 허용함

• 전체적인 보안 구조
• • 구조
    (게이트웨이) – VPC – (네트워크ACL) – 서브넷 – (보안 그룹) – 인스턴스

• 예시
• • VPC 내부에서의 패킷 전송 예시: 인스턴스 A에서, 인스턴스 B로 보내고 싶다
  • 인스턴스 A의 보안 그룹: 나가는 패킷은 기본적으로 통과 가능
    • 서브넷 1의 네트워크ACL: 유출 허용 목록을 확인한 뒤, 내보내 줌 (1과 2의 허용 목록은 다름)
    • 서브넷 2의 네트워크ACL: 유입 허용 목록을 확인한 뒤, 들여보냄 (즉, 1과 2 모두 허용되어 있어야 함)
    • 인스턴스 B의 보안 그룹: 유입 허용 목록을 확인한 뒤, 들여보냄(1과 2, B의 허용 목록은 각자 별개)
  • A의 패킷이 B에 성공적으로 전달됨, 이제 요청을 반환해 보자(반환 트래픽 패턴)
    • 인스턴스 B의 보안 그룹: 나가는 패킷은 기본적으로 통과 가능
    • 서브넷 2의 네트워크ACL: 유출 허용 목록을 확인한 뒤, 내보내 줌(stateless, 매번 검사)
    • 서브넷 1의 네트워크ACL: 유입 허용 목록을 확인한 뒤, 들여보내 줌(stateless, 매번 검사)
    • 인스턴스 A의 보안 그룹: Stateful(상태 저장)이므로, 곧바로 통과 가능

ACL vs 보안 그룹

• ACL: 전체 네트워크에 대한 허용 및 거부 규칙 지원
  • 모든 인스턴스에 자동 적용됨
• 보안 그룹: 인스턴스 하나에 대한 기준이 적용된다.
  • 기본적으로 모두 거부이고, 허용 규칙만 지정할 수 있다
  • 특정 그룹을 지정한 Instance에만 적용된다