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 도메인으로 접속시 변경사항이 적용된 것을 확인해서 변경이 됐다면 위 연동시스템이 구축되었다는 것을 볼 수 있다.

✏️ 학습목표

앞 선 시간에는 front 관련 파일을 AWS와 연동시키는 방법에 대해서 알아보았다. 이번시간에는 Backend 관련 파일을 AWS와 연동시키는 방법에 대해서 알아보고자 한다. 연동시키기에 앞서 네트워크 관련 개념을 숙지하면 해당 작업에 도움이 되어 네트워크 개념에 대해서 다루어보도록 하자.

🌐 네트워크

VPC (Virtual Private Cloud)

AWS가 만들어놓은 물리적인 서버 환경 위 클라우드 네트워크 공간에서 서비스 사용자가 공간을 구획하여 인터넷 연결의 유무를 설정해주는 AWS의 서비스이다. AWS 계정 생성시 외부 인터넷과 연결될 수 있는 default VPC가 생성이 된다.

VPC ID 클릭시 아래와 같은 화면이 뜨는데 이 중에서 살펴보아야 할 부분은 IPv4 CIDR이라는 부분이다.

IPV4 CIDR은 IP의 범위를 지정하는 방법입인데 예를 들어 172.32.0.0/16 이라고 하면 IP의 범위가 172.32.0.0 ~ 172.32.255.255 지정되게 된다.

VPC 에서 외부적으로 사용하는 IP 번호이고 앞으로 사용할 EC2 서비스 사용시 해당 IP 대역을 사용하게 된다. 즉 AWS의 VPC가 외부 인터넷 환경과의 소통에 필요한 창구의 대역대인 것이다.

위의 그림처럼 VPC는 외부 인터넷과 연결하는 VPC1과 내부에서 통신할 수 있는 VPC2로 구성할 수 있다.

서브넷

연결되는 서버 컴퓨팅 자원들에 내부 IP를 할당하는 것, 하나의 VPC에는 4개의 서브넷이 default로 할당되어 있다.

라우팅 테이블

어떤 서브넷을 연결하지 그리고 연결하지 말지를 라우팅 테이블에서 적용한다.

인터넷 게이트웨이 ID

외부 인터넷과 VPC를 연결하는 부분. 연결이 되어야지만 VPC가 외부 인터넷과 소통할 수 있다.

보안그룹

트래픽의 입출을 관리하는 인스턴스에 대한 방화벽 역할을 한다. S3와 Cloud Front는 포트를 조절 할 일이 없지만 EC2와 같은 백엔드 서비스를 사용하게 될시 특정 포트를 관리해주어야 하기 때문에 보안그룹을 사용한다.

• 인바운드 규칙
  인바운드 규칙은 클라이언트가 자신의 서버 데이터에 들어올 수 있는 규칙을 의미한다. 서버에 접속하고, 해당 데이터들을 읽을 수 있으며 권한 여부에 따라서 생성, 수정, 삭제도 허용하는 규칙이다. 기본적으로 인바운드 규칙은 모든 포트를 닫는 것으로 한다.

• 아웃바운드 규칙
  아웃바운드 규칙은 서버에서 나갈 수 있는 (반출할 수 있는) 데이터에 대한 규칙을 의미한다. 인바운드 규칙에서 허용된 포트로 들어왔다고 한들, 아웃바운드 규칙에서 데이터 반출이 허용되지 않은 포트라면 클라이언트는 "다운로드"를 할 수 없게 된다. 보통 아웃바운드 규칙은 기본 옵션으로 모든 포트에게 허용되어 있는 편이다.

탄력적 IP

고정 IP 입니다. 고정적인 IP가 필요할 때 사용합니다. 고정 IP를 사용하는 이유 EC2를 예로 들면 해당 인스턴스를 중지하고 다시 시작 할 경우 퍼블릭 IPv4의 주소가 변경되는 것을 확인할 수 있다. 이렇게 변경되는 IP가 싫을 경우 탄력적 IP사용을 통해 IP를 고정시킨다.

✏️ 백엔드 구성해보기

이번 시간에는 EC2를 통해서 서버를 돌려보도록 하자.

✏️ ELB (Elastic Load Balancer)

이번 시간에는 EC2 + ELB 를 구축해서 보다 안정적인 구조를 구축해보도록 하자. 가장 기초적인 형태는 EC2에 Elastic Load Balance를 연결하는 형태를 알아보도록 하자.

로드 발란서를 사용하는 이유는 트래픽이 증가 할 경우 EC2를 추가하는 것도 있고 특정 서버가 응답하지 않을 경우 그 서버로 요청을 보내지 않고 남은 서버에 요청을 보내기 위함도 있다.
Load Balancer가 EC2에 잘 연결이 됐을 경우 해당 DNS를 주소창에 입력 할 경우 EC2에서 표시되는 화면과 동일한 호면이 뜬다.

Image

Load Balancer 에서 자동으로 EC2가 추가될 경우 기존 EC2에 있던 파일들이 자동으로 새로 생긴 EC2에 추가될 수 있도록 만든 기능