마이크로 서비스 아키텍처 맛보기: 간단한 프로젝트 배포하기(AWS EKS, Java, Spring Boot, Gradle)

마이크로서비스 아키텍처(Micro Service Architecture, MSA)

마이크로서비스 아키텍처의 장점

• 독립적인 배포 및 확장
• 각 마이크로서비스는 독립적으로 배포하고 확장할 수 있습니다. 이를 통해 특정 서비스에 대한 변경이나 확장이 다른 서비스에 영향을 미치지 않습니다.

• 분리된 데이터 저장소
• 각 마이크로서비스는 자신만의 데이터베이스를 가질 수 있습니다. 이로 인해 서비스 간 데이터 형식의 종속성이 제거되며, 각 서비스가 필요에 따라 데이터베이스 유형을 자유롭게 선택할 수 있게 됩니다.

• 변경에 유연한 구조
• 각 마이크로서비스는 독립적이므로, 한 서비스의 변경이나 업데이트가 다른 서비스에 영향을 미치지 않습니다. 따라서 개발팀은 변경 사항을 빠르게 적용하고, 실험적인 기능을 안전하게 테스트할 수 있습니다.

• 분산 개발 효율성
• 마이크로서비스는 각 서비스를 독립적으로 개발할 수 있기 때문에, 다양한 기술 스택을 활용하거나, 분산된 팀 구조를 사용할 수 있습니다.

마이크로서비스 아키텍처의 단점

마이크로서비스 아키텍처를 지원하는 플랫폼

1. 쿠버네티스(Kubernetes)
• 현재 가장 널리 사용되는 컨테이너 오케스트레이션 플랫폼입니다. 컨테이너를 효과적으로 관리하고, 애플리케이션을 확장하며, 네트워킹, 서비스 디스커버리, 보안, 로깅, 모니터링 등을 관리하는 데 사용됩니다.

2. Docker Swarm
• Docker에서 직접 관리하는 컨테이너 오케스트레이션 플랫폼으로, Docker와의 긴밀한 통합이 특징입니다. 쿠버네티스보다 사용법이 간단하지만, 기능적으로는 쿠버네티스에 비해 다소 제한적입니다.

3. Apache Mesos
• 빅데이터 처리와 컨테이너 오케스트레이션을 모두 처리할 수 있는 강력한 플랫폼입니다. 하지만 배포와 관리의 복잡성 때문에 일반적으로 대규모 시스템에서 사용됩니다.

4. Amazon ECS (Elastic Container Service)
• AWS에서 제공하는 컨테이너 오케스트레이션 서비스입니다. AWS 서비스와의 통합이 잘 되어 있지만, 다른 클라우드 플랫폼으로 이동하는 데 제약이 있을 수 있습니다.

5. AWS EKS (Elastic Kubernetes Service)
• AWS에서 제공하는 관리형 쿠버네티스 서비스입니다. 쿠버네티스의 강력한 기능을 AWS 환경에서 사용할 수 있게 해줍니다.

6. Google Kubernetes Engine (GKE)
• Google Cloud에서 제공하는 관리형 쿠버네티스 서비스입니다. 쿠버네티스를 처음 개발한 Google에서 관리하므로, 쿠버네티스에 대한 깊은 이해와 최신 기능을 제공합니다.

7. Azure Kubernetes Service (AKS)
• Microsoft Azure에서 제공하는 관리형 쿠버네티스 서비스입니다. Azure 서비스와의 통합이 잘 되어 있습니다.

쿠버네티스(Kubernetes, k8s)

쿠버네티스의 핵심개념

• 파드(Pod): 파드는 쿠버네티스의 가장 작은 배포 단위입니다. 각 파드는 하나 이상의 컨테이너를 포함하며, 같은 파드 안의 컨테이너들은 같은 네트워크와 저장 공간을 공유합니다.

• 서비스(Service): 서비스는 네트워크에 쿠버네티스의 파드를 노출하는 방법입니다. 서비스를 통해 파드는 네트워크를 통해 다른 파드나 애플리케이션에 연결될 수 있습니다.

• 디플로이먼트(Deployment): 디플로이먼트는 파드의 복제본(replica)을 관리하는 쿠버네티스 리소스입니다. 디플로이먼트는 파드의 스케일링과 롤아웃을 관리하며, 파드에 문제가 발생하면 자동으로 재시작합니다.

쿠버네티스의 장점

• 자동 복구: 쿠버네티스는 장애가 발생하면 자동으로 파드를 재시작하며, 노드에 문제가 있는 경우 파드를 다른 노드로 이동시킵니다.

• 스케일링과 로드 밸런싱: 쿠버네티스는 애플리케이션의 트래픽을 자동으로 분산시키고, 요청에 따라 동적으로 스케일링합니다.

• 선언적 구성: 쿠버네티스는 애플리케이션의 상태를 선언하는 방식으로 작동하므로, 시스템 관리자는 쿠버네티스에 원하는 상태를 선언하면 쿠버네티스가 그 상태를 유지하는 데 필요한 작업을 수행합니다.

AWS EKS(Elastic Kubernetes Service)

AWS EKS 특징

• 표준 호환성
• AWS EKS는 오픈 소스 쿠버네티스를 그대로 사용하기 때문에, 기존 쿠버네티스 애플리케이션을 그대로 이식할 수 있습니다.

• AWS 서비스와의 통합
• AWS EKS는 Amazon RDS, Amazon S3, Amazon DynamoDB와 같은 AWS 서비스와 자연스럽게 연동됩니다. 이는 마이크로서비스의 다양한 요구사항을 쉽게 처리할 수 있게 해줍니다.

• 확장성 및 가용성
• AWS EKS는 클러스터를 여러 AWS 가용 영역에 걸쳐 분산시킬 수 있습니다. 이는 마이크로서비스의 고가용성과 확장성을 보장해줍니다.

• 보안 및 규정 준수
• AWS EKS는 AWS의 다양한 보안 및 규정 준수 도구와 통합되어, 애플리케이션의 보안 요구사항을 쉽게 만족시킬 수 있습니다.

프로젝트 생성 및 배포하기

REST API

package com.example.demo;

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

@RestController
public class HelloController {

    @GetMapping("/")
    public String index() {
        return "Hello, World!";
    }

}

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

}

plugins {
    id 'org.springframework.boot' version '2.6.2'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

test {
    useJUnitPlatform()
}

FROM openjdk:11
VOLUME /tmp
COPY build/libs/demo-0.0.1-SNAPSHOT.jar app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        image: <docker-image-url>
        ports:
        - containerPort: 8080

apiVersion: v1
kind: Service
metadata:
  name: demo-service
spec:
  selector:
    app: demo
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'mysql:mysql-connector-java'
    ...
}

spring.datasource.url=jdbc:mysql://${MYSQL_HOST:localhost}:3306/db_example
spring.datasource.username=${MYSQL_USER:example}
spring.datasource.password=${MYSQL_PASSWORD:example}
spring.jpa.hibernate.ddl-auto=update

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class User {

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    private Integer id;

    private String name;

    // getters and setters ...
}

import org.springframework.data.repository.CrudRepository;

public interface UserRepository extends CrudRepository<User, Integer> {
}

import org.springframework.web.bind.annotation.*;

@RestController
public class UserController {

    private final UserRepository repository;

    UserController(UserRepository repository) {
        this.repository = repository;
    }

    @GetMapping("/users")
    Iterable<User> all() {
        return repository.findAll();
    }

    @PostMapping("/users")
    User newUser(@RequestBody User newUser) {
        return repository.save(newUser);
    }

    // Additional CRUD methods ...
}

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.*;

@RestController
public class UserController {

    private static final Logger log = LoggerFactory.getLogger(UserController.class);

    // ...

    @ExceptionHandler
    @ResponseStatus(HttpStatus.NOT_FOUND)
    private void userNotFoundHandler(UserNotFoundException ex) {
        log.error("User not found", ex);
    }
}

AWS CLI 설치 및 배포

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

aws eks update-kubeconfig --region region-code --name cluster-name

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

bashCopy code
kubectl get services

프로젝트 관리

애플리케이션 모니터링 및 로깅

• AWS CloudWatch: AWS 리소스와 애플리케이션을 모니터링하고, 로그를 수집하고, 알람을 설정할 수 있는 서비스입니다.

• Prometheus and Grafana: Kubernetes의 상태를 모니터링하고 시각화하는데 널리 사용되는 오픈소스 도구입니다.

• Fluentd or Fluent Bit: 로그 수집을 위한 오픈소스 도구입니다.

CI/CD 파이프라인 설정

• AWS CodePipeline and AWS CodeBuild: AWS에서 제공하는 CI/CD 서비스로, 소스 코드의 변경을 감지하고, 빌드하고, 테스트하고, 배포하는 과정을 자동화할 수 있습니다.

• Jenkins, CircleCI, GitLab CI/CD 등: 널리 사용되는 오픈소스 또는 상용 CI/CD 도구입니다.

서비스 메쉬 적용

• Istio, Linkerd, AWS App Mesh 등: 서비스 메쉬를 제공하는 오픈소스 또는 상용 솔루션입니다.

보안 고려

• AWS IAM Roles for Service Accounts (IRSA): EKS 클러스터에서 서비스 계정을 사용하여 AWS 리소스에 접근 권한을 제공하는 방법입니다.

• AWS Secrets Manager or Vault: 비밀 키, 암호 등의 민감한 정보를 안전하게 관리하고 사용하는 서비스입니다.

• Container security tools: 컨테이너의 보안을 강화하고, 보안 취약점을 감지하고 관리하는 도구입니다.

배포 전략 설정

1. 롤링 업데이트(Rolling Update): 이 전략은 기존 파드를 새 파드로 순차적으로 교체하는 방식입니다. 이는 쿠버네티스 디플로이먼트의 기본 배포 전략입니다. 롤링 업데이트를 사용하면 서비스 중단 시간 없이 애플리케이션을 업데이트할 수 있지만, 업데이트 중에는 일부 트래픽이 이전 버전과 새 버전의 애플리케이션에 동시에 도달하게 됩니다.
롤링 업데이트 파라미터
• maxUnavailable: 이 파라미터는 업데이트 도중에 사용 불가능한 파드의 최대 비율 또는 수를 정의합니다. 이는 기존 파드가 새 파드로 교체되는 속도를 제어하며, 이 값이 클수록 업데이트가 빨라집니다.
• maxSurge: 이 파라미터는 디플로이먼트에서 허용하는 최대 초과 파드의 비율 또는 수를 정의합니다. 이 값이 클수록 업데이트가 빨라집니다.
예를 들어, maxUnavailable을 10%, maxSurge를 20%로 설정하면, 롤링 업데이트가 시작될 때 먼저 새 파드를 20%만큼 추가로 생성합니다. 그런 다음 이전 파드의 10%를 중단하고, 새 파드로 교체합니다. 이 과정을 계속 반복하여 모든 이전 파드를 새 파드로 교체합니다.
따라서 maxUnavailable과 maxSurge의 값을 조정함으로써, 새로운 파드의 몇 퍼센티지가 배포되면 이전 파드를 중단하도록 설정할 수 있습니다. 이 값들을 조정하여 롤링 업데이트의 속도와 서비스의 가용성을 적절히 조절해야 합니다.

2. 블루/그린 배포(Blue/Green Deployment): 블루/그린 배포는 테스트와 배포를 분리하기 위해 두 개의 동일한 환경을 준비하는 전략입니다. '블루' 환경에서는 현재 운영 중인 버전을 계속 실행하고, '그린' 환경에서는 새 버전을 배포하고 테스트합니다. 테스트가 완료되면, 트래픽을 그린 환경으로 전환(switch)하여 실제로 배포하게 됩니다. 이 전략은 롤링 업데이트와 달리 서비스의 버전이 동시에 혼재하는 상황을 방지할 수 있습니다.

3. 카나리 배포(Canary Deployment): 카나리 배포는 새 버전을 점진적으로 배포하는 전략입니다. 처음에는 일부 트래픽만 새 버전으로 라우팅하고, 새 버전의 안정성을 확인한 후에 나머지 트래픽도 새 버전으로 전환합니다. 이는 새 버전의 문제가 전체 사용자에게 영향을 미치는 것을 방지할 수 있습니다.