Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2주차 세미나 과제 #12

Open
airoca opened this issue Oct 27, 2024 · 0 comments
Open

2주차 세미나 과제 #12

airoca opened this issue Oct 27, 2024 · 0 comments

Comments

@airoca
Copy link
Collaborator

airoca commented Oct 27, 2024

1. L4 Switch, L7 Switch가 무엇인가? (비용, 역할, 알 수 있는 정보)

L4 Switch

  • OSI 4계층 (전송 계층)에서 작동하며, IP 주소와 포트 번호를 기반으로 단순히 네트워크 흐름을 처리한다.
  • IP 주소와 포트 번호, 그리고 TCP/UDP 프로토콜을 기반으로 트래픽을 처리하며, 단순히 요청을 분배한다.
  • L7 Switch에 비해 비교적 비용이 싸다.

L7 Switch

  • OSI 7계층 (애플리케이션 계층)에서 작동하며, URL, 헤더, 쿠키 등 패킷의 내용을 분석하여 트래픽을 세밀하게 분배한다.
  • 헤더와 콘텐츠를 읽어, URL, 쿠키, 메시지 내용 등에 따라 정교하게 트래픽을 제어하고 분배할 수 있다.
  • L4 Switch에 비해 비교적 비용이 비싸다.

L4 로드 밸런서는 단순히 요청을 여러 서버에 균등하게 분배하고 싶을 때, L7 Switch는 특정 요청을 특정 서버에서 처리하도록 하고 싶을 때 사용한다.

2. RESTful이란?

1) REST (Representational State Transfer)

  • REST는 클라이언트와 서버 간의 상호작용을 위한 아키텍처 스타일이다. (프로토콜, 표준 X)
  • REST의 목적은 웹 기반 시스템 간의 일관된 상호작용이다. (결합력을 낮춘다.)
  • API 개발자는 REST를 다양한 방식으로 구현할 수 있다.

2) API

  • API는 소프트웨어 구성 요소 간의 상호작용을 정의하는 인터페이스이다.
  • 인터페이스란 서로 다른 시스템이나 구성 요소 간의 상호작용을 정의하는 규칙이나 계약이다.

3) RESTful API

  • RESTful API는 REST 원칙을 따르는 API이다.
  • REST의 원칙을 모두 준수했을 때 RESTful 하다고 할 수 있다.

4) REST의 6가지 제약 조건

  • Client-Server

    클라이언트(UI)와 서버(Data Storage)가 독립적으로 상호작용한다. (관심사 분리)

  • Stateless

    서버가 클라이언트의 상태를 저장하지 않기 때문에 모든 필요한 정보를 요청에 포함해야 한다.

  • Cache

    서버의 응답이 캐시 가능한지 명시해야 한다. 캐시가 가능한 경우, 같은 요청에 대해 응답 데이터를 재사용할 수 있어야 한다.

  • Layered System

    계층화된 시스템을 사용하며, 각 구성 요소는 직접적으로 상호작용하는 계층 외의 내용을 볼 수 없어야 한다. (MVC, Proxy 등)

  • Code-on-Demand (Optional)

    Code-on-Demand는 클라이언트에 즉시 실행 가능한 코드(javascript)를 보내는 것을 의미한다.

    이는 클라이언트가 사전 구현해야 하는 기능의 수를 줄여주는데, 해당 조건은 선택적이다.

  • Uniform Interface

    클라이언트와 서버 간의 상호작용을 표준화하여, 독립적인 업데이트를 보장한다. (상호 운용성)

    구체적으로, 리소스는 URI를 통해 식별되고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 일관성 있게 처리되는데, Uniform Interface는 아래의 세부 원칙을 포함한다.

    • Self-Descriptive Messages
    • HATEOAS (Hypermedia As The Engine Of Application State)

3. 인프라 문제

1) 서버를 10개 띄울 예정인데, 클라이언트는 하나의 주소로 우리 서버를 호출했으면 좋겠어요. (Proxy)

  • Proxy 서버는 클라이언트와 서버 간의 중개 역할을 하는 서버이다.
  • 클라이언트가 요청을 프록시 서버에 보내면, 프록시 서버가 실제 목적지 서버로 해당 요청을 전달한 후, 그 응답을 다시 클라이언트에 반환하는 방식으로 동작한다. (즉, 직접적으로 실제 서버와 통신하지 않는다.)

2) 트래픽이 몰릴 때, 10개의 서버가 균등하게 요청을 처리할 수 있을까요? (Load Balancing)

  • 트래픽이 몰릴 때 10개의 서버가 균등하게 요청을 처리하려면 Load Balancing을 구현해야 한다.
  • Load Balancer는 들어오는 요청을 여러 서버에 분산시켜, 각 서버의 부하를 균등하게 유지한다.

3) 같은 형상의 서버를 n개 (위에서는 10개) 띄우기 위한 효과적인 방법은 무엇일까요? (Docker)

  • Docker를 통해 애플리케이션을 이미지화하면, 동일한 환경에서 여러 컨테이너를 찍어낼 수 있다. (Docker 이미지의 재사용성)
  • Docker 이미지: Docker 컨테이너를 만들기 위한 템플릿
  • Docker 컨테이너: Docker 이미지의 인스턴스 (Docker 이미지를 실행하여 생성된 실제 환경)

4) 특정 헤더를 인식하면, 정해진 도메인과 path로 요청을 보내고 싶어요. (L7 switch)

  • 특정 헤더를 인식하여 정해진 도메인과 path로 요청을 보내기 위해서는 L7 스위치를 활용할 수 있다.
  • L7 스위치는 애플리케이션 레벨에서 요청을 처리하여, HTTP 요청의 헤더, 쿠키, URL 등을 기반으로 요청을 라우팅한다.

5) Spring Boot Application 은 아무 설정하지 않는다면, 동시에 몇 개의 요청을 처리할 수 있을까요?

  • Spring Boot 애플리케이션은 기본적으로 Tomcat을 내장하고 있다.
  • 아무 설정이 없을 경우 기본적으로 200개의 동시 요청을 처리할 수 있다.

6) 그렇다면 무작정 tomcat thread를 늘리면 좋은 게 아닌가요? 적정 수의 thread 설정은 어떻게 하면 좋을까요?

  • 메모리 사용량 증가: 각 스레드에 고유의 메모리 스택을 할당해줘야 하므로 메모리 사용량 증가
  • CPU 사용량 증가: 스레드가 많아짐에 따라 컨텍스트 스위칭이 자주 일어난다. 이 과정에서 CPU 사용량이 증가한다.
  • 리소스 경합: 여러 스레드가 동일한 자원에 접근할 경우 경합이 발생하여 스레드가 대기하게 된다.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant