내가 겪은 메모리 누수 이야기 - 두 번째
2020년 12월 1일 화요일
·- 블로그를 날려먹었다가 복구해서 이미지가 깨져있습니다 ㅠㅠ (사내 위키에 썼었던 글을 옮깁니다.) 실험 결과로서 타임아웃을 줄이는 것이 메모리와 관계가 있다는 것은 알았지만 왜 그런지 궁금하여 조사해 본 결과를 정리해 보았습니다. (원래 스프링 시큐리티의 구조를 간단히 설명하는 글을 저도 공부하면서 써볼까 했는데 시간이 오래 걸려 미루었습니다...) 스프링 시큐리티는 요청을 필터 체인으로 동작합니다. 세션을 사용 하는 필터는 SecurityContextPersistenceFilter와 SessionManagementFilter가 있는데 간략화해서 SecurityContextPersistenceFilter의 동작에 대해서만 기술하려고 합니다. 스프링 시큐리티에서 인증된 사용자의 정보를 저장하는 곳 입니다. 인증된 사용자는 Context에 정보가 채워지게 됩니다. ThreadLocal로 구현되어 있습니다. 이 필터는 필터 체인 중에 상위에 위치하여 SecurityContextRepository 인터페이스로 부터 얻는 정보로 SecurityContextHolder를 채워 줍니다. 코드를 보면 아래와 같은 순서로 수행됩니다. SecurityContextRepository에서 SecurityContext를 가지고 옴. 불러온 SecurityContext를 SecurityContextHolder에 설정. 체인 필터 수행. SecurityContextHolder 클리어. 저장되어 있던 SecurityContextHolder를 SecurityContextRepository에 저장. 기본적으로 SecurityContextRepository는 HttpSession을 사용하는 HttpSessionSecurityContextRepository으로 설정되어 Session에 저장하게 됩니다. 요약하자면, 인증 필터들이 수행되기 전에 인증 정보를 세션에서 꺼내서 설정 해주고 필터가 수행되면 다시 세션에 저장해 줍니다. 그렇다면… 세션에 설정한다는 것이 어떤 의미를 가지고 있을까요? 나무위키에는 아래와 같이 설명하고 있습니다. 웹 서버에서 임시로 클라이언트의 데이터를 갈무리하는 것을 뜻한다. 쿠키와 역할이 비슷한데, 쿠키는 클라이언트 측에 데이터를 갈무리하는 반면에 세션은 서버 측에 데이터를 갈무리해 놓는다는 차이점이 있다. 주로 로그인, 온라인 쇼핑몰의 장바구니 등에 쓰인다. 클라이언트의 정보를 서버에 저장하는 것 정도가 되겠습니다. 세션은 파일, DB, In-Memory, Redis 등등에 저장할 수 있는데 우리가 쓰는 Undertow에서는 InMemorySessionManager를 기본으로 사용하여 In-Memory에 세션을 저장합니다. 다시 위의 요약으로 돌아가서 세션에서 꺼내 인증 상태로 만드다는 것은 클라이언트와 서버에서 사용하는 HTTP 프로토콜은 무상태성(Stateless)을 가지고 있는데 동일한 세션이고 이미 인증되었다면 인증된 상태로 만들어 주는 것이라고 할 수 있겠습니다. 우리 플랫폼에서 인증은 펠릭스가 만들어 준 람다에서 처리하고 결과를 모든 클라이언트 요청은 헤더에 담아서 보내줍니다. 그렇기 때문에 지금에야 드는 생각이지만, 요청 끼리 인증 결과를 공유하지 않아도 될 듯 합니다. 세션에서 인증된 결과를 불러와 SecurityContextPersistenceFilter뒤의 인증 필터들(UsernamePasswordAuthenticationFilter, BasicAuthenticationFilter)에서의 인증 시도를 건너뛴다고 하더라도 인증 필터에서 오래 소요되는 작업을 하는 것이 아니기 때문에 큰 영향은 없을 듯 합니다. (타암아웃을 설정했을 때와 하지 않았을 때의 TPS를 측정해 보면 명확할 것 같습니다.) 찾아보니 Spring Security Config에는 SessionManagement에서 세션 관련 설정을 할 수 있도록 되어 있습니다. SessionManagement에는 설정 필드들 중에는 최대로 생성할 수 있는 세션 수를 설정하는 maximumSessions와 (기본값은 제한이 없습니다.) 세션 생성방식을 설정하는 sessionCreationPolicy가 있습니다. sessionCreationPolicy에는 아래와 같은 값을 설정할 수 있습니다. ALWAYS - 항상 HttpSession을 생성합니다. NEVER - HttpSession이 있을 때만 사용하고 만들지는 않습니다. IF_REQUIRED - 필요할 때만 HttpSession을 만듭니다. (기본 값) STATELESS - HttpSession을 만들지 않고 사용하지도 않습니다. HttpSession을 만들고 사용하지 않기위해 STATELESS로 설정하려고 합니다. 값이 STATELESS일 때는 SecurityContextRepository로 NullSecurityContextRepository가 선택됩니다. NullSecurityContextRepository는 아래와 같이 SecurityContextPersistenceFilter의 필터에서 아무런 일도 하지 않습니다. 그럼 이제 테스트를 해봐야겠습니다. 테스트 커뮤니티 DEV를 대상으로 저번과 같이 댓글 조회하는 API를 호출하려고 합니다. Scouter 띄우고 nGinder로 부하를 줘 세션 타임아웃 기본 값(30m)으로 두었을 때와 적게 조절 (5m) 했을 때, 그리고 세션을 설정하지 않았을 때의 TPS와 Heap Memory 사용율을 확인해 보려고 합니다. nGinder에서 500명의 사용자로 10분간 계속 호출 하도록 합니다. JAVA_OPTS는 아래처럼 설정했습니다. CMS GC를 사용합니다. 지난 번에 테스트 했던 상황입니다. Heap 메모리가 점차 차오르다가 6분정도가 지났을 때 TPS가 급감했습니다. Heap 메모리가 차는 6분 전에 세션이 만료되기 때문에 TPS가 급감하는 현상이 나타나지 않았습니다. TPS는 큰 차이는 없었고 Heap 메모리가 요청에 따라 증가하는 현상이 없었습니다. 끝으로 SecurityContextHolder가 원인인줄 알았는데 Session에서 메모리를 많이 차지하는 현상으로 보입니다. 인스턴스 사양을 변경하기 전에 세션 설정을 변경해야 겠습니다. 그런데 실제로 Session을 사용하는 어플리케이션에서는 이런 현상을 어떻게 처리해야 할까요? 메모리를 많이 잡거나 타임아웃을 조절하는 수 밖에 없을까요? 더 이상 메모리 문제는 없었으면 좋겠습니다.
의존성을 가진 다중 DataSource의 순환 참조 오류 분석
내가 만든 프로젝트 중에는 에서는 2개 이상의 DataSource를 사용하고 있는 것이 있다. Aurora RDS의 Reader, Writer 엔드포인트에 연결되는 DataSource를 만들고 사용하고 있다. 이 방법에 대한 실효성은 논외로 하고, 그 프로젝트에서 최근에 모종의 이유로 Spring Boot Actuator에 대한 의존성을 제외했다. 그런데 모듈을 제외하고 빌드를 수행하니 DataSource Bean의 순환 참조 오류가 발생했다. 문제를 해결하기 위해 우선 HikariConfig Bean을 생성하는 것으로 변경했지만 모듈의 포함 여부가 DataSource의 생성에 영향을 주는 것이 굉장히 의아했기 때문에 그 이유를 분석해 보고 결과를 남겨보려고 한다. 오류 메시지와 사용했던 코드를 간략화한 것은 아래와 같다. 순환 참조 에러는 경험한 적이 있기 때문에 어떤 상황에서 발생하는지 알고 있었다. 하지만, DataSourceInitializerInvoker가 왜, 그리고 어디서 DataSource를 참조하는지를 몰랐기 때문에 이 클래스의 역할에 대해 알아보았다. Spring 문서에는 다음과 같은 설명이 있다. InitializingBean#afterPropertiesSet()에서 schema-*.sql을 실행하고 DataSourceSchemaCreatedEvent에서 data-*.sql 스크립트를 실행하여 DataSource 초기화를 처리하는 Bean이다. 설명을 적어보면 DataSourceInitializerInvoker는 DataSource의 초기화를 위해서 2가지 인터페이스를 구현하여 스키마 생성과 빈 생성 시점에 초기화 할 수 있다. 그리고 DataSourceInitializerPostProcessor에 의해서 DataSource 생성 후에 만들어진다. 역할과 생성 시점을 알고 나니 DataSource를 참조할 법도 해 보인다. 좀 더 명확한 이유를 알기위해 에러가 발생하는 곳을 디버깅을 해 보았다. 에러가 발생한 메소드는 Singleton Bean생성 전에 호출되는 콜백으로, 코드에서 보듯이 singletonsCurrentlyInCreation라는 Set에 현재 생성하려는 Bean 이름이 있다면 BeanCurrentlyInCreationException을 발생시킨다. singletonsCurrentlyInCreation에는 아래의 목록을 포함하고 있었고 communityDataSource가 이미 존재하기 때문에 에러가 발생한 것이다. 에러가 난 곳으로부터 trace를 따라가 보니 DataSourceInitializerInvoker가 구현하고 있는 InitializingBean인터페이스의 afterPropertiesSet메소드에서 DataSource를 가져오려고 한 것을 알 수 있었다. 그리고 @Primary 어노테이션에의해 communityDataSource가 선택되면서 순환 참조 오류가 발생하게 된 것을 알 수 있었다. 그렇다면 Actuator가 있을 때는 왜 발생하지 않았을까? Actuator가 포함되었을 때 singletonsCurrentlyInCreation에는 위와 같은 항목들이 있었다. 이 목록에서는 communityDataSource가 없었기 때문에 에러가 발생하지 않았다. 이 사실로 writerCommunityDataSource가 communityDataSource가 아닌 다른 어떤 것에 의해 생성되는 것을 알 수 있다. 모듈 포함 여부에 따른 DataSource 생성 플로우는 아래와 같이 진행된다. Actuator가 있을 때 5번째 과정에서는 순환 참조 에러가 왜 발생하지 않는지 모호하게 느껴졌었는데 디버깅을 해보니 DataSourceInitializerInvoker는 Bean 생성 후 호출되는 메소드이기 때문에 communityDataSource에서 의존관계를 찾을 때 정상적으로 찾는다. 생성하고 있는 Bean을 다시 참조하게 될 때만 순환 참조 에러가 발생하게 된다. 그렇다면 Actuator가 포함되었을 때는 Configuration에서 어노테이션으로 생성되는 시점보다 더 빨리 만들어져야 에러가 발생하지 않을 텐데 DataSource Bean을 생성하는 시점이 어떻게 다른 걸까? AbstractApplicationContext에서 빈이 생성되는 시점이 다른 것을 확인할 수 있었는데 Actuator가 포함되지 않았을 때는 finishBeanFactoryInitialization메소드에서 entityManagerFactory로 DataSource가 생성되고 Actuator가 포함될 때는 그보다 앞션 onRefresh메소드의 DataSourceHealthContributorAutoConfiguration에서 생성되는 것을 확인할 수 있었다. 그런데, 테스트하다 보니 스프링 부트 버전을 변경하니 Actuator가 포함되어 있어도 순환 참조 에러가 발생하는 것을 발견했다. 디버깅해보니 DataSourceHealthContributorAutoConfiguration는 DataSource를 생성할 때 DefaultListableBeanFactory에 정의된 beanDefinitionNames에서 DataSource 타입을 찾는데 에러가 발생하는 버전에서는 communityDataSource가 먼저 생성되어 아래와 같이 순환 참조 에러가 발생하게 된다. 버전에 따라 생성 순서가 바뀌는 이유를 Configuration클래스의 Bean메소드의 메타데이터를 읽는 ConfigurationClassParser클래스의 retrieveBeanMethodMetadata메소드의 주석에서 찾을 수 있었다. 불행하게도, JVM의 표준 리플렉션은 같은 JVM 에서 동일한 어플리케이션의 다른 실행 간에도 임의의 순서로 메서드를 반환합니다. 이 내용에 따라 Configuration클래스에서 Bean이 선언된 순서를 바꾸면 에러가 나던 버전에서는 에러가 발생하지 않고 에러가 발생하지 않던 버전에서는 에러가 나는 것을 확인 할 수 있었다. 지금까지 조사해본 내용을 요약해보면 아래와 같다. DataSource에 의존 관계가 있을 때 DataSourceInitializerInvoker에서 선택되는 DataSource에 따라 순환 참조 에러가 발생 할 수 있다. Actuator가 포함되었을 때 에러가 나지 않던 이유는 DataSourceHealthContributorAutoConfiguration에서 DataSource를 생성해서 순환 참조 에러가 발생하지 않았다. 하지만, 생성하는 순서에 따라 에러가 발생할 수 있으며 JVM에서 순서는 보장하지 않는다. 나의 경우에는 이 문제를 해결하기 위해 서두에 언급했듯이 DataSource의 의존관계를 없애고 DataSource를 1개만 생성하는 방법을 사용했다. DataSource를 생성하고 참조했던 이유가 @ConfigurationProperties가 설정된 필드는 변경하지 않고 Bean을 생성해주기 때문이었는데 DataSource를 생성하지 않고 HikariConfig만을 생성해 기존에 하고자 했던 것은 유지하도록 했다. 이제 에러가 발생하는 원인을 알았으니 다른 방법도 충분히 사용할 듯한데 DataSourceInitializerInvoker도 여러 개 정의되어 DataSource를 찾아올 수 있다면 순환 참조 에러가 발생하지 않을 것이다. 물론 해보지는 않았다.2020년 9월 30일 수요일·내가 겪은 메모리 누수 이야기 - 첫 번째
현재 플랫폼을 개발하고 운영하면서 몇 차례의 메모리 누수 문제를 겪었는데 이것들을 해결했던 과정과 그 원인을 적어보려고 한다. 발생한 지 몇 개월이 지난 것들이지만 혹시 나와 같은 문제를 겪는 사람이 있다면 도움이 되었으면 좋겠다. 가장 처음으로 발생했던 메모리 관련 문제는 서비스를 오픈하고 많은 날이 지나지 않았을 때였던 걸로 기억한다. 주말에도 마음 편하게 쉬지를 못하는 때였으니까... 아니나 다를까 정확한 선후 관계는 기억이 나지 않지만, 서비스가 느려진 것을 인지하고 각 서비스 상태를 모니터링했었다.2020년 6월 29일 월요일·아니... 서버 CPU의 상태가? Spring Data JPA 2.2.0
JPA 2.2.0 Heap JPA 2.2.0 TPS Spring Data JPA 2.2.4
JPA 2.2.4 Heap JPA 2.2.4 TPS CannotAcquireLockException과 Deadlock
내가 지금 회사에서 개발한 것 중에는 사용자에게 보이는 알림과 작품, 시스템에 대한 알림 설정을 관리하는 Notification API가 있고 댓글과 작품의 Rating, Like를 관리하는 Community API가 있다. 그런데 이 두 서비스에서 빈도는 낮지만, 간혹 CannotAcquireLockException이 발생하여 원인을 찾아보려고 했던 과정과 사례를 적어본다. 문서에는 이름과 같이 lock을 얻지 못해 발생하는 예외이다. 또한 stack trace의 메시지와 검색한 결과로 보건대 Notification API에서는 알림을 읽은 시간을 기록하는 Confirm API와 댓글을 Like 하는 Comment Like API에서 발생했고 deadlock과 관련되어 보였다. DB는 트랜잭션을 안전하게 수행하기 위해 lock을 사용한다. 그런데 트랜잭션들이 서로 필요한 lock을 가지고 있어 진행할 수 없는 상태가 되는 것이 deadlock이다. MySQL 문서에 있는 예제를 보면 어떻게 deadlock이 발생하는지 보여준다. 클라이언트 A에서 share mode로 select하여 lock를 얻는다. share mode는 트랜잭션이 끝날 때까지 값이 변경되지 않도록 한다. 그리고, 클라이언트 B에서 트랜잭션을 시작하고 row를 삭제한다. 삭제 작업은 x lock을 필요로 합니다. 그리고 s lock이 있는 동안은 x lock을 획들 할 수 없다. A가 s lock을 가지고 있고 B의 요청은 queue로 전달된다. 끝으로, A가 row를 삭제하려고 한다. deadlock은 이때 발생한다. A는 삭제 작업을 하기 위해 x lock이 필요하지만, B가 x lock에 대한 요청을 기다리고 있고 A가 lock을 해제하기를 기다리고 있기 때문이다. 결과적으로 InnoDB는 클라이언트 중 하나의 lock을 해제하고 에러를 발생시킨다. Confirm API는 알림을 읽은 시간을 기록하는 API이다. 30일 이내의 최대 50 건의 알림을 가져와서 읽지 않은 알림만 현재 시각으로 갱신하는 로직이다. (SimpleJpaRepository의 saveAll()을 사용한다.)결국, SELECT와 UPDATE하는 로직인데 UPDATE 할 때는 x lock이 필요하겠지만 위의 예제처럼 SELECT할 때 share mode를 쓰거나 하지 않아 s lock이 필요하지 않다. 그렇다면 왜 발생한 걸까? SHOW ENGINE INNODB STATUS 명령어의 LATEST DETECTED DEADLOCK 항목에 아래의 내용이 있었다. 이 내용으로 알 수 있는 사실은 다음과 같다. TRANSACTION 1은 id가 199064878인 row를 UPDATE 한다. TRANSACTION 2는 id가 199063150인 row를 UPDATE 한다. TRANSACTION 1은 UPDATE하는 record에 대한 x lock이 필요하여 기다리고 있다. TRANSACTION 2는 UPDATE하는 record에 대한 x lock이 필요하여 기다리고 있다. TRANSACTION 2는 TRANSACTION 1이 기다리고 있는 record의 x lock을 가지고 있다. 이 과정대로 쿼리를 수행하면 재현이 가능하다. 테이블을 생성. 위와 같이 데이터를 입력. 첫 번째 클라이언트에서 id가 1인 record의 x lock 획득. 두 번째 클라이언트에서 id가 2인 record의 x lock 획득. 그리고 id가 1인 record의 x lock을 얻기 위해 대기. 다시 첫 번째 클라이언트에서 id가 2인 record의 x lock 획득 시도. 여기서 deadlock발생. 재현 방법은 어렵지 않은데 위의 과정처럼 하나의 트랜잭션에서 2개 이상의 UPDATE명령을 실행해야 발생한다. 하지만 나는 트랜잭션을 사용한 적이 없었는데 deadlock이 발생한 것이 의아했다. 그러다가 saveAll() 코드를 확인해 보았는데 여기에 트랜잭션 어노테이션이 사용되고 있었다. 이제는 deadlock이 발생했을 때의 상황을 알 것도 같다. 짦은 시간 안에 Confirm API가 동시에 호출되어 읽은 시간을 업데이트하기 위해 알림 목록을 saveAll()로 업데이트할 때 같은 알림목록을 대상으로 하여도 업데이트가 수행되는 순서는 보장되지 않기 때문에 서로 다른 트랜잭션에서 lock을 필요로하는 상황으로 deadlock 발생한 것이다. Comment Like API는 댓글의 좋아요 버튼을 누를 때를 호출되는 API이다. comment, comment_like 2개의 테이블을 사용한다. comment_like에는 사용자가 댓글에 좋아요 설정 또는 취소한 상태를 comment에는 댓글과 좋아요 숫자를 필드로 가지고 있다. 아래는 2개의 테이블을 간략화한 스키마이다. 이것도 SHOW ENGINE INNODB STATUS로 deadlock 정보를 찾아보았다. Confirm API와 유사하지만 두 개의 트랜잭션이 하나의 row를 업데이트하고, 두 번째 트랜잭션이 x가 아닌 S lock을 가지고 있는 것이 눈에 띈다. 이 로직에서도 명시적으로 lock을 선언한 부분이 없는데 왜 deadlock이 발생한 것일까? InnoDB에서 lock을 설정하는 경우를 나열해놓은 문서에서 Foreign Key 조건에서 s lock을 설정한다고 나와있다. FOREIGN KEY가 테이블에 정의되어 있다면 제약조건을 확인해야 할 모든 insert, update, delete는 제약조건을 참조하고 있는 record에 shared lock을 설정한다. 또한, InnoDB는 제약조건이 실패하는 경우에도 lock을 설정한다. 이 내용대로 추론해보면 아래의 과정으로 재현할 수 있다. deadlock 테이블을 참조하는 deadlock_child 테이블 생성. 첫 번째 클라이언트에서 자식 테이블에 insert하여 deadlock 테이블의 id가 1인 record의 s lock 획득. 두 번째 클라이언트에서 동일하게 deadlock 테이블의 id가 1인 record의 s lock 획득. 첫 번째 클라이언트에서 x lock 획득을 위해 대기. 두 번째 클라이언트도 x lock이 필요. 여기서 deadlock 발생. 이것도 짧은 시간 안에 같은 API가 동시에 요청되어 발생한 문제라고 여겨진다. 이것 또한 MySQL 문서에서 deadlock를 어떻게 최소화할 수 있는지 알려준다. 기본적으로는 deadlock이 발생할 때는 재시도 하라고 하고 있으며 트랜잭션을 짧게 설정하라고 하고 있다. Confirm API의 경우에는 하나의 트랜잭션에서 수행되는 쿼리가 최대 50개가 될 수 있기 때문에 UPDATE ... WHERE IN 으로 변경하려고 한다. (2개의 row만 업데이트하는 경우에도 deadlock이 발생하기도 했다.) Comment Like API는 부모 테이블을 먼저 업데이트하면 deadlock이 발생하지 않는다. 쿼리에 필요한 lock을 미리 획득하기 때문인데 순서를 변경하여도 로직에는 영향을 주지 않기 때문에 순서를 바꿔도 무방하다. Deadlock found when trying to get lock; try restarting transaction ↩ https://jeong-pro.tistory.com/94 ↩2020년 6월 19일 금요일·Codility - FloodDepth
RESULT2019년 9월 20일 금요일·Codility - CountSemiprimes
RESULT2019년 9월 16일 월요일·Codility - CountNonDivisible
오랜만의 코딜리티... 근 2달만이다.2019년 9월 10일 화요일·그 동안 여러가지 일이 있었다.RESULTCodility - LongestPassword
RESULT2019년 9월 9일 월요일·Codility - MinAbsSum
RESULT 내가 이해한 바를 적어보면, 문제는 주어진 수들의 합이나 차의 절대값이 가장 수를 찾는 것이다. 바꿔말하면 주어진 집합을, 부분집합을 라 하고, 에서 를 제외한 나머지 수의 집합인 두 부분으로 나눌때 가 가장 작은 것. 즉, 가능한 부분집합들을 찾고 그 부분집합과 나머지 집합의 차가 가장 작은 수를 찾는 것이다. 부분집합의 차를 구하기 위해 집합의 모든 수를 다 더한 전체합을 이용한다. 전체합에서 구하려는 부분집합에 2를 곱하고 빼서 차를 구한다. 예를 들어, 라고 하고 라고 할 때 이고 이므로 S와 C의 차를 구할 수 있다. 그리고 부분집합을 선택 할 때 를 선택하는 경우와 를 선택하는 경우의 차가 동일하기 때문에 까지만 계산 할 수 있다. 부분집합을 구할 때에는 위에서 설명한 바에 따라서 두 부분의 부분집합 중 합에 대한 부분만을 찾아도 되며 그 부분집합의 합이 인 것까지만 찾으면 된다. 그런데 문제에서 주어진 집합에 길이에 비해 집합의 수의 범위가 작으므로 중복된 수가 많이 발생할 것이 예측가능하므로 계산 시간을 줄이기 위해 부분합을 구할 때 집합의 원소의 갯수를 활용하는데 부분합과 같이 기록하며, 부분합을 구하고 남은 숫자를 의미한다. 집합의 원소들을 까지 순회하면서 부분합을 찾는데, 이전 단계들에서 만든 부분합일 때는 현재 단계에서 사용할 수 있다는 의미로 카운팅을 넣고 이미 구한 부분합으로 만들 수 있는 부분합이라면 숫자 하나를 더 사용했다는 의미로 이전 단계에서 1을 뺀다.2019년 8월 30일 금요일·Codility - NumberSolitaire
RESULT2019년 8월 20일 화요일·