gony-dev 님의 블로그

이전 포스팅에서는 Cache-Control Header를 이용한 캐싱 기능을 사용해봤다.이번에는 서버 내부에서 Spring Boot Cache를 이용하여 캐싱 기능을 이용해보도록 하겠다.Spring Boot Cache vs. Cache-Control Header과연 둘의 차이는 뭘까?아래의 표를 통해 알아보자! Spring Boot CacheCache-Control Header위치서버 내부클라이언트 or 중간 캐시대상메서드 실행 결과HTML 응답 전체목적서버 처리 속도 향상네트워크 트래픽 감소설정 위치Java 코드HTTP 응답 헤더TTL 관리Redis TTL 사용max-age, no-cache 등의 값으로 결정 결론적으로 쓰는 목적과 사용 범위가 다르기 때문에 둘을 비교하기에는 다소 애매하지만이 둘을 함..

프로젝트를 진행하다보면 회원 유입이나 기능적으로 발생하는 오류들에 대해 즉각적으로 확인해야한다.하지만 우리가 일반적으로 확인하는 방법으로는 DB나 AWS EC2에 직접 접근하면서 확인하는 방법들이었는데여기서 이런 의문이 들 것이다. "좀더 편하게 확인할 수 있는 방법이 없을까?"우리는 이 불편함을 해소하기 위해 Spring과 Slack을 연동하여 특정 이벤트에 대해 알림을 보낼 수 있도록 할 것이다. 1. Slack이란?개발이나 커뮤니티에 익숙치 않은 사람들은 Slack이라는 어플리케이션을 모를 수도 있을 것이다.Slack은 '클라우드 컴퓨팅 기반 인스턴트 메신저 및 프로젝트 관리용 협업툴'로 프로젝트에 대해 관리하고 논의할 때 높은 효율성과 가독성 있게 구성되어 있다.그래서 실무 개발자들도 현재 Sla..

Overview일전에 다루었던 Redis는 캐싱 기능을 위해 사용하는 In-memory 데이터 저장소이다.우리는 자주 사용되는 데이터를 캐싱하여, 이후 발생하는 요청 시에 데이터베이스에 직접 접근하지 않고 데이터를 제공할 수 있다.Redis 같은 외부 라이브러리가 아닌 스프링 프로젝트 내부에서 헤더를 이용하여 캐싱을 하는 방법도 있다.이에 Cache-Control Header에 대해 알아보자.1. Cache-Control Header개요설명하기에 앞서 클라이언트-서버의 요청 플로우에 대해 알아보자.클라이언트는 서버와 HTTP를 통해 통신을 하여 데이터를 가져오고, 이를 사용자에게 제공한다. 이때 클라이언트는 네트워크를 거치는 시간, 서버는 요청을 처리하는데 시간이 걸린다.만일 클라이언트가 요청한 데이터가..

이번에는 드디어 1회차 프로젝트를 마무리 짓는 글이다!많은 이슈가 있었고, 팀원간에 문제를 해결하는 과정들이 있었지만 어찌저찌 잘 마무리한 것 같다.그럼 각설하고 1회차 프로젝트에 대한 마무리를 진행해보겠다. 이전 포스트에서는 docker-compose를 통해 컨테이너를 실행시켜 msa 환경이 잘 실행되는지 확인하고 테스트해보았다.다른 문제는 없었지만 계정을 로그아웃하고 재접속을 시도하였을 때 이전에 생성하였던 데이터 변경 사항이 적용이 되지 않아 아무 데이터도 저장되지 않았던 오류가 있었다.그래서 다양한 원인을 유추해 보았다. 추측1. ajax 호출위의 사진들은 Login 시 클라이언트 측에서 발생하는 진행상황이다.login을 진행하면 OAuth2 토큰을 받아와 유저 정보를 가져온다.이때 정보를 가져오..

지난 시간에는 서비스 코드를 리팩터링하여 가독성이 좋고, SOLID 원칙에 근거하도록 코드를 재구성해 보았다.이번에는 개선된 코드를 도커를 통해 컨테이너 실행하고 잘 되는지 테스트해 보겠다. 사실 많은 시간이 걸렸다. 팀원들 모두 MSA 환경을 처음 접해보았기 때문에 서비스 간의 통신과 라우팅을 직접 접해보고 이해하는 시간이 필요했기 때문이다..! 순서는 각 모듈에 대한 도커 컴포즈 파일의 구성, 그리고 이를 실행했을 때의 결과를 차례대로 보이도록 하겠다! Docker-compose.ymlversion: '3.8'networks: msa-network: driver: bridgeservices: rabbitmq: image: rabbitmq:3-management container_n..

AWS SES(Simple Email Service)말 그대로 간단히 이메일을 보내는 서비스이다.SMTP 인터페이스나 AWS SDK로 사람들에게 메일을 보낸다.메일을 받기 위해서는 S3나 SNS, Lambda와 통합할 수 있다.Amazon OpenSearch Service해당 서비스는 Amazon ElasticSearch의 후속작이라고 생각하면 된다.DynamoDB에서는 PK나 인덱스를 통해서만 데이터를 쿼리할 수 있었다.하지만 OpenSearch 사용 시 일부만 매칭이 되어도 모든 필드를 검색할 수 있다.OpenSearch는 두 가지 모드로 클러스터를 프로비저닝할 수 있다.Managed Cluster물리적 인스턴스가 프로비저닝Serverless Cluster서버리스 상태로 프로비저닝Cognito나 IA..

지난 번에는 Maven에서 Gradle로 프로젝트를 변경하는 과정을 진행해보았다.이번에는 내가 맡은 account-service 모듈을 리팩터링하는 과정을 살펴보겠다. piggymetrics 레거시 코드들의 특징은 다음과 같다.전체적으로 Lombok을 사용하지 않아 코드로 직접 구현하는 귀찮은 과정을 진행하였고, 오류 발생 시 클라이언트에게 반환하는 Exception도 제대로 구현되어 있지 않는 등 수정할 부분들이 많아 보였다.(오히려 좋아)하나씩 뜯어 고쳐보겠다.AccountControllerController 클래스의 코드 리팩터링 부분은 다음과 같다.1. 패키지별 API의 분리2. 원시 Mapping 사용이들을 수정하면 다음과 같아진다.@RequiredArgsConstructor@RestContro..

암호화전송 중 암호화는 TLS 또는 SSL이라고 부른다.(TSL는 SSL의 가장 최근 버전)데이터 전송 전에 암호화가 되고 받은 후에 해독되는 원리로 작용한다.이는 네트워크와 서버의 소통을 위해 사용된다.TLS 인증서가 암호화를 지원한다.전송 중 암호화를 하는 이유?데이터를 전송할 때 공공 네트워크를 사용하는 경우도 있고, 데이터가 여러 다른 서버를 통해 지나가기 때문에 중간자 공격을 방어할 필요가 있기 때문이다."중간자 공격"은 중간의 서버가 데이터를 받고 서버로 전송 중인 패키지를 관찰해버리는 것을 말한다.이러한 이유로 우리는 HTTPS나 TLS, SSL을 원한다!TLS를 이용한 데이터 전송암호화와 해독을 위한 키는 어딘가에서 관리가 일어나고, 서버가 이 키에 대한 접근을 할 수 있어야 함을 나타낸다..

지난 시간에는 스프링 데이터 JPA와 Querydsl의 기능을 비교하고,사용자 정의 리포지토리를 만들어 Querydsl을 상속받는 인터페이스를 구현보았다.이번에는 마지막 강의 정리로 복잡한 실무 환경에는 알맞지 않지만 스프링 데이터에서 제공하는 기능들을 살펴보겠다.인터페이스 지원 - QuerydslPredicateExecutorQuerydslPredicateExecutor는 인터페이스는 스프링 데이터 JPA에 Querydsl을 사용하기 위해 제공되는 기능이다.이를 사용하기 위해서는 사용하고 있는 인터페이스에 상속하면 된다!MemberRepository.javapublic interface MemberRepository extends JpaRepository, MemberRepositoryCustom, Q..

구름x카카오 부트캠프 프로젝트를 진행하던 도중, 의존성 주입을 하고 실행 테스트를 해보는 과정에서 난데 없는 오류가 발생하여 삽질을 하였기에 이를 기록해보겠다. 다음은 account-service 모듈 실행 오류이다.📌 Trouble"Failed to determine a suitable driver class"라는 말과 함께 오류가 발생하였다.내용을 보면 알겠지만 import하는 데이터베이스의 url을 표시하라는 문구이다.하지만 나는 mongoDB를 사용하기 때문에 이에 관한 설정은 해놓은 상태이다. 그럼에도 오류가 발생하는 이유가 뭘까?하나씩 살펴보도록 하자.먼저 account-service에 대한 설정은 다음과 같다.build.gradleapplication.yml위의 application.yml..