TIL 21.10.02 AWS

☁️ AWS

✏️ 기본 개념

AWS 사용

AWS는 내가 필요로 하는 사이즈에 맞게 필요한 부분을 찾아서 공부하고 사용하면 된다. AWS 안에도 방대한 상품들로 구성되어 있어 모든 것을 찾아서 공부하기 보다는 공용으로 자주 사용하는 기능이나 자신의 상황과 비슷한 회사의 reference를 참고하여 벤치마킹 및 상황에 맞게 구성하면 된다. 대용량 트래픽을 발생시키는 NETFLIX, 쿠팡, 배민을 참고하는 것이 그 예다.

AWS S3

AWS를 사용하는 이유는 여러가지 이유가 있지만 개발과 연동되어 배포를 빠르게 할 수 있다는 장점이 있다. Simple Storage Service 인 S3에 대해 알아보자.

terminal 설정

AWS를 terminal 환경으로 조작할 수 있다. 버킷관련해서 계정을 관리 및 운영해주는 기능인 IAM이 있는데 해당 탭에 가서 자신에게 필요한 서비스를 클릭할 시 처음에 부여되는 액세스 key와 비밀 액세스 키가 있다. 해당 값을 복사하여 local 컴퓨터에 저장해 놓아야지 후에 terminal 환경에서 access 했을 때 명령어로 aws 조작이 가능하다. 아래의 명령어는 하나의 예시이다.

aws s3 cp {파일명} s3://{버킷이름} --acl public-read

—acl 파일의 권한변경을 option으로 사용할 수 있다. 위 명령어는 특정 파일을 aws에 생성한 버켓에 퍼블릭 읽기 권한으로 업로드 하는 명령어이다.

버킷

버킷은 폴더와 유사하다. 버킷에 필요한 파일을 업로드해서 클라우드 서버에 저장할 수 있다. 여러개의 버킷을 만들어 나만 접근할 수 있는 Private bucket과 모두가 접근할 수 있는 Publick bucket을 만들어 관리 할 수도 있고 하나의 버킷에서 두가지 버전을 만들어 관리할 수도 있다.

객체 URL

파일을 올리면 객체 URL이 생긴다. 브라우저의 주소 창에 복사해서 넣으면 해당 객체의 URL에 담긴 내용이 브라우저에 표시된다. 표시가 되기 위해선 해당 객체에 대한 권한 설정을 해주어야한다. 사용자만 권한, 사용자가 지정한 구성원으로서의 권한, 공용 권한이 있으며 그 안에 읽기 및 실행으로 구성된다.

객체 URL과 관련해서 Acces denied라는 문구를 웹페이지에서 마주하게 됐을 때 권한문제로 간주하고 관련 객체에 들어가서 권한 설정을 변경해주면 된다.

웹호스팅 기능

웹 호스팅을 설정해주면 AWS에 내가 올린 파일을 권한이 있는 사용자 누구에게 access 할 수 있게 해준다.

Monolithic

한대의 서버에 하나의 저장소를 만들어서 모든 것을 관리하는 아키텍쳐이다. 프론트 부분과 백엔드 부분이 물리적으로 하나의 공간에 위치한다. 초창기 빠르게 개발을 진행했을 때 위의 아키텍처를 본의 아니게 구축하게 된다. 그렇게 몸집이 커지게 되면 한 부분의 수정으로 인해 전반적으로 영향을 미치는 결과를 초래하게되어 잘게 나눌 필요성을 느끼게 되고 MSA 사용하게 된다.

MSA

프론트 부분과 백엔드 부분을 물리적으로 나누어서 관리하는 것에 포인트가 있다. AWS의 사상 자체가 레고처럼 조립하는 식으로 리소스를 관리하는 것을 지향한다. 초창기 2001년 AWS가 2 tier 기반(data, application)에서 시작해서 현재 100개가 넘는 서비스를 제공하고 있다. 이런 부분이 개발 아키텍처에 영향을 미치게 되고 개발과 인프라가 같이 진행되고 있다. 위와 같이 잘게 쪼개질 수 있게 된 영향으로 https의 통신이 빨라지는 것이 한몫 한다.

결론적으로 최대한 잘게 쪼개서 아키텍처를 구성했을 때 가져가는 이점이 있다.

CDN

Contents Delivery Network 의 줄임말. 업로드한 리소스를 캐싱해주는 서비스이다. 캐싱을 하는 이유는 다른 나라의 리전에서 내가 올린 도메인에 접속했을 때 내가 속한 리전에서 접속했을 때의 서비스 환경과 비슷한 환경으로 구성해 주기 위해 위해 해당 서비스를 사용한다. AWS에선 CloudFront라는 이름으로 서비스를 제공한다. 캐싱 서버에 내가 리전에 올린 리소스를 올림으로써 CDN 서비스를 제공해준다.

전세계적으로 서비스를 하고 싶은데 AWS의 CloudFront 서비스를 이용할 수 없다고 하면 다른 서비스인 아카마이나 CDN Network Service를 쓰거나 S3를 리전마다 만들어야 한다.

예시

CloudFront 서비스를 사용하면 edge location에 내가 S3에 올린 파일이 캐싱된다. AWS가 해당 서비스를 할 수 있는 이유는 리전이 많고 그 곳에 캐싱서버가 많기 때문이다. 그래서 미국에서 사이트에 접속시 가장 가까운 캐싱서버로 접속이 된다.

Netflix가 전국적으로 서비스를 할 수 있는 부분이 단순히 CloudFront 서비스에 국한되는 것은 아니겠지만 여러나라의 리전에서 캐싱 서버를 사용한다는 것이다.

CloudFront 실습

CloudFront 서비스에서 새 배포를 만들게 되면 Domain Name이 생성이 된다. 정적 호스팅 기능을 사용하여 생성된 링크 뿐만 아니라 이제 해당 Domain Name으로도 서비스에 접속할 수 있다. 또 한가지 좋은 점은 S3 도메인으로 접속하게 될 경우 내가 요청 횟수에 비례하여 과금이 되는데 해당 서비스의 도메인으로 접속하게 될 경우 과금이 되지 않는다.

처음 CludFront를 설정해서 만들어 줄 경우 Default Root Object를 설정해주지 않을 경우 Access Denied가 뜨므로 Default Root Object에 웹페이지에 표시해 줄 파일명을 기입해주어야 한다.

CI/CD

Continuous Integration
지속적으로 소스를 원격저장소에 업데이트 시켜준다.

Continuous Delivery
원격저장소에 저장해 놓은 리소스들을 AWS와 같은 서비스에 지속적으로 전달해서 배포를 가능하게 한다. 요즘은 원격저장소에 push하자마자 인프라에도 반영이된다.

배포 주기를 짧게 가져감으로써 인프라에서 생기는 문제를 빠르게 대처하여 배포와 배포 사이의 텀을 줄이는 것이 요즘 상황이다.

✏️ 파이참 깃 Cloud Front 삼자연동

GitHub Action

AWS와 같은 서비스에 연동시켜 주면 자신의 local 환경에서 변경한 소스를 원격저장소에 올림(CI)과 동시에 자동으로 배포해주는 기능을 사용할 수 있다. .github/workflows/main.yml 파일을 통해 설정해주어야 한다.

AWS 버킷에 사용하는 서비스 권한 설정

먼저 계정관리를 하는 IAM 탭으로 들어가 CloudFront 서비스 권한을 기존 버켓에 추가시켜준다. 아래 그림을 보면 S3 FullAccess 말고도 CloudFront를 추가해 줌으로써 현재 해당 버켓이 두가지 서비스에 접근가능하도록 권한을 추가해 준 것을 볼 수 있다.

파이참과 깃 연동시키기

깃허브에 원격저장소를 하나 만들고 해당 깃주소를 복사한다. 파이참을 열면 Get for version control이 있는데 클릭해서 깃 주소를 기입하여 okay를 누른다. Pycharm preference 에 가서 Github 탭을 누르고 Login-via-Github를 누르면 파이참과 깃을 연동시킨 것이다. 이후 오른쪽 탭에서 commit 버튼 및 푸시버튼을 눌러서 해당 기능을 사용하면 된다.

파이참과 GitActions 연동시키기

Github Settings에 들어가서 몇가지 사항을 추가시켜 주어야 한다. 그 전에 먼저 .github/workflows/main.yml 파일을 만들어 준 후 아래 내용을 붙여 넣어서 세팅을 시켜주어야 한다. 아래 코드에 대한 이해보다는 기입해야 할 사항에 대해서 알아보면 name에 자신이 만든 프로젝트에대한 이름을 기입한다. branches에는 자신이 깃헙의 어떤 브랜치에 올렸는지 브랜치 이름을 적어준다.

name: my-front
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      AWS_REGION: 'ap-northeast-2'

    steps:
      - name: Checkout source code.
        uses: actions/checkout@master

      - name: Upload binary to S3 bucket
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --acl public-read --exclude '*' --include 'index.html'
        env:
          AWS_S3_BUCKET: ${{ secrets.BUCKET_NAME }}

      - name: Invalidate cache CloudFront
        uses: chetan/invalidate-cloudfront-action@master
        env:
          DISTRIBUTION: ${{ secrets.DISTRIBUTION_ID }}
          PATHS: '/index.html'
        continue-on-error: true

Github Setting 하기

그 다음으로는 Github에 Settings 부분으로 가서 자신이 처음 버킷을 만들었을 때 부여된 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY, 버킷이름 Cloud Front ID를 넣어주어야 한다. 다음과 같이 관리 되는 이유는 코드에 키 아이디와 비밀번호를 직접적으로 넣을 경우 문제가 발생하기 때문이다.
아래 그림과 같이 설정이 마무리된 후 파이참에서 push를 할 경우 CloudFront 도메인에서 변경된 사항이 반영이 되어야 정상적으로 세팅을 했다고 볼 수 있다.

결과 확인하기

파이참에서 push를 해서 Cloud Front 도메인으로 접속시 변경사항이 적용된 것을 확인해서 변경이 됐다면 위 연동시스템이 구축되었다는 것을 볼 수 있다.