흔적 노트

1. 마이크로서비스에 대해 설명해보세요.

하나의 어플리케이션을 이루는 서비스들을 기능 단위로 쪼개서 구축하는 것을 말합니다.

기존의 모놀로식 아키텍처의 문제점은, 하나의 서비스에 트래픽이 몰리면 그 쪽만 확장하면 되는데 이 단위 별로의 확장이 불가능하고, 일부 서비스의 오류가 전체 서비스에 영향을 준다는 것이었습니다.

마이크로 서비스를 채택하면, 일부 서비스가 장애가 있으면 해당 서비스만 내려가고, 나머지엔 영향이 없으며 시즌별로 트래픽이 몰리는 서비스쪽만 확장이 가능하다는 장점이 있습니다.

그리고 각 서비스마다 더 적절한 언어나 기술을 사용할 수 있다는 점도 있습니다.

단점은 모놀로식 아키텍처에 비해 구축 난이도, 개발 및 테스트가 어렵다는 단점이 있습니다.

1. Stomp가 뭔가요?

Stomp는 Simple Text Oriented Messaging Protocol의 약자로,

Websocket 위에서 동작하는 텍스트 기반 메세징 프로토콜입니다.

Stomp는 Publish-Subscribe 매커니즘을 제공합니다.

Broker를 통해 다른 사용자들에게 메시지를 보내거나 서버가 특정 작업을 수행하도록 메세지를 보낼 수 있습니다.

2. WebSocket 대신 Stomp를 사용하는 이유가 뭔가요?

각 커넥션마다 WebSocketHandler를 구현하는 것보다 Controller Annotation이 적용된 객체를 이용해 조직적으로 관리를 할 수 있습니다. ( 메세지를 Controller 객체의 MessageMapping Annotation으로 라우팅시킬 수 있습니다. )

Stomp의 Destination(URI 경로)를 기반으로 Spring Security를 적용해 메세지를 보호할 수 있습니다.

정리

Stomp는 Websocket 위에서 동작하는 텍스트 기반의 메세지 전송 프로토콜입니다.

메세지를 Controller 어노테이션이 적용된 객체를 이용해 조직적으로 관리할 수 있으며 Spring Security를 적용해 메세지를 보호할 수 있습니다.

간단하게만 정리해보았는데 좀 더 자세하게 알아야 할 것 같습니다 ㅠ 추후에 정리 한번 다시 하겠습니다

참조:

https://velog.io/@koseungbin/WebSocket#stomp

1. CORS에 대해서 설명해보세요.

CORS란, (= Cross Origin Resource Sharing )

서로 다른 도메인간에 자원을 공유하는 것을 의미하며 기본적으로 차단되어있습니다.

Origin이란 출처를 의미하며 Protocol + Host + Port 를 합친 것을 말합니다.

Origin이 같으면 CORS 에러는 발생하지 않습니다.

예를 들어 아래 개발 환경은 포트가 다르기때문에, Origin이 다른 것으로 판단되어 자원 요청 시 CORS 에러가 발생합니다.

http://localhost:8080

http://localhost:8000 

2. CORS 에러 해결 방법은 뭔가요?

서버에서 응답 헤더에 특정 헤더를 포함하는 방식으로 해결할 수 있습니다.

Access-Control-Allow-Origin: 특정 브라우저가 리소스에 접근이 가능하도록 허용합니다.

Access-Control-Allow-Method: 특정 HTTP Method만 리소스에 접근이 가능하도록 허용합니다.

Access-Control-Expose-Headers: 자바스크립트에서 헤더에 접근할 수 있도록 허용합니다.

credentials: 쿠키 등의 인증 정보를 전달할 수 있습니다.

# 정리

CORS란 서로 다른 Origin간에 자원을 공유하는 것을 말하며 기본적으로 브라우저간에 차단되어있습니다.

Origin이란 출처를 말하며, Protocol + Host + Port 를 합친 것을 의미합니다.

CORS 에러는 서버에서 응답 헤더에 특정 헤더를 포함하는 방식으로 해결할 수 있습니다.

예를 들어 Access-Control-Allow-Origin을 통해 특정 브라우저가 리소스에 접근이 가능하도록 허용할 수 있습니다.

감사합니다.

참조:

https://beomy.github.io/tech/browser/cors/

안녕하세요. 오늘은 REST 에 대해서 알아보겠습니다.

REST란, (=REpresentational State Transfer)

자원을 URI를 통해 명시하고, Method를 통해 해당 자원에 대한 행위를 정의하는 것을 의미합니다.

쉽게 말해서 Resource를 HTTP Method를 통해 처리하도록 설계된 아키텍처를 말합니다.

아래 표를 보면 이해가 쉽게 됩니다.

REST는 아래와 같은 구성 요소로 이루어져있습니다.

자원: URI

행위: HTTP Method

표현: Message(Json, XML 등을 이용한 표현)

REST를 사용하는 이유는 HTTP 표준을 기반으로 구현되며 메세지가 의도하는 바를 쉽게 파악할 수 있다는 점입니다.

그리고 다양한 브라우저와 디바이스에서도 통신을 해야하며 어플리케이션을 분리 및 통합하기 위해 사용됩니다.

REST API란,

REST 기반으로 서비스 API를 구현한 것을 말합니다.

API란 라이브러리 제공을 통해 프로그램간에 특정 기능을 호출할 수 있는 명세를 의미합니다.

REST API를 사용하는 이유는 REST는 HTTP 표준을 기반으로 구현하므로,  HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있습니다.

REST API의 설계 규칙은 다음과 같습니다.

1. URI로 자원을 표현한다.

2. Method로 자원에 대한 행위를 표현한다.

3. 슬래시(/)는 계층 관계를 나타낸다.

4. URL 마지막에 / 사용을 금지한다.

5. 언더바(_) 대신 하이픈(-)을 사용한다.

6. URI 경로에는 소문자를 사용한다.

7. 파일의 확장자는 URI 에 포함하지 않는다.

REST에 대해서 알아보았습니다.

Microservice에서도 보통 Rest API로 통신하기때문에 설계를 한 번 해보는 것이 좋은 것 같습니다.

참조:

https://velog.io/@stampid/REST-API%EC%99%80-RESTful-API

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

안녕하세요.

오늘은 웹 통신에 사용되는 프로토콜인 HTTP에 대해서 알아보겠습니다.

HTTP이란, ( = Hyper Text Transfer Protocol )

1. 웹에서 데이터를 주고받기 위해 사용되는 프로토콜입니다.

2. 상태가 없는 스테이트리스(Stateless) 프로토콜입니다.

3. TCP/IP 프로토콜 위에서 동작하며 80번 포트를 사용합니다.

- 여기서 TCP/IP 프로토콜이란, 인터넷에서 사용되는 표준 프로토콜입니다. 서로 다른 시스템을 가진 기기들을 연결하여 데이터를 전송하기 위해 사용됩니다.

[ HTTP Request와 Response ]

Client가 Server로 데이터를 요청하는 것을 HTTP Request, 

Server가 Client로부터 받은 요청에 따라 이에 대한 응답을  HTTP Response라고 합니다.

요청을 보내는 쪽을 Client, 요청을 받고 이에 대한 응답(데이터)를 반환하는 쪽을 서버라고 합니다.

[ HTTP의 구조 ] 

HTTP Request의 구조는 크게 3부분으로 구성됩니다.

• Start line
• Headers
• Body

아래 명령어를 통해 HTTP 요청을 보내보았을 때, 다음과 같은 HTTP Request와 Response를 확인할 수 있었습니다.

curl -v http://localhost:8000/test

> GET /test?a=1 HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/7.55.1
> Accept: */*
>

여기서 아래 부분을 HTTP Request의 startline이라고 합니다.

> GET /test?a=1 HTTP/1.1

Startline은 HTTP Method + Request Target + HTTP Version 으로 이루어져있습니다.

HTTP Method란,

해당 Request의 자원에 대한 행위를 정의하며 종류로는 GET, POST, PUT, DELETE 등이 있습니다.

예를 들어 GET은 자원을 얻는 것, POST는 등록을 목적으로 사용합니다.

Request Target이란,

해당 Request의 목표 URI를 의미합니다. 여기서 URI란 인터넷의 자원을 칭하는 통합 고유 자원 식별자를 말합니다.

그리고 아래 부분을 HTTP Request Headers라고 합니다.

> Host: localhost:8000
> User-Agent: curl/7.55.1
> Accept: */*

Header는 Request에 대한 추가 정보를 담고있습니다. 자주 사용되는 header의 정보는 다음과 같습니다.

Host: 요청이 전송되는 Target의 Host URL을 말합니다.

User-Agent: 요청을 보낸 클라이언트의 정보를 말합니다.

Accept: 해당 타입의 Response를 보내달라고 요청합니다.

Content-Type: Request의 body 타입을 말합니다.

Content-Length: 메세지 Body의 길이를 말합니다.

Authorization: JWT 같은 인증 토큰을 서버로 보낼 때 사용하는 헤더입니다.

그리고 지금은 비어있지만, 해당 Request의 내용이 위치하는 Body가 있습니다.

아래는 HTTP Response의 구조입니다.

< HTTP/1.1 200
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 9
< Date: Sun, 05 Sep 2021 07:26:31 GMT
<
HTTP test* Connection #0 to host localhost left intact

구조는 거의 동일하지만, 정보가 조금씩 다릅니다.

# StartLine

HTTP Version + Status Code + Status Text 로 이루어져있습니다.

Status Code: 응답 코드로, 200은 성공을 의미합니다.

Status Text: 응답 코드에 대한 메세지로, 200이면 OK가 담겨있습니다.

# Header

Date: 응답 일시

Content-type: 응답 데이터의 타입

HTTP에 대해서, 그리고 구조에 대해서 알아보았습니다.

참조:

https://programmer93.tistory.com/60

안녕하세요.

특정 시점을 기준으로 독립적으로 진행할 수 있는 Branch에 대해서 알아보겠습니다.

개념보다는 실습을 할 것이고, 이전 포스팅과 이어집니다.

저번에 first text를 commit 하여 기록하였습니다.

branch를 이용하면 이 Commit 시점을 기준으로 독립적으로 작업을 진행할 수 있습니다.

second branch를 생성하여, second branch로 작업을 한다고 명령어를 입력했습니다.

기존 first.txt에는 45645 가 저장되어있습니다.

first.txt의 내용을 1+1=2로 변경했습니다.

second branch에서 해당 내용을 Commit했습니다.

log 를 확인하면, second branch로 Commit된 이력을 확인할 수 있습니다.

master branch로 변경하고, first.txt를 확인해보면 second에서 commit한 1+1=2가 아닌 master에서 commit 했던 내용이 유지되는 것을 확인할 수 있습니다.

여기서 또 third branch를 생성해서 또다른 작업을 독립적으로 진행할 수 있겠죠.

해당 branch의 작업을 master branch로 병합하는 작업을 merge라고 합니다.

git merge bracn이름

second branch의 작업을 병합하고나서, first.txt를 확인해보면 내용이 변경된 것을 확인할 수 있습니다.

branch에 대해서 실습해보았습니다. 확실히 사용을 해봐야 이해도 잘 되는 것 같습니다.

감사합니다.

안녕하세요~ 오늘은 Git에서 사용되는 명령어에 대해서 알아보겠습니다.

이전 글에서 개념을 어느정도 확립하고 실습하는 것도 괜찮고 실습 하면서 이런 기능이구나 하면서 이론을 보는 것도 괜찮을 것 같습니다.

# Git 명령어 정리

 git init

 1. 로컬 저장소 선언을 하는 명령어입니다.

원하는 폴더로 이동 후 로컬 저장소를 생성하면 됩니다.

 git remote add 원격저장소이름지정 원격저장소주소

2. 로컬 저장소를 원격 저장소에 연결합니다.

지정한 원격 저장소의 이름으로 push 작업을 하게됩니다.

 git add .
 -- 해당 폴더의 모든 파일을 Index에 등록
 
 or
 
 git add 파일명

3. Index에 Commit할 파일을 등록합니다.

Index에 등록한 파일들만 Commit할 때 저장됩니다.

git branch
-- branch 목록 확인

git branch 브랜치이름
-- branch 생성

git checkout 브랜치이름 
-- branch 변경

4. branch를 설정합니다.

처음에는 존재하지 않으며 master branch로 커밋됩니다.

git commit -m "커밋 메세지 작성"

5. 인덱스에 등록한 파일들을 시점으로 기록합니다.

git log

5. commit 이력을 확인합니다.

git push 원격저장소이름 branch이름

6. 특정 branch로 해당 원격 저장소에 업로드합니다.

# 테스트 실습

1. 다음과 같이 Git의 로컬 저장소를 만들고 싶은 폴더로 이동 후, 위의 명령어를 통해 git 로컬 저장소를 생성합니다.

2. 생성한 Github의 원격 저장소의 주소를 통해 원격 저장소와 연결합니다.

저는 test란 이름의 원격 저장소를 연결했습니다.

3. Index에 업로드할 파일을 등록합니다.

4. 로컬 저장소에 이 시점을 commit 합니다.

5. Commit 이력을 확인합니다. master branch로 Commit 된 것을 확인할 수 있습니다.

6. 이제 master branch가 생긴 것을 확인할 수 있습니다.

Local 저장소에 Commit을 한 것이기때문에 아직 원격 저장소에는 업로드가 안된 모습을 확인할 수 있습니다.

7. master branch의 작업을 push합니다.

8. github에서 master branch의 Commit이 업로드된 것을 확인할 수 있습니다.

Git의 명령어에 대해 실습해보았습니다.

다음은 branch를 이용해 특정 시점을 기준으로 독립적으로 작업을 진행하는 것을 확인해보겠습니다.

안녕하세요. 오늘은 git에 대해서 알아보겠습니다.

Git이란,

소스 코드를 효율적으로 관리하기 위해 만들어진 "분산형 버전 관리 시스템" 입니다.

원래는 Linux 소스코드를 관리할 목적으로 만들어졌습니다.

Git을 사용하는 이유는, 다음과 같습니다.

1. 소스 코드의 변경 이력을 쉽게 확인 가능합니다.

2. 특정 시점에 저장된 버전과 비교하거나 특정 시점으로 되돌아갈 수 있습니다.

그러면 Git이라는 시스템을 이용해서 저장되는 저장소. 즉 Repository에 대해서 알아보겠습니다.

말 그대로 파일이나 폴더를 저장해두는 곳으로, Local 저장소와 Remote(=원격) 저장소로 나뉩니다.

• Local Repository: 나의 PC에 저장되는 개인 전용 저장소
• Remote Repository: 원격 저장소 전용 서버에 저장되는 저장소

예를 들어 철수와 짱구가 같이 작업물을 만든다고 했을 때, css를 짱구가 html을 철수가 맡게 된다고 한다면

html은 철수의 로컬 저장소에서 철수가 작업을 완료한 후 push라는 작업을 통해 원격 저장소에 업로드를 하고,

css는 짱구의 로컬 저장소에서 짱구가 작업을 완료한 후 push라는 작업을 통해 원격 저장소에 업로드가 되게 되면

원격 저장소에 html, css가 합쳐져서 하나의 작업물이 만들어지게 됩니다.

# Commit 

커밋이란, 변경 사항을 로컬 저장소에 기록하는 것을 말합니다.

# Index 

git에서는 Commit을 하기 전에 그 사이의 공간인 "인덱스"라는 공간에 파일의 상태를 기록하게 되어있습니다.

그 이유는 철수가 first.html과 second.html을 생성하고 작업하고있는데, 짱구가 작업한거 올려달라고 했을 때

second.html은 작업이 덜되어 first.html만 올리고 싶을 때! 이 때 필요한게 Index입니다.

자신이 로컬 저장소에서 변경/작업한 파일 중 선택하는 작업을 "Index에 등록"한다고 표현합니다.

# Branch

Branch는 일련의 작업을 독립적으로 만들기 위한 개념입니다.

특정 시점(마지막 Commit)에서 여러가지 작업을 해야할 때, 여러 작업을 동시에 진행할 수 있게 해줍니다.

개인적으로 Git에서 가장 중요한 개념이라고 생각합니다

예를 들어

철수는 게시판을 만들고 난 이후에, 게시판에 첨부파일을 첨부할 수 있는 기능을 작업하고있었습니다.

그런데 갑자기 게시판 등록 로직에 오류가 발생하여 빠르게 수정해달라는 요청을 받았습니다.

첨부파일 기능은 완료되지 않아서 오래걸리는데, 해당 로직을 다 삭제하고 초기로 돌아가서 작업을 해야할까요?

아닙니다.

Branch를 이용해, 첨부파일을 작업하는 Branch와 로직의 버그를 수정하는 Branch로 나눌 수 있습니다.

Master Branch(관리자 Branch)를 기준으로, attchBranch를 만들고 작업을 하고 있었다면 작업을 하던 도중 Commit을 하고 Master Branch로 돌아가서 bugBranch를 만들어서 작업하면 됩니다.

-> Master Branch로 돌아가면 마지막 master Brnach의 Commit 시점으로 파일들이 변경되기때문에 타 Branch의 작업과 독립적으로 작업할 수 있습니다. 첨부파일의 작업은 모두 attachBranch에 저장되어 있습니다.

Branch는 직접 해보시는게 이해가 빠를겁니다!

저도 이해가 안되서 커뮤니티에 질문하려다가 직접해보니 바로 이해됐다는... 알고보니 신세계 ㄷㄷ

# Push

원격 저장소에 Commit 내용을 업로드하는 것을 말합니다.

Git을 사용을 해보니 VMware의 스냅샷과 같이 사용할 수 있어서 편리했던 경험이 있습니다.

버전을 비교하면서 수정할 수 있는 것도 장점으로 느껴졌습니다.

다음엔 실습 과정을 업로드하겠습니다.

참조: 

https://backlog.com/git-tutorial/kr/intro/intro1_1.html

정말 잘 정리되어있는 튜토리얼입니다. 이 글도 참고하세요~ 

안녕하세요. 오늘은 마이크로서비스의 Service Discovery 역할을 하는 Eureka Server에 대해서 알아볼까 합니다.

Eureka Server란, 

AWS와 같은 Cloud 시스템에서 로드 밸런싱과 실패 처리 등을 유연하게 처리하는 서버입니다.

MSA의 핵심 원칙 중 하나인 Service Discovery의 역할을 수행합니다.

Service Discovery란, 어떤 서비스가 특정 서비스를 호출할 때 특정 서비스의 위치(IP, Port)를 알려주는 역할을 말합니다.

MSA에서는 Service의 IP 및 Port가 지속적으로 변화하기 때문에 정보를 수동으로 입력하는 것은 비효율적입니다.

Eureka Server의 동작 과정은 다음과 같습니다.

1. Eureka Client들은 본인의 정보 ( IP, Port, AppName 등 )을 Eureka Server로 전달합니다.

2. Eureka Server에서 필요한 Client의 정보를 Fetch하여 통신합니다.

Eureka Client는 등록되면 30초를 주기로 Eureka Server에 heartbeat를 보냅니다.

만약 90초동안 heartbeat를 받지 못하면 Server가 저장한 해당 Client의 정보가 제거됩니다.

"등록된 서비스들의 정보를 담고 있는 서버로, 서버들 사이에서 로드밸런싱 역할을 한다" 라고 알고 있으면 될 것 같습니다.

아래 참조 글을 거의 참조했으니 참고하시길 바랍니다.

참조:

https://sabarada.tistory.com/61?category=822738

안녕하세요~ 오늘은 MSA 에 대해서 글을 작성해보겠습니다.

MicroService가 발생하게 된 배경은 보통의 프로젝트 형태인 Monolithic Architecture는 프로젝트 규모가 커질수록, 빌드 시간이 길어지고 유지보수가 힘들다는 특징이 있습니다. 이를 보완하기 위해서 MicroService의 형태가 발생하게 되었습니다.

MicroService란,

어플리케이션을 이루는 서비스들을 기능 단위로 쪼개서 구축하는 것을 말하며 각 서비스들은 REST API를 통해 통신합니다.

장점

1. 수정 사항 및 추가사항이 있는 서비스만 빌드, 배포가 가능합니다.

2. 해당 서비스에 더 적절한 서로 다른 언어나 기술을 사용할 수 있습니다.

단점

1. 모니터링이 힘들고, 개발 및 테스트가 까다롭습니다.

2. 모놀로식에 비해 구축 난이도가 어렵습니다.

보통의 프로젝트 형태인 Monolithic Architeture의 형태는 다음과 같습니다.

MicroService와 반대되는 개념으로, 하나의 서버에서 모든 서비스가 동작하는 것을 말합니다.

장점

1. 아키텍처가 단순하고 모든 서비스의 개발환경이 같아 개발이 용이합니다.

2. End-to-End Test(사용자 입장에서의 테스트)가 용이합니다.

단점

1. 조금만 수정해도 전체를 다시 빌드하고 재배포해야 합니다.

2. 프로젝트 규모가 커짐에 따라 빌드 시간이 증가하고 유지보수가 힘듭니다.

3. 일부 서비스의 오류가 전체 서비스에 영향을 줍니다.

MicroService에 장점만 있는건 아니기 때문에, 상황에 따라 적절하게 서비스를 구축해야합니다.

MSA를 사용하는 대표적인 기업으로는 아마존과 Netflix가 있습니다.

넷플릭스는 2007년 데이터 베이스 손상으로 인해 3일간 서비스 장애를 겪고 나서 고가용성, 유연한 확장성, 빠르고 쉬운 배포 의 장점을 가진 MSA 구조를 채택했습니다. 이 과정에서 경험한 노하우 및 문제 해결 방법을 오픈소스로 공개했습니다.

​

# Spring Cloud

Spirng Cloud는 Springboot를 기반으로 MSA 구축에 특화된 라이브러리들의 집합입니다. Spring Cloud에는 Eureka, Zuul(springboot 2.4? 2.5 부터 지원안함> Spring Cloud Gateway로 대체) , Histrix, Ribbon 등 많은 넷플릭스 OSS(Open Source Software) 가 통합되어 있습니다.

​

# Eureka - Service Discovery Server

MSA를 이루는 서비스들은 동적으로 확장 및 축소되는데, 이 인스턴스의 상태를 동적으로 관리하는 서버를 말합니다.

새로운 서비스 인스턴스는 시작될 때 IP, 포트번호 등을 스스로 전송합니다. 이로 인해 운영자들은 서비스를 수평 확장할 때 IP를 신경쓸 필요가 없게됩니다.

​

# Zuul - API GateWay

API 게이트웨이는 사용자의 Request에 맞는 서비스로 라우팅시켜주는 역할을 합니다. Client 와 Server의 중간다리역할을 한다고 생각하면 됩니다. 사용자에게는 API GateWay만 노출되게 됩니다.

이유로는 적절한 사용자의 요청인지 확인하는 인증, 각 서비스에 대한 요청을 로그로 기록하는 로깅, 요청사항을 구분하는 필터 등을 통해 모든 요청에 대한 관리를 수월하게 하기 위해 필요합니다.

​

# Ribbon - Client Side Load Balancer

Ribbon은 Cilent에 탑재하는 소프트웨어 로드밸런서입니다.

​

# Hystrix - Circuit Breaker

특정 서비스에 과부화가 걸려 장애가 발생하면, 전체 서비스에 장애를 전파하는 경우가 있습니다. 이와 같은 현상을 막아주는 역할을 하는 것이 서킷 브레이커입니다. Hystrix는 각 서비스의 오류 상태 및 복구 상태, 오류 내용을 파악하며 장애가 발생하면 통신을 즉시 중단시키고 문제가 발생한 서비스를 격리시킵니다. 문제가 해결될 때 까지 호출을 제한합니다.

또한 정해진 시간내에 호출이 실패하면 대신 동작하는 예외 처리인 Fallback을 지원해 시스템 장애로부터 유연하게 대처할 수 있습니다.

MicroService에 대해서 알아보았습니다. 감사합니다.

참고한 사이트

https://wonit.tistory.com/497?category=854728

https://www.samsungsds.com/kr/insights/msa_and_netflix.html

​

​