Post

그림으로 이해하는 AWS구조와 기술

Posted Updated
Preview Image
By minnnning
14 min read
그림으로 이해하는 AWS구조와 기술

AWS를 공부하기 위해서 도서관에서 기본이 되는 책을 읽어 봤다 책의 이름은 그림으로 이해하는 AWS 구조와 기술로 내용으로는 클라우드의 기본 개념과 AWS를 이해하기 위한 네트워크 구조 마지막으로 AWS의 대표적인 서비스에 대해서 작성한 책었다

1~3장까지는 AWS의 기초 지식으로 왜 클라우드를 왜 사용하는지 사용 방법, 도입 사례가 있었다 그래서 작성은 패스

 

4장 EC2

EC2란 elastic compute cloud로 서버에 필요한 세트를 클라우드에서 빌릴 수 있다

EC2는 매니지드 서비스(사용자가 설치하고 운영해야 한다)가 아니다 매니지드 서비스란 단어를 들어는 봤지만 크게 생각을 안해 봤었는데 여기서 정확한 뜻을 알았다

EC2로 생성한 서버 인스턴스는 여러 유형이 존재한다

t2(인스턴스 유형).micro(인스턴스 크기)

용도인스턴스 유형내용
범용T2,T3,M5,M4등일반적인 서버로 부하가 일정한 서버인 경우 사용 버스트 가능
컴퓨팅 최적화C5,C4등CPU특화 연산 능력이 높음
메모리 최적화X1e,X1등메모리 액세스 속도를 높인 서버
메모리 최적화R4대용량 메모리 탑재한 서버
가속한된 컴퓨팅 최적화P3,P2,G3,F1머신 러닝등에 사용 GPU를 탑재
스토리지 최적화H1,I3,D2등스토리지 최적화한 유형 I3는 SSD

 

EBS(Elastic Block Store)

EC2 인스턴스를 실행할 때 연결되는 스토리지이다 SSD, HDD 설정가능하다 EBS는 하나의 EC2에만 연결이 가능하다 이외에도 탄력적 볼륨(크키 간단히 조절), 스냅샷(특정 시점의 데이터 통째로 저장), 암호화등이 존재한다

 

ELB(Elastic Load Balancing)

부하를 분산시키는 부하 분산 장치 3가지 종류가 있다

  • ALB(Application Load Balancer): HTTP/HTTPS에 가장 적합한 로드 밸런서로 어플리케이션 계층에서 동작한다 URL 간위로 분배하는것이 가능
  • NLB(Network Load Balancing): 전송계층(4계층)에서 작동하기 때문에 패킷이라는 단편 데이터만 볼 수 있다 TCP/UCP, TLS지원
  • CLB(Classic Load Balancing): 오래된 유형의 로드 밸런서 지원 프로토콜이 많지만 사용 거의 x

 

스냅샷

어던 시점의 서버 디스크 산태를 통째로 보존한 파일이나 폴더들의 집합이다 os설정 정보까지 모두 포함한다

개인이 AWS에서 AMI를 만들기 위해서 스냅샷을 사용하기도 한다 처음에만 통째로 저장하지만 두번째부터는 변경사항만 보존한다

 

오토 스케일링

오토 스케일링 그룹(인스턴스 집합)을 생성하고 인스턴스의 최소 대수와 최대 대수를 설정한다 그러면 그 범위 안에서 인스턴스가 증감한다

AMI와 키페어, 보안 그룹등을 설정해야한다

  1. EC2 인스턴스가 정지한 경우에 분리하고 새로운 EC2인스턴스를 생성하는 방법
  2. 일정에 맞춰 스케일링하는 방법
  3. CPU와 네트워크 부하를 참고하여 특정 임계값을 넘어갈 때 인스턴수 증감

 

EC2요금

인스턴스 사용량 + EBS 요금 + 통신 요금 + 그외 옵션(Elastic IP, ELB등)의 비용이 같이 계산한다

 

5장 스토리지 서비스 S3

S3란 객체 스토리지 서비스이고 데이터를 객체 단위로 관리한다 대표적 지는으로 웹서버 기능, 쿼리 기능이 있다

 

스토리지 클래스

  • standard: 3곳의 가용 영역에 데이터 저장, 검색 요금이 없다
    • Reduced Redundancy Storage(RRS)는 옵션으로 standard에서 이중화 수준을 낮춰 하나의 가용 영역만 이용
  • Intelligent-Tiering: 2개의 게층이 존재 액세스가 빈번한지에 따라 자동으로 분류한다 2개의 액세스 계층 이동하는데 비용 x, 기본적으로 standard와 비슷하지만 최소 저장 기산에 대한 요금 설정됨
  • Standard-Infrequent Access: 저장 요금이 싸지만 액세스 요금이 부과, 액세스 적고 요량이 큰 데이터 적합
  • S3 Glacier/S3 Glacier Deep Archive: 장기간 백업 데이터 낮은 용량으로 저장 액세스시 다른 S3 버킷에 이동해서 액세스 하므로 검색 요금이 2배

 

객체와 버킷

버킷안에 버킷이 불가능하다 폴더 개념이 없다 웹에서 폴더 구조를 보여주지만 사실은 병렬로 저장된다

버킷 이름은 소문자 + . + 숫자조합으로 사용하고 ip주소형식이나 중복된 이름은 불가능하다

 

데이터 분석

S3의 객체나 객체 내용에 대해서 분석할 수 있다

  • S3 Select: S3로 저장된 하나의 파일에 SQL문을 사용하여 집계 및 검색
  • Athena: 어떤 대상에 대해 어떤 검색을 할지 사전에 구성해야한다(여러 파일 분석 가능) 서버 없이 실행할 때만 비용
  • Redshift Spectrum: Athena와 비슷하지만 분석용 서버를 따로 만들어서 분석한다 복잡한 데이터를 처리할 때 사용

 

CloudFront

graph TD
    subgraph "S3 단독 사용"
        U1[👤 사용자] -- "콘텐츠 요청" --> S3_Only[S3 버킷]
        S3_Only -- "콘텐츠 반환<br/>(💸 <b>비싼 인터넷 전송료 발생</b>)" --> U1_Return[👤 사용자]
        S3_Only -- "스토리지 및 요청 요금" --> Cost_S3_Only((S3 총비용))
        U1_Return -- "최종 비용 포함" --> Cost_S3_Only
    end

    subgraph "S3 + CloudFront 사용"
        U2[👤 사용자] -- "콘텐츠 요청" --> CF_With_S3[🌍 CloudFront 엣지]
        
        CF_With_S3 -- "캐시 히트: 즉시 반환" --> U2_Return_Fast[👤 사용자]
        CF_With_S3 -- "캐시 미스: S3에 요청" --> S3_With_CF[S3 버킷]
        S3_With_CF -- "S3 -> CloudFront<br/>(🟢 <b>데이터 전송 무료</b>)" --> CF_With_S3
        CF_With_S3 -- "콘텐츠 반환<br/>(💰 <b>저렴한 CloudFront 전송료 발생</b>)" --> U2_Return_Normal[👤 사용자]

        CF_With_S3 -- "CloudFront 요청 요금" --> Cost_CF_With_S3((CF + S3 총비용))
        S3_With_CF -- "S3 스토리지 및 요청 요금" --> Cost_CF_With_S3
        U2_Return_Fast -- "최종 비용 포함" --> Cost_CF_With_S3
        U2_Return_Normal -- "최종 비용 포함" --> Cost_CF_With_S3
    end

    %% 스타일링
    style S3_Only fill:#f05b69,stroke:#e03c4c,stroke-width:2px,color:#fff
    style CF_With_S3 fill:#3bed77,stroke:#2cb658,stroke-width:2px,color:#fff
    style S3_With_CF fill:#f05b69,stroke:#e03c4c,stroke-width:2px,color:#fff

 

요금

요금은 스토리지 종류와 지전에 따라 다르지만 저장 요량 + 전송량으로 계산한다 저장된 용량과 S3에서 파일을 받거나 보낼 때 발생하느 요금 수신 요청 (get) 송신요청 (put)에 대해서 1GB단위로 과금된다

 

VPC

위 그림이 vpc를 잘 표현하고 있어서 책(그림으로 이해하는 AWS구조와 기술) 201페이지에서 가져왔다 위 그림에서 라우터가 보이지만 vpc는 클라우드여서 라우터가 소프트웨어로 작동한다

vpc에서 인터넷 게이트웨이가 없다면 인터넷을 이용할 수 없다 보안 때문이라면 NAT게이트웨이(나가는것만 허용)를 사용하면 된다

### 네트워크 ACL

서브넷 단계에서 허용과 거부를 설정한다 위에서부터 순차로 처리한다

보안그룹

인스턴스 단위에서 적용되는것으로 허용만 설정한다 (기본이 거부임)

 

VPC 엔드포인트

vpc 내부의 리소스가 인터넷을 거치지 않고 AWS(S3, Dynamo DB)와 비공개로 안전하게 통신할 수 있게 해주는 기능

vpc 내부의 것만 이용하면 위 기능을 이용할 필요가 없지만 외부 또는 S3, Dynamo DB와 연결할때 안전하게 통신하기위해 사용하는게 vpc 엔드포인트이다

  • 게이트웨이 엔드포인트: 라우팅 테이블에 경로를 추가한다 특정 AWS서비스 S3, Dynamo DB로 향하는 트래픽을 인터넷, NAT게이트웨이가 아닌 이 엔드포인트로 보냄
graph TD
    subgraph "엔드포인트 사용 전"
        VPC1[VPC] --> NAT[NAT Gateway]
        NAT --> IGW[Internet Gateway]
        IGW --> S3_1[AWS Service]
    end

    subgraph "엔드포인트 사용 후"
        VPC2[VPC] --> Endpoint[VPC Endpoint]
        Endpoint --> S3_2[AWS Service]
    end
  • 인터페이스 엔드포인트: 서브넷 내부에 프라이빗 IP주소를 가진 네트워크 인터페이스(ENI)를 생성하는 방식 마치 vpc내부에 있는것처럼 동작한다 privateLink를 이용한다
graph TD
    subgraph "서비스 소비자 VPC"
        direction LR
        Consumer_EC2[EC2 인스턴스] --> ENI[ENI 인터페이스 엔드포인트]
    end

    subgraph "서비스 제공자 VPC"
        direction LR
        NLB[Network Load Balancer] --> Provider_EC2s[EC2 인스턴스들]
        EndpointService[VPC 엔드포인트 서비스] --> NLB
    end

    ENI -- "<b>AWS PrivateLink</b><br/>(AWS 내부망을 통한<br/>안전한 비공개 연결)" --> EndpointService

 

Amazon RDS

RDS는 인스턴스 사양을 선택하고 어떤 DBMS를 선택해서 사용한다 그리고 완전 매니지먼드 시스템으로 AWS가 알아서 관리해준다

6개 종류를 선택할 수 있다

  • MySQL
  • PostgreSQL
  • MariaDB
  • Oracle Database: 상용 데이터베이스
  • Microsoft SQL Server: 상용 데이터베이스
  • Amazon Aurora: MySQL 및 PostgreSQL과 완벽하게 호환되면서도, 상용 데이터베이스 수준의 성능과 가용성을 훨씬 저렴한 비용으로 제공한다

 

Amazon DynamoDB

완전 관리형 NoSQL 데이터베이스 서비스로 엄격한 스키마가 없는 Key-Value 및 문서(Document) 데이터 모델을 지원한다

 

Amazon ElastiCache

AWS에서 제공하는 완전 관리형 인 메모리 캐싱 서비스로 키-밸류 스토어의 빠른 속도를 활용하여 성능을 향상한다 Redis (Remote Dictionary Server)와 Memcached (멤캐시디)가 있다

책
This post is licensed under CC BY 4.0 by the author.