우노

[K8S] Label, Taint, Toleration 예제

운호(Noah) — Tue, 11 Nov 2025 14:59:37 +0900

Kubernetes - Label / Taint / Toleration 관계 정리

이 글에서는 Label, nodeSelector, Taint, Toleration의 관계와 스케줄링 과정이 어떻게 흘러가는지를 구체적인 예시로 정리했습니다.

Label, Taint, Toleration 관계

개념	설정 대상	역할	예시
Label	노드 or 파드	“나는 이런 속성을 가지고 있다”	`nodepool=variant`
nodeSelector	파드	파드가 “어떤 라벨 가진 노드로 가고 싶은지” 지정	`nodeSelector: { nodepool: variant }`
Taint	노드	노드가 “아무나 오지 마라”는 제한	`variant=required:NoSchedule`
Toleration	파드	파드가 “그 제한을 견딜 수 있다”는 허가	`key=variant, value=required, effect=NoSchedule`

노드 스케줄링 판단 흐름

nodeSelector 일치 여부 확인 → taint/toleration 확인 → 배치

클러스터 구성 예시

노드 이름	라벨(Label)	Taint	비고
node-a	`nodepool=default`	(없음)	일반 노드
node-b	`nodepool=variant`, `gpu=true`	`variant=required:NoSchedule`	GPU 노드 (taint 있음)
node-c	`nodepool=debug`	`debug=true:NoSchedule`	디버깅 전용 노드

동작 예시

예시 1. 아무 제약이 없는 기본 파드

spec:
  containers:
  - name: web
    image: nginx

가능 노드	이유
node-a	✅(가능) - Pod에 nodeSelector가 없다면, 스케줄러는 라벨 조건은 신경 쓰지 않고, 스케줄 가능한(taint에 막히지 않은) 노드 중 하나를 선택함
node-b	❌(불가능) - Node taint에 해당하는 Pod toleration이 없음
node-c	❌(불가능) - Node taint에 해당하는 Pod toleration이 없음

예시 2. nodeSelector로 GPU 노드만 지정

spec:
  nodeSelector:
    gpu: "true"
  containers:
  - name: trainer
    image: ml/trainer:latest

가능 노드	이유
node-a	❌(불가능) - Node와 Pod의 라벨이 동일하지 않음
node-b	❌(불가능) - Node와 Pod의 라벨은 맞지만, Node taint에 해당하는 Pod toleration이 없음
node-c	❌(불가능) - Node와 Pod의 라벨이 동일하지 않음

Node와 Pod의 라벨이 일치하더라도, 그 Node에 taint가 걸려 있다면, Pod에 해당 taint를 허용하는 toleration이 필요합니다.

예시 3. nodeSelector + toleration 둘 다 있음 (정상 조합)

spec:
  nodeSelector:
    gpu: "true"
  tolerations:
    - key: "variant"
      operator: "Equal"
      value: "required"
      effect: "NoSchedule"
  containers:
  - name: trainer
    image: ml/trainer:latest

가능 노드	이유
node-a	❌(불가능) - Node와 Pod의 라벨이 동일하지 않음
node-b	✅(가능) - Label, Taint, Toleration이 모두 일치
node-c	❌(불가능) - Node와 Pod의 라벨이 동일하지 않음

예시 4. toleration만 있고 nodeSelector가 없음

spec:
  tolerations:
    - key: "debug"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"
  containers:
  - name: debug-agent
    image: internal/debug-agent:latest

가능 노드	이유
node-a	✅(가능) - Node에 선언되어있는 taint가 없음
node-b	❌(불가능) - Taint, Toleration 불일치
node-c	✅(가능) - Taint, Toleration이 일치

Pod에 Label이 없으면, toleration이 있거나 taint 없는 노드에 배치됩니다.

예시 5. debug 노드 전용 파드

spec:
  nodeSelector:
    nodepool: debug
  tolerations:
    - key: "debug"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"
  containers:
  - name: debug-agent
    image: internal/debug-agent:latest

가능 노드	이유
node-a	❌(불가능) - Node와 Pod의 라벨이 동일하지 않음
node-b	❌(불가능) - Node와 Pod의 라벨이 동일하지 않음
node-c	✅(가능) - Label, Taint, Toleration이 모두 일치

예시 6. “나는 어디든 가고 싶다” (모든 taint 허용)

spec:
  tolerations:
    - operator: "Exists"      # 모든 taint 허용
  containers:
  - name: agent
    image: global/agent:latest

가능 노드	이유
node-a	✅(가능)
node-b	✅(가능) - 모든 taint 허용
node-c	✅(가능) - 모든 taint 허용

operator: Exists는 “모든 taint를 무시한다”는 의미입니다. 주로 시스템 데몬(예: logging, monitoring agent)에서 자주 사용됩니다.

정리

Label / nodeSelector: “가고 싶은 곳”을 지정
Taint / Toleration: “들어올 수 있는가”를 결정
스케줄링 순서:
1. nodeSelector 일치 여부
2. taint/toleration 허용 여부

[Network] L4 로드 밸런서 vs L7 로드 밸런서

운호(Noah) — Tue, 7 Jan 2025 16:08:12 +0900

선요약

L4 로드 밸런서는 빠르고 간단한 트래픽 분배가 필요한 경우에 적합합니다.
- 성능이 중요하고, 복잡한 애플리케이션 로직이 필요 없는 경우 유리합니다.
L7 로드 밸런서는 애플리케이션 로직에 맞춰 세분화된 트래픽 분배가 필요한 경우에 적합합니다.
- 고급 기능이 필요하거나 세션 유지와 동적 라우팅이 중요한 애플리케이션에서 유리합니다.

들어가기 앞서,

로드 밸런서는 네트워크 트래픽을 여러 서버나 리소스로 분산시켜서 시스템의 부하를 효율적으로 처리하고, 가용성을 높이는 역할을 합니다.
로드 밸런서에는 L4 (Layer 4) 로드 밸런서와 L7 (Layer 7) 로드 밸런서 두 가지 주요 유형이 있습니다.
이들은 OSI 모델의 서로 다른 계층에서 동작하며, 각기 다른 용도와 특성을 가지고 있습니다.

L4 로드 밸런서 (Layer 4 Load Balancer)

개념
- L4 로드 밸런서는 OSI 모델의 전송 계층 (Transport Layer)인 4계층에서 동작합니다.
- TCP/IP 또는 UDP 프로토콜을 기반으로 하여 클라이언트의 요청을 처리합니다.
- L4 로드 밸런서는 요청의 IP 주소와 포트 번호를 사용하여 트래픽을 분산합니다.
특징
- L4 로드 밸런서는 주로 IP 주소와 포트 번호를 기반으로 트래픽을 분산시킵니다.
- HTTP, HTTPS, FTP와 같은 애플리케이션 프로토콜이 아닌 저수준의 전송 프로토콜을 다룹니다.
- 로드 밸런서는 패킷 헤더 정보를 바탕으로 트래픽을 전달하므로 요청의 내용을 알지 못합니다.
장점
- 속도와 성능이 뛰어나며, 높은 트래픽을 빠르게 처리할 수 있습니다.
- 복잡한 애플리케이션 프로세스를 알지 못하므로 시스템 자원 소비가 적습니다.
- 낮은 레벨에서 동작하기 때문에 단순한 구현과 빠른 트래픽 처리가 가능합니다.
단점
- 요청의 세부 정보를 알지 못하고, 단지 네트워크 정보를 기반으로 분배하므로, 특정한 로직에 따른 세분화된 라우팅이 어렵습니다.
- 애플리케이션 계층에 대한 세부 정보를 고려하지 않기 때문에 복잡한 라우팅 전략이나 세션 유지가 필요한 경우에는 적합하지 않을 수 있습니다.

L7 로드 밸런서 (Layer 7 Load Balancer)

개념
- L7 로드 밸런서는 OSI 모델의 애플리케이션 계층 (Layer 7)에서 동작합니다.
- HTTP, HTTPS, WebSocket, FTP, SMTP와 같은 애플리케이션 프로토콜에 대한 트래픽을 분석하고 처리합니다.
- L7 로드 밸런서는 HTTP 헤더, 쿠키, URI 경로 등을 분석하여 요청을 처리하고, 요청에 맞는 서버로 트래픽을 분배합니다.
특징
- 애플리케이션 레벨에서 트래픽을 분배하며, HTTP 요청의 세부 내용까지 파악할 수 있습니다.
- 동적 라우팅과 세분화된 정책을 설정할 수 있습니다. 예를 들어, URL 경로에 따라 서로 다른 서버로 트래픽을 전달하는 등의 처리가 가능합니다.
- SSL 종료, 리다이렉트, 리버스 프록시 등 고급 기능을 제공할 수 있습니다.
장점
- 세분화된 라우팅과 애플리케이션 계층의 동적 제어가 가능하여 복잡한 애플리케이션 로직을 처리할 수 있습니다.
- 세션 유지 및 상태 정보 기반 라우팅이 가능하며, 트래픽의 세부 내용을 기반으로 한 최적화가 가능합니다.
- 애플리케이션 레벨에서 SSL 종료, URL 기반 라우팅, IP 주소 기반 라우팅 등 다양한 기능을 지원합니다.
단점
- L4보다 성능이 떨어질 수 있습니다.
  - 애플리케이션 프로토콜을 분석하고 처리해야 하므로, 더 많은 시스템 리소스를 사용하고 더 높은 지연을 발생시킬 수 있습니다.
- 구현이 더 복잡하며, 자원 소비가 많을 수 있습니다.

L4와 L7 로드 밸런서를 선택하는 기준

L4 로드 밸런서 사용 사례
- 단순한 트래픽 분배: 트래픽이 단순히 네트워크 계층에서 분배되고, 애플리케이션의 복잡한 로직을 처리할 필요가 없는 경우.
- 고성능 및 빠른 처리: 빠른 응답 시간이 필요한 애플리케이션이나 고속 트래픽 처리가 중요한 경우.
  - 예를 들어, 게임 서버, 비디오 스트리밍 등에서는 L4 로드 밸런서를 사용합니다.
- TCP/UDP 기반 서비스: HTTP 외의 서비스(FTP, DNS 등)를 로드 밸런싱하는 경우.
L7 로드 밸런서 사용 사례
- 애플리케이션 세부 제어: URL, 헤더, 쿠키, 파라미터 등에 따라 정밀한 라우팅이 필요한 경우.
  - 예를 들어, 웹 애플리케이션에서 /images/* 요청은 특정 서버로, /api/* 요청은 다른 서버로 보내는 경우.
- 세션 유지를 위한 로드 밸런싱: 사용자의 상태를 유지하며 같은 서버로 계속 요청을 보내는 경우.
  - 예를 들어, 로그인 상태를 유지해야 하는 웹 애플리케이션.
- SSL 종료: HTTPS 트래픽을 로드 밸런서에서 종료하고, 이후에는 HTTP로 전달하는 기능을 제공하는 경우.
- 복잡한 애플리케이션 요구 사항: 트래픽을 기반으로 동적으로 처리해야 하는 경우 (예: 리버스 프록시, 인증 처리 등).

L4와 L7 로드 밸런서의 결합

하이브리드 방식으로 L4와 L7 로드 밸런서를 조합하여 사용하는 것도 가능합니다.
예를 들어, 트래픽의 대다수는 L4 로드 밸런서를 통해 빠르게 처리하고, 특정 요청은 L7 로드 밸런서를 사용하여 세부 로직을 처리하는 방식입니다.

[Kotlin] Bulk Insert

운호(Noah) — Fri, 3 Jan 2025 15:22:07 +0900

Bulk Insert란?

Bulk Insert는 데이터베이스에 여러 개의 데이터를 한 번에 삽입하는 기법으로,
여러 번의 Single Insert 대신 한 번에 여러 레코드를 삽입하여 속도와 효율성을 개선할 수 있습니다.

Single Insert vs Bulk Insert

Single Insert

데이터를 하나씩 삽입하는 방식입니다.

  INSERT INTO table1 (col1, col2) VALUES (val11, val12);

여러 번 반복되는 경우

  INSERT INTO table1 (col1, col2) VALUES (val11, val12);
  INSERT INTO table1 (col1, col2) VALUES (val21, val22);
  INSERT INTO table1 (col1, col2) VALUES (val31, val32);

Bulk Insert

여러 개의 데이터를 한 번에 삽입하는 방식입니다.

  INSERT INTO table1 (col1, col2) VALUES
  (val11, val12),
  (val21, val22),
  (val31, val32);

Bulk Insert의 장점

속도 개선: 한 번의 네트워크 호출로 여러 개의 데이터를 삽입하여 성능이 향상됩니다.
리소스 절약: 네트워크 호출 횟수와 데이터베이스 연결을 줄여 시스템 자원을 절약할 수 있습니다.
트랜잭션 관리: 여러 데이터를 하나의 트랜잭션으로 처리하여 일관성을 유지하고, 오류 발생 시 전체 작업을 롤백할 수 있습니다.

JPA와 JDBC에서 Bulk Insert 처리 방법

JPA의 saveAll() 사용하기
- JPA는 saveAll() 메서드를 통해 여러 데이터를 한 번에 저장할 수 있습니다.
- 하지만 내부적으로 반복적으로 save()를 호출하여 데이터를 개별적으로 처리하므로 진정한 Bulk Insert가 아님
  - save() : N개의 트랜잭션과 N개의 쿼리
  - saveAll() : 1개의 트랜잭션과 N개의 쿼리
- 문제점
  - Hibernate의 쓰기 지연(Write-Behind) 전략
    - 데이터는 영속성 컨텍스트에 저장되고 트랜잭션이 커밋될 때 INSERT 쿼리가 실행됩니다.
    - 하지만 IDENTITY 전략을 사용하면, 각 엔티티의 ID를 알기 위해 매번 INSERT가 실행되어 Batch Insert가 불가능합니다.
  - 영속성 컨텍스트의 메모리 문제
    - 많은 데이터를 한 번에 저장하면 메모리 사용량이 증가하고 성능 저하가 발생합니다.
  - 성능 문제
    - JPA의 saveAll()은 개별 쿼리를 실행하므로 네트워크 호출이 많아지고 속도가 느려질 수 있습니다.
- 해결 방법
  - ID 생성 전략 변경
    - IDENTITY 대신 SEQUENCE 또는 TABLE 전략을 사용하여 ID 값을 미리 생성할 수 있습니다.
  - Batch Insert 활성화
    - Hibernate 설정을 통해 Batch Insert를 활성화합니다.
```
  spring.jpa.properties.hibernate.jdbc.batch_size=30
  spring.jpa.properties.hibernate.order_inserts=true
  spring.jpa.properties.hibernate.order_updates=true
```

JDBC의 batchUpdate 사용하기

JDBC는 데이터베이스에 최적화된 Batch Insert 기능을 제공합니다.

JdbcTemplate의 batchUpdate() 메서드를 사용하면 여러 데이터를 효율적으로 삽입할 수 있습니다.

String sql = "INSERT INTO table1 (col1, col2) VALUES (?, ?)";

jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() {
  @Override
  public void setValues(PreparedStatement ps, int i) throws SQLException {
      ps.setString(1, dataList.get(i).getCol1());
      ps.setString(2, dataList.get(i).getCol2());
  }

  @Override
  public int getBatchSize() {
      return dataList.size();
  }
});

Native SQL을 사용한 Bulk Insert
- Spring Data JPA는 Native SQL을 지원합니다.
- 이를 통해 직접 SQL 쿼리를 실행하여 효율적으로 Bulk Insert를 처리할 수 있습니다.
```
  @Query(value = "INSERT INTO table1 (col1, col2) VALUES :values", nativeQuery = true)
  void bulkInsert(@Param("values") List<Object[]> values);
```

Bulk Insert의 성능 비교

방법	10000건 처리 시간	장점	단점
JPA saveAll()	느림 (~5초)	코드 간결, 트랜잭션 관리 자동화	개별 INSERT 쿼리 실행으로 성능 저하
JDBC batchUpdate()	빠름 (~1초)	최적화된 성능, 네트워크 호출 감소	직접 쿼리 작성 필요
Native SQL	빠름 (~1초)	데이터베이스 기능 활용 가능	유지보수가 어렵고 JPA의 장점 활용 불가

Bulk Insert 시 주의사항

MySQL의 max_allowed_packet 설정
- MySQL에서 한번에 보낼 수 있는 데이터 크기 제한이 max_allowed_packet 설정값을 넘지 않도록 주의해야 합니다.
- 너무 큰 데이터를 한 번에 보내지 않도록 배치 크기를 조절하는 것이 중요합니다.
메모리 관리
- 대량 데이터를 처리할 경우 메모리 부족 문제가 발생할 수 있습니다.
- 배치 크기를 조정하여 메모리 사용량을 관리하세요.
롤백 비용
- 배치 처리 중 오류가 발생하면 전체 트랜잭션이 롤백되므로, 배치 크기를 적절히 조정하여 롤백 비용을 최소화해야 합니다.

결론

Bulk Insert는 대량 데이터를 효율적으로 삽입할 수 있는 기법으로, 성능 향상과 리소스 절약이 가능합니다.
JPA를 사용할 때는 Hibernate Batch Insert 설정을 활용하거나, JDBC batchUpdate와 Native Query를 적절히 활용하여 성능을 최적화할 수 있습니다.
데이터 크기, 메모리 사용량, 롤백 비용을 고려하여 배치 크기와 전략을 신중히 설계하세요.

참고

[Kotlin] @Transactional, Service vs Repository 어디에 적용할까?

운호(Noah) — Thu, 26 Dec 2024 16:36:57 +0900

Spring에서 @Transactional, 어디에 적용할까?

Spring에서 트랜잭션 관리를 위해 사용하는 @Transactional은 주로 Service 계층과 Repository 계층에 적용됩니다.
두 계층에서의 사용법과 차이를 알아보고, 올바른 설계 방향을 살펴보겠습니다.

Service 계층에서 @Transactional

Service 계층은 비즈니스 로직을 처리하는 핵심 부분입니다.
이 계층에 @Transactional을 사용하면 비즈니스 작업 단위 전체를 하나의 트랜잭션으로 묶을 수 있습니다.

예제

  @Service
  public class OrderService {
      @Transactional
      public void placeOrder(Order order) {
          orderRepository.save(order);
          paymentService.processPayment(order);
      }
  }

장점
- 트랜잭션 경계 설정: 비즈니스 로직 전체를 하나의 트랜잭션으로 묶어 관리 가능.
- 예외 처리: Service 계층에서 발생한 예외에 따라 트랜잭션을 자동으로 커밋하거나 롤백.
- 책임 분리: Repository는 데이터 접근만 담당하고, 트랜잭션 관리는 Service에서 처리.
언제 사용하면 좋을까?
- 여러 Repository 호출이나 외부 API 호출을 조합한 복잡한 로직을 처리할 때.
- 비즈니스 작업 전체를 하나의 트랜잭션으로 묶어야 할 때.

Repository 계층에서 @Transactional

Repository 계층은 데이터 접근 로직을 처리하는 곳입니다.
이 계층에 @Transactional을 사용하면 특정 데이터 접근 작업을 트랜잭션 단위로 묶을 수 있습니다.

예제

  @Repository
  public class OrderRepository {
      @Transactional
      public void save(Order order) {
          entityManager.persist(order);
      }
  }

장점
- 특정 데이터 접근 로직만 트랜잭션으로 묶고자 할 때 유용.
- 단순한 데이터 작업에 적합.
단점
- 여러 Repository를 조합한 작업에서는 트랜잭션 경계가 불명확해질 수 있음.
- Service 계층에서 트랜잭션을 관리하지 않으면 코드가 비일관적이 될 수 있음.
언제 사용하면 좋을까?
- Service 계층이 필요 없을 정도로 간단한 데이터 작업만 처리할 때.
- 트랜잭션 범위를 좁게 설정하고 싶을 때.

Service vs Repository: 무엇을 선택해야 할까?

둘 중 하나를 선택해야 한다면 Service 계층에서 트랜잭션을 관리하는 것이 일반적으로 더 권장되며, 이유는 다음과 같습니다.
- Service 계층에서 트랜잭션 관리: 비즈니스 로직의 경계를 명확히 설정할 수 있음.
- Repository는 데이터 접근만 담당: 트랜잭션의 책임을 분리하고 역할을 명확히 할 수 있음.
예외 상황
- 간단한 애플리케이션이나 특정 Repository 메서드만 트랜잭션이 필요한 경우, Repository에 @Transactional을 사용하는 것도 괜찮습니다.

Service와 Repository에 동시에 사용하면?

Service와 Repository에 중복으로 @Transactional을 사용해도 문제가 되지는 않습니다.
다만, Service 계층의 트랜잭션이 우선됩니다.
- 즉, Service에서 시작된 트랜잭션에 Repository가 참여하게 됩니다.
또한, 중복 사용의 단점이 발생합니다.
- 불필요한 코드 중복 발생.
- 트랜잭션 관리 책임이 명확하지 않음.

결론

@Transactional은 어디에 적용하느냐에 따라 트랜잭션 관리 방식이 달라집니다.
- Service 계층: 비즈니스 로직 전체를 트랜잭션 단위로 묶어야 할 때 사용.
- Repository 계층: 특정 데이터 접근 작업만 트랜잭션 단위로 묶을 때 사용.
추천 설계
- 대부분의 경우 Service 계층에 @Transactional을 사용하고,
- Repository는 데이터 접근에 집중하도록 설계하는 것이 유지보수성과 확장성 면에서 유리합니다.

[Kotlin] @Transactional

운호(Noah) — Mon, 23 Dec 2024 13:43:04 +0900

@Transactional 이란?

@Transactional은 Spring에서 트랜잭션 관리를 자동화해주는 강력한 애노테이션입니다.
메서드나 클래스에 선언하면, 트랜잭션이 시작되고 작업 완료 시 자동으로 커밋하거나 예외 발생 시 롤백됩니다.

1. 메서드 수준에서 사용

메서드가 실행되는 동안 트랜잭션이 시작됩니다.

  @Service
  class UserService(private val userRepository: UserRepository) {

      @Transactional
      fun createUser(user: User): User {
          userRepository.save(user) // 트랜잭션 내 작업
          return user // 트랜잭션 커밋
      }
  }

2. 클래스 수준에서 사용

클래스에 선언하면 해당 클래스의 모든 메서드에 트랜잭션이 적용됩니다.

  @Service
  @Transactional
  class UserService(private val userRepository: UserRepository) {

      fun createUser(user: User): User {
          userRepository.save(user)
          return user
      }

      fun updateUser(user: User): User {
          userRepository.save(user)
          return user
      }
  }

주요 옵션

@Transactional은 다양한 옵션을 제공하여 트랜잭션 동작을 세밀하게 제어할 수 있습니다.

1. 전파 방식 (Propagation)

트랜잭션이 호출될 때, 기존 트랜잭션을 사용할지, 새로 생성할지 결정합니다.
- REQUIRED: 기본값. 기존 트랜잭션이 있으면 사용하고, 없으면 새로 생성합니다.
- REQUIRES_NEW: 항상 새 트랜잭션을 생성하고, 기존 트랜잭션은 일시 중단됩니다.
- SUPPORTS: 기존 트랜잭션이 있으면 사용하고, 없으면 트랜잭션 없이 실행됩니다.
- NOT_SUPPORTED: 트랜잭션 없이 실행하고, 기존 트랜잭션이 있으면 일시 중단됩니다.
- MANDATORY: 기존 트랜잭션이 반드시 있어야 하며, 없으면 예외가 발생합니다.
- NEVER: 트랜잭션 없이 실행하고, 기존 트랜잭션이 있으면 예외가 발생합니다.
- NESTED: 중첩 트랜잭션을 생성하며, 독립적인 롤백이 가능합니다. (JDBC에서만 지원)
```
@Transactional(propagation = Propagation.REQUIRES_NEW)
fun processPayment(payment: Payment) {
  // 항상 새로운 트랜잭션으로 실행
}
```

2. 격리 수준 (Isolation)

동시에 실행되는 트랜잭션 간 데이터 일관성을 유지하는 방법을 설정합니다.
- DEFAULT: 데이터베이스의 기본 설정을 사용합니다. 일반적으로 READ_COMMITTED입니다.
- READ_UNCOMMITTED: 커밋되지 않은 데이터도 읽을 수 있습니다. (Dirty Read 허용)
- READ_COMMITTED: 커밋된 데이터만 읽을 수 있습니다. (Dirty Read 방지)
- REPEATABLE_READ: 트랜잭션 동안 동일 데이터를 읽으면 항상 같은 값을 읽습니다. (Phantom Read 허용)
- SERIALIZABLE: 가장 높은 격리 수준으로, 트랜잭션이 완전히 순차적으로 실행됩니다. (성능 저하 가능)
```
@Transactional(isolation = Isolation.REPEATABLE_READ)
fun getAccountBalance(accountId: Long): BigDecimal {
  // 트랜잭션 내 동일 데이터의 일관성 유지
}
```

3. 읽기 전용 (ReadOnly)

데이터 조회만 수행하는 경우, 최적화를 위해 읽기 전용으로 설정합니다.

  @Transactional(readOnly = true)
  fun getAllUsers(): List<User> {
      return userRepository.findAll() // 읽기 전용 작업
  }

4. 타임아웃 (Timeout)

트랜잭션이 특정 시간 내 완료되지 않으면 롤백합니다.

  @Transactional(timeout = 5) // 5초 초과 시 롤백
  fun processLargeData() {
      // 오래 걸리는 작업
  }

5. 롤백 조건 (RollbackFor, NoRollbackFor)

특정 예외에 대해 롤백 여부를 설정할 수 있습니다.

  @Transactional(rollbackFor = [CustomException::class])
  fun updateUser(user: User) {
      if (user.name.isEmpty()) {
          throw CustomException("Invalid user name") // 롤백 발생
      }
      userRepository.save(user)
  }

주의사항

같은 클래스 내 메서드 호출
- @Transactional은 Spring 프록시로 작동하므로, 같은 클래스 내 메서드 호출 시 적용되지 않습니다.
```
@Transactional
fun methodA() {
  methodB() // 트랜잭션 적용되지 않음
}
```
Checked Exception
- 기본적으로 Checked Exception이 발생해도 트랜잭션은 롤백되지 않습니다.
- 롤백을 원하면 rollbackFor를 명시적으로 설정해야 합니다.

요약

@Transactional은 데이터의 일관성과 안정성을 보장하며, 트랜잭션 관리를 쉽게 해줍니다.
주요 옵션(전파 방식, 격리 수준, 읽기 전용 등)을 상황에 맞게 설정하면, 성능과 유지보수성을 동시에 확보할 수 있습니다.
기본 동작을 이해하고 적절히 설정하여 애플리케이션의 데이터 무결성을 유지하세요.

[Kotlin] @Service vs @Component

운호(Noah) — Mon, 23 Dec 2024 11:14:05 +0900

@Service

의미: 서비스 계층(비즈니스 로직을 처리하는 계층)을 나타내는 클래스에 사용합니다.
사용 목적: 애플리케이션의 핵심 비즈니스 로직을 담당하는 클래스임을 명확히 하기 위해 사용됩니다.
주요 역할:
- 비즈니스 규칙 및 트랜잭션 관리.
- 다른 계층(@Repository, @Component)의 Bean을 사용하여 로직을 조합.
- 데이터와 사용자 인터페이스 사이를 연결하는 가교 역할.

@Component

의미: 특정 계층에 속하지 않는 일반적인 클래스를 Spring Bean으로 등록할 때 사용합니다.
사용 목적: 유틸리티, 공통 로직, 지원 클래스 등 다양한 곳에서 재사용될 수 있는 Bean을 등록합니다.
주요 역할:
- 특정 계층(Service, Controller, Repository)에 명시적으로 속하지 않는 클래스.
- 범용적인 기능(예: 문자열 처리, 포맷팅, 데이터 변환)을 제공.

비유로 이해하기

스프링 애플리케이션을 하나의 조직으로 생각해 봅시다.
- @Service
  - "비즈니스 로직을 수행하는 핵심 부서의 직원"
  - 예를 들어, 사용자의 주문을 처리하거나 결제 시스템과 상호작용하는 업무 담당자입니다.
- @Component
  - "특정 부서에 속하지 않고 여러 부서를 지원하는 지원 직원"
  - 예를 들어, 모든 부서에서 사용하는 공용 도구(문서 양식 변환기, 데이터 계산기) 같은 역할을 합니다.
- 다른 계층 어노테이션과의 비교
  - @Controller: 사용자와 직접 소통하는 프런트라인 직원(예: 사용자 요청을 받고 결과를 반환).
  - @Repository: 데이터베이스를 관리하는 기록 담당자(예: 데이터 저장소와 직접 상호작용).

@Component 예제

아래는 특정 계층에 속하지 않는 문자열 포맷팅 유틸리티 클래스입니다.

  import org.springframework.stereotype.Component

  @Component
  class StringFormatter {
      fun capitalize(input: String): String {
          return input.replaceFirstChar { it.uppercaseChar() }
      }
  }

특징:
- 이 클래스는 비즈니스 로직이 아니며, 특정 계층에 속하지 않습니다.
- 여러 계층에서 재사용될 수 있는 범용 유틸리티입니다.

@Service 예제

아래는 비즈니스 로직을 처리하는 서비스 클래스입니다.

  import org.springframework.stereotype.Service

  @Service
  class GreetingService(private val stringFormatter: StringFormatter) {
      fun getGreeting(name: String): String {
          return "Hello, ${stringFormatter.capitalize(name)}!"
      }
  }

특징:
- GreetingService는 비즈니스 로직을 담당합니다.
- 내부적으로 StringFormatter를 사용하여 문자열을 변환하는 로직을 조합합니다.
- 서비스 계층에 적합한 작업(예: "환영 메시지 생성")을 수행합니다.

FAQ

@Component 대신 항상 @Service를 사용하면 안 되나요?
- 가능은 하지만, @Service는 비즈니스 로직을 처리하는 클래스를 나타내기 위해 사용합니다.
- 모든 클래스에 @Service를 사용하면 계층을 구분하는 의도가 모호해질 수 있습니다.
@Component와 @Service가 내부적으로 다른가요?
- 내부적으로는 동일합니다. 둘 다 Spring Bean으로 등록되며, 동작에 차이는 없습니다.
- 단지 코드의 의도를 명확히 하기 위해 @Service를 사용합니다.

결론

비즈니스 로직을 처리하는 클래스에는 @Service를 사용하세요.
특정 계층에 속하지 않고 범용적인 지원 역할을 하는 클래스에는 @Component를 사용하세요.
이렇게 하면 코드의 가독성이 향상되고 역할이 명확해져 유지보수와 협업이 쉬워집니다.

[Kotlin] Controller와 Service의 계층 구조

운호(Noah) — Fri, 20 Dec 2024 11:40:51 +0900

컨트롤러(Controller)와 서비스(Service)의 개념

Spring Framework에서 컨트롤러(Controller)와 서비스(Service)는 애플리케이션 아키텍처의 중요한 부분으로, 각각의 역할과 책임이 명확히 나뉘어 있습니다.
이 둘은 Spring MVC(Model-View-Controller) 패턴의 일부로, 애플리케이션의 데이터 흐름을 구조화하고 유지보수를 용이하게 합니다.

컨트롤러(Controller)

컨트롤러는 클라이언트의 요청을 받아 응답을 반환하는 역할을 합니다. 주로 RESTful API 개발에서 사용됩니다.

역할
- 사용자가 보낸 요청(Request)을 받고, 적절한 서비스를 호출하여 처리 결과를 반환(Response).
- URL 경로를 매핑하고 HTTP 요청을 처리.
- 데이터를 직접 처리하지 않고, 비즈니스 로직은 서비스에 위임.
특징
- 요청/응답 흐름을 관리.
- REST API에서는 @RestController를 사용하여 JSON 데이터를 반환.
- Spring MVC 뷰를 사용하는 경우 @Controller를 사용.

예제

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

  @RestController
  @RequestMapping("/users") // 모든 요청이 /users로 시작
  public class UserController {

      private final UserService userService;

      public UserController(UserService userService) {
          this.userService = userService; // Service 의존성 주입
      }

      @GetMapping
      public List<User> getAllUsers() {
          return userService.getAllUsers(); // 서비스 호출
      }

      @GetMapping("/{id}")
      public User getUserById(@PathVariable Long id) {
          return userService.getUserById(id); // 서비스 호출
      }

      @PostMapping
      public User createUser(@RequestBody User user) {
          return userService.createUser(user); // 서비스 호출
      }
  }

서비스(Service)

서비스는 비즈니스 로직을 처리하는 계층으로, 컨트롤러와 데이터 액세스 계층(Repository) 사이에서 중간 역할을 합니다.

역할
- 컨트롤러에서 받은 요청 데이터를 바탕으로 실제 처리 작업 수행.
- 데이터베이스와의 직접적인 상호작용은 Repository에 위임.
- 애플리케이션의 핵심 로직 구현 및 재사용 가능한 메서드 작성.
특징
- 데이터 검증, 트랜잭션 관리 등의 비즈니스 로직 포함.
- 데이터 액세스 코드와 컨트롤러 코드를 분리하여 의존성을 줄임.

예제

  import org.springframework.stereotype.Service;

  @Service
  public class UserService {

      private final UserRepository userRepository;

      public UserService(UserRepository userRepository) {
          this.userRepository = userRepository; // Repository 의존성 주입
      }

      public List<User> getAllUsers() {
          return userRepository.findAll(); // 데이터베이스에서 모든 유저 조회
      }

      public User getUserById(Long id) {
          return userRepository.findById(id)
                  .orElseThrow(() -> new RuntimeException("User not found"));
      }

      public User createUser(User user) {
          return userRepository.save(user); // 새로운 유저 저장
      }
  }

컨트롤러와 서비스의 계층 구조

Spring MVC 애플리케이션의 계층 구조는 아래와 같습니다
- Controller Layer
  - 사용자의 요청을 받음 → 적절한 HTTP 응답 반환.
  - @RestController, @RequestMapping, @GetMapping 등을 사용.
- Service Layer
  - 비즈니스 로직 처리.
  - @Service를 사용하여 선언.
- Repository Layer
  - 데이터베이스와의 상호작용을 담당.
  - JpaRepository와 같은 인터페이스로 데이터 조회, 저장, 삭제.
상단 예제 코드 기반 계층 구조 흐름
1. Controller: GET /users 요청을 받으면, UserService의 getAllUsers() 호출.
2. Service: getAllUsers()에서 UserRepository를 호출하여 데이터를 가져옴.
3. Repository: findAll() 메서드를 통해 데이터베이스에서 데이터를 조회.

컨트롤러와 서비스를 분리하는 이유

유지보수성 향상
- 컨트롤러는 요청/응답만, 서비스는 비즈니스 로직만 관리.
- 각 계층이 독립적이므로 코드 가독성과 유지보수성이 높아짐.
재사용성
- 서비스 계층은 여러 컨트롤러에서 공통적으로 호출 가능.
- 동일한 비즈니스 로직을 중복 작성하지 않아도 됨.
테스트 용이성
- 역할 분리로 인해 컨트롤러와 서비스를 독립적으로 테스트하기 쉬움.
- Mock 객체를 활용하여 단위 테스트 가능.

[Kotlin] @SqlResultSetMapping

운호(Noah) — Fri, 20 Dec 2024 10:12:57 +0900

@SqlResultSetMapping

@SqlResultSetMapping은 네이티브 쿼리의 결과를 JPA에서 사용할 수 있는 형식으로 매핑하기 위해 사용하는 어노테이션입니다.
쉽게 말하면, 데이터베이스에서 가져온 데이터를 Entity나 DTO로 변환해주는 설계도라고 보면 됩니다.

왜 필요한가요?

기본적으로 JPA는 쿼리 결과를 자동으로 매핑해 주지만,
복잡한 쿼리나 특정 구조의 데이터를 반환해야 할 경우 직접 매핑을 설정해야 합니다.
@SqlResultSetMapping을 사용하면 이런 매핑 과정을 명확하고 간단하게 정의할 수 있습니다.

어떻게 사용하나요?

데이터베이스의 결과를 Entity로 매핑 (EntityResult)

사용 예시

  @SqlResultSetMapping(
      name = "UserMapping", // 매핑 이름
      entities = @EntityResult( // 엔티티로 매핑
          entityClass = User.class, // 어떤 엔티티에 매핑할지 지정
          fields = { // 쿼리 결과 컬럼 -> 엔티티 필드 매핑
              @FieldResult(name = "id", column = "user_id"),
              @FieldResult(name = "username", column = "user_name"),
              @FieldResult(name = "email", column = "user_email")
          }
      )
  )

  // User 엔티티 정의
  @Entity
  public class User { 
      @Id
      private Long id;
      private String username;
      private String email;
  }

쿼리 사용

  @Query(value = "SELECT user_id, user_name, user_email FROM users", nativeQuery = true)
  @SqlResultSetMapping(name = "UserMapping") // 매핑 참조
  List<User> findUsers();

결과
- 데이터베이스에서 가져온 쿼리 결과가 User Entity 객체에 자동으로 매핑됩니다.
- 예를 들어, user_id → id, user_name → username과 같이 컬럼 이름이 엔티티 필드에 대응됩니다.

데이터베이스의 결과를 DTO로 매핑 (ConstructorResult)

Entity가 아닌 DTO 또는 별도의 클래스로 데이터를 매핑할 때 사용합니다.
이 경우 생성자를 통해 데이터를 전달합니다.

사용 예시

  @SqlResultSetMapping(
      name = "UserDTOConstructorMapping", // 매핑 이름
      classes = @ConstructorResult( // 생성자를 통해 매핑
          targetClass = UserDTO.class, // 어떤 클래스에 매핑할지 지정
          columns = { // 쿼리 결과 컬럼 -> 생성자 매개변수 매핑
              @ColumnResult(name = "user_id", type = Long.class),
              @ColumnResult(name = "user_name", type = String.class),
              @ColumnResult(name = "user_email", type = String.class)
          }
      )
  )

  // DTO 클래스 정의
  public class UserDTO {
      private Long id;
      private String username;
      private String email;

      public UserDTO(Long id, String username, String email) { // 생성자
          this.id = id;
          this.username = username;
          this.email = email;
      }
  }

쿼리 사용

  @Query(value = "SELECT user_id, user_name, user_email FROM users", nativeQuery = true)
  @SqlResultSetMapping(name = "UserDTOConstructorMapping") // 매핑 참조
  List<UserDTO> findUserDTOs();

결과
- 쿼리 결과가 UserDTO 객체에 매핑됩니다.
- 예를 들어, user_id → 생성자의 id, user_name → username 매개변수로 전달됩니다.

요약

EntityResult : 데이터베이스 결과를 Entity로 매핑
ConstructorResult : 데이터베이스 결과를 DTO로 매핑

장점

유연성: 복잡한 쿼리 결과를 Entity나 DTO에 매핑 가능
재사용성: 동일한 매핑 이름을 여러 네이티브 쿼리에서 재사용 가능
가독성: 매핑 규칙이 명확히 정의되어 코드 가독성 향상

단점

유지 보수 어려움: 컬럼 이름 변경 시 매핑 설정도 함께 수정 필요
DB 의존성 증가: 네이티브 쿼리 사용으로 특정 DB 종속 가능성

사용 시점

여러 테이블 조합: 엔티티로 표현하기 어려운 데이터를 반환해야 할 때
DTO 반환: 엔티티 외부 데이터를 가공해 API 응답으로 전달해야 할 때

[Kotlin] ORM, JPA, Spring Data JPA

운호(Noah) — Wed, 18 Dec 2024 15:43:10 +0900

구성 요소 요약

JPA (Java Persistence API)
   ├── ORM (Object-Relational Mapping)
   │    └── Entity
   ├── Spring Data JPA
   │    └── Repository
   │         ├── JpaRepository
   │         └── CrudRepository

JPA : ORM을 Java에서 쉽게 사용할 수 있도록 정의한 표준 API입니다.
- ORM : 객체와 데이터베이스 간 매핑을 처리하는 기술입니다.
  - Entity : 데이터베이스의 테이블과 매핑되는 자바 객체입니다.
- Spring Data JPA : JPA를 쉽게 사용할 수 있도록 도와주는 Spring 모듈입니다.
  - Repository : 데이터베이스에 접근하기 위한 인터페이스입니다.
    - JpaRepository : 기본적인 CRUD 기능뿐만 아니라 페이징, 정렬, 쿼리 메소드 등을 지원하는 기능이 추가된 인터페이스입니다.
    - CrudRepository : 가장 기본적인 CRUD 기능(생성, 읽기, 수정, 삭제)을 제공하는 인터페이스입니다.

Entity

목적: 데이터베이스 테이블과 매핑되는 자바 객체입니다.
특징: @Entity 어노테이션을 사용하여 데이터베이스 테이블을 자바 클래스와 연결합니다.

예제

  @Entity
  public class Product {
      @Id
      @GeneratedValue(strategy = GenerationType.IDENTITY)
      private Long id;

      private String name;
      private Double price;

      // Getters, Setters
  }

ORM (Object-Relational Mapping)

목적: 데이터베이스와 객체(Entity) 간의 매핑을 관리하는 기술입니다.
장점: SQL을 직접 작성하지 않고 객체 지향적으로 데이터베이스 작업을 처리할 수 있어 생산성과 유지보수성을 높입니다.

예제

  @Entity
  public class User {
      @Id
      @GeneratedValue(strategy = GenerationType.IDENTITY)
      private Long id;

      private String name;
      private String email;

      // Getters, Setters
  }

JPA (Java Persistence API)

목적: Java에서 ORM(Object-Relational Mapping)을 사용하기 위한 표준 API입니다.
기능:
- Entity 매핑: 객체와 데이터베이스 테이블 간의 매핑을 제공합니다.
- 영속성 컨텍스트 관리: 엔티티 상태를 관리하여, 데이터의 생명 주기를 처리합니다.
- JPQL (Java Persistence Query Language): 객체지향적 쿼리 언어를 사용하여 데이터를 조회합니다.
- 트랜잭션 관리: 데이터 작업의 원자성 보장합니다.
필수 구현체: JPA는 표준 API이므로 Hibernate, EclipseLink, DataNucleus와 같은 구현체가 필요합니다.

Spring Data JPA

목적: JPA를 쉽게 사용할 수 있도록 돕는 Spring 모듈입니다. JPA를 사용한 데이터 접근을 더 간편하게 구현할 수 있게 해줍니다.
기능:
- 자동 구현: 인터페이스에서 JpaRepository를 상속받으면 기본적인 CRUD 작업이 자동으로 제공됩니다.
- 쿼리 메소드: 메서드 이름으로 쿼리를 생성할 수 있습니다. 예: findByName(String name)
- 페이징 및 정렬 지원: PagingAndSortingRepository로 페이징과 정렬 기능을 제공합니다.
- 커스텀 쿼리: @Query 어노테이션으로 복잡한 쿼리를 정의할 수 있습니다.

Repository

목적: 데이터베이스에 접근하기 위한 인터페이스로, CRUD (Create, Read, Update, Delete) 및 쿼리 메소드 등을 제공합니다.
Spring Data JPA의 주요 인터페이스:
- JpaRepository: 기본적인 CRUD 기능과 더불어 페이징, 정렬, 쿼리 메소드 기능을 제공합니다.
- CrudRepository: 기본적인 CRUD 기능만 제공합니다.

JpaRepository

목적: Spring Data JPA에서 데이터베이스 작업을 더 간편하게 처리할 수 있도록 돕는 인터페이스입니다.
특징:
- 기본적인 CRUD 기능과 페이징, 정렬, 쿼리 메소드 기능을 제공합니다.
- 개발자가 직접 구현하지 않고, Spring Data JPA가 자동으로 구현해줍니다.
기본적인 CRUD 제공:
- save() : 엔티티 저장
- findById() : ID로 엔티티 조회
- findAll() : 모든 엔티티 조회
- delete() : 엔티티 삭제
메서드 이름에 따른 자동 쿼리 생성:
- 예를 들어, findByName(String name) 메서드를 작성하면 name 필드를 기준으로 데이터를 조회하는 쿼리가 자동으로 생성됩니다.
JpaRepository 예시
```
  public interface UserRepository extends JpaRepository<User, Long> {
      // name 필드를 기준으로 데이터를 조회하는 쿼리가 자동으로 생성됩니다.
      List<User> findByName(String name);
  }
```
- 위 예시에서 UserRepository는 JpaRepository를 상속받아 User 엔티티에 대한 CRUD 작업을 자동으로 제공합니다.
- findByName 메서드는 name 필드를 기준으로 자동으로 쿼리를 생성하여 데이터를 조회합니다.

[Kotlin] @Entity와 @Repository

운호(Noah) — Wed, 18 Dec 2024 14:39:58 +0900

@Entity

목적
- JPA의 Entity 클래스는 데이터베이스 테이블에 매핑되는 객체입니다.
- 데이터베이스 테이블과 자바 객체 간의 매핑을 담당합니다.
어노테이션
- @Entity: 해당 클래스가 데이터베이스 테이블과 매핑된다는 것을 명시합니다.
- @Table(name = "table_name"): 데이터베이스 테이블 이름을 지정할 수 있습니다.
- @Id: 해당 필드가 기본 키(primary key)임을 지정합니다.
- @GeneratedValue: 기본 키 값의 자동 생성 전략을 지정합니다.
  - 예: GenerationType.IDENTITY
- @Column(name = "column_name"): 필드와 데이터베이스 컬럼 간의 매핑을 지정합니다.
특징
- Entity 클래스는 데이터베이스 작업을 직접 수행하지 않고, JPA에서 데이터를 저장하고 관리하기 위한 객체 모델입니다.
- Entity 자체로는 비즈니스 로직을 수행하지 않으며, 단순히 데이터베이스와의 매핑을 위한 구조체 역할을 합니다.

예시

  @Entity
  @Table(name = "user_table")
  public class User {

      @Id
      @GeneratedValue(strategy = GenerationType.IDENTITY)
      @Column(name = "user_id")
      private Long id;

      @Column(name = "username")
      private String username;

      @Column(name = "email")
      private String email;

      // Getters and Setters
  }

복합 기본키 예시

  // 복합 기본키 클래스를 @Embeddable로 정의
  @Embeddable
  public class OrderDetailId implements Serializable {
      private Long orderId;
      private Long productId;
  }

  // 복합 기본키를 @EmbeddedId로 엔티티에 포함
  @Entity
  public class OrderDetail {
      @EmbeddedId
      private OrderDetailId id;

      private Integer quantity;
      private BigDecimal price;
  }

@Repository

목적
- Repository는 주로 특정 Entity를 기준으로 데이터베이스에 접근하는 기능을 제공합니다.
- JpaRepository나 CrudRepository를 상속받은 인터페이스는 해당 Entity에 대한 CRUD 기능을 자동으로 제공합니다.
특징
- Repository는 기본적으로 특정 Entity를 다룹니다.
- 이를 기반으로 쿼리 메소드나 네이티브 쿼리를 실행하여 데이터를 처리합니다.
- JpaRepository는 기본적인 CRUD 기능 외에도 페이징, 정렬, 복잡한 쿼리 등을 처리할 수 있습니다.
예시
```
  public interface UserRepository extends JpaRepository<User, Long> {
      List<User> findByUsername(String username);
  }
```
- 위의 예시에서 UserRepository는 User 엔티티와 관련된 쿼리만 다루며,
- findByUsername 메서드는 User 엔티티를 기반으로 데이터를 조회합니다.

nativeQuery 사용 예시

  public interface UserRepository extends JpaRepository<User, Long> {

      @Query(value = "SELECT * FROM another_table WHERE condition = ?1", nativeQuery = true)
      List<Object[]> findByCustomQuery(String condition);
  }

nativeQuery를 사용하면 Entity와 관계없는 다른 테이블을 참조하거나 복잡한 SQL 쿼리를 작성하여 데이터베이스 작업을 할 수 있습니다.

기타

DataSource 설정
- application.properties 또는 application.yml 파일에서 DataSource를 설정하여 JPA가 사용할 데이터베이스 연결 정보를 제공합니다.
- Spring Data JPA는 이 설정을 통해 데이터베이스와의 연결을 관리하고, Entity에 매핑된 데이터를 쿼리 및 저장합니다.

[Kotlin] DTO와 Entity의 관계

운호(Noah) — Tue, 17 Dec 2024 17:46:13 +0900

DTO와 Entity의 관계

DTO(Data Transfer Object)와 Entity는 역할과 사용 목적이 다르며,
이로 인해 서로 명확히 구분해서 사용됩니다.

DTO와 Entity의 차이

항목	DTO	Entity
역할	데이터 전송에 사용되는 객체	데이터베이스와 직접 연결된 객체
목적	클라이언트-서버 간 데이터 교환 간소화	데이터베이스 테이블의 구조를 반영
속성	필요한 데이터만 포함, 가공된 데이터 가능	데이터베이스의 컬럼에 직접 매핑되는 필드 포함
위치	주로 API 요청/응답에서 사용됨	서비스 내부에서 사용됨
종속성	독립적, 데이터베이스와 무관	데이터베이스와 밀접하게 연관

DTO → Entity

필수는 아닙니다.
단순 조회만 수행하는 경우에는 DTO를 Entity로 변환할 필요가 없습니다.
하지만, DTO 데이터를 기반으로 데이터베이스 저장, 수정, 삭제 작업을 진행하는 경우에는 필수입니다.

Entity → DTO

필수는 아닙니다.
하지만, Entity를 그대로 사용한다면 클라이언트에게 불필요한 데이터가 노출되거나
스키마 변경 시 유지보수성에 어려움이 있을 수 있습니다.

변환 예제 - ModelMapper 사용

ModelMapper는 DTO와 Entity 간의 변환을 쉽게 해주는 Java 라이브러리입니다.
객체 간의 매핑 작업을 자동화하고, 복잡한 변환을 간단하게 처리할 수 있게 도와줍니다.
ModelMapper를 사용하여 User Entity를 UserDTO로 변환하는 예제를 확인해보겠습니다.

User Entity

public class User {
    private Long id;
    private String name;
    private String email;

    // Constructor, getters and setters
}

UserDTO

public class UserDTO {
    private Long id;
    private String name;
    private String email;

    // Constructor, getters and setters
}

ModelMapper를 사용한 변환

import org.modelmapper.ModelMapper;

public class ModelMapperExample {
    public static void main(String[] args) {
        // ModelMapper 객체 생성
        ModelMapper modelMapper = new ModelMapper();

        // Entity 객체 생성
        User user = new User();
        user.setId(1L);
        user.setName("John Doe");
        user.setEmail("john.doe@example.com");

        // Entity -> DTO 변환
        UserDTO userDTO = modelMapper.map(user, UserDTO.class);

        // 결과 출력
        System.out.println("UserDTO ID: " + userDTO.getId());
        System.out.println("UserDTO Name: " + userDTO.getName());
        System.out.println("UserDTO Email: " + userDTO.getEmail());
    }
}

결론

DTO ↔ Entity 변환은 필수가 아니지만, 보안, 유지보수, 유연성을 위해 권장됩니다.

[Kotlin] @Scheduled 란?

운호(Noah) — Mon, 2 Dec 2024 16:18:52 +0900

들어가기 앞서,

Spring의 @Scheduled 작업은 기본적으로 싱글 스레드에서 실행됩니다.
두 개 이상의 @Scheduled 작업이 정의되어 있어도, 병렬 스케줄링 설정을 하지 않으면 스프링의 기본 설정으로 인해 동시에 실행되지 않고 순차적으로 실행됩니다.
해당 개념을 모르고 무작정 코드부터 짰다가 병렬 쓰레드로 동작하지 않아, 원인을 찾느라 시간을 많이 썼습니다.. ㅜㅜ

@Scheduled 란?

@Scheduled는 Spring 프레임워크에서 제공하는 스케줄링 작업을 정의하는 어노테이션입니다.
특정 메서드를 주기적으로 실행하거나 예약된 시간에 실행할 수 있도록 설정하는 데 사용됩니다.
Spring Scheduling 기능을 활성화하면, @Scheduled 어노테이션이 붙은 메서드가 자동으로 실행됩니다.

주요 기능

주기적으로 실행해야 하는 작업 (배치 작업, 데이터 처리 등)에 사용.
간단하게 설정으로 크론 표현식, 고정된 간격(fixedRate), 고정된 지연(fixedDelay) 등을 지원.

사용 방법

스케줄링 활성화

@Scheduled를 사용하려면 Spring Boot 또는 Spring 프로젝트에서 스케줄링 기능을 활성화해야 합니다.

@SpringBootApplication
@EnableScheduling // 스케줄링 활성화
public class MyApplication {
   public static void main(String[] args) {
       SpringApplication.run(MyApplication.class, args);
   }
}

1. @Scheduled 어노테이션 적용
  
  @Scheduled 어노테이션을 메서드에 붙여 스케줄링 작업을 정의합니다.

@Scheduled 어노테이션 적용 방법

(1) 고정된 간격으로 실행 (fixedRate)

이전 작업이 시작된 시간 기준으로 일정 간격으로 실행.

@Component
public class ScheduledTasks {

  @Scheduled(fixedRate = 5000) // 5초 간격으로 실행
  public void fixedRateTask() {
      System.out.println("Fixed Rate Task: " + System.currentTimeMillis());
  }
}

(2) 작업이 끝난 후 일정 시간 뒤 실행 (fixedDelay)

이전 작업이 종료된 시점 기준으로 일정 간격 뒤 실행.

@Scheduled(fixedDelay = 5000) // 이전 작업 종료 후 5초 뒤 실행
public void fixedDelayTask() {
  System.out.println("Fixed Delay Task: " + System.currentTimeMillis());
}

(3) 초기 지연 시간 설정 (initialDelay)

작업이 시작되기 전에 초기 대기 시간을 설정.

@Scheduled(fixedRate = 5000, initialDelay = 2000) // 2초 대기 후 시작, 5초 간격 실행
public void initialDelayTask() {
  System.out.println("Initial Delay Task: " + System.currentTimeMillis());
}

(4) 크론 표현식 (cron)
- 크론 표현식을 사용해 원하는 시간대나 요일에 작업 실행.
```
@Scheduled(cron = "0 0 12 * * ?") // 매일 12시에 실행
public void cronTask() {
  System.out.println("Cron Task: " + System.currentTimeMillis());
}
```
- 크론 표현식 구조
```
  초(0-59) 분(0-59) 시(0-23) 일(1-31) 월(1-12) 요일(0-7)
```
  표현식 설명
  
  0 * * * * ? 매 분 0초마다 실행
  
  0 0 12 * * ? 매일 정오(12:00)에 실행
  
  0 0 0 * * 1 매주 월요일 자정에 실행
  
  */10 * * * * ? 매 10초마다 실행

표현식	설명
`0 * * * * ?`	매 분 0초마다 실행
`0 0 12 * * ?`	매일 정오(12:00)에 실행
`0 0 0 * * 1`	매주 월요일 자정에 실행
`/10 * * * ?`	매 10초마다 실행

주의사항

빈으로 등록된 메서드만 실행
- @Scheduled가 적용된 메서드는 반드시 Spring 빈으로 등록된 클래스에 있어야 합니다.
리턴 타입은 void
- @Scheduled 메서드는 리턴 값을 가질 수 없습니다.
병렬 실행 주의
- 기본적으로 단일 스레드에서 실행되므로, 두 개 이상의 @Scheduled 작업이 정의되어 있어도, 병렬 스케줄링 설정을 하지 않으면 스프링의 기본 설정으로 인해 동시에 실행되지 않고 순차적으로 실행됩니다.
- 병렬 처리가 필요하면 TaskScheduler 또는 @Async를 함께 사용해야 합니다.

병렬 스케줄링 설정

스케줄러가 단일 스레드로 동작하는 기본 동작을 변경하려면, 커스텀 TaskScheduler를 설정할 수 있습니다.

  @Configuration
  public class SchedulerConfig {

      @Bean
      public TaskScheduler taskScheduler() {
          ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
          scheduler.setPoolSize(5); // 5개의 스레드 풀
          scheduler.setThreadNamePrefix("MyScheduler-");
          return scheduler;
      }
  }

[BigQuery] streaming buffer란?

운호(Noah) — Thu, 25 Jul 2024 16:02:54 +0900

에러 코드

BigQuery Table에서 특정 레코드를 DELETE하려했지만, 아래 에러가 발생했습니다.

  UPDATE or DELETE statement over table '' would affect rows in the streaming buffer, which is not supported

에러 발생 원인

BigQuery는 데이터를 테이블에 영구적으로 저장하기 전에 스트리밍 버퍼(streaming buffer)라는 메모리 기반 저장소에 임시로 저장합니다.
- 높은 데이터 수신 속도를 제공하기 위함입니다.
에러 메시지는 UPDATE 또는 DELETE 문이 스트리밍 버퍼에 있는 행을 수정하려 했기 때문에 발생한 에러입니다.
스트리밍 버퍼에 있는 데이터는 아직 테이블에 완전히 반영되지 않았기 때문에 이러한 행에 대해 직접적인 수정 작업은 불가능합니다.
최근에 삽입한 데이터가 아니라면 이미 테이블로 반영됐기 때문에, 수정이 가능하며 위 에러 또한 발생하지 않습니다.
스트리밍 버퍼에 있는 최신 데이터는 일정 시간(최대 약 90분) 이후에 테이블에 반영됩니다.

에러 해결 방법

스트리밍 버퍼에 있는 데이터를 삭제하거나 수정하려면 다음 방법을 사용할 수 있습니다.

기다리기
- 스트리밍 버퍼에 있는 데이터가 테이블에 반영될 때까지 기다립니다.

임시 테이블 사용

  -- 임시 테이블로 원본 데이터 복사
  CREATE OR REPLACE TABLE mydataset.temp_table AS
  SELECT * FROM mydataset.original_table;

  -- 임시 테이블에서 수정 작업 수행
  UPDATE mydataset.temp_table
  SET column_name = 'new_value'
  WHERE condition;

  DELETE FROM mydataset.temp_table
  WHERE condition;

  -- 임시 테이블에서 원본 테이블로 데이터를 병합
  MERGE mydataset.original_table AS T
  USING mydataset.temp_table AS S
  ON T.id = S.id
  WHEN MATCHED THEN -- temp_table의 값으로 업데이트
    UPDATE SET column_name = S.column_name
  WHEN NOT MATCHED BY SOURCE THEN -- original_table에 있고 temp_table에는 없는 행은 삭제
    DELETE;

Polling과 Pulling의 차이

운호(Noah) — Mon, 8 Apr 2024 14:40:19 +0900

들어가기 앞서,

Polling과 Pulling은 모두 클라이언트가 서버로부터 데이터를 가져오는 방식을 나타내지만, 두 용어는 약간의 차이가 있습니다.

Polling

Polling은 클라이언트가 주기적으로 서버에 요청을 보내어 새로운 데이터나 업데이트가 있는지 확인하는 방식입니다.
클라이언트는 일정한 시간 간격으로 서버에 요청을 보내며, 서버는 해당 시점에 가용한 데이터를 응답으로 전송합니다.
새로운 데이터가 없더라도 클라이언트는 계속해서 요청을 보내므로, 불필요한 통신 오버헤드가 발생할 수 있습니다.
실시간성이 중요하지 않은 경우나 업데이트 빈도가 낮은 경우에 적합합니다.

Pulling

Pulling은 클라이언트가 필요할 때마다 서버에 요청을 보내어 데이터를 가져오는 방식입니다.
클라이언트는 데이터가 필요한 시점에 서버에 요청을 보내고, 서버는 요청을 받은 시점의 데이터를 응답으로 전송합니다.
Pulling은 클라이언트의 요구사항에 따라 데이터를 가져오므로, 불필요한 통신 오버헤드를 줄일 수 있습니다.
클라이언트가 능동적으로 데이터를 요청하므로, 실시간성이 필요한 경우에도 사용될 수 있습니다.

Polling과 Pulling의 주요 차이점

Polling은 새로운 데이터가 없더라도 지속적으로 요청을 보내므로 불필요한 통신 오버헤드가 발생할 수 있습니다.
반면에 Pulling은 필요한 시점에만 요청을 보내므로 오버헤드를 줄일 수 있습니다.

추가적으로

주기적인 Pulling은 Polling으로도 볼 수 있습니다.

참고

[Network] HTTP, HTTPS 및 SSL/TLS 암호화 프로토콜

운호(Noah) — Mon, 8 Apr 2024 13:49:51 +0900

HTTP(Hyper Text Transfer Protocol)란?

HyperText 문서(ex. html)를 주고받는 프로토콜입니다.
- ex) 클라이언트가 웹 브라우저에 URL을 입력하면, 웹 서버에 HyperText 문서를 요청하고 응답받는 과정이 진행됩니다.
HTTP 요청(Request) 예제
```
  GET /index.html HTTP/1.1
  Host: www.example.com
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
```
- GET : HTTP 메서드로 서버 리소스를 요청합니다.
- /index.html : 요청하는 리소스의 경로입니다.
- Host : 요청을 보내는 대상 서버의 도메인 이름입니다.
- User-Agent : 요청을 보내는 클라이언트(브라우저)의 정보입니다.
- Accept : 클라이언트가 받을 수 있는 콘텐츠 타입을 나열합니다.
HTTP 응답(Response) 예제
```
  HTTP/1.1 200 OK
  Date: Fri, 22 May 2015 06:07:21 GMT
  Content-Type: text/html
  Content-Length: 1256

  <!doctype html>
  <html>
  <head>
      <title>Example Domain</title>
      ... (응답 본문 생략)
  </html>
```
- HTTP/1.1 200 OK : HTTP 버전과 상태 코드(200은 성공)입니다.
- Date : 응답이 생성된 날짜와 시간입니다.
- Content-Type : 응답 본문의 콘텐츠 타입(여기서는 HTML)입니다.
- Content-Length : 응답 본문의 길이(바이트 단위)입니다.
- (응답 본문) : 서버가 클라이언트에게 보내는 실제 콘텐츠입니다(예시에서는 HTML 코드).

HTTPS(Hyper Text Transfer Protocol Secure)란?

HTTPS는 SSL/TLS 암호화 프로토콜을 사용하여 클라이언트와 서버 간 통신 내용을 암호화하는 프로토콜입니다.
- 일반 HTTP 통신에서는 평문 데이터를 그대로 전송하므로, 통신 내용이 제3자에게 노출될 수 있는 위험이 있습니다.
HTTPS에서 암호화되는 부분은 다음과 같습니다.
- 요청 본문 (Request Body)
  - POST 또는 PUT 요청과 같이 요청 본문에 데이터가 포함된 경우, 해당 데이터는 암호화됩니다.
  - 예를 들어, 로그인 폼의 사용자 이름과 비밀번호와 같은 민감한 정보가 요청 본문에 포함될 수 있습니다.
- 응답 본문 (Response Body)
  - 서버에서 클라이언트로 전송되는 응답의 내용은 암호화됩니다.
  - 응답 본문에는 HTML, JSON, 이미지 등의 데이터가 포함될 수 있습니다.
나머지 정보들은 요청, 응답을 올바르게 처리하고 라우팅하는데 필요한 정보이기 때문에 암호화되지 않습니다.

SSL(Secure Sockets Layer) / TLS(Transport Layer Security) 암호화 프로토콜이란?

위에서 언급했듯이, SSL/TLS 암호화 프로토콜은 HTTPS에서 클라이언트와 서버 간 통신 내용을 암호화할 때 사용되는 프로토콜입니다.
- TLS는 SSL의 후속 버전이며, 현재는 TLS가 널리 사용되고 있습니다.
SSL/TLS 암호화 프로토콜은 다음 순서로 진행됩니다.
- 암호화 통신 세션 연결 (SSL / TLS 핸드셰이크)
- 암호화 통신
- 암호화 통신 세션 연결 해제

암호화 통신 세션 연결 (SSL / TLS 핸드셰이크) 방법

클라이언트에서 서버의 SSL/TLS 인증서를 확인해 신뢰 가능한 서버인지 검증하고 클라이언트와 서버간의 안전한 데이터 전송을 위해 대칭키를 공유합니다.
- 클라이언트
  - HTTPS 통신을 시작하겠다는 요청(Client Hello)을 보냅니다.
    - 클라이언트가 지원하는 SSL/TLS 버전, 암호화 알고리즘, 압축 방식 등의 정보를 포함합니다.
- 서버
  - 응답(Server Hello)을 보냅니다.
    - 클라이언트의 SSL/TLS 버전, 암호화 알고리즘 등을 선택합니다.
  - 서버의 SSL/TLS 인증서를 보냅니다.
    - SSL/TLS 인증서에는 서버 공개키, 서버 도메인, 인증기관 정보, 유효기간 등이 포함되어 있으며,
    - 인증기관(CA, Certificate Agent)의 개인키로 암호화(서명)되어 있습니다.
- 클라이언트
  - 서버의 SSL/TLS 인증서 검증
    - 클라이언트는 신뢰할 수 있는 CA(인증기관)의 공개키를 사용해, 서버 인증서의 서명을 검증하고,
    - 인증서에 포함된 정보(서버 도메인, 유효기간 등)를 확인합니다.
  - 대칭키 전송
    - 인증서 검증에 성공하면 클라이언트는 데이터 암호화에 사용될 대칭키를 생성하고,
    - 서버의 공개키로, 대칭키를 암호화하여 전송합니다.
- 서버
  - 서버의 개인키로, 암호화된 대칭키를 복호화합니다.

전체적인 HTTPS 통신 순서

TCP 연결 설정 (3-way Handshake)
- 클라이언트가 서버에게 SYN 패킷을 보냅니다.
- 서버는 SYN 패킷을 받고, 클라이언트에게 SYN+ACK 패킷을 보냅니다.
- 클라이언트는 SYN+ACK 패킷을 받고, 서버에게 ACK 패킷을 보냅니다.
암호화 통신 세션 연결 (SSL/TLS 핸드셰이크)
- 클라이언트와 서버는 SSL/TLS 버전 및 암호화 알고리즘을 협상합니다.
- 서버는 SSL/TLS 인증서를 클라이언트에게 전송합니다.
- 클라이언트는 서버의 인증서를 검증하고, 안전한 데이터 전송을 위한 대칭키를 생성하여 서버의 공개키로 암호화한 후 전송합니다.
- 서버는 개인키로 대칭키를 복호화합니다.
암호화 통신
- 클라이언트와 서버는 공유된 대칭키를 사용하여 데이터를 암호화하고 복호화하며 통신합니다.
암호화 통신 세션 연결 해제
- 클라이언트 또는 서버가 SSL/TLS 세션 종료를 알리는 "close_notify" 경고 메시지를 보냅니다.
- 상대방은 "close_notify" 경고 메시지로 응답하여 SSL/TLS 세션 종료를 확인합니다.
- 클라이언트와 서버는 공유된 대칭키를 폐기합니다.
TCP 연결 해제 (4-way handshake)
- 클라이언트 또는 서버가 상대방에게 FIN 패킷을 보냅니다.
- 상대방은 FIN 패킷을 받고, ACK 패킷을 보냅니다.
- 상대방도 FIN 패킷을 보냅니다.
- 클라이언트 또는 서버가 FIN 패킷을 받고, ACK 패킷을 보냅니다.

참고

[Greedy] LeetCode “53. Maximum Subarray“ Python 풀이

운호(Noah) — Sat, 23 Mar 2024 19:32:34 +0900

문제 링크

https://leetcode.com/problems/maximum-subarray/description/

풀이

해당 문제는 그리디 알고리즘(Greedy Algorithm)의 한 종류인 카데인 알고리즘(Kadane’s Algorithm)을 사용해서 해결할 수 있습니다.
카데인 알고리즘(Kadane's Algorithm)은 배열에서 연속된 부분 배열의 최대 합을 구하는 효율적인 알고리즘입니다.
이 알고리즘은 O(N)의 시간 복잡도를 가지며, 다음과 같은 단계로 진행됩니다.
1. "현재 합"과 "최대 합"을 -inf(음의 무한대)로 초기화합니다.
2. 배열을 순회하며 다음 두 가지 경우 중 큰 값을 “현재 합”으로 갱신합니다.
  - 이전 인덱스까지의 “현재 합” + 현재 인덱스의 값
  - 현재 인덱스의 값
3. “현재 합”이 “최대 합”보다 크면 “최대 합”을 “현재 합”으로 갱신합니다.

예를 들어, 배열 [-2, 1, -3, 4, -1, 2, 1, -5, -2, 5]의 경우 다음과 같이 진행됩니다.

  초기화: 최대 합 = -inf, 현재 합 = -inf

  -2: 현재 합 = max(-2, -inf + (-2)) = -2
  1: 현재 합 = max(1, -2 + 1) = 1
  -3: 현재 합 = max(-3, 1 + (-3)) = -2
  4: 현재 합 = max(4, -2 + 4) = 4, 최대 합 갱신 = 4
  -1: 현재 합 = max(-1, 4 + (-1)) = 3
  2: 현재 합 = max(2, 3 + 2) = 5, 최대 합 갱신 = 5
  1: 현재 합 = max(1, 5 + 1) = 6, 최대 합 갱신 = 6
  -5: 현재 합 = max(-5, 6 + (-5)) = 1
  -2: 현재 합 = max(-2, 1 + (-2)) = -1
  5: 현재 합 = max(5, -1 + 5) = 4

따라서, 이 배열에서 연속된 부분 배열의 최대 합은 6입니다.

코드

class Solution:
    def maxSubArray(self, nums: List[int]) -> int:
        curr_sum = float(-inf)
        max_sum = float(-inf)

        for i in range(len(nums)):
            curr_sum = max(curr_sum + nums[i], nums[i])
            max_sum = max(curr_sum, max_sum)

        return max_sum

참고

https://wellsw.tistory.com/125

[DP] 백준 11722번 “가장 긴 감소하는 부분 수열” Python 풀이

운호(Noah) — Thu, 21 Mar 2024 15:36:47 +0900

문제 링크

https://www.acmicpc.net/problem/11722

코드


import sys

n = int(sys.stdin.readline())
item = list(map(int, sys.stdin.readline().split()))

# 아이템 역순 정렬
item_reversed = item[::-1]

# DP 테이블 생성
dp = [1] * n

for i in range(n):
    for j in range(i+1,n):
        # 현재 위치의 값(item_reversed[i])보다 비교 대상(item_reversed[j])보다 크면,
        # 증가하는 순서가 성립하므로 DP 테이블 업데이트
       if (item_reversed[i] < item_reversed[j]):
           dp[j] = max(dp[i]+1, dp[j])

print(max(dp))

[GCP] Bigquery 테이블 생성 with Python

운호(Noah) — Thu, 21 Mar 2024 14:56:35 +0900

들어가기 앞서,

해당 포스팅에선 Google Cloud의 BigQuery Python 클라이언트 라이브러리를 사용하여 BigQuery에 파티션된 테이블을 생성하는 코드에 대해서 다뤄보겠습니다.

예제 코드

# Google Cloud의 BigQuery 클라이언트 라이브러리를 가져옵니다.
from google.cloud import bigquery

# 사용할 BigQuery 프로젝트의 ID를 설정합니다.
project_id = "your_project_id"

# BigQuery 클라이언트 객체를 생성합니다.
bigquery_client = bigquery.Client(project=project_id)

# 생성할 BigQuery 테이블의 스키마를 정의합니다.
schema = [
    bigquery.SchemaField('category_l', 'STRING'),
    bigquery.SchemaField('category_m', 'STRING'),
    bigquery.SchemaField('category_s', 'STRING'),
    bigquery.SchemaField('company_name', 'STRING'),
    bigquery.SchemaField('date', 'DATE'),
    bigquery.SchemaField('hour', 'INTEGER'),
    bigquery.SchemaField('minute', 'INTEGER'),
    bigquery.SchemaField('usage', 'FLOAT'),
]

# 대상 데이터셋 ID와 테이블 ID를 지정합니다.
dataset_id = "your_dataset_id"
table_id = "your_table_id"

# 데이터셋 및 테이블 참조를 생성합니다.
table_ref = bigquery_client.dataset(dataset_id).table(table_id)

# 테이블 객체를 생성하고 스키마를 설정합니다.
table = bigquery.Table(table_ref, schema=schema)

# 테이블에 대한 시간 기반 파티션 설정을 추가합니다.
table.time_partitioning = bigquery.TimePartitioning(
    type_=bigquery.TimePartitioningType.DAY,  # 파티션 유형 설정 (일별)
    field='date',  # 파티션을 위한 컬럼 지정
    require_partition_filter=True  # 파티션 필터 필요 여부 설정
)

# 동일한 이름의 테이블이 존재하는 경우 삭제합니다 (선택적).
try:
    bigquery_client.delete_table(table)
except Exception as e:
    print(e)  # 에러 출력

# 테이블을 생성합니다.
create_table_result = bigquery_client.create_table(table)

# 생성 결과를 출력합니다.
print(f"Table {create_table_result.full_table_id} created.")

[GCP] GCS → Bigquery with Python

운호(Noah) — Thu, 21 Mar 2024 14:55:42 +0900

들어가기 앞서,

해당 포스팅에선 Google Cloud Storage(GCS)에서 CSV 파일을 읽어서 Google BigQuery에 데이터를 저장하는 코드에 대해서 다뤄보겠습니다.

예제 코드

# 필요한 라이브러리를 불러옵니다.
from google.cloud import storage, bigquery
import pandas as pd
from io import StringIO

# Google Cloud Storage(GCS) 설정
bucket_name = 'your_bucket_name'  # GCS 버킷 이름
prefix = 'your_file_prefix'  # 파일 경로 및 이름의 공통된 시작 부분
gcs_client = storage.Client()  # GCS 클라이언트 객체 생성
bucket = gcs_client.bucket(bucket_name)  # 버킷 객체 생성

# BigQuery 설정
bq_client = bigquery.Client()  # BigQuery 클라이언트 객체 생성
dataset_id = 'your_dataset_id'  # 데이터셋 ID
table_id = 'your_table_id'  # 테이블 ID
table_ref = bq_client.dataset(dataset_id).table(table_id)  # 테이블 참조 생성

# GCS에서 CSV 파일들을 읽고 BigQuery에 저장하는 과정
blobs = bucket.list_blobs(prefix=prefix)  # 지정된 경로의 파일 목록을 가져옵니다.
for blob in blobs:

    # CSV 파일 읽기
    data = blob.download_as_string()  # 파일 내용을 문자열로 다운로드
    df = pd.read_csv(StringIO(data.decode('utf-8')))  # 데이터프레임으로 변환

    # BigQuery에 데이터프레임 저장
    job = bq_client.load_table_from_dataframe(df, table_ref)
    job.result()  # Job이 완료될 때까지 대기

    print(f'{blob.name} 처리 완료')

[DP] 백준 12865번 “평범한 배낭” Python 풀이

운호(Noah) — Fri, 15 Mar 2024 13:40:47 +0900

들어가기 앞서,

배낭 문제(Knapsack Problem)는 제한된 공간에 가치가 높은 물건들을 최대한 많이 넣는 문제입니다.
이 문제는 물건을 나눌 수 있냐 없냐에 따라 두 가지 유형으로 나뉩니다.
- 분할 가능한 배낭 문제(Fractional Knapsack Problem)
  - 물건을 일부분으로 나눌 수 있는 경우 (예: 설탕 500g 중 300g만 넣기)
  - 그리디 알고리즘으로 해결 가능
- 0-1 배낭 문제(0-1 Knapsack Problem)
  - 물건을 나눌 수 없고, 전부 넣거나 전혀 넣지 않아야 하는 경우
  - 동적 프로그래밍(Dynamic Programming)으로 해결 가능
해당 문제는 0-1 배낭 문제(0-1 Knapsack Problem)에 해당됩니다.

설명

문제 설정
- 물건 개수: N = 4
- 배낭 용량: K = 7
- 물건 정보: (무게, 가치) = (6, 13), (4, 8), (3, 6), (5, 12)
동적 프로그래밍 테이블 d[n][k] 정의
- d[n][k]
  - n번째 물건까지 고려했을 때, 배낭 용량 k에서 얻을 수 있는 최대 가치
재귀 관계식
- 현재 물건 i, 현재 물건의 무게 weight, 현재 물건의 가치 value, 담으려는 배낭의 용량 j 일 때
- 경우 1) 현재 물건을 배낭에 담을 수 없는 경우 (weight > j)
  - d[i][j] = d[i-1][j]
    - 이전 물건을 담았을 때까지의 최대 가치
- 경우 2) 현재 물건을 배낭에 담을 수 있는 경우 (weight ≤ j)
  - d[i][j] = max( d[i-1][j-weight] + value , d[i-1][j] )
    - d[i-1][j-weight] + value : 현재 물건의 무게만큼 배낭에서 뺀 뒤, 현재 물건을 담았을 때의 최대 가치
    - d[i-1][j] : 현재 물건을 담지 않았을 때의 최대 가치
최종 코드
- 모든 값이 채워진 2차원 DP 테이블의 d[N][K] 값

진행 순서

첫 번째 물건(6, 13) 고려
두 번째 물건(4, 8) 고려
세 번째 물건(3, 6) 고려
네 번째 물건(5, 12) 고려

예제 코드

import sys

# 물건 개수, 배낭의 최대 용량
n, k = map(int, sys.stdin.readline().split())

# DP 테이블
dp = [[0] * (k+1) for _ in range(n+1)]

# 다루고자하는 물건(무게, 가치) 목록
items = [[0, 0]]
for _ in range(n):
    w, v = map(int, sys.stdin.readline().split())
    items.append([w, v])

for i in range(1, n+1):
    # 현재 물건의 무게와 가치
    w = items[i][0]
    v = items[i][1]

    for j in range(1, k+1):

        # 현재 물건을 배낭에 담을 수 없는 경우
        if (w > j):
            dp[i][j] = dp[i-1][j]

        # 현재 물건을 배낭에 담을 수 있는 경우
        else:
            dp[i][j] = max(dp[i-1][j-w] + v, dp[i-1][j])

print(dp[n][k])

참고

B 트리란?

운호(Noah) — Wed, 13 Mar 2024 11:34:47 +0900

B 트리란?

B트리는 데이터베이스와 파일 시스템에서 널리 사용되는 자가 균형 이진 검색 트리의 일종입니다.
B트리의 설계는 디스크 I/O 작업의 최소화를 목표로 하며, 이를 위해 트리의 높이를 가능한 낮게 유지합니다.
해당 포스팅에선 B트리의 규칙과 조회, 삽입, 삭제 방법에 대해서 다뤄보겠습니다.

규칙

노드
- 노드 차수(M): 각 노드가 가질 수 있는 자식 노드의 최대 개수
  - 각 노드는 최소 M/2개에서 최대 M개의 자식 노드를 가질 수 있습니다.
- 루트 노드: 최소 2개의 자식 노드 (트리 생성/삭제 시 예외 가능)
- 내부 노드: 최소 ⌈M/2⌉개의 자식 노드
- 리프 노드: 모든 리프 노드는 동일한 레벨에 있어야 함 (데이터 접근 시간 균일화)
키
- 각 노드에 저장된 값입니다.
- 키 개수 범위: 최소 (M/2)-1개, 최대 M-1개 (최소 키 개수는 1개)
- 키는 노드 내부에서 정렬된 상태로 유지되어야 합니다.

조회 방법

B트리에서 데이터를 조회할 때는 루트에서 시작하여 재귀적으로 자식 노드를 탐색하며, 리프 노드에서 최종적으로 키의 존재 유무를 판단하는 방식입니다.
1. 루트 노드에서 시작: 루트 노드에서 검색할 키 값과 노드 내 키 값들을 비교합니다. 검색 키가 노드 내 키들보다 작으면 왼쪽 자식 노드로, 크면 오른쪽 자식 노드로 이동합니다.
2. 재귀적 탐색: 선택된 자식 노드에서 동일한 과정을 반복하여 리프 노드에 도달하거나 검색 키를 찾을 때까지 탐색을 진행합니다.
3. 키 발견 또는 실패: 리프 노드에서 검색 키를 발견하면 검색에 성공한 것이고, 발견하지 못하면 해당 키가 트리에 없는 것이므로 검색에 실패한 것입니다.

삽입 방법

B트리에 새 키를 삽입할 때는 먼저 적절한 리프 노드를 찾고, 그 노드에 여유 공간이 있으면 삽입하고, 없으면 노드를 분할하여 상위 노드로 중간값을 올리는 과정을 거치게 됩니다.
1. 적절한 리프 노드 찾기 : 삽입하려는 키에 대해 조회 과정을 수행하여 적절한 리프 노드를 찾습니다.
2. 리프 노드에 삽입 : 해당 리프 노드에 여유 공간이 있다면 키를 삽입합니다.
3. 노드 분할 : 여유 공간이 없다면 노드를 분할하여 새로운 키와 기존 키들을 두 노드에 분배합니다. 중간값은 상위 노드로 올라갑니다.
4. 재귀적 분할 : 상위 노드도 꽉 차 있다면 이 과정을 재귀적으로 반복하여, 필요한 경우 루트까지 분할합니다.

삽입 예제

차수(M)가 3인 B트리를 통해 삽입 과정 및 노드 분할을 설명하겠습니다.

               [10, 20]
              /    |    \
           [5]   [15]   [25, 30]

삽입 시 노드 분할이 일어나지 않는 경우

'17' 삽입 과정
- 적절한 리프 노드 찾기
  - 루트 노드 [10, 20]에서 17은 10과 20 사이에 위치하므로, 중간 자식 노드 [15]로 이동합니다.
- 리프 노드 삽입
  - 리프 노드 [15]에 17을 삽입하면 [15, 17]이 됩니다.
  - 리프 노드에 여유 공간이 있어 17을 바로 삽입할 수 있습니다.
- 노드 분할 없이 삽입 완료
  - 리프 노드에 바로 삽입이 가능하므로 노드 분할 과정 없이 삽입이 완료됩니다.
```
       [10,    20]
      /     |     \
   [5]   [15, 17] [25, 30]
```

삽입 시 노드 분할이 일어나는 경우

'22' 삽입 과정
- 적절한 리프 노드 찾기
  - '22'는 루트 노드 [10, 20]를 거쳐 리프 노드 [25, 30]로 이동합니다.
- 리프 노드 삽입 시도
  - 리프 노드 [25, 30]에 '22'를 삽입하려 하지만, 이미 최대 키 수(2개)를 가지고 있어 노드 분할이 필요합니다.
```
       [10,    20]
      /     |     \
   [5]   [15, 17] [22, 25, 30]
```
- 노드 분할 준비
  - [22, 25, 30]에서 중간값 '25'를 기준으로 노드 분할을 준비합니다.
- 분할 실행
  - 왼쪽 새 노드 [22], 오른쪽 새 노드 [30]이 생성됩니다.
  - 중간값 '25'는 상위 노드로 이동합니다.
```
       [10,   20,   25]
      /    |      |    \
   [5]   [15,17] [22]  [30]
```
- 루트 노드 분할
  - 루트 노드 [10, 20, 25]도 최대 키 수(2개)를 넘어서므로 중간값 '20'을 기준으로 분할합니다.
  - 분할 결과 '20'이 새로운 루트 노드가 되고, [10]과 [25]가 자식 노드가 됩니다.
```
         [20]
        /       \
   [10]        [25]
  /    |      /    \
[5]   [15,17] [22]  [30]
```

삭제 방법

먼저 삭제할 키를 찾고, 그 키를 삭제한 후 트리의 균형이 깨지면 인접 노드들과 병합하거나 키를 재분배하여 균형을 유지하는 작업을 수행하게 됩니다.
- 키 위치 찾기
  - 삭제하려는 키의 위치를 트리에서 탐색하여 찾습니다.
- 키 삭제
  - 키가 리프 노드에 있다면 그 노드에서 바로 삭제합니다.
  - 키가 내부 노드에 있다면, 그 키를 리프 노드로 내리고 리프 노드에서 삭제합니다.
- 트리 균형 조정
  - 키 삭제 후 해당 노드의 키 개수가 최소 요구 개수(M/2 - 1) 미만이 되면 트리의 균형을 맞추기 위해 조정이 필요합니다.
  - 인접한 노드와 병합(merge)하거나 키를 재배치(redistribution)하여 균형을 맞춥니다.

리프 노드에서 삭제하는 경우

키 삭제 후 노드의 키 개수가 최소 개수 이상인 경우

단순히 해당 키를 삭제하면 됩니다.

트리 재조정이 필요하지 않습니다.

    # 키(17) 삭제

                  [20]
                /       \
            [10]        [25]
          /    |       /    \
       [5]   [15,17] [22]  [30]

                  [20]
                /       \
           [10]        [25]
          /    |      /    \
       [5]   [15]   [22]  [30]

키 삭제 후 노드의 키 개수가 최소 개수 미만인 경우

A. 형제 노드의 키 개수가 최소 개수를 초과하는 경우

삭제하려는 키를 부모의 키로 대체합니다.

왼쪽 형제라면 왼쪽 형제의 가장 큰 값을, 오른쪽 형제라면 오른쪽 형제의 가장 작은 값을 부모 키로 대체합니다.

    # 키(5) 삭제
                   [20]
                /       \
             [10]        [25]
          /    |        /    \
       [5]   [15,17] [22]  [30]

                  [20]
                /       \
           [15]        [25]
          /    |      /    \
       [10]   [17] [22]   [30]

B. 형제 노드의 키 개수도 최소 개수인 경우

a) 부모 노드의 키 개수가 최소 개수를 초과하는 경우

키를 삭제하고 부모 키를 내려 형제 노드와 병합합니다.

  # 키(13) 삭제
                      [20]
                   /        \
           [10, 15]         [25]
          /    |   \      /    \
       [5]   [13] [17] [22]   [30]

                 [20]
               /      \
           [15]       [25]
          /   \      /    \
      [5, 10] [17] [22]   [30]

b) 부모 노드의 키 개수도 최소 개수인 경우
1. 키를 삭제합니다.
2. 삭제된 키의 부모 노드의 키를 인접한 형제 노드에 붙입니다.
3. 만약 새로 구성된 형제 노드가 최대 키 개수를 넘어갔다면, 삽입 연산에 따른 노드 분할 과정을 수행합니다.
4. 형제 노드가 최대 키 개수를 넘지 않았지만, 부모 노드의 키 개수가 최소 개수를 만족하지 못한다면, 부모 키를 기준으로 2번을 다시 진행합니다.
5. 삽입에 따른 분할 과정을 수행합니다.
```
 # 키(22) 삭제
                   [20]
                 /        \
         [10, 15]        [25]
        /    |   \      /    \
     [5]   [13] [17] [22]   [30]
```
```
                   [20]
                /        \
          [10, 15]       []
        /    |    \        \
     [5]   [13]  [17]      [25, 30]
```
```
         [10, 15, 20]
        /    |   \    \
     [5]   [13] [17]  [25, 30]
```
```
              [15]
             /    \
         [10]      [20]
        /   \     /    \
     [5]   [13] [17]    [25, 30]
```

내부 노드에서 삭제하는 경우

리프 노드에 있는, 삭제하려는 키의 선임자 또는 후임자 키와 위치를 바꿉니다.
- 선임자 : 나보다 작은 데이터들 중 가장 큰 데이터
- 후임자 : 나보다 큰 데이터들 중 가장 작은 데이터

리프 노드에서 키 삭제

위치가 바뀐 선임자 또는 후임자 키를 리프 노드에서 삭제합니다.

이때 리프 노드에서의 삭제 방식은 앞서 설명한 리프 노드 삭제 규칙을 따릅니다.

    # 키(10) 삭제
                  [20]
                /       \
             [10]      [25]
          /    |      /    \
       [5]   [15,17] [22]  [30]

                 [20]
                /       \
            [15]       [25]
          /    |      /    \
       [5]   [10, 17] [22]  [30]

                [20]
              /       \
           [15]        [25]
          /    |      /    \
       [5]   [17]   [22]  [30]

[Python] 리스트(List), 튜플(Tuple), 셋(Set), 딕셔너리(Dictionary)의 차이

운호(Noah) — Tue, 12 Mar 2024 11:23:45 +0900

리스트(List)

가변(Mutable) : 요소의 추가, 삭제, 변경이 가능합니다.
대괄호 []를 사용하여 생성합니다.
중복된 요소를 가질 수 있습니다.
순서가 있어 인덱스를 통해 요소에 접근 가능합니다.
주로 동적인 데이터 관리에 사용됩니다.

my_list = [1, 2, 3]
my_list.append(4)    # 추가
my_list[1] = 5       # 변경
del my_list[0]       # 삭제

튜플(Tuple)

불변(Immutable) : 한 번 생성된 후에는 요소의 추가, 삭제, 변경이 불가능합니다.
소괄호 ()를 사용하여 생성합니다.
중복된 요소를 가질 수 있습니다.
순서가 있어 인덱스를 통해 요소에 접근 가능합니다.
주로 데이터의 불변성이 필요한 경우에 사용됩니다.

my_tuple = (1, 2, 3)
# my_tuple.append(4)   # 에러 발생 - 튜플은 변경 불가능
# my_tuple[1] = 5      # 에러 발생 - 튜플은 변경 불가능

셋(Set)

가변(Mutable) : 요소의 추가, 삭제가 가능합니다.
중괄호 {}를 사용하여 생성합니다.
중복된 요소를 허용하지 않습니다.
순서가 없어 인덱스를 통한 접근이 불가능합니다.
주로 고유한 값들을 저장하고 중복을 허용하지 않는 경우에 사용됩니다.

my_set = {1, 2, 3}
my_set.add(4)    # 추가
my_set.remove(2) # 제거

딕셔너리(Dictionary)

가변(Mutable) : 키-값 쌍을 추가, 삭제, 변경할 수 있습니다.
중괄호 {}를 사용하여 생성하며, 각 키-값은 콜론 :으로 구분됩니다.
키는 중복되지 않아야 하며, 값은 중복이 가능합니다.
순서가 없어 인덱스를 통한 접근이 불가능하며, 키를 통해 값을 참조합니다.
데이터의 키-값 쌍을 저장하고 검색하는데 사용됩니다.

my_dict = {'key1': 'value1', 'key2': 'value2'}
my_dict['key3'] = 'value3'  # 추가
del my_dict['key1']         # 삭제

[Airflow] Xcoms란?

운호(Noah) — Fri, 8 Mar 2024 14:20:19 +0900

Xcoms란?

XComs(Cross-Communications)는 Apache Airflow에서 태스크 간에 메시지나 데이터를 교환하기 위한 메커니즘입니다.
Xcoms를 통해 한 태스크가 생성한 데이터를 다른 태스크가 사용할 수 있으며, 이는 태스크 간의 의존성 관리와 데이터 공유에 매우 유용합니다.
XComs는 Key-Value 쌍으로 데이터를 저장하며, Airflow의 메타데이터 데이터베이스에 저장됩니다.

예제 코드

태스크에서 데이터를 XCom에 push하는 가장 간단한 방법은 태스크의 실행 함수에서 값을 반환하는 것입니다. Airflow는 반환된 값을 자동으로 XCom에 push합니다.


  @task
  def push_task():
      # XCom으로 메시지를 push
      return 'Hello from the push side!'

  @task
  def pull_task(**kwargs):
      # XCom에서 메시지를 pull
      message = kwargs['ti'].xcom_pull(task_ids="push_task")
      print(f"Received message: {message}")

보다 세밀한 데이터 관리가 필요할 땐, 키-값 쌍을 지정해서 XCom에 Push 할 수도 있습니다.

  @task
  def push_task(**kwargs):
      # 키를 지정하여 XCom으로 메시지를 push
      message = 'Hello from the push side!'
      kwargs['ti'].xcom_push(key='message', value=message)

  @task
  def pull_task(**kwargs):
      # 지정된 키로 XCom에서 메시지를 pull
      message = kwargs['ti'].xcom_pull(task_ids="push_task", key='message')
      print(f"Received message: {message}")

[Airflow] ShortCircuitOperator란?

운호(Noah) — Fri, 8 Mar 2024 11:09:45 +0900

ShortCircuitOperator란?

지정된 조건이 참(True)일 때만 다운스트림 작업을 실행하는 Operator입니다.
지정된 조건이 거짓(False)이라면, ShortCircuitOperator는 다운스트림 작업의 실행을 건너뜁니다.

ignore_downstream_trigger_rules 설정

ShortCircuitOperator가 거짓(False)된 조건으로 인하여 다운스트림 작업을 건너뛸 때,
다운스트림 작업들의 트리거 규칙을 무시할 것인지 결정하는 설정입니다.
- ignore_downstream_trigger_rules=True를 적용한 경우 (기본 설정)
  - 조건이 참(True)일 때 : ShortCircuitOperator 뒤에 오는 모든 다운스트림 작업을 실행합니다.
  - 조건이 거짓(False)일 때 : 모든 다운스트림을 건너뜁니다.
- ignore_downstream_trigger_rules=False를 적용한 경우
  - 조건이 참(True)일 때 : ShortCircuitOperator 뒤에 오는 모든 다운스트림 작업을 실행합니다.
  - 조건이 거짓(False)일 때 : 특정 트리거 룰이 있는 다운스트림을 제외한 모든 다운스트림을 건너뜁니다.

예제 코드

ignore_downstream_trigger_rules=True를 적용한 경우

short_circuit Task의 조건이 참(True)이면, ShortCircuitOperator 뒤에 오는 모든 다운스트림 작업을 실행합니다.

  @task.short_circuit(ignore_downstream_trigger_rules=True)
  def step_1():
      return True

  @task
  def step_2():
      return "step_2"

short_circuit Task의 조건이 거짓(False)이면, 모든 다운스트림을 건너뜁니다.

  @task.short_circuit(ignore_downstream_trigger_rules=True)
  def step_1():
      return False

  @task
  def step_2():
      return "step_2"

ignore_downstream_trigger_rules=False를 적용한 경우

short_circuit Task의 조건이 참(True)이면, ShortCircuitOperator 뒤에 오는 모든 다운스트림 작업을 실행합니다.

  @task.short_circuit(ignore_downstream_trigger_rules=False)
  def step_1():
      return True

  @task
  def step_2():
      return "step_2"

short_circuit Task의 조건이 거짓(False)이면, 특정 트리거 룰이 있는 다운스트림을 제외한 모든 다운스트림을 건너뜁니다.

  @task.short_circuit(ignore_downstream_trigger_rules=False)
  def step_1():
      return False

  @task
  def step_2():
      return "step_2"

  # NONE_FAILED = 이전 단계들이 모두 성공 또는 스킵일 경우에만 실행
  @task(trigger_rule=TriggerRule.NONE_FAILED) 
  def step_3():
      return "step_3"

참고

https://airflow.apache.org/docs/apache-airflow/stable/_modules/airflow/operators/python.html#ShortCircuitOperator

[Terraform] GCP Load Balancer에 특정 IP만 접근 허용하는 방법

운호(Noah) — Thu, 7 Mar 2024 17:10:53 +0900

들어가기 앞서,

해당 포스팅에선 Terraform을 통해, GCP Load Balancer에 특정 IP 접근만 허용하는 방법에 대해서 다뤄보겠습니다.
결론부터 말씀드리면, Google Cloud Armor security policy를 google_compute_backend_service에 연결하는 방식으로 접근 제어를 설정할 수 있습니다.
- google_compute_backend_service는 Google Cloud Load Balancing 사용 시, 트래픽을 여러 인스턴스 그룹에 분산하는 데 사용되는 리소스이며, 해당 리소스의 추가적인 설명은 아래 링크를 참고하시면 됩니다.
  - https://wooono.tistory.com/699
- Google Cloud Armor security policy는 google_compute_security_policy로 생성할 수 있습니다.

예제 코드

먼저, Google Cloud Armor security policy를 생성합니다.

  resource "google_compute_security_policy" "my_security_policy" {
    name = "my-security-policy"

    rule {
      action   = "allow"
      priority = 1000
      match {
        versioned_expr = "SRC_IPS_V1"
        config {
          src_ip_ranges = ["<YOUR_IP_RANGE>"]
        }
      }
    }
  }

<YOUR_IP_RANGE>는 허용하려는 IP 범위입니다.
예를 들어, ["192.168.1.0/24"]처럼 설정할 수 있습니다.
이 정책은 지정된 IP 범위에서의 접근만을 허용합니다.

이제 google_compute_backend_service를 생성하고, 앞서 생성한 security policy를 적용합니다.

  resource "google_compute_backend_service" "my_backend_service" {
    name        = "my-backend-service"
    protocol    = "HTTP"
    port_name   = "http"
    timeout_sec = 10

    backend {
      group = google_compute_instance_group.my_instance_group.self_link
    }

    security_policy = google_compute_security_policy.my_security_policy.self_link
  }

google_compute_instance_group.my_instance_group.self_link 부분은 실제 인스턴스 그룹의 Terraform 리소스 ID로 교체해야 합니다.

참고

https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_backend_service#security_policy

[GCP] Pub/Sub Topic에 Message를 Publish 하는 방법 with Python

운호(Noah) — Thu, 7 Mar 2024 16:46:38 +0900

들어가기 앞서,

해당 포스팅에선 GCP Pub/Sub Topic에 Message를 Publish하는 간단한 예제 코드를 다뤄보겠습니다.
테스트를 위한 간단한 코드이기 때문에, 필요에 따라 수정해서 사용하시면 됩니다 ㅎㅎ..

예제 코드

from google.cloud import pubsub_v1
import json

# 프로젝트 ID 및 서비스 계정 키 파일 경로 설정
project_id = "your-project-id"
key_file_path = "path/to/your/service-account-file.json"

# Pub/Sub 클라이언트 초기화
pubsub_client = pubsub_v1.PublisherClient.from_service_account_file(key_file_path)

# 토픽 이름 설정
pub_name = "your-topic-name"

# 테스트 데이터 준비
push_test_data = {
    "key": "value"
}

# 데이터를 JSON 형식으로 인코딩
json_data = json.dumps(push_test_data)
data = json_data.encode('utf-8')

# 토픽 경로 생성 및 메시지 게시
topic_path = pubsub_client.topic_path(project_id, pub_name)
future = pubsub_client.publish(topic_path, data=data)

# 게시 결과 확인
future.result()

참고

https://cloud.google.com/pubsub/docs/publisher?hl=ko#publish-messages

[DP] 백준 2011번 “암호코드” Python 풀이

운호(Noah) — Sun, 3 Dec 2023 16:10:30 +0900

문제 링크

https://www.acmicpc.net/problem/2011

풀이

마지막 숫자까지 해석할 수 있는 경우의 수는 아래 두 가지 경우의 수의 합과 같습니다.
- 마지막 1개 숫자 이전의 숫자들로 가능했던 경우의 수
- 마지막 2개 숫자 이전의 숫자들로 가능했던 경우의 수
따라서, “251”을 해석할 수 있는 경우의 수는 아래 두가지 경우의 수의 합과 같습니다.
- “마지막 1개 숫자 이전의 숫자들로 가능했던 조합” + “1”
  - 즉, “25”의 경우의 수와 동일합니다.
  - 마지막 1개의 숫자가 0 이상이기 때문에 가능합니다.
- “마지막 2개 숫자 이전의 숫자들로 가능했던 조합” + “51”
  - 즉, “2”의 경우의 수와 동일합니다.
  - 해당 경우엔 마지막 2개의 숫자가 10 이상 26 이하가 아니기 때문에 불가능합니다.
다음으로, “2511”을 해석할 수 있는 경우의 수는 아래 두 가지 경우의 수의 합과 같습니다.
- “마지막 1개 숫자 이전의 숫자들로 가능했던 조합” + “1”
  - 즉, “251”의 경우의 수와 동일합니다.
  - 마지막 1개의 숫자가 0 이상이기 때문에 가능합니다.
- “마지막 2개 숫자 이전의 숫자들로 가능했던 조합” + “11”
  - 즉, “25”의 경우의 수와 동일합니다.
  - 마지막 2개의 숫자가 10 이상 26 이하이기 때문에 가능합니다.
마지막으로, “25114”를 해석할 수 있는 경우의 수는 아래 두 가지 경우의 수의 합과 같습니다.
- “마지막 1개 숫자 이전의 숫자들로 가능했던 조합” + “4”
  - 즉, “2511”의 경우의 수와 동일합니다.
  - 마지막 1개의 숫자가 0 이상이기 때문에 가능합니다.
- “마지막 2개 숫자 이전의 숫자들로 가능했던 조합” + “14”
  - 즉, “251”의 경우의 수와 동일합니다.
  - 마지막 2개의 숫자가 10 이상 26 이하이기 때문에 가능합니다.

코드

import sys

number = list(map(int, sys.stdin.readline().rstrip()))

# dp[i] => i번째 숫자까지 해석할 수 있는 경우의 수
dp = [0] * (len(number)+1)
dp[0] = 1
dp[1] = 1 # 1번째 숫자까지 해석할 수 있는 경우의 수는 1이므로 미리 계산

# 암호가 잘못되어 해석할 수 없는 경우 (첫 번째 숫자가 0일 경우)
if (number[0] == 0):
    print(0)
else:
    for i in range(1, len(number)):

        # dp[0]이 사용되고 있으므로 dp 접근용 idx 재선언
        j = i+1

        if (number[i] > 0):     # 마지막 1개의 숫자가 0이면 대응되는 문자가 없음
            dp[j] += dp[j-1]    # 마지막 1개 숫자 이전의 숫자들로 가능했던 경우의 수와 동일하기 때문에, 해당 경우의 수를 더해주기

        if (10 <= 10 * number[i-1] + number[i] <= 26): # 마지막 2개의 숫자가 10 이상 26 이하라면
            dp[j] += dp[j-2]    # 마지막 2개 숫자 이전의 숫자들로 가능했던 경우의 수와 동일하기 때문에, 해당 경우의 수를 더해주기

    print(dp[-1]%1000000)

참고

https://velog.io/@jxlhe46/백준-2293번.-동전-1-bfi120m5

[DP] 백준 2293번 “동전 1” Python 풀이

운호(Noah) — Sat, 2 Dec 2023 19:38:42 +0900

문제 링크

https://www.acmicpc.net/problem/2293

풀이

우선, 동전 1원으로 10을 만들 수 있는 경우의 수와
동전 1, 2원으로 10을 만들 수 있는 경우의 수를 구함으로써 규칙을 찾을 수 있습니다.
즉, 새로 갱신되는 dp[n]의 값은 이전의 dp[n]의 값에 dp[n - 현재 사용한 동전의 종류 크기] 가 됩니다.
해당 규칙을 통해 1, 2, 5원으로 10을 만들 수 있는 경우의 수를 계산할 수 있습니다.
추가적으로, dp[0]은 주어진 동전을 통해 0원을 만들 수 있는 경우의 수인데,
아무 동전을 사용하지 않았을 때 0을 만들 수 있으므로, 경우의 수는 1입니다.

코드

import sys

n, k = map(int, sys.stdin.readline().split())

coins = []
for _ in range(n):
    coins.append(int(sys.stdin.readline()))

dp = [0] * (k+1)
dp[0] = 1

for coin in coins:
    for j in range(coin, k+1):
        dp[j] = dp[j] + dp[j-coin]

print(dp[k])

참고

https://velog.io/@jxlhe46/백준-2293번.-동전-1-bfi120m5

[Greedy] 백준 17609번 “회문” Python 풀이

운호(Noah) — Sun, 26 Nov 2023 16:03:11 +0900

문제 링크

https://www.acmicpc.net/problem/17609

풀이

왼쪽 포인터 값과 오른쪽 포인터 값이 동일할 경우, 양쪽 포인터를 그 다음 포인터로 이동
왼쪽 포인터 값과 오른쪽 포인터 값이 동일하지 않을 경우
- 왼쪽 포인터를 오른쪽으로 이동했을 때, 양쪽 포인터 내부 문자열이 회문이 되는지 확인
- 오른쪽 포인터를 왼쪽으로 이동했을 때, 양쪽 포인터 내부 문자열이 회문이 되는지 확인
- 나머지 경우(회문이나 유사회문도 아닌 일반 문자열인 경우)

코드

import sys

t = int(sys.stdin.readline())

for i in range(t):

    result = 0

    str = list(sys.stdin.readline().rstrip())

    left_idx = 0
    right_idx = len(str)-1

    while (left_idx < right_idx):

        # 왼쪽 포인터 값과 오른쪽 포인터 값이 동일할 경우
        if (str[left_idx] == str[right_idx]):
            left_idx += 1
            right_idx -= 1

        # 왼쪽 포인터 값과 오른쪽 포인터 값이 동일하지 않을 경우
        else:
            # 왼쪽 포인터를 오른쪽으로 이동했을 때, 양쪽 포인터 내부 문자열이 회문이 되는지 확인
            if (str[left_idx+1:right_idx+1] == str[left_idx+1:right_idx+1][::-1]):
                result = 1
                break

            # 오른쪽 포인터를 왼쪽으로 이동했을 때, 양쪽 포인터 내부 문자열이 회문이 되는지 확인
            elif (str[left_idx:right_idx] == str[left_idx:right_idx][::-1]):
                result = 1
                break

            # 회문이나 유사회문도 아닌 일반 문자열인 경우
            else:
                result = 2
                break

    print(result)

[Greedy] 백준 2812번 “크게 만들기” Python 풀이

운호(Noah) — Sat, 25 Nov 2023 20:08:53 +0900

문제 링크

https://www.acmicpc.net/problem/2812

풀이

큰 수가 되려면 높은 자리수의 숫자가 커야합니다.
그래서 스택을 이용합니다.
예를 들어, 4177252841 이고 k = 4이면 775841이 최대값이겠죠?
먼저 4를 stack에 집어넣습니다.
- stack = [4]
다음 1을 stack에 넣어야 하는데, stack의 최근 값인 4보다 1이 작거나 같죠? 그래서 그냥 stack에 1을 넣습니다.
- stack = [4, 1]
다음 7을 stack에 넣어야 하는데, stack의 최근 값인 1보다 7이 크죠? 그래서 1을 pop 합니다.
- stack = [4], k = 3
아직 stack의 최근 값인 4보다 7이 크죠? 그래서 4를 pop 합니다.
- stack = [], k = 2
이제 stack에 7을 집어넣습니다.
- stack = [7]
다음 7을 stack에 넣어야 하는데, stack의 최근 값인 7보다 7이 작거나 같죠? 그래서 그냥 stack에 7을 넣습니다.
- stack = [7, 7]
다음 2를 stack에 넣어야 하는데, stack의 최근 값인 7보다 2가 작거나 같죠? 그래서 그냥 stack에 2를 넣습니다.
- stack = [7, 7, 2]
다음 5를 stack에 넣어야 하는데, stack의 최근 값인 2보다 5가 크죠? 그래서 2를 pop하고 5를 넣습니다.
- stack = [7, 7, 5], k = 1
다음 2를 stack에 넣어야 하는데, stack의 최근 값인 5보다 2가 작거나 같죠? 그래서 그냥 2를 넣습니다.
- stack = [7, 7, 5, 2]
다음 8을 stack에 넣어야 하는데, stack의 최근 값인 2보다 8이 크죠? 그래서 2를 pop 합니다.
- stack = [7, 7, 5], k = 0
이제 k=0 이므로 나머지 숫자들은 그냥 추가합니다.
- stack = [7, 7, 5, 8, 4, 1]

코드

import sys

N, K = map(int, sys.stdin.readline().split())
num = list(sys.stdin.readline())
k = K # 기존 K 값 저장
stack = []

for i in range(len(num)):
    # 뺄 수 있는 횟수가 남아있고, 스택의 값이 남아있고, 현재 값이 stack의 최근값보다 클 경우 POP
    while (k > 0 and stack and num[i] > stack[-1]):
        stack.pop()
        k -= 1
    # 그 외 경우엔 현재 값을 stack에 삽입
    stack.append(num[i])

# 예외 케이스) 5 2 / 19876 일 경우, 답은 987
print("".join(stack[:N-K]))

[K8S] 리소스를 생성하지 않고 리소스 구성 파일만 출력

운호(Noah) — Tue, 21 Nov 2023 17:15:09 +0900

리소스를 생성하지 않고 리소스 구성 파일만 출력

kubectl 시, 리소스를 생성하지 않고 리소스 구성 파일만 출력할 수 있는 옵션이 있습니다.
```
  kubectl run redis \
  --image=redis \
  --dry-run=client \
  -o yaml \
  > redis-definition.yaml
```
- --dry-run=client : 명령어를 실행하지 않고 구성만을 출력합니다.
- -o yaml : 출력 형식을 YAML로 지정합니다.
- > redis-definition.yaml : 명령어의 출력을 파일에 저장합니다.

[Airflow] StatsD Exporter + Prometheus + Grafana On GKE

운호(Noah) — Fri, 17 Nov 2023 17:27:25 +0900

들어가기 앞서,

Airflow 운영에 있어서 Airflow 모니터링은 중요한 요소이며, 모니터링은 크게 두 가지 측면으로 구분할 수 있습니다.
- 서비스 측면 (Airflow 컨테이너 동작 여부, DAG 정상 실행 여부 등)
- 시스템 측면 (CPU, Memory 등)
해당 포스팅에선 Airflow의 서비스 측면 모니터링을 위해, StatsD Exporter + Prometheus + Grafana를 구성하는 방법에 대해서 다뤄보겠습니다.
- StatsD Exporter
  - StatsD는 애플리케이션에서 발생하는 이벤트 및 성능 지표를 수집하고, 이를 모니터링 시스템에 전송하는 데 사용되는 네트워크 데몬 및 프로토콜입니다.
  - Airflow 내부적으로 생성된 Metric은, StatsD를 통해 StatsD Exporter에 Push 됩니다.
  - StatsD Exporter는 StatsD에서 전송된 메트릭을 Prometheus가 이해할 수 있는 형식으로 변환하여 제공하는 중간자 역할입니다.
- Prometheus
  - Prometheus는 모니터링 시스템 및 Timeseries 데이터용 데이터베이스입니다.
  - 오픈소스로, 메트릭 수집 및 대시보드를 구축하는데 Grafana와 함께 많이 사용합니다.
- Grafana
  - Grafana는 대시보드 툴입니다.
  - 시계열 데이터에 대한 대시보드에 특화되어 있는 대시보드 툴이며 Graphite, InfluxDB, Prometheus 등을 지원합니다.

사전 구성 환경

Airflow와 Grafana는 GKE에 Helm Chart를 통해 설치되어 있으며, 설치 과정은 생략하겠습니다.
- Airflow Helm Chart : https://github.com/airflow-helm/charts
- Grafana Helm Chart : https://grafana.github.io/helm-charts

StatsD Exporter + Prometheus + Grafana 구조

Airflow 내부적으로 생성된 Metric은, StatsD를 통해 StatsD Exporter에 Push 됩니다.
StatsD Exporter는 StatsD로부터 받은 Metric을 저장해둡니다.
Prometheus는 StatsD Exporter가 저장하고 있는 Airflow Metric을 주기적으로 Scrape(Pull) 합니다.
Grafana는 Prometheus에 저장된 Airflow Metric을 Pull 하여 대시보드를 구성합니다.

진행 순서

StatsD Exporter 사용을 위한 Airflow Helm Chart Value 설정
Prometheus 관련 자원 생성 및 StatsD Exporter Scrape 설정
- Prometheus 자원 생성은 Terraform을 통해 진행하겠습니다.
Grafana의 Datasource로 Prometheus 추가

StatsD Exporter 사용을 위한 Airflow Helm Chart Value 설정

Airflow가 StatsD Exporter에 Metric을 보내도록 설정합니다.

  airflow:
    config:
      AIRFLOW__METRICS__STATSD_ON: 'true'
      AIRFLOW__METRICS__STATSD_HOST: 'localhost'
      AIRFLOW__METRICS__STATSD_PORT: '9125'

Airflow의 Webserver, Scheduler, Worker Pod에 StatsD Exporter가 extracontainer(sidecar)로 동작하도록 설정합니다.

  airflow:
    extraContainers:
      - name: prometheus-statsd-exporter
        image: prom/statsd-exporter:latest
        imagePullPolicy: Always
        args:
          - --web.listen-address=:9102
          - --statsd.listen-udp=:9125
        ports:
          - containerPort: 9102
            protocol: TCP
          - containerPort: 9125
            protocol: UDP
          - containerPort: 9125
            protocol: TCP

Prometheus는 StatsD Exporter의 URL 주소(K8S Service DNS)를 통해 Metric을 Scrape(Pull) 해야하므로, extramanifests를 사용해 Webserver, Scheduler, Worker의 StatsD Exporter 용 Service를 생성합니다.
```
  extraManifests:
    - apiVersion: v1
      kind: Service
      metadata:
        name: scheduler-statsd-exporter
      spec:
        selector:
          app: airflow
          component: scheduler
        ports:
          - port: 9102
            targetPort: 9102
```
- Webserver와 Worker의 Service 생성 코드는 생략하겠습니다.
이후, 생성한 StatsD Exporter의 Service DNS에 /metrics 경로를 추가하여, StatsD Exporter가 Airflow의 Metric을 잘 받아오고 있는지 확인할 수 있습니다.
- 해당 예제에선 “http://scheduler-statsd-exporter.default.svc.cluster.local:9102/metrics” 경로를 통해 확인할 수 있습니다.
Airflow Helm Chart Value는 아래 링크를 통해 참조하실 수 있습니다.
- https://github.com/airflow-helm/charts/blob/main/charts/airflow/values.yaml

Prometheus 관련 자원 생성 및 StatsD Exporter Scrape 설정

kubernetes_config_map 생성
```
  resource "kubernetes_config_map" "prometheus_config" {
    metadata {
      name = "prometheus-config"
    }

    data = {
      "prometheus.yml" = <<EOF
  global:
    scrape_interval: 30s
    evaluation_interval: 30s
    scrape_timeout: 10s

  scrape_configs:
    - job_name: 'airflow-scheduler-metric'
      static_configs:
        - targets: ['scheduler-statsd-exporter.default.svc.cluster.local:9102']
  EOF
    }
  }
```
- Deployment를 통해 Prometheus Container가 시작될 때,
- Prometheus가 기본 설정 파일(prometheus.yml)을 Container 내부에서 찾아서 실행될 수 있도록,
- Prometheus Container 내부에 마운트할 파일을 kubernetes_config_map을 통해 정의합니다.
- Prometheus 기본 설정 파일(prometheus.yml) 작성 방법은 아래 링크를 참조하실 수 있습니다.
  - https://prometheus.io/docs/prometheus/latest/configuration/configuration/
- 위 예제의 scrape_configs에는 Scheduler의 StatsD Exporter만 scrape하도록 설정되어있으며,
- Webserver와 Worker의 StatsD Exporter를 Scrape하는 코드는 생략하겠습니다.

Prometheus Deployment 생성

  resource "kubernetes_deployment" "prometheus" {
    metadata {
      name = "prometheus"
    }
    spec {
      replicas = 1
      selector {
        match_labels = {
          app = "prometheus"
        }
      }
      template {
        metadata {
          labels = {
            app = "prometheus"
          }
        }
        spec {
          container {
            image = "prom/prometheus"
            name  = "prometheus"
            args = [
              "--config.file=/etc/prometheus/prometheus.yml"
            ]
            port {
              container_port = 9090
            }
            volume_mount {
              mount_path = "/etc/prometheus/"
              name       = "prometheus-config-volume"
            }
          }
          volume {
            name = "prometheus-config-volume"
            config_map {
              name = kubernetes_config_map.prometheus_config.metadata[0].name
            }
          }
        }
      }
    }
  }

kubernetes_config_map이 Prometheus Container 내부로 volume mount 될 수 있도록 설정한 뒤,
Prometheus가 기본 설정 파일을 Container 내부에서 찾아 실행될 수 있도록,
Prometheus Container 실행 인자로 기본 설정 파일의 경로를 넣어줍니다.

Prometheus Service 생성

  resource "kubernetes_service" "prometheus" {

    metadata {
      name = "prometheus"
    }
    spec {
      type = "ClusterIP"
      selector = {
        app = "prometheus"
      }
      port {
        port        = 9090
        target_port = 9090
      }
      session_affinity = "None"
    }
  }

Grafana가 Prometheus의 Service DNS 주소를 통해 Prometheus를 Datasource로 등록할 수 있도록 Prometheus 용 Service를 생성합니다.

Grafana의 Datasource로 Prometheus 추가

Grafana 대시보드 접근 → 좌측 톱니바퀴 클릭
Data sources 카테고리에서 “Add new data source” 클릭 → “Prometheus” 선택
Prometheus Data source의 Name을 지정
HTTP URL에 Prometheus의 Service DNS를 삽입
- 해당 예제에선 “http://prometheus.default.svc.cluster.local:9090” 입니다.
Save & test 클릭
이후, 대시보드를 생성한 뒤 Data source를 Prometheus로 지정하고 원하는 패널을 만들면 됩니다.

참고

[Terraform] 특정 리소스의 변경사항만 apply 하는 방법

운호(Noah) — Fri, 17 Nov 2023 14:03:01 +0900

terraform apply -target=resource_type.resource_name

terraform은 apply 시, -target 옵션을 통해 특정 리소스의 변경사항만 apply 할 수 있습니다.

예를 들어, 만약 AWS의 S3 버킷을 정의하는 Terraform 코드가 있다면

  resource "aws_s3_bucket" "example_bucket" {
    bucket = "example-bucket"
    acl    = "private"
  }

아래 명령어를 통해 해당 리소스에 대한 변경사항만을 apply 할 수 있습니다.
```
  terraform apply -target=aws_s3_bucket.example_bucket
```
- ‘aws_s3_bucket’이 Terraform에서 정의한 리소스의 타입이고,
- ‘example_bucket’이 해당 리소스의 이름입니다.

[K8S] Resource Request, Limit이란?

운호(Noah) — Thu, 16 Nov 2023 17:18:17 +0900

요약

K8S에서 Resource의 Request와 Limit은 컨테이너에 할당되는 CPU, Memory의 자원량을 의미합니다.
Request는, 컨테이너 생성 시 필요한 자원량을 의미합니다.
Limit은, 컨테이너가 이미 실행 중인 상태에서 추가 리소스가 필요한 경우에 사용할 수 있는 최대 자원량을 의미합니다.
- 이때 주의할 점은, 반드시 Limit은 Request보다 같거나 커야한다는 것입니다.
- Limit은 추가로 얼만큼의 리소스를 더 사용할 것인지가 아닌,
- 컨테이너 생성 시 필요한 자원량과 추가로 사용할 자원량을 더한 최대 자원량을 의미하기 때문입니다.
CPU와 Memory의 자원 단위는 아래와 같습니다.
- CPU : Milicore (1,000 Milicore = 1Core)
- Memory : Mbyte

K8S의 스케줄링이란?

Kubernetes에서, Pod를 어느 Node에 배포할지 결정하는 것을 스케줄링이라고 합니다.
Kubernetes 입장에서는 Pod에 필요한 자원의 양을 알아야,
해당 자원을 사용할 수 있는 Node에 Pod를 배포할 수 있게 됩니다.
- Pod는 하나 이상의 Container로 구성되므로,
- 스케줄링은 Pod의 모든 Container Request 양을 합친 값을 기준으로 진행됩니다.

Request 양을 초과 사용하면 어떻게 되는가?

Pod가 Request 양을 초과하더라도 Limit 양을 넘지 않으면 문제가 발생하지 않습니다.
다만, Node의 자원이 부족할 경우에는 Request 양을 초과한 Pod는 퇴거(Eviction)의 대상이 되어, 다른 Node에 재배치됩니다.
만약 모든 Node의 자원이 부족하다면 이 Pod는 Pending 상태로 지속 됩니다.
- 따라서, 서비스 운영 시 자원 부족에 따른 Pod의 재배치나 Pending 상태에 대응하기 위해
- Replication을 설정하거나, 특정 Node에 Pod를 한정하여 배치하는 전략 등을 고려해야 합니다.

Limit 양을 초과하여 사용하면 어떻게 되는가?

Pod가 Limit 양을 초과하면, Overcommitted 상태에 진입하게 됩니다.
- Overcommitted 상태란, 실제 사용 가능한 물리적인 자원량보다 해당 Pod에 할당된 자원량이 많은 상태를 의미합니다.
CPU가 Overcommitted 될 경우, CPU는 throttling을 통해 실제 CPU 사용량을 Request에 정의된 상태까지 낮추게 됩니다.
- 예를 들어, Request가 100, Limit이 500인 경우, 현재 500으로 가동되고 있는 컨테이너의 CPU할당량을 100까지 낮추게 됩니다.
- 그래도 Overcommitted 상태가 해결되지 않을 경우, 우선 순위에 따라서 운영중인 컨테이너를 강제 종료 시키게 됩니다.
Memory가 Overcommitted 될 경우, 사용중인 메모리의 크기를 줄일 수는 없기 때문에, 우선 순위에 따라서 운영 중인 컨테이너를 강제 종료 시키게 됩니다.

Request와 Limit 양을 설정하지 않으면 어떻게 되는가?

Request와 Limit 양을 설정하지 않으면, Node의 자원 전체를 사용할 수 있다는 의미와 같습니다.
개발 중에는 자원량을 설정하지 않아도 문제는 없지만,
운영 시에는 Request, Limit 양이 설정되지 않은 Pod는 정확한 스케줄링이 어렵습니다.
- 한 Node에 Pod가 초과 배치될 수도 있고,
- Node 자원 부족 시 퇴거 대상이 증가할 수도 있습니다.

ResourceQuota & LimitRange

쿠버네티스에서는 ResourceQuota를 사용해 네임스페이스별로 사용할 수 있는 리소스의 양을 지정하거나,
LimitRange를 사용해 컨테이너마다 사용할 수 있는 리소스의 양을 지정할 수 있습니다.
ResourceQuota
```
  apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: example-resourcequota
  spec:
    hard:
      requests.cpu: "1"
      requests.memory: 1Gi
      limits.cpu: "2"
      limits.memory: 2Gi
```
- Resource Quota는 네임스페이스별로 사용할 수 있는 리소스의 양을 지정합니다.
- 위 yaml 파일은, example-resourcequota라는 네임스페이스의 리소스 양을 지정한 예제입니다.
- requests.cpu : 네임스페이스 전체의 CPU Request 리소스 제한 값입니다.
- requests.memory : 네임스페이스 전체의 Memory Request 리소스 제한 값입니다.
- limits.cpu : 네임스페이스 전체의 CPU Limit 리소스 제한 값입니다.
- limits.memory : 네임스페이스 전체의 Memory Limit 리소스 제한 값입니다.
LimitRange
```
  apiVersion: v1
  kind: LimitRange
  metadata:
    name: example-limitrange
  spec:
    limits:
    - type: Container
      max:
        memory: 512Mi
        cpu: 1
      min:
        memory: 50Mi
        cpu: 100m
      default:
        memory: 128Mi
        cpu: 200m
      defaultRequest:
        memory: 64Mi
        cpu: 100m
```
- Limit Range는 컨테이너 개별 자원의 사용 가능 범위를 지정합니다.
- type : Container : 이 LimitRange는 컨테이너에 대한 제한을 정의합니다.
- max : 컨테이너의 Limit을 지정할 경우, 설정 가능한 최대 값입니다.
- min : 컨테이너의 Limit을 지정할 경우, 설정 가능한 최소 값입니다.
- default : 컨테이너의 Limit 값에 대한 기본값을 정의합니다.
- defaultRequest : 컨테이너의 Request 값에 대한 기본값을 정의합니다.

참고

[Prometheus] Config의 scrape_configs 설정 시 static_configs의 targets 설정 방법

운호(Noah) — Wed, 15 Nov 2023 15:34:38 +0900

들어가기 앞서,

해당 포스팅에선, Prometheus Config의 scrape_configs 설정 시 static_configs의 targets을 어떻게 설정해야하는지에 대해서 다뤄보겠습니다.

Prometheus Config File 예제 코드

global:
  scrape_interval: 30s
  evaluation_interval: 30s
  scrape_timeout: 10s

scrape_configs:
  - job_name: 'Test'
    static_configs:
      - targets: ['12.34.567.890:8086']

“http://12.34.567.890:8086/metrics”라는 경로에서 metrics를 scrape 해오고 싶다면,
targets에는 “http://”와 “/metrics”를 제외한 “12.34.567.890:8086”만 적어도 됩니다.
- scheme의 기본값은 “http”이며, metrics_path의 기본 경로는 “/metrics”이기 때문입니다.

[K8S] Replicaset Desired, Current, Ready란?

운호(Noah) — Wed, 15 Nov 2023 14:58:06 +0900

K8S Replicaset 상태 확인 명령어

kubectl get replicaset

Desired (원하는 수)

ReplicaSet으로 관리하길 원하는 Pod의 수를 나타냅니다.
- 사용자가 설정한 값입니다.

Current (현재 수)

실제 동작 중인 Pod의 수를 나타냅니다.

Ready (준비된 수)

사용할 준비가 완료된 Pod의 수를 나타냅니다.

참고

정상적인 환경이라면 Desired, Current, Ready 개수가 모두 동일해야합니다.

[K8S] Container Sleep 방법

운호(Noah) — Wed, 15 Nov 2023 14:28:09 +0900

들어가기 앞서,

Pod를 띄웠을 때, 에러로 인해 Pod가 지속적으로 재시작되는 경우가 있습니다.
이때 트러블 슈팅을 위해 일시적으로 Container를 유지하는 방법에 대해서 포스팅하겠습니다.

Container Sleep 적용

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu
spec:
  containers:
  - name: ubuntu
    image: ubuntu:latest
    # Just spin & wait forever
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "while true; do sleep 3600; done;" ]

정석적인 방법은 아니며, 이외에도 다양한 방법이 사용될 수 있습니다.

참고

https://stackoverflow.com/questions/31870222/how-can-i-keep-a-container-running-on-kubernetes

[K8S] Persistent Volume, Persistent Volume Claim, StorageClass란?

운호(Noah) — Sun, 5 Nov 2023 15:48:53 +0900

들어가기 앞서,

Kubernetes에서 Volume은, 3가지 구조로 사용됩니다.
- PersistentVolume(PV)
- PersistentVolumeClaim(PVC)
- StorageClass
해당 포스팅에선 PV와 PVC에 대해서 먼저 이해한 뒤, StorageClass에 대해서 이해해보겠습니다.

PV와 PVC 요약

PV
- Volume 자체를 의미합니다.
- 클러스터 내에서 독립적으로 관리되며 별도의 생명 주기를 가집니다.
- 클라우드 서비스 또는 직접 구축한 Storage와 같은 다양한 소스에서 제공되는 스토리지를 사용할 수 있습니다.
PVC
- 사용자가 PV에 요청한 정보를 의미합니다.
- 필요한 용량, 액세스 모드 등을 지정하여 PV를 요청합니다.
- Pod는 직접 PV에 연결되는 대신, PVC를 통해 스토리지에 액세스합니다.
특징
- PV는 Pod에 직접 연결되지 않고, PVC를 통해 연결됩니다.
- PV와 PVC는 클러스터 관리자가 수동으로 설정하거나 StorageClass를 사용하여 동적으로 프로비저닝할 수 있습니다.

PV와 PVC의 생명 주기

Provisioning

PV를 생성하는 단계로, 두 가지 방법으로 이루어집니다.
- 정적(Static) 프로비저닝
  - 미리 적정 용량의 PV를 생성해두는 방법입니다.
  - 사용 가능한 스토리지 용량에 제한이 있을 때 유용합니다.
  - 만약, 100GB의 용량을 가진 PV를 미리 생성해두었을 때, 150GB를 요청하는 요청은 실패하게 됩니다.
- 동적(Dynamic) 프로비저닝
  - 사용자가 PVC를 통해 PV를 요청할 때, 사용자가 필요한 용량 만큼의 PV를 동적으로 생성하는 방법입니다.
  - 필요에 따라 다양한 용량의 PV를 동적으로 생성하고 싶을 때 유용합니다.
  - 동적 프로비저닝을 위해선 StorageClass라는 K8S 리소스가 사용되며,
  - 어떤 종류의 Storage를 프로비저닝할지에 대한 규칙과 설정을 StorageClass에 정의한 뒤,
  - PVC에서 해당 StorageClass를 지정하면,
  - PVC가 생성될 때, 사용자가 필요한 용량 만큼의 PV가 동적으로 프로비저닝됩니다.

Binding

프로비저닝으로 만든 PV를 PVC와 연결하는 단계입니다.
PVC에서 필요한 스토리지의 용량과 접근 방법을 명시하여 PV를 요청하면, 해당 요청에 맞는 PV가 바인딩됩니다.
- 만약 PVC에서 요청한 조건을 만족하는 PV가 없다면, PVC는 해당 PV가 생성될 때까지 대기 상태에 있습니다.
- PV와 PVC의 매핑은 1대1 관계이며, PVC는 여러 개의 PV에 할당될 수 없습니다.

Using

Pod는 PVC를 볼륨으로 인식해서 사용합니다.
Pod에 할당된 PVC는 Pod를 유지하는 동안 계속 사용되며, 시스템에서 임의로 삭제할 수 없습니다.
이 기능은 'Storage Object in Use Protection' (사용 중인 스토리지 오브젝트 보호)로 알려져 있습니다.
사용 중인 데이터 스토리지를 임의로 삭제하는 경우 치명적인 결과가 발생할 수 있으므로 이런 보호 기능을 사용하는 것입니다.

Reclaiming

사용이 끝난 PVC를 삭제하고, 해당 PVC를 사용하던 PV를 초기화(reclaim)하는 과정을 나타냅니다.
초기화 정책에는 Retain, Delete가 있습니다.
- Retain
  - PV가 삭제되어도 PV의 데이터는 클러스터 내에 보존됩니다.
  - 관리자가 PV를 수동으로 정리하고 데이터를 보존하거나 백업하는 데 활용됩니다.
  - PV를 다시 사용하기 위해서는 수동으로 다시 바인딩해야 합니다.
- Delete
  - PV가 삭제되면 PV와 관련된 데이터도 함께 삭제됩니다.
  - 테스트 및 개발 환경에서 주로 사용되며 데이터 보존이 필요하지 않을 때 유용합니다.
  - 동적으로 프로비저닝된 PV의 반환 정책은 기본적으로 Delete이며, 필요에 따라 수정이 필요합니다.

정적 프로비저닝 예제 코드

Persistent Volume

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: example-pv
  spec:
    capacity:         # Volume 용량
      storage: 1Gi    
    accessModes:      # 접근 옵션
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain  # PV가 삭제되었을 때의 초기화 옵션
    hostPath:                              # 마운트시킬 로컬 서버의 경로
      path: /data/example-pv

Persistent Volume Claim

  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: example-pvc
  spec:
    accessModes:             # 접근 옵션
      - ReadWriteOnce
    resources:               # 자원을 얼마나 사용할 것인지 요청 (PV의 용량을 초과하면 안됨)
      requests:
        storage: 500Mi

동적 프로비저닝 예제 코드

StorageClass

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:                            
    name: example-storageclass        # StorageClass의 이름을 지정합니다.
  provisioner: kubernetes.io/gce-pd   # Google Compute Engine Persistent Disk 를 스토리지 플러그인으로 사용합니다.
  reclaimPolicy: Retain               # PV가 삭제되어도 데이터를 보존합니다.

Persistent Volume Claim

  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: example-pvc
  spec:
    accessModes:            # PV에 대한 액세스 모드를 나타냅니다.
      - ReadWriteOnce
    resources:
      requests:
        storage: 1Gi        # PVC가 요청하는 스토리지의 크기를 나타냅니다.
    storageClassName: example-storageclass  # PV가 동적으로 프로비저닝될 때 사용될 StorageClass를 나타냅니다.

Persistent Volume, Persistent Volume Claim 연결 확인 명령어

Persistent Volume Claim 연결 확인 명령어

  $ kubectl get pvc
  NAME          STATUS   VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
  example-pvc   Bound    example-pv    2Gi        RWO            manual         2m

“example-pv”라는 VOLUME에 Bound 된 것을 확인할 수 있습니다.

Persistent Volume 연결 확인 명령어
```
  $ kubectl get pv
  NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
  example-pv  5Gi        RWO            Retain           Bound    default/example-pvc manual                  3m
```
- STATUS 종류
  - Available : PVC에서 사용할 수 있도록 준비된 상태
  - Bound : 특정 PVC에 연결된 상태
  - Released : PVC는 삭제되었고 PV는 아직 초기화 되지 않은 상태
  - Failed : 자동 초기화를 실패한 상태

참고

https://kimjingo.tistory.com/153

[Istio] AuthorizationPolicy란?

운호(Noah) — Sun, 5 Nov 2023 14:37:15 +0900

들어가기 앞서,

해당 포스팅에선, Istio의 AuthorizationPolicy에 대해서 다뤄보겠습니다.

AuthorizationPolicy란?

Istio의 AuthorizationPolicy는 서비스 메시 내에서 네트워크 트래픽에 대한 엑세스 제어를 정의하는 데 사용되는 Kubernetes Custom Resource Definition(CRD) 중 하나입니다.
AuthorizationPolicy를 사용하면 서비스 간 또는 서비스와 클라이언트 간의 통신을 제한하거나 규제할 수 있습니다.

AuthorizationPolicy 예제 코드

AuthorizationPolicy 리소스는 Terraform을 사용해 정의하겠습니다.

  resource "kubernetes_manifest" "example_authorization_policy" {
    manifest = {
      apiVersion = "security.istio.io/v1beta1"
      kind       = "AuthorizationPolicy"
      metadata = {
        name      = "example-auth-policy"
        namespace = "your-namespace"
      }
      spec = {
        selector = {
          matchLabels = {
            app = "your-app-label"   # 어떤 서비스에 규칙을 적용할지 설정합니다.
          }
        }
        action = "ALLOW"  # 규칙이 일치하는 경우 어떤 동작을 취할지 설정합니다.
        rules = [
          {
            when = [
              {
                key = "remote.ip"
                values = ["192.168.1.100"]  # 허용할 IP 주소를 지정합니다.
              }
            ]
          }
        ]
      }
    }
  }

이 AuthorizationPolicy는 Istio 서비스 메시 내에서 “your-app-label” Label을 가진 Service에 대한 액세스를 제어하며,
remote.ip가 “192.168.1.100”인 경우에만 액세스를 허용하게 됩니다.

참고

https://istio.io/latest/docs/reference/config/security/authorization-policy/

[K8S] ExternalName이란?

운호(Noah) — Wed, 1 Nov 2023 18:03:14 +0900

들어가기 앞서,

Kubernetes(K8s)에서 "ExternalName"은 서비스(Service) 리소스의 유형 중 하나로,
내부 클러스터의 애플리케이션들은 "ExternalName" 유형으로 선언된 서비스(Service)의 DNS를 사용해, 외부 서비스 또는 외부 도메인을 간단하게 참조할 수 있습니다.

예제

클러스터 내부 Pod에서 외부 도메인인 “external-service.example.com”에 접근해야 한다고 가정해 봅시다.

이때, 아래와 같이 ExternalName 유형의 Service를 생성한 뒤,

  apiVersion: v1
  kind: Service
  metadata:
    name: my-external-service
  spec:
    type: ExternalName
    externalName: external-service.example.com

클러스터 내부 Pod에서 해당 Service의 DNS를 아래와 같이 참조하면,
- my-external-service.namespace.svc.cluster.local
  - my-external-service : Service의 이름
  - namespace : Service의 Namespace
external-service.example.com 로 라우팅할 수 있게 됩니다.

[K8S] Node, Pod, Container 리소스 사용량 확인 방법

운호(Noah) — Fri, 20 Oct 2023 14:43:36 +0900

들어가기 앞서,

K8S에서 CPU는 Milicore단위(1,000 Milicore = 1Core)로, Memory는 Mbyte단위로 할당됩니다.

Node 리소스 사용량 확인

kubectl top node

NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node-1     50m          2%     800Mi           40%
node-2     75m          3%     900Mi           45%

Pod 리소스 사용량 확인

kubectl top pod

NAME             CPU(cores)   MEMORY(bytes)
my-pod-1         100m         50Mi
my-pod-2         200m         75Mi
another-pod      50m          30Mi

Pod 내부 Container 별 리소스 사용량 확인

kubectl top pod --containers=true

POD                NAME                   CPU(cores)   MEMORY(bytes)
my-pod-1           my-container-1          100m         50Mi
my-pod-2           my-container-2          200m         75Mi
another-pod        another-container       50m          30Mi

[Prometheus] Dashboard에 Basic Auth 적용하는 방법

운호(Noah) — Fri, 20 Oct 2023 14:09:26 +0900

들어가기 앞서,

해당 포스팅에선, K8S Deployment로 정의한 Prometheus Container를
기본 설정 파일 및 Basic Auth가 적용된 웹 설정 파일을 기반으로 실행하는 방법에 대해서 다뤄보겠습니다.
관련 리소스는 Terraform으로 관리하고 있기 때문에, HCL 코드를 기반으로 설명하겠습니다.

Basic Auth에 사용할 비밀번호 해싱

python3-bcrypt를 사용해 Basic Auth에 사용할 비밀번호를 해싱합니다.

  import getpass
  import bcrypt

  password = getpass.getpass("password: ")
  hashed_password = bcrypt.hashpw(password.encode("utf-8"), bcrypt.gensalt())
  print(hashed_password.decode())

이후, 비밀번호를 test로 입력한다면 아래와 같은 결과값이 출력됩니다.
```
  password:
  $2b$12$hNf2lSsxfm0.i4a.1kVpSOVyBCfIB51VRjgBUyv6kdnyTlgWj81Ay
```

kubernetes_config_map 예제 코드

Deployment를 통해 Prometheus Container가 시작될 때,
Prometheus가 기본 설정 파일 및 웹 설정 파일을 Container 내부에서 찾아 실행될 수 있도록,

Prometheus Container 내부에 마운트할 파일들을 kubernetes_config_map을 통해 정의합니다.

  resource "kubernetes_config_map" "prometheus_config" {
    metadata {
      name = "prometheus-config"
    }

    data = {
      "prometheus.yml" = <<EOF
  global:
    scrape_interval: 30s
    evaluation_interval: 30s
    scrape_timeout: 10s

  scrape_configs:
    - job_name: 'statsd-exporter'
      static_configs:
        - targets: ['prometheus-statsd-exporter.default.svc.cluster.local:9102']
  EOF

      "web.yml" = <<EOF
  basic_auth_users:
    admin: $2b$12$hNf2lSsxfm0.i4a.1kVpSOVyBCfIB51VRjgBUyv6kdnyTlgWj81Ay
  EOF
    }
  }

kubernetes_deployment 예제 코드

kubernetes_config_map이 Prometheus Container 내부로 volume mount 될 수 있도록 설정한 뒤,
Prometheus가 기본 설정 파일 및 웹 설정 파일을 Container 내부에서 찾아 실행될 수 있도록,

Prometheus Container 실행 인자로 기본 설정 파일 및 웹 설정 파일의 경로를 넣어줍니다.

  resource "kubernetes_deployment" "prometheus" {
    metadata {
      name = "prometheus"
    }

    spec {
      replicas = 1

      selector {
        match_labels = {
          app = "prometheus"
        }
      }

      template {
        metadata {
          labels = {
            app = "prometheus"
          }
        }

        spec {
          container {
            image = "prom/prometheus"
            name  = "prometheus"
            args = [
                          "--config.file=/etc/prometheus/prometheus.yml",
              "--web.config.file=/etc/prometheus/web.yml"
            ]
            port {
              container_port = 9090
            }

            volume_mount {
              mount_path = "/etc/prometheus/"
              name       = "prometheus-config-volume"
            }
          }
          volume {
            name = "prometheus-config-volume"
            config_map {
              name = kubernetes_config_map.prometheus_config.metadata[0].name
            }
          }
        }
      }
    }
  }

참고

[Terraform] kubernetes_manifest란?

운호(Noah) — Fri, 20 Oct 2023 11:46:21 +0900

들어가기 앞서,

Terraform에서, 공식 K8S Provider가 지원하지 않는 리소스는 ‘kubernetes_manifest’를 사용해 정의할 수 있습니다.
물론, yaml 파일을 그대로 사용할 수는 없으며 yaml의 모든 필드를 HCL 양식에 맞게 수정해야합니다.
- 다행히도 built-in function인 'yamldecode()'나 ‘tfk8s’ 같은 Tool을 사용해 YAML에서 HCL로 자동 변환할 수도 있습니다.

yaml 예제

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
  namespace: default
data:
  foo: bar

Terraform kubernetes_manifest 예제

resource "kubernetes_manifest" "test-configmap" {
  manifest = {
    "apiVersion" = "v1"
    "kind"       = "ConfigMap"
    "metadata" = {
      "name"      = "test-config"
      "namespace" = "default"
    }
    "data" = {
      "foo" = "bar"
    }
  }
}

참고

[K8S] labels, selector, match_labels의 차이

운호(Noah) — Wed, 18 Oct 2023 18:20:02 +0900

들어가기 앞서,

Kubernetes의 Service는 특정 Pod에 네트워크 트래픽을 라우팅하는 역할을 합니다.
- Service는 라벨 셀렉터(spec.selector)를 통해,
- 해당 라벨과 동일한 라벨(spec.template.metadata.labels)을 가지고 있는 Pod에게 네트워크 트래픽을 라우팅하게 됩니다.
하지만, 라우팅 설정에 사용되는 라벨 관련 필드는 다양하기 때문에 헷갈릴 수 있습니다.
- service
  - spec.selector (Service가 어떤 Pod에 라우팅할지 정하기 위한 라벨 셀렉터)
- deployment
  - metadata.labels (Deployment에 할당되는 라벨)
  - spec.selector.match_labels (Deployment가 어떤 Pod를 관리할지 정하기 위한 라벨 셀렉터)
  - spec.template.metadata.labels (Pod에 할당되는 라벨)
따라서, 해당 포스팅에선 Service, Deployment 생성 예제를 통해 labels, selector, match_labels의 차이에 대해서 이해해보겠습니다.
자원 생성 예제는 Terraform을 기반으로 설명하겠습니다.

Service 생성 코드

resource "kubernetes_service" "nginx" {
  metadata {
    name = "nginx-service"
  }

  spec {
    # Service가 어떤 Pod에 라우팅할지 정하기 위한 라벨 셀렉터
    selector = {
      app = "nginx"
    }

    port {
      port        = 80  # 서비스로 라우팅할 포트
      target_port = 80  # 선택한 Pod의 어떤 포트로 트래픽을 전달할지 설정
    }
  }
}

Deployment 생성 코드

resource "kubernetes_deployment" "nginx" {
  metadata {
    name = "nginx-deployment"
    labels = {
      app = "nginx"  # Deployment에 할당되는 라벨
    }
  }

  spec {
    replicas = 2

    # Deployment가 어떤 Pod를 관리할지 정하기 위한 라벨 셀렉터
    selector {
      match_labels = {
        app = "nginx"
      }
    }

    template {
      metadata {
        labels = {
          app = "nginx"  # Pod에 할당되는 라벨
        }
      }

      spec {
        container {
          image = "nginx:latest"
          name  = "nginx"
          port {
            container_port = 80
          }
        }
      }
    }
  }
}

요약

Service, Pod 라우팅을 위해선 Service의 spec.selector와 Deployment의 spec.template.metadata.labels가 일치해야합니다!
또한, Deployment가 Pod를 관리하기 위해선 Deployment의 spec.selector.match_labels와 spec.template.metadata.labels가 일치해야합니다!
즉, 아래 3가지 구성요소가 모두 일치해야합니다.
- Service
  - spec.selector (Service가 어떤 Pod에 라우팅할지 정하기 위한 라벨 셀렉터)
- Deployment
  - spec.selector.match_labels (Deployment가 어떤 Pod를 관리할지 정하기 위한 라벨 셀렉터)
  - spec.template.metadata.labels (Pod에 할당되는 라벨)

[Airflow] DAG에서 Airflow REST API 호출하는 방법

운호(Noah) — Mon, 16 Oct 2023 10:02:58 +0900

들어가기 앞서,

Airflow 환경
- airflow-stable helm chart를 사용해 GKE에 airflow가 설치된 상황
문제 상황
- DAG에서 Airflow REST API를 호출하고 싶음
해결 방법
- DAG는 Worker에서 동작하고, Airflow REST API 서버는 Webserver에서 동작하기 때문에
- DAG에서 Airflow REST API를 호출하고 싶다면
- Worker에서 Webserver로 REST API 내부 호출이 가능해야합니다.
- 따라서, basic auth를 사용해 Pod간 내부 호출을 할 수 있도록 API 관련 Airflow Configuration을 변경했습니다.
기타
- Worker Pod에서 Webserver Pod에 접근하기 위해
- Webserver Pod의 Service를 생성한 뒤, Service DNS를 사용해 접근하도록 설정했습니다.

Helm Chart - Basic Auth를 사용해 Airflow REST API를 호출할 수 있도록 Airflow Configuration 설정

기본 값

  airflow:
    config:
          AIRFLOW__API__AUTH_BACKENDS : 'airflow.api.auth.backend.session'

수정

  airflow:
    config:
          AIRFLOW__API__AUTH_BACKENDS : 'airflow.api.auth.backend.basic_auth'

Airflow REST API 호출 예제

curl -X GET  \
    --user "username:password" \
    "http://airflow-web-custom.default.svc.cluster.local:8080/api/v1/importErrors"

Basic Auth를 사용하기 위한 Airflow User는 이미 생성되어있다고 가정하겠습니다.
- Airflow Dashboard → Security → List Users에서 생성되어 있는 User를 확인할 수 있습니다.

참고

[Terraform] kubernetes_config_map 사용 방법

운호(Noah) — Tue, 26 Sep 2023 17:45:54 +0900

들어가기 앞서,

해당 포스팅에선 Terraform을 통해 kubernetes_config_map 자원 생성 후
kubernetes_deployment 내부에 kubernetes_config_map 파일을 마운팅하는 방법에 대해서 다뤄보겠습니다.

kubernetes_config_map 자원 생성

resource "kubernetes_config_map" "example_config_map" {
  metadata {
    name = "example-config-map"
  }

  data = {
    "config-file.txt" = <<EOF
This is a sample config file.
You can customize it as needed.
EOF
  }
}

kubernetes_deployment 내부 kubernetes_config_map 파일 마운팅

resource "kubernetes_deployment" "example_app" {
  metadata {
    name = "example-app"
    labels = {
      app = "example-app"
    }
  }

  spec {
    replicas = 3

    selector {
      match_labels = {
        app = "example-app"
      }
    }

    template {
      metadata {
        labels = {
          app = "example-app"
        }
      }

      spec {
        container {
          name  = "example-container"
          image = "nginx:latest"

          port {
            container_port = 80
            protocol = "TCP"
          }

          volume_mount {
            mount_path = "/etc/config"   # 컨테이너 내부 파일 저장 경로
            name       = "config-volume" # volumes 이름
          }
        }

        volumes {
          name = "config-volume"
          config_map {
            # kubernetes_config_map 이름
            name = kubernetes_config_map.example_config_map.metadata[0].name 
          }
        }
      }
    }
  }
}

결론

nginx container 내부 /etc/config 경로에 config-file.txt 파일이 저장됩니다.

[Airflow] Configuration 확인 명령어

운호(Noah) — Tue, 26 Sep 2023 17:23:59 +0900

들어가기앞서,

Airflow는 Airflow CLI를 사용해, Airflow에 설정된 Configuration을 확인할 수 있습니다.

Airflow CLI

전체 Configuration 목록 확인
```
  $ airflow config list
```

특정 Configuration Option 확인

  # airflow config get-value [Section] [Option]

  $ airflow config get-value core executor
  SequentialExecutor

  $ airflow config get-value metrics statsd_host
  localhost

참고 사이트

[GCP] generic::permission_denied: user does not have impersonation permission on the trigger service account specified: 에러 해결 방법

운호(Noah) — Thu, 21 Sep 2023 11:18:09 +0900

에러 코드

generic::permission_denied: user does not have impersonation permission on the trigger service account specified:

문제 상황

특정 사용자가 Cloud Build에 할당되어 있는 Service Account를 대신해 수동 실행할 수 있는 권한이 없어서 에러가 발생하는 상황입니다.

해결 방법

사용자 계정에 아래 역할을 할당하면 됩니다.
- “roles/iam.serviceAccountUser”
  - 해당 역할은 “iam.serviceAccounts.actAs” 권한을 포함하고 있으며,
  - “iam.serviceAccounts.actAs” 권한은 사용자가 다른 사용자 계정처럼 다른 역할을 수행할 수 있도록 허용하는 권한입니다.

[GCP] “gcloud auth login"과 “gcloud auth application-default login"의 차이

운호(Noah) — Thu, 21 Sep 2023 11:00:18 +0900

들어가기 앞서,

“gcloud auth login”과 “gcloud auth application-default login”은 Google Cloud SDK의 두 가지 다른 인증 방법을 설정하는 명령어입니다.
해당 포스팅에선 각각의 사용 목적에 대해서 다뤄보겠습니다.

gcloud auth login

직접 GCP 리소스와 상호작용할 때 사용하는 명령어입니다.
- 리소스 직접 액세스, Google Cloud SDK를 통한 GCP API 호출 등

gcloud auth application-default login

로컬 개발 환경에서 애플리케이션과 Google Cloud 서비스가 상호작용할 때 사용하는 명령어입니다.

동작

해당 명령어를 실행하면 브라우저 창이 열리고 Google 로그인 페이지로 리디렉션됩니다.
여기서 GCP 계정으로 로그인히면 로컬 환경에 인증 정보가 저장됩니다.

[Docker] Mac OS 환경에서 IntelliJ의 Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? 해결하기

운호(Noah) — Wed, 20 Sep 2023 15:29:53 +0900

문제 상황

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. 
Is the docker daemon running? (Details: [2] No such file or directory)

docker ps 명령어를 통해 docker 정상 작동을 확인했음에도 불구하고, IntelliJ에서 Docker 연결이 불가능한 상황

해결 방법

터미널에서 아래 명령어를 실행합니다.

  # {name}에는 자신이 macOS에 설정한 값을 넣는다.
  sudo ln -s /Users/{name}/.docker/run/docker.sock /var/run/

이후, Settings → 빌드, 실행, 배포 → Docker → 아래와 같이 재설정합니다.

참고

https://velog.io/@profoundsea25/Mac-OS-Apple-Silicon-환경-IntelliJ에서-Cannot-connect-to-the-Docker-daemon-at-unixvarrundocker.sock.-Is-the-docker-daemon-running-해결하기