MLOps 12/04 필기

1. 지난주 카톡에 나온 문의 내용:
   커스텀 image 만들기 + 볼륨 마운팅하면서 컨테이너 열기
   • dockerfile에 만들고자 하는 이미지의 레시피 적어두기. 참고로 확장자가 없이 dockerfile이라고 되어있어야함.
   • docker build . -t [이름]

     	>> dockerfile 찾아서 만들어줘
     	>> 이름 꼭 정해줘야함 

   • docker run -it --rm -v .:[컨테이너의 폴더][이름]

     	>> 지금 있는 위치의 파일을 컨테이너 폴더랑 연결짓기 

2. ARCHITECTURE - CASE (1)
   <중간궁금증 / 기억할 내용 적기>
   - TRAINING이 점선인 이유; 항상 살이있을 필요가 없음!!!!
   - 주기적으로 많은 양의 데이터를 트레이닝때 읽어야해서 읽기 복제본을 만든다.. 이것도 API 연결
   - 분산 DATABASE?? WRITE는 DB에게 무거운 작업. 컴퓨터 여러대로 데이터를 WRTIE하게 하는 것이 필요하다! 더 찾아보기 돈 들여서 클라우드쓰는게 최적
   - 항상 쓰지 않는 (즉 당장 훈련용으로 쓰지 않는 데이터는) 파일로 추출해서 S3, 일종의 외장하드로 빼놓기
   - 쿠버네티스는 컴포넌트들을 한몸처럼 조율시키는 역할?
   - CI/CD(얘도 별도의 컴퓨터? 시스템?)가 접근할 수 있는 또다른 컴퓨터를 만들어서 걔가 작업을 하도록 만든다. 주로 젠킨스라는 툴을 쓴다.
   - 컴포넌트 3는 그냥 파일저장소에 가까움. 들어오면 네이밍 잘해서 저장잘하고, 필요할떄 잘 줄 수 있는, 그리고 백업 주기적으로 잘하는 정도. 여기에 더해 버전을 더 설명적으로 관리하고 싶으면 설명을 위한 API를 관리하는 컴포넌트 추가. 근데 이것도 주로 쓰는 툴이 있음.
   - 모델 서빙 = 과제로 한 API 성격과 유사하다. PREDICTION을 제공받는 측 + PREDICT를 위해 받은 찐데이터를 또 저장하는 기능
   - CONTAINER 오케스트레이션: 사용량이 늘어나면 그떄 컴퓨터를 늘리고 줄이고 할수도 있고... 컴퓨터 고장났을때 다른 컴퓨터가 해당 일을 대신해주는 등... 의 니즈가 있음
   - STATELESS하게 만들기?: 서빙을 위한 컴포넌트에는 저장기능이 없어야한다. 껐다 켰다 될 수 있기 떄문에.. 저장ㅇ느 저장만을 위한 DB에게로..
   - 메세지큐: 여러 요청이 들어왔을 때 줄정리해서 하나씩 넘겨주는 역할. 서빙 컴포넌트와 DB컴포넌트 사이에서..
   - CICD는 일을 시키는 역할.. 얘도 과정과정의 LOG를 볼 수 있지만, ML WF 오케스트레이션이 전체 컴포넌트들의 LOG를 보게 해줄 수 있음 ML WF ORCH도 쿠버네티스로 연결, 쿠버네티스가 LOG보기에 좋음. (세이지 메이커라는 서비스와 비슷하다?)
   - FEATURE ENGINEERING은 결국 FEATURE 골라네는 일. ETL은 주로
   - 전처리라는 말은 STATIC한 데이터를 교정하는일이고, FEATURE ENGINEERING은 실시간 데이터를 주물러야하는 가장 통계적인 지식이 필요한 예술의 일.

alpine: 엄청엄청 가벼운 운영체제

DB는 DELETE가 가장 힘이 소요가 많이 된다... 그래서 안한다! VALID/INVALID로 나눌뿐

로깅이 꼭 처음부터 갖춰야하는 필수는 아니다?

숙제
1)우리가 실제로 만들고자 하는 서비스에 대해서 ARCH 만들어오기
핵심은 REQUIREMENTS를 적는 것! 이유찾기!!
2) 1)의 컴포넌트들을 지하철 CASE에 과대하지만 만들어보기