하이버네이트의 시간은 거꾸로 간다스프링부트 버전을 업그레이드하는 과정에서 발견된 버그 해결기• 문제 좁히기• 1. 배포 전후로 나노초 값이 다른 이유• 의심 1: 자바 버전 업그레이드의 영향 (11 ➡️ 17)• 의심 2: 하이버네이트 버전 업그레이드의 영향 (5.6.5 ➡️ 6.5.5)• 2. 조회 과정에서 음수의 나노초가 발생하는 이유저희 딜리버리 프로덕트 개발팀은 AWS MSK 버전 업그레이드에 대응하기 위해 관리 중인 시스템들의 스프링부트 버전을 3.x대로 업데이트했습니다. 이미 다른 프로젝트에서 스프링부트 버전업을 경험한 데다, 팀원들이 겪었던 이슈들을 잘 정리한 문서 덕분에 큰 어려움 없이 작업을 진행할 수 있었습니다. 업데이트된 프로젝트는 QA를 무사히 통과해 운영 환경에 배포되었고, 배포 후에도 별다른 문제 없이 잘 동작하는 듯했습니다.하지만 다음 날 자정 직전에 에러 알림이 발생하기 시작했습니다. 해당 버그로 인해 일부 배송 매니저는 배송 업무를 볼 때, 사용하는 컬리버드 앱에 로그인 자체가 불가능한 상태였습니다. 특히 에러가 발생한 시점이 샛별 배송이 활발하게 진행되는 시간대였기 때문에, 배송 업무에 차질이 없도록 신속하게 롤백을 진행한 후 다음날 에러 원인을 파악하기 시작했습니다.먼저 문제의 원인을 좁히기위해서 에러 로그를 확인했습니다.이 로그를 통해, DB에서 데이터를 조회하여 객체로 변환하는 과정에서 DateTime 형식에 문제가 있음을 파악할 수 있었습니다. 음수의 나노초 값을 가지는 데이터가 원인인 것 같아서, DB에 그런 데이터가 있는지 확인해보았습니다.하지만 확인 결과, 음수의 나노초를 포함한 날짜나 시각 데이터는 존재하지 않았고, 모든 데이터가 0 또는 양수 값을 가지고 있었습니다.데이터를 검토하면서 배포 이전과 이후의 시점에서 나노초 값이 미묘하게 달라졌다는 점을 발견했습니다. 배포 이전의 데이터에는 나노초가 없었으나, 배포 이후에는 나노초가 포함된 데이터가 생긴 것이었습니다.이로 인해 두 가지 의문이 생겼습니다• 배포 전후로 나노초 값이 다른 이유는 무엇일까?• DB에는 정상 범위의 나노초가 저장되어 있는데, 왜 조회 과정에서 음수의 나노초가 발생하는 걸까?1. 배포 전후로 나노초 값이 다른 이유의심 1: 자바 버전 업그레이드의 영향 (11 ➡️ 17)배포 전후의 차이점을 분석하던 중, 먼저 자바 버전의 변경을 의심했습니다. 스프링 부트 3.x는 최소 JDK 17을 요구하므로, 자바 버전을 11에서 17로 업그레이드했고, 이로 인한 영향을 고려해 LocalTime 로직의 변화를 확인해봤습니다. 하지만 자바 11과 17의 LocalTime 로직에 수정된 부분은 없었습니다.또한, 로컬 환경에서 테스트한 결과, 배포 이전에도 나노초 값은 0이 아닌 상태였으며, 저장 시점에 나노초 값을 버리고 DB에 저장된다는 사실을 알게 되었습니다.의심 2: 하이버네이트 버전 업그레이드의 영향 (5.6.5 ➡️ 6.5.5)자바 버전이 원인이 아닌 것으로 확인된 후, DB 저장을 처리하는 하이버네이트 로직을 의심했습니다. 실

bread.young ELK 환경에서 로그를 어떻게 쌓고, 보여주는지 쉽게 설명된 글입니다. 이슈 트래킹을 쉽게 하는 방법은 개발자라면 누구나 고민하는 부분인데 어떻게 풀어내었는지 궁금하네요🧐!!rain.drop ELK 환경에서의 로깅 방식과 Sentry를 이용한 이슈 트래킹 전략을 쉽게 풀어쓴 글입니다. ELK 환경을 구축하려는 분, 혹은 동일한 문제에 고민을 갖고 계신 분들께 추천드립니다~!안녕하세요. 해외결제서비스유닛에서 서버 개발 업무를 맡고 있는 포도입니다.지난 포스팅인 Kotlin으로 Spring AOP 극복하기!에 이어 이번 글에서는, Spring 기반의 서비스를 운영하는 개발자를 대상으로 이슈 트래킹 전략을 다룹니다. 복잡한 비즈니스 로직과 트랜잭션을 처리하는 환경에서 효과적인 이슈 트래킹을 고민하는 개발자에게 유용할 것입니다.이번에 다루게 될 내용은, 이슈 트래킹 전략을 단계적으로 발전시키는 과정을 3개의 Part로 나누어 설명하려고 합니다. 또한, 앞으로 소개될 내용의 전반적인 코드는 hello-elk-thread에서 확인하실 수 있습니다.• 먼저 이번 포스팅인 Part1에서는, ELK 환경에서의 Request 요청 로깅과 Sentry를 사용한 이슈 트래킹 전략의 기반을 마련합니다. 그리고 몇 가지 문제점을 설명하려고 합니다.• Part2에서는, Part1에서 설명한 문제점을 해결하기 위해 ThreadContext를 활용하여 이슈 트래킹 전략을 발전시킨 과정을 설명하려고 합니다.• 마지막인 Part3에서는, Part2에서 다루지 못하는 배치성 API, 비동기 상황에서의 극복을 위해 Multi Thread Context를 활용하여 발전시킨 과정을 설명하려고 합니다.만약에 ELK, Sentry를 사용한 이슈 트래킹 전략을 이미 사용하고 있다면, Part2부터 읽기를 시작하는 것을 추천드립니다.ELK 환경에서 로그 기반 마련하기이슈 발생 시 원인을 분석하기 위해서는 로그 정보를 확인하는 과정은 필수적일 것입니다. 하지만 로그를 분석하기 위한 별도의 환경이 구성되어 있지 않다면, 파일로 쌓아둔 로그 파일들을 하나하나 찾아가며 원인 분석을 해야 할 것입니다.ELK 스택은 애플리케이션에서 출력한 로그를 ElasticSearch에 저장하고, Kibana 대시보드를 통해서 로그 데이터의 가시성을 확보할 수 있는 환경을 제공합니다. 예를 들어 본 포스팅에서 설명할 내용처럼 Request 요청에 대한 로그 정보를 Kibana 대시보드를 통해 정보를 획득하는 것입니다.따라서 이슈 발생 시 쌓아둔 로그 파일에 접근하는 것이 아닌, Kibana 대시보드에 접근하여 로그 데이터를 빠르게 획득하여 보다 기민한 원인 분석을 할 수 있을 것입니다. 만약에 로그 분석을 하기 위한 별도의 환경이 구성되어 있지 않다면, ELK 스택을 활용한 본 포스팅의 내용이 도움이 될 것입니다.RequestLoggingFilter를 사용한 Request 요청 로깅Java Servlet의 기술 중 Servlet Filter는 클라이언트의 요청과 서버의 응답 사이에 위치하

본 글은 SK플래닛에서 OPA(Open Policy Agent)를 이용하여 사내 JIRA의 권한을 구현한 사례를 공유하며, 아래와 같이 크게 세 가지 작업을 정리하고자 합니다.• 첫번째는 개발 중인 ITSM 시스템에서 권한 부분을 OPA를 이용해 구현합니다.• 정책은 Rego로 작성합니다.• 두번째는 작성된 정책을, data API를 이용해 권한 체크를 구현합니다.• 세번째는 애플리케이션과 OPA 서버를 하나의 파드로 묶어 사이드카 형태로 쿠버네티스 개발 환경에 배포합니다.• ITSM 시스템의 백엔드를 Java Spring 및 JPA를 사용하여 개발하였고, 현재 사용 중인 JIRA를 대체할 예정입니다.• JIRA의 데이터를 이전할 계획이라, JIRA의 데이터 구조를 그대로 사용하고자 합니다.• JIRA의 권한 관련 데이터 및 권한 정책을 확인하였습니다.• JIRA의 프로젝트 관리 권한을 가진 사용자라면 아래와 같은 페이지에서 프로젝트의 롤과 퍼미션의 수정이 가능합니다.• Users and Roles 에서 ADMINISTRATORS/DEVELOPERS/USERS 롤에 그룹 및 사용자를 할당할 수 있습니다.• Project Permissions 에서 각 퍼미션에 사용자, 그룹 및 위에서 할당한 롤을 추가할 수 있습니다.• 이렇게 화면에서 설정한 값은 JSON으로 아래와 같이 표현합니다(JIRA API를 통해 확인).• 파일 크기가 꽤 되므로 일부 내용만 캡쳐하며, permissionKey(퍼미션 내용)과 grants(권한부여) 을 포함한 동일한 형태의 퍼미션을 배열로 정의하고 있습니다.• 해당 JSON을 OPA에서 권한 체크 시, 데이터로 사용합니다.• 이러한 구조를 염두해 두고 권한 처리를 생각해 보면, 사용자 및 사용자의 그룹이 속한 롤을 확인하고,• 사용자 아이디, 그룹명, 롤명으로 permissions의 grants를 뒤져서 해당 사용자가 해당 퍼미션에 권한이 있는지 여부를 확인할 수 있습니다.• 복잡해 보이지만 의외로 간단합니다. Rego를 작성해 봅니다.• 작성한 정책(rego)과 데이터을 이용하여 권한을 체크합니다. OPA 플레이그라운드에서 테스트할 수 있습니다.• 백엔드 서버에서 OPA data API를 이용하여 권한 체크를 하는 로직을 개발해 봅니다.• Spring security의 PreAuthorize 태그를 이용합니다.• Spring controller에 권한 체크를 위해 PreAuthorize 태그를 추가합니다.• PreAuhorize에서 opaclient.allow를 호출합니다.• opaClient.allow는 아래와 같이 구현하였습니다.• input으로 사용자 아이디와 그룹, 권한을 체크하고자 하는 프로젝트와 퍼미션를 입력합니다.• 개발한 백엔드 서버와 OPA 서버을 쿠버네티스(이하 k8s) 환경에 개발 서버로 배포해 봅니다.• 아래 k8s deployment yaml를 이용하여, 백단서버(pitsm-backend)와 OPA서버를 한 pod 내에 container로 배포합니다.• OPA 서버를 사이드카 형태로 실행

hyeoni.c 평소 잘 사용하던 라이브러리의 정책과 내부 구현을 살펴보며 문제를 해결해 가는 과정을 재밌게 풀어내었습니다. 유사한 경험을 가지신, 앞으로 마주할 수 있는 모든 분들에게 추천합니다!daisy.dani URI 정보가 왜 갑자기 사라졌을까요? 이 글에서 원인을 파헤치고, 어떻게 해결할 수 있는지 알아봅시다!Spring 프레임워크가 제공하는 UriComponentsBuilder 클래스를 아시나요? UriComponentsBuilder 클래스는 URL을 쉽게 다루기 위한 유틸 클래스입니다. 이번에 URL을 수정하기 위해 UriComponentsBuilder 클래스를 사용하던 중 서비스 장애가 발생했는데요. 원인을 분석해 보니 java.net.URI 클래스와 UriComponentsBuilder 클래스 사이에서 꽤나 흥미로운 일이 이뤄지고 있습니다. 무슨 일인지 궁금하지 않으신가요? 지금부터 함께 당시의 상황 속으로 들어가 보겠습니다.안녕하세요. 채널서버유닛의 레인입니다. 채널서버유닛은 여러분이 카카오페이의 다양한 서비스와 혜택을 마주하고 탐색할 수 있도록 홈 탭, 혜택 탭, 결제 탭 등 다양한 전면 서비스를 개발하고 있습니다. 이러한 서비스에는 이 글의 배경이 되는 알림피드도 존재하는데요. 카카오페이 앱을 사용하신다면 아래 사진 속 공간, 알림피드가 익숙하실 겁니다.알림피드는 여러분이 언제나 편하게 알림을 탐색하고 원하는 서비스를 방문할 수 있도록 노력하고 있습니다. 클릭하면 메시지가 사라지는 OS 알림 센터와 달리 메시지를 다시 볼 수 있도록 30일 동안 보관하고 있고요. 알림을 식별하기 편하도록 메시지에 서비스를 표시하거나, 원하는 종류의 알림을 탐색하기 편하도록 필터 등의 기능을 제공하고 있습니다.기: 무슨 일이 발생했는가알림피드를 구성하는 데이터는 앱푸시로 발송하는 메시지에 기반하고 있습니다. 그래서 알림피드는 OS 알림 센터 환경에 맞춰진 데이터들을 목적에 맞게 가공해서 사용하고 있습니다. 이 과정에서 알림피드는 반복되는 키워드를 제거하는 등 문구를 가공하고 있는데요. 어느 날 메시지의 랜딩 URL도 가공해야 하는 순간이 찾아왔습니다.카카오페이 앱 정책이 변경되면서 OS 알림 센터와 알림피드에서 메시지의 랜딩 동작이 서로 달라야 했습니다. OS 알림 센터에서 앱푸시 메시지를 클릭한 경우는 카카오페이 앱이 열리고 특정 흐름을 거친 후 서비스로 랜딩 합니다. 하지만 알림피드에서 메시지를 클릭한 경우는 카카오페이 앱 내부에서의 동작이기 때문에 특정 흐름을 거치지 않아야 합니다.정책을 반영하기 위해서는 메시지의 랜딩 URL에서 특정 파라미터를 제거하면 됩니다. 아래와 같이 OS 알림 센터에 맞춰진 메시지 랜딩 URL에서 base 파라미터를 제거하면 되는데요. 알림피드에 랜딩 URL을 가공하는 로직을 추가한 그날 문제가 발생했습니다.• OS 알림 센터에서의 메시지 랜딩 URL:• 알림피드에서의 메시지 랜딩 URL:알림피드에 URL 재처리 기능을 배포하고 몇 시간 후, 내부 크루 채널을 통해 알림피드가 이상하다는 제보를 받았습니다