728x90
비즈니스 로직을 작성하면서 정상 로직을 생각하는 것도 중요하지만, 예외 상황과 엣지 케이스에 대한 방어로직을 작성하는 데 신경을 더 쓰는 것은 당연할 것이다.try-catch문으로 예외를 잡아서 처리하는 것 뿐만 아니라, 커넥션, 메모리 등의 자원을 반환하거나 초기화 등을 수행하기 위해 finally 블럭을 사용하게 된다.김영한님의 중급 자바 강의를 들으면서 추가적으로 Java7에 도입된 try-with-resources 기능이 있음을 알게되었고, 추후에 업무에 사용할 수 있도록 차이점과 장점을 기록하는 것이 이번 포스팅의 목적이다. # 예시 시나리오차이점과 장점을 알아보기 위해 간단한 시나리오를 작성한다. Reader- 파일을 쓰기 위한 기본 기능 제공하는 메소드- 파일 열기, 쓰기, 닫기 메소드 존재..
이번 포스팅에서는 MongoDB 다중 업데이트 로직을 구현하면서 마주한 성능 개선의 필요성과 이를 풀어나간 방법들을 공유하고자 한다. 사용 환경은 다음과 같다.Spring 2.3.2MongoDB 5.0JDK 1.8.0Kotlin# 최초 기능 개발 - saveAll()해당 업무에서는 상태를 기반으로 Entity를 관리하며 비즈니스 로직을 태우는 프로세스를 구축하는 것이 필요했다.신규로 생성된 데이터들을 PENDING으로, 처리를 진행할 때는 PROGRESS, 처리 다 되면 SUCCESS & FAILED 등으로 관리한다. 그중 처리를 진행할 때 대상들을 일괄적으로 PENDING -> PROGRESS로 변경하는 작업이 필요했는데, 해당 과정에서 여러개의 데이터에 대한 업데이트를 진행했다. 최초 로직은 가장 ..
# 목적 웹서버와 API 서버에 대한 대상 그룹의 헬스체크를 ALB가 수행하는데, 헬스체크 요청에 대한 로그가 계속 쌓이게 되어서 사용자의 요청 로그를 추적하기 불편한 상황이 발생했다. 정상적인 운영 및 디버깅을 위해서 특정 엔드포인트로의 요청에 대한 로그를 제외시켜야했음. FastAPI와 Nginx에서 특정 엔드포인트에 대한 Health Check 용도의 엔드포인트에 대하여, 로그가 쌓이지 않도록 설정하는 방법을 공유한다. # 상태 확인 웹서버와 API 서버가 배포되어있는 환경과 라우팅 조건은 아래와 같았다. EKS 환경을 사용했고, Ingress를 통하여 L7 LB 구성을 수행했다. 해당 인그레스를 통하여 /* 경로로 접속하는 HTTP 요청은 웹서버로, /api/* 로 접속하는 요청은 API 서버로 ..
# 목적프로젝트를 진행하면서 웹서버에서 실시간으로 특정 파드에서 발생하는 로그를 실시간으로 보여지는 기능을 구현해야했다.목표로 한 기능은, kubectl logs 명령어를 통해서 파드의 로그를 확인하는 것 처럼, API 서버가 이를 수행하게 만드는 것이였다.이를 구현하는 방법 중 하나로 SSE(Server Sent Event)를 채택하게 되었고, FastAPI를 사용하여 이를 구현한 방법을 공유하고자 한다.FastAPI에서 쿠버네티스의 파드에 접근하는 방법에 대해서는 다른 글에서 설명하고, FastAPI 프레임워크를 통해 SSE 구현 방법을 중점으로 다룬다.# Server Sent Event을 사용한 이유우선 SSE 방식에 대해서 간단하게 짚어보자. 개념에 대해선 훨씬 잘 쓴 다른 블로거분들을 참고하자...
from fastapi import FastAPI app = FastAPI(docs_url='/api/docs', openapi_url='/api/openapi.json') 목적 프로젝트를 진행하면서, FastAPI를 EKS 위에서 배포하여 사용하는 서비스 환경을 설계하였다. API Server를 ALB(L7)와 Route53을 통해 /api prefix로 노출시키고 정상적으로 웹서버에서 통신이 가능하게 세팅이 된 후, FastAPI의 편리한 Swagger 기능을 통해 간단한 Web UI를 제공받고자 하였다. Swagger의 기본 URL은 /docs 및 /redoc 인데, 사용하는 도메인 주소에서 API 서버는 /api 를 차지한다. 그렇다 보니, /docs 를 입력하면 당연히 웹서버의 페이지로 라우팅되..