Rala
repo

AWS 기타

Github logo Edit on GitHub

개요

AWS에 대한 메모 모음.

EC2 몀명법

[type][generation].[capacity] ex. t2.micro : t타임 2세대의 마이크로(1core/1GB) 서버

타입

범용/cpu/gpu/memory/storage 범용 : T, M, A 컴퓨팅 : C 메모리 : R, X, z 가속화 : P, DL, Inf, G, F, VT.. GPU 가속. 부동소수점, 머신러닝 등 스토리지 최적화 : I, D, H

세대

t1, t2, t3, t4 : 숫자가 제너레이션

AWS 사용

CLI, Management Console, API

자격 증명

AccessKey, Password

cloud9

web base ide

x-ray

디버깅용 ??

cloudwatch

알람 등록(ex. cpu 50%이상..) 지표 수집 트리거링(ex. cpu 50%이상이면 날림)

cloudtrail

api call 전체 로깅. json으로 s3에 떨굼.

서비스 클라이언트 API와 리소스 API

서비스 클라이언트 API : API 접근을 key-value로 하나하나 접근. 리소스 API : 약간 추상화해둠. 개별 리소스(ex. s3)를 object로 추상화하여 접근 API. 추상화 수준이 높음. 개념적으로 리소스 접근

IAM

API 접근을 위한 아이디/비밀번호

  • Access Key ID : 아이디
  • Secret Access Key : 비밀번호

IAM 사용자와 Root 사용자

Root 사용자

  • 로그인 : email/ pw
  • 권한 : 전체권한
  • 권한이 크므로 직접 접속 추천하지 않음
  • IAM 유저를 걸고 쓰기
  • MFA를 꼭 걸기

IAM

  • 로그인 : Acess Key Id /사용자명/Secret Access Key
  • 권한 : 사용자가 권한

IAM USER

  • 영구 자격 증명. 유출되면 다 죽는다.

IAM GROUP

  • IAM 유저에 대한 그루핑

IAM ROLE

  • 역할
  • 사람이 아닌 sevrice/reousrce에 권한 부여.
  • 임시자격증명 사용
  • 교차계정 access
  • deny가 우선함

IAM Policy

  • 정책. 리소스 allow, deny 설정
  • 사용자/그룹/역할에 부여 가능
  • AWS Policy Generator를 통해 생성 가능
  • JSON으로 구성 가능

특수 : IAM User와 IAM Group의 Policy가 다를때? A유저에게 B권한이 있고, C그룹에게 D권한이 있다. A유저를 C그룹에 넣으면 권한은 D권한만 가진다. B+D권한이 되는 것이 아니라, 기존 유저 권한은 날아감.

IAM Policy format

{
    "version" : "2012-01-17",
    "statement":[{
        "Effect":"Allow",
        "Action":["dynamodb:*", "s3:*"],
        "Resource":
    }


    ]
"condition":{   //해당 소스만 OK
    {IPAddress:""


    }


}

관리형과 인라인

  • 관리형 : AWS관리형, 고객 관리형
  • 인라인 : 관리가 어렵다. 자제하자

리소스 정책 vs 자격증명 정책

  • 리소스 : 누가 접근할 수 있는가?
  • 자격증명 : 어디에 접근할 수 있는가? => 보통 이 이야기입니다.

최소권한의 원칙

권한을 다 합쳐서 최소 권한으로 부여

리소스 정책과 IAM 정책

리소스 정책이 걸려있으면 IAM 정책과 리소스 정책을 모두 보고 권한 부여. s3에 IAM 정책으로 allow가 걸려 있어도 s3의 버켓이 deny면 접근할 수 없음

자원에 s3를 붙여서

S3

simple storage service

object = file + metadata

보호장치

아래로 갈 수록 강력한 권한 제어

  • public access 막기
  • ACL
  • bucket policy -> 섬세하게 권한 제어

성능:요청

객체 메타데이터 생성

성능 : 지연시간

사용자에게 가까운 버킷 리전 선택

오류 코드 확인

400 오류 코드 확인

aws policy generator

https://awspolicygen.s3.amazonaws.com/policygen.html

다이나모디비

파티션키

균등성이 좋은 값을 필수

정렬키

정렬키를 기준으로 사용 옵션

기본키

1) 파티션 기본키 : 파티션키만 사용 2) 파티션 및 정렬 기본 키 : 파티션키와 정렬키 같이 사용

읽기 일관성

  • 최종 일관성 - 0.5ㄱㅊ -강력한 일관성 - 1rcu / 4kb / 1ㄴ

쓰기일관성

처리량단위

  • 읽기 : rcu, 4kb, strong
  • 쓰기 : wcu, 1kb, strong

initial provision configuration

before : RCU : 5 WCU : 5 auto : off

after : RCU : 1->10 WCU : 1->10 auto : on

보조인덱스. 세컨더리 인덱스

프라이머리키가 아닌 키로 쿼리

  • 글로벌 세컨더리 인덱스 : 파티션키가 다르다
  • 로컬 세컨더리 인덱스 : 파티션키는 같지만 소트키만 가지고 날림

글로벌테이블

  • 개별 테이블 생성
  • 묶자

백업

  • 자동백업 : 시점복구. ex) 35일을 지정하면 35일까지 시점에 대해서 롤백가능.
  • 수동백업 : 사용자가 복구. 엄청 빠르다. 수초 내에 진행

객체지속성모델(Object Persistence Model)

orm도 슉슉

테이블 생성

선택적 속성

DAX

다이나모 캐쉬

문제해결

클라우드트레일 : 에이피아이확인 클라우드와치 : 성능 알람 걸기 배치작업의 오류처리

  • 실패한 배치(unprocessedkeys)만 재시도 반환된오류코드 확인
  • 처리량, 프로비저닝 어쩌고 -> rcu, wcu 늘리자
  • 500 -> 제시도

파티션키의 분배

파티션키에 따라 RCU, WCU 분배하므로 적절히 분배할 수 있는 키를 선택 => 성으로 키를 나눌 경우 '김'씨가 많지만 전체 균등하게 r/wcu를 분배하므로 => 성은 적절한 파티션키가 아니다

글로벌 테이블 - 컨시스턴시

1초의 동기화 시간이 걸린다.

consistency option

  • read : 1rcu - 1s, 4kb, strong
    • strong consistency : 항상 동일한지 비교하여 리턴, 1rcu
    • eventually consistency : 하나를 바로 땡김, 0.5rcu
    • transaction consistency : 2rcu
  • write : 1wcu - 1s, 1kb, standard
    • standard consistency : 1wcu
    • transaction consistency : 2wcu

sql-like query

Lambda

서버리스 함수

생성

  • 리젼
  • 이름
  • 펑션 설정

lambda tempalte

//event : 필요 데이터
//context : 런타임 정보
handler_function(event, context){
    print("hello + o", event.name)
}

어떻게 구현?

  • 매니지먼트 콘솔에서 개발
  • 개발 후 zip 배포
    • 라이브러리를 말아서 같이 올려야 함
    • new! efs에 라이브러리 설치 후 람다에서 공유 가능
  • IDE 연동 : plug-in or cloud 9

실행방식

  • push : 외부에서 호출함
  • pull : 내부에서 먼저 호출함

호출 권한

실행 권한

  • 함수 실행 : 실행에 필요한 권한. s3의 이미지를 축소하는 함수라면 s3 read/write 권한 필요
  • 로킹 : cloudwatch log 권한

한계

  • 메모리 : 10GB
  • 실행시간 : 15분(900초)

구조

  • 핸들러함수
  • 이벤트 객체
  • 컨텍스트 객체

모범사례

  • 재귀코드 사용금지
  • 핸들러 진입점 분리
  • 실행 컨텍스트 재활용
  • 공통로직은 - 레이어나 이에프에스로 관리

limit

프리티어

-1,000,000호출까지 -400,000기가바이트초 까지

람다한계

memory : 10GB 실행시간 : 15분

API Gateway

  • 프론트엔드로 동작하며 예를 들어 람다의 리버스 프록시로 사용
  • 백엔드 하이드 가능 -> 디도스 완화
  • 메세지 검증/변환
  • cache : 0.5~237GB
  • api 호출 권한 제어
    • IAM
    • KEY
  • API 사용량
    • 모니터링
    • 제한 : 쓰로틀링 일일사용량

api endpoint

  • regional(default)
  • edge optimized
  • private

사용량 제한

모니터링 제한 - 스로틀링, 일일사용량 최대요청수 : 5000, AWS와 협의하에 가능

엔드포인트

  • 리져널
  • 엣지네트워크
  • private(internal vpc)

Step functions

start->end로 구성되는 스테이트머신

state

  • task : 작업
  • wait : 대기
  • pass : 전달
  • choice : 분기
  • parellel : 병렬
  • succeed / fail :
  • map

실행방법

  • start execution api call
  • api gateway에서 api가로채서
  • cloudwatch event 규칙 : 5분에 한번
  • lambda -> start execution api 호출 코드 구현

CloudFormation

IaC

SQS 및 SNS

SQS

  • standard :큐지만 fifo 아니다. 중복처리가 될 수 있음.
  • 무제한처리
  • fifo : 한번만 실행
  • 초당 300건, 3000건

SNS

pub/sub 모델

filter policy

ex. 이벤트 이름이 어떤 것인것만 받겠다

Amazon MQ

Rabbit MQ의 매니지드 서비스

SQS vs SNS

1:1 vs 1:n

Apache MQ

ElasticCache

전략

writethrough : 캐쉬에 쓰는 동시에DB에 씀. 매번 갱신하므로 속도가 느림. lazyloading : 캐쉬에 먼저 쓰고 나중에 갱신. 일관성 깨짐

redis : pub/sub 기능 제공

안전한 App

AC(certificates)M

인증서 갱신/발급/관리

AS(Secrets)M

보안정보 관리/갱신

STS

티켓 받아오기 ex) aws 외부 서비스가 s3에 파일을 올리려고 한다.

  • 내부 서비스가 아니므로 iam role을 사용할 수 없음.
  • sts에서 임시 크리덴셜을 받아서 사용

배포 자동화

인프라수준의 배포(Infra as a code)

  • CloudFormation
  • SAM Serverless App Template(?) 왜M?

Application

프로세스(CI/CD Pipeline)

  • 프로세스 : Code->build->test->deploy->monitoring
  • 전체지원도구 : Code Pipeline

스텝별 도구

  • Code : Code Commit
  • Build : Code Build
  • Test : 서드파티도구
  • Deploy : Code Deploy
  • Monitoring : Cloudwatch, Cloudtrail

Code Star

지라, 젠킨스까지 다 커버되는 프로세스 전체 관리

참고

Previous
Untitled 1
Next
F5 BIG-IP TCP 연결 흐름