같이 일하고 싶은 개발자

문제 설명왜 나의 타임리프엔 접근할 수 없을까요?사용자의 요청이 들어오면 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)를 통해 캐싱을 사용해보고 실제 성능이 얼마나 개선이 되..

지금의 회사에 합류한 지 만으로 1년 10개월이 넘어가고 있습니다.벌써 2년이라는 시간을 향해 달려가고 있다고 생각이 들면서 또 한편으로 아직 2년도 안 지났어?라는 생각이 드는 시점인 것 같습니다. 입사하게 된 23년의 한 해보다 24년의 한 해가 무척이나 심적으로 힘들었지만 한편으로는 또 많은 것을 알게 되고 정말 스스로를 되돌아보는 그런 한 해였지 않나?라는 생각이 들었고 많은 것을 배운 그런 한 해였기에 24년도 한 해를 생각을 정리하고 기록하며 털어버리기 위해 회고록을 작성해 봤습니다. 24년 키워드  배움, 스트레스, 개인과 조직 그리고 성장, 같이 일하고 싶은 개발자 그리고 동료 1. 배움 1-1. 갈증23년엔 같이 입사한 동기 중 한 명을 제외하고 같은 팀에 배정이 되었습니다.  같은 직무..

이번에 정리한 내용은 팀 문화 중 하나인 지식 공유 시간에 Redis에 대해 간략하게 발표한 자료입니다.  [서론]레디스(Redis)를 설명하기에 앞서 캐시(Cache)에 대해서 먼저 간단하게 설명하고자 합니다.범용성 있게 일반적으로 3 tier Architecture의 구조 채택ClientServerDataBase이러한 계층형 구조를 Layerd Architecture(레이어드 아키텍쳐 / 계층형 아키텍쳐 ) 라고 칭함 그러나!!! 윗 구조에서는 명확한 한계점이 존재!바로 서비스가 폭발적으로 성장해 사용자가 많아지고, 실시간으로 요청하는 API 수가 많아짐에 따라 서비스의 부하가 상승하는 경우우리는 아키텍쳐를 분리하거나 캐싱이라는 기능을 사용해 서비스 어플리케이션에서 발생하는 성능의 문제를 해결할 수 ..

결론 선 공개개인과 팀의 성장의 영양분으로 애자일이라는 방식을 채택했다면 애자일적 사고 방식이 중요하다.애자일을 애자일 다운 방식으로 도입하는 것은 중요하다.본론가을의 냄새가 물씬 풍겨오는 어느 오후였습니다, 팀 동료와 합법적인 월급 루팡??을 하다가 이직과 관련된 이야기가 나왔습니다. 티타임이라 쓰고 합법적인 월급 루팡이라 읽는 현장을 다 같이 보시죠 본인 : 만약에 다음에 이직을 하게 된다면 어떤 도메인으로 가고 싶으신가요?팀 동료 : 가고 싶은 도메인이 특정해 있진 않은데 피하고 싶은 도메인은 있습니다본인 : 혹시 이런 상상 해보신 적 있으신가요? 만약 지금의 회사의 제휴사으로 이직하는 상상...팀 동료 : 해본적 있습니다... 재잘재잘.... 본인 : 우리 회사에 내가 제휴사로 미팅라하려고 온다?..

취업 후 쉴 새 없이 달려오다보니 어느덧 2년차 백엔드 개발자가 되어 있었습니다.그동안 많은 일들도 있었고 다양한 영역의 지식과 도메인의 지식을 흡수하면서 나름대로 이제 어떤 문제가 발생해도 잘 해결할 수있으리라 생각했습니다.   그러나 개발이라는 거대한 야생에서는 얕은 지식만으로 해결되지 않는 문제들이 정말정말정말 많습니다. 한번은 어플리케이션 영역을 넘어선 인프라적 문제가 발생했던 경험이 있습니다. 당연히 인프라적 인사이트는 저에게 개방되지 않은 미지의 동굴과 같았기에 어떻게 해결할 수있는지에 관한 문제 해결 능력과 경험치가 부족했고 잘 모르는 영역이다보니 생각을 확장하기가 어려웠습니다. 어떻게 하면 조금 쉽고 편하게 지식을 습득하고 내가 가진 궁금증들에 관한 생각들을 확장할 수 있을까?에 관한 답변..

사내 팀 내 개발 문화를 도입하면서 공유한 내용입니다.  간단하게 어떤 개발문화를 도입했는지에 설명하자면 다음과 같습니다. - 팀원들 개인의 경험 공유 및 지식 나눔으로 매주 목요일 번갈아가며 진행- 발표자는 자유 주제로 팀원들과 소통- 무거운 주제도 괜찮지만 되도록 가벼운 주제로- 다른 개발의 영역이라도 자유롭게 참가 가능- 주 목적은 같이 성장하기 이미 여러 다른 회사들에서는 이러한 개발문화를 도입했을겁니다.이는 팀 내의 역량을 증진하고 더 나아가 발표를 하기 위해, 발표를 듣기 위해 자신의 지식을 점검하며 같이 성장하기에 주 목적이 있습니다   간단한 설명은 이쯤에서 끝내고 발표 준비한 내용을 공유도록 하겠습니다. 목차N+1 문제의 흔한 착각여러분은 Page와 Slice를 아시나요?DirtyChec..