동기

최근 chrome80 의 cookie 정책변경으로 저자가 서비스하는 모든 서비스들을 https로 운영하기로 했다. 관련 이슈는 여기 (https://hyeonguj.github.io/2020/02/05/chrome80/ ) 에 정리하였다.

기존에는 local환경과 개발서버에서는 http로 통신을 하며 작업을 하였으나 바뀐 정책에서 쿠키를 읽기위해서는 https로 서비스를 해야한다.

개발서버의 경우 apache나 nginx에서 모두 http -> https로 바꾸어주며, 인증서 처리가 되어있기때문에 문제가 되지 않는다. 하지만 local 환경의 경우 tomcat 또는 spring boot application에서 https로 서비스를 할 수 있어야 테스트가 가능하다.

chrome80

크롬 80버전부터 새로운 쿠키 정책(SameSite Cookie)이 시행될 예정이다.
이 정책이 시작되면 어떤 영향도가있는지, 어떻게 대응해야할지 알아보자

바뀐 쿠키정책

목적

CSRF ( cross-site-request-forger ) 공격을 막기 위해 third-party 쿠키를 막으려는것이 기본 컨셉이다. 이를 위해 cookie 정책중 samesite의 기본값을 바꾼다. 하지만 이렇게되면 오류가 매우 많이 발생할수 있으니 top-level navigation일 경우에는 third-party cookie를 허용해주는 Lax를 기본값으로 한다.
chrome79 에서는 samesite 기본값이 None으로 되어있으나 chrome80 부터는 Lax가 된다.

logback

지난포스트 에서 logback의 기본적인 설정에 관하여 다루었다.
이번 포스팅에서는 logback-spring.xml과 profile로 설정을 나누는 방법, 그리고 그 전략에 대해 다룬다.

logback-spring.xml

spring에서 logback은 설정파일을 아래와같은 순서로 찾는다.

1. logback.groovy
2. logback-test.xml
3. logback.xml
4. default

spring-boot의 경우 조금 다르게 logback-spring.xml이라는 이름으로 설정한다.
logback.xml 으로 설정하면 spring-boot 가 설정되기전에 로그백설정을 완료한다. 따라서 spring-boot에서 사용하는 properties 나 profile같은 설정값을 사용할 수 없게된다.

profile에 따라 로그설정

기본적인 logback.xml에 관한 설정은 logback 기본설정 포스팅에서 다루고 profile 설정에 관해 알아보자.

필자는 크게 console에 로깅, file에 로깅, 그리고 logstash로 로그를 전송하는 3가지 설정을 하였다.
그리고 profile별로 아래와같이 나누었다.

phase에 따라서 proflies를 나누는 경우에는 아래와같이 설정 할 수 있다

spring boot logging

스프링부트는 모든 내부 로깅에 Commons Logging를 사용한다, 그러나 근원적인 로그 구현체를 열어볼 수 있다. 기본 설정들은 Java Util Logging, Log4j 그리고 Logback을 제공한다. 각각 콘솔로 출력되고 파일로 출력된다. (10MB 크기가 되면 파일을 새로 생성)

기본적으로, ‘Starter POMs’를 사용한다면, Logback을 로깅에 사용할 것이다. 유연한 Logback은 Java Util Logging, Commons Logging, Log4j 혹은 SLF4J 를 사용하는 의존적 라이브러리들을 의존적인 라이브러리들도 문제없이 동작하는 것을 보장한다.

팁: 자바에서 사용가능한 로깅 프레임워크들은 대부분 지원한다. 목록만 보고서 당혹러워할 이유는 없다. 기본적으로 로깅 의존성을 변경할 필요는 없을 것이며 스프링부트는 기본적으로 잘 되어 있어있다.

스프링 부트에서 일정 시간 주기적으로 작업하는 스케쥴러를 만들어보려고 한다

@EnableScheduling 추가하기

• @EnableScheduling 주석은 응용 프로그램의 스케줄러를 활성화하는 데 사용된다
• 기본 스프링 부트 애플리케이션 클래스 파일에 추가해야 한다

1
2
3
4
5
6
7

@SpringBootApplication
@EnableScheduling
public class DemoApplication {
   public static void main(String[] args) {
      SpringApplication.run(DemoApplication.class, args);
   }
}

코딩테스트

각종 it회사에서 개발자를 채용할때 코딩테스트 전형을 실시하고있다
코딩테스트를 준비하기위해서는 다양한 알고리즘을 실전처럼 풀어보는것이 중요하다.
이때 다양한 문제를 풀어보고, 내가 제출한 답이 맞는지 테스트를 해볼 수 있는사이트들이 있다.

• 백준 : https://www.acmicpc.net
• 프로그래머스 : https://programmers.co.kr

각 사이트마다, 언어마다 인풋/아우풋을 다루는 방법이 다르므로 숙지해야한다.
이포스트는 백준에서 자바코드를 제출하는 방법에 대해 다룬다.

nginx의 기본 에러페이지

nginx의 기본 에러페이지가 노출되는 현상은 서버 정보를 노출할수 있으니 커스텀한 페이지로 수정할것을 권장한다.

가이드

http status code 에따라서 디폴트 에러페이지를 지정할 수 있다
경로는 yum 을 이용해 nginx를 설치한 기본경로로 가정한다.

설정파일의 기본경로:
/usr/local/nginx/conf/nginx.conf

nginx의 static page또한 설치방법마다 경로가 다르다, 하지만 수동으로 지정 가능하다.
기본경로는 /usr/share/nginx/html 으로 되어있을것이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

server {
    listen       443 ssl;
    server_name  hyeonguj.github.io;
    ....
    location / {
        proxy_pass         http://127.0.0.1:8080;
    ....
    }
    
    
    error_page  403 404 405 406 411 497 500 501 502 503 504 505 /error.html;
    location = /error.html {
        root /usr/share/nginx/html;
    }
}

http status code 에따라서 디폴트 에러페이지를 지정할 수 있다.

jenkins 빌드시에 가끔 git branch 가 충돌이 나기도한다
예를들면,
예전에 받아두었던 브랜치(feature/a)
이번에 빌드할 브랜치(feature/a/a/a) 로 되어있으면 feature/a 는 directory 로 쓸수없으니 충돌이 나게된다

쉽게 생각할수 있는 방법은 빌드할 브랜치이름을 바꾸거나
jenkins서버에가서 branch들을 정리하는 방법이 일반적인 해결 방법이다.

오늘 소개할 방법은, 더 간단하게 jenkins 설정으로 예방하는 방법이다.
빌드시 local repository를 비우고, 새로 clone받아 빌드하도록 한다.

javascript상에서 쿼리스트링을 생성하여 redirect하거나, 비동기로 요청을 해야하는 경우가 있다.
간단하게는 string을 직접 생성하여 사용하는 방법도 있다.
jquery는 좀더 우아한 코드작성에 도움을 준다, 파라메터가 복잡할수록 가독성도 좋아진다.

파라메터가 하나 추가될때 이전방식은 변수선언과 url합성을 동시에 해야하는반면,
jquery를 사용했을때는 들어가는 object의 내용만 바꿔주면된다.

before

1
2
3
4
5
6
7

var id = "myId";
var name = "myName";
var age = "20"
window.location = 'http://localhost:7000?' + 
            '&id=' + id +
            '&name=' + name
            '&age=' + age;

after

1
2
3
4
5
6
7

var url = 'http://localhost:7000';
var obj = {
        id    : 'myId',
        name : 'myName',
        age : 20
    };
window.location = url +'?' + $.param(obj);

웹서비스를 하다보면 데이터를 조회하고, 그데이터를 일괄 다운로드하는 니즈가 생긴다.(특히 어드민)
이런경우 서버 성능에따라 oom(out of memory)이 발생할 수 있다.
자주 생기는 상황으로는 대량의 데이터를 조회한 다음, 이를 엑셀파일로 내려받는경우가 있다.
이 경우를 예시로 원인과 해결법을 알아보고자 한다.

원인

1. db에서 데이터를 가지고와서 객체로 들고있는 단계에서 OOM
2. workbook을 생성해 데이터체우다가 OOM
3. 메모리에 담고있는것을 전송하는 단계까지 메모리를 계속 holding! - OOM 확률 up!

개선포인트

A. db에서 한번에 가지고오는 데이터 크기(fetch size)를 조절한다
B. db에서 가지고온 데이터를 통체로 들고있지 않고 나누어 처리한다.
C. 엑셀에 내용을 체우다가 일정 사이즈 이상 되면 Disk에 쓰도록 한다 (기존에도 되어있음)
D. 임시파일은 바로바로 삭제하도록한다 (삭제를 명시적으로 하지 않으면 tomcat 내려갈때 삭제됨. 강제종료시는 삭제 안될 가능성)
E. 다운로드 중복클릭 방지