이번주는 AWS Load Balancer를 이용해서 응답속도와 TPS를 개선하려고 했다. Application Load Balancer (Application Layer OSI 7 계층에서 5, 6, 7 계층)을 사용했다. 이것에 대해서는 블로그 자료도 많고 정보처리기사에서도 중요하게 다루어지는 개념인 것 같다. https://jjinhyeok.tistory.com/86 AWS 로드밸런서 적용 Redis 캐시를 적용하고 많은 개선점이 있었다. 하지만 아직 1000TPS라는 목표는 아직 도달하지 못했다. 이번주는 1000TPS 넘기는 것을 목표로 진행을 하려고한다. 밑에 있는 링크와 표는 지난주에 테 jjinhyeok.tistory.com 로드밸런서를 적용하고 나온 결과이다. test인원 항목 비관적 락 ..
https://jjinhyeok.tistory.com/74 프로젝트 Redis 캐시 적용하기 지난번에 Redis를 설치하고 테스트를 해보았다. 이제 실전 프로젝트에 적용을 해보겠다. 현재 프로젝트 html 보면 JSON으로 데이터를 주고 받고 하고 있기 때문에 JSON을 써야한다. 그래서 Redis 설정 jjinhyeok.tistory.com 이번주는 Redis캐시를 확실하게 적용했고 @Cacheable 캐시를 장애상황일때 대응을 못해서 개선을 했습니다. @Bean public RedisConnectionFactory redisConnectionFactory() { LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()..
지난 주 토요일에 멘토링을 받고 지금 내가 진행을 잘하고 있는가에 대해서 의문이 생겼다. 우리가 진행을 잘하고 있는지, 무엇을 해야하는지, 가이드를 얻고 싶은데 테스트는 지금 할때가 아니다, 인프라 할때가 아니다, 스프링과 자바를 해라, 등등 해야 할것들이 아니고 하지 말아야 할것에 대한 조언을 얻었다. 나는 여기서 프로젝트 완성을 위해서 어떤 것을 해야 하는지 고민이 깊어졌다. https://jjinhyeok.tistory.com/76 Tomcat Thread Pool 지난주 부터 코드에 개선점이 있을 때 마다 Jmeter로 부하 테스트를 했었다. 10000명의 가상사용자가 예매하기를 동시 했을때 8000석만 예매되고 남은 2000석은 예매 되지 않고 오류를 일으켰다. org.ap jjinhyeok.t..
실전 프로젝트를 시작하고 한주가 지났다. 현재 나는 서비스 프로젝트가 아닌 챌린지라는 이름을 달고 서버의 성능을 개선하고 대용량 트래픽을 해결하는 목표로 진행하고있다. 챌린지는 서비스팀과 다르게 프론트엔드가 없다. 백엔드가 HTML구조만들기, CSS UI 꾸미기 모든것을 해야한다. 실전프로젝트를 시작하고 나는 프론트를 맡아서 시작했다. 지금까지 스프링을 쭉 배워온 입장에서 HTML, CSS을 하려니까 모르는게 너무 많아서 고통스러운 코딩이 시작되었다. 이제 까지 프론트분들이 알아서 UI를 해줬는데 내가 해야해... CSS를 만지면서 프론트를 1명만 있었으면 좋겠다고 생각했고 실전 프로젝트 팀장으로써 어떻게 성능개선을 해야해?? 그래 먼저 성능 테스트를 해보자 https://jjinhyeok.tistory..
이번 클론 코딩에서 가장 관심이 갔던 것은 복잡한 쿼리문이다. 클론코딩 전까지 데이터베이스에서 가지고는 데이터의 조건이 많지 않아서 JPA로 쉽게 가지고 올 수 있었다. package com.example.seoulcultureport.repository; import com.example.seoulcultureport.entity.CommentLike; import org.springframework.data.jpa.repository.JpaRepository; import java.util.Optional; public interface CommentLikeRepository extends JpaRepository { Optional findByUseridAndBoardidAndCommentid(Lo..
지난 주차에서는 주특기 학습이 끝나고 처음으로 협업을 진행했다. 프로젝트를 시작할때 API명세서를 작성하는데 Backend와 Frontend가 요청하는 데이터가 다르다. 같이 의논하고 짜다보니 서로 의견차이가 있고 코드를 작성할때 소문자 대문자 작은차이로 오류생기는 부분이 자주 발생했다. 해결법 1. 목적과 범위를 명확히 설정해야한다. API 명세서에서는 API의 목적과 범위를 명확히 정의해야 합니다. 즉 API가 무엇을 하는지 이해하고 사용 방법을 파악할 수 있도록 이해해야합니다. 2. 요청 및 응답 데이터의 형식을 명확하게 작성한다. API 명세서에서는 요청 및 응답 데이터의 형식을 명확하게 정의해야 합니다. - Request 요청은 백엔트가 요청하는 데이터이기 때문에 백엔드가 작성해서 프론트와 협의..
- Total
- Today
- Yesterday
- 오토 스케일링
- script
- 로드 밸런서
- Auto Scaling
- githubactions
- 인스턴스
- CodeDeploy
- JWT
- 로드밸런서
- aws
- HTML
- java
- EC2
- 시작 템플릿
- 위치의 중요성
- Load Balancer
- CICD
- flask
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |