희연's 개발 일기장

1. 컨테이너 기술이란?
- 모놀리스 애플리케이션에서 MSA 으로 독립적 배포가 가능해지면서 발생한 관리 및 종속성 문제 해결
- 격리된 실행 환경 제공, 호스트 OS 에서 독립된 프로세스로 실행되어 자원 소비 및 오버헤드 최소화

2. 도커란?
- 컨테이너 기술을 사용해서 애플리케이션을 패키징, 배포, 실행하기 위한 오픈 소스 플랫폼
- 도커 파일로 이미지를 빌드하고, 이미지로 컨테이너를 실행한다.

3. 도커 파일, 도커 이미지, 도커 컨테이너의 개념은 무엇이고, 서로 어떤 관계입니까?
- 도커 파일(Dockerfile)
    - 도커에서 이미지를 생성하기 위해 작성하는 파일.
    - 컨테이너 설정을 정의한 것
- 도커 이미지(Docker Image)
    - 실행 가능한 컨테이너의 빌드된 상태
    - 애플리케이션을 실행하기 위한 모든 환경을 포함한다.
- 도커 컨테이너(Docker Container)
    - 도커 기반 컨테이너 이미지에서 생성된 리눅스 컨테이너
    - 실행 중인 컨테이너는 도커를 실행하는 호스트에서 실행되는 프로세스
    - 호스트와 호스트에서 실행 중인 다른 프로세스와 격리되어 있다.

📌GitHub Actions 실습

CI/CD 란?

• CI : Continuous Integration
  • 지속적인 통합
  • 코드, 빌드, 테스트 부분을 자동화해서
  • 커밋할 때마다 빌드와 자동 테스트로 동작을 확인해서 문제가 생기지 않도록 보장한다.
  • 개발에 더 많은 시간을 투자 가능
• CD : Continuous Delivery / Deployment
  • 지속적인 제공, 배포
  • 배포 자동화 과정
  • CI 프로세스를 통과하면 마지막에 배포하는 과정

GitHub Actions

• Workflow
• Job
• Step
• Action

yaml 파일 예시

name: 'Workflows name'

on: push // on은 script 가 언제 돌아가야하는지에 대한 부분 -> push 가 들어갈 때마다 실행된다.

jobs: // 스크립트가 해야하는 행동
  first-job: // job의 이름이고, 정해진 규칙은 없다.
    name: 'First Job' // name에 지정한 것은 각각 안에서 여러가지 나뉘는데 각각 job에 대한 이름 설정 안하면 위에 셋팅한 이름으로 default

    runs-on: ubuntu-latest // 어느 가상 환경에 올릴 것인지 보통 3가지 - windows mac linux

    steps:
      - name: Say Hello World 1
        shell: bash
        run: |
          echo "Hello World from step 1"

      - name: Say Hello World 2
        shell: pwsh
        run: |
          echo "Hello World from step 2"

• GitHub Actions 관련 문서 링크

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

GitHub Action 요구사항 해결 방안

• OS 종류와 Node 버전이 다양한 경우

-> 매트릭스 빌드 사용

• 빌드할 때마다 테스트 실행이 불편한 경우

-> 템플릿 변경으로 빌드 테스트 분리

• 다른 job에서 빌드 아티팩트 접근이 안되는 경우

-> Built-in 스토리지 이용

매트릭스 빌드

• 각 경우의 수에 맞게 빌드 아티팩트를 만들어서 실행

...
  strategy:
    matrix:
      os: [ubuntu-latest, windows-2016]
      node-version: [12.x, 14.x]
...

• 우분투 12, 14버전
• 윈도우 12, 14버전 실행

빌드, 테스트 분리

• build를 build와 test로 분리

jobs:
  build:
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

jobs:
  build:
  ...
  test:
  ...

job 병렬 실행 -> 종속적으로 실행 시키기

jobs:
  build:
    ...
  test:
    needs: build // 이 부분이 실행되기 위해서는 build job이 필요
    ...

GitHub Actions 요구 사항 해결 방안

• main 브랜치 에러 위험

-> 브랜치 정책 설정

• Pull Request 는 언제 merge?

-> PR 리뷰 강제화

• 늘어나는 Issue 와 PR 관리의 어려움

-> Custom action 으로 라벨링

Branch 정책 설정 방법

• Repo 의 Settings
• Branches 메뉴에서
• Branch protection rules 에 있는 Add rule

• Require pull request reviews before merging
  • 브랜치를 다른 브랜치와 merge 하려고할 때, PR 요청을 통해서 리뷰되어야만 가능
• Require status checks to pass before merging
  • merge 전에 status check 를 통과해야 한다.

실습

• Comment 에 "/close" 커맨드 입력 시 이슈 닫는 워크플로우 작성

name: 'Close Issue Condition Workflows'

on:
  issue_comment: 
    types: [ created ]

jobs: 
  close-issue:
    name: 'Close Issue Job' 
    if: contains(github.event.comment.body, '/close')
    runs-on: ubuntu-latest

    steps:
    - name: Closed Issue
      uses: actions/github-script@v6
      with:
        script: |
          github.rest.issues.update({
            issue_number: context.issue.number,
            owner: context.repo.owner,
            repo: context.repo.repo,
            state: 'closed'
          })

HTTP(HyperText Transfer Protocol)

• HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜
• 웹에서 이루어지는 모든 데이터 교환의 기초
• 클라이언트-서버 프로토콜 : 클라이언트 요청을 생성하기 위해 연결을 연 다음 응답을 받을 때 까지 기다리는 모델
  • 데이터 스트림이 아닌, 개별적인 메시지 교환으로 통신
• request(요청) : 클라이언트(브라우저)에 의해 전송되는 메시지
• response(응답) : 서버에서 응답으로 전송되는 메시지
• 애플리케이션 계층 프로토콜
• 신뢰 가능한 전송 프로토콜을 사용한다. 
  • 주로 TCP TLS(암호화된 TCP) 사용

프록시(Proxy)

• 웹 브라우저와 서버 사이에 있는 많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달한다.
• 애플리케이션 계층에서 동작하는 컴퓨터/머신
• 프록시로 다양한 기능 수행 가능
  • 캐싱
  • 필터링
  • 로드밸런싱
  • 인증
  • 로깅

HTTP 특징

• 간단한 사용 
• 확장 가능 : HTTP 헤더를 통해 확장 가능
• 무상태(Stateless), 세션
  • HTTP 쿠키를 통해 상태가 있는 세션을 만든다.
  • 헤더 확장성을 사용해서 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키 추가

HTTP 통신 과정

1. TCP 연결을 연다. : 요청을 보내거나 응답을 받는 데 사용

2. HTTP 메시지 전송(request)

- HTTP2는 캡슐화되어 직접 읽기 불가능

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr

3. 서버가 보낸 응답을 읽는다.

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

4. 연결을 닫거나 다른 요청을 위해 재사용

HTTP Message 구조

• 시작 줄(start-line) : HTTP 요청 / 요청에 대한 성공 또는 실패
• HTTP 헤더 : 요청에 대한 설명 / 메시지 본문에 대한 설명
• 빈 줄 : 요청에 대한 모든 메타 정보가 전송되었음을 알린다. (헤드와 본문 사이)
• 본문(optional) : 요청과 관련된 데이터(HTML form) / 또는 응답과 관련된 문서가 선택적으로 들어간다.

HTTP Requset

• 클라이언트가 서버로 전달하는 메시지
• request line : HTTP method + url + http version
• header(헤더)
  • request header
    • client의 IP, 사용 언어(accept language), content type(파일 형식), referer(이전 페이지 주소)
  • general header : 메시지 전체에 적용, connection(네트워크 접속 유지할지 유무)
  • entity header : 요청 본문에 적용, content-length(요청과 응답 메시지의 본문 크기)
• request body : query string의 정보

HTTP Resonse

• Status line(Response Line)
  • http/1.1 (프로토콜 버전) + status code 상태 코드(ex.200) + 상태 텍스트(ex.OK)
• response header
  • 결과 데이터에 대한 설명 : Encoding, content-type(MIME(HTML, Image, video), size, server 설명(아파치, 톰캣 등등)
• response body

<HTML>
<HEAD>
<BODY>
...

HTTP Request Method

• GET : 리소스를 받기 위해 사용. URI 형식으로 서버측에 리소스 요청
• POST : 내용 및 파일 전송. 클라이언트에서 서버로 어떤 정보를 제출하기 위해 사용
• PUT : 리소스 갱신. 
• DELETE : 리소스 삭제 -> 실제로는 클라이언트에게 리소스 삭제 권한 X
• HEAD : 메시지 헤더 정보를 받기 위해 사용. 응답 메시지에 Body는 비어있고 header 정보만 받는다.
• CONNECT : 클라이언트와 서버 사이의 중간 경유를 위해 사용. 보통 proxy으로 SSL 통신할 때 사용
• OPTIONS : 서버 측 제공 메소드에 대한 질의를 위해 사용. 웹 서버에서 지원하는 메소드를 알기 위해 사용
• TRACE : 요청 리소스가 수신되는 경로를 보기 위해 사용
• PATCH : 리소스의 일부분을 갱신하기 위해 사용. PUT과 유사하지만 모든 데이터 갱신이 아니라 일부분만 수정할 때 사용

HTTP Status Code

• 응답 상태 코드로 성공/실패 여부 확인
• 10x : 정보 확인
• 20x : 통신 성공
• 30x : 리다이렉트
• 40x : 클라이언트 오류
• 50x : 서버 오류

성공 응답

리다이렉션 메시지

클라이언트 오류

서버 에러 응답

Socket(소켓)

• 두 프로그램이 서로 데이터를 주고 받을 수 있도록 양쪽에 생성되는 통신 단자
• 양방향 통신 : 서버와 클라이언트 양방향 연결이 이루어지는 통신
• 클라이언트도 서버로 요청을 보낼 수 있고, 서버도 클라이언트로 요청을 보낼 수 있다.
  • 실시간 서비스 : 영상 스트리밍, 실시간 채팅
• 웹 소켓 프로토콜 : 최초 연결을 요청할때만 HTTP 프로토콜 위에서 Handshaking 하기 때문에 http hedaer 사용한다.

HTTP

• 파일을 전송하는 프로토콜
• JSON, Image 등등 전송
• 단방향 통신 : 클라이언트가 요청을 보내고 서버가 응답을 하는 방식의 통신

CSRF(Cross Site Request Forgery)

• 웹 애플리케이션 취약점 중 하나
• 인터넷 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(modify, delete, register) 등 특정한 웹사이트에 request 하도록 만드는 공격 기법
• ex. SNS의 광고성 글
• 자동 로그인으로 이런 피싱 사이트에 접속하게 되면서 피해를 입는 경우가 많다.

대응 기법

• 리퍼러(Refferer) 검증
  • 백엔드 단에서 Refferer 검증을 통해 승인된 도메인으로 요청시에만 처리하도록 한다.
  • request header 안에 있는 데이터를 가져와서 referer 값 확인

String referer = request.getHeader("Referer");

• Security Token 사용
  • 사용자의 세션에 임의의 난수 값을 저장하고, 사용자의 요청시 해당 값을 포함하여 전송시킨다.
  • 백엔드 단에서는 요청을 받을 때 세션에 저장된 토큰 값과 요청 파라미터로 전달받는 토큰 값이 일치하는지 검증 과정을 거치는 방법

XSS(Cross Site Scription)

• 웹 애플리케이션 취약점 중 하나
• 관리자가 아닌 권한이 없는 사용자가 웹 사이트에 스크립트를 삽입하는 공격 기법
• 악의적으로 스크립트를 삽입해서 이를 열람한 사용자의 쿠키가 해커에게 전송시키며, 쿠키를 통해 세션 하이재킹 공격을 한다.
• 해커는 세션 ID를 가진 쿠키로 사용자의 계정에 로그인

대응 기법

• 입출력 값 검증 : XSS 필터링 적용 후 스크립트 실행되는지 테스트
• XSS 방어 라이브러리, 확장앱 : 서버단에서 방어 라이브러리 추가 또는 사용자들이 확장앱 설치
• 웹 방화벽 : 다양한 injection 방어 가능
• CORS, SOP 설정 
  • CORS(Cross-Origin Resource Sharing), SOP(Same-Origin-Policy)를 통해 리소스의 Source를 제한하는 것
  • 사전에 지정된 도메인이나 범위가 아니면, 리소스를 가져올 수 없게 제한한다.

API Key

• 서비스 확대로 기능들이 분리되면서, Module이나 Application들간의 공유와 독립성을 보장하기 위한 기능들이 생겨남
• 동작 방식
  • 1. 사용자는 API Key를 발급받는다.
  • 2. 해당 API를 사용하기 위해 Key와 함께 요청을 보낸다.
  • 3. Application은 요청이 오면 Key를 통해 User정보를 확인해서 누구의 key인지 확인
  • 4. 해당 key의 인증과 인가에 따라 데이터를 사용자에게 반환
• 문제점 : key가 유출되면 대비하기 힘들다. -> key 업데이트의 번거로움

OAuth(Open Authorization)

• 인터넷 사용자들이 비밀번호를 제공하지 않고 
• 다른 웹 사이트 상의 자신들의 정보에 대해
• 웹 사이트나 애플리케이션의 접근 권한을 부여할 수 있는 개방형 표준
• 간편 로그인
• API Key 단점 보완
• 사용 용어
  • 사용자 : 계정을 가지고 있는 개인
  • 소비자 : OAuth를 사용해 서비스 제공자에게 접근하는 웹사이트 or 애플리케이션
  • 서비스 제공자 : OAuth를 통해 접근을 지원하는 웹 애플리케이션
  • 소비자 비밀번호 : 서비스 제공자에서 소비자가 자신임을 인증하기 위한 키
  • 요청 토큰 : 소비자가 사용자에게 접근 권한을 인증받기 위해 필요한 정보
  • 접근 토큰 : 인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해 보호 자원에 접근하기 위한 키 값
  • 토큰의 종류
    • Access Token : 만료시간 존재. 다시 요청 가능
    • Refresh Token : 만료되면 다시 처음부터 진행
• 문제점
  • Token이 규칙 없이 발행되기 때문에 증명확인이 필요하다.

인증 과정

1. 사용자가 App의 기능을 사용하기 위한 요청을 보낸다.

2. App은 해당 사용자가 로그인이 되어있는지 확인

3. App은 사용자가 로그인이 되어있지 않으면 사용자를 인증서버로 Redirection

4. 간접적으로 Autorize 요청을 받은 인증 서버는 해당 사용자가 회원인지 인증서버에 로그인 되어있는지 확인

5. 사용자가 최초의 요청에 대한 권한이 있는지 확인(GRANT)

6. 사용자가 Grant 요청을 받게 되면 사용자는 해당 인증정보에 대한 허가를 준다.

7. 인증서버에서 인증과 인가에 대한 과정이 모두 완료되면 App에게 인가코드

8. 인가코드의 유효시간은 짧기 때문에, App은 해당 코드를 Request Token으로 사용하여 인증 서버에 요청을 보낸다.

9. 인증서버는 자신의 저장소에 저장한 코드와 일치한지 확인하고 실제 리소스에 접근하게 될 Access Token 발급

10. 이제 App은 Access Token을 사용해서 업무 처리 가능

JWT(JSON Web Token)

• 토큰 작성에 대한 규약
• 웹 표준으로, 두 개체에서 JSON 객체를 사용하여 가볍고 자가수용적인 방식으로 정보를 안정성 있게 전달
• 인증 여부 확인을 위한 값, 유효성 검증을 위한 값 그리고 인증 정보 자체를 담고 있기 때문에 인증 서버에 묻지 않아도 사용 가능
• 문제점
  • 토큰 자체가 인증 정보를 가지고 있기 때문에 민감한 정보는 인증 서버에 다시 접속하는 과정이 필요하다.

JWT 구성요소

• 3가지 문자열로 구성
• 1. header(헤더) : JWT 서명에 사용된 알고리즘을 담는다. 
  • typ : 토큰의 타입
  • alg : 해싱 알고리즘 
• 2. payload(정보) : 토큰에 담긴 주체들을 담는다. 
  • 토큰을 담을 정보
  • iss : 토큰 발급자 (issuer)
  • sub : 토큰 제목 (subject)
  • aud : 토큰 대상자 (audience)
  • exp : 토큰 만료 시간(expiration)
  • nbf : 토큰의 활성 날짜(Not before)
  • iat : 토큰이 발급된 시간(issued at)
  • jti : JWT 고유 식별자
• 3. signature(서명) : 헤더와 페이로드를 각각 base64로 인코딩하고 콤마로 이어 붙인다. 그리고 헤더에 있는 알고리즘으로 암호화된 값을 담는다.
  • 클라이언트에서 받은 토큰의 데이터 조작 여부를 확인하는 곳 
  • 헤더의 인코딩 값과 정보의 인코딩 값을 합친 후 주어진 비밀키로 해쉬하여 생성한다. (header+payload+salt = hash)
  • 이렇게 만든 해쉬는 base64 형태로 나타낸다.
  • base64 : 8비트 이진 데이터를 문자 코드에 영향을 받지 않는 공통 ASCII 영역의 문자들로만 이루어진 일련의 문자열로 바꾸는 인코딩 방식. 통신과정에서 binary data 손실을 막기 위해 사용한다.

로그인 인증과 JWT

• 유효기간이 짧은 토큰은 사용자 입장에서 자주 로그인을 해야해서 번거롭다.
• 유효기간이 긴 토큰은 편하지만 토큰을 탈취당할 약점이 있다.
• Refresh Token : 위의 단점을 보완하기 위해 사용
  • Access Token의 유효기간이 만료되었을 때, Refresh Token이 새로 발급
  • Refresh Token이 만료되면, 새로 로그인
• 토큰 저장 장소
  • Access Token : 클라이언트(cookie)
  • Refresh Token : 서버(DB)

JWT와 OAuth 2.0의 차이

- 둘 다 인증 방식이라는 공통점이 있지만, 서로 목적이 다르다.

- OAuth 2.0 : 하나의 플랫폼의 권한(아무 의미없는 무작위 문자열 토큰)

다양한 플랫폼에서 권한을 행사할 수 있게 해줌으로써 리소스 접근이 가능하게 하는데 목적을 두고있다.

- JWT는 Cookie, Session을 대신하여 의미있는 문자열 토큰

로그인 세션이나 주고받는 값이 유효한지 검증할 때 주로 사용

아파치 카프카(Apache Kafka)

• 아파치 소프트웨어 재단이 슼라라로 개발하나 오픈 소스 메시지 브로커 프로젝트
• 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표
• 분산 트랜잭션 로그로 구성된, 확장 가능한 pub/sub 메시지 큐로 정의 가능
• 스트리밍 데이터를 처리하기 위한 기업 인프라를 위해 적절하다.

pub/sub 모델(발신자/수신자)

• 발신자 : 카프카에게 토픽(Topic)이라는 주소로 전송하는 역할
• 수신자 : 카프카에게 원하는 토픽을 구독

개발 배경

• 기존 링크드인 데이터 처리 시스템은 각각의 파이프라인 별 dependency가 높았고, 확장하기 어려운 상황이였다.
• 카프카 개발 전 링크드인 데이터 처리 시스템

• 카프카 적용
  • 프로듀서와 컨슈머의 분리
  • 영구 메시지 데이터를 여러 컨슈머에게 적용
  • 높은 처리량을 위한 메시지 최적화
  • 트래픽 증가에 따른 스케일 아웃이 가능한 시스템

카프카 구성 요소

• 프로듀서(Producer) : 메시지를 생산하고, 브로커의 토픽으로 전달하는 역할
• 컨슈머(Consumer) : 브로커의 토픽으로부터 저장된 메시지를 가져오는 역할
• 브로커(Broker) : 카프카 내의 서버 또는 노드를 지칭한다. -> 실행된 카프카 서버. 메시지를 저장하고 관리한다.
• 주키퍼(Zookeper) : 분산 어플리케이션 관리를 위한 코디네이션 시스템
  • 분산된 노드 정보(메시지 큐의 메타 정보) 중앙 처리 및 구성 관리, 동기화 등을 수행한다.

카프카 동작 방식

• 프로듀서는 메시지를 카프카에 전달한다.
• 전달된 메시지는 브로커의 토픽(Topic)이라는 구분에 의해 저장된다.
• 컨슈머는 구독한 토픽에 접근하여 pull 방식으로 가져온다.

카프카의 특징과 장단점

• 특징과 장점
  • 디스크에 메시지를 저장해서 영속성(persistency) 보장
  • 프로듀서와 컨슈머 분리로 멀티 프로듀서와 멀티 컨슈머 지원 -> pub/sub 구조의 확장성
  • 메시지 배치 처리가 가능해서 네트워크 오버헤드 감소
  • 높은 성능과 고가용성, 확장성 : 일부 노드가 죽어도 다른 노드가 일을 지속
  • 메시지 보장 여부 선택 가능
• 단점
  • 직접 통신이 아니기 때문에 잘 전달됬는지 파악 X
  • 중간 메시징 플랫폼을 거쳐서 전달 속도가 상대적으로 느리다.

쿠키(Cookie)

• 인터넷에 접속할 때 웹 사이트가 있는 서버에 의해 사용자의 컴퓨터에 저장되는 정보
• 주로 로그인 정보, 장바구니 정보를 저장한다.
• 쿠키와 다르게 캐시는 사운드, 이미지 파일을 일시적으로 저장해서 로딩을 빠르게 하는 것
• 기존에 쿠키는 암호화가 되지 않았지만, 최근에는 암호화가 이루어져서 과거처럼 매우 낮은 보안성을 가지지 않는다.
• 쿠키는 최적화 프로그램으로 자주 삭제하거나 브라우저의 자동 삭제 기능을 사용한다.
• 쿠키를 차단할 수 있지만, 차단하면 사이트가 동작하지 않을 수 있는 단점이 있다.

세션(Session)

• 쿠키를 기반으로 일정 시간동안 같은 브라우저로부터 들어오는 요구를 하나의 상태로 보고 그 상태를 유지하는 기술
• 쿠키는 클라이언트
• 세션은 웹 서버에 저장
• 둘 이상의 통신 장치나 컴퓨터와 사용자 간의 대화나 송수신 연결상태를 의미하는 시간대
• 세션은 연결상태 유지보다, 안정성이 더 중요하다.

쿠키 vs 세션

• 쿠키
  • 클라이언트에 저장, 파일로 관리되기 때문에 브라우저의 종료와 상관없이 만료시간까지 존재
  • 관련 정보들이 쿠키 내부에 존재해서 빠른 속도 
  • 클라이언트가 서버로 요청을 보낼 때 요청 메시지를 스나이핑 당할 위험이 있다.
• 세션
  • 서버에 저장되어 브라우저 종료 혹은 세션 만료시간 이후 삭제된다.
  • 관련 정보들이 서버에 저장되서 느린 속도를 가진다.
  • 세션은 쿠키를 통해 세션 Id만 저장하고 나머지 정보는 서버에 처리해서 상대적으로 보안성을 갖고 있다.

저장 위치 

• 쿠키 : 클라이언트의 웹 브라우저가 지정하는 메모리나 하드디스크
• 서버 : 서버의 메모리

만료 시점

• 쿠키 : 저장할 때 expires 속성을 정의한다.
• 세션 : 클라이언트 로그아웃 or 설정 시간 -> 정확한 시점을 알 수 없다.

리소스

• 쿠키 : 클라이언트에 저장, 서버 자원 사용 X
• 세션 : 서버에 저장, 서버 메모리에 로딩되고 세션이 생길 때마다 리소스 차지

용량 제한

• 쿠키 : 쿠키로 인해 문제가 발생하는 것을 방지하고자 한 도메인당 20개, 한 쿠키당 4KB
• 세션 : 클라이언트가 접속하면 서버에 의해 생성된다. -> 제한 없음

만약 로드밸런서와 세션을 사용한다면?

• 세션은 서버에 저장된다. 
• 여러 서버가 분산되어 있고, 로드밸런서를 사용할 때 세션은 공유되지 않는다.
• 클라이언트가 로그인을 위해 서버A에 요청을 보내면 서버 A의 세션 저장소에 저장된다.
• 클라이언트가 서비스를 이용하기 위해 서버B에 요청을 보내면 서버 B에는 해당 클라이언트의 세션 정보가 없기 때문에 로그인 페이지로 리다이렉트 하는 문제 발생
• 해결 방법
  • Sticky Session
    • 첫 요청에 대한 응답을 준 서버에게 sticky하게 붙어서 이후의 모든 요청들을 해당 서버로만 보내는 방법
    • 단점 : 로드 밸런성 효율 저하
  • Session Clustering(세션 클러스터링)
    • 여러 대의 서버를 하나의 서버처럼 운영한다. 각 서버의 세션 저장소를 하나로 묶어서 관리한다.
    • 모든 서버가 동일한 세션을 공유하게 되기 때문에 하나의 서버가 죽어도 세션 정보를 잃어버릴 위험이 없어진다.
    • 단점 : 모든 세션 저장소 업데이트, 메모리 필요 -> 성능 저하
  • Session Server
    • 세션만 관리하는 별도의 서버를 두는 방식
    • 모든 서버의 업데이트 필요 X, Redis같은 In-memory(인메모리) 데이터 저장소를 사용해서 빠른 세션 조회 가능
    • 단점 : 하나의 세션 서버로 관리하기 때문에 서버가 죽으면 모든 세션 데이터를 잃어버린다.
      • 하지만 레디스를 사용하면 다른 서버의 메모리에 실시간으로 복사본을 저장하거나 디스크에 직접 저장하여 백업 가능
      • Master-Slave 형식으로 서비스 유지 가능
      • 단점 : 데이터 별도 저장의 메모리 필요

RESTful API

• 월드 와이드 웹(WWW)와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로
• 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반에 대한 패턴
• REST(Representational State Transfer) 
  • 기본 원칙을 성실히 지킨 디자인을 RESTful 하다고 표현할 수 있다.
  • 하나의 아키텍처로 표현 가능하다.
  • Resource Oriented Architecture : API 설계의 중심에 자원(Resource)이 있고, HTTP Method를 통해 자원을 처리하도록 설계하는 것

URL(Uniform Resource Locator) : 실제 위치, 컴퓨터 네트워크에서 리소스가 어디에 있는지 알려주기 위한 규약 

URI(Uniform Resource Identifier) : 자원의 위치 + 자원에 대한 고유 식별자, 특정 리소스를 식별하는 통합 자원 식별자

REST 구성

• 자원(resource) 
  • 표현 방법 : HTTP URI
  • ex. http://localhost:8080/main
  • 명사로 표현
• 행위(Verb) : 자원의 행위
  • 표현 방법 : HTTP METHOD
  • GET, POST, PUT, DELETE
• 표현(Representations)  : 응답 자원의 상태
  • 표현 방법 : HTTP Message Pay Load
  • ex. JSON, XML

REST 6가지 원칙

• Uniform Interface(유니폼 인터페이스)
  • URI으로 지정한 리소스에 대한 조작을 통일되고, 한정적인 인터페이스로 수행하는 아키텍처 스타일
  • HTTP 표준만 맞으면, 어떤 기술도 가능하다.
    • REST API 정의가 HTTP + JSON 이면, 어떤 언어에 종속되지 않고 모든 플랫폼에 사용 가능
• Stateless(무상태성)
  • 작업을 위한 상태정보를 저장하고 관리하지 않는다. 세션 정보나 쿠키 정보를 관리 X
  • Request만 Message로 처리하고, context 정보를 신경쓰지 않아도 되서 구현 단순
  • API 실행중 실패 발생시 Transaction 복구를 위해 기존의 상태를 저장할 필요가 있다.
  • API 서버는 들어오는 요청만 단순 처리 한다.
• Caching(캐시 가능)
  • REST는 HTTP(기존 웹표준)을 그대로 사용하기 때문에, HTTP가 가진 캐싱 기능 적용을 할 수 있다. 
• Code on demand
  • 서버는 고객에게 실제 실행 가능한 코드를 전송해줄 수 있다.
  • applet이나 스크립트 전송으로 클라이언트의 기능 확장이나 커스터마이즈 가능
• Hierarchical system(계층형 시스템)
  • 다층 계층으로 구성되어, 로드 밸런싱, 보안, 암호화 계층을 추가해 구조상의 유연성을 얻을 수 있다.
• Client-Server 구조
  • REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조
  • 각각의 역할이 확실하게 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간의 의존성이 줄어들게 된다.

RESTful API 디자인

• 리소스와 행위를 명시적이고 직관적으로 분리
  • 리소스(URI)가 가리키는 것은 명사로 표현
  • 행위는 HTTP Method로 표현 - GET(조회), POST(생성), PUT(수정), PATCH(일부 수정), DELETE(삭제)
• Message는 Header와 Body를 명확하게 분리해서 사용
  • Entity는 Body에 담아 사용
  • 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입은 header에 담아 사용
    • MIME 유형 : Content-Type
  • header, body는 http header와 http body로 나눌 수 있다.
  • http body에 들어가는 json 구조 분리 가능
• API 버전 관리
  • 하위 호환성 보장
• 서버와 클라이언트가 같은 방식으로 사용해서 요청
  • 브라우저는 form-data 형식으로, 서버에서는 Json 형태로 보내지 않고 하나의 형태로 통일한다.
• URL에 케밥케이스(kebab-case) 사용

[GET] /userInfo
[GET] /user_Info

[GET] /user-Info

• Path Variable에 카멜케이스(camelCase) 사용

[GET] /user/{user_id}

[GET] /user/{userId}