뒤죽박죽이 되어버린 개발 환경을 정리하며 왜 이 글을 쓰게 되었나지금 우리 서비스는 운영 환경에서 RDS, MongoDB Atlas, S3를 모두 사용하고 있다. 문제는 테스트 서버였다. 비용 문제로 EC2 한 대로 버티다 보니 docker-compose를 이용해 DB와 Redis 같은 것들을 함께 띄워야 했는데, 여기서부터 문제들이 하나둘씩 터지기 시작했다. 문제 1. 환경 설정이 뒤죽박죽초기 .env 설정도 제대로 해두지 않은 상태에서 application-prod.yml에 모든 정보를 몰아넣은 구조였다. 이러다 보니 로컬에서 개발하다가 테스트 데이터를 넣는 과정이 귀찮고 시간이 걸리다 보니 그냥 운영 DB 붙어서 테스트를 하는 등 위험한 상황이 발생했다.과거에 운영 데이터를 건드려서 한번 복구 하는..

Spring Security는 쉽지 않은 녀석이였따Spring Security는 처음 접했었을떄“인증은 어디서 하고, 인가는 왜 또 따로 있을까”“필터는 왜 이렇게 많을까..?”나도 최근 JWT 기반 인증 흐름을 리팩토링하면서Security가 어려운 이유가 내가 구조 이해못해서라는 것을 느꼈다.내가 초보 개발자라..1. Spring Security가 어려운 이유Spring Security는 “요청이 들어왔을 때 어떤 필터를 거쳐서 인증·인가를 수행할지”를 먼저 정의하는 프레임워크다.많은 사람이 Spring Security를 Controller 쪽에서 작동한다고 생각하는데,사실은 그 이전, DispatcherServlet보다 훨씬 앞단에서 모든 게 시작된다.즉, 우리가 작성한 Controller 코드가 실..

Chapter 10. Scheduler10.1 스레드(Thread)의 개념 이해물리적인 스레드(Pysical Thread) : CPU 코어를 논리적으로 나눈 것듀얼코어 4 스레드 (작업관리자 [성능]에서 확인 가능) 논리적인 스레드(Logical Thread) : 프로세스 내에서 실행되는 세부 작업의 단위이론적으로는 제한이 없지만 실제로는 물리적인 스레드의 가용 범위내에서 생성 가능 💡병렬성(Parallelism) : 물리적인 스레드가 실제로 동시에 실행됨동시성(Concurrency) : 동시에 실행되는 것처럼 보이지만 실제로는 아님무수히 많은 논리적인 스레드가 물리적인 스레드를 아주 빠른 속도로 번갈아 가면서 사용 10.2 Scheduler란?어떤 스레드에서 무엇을 처리할지 제어(경쟁조건 등 고려)..

Chapter 8 Backpressure배압 또는 역압Publisher가 끊임없이 emit하는 무수히 많은 데이터를 적절하게 제어하여 데이터 처리에 과부하가 걸리지 않도록 제어하는 것.https://velog.io/@zini9188/Spring-WebFlux-Project-ReactorPublisher가 빠른 속도로 emit 할 경우 Subscriber의 처리속도가 느려서 처리하기도 전에 emit 됨.이렇게 될 경우 오버플로가 발생하거나 최악의 경우 시스템이 다운되는 문제가 발생⇒ 이 문제를 해결하기 위한 수단이 BackpressureReactor에서의 Backpressure 처리방식1. 데이터 개수 제어Subscriber가 적절히 처리할 수 있는 수준의 데이터 개수를 request()를 통해 Publi..

해당 내용은 '스프링으로 시작하는 리액티브 프로그래밍' 책의 Chapter 1을 보고 학습한 내용을 정리한 글입니다. 리액티브 프로그래밍을 들어가며에 했던 설명들은 모두 리액티브 프로그래밍을 위한 인트로에 불과하였다. 우리가 비즈니스 로직을 작성하고, 서버를 운영하게 되었을때 기존 Spring MVC 모델을 사용한다고 가정하면 스레드 모델 자체가 요청당 하나의 스레드가 작업이 이뤄지게 되는데 이때, 처리방식이 동기에 해당하기에 블로킹이 발생할 경우 쓰레드 풀을 이용하더라도 제한적인 쓰레드 갯수에 대한 문제는 해결 할 수 없다.블로킹(Blocking)과 논블로킹(Non-blocking)블로킹(Blocking): 어떤 작업이 끝날 때까지 다른 작업을 못하고 기다리는 상태. 예를 들어, 파일을 읽는 도중 C..

우리는 HTTP, HTTPS 프로토콜을 통해 클라이언트와 서버 간 통신을 진행한다.우리가 흔히 많이 사용하는 웹, 앱 등에서는 대부분 HTTP, HTTPS 프로토콜 기반으로 데이터를 전달하게 된다. 서버들이 어떤 방식을 통해 데이터를 전달해주는지 알아보자.서버는 대표적으로 웹 서버와 웹 어플리케이션 서버가 존재한다.Web Server흔히 우리가 많이 보는 웹 화면을 표시해주는 서버이며, 정적 리소스를 제공해준다.여기서 정적 리소스란 이미지, HTML, CSS, JavaScript 등 과 같은 정적인 파일을 제공하는 역할을 해주고, 흔히 우리가 쓰는 크롬 등 웹 브라우저에서는 해당 파일을 랜더링하여 우리가 볼 수 있는 화면으로 만들어 주는 역할을 한다.웹 서버에는 Nginx, Apache 등이 존재한다.W..

대학생 주거 리뷰 플랫폼, 찐빵 서비스 운영 중 문제가 발생하였다.원룸 리뷰를 작성할 때 건물 정보를 함께 입력하게 되는데, 원룸의 위치만으로 캠퍼스를 명확히 특정할 수 없는 경우가 많았다.예를 들어건물이 두 개 이상의 캠퍼스 반경에 겹치는 경우특정 캠퍼스에서 조금 떨어져 있지만 사실상 생활권인 경우애초에 전혀 다른 곳에 사는 경우초기 설계 단계에서 검색 필터에서 캠퍼스를 선택할 경우 캠퍼스 ID를 이용하여 검색하는 로직으로 구현했기에, 이런 애매한 상황은 마커 조회 및 검색 로직에서 걸림돌이 되었다.그래서 캠퍼스 위치(위도·경도)를 기준으로 반경 1~2km 내의 모든 마커를 불러오는 방식으로 로직을 전환하기로 했다.그래서 현재 위치(위도, 경도) 기반으로 반경에 속하는 마커들을 어떻게 하면 불러올 수 ..

개인적으로 서비스를 개발하는 것도 중요하지만, 운영하는 것도 정말 중요하다고 생각한다. 왜냐하면 운영을 하게 됐을 때 어떤 상황들이 발생할지 모르기 때문에, 예기치 못한 오류나 성능 저하에 빠르게 대응할 수 있는 준비가 반드시 필요하다.그렇기에 서비스 운영이 있어 로깅과 모니터링을 통해 항상 문제 없는지 체크하고, 장애를 감지할 수 있는 체계를 갖추어야 한다.서비스에 문제가 없는지 확인하는 데에는 로그와 지표를 심어 감시하여 장애에 대응할 수 있다. 프로덕션 준비 기능이란?운영 환경에서는 단순히 코드가 돌아간다는 사실만으로는 충분하지 않다. 서비스가 얼마나 안정적으로 동작하는지, 사용자가 체감하는 경험이 문제가 없는지까지 끊임없이 확인해야 한다. 이를 위해서는 눈에 보이지 않는 부분까지 세밀하게 점검할 ..