문제점: 잘못된 이름으로 만들어진 공통모듈직전 글에서 uv 를 이용해서 Python Monorepo 를 구성하였습니다. 대략 이런 모습이었죠. shared 에 있는 모듈을 services 에서 끌어다 쓰는 구조입니다.이 구조 자체는 괜찮은데, 저의 미숙함때문에 치명적인 문제가 생겼습니다. 바로 너무 일반적인 이름을 사용했다는 점입니다.services 하위의 app에서도 언제든지 exception, logger 와 같은 파일을 정의해서 사용할 수 있기에 충돌 가능성이 있습니다. 즉, 공통모듈을 사용하는 개발자 개개인이 조심해야하는 문제점이 생깁니다. 실무에 집중해야하는 개발자에게 큰 스트레스겠죠? 이 문제를 해결했던 과정을 공유하겠습니다.원하는 결과물가장 일반적으로 문제를 해결하는 방식은 shared 밑에..

Python&FastAPI 위주로 MSA 를 구성하면서 codebase 는 monorepo 형태를 차용했습니다. 이 글에서는 Python으로 MSA를 만들 때 uv를 통해 어떻게 monorepo 형태로 구성할 수 있는지 경험을 공유하고자 합니다.monorepo 란?monorepo 는 polyrepos(혹은 multi-project)에 대응되는 개념으로, 하나의 Git 저장소에서 여러 모듈(서비스‧라이브러리)을 함께 관리하는 전략을 말합니다. 동일한 논리적 변경을 하나의 Commit 또는 PR(Review)로 묶을 수 있고, 저장소별 권한·CI/CD 파이프라인을 중복 정의할 필요가 없다는 점이 가장 큰 장점입니다.반면 “거대한 모놀리식 시스템(모놀리식 코드베이스)과 같다”는 오해도 있지만, 코드 관리 방식..

서비스 하나에 대해서 REST 서버와 gRPC 서버를 따로 운영하면서 재밌지만 다소 버겁다고 생각하고 있었습니다. 그러던중 GraphQL까지 추가되었지요. 내부 비지니스 로직은 통합했더라도 여러 프로토콜을 운영하는건 공부할 내용도 많고 어떤일이 발생할지 불명확하여 두려운 일입니다. REST, gRPC, GraphQL 이 셋을 하나로 혹은 둘로만 줄일 수 있어도 참 좋겠다고 생각하고 찾아보던중 gRPC Gateway 라는 개념을 발견했고 이를 공부해보았습니다. 과연 현실적으로 개발 공수를 줄일 수 있을지, 그리고 운영하면서 추가적인 이슈를 만들어내지는 않을지 알아보았습니다.gRPC gateway개념gRPC Gateway는 gRPC 서버를 HTTP/JSON API처럼 사용할 수 있게 중간에서 변환해주는 서버..

모놀리식으로 개발했던 시스템들을 MSA로 전환하면서 실수를 보완하고 변경된 요구사항에 맞춰서 많은 것들을 바꾸고 있습니다. 특히 부동산 프로젝트 관리 도메인을 마이크로 서비스로 만들때는 다양한 프로젝트 관련 메타데이터들을 RDB에서 어떻게 관리할지 고민이 되었습니다. 어떤 문제를 인지했는지, 어떻게 해결했는지 공유하겠습니다.문제인지프로젝트 관리를 위해서는 프로젝트에 적절히 메타데이터를 부여해야했습니다. 이러한 메타데이터는 N 개로 늘어날수도 있으며, 심지어 하나의 메타데이터 카테고리 안에서 위계가 생겨나는 중이었죠. 처음에는 가볍게 생각했습니다. "000 이라는 카테고리에 하위 개념이 생기면 테이블 하나 더 만들지 뭐!" 하지만 얼마 지나지않아 그렇게 풀면 안되는 문제라는 것을 깨달았습니다.매번 위계가 ..

gRPC를 왜 써야했는지, 그리고 어떻게 구현해야하는지 알아봤습니다. 이제는 그래서 도대체 왜 gRPC가 빠른건지 이론적인 배경을 정리하겠습니다.gRPC 성능의 핵심 이론gRPC가 빠른 가장 큰 이유는 통신 계층의 개선(HTTP/2)과 데이터 표현 방식의 개선(Protocol Buffers)에 있습니다. HTTP/2가 제공하는 멀티플렉싱, 헤더 압축 등의 기능과, 프로토콜 버퍼를 통한 바이너리 데이터 직렬화가 결합되어 지연을 줄이고 처리량을 높입니다. 주요 이론적 요소를 정리하면 다음과 같습니다.HTTP/2 멀티플렉싱오늘날에 일반적인 웹 통신은 HTTP/1.1 버전을 따릅니다. 하지만 gRPC는 HTTP/2를 따르도록 되어 있으며, HTTP/2는 하나의 TCP 연결에서 동시에 여러 요청과 응답을 주고받을..

이전글에서 REST, gRPC 그리고 GraphQL를 비교해봤습니다. 이번에는 Python의 GraphQL 사용을 돕는 라이브러리를 비교해보려고 합니다. 솔직히 말하자면 FastAPI 유저인 저에게는 FastAPI가 공식문서에서 추천한 Strawberry가 정답으로 자리잡고 있고, 이미 Strawberry를 이용해서 구현했지만 공부하는 차원에서 각 라이브러리의 사용성, 문서화와 개발자 경험(DX), 타입 지원, 웹 프레임워크 통합성, 프로젝트 유지보수 및 커뮤니티 현황을 살펴보겠습니다.왜 라이브러리 비교기준에서 성능이 빠졌을지 의문을 가질 수 있습니다. 하지만 물론 저도 처음에는 알아봤지만 GraphQL 서버 성능은 주로 쿼리 실행 엔진의 효율과 리졸버에서의 I/O 처리 방식에 따라 좌우되며, 세 라이브..

기존에 REST 와 gRPC로 데이터를 서빙하던 FastAPI 서버에 GraphQL을 도입하게 되었습니다. 필드가 많은 데이터를 서빙하는 서버였는데, 다수의 클라이언트에 서로 다른 인터페이스의 API를 서빙해야 했습니다. 그렇다면 REST 보다는 데이터 질의가 유연한 GraphQL을 도입하는게 좋겠다는 결론을 내렸고, 이미 잘 만들어진 라이브러리와 공식문서 덕분에 3일만에 배포할 수 있었습니다. 일단 구현은 했고, 이제는 블로그에 글을 연재하면서 관련 이론과 케이스 스터디를 진행해보려고 합니다. 이번 글에서는 REST와 gRPC 그리고 GraphQL의 개념, 설계철학을 알아보고 성능 특성을 비교하여 향후 프로젝트를 진행할때 적절한 기술을 선택할 수 있는 기반을 다지고자합니다.REST: 리소스 중심의 AP..

Python Web 개발을 FastAPI로 시작하다보니 비동기 상태에서 Python을 다루는게 너무나 당연했습니다. 그동안 막연히 Python을 비동기적으로 쓰려면 asnyc 를 써야지 생각만해왔습니다. 주말을 맞이해서 이번에 그 기반을 닦아보려고 합니다. 오늘은 그래서 asyncio 는 무엇인지 그리고 왜 필요한지, node.js와의 차이점은 무엇인지 등을 알아보고 정리하려 합니다.asyncio란 무엇인가?공식 문서에서는 asyncio를 “async/await 문법을 이용하는 동시성(concurrent)처리를 위한 라이브러리" 라고 소개하고 있습니다. 이러한 asyncio 라이브러리를 이용하여 IO bound 되어있는 작업을 효율적으로 처리할 수 있고, 이러한 이유로 고성능 웹 프라임워크, 네트워크 연..