[클라우드 네이티브 스프링 인 액션] 1-2. 클라우드 네이티브 패턴 및 기술

애플리케이션 코드 베이스 -빌드→ 자바 애플리케이션 -패키징→ 컨테이너 이미지 -포함→ 쿠버네티스 파드

 

1. 클라우드 네이티브 개발 원칙 : 15요소

[1] 하나의 코드베이스, 하나의 애플리케이션

• 애플리케이션과 코드 베이스 사이의 일대일 관계를 설정한다.
• 배포는 애플리케이션의 실행 인스턴스다. 서로 다른 환경으로의 배포가 가능하며 각 환경에서 실행되는 애플리케이션 아티팩트는 모두 동일하다.
• 애플리케이션을 특정 환경에 배포하기 위해 코드베이스를 다시 빌드할 필요가 없다.

 

[2] API 우선

• API 우선 접근 방식을 사용하면 분산 시스템에 적합하도록 시스템을 고려하고 서로 다른 팀 간의 업무를 배분할 수 있다.
• API를 먼저 설계함으로써 해당 애플리케이션을 백엔드 서비스로 사용하는 다른 팀은 해당 API를 가지고 자신들의 시스템 개발을 진행할 수 있다.

 

[3] 의존성 관리

• 모든 의존 라이브러리는 명시적인 방식으로 선언되어야 하며, 이를 통해 라이브러리 관리 툴이 중앙 저장소에서 다운로드할 수 있어야 한다. (JAVA → Maven, Gradle)

 

[4] 설계, 빌드, 릴리스, 실행

• 설계 : 특정 애플리케이션 기능에 필요한 기술, 의존성 및 툴이 결정된다.
• 빌드 : 코드베이스를 컴파일하고 의존 라이브러리와 함께 패키지로 만들어 빌드라고 부르는 불가변 아티팩트를 생성한다.
• 릴리스 : 배포하지 위해 빌드를 특정 설정과 결합한다. 릴리스는 변경할 수 없다.
• 실행 : 애플리케이션의 특정 릴리스가 실행 환경에서 작동한다.

 

[5] 설정, 크리덴셜 및 코드

• 설정 : 배포 사이에 변경될 가능성이 있는 모든 것 (데이터베이스, 메시징 시스템, 유저 정보, 기능 플래그)

 

[6] 로그

• 애플리케이션은 로그를 시간 순서대로 생성되는 이벤트로 처리해 표준 출력에 기록한다.

 

[7] 일회성

• 언제라도 애플리케이션을 시작하거나 중지할 수 있는 경우
• 새 인스턴스가 필요할 때마다 신속하게 시작하고, 필요 없을 때는 정상적으로 종료하도록 설계해야 한다.
• graceful shutdown : 애플리케이션이 종료 신호를 받으면 새로운 요청을 수락하지 않고 이미 진행중인 요청을 모두 완료한 다음 종료하는 것

 

[8] 지원 서비스

• 어떤 애플리케이션이 자신의 기능을 제공하기 위해 사용하는 외부 리소스
• ex. 데이터베이스, 메시지 브로커, 캐싱 시스템, SMTP 서버, FTP 서버, RESTful 웹 서비스
• 탈찰식 리소스처럼 처리하면 애플리케이션 코드를 수정하지 않고도 이 리소스를 쉽게 변경할 수 있다.

 

[9] 환경 동일성

• 모든 환경을 가능한 한 비슷하게 유지하는 것이다.
• 시간 차이 : 코드 변경 이후 배포까지의 기간은 클 수 있다. 자동화 및 지속적 배포를 활용해 기간을 줄일 수 있다.
• 사람 차이 : 개발자는 애플리케이션을 만들고 운영자는 프로덕션에서 배포를 관리한다. 데브옵스 문화를 수용해 개발자와 운영자간의 차이를 줄일 수 있다.
• 도구 파이 : 환경 간의 주요 차이점 중 하나는 지원 서비스를 처리하는 방법이다. 일반적으로는 모든 환경에서 동일한 유형과 동일한 버전의 지원 서비스를 사용해야 한다.

 

[10] 관리 프로세스

• 애플리케이션 프로세스에 대해 수행한 것과 동일한 고려 사항이 관리 프로세스에도 적용된다.
• 관리 작업은 독립형 서비스 또는 특정 이벤트에 의해 실행하는 함수로 구성하거나, 애플리케이션의 일부로 특정 엔드포인트를 호출해 실행하도록 하는 것이 좋다.

 

[11] 포트 바인딩

• 프로덕션에는 외부로 공개된 엔드포인트로 들어온 요청을 특정 포트에 바인딩 된 내부 서비스로 변환하는 라우팅 서비스가 가능하다.
• 웹 애플리케이션은 HTTP 서비스를 특정 포트에 바인딩하고 다른 애플리케이션을 지원하는 서비스로 작동할 수 있다.

 

[12] 상태를 갖지 않는 프로세스

• 상태를 갖지 않는 프로세스 + 아무것도 공유하지 않는 아키텍처 : 애플리케이션 인스턴스 간에 상태를 공유해서는 안 된다.
• 애플리케이션은 상태를 갖지 않도록 설계하고 대신 상태는 데이터 저장소와 같은 상태를 갖는 서비스를 통해 처리해야 한다.

 

[13] 동시성

• 확장이 필요하다는 것은 더 많은 사용자에게 서비스를 제공해야 한다는 의미 → 애플리케이션은 동시성을 통해 많은 사용자에게 서비스를 제공할 수 있어야 한다.
• JVM 애플리케이션에서는 스레드 풀내의 사용 가능한 스레드를 사용해 동시성을 처리한다.

 

[14] 원격 측정

• 클라우드에서 분산 시스템을 관리하는 것은 복잡한데, 이런 복잡성을 관리할 수 있는 유일한 방법은 시스템의 작동을 원격으로 모니터링할 수 있도록 모든 구성 요소가 올바른 데이터를 제공하는 것이다.
• 원격 측정 데이터 ex. 로그, 메트릭, 추적, 상태, 이벤트

 

[15] 인증 및 승인

• Zero Trust 접근법에 따라 시스템 내 상호작용의 안정성은 모든 설계적, 인프라적 수준에서 확보되어야 한다.

 

---

 

2. 스프링을 사용한 클라우드 네이티브 애플리케이션 구축

스프링 개요

• 스프링 플랫폼은 모듈식 설계로 인해 필요한 프로젝트만 사용하고 이들은 결합할 수 있다는 장점이 있다.
• 스프링 프레임 워크 : 스프링 콘텍스트 또는 스프링 컨테이너라고 부르는 실행 콘텍스트를 제공하는데, 여기에서 빈 속성, 리소스가 애플리케이션의 전체 라이프 사이클에 걸쳐 관리된다.

 

스프링 부트 애플리케이션 구축

• 애플리케이션을 구현하는 데 필요한 의존성을 선언
• 스프링 부트로 애플리케이션을 부트스트래핑
• 외부로 제공되는 HTTP 엔드 포인트를 통해 환영 메시지를 반환하는 컨트롤러의 구현
• 애플리케이션의 실행
• OpenJDK 17, IntelliJ IDEA, Github 이용

 

(1) 프로젝트 초기화

 

(2) 컨트롤러 구현

• 카탈로그 서비스는 사용자가 도서 카탈로그에 방문한 것을 환영하기 위한 인사말을 반환하는 HTTP GET 엔드포인트를 노출한다.
• @RestController : HTTP 요청을 처리하는 컨트롤러로 식별

package com.polarbookshop.catalog_service;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HomeController {

    @GetMapping("/")
    public String getGreeting() {
        return "도서 카탈로그에 오신 것을 환영합니다!";
    }
}

 

 

---

 

3. 도커를 통한 애플리케이션 컨테이너화

• 클라우드에 배포하려면 컨테이너로 만들어야 한다. → 주변 환경과의 격리 + 애플리케이션 실행 시 필요 파일이 컨테이너 안에 준비됨
• 컨테이너 사용하지 않는다면, 애플리케이션을 배포하는 머신에 자바 런타임을 설치해야 한다.
• 도커 : 컨테이너라는 느슨하게 격리된 환경에서 애플리케이션을 패키징하고 실행할 수 있는 기능을 제공한다.

 

도커 소개 : 이미지 및컨테이너

• 도커 서버 : 도커 데몬이 포함되어 있다.
• 도커 데몬 : 백그라운드에서 실행하면서 이미지, 컨테이너, 볼륨, 네트워크와 같은 도커 객체를 만들고 관리한다.
• 도커 호스트 : 도커 서버가 실행되는 컴퓨터
• 컴퓨터에서 컨테이너를 실행하려면 컴퓨터가 도커 호스트여야 하고, 도커 데몬이 실행 중이어야 한다.
• 도커 데몬은 API를 제공하는데, 이 API를 통해 컨테이너를 실행하거나 볼륨을 생성하는 것과 같은 명령을 도커에 전달할 수 있다.
• 도커 클라이언트 : 이 API를 사용해 데몬과 상호작용하는 것, 명령어 기반, 도커 명령어 인터페이스를 사용해 데몬과 상호작용한다.
• 컨테이너 저장소 : 컨테이너 이미지를 관리, 배포하는데 사용한다.

• 컨테이너 이미지 : 내부에서 애플리케이션을 실행하는 데 필요한 모든 것을 포함하는 실행 가능한 경량의 패키지
• 도커 이미지 : 컨테이너 이미지를 만드는 데 가장 많이 사용된다.
• 컨테이너 : 컨테이너 이미지의 실행 가능한 인스턴스
• 기본적으로 컨테이너는 다른 컨테이너 혹은 호스트 머신과 격리되어 있지만, 포트 포워딩이나 포트 매핑이라는 프로세스를 통해 서비스를 특정 포트로 노출할 수 있다.

 

컨테이너를 통한 스프링 애플리케이션의 실행

• 스프링 부트와 바로 통합해 사용할 수 있는 클라우드 네이티브 빌드팩을 사용한다.

$ ./gradlew bootBuildImage
$ docker images catalog-service:0.0.1-SNAPSHOT
$ docker run --rm --name catalog-service -p 8080:8080 catalog-service:0.0.1-SNAPSHOT

• --rm : 실행이 끝난 후 컨테이너를 삭제한다.
• -p 8080:8080 : 8080포트를 통해 컨테이너 외부로 서비스를 노출한다.

 

---

 

4. 쿠버네티스로 컨테이너 관리

• 컨테이너 애플리케이션의 배포, 확장, 관리를 자동화하기 위한 오픈소스 시스템
• 도커 : 배포 대상은 하나의 머신
• 쿠버네티스 : 여러 머신으로 구성된 클러스터로 배포할 때 사용
• brew로 minikube를 설치한 후 진행한다.

$ minikube start

 

쿠버네티스 소개 : 배포, 파드, 서비스

• 클러스터 : 컨테이너화된 애플리케이션을 실행하는 작업자 머신의 집합
• 노드 : 작업자 머신
• 모든 클러스터에는 적어도 하나의 작업자 노드가 존재하며, 미니큐브를 사용하면 로컬 머신에서 쉽게 단일 노드 클러스터를 생성할 수 있다.
• 컨트롤 플레인 : 작업자 노드를 관리하는 컨테이너 오케스트레이션 계층이다.
• 쿠버네티스 CLI(kubectl create, get ..) —(객체 선언)—> 컨트롤 플레인 —(객체 생성)—> 작업자 노드
• Pod : 가장 작은 배포 단위, 하나 이상의 컨테이너를 포함한다.
• Deployment : 배포 객체를 통해 애플리케이션에 대해 원하는 배포 상태를 쿠버네티스에 알린다.
• Service : deployment는 클러스터 내의 다른 노드나 외부로 노출된다. 파드 인스턴스들이 균일한 부하를 갖도록 관리한다.

 

쿠버네티스에서 스프링 애플리케이션 실행

• minikube는 도커 허브 레지스트리에서 이미지를 가져오도록 기본 설정되어 있기 때문에 로컬 레지스트리에는 액세스할 수 없다.
• 수동 작업을 통해 도커 허브 레지스트에 있는 이미지를 로컬 클러스터로 가져올 수 있다.

$ minikube image load catalog-service:0.0.1-SNAPSHOT

• 파드는 쿠버네티스가 관리해준다.
• 파드는 애플리케이션 인스턴스이기에 영구적이지 않고 언제든지 삭제할 수 있다.
• 클라우드 네이티브의 목표를 달성하려면 플랫폼이 파드 인스턴스를 관리하고 한 인스턴스가 다운되면 다른 파드로 대체할 수 있어야 한다.
• 이를 위해서는 배포 리소스가 필요한데 이를 통해 쿠버네티스는 애플리케이션 인스턴스를 파드 리소스로 생성할 수 있다.
• 명령어 앞에 'k'는 'kubectl'이다. 빠르게 쓰려고 앨리어스를 지정해놓았다 !

$ k create deployment catalog-service --image=catalog-service:0.0.1-SNAPSHOT

• 쿠버네티스의 기본 설정으로는 파드로 실행중인 애플리케이션에 액세스할 수 없다.
• expose 명령을 통해 애플리케이션을 클러스터에 노출할 수 있다.

$ k expose deployment catalog-service --name=catalog-service --port=8080

• 컴퓨터의 로컬 포트 (ex. 8080)로부터 클러스터 내에서 서비스에 노출된 포트(8080)로 트래픽

$ k port-forward service/catalog-service 8000:8080

• 로컬 컴퓨터에서 8000 포트에 액세스할 때마다 카탈로그 서비스 애플리케이션을 노출하는 쿠버네티스 클러스터 내의 서비스로 전달된다.
• localhost:8000 으로 이동하면 서비스가 보인다.

 

---

 

5. 폴라 북숍 : 클라우드 네이티브 애플리케이션

시스템 요구 사항

• 고객 : 카탈로그에서 책을 검색하고, 구입하고, 주문을 확인할 수 있다.
• 직원 : 책을 관리하고, 기존 정보를 업데이트하며 카탈로그에 새 도서를 추가할 수 있다.