Cloud

[Production Traffic] 특정 API 호출 시 CPU와 Memory가 급증할 경우를 대비한 사전 시뮬레이션

dml113 — Sun, 3 Aug 2025 15:33:21 +0900

들어가며

장애는 무작위가 아닌 ‘예고된 반복’이다.

운영 환경에서 장애는 종종 예고 없이 찾아오는 것처럼 보이지만, 대부분은 이미 수많은 징후를 포함한 반복적인 패턴 속에서 발생합니다.
그중 대표적인 것이 특정 API의 리소스 폭증입니다.

이번 포스팅에서는 다음과 같은 상황을 가정하여 테스트를 진행했습니다:

> "만약 특정 API가 예상치 못하게 CPU와 Memory를 고갈시킨다면, 현재의 ECS Auto Scaling 정책은 이 상황에 얼마나 잘 대응할 수 있을까?"

코드는 수정하지 않고, 인프라 수준에서 ECS (EC2 타입) 기반 Auto Scaling 정책을 설정하고 `/v1/stress` API를 반복 호출해 실제 리소스 폭증을 유발해 봤습니다.
이를 통해 지표 기반 Auto Scaling 정책의 실효성, 한계, 그리고 보완 방향을 사전에 점검해볼 수 있었습니다.

문제 상황 설명

운영 환경에서는 전체 트래픽은 정상적이어도 특정 API로 인해 CPU 사용률이 급격히 상승하는 경우가 존재합니다. 또한 예기치 못한 리소스 폭증은 ECS 서비스 전체의 안정성을 해치고, 때로는 EC2 인스턴스 자체가 고갈될 수도 있기에 사후 대응이 아닌 사전 예방을 위해, 이런 상황을 테스트 환경에서 직접 시뮬레이션 해보기로 결정하였습니다.

기존 대응 방식과 한계

초기에는 다음과 같은 ECS Task 사양으로 서비스를 구성했습니다:

항	설정 값
Task 수	2개
Task spec	0.25 vCPU, 0.5 GB Memory
Launch type	EC2 (ECS Capacity Provider)
Scaling 정책	없음 (고정 Task 수)

이 구성으로도 일반적인 API 요청 처리에는 큰 문제가 없었지만, `/v1/stress`처럼 CPU와 Memory를 집중적으로 사용하는 요청이 들어올 경우 각 Task가 리소스를 빠르게 고갈하며, 다음과 같은 문제가 발생했습니다:

- CPU 사용률 90% 이상이 수 분간 지속

- Task 수 고정으로 인해 Auto Scaling 불가

성능 측정 결과

해당 조건에서 K6로 /v1/stress API를 테스트했을 때의 수치는 다음과 같습니다:

문제 해결

이러한 문제들을 해결하기 위해, 다음 단계에서는 다음과 같은 개선을 시도하였습니다:

- Task 사양 상향 조정 (0.25 → 0.5 vCPU)

- ECS Service Auto Scaling 정책 적용

적용 방법 (구체 구성)

앞서 언급한 두 가지 전략 — Task 사양 상향 조정과 Auto Scaling 정책 적용 — 을 실험 환경에 직접 반영해 보았습니다.

1. Task 사양 상향 조정

먼저 Task 정의(Task Definition)의 리소스 설정을 다음과 같이 변경하였습니다:

항목	기존 값	변경 값
vCPU	0.25	0.5
Memory	0.5 GB	1 GB

기존에 비해 약 2배 이상 리소스를 확보함으로써, 각 Task가 더 많은 요청을 감당할 수 있도록 했습니다.

2. ECS Auto Scaling 정책 적용

Task 사양만 높이는 것은 일시적 완화책일 뿐, 트래픽이 지속적으로 유입되거나 급격히 증가하는 경우에는 Task 수 자체의 자동 확장이 필요합니다.
이를 위해 ECS Service에 CPU 사용률 기반 Auto Scaling을 설정했습니다.

설정 조건:

정책 유형: Target Tracking

Target CPU 사용률: 60%

최소 Task 수: 2개

최대 Task 수: 6개

성능 측정 결과 (전/후 비교)

테스트 조건 요약

테스트 도구: k6
요청 API: /v1/stress
요청 수: 동시접속자 5명, 60초 동안 진행
테스트 목적: 리소스 폭증 시 ECS Auto Scaling 정책이 실제로 응답 속도 및 시스템 자원 사용에 어떤 영향을 주는지 측정

개선 전 (기존 고정 Task 수, 0.25 vCPU / 0.5GB Memory)

평균 응답 시간 (avg)	356.1ms
중앙값 응답 시간 (med)	345.2ms
90 percentile (p90)	622.8ms
95 percentile (p95)	739.5ms
CPU 사용률	90% 이상 지속
실패율	0%

개선 후 (0.5 vCPU / 1GB Memory + Auto Scaling 2~6 Tasks)

평균 응답 시간 (avg)	290.6ms
중앙값 응답 시간 (med)	287.4ms
90 percentile (p90)	393.9ms
95 percentile (p95)	413.7ms
CPU 사용률 (평균)	47%
실패율	0%

개선 효과

평균 응답 시간이 약 65ms 개선 (약 18% 성능 향상)
지연이 심한 상위 10~5% 구간(p90/p95)에서도 300ms 이상 응답 확보
CPU 사용률이 안정 구간(40~50%)에 위치하면서, 스케일 아웃 트리거 발생
Task 수가 증가하면서 리소스를 유연하게 분산, 서비스 안정성 향상

개선하기 전과 개선한 후의 지표

회고

내가 배운 점

1. Auto Scaling은 단순히 '붙이면 끝'이 아니다.

ECS Auto Scaling을 적용하기 전까지는 단순히 Task 수만 늘리면 되는 줄 알았습니다.

하지만 실제로는 아래와 같은 튜닝 요소들이 중요하다는 점을 깨달았습니다.

Scaling 정책의 트리거 지표(CPU, Memory 등) 선정

Scaling 반영 주기(Cooldown time)

최소/최대 Task 수의 적절한 범위 설정

2. 코드를 변경하지 않아도 ‘운영 품질’을 충분히 개선할 수 있다.

코드 레벨에서 비동기 처리, 리팩토링 등은 물론 중요하지만, 인프라 레벨의 대응 정책만으로도 리소스 과부하 문제를 어느 정도 해소할 수 있다는 것을 직접 경험했습니다.
특히 서비스 안정성은 트래픽 증가 상황에서 자동으로 확장되고, 축소되는 구조를 사전에 확보하는 것이 핵심임을 체감했습니다.

3. 평균값이 아니라 percentile 지표를 보는 것이 효율적일 수 있다.

단순 평균(avg)만으로는 문제가 드러나지 않았고, p90, p95 구간의 튐 현상에서야 비로소 실제 사용자 경험 저하가 확인되었습니다.
SLA나 운영지표는 반드시 percentile 기반으로 분석해야 한다는 교훈을 얻었습니다.

다음 개선 방향

1. Memory 기반의 Scaling 정책 병행

현재는 CPU 기반으로만 Scaling이 동작하지만, /v1/stress API처럼 메모리 사용률이 급격히 증가하는 경우를 위해 Memory 사용률 기준의 보조 정책도 병행 적용할 계획입니다.

2. Application Load Balancer의 Target 반응 속도 연동 지표 추적

Scaling이 발생했을 때, 실제 사용자에게 얼마나 빠르게 개선 효과가 도달했는지를 ALB의 Target Response Time 지표와 연동하여 측정하는 구조도 함께 고려하고 있습니다.

마무리

이번 테스트를 통해 리소스에 대한 지표의 중요도와 리소스의 설정값으로 인해 인프라에 어떤 영항을 끼치는지에 대해서 알게되었습니다.

이번 테스트로 앞으로 모니터링 시스템 구축을 더 찾아보고 보기 쉽게 정리할 수 있도록 하겠습니다.

[Production Traffic] MySQL 인덱스 전후 성능 차이, 실무 부하 테스트로 증명하기

dml113 — Sat, 2 Aug 2025 22:24:14 +0900

들어가며

현재 운영 중인 애플리케이션에서 특정 API의 응답 속도가 눈에 띄게 느려지는 현상이 발생하고 있었습니다. 사용자 입장에서는 페이지가 늦게 뜨고, 모니터링 시스템에서는 평균 응답 속도가 높게 유지되며 경고 알람이 자주 발생했습니다.

문제가 된 API는 단순히 MySQL에서 특정 조건(`email`)을 만족하는 데이터를 조회하는 쿼리 하나뿐이었습니다. 로직도 복잡하지 않고, 데이터의 양도 수백만 건 수준이라 아직 임계점이라고 보기도 어려운 상황이었죠.

그래서 이 문제를 해결하기 위해, 쿼리 성능 분석과 함께 MySQL의 인덱스(Index)를 활용한 성능 개선 작업을 진행했습니다. 그리고 이 효과를 k6 부하 테스트 도구를 통해 수치로 증명해 보았습니다.

이번 글에서는 인덱스를 적용하기 전/후의 부하 테스트 결과를 통해 성능 차이를 어떻게 체감할 수 있었는지 실제 데이터를 바탕으로 정리해보려고 합니다.

테스트 환경

본 테스트는 현재 운영 중인 Golang 기반 애플리케이션을 대상으로 진행했습니다.
애플리케이션은 MySQL 8.0.42 버전을 사용하고 있으며, API 형태로 클라이언트와 통신합니다.

데이터 흐름

사용자 정보는 다음과 같은 방식으로 처리됩니다:

1. 데이터 저장 (POST)

- 경로: `POST /v1/user`
- Request Body 예시:

{
	"requestid": "999999999999",
	"uuid": "7c5a3c6a-758f-4bc5-9bdf-3e573a0ad729",
	"username": "dbdump500001",
	"email": "dbdump500001@example.org",
	"status_message": "I’m happy"
}

2. 데이터 조회 (GET)

- 경로: `GET /v1/user`
- 쿼리 예시:

/v1/user?email=dbdump500001@example.org&requestid=999999999999&uuid=7c5a3c6a-758f-4bc5-9bdf-3e573a0ad729

- 하지만 실질적으로는 `email` 값만을 기준으로 DB에서 데이터를 조회하고 있으며, `requestid`와 `uuid`는 쿼리에는 포함되지만 데이터베이스에 저장하거나 검색 조건으로 사용하지 않습니다.

기술스택

- **언어:** Go (Golang)
- **DBMS:** MySQL 8.0.42
- **부하 테스트 도구:** [k6](https://k6.io)

문제 상황: 인덱스 적용 전 성능

애플리케이션에서 사용자의 이메일(`email`)을 기준으로 데이터를 조회하는 요청이 점점 증가하면서,
DB 쿼리 성능 저하가 체감될 정도로 발생하기 시작했습니다.

실제 운영 중인 서비스에서는 사용자 수가 많아질수록 단일 칼럼(email)에 대한 풀스캔(full table scan) 발생 빈도가 높아졌고,
이에 따라 다음과 같은 문제가 확인되었습니다:

- 평균 응답 속도가 높음
- 응답 시간 편차가 큼 (최대 975ms까지 도달)
- p95 응답 시간 기준으로도 700ms를 초과

부하 테스트 결과 (인덱스 적용 전)

k6를 이용해 `/v1/user` 경로에 대해 `email` 기준 동시접속자 5명으로 20초 동안 GET 요청을 반복 수행한 결과입니다:

- 평균 응답 시간: 356.1ms
- 95퍼센타일(p95): 739.54ms
- 최대 응답 시간: 975.71ms

원인 분석

현재 테이블에는 `email` 칼럼에 인덱스가 설정되어 있지 않으며, 그에 따라 `WHERE email =?` 조건이 들어가는 쿼리마다 전체 테이블을 스캔하는 방식으로 동작하고 있었습니다.

이는 다음과 같은 상황에서 치명적입니다:
- 사용자가 많을수록 성능이 선형적으로 저하됨
- 오토스케일링이 DB 부하를 감당하지 못하는 병목 지점이 됨
- 조회 요청이 많아지면 API 전체 응답 성능에 악영향을 줌

개선 방법: 인덱스 적용

문제의 핵심은 `email` 컬럼에 대한 빈번한 조건 조회가 발생하고 있음에도,
해당 컬럼에 적절한 인덱스가 존재하지 않았던 것이었습니다.

이에 따라 다음과 같이 인덱스를 생성했습니다:

CREATE INDEX idx_users_email ON user(email);

테이블명: users

인덱스명: idx_users_email

대상 컬럼: email

인덱스를 추가한 이후, 기존의 WHERE email =? 쿼리는 풀스캔이 아닌 인덱스 탐색(index seek) 방식으로 처리되기 시작했습니다.

인덱스 적용 후 예상된 변화

email 조건에 대한 탐색 성능 향상

응답 시간의 일관성 개선 (지연 시간 편차 축소)

전체 응답 속도 평균 및 p95 이하로 안정화 기대

테스트 환경 고정값

DB 버전: MySQL 8.0.42

API 언어: Golang

테스트 방식:

/v1/user 엔드포인트로 GET 요청
? email=dbdump500001@example.org
requestid, uuid는 전달되지만 저장되지 않음
email 기준으로만 조회 쿼리 발생

성능 측정 결과와 비교 분석

인덱스를 적용한 후 동일한 조건으로 k6 부하 테스트를 다시 실행했습니다.
아래는 테스트 결과 주요 지표입니다:

- 평균 응답 시간: 약 19ms
- 최소 응답 시간: 13ms
- 중앙값 응답 시간: 17.5ms
- 최대 응답 시간: 31ms
- 95 퍼센타일 응답 시간: 28ms

비교 요약

지표	인덱스 적용 전	인덱스 적용 후	향상율 (대략)
평균 응답 시간	356ms	19ms	약 95% 감소
95퍼센타일 응답 시간	739ms	28m	약 96% 감소
최대 응답 시간	975ms	31ms	약 97% 감소

아래의 사진은 왼쪽이 index 설정하기 전이며, 오른쪽이 index 설정 후의 결괏값입니다.

분석 및 의의

- 인덱스 생성만으로 평균 응답 속도가 356ms에서 19ms로 급격히 개선되었습니다.
- p95 응답 시간도 739ms에서 28ms로 대폭 단축되어, 사용자 체감 성능이 크게 향상됨을 의미합니다.
- 쿼리의 전체 테이블 스캔이 아닌, 인덱스를 활용한 빠른 탐색으로 전환되었기 때문입니다.
- 이번 테스트를 통해 작은 인덱스 하나가 서비스 성능에 얼마나 큰 영향을 미치는지 직접 체감할 수 있었습니다.

실무적 교훈과 회고

이번 프로젝트를 통해 얻은 가장 큰 교훈은 다음과 같습니다.

1. 쿼리 성능 문제의 첫 단추는 인덱스부터 점검해야 한다

성능 저하 문제를 만났을 때 가장 먼저 확인할 것은 데이터베이스 쿼리의 실행 계획입니다.
특히 자주 사용하는 조건 칼럼에 적절한 인덱스가 없으면,
작은 데이터셋이라도 예상보다 훨씬 느린 응답 시간을 초래할 수 있음을 몸소 경험했습니다.

2. 인덱스 하나가 서비스 전체 성능에 미치는 영향은 매우 크다

이번 사례처럼, 복잡한 최적화나 캐시 도입 없이도 단순히 인덱스 생성만으로 API 응답 속도가 95% 이상 개선될 수 있다는 사실은 모든 개발자가 놓치지 말아야 할 기본 중 기본입니다.

3. 부하 테스트를 통한 성능 검증은 필수

성능 개선 후 무작정 “빠르다”라고 판단하는 대신, 부하 테스트 도구(k6 등)를 사용해 체계적으로 수치를 확인하고 비교하는 과정이 매우 중요합니다.
이를 통해 실제 사용자 환경과 유사한 조건에서 신뢰할 수 있는 데이터를 확보할 수 있었습니다.

4. 지나친 인덱스 남발은 피해야 한다

하지만 무조건적으로 인덱스를 사용한다고 좋은 것은 아닙니다. 인덱스를 사용하면 읽기 성능은 향상하지만, 쓰기 성능에 대해서는 오히려 악효과가 됩니다. 따라서 조회 패턴을 분석하여, 필요한 칼럼에만 최소한의 인덱스를 설정할 줄 알아야 합니다.

마무리

이번 경험을 통해 다시 한 번 데이터베이스 설계와 운영에서 인덱스의 중요성을 실감했습니다.
앞으로도 서비스 성능 이슈가 발생하면 우선적으로 쿼리 실행 계획과 인덱스를 점검하는 습관을 꼭 지키겠습니다.

[Production Traffic] DynamoDB 쿼리가 느려터졌다면? GSI로 빠르게 만들자 – 실전 튜닝 사례

dml113 — Tue, 29 Jul 2025 23:27:56 +0900

배경

최근 사용 중인 Golang 애플리케이션에서 특정 API의 응답 속도가 느려, 사용자에게 정보를 빠르게 제공하지 못하는 문제가 있었습니다.
분석 결과, DynamoDB에서 `Scan`을 사용해 데이터를 조회하고 있었고, 이로 인해 성능이 크게 저하되고 있었습니다.

쿼리 효율화를 위해 Global Secondary Index(GSI)를 도입해 문제를 해결하고자 했습니다.

인프라 구성

0.25vCPU, 0.5GB을 가진 ECS Task 2대로 구성하였으며, 해당 애플리케이션은 다음과 같은 구조에서 동작합니다:

Client → ALB → ECS (Golang App) → DynamoDB

- POST Method: 새로운 데이터를 DynamoDB에 삽입
- GET Method: 특정 조건으로 데이터를 조회 (문제 발생 지점)

문제 상황

인프라 부하 테스트를 위해 [k6](https://k6.io/)를 사용하여 동시접속자 100명이 약 20초간 POST → GET 요청을 반복 수행하도록 설정했습니다.

그 결과, 다음과 같은 성능 병목이 관측되었습니다:

- 테스트 중 전체 요청 수: 5,746건, 초당 요청 처리량: 278 RPS
- `GET /v1/product?id=xxx&requestid=yyy&uuid=zzz` 요청이 문제의 핵심
- DynamoDB 테이블은 `id`를 Partition Key로 사용하고 있었으나,
실제 조회 조건은 `requestid`와 `uuid` 조합이 필요 → `Scan + FilterExpression` 사용 중
- 평균 응답 시간: 101.83ms
- P90 응답 시간: 197.79ms, P95 응답 시간: 276.16ms, 최대 응답 시간: 510.68ms
- 실패율: 0.01% (1건) 으로 무시 가능 수준

표면적으로 평균 응답 시간은 양호해 보이지만, 실제 서비스 상황에서는 다양한 요청 조건에서 Query Latency가 500ms 이상까지 증가하며 사용자 체감이 발생할 수 있는 수준이었습니다.

특히, 데이터가 누적됨에 따라 Scan 성능이 기하급수적으로 저하될 우려가 있었고, 이는 추후 확장성과 운영 안정성 측면에서도 **중대한 병목 요소**로 판단되었습니다.

해결방법

DynamoDB는 기본적으로 테이블의 파티션 키(Partition Key) 조합으로만 Query가 가능합니다. 하지만, 본 애플리케이션은 uuid와 requestid를 기준으로 조건 검색이 필요했기 때문에 Scan + FilterExpression이라는 비효율적인 방식으로 동작 중이었습니다.

이를 해결하기 위해 GSI(Global Secondary Index) 를 도입하여, uuid를 파티션 키로, requestid를 정렬 키로 설정하였습니다.

코드 변경: Scan → Query

기존에는 DynamoDB에서 데이터를 조회할 때 Scan + FilterExpression 방식으로 동작하고 있었습니다.
이 방식은 전체 테이블을 순회하므로, 데이터가 많아질수록 응답 시간이 길어지고 비용도 증가합니다.

이를 해결하기 위해, Global Secondary Index (GSI) 를 생성하고 Golang 애플리케이션 내 코드를 Scan 기반에서 Query 기반으로 리팩토링했습니다.

아래는 리팩토링된 전체 코드이며, 환경변수 TABLE_INDEX_NAME 이 존재할 경우 GSI 기반 쿼리(Query) 를 수행하고, 존재하지 않을 경우 fallback 으로 Scan 을 수행하는 구조입니다.

main.go (클릭하여 전체 코드 보기)

package main
import (
	"fmt"
	"net/http"
	"os"

	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/dynamodb"
	"github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute"
	"github.com/gin-gonic/gin"
)

type Product struct {
	ID        string `json:"id"`
	UUID      string `json:"uuid"`
	RequestID string `json:"requestid"`
	Name      string `json:"name"`
	Price     int    `json:"price"`
}

func main() {
	tableName := os.Getenv("TABLE_NAME")
	indexName := os.Getenv("TABLE_INDEX_NAME")

	sess := session.Must(session.NewSession())
	svc := dynamodb.New(sess)

	router := gin.Default()

	router.GET("/v1/product", func(c *gin.Context) {
		id := c.Query("id")
		requestid := c.Query("requestid")
		uuid := c.Query("uuid")

		var result Product
		var err error

		if indexName != "" {
			// GSI 쿼리
			queryInput := &dynamodb.QueryInput{
				TableName:              aws.String(tableName),
				IndexName:              aws.String(indexName),
				KeyConditionExpression: aws.String("#uuid = :uuid AND #requestid = :requestid"),
				ExpressionAttributeNames: map[string]*string{
					"#uuid":      aws.String("uuid"),
					"#requestid": aws.String("requestid"),
				},
				ExpressionAttributeValues: map[string]*dynamodb.AttributeValue{
					":uuid":      {S: aws.String(uuid)},
					":requestid": {S: aws.String(requestid)},
				},
			}

			queryOutput, err := svc.Query(queryInput)
			if err != nil || len(queryOutput.Items) == 0 {
				c.JSON(http.StatusNotFound, gin.H{"error": "Product not found"})
				return
			}
			err = dynamodbattribute.UnmarshalMap(queryOutput.Items[0], &result)
			if err != nil {
				c.JSON(http.StatusInternalServerError, gin.H{"error": "Failed to unmarshal result"})
				return
			}
		} else {
			// Scan fallback
			scanInput := &dynamodb.ScanInput{
				TableName: aws.String(tableName),
				FilterExpression: aws.String("#uuid = :uuid AND #requestid = :requestid"),
				ExpressionAttributeNames: map[string]*string{
					"#uuid":      aws.String("uuid"),
					"#requestid": aws.String("requestid"),
				},
				ExpressionAttributeValues: map[string]*dynamodb.AttributeValue{
					":uuid":      {S: aws.String(uuid)},
					":requestid": {S: aws.String(requestid)},
				},
			}

			scanOutput, err := svc.Scan(scanInput)
			if err != nil || len(scanOutput.Items) == 0 {
				c.JSON(http.StatusNotFound, gin.H{"error": "Product not found"})
				return
			}
			err = dynamodbattribute.UnmarshalMap(scanOutput.Items[0], &result)
			if err != nil {
				c.JSON(http.StatusInternalServerError, gin.H{"error": "Failed to unmarshal result"})
				return
			}
		}

		c.JSON(http.StatusOK, result)
	})

	router.Run(":8080")
}

위 코드 구조의 핵심은 다음과 같습니다:

- TABLE_INDEX_NAME 환경변수가 존재하면 → GSI 기반 Query

- 환경변수가 없으면 → 기존 Scan + FilterExpression fallback

- uuid를 Partition Key로, requestid를 Sort Key로 하는 GSI가 필요

성능 개선 결과 (Index 적용 후) -

- 전체 요청 수: 7,024건, 초당 요청 처리량: 341.59 RPS

- 평균 응답 시간: 35.56ms

- P90 응답 시간: 79.77ms, P95 응답 시간: 119.79ms, 최대 응답 시간: 413.33ms

- 실패율: 0.01% (1건)

GSI 설정 이후 평균 응답 시간 101.83ms → 35.56ms 로 65% 이상 성능 개선되었으며, RPS 약 23% 증가 (278 → 341) 했습니다.

회고

GSI 하나로 성능이 3배 빨라졌다 – 설정 하나의 위력

최근에 작은 프로젝트를 하나 운영하면서 "그렇게 중요해 보이지 않았던 설정 하나가 얼마나 치명적일 수 있는지" 뼈저리게 느꼈다.

처음엔 그냥 DynamoDB 테이블 하나 만들고, id 기준으로 Primary Key를 설정해 데이터를 쌓고 있었다. 애플리케이션은 Go(Golang)으로 작성했고, AWS ECS EC2 Task에서 실행되도록 구성했으며, 해당 Task에서 직접 DynamoDB와 연동해 데이터를 조회하는 구조였다. 처음에는 문제 없어 보였다. 실제로 API도 잘 동작했고, 예상한 대로 결과도 나왔다.

Scan으로는 문제가 많았고, 이 서비스는 클라이언트에서 uuid랑 requestid로 데이터를 조회해야 했는데, 테이블은 id 기준으로 구성돼 있었다. 즉, 조건에 맞는 데이터를 가져오려면 무조건 Scan + FilterExpression으로 모든 항목을 돌면서 일일이 체크해야 했다.

작은 데이터셋에선 티가 안 났다. 근데 k6로 부하 테스트를 돌려보니 문제가 명확해졌다.

구분 Scan 사용 시:

평균 응답 시간	101.83ms
P90	197.79ms
P95	276.16ms
최대	510.68ms

이건 단순히 느린 수준이 아니라, 지속적으로 사용하기에는 위험했다. 특히 사용자가 많아지거나, 테이블이 더 커졌을 때 상황은 문제가 커졌다.

GSI 하나로 체감 성능이 달라졌다

그래서 도입한 게 Global Secondary Index(GSI) 였다.

Partition Key: uuid
Sort Key: requestid

딱 우리가 조회하고 싶은 구조 그대로를 Index로 설계해서, 기존의 Scan을 Query로 대체했다. 단, 이게 모든 환경에서 항상 적용될 수는 없기에 코드 내에 TABLE_INDEX_NAME 이라는 환경 변수를 사용해서 인덱스 존재 여부에 따라 Scan ↔ Query를 자동 전환하도록 구성했다.

그리고 다시 성능을 측정해봤다.

구분 GSI 적용 후:

평균 응답 시간	35.56ms
P90	79.77ms
P95	119.79ms
최대	413.33ms

응답 속도가 3배 가까이 줄어들었다.
특히 평균 응답 시간이 100ms → 35ms로 줄어든 건 정말 체감이 클 수밖에 없다.

그리고 데이터는 절대 그대로 있지 않는다

지금은 괜찮다고 안심할 수 없다.

데이터는 무조건 늘어나게 되어 있다. 1MB, 10MB였던 데이터가 몇 달 후엔 1GB, 10GB가 되고, 그때도 Scan을 돌리고 있다면? 성능 차이는 선형이 아니라 기하급수적으로 벌어질 것이다. 지금 당장은 안 터질 수도 있다.

하지만 언젠간 반드시 병목이 된다.

마무리

DynamoDB는 굉장히 빠르고 유연한 서비스다.
하지만 아무리 좋은 기술도 잘못 설계된 구조 위에서는 성능을 보장할 수 없다.

데이터 접근 패턴을 먼저 정의하고
그에 맞는 PK, SK, GSI 구조를 잡고
fallback 구조도 코드에 녹여두고

이런 기초적인 설계가 가장 중요하다는 걸 이번에 다시 깨달았다.
앞으로는 절대 Scan부터 쓰는 일은 없을 것 같다.

[AWS Service] 생성한 EC2에 EBS 마운트하는 방법

dml113 — Thu, 12 Jun 2025 23:01:35 +0900

안녕하세요. 이번 글에서는 생성한 EC2에 EBS를 마운트하는 방법에 대해서 적어보도록 하겠습니다.

먼저 EC2에 마운트 작업을 하기 때문에 Default VPC를 사용하겠습니다.

사전준비

먼저 Default VPC 혹은 VPC를 생성하고, 임의의 EC2를 생성합니다.

1. EBS 생성

먼저 생성한 EC2에 붙힐 EBS를 생성합니다.

원하는 Volume type와 Size 등등 잘 설정하여 생성합니다.

2. EC2에 EBS 연결

EC2에 생성한 EBS를 Attach 해줍니다.

원하는 Instance를 선택하고 Device name을 선택 후 Attach 합니다.

3. EBS 마운트

EBS를 마운트하기 위해 먼저 EC2에 접근합니다.

접근 후 아래 명령어를 실행하면 아래와 같이 마운트되지 않은 디스크가 추가되어 있습니다.

lsblk

# output:
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0    8G  0 disk
├─nvme0n1p1   259:1    0    8G  0 part /
├─nvme0n1p127 259:2    0    1M  0 part
└─nvme0n1p128 259:3    0   10M  0 part /boot/efi
nvme1n1       259:4    0  100G  0 disk

확인하였다면 이제 파일시스템을 생성합니다.

mkfs -t ext4 /dev/nvme1n1

# output:
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: 92eddf0f-e69f-4ab9-a418-44426d648382
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (131072 blocks):
done
Writing superblocks and filesystem accounting information: done

파일시스템까지 생성하였다면 마운트할 디렉토리를 생성합니다.

mkdir /data

전 /data라는 디렉토리에다가 마운트해보겠습니다.

mount /dev/nvme1n1 /data

4. 마운트 확인

아래 명령어를 사용하여 정상적으로 마운트되었는지 확인합니다.

df -h

# output:
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          4.0M     0  4.0M   0% /dev
tmpfs             453M     0  453M   0% /dev/shm
tmpfs             181M  432K  181M   1% /run
/dev/nvme0n1p1    8.0G  1.6G  6.5G  20% /
tmpfs             453M     0  453M   0% /tmp
/dev/nvme0n1p128   10M  1.3M  8.7M  13% /boot/efi
tmpfs              91M     0   91M   0% /run/user/0

5. 마무리

오늘은 생성된 EC2에 새로운 Volume을 마운트하는 작업을 해봤습니다.

읽어주셔서 감사합니다.

[Kubernetes] 여러 Kubernetes 네임스페이스에서 단일 ALB Ingress 사용하기

dml113 — Sun, 16 Feb 2025 13:50:40 +0900

이번 글에서는 Amazon EKS에서 단일 AWS Application Load Balancer(ALB)를 사용하여 여러 Kubernetes 네임스페이스에 배포된 서비스에 대한 인그레스 트래픽을 관리하는 방법을 소개합니다. 구체적으로, 서로 다른 네임스페이스에 배포된 두 개의 서비스(HTTPD와 NGINX)에 대해 ALB Ingress Controller를 설정하고 URL 경로를 기준으로 트래픽을 라우팅하는 방법을 설명합니다.

사전 준비

시작하기 전에 다음 사항들을 확인해야 합니다:

EKS 클러스터가 정상적으로 작동하고 있어야 합니다.
ALB Ingress Controller가 클러스터에 설치되어 있어야 합니다. 설치 방법은 공식 문서를 참조하세요.

1. httpd 네임스페이스에 HTTPD 애플리케이션 배포하기

우선 httpd 네임스페이스에 HTTPD 서비스를 배포합니다. 아래는 HTTPD 배포 및 서비스에 대한 매니페스트 파일입니다.

# httpd.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-deployment
  namespace: httpd
spec:
  selector:
    matchLabels:
      app: httpd
  replicas: 2
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: httpd
spec:
  type: NodePort
  selector:
    app: httpd
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP

위 매니페스트는 httpd 네임스페이스에 HTTPD 컨테이너 2개로 구성된 배포를 생성합니다.
서비스는 NodePort 유형으로 설정되어 있으며, 80번 포트를 외부로 노출합니다.

2. nginx 네임스페이스에 NGINX 애플리케이션 배포하기

다음으로, nginx 네임스페이스에 NGINX 서비스를 배포합니다. 아래는 NGINX 배포 및 서비스에 대한 매니페스트 파일입니다.

# nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: nginx
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP

이 매니페스트는 nginx 네임스페이스에 2개의 NGINX 컨테이너로 구성된 배포를 생성합니다.
서비스는 NodePort 유형으로 설정되어 있으며, 80번 포트를 외부로 노출합니다.

3. ALB Ingress 설정

이제, 두 네임스페이스의 서비스를 ALB를 통해 라우팅할 수 있도록 Ingress 리소스를 설정합니다. 먼저, HTTPD 애플리케이션에 대한 Ingress를 설정합니다.

# httpd-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: instance
    alb.ingress.kubernetes.io/group.name: "test"
spec:
  rules:
    - http:
        paths:
          - path: /httpd
            pathType: Prefix
            backend:
              service:
                name: httpd
                port:
                  number: 80

위 매니페스트는 /httpd 경로로 들어오는 요청을 httpd 서비스로 라우팅합니다.

# nginx-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: skills-ingress
  namespace: nginx
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: instance
    alb.ingress.kubernetes.io/group.name: "test"
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx
                port:
                  number: 80

이 매니페스트는 / 경로로 들어오는 요청을 nginx 서비스로 라우팅합니다.

결과

위의 매니페스트 파일들을 적용한 후 생성되는 ALB에서는 다음과 같은 경로로 트래픽을 라우팅할 수 있습니다:

/ 경로로 접속하면 NGINX 페이지가 표시됩니다.
/httpd 경로로 접속하면 HTTPD 페이지가 표시됩니다.

이처럼 하나의 ALB를 사용하여 여러 네임스페이스에 배포된 서비스들에 대해 경로 기반으로 트래픽을 라우팅할 수 있습니다. 이 방법을 통해 다양한 서비스들을 효율적으로 관리할 수 있습니다.

[AWS Service] MWAA와 Glue를 연동하여 데이터 파이프라인 구축하기

dml113 — Sat, 15 Feb 2025 23:26:59 +0900

안녕하세요! 오늘은 Amazon MWAA (Managed Workflows for Apache Airflow)와 AWS Glue를 연동하여 데이터 파이프라인을 구축하는 방법에 대해 알아보겠습니다. MWAA는 Airflow를 관리형 서비스로 제공하여 데이터 엔지니어링 워크플로우를 쉽게 관리할 수 있도록 해줍니다. Glue는 서버리스 ETL(추출, 변환, 로드) 서비스로, 데이터를 정리하고 변환하는 데 사용됩니다.

1. S3 버킷 생성

먼저, S3 버킷을 두 개 생성합니다.

mwaa-scripts-s3: MWAA 스크립트, DAG, 플러그인, 요구 사항 파일을 저장하는 데 사용됩니다.
mwaa-dataset-s3: 처리할 CSV 파일을 업로드할 데이터셋 저장소로 사용됩니다.

2. 로컬 환경 설정 (MWAA Local Runner)

Amazon MWAA에서 바로 작업을 시작하기 전에 로컬 환경에서 코드를 테스트하는 것이 좋습니다. 다음 단계를 따라 로컬 환경을 설정합니다.

2.1. Bastion 호스트 설정

원하는 인스턴스 타입을 사용하여 인스턴스를 사용합니다. 다음 명령을 실행하여 Docker와 Git을 설치합니다.

sudo dnf install -y docker
sudo systemctl enable --now docker
sudo usermod -a -G docker ec2-user
sudo su - ec2-user
sudo dnf install -y git

2.2. MWAA Local Runner 클론 및 설정

GitHub에서 aws-mwaa-local-runner 리포지토리를 클론하고 디렉터리로 이동합니다.

git clone https://github.com/aws/aws-mwaa-local-runner.git
cd aws-mwaa-local-runner

Docker 이미지를 빌드합니다.

./mwaa-local-env build-image

로컬 서버를 시작합니다.

./mwaa-local-env start

3. Airflow DAG 작성

Airflow DAG 파일을 작성하여 S3 파일 감지 후 Glue 작업을 트리거하도록 설정합니다. 아래는 예시 DAG 코드입니다 (/dags/etl-dags.py).

from airflow import DAG
from airflow.providers.amazon.aws.operators.glue import GlueJobOperator
from airflow.providers.amazon.aws.sensors.s3 import S3KeySensor
from datetime import datetime, timedelta

default_args = {
    "owner": "airflow",
    "depends_on_past": False,
    "start_date": datetime(2024, 2, 15),
    "email_on_failure": False,
    "email_on_retry": False,
    "retries": 1,
    "retry_delay": timedelta(minutes=5),
}

dag = DAG(
    "s3_trigger_glue_jobs",
    default_args = default_args,
    schedule_interval = None,
    catchup = False
)

s3_sensor = S3KeySensor(
    task_id = "s3_file_sensor",
    bucket_name = "mwaa-dataset-s3-0410",
    bucket_key = "raw/*.csv",
    wildcard_match = True,
    aws_conn_id="aws_default",
    timeout=600,
    poke_interval=30,
    dag=dag,
)

glue_task = GlueJobOperator(
    task_id = "glue_job",
    job_name = "mwaa-job",
    script_location=f"s3://mwaa-scripts-s3-0410/scripts/glue.py",
    s3_bucket="mwaa-scripts-s3-0410",
    create_job_kwargs={"GlueVersion": "4.0", "NumberOfWorkers": 2, "WorkerType": "G.1X"}

)

s3_sensor >> glue_task

4. Glue Job 생성

mwaa-job이라는 이름을 가진 job을 생성합니다.

AWS Glue에서 생성한 스크립트를 Bastion 호스트의 /scripts/glue.py에 저장합니다. 이 스크립트는 MWAA에서 트리거될 Glue 작업을 정의합니다.

5. S3 버킷에 파일 업로드

다음 명령을 사용하여 스크립트, DAG, 요구 사항 파일 등을 mwaa-scripts-s3 버킷에 업로드합니다.

aws s3 cp scripts/ s3://mwaa-scripts-s3-0410/scripts --recursive
aws s3 cp dags/ s3://mwaa-scripts-s3-0410/dags/ --recursive
aws s3 cp requirements/ s3://mwaa-scripts-s3-0410/requirements/ --recursive
aws s3 cp plugins/ s3://mwaa-scripts-s3-0410/plugins/ --recursive

6. MWAA 환경 생성 및 설정

AWS 콘솔에서 MWAA 환경을 생성합니다.

MWAA가 사용할 IAM 역할에 Admin 권한을 부여해야 합니다.

7. Airflow UI에서 DAG 실행

Airflow UI에 접속하여 DAG를 트리거합니다. "Trigger DAG" 버튼을 클릭하여 DAG를 실행합니다.

8. 성공 확인

Airflow UI에서 DAG 실행 상태를 확인합니다. 모든 작업이 성공적으로 완료되면 다음과 유사한 화면이 표시됩니다.

결론

이 가이드에서는 Amazon MWAA와 AWS Glue를 연동하여 데이터 파이프라인을 구축하는 방법을 설명했습니다. 이 구성을 통해 데이터 워크플로우를 자동화하고 확장 가능한 데이터 처리 시스템을 구축할 수 있습니다.

[Kubernetes] Kubernetes Mutating Webhook을 이용한 Sidecar 자동 주입 가이드

dml113 — Fri, 14 Feb 2025 19:22:10 +0900

이번 글에서는 Kubernetes Mutating Webhook을 사용하여 Sidecar를 자동으로 주입하는 방법에 대해 알아봅니다. 이를 통해 각 Pod에 Sidecar 컨테이너를 수동으로 추가하는 번거로움을 덜고, 일관된 환경을 유지할 수 있습니다.

1. Prerequisites

시작하기 전에 다음 도구가 설치되어 있어야 합니다.

git
kubectl
make
Docker

2. 프로젝트 복제 및 설정

먼저, 다음 명령어를 사용하여 필요한 Kubernetes Mutating Webhook 튜토리얼 저장소를 복제합니다.\

git clone https://github.com/morvencao/kube-mutating-webhook-tutorial.git
cd kube-mutating-webhook-tutorial

3. Sidecar Injector 이미지 빌드 및 ECR Push

Sidecar Injector 이미지를 사용하기 위해 AWS ECR (Elastic Container Registry)을 생성하고, 이미지를 빌드하여 푸시합니다. IMAGE 변수를 ECR 리포지토리 URL 및 원하는 태그로 설정해야 합니다.

make docker-build docker-push IMAGE=<ECR REPO URL>:<IMAGE TAG>

# ex) make docker-build docker-push IMAGE=950274644703.dkr.ecr.ap-northeast-2.amazonaws.com/webhook:latest

4. ConfigMap 수정

Kubernetes에 배포하기 전에 Sidecar로 사용할 이미지로 설정하려면 deploy/configmap.yaml 파일을 수정합니다.

# ~/kube-mutating-webhook-tutorial/deploy/configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: sidecar-injector
  labels:
    app: sidecar-injector
data:
  sidecarconfig.yaml: |
    containers:
    - name: sidecar-curl
      image: curlimages/curl # 원하는 이미지 사용
      imagePullPolicy: IfNotPresent
      args:
      - --version
      command:
        - sleep
        - infinity

5. Kustomization 수정

deploy/kustomization.yaml 파일에서 불필요한 nginx-configmap 리소스를 제거하고, 사용할 이미지를 지정합니다.

# ~/kube-mutating-webhook-tutorial/deploy/kustomization.yaml

namespace: sidecar-injector

resources:
- namespace.yaml
- clusterrole.yaml
- clusterrolebinding.yaml
- deployment.yaml
- service.yaml
- serviceaccount.yaml
- configmap.yaml

images:
- name: sidecar-injector
  newName: <AccountID>.dkr.ecr.ap-northeast-2.amazonaws.com/webhook
  newTag: latest
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

6. Kubernetes 배포

모든 설정이 완료되면, 다음 명령어를 사용하여 Kubernetes에 배포합니다.

make deploy IMAGE=<ECR REPO URL>:<IMAGE TAG>

# make deploy IMAGE=12345678.dkr.ecr.ap-northeast-2.amazonaws.com/webhook:latest

7. Namespace 생성 및 Label 추가

Sidecar Injection을 활성화할 Namespace를 생성하고, sidecar-injection=enabled 레이블을 추가합니다.

kubectl create ns test-ns
kubectl label namespace test-ns sidecar-injection=enabled

레이블이 제대로 추가되었는지 확인합니다.

kubectl get namespace -L sidecar-injection

# output:
NAME                 STATUS   AGE   SIDECAR-INJECTION
default              Active   26m
test-ns              Active   13s   enabled
kube-public          Active   26m
kube-system          Active   26m
sidecar-injector     Active   17m

8. 테스트 Pod 배포

테스트를 위해 test-ns Namespace에 Pod를 배포합니다.

kubectl -n test-ns run alpine \
    --image=alpine \
    --restart=Never \
    --command -- sleep infinity

9. 배포 확인

다음 명령어를 사용하여 Pod가 정상적으로 실행 중인지 확인합니다.

kubectl -n test-ns get pod

# output: 
NAME                     READY     STATUS        RESTARTS   AGE
alpine                   2/2       Running       0          10s

READY 열이 2/2로 표시되면 Sidecar가 성공적으로 주입된 것입니다.

마무리

이 가이드에서는 Kubernetes Mutating Webhook을 사용하여 Sidecar를 자동으로 주입하는 방법을 설명했습니다. 이를 통해 애플리케이션 개발 및 배포 프로세스를 간소화하고, 일관된 환경을 유지할 수 있습니다.

[Kubernetes] EKS 클러스터에 ReadOnly 및 Admin 권한 설정하기

dml113 — Fri, 14 Feb 2025 18:38:00 +0900

안녕하세요! 이번 글에서는 Amazon EKS (Elastic Kubernetes Service) 클러스터에 ReadOnly 및 Admin 권한을 설정하는 방법에 대해 알아보겠습니다. 이 설정을 통해 특정 IAM 역할 (Role)에게 클러스터 내의 리소스에 대한 읽기 전용 또는 관리자 권한을 부여할 수 있습니다.

사전 준비 사항

warm-readonly-eks-role 생성 및 Bastion 연결: ReadOnly 권한을 부여할 IAM 역할을 미리 생성하고, 필요에 따라 Bastion 호스트에 연결해둡니다. 마찬가지로, Admin 역할을 위한 IAM 역할도 미리 생성합니다.

1. 클러스터 접근 및 설정

# clusterrole.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: readonly-role
rules:
- apiGroups:
  - '*'
  resources:
  - 'pods'
  verbs:
  - get
  - list
  - watch

# clusterrolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: readonly-role
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: readonly-role
subjects:
- kind: Group
  name: readonly-role
  apiGroup: rbac.authorization.k8s.io

# 권한 부족으로 apply 도중 오류가 발생할 수 있으므로 root 권한으로 접속합니다.
aws configure

# 설정 파일들을 apply 합니다.
kubectl apply -f <설정 파일 경로>

# aws-auth ConfigMap 파일을 수정합니다.
kubectl edit -n kube-system configmap/aws-auth

위에 있는 manifest를 apply합니다. kubectl edit 명령어를 사용하면 텍스트 편집기가 열립니다. 아래와 같이 mapRoles 섹션에 새로운 역할을 추가합니다.

2. ReadOnly 권한 설정

다음은 ReadOnly 권한을 부여하는 설정 예시입니다. aws-auth ConfigMap에 다음 내용을 추가합니다.

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::<AccountID>:role/eksctl-skills-cluster-nodegroup-ng-NodeInstanceRole-WZqydbY21JGQ
      username: system:node:{{EC2PrivateDNSName}}
    - groups:
      - readonly-role  # ReadOnly 권한을 부여할 그룹
      rolearn: arn:aws:iam::<AccountID>:role/bastion-role # ReadOnly 역할을 할 IAM Role ARN
      username: readonly-role
kind: ConfigMap
metadata:
  creationTimestamp: "2024-05-03T23:06:55Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "4087"
  uid: d8525b90-6e1e-4da6-8782-a1d5b98999bf

groups: readonly-role 는 ReadOnly 권한을 가진 그룹을 나타냅니다. 이 그룹 이름은 임의로 설정할 수 있습니다.
rolearn: arn:aws:iam::<AccountID>:role/bastion-role은 ReadOnly 역할을 수행할 IAM 역할의 ARN (Amazon Resource Name)입니다. 실제 IAM 역할 ARN으로 바꿔야 합니다.
username: readonly-role은 Kubernetes 내에서 이 역할에 매핑될 사용자 이름입니다.

3. 동작 테스트

동작 테스트를 위해 설정한 creditional을 삭제 후 instance에 생성한 bastion-role로 설정 후 다시 진행합니다.

rm -rf ~/.aws/*

아래와 같이 pod를 생성하려고 하면 권한 에러가 발생합니다.

kubectl run nginx --image nginx

마무리

EKS 클러스터에 ReadOnly 권한을 설정함으로써, 클러스터 리소스에 대한 접근 권한을 세밀하게 제어하고 보안을 강화할 수 있습니다. 이 가이드를 통해 EKS 클러스터의 보안을 더욱 효과적으로 관리하시기 바랍니다.

KubeArmor로 Kubernetes 환경에 보안 정책 적용하기

dml113 — Fri, 14 Feb 2025 16:31:53 +0900

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-group-1-proc-path-block
  namespace: green
spec:
  severity: 5
  message: "block /bin/sleep"
  selector:
    matchLabels:
      app: green
  process:
    matchPaths:
    - path: /bin/sleep
  action:
    Block

안녕하세요! 오늘은 Kubernetes 클러스터에 KubeArmor를 사용하여 간단한 보안 정책을 적용하는 방법에 대해 알아보겠습니다. KubeArmor는 Kubernetes 환경에서 런타임 보안을 강화할 수 있는 강력한 도구입니다. 이 튜토리얼에서는 KubeArmor CLI를 설치하고, 몇 가지 예시 YAML 파일을 사용하여 프로세스, 파일 접근, 시스템 호출에 대한 보안 규칙을 정의하고 적용하는 방법을 설명합니다.

1. KubeArmor CLI 설치

먼저, KubeArmor CLI를 설치해야 합니다. 아래 명령어를 사용하여 KubeArmor를 설치합니다.

curl -sfL http://get.kubearmor.io/ | sudo sh -s -- -b /usr/local/bin
# sudo access is needed to install it in /usr/local/bin directory. But, if you prefer not to use sudo, you can install it in a different directory which is in your PATH.

Helm을 설치하였다면 아래와 같이 KubeArmor를 설치할 수 있습니다.

karmor install

2. KubeArmor 설정 파일 (kubearmor.yaml)

다음은 /bin/sleep 실행을 차단하는 간단한 KubeArmor 정책 예제입니다.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-group-1-proc-path-block
  namespace: green
spec:
  severity: 5
  message: "block /bin/sleep"
  selector:
    matchLabels:
      app: green
  process:
    matchPaths:
    - path: /bin/sleep
  action:
    Block

apiVersion: security.kubearmor.com/v1 - 사용할 API 버전을 지정합니다.
kind: KubeArmorPolicy - KubeArmor 정책 리소스임을 나타냅니다.
metadata:
- name: ksp-group-1-proc-path-block - 정책의 이름을 지정합니다.
- namespace: green - 정책이 적용될 네임스페이스를 지정합니다.
spec:
- severity: 5 - 이벤트의 중요도를 나타냅니다.
- message: "block /bin/sleep" - 이벤트 발생 시 표시될 메시지입니다.
- selector:
  - matchLabels:
    - app: green - 정책이 적용될 Pod의 레이블을 지정합니다.
- process:
  - matchPaths:
    - path: /bin/sleep - 차단할 프로세스 실행 경로를 지정합니다.
- action: Block - 지정된 프로세스 실행을 차단합니다.

3. 배포 설정 파일 (deployment.yaml)

다음은 busybox 이미지를 사용하여 /bin/sleep 명령어를 실행하는 간단한 Deployment 예제입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: green-app
  namespace: green
spec:
  replicas: 1
  selector:
    matchLabels:
      app: green
  template:
    metadata:
      labels:
        app: green
    spec:
      containers:
        - name: green-container
          image: busybox
          command:
            - "sh"
            - "-c"
            - "echo 'Starting /bin/sleep'; /bin/sleep 3600"
          resources:
            limits:
              memory: "64Mi"
              cpu: "250m"

4. 보안 정책 추천

KubeArmor는 자동으로 보안 정책을 추천해주는 기능을 제공합니다.

karmor recommend -n green

5. 파일 접근 차단 정책

다음은 /account/ 디렉터리에 대한 접근을 차단하는 정책 예제입니다.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-group-1-proc-path-block
  namespace: green
spec:
  severity: 5
  message: "a critical directory was accessed"
  selector:
    matchLabels:
      app: green
  file:
    matchDirectories:
    - dir: /account/
      fromSource:
      - path: /bin/cat
  action:
    Block

6. 디렉터리 접근 감사 정책

다음은 /usr/bin/ 디렉터리에 대한 접근을 감사하는 정책 예제입니다.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-group-1-proc-path-block
  namespace: green
spec:
  tags:
  - WARNING
  severity: 10
  message: "block /usr/bin"
  selector:
    matchLabels:
      app: green
  process:
    matchDirectories:
    - dir: /usr/bin/
      recursive: true
  action:
    Audit

7. 시스템 호출 감사 정책

다음은 sleep 프로세스가 종료될 때 로그를 출력하는 정책 예제입니다.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-group-1-proc-path-block
  namespace: green
spec:
  severity: 3
  message: "sleep syscall"
  selector:
    matchLabels:
      app: green
  syscalls:
    matchSyscalls:
    - syscall:
      - exit
  action:
    Audit

마무리

KubeArmor를 사용하면 Kubernetes 환경에서 런타임 보안을 쉽게 강화할 수 있습니다. 이 튜토리얼에서는 KubeArmor CLI를 설치하고, 간단한 YAML 파일을 사용하여 프로세스, 파일 접근, 시스템 호출에 대한 보안 규칙을 정의하고 적용하는 방법을 설명했습니다. KubeArmor를 사용하여 Kubernetes 클러스터를 더욱 안전하게 보호하세요!

[Linux] Docker Swarm으로 마이크로서비스 구축하기

dml113 — Wed, 12 Feb 2025 23:15:03 +0900

안녕하세요! 오늘은 Docker Swarm을 사용하여 마이크로서비스 아키텍처를 구축하는 방법에 대해 알아보겠습니다. Docker Swarm은 여러 Docker 호스트를 클러스터로 구성하여 컨테이너를 쉽게 관리할 수 있게 해주는 도구입니다.

1. Docker 설치 및 Swarm 초기화

먼저, 마스터 서버에 Docker를 설치하고 Swarm을 초기화합니다.

#!/bin/bash
dnf install -y docker
systemctl enable --now docker

# Swarm 초기화
docker swarm init --advertise-addr 10.0.1.228

Swarm을 초기화하면 워커 노드를 추가할 수 있는 명령어가 출력됩니다. 이 명령어를 복사해두세요.

2. 워커 노드 추가

워커 노드로 사용할 서버에 접속하여 복사한 명령어를 실행합니다.

docker swarm join --token SWMTKN-1-4uu7ft977083s6zxn6j939lpqv7upypv2sdlm93efdb9vj7yji-6cdxe8dyfr0a7bxsduwwtr3nd 10.0.3.180:2377

3. 노드 상태 확인

마스터 노드에서 다음 명령어를 실행하여 노드 상태를 확인합니다.

docker node ls

4. 마스터 노드 설정

마스터 노드에 컨테이너를 생성하지 않도록 설정합니다.

docker node update --availability pause <Node ID>

5. 오버레이 네트워크 생성

노드 간 컨테이너 통신을 위한 오버레이 네트워크를 생성합니다.

docker network create --driver overlay network

6. 서비스 배포

ECR 이미지를 사용하여 서비스를 배포합니다. DNS 설정과 레지스트리 인증을 위한 옵션을 추가합니다.

docker service create --with-registry-auth --dns 8.8.8.8 --network network -p 8080:8080 --replicas=3 --name getuser 950274644703.dkr.ecr.ap-northeast-2.amazonaws.com/get-user:latest
docker service create --with-registry-auth --dns 8.8.8.8 --network network -p 8081:8080 --replicas=3 --name managed 950274644703.dkr.ecr.ap-northeast-2.amazonaws.com/managed:latest
docker service create --with-registry-auth --dns 8.8.8.8 --network network -p 8082:8080 --replicas=3 --name servercheck 950274644703.dkr.ecr.ap-northeast-2.amazonaws.com/servercheck:latest

마무리

이렇게 하면 Docker Swarm을 사용하여 마이크로서비스 아키텍처를 구축할 수 있습니다. 각 서비스는 3개의 레플리카로 실행되며, 오버레이 네트워크를 통해 서로 통신할 수 있습니다. 또한, 각 서비스는 서로 다른 포트로 외부에 노출되어 있어 쉽게 접근할 수 있습니다.

Docker Swarm을 사용하면 서비스의 확장성과 가용성을 쉽게 관리할 수 있으며, 롤링 업데이트 등의 기능도 활용할 수 있습니다. 이를 통해 효율적이고 안정적인 마이크로서비스 운영이 가능해집니다.