[2주차 과제] Switch와 RESTful

[choyeongju]

⭐ TODO

• Switch?
• What is RESTful?

---

Switch? - L4, L7

OSI 7계층?4계층?

OSI 7계층 은 개념적으로 사용되는 표준 모델이고, TCP/IP 4계층 은 현실에서 실질적인 통신을위해 사용하는 더 실용적인 모델이다!

• 전송 계층 (~L4)
  • 수신지와 목적지를 감독하면서 데이터가 오류 없이 도착하는 것을 담당
  • TCP(연결형), UDP(비연결형)
• 응용 계층 (~L7)
  • 사용자와 통신할 수 있는 응용 서비스를 제공한다.
  • 웹사이트 접속(HTTP), 파일 전송(FTP), 메일 송수신(SMTP, POP3), 이름 해석(DNS), SMTP(네트워크 구성, 성능, 장비, 보안 관리) 등…

IP

• **인터넷 계층(~L3)**에서 사용하는, 네트워크 통신 시 데이터를 전송하는 경로 및 주소 지정을 담당하는 프로토콜이다.
• IP는 데이터를 패킷 단위로 분할해서 전송하게 되는데, 패킷에는 출발지/목적지 IP주소를 가지고 있다.
• IP는 각 패킷의 출발지/목적지 IP 주소를 이용해서 데이터를 목적지로 전달한다.

캡슐화/역캡슐화

(미미나 자료에서 발췌)

그림을 살펴보면 My Phone(송신측)에서 캡슐화해서 전달한 데이터가 Instagram(수신측)에서 역캡슐화 된다.

• 송신측 : 상 → 하위 계층
  • 캡슐화 계층마다 필요한 정보(헤더)를 붙여서 다음 계층으로 보낸다.
  • 데이터 링크 계층에서는 트레일러(데이터를 전달할 때 데이터에 마지막에 추가하는 정보)도 추가
• 수신측 : 하 → 상위 계층
  • 역캡슐화 받는 쪽에서 헤더를 하나씩 제거한다.

Routing

• 네트워크 상에서 데이터 패킷을 출발지에서 목적지로 전송하는 과정으로, 네트워크 상의 여러 경로들 중에서 최적의 경로를 선택하여 패킷을 전달한다.
• IP 주소와 같은 네트워크 주소 정보를 기반으로 트래픽을 어디로 보내야 할지 결정한다.

L4, L7 Switch 역할_Load Balancing의 차이?

• **로드밸런싱(Load Balancing)**이란,
  • 여러 개의 서버나 프로세서가 있을 때, 각 서버에 적절히 작업을 분배해서 한쪽 서버에 트래픽이 몰리지 않도록 만드는 기술이다. 이 역할을 하는 것을 로드밸런서(Load Balancer)라고 한다.

☁️ 로드밸런서인 L4, L7에 대해서 자세하게 알아보자 !! ☁️

L7과 L4의 로드 밸런싱은 모두 트래픽을 여러 서버에 나누어 주는 역할을 하지만, 처리하는 방식이 다르다.

❗일단 결론부터 말하자면, 요청의 내용을 얼마나 깊이 분석하느냐? 의 차이 ❗

• L4는 패킷의 내용은 분석하지 않고, 단순히 네트워크 흐름을 처리한다.
• L7는 URL, 헤더, 쿠키 등 패킷의 내용을 분석하여 트래픽을 세밀하게 분배한다.

L4 스위치

IP, TCP/UDP **포트 번호를 기준(포트 기반 라우팅)**으로 클라이언트 요청을 여러 서버에 분배한다. 즉, HTTP(포트 80)와 HTTPS(포트 443)와 같은 요청을 구분할 수 있다

→ 어떤 요청이 어떤 서버에 가는지에 대한 관리는 어렵다.

L7 스위치

요청의 내용을 기반으로 하여 트래픽을 분배한다.

아래와 같이, 클라이언트가 요청한 URL, HTTP 헤더, 쿠키, API 경로 등을 분석하여 적절한 서버에 요청을 전달함으로써 더 세밀하게 로드 밸런싱한다.

예를 들어, /images 경로는 이미지 서버로, /api 경로는 API 서버로 라우팅할 수 있다.

비용

앞서 살펴 본 내용을 토대로.. 당연히 L7이 더 비싸다.

사용상황

L4 로드 밸런서

“단순한 부하 분산”

• 단순하게 모든 클라이언트 요청을 여러 서버에 균등하게 나누고 싶을 때
• 서버는 각 요청이 어떤 데이터를 가지고 있는지 신경 쓰지 않고, 단순히 IP 주소와 포트 정보를 기준으로 빠르게 트래픽을 분배

L7 로드 밸런서

“결제만 담당하는 서버, 회원가입만 담당하는 서버 등.. 작은 단위로 요청을 각각의 서버에 분산”

• 특정 사용자와 서버의 연결(세션)을 일정 기간 유지하는 기능이 필요할 때
• (ex) 쇼핑몰 사이트에서 사용자가 로그인하거나 장바구니에 상품을 추가할 때, 다른 서버에 접속되어 데터에 차이가 생기지 않도록 그 세션을 같은 서버로 유지한다.

→ HTTP 쿠키나 세션 데이터를 분석해, 사용자가 처음 접속한 서버로 계속 요청을 보내어 일관된 세션 관리를 가능하게 한다.

Server가 위의 내용들을 알아야 하는 이유는? ~~

(ex :: L4) AWS의 Elastic Load Balancer(ELB)

여기서 백엔드 개발자는 특정 포트로 들어오는 트래픽을 어떻게 분배할지 정의한다.

(ex :: L7) Nginx

http {
    upstream app1 {
        server app1.example.com;
    }
    
    upstream app2 {
        server app2.example.com;
    }

    server {
        location /app1/ {
            proxy_pass http://app1;
        }

        location /app2/ {
            proxy_pass http://app2;
        }
    }
}

미미나 리마인드 : 면접 Tip

🧔🏻 OSI 7계층에 대해서 설명해 주세요

💬 실제로 현업에서 자주 사용되는 계층은 주로 4계층이다. 하위 계층으로 갈수록 더 단순하고 기본적인 작업을 처리해야 하기 때문에, 하위 계층은 비교적 “바보같이” 동작하는 것이 효율적입니다.

L4는 IP 주소와 포트 번호만을 기반으로 트래픽을 분배합니다. 이 계층은 IP 정보 외에 더 많은 정보를 알지 못하므로, 매우 단순하게 동작합니다.

L7은 앞단에서 받은 데이터로부터 HTTP, URL, 쿠키와 같은 애플리케이션 데이터를 분석할 수 있으므로, 더 세밀한 방식으로 트래픽을 라우팅할 수 있습니다.

---

What is RESTful?

REST란 HTTP URI를 통해 자원(Resource)을 이름으로 구별하고, HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해 해당 자원의 상태를 주고받는 것을 의미한다.

기준

1. 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처
2. 무상태성(Stateless)
   • 요청 간에 클라이언트에 대한 데이터가 저장되지 않음
   • 각 요청이 분리되어 있고 서로 연결되어 있지 않음
3. 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터
4. 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템
5. 정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스

클라이언트가 좋아할만한 API PATH?! - RESTful ..

• 버전 정보(v1, v2..)가 명확하게 담겨 있어야 할 것 같다.
  → 유지보수 및 호환성 문제
• 행위는 HTTP 메서드로 정의하고, PATH에서는 어떤 “Resource”를 다루는지만 명확하게 하자.
  → 이를 통해 계층적인 URI 구조를 갖게끔 해서, 확장이 편리하게 하면 좋겠다.
• 클라이언트는 최대한 단순한 정보만으로도 서버와 통신이 가능하게끔 하자! 서버 내부에서 일어나는 일들은 클라이언트가 알 필요가 없다!!
  → 예를 들어, 파일 확장자는 api path에서 클라이언트가 알 필요가 없다. 클라이언트는 리소스만 요청하게끔 하자~
• URL은 대소문자를 구분하는 웹 표준을 따르기에, api path 에서 대소문자 사용으로 문제가 일어나지 않도록 클라이언트와 사전 논의가 필요할 것 같다. (일반적으로 소문자를 따른다)

---

참고문헌

• 모두의 네트워크 기초(서지영)
• Operating System Concepts (공룡책)
• https://joyhong-91.tistory.com/37