부트캠프

프로토콜 , 로드밸런싱 , 헬스체크

한우종 2024. 10. 31. 18:12
전송 계층 프로토콜
전송 계층 프로토콜은 컴퓨터 네트워크에서 데이터 전송을 관리하고 제어하는 역할을 하는 프로토콜입니다. 주로 TCP/IP모델의 전송 계층에 해당하며 두 가지 주요 프로토콜로 TCP(전송 제어 프로토콜) , UDP(사용자 데이터그램 프로토콜) 이 있습니다.

*TCP/IP : 컴퓨터 사이의 통신 표준 및 네트워크의 라우팅 및 상호연결에 대한 자세한 규칙을 지정하는 프로토콜 스위트입니다.

TCP는 연결 지향 프로토콜로 데이터 전송 전에 송신자와 수신자 간의 연결을 설정합니다. 이 때문에 신뢰성이 높고데이터 전송 여부를 확인하며 손실된 패킷은 재전송합니다. 이를 통해 데이터의 무결성을 보장합니다. 또한 TCP는 흐름 제어 기능이 있어 송신자의 전송 속도가 수신자의 처리 속도를 초과하지 않도록 조절합니다. 마지막으로 데이터가 전송된 순서대로 수신되도록 보장합니다.이러한 특성 덕분에 TCP는 웹 브라우징,이메일,파일 전송등 신뢰성이 중요한 애플리케이션에 주로 사용됩니다.

 

  • TCP 이해하기
이 TCP는 사람간에 대화 라고 생각하면서 이해를했는데 대화를 하기위해서 같은 공간에서 만나야 하듯이 TCP도 데이터 전송전에 연결을 수립합니다.(연결지향)

대화를 할때 상대방이 듣지 못하거나 문제가 생긴다면 "다시 말해주세요" 라고 요청을 하듯이 TCP는 데이터가 제대로 전송되었는지 확인하고 손실된 패킷이 있다면 패킷을 재전송합니다.(신뢰성)

또한 대화중 한명이 너무 빠르게 말한다면 상대방은 이해를 못할수 있잖아요? 이럴 경우 잠시 대화를 멈추거나 말의 속도를 조절하듯이 TCP도 송신자의 전송 속도가 수신자의 처리속도를 초과하지 않도록 조절합니다.(흐름제어)

마지막으로 사람이 말을 할때 내뱉을 말의 순서를 생각해야하는데요 예를들어서 "나는 사과를 먹었다." 라고 말해야하는데 "먹었다 사과 나는" 이라고 말하는건 이상하잖아요? 이러지않도록 TCP는 데이터가 전송된 순서대로 수신되도록 보장합니다.(순서보장)

 

  • UDP 이해하기
UDP에 대해 말씀드리면 UDP는 비연결 지향 프로토콜인데요. 데이터를 전송하기 전에 연결을 설정해놓지않기때문에 오버헤드가 적고 빠른 전송이 가능합니다. 하지만 신뢰성이 낮아 데이터의 전송 성공 여부를 확인하지 않으며 손실된 패킷에 대한 재전송이 이루어지지 않습니다. 또한 순서 보장을 해주지않기때문에 데이터가 도착하는 순서가 보장되지 않습니다. 이러한 특성때문에 UDP는 실시간 스트리밍 , 온라인 게임 , VoIP와 같이 빠른 전송이 필요한 애플리케이션에 사용됩니다.

UDP는 우편 발송 에 비유해봤는데요.
우리가 우편을 보낼때 편지를 작성하고 우체통에 넣어주기만 하면 발송이끝나죠 우편을 받을 상대와 딱히 연결되지는 않습니다. 마찬가지로 UDP는 비 연결 지향 프로토콜이기 때문에 데이터 전송 전에 별다른 연결을 설정하지않으며 오버헤드가 적습니다.(비연결지향)

하지만 우편을 보내기는 했는데 편지가 도착하지 않거나 분실될수도 있겠죠 하지만 발송자는 이를 확인할수도없고 받는사람이 이를 다시 요청하지 않는한 다시 우편을 보내지는 않습니다. UDP도 마찬가지로 데이터의 전송 성공 여부를 확인하지 않으며 손실된 패킷에 대한 재전송이 이루어지지 않습니다.(신뢰성 없음)

우편 발송은 별도의 확인절차가 없기때문에 더욱더 빠른 전송이 가능한데요 UDP또한 데이터 전송 과정에서 확인작업을 따로 하지 않기때문에 TCP보다 빠르게 전송할 수 있습니다.(속도)

또한 우편으로 여러개의 편지를 보낼때 편지가 도착하는 순서는 딱히 보장되지 않습니다. 어떤 편지는 빨리올수있고 어떤 편지는 늦게 도착할 수도 있죠 UDP도 전송된 데이터가 도착하는 순서를 보장해주지 않습니다.(순서 보장 없음)

 

  • IP의 한계
IP프로토콜의 한계는 비연결성 , 비신뢰성 , 그리고 비식별성이 있습니다.

(비연결성) ip프로토콜은 비연결 지향적인 프로토콜입니다. 데이터 전송전에 송신자와 수신자 간의 연결을 설정하지 않으므로 각 패킷은 독립적으로 전송됩니다. 이로인해 패킷이 도착하는 순서가 보장되지않으며 일부 패킷이 손상되는 일이 있습니다. 순서가 중요한 애플리케이션에서 문제를 일으킬수 있습니다.

(비신뢰성) IP는 데이터 전송의 신뢰성을 보장하지 않습니다. 패킷이 손실되거나 손상된 경우 IP프로토콜을 이를 감지하거나 재전송하지 않습니다.(이로인해 TCP같은 신뢰성있는 상위 계층 프로토콜이 필요함)

(비식별성) IP 프로토콜은 패킷을 전송할 때 각 패킷의 내용을 식별하지 않습니다. 그러다보니 패킷의 의미나 용도에 대한 정보를 알지 못합니다. 이로인해 특정 애플리케이션이나 서비스에대한 최적화가 어렵고 Qos(서비스 품질) 보장 같은 기능이 제한됩니다. 패킷의 처리는 오로지 라우터나 스위치의 주소 정보에 기반하여 이루어집니다.

이러한 문제들 때문에 각각의 애플리케이션이 요구하는게 다 다를기 때문에 그 요구에 맞춘 상위 계층 프로토콜들이 개발되었습니다.

 

  • 오류 제어 와 흐름 제어
오류 제어는 데이터 전송 중 발생할 수 있는 오류를 검출하고 수정하는 과정입니다. 데이터가 전송되는 동안 외부 요인으로 인해 손상되거나 변형될 수 있는데 오류 제어는 이러한 문제를 해결하기 위해 사용됩니다.

오류제어는 전송된 데이터에 오류가 있는지 확인하고 오류가 발견된다면 재전송 요청을 통해 손실된 데이터를 복구하거나 오류 정정 코드를 사용하여 데이터의 정확성을 회복합니다.

흐름 제어는 송신자와 수신자간의 데이터 전송 속도를 조절하는 과정인데요 데이터가 수신자가 처리하지 못하게 너무 빠르게 전송된다면 데이터 손실이 발생할 수 있기때문에 송신자는 수신자의 처리능력에 맞춰서데이터를 전송합니다. 이를 위해 다양한 프로토콜을 사용합니다. 예시로는 (stop-and-wait-sliding window) 가 있습니다.
● 오류 제어와 흐름 제어의 목적

오류제어는 데이터의 정확성을 보장 , 흐름제어는 데이터 전송 속도를 조정하여 데이터 손실을 방지합니다.

 

 

  • 대칭키 ,비대칭키 암호화
대칭키 암호화와 비대칭키 암호화는 데이터 보안에서 중요한 두가지 암호화 방식입니다.

1.대칭키 암호화 : 대칭키 암호화는 동일한 키를 사용하여 데이터를 암호화하고 복호화하는 방식입니다. 즉 송수신자가 같은 비밀키를 공유합니다.

송신자는 데이터를 암호화할때 비밀키를사용 => 수신자는 동일한 키로 암호화된 데이터를 복호화

장점 : 암호화와 복호화 과정이 빠름, 구현이 간단함 ,대량의 데이터를 처리하는데 유리함
단점 : 키 관리가 어려운 점이 있음, 키가 노출되면 보안이 위협받을수있음
2.비대칭키 암호화 : 비대칭키 암호화는 두개의 키를 사용하는 방식입니다. 하나는 공개키 하나는 개인키로 공개키는 누구나 사용할수있지만 개인키는 소유자만 알수있습니다.

송신자는 수신자의 공개키로 데이터를 암호화 => 수신자는 자신의 개인키로 데이터를 복호화 , 이과정은 비밀키 공유가 필요없음

장점 : 키 관리가 용이하고 보안성이 높음 , 공개 키가 노출되도 개인키가 안전하다.
단점 : 암호화의 복호화 과정이 상대적으로 느림 , 대량의 데이터 전송에는 비효율적

 

  • 대칭키/비대칭키 혼합 사용
대칭키와 비대칭키를 혼합하여 사용하는 것은 두 방식의 장점을 극대화하고 단점을보완하기 위해서입니다.

이 경우 송신자는 수신자의 공개 키를 사용하여 대칭키를 암호화하고 비대칭키 암호화를 사용하여 안전하게 전송할 수 있습니다.
이렇게 하면 대칭키의 노출 위험이 줄어들어 보안성을 크게 향상시키고 대칭키 암호화를 사용하여 빠른 암호화 및 복호화로 대량의 데이터를 효율적으로 처리할 수 있습니다.
비대칭키 암호화는 상대적으로 속도가 느리지만 여기서는 대칭키를 안전하게 전송하는데만 사용되고 데이터 전송은 대칭키로 수행하여 전체적인 성능을 향상시킬 수 있습니다.

 

  • HTTPS 란?
HTTPS는 HTTP의 보안 버전입니다.

웹에서 데이터를 안전하게 전송하기 위해 사용되는 프로토콜입니다.
HTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜 을 기반으로하여 작동합니다. 이 두 프로토콜은 데이터 암호화 , 인증 , 무결성을 보장합니다.

전송되는 데이터를 암호화하여 중간에 누가 가로채더라도 내용을 알아볼수 없고 클라이언트는 서버의 SSL인증서를 통해 서버의 신원을 확인할 수 있습니다.
이를통해 사용자는 데이터가 안전한 서버로 전송되고있다는것을 알수있습니다. 이러한 과정때문에 HTTP보다 성능이 뒤떨어지나 현대의 하드웨어와 최적화된 프로토콜 덕분에 그 차이가 점점 줄어들고있습니다.

포트 번호 : 기본적으로 HTTP는 포트 80을 사용하고, HTTPS는 포트 443을 사용합니다.

 

  • 로드밸런싱
로드밸런싱은 여러 서버나 컴퓨터 자원에 작업을 고르게 분산하는 기술입니다.

많은 사람들이 동시에 웹사이트에 접속할 때 그 요청을 여러 서버에 나눠서 처리하게 해줍니다.
이렇게하면 한 서버에만 부하가 걸리지 않아서 안정적인 서비스의 제공이 가능합니다.

 

  • 로드밸런싱 알고리즘
로드 밸런싱 알고리즘은 크게 두가지 범주로 나뉘는데 정적 로드 밸런싱과 동적 로드 밸런싱으로 나뉩니다.

1. 정적 로드 밸런싱 방식 : 정적 로드밸런싱은 미리 정의된 규칙에따라 요청을 분산하는 방식입니다.

라운드 로빈 방식 방식 : 클라이언트의 요청을 순서대로 각 서버에 할당하는 방식입니다. 1번요청은 1번서버 2번요청은 2번서버에 전달됩니다.

고정 할당 방식 : 특정 서버에 고정된 비율로 요청을 할당하는 방식입니다.예를들어 70대30으로 고정해둔다면 서버 A에 70% 서버 B에 30%의 요청을 할당할 수 있습니다.

장점 : 간단한 구현: 복잡한 알고리즘이 필요 없어 쉽게 설정할 수 있습니다. 예측 가능성: 트래픽 패턴이 일정할 경우, 서버의 부하를 예측할 수 있습니다.
단점 : 유연성 부족: 서버의 현재 상태를 반영하지 않기 때문에, 부하가 불균형하게 분산될 수 있습니다. 비효율성: 서버의 성능 차이를 고려하지 않기 때문에, 일부 서버가 과부하에 걸릴 수 있습니다

2.동적 로드 밸런싱 : 서버의 현재 상태(부하,성능 등)를 실시간으로 모니터링하고 이를 기반으로 클라이언트 요청을 적절하게 분산하는 방식입니다.

가중 라운드 로빈 방식 : 각 서버에 가중치를 부여하여 가중치가 높은 서버에 더 많은 요청을 할당합니다. 서버의 성능차이를 고려하여 요청을 분산하는 방식입니다.

IP해시 방식 : 클라이언트의 IP주소를 해시하여 특정 서버에 요청을 맵핑하는 방식입니다. 이를 통해 사용자가 항상 동일한 서버에 연결되도록 보장합니다.

장점
부하 분산 최적화: 서버의 현재 상태를 반영하여 요청을 분산하므로, 부하가 고르게 분산됩니다.
응답 시간 단축: 서버의 성능을 고려하여 요청을 할당하므로, 전체 시스템의 응답 시간이 개선됩니다.

단점
복잡성: 동적 로드 밸런싱은 구현이 복잡할 수 있으며, 추가적인 리소스가 필요할 수 있습니다.
비용: 실시간 모니터링 및 분석을 위한 추가적인 인프라가 필요할 수 있어, 비용이 증가할 수 있습니다

 

  • 헬스체크
헬스체크는 서버나 애플리케이션의 상태를 점검하여 정상작동 여부를 판단하는 기능입니다.

헬스체크를 통해 시스템의 이상징후를 조기에 발견할 수 있어 장애 발생시 신속한 대응이 가능하고 주기적인 상태 점검을 통해 시스템의 가용성을 높여 사용자에게 안정적인 서비스를 제공하게합니다.

헬스체크는 자동으로 수행되므로 별다른 개입 없이도 시스템 상태를 지속적으로 모니터링할 수 있습니다.

헬스체크는 3가지 방식으로 구분됩니다.
1.수동 헬스체크 
서버가 수신한 요청에 대한 응답을 검사하여 정상작동 여부를 판단합니다.
주로 로드 밸런서와 같은 프록시 서버에서 사용되며, 요청에 대한 응답 지연이나 실패를 감지합니다.

2.능동 헬스체크
주기적으로 서버에 요청을 보내 응답을 받아 서버의 상태를 확인합니다.
ICMP, TCP, HTTP, HTTPS 프로토콜을 이용하여 체크하며, 데이터베이스 연결이나 API 서비스에서 사용됩니다

3.에이전트 기반 헬스체크
서버에 에이전트를 설치하여 내부 상태 정보를 수집하고 체크합니다.
서버의 리소스 사용량 ,디스크 용량 등 세밀한 정보를 수집할 수 있어 정확한 상태파악이 가능합니다.

헬스체크의 활용
로드 밸런싱 : 헬스체크를 통해 비정상적인 서버를 자동으로 제외시켜, 트래픽을 정상 서버로 분산시킵니다.

장애 복구 : 장애가 발생한 서버를 자동으로 격리하고, 복구가 완료되면 다시 서비스에 포함시킵니다.