꼼개의 개발자취

변경감지와 병합(merge) 병합은 대부분이 알고있는 엔티티 매니저의 merge 메서드이다. 여기서 변경감지(dirty checking)은 JPA의 특징 중 하나이며 entity의 값만 바꿔주면 알아서 변경감지(dirty checking)를 하여 update 쿼리문을 날린다. 준영속 엔티티 영속성 컨텍스트가 더는 관리하지 않는 엔티티 문제는 준영속 엔티티인 경우 JPA가 관리하지 않음으로 어떻게 update을 할 지 애매한 경우이다. 그 때는 2가지 방법을 이용할 수 있다. 변경 감지 기능 사용 병합(merge) 사용 변경 감지 기능 사용 @Transactional public void update(Long id, Entity entity) { // entity를 가져온다. Entity entity = ..

백엔드 개발자로서 지낸 첫 해가 지나갔다. 이번년도는 유난히, 부족함을 느낌과 동시에 성장했다고도 느껴졌다. 물론 쉽지 않은 길이였다. 학부 때 부터 내 커리어에 전부는 임베디드와 인공지능이였다. 그러다, SSAFY를 하게 되었고, 운 좋게 초록창 회사 인턴을 하게 되었지만, 부족함을 느끼고, '역시 나는 제조업 SW로 가야겠어' 라는 다짐을 하였다. 이후, 어렵지 않게 제조업 SW로 취업하게 되었지만, 고민은 계속 있었다. 큰 기업의 제조업 SW는 개발보다는 관리직에 가깝고, 무엇보다 개발자로서의 로망을 이루기에 환경이 따라주지 않았다. 자고로 내가 꿈꾸던 개발자는 카페나, 관광지에서 노트북 하나 들고, 업무를 하는 자유로운 직업이였지만, 현실은 보안 때문에 회사 밖으로 노트북하나 들고 나가기도 어렵다..

save와 saveAll의 차이는 아래 링크을 참고하면 된다. https://code-killer.tistory.com/152

수정 송신이 필요없는 데이터의 송신은 UDP가 효율적이다. TCP가 복잡한 원리를 사용할 이유는 데이터를 확실하면서도 효율적으로 전달하기 위함이다. 데이터를 확실히 전달하려면 도착한 것을 확인하고, 도착하지 않았으면 다시 보내야한다. 위 내용을 가장 간단히 실현할 수 있는 방법은 그냥 데이터를 ‘전부’ 보낸 후에 수신측에서 수신 확인 응답을 받는 것이다. 이는 TCP 처럼 복잡한 과정을 생략하는 것이다. 그러나, 패킷이 한개만 없어져도 전체를 다시 보내야 함으로 비효율적인데, 용도에 맞게 TCP와 UDP를 사용하면 된다. 제어용 짧은 데이터 예를들어 DNS 서버에 대한 조회는 한개의 패킷으로 끝나기 때문에 UDP를 사용한다. UDP 동작방식도 간단하다. 애플리케이션에서 송신 데이터를 받으면 UDP 헤더를..

1. 패킷의 기본 패킷은 헤더와 데이터로 구성되어 있고, 헤더에는 제어정보, 데이터에는 내용이 들어있다. 먼저 송신처가 되는 기기가 패킷을 만들면 패킷의 제어정보에 따라 가까운 중계 장치로 이동한다. 중계장치에 도착하면 중계 장치 안의 목적지 테이블을 활용하여 다른 가까운 중계 장치로 이동하는 방식이다. 최종적으로 수신처의 기기에 패킷이 도착하는 것이다. 이러한 중계기기들을 엔드노드 또는 중계노드라 한다. TCP/IP 패킷 구조는 더 발전한 형태로, 서브넷이 라우터와허브라는 두 종류의 패킷 중계 장치에서 다음과 같은 역할은 분담한다. 라우터가 목적지를 확인하여 다음 라우터를 나타낸다.(라우터는 IP 규칙에 따라 패킷 운반) IP가 목적지를 확인하여 다음 IP의 중계장치를 나타낸다. 허브가 서브넷 안에서 ..

개요 현재 사내에서 사용하는 API 서버 중 HAProxy를 사용있는 서버가 있다. 구축 된 이후 인수인계 받은 서버라, 다 구현 되어 있지만 최근 인증서 교체를 위해 여러가지 알아보던 중 HAProxy에 대해 정확한 히스토리를 알 지 못하여, 이에 대해 리서치 후, 비슷한 역할을 수행하는 NGINX도 비교하여 정리한다. HAProxy Haproxy 는 L4, L7 과 같은 하드웨어 로드밸런서를 대체하기 위한 오픈소스 소프트에어로 이름처럼 Reverse Proxy 를 기반으로 로드밸런싱을 하기에 매우 강력하고 또 가벼운 어플리케이션이다. HA (High Availability) 라는 이름처럼 고가용성을 위하여 설계되었다. 로드밸런서에 대한 설명 : https://code-killer.tistory.com..

개요 원래는 HAproxy를 공부하여 포스팅하려 했는데, 공부하다보니, 로드밸런서 역할로의 비교대상인 Nginx가 있었다. 그래서 Nginx vs HAproxy로 포스팅하려고, Nginx를 공부하다 보니, Apache가 있었고, 내용이 재미있어서 따로 포스팅하려고 한다. HAproxy 포스팅하면서 Nginx와 비교까지 진행해봐야겠다 배경 Nginx 이전 Apache는 요청이 들어오면 connection을 생성하는데, 클라이언트 요청이 올 때 마다 새로운 프로세서 or 쓰레드를 생성한다. 그러나, 새로운 프로세서 or 쓰레드를 생성하는데 시간이 많이 걸리기 때문에 미리 만들어 놓는PreFork 방식을 이용한다. 근데 만약 1만명 이상의 접속자가 동시에 요청을 날린다면, 1만개의 프로세스나 쓰레드를 생성하여..