잡다한 IT 지식

GNS3 프로젝트가 열리지 않을 때 원인 확인 방법

가나무마 — Sat, 14 Mar 2026 09:17:41 +0900

TL;DR

GNS3에서 몇몇 이슈는 UI를 통해 확인이 불가능하다.
GNS3 로그 파일을 확인하여 트러블슈팅 진행이 필요하다.
Linux의 경우, ~/.config/GNS3/{GNS Version}/디렉터리에 로그 파일이 존재한다.

문제

일반적으로 GNS3에서 발생하는 에러는 Console 창이나 팝업 윈도우를 통해 쉽게 확인할 수 있습니다.

하지만 이번에 작업 중인 Fortinet 프로젝트에서 에러 메시지 없이 프로젝트 자체가 열리지 않는 이슈가 발생했습니다.

fortinet 프로젝트를 열려고 시도하지만 열리지 않고, 에러 메시지도 뜨지 않는다

원인 분석

UI 상에서 에러 확인이 불가능하므로 로그 메시지를 확인하여 트러블슈팅이 필요합니다.

Ubuntu 환경을 기준으로 GNS3의 로그 파일은 다음 경로에 위치합니다.

~/.config/GNS3/{GNS 버전}/

해당 경로로 이동해 gns3_server.log 파일을 확인해 보니, UI에서는 출력되지 않았던 에러 로그를 발견할 수 있었습니다.

gns3_server.log 파일에 UI에서 확인 불가했던 로그들이 출력된다.

제 경우에는 DockerError가 발생했으며, 생성하려는 컨테이너명을 이미 다른 곳에서 사용하고 있다는 내용이었습니다.

해결

충돌을 일으키는 해당 Docker 컨테이너들을 찾아 삭제 조치했습니다.

이후 GNS3에서 프로젝트를 다시 열자, 정상적으로 Fortinet 프로젝트가 실행되는 것을 확인했습니다.

해당 컨테이너들을 삭제

이후, 프로젝트를 다시 열자 정상적으로 프로젝트가 열렸습니다.

정상적으로 프로젝트가 열린다.

FortiGate - Threat Feed 기반 URL 필터링 동적 구성

가나무마 — Sat, 28 Feb 2026 01:03:41 +0900

TL;DR

- FortiGate에선 Threat Feed를 통해 외부 서버에서 IP 주소, MAC 주소, URL, Domain 등을 조회 가능

- 조회한 데이터를 객체로 만들어 Web Filter, Domain Filter, Firewall Source Address 등 적용 가능

- Threat Feed API: https://github.com/johnson434/fortigate_threat_feed_webserver

구성도

FortiGate Port2와 Threat Feed Server가 직접 연결

설정 화면

Threat Feed API 서버로부터 URL 목록 조회하기

FortiGate가 조회할 API 서버를 아래와 같이 설정

Security Fabric > External Connectors > Create New > Threat Feeds > FortiGuard Category

HTTP 인증 없이 5분 주기로 Threat Feed로부터 URL 목록 조회

"http://192.168.20.2/feeds/fortiguard-categories" 주소로부터 URL 목록을 조회한다.

목록 갱신 주기는 5분으로 설정한다.

Entries가 1로 유효한 URL 주소가 서버로부터 1개 반환됐다.

서버와 연동에 성공하자, 해당 API 서버로부터 URL을 1개 가져오는 데 성공했다.

1 Valid는 유효한 Entry 개수를 의미한다. 만약, MAC 주소와 같은 URL 형식에 맞지 않은 값이 들어있다면 Invalid로 처리된다.

View Entries를 클릭하면 API 서버로부터 받은 URL을 확인 가능

View Entries를 클릭하면 해당하는 URL 목록을 직접 확인할 수 있다.

이 예에선 이 블로그의 주소를 반환하도록 Threat Feed API 서버를 구축하였으므로 codingpracting.tistory.com이라는 주소를 반환한다.

Web Filter에서 해당 카테고리 주소를 차단하라고 설정

Security Profiles에 가면 방금 만든 External Connector와 이름이 같은 웹필터의 카테고리가 Remote Categories에 추가된다.

해당 사이트에 접근하면 차단하도록 Block으로 설정한다.

방화벽 정책에 적용

Web Filter를 접근을 차단할 방화벽 정책에 설정한다.

사이트 접속 시도 시 차단

codingpracting.tistory.com을 통해 접속했을 때, 차단됨을 확인

Log & Report의 Security Events 확인 시 해당 카테고리로 판단되어 차단되는 것을 볼 수 있음

로그에서도 URL 필터를 통해 차단됨을 확인

디버그 명령어를 통해 해당 category 192번을 통해 접속 차단됨을 확인

아래 디버그를 통해서도 확인 가능

diagnose debug enable
diagnose ips debug enable all

참고 자료

- FortiOS 7.6.6 Administrator Guide - External Feeds

- Technical Tip: Troubleshooting static URL filter by 'debug ips'

FortiGate VM permanent evaluation VM license 등록하기

가나무마 — Thu, 4 Sep 2025 23:10:25 +0900

FortiGate는 VMWare부터 AWS EC2 인스턴스에 등록 가능한 Permanent Evaluation VM License를 계정당 1개 제공한다.

공식 문서에 소개된 등록 방법은 아래와 같다.

https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/441460

FortiGate에 CLI로 접속하여 Fortinet 계정을 입력하면 라이센스 발급을 진행한다.

1. CLI로 라이센스 등록

아래 명령어를 FortiGate 콘솔에서 입력하면 VM License 등록이 진행된다.

execute vm-license-options account-id Fortinet이메일
execute vm-license-options account-password Fortinet비밀번호
execute vm-license

Do you want to continue?에 y를 입력하고 엔터를 치면 FortiGate가 재부팅되며 라이센스 등록이 진행된다.

FortiGate 콘솔에 로그인 후에 execute 커맨드를 통해서 라이센스 등록

2. 라이센스 등록 확인

CLI로 라이센스 등록 확인하기

FortiGate 콘솔에서 아래 명령어를 통해 라이센스 등록 여부를 확인할 수 있다.

get system status | grep -i license

https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/441460

Permanent trial mode for FortiGate-VM | Administration Guide

docs.fortinet.com

분산 시스템과 CAP

가나무마 — Tue, 19 Aug 2025 23:30:20 +0900

1. 분산 시스템이란?

분산 시스템은 공통의 목표를 위해 여러 개의 독립된 노드가 네트워크를 통해 협력하여 동작하는 시스템입니다.
예를 들어, 데이터를 여러 노드에 분산 저장하는 NoSQL 시스템, 읽기 부하를 분산하기 위한 RDBMS의 읽기 복제본도 분산 시스템의 사례로 볼 수 있습니다.

2. 분산 시스템은 왜 쓸까?

2.1 단일 서버 기반 아키텍처의 한계

어느 스타트업의 초창기 아키텍처 설계

어느 회사가 서비스를 런칭했다고 가정해 봅시다.
초기에는 시장 반응 검증이 목적이므로 대규모 트래픽을 고려하지 않은 단순한 아키텍처를 사용했습니다.
이때 Auto Scaling Group은 단일 인스턴스에 장애가 발생했을 때 동일한 인스턴스를 재기동하는 용도로만 쓰였습니다. 즉, 인스턴스 수는 항상 1개였습니다.
그러나 시간이 지나 트래픽이 증가하면서 단일 인스턴스로는 더 이상 부하를 감당할 수 없는 상황이 발생합니다.

서버를 여러 대 띄우고 로드밸런서를 통해 작업을 분배

웹 서버 계층은 애플리케이션이 Stateless로 설계되어 있다면 수평적 확장이 비교적 쉽습니다. 로드밸런서를 두고 서버 수를 늘리면 됩니다.
그렇다면 데이터 계층(RDS)에도 같은 방식이 적용될까요?

DB의 수평적 확장을 위해선 분산 시스템 설계가 필요하다.

아쉽게도 RDS는 웹 서버처럼 단순히 인스턴스를 늘린다고 해서 수평 확장이 되지 않습니다.
데이터 계층은 여러 DB 인스턴스가 동시에 쓰기·읽기를 처리할 때 데이터 동기화 문제가 필연적으로 발생합니다.
동기화가 제대로 되지 않으면 같은 쿼리에 대해 인스턴스마다 다른 결과를 반환할 수 있습니다.
따라서 RDS를 수평적으로 확장하려면 단순 복제 이상의 방법, 예를 들어 샤딩(Sharding) 같은 분산 데이터베이스 설계가 필요합니다.
그리고 이러한 분산 시스템의 동작 원리를 이해하기 위해 등장하는 개념이 바로 CAP 이론입니다.

3. CAP란?

CAP

CAP은 Consistency(일관성), Availability(가용성), **Partition Tolerance(분할 내성)의 앞 글자를 딴 개념입니다.
분산 시스템은 이 세 가지 특성을 동시에 만족할 수 없으며, 상황에 따라 이 중 2가지만 선택할 수 있다는 것이 CAP 이론의 핵심입니다.
흔히 다음과 같이 CA / CP / AP의 세 가지 분류로 설명됩니다.

3.1 Consistency (일관성)

Consistency는 분산 시스템의 모든 노드가 동일한 데이터를 보장하는 특성입니다.
사용자가 어느 노드에 요청을 보내더라도 항상 같은 결과를 받아야 합니다.
예: Kubernetes에서 사용하는 etcd는 강한 일관성(strong consistency)을 보장합니다.
→ 클러스터 구성 정보가 저장된 etcd는 과반수 노드 합의(RAFT 알고리즘)를 통해 항상 최신의 동일한 데이터를 반환합니다.

kubernetes의 etcd 저장소

3.2 Availability (가용성)

DynamoDB의 글로벌 테이블을 활용한 멀티 리전 배포

Availability는 일부 노드에 장애가 발생해도 정상 동작하는 노드가 요청에 응답할 수 있는 특성을 의미합니다.
예: DynamoDB 글로벌 테이블은 여러 리전에 데이터를 복제합니다. 특정 리전에 장애가 발생해도 다른 리전에서 읽기/쓰기 작업을 처리할 수 있으므로 높은 가용성을 제공합니다.

3.3 Partition Tolerance (분할 내성)

Partition Tolerance는 네트워크 단절(Partition)이 발생하더라도 시스템이 일부 기능을 유지할 수 있는 능력을 의미합니다.
예: DynamoDB는 특정 리전이 단절되더라도 나머지 리전에서 정상 응답을 할 수 있습니다.

4. CP, AP, CA?

4.1 P는 필수

현실의 네트워크 환경에서는 언제든 장애가 발생할 수 있으므로 Partition Tolerance(P)는 선택이 아닌 전제 조건입니다.
따라서 CAP 이론을 적용할 때는 P를 기본으로 하고, 그 위에서 **C(일관성)**과 A(가용성) 중 하나를 선택해야 합니다.
즉, CAP 이론은 Partition 상황에서 가용성을 지킬 것인가, 일관성을 지킬 것인가를 설명하는 이론입니다.

4.2 CP (Consistency + Partition Tolerance)

CP 시스템은 Partition이 발생하면 응답을 멈추고, 노드 복구가 될 때까지 데이터 연산을 제한합니다.

장점: 모든 노드의 데이터가 항상 일관성을 유지
단점: 일부 상황에서는 요청을 처리하지 못해 가용성이 낮아짐

예:

etcd → 과반수 노드가 살아있지 않으면 읽기/쓰기를 모두 거부
Zookeeper → 합의를 기반으로 동작하는 대표적인 CP 시스템

4.3 AP (Availability + Partition Tolerance)

AP 시스템은 Partition이 발생해도 응답을 계속합니다. 장애 노드를 기다리지 않고 가용한 노드에서 요청을 처리합니다.

장점: 빠른 응답, 높은 가용성
단점: 일관성이 일시적으로 깨질 수 있으며, 이후 동기화 과정이 필요

예:

Cassandra, DynamoDB → 네트워크 분리 상황에서도 가능한 한 응답을 제공

4.4 CA (Consistency + Availability)

CA는 Partition을 고려하지 않는 조합입니다.
즉, 네트워크 단절이 절대 발생하지 않는 환경을 전제로만 성립합니다.

장점: 항상 일관성과 가용성을 모두 만족
단점: 현실의 분산 환경에서는 Partition을 배제할 수 없으므로 사실상 불가능

예:

단일 노드 데이터베이스
네트워크 분리가 없는 중앙 집중형 시스템

실제 분산 환경에서 CAP을 논할 때 CA는 주로 “이론적인 경우”로만 설명됩니다.

5. PACELC

앞에서 본 것처럼 CAP 이론은 Partition이 발생했을 때 A와 C 중 무엇을 선택할 것인가만 설명합니다.
하지만 Partition이 없는 정상적인 상황에서는 어떤 trade-off가 존재하는지는 다루지 못합니다.
이를 보완하기 위해 나온 개념이 PACELC 이론입니다.

Partition이 있을 때 (P) → Availability(A) vs Consistency(C)
Partition이 없을 때 (Else) → Latency(L) vs Consistency(C)

즉, PACELC는 네트워크 분리 상황뿐만 아니라, 정상 상황에서도 시스템이 지향하는 특성을 함께 설명합니다.
PACELC의 세부적인 분류와 예시는 다음 글에서 별도로 다뤄보겠습니다.

참고 자료

위키백과. CAP theorem. https://en.wikipedia.org/wiki/CAP_theorem

Burp Suite - 프록시 설정

가나무마 — Wed, 30 Jul 2025 14:24:49 +0900

단서 질문 및 답변

Burp Suite란?
프록시 서버란?

핵심 요약

Burp Suite는 프록시 서버를 통해서 웹브라우저의 요청을 중간에서 가로채거나 API 요청 캡처 등 다양한 보안 관련 기능을 제공한다.
Burp Suite를 사용하기 위해선 웹브라우저가 Burp Suite의 프록시 서버를 사용하도록 설정해야 한다.

핵심 필기

Burp Suite란?

API 전문가 혹은 보안 전문가들이 사용하는 도구 모음으로 다음과 같은 기능을 가진다.

API 요청 캡처
Web Application crawling
API fuzzing

프록시 서버 설정하기

Burp Suite를 실행하면 프록시 서버가 실행된다. 프록시 서버는 클라이언트와 서버 간에 발생하는 트래픽을 가로채거나 스누핑할 수 있다. 흔히 말하는 중간자(Man In the Middle) 역할을 수행한다.

Burp Suite의 프록시 서버가 웹브라우저의 트래픽을 가로채기 위해선 웹브라우저에서 프록시 서버 설정이 필요하다. Firefox나 Chrome 등 대부분의 웹브라우저는 별다른 확장 프로그램을 사용할 필요 없이 설정 메뉴에서 프록시 메뉴를 직접 설정할 수 있다. 하지만, FoxyProxy와 같은 확장 도구를 사용하는 게 편리하다.

Foxy Proxy를 사용하면 프록시 서버 설정을 간단하게 켰다 끌 수 있다.

Foxy Proxy 설정

기본적으로 Burp Suite의 프록시 서버는 로컬호스트의 8080 포트를 사용한다.
따라서, Foxy Proxy 설정을 127.0.0.1:8080으로 설정한다.

이제 프록시 서버를 설정했으니 google.com에 접속해보자.

프록시 서버를 설정하니 google.com에 접속이 불가능해졌다. 에러 메시지를 보면 PortSwigger CA 때문에 이슈가 발생했다고 나온다. 왜 이런 일이 발생할까?

웹브라우저는 Burp Suite의 인증서를 신뢰하지 않는다.

프록시 서버를 사용하지 않는 경우, 웹 브라우저는 직접 서버와 TLS 핸드셰이크를 수행하며 이 과정에서 서버가 제공하는 인증서를 전달 받는다. 브라우저는 해당 인증서가 신뢰할 수 있는 CA(Certificate Authority)에서 발급 받은 것인지 검증한다. 그렇다면 프록시 서버를 사용하면 이 과정이 어떻게 변할까?

정답은 사용자와 프록시 서버 사이에 TLS 핸드셰이크가 발생하고 이 과정에서 프록시 서버가 전달한 인증서를 브라우저가 검증한다. 하지만 기본적으로 웹브라우저는 Burp Suite가 사용하는 PortSwigger CA를 신뢰하지 않는다. 따라서, Burp Suite의 루트 인증서(PortSwigger CA)를 브라우저의 신뢰 목록에 등록해야 한다.

FireFox에 Burp Suite CA 추가

Firefox에서 Burp Suite의 인증서를 추가하겠다.

FireFox의 설정으로 들어가서 보안 설정으로 들어간다.
밑으로 쭉 내리면 인증서 구간이 나온다.
인증서 보기를 클릭하면 위처럼 현재 웹브라우저에서 신뢰하는 CA 목록이 나온다.
Import를 누르면 인증서를 추가할 수 있다.

5. 위처럼 해당 CA를 신뢰한다고 설정하면 끝이다.

이제 Burp Suite 인증서 신뢰 설정을 끝냈으니 다시 google.com에 접속해보자.

제대로 접속되는 걸 볼 수 있다. 이제 인증서를 자세히 들여다 보자.

프록시 서버를 사용하지 않고 직접 google.com에 요청하면, 서버는 Google Trust Services에서 발급 받은 인증서를 전달한다. 이 인증서는 웹브라우저에 기본적으로 등록된 신뢰할 수 있는 CA가 서명한 것이므로 별다른 경고 없이 정상적으로 HTTPS 통신이 이루어진다.

반면, Burp Suite의 프록시 서버를 거쳐 같은 요청을 보내면 브라우저가 받는 인증서는 PortSwigger CA에서 발급 받은 인증서다. 이 CA는 방금 직접 우리가 브라우저에 등록해둔 루트 인증서로 신뢰 목록에 추가했기 때문에 브라우저가 해당 인증서를 유효한 것으로 판단하고 안전하게 통신을 허용하게 된다.

Burp Suite로 트래픽 Intercept하기

이제 Burp Suite에서 Intercept를 키면 요청을 가로챌 수 있다.

참고 자료

Installing Burp's CA Certificate

AWS Lambda 503 Server Error: Service Unavailable for url

가나무마 — Wed, 23 Jul 2025 12:00:25 +0900

문제 상황

부하테스트 중에

부하 테스트를 위해 Locust를 사용하여 서비스에 트래픽을 유입시켰고, 다음과 같은 문제가 발생했다.

- RPS 30 ~ 40 수준에서 HTTP 503 Service Unavailable 에러가 반복적으로 발생

- 평균 응답 속도는 약 300ms로 정상 범위 내에 있었음

추측

503 에러

HTTP 503 에러는 일반적으로 다음과 같은 상황에서 발생한다.

- 서버가 유지보수 중이거나 다운됨

- 서버가 과부하 상태로 더 이상 요청을 처리할 수 없음

우리 서비스는 AWS Lambda 기반의 서버리스 아키텍처로 구성되어 있어, 트래픽 증가 시 자동으로 함수 인스턴스가 확장되며 요청을 처리해야 한다.
그런데도 503 에러가 발생했다는 것은, Lambda 함수의 동시 실행 수가 제한되어 있고, 해당 제한에 도달했을 가능성이 높다고 판단했다.

해결 과정

1. CloudWatch에서 Lambda 동시성 지표 확인

Lambda 함수의 동시성 지

함수의 ConcurrentExecutions 메트릭을 확인해보니, 동시 실행 수가 정확히 10에서 멈춰 있다.

2. Lambda 함수 설정에서 동시성 제한 확인

Lambda 함수가 최대 동시성이 10이다.

현재 Lambda 함수는 Reserved Concurrency를 사용하지 않고, Unreserved Concurrency를 사용 중이다.

그런데, 예약되지 않은 계정 동시성이 10밖에 되지 않는다.

3. Service Quotas 확인

AWS 콘솔 > Service Quotas > Lambda > Concurrent executions 항목을 확인

계정 전체에 허용된 동시성 한도가 기본값인 1000이 아닌 10으로 설정되어 있다.

따라서, Lambda 확장 한계에 도달하여 더 이상 확장이 불가능했고, 이로 인해 503 에러가 발생했다.

해결

Lambda 함수 동시성 제한 상향 요청

AWS 콘솔에서 Lambda 동시성 제한 상향 요청을 제출하여 최대 동시성을 1000으로 설정했다.

Lambda 확장 요청이 완료됐단 이메일

3시간쯤 지나서 요청이 처리됐단 이메일이 도착했다.

Lambda가 동시에 12개까지 실행

처음과 동일한 부하 테스트 실행 시에도 에러가 발생하지 않음

이후 다시 부하테스트를 시도했을 때, 최대 동시성이 12까지 도달했으며 에러가 발생하지 않았다.

Kubernetes The connection to the server [IP] was refused 트러블슈팅

가나무마 — Fri, 18 Jul 2025 03:16:37 +0900

kube-apiserver에 접근이 안되는 문제가 발생해서 트러블 슈팅을 기록으로 남긴다.

err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s"

error 상황

문제 상황: kubectl 명령어 실행 시에 localhost:8080과 연결 불가

원인: ~/.kube/config 파일 존재하지 않거나 빈 값(kubectl config view를 통해 설정값 확인 가능)

해결 방법: /etc/kubernetes/admin.conf 파일을 ~/.kube/config로 복사

원인 설명

기본적으로 kubectl 명령어는 ~/.kube/config 파일을 설정 값으로 사용한다.

~/.kube/config 파일엔 kube-apiserver의 엔드포인트나 클러스터 접근을 위한 인증서 등 클러스터 사용을 위한 정보가 들어있다.

그런데 만약, ~/.kube/config 파일이 없다면 kubectl 명령어는 기본 경로를 사용한다.

이 때, 사용되는 기본 경로가 localhost:8080이다. 이는 kubernetes 깃허브 소스 코드에서 직접 확인 가능하다.

client-go/tools/clientcmd/client_config.go at a21e7a8bf0d6c98bb9652fb45e48cb8de15392b4 · kubernetes/client-go

Go client for Kubernetes. Contribute to kubernetes/client-go development by creating an account on GitHub.

github.com

환경변수가 없으면 localhost:8080을 기본 서버 주소로 반환한다.

err="couldn't get current server API group list: Get \"https://cp.cluster.local:6443/api?timeout=32s\": dial tcp 192.168.56.10:6443: connect: connection refused"

문제 상황: kubectl 명령어 실행 시에 kube-apiserver와 연결 불가

원인: 위 오류를 유발하는 원인은 굉장히 많다.(DNS lookup실패, iptables Deny, 인증서 문제 등) 이번 경우엔 kubelet 설정값 문제였다.

해결 방법: kubelet conf값 수정

트러블슈팅:

1. kube-apiserver 실행 여부 확인

kube-apiserver 실행 여부 확인

현재 실행 중인 컨테이너를 확인해봤다. kube-apiserver가 존재하지 않는다.

2. /etc/kubernetes/manifests 확인

kubelet은 kube-apiserver와 통신할 필요 없이 kubelet이 직접 실행하는 pod들이 존재한다. 이를 static pod(정적 파드)라고 한다.

static pod는 kubelet이 알아서 실행하므로 따로 명령어를 실행하거나 할 필요가 없다.

그런데, static pod가 실행되지 않았으므로 해당 경로에 제대로 yaml 파일들이 존재하는지 확인해보겠다.

파일들은 설정되어 있다. 그런데, 컨테이너를 생성하진 않는다.

static pod를 위한 yaml파일들이 설정된 상태지만 어째서인지 컨테이너들이 실행되지 않는다.

이제 그러면 컨테이너 실행의 주체인 kubelet의 상태를 확인할 필요가 있다.

3. kubelet 실행 여부 확인

static pod가 설정되어 있더라도 해당 yaml을 컨테이너로 만드는 건 kubelet의 역할이다.

kubelet이 일을 안하고 있을 확률이 높다. systemctl 커맨드로 상태를 확인해보자.

kubelet은 잘 실행 중이다.

kubelet은 잘 실행 중이다. 잘 실행 중이므로 이제 로그를 직접 확인하는 방법만 남았다.

4. journalctl로 kubelet 로그 확인

journalctl을 통해 kubelet의 로그를 추적

해당 로그를 보면 static pod의 경로가 /etc/kubernetes/manisfests가 아닌 /etc/kubernetes/manisfests2를 사용함을 알 수 있다.

즉, kubelet의 설정 값이 잘못됐다.

5. kubelet 설정 파일 찾기

다시 한 번 systemctl status kubelet을 통해서 kubelet이 어떤 설정 파일을 사용하는지 확인하겠다.

kubelet 실행에 쓰이는 설정 파일들이 나열된다.

6. 설정값 확인

잘못된 설정 값 발견

/etc/kubernetes/manifests가 아닌 /etc/kubernetes/manifests2로 설정되어 있다.

수정하고 kubelet을 재시작하자.

7. 재시작 후 컨테이너 실행 결과 확인

컨테이너가 제대로 실행된다.

8. kubectl 명령 실행

kubectl 명령어 실행

kubectl 명령어가 잘 실행된다. 현재 worker 노드가 없어 taint로 인해 nginx가 스케쥴링 되진 않는다.

AWS self managed kubernetes 구축 아이디어

가나무마 — Wed, 16 Jul 2025 21:55:06 +0900

1. Custom Controller 기반 Cluster Autoscaling

Unschedulable 이벤트가 발생하면 custom controller 또는 watcher가 이를 감지(현재 트래픽 기반으로 추가 개수 설정)
AWS CLI 또는 SDK를 통해 EC2 인스턴스를 생성 (Auto Scaling Group 또는 직접)
EC2는 User Data를 통해 kubeadm join을 자동 실행하여 클러스터에 등록
Pod가 정상적으로 스케줄됨

고려사항

kubeadm join을 어떤 방식으로 구성할 것인지 결정 필요
- 인증서 기반: /etc/kubernetes/pki를 S3 등에 저장 → 보안 문제 발생 가능성
- 토큰 기반: kubeadm token create → EC2 인스턴스에 안전하게 전달하는 방식 필요
토큰 만료 방지 (장기 토큰 또는 주기적 재발급 필요)
EC2 생성 후 ALB Target Group에 자동 등록 필요

2. kubeadm 환경에서 AWS Load Balancer Controller 사용

Ingress 리소스를 감시하여 ALB 생성, 삭제, Target Group 생성 및 자동 관리
EC2 오토스케일링 시 새로운 노드가 Target Group에 자동 등록됨
Pod 단위 IAM 역할 부여는 불가능하므로 EC2 Role에 의존해야 함

필요 구성

Controller Pod가 사용할 수 있는 AWS IAM 권한
- EC2 Instance Profile 또는 IRSA equivalent
Helm 또는 manifest를 이용한 aws-load-balancer-controller 배포

3. Pod 단위 IAM Role이 불가능하므로 Node Pool + Namespace 분리 전략

IAM Role을 기능별로 나누고, Node Pool을 그에 따라 분리 (예: S3 접근용, RDS 접근용)
Pod에는 NodeAffinity와 toleration 설정을 통해 특정 Node에만 배치
네임스페이스를 기반으로 RBAC 및 네트워크를 분리하여 보안성 향상

효과

EC2 IAM Role이 모든 Pod에 공유되는 구조에서 최소 권한 원칙 일부 유지 가능
IRSA를 사용할 수 없는 kubeadm 환경에서 현실적인 권한 분리 수단

4. Ingress 기반 서비스 분리 (검색, 주문 등)

Ingress 리소스를 path 또는 host 기반으로 구성하여 여러 서비스로 라우팅
ALB 도메인을 통해 외부 요청 수신
각 요청은 Ingress Controller를 통해 Kubernetes Service로 전달
Service는 Pod의 IP가 유동적이더라도 안정적인 라우팅을 보장

핵심 개념

Pod IP는 유동적이지만, Service가 이를 추상화하여 항상 접근 가능하게 유지

5. VPC CNI 기반 target-type: ip와 kubeadm 구조 비교

kubeadm 환경에서는 ALB → NodePort → kube-proxy → Pod 구조로 hop 수가 많음
EKS에서 VPC CNI를 사용하면 Pod에 직접 ENI가 부여되어 ALB가 바로 Pod로 트래픽 전달 (hop이 적고 성능이 좋음)
kubeadm에서는 이 구조가 구현 불가능하므로, 성능 민감한 서비스는 노드 배치 최적화가 필요

배치 최적화 예시

서로 자주 호출하는 서비스는 동일 노드 또는 동일 가용 영역에 배치
NodeAffinity, TopologySpreadConstraints 등을 활용하여 네트워크 hop 최소화

5. kubeflow 기반 재학습 파이프라인 구축

현재 파이프라인이 없어 재학습이 안됨.
kubeflow 사용하여 지속적 학습 구축

필요 구성

kubeflow 설치 시에 istio가 필수
인스턴스 크기: 최소 xlarge
인스턴스 개수: 최소 xlarge
taint나 nodeaffinity 필수

고려사항

데이터 수집 방법
- s3 -> lambda -> SQS -> lambda -> kubeflow
- s3 -> lambda -> SQS -> kubeflow polling
- s3 -> kinesis -> kubeflow(실시간성, 제일 비쌈)

AWS fcm 병목 지점 찾기

가나무마 — Thu, 10 Jul 2025 01:00:26 +0900

문제 상황

저희 팀 프로젝트는 사기 의심 거래가 발생하면 FCM을 통해 사용자에게 알림을 보내도록 설계했습니다.
이제 첫 테스트를 하는 중인데 첫 번째 알림 발송까지 무려 33초가 걸렸습니다.
아래는 CloudWatch Log insights를 통해 추출한 로그입니다.

[
    {
        "@timestamp": "2025-07-09 08:50:41.765",
        "@log": "secret:/aws/lambda/FinGuard-Backend-dev-createTransaction"
    },
    {
        "@timestamp": "2025-07-09 08:51:14.996",
        "@log": "secret:/aws/lambda/sns-receive-and-send-fcm"
    }
]

거래 발생 → FCM 발송 사이까지 걸린 시간이 무려 33초입니다.
트래픽이 없던 상황임에도 이 정도의 지연은 비정상적입니다.

문제 원인 추측

추측1. Cold Start

서버리스 아키텍처이므로 Lambda의 Cold Start로 인한 지연 문제일 가능성이 있습니다.
Init Duration에 얼마나 많은 시간이 소요 되는 지 확인해보겠습니다.

CloudWatch Log Insights

CloudWatch Log Insights에서 로그를 쿼리할 수 있다.

아래는 Init Duration의 평균, 최대, 최소 시간 쿼리문입니다.

fields @timestamp, @message
| filter @message like /Init Duration/
| parse @message /Init Duration: (?<init_duration>[0-9.]+) ms/
| stats     
    count() as cold_starts,    
    avg(init_duration) as avg_init_ms,    
    max(init_duration) as max_init_ms,    
    min(init_duration) as min_init_ms

Init Duration 로그 집계 결과

결과는 다음과 같습니다.

평균 시간: 782ms
최대 시간: 1550ms
최소 시간: 68ms

즉, Cold Start는 아무리 길어도 2초를 넘지 않습니다.
최악의 경우를 가정해도 총합해서 걸리는 시간은 1550ms * 3(Lambda 개수) = 4.65초 수준입니다.

추측2. Lambda 타임아웃으로 인한 SQS 메시지 재처리

로그를 확인해보면, SQS 메시지를 처리하던 Lambda가 실패한 뒤 약 24초 후(Lambda 타임아웃 시간 포함 30초)에 다시 실행되는 현상을 확인할 수 있습니다.

실행에 실패한 Lambda가 다시 시작된다.

이 30초라는 시간은 바로 SQS의 기본 Visibility Timeout(가시성 제한 시간) 때문입니다.

SQS 메시지 가시성 제한 시간은 기본 30초다.

문제의 원인은, Lambda가 SageMaker serverless endpoint를 호출했지만 endpoint의 Cold Start로 인해 Lambda가 응답을 받지 못하고 타임아웃 되기 때문입니다.
이로 인해 SQS의 메시지는 삭제되지 않은 채 invisible 상태로 유지되었고, Visibility Timeout이 만료된 시점에 다시 visible 상태로 전환되면서 같은 메시지로 Lambda가 재실행된 것입니다.

SQS에 거래 내역 메시지가 도착한다.

SQS는 Lambda를 트리거하며 해당 메시지는 가시성 제한 처리 된다.

Lambda가 SageMaker에 요청을 보낸다.

SageMaker Serverless Endpoint는 Cold Start로 인해 프로비저닝에 많은 시간을 소요한다.

6초가 지나도 SageMaker는 여전히 프로비저닝 중이며 Lambda는 시간 제한 초과로 종료된다.

Lambda 실행 시간 6초 + 24초 => 30초가 지나 SQS 메시지 가시성 제한이 해제된다.

SQS가 다시 Lambda를 트리거하고 SageMaker에 요청한다. SageMaker는 이전 요청으로 인해 프로비저닝이 끝난 상태이므로 Lambda에게 바로 응답한다.

해결 방안

Lambda 함수 제한 시간 상향

Lambda 함수가 SageMaker의 응답을 안정적으로 받을 수 있도록 기존 6초였던 Lambda의 시간 제한을 20초로 여유 있게 설정했습니다.

재발 방지

Lambda 타임아웃 발생 시 CloudWatch Alarm 설정

에러 발생 시 Slack으로 알림을 보내서 개발자가 대처를 할 수 있도록 CloudWatch Alarm을 설정했습니다.

SageMaker Serverless Endpoint와 Lambda 간 통신 불가 트러블슈팅

가나무마 — Wed, 9 Jul 2025 00:54:48 +0900

팀프로젝트 중, 백엔드 개발 담당 팀원이 Lambda 함수가 SageMaker와 통신이 안된다는 문제를 겪고 계셔서 트러블 슈팅을 진행했다.

문제 상황

Lambda 함수가 SageMaker Endpoint로부터 응답을 받지 못하고 타임아웃 후 종료

원인 추측하기

추측 1. Lambda의 제한 시간이 짧다.
SageMaker serverless 엔드포인트는 Lambda와 동일하게 Cold Start 현상이 존재한다.
첫 호출 시엔 프로비저닝에 수 초 이상 소요될 수 있다.
Lambda의 제한 시간이 짧다면, SageMaker의 프로비저닝 시간을 기다리는 동안 시간 초과가 발생했을 수 있다.
반론:
- Cold Start는 첫 요청에만 발생하며, 이후엔 Hot Start로 빠른 응답이 가능하다.
- 하지만 Lambda의 두 번째 호출에도 동일하게 타임아웃이 발생했다. 즉, Hot Start인데도 응답을 받지 못했다.

추측 2. 권한 부족
SameMaker는 IAM 기반 인증을 사용하며 해당 엔트포인트를 호출하기 위해선 sagemaker:InvokeEndpoint 권한이 필요하다.
반론:
- 권한이 부족하면 SageMaker에서 요청을 즉시 거부한다.
- CloudWatch로 SageMaker의 엔드포인트 로그를 확인했을 땐, Lambda로부터 요청 자체가 들어오지 않았다.

추측 3. 네트워크 문제
통신 자체가 안됐으므로 네트워크 문제일 가능성이 가장 유력하다.
Lambda의 네트워크 설정을 확인했더니 Lambda가 VPC에 배치되어 있었다. 설계한 내용과 달랐다.
현재 우리 팀프로젝트의 아키텍처는 아래와 같다.

클라우드 운영 비용을 최대한 줄이기 위해 모든 서비스가 Serverless로 구성된 상태

위를 보면 별 문제 없어 보이지만 상세 구성도는 아래와 같다.

SageMaker와 Lambda가 VPC 외부에 존재한다.

SageMaker의 서버리스 엔드포인트는 현재 VPC 구성을 지원하지 않으며 VPC Endpoint도 제공하지 않는다.
따라서, SageMaker의 엔드포인트와 통신하기 위해선 퍼블릭 인터넷을 통해야 한다.
즉, Lambda를 VPC 내부에 배치하고 NAT Gateway를 통하는 방법과 Lambda를 VPC와 연결하지 않는 방법이 있다.
현재 아키텍처는 고가용성을 목표로 하는 만큼 NAT Gateway를 사용한다면 최소 두 대가 필요하다. 그렇게 된다면 운영비에 상당 부분을 차지하게 된다.
따라서, 비용 절약을 위해 Lambda를 VPC 외부에 배치했다.
문제의 원인은 Lambda가 VPC에 연결된 채 배포되어 퍼블릭 인터넷을 통한 SageMaker 엔드포인트 접근이 불가능했던 것이다.

참고자료

AWS. SageMaker Serverless Endpoint.
https://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/serverless-endpoints.html?utm_source=chatgpt.com