민스씨의 일취일장

F-Lab Java Backend 과정 5개월 후기 글이다.F-Lab Java Backend 과정 멘토링 5개월 후기에프랩 멘토링을 한 달 연장하였고, 5개월을 끝으로 5개월의 멘토링을 마무리하였다.공채 시즌4개월차와 5개월차는 공채 시즌으로 다양한 기업에 원서를 쓰고 코딩테스트를 준비하면서 보냈다.자기소개서프로젝트를 계획적으로 진행하기 어려운 가장 큰 이유가 자기소개서였다. 프로젝트도 시간이 얼마나 걸릴지 완벽히 계획하기 어려운데, 자기소개서는 더 예측하기 어려웠다. 과거의 나의 이야기를 쓰는 것일 뿐인데 참 작성이 안된다. 하지만 그렇다고 시스템에 의지해 투두리스트를 채우듯 하기엔 글쓰기가 그정도로 능숙하진 못하다. 결론적으로 정말 많은 시간을 자기소개서를 작성하는 시간으로 보냈다. 스스로를 돌아보는..

F-Lab Java Backend 과정 4개월 후기 글이다.F-Lab Java Backend 과정 멘토링 4개월 후기원래 처음 계획된 F-Lab에서의 4개월이 끝났다.네 달 동안 진행 내용공부 주제매 달 후기글에 작성하는 커리큘럼 내용이다.1주차 : 객체지향 프로그래밍 / 객체지향 4가지 속성/ 자바 컴파일 과정2주차 : JVM 메모리 구조 / 자바 GC / Thread Safty와 동기화 / static, final3주차 : Exception, Generic, Collection, Synchronized Collection, Concurrent Collection, HashMap4주차 : JSP, Servlet, MVC Pattern, Cookie, Session, HTTP Method, HTTP St..

F-Lab Java Backend 과정 17주차~18주차 후기글입니다.F-Lab Java Backend 과자어 17주차 ~ 18주차17주차 ~ 18주차 멘토링 주제라이브 코딩1. 동시성 컨트롤이론1. Database View2. url 요청 보낸 후 일어나는 일들3. RDBMS vs. NoSQL4. LRU/LFU/FIFO 캐시 알고리즘프로젝트라이브 코딩17주차에는 16주차에 이어서 동시성 컨트롤에 대한 라이브 코딩을 진행했다. 동시성 컨트롤이라는 걸 한다면 직관적으로 아주 간단하게 synchronized를 적용하는 것을 생각했었다. 하지만 여기까지만 해서는 단순히 동시성 컨트롤을 했지만, 잘했다 소리는 듣지 못한다. 왜냐하면 synchronized는 해당 로직에 접근하는 모든 경우에 lock을 걸기 때문..

Java Backend 과정 16주차 후기글입니다.F-Lab Java Backend 과정 16주차16주차 멘토링 주제라이브 코딩이론1. 객체 직렬화(Serialization)와 역직렬화(Deserialization)2. Java Thread 생명주기멘토링이 일단 막바지(연장 연부가 결정이 안돼서)이고 요즘 한창 취업 원서 접수하고 있어 취업 관련 주제에 집중하고 있다. 하지만 프로젝트는 여전히 조용히 계속 진행중에 있다!라이브 코딩혹시 발생할 수 있는 라이브 코딩을 대비하기 위해 이번 멘토링 시간엔 짧은 원서 접수 이야기를 나눈 뒤 라이브 코딩에 집중했다. 지난 라이브 코딩은 알고리즘에 포커스를 맞췄다면, 이번에는 실무관점에서 구현에 포커스를 맞춰 진행했다. 빈 클래스 2개에 내용을 넣어가는 방식으로 진..

PaymentService에 적용된 Redis Cache를 분산 캐시(distributed cache)로 전환하는 과정(GitHub Issues #28)에 대한 글이다.Redis를 클러스터로 만들어 분산캐시 도입하기작업 순서 계획1. redis.conf 작성 및 적용2. 새로운 Redis용 인스턴스 생성3. Redis 노드(컨테이너)들을 클러스터 구성(생성) 명령 수행4. Redis 분산 캐시를 사용할 수 있도록 애플리케이션 설정 수정1. redis.conf 작성 및 적용nginx.conf와 마찬가지로, redis.conf를 작성해준다. 이 파일은 Redis 컨테이너 실행시 Volume으로 연결 해 줄 것이다. 경로는 어디다 해도 상관 없지만 민스씨 본인은 redis/redis.conf 경로로 할 것이다..

Redis 캐시 도입 후 선능 변화를 테스트(Gtihub Isssues #26)한 결과입니다.Redis 캐시 도입 후 성능 변화 테스트 시나리오1부터 100번까지의 paymentId를 랜덤으로 100명의 가상 사용자가 1분동안 요청을 보낸다.테스트 1캐시를 사용하지 않은 테스트이다.가상 사용자 99명이 1분동안 캐시 적용되지 않는 서비스에 무작위 요청을 보내는 테스트에 대한 결과이다. TPS(초당 처리량)은 평균 518이며 총 1분간 총 처리량은 20861이다.테스트2캐시를 사용하는 테스트이다.가상 사용자 99명이 1분동안 캐시가 적용된 서비스에 무작위 요청을 보내는 테스트에 대한 결과이다. TPS(초당 처리량)은 평균 679.2이며 총 1분간 총 처리량은 28673이다.테스트 분석TPS 31% 향상 (..