작심삼일ing

HTTP (HyperText Transfer Protocol) 특징

• 클라이언트 서버 구조
• 무상태 프로토콜 (Stateless)
• 비 연결성 (Connectionless)
• 단순함, 확장가능

Stateless ?

Stateful과는 반대로 서버에서 클라이언트의 상태를 저장하지 않는 것을 말합니다.

Stateless 구조에서 서버는 단순하게 요청에 대해 응답을 하는 역할만 하고, 세션 관리는 Client에게 있습니다.

즉, 서버의 응답이 클라이언트의 세션 상태와 독립적입니다.

따라서, 이러한 Stateless 구조는 Client와의 세션 정보를 서버에 저장하지 않습니다. 다만, 필요에 따라 DB에 저장하며 관리할 수 있습니다.

아래와 같이 응답할 수 있는 서버 3개가 있고 중계서버(LoadBalancer 역할)가 있는 구조를 살펴보겠습니다.

로그인과 같은 세션관리가 필요한 서비스에 대한 요청이 서버1에 들어왔다고 가정해보겠습니다.

Stateful 구조에서는 서버에 세션 정보를 저장했지만, Stateless 구조에서는 서버에 세션 정보를 저장하지 않고 DB에 저장합니다.

따라서 클라이언트1의 요청이 어떤 서버로 전달되던지 클라이언트1 정보에 접근할 수 있습니다.

이렇게 서버에서 세션 정보를 관리하지 않기 때문에 로드밸런서가 최초 서버로 계속 연결되도록 신경 쓸 필요가 없고

Scale-out에 유리합니다. (Stateful 같은 경우에는 최초 서버와 연결 되도록 해야하고 Scale-out시 세션정보를 옮겨주는 부가적인 작업 필요)

대표적인 Stateless 프로토콜로 HTTP, UDP가 있습니다.

비연결성 (Connectionless)

HTTP는 서버에서 클라이언트와의 연결을 계속 유지하는게 아니라 데이터를 주고 받으면 연결을 종료하는 모델입니다.

일반적으로 초 단위 이하의 빠른 속도로 응답하기 때문에 서버 자원을 효율적으로 사용할 수 있습니다. (연결 유지 X 때문에)

비연결성 (Connectionless) 한계 와 극복

• TCP/IP 연결을 새로 맺어야 한다 - 3 way handshake 시간 추가
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS, css, 추가 이미지 등 수 많은 자원이 함께 다운로드된다 (이때마다 다시 연결)
• 자원을 보낼 때마다 연결을 반복하는 것은 비효율적이기 때문에 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결한다.

참고 :

인프런 : 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한 

https://5equal0.tistory.com/entry/StatefulStateless-Stateful-vs-Stateless-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%99%80-HTTP-%EB%B0%8F-REST

URI (Uniform Resource Idenfier) ? 

URI는 단어 뜻대로 리소스를 나타내는 유일한 식별자를 말합니다. 그리고 URI는 URL, URN 두 종류가 있습니다.

여기서 Resource는 html 파일, text 파일, 이미지 파일 등 같은 정적 컨텐츠 뿐만 아니라 은행장고, 장바구니 같은 요청에 따라 결과값이 달라지는 동적 컨텐츠도 포함합니다.

URL (Umniform Resource Locator) ?

URL은 특정서버의 리소스에 대해 위치를 나타낸 것입니다..

아래는 URL 포맷입니다.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

• scheme : 프로토콜을 나타냅니다. (ex. http, https, ftp 등)
• userinfo : URL에 사용자정보를 포함해서 인증
• host       : 호스트명(도메인명 또는 IP 주소를 직접 사용)
• PORT     : 접속 포트
• path       : 리소스 경로   (ex. /manage/post)
• query     : key=value 형태로 웹서버에 제공하는 파라미터 (ex. ?q=hello&hl=ko)
• fragment : html 내부 북마크 등에 사용하는 것으로 서버에 전송하는 정보는 아닙니다. 

URN (Uniform Resource Name) ?

urn:example:animal:ferret:nose <- 처럼 실제로 리소스에 주소가 아닌 이름을 부여하는 것입니다.

URL은 리소스의 위치가 이동하게 되면 URL이 더이상 유효하지 않게 됩니다.

하지만 URN은 위치를 표현한게 아니라 이름을 부여한 것이기 때문에 리소스를 옮기더라도 찾을 수 있어야합니다.

그렇게 되려면 Name을 넣었을 때 리소스 결과가 나오도록 매핑이 되어있어야하는데 이게 보편적이지 않고 어려워서 잘 사용하지 않습니다.

Git에 Push 이벤트 발생시 자동으로 Jenkins 빌드까지 했으니 이번 포스팅에서는 Jenkins에서 EC2 서버 자동배포까지 해보겠습니다.

1. Jenkins SSH 설치

EC2 서버 배포를 위해 Jenkins 관리 -> 플러그인 관리에서 Publish Over SSH를 설치합니다.

2. SSH 연결 서버 정보 입력

Jenkins 관리 -> 시스템 설정에서 배포할 서버 정보를 입력해 줍니다.

정보를 모두 입력했다면 Use password authentication, or use a different key 를 체크해줍니다.

그리고 고급을 눌러서 EC2를 생성할 때 받은 pem 키를 열어서 해당 값을 Key 부분에 전부 넣어줍니다. 

마지막으로 Test Configuration을 눌러서 Success 가 나오는 것을 확인하고 저장합니다.

만약 Success가 나오지 않는다면 위에 입력한 정보가 맞는지, 배포할 EC2 서버에 SSH(22) 포트가 열려있는지 확인해야합니다.

2. Build 스크립트 작성 

Jenkins 프로젝트 -> 구성에 들어가서 빌드 스크립트를 작성해줍니다.

저는 배포 후 수행할 스크립트를 프로젝트에서 관리하도록 했기 때문에 deploy 폴더를 생성해 jar, 스크립트 파일을 SSH로 전송하도록 작성했습니다.

3. 배포 후 실행할 스크립트 작성

위에 언급한 것처럼 프로젝트에서 scripts 폴더 생성 및 delpoy.sh 이라는 스크립트를 작성했습니다.

#!/bin/bash

REPOSITORY=/home/ubuntu/test
PROJECT_NAME=jenkins-springboot

echo ">>> Build 파일 복사"

cp $REPOSITORY/deploy/*.jar $REPOSITORY/

echo ">>> 현재 구동중인 애플리케이션 pid 확인"

CURRENT_PID=$(pgrep -fl jenkins-springboot | grep java | awk '{print $1}')

echo ">> PID : " $CURRENT_PID

if [ -z "$CURRENT_PID" ]; then
  echo "구동중인 애플리케이션 없음."
else
  echo ">>> kill -15 $CURRENT_PID"
  kill -15 $CURRENT_PID
  sleep 10
fi

echo ">>> 애플리케이션 배포"

JAR_NAME=$(ls -tr $REPOSITORY/*.jar | tail -n 1)

echo ">>> JAR NAME : $JAR_NAME"

chmod +x $JAR_NAME

echo ">>> $JAR_NAME 실행"

nohup java -jar \
    -Dspring.config.location=classpath:/application.properties \
    $JAR_NAME > $REPOSITORY/nohup.out 2>&1 &

배포가 완료되면 자동으로 deploy.sh 이 실행되어 스프링부트가 실행되는 것을 확인할 수 있습니다.

참고 :

https://wellbell.tistory.com/9?category=976634