[스프링 부트 핵심 가이드] 02. 개발에 앞서 알면 좋은 기초 지식

목차

02. 개발에 앞서 알면 좋은 기초 지식

ㄴ2.1 서버 간 통신

ㄴ2.2 스프링 부트의 동작 방식

ㄴ2.3 레이어드 아키텍처

ㄴ2.4 디자인 패턴

    ㄴ2.4.1 디자인 패턴의 종류

    ㄴ2.4.2 생성 패턴

    ㄴ2.4.3 구조 패턴

    ㄴ2.4.4 행위 패턴

 

ㄴ2.5 REST API

    ㄴ2.5.1 REST란?

    ㄴ2.5.2 REST API란?

    ㄴ2.5.3 REST의 특징

    ㄴ2.5.4 REST의 URI 설계 규칙

 

2.1 서버 간 통신

서버간 통신이 나오게 된 이유 : 마이크로서비스 아키텍처의 출현

 

단일 서비스 아키텍쳐 : 여러 기능들을 구분 없이 하나의 애플리케이션에 통합

단일 서비스 아키텍쳐의 장점 > 내부 메서드 호출 등을 통해 원하는 자원을 자유롭게 가져와 사용할 수 있음

단일 서비스 아키텍쳐의 단점 > 서버를 업데이트 할때마다 모든 기능을 사용할 수 없고, 서비스 자체에 규모도 커져서 서비스 구동시간이 길어짐.

 

마이크로서비스 아키텍처 : 서비스를 기능별로 작게 나누어 구성한 아키텍쳐. ex> 블로그 서비스, 로그인 서비스, 이메일 서비스 등

마이크로서비스 아키텍처의 장점 > 분산형 개발이 가능해 동일한 애플리케이션 개발에 더 많은 개발자들이 동시 참여할 수 있으므로 개발에 소요되는 시간을 단축할 수 있음. 그 외에도 여러 장점 존재

마이크로서비스 아키텍처의 단점 > 각 서비스 간에 통신을 해야하는 경우 서버간 통신이 필요.

 

** 쓰여있는 장, 단점은 필자가 서버 간 통신을 이해하기 위함으로 분류해놓은 것이지 실제 장,단점이 아닙니다.

 

이때 서버간 통신은 프로토콜로 사용 가능한데 이때 HTTP/HTTPS 프로토콜을 사용(웹통신)함을 의미하며,

HTTP프로토콜은 서버 <-> 클라이언트 구조로 이루어져 클라이언트 쪽에서 서버로 데이터를 요구하며 서버가 해당 데이터를 제공하는 통신 프로토콜 입니다.

2.2 스프링 부트의 동작 방식

스프링 부트에서 spring-boot-starter-web 모듈을 사용하면 기본적으로 톰캣을 사용하는 스프링 MVC 구조를 기반으로 동작함.

 

 

서블릿(Servlet) : 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술. 스프링에서는 DispatcherServlet이 서블릿의 역할을 수행함.

서블릿 컨테이너(Servlet Container) : Servlet을 관리하는 곳. 서블릿 인스턴스(Servlet Instance)를 생성하고 관리하는 역할을 수행하는 주체. 대표적으로 톰캣이 있으며, 톰캣은 WAS의 역할과 서블릿 컨테이너 역할을 수행하는 대표적인 컨테이너이다.

 

-> 스프링은 톰캣을 임베드(embed)해 사용하기 때문에 서블릿 컨테이너와 DispatcherServlet은 자동 설정된 web.xml의 설정값을 공유함

 

 

서블릿 컨테이너의 특징

• 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리
• 서블릿 객체는 싱글톤  패턴으로 관리됨
• 멀티 스레딩을 지원

DispatcherServlet의 동작 

(1) DispatcherServlet으로 요청(HttpServletRequest)이 들어오면 DispatcherServlet은 핸들러 매핑(Handler Mapping)을 통해 URI에 매핑된 핸들러(=Controller)를 탐색함.

(2) 핸들러 어댑터(Handler Adapter)로 컨트롤러를 호출함.

(3) 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공해 반환함.

(4) 뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 뷰 리졸버(View Resolver)를 통해 뷰(View)를 받아 리턴함.

 

여기서 알아둬야할 점은 (4)에서 뷰 형식으로 리턴하는 컨트롤러와 뷰 형식이 없는 REST 형식을 리턴할 컨트롤러가 있다는 것이다.

 

뷰 형식으로 리턴하는 컨트롤러를 사용하는 DispatcherServlet 동작방식

 

뷰 형식이 없는 REST 형식의 @ResponseBody를 사용하는 DispatcherServlet 동작방식

보통 우리가 프로젝트를 만드는 스프링 부트는 @RestController를 사용하는 동작 방식을 따르게 된다.

MessageConverter를 거쳐 JSON 형식으로 변환해서 HTTP에 요청에 응하는 응답을 주는 구조이다.

 

스프링 부트의 자동 설정 내역에서 HttpMessageConverter 인터페이스 사용하고 있는 걸 확인할 수 있다.

 

 

2.3 레이어드 아키텍처

레이어드 아키텍처(Layered Achitecture) : 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조

 

레이어드 아키텍쳐 기반 설계의 특징

• 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받음
• 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역할을 침범하지 않음
  • 각 컴포넌트의 역할이 명확해지고 코드의 가독성과 기능 구현에 유리함
  • 코드의 확장성도 좋아짐
• 각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이함

 

레이어드 아키텍쳐는 어떻게 설계하느냐에 따라 용어와 계층 수가 달라진다.

일반적인 레이어드 아키텍쳐는 3계층 or 4계층 구성을 의미한다.

 

이를 스프링 부트(스프링 MVC 구조)와 결합해서 레이어드 아키텍쳐를 생각하면 다음과 같다.

프레젠테이션 계층

• 상황에 따라 유저 인터페이스(UI) 계층이라고도 함.
• 클라이언트와의 접점
• 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할

비지니스 계층

• 상황에 따라 서비스(Service)계층이라고도 함.
• 핵심 비지니스 로직 구현하는 영역
• 트래잭션 처리나 유효성 검사 등의 작업도 수행함.

데이터접근 계층

• 상황에 따라 영속(Persistence) 계층이라고도 함.
• 데이터베이스에 접근해야 하는 작업을 수행함.
• 그림 2.6에서는 DAO라는 컴포넌트를 표현했지만 Spring Data JPA에서는 DAO 역할을 리포지터리가 수행하기 때문에 Repository로 대체 가능.

스프링에서  외부에서는 컨트롤러로 접속하고, 컨트롤러는 서비스, 서비스는 레파지토리로 순차적인 접근 가능한 구조임을 상기하면 위의 레이어드 아키텍처가 조금은 이해 가능하다.

 

2.4 디자인 패턴

디자인 패턴이란? 소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위한 고안된 해결책

 

디자인 패턴의 종류 : 생성(Creational)패턴, 구조(Structural) 패턴, 행위(Behavioral) 패턴

디자인 패턴을 구체화해서 정리한 대표적인 분류 방식인 'GoF(Gang of Four) 디자인 패턴 분류'를 따름.

Gang of Four은 디자인 패턴을 구체화하고 체계화 해서 분류한 4명의 인물을 의미함.

 

생성 패턴 : 객체 생성에 사용되는 패턴, 객체를 수정해도 호출부가 영향을 받지 않음

Abstraact Factory(추상 팩토리) : 구체적인 클래스를 지정하지 않고 상황에 맞는 객체를 생성하기 위한 인터페이스 제공
Builder(빌더) : 객체의 생성과 표현을 분리해 객체를 생성하는 패턴
Factory Method(팩토리 메서드) : 객체 생성을 서브 클래스로 분리해서 위임하는 패턴
Prototype(프로토타입) : 원본 객체를 복사해 객체를 생성하는 패턴
Singleton(싱글톤) : 한 크래스마다 인스턴스를 하나만 생성해서 인스턴스가 하나임을 보장하고 어느 곳에서도 접근할 수 있게 제공하는 패턴

 

구조 패턴 : 객체를 조합해서 더 큰 구조를 만드는 패턴

Adapter(어댑터) : 클래스의 인터페이스를 의도하는 인터페이스로 변환하는 패턴
Bridge(브릿지) : 추상화와 구현을 분리해서 각각 독립적으로 변형케 하는 패턴
Composite(컴포지트) : 여러 객체로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루는 패턴
Decorator(데코레이터) : 객체의 결합을 통해 기능을 동적으로 확장할수 있게 하는 패턴
Facade(퍼사드) : 서브시스템의 인터페이스 집합들에 하나의 통합된 인터페이스를 제공하는 패턴
Flyweight(플라이웨이트) : 특정 클래스의 인스턴스 한 개를 가지고 여러 개의 가상 인스턴스를 제공할 때 사용하는 패턴
Proxy(프락시) : 특정 객체를 직접 참조하지 않고 해당 객체를 대행(프락시)하는 객체를 통해 접근하는 패턴

 

행위 패턴 : 객체 간의 알고리즘이나 책임 분배에 관한 패턴, 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배하고, 결합도 최소화를 고려할 필요 존재

Chain of Responsibility(책임 연쇄) : 요청 처리 객체를 집합으로 만들어 결합을 느슨하게 만드는 패턴
Command(커맨드) : 실행될 기능을 캡슐화해서 주어진 여러 기능을 실행하도록 클래스를 설계하는 패턴
Interpreter(인터프리터) : 주어진 언어의 문법을 위한 표현 수단을 정의하고 해당 언어로 구성된 문장을 해석하는 패턴입니다.
Iterator(이터레이터) : 내부 구조를 노출하지 않으면서 해당 객체의 집합 원소에 순차적으로 접근하는 방법을 제공하는 패턴
Mediator(미디에이터) : 한 집합에 속한 객체들의 상호작용을 캡슐화하는 객체를 정의하는 패턴
Memento(메멘토) : 객체의 상태 정보를 저장하고 필요에 따라 상태를 복원하는 패턴
Observer(옵저버) : 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버 목록을 객체에 등록해 상태가 변할 때마다 메서드 등을 통해 객체가 직접 옵저버에게 통지하는 패턴
State(스테이트) : 상태에 따라 객체가 행동을 변경하게 하는 패턴
Strategy(스트레티지) : 행동을 클래스로 캡슐화해서 동적으로 행동을 바꿀 수 있게 하는 패턴
Template Method(템플릿 메서드) : 일정 작업을 처리하는 부분을 서브 클래스로 캡슐화해서 전체 수행 구조는 바꾸지 않으면서 특정 단계만 변경해서 수행하는 패턴
Vistor(비지터) : 실제 로직을 가지고 있는 객체(visitor)가 로직을 적용할 객체(element)를 방문하며 실행하는 패턴

 

2.5 REST API

REST API는 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스 입니다.

이 인터페이스로 클라이언트는 서버에 접근하고 자원을 조작할 수 있음.

 

REST : Respresentational State Transfer의 약자로, 주고 받는 자원(Resource)에 이름을 규정하고 URI에 명시해 HTTP aptjem(GET, POST, PUT, DELETE)를 통해 해당 자원의 상태를 주고 받는 것을 의미. 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템 아키텍처의 한 형식임. 

 

API : Application Programming Interface의 약자로, 애플리케이션에서 제공하는 인터페이스를 의미. API를 통해 서버 또는 프로그램 사이를 연결할 수 있음.

 

-> REST API = REST 아키텍쳐를 따르는 시스템/애플리케이션 인터페이스

 

RESTful하다 = REST 아키텍쳐를 구현하는 웹서비스를 의미

REST의 특징

• 유니폼 인터페이스(일관된 인터페이스)
  • REST 서버는 HTTP 표준 전송 규약을 따르기 때문에 프로그래밍 언어/ 플랫폼/ 기술에 종속되지 않고 타 언어, 플랫폼, 기술 등 호완 가능함
• 무상태성(Stateless)
  • HTTP의 특성과 마찬가지로 서버에 상태 정보를 따로 보관하거나 관리하지 않는 특성
  • 서버가 불필요한 정보를 관리하지 않아도 되므로 비지니스 로직의 자유도가 높고 설계가 단순함
• 캐시 가능성
  • 무상태성과 마찬가지로 HTTP 특성 중 캐싱 기능 적용 가능
  • 응답과 요청이 모두 캐싱 가능한지 명시가 필요함
  • 캐싱이 가능한 경우 클라이언트에서 캐시를 저장해두고(쿠키) 같은 요청에 대해서는 해당 데이터를 가져다 사용함
  • 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선됨
• 레이어 시스템
  • REST 서버는 네트워크 상의 여러 계층으로 구성될수 있음(Layerd System).
  • 서버의 복잡도와 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 됨.
• 클라이언트-서버 아키텍처
  • 앞선 무상태성, 캐시 가능성과 마찬가지로 HTTP 프로토콜을 이용하기 때문에 클라이언트-서버 아키텍처를 가짐
  • 서로(클라이언트, 서버)에 대한 의존성을 낮춤

REST의 URI 설계 규칙

• URI의 마지막에는 '/'를 포함하지 않음.
• 언더바(_)는 사용하지 않습니다. 대신 하이픈(-)을 이용
• URL에는 행위(동사)가 아닌 결과(명사)를 명시함
  • 행위는 HTTP 메서드로 표현함.
  • ex> http://localhost.com/delete-product가 아닌 http://localhost.com/product 으로 두되 HTTP method는 DELETE 로 표현
• URI는 소문자로 작성
  • 일부 웹 서버의 운영체제는 리소스 경로 부분의 대소문자를 다른 문자로 인식하기 때문
  • RFC 3986은 URI 문법 형식을 정의하고 있는데, 호스트의 구성요소를 제외하고 URI의 대소문자를 구분해서 정의하고 있음.
• 파일의 확장자는 URI에 포함하지 않음.
  • HTTP에서 제공하는 Accept 헤더를 사용하는 것이 좋음.

예시

http://localhost.com/product  

http://localhost.com/product/123

http://localhost.com/product-company-name