출처 : 변성윤님 블로그.
출처 : 부스트캠프 AI Tech.
1.백엔드 프로그래밍
1.1 Server 구성 Use Case
- 앱/웹 서비스의 서버가 존재
- 머신러닝 서비스의 서버가 존재
- 서비스 서버에서 머신러닝 서버에 예측 요청하며 통신함(혹은 서비스 서버의 한 프로세스로 실행)
1.2 Server의 형태
1.2.1 Monolithic Architecture
- 하나의 큰 서버 = 종업원, 요리사, 서랍, 계산 등을 모두 하나에서 처리하는 경우(큰 범주로 모두 서버)
- 모놀리식 아키텍처(Monolithic Architecture)
1.2.2 Mircroservice Architecture - MSA
- 종업원, 요리사, 서랍, 계산 등을 각각의 개별 서버로 구성하고 서로 통신하도록 하는 경우
- 마이크로서비스 아키텍처(Mircroservice Architecture - MSA)
1.3 REST API
- REST API : 정보를 주고 받을 때 널리 사용되는 형식
- 주문할 때(API 요청시) 활용하는 정해진 형식
- 요청의 모습을 보고 어떤 일을 하는지 알 수 있음
- 개발할 때 API를 임의로 만들 수도 있음
- 예) https://www.naver.com/1 : 네이버 블로그 접속
- https://www.naver.com/2 : 카페 접속
- 이런 경우라면 1, 2가 무엇을 의미하는지 알아야 함 => 협업할 때 힘들어짐
- HTTP(Hyper Text Transfer Protocol) : 정보를 주고 받을 때 지켜야 하는 통신 프로토콜(규약),
- 약속 약속이 없으면 사람마다 다르게 쓰게 됨
- HTTP는 기본적으로 80번 포트를 사용하고 있으며, 서버에서 80번 포트를 열어주지 않으면 HTTP 통신이 불가능
- REST란 형식의 API
- 각 요청이 어떤 동작이나 정보를 위한 것을 요청 모습 자체로 추론할 수 있음
- 기본적인 데이터 처리 : 조회 작업, 새로 추가, 수정, 삭제
- CRUD : Create, Read, Update, Delete
- Representational State Transfer의 약자
- Resource, Method, Representation of Resource로 구성
- 클라이언트 : 요청을 하는 플랫폼. 브라우저 같은 웹일 수 있고, 앱일수도 있음. 우리가 Python을 사용해 요청하는 것도 클라이언트
- Resource : Unique한 ID를 가지는 리소스, URI
- Method : 서버에 요청을 보내기 위한 방식 : GET, POST, PUT, PATCH, DELETE
- URI와 URL
- URL : Uniform Resource Locator로 인터넷 상 자원의 위치
- URI : Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성
- URI는 URL을 포함하게 되며, URI가 더 포괄적인 범위
1.4 HTTP Method
1.4.1 HTTP Method 종류
- GET : 정보를 요청하기 위해 사용(Read)
- POST : 정보를 입력하기 위해 사용(Create)
- PUT : 정보를 업데이트하기 위해 사용(Update)
- PATCH : 정보를 업데이트하기 위해 사용(Update)
- DELETE : 정보를 삭제하기 위해 사용(Delete)
1.4.2 GET, POST 의 차이
- GET
- 어떤 정보를 가져와서 조회하기 위해 사용되는 방식
- URL에 변수(데이터)를 포함시켜 요청함
- 데이터를 Header(헤더)에 포함하여 전송함
- URL에 데이터가 노출되어 보안에 취약
- 캐싱할 수 있음
- POST
- 데이터를 서버로 제출해 추가 또는 수정하기 위해 사용하는 방식
- URL에 변수(데이터)를 노출하지 않고 요청
- 데이터를 Body(바디)에 포함
- URL에 데이터가 노출되지 않아 기본 보안은 되어 있음
- 캐싱할 수 없음(다만 그 안에 아키텍처로 캐싱할 수 있음)
1.5 Header와 Body
- Http 통신은 Request 하고, Response를 받을 때 정보를 패킷(Packet)에 저장
- Packet 구조 : Header / Body
- Header : 보내는 주소, 받는 주소, 시간
- Body : 실제 전달하려는 내용
1.6 Status Code
- 클라이언트 요청에 따라 서버가 어떻게 반응하는지를 알려주는 Code
- Status Code
- 1xx(정보) : 요청을 받았고, 프로세스를 계속 진행함
- 2xx(성공) : 요청을 성공적으로 받았고, 실행함
- 3xx(리다이렉션) : 요청 완료를 위한 추가 작업이 필요
- 4xx(클라이언트 오류) : 요청 문법이 잘못되었거나 요청을 처리할 수 없음
- 5xx(서버 오류) : 서버가 요청에 대해 실패함
1.7 동기와 비동기
- 동기(Sync) : 서버에서 요청을 보냈을 때, 응답이 돌아와야 다음 동작을 수행할 수 있음. A 작업이 모두 완료될 때까지 B 작업은 대기해야 함
- 비동기(Async) : 요청을 보낼 때 응답 상태와 상관없이 다음 동작을 수행함. A작업과 B 작업이 동시에 실행됨
1.8 IP
- 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
- Internet Protocol의 줄임말, 인터넷상에서 사용하는 주소체계
- 4덩이의 숫자로 구성된 IP 주소 체계를IPv4라고 함
- 각 덩어리마다 0~255로 나타낼 수 있음. 2^32 = 43억개의 IP 주소를 표현할 수 있음
- 몇가지는 용도가 정해짐
- localhost, 127.0.0.1 : 현재 사용 중인 Local PC
- 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소
- 개인 PC 보급으로 누구나 PC를 사용해 IPv4로 할당할 수 있는 한계점 진입, IPv6이 나옴
1.9 Port
- IP 주소 뒤에 나오는 숫자
- PC에 접속할 수 있는 통로(채널)
- 사용 중인 포트는 중복할 수 없음
- Jupyter Notebook은 8888
- Port는 0 ~ 65535까지 존재
- 그 중 0~1024는 통신을 위한 규약에 정해짐
- 22 : SSH
- 80 : HTTP
- 443 : HTTPS
2. FastAPI
2.1 FastAPI 소개 & 특징
- 최근 떠오르는 Python Web Framework
- Node.js, go와 대등한 성능
- Flask와 비슷한 구조 Microservice에 적합
- Swagger 자동 생성 Pydantic을 이용한 Serialization
2.2 FastAPI vs Flask
2.2.1 장점
- Flask보다 간결한 Router 문법
- Asynchronous(비동기) 지원
- Built-in API Documentation (Swagger)
- Pydantic을 이용한 Serialization 및 Validation2.2.2 아쉬운점
- 아직까지는 Flask의 유저가 더 많음
- ORM 등 Database와 관련된 라이브러리가 적음
2.3 FastAPI 구조 및 환경설정
- FastAPI에서 자주 사용되는 프로젝트 구조 소개
- 프로젝트의 코드가 들어갈 모듈 설정(app). 대안 : 프로젝트 이름, src 등
- main.py는 간단하게 애플리케이션을 실행할 수 있는 Entrypoint 역할 (참고)
- Entrypoint : 프로그래밍 언어에서 최상위 코드가 실행되는 시작점 또는 프로그램 진입점 - main.py 또는 app.py : FastAPI의 애플리케이션과 Router 설정
- model.py는 ML model에 대한 클래스와 함수 정의
- Poetry라는 가상 환경 및 의존성 관리 소개
2.4 Poetry
- Dependency Resolver로 복잡한 의존성들의 버전 충돌을 방지
- Virtualenv를 생성해서 격리된 환경에서 빠르게 개발이 가능해짐
- 기존 파이썬 패키지 관리 도구에서 지원하지 않는 Build, Publish가 가능
- pyproject.toml을 기준으로 여러 툴들의 config를 명시적으로 관리
- 새로 만든 프로젝트라면 poetry를 사용해보고, virtualenv 등과 비교하는 것을 추천
- 공식 홈페이지 링크
- MAC OSX / Linux:
$ curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python -
- Windows(Powershell)
2.4.1 Poetry 프로젝트 생성하기(Invoke-WebRequest -Uri https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py -UseBasicParsing).Content | python -
- Poetry 사용 흐름
- 프로젝트 init
- Poetry Shell 활성화
- Poetry Install
- Poetry Add
- FastAPI 프로젝트를 만들기 위해 아래 패키지들이 필요
- fastapi
- uvicorn or gunicorn
2.4.1.1 Poetry 사용 흐름 - 프로젝트 init
- 사용할 라이브러리 지정
- 대화 형식으로 패키지 설치 가능
- 패키지 이름 검색 및 선택
- 패키지 버전 명시
- Dependency(프로덕션용)
- Development Dependency(Dev용)
- 개발 환경마다 필요한 패키지 분리
- pyproject.toml에 설정 저장됨
2.4.1.2 Poetry Shell 활성화, Poetry Install, Poetry Add
- Poetry Shell 활성화 : poetry shell
- Poetry Install : pyproject.toml에 저장된 내용에 기반해 라이브러리 설치
- Poetry Add : 필요한 패키지를 추가하고 싶은 경우 사용
2.4.1.3 poetry.lock
- Writing lock file에서 생성되는 파일
- 이 파일이 존재하면 작성하고 있는 프로젝트 의존성과 동일한 의존성을 가질 수 있음
- Github Repository에 꼭 커밋!
2.4.2 Poetry 프로젝트 예제 - Simple Web Server 띄우기
2.5 Swagger
- localhost:8000/docs로 이동하면 Swagger를 확인할 수 있음
- localhost:8000/redoc로 이동하면 API Specification 를 확인할 수 있음
- Swagger가 유용한 이유
- 만든 API를 클라이언트에서 호출하는 경우(협업)
- Q) 어떻게 Request 해야 하죠?
- A) 이 인자를 주시면 되어요~~!
- REST API 설계 및 문서화할 때 사용
- 다른 개발팀과 협업하는 경우
- 구축된 프로젝트를 유지보수하는 경우
- 기능
- API 디자인
- API 빌드
- API 문서화
- API 테스팅
- 백엔드 프로그래밍 기초 지식은 굉장히 많은 편 => 자주 접해서 익숙해지기
- FastAPI를 사용하는 것보다 이런 기초 지식이 존재해야 백엔드 프로그래밍을 수월하게 할 수 있음
'MLOps' 카테고리의 다른 글
MLOps - 14. FastAPI (0) | 2022.05.29 |
---|---|
MLOps - 13. FastAPI (0) | 2022.05.28 |
MLOps - 11. CI/CD, Github Action (0) | 2022.05.26 |
MLOps - 10. Cloud (0) | 2022.05.25 |
MLOps - 9. Linux & Shell Command (0) | 2022.05.24 |
댓글