Product Serving(4): Online Serving을 위한 웹 프로그래밍

1. Online Serving

실시간으로 데이터를 처리하고 즉각적으로 결과 반환
실시간성을 요구하는 경우에 유용
주로 Cloud, On-premise 서버에서 모델 호스팅 후, 요청 들어오면 모델이 예측 반환하는 구조

---

크게 세가지 방법으로 개발을 나눌 수 있다.

1. 직접 웹 서버 개발
   Flask, FastAPI 활용하여 서버 구축
   localhost/

2. 클라우드 서비스 활용
   AWS의 SageMaker, GCP의 Vertex AI
   회사에서 리소스가 적은 경우 활용해 볼만 하지만, 매니지드 서비스를 이용하는 것이기에 직접 구축하는 것 보다 비용이 더 나갈 수 있고, 해당 서비스에 의존성이 생기며, 내부 구현 방식을 정확히 확인하지 못하는 경우도 더러 있기에 불안불안할 때가 있다.

3. 오픈소스 활용
   Tensorflow Serving, Torch Serve, MLFlow, BentoML 등

Online Serving 적용
어떤 방법을 쓰느냐는 주어진 환경(일정, 인력, 예산, 모델 성능 등)에 따라 다르게 설택할 수 있음
클라우드 건드리다가... 직접 서버만들다가... 서빙 오픈소스 활용하다가... 등등

Online Serving과 Docker
Serving 할 때 Python 버전, 패키지 버전 등 Dependency가 굉장히 중요함.
이를 위해 Docker Image, Docker Compose에 익숙하면 좋음

Online Serving과 Latency
지연시간 최소화는 실시간 예측에서 반드시 고려해야 할 점

• 데이터 전처리 서버 분리
• 모델 경량화
• 병렬 처리
• 예측 결과 캐싱
  병목 지점이 모델 서버가 아닌, 데이터를 가져오는 Database 일 수도 있기에 유동적으로 성능을 확인해서 문제를 해결하려하는 역량이 필요함.

2. Server 아키텍쳐

Q. 실제 회사에서는 어떻게 서버들이 배포되어 있을까?

• 하나의 큰 API서버를 운영 vs 여러대의 작은 API 서버
  • 모놀리스 아키텍쳐
    하나의 큰 서버로 개발
    모든 로직이 하나의 거대한 코드 베이스에 저장
    일반 서비스와 ML 서비스 코드가 혼재
    배포해야 할 코드 프로젝트가 하나
    Github: 모노레포
    • 서비스 개발 초기에는 단순하고 직관적이지만
    • 모든 서비스 로직이 하나에 저장되는 만큼 복잡도가 증가하고, 서비스 코드 간에 결합도가 높아서 후추 수정이 힘들고 의존성 및 환경을 하나로 통일한 부작용이 있음
  • 마이크로 서비스 아키텍쳐
    작은 여러개의 서버로 개발
    모든 로직이 각각 개별 코드에 저장
    일반 서비스와 ML 서비스 코드가 분리
    배포해야 할 코드 프로젝트가 여러개
    • 거대한 코드 베이스를 작게 나눌 수 있음
    • 필요에 따라 각 담당 서버 단위의 스케일 업 다운 가능
    • 의존성 및 환경을 담당 서버 별로 다르게 둘 수 있음
    • 전체적인 구조와 통신은 다소 복잡해짐

3. API

• API 란?
  APllication Programming Interface 의 약자로 소프트 웨어 응용 프로그램들이 서로 상호 작용하기 위한 인터페이슬르 총칭하는 말
• 쉽게 말하면 특정 소프트웨어에서 다른 소프트웨어를 사용할 때의 인터페이스
• 기본적으로 사람을 위한 인터페이스가 아니라 소프트웨어를 위한 인터페이스임
• API의 구현에는 웹 API, 라이브러리, OS 시스템 콜 등 다양한 종류가 존재

3.1 Web API

• Web 에서 사용하는 API
• 라이브러리 API나 시스템 골 등의 API는 Web에서 사용되지 않고, Web을 이용하지 않음
• 주로 HTTP를 통해 웹 기술을 기반으로 하는 인터페이스

HTTP란?

• HTTP(Hyper Text Transfer Protocol)
  정보를 주고 받을 때 지켜야 하는 통신 프로토콜(규약), 약속
• 약속이 없다? => 사람마다 다르게 쓰게 됨.
• 많은 정보가 오갈 때 이런건 병목을 만듦
• HTTP는 기본적으로 80번 포트를 사용하고 있으며, 서버에서 80번 포트를 열어주지 않으면 HTTP 통신이 불가능

• Web API의 종류

1. REST(Representational State Transfer)
   자원을 표현하고 상태를 전송하는 것에 중점을 둔 API 방식을 의미
   정확히는 REST라고 부르는 아키텍쳐 스타일로 HTTP 통신을 활용
   가장 대중적이고, 현대의 대부분 서버들이 이 API 방법을 채택
   요청의 모습을 보고 어떤 일을 하는지 알 수 있음
   본질적으로 협업할 때 위와 같은 직관적이고 명시적 요청은 효과적이게 작동함.
2. GraphQL
3. RPC(Remote Procedure Call)

3.2 REST API

각 요청이 어떤 동작이나 정보를 위한 것인지 요청 모습 자체로 추론 가능

• 기본적인 데이터 처리: 조회 작업, 새로 추가, 수정, 삭제
  • CRUD: Create, Read, Update, Delete
• Resource, Method, Representation of Resource로 구성
• Resource: Unique한 ID를 가지는 리소스, URI
• Method: 서버에 요청을 보내기 위한 방식
  GET, POST, PUT, PATCH, DELETE

URI와 URL

• URL: Uniform Resource Locator로 인터넷 상 자원의 위치
• URI: Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성
  URI는 URL을 포함하게 되며, URI가 더 포괄적인 범위

HTTP Header, Payload
HTTP Method와 URL 뿐만 아니라, HTTP Header와 HTTP Payload를 사용하여 요청 가능

• curl?
  터미널(CLI) 환경에서 HTTP 요청을 할 때 주로 사용하는 도구

  • curl -X POST -H ~

  • HTTP 메서드로 POST를 사용

  • H?
    HTTP Header에 Content-Type: application/json 이라는 key: value를 추가

    • 우리가 지금 보내는 데이터가 JSON 타입임을 표현

  • HTTP Header에 key: value 형태로 데이터를 저장할 수 있음

  • d?
    데이터를 의미하는 것으로, Payload를 사용하여 요청한다.
    Payload로 Json을 추가
    Payload는 앞 뒤에 따옴표(")를 붙여야 함

  • 맨 뒤 주소는 HTTP URL 부분으로 요청을 어디로 보낼 것인지 표현한다.

• Status Code
  참고: https://restfulapi.net/http-status-codes/

4. 그외 개념들

• IP?
  네트워크에 연결된 특정 PC의 주소를 나타내는 체계

  • Internet Protocol의 줄임말로, 인터넷상에서 사용하는 주소체계를 의미함

  • 네 덩이의 숫자로 구성된 IP 주소 체계를 IPv4라고 함

  • 각 덩어리마다 0~255로 나타낼 수 있음

  • 다만, 몇가지는 이미 용도가 정해짐.
    localhost, 127.0.0.1: 현재 사용중인 Local PC
    0.0.0.0 255.255.255.255: 로컬 네트워크에 접속된 모든 장치와 소통하는 주소

• Port란?

  • IP 주소 뒤에 나오는 숫자 ex) 127.0.0.1:8080
  • PC에 접속할 수 있는 통로(채널)
  • 사용중인 포트는 중복 불가
  • Jupyter Notebook은 8888
  • Port는 0 ~ 65535까지 존재
    다만, Port 또한 이미 정해진 것이 있음
  • 0~1023은 통신을 윟나 규약에 예약됨
    22: SSH
    80: HTTP
    443: HTTPS