꼼개의 개발자취

1. 클라이언트와 서버의 차이점 접속동작을 할때 클라는 보내는쪽이고, 서버는 기다리는 쪽이라, Socket 라이브러리의 활용법이 달라진다. 또한, 서버는 동시에 다수의 클라이언트 PC와 통신한다는 차이도 있다. 그러므로 서버와 클라이언트는 구조가 다르다. 2. 서버 애플리케이션의 구조 서버는 여러 클라이언트와 통신해야 함으로 대화의 진행이 어디까지인지 알아야한다. 그래서 클라가 새로 접속할 때 마다 새로 서버 프로그램을 작동하여 서버 애플리케이션이 클라와 1대 1로 대화하는 방법을 선택하는 것이 일반적이다. 서버 OS는 멀티태스크, 멀티스레드 라는 기능에 의해 다수의 프로그램을 동시에 함께 작동할 수 있는데 이를 활용하여 접속을 기다리는 부분과 클라이언트가 대화하는 부분을 나눈다. 만약 접속을 접수하면 ..

개요 회사에서 Spring boot + JPA + mysql 조합을 사용하는 프로젝트가 있는데, PK 중복 문제로 update 시 문제가 발생하였다. 추적 결과 기존 코드는 멀티스레딩 환경에서 조건적으로 동시성 이슈로 생기는 문제였다. 비관적 락, 낙관적 락을 사용하여 해당 이슈를 해결해보기로 한다. 비관적 락 이름 그대로 트랜잭션끼리 충돌을 발생한다고 가정(비관적 락)하여 우선 락을 거는 방법이다. DB의 Lock 기능을 이용한다. (쿼리에 Select for update 구문이 들어감) Lock을 획득할 때까지 트랜잭션은 대기하므로, Timeout 설정 가능 낙관적 락 이름 그대로 트랜잭션 끼리 충돌나지 않는다고 가정하고(낙관적 락)하여 커밋 시 충돌을 알 수 있다. DB Lock 기능을 이용하지 않..

변경감지와 병합(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만개의 프로세스나 쓰레드를 생성하여..

스프링 빈 스프링 빈은 이름, 타입, 객체로 구성 @Configuration + @Bean 프레임워크를 설정할 때 애플리케이션을 설정할 때 애플리케이션 전체에서 공통으로 사용할 때 @ConponentScan + Stereotype Annotation 비즈니스 로직을 처리할 때 예시로 들어가기전 file tree KaKao & Member는 NotificationService를 상속받고 있다. Spring Bean 주입 - @Bean + @Configuration : 01 메서드의 파라미터 전달 @Configuration public class JavaConfig { @Bean public MemberRepository memberRepository() { return new MemberRepository..