수집 코드 실행 환경 dockerize #5
Description
Describe
TL;DR(Too Long; Didn't Read)
- aws ecr 람다 base image에 selenium, chromedriver, python libraries, 프로젝트 소스코드 등을 이미지로 빌드해놓고(dockerize), 수집 코드 동작하는 환경을 일관적이고 멱등하게 보장합니다.
- 클라우드 환경 대신 팀원 개개인의 개발 장비에서 수집 코드를 동작시킬 때 개인의 장비 차이에 따른 변수 제거
- webdriver 환경 격리 -> 세션, 사용 자원, 사용자 경로 등 격리 -> 병렬처리 안정성 견고하게 하기
- 이후 클라우드 환경으로 배포 용이하게 함
클라우드에서의 실행 vs 각 개인 장비에서의 실행
시나리오 후보들
- ec2
ec2에 도커 엔진 다 깔고 각 수집 대상 브랜드명 arg로 주고 컨테이너 돌려서 동시에 수집
- 한 ec2 내 컨테이너 병렬 * ec2 개수로 병렬처리 꿈꿨으나
- 프리티어로 돌리려면 t2.micro가 1 core, 1GB RAM, 달에 750시간 줌(인스턴스 런타임 총 합)
- -> 도커 여러개 띄워봤자 병렬 처리가 아니라 시분할임
- 모두의 개발장비 로컬에서 돌리는게 오히려 리소스가 더 많음
- Lambda
- 컨테이너 환경 주고 거기서 handler 함수 실행되도록
- 최대 실행시간 15분, 몇 시간씩 돌리고 있어야하는 현 상황에는 적합하지 않음
- Fargate
- 컨테이너 서버리스로 구동할 수 있음, 장시간 가능
- 초단위로 과금된다고 해서 폭탄맞을끼봐 두려움(정확한 계산은 안해봤으나 현재의 저희의 실행시간을 고려해보면 두려울 수 있을 것 같습니다.)
So...
- 학습 데이터 수집 - 기존 수집 방법으로...
- 각자 로컬 환경에서 장시간 실행시켜놓을 수 있도록 먼저 컨테이너 환경으로 잘 패키징 & 격리 시켜둬서 학습 데이터 수집한 이후
- update 데이터 수집은 개발해둔 컨테이너 + 소스코드 써서 클라우드에 배포(실행시간 더 짧을 테니까) + 작업 스케줄링 시도해보는 걸로..
To Do
- 기본 실행 도커 이미지
- handler 함수 개발, 테스트(람다 entrypoint)
- 올리브영 수집 코드 유튜브 arg 받는 부분이랑 코드 얼라인시키기
- 쉘스크립트 개발 - 검색키워드1:컨테이너1 로 컨테이너 여러 개 동시에 띄워서 running -> 병렬 처리(제대로 격리시킨 멀티프로세싱 같은..)
- 실행 테스트
- 로깅, 유틸 등 코드 통합