FastAPI와 Uvicorn의 관계, ASGI

Python Web Server 및 Application Framework의 개념에 대해서 공부하면서 헷갈렸던 개념들을 정리하고자 한다.현재 회사에서 운영 과정에서 발생하는 수동 업무들을 시스템화하고자, 간단한 스택으로 백오피스를 구축한 후 지속적으로 유지보수하고 있다.팀이 Python 기반 스택을 갖고있다보니, 자연스럽게 FastAPI 프레임워크를 선택했고, 프론트 스택은 별도로 두지 않고 HTMX 기반으로 SSR Web Endpoint와 API Endpoint를 함께 제공하도록 구성하였다.Uvicorn에서 서빙하고 있고, 단일 worker로 올린 후 K8s 환경에서 배포하여 HPA 구성을 수행해 운영중이다.상세 아키텍처는 추후에 별도로 포스팅하고, 금일은 FastAPI를 배포하다 보면 uvicorn ..

• format_list_bulleted Tech/Backend
• · 2026. 6. 16.
• textsms

Next Arc Browser; Dia Browser 둘러보기 (현재 무료 !!!)

Main Browser로 Chrome을 주력으로 사용하고 있었는데, 문득 Arc Browser는 요즘 어떤지 싶은 생각이 들어 검색해보았다.최초 Arc Browser 출시 되어 사용했을 때 램을 많이 차지했던 경험이 있었고, Chrome으로 다시 넘어갔던 경험이 있다. Arc from The Browser CompanyExperience a calmer, more personal internet in this browser designed for you. Let go of the clicks, the clutter, the distractions.arc.net 접속 시 상단에 Try Dia 가 눈에 들어오는데, Browser Company는 현재에는 Arc 대신 Dia라는 새로운 브라우저에 집중하고 있..

• format_list_bulleted Tools/Etc
• · 2026. 6. 15.
• textsms

Browser 살펴보기 #1 - Chrome Process

자동화 및 스크래핑 관련 업무를 진행하면서, 브라우저 자체에 대한 이해도가 낮았음을 알 수 있었고, 이를 제대로 살펴봐야겠다 생각했다.오랜 기간동안 소식이 없던 포스팅도 같이 이어가려고 한다.단계적으로 실제로 사용하는 브라우저들을 직접 확인하면서 업무에도 잘 녹여보는 것이 목표이다. Chrome이 multi-processing인 이유어느 곳이었는지 정확하게 기억나진 않지만, 초기 브라우저들에서는 모든 탭을 하나의 프로세스 안에서 처리하는 단일 프로세스 구조여서, 한 탭에서 크래시가 발생하면 전체 브라우저가 함께 죽는 문제가 있었다. Chrome은 멀티프로세스 구조를 채택해 이 문제를 해결하여, 탭 하나가 크래시 나도 전체 브라우저는 유지될 수 있었다는 내용을 들었던 적이 있었다.이번 포스팅에선 Chrom..

• format_list_bulleted Tech/Etc
• · 2026. 6. 7.
• textsms

Spark Join Strategy 로컬에서 확인해보기

금일 포스팅에선 Spark의 몇가지 조인 전략에 대해 어떤 상황에서 사용하면 좋은지 실습을 하며 확인한 과정을 공유하고자 한다. 사용한 실습 코드들은 다음 레포에 존재한다.https://github.com/Choiwonwong/local-spark GitHub - Choiwonwong/local-spark: spark practice in localspark practice in local. Contribute to Choiwonwong/local-spark development by creating an account on GitHub.github.com 우선, 조인 실습은 테스트 셋을 통해 진행했는데, 레포 내의 join_test/data_gen.py 스크립트를 실행하여 간단히 생성할 수 있다. 해당..

• format_list_bulleted Tech/Data Engineering
• · 2025. 9. 10.
• textsms

로컬에서 스트리밍 파이프라인 올려보기 with AI

지금까지의 데이터 파이프라인 경험은 배치(Batch) 기반의 ETL이었다. Airflow, Hive, Spark 등을 활용해 정해진 주기로 데이터를 처리하는 방식에 익숙했다.상대적으로 실시간 데이터 처리는 깊게 다뤄볼 기회가 없었다. 하지만 데이터 엔지니어의 역량은 배치 처리뿐 아니라 스트리밍 처리도 필수적이고, 요즘은 실시간 처리가 중요하다고 느껴서 관련 스택을 제대로 공부해야겠다는 생각이 들었다.Kafka, 스트리밍 엔진, 스토리지 및 OLAP 엔진 등에 대해서도 공부한 내용들도 포스팅해야하지만, 로컬에서 간단하게 올려봐야겠다 생각되어 Claude & Gemini CLI 두 시니어 엔지니어분들와 함께 간단한 유즈케이스로 로컬에서 (다행히) 돌아가는 스트리밍 파이프라인을 만들어 금번 포스팅에는 해당 내..

• format_list_bulleted Tech/Data Engineering
• · 2025. 8. 31.
• textsms

Spark BufferHolder 메모리 한계 해결하기 - explode -> RDD Flatmap, 제너레이터

대용량 데이터 처리 과정에서 Spark BufferHolder 메모리 초과 이슈를 잡고 있었는데, 몇시간 전에 다행히 해결할 수 있었다. 금번 포스팅에선 특정 Time Slot에서 반복적으로 발생했던 Spark BufferHolder 메모리 초과 문제 상황과 해결 과정을 공유하고자 한다. 일반적인 Spark 튜닝으로는 해결할 수 없었고, udf & explode() 기반 처리를 RDD 스트리밍 처리 구조로 변경하여 문제를 해결할 수 있었다. 해당 변경을 통해 수백 ~ 수천만건 데이터도 처리할 수 있는 구조로 개선하여 Data Engineering의 성취를 느낄 수 있었다. 향후 전체 프로세스를 오픈하여 실제 검증을 진행할 예정이다. 환경spark 3.4.1pysparkhive(json) -> iceber..

• format_list_bulleted Tech/Data Engineering
• · 2025. 8. 19.
• textsms