카프카 구성요소

우연한 기회에 카프카 스터디를 하게 되었습니다. 업무에서 kinesis를 사용하고 있기는 하지만 항상 kafka에 대한 갈증이 있었고 이번 기회를 통해 kafka에 대해 구조적으로 파악하고 왜 kafka가 실시간 메세징 시스템을 지배하게 되었는지 파악할 수 있게 되기를 소망합니다.

UnLimitedParallelism

airflow에는 여러 구성요소가 있지만 그 중에서 Executor에 대한 공부를 가장 소홀히 했다는 생각이 듭니다. 코딩을 하며 가장 많이 만나는 각종 Operator은 그 기능이 직관적이기 때문에 내부 코드를 굳이 보지 않아도 사용에 큰 지장이 없고 보더라도 그 구조가 간단한 경우가 많습니다.

대부분 파일로 저장하는 데이터들은 그 원본이 바뀌는 일은 많지 않습니다. 일자별로 파티션을 나누거나 적재된 시간을 기준으로 데이터를 ETL하면 원본이 변경되지 않는 한 동일한 결과를 도출할 것입니다.

DAGFactory를 만들려다 보니 자연스럽게 TaskFactory에 대한 필요성을 느꼈습니다. Medium에서 찾아본 DAGFactory에 대한 포스트들도 대부분 TaskFactory도 같이 만들던데, 직접 구현해보니 의식의 흐름과 같이 TaskFactory가 필요함을 알 수 있었습니다.

약 8개월 전 회사에서 개발해 사용했던 airflow를 클라우드로 옮기면서, 2.0 업데이트를 하고자 마음먹었고 필연적으로 코드 리팩토링에 대한 필요성을 느껴 리팩토링도 함께 진행중입니다.

8월 31일에 MWAA(Amazon Managed Workflows for Apache Airflow)가 서울 리전에도 출시되었습니다. 짝짝!!

firehose는 data stream의 consumer로 등록 가능한 aws 서비스입니다. broker인 data stream에 있는 데이터를 특정 목적지(s3, redshift, http…)로 보내주는 역할을 하는데, 중간에 끼워넣을 수 있는 transform 단계로 lambda와 glue catalog table이 있습니다.

최근 실시간 로그 수집을 위해 kinesis를 도입했습니다. 앞단에서는 k8s 환경으로 배포된 fastapi 어플리케이션이 로그를 받고, 여기서 여러 군데로 로그를 전송하는데 그 중 하나가 kinesis입니다. 안정적으로 kinesis를 가용하기 위해 공부하고 테스트했던 사항들을 기록합니다.