Gom3rye

구현 문제에서 '새 배열 교체' vs. '좌표 집합만 교체'

Gom3rye — Fri, 23 Jan 2026 16:21:11 +0900

언제 '새 배열'을 만들고, 언제 '좌표 집합'만 쓸까?

이 두 방식을 구별하는 기준은 "데이터의 밀도"와 "참조 방식"에 있다.

A. 매 단계 '새 배열' 생성이 유리한 경우 (밀도가 높을 때)

상태 전파: 한 칸의 변화가 주변 칸에 연쇄적으로 영향을 줄 때 (예: 모래바람, 불 번지기, 물 시뮬레이션)
주변 참조: board[i][j]의 다음 값이 board[i-1][j], board[i+1][j] 등 주변 8칸의 모든 상태에 의존할 때
객체가 꽉 찼을 때: 보드의 거의 모든 칸에 데이터가 들어있어서 좌표만 따로 관리하는 게 더 메모리를 많이 먹을 때

B. '좌표 집합(Set/Dict)'만 관리해도 되는 경우 (밀도가 낮을 때)

독립적 이동: 객체들이 서로의 상태를 실시간으로 참조하지 않고, 각자 자기 갈 길을 갈 때 (예: 아두이노, 로봇, 총알)
희소 데이터(Sparse Data): 100*100 보드에 객체는 고작 10~20개뿐일 때. (10,000칸을 다 뒤지는 것보다 20개 좌표만 보는 게 훨씬 빠름)
충돌 판정 중심: 이동 후 "겹치면 삭제" 같은 로직이 핵심일 때 (딕셔너리가 보드보다 훨씬 유리함)

문제를 알아보는 결정적 힌트

다음에 문제를 볼 때 이 질문을 스스로에게 던져보기

"내가 지금 보드(board[i][j])의 '빈 공간(.)'을 연산에 쓰고 있는가?"

YES: 빈 공간이 물길이 되거나, 빈 공간의 개수를 세야 하거나, 주변 빈 공간으로 확산된다면 매번 새 배열을 만드는 게 편하다.
NO: 빈 공간은 그냥 배경일 뿐이고, 중요한 건 'I'와 'R'의 위치뿐이라면 좌표 관리가 훨씬 유리하다. 마지막에 출력할 때만 그 좌표들을 보드에 찍어주면 된다.

보드가 "출력용 도구"인지, "내부 로직을 계산하는 데 필수적인 데이터 구조"인지 파악해보자!

DP vs. Stack vs. Heapq

Gom3rye — Fri, 2 Jan 2026 20:57:31 +0900

DP / Stack의 본질

과거에서부터 일직선으로 작동한다.

무슨 의미냐 하면은

DP

상태가 dp[i] → dp[i+1]로 단방향
한 번 계산된 과거 상태는 되돌리지 않음
과거 선택이 “최선”이라는 전제 하에 누적

그래서
✔ “지금 선택이 나중에 틀릴 수 있는 문제”에는 부적합

Stack

가장 최근 선택만 취소 가능 (LIFO)
“조건 위반 시, 방금 넣은 것만 제거” 가능
임의의 과거 선택 제거 불가능

백준) 컵라면 문제에서:

제거해야 할 건 “가장 컵라면 적은 문제”
이게 꼭 마지막에 넣은 것이 아니다 ❌

Heap(우선순위 큐)의 본질

우선순위 기준으로 과거 선택을 언제든지 되돌릴 수 있다

이게 힙의 핵심 능력

힙은 시간 순서가 아니라 가치 순서로 관리
따라서 과거에 “최선처럼 보였던 선택”도 더 좋은 선택이 오면 즉시 폐기 가능

그래서 힙은 이런 문제에 강함:

“일단 다 넣어본다”
“조건 위반 시, 제일 나쁜 것 하나 제거”

컵라면 문제로 다시 연결해보면

상황

데드라인 2까지는 문제 2개만 가능
이미 2개를 골랐는데
컵라면 100짜리 문제가 새로 등장함

해야 할 일

과거 선택 중 컵라면 최소를 제거
이게 언제 들어온 문제인지는 중요 ❌

힙만 가능

즉,

DP나 스택은 과거 선택이 한 방향으로만 누적되며, 한 번 선택한 것이 나중에 뒤집히지 않는다.
반면 heapq는 우선순위를 기준으로 관리되기 때문에 과거에 최선이라고 선택한 것도 나중에 더 좋은 선택이 나오면 즉시 되돌릴 수 있다.

코테용 암기 포인트!

“과거 선택을 나중에 우선순위로 취소해야 하면 힙을 쓰자.”

투 포인터가 가능한 문제 판별법 (체크리스트)

Gom3rye — Wed, 31 Dec 2025 20:01:02 +0900

아래 조건 중 3개 이상 맞으면 거의 확정

1️⃣ “연속한 구간(부분 수열)”이라는 말이 있는가?

투 포인터의 절대적 전제 조건

✔ 연속한
✔ 부분 수열
✔ subarray
✔ 구간 [L, R]

❌ 순열, 조합, 임의 선택 → 투 포인터 아님

2️⃣ 구간에 대한 “조건”이 단조적인가?

단조성(monotonicity)이 핵심

오른쪽을 늘리면 조건이 점점 나빠지거나 / 좋아지거나

예시

조건	단조성
합 ≤ K	right ↑ → 합 ↑
중복 없음	right ↑ → 중복 가능성 ↑
서로 다른 수 개수 ≤ K	right ↑ → 개수 ↑
최대 − 최소 ≤ K	right ↑ → 차이 ↑

조건이 깨지면 left를 움직여 회복 가능

3️⃣ “최대 / 최소 / 개수”를 묻는가?

투 포인터의 전형적인 질문들:

✔ 가능한 최대 길이
✔ 가능한 최소 길이
✔ 조건을 만족하는 구간의 개수

이 중 하나면 의심 1단계 통과

4️⃣ N이 크다 (보통 ≥ 10⁵)

이건 거의 신호등

N가능	알고리즘
10³	O(N²)
10⁵	O(N) or O(N log N)
10⁶	거의 O(N)

연속 + 조건 + N 큼 → 투 포인터 거의 확정

5️⃣ “하나씩 늘려보면 된다”는 느낌이 드는가?

문제를 읽을 때 이런 생각이 들면 바로 투 포인터:

“오른쪽을 늘리다가 안 되면 왼쪽 줄이면 되겠네”
“중복 나오면 앞(left)에서 빼면 되겠네”
“합이 넘치면 앞(left)에서 줄이면 되겠네”

이 생각 자체가 투 포인터 사고방식

❌ 투 포인터가 절대 안 되는 경우

1. 연속이 아니다

수열에서 K개를 골라서

❌ 투 포인터 불가

2. 조건이 비단조적

합이 정확히 K

합은:

늘리면 커졌다가
줄이면 작아졌다가
다시 늘리면 또 커짐

슬라이딩 윈도우 불가

(단, 양수만 있을 때는 예외적으로 가능)

3. 뒤에서 상태가 바뀌는 문제

나중 선택이 앞의 상태를 바꾼다

DP / 그리디 / 스택 문제

대표 문제 유형 매핑

문제 설명	알고리즘
중복 없는 연속 부분 수열 개수	투 포인터
합이 K 이하인 최대 길이	투 포인터
서로 다른 수 ≤ K	투 포인터
최소 길이 부분 수열	투 포인터
스카이라인 / 히스토그램	❌ 스택
스위치 / 토글	❌ 그리디
모든 경우의 수	❌ DP

빠른 판별 3문장 법칙

문제 보자마자 스스로에게 물어볼 질문

1️⃣ 연속인가?
2️⃣ 오른쪽 늘리면 조건이 단조적으로 변하나?
3️⃣ 안 되면 왼쪽 줄이면 회복되나?

전부 YES → 투 포인터

한 줄 요약

연속 + 조건 단조 + N 큼
투 포인터

stack vs. heapq 문제 차이 비교

Gom3rye — Wed, 17 Dec 2025 12:50:52 +0900

핵심 한 줄 요약

heapq는 “여러 후보 중 최선 1개를 계속 고르는 문제”
stack은 “앞에서 한 선택을 뒤에서 취소해야 하는 문제”

이 한 줄을 기준으로 보면 대부분 문제가 정리된다.

1️⃣ heapq 문제

회의실 배정
동시에 열리는 회의의 최대 개수
또는 필요한 최소 회의실 수

이 문제에서 우리가 반복하는 질문

“지금 시작하는 회의가 기존 회의 중 가장 빨리 끝나는 회의를 재사용할 수 있는가?”

매 순간 여러 회의 중 ‘가장 빨리 끝나는 회의 1개’만 중요

그래서 heapq가 딱 맞음

q에는 현재 진행 중인 회의들의 종료 시간
q[0] = 가장 빨리 끝나는 회의
그 하나만 보면 됨 ❗

for start, end in info: 
    if q and q[0] <= start: # 재활용 가능 
        heapq.heappop(q) 
    heapq.heappush(q, end)

과거 선택을 취소하지 않음

이미 시작한 회의는 되돌리지 않음
단지 “끝났는지”만 확인

2️⃣ 반대로 stack 문제는 뭐가 다를까?

❌ 크게 만들기(백준 2812) 에서 우리가 묻는 질문

“현재까지 선택한 숫자 중 어떤 걸 버릴지 다시 결정해야 하는가?”

정답: YES

예제 다시 보기

4177252841 K=4

진행 중:

4
41
417 ← 7이 1보다 크고, 4보다 크니까 차례대로 빼주기
77
772 ← 2 등장 → 앞의 7은 유지
7725 ← 5 등장 → 앞의 2는 제거해야 더 큼 ❗
7752

이미 선택한 숫자를 다시 취소해야 함

❌ heapq로는 이게 불가능

heapq는:

“가장 큰 것”을 알려줄 뿐
누가 언제 들어왔는지
앞자리에 있는지
지금 지워야 하는지

이 정보들을 전부 잃어버림

3️⃣ 구조적으로 비교해보자

기준	heapq (회의실)	stack (크게 만들기)
후보 개수	여러 개	사실상 연속된 과거 선택
관심 대상	항상 “최선 1개”	바로 직전 선택
과거 선택 취소	❌	✅
순서 유지	중요 ❌	필수 ✅
핵심 연산	최솟값 조회	pop / push
문제 본질	자원 관리	선택 수정

4️⃣ 결정적인 질문 3가지

✅ 질문 1

지금 선택이 나중에 취소될 수 있는가?

YES → stack
NO → heapq 가능

✅ 질문 2

후보가 여러 개 있고, 그중 최선 하나만 중요할까?

YES → heapq
NO → stack

✅ 질문 3

입력 순서를 반드시 유지해야 하나?

YES → stack
NO → heapq 가능

5️⃣ 두 문제를 한 문장으로 비교하면

회의실 문제

“지금까지 열린 회의 중 가장 빨리 끝나는 것 하나만 알면 된다”

크게 만들기

“앞자리에 있는 작은 숫자는 언제든지 취소될 수 있다”

Union-Find를 쓸 수 있는 문제 유형 5가지

Gom3rye — Tue, 9 Dec 2025 23:50:06 +0900

Union-Find를 떠올려야 하는 신호(패턴)

아래 상황 중 하나라도 보이면 무조건 Union-Find부터 의심해야 해.

✔ 1) "합치기(union) / 묶기 / 연결하기 / 같은 그룹"이라는 표현이 나올 때

예:

친구 관계(Friend Network)
SNS 팔로우 묶기
같은 팀 만들기
섬/영역/구역을 하나로 합치기
사람/도형/원소들을 같은 집합으로 묶기

✔ 2) 결과가 "그룹 크기" 또는 "연결 요소 개수"일 때

“현재 속한 네트워크의 인원 출력”
“몇 개의 영역이 생기는가?”
“그룹별 개수는?”
“분리된 구역은?”

✔ 3) 서로 겹치거나 닿는 기하학 도형(선분, 원, 직사각형) 문제

이 문제도 여기에 해당됨.

유형 예:

원 1억 개 → 겹치는 원들을 하나의 영역으로 묶기
직사각형이 맞닿는지 파악하기 → 묶기
점/선분이 이어지는지 → 묶기

✔ 4) 실시간으로 “두 개의 무언가를 연결하라” → 이후 질의 발생

예:

A와 B를 같은 집합으로 만들어라
이후 X와 Y가 같은 집합인지 물어봄

이런 구조는 90% Union-Find.

✔ 5) BFS/DFS로 하면 10^6~10^7 이상 연결 관계가 생겨서 느릴 때

Union-Find는 거의 O(1)로 작동하니 훨씬 적합함.

Union-Find 자주 나오는 대표 문제

유형	예시
친구/네트워크	Friend Network, 집합의 개수
기하학 영역	원/직사각형 접촉 문제
서버/컴퓨터 연결	네트워크 연결 여부, 최소 비용 연결
클러스터링	그룹 묶기, 그룹 수 세기
부모-자식/팀 배정	A와 B는 같은 팀
어떤 조건에 의해 “둘을 연결”	예: 길이 연결되면 같은 구역

⭐ 앞으로 이런 문제 보면 바로 Union-Find 떠올리기

문제를 보면 딱 두 가지 체크만 하면 된다.

✔ Q1. "두 개의 무언가를 연결해야 하나?"

→ YES면 Union-Find 후보.

✔ Q2. "그룹 크기 / 그룹 개수 / 같은 그룹 여부" 출력인가?

→ 100% Union-Find.

이 두 조건이 동시에 나오면 → 확정이다.

투 포인터를 쓸 수 있는 문제 유형 10가지

Gom3rye — Mon, 8 Dec 2025 20:23:09 +0900

공통점은 전부 두 개의 증가하는 포인터로 어떤 조건을 만족하는 두 수(또는 구간)를 찾는 형태라는 점!

1. 차이(difference)가 특정 값이 되는 두 수 찾기

대표 문제: “수열에서 |A[j] – A[i]| = K 되는 쌍 찾기”

정렬된 배열에서
- diff < K → right 증가
- diff > K → left 증가
- diff == K → 정답 처리 후 right 증가
딱 이 문제 다이어트 문제 구현과 동일 패턴

2. 두 수의 합이 특정 값이 되는 pair 찾기 (Two-Sum sorted)

예시: BOJ 3273 두 수의 합

sum < target → left++
sum > target → right--
sum == target → answer++

이 문제는 하나는 증가, 하나는 감소지만
“조건 비교를 통한 포인터 이동”이라는 패턴은 동일.

3. 두 수의 합이 특정 값 이하인 최대 pair 수

예시: 투포인터로 배 만들기, 우산 두 개 고르는 문제 등

weight[left] + weight[right] ≤ limit → left++
아니면 → right--

특정 한계를 넘지 않는 최적의 조합을 찾는 문제.

4. 두 수의 차이가 최소가 되는 pair 찾기

수열이 정렬되어 있을 때 가능한 가장 작은 차이를 찾는 문제
예: “수열에서 두 수의 최소 차이 찾기”

diff < best → 업데이트
diff == 0 → 바로 종료
diff > best → left/right 조절

5. 정렬된 배열에서 제곱 수 차이 문제

즉,
x² - y² = C
를 만족하는 x, y 찾기
→ 바로 다이어트 문제와 동일 패턴
(x² - y² = (x+y)(x-y))

다른 N에서 나오는 변형 문제로 자주 등장한다.

6. 부분합이 특정 값 이상 되는 최소 구간 (투포인터 + 슬라이딩 윈도우)

예: BOJ 1806 “부분합”

sum < target → right++
sum ≥ target → 길이 갱신 후 left++

이 문제는 "합" 기반이지만
포인터를 한 번씩 증가시키는 단조 탐색이라는 점이 동일.

7. 연속 부분수열이 특정 조건을 만족하는 최대/최소 길이

예: “서로 다른 숫자가 K개 이하가 되도록 하는 최대 구간 길이”
투포인터로

조건 만족 → right++
조건 만족 안 함 → left++

단조성 + 윈도우라는 점에서 구조가 완전히 동일.

8. 두 배열에서 x + y = target 찾기

배열 A의 포인터 i 증가
배열 B의 포인터 j 감소
두 포인터의 상방향/하방향 이동으로 target을 찾는 투포인터 패턴.

9. **A[i] * B[j] 특정 비교 문제**

예: “곱이 특정 값을 넘지 않는 쌍의 개수 세기” 같은 문제

product < target → left++
else → right--

sum, diff 뿐 아니라 곱에 대해서도 가능.

10. 두 개의 리스트 병합(Merge Two Sorted Lists)

두 리스트의 pointer를 각각 비교하며 오른쪽으로 이동
정렬된 결과를 만든다
두 포인터가 단조하게 증가하며 전체를 스캔한다는 점에서
투포인터의 기본형 문제.

전체 패턴 요약

투포인터가 사용되는 상황은 다음 조건을 만족한다:

✔ 1. 배열 또는 수열이 "단조성(정렬)"을 가지고 있고

✔ 2. 포인터가 움직일 때 항상 앞으로만 가고

✔ 3. 전체 복잡도가 O(N) 또는 O(N log N)으로 해결돼야 할 때

→ 어떤 조건(합, 차이, 곱 등)을 만족하는 두 위치를 찾는 구조면 대부분 투포인터로 가능함.

즉,
“증가/감소에 따라 diff 단조 변화를 가진다"
= 투포인터 조건 만족

그래서 정렬도 필요 없고 투포인터가 바로 답.

팀 프로젝트) (topic생성) MSK 테스트를 위한 bastion host EC2 만들기

Gom3rye — Tue, 11 Nov 2025 10:14:15 +0900

MSK는 강력한 기능이지만… strimzi처럼 직접 topic을 생성하는 기능도 없고 제대로 들어오고있는지, 시험삼아 메시지 보내보고~ 이런 간단한 테스트를 위한 UI가 따로 제공되지는 않기 때문에!! 테스트를 해보려면 같은 VPC 대역에 있는 누군가를 위하여 원격으로 해보아야 한다.

이미 같은 VPC에 있는 EKS들을 써도 되지만, 한창 바쁜 때에 끼어들고 싶지 않기 때문에 이거 전용의 작고 소중한 EC2를 만들기로 했다.

실제 업계에서도 스탠다드로 사용하는 방식이라고 하네요. 그래서 쓰는 용어가 배스쳔호스트(bastion host)이다.

EC2를 만들자

자유롭게 하되, VPC는 solog-unified-vpc를 선택해줍니다!!
보안그룹은 따로 만들어서 9092 등을 개방해도 되고, 이미 있는걸 써도 됨. 우리는 msk cluster가 쓰는 보안그룹을 재활용하기로 함.

Kafka를 설치하자

만들어진 EC2에 접속한 후, kafka client부터 깔아준다.

sudo apt update
sudo apt install -y openjdk-11-jre
sudo apt install -y make

wget https://downloads.apache.org/kafka/3.9.0/kafka_2.13-3.9.0.tgz
tar -xzf kafka_2.13-3.9.0.tgz

echo "export KAFKA_HOME=~/kafka_2.13-3.9.0" >> ~/.bashrc
echo "export PATH=\$PATH:\$KAFKA_HOME/bin" >> ~/.bashrc
source ~/.bashrc

이제 어느 경로에서던 kafka-어쩌구.sh를 실행할 수 있게 되었다. tab으로 자동완성도 된다.

MSK 테스트해보기

일단 MSK의 부트스트랩 주소로 사용할… 9092로 끝나는 엔드포인트 주소 뭉탱이를 터미널 변수로 해둡시다… 매번 치기엔 너무 기니까…

MSK="(endpoint주소!!)"

MSK="b-2.sologmskcluster.81f2k0.c4.kafka.ap-northeast-2.amazonaws.com:9092,b-1.sologmskcluster.81f2k0.c4.kafka.ap-northeast-2.amazonaws.com:9092"

kafka topic 만들기 test

kafka-topics.sh --bootstrap-server $MSK \
                --create \
                --topic test-topic \
                --replication-factor 2

일단 사용할 명령어는 kafka-topics.sh 이고, 옵션을 주렁주렁 줘야 하는데 차례대로…

--bootstrap-server : 접속할 카프카 클러스터의 주소. 아까 참고로 줬던 MSK의 주소 정보를 사용하면 된다. 암호화 없는 버전이니까 plaintext 버전, 즉 9092로 끝나는 주소를 넣어주면 된다.

--create 토픽 만들겠다는 뜻이죠? 나중에 만든 토픽 확인할 때는 이거를 --list 로 변경하면 된다.

--topic 이게 중요한 부분. 그래서 어떤 토픽을 만들건데?? 이다. 테스트니까 test-topic 이라고 해줬는데 실제로 만들 때는 실제로 사용할 토픽 이름을 여기에 써주면 된다.

--replication-factor 자가복제를 몇개 하겠냐는건데, 보통은 브로커 수만큼 해준다. 우리 브로커는 현재 두개니까 2로 넣어준다.

잘 만들어졌는지는 아래의 명령어로 테스트 해봅시다. 앞서 말했듯 create 대신 list 옵션을 주면 된다.

kafka-topics.sh --bootstrap-server $MSK --list

결과값에 아까 만든 test-topic이 포함되어 있는지 확인해보자.

kafka topic consume & produce test

이제 아까 만든 토픽에 뭔가를 produce해보고, 그게 잘 consume 되는지 확인해보자.

일단 produce 되자마자 들어오는지 보기 이해서 consumer를 먼저 켜둔다. 둘이 동시에 진행해야 하니 ssh 접속도 두개를 유지해주자.

먼저 아까 만든 test-topic을 대상으로 consumer를 켜둔다. 부트스트랩 서버는 아까랑 동일하게 우리의 MSK 클러스터 주소로 하고

kafka-console-consumer.sh --bootstrap-server $MSK --topic test-topic

그럼 구독중인 상태가 된다. 아직 아무것도 안 뜰텐데, 그냥 그렇게 두시구 다른 ssh 창으로 넘어가서~

produce를 해보자. 동일한 부트스트랩 주소를 사용하고, 같은 test-topic을 대상으로 발행할 것이다.

kafka-console-producer.sh --bootstrap-server $MSK --topic test-topic

이거 하고나면 > 표시가 뜰텐데, 여기서 뭔가 원하는걸 입력하고 엔터를 누르면 아까 구독해둔 consumer 측에 같은 메시지가 전송될 것이다!

좌측 프로듀서가 보낸 Consumer Test 가 우측 consumer에 보이는 걸 확인할 수 있다.

이제 여기서 우리가 실제로 사용할 topic들 정도만 만들어주고 마무리하면 된다.

kafka-topics.sh --bootstrap-server $MSK \
                --create \
                --topic service-topic \
                --replication-factor 2

kafka-topics.sh --bootstrap-server $MSK \
                --create \
                --topic system-auth-topic \
                --replication-factor 2

kafka-topics.sh --bootstrap-server $MSK \
                --create \
                --topic system-kmsg-topic \
                --replication-factor 2

+ bastion host EC2의 기본 홈에 Makefile을 만들어둠. 아래의 명령어들로 간편한 동작 가능~~

Makefile (최상단 MSK 내용을 최신의 MSK bootstrap-server로 수정해서 만들고 사용하기!)

MSK="b-2.sologmskcluster.81f2k0.c4.kafka.ap-northeast-2.amazonaws.com:9092,b-1.sologmskcluster.81f2k0.c4.kafka.ap-northeast-2.amazonaws.com:9092"

topics:
        kafka-topics.sh --bootstrap-server ${MSK} --list

service:
        kafka-console-consumer.sh --bootstrap-server ${MSK} --topic service-topic

kmsg:
        kafka-console-consumer.sh --bootstrap-server ${MSK} --topic system-kmsg-topic

auth:
        kafka-console-consumer.sh --bootstrap-server ${MSK} --topic system-auth-topic

토픽 목록 확인하기

make topics

service-topic 구독하기

make service

system-kmsg-topic 구독하기

make kmsg

system-auth-topic 구독하기

make auth

팀 프로젝트) AWS MSK 구축하기 (feat. Terraform)

Gom3rye — Tue, 11 Nov 2025 10:07:04 +0900

공식문서: Amazon MSK 개발자 안내서에 오신 것을 환영합니다. - Amazon Managed Streaming for Apache Kafka

MSK(Managed Streaming for Apache Kafka): 고가용성을 갖춘 Apache Kafka 클러스터. AWS에서 완전 관리형으로 제공하므로 내부적인 브로커 설정, zookeeprt나 kraft 컨트롤러 등을 직접 설치하고 관리할 필요 없이 알아서 다 해줌.

구축되면 bootstrapserver를 엔드포인트를 노출시켜주므로, 기존의 kafka 클러스터로 구성된 아키텍쳐에서 해당 주소만 바꿔치기 하면 간편하게 마이그레이션이 가능하다!!!!

즉, 특정 VPC에 위치하여 같은 VPC 대역 안에 있는 친구들이 bootstrapserver로 접근 가능하게 함. HA를 위해 최소 2개 이상 AZ에 속한 서브넷을 필요로 하며, 서브넷당 1개 이상의 브로커가 배치됨. (브로커가 모든 AZ에 고르게 퍼져야 하는 듯. AZ가 2개면 브로커 갯수도 2의 배수로 설정해야 함 안그럼 에러 남ㅠ)

준비물: 소속될 VPC, 서브넷, 보안그룹, 필요시 KSM 키나 IAM역할(우리는 생략)

serverless 비용: 존재하는 것 만으로 드는 비용 + 데이터가 오가는 양마다 드는 비용(GB단위)

Terraform을 이용해 원클릭으로 배포 및 삭제가 가능하도록 할 예정 (15-30분 소요)

msk.tf

# Terraform AWS Provider 설정
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0" 
    }
  }
}

provider "aws" {
  region = "ap-northeast-2" 
}

# 1. 기존 리소스 정보 가져오기 (Data Sources)
# --- 1-1. 기존 VPC 정보 가져오기 ---
data "aws_vpc" "solog_vpc" {
  tags = {
    Name = "solog-unified-vpc"
  }
}

# --- 1-2. MSK 브로커를 배치할 기존 서브넷 정보 가져오기 ---
data "aws_subnets" "solog_public_subnets" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.solog_vpc.id]
  }
}

# --- 1-3. 기존 EKS 워커 노드의 보안 그룹 정보 가져오기 ---
data "aws_security_group" "eks_producer_sg" {
  tags = {
    Name = "eks-cluster-sg-eks-datacenter-cluster-1029477356"
  }
}

data "aws_security_group" "eks_consumer_sg" {
  tags = {
    Name = "eks-cluster-sg-eks-monitoring-cluster-1453820597"
  }
}

# 2. MSK 클러스터를 위한 새 보안 그룹 생성
#variable "kafka_ports" {
#  description = "EKS가 MSK에 접속하기 위해 열어줄 Kafka 포트 목록"
#  type        = list(number)
#  default     = [9092, 9098, 9094] 
#}

resource "aws_security_group" "msk_sg" {
  name        = "my-msk-cluster-sg"
  description = "Allow inbound traffic from EKS worker nodes to MSK"
  vpc_id      = data.aws_vpc.solog_vpc.id

  # --- 인바운드 규칙 (Ingress) ---
  ingress {
    from_port                = 0
    to_port                  = 0
    protocol                 = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # --- 아웃바운드 규칙 (Egress) ---
  # MSK가 외부(EKS 응답 등)와 통신하기 위해 모든 아웃바운드를 허용합니다.
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1" # 모든 프로토콜
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "my-msk-cluster-sg"
  }
}

# 3. AWS MSK 클러스터 생성 (KRaft + EBS)
resource "aws_msk_cluster" "msk_cluster" {
  cluster_name = "solog-msk-cluster2"

  kafka_version = "3.6.0"

  number_of_broker_nodes = 2
  broker_node_group_info {
    instance_type = "kafka.t3.small"

    client_subnets  = data.aws_subnets.solog_public_subnets.ids
    security_groups = [aws_security_group.msk_sg.id]

    storage_info {
      ebs_storage_info {
        volume_size = 100
        # volume_type = "GP3" # (선택) GP3 타입을 명시할 수 있습니다.
        # throughput = 125    # (선택) GP3 사용 시 처리량 (MiB/s)
      }
    }
  }

  # --- 보안 및 인증 설정 --- 안해~
  client_authentication {
    #sasl {
      #iam = true
    #}
    unauthenticated = true
  }

  # 전송 중 암호화 (네트워크 트래픽 암호화)
  encryption_info {
    encryption_in_transit {
      client_broker = "TLS_PLAINTEXT" # TLS_PLAINTEXT, TLS 중 선택
    }
  } 
#
#  # CloudWatch 로깅 설정
  logging_info {
    broker_logs {
      cloudwatch_logs {
        enabled   = true
        log_group = "/aws/msk"
      }
    }
  }

  tags = {
    Name = "my-msk-cluster"
  }
} 

# 4. (선택) 생성된 MSK 클러스터 정보 출력

output "msk_cluster_arn" {
  description = "생성된 MSK 클러스터의 ARN"
  value       = aws_msk_cluster.msk_cluster.arn
}

output "msk_bootstrap_servers_iam" {
  description = "IAM 인증용 부트스트랩 서버 주소"
  value       = aws_msk_cluster.msk_cluster.bootstrap_brokers_sasl_iam
}

output "msk_bootstrap_servers_tls" {
  description = "TLS 인증용 부트스트랩 서버 주소"
  value       = aws_msk_cluster.msk_cluster.bootstrap_brokers_tls
}

output "msk_bootstrap_servers_plaintext" {
  description = "Plaintext (비인증, 9092 포트) 부트스트랩 서버 주소"
  value       = aws_msk_cluster.msk_cluster.bootstrap_brokers
}

이제 output에 정의된 바와 같이 bootstrap server 주소가 stdout으로 출력 될 것임. 잘 킵해뒀다가 쓰면 끝~

msk_bootstrap_servers_plaintext = "b-1.sologmskcluster2.tak97t.c4.kafka.ap-northeast-2.amazonaws.com:9092,b-2.sologmskcluster2.tak97t.c4.kafka.ap-northeast-2.amazonaws.com:9092"

msk_bootstrap_servers_tls = "b-1.sologmskcluster2.tak97t.c4.kafka.ap-northeast-2.amazonaws.com:9094,b-2.sologmskcluster2.tak97t.c4.kafka.ap-northeast-2.amazonaws.com:9094"

msk_cluster_arn = "arn:aws:kafka:ap-northeast-2:484400672545:cluster/solog-msk-cluster2/93e22e78-17bc-4d81-9755-4bf53f63b035-4"

우리는 TLS 안 할거라고 했으니 9092 버전, 최상단의 버전을 쓰면 될 것임.

*주의!!! 브로커별 주소가 컴마 , 로 연결된 형태로 나타나는데, 이건 고가용성을 위한 표준이므로 전체를 통으로 사용해야 함. "b-1.sologmskcluster2.tak97t.c4.kafka.ap-northeast-2.amazonaws.com:9092,b-2.sologmskcluster2.tak97t.c4.kafka.ap-northeast-2.amazonaws.com:9092" 이거 다 써야 함!!

상세한 이유

MSK는 Kubernetes 위에서 동작하는 것이 아니라, AWS의 EC2/VPC 네트워크 위에서 직접 동작합니다. K8s의 Service 같은 자동 중계 기능이 없습니다.

대신 MSK는 Kafka가 원래 설계된 표준 "부트스트랩(Bootstrap)" 방식을 그대로 사용합니다.

Kafka 클라이언트의 기본 동작: Kafka 클라이언트(Fluentd, Java, Python 등)는 애초에 "대표 주소 1개"가 아니라 "브로커 주소 목록"을 받도록 설계되었습니다.

"아무거나 하나만 써도 되나요?"

아니요, 절대 안 됩니다. 반드시 b-1...:9092,b-2...:9092 전체 목록을 다 사용해야 합니다.

이유: 고가용성 (High Availability, HA)

만약 b-1 주소 하나만 Fluentd 설정에 넣었다고 가정해 보겠습니다.

장애 상황: AWS가 b-1 브로커가 있는 EC2 인스턴스를 점검하거나 해당 하드웨어에 장애가 발생하면, b-1 브로커는 잠시 다운됩니다.
결과: Fluentd는 b-1 외에 다른 주소를 모르기 때문에, MSK에 접속 자체가 실패하고 데이터(로그)는 유실됩니다.

올바른 설정:

b-1..., b-2... 전체 목록을 Fluentd 설정에 넣습니다.
장애 상황: b-1 브로커가 다운됩니다.
결과: Fluentd(Kafka 클라이언트)가 "어? b-1이 죽었네. 그럼 목록에 있는 다음 주소(b-2)로 접속해봐야지"라며 자동으로 b-2에 접속하여 부트스트랩을 계속합니다.

+ 참고: 포트들 뭔 차이?

포트	인증 방식 (Authentication)	암호화 (Encryption)	Terraform (client_authentication)
9092	비인증 (Unauthenticated)	없음 (Plaintext, 평문)	unauthenticated = true
9094	비인증 (Unauthenticated)	필수 (TLS/SSL)	unauthenticated = true
9096	SASL/SCRAM (ID/PW)	필수 (TLS/SSL)	sasl.scram = true
9098	AWS IAM (Role/User)	필수 (TLS/SSL)	sasl.iam = true

팀 프로젝트) Terraform EKS - 3개 클러스터 통합 관리 (VPC 공유)

Gom3rye — Tue, 11 Nov 2025 10:02:26 +0900

1. 테라폼(Terraform)이란?

테라폼은 "코드로 인프라를 관리(Infrastructure as Code, IaC)"하게 해주는 도구이다.

선언형 언어: eksctl처럼 "클러스터를 만들어 줘"라는 명령을 내리는 것이 아니라, "나는 VPC 1개, 서브넷 3개, EKS 클러스터 1개가 필요해."라고 원하는 상태를 코드(.tf 파일)로 선언한다.
실행 계획: terraform plan 명령을 실행하면, 테라폼이 현재 인프라 상태와 코드를 비교해서 "VPC를 새로 만들어야겠네. 서브넷도 3개 만들어야겠다."처럼 변경 계획을 보여준다.
상태 관리: terraform apply로 계획을 실행하면, 테라폼이 실제로 AWS에 리소스를 생성하고, 생성된 리소스의 정보를 terraform.tfstate라는 파일에 저장한다. 이 덕분에 나중에 코드를 변경해도 무엇이 바뀌어야 하는지 정확히 알 수 있다.

eksctl이나 CloudFormation과 비교하면, 테라폼은 AWS뿐만 아니라 GCP, Azure 등 다양한 클라우드 제공자를 하나의 언어로 관리할 수 있고, 코드를 재사용하거나 모듈화하기에 더 유용하다.

2. 테라폼 설치

다운로드: HashiCorp 공식 다운로드 페이지에서 본인 OS(Windows, macOS, Linux)에 맞는 파일을 다운로드한다.
설치:
- 다운로드한 파일은 .zip 압축 파일이다.
- 압축을 풀면 terraform.exe (Windows) 또는 terraform (macOS/Linux) 실행 파일 하나가 나온다.
- eksctl을 설치하고 **환경 변수(Path)**에 경로를 추가했던 것과 똑같이, 이 파일을 원하는 폴더(예: C:\Terraform)에 옮기고 해당 폴더 경로를 시스템 환경 변수 Path에 추가한다.
설치 확인: 터미널(CMD 또는 PowerShell)을 새로 열고 아래 명령어를 입력한다. 버전 정보가 나오면 성공이다.

c:\Terraform>terraform --version

Terraform v1.13.4
on windows_386

3. 사전 준비 (AWS 자격증명)

(1) IAM 사용자 생성 및 액세스키 발급

IAM 정책(all) 생성

IAM - 정책 - 정책 생성 - JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect" : "Allow",
      "Action": [
        "*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

IAM 사용자에 정책연결

권한 설정 : 직접 정책 연결 이전에 만든 all 권한을 설정해준다.

사용자에게 액세스키 발급

사용자 JWON - 보안자격 증명 - 액세스 키 만들기 - AWS 외부에서 실행되는 애플리케이션 - 액세스키 만들기

액세스 키가 만들어지면 따로 저장해놓아야 한다.

(2) AWS CLI

AWS 리소스를 관리하기 위한 명령줄 도구이다.

설치 확인:
- c:\Terraform>aws --version aws-cli/2.27.58 Python/3.13.4 Windows/11 exe/AMD64
aws configure
- IAM의 사용자의 access-key 와 secret access-key를 설정해야 한다.
aws configure --profile=JWON
- 사용자 생성 시 발급받은 액세스 키를 넣어주면 된다.

AWS Access Key ID [None] : ...
AWS Secret Access Key [None] : ...
Default region name [None] : ap-northeast-2
Default output format [None] : json

프로필 확인 : aws configure list-profiles
- JWON 로 생성된 것을 확인 가능하다.

(3) kubectl

쿠버네티스 클러스터와 통신하기 위한 명령줄 도구이다.

다운로드: curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/1.31.0/2024-09- 12/bin/darwin/amd64/kubectl
설치 확인: kubectl version --client

4. 프로젝트 구조: 3개 EKS 클러스터 통합 관리

이전에는 3개의 클러스터(datacenter, kafka, monitoring)를 생성하기 위해 3개의 개별 폴더에서 각각 terraform apply를 실행하는 방식을 사용했다.

이번에 수정된 구조(solog-terraform-unified)는 단일 테라폼 프로젝트에서 3개의 EKS 클러스터를 동시에 관리하는 방식이다.

VPC 공유 (비용 절감): vpc.tf 파일 하나가 1개의 VPC와 2개의 공용 서브넷을 생성한다. 3개의 모든 클러스터가 이 공유된 네트워크 자원을 함께 사용한다.
파일 분리 (가독성): 각 클러스터에 필요한 EKS, IAM 리소스는 eks_datacenter.tf, iam_datacenter.tf처럼 기능별/클러스터별 파일로 분리하여 관리가 용이하다.
통합 실행 (효율성): terraform apply 단 한 번의 실행으로 3개 클러스터와 모든 부속 자원(VPC, IAM 역할 등)이 동시에 생성, 수정, 삭제된다.

5. 테라폼 코드로 EKS 클러스터 3개 동시 구축하기

solog-terraform-unified 폴더 내의 각 파일은 다음과 같은 역할을 수행한다.

(1) provider.tf : 테라폼 설정 (AWS + Kubernetes)

테라폼이 AWS와 통신하고, 추가로 생성될 EKS 클러스터 내부(aws-auth 수정)와도 통신할 수 있도록 설정한다.

kubernetes 프로바이더: aws-auth.tf에서 클러스터 내부의 ConfigMap을 수정하기 위해 필요하다.
alias (별명): 3개의 클러스터에 각각 접속해야 하므로, datacenter, kafka, monitoring이라는 별명을 부여하여 테라폼이 어떤 클러스터에 명령을 내려야 할지 구분할 수 있게 한다.

# provider.tf

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.0" 
    }
    kubernetes = {
      source = "hashicorp/kubernetes"
      version = "~> 2.20"
    }
  }
}

# AWS 프로바이더 설정
provider "aws" {
  region = "ap-northeast-2"
  profile = "JWON" 
}

# 2. Kubernetes 프로바이더 (클러스터 "내부" 관리용)
# --- 3개 클러스터에 대한 접속 정보를 각각 정의 ---

# 2-1. DataCenter 클러스터 접속 정보
data "aws_eks_cluster" "datacenter" {
  name = aws_eks_cluster.datacenter_cluster.name
}
data "aws_eks_cluster_auth" "datacenter" {
  name = aws_eks_cluster.datacenter_cluster.name
}
provider "kubernetes" {
  alias = "datacenter" # "datacenter" 라는 별명 부여
  host = data.aws_eks_cluster.datacenter.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.datacenter.certificate_authority[0].data)
  token = data.aws_eks_cluster_auth.datacenter.token
}

# 2-2. Kafka 클러스터 접속 정보
data "aws_eks_cluster" "kafka" {
  name = aws_eks_cluster.kafka_cluster.name 
}
data "aws_eks_cluster_auth" "kafka" {
  name = aws_eks_cluster.kafka_cluster.name
}
provider "kubernetes" {
  alias = "kafka"
  host = data.aws_eks_cluster.kafka.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.kafka.certificate_authority[0].data)
  token = data.aws_eks_cluster_auth.kafka.token
}

# 2-3. Monitoring 클러스터 접속 정보
data "aws_eks_cluster" "monitoring" {
  name = aws_eks_cluster.monitoring_cluster.name
}
data "aws_eks_cluster_auth" "monitoring" {
  name = aws_eks_cluster.monitoring_cluster.name
}
provider "kubernetes" {
  alias = "monitoring"
  host = data.aws_eks_cluster.monitoring.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.monitoring.certificate_authority[0].data)
  token = data.aws_eks_cluster_auth.monitoring.token
}

(2) vpc.tf : 공유 VPC 및 서브넷

3개의 클러스터가 공동으로 사용할 단일 VPC와 서브넷 2개(가용 영역 2a, 2c)를 생성한다.

kubernetes.io/cluster/... 태그: EKS가 이 서브넷들을 컨트롤 플레인(ELB 등)이나 워커 노드용으로 인식할 수 있도록 3개 클러스터의 이름을 모두 shared로 태그하는 것이 매우 중요하다.

# vpc.tf
# [비용 절감형] 1개 VPC, 2개 AZ, 2개 서브넷으로 3개 클러스터 모두 공유

# 1. VPC 생성
resource "aws_vpc" "solog_vpc" {
  cidr_block           = "192.168.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "solog-unified-vpc"
  }
}

# 2. 퍼블릭 서브넷 "2개" 생성 (2개 AZ)
resource "aws_subnet" "solog_public_subnets" {
  count                   = 2
  vpc_id                  = aws_vpc.solog_vpc.id
  availability_zone       = ["ap-northeast-2a", "ap-northeast-2c"][count.index]
  cidr_block              = "192.168.${count.index}.0/24"  
  map_public_ip_on_launch = true 

  tags = {
    Name = "solog-unified-public-subnet-${count.index + 1}"
    
    # 3개 클러스터 이름을 모두 태그
    "kubernetes.io/cluster/eks-datacenter-cluster" = "shared"
    "kubernetes.io/cluster/eks-kafka-cluster"      = "shared"
    "kubernetes.io/cluster/eks-monitoring-cluster" = "shared"
  }
}

# 3. 인터넷 게이트웨이 생성
resource "aws_internet_gateway" "solog_igw" {
  vpc_id = aws_vpc.solog_vpc.id

  tags = {
    Name = "solog-unified-igw"
  }
}

# 4. 라우트 테이블 (Public) 생성
resource "aws_route_table" "solog_public_rt" {
  vpc_id = aws_vpc.solog_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.solog_igw.id
  }

  tags = {
    Name = "solog-unified-public-rt"
  }
}

# 5. 서브넷 2개를 라우트 테이블에 연결
resource "aws_route_table_association" "solog_public_rta" {
  count          = 2
  subnet_id      = aws_subnet.solog_public_subnets[count.index].id
  route_table_id = aws_route_table.solog_public_rt.id
}

(3) iam_*.tf : 클러스터별 IAM 역할

3개의 클러스터는 VPC를 공유하더라도, 각자 고유한 IAM 역할(클러스터용, 노드용)이 필요하다. iam_datacenter.tf, iam_kafka.tf, iam_monitoring.tf 3개 파일로 분리하여 각 클러스터에 필요한 역할을 정의한다.

(예시: iam_datacenter.tf - kafka, monitoring 파일도 동일한 구조로 이름만 변경)

# iam_datacenter.tf

# 1. DataCenter EKS 클러스터(컨트롤 플레인)를 위한 IAM 역할
resource "aws_iam_role" "eks_datacenter_cluster_role" {
  name = "eks-datacenter-cluster-role" # 고유 이름

  # EKS 서비스가 이 역할을 맡을 수 있도록 허용
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Principal = { Service = "eks.amazonaws.com" },
        Action = "sts:AssumeRole"
      }
    ]
  })
}

# EKS 클러스터 역할에 필요한 정책 연결
resource "aws_iam_role_policy_attachment" "cluster_policy_attachment_datacenter" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
  role       = aws_iam_role.eks_datacenter_cluster_role.name
}

# 2. DataCenter 워커 노드(EC2 인스턴스)를 위한 IAM 역할
resource "aws_iam_role" "eks_datacenter_node_role" {
  name = "eks-datacenter-node-role" # 고유 이름

  # EC2 인스턴스가 이 역할을 맡을 수 있도록 허용
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Principal = { Service = "ec2.amazonaws.com" },
        Action = "sts:AssumeRole"
      }
    ]
  })
}

# 워커 노드 역할에 필요한 3가지 기본 정책 연결
resource "aws_iam_role_policy_attachment" "node_policy_attachment_worker_datacenter" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
  role       = aws_iam_role.eks_datacenter_node_role.name
}

resource "aws_iam_role_policy_attachment" "node_policy_attachment_cni_datacenter" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
  role       = aws_iam_role.eks_datacenter_node_role.name
}

resource "aws_iam_role_policy_attachment" "node_policy_attachment_ecr_datacenter" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
  role       = aws_iam_role.eks_datacenter_node_role.name
}

(4) eks_*.tf : 클러스터별 EKS 정의

각 클러스터의 컨트롤 플레인(aws_eks_cluster)과 노드 그룹(aws_eks_node_group)을 정의한다. role_arn은 iam_*.tf에서 만든 고유한 역할을, subnet_ids는 vpc.tf에서 만든 공유 서브넷을 참조한다.

(예시: eks_datacenter.tf - eks_kafka.tf, eks_monitoring.tf 파일도 동일한 패턴으로 생성한다.)

# eks_datacenter.tf

# 1. EKS 클러스터(컨트롤 플레인) 생성
resource "aws_eks_cluster" "datacenter_cluster" {
  name     = "eks-datacenter-cluster"
  version  = "1.30"
  role_arn = aws_iam_role.eks_datacenter_cluster_role.arn

  # 클러스터가 사용할 VPC 및 서브넷 정보 (공유 서브넷 참조)
  vpc_config {
    subnet_ids = [for s in aws_subnet.solog_public_subnets : s.id]
  }

  depends_on = [
    aws_iam_role_policy_attachment.cluster_policy_attachment_datacenter,
    aws_vpc.solog_vpc,
  ]
}

# 2. EKS 노드 그룹 생성
resource "aws_eks_node_group" "datacenter_nodegroup" {
  cluster_name    = aws_eks_cluster.datacenter_cluster.name
  node_group_name = "eks-datacenter-nodegroup"  
  node_role_arn   = aws_iam_role.eks_datacenter_node_role.arn
  subnet_ids      = [for s in aws_subnet.solog_public_subnets : s.id]
  instance_types  = ["t3.medium"] 

  scaling_config {
    desired_size = 2 
    min_size     = 2 
    max_size     = 5 
  }
  
  depends_on = [
    aws_iam_role_policy_attachment.node_policy_attachment_worker_datacenter,
    aws_iam_role_policy_attachment.node_policy_attachment_cni_datacenter,
    aws_iam_role_policy_attachment.node_policy_attachment_ecr_datacenter,
  ]
}

(5) aws-auth.tf : 3개 클러스터 팀원 권한 동시 설정

EKS 클러스터 생성자 외의 다른 팀원(IAM 사용자)이 kubectl로 클러스터에 접속할 수 있도록 aws-auth ConfigMap에 등록해주는 파일이다.

locals: 권한을 부여할 팀원 목록을 정의한다. 이 목록은 3개 클러스터가 공유한다.
provider = kubernetes.*: provider.tf에서 정의한 **별명(alias)**을 사용하여, 테라폼이 어떤 클러스터의 aws-auth를 수정할지 정확히 지정한다. (예: provider = kubernetes.datacenter)

# aws-auth.tf

# 1. 팀원 목록을 정의합니다. (이 목록은 3개 클러스터가 공유)
locals {
  map_users = [
    {
      userarn  = "arn:aws:iam::484400672545:user/MJ"
      username = "MJ"
      groups   = ["system:masters"] # 관리자 권한
    },
    {
      userarn  = "arn:aws:iam::484400672545:user/JWOO"
      username = "JWOO"
      groups   = ["system:masters"]
    },
    {
      userarn  = "arn:aws:iam::484400672545:user/JJ"
      username = "JJ"
      groups   = ["system:masters"]
    }
    # ... 팀원 추가 ...
  ]
}

# --- 2. DataCenter 클러스터 권한 설정 ---

# 2-1. DataCenter 클러스터의 'aws-auth' ConfigMap을 읽어옵니다.
data "kubernetes_config_map" "aws_auth_datacenter" {
  provider = kubernetes.datacenter # DataCenter 클러스터에 접속
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }
}

# 2-2. DataCenter 클러스터의 'aws-auth'를 수정(Patch)합니다.
resource "kubernetes_config_map_v1_data" "aws_auth_patch_datacenter" {
  provider = kubernetes.datacenter # DataCenter 클러스터에 접속
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }
  data = {
    "mapUsers" = yamlencode(concat(
      try(yamldecode(data.kubernetes_config_map.aws_auth_datacenter.data.mapUsers), []),
      local.map_users
    ))
  }
  depends_on = [
    aws_eks_node_group.datacenter_nodegroup 
  ]
}

# --- 3. Kafka 클러스터 권한 설정 ---

# 3-1. Kafka 클러스터의 'aws-auth' ConfigMap을 읽어옵니다.
data "kubernetes_config_map" "aws_auth_kafka" {
  provider = kubernetes.kafka # Kafka 클러스터에 접속
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }
}

# 3-2. Kafka 클러스터의 'aws-auth'를 수정(Patch)합니다.
resource "kubernetes_config_map_v1_data" "aws_auth_patch_kafka" {
  provider = kubernetes.kafka # Kafka 클러스터에 접속
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }
  data = {
    "mapUsers" = yamlencode(concat(
      try(yamldecode(data.kubernetes_config_map.aws_auth_kafka.data.mapUsers), []),
      local.map_users
    ))
  }
  depends_on = [
    aws_eks_node_group.kafka_nodegroup 
  ]
}


# --- 4. Monitoring 클러스터 권한 설정 ---

# 4-1. Monitoring 클러스터의 'aws-auth' ConfigMap을 읽어옵니다.
data "kubernetes_config_map" "aws_auth_monitoring" {
  provider = kubernetes.monitoring # Monitoring 클러스터에 접속
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }
}

# 4-2. Monitoring 클러스터의 'aws-auth'를 수정(Patch)합니다.
resource "kubernetes_config_map_v1_data" "aws_auth_patch_monitoring" {
  provider = kubernetes.monitoring # Monitoring 클러스터에 접속
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
    }
  data = {
    "mapUsers" = yamlencode(concat(
      try(yamldecode(data.kubernetes_config_map.aws_auth_monitoring.data.mapUsers), []),
      local.map_users
    ))
  }
  depends_on = [
    aws_eks_node_group.monitoring_nodegroup 
  ]
}

(6) outputs.tf : 3개 클러스터 접속 정보 출력

terraform apply 완료 후, 터미널에 3개 클러스터 각각의 이름, 엔드포인트, kubeconfig 업데이트 명령어를 출력한다.

# outputs.tf

# --- 1. DataCenter 클러스터 ---
output "datacenter_cluster_name" {
  description = "DataCenter EKS 클러스터 이름"
  value = aws_eks_cluster.datacenter_cluster.name
}

output "datacenter_cluster_endpoint" {
  description = "DataCenter EKS 클러스터 엔드포인트 URL"
  value = aws_eks_cluster.datacenter_cluster.endpoint
}

output "datacenter_kubeconfig_command" {
  description = "DataCenter 클러스터 접속을 위한 kubeconfig 업데이트 명령어"
  value = "aws eks update-kubeconfig --region ap-northeast-2 --name ${aws_eks_cluster.datacenter_cluster.name} --profile JWON"
}

# --- 2. Kafka 클러스터 ---
output "kafka_cluster_name" {
  description = "Kafka EKS 클러스터 이름"
  value = aws_eks_cluster.kafka_cluster.name
}

output "kafka_cluster_endpoint" {
  description = "Kafka EKS 클러스터 엔드포인트 URL"
  value = aws_eks_cluster.kafka_cluster.endpoint
}

output "kafka_kubeconfig_command" {
  description = "Kafka 클러스터 접속을 위한 kubeconfig 업데이트 명령어"
  value = "aws eks update-kubeconfig --region ap-northeast-2 --name ${aws_eks_cluster.kafka_cluster.name} --profile JWON"
}

# --- 3. Monitoring 클러스터 ---
output "monitoring_cluster_name" {
  description = "Monitoring EKS 클러스터 이름"
  value = aws_eks_cluster.monitoring_cluster.name
}

output "monitoring_cluster_endpoint" {
  description = "Monitoring EKS 클러스터 엔드포인트 URL"
  value = aws_eks_cluster.monitoring_cluster.endpoint
}

output "monitoring_kubeconfig_command" {
  description = "Monitoring 클러스터 접속을 위한 kubeconfig 업데이트 명령어"
  value = "aws eks update-kubeconfig --region ap-northeast-2 --name ${aws_eks_cluster.monitoring_cluster.name} --profile JWON"
}

6. 테라폼 실행 (클러스터 3개 동시 생성)

solog-terraform-unified 폴더의 터미널에서 아래 명령어들을 차례로 실행한다.

terraform init (초기화) 테라폼이 provider.tf 파일을 읽고 필요한 aws 프로바이더와 kubernetes 프로바이더 플러그인을 다운로드한다. (폴더당 최초 1회만 실행)

[중요] 처음 테라폼 실행 시 aws-auth.tf 파일은 빼주어야 한다. 아직 접속할 클러스터가 없기 때문에 kubernetes 프로바이더가 인증을 시도하다 에러가 발생하기 때문이다.

aws-auth.tf 파일명을 aws-auth.tf.bak 등으로 임시 변경한다.

terraform init, plan, apply를 진행하여 EKS 클러스터를 생성한다.

apply 완료 후 7. 클러스터 접속을 진행하여 kubeconfig에 클러스터 정보를 등록한다. (이 과정이 있어야 kubernetes 프로바이더가 정상 동작한다.)

aws-auth.tf.bak 파일명을 다시 aws-auth.tf로 변경한다.

terraform apply를 한 번 더 실행하면 aws-auth 관련 변경 사항(팀원 권한)만 추가로 반영된다.

$ terraform init
Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 5.0"...
- Finding hashicorp/kubernetes versions matching "~> 2.20"...
...
Terraform has been successfully initialized!

2. terraform plan (실행 계획) 테라폼이 모든 .tf 코드를 읽고 AWS에 "무엇을" 만들지 미리보기로 보여준다. (실제 생성 X) 공유 VPC 관련 리소스 + 3개 클러스터의 IAM 역할 + 3개 EKS 클러스터 + 3개 노드 그룹 등 수십 개의 리소스가 목록에 나타난다.

$ terraform plan
...
Plan: 50 to add, 0 to change, 0 to destroy. # (리소스 개수는 예시)
...

3. terraform apply (적용) 실행 계획을 확인한 후, 실제로 모든 리소스를 생성한다. 3개의 클러스터가 동시에 생성되므로 15~20분 이상 소요될 수 있다.

$ terraform apply
...
Plan: 50 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Only 'yes' will be accepted to approve.

  Enter a value: yes  <-- "yes"를 직접 입력하고 엔터

...
aws_eks_cluster.datacenter_cluster: Creating...
aws_eks_cluster.kafka_cluster: Creating...
aws_eks_cluster.monitoring_cluster: Creating...
...
Apply complete! Resources: 50 added, 0 changed, 0 destroyed.

Outputs:

datacenter_cluster_endpoint = "https://<...>.eks.amazonaws.com"
datacenter_cluster_name = "eks-datacenter-cluster"
datacenter_kubeconfig_command = "aws eks update-kubeconfig ... --name eks-datacenter-cluster --profile JWON"
kafka_cluster_endpoint = "https://<...>.eks.amazonaws.com"
kafka_cluster_name = "eks-kafka-cluster"
kafka_kubeconfig_command = "aws eks update-kubeconfig ... --name eks-kafka-cluster --profile JWON"
monitoring_cluster_endpoint = "https://<...>.eks.amazonaws.com"
monitoring_cluster_name = "eks-monitoring-cluster"
monitoring_kubeconfig_command = "aws eks update-kubeconfig ... --name eks-monitoring-cluster --profile JWON"

7. 클러스터 접속 (kubeconfig 설정)

테라폼은 ~/.kube/config 파일을 자동으로 업데이트하지 않는다.

terraform apply 완료 후 출력(Outputs)된 3개의 kubeconfig_command 값을 복사해서 터미널에 각각 붙여넣고 실행해야 한다.

# 1. DataCenter 클러스터 접속 정보 추가
$ aws eks update-kubeconfig --region ap-northeast-2 --name eks-datacenter-cluster --profile JWON
Added new context arn:aws:eks:ap-northeast-2:ACCOUNT_ID:cluster/eks-datacenter-cluster to C:\Users\...\.kube\config

# 2. Kafka 클러스터 접속 정보 추가
$ aws eks update-kubeconfig --region ap-northeast-2 --name eks-kafka-cluster --profile JWON
Added new context arn:aws:eks:ap-northeast-2:ACCOUNT_ID:cluster/eks-kafka-cluster to C:\Users\...\.kube\config

# 3. Monitoring 클러스터 접속 정보 추가
$ aws eks update-kubeconfig --region ap-northeast-2 --name eks-monitoring-cluster --profile JWON
Added new context arn:aws:eks:ap-northeast-2:ACCOUNT_ID:cluster/eks-monitoring-cluster to C:\Users\...\.kube\config

이제 kubectl로 3개 클러스터에 모두 접속되는지 확인한다.

# 1. 컨텍스트 목록 확인 (3개 클러스터가 모두 보여야 함)
$ kubectl config get-contexts

CURRENT   NAME                                                        CLUSTER                                  ...
          arn:aws:eks:...:cluster/eks-datacenter-cluster              arn:aws:eks:...:cluster/eks-datacenter-cluster
          arn:aws:eks:...:cluster/eks-kafka-cluster                  arn:aws:eks:...:cluster/eks-kafka-cluster
*         arn:aws:eks:...:cluster/eks-monitoring-cluster             arn:aws:eks:...:cluster/eks-monitoring-cluster

# 2. 현재 활성 클러스터(monitoring) 노드 조회
$ kubectl get nodes
NAME                                           STATUS   ROLES    AGE   VERSION
ip-192-168-0-10.ap-northeast-2.compute.internal   Ready    <none>   2m    v1.30...
ip-192-168-1-20.ap-northeast-2.compute.internal    Ready    <none>   2m    v1.30...

# 3. 다른 클러스터(예: kafka)로 컨텍스트 변경
$ kubectl config use-context arn:aws:eks:...:cluster/eks-kafka-cluster
Switched to context "arn:aws:eks:...:cluster/eks-kafka-cluster".

# 4. Kafka 클러스터 노드 조회
$ kubectl get nodes
NAME                                           STATUS   ROLES    AGE   VERSION
ip-192-168-0-30.ap-northeast-2.compute.internal   Ready    <none>   3m    v1.30...
ip-192-168-1-40.ap-northeast-2.compute.internal    Ready    <none>   3m    v1.30...

팀원들이 해야 할 일 (권한 부여 후)

관리자가 aws-auth.tf를 포함하여 terraform apply를 완료했다면, 팀원들은 각자 PC에서 다음을 수행해야 한다.

AWS CLI 설치 및 본인 IAM 사용자로 aws configure --profile [본인프로필] 설정.
kubectl 설치.
(중요) 관리자에게 3개 클러스터의 update-kubeconfig 명령어를 받아서 3개 모두 실행한다. (위 7번 항목과 동일)

default 에 액세스 키 넣어놨으면 --profile [각자 프로필] 이 부분 빼고 쳐도 돼요

aws eks update-kubeconfig --region ap-northeast-2 --name eks-datacenter-cluster --profile [각자 프로필]

aws eks update-kubeconfig --region ap-northeast-2 --name eks-kafka-cluster --profile [각자 프로필]

aws eks update-kubeconfig --region ap-northeast-2 --name eks-monitoring-cluster --profile [각자 프로필]

이제 팀원들도 kubectl로 3개 클러스터에 모두 접속할 수 있다.

8. 클러스터 삭제 (정리)

단일 프로젝트로 통합 관리할 때의 가장 큰 장점이다. terraform destroy 단 하나의 명령어로 3개의 EKS 클러스터, 3개의 노드 그룹, 공유 VPC, 모든 IAM 역할 등 생성했던 모든 리소스(50+개)를 한 번에 삭제한다.

$ terraform destroy

...
Plan: 0 to add, 0 to change, 50 to destroy.
...
Do you really want to destroy all resources?
  Only 'yes' will be accepted to approve.

  Enter a value: yes  <-- "yes" 입력

...
aws_eks_node_group.datacenter_nodegroup: Destroying...
aws_eks_node_group.kafka_nodegroup: Destroying...
aws_eks_node_group.monitoring_nodegroup: Destroying...
...
Destroy complete! Resources: 50 destroyed.

kubectl config get-contexts 로 쓸데 없는 context 뜰 때 아래 명령어로 정리해주기

원래는 eks-datacenter-cluster, eks-kafka-cluster, eks-monitoring-cluster 3개만 있으면 됨

# 1. datacenter 컨텍스트 삭제
kubectl config delete-context arn:aws:eks:ap-northeast-2:484400672545:cluster/datacenter

# 2. datacenter 클러스터 정보 삭제
kubectl config delete-cluster arn:aws:eks:ap-northeast-2:484400672545:cluster/datacenter

# 3. datacenter 사용자 정보 삭제
kubectl config delete-user arn:aws:eks:ap-northeast-2:484400672545:cluster/datacenter

팀 프로젝트) Grafana를 위한 AWS API Gateway, Lambda, SNS 설정

Gom3rye — Tue, 11 Nov 2025 09:55:20 +0900

Prometheus Metric 정보를 Grafana Alertmanager, API Gateway와 Lambda를 통해 AWS SNS로 전송하기

온프레미스(On-premise) 환경의 Prometheus에서 발생하는 metric을 grafana에서 받아서 알림 기본 정보를 AWS의 API Gateway로 보내 SNS(Simple Notification Service)로 전송하는 아키텍처를 구축

Lambda 함수 생성 및 권한 설정

다음으로 API Gateway로부터 요청을 받아 SNS로 메시지를 전달하는 Lambda 함수를 생성한다.

각각의 metric을 담당하는 Lambda 함수 생성

주의: 코드 내의 SNS_TOPIC_ARN 변수 값을 환경 변수에 설정해야 한다.

CPU 기준 람다 함수 (10/2)

import json
import os
import re
import boto3
from datetime import datetime

SNS_TOPIC_ARN = os.environ["SNS_TOPIC_ARN"]
AWS_REGION = os.environ.get("AWS_REGION", "ap-northeast-2")
sns = boto3.client("sns", region_name=AWS_REGION)

def extract_numeric_value(value_string: str) -> str:
    """Grafana의 valueString에서 숫자만 추출 (예: 10, 85.4 등)"""
    if not value_string:
        return "데이터 없음"
    # "value=10" 또는 "value=85.4321" 같은 패턴에서 숫자만 추출
    match = re.search(r"value\s*=\s*([0-9]+(?:\.[0-9]+)?)", value_string)
    if match:
        return match.group(1)
    # 혹시 숫자 형태가 다르면 fallback으로 전체에서 숫자 추출
    match = re.search(r"([0-9]+(?:\.[0-9]+)?)", value_string)
    return match.group(1) if match else "데이터 없음"

def clean_summary(summary: str) -> str:
    if not summary:
        return "요약 정보 없음"
    return summary.replace("%!f(<nil>)", "데이터 없음").replace("[no value]", "데이터 없음")

def lambda_handler(event, context):
    print("[CPU] Event received:", json.dumps(event)[:1500])

    # 1️⃣ Body 파싱
    body = event.get("body", event)
    if isinstance(body, str):
        body = json.loads(body)
    payload = body

    alerts = payload.get("alerts", [])
    now_utc = datetime.utcnow().strftime("%Y-%m-%d %H:%M:%S UTC")

    details = []

    for a in alerts:
        labels = a.get("labels", {})
        annotations = a.get("annotations", {})

        # 인스턴스명
        instance = (
            a.get("instance")
            or labels.get("instance")
            or labels.get("pod")
            or labels.get("node")
            or "데이터 없음"
        )

        # ✅ valueString에서 숫자만 추출
        raw_value = a.get("valueString") or a.get("current_value") or ""
        cpu_value = extract_numeric_value(raw_value)

        # 요약 메시지 정리
        summary = clean_summary(
            annotations.get("summary") or annotations.get("description") or "요약 정보 없음"
        )

        start_time = (
            a.get("startsAt", "").replace("T", " ").replace("Z", " UTC")
            if a.get("startsAt")
            else "시간 정보 없음"
        )

        details.append(
            f"  인스턴스: {instance}\n"
            f"  현재 CPU 사용률: {cpu_value} %\n"
            f"  요약: {summary}\n"
            f"⏰ 발생 시각: {start_time}\n"
        )

    subject = "  [Grafana] CPU 사용률이 90%를 초과했습니다 !!!"
    message = f"""
⚙️ CPU 사용률 이상 감지
━━━━━━━━━━━━━━━━━━━━━━━
  감지 시각: {now_utc}
  알림 개수: {len(alerts)}건

  상세 정보:
{'-'*40}
{chr(10).join(details)}

 ️ 조치 가이드:
- CPU 사용률이 90% 이상인 인스턴스의 프로세스 상태를 점검하세요.
- 불필요한 백그라운드 작업을 중단하거나, 리소스 할당량을 조정하세요.
- 필요 시 워크로드를 다른 노드로 분산하거나 스케일 아웃을 고려하세요.
"""

    sns.publish(TopicArn=SNS_TOPIC_ARN, Message=message, Subject=subject[:100])
    return {"statusCode": 200, "body": json.dumps({"ok": True})}

API Gateway 엔드포인트 생성 및 Lambda 연동

마지막으로 외부(ElastAlert)에서 HTTP 요청을 보낼 수 있는 엔드포인트를 생성하고, 이를 Lambda 함수와 연결한다.

각각 과정에 대한 설명은 Elastalert2를 위한 AWS API Gateway, Lambda, SNS 설정 게시글에 있다.