개발계발

API 서버를 prod 환경에서 띄울 때 어떻게 하는 것이 가장 좋을까? 기본적으로 애플리케이션을 실행 시키는 방법은 다음과 같다. ( 아래는 fastapi 앱을 실행시키는 명령어이다. ) gunicorn main:app --workers 4 -k uvicorn.workers.UvicornWorker --bind unix:/tmp/gunicorn.sock 이렇게 하면 애플리케이션을 띄우고 트래픽을 받을 수 있다. 이대로 마쳐도 되지만 앱이 crash등의 이유로 죽는 상황에 대해 한 번 더 생각해 볼 수도 있다. 우리 서비스는 ECS fargate로 띄워서 서버가 죽는다면 ECS 에서 자동으로 오토스케일링되어 새로 띄운다. 하지만 죽은 서버를 띄우는데 상대적으로 시간이 걸려 딜레이가 발생한다. 요 부분을 ..

만들게 된 계기 Django에서 테스트 코드를 작성할 때 테스트용 객체를 생성해 주는 factory_boy 라이브러리를 사용해 좀 더 손쉽게 테스트코드를 작성할 수 있었다. 마찬가지로 FastAPI에서도 사용하기 위해 factory_boy의 SQLAlchemyModelFactory를 사용하고자 했으나 다음과 같은 문제가 있었다. session 동적 할당이 불가능하다. 클래스를 정의하는 시점에 Meta 클래스 내 sqlalchemy_session에 session을 정의해주어야 한다. 이 방식은 테스트코드 런타임에 session을 동적 할당하는 것이 불가능해서 session 기반의 데이터들이 테스트 전반에 영향을 미치는 문제가 있다. 아래는 sqlalchemy_session에 session을 할당하는 예시이..

신규 API 서버에서는 Oauth 방식의 SNS로그인과 JWT를 사용한 토큰 기반의 인증/인가 방식을 구현하였다. 토큰 기반의 인증 방식을 사용한 이유는 다음과 같다. 기존 API 서버에도 동일한 인증 방식을 쉽게 적용할 수 있다. 서버에서 디비 조회 없이도 검증이 가능하다. 개념 설명은 다른 포스팅에서 다루도록 하고 구현에 집중하여 살펴보겠다. 스펙 Python 3.12 FastAPI 0.103.1 구현 Access Token 사용 유저의 인가(Authorization)를 검증할 때 access token이 유효한지로 판단한다. access token에는 서비스에 필요한 유저 정보와 만료일자 등이 포함되며 해당 포스팅에서는 다음과 같은 데이터를 포함한다. { user_id: int, user_devic..

fastapi를 사용하며 공부한 pydantic에 대해 주요 내용들을 간단하게 정리해 보았다. pydantic 이란? pydantic은 데이터 검증 라이브러리로 데이터에 대한 유효성 검사와 직렬화를 제공한다. type annotation 만으로 유효성 검사를 진행하기 때문에 간결하게 구현 가능하다는 장점이 있다. model pydantic에서 스키마를 정의하는 주요 방법 중 하나는 모델을 사용하는 것이다. 모델은 pydantic.BaseModel을 사요삭하고 필드를 주석이 달린 attribute로 정의하는 단순한 클래스이다. python dataclass와 유사하지만 유효성 검사, 직렬화 및 json 스키마 생성과 관련된 특정 워크플로우를 간소화하는 중요한 차이가 있다. 다음과 같이 user model이..

코루틴(coroutine)이란? 코루틴은 co + routine의 합성어로, 직역하면 함께/협력하여 수행되는 루틴이라고 볼 수 있다. 여기서 루틴이란 실행하는 프로시저나 함수를 의미한다. 다시 말해, 코루틴은 협력하여 실행되는 함수로 설명된다. 이게 어떤 의미일까? 루틴의 종류부터 살펴보자. 메인 루틴 - 서브 루틴 함수 내에서 또 다른 함수를 호출하면, 해당 함수가 결과 값을 반환할 때까지 대기했다가 그 이후 코드들을 순차적으로 수행한다. 이때 호출한 함수가 메인 루틴, 호출된 함수가 서브 루틴에 해당한다. 코루틴 반면에 코루틴은 비동기적으로 함수 내 여러 다른 지점에서 진입하고 탈출하고 재개할 수 있는 특수한 서브루틴에 해당한다. 코루틴이 완료되지 않아도 또 다른 코루틴을 실행할 수 있다. 코루틴을 ..

우리가 기본적으로 접하는 동기, 비동기 개념은 관점에 따라 설명을 달리 할 수 있다. 여기서 살펴볼 관점은 함수의 제어권과 반환된 결과에 따른 처리이다. 관점에 따라 아래의 도표와 같이 sync/async, blocking/non-blocking으로 나누어 진다. 설명에 앞서, A 함수가 B 함수를 호출한다고 가정하자. 가령 이런 것이다. def A(): ... B() ... def B(): ... blocking/non-blocking blocking과 non-blocking을 나누는 기준은 제어권을 언제 반납하느냐 하는 것이다. 여기서 제어권이란 함수의 실행 흐름을 제어하는 것으로, 쉽게 말해 제어권이 있어야 함수 내 코드를 계속 실행할 수 있다. blocking 방식은 A 함수가 B 함수 호출 시에..

QueryDSL을 추가하면서 빌드 위치를 바꾸기 위해 build.gradle을 업데이트했다. 그러나 gradle 새로고침 시 에러가 발생한다. Unable to set prepareKotlinBuildScriptModel sync task. 찾아보니 다음과 같이 수정하면 된다. 나의 경우는 querydsl-apt 버전이 5.0.0인데 있지도 않은 jpa 모듈을 검색해서 문제가 되었고, jakarta로 변경해서 해결했다. dependency를 평소에 잘 확인해 보자. https://mvnrepository.com/artifact/com.querydsl/querydsl-apt/5.0.0 dependencies { // queryDSL 설정 implementation "com.querydsl:queryds..

약 한 달에 걸쳐 진행한 챌린지가 끝났다. 쿠버네티스에 대한 지식이 거의 없었기 때문에 시작이 조금 지지부진했지만 호스트님의 가이드 PPT와 팀원들과의 위클리 스크럼 진행 덕분에 마무리할 수 있었다. 짧은 회고로 마무리 해보자. 진행 과정 Kubernetes를 사용하여 컨테이너화된 앱들을 운영하고, 앱들의 로그를 수집하여 모니터링 시스템을 구축하는 프로젝트를 진행했다. 쿠버네티스 클러스터는 private subnet에 두어 외부에서 접근이 불가능하기 때문에 LoadBalancer 타입의 Service object를 추가하여 앱 서비스에 접근하도록 했다. 앱 배포는 ArgoCD에서 App of Apps 패턴을 적용하여 관리하였다. App of Apps 패턴은 앱 별로 Application CRD를 생성하고..

넘블이라는 개발자 교육 사이트에서 Kubernetes로 모니터링 시스템 구축하기 챌린지를 진행하게 되었다. 쿠버네티스에 대한 공부를 하고 싶었던 참인데 우연히 발견하게 되어 후다닥 신청했다. 챌린지를 진행하며 진행과정을 포스팅으로 남겨 두려 한다. 쿠버네티스뿐만 아니라 ArgoCD, ELK Stack, Prometheus, Grafana 도 사용하니, 관심 있으신 분들은 아래 포스팅을 참고하면 되겠다. :) 관련 포스팅 1. 쿠버네티스 구성 살펴보기 2. 인프라 설정 및 Nginx 띄워보기 3. ArgoCD 개념 파악 및 배포하기 4. ELK Stack으로 로그 모니터링 시스템 구축하기 5. Prometheus와 Grafana 사용해 보기

목차 1. 쿠버네티스 구성 살펴보기 2. 인프라 설정 및 Nginx 띄워보기 3. ArgoCD 개념 파악 및 배포하기 4. ELK Stack으로 로그 모니터링 시스템 구축하기 5. Prometheus와 Grafana 사용해보기 👈 here 이번 포스팅에서는 Prometheus와 Grafana를 사용할 것이다. 간단하게 개념부터 살펴보자. Prometheus(프로메테우스) 모니터링 및 경고 툴킷으로 메트릭 이름과 키/값 쌍으로 식별되는 시계열 데이터를 수집한다. 매트릭이란 숫자 측정을 의미하며 요청 시간, 연결 수, 활성 쿼리 수 등이 해당한다. PromQL이라는 프로메테우스의 자체 쿼리 언어를 제공하여 쿼리문으로 시간 관련 쿼리 기능 등을 제공한다. 아래 그림은 프로메테우스 아키텍처이다. Grafana..