FastAPI는 빠르고 효율적인 웹 프레임워크로, Python을 사용해 REST API를 구축하는 데 매우 유용합니다.이 프레임워크는 또한 의존성 주입(Dependency Injection)을 쉽게 구현할 수 있는 강력한 기능을 제공하여, 더 유연하고 확장 가능한 서비스 구조를 설계하는 데 도움을 줍니다.이번 글에서는 의존성 주입이 무엇인지, 그리고 FastAPI에서 이를 어떻게 적용할 수 있는지 살펴보겠습니다.SOLID 원칙과 의존성 역전 원칙 (DIP)SOLID 원칙은 객체지향 설계의 다섯 가지 주요 원칙을 의미하며, 소프트웨어 개발에서 유연성과 유지보수성을 높이는 데 중점을 둡니다.그중에서도 DIP(Dependency Inversion Principle, 의존성 역전 원칙)은 실무에서 특히 많이 활용되는 원칙 중 하나입니다.DIP는 고수준 모듈(비즈니스 로직)이 저수준 모듈(구체적인 구현체)에 의존하지 않고, 추상화에 의존하도록 설계함으로써 시스템의 결합도를 낮추고 유연성을 높이는 것을 목표로 합니다.아래는 이 구조를 시각적으로 표현한 다이어그램입니다.다이어그램에서 볼 수 있듯이, 고수준 모듈은 추상화된 인터페이스에만 의존하고, 구체적인 구현체는 추상화된 인터페이스를 구현하는 방식으로 설계됩니다.DIP는 쉽게 말해 구체적인 구현 대신 추상화에 의존함으로써, 코드의 수정 없이도 구현체를 교체할 수 있는 구조를 만드는 것을 의미합니다.이로 인해 비즈니스 로직은 데이터 접근 방식의 변화에 영향을 받지 않으며, 시스템의 유지보수성과 확장성을 크게 개선할 수 있습니다.DIP와 의존성 주입 (DI)의존성 주입(Dependency Injection, DI)은 의존성 역전 원칙(DIP)을 구현하는 방법 중 하나입니다.DI는 객체가 직접적으로 다른 객체를 생성하거나 참조하지 않고, 외부에서 필요한 객체를 주입받도록 함으로써 DIP를 실현합니다.이를 통해 시스템의 결합도를 낮추고, 구현체를 쉽게 교체하며, 테스트 용이성을 높일 수 있습니다.이번 글에서는 이러한 의존성 주입을 FastAPI에서 어떻게 활용할 수 있는지, 구체적인 예시를 통해 살펴보겠습니다.의존성 주입은 프로그램의 각 구성 요소가 서로 강하게 결합되는 것을 피하기 위해 사용하는 디자인 패턴입니다.보통 서비스 로직은 데이터 접근 로직과 같은 특정 모듈에 직접 의존하게 되는데, 이는 시스템의 유지보수성을 떨어뜨리고 확장 가능성을 제한합니다.이를 해결하기 위해 의존성 주입은 구체적인 구현체 대신 추상화된 인터페이스에 의존하도록 하여 유연성을 높입니다.간단히 말해, 의존성 주입은 특정 객체가 직접적으로 다른 객체를 생성하거나 의존하지 않도록 하고, 외부에서 필요한 객체를 주입함으로써 시스템의 결합도를 낮추는 방법입니다.이를 통해 구현체 변경이 쉽고, 테스트 시 모의 객체(mock)를 주입하여 독립적인 테스트를 수행할 수 있습니다.FastAPI에서 의존성 주입의 필요성FastAPI에서는 의존성 주입을 사용해 비즈니스 로직과 데이터 접근 로직 간의 결합도를 낮추고, 유연하게 서비스 구조를 변경할

스마트폰을 바꾼 후 이전에 썼던 기기를 중고로 팔아보신 적 있으세요? ‘이 정도 상태의 기기면 어느 정도 가격대가 적당한 거지?’ 고민하며, 수많은 중고 매물 게시글을 일일이 확인하지는 않으셨나요? 이제는 LLM(대형 언어 모델) 덕분에 이렇게 번거롭고 어려웠던 작업이 훨씬 쉽고 빠르게 해결되고 있어요.이 글에서는 LLM을 활용해 중고거래 게시글에서 스마트폰 정보를 추출하고, 이를 통해 시세를 산출한 방법을 소개하려고 해요. 먼저 스마트폰 시세조회 서비스를 왜 만들게 됐는지 배경을 간단히 살펴본 후, LLM으로 게시글을 분류·정제하는 과정, BigQuery를 이용해 정보를 후처리하고 시세를 집계하는 과정, 마지막으로 벡터 DB 기반으로 유사 게시글을 추천하는 과정을 단계별로 소개해 드릴게요. LLM으로 사용자 경험을 효과적으로 개선할 방법을 고민 중인 분들에게 이 사례가 큰 도움이 되면 좋겠어요.스마트폰 시세조회 서비스의 모습스마트폰 시세조회는 왜 필요할까요?많은 중고거래 판매자들이 물품의 적절한 가격을 결정하는 걸 어려워해요. 개인 간 거래는 워낙 다양한 상품이 혼재되어 있기 때문인데요. 종류도 워낙 다양한데 상태도 가지각색이라, 물품의 정확한 시세를 한눈에 파악하기 어려운 거죠. 스마트폰을 예로 들면 단순히 같은 기종만 검색해서 끝날 일이 아니라, 사용 기간, 배터리 효율, 스크래치 여부 등 상태가 비슷한 기기가 얼마에 팔리는지 일일이 확인해야 하는 거예요.중고거래팀은 사용자가 물품의 시세를 한눈에 확인하고 더 쉽게 가격을 결정할 수 있도록, 아이폰, 갤럭시 기종을 대상으로 한 스마트폰 시세 조회 서비스를 테스트하기로 했어요. 다양한 물품 중 스마트폰을 베타 테스트 대상으로 선정한 이유는 다음과 같아요. 스마트폰은 제품 모델이 명확하고 게시글 수가 많아 데이터 기반 시세 계산에 유리해요. 또 판매 단가가 높아 가격 결정이 중요한 상품이기도 하고요.결과적으로 모델, 용량, 새 상품 여부, 스크래치 및 파손, 배터리 효율 등 구체적인 물품 상태에 따라 시세가 어느 정도인지 파악할 수 있는 서비스를 만들었어요. 예를 들어 사용자가 ‘아이폰 16 Pro 128GB’를 선택하고 필터에서 구체적인 ‘사용 상태’나 ‘배터리 성능’을 설정하면, 곧바로 그에 따른 시세 정보를 ‘OOO만원-OOO만원’과 같은 가격 범위의 형태로 확인할 수 있어요. 이번 프로젝트는 머신러닝을 활용해 당근 중고거래 데이터를 기반으로 정확한 시세를 제공한 첫 번째 시도로, 팀 내에서도 의미가 큰 프로젝트이기도 했는데요. 그럼 본격적으로 기능을 구현해 나간 과정을 단계별로 소개해 드릴게요.Step 1. 상품 정보 추출가장 큰 문제는 게시글에서 상품 정보를 추출하는 것이에요. 당근은 판매자의 글쓰기 허들을 낮추기 위해 중고거래 게시글에 구체적인 기종이나 물품 상태를 입력하도록 요구하지 않아요. 하지만 구체적인 물품 상태별로 스마트폰 시세를 제공하려면 모델, 용량, 새 상품 여부, 스크래치 및 파손 여부, 배터리 효율 등 여러 가지 다양한 조건을 알아내야 했어요.기존에는 이런

dory.m 애플리케이션은 최근에 들어선 쉽게 스케일 아웃 할 수 있는 여러 방법들이 있지만, 아직도 데이터베이스는 그렇지 않습니다. 귀중한 데이터베이스 리소스를 효율적으로 활용하고 있는지 다시금 생각하게 해주는 글입니다.wade.hong JPA를 다루는 개발자라면 구동되는 원리를 정확하게 알아야 한다고 생각합니다. 그런 점에서 이 내용은 필수적으로 봐야 하는 내용입니다. 한 번 더 JPA Transactional를 점검할 기회인 거 같습니다.wonny.p 당연하게 사용하던 Transactional에 대해서 고찰할 수 있는 시간을 갖게 해주는 좋은 글이라 생각합니다.👍🏻 실제 개선했던 내용들이 들어 있어서 더욱 읽기 좋았습니다.안녕하세요 카카오페이에서 온라인결제 서비스 백엔드 개발을 맡고 있는 bri.ghten입니다.본 포스팅에서는 JPA Transactional과 그에 따른 DB 쿼리 성능과의 관계에 대해서 설명합니다. 따라서 DB Transaction과 Spring Transactional, JPA, Spring data source에 대한 기본적인 이해가 필요합니다.DataSource로는 Mysql을 기준으로 설명하며 쿼리 튜닝 및 인덱스 튜닝으로 인한 성능 개선에 대해서는 설명하지 않습니다.어느 날 DBA 에게서 위험 알림이 왔다.어느 날, DBA가 서비스 위험을 감지하고 알림을 보냈습니다.당시 지표를 정리하면 다음과 같습니다.peak total qps는 24K 정도로 잡혀있었지만 select와 commit 쿼리는 약 5K, update와 insert 쿼리는 3K 미만으로 식별이 힘들었고, set_option 쿼리가 약 14K 정도로 높다는 점이 수상했습니다. set_option 쿼리를 살펴볼 필요가 있었습니다.Mysql에서의 set_option은 말 그대로 option setting 하는 모든 쿼리입니다. 카카오페이 온라인결제 서비스의 개발환경에서 DB 로그를 약 4일간 켜두고 어떤 쿼리들이 가장 많이 호출되는지 10위까지의 순위를 찾아봤습니다.이 중 set_option과 연관된 쿼리들을 보니 , , , 등이 있는 걸 확인할 수 있습니다. 저희는 여기서 autocommit과 transaction 관련 쿼리를 눈여겨보았습니다.카카오페이 온라인결제 서비스 백엔드에서는 JPA를 통한 DB Access 처리를 하고 있는데요. 여기서 JPA Transactional이 DB 리소스 사용, 즉 DB 조회 성능에 알게 모르게 영향을 끼치고 있음을 알게 되었습니다.실제로 set_option과 commit이 성능에 영향을 미칠까?autocommit과 transaction 관련 쿼리가 조회 쿼리도 아니고 DB cpu나 메모리를 잡아먹는 큰 허들이 될까 싶었지만 직접 테스트를 진행해 확인해 보기로 했습니다. 테스트는 운영 중인 서비스에서 실제 최다 조회되는 테이블을 기준으로 진행했습니다.아래 예제 코드는 테스트한 실제 예제코드와 최대한 비슷하게 작성한 코드입니다.해당 코드로 성능 테스트를 진행하였고 외부 요인을 제거하기 위해 osiv=false로 두

안녕하세요, SRE팀에 DBA로 새로 합류한 브라우니입니다.AWS Service에 여러 서비스가 있지만 그 중에서도 여러 서비스에 활용할 수 있는 주제를 다뤄보고자 합니다. 그래서 선택한 주제는 AWS에서 제공하는 Aurora Serverless v2입니다. Aurora Serverless v2는 Aurora MySQL 호환 버전 및 PostgreSQL 호환 버전에 사용할 수 있습니다. 본 포스팅에서는 명칭의 혼선을 없애기 위해 Aurora Serverless(Aurora Serverless Mysql v2)와 Aurora MySQL(기존 Aurora MySQL)로 지칭하겠습니다. Aurora Serverless 에 대한 간략한 소개와 더불어 Aurora MySQL과 대조를 해 보고, 그 중 주목할만한 점에 대해 성능 위주로 공유하고자 합니다.참조 : Aurora Serverless v2 사용하기 — Amazon AuroraAmazon AuroraAurora Serverless의 개요 및 주요 특징Aurora Serverless란?Aurora Serverless는 Aurora MySQL에 대한 온디맨드 방식의 자동 크기 구성을 할 수 있게 해주는 AWS 서비스입니다. 기존에는 Aurora MySQL을 관리하려면 새로운 부하 상황을 미리 예상하여 증설해야만 했었습니다. 하지만, Aurora Serverless 는 애플리케이션 요구 사항에 따라 데이터베이스가 자동으로 확장/축소됩니다. 또한, 사용하지 않는 리소스에 대해서는 요금을 지불하지 않고 Aurora의 고가용성, 확장성을 그대로 활용할 수 있으며, 빠른 속도로 이용할 수 있습니다. 즉, 트래픽을 예측할 수 없을 때 적절한 구성으로 볼 수 있습니다Aurora Serverless는 v1, v2로 버전이 나뉘어져 있습니다. 그리고 Aurora MySQL은 v1,v2,v3가 있는데, 현재는 Aurora MySQL v3에서 Aurora Serverless v1 사용은 불가합니다.참조 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.html#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.amyAurora Serverless에선 ACU(Aurora Capacity Unit)라는 단위를 이용하여 Resource를 정하게 됩니다. 0.5 ~ 128 ACU까지 범위를 정할 수 있으며 최소단위 ACU로 초당 과금됩니다. 1 ACU= 대략 적으로 2GB Memory + CPU + Network 의 조합으로 이루어집니다. ACU는 ServerlessDatabaseCapacity와 ACUUtilization, 두 가지 지표를 통해 손쉽게 확인할 수 있습니다.참조 : Aurora Serverless v2의 성능 및 크기 조정 — Amazon AuroraScale Up / Down에 따라