EC2 내부에 docker-compose를 사용하여 Airbyte를 생성하고, Source는 AWS RDS 위에 운영되는 MySQL, Destination은 Snowflake로 각각 커넥터 설정을 하였습니다. 해당 설정을 하여 CDC를 진행했을 때 겪었던 상황과 해결 방법을 작성하였습니다. MySQL에서 1억건 이상의 테이블에 대한 초기 마이그래이션 시 리소스 고려 Airbyte는 CDC 이전 초기 연결 시 테이블에 대해 Source에서 Destination으로 마이그래이션을 진행합니다. 마이그래이션 시 RDS 리소스도 중요하지만 EC2 리소스를 더 많이 사용합니다. RDS는 Task 당 커넥션을 하나만 사용하지만, EC2는 돌아가고 있는 모든 Task들을 관리해야 하기 때문입니다. 1억건 이상 테이블 당 마이그래이션 시 RDS 리소스는 db.m6i.2xlarge 기준 CPU 점유율이 2% 정도 상승하였습니다. 반면 EC2는 c7i.4xlarge 기준 CPU 점유율이 20% 되었습니다. 그래서 EC2 c7i.4xlarge 기준 1억건 이상 테이블을 5개 이상 한번에 적재하는 경우 CPU 리소스가 부족할 수 있습니다. 그래서 초기 마이그래이션 시 테이블 하나당 EC2 c7i.xlarge 기준으로 생각하여 고려하고 있는 병렬 처리 테이블 개수만큼 인스턴스 크기를 늘려서 짧은 시간에 마이그래이션을 완료할 수 있도록 합니다. CPU 리소스가 부족한 경우, Sync 과정에서 중지가 될 수 있으며 지금까지 받은 데이터를 모두 날리고 새로 받아야 하는 경우도 생길 수 있습니다. CDC를 위한 RDS MySQL 설정 수정 시스템에서 사용하는 DB에는 별도 설정없이 기본값으로 사용하는 경우가 있습니다. 그런 경우 MySQL에서 복제, 동기화 등의 목적으로 사용하는 binlog 에 대한 설정도 기본값인 경우가 대부분입니다. binlog 설정 시 확인했던 부분은 다음과 같습니다. binlog 확인: SHOW binary logs; RDS 내부 설정 확인: CALL mysql.rds_show_configuration; 설정 확인 후 MySQL에서 binlog를 수정한 내용은 다음과 같습니다. RDS 파라미터 그룹 수정 RDS 파라미터 그룹은 MySQL 중지없이 설정 변경 시 즉시 적용되어 binlog 관련 설정을 운영에 지장없이 변경할 수 있었습니다. binlog_format: MIXED -> ROW (CDC Required) binlog_row_image: null(full) -> full (CDC Required) MySQL 내부에서 프로시저 실행 해당 프로시저 또한 MySQL 중지없이 실행으로 설정을 변경할 수 있었습니다. CALL mysql.rds_set_configuration('binlog retention hours', 25); binlog에 대한 retention 시간을 25시간으로 두었기 때문에, 25시간 이상 간격이 필요한 CDC에는 설정값을 높힐 필요가 있습니다. 초기 MySQL에서 Snowflake 테이블 적재 시 대략적인 소요 시간 적재하는 Source나 Destination의 종류, Airbyte가 서비스되는 플랫폼의 종류 및 인프라 제원 등에 따라서 마이그래이션 시간은 상이할 수 있습니다. 이 부분을 참고하셔서 대략적으로 참고하실 수 있도록 테이블 마이그래이션 및 CDC 결과 공유드립니다.

팀장님이 UI 기반의 스케줄러를 요구사항으로 요청하였습니다. 신규 프로젝트여서 익숙한 Airflow를 사용하고 싶었으나, JS7 Scheduler를 추천해주셔서 내부에서 테스트를 해보아야 하는 상황입니다. 그래서 제품을 확인해보려고 구글링(+perplexity)을 해보았지만 문서나 포럼 외에 사용 사례나 리뷰 등이 부족하였습니다. 그래서 직접 공부를 하면서 사용하는 방법을 테스트해보고 트러블 슈팅한 부분을 공유하기 위해서 블로그에 글을 작성합니다. 대부분의 요소들은 공식 Documentation을 참고하여 작성하였습니다. 1983년 베를린에서 설립된 회사에서 2005년부터 오픈소스로 스케줄러를 오픈하여 개발, 운영 IT 자동화, 비즈니스 프로세스 자동화, 데이터 처리 및 ETL 작업, 클라우드 및 온프레미스 환경에서의 작업 스케줄링, 복잡한 워크플로우 관리 등에 사용합니다. 주로 Control-M의 오픈소스 대체제로 소개, 내부망을 사용하는 금융권에서 사용하는 것 같다고 몇몇 글을 보고 추측은 되는데 실제 사용한 국내 레퍼런스를 찾을 수가 없습니다. 라이센스 정책 JS7 JobScheduler와 YADE 제품은 고객에게 오픈 소스 라이선스와 상업용 라이선스 중에서 선택할 수 있는 듀얼 라이선스 모델로 제공 오픈 소스 라이선스 GPLv3(일반 공중 라이선스)에 따라 제공 SOS의 상용 라이센스 구매 유일한 예외는 기업 고객을 위한 상업적으로 이용 가능한 기능인 고가용성을 위해 JS7 제품을 클러스터링하는 운영 기능 초기 해당 제품을 사용하여 피봇팅을 하는 경우 단일 컨트롤러에 독립형 에이전트를 여러개 사용할 수 있으나, 규모가 확장되고 SPOF를 피하는 목적으로 에이전트 클러스터링을 고려할 수 있음 아키텍처 구성요소 Controller 컨트롤러는 실행할 워크플로와 작업, 실행 시기, 실행에 사용할 에이전트를 알고 있습니다. 컨트롤러는 JOC Cockpit에서 작업 관련 인벤토리를 수신하고 이 정보를 각 서버에서 워크플로우와 작업을 실행하는 에이전트에 배포합니다. 독립형 컨트롤러는 에이전트를 오케스트레이션하는 단일 인스턴스입니다. 할당하는 에이전트의 개수는 무제한입니다. Agent 에이전트은 에이전트 서버에서 실행 파일 및 명령을 호출하는 작업을 실행합니다. 에이전트는 컨트롤러로부터 시작할 잡과 시작 시점에 대한 정보를 받습니다. 에이전트는 실행 결과와 로그 출력을 컨트롤러에 다시 보고합니다.

2022년에 작성한 글을 욺겨 담았습니다. 라벨링을 할 때 자동화를 하지 않는 이상, 사람 개인마다의 인지와 라벨링 가이드라인이 가장 중요하다 생각하여 해당 글을 작성하였습니다. 다른 블로그에는 너무 원론적인 말이 주로 있었기 때문이였습니다. 1. 라벨링(Labeling)이 뭔가요? 어떤 데이터가 있다. 해당 데이터는 이미지나 글자, 소리 등이 될 수 있다. 해당 데이터는 자체적으로 정보(Information)를 나타내고 있다. 하지만 데이터 내 정보 속에 담긴 의미(Knowledge)는 정보를 보고 찾아야 한다. 데이터 속에 정보(Information)을 찾아 지식(Knowledge)를 만들어내거나 기입 또는 연결하는 것을 라벨링이다. 라벨링을 통해서 정보를 지식으로 가공하고 이를 컴퓨터가 머신러닝 학습하여 지식을 습득하여 지혜(Wisdom)으로 만들 수 있다. DIKW 피라미드를 생각하면 좀 더 이해하기 쉽다. 데이터에서 나타나는 정보에 대해서 지식를 찾는 작업이 라벨링이다. 라벨링한 지식을 가지고 머신러닝 학습을 진행하고 나타나는 패턴을 찾는 것이 지혜(Wisdom)으로 볼 수 있다. 2. 혹시 예시 좀 들어주실 수 있나요? 예시를 들어보면 아래의 그림으로 강아지 4마리가 사람과 같이 있고, 사람들이 뒤에 앉아있는 사진이 있다. 해당 사진에서 사람은 쉽게 강아지 4마리와 사람이 어디 위치에 있는 지 쉽게 찾을 수 있다. 하지만 이를 컴퓨터가 찾아야 한다면 이야기는 달라진다. 컴퓨터는 강아지와 사람을 특별하게 구별할 수 없다. 그렇기 때문에 강아지와 사람이 저 이미지 화소 중에 어디어디 부분을 가르키는 건지 라벨링을 해줘야 한다. 개개인이 갖고 있는 지식을 사용하거나 개와 사람에 대한 인지학습을 한 후 라벨링 진행한다. 3. 만약 라벨링을 하는데 사람이 데이터를 이해하지 못하면 어떻게 하나요? 라벨링은 얻고자 하는 정보를 데이터에서 취득 후 지식으로 변환하는 작업이다. 사람이 데이터를 이해하지 못하는 것은 얻고자 하는 정보를 찾지 못한다는 것과 동일한 이야기이다. 라벨링 작업 시 가장 중요한 것은 라벨링을 통해서 얻고자 하는 것이 어떤 것인지 분명하게 알아야 한다. 이를 알아야 목적에 맞게 라벨링을 할 수 있다. 라벨링 프로젝트에서 작업 수행 전 해당 데이터를 어떻게 사용하고 어떤 정책으로 라벨링을 하는 지에 대한 가이드라인을 작성해서 배포한다. 가이드라인 작성 시 데이터를 어떻게 사용하려는 지에 대한 내용이 녹여저서 제공이 된다. 이를 바탕으로 데이터에 대한 이해를 완료하고 작업을 시작해야 완성도 높게 작업이 완료된다. 얻고자 하는 목표가 무엇인 지 모르고 하는 라벨링은 밑빠진 독에 물붇는 격이다. 4. 라벨링을 연습하고 싶은데 추천해주고 싶은 사이트가 있나요? CVAT(Computer Vision Annotation Tool)에서는 본인이 준비한 이미지 데이터를 가지고 직접 라벨링해볼 수 있다. 무료이고 간편하게 연습해볼 수 있어서 추천한다. 사용 방법 CVAT 2.13 버전 기준입니다. 위 링크에 접속을 하면 간단한 회원가입 후 우측 상단의 + 버튼을 하이라이트하여 Create a New Task를 누른다. 이름(Name)에 연습할 데이터를 대표하는 제목을 작성한다.

개요 Airbyte를 EC2에서 운영하다보면 어느 시점에 할당한 디스크 용량이 부족한 경우가 발생할 때가 있습니다. 해당 이슈를 탐지하지 못하는 경우에 디스크 용량이 꽉차게 되어 Airbyte가 동작하지 않는 상황이 발생할 수 있습니다. 이 경우 CDC(Change Data Capture)가 정지되기 때문에 미리 대응하는 것이 중요합니다. Airbyte 운용 시 디스크 용량을 많이 차지하는 요소 확인 Airbyte는 Source와 Destination을 연결하는 커넥터를 설정 후 사용하는 방식입니다. 각각은 도커 컨테이너로 구성되어 있고 커넥터의 업데이트 시에는 컨테이너 이미지를 다운로드 받아 사용합니다. 사용자가 설정한 시간에 각 단위 별로 커넥터가 동작하는 것을 Task라 하는데, 동작하는 위치마다 로그가 발생하게 됩니다. Task에서 발생하는 리텐션 기간이 30일로 기본값으로 잡혀있습니다. 기본적으로 리텐션 기간 이전까지는 운영 시 로그가 비교적 많이 적재됩니다. 적재 주기와 리텐션 기간을 고려하여 처음에 디스크 용량 산정 시 넉넉하게 주는 것이 좋습니다. 하지만 한달 이후로 운영하다보면 계속적으로 조금씩 Airbyte 컨테이너 용량이 증가하는 것을 확인하실 수 있습니다. 이를 확인하기 위해서 컨테이너 별 용량을 확인해야 합니다. 용량을 확인했을 때 많이 차지하는 컨테이너는 airbyte-server 와 airbyte-worker 로 확인했습니다. Airbyte 컨테이너 내부 확인 이후 컨테이너 내부로 들어가서 어떤 데이터가 용량을 많이 차지하는 지 확인해야 했습니다. airbyte-server에 들어갔을 때 있었던 파일들은 다음과 같습니다. (airbyte-worker 도 상황은 동일하였습니다.) 두 컨테이너에서 모두 build.log 파일이 비대하게 적재되어 있는 부분을 확인했습니다. 로그 파일에서는 내부에서 동작하는 부분에 대해서 로그를 남기고 이상 발생 시 트래킹 할 수 있도록 구성되어 있었습니다. 해당 로그는 운영에 이상을 주기 때문에 S3로 백업 후 삭제하였고, docker compose restart 로 컨테이너를 재부팅하여 삭제된 로그의 캐시를 제거하였습니다. 한계점 사실 위와 같이 작업한다면, 이후 계속적으로 사람이 수작업으로 백업 — 삭제 — 리부팅을 해줘야 합니다. 운영 상 사람으로 발생하는 피해를 줄이기 위해서 자동화를 해주는 것이 좋습니다. airbyte-server 와 airbyte-worker 컨테이너 내부에 build.log의 리텐션을 조정할 수 있는 방법을 찾지 못하여서 이를 아시는 분은 댓글 부탁드립니다:) Reference Understand Airbyte Docker 용량 확인 및 관리

AWS 키가 Github를 통해 노출이 되서 해킹으로 천만원 넘게 과금이 되고, 이를 AWS에서 도와주는 경우를 종종 들었습니다. AWS 키 노출 키워드로 구글에 검색하면 이에 대한 썰(?)을 어렵지 않게 찾아볼 수 있습니다. 키 노출 이슈가 개인이나 기업에서 중대하게 작용하기 때문에 이에 대한 대비책들도 존재합니다. 이외에도 개발을 하면서 서버나 DB, API 등에 접근하기 위해 비밀 키 등을 사용합니다. 이러한 비밀들이 Git 리포지토리에 커밋이 되었는 지를 확인해주는 오픈소스 도구인 Gitleaks에 대해서 소개해드리려고 합니다. Gitleaks Gitleaks는 Git 리포지토리의 비밀번호, API 키, 토큰과 같은 하드코딩 된 비밀을 감지하고 유출을 방지하는 SAST(Static Application Security Testing, 정적 어플리케이션 보안 테스트) 도구입니다. Go로 작성되었으며, Homebrew, Docker, Git Repo, Pre-commit, Github-Action 등으로 설치하여 사용할 수 있습니다. 아래는 Homebrew를 통해서 맥 로컬에 설치하는 방법입니다. Gitleaks를 통해서 찾을 수 있는 비밀은 여러가지가 있고, Github Repo에서 각 규칙(총 137가지)들을 확인할 수 있습니다. 만약, 찾는 규칙이 없다면 오픈소스에 직접 기여해보는 방법도 추천드립니다:) Gitleaks를 만약 로컬에 설치했다면, 실행하는 방법은 다음과 같습니다. 157개의 커밋된 Git Repo를 Gitleaks로 검사했을 때 1.49초만에 완료하고, 찾은 비밀은 없는 경우입니다. Gitleaks 설정 Gitleaks로 검사할 때 탬플릿에 목업으로 적어놓은 키 같이 필터링을 해서 비밀키를 찾아야 하는 경우가 있습니다. 이를 위해서 config 파일을 제공합니다. config 파일은 Git Repo가 위치한 루트 패스에 .gitleaks.toml 로 저장하면 별도 스크립트 추가없이 실행할 때 자동으로 설정이 적용됩니다. .gitleaks.toml을 통해서 설정을 했음에도 불구하고 커밋된 목업 키가 계속 찾아진다면 .gitleaksignore 를 통해서 검사를 무시할 위치를 추가합니다. 위처럼 테스트에서 사용하는 키가 Gitleaks 검사 시 나왔고 해당 키는 검사에는 제외하고 싶습니다. 이런 경우, .gitleaksignore에는 Fingerprint의 값을 추가하면 다음 검사부터는 해당 커밋의 키는 검사하지 않게 됩니다. gitleaks로 검사를 했을 때 나온 파일들이 이상이 없는 경우, report로 나온 파일을 사용하여서 기준점을 만들 수 있습니다. (해당 기능을 사용하여 리포팅도 가능합니다.) 재 검사 시 기준점 이후 나온 항목들에 대해서만 추출하는 방식으로 검사할 수 있습니다. Case Study: Apache Airflow에 Gitleaks 써보기 Github에는 수많은 레포들이 존재합니다. Case Study를 위해 클론하여 테스트 해 볼 레포는 데이터 파이프라인을 구축할 때 자주 사용하는 Apache Airflow로 정했습니다. 커밋의 수가 많고, 프로젝트 기간이 오래되어서 확인해보기 좋을 것 같았습니다. Gitleaks를 사용하기 위해 먼저 Airflow Repo를 클론합니다. 작성일 당시 main 브랜치가 25,000 커밋 정도 되었기 때문에 Repo 크기가 큽니다. 클론 시간이 조금 걸릴 수 있습니다. 이후, CLI(Bash, Zsh…)에서 Gitleaks를 실행합니다.