IP의 특징: unreliable, connectless

IP 패킷은 신뢰성이 없고 연결을 수립하는 과정이 없다. ⇒ 호스트 간의 연결이 이루어지지 않고 패킷이 수신됐다는 것을 보장할 수 없다.

왜? 그럴까? 빠른 전송 속도가 중요하다. 패킷 한 두 개 쯤 손실이 발생해도 큰 지장이 없다.

전송 계층에서 IP 한계 보완

• TCP
  • 연결형 통신 TCP의 경우 송수신할 두 호스트가 연결을 수립한다.
  • 신뢰성 있는 통신 오류, 흐름, 혼잡 제어 등으로 패킷이 올바른 순서대로 전달되는 것을 보장한다.
• UDP
  • TCP가 항상 좋은 것은 아니다. 빠른 전송이 필요한 경우 사용할 수 있다.
  • 비연결형 통신
  • 신뢰할 수 없는 통신

포트(port)

패킷은 실행 중인 특정 프로세스까지 전달되어야 한다. 한 호스트 내에서 각 프로세스를 구분할 수 있는 정보가 바로 포트이다.

포트 번호는 16bit로 표현 ⇒ 2¹⁶개 존재 ⇒ 0 - 65536

e.g.)

• 22번: ssh
• 80번: http
• 443번: https
• 3306: MySQL 데이터베이스

NAT과 NAPT

IP 주소를 변환하는 기술이다. LAN에서 사용되는 사설 IP ↔ WAN에서 사용되는 공인 IP 비교적 적은 공인 IP, 비교적 다수의 사설 IP ⇒ 모든 IP 주소를 일대일 매칭하는 것은 불가능

포트를 기반으로한 NAPT(Network Address Port Translation)이 해결 방안이 될 수 있다. 같은 공인 IP 주소를 서로 다른 사설 IP 주소로 식별하기 위해 NAT 테이블에 포트를 함께 기술하여 사용한다.

TCP

TCP 세그먼트 구조

TCP 연결 수립 및 종료

TCP는 three-way handshake로 연결을 수립하고 four-way handshake 과정으로 연결을 종료한다.

위의 과정에서 TCP 상태만 살펴보면 아래 이미지와 같다.

오류 제어: 재전송 기법

TCP는 아래 두 가지 상황에서 오류가 발생했다고 판단하고 세그먼트를 재전송한다.

• 중복된 ACK 수신
  • 클라이언트 측에서 송신 호스트가 보낸 특정 세그먼트를 받지 못한 경우, 다음 세그먼트를 전달해달라는 세그먼트를 여러 번 받게 된다.
• 타임아웃
  • TCP 세그먼트를 송신하는 호스트는 재전송 타이머 값을 유지한다.
  • 이 타이머의 카운트다운이 끝날 떄까지 ACK 세그먼트가 오지 않으면(RTT를 넘길 경우) 타임아웃이 발생하고 세그먼트를 재전송한다.

흐름 제어: 슬라이딩 윈도우

호스트가 한 번에 받아서 처리할 수 있는 세그먼트의 양에는 한계가 있다. 따라서 송신 호스트가 수신 호스트의 처리 속도를 고려하며 송수신 속도를 균일하게 유지해야한다. 이때 슬라이딩 윈도우 알고리즘을 활용한다.

혼잡 제어

혼잡(congestion)이란, 트래픽이 많아 세그먼트가 유실되거나 처리속도가 늦어지는 현상을 말한다. 혼잡 윈도우란, 혼잡 없이 전송할 수 있는 데이터의 양을 말한다. 따라서 혼잡 윈도우를 적절히 설정하는 것이 중요하다.

혼잡 제어를 위한 가장 기본적인 알고리즘은 AIMD(Additive Increase/MultiplicativeDecrease)이다. 말 그대로 혼잡 감지 X ⇒ 혼잡 윈도우를 RTT마다 1 증가 / 혼잡 감지 ⇒ 혼잡 윈도우 반감

조금 더 정교한 알고리즘으로 아래 세 가지가 있다.

• 느린 시작

  • 혼잡 윈도우를 1부터 시작해, 문제 없이 수신된 ACK 세그먼트 1개당 1씩 증가

  • 혼잡 감지 시

    상황 분류	해결 방법
    타임 아웃	혼잡 윈도우 = 1 느린 시작 임계치를 이전의 절반으로 초기화 느린시작 재개
    혼잡 윈도우 >= 느린 시작 임계	느린 시작 종료, 혼잡 회피
    3번의 중복 ACK 세그먼트	빠른 재전송 후 빠른 회복

• 혼잡 회피

  • RTT마다 혼잡 윈도우를 1MSS만큼 증가

• 빠른 회복

  • 세 번의 중복 ACK 세그먼트를 수신했을 때 느린 시작은 건너뛰고 혼잡 회피를 수행

숙제

필수 숙제

1. Ch.04-1 확인 문제 1번
   • 비신뢰성
   • 비연결형
2. Ch 04-2 확인 문제 2번
   • ACK

<참고 자료>

• TCP 세그먼트 구조: http://www.ktword.co.kr/test/view/view.php?m_temp1=1889
• TCP 연결 수립: https://haloworld.tistory.com/15
• TCP 연결 수립 및 종료: https://www.crocus.co.kr/1362
• TCP 상태 전이도: http://www.ktword.co.kr/test/view/view.php?no=657
• TCP 흐름제어(슬라이딩 윈도우): https://steady-coding.tistory.com/507
• 혼잡 윈도우 변화에 따른 그래프: https://blog.skby.net/tcp-%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4/

데이터 링크 계층의 한계

• 다른 네트워크까지의 도달 경로를 알기 어렵다.

  • 라우팅(routing): 패킷이 이동할 최적의 장비를 결정하는 것
  • 물리 계층, 데이터 링크 계층의 장비로는 라욷팅을 수행할 수 없다.

• MAC 주소로 호스트를 트겅하기 어렵다.

  MAC 주소	IP 주소
  물리 주소	논리 주소
  NIC마다 할당(고정 주소)	DHCP or 사용자가 직접 할당

인터넷 프로토콜 (IP, Internet Protocol)

네트워크 계층의 프로토콜로 IPv4와 IPv6만 있다. 다만 아래에서는 IPv4만 정리할 예정이다.

기능

• IP 주소 지정 (addressing): IP 주소를 바탕으로 송수신 대상 지정
• IP 단편화 (fragmentation): MTU(Maximum Transmission Unit) 보다 패킷 크기가 크면 여러 개의 패킷으로 나누어 전송

IPv4

• 4byte로 표현

  • e.g.) 192.168.1.1

• 패킷 구조

  영어	한국어	역할
  Identifier	식별자	패킷에 할당된 번호 패킷이 여러 조각으로 나누어져 전송된 경우 어떤 메시지에서부터 쪼개졌는지 인식하기 위한 용도
  Flags	플래그	순서대로 0 DF MF 비트로 구성된 필드 DF(Don't Fragment): 1이면 단편화 불가 / 0이면 단편화 가능 MF(More Fragment): 1이면 쪼개진 패킷이 더 있음 / 0이면 마지막 패킷
  Fragment offset	단편화 오프셋	초기 데이터에서 몇 번째로 떨어진 패킷인지를 나타내는 필드
  TTL(Time to Live)	-	패킷이 하나의 라우터를 거칠 때마다 == 한 홉(hop)마다 1씩 감소 무의미한 패킷이 네트워크 상에 남아있는 것을 방지함
  Protocol	프로토콜	상위 계층의 프로토콜 e.g.) TCP는 6번, UDP는 17번

ARP (Address Resolution Protocol)

IP 주소를 통해 MAC 주소를 알아내는 프로토콜

처리 과정 호스트 A가 호스트 B의 MAC 주소를 알고싶어하는 상황

1. ARP 요청 (ARP request)
   • A가 브로드캐스트 메시지 전송
2. ARP 응담 (ARP reply)
   • B를 제외한 호스트는 응답 X
   • B만 유니캐스트 메시지 전송
3. ARP 테이블 갱신

만약 호스트 A와 B가 다른 네트워크에 있다면? ⇒ ARP 테이블에는 라우터의 MAC 주소가 저장된다.

IP 주소

네트워크 주소와 호스트 주소

클래스풀 주소 체계(classful addressing)

• A의 경우 호스트가 할당되지 않은 IP 주소가 낭비될 수 있다.
• C의 경우 호스트가 사용할 IP 주소가 부족해질 수 있다.

클래스리스 주소 체계(classless addressing)

클래스풀 주소 체계 보다 정교하게 표현하는 방법으로 8bit 단위로 네트워크/호스트 주소가 구분되지 않고 원하는 크기로 잘게 쪼개어 사용할 수 있다.

• 서브넷 마스크(subnet mask)로 서브네팅하기

  	10진수	bit
  IP 주소	192.168.219.103	11000000.10101000.11011011.01100111
  서브넷 마스크	255.255.255.0	11111111.11111111.11111111.00000000
  AND 연산의 결과 (네트워크 주소)	192.168.219.0	11000000.10101000.11011011.00000000

  • 8비트로 호스트를 표현할 수 있다.
  • 네트워크 주소: 192.168.219.0
  • 브로드캐스트 주소: 192.168.219.255
  • 호스트는 2⁸ - 2 = 254개

• CIDR 표기법
  • <IP 주소/서브넷 마스크 상의 1의 개수> 로 클래스리스 주소 체계를 표현할 수 있다.

공인 IP와 사설 IP

공인 IP

전 세계에서 고유한 IP 주소를 말한다.

사설 IP

LAN 내에서 사용하는 IP 주소를 말하며 라우터(router)가 할당한다. NAT(Network Address Translation)을 거쳐 공인 IP로 변경 ⇒ 외부 호스트와 통신한다. e.g.) 171.16.0.0/12, 168.192.0.0/16

정적 IP와 동적 IP

• 정적 할당
  • 호스트에 직접 부여한 IP
• 동적 할당
  • 사용자가 IP를 직접 입력하지 않아도 자동으로 IP를 할당하는 방식
  • DHCP(Dynamic Host Configuration Protocol)로 IP를 할당한다.

DHCP로 IP 할당하기

• DHCP 서버 (일반적으로 라우터 또는 특정 호스트)와 호스트 간에 메시지를 주고 받으며 동적으로 IP가 할당된다.
• IP 주소 임대 시간이 정해져 있다.
• 임대 기간이 끝나면 IP를 반납하고 재할당 받거나 갱신해야한다.

1. DHCP Discover (호스트 → DHCP 서버)
   • 브로드캐스트로 전송
   • 송신지 IP는 0.0.0.0
   • "나 DHCP 서버 찾고 있어!!"
2. DHCP Offer (DHCP 서버 → 호스트)
   • "IP 주소, 서브넷 마스크, 임대 기간 등을 제안할께!"
3. DHCP Request (호스트 → DHCP 서버)
   • 브로드캐스트로 전송
   • "Offer 잘 받았어. 이 IP 주소 써도 되는거지?"
4. DHCP ACK (DHCP 서버 → 호스트)
   • "승인 완료"

라우팅

라우팅이라 패킷이 이동할 최적의 경로를 설정하여 패킷을 이동시키는 과정을 말한다.

라우터와 라우팅 테이블

라우터는 네트워크 계층에서 사용하는 장비이다. 집에 있는 공유기가 라우터의 역할을 한다.

• 패킷이 하나의 라우터를 거치는 과정을 홉(hop)이라고 한다.

라우팅 테이블에선 아래와 같은 정보를 얻을 수 있다.

• 수신지 IP 주소와 서브넷마스크
• 다음 홉/게이트웨이: 다음으로 거쳐야 할 호스트의 IP 주소나 인터페이스
• 네트워크 인터페이스: 패킷을 보낼 통로
• 메트릭(metric): 해당 경로로 이동하는 데에 드는 비용

정적 라우팅과 동적 라우팅

정적 라우팅은 사용자가 직접 라우팅 테이블을 채워 넣어 라우팅되는 방식을 말한다.

동적 라우팅은 자동으로 라우팅 테이블을 만들고 활용하는 방식이다. AS 내부에서 수행되는 지 여부에 따라 라우팅 프로토콜이 나뉜다.

라우팅 프로토콜

AS 내부에서 수행되면 IGP, 외부에서 수행되면 EGP라고 한다.

AS(Autonomous System)란? 하나의 관리 도메인 안에 있는 라우터의 집합을 AS라고 한다.

IGP(Interior Gateway Protocol)

• RIP(Routing Information Protocol)
  • 거리 벡터 기반
  • 홉 수가 가장 적은 경로를 최적의 경로라고 판단
  • 주기적으로 라우팅 테이블 갱신
• OSPF(Open Shortest Path First)
  • 링크 상태 기반
  • 현재 네트워크의 상태를 그래프의 형태로 최적의 경로 판단
  • 대역폭을 기반으로 메트릭 계산
  • AS 내 정보가 바뀔 때마다 정보 변경이 이루어진다.

EGP(Exterior Gateway Protocol)

• BGP(Border Gateway Protocol)
  • 피어링을 통해 다른 AS의 BGP 라우터와 피어 상태를 유지

숙제

필수 숙제

1. Ch.03-1 확인 문제 1번 ② IP 주소 지정 ③ IP 단편화
2. Ch.03-3 확인 문제 2번 라우팅 프로토콜은 AS 내부에서 수행되는 IGP와 AS 외부에서 수행되는 EGP로 나뉩니다. RIP는 대표적인 거리 벡터 라우팅 프로토콜이고, OSPF는 대표적인 링크 상태 라우팅 프로토콜입니다.

<참고 자료>

• IP 패킷 구조 이미지: https://blog.siner.io/2021/12/13/network-ipv4-packet/
• 클래스풀 주소 체계: http://www.ktword.co.kr/test/view/view.php?no=2461
• 라우터와 라우팅 테이블: https://geek-university.com/routing-table-explained/
• AS: http://www.ktword.co.kr/

• 이더넷
• MAC 주소
• NIC
• 허브 / 스위치
• 반이중(half duplex) / 전이중(full duplex)

이더넷(Ethernet)

이더넷이란 다양한 통신 매체의 규격들과 송수신되는 프레임 형태, 프레임을 주고받는 방법 등이 정의된 네트워크 기술이다.

이더넷 표준에 맞추어 통신 => 서로 다른 네트워크 장비 통신

이더넷 프레임

• 프리앰블 + SFD 프리앰블은 10101010, SFD는 10101011 프리앰블이 오는 동안 1과 0이 계속 반복되며 이더넷 프레임이 오고있음을 알 수 있다.
• DA(Destination Address), SA(Source Address) MAC 주소
• Data 최소 46byte / 최대 1500byte 46byte보다 작은 경우 Padding(뒤에 붙은 0)을 넣음
• FCS(Frame Check Sequence 수납된 데이터의 에러검출을 위한 CRC(Cydle Redundancy Check)

NIC

NIC(Network Interface Controller)는 MAC 주소가 부여되는 네트워크 장비이다.

역할

• 통신 매체를 통해 전달되는 신호 ↔ 컴퓨터가 이해할 수 있는 정보
• 수신된 프레임의 MAC 주소가 자신의 것이 아니라면 폐기
• FCS 필드를 토대로 오류 검출

허브

대표적인 물리계층의 장비이다.

특징

• 물리 계층에는 주소 개념이 없다. => 전달 받은 신호를 그대로 내보낸다. 송수신된 내용을 조작이나 판단하지 않는다.
• 반이중 모드로 통신한다. => 동시에 송수신이 불가능하다. 한 허브에 여러 호스트 장비가 연결 -> 여러 호스트 장비에서 허브에 송신 -> 허브에 여러 신호가 동시에 도착 -> 충돌(collision) 발생!! => 한 허브에 연결된 여러 호스트가 같은 collision domain에 속한다고 한다.

CSMA/CD

허브가 반이중 모드로 통신해서 충돌이 발생할 수 있다.

충돌 문제를 해결하기 위해 CSMA/CD 라는 프로토콜을 사용한다.

• CA (Carruer Sense) : 캐리어 감지 호스트는 메시지를 보내기 전에 현재 네트워크 상에 전송 중인 것이 있는 지 확인한다.
• MA (Multiple Access) : 다중 접근 여러 호스트가 네트워크에 접근하려는 상황에서
• CD (Collision Detection) : 충돌 검출 충돌이 발생하면 호스트에게 충돌이 발생했음을 알리고 호스트는 임의의 시간만큼 대기한 뒤 다시 전송한다.

스위치

데이터 링크 계층에서는 MAC 주소라는 주소체계를 사용한다. 물리 계층과 다르게 전이중 모델을 사용한다.

MAC주소 학습

스위치가 연결된 포트의 주소를 학습하는 방법은 다음과 같은 과정을 통해 일어난다.

• 플러딩
• 포워딩과 필터링
• 에이징

1. A -> C로 프레임을 전송하는 상황이다. 최초의 스위치는 아무 주소도 알지 못한다.

   포트	주소
   A
   B
   C
   D

2. A -> 스위치: A의 MAC주소를 MAC 주소 테이블에 기록한다.

   포트	주소
   A	ab:cd:ab:cd:00:01
   B
   C
   D

3. 플러딩(flooding): A를 제외한 모든 포트에 프레임을 전송한다.

4. C가 A의 메시지에 응답한다.

   포트	주소
   A	ab:cd:ab:cd:00:01
   B
   C	ab:cd:ab:cd:00:03
   D

5. A -> C에 프레임을 다시 한 번 보낸다.

   • 필터링(filtering): B, D로는 프레임이 전송되지 않는다.
   • 포워딩(fowarding): C에 프레임을 전송한다.

6. 에이징(aging): 특정 포트가 일정 시간동안 메시지를 받지 못했다면 MAC 주소 테이블에서 제거된다.

숙제

필수 숙제

1. Ch.02-1 확인 문제 2번 ㉠ 프리앰블 ㉡ 송신지 MAC 주소 ㉢ FCS
2. Ch.02-3확인 문제 4번 ① CS (Carrier Sense) -> 캐리어 감지 ② MA (Multiple Access) -> 다중 접근 ③ CD (Collision Detection) -> 충돌 검출

<참고 자료>

• 참고문헌: '데이터통신', 오창환 저, 한국학술정보(주)

네트워크 기초

용어 정리

• 호스트(Host)
  • 가장자리 노드
  • 최초로 정보를 생성, 송신 + 최종적으로 수신
  • e.g) 서버 컴퓨터, 데스크톱 등

네트워크 분류

1. 범위에 따른 분류

   • LAN(Local Area Network)

     • 근거리 통신망
     • e.g) 회사 내부망

   • WAN(Wide Area Network)

     • 광역 통신망

2. 메시지 교환 방식에 따른 분류

   • 회선 교환 방식
     • 두 호스트를 연결하여 해당 경로로 통신
     • 단점) 회선 효율 낮음 - 연결되지 않은 회선은 낭비
       • 패킷 교환 방식
     • 메시지를 패킷 단위로 쪼개어 전송
     • 장점) 회선을 점유하지 않아 네트워크 효율 높음
     • 네트워크 장비) 라우터, 스위치

OSI 7계층과 TCP/IP 4계층

용어 정리

• Protocol
  • 노드 간에 정보를 올바르게 주고받기 위해 합의된 규칙이나 방법
  • e.g) IP, ARP, HTTP, TCP 등

네트워크 모델

OSI 모델

• physical layer(물리 계층)
  • 비트 신호 전달
• data link layer(데이터 링크 계층)
  • MAC 주소 사용
  • 물리 계층을 통해 주고 받는 정보 확인
• network layer(네트워크 계층)
  • 다른 네트워크에 속한 수신지까지 전달
  • 최적의 경로 설정
• transport layer(전송 계층)
  • 패킷 흐름 제어 및 전송 오류 점검
  • 신뢰성 있고 안정성 있는 정보를 전달할 때 필요
• session layer(세션 계층)
  • 연결 상태 생성 유지 및 종료 시에 연결 종료
• presentation layer(표현 계층)
  • 문자 -> 코드, 압축, 암호화 등
• application layer(응용 계층)
  • 실제 사용자가 이해할 수 있는 형태의 응용 프로그램
  • e.g) 웹 페이지 제공, 이메일 서비스

TCP/IP 모델

• network access layer(네트워크 엑세스 계층)
  • physical layer + data link layer 와 유사
• internet layer(인터넷 계층)
  • network layer와 유사
• transport layer(전송 계층)
• application layer(응용 계층)
  • session layer + presentation layer + application layer

캡슐화와 역캡슐화

• 캡슐화(incapsulation)
  • 송신과정에서 헤더 및 트레일러를 추가해나가는 과정
  • 응용 계층 -> 물리 계층 방향으로 데이터 추가
• 역캡슐화(decapsulation)
  • 수신과정에서 헤더 및 트레일러 확인 후 제거
  • 물리 계층 -> 응용 계층 방향으로 데이터 제거

PDU(Protocol Data Unit)

• 각 계층에서 송수신 되는 메시지 단위

네트워크 성능 지표

• 처리율(throughput)
  • 단위 시간당 네트워크를 통해 실제로 전송되는 정보량
  • bps, Mbps
• 대역폭(bandwidth)
  • 단위 시간 동안 송수신할 수 있는 최대 정보량
• 패킷 손실(packet loss)

숙제

추가 숙제

1. CH01-1 확인 문제 2번 여러 장치가 연결되어 정보를 주고받을 수 있는 통신망을 (컴퓨터 네트워크)라고 합니다.
2. CH01-3 확인 문제 2번 2번, TCP/IP 모델은 4개의 계층으로 통신 과정을 구분합니다. network access, internet, transport, application이 있다.

🎤 대표적인 라이브러리

1. Lettuce
   • setnx (set if not exist) 명령어를 활용하여 분산락 구현
     • key와 value를 set할 때, 기존의 값이 없을 때만 set을 진행
   • spin lock 방식
     • lock을 획득하려는 thread가 lock을 사용할 수 있는지 반복적으로 확인하면서 lock 획득

2. Redisson
   • pub-sub 기반의 lock
     • 채널을 하나 만들고 락을 점유 중인 thread가 락을 해제할 때, 해당 lock을 획득하려고 대기 중인 thread에게 해제를 알려줌
     • lettuce와 다르게 락 획득 로직을 개발자가 작성할 필요 없음

🥬 Lettuce

Redis에서 setnx를 통해 키를 획득하는 방식이다.

적용 과정

1. Redis dependency 추가 implementation 'org.springframework.boot:spring-boot-starter-data-redis'

2. Redis 명령어를 활용하기 위한 redis repository 생성

   public Boolean lock(Long key) {
     return redisTemplate
             .opsForValue()
             .setIfAbsent(generateKey(key), "lock", Duration.ofMillis(3_000));
   }
   
   public Boolean unlock(Long key) {
     return redisTemplate
             .delete(generateKey(key));
   }
   
   private String generateKey(Long key) {
     return key.toString();
   }

3. lock의 획득과 해제를 위한 facade 정의

    public void decrease(Long id, Long quantity) throws InterruptedException {
      while (!redisLockRepository.lock(id)) {
        Thread.sleep(100);
      }
   
      try {
          stockService.decreaseStock(id, quantity);
      } finally {
          redisLockRepository.unlock(id);
      }
   }

장·단점

장점

• 구현이 단순하다.
• spring data redis를 이용하면 lettuce가 기본이므로 별도의 라이브러리를 사용할 필요가 없다.
• 단점*
• spin lock 방식이므로 redis에 부하를 줄 수 있다. ⇒ Thread.sleep()을 통해 락 획득 재시도에 텀을 주어야하므로

🚀 Redisson

Redis가 채널을 통해 통신하고 있는 것이다. Redisson은 자신이 점유하고 있는 락을 해제할 때 채널에 메세지를 보내줌으로써 다른 thread에게 락을 획득하라고 전달한다.

적용 과정

1. Redisson dependency 추가 implementation 'org.redisson:redisson-spring-boot-starter:3.25.2' 해당 의존성에서 lock과 관련된 라이브러리를 제공해주므로 별도의 repository를 작성할 필요가 없다.

2. lock 획득과 해제를 위한 facade 정의

   RLock lock = redissonClient.getLock(id.toString());
   
   try {
     boolean available = lock.tryLock(10, 1, TimeUnit.SECONDS);
   
     if (!available) {
         System.out.println("lock 획득 실패");
         return;
     }
     stockService.decreaseStock(id, quantity);
   } catch (InterruptedException e) {
     throw new RuntimeException(e);
   } finally {
     lock.unlock();
   }

장·단점

장점

• 라이브러리에서 락 획득 재시로를 기본으로 제공한다.
• pub-sub 기반으로 redis의 부하를 줄여준다.

단점

• 구현이 복잡하다.
• 별도의 라이브러리 활용 필요하다.

⚖️ 실무에서의 활용 방안

Lettuce vs. Redisson

실무에서는 재시도의 필요성에 따라 혼용하여 사용한다.

재시도가 필요하지 않은 락 ⇒ lettuce 재시도가 필요한 경우 ⇒ redisson

MySQL vs. Redis

MySQL

• 이미 MySQL을 사용하고 있다면 별도의 비용이 필요없다.
• 어느 정도의 트래픽까지는 문제없이 활용이 가능하다.

Redis

• 활용중인 Redis가 없다면 별도의 구축비용과 인프라 관리 비용이 발생한다.
• MySQL보다 성능이 좋다.

🔒 다양한 lock의 종류

1. Pessimistic lock (비관적 락)

   • 실제로 데이터에 Lock을 걸어 정합성을 맞추는 방법이다.
   • Exclusive lock(베타적 잠금)이 걸리면 다른 트랜잭션에서는 lock이 해제되기 전까지 데이터를 가져갈 수 없다.
   • 다만, 데드락이 걸리는 상황에 주의해서 사용해야한다.

   ⇒ 자원을 요청하면 동시성 문제가 발생할 것을 예상하고 lock을 걸어버리는 비관적 락이다.

2. Optimistic lock (낙관적 락)

   • 버전을 통해 정합성을 맞추는 방법이다.
   • 데이터를 읽은 후에 update 를 수행할 때 현재 내가 읽은 버전이 맞는지 확인하며 업데이트를 한다.
   • 읽은 버전에서 수정사항이 생겼을 경우에는 application에서 다시 읽은 후에 작업을 수행해야 한다.

   ⇒ 자원에 락을 걸어 선점하기보단, 동시성 문제가 발생했을 때 감지하고 처리하는 낙관적 락이다.

3. Named lock

   • 이름을 가진 metadata locking이다.
   • 이름을 가진 lock을 획득한 후 해제할 때까지 다른 세션은 이 lock을 획득할 수 없다.
   • transaction이 종료될 때 lock이 자동으로 해지되지 않아 별도의 명령어로 해제하거나 선점 시간이 끝나야 해제된다.

😒 Pessimistic lock 활용

적용 과정

Spring data jpa를 활용하면 @Lock을 통해 손쉽게 pessimistice lock을 구현할 수 있다.

public interface StockRepository extends JpaRepository<Stock, Long> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select s from Stock s where s.id = :id")
    Stock findByIdWithPessimisticLock(Long id);
}

결과 확인

Test가 성공적으로 실행되며, 실행 중 for update라는 부분이 lock을 걸고 데이터를 가져오는 부분이다.

장·단점

장점

• 충돌이 빈번한 경우 롤백의 횟수를 줄일 수 있고, Optimistic lock보다 성능이 좋을 수 있다.
• lock을 통해 업데이터를 제어하므로 데이터의 정합성이 보장된다.

단점

• 별도로 lock을 걸어야 하므로 성능 감소가 있을 수 있다.
• 서로의 자원이 필요한 경우, 데드락이 발생할 수 있다.

🌞 Optimistic lock 활용

적용 과정

1. Optimistic lock을 활용하기 위해 Stock Entity에 version이라는 attribute을 추가한다.

   @Version
   private Long version;

2. Spring Data JPA에서 제공하는 @Lock을 통해 Optimistic lock을 구현한다.

   @Lock(LockModeType.OPTIMISTIC)
   @Query("select s from Stock s where s.id = :id")
   Stock findByIdWithOptimisticLock(Long id);

3. Optimistic lock은 실패했을 때 재시도 과정이 필요하므로 facade를 만들어 그곳에서 service layer의 함수를 호출한다.

   @Component
   public class OptimisticLockFacade {
   
     private final OptimisticLockStockService optimisticLockStockService;
     public OptimisticLockFacade(OptimisticLockStockService optimisticLockStockService) {
         this.optimisticLockStockService = optimisticLockStockService;
     }
   
     public void decrease(Long id, Long quantity) throws InterruptedException {
         while (true) {
             try {
                 optimisticLockStockService.decrease(id, quantity);
   
                 break;
             } catch (Exception e) {
                 Thread.sleep(50);
             }
         }
      }
   }

장·단점

장점

• 충돌이 적게 발생할 때, 별도의 lock을 잡지 않으므로 pessimistic lock보다 성능이 좋다.

단점

• update에 실패했을 때의 재시도 로직을 개발자가 직접 작성해야 한다.

⚖️ Pessimistic lock vs. Optimistic lock

따라서 충돌의 발생 빈도에 따라 lock을 다르게 사용하는 것을 추천한다.

• 충돌이 빈번한 경우 ⇒ Pessimistic lock
• 충돌이 적은 경우 ⇒ Optimistic lock

🙋🏻 Named lock 활용

Named Lock은 이름을 가진 metadata lock으로 이름을 가진 lock을 획득한 후 해제할 때까지 다른 세션은 이 락을 획득할 수 없다.

트랜잭션이 종료될 때 lock이 자동으로 해제되지 않기 때문에 다음과 같은 상황에서 lock을 해제할 수 있다.

• 별도의 명령어 사용
• 선점 시간이 종료

MySQL에서의 Named lock 사용 명령어는 다음과 같다.

• lock 획득: get-lock
• lock 해제: release-lock

강의 예제 vs. 실무

강의에서는 편의를 위해 JPA의 Native Query를 사용하고 동일한 data source를 사용한다.

실제로 사용할 때에는 data source를 분리하는 것을 추천한다. 같은 데이터 소스를 사용하면 connection pool이 부족해져 다른 서비스에도 영향을 줄 수 있다.

적용 과정

1. lock을 획득하고 종료하는 LockRepository를 정의한다.

   public interface LockRepository extends JpaRepository<Stock, Long> {
     @Query(value = "select get_lock(:key, 3000)", nativeQuery = true)
     void getLock(String key);
   
     @Query(value = "select release_lock(:key)", nativeQuery = true)
     void releaseLock(String key);
   }

2. StockService 로직을 활용하여 락을 획득하고 해제할 facade를 정의한다.

   try {
     lockRepository.getLock(id.toString());
     stockService.decreaseStock(id, quantity);
   } finally {
     lockRepository.releaseLock(id.toString());
   }

3. StockService의 재고 감소 로직은 facade의 transaction과 별도로 실행되어야 하므로 propagation을 변경한다.

   // 부모(NamedLockStockFacade)의 transaction과 별도로 실행되어야 하므로 propagation 변경
   @Transactional(propagation = Propagation.REQUIRES_NEW) 
   public void decreaseStock(Long id, Long quantity) {
     // Stock 조회
     Stock stock = stockRepository.findById(id).orElseThrow();
     stock.decrease(quantity);
     stockRepository.saveAndFlush(stock);
   }

4. 예제에서는 같은 data source를 활용하여 두 로직(재고 감소 & lock의 획득 및 해제)을 실행하므로 connection pool의 사이즈를 증가시킨다.

   // application.yml 파일
   spring: 
   datasource:
     hikari:
       maximum-pool-size: 40

   실무에서의 활용 방안과 장·단점

   Named lock은 주로 Distributed lock을 구현할 때에 사용된다.

장점

• 타임아웃을 구현하기 어려운 Pessimistic lock과 달리 Named lock을 타임아웃을 구현하기 쉽다.

단점

• 트랜잭션 종료 시에 락 해제, 세션 관리에 주의해야하기에 구현이 복잡할 수 있다.

👯‍♂️ 활용 예제

method 선언부에 syncrhonized 키워드를 붙이면 해당 메소드에 하나의 thread만 접근할 수 있도록 제한한다.

public class StockService {
    ...

    // @Transactional
    public synchronized void decreaseStock(Long id, Long quantity) {
        Stock stock = stockRepository.findById(id).orElseThrow();
        stock.decrease(quantity);
        stockRepository.saveAndFlush(stock);
    }
}

🚫 @Transactional 사용에 주의하자

해당 함수에 @Transactional을 붙이게 되면 annotation의 동작 방식 때문에 의도한 대로 동작하지 않는다.

Spring에서는 @Transactional이 붙은 메소드를 실행할 때 해당 클래스를 매핑한 클래스를 생성하여 실행한다.

이 때 트랜잭션 시작 ⭢ method 실행 ⭢ 트랜잭션 종료 순서로 진행 되는데, 트랜잭션이 종료될 때 상태가 데이터베이스에 업데이트된다. method 실행은 완료되었지만 데이터베이스에 업데이트되지 않은 상황에서 다른 스레드가 해당 메서드에 접근할 때 동기화 문제가 다시 발생할 수 있다.

❓ synchronized 사용 시 문제점

하나의 키워드를 통해 간단히 구현할 수 있다는 장점이 있지만, Java의 synchronized는 하나의 프로세스 안에서만 보장된다.

따라서 여러 대의 서버에서 동시에 접근할 때는 보장하지 못하므로 실제 운용 서비스에서는 잘 사용하지 않는 방법이다.

인프런의 재고시스템으로 알아보는 동시성이슈 해결방법강의를 듣고 정리한 글입니다. 강의를 들으며 내용과 코드는 github에 정리해두었습니다.

기본 로직

재고 시스템에서 재고량을 감소시키며 동시성 문제가 발생하는 상황을 가정한다.

• Stock 재고를 가진 객체
• StockRepository JPA 사용을 위한 JpaRepository 상속
• StockService 재고 감소 로직

📈 Stock

@Entity
public class Stock {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private Long productId;
    private Long quantity;

    public Stock() {
    }

    public Stock(Long productId, Long quantity) {
        this.productId = productId;
        this.quantity = quantity;
    }

    public Long getQuantity() {
        return quantity;
    }

    // 재고 감소
    public void decrease(Long quantity) {
        if(this.quantity - quantity < 0) {
            throw new RuntimeException("재고가 부족합니다.");
        }
        this.quantity -= quantity;
    }
}

📉 StockService

@Service
public class StockService {

    private final StockRepository stockRepository;

    public StockService(StockRepository stockRepository) {
        this.stockRepository = stockRepository;
    }

    // 재고 감소
    public void decreaseStock(Long id, Long quantity) {
        // Stock 조회
        Stock stock = stockRepository.findById(id).orElseThrow();
        stock.decrease(quantity);
        stockRepository.saveAndFlush(stock);
    }
}

동시성 문제 (Concurrency Issue)란,

하나의 데이터를 둘 이상의 thread나 session이 제어할 때 발생하는 문제로

하나의 세션이 데이터를 수정 중일때, 다른 데이터에서 수정 전의 데이터를 조회하여 로직을 처리하므로써 데이터의 정합서이 깨지는 문제를 말한다.

✍🏻 예제 코드

테스트에서 사용되는 라이브러리/클래스는

• ExecutorService 비동기로 실행하는 작업을 단순화하여 사용할 수 있도록 도와주는 Java API이다.
• CountDownLatch 다른 스레드가 수행하는 작업이 끝날 때까지 기다릴 수 있는 기능을 제공한다.

@SpringBootTest
public class StockServiceTest {

    @Autowired
    private StockService stockService;

    @Autowired
    private StockRepository stockRepository;

    @BeforeEach
    public void before() {
        stockRepository.saveAndFlush(new Stock(1L, 100L));
    }

    @AfterEach
    public void after() {
        stockRepository.deleteAll();
    }

    @Test
    public void 재고감소() {
        stockService.decreaseStock(1L, 1L);

        Stock stock = stockRepository.findById(1L).orElseThrow();

        assertEquals(99L, stock.getQuantity()); // 100개 - 1개 = 99개
    }

    @Test
    public void 동시에_100개_요청() throws InterruptedException {
        int threadCount = 100;
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; ++i) {
            executorService.submit( () -> {
                try {
                    stockService.decreaseStock(1L, 1L);
                } finally {
                    latch.countDown();
                }
            });
        }
        latch.await();

        Stock stock = stockRepository.findById(1L).orElseThrow();

        assertEquals(0L, stock.getQuantity());
    }

}

위 테스트 코드에서 재고감소()는 성공적으로 실행되지만 동시에_100개_요청()은 실패한다.

그 이유는 Race condition이 발생했기 때문이다. Race condition은 둘 이상의 thread가 공유 자원에 동시에 접근하여 변경하려고 할 때 발생하는 문제이다.

❓ 멀티스레드 환경에서 race condition 발생 이유

기대했던 순서는 Thread1 재고 확인 🠒 Thread1 재고 감소 🠒 Thread2 재고 확인 🠒 Thread2 재고 감소 🠒 ... 이지만

실제 실행 순서는 Thread1 재고 확인 🠒 Thread2 재고 확인 🠒 Thread1 재고 감소 🠒 Thread2 재고 감소 🠒 ... 이므로 문제가 발생한다.

🙌 race condition 해결하기

race condition 문제를 해결하기 위해 하나의 스레드 작업이 완료된 이후에 다른 스레드 작업을 하도록한다.

강의에서 소개하는 방법으로는 크게 3가지가 있다.

• Application level에서의 해결 방안
  • Java의 synchronized
• Database의 Lock 활용
  • Pessimistic lock(비관적 락)
  • Optimistic lock(낙관적 락)
  • Named lock
• Redis Distributed Lock 활용
  • Lettuce 라이브러리
  • Redisson 라이브러리

주제 선정 과정이 정말 힘들었다. 다양한 주제들이 나왔지만 통일되지 않았고, 컨설턴트님의 의견도 더해지니 주제 선정에 오랜 시간이 걸렸다. 그러다 누군가가 막 던진 아이디어인 실시간 코미디 플랫폼에 의견이 모이면서 프로젝트를 진행하게 되었다.

프로젝트의 주제도 중요하지만 주제 선정이 길어진 만큼 개발 기간이 짧아졌기에 되돌아보니 아쉬움이 남는다. 다음부터는 주어진 시간에 맞추어 주제 선정-설계-개발-산출물 도출 기간을 적절히 나누어야겠다.

✍🏻 학습 내용 기록

처음 진행하는 프로젝트이다 보니 다양한 코드를 읽고 프로젝트에 적용해 보기도 했고 많은 에러를 마주치기도 했다. 인프라 구축 과정, 배포 과정에서 마주한 문제, annotation 제작 방법 등 내가 학습한 내용들을 기록하고 보니 복습하기에 정말 좋았다.

또 문제가 발생했을 때, 내가 어떤 사고 과정을 거쳤고 어떤 코드를 작성해서 해당 문제가 발생했는지 명확하게 팀원에게 공유할 수 있어서 더 빠르게 문제의 원인을 찾고 해결할 수 있었다.

🗣️ 소통의 부재

소통을 명확하게 하지 않았던 것이 이번 프로젝트에서 가장 아쉬운 점이다. 각자 개발에만 몰두하다 보니 코드를 통합하는 일이 늦어졌다. 따라서 코드를 통합 과정에서 발생하는 문제, 에러에 대해 대화할 시간이 부족했고 시연 과정에서 화면이 공유되기도, 되지 않기도 하는 문제 발생했다.

앞으로의 프로젝트에서는 주기적으로 코드를 통합하여 발생하는 문제들에 대해 모니터링할 수 있도록 해야겠다.

🤔 문제 이해하기

• 로봇은 사방으로 이동할 수 있으며 각 방향을 이동할 확률이 주어진다.

• 로봇이 총 n번 이동한다.

• 이미 방문한 경로에 또 방문하는 경우를 단순하지 않은 경로, 그렇지 않은 경로를 단순한 경로라고 한다.

• 로봇이 단순한 경로로 이동할 확률을 구해라

• n ≤ 14

⭐ 알고리즘

• DFS
• 백트래킹

📖 스토리 라인

1. 30 x 30 크기의 공간이 있고, 해당 로봇은 15행 15열에서 출발한다.
2. dfs로 방문여부를 표시하며 진행한다.
   • 임의의 경로로 이동할 때 다음 방향을 선택할 확률은 지금까지 이동한 확률 * 다음 방향으로 이동할 확률이다.
   • 코드의 move() 호출 부분을 부분에 나와있다.
3. 방문한 곳에 다시 방문하다면 되돌아온다. (백트래킹)
4. 목표한 횟수만큼 이동했다면 단순한 경로이므로 해당 경로로 이동할 확률을 더한다.

💻 문제를 해결한 코드

import java.io.*;
import java.util.*;

public class Main {

    static int n;
    static double ans = 0;
    static double[] p = new double[4]; // E(동), W(서), S(남), N(북)쪽으로 이동할 확률
    static int[] dr = {0, 0, 1, -1};
    static int[] dc = {1, -1, 0, 0};

    static boolean[][] visited = new boolean[30][30];

    // 백트래킹으로 모든 경로를 이동해보며 단순한 경로인지 확인
    // move: 지금까지 움직인 횟수, cr: 현재 있는 행, cc: 현재 있는 열
    private static void move(int move, int cr, int cc, double per) {
        if (move == n) { // n번 만큼 이동한 경우
            ans += per;
            return;
        }

        for (int dir = 0; dir < 4; ++dir) {
            int nr = cr + dr[dir];
            int nc = cc + dc[dir];

            if (visited[nr][nc]) continue; // 이미 방문한 곳인 경우

            visited[nr][nc] = true;
            move(move + 1, nr, nc, per * p[dir]);
            visited[nr][nc] = false;
        }
    }

    // 변수 입력 받기
    private static void readData() throws Exception{
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        StringTokenizer st = new StringTokenizer(br.readLine(), " ");
        n = Integer.parseInt(st.nextToken());
        for (int i = 0; i < 4; ++i) {
            p[i] = Integer.parseInt(st.nextToken()) * 0.01;
        }

        br.close();
    }

    // 데이터 쓰기
    private static void writeData() throws Exception {
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
        StringBuilder sb = new StringBuilder();

        sb.append(ans).append("\n");

        bw.write(sb.toString());
        bw.flush();
        bw.close();
    }

    public static void main(String[] args) throws Exception {
        readData();
        visited[15][15] = true;
        move(0, 15, 15, 1);
        writeData();
    }
}

❗ 주의할 점

각 방향으로 이동할 확률을 나타내는 변수 (double[] p)를 입력받을 때 p[i] = Integer.parseInt(st.nextToken()) / 100; 을 썼더니 모든 확률이 0.0으로 저장됐다.

1. int / int 연산
2. double로 casting 되는데 1번 과정에서 0이라는 결과가 도출되기 때문이었다.

따라서 int * double로 연산하여 의도한 값이 저장되도록 변경하여 문제를 해결할 수 있었다.

카프카에 저장된 데이터를 hadoop에 적재하는 역할을 맡았는데, 그 과정을 정리해보고자 한다.

❓ 왜 Hadoop을 사용했나요?

hadoop은 성능이 좋은 컴퓨터 한 대가 아닌, 보통 성능의 컴퓨터를 여러 개 두어 분산환경에서 데이터를 처리한다.

사용자가 wearOS 기기를 착용하고 운동을 시작하면 심박수 데이터를 모아 저강도, 중강도, 고강도 운동을 각각 몇 분씩 진행하였는지 제공하였다.

이때 1초에 1개씩 심박수 데이터를 수집하게 되는데,

• 100명의 사용자가
• 60분씩만 운동했다고 가정해도 하루에만 36만개의 데이터가 발생한다.

이렇게 많은 양의 데이터를 처리하기 위해 hadoop을 적용하였다.

🏗️ 아키텍처

간단하게 정리하자면 아래 두 과정으로 나눌 수 있다.

1. 워치에서 소켓통신을 통해 데이터 kfaka에 저장
2. kafka에 저장된 테이터를 spark를 통해 hadoop에 적재

🛠️ 사용 기술

Kafka

카프카는

• low coupling 워치와 hadoop이 서로의 정보를 알지 못해도 데이터를 처리한다.
• 장애 복구성 서버에 장애가 생겨도 워치에서 발생한 데이터는 kafka에 버퍼링되어 hadoop에 적재된다는 점이 보장

되어 적용하였다.

kafka를 docker로 띄어보자

아래 docker-compose.yml파일은 kafka를 docker container로 띄우는 코드이다.

version: '2'
services:
  zookeeper:
    container_name: heartbeat_zookeeper
    image: wurstmeister/zookeeper
    ports:
      - "2181:2181"
    networks:
      - deploy
  kafka:
    container_name: heartbeat_kafka
    image: wurstmeister/kafka
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"
    environment:
      KAFKA_ADVERTISED_HOST_NAME: 127.0.0.1
      KAFKA_ADVERTISED_PORT: 9092
      KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://43.202.219.160:9092
      KAFKA_CREATE_TOPICS: "heartbeat-raw-topic:2:1"
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
            KAFKA_HEAP_OPTS: "-Xmx4G -Xms4G"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - deploy
networks:
  deploy:
    external: true

Kafka는 크게 Kafka와 Zookeeper로 구분할 수 있다.

• zookeeper 메시지 큐의 데이터를 관리한다.
• kafka 메시지를 TCP로 전송하기 위한 브로커를 제공한다.

Spark

kafka에 쌓여있는 데이터를 hadoop에 적재하기 위해 spark를 사용하였다. 빠른 시간 내에 구현해야했기에 레퍼런스가 많은 tool을 선택하였으며, spark의 경우 인메모리 방식의 연산으로 빠른 데이터 처리가 가능하다.

실행 명령어

• 스파크 버전 파악 spark-submit --version
• 스파크 실행 spark-submit --master spark://43.202.219.160:7077 --packages org.apache.spark:spark-sql-kafka-0-10_2.12:3.5.0 kafka_to_hadoop.py

첫번째 시도(binary타입으로 저장)

아래와 같은 코드를 실행했을 때에는 데이터가 binary 타입으로 저장되었다.

from pyspark.sql import SparkSession

# spark session 생성
sc = SparkSession.builder \
    .appName("gunapang") \
    .getOrCreate()
#sc.sparkContext.setLogLevel('ERROR')

# kafka 서버와 토픽 설정
kafka_params = {
    "kafka.bootstrap.servers": "http://43.202.219.160:9092",
    "subscribe": "heartbeat-raw-topic",
    "startingOffsets": "earliest"
}

# kafka에서 데이터를 읽어 DataFrame 생성
df = sc.readStream.format("kafka") \
    .options(**kafka_params) \
    .load()

# Hadoop에 쓰기 위한 경로 설정
path = "hdfs://43.202.219.160:9000/user/hadoop/heartbeat"
checkpointLocation = "/home/ubuntu/spark/checkpoint"

# DataFrame을 Hadoop에 쓰기
query = df.writeStream \
    .format("parquet") \
    .option("path", path) \
    .option("checkpointLocation", checkpointLocation) \
    .start()

query.awaitTermination()

두번째 시도(의도한 데이터 타입으로 변경)

첫번째 시도와 달리 데이터 프레임을 전처리하여 저장하였다.

from pyspark.sql import SparkSession, functions as F

# spark session 생성
sc = SparkSession.builder \
    .appName("gunapang") \
    .enableHiveSupport() \
    .getOrCreate()
#sc.sparkContext.setLogLevel('ERROR')

# kafka 서버와 토픽 설정
kafka_params = {
    "kafka.bootstrap.servers": "http://43.202.219.160:9092",
    "subscribe": "heartbeat-raw-topic",
    "startingOffsets": "earliest"
}

# kafka에서 데이터를 읽어 DataFrame 생성
df = sc.readStream.format("kafka") \
    .options(**kafka_params) \
    .load()

# Kafka에서 읽은 데이터를 적절한 스키마로 변환
df = df.selectExpr("CAST(value AS STRING) as json")
df = df.select(F.from_json(df.json, "playerId STRING, heartbeat DOUBLE, createdAt ARRAY<INT>").alias("data"))
df = df.select("data.*")
df = df.withColumn("createdAt", F.to_timestamp(
        F.concat(
           F.expr("createdAt[0]"), F.lit("-"),
           F.expr("createdAt[1]"), F.lit("-"),
           F.expr("createdAt[2]"), F.lit(" "),
           F.expr("createdAt[3]"), F.lit(":"),
           F.expr("createdAt[4]"), F.lit(":"),
           F.expr("createdAt[5]"), F.lit("."),
           F.expr("createdAt[6]")
    )
))

# Hadoop에 쓰기 위한 경로 설정
path = "hdfs://43.202.219.160:9000/user/hadoop/heartrate2"
checkpointLocation = "/home/ubuntu/spark/checkpoint4"

# DataFrame을 Hadoop에 쓰기
query = df.writeStream \
    .format("parquet") \
    .option("path", path) \
    .option("checkpointLocation", checkpointLocation) \
    .start()

query.awaitTermination()

<참고 블로그>

• https://waspro.tistory.com/645
• https://pythontoomuchinformation.tistory.com/428

싸피 공통 프로젝트를 진행하며 인프라 구축을 담당하였고, 그 과정에서 docker로 redis를 구동하였다.

서비스를 실제로 배포하기 전 환경 점검 해볼 겸 로그를 찍어보았는데.. 이럴수가.. 사용하지도 않은 redis에 뭔가 찍혀있다.

docker exec -it wcc_api_cache redis-cli keys *

docker logs wcc_api_cache

찾아보니 redis 해킹은 꽤 흔한 것 같다.

🔒 redis에 비밀번호를 꼭 설정하자

redis에 비밀번호를 설정하여 인증 없이는 해당 container에 접근하지 못하도록 막자.

docker-compose.yml에 비밀번호 option을 추가하는 방법은 아래와 같다.

version: "3.7"

services:

  cache:
    container_name: wcc_api_cache
    image: redis:alpine
    command: redis-server --requirepass ${password} --port 6379
    ports:
      - 6379:6379
    volumes:
      - /var/api_cache/:/data
    networks:
      - deploy

networks:
  deploy:
    external: true

🛸 port 번호를 변경하자

기본 포트인 6379가 아닌 다른 포트를 사용하는 것도 한 가지 방법이라고 하니 참고하자.

<참고 자료>

• 내 redis가 해킹당했다고? 심지어 local인데?
• Redis 해킹당한 이야기
• [redis] 도커 컴포즈로 레디스 컨테이너 만들기

언제인가부터 git에서 github에 push를 하면 잔디가 심어지지 않는 현상이 생겼다. 내가 commit을 해도 기록이 안 남으니까 조금 속상했다.

해결방법을 찾아보다가 git log에 format을 지정하는 방법을 알아냈다. 이것을 잘 활용한다면 commit log에서 필요한 정보만 가져와서 변화 내용을 파악하기 편리할 것 같다.

📝 git log의 다양한 option들

한 줄로 보기

git log --oneline

특정 시간에 생성된 커밋 확인

git log --since=2.weeks
git log --after="yesterday"
git log --after="2023-7-1" --before="2023-7-15"

format 지정

git log --pretty=format:"%h = %ar : %s"

사용할 수 있는 format 일부는 아래와 같다.

%H 커밋 해시
%h 짧은 길이 커밋 해시

%an 저자 이름
%ae 저자 메일

%ad 작성 시각
%ar 상대적 작성 시각

%s 요약

그래프로 브랜치 변화 파악

git log --graph

(개인 정보는 가려두었다)

모든 브랜치 흐름 파악

git log --all --graph --decorate --oneline

all 옵션을 사용하지 않으면 현재 브랜치와 관련한 로그를 보여준다. all 옵션을 통해 모든 브랜치의 흐름을 파악할 수 있다.

<참고자료>

• https://www.atlassian.com/git/tutorials/git-log

JPA와 관련하여 공부하다 보니 Entity class에 wrapper class를 사용한 것을 볼 수 있었다. 이전에는 항상 primitive class를 사용했기에 어색하게 느껴져서 조사해 보았다.

@Entity
public class Employee {
    @Id
    private Long empNo;
    private String name;
    private Integer age;
    private Character gender;
}

💡 Wrapper type과 Primitive type

Id

Hibenate 공식 문서를 살펴보면 Id에 non-primitivive type을 사용하는 것을 권장한다.

Primitive type의 경우 null값을 가질 수 없으며 기본 값이 0이다. 반면, Hibernate에서는 데이터가 존재하지 않을 때 null로 표현한다. 즉, 데이터가 없을 때 primitive type은 0으로, hibernate는 null로 표현한다는 것이다.

Wrapper type은 primitive type 객체를 다루기 위해 사용하는 클래스로 null이 될 수 있다. 따라서 Hibernate의 데이터 존재 여부를 제대로 파악하기 위해서 Id는 Wrapper class를 사용하는 것이 바람직하다.

그 외의 attibutes

Id가 아닌 값들에 대해선 어떻게 하는 것이 좋을까? 공식 문서에서 정확한 사용 방법에 대해서 알 수는 없었다.

내 생각에는 모든 속성에 Wrapper class를 사용하는 것이 작성하는 것이 코드 작성의 편리함과 가독성 측면에서 더 좋을 것 같다.

<참고자료>

• https://hyune-c.tistory.com/44
• https://velog.io/@chiyongs/JPA-Entity-Wrapper-class-or-Primitive-type

1. JPA(Java Persistent API)는 인터페이스이다.

ORM(Object-Relation Mapping)

JPA를 이해하기 전 ORM(Object-Relation Mapping)의 개념에 대해 이해할 필요가 있다.

간단히 정리하면 아래와 같은 특징이 있다.

• 객체와 RDB(Relational Database, 관계형 데이터베이스)의 데이터를 자동으로 매핑한다.
• 객체지향프로그램의 클래스와 RDB의 테이블 사용한다.
• ORM을 사용하면 SQL Query가 아닌 코드로 데이터 조작할 수 있다.

JPA(Java Persistent API)

JPA는 Java ORM 기술에 대한 명세이다. 즉, Java 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스로 이해할 수 있다. 특정 기능을 하는 라이브러리가 아니다!

JPA를 사용하기 위해서는 JPA를 구현한 프레임워크(Hibernate나 EclipseLink 등)을 사용해야 한다.

2. Hibernate는 JPA의 구현체이다.

Hibernate는 JPA의 구현체 중 하나이다.

JPA에 정의된 EntityManagerFactory, EntityManager, EntityTransaction과 같은 인터페이스를 Hibernate의 SesscionFactory, Session, Transaction이 상속받고 있는 것을 확인할 수 있다.

Hibernate 내부에서 JDBC API가 동작하고 있어 사용자가 직접 connection을 관리하지 않아도 된다.

3. Spring Data JPA로 JPA 사용을 편하게하는 모듈이다.

Spring Data JPA는 Spring에서 제공하는 모듈 중 하나로 사용자가 JPA를 편하게 사용할 수 있도록 도와준다. 이는 JPA를 추상화한 Repository라는 인터페이스를 통해 가능하다.

만약 Spring Data JPA 없이 Hibernate만 사용한다면 어떨까? Hibernate만을 사용한다면 JPA의 영속성을 관리하는 EntityManager를 주입 받아 사용해야한다. (해당 과정은 이곳에 자세히 나와있다.)

하지만 Spring Data JPA를 활용한다면 훨씬 간편하게 JPA를 사용할 수 있다.

public interface FOODao extends JpaRepository<Foo, Long> {
    Foo findByName(String name);
}

(사용 방법은 이곳에 나와있다.)

⭐요약

1. JPA는 ORM 기술의 명세다.
2. Hibernate는 JPA의 구현체이다.
3. Spring Data JPA는 데이터베이스 접근과 같은 반복되는 코드의 사용을 줄여주는 인터페이스이다. ⇒ Spring Data JPA를 사용하기 위해선 Hibernate과 같은 JPA privider가 필요하다.

Spring Data를 사용하면

• Hibernate과 같은 JPA provider를 사용할 수 있다.
• @Transaction을 통해 트랜잭션 영역을 선언하고 관리할 수 있다.

<참고 자료>

ORM

• https://gmlwjd9405.github.io/2019/02/01/orm.html

JPA, Hibernate과 Spring Data JPA

• https://dev-coco.tistory.com/74
• https://suhwan.dev/2019/02/24/jpa-vs-hibernate-vs-spring-data-jpa/
• https://sas-study.tistory.com/364

Spring Data JPA와 QueryDSL

• https://ict-nroo.tistory.com/117

<이미지 출처>

JPA 구현 프레임워크

• https://victorydntmd.tistory.com/195

JPA와 Hibernate의 상속관계

• https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html

Jpa, Hibernate, Spring Data JPA의 상관관계

• https://suhwan.dev/2019/02/24/jpa-vs-hibernate-vs-spring-data-jpa/

🤔 문제 이해하기

1. N개의 자연 수 중 M개를 아래 조건에 맞추어 선택
   • 사전 순으로 증가하는 순서
   • 중복되는 수열은 여러 번 선택 X
2. M ≤ N ≤ 8

⭐ 알고리즘

1. 수를 선택하는 문제 => 조합

2. 중복되는 수를 어떻게 확인할 건지가 관건

   • 사전 순으로 증가하는 순서

     • 주어진 N개 수를 오름차순으로 정렬
     • Link로 연결하여 순서 보장

   • 중복되는 수열은 여러 번 선택 X

     • Hashset의 특성 이용

     ⇒ LinkedHashSet을 사용하여 조건에 부합하는 M개의 숫자를 선택

💻 문제를 해결한 코드

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.util.Arrays;
import java.util.LinkedHashSet;
import java.util.StringTokenizer;

public class Main {

    static int n, m, arr[];
    static LinkedHashSet<String> hs = new LinkedHashSet<>();

    public static void main(String[] args) throws Exception {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
        StringBuilder sb = new StringBuilder();

        // 입력
        StringTokenizer st = new StringTokenizer(br.readLine(), " ");
        n = Integer.parseInt(st.nextToken());
        m = Integer.parseInt(st.nextToken());

        arr = new int[n];
        arr = Arrays.stream(br.readLine().split(" ")).mapToInt(Integer::parseInt).toArray();

        // 정렬
        Arrays.sort(arr);

        // 숫자 선택
        combination(0, new int[m], new boolean[n]);

        // 출력
        for (String str : hs) {
            sb.append(str).append("\n");
        }

        bw.write(sb.toString());
        bw.flush();
        bw.close();
        br.close();
    }

    private static void combination(int idx, int[] selected, boolean[] visited) {
        if (idx == m) {
            String str = "";
            for (int i = 0; i < m; ++i) {
                str += Integer.toString(selected[i]) + " ";
            }
            hs.add(str);
            return;
        }

        for (int i = 0; i < n; ++i) {
            if(visited[i]) continue;
            selected[idx] = arr[i];
            visited[i] = true;
            combination(idx + 1, selected, visited);
            visited[i] = false;
        }
    }

}

1464번 뒤집기3

문제 이해하기

• 문자열을 뒤집거나 그대로 두어 사전순으로 가장 앞선 문자열을 찾는다.
• 문자열의 길이 <= 50
• 제한시간 2초

문제 접근 방법

사전 순으로 앞에 있는 단어를 뒷쪽에 두고 마지막에 문자열을 reverse한다.

1. 초기 문자열: a₁a₂a₃ ... a_k-1a_ka_k+1
2. k번째 문자까지 뒤집은 문자열: a_ka_k-1 ... a₂a₁a_k+1
3. k+1번째 문자까지 뒤집은 문자열: a_k+1a₁a₂a₃ ... a_k-1a_k

⇒ 1, 2, 3 과정을 거친 결과 a_k+1의 위치만 변경되었다.

이 점을 문제에 적용해보자.

문자열 a₁a₂a₃ ... a_k-1a_ka_k+1에서

• a_k가 a_k+1보다 앞선다면 a_k+1의 위치를 변경
• a_k가 a_k+1과 앞서지 않는다면 문자열을 유지

예시로 이해해보자.

초기문자열 ACAB에서

1. 문자열 AC에서 A와 C 비교 ⇒ 위치 변경 ⇒ CAAB
2. 문자열 CAA에서 A와 A 비교 ⇒ 위치 유지 ⇒ CAAB
3. 문자열 CAAB에서 A와 B 비교 ⇒ 위치 변경 ⇒ BCAA
4. 사전 순으로 앞에 있는 단어를 뒤에 두었으므로 reverse한다.

구현 배경 지식

• 문자열 비교

문제를 해결한 코드

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;

public class Main {

    public static void main(String[] args) throws Exception {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
        StringBuilder sb = new StringBuilder();

        // 입력 및 전처리
        String str = br.readLine();
        String ans = str.substring(0, 1);

        // 로직
        for (int i = 1; i < str.length(); ++i) {
            if (ans.charAt(i - 1) < str.charAt(i)) {
                ans = str.charAt(i) + ans;
            } else {
                ans = ans + str.charAt(i);
            }
        }

        // 출력
        sb.append(ans);
        sb.reverse();
        sb.append("\n");

        bw.write(sb.toString());
        bw.flush();
        bw.close();
        br.close();
    }

}

https://leetcode.com/problems/two-sum/ 정수 배열과 target이 주어졌을 때, 배열에서 선택한 두 값의 합이 target값과 같아지도록 하는 값의 인덱스를 구한다.

O($n^2$), 85ms

문제를 처음 보았을 때 직관적으로 이중 for문을 활용하여 풀어야겠다고 생각했다.

class Solution {
    public int[] twoSum(int[] nums, int target) {
        for(int i = 0; i < nums.length - 1; ++i){
            for(int j =i+1;j<nums.length; ++j){
                if(nums[i]+ nums[j] == target){
                    return new int[] {i,j};
                }
            }
        }

        return new int[] {0, 0};
    }
}

그 결과 시간 복잡도가 상위 77%가 나왔다.

O($n$), 2ms

자료구조를 잘 활용하면 시간복잡도 개선할 수 있다. 정수 값을 key로 갖고, 배열의 인덱스를 value로 가지는 map을 이용하여 문제를 해결하였다.

import java.util.HashMap;
import java.util.Map;

class Solution {
        public int[] twoSum(int[] nums, int target) {
            Map<Integer, Integer> map = new HashMap<>();
            for (int i = 0; i < nums.length; ++i) {
                if (map.containsKey(target - nums[i])) {
                    return new int[] { i, map.get(target - nums[i]) };
                }
                map.put(nums[i], i); // put number and index
            }

            return new int[] {};
        }
    }

문제

https://www.acmicpc.net/problem/6064

❌ 시간 초과

날짜 계산 문제를 풀었던 것처럼 브루트포스를 이용하여 풀어보고자 하였다. 그러나 이 경우 시도해보아야하는 경우의 수는 M*N, 최대 16억 개를 주어진 시간 안에 문제를 해결할 수 없다.

#include <iostream>
using namespace std;

int getGCD(int a, int b) {
    int c;
    while (b != 0) {
        c = a % b;
        a = b;
        b = c;
    }
    return a;
}

int getLCM(int a, int b) {
    int gcd = getGCD(a, b);
    return a * b / gcd;
}

int main() {
    ios_base::sync_with_stdio(false);
    cin.tie(NULL); cout.tie(NULL);

    int t; cin >> t;
    while (t--) {
        int m, n, x, y;
        cin >> m >> n >> x >> y;
        int cnt = getLCM(m, n);
        int year = 1;

        while (cnt--) {
            x--; y--;
            if (x <= 0 && y <= 0) break;

            if (x <= 0) x = m;
            if (y <= 0) y = n;
            year++;
        }
        if (cnt > 0) cout << year << '\n';
        else cout << -1 << '\n';
    }

    return 0;
}

⭕ 맞았습니다!!

브루트포스로는 해결할 수 없어 아래 나온 몇가지 조건들을 고려하여 해결하였다.

• 구하고자하는 연도를 M으로 나누었을 때 나머지가 x여야한다.
• 멸망년도에 도달하기 전까지, 구하고자하는 연도와 y값이 대응하는지 살펴본다.

  #include <iostream>
  using namespace std;
  

int getGCD(int a, int b) { int c; while (b != 0) { c = a % b; a = b; b = c; } return a; }

int getLCM(int a, int b) { int gcd = getGCD(a, b); return a * b / gcd; }

int main() { ios_base::sync_with_stdio(false); cin.tie(NULL); cout.tie(NULL);

int t; cin >> t;
while (t--) {
    int m, n, x, y;
    cin >> m >> n >> x >> y;
    int cnt = getLCM(m, n);
    int year = -1;

    for (int i = x; i <= cnt; i += m) {
        int ny = i % n;
        if (ny == 0) ny = n;
        if (ny == y) {
            year = i;
            break;
        }
    }
    cout << year << '\n';
}

return 0;

} ```

문제

https://www.acmicpc.net/problem/6588

⭕ 맞았습니다!!

에라토스테네스의 체를 사용하여 소수를 모두 구해두었다. 그 다음, 주어진 숫자를 홀수 소수의 합으로 구할 수 있는지 살펴보았다. 불가능한 경우를 나타내기 위해 투포인터의 개념을 적용하였다.

#include <iostream>
#include <math.h>
using namespace std;


int main() {
    ios_base::sync_with_stdio(false);
    cin.tie(NULL); cout.tie(NULL);

    int primeNum[1000001] = { 0, };

    primeNum[1] = 1;
    for (int i = 2; i <= sqrt(1000000); i++) {
        if (primeNum[i] == 1) continue;
        for (int j = 2 * i; j <= 1000000; j += i) {
            primeNum[j] = 1;
        }
    }

    int n;
    while (1) {
        cin >> n;
        if (n == 0) break;

        for (int left = 3; left <= n / 2 + 1; left += 2) {
            int right = n - left;
            if (left > right) {
                cout << "Goldbach's conjecture is wrong.\n";
                break;
            }
            if (primeNum[left]) continue;
            if (primeNum[right] == 0) {
                cout << n << " = " << left << " + " << right << '\n';
                break;
            }
        }
    }
    return 0;
}

Stack Overflow

문제를 풀며 stack overflow를 마주하였다. 범위가 큰 primeNum 배열을 main 함수 내부에서 정의하여 발생한 것이였다.

그 원인은 배열이 할당되는 위치에 있었다. main 함수 내에서 선언된 배열은 스택 영역에 생성된다. 스택영역은 프로그램이 사용하는 임시 메모리로 할량할 수 있는 정도가 적다.

해당 배열을 전역 변수로 설정하여 문제를 해결할 수 있었다. 전역변수로 변수를 선언하면 이는 함수가 호출되기 전에 메모리의 데이터 영역에 할당된다.

자세한 내용은 백준 게시판 질문, 위키백과의 참고2에서 살펴볼 수 있다.