일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 미션
- 의존성
- Docker
- 코드리뷰
- Spring Batch
- yml
- MSA
- REDIS
- HTTP
- 서블릿
- 우테코
- mock
- 프리코스
- 스프링부트
- 세션
- AWS
- 우아한테크코스
- 스프링 부트
- 프로그래머스
- 백준
- 레벨2
- 트랜잭션
- Paging
- CircuitBreaker
- Level2
- JUnit5
- 우아한세미나
- AOP
- JPA
- 자바
- Today
- Total
목록백앤드 개발일지 (72)
늘
프로젝트가 거의 막바지 단계에 다다라서 운영할 때 꼭 필요한 로그를 찍으려고 한다. 이번 로그는 AOP를 이용해서 찍었지만 다음번에는 인터셉터를 이용해서 찍어보려고 한다. (경험은 많을수록 좋으니😇😇) Log설정 build.gradle implementation 'org.springframework.boot:spring-boot-starter-aop' implementation 'com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.5.8' 우리는 aop를 적용할것이기 때문에 aop와 p6spy라이브러리를 추가해준다. slf4j slf4j2 p6spy는 나중에 정리해보도록 하겠다. 참고 주소는 글 맨 아래에 남겨두겠다! logback-spring.xml appli..
대용량 데이터 처리하는 방법에 여러 방법이 있다. Load Balancer Request를 연결된 서버들에게 나누어줌 장애 발생시 해당 LB(Load Balancer)에게 할당된 IP를 다른 LB에게 넘겨줌 DBMS 2개(Master-Slave = Primary-Secondary) primary(실제 서비스) primary에서 장애 발생시 secondary가 primary로 되고, 장애가 해결되도 primary는 secondary 역할을 하게 된다. primary(CUD), secondary(R) 두대를 두고 primary의 데이터를 secondary로 계속 Replication을 통해 복제한다. Object Storage Service (File-Server) 파일을 저장할 서버를 둘 경우 총 3개의 ..
프로젝트를 진행하면서 휴대폰 인증 기능이 추가되어 과정을 기록할 겸 적어보겠다. 이용한 api는 네이버 클라우드에서 제공해주는 한 달에 50건 무료인 api를 사용했다. https://www.ncloud.com NAVER CLOUD PLATFORM cloud computing services for corporations, IaaS, PaaS, SaaS, with Global region and Security Technology Certification www.ncloud.com 네이버 클라우드에 우선 가입을 해주고 콘솔에서 빨간 박스로 들어가 줍니다. 들어간 후 api 가이드에 따라 진행하면 수월하다. 친절하게 설명이 되어 있는데 설명에 따라 우선 프로젝트를 생성해 줍니다. 그 후 SMS를 눌러줍니다..
백신 2차까지 맞고 팔을 잃었지만 아직 나에겐 다른 한쪽 팔이 남았다 🤫🤫 귀와 팔 한쪽이 멀쩡하기 떄문에 우아한 세미나에서 기선님의 강의를 듣고 직접 적용해보고 정리해보려고 한다. 멋있음ㅋ META-INF/spring.factories 에서 이렇게 자동 설정을 한다. 이러한 자동설정들이 제공되어 있는 게 스프링 부트이다. 순서는 애플리케이션 설정한 빈이 먼저 등록되고 그 후에 자동 설정으로 제공하는 빈이 등록된다. 만약 앞에서 애플리케이션에서 설정한 빈 등록이 있고, 자동 설정으로 제공하는 빈의 빈 아이디가 중복이 되있다면 충돌 나서 애플리케이션이 뜨지 않는다. 또한 자동 설정으로 제공하는 빈끼리도 중복되면 충돌나서 애플리케이션이 뜨지 않는다고 한다. application.properties/ appl..
테스트코드를 작성해보면서 JUnit4나 5를 사용하는데 이번 포스팅에서 4와 5를 비교하고 JUnit5 사용법에 초점을 맞춰서 정리해두려고한다. Junit5 Platform: Junit으로 작성한 테스트를 실행해주는 런처를 제공한다. TestEngineApi 제공한다. Vintage: Junit3과 4를 지원하는 TestEngine 구현체 Jupiter: Junit5를 지원하는 TestEngineApI 구현체 Junit 5는 스프링부트 2.2 버전 이상부터는 기본적으로 의존성이 장착되어 따로 설정할 필요가 없다. Junit5의 애노테이션들 @Test - 테스트 메서드를 나타내주는 애노테이션이다. - Junit4와 달리 어떠한 속성도 선언하지 않는다. //Junit4 @Test(expected = Exce..
WHEN? 언제 무엇이 왜 사용되는가? - 로그인 처리 방식에 대해서 고민하면서 필터와 인터셉터를 공부했는데 둘이 비슷하다고 생각되고 둘 중에 어느 때에 무엇을 선택해야 할지 명확한 해답이 안 나와서 글을 적으면서 정리해보려고 한다. *공부를 하던 중 AOP와도 비교를 하는 글들이 보여서 짧게 추가해보았다. (개인적인 생각!) 우선 AOP는 앞서 필터와 인터셉터와는 다르게 비즈니스적 관점에서 사용할 때, 사용된다고 생각된다. ex) 로직의 시간 측정, 트랜잭션 관리, 에러 처리 등, 반면에 필터나 인터셉터는 인증/인가, 세션 체크, 인코딩 확인 등 좀더 웹과 관련된 공통 관심사 처리하는 느낌으로 구별하면 될 것 같다. 이제 본격적으로 필터와 인터셉터를 분석해 보겠다. 제목에서도 보았듯이 필터는 Dispa..
compose사용하는 이유, 도커의 멀티 컨테이너들을 묶어서 관리할 수 있다. ex) redis 서버와 실제 운영할 서버처럼 두 개의 서버를 연결하면 --link와 같은 명령어를 사용해야 하지만 docker-compose를 이용하면 손쉽게 연결하여 사용할 수 있다. docker-compose.yml version: "3" # 도커 컴포즈의 버전 services: # 이곳에 실행하려는 컨테이너들을 정의 redis-server: # 컨테이너 이름을 지정 (원하는 이름) image: "redis" # 사용할 이미지 이름 giron: # 컨테이너 이름을 지정 (원하는 이름) build: "" # 현 디렉토리에 있는 Dockerfile을 사용하여 빌드 ports: - "5000:8080" # 로컬포트:컨테이너포트..
연관관계는 객체 참조가 있는 상태이다. A -> B로 영구적으로 갈 수 있는 경로가 있다고 보면 된다. class A{ private B b; } 의존관계는 파라미터의 타입이 나오거나, 리턴 타입에 나오거나, 메서드 안에서 그 인스턴스를 생성하면 인스턴스이다. 일시적으로 관계 맺고 헤어지는 관계 class A{ public B method(B b){ return new B(); } } 1. 양방향 의존성을 피하라 - 성능 이슈 - sync를 맞출 때, 많은 버그를 만날 수 있다. 2. 다중성이 적은 방향을 선택하라 - 즉, One-To-Many보단 Many-To-One방향을 잡는 게 더 좋다 - 성능 이슈, 컬랙션의 관계들을 유지하기 위해 노력하는 게 너무 힘들다. 3. 의존성이 필요 없다면 제거하라 4..
[build.gradle] plugins { id 'org.springframework.boot' version '2.3.1.RELEASE' id 'io.spring.dependency-management' version '1.0.9.RELEASE' //querydsl 추가 id "com.ewerk.gradle.plugins.querydsl" version "1.0.10" id 'java' } group = 'study' version = '0.0.1-SNAPSHOT' sourceCompatibility = '1.8' configurations { compileOnly { extendsFrom annotationProcessor } } repositories { mavenCentral() } depend..
이번에는 JPA 기본을 중심으로 Batch 처리에 대해서 조금 다뤄보려고 한다. 저번 시간에 얘기 했던 것처럼 수백만 건의 배치 처리할 때, 일반적인 방식으로 엔티티를 계속 조회하면, 영속성 컨텍스트에 많은 엔티티가 쌓이면서 메모리 부족 오류가 발생한다. 따라서 이러한 배치 처리를 적절한 단위로 영속성 컨텍스트를 초기화해야 한다. 또한 2차 캐시를 사용하고 있다면 2차 캐시에 엔티티를 보관하지 않도록 주의해야 한다. [JPA 등록 배치] 수만 건 이상의 엔티티를 한 번에 등록할 때 주의할 점은 영속성 컨텍스트에 엔티티가 계속 쌓이지 않도록 일정 단위마다 영속성 컨텍스트의 엔티티를 데이터베이스에 플러시하고 영속성 컨텍스트를 초기화해야 한다. EntityManager em = entityManagerFact..