개발블로그, 숲

Apache Airflow 기초

sanook — Sun, 16 Feb 2025 22:38:11 +0900

Apache Airflow

Apache Airflow는 워크플로우를 자동화하고 관리하기 위한 오픈 소스 플랫폼입니다.

DAG(Directed Acyclic Graph)를 기반으로 작업(Task)을 정의하고 실행하며, 다양한 Operator를 활용해 여러 유형의 작업을 수행할 수 있습니다.

DAG (Directed Acyclic Graph)

DAG는 작업의 실행 순서를 정의하는 그래프로, 각 작업(Task)의 종속성을 표현합니다.

Airflow에서는 DAG를 통해 복잡한 워크플로우를 쉽게 정의할 수 있습니다.

주요 특징

작업 간의 실행 순서를 정의합니다.
반복 실행이 가능하며 스케줄링을 지원합니다.
DAG 내 모든 Task는 서로 연결되어야 합니다.

DAG 실행 (DAG Run)

DAG 실행(DAG Run)은 특정 시간에 DAG를 실행하는 개별적인 인스턴스를 의미합니다.

DAG는 설정된 schedule_interval에 따라 자동으로 실행 자동 실행되거나 사용자가 직접 UI나 CLI를 통해 수동으로 실행할 수 있습니다.

또한, API 등을 통해 외부에서 DAG 실행을 트리거할 수 있습니다.

상태

DAG 실행 상태는 state 속성을 통해 확인할 수 있으며, 주요 상태는 다음과 같습니다

running: DAG 실행이 진행 중인 상태
success: DAG 실행이 성공적으로 완료됨
failed: DAG 실행이 실패함
queued: DAG 실행이 대기열에 있음
skipped: DAG 실행이 건너뛰어짐
up_for_retry: DAG 실행이 재시도 상태임

DAG 실행 상태를 모니터링하려면 Airflow UI의 DAG Runs 탭을 활용하거나, CLI 명령어를 사용할 수 있습니다.

과거 데이터 처리

Backfill

Backfill은 특정 기간 동안 실행되지 않은 DAG Run을 수동으로 실행하는 기능입니다. CLI에서 다음과 같이 실행할 수 있습니다:

# 2024-01-01부터 2024-01-10까지 실행되지 않은 DAG를 채움
airflow dags backfill -s 2024-01-01 -e 2024-01-10 example_dag

위 명령어는 2024-01-01부터 2024-01-10까지의 실행되지 않은 DAG Run을 실행합니다.

Catchup

Catchup은 DAG의 catchup=True 설정을 통해 자동으로 실행되지 않은 과거 DAG 실행을 보충하는 기능입니다.

from airflow import DAG
from datetime import datetime

dag = DAG(
    dag_id='example_dag',
    schedule_interval='@daily',
    start_date=datetime(2024, 1, 1),
    catchup=True  # 과거 실행을 자동으로 채움
)

catchup=False로 설정하면 최신 실행만 수행되며, 과거 실행이 무시됩니다.

dag = DAG(
    dag_id='example_dag',
    schedule_interval='@daily',
    start_date=datetime(2024, 1, 1),
    catchup=False  # 과거 실행을 무시하고 최신 실행만 수행
)

Trigger Rule

Task는 기본적으로 all_success 조건에서 실행되지만, trigger_rule을 사용하면 실행 조건을 변경할 수 있습니다.

all_success: 모든 부모 Task가 성공해야 실행됨 (기본값)
all_failed: 모든 부모 Task가 실패해야 실행됨
all_done: 부모 Task의 상태와 관계없이 실행됨
one_failed: 하나 이상의 부모 Task가 실패하면 실행됨
one_success: 하나 이상의 부모 Task가 성공하면 실행됨
none_failed: 부모 Task 중 하나라도 실패하지 않으면 실행됨
none_skipped: 부모 Task 중 하나라도 건너뛰어지지 않으면 실행됨

from airflow.operators.python import PythonOperator

def task_function():
    print("실행 중")

def task_final():
    print("Trigger Rule 조건 충족")

start = PythonOperator(task_id='start', python_callable=task_function)

task_1 = PythonOperator(task_id='task_1', python_callable=task_function)
task_2 = PythonOperator(task_id='task_2', python_callable=task_function)

task_3 = PythonOperator(task_id='task_3', python_callable=task_final, trigger_rule='one_success')

start >> [task_1, task_2] >> task_3

위 코드에서 task_3는 task_1 또는 task_2 중 하나라도 성공하면 실행됩니다.

Task (작업)

Task는 DAG 내에서 실행되는 개별 작업 단위입니다. Airflow에서는 다양한 Operator를 사용해 Task를 정의할 수 있습니다.

주요 특징

DAG 내에서 하나의 작업을 의미합니다.
Operator를 사용하여 실행할 작업을 정의합니다.
다른 Task와 종속 관계를 설정할 수 있습니다.
@task 데코레이터를 사용하여 간결하게 Task를 정의할 수 있습니다.

@task 데코레이터 사용

Airflow 2.0부터는 @task 데코레이터를 사용하여 Python 함수를 간단하게 Task로 정의할 수 있습니다.

from airflow.decorators import task

@task
def print_message():
    print("Airflow Task 실행 중")

message_task = print_message()

Operator (연산자)

Operator는 특정 유형의 작업을 실행하는 기본 구성 요소입니다.

주요 Operator

PythonOperator

PythonOperator는 Python 함수를 실행하는 연산자로, Python 코드 실행이 필요할 때 사용됩니다.

from airflow.operators.python import PythonOperator

def print_hello():
    print("Hello, Airflow!")

python_task = PythonOperator(
    task_id='print_hello_task',
    python_callable=print_hello,
)

PythonOperator는 python_callable 매개변수를 사용해 실행할 함수를 지정합니다.

이 함수는 파라미터를 받을 수도 있으며, 실행 결과를 다른 Task에서 활용할 수도 있습니다.

BashOperator

Bash 명령어를 실행할 때 사용하는 연산자입니다.

from airflow.operators.bash import BashOperator

bash_task = BashOperator(
    task_id='print_date',
    bash_command='date'
)

Jinja 템플릿과 템플릿 기능

Airflow에서는 Jinja 템플릿을 사용하여 동적으로 값을 삽입할 수 있습니다. 이를 통해 실행 시간, 변수, XCom 데이터를 활용할 수 있습니다.

주요 기능

실행 시간({{ ds }}) 등의 기본 변수 사용 가능
사용자 정의 매크로 및 필터 사용 가능
XCom을 활용하여 Task 간 데이터 공유 가능

from airflow.operators.bash import BashOperator

bash_task = BashOperator(
    task_id='templated_bash',
    bash_command='echo "오늘 날짜는 {{ ds }} 입니다."'
)

위 코드에서 {{ ds }}는 실행 날짜를 의미하며, 실제 실행될 때 해당 날짜로 대체됩니다.

PythonOperator와 Jinja 템플릿

PythonOperator에서도 templates_dict를 활용하여 Jinja 템플릿을 사용할 수 있습니다.

from airflow.operators.python import PythonOperator

def print_date(**kwargs):
    execution_date = kwargs['templates_dict']['execution_date']
    print(f"실행 날짜: {execution_date}")

python_task = PythonOperator(
    task_id='templated_python',
    python_callable=print_date,
    templates_dict={'execution_date': '{{ ds }}'}
)

위 코드에서는 {{ ds }} 값이 execution_date에 전달되며, 실행 시 해당 날짜로 치환됩니다.

Task 분기 처리 방법

Airflow에서는 특정 조건에 따라 실행할 Task를 동적으로 결정하는 기능을 제공합니다.

대표적으로 BranchPythonOperator와 @task.branch 데코레이터를 사용할 수 있습니다.

1. BranchPythonOperator 활용

BranchPythonOperator는 특정 조건을 평가하고, 조건에 따라 실행할 Task를 결정하는 연산자입니다.

from airflow.operators.python import BranchPythonOperator, PythonOperator

def choose_branch():
    return 'task_a' if some_condition else 'task_b'

branch_task = BranchPythonOperator(
    task_id='branch_task',
    python_callable=choose_branch
)

task_a = PythonOperator(task_id='task_a', python_callable=lambda: print("Task A 실행"))
task_b = PythonOperator(task_id='task_b', python_callable=lambda: print("Task B 실행"))

branch_task >> [task_a, task_b]

위 코드에서 choose_branch() 함수가 실행된 후, task_a 또는 task_b 중 하나만 실행됩니다.

2. @task.branch 데코레이터 활용

Airflow 2.0부터는 @task.branch 데코레이터를 사용하여 더욱 간결하게 Task 분기를 처리할 수 있습니다.

from airflow.decorators import task

@task.branch
def choose_branch():
    return 'task_a' if some_condition else 'task_b'

@task
def task_a():
    print("Task A 실행")

@task
def task_b():
    print("Task B 실행")

branch_task = choose_branch()
task_a = task_a()
task_b = task_b()

branch_task >> [task_a, task_b]

위 방식은 BranchPythonOperator와 동일한 기능을 수행하지만, @task.branch 데코레이터를 사용해 더욱 깔끔하게 분기 처리를 할 수 있습니다.

XCom (Cross-Communication)

XCom은 Task 간 데이터를 공유하는 기능을 제공합니다.

XCom을 활용하면 한 Task에서 데이터를 저장하고, 다른 Task에서 해당 데이터를 가져와 사용할 수 있습니다.

XCom 데이터 저장 및 가져오기

방법 1: ti 객체 활용

아래 코드는 TaskInstance (ti) 객체를 이용하여 데이터를 저장(XCom push)하고, 다른 Task에서 해당 데이터를 가져오는(XCom pull) 방법을 보여줍니다.

from airflow.operators.python import PythonOperator

def push_data(**kwargs):
    ti = kwargs['ti']  # TaskInstance 객체 가져오기
    ti.xcom_push(key='message', value='Hello, XCom!')

def pull_data(**kwargs):
    ti = kwargs['ti']
    message = ti.xcom_pull(task_ids='push_task', key='message')
    print(f"Received message: {message}")

push_task = PythonOperator(
    task_id='push_task',
    python_callable=push_data,
    provide_context=True
)

pull_task = PythonOperator(
    task_id='pull_task',
    python_callable=pull_data,
    provide_context=True
)

push_task >> pull_task

push_data 함수는 ti.xcom_push(key, value)를 사용하여 데이터를 저장하고

pull_data 함수는 ti.xcom_pull(task_ids, key)를 사용하여 데이터를 가져옵니다.

두 Task는 push_task >> pull_task로 연결되어, 먼저 push_task가 실행된 후 pull_task에서 데이터를 가져오도록 설정됩니다.

방법 2: 함수의 return 값 활용

Airflow 2.0부터는 @task 데코레이터를 사용하여 간결한 방식으로 XCom을 활용할 수 있습니다. 아래 코드는 Task 간 데이터를 전달하는 또 다른 방법을 보여줍니다.

from airflow.decorators import task

@task
def push_data():
    return "Hello, XCom!"

@task
def pull_data(message):
    print(f"Received message: {message}")

push_task = push_data()
pull_task = pull_data(push_task)

push_data 함수의 return 값이 자동으로 XCom에 저장되고 pull_data 함수는 push_data에서 반환된 값을 인자로 받아 데이터를 출력하여 push_task >> pull_task의 흐름으로 실행됩니다.

이 방식은 코드가 더욱 간결해지며, 별도로 xcom_push() 및 xcom_pull()을 호출할 필요 없이 데이터를 주고받을 수 있다는 장점이 있습니다.

출저 : https://airflow.apache.org/docs/apache-airflow/stable/index.html

Kubernetes 기초: 서비스

sanook — Sun, 19 Jan 2025 22:03:06 +0900

Kubernetes(K8s)는 애플리케이션의 여러 구성 요소를 파드(Pod) 형태로 모델링하여 관리합니다.

파드는 하나 이상의 컨테이너를 포함하며, K8s는 이를 클러스터 내에서 동적으로 배치하고 관리합니다.

하지만 파드는 재배포될 때마다 IP 주소가 변경되므로, K8s는 이를 해결하기 위해 서비스(Service) 리소스를 제공합니다.

서비스(Service)란?

서비스는 파드 간 통신을 안정적으로 제공하기 위한 K8s의 핵심 리소스입니다.

클러스터 내부와 외부 간의 트래픽을 원활하게 처리할 수 있도록 다음과 같은 주요 기능을 수행합니다.

주요 기능

어드레스 디스커버리(Address Discovery)
Kubernetes의 서비스는 파드의 IP가 변경될 때마다 이를 자동으로 추적하고, 클러스터 내 DNS를 통해 서비스 이름을 IP 주소로 매핑합니다. 애플리케이션은 서비스 이름을 사용하여 파드의 현재 IP 주소를 자동으로 찾을 수 있어, 파드가 재배포되더라도 중단 없이 안정적으로 통신할 수 있습니다.
트래픽 라우팅 및 레이블 셀렉터
Kubernetes 서비스는 클러스터 내부와 외부에서 발생하는 트래픽을 적절한 파드로 연결하여 애플리케이션이 원활히 실행될 수 있도록 합니다. 이때, 레이블 셀렉터를 사용하여 특정 파드를 선택하고 해당 파드로 트래픽을 유도합니다.
또한, 로드 밸런싱 방식을 적용해 트래픽을 여러 파드에 고르게 분산하며, 파드의 IP가 변경될 경우 자동으로 반영됩니다.
이를 위해 kube-proxy는 각 노드에서 실행되며, 네트워크 규칙을 설정해 요청을 적절한 파드로 전달하는 역할을 수행합니다.
가상 주소 제공
- ClusterIP: 클러스터 내에서만 접근 가능한 고정 IP 주소 제공합니다.
- DNS 이름: Kubernetes는 서비스 생성 시 내부 DNS 시스템에 해당 서비스의 고유 도메인 이름을 등록합니다. 예를 들어, frontend-service.default.svc.cluster.local과 같은 도메인 네임을 제공하여, 클러스터 내부에서 일관된 방식으로 서비스에 접근할 수 있도록 합니다.
엔드포인트 관리:
Kubernetes API 서버를 통해 대상 파드의 네트워크 정보를 자동으로 업데이트하며, 이를 동적으로 관리합니다. 이는 kubectl get endpoints 명령어를 사용하여 확인 가능합니다.

서비스를 사용하면 IP 주소가 변하는 파드를 안정적으로 연결할 수 있으며, 클러스터 외부에서 클러스터 내부의 애플리케이션에 접근할 수 있도록 네트워크 인터페이스를 제공합니다.

서비스 유형

Kubernetes에서는 다양한 유형의 서비스를 제공하며, 각 유형은 특정 네트워크 요구 사항을 충족합니다.

ClusterIP (기본값):
- 클러스터 내부에서만 사용할 수 있는 고정 IP를 제공하며, 파드의 위치와 관계없이 동일한 주소로 접근할 수 있습니다. 외부 접근이 필요 없는 내부 컴포넌트에 적합하며, 기본 서비스 유형으로 내부 네트워크에서만 접근을 허용합니다. 기본적으로 kubernetes.default.svc라는 서비스가 자동으로 생성되며, 이를 통해 클러스터 내부에서 API 서버에 접근할 수 있습니다.
- 사용 사례: 내부 데이터베이스 서비스, 클러스터 내 마이크로서비스 간 통신.
- 예시 YAML:
```
apiVersion: v1
kind: Service
metadata:
  name: internal-service
spec:
  selector:
    app: my-internal-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: ClusterIP
```

NodePort:

클러스터 외부에서 노드의 특정 포트를 통해 서비스에 접근할 수 있습니다.
사용 사례: 개발 및 테스트 환경에서 간단한 외부 접근 제공.
예시 YAML:

apiVersion: v1
kind: Service
metadata:
  name: nodeport-service
spec:
  selector:
    app: my-nodeport-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
      nodePort: 30080
  type: NodePort

LoadBalancer:
- 클라우드 제공자의 로드 밸런서를 통해 외부 트래픽을 분산 처리합니다.
- 사용 사례: 사용자 트래픽을 여러 파드에 분산하여 고가용성을 제공.
- 예시 YAML:
```
apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-service
spec:
  selector:
    app: my-loadbalancer-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: LoadBalancer
```
ExternalName:
- 외부 DNS 이름을 내부 서비스에서 사용할 수 있도록 매핑합니다.
- 사용 사례: 클러스터 내부 애플리케이션이 외부 데이터베이스 또는 API 서비스에 접근할 때.
- 예시 YAML:
```
apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  type: ExternalName
  externalName: example.com
```

Kubernetes 네트워크 프록시

서비스 리소스가 클러스터 내에서 안정적인 통신을 보장하려면, 트래픽을 적절한 파드로 전달하고, 파드의 동적인 IP 변경을 관리할 필요가 있습니다. 네트워크 프록시는 이러한 요구 사항을 해결하기 위해 사용됩니다.

클러스터 내부에서 동적으로 변경되는 파드의 IP 주소를 숨기고, 일관된 네트워크 연결을 제공하여 애플리케이션의 안정성을 높입니다.

또한, 클러스터 외부에서 내부로의 안전한 트래픽 전달을 보장하며, 로드 밸런싱과 서비스 검색 기능을 제공합니다.

역할과 동작 방식

네트워크 프록시는 kube-proxy라는 구성 요소를 통해 구현되어 클러스터 내 모든 노드에서 실행되며, 최신 서비스 엔드포인트 정보를 유지합니다.

클라이언트가 서비스의 고정된 클러스터 IP로 요청을 보내면, 프록시는 해당 요청을 받아 적절한 파드로 전달합니다.

파드가 삭제되거나 재배포될 경우 프록시는 Kubernetes API 서버로부터 새로운 엔드포인트 정보를 받아 최신 상태로 유지하며, 이를 통해 클러스터 내에서 지속적으로 유효한 네트워크 연결을 보장합니다.
또한 동일한 서비스를 제공하는 여러 파드가 있을 때, 프록시는 트래픽을 균등하게 분산시켜 리소스를 효율적으로 사용하고 애플리케이션의 부하를 최소화합니다.
iptables 및 IPVS와 같은 기술을 활용하여 패킷을 필터링하고 라우팅하는 기능을 수행합니다.

Kubernetes 기초: 파드, 디플로이먼트, 컨트롤러 객체

sanook — Sun, 5 Jan 2025 20:59:29 +0900

파드(Pod)

Kubernetes(K8s)가 하나 이상의 컨테이너를 효과적으로 관리하고 애플리케이션을 더 잘 분리하고 배포하기 위해 사용하는 가장 작은 배포 단위로, 컴퓨팅의 단위 역할을 합니다.

이는 애플리케이션의 실행 환경을 제공하며, 클러스터를 이루는 노드 중 하나에서 실행됩니다.

노드 간 이동이나 복구 작업 시에도 Kubernetes가 이를 자동으로 관리합니다.

주요 특징

자체 복구(Self-Healing) 애플리케이션 관리 기능과 원하는 상태(desired state) 관리

Kubernetes는 파드의 상태를 지속적으로 모니터링하며, 문제가 발생하거나 파드가 실패할 경우 비정상적으로 종료된 파드를 재시작하거나, 정의된 개수만큼 파드를 유지하기 위해 새로운 파드를 생성하는 등 자동으로 복구하거나 대체합니다.

사용자가 정의한 원하는 상태(desired state)에 따라 파드와 관련 리소스를 관리합니다.

예를 들어, 파드의 개수, 리소스 요구사항, 네트워크 설정 등이 원하는 상태와 일치하도록 Kubernetes가 지속적으로 조정합니다.

이를 통해 관리자는 복잡한 환경에서도 애플리케이션의 일관성을 유지할 수 있습니다.

가상 네트워크와의 통합

파드는 자신만의 가상 IP 주소를 가지고 있으며, 이를 통해 가상 네트워크에 접속됩니다.

Kubernetes는 서비스를 통해 파드 간 통신을 지원하며, 서비스는 고정된 가상 IP를 제공하여 클러스터 내에서 동적으로 변경되는 파드와 안정적으로 통신할 수 있게 합니다.

이 주소를 사용하면 다른 파드, 심지어는 다른 노드에서 실행 중인 파드와도 원활하게 통신할 수 있습니다.

컨테이너 그룹

하나의 파드는 N개의 컨테이너를 포함할 수 있습니다.

단일 컨테이너 파드의 경우 단순한 마이크로서비스를 배포할 때 사용되고 멀티 컨테이너 파드의 경우 서로 협력해야 하는 여러 컨테이너를 하나의 파드에 포함시키기 위해 사용됩니다.

파드 내 컨테이너는 같은 네트워크 네임스페이스를 공유하기 때문에, localhost를 통해 서로 통신할 수 있습니다.

이와 함께, 같은 스토리지 볼륨을 공유함으로써 데이터의 일관성을 유지할 수 있습니다.

Kubernetes에서의 파드 추상화

Kubernetes에서 파드는 컨테이너를 직접 관리하지 않고, 이를 추상화하여 관리합니다.

Kubernetes가 컨테이너 생성 및 실행을 클러스터의 각 노드에 설치된 컨테이너 런타임(예: Docker, containerd 등)에 맡기는 방식으로 이루어집니다.

클러스터 관리자가 컨테이너의 세부적인 동작 방식보다는 파드 단위에서 애플리케이션의 전체 상태를 정의하고 유지할 수 있게 함으로써 Kubernetes의 유연성과 확장성을 뒷받침합니다.

예시

파드를 생성하는 예시 YAML 파일은 다음과 같습니다.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  labels:
    app: frontend
spec:
  containers:
  - name: nginx
    image: nginx:1.21.6
    ports:
    - containerPort: 80

아래 명령어를 사용하여 배포합니다.

kubectl apply -f example-pod.yaml

컨트롤러 객체

Kubernetes에서 다른 리소스를 관리하고 제어하는 핵심 리소스입니다. Kubernetes API와 연동하여 시스템의 현재 상태를 지속적으로 감시하며, 바람직한 상태(desired state)와의 차이가 발견되면 이를 자동으로 바로잡습니다.

주요 특징

현재 상태 감시와 조정

컨트롤러 객체는 시스템의 현재 상태를 Kubernetes API를 통해 주기적으로 조회합니다.

사용자가 정의한 바람직한 상태(desired state)와 현재 상태가 일치하지 않을 경우, 필요한 작업을 수행하여 일치를 보장합니다.

생애 주기 관리

컨트롤러 객체는 자신이 관리하는 리소스의 생성, 수정, 삭제 등 생애 주기를 완전히 관장합니다.

외부에서 관리 리소스에 간섭하거나 임의로 삭제하려는 시도를 방지하며, 만약 관리 리소스가 삭제될 경우 이를 자동으로 대체합니다.

관리 리소스 삭제 시의 동작

컨트롤러 객체가 관리하는 리소스를 삭제하려면 반드시 해당 컨트롤러 객체를 삭제해야 합니다.

그렇지 않으면 컨트롤러는 즉시 새로운 리소스를 생성하여 삭제된 리소스를 대체합니다.

레이블과 레이블 셀렉터를 통한 자신이 관리해야 할 리소스 식별

컨트롤러는 레이블을 통해 자신이 관리해야 할 리소스를 식별합니다.

레이블은 모든 Kubernetes 리소스에 적용 가능한 key-value 쌍으로, 리소스의 속성을 정의하거나 그룹화할 때 사용됩니다.

레이블 셀렉터는 특정 레이블을 기준으로 리소스를 선택하는 규칙으로, 컨트롤러가 관리 대상을 동적으로 결정할 수 있도록 도와줍니다.

레이블과 레이블 셀렉터를 활용하면 동적인 환경에서도 항상 최신 상태를 유지할 수 있습니다.

Kubernetes API를 호출해 주기적으로 필요한 리소스를 조회하며, 정의된 상태와 일치하지 않을 경우 이를 조정하는 방식으로 동작합니다.

디플로이먼트(Deployment)

Kubernetes(K8s)에서 파드와 관련된 리소스를 선언적으로 관리하는 컨트롤러 객체입니다.

이는 애플리케이션의 배포, 확장, 업데이트, 복구 작업을 자동화하여 사용자가 정의한 상태(desired state)를 유지합니다.

주요 특징

파드의 생성 및 관리

디플로이먼트는 필요에 따라 파드를 생성, 삭제, 대체합니다.

노드에 문제가 있어 파드가 유실되었을 경우, 대체 파드를 다른 노드에서 실행하여 애플리케이션의 가용성을 보장합니다.

그리고 여러 노드에 걸쳐 균등하게 파드를 배포하여 리소스 활용을 극대화하고 롤링 업데이트를 지원하여, 애플리케이션의 가용성을 유지하면서 새로운 버전으로 전환합니다.

선언적 구성

사용자는 디플로이먼트를 정의할 때 필요한 파드와 관련 설정(이미지, 환경 변수, 볼륨 등)을 명시합니다.

디플로이먼트는 Kubernetes API를 통해 현재 클러스터 상태를 주기적으로 조회하며, 정의된 상태와 비교하여 필요한 작업을 수행합니다.

예시

app: frontend라는 레이블을 가진 파드를 관리 대상으로 지정하고, Nginx 컨테이너 3개의 복제본을 생성하는 디플로이먼트를 정의합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
  labels:
    app: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6
        ports:
        - containerPort: 80

이 YAML 파일은 다음 명령어를 사용하여 Kubernetes 클러스터에 배포할 수 있습니다:

kubectl apply -f example-deployment.yaml

참고 :

https://kubernetes.io/ko/docs/concepts/workloads/pods/

엘튼 스톤맨 저/심효섭 역, 쿠버네티스 교과서: 기초부터 운영까지, 실전에 강한 쿠버네티스 사용법!, 길벗

글또 10기 다짐글

sanook — Sun, 13 Oct 2024 22:30:49 +0900

3년 동안 4번의 글또를 마치며 블로그와 노션, 그리고 옵시디언을 통해 글을 정리하고 작성할 수 있었다.

매번 글또에 참여할 때마다 조금씩 더 나아지고 꾸준히 글을 작성하게 되었고, 이제는 그 과정이 습관처럼 자리 잡았다.

만약 내가 글또에 참여하지 않았더라면, 이 글들은 작성되지 않았을 것이고, 나의 생각과 학습 내용을 기록으로 남기지도 못했을 것이다.

또한 다양한 분들의 글을 읽으며 생각의 폭을 넓힐 수 있었고 좋은 분들을 많이 만날 수 있어 감사했다.

그래서 이번 기수에도 주저 없이 참여하게 되었다.

글또가 나에게 얼마나 큰 동기부여가 되었는지 알기에, 내가 배운 것들을 이번 기수에도 계속 정리하고자 한다.

어떤 글감으로 진행할지

쿠버네티스 이해하기

몇 개월 전, "쿠버네티스 교과서"라는 책을 완독하기 위한 스터디에 참여했다.

하지만 회사 업무와 개인적인 일정이 겹치면서 끝까지 책을 완독하지 못했고, 그로 인해 아쉬움이 많이 남았다.

현재 혼자서 다시 처음부터 읽어 나가는 중인데 책과 공식 문서를 읽으면서 내가 이해한 대로 정리하여 글을 다시 작성하며 깊이 있게 이해해 보고자 한다.

운영체제 다시 공부하기

이전 스터디에서 함께 했던 멤버들과 다음 스터디 주제를 고민하던 중, 최신 기술을 배우는 것도 중요하지만 가장 기본적인 지식을 탄탄하게 갖추는 것이 중요하다는 결론에 도달했다. 기본적인 지식이 없으면, 새로운 기술을 배우더라도 전체적인 이해가 부족하게 된다. 이 점에서 나는 운영체제에 대한 지식을 다시 한번 깊이 있게 공부하고 싶다. 학교를 졸업하고 난 뒤로 항상 책장에 꽂혀만 있던 운영체제 책을 꺼내어, 하나하나 다시 이해하고 정리해 보고자 한다. 운영체제는 시스템 개발이나 성능 최적화와 같은 분야에서 필수적인 지식이고 컴퓨터의 기본적인 동작 원리부터 고급 개념까지 깊이 있게 이해하는 것이 앞으로 도움이 될 것으로 생각한다. 이번 기회에 이 책을 다시 공부하며, 컴퓨터의 기본적인 동작 원리를 깊이 이해할 수 있기를 바래본다.

어떻게 실행할 수 있을까

2주에 한 번 글을 써내자고 의지를 다잡는 것 보다 매일의 습관을 만들어 시스템화 해나가는 것이 훨씬 실행할 가능성이 높아짐을 지난 3년간 느꼈다.

방의 조명을 바꾸고 좋아하는 음료를 준비하고 즐겨듣는 음악을 들으며 하루에 한 시간씩 꾸준히 글을 옵시디언에 정리할 예정이다.

이 글을 기반으로 주말에 다시 다듬어 블로그에 작성하고자 한다.

그리고 글을 두 번 잘 작성하면 나에게 조그마한 선물을 주며 꾸준히 독려해주고자 한다.

글을 마치며

원하는 목표에 다다르기 위해 무리하게 운동하다 다쳐 병원을 오가는 요즘, 다시 한번 잘하는 것보다 나를 잘 돌보며 꾸준하게 하는 것의 중요성을 느끼고 있다.

이번 글또도 완벽하게 하는 것보다는 패스를 사용하더라도 6개월간 완주하는 것을 목표로 하여 완주해 보고자한다.

Udemy :【한글자막】 Java 멀티스레딩, 병행성 및 성능 최적화 - 전문가 되기 수강 후기

sanook — Sun, 14 Apr 2024 12:29:29 +0900

【한글자막】 Java 멀티스레딩, 병행성 및 성능 최적화 - 전문가 되기 강의는 Java 멀티스레딩에 대한 체계적이고 포괄적인 이해를 제공하는데, 이를 바탕으로 실제 실무에서 개발시 많은 도움을 얻을 수 있었습니다.

강의는 초보자부터 중급자까지 폭넓게 다루고 있어, 멀티스레딩의 핵심 개념부터 고급 기술까지 이해하기 쉽게 설명하고 있습니다.

강의의 첫 부분에서는 Java의 스레드 모델 및 멀티스레딩의 기본 개념을 다룹니다. 이 부분은 멀티스레딩에 대한 기초를 이해하는 데 큰 도움이 되었습니다. 또한, 스레드의 생성과 제어, 동기화 메커니즘에 대한 설명도 명확하게 제공되어 병행성에 대한 이해를 높일 수 있었습니다.

강의의 중간 부분에서는 멀티스레딩을 활용하여 병렬성을 증가시키고 성능을 최적화하는 방법에 대해 심층적으로 다루고 있습니다. 스레드 풀, 병렬 컬렉션, 그리고 고급 동기화 기법 등을 배우면서 실제 애플리케이션에서의 멀티스레딩 활용에 대한 통찰력을 얻을 수 있었습니다.

특히, 강의는 실전 프로젝트를 통해 이론을 실제로 적용하는 방법을 보여주는데, 이는 학습 경험을 더욱 풍부하게 만들어주었습니다. 강의에서 제공하는 다양한 예제와 실습을 통해 멀티스레딩을 활용한 프로그래밍 기술을 실제로 경험할 수 있었습니다.

이 강의를 통해 멀티스레딩에 대한 이해가 깊어지고, 앞으로의 개발 과정에서 병행성을 고려한 코드를 작성하는 데 도움이 될 것으로 기대됩니다. 저는 학습 경험을 토대로, Java 멀티스레드 프로그래밍에서 올바르고 효율적인 설계를 구현하는 방법에 대해 더욱 자신감을 갖게 되었습니다. 이를 통해 애플리케이션을 개발하는 데 있어서 성능과 반응성을 극대화할 수 있는 방법을 배웠습니다.

또한, 이 강의를 통해 얻은 지식을 실제 프로젝트에 적용하여 Java 애플리케이션의 멀티스레딩을 효과적으로 구현할 수 있을 것으로 기대됩니다. 이를 통해 애플리케이션의 성능을 향상시키고, 사용자 경험을 개선수 있을 것입니다.

자바를 이용하여 개발하면서 멀티스레딩과 병행성 그리고 성능 최적화에 대해 고민하고 있는 동료들이 있다면 이 강의를 먼저 들어보라고 추천할 것 같습니다.

해당 글은 https://www.udemy.com/course/java-multi-threading 를 보고 정리한 글로 해당 콘텐츠는 유데미로부터 강의 쿠폰을 제공받아 작성되었습니다.

카프카의 내부 동작 원리와 구현

sanook — Sun, 17 Mar 2024 15:33:25 +0900

카프카 리플리케이션

카프카는 많은 데이터 파이프라인의 정중아에 위치하는 메인 허브 역할로 정상 동작 하지 않을시 심각한 문제

→ 안정성 확보를 위해 카프카 내부에서 리플리케이션 동작

리플리케이션 동작 개요

replication factor

카프카의 리플리케이션 동작을 위해 토픽 생성시 필수값

리더와 팔로워

리더

리플리케이션 중 하나가 선정되어 모든 읽기 쓰기는 리더를 통해서만 가능
프로듀서는 리더에게만 메시지 전송 / 컨슈머도 오직 리더로 부터 메시지 가져옴

팔로워

리더에 문제가 발생하거나 이슈가 있을 경우를 대비해 언제든지 새로운 리더가 될 준비
컨슈머가 토픽의 메시지를 꺼내 가는 것과 비슷하게 파티션의 리더가 새로운 메시지를 받았는지 확인하고, 새로운 메시지가 있다면 이를 리더로부터 복제

복제 유지와 커밋

ISR(InSyncReplica)

리더와 팔로워가 묶여있는 논리적 그룹

팔로워가 네트워크 오류, 브로커 장애 등 으로 리더로부터 리플리케이션 하지 못하는 경우 발생

→ 뒤처진 팔로워는 리더와 데이터 정합성/ 메시지 손실 문제로 리더를 넘겨 줄 수 없음

→ 잘 따라 잡는 팔로워들만 ISR에 속하고 리더 장애시 새로운 리더의 자격

⇒ 이를 판단하는 주체? 리더

리더 가 읽고 쓰는 동작은 물론, 팔로워가 리플리케이션 동작을 잘 수행하는지 판단
팔로워가 특정 주기 만큼 복제 요청을 하지 않으면 리더가 팔로워의 리플리케이션 문제가 있다고 판단해 ISR 그룹에서 추방
하이워터마크
- 마지막 커밋 오프셋 위치
- ISR내 모든 팔로워의 복제 완료시 리더는 내부적으로 커밋 표시
- 커밋 == 리플리케이션 팩터의 모든 리플리케이션이 모두 메시지를 저장했음
- 커밋된 메시지만 컨슈머가 읽어 감으로써 메시지의 일관성 유지 가능
- 커밋된 메시지 유지를 위해 로컬 디스크의 replication-offset-checkpoint 파일에 마지막 커밋 오프셋 유지

리더와 팔로워의 단계별 리플리케이션 동작

리더와 팔로워 간의 리플리케이션 동작 처리시 서로 통신 최소화하도록 설계됨

fetch : 팔로워들이 리더에게 오프셋 메시지 가져오기 요청
리더는 팔로워들이 요청을 보낸 사실은 알고 있지만 오프셋에 대한 리플리케이션 동작 성공/실패 여부는 모름
- ↔ 래빗MQ : 모든 미러(팔로워)가 메시지를 받았느지에 대한 ACK를 리더에게 리턴함으로 리더는 미러들이 메시지를 받았는지 여부 앎
- 카프카는 ACK 통신 없어서 리플리케이션의 성능 높힘
리더는 n번째 오프셋 위치에 세로운 메시지를 프로듀서로 받은 후 저장하고 팔로워는 n-1번 오프셋에 대한 리플리케이션 동작을 마친 후 n 번째 오프셋에 대한 리플리케이션 요청
이에 대한 요청을 받은 리더는 n-1 오프셋에 대한 리플리케이션 동작이 성공했음을 인지하고, 오프셋 n-1에 대한 커밋 표시 후 하이워터마크를 증가 및 이에 대한 내용을 팔로워에게 응답
팔로워들이 Pull 하는 방식 이여서 빠르고 신뢰 가능하며 리더의 부하를 줄임

리더에포크

카프카의 파티션들이 복구 동작시 메시지의 일관성 유지

리플리케이션 프로토콜에 의해 전파, 새로운 리더 변경시 리더에 대한 정보는 팔로워에게 전파

복구시 하이워터마크 대체하는 역할

컨트롤러

리더 선출

ISR 리스트는 주키퍼에 저장

graceful 종료의 경우 다운타임 최소화 가능

로그(세그먼트)

카프카의 토픽으로 들어오는 메시지는 세그먼트라는 파일에 정해진 형식으로 저장

세그먼트 삭제와 컴팩션으로 로그 크기 관리

삭제

retention.ms 옵션

컴팩션

활성화된 세그먼트 제외

메시지값 기준으로 마지막 데이터만 보관

키 벨류 형식

예제 : _consumer_offset 토픽

ㄴ 컨슈머 그룹이 어디까지 읽었는지 나타내는 오프셋 커밋 정보

카프카로 메시지 전송시 키 값은 필수 아니지만 컴팩션 사용시에는 필수

빠른 장애 복구

컴팩션시 브로커에 과도한 입출력 발생 주의

출저 : 고승범 저, 실전 카프카 개발부터 운영까지, 책만, 4장. 카프카의 내부 동작 원리와 구현

카프카 기본 개념과 구조

sanook — Sun, 3 Mar 2024 22:24:31 +0900

카프카 기초 다지기

주요 요소

주피커

카프카의 메타데이터 관리 및 브로커 health check

브로커

카프카가 설치된 서버 / 노드

프로듀서

카프카로 메세지 보내는 클라이언트

컨슈머

카프카에서 메시지를 꺼내가는 클라이언트

토픽

카프카는 메시지 피드들을 토픽으로 구분, 토픽 이름은 카프카 내 고유

파티션

병렬 처리 및 고성능을 위해 여러 토픽을 여러 개로 나눈 것

세그먼트

프로듀서가 전송한 실제 메시지가 브로커의 로컬 디스크에 저장

메시지 / 레코드

프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조각

리플리케이션

메시지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에 분산하는 동작

→ 하나의 브로커가 종료되어도 카프카 안정성 유지

옵션

—replication-factor {숫자}

카프카 내 {숫자} 개의 리플리케이션 유지
토픽의 파티션이 리플리케이션 되는 것
수가 커지면 안정성은 높아지지만 브로커 리소스를 많이 사용하게 됨
- 테스트 / 개발 : 1
- 운영(로그성으로 유실 허용) : 2
- 운영(유실 허용 X) : 3

파티션

하나의 토픽이 한 번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러 개로 나눠 병렬 처리가 가능하도록 만든 것
파티션 수 만큼 컨슈머 연결 가능
0부터 시작
초기 생성 후 언제든지 늘릴 수 있지만 늘린 수에서 줄일 수는 없음
초기에 토픽 생성시 2 / 4개 정도로 생성후 메시지 처리량 / 컨슈머의 LAG(프로듀서가 보낸 메세지 수 - 컨슈머가 가져간 수) 를 모니터링 하며 조금씩 늘려가기

세그먼트

프로듀서에 의해 브로커로 전송된 메시지는 토픽의 파티션에 저장되며, 각 메시지들은 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장

(각 파티션마다 N개의 세그먼트 로그 파일 존재)

카프카의 핵심 개념

분산 시스템

네트워크상에서 연결된 컴퓨터들의 그룹
단일 시스템이 갖지 못한 높은 성능 목표
장애 대응 (하나 서버/노드 장애시 다른 서버/노드가 처리)
최초 구성한 클러스터의 리소스가 한계치에 도달해 높은 메시지 처리량이 필요한 경우, 브로커를 추가하는 방식으로 확장 가능

페이지 캐시

직접 디스크에 읽고 쓰는 대신 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리 활용
카프카가 디스크에서 읽고 쓰지 않고 페이지 캐시를 통해 읽고 쓰기를 함

배치 전송 처리

카프카는 프로듀서, 컨슈머 클라이언트와 서로 통신하며 수많은 메시지를 주고 받는데 이를 묶어 처리하면 단건 통신시 네트워크 오버헤드를 줄일 수 있음 + 장기적으로 더욱 빠르고 효율적
로그를 저장소로 보내는 것과 같은 작업은 이미 로그가 서버에 기록되어 있으므로 실시간 처리 보다는 배치 처리 이용이 효율적

압축 전송

성능이 높은 압축 전송을 사용하는 것을 권장
- 높은 압축률 : gzip, zstd
- 빠른 응답 속도 : snappy, lz4, zstd
압축만으로 네트워크 대역폭 / 회선 비용 줄이기 가능

토픽, 파티션, 오프셋

토픽

메일 전송 시스템에서 이메일 주소 정도의 개념
파티셔닝을 통해 단 하나의 토픽이라도 높은 처리량 수행

오프셋

파티션의 메시지가 저장되는 위치
순차적으로 증가하는 숫자(64비트 정수) 형태
각 파티션에서 오프셋은 고유한 숫자로, 카프카에서는 오프셋을 통해 메시지의 순서를 보장, 컨슈머에서는 마지막으로 읽은 위치를 알 수 있음

고가용성 보장

분산 시스템을 위한 토픽의 파티션을 복제하는 리플리케이션 기능을 통해 장애 발생한 서버 역할을 대신해 안정적인 서비스 가능
원본(리더), 리플리케이션(팔로워)
팔로워 수 만큼 브로커의 디스크 공간도 소비됨으로 이상적인 리플리케이션의 팩터 수 유지 필요
리더는 프로듀서, 컨슈머로부터 오는 모든 읽기와 쓰기 요청을 처리하며, 팔로워는 오직 리더로 부터 리플리케이션

주키퍼의 의존성

여러 대의 서버를 앙상블(클러스터)로 구성하고, 살아 있는 노드 수가 과반수 유지된다면 지속적인 서비스가 가능한 구조 → 주피커는 반드시 홀수
지노드를 이용해 카프카의 메타 정보가 주키퍼에 기록, 주키퍼는 지노드를 활용해 브로커의 노드 관리, 토픽 관리, 컨트롤러 관리 등 역할

프로듀서의 기본 동작과 예제 맛보기

프로듀서 디자인

ProducerRecord

카프카로 전송하기 위한 실제 데이터
필수 : 토픽, 벨류(메세지 내용)
옵션 : 특정 파티션을 지정하기 위한 레코드의 파티션, 특정 파티션에 레코드들을 정렬하기 위한 레코드의 키

파티셔너

파티션 지정 O : 아무 동작 하지 않고 지정된 파티션으로 레코드 전달
파티션 지정 X
- 키를 가지고 파티션을 선택해 레코드 전달(default : 라운드 로빈)

동작

프로듀서가 카프카 전송 전 배치 전송을 위해 레코드들을 파티션별로 잠시 모아둠
전송 실패시 재시도, 지정된 횟수만큼 재시도 실패시 최종 실패
전송 성공시 메타데이터 리턴

프로듀서의 주요 옵션

참고 : https://multifrontgarden.tistory.com/297

프로듀서 예제

전송 방법

메시지를 보내고 확인하지 않기
- 실제 운영에서 사용 X
동기 전송
- 전송 성공시 응답된 메타데이터를 통해 파티션과 오프셋 정보 확인
비동기 전송
- send() 메서드와 콜백을 함께 호출하여 빠른 전송, 메세지 실패시 콜백을 통해 예외 처리 가능

컨슈머의 기본 동작과 예제 맛보기

컨슈머의 기본 동작

컨슈머 그룹

하나 이상의 컨슈머가 모여 있는 그룹으로 반드시 속함
컨슈머 그룹은 각 파티션의 리더에게 카프카 토픽에 저장된 메시지를 가져오기 위한 요청 보냄
- 파티션 수와 컨슈머 수는 1:1 매핑이 이상적
- 파티션 수보다 컨슈머 수가 많게 구현하면 안됨
  - 빠른 성능이 아닌 많은 수의 컨슈머들이 그냥 대기
  - 컨슈머 그룹 내 리밸런싱 동작을 통해 장애 발생시 동일 그룹에 있는 다른 컨슈머가 그 역할 대신함으로 장애 대비 컨슈머는 필요 없음

출저 : 고승범 저, 실전 카프카 개발부터 운영까지, 책만, 3장 카프카 기본 개념과 구조

카프카 운영과 모니터링

sanook — Sun, 18 Feb 2024 21:39:10 +0900

안정적인 운영을 위한 주키퍼와 카프카 구성

주키퍼 구성

최근에는 주키퍼의 의존성을 제거하려 하는 움직임

주키퍼는 파티션과 브로커의 메타데이터를 저장, 컨트롤러 서버를 선출하는 동작 수행

주키퍼 서버 수량

쿼럼(과반수) 구성 기반 동작임으로 반드시 홀수
과반수를 충족할 수 있는 수까지만 장애 허용 (3대면 1대만 장애 허용)
일반적 3, 핵심 중앙 데이터 파이프라인이면 5

하드웨어

메모리 4~8GB, 디스크는 240/480G SSD
- 과도한 물리 메모리는 낭비
- 트랜잭션이나 스냅샷 로그는 로컬 디스크에 저장함으로 Write 성능 좋은 SSD 추천
네트워크 1G 이더넷

배치

각기 다른 랙에 분산 배치, 전원 / 스위치 이중화

카프카 구성

서버 수량

최소 3개의 브로커
- 손쉬운 서버 확장 가능함으로 필요한 만큼만

하드웨어

프로듀서나 컨슈머의 처리량을 높이기 위해 배치 / 압축 기능을 많이 적용하게 됨으로 CPU 사용량이 높은 편
- 코어수 많은 CPU
카프카에서 요구하는 JVM 힙 크기는 6GB 정도임으로 이보다 큰 물리 메모리
- 힙 크기를 제외한 물리 메모리는 모두 페이지 캐시로 사용해 빠른 처리 도움
- 32~256GB
로그 마지막에 순차적으로 씀으로 어느 디스크나 가능
병렬 처리를 위해 10개 정도, 토픽 보관 주기를 충분하게 설정하려면 4TB 이상
이더넷 카드 10G, 네트워크 사용량 비율이 50%가 넘지 않도록 토픽을 분산해 운영
- 디스크 장애 복구 / 신규 브로커 추가로 인해 카프카 클러스터내 대량 데이터 이동 발생

배치

여러 랙에 분산해 카프카 서버 배치, 전원 / 스위치 이중화

모니터링 시스템 구성

애플리케이션으로서 카프카의 로그 관리와 분석

카프카 애플리케이션 로그

자바 기반 log4j, 레벨별 로깅
default : INFO
브로커에서 직접 로그 레벨 변경 가능
실습 : 223p
레벨 낮출 수록 많은 로그가 기록됨으로 브로커의 디스크 여유 공간 확인 필요
브로커 설정 및 정보, 컨트롤러 / 클라이언트 요청, 로그 컴팩션, 인증 등 정보 기록

JMX를 이용한 카프카 메트릭 모니터링

JMX

자바로 만든 애플리케이션의 모니터링을 위한 도구를 제공하는 자바 API
상태나 이상 유무를 빠르게 확인 , MBean 이라는 객체로 표현

JMX를 이용해 카프카의 주요 메트릭들을 그래프와 같은 형태로 확인

확인 방법
- JMX 포트 요청 → 메트릭 정보를 관리자가 GUI 형태로 볼 수 있게 구성
- 프로메테우스 + 익스포터 많이 사용
- 역할
  - 프로메테우스
    - 주기적으로 대상서버의 메트릭값을 가져와 자신의 DB에 저장
    - http 클라이언트 요청에 응답하는 형태로 로컬 JVM의 메트릭을 보여주기 위해 독립적인 HTTP 서버로 설정 / 자바 에이전트로 설정 중 선택
  - 그라파나
    - 대시보드 형태로 보여줌
    - 누군가 이미 만들어둔 메트릭 대시보드를 upload json file을 함으로써 import 가능
  - 익스포터
    - 프로메테우스의 모니터링 방식은 푸시가 아닌 풀임으로 모니터링 하는 대상 서버에 자신의 메트릭 정보를 보여줄 수 있는 익스포터 설치 필요
    - 다양한 애플리케이션에서 수집되는 메트릭을 프로메테우스가 인식할 수 있는 형태로 나타내는 에이전트
    - 예제에서는 JMX 익스포터 프로세스의 관리를 용이하게 하기 위해서 systemd를 이용해 실행
    - 상태 확인 명령어(sudo systemctl status jmx-exporter > Active) / curl 명령어로 확인
    - 카프카 클러스터 내 모든 브로커에 설치 + 프로메테우스 환경 설정 파일에 수집 대상 서버 명시 ⇒ 프로메테우스에 메트릭이 수집, 저장
    - 노드 익스포터
      - 서버에서 제공하는 CPU, 디스크, 네트워크 등의 리소스 사용량을 수집
JMX 모니터링 지표
- https://docs.confluent.io/platform/current/kafka/monitoring.html

카프카 익스포터

카프카 모니터링시 컨슈머의 LAG(Producer가 넣은 메세지의 Offset과 Consumer가 가져간 메세지의 Offset간의 차이) 모니터링이 가장 중요

출저 : 고승범 저, 실전 카프카 개발부터 운영까지, 책만, 7장 카프카 운영과 모니터링

Udemy :【한글자막】 Docker & Kubernetes : 실전 가이드 수강 후기

sanook — Sun, 21 Jan 2024 21:23:12 +0900

컨테이너 간 통신

Docker 컨테이너와의 통신은 어떻게 이루어 지게 될까요?
강의에서는 세가지 경우를 설명하고 있습니다.

Case 1: WWW 통신 컨테이너

컨테이너에서 실행되는 어플리케이션이 웹 API로 HTTP Request를 보내는 방법을 설명합니다.

이는 일반적인 API 통신과 동일한 방식으로 이루어집니다.

Case 2: 컨테이너에서 로컬 호스트 머신으로의 통신

컨테이너 내부에서 호스트 머신 또는 다른 도커화된 앱과의 통신이 필요한 경우에 대한 방법을 다룹니다.

특히, 호스트머신이나 데이터베이스와 통신하고자 할 때 해당 주소 설정은 아래와 같습니다.

localhost -> host.docker.internal

도커가 이해할 수 있는 도메인 도커 컨테이너 내부에서 알 수 있는 호스트 머신의 IP 주소로 변환되며 컨테이너와 호스트 머신 간의 통신을 보장합니다.

Case 3: 컨테이너 간 통신

컨테이너 내에서 실행 중인 어플리케이션이 다른 컨테이너와 통신하길 원할 때 어떻게 설정하는지에 대한 내용을 다룹니다.

이때 컨테이너의 IP 주소를 명시하여 통신을 설정하고 이를 확인 할 수 있는 방법은 아래와 같습니다.

docker container inspect {name}

실행 결과의 NetworkSettings > IPAddress는 컨테이너의 IP 주소를 의미하며 default port는 27017 입니다.

Docker Networks 소개: 우아한 컨테이너 간 통신

다음으로, 컨터이너 네트워크(=네트워크)는 다중 컨테이너 간의 통신을 허용하는 것을 의미합니다.

네트워크를 생성하고 컨테이너를 해당 네트워크에 연결하는 방법은 아래와 같습니다.

docker run --network {네트워크 이름}

--network 라는 플래그를 설정하여 모든 컨테이너를 하나의 동일한 네트워크에 밀어 넣을 수 있고 컨테이너 IP 조회 및 해결 작업을 자동으로 수행할 수 있습니다.
실행시 중지된 컨테이너 제거 후 실행 필요하며 도커는 네트워크를 자동으로 생성하지 않음으로 직접 만들어야 합니다.

docker networkd create {네트워크 이름}
# my_network 와 같이 생성한 네트워크 뿐만 아니라 내장 네트워크 확인 가능 
docker networkd ls

두개의 컨테이너가 동일한 네트워크의 일부분인 경우 애플리케이션의 코드에 IP 하드코딩 하는 대신 컨테이너의 이름을 입력하면고 도커에 의해 컨테이너의 IP 주소로 변환됩니다.

이를 통해 네트워크 설정시 컨테이너에 연결하기 위해 실행될때 포트 게시(publish) 안 해주어도 통신이 가능하게 됩니다.

Docker가 IP 주소를 해결하는 방법

도커가 애플리케이션이 실행되는 환경을 소유하고 애플리케이션이 요청을 전송하는 경우 도커가 이를 인식 이 시점에서 주소, 컨테이너 이름, host.docker.internal 을 실제 IP 주소로 변환 주변의 컨테이너와 호스트 머신을 앎으로써 가능하게 됩니다.

해당 글은 https://www.udemy.com/course/docker-kubernetes-2022/ 를 보고 정리한 글로 해당 콘텐츠는 유데미로부터 강의 쿠폰을 제공받아 작성되었습니다.

글또 9기 다짐글

sanook — Sun, 10 Dec 2023 19:34:05 +0900

글또 모임 6기부터 총 4번에 참여하여 이제 9기에 참가하게 되었다.

이전 글또에 참여하며 좋은 분들을 많이 만날 수 있었고 지속해서 글을 써 나갈 수 있어 감사했다.
3개월의 휴식을 마치고 앞으로 5개월의 시간 동안 내가 작성할 수 있는 글감들은 무엇이 있을까

5개월간의 글감

Real MySQL

이번년도 6월부터 총 5개월 동안 참여한 스터디에서 1, 2권을 모두 완독하였다.

매주 50p 이상 읽고 실습하며 대략적인 내용을 알 수 있었지만 때때로 스터디에 따라가는 데 급급하여 깊이 이해하고 넘어가지 않은 부분이 존재한다.

이에 이번 5개월간 다시 책을 읽으며 다시 한번 정리해 보고 싶다.

Docker & Kubernetes : 실전 가이드
실제 업무에서 활용하고 있는 기술들이지만 매번 막히는 부분을 찾아보았을 뿐 하나하나 자세히 살펴본 적은 없다.

이번에 들을 인터넷 강의를 듣고 정리해 나가며 데브옵스 엔지니어분들과 원활한 소통을 하는 것을 우선 목표로 잡고 더 나아가 이번 연도 말에는 CKA를 위한 공부를 시작해 볼 예정이다.

Java 멀티스레딩, 병행성 및 성능 최적화 - 전문가 되기

최근 python의 멀티스레딩에 관해 공부하고 이를 타 개발자분에게 친숙한 java의 멀티스레딩과 비교하며 말씀드린 일이 있었는데 생각했던 것 보다 자세히 설명하지 못함을 깨달았다. 이를 보완하기 위해 찾은 강의인데 멀티스레드 병렬 실행 애플리케이션의 성능 관련 고려 사항 및 설계 패턴. 지연 시간 또는 처리량을 최적화하는 방법뿐만 아니라 이때 발생할 수 있는 모든 함정과 어려움 및 솔루션과 모범 사례를 공유해 주신다고 하니 기대가 된다.

마치며

이번 연도 하반기와 동일하게 내년 상반기에도 내가 맡은 업무뿐만 아니라 타 분야도 함께 공부해 가며 시야를 넓혀나가고 싶다.
이를 위해 이번 기수에는 패스 2번을 제외하고 완주해 볼 예정이다.