[ AWS ] S3 수명주기 관리

[ 수명 주기 관리 ]

스토리지 수명 주기 관리에는 2가지 작업으로 수행한다.

• 전환작업
• 스토리지 클래스 전환 Ex. S3d STANDARD-IA -> S3 Glacier
• 만료작업
• 설정한 만료 기간에 따라 객체 삭제

해당 작업을 위해선 설정하려는 S3에 대해

날짜와 빈도를 고려해야 최적의 비용을 산출 할 수 있다.

날짜 : 최근 N일은 자주 사용하지만 그 이후는 참조가 거의 없음

빈도 : N일 동안 M번 정도 참고 할 것 같고, N일 이후에는 액세스가 적지만 P번 정도 참조




[ 수명 주기 구성 생성 ]

생성할 수 있는 Tool

• Amazon S3 콘솔
• REST API
•  AWS SDK 
• AWS CLI

[ 객체 전환 ]

아래의 그림과 같이 내려갈수록 

객체 액세스 빈도 ↓, 비용 ↓ 

또한 하위 객체에서 상위 객체로의 전환은 불가하다. 

* 제약사항 *

사이즈

S3 Standard-IA, S3 Intelligent-Tiering, S3 One Zone-IA로 전환 시

128KB보다 작은 객체는 전환을 제공하지 않는다.

최소 유지 기간

객체가 전환되고 난 후 다른 스토리지 클래스로 전환하기 위해선

최소 기간을 유지한 후에 가능하다.

TYPE	1G당 비용(1개월)	최소 유지 기간	설계 내용
S3 Standard	0.025		자주 액세스하는 데이터
S3 Standard - Infrequent Access	0.018	30	수명이 길고 자주 액세스하지 않는 데이터
S3 One Zone - Infrequent Access	0.0144	30	수명이 긴 데이터에 자주 액세스하지 않는 중요하지 않은 데이터
S3 Glacier	0.005	90	분에서 시간 단위로 검색 시간을 지원하는 장기간 데이터 보관
S3 Glacier Deep Archive	0.002	180	12시간의 기본 검색 시간으로 거의 액세스하지 않는 데이터 아카이빙

S3 Glacier 

• S3 Glacier or S3 Glacier Deep Archive에 저장된 객체는 실시간으로 사용X
• 아카이브 상태이므로 임시복사본으로 복원하는 작업 필요
• 복원 후 지정한 기간 동안 사용 가능, 그 후 복사본 삭제 후 아카이브 상태로 유지

[ 객체만료 ]

수명 주기 정책에 따라 만료가 될 경우 

S3에서는 제어를 위해 대기열에 넣고 비동기 방식으로 제거합니다.

만료 된 객체에 대해서는 요금이 청구 되지 않습니다.

[ 버킷 수명 주기 설정 ]

버킷의 수명 주기를 설정하는 방법은 4가지가 있다.

• S3 Console
• AWS CLI 
• AWS SDK ( Java/.NET/Ruby )
• REST API ( PUT/GET/DELETE )

[ S3 console을 사용하여 간단히 수명 주기를 적용 ]

1. S3버킷 페이지에서 -> 버킷선택 -> 관리 -> 수명 주기 규칙 생성

2. 수명 주기 규칙 구성

규칙 범위 선택 :

버킷 하위 파일 모두 적용하느냐 필터로 범위를 제한하느냐 여부 

'하나 이상의 필터를 사용하여 이 규칙의 범위 제한' 선택 시 접두사 사용

Ex. path가 아래와 같다면, 

bucket_name/logs/users/yymmdd=20211201/00001.parquet

• logs하위 파일들에게만 적용 접두사 = logs
• 파티셔닝된 yymmdd 하위 파일들에게만 적용, 접두사 = logs/users/yymmdd=

3. 수명 주기 규칙 작업

'스토리지 클래스 간에 객체의 현재 버전 이동' 

• Standard(현재)에서 Standard-IA로 스토리지 클래스 변경

'객체의 현재 버전 만료'  

• 제시한 요청일 이후 객체삭제

* 이전버전 사용시 버킷생성할 때 아래 설명을 활성화해야한다.

4. 일수 설정

해당 일수를 설정하고 규칙생성 클릭

참조 

스토리지 클래스 종류 :

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/storage-class-intro.html

S3 Glacier :

https://docs.aws.amazon.com/ko_kr/amazonglacier/latest/dev/introduction.html

스토리지 수명 주기 관리 :

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html

[ AWS ] Organization 시작하기

[ Organization이란? ]

AWS Organizations 기능

• 중앙에서 계정 관리
• 계정 일부나 전체에 정책연결 가능
• 계정 별로의 서비스 사용 요금 식별 가능
• 계정 별로 활동 기록 로그 추적
• 계정 또는 계정을 그룹화 하여 서비스 액세스관리
• 계정 수준으로 권한 관리를 확장( Organizations >> 사용자 iam role )
• 사용자는 organizations와 iam정책 모두 허용하는 것만 액세스
• 다른 AWS 서비스와 통합
• 전역 액세스 ( 리전 구분없음 )

AWS Organizations 요금

• 무료

AWS Organizations에 액세스

• Organization Console
• AWS CLI
• AWS SDK
• AWS HTTPS API

AWS Organizations 개념

[ 실습 ]

1. 조직 만들기

2. 기존 멤버 초대하기

3. 조직 단위 만들기

4. 서비스 제어 정책 생성

    - AWS CloudTrail 로그도 생성 및 수정 제어

Prerequisites

AWS계정 2개 :

111111111111 - 조직을 만들 때 사용하는 계정

222222222222 - 멤버 계정으로 조직에 초대한 계정

1. 조직 만들기

- 111111111111 계정의 관리자로 AWS에 로그인한 후 AWS Organizations 콘솔을 오픈

- 소개 페이지에서 조직 생성(Create organization)을 선택

- 확인 대화 상자에서 조직 생성Create organization)을 선택

2. 기존멤버초대하기

- 111111111111 계정 verification : 해당메일로가서 계정이메일 인증

- 계정초대메세지 보내기

- 222222222222 계정으로 로그인하여 초대수락

- 111111111111(관리계정) 외에 다른 멤버 확인

3. 조직단위 만들기

- 조직단위 생성 후, 생성된 곳에 222222222222 계정 이동

4. 서비스 제어 정책 생성

- 정책(Policies) -> 서비스 제어 정책(Service Control Policies)을 선택

- 서비스 제어 정책 활성화(Enable service control policies)를 선택

    조직에서 SCP를 만들 수 있음을 알리는 녹색 배너가 나타남

- 정책(Policies) 페이지로 이동한 다음 서비스 제어 정책(Service Control Policies)을 선택

- 서비스 제어 정책 페이지(Service control policies)에서 정책 생성(Create policy)을 선택

- 정책 이름에 Block CloudTrail Configuration Actions을 입력

- 정책(Policy) 섹션의 왼쪽에 있는 서비스 목록에서 CloudTrail을 서비스로 선택

- 다음 AddTags, CreateTrail, DeleteTrail, RemoveTags, StartLogging, StopLogging 및 UpdateTrail 작업을 선택

- 왼쪽 창에서 리소스 추가(Add resource)를 선택하고 CloudTrail 및 모든 리소스(All Resources)를 지정 

- 다음 리소스 추가를 선택합니다.

참조 :

https://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_tutorials_basic.html

[ Glue ] Pycharm, Notebook 개발환경 설정

[ 사전 설치 ]

1. Docker 

2. Pycharm

3. aws configure 설정

[ Dokcer ]

#이미지 다운로드 

docker pull amazon/aws-glue-libs:glue_libs_1.0.0_image_01

# 참고 문서 : https://aws.amazon.com/ko/blogs/big-data/developing-aws-glue-etl-jobs-locally-using-a-container/

# 실행 - Mac / Linux

docker run -itd -p 8888:8888 -p 4040:4040 -v ~/.aws:/root/.aws:ro --name glue_jupyter amazon/aws-glue-libs:glue_libs_1.0.0_image_01 /home/jupyter/jupyter_start.sh

# 실행 - Windows 

docker run -itd -p 8888:8888 -p 4040:4040 -v c://user_path//.aws:/root/.aws:rw --name glue_jupyter amazon/aws-glue-libs:glue_libs_1.0.0_image_01 /home/jupyter/jupyter_start.sh

# 제플린이라면 

8888:8888 -> 8080:8080

/home/jupyter/jupyter_start.sh -> /home/zeppelin/bin/zeppelin.sh

#아래 이미지와 같이 해당 container 생성 확인

# bash 셀 사용

docker exec -it glue_jupyter bash

[ 노트북 사용 ]

# notebook or zeppelin

http://localhost:<port_on_client>에 접속

[ Pycharm 설정 ]

아래 참조 url에 따라 실행

https://aws.amazon.com/ko/blogs/big-data/developing-aws-glue-etl-jobs-locally-using-a-container/

* 주의할 내용은 Host path값이 C:\User\path\.aws라면

C://User//path//.aws로 치환해야 Pycharm에서 인식한다.

* .aws 폴더가 없다면 aws configure설정했는지 확인

[ AWS ] SAM을 통한 Lambda Layer with Pycharm

Pycharm 환경에서 Layer를 생성하고 

배포하는 과정이다.

아래 과정 이후에 진행하면 도움이 된다.

[ AWS ] SAM을 통한 Lambda 개발환경 셋팅

[ AWS ] SAM을 통한 Lambda Local Debugging

1. Layer 선언

프로젝트에 패키지 하나를 따로 생성해 

Layer로 쓸 function들을 정의한다.

이후 template.yaml 파일에 

해당 패키지를 mapping해준다.

[ template.yaml ]

TestCommon:

    Type: AWS::Serverless::LayerVersion

    Properties:

      ContentUri: test_common/

      CompatibleRuntimes:

        - python3.9

      LayerName: test_common

      RetentionPolicy: Retain

명시한 Layer(TestCommon)를

배포 시 해당 함수에 물리게끔 하는 작업이 필요하다.

2가지 방법이 있는데,

Globals부분 또는 Resoureces 부분에 명시한다.

[ template.yaml ]

Globals:

  Function:

    Timeout: 600

    MemorySize: 128

    Tracing: Active

    Layers:

      # 택1

      - !Ref TestCommon 

      ( or )

      # 택2 - 미리 Lambda Layer에 Upload 되어있을 시

      - arn:aws:lambda:ap-northeast-2:123123:layer:test_common:1

Resources:

  HelloWorld:

      ...

      Layers:

        - !Ref TestCommon

Globals부분에 선언하면 Resources하위 Function에 다 적용이 되어서

한번만 적으면 되어 편리함이 있지만,

각 Function마다 Layer를 다르게 설정할 경우에는 

Resources부분에 각각 적용한다.

Lambda Layer 만들기 참고 Ref : 

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/configuration-layers.html

이후 아래 명령어로 배포하면 Function과 Layer 모두 Lambda에 업데이트 된다.

sam deploy --stack-name testLambda --s3-bucket test-dighty-appinstall

2. Layer 폴더추가 

a. 해당 구조로 생성

b. layer는 sam build시에도 build 디렉토리에 나타나지 않음

3. Package 정리 Layer

업로드 된 람다 함수의 코드를 보면 

아래 그림과 같이 import하는 패키지들도 같이 업로드 된다.

이 패키지들을 Layer로 만들면 

재사용하기도 쉽고 파일도 깔끔해질 것이다.

a. 업로드할 Lamba Function의 Package의 requirements 비운다.

b. layer로 사용할 directory를 만든 후, requirements.txt파일에 필요한 library를

   pip freeze 등의 명령어로 input 

c. 해당 명령어 실행

pip install -r ./package_layer/requirements.txt -t ./package_layer/

d. 디렉토리에 관련 lib설치 확인

e. template.yaml에서 Metadata설정 추가

TestCommon:

    Type: AWS::Serverless::LayerVersion

    Properties:

        ContentUri: test_common

        CompatibleRuntimes:

            - python3.9

        LayerName: test_common

        RetentionPolicy: Retain

    Metadata:

        BuildMethod: python3.9

f. sam bulid

g. build 디렉토리에서 Layer만 따로 빌드된 폴더가 추가됨

이제 sam deploy로 배포하면

Lambda 프로젝트 폴더 안에 관련 패키지가 없음에도 

import하여 사용할 수 있다.

CloudWatch에서 해당 람다함수 로그까지 확인한다.

참조 : https://aws.plainenglish.io/a-practical-guide-surviving-aws-sam-part-3-lambda-layers-8a55eb5d2cbe

[ AWS ] SAM을 통한 Lambda Local Debugging

아래 단계의 다음 단계이다.

Sam을 통한 Pycharm Lambda 개발환경 셋팅

 

1. template.yaml 파일 수정

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
test description 

# Global 설정 Layer선언 부분
Globals:
  Function:
    Timeout: 3

# 람다 함수 관련 부분
Resources:

  # 대표이름, sam build시 해당 이름으로 폴더가 생성됨
  HelloWorld:
    Type: AWS::Serverless::Function

    Properties:

      # 해당 폴더가 있는 URL ( ex. myPycharmProject/sam-app/hello_world/app.py )
      CodeUri: hello_world/

      # 함수명, Lambda에서 보여질 이름
      FunctionName: test_hello_world
      Handler: app.lambda_handler
      Runtime: python3.9
      Architectures:
      - x86_64

      # AWS IAM Role. 관련 Role이 없다면 sam delploy -g 를 통해 배포 시 자동생성

      Role: 'arn:aws:iam::123123123:role/lambdaEtlRole'

#      #Web Api, S3 Trigger 등 Event 선언 부분
#      Events:
#        HelloWorld:
#          Type: Api
#          Properties:
#            Path: /hello
#            Method: get

  # 한 프로젝트에 여러 Lambda 함수를 정의하고 싶을 때 이어서 쓰면 된다.

  HelloWorld_2:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world_2/
      FunctionName: hello_world_2
      Handler: app.lambda_handler
      Runtime: python3.9
.....

2. Edit Configurations

a. 최상단의 Run/Debug 종류를 고르는 select box에서 edit configurations를 클릭

b. 위 이미지의 좌측 상단에 '+'를 클릭해 AWS Lambda 선택

c. from template 선택 -> template.yaml 지정 -> 함수 지정 -> input 데이터 지정

d. Apply 후 Ok, Run 실행

3. Local Debugging

braekpoint를 찍어 디버깅이 잘 되는지 확인

[ AWS ] SAM을 통한 Lambda 개발환경 셋팅

[ 사전 설정 ]

1. aws cli

OS별 설치 방법 : https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/install-cliv2.html

2. aws sam cli

OS별 설치 방법 : https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html

3. docker 설치

Run Function을 하게 되면 Docker 환경에서 실행 됨

Mac OS일 경우 마운트 경로 추가

4. pycharm 설정

plugin에서 aws toolkit을 검색 하여 설치

aws설치 path가 잘 잡혔는지 확인

프로젝트 생성

[ SAM 명령어 ]

Step 1 - Download a sample application

$ sam init

Step 2 - Build your application

$ cd sam-app

( 코드 추가 or 수정 )

$ sam build

$ sam local invoke

Step 3 - Deploy your application

$ sam deploy --guided

or 

$ sam deploy --stack-name testLambda --s3-bucket test-bucket-name

Sam Deploy Option Ref : 

https://aws.amazon.com/ko/blogs/compute/a-simpler-deployment-experience-with-aws-sam-cli/

Sam Example Ref : 

https://docs.aws.amazon.com/ko_kr/serverless-application-model/latest/developerguide/serverless-getting-started-hello-world.html

AWS Toolkit Ref : 

https://docs.aws.amazon.com/ko_kr/toolkit-for-jetbrains/latest/userguide/welcome.html

[ AWS ] 

배포 일련의 과정을 보자면

-> Lambda 애플리케이션의 코드를 압축해 S3에 업로드

-> CodeUri가 S3 path로 설정된 CloudFormation template파일 생성, S3에 업로드

-> S3에 업로드된 파일을 이용해서 CloudFormation 스택을 생성해서 Lambda에 배포

CloudFront 과 S3를 살펴보면

배포 관련 Stack과 S3안에 파일이 생성된 것을 볼 수 있다.

[ Git ] 기본 명령어

[ 저장소 ]

git remote

  - git 원격저장소[Repository] 목록 확인

git remote -v

  - git 원격저장소 이름과 url 목록 확인

git remote add 저장소이름 저장소URL 

  - 저장소URL의 원격저장소를 저장소이름으로 추가

git remote rm 저장소이름

  - 저장소이름의 원격저장소 제거

[ 확인 ]

git log

  - commit 로그 확인

git status

  - 파일 상태 확인(staged, untracked, ..)

git diff

  - commit된 파일상태와 현재 수정중인 상태 비교

git diff --staged

  - commit된 파일상태와 add된 파일 상태 비교

[ 업로드 ]

git add 파일명1 파일명2

  - 해당 파일을 [Staging Area]로 이동(tracking)

git commit -m "커밋메세지"

  - editor 호출없이 바로 커밋

git push

  - 원격저장소[Repository]에 local repository[Working Directory]의 commit 내용을 올림

[ 다운로드 ]

git pull

  - 원격저장소[Repository]의 내용을 가져와서(fetch) local repository[Working Directory]에 합침(merge)

[ 브런치 ]

git branch <브랜치 이름>

 - 브런치생성

git checkout <브랜치 이름>

 - 사용할 브런치로 변경

git branch -r (-a는 로컬원격전부 확인)

 - 원격브런치 목록확인

git push origin <브랜치 이름> 

 - 로컬브런치를 원격브런치로 추가

git branch --set-upstream-to origin/<브랜치 이름> 

 - 로컬브런치와 원격브런치 연동

git branch -d <브랜치 이름>

 - 브런치 삭제

git push origin --delete <브랜치 이름>

 - 원격저장소 브런치 삭제

[ 브런치 병합 ]

git checkout master

 - master사용

git branch -a 

 - checkout 바뀌었는지 확인

git merge <브런치 이름>

 - 병합

git push

 - 원격저장소에 병합할 경우 

[ 초기설정 ]

git init

git add .

git commit -m 'init'

github에서 프로젝트 생성

git remote add origin https://github.name.com/42f-platfrom/00000.git

git push --set-upstream origin master

[ git reset ]

git reset COMMIT_ID

- 로컬 저장소 원하는 commit 시점으로 리셋

git push -f origin master

- 원격 저장소 롤백

https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html