IT's 잡탕찌개 블로그

앞서 Proxy Server와 비슷한 역할을 하지만 반대 방향으로 일을 진행한다고 생각하면 쉽다.

Reverse Proxy란

. Proxy Server가 여러 Client로부터 받은 요청을 중계하여 Server에 요청을 하는 것이라면, 

Reverse Proxyt Server는 Client로부터 받은 요청들을 여러 Server에 중계해주는 역할을 한다.

 - 즉, LAN->WAN을 중계하는것이 proxy / WAN->LAN을 중계하는 것이 reverse proxy

그렇다면 reverse proxy만의 특징은 무엇이 있을까

. Client요청을 Server에 전달하기 전, 또는 응답하기 전에 전후처리를 할 수 있다.

. URL마다 호출하는 서버를 지정할 수 있으며, 동적 contents를 전달하는 서비스(ex: SPA)의 경우 

트래픽을 적절히 분산할 수 있으며 서비스 개발, 유지보수가 쉬워진다.

위키백과에는 다음과 같이 서술되어 있다.

https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%EC%84%9C%EB%B2%84

Proxy server란 client가 자신을 대신하여 다른 network service에

간접적으로 접속할 수 있게 해주는 System 혹은 Computer를 의미한다.

proxy server를 통한 요청과정은 간단하게 아래와 같이 이루어진다.

[ 정확히는 Front Proxy Server이지만 보통 Proxy Server라고 부르면 Front Proxy Server를 의미한다. ]

. client가 특정 service에 대한 url을 요청

. 해당 요청이 proxy server에 전달됨.

. proxy server가 해당 요청을 확인 후 특정 service에 전달 및 응답 수신

. 해당 응답을 client에 전달.

위의 과정을 client 가 직접하는 것이 아닌 proxy server를 통해 수행하는 이유는 무엇일까?

당연히 proxy server를 통해서 얻는 이점이 있기 때문이고 해당 이점은 아래와 같다.

. 특정 요청에 대한 결과를 캐싱함으로써 응답에 걸리는 시간을 줄일 수 있다.

 - 예를 들어 특정 url로 GET을 여러번 요청하는 경우 캐싱된 내용을 전달함으로써 시간 단축

 - 캐싱된 내용을 전달하는 경우 Service에 불필요한 연결을 줄일 수 있다.

 - 또한 이로인해 전체 네트워크의 트래픽이 주어들기 때문에 네트워크 병목현상도 줄어든다.

. Client가 Proxy server를 거침으로써 자신의 IP를 숨길 수 있다. 

. 필요에 따라서 접속을 Proxy Server를 통해서 우회할 수 있다.

. 즉, Proxy Server를 통한 요청의 경우 LAN->WAN의 요청을 대리하는 경우라고 볼 수 있다.

VPN과  Proxy server의 차이

. Proxy Server의 경우 Data의 암호화를 하지는 않는다.

. VPN의 경우 보안처리된 터널을 통해 Data를 주고 받기 때문에 보안이 유지된다.

HTTP란?

. Hyper Text Transfer Protocol의 약자.

. Internet에서 Data를 주고 받을 때 사용하는 Protocol의 일종

. 비연결성이라는 특징이 있으며 Socket은 TCP socket을 사용한다.

 -> HTTP 통신은 요청 -> 응답 과정이 끝나면 연결이 끊기기 때문.

 -> HTTP 1.1부터 keep-alive header를 통해서 연결을 유지하는 것이 가능해졌다.

. Stateless이다.

 -> 연결을 유지하지 않기 때문에 Server는 Client를 식별하지 못한다.

 -> 이를 해결하는 방법으론 쿠키사용, 세션, OAuth, JWT등 여러 방법이 있다.

. Server와 Client의 통신이 평문(ASCII)으로 이루어 진다.

각 HTTP 요청에 대한 주요 응답 코드는 아래와 같다.

100 ~ 109 : 메세지 정보

200 ~ 206 : 요청 성공

300 ~ 305 : Redirection

400 ~ 415 : Client Erorr

500 ~ 505 : Server Error

HTTP Method의 종류

. POST

 - Server에 Data정보를 입력하는 요청인 경우 주로 사용

. GET

 - Server에 특정 Data에 대한 조회를 요청하는 경우 주로 사용

. PUT

 - Server가 요청을 통해 URI에 따른 Data 생성 혹은 갱신 시 주로 사용

. DELETE

 - Server에 특정 Data, Resource의 삭제를 요청할 때 주로 사용

. HEAD

 - Get과 유사하지만 Server는 응답 시 Header정보만 응답한다.

 - Client가 Header 정보만 필요로 하는 경우 사용

간단하게 OSI 7계층과 TCP/IP 4계층에 대해서 알아보자.

7계층 : 물 - 데 - 네 - 전 - 세 - 표 - 어 

위처럼 외우면 편하다.

물리계층

 - 전기 신호를 아날로그 신호로 변경한 후 전송, 수신한 아날로그 신호를 전기 신호로 변환.

데이터 링크 계층

 - MAC주소

 - Frame 단위로 전송하며 header/payload 로 구성된다.

 - EtherNet을 통한 LAN 구성

네트워크 계층

 - WAN 구성.

 - IP주소로 구분, IPv4, IPv6로 나뉨

 - 라우터를 통한 패킷 전달.

 - host 간의 논리적 통신 담당.

전송계층 

 - TCP/IP Protocol

 - Application간의 논리적 통신을 담당.

세션 계층

 - 사용자 위주의 논리적인 연결 서비스 제공

어플리케이션 계층

 - 최상위 계층으로 사용자의 응용 서비스가 돌아간다.

 - SMTP, FTP 등등 

원론적으로는 위의 7계층이지만 때에 따라 4계층으로 구분하기도 한다.

TCP/IP 4계층의 경우 OSI 참조 모델을 상업적이고 실무적으로 이용할 수 있게 단순화 한 모델이다.

. 네 - 인 - 전 - 어

네트워크 계층

 - 실제 Data인 Frame 전송을 담당.

 - EtherNet 구축

인터넷 계층

 - Data 전송을 위한 논리적인 주소 및 경로 지정하며 Packet 전송을 담당

 - IP, ARP 등

전송계층

 - host간의 자료를 송,수신하며, Segment 전송을 담당

 - TCP/UDP와 port번호를 관리

어플리케이션 계층

 - Application간의 data 송수신을 담당

 - P2P, FTP, SMTP, DNS 등등

7계층과 4계층의 대응관계

. 물리계층 + 데이터 전송계층 => 네트워크 계층

. 네트워크 계층 => 인터넷 계층

. 전송 계층 => 전송계층

. 세션 계층 + 표현계층 + 어플리케이션 계층 => 어플리케이션 계층

로드 밸런싱이란 기본적으로 부하를 분산하는 것을 말한다.

로드밸런서의 종류는 크게 두가지로 나뉜다.

 . 운영체제 로드 밸런서

    -> 물리적인 프로세서간에 작업을 스케줄링을 통해서 분산 시킨다.

        -> ex : 멀티코어 프로세서

 . 네트워크 로드 밸런서

    -> 백엔드에서 네트워크 작업을 스케줄링을 통해 분산 시킨다.

네트워크 로드 밸런서

 . L2

    -> Mac 주소를 바탕으로 로드 밸런싱하는 방법

 . L3

    -> IP 주소를 바탕으로 로드 밸런싱하는 방법

 . L4

    -> 전송계층에서 로드 밸런싱하는 방법

    -> port 기반으로 스위칭을 지원하며 주로 라운드 로빈 방식을 사용한다.

 . L7

    -> 응용 계층에서 로드밸런싱을 하는 방법

load balancing 알고리즘

 . round robin

 . least connection

 . weighted least connections

 . faster response time

 . adaptive

 . fiexed, hashing 등등 여러 알고리즘이 존재.

Round robin (순차 방식)

 . 요청의 순서대로 각 서버에 균등하게 분배하는 방식

 . 서버 connection 수나 응답시간에 상관없이 모든 서버를 동일하게 처리한다.

 . 타 알고리즘에 비해 단순하여 속도가 가장 빠르다.

Least connecntion (최소 접속 방식)

 . 서버에 연결되어 있는 Connection 개수만 갖고 단순 비교하여 가장 적은 곳에 연결해준다.

Weighted Least Connections (가중치 최소 접속 방식)

 . 각 서버별 가중치를 정하고 가중치 대비 Connection 이 가장 적은곳에 연결해준다.

Fastest Response Time (응답 우선 방식)

 . 가장 빨리 응답하는 서버에 연결해준다.

Adaptive (최소 대기 방식)

 . Open 또는 Pending 상태인 Connection을 적게 지닌 서버로 연결시켜준다.

출처 및 참고 : https://medium.com/@pakss328/%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C%EB%9E%80-l4-l7-501fd904cf05

https://nesoy.github.io/articles/2018-06/Load-Balancer

ps : 위 두 출처에 다른 포스팅도 유용하니 추후에 공부 더 할 것.

일단 아래와 같이 몆번 중얼거리면 순서 및 구성은 외우기 쉽다.

물데네전세표어, 네인전어

각각 7계층, 4계층을 순서대로 앞글자만 따온것인데 각각에 대해서 알아보자.

OSI 7계층

물리 <-> 데이터 링크 <-> 네트워크 <->전송 <-> 세션 <->표현 <-> 어플리케이션

TCP/IP 4 계층

네트워크 엑세스 <->인터넷 <-> 전송 <-> 어플리케이션

우선 두 종류의 계층도의 관례는 아래 그림과 같다.

그렇다면 굳이 두 계층이 구분되어 있는 이유와 차이점은 무엇일까?

OSI 7계층

 . ISO에 의해서 정의되었다.

 . 계층 구조를 지니끼 때문에 각 구간별로 데이터의 흐름을 알 수 있다.

 . 각 구간별로 트러블 슈팅 자체가 용이하며 각기 다른 벤더사와의 호환성도 해결될 수 있다.

TCP/IP 4계층

 . 현재 인터넷에서 컴퓨터들이 서로 정보를 주고 받는데 사용되는 프로토콜의 모음이다.

 . 하드웨어, 운영체제, 접속 매체에 관계없이 동작할 수 있는 개방성을 가진다.

두 계층의 차이

 . TCP/IP 계층은 OSI 계층보다 먼저 개발되었다.

   -> 따라서 위 그림처럼 정확히 일치하지는 않는다.

 . 두 계층 모두 계층형이긴 하지만 TCP/IP의 경우 지속적인 표준화로 신뢰성이 우수하지만 OSI 7계층은 표준이긴 하되 실제적으론 적은 구현으로 인해 신뢰성이 다소 낮다.

 . OSI 7계층은 장비 개발, 통신 자체에 대한 표준으로 사용되지만, 실제 통신 자체는 보통 TCP/IP를 사용한다.

OSI 7계층 세부 설명

 . 물리계층

    -> 전송단위 : Bit

    -> 물리적, 전기적인 인터페이스 사이의 전송을 위해 필요한 기능 및 처리 절차를 규정한다.

 . 데이터 링크 계층

    -> 전송단위 : Frame

    -> 물리계층에 신뢰도를 더하기위한 흐름제어 및 오류제어를 담당한다.

    -> 노드와 노드 사이의 Data를 전달한다.

 . 네트워크 계층

    -> 전송단위 : Packet

    -> 송신측부터 목적지까지의 패킷 전송을 담당한다.

    -> 정확하고 안전한 전송을 위해서 Routing 기능을 사용한다.

    -> 상위 계층의 data를 작은 크기의 Packet으로 분할하여 전송한다.

    -> IP주소를 통해 목적지를 구분한다.

 . 전송 계층

    -> 전송단위 : Segment

    -> 전송 계층은 해당 Segement를 수신 프로세스까지의 전달을 담당한다.

    -> Port 번호를 통해서 수신 프로세스를 구분한다.

    -> 물리 ~ 전송계층까지를 하위 계층, 이후를 상위 계층으로 구분하기도 한다.

 . 세션 계층

    -> 전송단위 : Message

    -> 실제 응용 프로그램 사이에서 세션이라 불리는 연결을 확립하고 유지하며, 동기화 기능을 제공한다.

    ->표현계층에서 전송한 데이터를 효율적으로 관리하기 위해서 짧은 데이터 단위로 나눈 후 전송계층에 전달한다.

 . 표현 계층

    -> 전송단위 : Message

    -> 송수신자가 공통으로 이해가능한 데이터로 바꿔준다.

    -> 응용계층으로부터 받은 데이터의 보안과 효율적인 전송을 위해 암호와 및 압축을 한 후 세션 계층으로 보낸다.

 . 어플리케이션 계층

    -> 전송단위 : Message

    -> 최상위 계층으로 원격파일 전송등의 사용자 인터페이스를 제공한다.

TCP/IP 계층

 . 네트워크 액세스 계층

    -> 물리, 데이터 링크 계층에 해당한다.

    -> 하드웨어 적인 요소와 관련된 모든 것을 지원한다.

    -> 송신 시 상위계층이 보낸 패킷에 MAC 주소가 담긴 헤더를 추가한 후 프레임을 만든다.

 . 인터넷 계층

    -> OSI 7계층의 네트워크 계층에 해당된다.

    -> 상위 전송계층이 보낸 데이터에 IP 헤더를 붙여 IP 패킷으로 만든 후 전송한다.

 . 전송계층

    -> OSI 7계층에서 전송계층에 해당한다.

    -> 송수신 호스트 사이에서 신뢰성있는 전송기능을 담당한다.

    -> 시스템의 논리주소, port를 가지고 있고 상위 계층의 프로세스를 연결해서 통신한다.

    -> 전송 시 TCP 프로토콜, UDP 프로토콜을 이용한다.

    -> 정확한 전송보다 빠른 전송이 필요할 시 UDP 프로토콜이 좀더 유용하다.

 . 어플리케이션 계층

    -> OSI 7계층의 세션, 표현, 어플리케이션  계층에 해당한다.

    -> 각 어플리케이션들이 네트워크 서비스를 이용할 수 있도록 표준 인터페이스를 제공한다.

출처 및 참고 : https://goitgo.tistory.com/25

Thrift를 현재 회사에서 사용하고 있는데 생각외로 문서나 포스팅이 없어서 간단하게 포스팅을 해본다

우선 Thrfit란 무엇인가?

thrift는 facebook에서 개발하고 현재는 Apache 재단에 의해서 관리, 개발되고 있는 라이브러리이다.

거두절미하고 장점과 단점을 말해보면,

우선 장점으로는 각기 다른 개발언어의 프로그램끼리 공통 RPC를 통해 통신할 수 있다는 점이 있고

반면 단점으로는 RPC관련 생성파일들의 코드가 매우 지저분하다는 점이다.

비슷한 RPC관련 라이브러리로 Google Protocol Buffer 라는게 있는것 같은데 여기서는 다루지 않겠다.

해당 라이브러리 다운로드 주소 : https://thrift.apache.org/download

위 주소에 가면 thrift-0.13.0.tar.gz 파일과 Thrift compiler for Windows (thrift-0.13.0.exe) 파일을 다운로드 받을 수 있다.

thrift-0.13.0 파일의 경우 압축을 해제해보면 tutorial 폴더 외 여러 폴더가 보이는데 우리는 C#만 사용할 것이기 때문에 

thrift-0.13.0\lib\csharp\src 에 있는 파일들을 별도 프로젝트에 복사해 사용할 것이다.

thrift-0.13.0.exe 파일의 경우는 xxx.thrift 문서 파일에 명시된 정보들을 통해 RPC와 관련된 파일을 생성해준다.

 
struct SharedStruct {
  1: i32 key
  2: string value
}
 
 
 service RPCTest
 {
 	i32 sendPing(),
    void sendPing2(),
    oneway NotiTest(),
 }

위 처럼 단순 struct부터 RPC인 service, 한방향 호출 RPC[리턴값이 oneway인 것] 까지 필요에 맞게 정의하면 된다.

그리고 thrift.exe 파일의 경우 우리가 추가적으로 thrift-0.13.0\compiler\cpp\compiler.sln을 통해서

추가타입 혹은 코드 변경을 통해서 커스터마이징 후 빌드하여 사용할 수 있게 되어 있다.

해당 exe 파일을 실행 시 매개변수로 몆가지 명령어를 같이 넣어줄 수 있는데

-out, --gen 명령어만 알아두어도 기능 테스트에는 충분할 것이다.

우선 -out 의 경우 우리가 thrift에 정의한 RPC 규격에 대한 cs파일이 위치할 폴더의 경로를 지정할 수 있다.

ex : -out ..\..\thrift\RPC

--gen의 경우 해당 RPC규격파일에 따른 코드를 생성 하기 위해서 어떠한 언어인지, 참고할 thrift 파일은 어디에 있는지를 지정해준다.

ex : --gen csharp:async .\TestRPC.thrift

Tip - 

해당 thrift.exe. 파일의 경우 일일히 cmd 창등을 통해 실행하기 귀찮기 때문에 bat파일을 활용하면 좋다.

참고 출처 : https://skibis.tistory.com/310

RabbitMQ란 AMQP을 기반으로 만들어진 프로그램이다.

RabbitMQ와 관련된 주요 용어는 아래와 같다.

producer : 메세지를 보내는 App

publish : Producer가 메세지를 보내는 것

Queue : 메세지를 저장하는 버퍼, Queue는 Exchange에 Binding 된다.

Consumer : 메세지를 수신하는 App

 - 동일 업무를 처리하는 Consumer는 보통 한개의 Queue를 본다.

 - 여러 Consumer가 같은 Queue를 볼 때 자동으로 메세지가 분배되서 전달된다.

Subscribe : Consumer가 메세지를 수신하기 위해 Queue를 실시간 리스닝 하도록 한다.

Exchange : Producer가 전달한 메세지를 Queue에 전달하는 역할을 한다.

 - 메세지가 Queue에 직접 전달되지 않고 exchange type에 정의한 대로 동작한다. 

ExchangeType : type에는 fanout, direct, topic, header 4가지가 존재한다.

Binding : Exchange와 Queue를 연결해주는 작업

Routing : Exchange와 Queue에 메세지를 전달하는 과정을 의미한다.

RoutingKey : Exchange와 Queue가 binding 될 때 Exchange가 Queue에 메세지를 전달할지 여부를 결정한다.

Exchange를 별도로 명시하지 않은 경우, RabbitMQ의 기본적인 흐름은 아래와 같다.

1. Producer가 메세지를 생성하여 전송.

2. Queue가 이 메세지들을 순차적으로 쌓는다.

3. Consumer가 Queue에 대한 Biunding을 가지고 있다가 메세지를 Queue에서 수신한다.

메세지의 분배 [ Round - robin Dispatching ]

RabbitMq는 Consumer가 병렬처리를 쉽게 할 수 있도록  같은 Queue를 바라보고 있는 Consumer에게 균등 분배한다.

즉, 첫 메세지는 Consumer1, 두번째 메세지는 Consumer2에게 주는 식으로 중복처리되지 않게 자동 분배를 해준다.

 - 이 특징을 통해서 RabbitMQ는 수평적 확장이 용이하다.

공평한 분배 [ Fair dispatch ]

여러 consumer에게 round robin을 통해 메세지를 균등하게 전달하지만 완전한 균등은 아니다.

이 때 Busy한 서버에게 메세지가 계속 전달되지 않도록 prefetchCountㄹ하는 개념을 사용한다.

prefetchCount가 1일 때는 아직 sck를 받지목한 메세지가 1개라도 존재 시,

해당 Consumer에게 메세지를 할당하지 않는다.

[prefetchCount는 해당 Consumer의 동시 처리가능한 메세지 갯수를 의미하는 듯]

메세지 수신 통보 [ Acknowledgement ]

많은 프로토콜이 메세지 전달 보장을 위해서 Acnowledgement( ACK ) 라는 개념을 사용해서

메세지에 대한 응답을 보내주도록 되어 있다.

ACK의 중요성은 메세지가 확실히 처리되었는지를 확인할 수 있게 해주며 ACK가 온 메세지에 한해서만

Queue에서 삭제를 진행하기 때문이다.

Consumer 중 일부가 죽었을 시 대응방법

ACK가 오지 않는 Consumer가 존재 시(Disconnect등의 경우) 해당 메세지를 다음 Consumer에게 할당한다.

RabbitMQ가 죽었을 경우 대응 방법

RabbitMQ는 Queue에 메세지를 보관하고 ACK를 받은 경우에만 메세지를 Queue에서 삭제한다.

Consumer가 죽었을 시 메세지를 보존할 수 있지만 RabbitMQ가 죽은 경우는 어떻게 해야할까

RabbitMQ가 죽는다면 Queue에 있는 메세지들 역시 날아가 버릴 것이다.

이 경우에 대한 대비책은 메세지들을 Queue에 저장 시 File에도 기록하는 것이다.