![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/qYs9k/btsyuJ4MB12/kN4LKxkV7VppvYwrVqfOaK/img.png)
외/내부적으로 개인이 진행한 스터디 기록을 확인했으면 한다는 수요가 있어 현재 하루스터디 서비스에선 Google OAuth 로그인을 통해 개인 스터디 기록 조회 기능을 제공하고 있다. 하지만 처음 인증 관련 로직을 구현해 도입하는 과정에서 이해가 부족한 부분이 많았다. 다행히 최근 인증 플로우를 점검하면서 생각이 짧았던 포인트들을 많이 찾아내고 정리할 수 있었다. 이 기회에 인증 로직이 처음부터 어떻게 바뀌었는지, 어떻게 바뀌어야 하는지 정리해보려고 한다. 1. Access, Refresh Token 방식과 JWT 사용 구조 맨 처음 인증 로직을 작성할 때는 토큰과 세션 방식의 차이를 인식해가는 수준이었다. 경험이 없으니 토큰과 세션 중 어떤 것을 사용할지 결정하기도 어려워 함께 사용할 OAuth 2.0..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/vGiMO/btsxtohwK7q/ODWPMNQFldsoFrMCR5lNNk/img.png)
벨로그에 우리 서비스를 홍보했던 글을 보고 많은 분들이 기대 이상으로 사용해 주시고 응원해 주셨다 여러 플랫폼에 서비스를 소개했지만 운 좋게도 벨로그에서 추천을 굉장히 많이 받아 글이 주간 트랜딩 3위까지 올라갔고 현재는 월간 트렌드로 넘어간 상태다. 덕분에 무난하게 초기 사용자 목표를 달성할 수 있었다. 사실 이보다 더 기대했던 것은 실 사용 데이터였고, 의미 있는 수준의 데이터가 쌓여 이를 바탕으로 우리의 서버가 얼마나 안정적으로 사용자를 수용할 수 있을지 테스트가 가능해졌다. 마침 새로 추가되는 기능으로 인해 API 호출 수준이 많이 늘어날 것으로 예상되었고, 테스트 결과를 바탕으로 목표한 수준의 로드에서도 병목이 발생한다면 어느 부분이 문제인지 인지하고 튜닝을 진행할 것을 기대했다. 테스트 목표:..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/sSgpX/btsvM0Cim5I/7UkCUt1kWxjO3Ks1v3yxg1/img.png)
JPA를 통한 테스트 구현 과정에서 entityManager의 merge()를 사용해 준영속인 엔티티를 다시 영속화하고 변경 감지를 아래처럼 사용하려 했으나 제대로 적용되지 않았다. entityManager.merge(entity); entity.proceed(); // 상태 변경 메서드 entityManager.flush(); 준영속 상태인 엔티티를 다시 영속화하고 상태를 변경하였는데 변경 감지가 동작하지 않았다. merge() 시에 select 쿼리가 나가기는 하나 proceed() 시에 update 쿼리가 나가지는 않았다. proceed() 이후 entityManager.contains(entity)로 영속화 여부를 확인해도 false가 출력되었다. 아래와 같이 순서를 바꾸니 변경 내용을 정상적으로..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/bFpKV8/btstX297o0E/WRB2BU7cGx3jGYV1CmkRT1/img.png)
이 글에서는 Java Enum의 valueOf()보다 switch ~ case의 사용이 빠른 예시와, Enum의 switch ~ case가 바이트코드 레벨에서 어떻게 최적화되는지를 기술하였다. Spring MVC의 코드를 살펴보던 도중 RequestMethod라는 Enum에서 HTTP 요청 메서드 문자열을 Enum으로 변환할 때 java.lan.Enum.valueOf()를 사용하지 않고 resolve()라는 메서드를 별도로 만들어 사용하는 것을 보았다. // Spring 6.0.6+ public enum RequestMethod { GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE; @Nullable public static RequestMethod resolv..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/vBxop/btssZcZM1gV/4DEPufxea8uUknp8Cne6uK/img.png)
DB 마이그레이션을 진행하며 동시에 데이터의 일부를 개발 서버의 인메모리로 데이터를 관리할 일이 생겼다. DB와 웹 서버의 변경이 동시에 일어나야 하는 상황에서 다운타임이 없는 무중단 배포를 하는 것은 많이 까다롭다. 변경된 데이터를 다루는 API들에 대해서 정교하게 요청을 구분하고 프록시 서버로 라우팅을 해줘야 한다. 다행히(?) 변경하려는 서버는 운영 서버가 아닌 개발 서버이고, 웹서버도 한 대만 올라간 상태여서 비교적 간단한 중단 배포를 하기로 결정했다. 이 예시는 Jenkins, MySQL과 SpringBoot 서버 환경에서 진행되었으며 예약 명령어들을 사용해 밤 시간에 DB 및 웹 서버를 안전하게 예약하여 재배포하는 방법을 다룬다. DB 스키마 변경 예약하기 DB의 스키마 변경은 MySQL의 이..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/cmPet6/btsqY02nKLq/McPDj6YYoYIs934qAdDuq0/img.png)
간단한 SpringBoot Rest Api 서버를 배포한 뒤 해당 서버가 설치된 AWS EC2에 대한 모니터링이 필요해졌다. 본 글은 설치 및 운영에 대한 가이드보다 어떠한 배경을 고려하여 도입하게 되었는지를 위주로 작성했다. 고려 사항과 목표 모니터링 시스템 구축 시 고려한 제약 사항은 아래와 같다. 배포한 Api 서버가 초기 단계여서 아직 부하가 거의 없는 상황 EC2에 대한 ssh 접속이 사내 네트워크에서만 접속이 가능하여 외부에서 대시보드로 상황을 확인할 수 있어야 함 보안을 위해 모든 IP에서 접속 가능한 EC2의 인바운드 규칙은 443, 3000, 8080 포트로 제한이 되어있으며 EC2 한 대는 443과 8080은 이미 HTTPS 접속과 Api 서버에 사용 중이어서 사실상 3000번만 사용이..
- Total
- Today
- Yesterday
- thenComparing
- 람다식
- Java
- GitHub Discussion Template
- comparing
- Spring
- java switch case
- 우테코 프리코스
- logback-spring.xml
- springboottest
- 우테코 5기
- Spring 테스트
- invokedynamic
- JPA JSON
- GitHub Discussion
- stubbing
- Jenkins 예약 배포
- 우테코
- 스프링
- RandomPort
- 자바
- Fromtail
- 함수형 인터페이스
- MySQL 이벤트 스케줄
- Spring Boot Monitoring
- GitHub Discussion 템플릿
- JPA
- 생성자 주입
- Payload 암호화
- 의존성 주입
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 |