같이 일하고 싶은 개발자

문제 설명왜 나의 타임리프엔 접근할 수 없을까요?사용자의 요청이 들어오면 Load Balancer(로드 밸런서)에 의해 여러 대의 서버로 이동하게 됩니다.예를 들어 2개의 서버로 구성된 인프라 환경이 있다고 가정한 후 시나리오를 작성해보겠습니다.A서버의 로그인 요청 → A서버에서는 로그인 성공이라는 응답동일한 클라이언트는 로드 밸런서에 새로운 요청을 보냄새로운 요청은 B 서버로 전달B 서버에선 로그인 한 사용자의 정보가 없기에 어플리케이션에서 설정한 특정 페이지로 리다이렉트 하도록 응답을 보냅니다위의 시나리오처럼 접근이 됐다, 안됐다 하는 이유는 요청에 관한 클라이언트의 정보를 판단할 수 없기에 발생하는 문제라는 것으로 접근했고 해당 가설을 검증하기 위해 아래와 같이 테스트를 진행했습니다.가설 검증 시나..

문제 상황가장 먼저 식별한 문제인 thymeleaf에 접근이 되지 않는 현상캐시를 지웠다가 할 땐, 간헐적으로 화면이 보이긴 하나 css가 적용되지 않거나 계속해서 페이지가 리다이렉되서 많은 요청이 발생하는 문제 식별, 어디에선 됐다 어디에선 안됐다 와 같은 문제 반복해서 발생고민 및 해결을 위한 시도고민 1) 앞서 해결 방법으로 강구한 인증서 문제 → 인증서 정상고민 2) nginx 문제 혹은 도메인 문제 → x고민 3) 로드밸런스 문제 → x고민 4) 서버 상태 문제 → actuator api 정상 호출고민 5) 어플리케이션 설정 확인 → 문제 식별 (또 다른 문제 -해당 문제 해결 후 로그인이 정상적으로 되지 않는 이슈)고민 6) 운영 도메인, nginx, load balancer와 같은 문제에 포..

문제 상황 :k8s에 의해 N개의 파드, previw 서버, 레플리카, 오토 스케일링 등등의 운영 환경 배포 상황에서 관리자 모듈을 빌드 및 오케스트레이션 하는 과정에서 커넥션이 다수 발생해서 설정된 DB 커넥션의 한계치를 넘어버리는 상황추가 설명 : (멀티 모듈의 상위 모듈은 하위 모듈이 가지고 있는 의존성들의 커넥션의 총 합을 갖게 됨..)어플리케이션의 actuator가 헬스체크도 제대로 못할 뿐더러 rds에서 생성한 db 의 max_connection의 임계치까지 도달해버려 로컬에서 DB 접속이 불가해지고, 물론 파드에 문제가 발생하는 현상 식별멀티 모듈 형태의 아키텍처를 가지고 있는 어플리케이션에서 **관리자 모듈(**Admin)을 운영 환경에 배포해야하는 상황에서 발생한 문제고민한 내용 그리고 ..

과거에 해당 부분에 대해서 팀 내 논의가 있어 해당 내용을 간략하게 정리하고 공유하고자 합니다. 팀 내 진행되는 프로젝트에선 API 컨벤션 및 협업과 관련된 컨벤션 논의가 활발하게 이뤄지지 않은 상태였습니다.그렇기 때문에 과거 정리해둔 글을 기반으로 회고하고 생각을 나누기 위해 글을 정리했습니다. 해당 아래의 내용은 과거의 내용입니다  당시 팀 내 진행되는 프로젝트에선 객체 조회 시 객체가 존재하지 않으면 정의된 예외를 발생하고 예외 핸들러를 통해 HttpStatus를 404로 전달하고 있었습니다. 주로 200Status 는 성공을 의미하는, 400번대는 잘못된 요처에 관한 내용을 담고 있기에 HttpStatus에 관한 나름의? 규칙을 준수하고 있다고 생각하고 있었습니다. 그러나 오늘 문득 코드를 작성하..

이전 과거의 글 에서 레디스와 캐시에 대해 간략하게 정리했습니다. 현업에 오니 직접적으로 레디스를 사용하거나 혹은 캐싱 기능을 사용할 정도의 경험을 갖는것이 어렵다는 생각이 들었습니다.그러한 이유는 성능에 이슈가 생겼을 때 1순위로 캐싱을 사용하기엔 비용이 크다는 생각이 듭니다. 대부분의 성능적인 이슈는 SQL 튜닝을 통해서 해결이 가능하고 비용적인 측면에서 가장 저렴하다는 생각이 들었습니다.(SQL 튜닝 을 통해서 성능적인 이슈를 해결하기도 하고 캐싱 서버 활용, 샤딩, DB 스케일 업과 같은 하드웨어 성능을 업그레이드 하는 부분도 방법이 될 수 있고, 레플리케이션 등등 여러 방법이 있습니다) 그중에서 SQL 튜닝의 다음 단계인 레디스(Redis)를 통해 캐싱을 사용해보고 실제 성능이 얼마나 개선이 되..