프론트엔드 개발자도 알면 좋은 지식 Infra

2023. 5. 18. 16:46ㆍ프론트엔드

서버와 클라우드 컴퓨팅 그리고 AWS

서버

  1. 무언가를 제공해주는 사람이나 물건
  2. it 업계 : 무언가를 제공해 주는 컴퓨터.

서버는 물리적인 실체가 있는 컴퓨터이다. 컴퓨터는 하드웨어이고, 각각 구성품에 사양을 가지고 있음. 서버가 받아들일 수 없는 성능을 요구하게 되면 서버가 터지게 된다.

서버를 운영하는 방법

온프레미스 (On-promise)

  • 서버에 필요한 물리적인 공간, 컴퓨터, 제반시설등을 직접 구축해서 활용함
  • 전통적인 방식, 직접 모니터링
  • 전문인력들이 직접 하드웨어를 구입하고 제반시설을 구축해야 한다.
  • ⚠️why! 급변하는 소프트웨어에 맞춰서 유지보수하기 어렵다는 단점으로 인해 많은 기업들이 현재는 온 프로미스 방식을 벗어나서 클라우드 컴퓨팅 기반의 환경으로 변경하고 있음.

클라우드 컴퓨팅 (cloud computing)

  • 인터넷을 이용한 클라우드 서비스를 통해서 사용하는 것을 의미함.
  • 클라우드 서비스 프로바이더를 원하는 사양을 원하는 시간만큼 대여해서 사용할 수 있음.
    • 탄력적인 대여가 가능하다.
  • 전세계에 걸쳐 서버를 운영할 수 있는 인프라를 구축해두고 물리적인 컴퓨터를 관리하고 있음.
  • 클라우드 컴퓨팅의 사용자 입장에서는 물리적인 관리에 대한 필요성이 사라지며 훨씬 더 안정적인 환경을 제공받을 수 있기에 관리상에 이점이 있음.

클라우드 컴퓨팅의 종류

클라우드 컴퓨팅은 제공하는 서비스의 수준에 따라서 3개의 계층으로 구분지을 수 있음

  1. IaaS(Infrastructure as a Service)
    • 인프라를 구축하기 위해 필요한 컴퓨터를 대여해주는 것을 의미함.
    • 대여 받은 컴퓨터의 대부분의 리소스에 접근해서 서비스를 구성하고 관리 할 수 있으므로 가장 많은 제어권을 가지고 있음
    • 내가 가장 많은 부분을 일일이 구성하고 관리해줘야 한다.

ex) AWS EC2

  1. PaaS(Platform as a Service)
    • Paas는 IaaS와 더블아 SW를 개발하고 운영하기 위해 필요한 구성 요소들을 플랫폼화 해서 제공해주는 서비스
    • SW운영에 대한 관리 를 PaaS에 위임 할 수 있어서 효율적인 개발이 가능
    • 플랫폼의 형태로 제공된다는 점으로 인해 특정 플랫폼에 종속적이 될 수 있다.
    • 해당 플랫폼에서 접근을 허용하지 않는 부분은 제어할 수 없다.

ex) AWS Elasctic BeanStalk, Heroku, Github Pages

  1. SaaS(Software as a Service)
    • 클라우드 서비스에 더불어, 고객이 이를 사용할 수 있는 소프트웨어가 함께 제공되는 형태
    • 명시적으로 app을 PC에 설치할 필요가 없으며 서비스를 활용하기 위해 만들어진 sw가 함께 제공 되기때문에 편리하게 이용 가능

ex) Netflix, DropBox, iCloud, Google Apps

AWS

  • 클라우드 컴퓨팅 서비스를 제공하는 프로바이더 중 하나
  • 전세계에서 가장 많이 사용되고 있는 클라우드 컴퓨팅 서비스
  • 수많은 서비스를 확장성, 안정성, 높은 보안수준과 함께 제공해줌.

AWS S3 : AWS Simple Storage Service

  • 특정한 파일을 저장하고, 인터넷상으로 접근할 수 있게 해주는 서비스
  • 웹서비스에 필요한 정적 파일을 저장할 때 사용
    • cra ⇒ create react app → spa ⇒ single page application → csr ⇒ client side rendering
    … CRA로 만들어진 React App은 정적 파일이다. : 정적인 파일이기 때문에 호스팅 가능… Next로 만들어진 React App은 동적 파일이다. : S3에 호스팅 절대 불가
  • build를 하면 정적 파일이 생긴다. 정적 파일 을 호스팅 서버에 올리면 베포가 끝나는 것

버킷 정책 설명

{
    "Version": "2012-10-17", // iam 정책 날짜 (이게 최신 버전)
    "Statement": [
        {
						// 정책 id의 unique한 값
            "Sid": "PublicReadGetObject",
						// effect 설정
            "Effect": "Allow", 
            "Principal": "*", // 누구한테 적용할 지
            "Action": "s3:GetObject", // 행동 이름
						// 이 버킷 파일에 대해서 접근 허용 여부
            "Resource": "arn:aws:s3:::<bucket-name>/*"
	          // "Resource": "arn:aws:s3:::<bucket-name>/index.html" 
        }
    ]
}

😒 http 401 vs 403

CI/CD with Github Actions

⚠️ 배포는 했는데 계속 S3에 업로드 하기가 너어무 귀찮아요!! ㅠㅠ 이거 자동화로 바꿀 수 있지 않을까요?

cl/cd : contiuous integration / continuous Delivery/Deployment

  • 개발 과정에서 필요한 빌드, 테스트, 베포등의 과정을 자동화 합니다.
  • CI/CD 자동화를 통해서 개발자들은 코드를 자동으로 테스트하고 배포할 수 있다.
  • 이를 통해 효율적인 작업과 더 빠르고 더 자주 배포를 진행할 수 있다.

CI

Continuous Integration 은 코드를 지속적으로 통합해나가는것 하지만…

  • 일반적인 통합 : Github 의 PR을 통해서 진행

→ 여기서 말하는 통합은 코드를 합치는 것뿐만이 아니라 코드를 테스트 하고 유효한지 검사하는 확인을 포함함. ( : merge 후에 제대로 돌아갈까..? )

  • 테스트 코드를 짜두고, 코드가 유효한지 검사하고 문제가 발생했을 경우 즉각적으로 피드백을 받을 수 있어서 확인하고 수정할 수 있게 만들어줌.

CD

Continuous Delivery/Deployment 은 통합된 코드를 실제 사용자가 사용하고 있는 Production 환경에 배포하는 것을 의미함.

→ 이 일련의 과정을 처리하는 CI/CD 파이프라인을 구축을 일일히 하긴 힘들다.

CI/CD 플렛폼의 종류

CI/CD 파이프라인을 구축함으로써 자동화 함 → CI/CD 파이프라인이 구축되어 있는 플랫폼 사용

  • 설치형 : 하나의 프로그램으로 설계해두면 이를 실행할 컴퓨터가 필요함, 설치형은 파이프 라인을 구축하는 개발자가 직접 특정 컴퓨터에 CI/CD 플랫폼을 설치해서 활용하는 방법
  • Jenkins
  • 클라우드형 : 서비스 제공자가 클라우드에서 모두 운영해주는 형태, 플렛폼에서 제공해주는 수준까지만 할 수 있기에 세부적인 조정이 불가능 하다는 단점
  • github actions

⚠️왜 많이 쓸까 이걸?

  • 어느정도 규모가 있는 개발팀의 경우에는 CI/CD를 구축하는 것이 보편적이다. 사실 CI/CD는 장점만 있는것은 아니다. CI/CD를 구축하고 운영하기 위해서는 구축/관리 를 위한 노력이 필요하며 플랫폼이나 서버를 구축해서 진행해야한다.
  • 소프트웨어는 하드웨어에 비해 상대적으로 변경하기가 쉽다. 기업에서는 항상 유저의 피드백을 통해서 프로적트를 더 좋은 방향으로, 더 빨리, 더 자주 개선하고자 함.
  • 이런 상황에서 개발자가 직접 수동으로 배포를 하 는 과정에서 리소스를 쏟기 보다 프로덕트의 개발 및 개선 과정에 더 많은 리소스를 투입하는 것이 효율적이라고 판단
  • 개발자의 몸값이 비싸기 때문에, 하드웨어의 사양을 증대시키거나, 필요한 PaaS서비스들을 활용해 개발자들의 핵심 가지를 창출하는데 집중시키는 방향으로 산업이 발전하고 있음.
  • CI/CD는 이러한 상황에 맞춰서 그 효율이 입증되어서 각광 받고 있는 것

Github Actions

Github 에서 제공하는 클라우드형 CI/CD 툴

Github 레파지토리와의 연동이 쉽고, 레파지토리 안에서 CI/CD까지 함께 구축하고 관리할 수 있다.

1. GitHub Actions 의 구성요소들

  1. Workflow
    1. YAML 형식 파일을 통해서 Workflow를 설정할 수 있음
    2. 이벤트나 예약된 스케줄에 의해 실행될 수 있으며, 수동으로 실행도 가능
  2. Event
    1. 레파지토리에서 발생하는 push, pr open, issue open
    2. 특정한 event 발생 시 그에 맞는 CI/CD 파이프라인을 구동시킬 수 있음
  3. Jobs
    1. 하나의 runner에서 실행될 여러 step의 모음을 의미
    2. step → 실행가능한 shell script또는 action을 의미
    3. jobs안의 step들은 순차적으로 실행됨
    4. workflow의 job들은 기본적으로 병렬로 실행
    5. 일부 job의 경우에는 다른 job에 의존성을 설정해서 동기적으로 실행가능
  4. Actions
    1. github workflow에서 자주 사용되는 기능들을 모아둔 일종의 커스텀 애플리케이션
    2. 설정파일에서 use키워드와 함께 사용 가능
    3. Github Marketplace에서 Action들을 검색하고 활용가능 ( 라이브러리 )
  5. Runner
    1. workflow를 실행할 서버를 의미
    2. 클라우드 형 CI/CD 플랫폼 → Runner를 통해서 Workflow를 실행시켜줌
    3. Github Actions → node가 기본으로 깔려 있음

2. CI/CD로 구축할 목표

정적웹사이트들은 S3를 통해서 호스팅 할 수 있다. 매번 실행되는 중복 작업 들이 있을 것

CRA dependencies 설치, build script 실행, AWS S3 버킷에 기존의 자료 삭제, 새로운 파일 업로드

CI/CD 파이프라인 구축 일련의 예시 과정

  1. 마스터 브랜치에 push or Pull Request Merge가 발생하면 workflow를 실행한다.
  2. 필요한 dependencies들을 설치한다.
  3. build script를 실행합니다.
  4. aws에 접속한 후 s3 bucket에 build한 결과물을 업로드합니다.aws s3 → 보안 자격 증명 → accessKey 발급 ( ID, PW ) → 스크립트에 계정 설정
  5. → AWS S3에 대한 명령어를 사용 가능
  6. **자동화를 위해 4번 과정을 스크립트로 작성할 수 있는 과정이 필요 !!**

모든 자동화는 기능을 스크립트화 시켜주는것이 시작이다!!!

CI/CD.yml 예시 파일

name: CI/CD

on:
  push:
    branches:
    - master
  workflow_dispatch:

jobs:
  cicd:
    runs-on: ubuntu-latest
    steps:
		// 항상  checkout 해야 브랜치의 내용을 읽을 수 있다.
    - uses: actions/checkout@master 
		// npm clean install 줄임말
    - run: npm ci
    - run: npm run test
    - run: npm run build
		// cicd 파이프라인이 돌아가는 컴퓨터에서는 s3계정 설정이 당연히? 안되어 있다.
    - name: deploy to s3
      uses: jakejarvis/s3-sync-action@master
      with:
        args: --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'ap-northeast-2'
        SOURCE_DIR: 'build'

근데… 이걸 내가 알아야 하나..?

  • 나 프론트 엔든데?

UI와 기능들을 코드로 개발하는 것이 업무의 전체라고 생각하기 쉽다. 개발자가 하는 기능개발은 전체 프로세스의 일부분일 뿐이다.

제품의 기획분석, 기능 개발 배포 및 운영을 책임져야 하며, 나아가 제품의 기획 단에도 참여해서 개발적으로 어떻게 요구사항을 풀어나갈 수 있는지, 유저의 피드백을 어던 방식으로 수용하면 좋을지에 대한 의견도 내곤 함

배포 및 운영까지 나의 책임이란 생각을 가져야지만 전체 개밝돠정을 보는 시야가 길러지고 그에 맞춰서 개발 일정을 조율하고, 어떤 식으로 하면 배포와 운영을 안정적으로 할 수 있을까? 란 고민을 할 수 있게 된다.

  • SW개발 프로세스의 A-Z까지를 이해하기 위해서 배포에 대한 지식은 필수적이다.
  • 프론트엔드 개발자도 개발한 프로덕트가 배포과정에서 발생한 트러블 슈팅에대해서 확인하고 대응할 수 있어야 한다.

'프론트엔드' 카테고리의 다른 글

React에서 관심사를 분리하는 법 (feat . customHook, router )  (0) 2023.05.21
소프트웨어 테스트 feat. react  (0) 2023.05.20
개발자의 기본 협업  (1) 2023.05.18
세션 기반 로그인에 대한 설명  (0) 2023.03.16
JWT토큰 인증 방식 로그인  (0) 2023.03.14

관련글

댓글 0

티스토리툴바