들어가기에 앞서 이번에 RAG를 이용한 채용정보 챗봇 구축을 위해 Azure 쿠버네티스 환경(통칭 AKS)에서 ETL 프로젝트를 해보기 위해 아래와 같은 계획을 짰다. 프로젝트 환경에 airflow를 띄우고 주기적인 크롤링 SPARK를 통한 데이터 마트 구축 GPT-3 토크나이저를 이용한 데이터 임베딩 크로마 DB에 데이터 적제 이거 할 생각에 잔뜩 기대하고 허겁지겁 일단 AKS 위에 쿠버네티스를 올린 후 pod에 airflow를 올리고 DAG를 GIT으로 관리할 수 있게끔 구성했다. ACR(Azure Container Registry)도 만들어 도커로 환경 배포까지 자동화를 해놨으나 결국 무산 되었다… 그 이유는 바로 비용문제이다. 일단 내가 개발한 크롤러로 데이터를 수집하면 데이터의 형태가 다음과 같다. 여기서 문제가 바로 ‘detail_data’다. 이 데이터를 , , 그리고 프롬프트만해도 이 엄청나다. 근데 해당 기능은 필수적인 기능이라 데이터 엔지니어링 파트에서 비용 절감…

드디어 글또 10기를 시작하게 되었다. 드이어 글또 10기를 시작하게 되었습니다!!! 이번에 글또 10기를 시작하게 되어서 너무 감사하다. 이렇게 좋은 습관과 네트워킹을 만들 수 있게 해주신 변성윤님께도 감사하고 알맞은 시기에 또 글또 10기 모집 글을 다시 한번 확인한 스스로에게도 감사하다. 전체적으로 글또 10기를 위해서 다짐한 사항이 몇가지 있다. 그러기 위해서는 나의 9기 활동으로 가봐야 한다. 잠깐 그전에!! 아직 글또가 뭔지 모르신다구요? 아래 이미지를 눌러주세요 총총.. 글또 docs A few months ago… 내가 다짐했다는 것은 9기에서 느낀 아쉬운 부분이 있었다는 것이다. 9기보다 이런 부분에서는 더 나아져야겠다 라는 생각을 글로 풀어보고자 한다. 1. 경험한 사실 보다는 생각과 느낀점에 대한 글을 쓰기 “이게 무슨 소리인교..?” 할 수 있지만 내가 쓴 글을 돌아보면 항상 내가 경험한 사실에 대해서 썼을 뿐, 그래서 내가 이걸 경험하면서 느낀 어려움과 깨달…

들어가기에 앞서 최근에 BOAZ 동아리에서 Oauto2와 goole calender를 이용해서 웹 서비스를 만드는 프로젝트를 진행하는데(계획에 전혀없던 리액트까지 써보는중🥲) 전반적인 인프라 구성을 내가 맡았다. 이때, 도메인을 AWS EC2에 등록하는 과정에서 로드밸런서를 사용하게 되었다. ALB 로드 밸런서에 SSL 인증을 적용하면 각 Ec2 인스턴스 마다 SSL을 처리하지 않아도 HTTPS 트래픽을 처리할 수 있기에 반드시 필요한 부분이었다. 그 과정에서 로드 밸런서를 단순히 “그냥 부하분산 아님?”으로 알고 있던 나에게 개념정리가 꼭 필요한 부분이라 이번 글을 작성하게 되었다. 그럼 시작해보자 시작해보자 Core 기본적으로 로드밸런서는 Scale out에서 사용된다. 서비스는 성장하는데 늘어나는 트래픽을 서버가 감당할 수 없을때 서버를 증설하는데 이 과정에서 각 서버에 걸리는 부하를 고르게 나누기 위해서는 로드밸런싱이 필수적으로 동반되어야 한다. 즉 다양한 곳에서 들어오는 …

들어가기에 앞서 kafka 토픽관리나 메모리 관리 그리고 SPARK 메모리나 yarn 그리고 프로케테우스와 그라파나 등이 잘 작동하는지 모두 cli로 관리하는것은 명백한 한계가 존재한다. 너무 불편하고 그게 다 시간 자원 빼먹는거다. 때문에 Web ui로 관리하는 것이 보통 굉장히 편한데 사용하는 리소스와 툴이 늘어나는 만큼 많은 Web ui를 띄워야 한다. 그동안 나는 포트 포워딩으로 모든 ui를 띄웠다. 이렇게 됐을 경우 단점은 인스턴스를 끄고 킬때마다 매번 포트포워딩을 수동으로 해주어야 한다는 것이다.그동안은 한번에 포트 포워딩을 해주는 .sh파일을 길게 만들어서 해결해왔으나 점점 감당하기 어려운 수준까지 갔다. 때문에 도입한 것이 바로 우리 팀원 로컬 내부의 hosts에 ip주소와 도메인 이름을 지정해두고 nginx로 ui를 띄울 수 있도록 설정해두는 방향이었다. nginx 설정 public-nat에 nginx 설치하여 http rewrite할 수 있도록 설정 먼저 ngin…

들어가기에 앞서.. 요새는 학교 과제를 위한 따릉이 대시보드가 아닌 한이음 ICT 공모전을 위한 따릉이 실시간 대시보드 구축을 진행중이다. 원래는 카프카로 데이터를 producing 하자마자 스피드레이어를 구축해서 대시보드에 마이크로 배치 형태로 실시간 대시보드를 구축했다면 이번에는 대시보드를 더 고도화하기 위해 Spark를 이용해 한번 형태 변환을 하고 S3에 적제하는 과정을 거져봤다. 즉, 아키텍쳐의 변화가 다음과 같다. 이전 아키텍쳐 변경 후 아키텍쳐 좀 많이 힘써봤다. 단순하게 실시간 모니터링만 하는 대시보드는 식상하기도 하고 솔직히 요즘 같이 Chatgpt가 발달한 시대에 그 정도 못만드는 사람 없을 것이다. 다만 이렇게 클라우안에서 다양한 툴과 함께 서비스를 제작한다는 것은 또 다른 개념이라 그 의미가 크다. 나는 위 아키텍쳐에서 카프카로부터 데이터를 실시간으로 받아 SPARK에서 변환 후 S3에 실시간으로 적제하는 Spark-Streaming 코드를 이번에 작성해봤다.…

들어가기에 앞서 이번에 AWS EC2를 이용해 NAT instance를 활용해 kafka broker를 구축했다. 이제 producer를 실행하면 자연스럽게 카프카를 사용할 수 있다.(리소스 비용 이슈로 프로듀서 서버를 따로 분리하지 않았다.ㅎㅎ) 다만 producer는 아직 본격적으로 개발한 상태가 아닐뿐더러 나중에 대시보드를 배포할 때 producer를 지속적으로 수정해야 한다. 때문에 계속해서 TEST를 해야 하는데 그 과정이 여간 불편한게 아니다. 매번 Ec2 키고 접속해서 주키퍼랑 카프카 올리고… 아무튼 생각보다 노력을 필요로 한다. 또 Github와 같이 producer의 버전을 관리하고 다른 사람들에게 공유도 용이하게 하기 위해서는 응당 구축해야할 것이 있다. 그것이 바로.. CI/CD다!! Devops의 기본 소양이자 DE라면 당연히 알아야 하는 CI/CD를 구현해보기로 했다. 다행히도 학교에서 젠킨스를 이용한 CI/CD 구현 수업을 들었기에 개념 정도는 꿰고 있었다…

Base 이번에 한이음의 일환으로 클라우드 환경에서 실시간 따릉이 대시보드를 만들게 되었다. 다만 내 역할이 데이터 엔지니어링 및 인프라에 국한되어 있어 개인적으로 오픈소스를 활용하여 로컬에서 하나를 더 만들어 보려고 한다. 때문에 레퍼런스를 찾던 도중 다음과 같은 글을 발견했다. https://medium.com/@emergeit/realtime-data-streaming-with-apache-kafka-apache-pinot-apache-druid-and-apache-superset-e67161eb9666 2년이 넘은 자료이기는 하지만 내 요구사항을 모두 만족했기에 아주 적합한 래퍼런스였다. 그럼 이제 시작해보자 시작해보자 Ddareungi real-time Dashboard architecture Dashboard architecture 위는 내가 수정한 아키텍처다. 신경 쓴 부분은 아래와 같다. Docker는 Superset을 올릴때만 사용하고자 한다. 레퍼런스에서는 모든…

사진카프카 로고 이번에 카프카를 로컬에서도 돌려보고 클라우드 환경에서도 다뤄보게 되었다. 그래서 카프카의 구조나 기본 개념에 대해 정리를 하고 가야할 필요성을 느꼈다. 물론 실제 구축을 할때는 인프라적인 측면에서 더 애를 먹는다. 방화벽 설정이라던지.. 그래서 기본적인 개념에 대해서는 약간 소홀해 지는 경향이 있었다. 아래 토픽 생성할 때의 shell 명령어를 보자 사실 이 문구를 그냥 copy/paste 한다면야 생성 가능하겠지만 라는 명령어가 어떤 의미인지 잘 모른다면 사실상 kafka를 사용하는 의미가 없다. 때문에 이번 기회에 깊이있게는 아니더라도 대략적으로 정리를 해보려고 한다. Back ground of Kafka Kafka는 왜 Kafka일까? 카프카의 창시자인 Jay Kreps는 kafka는 쓰기에 최적화된 시스템이기에 작가의 이름을 붙이는게 낫다고 생각하여 본인이 좋아하는 작가인 프란츠 카프카의 이름을 오픈소스 프로젝트 이름으로 명명했다. Before Kafka &…

AWS - jammy InRelease & 101: Network is unreachable jammy InRelease 오류 카프카 브로커 Ubuntu 서버에 java를 설치하려고 하는데 아래와 같은 문구가 뜨면서 동작이 되지 않았다. 무슨 jammy가 inrelease된 것 같은데 재미 하나도 없고 머리 아프다 다행히도 해당 에러에 대해서는 AWS측에서 답변 달아준 부분 있다. 공식 해결 방법 대충 해석을 보면 아래의 포인트들을 다시 체크해봐라 같은데 해석해보면 다음과 같다. 현재 EC2가 제대로 작동하는 다른 EC2들과 동일한 VPC 및 서브넷에 배포되었는가? 그게 아니라면 VPC가 인터넷 게이트웨이로 인터넷에 접근이 허용되어 있는가? 서브넷이 public이라면 인터넷 바운드 트레픽을 인터넷 게이트 웨이로 라우팅하는 라우팅 테이블이 있는가? 서브넷이 private이라면 인터넷 바운드 트래픽을 공용 서브넷의 NAT 게이트 위에이로 라우팅하는 라우팅 테이블이 있는가? 체크리스트…

NAT 인프라 이번에 실시간 따릉이 대시보드 제작 프로젝트에 데이터 엔지니어 및 인프라로 참여하게 되었다. 협업 및 배포의 용이성 때문에 클라우드를 이용하기로 결정이 났고 AWS에 EC2에 카프카 클러스터를 구축하고 프로듀서를 개발하기로 하였다. AWS를 이용한 협업은 처음이기에 세세하게 사전조사를 했는데 첫째로 알게 된 사실은 AWS에서 네트워크를 설계할때 NAT의 사용은 필수적이라는 것이다. 보안상 카프카 클러스터 서버들을 외부에서 접근할 수 없게 해야하기 때문이다. 때문에 VPC 인프라를 구축할때 Public 서브넷과 Private 서브넷을 만들어 그안에 EC2 인스턴스를 두고, Bastion Host를 통해 Public 서브넷에서 Priavate 서브넷으로 접속한 후, NAT Gateway를 통해서 외부 인터넷 소스를 사설망에서 받는 식으로 운용된다. 그만큼 중요한 것으로 당연히 AWS에도 관련 서비스인 NAT Gateway가 존재하고 그것을 이용해서 손쉽게 사설망 …

데이터 파이프라인 최적화의 필요성 대 빅데이터 시대인 만큼 데이터 파이프라인을 최적화하는 것은 굉장히 중요하다. 특히 MLOps 분야에서는 훨씬 더 중요하다. 왜냐하면 AI 성능이 기하급수적으로 발전하면서 그만큼 추론속도나 학습 속도 또한 굉장히 중요해지고 있기 때문이다. 사진 보편적인 최적화 방안이 존재할까? 그렇다면 데이터 파이프라인을 최적화하는 보편적인 정답이 존재할까? 내 대답은 No!다. 구축하는 파이프라인마다 도메인과 요구사항들이 모두 다르기 때문에 보편적인 요구사항이란 존재할 수 없다. 사진 보편적인 컴포넌트는 존재할까? 그렇다면 보편적인 컴포넌트는 중요할까? 내 대답은 Yes다. 보편적인 컴포넌트는 존재한다. 바로 DataLake다. 데이터 파이프라인은 “수집 -> 적재 -> 처리 -> 활용”의 단계를 거치는데 이때 적재 부분에서 실제 데이터를 운영용으로쓰는 경우에는 Datalake를 사용할 수밖에 없다. 따라서 datalake를 최적화 하는것이 결국 데이터 파이프라…

제목을 보면 이게 무슨 소리인가 싶을 수 있다. 나도 처음 듣고 띠요옹? 했었다. 내가 알고 있는 MongoDB는 BASE(BA: Basically Avaliable) 즉, 가용성과 성능을 중시한 분산 시스템의 특성을 가지고 있고 또한 이 점이 기존에 ACID 특성을 가진 RDBMS와의 차이점이라고 알고 있었다. 더군다나 Mongo DB가 탄생하게 된 배경이 아래와 같은 고민 끝에 탄생한 것을 알았기에 더욱 의아했었다. 대규모 데이터를 처리해야 하는데 RDBMS는 성장 한계가 있구나 일관성과 무결성을 버리고 더 빠른 읽기 성능과 수평확장이 가능한 DB가 필요해! 그럼 어쩌다 제목과 같이 눈이 크게 떠지는 질문을 스스로에서 던졌을까 이번에 대규모 시스템 설계 기초 도서를 공부하면서 CAP이론이라는 것을 처음 접하며 이 의문이 시작되었다. CAP이론 이란? CAP 이론은 2000년에 에릭 브류어가 최초로 소개한 이론이며 어떤 분산 시스템이더라도 Consistency (일관성), Ava…