Sunwoo’s log

네트워크 면접 키워드 - 1

Sat, 09 Nov 2024 09:39:38 GMT

1. 네트워크 기본 개념

컴퓨터 네트워크

컴퓨터 네트워크란 두 대 이상의 컴퓨터와 기타 장치들이 서로 연결되어 데이터를 주고받을 수 있는 시스템을 말한다. 컴퓨터 네트워크는 자원 공유, 데이터 전송, 원경 통신을 가능하게 하여 현대 정보 통신 시스템의 기반이 된다. 네트워크의 규모는 소규모 LAN 부터 전 세계를 연결하는 WAN 까지 다양하다.

주요 구성 요소
1. 노드: 네트워크에 연결된 컴퓨터, 서버, 라우터와 같은 개별 장치를 의미
2. 전송 매체: 데이터를 전달하기 위해 사용하는 물리적 또는 무선 매체로 이더넷 케이블이나 와이파이 같은 형태가 있다
3. 프로토콜: 네트워크 통신을 위해 사용하는 규칙과 표준으로, 대표적으로 TCP/IP 가 있다
4. 라우터: 서로 다른 네트워크를 연결하고, 패킷이 목적지로 갈 수 있도록 경로를 지정
5. 스위치: 같은 네트워크 내에서 장치들을 연결하고, 데이터를 특정 기기로 전달하는 장치
인터넷

인터넷은 전 세계의 다양한 컴퓨터 네트워크가 하나로 연결된 거대한 네트워크 시스템이다. 인터넷은 TCP/IP 라는 통신 규약을 기반으로 작동하며, 네트워크 간 데이터 교환과 커뮤니케이션을 가능하게 한다. 오늘날 인터넷은 정보의 공유, 원격 통신, 다양한 서비스 제공의 중심에 있으며, 거의 모든 디지털 활동의 기반이 된다.

인터넷의 주요 요소
1. IP 주소: 네트워크 상에서 기기를 식별하기 위해 사용하는 고유한 숫자 주소이다. IPv4 와 IPv6 두 가지 형식이이 존재한다
2. 도메인 이름: IP 주소 대신 사람이 쉽게 기억할 수 있는 이름으로, DNS 를 통해 IP 주소로 변환된다
3. 프로토콜: 인터넷에서 데이터 통신이 이루어지는 규칙으로 HTTP, FTP, SMTP 등이 있다
4. ISP: Internet Service Provider 로 인터넷 연결 서비스를 제공하는 사업자이다
네트워크 구조

네트워크 구조는 컴퓨터와 장치들이 어떻게 서로 연결되고 통신하는지를 나타내며, 네트워크의 효율성, 확장성, 보안성 등에 영향을 미친다. 네트워크 구조는 물리적 연결 방식과 논리적 통신 방식에 따라 다양하게 구성되며, 대표적인 구조로 버스형, 스타형, 링형, 메시형, 트리형이 있다.

1. 버스형 구조
    1. 모든 컴퓨터와 장치가 버스라고 하는 하나의 중앙 케이블에 연결되는 구조이다
    2. 장점은 설치가 간단하고 케이블 비용이 낮다
    3. 단점은 중앙 케이블이 손상되면 전체 네트워크가 중단되고, 대역폭이 제한적이기 때문에 장치가 많아지면 성능이 저하될 수 있다
    4. 소규모 네트워크에 적합하다

2. 스타형 구조
    1. 중앙에 스위치나 허브가 있고, 모든 장치가 이 중앙 장치에 각각 연결되는 구조이다
    2. 장점은 중앙 장치의 유지 보수 만으로 관리가 용이하고, 한 장치가 고장 나도 네트워크 전체에는 영향을 미치지 않는다
    3. 단점은 중앙 장치가 고장 나면 전체 네트워크가 중단될 수 있고, 중앙 장치에 부하가 많이 걸릴 수 있다
    4. 가정이나 소규모에서 대규모 네트워크에 널리 사용된다

3. 링형 구조
    1. 각 장치가 양 옆의 장치와 연결되어 원형 형태를 이루는 구조이고, 데이터는 한 방향으로 순환하며 목적지에 도달한다
    2. 장점은 데이터 충돌이 적고, 네트워크의 흐름을 제어 하기가 용이하다
    3. 단점은 하나의 장치나 링크가 고장 나면 전체 네트워크에 문제가 생긴다
    4. 트래픽 관리가 중요한 네트워크에 사용된다

4. 메시형 구조
    1. 모든 장치가 서로 직접 연결되는 구조로, 모든 장치 간에 다수의 경로가 존재한다
    2. 장점은 고장 시 다른 경로로 데이터 전송이 가능해 매우 안정적이고, 보안성과 신뢰성이 높다
    3. 단점은 설치 비용과 복잡도가 높고, 많은 케이블과 포트가 필요해 확장성이 떨어진다
    4. 안정성과 보안이 중요한 대규모 네트워크에 적합하다

5. 트리형 구조
    1. 계층 구조를 이루며, 여러 스타형 네트워크가 버스 형태로 연결된 구조이고, 각 계층의 장치가 계층적으로 연결된다
    2. 장점은 네트워크의 확장과 관리를 쉽게 할 수 있으며, 네트워크 분할에 용이하다
    3. 단점은 버스 케이블에 장애가 발생하면 전체 네트워크가 영향을 받을 수 있다
    4. 대규모 네트워크 환경에서 계층적으로 연결하여 관리가 필요한 경우 사용된다

네트워크의 구조는 확장성, 유지 보수 용이성, 안정성 및 복구 가능성, 비용 등을 고려하고 선택해야 한다

LAN

LAN은 Local Area Network 로 동일한 물리적 위치 내에서 제한된 거리 안의 컴퓨터와 장치들을 연결한 네트워크이다. 일반적으로 사무실, 학교, 가정 등 좁은 공간에서 사용되며, 고속 데이터 전송이 가능하고 외부 인터넷 연결 없이도 네트워크 내에서 자원 공유와 통신이 가능하다

주요 특징
1. 제한된 범위: LAN은 비교적 좁은 공간 내에서 운영된다
2. 고속 데이터 전송: 근거리 내의 네트워크로 빠른 전송 속도가 가능하다
3. 자원 공유: 네트워크에 연결된 장치들이 프린터, 스캐너, 파일 서버 등의 자원을 공유한다
4. 보안 및 제어: 네트워크 관리자에 의해 제어되어, 외부 접근을 제한하고 보안을 강화할 수 있다
5. 유선 및 무선 연결: 이더넷 케이블을 사용하는 유선 LAN 과 WIFI 를 이용하는 무선 LAN 으로 구성될 수 있다
  
  구성 요소
6. NIC: 네트워크 인터페이스 카드로 컴퓨터가 네트워크에 연결되도록 하는 장치이고 유선 또는 무선 연결을 지원한다
7. 스위치: 네트워크 내의 장치들이 서로 연결되어 데이터를 주고받도록 하는 장치이다
8. 라우터: LAN 과 외부 네트워크를 연결해주며, 네트워크 간 데이터 경로를 설정한다
9. 케이블 및 무선 액세스 포인트: 유선 LAN 에서는 이더넷 케이블이 사용되고, 무선 LAN 에서는 무선 액세스 포인트가 사용된다

장점

고속 데이터 전송: 근거리 환경에서 높은 전송 속도를 제공해 데이터 교환이 빠르다
비용 효율성: 좁은 범위에서 이루어지기 때문에 초기 설치 비용이 낮다
자원 및 파일 공유: 같은 네트워크에 연결된 여러 사용자가 쉽게 자원을 공유할 수 있다
보안성: 외부 네트워크와 격리되어 있어 보안성을 높일 수 있다

단점

거리 제한: 한정된 범위 내에서만 구축 가능하고 다른 지점과 연결하려면 WAN 을 사용해야 한다
트래픽 부하: 많은 장치가 연결되면 대역폭이 소모되어 네트워크 속도가 저하 될 수 있다

WAN

WAN 은 Wide Area Network 로 지리적으로 떨어져 있는 넓은 지역에 걸쳐 여러 LAN 과 다른 네트워크를 연결한 네트워크이다. 도시, 국가, 대륙 단위로 네트워크를 구성하며, 가장 대표적인 예로 인터넷이 있다.

주요 특징

광범위한 범위: WAN 은 국가, 대륙 간의 넓은 범위에서 네트워크를 연결할 수 있다
낮은 데이터 전송 속도: 넓은 지역을 커버하기 때문에 LAN 에 비해 전송 속도가 낮다
공공 네트워크 인프라 활용: WAN 은 통신사를 통한 ISP, 전용선과 같은 네트워크 서비스를 사용하여 연결되는 경우가 많다
고비용: 광범위한 연결과 유지 관리에 비용이 많이 든다
인터넷 연결: 인터넷과 같은 광범위한 네트워크와 연결되어 세계적인 데이터 교환을 가능하게 한다

주요 구성 요소

라우터: 서로 다른 네트워크를 연결하고, 데이터가 목적지까지 올바르게 전달되도록 경로를 설정
전용선: 두 지역을 연결하기 위해 통신사에서 임대한 전용 회선으로, 고속 데이터 전송이 가능하지만 비용이 높다
위성 링크: 멀리 떨어진 지역 간의 연결을 위해 위성을 통한 통신을 사용하며, 특히 해양이나 외딴 지역에서 유용하다
모뎀: 전화선을 이용한 네트워크 연결을 위해 사용되는 장치로, 데이터를 아날로그 신호로 변환하여 전송

장점

광범위한 연결: 다양한 지역, 국가, 대륙 간 네트워크를 연결할 수 있어 글로벌 통신 가능
효율적인 자원 공유: 원격지 간 자원과 데이터를 공유할 수 있어 대규모 조직이나 지점 간 협업에 용이
강화된 보안: WAN 전용선을 사용하거나, VPN 을 통해 보안이 강화된 연결 제공

단점

높은 비용
낮은 전송 속도
복잡한 관리

회선 교환 네트워크

회선 교환 네트워크는 통신을 위해 물리적인 경로를 고정적으로 설정하여 데이터를 전송하는 네트워크 방식이다.

회선 교환 방식은 주로 전화망에서 사용되며, 통신이 시작되면 두 장치 간에 하나의 전용 회선이 설정되고, 통신이 끝날 때 까지 해당 회선이 독점적으로 사용된다

특징

고정 경로 설정: 통신이 시작되기 전에 경로가 설정되며, 경로는 통신이 끝날 때까지 고정
연속 데이터 전송: 데이터가 연속적으로 전달되며, 전송 중에 경로 변경 X
낮은 지연: 경로가 설정되면 데이터가 연속적으로 전송되어 지연이 거의 없다
전용 회선 사용: 통신 중에는 다른 장치가 해당 회선을 사용할 수 없어, 안정적이고 독점적인 데이터 전송 가능

주요 단계

경로 설정 (Call Setup): 두 장치 간 통신 경로가 설정되는 단계, 모든 네트워크 장비가 데이터를 전송할 고정 경로 확보
데이터 전송 (Data Transfer): 경로가 설정된 후 데이터가 연속적으로 전송, 이 동안 회선은 통신하는 두 장치가 독점적으로 사용
경로 해제 (Call Teardown): 통신이 끝나면 경로가 해제되어 다른 통신이 해당 경로 사용할 수 있게 된다

장점

지속적이고 안정적인 전송: 경로가 설정되면 데이터가 끊김 없이 전송되어, 음성 통신과 같은 실시간 통신에 적합
낮은 지연 시간: 경로가 고정되어 있어 데이터 전송 시 지연이 거의 없다
일관된 대역폭 제공: 설정된 경로의 대역폭을 두 장치가 독점적으로 사용해 일정한 전송 속도를 유지할 수 있다

단점

낮은 자원 효율성: 통신 중에는 회선이 두 장치에 고정되어 실제 데이터가 전송되지 않을 때도 회선이 비어 있게 되어 자원이 낭비될 수 있다
고비용: 전용 회선을 사용하는 방식이기 때문에, 특히 대규모 네트워크에서는 비용이 많이 들 수 있다
설정 시간 필요: 통신 전에 경로 설정이 필요하여, 데이터 전송 전에 약간의 지연이 발생할 수 있다

패킷 교환 네트워크와의 비교

회선 교환: 통신을 위해 고정된 경로가 설정되고, 경로를 통신하는 두 장치가 독점적으로 사용해 실시간 음성 통신에 적합
패킷 교환: 데이터를 작은 패킷 단위로 나눠 각 패킷이 독립적으로 최적의 경로로 전송되어 자원 효율성이 높고, 인터넷과 같은 데이터 통신에 적합
패킷 교환 네트워크

패킷 교환 네트워크는 데이터를 작은 단위인 패킷으로 나누어 전송하는 방식의 네트워크이다.

각 패킷은 독립적으로 목적지로 전송되며, 경로는 고정되지 않고 네트워크 상황에 따라 동적으로 설정된다. 이 방식은 회선 교환 네트워크와 달리 여러 사용자가 네트워크 자원을 효율적으로 공유할 수 있게 해준다

작동방식

데이터 분할: 보낼 데이터를 일정한 크기의 패킷으로 나눈다
패킷 헤더 추가: 각 패킷에는 송신자, 수신자 주소, 순서 정보 등이 포함된 헤더가 존재
독립적 전송: 각 패킷은 독립적으로 최적의 경로를 찾아 전송되며, 경로는 전송 중에 변경할 수 없다
재조립: 목적지에 도착한 패킷들은 순서에 따라 다시 원래 데이터로 조립

주요 특징

동적 경로 설정: 각 패킷이 최적의 경로를 찾아 목적지로 이동해 네트워크 상태에 따라 경로가 달라질 수 있다
높은 자원 효율성: 네트워크 자원을 모든 사용자가 공유하기 때문에 회선 교환에 비해 자원 효율이 높다
데이터 손실 가능성: 네트워크 혼잡이나 장애로 인해 일부 패킷이 손실될 수 있지만, 패킷 재전송으로 보완된다
지연 발생 가능성: 패킷이 서로 다른 경로로 이동하고, 혼잡 시 지연이 발생할 수 있다

장점

효율적인 자원 사용: 회선을 독점하지 않고 필요한 만큼의 자원을 사용하기 때문에 네트워크 효율성이 높다
유연성: 네트워크 상태에 따라 경로를 동적으로 조정할 수 있어, 장애에 유연하게 대응할 수 있다
비용 절감: 여러 사용자가 네트워크 자원을 공유해 대규모 네트워크 구축 비용 절감

단점

가변 지연: 네트워크 상태에 따라 경로와 전송 시간이 달라져, 지연이 발생할 수 있다
복잡한 관리: 패킷 재전송, 경로 최적화 등 복잡한 네트워크 관리가 필요
데이터 손실 가능성: 패킷 손실 시 재전송 매커니즘이 필요해 추가적인 대역폭 소모가 발생할 수 있다

프로토콜

프로토콜은 컴퓨터 네트워크에서 데이터 통신을 위한 일련의 규칙과 규약을 의미한다. 서로 다른 장치가 원활하게 데이터를 주고받기 위해 따르는 일종의 언어와 약속이다. 각 프로토콜은 특정한 기능과 구조를 가지고 있으며, 네트워크의 여러 계층에서 다양한 역할을 수행한다

주요 프로토콜의 종류와 역할
1. TCP/IP (Transmission Control Protocol / Internet Protocol)
  - TCP: 데이터를 신뢰성 있게 전송하기 위한 프로토콜로, 데이터 전송 중 손실된 패킷을 재전송하는 기능을 제공하고 연결 지향적이다
  - IP: 패킷을 목적지 주소로 전달하는 역할을 하며, 라우팅을 담당한다. 주소 지정 및 패킷 전달을 수행하며 비연결형이다
2. HTTP/HTTPS (Hypertext Transer Protocol / Secure)
  - HTTP: 웹 브라우저와 서버 간에 통신에 사용하는 프로토콜로, 주로 HTML 문서를 전송하는 데 사용된다
  - HTTPS: HTTP에 보안 계층(SSL/TLS)을 추가한 것으로, 데이터 암호화를 통해 사용자 정보를 보호한다
3. FTP (File Transfer Protocol)
  - 파일을 서버와 클라이언트 간에 전송하기 위한 프로토콜로 대용량 파일 전송에 적합하며, 업로드와 다운로드 모두 가능하다
4. SMTP/POP3/IMAP (Email Protocols)
  - SMTP (Simple Mail Transfer Protocol): 이메일을 보내는 데 사용되는 프로토콜
  - POP3 (Post Office Protocol 3): 서버에서 이메일을 가져오고 로컬에 저장하는 프로토콜
  - IMAP (Internet Message Access Protocol): 서버에서 이메일을 관리하고 동기화하는 데 사용되며, 여러 기기에서 이메일을 확인할 때 사용
5. DNS (Domain Name System)
  - 사용자가 입력한 도메인 이름을 IP 주소로 변환하기 위한 프로토콜로 웹사이트에 접근할 때 사람이 이해하기 쉬운 도메인 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환해주는 프로토콜
6. DHCP (Dynamic Host Configuration Protocol)
  - 네트워크에 연결되는 장치에 IP 주소를 자동으로 할당하는 프로토콜
7. SSH (Secure Shell)
  - 네트워크를 통해 원격으로 컴퓨터에 안전하게 접근하기 위한 프로토콜로 보안이 강화된 통신을 제공하고, 원격 서버나 장치에 접속할 때 흔히 사용된다
8. SNMP (Simple Network Management Protocol)
  - 네트워크 장비를 모니터링하고 관리하기 위한 프로토콜
9. ARP (Address Resolution Protocol)
  - 네트워크 내에서 IP 주소를 MAC 주소로 변환하는 프로토콜로 네트워크 계층의 IP 주소와 데이터 링크 계층의 물리 주소 간 매핑을 제공
10. ICMP (Internet Control Message Protocol)
  - 네트워크 진단 및 오류 보고를 위한 프로토콜로 주로 ping 명령어로 목적지와의 연결 상태를 확인 할 때 사용
네트워크 참조 모델

네트워크 참조 모델은 네트워크 통신이 이루어지는 과정과 각 계층의 역할을 정의하는 표준화된 모델이다. 네트워크의 다양한 요소가 서로 상호작용하고 데이터를 전달하기 위해 필요한 규칙과 절차를 계층별로 나누어 설명하고 대표적인 네트워크 참조 모델로는 OSI (Open Systems Interconnection) 모델이나 TCP/IP 모델이 있다

OSI 모델 (7계층 모델)

OSI 모델은 ISO가 제안한 7계층 모델로, 네트워크 통신을 7개의 계층으로 나누어 각 계층이 독립적으로 기능할 수 있도록 한 모델이다

1. 물리 계층
    - 전기적, 물리적 신호의 전송을 담당하며, 비트 단위로 데이터를 전송
    - 케이블, 무선과 관련된 전송매체들의 표준을 정의
2. 데이터 링크 계층
    - 에러 감지 및 수정, 프레임을 통한 데이터 전송을 담당
    - MAC 주소를 기반으로 네트워크 내에서 장치 간의 통신을 관리
    - 스위치와 같은 장치가 작동하는 계층
3. 네트워크 계층
    - 데이터를 목적지 IP 주소로 전달하고, 패킷의 라우팅을 담당
    - IP 주소를 사용해 데이터가 네트워크를 통해 전송되는 경로를 결정
    - 라우터가 작동하는 계층
4. 전송 계층
    - TCP 와 UDP 가 위치하며, 데이터 전송의 신뢰성과 속도 조정
    - 패킷을 분할하고 재조립
5. 세션 계층
    - 통신 세션을 설정하고 유지, 종료하는 기능을 담당
6. 표현 계층
    - 데이터의 인코딩, 압축, 암호화를 수행
7. 응용 계층
    - 사용자와 직접 상호 작용하는 프로토콜이 위치하며, HTTP, FTP, SMTP 등이 포함

TCP/IP 모델 (4계층 모델)

TCP/IP 모델은 인터넷에서 사용되는 기본적인 네트워크 모델로, OSI 모델과 달리 4계층으로 구성된다. OSI 모델보다 단순하며, 실제 인터넷에서 널리 사용되는 모델이다

1. 네트워크 접근 계층
    - OSI 모델의 물리 계층과 데이터 링크 계층을 결합한 계층으로, 데이터가 네트워크 매체를 통해 전달되는 과정을 담당
    - 이더넷, 와이파이와 같은 물리적 연결 기술을 포함
2. 인터넷 계층
    - OSI 모델의 네트워크 계층에 해당하며, IP 주소를 통해 데이터 패킷이 목적지에 도달할 수 있도록 라우팅
3. 전송 계층
    - 데이터의 신뢰성과 속도를 제어하며, 애플리케이션 간 데이터 전송을 관리
4. 응용 계층
    - OSI 모델의 상위 3개 계층을 결합해 사용자가 직접 접속하는 부분

네트워크 참조 모델의 중요성

표준화된 통신: 네트워크 통신의 표준을 제시해 서로 다른 기기나 시스템이 원활하게 통신 가능
계층화된 구조: 각 계층이 독립적으로 기능을 수행할 수 있어 네트워크 설계와 관리가 용이
문제 해결 및 유지보수 용이: 각 계층별로 문제를 구분하고 해결할 수 있어 네트워크 유지보수가 효율적
다양한 프로토콜 통합: 각 계층에서 특정한 프로토콜을 사용해 다양한 통신 요구를 충족 가능
캡슐화

캡슐화는 네트워크 통신 과정에서 데이터를 송신자에서 수신자로 보내기 위해 각 계층별로 헤더나 트레일러를 추가하는 과정이다. 이 과정을 통해 데이터가 효율적이고 안전하게 전달되며, 계층 간의 독립성이 보장된다. 캡슐화는 데이터가 네트워크를 통해 이동하는 동안 각 계층에서 필요한 정보를 추가하는 방식으로 이루어진다.

캡슐화 과정
1. 응용 계층
  - 사용자가 입력한 데이터를 전달받고, 응용 계층 프로토콜(HTTP, FTP..)이 해당 데이터를 처리
  - 응용 계층에서 제공된 데이터는 전송 계층으로 전달
2. 전송 계층
  - 전송 계층에서는 데이터에 TCP/UDP 헤더를 추가해 데이터 전송의 신뢰성과 속도를 관리
  - 이 계층에서 추가된 헤더에는 송신 포트와 수신 포트 정보, 오류 검출을 위한 정보가 포함
  - 이 과정으로 만들어진 데이터를 세그먼트(TCP) 나 데이터그램(UDP) 로 부른다
3. 네트워크 계층
  - 네트워크 계층에서는 세그먼트에 IP 헤더를 추가해 패킷을 목적지로 전달하는 데 필요한 정보를 포함한다
  - 이 계층에서 만들어진 데이터를 패킷 이라고 한다
4. 데이터 링크 계층
  - 데이터 링크 계층에서는 패킷에 MAC 주소와 같은 물리적인 주소 정보를 포함한 프레임 헤더와 오류 검출을 위한 트레일러를 추가
  - 이 과정으로 만들어진 데이터를 프레임 이라고 한다
5. 물리 계층
  - 물리 계층에서는 프레임을 전기 신호 또는 무선 신호로 변환하여 실제 네트워크 매체를 통해 전송
  - 비트 단위로 데이터를 전송
  캡슐화의 장점
- 계층 간 독립성: 각 계층이 독립적으로 기능을 수행할 수 있어 네트워크 설계와 관리가 용이
- 확장성: 새로운 프로토콜이나 기능을 추가할 때, 다른 계층에 영향을 최소화 할 수 있다
- 데이터 보안과 무결성: 각 계층에서 필요한 정보를 추가하므로, 데이터 전송 중 오류 검출과 보안 기능이 강화된다
역캡슐화

송신자가 보낸 데이터를 수신자가 받는 과정에서 각 계층별로 추가된 헤더와 트레일러를 제거하여 원래의 데이터로 추출하는 과정이다. 이는 캡슐화의 반대 과정으로, 네트워크를 통해 전달된 데이터가 목적지에서 다시 해석되고 원래 형태로 변환되는 데 사용된다

역캡슐화 과정
1. 물리 계층
  - 데이터를 비트 단위의 전기 신호 또는 무선 신호로 받아들인다
  - 받은 비트 신호를 디지털 데이터로 변환하여 상위 계층인 데이터 링크 계층으로 전달
2. 데이터 링크 계층
  - 물리 계층에서 받은 프레임을 처리하며, 이 과정에서 프레임 헤더와 트레일러를 제거하고 남은 데이터를 네트워크 계층으로 전달
  - 프레임 헤더에는 송신자와 수신자의 MAC 주소와 같은 물리적 주소 정보가 포홤되어 있다
3. 네트워크 계층
  - 데이터 링크 계층에서 받은 패킷을 처리하고, 패킷의 IP 헤더를 제거한다
  - 이 과정에서 송신 IP 주소와 수신 IP 주소 등의 정보가 사용되며, 데이터가 최종 목적지에 도달하도록 관리
  - 네트워크 계층의 처리가 끝나면 전송 계층으로 전달
4. 전송 계층
  - 네트워크 계층에서 받은 세그먼트를 처리하여 TCP 또는 UDP 헤더를 제거
  - 이 헤더에는 포트 번호와 오류 검출 정보 등이 포함되어 있으며, 데이터가 올바르게 수신되었는지 확인
  - 전송 계층의 처리 후 데이터는 응용 계층으로 전달
5. 응용 계층
  - 전송 계층에서 받은 데이터에서 응용 계층 프로토콜을 통해 원래의 데이터를 추출
  - 최종적으로 사용자가 이해할 수 있는 형태로 데이터가 제공
  역캡슐화의 중요성
- 데이터 복원: 송신자가 보낸 원본 데이터를 수신자가 올바르게 해석할 수 있게 한다
- 네트어크 계층별 기능 분리: 각 계층이 캡슐화/역캡슐화 과정을 통해 독립적으로 기능 수행 가능
- 데이터 무결성 및 오류 검출: 각 계층에서 헤더 정보를 통해 데이터가 올바르게 전송되었는지 확인
PDU

PDU(Protocol Data Unit)는 프로토콜 데이터 단위로 네트워크의 각 계층에서 데이터를 전송하거나 처리할 때 사용하는 데이터의 단위를 의미한다. 네트워크의 각 계층별로 다르게 정의되며, 계층별 데이터 전송 규약에 따라 특정 이름으로 불린다.

OSI 모델에서의 PDU 종류
1. 응용 계층, 표현 계층, 세션 계층 - 데이터
2. 전송 계층 - 세그먼트
3. 네트워크 계층 - 패킷
4. 데이터 링크 계층 - 프레임
5. 물리 계층 - 비트

PDU의 중요성

데이터 관리와 계층별 처리: 각 계층의 PDU는 데이터를 계층별로 독립적으로 처리할 수 있도록 하며, 이를 통해 네트워크 통신이 구조적으로 이루어진다
데이터 전송 오류 방지: 각 계층에서 데이터 오류를 감지하고 수정할 수 있는 정보가 추가되어, 데이터 전송의 신뢰성을 보장
프로토콜 간 상호 운용성: 다양한 네트워크 프로토콜이 계층별 PDU를 사용해 상호 운용되며, 다양한 네트워크 환경에서의 통신을 가능하게 한다

세션과 JWT

Thu, 31 Oct 2024 13:36:22 GMT

인증과 인가란?

세션과 JWT에 대해서 설명드리기 전에 인증과 인가에 대해서 말씀드리겠습니다. 인증이란 Authentication 으로 사용자 또는 장치의 신원을 확인하는 과정입니다. 예를 들어 어떤 서비스를 이용하기 전에 아이디와 패스워드를 입력해서 서비스가 사용자의 신원을 확인하는 과정을 인증이라고 합니다. 인가는 Authorization 으로 사용자가 어떤 리소스에 접근할 수 있는지 또는 어떤 동작을 수행할 수 있는지 검증을 하는 것을 의미합니다. 예를 들어 무신사에서 상품을 삭제하는 기능을 사용자가 사용할 수 있는지 권한을 확인하는 과정을 의미합니다.

저희가 서비스를 개발할 때 인증과 인가를 사용해서 현재 로그인되어 있는 사용자가 어떤 기능을 사용할 수 있는지 확인하는 과정을 거쳐야합니다. 그런데 저희가 사용하는 HTTP 는 클라이언트가 서버에 요청을 보내고, 서버가 클라이언트에게 데이터를 응답하는 방식으로 동작하는 프로토콜인데, HTTP 의 대표적인 특징으로는 Stateless가 있습니다. Stateless란 클라이언트와 첫번째 통신에서 데이터를 주고받았을지라도, 두번째 통신에서는 이전 데이터를 유지하지 않는다는 것입니다. 그렇기 때문에 로그인 상태를 유지하기 위해서는 서버에 요청을 보낼 때마다 내가 누구인지를 알려줘야 합니다.

그런데 모든 요청마다 사용자가 로그인을 할 수는 없으니 로그인 상태를 유지해야하는데 이때 사용되는 기술이 세션과 JWT입니다.

세션

세션 방식 로그인은 기존에 전통적으로 많이 사용되어온 방식입니다.

세션 방식의 로그인 과정은 아래와 같습니다.

유저가 사이트에 접속을 한 후 로그인을 진행합니다.
유저가 로그인을 완료하면 서버에서 세션 ID를 생성하고 세션 ID, 사용자 정보, 세션 유효기간 등의 정보가 담긴 새로운 세션을 생성하고 서버의 메모리나 세션 스토어등에 저장합니다
생성한 세션 ID를 클라이언트에 Header 의 Set-Cookie로 전달해줍니다.
이후 클라이언트에서는 서버로부터 전달받은 세션 ID를 클라이언트의 쿠키에 저장합니다.
해당 사이트에 대한 모든 요청에 세션 ID를 담은 쿠키를 함께 전송합니다.
서버는 클라이언트가 보낸 세션 ID와 서버에서 관리하고 있는 세션 ID를 비교해서 일치한다면 인가를 수행해줍니다.

이 과정에서의 중요한 점은 유저의 정보들을 서버 쪽에서 관리한다는 것입니다.

세션 방식의 로그인의 장점은 위와 같습니다.

사용자 정보가 서버에 저장되기 때문에 클라이언트가 정보를 직접 보관하지 않아 보안성이 높습니다.
클라이언트는 세션 ID만 저장하면 되기 때문에, 클라이언트의 저장 공간을 절약할 수 있습니다.
서버에서 세션 정보를 관리하므로, 사용자의 추가 정보나 상태를 쉽게 업데이트하고 관리할 수 있습니다.
사용자가 여러 장치에서 로그인할 경우, 서버는 이를 관리해서 사용자가 각 장치에서 동일한 세션을 사용할 수 있게 하여 편리함을 제공해줍니다.

단점은 위와 같습니다.

서버는 모든 사용자 세션 정보를 메모리나 데이터베이스에 저장해야 하므로, 많은 사용자 트래픽을 처리할 경우 서버의 리소스가 많이 소모됩니다.
중앙 세션 스토어가 아닌, 서버 컴퓨터의 메모리나 하드디스크에 저장할 경우 확장성이 좋지 않습니다. 그 이유는 서버 컴퓨터를 추가할 경우 각 서버 컴퓨터마다 세션 정보를 공유해야하기 때문입니다.
사용자의 아이디와 패스워드를 몰라도 공격 대상이 이미 시스템에 접속되어 세션이 연결되어 있는 상태를 가로채기 하는 공격으로 공격자가 인증 작업 등이 완료된 정상적으로 통신하고 있는 다른 사용자의 세션을 가로채서 별도의 인증 작업을 거치지 않고 가로챈 세션으로 통신을 계속하는 세션 하이재킹 공격을 당할 수 있습니다. 이를 방지하기 위해 HTTPS를 사용해 요청 자체를 탈취해도 정보를 읽기 힘들게 하고, 세션에 유효기간을 넣어, 정보를 탈취하더라도 유효기간이 끝나면 더이상 해커가 이용할 수 없도록 해야합니다.

JWT

JWT는 JSON Web Token의 약자로 특수한 형태의 문자열입니다

. 을 기준으로 구분되어 header, payload, signature 로 구성되어 있습니다. JWT는 암호화되어 있지 않기때문에 누구나 확인할 수 있습니다. 그렇기 때문에 중요한 정보를 JWT에 담으면 안됩니다.

Header에는 typ 와 alg 라는 정보가 존재하는데 typ 에는 토큰의 타입이 작성되어 있고, alg에는 Signature 에서 사용하는 알고리즘이 무엇인지가 작성되어 있습니다.

Payload에는 토큰의 실제 내용을 담고 있습니다. 여기에는 클레임 이라고 불리는 정보 조각이 포함됩니다.

Signature에는 헤더와 페이로드를 조합하여 특정 비밀키로 서명되어 생성됩니다. Signature를 사용해 해당 토큰이 변조되지 않았음을 검증하는 데 사용됩니다.

JWT 토큰을 사용한 로그인 과정에 대해서 설명해보겠습니다.

사용자가 사이트에 접속을 한 후 로그인을 진행합니다.
로그인이 완료되면 서버에서 JWT 토큰을 생성하고 클라이언트에 전송합니다.
클라이언트는 JWT 토큰을 쿠키나 로컬 스토리지에 저장을 하고 모든 요청에 Authorization 헤더에 JWT 토큰을 포함하여 서버에 전송합니다.
서버에서는 JWT에 포함된 Signature를 확인하여 토큰의 무결성을 검사하고 만료 시간을 체크한 후에 요청을 처리합니다.

앞의 세션과의 가장 큰 차이점은 세션은 사용자의 정보를 서버에 저장하고 SESSIONID만 클라이언트에 전송하는 것과 사용자의 정보를 JWT 토큰에 저장하고 토큰 자체를 클라이언트에 전송하는 것입니다.

JWT 방식의 로그인의 장점에 대해서 말씀드리겠습니다.

JWT는 클라이언트에 저장되므로 서버는 사용자 세션 정보를 유지할 필요가 없어 서버의 메모리 사용량을 줄이고 여러 대의 서버 사용을 용이하게 만듭니다.
JWT는 사용자 정보의 메타데이터를 토큰 자체에 포함하기 때문에 서버는 JWT를 검증함으로써 사용자의 정보를 즉시 조회할 수 있어 별도의 데이터베이스 호출이 필요하지 않습니다.
http 헤더나 url 파라미터를 통해 간단하게 전송되기 때문에 네트워크 부하가 적습니다

다음으로 JWT 방식의 로그인의 단점에 대해서 말씀드리겠습니다.

XSS 공격에 대한 취약성입니다. XSS 공격은 악성 스크립트를 웹 페이지에 삽입해 사용자의 브라우저에서 실행되도록 하는 공격 방식입니다. JWT 토큰이 클라이언트 측의 로컬 스토리지나 세션 스토리지에 저장되면, 악의적인 스크립트가 삽입될 경우 XSS 공격에 의해 JWT가 탈취될 수 있으며, 이렇게 탈취된 토큰을 공격자가 사용할 수 있습니다.
CSRF 공격에 대한 취약성입니다. CSRF 공격은 신뢰할 수 있는 사이트에서 사용자의 인증이 되어있을 때 사용자의 웹 브라우저가 악의적인 웹사이트나 이메일, 메시지 등에 의해 원치않는 action을 수행하는 공격입니다. 이러한 공격은 웹 브라우저의 request가 자동적으로 세션 쿠키를 포함한 모든 쿠키를 자동적으로 포함하기 때문에 발생합니다. JWT를 쿠키에 저장할 경우, 요청 시 자동으로 포함되기 때문에 CSRF 공격에 취약할 수 있습니다.
토큰의 크기 문제입니다. JWT는 헤더, 페이로드, 서명을 포함하기 때문에 상대적으로 크기가 커 요청 시 매번 전송해야 할 데이터량이 많아질 수 있습니다. 이는 네트워크 대역폭을 낭비하게 됩니다.
정보를 수정할 수 없습니다. JWT는 서명된 토큰으로 발급 후에 내용을 수정할 수 없습니다. 사용자 정보가 변경되면 새로운 JWT를 발급받아야 하며, 추가적인 서버 자원 소모를 유발할 수 있습니다
탈취 시 접근 허용 JWT가 탈취당하면 해당 토큰을 사용하여 공격자가 인증된 사용자로 서버에 접근할 수 있다는 문제가 생깁니다. 특히 JWT는 서버에서 상태를 유지하지 않기 때문에, 토큰 자체를 검증하는 방식으로 작동하며, 탈취된 토큰이 만료되기 전까지는 이를 무효화하기 어렵습니다. 따라서, 탈취된 JWT는 만료 시점까지 악용될 수 있으며, 이를 방지하려면 짧은 만료 시간을 설정하고, 추가로 리프레시 토큰이나 IP 확인 등 보안 조치를 도입하는 것이 필요합니다.

결론적으로 세션 방식의 로그인과 JWT 방식의 로그인 중 하나를 선택할 때에는 사용 환경과 요구 사항에 따라 결정을 해야합니다.

세션 방식은 서버에서 사용자의 세션을 관리하기 때문에, 보다 강력한 보안을 요구하는 상황에 적합하고, 특히 사용자 정보를 서버에 안전하게 저장하고 싶거나, 실시간으로 사용자 세션을 업데이트해야 하는 경우에 유리합니다. 예를 들어 금융 서비스와 같이 사용자의 데이터 보호가 중요한 시스템에서 세션 방식을 사용합니다. JWT 로그인 방식은 서버의 상태를 유지하지 않기 때문에 확장성이 뛰어나고 서버의 부하를 줄일 수 있습니다. MSA 와 같이 분산된 시스템에서는 JWT 방식이 유용할 수 있습니다.

자바 예외란?

Fri, 04 Oct 2024 07:39:09 GMT

예외 계층 그림

Object 모든 객체의 최상의 부모는 Object이다. 예외또한 객체이기 때문에 예외의 최상의 부모도 Object이다.
Throwable 최상위 예외이다. 하위에 Exception과 Error가 있다
Error (언체크 예외) 메모리 부족이나 심각한 시스템 오류와 같이 애플리케이션에서 복구 불가능한 시스템 예외이다. 애플리케이션 개발자는 이 예외를 잡으려고 해서는 안된다 그렇기 때문에 상위 예외를 catch로 잡으면 그 하위 예외까지 함께 잡기 때문에 Throwable 예외를 catch하면 안되고 Exception 부터 필요한 예외로 생각하고 잡아야한다
Exception (체크 예외) 애플리케이션 로직에서 사용할 수 있는 실질적인 최상위 예외이다. RuntimeException을 제외하고 Exception과 그 하위 예외는 모두 컴파일러가 체크하는 체크 예외이다
RuntimeException (언체크 예외) 컴파일러가 체크 하지 않는 언체크 예외이다

예외 기본 규칙

예외는 폭탄 돌리기로 이해하면 된다. 잡아서 처리하거나, 처리할 수 없으면 밖으로 던져야한다.

위의 그림과 같이 예외를 처리하지 못하면 호출한 곳으로 예외를 계속 던지게 된다

추가로 예외를 잡거나 던질 때 지정한 예외뿐만 아니라 그 예외의 자식들도 함께 처리된다

그러면 여기서 예외를 처리하지 못하면 밖으로 던지면 된다고 했는데 계속해서 처리하지 못하고 던지게 된다면 자바 main() 쓰레드의 경우 예외 로그를 출력하면서 시스템이 종료된다

웹 애플리케이션의 경우 여러 사용자의 요청을 처리하기 때문에 하나의 예외 때문에 시스템이 종료되면 안된다. 이럴때 WAS가 해당 예외를 받아서 사용자에게 개발자가 지정한 오류 페이지를 보여주는 식의 처리를 한다

체크 예외

Exception과 그 하위 예외는 모두 컴파일러가 체크하는 체크 예외이다. 물론 RuntimeException은 언체크 예외이다.

체크 예외는 잡아서 처리하거나, 또는 밖으로 던지도록 선언해야한다

/**
* 예외를 잡아서 처리하는 코드 */
         public void callCatch() {
             try {
                 repository.call();
             } catch (MyCheckedException e) {
//예외 처리 로직
log.info("예외 처리, message={}", e.getMessage(), e); }
}

/**
* 체크 예외를 밖으로 던지는 코드
* 체크 예외는 예외를 잡지 않고 밖으로 던지려면 throws 예외를 메서드에 필수로 선언해야한다. */
         public void callThrow() throws MyCheckedException {
             repository.call();
} }
     static class Repository {
         public void call() throws MyCheckedException {
             throw new MyCheckedException("ex");
         }
}

체크 예외의 장단점

체크 예외는 예외를 잡아서 처리할 수 없을 때, 예외를 밖으로 던지는 throws 예외를 필수로 선언해야 한다. 그렇지 않으면 컴파일 오류가 발생한다.

장점

개발자가 실수로 예외를 누락하지 않도록 컴파일러를 통해 문제를 잡아주는 안전 장치이다

단점

실제로는 개발자가 모든 체크 예외를 잡거나 던지도록 처리해야 하기 때문에, 너무 번거로운 일이 되며 크게 신경쓰고 싶지 않은 예외까지 모두 챙겨야 한다.

언체크 예외

RuntimeException과 그 하위 예외는 언체크 예외로 분류된다 언체크 예외는 말 그대로 컴파일러가 예외를 체크하지 않는다. 체크 예외와의 차이점은 예외를 던지는 throws를 선언하지 않고 생략할 수 있다. 이 경우에는 자동으로 예외를 던진다.

 try {
     repository.call();
} catch (MyUncheckedException e) { //예외 처리 로직
     log.info("error", e);
 }

언체크 예외도 필요한 경우에는 catch를 사용해서 처리할 수 있다

  public void callThrow() {
     repository.call();
}

체크 예외와는 다르게 throws 예외를 선언하지 않아도 된다

언체크 예외의 장단점

언체크 예외는 예외를 잡아서 처리할 수 없을 때, 예외를 밖으로 던지는 throws 예외를 생략할 수 있다.

장점

신경쓰고 싶지 않은 예외를 무시할 수 있다. 체크 예외의 경우 처리할 수 없는 예외를 밖으로 던지려면 항상 throws 예외를 선언해야 하지만, 언체크 예외는 이 부분을 생략할 수 있다

단점

개발자가 실수로 예외를 누락할 수 있다.

그렇다면 언제 체크 예외를 사용하고 언제 언체크 예외를 사용하면 될까??

그 답은 2가지의 원칙을 확인해보면된다.

기본적으로 언체크 예외를 사용하자!!
체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용하자!!
- 이 경우 해당 예외를 잡아서 반드시 처리해야 하는 문제일 때만 체크 예외를 사용해야한다

이 원칙에 의문이 들 수가 있다. 물론 체크 예외는 필수로 throws 예외를 선언해야 하기 때문에 개발자 입장에서 귀찮을 수 있지만 언체크 예외에 비해 더 안전해보이는데 왜 기본적으로 언체크 예외를 사용해야하는지 의문이 드는 것이 당연하다.

위의 그림을 바탕으로 그 이유를 설명해보도록 하겠다.

리포지토리는 DB에 접근해서 데이터를 저장하고 관리한다. 여기서는 SQLException 체크 예외를 던진다
NetworkClient는 외부 네트워크에 접속해서 어떤 기능을 처리하는 객체이다. 여기서는 ConnectionException 체크 예외를 던진다
서비스는 리포지토리와 NetworkClient 둘 다 호출한다
- 따라서 두 곳에서 올라오는 체크 예외 두개를 처리해야 한다. 그러나 서비스는 ConnectException처럼 연결이 실패하거나, SQLException처럼 데잍머베이스에서 발생하는 문제들과 같이 심각한 문제들은 대부분 애플리케이션 로직에서 처리할 방법이 없다
서비스는 SQLException과 ConnectException을 처리할 수 없으므로 둘 다 밖으로 던진다 둘 다 체크 예외이기 때문에 method() throws SQLException, ConnectException과 같이 선언해야한다.
서비스와 마찬가지로 컨트롤러도 두 예외를 처리할 수 없기 때문에 method() throws SQLException, ConnectException과 과 같이 선언해야한다.
웹 애플리케이션이라면 서블릿의 오류 페이지나 또는 스프링 MVC가 제공하는 ControllerAdvice에서 이런 예외를 공통으로 처리한다.
추가로 이런 Exception을 처리할 때에는 사용자에게 어떤 문제가 발생했는지 자세히 설명하기 어렵기 때문에 "서비스에 문제가 있습니다"와 같이 일반적인 메시지를 보여준다

위에서 설명한 내용을 보면 체크 예외의 2가지 문제점을 알 수 있다

복구 불가능한 예외
의존 관계에 대한 문제

1. 복구 불가능한 예외

대부분의 예외는 복구가 불가능하다. 일부 복구가 가능한 예외도 있지만 아주 적다 SQLException을 예로 들면 데이터베이스에 문제가 있어서 발생하는 예외이다. SQL 문법에 문제가 있을 수도 있고, 데이터베이스 자체에 문제가 발생했을 수도 있다. 대부분의 서비스나 컨트롤러는 이러한 문제들을 해결할 수 없다. 따라서 이런 문제들은 일관성 있게 공통으로 처리해야 한다. 오류 로그를 남기고 개발자가 해당 오류를 빠르게 인지하는 것이 필요하다. 서블릿 필터, 스프링 인터셉터, 스프링의 ControllerAdvice를 사용하면 이런 부분을 깔끔하게 공통으로 해결할 수 있다

2. 의존 관계에 대한 문제

체크 예외의 또 다른 문제는 예외에 대한 의존 관계 문제이다 앞서 대부분의 예외는 복구 불가능한 예외라고 했다. 그런데 체크 예외이기 때문에 컨트롤러나 서비스 입장에서는 본인이 처리할 수 없어도 어쩔 수 없이 throws를 통해 던지는 예외를 선언해야 한다

그런데 여기서 예외를 던지는 것이 문제인 이유는 바로 서비스, 컨트롤러에서 java.sql.SQLException을 의존하기 때문에 문제가 된다

그로인해 OCP, DI를 통해 클라이언트 코드의 변경 없이 대상 구현체를 변경할 수 있다는 장점이 체크 예외 때문에 발목을 잡히게 된다.

언체크 예외 활용

SQLException을 런타임 예외인 RuntimeSQLException으로 변환하고 ConnectException 대신에 RuntimeConnectException을 사용하도록 바꿀 수 있다

static class Repository {
    public void call() {
        try {
            runSQL();
        } catch (SQLException e) {
            throw new RuntimeSQLException(e);
} }

리포지토리에서 체크 예외인 SQLException이 발생하면 런타임 예외인 RuntimeSQLException으로 전환해서 예외를 던진다 이런식으로 체크 예외 대신에 언체크 예외를 던지게 해주면 서비스나 컨트롤러가 이런 복구 불가능한 예외를 신경쓰지 않아도 된다.

런타임 예외를 사용하면 중간에 기술이 변경되어도 해당 예외를 사용하지 않는 컨트롤러, 서비스에서는 코드를 변경하지 않아도 된다. 구현 기술이 변경되는 경우 예외를 공통으로 처리하는 곳에서는 예외에 따른 처리가 필요할 수 있다. 하지만 공통 처리하는 한곳만 변경하면 되기 때문에 변경의 영향 범위는 최소화된다

 public void call() {
     try {
         runSQL();
     } catch (SQLException e) {
throw new RuntimeSQLException(e); //기존 예외(e) 포함 }
}

추가로 이런식으로 언체크 예외로 throw를 할 떄에는 기존 예외를 포함해줘야한다.

체크 예외와 인터페이스

서비스 계층은 가급적 특정 구현 기술에 의존하지 않고, 순수하게 유지하는 것이 좋다. 이렇게 하려면 예외에 대한 의존도 함께 해결해야한다. 예를 들어서 SQLException에 대한 의존을 제거하려면 런타임 예외로 전환해서 언체크 예외로 전환해 해당 예외를 무시하면서 특정 구현 기술에 의존하는 부분을 제거하고 서비스 계층을 순수하게 유지하면된다

catch (SQLException e) {
     throw new MyDbException(e);
}

위와 같이 체크 예외를 런타임 예외로 변환하면 인터페이스와 서비스 계층의 순수성을 유지할 수 있다 덕분에 향후 JDBC나 JPA로 변경하더라도 서비스 계층의 코드를 변경하지 않고 유지할 수 있다

이럴때 특정 상황에서는 예외를 잡아서 복구를 하고싶을 때가 있다 그럴때는 데이터 접근 예외를 직접 만들면된다.

예를 들어서 회원 가입시 DB에 이미 같은 ID가 있으면 ID 뒤에 숫자를 붙여서 새로운 ID를 만들어야하는 상황이다. 이런 상황에서 JDBC 드라이버는 SQLException을 던지고 이 예외에는 데이터베이스가 제공하는 errorCode가 존재한다

e.getErrorCode() == 23505

서비스 계층에서는 예외 복구를 위해 키 중복 오류 코드를 확인할 수 있어야한다. 하지만 SQLException을 그대로 서비스 계층으로 던지면 서비스 계층이 JDBC 기술에 의존하게 된다. 그렇게 때문에 위에 작성한 것과 같이 리포지토리에서 예외를 변환해서 던져야 한다.

public class MyDuplicateKeyException extends MyDbException {
    public MyDuplicateKeyException() {
}
    public MyDuplicateKeyException(String message) {
        super(message);
}
    public MyDuplicateKeyException(String message, Throwable cause) {
        super(message, cause);
}
    public MyDuplicateKeyException(Throwable cause) {
        super(cause);
} }

} catch (SQLException e) {
     //h2 db
     if (e.getErrorCode() == 23505) {
         throw new MyDuplicateKeyException(e);
}
     throw new MyDbException(e);
 }

위와 같이 오류 코드를 확인해서 오류 코드가 키 중복 오류(23505)인 경우에 MyDuplicateKeyException을 새로 만들어서 서비스 계층에 던지면 된다

 try {
     repository.save(new Member(memberId, 0));
     log.info("saveId={}", memberId);
} catch (MyDuplicateKeyException e) { log.info("키 중복, 복구 시도");
String retryId = generateNewId(memberId); log.info("retryId={}", retryId); repository.save(new Member(retryId, 0));
} catch (MyDbException e) { log.info("데이터 접근 계층 예외", e); throw e;
}

그렇게 하면 MyDuplicateKeyException을 catch해서 memberId에 추가적인 숫자를 더하는 로직을 실행할 수 있다

그런데 여기서 추가로 발생하는 문제점은 SQL ErrorCode는 각각의 데이터베이스마다 다르다. 결과적으로 데이터베이스가 변경될 때마다 ErrorCode를 모두 변경해야 한다.

이 문제점을 해결하기 위해서는 데이터 접근과 관련된 예외를 추상화해서 제공해야한다.

스프링 데이터 접근 예외 계층

스프링은 데이터 접근 계층에 대한 수십 가지 예외를 정리해서 일관된 예외 계층을 제공한다 각각의 예외는 특정 기술에 종속적이지 않게 설계되어 있다. 따라서 서비스 계층에서도 스프링이 제공하는 예외를 사용하면 된다.

JDBC나 JPA를 사용할 때 발생하는 예외를 스프링이 제공하는 예외로 변환해주는 역할도 스프링이 제공한다

스프링이 제공하는 예외 변환기

 @Test
 void exceptionTranslator() {
     String sql = "select bad grammar";
     try {
         Connection con = dataSource.getConnection();
         PreparedStatement stmt = con.prepareStatement(sql);
         stmt.executeQuery();
     } catch (SQLException e) {
         assertThat(e.getErrorCode()).isEqualTo(42122);
         //org.springframework.jdbc.support.sql-error-codes.xml
         SQLExceptionTranslator exTranslator = new
 SQLErrorCodeSQLExceptionTranslator(dataSource);
         //org.springframework.jdbc.BadSqlGrammarException
         DataAccessException resultEx = exTranslator.translate("select", sql, e);
         log.info("resultEx", resultEx);
         assertThat(resultEx.getClass()).isEqualTo(BadSqlGrammarException.class);
} }

SQLExceptionTranslator exTranslator = new
 SQLErrorCodeSQLExceptionTranslator(dataSource);
DataAccessException resultEx = exTranslator.translate("select", sql, e);

translate() 메서드의 첫번째 파라미터는 읽을 수 있는 설명이고, 두번째는 실행한 sql, 마지막은 발생된 발생한 SQLException을 전달하면 된다.

이번 글에서 스프링에서 예외처리를 어떤식으로 해야하는지, 왜 해야 하는지, 체크 예외와, 언체크 예외가 무엇이지 등을 작성해봤다.

작성을 하면서도 아직 모르는 개념들이 많다는 생각이 들었고 헷갈리기까지 한다. 프로젝트를 진행하면서 체크 예외와 언체크 예외를 구분해서 생각을 해본 적이 없는데 앞으로는 아 이 예외는 체크 예외이기때문에 언체크 예외로 전환을 해줘야 되겠구나, 이 예외는 체크 예외로 해야겠구나 등을 생각하면서 진행해야 익숙해질 것 같다

DB SIDU와 인덱스와 VIEW

Thu, 03 Oct 2024 09:01:07 GMT

데이터 입력 - INSERT

CREATE TABLE 직후에는 아무런 행도 없는 상태이다. 그 후에 INSERT를 사용해서 DB를 삽입한다

INSERT INTO 테이블이름 VALUES (값1, 값2, 값3, ...);

INSERT를 실행할 떄에는 NOT NULL이 걸린 필드나 외래키 참조 상황인 필드를 고려해서 INSERT를 실행해야 한다.

데이터 조회 - SELECT

SELECT의 순서

SELECT 컬럼 FROM 테이블 WHERE 조건 GROUP BY 그룹화할_컬럼 HAVING 필터_조건 ORDER BY 정렬할_컬럼 ;

연산 및 집계함수

COUNT: SELECT COUNT(*) FROM products;
SUM: SELECT SUM(price) FROM products;
AVG: SELECT AVG(price) FROM products;
MAX: SELECT MAX(price) FROM products;
MIN: SELECT MIN(price) FROM products;

LIKE를 이용한 패턴 검색

WHERE를 이용해서 조건 검색을 하기 위해서는 문자열이 완전하게 일치해야 한다.

SELECT name FROM products WHERE name = 'monitor';

그러나 LIKE를 사용하면 부분적 일치로도 검색을 할 수 있다. 사용 가능한 와일드 카드는 %, _ 두 가지이다. %는 임의의 문자열을 뜻하고 _는 하나의 임의의 문자를 뜻한다

SELECT name FROM products WHERE name LIKE '_onitor'; SELECT name FROM products WHERE name LIKE '%monitor';

GROUP BY & HAVING

SELECT 컬럼 FROM 테이블 WHERE 조건 GROUP BY 그룹화할_컬럼 HAVING 필터_조건 ORDER BY 정렬할_컬럼 ;

테이블 내 데이터를 그룹으로 묶어 조회하고 싶을 때, 주로 집계 함수와 함께 사용한다 HAVING을 상요해서 그룹화한 결과를 필터링 할 수 있다.

서브 쿼리

서브 쿼리란 퀴리 속의 select이다.

데디터 수정 - UPDATE

UPDATE를 사용해서 데이터의 수정을 할 수 있다.

UPDATE 테이블 SET 열=값, 열=값 [WHERE 조건식];

where를 이용해서 특정 행일 식별해 조건에 일치하는 모든 행을 대상으로 업데이트한다. where가 생략된 경우 모든 행이 갱신을 하며 set에 사용된 =는 대입 연산자이다.

참조 시 UPDATE(on update)

cascade: 참조 데이터 업데이트 시 상대방 데이터도 함께 업데이트
set null: 참조 데이터 업데이트 시 상대방 테이블의 참조 컬럼을 NULL로 업데이트
set default: 참조 데이터 업데이트 시 상대방 테이블의 참조 컬럼을 Default 값으로 업데이트
restrict: 참조하고 있을 경우, 업데이트 불가
no Action: Restrict와 동일, 옵션을 지정하지 않았을 경우에 자동으로 선택

데이터 삭제 -DELET

조건에 맞는 데이터 삭제

DELETE FROM 테이블명 WHERE 조건식;

테이블의 모든 데이터 삭제

DELETE FROM 테이블명;

참조 시 DELETE(on delete)

cascade: 참조 데이터 업데이트 시 상대방 데이터도 함께 삭제
set null: 참조 데이터 업데이트 시 상대방 테이블의 참조 컬럼을 NULL로 업데이트
set default: 참조 데이터 업데이트 시 상대방 테이블의 참조 컬럼을 Default 값으로 업데이트
restrict: 참조하고 있을 경우, 삭제 불가
no Action: Restrict와 동일, 옵션을 지정하지 않았을 경우에 자동으로 선택

인덱스

인덱스란 테이블을 더 빠르게 조회하기 위한 참조 수단으로 실무에서 검색 속도를 향상시키기 위해서 빈번히 사용한다.

이미지와 같이 인덱스는 열 단위로 사용한다

인덱스가 없다면 데이터를 찾기 위해서 모든 테이블의 데이터를 스캔해야한다.

인덱스의 부작용

인덱스를 저장할 추가적인 저장 공간이 필요하다
인덱스를 작성할 때 시간이 사용된다.
SELECT가 아닌 INSERT, UPDATE, DELETE 시 성능이 악화된다

인덱스의 종류

클러스터형 인덱스
보조 인덱스

클러스터형 인덱스 (Clustered index)

PRIMARY KEY (우선 지정) / UNIQUE + NOT NULL 제약 조건 지정 시 자동으로 생성된다. 테이블 당 하나이며 행 데이터가 인덱스로 지정된 데이터에 대해 자동 정렬된다.

select 했을 때 primary key에 대해 자동 정렬되는 이유이다

보조 인덱스 (Secondary index)

테이블 당 여러 개가 사용 가능하며 중복이 가능하다 고유키로 지정된 컬럼은 자동으로 보조 인덱스가 생성되며 행 데이터가 인덱스로 지정된 데이터에 대해 자동으로 정렬되지 않는다

보조 인덱스 생성 CREEATE INDEX 인덱스명 ON 테이블명;

인덱스 조회 SHOW INDEX FROM 테이블명;

인덱스 삭제 DROP INDEX 인덱스명 FROM 테이블명;

VIEW

뷰란 가상의 테이블로 SELECT의 결과를 마치 테이블과 같이 간주한 것이다. VIEW로 인해 쿼리를 단순화할 수 있고 모든 데이터를 보여줄 필요가 없어진다

뷰 생성 USE VIEW 뷰이름 AS SELECT;

뷰 삭제 DROP VIEW 뷰이름;

뷰를 조회하는 것은 제한이 없지만 삽입, 수정, 삭제 등은 제약이 있을 수도 있다

JOIN

JOIN이란 관계형 데이터베이스의 핵심으로 여러 개의 테이블을 하나로 묶는 방법이다.

JOIN의 종류에는 INNER JOIN, (LEFT, RIGHT, FULL) OUTER JOIN 이 있다.

INNER JOIN

SELECT 열명 FROM 테이블명1 INNER JOIN 테이블명2 ON 결합조건 테이블명 1과 테이블명 2 결합 조건을 모두 만족하는 데이터만을 선택해 결합(교집합)

LEFT OUTER JOIN

테이블 1을 모두 선택하고 테이블2를 합치되 매칭되지 않으면 NULL

RIGHT OUTER JOIN

테이블 2를 모두 선택하고, 테이블1를 합치되 매칭되지 않으면 NULL

FULL OUTER JOIN

두 테이블 모두 선택하고 매칭되지 않으면 NULL

oAuth 2.0 jwt

Tue, 01 Oct 2024 08:40:58 GMT

이번 게시글은 개발을 하는 도중에 Spring OAuth 2.0 을 jwt 방식으로 사용하면서 겪은 시행착오에 대해서 작성하려고 한다.

우선 사용자의 인증과 인가를 처리할 때 쿠키 방식, 세션 방식, JWT 토큰 방식의 차이점에 대해서 말해보겠다

쿠키 VS 세션 VS JWT

쿠키 인증 방식

쿠키 인증 방식은 쿠키에 사용자의 인증 정보를 담아서 인증하는 방식으로 클라이언트가 인증 정보를 관리한다

대략적인 흐름은

클라이언트가 서버에 첫 로그인 인증 요청을 보내면, 서버에서 응답으로 쿠키에 사용자 인증 정보를 담아서 보낸다
서버에서 응답한 쿠키를 클라이언트에서 저장하고, 인증/인가 요청 시마다 서버로 요청한다

흐름이 간단해보이는 것처럼 인증/인가 작업이 가장 쉽고 간단하다. 사용자의 인증 정보를 클라이언트가 관리하기 때문에 서버 부하가 적고, 인증 상태를 서버가 관리하지 않고 매번 클라이언트의 인증 정보를 담은 쿠키의 요청을 받을 때 처리하므로 Stateless 하다.

그러나 인증/인가 작업이 간단한 만큼 가장 치명적인 단점이 존재한다

클라이언트 즉 사용자가 쉽게 쿠키에 담긴 인증 정보를 위조할 수 있다
쿠키의 데이터 크기가 제한적이고, 또 크키가 커진다면 네트워크 부하가 심해진다

CSRF, XSS 공격등에 매우 취약하기 때문에 3가지의 인증/인가 방법 중에서 가장 기초적이고 사용하지 않는 방식이다

세션 인증 방식

다음으로는 세션 인증 방식이다. 세션 인증 방식은 세션으로 사용자의 인증 정보를 관리하는 방식이다

대략적인 인증/인가 방식은 아래와 같다

클라이언트가 서버에 첫 로그인 요청을 보내면, 서버에서 인증 정보를 저장하고 SessionID를 클라이언트에게 제공한다
서버에서 받은 SessionId로 서버에게 인증, 인가 요청을 해서 서버에서 SessionID에 해당하는 인증 정보로 인증/인가를 처리한다

쿠키 인증 방식과는 다르게 사용자의 인증 정보를 클라이언트가 아닌 서버가 관리한다. 그렇기 때문에 보안상 훨씬 안전하다 추가로 세션의 장점은

한 사용자의 디바이스별 인증을 관리할 수 있다
하나의 계정 공유를 관리할 수 있다
비정상적인 접근 신고가 들어오면, 서버에서 판단하여 해당 세션을 삭제해서 바로 로그아웃시킬 수 있다

여기서 서버가 사용자 인증 정보를 관리하는 곳에 따라서도 장단점이 나뉜다. 크게 메모리, 하드디스크, DB에서 사용자의 인증 정보를 관리한다.

메모리 영역에서 사용자의 인증 정보를 관리하게 되면, 속도가 하드디스크나 DB에서 관리하는 것에 비해 빠르지만 사용자가 동시에 SessionId로 인증 요청을 많이 보내게 되면 서버 메모리가 부족해지고, 서버를 껐다 켰을 때 Session 정보가 휘발된다는 치명적인 단점이 존재한다

하드디스크에서 관리하게되면 메모리에서보다는 속도가 느리지만 DB보다는 빠르다 그리고 발생하는 문제점은 메모리도 마찬가지지만

Scale-out을 사용해서 서버가 여러 대 존재하여 로드 밸런싱을 사용할 때 한 사용자가 로그인 후 다음 인가 요청 시 로드 밸런싱으로 인해 사용자가 로그인한 서버가 아닌 다른 서버로 요청이 보내지면 다시 재로그인 필요하다.

한마디로 사용하는 서버가 여러개일때에는 인증 요청과 인가 요청 대상 서버가 달라지면 재로그인을 해야 한다는 것이다.

마지막으로 서버DB에서 사용자 인증 정보를 관리하는 방식이 있다 속도는 가장 느리지만 위에서 말한 단점들을 모두 해결할 수 있다 그렇기 때문에 세션으로 인증/인가를 진행을 해야한다면 서버 DB에 사용자 인증 정보를 관리하는 것이 가장 효율적이다.

단점은 로그인한 모든 유저의 인증 정보를 DB에 관리해야하므로 무겁고, 매 인증마다 DB를 거쳐 인증 정보를 Select 해야하므로 연결 비용이 클 수 있다.

JWT 토큰 방식

마지막으로 JWT 토큰 방식에 대해서 설명하겠다. 인증/인가 흐름은 아래와 같다

클라이언트가 서버에 첫 로그인 인증 요청을 보내면, 서버에서 응답으로 Token을 담아서 보낸다
서버에서 응답한 Token을 클라이언트에서 저장하고, 인증/인가 요청 시마다 서버로 요청한다

이것만 들으면 기본적으로 클라이언트가 인증 정보를 관리하기 때문에 쿠키 인증 방식과 뭐가 다르지?라는 생각이 나는 처음에 들었다. 하지만 좀 더 알아보니 차이점은 쿠키가 아닌 JWT 토큰을 매개체로 인증한다는 것과 서버에서 토큰 검증이 이루어지는 것이 쿠키에 비해서 보안적으로 안전하게 관리될 수 있는 차이점이다.

JWT는 사용자의 인증 정보와 서버의 SecretKey로 이루어져 서버가 생성한 Token이기 때문에 요청으로 온 Token이 서버에서 발급한 Token인지 검증할 때 Token의 SecretKey가 다르다면 위조, 변조된 Token이라고 판단할 수 있다

세션 방식과 비교해서는 기본적으로 클라이언트가 Token을 관리하기 때문에 서버 부하가 비교적 적다. 단점은 보안이 세션 방식 보다는 취약하고 세션 방식의 여러 기능들을 사용할 수 없다는 단점이 존재했다.

나는 현재 프로젝트에서 JWT 토큰 방식을 사용하고 있다

그래서 내가 JWT 토큰을 사용하면서 겪었던 고민을 말해보겠다 그러기 전에 우선 Access Token과 Refresh Token이 뭔지 알아야한다.

Access, Refresh Token

Jwt 토큰은 유저의 신원이나 권한을 결정하는 정보를 담고 있는 데이터 조각이기 때문에 탈취를 당했을 때 Jwt 토큰을 탈취한 사람은 마치 신뢰할만한 사람인 것처럼 인증을 통과할 수 있고, 클라이언트와 탈취한 사람을 서버는 구분할 수 없기 때문에 최소한의 대비책으로 유효기간을 필수로 두어야한다.

그런데 유효기간을 짧게 두면 사용자가 로그인을 자주 해야하기 때문에 사용자 경험적으로 좋지 않고, 유효기간을 길게 두면 보안상 탈취 위험에서 벗어날 수 없다.

그래서 나온 개념이 Access Token과 Refresh Token이다.

보통 Access Token의 유효기간은 1시간에서 60일 정도로 정해진 기간은 없지만 비교적 짧게 설정이 되고, Refresh Token의 유효기간은 몇 십일에서 1년 정도를 길게 설정한다. 평소에 API와 통신할 때에는 Access Token을 사용하고, Refresh Token은 Access Token이 만료되었을 때 갱신을 하기 위해서 사용한다.

서버-클라이언트 통신 과정

좀 더 구체적으로 서버와 클라이언트가 JWT토큰을 이용해서 통신하는 과정을 말해주겠다

로그인 인증에 성공한 클라이언트는 Refresh Token과 Access Token을 서버로부터 받는다
클라이언트는 Refresh Token과 Access Token을 로컬에 저장해놓는다.
클라이언트는 헤더에 Access Token을 넣고 API 통신을 한다 (Authorization)
일정 기간이 지나 Access Token의 유효기간이 만료가된다. 4.1 Access Token은 이제 유효하지 않기 때문에 권한이 없는 사용자가 된다 4.2 클라이언트로부터 유효기간이 지난 Access Token을 받은 서버는 401 Unauthorized 에러 코드로 응답한다 4.3 401 에러코드를 통해 클라이언트는 토큰의 유효기간이 만료되었음을 알 수 있다
헤더에 Access Token 대신 Refresh Token을 넣어서 API를 재요청한다
Refresh Token으로 사용자의 권한을 확인한 서버는 응답쿼리 헤더에 새로운 Access Token을 넣어서 응답한다
만약 Refresh Token도 만료되었다면 서버는 동일하게 401 errorCode를 보내고 클라이언트는 재로그인해야한다.

그렇기 때문에 탈취자가 통신이 빈번히 일어나는 Access Token을 탈취를 하더라도 유효기간이 짧기 때문에 보안을 높일 수 있는 대안이 되는것이다

내가 여기서 고민했던 점는 Access Token과 Refresh Token에 어떤 정보를 담아서 만들어야 하고, 어디에 저장을 어떻게 해야하는지였다.

우선 첫번째 후보는 로컬 스토리지 & 세션 스토리지 였다. 그러나 이렇게 저장한다면 자바스크립트로 토큰 값을 꺼내서 보내는 방식이기 때문에 XSS 공격에 취약하기 때문에 적절치 않다고 판단했다. 두번 째 후보는 쿠키이다. 쿠키 또한 자바스크립트로 접근이 가능하지만 HTTP Only 옵션과 secure 옵션을 설정한다면 보안을 높일 수 있지만 CSRF 공격에는 취약할 수 있다. 처음에는 그래도 다른 곳에 저장하는 방식에 비해서는 안전하다고 생각해 Access Token과 Refresh Token을 둘 다 쿠키에 저장을 하려고 했지만 Refresh Token은 사용자의 Access Token을 재발급 하는 용도이기 때문에 괜찮을 수 있지만 Access Token 또한 쿠키에 저장한다면 CSRF 공격을 통해서 인증 인가 과정으로 보호된 동작을 실행해버릴 수 있기 때문에 Refresh Token만 쿠키에 저장하기로 결정했다

그리고 Access Token은 Authorization Header를 통해서 클라이언트에게 전달하기로 했다. 물론 완벽한 보안은 아닐 수 있지만 최소한의 위험만 감수하는 방법이라고 생각한다.

영속성이란?

Sat, 28 Sep 2024 14:10:54 GMT

영속성이란 JPA를 공부하면서 많이 접하게 되는 용어이다. 영속성은 JPA가 제공하는 핵심 개념 중 하나로, 데이터베이스와 자바 애플리케이션 간의 데이터 저장과 관리를 의미한다. 이를 통해서 데이터베이스의 레코드를 자바 객체로 다루면서, 객체 지향적인 방법으로 데이터베이스 조작을 할 수 있게 된다.

JPA에서의 영속성에 대해 주요 개념을 추가로 설명해보겠다.

1. 영속성 컨텍스트

영속성 컨텍스트는 엔티티 객체를 관리하는 일종의 메모리 공간이다. 엔티티 매니저가 이 영속성 컨텍스트를 통해서 엔티티의 상태를 관리한다. 영속성 컨텍스트는 JPA에서 데이터의 일관성을 보장하는 중요한 역할을 하며, 여기서 관리되는 엔티티들은 영속 관계에 놓인다.

영속성 컨텍스트의 장점

1차 캐시: 영속성 컨텍스트는 엔티티를 메모리에 캐시해서 중복 조회를 방지하고 성능을 최적화시켜준다.
변경 감지: 엔티티의 상태가 변경되면 자동으로 감지되어, 트랜잭션이 커밋될 때 자동으로 데이터베이스에 반영된다.
지연 로딩: 필요한 시점에만 데이터베이스에서 데이터를 조회하는 방식으로 성능을 최적화할 수 있다.

2. 엔티티와 영속성

엔티티는 데이터베이스의 테이블과 매핑된 자바 객체로, JPA를 사용하면 이 객체를 통해 테이블의 데이터를 조작한다. JPA는 엔티티의 생명주기를 기반으로 엔티티의 상태를 관리하는데, 이를 통해 영속성과 관련된 여러 상태 변화를 관리할 수 있다

3. 엔티티의 생명주기

JPA에서 엔티티 객체는 네 가지의 생명주기를 가진다.

비영속 상태 Transient 엔티티 객체가 영속성 컨텍스트와 전혀 연과되어 있지 않은 상태이다. 자바 객체로는 존재하지만, 데이터베이스와 연관되어 있지 않은 상태를 말한다. 예를 들어서 new 키워드를 사용해서 새로 생성한 엔티티는 비영속 상태이다.
영속 상태 Persistent 엔티티가 영속성 컨텍스트에 저장된 상태로, 데이터베이스에 반영될 준비가 된 상태이다. 이 상태에서는 영속성 컨텍스트가 엔티티를 관리하며, 자동으로 변경 사항을 데이터베이스에 반영한다. 예를 들어서 entityManager.persist(entity)를 호출하면 엔티티가 영속 상태로 전환된다
준영속 상태 Detached 영속성 컨텍스트에 의해 관리되던 엔티티가 더 이상 관리되지 않는 상태이다. 즉 데이터베이스와의 동기화가 끊긴 상태이다. 예를 들어서 entityManger.detach(entity)를 호출하거나 entityManger.clear()로 전체 컨텍스트를 비울 때 엔티티가 준영속 상태가 된다.
삭제 상태 Removed 마지막 상태로 엔티티가 영속성 컨텍스트에서 삭제되어 데이터베이스에서도 삭제될 준비가 된 상태이다. entityManager.remove(entity) 를 호출하면 엔티티가 상태 상태가 된다.

아마 엔티티의 생명주기를 읽으면서 나는 EntityManager를 직접 사용한적이 없는데 생명주기를 이용안한건가?? 라는 생각을 할 수도 있지만 JPA를 사용한다면 EntityManager를 내부적으로 사용하면서 개발자가 직접 EntityManger를 다루지 않고도 쉽게 JPA의 기능을 활용할 수 있도록 도와준다고 한다.

public interface MemberRepository extends JpaRepository {
    // 기본 CRUD 메서드가 자동으로 제공됨
    Optional findByUsername(String username);
}

예를 들어서 위의 코드에서는 JpaRepository 인터페이스를 상속받기만 하면 자동으로 EntityManager를 사용해서 데이터베이스와 상호작용하는 메서드를 제공하기 때문에 EntityManager를 직접 다룰 필요가 없다

4. 트랜잭션과 영속성

JPA는 트랜잭션을 기반으로 엔티티의 상태를 데이터베이스에 반영한다 트랜잭션이 커밋될 때 영속성 컨텍스트는 모든 변경 사항을 데이터베이스에 적용한다
추가로 트랜잭션 내에서만 엔티티가 영속성 컨텍스트에 의해 관리되므로, 트랜잭션이 끝나면 영속성 컨텍스트도 더 이상 존재하지 않는다

5. 플러시 Flush

Flush는 영속성 컨텍스트에 있는 변경 사항을 데이터베이스에 반영하는 작업을 의미한다. 기본적으로 JPA는 트랜잭션이 커밋되기 전에 플러시를 수행해서 엔티티의 변경사항을 자동으로 데이터베이스에 동기화한다. 개발자가 필요에 따라 flush() 메서드를 호출해서 수동으로 플러시를 할 수도 있다
주의 해야 할점은 플러시는 영속성 컨텍스트의 변경 사항을 데이터베이스에 반영하지만, 트랜잭션을 커밋하지 않으면 그 데이터는 데이터베이스에 반영되지 않고 롤백될 수 있다.

6. 변경 감지 Dirty Checking

변경 감지 즉 Dirty Checking 이란 용어도 개발을 진행하면서 자주 들었지만 어떤 용어인지는 잘 몰랐던 용어인데, JPA가 영속 상태의 엔티티 객체가 변경되었을 때 자동으로 이를 감지하여, 트랜잭션 커밋 시점에 데이터베이스에 업데이트한다. 이러한 로직을 Dirty Checking이라고 한다. 이 과정에서 @Entity 객체의 필드 값이 변경되었는지를 추적한다. Dirty Checking은 성능을 최적화하고 데이터 일관성을 보장하기 위해 매우 중요한 개념이라고 한다

7. Lazy Loading & Eager Loading

Lazy Loading 즉 지연 로딩은 위에서도 언급한 용어인데, 연관된 엔티티나 데이터를 실제로 사용할 때 데이터베이스에서 조회하는 방식이다. 필요하지 않은 데이터를 미리 로드하지 않기 때문에 성능 상의 이점이 있다

Eager Loading 은 즉시 로딩이라고 하는데 연관된 엔티티나 데이터를 즉시 데이터베이스에서 가져오는 방식이다. 기본적으로 모든 관련 엔티티가 함께 로드되기 때문에 성능 저하가 발생할 수 있다

두 개의 용어를 언제 사용하냐면 보통 엔티티 관계에서 @OneToMany 와 @ManyToOne 등의 관계를 설정할 때 많이 사용했다.

그래서 만약에 누군가가 너 JPA에서의 영속성 과 영속성 컨텍스트가 뭐야? 라고 묻는다면

영속성은 데이터를 데이터베이스에 영구적으로 저장되어서 애플리케이션이 종료되더라도 유지되는 것이고, 영속성 컨텍스트란 엔티티 객체를 관리하고 트랜잭션이 진행되는 동안 데이터베이스와의 동기화를 처리하는 메모리 공간이야 정리하자면 영속성 컨텍스트는 애플리케이션이 실행되는 동안만 메모리에서 엔티티 객체를 관리하는 일종의 임시 저장소라 애플리케이션이 종료되면 영속성과 다르게 사라져!!

라고 말할 수 있어야 할 것 같다.

스프링 배치

Thu, 26 Sep 2024 09:16:23 GMT

프로젝트를 진행하면서 일정 시간마다 특정 로직을 실행시켜줘야 하는 경우가 여러 번 있었고 그때마다 나는 @Scheduled(cron = "0 0 12 * * ?") 어노테이션을 사용해서 특정 로직을 일정 시간마다 실행시켜줬다. 그런데 대량의 데이터를 처리하거나 더욱 더 복잡한 비즈니스 로직을 포함한 작업을 효율적으로 실행시키기 위해서는 스프링의 Batch를 사용한다는 글을 봐서 이번 기회에 스케줄러 대신에 배치를 사용해 보기로 했다.

내가 스프링 배치를 사용해보기 전에 우선 스케줄러와 배치의 개념에 대해서 알아보기로 했다.

1. 스케줄러 (Scheduler)

스케줄러의 주된 목적은 특정 시간 간격 또는 일정에 따라 단순 작업을 반복적으로 실행하는 것이다. 사용하는 방법은 위에서 말했듯이 @Scheduled 어노테이션을 사용하면된다.

스케줄러의 특징은

어노테이션 하나만 붙이면 되는만큼 간단하고 빠르게 설정할 수 있다.
주로 짧은 기간 동안 실행되는 작업 즉 짧은 시간 안에 완료되는 작업에 적합하다.
기본적으로 스프링의 TaskScheduler를 사용하며, 멀티스레드로 동작 가능하다
상태 관리가 복잡하지 않고, 트랜잭션 관리나 대규모 데이터 처리에는 부적합하다.

여기서 스프링의 TaskScheduler란 스프링에서 제공하는 스케줄링 인터페이스로, 주기적으로 반복 실행되거나 특정 시간에 실행되는 작업을 관리하는 데 사용된다.

2. 배치 (Batch)

배치의 주된 목적은 위에서 말했듯이 대량의 데이터를 처리하거나 복잡한 비즈니스 로직을 포함한 작업을 효율적으로 실행하는 것이다. 배치의 사용 방법은 Spring Batch를 사용해서 배치 잡(Job), 스텝(Step), 리더(Reader), 프로세서(Processor), 라이터(Writer) 등을 정의해서 작업을 수행한다.

배치의 특징은

대규모 데이터 처리, 트랜잭션 처리, 실패 관리, 체크포인트 등의 기능을 제공한다
병렬 처리나 대량의 데이터 작업, 복잡한 로직을 실행하는 데 적합하다
배치 작업의 흐름(Flow)를 관리하고, 여러 단계(Step)으로 구성할 수 있다
데이터베이스 또는 외부 시스템과의 연동을 통해 데이터를 읽고 쓰는 작업을 쉽게 구현할 수 있다
스케줄러와 결합해서 특정 시간에 배치 작업을 실행하는 것도 가능하다

@Bean
public Job sampleJob() {
    return jobBuilderFactory.get("sampleJob")
        .start(step1())
        .next(step2())
        .build();
}

@Bean
public Step step1() {
    return stepBuilderFactory.get("step1")
        .chunk(10)
        .reader(reader())
        .processor(processor())
        .writer(writer())
        .build();
}

언뜻 봐도 스케줄러에 비해 배치의 난이도가 훨씬 높아 보이긴 하는 것 같다.

스케줄러 VS 배치

결론적으로 스케줄러는 단순하고 주기적으로 수행할 작업을 실행하는 데 적합하며, 배치는 대규모 데이터 처리를 수행하고 복잡한 로직이 필요한 경우에 적합하다. 스케줄러를 사용해 배치 작업을 주기적으로 실행할 수도 있으며, 두 가지 기능을 서로 상호 보완적으로 사용할 수 있다

그럼 내가 작성한 스케줄러를 사용한 코드를 배치와 함께 사용할 수 있도록 리팩토링 해보겠다.

@Slf4j
@RequiredArgsConstructor
@Service
@EnableScheduling
public class MemberScheduled {

    private final MemberRepository memberRepository;

    @Scheduled(cron = "*/10 * * * * *")
    public void deleteMembersFromDb() {
        log.info("Deleting members");
        log.info("삭제 처리 중");

        List deleteMembers = memberRepository.findAllByIsDeletedTrue();

        for (MemberEntity memberEntity : deleteMembers) {
            LocalDateTime lastConnectionAt = memberEntity.getLastConnectionAt();
            if (lastConnectionAt != null) {
                if (ChronoUnit.DAYS.between(lastConnectionAt, LocalDateTime.now()) > 7) {
                    memberRepository.delete(memberEntity);
                    log.info("Delete member: {}", memberEntity.getProviderId());
                }
            }
        }
        log.info("Deleting members");
    }

}

일단 위의 코드는 매일 자정마다 memberRepository에서 isdeleted가 true인 member들 중에 lastConnectionAt이 일주일이 지난 member를 memberRepository에서 삭제하는 스케줄러를 사용한 로직이다. 그래서 이 로직을 배치와 함께 사용하는 것으로 바꿔보기로 했다.

첫번쨰로 전체적인 배치를 설정하는 BatchConfig 클래스를 만들어야 한다

@Configuration
@EnableBatchProcessing
public class BatchConfig {

    @Bean
    public Job deleteMemberJob(Step deleteMemberStep, JobRepository jobRepository) {
        return new JobBuilder("deleteMemberJob", jobRepository)
            .start(deleteMemberStep)
            .build();
    }

    @Bean
    public Step deleteMemberStep(ItemReader reader, ItemProcessor processor,
        ItemWriter writer, JobRepository jobRepository, PlatformTransactionManager transactionManager) {
        return new StepBuilder("deleteMemberStep", jobRepository)
            .chunk(10, transactionManager)
            .reader(reader)
            .processor(processor)
            .writer(writer)
            .build();
    }

    @Bean
    public PlatformTransactionManager transactionManager(EntityManagerFactory entityManagerFactory) {
        return new JpaTransactionManager(entityManagerFactory);
    }
}

우선 @EnableBatchProcessing 어노테이션으로 Spring Batch 기능을 활성화 시켜줘야 한다.

그리고 Job을 설정해야 한다. JobBuilder를 사용해서 배치 작업(Job)을 구성한다. Job은 하나 이상의 Step으로 구성된 전체 배치 작업의 흐름을 정의하는 객체이다.

start(deleteMemberStep) 현재 메소드의 Job이 deleteMemberStep 을 첫 번째 단계로 설정한 것이다.

이 Job은 deleteMemberStep이라는 단일 Step을 실행하며, 회원 삭제 작업을 처리한다.

다음으로 회원 삭제 작업을 처리하는 Step을 설정한다. chunk(10) 이 부분에서 CHunk 기반 처리를 설정한다 즉 ItemReader는 한 번에 10개의 데이터를 읽고, ItemProcessor는 이 10개의 데이터를 처리하며, ItemWriter는 처리된 데이터를 한 번에 10개씩 DB에 반영한다.

그 후 이 Step에서 사용할 itemReader, writer, ItemReader를 지정한다 이 메소드의 Step의 역할은 ItemReader를 사용해서 회원 데이터를 DB에서 읽어오고, ItemProcessor를 사용해서 읽어온 데이터 중에서 조건에 맞는 데이터를 필터링 또는 처리하고 ItemWriter를 사용해 처리된 데이터를 DB에 반영하거나 삭제한다.

다음은 Spring Batch의 ItemReader를 구현한 MemberItemReader 클래스이다. 이 클래스는 삭제 대상 회원의 목록을 읽어 오는 역할을 한다. ItemReader가 배치 작업에서 데이터를 읽는 단계를 담당하며, 그 후에 ItemProcessor와 ItemWriter로 데이터를 전달한다.

즉 MemberRepository를 사용해서 isDeleted가 true로 설정된, 삭제 대상인 회원 목록을 DB에서 가져온 후에 하나씩 반환하며, 더 이상 반환할 데이터가 없으면 null 을 반환하여 읽기 작업을 종료한다.

@Component
public class MemberItemReader implements ItemReader {

    private final MemberRepository memberRepository;
    private List membersToDelete;

    public MemberItemReader(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    @Override
public MemberEntity read() {
    if (membersToDelete == null || membersToDelete.isEmpty()) {
        // 삭제 대상 회원 목록을 DB에서 읽어옴
        membersToDelete = memberRepository.findAllByIsDeletedTrue();
    }
    // 목록이 비어있으면 null을 반환하여 읽기 종료
    return membersToDelete.isEmpty() ? null : membersToDelete.remove(0);
}

다음은 ItemProcessor를 구현한 MemberItemProcessor이다. 회원의 마지막 접속 시간을 확인하고, 7일 이상 접속하지 않은 회원만 다음 단계로 넘기도록 처리하는 역할을 한다

@Component
public class MemberItemProcessor implements ItemProcessor {

    @Override
    public MemberEntity process(MemberEntity memberEntity) throws Exception {
        LocalDateTime lastConnectionAt = memberEntity.getLastConnectionAt();
        if (lastConnectionAt != null && ChronoUnit.DAYS.between(lastConnectionAt, LocalDateTime.now()) > 7) {
            return memberEntity;  // 삭제 대상으로 처리
        }
        return null;  // 처리할 필요 없는 경우 null 리턴
    }
}

ItemProcessor 은 Spring Batch의 핵심 인터페이스 중 하나로, 데이터를 처리하는 역할을 담당한다.

T는 입력 타입으로 MemberEntity 객체가 입력으로 들어온다
R은 출력 타입으로 처리된 후 반환되는 타입이다. 여기서는 다시 MemberEntity 객체를 반환한다. 만약 처리가 필요하지 않은면 null을 반환해서 해당 데이터를 무시할 수 있다

그 후 마지막 처리 작업인 MemberItemWriter 코드이다.

@Component
public class MemberItemWriter implements ItemWriter {

    private final MemberRepository memberRepository;

    public MemberItemWriter(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Override
    public void write(Chunk members) throws Exception {
        for (MemberEntity member : members) {
            if (member != null) {
                memberRepository.delete(member);
            }
        }
    }
}

위의 클래스는 회원 삭제 작업을 수행하는 Writer 역할을 한다. ItemWriter 인터페이스를 구현해서 처리할 회원 데이터를 삭제하는 로직을 정의하고, writer 메서드는 Chunk 단위로 데이터를 받아오며, 여기서 memberRepository.delete()를 통해서 회원 정보를 삭제한다.

여기서 Chunk 단위란 Spring Batch에서 데이터를 읽고, 처리하고, 쓰는 작업을 묶음 단위로 처리하는 방식이다. 즉 데이터를 한 번에 하나씩 처리하는 것이 아니라, 일정한 개수의 데이터 묶음(Chunk)을 만들어서 일괄적으로 처리하는 개념이다.

Spring Batch에서는 Chunk 기반 프로세싱을 통해서 대용량 데이터를 효과적으로 처리한다. 예를 들어서 1000개의 데이터를 처리한다고 할 때, 한 번에 1000개를 처리하는 것이 아니라, 10개씩 묶음으로 나누어 처리하는 방식이다.

마지막으로 현재까지 작성한 MemberItemReader -> MemberItemProcessor -> MemberItemWriter 을 지나 최종 종착역인 BatchScheduler(스케줄러) 코드이다.!

@Configuration
@EnableScheduling
@Slf4j
public class BatchScheduler {

    private final JobLauncher jobLauncher;
    private final Job deleteMemberJob;

    public BatchScheduler(JobLauncher jobLauncher, Job deleteMemberJob) {
        this.jobLauncher = jobLauncher;
        this.deleteMemberJob = deleteMemberJob;
    }

    @Scheduled(cron = "0 0 0 * * ?")
    public void runDeleteMemberJob() {
        log.info("Deleting members");
        try {
            jobLauncher.run(deleteMemberJob, new JobParametersBuilder()
                .addLong("time", System.currentTimeMillis())
                .toJobParameters());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

이 클래스는 스케줄러로 배치 작업을 일정한 주기로 실행한다. JobLauncher는 Spring Batch에서 배치 작업을 실행하는 역할을 담당하는 인터페이스로, JobLauncher는 정의된 배치 작업(Job)을 실행하고, 실행 시 JobParameters를 전달할 수 있다.\

또한 Job deleteMemberJob은 회원 삭제 작업을 정의한 Spring Batch의 Job이다. 이 작업이 스케줄러에 의해 매일 자정에 실행되며 삭제 작업을 수행한다.

여기서 JobParametersBuilder를 사용해서 현재 시간을 파라미터로 전달한다. 파라미터로 전달하는 이유는 매번 배치 작업을 실행할 때 새로운 실행 인스턴스로 관리하기 위함이다.

Spring Batch는 동일한 파라미터로는 새로운 인스턴스를 실행하지 않는다

위의 이유를 더 풀어서 설명하면 Spring Batch는 배치 작업이 중복해서 실행되는 것을 방지하기 위한 메커니즘을 가지고 있다. 예를 들어, 동일한 데이터에 대해 배치 작업을 중복으로 실행하는 경우, 같은 데이터를 여러 번 처리하게 되면 데이터 오류가 발생할 수 있기 떄문이다. 이를 방지하기 위해 Spring Batch는 동일한 JobParameters로 동일한 배치 작업을 여러 번 실행 하지 않도록 설계되었다.

@Configuration
@EnableBatchProcessing
public class BatchConfig {

    @Bean
    public Job deleteMemberJob(Step deleteMemberStep, JobRepository jobRepository) {
        return new JobBuilder("deleteMemberJob", jobRepository)
            .start(deleteMemberStep)
            .build();
    }

    @Bean
    public Step deleteMemberStep(ItemReader reader, ItemProcessor processor,
        ItemWriter writer, JobRepository jobRepository, PlatformTransactionManager transactionManager) {
        return new StepBuilder("deleteMemberStep", jobRepository)
            .chunk(10, transactionManager)
            .reader(reader)
            .processor(processor)
            .writer(writer)
            .build();
    }

    @Bean
    public PlatformTransactionManager transactionManager(EntityManagerFactory entityManagerFactory) {
        return new JpaTransactionManager(entityManagerFactory);
    }
}

지금 여기서 config 파일을 다시 확인해보면 deleteMemberStep에서 reader, processor, writer를 builder 하는 것으로 보아 reader -> processor -> writer 로 데이터를 전송하는 것을 build를 함으로써 해주는 것으로 예상하고 있고,

여러개의 step을 jopRepository에 넣어서 .start(deleteMemberStep)으로 자동화 시키는 것이다.

이렇게 배치를 사용해봤는데 뭔가 스케줄러보다 체계적인 것 같고 동시에 여러 개의 스케줄러를 사용할 수 있을 것 같다. 좋은 시간이었다.

정적 팩토리 메서드란?

Wed, 25 Sep 2024 10:23:08 GMT

Kernel 360에서 파이널 프로젝트를 하던 중 정적 팩토리 메서드라는 단어가 많이 나와서 한 번 정리를 해보도록 했다.

정적 팩토리 메서드는 Static Factory Method로 개발자가 생성자를 호출해서 객체를 생성하는 것 대신에 static 을 사용해서 간접적으로 생성자를 호출해서 생성하는 디자인 패턴이라고 한다.


class Book {
    private String title;

    // 생성자를 private화 하여 외부에서 생성자 호출 차단
    private Book(String title) { this.title = title; }

    // 정적 팩토리 메서드
    public static Book titleOf(String title) {
        return new Book(title); // 메서드에서 생성자를 호출하고 리턴함
    }
}

public static void main(String[] args) {
    // 정적 메서드 호출을 통해 인스턴스화된 객체를 얻음
    Book book1 = Book.titleOf("어린왕자"); 
}

이렇게 생성자 대신에 정적 팩토리 메서드를 통해서 객체를 생성하면 단순히 생성자의 역할을 대신 이행해주는 것 뿐만이 아니라 개발자가 좀 더 가독성 좋은 코드를 작성하고 객체 지향적으로 프로그래밍 할 수 있도록 도와준다.

정적 팩토리 메서드의 특징

생성 목적에 대한 이름 표현이 가능하다

클래스를 설계할 때 다양한 타입의 객체를 생성하기 위해서 생성 목적에 따라 생성자를 오버로딩하여 사용한다. 이렇게 객체를 new 키워드를 통해서 생성하려면 개발자가 해당 생성자의 인자 순서와 내부 구조를 알고 있어야 목적에 맞게 객체를 생성할 수 있다.

예를 들어 코드를 보여주겠다.

class Car {
    private String brand;
    private String color = "black";

    public Car(String brand, String color) {
        this.brand = brand;
        this.color = color;
    }

    public Car(String brand) {
        this.brand = brand;
    }
}

public static void main(String[] args) {
    // 검정색 테슬라 자동차 
    Car teslaCar = new Car("Tesla");

    // 빨간색 BMW 자동차
    Car bmwRedCar = new Car("BMW", "Red");
}

class Car {
    private String brand;
    private String color;

    // private 생성자
    private Car(String brand, String color) {
        this.brand = brand;
        this.color = color;
    }

    // 정적 팩토리 메서드 (매개변수 하나는 from 네이밍)
    public static Car brandBlackFrom(String brand) {
        return new Car(brand, "black");
    }

    // 정적 팩토리 메서드 (매개변수 여러개는 of 네이밍)
    public static Car brandColorOf(String brand, String color) {
        return new Car(brand, color);
    }
}

public static void main(String[] args) {
    // 검정색 테슬라 자동차 
    Car teslaCar = Car.brandBlackFrom("Tesla");

    // 빨간색 BMW 자동차
    Car bmwRedCar = Car.brandColorOf("BMW", "Red");
}

위의 예시와 같이 생성자 대신에 정적 팩토리 메서드를 호출함으로써 생성될 객체의 특성에 대해 쉽게 묘사할 수 있어 가독성을 높여준다. 이 이유가 정적 팩토리 메서드를 사용하는 가장 중요한 이유이며 이외에도 몇 가지 이유가 있다.

인스턴스에 대한 통제 및 관리가 가능하다 메서드를 통해 한단계 거쳐 간접적으로 객체를 생성하기 때문에, 기본적으로 전반적인 객체 생성 및 통제 관리를 할 수 있게 된다. 즉, 필요에 따라 항상 새로운 객체를 생성해서 반환할 수도 있고, 아니면 객체 하나만 만들어두고 이를 공유하여 재사용하게 하여 불필요한 객체를 생성하는 것을 방지 할 수 있다
하위 자료형 객체를 반환할 수 있다.
```
interface SmarPhone {}
```

class Galaxy implements SmarPhone {} class IPhone implements SmarPhone {} class Huawei implements SmarPhone {}

class SmartPhones { public static SmarPhone getSamsungPhone() { return new Galaxy(); }

public static SmarPhone getApplePhone() {
    return new IPhone();
}

public static SmarPhone getChinesePhone() {
    return new Huawei();
}

}

```

위의 코드처럼 클래스의 다형성의 특징을 응용해서 메서드 호출을 통해 얻을 객체의 인스턴스를 자유롭게 선택할 수 있는 유연성을 갖는다.

객체 생성을 캡슐화 할 수 있다. 생성자를 사용하는 경우 외부에 내부 구현을 드러내야 하는데, 정적 팩토리 메서드는 구현부를 외부로부터 숨길 수 있어 캡슐화 및 정보 은닉을 할 수 있다. 또한 노출하지 않는다는 특징은 정보 은닉성을 가지기도 하지만, 동시에 사용하고 있는 구현체를 숨겨 의존성을 제거해주는 장점을 가지고 있다.

API 예외 처리

Sun, 22 Sep 2024 10:55:13 GMT

HTML 페이지의 경우 지금까지 설명했던 것 처럼 4xx, 5xx와 같은 오류 페이지만 있으면 대부분의 문제를 해결할 수 있지만 API의 경우에는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려주어야 한다. 전 작성글의 서블릿 오류 페이지 방식을 사용하면 오류가 발생했을 때 만들어둔 오류 페이지 HTML이 반환된다. 하지만 API의 경우에는 정상 요청이든 오류 요청이든 JSON을 반환해주어야 한다.

 @RequestMapping(value = "/error-page/500", produces =
 MediaType.APPLICATION_JSON_VALUE)
 public ResponseEntity> errorPage500Api(HttpServletRequest
 request, HttpServletResponse response) {
     log.info("API errorPage 500");
     Map result = new HashMap<>();
     Exception ex = (Exception) request.getAttribute(ERROR_EXCEPTION);
     result.put("status", request.getAttribute(ERROR_STATUS_CODE));
     result.put("message", ex.getMessage());
     Integer statusCode = (Integer)
 request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);
     return new ResponseEntity(result, HttpStatus.valueOf(statusCode));
 }

produces = MediaType.APPLICATION_JSON_VALUE의 뜻은 클라이언트가 요청하는 HTTP Header의 Accept의 값이 application/json일 때 해당 메서드가 호출된다는 것이다.

응답 데이터를 위해서 Map을 만들고 status, message키에 값을 할당했다. Jackson 라이브러리는 Map을 JSON 구조로 변환할 . 수있다. ResponseEntity를 사용해서 응답하기 때문에 메시지 컨버터가 동작하면서 클라이언트에 JSON이 반환된다.

스프링 기본 오류 처리

 @RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
 public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse
 response) {}
 @RequestMapping
 public ResponseEntity> error(HttpServletRequest request) {}

/error 동일한 경로를 처리하는 errorHtml(), error() 두 메서드를 확인할 수 있다.

HTML 페이지 vs API 오류

스프링 부트가 제공하는 BasicErrorController는 HTML 페이지를 제공하는 경우에는 매우 편리하다. 그런데 API 오류 처리는 다른 차원의 이야기이다. API마다 각각의 컨트롤러나 예외마다 서로 다른 응답 결과를 출력해줘야 한다. 따라서 API 오류 처리는 @ExceptionHandler를 사용해서 처리해야 한다.

HandlerExceptionResolver

예외가 발생해서 서블릿을 넘어 WAS까지 예외가 전달되면 HTTP 상태코드가 500으로 처리된다. 발생하는 예외에 따라 400, 404 등등 다른 상태코드로 처리할 수 있다.

예를 들어서 IllegalArgumentException을 처리하지 못해서 컨트로럴 밖으로 넘어가는 일이 발생하면 HTTP 상태코드를 400으로 처리하고 싶다.

@GetMapping("/api/members/{id}")
 public MemberDto getMember(@PathVariable("id") String id) {
if (id.equals("ex")) {
throw new RuntimeException("잘못된 사용자");
     }
     if (id.equals("bad")) {
throw new IllegalArgumentException("잘못된 입력 값"); }
     return new MemberDto(id, "hello " + id);
 }

코드를 실행해보면 상태 코드가 500인 것을 확인할 수 있다. WAS입장에서는 서버 내부에서 Exception이 터진 것이기 때문에 상태코드 500이 나오는 것이 맞다.

HandlerExceptionResolver

스프링 MVC는 컨트롤러(핸들러) 밖으로 예외가 던져진 경우 예외를 해결하고, 동작을 새로 정의할 수 있는 방법을 제공한다.

여기서 postHandle()이란 스프링 프레임워크의 인터셉터에서 사용하는 메서드 중 하나로, 클라이언트의 요청을 처리한 후에 실행되는 메서드이다.

클라이언트 요청이 컨트롤러로 전달되고
컨트롤러가 그 요청을 처리한 뒤
뷰에 결과를 보내기 전에 postHandle() 메서드가 호출된다.

이 메서드는 주로 요청이 처리된 이후에 추가적인 작업을 수행할 때 사용된다. postHandle()은 컨트롤러가 정상적으로 요청을 처리한 이후에 실행되는 메서드이기 때문에, 요청 처리 중에 예외가 발생하면 해당 메서드는 호출되지 않는다.

@Slf4j
 public class MyHandlerExceptionResolver implements HandlerExceptionResolver {
@Override
     public ModelAndView resolveException(HttpServletRequest request,
 HttpServletResponse response, Object handler, Exception ex) {
         try {
             if (ex instanceof IllegalArgumentException) {
                 log.info("IllegalArgumentException resolver to 400");
                 response.sendError(HttpServletResponse.SC_BAD_REQUEST,
 ex.getMessage());
                 return new ModelAndView();
             }
         } catch (IOException e) {
             log.error("resolver ex", e);
}
         return null;
     }
}

위의 코드에서는 IllegalArgumentException이 발생하면 response.sendError(400)을 호출해서 HTTP 상태 코드를 400으로 지정하고, 빈 ModelAndView를 반환한다.

여기서 ModelAndView는 스프링 프레임워크에서 컨트롤러가 클라이언트의 요청을 처리한 후에 반환하는 객체로 모델과 뷰 정보를 함께 담고 있다. 즉 ModelAndView는 컨트롤러에서 어떤 데이터를 보여줄지(Model)과 어떤 화면(View)를 보여줄지를 . 한번에 처리하는 객체이다.

반환 값에 따른 동작 방식

빈 ModelAndView: new ModelAndView() 처럼 빈 ModelANdView를 반환하면 뷰를 렌더링 하지 않고, 정상 흐름으로 서블릿이 리턴된다.
ModelAndView 지정: ModelAndView에 View, Model 등의 정보를 지정해서 반환하면 뷰를 렌더링 한다.
null: null를 반환하면, 다음 ExceptionResolver를 찾아서 실행한다. 만약 처리할 수 있는 ExceptionResolver가 없으면 예외 처리가 안되고, 기존에 발생한 예외를 서블릿 밖으로 던진다

ExceptionResolver 활용

예외 상태 코드 변환
- 예외를 response.sendError(xxx) 호출로 변경해서 서블릿에서 상태 코드에 따른 오류를 처리하도 록 위임
- 이후 WAS는 서블릿 오류 페이지를 찾아서 내부 호출, 예를 들어서 스프링 부트가 기본으로 설정한 / error 가 호출됨
뷰 템플릿 처리
- ModelAndView 에 값을 채워서 예외에 따른 새로운 오류 화면 뷰 렌더링 해서 고객에게 제공
API 응답 처리
- response.getWriter().println("hello"); 처럼 HTTP 응답 바디에 직접 데이터를 넣어주는 것도 가능하다. 여기에 JSON 으로 응답하면 API 응답 처리를 할 수 있다.

HandlerExceptionResolver 활용

예외가 발생하면 WAS까지 예외가 던져지고, WAS에서 오류 페이지 정보를 찾아서 다시 /error를 호출하는 과정은 복잡하다. ExceptionResolver를 활용하몀ㄴ 예외가 발생했을 때 이런 복잡한 과정없이 여기에서 문제를 해결할 . 수있다.

public class UserException extends RuntimeException {
     public UserException() {
         super();
}
     public UserException(String message) {
         super(message);
}
     public UserException(String message, Throwable cause) {
         super(message, cause);
}
     public UserException(Throwable cause) {
         super(cause);
}
protected UserException(String message, Throwable cause, boolean
 enableSuppression, boolean writableStackTrace) {
         super(message, cause, enableSuppression, writableStackTrace);
     }
}

@Slf4j
 @RestController
 public class ApiExceptionController {
     @GetMapping("/api/members/{id}")
     public MemberDto getMember(@PathVariable("id") String id) {
if (id.equals("ex")) {
throw new RuntimeException("잘못된 사용자");
         }
         if (id.equals("bad")) {
throw new IllegalArgumentException("잘못된 입력 값"); }
if (id.equals("user-ex")) {
throw new UserException("사용자 오류");
}
         return new MemberDto(id, "hello " + id);
     }
     @Data
     @AllArgsConstructor
     static class MemberDto {
private String memberId;
private String name;
     }
}

/user-ex 호출 시 UserException이 발생하도록 해두었다.

 @Slf4j
 public class UserHandlerExceptionResolver implements HandlerExceptionResolver {
     private final ObjectMapper objectMapper = new ObjectMapper();
@Override
     public ModelAndView resolveException(HttpServletRequest request,
 HttpServletResponse response, Object handler, Exception ex) {
         try {
             if (ex instanceof UserException) {
                 log.info("UserException resolver to 400");
                 String acceptHeader = request.getHeader("accept");
                 response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
                 if ("application/json".equals(acceptHeader)) {
                     Map errorResult = new HashMap<>();
                     errorResult.put("ex", ex.getClass());
                     errorResult.put("message", ex.getMessage());
                     String result =
 objectMapper.writeValueAsString(errorResult);
                     response.setContentType("application/json");
                     response.setCharacterEncoding("utf-8");
                     response.getWriter().write(result);
                     return new ModelAndView();
                 } else {
                     //TEXT/HTML
                     return new ModelAndView("error/400");
                 }
             }
         } catch (IOException e) {
             log.error("resolver ex", e);
         }
         return null;
     }
}

스프링이 제공하는 ExceptionResolver

스프링 부트가 기본으로 제공하는 ExceptionResolver는 다음과 같다. HandlerExceptionResolverComposite에 다음 순서로 등록한다.

ExceptionHandlerExceptionResolver @ExceptionHandler을 처리한다. API 예외 처리는 대부분 . 이기능으로 해결한다.
ResponseStatusExceptionResolver HTTP 상태코드를 지정해준다.
DefaultHandlerExceptionResolver -> 우선 순위가 가장 낮다

ResponseStatusExceptionResolver

예외에 따라서 HTTP 상태 코드를 지정해준다.

 package hello.exception.exception;
 import org.springframework.http.HttpStatus;
 import org.springframework.web.bind.annotation.ResponseStatus;
@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "잘못된 요청 오류") public class BadRequestException extends RuntimeException {
}

@ResponseStatus 어노테이션을 적용하면 HTTP 상태코드를 변경해준다.

ResponseStatusException

@ResponseStatus는 개발자가 직접 변경할 . 수없는 예외에는 적용할 수 없다. 이때에는 ResponseStatusException 예외를 사용하면 된다.

@GetMapping("/api/response-status-ex2")
 public String responseStatusEx2() {
     throw new ResponseStatusException(HttpStatus.NOT_FOUND, "error.bad", new
 IllegalArgumentException());
}

DefaultHandlerExceptionResolver

스프링 내부에서 발생하는 스프링 예외를 해결한다. 대표적으로 파라미터 바인딩 시점에 타입이 맞지 않으면 내부에서 TypeMismatchException 이 발생하는데, 이 경 우 예외가 발생했기 때문에 그냥 두면 서블릿 컨테이너까지 오류가 올라가고, 결과적으로 500 오류가 발생한다. 그런데 파라미터 바인딩은 대부분 클라이언트가 HTTP 요청 정보를 잘못 호출해서 발생하는 문제이다. HTTP 에서는 이런 경우 HTTP 상태 코드 400을 사용하도록 되어 있다. DefaultHandlerExceptionResolver 는 이것을 500 오류가 아니라 HTTP 상태 코드 400 오류로 변경한다. 스프링 내부 오류를 어떻게 처리할지 수 많은 내용이 정의되어 있다.

@ExceptionHandler

API 예외처리의 어려운 점

HandlerExceptionResolver를 떠올려 보면 ModelAndView를 반환해야 했다. 이것은 API 응답에는 필요하지 않다.
API 응답을 위해서 HttpServletResponse에 직접 응답 데이터를 넣어주었다. 이것은 비효율적이다.
특정 컨트롤러에서만 발생하는 예외를 별도로 처리하기 어렵다.

 package hello.exception.exhandler;
 import lombok.AllArgsConstructor;
 import lombok.Data;
 @Data
 @AllArgsConstructor
 public class ErrorResult {
     private String code;
     private String message;
 }

 @Slf4j
 @RestController
 public class ApiExceptionV2Controller {
     @ResponseStatus(HttpStatus.BAD_REQUEST)
     @ExceptionHandler(IllegalArgumentException.class)
     public ErrorResult illegalExHandle(IllegalArgumentException e) {
         log.error("[exceptionHandle] ex", e);
         return new ErrorResult("BAD", e.getMessage());
     }
     @ExceptionHandler
     public ResponseEntity userExHandle(UserException e) {
         log.error("[exceptionHandle] ex", e);
         ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
         return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
         }
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
@ExceptionHandler
public ErrorResult exHandle(Exception e) {
    log.error("[exceptionHandle] ex", e);
return new ErrorResult("EX", "내부 오류"); }
@GetMapping("/api2/members/{id}")
public MemberDto getMember(@PathVariable("id") String id) {
if (id.equals("ex")) {
throw new RuntimeException("잘못된 사용자");
    }
    if (id.equals("bad")) {
throw new IllegalArgumentException("잘못된 입력 값"); }
if (id.equals("user-ex")) {
throw new UserException("사용자 오류");
}
    return new MemberDto(id, "hello " + id);
}
@Data
@AllArgsConstructor
static class MemberDto {
    private String memberId;
    private String name;
}
}

@ExceptionHandler 어노테이션을 선언하고 해당 컨트롤러에서 처리하고 싶은 예외를 지정해주면 된다. 해당 컨트롤러에서 예외가 발생하면 이 메서드가 호출된다. 참고로 지정한 예외 또는 그 예외의 자식 클래스는 모두 잡을 수 있다.

스프링의 우선순위는 항상 자세한 것이 우선권을 가진다. 예를 들어서 부모 자식 클래스가 있고 다음과 같이 예외가 처리된다.

@ExceptionHandler 에 지정한 부모 클래스는 자식 클래스까지 처리할 수 있다. 따라서 자식예외 가 발생하면 부모 예외처리() , 자식예외처리() 둘다 호출 대상이 된다. 그런데 둘 중 더 자세한 것이 우선권을 가지므로 자식예외처리() 가 호출된다. 물론 부모예외 가 호출되면 부모예외처리() 만 호출 대상이 되므로 부모예외처리() 가 호출된다.

실행 흐름

컨트롤러를 호출한 결과 IllegalArgumentException 예외가 컨트롤러 밖으로 던져진다.
예외가 발생했으므로 ExceptionResolver 가 작동한다. 가장 우선순위가 높은 ExceptionHandlerExceptionResolver가 실행된다.
해당 컨트롤러에 IllegalArgumentException을 처리 할 수 있는 @ExceptionHandler가 있는지 확인한다.
illegalExHandle()가 적용된다. 따라서 HTTP 컨버터가 사용되고, 응답이 다음과 같은 JSON으로 반환된다.
@ResponseStatus(HttpStatus.BAD_REQUEST)를 지정했으므로 HTTP 상태코드 400으로 응답한다.

@ControllerAdvice

@ExceptionHandler를 사용해서 예외를 깔끔하게 처리할 수 있지만 정상 코드와 예외 처리 코드가 하나의 컨트롤러에 섞여 있다. @ControllerAdvice, @RestControllerAdvice를 사용하면 둘을 분리할 수 있따.

 @Slf4j
 @RestControllerAdvice
 public class ExControllerAdvice {
     @ResponseStatus(HttpStatus.BAD_REQUEST)
     @ExceptionHandler(IllegalArgumentException.class)
     public ErrorResult illegalExHandle(IllegalArgumentException e) {
         log.error("[exceptionHandle] ex", e);
         return new ErrorResult("BAD", e.getMessage());
     }
     @ExceptionHandler
     public ResponseEntity userExHandle(UserException e) {
         log.error("[exceptionHandle] ex", e);
         ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
         return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
}
     @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
     @ExceptionHandler
     public ErrorResult exHandle(Exception e) {
         log.error("[exceptionHandle] ex", e);
return new ErrorResult("EX", "내부 오류"); }
}

@ControllerAdvice

@ControllerAdvice 는 대상으로 지정한 여러 컨트롤러에 @ExceptionHandler , @InitBinder 기능 을 부여해주는 역할을 한다. @ControllerAdvice 에 대상을 지정하지 않으면 모든 컨트롤러에 적용된다. (글로벌 적용) @RestControllerAdvice 는 @ControllerAdvice 와 같고, @ResponseBody 가 추가되어 있다. @Controller , @RestController 의 차이와 같다.

@ControllerAdvice(annotations = RestController.class) 위와 같이 작성하면 컨트롤러 클래스를 지정해줄 수 있다!

서블릿 예외 처리

Sun, 22 Sep 2024 05:59:48 GMT

서블릿은 2가지 방식으로 예외 처리를 지원한다

Exception
response.sendError(HTTP 상태 코드, 오류 메시지)

Exception(예외)

자바의 메인 메서드를 실행 ->main이라는 이름의 쓰레드가 실행 실행 도중에 예외를 잡지 못하면 -> 예외 정보를 남기고, 해당 쓰레드는 종료된다.

웹 애플리케이션

웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 애플리케이션에서 예외가 발생했을 때, 어디선가 try ~ catch로 예외를 잡아서 처리하면 아무런 문제가 없다. 그러나 예외를 잡지 못하고, 서블릿 밖으로 까지 예외가 전달하면 아래와 같이 동작한다.

서블릿

여기서 서블릿이란 간단하게 말하면 Java를 기반으로 한 웹 애플리케이션을 개발할 때 서버 측에서 클라이언트의 요청을 처리하고 그에 대한 응답을 생성하는 자바 클래스이다. 웹 서버에서 실행되며, 클라이언트로부터의 HTTP 요청을 받아 적절한 비즈니스 로직을 수행하고, 결과를 HTTP 응답으로 반환하는 역할을 한다.

WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)

결국 톰캣 같은 WAS까지 예외가 전달된다.

 @Controller
 public class ServletExController {
     @GetMapping("/error-ex")
     public void errorEx() {
throw new RuntimeException("예외 발생!"); }
}

위 url을 실행하면 HTTP 상태 코드 500이 반환된다. -> Exception의 경우 서버 내부에서 처리할 수 없는 오류가 발생한 것으로 생각되어 상태 코드 500이 반환된다.

response.sendError(HTTP 상태코드, 오류 메시지)

이것은 호출한다고 당장 예외가 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다.

@GetMapping("/error-500")
 public void error500(HttpServletResponse response) throws IOException {
     response.sendError(500);
 }

WAS(sendError 호출 기록 확인) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러 (response.sendError())

response 내부에서 오류가 발생했다는 상태를 저장해둔다. 그리고 서블릿 컨테이너는 고객에게 응답 전에 response sendError()가 호출되었는지 확인한다. 그리고 호출 되었다면 설정한 오류 코드에 맞추어 기본 오류 페이지를 보여준다.

서블릿 컨테이너

여기서 서블릿 컨테이너가 무엇인지 간단히 말하자면

서블릿 컨테이너는 서블릿이라는 프로그램을 관리하고 실행하는 역할을 하는 곳으로, 서블릿을 실행하고, 클라이언트의 요청을 받아서 서블릿에게 전달하고, 서블릿이 처리한 결과를 다시 클라이언트에게 보내주는 일을 한다.

오류 화면 제공

서블릿 컨테이너가 제공하는 기본 예외 처리 화면은 고객 친화적이지 않다.

과거에는 web.xml이라는 파일에 오류화면을 등록했다.

 
     
     404
     /error-page/404.html
     
     
     500
     /error-page/500.html
     
     
     java.lang.RuntimeException
     /error-page/500.html

지금은 스프링 부트를 통해서 서블릿 컨테이너를 실행하기 때문에 스프링 부트의 기능을 사용할 수 있다.

package hello.exception;
 import org.springframework.boot.web.server.ConfigurableWebServerFactory;
 import org.springframework.boot.web.server.ErrorPage;
 import org.springframework.boot.web.server.WebServerFactoryCustomizer;
 import org.springframework.http.HttpStatus;
 import org.springframework.stereotype.Component;
@Component
 public class WebServerCustomizer implements
 WebServerFactoryCustomizer {
     @Override
     public void customize(ConfigurableWebServerFactory factory) {
         ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-
 page/404");
         ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR,
 "/error-page/500");
ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-
page/500");
         factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
} }

response.sendError(404): errorPage404 호출 response.sendError(500): errorPage500 호출 RuntimeException 또는 그 자식 타입의 예외: errorPageEx 호출

@Slf4j
 @Controller
 public class ErrorPageController {
     @RequestMapping("/error-page/404")
     public String errorPage404(HttpServletRequest request, HttpServletResponse
 response) {
         log.info("errorPage 404");
         return "error-page/404";
     }

오류를 처리할 컨트롤러이다.

오류 페이지 작동 원리

서블릿은 Exception이 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError()가 호출 되었을 때 설정된 오류 페이지를 찾는다.

WAS는 해당 예외를 처리하는 오류 페이지 정보를 확인한다.

중요한 점은 웹 브라우저(클라이언트)는 서버 내부에서 이런 일이 일어나는지 전혀 모른다. 오직 서버 내부에서 오류 페이지를 찾기 위해 추가적인 호출을 한다.

예외가 발생해서 WAS까지 전파된다.
WAS는 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다. 이때 오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다.

오류 정보 추가

WAS는 오류 페이지를 단순히 다시 요청만 하는 것이 아니라, 오류 정보를 request의 attribute에 추가해서 넘겨준다.

public static final String ERROR_EXCEPTION =
"javax.servlet.error.exception";
    public static final String ERROR_EXCEPTION_TYPE =
"javax.servlet.error.exception_type";
    public static final String ERROR_MESSAGE = "javax.servlet.error.message";
    public static final String ERROR_REQUEST_URI =
"javax.servlet.error.request_uri";
    public static final String ERROR_SERVLET_NAME =
"javax.servlet.error.servlet_name";
    public static final String ERROR_STATUS_CODE =
"javax.servlet.error.status_code";
    @RequestMapping("/error-page/404")
    public String errorPage404(HttpServletRequest request, HttpServletResponse
response) {
        log.info("errorPage 404");
        printErrorInfo(request);
        return "error-page/404";
}

private void printErrorInfo(HttpServletRequest request) {
        log.info("ERROR_EXCEPTION: ex=", request.getAttribute(ERROR_EXCEPTION));
        log.info("ERROR_EXCEPTION_TYPE: {}",
request.getAttribute(ERROR_EXCEPTION_TYPE));
        log.info("ERROR_MESSAGE: {}", request.getAttribute(ERROR_MESSAGE)); //ex
        의 경우 NestedServletException 스프링이 한번 감싸서 반환 log.info("ERROR_REQUEST_URI: {}", request.getAttribute(ERROR_REQUEST_URI));
         log.info("ERROR_SERVLET_NAME: {}",
 request.getAttribute(ERROR_SERVLET_NAME));
         log.info("ERROR_STATUS_CODE: {}",
 request.getAttribute(ERROR_STATUS_CODE));
         log.info("dispatchType={}", request.getDispatcherType());
     }
}

필터

로그인 인증 체크 같은 경우를 생각해보면, 이미 한번 필터나, 인터셉터에서 로그인 체크를 완료했다. 따라서 서버 내부에서 오류 페이지를 호출한다고 해서 해당 필터나 인터셉트가 한번 더 호출되는 것은 매우 비효율적이다. 결국 클라이언트로 부터 발생한 정상 요청인지, 아니면 오류 페이지를 출력하기 위한 내부 요청인지 구분할 수 있어야 한다. 서블릿은 이런 문제를 해결하기 위해 DispatcherType이라는 추가 정보를 제공한다.

필터에 이런 경우를 위해서 dispatcherType 라는 옵션을 제공한다.

고객이 처음 요청하면 dispatcherType=REQUEST이다. 이렇듯 서블릿 스펙은 실제 고객이 요청한 것인지, 서버가 내부에서 오류 페이지를 요청하는 것인지 DispatcherType으로 구분할 수 있다.

@Configuration
 public class WebConfig implements WebMvcConfigurer {
     @Bean
     public FilterRegistrationBean logFilter() {
         FilterRegistrationBean filterRegistrationBean = new
 FilterRegistrationBean<>();
         filterRegistrationBean.setFilter(new LogFilter());
         filterRegistrationBean.setOrder(1);
         filterRegistrationBean.addUrlPatterns("/*");
         filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST,
 DispatcherType.ERROR);
         return filterRegistrationBean;
} }

인터셉터

앞서 필터의 경우에는 필터를 등록할 때 어떤 DispatcherType인 경우에 필터를 적용할 지 선택할 수 있었다. 그런데 인터셉터는 서블릿이 제공하는 기능이 아니라 스프링이 제공하는 기능이다. 따라서 DispatcherType과 무관하게 항상 호출된다.

대신에 인터셉터는 다음과 같이 요청 경로에 따라서 추가하거나 제외하기 쉽게 되어 있기 때문에, 이러한 설정을 사용해서 오류 페이지 경로를 excludePathPattern 를 사용해서 빼주면 된다.

@Override
     public void addInterceptors(InterceptorRegistry registry) {
     registry.addInterceptor(new LogInterceptor())
        .order(1)
        .addPathPatterns("/**")
        .excludePathPatterns(
); }

스프링 부트 - 오류 페이지

스프링 부트는 모든 과정을 기본으로 제공한다

ErrorPage를 자동으로 등록한다. 이때 /error라는 경로로 기본 오류 페이지를 설정한다.
- new ErrorPage("/error"), 상태코드와 예외를 설정하지 않으면 기본 오류 페이지로 사용된다.
- 서블릿 밖으로 예외가 발생하거나, response.sendError()가 호출되면 모든 오류는 /error를 호출하게 된다.
BasicErrorController라는 스프링 컨트롤러를 자동으로 등록한다.
- ErrorPage에서 등록한 /error를 매핑해서 처리하는 컨트롤러이다.

cf) ErrorMvcAutoConfiguration이라는 클래스가 오류 페이지를 자동으로 등록하는 역할을 한다.

BasicErrorController는 기본적인 로직이 모두 개발되어 있다. 개발자는 오류 페이지 화면만 BasicErrorController가 제공하는 룰과 우선순위에 따라서 등록하면 된다. 정적 HTML이면 정적 리소스, 뷰 템플릿을 사용해서 동적으로 오류 화면을 만들고 싶으면 뷰 템플릿 경로에 오류 페이지 파일을 만들어서 넣어두기만 하면 된다.

기본 키와 외래 키, 데이터베이스와 테이블 생성하기

Tue, 17 Sep 2024 07:15:05 GMT

키(key)

조건에 맞는 데이터를 찾기 위한 식별자
기본 키, 외래 키, 고유 키 ...

관계형 데이터베이스란 테이블처럼 표의 형태로 데이터를 관리한다

위의 테이블에서 각각의 행을 지칭할 수 있는 가장 중요한 것 -> ID -> 기본키(Primary Key, PK)

기본 키(Primary Key)

중복되어서는 안되고, 고유해야 하며, NULL 이어서는 안된다.
때로는 여러 열을 묶어 하나의 기본 키로 삼기도 한다.

고유 키(Unique Key)

기본 키와 유사하나 널(NULL)로 지정 가능하다

외래 키(Foreign Key, FK)

두 개의 테이블 간의 관계를 표현하기 위한 키
다른 테이블을 연결(참조)하기 위한 키

외래키를 사용할 떄에는 주의해야 할 점이 있다. 예를 들어서 참조한 테이블이 삭제된다면??(on delete) 참조한 테이블이 변경된다면??(on update) -> 해결 방법

SET NULL: 전부 NULL 값으로 채워라
CASCADE: 함께 변경해라 (함게 삭제, 함께 업데이트)
RESTRICT: 삭제, 업데이트 자체를 제한

MySQL이 관리하는 것

데이터베이스
테이블
데이터를 의미하는 행과 열
데이터

MySQL에서는 데이터베이스를 스키마로 표현한다.

데이터베이스(스키마) 생성 CREATE DATABASE DBNAME;

데이터베이스(스키마) 조회 SHOW DATABASES;

데이터베이스(스키마) 사용 USE DBNAME;

데이터베이스(스키마) 삭제 DROP DATABSE DBNAME;

테이블 생성 CREATE TABLE 테이블이름 ( 열이름1 자료형, [DEFAULT 기본값] [NULL | NOT NULL] .... ) 괄호로 자료형의 최대 길이 명시 가능, 다양한 제약 조건을 추가할 수 있다.

자료형

숫자형(INT, BIGINT, FLOAT, DOUBLE, DECIMAL, ....)
문자형(CHAR, VARCHAR, ...)
날짜/시간형(DATE, DATETIME, TIMESTAMP, ..)
ENUM, SET, JSON, XML, ...

테이블 조회 SHOW TABLES; SHOW TABLES FROM DBNAME;

테이블 변경 ALTER TABLE tbl_name alter_option

테이블 삭제1 DROP TABLE TABLENAME;

테이블 삭제2 - 테이블 구조는 유지, 행만 삭제한다 TRUNCATE TABLE TABLENAME

MVC 패턴 강의 정리

Mon, 09 Sep 2024 01:46:29 GMT

객체지향 프로그래밍 특징

캡슐화(Encapsulation) 캡슐화는 객체의 상태(속성, 필드)와 행동(메서드)을 하나의 단위로 묶는 개념 객체의 내부 데이터는 외부에서 직접 접근할 수 없도록 보호되며, 필요한 경우 공개된 메서드를 통해서만 접근 가능하게 한다

-> 객체의 무결성을 유지하고, 데이터의 직접적인 변경을 방지할 수 있다


public class Car {
    private String model;  // private로 선언된 속성 (캡슐화)
    private int speed;

    // public 메서드를 통해서만 접근 가능
    public void setModel(String model) {
        this.model = model;
    }

    public String getModel() {
        return model;
    }
}

상속(Inheritance) 상속은 기존 클래스(부모 클래스, 슈퍼 클래스)의 속성과 메서드를 새로운 클래스(자식 클래스, 서브 클래스)가 물려받아 사용할 수 있게 하는 개념

-> 코드 재사용성을 높이고, 공통된 기능을 여러 클래스에서 쉽게 구현할 수 있게 한다.


public class Vehicle {
    protected int speed;

    public void move() {
        System.out.println("The vehicle is moving.");
    }
}

public class Car extends Vehicle {
    private String model;

    public void showModel() {
        System.out.println("The model is " + model);
    }
}

다형성(Polymorphism) 다형성은 동일한 인터페이스나 부모 클래스를 상속받은 객체들이 각기 다른 방식으로 행동 할 수 있는 능력이다. 메서드 오버라이딩과 메서드 오버로딩이 있다.


public class Animal {
    public void makeSound() {
        System.out.println("Some generic animal sound");
    }
}

public class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Bark");
    }
}

public class Cat extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Meow");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal myDog = new Dog();
        Animal myCat = new Cat();
        myDog.makeSound();  // Bark
        myCat.makeSound();  // Meow
    }
}

추상화(Abstraction) 추상화는 불필요한 세부사항을 숨기고 중요한 정보만 드러내는 것이다. 객체가 가진 속성과 메서드를 공통적인 인터페이스나 추상 클래스로 정의하고, 구현은 하위 클래스에서 책임진다.


public abstract class Shape {
    // 추상 메서드 (구현은 하위 클래스에서 제공)
    public abstract double getArea();
}

public class Circle extends Shape {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double getArea() {
        return Math.PI * radius * radius;
    }
}

public class Main {
    public static void main(String[] args) {
        Shape circle = new Circle(5);
        System.out.println("Area of circle: " + circle.getArea());
    }
}

SOLID

SOLID는 객체지향 설계 원칙 중에서 가장 중요한 다섯 가지 원칙을 나타내는 약어이다. 이 원칙들은 유지보수성, 확장성, 가독성을 높이기 위해 설계된 원칙들로, 객체지향 프로그래밍에서 견고하고 유연한 소프트웨어를 개발하는 데 도움을 준다.

단일 책임 원칙(SRP: Single Responsibility Principle) 원칙: 하나의 클래스는 오직 하나의 책임만 가져야 한다.

-> 클래스는 하나의 기능만 수행하고, 그 기능에 대한 변경 사유는 하나뿐이어야 한다는 의미이다. -> 책임이 많을수록 클래스를 변경해야 할 이유가 많아져, 유지보수가 어려워진다.


public class User {
    private String name;
    private String email;

    // 사용자 정보 저장 관련 로직
    public void saveUserToDatabase() {
        // DB에 사용자 저장하는 로직
    }

    // 이메일 보내기 관련 로직 (단일 책임 원칙 위반)
    public void sendEmail(String message) {
        // 이메일 전송 로직
    }
}

이 경우, 사용자 정보 저장과 이메일 전송이라는 두 가지 책임이 있어 단일 책임 원칙을 위반한다. 이를 분리한 코드가 아래의 코드이다.


public class User {
    private String name;
    private String email;
    // 사용자 정보만 다루는 클래스
}

public class EmailService {
    public void sendEmail(String email, String message) {
        // 이메일 전송 로직
    }
}

개방-폐쇄 원칙(OCP: Open/Closed Principle) 원칙: 클래스는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다

-> 기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있도록 설계해야 한다 -> 변경으로 인한 리스크를 줄이고, 시스템의 유연성을 높일 수 있다.

// 잘못된 예시: 할인 정책 변경 시 기존 코드 수정 필요
public class DiscountService {
    public double applyDiscount(double price, String discountType) {
        if (discountType.equals("fixed")) {
            return price - 10;
        } else if (discountType.equals("rate")) {
            return price * 0.9;
        }
        return price;
    }
}

public interface DiscountPolicy {
    double applyDiscount(double price);
}

public class FixedDiscountPolicy implements DiscountPolicy {
    @Override
    public double applyDiscount(double price) {
        return price - 10;
    }
}

public class RateDiscountPolicy implements DiscountPolicy {
    @Override
    public double applyDiscount(double price) {
        return price * 0.9;
    }
}

리스코프 치환 원칙(LSP: Liskov Substitution Principle) 원칙: 서브 클래스는 언제나 자신의 부모 클래스를 대체할 수 있어야 한다

-> 자식 클래스는 부모 클래스의 행위를 일관되게 유지해야 하며, 부모 클래스로 선언된 객체를 자식 클래스로 치환해도 프로그램의 행동이 변하지 않아야 한다


public class Bird {
    public void fly() {
        System.out.println("Bird is flying");
    }
}

public class Ostrich extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Ostrich can't fly");
    }
}

타조는 날 수 없기 때문에 부모 클래스인 Bird의 행위를 위반하게 된다 이는 LSP를 위반한다.

인터페이스 분리 원칙(ISP: Interface Segregation Principle) 원칙: 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.

-> 특정 클래스가 사용하지 않는 메서드를 강제로 구현하게 하지 말아야 한다. -> 인터페이스를 세분화하여 필요한 부분만 구현하도록 해야 한다.

public interface Worker {
    void work();
    void eat();
}

public class HumanWorker implements Worker {
    public void work() {
        // 일하는 로직
    }
    public void eat() {
        // 밥 먹는 로직
    }
}

public class RobotWorker implements Worker {
    public void work() {
        // 일하는 로직
    }
    public void eat() {
        // 로봇은 밥을 먹지 않으므로 문제 발생
    }
}

위의 코드철머 큰 인터페이스를 구현하면 모든 메서드를 구현해야 하므로 문제가 될 수 있다.


public interface Workable {
    void work();
}

public interface Eatable {
    void eat();
}

public class HumanWorker implements Workable, Eatable {
    public void work() {
        // 일하는 로직
    }

    public void eat() {
        // 밥 먹는 로직
    }
}

public class RobotWorker implements Workable {
    public void work() {
        // 일하는 로직
    }
}

의존 역전 원칙(DIP: Dependency Inversion Principle) 원칙: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다.

-> 구체적인 구현체에 의존하지 말고, 추상화된 인터페이스나 부모 클래스에 의존해야 한다.

Servlet

서블릿은 Java를 기반으로 한 웹 애플리케이션을 개발하기 위한 서버 측 컴포넌트이다. 주로 HTTP 요청을 처리하고, 그에 대한 응답을 생성하는 역할을 한다. 서블릿은 자바 인터페이스로, 웹 서버에서 실행되며 동적인 웹 페이지를 생성하는 데 사용된다.

서블릿의 주요 기능

HTTP 요청 처리: 클라이언트로부터 들어온 요청을 받아 처리하고, 적절한 응답을 생성한다.
동적 콘텐츠 생성: 요청에 맞는 동적인 웹 페이지나 데이터를 생성해 클라이언트로 전송한다
상태 관리: 세션, 쿠키 등을 이용해서 클라이언트의 상태를 관리할 수 있다.

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.setContentType("text/html");
        PrintWriter out = response.getWriter();
        out.println("Hello, World!");
    }
}

ServletContainer

서블릿 컨테이너는 서블릿의 실행 환경을 제공하는 소프트웨어이다. 일반적으로 웹 애플리케이션의 서버(WAS)의 일부로 존재하며, 서블릿의 생명주기 관리, 요청 및 응답 처리, 세션 관리등의 기능을 수행한다.

서블릿 컨테이너의 역할

서블릿 관리: 서블릿의 생성, 초기화, 실행, 종료를 포함한 생명주기 관리
HTTP 요청 및 응답 처리: 클라이언트로부터 HTTP 요청을 받아 적절한 서블릿에 전달하고, 서블릿의 응답을 클라이언트로 전달
멀티스레드 지원: 하나의 서블릿이 여러 클라이언트 요청을 동시에 처리할 수 있도록 스레드를 관리
세션 관리: 클라이언트의 상태를 유지하기 위해 세션 및 쿠키를 관리

서블릿 컨테이너로는 Apache Tomcat, Jetty, Undertow 등이 있다.

WAS VS 서블릿 컨테이너

WAS는 웹 서버 기능뿐만 아니라 비즈니스 로직을 처리하는 애플리케이션 서버이다. 즉, WAS는 서블릿 컨테이너뿐만 아니라 EJB 컨테이너와 같은 더 복잡한 애플리케이션 로직을 처리할 수 있는 다양한 모듈을 퐇마한다. WAS는 데이터베이스와 연동하거나, 트랜잭션 관리, 분산 컴퓨팅, 보안 등을 처리할 수 있는 기능을 제공한다.

WAS의 주요기능

서블릿, JSP 실행: 서블릿 컨테이너 역할
비즈니스 로직 처리: EJB(Enterprise JavaBeans) 등 복잡한 비즈니스 로직을 처리
트랜잭션 관리: 여러 데이터베이스 작업이나 비즈니스 로직 실행 간의 트랜잭션 관리
자원 관리: 연결 풀링, 데이터베이스 연결, 메시징 시스템 등을 관리
보안: 인증 및 인가, SSL 지원 등을 통해 보안을 강화

서블릿 컨테이너는 서블릿과 JSP를 실행하는 환경을 제공하는 서버이고, 주로 HTTP 요청과 응답을 처리한다. WAS는 서블릿 컨테이너의 기능을 포함하면서 더 복잡한 비즈니스 로직 처리, 트랜잭션 관리 등 다양한 기능을 제공하는 웹 애플리케이션 서버이다.

Dispatcher Servlet

디스패처 서블릿이란 Servlet의 일종이다.


public class DispatcherServlet extends FrameworkServlet {
}

public abstract class FrameworkServlet extends HttpServletBean {
}

public abstract class HttpServletBean extends HttpServlet {
}

가장 먼저 요청을 받고, 적절하게 처리할 함수(컨트롤러)를 찾아서 정해주는 역할을 한다.

과거에는 모든 서블릿을 URL 매핑을 위해 web.xml에 등록해야 했지만, 디스패처 서블릿을 통해 해결할 수 있다. 디스패처 서블릿은 스프링 MVC의 중앙 서블릿이며 어플리케이션으로 오는 모든 요청을 핸들링하고 공통작업을 처리해준다. -> 이처럼 서블릿 컨테이너 맨 앞에서 모든 요청을 받아 처리해주는 컨트롤러로 프론트 컨트롤러 패턴이라고 한다.

서블릿은 스스로 동작하지 않는다. 보통 서블릿을 관리할 톰캣 등과 같은 서블릿 컨테이너를 사용한다.

서블릿 컨테이너는 싱글톤인 서블릿 객체의 생명주기를 관리한다. 또한 웹서버와 소켓으로 통신하며, 클라이언트의 요청을 받고 응답을 보내준다.

MVC란

MVC 는 Model, View, Controller의 약자 입니다. 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴입니다.

모델은 컨트롤러에 컨트롤러는 뷰에 뷰는 다시 유저 유저는 다시 컨트롤러를 향해서 갑니다.

모델, Model

애플리케이션의 정보, 데이타를 나타냅니다. 데이타베이스, 처음의 정의하는 상수, 초기화값, 변수 등을 뜻합니다. 또한 이러한 DATA, 정보들의 가공을 책임지는 컴포넌트를 말합니다.

이 모델은 다음과 같은 규칙을 가지고 있습니다.

사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.

즉, 화면안의 네모박스에 글자가 표현된다면, 네모박스의 화면 위치 정보, 네모박스의 크기정보, 글자내용, 글자의 위치, 글자의 포맷 정보 등을 가지고 있어야 한다는 것입니다.

뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.

데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안 된다는 말입니다.

변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.

모델의 속성 중 텍스트 정보가 변경이 된다면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을 때 이를 수신할 수 있는 처리 방법을 구현해야 합니다. 또한 모델은 재사용가능해야 하며 다른 인터페이스에서도 변하지 않아야 합니다.

뷰, View

input 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타냅니다. 다시 말해 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당합니다. 데이타를 기반으로 사용자들이 볼 수 있는 화면입니다.

뷰에서는 다음과 같은 규칙들이 있습니다.

모델이 가지고 있는 정보를 따로 저장해서는 안된다.

화면에 글자를 표시 하기 위해, 모델이 가지고 있는 정보를 전달받게 될텐데, 그 정보를 유지하기 위해서 임의의 뷰 내뷰에 저장하면 안됩니다. 단순히 네모 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고 그 화면을 그릴 때 필요한 정보들은 저장하지 않아야 합니다.

모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.

모델과 같은 자기 자신의 빼고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안됩니다. 그냥 뷰는 데이터를 받으면 화면에 표시해주는 역할만 가진다고 보면 됩니다.

변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.

모델과 같이 변경이 일어났을 때 이른 누군가에게 변경을 알려줘야 하는 방법을 구현해야 합니다. 뷰에서는 화면에서 사용자가 화면에 표시된 내용을 변경하게 되면 이를 모델에게 전달해서 모델을 변경해야 할 것이다. 그 작업을 하기 위해 변경 통지를 구현합니다.

그리고 재사용가능하게끔 설계를 해야 하며 다른 정보들을 표현할 때 쉽게 설계를 해야 합니다.

컨트롤러,Controller

데이터와 사용자인터페이스 요소들을 잇는 다리역할을 합니다.

즉, 사용자가 데이터를 클릭하고, 수정하는 것에 대한 "이벤트"들을 처리하는 부분을 뜻합니다.

컨트롤러 또한 다음과 같은 규칙을 이해해야 합니다.

모델이나 뷰에 대해서 알고 있어야 한다.

모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데 이를 컨트롤러가 중재하기 위해 모델과 그에 관련된 뷰에 대해서 알고 있어야 합니다.

모델이나 뷰의 변경을 모니터링 해야 한다.

모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 합니다.

또한, 애플리케이션의 메인 로직은 컨트롤러가 담당하게 됩니다.

왜 MVC패턴을 사용해야 할까.

사용자가 보는 페이지, 데이터처리, 그리고 이 2가지를 중간에서 제어하는 컨트롤, 이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은바에만 집중을 할 수 있게 됩니다. 공장에서도 하나의 역할들만 담당을 해서 처리를 해서 효율적이게 됩니다. 여기서도 마찬가지입니다.

사실 저 밑에 스즈키 네는 군용 볼트를, 옆집 하루노보 네는 군용 너트를 만들고 있을 뿐이다.

(커티스 르메이, 도쿄 대공습 직전에 부하들에게.)

서로 분리되어 각자의 역할에 집중할 수 있게끔하여 개발을 하고 그렇게 애플리케이션을 만든다면, 유지보수성, 애플리케이션의 확장성, 그리고 유연성이 증가하고, 중복코딩이라는 문제점 또한 사라지게 되는 것입니다. 그러기 위한 MVC패턴입니다.

*유연성: 여기서 유연성이라는 것은 클라이언트의 새로운 요구사항에 대해 최소한의 비용으로 보다 유연하게 대처할 수 있는 것을 말합니다.

*비즈니스로직: 프로그램의 논리구조

데이터베이스 거시적으로 보기

Sun, 08 Sep 2024 08:23:29 GMT

데이터베이스란

데이터베이스는 여러 사람이 공유하여 사용할 목적으로 체계화해 통합, 관리하는 데이터의 집합

데이터베이스에 저장될 수 있는 것들

학생 데이터
학과 데이터
결제 데이터
품목 데이터 ,,,,
저장해야 하는 대부분의 것들

데이터베이스란 웹 서비스의 심장과도 같다. 저장되는 대상/ 저장하는 방법에 따라 웹서비스의 목적과 성능이 달라진다

저장되는 방법 -> 데이터베이스 설계 및 모델링하는 방법

DBMS

Data Base Management System 데이터베이스를 관리하는 시스템

DBMS의 종류

MySQL
MongoDB
Oracle
SQL Server
PostgreSQL

관계형 DBMS와 비관계형 DBMS로 나눌 수 있다

관계형 DBMS란

데이터를 테이블 형태(열 & 행)로 저장
즉, 데이터를 표와 같은 형태로 저장하는 DBMS
테이블끼리 참조, 합치기도 가능하다

관계형 DBMS를 다루기 위한 언어 -> SQL

SQL은 Structured Query Language 관계형 데이터베이스 관리 시스템(RDBMS)에서 데이터를 조작하고 관리하기 위한 언어

ex)

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    department VARCHAR(50)
   );

SELECT first_name, last_name
FROM employees;

DELETE FROM orders
WHERE order_id =456;

SQL의 종류

DML: Data Manipulation Language

SELECT, INSERT, UPDATE, DELETE DDL: Data Definition Language
CREATE, ALTER, DROP, RENAME, TRUNCATE DCL: Data Control Language
GRANT, REVOKE, TCL(COMMIT, ROLLBACK, SAVEPOINT)

cf) NoSQL 비관계형 데이터베이스 NoSQL은 먼저 구조를 정의할 필요없이 데이터를 저장 및 검색 확장성, 가용성이 장점(실시간 웹 어플리케이션 & 빅데이터) ex) MongoDB

트랜잭션(Transaction)

데이터베이스 상호작용의 단위
논리적 작업 단위 ex) 돈을 계좌에서 인출하는 작업 / 학생을 테이블에서 삭제하는 작업

트랜잭션이 지켜야 할 성질

ACID
A(원자성, Atomicity) 트랜잭션은 하나의 논리적인 작업 단위로 간주 모든 데이터 조작 작업은 성공하거나, 실패할 때까지 적용되지 않거나 롤백 계좌에서 인출하고 다른 계좌로 입금하는 트랜잭션에서 하나의 작업이 실패하면 다른 작업도 취소
C(일관성, Consistency) 트랜잭션은 데이터베이스를 일관된 상태로 유지 트랜잭션이 시작하기 전과 끝난 후에도 데이터베이스는 일관된 규칙과 제약 조건을 따라야 한다
I(격리성, Isolation) 동시에 여러 트랜잭션이 실행될 때 각 트랜잭션은 서로 간섭하지 않고 격리되어야 한다 한 트랜잭션의 작업이 다른 트랜잭션에게 영향을 미치지 않도록 보장 두 개의 트랜잭션이 동시에 계좌에서 돈을 인출하려 할 때, 한 트랜잭션이 완료되기 전에 다른 트랜잭션은 해당 계좌에 접근하지 못해야 한다
D(지속성, Durablility) 트랜잭션이 성공적으로 완료되면, 그 결과는 영구적으로 저장되어야 한다

E2E 프로젝트

Thu, 05 Sep 2024 09:52:15 GMT

2024년 7월 29일 부터 8월 30일까지 한달 간 동시성 테스트를 경험해보기 위해 식당 예약 및 원격으로 줄을 설 수 있는 서비스를 만들었다. 서비스를 만들기 전에 만든 아키텍처 설계와 ERD 설계는 아래 사진과 같다.

위의 사진처럼 route53에 가비아에서 구매한 도메인을 EC2서버에 연결해 localhost:8080에서 접속할 수 있었던 사이트를 catchline.site에서 접속할 수 있게 했고, 배포된 사이트에서 데이터베이스를 사용할 수 있기 위해서 Aamazon RDS에서 MySQL을 사용했다. 그 후 클라이언트에서 요청을 보내면 AWS Certificate Manager와 Aamazon ELB를 거쳐서 EC2서버에 요청이 가도록 설계를 했다.

백엔드 개발자로써 이번처럼 본격적으로 프로젝트를 하는 것이 처음이라 개발을 하기 전에 전체적인 협업규칙을 정하기로 했다. 그 결과 우리팀이 정한 협업 규칙은 여러가지가 있지만 대표적으로 특정 기술을 선택하기 전에 왜 이 기술을 사용해야 하는지 팀원들과 함께 충분한 대화를 통해서 인지를 하고 기술을 사용하는 것이었다. 프로젝트 개발이 끝난 지금도 이런 규칙을 정한 것이 되게 괜찮다고 생각이 들었다. 그 이유는 포트폴리오를 작성할 때나 면접을 볼 때 왜 Jwt를 사용하셨나요? 와 같은 질문들이 되게 많이 나온다고 알고 있고, 이러한 질문들에 대비를 할 수 있기 때문이다.

한달 동안 프로젝트에서 구현한 기능들은 대략적으로 설명해보자면 CRUD는 기본적으로 식당,리뷰,스크랩,웨이팅,예약,유저 추가 삭제 편집 등에서 구현했고, 스프링 시큐리티, jwt, 세션 사용과 querydsl를 사용해 페이지네이션, 검색, 정렬 기능 구현, SSE를 사용해 알림 기능등을 구현했다. 또한 동시성 테스트를 하기 위해서 syncronized 를 사용해 예약등록 메서드를 동시성 테스트를 해봤다.

위에서 내가 한달 동안 팀원들과 함께 만든 서비스의 소개, 협업 규칙, 설계, 구현한 기능을 소개했으니 한달동안 발생한 주요한 이슈들 몇가지를 소개해보겠다.

동시성 테스트를 하면서 발생한 이슈부터 말해보겠다.

첫 번쨰로 20명의 사용자가 동시에 하나의 식당에 예약을 할 때 1명의 사용자를 제외하고 19명의 사용자가 예약등록을 실패해야하는데 처음에 내가 동시성 테스트를 실행했을때에는 7명의 사용자가 예약 등록을 성공하는 이슈가 발생했다. 그래서 나는 이 이슈의 원인이 내가 ExecutorService executorService = Executors.newFixedThreadPool(20) 을 사용해서 스레드 풀에 총 20개의 스레드를 만들고 테스트를 실행했는데 하나의 스레드가 예약등록 메서드를 실행 중이고 아직 메서드가 종료되지 않았을 때 다른 스레드가 예약등록 메서드를 실행해서 발생한 이슈라고 생각해 예약등록 메서드에 트랜잭션과 syncronized를 추가해 이 이슈를 해결했다. 그러나 이 이슈를 해결한 후 바로 다른 이슈가 발생했다.

두 번쨰로 트랜잭션과 syncronized를 추가한 후에는 1명의 사용자를 제외하고 나머지 모든 사용자가 예약등록에 실패하는 결과가 올바르게 나왔는데 테스트를 10번 실행하면 3번 정도는 테스트가 실패하는 이슈가 발생했다. 결론적으로 이 이슈의 원인은 트랜잭션과 syncronized를 함께 사용해서 발생한 결과인데 그 이유는 트랜잭션을 사용하면 메서드의 앞뒤로 transaction begin, transaction commit 과 같은 코드들이 생기는데 이 코드들은 syncronized의 동시성 제어의 영역이 아니기 떄문에 transaction commit이 끝나기 전에 다른 스레드가 메서드를 실행시키는 경우가 발생해서 위와 같은 이슈가 발생했었다. 그래서 이 이슈는 예약 등록 메서드에서 트랜잭션을 제거하고 해결했다.

세 번쨰로 200명이 동시에 예약을 했을 때 예약 등록에 성공하는 유저가 memberId 1부터 20번 정도로만 테스트를 실행시켰을 때 나오지 않았다. 이 이슈의 원인은 디버깅을 통해서 해결했는데 내가 바라는대로 200개의 스레드가 동시에 예약 요청을 하지 않고, 20개 정도의 스레드가 먼저 예약을 시도한 후에 나머지 스레드가 예약을 동시에 실행하고 있어서 발생한 이슈였다. 그래서 나는 이 이슈를 CountDownLatch의 startLatch.await()을 사용해서 모든 스레드가 준비 상태에 도달할 때까지 대기하고 모든 스레드가 준비 완료되면 startLatch.countDown()을 호출해서 모든 스레드가 동일한 조건에서 동시에 메소드를 실행하게 해서 이슈를 해결했다. 아래의 이미지가 내가 동시성을 테스트한 코드이다.

다음은 배포과정 중에서 발생한 이슈인데 처음에 EC2와 RDS를 사용해서 배포를 한 후에 확인을 했을 때 카카오맵 API가 정상적으로 연동이 되지 않고, HTTP로 배포가 되어서 보안이 매우 취약한 이슈였다. 그래서 나는 이 이슈들을 AWS의 Route53과 Certificate Manager를 사용해서 SSL 인증을 받아 HTTPS 로 배포를 하면서 이 이슈를 해결했다. 나중에 알고보니 카카오맵 API 연동 문제는 HTTP를 사용해서 발생한 것이 아니라 다른 해결방법이 있었던 것 같아서 괜히 HTTPS로 배포했나 싶기도 했지만 보안 문제를 생각하면 SSL인증을 받아 HTTPS로 배포한 것이 괜찮은 선택이었던 것 같다.

내가 겪은 주요한 이슈들은 이정도였지만 팀원들이 겪었던 이슈들도 매우 많았던 것 같다.

이번 프로젝트를 하면서 제일 많이 얻은 것은 스프링에 대한 기본적인 숙련도인 것 같다. 이번 프로젝트에 기본적인 CRUD를 사용해서 만든 기능들이 많아 한달 전보다 훨씬 스프링에 익숙해졌고, 또한 수많은 멘토링을 통해서 클린코드에 좀 더 가까워지게 코드를 작성할 수 있게 되었다.

그러나 아직 모르는 스프링에 대한 기능들이 많기 때문에 좀 더 많이 경험을 해보고 익숙해지고 싶다. 그리고 이번에 동시성 테스트에서 Redis를 사용해보는 경험을 해보고 싶었는데 시간이 부족해 사용해보지 못해 약간 반쪽짜리 동시성 테스트 였다는 생각이 들었다. 그리고 만들고 보니 기능을 많이 구현했다고 생각했지만 핵심적인 기능들이 조금 적었던 것 같아 여러모로 부족했던 점이 많은 프로젝트였던 것 같다. 하지만 그만큼 얻은 것도 많고 다음 프로젝트는 무려 3달이 넘는 기간동안 만들기 때문에 훨씬 디테일을 많이 챙기면서 만들어 볼 수 있을 것 같다.

HTTP, 캐시, 쿠키

Sun, 01 Sep 2024 10:01:33 GMT

HTTP 메시지 개관

HTTP 메시지 개요

HTTP 메시지는 웹 상에서 클라이언트와 서버 간에 데이터를 교환하기 위해 사용되는 메시지 포맷입니다. HTTP 메시지는 크게 두 가지로 나뉩니다.

요청 메시지: 클라이언트가 서버에 정보를 요청할 때 사용
응답 메시지: 서버가 클라이언트의 요청에 대해 응답할 때 사용

HTTP 메시지의 구조

HTTP 메시지는 다음과 같은 기본 구조로 이루어져 있습니다.

시작 라인(Start Line) 요청 메시지에서는 HTTP 메서드, 요청 대상(URI), HTTP 버전으로 구성 응답 메시지에서는 HTTP 버전, 상태 코드, 이유 문구로 구성
헤더(Header) 다양한 헤더 필드들이 존재하며, 이들은 요청이나 응답에 대한 추가 정보를 제공
본문(Body) 선택적으로 사용되며, 주로 POST나 PUT 요청에서 데이터 전송을 위해 사용

HTTP 메서드

HTTP 메서드는 클라이언트가 서버에 어떤 동작을 요청하는지를 정의

GET 서버로부터 자원을 요청하는 메서드로 주로 데이터 조회에 사용되며, 요청 본문이 없다
POST 서버로 데이터를 전송하고, 그 데이터를 처리하도록 요청하는 메서드로 주로 자원 생성이나 데이터 처리를 위해 사용
PUT 서버의 자원을 덮어쓰는 메서드로 자원이 존재하지 않으면 새로 생성하기도 한다
PATCH 자원의 일부를 수정하는 메서드
DELETE 서버에서 자원을 삭제하는 메서드

HTTP 상태코드

HTTP 상태 코드는 서버가 클라이언트의 요청을 처리한 결과를 나타낸다. 5가지의 범주로 나타낸다

1XX(정보) 요청이 수신되었으며, 처리가 계속 진행됨을 나타낸다
2XX(성공) 요청이 성공적으로 처리되었음을 나타낸다
3XX(리다이렉션) 클라이언트가 요청한 리소스가 다른 위치로 이동되었음을 나타낸다
4XX(클라이언트 오류) 클라이언트의 잘못된 요청으로 인해 오류가 발생함을 나타낸다
5XX(서버 오류) 서버에서 요청을 처리하는 도중 오류가 발생했음을 나타낸다

HTTP 요청 및 응답 헤더 필드

HTTP 헤더는 요청과 응답에 대한 추가 정보를 제공하는 필드로, 매우 다양하게 사용된다.

Request Headers 클라이언트가 서버에 요청할 때 추가적인 정보를 제공하는 헤더 ex) User-Agent, Accept, Authorization
Response Headers 서버가 클라이언트에 응답할 때 제공하는 추가적인 정보를 담고 있다 ex) Content-Type, Set-Cookie, Location

헤더 필드는 HTTP 메시지의 기능을 확장하고, 보다 효율적인 통신을 가능하게 한다

기타 중요한 개념

멱등성(Idempotency): 멱등성은 동일한 요청을 여러 번 보내더라도, 결과가 처음 요청과 동일한지를 의미한다. 예를 들어 GET, PUT, DELETE 메서드는 멱등성이 있는 메서드이다.
캐시 가능성(Cacheability): 캐시 가능성은 서버의 응답을 클라이언트나 중간 캐시가 저장할 수 있는지 여부를 나타낸다. 에를 들어, GET 응답은 캐시될 수 있지만, POST 응답은 일반적으로 캐시되지 않는다.

HTTP 헤더

HTTP 헤더의 개요

HTTP 헤더는 헤더 필드라고 불리며, 각 필드는 이름과 값으로 구성된다. 일반 적으로 다음과 같은 형식으로 구성된다. header-field = field name ":" field-value 이 형식은 HTTP 메시지의 전송 시 필요한 추가 정보를 제공한다.

주요 HTTP 헤더 필드

HTTP 헤더에는 다양한 필드가 있으며, 그 중 자주 사용되는 헤더 필드는 아래와 같다.

요청(Request) 관련 헤더 필드
- Host: 요청 대상 서버의 호스트명과 포트 정보를 나타낸다
- Referer: 클라이언트가 이전에 방문한 URL을 가리킨다.
- User-Agent: 클라이언트 소프트웨어의 이름과 버전을 나타내며, 주로 브라우저 정보를 담고 있다
응답(Response) 관련 헤더 필드
- Server: 서버 소프트웨어의 이름과 버전을 나타낸다
- Location: 리다이렉션 시 클라이언트를 이동시킬 새로운 URL을 나타낸다.
대표적인 헤더 필드 예시 Host: Host: www.example.com 요청이 www.example.com 서버에 보내졌음을 의미합니다.

Date: Date: Mon, 27 Sep 2021 12:00:00 GMT 요청 또는 응답이 발생한 시간을 나타냅니다.

Referer: Referer: http://previous.page.com 클라이언트가 이 페이지로 이동하기 전에 방문한 페이지의 URL입니다.

User-Agent: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 클라이언트가 사용하는 브라우저와 운영체제에 대한 정보입니다. 여기서 클라이언트는 윈도우 10을 사용하는 크롬 브라우저입니다.

Server: Server: Apache/2.4.41 (Ubuntu) 서버가 Apache 웹 서버를 사용하고 있음을 나타냅니다.

Location: Location: https://new-url.com 리다이렉션 시 이동할 경로이다.

콘텐츠 관련 필드

Content-Type 요청 또는 응답에서 사용되는 콘텐츠의 유형을 나타낸다.
- text/html; charset=utf-8: HTML 문서로, UTF-8 인코딩을 사용합니다.
- application/json: JSON 형식의 데이터를 사용합니다.
- image/png: PNG 이미지 파일입니다.
Content-Encoding 콘텐츠의 인코딩 및 압축 방식을 나타낸다
Content-Length 콘텐츠의 길이를 바이트 단위로 나타낸다
Content-Language 콘텐츠의 언어를 나타낸다

캐시

캐시의 개념

캐시는 네트워크에서 자원의 사본을 임시 저장하는 기술이다. HTTP 프로토콜은 기본적으로 상태를 유지하지 않는 무상태 프로토콜이기 때문에, 동일한 자원에 대한 요청이 반복될 경우 서버는 매번 자원을 새롭게 응답해야한다. 이를 보완하기 위해 캐시가 사용된다.

캐시된 자원은 다음과 같은 위치에 저장될 수 있다.

클라이언트(브라우저) 캐시: 사용자의 브라우저가 자원을 로컬에 저장한다.
캐시 서버/프록시 서버: 중간 서버가 자원의 사본을 저장하여 어러 클라이언트 요청에 대해 빠르게 응답할 수 있다.

Cache-Control 헤더

캐시의 동작을 제어하기 위해 Cache-Control 헤더가 사용된다. 이 헤더는 캐시의 사용 여부와 조건을 명시한다.

max-age=숫자(초): 자원을 캐시할 수 있는 최대 시간을 초 단위로 설정한다
no-cache: 자원을 캐시할 수는 있지만, 항상 원본 서버에 자원의 유효성을 검증해야 한다
no-store: 자원을 캐시해서는 안된다. 이 설정은 자원의 보안이 중요한 경우에 사용된다.

캐시된 자원의 유효 기간

캐시된 자원은 무한히 유효하지 않으며, 일정 기간 동안만 유효하다. 자원의 마지막 변경 시점을 나타내는 Last-Modified 헤더가 이를 관리하는 데 사용된다.

캐시된 자원의 변경

캐시된 자원이 변경된 경우, 클라이언트는 이를 인지하고 새로운 자원을 받아야 한다. 자원의 변경 여부를 확인하는 두 가지 주요 방법이 있다.

If-Modified-Since 헤더 클라이언트는 요청 시 If-Modified-Since 헤더를 사용하여 특정 시점 이후 자원이 변경되었는지를 서버에 묻는다. 만약 자원이 변경되지 않았다면 서버는 304 응답을 보내며 이는 클라이언트가 캐시된 자원을 그대로 사용할 수 있음을 나타낸다.
ETag(Entity Tag) 서버는 자원에 대해 고유한 식별자인 ETag값을 부여한다. 클라이언트는 이후 요청에서 If-None-Match 헤더를 통해 이 ETag값이 변경되었는지 확인할 수 있다.

쿠키

쿠키란 무엇인가?

쿠키는 서버에서 클라이언트로 전송된 정보를 임시로 저장하는 작은 데이터 조각이다. 쿠키는 이름=값의 형태로 저장되며, 주로 세션 유지, 사용자 추적, 사용자 설정 저장 등의 목적으로 사용된다. 쿠키는 다음과 같은 특징을 가지고 있다.

유효 기간: 쿠키는 유효 기간이 설정되며, 그 기간이 지나면 자동으로 삭제된다.
도메인 및 경로: 쿠키가 적용되는 도메인과 경로가 설정되어 있어, 특정 도메인이나 경로에서만 쿠키가 전송된다.

쿠키의 동작 방식

서버는 Set-Cookie 헤더를 통해 쿠키를 클라이언트로 전송된다. 클라이언트는 이 쿠키를 저장하고, 이후 해당 도메인으로의 요청 시 Cookie 헤더에 쿠키를 포함시켜 서버로 전송한다. 이를 통해 서버는 클라이언트를 식별하고 이전 상태를 유지할 수 있다.

쿠키의 도메인과 경로

도메인: Set-Cookie: domain=example.com으로 설정된 쿠키는 example.com과 그 하위 도메인에서 사용된다.
경로: Set-Cookie: path=/posts로 설정된 쿠키는 /posts 경로 및 그 하위 경로에서만 유효하다

쿠키의 유효 기간 설정

쿠키의 유효 기간은 다음과 같은 두 가지 방법으로 설정된다.

expires: Set-Cookie: expires=Wed, 10 Aug 2023 12:00:00 GMT와 같이 특정 만료일을 설정합니다.
max-age: Set-Cookie: max-age=1000과 같이 설정된 초 단위로 쿠키의 수명을 지정할 수 있습니다. 이 예에서는 쿠키가 1000초 동안 유효합니다.

쿠키와 보안

쿠키는 민감한 정보를 저장할 수 있으므로 보안에 대한 주의가 필요하다.

Secure: 쿠키를 HTTPS를 통해서만 전송하도록 설정한다. 이를 통해 전송 중에 쿠키가 도청될 위험을 줄인다.
HTTPOnly: 쿠키에 자바스크립트를 통해 접근할 수 없도록 설정한다. 이는 XSS 공격을 방지하는 데 유용하다

쿠키와 세션

쿠키와 세션은 사용자 상태를 유지하는 두 가지 방법이다.

쿠키: 클라이언트측에 저장되고 관리된다.
세션: 서버 측에서 관리되며, 서버는 클라이언트를 식별하기 위해 세션 ID를 쿠키로 클라이언트에 전달한다. 이후 클라이언트는 요청 시 이 세션 ID를 서버에 다시 전송하여 상태를 유지한다

싱글톤이란?

Fri, 30 Aug 2024 12:29:49 GMT

싱글톤 패턴이란

싱글톤 패턴은 특정 클래스의 인스턴스를 1개만 생성되는 것을 보장하는 디자인 패턴입니다. 즉, 생성자를 통해서 여러 번 호출이 되더라도 인스턴스를 새로 생성하지 않고 최초 호출 시에 만들어두었던 인스턴스를 재활용하는 패턴입니다.

싱글톤 패턴을 사용하면 메모리 사용을 최적화하고, 객체 생성 비용을 절감할 수 있습니다.

    @Test
    @DisplayName("스프링 없는 순수한 DI 컨테이너")
    void pureContainer() {
        AppConfig appConfig = new AppConfig();

        MemberService memberService1 = appConfig.memberService();
        MemberService memberService2 = appConfig.memberService();

        System.out.println("memberService1: " + memberService1);
        System.out.println("memberService2: " + memberService2);

        assertThat(memberService1).isNotSameAs(memberService2);
    }

위의 코드는 AppConfig 클래스를 이용해 MemberService 객체를 두 번 호출을 한 후 memberService1과 memberService2의 참조값을 비교하는 테스트 코드입니다. 참조값을 비교해보면 다른 것을 확인할 수 있고, 이는 매번 객체를 호출할 때마다 새로운 인스턴스가 만들어지고, 이는 메모리 낭비로 이어질 수 있습니다.

위의 문제점을 해결하기 위해 싱글톤 패턴을 구현해보고 테스트를 다시 한 번 해보았습니다.

package springproject.basicspring.singleton;

// 싱글톤 패턴을 구현하는 방법은 여러가지가 있고, 이 코드에서 사용한 방법은 객체를 미리 생성해두는 가장 단순하고 안전한 방법이다.
public class SingleTonService {

    //1. static 영역에 객체를 딱 1개만 생성해둔다.
    private static final SingleTonService instance = new SingleTonService();

    //2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다.
    public static SingleTonService getInstance() {
        return instance;
    }

    //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 만든다.
    private SingleTonService() {
    }

    public void login() {
        System.out.println("싱글톤 객체 로직 호출");
    }

}

    @Test
    @DisplayName("싱글톤 패턴을 적용한 객체 사용")
    void singletonServiceTest() {
        SingleTonService singleTonService1 = SingleTonService.getInstance();
        SingleTonService singleTonService2 = SingleTonService.getInstance();

        System.out.println("singleTonService1: " + singleTonService1);
        System.out.println("singleTonService2: " + singleTonService2);

        assertThat(singleTonService1).isSameAs(singleTonService2);
    }

위의 코드들은 싱글톤 패턴을 자바로 구현을 한 코드입니다. 객체의 인스턴스를 static을 사용해 static 영역에 미리 생성해 올려주고, 객체 인스턴스가 필요할 때는 getInstance() 메서드를 통해서만 접근할 수 있게 해 항상 동일한 인스턴스를 반환하게 해줍니다. 그 후 객체의 생성자를 private로 선언하여 외부에서 new 키워드를 사용해 인스턴스를 생성하지 못하도록 해주었습니다.

테스트 코드에서 하나의 인스턴스만 생성하는지 확인해보면 두 번의 getInstance() 호출이 동일한 객체를 반환하는 것을 확인할 수 있습니다. 이처럼 싱글톤 패턴은 객체를 하나만 생성하여 여러 곳에서 공유할 수 있도록 해줍니다.

하지만 이 패턴에도 몇 가지 단점이 있습니다. 우선 getInstance()와 같은 메서들르 직접 구현해야 하며 클라이언트가 구체 클래스에 의존하게 되어 DIP와 OCP를 위반할 수 있습니다. 그로 인해 코드의 유연성이 떨어지고 안티패턴이라고도 불리기도 합니다. 그러나 스프링 프레임워크를 사용하면 이러한 단점들을 해결하고 싱글톤을 사용할 수 있습니다.

스프링 컨테이너는 @Configuration 어노테이션이 붙은 설정 파일을 통해 객체 간의 의존관계를 설정하고 관리합니다. 이를 통해 애플리케이션 내에서 Bean을 싱글톤으로 관리할 수 있습니다. 그로 인해 직접 싱글톤 패턴을 구현할 필요 없이 객체를 효율적으로 관리할 수 있습니다.

package springproject.basicspring;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import springproject.basicspring.discount.DiscountPolicy;
import springproject.basicspring.discount.FixDiscountPolicy;
import springproject.basicspring.discount.RateDiscountPolicy;
import springproject.basicspring.member.MemberRepository;
import springproject.basicspring.member.MemberService;
import springproject.basicspring.member.MemberServiceImpl;
import springproject.basicspring.member.MemoryMemberRepository;
import springproject.basicspring.order.OrderService;
import springproject.basicspring.order.OrderServiceImpl;

@Configuration
public class AppConfig {

    //@Bean memberService -> new MemoryMemberRepository()
    //@Bean orderService -> new MemoryMemberRepository()
    // -> 싱글톤이 깨지는 거 아닐까??

    //AppConfig.memberService
    //AppConfig.memberRepository
    //AppConfig.memberRepository
    //AppConfig.orderService
    //AppConfig.memberRepository

    //AppConfig.memberService
    //AppConfig.memberRepository
    //AppConfig.orderService

    @Bean
    public MemberService memberService() {
        System.out.println("AppConfig.memberService");
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public MemberRepository memberRepository() {
        System.out.println("AppConfig.memberRepository");

        return new MemoryMemberRepository();
    }

    // 스프링 컨테이너가 @Bean 메서드를 오버라이딩하여 싱글톤을 보장하는 프록시 메커니즘을 사용
    // 아래와 같이 static을 붙이면 static 메서드는 스프링 컨테이너에 의해 오버라이딩되어 관리될 수 없기 때문에
    // 싱글톤으로 관리되지 않는다.
//    @Bean
//    public static MemberRepository memberRepository() {
//        return new MemoryMemberRepository();
//    }

    @Bean
    public OrderService orderService() {
        System.out.println("AppConfig.orderService");

        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }
    @Bean
    public DiscountPolicy discountPolicy() {
//        return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }


}

위의 AppConfig 클래스 또한 스프링 설정 파일로 각 서비스 객체를 빈으로 등록해 사용합니다. 테스트 코드를 통해 MemberService 객체를 두번 호출하고 그 참조값을 비교해보면

    @Test
    @DisplayName("스프링 컨테이너와 싱글톤")
    void springContainer() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        MemberService memberService1 = ac.getBean("memberService", MemberService.class);
        MemberService memberService2 = ac.getBean("memberService", MemberService.class);

        // 참조값이 같은 것을 확인
        System.out.println("memberService1: " + memberService1);
        System.out.println("memberService2: " + memberService2);

        // memberService1 == memberService2
        assertThat(memberService1).isSameAs(memberService2);
    }

예상했던 바와 같이 두 객체의 참조값이 동일함을 확인할 수 있습니다. 이를 통해 스프링이 기본적으로 빈을 싱글톤으로 관리한다는 것을 알 수 있습니다.

스프링에서 싱글톤 패턴을 사용할 때는 주의할 점이 있습니다. 싱글톤 빈은 여러 클라이언트가 동일한 인스턴스를 공유하기 때문에 상태를 가지지 않도록 해야 합니다.

package springproject.basicspring.singleton;

public class StatefulService {

    // statefulService
    private int price;

    public void order(String name, int price) {
        System.out.println("name = " + name + ", price = " + price);
        this.price = price;
    }

    public int getPrice() {
        return price;
    }

    // 무상태로 코드 짜는 법

//    public int order(String name, int price) {
//        System.out.println("name = " + name + ", price = " + price);
//        return price;
//
//    }



}

package springproject.basicspring.singleton;

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;

import static org.junit.jupiter.api.Assertions.*;

class StatefulServiceTest {

    @Test
    void statefulServiceSingleton() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(StatefulService.class);
        StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

//        int userAPrice = statefulService1.order("userA",10000);
//        int userBPrice = statefulService2.order("userB",20000);

        // ThreadA: A사용자 10000원 주문
        statefulService1.order("userA", 10000);
        // ThreadB: B사용자 20000원 주문
        statefulService2.order("userB", 20000);

        // ThreadA: 사용자A 주문 금액 조회
        int price = statefulService1.getPrice();
        System.out.println("price = " + price);
//        System.out.println("price = " + userAPrice);


        Assertions.assertThat(price).isEqualTo(20000);

    }

    static class TestConfig {

        @Bean
        public StatefulService statefulService() {
            return new StatefulService();
        }
    }

}

StatefulService 클래스는 상태를 유지하는 필드 price를 가지고 있습니다. 이 상태를 가지는 필드 때문에 특정 클라이언트가 값을 변경하면 다른 클라이언트들에게도 영향을 미치게 됩니다. 테스트코드를 보시면 두 사용자가 각각 주문을 했을 때, 사용자 A의 주문 금액이 10000원이 아니라 20000원이 출력되는 것을 확인할 수 있습니다. 이는 상태를 가지는 싱글톤 빈의 문제점을 잘 보여주고 그로 인해 스프링 빈은 항상 상태를 가지지 않게 설계해야 합니다.

추가로 스프링 프레임워크를 사용해서 만든 모든 빈이 싱글톤으로 관리되는 것은 아닙니다.스프링 프레임워크에서의 빈의 기본 스코프는 싱글톤이지만, Scope 어노테이션을 사용하면 필요에 따라 빈의 스코프를 설정할 수 있습니다. 그리고 싱글톤 객체의 크기가 클 때에는 객체를 스코프 설정을 통해 싱글톤을 관리하지 않는게 더 메모리에 효율적일 수도 있습니다. 그 이유는 싱글톤 객체가 너무 많은 메모리를 차지하는 경우, 이 객체가 애플리케이션이 종료될 때까지 메모리를 점유하기 때문에 프로그램이 더 이상 필요하지 않은 메모리를 해제하지 않고 계속해서 점유하고 있는 메모리 릭이 발생할 수 있기 때문입니다.

DNS와 HTTP의 특성

Sun, 25 Aug 2024 09:58:36 GMT

DNS

DNS의 개념에 대해서 말씀드리면 주소창에 google.com 같은 주소를 검색할 때에 컴퓨터가 이런 문자로 된 주소를 이해할 수 있도록 google.com이라고 입력하면, IP주소로 바꿔주는 역할을 하는 시스템입니다.

예를 들어, 전화번호부에서 전화를 하고 싶은 이름을 검색하면 전화번호를 알 수 있듯이 DNS도 웹사이트 이름을 입력하면, DNS가 그 이름에 해당하는 IP 주소를 찾아서 알려주는 역할을 합니다.

DNS는 단순히 하나의 서버가 일을 하는 게 아니라, 여러 단계로 나눠져 있습니다. 이런 식으로 여러 단계로 나뉜 이유는 인터넷이 너무 커서 모든 정보를 한 서버에 다 저장할 수 없기 때문에 여러 서버가 나눠서 정보를 관리하고 있어.

루트 네임 서버

인터넷의 최상위 서버로 사용자가 웹사이트에 접속하려고 할 때, 가장 먼저 이 루트 서버에 물어보는 겁니다. 이 서버는 사용자가 찾는 웹사이트가 어디에 있는지 정확히는 모르지만, 다음에 물어볼 서버를 알려줍니다.

TLD 서버

이건 최상위 도메인 서버입니다. 예를 들어, .com, .kr, .edu 같은 도메인을 관리하는 서버입니다. 루트 서버가 "이 웹사이트는 .com에 있어"라고 알려주면, 이 TLD 서버에 가서 "그럼 구체적으로 어디에 있어?"라고 물어보게 됩니다.

Authoritative DNS 서버

마지막으로 이 서버는 우리가 찾는 웹사이트의 실제 IP 주소를 가지고 있습니다. 그러니까 이 서버가 최종적으로 "구글은 여기 있어! 이 IP 주소를 써!"라고 답해주게 됩니다.

DNS 질의 방식

DNS에는 반복적 질의 방식과 재귀적 질의 방식이 있습니다.

반복적 질의: 사용자가 루트 서버한테 물어보고, 루트 서버가 "난 잘 모르겠는데, 이 서버한테 물어봐"라고 하면, 사용자가 직접 그 서버한테 또 물어보는 방식입니다. 계속 사용자가 직접 물어보는 거라서 반복적 질의라고 한다고 합니다.
재귀적 질의: 이건 사용자가 처음 물어본 DNS 서버가 대신 다 알아봐 주는 방식입니다. 사용자가 한 번만 물어보면 되고, 나머지는 서버가 알아서 다 해주게 됩니다. 그래서 이걸 재귀적 질의라고 불러.

DNS 레코드

DNS 서버에는 여러 가지 정보가 저장되어 있는데 이 정보를 DNS 레코드라고 부릅니다.

A 레코드: 도메인 이름에 대한 IPv4 주소를 저장합니다. 이게 우리가 주로 사용하는 IP 주소 형식입니다.
AAAA 레코드: 이건 IPv6 주소를 저장합니다. IPv6는 좀 더 긴 형식의 IP 주소입니다.
CNAME 레코드: 도메인의 별칭을 저장합니다. 예를 들어 www.example.com이 실제로는 example.com의 다른 이름이라면, 이걸 CNAME 레코드가 저장합니다.
NS 레코드: 이건 도메인을 관리하는 네임 서버의 정보를 저장합니다. 예를 들어, google.com을 관리하는 네임 서버가 어디 있는지를 이 레코드가 알려줘.

DNS 캐싱

DNS 캐싱은 우리가 자주 방문하는 웹사이트의 IP 주소를 미리 저장해 두는 겁니다. 이렇게 하면 웹사이트에 접속할 때마다 DNS 서버에 물어볼 필요가 없어서 더 빠르게 접속할 수 있습니다. 이 캐시된 정보는 일정 시간 동안만 유효합니다. 이 시간을 TTL이라고 하는데, 시간이 지나면 캐시가 만료되고 다시 물어봐야합니다.

이런 식으로 DNS는 우리가 매일 인터넷을 편리하게 사용할 수 있게 도와주는 시스템입니다. 평소에는 잘 느끼지 못하지만, DNS로 인해서 우리는 숫자로 된 IP 주소를 외우지 않고도 편하게 웹사이트를 이용할 수 있습니다.

자원과 자원의 식별

네트워크에서 자원이란?

네트워크에서의 자원은 네트워크를 통해 주고받을 수 있는 모든 정보를 말합니다. 예를 들어, 우리가 웹사이트를 방문할 때 보는 HTML 파일, 웹에서 다운로드하는 이미지나 동영상, JSON 파일 같은 것들이 모두 자원에 속합니다. 간단히 말해서, 인터넷에서 우리가 요청하고 받을 수 있는 모든 데이터가 자원입니다.

네트워크에서 자원을 사용하려면, 이 자원을 식별할 수 있어야 합니다. 자원이 어디에 있는지, 그리고 그 자원이 무엇인지를 정확하게 지정해줘야 하기 때문에 등장한 개념이 URI입니다.

URI(Uniform Resource Identifier)

자원을 식별할 수 있는 문자열로 쉽게 말해, 인터넷 상의 자원을 가리킬 수 있는 주소 같은 역할을 하고 이 URI는 크게 두 가지로 나뉩니다.

URL(Uniform Resource Locator) 자원의 위치를 기반으로 식별하며 흔히 보는 웹 주소가 바로 URL이야. 예를 들어, https://www.example.com 같은 게 URL이며 이 주소는 자원이 어디에 있는지를 알려줍니다.
URN(Uniform Resource Name) 자원의 이름을 기반으로 식별합니다. 위치는 상관없이, 그 자원의 고유한 이름을 사용하는 방식입니다. 하지만 일상적으로는 URL이 더 많이 사용돼서 URN은 상대적으로 덜 알려져 있어.

URL의 구성 요소

URL을 보면, 그냥 긴 문자열처럼 보일 수 있는데, 사실은 여러 구성 요소가 있습니다.

Scheme: 주로 프로토콜 이름이 들어가는 부분으로 예를 들어, http://, https://, ftp:// 같은 게 여기에 들어갑니다. 이 부분은 브라우저에게 어떤 방식으로 자원에 접근해야 하는지를 알려줍니다.
Authority: 이 부분은 주로 도메인 이름과 포트 번호로 구성됩니다. 예를 들어 www.example.com:80에서 www.example.com은 호스트 이름(도메인 이름), :80은 포트 번호입니다. 여기서는 Authority가 자원이 어디에 있는지를 더 구체적으로 지정해줍니다.
Path: 이건 자원이 서버 내에서 어디에 있는지를 나타내는 경로입니다. 예를 들어 https://www.example.com/images/logo.png에서 /images/logo.png가 경로입니다. 서버 안에서 그 자원이 저장된 위치를 알려줍니다.
Query: 이건 주로 서버에 전달하는 추가적인 정보로 예를 들어, 검색할 때 https://www.google.com/search?q=example처럼 URL 뒤에 ?q=example 같은 형식이 Query로 서버에 전달될 정보입니다.
Fragment: 이건 자원의 특정 부분을 가리킬 때 사용되며 예를 들어 긴 문서의 특정 섹션으로 바로 이동하고 싶을 때 사용합니다. URL 끝에 #section1 같은 형식으로 붙어. 예를 들어 https://www.example.com/page#section1 에서 #section1입니다.

URL 해석

URL은 처음엔 복잡해 보일 수 있지만, 위의 구성 요소들을 알고 나면 해석하기가 쉬워진다고 합니다. https://john.doe@www.example.com:123/forum/questions/?tag=networking&order=newest#top이라는 URL을 보면, 이 안에는 다양한 정보가 들어있어:

Scheme: https Authority: john.doe@www.example.com:123 (여기서 john.doe는 사용자 정보, www.example.com은 호스트, 123은 포트 번호야) Path: /forum/questions/ Query: ?tag=networking&order=newest (여기서 tag=networking과 order=newest가 서버에 전달될 정보야) Fragment: #top (이건 자원의 특정 부분, 즉 페이지의 맨 위를 가리키는 거지)

웹 서버와 웹 어플리케이션 서버

서버와 클라이언트의 기본 개념

서버와 클라이언트의 관계에 대해서 간단하게 말해보자면 클라이언트는 요청을 보내는 쪽이고, 서버는 그 요청에 대해 응답을 보내는 쪽입니다. 예를 들어, 우리가 웹 브라우저에서 google.com을 입력하면, 브라우저는 클라이언트가 되고, 구글의 서버는 우리에게 페이지를 보여주기 위해 응답을 보내는 서버가 되는 겁니다.

웹 서버와 웹 애플리케이션 서버의 차이

웹 서버(Web Server): 주로 정적인 자원을 제공합니다. 여기서 정적인 자원이라는 건, 예를 들어 HTML 파일, 이미지, 동영상처럼 언제, 어디서, 누가 보든지 내용이 변하지 않는 파일들을 말합니다. 이런 파일들은 이미 서버에 저장돼 있고, 요청이 오면 그대로 제공되기만 하면 됩니다. 그래서 웹 서버는 단순히 클라이언트의 요청에 따라 이런 정적인 파일들을 제공하는 역할을 합니다.

웹 애플리케이션 서버(WAS: Web Application Server): 반면에, WAS는 동적인 자원을 제공합니다. 동적인 자원이란 사용자가 누구인지, 또는 언제, 어디서 요청을 하느냐에 따라 내용이 달라질 수 있는 데이터를 말합니다. 예를 들어, "오늘의 날씨는 20도입니다"와 같이, 사용자가 있는 위치나 시간에 따라 변할 수 있는 정보를 제공하는 겁니다. WAS는 이런 정보를 생성하기 위해 데이터베이스와 상호작용해서, 사용자 맞춤형 데이터를 만들어 클라이언트에게 제공합니다.

웹 서버와 WAS의 협력 현대적인 웹 서비스는 웹 서버와 WAS가 서로 협력해서 동작합니다. 웹 서버는 빠르게 정적인 자원을 제공하고, WAS는 필요한 경우 데이터베이스와 상호작용해 동적인 정보를 생성합니다. 이렇게 역할을 분담하면, 전체 시스템이 더 효율적으로 작동하고, 과도한 부하도 막을 수 있고 또한, 보안적인 측면에서도 이점이 있습니다. 왜냐하면, 정적인 자원과 동적인 자원이 분리되어 있기 때문에 각각의 보안을 별도로 관리할 수 있기 때문입니다

HTTP의 특성

HTTP의 기본 개념

먼저, HTTP는 HyperText Transfer Protocol의 약자야. 이 프로토콜은 주로 웹 브라우저와 웹 서버 간에 데이터를 주고받을 때 사용됩니다. 예를 들어, 사용자가 웹사이트를 방문할 때, 브라우저는 HTTP를 사용해서 웹 서버에 "이 페이지를 보여줘!"라고 요청을 보내고, 서버는 그 요청에 응답해서 페이지를 보내줍니다. 이 과정은 요청-응답 기반의 클라이언트-서버 구조로 작동합니다. 여기서 클라이언트는 요청을 보내는 쪽(보통 웹 브라우저), 서버는 그 요청에 응답하는 쪽입니다.

HTTP의 주요 특성

미디어-독립적 HTTP는 어떤 형태의 데이터든지 전송할 수 있습니다. 예를 들어, HTML 문서, 이미지, 동영상, JSON 데이터, XML 파일 등 어떤 데이터라도 HTTP를 통해 전송할 수 있습니다. 그래서 HTTP는 매우 유연한 프로토콜로, 다양한 종류의 데이터를 처리할 수 있어.
비연결성 HTTP는 기본적으로 비연결성 프로토콜입니다. 클라이언트가 서버에 요청을 보내고, 서버가 응답을 보내면 그 연결이 바로 끊어집니다. 이렇게 하면 서버의 자원을 효율적으로 사용할 수 있습니다. 그 이유는 연결을 계속 유지하면 서버 자원이 많이 소모되기 때문입니다. 하지만, 최근의 HTTP/1.1부터는 이러한 비연결성을 개선하기 위해 지속 연결(Keep-Alive) 기능이 추가되었습니다. 이 기능 덕분에, 한 번 연결을 맺으면 그 연결을 유지하면서 여러 요청을 보낼 수 있게 되었습니다.
스테이트리스: HTTP는 스테이트리스 프로토콜입니다. 이는 서버가 클라이언트의 상태를 기억하지 않는다는 뜻입니다. 예를 들어, 사용자가 웹사이트에서 여러 페이지를 방문해도, 서버는 이전 페이지에서 사용자가 뭘 했는지 기억하지 않습니다. 이 덕분에 서버 확장이 용이해지고, 사용자가 여러 서버에 요청을 보내더라도 문제가 없게 됩니다.
지속 연결 (Keep-Alive): 앞서 말한 것처럼, HTTP/1.1부터는 지속 연결 기능이 추가됐습니다. 이 기능은 한 번 연결된 상태에서 여러 개의 요청과 응답을 주고받을 수 있게 해줍니다. 이렇게 하면 매번 새로운 연결을 맺기 위해 시간을 낭비하지 않아도 돼서, 네트워크 혼잡을 줄이고, 페이지 로딩 속도도 빨라지게 됩니다.

HTTP 버전의 진화

HTTP 0.9: 가장 초기 버전으로, GET 메서드만 지원하고 비지속 연결이었으며 기능이 매우 제한적이었습니다.
HTTP 1.0: 다양한 요청 방법과 헤더를 지원하게 되었지만여전히 비연결성 프로토콜이었어습니다.
HTTP 1.1: 지속 연결 기능이 추가되었고 한 번 연결된 상태에서 여러 요청을 보낼 수 있는 기능이 들어갔습니다.
HTTP 2.0: 성능이 크게 개선되었습니다. 예를 들어, 요청이 꼭 순서대로 처리될 필요가 없어졌고, 헤더 데이터를 압축해서 전송할 수 있게 됐습니다.
HTTP 3.0: 최신 버전으로, TCP 대신 UDP 기반 프로토콜인 QUIC을 사용해 더 빠르고 안전한 연결을 제공합니다

스프링+MySQL+RDS+EC2 배포과정

Sat, 17 Aug 2024 10:04:07 GMT

스프링에서 MySQL DB를 쓰면서 AWS의 RDS와 EC2를 이용해서 배포를 하는 방법을 간단하게 작성해보려고 한다.

우선 DB를 RDS에서 MySQL을 빌려서 연결을 한 후에 EC2를 이용해서 배포를 해보려고 한다. 그 이유는 RDS에서 DB를 사용하지 않고 EC2를 써봤는데 NullPointException과 BeanCreationException이 발생했기 떄문이다.

스프링 프로젝트에 의존성 추가

 implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
 runtimeOnly 'com.mysql:mysql-connector-j'
 implementation 'org.springframework.boot:spring-boot-starter-web'

AWS RDS에 접속해서 MySQL 빌리기

DB인스턴스 식별자, 마스터 사용자 이름, 마스터 암호는 원하는대로 작성하면 된다.

프리티어는 db.t3와 db.t2만 사용할 수 있어서 db.t3를 사용했다.

초기 데이터베이스 이름을 프로젝트의 db이름인 catch_line으로 설정하고 자동 백업을 활성화하면 비용이 청구가 되기 때문에 비활성화로 설정했다.

그 후 만든 인스턴스의 보안 그룹으로 들어가 인바운드 규칙 편집에서

MySQL의 default 포트인 3306을 IPv4 Anywhere로 Ipv4를 사용하는 누구나 사용할 수 있게 설정했다.

application.properties에 데이터베이스 정보 추가

spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://주소:포트/데이터베이스?useSSL=false&useUnicode=true&serverTimezone=Asia/Seoul&allowPublicKeyRetrieval=true
spring.datasource.username=아이디
spring.datasource.password=비밀번호

RDS를 만들면서 설정한 아이디와 비밀번호를 입력하면된다. 포트와 비밀번호는 나같은 경우에는 포트:3306, 데이터베이스는 RDS의 데이터베이스에 들어가면 엔드포인트를 볼 수 있는데 그 엔드포인트를 입력하면 된다.

그 후 스프링 프로젝트를 실행시켜서 제대로 동작한다면 RDS에서 빌린 MySQL 데이터베이스에 접속이 잘 된 것이다.!

이번에는 EC2를 이용해서 RDS에서 MySQL 데이터베이스를 빌려서 사용하고 있는 스프링 프로젝트를 배포해보겠다.

스프링 부트 jar파일 생성하기

인텔리제이 -> Gradle -> Tasks -> build -> bootJar을 더블클릭하면 Jar파일이 프로젝트의 폴더의 build -> libs 안에 생성된다. 그 파일을 바탕화면으로 옮겨놓으면 된다.!

EC2 인스턴스 생성

EC2 -> 인스턴스 생성에 들어가 설정을 완료하면 된다.

이름을 원하는대로 설정하고, db를 애플리케이션 및 OS 이미지를 Ubuntu로 설정했다.

다음으로 키페어 생성을 클릭하고, 나는 OpenSSh(Git Bash)를 사용했기 때문에 프라이빗 키 파일 형식을 .pem으로 설정한 후 키페어를 생성하면 된다. 키 페어를 생성한 후 바탕화면에 옮겨놓는다.

그 후에 스토리지 구성을 약 10GIB로 설정하고 인스턴스 시작을 누른다.

AWS EC2 컴퓨터에 접근할 수 있는 포트를 열기

EC2 좌측 카테고리 -> 보안그룹 -> 인바운드 규칙 편집 -> 규칙 추가 -> 8080과 3360 추가

인스턴스에 들어가 생성한 인스턴스 -> 우클릭 -> 연결 -> SSH 클라이언트 에 들어가면 인스턴스에 접속할 수 있는 방법이 나온다.

인스턴스 접속

Git Bash 접속 -> cd ~/Desktop (바탕화면으로 이동) -> chmod 400 mainkey.pem (키페어에 권한 주기) -> 권한을 가진 키페어를 통해 ssh 접속을 할 수 있다 -> ssh -i mainkey.pem ~~~~~~ (~는

예: 에서 unbuntu부터 끝까지이다.) (ssh 접속)

-> yes -> ssh 접속 완료 -> 서버 컴퓨터에 jvm(자바)를 설치해야 하기 때문에 우선 java가 존재하는지 확인하기 위해 java -version 명령어를 친다. -> java가 설치되어 있지 않다면 -> java를 설치하기 위해 apt를 업데이트 한다 - > sudo apt update ( apt 업데이트) -> sudo apt install openjdk-17-jre-headless (java 17버전 설치) (다른 버전 설치해도 상관없다) -> AWS EC2 서버에 로컬에 있는 스프링 부트 jar 파일을 서버로 가져와야 한다. -> 기존 EC2에 연결된 bash 쉘에 추가로 git bash를 열어 하나 더 실행시킨다. -> cd ~/Desktop -> ls (jar파일 확인) -> chmod 400 mainkey.pem(서버에 접근하기 위해 권한 주기) -> scp -i "키페어.pem" ~/Desktop/파일이름.jar (ubuntu@IP:~/받을서버경로) (jar파일 EC2 서버에 전송) ((~~~)는 위에 말했던 SSH 클라이언트 글에서 예: 밑에 써있는 코드에서 ubuntu부터 쭉 쓰면 된다!! )

EC2서버에 jar 파일을 전송하면 로컬에 연결된 bash는 종료하고 ec2서버에 연결된 bash 에서 ls를 해 jar 파일이 제대로 전송되었는지 확인한다

이제 마지막으로 jvm으로 파일을 작동시키면 된다!

sudo java -jar 파일이름.jar

이렇게 jar을 실행시키고

url에 54.180.235.56:8080 을 검색하면 내가 서버에 올린 프로젝트를 볼 수 있다!!

마지막으로 git bash를 꺼도 서버가 종료되지 않게 하기 위해서는

jar파일을 실행 시킬 때 sudo nohup java -jar [jar파일이름] & 이 코드로 실행시키면된다.

종료할때에는

ps -ef | grep catch_line-0.0.1-SNAPSHOT.jar 이런식으로 PID 번호를 찾은 후 가장 위에 있는 PID 번호를 sudo kill -9 [맨 위에 있는 PID 번호] 종료시켜주면 된다!!

TCP 연결, 상태, 재전송, 혼잡 제어와 흐름제어

Thu, 15 Aug 2024 13:31:24 GMT

TCP 연결

TCP는 전송 제어 프로토콜로 인터넷에서 데이터를 신뢰성 있게 송수신 하기 위한 프로토콜로 TCP 연결의 주요 과정은 연결 설정, 데이터 송수신, 연결 종료로 나눌 수 있습니다

우선 용어에 대해서 간단히 말씀 드리면 액티브 오픈 호스트는 연결 설정을 시작하는 호스트이고, 주로 클라이언트의 역할을 말한다고 합니다. 그리고 패시브 오픈 호스트는 연결 요청을 수신하고 수락하는 호스트로 주로 서버 역할을 한다고 합니다.

연결 설정: TCP 연결을 설정하는 과정은 Three-Way-Handshake라는 세 단계의 절차를 통해 이루어집니다.

SYN (Synchronize) 단계 액티브 오픈 호스트가 연결을 시작하고 싶을 때, 먼저 SYN 패킷을 보내는 것으로 연결 요청을 합니다. SYN 패킷은 연결 설정을 위한 초키 시퀀스 번호와 기타 정보를 포함하고 있다고 합니다.
SYN-ACK (Synchronize-Acknowledge) 단계 패시브 오픈 호스트가 이 요청을 수신하면, 연결을 수락할 준비가 되었음을 알리기 위해 SYN-ACK 패킷을 반환합니다. 이 패킷은 수신자가 보낸 SYN에 대한 응답으로 수신자의 SYN과 ACK를 포함합니다
ACK (Acknowledge) 액티브 오픈 호스트가 SYN-ACK 패킷을 수신하면 마지막으로 ACK 패킷을 보내 연결을 확인합니다. 이 패킷은 상대방의 SYN-ACK 패킷을 확인 응답하며, 이제 양쪽 호스트가 서로의 존재를 인식하고 연결이 설정 됩니다.

연결 종료 과정: Four-Way-Handshake라고 하는 네 가지 단계로 이루어진다고 합니다

FIN (Finish) 액티브 클로즈 호스트가 연결 종료를 시작하고, 이 호스트는 더 이상 데이터를 송신하지 않겠다는 신호를 보내기 위해 FIN 패킷을 전송합니다. 이 패킷은 연결 종료를 요청하는 신호로, 송신자는 이 패킷을 통해 자신의 데이터 전송을 종료하겠다는 의사를 표현합니다
ACK (Acknowledge) 패시브 클로즈 호스트는 FIN 패킷을 수신한 후 이를 확인하기 위해 ACK 패킷을 반환합니다. ACK 패킷은 FIN 패킷에 대한 응답으로 수신자는 송신 호스트의 종료 요청을 수락했음을 나타냅니다 이때 패시브 클로즈 호스트는 자신의 데이터 전송을 계속할 수 있다고 합니다
FIN (Finish) 패시브 클로즈 호스트가 자신의 데이터 전송을 완료하고 연결 종료를 원할 때 FIN 패킷을 송신합니다.
ACK (Acknowledge) 액티브 클로즈 호스트가 패시브 클로즈 호스트가 보낸 FIN 패킷을 수신한 후, 이를 확인하기 위해 ACK 패킷을 반환합니다.

이런 과정을 통해 데이터 손실 방지, 완전한 종료, 시간 지연 방지, 상태 일관성 유지를 할 수 있다고 합니다.

TCP 상태

TCP는 연결형 프로토콜이자 스테이트풀 프로토콜이라고 합니다. 이는 TCP가 연결 상태를 유지하고, 관리하며 다양한 상태를 통해 안정적이고 신뢰성 있는 통신을 제공한한다는 것을 의미합니다.

TCP 연결의 주요 상태 중 대표적인 것으로는

CLOSED: 연결이 완전히 종료된 상태로 모든 자원이 해제되고, 상태가 초기화되는 상태입니다.
LISTEN, SYN-SENT, SYN-RECEIVED: 연결 수립 도중 사용되는 상태 LISTEN은 서버가 클라이언트의 연결 요청을 기다리는 상태, SYN-SENT는 클라이언트가 연결 요청을 보내고, 서버의 응답을 기다리는 상태로 클라이언트가 이 상태에서 SYN 패킷을 보내고, SYN-ACK 패킷을 기다립니다. SYN-RECEIVED는 서버가 클라이언트의 연결 요청을 수신하고, 응답을 보낸 후에 있는 상태입니다.
ESTABLISHED: 클라이언트와 서버 간에 연결이 설정된 상태로, 데이터 송수신이 가능한 상태로, 양쪽 호스트가 데이터를 교환할 수 있습니다.
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT: 연결 해제시 사용되는 상태

이중에서 TIME-WAIT 상태는 액티브 클로즈 호스트가 FIN 패킷을 보내고 마지막으로 ACK 패킷을 수신한 후에 들어가는 상태로 주된 역할로는

마지막 ACK 세그먼트의 유실 대비: 만약 ACK 패킷이 유실되면, 상대방 호스트는 FIN 패킷을 재전송할 수 있으며, TIME-WAIT 상태를 통해 이 재전송을 수신하고 정상적으로 종료할 수 있습니다
패킷 혼선 방지: 네트워크에서 이전 연결의 패킷이 지연되어 새로운 연결에 영향을 미치는 것을 막기 위해 TIME-WAIT 상태에서 일정 시간 동안 기다리며 이 시간을 통해 이전 연결의 패킷이 네트워크에서 소멸되도록 합니다.

TCP 재전송 기능

TCP는 데이터가 정확히 전달되도록 보장하기 위해 재전송 기반의 오류 제어를 사용합니다. 이 기법은 잘못된 데이터 전송을 수정하기 위해 데이터 패킷을 재전송하는 방식입니다. 주요 특징으로는 두 가지가 있습니다.

ARQ (Automatic Repeat reQuest): 자동 재전송 요구 방식으로, 송신자가 패킷 전송 후 확인 응답을 기다리고, 응답이 오지 않거나 오류가 발생한 경우 패킷을 재전송하는 방식입니다.
타임아웃: 송신자는 데이터 패킷을 보낸 후, 일정 시간 동안 확인 응답을 기다리고 일정 시간 초과하면 패킷이 손실된 것으로 간주하고, 해당 패킷을 재전송합니다

잘못된 데이터 전송을 인지하는 오류 인지 방법에 대해서 말씀드리겠습니다.

중복된 ACK 세그먼트를 수신했을 때

수신 호스트가 동일한 데이터 패킷을 여러 번 수신했거나, 패킷이 손실되어 후속 패킷이 도착하지 않은 경우, 송신 호스트는 중복된 ACK 세그먼트를 수신할 수 있습니다.
빠른 재전송 (Fast Retransmit): 중복된 ACK 세그먼트를 일정 횟수(일반적으로 세 번) 수신하면, 송신자는 타이머가 만료되기 전에 손실된 패킷을 즉시 재전송하는 방식또한 있습니다. 이 방식은 타이머가 만료되기 전에 오류를 빠르게 감지하고 수정할 수 있게 합니다.

타임아웃이 발생했을 때

타임아웃: 송신자는 패킷을 보내고 일정 시간 동안 ACK를 기다립니다. 타이머가 만료되면, 해당 패킷이 손실된 것으로 간주하고, 패킷을 재전송합니다.

재전송 기법은 데이터 패킷을 효율적으로 관리하기 위한 방법으로, 다음과 같은 방식이 있습니다

Stop-and-Wait ARQ

단순 재전송: 송신자는 하나의 패킷을 보내고, 그에 대한 ACK를 받을 때까지 기다립니다. ACK를 수신하면 다음 패킷을 전송합니다. 이 방법은 구현이 간단하지만, 데이터 전송 속도가 느릴 수 있습니다. 이렇게 네트워크 이용 효율이 낮아지는 문제가 생기고 이러한 문제를 해결하기 위해 파이프라이닝을 사용합니다. 파이프라이닝은 네트워크 전송에서 여러 데이터 패킷을 연속적으로 송신할 수 있도록 하는 기법입니다.

파이프라이닝의 작동 방식

연속적인 패킷 전송: 파이프라이닝에서는 송신자가 하나의 패킷에 대한 ACK를 기다리지 않고, 여러 개의 패킷을 연속적으로 전송합니다.
윈도우 기반의 관리: TCP에서 파이프라이닝을 지원하는 주요 방법은 슬라이딩 윈도우(sliding window) 기법입니다. 송신자는 윈도우 크기 내에서 여러 패킷을 전송할 수 있으며, 수신자는 이러한 패킷들을 수신하고, 순서대로 ACK를 보내면서 패킷을 처리합니다.

이런 파이프라이닝과 결합한 재전송 기법에 Selective Repeat ARQ와 Go-Back-N ARQ입니다.

Go-Back-N ARQ 연속된 패킷 전송: 송신자는 일정 수의 패킷을 연속적으로 전송하고, 수신 호스트는 각각의 패킷에 대해 ACK를 보냅니다. 만약 N번 패킷이 손실되거나 오류가 발생하면, 송신자는 N번 패킷과 이후 모든 패킷을 재전송합니다.

윈도우 크기: 송신자는 한 번에 전송할 수 있는 패킷의 범위를 정의하며, 이 범위 내에서 패킷을 보내고 ACK를 기다립니다.

Selective Repeat ARQ 개별 패킷 재전송: 송신자는 각각의 패킷에 대해 확인 응답을 받으며, 오류가 발생한 패킷만 재전송합니다. 이 방식은 데이터 전송의 효율성을 높이며, 필요한 패킷만 재전송하므로, 성능이 더 좋습니다.

윈도우 크기: 송신자와 수신자는 각각 개별 패킷의 ACK를 수신하고 전송 상태를 추적합니다.

TCP의 혼잡 제어와 흐름 제어

TCP는 데이터 전송의 신뢰성을 보장하기 위해 두 가지 주요 제어 기법인 흐름 제어와 혼잡 제어를 사용합니다.

흐름 제어 (Flow Control) 흐름 제어는 송신 호스트와 수신 호스트 간의 데이터 전송 속도를 조절하여 수신 호스트가 데이터를 제대로 처리할 수 있도록 보장하는 기법입니다. 송신 호스트는 수신 호스트의 처리 능력에 맞춰 데이터를 송신해야 한다고 합니다

흐름 제어의 주요 구성 요소로는 송신 버퍼와 수신 버퍼가 있습니다. 송신 버퍼는 송신 호스트가 전송할 데이터를 임시로 저장하는 버퍼이고 수신 버퍼는 수신 호스트가 수신한 데이터를 임시로 저장하는 버퍼입니다.

TCP의 흐름 제어는 슬라이딩 윈도우 기법을 통해 이루어집니다. 슬라이딩 윈도우 기법은 송신자가 수신자로부터 ACK를 받기 전에도 여러 패킷을 전송할 수 있도록 하여, 전송 효율성을 높이는 방법입니다. 슬라이딩 윈도우의 구성 요소에는 윈도우가 있습니다. 윈도우는 데이터 전송에서 송신자와 수신자 간의 데이터 흐름을 조절하는 범위로 송신자가 전송할 수 있는 데이터의 범위를 정의합니다. 윈도우는 송신 윈도우와 수신 윈도우로 나뉘는데 송신 윈도우는 송신자가 전송할 수 있는 데이터의 범위이고, 수신자의 버퍼 크기와 송신자의 현재 상태에 따라 결정됩니다. 수신 윈도우는 수신자가 수신할 수 있는 데이터의 범위이고 수신자의 버퍼 크기와 현재 수신 상태에 따라 결정됩니다.

흐름 제어의 목적

수신 호스트가 데이터 처리 속도에 따라 송신 속도를 조절하여, 데이터 손실을 방지하고 효율적인 전송을 보장합니다.
수신 호스트의 버퍼가 가득 차면 송신 호스트는 데이터를 더 이상 전송하지 않으며, 이를 통해 버퍼 오버플로우를 방지합니다.
혼잡 제어 (Congestion Control)

혼잡 제어는 네트워크의 트래픽이 과도해져서 패킷 손실이나 지연이 발생할 수 있는 상황을 조절하는 기법입니다. 네트워크가 혼잡해지면 패킷이 손실되거나 지연될 수 있으므로, 이를 방지하기 위해 송신 호스트가 전송 속도를 조절해야 합니다.

혼잡 제어의 주요 구성 요소로는 혼잡 윈도우가 있습니다. 혼잡 윈도우는 송신 호스트가 네트워크 혼잡 상태를 고려하여 송신할 수 있는 데이터의 양을 정의하는 윈도우입니다. 혼잡 윈도우는 네트워크의 혼잡 정도에 따라 조정됩니다.

주요 혼잡 제어 알고리즘은 세 가지가 있습니다.

느린 시작 (Slow Start):

느린 시작 알고리즘의 작동방식은 송신 호스트가 연결을 시작할 때, 혼잡 윈도우를 작게 설정하고, ACK 세그먼트가 수신될 때마다 혼잡 윈도우 크기를 증가시킵니다. RTT(왕복 시간)마다 혼잡 윈도우를 2배로 증가시켜 네트워크 혼잡을 피하면서 최대 전송 속도를 점진적으로 찾아가는 것입니다.

혼잡 회피 (Congestion Avoidance):

혼잡 회피 알고리즘의 작동 방식은 혼잡 윈도우가 일정 크기에 도달하면, 매 RTT마다 혼잡 윈도우를 1씩 증가시킵니다. 혼잡 회피의 목표는 혼잡 상태를 예방하기 위해, 전송 속도를 천천히 증가시키면서 네트워크의 혼잡을 방지합니다.

빠른 회복 (Fast Recovery):

빠른 회복 알고리즘의 작동 방식은 패킷 손실이 감지되면, 혼잡 윈도우 크기를 급격히 감소시키고, 손실된 패킷을 빠르게 재전송합니다. 손실된 패킷이 재전송된 후, 혼잡 윈도우를 점진적으로 증가시킵니다. 빠른 회복 알고리즘의 목표는 패킷 손실이 발생했을 때, 느린 시작을 건너뛰고 빠르게 네트워크 상태를 회복하는 것입니다.

이러한 혼잡 제어를 통해서 네트워크의 혼잡을 완화하고, 자원을 효율적으로 사용할 수 있습니다.

2024-08-12 ~ 18 개념 정리

Tue, 13 Aug 2024 14:28:55 GMT

제너럴 타입

제너럴 타입은 자바에서 타입 안정성을 높이고, 코드의 재사용성을 개선하기 위해 도입된 기능

클래스나 메서드, 인터페이스에서 구체적인 데이터 타입을 지정하지 않고도 타입을 매개변수로 받아 사용할 수 있다. -> 이는 컴파일 시 타입 체크를 통해 타입 안정성을 보장하며, 런타임 오류를 줄여준다

예를 들어, 'List'와 같은 형태로 제너럴 타입을 사용하면, 리스트의 요소 타입을 제너럴 타입 매개변수 'T'로 정의할 수 있다.


  // 제너럴 타입 T를 사용하는 Box 클래스
public class Box {
    private T content;

    public void setContent(T content) {
        this.content = content;
    }

    public T getContent() {
        return content;
    }

    public static void main(String[] args) {
        // Integer 타입의 Box 객체 생성
        Box integerBox = new Box<>();
        integerBox.setContent(123);
        System.out.println("Integer content: " + integerBox.getContent());

        // String 타입의 Box 객체 생성
        Box stringBox = new Box<>();
        stringBox.setContent("Hello, Generics!");
        System.out.println("String content: " + stringBox.getContent());
    }
}

위의 예제에서 'Box' 클래스는 제너럴 타입 'T'를 사용해 다양한 타입의 객체를 저장할 수 있는 클래스를 정의했다.

  public class Util {
    // 제너럴 메서드
    public static  boolean isEqual(T a, T b) {
        return a.equals(b);
    }

    public static void main(String[] args) {
        // Integer 타입 비교
        boolean result1 = Util.isEqual(10, 10);
        System.out.println("Are integers equal? " + result1);

        // String 타입 비교
        boolean result2 = Util.isEqual("hello", "hello");
        System.out.println("Are strings equal? " + result2);
    }
}

제너럴 타입의 장단점

장점

타입 안정성
코드 재사용성
코드의 가독성

단점
제너럴 타입의 타입 인스턴스화: 제너럴 타입의 인스턴스를 직접 생성할 수 없다. 예를 들어 'new T()'와 같은 생성자는 사용할 수 없다
제너럴 타입의 배열: 제너럴 타입 배열을 직접 생성할 수 없다. 예를 들어 'new T[10]과 같은 형태는 허용되지 않는다.

RestTemplate

RestTemplate는 스프링 프레임워크에서 제공하는 클래스로, Restful 웹 서비스와의 통신을 단순화하고 관리하기 위한 HTTP 클라이언트이다.

주요 기능

HTTP 메서드 지원
요청 및 응답 처리: JSON, XML 등의 다양한 데이터 포맷을 쉽게 처리할 수 있으며, 객체와 문자열 간의 변화를 지원한다
타임아웃 설정: 연결 및 읽기 타임아웃을 설정할 수 있다
요청 헤더 설정: 요청에 다양한 헤더를 추가할 수 있다

사용하는 경우

RESTful 웹 서비스 호출: 외부 RESTful API와 통신 할 때, 데이터 조회, 생성, 업데이트, 삭제 등의 작업을 수행할 때 사용
클라이언트 측 API 통합: 스프링 애플리케이션에서 외부 시스템과의 통합이 필요할 때, RestTemplate를 통해 API호출을 간편하게 처리할 수 있다

서비스 간 통신

기본 사용법 예시


import org.springframework.http.ResponseEntity;
import org.springframework.web.client.RestTemplate;

public class RestTemplateGetExample {

public static void main(String[] args) {
    RestTemplate restTemplate = new RestTemplate();
    String url = "https://jsonplaceholder.typicode.com/posts/1";

    // GET 요청
    ResponseEntity response = restTemplate.getForEntity(url, String.class);

    // 응답 출력
    System.out.println("Response Body: " + response.getBody());
}

}

  위의 코드에서 `restTemplate.getForEntity` 메서드를 사용해서 지정된 URL로 GET요청을 보내고 응답을 `String`으로 받아온다

  ```java
  import org.springframework.http.HttpEntity;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpMethod;
import org.springframework.http.ResponseEntity;
import org.springframework.web.client.RestTemplate;

public class RestTemplatePostExample {

    public static void main(String[] args) {
        RestTemplate restTemplate = new RestTemplate();
        String url = "https://jsonplaceholder.typicode.com/posts";

        // POST 요청에 사용할 객체
        String requestJson = "{ \"title\": \"foo\", \"body\": \"bar\", \"userId\": 1 }";

        // 요청에 사용할 HttpHeaders 설정
        HttpHeaders headers = new HttpHeaders();
        headers.set("Content-Type", "application/json");

        // 요청과 헤더를 포함한 HttpEntity 생성
        HttpEntity request = new HttpEntity<>(requestJson, headers);

        // POST 요청
        ResponseEntity response = restTemplate.exchange(url, HttpMethod.POST, request, String.class);

        // 응답 출력
        System.out.println("Response Body: " + response.getBody());
    }
}

JsonIgnoreProperties(ignoreUnknown)/JsonProperty

@JsonIgnoreProperties와 @JsonPreperty는 Jackson 라이브러리에서 JSON 데이터를 직렬화(객체를 JSON으로 변환)하거나 역직렬화(JSON을 객체로 변환)할 때 사용하는 어노테이션이다

@JsonIgnoreProperties

JSOn 데이터의 직렬화 및 역직렬화 과정에서 특정 속성을 무시하도록 설정할 때 사용한다. 이 어노테이션을 클래스에 적용하면, 지정한 속성들이 JSON으로 직렬화되거나 JSON으로부터 역직렬화되는 과정에서 무시된다

  import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
import com.fasterxml.jackson.databind.ObjectMapper;

@JsonIgnoreProperties(ignoreUnknown = true) // JSON에서 알 수 없는 속성 무시
public class User {
    private String name;
    private int age;

    // getters and setters
    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public static void main(String[] args) throws Exception {
        String json = "{\"name\":\"John\", \"age\":30, \"unknownProperty\":\"value\"}";

        ObjectMapper mapper = new ObjectMapper();
        User user = mapper.readValue(json, User.class);

        System.out.println("Name: " + user.getName());
        System.out.println("Age: " + user.getAge());
    }
}
    ```

  User 클래스의 name과 age만을 처리하고 나머지 속성은 무시한다
  여기에서 ObjectMapper란
```java
    // 객체를 JSON 문자열로 변환
          String jsonString = objectMapper.writeValueAsString(person);

    // JSON 문자열을 자바 객체로 변환
        Person person = objectMapper.readValue(jsonString, Person.class);

@JsonProperty

위의 어노테이션은 JSON 데이터에서 특정 속성의 이름을 자바 객체의 필드에 매핑할 때 사용한다

  import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.databind.ObjectMapper;

public class User {
    @JsonProperty("user_name")
    private String name;

    @JsonProperty("user_age")
    private int age;

    // getters and setters
    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public static void main(String[] args) throws Exception {
        String json = "{\"user_name\":\"John\", \"user_age\":30}";

        ObjectMapper mapper = new ObjectMapper();
        User user = mapper.readValue(json, User.class);

        System.out.println("Name: " + user.getName());
        System.out.println("Age: " + user.getAge());
    }
}

JSON, XML

JSON

JSON은 데이터를 간단하고 읽기 쉬운 형식으로 표현하기 위해 설계된 텍스트 기반의 데이터 포맷이다. 주로 웹 애플리케이션에서 서버와 클라이언트 간의 데이터 교환에 사용한다

특징

형식: 텍스트 기반으로 간결하고 읽기 쉽습니다.
구조: {} (객체)와 [] (배열)로 데이터를 구조화합니다.
데이터 타입: 문자열, 숫자, 객체, 배열, 불리언, null 등이 지원됩니다.
경량: XML보다 데이터 용량이 적어 네트워크 대역폭을 절약할 수 있습니다.
```
{
  "name": "John Doe",
  "age": 30,
  "isEmployee": true,
  "address": {
      "street": "123 Main St",
      "city": "Anytown",
      "state": "CA"
  },
  "phoneNumbers": [
      "555-1234",
      "555-5678"
  ]
}
```
JSON의 장단점 장점
- 간결성, 처리 속도, 호환성 단점
- 데이터 형식 제한, 메타데이터 부족
XML

XML은 데이터를 계층적으로 구조화하고 태그를 사용하여 데이터의 의미를 설명하는 텍스트 기반의 마크업 언어이다. 데이터 저장, 전송, 문서 작성 등 다양한 용도로 사용된다.

특징
형식: 텍스트 기반으로 태그와 속성을 사용하여 데이터를 설명합니다.
구조: 와 로 데이터를 구조화하며, 태그 내에 속성(attribute)을 포함할 수 있습니다.
데이터 타입: 문자열, 숫자 등 단순 데이터 타입 외에 복잡한 구조를 지원합니다.

자체 설명: 태그와 속성을 통해 데이터의 의미를 설명할 수 있습니다


  John Doe
  30
  true
  
      123 Main St
      Anytown
      CA
  
  
      555-1234
      555-5678

Sunwoo’s log

네트워크 면접 키워드 - 1

1. 네트워크 기본 개념

세션과 JWT

인증과 인가란?

세션

JWT

결론적으로 세션 방식의 로그인과 JWT 방식의 로그인 중 하나를 선택할 때에는 사용 환경과 요구 사항에 따라 결정을 해야합니다.

자바 예외란?

예외 계층 그림

예외 기본 규칙

체크 예외

체크 예외의 장단점

언체크 예외

언체크 예외의 장단점

그렇다면 언제 체크 예외를 사용하고 언제 언체크 예외를 사용하면 될까??

1. 복구 불가능한 예외

2. 의존 관계에 대한 문제

언체크 예외 활용

체크 예외와 인터페이스

스프링 데이터 접근 예외 계층

스프링이 제공하는 예외 변환기

DB SIDU와 인덱스와 VIEW

데이터 입력 - INSERT

데이터 조회 - SELECT

연산 및 집계함수

LIKE를 이용한 패턴 검색

GROUP BY & HAVING

서브 쿼리

데디터 수정 - UPDATE

참조 시 UPDATE(on update)

데이터 삭제 -DELET

조건에 맞는 데이터 삭제

테이블의 모든 데이터 삭제

참조 시 DELETE(on delete)

인덱스

인덱스의 부작용

인덱스의 종류

클러스터형 인덱스 (Clustered index)

보조 인덱스 (Secondary index)

VIEW

JOIN

INNER JOIN

LEFT OUTER JOIN

RIGHT OUTER JOIN

FULL OUTER JOIN

관련 면접 질문 리스트

1. WHERE 과 HAVING의 차이점은?

2. 인덱스의 장단점은?

3. DELETE와 TRUNCATE의 차이점은?

4. ON DELETE CASCADE 란?

oAuth 2.0 jwt

쿠키 VS 세션 VS JWT

쿠키 인증 방식

세션 인증 방식

JWT 토큰 방식

Access, Refresh Token

서버-클라이언트 통신 과정

영속성이란?

1. 영속성 컨텍스트

영속성 컨텍스트의 장점

2. 엔티티와 영속성

3. 엔티티의 생명주기

4. 트랜잭션과 영속성

5. 플러시 Flush

6. 변경 감지 Dirty Checking

7. Lazy Loading & Eager Loading

스프링 배치

1. 스케줄러 (Scheduler)

스케줄러의 특징은

2. 배치 (Batch)

배치의 특징은

스케줄러 VS 배치

정적 팩토리 메서드란?

정적 팩토리 메서드의 특징

API 예외 처리

스프링 기본 오류 처리

HTML 페이지 vs API 오류

HandlerExceptionResolver

HandlerExceptionResolver

MVC 패턴 강의 정리