탐험가

1. 빌드 (Build)

1. 빌드란?

 - 소스코드 파일을 컴퓨터에서 실행할 수 있는 독립 소프트웨어 가공물로 변환하는 과정 또는 그에 대한 결과물 이다.
 - 이를 좀더 쉽게 풀어 말하자면 우리가 작성한 소스코드(java), 프로젝트에서 쓰인 각각의 파일 및 자원 등(.xml, .jpg, .jar, .properties)을 JVM이나 톰캣같은 WAS가 인식할 수 있는 구조로 패키징 하는 과정 및 결과물이라고 할 수 있다.

2. 빌드 도구(Build tool)

 - 빌드 도구란 프로젝트 생성, 테스트 빌드, 배포 등의 작업을 위한 전용 프로그램.
 - 빠른기간동안 계속해서 늘어나는 라이브러리 추가, 프로젝트를 진행하며 라이브러리의 버전 동기화의 어려움을 해소하고자 등장.
 - 초기의 java 빌드도구로 Ant를 많이 사용하였으나 최근 많은 빌드도구들이 생겨나 Maven이 많이 쓰였고, 현재는 Gradle이 많이 쓰인다.
(Ant는 스크립트 작성도 많고, 라이브러리 의존관리가 되지 않아 불편함)

Maven은 무엇인가?

Maven은 자바 프로젝트의 빌드(build)를 자동화 해주는 빌드 툴(build tool)이다. 즉, 자바 소스를 compile하고 package해서 deploy하는 일을 자동화 해주는 것이다.

 - Maven은 자바용 프로젝트 관리도구로 Apache Ant의 대안으로 만들어졌다.  

- Maven은 Ant와 마찬가지로 프로젝트의 전체적인 라이프 사이클을 관리하는 도구 이며, 많은 편리함과 이점이 있어 널리 사용되고 있다.

Maven의 특징

 - Maven은 필요한 라이브러리를 특정 문서(pom.xml)에 정의해 놓으면 내가 사용할 라이브러리 뿐만 아니라 해당 라이브러리가 작동하는데에 필요한 다른 라이브러리들까지 관리하여 네트워크를 통해서 자동으로 다운받아 준다. 

 - Maven은 중앙 저장소를 통한 자동 의존성 관리를 중앙 저장소(아파치재단에서 운영 관리)는 라이브러리를 공유하는 파일 서버라고 볼 수 있고, 메이븐은 자기 회사만의 중앙 저장소를 구축할수도 있다.  

- 간단한 설정을 통한 배포 관리가 가능 하다.

Ant와 Maven의 차이

1. Ant는 비교적 자유도가 높은 편     (Ant : 전처리 / 컴파일 / 패키징 / 테스팅 / 배포 가능) 

2. Maven은 정해진 라이프사이클에 의하여 작업 수행하며, 전반적인 프로젝트 관리 기능까지 포함.    (Build Tool + Project Management)

Maven LifeCycle

1) LifeCycle
 - 미리 정해진 빌드순서
 - 메이븐은 프레임워크이기 때문에 동작 방식이 정해져있고, 미리 정의하고 있는 빌드 순서가 있다. 이를 라이프사이클(Lifecycle)이라 한다. 

◎ Default(Build) : 일반적인 빌드 프로세스를 위한 모델이다.
◎ Clean : 빌드 시 생성되었던 파일들을 삭제하는 단계
◎ Validate : 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용할 수 있는지 확인하는 단계
◎ Compile : 프로젝트의 소스코드를 컴파일 하는 단계
◎ Test : 유닛(단위) 테스트를 수행 하는 단계(테스트 실패시 빌드 실패로 처리, 스킵 가능)
◎ Pacakge : 실제 컴파일된 소스 코드와 리소스들을 jar, war 등등의 파일 등의 배포를 위한 패키지로 만드는 단계
◎ Verify : 통합 테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계
◎ Install : 패키지를 로컬 저장소에 설치하는 단계
◎ Site : 프로젝트 문서와 사이트 작성, 생성하는 단계
◎ Deploy : 만들어진 package를 원격 저장소에 release 하는 단계

LifeCycle 진행순서

 - mvn install : 로컬 저장소로 배포

 - mvn deploy : 원격 저장소로 배포

 - mvn clean : 빌드 과정에서 생긴 target 디렉토리 내용 삭제

 - mvn site : target/site에 문서 사이트 생성

 - mvn site-deploy : 문서 사이트를 서버로 배포

<build>에서 설정할 수 있는 값을 확인

<finalName> : 빌드 결과물(ex .jar) 이름 설정

<resources> : 리소스(각종 설정 파일)의 위치를 지정할 수 있다.

- <resource> : 없으면 기본으로 "src/main/resources"

<testResources> : 테스트 리소스의 위치를 지정할 수 있다.

- <testResource> : 없으면 기본으로 "src/test/resources"

<Repositories> : 빌드할 때 접근할 저장소의 위치를 지정할 수 있다. 기본적으로 메이븐 중앙 저장소인 http://repo1.maven.org/maven2로 지정되어 있다.

<outputDirectory> : 컴파일한 결과물 위치 값 지정, 기본 "target/classes"

<testOutputDirectory> : 테스트 소스를 컴파일한 결과물 위치 값 지정, 기본 "target/test-classes"

<plugin> : 어떠한 액션 하나를 담당하는 것으로 가장 중요하지만 들어가는 옵션은 제 각각이다. 

- <executions> : 플러그인 goal과 관련된 실행에 대한 설정

- <configuration> : 플러그인에서 필요한 설정 값 지정

최종 빌드 순서는 compile => test => package 이다. 
① compile : src/main/java 디렉토리 아래의 모든 소스 코드가 컴파일 된다.

② test : src/test/java, src/test/resources 테스트 자원 복사 및 테스트 소스 코드 컴파일 된다.

③ packaging : 컴파일과 테스트가 완료 된 후, jar, war 같은 형태로 압축하는 작업.

2) Phase(단계) Build Lifecycle의 각각의 단계를 Phase라고 한다. 

Phase는 의존관계를 가지고 있어 해당 Phase가 수행되려면 이전 단계의 Phase가 모두 수행되어야 한다. 

즉, 모든 빌드단계는 이전 단계가 성공적으로 실행되었을 때 실행된다는 것이 Dependency 입니다. 

3) Goal  - 특정 작업, 최소한의 실행 단위(task).  

- 하나의 플러그인에서는 여러 작업을 수행할 수 있도록 지원하며, 플러그인에서 실행할 수 있는 각각의 기능(명령)을 Goal이라고 한다. (각각 Phase에 연계된 Goal을 실행하는 과정을 Build라고 한다.)

 - 플러그인의 goal을 실행하는 방법.  

■ - mvn groupId:artifactId:version:goal(생략 가능)

■ - mvn plugin:goal

4 Maven 설정파일

1) settings.xml
- 메이븐 빌드 툴과 관련한 설정파일
- MAVEN_HOME/conf 디렉토리에 위치 (메이븐 설치 시 기본 제공)
- settings.xml의  설정
  

2) POM(프로젝트 객체 모델(Project Object Model))
- POM은 pom.xml파일을 말하며 pom.xml은 메이븐을 이용하는 프로젝트의 root에 존재하는 xml 파일이다.
 - Maven의 기능을 이용하기 위해서 POM이 사용된다. 
 - 파일은 프로젝트마다 1개이며, pom.xml만 보면 프로젝트의 모든 설정, 의존성 등을 알 수 있다.
 - 다른 파일이름으로 지정할 수도 있다.

Maven이 참조하는 설정파일

1) settings.xml

settings.xml은 maven tool 자체에 관련된 설정을 담당한다.

MAVEN_HOME/conf/ 아래에 있다. ( * MAVEN_HOME은 환경변수에 설정한 경로)

Maven 자체에 설정 값을 바꾸는 일은 일단 잘 없으므로 넘어가고 기획한대로 pom.xml을 살펴본다.

2) pom.xml

하나의 자바 프로젝트에 빌드 툴로 maven을 설정했다면, 프로젝트 최상위 디렉토리에 "pom.xml"이라는 파일이 생성되었을 것이다.

pom.xml은 POM(Project Object Model)을 설정하는 부분으로 프로젝트 내 빌드 옵션을 설정하는 부분이다.

꼭 pom.xml이라는 이름을 가진 파일이 아니라 다른 파일로 지정할 수도 있다. 

pom.xml 분석

Spring boot에서 프로젝트를 생성했을 때 나오는 pom.xml의 내용이다.

pom.xml은 <project>...</project>로 둘러싸여서 section별로 여러 정보를 나타내며 설정할 수 있다.

▶ 엘리먼트 

◎ modelVersion : POM model의 버전 

◎ parent : 프로젝트의 계층 정보 

◎ groupId : 프로젝트를 생성하는 조직의 고유 아이디를 결정한다. 일반적으로 도메인 이름을 거꾸로 적는다. 

◎ artifactId : 프로젝트 빌드시 파일 대표이름 이다. groupId 내에서 유일해야 한다.

◎ version : 프로젝트의 현재 버전, 프로젝트 개발 중일 때는 SNAPSHOT을 접미사로 사용.

◎ packaging : 패키징 유형(jar, war, ear 등)

◎ name : 프로젝트, 프로젝트 이름

◎ description : 프로젝트에 대한 간략한 설명

◎ url : 프로젝트에 대한 참고 Reference 사이트

◎ properties : 버전관리시 용이 하다.

◎ dependencies : dependencies태그 안에는 프로젝트와 의존 관계에 있는 라이브러리들을 관리 한다.

◎ build : 빌드에 사용할 플러그인 목록

1) 프로젝트 정보

제일 위에 태그부터 살펴보도록 한다.

<modelVersion> : 4.0.0이라고 써있는데 이것은 maven의 pom.xml의 모델 버전이다. 형식이 4.0.0 버전이라고 이해하면 된다.

<groupId> : 프로젝트를 생성한 조직 또는 그룹명으로 보통, URL의 역순으로 지정한다.

<artifactId> : 프로젝트에서 생성되는 기본 아티팩트의 고유 이름이다.

메이븐에 의해 생성되는 일반적인 artifact는 <artifact>-<version>.<extention>이다. (ex demo-0.0.1-SNAPSHOT.jar)

<version> : 애플리케이션의 버전. 접미사로 SNAPSHOT이 붙으면 아직 개발단계라는 의미이며, 메이븐에서 라이브러리를 관리하는 방식이 다르다고 한다.

<packaging> : jar, war, ear, pom등 패키지 유형을 나타낸다.

<name> : 프로젝트 명

<description> : 프로젝트 설명

<url> : 프로젝트를 찾을 수 있는 URL

위와 같은 태그들은 프로젝트 정보에 관련된 내용이다.

* <properties> : pom.xml에서 중복해서 사용되는 설정(상수) 값들을 지정해놓는 부분. 다른 위치에서 ${...}로 표기해서 사용할 수 있다. (java.version에 1.8을 적용하고 다른 위치에서 ${java.version}이라고 쓰면 "1.8"이라고 쓴 것과 같다.

* <profiles> : dev, prod 이런식으로 개발할 때, 릴리즈할 때를 나눠야할 필요가 있는 설정 값은 profiles로 설정할 수 있다.

maven goal 부분에 -P 옵션으로 프로파일을 선택할 수 있다.

mvn compile -P prod 라고 하면 ${java.version}은 1.9가 된다. 

2. 의존성 라이브러리 정보

의존성 라이브러리 정보를 적을 수 있다.

최소한 groupId, artifactId, version 정보가 필요하다.

스프링부트의 spring-boot-starter-*같은 경우에는 부모 pom.xml에서 이미 버전정보가 있어서 version은 따로 지정할 필요가 없다. 특히 스프링부트는 해당 스프링버전에 잘 맞는 버전으로 이미 설정되어 있기 때문에 오버라이드해서 문제가 생기는 부분은 순전히 개발자 탓이다.

그리고 A라는 라이브러리를 사용하는데 B,C,D가 의존성을 가진다면 A를 dependency에 추가하면 자동으로 필요한 B,C,D도 가져오는 기능이 있다.

3. build 정보

build tool : maven의 핵심인 빌드와 관련된 정보를 설정할 수 있는 곳이다.

<build> 부분에서 설정할 수 있는 값들에 대해 설명하기 전에 "라이프 사이클(life-cycle"에 대해서 알 필요가 있다.

객체의 생명주기처럼 maven에는 라이프 사이클이 존재한다.

크게 default, clean, site 라이프 사이클로 나누고 세부적으로 페이즈(phase) 있다

1. 제어의 역전(IOC)

2. 의존성 주입(DI)

3. 관심 지향 프로그래밍(AOP)

이런 특징으로 결합도를 낮춰(Loose coupling) 유연한 개발이 가능해졌습니다.

1. 제어의 역전(IOC)


제어의 역전 패턴이 인기를 끄는 이유는 프로그램의 생명주기에 대한 제어권이 웹 애플리케이션 컨테이너에 있기 때문입니다. 즉, 사용자가 직접 new 연산자를 통해 인스턴스를 생성하고 메서드를 호출하는 일련의 생명주기에 대한 작업들을 스프링에 위임할 수 있게 되는 것입니다.

쉽게 말해 개념적으로 IOC(제어의 역전)라는 것은 간단한 의미인데, 원래 개발자가 해왔던 일을 컨테이너라는 객체 관리 프로그램이 알아서 해준다는 것이다. 프레임워크를 쓰는 이유 중의 하나가 내가 할일을 프레임워크가 대신해주니 코딩이 편해지고 빨리지는 것이다

IOC는 직관적이지 못하기 때문에 IOC를 구현하는 방법으로는 의존성 주입(DI)이 있습니다.



2. 의존성 주입(DI)

컨테이너에서 관리할 객체를 지정해주고, 코드(app) 내에서는 컨테이너에서 객체를 받아 사용하는 방식
빈을 정의할 때 객체 간 의존 관계를 명시해 코드에서 사용 시 자동으로 주입 받도록 함
스프링 컨테이너는 어플리케이션 작동 과정에 필요한 여러 객체들을 알아서 생성하고 지우고 관리해준다고 했습니다. DI는 개발자가 컨테이너에서 관리될 객체를 지정해줄 때 의존 객체를 지정해주는 작업을 의미합니다



의존성 주입이란? = (DI : Dependency Injection)

객체 사이에 필요한 의존 관계에 대해서 스프링 컨테이너가 자동으로 연결해 주는 것을 말합니다

스프링 컨테이너는 DI를 이용하여 빈(Bean) 객체를 관리하며, 스프링 컨테이너에 클래스를 등록하면 스프링이 클래스의 인스턴스를 관리해 줍니다

의존성이란?? : 간단히 생각하면 스마트폰을 사용하기 위해서는 배터리가 필요합니다. 배터리가 없으면 스마트폰은 사용할 수 없죠? 즉 스마트폰은 배터리에 의존한다고 보면 됩니다. 만약 그 배터리가 스마트폰과 일체형으로 되어있으면 어떤가요?

배터리 교체를 하기 위해선 분리형과 비교해서 가볍게 바꿀 수가 없겠죠?

 

이러한 의존성에 대해서 느슨한 결합이 필요하고 의존성을 주입받아 사용받을 필요성이 있게 되는 겁니다.

스프링이란 이름이 생겨난 이유

Whatever happened next, the framework needed a name. In the book it was referred to as the “Interface21 framework” (at that point it used com.interface21 package names), but that was not a name to inspire a community. Fortunately Yann stepped up with a suggestion: “Spring”. His reasoning was association with nature (having noticed that I'd trekked to Everest Base Camp in 2000); and the fact that Spring represented a fresh start after the “winter” of traditional J2EE. We recognized the simplicity and elegance of this name, and quickly agreed on it.

해석하면 : 기존의 J2EE의 "겨울"로부터 새로운 시작의 "봄"이 왔다고 합니다 

스프링(String)이란?

스프링 = String -> 자바 기반의 웹 애플리케이션을 만들 수 있는 프레임워크

스프링(Spring)의 정확한 명칭은 스프링 프레임워크(Spring Framework)입니다.

스프링에 대해서 이해하기 위해서는 프레임워크가 무엇인지, 라이브러리와의 차이를 알아야 합니다.

라이브러리는 간단하게 특정 기능을 하는 코드 뭉치이다.

개발자는 자기 코드에 라이브러리를 포함시키고 원하는 기능을 사용해서 개발을 할 수 있다. 더욱 간단하게는 원하는 기능을 하는 함수를 콜해서 사용하는 것으로 라이브러리를 활용한다.

프레임워크는 라이브러리를 포함하는 개념이고, 개발자가 만든 코드를 사용한다. 스프링 프레임워크는 여러 라이브러리를 제공하고, 그것을 활용해서 개발한 프로그램을 동작시킨다.

소스를 어떻게 실행하는지는 코드를 사용하는 프레임워크에 달려있다

스프링 사이트에서는 스프링 프레임워크가 인프라와 관련된 내용을 애플리케이션 레벨에서 설정하도록 해줌으로써 개발자가 코드로 대부분을 컨트롤 할 수 있게끔 지원한다고 설명한다. 즉, 개발자가 코드 안에 애플리케이션 동작에 대한 내용을 기술하면 스프링 프레임워크가 이를 해석해서 동작하는 것이다.

스프링을 사용하는 가장 일반적인 예로는 Servlet API 가 있다. 개발자는 API를 처리할 클래스를 정의하고 이것이 Servlet API 를 위한 클래스임을 표시(어노테이션 활용)한다. 그 이후 프로그램을 실행하면 스프링은 API 요청이 들어오면 해당 클래스를 이용해서 처리한다. 개발자가 Servlet에 관련된 것을 개발하지 않아도 되며, 데이터 바인딩, 객체 생성 등 왠만한 것들은 스프링이 알아서 해준다. 이런 편한 점 때문에 많은 개발자들이 스프링 프레임워크를 사용하고 있다.

스프링 부트란? (Spring Boot)
스프링 프레임워크는 기능이 많은만큼 환경설정이 복잡한 편이다. 이에 어려움을 느끼는 사용자들을 위해 나온 것이 바로 스프링 부트다. 스프링 부트는 스프링 프레임워크를 사용하기 위한 설정의 많은 부분을 자동화하여 사용자가 정말 편하게 스프링을 활용할 수 있도록 돕는다. 스프링 부트 starter 디펜던시만 추가해주면 바로 API를 정의하고, 내장된 탐캣이나 제티로 웹 애플리케이션 서버를 실행할 수 있다. 심지어 스프링 홈페이지의 이니셜라이저를 사용하면 바로 실행 가능한 코드를 만들어준다. 실행환경이나 의존성 관리 등의 인프라 관련 등은 신경쓸 필요 없이 바로 코딩을 시작하면 된다. 그리고 바로 그것이 스프링의 키 포인트이다.

정리

스프링 프레임워크는 라이브러리가 아닌 프레임워크이다. 단순히 코드를 제공하는 것이 아니라 프로그래밍 방법을 제공한다. 이렇게 프로그래밍 방법을 제공하고 개발자가 그에 맞추어 개발하는 방식은 어쩌면 너무 딱딱하고 획일화된 프로그램을 만들 수 있다. 하지만 특정 목적을 위한 프로그램을 만드는 데에 있어서 정형화된 방식은 효율성을 극대화 시켜준다. 그리고 스프링을 처음 사용하거나 웹 애플리케이션 서버를 간단히 만들 때 스프링 부트로 개발을 한다면 정말 빠르고 간편하게 프로그램을 만들 수 있다.

Message Queue(MQ) = 메시지 큐 -> 프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법 중에 하나로 메시지를 저장하는 공간이다.

Producer = 프로듀서(생산자) -> 생산자로 취급되는 컴포넌트가 메시지를 메시지 큐에 추가한다. 메시지를 생산하고, 메시지를 저장공간인 큐에 전송하는 역할을 한다.

Consumer = 컨슈머(소비자) -> 메시지를 처리하는 방식, 메시지 큐에 저장되어 있는 메시지를 읽어와서 처리하는 방식

Message Broker = 메시지 브로커 -> Publisher(송신자)로부터 전달받은 메시지를 Subscriber(수신자)로 전달해주는 중간 역할이며 응용 소프트웨어 간에 메시지를 교환할 수 있게 한다. 메시지의 그룹을 Topic(토픽)이라고 한다.

Topic = 토픽 -> 메시지를 저장하는 단위, Producer로 메시지 큐에 메시지를 넣으면 Topic에 저장되고, Consumer로 메시지 큐에서 메시지를 가져갈 때 Topic에서 가져간다. 즉, Producer와 Consumer는 Topic를 기준으로 메시지를 주고받게 된다.

partition = 파티션 -> 메세지가 저장되는 물리적인 파일

브로커 = 파티션에 저장되는 메시지를 파일 시스템에 저장, 파일시스템 = "세그먼트 파일"

Publisher / Subscriber = Producer / Consumer

-> 메시지를 메시지 큐의 저장순서는 FIFO방식으로 먼저 들어온 메시지부터 저장되고, 메시지를 가져갈 때는 먼저 들어온 메시지 부터 나가는 방식이다.

메시지 큐를 사용하는 이유

1. 메시지는 consumer로 취급되는 다른 컴토넌트가 메시지를 검색하고, 어떤 작업을 수행할 때까지 작업을 수행한다.

2. 각 메시지는 하나의 소비자에 의해 한번만 처리될 수 있는데, 이러한 이유로 메시지 큐를 이용하는 방식을 일대일 통신이라고 부른다.

일대일통신(유니 캐스팅) / 일대다통신(멀티 캐스팅)

메시지 큐를 이용해서 무엇을 하는가?

- 이메일 전송 = 이메일 발급서비스, 회원가입을 위해 이메일 발급 서비스

- 블로그 포스팅 = 사용자 -> 이미지가 포함된 블로그 포스팅 -> 이미지를 저장소에 전송 -> 이미지 정보가 포함된 메시지를 메시지 큐(저장소)에 저장 -> 메시지 큐(저장소)에서 이미지를 가져와 최적화

메시지 큐의 장점

• 비동기(Asynchronous): Queue에 넣어두기 때문에 나중에 처리할 수 있다.
• 분리 또는 비동조(Decoupling): 애플리케이션과 분리할 수 있다.
• 탄력성(Resilience): 일부가 실패 시 전체에 영향을 받지 않는다.
• 과잉(Redundancy): 실패 할 경우 재실행이 가능하다.
• 보증(Guarantees): 작업이 처리된 걸 확인할 수 있다.
• 확장성(Scalable): 다수의 프로세스들이 큐에 메시지를 보낼 수 있다.

대표적인 메시지 큐(MQ)의 종류 = ActiveMQ(JMS), RabbitMQ, kafka

1. ActiveMQ(JMS)

MOM을 자바에서 지원하는 표준 API이다. JMS는 다른 자바 애플리케이션들끼리 통신이 가능하지만 다른 MOM의 통신은 불가능하다. (AMQP, SMTP 같은)

ActiveMQ의 JMS 라이브러리를 사용한 자바 애플리케이션들끼리 통신이 가능하다. 하지만 다른 자바 애플리케이션(Non ActiveMQ)의 JMS와는 통신할 수 없다.

2. RabbitMQ

RabbitMQ는 AMQP(Advanced Message Queuing Protocol)를 구현한 오픈소스 메시지 브로커이다.

AMQP는 MQ를 오픈 소스에 기반한 표준 프로토콜이다. 프로토콜만 맞다면 다른 AMQP를 사용한 애플리케이션끼리 통신이 가능하다. 플러그인을 통해서 SMTP, STOMP 프로토콜과의 확장이 가능하다.

AMQP는 메세지 전달을 아래 3가지 방식 중 하나를 보장한다.

• At-Most-Once: 각 메시지는 한번만 전달되거나 전달되지 않음
• At-Least-Once: 각 메시지는 최소 한번 이상 전달됨을 보장
• Exactly-Once: 각 메시지는 딱 한번만 전달됨

AMQP는 메시징 제공자와 클라이언트의 동작에 대해 각기 다른 벤더들의 구현체가 상호 운용될 수 있는 정도로까지 권한을 준다. 이는 SMTP, HTTP, FTP 등이 상호 운용이 가능한 시스템을 만든다는 점에서 동일하다.

• Producer(Publisher): 메시지를 보내는 곳이다.
• Consumer(Subscriber): 메시지를 받는 곳이다.
• Exchange: Producer로부터 메시지를 수신하는 곳. 수신한 메시지를 큐에 분배한다.
• Queue: 메시지를 저장하는 곳. 저장했다가 Consumer에게 전달한다.
• Binding: Exchange와 Queue의 Mapping. 1:1 또는 1:N

Exchange가 Producer로부터 메시지를 받고 Queue에 전달한다. Queue는 Consumer에게 메시지를 전달한다.

3. Apache Kafka

Apache Kafka는 LinkedIn이 개발하고 Apache Software Foundation에 기부한 오픈 소스 스트림 프로세싱 소프트웨어 플랫폼이다.

높은 처리량을 요구하는 실시간 데이터 피드 처리나 대기 시간이 짧은 플랫폼을 제공하는 것을 목표로 하며 TCP 기반 프로토콜을 사용한다. 클러스터를 중심으로 Producer와 Consumer가 데이터를 Push하고 Pull하는 구조를 가진다.

특징

• Publisher / Subscriber 모델
• 고가용성
• 확장성
• 디스크 순차 저장 및 처리
• 분산 처리 (Partitioning)

카프카는 내구성이 뛰어난 메시지 저장소로, 고객들은 메시지가 한 번 배달되면 대기열에서 제거되는 전통적인 메시지 중개업자들과는 달리, 필요에 따라 이벤트 스트림을 재생할 수 있다.

대용량의 실시간 로그 처리에 특화되어 설계된 메시징 시스템으로써 기존 범용 메시징 시스템대비 TPS(Transaction per second)가 매우 우수하다. 단, 특화된 시스템이기 때문에 범용 메시징 시스템에서 제공하는 다양한 기능들은 제공되지 않는다.

분산 시스템을 기본으로 설계되었기 때문에 기존 메시징 시스템에 비해 분산 및 복제 구성을 손쉽게 할 수 있다.

AMQP 프로토콜이나 JMS API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP기반의 프로토콜을 사용하여 프로토콜에 의한 오버헤드를 감소시켰다.

Producer가 Broker에게 다수의 메시지를 전송할 때 각 메시지를 개별적으로 전송해야하는 기존 메시징 시스템과는 달리, 다수의 메시지를 batch형태로 Broker에게 한 번에 전달할 수 있어 TCP/IP 라운드 트립 횟수를 줄일 수 있다.

메시지를 기본적으로 메모리에 저장하는 기본 메시징 시스템과는 달리 메시지를 파일 시스템에 저장한다. (RabbitMQ는 ram or disk 선택가능)

파일 시스템에 메시지를 저장하기 때문에 별도의 설정을 하지 않아도 데이터의 영속성이 보장된다.

기존 메시징 시스템에서는 처리되지 않고 남아있는 메시지의 수가 많을수록 시스템의 성능이 크게 감소하였으나, Kafka에서는 메시지를 파일 시스템에 저장하기 때문에 메시지를 많이 쌓아두어도 성능이 크게 감소하지 않는다. 또한 많은 메시지를 쌓아둘 수 있기 때문에, 실시간 처리뿐만 아니라 주기적인 batch 작업에 사용할 데이터를 쌓아두는 용도로도 사용할 수 있다.

Consumer에 의해 처리된 메시지(ack)를 곧바로 삭제하는 기존 메시징 시스템과는 달리 처리된 메시지를 삭제하지 않고 파일 시스템에 그대로 두었다가 설정된 수명이 지나면 삭제한다. 처리된 메시지를 일정 기간동안 삭제하지 않기 때문에 메시지 처리 도중에 문제가 발생하였거나 처리 로직이 변경되었을 경우 Consumer가 메시지를 처음부터 다시 처리(rewind)하도록 할 수 있다.

기존의 메시징 시스템에서는 Broker가 Consumer에게 메시지를 Push해주는 방식인데 반해, Kafka는 Consumer가 Broker로부터 직접 메시지를 가지고 가는 pull(poliing)방식으로 동작한다. 따라서 Consumer는 자신의 처리능력만큼의 메시지만 Broker로부터 가져오기 때문에 최적의 성능을 낼 수 있다.

메시지를 Pull 방식으로 가져오므로, 메시지를 쌓아두었따가 주기적으로 처리하는 Batch Consumer의 구현이 가능하다.

큐의 기능은 JMS, AMQP 기반의 RabbitMQ등에 비해서는 많이 부족하지만 대용량 메시지를 지원할 수 있는 것이 가장 큰 특징이다. 특히 분산 환경에서 복사본을 다른 노드에 저장함으로써 노드 장애에 대한 장애 대응성을 가지고 있는 강점이 있다.