일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 미션
- 코드리뷰
- 프로그래머스
- yml
- JPA
- 우테코
- Docker
- 프리코스
- HTTP
- 서블릿
- CircuitBreaker
- REDIS
- 우아한테크코스
- 스프링부트
- mock
- 스프링 부트
- 백준
- MSA
- Spring Batch
- 우아한세미나
- Level2
- AWS
- 트랜잭션
- 자바
- 레벨2
- AOP
- JUnit5
- Paging
- 의존성
- 세션
- Today
- Total
목록우아한테크코스 4기 (41)
늘
프로젝트를 한창 할 당시에는 몰랐었지만 추후에 학습하면서 Event처리를 통해 의존성을 끊는 방법을 알았다. 기존의 공식 프로젝트도 외부 api사용 로직을 분리하고 인터페이스를 통해서 의존성을 많이 줄였다고 생각했는데 여전히 불필요한 의존성이 엮여있었다. 프로젝트가 종료된 후, 해당 문제점을 개선하면서 경험을 포스팅을 해봅니다. 문제 정의 임시 저장 게시글을 등록할 시, 임시 저장 게시글 삭제 로직 아래는 게시글 임시 저장 -> 임시 저장된 게시글을 등록 -> 게시글은 저장되고 임시 저장 글은 제거하는 로직입니다. 해당 로직에서 구체적으로 2가지 문제를 가집니다. Article -> TempArticle의 의존성 생성 게시글을 저장하는 로직에서 임시 저장글이 어떻게 처리 되어야 하는지를 알 필요가 없다고..
우아한테크코스에서 보안 특강을 듣고 정리가 필요하겠다고 생각했습니다. 백엔드 개발자도 OWASP정도는 알고 있어야 한다고 생각합니다. 따라서 정리를 해보겠습니다😁 OWASP란? OWASP는 ‘Open Web Application Security Project’라는 비영리 보안 프로젝트 재단을 의미하는 약자입니다. 이 재단에서는 애플리케이션에서 발생할 수 있는 취약점을 분석하고 연구하고 있으며 3~4년 주기로 Top10을 발표합니다. 2021년 이슈 Injection(1st -> 3rd) 2017년까지 1위를 달리던 Injection 취약점이 21년부터는 3위로 내려온 모습을 볼 수 있습니다. 이러한 이유에 대해서는 ORM이 많이 쓰이면서 발생한 현상이라고 생각해볼 수 있겠네요. 왜냐하면 ORM을 사용하면..
이전의 게시글에서 필자의 서비스에서 테스트는 @Tansactional을 통한 롤백을 제거했다. 이후, 매번 테스트에서 아래의 사진처럼 DatabaseCleaner를 주입받아 반복적으로 @AfterEach로 테스트가 끝난 후, 롤백을 진행해 주었다. 최근에 우아한테크코스 리펙토링 미션을 진행하면서 해당 방식에 대해서 알게 되었다. 이후, Junit5의 공식 문서를 확인해봤고 해당 기술에 대해서 알게 되었다. BeforeAllCallback - @BeforeAll 적용된 메서드 전에 실행(가장 먼저 실행된다.) BeforeEachCallback - @BeforeEach 적용된 메서드전에 실행 BeforeTestExecutionCallback - 각 테스트가 실행되기 직전에 실행(@Before후에 실행된다.)..
해당 글은 innodb에서 lock이 어떻게 동작하는지 어느 정도 알고 있는 상태에서 읽으면 좋을 것 같습니다! 제목에 JPA가 들어가서 주제가 JPA에 한정적으로 보일수 있겠다. 하지만 실제 해당 이슈는 JPA 뿐만 아니라 모든 곳에서 발생이 가능하다. 하지만 JPA에서는 dirty checking이라는 기능을 지원해주므로 더욱 조심해야 한다고 생각해서 제목으로 지어봤다. 본론으로 들어가자면 해당 상황이 위험한 이유는 lock과 관련이 있다. 그중에서 Lost Update 문제이다. (저희 서비스는 JPA와 MVCC를 지원하는 Mysql Innodb를 사용합니다.) QA를 진행하다 다른 팀에서 데드락이슈를 맞이했다. 우리 팀은 괜찮을까 테스트해보다가 다른 이슈를 맞이했다. 바로 동시성 이슈였는데 해당 ..
저번 게시글에서 레디스를 도입하기로 결정을 했고 처음으로 적용해보았다. 그런데 테스트를 하는 도중에 테스트 격리가 실패를 했다. 레디스에서 테스트 격리를 위해 일주일간 고군분투한 경험을 기록하려고 작성한다. 테스트가 돌아가지 않는 코드는 믿을 수가 없다! 필자의 팀은 테스트 코드가 돌아가지 않는 코드를 ec2에 올리지 않는다. 처음 시도하는 것들이기에 테스트 코드가 보장되지 않는다면 신뢰할 수가 없기 때문이다. 따라서 redis를 적용하고 잘 동작하는지 테스트가 필요했다. 레디스를 적용 후, 로컬에서는 정상 동작했다. 하지만 ec2의 젠킨스에서 빌드가 할 때 오류가 발생하는 문제가 발생했고 결국 레디스를 제거하였다...🤦♂️ 레디스 적용 후, 테스트하기 레디스를 적용한 후 테스트를 진행했다. 그런데 테..
Redis(Remote Dictionary Server)란? “key-value” 구조로 데이터를 저장하고 관리하기 위한 비 관계형 데이터베이스로 모든 데이터를 메모리에서 처리하는 메모리 기반 DB이다. 메모리를 통해 사용하기 때문에 일반적인 DB보다 빠른 성능을 보여준다. 레디스는 싱글 스레드로 동작한다. 캐시 매번 디비에 접근해서 디스크를 일고 쓰는 것은 비용이 크다. 따라서 데이터를 메모리에 두어 디스크에 접근을 최소화하는 방법이다. 어떤 정보를 캐시할까 잘 안 바뀌는데, 자주 읽어오는 경우 ex) 로그인 정보 key마다 태그를 달아서 어떤 데이터가 많이 생성되는지 확인한다. 캐시 vs 버퍼 버퍼는 주로 차기를 기다려서 꽉 차면 보내주고, cache는 미리 계산하고 가져온다. 버퍼는 쓰기를 위해서 ..
현재 저희 공식팀은 인수 테스트와 @WebMvc를 통한 컨트롤러 테스트, @SpringBootTest를 활용한 서비스 테스트, 그리고 @DataJpaRepository를 활용한 레포지토리 테스트로 크게 4종류의 테스트를 진행 중입니다. 테스트 격리 테스트 격리의 방식으로는 다양한 방식이 있습니다. DirtiesContext 사용하기 가장 쉬운 방법이지만 매번 컨텍스트를 올려야 하므로 느린 방식이어서 저희 팀은 처음부터 해당 방식을 적용하지 않았습니다. @Sql을 활용한 sql문 미리 작성하기 해당 방법을 미션 하면서 적용해보았다. 그때는 규모도 작고 페어로 진행하기 때문에 크게 문제가 되지 않았다. 그런데 팀 프로젝트에 적용하기엔 아래와 같은 단점이 많았다. 따라서 이것도 적용하지 못했다. 테스트에 필요..
현재 우아한테크코스에서는 톰캣구현하기 미션을 진행중이다. 해당 미션을 진행하면서 서블릿에 대해 정리를 해보려고 한다. 서블릿 특정 비즈니스 로직을 처리하는 서블릿 객체를 개발자가 만들어놓음. 각 로직마다 하나의 서블릿 객체만 생성. 싱글톤이 아니다!: 싱글톤 패턴의 경우 객체로 딱 한 번만 생성할 수 있도록 클래스 내부적으로 처리해놓음. 톰캣이 구조상 서블릿을 한번만 생성할 뿐임. HandlerAdapter와 HandlerMapping으로 나눈 이유 어댑터 패턴이 무엇인가 하면 • 현재 사용하고 있는 라이브러리가 더 이상 요구에 부합하지 않아 재 작성하거나, 다른 라이브러리를 사용해야 할 때가 있다. 다른 라이브러리를 사용하는 경우 Adapter 패턴을 이용해 기존 코드를 가능한 적게 변경하면서 새로운 ..
SQL 인젝션이란? 데이터베이스와 연동된 웹 애플리케이션에 공격자가 입력이 가능한 폼에 조작된 질의문 삽입하여 디비 정보 열람 및 정보를 조작하는 공격 단순한 기법이지만 강력한 공격이어서 반드시 주의해야 한다! 예방 방법 에러처리를 잘해서 테이블 정보를 사용자들에게 공개하지 않도록 해야한다. 테이블 정보 노출 및 컬럼 노출로 sql쿼리 작성이 가능하기 때문이다. 방어 방법 파라미터 바인딩! 직접 쿼리를 작성하지 않고 파라미터 바인딩을 사용하면 된다. 예시를 들어 설명해보겠다. SQL Injection에 취약한 코드 statement = connection.createStatemnt(); String query = "SELECT * FROM USERS WHERE name = '" + loginName + ..
현재 프로젝트가 어느 정도 진행되면서 Test위에 붙는 Import도 늘어났다. 아래 사진처럼 매번 Repository 테스트를 할 때마다 붙여줘야 하는데 불편해서 어노테이션을 만들어서 정리를 해보았다. 사실 포스팅 할만한 정도로 대단할 건 없지만 앞으로도 프로젝트를 진행하면 자주 적용할 것 같아서 기록해두려고 한다. 메타 어노테이션을 활용하여 위와 같이 작성해주면 끝! 이제 @Repository만 작성하면 간편하게 적용이 가능하다. 또한 스프링은 테스트 시 매번 컨텍스트를 띄우지 않고 테스트가 사용하는 컨텍스트를 캐싱해서 여러 테스트가 1개의 (애플리케이션) 컨텍스트를 공유하는 방법을 제공한다. 즉, 테스트마다 동일한 컨텍스트를 사용하면 컨텍스트가 1번만 올라가므로 테스트 성능에도 좋다. 1) @Rep..