container orchestration 서버의 상태를 관리하기 위한 노력 중앙제어 (master-node) 클러스터 단위로 추상화해서 관리 master server를 이용하여 관리자가 master server에 명령하면 master가 클러스터에 명령함 상태 관리 ex. 컨테이너가 3개였으면 좋겠어 -> 하나가 죽으면 새로운 하나를 생성 배포 관리 여유로운 서버를 찾거나 생성하여 스케줄링을 할 수 있음 배포 버전관리 각 컨테이너들의 버전을 중앙에서 관리할 수 있음 서비스 등록 및 조회 볼륨 스토리지 kubernetes (k8s) 컨테이너 기반 서비스 배포/스케일/관리 자동화를 해주는 오픈소스 프레임워크 구글에서 사용하던 Borg 서비스를 오픈소스화함 클라우드 on-prem 모두에서 잘 동작 모든 컨테이..
Docker-Compose 다수의 Container로 소프트웨어가 구성되는 경우 사용할 수 있는 툴 + 환경설정파일 docker-compose.yml(yaml)로 설정 여기서 다양한 테스트등도 수행가능 다양한 버전을 만드는 것도 일반적 (dev, test, prod 등등) 개인적으로 개발할 때 product일 때 등등.. 개별 Container를 따로 관리하는 것보다 훨씬 더 생산성이 높음 사용법 자체는 간단함, 소프트웨어를 구성하는 모든 컨테이너에게 적용됨 docker-compose up: docker run과 동일 docker-compose down: 컨테이너 중지 및 삭제까지 진행, 이미지는 그대로 있음 docker-compose pull: 그룹으로 진행 Docker Desktop의 일부로 설치됨 ..
Docker Volume의 필요성 Docker Container가 실행되었다가 중단되면 데이터들은 어떻게 될까? -> 유실됨.. 특정 소프트웨어가 Docker Container를 통해 일회성으로 동작하는 것이 아니라 지속적으로 동작해야 한다면 데이터가 영구적으로 보관되어야 함 ex. 데이터베이스가 docker container안에서 동작한다면? 이를 보장하는 기능이 Docker Volumes -> Data Persistence Docker Container내의 가상 파일 시스템과 호스트 시스템의 파일 시스템을 매핑 ex. 호스트 파일 시스템의 /home/hyangsso/logs를 Docker Container의 /var/lib/airflow/logs로 매핑 이 경우 Docker Container가 중단되..
소프트웨어 빌드 우리가 개발한 소프트웨어를 최종적으로 출시하기 위한 형태로 만드는 것 테스트가 빌드의 중요한 일부로 포함 테스트를 다 통과해야 패키지 포맷으로 만듦 테스트가 충분히 있어야 함 참여 개발자들이 많을수록 더 중요 개발이 끝나기 전부터 빌드를 하면 소프트웨어의 안정성 증대 -> Continuous Integration 개발자가 코드를 고칠 때 마다 테스트를 돌림 -> 테스트가 많아야 함 -> 작은 회사에서는 어려움 Continuous Integration (CI) 기본 원칙 코드 Repo는 하나만 유지 (master/main) 코드 변경은 최대한 자주 반영 테스트를 최대한 추가 Test Coverage 빌드를 계속적으로 수행 (자동화) Commit Build vs. Nightly Build 성..
관리해야 하는 DAG의 수가 100개를 넘어간다면? 데이터 품질이나 데이터 리니지 이슈 이외에도 다양한 이슈들이 발생 주로 발생할 수 있는 이슈 라이브러리 충돌 라이브러리/모듈의 충돌 이슈가 발생하기 시작함 DAG에 따라 실행에 필요한 라이브러리/모듈이 달라지기 시작 (ex. python 버전) 이로 인해 DAG 혹은 Task 별로 별도의 독립공간을 만들어주는 것이 필요 Docker to the rescue Dag 혹은 Task 코드를 Docker Image로 만들고 이를 독립된 공간(Docker Container)안에서 실행 Worker의 부족 해결책 scale up (언젠가 한계가 있음) scale out 클라우드 서비스 사용 K8s와 같은 컨테이너 기술 사용 필요한대로 서버 요청 Worker 서버..
ETL vs ELT ETL: 데이터를 데이터 웨어하우스 외부에서 내부로 가져오는 프로세스 보통 엔지니어들이 수행 ELT: 데이터 웨어하우스 내부 데이터를 조작해서 (보통은 좀더 추상화되고 요약된) 새로운 데이터를 만드는 프로세스 보통 데이터 분석가들이 수행 이 경우, 데이터 레이크 위에서 이런 작업들이 벌어지기도 함 이런 프로세스 전용 기술들이 있으며 dbt(Data Build Tool)가 가장 유명: Analytics Engineering Data Lake vs Data Warehouse Data Lake 구조화 데이터 + 비구조화 데이터 보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지에 가까움 보통은 데이터 웨어하우스보다 몇 배는 더 큰 스토리지 Data Warehouse 보존 기한이..
