AI_Tech부스트캠프 week15...[3] 웹프로그래밍 지식

Leejaegun·2024년 12월 16일
NaverAIBoostCamp
0

AI_tech_CV트랙 여정

목록 보기
52/74

1.Online Serving

1.1 OnlineServing의 구현

실시간으로 데이터를 처리하고 즉각적인 결과반환
실시간성을 요구하는 경우에 유용
주로Cloud나 On-Premise서버에서 모델호스팅후,요청 들어오면 모델이 예측 반환하는 구조
ex) 음식배달플랫폼.

직접 웹서버개발:Flask,FastAPI등 활용해 서버구축

Flask,FastAPI등을 사용해 서버구축

클라우드서비스활용:AWS의 SageMaker,GCP의 VertexAI등

장점

  • MLOps의다양한 부분을 이미 클라우드 회사에서 구축해 제공하기 때문에 활용만하면됨
  • 초기에 클라우드에 익숙해져야 하는 러닝커브가 있지만 이 커브만 극복하면 유용함
  • 회사에서 사람이 적은경우(=리소스가적은경우)사용해보는 것 추천

단점

  • 매니지드 서비스를 이용하는 것이기 때문에 직접 구축 대비 운영비용이 더 나갈수있음
  • 해당서비스에 디펜던시가 생기고,내부구현방식을 정확히 확인하지 못하는 경우도 있음

오픈 소스활용

tensorflow Serving,Torch Serve,MLFlow,BentoML등
ex) BentoML

OnlineServing 적용

어떤방법을쓰느냐는 주어진환경(일정,인력,예산,모델성능등)에따라 다르게 선택할수있음

클라우드 매니지드 서비스->직접 서버 개발->서빙 오픈소스 활용방식 권장

서빙 오픈소스 학습 마지막에 권장하는이유

  • 사용은 편하지만 특정오픈 소스나 툴에 숙련도를 키우는것 보다 여러 선택지 중에서 적절한 옵션을 고르는 능력과 기반지식을 먼저기르는것을추천(=핵심역량)
  • 오픈소스의 변화트렌드는 빠르기 때문에 특정도구의 숙련도만 키우면 부족함
  • 언제든 새로운 오픈소스 학습할 준비되어 있어야함
  • HighLevel오픈소스를 먼저사용할경우 LowLevel의이해도가부족할수있음

1.2 OnlineServing에서 고려할것

OnlineServing 과 Docker

Serving할때 Python버전,패키지버전등 Dependency가 굉장히중요함
이를위해 DockerImage,DockerCompose에 익숙하면 좋음

OnlineServing 과 Latency

실시간 예측을 하기 때문에 예측할 때 지연시간(Latency)를 최소화해야함

Latency최소화방법

  • 데이터 전처리 서버분리(혹은Feature를미리가공-FeatureStore)
  • 모델경량화
  • 병렬처리
  • 예측결과캐싱

2.Server 아키텍처

2.1 모놀리스 아키텍처

하나의 큰 API서버를 운영하는 방식

  • 모든 로직이 하나의 거대한 코드베이스에 저장
  • 일반 서비스와 ML서비스 코드가 혼재
  • 배포해야 할 코드프로젝트가 하나
  • Github:모노레포

아키텍쳐

Clinet 는 하나의 Server에게 요청하고, Server는 내부적으로 처리하고 요청을 반환.
장점

  • 서비스 개발 초기에는 단순하고 직관적
  • 관리해야 할 코드 베이스가 하나라 심플

고민할점

  • 모든 서비스 로직이 다 하나의저장소에저장
  • 나중엔 너무 커져서 이해하기어려움(=복잡도증가)
  • 서비스코드간 결합도가 높아서,추후에 수정이나 추가 개발하기 어려울 수있음
  • 의존성 및 환경을 하나로 통일
project/
├─ app/
│  ├─ __init__.py
│  ├─ models.py       # 데이터베이스 모델
│  ├─ views.py        # 웹 요청 핸들러 (Controller)
│  ├─ services.py     # 비즈니스 로직
│  ├─ forms.py        # 폼 처리 (웹 사이트용)
│  ├─ templates/      # HTML 템플릿
│  └─ static/         # 정적 파일(CSS, JS)
├─ tests/
│  ├─ test_models.py
│  ├─ test_views.py
│  └─ ...
├─ requirements.txt
└─ manage.py (또는 run.py)

2.2 마이크로서비스 아키텍처

핵심

  • 작은 여러개의 서버로 개발
  • 모든 로직이 각각의 개별코드에 저장
  • 일반서비스와 ML서비스 코드가 분리
  • 배포해야 할 코드프로젝트가 여러개

아키텍처

  • Client는 하나의 Server (혹은Load Balancer)에게 요청
  • Server는 이 요청을 처리할 각각의 내부적인Server(요리담당,비품담당)로 요청
  • 내부적인 Server들이 이 요청을 처리하고 다시요청했던 Server로반환
  • Server는 이 응답을 받아 필요에 맞게 변환 후Client에게 반환

장점

  • 거대한 코드 베이스를 작게 나눌 수 있음(마치 거대한 코드를 리팩토링 하는 것과 유사함)
  • 필요에따라 각 담당서버 단위로 스케일업/다운이 가능함
  • 의존성 및 환경을 담당서버별로 다르게 둘 수 있음

고민할 점

  • 전체적인 구조와 통신이 복잡해짐
project/
├─ user-service/
│  ├─ app/
│  │  ├─ main.py             # FastAPI/Flask 진입점
│  │  ├─ models.py           # User 모델
│  │  ├─ controllers.py      # REST API 핸들러
│  │  ├─ services.py         # User 관리 비즈니스 로직
│  │  └─ database.py         # DB 연결
│  ├─ requirements.txt
│  └─ Dockerfile
├─ order-service/
│  ├─ app/
│  │  ├─ main.py
│  │  ├─ models.py           # Order 모델
│  │  ├─ controllers.py
│  │  ├─ services.py         # 주문 처리 비즈니스 로직
│  │  └─ database.py
│  ├─ requirements.txt
│  └─ Dockerfile
└─ payment-service/
   ├─ app/
   │  ├─ main.py
   │  ├─ models.py           # Payment 기록 모델
   │  ├─ controllers.py
   │  ├─ services.py         # 결제 처리 로직
   │  └─ database.py
   ├─ requirements.txt
   └─ Dockerfile

2.3 무엇을 사용해야할까?

규모가 작고, 개발조직이 하나 -> 모놀리스
규모가 있고, 개발과 ML이 분리 -> 마이크로서비스 아키텍쳐

3.API

Application Programming Interface"의 약자로,소프트웨어 응용프로그램들이 서로 상호 작용하기 위한 인터페이스를 총칭하는 말

  • 쉽게말해 특정소프트웨어에서 다른 소프트웨어를 사용할때의 인터페이스
  • 기본적으로 사람을 위한 인터페이스(UI,UserInterface)가 아니라,소프트웨어를 위한 인터페이스임
    -> 웹API, 라이브러리, OS시스템 콜 등 다양한 종류 존재함.

3.1 WebAPI

Web에서 사용되는 API
주로 HTTP를 통해 웹 기술을 기반으로 하는 인터페이스

HTTP란?

  • HTTP(HyperTextTransferProtocol):정보를 주고 받을때 지켜야 하는 통신 프로토콜(규약),약속

Web API종류

  • REST(Representational State Transfer)
  • GraphQL
  • RPC(Remote Procedure Call)

3.2 RESTAPI

  • RepresentationalStateTransfer의약자로“ 자원을 표현하고 상태를 전송하는것”에 중점을둔API
    -정확히말하면 REST라고 부르는 아키텍처“스타일”로 HTTP통신을활용

-> 요청의 모습을 보고 어떤 일을 하는지 알 수 있음.

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:UniformResourceIdentifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성
    URI는 URL을 포함하게되며,URI가 더 포괄적인 범위

리소스(Resource)
리소스란 고유하게 식별될 수 있는 데이터를 의미한다. 예를 들어, User라는 리소스가 있고, 각 사용자는 고유한 ID를 가지고 있다고 하자.
특정 리소스를 식별하기 위해 URI(Uniform Resource Identifier)를 사용한다.

예시:
모든 사용자 목록: https://api.example.com/users
특정 사용자(예: ID가 123인 사용자): https://api.example.com/users/123
여기서 /users는 '사용자'라는 리소스 컬렉션을 의미하고, /users/123은 그 컬렉션 중 특정한 한 명의 사용자 리소스를 식별한다.

메서드(Method)
HTTP 메서드는 서버에게 요청자의 의도를 전달하는 역할을 한다. 주로 CRUD(Create, Read, Update, Delete) 동작과 매핑된다.

GET: 데이터 조회(읽기, Read)
POST: 새로운 데이터 추가(생성, Create)
PUT: 기존 데이터의 전체 업데이트(수정, Update)
PATCH: 기존 데이터의 일부 업데이트(부분 수정)
DELETE: 데이터 삭제(Delete)

표현(Representation of Resource)
리소스는 단순히 URI로만 존재하는 것이 아니라, 클라이언트와 서버 간에는 그 리소스의 상태나 정보를 "표현" 형태(주로 JSON이나 XML)로 주고받는다.

REST API 예시

4.RESTAPI

4.1 RESTAPI 사용 예시

GET http://localhost:8080/users?name=seongyun

GET

  • HTTPMethod부분
  • 하고자하는 것을 주 표현함(그래서동사)
  • HTTPMethod종류로 주로 사용되는것
  • GET:리소스를 조회할때
  • POST:리소스를 생성할때
  • PUT:생성된리소스 하나를 전체업데이트 할때
  • PATCH:생성된 리소스 하나를 부분업데이트할때
  • DELETE:생성된 리소스하나를 삭제할때
  • 위API는users라는리소스를조회하는API호출

http://localhost:8080/users?name=seongyun

  • 각 프로세스(서버)는 하나의 Port를 사용하여 네트워크 통신
    -즉,위API호출은 localhost(내컴퓨터)의 8080포트에서 리슨하고 있는 서버로HTTP 요청하는것
    -위 요청에 대한 응답이 정상적으로오려면,localhost(내컴퓨터)의8080포트에 서버가 실행되고있어야함

4.2 RESTAPI 추가개념-URL Parameters

QueryParameter

  • URL의 끝에 추가하며,특정 리소스의 추가 정보를 제공 또는 데이터를 필터링 할 때 사용
  • Parameter가 QueryString에저장
  • API뒤에 입력데이터를 함께 제공하는 방식으로 사용
  • QueryString은 Key,Value의 쌍으로 이루어지며 &로 연결해 여러데이터를 넘길 수 있음
    ex) http://localhost:8080/users?name=seongyun
    물음표 뒤에 ?name=seongyun여기 정보 제공하는 거임

PathParameter

  • 리소스의 정확한 위치나 특정리소스를 찾을때사용
  • Parameter가 Path에저장
    ex) http://localhost:8080/users/seongyun

4.3 RESTAPI추가개념-Header,Payload

curl -X POST -H "Content-Type:application/json" -d '{"name":"seongyun"}' http://localhost:8080/users

-H"Content-Type:application/json"

  • HTTPHeader에 Content-Type:application/json이라는 key:value를추가
    -우리가 지금 보내는 데이터가 JSON타입임을 표현
  • HTTPHeader에 key:value형태로 데이터를 저장할수있음

-d'{"name":"seongyun"}

  • Payload로 JSON을 추가
  • Payload는 앞뒤에 따옴표(“)를 붙여야 함
    Header,Payload 정보는 브라우저창에서 확인할수있음

4.4 RESTAPI추가개념-Status Code

클라이언트 요청에 따라 서버가 어떻게 반응하는지를 알려주는 Code

  • 1xx(정보):요청을 받았고,프로세스를 계속 진행함
  • 2xx(성공):요청을 성공적으로 받았고,실행함
  • 3xx(리다이렉션): 요청 완료를 위한 추가작업이 필요
  • 4xx(클라이언트오류):요청 문법이 잘못되었거나 요청을 처리 할 수 없음
  • 5xx(서버오류)서버가 요청에 대해 실패함
  • 미리정의되어있음
    정보: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

4.5 그외로 추가로 알면 좋은 개념들

IP란?

  • 네트워크에 연결된 특정PC의 주소를나타내는체계
  • InternetProtocol의줄임말,인터넷상에서 사용하는 주소체계
  • 네덩이의 숫자로 구성된 IP주소체계를 IPv4라고함
  • 각 덩어리마다 0~255로나타낼 수 있음.2^32=약43억개의 IP주소를 표현할 수 있음

Port란?

  • PC에 접속할 수 있는 통로(채널)
  • 사용중인 포트는 중복할 수 없음
    -0~1023는통신을위한규약에예약됨
    -22:SSH
    -80:HTTP
    -443:HTTPS
profile
Leejaegun
Lee_AA
이전 포스트

AI_Tech부스트캠프 week15...[2] Batch Serving과 Airflow

다음 포스트

AI_Tech부스트캠프 week15...[4] FastAPI(1)

0개의 댓글

관련 채용 정보