본문 바로가기

분류 전체보기

(20)
MacOS 컨테이너 apt-get update시 발생하는 문제 해결(Mirror sync) Openfaas 실습을 진행하다 발견한 특이한 현상과 해결 방법이라 미래의 나를 위해 남겨둔다. version: 1.0 provider: name: openfaas gateway: http://127.0.0.1:8080 functions: api: lang: python3-debian handler: ./api image: wannte/api:latest 아래의 그림처럼 apt-get update도중 Mirror sync in progress의 에러를 접하게 된다. 처음에는 python3-debian 템플릿의 문제인줄 알고 이슈를 찾아봤지만, 이와 관련된 이슈는 없었다. 해결 방법 구글링을 하다보니 이 글에서 해결책을 찾을 수 있었다. ScreenTime의 Web Content 제약조건을 Unrestri..
@Version + @Embeddable 이상 동작 현상에 대한 기록 이전 글에서 낙관적 잠금(@Version 어노테이션)을 활용하여 동시성 이슈를 해결할 수 있었습니다. 이번에는 @Embeddable 어노테이션을 활용하여 엔티티의 가동성을 높이고 역할을 분리하고자 했습니다. 하지만, 예상치 못한 동작이 발생했고, 이에 대해 남겨보고자 합니다. 기존 구조 @Entity public class Petition { @OneToMany(cascade = CascadeType.PERSIST, fetch = FetchType.LAZY, mappedBy = "petition") private List agreements = new ArrayList(); @OneToOne(cascade = CascadeType.PERSIST) @JoinColumn(name = "answer_id", ..
우리 프로젝트에서 동시성 이슈를 해결하는 방법 - 3. 비관적 잠금 지금까지 알아본 우리 프로젝트에서 동시성 이슈를 해결하는 방법은 다음과 같다. 1. 유니크 제약 조건 2. 낙관적 잠금 마지막으로 비관적 잠금에 대해서 알아보도록 하자. 문제 상황 정의 우리 서비스는 청원의 동의 수를 실시간으로 반영하고 보여줘야 했고, 거의 모든 조회 요청에는 동의 수가 필요했다. 조회수를 가지고 Sorting 하는 비즈니스 적인 요구사항 또한 있었기 때문에, 매번 해당 청원의 동의들의 개수를 세는 것은 불가능하다 판단했다. 그렇기에 별도의 agreeCount라는 칼럼을 추가하여 관리하고자 했다. @Entity public class Petition { @OptimisticLock(excluded = true) private Integer agreeCount; // 1. DB 유니크 조..
우리 프로젝트에서 동시성 이슈를 해결하는 방법 - 2. 낙관적 잠금 이전 글에서 하나의 청원에 동시에 한 유저로부터 여러 동의 요청이 발생했을 때, DB의 유니크 조건을 활용함으로써 하나의 청원 동의만을 허용할 수 있었다. 이번 글에서는 청원에 관리자가 답변을 달 때, 발생할 수 있는 동시성 문제를 해결하는 과정에서 적용한 낙관전 잠금, Entity Versioing에 대해 다루고자 한다. 문제 상황 정의 우리 서비스는 청원의 동의 수가 일정 수 이상을 넘게 되면, 관리자가 해당 청원에 답변을 남긴다. 이때, 청원의 답변은 최대 1개만 남길 수 있는 요구사항이 정의되어 있다. 이러한 요구사항을 위해 사용되는 청원과 답변 Entity의 Column들만 간단하게 작성해보면 아래와 같다. 비즈니스적인 요구사항으로 '답변-> 청원'의 방향의 연관관계는 필요 없다고 판단했기에 일..
간단한 Spring AOP 적용기 이전 글에서 Table의 칼럼에 Unique Constraint 조건을 추가함으로써 동시성 이슈를 해결할 수 있었다. 이러한 동시성 이슈는 청원에 동의를 할 때뿐만 아니라, 다른 도메인에서도 마찬가지로 필요성이 생겼고 이는 코드의 중복으로 이어졌다. Unique조건 위배시 발생하는 예외 처리하는 로직을 하나의 관심사로 분리하는 작업을 진행했고 이 적용 과정을 설명하고자 한다. 기존 코드 기존 코드의 구성은 아래와 같다. user_id와 petition_id에 Unique조건을 걸어두었기 때문에 동시에 동일한 user_id와 petition_id의 Agreement를 생성하게 되면, DataIntegrityViolationException이 발생하게 된다. 이를 그 의미가 명확하게 드러날 수 있도록 에러를..
우리 프로젝트에서 동시성 이슈를 해결하는 방법 - 1. DB Unique 조건을 활용하여 지스트 청원 프로젝트에서는 각 사용자마다 한 번의 청원 동의만을 허용합니다. 여러 요청이 동시에 들어왔을 때에도, 처음 들어온 하나의 요청만을 허용하도록 동시성과 관련하여 고민한 부분들을 작성하고자 합니다. 테스트 코드 작성 10개의 Thread를 생성하고 동시에 같은 유저의 id로 동의 요청을 보내는 테스트를 작성했고, 실행하게 되면 한 명의 유저가 10개의 청원 동의를 하는 결과를 가지게 됩니다. 10개의 동시 요청이 오더라도 하나의 동의만을 허용하도록 코드를 수정해야만 합니다. @Test public void applyAgreementWithConcurrency() throws InterruptedException { Long petitionId = petitionService.createPetit..
Spring Data Envers를 활용하여 Entity의 변경 이력을 관리하기 지스트 청원 프로젝트의 실제 서비스 운영을 위해서 청원과 답변 Entity에 대한 변경 이력이 관리되어 문제 상황에 대비해야 한다는 팀적으로 요구사항이 생겼고, 이를 Hibernate의 Envers기능을 이용하여 손쉽게 구현할 수 있었다. 요구사항 사용자가 청원을 등록했을 때, 관리자(학생회 측)는 해당 내용 중 부적절한 정보의 숨김 처리를 진행한다. 악의적으로 글의 내용을 수정하는 트롤 행위가 충분히 발생할 수 있지만 이를 막을 방법이 없다. 또한, 어떤 관리자가 작업을 진행했는지의 이력을 확인할 수 없고, 원본 글의 정보 또한 찾을 수 없게 되는 구조였다. (숨김 처리 작업을 진행하면, Entity 테이블의 해당 칼럼의 수정을 진행한다.) 이러한 문제들을 해결하기 위한 요구사항을 정리하면 다음과 같다..
SameSite 쿠키 정책으로 발생한 문제와 해결 방법에 관하여 지스트 청원 프로젝트를 진행하는 과정에서 쿠키가 의도하는 방식으로 동작하지 않았고, 이를 해결하는 과정에서 SameSite 쿠키의 문제임을 확인했고 이를 정리해보고자 한다. 문제 상황 - 프론트 서버: S3정적 웹호스팅을 활용하여 배포(http://petition-bucket.s3-website.ap-northeast-2.amazonaws.com) - api 서버: ec2서버에 도메인 연결(http://dev-api.gist-petition.com) 우리 프로젝트는 왜 세션을 도입하게 되었는가? 글에서 확인할 수 있듯이, 우리 팀은 세션 방식을 활용하여 로그인 상태를 유지한다. 처음 api 요청 시 `Set-Cookie: JSESSIONID={세션 ID}; HttpOnly`가 응답에 담겨 오고, 이후에 ..