👉🏻문서 1번: https://velog.io/@heewonkim-dev/AWS-TIL-05

Achievement Goals

• 배포 자동화에 정의와 이점에 대해 설명할 수 있다.
• 배포 파이프라인이 무엇인지 정의할 수 있다.
• 파이프라인을 구성하는 단계(Stages)와 작업(Actions)에 대해 설명할 수 있다.
• AWS 개발자 도구를 활용하여 파이프라인을 구축할 수 있다.
• 배포 자동화 파이프라인 구축 과정에서 문제가 발생할 경우, log 파일과 공식 문서를 통해 해결할 수 있다.
• AWS에서 제공하는 IAM 서비스를 이해하고 사용할 수 있다.
  • 그룹, 사용자, 정책, 역할의 차이점과 특징에 대해서 이해할 수 있다.
  • IAM 정책에 대해 이해하고 특정 주체에게 권한을 부여할 수 있다.
  • IAM 보안 모범 사례에 대해 찾아보고, 서비스를 이용하며 적용할 수 있다.

Written with StackEdit.

배포 자동화

한 번의 클릭, 명령어 입력으로 전체 배포 과정을 자동으로 진행

• 반복적인 배포 과정을 자동화해 시간 절약.
• 휴먼 에러(Human Error) 방지.
  • 휴먼 에러 : 사람이 수동 배포 과정을 진행하는 중에 생기는 실수

배포 자동화 파이프라인

소스 코드의 관리부터 실제 서비스로의 배포 과정

• 파이프라인은 전체 배포 과정을 여러 단계(Stages)로 분리
  • 각 단계는 파이프라인 안에서 순차적 실행
    • 단계마다 주어진 작업(Actions) 수행

파이프라인에는 대표적으로 쓰이는 세 가지 단계가 존재합니다. 각 단계의 이름 및 수행하는 작업에 대해서 알아보겠습니다.

AWS 개발자 도구

개발자 도구 섹션 제공 서비스로 배포 자동화 파이프라인을 구축.

CodeCommit : Source 단계를 구성할 때 이용

GitHub과 유사한 서비스를 제공하는 버전 관리 도구.

• CodeCommit 서비스는 보안 기능에 강점.
• CodeCommit을 사용할 때는 과금 가능성을 고려해야 한다.
  • 프리티어 한계 이상으로 사용할 시 사용 요금이 부과될 수도 있다.
  • 사이드 프로젝트나 가볍게 작성한 소스 코드를 저장해야 할 경우 GitHub을 이용하는 것이 효과적.

CodeBuild : Build 단계에서 이용

• 유닛 테스트, 컴파일, 빌드와 같은 빌드 단계에서 필수적으로 실행되어야 할 작업을 명령어러 실행할 수 있다.

CodeDeploy : Deploy 단계를 구성할 때 이용

• 실행되는 서버 애플리케이션에 실시간으로 변경 사항을 전달할 수 있다.
• S3 서비스 버킷을 통해 업로드된 정적 웹 사이트에 변경 사항을 실시간으로 전달하고 반영할 수 있다.

CodePipeline: 각 단계를 연결하는 파이프라인을 구축할 때 이용

• 프리티어 계정에 두 개 이상의 파이프라인을 생성하면 추가 요금이 부여될 수 있다.

Written with StackEdit.

👉🏻문서 1번: https://velog.io/@heewonkim-dev/Docker-TIL-01 👉🏻문서 2번: https://velog.io/@heewonkim-dev/Docker-TIL-02 👉🏻문서 3번: https://velog.io/@heewonkim-dev/Docker-TIL-03

Achievement Goals

• Docker Hub에서 Docker Image를 검색하고, 사용할 수 있다.
• 한 개의 Docker Image를 이용해서 Container를 구축할 수 있다.
• 두 개 이상의 Docker Container를 이용해서 Container를 구축할 수 있다.
• 아래의 주요 키워드에 대해서 이해하고 CLI에서 명령어를 사용해서 제어할 수 있다.
  • Docker
  • Docker Hub
  • Docker Image
  • Docker Container
  • Docker Compose

Written with StackEdit.

Docker 컨테이너에 파일 복사

• 로컬에 있는 파일과 도커 이미지를 연결하는 방법

  1. *CP(Copy) 를 이용하는 방법 *

     • CP(Copy) : 호스트와 컨테이너 사이에 파일을 복사(Copy)

  2. Docker Volume 기능을 이용하는 방법

     • Volume : 호스트와 컨테이너 사이에 공간을 마운트(Mount)
       • 마운트 :
         • 저장 공간을 다른 장치에서 접근할 수 있도록 경로를 허용
         • 마치 *하나의 저장 공간을 이용하는 것처럼 보이게 하는 작업. *

httpd 웹 서버

Apache HTTP Server 실행할 수 있는 오픈소스 웹 서버 소프트웨어

httpd 는 /usr/local/apache2/htdocs/ 경로에 웹 서버와 관련된 파일들이 저장되어 있다면, 해당 파일을 기반으로 웹 서버가 실행되도록 합니다.

*1. codestates/pacman-canvas 레포지토리 클론. *

    git clone https://github.com/codestates/pacman-canvas

    //pacman-canvas 레포지토리를 클론

*2. docker container run로 httpd 실행. *

    docker container run --name 컨테이너_이름 -p 818:80 httpd

    // httpd를 실행
    // -p : 로컬호스트의 포트와 컨테이너의 포트를 연결
    // 818포트가 로컬호스트의 포트
    // 80번은 컨테이너의 포트

*3. 127.0.0.1:818, localhost:818로 웹 서버가 작동하고 있는지 확인 *

• *127.0.0.1 과 localhost *를 이용하면 *로컬 컴퓨터의 IP 주소로 redirecting *할 수 있다.

  • DNS 설정으로 인해 localhost 로 접속이 안 되고 127.0.0.1 만 접속 가능!

    

*4. 새로운 터미널을 열어 docker container cp 입력해 로컬호스트에 있는 파일을 컨테이너에 전달. *

• docker container cp : 앞 경로의 파일을 뒤 경로에 복사.

    docker container cp ./ 
    컨테이너_이름:/usr/local/apache2/htdocs/

    //현재 폴더의 파일을 뒤 경로에 복사

*5. 127.0.0.1:818 혹은 localhost:818 에 접속해서 게임 서버가 구동되는지 확인 *

Docker 이미지 만들기

1. 구동한 Docker Container를 이미지로 만드는 방법

** 1. docker container commit 이용 **

    docker container commit 컨테이너_이름 my_pacman:1.0

    //구동한 Docker Container를 commit

*2. 생성된 이미지를 900 포트에서 웹 서버로 구동 *

    docker run --name my_web2 -p 900:80 my_pacman:1.0
    //900 포트에서 웹 서버로 이미지를 구동

*3.127.0.0.1:900 혹은 localhost:900 을 통해 웹 서버가 작동하고 있는지 확인. *

2. Docker Image 빌드를 위한 파일인 Dockerfile 로 만드는 방법

• Dockerfile 을 만들고, *Dockerfile 대로 이미지를 build *하는 방법.

  • Dockerfile = 이미지 파일의 설명서.

    //현재 경로에 있는 파일을 생성할 이미지 경로에 
    //복사하는 명령의 Dockerfile 소스 코드
    

  FROM httpd:2.4 // 베이스 이미지를 httpd:2.4 로 사용합니다.

  COPY ./ /usr/local/apache2/htdocs/ // # 호스트의 현재 경로에 있는 파일을 생성할 이미지를 // /usr/local/apache2/htdocs/ 에 복사합니다.

1. docker build : Dockerfile로 도커 이미지 파일을 생성.

     // --tag 는 name:tag 형식으로 이미지를 생성할 수 있다.
     // 지정한 경로에 있는 Dockerfile을 찾아서 빌드

     docker build --tag my_pacman:2.0 . 
     // "."을 명령어에 꼭 포함! 

     //docker build는 Dockerfile로 도커 이미지 파일을 생성

2. 생성된 이미지를 이용해 901 포트에 웹 서버 구동

    docker run --name my_web3 -p 901:80 my_pacman:2.0

    //901 포트에서 웹 서버로 이미지를 구동

3. 127.0.0.1:901 혹은 localhost:901 을 통해 웹 서버가 작동하고 있는지 확인.

Written with StackEdit.

도커 이용하기

도커 이미지가 실행되면 도커 컨테이너가 됩니다.

docker/whalesay

• docker/whalesay 구성 :
  • 레지스트리 계정
  • 레포지토리 이름
  • 태그

1. 레지스트리(Registry)

• Docker Hub : https://hub.docker.com/
  • 도커 이미지 관리 공간
  • 다른 것을 지정하지 않는다면, 도커 허브(Docker Hub)가 기본 레지스트리.
    • Docker Hub
    • Private Docker Hub
    • 회사 내부용 레지스트리

2. 레포지토리(Repository)

• 레지스트리 내 도커 이미지가 저장되는 공간.
  • GitHub의 레포지토리와 유사.

3. 태그(Tag)

• 같은 이미지여도 버전 별 내용이 조금은 다를 수 있다.
• 해당 이미지를 설명하는 버전 정보를 입력.
  • 다른 것을 지정하지 않는다면 latest 태그를 붙인 이미지를 가져옴.

docker/whalesay:latest 라는 문장을 다시 읽어보면, 다음와 같이 읽을 수 있습니다.

• Docker Hub라는 레지스트리에서
• docker라는 유저가 등록한 whalesay 이미지 혹은 레포지토리에서
• latest 태그를 가진 이미지

Docker Hub : docker/whalesay

1. docker image pull

docker image pull docker/whalesay:latest

// docker/whalesay : docker 유저의 
//                   whalesay 레포지토리에서
// latest: 최신 이미지를 받아오기

• {image} pull : 레지스트리에서 이미지 혹은 레포지토리를 가져옴
  • docker pull로 검색해도 많은 정보를 찾을 수 있다.

2. docker image ls

docker image ls

//이미지 리스트를 출력

• 이미지 리스트를 출력

3. docker container run

docker container run --name 컨테이너_이름 
docker/whalesay:latest cowsay boo

//컨테이너_이름을 이름으로 갖는 컨테이너 실행
//받아온 이미지를 실행합니다. (이미지 → 컨테이너)

• {container} run *: *컨테이너를 실행
  • --name : 컨테이너의 이름을 할당
• command는 초기 컨테이너 실행 시 수행되는 명령어.
  • cowsay : *컨테이너 실행 시 cowsay를 호출. *
    • node를 호출하듯 이용.
  • boo : COMMAND인 cowsay에 넘겨질 파라미터.

whalesay 컨테이너가 실행되었을 때 터미널에 출력되는 화면

4. docker container ps -a

docker container ps -a

//모든 컨테이너의 리스트를 출력

• {container} ps : 컨테이너의 리스트를 출력
• -a : 종료된 컨테이너를 포함하여 모든 컨테이너를 출력.

5. docker container rm 컨테이너_이름

docker container rm 컨테이너_이름

//컨테이너_이름이라는 이름을 가진 컨테이너를 삭제

• {container} rm :
  • *컨테이너를 지칭해서 삭제. *
  • 컨테이너 명시: *ps로 확인 가능한 NAMES 혹은 CONTAINER ID *

6. docker image rm docker/whalesay

//# docker image 의 용량 확인
docker image ls

//# docker/whalesay 이미지 지우기
docker image rm docker/whalesay

• 사용한 images의 용량을 확인하고, 도커 이미지를 삭제

7. 세 가지 작업을 한 번에 실행

하나의 이미지를 받아와 컨테이너로 실행하고, 컨테이너와 관련된 리소스를 삭제하는 작업까지 수행했습니다. 이번에는 세 가지 작업을 한 번에 실행해 보겠습니다.

docker container run --name 컨테이너_이름 --rm 
docker/whalesay cowsay boo

//세 가지 작업을 한 번에 실행

• {container} run : 컨테이너를 실행. 이미지가 없다면 이미지를 받아온 뒤(pull) 실행
• --rm : 컨테이너를 일회성으로 실행. 컨테이너가 중지되거나 종료될 때, 컨테이너와 관련된 리소스를 모두 제거.

8. docker image rm docker/whalesay

docker image rm docker/whalesay

//지정된 도커 이미지를 삭제

• image rm : 지정된 도커 이미지를 삭제
  • docker rmi 도 같은 기능

danielkraic/asciiquarium

danielkraic/asciiquarium를 정상적으로 실행시켰을 때 출력되는 알록달록한 바닷속 물고기

docker container run -it --rm 
danielkraic/asciiquarium:latest

//danielkraic/asciiquarium 이미지를 실행

• danielkraic라는 사람이 올린 이미지 asciiquarium 를 실행

• *-it : -i, -t 를 동시에 사용한 옵션. *

  • 사용자와 컨테이너 간에 인터렉션(interaction)이 필요시 사용

• container는 ctrl + c 로 종료.

Written with StackEdit.

Docker

리눅스 컨테이너(Linux Container) 기술 기반의 오픈 소스 서비스

Linux Container

• 필요한 라이브러리와 애플리케이션을 모아서 마치 별도의 서버처럼 구성한 것.
• 컨테이너를 이루는 네트워크 설정, 환경 변수 등의 시스템 자원은 각 컨테이너가 독립적으로 소유하고 있다.

Linux Container 특징

Docker가 해결할 수 있는 문제들

1. 환경 표준화

개발하려고 하는 여러 애플리케이션을 구동하는 운영체제가 서로 다르다면 환경에 따라 조금씩 변경할 부분이 발생합니다. 같은 Linux 인 Ubuntu, CentOS, Debian 은 서로 다른 환경이므로 여러 버전이 존재할 수도 있습니다.

2. 수작업으로 일치시키는 환경 구성

개발된 애플리케이션을 내 컴퓨터에 설치해 사용하고자 할 때, '내 컴퓨터' 혹은 '내 사용 목적'에만 맞는 설정이 따로 필요할 수 있습니다. 예를 들어 환경 변수처럼, 같은 OS라도 사용자에 따라 달라지는 구성이 있습니다.

3. 리소스 격리성

• 리소스 격리성:
  • 실제로는 하나의 컴퓨터를 사용하지만, *마치 여러 개의 컴퓨터를 이용하는 것 *
• 리소스 격리성을 제공하는 기술로: 가상 머신(Virtual Machine), 도커
  • 가상 머신:
    • 개발 환경이나 사용 환경을 이미지로 저장
    • Host OS 위에 게스트 OS를 올리는 방식: VirtualBox, VMware

      가상 머신과 도커는 격리성을 제공하기 때문에, 각 애플리케이션마다 다른 컴퓨터에서 실행되는 것처럼 IP나 Port 등을 다르게 설정할 수 있습니다.

도커 VS 가상 머신

• 도커는 가상 머신만큼 견고한 격리성을 제공하지는 않는다.
• 도커는 리눅스의 컨테이너(Linux Container)를 이용한 기술
  • OS 위에 다른 OS를 실행하는 것이 아니므로 가상 머신보다 좋은 성능을 낼 수 있다.
• VM: 애플리케이션에 대한 환경 격리성을 중심
• 도커: Container의 관점에서 개발자와 사용자 커뮤니티 중심으로 혜택 제공

Docker Container Lifecycle

도커 컨테이너의 독립적인 특징을 기반으로 한 Lifecycle이 있습니다. 위 그림을 보면, 컨테이너의 생성, 실행, 종료의 과정을 이해할 수 있습니다.

Written with StackEdit.

👉🏻문서 1번: https://velog.io/@heewonkim-dev/AWS-TIL-01 👉🏻문서 2번: https://velog.io/@heewonkim-dev/AWS-TIL-02 👉🏻문서 3번: https://velog.io/@heewonkim-dev/AWS-TIL-03 👉🏻문서 4번: https://velog.io/@heewonkim-dev/AWS-TIL-04

Achievement Goals

• Cloud와 Deployment의 의미를 각각 알고, 내 코드를 남에게 배포할 수 있다.

  • 클라우드 컴퓨팅이 무엇인지 설명할 수 있다.
  • Deployment의 의미를 이해할 수 있다.
  • 코드를 남에게 배포할 수 있다.

• 사용하는 서비스들의 특징과 사용해야 하는 이유를 이해할 수 있다.

  • RDS와 EC2에 설치된 데이터베이스의 차이를 이해할 수 있다.
  • S3의 높은 가용성과 안정성을 이해할 수 있다.
  • CloudFront의 콘텐츠 로딩시간 단축의 효과들을 이해할 수 있다. (advanced)
  • Route53을 이용해 요청을 쉽고 안전하게 원하는 곳으로 보낼 수 있음을 이해할 수 있다. (advanced)

• 커스텀 도메인을 이용해 요청을 원하는 곳으로 라우팅할 수 있다. (advanced)

  • DNS가 무엇인지 이해할 수 있다. (advanced)
  • 커스텀 도메인을 이용해 인증서를 발급받고 SSL을 적용할 수 있다. (advanced)

Written with StackEdit.

배포 전략

배포 : 개발한 서비스를 사용자가 이용할 수 있도록 하는 것

1. Client Application 배포

1-1. AWS의 S3 서비스를 통해 사용자들에게 Client를 제공할 수 있다.

• 로컬 환경에서는 *자체 개발 서버를 이용해서 클라이언트 앱을 실행. *

그럼, 클라이언트를 위해서 EC2 인스턴스를 사용해야 할까요?

그렇지 않다.

• 클라이언트 앱을 정적 파일로 빌드하여 제공하므로 S3를 이용해서 클라이언트를 배포한다.

1-2. 빌드

• 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합하여 배포하기에 최적화된 상태를 만드는 것.
• 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다.
• 웹 앱은 배포 가능한 정적 파일의 형태로 만들어 줘야 한다.

  asset 자체가 정적인 경우, 있는 그대로 배포하면 됩니다. React의 경우 npm run build와 같은 명령을 사용해서, 정적 파일 형태의 결과물을 만들어 낸 후 배포하면 됩니다. 사용하고 있는 환경에 따라 빌드 과정은 다를 수 있습니다.

S3로 사용자들에게 Client Application을 제공하고 있는데, 사용자가 지구 반대편에 있다면 어떻게 빠르게 서비스를 제공할 수 있을까요?

• AWS에서 제공하는 CDN 서비스인 CloudFront를 통해 각 데이터센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공.

2. Server Application 배포

사용자들이 제공받은 Client Application을 통해서 요청을 전달할 Server Application은 어떻게 배포해야 할까요?

• AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있습니다.

3. Database 배포

• AWS에서는 Database 특화 서비스인 RDS 서비스를 제공하고 있다.
  • *유지 보수 작업 담당하는 RDS를 이용해 즉시 데이터베이스를 사용. *
• RDS를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포.

4. DNS

• www.google.com과 같은 도메인 주소를 이용해서 접근할 수 있었다.

처음 배포된 서비스는 도메인주소를 통해 접근할 수 있까?

• S3, EC2를 이용해 배포된 서비스는 IP주소 혹은 AWS에서 제공하는 서비스와 상관없는 긴 도메인주소를 통해 접근.

• AWS Route 53 서비스를 이용하면 도메인 주소를 통해 서비스에 접근 할 수 있다.

Written with StackEdit.

RDS (Relational Database Service)

RDS: AWS에서 제공하는 관계형 데이터베이스 서비스

RDS 사용 이점

1. EC2 인스턴스

• EC2 인스턴스에 데이터베이스를 설치하여 데이터를 관리하는 것은 개인 소유 차량을 이용하는 것과 비슷.
  • 개인 소유 차량을 이용하면 유지보수, 보험처리 일들을 운전자 부담.
  • EC2 인스턴스 : 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야한다.

    가용성과 내구성이 확보되지 않기에데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어렵습니다.

2. RDS

• RDS를 이용하는 것은 렌터카 회사에서 차량을 대여하는 것과 비슷.
  • 대여 차량과 관련하여 시간이 들어가는 일들을 렌터카 회사에서 대신 처리.
  • 운전자는 운전만 하면 되기에 매우 편리.
• RDS를 이용하면 데이터베이스 유지보수는 RDS에서 전적으로 자동 관리.
• 사용자가 해야할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없다.

3. 다양한 데이터베이스 엔진 선택지를 제공

• 실무자는 회사에 필요한 데이터베이스 엔진을 취사선택하여 이용할 수 있다 .
• 일반 사용자는 필요와 목적에 맞게 데이터베이스 엔진을 선택하여 효율성을 높일 수 있다.

S3

클라우드 스토리지

인터넷 공간에 데이터를 저장하는 저장소

• 컴퓨터 부품으로 비유하면 하드디스크의 역할을 하는 서비스.
• 클라우드 스토리지 서비스의 장점
  • 뛰어난 접근성을 가지고 있다.
    • 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있다.

S3 : Simple Storage Service

AWS에서 제공하는 클라우드 스토리지 서비스

• S3도 뛰어난 접근성을 가지고 있다.

S3 사용 시 얻을 수 있는 이점

1. 높은 확장성

• 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있다.
  • S3에서는 스토리지의 용량을 무한히 확장할 수 있다.
• 사용한 만큼만 비용을 지불하면 되기 때문에 비용적 측면에서 매우 효율적.

2. 강력한 내구성

• 스토리지의 내구성이 높으면 저장된 파일을 유실할 가능성이 적어진다.
• S3는 99.999999999%의 내구성을 보장.

3. 99.99%의 가용성 보장

• 가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어진다.
• S3는 연간 99.99%의 스토리지 가용성을 보장한다.

AWS는 어떤 원리로 해당 서비스들의 높은 가용성과 내구성을 보장할 수 있는 걸까요?

• 리전(Region - 지도 상 주황색 동그라미):
  • AWS 클라우드 서비스를 제공하기 위해 운영하는 물리적 서버의 위치.
• 주황색 동그라미 안 숫자: 리전에 위치한 가용영역의 수
  • 가용 영역(Availability Zone): 각 리전 안에 존재하는 데이터 센터(IDC)
    • 가용 영역은 각각 개별적인 위치에 떨어져서 존재.
    • 한 곳의 가용 영역이 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제 없이 서버가 가동

4. 다양한 스토리지클래스를 제공

4-1. Standard 클래스

• 범용적인 목적으로 사용
• 데이터에 빠른 속도로 접근
• 데이터 액세스 요청에 대한 처리 속도가 빠름
• 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아님
  • 보관 비용이 높게 발생

4-2. Glacier 클래스

• 장기적인 보관 목적으로 스토리지를 사용할 때는 Glacier를 사용
• 저장된 데이터 *액세스 속도는 느리지만, 데이터를 보관하는 비용이 저렴. *

이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등등 여러 가지 스토리지 클래스가 존재하여 사용자의 이용 목적에 따라 다양한 스토리지 클래스를 사용할 수 있습니다.

5. 정적 웹 사이트 호스팅이 가능

정적 웹 사이트 호스팅

• 정적 파일 :
  • 서버의 개입 없이 생성된 파일
• 동적 파일:
  • 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일

웹 호스팅(Web Hosting) :서버의 한 공간을 임대해주는 서비스

• 웹 호스팅 업체가 제공하는 *서버의 한 공간을 빌려서 원하는 서비스를 배포. *
• S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공.

  버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있다.

5-1. 버킷

S3에 저장되는 파일들이 담기는 바구니 (파일을 저장하는 최상위 디렉터리)

• S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 함.
• 버킷에는 무한한 양의 파일을 저장할 수 있다.
• 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 한다.
• 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있다.

5-2. 객체

S3에서 버킷에 담기는 파일

왜 객체라고 부를까요?? S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문입니다.

• S3에 저장되는 객체는 파일과 메타데이터로 구성.
  • 파일 : 키-값 페어 형식으로 데이터를 저장.
    • 파일 값: 실제 데이터를 저장.
      • S3 객체의 값으로써 저장될 수 있는 데이터는 최대 5TB.
    • 파일 키: 각각의 객체를 고유하게 만들어주는 *식별자 역할. *
      • 파일의 키를 이용하여 원하는 객체를 검색할 수 있다.
  • 메타데이터: 객체에 대한 정보가 담긴 데이터.
    • (객체를 설명하는 데이터)
• 모든 객체는 고유한 URL 주소를 가지고 있다.
  • URL : http://[버킷의 이름].S3.amazonaws.com/[객체의 키]
  • URL 주소를 통해서도 원하는 데이터에 접근할 수 있다.

Written with StackEdit.

Deployment

배포: 개발한 서비스를 사용자들이 이용가능하게 하는 일련의 과정

회사마다 추가적인 과정이 있을 수 있지만, 기본적으로 4단계를 거쳐서 개발한 서비스를 배포하게 됩니다.

• Development 환경과 Production 환경은 서로 다를 수가 있다.
• 배포에서, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요

작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면

1. 절대 경로 대신 상대 경로를 사용한다.
2. 환경에 따라 분기 할 수 있도록 환경변수를 설정해준다.
3. Docker와 같은 개발 환경 자체를 통일 시키는 솔루션을 사용한다.

배포를 위한 다양한 플랫폼들

EC2

아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스

클라우드 컴퓨팅: 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스.

정리하면 아마존에서 가상의 컴퓨터를 한 대 빌리는 것과 같습니다.

EC2서비스는 AWS에서 비용, 성능, 용량면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스

AWS에서 제공하는 Elastic Compute Cloud서비스 앞에 붙은 Elastic이라는 단어는 어떤 의미일까요?

• EC2서비스는 사용한 만큼비용을 지불하기 때문에 탄력적인 이라는 의미의 Elastic이라는 단어가 붙었다.
• Elastic은 비용적인 부분 뿐만이 아니라 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다는 의미도 가지고 있다.

EC2 서비스의 장점

1. 구성하는 데 필요한 시간이 짧다.

만약 PC를 구매한다면 구매해서 배송되는 데까지의 시간이 필요하지만 EC2 서비스는 몇 번의 클릭만으로 PC를 구성할 수 있습니다.

2. 다양한 운영체제에 대한 선택이 가능하다.

• EC2에서는 AMI라는 다양한 템플릿을 제공하고 있어서 필요에 따라 손쉽게 운영체제를 선택하고 구성할 수 있다.
• 운영체제뿐만이 아니라 CPU와 RAM, 용량까지도 손쉽게 구성할 수 있다.

AWS에서 빌리는 컴퓨터를 인스턴스

• EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 일을 할 수 있다.
• 아마존 EC2를 통해서 할 수 있는 기본적인 일 :
  • 웹서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공.
• 인스턴스는 1대의 컴퓨터를 의미하는 단위
• (AWS에서 컴퓨터를 빌리는 것) = (인스턴스를 생성).

AMI

AMI는 소프트웨어 구성이 기재된 템플릿

• 이미지 종류로는 단순히 운영체제만 깔려있는 템플릿을 선택할 수도 있다.
• 아예 특정 런타임이 설치되어있는 템플릿이 제공되는 경우도 있다.
  • 우분투 + node.js
    • 윈도우 + JVM

• Instance는 선택한 AMI를 토대로 구성.
• AWS에는 AMI 셋팅이 준비되어 있어 인스턴스의 운영체제를 구성할 수 있다.
• 셋팅되어 있는 AMI 이외에도 필요에 따라 직접 AMI를 구성할 수도 있다.

AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것입니다.

Written with StackEdit.

Cloud Computing

클라우드 컴퓨팅의 등장 배경

• 클라우드 등장 이전 :
  • 전산실 등에 컴퓨터를 배치하고 인터넷 연결하여 서비스를 제공.

그런데 만약 서버가 요청에 대한 수용 능력이 한계에 도달한다면 어떻게 대처할까요?

1. 같은 공간에 더 많은 컴퓨터를 제공해 한 대가 해결할 수 있는 요청을 여러 대가 나누는 방식 사용.
2. 컴퓨터 한 대의 성능을 높이는 방식을 사용.

하지만 이런 방식은 몇 가지 문제점들을 가지고 있었습니다.

1. 주기적인 관리가 필요.
   • 서버실에** 종종 고장**이 나거나 인터넷과 연결이 되지 않는 컴퓨터가 생긴다.
     • 이를 해결하기 위한 인력 및 비용이 투입되어야 했다.
   • 관리해야 하는 컴퓨터 수가 많아져 투입 인력 및 비용도 증가하기 시작.
2. 공간의 한계
   • 예전 : 서버실에 컴퓨터를 배치해 두고 필요에 따라 컴퓨터를 추가하는 방식으로 수용 능력 향상.
     • 이런 방식은 공간이 부족하여 컴퓨터를 더는 배치할 수 없는 문제에 직면.
     • 컴퓨터의** 성능을 높이고 부피를 줄여 좀 더 많은 컴퓨터를 같은 공간에 배치**하는 방법.
   • 추가적인 서버 증설이 어렵게 되자 거대 기업은 데이터센터라는 거대한 건물을 세우기 시작.
   • 이때부터 데이터센터의 유휴 자원을 대여하는 서비스가 등장하기 시작.

즉 서버의 자원과 공간, 및 네트워크 환경을 제공을 빌려 사용하는 클라우드 컴퓨팅이 시작된 순간입니다.

Cloud

클라우드의 등장

• 데이터 센터에서 서버 자원과 공간, 및 네트워크 환경을 제공. (온프레미스)
  • 현대의 클라우드 컴퓨팅은 데이터 센터와 비슷한 역할
  • 물리적인 컴퓨터가 아닌, 가상 컴퓨터를 대여한다.
• 가상화 기술을 사용하는 클라우드 서비스의 장점.
  1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있다.
  2. 고정 비용의 온프레미스와는 달리 사용한 만큼의 요금만 지불.
  3. 컴퓨터의 스냅샷을 이용해 다른 컴퓨터로 즉시 이주(migration) 가능.

클라우드의 단점

• 운영 환경이 클라우드 제공자에게 종속되어 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향이 미친다.
  • 운영환경이 특정 클라우드 사업자(vendor)에게 종속된다 :
    • 백엔드 구성이 특정 회사의 기술로 구성 해야만 하는 경우가 발생할 수도 있다.

클라우드는 모든 것을 서비스화하는 것을 목표

대표적 클라우드 서비스의 형태 : SaaS, IaaS, PaaS

Written with StackEdit.

👉🏻문서 1번:https://velog.io/@heewonkim-dev/GIT-TIL-03 👉🏻문서 2번:https://velog.io/@heewonkim-dev/GIT-TIL-04

Before You Learn

• Git의 환경설정을 할 수 있다.
• 버전 관리 시스템의 필요성을 이해 하고 있다.
• Github과 Git의 관계에 대해 이해 하고 있다.
• Repository에 대해 이해 하고 있다.
  • Local Repository와 Remote Repository의 차이를 이해하고 있다.

Achievement Goals

• Git 브랜치의 개념을 이해할 수 있다.
• Git 으로 협업하며 브랜치를 나누는 이유를 이해할 수 있다.
• Git 으로 프로젝트를 관리하며 브랜치를 생성, 전환, 병합할 수 있다.

Written with StackEdit.

프로젝트 workflow

1. Fork, clone

Remote에 생성한 프로젝트 Repository를 각자의 Repository로 가져오기

1. 프로젝트 Remote Repository 만들기.
2. 팀원들과 함께 나누어 작업을 하기 위해서 각자의 Remote Repository로 Fork.
3. Local에서 작업하기 위해서 git clone 명령어로 Repository를 Local에 가지고 왔다.

2. git checkout -b 새로운 브랜치 이름 / git switch -c 새로운 브랜치 이름

브랜치를 생성하고 생성한 브랜치로 이동

• 개발 과정에서는 main 브랜치가 아닌 dev 브랜치를 하나 만들어서 작업을 하는 경우가 많다.

dev 브랜치를 만들어서 해당 브랜치로 이동해 보겠습니다. 여기서 HEAD는 현재 위치의 커밋을 가리킵니다. 즉 현재 작업중인 커밋입니다.

• git checkout -b dev 통해서 dev 브랜치를 생성.
  • git switch -c dev 도 가능.
• Remote Repository 에도 생성한 브랜치를 반영하기 위해서는 git push origin dev 를 입력.

3. git branch

생성한 브랜치의 목록 및 현재 위치한 브랜치 확인

브랜치가 잘 생성되었는지 확인하고 싶어요. 생성한 브랜치의 목록과 내가 현재 dev 브랜치에 있는 것이 맞는지 확인해 볼 방법은 없을까요?

• git branch 명령어를 통해 확인할 수 있다.
• 터미널 창에 git branch 를 입력하면 아래 화면이 뜬다.

• 알파벳 q 를 눌러서 종료할 수 있다.

4. git checkout -b 새로운 브랜치 이름 / git switch -c 새로운 브랜치 이름

브랜치를 생성하고 생성한 브랜치로 이동

회의를 통해 하나의 기능을 구현할 때는 feature/기능이름 브랜치를 만들어서 작업하기로 정했습니다. 로그인 기능을 구현하기 위해서 feature/login 브랜치를 생성해보도록 하겠습니다.

• git checkout -b feature/login 를 입력.
  • git switch -c feature/login 도 같은 기능.

5. git checkout -b 새로운 브랜치 이름 / git switch -c 새로운 브랜치 이름

브랜치를 생성하고 생성한 브랜치로 이동

feature/login 브랜치에서 로그인 기능이 완성되었습니다! 여기에 소셜 로그인(oauth) 기능을 추가해 보고 싶어요. 그런데 로그인 코드를 건드리자니 위험 부담이 있네요. 새로운 브랜치를 하나 더 만들어서 작업하고 싶습니다. feature/login-oauth 라는 이름으로 feature/login 브랜치에서 파생된 브랜치를 하나 더 만들어서 작업해 보겠습니다.

• git checkout -b feature/login-oauth 를 입력.
  • git switch -c feature/login-oauth 명령어도 같은 기능.

6. git checkout -b 새로운 브랜치 이름 / git switch -c 새로운 브랜치 이름

브랜치를 생성하고 생성한 브랜치로 이동

소셜 로그인 기능까지 구현이 완료되었습니다. 이 feature/login-oauth에 있는 코드를 feature/login 브랜치로 병합(merge) 할 수 있는 방법이 있을까요? 먼저 git checkout(switch) feature/login 명령어를 통해 feature/login 브랜치로 이동하세요.

• git checkout -b feature/login 를 입력.
• merge하기 위해서는 먼저 병합이 될 브랜치로 이동을 해야 한다.
  • feature/login-oauth 브랜치를 feature/login 브랜치로 병합하기 위해서는 feature/login 브랜치로 이동.
  • git switch feature/login도 같은 기능.

7-1. git merge 병합할 브랜치 이름

브랜치 병합하기

• feature/login-oauth 내용을 feature/login 브랜치로 병합
  • 현재 위치가 feature/login
    • git merge feature/login-oauth 입력.
• feature/login-oauth 머지 전 feature/login에 추가 커밋이 없어, 브랜치가 분기될 필요가 없다.
  • 자동적으로 fast-forward 방식으로 병합이 이뤄진다.
    • fast-forward : 별도의 커밋을 생성하지 않고 feature/login 브랜치가 가리키는 커밋을 feature/login-oauth 가 생성한 커밋으로 바꾸는 작업

7-2. git merge 병합할 브랜치 이름

만일, feature/login 브랜치에 별도의 커밋이 있었다면?

• merge commit 방식으로 병합되었을 것.
  • 각 브랜치가 줄기처럼 분기한 후, 병합의 모양새를 가짐.

• git merge feature/login-oauth 입력
• 해당 브랜치를 현재 위치한 브랜치로 병합(merge).

merge와 rebase의 차이점

• merge
  • 변경 내용의 이력이 모두 그대로 남아 있어 이력이 복잡해 짐.
• rebase
  • 말 그대로 branch base를 이동
  • rebase의 원리 = fast-forward.
  • 머지처럼 브랜치 통합을 목적
  • 특정 시점으로 브랜치가 가리키는 곳을 변경하는 기능.

feature/login 에서 git rebase main feature/login 명령어를 입력하면 main의 가장 최신 커밋으로 브랜치가 가리키는 곳이 변경됩니다. (main의 다른 커밋에서 충돌이 없을 경우)

8. git push origin 브랜치 이름

Remote Repository로 업로드하기

• 로컬 작업 내용을 Remote Repository 에 업로드하기 위해서는 push

• git push origin feature/login 입력
• 해당 브랜치를 Remote Repository로 업로드.

9. Pull Request

내가 push한 변경사항에 대해서 다른 사람들에게 알리는 것

feature/login의 변경 사항을 다른 팀원들과 함께 코드 리뷰를 하고 dev 브랜치에 적용하고 싶습니다.

• Github의 Pull Request 기능을 활용해 dev 브랜치로의 반영을 요청.
• 리뷰가 끝난 코드는 브라우저에서도 dev 브랜치로 merge 할 수 있다.

• 간단하게 PR 내용을 입력한 후 Create pull request 버튼을 클릭.

전체적인 흐름 그림 (아래 참조)

Written with StackEdit.

브랜치

독립적으로 어떤 작업을 진행하기 위한 개념

개발을 하다 보면 한 페이지 안의 여러 기능을 따로 구현하기 위해, 코드를 여러 개로 복사해야 하는 일이 자주 생깁니다. 브랜치 기능을 활용하면, 코드를 통째로 복사한 후 원래 코드가 변경될 우려 없이 독립적으로 개발할 수 있습니다.

• 각각의 브랜치는 다른 브랜치의 영향을 받지 않아 여러 작업을 동시에 진행할 수 있다.
• 브랜치 기능의 장점
  • 한 소스코드에서 동시에 다양한 작업을 할 수 있게 해준다.
  • 소스코드의 한 시점과 동일한 상태를 만들고, 브랜치를 넘나들며 작업을 수행할 수 있다.
  • 각각의 브랜치에서 생긴 변화가 다른 브랜치에 영향을 주지 않고 독립적으로 코딩을 진행할 수 있다.

master 또는 main 이라는 이름을 가진 통합 브랜치에 뿌리를 두고, 각각의 브랜치가 갈라져 나오고 있는 모습입니다.

• 나누어진 브랜치에서는 각 저장소 안에서 마음대로 소스코드를 변경할 수 있다.
• 브랜치에서 변경된 내용들은 다른 브랜치와 병합함으로써 다시 새로운 하나의 브랜치로 모을 수 있다.

여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 통합 브랜치에서 자신의 작업 전용 브랜치를 만듭니다.

• 각자의 브랜치에서 맡은 영역에 대한 작업을 진행한 후, 작업이 끝난 브랜치는 통합 브랜치에 병합해서 변경 사항을 적용.

브랜치 종류

1. 통합 브랜치 (Integration Branch)

배포될 소스 코드가 기록되는 브랜치.

• Github Repository를 생성하게 되면 기본적으로 main 브랜치가 생긴다.
• 프로젝트의 모든 기능이 정상적으로 작동하는 상태의 소스코드가 담겨 있다.
  
  

2. 피처 브랜치 (Feature Branch)

기능 추가, 버그 수정과 같이 단위 작업을 위한 브랜치.

• 통합 브랜치로부터 만들어내며, 피처 브랜치에서 하나의 작업이 완료가 되면 다시 통합 브랜치에 병합하는 방식으로 진행.
• 토픽 브랜치라고도 한다.

브랜치 명령어 모음

Written with StackEdit.

👉🏻문서 1번:https://velog.io/@heewonkim-dev/HTTP-TIL-06 👉🏻문서 2번:https://velog.io/@heewonkim-dev/HTTP-TIL-07 👉🏻문서 3번:https://velog.io/@heewonkim-dev/HTTP-TIL-08 👉🏻문서 4번:https://velog.io/@heewonkim-dev/HTTP-TIL-09 👉🏻문서 5번:https://velog.io/@heewonkim-dev/HTTP-TIL-10 👉🏻문서 6번:https://velog.io/@heewonkim-dev/HTTP-TIL-11 👉🏻문서 7번:https://velog.io/@heewonkim-dev/HTTP-TIL-12 👉🏻문서 8번:https://velog.io/@heewonkim-dev/HTTP-TIL-13

Achievement Goals

• HTTP 기반 네트워크 흐름에 대해 이해할 수 있다.
• TCP/IP 기반 네트워크 흐름에 대해 이해할 수 있다.
  • TCP/IP 패킷이 왜 필요한 지 설명할 수 있다.
  • TCP와 UDP의 차이에 대해 설명할 수 있다.
• HTTP 기본 동작과 특징에 대해 이해할 수 있다.
  • 상태유지(Stateful)과 무상태(Stateless)의 개념에 대해 설명할 수 있다.
  • HTTP 메시지 구성에 대해 설명할 수 있다.
• HTTP 헤더의 역할에 대해 이해할 수 있다.
  • 표현, 콘텐츠 협상 등 다양한 헤더의 역할에 대해 알 수 있다.
• 캐시가 왜 필요한 지 알 수 있다.
  • 브라우저 캐시, 프록시 캐시에 대해 설명할 수 있다.
  • 조건부 요청, 캐시 무효화 방법 등을 사용할 수 있다.

Written with StackEdit.

프록시 캐시

• 프록시: 클라이언트와 서버 사이에 대리로 통신을 수행하는 중계 기능을 하는 서버.

  클라이언트, 혹은 반대로는 서버가 다른 네트워크에 간접적으로 접속 할 수 있기 때문에, 보안, 캐싱을 통한 성능, 트래픽 분산 등의 장점을 가집니다.

한국에 있는 클라이언트에서 특정 데이터가 필요한 상황인데 해당 데이터의 원 서버가 미국에 있다고 가정.

• 한국에서 미국까지 직접 접근하여 이미지를 가져오는데 0.5초 소요.
• 한국 클라이언트는 모두 0.5초 가량을 기다려야 해당 이미지를 받을 수 있다.

클라이언트와 원 서버 사이에 위치한 프록시 캐시 서버를 도입.

한국에 프록시 캐시서버를 두고 한국의 클라이언트는 프록시 캐시서버를 통해 자료를 가져오도록 해봅시다.

• 여러 사람이 찾은 자료일수록 이미 캐시에 등록되어 빠른 속도로 자료를 가져올 수 있다.
  • 같은 국내에 있기에 원서버에 접근하는 것보다 훨씬 빠른 속도에 자료를 가져올 수 있기 때문.
  • 클라이언트에서 사용하고 저장하는 캐시를 private 캐시
  • 프록시 캐시 서버의 캐시를 public 캐시

캐시 지시어

캐시 무효화

• 캐시를 무효화를 확실하게 해야하는 경우 Pragma와 같은 하위호환까지 포함하여 위와같이 적용해야 한다.

no-cache

• 캐시 서버 요청을 하면 프록시 캐시 서버에 도착하면 no-cache인 경우 원 서버에 요청.
• 원 서버에서 검증 후 304 응답.

• 프록시 캐시 서버와 원 서버간 네트워크 연결이 단절되어 접근이 불가능
• no-cache에서는 오래된 데이터라도 보여주자라는 개념으로 200OK으로 응답.

must-revalidate

• 원 서버에 접근이 불가할 때 504 Gateway Timeout 오류를 보냄.

  통장 잔고 등 중요한 정보가 원 서버를 못 받았다고 해서 예전 데이터로 뜬다면 큰 문제가 생기기때문에 이런 경우 must-revalidate를 써야 합니다.

Written with StackEdit.

캐시 검증 헤더와 조건부 요청

Last-Modified & If-Modified-Since

• 검증 헤더 Last Modified로 캐시의 수정시간을 알 수 있다.
  • Last Modified : 데이터가 마지막으로 수정된 시간정보를 헤더에 포함. (데이터 최종 수정일 정보)
    • 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장.

• 캐시의 유효시간이 초과되도 If-Modified-Since 헤더를 이용해서 조건부 요청을 할 수 있다.
  

• 서버의 해당 자료의 최종 수정일과 비교해 데이터 수정이 안되었을 경우 응답 메세지에 이를 담아서 알려준다.
  • 이때 HTTP Body는 응답 데이터에 없음
    • 상태코드 304 Not Modified : 변경된 것이 없다는 뜻.
• 전송 데이터에 바디가 빠졌기 때문에 헤더만 포함된 0.1M만 전송.
• 클라이언트에서는 해당 응답을 받은 뒤 캐시를 갱신해주고 다시 일정시간(60초)동안 유효하게 됨.

Last-Modified와 If-Modified-Since를 정리

• 캐시 유효 시간이 초과해도 서버의 데이터가 갱신되지 않으면?
  • 304 Not Modified + 헤더의 메타데이터만 응답 (바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 데이터를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터를 재활용
• 결과적으로 네트워크 다운 로드가 발생하지만, 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책

Last-Modified와 If-Modified-Since 단점

• 1초 미만의 단위로는 캐시 조정이 불가능
• 날짜 기반의 로직 사용
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터의 결과가 똑같은 경우
• 서버에서 별도로 캐시 로직을 관리하고 싶은 경우
  • 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

ETag와 If-None-Match 검증헤더

서버에서 완전히 캐시를 컨트롤하고 싶은 경우 ETag를 사용

ETag와 If-None-Match의 작동방식

• 서버에서 헤더에 ETag를 작성해 응답.
• 클라이언트의 캐시에서 해당 ETag 값을 저장.

• 캐시시간이 초과되서 다시 요청을 해야하는 경우
  • ETag값을 검증하는 If-None-Match를 요청 헤더에 작성해서 보낸다.

• 서버에서 데이터가 변경되지 않았을 경우 ETag는 동일해서 If-None-Match는 거짓.
  • 서버에서는 304 Not Modified를 응답
  • HTTP Body는 없다.
• 브라우저 캐시에서는 응답 결과를 재사용하고 헤더 데이터를 갱신

ETag와 If-None-Match를 정리

• 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 형식
• 캐시 제어 로직을 서버에서 완전히 분리
• 클라이언트는 단순하게 이 값을 서버에 제공
  • 클라이언트는 캐시 매커니즘을 모름.

캐시와 관련된 헤더들과 조건부 요청 헤더

Written with StackEdit.

캐시

캐시가 없는 경우

클라이언트가 logo.jpg 이미지에 대한 요청을 보내고 서버가 해당 이미지에 대한 응답을 줄 때, HTTP 헤더가 0.1M, 바디가 1.0M로 총 1.1M로 가정해보겠습니다.

• 데이터가 변경되지 않아도 계속 네트워크를 통해 데이터를 다운 받아야한다.
• 인터넷 네트워크 속도가 느리고 비싸다.
• 브라우저 로딩속도가 느리다.
• 느린 사용자 경험을 제공한다.

캐시를 적용한 경우

캐시(cache): 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소.

• 캐시 접근 시간에 비해 원래 데이터 접근 시간이 오래 걸리는 경우
• 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용.
• 캐시에 데이터를 미리 복사해 놓으면 더 빠른 속도로 데이터에 접근할 수 있다.
• 브라우저에 캐시를 저장: 헤더에 cache-control 속성
  • 캐시가 유효한 시간을 지정.

    60초로 설정한다면 60초 동안은 해당 캐시가 유효

응답을 받았을 때 브라우저 캐시에 해당 응답 결과를 저장하며 이는 60초간 유효합니다.

캐시를 적용한 경우 : 캐시 시간 초과

• 두 번째 요청에선 캐시를 우선 조회.
• 캐시가 존재하고 아직 60초가 지나지 않아 유효한 캐시라면 해당 캐시에서 데이터를 가져온다.

만약 캐시의 유효시간이 초과한다면 어떻게 될까요?

• 다시 서버에 요청을하고 60초간 유효한 logo.jpg 이미지를 응답받는다.
• 이때 다시 네트워크 다운로드가 발생.

• 응답 결과를 브라우저가 렌더링하면 브라우저 캐시는 기존 캐시를 지우고 새 캐시로 데이터를 업데이트.
• 이 과정에서 캐시 유효 시간이 다시 초기화.

Written with StackEdit.

콘텐츠 협상 헤더

콘텐츠 협상 (contents negotiation)

클라이언트가 선호하는 표현 요청

• 콘텐츠 협상에서 사용하는 헤더
  • 협상 헤더는 요청시에만 사용

Accept-Language 예시

Accept-Language 헤더를 통해 클라이언트가 원하는 언어를 어떻게 서버에 요청할 수 있는지 알아봅시다.

• 한국어 브라우저에서 특정 웹사이트에 접속했을 때 콘텐츠 협상(Accept-Language)이 적용되지 않은 경우 :
  • 서버는 요청으로 받은 우선순위가 없으므로 기본언어로 설정된 영어로 응답.
• 클라이언트에서 Accept-Language로 KO를 작성해 요청 :
  • 서버에서는 해당 우선순위 언어를 지원할 수 있기 때문에 한국어로 된 응답을 돌려줌

Accept-Language 복잡한 예시

• 클라이언트는 한국어를 선호해 Accept-Language에 한국어를 요청했지만 서버는 한국어를 지원하지 않으며 기본 언어는 독일어로 설정되어있다.
• 클라이언트는 독일어는 너무 어렵기 때문에 한국어가 안되면 영어로라도 응답을 받기 원한다.

앞의 경우처럼 지원하는 언어를 요청하는 단순한 경우가 아닌 이처럼 서버에서 지원하는 언어가 여러개일때 클라이언트가 최우선으로 선호하는 언어가 지원되지 않는다면 어떻게 해야할까요?

• 협상 헤더에서는 원하는 콘텐츠에 대한 우선순위를 지정할 수 있다.
  • Quality-Values (q) 값을 사용
  • 0 ~ 1까지 숫자가 클수록 더 우선순위
  • 생략하는 경우 1로 간주
• 1부터 0까지 우선순위를 부여하면 이를 토대로 서버는 응답을 지원.

이를 이용해 서버에 우선순위 요청을 하게 되면 1순위인 한국어를 서버에서는 지원하지 않지만 2순위인 영어를 지원하기에 서버에서는 우선순위에 있는 영어를 독일어보다 클라이언트가 선호하기에 영어로 응답을 주게됩니다.

Written with StackEdit.

요청(Request)에서 사용되는 헤더

1. From : 유저 에이전트의 이메일 정보

• 일반적으로 잘 사용하지 않음
• 검색 엔진에서 주로 사용
• 요청에서 사용

2. Referer : 이전 웹 페이지 주소

• 현재 요청된 페이지의 이전 웹 페이지 주소
• A → B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청
• Referer 를 사용하면 유입경로 수집 가능
• 요청에서 사용
• referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐

3. User-Agent : 유저 에이전트 애플리케이션 정보

• 클라이언트의 애플리케이션 정보 (웹 브라우저 정보, 등등)
• 통계 정보
• 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• 요청에서 사용

  user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36

4. Host : 요청한 호스트 정보(도메인)

• 요청에서 사용

• 필수 헤더

• 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해

• 하나의 IP 주소에 여러 도메인이 적용됬을 때 호스트 정보를 명시하기 위해

  

5. Origin : 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄

• 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생
• 응답 헤더의 Access-Control-Allow-Origin와 관련

6. Authorization : 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더

• 토큰의 종류(e.g. Basic) + 실제 토큰 문자 전송

  Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

응답(Response)에서 사용되는 헤더

1. Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

• 응답에서 사용

  Server: Apache/2.2.22 (Debian) Server: nginx

2. Date : 메시지가 발생한 날짜와 시간

• 응답에서 사용

  Date: Tue, 15 Nov 1994 08:12:31 GMT

3. Location : 페이지 리디렉션

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
• 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
• 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스

4. Allow : 허용 가능한 HTTP 메서드

• 405(Method Not Allowed)에서 응답에 포함

  Allow: GET, HEAD, PUT

5. Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

• 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음

  Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기) Retry-After: 120(초 단위 표기)

Written with StackEdit.