스프링 부트소개

스프링 프레임 워크의 등장

JavaBean

현실 세계에 있는 개념적, 물리적 객체를 표현할 때 정의하는 클래스로 메인 메서드가 없어 실행이 안되고 객체의 속성, 행위만 적어놓은 데이터를 표현하는 것에 목적을 둔 재사용 가능한 자바 클래스이다.

예를 들어 회원 관리 어플리케이션이라면 회원을 추상화하여 정의할 수 있는 정보를 선언해 놓은 클래스이다.

자바 빈은 규약에 맞춰 작성되어야 한다.

 

Java Bean의 규약

• 반드시 클래스는 패키지화 되어야 함
• 필드는 property(프로퍼티)라고 함
• 필드는 private로 지정하고, 외부접근을 위한 get, set 메소드를 정의해야 함
• get, set 메소드는 public으로 지정

 

EJB(Enterprise Java Bean)

EJB는 자바를 만든 썬마이크로시스템즈가 기업 환경 개발을 단순화 하기 위해 제창한 규약으로 위 스펙에 따라 비즈니스 로직을 처리하는 서버 애플리케이션 이다.

 

IT 시스템 규모가 커지고 복잡해짐에 따라 다양한 기술( 트랜잭션, 멀티 쓰레딩, 리소스 풀링, 보안 등)의 요구에 구조가 복잡한 대규모 시스템의 분산 객체 환경을 쉽게 구현하기 위해 등장했다.

개발하다보면 많은 객체들을 만드는데 이러한 비지니스 객체들을 관리하는 컨테이너를 만들어서 필요할 때마다 컨테이너로부터 객체를 받아 관리하면 효율적일 것이라는 생각에 탄생되었다.

 

Database 처리, Transaction 처리 등의 시스템 서비스를 이용한 로직을 감추고 있는 부품을 "컨테이너"라고 불린다.

효율적으로 사용하려고 만들어 졌으나 서비스가 구현해야하는 실제 비지니스 로직보다 EJB 컨테이너를 사용하기 위한 상투적인 코드 (상속과 구현해야하는 클래스들)들이 많다는 불편함이 있었다.

또한 작성된 코드는 EJB컨테이너가 없으면 사용할 수 없었기 때문에 개발자들은 반복되는 수정-빌드-배포-테스트 과정으로 많은 시간을 낭비해야 했다.

 

심각한 것은 벤더사마다 EJB 컨테이너를 구현한 내용이 다르기 때문에 다른 벤더사의 컨테이너로 변경이 어려웠고, 설정 또한 너무 복잡하다는 문제로 부각되었다. 따라서 프로젝트 자체가 특정 기술(개발 툴 등)에 종속적인 문제가 있었다.

 

스프링 컨테이너의 탄생

EJB는 컨테이너로부터 필요한 객체를 꺼내 사용하는 방식으로 객체들간의 의존성을 해결하려는 것이었지만 비지니스 로직에 특정 기술이 종속되는 것이 가장 큰 문제점이었다. 2002년 '로드 존슨'은 특정 클래스를 상속하거나 인터페이스를 구현하지 않은 평범한 자바 클래스 (POJO : Plain Old Java Object (느슨한 Java Bean, Spring Bean))을 이용하며 단순하지만 EJB에서 제공하는 고급 기술을 제공하는 Spring을 창시하게 된다.

 

스프링은 '자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크' 라고 정의된다.

평범한 자바 클래스를 이용하여 EJB 기능을 유지하면서 복잡성(기존 EJB 컨테이너에서 제공하는 API를 상속받거나 구현하여 코드를 작성하는 부분들)을 제거해 코드가 단순&가벼워졌고 스프링에 특화된 인터페이스 구현을 요구하지 않는 등 자바 개발의 폭넓은 간소화를 실현하게 된다. 또한 스프링은 여러 객체들을 의존생 해결(DI) 및 제어(IOC)하며 객체들의 라이프 사이클을 관리해준다.

https://hoon93.tistory.com/56

EJB와 스프링 개론

 

POJO(Plain Old Java Object)

Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다. 

“우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고.”
 — 마틴 파울러 —

POJO라는 용어는 이후에 주로 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용되었다. 스프링 프레임워크는 POJO 방식의 프레임워크이다.

 

POJO란 특정 기술에 종속되지 않는 순수한 자바 객체를 의미한다. 특정 프레임워크를 의존하게 되면 그것을 POJO라 할 수 없다.

특정 기술에 종속되지 않는 순수 자바객체로 POJO라고 할 수 있다.

Window의 기능을 사용하기 위해 WindowAdapter 클래스를 상속받았다.

이렇게 되면 다른 솔루션을 사용하고자 할 때 많은 양의 코드를 리팩토링해야하는 문제가 있다.

 

이처럼 특정 기술과 환경에 종속되어 의존하게 되면, 코드 가독성뿐 아니라 유지보수, 확장성에도 어려움이 생긴다. 이러한 객체지향의 장점을 잃어버린 자바를 되살리기위해 POJO라는 개념이 등장했다.

 

토비의 스프링에서는 POJO를 다음과 같이 정의하였다.

 

그럼 특정 기술규약과 환경에 종속되지 않으면 모두 POJO라고 말할 수 있는가? 많은 개발자가 크게 오해하는 것 중의 하나가 바로 이것이다. ...(중략)... 
진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

https://yoo11052.tistory.com/133

[Spring] POJO란?

 

 

스프링도 세월이 지나고 여러 기술이 축적되면서 점점 몸집을 불려나가다 보니 부차적으로 설정해야하는 기술이 늘어났다. 스프링을 기반으로 한 스프링 생태계 지원 기술이 너무 많아져 스프링의 기능도 점점 많아졌다.

다양한 오픈소스의 등장으로 수 많은 라이브러리를 함께 사용해야 하고 스프링 프로젝트 시작 시 필요한 설정이 늘어나며 시작도 하기 전에 복잡한 설정때문에 포기하게 되기도 한다. (스프링의 버전과 라이브러리끼리의 버전 설정도 맞는 버전끼리 설정해야한다는 번거로움까지)

• 핵심기술: 스프링 DI 컨테이너, AOP, 이벤트
• 웹기술: 스프링 MVC, 스프링 WebFlux
• 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원
• 기술 통합: 캐시, 이메일 원격접근, 스케줄링
• 테스트: 스프링 기반 테스트 지원
• 스프링 기반 지원 기술: 스프링 데이터, 스프링 세션, 스프링 시큐리티, 스프링 Rest Docs, 스프링 배치, 스프링 클라우드..

이러한 문제점을 해결하기 위해 스프링 부트가 나왔다.

 

스프링 부트의 등장

BOOT, 부트란 말은 최소한의 인간 개입으로 시작하고 완전히 작동하는 것을 의미하며 어떤 일을 시작하기 위해 필요한 모든 준비를 마친다는 의미이다.

시작을 위한 복잡한 설정 과정은 스프링 부트가 해결하고 개발자는 새로운 스프링 어플리케이션을 쉽고 빠르게 시작할 수 있다. 스프링을 편리하게 사용할 수 있도록 지원하는 도구이며, 최근에는 기본적으로 부트를 사용하고 단독으로 실행할 수 있는 스프링 어플리케이션을 쉽게 생성하고 있다. 관례에 의한 간결한 설정이 장점이다.

 

스프링 부트 핵심 기능 5가지

• WAS : Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
• 라이브러리 관리
  • 손쉬운 빌드 구성을 위한 스타터 종속성 제공
  • 스프링과 외부 라이브러리의 버전을 자동으로 관리
• 자동 구성 : 프로젝트 시작에 필요한 스프링과 외부 라이브러리의 빈을 자동 등록(Auto Configuration)
• 외부 설정 : 환경에 따라 달라져야하는 외부 설정 공통화(local, dev, staging, OS 환경변수, 자바 시스템 속성)
• 프로덕션 준비 : 모니터링을 위한 메트릭, 상태 확인 기능 제공 (프로메테우스, 그라파나)

 

스프링 프레임워크와 스프링 부트

스프링 부트는 스프링 프레임워크를 쉽게 사용할 수 있게 도와주는 도구로 본질은 스프링 프레임 워크이다.

하지만 스프링 부트가 제공하는 편의 기능이 막강하여 스프링 부트 사용이 필수로 자리잡고 있다.

 

스프링 부트를 배워야 하는 이유

스프링 부트는 사용하기 편리하지만 너무 많은 것을 자동화하여 문제가 발생했을 때 어떤 원리로 작동하는지 알아야 문제점을 쉽게 파악하여 해결이 가능하다. 

대부분 개발자가 비슷하게 고민하는 기능을 스프링 부트는 이미 만들어서 제공하고 있고 수 많은 편의 기능들을 제공한다.

예를 들어 외부설정이나 액추에이터를 통한 모니터링 관리 기능 등... 실용적이고 이미 잘 만들어진 기능들을 많이 제공해주니 개발 시간이 단축된다는 장점도 있다.

 

 

프로메테우스와 그라파나

개발 서버같은 머신들의 상태를 모니터링을 위한 도구로 프로메테우스는 상태 데이터를 수집하고, 그라파나는 프로메테우스로 수집한 데이터를 관리자가 보기 좋게 각종 그래프로 시각화한다. 컨테이너 인프라 환경에서는 많은 종류의 소규모 기능이 각각 나누어 개발되기 때문에 중앙 모니터링이 필요하다. 이 때 효율적으로 모니터링하는 방법 중 하나가 프로메테우스와 그라파나의 조합이다. 프로메테우스와 그라파나는 컨테이너로 패키징돼 동작하며 최소한의 자원으로 쿠버네티스 클러스터의 상태를 시각적으로 표현한다.

데이터를 시각화하는 도구는 그라파나 외에도 키바나, 크로노그래프 등이 있으나 업계에서는 그라파나와 키바나가 시장

을 양분화한 상태다. 하지만 키바나는 프로메테우스와 연결구성이 복잡하여 그라파나를 더 선호한다.

 

https://thebook.io/080241/ch01/02/04/

컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커: 1.2.4 프로메테우스와 그라파나

 

액추에이터

액추에이터는 스프링 부트 애플리케이션의 모니터링이나 매트릭과 같은 기능을 HTTP와 JMX 엔드포인트를 통해 제공한다.

액추에이터는 실행중인 애플리케이션의 내부를 볼 수 있게하고, 어느 정도까지는 애플리케이션의 작동 방법을 제어할 수 있게한다.

• 애플리케이션 환경에서 사용할 수 있는 구성 속성들
• 애플리케이션에 포함된 다양한 패키지의 로깅 레벨
• 애플리케이션이 사용 중인 메모리
• 지정된 엔드포인트가 받은 요청 횟수
• 애플리케이션의 건강 상태 정보

https://incheol-jung.gitbook.io/docs/study/srping-in-action-5th/chap-16.

CHAP 16. 스프링 부트 액추에이터 사용하기 - Incheol's TECH BLOG

 

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-%ED%99%9C%EC%9A%A9/dashboard