인생을 코딩하다.

안녕하세요. 이번에는 프로젝트에서 Redis를 적용해야 하는 이슈가 생겼는데요. Redis를 적용해야 하는 이유는 여기서 확인 하실 수 있습니다. 우선 Spring Boot Redis Docs와 함께 외부 Redis에 간단히 알아볼까요? https://docs.spring.io/spring-boot/docs/2.0.0.M7/reference/htmlsingle/#boot-features-connecting-to-redis hget "spring:session:sessions:9a398c47-36c6-4d33-95d1-80f51447f7eb" "sessionAttr:email" "\xac\xed\x00\x05t\x00\x0fadmin@gmail.com" 하지면 여기서 문제가 하나 있습니다. 스프링에서 로그..

프로젝트를 scale out 방식으로 확장할 계획을 하면서 그에 따른 session의 정합성에 관한 이슈가 생겼습니다. 별도의 독립적인 session 저장소로 세션의 정합성 문제를 해결하기 위해서는 대표적인 redis와 memcached 데이터 베이스를 고려해볼 수 있습니다. Amazon ElastiCache는 Memcached 및 Redis 캐시 엔진을 지원합니다. 각 엔진에는 몇 가지 장점이 있습니다. 이 항목의 정보를 활용하면 요구 사항에 가장 잘 맞는 엔진과 버전을 선택하는 데 도움이 됩니다. Memcached와 Redis 엔진은 둘 다 인 메모리 키-값 저장소입니다. NoSql 데이터베이스라고도 할 수 있죠. 그러나 실제로 상당한 차이점이 있습니다. session의 정합성 이슈를 해결하기 위해서..

프로젝트에서 세션 로그인 기능을 만들었습니다. 그리고 추후 저는 대용량 트레픽을 감당할 수 있는 서버를 만들 계획이 있었습니다. 대용량 트레픽을 감당할 수 있는 서버를 만들기 위해 scale up을 고려해 서버를 한 대만 놓는다면, 서버 한 대에 모든 부하가 집중되므로 장애 시 서버가 복구될 때까지 서비스를 중단해야 하는 상황이 발생합니다. 사용하려던 서비스가 중단된다면, 그에 안좋은 기억이 생기고 타 서비스로 이용을 바꾸거나, 서비스를 사용하지 않을 수 있는데, 이것은 엄청난 비즈니스 손실(수익 손실)이 생길 수 있습니다. 그러기 위해선 scale out을 고려해 서버를 확장해야 했습니다. 하지만 서버 확장시 제가 만든 세션 로그인 기능에 문제가 생길 우려가 있었습니다. 이 문제는 아래에서 그림과 함께..

Redis(Remote dictionary server)란? Remote -> 외부, dictionary -> HashMap (Key - Value), server -> 서버 Database, Cache, Message borker In-memory Data Structure Store Supports rich data structure Redis(레디스)는 REmote DIctionary Server의 약자로 오픈소스DBMS입니다. In-memory 데이터 저장소이며, Key-Value기반의 NoSQL DBMS입니다. 보통 DB, Cache(캐시), 메시지 브로커 등의 용도로 사용합니다. Redis를 효율적으로 쓰기 위해선 Cache에 관해 잘 알아야합니다. Cache는 나중의 요청에 대한 결과를 미리..

프로젝트에서 이메일 중복 체크 관련해서 이슈가 하나 있었습니다. 클라이언트에게는 json으로 "이미 존재하는 이메일입니다."라고 예외를 전환해서 JSON 통신으로 알려줬습니다. 그런데 생각해보니 실제 서비스를 돌리고 있다고 가정하면, 클라이언트는 알 수 있지만 정작 서버를 만든 저는 알 수가 없었습니다. 알기 위해서는 콘솔창에 찍혀야했습니다. 그래서 Log로 서버에도 기록을 해야겠다는 생각이 들었습니다. 추가로 개발도구를 24시간 실행하고 있진 않을터이니 추후 슬랙으로 정보를 받을 수 있도록 만들어야 할 것 같다는 생각도 들었습니다.. 슬랙은 컴퓨터 앞에 앉아있지 않아도 폰으로도 계속 확인할 수 있을터이니.. 위에서 말한 이메일 중복체크 관련 외에도 동작상태나 상황등에 관해 디버깅이나 모니터링을 위해 정..

application.yml에 아래 로직을 다 구현했다고 가정해봅시다. // application.yml spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql: username: password: jpa: hibernate: ddl-auto: create-drop properties: hibernate: format_sql: true logging.level: org.hibernate.SQL: debug default Profile만 쓰면 어떤 문제점이 있을까요?? 아무런 테스트 없이 바로 개발서버, 실서버에 서비스를 배포하게 된다면 예기치 못한 장애와 버그들이 생길 수 있습니다. 예상치 못한 실수 등의 예를 하나 ..

@Transactional fun saveUser(userDto: UserDto) { // 이메일 중복체크 예외처리 로직 if (userRepository.existsByEmail(userDto.email)) { throw EmailDuplicateException() } ... 중간 생략 userMapper.save(user.toUserEntity()) } 위의 코드에서 saveUser메서드는 회원가입을 하는 API다. 이 메서드에는 이메일 중복검사에 관한 기능과 회원 정보를 저장하여 회원가입을 하는 기능이 있다. 또한 위에서 보이는 로직 말고도 추 후 변경이 생겨 다른 로직들이 더 추가 될 수 있다. 서비스에서 회원가입 기능의 흐름상 이메일 중복검사 기능은 어떤식으로든 들어가야 한다. 또 변경이 생겨..

1. 롬복은 왜 써야할까요 어노테이션 기반이기 때문에 코드 자동생성을 통한 생산성을 향상 시킬 수 있습니다. 그에 따라 반복되는 코드르 줄여 가독성 및 유지보수를 향상 시킬 수 있습니다. 추가로 빌더 패턴이나 로그 생성 등 다양하게 활용할 수 있습니다. 하지만 롬복에는 주의사항도 있습니다. @AllArgsConstructor,@RequiredArgsConstructor을 사용했을 떄, 필드 순서를 바꾸면 생성자의 순서도 바뀌는데, 기존 코드의 수정은 필요하지 않기 때문에, 개발자가 의도한 대로 동작하지 않아 버그가 생길 가능성이 큽니다. @Setter의 사용은 객체를 언제든지 변경할 수 있는 상태가 되어서 객체의 안전성이 보장받기 힘듭니다. @Data를 사용하면 모든 어노테이션을 한 번에 사용하기 떄문에..