1. JPG - Joint Photographic Experts Group(JPEG) JPG와 JPEG에 대해서 간단히 설명하겠다. JPG와 JPEG의 관계를 알기 위해서는 지금은 거의 사용되지 않은 도스(DOS)를 조금 살펴보아야 한다. 도스는 윈도우가 보편화되기 전에 주로 사용되던 프로그램으로 일종의 운영체제이다. 도스에서는 파일명을 최대 8자, 확장자를 최대 3자까지 밖에 사용할 수 없어 기존의 4자리로 된 JPEG를 줄여 JPG로 사용한 게 시초가 되었다. 하지만, 윈도우 macOS 등 다양한 운영체제가 개발되면서 파일명과 확장자를 포함하여 최대 255자까지 사용할 수 있게 되면서, JPEG를 굳이 JPG로 표기할 필요가 없게 되었다.

메시지 큐(Message Queue)는 프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법 중에 하나로, 메시지 지향 미들웨어(Message Oriented Middleware:MOM)를 구현한 시스템을 의미한다. 메시지 지향 미들웨어란 비동기 메시지를 사용하는 응용 프로그램들 사이에서 데이터를 송수신하는 것을 의미한다. 여기서 메시지란 요청, 응답, 오류 메시지 혹은 단순한 정보 등의 작은 데이터가 될 수 있다. 메시지 큐는 메시지를 임시로 저장하는 간단한 버퍼라고 생각하면 된다. 메시지를 전송 및 수신하기 위해 중간에 메시지 큐를 두는 것이다.

해싱 해싱은 산술적인 연산을 이용하여 키가 있는 위치를 계산하여 찾아가는 검색 방식이다. 키값을 원소 위치로 변환하는 함수를 해시 함수(Hash Function)라 한다. 해시 함수에 의해 계산된 주소에 저장할 값을 저장한 표를 해시 테이블(Hash Table)이라 한다. 해시 테이블은 빠른 검색 속도를 제공하는데 이유는 내부적으로 버킷(배열)을 사용하여 데이터를 저장하기 때문이다. 해시 테이블은 각각의 key 값에 해시 함수를 적용해 배열의 고유한 인덱스를 생성한 후 인덱스를 이용해 값을 저장한다. 실제 값이 저장되는 장소를 버킷이라 한다.

로드 밸런싱이란 서버가 처리해야 할 업무 혹은 요청(Load)을 여러 대의 서버로 나누어(Balancing) 처리하는 것을 의미한다. 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 하는 것이 목적이다. 서비스의 규모가 커지고, 이용자 수가 늘어나게 되면 기존의 서버만으로는 원활한 서비스 동작이 불가능하게 되고, 이에 대처할 수 있는 방법은 크게 두 가지로 나뉜다. 기존의 서버 성능을 확장하는 Scale-up 방식 기존의 서버와 동일하거나 낮은 성능의 서버를 증설하는 Scale-out 방식 이때 Scale-out 방식을 통해 증가한 트래픽에 대처하기로 했다면, 여러 대의 서버로 트래픽을 균등하게 분산해주는 로드 밸런싱이 반드시 필요하다.

비관적 락 비관적 락은 대부분의 경우 트랜젝션에서 충돌이 발생할 것이라 가정하고, 일단 락을 걸고 보는 기법이다. 락을 걸게 되면 다른 트랜잭션에서는 락이 해제되기 전에 데이터를 가져갈 수 없다. 비관적 락은 데이터베이스의 락 알고리즘을 통해 구현되며, 데이터를 수정하는 즉시 트랜잭션 충돌을 감지한다. JPA에서 비관적 락 구현 1 2 3 4 5 6 public interface HomeRepository extends JpaRepository<Home, Long> { @Lock(LockModeType.PESSIMISTIC_WRITE) @Query("select h from Home h where h.name = :name") Home findWithNameForUpdate(@Param("name") String name); } 1 2 3 4 5 6 7 8 9 10 11 12 13 @Service @RequiredArgsConstructor @Slf4j public class HomeService { private final HomeRepository homeRepository; @Transactional public int decreasePrice(String name, int price) { Home home = homeRepository.

TCP Keep-Alive 두 종단 간의 연결을 유지하는 것이 목적이다. 연결된 TCP 소켓을 체크할 수 있고 TCP 연결이 여전히 진행중인지 혹은 끊어졌는지를 결정한다. TCP Keepalive는 연결된 세션의 재활용 측면에서만 아니라 좀비 커넥션의 삭제에도 도움을 준다. TCP 연결을 끊으려면 FIN 패킷이 필요하다. 하지만 다양한 이유로 FIN 패킷을 받을 수 없는 상황이 된다면 FIN을 전달할 수 없어 계속 연결된 것처럼 남아있게 된다. TCP Keepalive 옵션을 사용한다면 일정시간이 확인 패킷을 보내는 로직을 통해 일정시간 동안 응답이 없다면 연결을 종료하기 때문에 좀비 커넥션을 방지할 수 있다.