장미정원

들어가며동시성 문제는 서버 애플리케이션을 개발 할 때 항상 고민해야하는 문제입니다. 공유 자원을 여러 스레드가 접근하려할 때 경쟁상태가 발생하여 lost update와 같은 이상 현상이 발생할 수 있습니다. 이러한 동시성 처리를 위해 데이터베이스 Lock을 사용할 수 있습니다. Spring Data Jpa를 사용한다면 어노테이션으로 간단하게 낙관적 락, 비관적 락을 손쉽게 적용하여 동시성 처리를 할 수 있습니다. @Transaction 어노테이션 속성으로 isolation 단계를 SELIALIZATION으로 설정하여 데이터 정합성을 보장할 수도 있습니다. 추가로 자바 문법에서 지원하는 메서드에 synchronized 키워드를 붙혀 내부적으로 모니터락을 사용하여 동시성 처리를 할 수 있지만, scale-o..

Spring WebFlux, MVC Stack에 대해 WebFluxSpring WebFlux는 reactive web stack 프래임워크이며, non-blocking I/O를 지원하고 event-loop 방식으로 적은 양의 스레드로 대용량 요청을 처리할 수 있습니다.WebFlux 스택을 기존에 사용하는 MVC 모델과 비교하며 설명하도록 하겠습니다. MVC Thread Per Request 모델Spring MVC는 요청을 처리할 때 blocking 방식으로 처리합니다. (DB I/O, HTTP req ex. RestTemplate)MVC 서버는 요청이 들어올 때 ThreadPool에서 Thread를 꺼내서 요청 하나에 할당합니다. (thread per request) 일반적인 경우에는 이러한 방식이 문제..

들어가며 교내 입학지원시스템인 Hello, GSM 서버 개발 중에 겪었던 문제점들 중 하나였던 싱글톤 빈 동시성 문제와 해결과 개선 방안에 대해 소개드리겠습니다. 간단하게 Hello, GSM 서비스에 대해 소개하자면, 광주소프트웨어마이스터고등학교 입학 원서를 제출, 합격자 관리, 합격자 조회 등등 여러 편리한 기능을 제공하는 서비스입니다.  성적 계산식 이슈 릴리즈를 2주 정도 남겨둔 상황에서 상당히 크리티컬한 이슈가 발생했습니다. 입학지원시스템에서 가장 중요하다고 할 수 있는 성적 계산식에서 발생한 문제였습니다. 비즈니스상 성적 환산점 만점은 300점이지만, 무슨 이유에서인지 300점을 초과하는 case가 발생했습니다. 하지만 400줄이 넘어가는 계산식 클래스와 비즈니스 요구사항이 덕지덕지 뭍어있는 ..

개요DDD (Domain Driven Design)는 비즈니스 영역을 의미하는 도메인을 중심으로 하는 개발 방식입니다. DDD에 대해 자세하게 알아보기 전에 DDD에 대해 자주 하는 오해가 있는 것 같은데요. DDD를 구현하려면 이러이러한 구조를 따라야해! 가 아닌 도메인에 대한 문제를 해결하기 위해 도메인과 비즈니스 로직에 초점을 맞춰 개발할 수 있게 도와주는 도구입니다. DDD의 목표는 낮은 결합도, 높은 응집도 입니다. DDD를 통해 도메인 간의 경계를 나눠 응집도 높은 애플리케이션을 설계할 수 있게 도와줍니다. Ubiquitous LanguageDDD의 특징 중 하나는 유비쿼터스 언어를 사용하는 것입니다. 유비쿼터스 언어는 프로젝트에 참여하는 모든 이해 관계자들이 사용하는 비즈니스 도메인 용어를..

들어가며서버 애플리케이션의 규모가 커질 수록 트래픽이 많아지며 데이터베이스에 쓰기, 수정, 읽기 등등의 작업이 빈번하게 일어나게 됩니다. 이러한 상황에서 서비스에 예상치 못한 장애가 발생할 수 있습니다. 그렇기 때문에 높은 트래픽의 상황에 대비하여 시스템의 확장성, 고가용성, 성능을 높히기 위한 노력이 필요합니다. 데이터베이스의 성능 향상을 위한 기술은 파티셔닝, 샤딩, 레플리케이션에 대해 알아보겠습니다. 파티셔닝데이터베이스 파티셔닝은 데이터베이스의 테이블을 분활하여 저장하는 기술입니다. 데이터베이스에 데이터가 많이 저장되어있다면 그만큼 인덱스 자료구조의 크기가 큰 것이며 쓰기 작업시 B-Tree 재구조화 시간도 오래걸리는등 성능이 많이 떨어지게 됩니다.파티셔닝은 수직(Vertical) 파티셔닝, 수평(..

들어가며클라우드 인프라 기술이 대두되면서 유연한 확장과 안정성을 추구하는 많은 회사에서 MSA 아키텍처를 도입하게 되었습니다. (클라우드 인프라와 MSA) MSA 아키텍처를 도입한다면 기존 모놀리식 아키텍처 시스템의 한계를 극복할 수 있습니다. 여러 서비스 간의 장애 전파, 스케일 아웃, 확장의 어려움 등 여러 이점이 있습니다. 하지만 항상 MSA 아키텍처가 옳은 답은 아닙니다. 복잡한 구조로 유지보수가 힘들 수 있고 비용적인 부분도 무시할 수 없습니다. 이러한 MSA 구조에서 고민해야하는 부분 중 하나인 트랜잭션 작업의 원자성을 어떻게 지킬 수 있을지 알아보겠습니다. 모놀리식과 MSA의 트랜잭션 처리먼저 모놀리식과 MSA의 트랜잭션 처리에 대해 비교해보겠습니다. 설명을 위해 간단하게 토스 앱에서 돈을 ..

HTTP? HTTPS?HTTP는 웹 페이지와 같은 HTML 문서를 전송하기 위한 프로토콜입니다. 현재 보고있는 이 티스토리 웹사이트도 HTTP 통신을 기반으로 웹 페이지를 브라우저가 전송받아 보고있는 것입니다. 하지만 주소창을 확인해보면 http://... 가 아닌 https://... 라고 표기되어있는 것을 볼 수 있습니다. 실제로 http://... 만 지원하는 웹 사이트인 경우 크롬에서 안전하지 않다는 경고를 보내주게 됩니다. HTTPSHTTPS는 HTTP 프로토콜과 목적과 골격은 동일한 프로토콜이지만 S(Secure), 보안요소가 포함된 프로토콜입니다. 기본 포트도 HTTP 80포트가 아닌 443를 기본 포트 사용합니다. 인터넷 상에서는 수많은 패킷들을 주고 받게 됩니다. 로그인을 위해 아이디와 ..

다소 자극적인 제목을 선정해보았지만 이 글을 끝까지 읽어봐주시면 좋은 인사이트를 하나라도 얻어가실 수 있을거라 생각합니다. 제가 프로젝트를 개발, 운영해보며 느낀 경험들을 꾹꾹 눌러담아 보았습니다. 이유 없는 기술 도입을 지양하자프로젝트에서 주어진 요구사항이나 문제를 해결하기 위해 기술을 도입해 본 경험이 있을 것입니다. 동적 쿼리를 편하게 작성하기 위해 QueryDSL 도입, 반복적인 조회 작업을 개선하기 위해 Redis 캐시 저장소 도입, 동시성 문제를 해결하기 위해 비관적 락 적용 등등... 하지만 이런 기술들을 도입하고 적용할 때 여러 기술을 비교해 보지도 않고 이유 없이 특정 기술을 도입하는 것은 지양해야 할 태도라고 생각합니다. 상황에 맞지 않는 기술이지만 단순히 관심이 있어서, 재밌어 보여서..