일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- laravel
- 맛집
- tool
- redis
- java
- Git
- it
- php
- Design Patterns
- elasticsearch
- jenkins
- linux
- AWS
- Spring
- Gradle
- jsp
- db
- docker
- Web Server
- 요리
- IntelliJ
- devops
- JPA
- MySQL
- Oracle
- ReactJS
- springboot
- javascript
- ubuntu
- Spring Boot
- Today
- Total
목록전체 (785)
아무거나
Ehcache3 (Maven) CacheManagerBean 구현을 통한 Ehcache3 적용 Ehcache3 부터는 JSR-107 로 CacheManager 로 구현해야 한다고 한다. JSR-107 호환 캐시를 사용하기 위해선 JCache 구현 필요 구현 ehcache.xml 생성 (resources 경로 - alias: @Cacheable 의 value 값, key: 키값, value-type: cache 로 저장할 값) java.lang.String java.util.ArrayList 30 com.lotteon.display.config.ehcache.CacheEventLogger ASYNCHRONOUS UNORDERED CREATED EXPIRED 10000 1000 Cache Logger [Ca..
원인 원인은 Redis 의 Packet Loss 가 발생하였고 해당 애플리케이션의 전체 Pod 에서 OOM 이 발생하면서 재시작되는 현상이였고 Pod 의 Heap 메모리 사용량은 여유가 있는 상태였습니다. 왜 이러한 문제가 발생하였는지 알아보겠습니다. 컨테이너에서 OOM 발생 먼저 서버로그를 확인해본 결과 Gzip 압축 적용후에 점진적으로 메모리 사용량이 증가한 내용이 확인되었다. 또한 컨테이너에 OOM Kill 도 발생한 것을 확인할 수 있었다. 그러나 이상한점은 Heap Memory 는 정상적인 수치로 확인되었다. 원인분석 Native Memory 에서 OOM 이 발생하였고, Heap Memory 는 정상 적이라 애플리케이션 코드에 문제가 있다고 판단 하였고 관련하여 상기 언급 되었던 배포 항목중 g..
시작에 앞서 먼저 Java8 부터 삭제되는 영역인 Permanent Generation 부터 알아보자면 Class 혹은 Method Code 가 저장되는 영역이다. 줄여서 PermGen 이라고 하며, Heap 영역에 속한다. PermGen 에는 로드된 클래스의 정보, 정적 변수, 상수 정보 등 변하지 않을 것이라고 어느 정도 보증되는 데이터가 저장된다고 한다. PermGen -> Metaspace 영역으로 변경된 이유 PermGen 은 메모리가 제한되기 때문에 OOM(=OutOfMemoryError) 이 발생하게 된다. 그래서 해당 문제를 해결하기 위해 Native 메모리를 사용하는 Metaspace 로 변경되었으며 Metaspace 영역은 Native 메모리를 이용함으로써 개발자는 영역 확보의 상한을 ..
Cache 적용 패턴 및 관리 전략 읽기 캐시 전략 Cache-Aside 캐시는 데이터베이스와 직접 연결되지 않고, 애플리케이션이 주체가 되며 보편적으로 많이 사용되는 캐시 전략, 읽기 요청에 적합 방식 (1) 캐시에 데이터가 존재하는지 확인 (2) 데이터가 존재하면 캐시 데이터 반환 (3) 데이터가 존재하지 않으면 애플리케이션에서 DB 에 데이터 요청 후 캐시에 저장하고 데이터를 반환 Read-Through 애플리케이션이 캐시를 직접 바라본다. 즉, 캐시가 주 데이터스토어로 인식되며 데이터베이스로 동기화하는 몫은 캐시에 위임, 읽기 요청에 적합 최초 호출 시 캐시에 데이터가 없으므로 첫 요청시 캐시가 갱신되게 대응 (Ex: Cache Warm up 스케쥴 작업 등..) 방식 (1) 캐시에 데이터 요청 ..
React + Typescript 에서 FC 를 사용하면 안되는 이유 먼저 React17 이하에서는 아래와 같이 React.FC 사용이 가능하며 React18 이상부터는 없어졌다고 한다. 참고 그러나 FC 를 사용하는건 좋은 방법이 아니며 CRA 에서는 여러가지의 이유로 FC 를 없애야 한다고 이슈가 올라왔었고 반영되었으며 이유는 아래 설명을 참고하자. children 을 암시적으로 가지고 있다. FC 를 이용한 컴포넌트 props 는 type 이 ReactNode 인 Children 을 암묵적으로 가지게 되며 이는 꼭 타입스크립트에 한정하지 않더라도 안티패턴이라고 한다. 왜냐하면 children 이라는 암묵적이었던 키워드는 자식노드가 필요한지 아닌지의 의도를 명확하게 드러낼 수 없다는, 타입의 관점에서..
Spring Boot + Jacoco 를 활용한 코드 커버리지 관리 해당 포스팅에 대한 코드는 https://github.com/bkjeon1614/java-example-code 를 참고 Jacoco 란? Java 코드 커버리지를 측정하는 도구이다. (코드 커버리지란 소프트웨어 테스트를 논할 때 얼마나 테스트가 충분한가를 나타내는 지표중 하나이다. 또한 코드 커버리지는 소스코드 기반으로 수행하는 화이트 박스 테스트를 통하여 측정한다.) Jacoco 를 사용할 경우 장점은 아래와 같다. 소프트웨어의 안정성을 높여준다. 사이드 이펙트가 발생할 확률이 높아진다. 간결하고 재사용성이 좋은 코드를 작성할 수 있게 해준다. 코드 커버리지 측정기준 코드 커버리지의 측정기준은 구문(Statement), 조건(Cond..
Spring Boot + Junit5 를 활용한 테스트 코드 분리 해당 포스팅에 대한 코드는 https://github.com/bkjeon1614/java-example-code 를 참고 테스트 분리를 왜 하는가? 각각의 테스트 규칙에 따라 테스트 코드를 작성하게 될 경우 통합 테스트가 단위 테스트보다는 아무래도 전체적으로 하다보니 수행속도가 느릴 수 밖에 없다. 즉, 개발과정에서 통합 테스트를 지속적으로 수행하게 된다면 개발생산성이 매우 저하 될 것이다. 그러므로 테스트 분리에 따라 테스트 수행을 하는것이 더 효과적일 수 있다. Given - When - Then Pattern Given - When - Then Pattern 은 테스트 코드를 접해본 개발자들은 한 번쯤은 보았을거라고 생각한다. 해당 ..
BatchGetItem (WHERE IN) 정의 다수의 테이블 아이템을 hashkey, rangedkey 를 지정해서 가져올 수 있으나 결과값이 100개로 제한된다, 특정 rangedkey 로 다수의 아이템 검색이 필요하면 query 과 권장된다. BatchGetItem 은 조건식을 사용할 수 없고 쿼리 결과를 수정할 수 없기 때문에 상황에 따라 GetItem 과 적절하게 선택하여 사용하는것이 좋다. WHERE IN 절과 비슷하게 사용할 수 있다. 사용법(SDK) [build.gradle] ... implementation 'com.amazonaws:aws-java-sdk-dynamodb:1.12.239' ... [DynamoDBConfig.java] ... import com.amazonaws.serv..
Spring Boot + Gradle 을 활용한 정적 코드 분석 도구 Spotbugs 적용 해당 내용은 Spotbugs 4.7.3 기준으로 작성하였고, Spotbugs Gradle Plugin 5.0.14 를 활용하였다. 예제소스: https://github.com/bkjeon1614/java-example-code/tree/develop/bkjeon-mybatis-codebase 정적 코드 분석 도구란 정적 분석 도구 는 코드를 검사하여 메모리 누수 또는 버퍼 오버플로우 등 일반적으로 알려진 오류 및 취약점을 파악하고 코딩 표준 적용이 가능하다. 즉, 코드의 정확도, 스타일, 성능 등 코드 품질에 관련된 패턴을 분석해서 알려준다. 또한 GNU Lesser General Public License 조건에..
파티션 (partition) 대량의 데이터를 테이블에 저장할 때, 물리적으로 별도의 테이블로 분리해서 저장시키는 기법 (단, mysql 내부적으로 분리되어 처리되기 때문에, 파티션이 얼마나 있든 사용자는 하나의 테이블로 보인다.) 특정 DML과 Query의 성능을 향상시키고, 주로 데이터가 실시간으로 쌓이는 데이터베이스 환경에서 효율적이다. 특히 Full Scan에서 데이터의 접근 범위를 줄여 성능 향상을 가져올 수 있습니다. 물리적인 파티셔닝으로 인해 전체 데이터의 훼손 가능성이 줄어들며, 각 파티션 별로 독립적으로 백업하고 복구할 수 있다. 다만, 테이블 간 Join이 일어날 경우 비용이 증가 하며 테이블과 인덱스를 별도로 파티셔닝 할 수는 없다. 파티션 종류 기본적으로 파티셔닝은 수평 분할과 수직 ..