지식 줍줍 🐿️

JPA (Java Persistence API)

자바 진영에서 만든 ORM 기술 표준

사용하는 이유

소프트웨어 개발자가 SQL 에 의존하는 개발을 피할 수 있다.
개발자 입장에서 쿼리문을 다루지 않고 객체지향 중심으로 개발을 할 수 있도록 되어있기에, 생산성 및 유지보수에 효율적
객체와 관계형 DB의 차이를 중간에서 해결해주기 때문에 데이터베이스를 교체하더라도 유지보수 영향도가 크지 않음.
    → mysql,, oracle 바꿔 사용하더라도 쿼리 변경없이 사용 가능

JPA 가 제공하는 기능

‣ 엔티티 와 테이블을 매핑하는 설계 부분
‣ 매핑한 엔티티를 실제 사용하는 부분.

✢ 엔티티 ? 
정보를 표현하는 단위이기도하며
JPA 에서는 관계형 데이터베이스에 영속화 해야할 자바 객체 (데이터 베이스 테이블로 표현)를 나타냄.

영속성 관리

프로세스가 생성이 되었지만, 별개로 유지되는 상태의 특징중 하나.
이를 별도의 기억장치에 보존 및 관리하는것.

엔티티 매니저는 트랜잭션이 실행될때 커넥션을 얻음

엔티티 매니저 팩토리

EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");

‣ JPA 을 사용할 수 있게함.
‣ JPA 동작 위해 기반 객체를 만들고 커넥션풀을 생성함 → 비용이 크다.
‣ 어플리케이션에서 딱 한번 생성 후 공유해서 사용해야 함.

엔티티 매니저

EntityManager em = emf.createEntityManager();

‣ JPA 기능을 제공. 이를 이용하여 CRUD가 가능함.
‣ 엔티티를 영속성 컨텍스트에 저장해주는 역할을 함. (관리자)
‣ 트랜잭션을 커밋하기 직전까지 데이터베이스에 엔티티를 저장하지 않고 내부 쿼리 저장소(쓰기지연 SQL 저장소)에 쿼리를 모아두도록 함.
    → 트랜잭션 커밋시 모아둔 쿼리를 데이터베이스에 보냄=플러시 (쓰기지연)
    → 트랜잭션 커밋까지 되어야 데이터베이스 변경내용 반영이 됨
‣ 내부에 데이터 소스를 유지하면서 (커넥션 유지) 데이터베이스와 통신함.
‣ 개발자 입장에선 데이터베이스로 생각할 수 있음.
‣ 데이터베이스 커넥션과 밀접한 관계가 있으므로 스레드간에 공유하거나 재사용하면 안됨. (동시성 문제)
‣ 생성 비용이 크진 않음.
‣ 엔티티매니저를 사용할 때 마다 실제로 영속성 컨텍스트와 상호 작용을 함.

영속성 컨텍스트 (persistence context)

‣ 엔티티를 영구 저장하는 환경 
‣ 엔티티 매니저를 사용하여 엔티티를 영속성 컨텍스트에 저장
‣ 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리 (엔티티 매니저의 수명주기 관리)
‣ 1차캐시, 동일성보장(identity), 쓰기지연, 변경감지(Dirty Checking), 지연로딩(Lazy Loading) 됨

✢ 1차 캐시 ? 
영속성 컨텍스트 내 캐시를 가지고 있는 것. 
영속상태의 엔티티는 모두 이곳에 저장됨.
Map 형태이고 [key: @Id로 매핑한 식별자, value: 엔티티 인스턴스] 이다

엔티티 생명주기

‣ 비영속 (new/transient): 영속성 컨텍스트와 전혀 관계가 없는 상태
    → 엔티티를 영속성 컨텍스트에 저장하지 않은 상태.
    → 객체만 생성한 상태 
‣ 영속 (managed): 영속성 컨텍스트에 저장된 상태 (영속상태)
‣ 준영속 (detached): 영속성 컨텍스트에 저장 되었다가 분리된 상태 
   → 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
   → 1차 캐시에서 사라짐..
   → 지연로딩(LAZY LOADING) 할 수 없다.
   → 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
   → 식별자값을 가지고 있고 거의 비영속 상태임.
   → 다시 영속 상태로 만드려면 merge() 하면 됨. (준영속 상태의 엔티티를 받아 다시 영속 상태로 만듬)
‣ 삭제 (removed): 삭제 

엔티티 저장 (insert)

‣ 쓰기지연(transactional write-behind)
    → 트랜잭션 커밋 직전까지 데이터베이스에 엔티티를 저장하지 않고,
        내부 쿼리 저장소에 INSERT 쿼리를 모아두고 커밋시 데이터베이스에 보내는 상태 (보내는 작업=flush)

엔티티 조회 (read)

‣ 동일성이 보장된다!

변경 감지 (dirty checking) - 수정

‣ 엔티티의 변경사항을 데이터베이스에 자동으로 반영하는 기능
‣ 엔티티를 조회하여 변경부분 파악 후 업데이트
‣ 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용
☞ 변경 감지 관련 상황 (링크)

플러시 (flush)

‣ 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 작업. 
    → 직접 호출: em.flush() 직접 호출
    → 트랜잭션 커밋 시 플러시 자동 호출: 기본설정..
    → JPQL 쿼리 실행시 플러시 자동 호출

참고

- 책: http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788960777330 

- 링크: https://ko.wikipedia.org/wiki/%EC%A7%80%EC%86%8D%EC%84%B1

- 링크: https://www.baeldung.com/jpa-entities

- 링크: https://cupping.tistory.com/2

- 링크: https://openjpa.apache.org/builds/1.2.3/apache-openjpa/docs/jpa_overview_emfactory_perscontext.html

- 링크: https://www.baeldung.com/jpa-hibernate-persistence-context

- 강의: https://www.youtube.com/playlist?list=PL9mhQYIlKEhfpMVndI23RwWTL9-VL-B7U 

쿠버네티스
(k8s = kubernetes)

설명

• 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼
• 쉽게말해, 다수의 컨테이너를 관리하는데 사용
• 구글에서 만들었고 borg 기반
•컨테이너 오케스트레이션(container orchestration)의 표준 
  ↑↑↑ click-! ↑↑↑

※ 컨테이너
• 하나의 운영체제(OS) 커널 에서 다른 프로세스에 영향받지 않고 독립적으로 실행되는 프로세스 상태
• 운영체제 환경에 관계 없이 독립적인 환경에서 일관된 결과 보장
• 어플리케이션 간 운영체제(OS)을 공유
• 컨테이너 내에는 자체 파일시스템, CPU점유율, 메모리, 프로세스 공간 등이 존재.
• 클라우드 or OS 배포본에 모두 이식 가능.

쿠버네티스를 사용하는 이유?

• 분산시스템을 탄력적으로 실행하기 위해 사용. (배포 관리등을 시스템이 알아서 처리해줌으로써 안정성에 기여함)

Desired State (원하는 상태)

• 상태 체크(Observe) 중 현재상태(Current State)에서 차이점(Diff)이 발견시 조치(Act)를 취하여 원하는 상태로 만듬
• 비교하고 비교하고 비교하여 다르면 그에 맞게 상태를 변경함
• API 가 현재상태를 갖고 있으며, 이를 보존하기 위해 etcd가 필요 (한몸으로 움직임)

쿠버네티스 컴포넌트

• 쿠버네티스를 배포하였을때 생성

쿠버네티스 아키텍처

❁ 마스터노드와 워커노드로 구성 ❁ 
    ‣ 마스터 노드에는 kubectl, API 서버, etcd, 컨트롤러 매니저, 스케줄러 등이 존재. (선언적 시스템)
    ‣워커노드에는 kubelet, 컨테이너 런타임, Pod, 네트워크플러그인, CoreDNS 가 존재함. (워커노드는 워커플로 구조)

❖ Kubernetes cluster
    ‣ 컨테이너화된 어플리케이션을 실행하는 노드라고 하는 (컨테이너 실행위함) 의 워커 머신의 집합

❖ Control Plane
    ‣ 끊임없이 상태를 체크하고 원하는 상태를 유지함 (새로생긴 Pod을 계속 체크함)
    ‣ etcd, API 서버, Scheduler, 컨트롤러매니저, 클라우드 컨트롤러 매니저 등의 컴포넌트로 구성 → 이를 실행해주는 것이 Master
    ‣ 마스터노드

❖ Controller
    ‣ 끊임없이 상태를 체크하고 원하는 상태를 유지함 (새로생긴 Pod을 계속 체크함, API 서버를 통해 클러스터의 공유 상태 감시)
    ‣ 단일 프로세스로 실행 (복잡성 낮춤)
    ‣ 무한반복으로 돌면서 체크
    ‣논리적으로 다양한 컨테이너가 존재함 (복제컨트롤러,, 노드컨트롤러,, 엔드포인트 컨트롤러,, 10개..20개..)

❖ Scheduler
    ‣ Node 현재 상태를 체크함
    ‣ 새로 생성된 Pod을 감지하고 실행할 노드를 선택함. (할당요청 Pod을 확인함)
    ‣ 노드의 현재 상태와 Pod의 요구사항을 체크함

❖ API Server
    ‣etcd 와 유일하게 통신하는 모듈 **
    ‣ 상태를 바꾸거나 조회하는 기능 (조회 및 요청은 무조건 API Server을 통해서 함)
    ‣ REST API 형태로 제공
    ‣ 권한체크, 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신함
    ‣ 수평으로 확장되도록 디자인

❖ etcd
    ‣ 상태 및 데이터를 저장 (날라가지않게,, 보통 3대로 관리,, 백업 필수)
    ‣ 복구 가능하도록 함
    ‣ 고가용성, 일관성
    ‣ Key, Value 형태 및 TTL(time to live), watch 같은 부가 기능 제공

쿠버네티스 노드(Node) 컴포넌트

▪︎ 컨테이너화된 어플리케이션을 실행
▪︎ 클러스터에 따라 가상 or 물리적일 수 있다.
▪︎Control Plain 에 의해 관리되며, Pod을 실행하는 데 필요한 서비스를 포함함.
▪︎ 하나의 클러스터에는 여러개의 노드가 존재.

    ❖ kubelet
        ‣ Pod 을 실행/중지하고 상태를 체크함 (각 노드에서 실행, 미실행 Pod을 확인하여 Pod을 생성함)
        ‣ 다 실행되어 있어야 함.
        ‣ 컨테이너를 직접 쓰지 않고 Pod라는 걸로 감싸서 사용함.

    ❖ kube-proxy
        ‣ 네트워크 프록시와 부하 분산 역할, iptables or IPVS을 사용 (설정만 관리)
 
    ❖ 컨테이너 런타임
        ‣컨테이너 실행을 담당하는 소프트웨어  

Kubectl

▪︎ 명령형 커맨드.. 이를 이용하여 쿠버네티스 오브젝트를 관리함

쿠버네티스 오브젝트

❖ Pod
    ‣ 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위
    ‣ 전체 클러스터에서 고유한 IP을 할당 (Pod 별로 IP 할당)
    ‣ 하나의 Pod 안에 여러개의 컨테이너 속할 수 있다.

❖ ReplicaSet
    ‣ Pod을 단독으로 만든상황에서 pod가 사라지는경우(서버가죽음) 자동복구가 되지 않는데, 이러한 pod을 자동 복제 관리해주는것.
    ‣ 여러개의 Pod 을 관리 (몇개의 Pod을 관리할지 결정)
    ‣ 무중단배포 하고싶을때 사용
    ‣ 신규 Pod을 생성하거나 기존의 Pod을 제거하여 원하는 수 (Replicas)을 유지

❖ Deployment
    ‣ 배포버전 관리 (ReplicaSet을 이용하여 버전관리를 함)
    ‣ 내부적으로 ReplicaSet 을 이용함

❖ Workload
    ‣ 클러스터 내에서 Pod 실행중 집합 나타냄

❖ Service
    ‣ 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법.
    ‣ Pod 을 연결하고 외부에 노출

❖ Service > ClusterIP
    ‣ Pod을 로드밸런서 하는 서비스
    ‣ 클러스터 내부에서 사용하는 프록시 
    ‣ Pod는 동적이지만, Service는 고유 IP을 가짐
    ‣ 클러스터 내부에서 서비스 연결은 DNS 이용

❖ Service > NodePort
    ‣ 노드에 노출되어 외부에서 접근 가능한 서비스 (브라우저가 접근 가능 등)
    ‣ 모든 노드에 동일한 포트로 생성

❖ Service > LoadBalancer
    ‣ 하나의 IP주소를 외부에 노출

❖ Ingress
    ‣ URL, path 기반 라우팅 정의 
    ‣ SSL 보안 연결
    ‣ domain path에 따라 내부 ClusterIp에 접근 가능하도록 처리
    ‣ 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP을 관리함.

❖ Volume 
    ‣ 데이터를 포함하고 있는 디렉터리이며, Pod의 컨테이너에서 접근 가능.

❖ ConfigMap
    ‣ key-value 쌍인 데이터를 저장하는데 사용하는 API 오브젝트.
    ‣ 설정 값을 Pod 에 전달
    ‣ 컨테이너 설정 정보를 저장 해 놓는 일종의 저장소 (key / value 형식)
    ‣ 컨테이너에서 필요한 환경 설정 내용을 컨테이너와 분리해서 제공
    ‣ 설정 값이 변경되었을 때마다 컨테이너의 재배포 없이 적용 가능

※ 참고
- 인프런 강의: 초보를 위한 쿠버네티스 안내서

- 책: 컨테이너 인프라 환경 구축을 위한 쿠버네티스 / 도커 

- 링크: https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/

- 링크: https://subicura.com/2019/05/19/kubernetes-basic-1.html

컨테이너 오케스트레이션 (container orchestration)

설명

◦ 복잡한 컨테이너 환경을 효율적으로 관리 하기 위한 도구
◦ 서버 관리자가 해야하는 일을 대신 해주는 프로그램을 만드는것
◦ 복잡한 단계를 관리하고 요소들의 유기적인 관계를 미리 정의 해 손쉽게 사용할 수 있는 서비스
◦ 쿠버네티스가 이의 표준이라고 함.

※ 오케스트레이션
서버 구성 관리 자동화 = 컴퓨터 시스템과 소프트웨어의 자동화된 구성, 조율 관리
관련 도구로 Ansible, Puppet, Salt, 테라폼, AWS CloudeFormation..

..컨테이너 관리를 자동화 한다는 것?

특징

◦ 클러스터 단위 관리가 가능하다. (마스터 서버에서 각 노드별 관리..)
◦ 오토스케일링 가능
◦ 배포관리 알아서 함
◦ 서버 롤백등을 중앙에서 관리함
◦ 새로 등록되거나 변경되는 서버 IP를 자동으로 관리해줌 
◦ 볼륨 스토리지 마운트 설정 가능

※ 클러스터
여러대의 서버들을 하나의 시스템으로 동작하게 함으로써, 클라이언트들에게 고가용성(=오랜기간동안 정상운영 가능)을 제공

・ 쿠버네티스 클러스터 = 노드머신 (컨테이너 실행위함) 의 워커 머신의 집합
→ 쿠버네티스 실행중 ? 클러스터 실행중 !

※ 참고
- inflearn: 초보를 위한 쿠버네티스 안내서

- book: 컨테이너 인프라 환경 구축을 위한 쿠버네티스 / 도커 

- search: https://ko.wikipedia.org/wiki/%EC%98%A4%EC%BC%80%EC%8A%A4%ED%8A%B8%EB%A0%88%EC%9D%B4%EC%85%98_(%EC%BB%B4%ED%93%A8%ED%8C%85) 

https://wooody92.github.io/kubernetes/Kubernetes-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%EC%98%A4%EC%BC%80%EC%8A%A4%ED%8A%B8%EB%A0%88%EC%9D%B4%EC%85%98/

https://www.redhat.com/ko/topics/containers/what-is-a-kubernetes-cluster

https://ko.wikipedia.org/wiki/%EC%BB%B4%ED%93%A8%ED%84%B0_%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0

상황

vagrant up 명령어를 실행하여 master node, worker node 등을 실행하려고 하였는데 에러가 발생함.
(이책으로 학습중 이였고.., 나는 mac 유저였뜸..)

구글링을 해보니 VirtualBox 버전을 다운그레이드를 해야한다는 내용등등 발견하긴하였뜸.. 

해결

private_network 정보를 192.168.1.10 에서 192.168.56.10 으로 변경하여 적용하여 다시 실행하였더니 에러 발생 하지 않게됨.

그렇게 한 이유는 virtualbox 사이트 관련 문서 내용중이 이러한 내용을 발견했기 때문..,
>> Linux, Mac OS X 및 Solaris Oracle VM VirtualBox는 192.168.56.0/21 범위의 IP 주소만 호스트 전용 어댑터에 할당하도록 허용한다는 내용..

json web token

설명

JSON 객체를 사용하여 토큰 자체에 정보들을 저장하고 있는 웹토큰.
claims을 안전하게 전달하는 표준.
HMAC 알고리즘 사용 하거나, RSA or ECDSA를 사용하는 공개 / 개인키 쌍을 사용하여 서명이 가능함.
권한 부여 및 정보교환시점에서 사용.

✳︎ claims ?
JWT 의 PAYLOAD 부분을 구성하고 교환되는 정보 집합.

토큰생김새

위와 같은 형태로 생겼으며, https://jwt.io/ 사이트에서 토큰 정보를 확인할 수 있다.

구성방식

HEADER, PAYLOAD, SIGNITURE 으로 구성된다. 
이 세부분은 Base64url 인코딩을 사용하여 별도로 인코딩되며 JWT 생성을 위하 점(.)을 사용하여 연결된다. 

각 구성 설명은 아래와 같다.

동작방식

jwt 토큰 인증 방식 기준으로 그려본것이다. (oauth2의 허가는 생략)

장점과 단점

• 장점
  중앙의 인증서버, 데이터 스토어에 대한 의존성이 없고, 시스템 수평확장에 유리하다.
  
  
• 단점
  PAYLOAD 정보가 많아지면 네트워크 사용량이 증가함.
  토큰이 클라이언트에 저장되기에 서버에서 클라이언트의 토큰을 조작할 수 있다.

참조

https://jwt.io/introduction

https://ko.wikipedia.org/wiki/JSON_%EC%9B%B9_%ED%86%A0%ED%81%B0

https://velog.io/@kshired/Express%EC%97%90%EC%84%9C-JWT%EB%A1%9C-%EC%9D%B8%EC%A6%9D%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0-Access-Token%EA%B3%BC-Refresh-Token

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-jwt/dashboard

https://techdocs.akamai.com/api-gateway/docs/json-web-token-jwt-val#jwt-claims

트랜잭션

설명

두개 이상의 쿼리를 한 작업으로 실행해야 할 때 사용하는것 
트랜잭션으로 묶인 쿼리 중 하나라도 실패하면 전체 실패로 간주 -> 기존상태로 되돌림 (rollback)
트랜잭션으로 묶인 쿼리가 모두 성공할 경우 -> 실제반영 (commit)

@Transactional

설명

스프링에서 트랜잭션 범위를 설정할 수 있도록 하는 어노테이션 
트랜잭션 범위를 설정하고 싶을때 사용함.
제대로된 동작을 하기 위해서는 PlatformTransactionManager 빈 설정 & @Transactional 어노테이션 활성화 설정 이 필요

PlatformTransactionManager
- 트랜잭션 처리에 필요한 API 제공
- 개발자가 API를 호출하는 것으로 트랜잭션 조작을 수행할 수 있다.
- 대표적인 구현 클래스: DataSourceTransactionManager, HibernateTransactionManager, JpaTransactionManager, JtaTransactionManager, WebLogicJtaTransactionManager, WebSphereUowTransactionManager

@Transactional 어노테이션 활성화 설정
 - @EnableTransactionManagement 어노테이션을 이용하여 @Transactional 어노테이션이 붙은 메서드를 트랜잭션 범위에서 실행하는 기능을 활성화
- 등록된 PlatformTransactionManager 빈을 사용해서 트랜잭션을 적용한다.

@Transactional과 프록시

스프링은 트랜잭션을 사용하기 위해 내부적으로 AOP을 이용함!

..

트랜잭션 관리자 정의

로컬트랜잭션을 사용하는 경우 JDBC API 호출, 트랜잭션 제어를 수행하는 DataSourceTransactionManager을 사용한다.
단일 데이터 저장소에 대한 여러 조작을 하나의 논리적 단위로 처리하고 싶을때 사용

글로벌트랜잭션을 사용하는 경우(여러 데이터 저장소에 걸쳐서 적용되는 경우: DB가 여러개이고, 각각 조작 수행 단위를 하나의 트래잭션으로 묶는 경우) JtaTransactionManager 을 사용

선언적 트랜잭션 

설명

commit, rollback 등의 처리를 비지니스 로직에 서술하지 않고 사용하는 방법 (@Transactional)

필요정보

value
transactionManager
propagation
isolation
timeout
readOnly
rollbackFor
rollbackForClassName
noRollbackFor
noRollbackForClassName

.....

명시적 트랜잭션

설명

커밋이나 롤백과 같은 트랜잭션 처리를 소스코드에 직접 명시하는 방법.
메서드 단위보다 더 작은 단위로 트랜잭션을 제어하고 싶을때 사용.
PlatformTransactionManager, TransactionTemplate을 사용하는 두가지 방법 제공

....

트랜잭션 격리수준

설명

동시에 DB에 접근할 때 그 접근을 어떻게 제어할지에 대한 설정을 다룸.
DEFAULT, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE
....

참고

(책) 초보 웹 개발자를 위한 스프링5 프로그래밍 입문
(책) 스프링 철저 입문 

자바는 call by value (값에 의한 호출) 방식이다.

public class CallTest {

    public static void main(String[] args) {
        String test1 = "test1";
        String test2 = "test2";
        CallTest.callByValue(test1, test2); // 값에 의한 참조
        
        // CallTest.callByValue 에서 매개변수 전달 후 바꿧다 하여, test1, test2에 영향 안미침.
        System.out.println("test1:" + test1+", test2:"+test2); 
    }

    public static void callByValue(String test1, String test2) {
        String temp = test1;
        test1 = test2;
        test2  = temp;
        System.out.println("test1:" + test1+", test2:"+test2);
    }
}

/*
// result)
test1:test2, test2:test1
test1:test1, test2:test2
**/

함수 호출 시 매개변수의 값을 그대로 전달!
전달한 값 그대로 사용!
매개변수의 값들은 각각의 다른 메모리 위치에 저장됨. 
함수 내부에서 변경한 사항은 호출자의 실제 매개변수에 반영되지는 않음.

call by reference (주소에 의한 호출)

매개변수는 동일한 위치를 참조하므로 함수 내부에서 변경한 사항은 실제 호출자의 매개변수에 반영됨.
함수 호출 시 매개변수에 주소를 전달하여 사용!
참조에 의한 호출 (C++ 포인터)

/** 
C++ 언어에서 변수 주소를 매개변수로 전달 하였을 때
result) 
test1:test2, test2:test1
test1:test2, test2:test1 // 주소 참조에 의해 값이 변경 됨.
*/

참고

https://www.geeksforgeeks.org/difference-between-call-by-value-and-call-by-reference/

filter

설명

dispatcherServlet 호출 전, 요청에 대해서 전처리 작업(원하는 형태로 변형)이 필요한 경우 사용하는것. (웹 어플리케이션에서 등록)
filter chain 을 통해 연쇄적으로 동작할 수 있게 가능.
인증, 권한, CORS, 인코딩, XSS 작업시 이용

dispatcherServlet

설명

프런트 컨트롤러와 연동되는 진입점 역할을 하며, 기본적인 처리 흐름을 제어하는 사령탑 역할을 한다. 

✿ 프론트 컨트롤러?
클라이언트 요청을 프런트 컨트롤러라는 컴포넌트가 받아 요청 내용에 따라 수행하는 핸들러(Handler)를 선택하는 아키텍처

dispatcherServlet과 연동되는 인터페이스

Handler

설명

프레임워크 관점에서 불리는 Handler는 개발자가 작성하는 클래스의 관점에서 Controller 이다.

HandlerMapping

설명

요청에 대응할 핸들러를 선택하는 역할을 수행한다. (컨트롤러내의 메소드가 핸들러로 인식!)
클라이언트(브라우저)에서 요청이 올 경우 RequestMappingHandlerMapping 클래스는
요청 내용(요청 경로 혹은 HTTP 메서드)과 요청 매핑 정보를 매칭해서 실행할 핸들러르 선택한다!

@Controller
class TestController {
    @RequestMapping("/hello")
    public String hello() {
        return "/hi";
    }
    // hello 메소드가 핸들러!
}

HandlerAdapter

설명

핸들러 메서드를 호출하는 역할을 한다. (RequestMappingHandlerAdapter)
RequestMappingHandlerAdapter 클래스 에서는 핸들러 메서드에 매개변수를 전달하고 메서드의 처리 결과를 반환값으로 되돌려 보냄
빈 객체 검사 등등을 함.

ViewResolver

설명

핸들러에서 반환한 뷰 이름을 보고, 이후에 사용할 View 인터페이스의 구현 클래스를 선택하는 역할을 한다.

참고

(책) 스프링 철저 입문
(책) 스프링 부트로 배우는 자바 웹 개발
https://exhibitlove.tistory.com/7

https://stargatex.wordpress.com/2015/12/08/spring-mvc-request-lifecycle/

REST (Representational State Transfer)

설명

자원을 표현(Representational)으로 구분하여 해당 자원의 상태(State)를 주고 받는(Transfer)다.
HTTP URI(Uniform Resource Identifier)을 통해 자원(Resource)을 명시하고, Http Method(GET, POST, PUT, DELETE)을 통해 자원에 대한 CRUD Operation을 적용

✱ URI (Uniform Resource Identifier)
인터넷 자원을 나타내는 유일한 주소
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
 - URN: 자원의 이름 (식별자)
 - URL: 자원의 위치 

구성요소

1. 자원 (Resource)
‣ Http URI (ex. /users/:userId)

2. 행위 (Method)
‣ GET, POST, PUT, DELETE,
‣ HEAD (요청 header 정보만 응답),
‣ PATCH (PUT과 다르고, 자원의 일부만 수정하고자 할때 사용),
‣ OPTION (현재 End-point가 제공 가능한 API method를 응답)

3. 표현 (Representation of Resource)
  Client(브라우저)가 자원의 상태에 대한 조작을 요청(Request)하면 서버는 이에 적절한 응답(Response)을 보낸다.
  JSON, XML, TEXT, RSS 등 여러 형태로 표현

REST API 특징

1. 클라이언트/서버
‣ 아키텍처를 단순화 시키고 작은단위로 분리함으로써
클라이언트 - 서버 각 파트가 독립적으로 개선될 수 있도록 한다. 

2. 상태없음
‣ 클라이언트의 상태가 서버에 저장되어서는 안된다.

3. 레이어드 아키텍처 (Layered Architecture)
‣ 클라이언트 - 서버 연결 사이의 중간 서버가 존재하는 경우 (클라이언트 - 중간서버 - 서버),
중간서버(게이트웨이, 방화벽, 프록시 etc)는 로드밸런싱 혹은 공유 캐시 기능을 제공함으로써
시스템 규모 확장성을 향상시키는데 유용

4. 캐시 (Cache)
‣ 클라이언트 응답을 캐싱할 수 있어야 함. 캐싱함으로서 서버에 부하 최소화

5. 코드 온 디맨드(Code on demand)
‣ 요청이 오면 코드를 준다는 의미로 특정 시점에 서버가 특정 기능을 수행하는 스크립트 또는
플러그인을 클라이언트에 전달해서 해당 기능을 동작하도록 하는것. (자바스크립트, 플래시 etc)

6. 통합 인터페이스
‣ 일관적인 인터페이스로 분리 되어야 함.

REST 인터페이스 규칙

1. 리소스 식별
‣ 요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. (URI)

2. 표현을 통한 리소스 처리
‣ 다양한 콘텐츠 유형으로 표현 가능 (JSON, XML, HTML ..)

3. 자기 묘사 메세지
‣ Http header 에 메타 데이터 정보를 추가해서 실제 데이터와는 관련 없지만
데이터에 대한 설명을 나타내는 정보를 담을 수 있음.

4. 어플리케이션의 상태에 대한 하이퍼미디어(HATEOAS, Hypermedia As The Engine Of Application State)
‣ REST API 개발할 때에 단순 데이터만 전달하지 않고, 링크 정보까지 포함하여 전달 (하이퍼 텍스트 링크)
‣ 리소스 상태가 전이되는 경우에 변경되는 정보를 제공하고자 함.
(등록 요청 후, 변경 된 정보를 좀 더 자세히 알고자 할때 하이퍼 링크도 같이 제공)
    

REST API 

설명

REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스

RESTful의 목적

API 이용자가 해당 API 으로 데이터를 얻고, 특정 기능을 파악할 수 있도록 하는 것

리소스 원형

도큐먼트 (document)
‣ 객체 인스턴스나 데이터베이스 레코드와 유사한 개념

컬렉션 (collection)
‣ 서버에서 관리하는 디렉터리 리소스 

스토어 (store)
‣ 클라이언트에서 관리하는 리소스 저장소
‣ API 클라이언트가 리소스를 등록/수정/삭제에 관여

컨트롤러 (controller)
‣ 절차적인 개념을 모델화 한 것

✰ REST API 디자인을 위한 규칙

추상적인 것 보단, 구체적인 것이 좋다.
ex) /animals -> /pigs

동사를 사용하지 않는다. (명사를 사용)
method 를 동사 대용으로 사용.

단수보단, 복수를 사용하는 것을 권장한다.
ex) /thing  ->  /things or /things/{id}

슬래시(/) 을 사용하여 계층관계를 표시해야 한다.
리소스간 연관관계는 /리소스명/리소스ID/관계가 있는 다른 리소스명 으로 표현한다.
ex) GET /users/{userid}/devices (소유자가 가지고있는 디바이스 목록?)

URL 마지막에 슬래시(/) 을 포함하지 않는다.
슬래시를 포함한다면, 슬래시 다음에 식별자가 와야하는데 오지 않음으로 혼동을 줄 여지가 있음.

URI의 가독성을 높히려면 하이픈(-)을 사용해야 한다.

URI에 밑줄(_)을 사용해선 안된다.
보기가 어려움. 가독성

URI 경로에는 소문자를 사용해야 한다.

파일 확장자는 사용하지 않는다.

참고

https://www.redhat.com/ko/topics/api/what-is-a-rest-api

(책) 스프링 부트로 배우는 자바 웹 개발

https://nsinc.tistory.com/192

https://spoqa.github.io/2013/06/11/more-restful-interface.html

https://dzone.com/articles/7-rules-for-rest-api-uri-design-1

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://www.slideshare.net/nexusz99/rest-api-48600643

https://zsgg.tistory.com/entry/REST-API-%EB%94%94%EC%9E%90%EC%9D%B8-%EA%B7%9C%EC%B9%99

https://sanghaklee.tistory.com/57

https://meetup.toast.com/posts/92

DI

설명

의존성 주입이라고도 하며, IoC (Inversion of Control) 라고 하는 소프트웨어 디자인 패턴 중 하나.
어떤 클래스가 필요로 하는 컴포넌트를 외부에서 생성한 후, 내부에서 사용 가능하게 만들어 주는 과정
DI 컨테이너를 통해 각 컴포넌트의 인스턴스를 생성하고 통합 관리하면서 컴포넌트간 의존성 문제를 해결할 수 있다.

✳︎ 빈 (@bean)
spring DI container에 의해 관리되는 객체 
ApplicationContext.getBean(XXX.class) 으로 얻어지는 객체를 의미


✳︎ 컴포넌트 (@Component)
사용자가 만든 bean 을 자동으로 감지할 수 있도록 한 것


✳︎ IoC 컨테이너 (Inversion of Control)
의존성 주입을 자동으로 처리하는 기반이고 인스턴스 구성 및 빈 조립을 담당한다.
빈 팩토리(Bean Factory)라고도 함.
Bean Factory에 여러가지 컨테이너 기능을 추가하여 ApplicationContext라고 부름. (Bean Factory의 확장)


✳︎ Bean Factory
Bean 을 등록/생성/조화/반환 관리함.


✳︎ ApplicationContext
spring bean을 보유하고있는곳
Bean Factory 와 기능 같고, Spring의 부가 서비스를 추가로 제공

어떤 컴포넌트는 싱글턴(singleton) 객체로 만들어야 하며, 어떤 컴포넌트는 프로토타입(prototype) 객체로 만들어야 한다. 이러한 인스턴스 스코프(scope) 관리를 DI 컨테이너가 대신 해준다.

DI 방법 3가지

1. 설정자 기반 (setter-based)
  setter method 에 @Autowired 을 적용

@RestController
public class AController {
    private A a;

    @Autowired
    public void setA(A a) {
	    this.a = a;
    }
}

2. 생성자 기반 (contructor-based)
  생성자 인수를 사용해 의존성을 주입하는 방식

@RestController
public class AController {
    private final A a;
    
    public AController(A a){
        this.a = a;
    }
}

3. 필드기반 (field-based)
  사용하고 싶은 필드에 @Autowired 을 적용 

@RestController
public class AController {
    
    @Autowired
    private A a;
}

✳︎ @Autowired
빈을 자동으로 주입하는 방식

필드 기반 방식은 추천하지 않는다. (생성자 방식으로 사용하는것을 권장)
추천하지 않는 이유는 순환참조 때문! 

✳︎ 순환참조
서로 다른 클래스가 서로를 참조하고 있는 상태, 따라서 스프링 컨테이너가 어떤 빈을 먼저 생성해야할지 판단을 하지 못해서 발생하는 문제!

생성자 방식을 추천하는 이유는 테스트 코드 작성에 용의하며, 실행 중 객체가 변경되는 것을 방지할 수 있다.
  

DI 컨테이너 사용의 장점

장점

  인스턴스 스코프 제어
  인스턴스 생명주기 제어
  AOP 방식으로 공통기능 적용 가능
  의존하는 컴포넌트 간의 결합도를 낮춰 단위테스트 쉽게 가능

빈 설정 방법

설정 방법 3가지

1. 자바 기반 설정 방식 (Java-based configuration)
  - 자바 클래스에 @Configuration, 메소드에 @Bean 을 사용해 빈을 정의하는 방법

2. XML 기반 설정 반식 (XML-based configuration)
  - XML 파일을 사용하는 방법 (<bean>, <constructor-arg>, <property>)

3. 애너테이션 기반 설정 방식 (Annotation-based configuration)
  - @Component 같은 마커 어노테이션이 부여된 클래스를 탐색해서(Component Scan) IoC컨테이너에 빈을 자동으로 등록하는 방법.

컴포넌트 스캔 (Component Scan)

설명

클래스 로더(Class Loader)를 스캔하면서 특정 클래스를 찾은 다음, DI 컨테이너에 등록하는 방법

종류

@Component, @Controller, @Service, @Repository, @Configuration, @RestController, @ControllerAdvice, @ManagedBean, @Named ..

참고

(책) 스프링 철저 입문
http://blog.naver.com/PostView.nhn?blogId=gngh0101&logNo=221179100057&parentCategoryNo=&categoryNo=32&viewDate=&isShowPopularPosts=false&from=postView
https://dog-developers.tistory.com/12
https://ict-nroo.tistory.com/120
https://www.baeldung.com/spring-component-annotation
https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-basics