ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 인프런 AWS 입문자를 위한 강의-IAM, EC2, EBS, ELB, Route53, RDS, S3, CloudWatch (22.05.31)
    Cloud/AWS 2022. 5. 31. 18:46

    #AWS

    Amazon Web Service

    클라우드 컴퓨팅

    서버리스(원격에서 서버를 작동시키고 관리하며 메모리활동 지원 스스로 관리) 기능 지원. 

     

    #IAM

    Identity and Access Management

    유저를 관리하고 접근 레벨 및 권한에 대한 관리

    - 회원가입시 root 권한을 얻는다

    - 그 외 다른 사용자가 접근할 수 있도록 접근키, 비밀키를 생성할 수 있다.

    - 매우 세밀한 접근 권한 부여 기능. ex) 직원의 권한에 맞는 수준으로만 권한 제공

    - 비밀번호를 수시로 변경 가능케 해줌

    - multi-Factor Authentication(다중인증)기능

    -정책은 그룹, 역할에 추가시킬 수 있다. 하나의 그룹 안에 다수의 유저가 존재 가능하다. 1)그룹 2)유저 3)역할 4)정책

    - Universal함 (지역 설정 필요 없음)

     

    #IAM정책시뮬레이터

    1. 개발환경(Staging or Develop)에서 실제환경(Production)으로 빌드하기 전 IAM정책이 잘 작동되는지 테스트하기 위함

    2. IAM과 관련된 문제들을 디버깅하기에 최적화된 툴 (이미 실제로 유저에 부여된 다양한 정책들도 테스트 가능)

    ex) 정책시뮬레이터 대시보드> 정책시뮬레이터 dynamodb select action permission  run simulation  사용자 

    dynamodb read only access 사용자 권한 추가 permission 

     

    #IAM

    실습

    사용자 추가

    사용자이름

    프로그래밍 방식 액세스

    AWS Management Console 액세스

    액세스키ID, 비밀 엑세스키

     

    #EC2

    Elastic Compute Cloud. 유연하게 컴퓨팅클라우드 크기를 조절할 수 있다

     

    #EC2지불방법

    1. on-demand

     - 시간 단위로 가격이 고정되어 있음

     - 오랜시간동안 선불로 내지 않고 최소한의 비용을 지불하여 EC2인스턴스를 사용하고 싶을 때

     - 특히, 앱/프로그램 개발시 최초로 EC2인스턴스에 Deploy할 때 유용

    2. Reseved

     - 한정된 EC2 용량 사용 가능, 1-3년 동안 시간별로 할인 적용 받을 수 있음

     - 안정된, 예상 가능한 workload시 권장

     - 선불로 인한 컴퓨팅 비용 대폭 감소

    3. Spot

     - 입찰 가격 적용. 가장 큰 할인율을 적용받으며 특히 인스턴스의 시작과 끝기간이 전혀 중요하지 않을 때 유용

     - 단순히 비용 절감 시 유용함. 인스턴스의 시작/끝시점에 구애받지 않을 경우 권장

     

    #EBS

    - Elastic Block Storage

    - EC2를 사용하기 위해 EBS라는 디스크 볼륨을 요구한다.  일종의 하드디스크. 

    - 저장공간이 생성되어지며 EC2 인스턴스에 부착된다. 

    - 디스크 볼륨 위에 File System이 생성된다

    - EBS는 특정 Availability Zone에 생성된다.

     

    #Availability Zone(AZ)

    - 하나의 Regoin안에 여러개의 AZ가 존재할 수 있다.

    - 중심으로부터 복사본이 AZ로 뿌려지며, 한쪽 서버가 망가지면 AZ백업을 통해 서비스 제공을 가능케해준다. 일종의 Disaster Recovery.

     

    #EBS볼륨타입

    <<SSD군>>

    1) General Purpose SSD (GP2) : 최대 10K IOPS를 지원하며 1GB당 3IOPS속도가 나옴

    2) Provisioned IOPS SSD (IO1) : 극도의 I/O률을 요구하는 (ex 매우 큰 DB관리) 환경에서 주로 사용됨. 10K이상의 IOPS를 지원함.

    <<Magnetic/HDD군>>

    3) Throughput Optimized HDD (ST1)  : 빅데이터 Datawarehouse, Log프로세싱시 주로 사용 (boot volume으로 사용x)

    4) CDD HDD (SC1)  : 파일서버와 같이 드문 volume접슨시 주로 사용, 역시 boot volume으로 사용 불가능하나 비용은 매우 저렴함

    5) Magnetic (Standard) : 디스크 1GB당 가장 싼 비용을 자랑함. Boot volume으로 유일하게 가능함

     

    #ELB

    - Elastic load Balancers 

    - 수많은 서버의 흐름을 균형있게 흘려보내는데 중추적인 역할을 함

    - 하나의 서버로 traffic이 몰리는 병목현상(bottleneck) 방지

    - Traffic의 흐름을 Unhealthy instance -> healthy instance로 바꿔줌

     

    #어떤 ELB타입이 적절하게 사용되어져야하나?

    1. Application Load Balancer : OSI Layer7에서 작동됨.

     - HTTP, HTTPS와 같은 traffic의 load balancing에 가장 적합함

     - 고급 request 라우팅 설정을 통하여 특정 서버((루트변경 가능))로 request를 보낼 수 있음

    2. network : OSI layer4에서 작동됨. 매우 빠른 속도를 자랑하며 production환경에서 종종 쓰임

    - 극도의 performance가 요구되는 TCP traffic에서 적합함

    - 초당 수백만개의 request를 아주 미세한 delay로 처리 가능

    3. Classic Laod Balanacer : 현재 Legacy로 간주됨. 따라서 거의 쓰이지 않음. 시험에 가장 많이 등장

    - Layer7의 Http/Https 라우팅 기능 지원

    - Layer4의 TCP traffic 라우팅 기능 지원

     

    #LoadBalancerError

    - 504erorr : 어플리케이션이나 서버가 응답을 받지 못하는 경우 나타는 현상

    => 웹서버layer, 데이터베이스layer에서 문제해결 가능

     

    #x-forwarded-for헤더

    152.12.3.225(public IP address) -DNS-> ELB 10.0.0.23(private IP address) -> EC2 10.0.0.23

    - EC2는 private IP address 밖에 모른다.

    - public IP address를 알려면 x-forwarded-for 헤더를 이용해서 알아낼 수 있다.

     

    #Route53

    - AWS에서 제공하는 DNS서비스

    - 일상에서 종종 사용하는 서버에 이름 부여. 즉, 도메인 주소 구매하여 3가지(EC2 instance, S3 Bucket, Load Balancer) 백엔드로 연결시켜주는 것

    - 호스팅 영역 생성

     

    #EC2실습

    -putty : ssh를 사용하여 원격 서버에 접속할 수 있도록 해줌

    -실습 순서

    1) putty다운로드. putty.exe  puttygen.exe(pem파일을ppk파일로 변환해줌) 두개파일 설치

    2) EC2인스턴스시작. > AMI선택 > 인스턴스유형선택(t2micro) >인스턴스 구성>스토리지추가>태그추가>보안그룹구성(ssh, https)> 검토, 새 키페어 생성하면 pem파일이 다운됨. > 인스턴스 시작을 누르면 pending에서 start상태가 됨.

    3) puttygen에서 pem파일>ppk로 변환

    4) hostname(ec2-user@awsIpv4퍼블릭IP), port22 + ssh>auth에서 ppk등록> session 저장

    sudu su #슈퍼유저
    yum update -y #운영체제 업데이트. 관련 패키지 모두 설치해줌.
    yum install httpd -y # 아파치 설치. 아파치를 사용하여 인스턴스를 실제 웹서비스처럼 사용할 수 있게 해줌
    service httpd start
    chkconfig httpd on
    cd /var/www/html
    ls
    vi index.html
    <html>
    <body><h1>웹페이지</h1></body>
    </html>

     

    #RDS

    - Relational DB Service  관계형 데이터베이스 (데이터베이스, 테이블, 데이터, 필드)

     

    #DataWarehousing

    - Business Intellignece

    - 리포트 작성, 데이터분석시 사용 (Production Database -> Data warehousing)

    - 매우 방대한 분량의 데이터 로드시 사용

     

    #OLTP vs OLAP ★

    - OLTP : Transaction. INSERT와 같이 종종 사용되어지는, 혹은 규모가 작은 데이터를 불러올때 사용되는 SQL 쿼리가 필요할때 유용

    ex) Order # 210에만 해당되는 Customer 이름, 주소, 시간 정보 insert

    - OLAP : Analytical. 매우 큰 데이터를 불러올때 사용. 주로 덩치가 큰 select 쿼리가 사용됨

    ex) 특정 회사 부서의 Net profit, Products

     

    #RDS-Backup

    1. Automated Backups(AB) 자동백업

    - Retention Period(1-35일) 안의 어떤 시간으로 돌아가게 할 수 있음

    - AB는 그날 생성된 스냅샷과 Transaction logs(TL)을 참고함

    - 디폴트로 AB기능이 설정되어 있으며 백업정보는 S3에 저장

    - AB동안 약간의 I/O suspension(정지)이 존재할 수 있음 -> Latency 지연시간

     

    #DB Snapshots (데이터베이스 스냅샷)

    - 주로 사용자에 의해 실행됨

    - 원본 RDS Instance를 삭제해도 스냅샷은 존재함 (vs AB, AB는 인스턴스 삭제시 스냅샷 모두 삭제됨)

     

    #RDS데이터베이스 백업시 원본 일어나는 현상? 

    새로운 RDS Instance, RDS Endpoint 가 생성됨.

    즉, 원본과 백업본은 완전히 다른 객체가 됨. 

     

    #RDS-Multi AZ, Read Rplicas

    Multi AZ

    - 원래 존재하는 RDS DB에 무언가 변화(e.x: write)가 생길 때 다른 Availability Zone에 똑같은 복제본이 만들어짐 = Synchronize

    - AWS에 의해서 자동으로 관리가 이루어짐 (No admin intervention)

    - 원본 RDS DB에 문제가 생길 시 자동으로 다른 AZ의 복제본이 사용됨

    - Disater Recovery Only! 성능개선을 위해 사용되진 않음. (성능개선은 Read Replica) ★

    - 3ec2 -> 1개 RDS ap-northeast-2A <-> ap-northeast-2B: ap-northeast-2A에서 재해발생시, 자동으로 ap-northeast-2B으로  fail over함.

     

    Read Replica

    - production DB의 읽기 전용 복제본이 생성됨

    - 주로 Read-Heavy DB 작업시 효율성의 극대화를 위해 사용됨(Scaling)

    - Disaster Recovery용도가 아님★

    - 최대 5개 Read Replica DB 허용

    - Read Replica의 Read Replica 생성 가능 (단, Latency 발생) 

    - 각각의 Read Replica는 자기만의 고유 Endpoint존재

    - 3ec2 -> RDS연결. ec2인스턴스로부터 쓰기 작업 실행될 시, Read Replica에 의해 똑같은 RDS 복제본이 생성됨.

     ex) read traffic? main으로 모두 보는 것이 아니라 하나의 인스턴스를 각각의 Read Replica로 연결시킴. 즉, mainDB의 워크로드를 현저히 낮출 수 있으며 성능 높일 수 있다. 

     

    #ElastiCache

    - 클라우드 내에서 In-memory캐시를 만들어줌

    - 데이터베이스에서 데이터를 읽어오는 것이 아니라 캐시에서 빠른 속도로 데이터를 읽어옴

    - Read-Heavy 애플리케이션(SNS, 실시간 top 10)에서 상당한 Latency감소 효과 누림

    ★Read-Heavy데이터 사용시 어떤 서비스를 사용해야 최고의 효율을 낼 수 있을까요? ElastiCache

     

    # ElastiCache 종류

    1) Memcached 

     - Object캐시 시스템으로 잘 알려져 있음

     - ElastiCache는 Memcached의 프로토콜을 디폴트로 따름

     - EC2 Auto Scaling 처럼 크리가 커졌다 작아졌다 가능함

     - 오픈소스

     - 사용목적

       i) 가장 단순한 캐싱 모델이 필요한가요?

       ii) Object caching이 주된 목적인가요?

       iii) 캐시 크기를 마음대로 scaling하기를 원하나요?

    2) Redis

    - Key-value, Set, List와 같은 형태의 데이터를 In-Memory에 저장 가능함

    - 오픈소스

    - multi-AZ(재해복구) 지원

     - 사용목적

       i) List, Set과 같은 데이터셋을 사용하나요?

       ii) 리더보드처럼 데이터셋의 랭킹을 정렬하는 용도가 필요한가요?

       iii) Multi AZ기능이 사용되어져야 하나요?

     

    #RDS실습

    - 데이터베이스 생성>엔진옵션(mysql etc)>템플릿(프리티어)>설정>DB인스턴스크기>스토리지>가용성 및 내구성>연결-추가연결구성 퍼블릭엑세스기능 아니요/vpc보안그룹 새로 생성 가용영역 기본설정없음>데이터베이스 인증> 추가구성>월별추정요금

     

    >고급세부정보

    #!/bin/bash
    yum install httpd php php-mysql -y
    yum update -y
    chkconfig httpd on # 아파치서버 켬
    service httpd start # 아파치 실행
    echo "<?php phpinfo();?>" > /var/www/html/index.php #phpvkdlf todtjd gn wjwkd
    cd /var/www/html # todtjdgkf vhfejfh dlehd 
    wget https://aws-learner-storage.s3.ap-northeast-2.amazonaws.com/connect.php #파일 다운

    > connect.php 파일

    <?php 
    //username password hostname dbname 등록
    $username = "awslearner"; 
    $password = "awslearner"; 
    $hostname = "yourhostnameaddress";  //RDS endpoint
    $dbname = "awslearner";
    
    //connection to the database
    $dbhandle = mysql_connect($hostname, $username, $password) or die("MySQL에 연결할 수 없습니다"); 
    echo "MySQL 접속 성공! username - $username, password - $password, host - $hostname<br>"; 
    $selected = mysql_select_db("$dbname",$dbhandle) or die("MySQL DB 연결 실패... - 다시 시도해보세요!"); 
    ?>

     

    #S3

    - simple storage servicve

    - 안전하고 가변적인 Object 저장공간을 사용 (ex: Google Cloud)

    - 편리한 UI인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있음

    - 파일 크기는 0kb~5tb까지 지원

    - 저장공간 무제한

    -  Bucket이라는 이름을 사용함 (디렉토리와 유사함)

    - Bucket은 보편적인 namespace를 사용함

     

    #S3 Object구성요소

    - key: 파일명

    - value : 파일내용

    - version ID : 버전

    - metadata : 어떤 팀의 owner인지 등 데이터의 상세정보

    - CORS (Cross Origin Resource Sharing) : 한버킷의 파일을 다른 버킷에서 접근가능하도록 해줌(지역상관 x)

     

    #S3 Data Consistency Model

    1. Read after Write Consistency (PUT)

    2. Eventual Consistency (UPDATE, DELETE)

     

    # S3스토리지

    1. 일반 S3

     - 가장 보편적으로 사용되는 스토리지 타입

     - 높은 내구성(Durability, 얼마나 손실없이 잘 복원되는지), 가용성(Avaliability, 얼마나 데이터 접근 용이한지)

    2. S3-IA (Infrequent Access)

     - 자주 접근되지는 않으나 접근시 빠른 접근이 요구되는 파일이 많을 시 유용

     - 일반 S3에 비해 비용이 저렴하나 접근시 추가 비용 발생

     - 멀티 AZ를 통한 데이터 저장 => 가용성 상당히 높음

    3. S3-One Zone IA

     - 단일 AZ를 통한 데이터 저장

     - 단일  AZ에 의한 데이터 접근 제한 (조금 낮은 가용성)

     - 데이터 접근시 S3-IA보다 20% 비용 저렴

    4. Glacier

     - 거의 접근하지 않을 데이터 저장 시 유용

     - 매우 저렴한 비용

     - 데이터 접근시 대략 4-5시간 소요

    5. Intelligent Tiering

      - 데이터 접근 주기가 불규칙할 때 매우 유용

      - 2가지 티어 존재

         - Frequent Tier

         - Infrequent Tier

     - 데이터 접근주기에 따라 두가지 티어중 하나로 선택됨

     - Frequent Tier가 비용이 약간 더 비쌈

     - 최고의 비용 절감 효율을 누릴 수 있음

     

    #S3요금

    - GB당 (0.023 per GB 정도) 

    - PUT, GET, COPY 요청 횟수당

    - 데이터 다운로드시 / 다른 리소스로 전송시

    - METADATA (object tag)

     

    #S3사용 사례

    사례1. 파일 저장소(로그, 다양한 파일들(이미지, 비디오, 압축파일 등))

    사례2. 웹사이트 호스팅 : html, css, javascript등 웹사이트 구성에 필요한 파일 S3에 올려두고 Route53으로 DNS를 생성하여 사용가능

    사례3. CORS : Cross Origin Resource sharing. 한 버킷이 다른 버킷의 파일로 접근 가능하게 해줌.

     

    #최초S3버킷 생성시 -> 비공개(private)

    이를 public or 공유가능하도록 변경하려면?

    방법1. 버킷 정책 변경 (Bucket policy)

    방법2. 접근 제어 리스트 변경 (Access Control List) : 각 파일마다 접근제어 설정 가능

     

    #S3암호화

    상황1. 파일 업로드/다운로드시 

    - SSL(Secure Socket Layer) / TLS (Transport Layer Security) 

    상황2. 가만히 있을시

    i) SSE-S3 : 자동으로 주기적으로 암호 변경 (AES-256 사용됨)

    ii) SSE-KMS : 언제, 누가 암호를 변경했는지 기록해주기 때문에 보안관리에 좋음

    iii) SSE-C : 직접 암호 변경 가능.

    *SSE : Server Side Encrypt

     

    #S3암호화 과정

    - PUT 요청이 생성됨

    - host: bucket이름

    - x-amz-server-side-encryption-parameter: AES-256 => 우리가 파일을 s3에 업로드할 때 헤더에 이것이 있다면 암호화(AES-256)하라는 의미.

    암호화가 걸리지 않은 파일을 버켓에 올리지 못하게 하는 방법 있다. 버켓정챙설정. 저 값이 헤더에 없으면 reject.

     

     

    #S3실습

    버킷만들기:일반구성>퍼블릭액세스차단설정>고급설정

    버킷에서 폴더만들어 직접 upload도 가능.

    고급설정:다른 AWS계정에 대한 엑세스: ACL(액세스 제어리스트)

    버킷레벨에 해당하는 접근 권한이 없기 때문

    권한 버킷정책 정책생성기 

     

    #CloudWatch

    -얼마나 많은 공간? 어떤 이벤트들? 서비스의 상태는? 얼마나 에러 발생?

    - AWS 리소스 사용의 실시간 모니터링 기능 지원

    - 다양한 이벤트(s3버킷 파일 업로드&삭제, S3 버킷 접근시 접근거부 발생, RDS 데이터베이스에 접속 시도)들을 수집하여 로그파일로 저장

    - 이벤트&알람 설정을 통해  SNS, AWS Lambda로 전송 가능

    - CloudWatch 사용 가능 서비스들 : EC2, RDS, S3, ELB 등!

     

    #CloudWatch모니터링 종류

    종류1. Basic Monitoring : 무료, 5분간격으로 최소의 Metrics  제공

    종류2. Detailed Monitoring : 유료, 1분 간격으로 자세한 Metrics 제공

    (자세한? cpu사용량, 디스크사용량, 네트워크 I/O 등)

     

    #CloudWatch 사용 사례

    CASE1.

    - Use Case: 매일 얼마나 많은 사람들이 모바일 앱을 사용하는지 알고 싶음

    - Potential Issue: 특정날에 수많은 traffic이 몰릴 수 있어 병목현상이 생길 수 있음

    - Solution : 매일 traffic rate과 특정 버튼의 유저 클릭 횟수를 분석하여 더 효율적인 앱개발을 할 수 있는 통찰력을 얻을 수 있음

    CASE2.

    - Use Case: 특정 시간대에 웹서버 상태를 점검하여 비용 절감 목표

    - Potential Issue: 똑같은 비용을 내며 AWS리소스들을 사용하지만 낮시간대와 밤시간대에 필요한 서버의 성능은 달라질 수 있기 때문에 금전적 손실이 생길 수 있음 (주로 밤시간대가 낮시간대보다 서버가 오랫동안 idle)

    - Solution : 알람 설정을 통하여 특정 threshold에 도달했을 때 개발자에게 상황을 보고해줌으로서 서버관리 가능

     

    #CloudWatch-Alarm

    - 임의로 정해놓은 값에 도달할 시 Alarm이 울림

    - Alarm이울릴 시 특정 이벤트들을 작동시킬 수 있음

     

    #Alarm State

    - Alarm

    - Insufficient불충분

    - OK

     

    #Billing Alarm

    - 우리가 정해놓은 지출 임계값을 초과할 경우 SNS를 통하여 경고를 함

     

    반응형
Designed by Tistory.