[0608] TIL 42일차

nikevapormax·2022년 6월 8일
TIL

TIL

목록 보기
42/116

😂 AWS 2주차

😭 프론트와 백앤드 구분

  • 처음에는 다 Monolithic으로 시작하였지만, 서비스의 규모가 커저감에 따라 한 부분의 오류가 전체의 오류가 될 수 있기 때문에 MSA로 변경하는 흐름을 보인다.
  • MSA가 통신의 속도 또한 더 빠르다.
  • 현재 우리가 공부하는 AWS도 처음에는 Monolithic이었다.
  • AWS는 아마존이 사용하던 인프라를 그대로 서비스로 만들어 놓은 것이며, 이는 점점 분산 서비스 플랫폼으로 변경되었다. 따라서 현재 아마존의 첫 페이지를 구성하기 위해 1000개의 서비스를 호출하고 있다.
  • AWS는 현재 분산 서비스를 만들며 클라우드 서비스를 제공한다.

😭 CloudFront 구성

- CDN

  • Content Delivery Network Service
  • 지리적으로 분산된 여러 개의 서버
  • 웹 콘텐츠를 사용자와 가까운 곳에서 전송함으로써 전송 속도를 높인다.
  • 전 세계 데이터센터는 파일 복사본을 임시로 저장하는 프로세스인 캐싱을 사용하며, 사용자는 가까운 서버를 통해 웹 활성화 디바이스 또는 브라우저에서 인터넷 콘텐츠에 빠르게 접속할 수 있다.
  • 보안을 강화해 DDoS(Distributed Denial-of-Service) 공격과 같은 보안 문제와 악의적 공격자를 차단하는 기능을 웹사이트에 제공할 수 있다.

- CloudFront

  • AWS에서 제공하는 CDN

  • 정적 파일들을 글로벌하게 캐싱해준다.

  • AWS 공홈 CloudFront

  • 진행 흐름

    • 사용자가 자신의 S3 Bucket에 정적 파일을 업로드한다.
    • Amazon CloudFront에서 해당 파일을 올리면 자동적으로 각 Edge Location들로 캐싱해서 올려준다.
      • 아마존은 region과 zone이 세계적으로 퍼져있기 때문에 가능한 일!
    • 이로 인해 다른 나라에서도 사용자들이 본인들 근처의 region을 통해 접속하고, 각 Edge Location들로 인해 접속하는 속도가 느리지 않게 된다.

  • 사용자는 자신의 S3 Bucket과 Amazon CloudFront을 연결하기만 하면 된다.

  • CloudFront 생성

    • 우선은 원본 도메인만 맞추며, 해당 도메인은 나의 s3 bucket과 연결한 것이다. (클릭하면 자동생성되어 선택하면 됨)

  • 하단의 배포 생성 버튼 클릭

  • 다시 클라우드프론트 페이지로 돌아오면 다음과 같은 페이지가 생성되어 있다.

    • ID : CloudFront의 유니크한 아이디
    • 도메인 이름 : 해당 도메인 이름을 사용해야 CloudFront에 접속할 수 있다.

  • 이제 도메인 이름을 입력해 접속해보도록 하겠다.

  • 역시나 거절당했다. 왜냐하면 우리가 아까 설정에서 도메인만 입력했기 때문이다. 설정을 변경하도록 하겠다.

  • 클라우드프론트 페이지에 있는 ID를 클릭한다. 그러면 편집을 눌러 설정을 변경할 수 있다.

  • 다시 웹사이트에 들어가 새로고침을 해보면 잘 실행되는 것을 볼 수 있다.

😭 GIT 배포

- GitHub Action

  • Github에서 제공하는 배포 서비스
  • GitHub Action 공홈
  • 기존의 소스저장소의 기능에서 DevOps플랫폼으로 발전
    • DevOps
      • development(개발)와 operations(운영)가 합쳐진 단어
      • 신속한 고품질 서비스 제공을 통해 비즈니스 가치와 대응력을 향상시키기 위한 기업 문화, 자동화, 플랫폼 설계에 대한 접근 방식
      • 레거시 애플리케이션과 최신 클라우드 네이티브 애플리케이션 및 인프라를 연결하는 것을 의미
      • DevOps 참고링크
  • 아키텍처의 변화로 작아진 어플리케이션들을 부담없이 자주 배포하기 위해서 CI/CD의 통합(소스저장소와 배포시스템을 통합)

- GitHub Action 자동 배포만들기

  • 먼저 CloudFront에 대한 권한을 추가한다.

    • IAM 메뉴로 들어간다.
    • (좌측)엑세스관리 - 사용자 - 사용자 이름을 누르게 되면 나의 권한을 볼 수 있다.
    • 현재 나의 권한은 s3 bucket만 부여되어 있다.
    • 따라서 CloudFront에 대한 권한을 추가하도록 하겠다.
    • 위의 과정을 마무리하게 되면 다음과 같이 권한이 부여된 것을 볼 수 있다.

  • 권한을 부여하였으니, GitHub Action을 사용하기 위해 repository를 생성하도록 하겠다.

  • 위의 SSH를 복사해 pyCharm과 연동하도록 하겠다.

    • 아래의 VCS에서 받기 버튼 클릭
    • 아까 복사했던 SSH를 URL에 입력하고, 복제 클릭
    • 연동 끝(이것도 신기한 방법,,, 별게 다 있단걸 느낌)
      • 추가적으로 위의 빨간 박스에 있는 버튼을 통해 커밋 푸시 다 가능함
    • 계정을 연결해보도록 하겠다.
      • 아래 메뉴로 들어와 계정 추가 클릭
    • GitHub를 통해 로그인 선택
    • 웹사이트로 자동연결되며 이제 차례대로 연동해주면 된다.
      • 하란대로만 하면 아래와 같이 연동 성공

  • 이제 깃에 커밋을 진행해보도록 하겠다.

    • 아까 레포를 파면서 리드미를 만들었어야 했는데 원래 습관처럼 하지 않아서 내가 수기로 만들어 주었다.
    • 아래에 써놓은 순서대로 진행하면 된다.
      • 처음에 맨 위의 커밋 아이콘을 클릭하면 아래의 창으로 들어와진다.
      • 그리고 올리고 싶은 파일을 선택한다.
      • 커밋 메세지를 써주고
      • 커밋 및 푸시를 눌러준다. 물론 커밋만 한다고 죽는거는 아니다. 그런데 커밋만 누르게 되면 다시 푸시 버튼을 눌러줘야 하므로 한 번에 끝내는 방향으로 진행한다.

  • GitHub으로 가 내용이 잘 올라왔는지 확인한다.

    • 리드미에 내용이 잘 반영된 것을 볼 수 있다.

  • GitHub Action에서 사용방법 찾아보기

  • 이제 배포에 필요한 파일들을 깃헙에 올리도록 하겠다.

    • index.html
    • ./github/workflows/main.yml

  • 다음과 같은 폴더 구조를 갖게 된다.

  • 아까와 같이 커밋 & 푸시 진행

  • GitHub 체크

  • 상단의 Actions 탭 클릭

    • 아까와 달리 무언가가 진행되고 있는 것을 알 수 있다.

  • git action file 추가를 눌러보면 다음과 같은 내용을 확인할 수 있다. 현재는 에러가 나 있는 상태이다.

  • main.yml 파일을 보면 아래 표시된 부분에 들어가는 내용은 세팅이 되어 있어야 한다. 하지만 우리는 세팅이 되지 않은 상태라 에러가 나는 것!

  • 이 내용을 세팅하러 GitHub - Settings - Secrets로 이동한다.

  • New Repository secret 클릭

  • 아까 변수로 선언되어 있던 비밀키들의 값을 이렇게 하나씩 넣어주면 됨

    • AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY는 어제 저장해놓았던 키
    • BUCKET_NAME이랑 DISTRIBUTION_ID는 aws에서 확인 가능!

  • 다 추가하고 아래로 스크롤을 내려보면 잘 저장된 것을 확인할 수 있다.

  • 다시 배포를 진행한다.

    • 배포를 해야 하므로 엔터라도 쳐서 커밋을 진행했다.

  • Actions로 가서 초록불이 들어온 것을 확인하고 기뻐한다.

  • 이렇게 하고 다시 클라우드 프론트 url에 들어가 본다.

  • 잘 되긴 하는데, 이게 진짜 돌아가고 있는지 맞나라는 의심이 드므로 글자를 바꿔보도록 하겠다.

    • 글자를 변경하고 다시 깃에 올리는 것이므로, 다시 actions에 가서 초록색을 확인한다.
    • 그리고 다시 웹페이지에 가서 새로고침을 하는 순간 성공이 보인다.

😭 네트워크

- VPC

  • Virtual Private Cloud
  • VPN, VPC
  • Amazon VPC
  • VPC를 적용하면 VPC별로 네트워크를 구성할 수 있고 각각의 VPC에따라 다르게 네트워크 설정을 줄 수 있다. 또한 각각의 VPC는 완전히 독립된 네트워크처럼 작동하게 된다.

- Amazon VPC

  • 서치바에 VPC를 입력하고 다음 메뉴에 들어가면 아래 화면이 나온다.
    • IPv4 CIDR : VPC에서 내부적으로 사용되는 IP (IP의 범위를 지정하는 방법)
  • subnet
    • 하나의 VPC에 4개의 subnet이 연결된 것을 볼 수 있음(위에서 만든 VPC ID가 적혀있음)
    • CIDR를 보면 VPC의 CIDR 안에서 대역폭이 나누어진 것을 볼 수 있음
  • 라우팅 테이블
    • VPC에 적혀있는 IPv4 CIDR가 local로 잡혀있는 것을 볼 수 있음
    • 라우팅 테이블을 통해 연결하고 싶은 subnet의 구성을 정할 수 있음
    • 내가 어떤 것을 연결하고 싶은지 정할 수 있는 기능이라 생각
    • 대상에 적혀있는 igw-0efe7aaf755727807는 인터넷 게이트웨이

  • 인터넷 게이트웨이
    • 아래의 VPC ID와 해당 인터넷 게이트웨이가 연결되어 있음을 알 수 있고, 이를 통해 외부와 통신을 할 수 있다.

- 보안그룹

  • 방화벽의 개념과 비슷하다.

  • 예를 들어, ec2에 들어올 수 있는, 즉 인바운드에 대한 규칙을 설정하는 곳이다. 몇 번 포트로만 들어올 수 있도록 하는 등의 보안을 설정한다.

  • 아래의 메뉴를 통해 보안그룹에 들어갈 수 있다.

  • 인바운드 및 아웃바운드 규칙

  • 인바운드 규칙의 보안그룹 ID가 소스에 그대로 있는 것을 볼 수 있다. 즉, 해당 ID는 보안에 막히지 않는다는 뜻이다.

  • 인바운드 및 아웃바운드 규칙 편집을 통해 변경이 가능하다.

- 탄력적 IP

  • 리소스에 IP를 고정하는 것
  • 방금 ec2를 하나 생성하였다.
  • 이러고 해당 ec2를 인스턴스 실행 중지를 한 후, 다시 실행하게 되면 빨간 네모가 쳐져있는 퍼블릭 IPv4 주소가 변경된다.
  • 그런데 이렇게 어떠한 상황때문에 인스턴스를 껐다 켜야될 수 있는데, 서비스를 계속 진행하는 과정에서 이러면 문제가 생길 수 있다.
  • 이럴 때 사용하는게 탄력적 IP이다.
  • 아래 메뉴에 들어가 한 번 세팅해보자.
    • 탄력적 IP 주소 할당 클릭
    • 아래와 같이 세팅한 후 하단의 할당 클릭
    • 탄력적 IP 주소가 생성됨
      - 아래의 할당된 주소 클릭
    • 우상단 탄력적 IP 주소 연결 클릭
    • 현재 우리가 돌리고 있는 인스턴스를 선택해주기
    • 퍼블릭 IPv4 주소에 3.36.62.133이 아닌 우리가 방금 만들었던 탄력적 IP 주소가 들어가 있는 것을 볼 수 있다.
  • 이제 아무리 인스턴스를 껐다 켜도 IP 주소가 바뀌지 않는 것을 볼 수 있을 것이다.
profile
nikevapormax
https://github.com/nikevapormax
이전 포스트

[0607] TIL 41일차

다음 포스트

[0609] TIL 43일차

0개의 댓글