일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- aspect
- OOP
- 객체지향프로그래밍
- RestControllerAdvice
- 인터셉터
- response
- MYSQL
- exception
- spring boot
- SQL
- Filter
- http
- Transaction
- 트랜잭션
- 스프링 시큐리티
- request
- Interceptor
- 디자인패턴
- git
- 스프링
- 관점지향프로그래밍
- Spring
- proxy pattern
- 자바
- java
- network
- aop
- 스프링부트
- mybatis
- Spring Security
- Today
- Total
목록전체 글 (64)
장쫄깃 기술블로그
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/pbv1l/btrWr7hjdGp/0EdLkve1rRBwR1EDirXzok/img.jpg)
들어가며 하나의 어플리케이션에서 다중 DB에 접근할 수 있는 설정에 대해 알아보려고 한다. 대략적인 순서로는 application.yml 설정파일에 db 연결정보 작성 Config 파일 생성 service, dao, mapper 파일 생성 테스트 위와 같으며, 패키지 구조도 함께 살펴보겠다. 0. 프로젝트 구조 프로젝트 구조는 다음과 같다. 중요하게 봐야할 부분은 Mapper 인터페이스 파일과 쿼리를 작성하는 xml 파일을 DB별로 나눠서 사용할 수 있게끔 나누었다. 1. application.yml 설정파일에 db 연결정보 작성 연결하려는 DB의 접속정보들을 작성한다. 2. Config 파일 생성 Mybatis를 사용하기 위해 HikariCP의 DataSource를 설정하였다. HikariCP에 대한 ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/blWvFu/btrPQICZesB/1bkkPn6MGOnfQRA5AfRWZ1/img.jpg)
들어가며 application.yml 이나 application.properties 파일에 DB 접속 정보 또는 키 값을 명시하는 경우 중요한 정보들이 외부로 유출되어 심각한 피해가 발생할 수 있다. 이를 해결하기 위해 해당 파일의 정보를 암호화하는 방법에 대해서 알아보려고 한다. 이번 게시글에서 사용할 라이브러리는 jasypt(Java Simplified Encryption) 이다. 참조 : http://www.jasypt.org/ Jasypt: Java simplified encryption - Jasypt: Java simplified encryption - Main Jasypt 1.9.3 RELEASED! (May 25th, 2019) [DOWNLOAD and ChangeLogs] [WHAT'S ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/pWLtJ/btrPVElMSv9/AuYkpizmtHICja4DlcdMOK/img.jpg)
들어가며 서비스를 제공하다 보면 운영환경과 개발환경이 서로 다른 경우들이 있다. 예를 들면, 운영 DB와 개발 DB 환경이 다르거나, 로그 레벨을 다르거나 하는 경우이다. 그럴 때마다 매번 application.yml 혹은 logback.xml 파일을 수정할 수 있지만, 매우 비효율적이다. 이번 게시글에서는 실행환경(profile)에 따라 다른 설정 파일을 사용하는 방법에 대해서 알아보려고 한다. 이번 게시글은 스프링 2.4 이상 버전을 기준으로 작성하였다. 2.4 버전을 기준으로 application.yml에서 active profile을 설정하는 방법이 바뀌었다. spring: profiles: active: dev spring: config: activate: on-profile: dev 1. re..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/ldWoD/btrM29BJhvX/q2LkaZ7GU9NJXL8vqvz8wK/img.jpg)
들어가며 지난 게시글에서 @ControllerAdvice, @RestControllerAdvice에 대해 알아보았다. 이번 게시글에서는 해당 어노테이션을 사용하여 예외 처리하는 방법에 대해서 알아보려고 한다. Rest API 구현 중 오류 메시지는 개발자가 의도한 오류(Custom Exception)와 예상치 못한 오류(System Exception)로 구분된다. 이번 게시글에선 이러한 예외 상황에 대한 공통 예외 처리(Exception Handler)를 적용하는 방법에 대해 알아보겠다. 네이버 오픈 API 오류 메시지 형식 가이드처럼 API 오류 메시지에 대해 일관된 형식으로 응답하도록 설계해야 한다. 신규 API를 구현할 때마다 작성하도록 설계하는 것은 작업자마다 일관된 응답 구조를 보장하기 어렵기 ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bbhROo/btrMYTlUKiA/jJV6EHr2WoI7EAkshKuwB1/img.jpg)
들어가며 자사 서드파티 API를 개발하는 업무를 담당했을 때, 처음에는 모든 예외처리를 try-catch로 처리하였다. 그렇다 보니 불필요한 중복 코드들이 많아지고 가독성도 떨어졌다. 또, 코드가 점점 복잡해져 생산성도 떨어졌다. 확실한 건 중복되는 코드들이 너무 많았다. 이러한 문제를 해결하기 위해 고민하고 찾아본 결과 @ControllerAdvice, @RestControllerAdvice를 발견했다. @ControllerAdvice 란 /** * Specialization of {@link Component @Component} for classes that declare * {@link ExceptionHandler @ExceptionHandler}, {@link InitBinder @InitBi..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/dnceBo/btrMIOLIFGA/UTCwSZyYryL1MYR7IkYu70/img.jpg)
git-flow란 git-flow는 git이 새롭게 활성화되기 시작하는 10년전 쯤에 Vincent Drissen이 제안한 효율적인 git 브랜치 전략이다. 현재는 git으로 개발할 때 거의 표준과 같이 사용되는 방법론이다. 말하자면, git-flow는 기능이 아니라 하나의 방법론이라는 점이다. Vincent Drissen도 언급했듯이 git-flow가 완벽한 방법론은 아니고 각자 개발 환경에 따라 수정하고 변형해서 사용하라고 언급한다. git-flow 5가지 브랜치 모델 Vincent Drissen의 브랜칭 모델에는 5개의 브랜치가 사용된다. master develop feature release hotfix master 정식 배포되는 안정적인 버전의 소스코드가 관리되는 브랜치로, master 브랜치의..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/lYpgc/btrMkgcDkxk/I7LZKcKFKN3mzGwjvL6tQ1/img.jpg)
Merge 일반적으로 많이 사용되는 병합으로, 커밋 이력을 모두 남길 때 사용한다. git checkout jangjjolkit git merge my-branch 이 방식은 다시 Fast-Forward 방식과 Recursive 방식으로 나뉜다. Fast-Forward 새로운 브랜치 my-branch가 jangjjolkit 브랜치로부터 분기된 이후 jangjjolkit 브랜치에 새로운 커밋이 올라오지 않았다면, my-branch 브랜치가 jangjjolkit 브랜치와 비교하여 최신의 브랜치라고 할 수 있다. 이런 경우 my-branch의 변경 이력을 그대로 jangjjolkit으로 가져올 수 있는데, 이를 Fast-Forward Merge라고 한다. Recursive my-branch가 jangjjolk..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bJyB8p/btrLLWlpzTw/4jT2zSZse40Z1s7KNmK1rK/img.png)
캐시(Cache) 란? 컴퓨터 공학 전반에서 이야기되는 캐시는 자주 사용되는 데이터를 임시로 복사해두는 임의의 장소를 의미한다. 그리고 데이터를 캐시에 저장하는 행위를 캐싱이라고 한다. 일반적으로 캐싱은 캐시에 저장된 데이터에 접근하는 시간에 비해 원본 데이터에 접근하는 시간이 오래 걸리는 경우 사용한다. HTTP 캐시 앞서 설명했듯이 캐시는 자주 사용하는 데이터에 더 빠르게 접근하기 위해 사용한다. 데이터 접근을 위해 네트워크를 사용해야 하는 웹 환경에서도 캐시는 유용하게 사용된다. HTTP 캐싱을 활용하면 웹 사이트의 로딩 시간을 개선할 수 있다. 특히 자주 변하지 않는 정적 파일(js, css, 이미지 등)들을 캐시를 사용하지 않으면, 요청마다 새롭게 다운로드 해야 한다. 이는 불필요한 네트워크 비..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/LaXOb/btrLQzikkYP/XC4gu8FDkPkljcnsCpZ9Qk/img.png)
프록시(Proxy) 란? 프록시는 클라이언트와 서버 사이에 위치한 중계 서버로, 통신을 대신 수행하는 대리자 역할을 한다. 프록시가 없다면 클라이언트는 서버와 직접 통신한다. 반면, 클라이언트와 서버 사이에 프록시 서버가 있다면, 클라이언트와 서버는 프록시를 한번 거쳐 통신하게 된다. 왜 프록시를 사용할까? 프록시를 사용하면 보안을 강화할 수 있고, 통신 성능을 높여주며, 통신 비용을 절약할 수 있다. 프록시는 프록시 서버의 위치에 따라 유형이 나뉜다. 유형에 따라 각각의 용도도 조금씩 다른데, 이 글에서는 프록시의 유형을 크게 포워드 프록시(Forward Proxy)와 리버스 프록시(Reverse Proxy) 2가지로 나누어 설명하려고 한다. 포워드 프록시 (Forward Proxy) 포워드 프록시는 ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/blGG3R/btrLQnaVCql/NgilKb1rCspPgcTS96s161/img.png)
중단 배포 방식과 다운타임 서버 한대로 서비스를 운영한다면, 서버 배포 시 어떻게 될까. 현재 서버에서 V1 버전이 실행되고 있는 상황이다. 그리고 우리는 여러 기능이 추가된 V2 버전을 새로 개발했다. 이제 사용자들이 V2 버전을 사용할 수 있도록 배포해야 한다. 배포를 하려면 우선 기존에 V1 버전이 실행되고 있는 서버를 중지시켜야 한다. V1 버전과 V2 버전은 서로 같은 포트를 사용하므로, V2 버전을 실행하기 전에 먼저 V1 버전의 프로세스를 중단해야 한다. 이 시점부터 사용자들은 서비스를 사용할 수 없게 된다. 사용자가 V2 버전을 사용할 수 있도록 바로 V2 버전을 빌드 후 실행해야 한다. 빌드, 로딩과정을 거치고 V2 버전이 정상적으로 실행되면 사용자들은 서비스를 이용할 수 있게 된다. 이..