IT's 잡탕찌개 블로그

HTTP Header 란?

http header란 http 통신에서 client와 server가 요청 또는 응답에 부가적인 정보를 전송할 수 있도록 해준다.

Header 는 대소문자를 구분하지 않는 key값, 그에 대응되는 value값으로 이루어져 있다.

header는 4가지 분류로 구분할 수 있는데 아래와 같이 그룹화 할 수 있다.

. generic header

 - 요청, 응답에 모두 적용되지만 message body 와는 관계없는 header

. request header

 - 패치될 resource나 client 자체에 대한 정보를 포함하는 헤더

. response header

 - 위치 또는 server 자체에 대한 정보와 응답에 대한 부가적인 정보를 포함하는 헤더

. entity header

 - 컨텐츠 길이나 MIME 타입과 같이 Entity body에 대한 자세한 정보를 포함하는 헤더

대표적인 Header의 종류[Request]

. Host : 요청하려는 서버 호스트의 이름과 포트번호

. User-agent : client의 프로그램 정보

. Referer : 바로 직전에 머물렀던 web irl 주소 [ 경우에 따라서 null 일 수도 있다.]

. Accept : client가 처리 가능한 미디어 타입 종류 정보

. Accept-charset : client가 지원 가능한 언어 계열

. Accept-encoding : client가 지원 가능한 언어 encoding

. Content-location : 해당 개체의 실제 위치

. Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에서 시작되는지 나타내는 값

. Cookie : 쿠키 값

대표적인 Header의 종류[Response]

. Location : redirect시 이동해야할 url 이 담겨있다.

. Server : web server의 종류

. Age : max-age 시간 내에서 얼마나 흘렀는지 초단위로 알려주는 값.

참고

 - https://hazel-developer.tistory.com/145

 - https://developer.mozilla.org/ko/docs/Web/HTTP/Headers

이번 포스팅에서는 MSA를 설계할 때 고려해야할 것들, 주의할 점등에 대해서 알아보자.

MSA의 설계 철학
. service의 크기는 작아야한다.
. test 및 자동 배포를 하여 유지보수 부담을 낮춰야 한다.
. 각 작업자는 자신의 코드영역만 작업할 수 있어야 한다.
. 각 service는 유연하고 회복력이 있게 구성되어야 하며, 해당 service만으로도 완전해야 한다.
. 각 service는 구분되며 이에 필요한 기술스택은 다양할 수 있다.

위의 설계 철학에 따른 구조를 위 그림과 같다고 할 수 있을 것이다.
일부 시스템은 단일 서비스로 구현되고 어떠한 시스템은 여러 service에 분산 될 수 있다.
분산되는 service의 경우 HTTP를 통해 통신하거나 Kafka와 같은 메세지 브로커를 비동기식으로 사용해 구현될 수 있다.
그렇다면  MSA 적용시 어떠한 점들을 고려해야 할까?
우선 우리의 프로젝트가 과연 MSA를 적용하는것이 옳은지 생각해봐야한다.
만약 MSA를 적용하기에 비효율적으로 복잡하거나 런타임 시 결합이 긴밀할 것으로 생각된다면 MA를 적용하는 것이 좋을 수 있다.
MSA를 적용하기로 했다면 이제 분산 작업을 설계할 차례이다.
MSA를 사용할 때 우리는 service를 분산시킬 것이며, 이는 각 service가 고유 DB를 지닌다는 얘기가 된다.
이로인해 DB에 대해 어떻게 접근할 지를 고려해야 하며 DB와 관련된 여러가지 문제가 발생할 수 있다. 해결책으로는 아래 이미지의 여러 패턴을 적용하는 것이 있지만 이 내용은 다소 분량이 커서 다른 포스팅에서 다루기로 한다.

DB외에도 고려해야 할 점은 또 있다.
우선 service를 구분하는 범위에 대한 기준을 정해야 한다.
단순히 A service로 묶을지 혹은 A의 기능인 A`와 A``를 개별 service로 묶을지에 대한 기준이다.
이러한 기준은 비즈니스 혹은 해당 서비스에 따라서 달라질 수 있다.
그 외에도 service내에서 API를 어떻게 설계할지, 또는 service간의 종속성과 배포 용이성, 장애 대응을 어떻게 할지 등등 고려해야할 점이 많다.


참고 -
https://microservices.io/patterns/microservices.html https://ko.m.wikipedia.org/wiki/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

MA란 무엇인가?
Monoilithic Architecture의 경우 전통적인 개발 방식으로 하나의 프로젝트 속에 여러 기능을 모두 포함한다.

MA의 특징
MA의 경우 기능이 모듈별로 쪼개지는 것이 아니기 떄문에 하나의 프로젝트에 전체 APP이 다 포함된다.
이러한 구조로 인해서 기능, 모듈이 추가될 때마다 프로젝트가 커지게 된다.

MA의 장점
아무래도 구조등을 고민할 필요가 적어 초기에 개발하기가 편하다.
더불어 모든 기능이 같은 내부에 존재하기 때문에 별도의 통신이 없이 다른 기능을 직접 사용할 수 있다.  

MA의 단점
시간이 지나 프로젝트 규모가 커질수록 유지보수 규모와 비용이 커지며 확장이 점점 힘들어진다.
그외의 사소한 기능 수정임에도 전체 App을 재기동해야하는등의 단점이 존재한다.

MSA 란 무엇인가?
msa(micro service architecture)란 MA에 반대되는 개념으로
여러개의 작은 service로 구성되어 각 service가 독립적으로 개발 되고 배포되는 구조를 의미한다.

MSA 의 특징
MSA는 MA와 달리 각 기능별로 독립적으로 배포 및 개발이 되기 때문에 전체적으로 시스템이 분산되어 있다.
이로 인해서 각 기능별로 개발, 배포가 독립적으로 가능하며 MA에 비해서 규모 및 기능을 확장하기가 쉽다.
또한 유지보수가 용이하다.

MSA의 장점
각 service간의 독립성으로 인해서 확장성과 유연성이 높아진다.
가령 cloud 환경에서 특정 기능에 부하가 몰리는 경우 해당 기능과 관련된 instance 규모만 확장하면 된다.
또한 각 service가 구분되어 있기 때문에 일부 service의 장애가 다른 service에 영향을 끼치지 않는다.

MSA의 단점
반면 MSA 역시 단점이 존재하는데 각 service가 독립되어 있기 때문에 service간의 통신을 고려해야한다.
이로 인해서 각 service와의 연결구조 및 관리가 다소 복잡해진다.
추가로 초기 구조 세팅에 소모되는 비용이 다소 크다.

MSA가 적용된 예
MA의 경우 프로젝트 크기가 별로 크지 않을때 많이 적용되며 반대로 MSA의 경우 대규모 프로젝트에 적합하다.
간단하게 게임분야의 경우 login server와 lobby server, battle server, guild server 등으로 구분하여 service를 구현하는 경우도 MSA로 볼 수 있을 것이다.