Spring Cloud에서 제공하는 선언적 HTTP 클라이언트
Netflix에서 간단하게 HTTP Client를 사용하기 위해 개발한 기술
RestTemplate, WebClient를 쓸 때보다 훨신 가독성있고 편하게 사용 가능
HTTP 기반의 외부 서비스와 통신하기 위한 REST 클라이언트를 간단하게 생성할 수 있도록 도와주는 라이브러리
* WebClient :
Spring webflux의 라이브러리, non-blocking 방식으로 동작 (대용량 트래픽)
2.FeignClient의 주요 특징
1. 선언적 API 호출:
FeignClient는 HTTP 요청을 메서드 인터페이스로 선언할 수 있어,
HTTP 요청을 직접 만드는 코드나 RestTemplate을 사용하는 것보다
코드가 간결하고 읽기 쉬운 방식으로 API를 호출 가능
2. 자동 retry 및 로드 밸런싱:
Spring Cloud Feign은 Ribbon과 통합되어 자동으로 로드 밸런싱을 제공하며,
Hystrix와 결합해 장애 처리 및 retry 메커니즘을 지원
3. 템플릿 기반 요청:
@FeignClient 인터페이스에서 메서드를 선언하고, 이를 기반으로 HTTP 요청을 템플릿 방식으로 처리
4. 유연한 커스터마이징:
각종 인터셉터나 오류 처리 메커니즘을 쉽게 추가하여 API 호출 로직을 커스터마이징 가능
@EnableFeignClients 또는 configration 파일 지정된 패키지에서 Feign 클라이언트 인터페이스를 스캔하고, 해당 인터페이스에 대한 구현체를 생성
3. FeignClient 구현 (인터페이스 작성) :
구현체는 크게 Feign의 Default, ApacheHttpClient, OkHttpClient
ApacheHttpClient와 OkHttpClient는 추가적인 의존성을 주입해줘야 사용가능
feign.Client.Default는 Feign에서 기본으로 제공, 의존성 주입 없이 사용가능
Default는 내부적으로 java.net의 HttpUrlConnection을 사용, 가볍고 빠르다는 장점
ApacheHttpClient와 OkHttpClient는 Default 구현체보다 설정할 수 있는 값들이 더 많고, 더 편리한 api들을 제공
4. dto, controller 등 작성
3-1. FeignClient 인터페이스 정의
@FeignClient(name = "user-service")
public interface UserServiceClient {
@GetMapping("/users/{id}")
User getUser(@PathVariable("id") Long id);
@PostMapping("/users")
User createUser(@RequestBody User user);
}
3-2. FeignClient 호출
@Service
public class UserService {
@Autowired
private UserServiceClient userServiceClient;
public User getUser(Long id) {
return userServiceClient.getUser(id);
}
public User createUser(User user) {
return userServiceClient.createUser(user);
}
}
4. 추가 기능 (errorrecoder, decoder , interceptor, retry)
4-1.RequestInterceptor
Feign 요청을 가로채서 수정하거나, 공통 헤더 , 로깅을 추가하는 등의 작업을 할 수 있습니다.
RequestInterceptor를 사용하여 요청을 인터셉트할 수 있습니다.
* RequestIntercepor : @interface, @Override apply
@Bean
public RequestInterceptor requestInterceptor() {
return new RequestInterceptor() {
@Override
public void apply(RequestTemplate template) {
// 헤더에 인증 토큰 추가
template.header("Authorization", "Bearer " + token);
}
};
}
@FeignClient(name = "user-service", configuration = FeignConfig.class)
public interface UserServiceClient {
@GetMapping("/users/{id}")
User getUser(@PathVariable("id") Long id);
}
4-2. ErrorDecoder
Feign 클라이언트를 통해 요청을 보냈을 때 HTTP 응답 코드가 실패한 경우에 처리할 로직을 정의하는 데 사용
spring cloud openfeign은 ErrorDecoder를 통해 응답값이 200이 아닐 경우 에러
400, 404, 500 등의 오류가 발생하면 FeignException을 던지고, 이는 기본적으로 5xx 예외로 처리
public class MyErrorDecoder implements ErrorDecoder {
@Override
public Exception decode(String methodKey, Response response) {
if (response.status() == 404) {
return new NotFoundException("Resource not found");
} else if (response.status() == 500) {
return new InternalServerErrorException("Internal server error");
}
return FeignException.errorStatus(methodKey, response);
}
}
@FeignClient(name = "user-service", configuration = MyErrorDecoder.class)
public interface UserServiceClient {
@GetMapping("/users/{id}")
User getUser(@PathVariable("id") Long id);
}
4-3. Decoder
Feign 클라이언트가 서버에서 받은 응답을 객체로 변환하는 역할
기본적으로 JSON을 Java 객체로 변환하기 위해 Jackson을 사용하지만,
다른 포맷(예: XML, YAML 등)을 처리하려면 Decoder를 구현하여 변환 로직을 커스터마이즈
public class MyCustomDecoder implements Decoder {
private final JacksonDecoder jacksonDecoder = new JacksonDecoder();
@Override
public Object decode(Response response, Type type) throws IOException {
// 커스텀 디코딩 로직
if (type.equals(MyCustomType.class)) {
return customDecodeLogic(response);
}
return jacksonDecoder.decode(response, type); // 기본 Jackson 디코더 사용
}
}
@Configuration
public class FeignConfig {
@Bean
public Decoder decoder() {
return new MyCustomDecoder();
}
}
@FeignClient(name = "user-service", configuration = FeignConfig.class)
public interface UserServiceClient {
@GetMapping("/users/{id}")
User getUser(@PathVariable("id") Long id);
}
4-4. Retryer
Feign 클라이언트가 요청을 보냈을 때
일시적인 오류(예: 네트워크 오류 등)가 발생하면 자동으로 재시도할 수 있게 해줌,
재시도할 횟수와 대기 시간 등을 설정
public class MyRetryer implements Retryer {
private int attempt = 1;
private static final int MAX_ATTEMPTS = 3;
@Override
public void continueOrPropagate(RetryableException e) {
if (attempt++ > MAX_ATTEMPTS) {
throw e;
}
try {
Thread.sleep(1000); // 재시도 간 대기 시간
} catch (InterruptedException ex) {
Thread.currentThread().interrupt();
}
}
@Override
public Retryer clone() {
return new MyRetryer();
}
}
@Configuration
public class FeignConfig {
@Bean
public Retryer retryer() {
return new MyRetryer();
}
}
@FeignClient(name = "user-service", configuration = FeignConfig.class)
public interface UserServiceClient {
@GetMapping("/users/{id}")
User getUser(@PathVariable("id") Long id);
}
불변 객체(Immutable Object) : 한 번 생성되면 내부 상태(필드 값)를 변경할 수 없는 객체
즉, 객체가 생성된 이후에는 해당 객체의 상태를 변경하는 어떤 메서드나 동작도 존재하지 않음
대표적인 불변 객체의 예:
•String 클래스
•Integer, Long, Double 등 기본형 래퍼 클래스
불변 객체의 장점
1. 내부 상태 변경 불가
객체가 생성된 이후에는 그 값이 변경되지 않음
모든 필드는 final로 선언되어야 하며, 생성자에서만 초기화 가능
2. 가비지 컬렉션의 성능을 높일 수 있음
불변객체를 이용하면 GC의 스캔빈도와 범위가 줄게되어 GC의 성능에 도움이 됨
3. equals와 hashCode의 안정성 보장
객체의 상태가 변하지 않기 때문에, 해시 기반 컬렉션(HashMap, HashSet 등)에서 안전하게 사용가능
4. 스레드 안전성(Thread-Safety)
불변 객체는 항상 동일한 값을 보장하므로 동기화를 신경쓸 필요가 없음
병렬 프로그래밍에 유용함
* 멀티 스레드 환경에서는 공유 자원에 대해 서로 변경하면 값이 덮어씌워지는 문제가 발생
불변 객체를 선호하고 중요하게 여기는 이유
1. 스레드 안전성
불변 객체는 여러 스레드에서 동시에 사용되더라도 상태가 변경되지 않으므로
동기화 코드 없이 안전하게 사용할 수 있다
ex. String 클래스는 스레드 간 안전하게 공유 가능
2. 안정성과 신뢰성
객체의 상태가 변하지 않으므로 한 번 설정된 값은 변하지 않는다
디버깅과 유지보수가 용이
3. 캡슐화 강화
불변 객체는 내부 상태가 외부에 노출되지 않도록 설계되기 때문에 캡슐화 원칙을 강화
불변성을 유지하기 위해 외부에서 내부 필드에 접근할 수 없도록 방지
4. 캐싱과 재사용 가능
불변 객체는 상태가 변하지 않으므로 동일한 상태를 가진 객체를 캐싱하여 재사용 가능
ex. Integer 클래스의 valueOf 메서드는 -128부터 127 사이의 값을 캐싱하여 성능을 최적화
5. 컬렉션에서 안정적 동작
불변 객체는 HashMap, HashSet 등의 컬렉션에서 안정적으로 동작
해시 기반 컬렉션에서는 객체의 상태가 변경되면 해시 충돌이 발생할 수 있는데, 불변 객체는 이런 문제를 방지
불변 객체의 단점
1. 초기화 시 성능 비용
불변 객체를 새로 생성하려면 기존 객체를 복사하여 새로운 객체를 생성해야 하므로 메모리와 CPU 비용이 증가할 수 있음
다만, 작은 크기의 객체나 캐싱 기법을 통해 이러한 비용을 줄일 수 있음
2. 메모리 사용량 증가
상태가 변할 때마다 새로운 객체를 생성하므로, 가변 객체보다 더 많은 메모리를 소비할 수 있음
* 주로 대량의 데이터를 처리할 때 문제
불변 객체 설계 방법
1. 모든 필드를 final로 선언:
private final String name;
private final int age;
2. 클래스를 final로 선언 (상속 방지):
public final class Person {
// 필드 및 생성자
}
3. 생성자를 통해 필드를 초기화:
public Person(String name, int age) {
this.name = name;
this.age = age;
}
4. 필드에 대한 getter는 원시값이나 불변 객체만 반환:
public String getName() {
return name;
}
5. 참조 타입 필드는 복사본을 반환:
private final List<String> hobbies;
public Person(String name, int age, List<String> hobbies) {
this.name = name;
this.age = age;
this.hobbies = new ArrayList<>(hobbies); // 방어적 복사
}
public List<String> getHobbies() {
return Collections.unmodifiableList(hobbies); // 불변 리스트 반환
}
불변 객체의 활용 예시 1. 불변 객체 클래스
public final class Person {
private final String name;
private final int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public int getAge() {
return age;
}
@Override
public String toString() {
return "Person{name='" + name + "', age=" + age + '}';
}
}
2. 사용 예
public class Main {
public static void main(String[] args) {
Person person = new Person("Alice", 25);
System.out.println(person); // 출력: Person{name='Alice', age=25}
// 상태 변경 불가
// person.setName("Bob"); // 컴파일 에러 발생
}
}
불변(immutable) 객체를 쉽게 생성할 수 있도록 하는 유형의 클래스
- 필드가 자동으로 final로 선언되어 불변 객체를 생성 (필드 캡슐화)
- class가 final로 선언, final 클래스(상속불가)
- 클래스의 필드 선언, 생성자, getter, equals, hashCode, toString이 모두 자동으로 생성
- 컴파일 타임에 컴파일러가 코드를 추가
- getter를 사용할 때, getFieldName()이 아니라 fieldName()을 사용
- Record 클래스가 제공해주는 메소드들은 재정의가 가능
1. 생성자는 모든 field를 포함
2. toString()도 모든 field를 포함
3. equals(), hashCode() 메서드는 invokedynamic based mechanism을 사용
4. getter는 field이름과 유사한 이름으로 생성 ex) id(), email()..
5. 기본적으로 java.lang.Record class를 상속받기 때문에 다른 class를 상속받을 수 없음
6. class가 final이기 때문에 다른 subclass를 생성할 수 없음
7. 모든 field는 불변이기 때문에 setter는 제공하지 않음
8. DTO(data transfer object)나 domain model class에 사용
Q. 레코드(record)를 JPA의 Entity 클래스로 사용할 수 없을까요?
레코드는 바이트코드로 본 것처럼 final 클래스(상속불가)이고, abstract로 선언할 수 없습니다.
따라서 레코드를 Entity 클래스에 사용할 수 없는데요, 그 이유는 JPA의 지연로딩에 있습니다.
지연 로딩 방식을 사용할 때, JPA는 엔티티 객체의 프록시 객체를 생성합니다.
프록시 객체는 원본 객체를 상속하여 생성된 확장 클래스입니다.
하지만 레코드는 상속이 불가능하므로 엔티티로 사용할 수 없습니다.
멀티모듈의 설계 / 구조는 계층 기반으로 구성
하나의 프로젝트를 여러 개의 모듈로 나누어 관리
최상위 프로젝트(root)와 여러 개의 하위 모듈(module)로 구성
project-root/
├── module-api/
│ ├── controller/
│ ├── dto/
│ ├── resources/
│ └── build.gradle
├── module-service/
│ ├── service/
│ ├── utils/
│ └── build.gradle
├── module-domain/
│ ├── entity/
│ ├── repository/
│ └── build.gradle
├── module-core/
│ ├── conf/
│ ├── utils/
│ └── build.gradle
└── build.gradle (루트 설정)
project-root: 전체 프로젝트를 대표하는 루트 프로젝트로, 공통적인 빌드 설정을 관리
module-*: 각 모듈은 서로 다른 기능을 담당
module-api: 컨트롤러 및 외부와의 통신을 처리
module-service: 비즈니스 로직과 서비스 계층을 관리
module-domain: 데이터 모델 및 데이터 접근 계층을 관리
module-core: 공통 모듈로, 여러 모듈에서 재사용 가능한 유틸리티 및 설정 포함
멀티모듈의 주요 특징
1. 모듈화로 인해 코드 분리가 명확함
각 모듈은 특정한 책임만을 가지며 서로 독립적
결합도를 낮추고 응집도를 높이는 설계가 가능
2. 재사용성
공통적인 로직이나 유틸리티를 module-core 같은 공통 모듈에 작성하여, 다른 모듈에서 재사용 가능
3. 빌드 및 배포 효율성
변경 사항이 있는 모듈만 빌드하여 배포할 수 있어 빌드 시간을 단축
Gradle이나 Maven을 사용하면 하위 모듈의 의존성과 빌드 순서를 관리 가능
4. 팀 협업 효율성
각 팀이 서로 다른 모듈을 개발하도록 나누어 작업 가능
충돌을 최소화하고 생산성 증가
멀티모듈 프로젝트의 장점
유지보수성: 각 모듈이 독립적이므로 변경 사항의 영향 범위가 작음
확장성: 새로운 기능을 추가할 때, 기존 모듈에 영향을 주지 않고 새로운 모듈로 추가 가능
재사용성: 특정 모듈을 여러 프로젝트에서 재사용 가능
의존성 관리: 각 모듈이 개별적으로 의존성을 관리하므로 필요하지 않은 의존성을 배제할 수 있음
경험한 어려움 및 해결 방안
경험한 어려움 및 해결 방안
1: 의존성 관리의 어려움
module-service에서도 @Transactional을 사용하려면 spring-boot-starter-data-jpa가 필요
해결 : JPA 의존성을 추가
2. 멀티모듈 간 의존성 순환 문제
module-core는 최대한 독립적으로 설계하고 PoJo 기반 순수 자바 클래스로 구성
단방향 의존성을 유지하여 의존성 순환 방지
3. 멀티모듈에서 공통 설정 (Config 파일) 관리
공통 모듈의 역할을 명확하게 정리 → module-core가 비대해지지 않도록 주의
*. Config 위치
api 로 가는 경우
- WebMvcConfig: API 요청/응답 설정 (예: 메시지 컨버터, CORS 등)
- SwaggerConfig: Swagger 문서화 설정
- SecurityConfig: API 인증/인가 관련 설정 (Spring Security, OAuth)
- RestTemplateConfig: 외부 API 호출을 위한 RestTemplate 설정
core 로 가는 경우
- LoggingConfig: 로깅 설정
- GlobalExceptionHandler: 전역 예외 처리
- CommonConstants: 프로젝트 전반에서 사용하는 상수들
- EncryptionConfig: 암호화 관련 공통 설정
그 외
- feign : service 또는 (특정 API 모듈에서만 사용된다면) api
- Redis : 캐싱 또는 비즈니스 로직과 관련(service), 또는 core
- JPA Config (Audit 등) : domain
멀티 모듈 적용
1. 모듈단위로 잘게 쪼개서 사용하고 싶어서 사용 (재활용)
2. api / consumer(kafka) / batch > service > domain > common
- 엔트리포인트(=접근하는 컨트롤러) 부터 시작
- core(=common)에는 어떤 엔트리포인트에도 문제없는(=특정기술에 종속 X) 순수한 포조객체 , Utils 메소드
- domain에는 POJO(plain old Java Object), pojo + entity = jpa entity
- 항상 단방향 ex. service 모듈 에서 common implement
멀티 모듈 회고
1. Api 모듈
- api 모듈은 프로젝트의 엔트리 포인트
- 외부로부터의 요청을 처리하는 컨트롤러와 데이터 전달을 위한 객체인 DTO(Data Transfer Object) 포함
- 그 외 AOP, 공통 설정, 예외 처리 등을 포함
- 최상위 계층으로 외부와의 직접적인 인터페이스 역할을 하며, 모든 하위 모듈을 참조할 수 있는 구조로 설계
- API의 단순히 요청을 라우팅하고 데이터를 가공하는 역할에 집중해야 한다고 생각
- 그 외 추가적으로 배치, 컨슈머와 같은 다른 엔트리 포인트와도 구조적으로 통일성을 유지
2. Service
- 핵심 비즈니스 로직을 처리하고 데이터의 흐름을 제어하는 중간 계층
- Domain 모듈과 협력하여 데이터 조작 및 검증을 처리하며, API 모듈로부터 요청을 전달받아 로직을 수행
- 단방향 의존성을 유지하면서 Core 및 Domain 모듈만 참조
- VO(Value Object) 비즈니스 로직과 관련된 값 객체를 포함
3. Domain 모듈
- 프로젝트의 핵심 데이터를 정의하고, 데이터 접근 계층을 처리하는 중요한 역할
- POJO 기반의 엔티티와 JPA를 활용한 레포지토리 계층으로 구성
- 특정 비즈니스 로직이 없는 순수한 데이터 계층으로 유지
- module-core만 참조하도록 설계하여, 특정 비즈니스 로직이 없는 순수한 데이터 계층으로 유지
- 다른 모듈에서 도메인 객체를 재사용할 수 있도록 돕고, 데이터 계층과 비즈니스 로직 간의 결합도를 낮춤
- JPA 엔티티와 레포지토리를 포함하여 특정 기술 스택(JPA)에 종속적일 수 있음
4. Core 모듈
- 공통적으로 사용되는 유틸리티와 설정을 모아둔 가장 하위 계층
- 특정 기술 스택에 종속되지 않고,
배치 작업이나 다른 엔트리 포인트에서도 독립적으로 활용될 수 있도록 POJO 기반의 순수한 자바 클래스로 구성
- 모든 모듈에서 재사용 가능한 코드를 포함하며, JPA와 같은 기술 의존성을 철저히 배제
- 기술 변경이나 새로운 기능 추가 시에도 유연하게 대응할 수 있도록 설계
- ex. 공통 예외 처리나 유틸 메서드처럼 어디서나 필요한 기능
5. Config 위치
api 로 가는 경우
- WebMvcConfig: API 요청/응답 설정 (예: 메시지 컨버터, CORS 등)
- SwaggerConfig: Swagger 문서화 설정
- SecurityConfig: API 인증/인가 관련 설정 (Spring Security, OAuth)
- RestTemplateConfig: 외부 API 호출을 위한 RestTemplate 설정
core 로 가는 경우
- LoggingConfig: 로깅 설정
- GlobalExceptionHandler: 전역 예외 처리
- CommonConstants: 프로젝트 전반에서 사용하는 상수들
- EncryptionConfig: 암호화 관련 공통 설정
5. 그 외
feign : service 또는 (특정 API 모듈에서만 사용된다면) api
Redis : 캐싱 또는 비즈니스 로직과 관련(service), 또는 core
JPA Config (Audit 등) : domain
자바(Java)와 같은 프로그래밍 언어에서 코드의 재사용성과 타입 안전성을 높이기 위해 사용하는 템플릿
데이터 형식에 의존하지 않고, 하나의 값이 여러 다른 데이터 타입들을 가질 수 있도록 한다
컴파일 시점에 데이터 타입을 명확히 지정할 수 있어, 코드의 유연성과 안전성을 동시에 확보
제네릭의 주요 특징
1.타입 안정성(Type Safety)
•제네릭을 사용하면 컴파일 시점에 타입이 결정되므로, 잘못된 타입 사용으로 인한 오류를 방지
•예: List<String>은 문자열만 저장 가능하며, 컴파일 시점에 다른 타입을 넣으려 하면 에러가 발생
2.코드 재사용성
•제네릭을 사용하면 다양한 데이터 타입에 대해 하나의 코드로 처리 가능
•예: List<T>는 문자열, 숫자, 사용자 정의 객체 등 어떤 타입이든 처리
3.형변환(Downcasting) 제거
•제네릭을 사용하면 형변환(casting)이 필요 없어 코드가 간결하고 안전
•예: List<String>에서 값을 꺼낼 때는 문자열(String)로 자동 처리
제네릭의 사용법
1. 클래스에서 제네릭 사용
// 제네릭 클래스를 정의
public class Box<T> {
private T value;
public void setValue(T value) {
this.value = value;
}
public T getValue() {
return value;
}
}
// 사용하는 예제
Box<String> stringBox = new Box<>();
stringBox.setValue("Hello");
System.out.println(stringBox.getValue()); // 출력: Hello
Box<Integer> intBox = new Box<>();
intBox.setValue(123);
System.out.println(intBox.getValue()); // 출력: 123
2. 메서드에서 제네릭 사용
// 제네릭 메서드
public static <T> void printArray(T[] array) {
for (T element : array) {
System.out.println(element);
}
}
// 사용하는 예제
String[] stringArray = { "A", "B", "C" };
printArray(stringArray);
Integer[] intArray = { 1, 2, 3 };
printArray(intArray);
3. 제네릭 인터페이스
// 제네릭 인터페이스 정의
public interface Repository<T> {
void save(T entity);
T findById(int id);
}
// 구현 클래스
public class UserRepository implements Repository<User> {
@Override
public void save(User user) {
System.out.println("Saving user: " + user.getName());
}
@Override
public User findById(int id) {
return new User(id, "Sample User");
}
}
가상화 환경 또는 가상 머신 (Virtual Machine, VM)은 실제 하드웨어 시스템을 에뮬레이션하거나 복제한 소프트웨어 구현체입니다. 이는 다른 운영 체제 (OS)를 호스트 시스템에서 독립적으로 실행할 수 있게 해주며, 하나의 물리적 기계에서 여러 가상 시스템을 구동하는 것이 가능하게 합니다. 가상화 기술은 다양한 용도로 사용될 수 있습니다:
개발 및 테스트: 개발자들은 가상 머신을 사용하여 다양한 OS와 환경에서 소프트웨어를 테스트하고 디버깅할 수 있습니다. 이는 개발 단계에서 버그를 찾고 수정하는 데 도움이 됩니다.
서버 통합: 가상화를 통해 하나의 물리적 서버에서 여러 가상 서버를 운영함으로써 하드웨어 사용을 최적화하고 운영 비용을 절감할 수 있습니다.
레거시 시스템 실행: 일부 애플리케이션은 특정 OS나 환경에서만 작동합니다. 가상화를 통해 이러한 레거시 애플리케이션을 최신 시스템에서 실행할 수 있습니다.
보안 및 안전성 : 가상화는 시스템 간의 격리를 제공하므로, 하나의 시스템에서 문제가 발생하더라도 다른 시스템에 영향을 미치지 않습니다. 이는 보안 및 안정성을 향상시키는 데 도움이 됩니다.
: 개발을 하게 될때 어플리케이션을 만들고 배포 과정을 도와주는 플랫폼으로 쿠버네티스를 많이 사용하고 있기 때문에
쿠버네티스란 애플리케이션을 개발하고 배포하는 과정을 크게 단순화해주는 플랫폼이다.
미들웨어에서의 컨테이너 개념은 일반적으로 컨테이너 기반의 가상화 기술을 의미합니다. 컨테이너는 소프트웨어를 실행하는데 필요한 모든 요소(코드, 런타임, 시스템 도구, 시스템 라이브러리 등)를 패키지화하여 일관된 환경에서 소프트웨어를 실행하는 기술입니다.
미들웨어에서 컨테이너 기술을 이용하면, 애플리케이션과 그에 필요한 미들웨어 컴포넌트들(웹 서버, 메시지 큐, 데이터베이스 등)을 독립적으로 패키지화하고, 배포하며, 실행하고, 관리할 수 있습니다. 이는 개발, 테스트, 배포의 과정을 간소화하고, 환경에 따른 문제를 최소화하는 등의 이점을 제공합니다.
쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션을 배포, 확장 및 관리하기 위한 오픈소스 플랫폼으로, 그 자체로는 PaaS(Platform as a Service)를 완전히 제공하지는 않습니다. 쿠버네티스는 보다 기본적인 수준에서 동작하는 시스템으로, 기본적인 빌딩 블록(컨테이너, 서비스, 볼륨 등)을 제공하고, 이를 통해 사용자가 원하는 플랫폼을 구축할 수 있게 해줍니다.
그러나 쿠버네티스 위에 추가적인 추상화 계층을 제공하는 오픈소스 프로젝트나 상용 제품들이 있으며, 이러한 솔루션들을 사용함으로써 쿠버네티스를 기반으로 하는 PaaS를 구축할 수 있습니다. 예를 들어, OpenShift, Rancher, Google Cloud Run 등이 이에 해당합니다.
결국, 쿠버네티스는컨테이너오케스트레이션을위한필수적인기능을제공하며, 이를기반으로사용자나기업이자신들의요구사항에맞는 PaaS를구축하는데사용될수있습니다. 이는쿠버네티스가제공하는유연성과확장성때문에가능한것입니다.
Docker는 컨테이너화 된 애플리케이션을 생성하고 관리하기 위한 오픈 소스 플랫폼입니다. Docker는 컨테이너라는 개념을 대중화했으며, 컨테이너를 사용하여 소프트웨어 의존성 문제를 해결했습니다.
컨테이너는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 애플리케이션 실행에 필요한 모든 것을 포함하므로, 개발자는 코드가 예상대로 실행될 것임을 확신할 수 있습니다. Docker 컨테이너는 거의 모든 곳에서 실행될 수 있으므로, 소프트웨어 배포는 물론, 배포, 테스트, 그리고 디버그 과정도 단순화되었습니다.
Kubernetes (또는 줄여서 k8s 또는 kube)는 컨테이너화 된 애플리케이션을 자동으로 배포, 확장, 관리할 수 있는 오픈 소스 플랫폼입니다. Kubernetes는 컨테이너 오케스트레이션 시스템으로, 대규모의 컨테이너화 된 애플리케이션을 관리하고 운영하는데 필요한 도구를 제공합니다.
Kubernetes는 서비스 검색, 로드 밸런싱, 자동 복구, 스케일링, 롤링 업데이트, 시크릿과 구성 관리 등을 지원합니다. 이를 통해 사용자는 복잡한 머신 클러스터 위에서 애플리케이션을 보다 효율적으로 운영할 수 있습니다.
자동 복구(Auto Healing): 쿠버네티스는 시스템에 장애가 발생하면 애플리케이션을 자동으로 복구하는 기능을 제공합니다. 예를 들어, 컨테이너가 실패하면, 노드가 다운되면, 또는 애플리케이션 자체가 사용자 정의 상태 체크를 통과하지 못하면 쿠버네티스는 문제가 된 컨테이너를 재시작하여 애플리케이션을 복구할 수 있습니다.
스케일링과 로드 밸런싱(Scaling and Load Balancing): 쿠버네티스는 애플리케이션의 트래픽 요구사항에 따라 동적으로 스케일링할 수 있습니다. 또한, 부하 분산을 위한 서비스를 제공하여 애플리케이션의 트래픽을 여러 인스턴스로 분산시키는 기능도 제공합니다.
코드 배포 및 롤백(Deployment and Rollback): 쿠버네티스를 사용하면 새로운 버전의 애플리케이션을 빠르고 안정적으로 배포할 수 있으며, 문제가 발생하면 이전 버전으로 쉽게 롤백할 수 있습니다.
개발및운영효율성(Dev and Ops Efficiency): 쿠버네티스는애플리케이션을개발하고운영하는과정에서의효율성을크게향상시킵니다. 개발팀은애플리케이션코드에집중할수있으며, 운영팀은배포, 모니터링, 로깅등의운영작업을효과적으로수행할수있습니다.
컨테이너: 더 작고 더 빠르게 애플리케이션을 실행할 수 있게 해주는 소프트웨어 표준화 단위입니다. 이는 애플리케이션의 코드, 설정 및 종속성을 하나로 모아 각 환경에서 동일하게 실행할 수 있게 해줍니다. 컨테이너는 리눅스 커널 기술인 namespaces와 cgroups를 활용해 격리된 실행 환경을 제공합니다.
쿠버네티스: 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화해주는 오픈 소스 플랫폼입니다. 여러 머신에 걸쳐 컨테이너가 동작하도록 분산 시스템을 구축하고 관리하는 것을 돕습니다.
웹 서버와 컨테이너: 웹 서버는 일반적으로 운영 체제 위에 설치되며, 웹 브라우저와 같은 클라이언트의 HTTP 요청에 응답합니다. 반면, 컨테이너는 필요한 소프트웨어 및 라이브러리를 포함하여 웹 서버와 같은 애플리케이션을 격리된 환경에서 실행합니다. 이를 통해 개발 환경과 운영 환경 사이의 일관성을 보장하며, 배포 및 확장을 용이하게 합니다.
AWS와 EKS: AWS는 클라우드 컴퓨팅 서비스를 제공하는 플랫폼이며, 가상 머신을 구동하는 서비스인 EC2 등을 포함합니다. 반면, AWS EKS는 Amazon Elastic Kubernetes Service의 약자로, AWS에서 제공하는 완전 관리형 쿠버네티스 서비스입니다. EKS는 쿠버네티스를 사용하여 컨테이너화된 애플리케이션을 실행하고 관리할 수 있도록 해줍니다. EKS는 AWS의 EC2 인스턴스를 사용하여 쿠버네티스 클러스터를 구성할 수도 있습니다.
따라서 "쿠버네티스"는컨테이너를관리하고운영하는플랫폼으로, 컨테이너화된웹서버와같은애플리케이션을확장및배포하는데도움이됩니다
