Computer Science Knowledge Storage

제가 공부한 내용을 정리하는 블로그입니다.
아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁

해당 포스팅은 Github Action 사용법 정리입니다.

서론

GitHub Actions는 소프트웨어 워크플로우를 자동화하는 도구입니다. 이를 통해 코드를 빌드하고, 테스트하고, 배포하는 과정을 간소화할 수 있습니다. 특히 GitHub Actions는 YAML 파일을 기반으로 정의되며, 다양한 이벤트(예: push, pull request, cron 등)에 따라 실행됩니다.

이번 포스팅에서는 GitHub Actions의 기본 개념과 함께, API를 기능별로 자동화하거나 Python 프로젝트에서 유용하게 사용할 수 있는 예제를 소개합니다.

Github Actions 기본개념

GitHub Actions를 이해하기 위해 알아야 할 주요 개념은 다음과 같습니다

1. Workflow
   • 자동화된 프로세스의 가장 상위 개념으로, 여러 Job으로 구성됩니다.
   • YAML 파일로 정의되며, .github/workflows 폴더에 저장됩니다.
2. Event
   • Workflow를 실행하는 특정 조건이나 규칙입니다.
     예: 브랜치로의 push, pull_request, schedule(cron) 등.
3. Job
   • 특정 작업 단위를 정의하며, 여러 Step으로 구성됩니다.
   • 독립적으로 실행되거나 다른 Job과 병렬 실행이 가능합니다.
4. Step
   • 각 작업(Job)을 구성하는 단위로, 커맨드 실행 또는 액션 사용이 가능합니다.
5. Action
   • Workflow의 재사용 가능한 가장 작은 구성 요소입니다.
     예: actions/checkout@v2를 사용하여 리포지토리를 체크아웃.

Workflow 정의 방법

GitHub Actions의 Workflow는 .github/workflows 디렉토리에 .yml 파일로 작성됩니다. 아래는 간단한 Workflow 예제입니다.

on:
    push:
      branches: [ master ]
    pull_request:
      branches: [ master ]

• on (이벤트 정의)
  Workflow를 Trigger(실행)하는 조건을 정의합니다.
  • 주요 이벤트:
    • push: 특정 브랜치나 태그로 코드가 푸시될 때 실행.
    • pull_request: 특정 브랜치로 PR(Pull Request)이 생성되거나 업데이트될 때 실행.
    • schedule: 특정 시간에 반복적으로 실행(Cron 표현식 사용).
    • 여러 이벤트를 정의할 수 있으며, 배열로 작성 가능합니다.

jobs:
    build:
      runs-on: ubuntu-latest

      steps:
      - uses: actions/checkout@v2
      - name: Run a one-line script
        run: echo Hello, world!

      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

• jobs
  Workflow는 여러 Job으로 구성되며, 각 Job은 독립적으로 실행됩니다.
  
  • 병렬 실행: 기본적으로 여러 Job은 병렬로 실행됩니다.
  • build라는 job을 생성하고, 그 아래에 2개의 step이 존재하는 구조
    • runs-on은 어떤 OS에서 실행될지 지정
    • name: Job의 이름을 지정.
    • runs-on: Job이 실행될 운영 체제(OS) 환경을 지정
    • env: 환경변수 등록Job의 주요 요소:
  • steps의 uses는 어떤 액션을 사용할지 지정함. 이미 만들어진 액션을 사용할 때 지정

기본 Workflow 예제

name: CI workflow

on:
  push:
    branches:
      - dev
  pull_request:
    branches:
      - dev

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Grant execute permission for gradlew
        run: chmod +x ./gradlew

      - name: Build with Gradle
        run: ./gradlew clean build --info

      - name: Upload Artifact
        uses: actions/upload-artifact@v3
        with:
          name: spring-app
          path: build/libs/*.jar

  deploy:
    needs: build
    runs-on: ubuntu-latest

    steps:
      - name: Download Artifact
        uses: actions/download-artifact@v3
        with:
          name: spring-app

      - name: Deploy JAR to AWS
        uses: appleboy/scp-action@v0.1.4
        with:
          host: ${{ secrets.AWS_SERVER_IP }}
          username: ${{ secrets.AWS_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          source: "*.jar"
          target: "~/proj"

      - name: Restart Application on AWS
        uses: appleboy/ssh-action@v0.1.10
        with:
          host: ${{ secrets.AWS_SERVER_IP }}
          username: ${{ secrets.AWS_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            # Define variables
            DEPLOY_DIR=~/proj
            JAR_FILE=server-0.0.1-SNAPSHOT.jar

            # Kill process on port 8080
            echo "Stopping existing server..."
            PID=$(sudo lsof -t -i:8080)
            if [ -n "$PID" ]; then
              sudo kill -9 $PID
            fi

            # Navigate to deployment directory
            cd $DEPLOY_DIR || exit

            # Start the new server
            echo "Starting new server..."
            nohup java -jar $JAR_FILE > app.log 2>&1 &
            echo "Server restarted. Logs can be found in $DEPLOY_DIR/app.log"

YAML 파일 설명

해당 yaml은 dev 브랜치에 이벤트가 발생할 때마다 AWS 서버에 실행 중인 서버를 껏다가 업데이트 된 것으로 실행하는 workflow입니다.

1. build Job:
   • GitHub Actions에서 코드 체크아웃, JDK 설치, 빌드, 그리고 생성된 JAR 파일을 아티팩트로 업로드합니다.
2. deploy Job:
   • 빌드된 JAR 파일을 다운로드하여 AWS 서버로 전송한 후, 애플리케이션을 재시작합니다.
   • 기존 서버 프로세스를 종료하고 새 JAR 파일로 서버를 실행합니다.

분석

이벤트 트리거

• on:
  • push 또는 pull_request 이벤트가 dev 브랜치에서 발생하면 Workflow가 실행됩니다.

build Job

• runs-on:
  • Job이 실행될 환경으로 ubuntu-latest를 사용합니다.
• steps:
  1. actions/checkout: 리포지토리를 체크아웃합니다.
  2. actions/setup-java: JDK 17을 설치합니다.
  3. gradlew clean build: Gradle을 사용해 소스 코드를 빌드합니다.
  4. actions/upload-artifact: 빌드 결과물(JAR 파일)을 업로드합니다.
• with:
  1. uses로 지정한 Action에 인자(Arguments)를 전달할 때 사용됩니다.
  2. Action의 동작을 세부적으로 설정하는 데 필요합니다.

deploy Job

• needs:
  • build Job이 성공적으로 완료된 후 실행됩니다.
• steps:
  1. actions/download-artifact: 빌드된 JAR 파일을 다운로드합니다.
  2. appleboy/scp-action: 다운로드된 JAR 파일을 AWS 서버로 전송합니다.
  3. appleboy/ssh-action:
     • 기존 서버 프로세스를 종료합니다.
     • 새로운 JAR 파일로 서버를 시작합니다.
• run:
  1. 정의:
  2. Job에서 실행할 커맨드(Command)를 지정합니다.
  3. 단일 명령어 또는 여러 줄 명령어를 실행할 수 있습니다.

제가 공부한 내용을 정리하는 블로그입니다.
아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁

해당 포스팅은 Bash Shell 정리입니다.

서론

Bash는 유닉스 및 리눅스 환경에서 사용되는 가장 널리 알려진 셸로, 강력한 스크립팅 기능을 제공하여 시스템 관리와 반복 작업 자동화에 매우 유용합니다. Bash Shell 스크립팅은 단순한 명령어 실행을 넘어 변수, 조건문, 반복문, 함수 등을 활용하여 복잡한 작업을 효율적으로 처리할 수 있습니다. 이번 포스팅에서는 Bash Shell 프로그래밍을 초보자도 쉽게 이해하고 활용할 수 문법 정리를 하겠습니다!

본론

1. Bash 스크립트 기본 구조

쉘 스크립트는 첫줄에 어떤 쉘로 스크립트를 실행할지 정의하는 부분이 존재합니다.

Bash 스크립트는 #!/bin/bash라는 셰뱅(Shebang)으로 시작하며, 실행 권한을 부여한 후 실행됩니다.

#!/bin/bash 

echo "Hello, World!"

• 쉘 종류
  • sh: 초기 유닉스 쉘
  • bash: sh와 대부분 호환되는 Bash Shell
  • ksh: 콘 쉘이라고도 불리며 sh를 확장하여 만든 쉘
  • csh: C언어 기반의 쉘
• 스크립트 실행

chmod +x script.sh
./script.sh

실행권한을 주어야 스크립트를 실행할 수 있습니다.

2. 변수와 데이터

변수는 프로그래밍 언어들과 같은 제약조건이 존재하며 값을 사용할 때에는 $로 시작하고 변수를 생성할 때에는 대입문자 앞뒤로 공백이 없어야 합니다. 

• 변수 선언

variable="값"

• 변수호출

echo $variable # {}가 있으나 없으나 $만으로 변수의 값을 넣어줄 수 있으나, 문자열을 붙여서 쓸려면 ${} 를 사용해야 한다.
echo "this product's price is ${variable}"

• 읽기 전용 변수

readonly variable

• 사용자 입력 받기

read -p "Enter your name: " name
echo "Hello, $name!"

• 환경변수

쉘 스크립트에서 변수명 앞에 export를 붙여주면 환경변수로 설정되어 스크립트에서 사용 가능합니다.

관례로 환경변수는 모두 대문자를 작성해주셔야 합니다.

# network.sh 작성
#!/usr/bin/bash
echo ${ENDPOINT}

# 환경변수 선언
export ENDPOINT="localhost:8080"

3. 조건문

중괄호 대신 fi문으로 if문의 종료를 알리며 조건식이 들어가는 대괄호 [] 사이에 공백이 존재해야합니다.

• if문 기본 사용법

if [ 조건 ]; then
    echo "조건이 참입니다."
else
    echo "조건이 거짓입니다."
fi

• 숫자 비교 연산자
  • -eq: 같음
  • -ne: 같지 않음
  • -lt: 작음
  • -le: 작거나 같음
  • -gt: 큼
  • -ge: 크거나 같음

num=10
if [ $num -gt 5 ]; then
    echo "$num은 5보다 큽니다."
fi

4. 반복문

• for문

for i in {1..5}; do
    echo "숫자: $i"
done

• while문

count=1
while [ $count -le 5 ]; do
    echo "Count: $count"
    count=$((count + 1))
done

5. 함수

• 함수 정의 및 호출

function greet {
    echo "Hello, $1!"
}
greet "Bash"

• 매개변수

#!/bin/bash

echo "첫 번째 매개변수: $1"
echo "두 번째 매개변수: $2"
echo "모든 매개변수: $@"
echo "매개변수 개수: $#"

# 실행
./script.sh Hello World

# 출력
첫 번째 매개변수: Hello
두 번째 매개변수: World
모든 매개변수: Hello World
매개변수 개수: 2

6. 파일 처리

• 파일 존재 여부 확인

if [ -e filename ]; then
    echo "파일이 존재합니다."
fi

• 파일 읽기 예제

while read line; do
    echo $line
done < filename.txt

7. 기타 유용한 문법

• 명령어 실행 결과 저장

result=$(ls -l)
echo "$result"

• 에러 처리

command || echo "명령어 실패!"

결론

Bash Shell 프로그래밍은 간단한 문법으로 시스템을 제어하고 반복 작업을 자동화하는 데 강력한 도구가 됩니다. 이번 포스팅에서는 변수, 조건문, 반복문, 함수 등 핵심 문법을 정리했으며, 이를 기반으로 더 복잡한 스크립트를 작성할 수 있습니다. 꾸준한 연습과 다양한 예제 실습을 통해 Bash 스크립팅 실력을 쌓아 보세요😁

해당 포스팅은 AWS 강의실(https://www.youtube.com/@AWSClassroom)를 보고 공부한 내용을 정리한 블로그입니다.

아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁

네 자신의 불행을 생각하지 않게 되는 가장 좋은 방법은 일에 몰두하는 것이다.
Ludwig van Beethoven

Static VS Dynamic Contents

Static Contents

• 서버에 저장된 파일이 모든 사용자에게 동일하게 전달되는 컨텐츠
• 매번 서버에 요청할 필요없이 캐싱 가능
• HTML/Javascript 등으로 구성
• 예: 이미지, 글, 뉴스 등

Dynamic Contents

• 시간, 사용자, 입력 등에 따라 내용이 변경되는 컨텐츠
• 매번 서버에 요청하여 내용을 구성하고 전달받아야함.
• PHP, JSP, ASP.net 등으로 서버 처리
• 예: 로그인이 필요한 내용, 게시판, 댓글 등

Amazon S3 Static Hosting

• S3를 사용해서 정적(Static) 웹 컨텐츠를 호스팅하는 기능
• 별도의 서버 없이 웹사이트 호스팅 가능
• 고가용성/장애 내구성을 확보
• 사용 사례: 대규모 접속이 예상되는 사전 예약 페이지, 홍보 페이지, 회사 웹 사이트 등

권한

• 정적 웹 호스팅을 public으로 공개할 경우: 불특정 다수에게 허용되는 권한 부여 필요
• 불특정 다수가 접속할 수 있는 권한을 확보하려면
  • S3 Block Public Access 해제 필요
  • Bucket Policy에서 정책 허용 필요

활용

• route 53에서 보유한 도메인으로 연결 가능
  • 단 버킷명 = 호스팅 주소여야 가능
  • test.example.com으로 호스팅하고 싶다면, 버킷명도 ‘test.example.com’ 필요
• 실전에서 CloudFront와 연동
  • HTTPS 프로토콜 구현을 위해서 CloudFront와 연동 필요.
    • ACM을 통한 SSL 키 관리가 가장 편함
    • 보통 Public Hosting의 활성화 대신 그대로 Private 모드로 두고 OAI/OAC 등을 활용해서 보안 강화

아키텍처

실습

1. 버킷 만들기

  1. S3 버킷의 정적 호스팅 기능 활성화하기

2. 속성 -> 정적 웹사이트 호스팅 편집

3. 퍼블릭에 공개할 수 있는 권한 및 설정 적용

4. S3 버킷에 샘플 static 웹 사이트 파일을 작성해서 업로드하기

  1. S3 정적 호스팅 웹 주소를 사용해 웹 사이트 동작 확인하기 

  2. 파일 업로드 후 퍼블릭 도메인에 접근

5. 도메인 이름을 바꾸고 싶으면 Route 53을 변경해야함.

해당 포스팅은 AWS 강의실(https://www.youtube.com/@AWSClassroom)를 보고 공부한 내용을 정리한 블로그입니다.

아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁

네 자신의 불행을 생각하지 않게 되는 가장 좋은 방법은 일에 몰두하는 것이다.
Ludwig van Beethoven

암호화

1. On Transit: SSL/TLS(HTTPS) ⇒ 데이터가 클라이언트에서 s3로 통신하는 과정에서의 암호화
2. At Rest(Server Side)
   1. SSE S3
   2. SSE KMS
   3. SSE C
3. Client Side 

At Rest(Server Side)

• S3가 데이터를 저장할 때 암호화

SSE S3

• S3에서 알아서 암호화

SSE KMS

• KMS 서비스를 이용해 암호화
• KMS로 활용하기에 키를 로깅 및 로테이션 가능
  • 권한 분리 가능

SSE C

• 클라이언트에서 제공한 암호를 암호화
• 클라이언트 키를 같이 암호화
• 클라이언트가 키를 보관해야함.(잃어버리면 데이터 복구 불가)

Client Side

• 클라이언트가 직접 암호화

해당 포스팅은 AWS 강의실(https://www.youtube.com/@AWSClassroom)를 보고 공부한 내용을 정리한 블로그입니다.

아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁

네 자신의 불행을 생각하지 않게 되는 가장 좋은 방법은 일에 몰두하는 것이다.
Ludwig van Beethoven

버전관리

• 객체의 생성, 업데이트 삭제의 모든 단계를 저장
  • 삭제시에는 실제 객체를 삭제하는 대신 삭제 마커를 추가
• 버킷 단위로 활성화 필요(기본적으로 비활성화)
  • 중지 가능, 단 비활성화 불가능
  • 한번 버전관리를 시작하면 비활성화 불가능(버킷 삭제 후 재생성으로 해결 가능)
• 수명 주기 관리와 연동 가능
• MFA 인증 후 삭제 기능을 통해 보안 강화 기능

• delete marker만 삭제하면 version 22222를 확인 가능.
• 버전 삭제도 가능.

버전 관리 유의 사항

• 중지 가능, 단 비활성화 불가능
  • 한번 버전관리를 시작하면 비활성화 불가능(버킷 삭제후 재생성으로 해결 가능)
• 모든 버전에 대해 비용 발생
  • 10gb 객체의 버전이 5개 있다면, 총 50gb에 대해 비용 발생

객체 잠금

• Write Once, Read Many(WORM) 모델을 활용하여 객체를 저장
• 고정된 시간, 혹은 무기한으로 객체의 삭제/덮어쓰기 방지 가능
• 규정 준수 및 객체의 보호를 위해 사용
• 버전 활성화 필요

종류

• 보관모드(Retention Mode): 일정 기간동안 수정 방지
  • 규정 준수 모드: 누구도 잠금 설정 변경, 객체 삭제 불가능
  • 거버넌스 모드: 특별한 권한 없이 삭제 혹은 잠금 설정 변경 불가능
    • 객체 삭제 방지 혹은 규정에 따라 보관하기 위해 사용
    • 규정 준수 모드의 테스트
• 법적 보존(Legal Hold)
  • Hold를 객체에 부여하고 Hold가 존재하는 한 객체 삭제, 수정 불가능
  • 제한 기간이 없음

해당 포스팅은 AWS 강의실(https://www.youtube.com/@AWSClassroom)를 보고 공부한 내용을 정리한 블로그입니다.

아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁

네 자신의 불행을 생각하지 않게 되는 가장 좋은 방법은 일에 몰두하는 것이다.
Ludwig van Beethoven

S3 권한 관리

S3 버킷 정책

• IAM 정책 중의 리소스 정책

IAM 종류

• Identity-based policies(자격 증명 기반 정책)
  • 자격 증명(IAM 유저, 그룹, 역할)에 부여하는 정책
  • 해당 자격증명이 무엇을 할 수 있는 지 허용

• Resource-based policies(리소스 기반 정책)
  • 리소스(S3, SQS VPC Endpoint, KMS 등)에 부여하는 정책
  • 해당 리소스에 누가 무엇을 할 수 있는지 허용 가능
    • SQS 대기열에 lambda Service가 접근 가능
    • IAM 정책을 평가할 때 리소스 정책 허용이면 허용하는 특징

S3 버킷 정책

• 버킷 단위로 부여되는 리소스 기반 정책
• 해당 버킷의 데이터에 언제 누가 어디서 무엇을 어떻게 할 수 있는지 정의 가능
  • 리소스 계층 구조에 따라 권한 조절 가능
  • 다른 계정에 엔티티에 대해 권한 설정 가능(cross account)
  • 익명 사용자에 대한 권한 설정 가능.
• 기본적으로 모든 버킷은 Private ⇒ 접근 불가능

S3의 계층 구조

{
	"Version": "2012-10-17",
    "Statement": [
    	{
        	"Sid": "StatementAllow",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::demo.rwlecture.com/*",
        }
    ]
}

• AWS 콘솔에서는 S3의 디렉토리를 생성 가능하고 확인 가능
• S3 내부적으로는 계층 구조가 존재하지 않음
  • 키 이름에 포함된 “/”로 계층 구조를 표현
  • 예
    • s3:mybucket/aaa/bbb/ccc/ddd
    • bucket: mybucket
    • key: aaa/bbb/ccc/ddd(단일 스트링)
  • effect: 허용
  • principal: 누가? ⇒ 퍼블릭 액세스 차단 편집을 수정해야함.
  • action: 무엇을
  • resource: 어떤 버킷에 대해서?

버킷 관리 방법의 선택

• Identity-based policies(자격 증명 기반 정책)
  • 같은 계정의 IAM 엔티티의 S3 권한 관리할 때
  • S3 이외에 다른 AWS 서비스와 같이 권한 관리할 때
• Resource-based policies(리소스 기반 정책)
  • 익명 사용자 혹은 다른 계정의 엔티티의 S3 이용 권한을 관리할 때
  • S3 만의 권한을 관리할 때

Access Control List(ACL)

• 버킷 혹은 객체 단위로 읽기, 쓰기의 권한 부여
• S3에서 설정을 통해 ACL을 활성화 시킨 후에 적용 가능
• 파일 업로드시 설정 가능
• 간단하고 단순한 권한 관리만 가능
• 사용하지 않는 추세 ⇒ 버킷 괸리로 사용 가능함.

해당 포스팅은 AWS 강의실(https://www.youtube.com/@AWSClassroom)를 보고 공부한 내용을 정리한 블로그입니다.

아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁

네 자신의 불행을 생각하지 않게 되는 가장 좋은 방법은 일에 몰두하는 것이다.
Ludwig van Beethoven

S3 스토리지 클래스

• S3 다양한 스토리지 클래스 제공
  • 클래스 별로 저장의 목적, 예산에 따라 다른 저장 방법 적용
  • 8가지 클래스(S3 on OutPosts는 설명만)

s3 스탠다드

• 99.99% 가용성
• 99.999999999% 내구성(eleven-nine)
• 최소 3개 이상의 가용영역에 분산 보관
• 최소 보관기간 없음, 최소 보관 용량 없음
• 파일 요청 비용 없음(전송 요금은 발생)

s3 스탠다드 IA(Infrequently Accessed)

• 자주 사용되지 않는 데이터를 저렴한 가격에 보관
• 최소 3개 이상의 가용영역에 분산 보관
• 최소 저장용량: 128kb 최소 저장 기간: 30일
  • 작은 용량을 저장해도 128kb만큼의 비용발생, 1일만 저장해도 30일 보관만큼의 비용발생
• 데이터 요청 비용 발생: 데이터를 불러올 때마다 비용 지불
• 자주사용하지 않는 파일 중 중요한 파일

s3 one zone-IA

• 자주 사용되지 않는, 중요하지 않은 데이터를 저렴한 가격에 보관
• 단 한개의 가용영역에만 보관
• 최소 저장용량: 128kb 최소 저장 기간: 30일
  • 작은 용량을 저장해도 128kb만큼의 비용발생, 1일만 저장해도 30일 보관만큼의 비용발생
• 데이터 요청 비용 발생: 데이터를 불러올 때마다 비용 지불
• 자주사용하지 않는 파일 중 쉽게 복구할 수 있는 파일

s3 Glacier Instant Retrieval

• 아카이브용 저장소
• 최소 저장용량: 128kb 최소 저장 기간: 90일
• 바로 액세스 가능.
• 사용사례: 의료 이미지 혹은 뉴스 아카이브 등

s3 Glacier Flexible Retrieval

• 아카이브용 저장소
• 최소 저장용량: 40kb 최소 저장 기간: 90일
• 분~시간 단위 이후 액세스 가능
• 사용사례: 장애 복구용 데이터, 백업 데이터 등

s3 Glacier Deep Retrieval

• 아카이브용 저장소
• 최소 저장용량: 40kb 최소 저장 기간: 90일
• 데이터를 가져오는데 12~48시간 소요
• 사용사례: 오래된 로그 저장, 사용할 일이 거의 없지만 법적으로 보관해야하는 서류 등

s3 Intelligent-Tiering

• 머신러닝을 사용해 자동으로 클래스 변경
• 적절한 스토리지 클래스로 변경
• 퍼포먼스 손해/오버헤드 없이 요금 최적화

s3 on Outposts

• 온 프로메스 환경에 s3 제공
• 내구성을 확보한 상태로 파일을 저장하도록 설계
• IAM, S3 SDK 등 사용가능

해당 포스팅은 AWS 강의실(https://www.youtube.com/@AWSClassroom)를 보고 공부한 내용을 정리한 블로그입니다.

아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁

네 자신의 불행을 생각하지 않게 되는 가장 좋은 방법은 일에 몰두하는 것이다.
Ludwig van Beethoven

S3

Amazon Simple Storage Service(Amazon S3)는 업계 최고의 확장성과 데이터 가용성 및 보안과 성능을 제공하는 객체 스토리지 서비스입니다. 99.99%의 내구성을 제공하도록 설계되었으며, 전 세계 기업의 수백만 애플리케이션을 위한 데이터를 저장합니다.
-AWS-

Amazon S3

• 객체 스토리지 서비스: 파일 보관만 가능 ↔ Block Storage Service(EBS, EFS 등)
  • 어플리케이션 설치 불가능
• 글로벌 서비스. 단, 데이터는 리전에 저장
• 무제한 용량
  • 하나의 객체는 0byte에서 5TB의 용량

버킷

• S3의 저장공간을 구분하는 단위
• 디렉토리/폴더와 같은 개념
• 버킷이름은 전 세계에서 고유 값: 리전에 관계없이 중복된 이름이 존재할 수 없음.

S3객체의 구성

• Owner: 소유자
• Key: 파일의 이름
• Value: 파일의 데이터
  • 0byte의 데이터 → value가 없을 수도 있음
• Version Id: 파일의 버전 아이디
• Metadata: 파일의 정보를 담은 데이터
• ACL: 파일의 권한을 담은 데이터
• Torrents: 토렌트 공유를 위한 데이터

내구성

• 최소 3개 이상 가용영역(AZ)에 데이터를 분산 저장(Standard의 경우)
• 99.999999999% 내구성(eleven nine)
  • 0.000000001% 확률로 파일을 잃어버릴 수 있음
• 99.9% SLA 가용성(스토리지 클래스에 따라 다름)

보안 설정

• S3모든 버킷은 새로 생성시 기본적으로 Private(비공개)
  • 따로 설정을 통해 불특정 다수에게 공개 가능(ie 웹 호스팅)
• 보안 설정은 객체 단위와 버킷 단위로 구성
  • Bucket Policy: 버킷단위
  • ACL(Access Control List): 객체 단위
• MFA를 활용해 객체 삭제 방지 가능
• Versioning을 통해 파일 관리 가능
• 액세스 로그 생성 및 전송 가능
  • 다른 버킷 혹은 다른 계정으로 전송 가능

실습

1. S3 검색 후 대시보드 들어가서 버킷 생성

  1. 나머지 옵션은 그대로

2. 업로드 하는 메타 데이터(아무거나 하셔도 됩니다)

3. IAM 역할 선택

4. S3 권한 추가

  1. S3 검색 후 FullAccess 선택

  2. EC2에서 S3로 접근할 수 있도록 권한을 만들어줘야함.

EC2 생성