윤자이 기술블로그

Pod란? 쿠버네티스는 컨테이너를 개별적으로 배포하는 것이 아니라 Pod라는 단위로 컨테이너를 묶어서 관리하게 됩니다. 하나의 파드는 다수의 컨테이너를 가지고 있을 수 있는데, 왜 개별적으로 하나씩 컨테이너를 배포하지 않고 여러 개의 컨테이너를 Pod단위로 묶어서 배포하게 될까요? 이와 같은 이유에는 두 가지 특징이 있습니다. Pod 내의 컨테이너는 IP와 Port를 공유합니다. 즉 두개 이상의 컨테이너가 하나의 파드를 통해 배포되었을 때 localhost로 통신이 가능합니다. Pod내에 배포된 컨테이너 간에는 디스크 볼륨을 공유할 수 있습니다. 최근 애플리케이션들은 실행할 때 애플리케이션만 올라가는 것이 아니라 로그 수집기와 같은 다양한 솔루션이 함께 배포되는 경우가 많습니다. 특히 로그수집기 같은 경..

핵심 개념 쿠버네티스의 핵심 개념을 한 줄로 표현하자면, 계속해서 원하는 상태를 만들기 위해 현재 상태를 바꾸는 플랫폼입니다. 예를 들어 내가 원하는 컨테이너를 쿠버네티스에 알려주면 (Desired State) 쿠버네티스는 계속해서 Current State(현재상태) 를 체크합니다. 단순히 컨테이너 뿐만 아니라 네임스페이스나 네트워크, 스토리지 같은 부분도 동일하게 동작합니다. 마스터와 노드 쿠버네티스는 가장 먼저 클러스터 구조를 이해할 필요가 있습니다. 클러스터는 여러 대의 컴퓨터가 모여서 같은 목적으로 수행되는 컴퓨터들의 집합이라고 볼 수 있는데, 이때 클러스터 전체를 관리하는 컨트롤러로서 마스터가 존재하고, 컨테이너가 배포되는 물리적인 머신을 노드라고 하게 됩니다. 마스터에는 kube-api-ser..

이전 포스팅에서 docker network를 이용하여 하나의 네트워크 안에 여러 개의 멀티 컨테이너를 배포하는 것을 실습해보았습니다. 그런데 만약 이전 포스팅처럼 2개의 컨테이너를 배포하는 것이 아니라 100개의 컨테이너를 배포해야 되는 상황이라면 어떨까요? 분명 도커를 사용함으로 인해서 많은 부분 배포가 간결해졌지만, 100개의 컨테이너를 손수 배포하는 것은 여전히 부담스럽습니다. 또한 중간에 오타가 나거나 실수를 하는 경우가 발생할 수 있고 다수의 인스턴스에 일관되게 배포하는 것에 어려움이 있을 수 있습니다. 이러한 문제를 해결하는 것이 바로 docker-compose입니다. docker-compose는 docker 프로그램을 정의하고 멀티 컨테이너를 손쉽게 배포할 수 있는 도구입니다. 컨테이너 하나..

토픽, 파티션 카프카가 고성능, 고가용성 메시징 애플리케이션으로 발전하는 데에는 토픽과 파티션이라 불리는 카프카 데이터 모델의 역할이 컸습니다. 토픽은 메시지를 받을 수 있는 논리적인 모델로 데이터를 구분하기 위한 단위입니다. 예를 들어 A라는 사람에게서 받은 메일과 B라는 사람에게서 받은 메일을 구분하기 위해서 이메일 주소를 사용하는 것과 비슷한 논리입니다. 파티션은 토픽을 구성하는 데이터 저장소로서 수평 확장이 가능한 단위입니다. 즉 토픽을 분할해서 파티셔닝 한 형태입니다. 이와 같이 토픽을 파티셔닝 하는 이유는 프로듀서로부터 도착한 메시지의 순서가 보장되어야 하면서 동시에 성능을 향상하기 위해서입니다. 예를 들어 4개의 프로듀서에서 전송되는데 1초가 걸리는 메시지를 하나의 파티션에 전송했다고 가정해..

카프카는 중앙 집중형 빅데이터 스트리밍 플랫폼으로 고성능으로 디자인된 플랫폼입니다. 이와 같이 고성능으로 실시간 메시지를 처리하기 위해 카프카는 내부적으로 몇 가지 특징을 가지고 있습니다. 분산 시스템 그 첫번째로 카프카는 분산 시스템을 기반으로 디자인되었습니다. 분산 시스템이란 네트워크로 이루어진 컴퓨터들의 그룹으로서 시스템 전체가 공통의 역할을 하는 서버 컴퓨터의 집합입니다. 분산 시스템의 경우 단일 시스템보다 더 높은 성능으로 작동할 수 있고, 분산 시스템의 일부 노드가 장애가 발생하더라도 다른 노드가 이를 대신하여 처리할 수 있으므로 장애에 대한 내성을 가지고 있습니다. 또한 추가적으로 서버를 추가하는 것과 같이 시스템 확장에 용이합니다. 예를 들어 초당 1000개의 메시지를 처리하게 되면 CPU..

앞선 포스팅에서 살펴봤듯이 카프카는 크게 메시지를 카프카로 전송하는 프로듀서, 메시지를 저장하고 있는 카프카(브로커), 메시지를 가져가는 컨슈머가 있다고 했습니다. 그리고 마지막으로 카프카와 떨어질 수 없는 코디네이션 애플리케이션인 주키퍼zookeeper가 있습니다. 주키퍼는 중앙에서 분산 application을 관리하는 코디네이션 애플리케이션으로 카프카의 상태 관리는 목적으로 합니다. 카프카는 주키퍼와 긴밀하게 통신을 하기 때문에 카프카를 사용하기 위해서는 주키퍼의 사용이 필수적입니다. 원래 주키퍼는 하둡Hadoop의 서브 프로젝트 중 하나였습니다. 대용량 분산 처리 애플리케이션인 하둡에서는 중앙에서 분산 애플리케이션을 관리하는 코디네이션 애플리케이션이 필요하기 시작했고, 서브 프로젝트로 주키퍼 개발을..

Micro Service Architecture로 아키텍처 패턴이 만들어 짐에 따라서, 각각의 서비스들이 통신하게 되는 구조가 이전보다 복잡해지게 되었습니다. 이와 같이 복잡해진 데이터 전송 구조는 베포와 장애의 어려움을 만들어내게 됩니다. 또한 데이터를 전송할 때 프로토콜의 파편화가 심각해지게 되는 문제가 발생하게 됩니다. Apache Kafka는 이러한 문제를 해결하기 위해 Linked In에서 개발한 오픈소스로 Source Application과 Target Application의 커플링을 약하기 위해 개발 된 것으로 애플리케이션들의 중추 신경과 같은 역할을 하게 됩니다. 아래의 이미지는 카프카가 개발되기 전 링크드인의 데이터 처리 시스템을 나타낸 것입니다. 한눈에 보기에도 복장한 아키텍처 흐름도를..

Spring Batch란? 스프링 배치란 대용량의 데이터를 클라이언트와 소통하지 않고 애플리케이션 단독으로 처리하는 작업에 특화된 프레임워크를 이야기합니다. 스프링 프레임워크를 기반으로 개발되었기 때문에 기존의 DI, AOP, 서비스 추상화 등과 같은 Spring 프레임워크의 특징들을 그대로 사용할 수 있습니다. 또한 배치 애플리케이션은 일반 API 웹 애플리케이션과 달리 API를 통해 통신하지 않고 스스로 일하며, 중간에 실패를 하게 되더라도 실패한 부분부터 다시 실행할 수 있다는 장점이 있습니다. 스프링 배치의 특징은 아래와 같습니다. 대용량 데이터: 배치 애플리케이션은 대량의 데이터를 가져오거나, 전달하거나, 계산하는 등에 최적화되어 고성능을 발휘합니다. 자동화: 심각한 문제 해결을 제외하고는 사용..

자바에서 멀티 스레드를 잘 사용하면 좋은 성능을 내는 프로그램을 개발할 수 있지만, 스레드 간 동기화 문제를 필수적으로 해결해야 합니다. 예를 들어 스레드 간 공유 자원으로 사용하고 있는 데이터가 있을 경우, 여러 개의 스레드가 하나의 데이터에 접근할 경우 신뢰성을 보장할 수 없게 됩니다. 이러한 스레드 동기화 문제는 자바 heap영역에서 발생하게 됩니다. 왜냐하면 자바 스레드는 스레드 안에 스택 영역을 포함하고 있기 때문에 스택 영역의 경우에는 Thread-Safe 하게 되지만 heap영역 같은 경우에는 공유하는 메모리 영역이기 때문에 Thread 간에 safe하지 못하게 됩니다. [OS] Synchronization 동기화란? 1. 동기화란? 동기화란 컴퓨터 공학의 영역 뿐만 아니라 클라우드 저장소와..

Spring MVC는 기본적으로 블럭킹이고 동기방식을 사용합니다. 비동기 처리 기능이 스프링 프레임워크 3에서 추가되어 지원된다고 하지만, 서블릿은 응답을 기다리는 동안 pool의 스레드들은 여전히 지연시킬 수 있기 때문에 전체 stack이 reactive 해야 하는 요구를 충족시킬 수 없습니다. 이러한 요구사항에 맞추어 스프링 프레임워크5에 도입된 대안적인 모듈이 바로 WebFlux로써 웹 요청을 reactive 하게 다루는 데에 초점이 맞추어져 있습니다. 기존의 서블릿 기반의 Spring Boot는 Tomcat을 기반으로 동작합니다. 반면 Spring Boot WebFlux는 여러 가지를 고를 수 있는데 Default롤 Netty를 사용합니다. Netty를 사용하는 이유는 tomcat은 요청 당 하나..