(응용) AWS - Advanced IAM

AWS에 대해 알아봅니다.

정민호정민호

1. IAM

AWS 내에서 유저를 만들고 Role과 Policy 관리

3가지 IAM Policy 유형

  • Inline

  • Managed

  • Customer

1.1. Inline Policies VS Managed Policies VS Custom Policies

1.1.1. Inline

유저, 그룹에 직접 policy를 심어줌

  • 1:1 관계

  • 다른 유저나 그룹에 inline policy 적용x

  • 유저나 그룹 삭제시 inline policy 역시 삭제됨

1.1.2. Managed

AWS에서 생성되고 관리되어지는 Policies

  • 우리가 직접 Policy 만들 필요 없음

  • Managed Policy는 다수의 유저와 그룹에 적용 가능

  • Managed Policy는 수정 및 삭제 불가

    • 예) AmazonDynamoDBFullAccess

1.1.3. Customer

우리들이 직접 새로운 Policy를 만들 수 있음

  • 기존에 존재하는 Managed Policy 사용

  • 원하는 요구사항에 맞게 수정하고 사용

  • Managed Policy에서 원하는 Policy가 없을 때 사용

1.2. Web Identity Federation(WIF)

  • 아마존, 구글 등을 통하여 유저들에게 AWS 접근 권한제공

  • 인증코드(토큰) 사용

    • 예) 이중 인증(Two-Factor Authentication)

1.3. Cognito

Web Identity Federation(WIF) 기능을 제공

1.3.1. Cognito 주요 특징

  • 회원가입, 로그인 기능(Guest로 로그인 가능)

  • 어프리케이션과 Web Provider간의 중재자 역할

  • 다양한 기기로 부터 사용자 정보를 동기화함 → 확장성

  • 사용자 Credentials을 자동으로 관리

1.3.2. Cognito Use Cases

Facebook, Google과 같은 소셜미디어를 통한 WIF

  • 사용자 → Facebook → Token → Cognito (AWS credentials) → Token → 사용자 → AWS(EC2, S3, DanamoDB)

1.4. Cognito User Pool

  • 모바일, 웹 어플리케이션의 회원가입과 로그인 기능을 관리하는 곳

  • 유저는 User Pool을 거쳐 직접 로그인을 할 수 있음

  • Json Web Token(JWT)

    • 사용자 ←→ User Pool ←(JWT Token)→ Facebook

      • 사용자 ←(AWS credentials)→ Identity Pool

        • JWT Token과 AWS credentials을 일시적으로 교환

        • Identity Pool은 우리들이 유저들을 위해 고유한 Identity를 만들수 있고, 소셜미디어를 통해 인증 가능하게 해주는 기능을 제공(User Pool로 부터 받은 JWT Token과 교환해주는 중추적인 역할)

          • 유저는 생성된 Identity를 가지고 AWS credentials을 얻을 수 있는데 제약이 필요함(AWS에 대한 모든 권한을 제공할순 없으니까!).

          • 이러한 커스텀 설정을 제공하는게 Identity Pool.

    • AWS(EC2, S3, RDS) ←→ 사용자

      • AWS credentials 을 통해 AWS에 접근

(응용) AWS - Advanced CI/CD

AWS에 대해 알아봅니다.

정민호정민호

1. Code Deploy Life Cycle Event Hooks

  • appspec.yml 파일

    • CodeDeploy 하는데 있어 모든 설정관련 정보들이 내포되어 있는 중추적인 역할을 하는 파일

version: 0.2
os: linux
files:
  - source: config/config.txt
    destination: /webapps/Config
  - source: Source
    destination: /webapps/myApp
hooks:
 BeforeInstall:
   - location: Scripts/UnzipResourceBundles.sh
   - location: Scripts/UnzipDataBundles.sh
 AfterInstall:
   - location: Scripts/RunResourcesTests.sh
     timeout: 360
 ApplicationStart:
   - location: Scripts/RunFunctionalTests.sh
 ValidateService:
   - location: Scripts/ValidateService.sh
     timeout: 3600

  • 많이 사용되는 이벤트 hooks(Run Order(State의 순서가 정해져 있음)) 종류

    • ELB[ ApplicationStop → DownloadBundle → BeforeInstall → Install → AfterInstall → ApplicationStart → ValidateService ]ELB

(기초) AWS - DynamoDB

AWS에 대해 알아봅니다.

정민호정민호

1. DynamoDB

  • NoSQL(Not Only SQL) 데이터베이스

  • 매우 빠른 쿼리 속도

  • Auto-Scaling 기능 탑재

  • Key-Value 데이터 모델 지원

  • 테이블 생성시 스키마 생성 필요 없음

  • 모바일, 웹, IoT데이터 사용시 추천됨

  • SSD 스토리지 사용

  • 테이블(Table)

  • 아이템(Items) - 행(row)과 개념이 비슷함

  • 특징(Attributes) - 열(column)과 개념이 비슷함

  • Key-Value (Key : 데이터의 이름, Value : 데이터 자신)

    • 예) JSON, XML

1.1. DynamoDB - Primary Keys (PK)

  • PK를 사용하여 데이터 쿼리

  • DynamoDB에는 두가지의 PK 유형이 있음

1.1.1. 파티션키(Partition Key)

  • 고유 특징(Unique Attribute)

  • 실제 데이터가 들어가는 위치를 결정해줌

  • 파티션키 사용시 동일한 두개의 데이터가 같은 위치에 저장될 수 없음!

1.1.2. 복합키(Composite Key)

  • 파티션키(Partition Key) + 정렬키(Sort Key)

    • 예) 똑같은 고객이 다른 날짜에 다른 물건을 구매

    • 파티션키 : 고객아이디, 정렬키 : 날짜(Timestamp)

  • 같은 파티션키의 데이터들은 같은 장소에 보관, 드 다음 정렬키에 의해 데이터가 정렬됨

1.1.3. 데이터 예시

{
    "Cusomer_id" : "28942",
    "Transaction_id" : "g9s4dd2",
    "Item_purchased" : "sofa",
    "Store_location" : "seoul",
    "Transaction_date" : "2020-10-16 14:20:00"
}

1.2. DynamoDB 데이터 접근 관리

  • AWS IAM으로 관리할 수 있음

    • 테이블 생성과 접근 권한을 부여할 수 있음

    • 특정 테이블만, 특정 데이터만 접근 가능케 해주는 특별한 IAM 역할 존재

2. Index

  • 특정 컬럼만을 사용하여 쿼리

  • 테이블 전체가 아닌 기준점(pivot)을 사용해 쿼리가 이루어짐

  • 매우 큰 쿼리 성능 효과

  • 두가지의 Index 유형 존재

    • Local Secondary Index

    • Global Secondary Index

2.1. Local Secondary Index (LSI)

  • 테이블 생성시에만 정의해 줄 수 있음

  • 따라서 테이블 생성 후 변경, 삭제가 불가능

  • 똑같은 파티션키 사용, 그러나 다른 정렬키 사용

2.2. Global Secondary Index (GSI)

  • 테이블 생성후에도 추가, 변경, 삭제 가능

  • 다른 파티션키, 정렬키 사용

3. Query VS Scan

3.1. Query

  • Primary Key를 사용하여 데이터 검색

  • Query 사용시 모든 데이터(컬럼) 반환

  • ProjectionExpression 파라미터

가격 거래아이디 거래시간

2500

AAA

2020-10-30 17:30:00

3000

BBB

2020-10-31 14:00:00

1000

AAA

2020-11-02 11:00:00

2000

AAA

2020-11-04 15:25:00

3.2. Scan

  • 모든 데이터를 불러옴(primary key 사용X)

  • ProjectionExpression 파라미터

  • 대용량 테이블 조회시 병렬처리

3.3. Query VS Scan

  • Query가 Scan 보다 훨씬 효율적임

  • 따라서 Query 사용 추천

4. DAX

DynamoDB Acclerator

  • 클러스터 In-Memory 캐시

  • 10배 이상의 속도 향상

  • 읽기 요청만 해당사항(쓰기요청 X)

    • 예) Black Friday 날 쇼핑 웹사이트 운영(수만은 읽기 요청 예상)

4.1. DAX 원리

  • DAX 캐싱 시스템

    • 테이블에 데이터 삽입 & 업데이트 시 DAX에도 반영

  • 읽기 요청에 맞는 데이터가 DAX에 들어있을 시 DAX에서 데이터 즉시 반환(Cache Hit) ←→ (Cache Miss)

4.2. DAX 단점

  • 쓰기 요청이 많은 어플리케이션에서는 부적절함

  • 읽기 요청이 많지 않은 어플리케이션에서 부적절함

  • 아직 모든 지역에서 제공하지 않음

5. DynamoDB Stream

  • DynamoDB 테이블에서 일어나는 일들(삽입, 수정, 삭제 등)이 일어날 시 시간적 순서에 맞게 Streams에 기록

  • Log는 즉각 암호화가 일어나며 24시간동안 보관됨

  • 주로 이벤트를 기록하고 이벤트 발생을 외부로 알리는 용도

    • 예) Lambda Function

  • 이벤트 전&후에 대한 상황 보관 (24시간 동안 보관됨)

  • 어플리케이션 → AWS SDK(DynanoDB API / DynanoDB Streams API) → DynamoDB Endpoint / DynamoDB Stream Endpoint

  • DynamoDB Streams ← Lambda Function → SNS(Simple Notification Service) → SQS(Simple Queue Service) ←→ 어플리케이션