Winter Breeze

[Go] 컨텍스트(Context)

겨울바람_ — Tue, 7 Apr 2026 14:45:59 +0900

고루틴은 한 번 시작하면 외부에서 직접 멈출 방법이 없다. 채널로 quit 신호를 보내는 방법이 있지만, 고루틴이 다른 고루틴을 생성하는 계층 구조에서 quit을 일일이 전달하는게 너무 복잡해진다.

context는 취소 신호를 트리 구조로 자동 전파하기 때문에 복잡한 계층 구조에서 효과적으로 고루틴을 정지시킬 수 있다.

위의 그림처럼 고루틴이 부모 자식 관계로 트리 구조를 형성해 있을 때, 문제가 발생하면 context를 통해 취소 신호가 전파된다. 이를 실제로 구현하면 아래의 코드와 같다.

HTTP Handler에서 파생되는 queryDB 함수와 queryCache 함수, callAPI() 함수의 파라미터로 컨텍스트를 전달하여 취소 신호가 전파될 수 있도록 한다.

context에는 자주 사용되는 4가지 생성 함수가 존재한다.

context.Background()는 루트 컨텍스트로 main함수, 테스트, 최상위 고루틴에서 사용되는 절대 취소되지 않는 빈 컨텍스트다. 모든 컨텍스트 트리의 시작점 역할을 한다.

빈 컨텍스트를 하위 함수에 전달하면서 필요에 따라 WithCancel() 등으로 래핑할 수 있다.

context.WithCancel()는 작업이 끝났을 때 혹은 에러가 났을 때 등 수동으로 고루틴을 취소하고 싶을 때 사용된다.

사용 시 cancel()을 호출하지 않으면 부모 고루틴이 취소될 때까지 자식 컨텍스트의 리소스가 해제되지 않기 때문에 defer cancel()을 필수적으로 사용해야 한다.

context.WithTimeout()은 N초 안에 응답을 받지 못하면 동작을 취소하고 싶을 때 사용한다. HTTP 요청 혹은 DB 쿼리를 호출할 때 자주 사용된다.

WithTimeout(ctx, d)은 내부적으로 WithDeadline(ctx, time.Now().Add(d))와 동일하기 때문에 지정한 시간이 지나면 cancel()을 자동으로 호출한다.

하지만 defer cancel()을 명시하는 편이 좋다. 시간이 지나면 컨텍스트는 취소되지만, 고루틴에 지정된 타임아웃의 지정 시간과 리소스는 자동으로 해제되지 않기 때문에 호출하지 않으면 내부 타이머와 타이머가 참조하는 메모리가 지정된 시간이 지날 때까지 계속 할당되어 있기 때문에 리소스가 낭비된다.

context.WithValue()는 요청 ID, 인증 토큰처럼 요청 범위의 데이터를 파라미터 추가 없이 전달하려고 할 때 주로 사용된다.

WithValue()를 통해 전달되는 키로 string, int 같은 내장 타입을 쓰게 되면 다른 패키지의 키와 충돌이 발생할 수 있기 때문에 반드시 패키지 전용 struct 타입을 키로 사용해야 한다.

예를 들어, 키 값으로 "userID"를 전달하게 되면 다른 패키지에서도 같은 키로 접근이 가능하기 때문에 충돌 가능성이 생긴다.

그래서 패키지마다 전용 구조체 타입을 만들어 외부에서 접근이 불가능하게끔 만들거나 구분될 수 있도록 만들 필요가 있다.

Go는 타입을 비교할 때 패키지 경로까지 포함해서 판단하기 때문에, 이름이 같아도 다른 패키지에 위치해 있다면 서로 다른 타입으로 구분된다.

구현한 구조체를 unexported 하게끔 하여 외부에서 직접 건드리지 못하도록 하는 대신 Set/Get 함수를 필요에 따라 구현하여 전달하는 것이 좋다. 이는 Java의 캡슐화와 굉장히 유사하기 때문에 이전에 Java를 했던 사람이라면 무슨 말인지 쉽게 이해할 수 있을 것이다.

컨텍스트는 사용함에 있어 몇 가지 사용 규칙을 잘 준수해야 버그가 발생하지 않기 때문에 올바른 사용 방법을 숙지하는 것이 중요하다.

컨텍스트를 전달할 때는 첫 번째 파라미터로 전달하는 것이 올바른 사용법이며, 컨텍스트를 구조체에 저장하거나 nil 컨텍스트를 전달하지 않아야 한다. 만약 빈 컨텍스트를 전달하고 싶다면 context.TODO()를 전달하는 것이 좋다. 그리고 한 번 더 언급하자면 defer cancel()을 명시하자.

주로 select문과 context를 연계하여 사용되기 때문에 이전 포스팅에 작성했던 내용을 참고하여 두 기능 모두 잘 공부해서 사용하도록 하자.

Go를 시작한 계기는 쿠버네티스가 Go로 짜여져 있다는 말을 듣기도 했고 OpenTelemetry 사용 시 OCB를 사용하려면 Go로 작성해야 한다는 말을 들어서 였는데, 하다보니 Go라는 언어 자체에 매력이 있는 것 같다.

Go를 사용해서 메트릭 수집기를 만드는 프로젝트를 진행하고 있는데 관련된 내용도 기회가 된다면 포스팅 해보려고 한다.

[Go] 고루틴(Goroutine) & 채널(Channel)

겨울바람_ — Fri, 27 Mar 2026 10:50:13 +0900

Go의 동시성이 OS 스레드 기반의 다른 프로그래밍 언어들보다 훨씬 가벼운 이유는 런타임이 자체 스케줄러를 갖고 있기 때문이다.

OS 스레드를 Go가 직접 사용하는게 아니라, G(goroutine) -> P(processor) -> M(Machine-OS Thread)의 3계층 구조로 고루틴을 관리한다.

고루틴은 Go의 경량 실행 단위(Thread)로 go 키워드를 통해 사용할 수 있다. OS 스레드가 환경에 따라 1~8MB의 스택 크기를 갖는 반면, 고루틴은 그에 비해 최대 500배 작은 2KB의 초기 스택을 갖는다. 항상 2KB로 고정되어 있는건 아니고 64bit 환경 기준 필요에 따라 최대 1GB까지 확장이 가능하다.

또 OS 스레드가 일반적으로 컨텍스트 스위치에 ~1μs가 걸리는 반면 고루틴은 일반적으로 컨텍스트 스위치에 ~100ns의 시간이 걸리는데, OS 스레드와 비교했을 때 10배 빠른 속도로 전환이 가능하다.

프로세서는 고루틴을 실제 OS 스레드에 올려 실행시키는 역할을 맡는다. 프로세서가 없으면 OS 스레드는 고루틴을 실행시킬 수 없기 때문에 Go 런타임의 핵심 자원이라고 할 수 있다. 프로세서는 기본적으로 GOMAXPROCS 의 설정 값만큼 생성되며 기본적으로 CPU 코어 수만큼 생성된다.

각각의 프로세서는 Local Run Queue(LRQ)를 가지고 있는데, 프로그램이 실행되면 프로세서(P)가 할당되고 각 프로세서의 LRQ에는 실행할 고루틴(G)이 배치된다. 이때 OS 스레드(M)은 직접 고루틴을 실행시키는게 아니라 프로세서의 LRQ로부터 고루틴을 가져온 후 실행한다.

LRQ에는 최대 256개의 고루틴이 배치될 수 있으며, 그 숫자를 초과할 시 Global Queue로 이동된다. 만약 OS 스레드가 syscall로 인해 블로킹 상태가 되면 Handoff 메커니즘에 의해 프로세서는 동작 가능한 OS 스레드에 재배치 된다.

OS 스레드(M)는 OS가 실제로 스케줄링 하는 커널 스레드로 프로세서 없이 고루틴을 직접 실행할 수 없다. 블로킹 상태가 되어 프로세서와 분리된 후 다시 동작 가능한 상태가 되면 비어있는 프로세서를 찾거나 Global Queue에서 대기한다.

GPM 모델에서 스케줄러의 효율을 높이는 가장 중요한 메커니즘이 바로 Work-Stealing인데, 특정 프로세서의 LRQ가 비어버리는

경우, 해당 프로세서와 OS 스레드는 유휴 상태가 된다.

다른 프로세서에 고루틴이 쌓여있음에도 놀고 있는 자원이 생기게 되기 때문에 이를 방지하기 위해서 LRQ가 비어버린 프로세서는 다른 프로세서의 LRQ에서 고루틴을 절반 가져와 자신의 비어버린 LRQ에 채운 후 실행을 이어간다.

만약, 다른 프로세서의 LRQ에도 훔쳐올 고루틴이 없다면 Global Queue를 확인하여 대기 중인 고루틴을 가져온다.

고루틴을 사용하다보면 결과를 돌려받아야 할 때가 있는데, 이를 위해 채널을 사용한다. 채널은 송신 대기열(send Queue), 링 버퍼(Ring Buffer), 수신 대기열(Recv Queue)로 구성되어 있다.

채널은 고루틴이 데이터를 주고받는 파이프라고 생각하면 된다. 채널은 Buffered 채널과 Unbuffered 라는 두 개의 특성으로 구분할 수 있는데, Unbuffered 채널의 경우 하나의 수신자가 데이터를 받을 때까지 송신자가 데이터를 보내는 채널에 묶여 있게 된다.

하지만, Buffered 채널을 사용하면 수신자가 받을 준비가 되어 있지 않더라도 지정된 버퍼의 크기만큼 데이터를 보내고 계속 다른 일을 수행할 수 있다.

채널은 close() 함수를 통해 닫을 수 있는데, 닫게 되면 해당 채널로는 데이터를 송신할 수는 없지만 수신은 가능하다.

채널을 복수 사용할 경우 select문을 통해 여러 채널을 동시에 감시할 수 있다. select문은 여러 개의 case에서 각각 다른 채널을 기다리다가 준비가 된 채널의 case를 실행한다. 만약 복수 채널에서 신호가 오면 무작위로 그 중 하나를 선택한다.

대표적으로 자주 사용되는 타임아웃 패턴은 실행이 오래 걸리는 프로세스를 호출하고 정해진 시간까지 응답이 반환되지 않으면, 실패로 간주하고 강제적으로 에러를 반환한다.

무한 루프를 활용한 이벤트 루프 패턴은 close(quit) 명령이 올 때까지 루프를 돌며 작업이 오면 해당 작업을 처리한다. close(quit) 명령을 채널을 통해 수신하면 모든 worker가 루프를 종료한다.

만약 default문이 있으면, case문 채널이 준비되지 않더라도 계속 대기하지 않고 바로 default문을 실행한다. for ch range문을 사용하면 채널이 종료 신호를 받을 때까지 무한 루프가 진행되며, 채널이 비어있을 경우 블로킹 상태로 전환된다.

default문을 활용하는 대표적인 예제가 바로 아래의 로그 처리다.

로그의 경우 일부가 드랍되어도 서비스의 성능에 크게 영향을 미치지 않는다.

로그를 전송하는 Send() 메소드는 default를 사용한 논블로킹 방식으로 값을 보낼 수 없는 상황 즉, 채널의 버퍼가 가득 차면 로그를 드랍한다. 로그를 수집하는 Cousume() 메소드는 default를 사용하지 않는 블로킹 방식으로 값이 수신될 때까지 대기한다.

정리해보자면 select문을 사용했을 때 준비된 케이스가 하나면 그것을 실행, 준비된 케이스가 여러 개면 특정 채널이 굶지 않도록 무작위로 하나 선택. 만약 준비된 케이스가 없다면 default를 실행하는데, default문이 없으면 블로킹 된다.

이번 주제는 난이도가 있어 며칠 동안 나눠쓰는 바람에 주기가 좀 길어졌다. 다음 주제는 context인데 이것도 어려워서 좀 시간이 걸릴 것 같다.

[Go] 메모리 관리에 대해서 알아보자

겨울바람_ — Wed, 18 Mar 2026 17:37:09 +0900

Go에서 메모리는 크게 두 곳에 할당된다. 스택은 함수가 호출될 때 자동으로 생성되고 반환 시 즉시 사라지는 임시 공간으로 사용되고, 힙은 장기적으로 보관되어야 하는 데이터가 머무는 공간으로 사용된다.

장기적인 보관이라 함은, "변수가 함수의 범위를 벗어나도 살아남아야 한다." 정도로 생각하면 쉽게 이해할 수 있다. 함수의 범위에서 벗어나 힙에 할당되는 것을 escape 라고 부른다.

스택 메모리는 자동으로 해제되고 속도가 빠르며, 크기 제한이 존재한다. 주로 함수 내부에 정의된 지역 변수, 함수 파라미터가 스택 메모리에 저장된다.

힙 메모리는 GC를 통해 관리되어 속도가 느리지만, 크기가 스택 메모리에 비해 유연하다. 주로 포인터 타입으로 반환된 변수, 클로저 캡처 등이 저장된다.

Go는 선언된 변수가 힙 메모리에 저장되어야 하는지 스택에 남아있어야 하는지를 컴파일 타임에 결정하는데, 이를 Escape Analysis라고 한다.

개발자가 직접 malloc을 선언하는 C와 다르게, Go는 이 결정을 전적으로 컴파일러에게 맡긴다.

go build -gcflags="-m" 명령어를 사용하면 어떤 변수 혹은 객체 등이 escape 되는지 콘솔을 통해 확인할 수 있다.

위의 코드를 기반으로 go build -gcflags="-m" 명령어를 실행시키면 아래처럼 Escape Analysis가 발생하는 것을 확인할 수 있다.

콘솔에 출력된 내용을 천천히 살펴보자.

우선, newUser가 인라인된 것을 확인할 수 있다. 인라인은 함수 호출을 없애는 최적화로 newUser 함수 호출을 없애고 함수의 본문을 직접 호출 지점에 삽입하는 것을 의미한다.

인라인을 통해 함수 호출을 없애면 스택 프레임 생성/해제 오버헤드 비용이 줄어든다. 즉, Go 컴파일러가 newUser 함수를 단순한 함수라고 판단하여 최적화를 진행했다는 것을 알 수 있다.

하지만 신기하게도 fmt.Println() 함수도 인라인이 됐는데, fmt.Println() 함수는 사실 Fprintln(os.Stdout, a...) 함수를 감싸고 있는 래퍼(Wrapper)이기 때문에 실질적으로 동작을 수행하는 Fprintln(os.Stdout, a...) 함수가 제거된 것이 아니라 래퍼인 fmt.Println()의 호출만 제거된 것이다.

name 파라미터에는 leak이라는 언급이 붙는데, 이는 해당 파라미터가 u에 할당되어 함수 바깥으로 벗어난다는 의미로 사용된다. 메모리 누수가 아니다.

가장 핵심인 newUser 함수의 지역변수인 u가 힙에 할당되었다는 메세지다. 해당 함수가 &u로 변수가 저장된 메모리의 주소를 반환하기 때문에, 함수가 끝나도 u가 살아있어야 한다고 판단했기에 힙 메모리로 이동했다는 것이다.

...은 fmt.Println()에서 사용되는 가변인자 슬라이스(...interface{})인데, 힙이 아닌 스택 메모리에서 처리된다고 표시된다.

마지막으로 p.Name은 fmt.Println()의 interface{}로 전달되어 boxing 되었기 때문에 힙으로 할당되었다.

Go의 컴파일러는 CPU의 월드 사이즈에 맞춰 구조체 필드 사이에 패딩을 자동으로 삽입하는데, 필드 순서를 잘 배치하는 것으로 구조체가 할당되는 메모리의 크기를 줄일 수 있다.

보통 64bit 컴퓨터의 월드 사이즈는 8 바이트이기 때문에 구조체의 필드를 8 바이트 기준으로 정렬하면 메모리 효율을 최적화 할 수 있다.

BadStruct 구조체가 할당된 메모리의 경우

무려 17bytes의 패딩이 들어가 실제 데이터의 크기인 15bytes보다 더 큰 패딩이 추가된 것을 볼 수 있다. 이렇게 되면 32bytes의 메모리를 사용하는 반면,

GoodStruct 구조체가 할당된 메모리의 경우

필드의 순서를 다르게 한 것만으로도 32bytes였던 구조체의 크기를 16bytes로 50%나 줄일 수 있다.

[Prometheus] Thanos & Sharding

겨울바람_ — Thu, 12 Mar 2026 10:42:09 +0900

Prometheus는 메트릭 수집 기능 및 시각화, 쿼리 기능을 제공하며 모니터링에서 사실상 표준 처럼 사용되고 있다.

하지만, 프로메테우스는 단일 노드 시스템으로 설계되어 있기에 확장성과 고가용성 측면에서 부족함이 존재한다. 거기에 수집한 시계열 데이터를 로컬 디스크에 저장하기에 데이터의 영구 보존이 어렵다는 단점을 안고 있다.

이런 단점을 보완하기 위해 등장한 것이 바로 Thanos 다.

Thanos는 위에서 언급됐던 Prometheus의 단점을 모두 보완할 수 있다.

Prometheus 서버에 Thanos Sidecar가 함께 배포된다. Prometheus는 수집된 데이터를 기본적으로 2시간 간격으로 TSDB Block으로 압축하여 로컬 디스크에 저장하는데, Thanos Sidecar는 TSDB Block이 완성되면 이를 감지하여 원격 저장소에 자동으로 업로드한다.

추가적으로 Prometheus는 쌓여있는 작은 TSDB Block을 로컬에서 Compaction(압축)을 통해 하나의 큰 블록 단위로 만드는 작업을 진행한다. 하지만 Thanos를 함께 사용하는 경우 병합된 새 블록의 ID와 구조가 이전의 것과 달라지기 때문에 중복 업로드나 데이터 불일치가 발생할 수 있다.

따라서 Prometheus의 Compaction 기능을 비활성화 하고 Thanos Compactor를 사용하는 것이 좋다. Thanos Compactor를 사용하게 되면, 로컬이 아닌 원격 저장소 내에서 Compaction을 시행하게 된다.

각각 prometheus-0, prometheus-shard-1-0의 설정값이다.

Prometheus는 Sharding을 통해 데이터를 분산 저장할 수 있다. 메트릭 주소값(__address__)을 md5로 해싱하여 'tmp_hash' 라벨로 매핑한 뒤 'modules' 값으로 나눈 나머지 값에 따라 각 프로메테우스 인스턴스에 대해 타겟으로 설정된다. 만약 나눈 나머지의 값이 0이라면 'regex'가 0인 prometheus-0으로 1일 경우 prometheus-shard-1-0으로 메트릭이 스크랩된다.

데이터의 영구 저장 이외에도 Prometheus는 인스턴스를 늘리는 경우, 동일 대상으로 중복된 데이터를 수집하게 되는데 이러한 문제도 Thanos를 통해 해결이 가능하다.

Thanos Query는 replicaLabel을 통해 조회 시점에 중복된 데이터를 하나로 통일하여 반환한다.

예를 들어 Prometheus에서 수집한 데이터의 라벨이

Prometheus + sidecar “A”: cluster=1,env=2,replica=A
Prometheus + sidecar “B”: cluster=1,env=2,replica=B

위의 예제와 같을 때, replica를 제외한 라벨의 값이 모두 동일하기 때문에 Thanos Query는 이를 다른 프로메테우스에서 수집된 동일한 데이터로 판단하고 쿼리 결과에서 하나의 값만을 반환한다.

만약 Sharding을 진행했다면, 분리된 데이터를 Thanos Query가 하나로 통합하여 보내주기 때문에 Grafana와 같은 대시보드 사용 시 매우 유용하다.

[Prometheus] Re-Labeling

겨울바람_ — Tue, 3 Mar 2026 14:34:05 +0900

Re-Labeling은 라벨을 재설정하는 것으로 Prometheus의 타겟과 메트릭을 분류하고 필터링할 수 있게 한다.

prometheus.yaml 파일 내부의 scrape_configs 아래에 relabel_configs 속성을 지정할 수 있다. Re-Labeling은 스크랩이 발생하기 전에 이루어다.

다른 방법은 metric_relabel_configs 인데, 이 속성에 지정된 라벨링은 스크랩 이후에 발생한다. 따라서 스크랩한 후에 받은 모든 메트릭과 라벨에 접근할 수 있다.

relabel_configs

relabel_configs의 'source_labels'는 발생한 메트릭의 labels 배열 중 Re-Labeling을 통해 접근하고자 하는 라벨의 배열을 의미한다. 위의 예제에서는 '__meta_ec2_tag_env' 라는 이름의 라벨의 값에 접근하고자 사용됐다.

'regex'는 source_labels를 통해 추출한 라벨의 특정 값과 일치되는 값을 걸러내기 위해 사용한다. 즉, ' __meta_ec2_tag_env'의 값이 'prod'일 경우 'action' 속성에 정의된 행동을 취하게 된다.

'keep'은 필터링된 타겟을 계속 스크랩하겠다는 의미이며, `drop'은 필터링된 타겟을 스크랩하지 않겠다는 것이다. 주의해야 할 점은 'keep'을 선택할 경우 라벨의 값이 'prod'가 아닌 메트릭은 수집되지 않는다는 것이다.

만약 source_labels의 값이 하나 이상인 경우, Prometheus는 각 라벨의 값을 가져와서 ';'을 통해 결합한다. 위의 예제는 라벨의 값이 '{env="dev"}, {team="marketing"}' 일 경우 해당 메트릭을 계속 스크랩하겠다는 것을 의미한다.

세미콜론(;) 대신 대시(-)를 사용하고 싶다면, `seperator' 속성을 사용하면 된다.

Target Labels는 모든 Timeseries의 라벨에 추가되는 라벨이다. 이는 스크랩에서 반환되는 라벨이기에 어떤 메트릭을 추가해도 항상 Target Labels를 가지게 된다.

'__address__' 라벨의 값이 192.168.1.1:80 이라고 가정해보자. 이 라벨의 IP 부분을 Target Labels로 저장하고 싶다면, 우선 포트 부분을 제외시키고 IP만 노출되도록 변환해야 한다.

'action'을 replace로 지정하고 'target_label'의 값을 통해 라벨에 새롭게 이름을 부여한다.

regex는 콜론(:)을 기준으로 콜론 앞의 값 전부 그리고 뒤의 값 전부를 의미하며, 소괄호로 감싼 부분은 시작부터 콜론(:) 전까지의 모든 부분을 의미한다. 이를 $1으로 추출하여 'replacement'에 지정하는 것으로 '__address__' 라벨에서 IP 값만을 추출하여 Target Labels의 값으로 지정할 수 있다.

결론적으로 Target Labels는 {ip=" 192.168.1.1"} 이렇게 표기될 것이다.

만약 라벨을 삭제하고 싶다면 'regex' 필드에 삭제하고자 하는 라벨의 이름과 일치하는 정규표현식을 작성한다. 그리고 action을 labeldrop으로 설정하면 정규표현식과 일치하는 라벨이 삭제된다.

labeldrop과 반대의 역할을 수행하는 action은 labelkeep이다. 동일하게 'regex'에 스크랩을 유지하고자 하는 라벨의 이름을 지정하고 action을 labelkeep으로 설정하면 된다. 주의할 점은 keep과 동일하게 지정한 라벨을 제외한 모든 라벨이 삭제된다.

참고로 '__'로 시작하는 라벨은 별도로 labeldrop을 사용하지 않더라도 Re-Labeling 이 끝난 후 삭제된다. 만약 '__'로 시작하는 라벨을 유지하고 싶다면 labelmap을 통해 쉽게 유지 가능하다.

labelmap은 라벨의 값을 수정하지 않고 라벨의 이름을 수정한다.

'__meta_ec2_'로 시작하는 모든 라벨의 이름을 'ec2_' 로 시작하도록 변경한다.

metric_relabel_configs

metric_relabel_configs는 위에서 언급했듯이 스크랩 이후에 이루어지기 때문에, 스크랩한 모든 메트릭에 접근할 수 있다.

metric_relabel_configs에서 사용되는 설정들은 relabel_configs에서 사용했던 설정들과 동일하다.

수집된 메트릭의 이름은 '__name__' 라벨에 저장된다. 즉 위의 예제는 'http_errors_total' 이라는 이름의 메트릭을 드랍하기 위해 사용된다.

수집된 메트릭의 이름을 변경하고자 한다면 위의 예제처럼 작성하면 된다. 'http_errors_total' 이라는 메트릭의 이름을 'http_failures_total'로 바꿀 때 사용되는 예제다.

만약 path라벨의 값이 HTTP 요청의 경로인 '/cars'이라면, 라벨의 모습은 {path="/cars"}일 것이다. 이 라벨의 값을 이용해 {endpoint="cars"} 라벨을 새롭게 만들어내고자 할 때 사용하는 것이 위의 예제다.

[Prometheus] Recording Rules

겨울바람_ — Fri, 27 Feb 2026 00:00:39 +0900

Recording Rules는 Prometheus가 주기적으로 PromQL 표현식을 평가하고 그 결과를 데이터베이스에 저장할 수 있도록 한다.

Grafana 같은 대시보드에서 요청을 보냈을 때 Prometheus는 데이터베이스에서 Recording Rules의 결과를 직접 가져와 대시보드로 전달할 수 있다.

Recording Rule을 설정하려면 별도의 rules.yaml 파일에 규칙을 저장해야 한다.

rule.yaml 파일의 예제를 살펴보자.

groups 아래에 하나 이상의 규칙 그룹을 정의한다. 규칙 그룹의 이름과 함께 규칙 평가 간격을 지정해야 한다. 기본적으로 전역 평가 간격을 사용하지만, 그룹 내에 원하는 값을 지정하여 덮어쓰는 것이 가능하다.

이는 Recording Rule을 얼마나 자주 실행하고 수집할지를 결정하고, 특정 표현식을 실행한다. rules 섹션 아래의 각 규칙은 Prometheus에게 expr 필드에 정의된 PromQL의 표현식을 평가하라는 지시를 내린다.

label 필드는 결과를 저장하기 전에 선택적으로 라벨을 추가하거나 제거할 수 있다.

그리고 그룹 내의 규칙들은 선언된 순서대로 순차적으로 평가된다. 즉, 첫 번째로 선언된 규칙이 종료되면 두 번째로 선언된 규칙이 실행되는 것이다.

만약 그룹이 여러 개 존재한다면, 그룹은 병렬적으로 수행되지만 그룹 내의 규칙들은 순차적으로 수행된다.

Recording Rule의 간단한 사용 예시를 들자면, 노드에서 사용 가능한 메모리 공간의 비율과 파일 시스템에서 사용 가능한 여유 공간의 비율을 추적하고 싶다고 가정해보자.

100 - (100 * node_memory_MemFree_bytes / node_memory_MemTotal_bytes)

100 * node_filesystem_free_bytes / node_filesystem_avail_bytes

각각 위와 같은 두 개의 표현식을 필요로 한다. 매번 이 정보를 수집하기 위해 표현식을 실행하고 싶지 않다고 한다면 주기적으로 정보를 수집하기 위해 Recording Rule을 설정하는 것이 좋다.

record 필드에 설정한 규칙의 명칭을 Prometheus의 Expression Browser에 넣으면, expr 필드에 선언한 표현식을 반환한다.

앞서 언급했듯 rule.yaml 파일 내의 규칙들은 그룹 내에서 순차적으로 실행될 것이기에 node_memory_memFree_percent 규칙이 실행이 완료된 후 node_filesystem_free_percent 규칙이 실행될 것이다.

순차적으로 규칙이 실행되기에 현재 진행 중인 규칙이 앞서 실행된 규칙을 참조하는 것도 가능하다.

첫 번째 규칙을 살펴보면, Node Exporter 파일 시스템의 여유 공간의 비율을 가져오는 것이고 두 번째 규칙은 그 평균을 구하는 것이다.

rules.yaml 파일이 수정될 때마다 Prometheus가 이를 자동적으로 감지하지는 않는다. 변경사항을 반영하기 위해서는 Prometheus를 재시작해야 한다. rules.yaml 파일의 작성이 완료됐다면 저장하고 prometheus.yaml 파일에 어떤 파일을 사용할지 지정하면 끝이다.

Prometheus를 재시작 한 후, 설정한 규칙이 정상적으로 동작가능 한지 확인하고 싶다면 Prometheus의 Expression Browser의 Rule health 탭에서 State가 OK로 표시되어 있는지 확인해보면 된다.

이제 node_memory_memFree_percent 를 사용하면 별도의 PromQL 표현식 입력 없이 결과값을 반환한다.

[Prometheus] Histogram & Summary

겨울바람_ — Thu, 26 Feb 2026 10:43:52 +0900

Histogram

Histogram 타입은 관측된 데이터의 분포를 측정하는 메트릭이다.

Histogram 메트릭 타입 내부에는 세 가지의 서브 타입 메트릭이 존재한다.

첫 번째는 '_count'다. 이 메트릭은 이름 그대로 샘플 데이터의 수를 의미한다. 샘플 데이터 값이 아닌 몇 개의 샘플 데이터가 존재하는지를 나타낸다.

위의 예시에서 사용된 'http_request_total_count'는 받은 요청의 수를 나타낸다.

round 함수로 소수점을 정리했기에 메트릭 이름이 보이지 않지만, http_request_total_sum으로 측정된 값이다.

두 번째는 '_sum'이다. 이 메트릭은 수집된 모든 데이터의 합계를 의미한다. 'http_request_total_count'에서 측정된 각 샘플 데이터의 값의 합이 표시되는 것을 확인할 수 있다.

예를 들어, {code="200", instance="node01:3000", job="api", method="get", route="/events"} 인 메트릭의 총 수가 155이고 155개의 샘플 데이터의 모든 값을 더한 값이 175라는 것이다.

해당 캡처본에서 보이는 것 이외에도 더 많은 샘플 데이터가 존재한다.

세 번째는 가장 어려운 '_bucket'이다. 다른 서브 메트릭들과는 다르게 'le' 라벨이 추가된 것을 확인할 수 있다. 해당 라벨이 존재하는 버킷 데이터는 le 라벨에 설정된 값보다 작거나 같은 모든 샘플 데이터들을 포함한다.

http_request_total_bucket{code="200", instance="node01:3000", job="api", le="0.08", method="get", route="/events"}

이 메트릭을 예시로 들자면, le 값이 0.08로 설정되어 있고 반환 값이 362인 것을 확인할 수 있다. 해석해보자면, /events 경로로 들어온 GET 요청 중 0.08초 이내(작거나 같음)로 처리된 요청이 362개 있다는 의미다.

'_bucket'은 le에 지정된 값 이하에서 관측된 값들을 나타낸다.

만약 le 값이 0.02이고 반환된 값이 90이라면, 0.02초 이내로 처리된 요청이 90개가 있다는 것이다.

여기서 알고 넘어가야 하는 건 le가 0.08인 반환값에는 le가 0.05, 0.02인 값들이 포함하고 있다는 것이다. 즉, 값이 누적되기 때문에 le값이 커질 수록 값 또한 증가한다.

최종적으로는 le 값이 '+Inf' 인 메트릭이 존재한다. 이는 양수 무한대보다 작은 모든 샘플 데이터의 수를 의미한다. 이 메트릭은 어떤 경우에는 '_count' 메트릭의 값과 동일할 수도 있지만, 샘플 데이터가 음수 값을 포함할 수도 있기 때문에 다른 경우도 존재한다.

Histogram 타입을 활용하면 Quantiles 값을 매우 쉽게 계산할 수 있다. Quantiles란 분포 상에서 특정 한계값보다 위나 아래에 있는 값의 개수를 결정한다.

'_bucket' 메트릭의 le 라벨과 동일한 역할을 하는 것 같지만, Quantiles는 백분위수를 나타낸다. Histogram의 백분위수를 알고 싶다면, 'histogram_quantile()' 함수를 사용하면 된다.

75%의 백분위수를 알고 싶다면, 다음과 같이 입력하면 된다.

histogram_quantile(0.75, http_request_total_bucket)

첫 번째 인자로 구하고자 하는 백분위수를 입력하고, 다음으로는 관심있는 메트릭을 전달한다.

{code="200", instance="node01:3000", job="api", method="get", route="/events"} 0.28431055900621116 라는 값이 나왔다면, /events 경로로 들어온 GET 요청 중 75%의 요청이 284ms 이하로 처리되었다는 것을 의미한다.

Histogram 메트릭의 백분위수는 SLO가 정확하게 충족되고 있는지를 측정하는데 사용할 수 있다.

Summary

Summary 타입은 Histogram과 비슷하게 동작하지만 기본적으로 퍼센트로 동작하기 때문에 약간 차이가 있다.

Histogram 메트릭과 동일하게 '_count', '_sum' 와 quantiles를 포함한 세 개의 서브 메트릭을 가진다. 가장 큰 차이는 'quantiles'를 포함한 메트릭에서 발생한다.

quantiles가 포함된 메트릭은 기본적으로 Histogram에 histogram_quantile 함수를 사용한 것과 동일하게 동작한다.

Histogram과 Summary의 가장 차이를 비교해보면, Histogram은 버킷의 크기를 설정할 수 있다. 클라이언트에 부담도 덜하고 어떤 Quantile도 선택할 수 있지만 Prometheus 서버는 백분위수에 대한 계산을 수행해야 하기 때문에 서버 측 비용이 Summary에 비해 높다.

Summary 타입은 백분위수를 미리 정의해야 하기 때문에 클라이언트 측 부담이 더욱 크고 미리 정의한 Quantile 값만 사용할 수 있다.

CKA, CKAD, CKS 자격증 취득 후기, 앞으로의 방향성

겨울바람_ — Wed, 11 Feb 2026 16:18:34 +0900

작년부터 진행해오던 클라우드 네이티브 전환 프로젝트를 마무리하며, 오랜만에 글을 남겨보려 한다.

해당 프로젝트를 진행하며 신입이었던 나는 쿠버네티스 플랫폼을 직접 구축했고, 이전에 스터디로만 접해보았던 Observability를 실제 프로젝트에 적용해보는 경험도 할 수 있었다.

사수가 없어 나 혼자 여러 일들을 해야했고, 시행착오도 많았으며 부담이 많이 되기도 했지만 덕분에 적극적으로 공부하고 스터디에 참여할 수 있는 계기가 되었다.

여러 시행착오와 어려움을 겪으며 좀 더 체계적으로 지식을 정리해보고 싶다는 생각이 들었고, 이를 계기로 쿠버네티스 자격증 취득을 결심하게 되었다.

대부분의 IT 자격증은 늘 실효성에 대한 의문이 따라붙는다. 리눅스 자격증이 있다고 해서 그 사람이 실무에서 반드시 뛰어난 역량을 발휘한다고 단정할 수는 없듯, 쿠버네티스 자격증인 CKA, CKAD, CKS 역시 이런 평가에서 자유로울 수는 없다.

이 자격증들은 가상 환경에 접속해 문제를 해결하는 실습형 시험이기에 단순히 문제를 암기하는 것만으로는 통과하기 어렵다. 그럼에도 자격증 취득 사실만으로 해당 분야의 전문가라고 말하기는 힘들다.

나 역시 자격증 취득을 준비하는 과정을 통해 쿠버네티스에 익숙해졌다고 생각하지만, 스스로를 전문가라고 부를 만큼 깊이 있는 이해에 도달했다고 느끼지는 못했다.

그럼에도 누군가 쿠버네티스 자격증 취득을 고민하고 있다면, 나는 적극적으로 취득하기를 추천하고 싶다. 준비 과정 자체가 좋은 공부가 되기 때문이다. 특히, 시험 특성상 공식 문서를 적극적으로 활용해야 하기 때문에, 자연스럽게 공식 문서에 익숙해지고 필요한 정보를 빠르게 찾아 적용하는 능력을 기를 수 있다.

여러 우여곡절 끝에 대표적인 세 가지 자격증을 취득할 수 있었지만, 여기서 만족하지 않고 좀 더 쿠버네티스에 대한 공부를 이어가고자 한다. 또한 쿠버네티스 위에서 주로 사용되는 CNCF 프로젝트들에 대한 이해도 더 깊이 가져가야겠다는 생각이 들었다.

이번 프로젝트에서도 여러 CNCF 프로젝트를 도입해보았지만 내 역량이 충분하지 않아 그 기능과 철학을 온전히 활용하지 못한 것 같아 아쉬움이 남는다.

앞으로는 이번 프로젝트에서 사용했던 Istio, Cilium, OpenTelemetry, Prometheus를 보다 체계적으로 공부해보고자 한다. 단순히 설치하고 사용한느 수준을 넘어 왜 필요한지, 어떤 문제를 해결하기 위해 등장했는지까지 이해하는 것이 목표다. 아울러「쿠버네티스 창시자에게 배우는 모범 사례」라는 책을 읽으며, 쿠버네티스의 아키텍처와 운영 원칙을 다시 한 번 정리해보고자 한다.

아울러 쿠버네티스뿐 아니라, 그 기반이 되는 리눅스에 대해서도 보다 깊이 있기 정리해보고 싶다는 생각이 들었다. 실무에서 쿠버네티스를 다루다 보면 결국 운영체제에 대한 이해가 중요하다는 것을 체감하게 된다.

이에 따라 리눅스 자격증 취득도 다음 목표로 삼고자 한다. 쿠버네티스 자격증과 마찬가지로 리눅스 재단에서 발행하는 LFCS와 Red Hat에서 발행하는 RHCSA 중 하나를 준비해 볼 계획이다.

마침 회사에서 RHCSA 취득 비용을 지원해주고 있어, 우선은 RHCSA를 목표로 준비해볼 생각이다.

이번 자격증 취득이 끝이 아니라, 더 깊이 있는 학습으로 나아가는 출발점이 되기를 기대한다.

오랜만에 적는 글이라 여러모로 두서가 없지만, 그래도 목표로 삼았던 자격증 취득을 이뤄 굉장히 기분이 좋다. 부끄럽지만 마지막은 자격증 자랑으로 마무리 하고자 한다. 이 글을 읽는 사람들도 목표로 삼았던 것들을 모두 이룰 수 있기를 바란다.

Book Study - SRE (Site Reliability Engineering) Chapter08, 09

겨울바람_ — Sun, 6 Apr 2025 21:15:09 +0900

Chapter 8 - Release Engineering

Summary

릴리즈 엔지니어의 역할

릴리즈 엔지니어는 소프트웨어 엔지니어 및 사이트 SRE와 협력하여 소프트웨어의 빌드, 테스트, 패키징, 배포 등 릴리즈에 필요한 모든 단계를 정의한다. 이를 통해 개발 팀이 기능 개발에 집중할 수 있도록 지원하며, 일관되고 반복 가능한 릴리즈 프로세스를 보장한다.

릴리즈 엔지니어링의 철학

자기 주도 서비스 모델 : 릴리즈 프로세스는 자동화를 통해 엔지니어의 개입을 최소화하여 문제 발생하지 않는 이상 엔지니어가 개입할 필요가 없다
빠른 릴리즈 주기
밀폐된 빌드 : 빌드 프로세스의 결과물은 항상 동일해야 하기에 버전 관리를 통해 일관성을 유지한다
원리와 절차의 강제 : 프로젝트 릴리즈 시 엄격한 관리 작업을 통해 문제가 발생했을 때, 새로운 빌드에 어떤 변경 사항이 포함되어 있는지 쉽게 확인할 수 있어 쉽게 조치가 가능하다

Question

CI/CD 파이프라인 구축과 릴리즈 엔지니어링의 차이? (진짜 모름...)

Thoughts

이번 챕터는 릴리즈 엔지니어링이라는 생소한 분야에 대한 설명이 이어졌는데, 전부 읽고 난 후에는 CI/CD 파이프라인 구축을 릴리즈 엔지니어링이라는 용어로 설명하는게 아닌가 싶을 정도로 굉장히 유사한 측면이 많다고 느껴졌다.

Chapter 9 - Simplicity

Summary

시스템의 안정성과 신속함 사이의 균형을 맞추는 것이 SRE의 역할

안정성을 갖춘 프로세스는 신속성을 높이는 경향이 있음.

-> 신뢰성 있는 프로세스는 짧은 시간 내에 버그를 발견하여 수정할 수 있기 때문에, 개발자들이 개발 과정에서 기능 개발에만 집중할 수 있음

불필요한 코드, 한 번도 사용되지 않는 코드 로직은 과감하게 삭제하는 것이 좋다.
-> 예상치 못한 사이드 이펙트가 발생할 확률이 높아지고, 불필요한 코드는 장애 대응 속도를 늦추기 때문

간결한 시스템, 즉 최소한의 구성요소로 구성된 시스템이 가장 완벽한 시스템임
-> 이해하기 쉽고, 수정과 유지보수가 굉장히 용이할수록 확장 또한 쉽기 때문

간결함이 갖춰져야 신뢰성을 확보할 수 있음

Thoughts

시스템 설계 시 단순한 구조로 설계하기 위해 고민하기 보다는 기능이 많은 시스템 구조 위주로 설계 방향을 잡아왔던 적이 많았어서 굉장히 반성하게 되는 챕터였다.

안정성과 신속함의 균형

-> 안정성과 신속함을 서로 상반되는, 일종의 반대급부 개념으로 생각해온 적이 많다.

이번 챕터를 읽으며, 오히려 안정성을 갖춘 시스템일수록 신속한 기능 개발이 가능하다는 점에 크게 공감하게 되었다.

하지만 이미 운영되고 있는 시스템일수록 초기부터 안정성을 염두에 두고 설계된 경우가 드물고,
그만큼 안정성을 확보하기 위한 재설계나 구조 개선에는 많은 시간과 노력이 소요된다.

결과적으로 안정성을 높이기 위한 작업이 진행될수록, 신규 기능 개발은 점점 뒷순위로 밀리게 되고 이로 인해 두 요소 사이의 균형을 잡는 일이 생각보다 훨씬 더 어렵다는 점을 느끼게 된다.

궁극적으로는 프로젝트의 초기에 안정성을 충분히 고려한 설계가 가장 중요하며, 그렇지 못한 상황에서는 조직 차원에서의 명확한 우선순위 정립과 점진적인 개선 전략이 필요하다고 생각하지만...거기에 일정 관리까지 생각한다면 매우 힘든 일이 되지 않을까 싶다.

Book Study - SRE (Site Reliability Engineering) Chapter07

겨울바람_ — Mon, 31 Mar 2025 22:07:50 +0900

Chapter 7 - The Evolution of Automation at Google

Summary

자동화의 필요성: 시스템 규모가 커지고 복잡해짐에 따라 수동 작업은 비효율적이며 휴먼 에러의 발생률이 높아진다. 자동화를 통해 일관성을 유지하고 운영의 신뢰성을 향상시킴
자동화 사례: 클러스터 턴업 자동화를 통해 새로운 클러스터를 설정하는데 드는 시간을 줄이고 이를 통해 낮은 지연 시간을 가지는 클러스터를 구축할 수 있게 되었음. 클러스터 턴업 자동화가 더욱 발전하여 Borg가 되었고, 현재의 Kubernetes의 근간이 된 것 같다.
실패 용인: 구글에서 진행한 자동화의 실패 사례를 설명해줌. 디스크삭제 프로세스 디버깅 중 스크립트가 운영 중이던 거의 모든 서버에 디스크삭제를 진행. 다행히(?) 소수의 사용자만 문제를 인지했었고, 이를 통해 자동화를 더욱 개선할 수 있었다고 함."자동화의 우선순위?"

Questions

-> 일정에 쫓기고 있을 때, 자동화를 하면 더 편해진다는 것을 알면서도 쉽게 시도하지 못할 때가 많다. 당장 눈 앞에 맞닥뜨린 일이 수동으로 할 수 있는 일을 자동화하는 것보다도 급하게 느껴지기 때문이다.

만약 정말 간신히 어떤 작업을 자동화 할 수 있다면, 어떤 기준을 우선시하여 자동화를 진행해야 할까?

Thoughts

"생각 없이 자동화를 진행하면 새로운 문제들이 생겨나기 마련"

-> 자동화라는 이름은 굉장히 편해보이고, 그 결과만 봐서는 굉장히 손쉽게 무언가가 이루어지기에 정말 매력적인 작업이라고 느껴진다.

하지만 그 결과를 이룰 때까지의 과정은 결코 만만치가 않은듯. 특히나 여러 사람이 함께 작업하는 환경일수록 고려해야 하는 것들이 너무 많아지기에 굉장히 공감이 되는 문구였다.

"자동화 꼭 해야하나?"

-> 자동화가 가능하다면 반드시 해야 할까?

개인적으로는 자동화를 도입하는 것이 좋다고 생각하지만, 모든 사람이 이를 환영하는 것은 아니다. 변화와 개선을 달가워하지 않는 사람도 있고, 조직에 따라 자동화의 필요성이 다르게 평가될 수도 있다.

특히, 자동화의 실패 사례를 보면 구글 같은 대규모 기업에서는 큰 문제 없이 넘어갈 수도 있지만, 다른 환경에서는 상황이 다를 수 있다.

예를 들어, 금융권과 같은 신뢰성이 중요한 산업에서 자동화된 프로세스가 실패한다면 그 여파는 심각할 수 있다.

자동화 뿐만이 아니라 무언가 새로운 기술을 도입할 때에는, 조직의 특성과 리스크를 충분히 고려하는 과정이 필요하지 않을까?

Difficulties

"보그에 설정된 작업들은 일주일에 최소한 한 두번은 이동했다."

-> 일단, 쿠버네티스로 비유해보면 파드가 다른 워커 노드로 이동됐다는 의미라고 넘겨짚긴 했지만, 아무래도 보그에 대한 잘 알지 못하다보니 이해하는데 오래 걸린 것 같았다.

Book Study - SRE (Site Reliability Engineering) Chapter05, 06

겨울바람_ — Mon, 24 Mar 2025 22:17:08 +0900

Chapter 5 - Eliminating Toil

Summary

삽질(Toil)의 정의

프로덕션 서비스 운영과 직접적으로 연관이 존재
수작업을 동반함
- 자동화된 작업을 실행하기 위해 수작업으로 스크립트를 실행하는 것 또한 포함된다
반복적임
자동화가 가능함
- 인간의 판단에 의해 실행되어야 한다면 삽질로 분류되지 않는다
사후 대처가 필요함
- 미리 처리할 수 있는 업무가 아니고 업무를 방해하며, 사후에 처리하게 되는 일이다
지속적인 가치가 결여되어 있음
- 특정 작업을 수행했음에도 서비스가 계속 같은 상태로 남아있는 경우
서비스의 성장에 비례하여 증가함

위의 조건들을 만족하는 업무들은 삽질이라고 정의한다.

삽질이 줄어들면 좋은 이유

삽질은 엔지니어의 시간을 소모하고, 자동화와 효율성을 저해하기에 삽질을 줄이거나 제거함으로써 엔지니어는 더 가치 있는 작업에 집중할 수 있다.

엔지니어링에 해당하는 업무

소프트웨어 엔지니어링
- 코드 작성 및 수정, 디자인, 문서화 작업 수행
시스템 엔지니어링
- 프로덕션 시스템의 설정을 조정하거나 문서화 수행
삽질
부하
- 서비스 운영과 직접적으로 관련되지 않은 업무
- HR, 팀 및 회사 회의, 업무 보고, 동료 평가 등

삽질이 불러올 수 있는 문제들

경력 개발이 침체
- 삽질에 매몰되어 프로젝트에 너무 적은 시간을 투입하면 경력 개발이 침체된다
의욕 저하
혼란 가중
성장 저하
좋지 않은 선례를 남김
인력 유출 발생
신뢰에 문제가 생김

Chapter 6 - Monitoring Distributed Systems

Summary

정의

이번 챕터에서 사용되는 용어 정의

모니터링
- 쿼리의 수와 종류, 에러의 수와 종류 등 시스템에 대한 정량적 실시간 데이터를 모으고 처리하고 집계해서 보여주는 것을 의미
화이트박스 모니터링
- 로그나 JVM의 프로파일링 인터페이스, 내부 통계 지표를 제공하는 HTTP 핸들러 등을 이용해서 얻은 시스템의 내부 지표들을 토대로 하는 모니터링
블랙박스 모니터링
- 사용자가 보게 되는 확인 가능한 동작들을 외부에서 테스트하는 과정을 의미
- 시스템이 지금 현재 올바로 동작하지 않고 있는 상황을 알기 위한 것
노드와 머신
- 물리적인 서버, VM, 컨테이너에서 동작하는 커널의 단일 인스턴스를 의미
- 한 머신이 모니터링할 여러 개의 서비스를 운영하고 있을 수도 있다
  - 서로 관련된 서비스
  - 서로 관련이 없지만 하드웨어만 공유하는 서비스

구글의 모니터링 방식

구글은 최종 사용자의 요청률에서 예측하지 못한 변화를 탐지하는 규칙을 통해 구체적이면서도 심각한 예외를 매우 빠르게 찾아낸다.

모니터링 시스템에 있어 중요한 것은 최대한 간결하면서도 팀 모두가 이해할 수 있도록 유지하는 것이다.

중요도가 낮은 서비스들에 대해서는 화이트박스 모니터링을 수행하지만, 반대의 경우에는 블랙박스 모니터링을 수행한다.

블랙박스 모니터링은 아직 발생하지 않았지만 곧 발생할 문제에 대해서는 거의 도움이 되지 않는다.

네 가지 결정적 지표

지연응답
- 요청이 서비스에 의해 처리되기까지의 시간을 의미
트래픽
에러
- 실패한 요청의 비율을 의미
- 명시적인 실패(실제로 에러가 발생) / 묵시적인 실패(정책과 관련된 실패) 모두 고려
서비스 포화 상태
- 가장 병목이 발생하는 리소스를 집중해서 측정
- 긴급한 상황을 미리 예측하는 것과 관련이 깊음

[o11y] Intro-to-mltp - LogQL

겨울바람_ — Tue, 18 Mar 2025 11:00:13 +0900

LogQL

LogQL은 Log Stream Selector를 통해 동작한다.

Log Stream Selector는 ,로 분리된 여러 쌍의 Key-Value 형태로 명시된다. 여러 쌍의 Key-Value 데이터들을 { } 로 감싸서 Stream Selector를 구분하게 된다.

Grafana에서 제공하는 intro-to-mltp 프로젝트에서 Builder를 통해 label을 선택하게 되면 아래쪽에 Log Stream Selector를 확인할 수 있다.

{level="error", beast="beholder"}

위 예제의 Log Stream Selector는 모든 Log Stream들 중에서 명시된 Key-Value의 label들을 가지는 스트림들만 쿼리 결과에 포함시키게 된다.

LogQL은 이외에도 여러 연산자를 지원하는데 이 연산자들은 Label Matching 연산자라고 불리기도 한다.

= : 정확하게 일치
!= : 일치하지 않음
=~ : 정규식에 부합함
!~ : 정규식에 부합하지 않음

{name =~ "mysql.+"} // mysql 이후 어떤 문자가 하나 이상 오는 문자열을 모두 포함 
{name !~ "mysql.+"} // mysql 이후 어떤 문자가 하나 이상 오는 문자열을 모두 미포함 
{name !~ `mysql-\d+`} // mysql 이후 하이픈 + 한자리 이상의 숫자가 오는 문자열을 모두 미포함

Builder를 통해 생성된 쿼리를 살펴보면 Log Stream Selector 이외에도 |= '' 표현식을 볼 수 있는데, 이는 로그 라인에 해당 문자가 포함되어 있다면 쿼리 결과에 포함시키겠다는 의미다.

실제로 해당 표현식을 제외하고 실행시켜도 실행 결과는 다르지 않기 때문에 Builder를 통해 쿼리를 만들 때 일종의 관례처럼 붙여주는게 아닐까 하는 생각이다.

이전 글에서도 살펴봤듯이 intro-to-mltp에서 발생하는 에러는 Not-Null 제약조건이 걸려있는 컬럼인 name 컬럼에 null 값이 삽입되어 발생하는 에러밖에 없는데, 이번에는 LogQL을 통해 이를 좀 더 확실히 확인해보고자 한다.

{level="error", job="mythical-server"} |= "error: null value in column \"name\" of relation"

위의 쿼리는 mythical-server에서 발생하는 로그 중 level=error 레이블을 가지고 null value in column "name" of relation 에러 메세지를 포함한 에러만을 가져오는 쿼리인데, 해당 쿼리를 실행할 경우 아래의 사진처럼 해당 메세지를 포함한 에러 로그만을 가져오는 것을 확인할 수 있다.

이제 해당 에러 메세지 이외의 다른 메세지를 포함하고 있는 에러를 가져와보자. 쿼리는 다음과 같다.

{level="error", job="mythical-server"} != "error: null value in column \"name\" of relation"

위의 쿼리를 실행하면 아래의 사진과 같이 결과가 나오게 된다.

이전 글에서 했던 예측과는 다르게 다른 에러를 확인할 수 있었다. 새롭게 발견된 에러 로그의 메세지는 다음과 같다.

error: duplicate key value violates unique constraint "illithid_name_key"

해당 에러는 테이블의 키 값에서 유니크 제약조건을 위배했기 때문에 발생한 에러로, name 값이 null 인 경우에 발생하는 에러에 비해 극히 드물게 발생하기 때문에 쿼리문 없이 단순 로그만을 확인했을 때 파악하기 어려웠던 에러였다.

mythical-server에서 발생하는 로그 중 에러 로그의 비율을 확인해보는 것도 가능하다. 쿼리는 다음과 같다.

(sum(rate({job = "mythical-server"} | level =`error`[5m]))) / sum(rate({job = "mythical-server"} [5m]))

rate() 함수는 주어진 시간 범위([5m], [10m] 등) 내에서 초당 로그 발생률을 계산한다. rate()는 로그 수를 시간(초)으로 나눈 평균값을 반환한다.

즉, rate({job="mythical-server"} [5m])은 최근 5분 동안 발생한 로그 개수를 300초(5분)로 나눈 값을 의미한다. 해당 비율들을 모두 합산하여 에러 로그 발생률 / 전체 로그 발생률 식을 통해 30분 간의 그래프를 확인해보면 다음과 같다.

rate() 함수 이외에도 수를 세는 count_over_time()를 통해서도 동일한 결과 값을 얻을 수 있다.
아래 그림은 시간이 좀 경과한 상태라서 그림 자체는 다르게 보이지만 나오는 결과 값 자체는 동일하다.

sum(count_over_time({job = "mythical-server"} | level = "error" [5m])) / sum(count_over_time({job = "mythical-server"} [5m])) * 100`

그렇다면 비율을 측정할 때 rate()와 count_over_time() 함수 중 어떤 함수를 사용하는 것이 더욱 효율적일까? ChatGPT의 답변은 다음과 같다.

비율을 시계열 데이터로 표현하기 어려움
- count_over_time()은 고정된 총 개수(정수 값)를 반환하기 때문에, 이를 시계열(time-series) 그래프로 표현하기 어렵습니다.
- 반면 rate()는 초당 로그 발생률(logs/sec)을 반환하여 변화 추이를 쉽게 볼 수 있습니다.
데이터 샘플링 문제
- count_over_time()은 5분 동안 정확히 몇 개의 로그가 있었는지를 반환합니다.
- 하지만 rate()는 로그가 일정하지 않은 경우에도 부드러운 값을 제공합니다.
- 예를 들어, 5분 동안 로그가 몰려 있다가 갑자기 줄어들면 count_over_time()은 급격한 변화를 보이지만, rate()는 점진적인 변화를 보여줍니다.
알람 설정 시 부적절
- rate()는 로그 발생 속도를 기준으로 임계값을 설정할 수 있어 알람 설정에 적합합니다.
- 반면 count_over_time()은 특정 구간의 총 개수만 반환하므로, 일정 주기마다 급격히 변할 수 있습니다.

count_over_time() 함수보다는 rate() 함수를 사용하는게 더 적합하다고 한다.

Reference

https://grafana.com/docs/loki/latest/query/

LogQL: Log query language | Grafana Loki documentation

LogQL: Log query language LogQL is Grafana Loki’s PromQL-inspired query language. Queries act as if they are a distributed grep to aggregate log sources. LogQL uses labels and operators for filtering. There are two types of LogQL queries: Binary operator

grafana.com

https://sbcode.net/grafana/logql/

LogQL - Grafana Tutorials

LogQL Video Lecture Description Now that we have a loki data source we can query it with the LogQL query language. In this video, we will try out many LogQL queries on the Loki data source we've setup. There are two types of LogQL queries: Log queries retu

sbcode.net

Book Study - SRE (Site Reliability Engineering) Chapter03, 04

겨울바람_ — Mon, 17 Mar 2025 09:12:53 +0900

Chapter 3 - Embracing Risk

Summary

SRE 조직에서는 완벽한 가용성을 목표로 삼기보다는 비즈니스 목표와 사용자 기대치를 고려하여 적절한 수준의 신뢰성을 유지하는 것이 핵심이다. 모든 시스템의 가용성을 100%로 설정하려 하면 과도한 운영 비용이 발생할 수 있으며, 이는 불필요한 경우가 많다.

가용성 목표치를 100%로 맞추기 위해 더 많은 노력을 기울이는 대신, 일정 수준의 다운타임을 허용함으로써 운영 비용 절감과 새로운 기능 개발의 균형을 맞추려 한다.

서비스의 위험 수용도(Risk Tolerance) 를 정의할 때는, 해당 서비스의 기능과 시장 내 위치를 고려해야 하며, 소비자 대상 서비스인지 인프라스트럭처 서비스인지에 따라 차이가 발생한다.

예를 들어, 유튜브와 같은 소비자 대상 서비스는 일시적인 장애가 발생하더라도 사용자가 다른 대안을 찾을 수 있어 상대적으로 낮은 가용성을 설정할 수 있다. 그러나, 구글 앱스와 같은 B2B 서비스는 다양한 기업이 업무에 활용하기 때문에 훨씬 높은 수준의 가용성이 요구된다.

또한, 발생할 수 있는 장애의 유형을 예측하고, 목표 가용성을 유지했을 때 발생하는 수익이 이를 달성하기 위한 비용을 상쇄할 수 있는지 등을 고려해야 한다.

인프라스트럭처 서비스의 경우 응답 속도, 신뢰성, 처리량 등의 요소가 더욱 중요하며, 서비스의 특성에 따라 성공과 실패의 기준이 달라진다. 이러한 서비스들은 고객이 시스템을 구축할 때 위험과 비용의 균형을 명확히 설정할 수 있도록 서비스 수준을 정확하게 명시해야 한다. 이를 통해 고객은 자신의 요구사항에 적합한 서비스를 선택할 수 있다.

위험 수용도를 정의한 후에는 에러 예산(Error Budget)을 산정해야 한다. 일반적으로, 위험 수용도가 높을수록 에러 예산이 크고, 위험 수용도가 낮을수록 에러 예산이 작아진다.

에러 예산이 넉넉하면 개발팀은 새로운 기능을 빠르게 배포하고, 실험적인 기능을 개발하는 등 더 많은 리스크를 감수할 수 있다. 반면, 에러 예산이 부족하면 안정성 개선 작업에 집중하고, 배포 속도를 늦춰야 한다.

따라서 에러 예산은 운영 및 배포 전략을 조정하는 중요한 기준이 되므로, 서비스에 맞는 위험 수용도를 명확하게 정의하고 이에 따라 적절한 에러 예산을 산정하는 것이 필수적이다.

Thoughts

책 자체가 확실히 여러 사람이 함께 작성한 내용이다 보니, 용어부분에서 일정 부분 설명이 겹치는 경우가 종종 있는 것 같다.

뭔가 자주 반복해서 나올 수록 점점 더 헷갈리는 것 같기도 하고...

별개로, 이번 챕터에서 나온 내용 중 서비스의 목적에 따라 위험 수용도를 정의해야 한다는 부분이 굉장히 와닿았다.

상대적으로 민감한 정보를 다루게 되는 금융 혹은 공공 분야의 경우 최신 기술을 사용하기 보다는 이미 검증된 기술들 위주로 사용하기 때문에 에러 예산 측정에 더욱 보수적인 것이 맞는 것 같다.

최근에는 금융 및 공공 분야도 클라우드 네이티브 전환을 목적으로 여러 프로젝트가 발생하고 있지만, 신기술과 시스템 안정성과 보안성, 그리고 예측 가능성 사이에서 적절하게 균형을 잡을 수 있을지가 정말 관건인 것 같다.

Chapter 4 - Service Level Objectives

Summary

SLI (Service Level Indicator) - 서비스 수준 척도

서비스 수준을 판단하기 위해 정량적으로 측정한 값을 의미한다.

대부분의 서비스에서 핵심 SLI로 사용하는 지표는 다음과 같다.

응답 속도: 요청을 처리하는 데 걸리는 시간
에러율: 수신한 전체 요청 대비 실패한 요청 비율 (예: HTTP 500 오류 발생률)
처리량(Throughput): 초당 처리할 수 있는 요청 수

이러한 값들은 일정 기간 동안 수집된 데이터를 바탕으로 비율, 평균, 백분위수(percentile) 등을 계산하여 분석된다. 특히, 평균보다는 분포(percentile)가 더 중요한 경우가 많다. 평균 값은 특정 시점에서 발생한 급격한 요청 증가(스파이크)를 제대로 반영하지 못하기 때문이다.

SLI는 주로 쿠버네티스, 프로메테우스, 로그 분석 도구 등을 통해 서버 측에서 수집된다. 그러나 사용자의 실제 경험을 측정하기 위해 클라이언트 측 데이터도 함께 수집하는 것이 중요하다.

여러 가지 서비스 수준 척도가 존재하지만, SRE 팀에서 가장 중요하게 여기는 지표 중 하나는 서비스의 가용성(Availability) 이다. 일반적으로 이는 올바른 요청이 성공적으로 처리된 비율을 의미한다.

SLI를 명확하게 설정하려면 사용자가 원하는 것이 무엇인지 이해하는 것이 중요하다.

사용자가 직접 대면하는 서비스: 가용성, 응답 시간, 처리량이 중요
저장소 시스템(Storage systems): 응답 시간, 가용성, 내구성이 중요
빅데이터 시스템(Big Data systems): 처리량, 종단 간 응답 시간(end-to-end latency)이 중요

SLO (Service Level Objectives) - 서비스 수준 목표

SLI로 측정된 서비스 수준에 대해 목표값 또는 허용 범위를 정의한 것을 의미한다.

SLO는 다음과 같은 수식으로 표현할 수 있다.

SLI ≤ 목표치
최솟값 ≤ SLI ≤ 최댓값

SLO를 설정하고 이를 고객에게 공개하면 서비스 동작에 대한 예측 가능성을 높일 수 있다.
예를 들어, 특정 서비스의 SLO가 "요청당 평균 응답 시간을 100ms 이내로 유지"라고 설정될 수 있다.

또한, SLO를 달성하지 못한 비율은 사용자가 서비스 품질을 어떻게 인식하는지를 평가하는 데 유용한 척도가 된다.
따라서 SLO를 일 단위 또는 주 단위로 추적하여 장기적인 트렌드를 파악하고, 장애 발생 전에 문제 조짐을 미리 감지하는 것이 중요하다.

하지만 적절한 SLO를 설정하는 것은 생각보다 복잡한 작업이다.

서비스 이용자 수처럼 불규칙하고 외부 요인에 따라 변하는 지표는 관리가 어렵다.
현재의 성능을 기준으로 목표치를 설정하면, 이후 변화에 따라 비현실적인 목표가 될 가능성이 높다.
따라서 최대한 단순하게 설정하고, 서비스 특성을 정확히 반영하는 최소한의 SLO를 설정하는 것이 바람직하다.

SLA (Service Level Agreement) - 서비스 수준 협약

SLA는 SLO가 충족되었을 때 또는 충족되지 않았을 때의 보상 조건을 명시한 계약을 의미한다.

일반적으로 SRE는 SLA 체결 과정에는 관여하지 않지만, 서비스 운영 측면에서 SLO를 유지하여 SLA 위반을 방지하는 역할을 담당한다.

모든 서비스에 SLA가 존재하는 것은 아니다.

예를 들어, 구글 검색은 SLA가 없지만, 검색 기능이 중단되면 기업의 평판 악화 및 광고 수익 감소 등 부정적인 영향을 초래할 수 있다.
반면, B2B 서비스(예: Google Workspace, Cloud 서비스) 는 고객과 명확한 SLA를 체결 하며, SLA 위반 시 환불 또는 크레딧 제공 등의 보상이 이루어질 수 있다.

[o11y] Intro-to-mltp

겨울바람_ — Tue, 11 Mar 2025 17:51:34 +0900

Project Architecture Diagram

아래의 아키텍처는 Grafana에서 제공하는 intro-to-mltp라는 프로젝트의 아키텍처로, 본 글은 Grafana의 Loki, Grafana, Tempo, Mimir를 통해 해당 프로젝트에서 발생하는 에러의 원인을 파악하는 것을 목적으로 한다.

Loki

로그는 어디서든 발생할 수 있기 때문에 로그에서 특정한 내용을 찾으려고 할 때 다소 어려움이 존재할 수 있다. 또한 시스템의 가동 시간이 길어지고 사용량이 많아질 수록 기록이 방대해지면서 저장 공간의 필요성도 커지고 있다.

또한, 방대한 양의 로그를 어떤 식으로 결합하고 의미있는 방식으로 집계할지에 대한 고민이 필요하다.

이에 더해, 영구적이지 않은 저장소에서 정보를 추출하는 것은 불확실성을 내포하고 있기에 영구적으로 로그를 저장할 수 있는 저장소가 필요하다.

Loki는 이러한 문제를 해결하기 위해 탄생한 로그를 위한 데이터베이스다.

Loki는 로그의 전체 텍스트가 아닌 메타데이터만 색인화하여 저장한다. 따라서, 쿼리가 더욱 빨라질 뿐 아니라 색인만을 스토리지에 저장하므로 저장소의 리소스 사용량이 현저히 감소한다.

Prometheus & Mimir

메트릭은 시스템이 어떻게 작동하는지에 대한 정량적인 정보를 빠르게 얻는 데 유용하며 숫자로 표현되기 때문에 여러 구성 요소 혹은 시간 경과에 따라 집계할 수 있다.

메트릭 그 자체만으로는 맥락없는 단순한 수치를 나타내기 때문에 문제를 해결하는데 그다지 효과적이지 않다. 구체적인 무언가를 찾기 위해서는 다른 지표를 함께 활용하거나 표현된 숫자가 의미를 갖도록 집계해야 한다.

하지만 메트릭 집계를 위해서는 많은 시간 혹은 리소스가 필요하다.

Prometheus는 메트릭을 위한 데이터베이스지만 기존 데이터베이스와는 다르게 레이블을 사용하여 매우 뛰어난 성능을 자랑한다. 또한 푸시와 풀 기반 모니터링을 제공하기 때문에 애플리케이션 구성 요소가 푸시하는 데이터를 수신할 수도 있고 해당 데이터를 데이터베이스로 가져올 수도 있다.

Mimir는 프로메테우스를 위한 장기 스토리지와 멀티 테넌트 기능을 제공한다. 또한, 수평 확장이 가능하고 안정적이다.

복수의 Prometheus를 운영한다면 Mimir를 활용하는 것이 좋다.

Tempo

트레이스는 로그와 비슷하지만 서비스나 구성 요소에 대한 것이 아니라 단일 트랜잭션에 대한 흐름, 즉 여러 서비스에서 처리되는 요청을 추적하여 어디로 갔는지 어디에서 얼마나 걸렸는지에 대한 흐름을 파악할 수 있다.

로그와 마찬가지로 저장해야 할 정보가 방대하기 때문에 많은 비용이 소모될 수 있다. 트레이스는 모든 구성 요소가 계측된 경우에만 유효하게 동작하는데 이는 실제로 트레이스를 통해 의미있는 정보를 얻기 위해서는 많은 설정이 필요하다는 것을 의미한다.

Tempo는 분산 트레이스를 위한 데이터베이스이며, 파이프 기반으로 동작하는 TraceQL을 통해 트레이스에 필요한 데이터 수집에 적합하다.

Pyroscope

프로파일은 애플리케이션이 얼마나 많은 컴퓨팅 파워 혹은 리소스를 사용하는지에 대한 정보이며, 시간 경과에 따라 특정 간격으로 수집된다.

이는 CPU나 메모리 사용률을 알려준다는 점에서 일종의 메트릭이지만, 전반적인 사용률에 관련된 특정 함수 호출까지 세부적으로 살펴볼 수 있다는 점에서 일종의 트레이스와도 같다.

프로파일은 상당한 오버헤드를 발생시키는데, CPU에 대한 정보 수집 시 CPU에 추가적인 작업이 발생할 수 있기에 성능에 영향을 미칠 수 있다.

Pyroscope는 연속 프로파일을 위한 데이터베이스로 애플리케이션의 성능을 위해 구축됐다. 보통 애플리케이션의 복잡도에 따라 프로파일을 수집하는데 1~10%의 오버헤드가 발생할 수 있는데 Pyroscope는 개별적인 측정항목을 저장하지 않고 전체 프로파일의 형태를 파악하는데 필요한 정보만을 저장한다.

Alloy

Alloy는 OTel, Prometheus, Pyroscope, Loki 및 기타 여려 메트릭, 로그, 트레이스 및 프로파일 도구에 대한 기본 파이프라인을 제공한다.

Beyla

Beyla는 HTTP/gRPC 애플리케이션 자동 계측을 가능하게 하는 오픈소스 프로젝트다. 프로젝트는 eBPF를 기반으로 하며, 이를 통해 리눅스 커널의 다양한 지점에 프로그램을 연결할 수 있다.

애플리케이션에 대한 계측을 진행하려면 일반적으로 언어 에이전트를 배포나 패키지에 추가하고, 수동으로 트레이스 포인트를 추가한 후 재배포를 해야 한다. 그러나 Beyla를 사용하면 소스 코드를 수정하지 않고 단일 명령으로 모든 서비스에 대해 계측을 진행할 수 있다.

Beyla의 목표는 eBPF를 활용하여 애플리케이션 가시성(application observability)을 빠르게 시작할 수 있도록 돕는 것이고, 수집된 텔레메트리 데이터는 Grafana Labs의 LGTM 스택을 통해 백엔드 및 인프라 데이터와 결합되어, 원활한 풀 스택 오픈소스 가시성 솔루션을 제공한다.

Project에서 활용해보기

Tempo를 통해 각 애플리케이션 서비스를 트레이스 해봤을 때, mythical-server와 mythical-requester, postgresql에서 각각 에러가 발생한다는 것을 확인할 수 있었다.

Loki를 통해 mythical-requester에서 발생하는 에러의 로그를 탐색해보았고, 아래의 사진처럼 POST 메소드를 통해 각 테이블 엔드 포인트로 요청을 보냈을 때 지속적으로 요청이 실패하는 것을 확인할 수 있었다.

실패한 로그의 트레이스 ID를 Tempo를 통해 추적해본 결과 아래의 사진처럼 데이터베이스에 INSERT 쿼리를 보낼 때 문제가 생기는 것을 확인해볼 수 있다.

또한 mythical-requester가 mythical-server로 보낸 요청 자체가 실패한 것이기 때문에 mythical-server와 mythical-requester, postgresql에서 각각 에러가 발생한 것임을 알 수 있다.

발생하는 에러 메시지를 자세히 확인해보면 다음과 같다.
null value in column "name" of relation "owlbear" violates not-null constraint

이는 owlbear 테이블의 name 컬럼이 null 값을 허용하지 않는 not-null 제약조건이 걸려있는데, INSERT 요청의 name 값이 null 이기 때문에 발생하는 문제이다.

좀 더 정확한 확인을 위해 데이터베이스의 owlbear 테이블의 제약조건을 조회해보자.

예상했던 대로 name 컬럼의 is_nullable 값이 NO로 설정되어 있는 것을 확인할 수 있다. 해당 프로젝트에서 지속적인 에러가 발생한 원인은 바로 요청에 name 값이 결여되어 있기 때문

Reference

Observability (O11y)

겨울바람_ — Mon, 10 Mar 2025 10:22:35 +0900

Observability란?

인체는 서로 다른 기능을 수행하는 여러 시스템으로 구성되어 있다. 소화계, 호흡계, 신경계, 근육 등 모든 시스템이 모여 하나의 인체를 형성한다.

이중 하나 이상의 시스템이 제대로 동작하지 않을 때, 우리는 원인 모를 질병에 시달리거나 기력을 상실할 것이다. 이를 해결하기 위해 우리는 인체의 전문가 즉, 의사를 찾아간다.

의사는 인체의 체온, 혈압, 산소 수치 등과 같은 신체 지표를 우선 측정한다. 해당 진찰을 통해 우리의 신체 지표 중 이상이 발생한 부분을 발견하고 원인을 파악하기 위해 다양한 검진을 진행할 수 있다.

이를 통해 의사는 우리 인체 내부에서 무슨 일이 발생하는지 어디서 발생하는 지를 더 자세히 알아볼 수 있다. 또한, 이를 통해 의사는 문제를 해결하고 동일한 문제가 발생하지 않도록 예방 계획을 설립할 수 있다.

소프트웨어에 대한 Observability 또한 마찬가지로 응용프로그램을 실행하는 인프라 시스템 내부에서 무슨 일이 일어나고 있는지 관찰하여, 잘못된 부분이 존재한다면 원인과 위치를 파악하는 것이다.

소프트웨어 시스템을 관찰하기 위해 수집하는 가장 일반적인 데이터에는 메트릭, 로그, 트레이스 등이 존재한다.

Metrics

메트릭은 소프트웨어 시스템의 상태와 성능에 대한 단서를 제공하는 수치적 데이터다.

시간 경과에 따라 시스템 성능에 대한 단서를 제공하는 메트릭 데이터를 수집할 수 있고, 관찰 대상에 따라 수집하는 데이터 유형이 달라질 수 있다.

가장 일반적으로 수집되는 메트릭으로는 응답 시간, 요청의 수, CPU 및 메모리 사용량 등이 있다.

Logs

메트릭을 통해 소프트웨어 시스템의 상태가 이상하다는 것을 파악했다면, 로그를 통해 시스템 내부에서 무슨 일이 발생하고 있는지를 파악해야 한다.

로그는 시스템 내부에서 발생한 이벤트에 대한 텍스트 기록이며, 문제가 발생한 시기와 해당 문제와 연관된 이벤트에 대한 단서를 제공한다. 이를 참고하면 시스템 내부에서 발생하고 있는 일에 대해 자세한 맥락 파악이 가능하다.

Traces

트레이스는 애플리케이션에 대한 요청이 시스템 전체를 경유하는 것을 추적할 수 있다.

우리는 이를 통해 메소드, 서비스와 요청이 어떻게 상호작용하는지 관찰하고 병목 현상이 발생하는 경우 정확한 위치를 추적하여 문제의 발생지를 발견할 수 있다.

Reference

Grafana : Observability란 무엇인가?

Book Study - SRE (Site Reliability Engineering) Chapter01, 02

겨울바람_ — Sun, 9 Mar 2025 12:00:12 +0900

Chapter 1 - Introduction

Summary

시스템의 복잡도와 트래픽이 증가할수록 서비스 관리의 어려움이 커지며, 운영팀과 개발팀 간의 상이한 목표로 인해 갈등이 자주 발생한다.

Google은 이를 해결하기 위해 운영을 코드로 해결하는 엔지니어링 접근법을 도입했고, 이를 SRE(Site Reliability Engineering) 라고 명명했다. SRE의 도입으로 인해 제품 개발팀과 SRE팀 간의 손쉬운 업무 전환이 가능해져, 개발팀과 운영팀의 분리에서 발생하는 갈등이 완화되었다.

또한, SRE팀은 반복적인 운영 작업을 자동화하고 혁신적인 운영 방식으로 전환하는 역할을 수행한다.

SRE팀은 개발팀의 목표인 빠른 개발 속도와 운영팀의 목표인 서비스 안정성 사이의 균형을 맞추기 위해 SLO(Service Level Objectives) 를 설정하며, 이를 기준으로 에러 예산(Error Budget) 을 계산한다.

예를 들어, 아래와 같이 SLO와 에러 예산이 설정되었다고 가정해보자.

가용 가능한 SLO를 95%로 설정하면, 에러 예산은 5%
한 달 기준으로 보면 최대 36시간의 다운타임 허용

에러 예산을 활용하면 서비스 신뢰성을 유지하면서도 혁신적인 기능을 빠르게 출시할 수 있다. 즉, 다운타임을 예측 가능한 상황으로 만들어 SRE의 통제 하에서 운영되도록 하는 것이다.

Google에서 제시하는 SRE의 핵심 업무는 다음과 같다:

모니터링 및 긴급 대응 (Monitoring & Incident Response)
변화 관리 (Change Management)
수요 예측 및 수용 계획 (Capacity Planning)
프로비저닝 (Provisioning)
성능 최적화 (Performance Optimization)

❗ Difficulties

생소한 용어들이 많아서 이해하고 적용하는 데 어려움을 겪었다. 주요 개념들을 정리해보았다.

Postmortem

문제가 발생한 후 원인을 분석하고 재발 방지 대책을 마련하는 과정
프로젝트 종료 후 검토 회의를 진행하여 자유롭게 피드백을 공유하는 방식

SLA (Service Level Agreement)

고객이 기대할 수 있는 최소 수준의 성능과 가용성을 정의하는 계약

SLO (Service Level Objective)

공급업체가 SLA를 충족하기 위해 설정하는 내부 목표

SLI (Service Level Indicator)

실제로 SLA 및 SLO를 얼마나 충족하는지 측정하는 지표

Chapter 2 - The Production Environment at Google, from the Viewpoint of an SRE

Summary

Google의 데이터센터 내에는 대규모의 하드웨어 자원이 존재하며, 대규모 분산 시스템을 기반으로 운영된다. 이러한 자원들은 개별 서버 단위가 아닌 분산 클러스터 운영 시스템인 Borg(보그) 를 통해 관리된다.

Borg는 현재 널리 사용되고 있는 쿠버네티스(Kubernetes)의 전신이며, Borg의 태스크(Task)들은 데이터를 Lustre 및 HDFS 같은 클러스터 파일 시스템을 활용해 저장한다.

Google의 서비스들은 Borg 내에서 Job 단위로 관리되며,
전 세계적으로 분포된 서비스 간 지연 시간을 최소화하기 위해 GSLB(Global Server Load Balancing)를 활용해 사용자를 가장 가까운 데이터센터로 연결한다.

본 챕터에서는 사용자의 요청이 Google의 프로덕션 환경에서 어떻게 전달되는지를 예시를 통해 설명한다.

사용자는 도메인에 접속하여 DNS로부터 IP 주소를 획득하게 되는데, 이때 GSLB를 통해 사용자와 가장 근접한 위치에 있는 서버의 IP 주소가 할당된다.

사용자의 요청은 GFE를 통해 서비스의 프론트엔드 서버에 전달되며 프론트엔드와 백엔드는 gRPC를 통해 데이터를 주고받는다. 이때, 프론트엔드와 백엔드 역시 GSLB를 통해 연결된다.

Google의 서비스와 데이터센터는 전 세계적으로 분포되어 있기 때문에, GSLB에 장애가 발생하거나 특정 Task가 트래픽을 감당하지 못하면 서비스 운영이 어려워질 수 있다.

이를 예방하기 위해 Google은

부하 테스트(Load Testing)
여러 지역에서의 시범 테스트

를 통해 각 지역에서 필요한 최소한의 Task 수를 계산하고,
이를 기반으로 안정적인 서비스를 제공한다.

❗ Difficulties

이번 챕터에서는 Borg에 대한 용어가 자주 언급되므로,
아래 표를 통해 핵심 개념을 정리했다.

구성 요소	설명
BorgMaster	Borg 시스템의 중앙 제어 역할을 하며, API 제공, 작업 예약(스케줄링), 클러스터 관리 등을 수행한다.
Scheduler	Slave 노드에서 실행할 작업을 결정하고 할당하는 역할. 리소스 가용성과 우선순위에 따라 작업을 배치한다.
Borglet	각 Slave Node에 설치된 에이전트로, 컨테이너 관리 및 네트워크 라우팅을 담당한다.
작업(Task)	Borg 시스템에서 실행되는 개별 작업 단위.
할당(Alloc)	작업을 실행하기 위해 Scheduler에 의해 Slave 노드에 할당된 자원을 의미.
작업 그룹(Job)	여러 개의 Task를 그룹화하여 관리하는 단위.
셀(Cell)	Borg 시스템에서 클러스터를 관리하는 단위로, 평균적으로 10,000대의 머신으로 구성됨.

References

Borg와 관련된 용어

본 책에서는 SLO, SLA, SLI라는 단어가 직접적으로 언급되지는 않지만, 에러 예산을 조사하는 과정에서 관련된 개념이라 정리해보았다.

메모리 영역

겨울바람_ — Thu, 6 Feb 2025 21:46:09 +0900

buffers와 cached 영역

커널은 디스크로부터 데이터를 읽거나 사용자의 데이터를 디스크에 저장한다.

하지만 디스크는 매우 느리고 I/O에 상당한 시간이 소요되기 때문에 커널은 디스크에 대한 요청을 빠르게 하기 위해 메모리의 일부를 디스크 요청에 대한 캐싱 영역으로 할당한다.

이때 커널이 디스크 캐싱을 위해 할당한 영역을 buffers와 cached라고 부른다.

커널이 읽어야 할 데이터가 파일의 내용이라면 커널은 bio 구조체를 생성하고 해당 구조체에 Page Cache 용도로 할당한 메모리 영역을 연결해준다. bio 구조체는 디바이스 드라이버와 통신하여 디스크로부터 데이터를 읽어 Page Cache에 파일의 내용을 채운다.

super_block, inode_block처럼 파일의 내용이 아닌 파일 시스템을 관리하기 위한 메타 데이터를 읽어올 때는 _get_blk()같은 내부 함수를 통해 블록 디바이스와 직접 통신한다. 그리고 가져온 데이터를 읽어 Buffer Cache에 저장한다.

즉, cached는 파일의 내용을 저장하고 있는 캐시, buffers는 메타 데이터를 담고 있는 캐시라고 할 수 있다.

free 명령어를 통해 각각의 영역을 얼마나 사용하고 있는지 확인할 수 있다.

buffers와 cached 영역은 시스템의 I/O 성능 향상을 위해 커널이 사용하는 영역이지만, 프로세스의 사용량이 많아져 메모리가 부족한 상황이 되면 커널은 해당 영역을 자동으로 반환하기 때문에 free 명령에서도 해당 영역을 제외한 영역을 실제 사용 가능한 영역으로 계산하게 된다.

/proc/meminfo

free 명령어를 통해서도 메모리의 사용량을 확인할 수 있지만, 대략적인 정보만 확인이 가능하다.

현재 메모리의 사용량을 좀 더 세부적으로 확인하고 싶다면 /proc/meminfo를 통해서 free보다 더 많은 정보를 파악할 수 있다.

/proc/meminfo를 통해 파악할 수 있는 정보는 커널의 버전마다 다르지만 공통적으로 나타내는 부분이 존재한다.

SwapCached : swap으로 빠진 영역 중 다시 메모리로 돌아온 영역을 의미한다.

Active (anon) : Page Cache 영역을 제외한 메모리 영역을 의미하며, 주로 프로세스들이 사용하는 메모리 영역을 지칭할 때 많이 사용된다. 그중에서도 비교적 최근에 메모리 영역이 참조되어 swap 영역으로 이동되지 않을 메모리 영역을 의미한다.
Inactivce (anon) : Active (anon)과 같은 영역을 의미하지만, 비교적 참조된 지 오래되어 swap 영역으로 이동될 수 있는 메모리 영역을 의미한다.
Active (file) : anon과 다르게 파일로 되어있는 이영역은 커널이 I/O 성능 향상을 위해 사용하는 영역을 의미한다. buffers와 cached 영역이 여기에 속한다. 그중에서도 비교적 최근에 메모리 영역이 참조되어 swap 영역으로 이동되지 않을 메모리 영역을 의미한다.
Inactive (file) : Active (file)과 같은 영역을 의미하지만, 비교적 참조된 지 오래되어 swap 영역으로 이동될 수 있는 메모리 영역을 의미한다.

Active 영역에서 Inactive 영역으로 이동하는 시기

anon과 file 영역의 메모리는 LRU 기반의 리스트로 관리되고, 각기 Active, Inactive 두 개의 리스트로 나뉜다.

가장 최근에 참조한 메모리가 Active 리스트로 참조 시기가 오래될수록 Inactive 리스트로 이동하고 이후 free 영역으로 이동하게 된다. free 영역의 최소 메모리 양을 결정하는 커널 파라미터로는 vm.min_free_kbytes가 존재한다.

하지만 시간이 지났다고 무조건 이동하는게 아니라 메모리 부족 현상이 발생해서 해제해야 할 메모리를 찾아야 할 때만 이동이 발생하게 된다.

Dirty : Active (file), Inactive (file)과 비슷한 용도다. 커널은 I/O 쓰기 요청이 발생했을 때 바로 블록 디바이스로 명령을 내리지 않고 일정량이 될 때까지 모았다가 한 번이 쓰는 일종의 지연 쓰기 작업을 한다. 이 과정에서 I/O 성능 향상을 위해 커널이 캐시 목적으로 사용하는 영역 중 쓰기 작업이 이루어져서 실제 블록 디바이스의 블록에 씌어져야 할 영역을 의미한다.slab 메모리 영역slab 메모리 영역은 커널이 내부적으로 사용하는 영역이다. /proc/meminfo로 확인할 수 있는 영역 중 slab 항목이 존재한다.

slab : 커널이 직접 사용하는 메모리 영역
SReclaimable : slab 영역 중 재사용될 수 있는 영역으로 캐시 용도로 사용되는 메모리가 주로 포함된다. 메모리 부족 현상이 발생하면 해제되어 프로세스에 할당될 수 있는 영역
SUnreclaime : slab 영역 중 커널이 현재 사용 중이기 때문에 해제해서 재사용될 수 없는 영역

slab 영역에 대한 자세한 정보는 slabtop 명령어를 통해 알아볼 수 있다.

커널은 많은 용량의 메모리를 필요로하지 않기 때문에 메모리를 할당해주는 버디 시스템이 제공하는 4KB 보다 더 작은 양의 메모리를 Slab 할당자를 통해 확보한다.

메모리의 기본 단위인 4KB의 영역을 Slab 할당자가 할당 받은 후 목적별로 나뉘어진 캐시의 크기에 맞게 영역을 나누어 사용한다. 이 경우 종종 페이지 크기의 배수로 나누어 떨어지지 않는 경우도 존재한다.

swap 메모리 영역

swap 메모리는 물리 메모리가 부족할 경우를 대비해서 만든 영역으로, 시스템이 응답 불가 상태에 빠지지 않고 안정적으로 운영될 수 있도록 비상용으로 확보해둔 영역이라고 생각하면 된다.

물리 메모리가 아닌 디스크의 일부를 메모리처럼 사용하기 위해 만들어 놓은 공간이기 때문에 메모리의 접근 속도와 꽤 현저한 차이가 존재한다. 따라서 swap 메모리를 사용하게 되는 경우 시스템의 성능 저하가 발생하게 된다.

swap에 대한 정보는 free 명령어를 통해 확인할 수 있다.

불필요한 프로세스가 메모리를 점유하고 있는 경우 해당 프로세스를 죽여서 메모리를 확보하는 것이 좋다. 이때 프로세스가 사용하는 메모리에 대한 정보를 확인할 수 있는 방법이 /proc/<pid>/smaps 파일이다.

해당 파일은 프로세스가 사용 중인 메모리의 정보를 저장하고 있다.

하지만 이 방법은 프로세스의 메모리 영역별로 살펴봐야 하기 때문에 불편할 수도 있다. 특정 프로세스가 사용하는 전체 swap 메모리에 대한 정보가 필요한 경우에는 /proc/<pid>/status 파일을 통해 확인할 수 있다.

top 명령어 제대로 알고 쓰자

겨울바람_ — Tue, 4 Feb 2025 23:41:43 +0900

top 명령어로 확인하는 프로세스 정보

리눅스 환경에서 사용하는 top 명령어는 주로 동작하고 있는 프로세스의 정보를 손쉽게 확인하여 리눅스 시스템의 상태를 전반적으로 빠르게 확인할 수 있는 명령어다.

top 명령어를 사용하게 되면 프로세스의 상태가 여러 수치들과 함께 화면에 표현되는데 이 수치들이 각각 어떤 의미를 가지고 있는지 알아보도록 하자.

각 수치가 의미하는 정보

현재 서버의 시간과 서버의 구동 시간이 표시된다.
사용자가 몇 명이나 로그인해 있는지, 시스템의 Load Average는 어느 정도인지 보여준다.
- Load Average란 현재 시스템이 얼마나 많이 동작하고 있는지 보여주고 있는 지표로 해당 수치가 높으면 높을 수록 서버가 열심히 일하고 있다는 것을 의미한다.
현재 시스템에서 구동 중인 프로세스의 수를 나타낸다.
CPU, Memory, Swap 메모리의 사용량을 의미한다.
PR은 프로세스의 실행 우선 순위, 즉 다른 프로세스들보다 먼저 실행되어야 하는지의 여부를 의미힌다.
NI는 PR을 얼마나 조정할 것인지를 결정한다. 기본 PR 값에 NI를 더해 실제 PR의 값이 결정된다.
VIRT, RES, SHR에 대해서는 아래에서 더 자세히 설명
S는 프로세스의 상태를 나타낸다.VIRT, RES, SHR이 세 가지 항목은 프로세스가 현재 사용 중인 메모리에 대한 값이다.

VIRT는 프로세스가 사용 중인 가상 메모리의 전체 용량이다. 즉, 프로세스에 할당된 가상 메모리 전체의 크기를 나타낸다.

RES는 현재 프로세스가 사용하고 있는 물리 메모리의 양을 의미한다. 이는 프로세스에 할당된 가상 메모리 VIRT 중 실제로 메모리에 올려서 사용하고 있는 메모리의 크기를 나타낸다.

마지막으로, SHR은 프로세스가 다른 프로세스와 공유하고 있는 공유 메모리의 양을 의미한다. 주로 라이브러리가 이에 해당될 수 있다.

VIRT의 경우에는 실제로는 할당되지 않은 가상의 공간이기 때문에 해당 값이 크다고 해도 문제가 되진 않는다. 실제로 프로세스가 사용하고 있는 메모리는 RES 영역이기 때문에 메모리 점유율이 높은 프로세스를 찾기 위해서는 RES 영역이 높은 프로세스를 찾아야 한다.

Memory Commit - VIRT와 RES는 왜 구분될까?

VIRT로 표현되는 가상 메모리는 프로세스가 커널로부터 사용을 예약받은 메모리라고 생각할 수 있다.

예를 들어, 프로세스는 malloc()과 같은 시스템 콜을 사용해 자신이 필요로 하는 메모리의 영역을 할당해 줄 것을 요청한다. 이에 대해 커널은 가용 가능한 공간이 있다면 성공 메시지와 함께 해당 프로세스가 사용할 수 있도록 가상의 메모리 주소를 전달한다.

하지만 성공 메시지가 전달 됐다고는 해도 물리 메모리에 해당 영역이 할당된 상태는 아니라는 것이다.

이런 동작 방식을 Memory Commit이라고 한다.

이후 프로세스가 할당받은 메모리 영역에 실제로 쓰기 작업을 진행하면 Page fault가 발생하며, 해당 시점에 커널은 실제 물리 메모리에 프로세스의 가상 메모리 공간을 매핑한다. 이는 Page Table 이라고 하는 커널의 전역 변수로 관리된다.

이렇게 실제 물리 메모리에 바인딩된 영역이 RES로 계산된다.

그렇다면 Memory Commit과 같은 방식을 사용해 실제 물리 메모리를 프로세스에 할당하는 시기를 지연시키는 이유는 무엇일까?

주요한 이유는 새로운 프로세스를 만들기 위한 콜을 처리해야 하기 때문이다. fork() 시스템 콜을 사용하면 커널은 현재 실행 중인 프로세스와 똑같은 프로세스를 하나 더 만들게 되는데, 대부분 fork() 후 exec() 시스템 콜을 통해 전혀 다른 프로세스로 변화하게 된다.

fork() 후 exec()로 프로세스를 변화시키는 이유

프로세스가 생성될 때 프로세스는 고유의 주소 공간을 가지게 된다. fork() 시스템 콜을 사용해 부모 프로세스를 복사하게 되면 주소 공간까지 동일하게 복사하게 되는데, 이때 Code, Data, Stack, Program Counter까지 모두 복사되기 때문에 복사된 자식 프로세스는 부모 프로세스가 실행한 부분부터 실행하게 된다.

이렇게 되면 시스템의 프로세스는 모두 똑같이 동작하기 때문에 exec()를 통해 새롭게 프로세스를 덮어씌워야 한다.

따라서 이 과정에서 확보한 메모리 영역이 쓸모없어지기 때문에 COW (Copy-On-Write) 기법을 통해 복사된 메모리 영역에 실제 쓰기 작업이 발생한 후에 실제적인 메모리 할당을 시작하는 것이다.

COW 기법을 사용하기 위해서는 실제 물리 메모리에 할당하는 시기를 지연시키는 Memory Commit이 필수적이다.

현재 시스템의 Memory Commit의 상태는 sar 명령어를 통해 확인할 수 있다.

필자의 서버가 터져서 대체 이미지 사용 출처 : https://www.linuxtechi.com/generate-cpu-memory-io-report-sar-command/

위의 사진에서 %commit의 숫자는 시스템의 Memory Commit의 비율을 나타낸다. 즉, 할당만 되고 실제로 사용되지 않는 메모리의 양이 전체 메모리의 5.05 정도라는 것이다.

수치가 낮다면 순간적으로 해당 메모리에 쓰기 작업이 들어가더라도 전체적으로는 문제가 없지만, 만약 수치가 높다면 순간적으로 시스템에 부하를 일으키거나 커널 응답 불가 현상을 발생시킬 수 있다.

따라서, 커널은 Memory Commit에 대한 동작 방식을 vm.overcommit_memory라는 파라미터로 제어할 수 있도록 했다.

vm.overcommit_memory는 0, 1, 2 세 가지 값으로 설정할 수 있다.

0 : 기본 설정 값으로, overcommit 할 수 있는 최댓값은 page cache와 swap 영역 그리고 slab reclaimable 이 세 값을 합한 값이 된다. 현재 메모리에 가용 공간이 얼마나 존재하는지는 고려하지 않는다.
1 : 아무 것도 계산하지 않고 요청 온 모든 메모리에 대해 commit이 발생한다.
2 : 제한적으로 commit을 진행한다. 계산식이 존재하며 vm.overcommit_ratio에 설정된 비율과 swap 영역의 크기를 토대로 계산된다.

slap reclaimable?

slab reclaimable은 Slab 메모리 중에서 필요한 경우 다시 회수(reclaim) 할 수 있는 메모리의 양을 의미한다. Slab 메모리는 커널이 사용하는 구조체나 객체를 저장하기 위해 할당되며, 커널 공간에서 관리된다.

사용하지 않을 때는 주로 캐시를 위해 할당되는 경우가 많으며, 시스템 메모리가 부족할 때 해제하여 다른 용도로 사용할 수 있다.

vm.overcommit_memory을 통해 swap 영역이 프로세스에 할당되는 commit memory를 결정하는데 큰 역할을 한다는 것을 알 수 있다.

프로세스의 상태 확인

프로세스의 상태는 SHR 옆에 있는 S 항목을 통해 확인할 수 있다.

D - uninterruptible sleep 상태로, 디스크 혹은 네트워크 I/O를 대기하고 있는 프로세스를 의미한다. 이 상태의 프로세스들은 대기하는 동안 Run Queue에서 벗어나 Wait Queue로 들어가게 된다.
R - running 상태로, 실제로 CPU 자원을 소모하며 실행 중인 프로세스를 의미한다.
S - sleeping 상태의 프로세스로, D 상태의 프로세스와의 차이점은 요청한 리소스를 즉시 사용할 수 있는지의 여부다.
T - traced or stopped 상태로, strace 명령어 등으로 프로세스의 시스템 콜을 추적하고 있는 상태를 보여준다.
Z - zombie 상태의 프로세스로 부모 프로세스가 죽은 자식 프로세스를 의미한다.

좀비 상태 프로세스의 경우 스케줄러에 의해 선택되지 않기 때문에 CPU를 사용하지 않고, 이미 사용이 중지된 프로세스이기 때문에 메모리 또한 사용하지 않는다.

하지만, PID를 점유하기 때문에 좀비 프로세스가 쌓이다 보면 PID가 고갈되게 되고 PID 할당이 불가능해진다.

프로세스의 우선 순위

PR과 NI는 커널이 프로세스를 스케줄링할 때 사용하는 우선순위를 나타내는 값이다.

참고로 프로세스 스케줄링이 진행되는 구조는 다음과 같다.

CPU마다 Run Queue라는 것이 존재하며, Run Queue에는 우선순위 별로 프로세스가 연결되어 있다.

스케줄러는 유휴 상태에 있던 프로세스가 깨어나거나 특정 프로세스가 스케줄링을 양보하는 등의 경우에 현재 Run Queue에 있는 프로세스들 중 가장 우선순위가 높은 프로세스를 꺼내서 디스패처에 넘겨준다.

디스패처는 현재 실행 중인 프로세스의 정보를 다른 곳에 저장한 후 넘겨받은 프로세스의 정보를 가지고 다시 연산하도록 요청한다.

이러한 프로세스 스케줄링 과정에서 프로세스의 실제 우선순위 값을 의미하는 것이 바로 PR이며, nice 명령어를 통해 우선순위 값을 낮추는데 이를 표시하는 값을 NI라고 한다.

기본적으로 모든 프로세스는 20의 우선순위를 갖는데, 여기에 nice 명령어를 통해 NI 값을 변경하게 되면 우선순위가 바뀐다.

이때 유의해야 할 점은 프로세스의 우선순위를 낮췄다고 해도, CPU 코어의 수와 동일한 프로세스가 실행되고 있다면 경합이 발생하지 않기 때문에 비슷한 시간에 종료되게 된다.

만약 동일한 우선순위를 가진 A, B 프로세스가 실행 중일 때 새롭게 우선순위가 낮은 C 프로세스가 생성되면, A 프로세스는 다른 CPU의 Run Queue로 옮겨간다.

Load Average

Load Average란 R, D 상태에 놓여있는 프로세스 개수의 1분, 5분, 15분마다의 평균 값을 나타내는 값이다. 이는 얼마나 많은 프로세스가 실행 중이거나, 실행 대기 중인지를 의미하는 수치이다.

Load Average가 높다는 것은 많은 수의 프로세스가 실행 중이거나 I/O 처리를 위해 대기 상태에 있다는 것이며, 낮다는 것은 실행 중이거나 대기 중인 프로세스가 적다는 것을 의미한다.

프로세스의 수를 헤아리는 값이기 때문에 CPU의 코어 수에 따라 값의 의미는 상대적이다.

Load Average가 높은 상황일 때 우리는 그 원인을 파악해야 하는데, 이를 위해서는 CPU를 점유하고 있는 프로세스가 많다는 의미인지 I/O 병목 때문에 I/O 대기 중인 프로세스가 많은 것인지 알아낼 필요가 있다.

부하를 일으키는 프로세스는 CPU 자원을 많이 차지하는 nr_running이라 불리는 프로세스와 nr_uninterruptible로 표현되는 I/O 바운드 프로세스 크게 두 종류로 나눌 수 있다.

top 명령어로는 구체적으로 어떤 부하가 발생하고 있는지 파악하기 어렵기 때문에 vmstat 명령어를 통해 부하의 원인을 명확하게 살펴볼 수 있다.

첫 번째 열의 r은 CPU 자원을 소모하는 nr_running 프로세스의 개수를 나타내고 b는 I/O 자원을 차지하고 있는 nr_uninterruptible 프로세스의 개수를 나타낸다.

단일 트랜잭션 유지 그리고 PGMQ

겨울바람_ — Sun, 15 Dec 2024 21:09:39 +0900

Overview

애플리케이션을 개발하다 보면 어떤 특정한 목적을 위해 비동기 처리를 구현해야 하는 상황을 종종 마주하게 된다.

비동기 처리를 구현하기 위해 흔히 Apache Kafka 혹은 RabbitMQ와 같은 메시지 큐를 도입하곤 한다.

특히나 요즘은 Application Modernization이라는 명목 하에 여러 기업 뿐만 아니라 공공까지도 MSA와 클라우드 사용이 주가 되는 Cloud Native 환경으로 넘어가는 추세이니 만큼 애플리케이션의 복잡도가 수직 상승하고 있기에 비동기 처리를 위한 메시지 큐 사용은 필수적이라고 볼 수 있다.

MSA 환경에서는 각 서비스가 설계자의 의도에 따라 분리되어 있고 모놀리틱 방식에 비해 결합도가 떨어지기 때문에 메시지 큐를 얼마나 잘 활용하느냐가 MSA 환경 구축의 난이도 혹은 기능 구현 여부를 판가름한다.

이러한 상황에서 메시지 큐의 대표격이라 할 수 있는 Apache Kafka와 RabbitMQ의 사용 난이도와 학습 곡선은 꽤나 가파른 편이다. 특히 Kafka의 경우 학습 난이도와 난해함으로 악명이 자자하다.

필자 또한 채팅 기능 구현을 위해 RabbitMQ를 사용해본 경험이 있는데 RabbitMQ의 난이도 또한 그리 쉽지만은 않았다.

거기에 메시지 큐 도구 자체의 복잡성뿐만 아니라 DB와 메시지 큐 간의 데이터 일관성 유지까지 고려한다면, 클라우드 네이티브 환경 구축이라는 목표는 꽤 아득히 먼 곳에 있는 것처럼 느껴진다.

단일 트랜잭션 유지

메시지 큐와 데이터베이스 간 데이터 일관성을 유지하기 위해서는 DB와 메시지 큐를 단일 트랜잭션으로 묶어야 한다.

예를 들어, 비즈니스 로직에 의해 데이터베이스를 수정한 다음 메시지 큐에 메시지를 보냈지만, 이후의 로직에서 에러가 발생하면 동일 트랜잭션에서 수행된 데이터베이스는 Rollback이 발생할 것이다. 하지만 메시지 큐에 보낸 메시지를 다시 롤백시키기에는 어려움이 뒤따른다.

이런 문제를 해결하기 위해 트랜잭션에 데이터가 완전히 커밋된 이후 메시지 큐에 데이터를 전송하도록 구현하는 방법이 존재하지만, 알 수 없는 네트워크 상의 이유로 메시지 전송에 실패할 수도 있다.

이러한 실패에 대비하려면 메시지를 어딘가에 저장해둬야 한다. 하지만 메시지를 어딘가에 저장해둬야 한다는 전제는 우리를 다시 데이터 일관성에 대해 고민하게 만든다.

우리는 이러한 문제를 Transactional Messaging을 통해 해결할 수 있다. 이는 메시지를 데이터베이스 트랜잭션의 일부로 발행하는 것을 의미한다. 즉, 비즈니스 로직에서 데이터베이스를 수정하는 것과 메시지 큐에 메시지를 발행하는 일련의 과정을 원자적으로 수행하여 데이터 일관성을 보장한는 것이다.

Transactional Messaging을 구현하는 두 가지 방법

마이크로서비스 패턴의 저자인 크리스 리처드슨이 제시하는 두 가지 패턴에 대해 간략히 소개하려고 한다. 두 패턴 모두 Outbox라는 테이블을 메시지 큐로 사용한다.

Transactional Outbox Pattern

메시지를 바로 메시지 큐에 보내지 않고 데이터베이스의 아웃박스 테이블에 넣는 방식이다. 이어 데이터베이스 트랜잭션이 커밋되면 주기적으로 아웃박스 테이블 내용을 읽어 메시지 큐에 전달하는 방식이다.

https://microservices.io/patterns/data/transactional-outbox.html

Transactional Log Tailing Pattern

아웃박스 테이블에 메시지 큐에 전달한 메시지를 저장하는 것까지는 Transactional Outbox 패턴과 동일하지만 아웃박스 테이블의 데이터를 읽는 방식에서 차이가 있다.

해당 패턴의 이름대로 데이터베이스의 트랜잭션 로그를 읽고 아웃박스 테이블의 데이터 변경만을 필터링하여 메시지 큐에 전달한다.

https://microservices.io/patterns/data/transaction-log-tailing.html

우발적 복잡성의 증가

비동기 처리를 위해 메시지 큐를 도입하고, 데이터베이스와 메시지 큐 사이의 데이터 일관성을 보장하기 위해 위에서 소개한 패턴 등을 적용하는 과정은 우발적 복잡성을 증가시킨다.

PGMQ (Postgres Message Queue)

이러한 우발적 복잡성의 증가를 막기 위해 PostgreSQL의 PGMQ(Postgres Message Queue)를 활용하여 위에서 언급한 문제들을 해결할 수 있다. PostgreSQL과 PGMQ를 같이 사용하면 데이터베이스 단일 트랜잭션으로 두 가지 작업을 한 번에 묶을 수 있다.

비즈니스 로직을 수행하다 오류가 발생할 경우, 데이터베이스뿐만 아니라 PGMQ에 넣었던 메시지 또한 롤백한다는 것이다.

PGMQ의 사용법은 PostgreSQL 내에서 SQL을 사용하기 때문에 Kafka나 RabbitMQ에 비해 복잡성이 현저히 낮은 편에 속한다.

또한 PGMQ의 메시지를 읽어 Kafka로 전송하는 메시지 릴레이를 추가할 수 있기 때문에 굉장히 다양한 환경에서 적용이 가능하다.

PGMQ는 자체적으로 메시지 삭제 기능을 제공하기 때문에 PGMQ를 사용하는 것으로 아웃박스 테이블을 구현하고 메시지를 추가 및 삭제하는 로직을 추가로 작성할 필요없이 우발적 복잡성을 현저히 낮출 수 있다.

Conclusion

사실 개발판에서는 "은탄환은 없다"라는 말이 자주 쓰인다. 한 번에 모든 것을 해결해주는 만능 도구는 없다는 의미인데, PGMQ 또한 적절한 환경과 상황이 갖추어 졌을 때 사용해야 그 진가를 발휘한다고 생각한다.

이번 포스팅은 아래의 아티클을 참조하여 작성되었다. MSA 환경에 대해 많이 고민하고 있던 필자에게 매우 도움이 된 글이기에 한 번씩 읽어본다면 분명 도움이 될거라고 생각한다.

https://yozm.wishket.com/magazine/detail/2833/

[Go] 함수 고급

겨울바람_ — Mon, 2 Dec 2024 22:29:40 +0900

가변 인수 함수

fmt.Println()
fmt.Println(1)
fmt.Println(1, 2, 3, 4, 5)

fmt 패키지의 Println 함수는 인수 개수가 정해져 있지 않다. 이처럼 인수의 개수가 고정되어 있지 않은 함수를 가벼 인수 함수라고 한다.

... 키워드를 사용해서 가변 인수를 생성할 수 있다. 인수 타입 앞에 ...를 붙여서 해당 타입 인수를 여러 개 받는 가변 인수임을 표시하면 된다.

func sum(nums ...int) int {
    sum := 0

    fmt.Printf("nums 타입 : %T\n", nums)
    for _, v := range nums {
        sum += v
    } 
    return sum
}

func main() {
    fmt.Println(sum(1, 2, 3, 4, 5)) // nums 타입 : []int 15
    fmt.Println(sum(10, 20))        // nums 타입 : []int 30
    fmt.Println(sum())              // nums 타입 : []int 0
}

출력되는 타입에서 확인할 수 있듯이 가변 인수는 함수 내에서 슬라이스 타입으로 처리된다.

fmt.Println() 함수는 이처럼 동일한 타입의 인수를 가변적으로 받을 수도 있지만, 다른 타입의 인수도 여러 개 받을 수 있다. 이는 빈 인터페이스를 인수로 활용했기 때문이다.

...interface{} 타입으로 인수를 받으면 모든 타입의 가변 인수를 받을 수 있다.

func Print(args ...interface{}) string {
    for _, arg := range args {
        switch f := arg.(type) {
        case bool:
            val := arg.(bool)
        case float64:
            val := arg.(float64)
        case int:
            val := arg.(int)
        }
    }
}

`defer` 지연 실행

함수가 종료되기 직전에 실행해야 하는 코드가 존재할 때 사용하는 defer 에 대해 알아보자. 대표적으로 OS 내부 자원을 사용하는 경우, 사용 후 반드시 OS에 해당 자원을 반환해야 한다.

만약 자원을 되돌려주지 않으면 내부 자원이 고갈되어 본래의 기능을 제대로 수행할 수 없기 때문이다. 이러한 경우 자원 반환을 잊지 않고 수행하기 위해 defer를 사용해 해당 기능을 수행할 수 있다.

func main() {
    f, err := os.Create("test.txt")
    if err != nil {
        fmt.Println("failed to create a file")
        return
    }

    defer f.Close()
    defer fmt.Println("defer 동작")

    fmt.Println("파일에 Hello World를 쓴다.")
    fmt.Fprintln(f, "Hello World!")
}

위의 main 함수를 실행하면 생성된 텍스트 파일에 Hello World! 를 작성한 후 함수의 마지막 단계에 "defer 동작" 이라는 문구가 콘솔에 출력되는 것을 확인할 수 있다.

함수 타입 변수

함수 타입 변수란 함수를 값으로 갖는 변수를 의미한다. 포인터는 0과 1로 나타낼 수 있는 숫자를 메모리 주소 값으로 가진다.

작성된 코드 중 100번 라인에서 f() 함수가 시작된다고 가정해보자.

CPU의 프로그램 카운터(PC)는 다음 실행할 라인을 나타내는 레지스터인데, 코드 실행 중 f() 함수가 호출되면 프로그램 카운터는 f() 함수가 시작되는 라인인 100번 라인을 값으로 가지며, 다음 차례에 100번 라인부터 명령을 실행하게 된다.

이를 포인터처럼 라인을 통해 함수의 위치를 가리킨다고 하여 함수 포인터 (function pointer)라고 부른다.

func add(a, b int) int {
    return a + b
}

func mul(a, b int) int {
    return a * b
}

func getOperator(op string) func (int, int) int {
    if op == "+" {
        return add
    } else if op == "*" {
        return mul
    } else {
        return nil
    }
}

func main() {
    var operator func (int, int) int
    operator = getOperator("*")

    var result = operator(3, 4)
    fmt.Println(result) // 12
}

이러한 함수 타입 변수를 사용할 경우 별칭을 사용하여 함수 정의를 줄여 쓸 수 있다.

type opFunc func (int, int) int

func getOperator(op string) opFunc {
    ...
}

함수 리터럴

함수 리터럴은 함수명을 적지 않고 함수 타입 변숫값으로 대입되는 함수값을 의미한다. 익명 함수 혹은 람다 함수라고 불리기도 한다.

return func(a, b int) int {
    return a + b
}

함수 리터럴은 필요한 변수를 내부 상태로 가질 수 있다. 함수 리터럴 내부에서 사용되는 외부 변수는 자동으로 함수 내부 상태로 저장된다.

func main() {
    i := 0

    f := func() {
        i += 10
    }

    i++

    f()

    fmt.Println(i) // 11
}

i는 함수 외부에 선언되어 있는 외부 변수다. 함수 리터럴 내부에서 외부 변수에 접근할 때 필요한 변수를 내부 상태로 가져와서 접근할 수 있도록 한다. 결과적으로 i의 값은 f() 함수에 의해 10이 더해져 11이 된다.

함수 리터럴 내부로 외부 변수를 가져오는 것을 캡쳐라고 한다. 캡쳐는 값 복사가 아닌 참조 형태로 가져오는 것에 주의해야 한다.

값을 복사하는 것이 아닌 외부 변수의 주소값을 포인터 형태로 함수 리터럴 내부로 가져와 사용하게 된다. 값 참조를 사용할 때 외부 변수에 영향을 미치기 싫다면 해당 값을 변수로 받아 값을 복사하는 것을 권장한다.

type Writer func(string)

func writeHello(writer Writer) {
    writer("Hello World!")
}

func main() {
    f, err := os.Create("test.txt")
    if err != nil {
        fmt.Println("Failed to create a file")
        return
    }

    defer f.Close()

    writeHello(func(msg string) {
        fmt.Fprintf(f, msg)
    })
}

파일에 msg를 쓰는 함수 리터럴을 만들어서 writeHello() 함수의 인수로 사용했다. writeHello() 함수는 함수 리터럴을 "Hello World!" 문자열을 인수로 호출했기 때문에 위 예제를 실행하면 test.txt 파일이 생성되고 해당 문자열이 저장된다.

위의 예제는 의존성 주입을 활용한 함수로 writeHello() 함수는 인수로 오는 writer를 호출했을 때 해당 함수가 어떻게 수행될지 알 수 없다. 이렇듯 외부에서 로직을 주입하는 방식으로 객체지향적인 코드 작성이 가능하다.

[k8s] NodePort, LoadBalancer, Ingress

겨울바람_ — Tue, 12 Nov 2024 17:11:35 +0900

NodePort

NodePort는 가장 기본적인 외부 노출 방식으로, 각 노드의 특정 포트를 통해 서비스를 외부에 노출한다.

특징
- Kubernetes 노드의 IP와 특정 포트를 사용하여 외부에서 접근
- 기본적으로 30000~32767 범위의 포트를 사용
- 클러스터의 모든 노드에서 해당 포트로 서비스에 접근할 수 있다
장점
- 설정이 간단하고, 클러스터 외부에서 즉시 접근 가능
- 추가적인 리소스 필요 없이 노드 IP로 접근 가능
단점
- 포트 범위가 제한적이며, 노드의 IP 주소를 알아야 합니다
- 노드가 다운되면 해당 노드의 서비스에 접근 불가

apiVersion: v1 
kind: Service 
metadata:   
    name: my-service 
spec:   
    type: NodePort   
    ports:     
      - port: 80       
        targetPort: 8080       
        nodePort: 30001

LoadBalancer

LoadBalancer는 클라우드 환경에서 주로 사용되는 방식으로, 클라우드 제공자의 로드 밸런서를 통해 외부 트래픽을 서비스로 전달한다.

특징
- 클라우드 환경(AWS, GCP, Azure 등)에서 외부 로드 밸런서를 자동으로 생성하여 IP를 할당
- 서비스마다 고유한 외부 IP가 할당되며, 주로 프로덕션 환경에서 사용
- 온프레미스 환경에서도 Metallb와 같은 소프트웨어를 사용하여 구성 가능
장점
- 외부 IP가 자동으로 할당되어 쉽게 접근 가능하며, 높은 가용성 제공
- 클라우드 로드 밸런서와 연동하여 트래픽을 분산
단점
- 클라우드 제공자의 리소스를 사용할 경우 추가 비용이 발생할 수 있다

apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress

Ingress는 도메인 기반 라우팅을 지원하는 방식으로, 외부 트래픽을 클러스터 내부의 여러 서비스에 전달할 수 있다.

특징
- Ingress Controller를 통해 도메인과 경로 기반 라우팅 규칙을 정의하고 서비스로 연결
- HTTPS를 지원하며, SSL 인증서를 설정하여 보안 트래픽을 처리할 수 있다
장점
- 도메인 및 경로 기반 라우팅이 가능하여, IP 주소를 절약하고 트래픽을 효율적으로 관리
- 하나의 IP로 여러 도메인이나 서브도메인을 관리 가능
단점
- Ingress Controller를 설치해야 하며, 설정이 다소 복잡할 수 있다.
- 클러스터 환경에 따라 지원되는 Ingress Controller가 제한될 수 있다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /service1
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80
          - path: /service2
            pathType: Prefix
            backend:
              service:
                name: service2
                port:
                  number: 80

Ingress, LoadBalancer, NodePort의 차이점

유형	특징	장점	단점	사용 사례
NodePort	노드의 특정 포트를 통해 서비스 노출	설정이 간단하고 추가 리소스가 필요 없음	포트 범위가 제한적이며 노드 IP가 필요	개발 환경, 간단한 서비스 노출
LoadBalancer	클라우드 로드 밸런서를 통해 외부 노출	외부 IP 자동 할당, 높은 가용성과 로드 밸런싱 제공	클라우드 비용 발생, 온프레미스 지원 제한	클라우드 환경의 프로덕션 서비스
Ingress	도메인 기반 라우팅, SSL 지원 가능	도메인과 경로 기반의 정교한 라우팅, IP 절약	Ingress Controller 설정 필요, 다소 복잡	다수의 서비스, 도메인 기반의 접근이 필요한 경우

[k8s] k8s Security basic

겨울바람_ — Mon, 11 Nov 2024 16:02:54 +0900

Overview

쿠버네티스 환경에서의 보안이란 쿠버네티스 클러스터의 안정성과 보안성을 유지하는 것을 의미한다.

쿠버네티스는 클러스터의 보안을 위해 많은 기능을 제공하지만, 이번 포스팅에서는 CKA 자격증 준비를 위해 공부했던 세 가지 기능에 대한 소개를 하려고 한다.

Network Policy
Role-Based Access Control
Secret

Network Policy

쿠버네티스의 통신 정책은 기본적으로 모든 Pod 간 통신을 허용한다. 이는 Pod 간 통신을 원활하게 해주지만, 원치 않는 통신에 Pod를 노출시킬 수 있다는 위험 또한 존재한다.

외부의 위협으로부터 Pod를 보호하기 위해 사용되는 쿠버네티스 보안 기능이 바로 네트워크 정책(Network Policy)이다.

네트워크 정책은 Pod 간 통신 또는 다른 네트워크 엔드포인트와 Pod 사이의 통신을 제어하는 기능이다. 네트워크 정책을 사용하면 IP 주소, 포트, 프로토콜 및 레이블(label), 네임스페이스와 같은 다양한 기준에 따라 트래픽을 허용하거나 거부하는 규칙을 정의할 수 있다.

네트워크 정책은 쿠버네티스 네트워크 플러그인 아키텍처를 사용하여 구현되기 때문에 네트워크 플러그인마다 네트워크 정책에 대한 지원 수준에 차이 존재할 수 있다.

네트워크 정책 설정 시 다음 세 가지 요소를 중점으로 살펴보아야 한다.

podSelector : 정책이 적용될 Pod를 지정한다
policyTypes : 정책이 적용될 트래픽을 지정한다
ingress/egress : 수신 트래픽 / 발신 트래픽에 대한 세부 내용을 지정한다

아래의 예시 YAML 파일을 통해 사용 사례를 살펴보자.

apiVersion: networking.k8s.io/v1    # NetworkPolicy 리소스의 API 버전 
kind: NetworkPolicy                 
metadata:
  name: test-network-policy        
  namespace: default                
spec:
  podSelector: 
    matchLabels:
      role: db                      # 이 정책이 적용될 Pod를 선택. 여기서는 "role=db" 레이블을 가진 Pod들에 적용됨
  policyTypes:
    - Ingress                       # 인바운드 트래픽에 대한 규칙 정의
    - Egress                        # 아웃바운드 트래픽에 대한 규칙 정의
  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16     # 인바운드 트래픽을 허용할 IP 범위 설정. 여기서는 "172.17.0.0/16" 대역의 IP에서 오는 요청 허용
            except:
              - 172.17.1.0/24       # 위의 cidr에서 제외할 IP 범위 설정. "172.17.1.0/24" 대역은 제외하여 차단
        - namespaceSelector:
            matchLabels:
              project: myproject    # 특정 네임스페이스에서 오는 트래픽을 허용. 여기서는 "project=myproject" 레이블이 있는 네임스페이스에서 오는 요청 허용
        - podSelector:
            matchLabels:
              role: frontend        # 특정 레이블을 가진 Pod에서 오는 트래픽을 허용. 여기서는 "role=frontend" 레이블이 있는 Pod에서 오는 요청 허용
      ports:
        - protocol: TCP             # 허용할 프로토콜 지정. 여기서는 TCP만 허용
          port: 6379                # 허용할 포트 번호. 여기서는 6379 포트만 허용
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24       # 아웃바운드 트래픽이 허용될 IP 범위 설정. "10.0.0.0/24" 대역으로 나가는 트래픽 허용
      ports:
        - protocol: TCP             # 허용할 프로토콜 지정. 여기서는 TCP만 허용
          port: 5978                # 허용할 포트 번호. 여기서는 5978 포트만 허용

위의 YAML 파일은 쿠버네티스의 공식 문서 중 Network Policy 문서의 예제 YAML 파일을 가져온 것이다.

YAML 파일 내에 작성된 주석을 통해 네트워크 정책의 동작 방식에 대해 유심히 살펴보면 클라우드 서비스에서 제공하는 보안 그룹과 유사하게 동작할 것을 예상할 수 있다.

이러한 동작을 통해 Pod에서 동작하는 애플리케이션이 어떤 요청을 받을 수 있고, 어디로 요청 혹은 응답을 보낼 수 있는지 결정하고 통제한다. 이에 더해 Pod의 네트워크 트래픽을 제한하는 것으로 다양한 외부 공격으로부터 클러스터를 보호할 수 있다.

Role-Based Access Control

쿠버네티스에 존재하는 여러 리소스들에 대한 권한을 사용자 및 서비스 계정의 역할을 정의하는 것으로 제어하는 것을 RBAC, 역할 기반 접근 제어라고 한다.

사용자나 서비스 계정의 역할을 설정하는 Role, 클러스터 수준에서 역할을 설정하는 ClusterRole을 사용해 보안 규칙을 정의하고, 정의한 규칙을 사용자의 모음인 Group에 정의한다.

역할 기반 접근 제어를 설정하기 위해서는 다음 세 가지 요소를 중점적으로 살펴봐야 한다.

Role : 쿠버네티스 리소스에 대한 권한의 집합이다. 특정 네임스페이스에서만 유효한 권한 할당
RoleBinding : 특정 사용자 혹은 사용자의 계정에 Role을 할당한다
ClusterRole : Role과 유사하지만, 클러스터 전체에서 유효한 권한을 할당한다.ClusterRoleBinding을 통해 사용자 또는 사용자의 계정과 연결을 정의해야 한다

다음은 각각 Role을 생성하여 특정 사용자에게 연결하는 Rolebinding에 대한 예제 YAML 파일이다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]                   
  resources: ["pods"]                  # 접근할 수 있는 리소스 지정 
  verbs: ["get", "watch", "list"]      # 리소스에 대한 작업 권한 부여 

--- 

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

리소스에 대한 작업 권한을 부여하는 verbs는 총 9가지가 존재한다.

create : 새로운 리소스 생성할 수 있는 권한
get : 개별 리소스 세부 정보를 조회할 수 있는 권한
list : 리소스 목록을 조회할 수 있는 권한
update : 기존 리소스 내용 전체를 수정할 수 있는 권한
patch : 기존 리소스 내용을 부분적으로 수정할 수 있는 권한
delete : 특정 리소스를 삭제할 수 있는 권한
deletecollection : 여러 리소스를 한 번에 삭제하는 권한. 일괄 삭제할 때 사용
watch : 리소스의 변경 사항을 실시간으로 모니터링 할 수 있는 권한
impersonate : 다른 사용자 혹은 계정으로 가장하는 권한. 다른 사용자 계정으로 API 요청을 수행할 수 있음

이처럼, 역할 기반 접근 제어를 적용할 경우 클러스터 관리자는 리소스에 대한 접근 권한을 관리할 수 있다. 이를 통해 다양한 사용자와 서비스 계정 간 접근 권한을 분리하여, 권한이 부여되지 않은 사용자가 민감한 데이터를 볼 수 없게끔 보호할 수 있다.

Secret

시크릿은 암호화된 정보, 토큰, 비밀번호와 같은 중요한 데이터를 안전하게 저장하기 위한 리소스다.

시크릿 정보는 컨테이너 이미지에 포함되지 않으며, 애플리케이션을 실행하는 동안 환경 변수 또는 볼륨 마운트를 통해 컨테이너에 전달된다.

시크릿은 일반적으로 Base64로 인코딩된 Key-Value 쌍으로 정의된다. 인코딩된 시크릿은 컨테이너 런타임시 복호화 되어 사용되므로, 시크릿을 사용하는 애플리케이션은 별도로 복호화 로직을 구현할 필요가 없다.

시크릿은 Pod와 독립적으로 생성되며, 민감 정보를 etcd 저장소에 보관하다가 Pod가 해당 정보를 필요로 할 때 컨테이너에 제공해준다.

아래는 간단한 시크릿 사용 예제다.

$echo -n "admin" | base64
YWRtaW4=
$echo -n "1234" | base64
MTIzNA==

시크릿에 정보를 저장하기 위해서는 우선 평문이 아닌 Base64로 인코딩한 문자열을 필드로 넣어줘야 한다.

apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
type: Opaque
data:
  USERNAME: YWRtaW4=
  PASSWORD: MTIzNA==

시크릿은 타입은 크게 네 가지가 존재한다.

Opaque : 일반적인 용도의 시크릿. ConfigMaps와 동일한 목적으로 사용할 수 있으며, 민감한 데이터를 컨테이너에 전달하는 용도로도 사용할 수 있다
dockerconfigjson : 도커 이미지 저장소 인증 정보. private 레지스트리에 접근하기 위한 인증 절차를 치룰 때 사용하는 용도
tls : TLS 인증서를 시크릿으로 관리할 수 있도록 한다. TLS 인증서를 시크릿을 통해 저장하면, Pod나 Service 같은 리소스에서 TLS 인증서를 가져다 통신을 암호화 할 수 있다
service-account-token : Service Account에 대한 인증 정보를 담은 토큰을 시크릿으로 생성

시크릿은 인코딩-디코딩 방식을 통해 암복호화가 이루어지기 때문에 완벽하게 데이터를 보호하는 방법이라고 볼 수 없다.

그렇기 때문에 역할 기반 접근 제어를 통해 권한이 있는 사용자만 시크릿 정보를 조회할 수 있도록 제한하거나, 별도의 암호화 플러그인과 KMS를 통해 시크릿을 완전히 암호화 하는 것을 권장한다.

Reference

https://yozm.wishket.com/magazine/detail/1953/

[Go] 인터페이스

겨울바람_ — Sun, 10 Nov 2024 19:09:17 +0900

Interface

인터페이스란 구현을 포함하지 않는 메소드 집합으로, 구체화된 타입이 아닌 인터페이스만 가지고 메소드를 호출할 수 있어 추후 프로그램 요구사항 변경 시 유연하게 대처할 수 있다.

Go에서는 인터페이스 구현 여부를 특정 타입이 인터페이스에 해당하는 메소드를 가지고 있는지로 판단하는 덕 타이핑을 지원한다.

인터페이스를 사용하는 것으로 객체 간 상호작용을 정의할 수 있으며, 덕 타이핑을 통해 사용자 중심의 코딩이 가능하다.

인터페이스 선언 방법은 다음과 같다.

type DuckInterface interface {
    Fly()
    Walk(distance int) int
}

인터페이스 또한 구조체처럼 타입의 한 종류이기 때문에 type 키워드를 작성해야 한다. 인터페이스를 작성할 때 유의해야 할 몇 가지 주의 사항을 살펴보자.

메소드는 반드시 메소드명이 있어야 한다
매개변수와 반환이 다르더라도 이름이 동일한 메소드는 있을 수 없다
인터페이스에서는 메소드 구현을 포함하지 않는다

필자의 생각으로 가장 주의깊게 봐야하는 것이 바로 2번 항목이다. 메소드 포스팅에서도 그러했듯이 Java를 사용해본 적이 있는 개발자들에게 인터페이스라는 이름이 굉장히 친숙할 것이다.

하지만, Go에서는 메소드 오버로딩을 지원하지 않기 때문에 매개변수와 반환 값이 다르더라도 동일한 메소드명을 사용할 수 없다.

인터페이스의 사용 방법을 나타낸 간단한 코드 예제다.

package main

import "fmt"

type Stringer interface {
    String() string
}

type Student struct {
    Name string
    Age int
}

func (s Student) String() string {
    return fmt.Sprintf("이름 : %s, 나이 : %d", s.Name, s.Age)
}

func main() {
    student := Student{ "철수", 12 }
    var stringer Stringer

    stringer = student

    fmt.Printf("%s\n", string.String()) // 이름 : 철수, 나이 : 12
}

덕 타이핑

Go언어에서는 어떤 타입이 인터페이스를 포함하고 있는지 여부를 결정할 때 덕 타이핑 방식을 사용한다.

덕 타이핑이란 타입 선언 시 인터페이스 구현 여부를 명시적으로 나타낼 필요 없이 인터페이스에 정의한 메소드 포함 여부만으로 결정하는 방식이다.

덕 타이핑 방식의 장점은 사용자 중심의 코딩을 할 수 있다는 점이다.

덕 타이핑에서는 인터페이스 구현 여부를 타입 선언에서 하는 게 아니라 인터페이스가 사용될 때 해당 타입이 인터페이스에 정의된 메소드를 포함했는지 여부로 결정하기 때문에, 서비스 제공자가 인터페이스를 정의할 필요 없이 구체화된 객체만 제공하고 서비스 이용자가 필요에 따라 인터페이스를 정의해서 사용할 수 있다.

인터페이스를 포함하는 인터페이스

구조체가 다른 구조체를 포함하는 필드를 가질 수 있듯이, 인터페이스 또한 다른 인터페이스를 포함할 수 있다. 이를 포함된 인터페이스라고 한다.

다음 예제를 살펴보자.

type Reader interface {
    Read() (n int, err error)
    Close() error
}

type Writer interface {
    Write() (n int, err error)
    Close() error
}

type ReadWriter interface {
    Reader // Reader의 메소드 집합을 포함한다. 
    Writer // Writer의 메소드 집합을 포함한다.
}

위의 예제에서 ReadWriter 인터페이스에 포함된 Reader, Writer 인터페이스에 동일한 이름의 메소드인 Close()가 존재한다.

이 경우, 두 인터페이스 존재하는 각각의 Close() 메소드가 하나로 합쳐져서 하나의 Close() 메소드만 ReadWriter 인터페이스에 포함되게 된다.

그리고 덕 타이핑에 의해서 Read(), Write(), Close() 메소드를 구현한 타입은 세 인터페이스를 모두 사용 가능하다.

빈 인터페이스

interface{}는 메소드가 없는 빈 인터페이스로 모든 타입을 받을 수 있는 함수, 메소드, 변수값을 만들 때 주로 사용된다.

package main

import "fmt"

func PrintVal(v interface{}) {
    switch t := v.(type) {
    case int:
        fmt.Println("v is int")
    case float64: 
        fmt.Println("v is float64")
    case string:
        fmt.Println("v is string")
    default:
        fmt.Println("Not Supported Type")
    }
}

type Student struct {
    Name string
}

func main() {
    PrintVal(10)           // v is int
    PrintVal(3.14)         // v is float64
    PrintVal("hello")      // v is string
    Printval(Student{15})  // Not Supported Type
}

인터페이스의 기본값은 nil

인터페이스의 기본값은 유효하지 않은 메모리 주소를 나타내는 nil이다.

만약 인터페이스 변수를 초기화하지 않고 사용하게 될 경우 인터페이스의 기본값은 nil이기 때문에, 런 타임 에러가 발생하게 된다.

type Attacker interface {
    Attack()
}

func main() {
    var att Attacker
    att.Attack() // runtime error: invalid memory address or nil pointer dereference
}

인터페이스 변환

인터페이스 변수를 타입 변환을 통해서 구체화된 다른 타입이나 다른 인터페이스로도 변환할 수 있다.

구체화된 다른 타입으로 변환하는 방법은 인터페이스를 본래의 구체화된 타입으로 복원할 때 주로 사용한다. 사용 방법은 인터페이스 변수 뒤에 .을 찍고 ()안에 변경하려는 타입을 써주면 된다.

var a Interface
t := a.(ConcreteType)

구체적인 사용 예시를 위해 코드를 작성해보자.

package main

import "fmt"

type Stringer interface {
    String() string
}

type Student struct {
    Name string
}

func (s *Student) String() string {
    return fmt.Sprintf("Student Name: %s", s.Name)
}

func PrintAge(stringer Stringer) {
    s := string.(*Student)
    fmt.Printf("Name: %s\n", s.Name) 
}

func main() {
    s := &Student{"철수"}
    PrintAge(s) // Name: 철수
}

위의 코드에서 Stringer 인터페이스를 *Student타입으로 형변환시켰다. 그 이유는 Stringer 인터페이스는 String() 메소드만 존재하기 때문에 Name 필드에 접근할 수 없기 때문이다.

즉, Name 필드를 호출하기 위해 인터페이스를 형변환시킨 것이다. PrintAge()로 넘겨진 stringer 인스턴스 변수 내부에 *Student 타입 인스턴스를 가리키고 있었기 때문에 에러 없이 변환이 이루어진다.

다른 인터페이스로 타입 변환하기

인터페이스를 또 다른 인터페이스로 변환할 수 있다. 구체화된 타입으로 변환할 때와는 달리 변경되는 인터페이스가 변경 전 인터페이스를 포함하지 않아도 된다.

하지만 인터페이스가 가리키고 있는 실제 인스턴스가 변환하고자 하는 다른 인터페이스를 포함해야 한다.

Student타입이 Interface A와 Interface B 인터페이스를 모두 포함하고 있는 경우에 다음과 같이 Student 인스턴스를 가리키고 있는 Interface A 변수 a는 Interface B로 변환이 가능하다.

var a Interface_A = Student{}
b := a.(Interface_B)

타입 변환이 아예 불가능한 타입이라면 컴파일 타임 에러가 발생하고 문법적으로 문제 없지만, 실행 도중 타입 변환에 실패하는 경우에는 런 타임 에러가 발생한다.

이를 예방하기 위해 타입 변환 가능 여부를 확인하여 런 타임 에러가 발생하지 않는 타입 변환 방법에 대해 알아보자.

타입 변환 반환값을 두 개의 변수로 받으면 타입 변환 가능 여부를 두 번째 반환값으로 알려준다. 이때 타입 변환이 불가능하면 두 번째 반환값이 false로 반환되며, 런 타임 에러는 발생하지 않는다.

var a Interface
t, ok := a.(Type)

만약 변환에 실패하더라도 런 타임 에러를 방지할 수 있기 때문에 인터페이스 변환 시 아래의 코드와 같이 변환 여부를 확인하기를 추천한다.

func ReadFile(reader Reader) {
    if c, ok := reader.(Closer); ok {
        ...
    }
}

[Go] 메소드

겨울바람_ — Sat, 9 Nov 2024 19:05:51 +0900

Method

이전에 Java를 사용해본 사람이라며 Method라는 이름이 친숙하게 느껴질 것이다. 필자 또한 Java를 주로 사용했기 때문에 이번 파트를 공부하며 Method라는 명칭이 굉장히 반갑게 느껴졌다.

하지만 Go는 Java와 달리 클래스가 존재하지 않기 때문에 어떤 식으로 메소드를 사용하는지 의구심이 들었다.

Go에서의 메소드는 구조체 바깥에서 정의되며 리시버를 통해 구조체와 연결된다.

Receiver

메소드는 구조체 바깥에서 선언되기 때문에 메소드가 어떤 구조체에 속하는지 표시할 방법이 필요하다. 이를 위해 리시버를 사용하여 메소드가 속한 구조체를 알려준다.

Method 선언

메소드를 선언하기 위해서는 리시버를 ()로 명시해야 한다.

func (r Rabbit) info() int {
    return r.width * r.height
}

위의 코드에서 (r Rabbit)부분이 리시버다. 리시버를 통해 우리는 info() 메소드가 Rabbit 타입에 속해있다는 것을 알 수 있다. 구조체 변수로 선언된 r은 메소드 내에서 매개변수처럼 이용된다.

모든 로컬 타입은 리시버 타입이 될 수 있으며, 별칭 타입 또한 리시버가 될 수 있다. int 타입 또한 별칭 타입을 만들면 메소드를 가질 수 있다.

package main

import "fmt"

type myInt int

func (a myInt) add(b int) int {
    return int(a) + b
}

func main() {
    var a myInt = 10
    fmt.Println(a.add(30)) // 40
    var b int = 20
    fmt.Println(myInt(b).add(50)) // 70
}

포인터 메소드 vs 값 타입 메소드

package main

import "fmt"

type account struct {
    balance int
    firstName string
    lastName string
}

func (a1 *account) withdrawPointer(amount int) {
    a1.balance -= amount
}

func (a2 account) withdrawValue(amount int) {
    a2.balance -= amount
}

func (a3 account) withdrawReturnValue(amount int) account {
    a3.balance -= amoun
    return a3
}

func main() {
    var mainA *account = &account{ 100, "Joe", "Park" }
    mainA.withdrawPointer(30)
    fmt.Println(mainA.balance) //70

    mainA.withdrawValue(20)
    fmt.Println(mainA.balance) // 70

    var mainB account = mainA.withdrawReturnValue(20)
    fmt.Println(mainB.balance) // 50

    mainB.withdrawPointer(30)
    fmt.Println(mainB.balance) // 20    
}

위의 코드에서 withdrawPointer() 메소드는 리시버로 포인터를 갖기 때문에 *account 타입에 속하고, withdrawValue(), withdrawReturnValue() 메소드는 값 타입을 리시버로 갖기 때문에 account에 속한다.

포인터 메소드를 호출하면 포인터가 가리키고 있는 메모리의 주소값이 복사되지만, 값 타입 메소드를 호출하면 리시버 타입의 모든 값이 복사된다.

withdrawPoint() 메소드가 호출되면 mainA 포인터 변수가 갖는 값인 메모리 주소가 복사되기 때문에 a1과 mainA는 동일한 인스턴스를 가리키게 된다. 그렇기 때문에 a1의 balance를 변경하게 되면 mainA의 balance 또한 변경된다.

반면, withdrawValue() 메소드를 호출할 때는 값이 복사되어 전달되기 때문에 a2와 mainA는 서로 다른 메모리 주소를 갖게 된다.

그렇기 때문에 a2의 balance를 변경해도 mainA의 balance는 변경되지 않는다. 이를 해결하기 위해서 withdrawReturnValue() 메소드처럼 변경된 값을 다시 반환해야 한다.

withdrawReturnValue() 메소드에서는 값 복사가 호출 시와 결과값 반환 시 두 번 이루어진다. 이는 mainA, a3, mainB가 각각 다른 메모리 주소를 갖게 된다는 것을 의미한다.

메소드 호출

mainA는 포인터 변수이고, withdrawValue()는 account 값 타입을 리시버로 받는 메소드다. 포인터인 mainA는 바로 호출할 수 없고 (*main).withdrawValue(20)과 같이 값 타입으로 변환하여 호출하여야 한다.

Go에서는 자동으로 mainA의 값으로 변환하여 호출한다. 반대의 경우에도 동일한데, mainB.withdrawPointer(30)에서 mainB는 account 값 타입 변수이고 withdrawPointer()는 *account 포인터를 리시버로 받는 메소드다.

동일하게 바로 호출이 불가능하기 때문에 주소 연산자를 사용해 (&mainB).withdrawPointer(30)처럼 포인터로 변환 후 호출해야 하지만 Go에서는 자동으로 mainB의 메모리 주소값으로 변환하여 호출한다.

[k8s] Kubernetes Network

겨울바람_ — Fri, 8 Nov 2024 14:20:01 +0900

Overview

Kubernetes 환경에서 이루어지는 네트워킹은 크게 4가지로 분류할 수 있다.

서로 결합된 컨테이너와 컨테이너 간의 통신
Pod와 Pod 간의 통신
Pod와 Service 간의 통신
외부와 Service 간의 통신서로 결합된 컨테이너와 컨테이너 간의 통신Docker 환경에서 생성된 컨테이너의 기본적인 네트워크 동작 구조를 그림으로 표현하면 아래와 같다.

Docker에서는 기본적으로 같은 노드 내의 컨테이너끼리의 통신은 위 그림과 같이 docker0라는 가상 네트워크 인터페이스를 통해 가능하다.

각 컨테이너는 veth라는 가상 네트워크 인터페이스를 고유하게 가지며 따라서 각각의 veth IP 주소 값으로 통신할 수 있다. 하지만 두 컨테이너가 동일한 veth에 할당되는 경우도 존재한다.

위 그림에서는 두 개의 컨테이너가 모두 veth0라는 동일한 네트워크를 사용한다. 외부에서 바라봤을 때 두 개의 컨테이너는 동일한 IP로 인식되기 때문에 동일한 네트워크 상의 컨테이너는 port를 통해 구분된다.

즉, Pod 내에서 컨테이너는 각자 고유한 포트 번호를 사용해야 한다. 이러한 네트워크 인터페이스를 제공해주는 특별한 컨테이너가 있다.

pause라는 명령으로 실행된 컨테이너는 각 Pod마다 존재하며 다른 컨테이너들에게 네트워크 인터페이스를 제공하는 역할만 담당한다.

Pod와 Pod 간의 통신

싱글 노드 Pod 네트워크

Pod의 특징 중 하나로 각 Pod는 veth를 통해 고유한 IP 주소를 가진다. 각 Pod는 kubenet 혹은 CNI로 구성된 네트워크 인터페이스를 통하여 고유한 IP 주소로 서로 통신할 수 있다.

멀티 노드 Pod 네트워크

여러 개의 워커 노드 사이에 각각 다른 노드에 존재하는 Pod가 서로 통신하려면 라우터를 거쳐서 통신하게 된다.Pod는 기본적으로 쉽게 대체될 수 있기 때문에 Pod간 네트워크만으로는 쿠버네티스 시스템을 내구성 있게 구축할 수 없다.

Pod와 Service 간의 통신

이를 해결하기 위해 서비스 앞단에 reverse-proxy혹은 Load Balancer를 위치시키는 방법이 있다.

클라이언트에서 proxy로 연결을 하면 proxy의 역할은 서버들 목록을 관리하며 현재 살아있는 서버에게 트래픽을 전달하는 것이다.

이는 다음의 요구사항을 만족해야 한다.

proxy 서버 스스로 내구성이 있어야 하며 장애에 대응할 수 있어야 함
트래픽을 전달할 서버 리스트를 가지고 있어야 함
서버 리스트 내 서버들이 정상적인지 확인할 수 있는 방법을 알아야 함

쿠버네티스 리소스 중 Service가 이러한 요구사항을 만족한다. Service는 각 Pod로 트래픽을 포워딩해주는 프록시 역할을 한다.

이때, selector라는 것을 이용하여 트래픽을 전달받을 Pod들을 결정한다.

Service 또한 Pod 네트워크와 동일하게 가상 IP 주소지만, Pod 네트워크가 실질적으로 가상 이더넷 네트워크 인터페이스가 설정되어 ifconfig 명령어로 조회되는 것과 다르게 ifconfig 명령어로 조회할 수 없다.

또한 라우팅 테이블에서도 Service 네트워크에 대한 경로를 찾아볼 수 없다. 이는 Service와 Pod 간의 통신이 netfilter와 kube-proxy를 통해 이루어지기 때문이다.

Client Pod에서 Target Pod로 요청을 보내면 Pod의 이더넷 인터페이스가 해당 요청을 전달받은 후, 해당 Target Pod의 IP를 알지 못하기 때문에 다음 게이트웨이로 해당 요청을 전달한다.

veth0는 다음 게이트웨이인 cbr로 요청을 전달하지만, cbr은 bridge이기 때문에 해당 요청을 바로 다음 게이트웨이로 다시 전달한다.

이 전달 과정에서 netfilter가 해당 요청의 목적지 IP를 실제 Target Pod의 IP로 변환하여 다음 게이트웨이로 전달한다. 이후 최종적으로 eth0에 의해 Target Pod로 요청이 라우팅되게 되는 것이다.

쿠버네티스 1.2 버전 이후에서는 해당 패킷의 주소 변환 과정의 비용을 줄이기 위해 kube-proxy의 역할을 netfilter의 규칙을 알맞게 수정하는 것만을 담당하는 것으로 축소시켰다.

위의 그림 또한 쿠버네티스 1.2 버전 이후를 예시로 들어 그려진 것이다.

kube-proxy는 마스터 노드의 API Server에서 정보를 수신하기 때문에 클러스터의 변화를 감지할 수 있고, 이를 통해 지속적으로 iptables를 업데이트하여 netfilter의 규칙을 최신화한다. 하지만 이러한 방식은 클러스터 내부에 위치한 Pod간 통신에서만 동작한다.

외부에서 들어온 요청에 대해서는 다른 처리 방식을 사용해야 한다. 외부의 요청을 처리하는 대표적인 방식이 바로 NodePort, Load Balancer, Ingress다.

NodePort, Load Balancer, Ingress에 대해서는 다음 포스팅에서 자세히 다뤄볼 예정이다.

[Go] 슬라이스

겨울바람_ — Thu, 7 Nov 2024 22:09:40 +0900

Slice란?

슬라이스는 Go 언어에서 제공하는 자료구조 중 하나로, 동적으로 크기를 증가시키는 동적 배열이다. 또한, 슬라이싱 기능을 이용해 배열의 일부를 나타내는 슬라이스를 만들 수 있다.

Slice 선언

`{}`를 이용한 초기화

var slice []int

일반적인 배열과 달리 [] 내부에 배열의 개수를 적지 않고 선언한다. 별도로 슬라이스의 크기를 지정해주지 않으면, 길이가 0인 슬라이스가 생성된다.

var slice []int

if len(slice) == 0 {
    fmt.Println("slice is Empty")
}
// slice is Empty

슬라이스 초기화 시점에 슬라이스 내부에 포함되는 값들을 미리 설정하기 위해서는 배열처럼 {}를 이용하여 요소값을 지정해야 한다.

var slice1 = []int {1, 2, 3} // [1, 2, 3]
var slice2 = []int {1, 5:2, 10:3} // [1, 0, 0, 0, 0, 2, 0, 0, 0, 0, 3]

slice1은 1, 2, 3을 값으로 갖는 슬라이스가 되며, slice2는 인덱스 1은 1, 인덱스 5는 2, 인덱스 10은 3을 각각 값으로 갖고 나머지는 0인 슬라이스로 초기화 된다.

`make()`를 이용한 초기화

내장 함수 make()를 사용하는 방법도 있다.

함수의 첫 번째 인자로 생성하고자 하는 슬라이스의 타입을 입력하고, 두 번째 인자로 해당 슬라이스의 길이를 작성한다.

var slice = make([]int, 3) // [0, 0, 0]

슬라이스에 포함된 값은 int 타입의 기본 값인 0으로 초기화된다.

Slice 요소 추가

➕ append

슬라이스의 요소를 조회하거나 순회하는 방식은 일반 배열과 동일하지만, 값을 추가하는 방식에서 일반적인 배열과 차이점이 존재한다.

일반적인 배열은 초기화 시점에서 길이가 정해지면 길이를 늘릴 수 없지만, 슬라이스는 요소를 추가하는 것으로 길이를 늘릴 수 있다.

요소를 추가하기 위해서는 내장 함수인 append()를 사용하면 된다. 다른 언어에서 사용되는 것과 동일하게 슬라이스의 맨 뒤에 요소를 추가한다.

이때 기존의 슬라이스 값을 변경하는 것이 아닌 인수를 추가한 슬라이스를 반환하기 때문에 append()의 결과를 대입할 값이 필요하다.

var slice = []int {1, 2, 3}

sliceForAppend := append(slice, 4)

fmt.Println(slice) // output > 1, 2, 3
fmt.Println(sliceForAppend) // output > 1, 2, 3, 4

append()를 사용해 slice에 4를 추가해 반환한 값을 sliceForAppend에 대입한다.

append()를 사용하면 여러 개의 값을 한 번에 추가할 수도 있다.

var slice = []int {1, 2, 3}

sliceForAppend := append(slice, 4, 5, 6)

fmt.Println(slice) // output > 1, 2, 3
fmt.Println(sliceForAppend) // output > 1, 2, 3, 4, 5, 6

Slice 동작 원리

슬라이스는 내장 타입으로 내부 구현이 감춰져 있지만, SliceHeader 구조체를 사용해 내부 구현을 살펴볼 수 있다. 슬라이스 내부 정의는 다음과 같다.

type SliceHeader struct {
    Data uintptr // 실제 배열을 가리키는 포인터
    Len int      // 요소 개수 
      Cap int      // 실제 배열의 길이
}

슬라이스 구조체는 배열을 가리키는 포인터와 요소 개수를 나타내는 len, 전체 배열 길이를 나타내는 cap 필드로 구성되어 있다.

슬라이스가 실제 배열을 가리키는 포인터를 가지고 있기 때문에 쉽게 크기가 다른 배열을 가리키도록 변경할 수 있고, 슬라이스 변수 대입 시 배열에 비해서 사용되는 메모리나 속도에 이점이 있다.

var slice := make([]int, 3)
var slice2 := make([]int, 3, 5)

slice는 len이 3이고 cap 또한 3이다. slice2는 len이 3이고 cap은 5다. 그림을 통해 살펴보면 다음과 같다.

Slice와 배열의 동작 차이

슬라이스의 내부 구현이 배열과 다르기 때문에 동작 또한 배열과 다르다. 예제를 통해 차이를 살펴보자.

package main

import "fmt"

func changeArray(array2 [5]int) {
    array2[2] = 200
}

func changeSlice(slice2 []int) {
    slice2[2] = 200
}

func main() {
    array := [5]int{1, 2, 3, 4, 5}
    slice := []int{1, 2, 3, 4, 5}

    changeArray(array)
    changeSlice(slice)

    fmt.Println("array:", array) // array: [1, 2, 3, 4, 5]
    fmt.Println("slice:", slice) // slice: [1, 2, 200, 4, 5]
}

배열의 값은 변경되지 않는 반면, 슬라이스는 값이 변경되는 것을 확인할 수 있다.

Go언어에서 모든 값의 대입은 복사로 일어난다. 함수에 인수로 전달될 때나 다른 변수에 대입할 때나 값의 이동은 복사로 일어난다.

복사는 타입의 값이 복사되는데, 포인터의 경우 포인터의 값인 메모리 주소가 복사되고 구조체가 복사될 때는 구조체의 모든 필드가 복사된다.

changeArray() 함수에 인자로 들어간 array는 int 타입의 요소 다섯 개를 가지고 있다. 즉, array의 크기는 40byte인 것을 알 수 있다. (8 x 5 = 40) changeArray() 함수가 동작했을 때 array의 값이 array2로 복사된다.

array와 array2는 별도의 메모리 공간을 가지는 아예 별개의 배열인 것이다. 그렇기 때문에, array2의 요소값을 변경해도 array의 요소값에는 아무런 영향이 없는 것이다.

`append()`를 사용했을 때 발생할 수 있는 문제 (1)

append() 함수가 호출되면 먼저 슬라이스에 값을 추가할 수 있는 빈 공간이 있는지 확인한다. 남은 빈 공간은 cap에서 len을 뺀 값이다.

남은 빈 공간의 개수가 추가하는 값의 개수보다 크거나 같은 경우 배열 뒷부분에 값을 추가한 뒤 len 값을 증가시킨다.

다음 코드를 수행했을 때 slice1과 slice2에서 발생하는 문제점과 원인에 대해서 알아보자.

package main

import "fmt"

func main() {
    slice1 := make(int[], 3, 5)

    slice2 := append(slice1, 4, 5)
    fmt.Println("slice1:", slice1, len(slice1), cap(slice1)) 
    // slice1: [0, 0, 0], 3, 5 
    fmt.Println("slice2:", slice2, len(slice2), cap(slice2))
    // slice2: [0, 0, 0, 4, 5], 5, 5

    slice1[1] = 100

    fmt.Println("slice1:", slice1, len(slice1), cap(slice1)) 
    // slice1: [0, 100, 0], 3, 5 
    fmt.Println("slice2:", slice2, len(slice2), cap(slice2))
    // slice2: [0, 100, 0, 4, 5], 5, 5

    slice1 := append(slice1, 500)

    fmt.Println("slice1:", slice1, len(slice1), cap(slice1)) 
    // slice1: [0, 100, 0, 500], 4, 5 
    fmt.Println("slice2:", slice2, len(slice2), cap(slice2))
    // slice2: [0, 100, 0, 500, 5], 5, 5
}

출력된 결과를 보면 알 수 있다시피 slice1에 값을 변경, 추가했을 때 slice2에도 해당 변화가 영향을 미치는 것을 확인할 수 있다.

이는 두 슬라이스 모두 동일한 배열의 주소를 포인터로 가지고 있기 때문이다. 즉, 다음의 그림과 같은 상황이 발생한다.

슬라이스가 배열의 주소를 포인터로 가지고 있고, append() 사용 시 해당 주소값을 가지고 있는 포인터가 복사된다는 것을 알고있지 못한다면 이렇듯 예기치 못한 문제에 마주칠 수 있다.

`append()`를 사용했을 때 발생할 수 있는 문제 (2)

append() 함수가 호출되면 빈 공간이 있는지 확인한 후 빈 공간이 충분하지 않다면 통상적으로 기존 배열의 2배 크기의 새로운 배열을 마련한다. 그리고 새로운 배열에 기존 배열의 모든 요소를 복사한 뒤, 맨 뒤에 새 값을 추가한다.

이 과정에서 cap은 새로운 배열의 길이가 되고, len은 기존 길이에 추가한 개수만큼 더한 값이 되며, 포인터는 새로운 배열을 가리키는 슬라이스 구조체를 반환한다.

package main

import "fmt"

func main() {
    slice1 := []int{1, 2, 3}
    slice2 := append(slice1, 4, 5)

    fmt.Println("slice1:", slice1, len(slice1), cap(slice1)) 
    // slice1: [1, 2, 3], 3, 3 
    fmt.Println("slice2:", slice2, len(slice2), cap(slice2))
    // slice2: [1, 2, 3, 4, 5], 5, 6

    slice[1] = 100

    fmt.Println("slice1:", slice1, len(slice1), cap(slice1)) 
    // slice1: [1, 100, 3], 3, 3 
    fmt.Println("slice2:", slice2, len(slice2), cap(slice2))
    // slice2: [1, 2, 3, 4, 5], 5, 6

    slice1 := append(slice1, 500)

    fmt.Println("slice1:", slice1, len(slice1), cap(slice1)) 
    // slice1: [1, 100, 3, 500], 4, 6 
    fmt.Println("slice2:", slice2, len(slice2), cap(slice2))
    // slice2: [1, 2, 3, 4, 5], 5, 6
}

append()함수로 인해 slice1과 slice2가 서로 다른 배열의 주소를 포인터로 가지게 됐기 때문에 slice1의 변화에도 slice2는 영향을 받지 않는다.

Slicing

슬라이싱은 배열의 일부를 집어내는 기능을 의미한다. 슬라이싱을 사용하면 그 결과로 슬라이스를 반환한다.

array[startIndex:endIndex] // 시작 인덱스 ~ 끝 인덱스 - 1

슬라이싱을 통해 반환된 슬라이스는 포인터 값으로 메모리 주소를 갖기 때문에 배열의 중간을 가리킬 수도 있다.

array := [5]int{1, 2, 3, 4, 5}
slice := array[1:2]

fmt.Println("array:", array)
fmt.Println("slice:", slice, len(slice), cap(slice))

array[1] = 100

fmt.Println("array:", array)
fmt.Println("slice:", slice, len(slice), cap(slice))

slice := append(slice, 500)

fmt.Println("array:", array)
fmt.Println("slice:", slice, len(slice), cap(slice))

위의 코드를 그림으로 표현하면 아래의 그림과 같다. 배열을 슬라이싱을 통해 슬라이싱을 통해 가져오면 cap은 배열의 총 길이에서 시작 인덱스를 뺀 4로, len은 슬라이스에 포함된 요소의 수만큼 각각 할당된다.

시작 인덱스와 끝 인덱스 2개만 사용할 때 cap은 배열의 전체 길이에서 시작 인덱스를 뺀 값이 된다. 인덱스를 3개 사용하여 cap까지 조절이 가능하다.

array[startIndex:endIndex:maxIndex]

시작 인덱스부터 끝 인덱스 하나 전까지 추출하고 최대 인덱스까지만 배열을 사용한다는 의미다. 즉, 슬라이스의 cap 값은 최대 인덱스 - 시작인덱스가 된다. 다음 예시를 살펴보자.

slice1 := []int {1, 2, 3, 4, 5}
slice2 := slice1[1:3:4]

인덱스 1부터 2까지 값을 추출한 slice2는 [2, 3]이 되고, cap은 최대 인덱스가 4이므로 1이 된다.

이 경우 slice1[1:3:4]의 의미는 slice1이 가리키는 전체 배열 길이를 전부 사용하는 것이 아니라 인덱스 4까지만 배열을 사용하겠다는 의미가 된다.

즉, 배열의 두 번째부터 네 번째까지만 배열을 사용하게 된다.

Slice 복제

슬라이스가 서로 동일한 배열을 가르키기 때문에 발생하는 문제를 해결하기 위해, 두 슬라이스가 서로 다른 배열을 가르키게 만드는 방법 또한 존재한다.

바로 슬라이스를 복제하는 것이다. slice1이 가리키는 배열과 똑같은 배열을 복제한 뒤 slice2가 가리키게 한다면 서로 다른 배열을 가리키기 때문에 slice1의 변화에도 slice2는 영향을 받지 않을 것이다. 반대 또한 마찬가지다.

반복문을 사용하는 방법과 append() 함수를 사용하는 방법 또한 존재하지만, 내장 함수인 copy()를 활용하는 방법을 알아보자.

func copy(dst, src []Type) int

copy() 함수의 첫 번째 인수로 복사한 결과를 저장하는 슬라이스 변수를 넣고, 두 번째 인수로 복사 대상이 되는 슬라이스 변수를 넣는다. 반환값은 실제로 복사된 요소의 개수다.

Slice 요소 삭제

슬라이스의 중간에 위치한 요소를 삭제하는 방법에 대해서도 알아보자. 아래의 그림처럼 중간의 요소를 삭제하고 다른 요소의 위치를 옮겨야 한다고 가정해보자.

append() 함수를 사용해 위의 그림을 구현해보자.

slice = append(slice[:idx], slice[idx+1:])

굉장히 간단하다. 한 번 각 인덱스가 어떤 역할을 하는지 분석해보자.

slice[:idx]는 슬라이스의 처음부터 끝 요소의 바로 앞에 위치한 요소까지 집어낸 슬라이스다. 지우고자 하는 인덱스의 요소는 포함되지 않는다. 위의 그림에서 지워야 하는 값은 3이기 때문에 slice[:idx는 [1, 2]가 된다.

slice[idx+1:]은 idx의 하나 뒤의 값부터 끝까지 집어낸 슬라이스다. slice[idx+1:]는 [4, 5, 6]이 될 것이다.

마지막으로 append()를 통해 [1, 2]와 [4, 5, 6]을 이어주면 [1, 2, 4, 5, 6]이 된다.

Slice 요소 추가

슬라이스 중간에 요소를 추가하는 방법에 대해서 알아보자. 전개되는 상황은 아래의 그림과 동일하다.

append() 함수를 사용하여 위의 그림을 구현하는 코드는 아래와 같다.

slice = append(slice, 0)
copy(slice[idx+1:], slice[idx:])
slice[idx] = 100

append(slice, 0)으로 슬라이스 맨 뒤에 요소를 추가한다. 내장 함수 copy()를 사용해 슬라이스 값을 복사한다. 이때, 첫 번째 인수는 복사하는 위치, 두 번째 인수는 복사하려는 대상이다.

slice[idx + 1:] 즉 삽입하려는 위치 하나 다음부터 끝까지는 slice[idx:] 위치부터 복사한다. 그렇게되면 한 칸씩 밀려서 복사가 이루어지게 된다. 이후 idx의 위치에 100을 삽입한다.

Slice 정렬

int 타입의 슬라이스를 정렬하는 방법은 매우 간단하다.

s := []int{5, 2, 3, 4, 1}
sort.Ints(s)
fmt.Println(s) // [1, 2, 3, 4, 5]

그렇다면 구조체 타입의 슬라이스를 정렬하려면 어떻게 해야 할까? 구조체 슬라이스를 정렬하기 위해서는 Sort() 함수 사용에 필요한 Len(), Less(), Swap() 세 메소드를 구현해야 한다.

Golang에서의 메소드 구현 방식에 대한 자세한 설명은 다음 포스팅에서 다뤄보기로 하고 우선 코드를 살펴보자.

package main

import (
    "fmt"
    "sort"
)

type Student struct {
    Name string
    Age int
}

type Students []Student 

func (s Students) Len() int { return len(s) }
func (s Students) Less(i, j int) bool { return s[i].Age < s[j].Age }
func (s Students) Swap(i, j int) { s[i], s[j] = s[j], s[i] }

func main {
    s := []Student {
        {"화랑", 31}, {"백두산", 52}, {"류", 42},
        {"켄", 37}, {"송하나", 17}
    }

    sort.Sort(Students(s))
    fmt.Println(s)
}

// [{"송하나", 17}, {"화랑", 31}, {"켄", 37}, {"류", 42}, {"백두산", 52}]

[]Student의 별칭 타입인 Students를 만들고 Len(), Less(), Swap() 메소드를 구현하는 것으로 sort.Interface를 사용할 수 있게 되었다.

Less() 메소드를 통해 Student 구조체의 Age 필드를 통해 값을 비교하도록 선언했다.

[Traefik] K8s Traefik 설치, External-IP 설정 및 HTTPS 적용 방법

겨울바람_ — Sun, 22 Sep 2024 14:48:47 +0900

사용하던 서버의 리소스들을 Docker-Compose에서 Kubernetes를 사용하는 방식으로 마이그레이션을 진행하는 과정에서 Reverse Proxy 겸, LoadBalancer로 사용했던 Traefik 또한 Kubernetes Cluster로 옮겨야 했다.

마이그레이션을 진행하는 것을 계기로 겸사겸사 Kubernetes의 Ingress Controller로 사용되는 Traefik에 외부 접속이 가능하도록 External-IP를 할당해주는 방법과 Letsencrypt의 acme를 사용하여 HTTPS 인증서 사용이 가능하도록 하는 방법에 대한 포스팅을 적어보려고 한다.

Traefik에 대한 대략적인 내용은 아래의 포스팅을 참조하자

Traefik 이란?

사전 준비 사항

1. 외부 접속이 가능한 공인 DNS 필요

2. Kubernetes Cluster가 구성되어 있는 환경 필요 (필자는 On-Premise 환경에서 진행했다.)

3. On-Premise 환경에 구축된 Kubernetes Cluster에 외부 접속을 하기 위한 LoadBalancer가 필요

4. 인증서 저장을 위한 PVC 필요

Metallb LoadBalancer IPAddressPool

Metallb LoadBalancer를 사용하게 되면, Metallb가 할당할 수 있는 IP 대역폭을 지정해주어야 하는데 이때 대역폭을 외부 접근이 가능한 IP 주소가 포함되도록 설정해야 한다. 예를 들어 외부 접근이 가능한 IP 주소가 123.123.123.123이라면 Address Pool은 123.123.123.123 - 123.123.123.133 과 같이 설정되어야 한다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: address-pool
  namespace: metallb
spec:
  addresses:
  - 123.123.123.123 - 123.123.123.133

IPAddressPool을 할당하기 이전에 아래의 명령어로 이미 사용되고 있는 IP 주소인지 아닌지 확인하는 것을 권장한다.

for i in {1..9}; do ping -c 1 123.123.123.12$i; done

위의 IP는 어디까지나 예시이기 때문에 본인 환경의 IP 주소 상황을 고려하여 각자 다르게 적용하도록 하자. 참고로 IP 주소는 ifconfig 명령어를 통해 확인할 수 있다.

Helm을 통해 Traefik 설치

Helm을 통해 바로 Traefik을 설치하지 않고 환경에 맞게 커스터 마이징 하기 위해 pull 명령어를 통해 Traefik의 리소스 파일들을 내려받는다.

helm repo add traefik https://helm.traefik.io/traefik
helm repo update
helm pull traefik/traefik

tar xvfz traefik-28.3.0.tgz
rm -rf traefik-28.3.0.tgz
mv traefik traefik-28.3.0
cd traefik-28.3.0/

cp values.yaml my-values.yaml

기존의 설정 파일을 my-values.yaml로 복사하여 새로운 Helm value 파일을 생성한다. 복사한 my-values.yaml 파일을 환경에 맞도록 다음과 같이 수정한다.

ports:
  traefik:
    port: 9000
    expose:
      default: true
    exposedPort: 9000
    protocol: TCP

...

affinity:
 podAntiAffinity:
   requiredDuringSchedulingIgnoredDuringExecution:
     - labelSelector:
         matchExpressions:
         - key: app
           operator: In
           values:
           - traefik
       topologyKey: kubernetes.io/hostname

Traefik Dashboard 접근을 위해 traefik EntryPoint에 외부 접속이 허용되도록 만들고, 동일한 Node에 Traefik Pod가 추가 실행되지 않도록 Affinity 설정을 한다.

my-values.yaml 파일은 추후 HTTPS 인증서 적용을 위해 다시 살펴봐야 하기 때문에 어느 정도 눈에 익혀두는 편이 좋다. 여기까지 진행이 완료됐다면 Traefik 전용 네임스페이스를 생성하자.

kubectl create ns traefik
kubectl ns traefik

네임스페이스가 제대로 변경됐는지 확인하고 Helm을 통해 변경된 변수 파일을 적용하여 Traefik을 설치하자.

helm install traefik -f my-values.yaml .

큰 문제가 없다면 정상적으로 설치가 진행되고 Pod와 SVC 같은 리소스가 정상적으로 동작하는 것을 확인할 수 있을 것이다. SVC를 조회하여 External-IP가 Metallb에서 지정한 AddressPool에 맞게 설정되었는지 확인하자.

확인을 위해 브라우저에 http://{External-IP}:9000/dashboard/# 을 입력하여 Traefik Dashboard에 정상적으로 접근이 가능한지 확인해보자. 정상적으로 리소스가 실행되고 있다면 아래의 사진과 같은 Traefik Dashboard에 접근할 수 있다.

여기까지 됐다면, Traefik 설치는 정상적으로 완료된 것이다.

IngressRoute 설정

Traefik은 EntryPoint로 들어온 요청을 Router로 분기하여 각 SVC에 전달한다. 요청을 분기하기 위한 IngressRouter를 작성해보자.

우선 요청이 들어오는 것을 확인할 수 있도록 Pod를 생성해보자.

# coffee-svc-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coffee
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: coffee
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: nginxdemos/nginx-hello:plain-text
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
  namespace: default
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: coffee

coffee라는 이름의 nginx-hello 이미지를 사용한 컨테이너를 배포하는 yaml 파일이다. nginx-hello 는 서버의 IP 주소와 이름 등을 화면에 출력하는 간단한 서비스다.

kubectl apply -f coffee-svc-deploy.yaml

위의 명령어를 통해 실행시키면 Pod 2개와 SVC, Delpoyment가 동작하는 것을 확인할 수 있다. 이제 coffee의 SVC와 Traefik의 EntryPoint를 연결시켜야 한다. SVC와 Traefik EntryPoint의 연결을 담당하는 것이 위에서 설명했던 IngressRoute다.

IngressRoute에 분기 조건을 적용하면 해당 조건에 맞게 Traefik이 트래픽을 라우팅하여 알맞은 SVC로 전달한다. Traefik은 사용자가 편리하게 해당 기능을 구현할 수 있도록 자체적으로 IngressRoute라는 CRD를 제공한다.

# coffee-crd-ingressroute.yaml

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: coffee-ingressroutetls
  namespace: default
spec:
  entryPoints:
  - web
  routes:
  - match: Host(`your.domain.example`)
    kind: Rule
    services:
    - name: coffee-svc
      port: 80

web EntryPoint에 전달되는 트래픽 중 your.domain.example 이라는 호스트를 가진 트래픽만 coffee-svc에 전달한다는 내용이다. web의 경우 my-values.yaml을 살펴보면 기본적으로 지정되어 있는 EntryPoint 중 하나이다. 이외에도 websecure, traefik 등이 있다.

kubectl apply -f coffee-crd-ingressroute.yaml

위의 명령어로 IngressRoute 리소스를 생성하자. 공인 도메인을 사용 중이라면 match.Host에 설정한 도메인으로 접속할 수 있다. 아직 HTTPS 적용이 되지 않아 안전한지 않은 사이트라고 표시되겠지만 접속은 가능하다.

만약 공인 도메인이 없다면, /etc/hosts 파일에 Traefik SVC의 External-IP와 match.Host에 설정한 도메인을 입력해두면 브라우저를 통해 접속이 가능하지만 외부 네트워크에서의 접속은 불가능하다.

Let'sEncrypt ACME를 통해 HTTPS 인증서 등록하기

우리가 만든 사이트를 안전하게 만들기 위해 Let'sEncrypt를 통해 인증서를 발급받아 Traefik에 적용시켜보자. Traefik 인그레스를 사용할 경우 사용자는 인증서를 다수의 웹서버에 등록할 필요 없이 단일 Traefik 설정 파일을 통해 관리할 수 있다.

우선 Let'sEncrypt 는 CA로 ACME 프로토콜을 사용하여 x509 인증서를 자동으로 발급받는 것이 가능하도록 해준다. 즉, Let'sEncrypt 는 유효한 인증서를 무료로 사용자에게 제공해주며 ACME 프로토콜을 통해 자동으로 인증서를 발급받도록 한다. 라는 것이 요점이다.

Traefik은 Let'sEncrypt를 공식적으로 지원하기 때문에 굉장히 간편하게 사용이 가능하다. 우선 인증서를 저장하기 위해 PVC를 생성하도록 하자. 필자는 OpenEBS를 사용했다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: traefik-acme-pvc
  namespace: traefik
spec:
  accessModes:
  - ReadWriteOnce  
  resources:
    requests:
      storage: 1Gi
  storageClassName: "openebs-hostpath"

Storage 할당을 꽤 과하게 한 것 같지만 우선 무시하고 진행하도록 하자.

k apply -f traefik-acme-pvc.yaml

PVC가 정상적으로 생성됐다면, 이전에 커스터 마이징 했던 my-values.yaml 파일을 살펴보도록 하자. 볼륨 마운트를 위해 persistence 부분을 찾아 아래와 같이 수정해보자.

persistence:
  # -- Enable persistence using Persistent Volume Claims
  # ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
  # It can be used to store TLS certificates, see `storage` in certResolvers
  enabled: true
  name: data
  #  existingClaim: ""
  accessMode: ReadWriteOnce
  size: 1Gi
  storageClass: openebs-hostpath
  # volumeName: ""
  path: /data/letsencrypt
  annotations: {}
  existingClaim: traefik-acme-pvc
  # -- Only mount a subpath of the Volume into the pod
  # subPath: ""

그리고 인증서 적용을 위해 certResolvers, additionalArguments 부분을 수정해줘야 한다.

# Ref: https://doc.traefik.io/traefik/https/acme/#certificate-resolvers
# See EXAMPLES.md for more details.
certResolvers:
  myresolver:
  acme:
    email: your@email.com
    storage: /data/letsencrypt/acme.json 
    httpChallenge:
      entryPoint: web

...

additionalArguments:
  - "--certificatesresolvers.myresolver.acme.email=your@email.com"
  - "--certificatesresolvers.myresolver.acme.storage=/data/letsencrypt/acme.json"
  - "--certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web"

위처럼 수정이 완료된 my-values.yaml 파일을 저장하고 해당 내용을 다시 적용시키자. 특별한 사유가 없다면 안전하게 기존의 리소스들을 삭제하고 다시 설치하는 것을 추천한다.

helm uninstall traefik
helm install traefik -f my-values.yaml .

Traefik 리소스들이 재시작 되었다면, 이전 작성해두었던 IngressRoute 파일을 수정해줘야 한다.

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: coffee-ingressroutetls
  namespace: default
spec:
  entryPoints:
  - websecure
  routes:
  - match: Host(`your.domain.com`)
    kind: Rule
    services:
    - name: coffee-svc
      port: 80
  tls:
    certResolver: myresolver

web EntryPoint를 websecure로 변경하고 tls.certResolver를 추가했다. 이제 변경사항이 적용되도록 IngressRoute도 다시 실행시키자.

kubectl apply -f coffee-crd-ingressroute.yaml

여기까지 됐다면 이전처럼 안전하지 않은 사이트라는 경고 없이 HTTPS로 접속이 가능해진다.

jdeps와 jlink를 활용한 Java 기반 컨테이너 경량화

겨울바람_ — Thu, 12 Sep 2024 14:02:28 +0900

Overview

컨테이너로 배포되는 애플리케이션은 컨테이너 이미지의 크기가 작을수록 빠르게 실행하고 확장할 수 있으며 이미지 보관 및 전송에 드는 비용이 절감된다.

Java 기반의 애플리케이션은 JVM이 함께 배포되어야 하기 때문에 Go 언어와 같은 바이너리 형태로 배포되는 애플리케이션에 비해 컨테이너 이미지의 크기가 비대하다.

이번 글에서는 jdeps와 jlink가 각각 어떤 명령어인지 알아보고 해당 명령어를 통해 Java 기반의 애플리케이션 컨테이너를 경량화 하는 방법에 대해 알아보고자 한다.

본 포스팅은 AWS 기술 블로그와 일본 개발자분의 포스팅을 토대로 작성되었다.

https://qiita.com/yTakada-gxp/items/f681d28f31e999e5dfae
https://aws.amazon.com/ko/blogs/tech/amazon-corretto-base-container-diet/

jdeps

https://docs.oracle.com/en/java/javase/11/tools/jdeps.html#GUID-A543FEBE-908A-49BF-996C-39499367ADB4
jdeps 명령어는 .class 파일의 패키지 혹은 클래스 레벨의 의존성을 보여준다. 모듈화가 적용된 jdk9 버전 이후에만 동작하기 때문에 버전 지정시 주의해야 한다. jdeps에는 여러가지 옵션이 존재하지만, 이번 글에서 주요하게 사용하게 되는 옵션은 다음과 같다.

--ignore-missing-deps : 결락되어 있는 의존성을 무시한다. 즉, 의존성을 알 수 없는 모듈은 제외
--print-module-deps : 모듈 의존성을 콤마로 구분된 리스트 형태로 출력한다.
--class-path <path> : 클래스 파일의 위치를 지정한다.

위에 설명한 옵션들을 사용해서 의존성이 존재하는 모듈을 추출하는 코드는 다음과 같다.

$ jdeps \
    --ignore-missing-deps \
    --print-module-deps \
    -q \
    -R \ ##모든 런타임의 종속성을 재귀적으로 탐색한다
    --multi-release 17 \ ##의존성을 분석할 버전을 지정한다. 
    --class-path="./<app_name>/BOOT-INF/lib/*" \
    --module-path="./<app_name>/BOOT-INF/lib/*" \
    build/libs/<jar_file_name>.jar

SpringBoot를 사용하는 경우 jar파일 내부에 /BOOT-INF/lib/라는 디렉토리에 의존 라이브러리를 보유하고, 실행될 때 읽어오는 구조를 가지고 있다. 해당 jar을 jdeps의 클래스패스에 지정할 필요가 있다.

jlink

https://docs.oracle.com/en/java/javase/11/tools/jlink.html
jlink 명령어를 통해 모듈과 모듈의 의존성을 커스텀 런타임 이미지에 결집하고 최적화 할 수 있다. jlink의 여러 옵션들 중 이번 글에서 주요 사용되는 옵션은 다음과 같다.

--add-modules [...] : 모듈과 모드를 기본 루트 모듈에 추가한다. 기본 루트 모듈은 비어있다.
--strip-debug : 출력에서 디버그 정보를 제거한다.
--no-man-page : man pages를 제거한다.
--no-header-files : header files를 제거한다.
--compress=2 : 리소스의 압축을 가능하게 한다.
0 : 압축 불가
1 : 상수 문자열 공유
2 : ZIP
--output path : 런타임 이미지를 생성할 위치를 지정한다.

$ jlink \ --verbose \. ##상세한 추적을 활성화 하여 로깅합니다.
    --add-modules [] \ ## jdeps 명령어를 통해 확인한 의존성을 입력한다.
    --strip-debug \
    --no-man-pages \  
    --no-header-files \ 
    --compress=2 \ 
    --output <path>

jdeps와 jlink를 활용하여 만들어진 jre 파일은 해당 자바 애플리케이션을 실행하기 위한 최소 모듈만을 포함하고 있으며 최소한의 CLI만 포함된 상태로 생성된다.

Write Dockerfile

위에서 작성한 jdeps와 jlink 명령어를 도커파일에 적용시켜 경량화된 컨테이너 이미지를 생성해보는 실습을 진행해보자.

해당 Dockerfile은 애플리케이션이 이미 jar파일로 빌드된 상태임을 가정하고 작성되었다. 또한, 클라우드 플랫폼 중립적으로 작성하기 위해 amazon-correctto가 아닌 eclipse-temurin을 기반으로 작성했다.

# Stage 1
FROM eclipse-temurin:<version>-alpine as deps

COPY ./<jar_file_name>.jar /app/<jar_file_name>.jar

RUN mkdir /app/unpacked && \
    cd /app/unpacked && \
    unzip ../<jar_file_name>.jar && \
    cd .. && \
    $JAVA_HOME/bin/jdeps \
    --ignore-missing-deps \ 
    --print-module-deps \ 
    -q \ 
    --recursive \ 
    --multi-release <version> \ 
    --class-path="./unpacked/BOOT-INF/lib/*" \ 
    --module-path="./unpacked/BOOT-INF/lib/*" \ 
    ./<jar_file_name>.jar > /deps.info

# Stage 2
FROM eclipse-temurin:<version>-alpine as temurin-jdk

RUN apk add --no-cache binutils

COPY --from=deps /apo/deps.info /deps.info

RUN $JAVA_HOME/bin/jlink \
        --verbose \
        --add-modules $(cat /deps.info) \ 
        --strip-debug \ 
        --no-man-pages \ 
        --no-header-files \ 
        --compress=2 \ 
        --output /<custom_jre_name>

# Stage 3
FROM alpine:<version>
ENV JAVA_HOME=/jre
ENV PATH="${JAVA_HOME}/bin:${PATH}"

COPY --from=temurin-jdk /<custom_jre_name> $JAVA_HOME

ARG APPLICATION_USER=appuser
RUN adduser --no-create-home -u 1000 -D $APPLICATION_USER

RUN mkdir /app && \
    chown -R $APPLICATION_USER /app

USER 1000

COPY --chown=1000:1000 ./<jar_file_name>.jar /app/<jar_file_name>.jar
WORKDIR /app

EXPOSE 8080
ENTRYPOINT [ "/jre/bin/java", "-jar", "/app/<jar_file_name>.jar" ]

Stage 1은 temurin:<version>-alpine 이미지를 베이스 이미지로 사용하여 jdeps를 이용한 의존성 분석 및 분석 결과를 deps.info라는 이름으로 생성한다.

Stage 2는 Stage 1과 동일한 이미지와 생성된 의존성 목록을 바탕으로 jlink를 사용해 경량화된 커스텀 jre를 생성한다.

Stage 3는 alpine:<version>을 베이스로 Stage 2에서 생성된 커스텀 jre를 사용하여 최종 이미지를 생성한다. 이 과정에서 보안을 위해 별도의 유저를 생성하여 권한을 부여하고 jar 파일을 실행한다.

여기까지 작성한 Dockerfile을 docker build -t <image_name>:<version> . 명령을 통해 이미지로 빌드시킨다. Dockerfile 설정을 잘못 적지 않았다면 성공적으로 확연하게 줄어든 43MB 용량의 이미지가 생성된 것을 확인할 수 있다.

비교를 위해 alpine jdk만을 써서 빌드한 이미지의 용량과 비교해보자. 아래는 비교를 위해 작성한 간단한 Dockerfile이다.

FROM eclipse-temurin:17-alpine

CMD ["./gradlew", "clean", "build"]

VOLUME /tmp

ARG JAR_FILE=./app.jar

COPY ${JAR_FILE} app.jar

EXPOSE 8080

ENTRYPOINT ["java","-jar","/app.jar"]

jdeps와 jlink를 사용하지 않았기 때문에 의존성이 최적화되지 않아 불필요한 의존성까지 모두 포함된 이미지가 생성된다.

리사이징된 이미지와 비교했을 때 이미지의 용량이 약 80~90% 감소됐다.

실행 또한 성공적으로 되는 것을 확인할 수 있다.

[Terraform] 테라폼 기초 (3)

겨울바람_ — Wed, 28 Aug 2024 22:31:30 +0900

Provider

테라폼은 terraform 바이너리 파일을 시작으로 로컬 환경이나 배포 서버와 같은 원격 환경에서 원하는 대상을 호출하는 방식으로 실행된다.

이때 호출되는 대상은 프로바이더가 제공하는 API를 호출해 상호작용 하게 된다. 즉, 테라폼이 대상과의 상호작용을 할 수 있도록 하는 것을 프로바이더라 한다.

각 프로바이더의 API 구현은 서로 다르지만, 테라폼의 고유 문법으로 동일한 동작을 수행하도록 구현되어 있다. 프로바이더는 플러그인 형태로 테라폼에 결합되어 대상이 되는 클라우드, SaaS, 기타 서비스 API를 사용해 동작을 수행한다.

각 프로바이더는 테라폼이 관리하는 리소스 유형과 데이터 소스를 사용할 수 있도록 연결한다. 그렇기 때문에 테라폼은 프로바이더 없이는 어떤 종류의 인프라와 서비스도 관리할 수 없다는 의미다.

대부분의 프로바이더는 대상 인프라 환경이나 서비스 환경에 대해 리소스를 관리하므로, 프로바이더를 구성할 때는 대상과의 연결과 인증에 대한 정보가 제공되어야 한다.

Provider Config

프로바이더 구성에 대한 요구사항은 공식 레지스트리 사이트인 테레폼 레지스트리에 공개되어 있는 구성 방식을 참고하는 것이 좋다.

https://registry.terraform.io/

Required_Providers

terraform 블록의 required_provieders 블록 내에 <로컬 이름> = { }으로 여러 개의 프로바이더를 정의할 수 있다.

로컬 이름은 테라폼 모듈 내에서 고유해야 한다. 로컬 이름과 리소스 접두사는 각각 독립적으로 선언되며, 각 프로바이더의 소스 경로가 지정되면 프로바이더의 고유 접두사가 제공된다.

만약 동일한 접두사를 사용하는 프로바이더가 선언되는 경우 로컬 이름을 달리해 관련 리소스에서 어떤 프로바이더를 사용하는지 명시적으로 지정할 수 있다.

예를 들어, 아래의 main.tf에서처럼 동일한 http 이름을 사용하는 다수의 프로바이더가 있는 경우 각 프로바이더에 고유한 이름을 부여하고 리소스와 데이터 소스에 어떤 프로바이더를 사용할지 provider 인수에 명시한다.

단, 동일한 source에 대해 다수의 정의는 불가능하다.

terraform {
    required_providers {
        architect-http = {
            source = "architect-team/http"
            version = "~> 3.0"
        }
        http = {
            source = "hashicorp/http"
        }
        aws-http = {
            source = "terraform-aws-modules/http"
        }
    }
}

data "http" "example" {
    provider = aws-http
    url = "https://checkpoint-api.hashicorp.com/v1/check/terraform"
    request_headers = {
        Accept = "application/json"
    }
}

위의 코드에서 required_providers 블록 내부의 요소들을 하나씩 살펴보자. architect-http, http, aws-http는 모두 프로바이더의 로컬 이름을 의미한다.

source의 경우 프로바이더 다운로드 경로를 지정하고, version은 버전 제약을 명시한다. version을 생략하는 경우 가장 최신 버전으로 선택된다.

아래의 예제 코드를 참고하자.

terraform {
    required_providers {
        <프로바이더 로컬 이름> = {
            source = [<호스트 주소>/]<네임스페이스>/<유형>
            version = <버전 제약>
        }
    }
}

source를 좀 더 분석해보면, 호스트 주소는 프로바이더를 배포하는 주소로 기본값은 테라폼의 레지스트리인 registry.terraform.io다.

네임스페이스는 지정된 레지스트리 내에서 구분하는 네임스페이스로, 공개된 레지스트리 및 Terraform Cloud의 비공개 레지스트리의 프로바이더를 게시하는 조직을 의미한다.

유형은 프로바이더에서 관리되는 플랫폼이나 서비스 이름으로 일반적으로 접두사와 일치하지만 일부 예외가 존재한다.

Multiple Provider

동일한 프로바이더를 사용하지만 다른 조건을 갖는 경우, 사용되는 리소스마다 별도로 선언된 프로바이더를 지정해야 하는 경우가 있다.

예를 들어, AWS 프로바이더를 사용하는데 서로 다른 권한의 IAM을 갖는 Access ID 또는 리전을 지정해야 하는 경우다. 이때는 프로바이더 선언에서 alias를 명시하고 사용하는 리소스와 데이터 소스에서는 provider 메타인수를 사용해 특정 프로바이더를 지정할 수 있다.

provider 메타인수에 지정되지 않은 경우 alias가 없는 프로바이더가 기본 프로바이더로 동작한다. 아래의 예제를 통해 살펴보자.

provider "aws" {
    region = "us-west-1"
}

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

resource "aws_instance" "app_server" {
    provider = aws.seoul
    ami = "ami-..."
    instance_type = "t2.micro"
}

AWS Provider

AWS 리소스를 관리하는 AWS 프로바이더를 통해 리소스를 프로비저닝하기 위해서는, 가입된 계정의 액세스 키와 비밀 액세스 키가 필요하다.

발급받은 자격증명을 AWS 프로바이더에서 사용하기 위해서는 환경 변수, 파일, 테라폼 구성에 추가하는 각각의 방식을 사용해야 한다. 이번에는 테라폼 구성에 추가하는 방식을 통해 확인해보자.

terraform {
    required_providers {
        aws = {
            source = "hashicorp/aws"
            version = "~> 4.0"
        }
    }

    required_version = ">= 1.0"
}

provider "aws" {
    region = "ap-northeast-2"
    access_key = "<my_access_key>"
    secret_key = "<my_secret_key>"
}

data "aws_ami" "amzn2" {
    most_recent = true
    owners = ["amazon"]

    filter {
        name = "owner-alias"
        values = ["amazon"]
    }

    filter {
        name = "name"
        values = ["amzn2-ami-hvm*"]
    }
}

resource "aws_instance" "app_server" {
    ami = data.aws_ami.amzn2.id
    instance_type = "t2.micro"

    tags = {
        Name = "ExampleAppServerInstance"
    }
}

위의 코드의 내용 중 몇 가지를 간단하게 분석해보자. required_version은 해당 코드를 실행하기 위한 테라폼의 버전을 의미하며 해당 코드에서는 1.0버전 이상의 테라폼만이 코드를 동작시킬 수 있다.

data.aws_ami.amzn2는 AWS의 AMI를 조회하기 위한 데이터 블럭이며, most_recent = true는 가장 최신 버전의 AMI를 가져오도록 하며 owners는 AMI의 소유자를 설정하는데 해당 코드에서는 AWS 소유의 AMI만을 필터링한다.

첫 번째 filter는 owner-alias가 amazon인 AMI를 찾는다는 의미이고, 두 번째는 amzn2-ami-hvm*로 시작하는 AMI를 찾는다는 의미다.

resource 블럭은 AWS 인스턴스를 생성하기 위한 블럭이다. ami에서는 위의 data 블럭에서 조회한 AMI의 ID를 사용하여 인스턴스를 생성한다. 이때 생성된 인스턴스에 ExampleAppServerInstance라는 태그를 붙인다.

환경변수를 통해 엑세스 키와 시크릿 키를 추가하는 방법도 있다.

# Linux / Unix
export AWS_ACCESS_KEY_ID = <my_access_key>
export AWS_SECRET_ACCESS_KEY = <my_secret_key>

# Windows
set AWS_ACCESS_KEY_ID = <my_access_key>
set AWS_SECRET_ACCESS_KEY = <my_secret_key>

# Windows Powershell
$Env:AWS_ACCESS_KEY_ID = <my_access_key>
$Env:AWS_SECRET_ACCESS_KEY = <my_secret_key>

위처럼 OS에 환경변수로 자격증명을 등록하고 기존에 작성했던 코드에서 provider.access_key, provider.secret_key를 제외하면 된다.

State

테라폼은 Stateful한 애플리케이션이다. 프로비저닝 결과에 따른 State를 저장하고 프로비저닝한 모든 내용을 저장된 상태로 추적한다. 로컬 실행 환경에서는 terraform.tfstate 파일에 JSON 형태로 저장되고, 팀이나 조직에서의 공동 관리를 위해서는 원격 저장소에 저장해 공유하는 방식을 활용한다.

State에는 작업자가 정의한 코드와 실제 반영된 프로비저닝 결과를 저장하고, 이 정보를 토대로 이후의 리소스 생성, 수정, 삭제에 대한 동작 판단 작업을 수행한다.

Why State?

테라폼은 State를 사용해 대상 환경에서 어떤 리소스가 테라폼으로 관리되는 리소스인지 판별하고 결과를 기록한다.

State의 역할은 다음과 같다.

테라폼 구성과 실제를 동기화하고 각 리소스에 고유한 아이디로 매핑한다.
리소스 종속성과 같은 메타데이터를 저장하고 추적한다.
테라폼 구성으로 프로비저닝된 결과를 캐싱하는 역할을 수행한다.

terraform plan을 실행하면 암묵적으로 refresh 동작을 수행하면서 리소스 생성의 대상과 State를 기준으로 비교하는 과정을 거친다.

이 작업은 프로비저닝 대상의 응답 속도와 기존 작성된 State의 리소스 양에 따라 속도 차이가 발생한다.

대량의 리소스를 관리해야 하는 경우 terraform plan -refresh=false를 통해 대상 환경과의 동기화 과정을 생략할 수 있다.

State Synchronization

테라폼 구성 파일은 기존 State와 구성을 비교해 실행 계획에서 생성, 수정, 삭제 여부를 결정한다.

Workspace

State를 관리하는 논리적인 가상 공간을 워크스페이스라고 한다. 테라폼 구성 파일은 동일하지만 작업자는 서로 다른 State를 갖는 실제 대상을 프로비저닝할 수 있다.

워크스페이스는 기본 default로 정의된다. 로컬 작업 환경의 워크스페이스를 관리하기 위한 CLI 명령어로 workspace가 있다.

terraform workspace list 명령어를 통해 존재하는 워크스페이스의 목록을 확인할 수 있으며, 현재 사용하고 있는 워크스페이스 이름 옆에는 *기호가 표시되어 있다.

terraform workspace new <워크스페이스 이름> 명령어를 통해 default가 아닌 새로운 워크스페이스를 생성하고 terraform plan을 실행하면, 기존 default 워크스페이스와는 다른 State를 가지고 있기 때문에 앞서 정의한 테라폼 구성의 리소스를 다시 생성한다는 메시지가 출력된다.

워크스페이스를 구분하면 동일한 구성에서 기존 인프라에 영향을 주지 않으며 간편하게 테라폼 프로비저닝을 테스트하고 확인할 수 있다. 또한 테라폼 코드 상에서 terraform.workspace를 사용해 워크스페이스 이름을 조회하여 조건을 부여하는 것도 가능하다.

resource "aws_instance" "web" {
    count = "${terraform.workspace == "default" ? 5 : 1}"
    ami = "ami-..."
    instance_type = "t2.micro"

    tags = {
        Name = "Hello World - ${terraform.workspace}"
    }
}

다수의 워크스페이스를 사용하면 다음과 같은 장점이 있다.

하나의 루트 모듈에서 다른 환경을 위한 리소스를 동일한 테라폼 구성으로 프로비저닝하고 관리할 수 있다.
기존 프로비저닝된 환경에 영향을 주지 않고 변경 사항 실험이 가능하다.
깃의 브랜치 전략처럼 동일한 구성에서 서로 다른 리소스 결과를 관리할 수 있다.

단점은 다음과 같다.

State가 동일한 저장소(로컬 또는 백엔드)에 저장되어 State 접근 권한 관리가 불가능하다.
모든 환경이 동일한 리소스를 요구하지 않을 수 있으므로 테라폼 구성에 분기 처리가 다수 발생할 수 있다.
프로비저닝 대상에 대한 인증 요소를 완벽히 분리하기가 어렵다.

워크스페이스 사용의 근본적인 단점은 완벽한 격리가 불가능하다는 것이다. 이를 해결하기 위해 루트 모듈을 별도로 구성하는 디렉토리 기반의 레이아웃을 사용할 수도 있다.

[Terraform] 테라폼 기초 (2)

겨울바람_ — Mon, 19 Aug 2024 22:26:42 +0900

Terraform 조건식

테라폼에서의 조건식은 삼항 연산자 형태를 갖는다.

<조건 정의> ? <true> : <false>

조건식의 각 조건은 비교 대상의 형태가 다르면 테라폼 실행 시 조건 비교를 위해 형태를 추론하여 자동으로 변환되는데, 혼란이 발생할 수 있기 때문에 명시적인 형태로 작성하는 편이 좋다.

var.example ? tostring(12) : "hello" # 권장
var.example ? "12" : "hello" # 권장

count와 조건식을 결합하여 사용하는 경우 특정 조건에 따라 리소스 생성 여부를 선택하는 방식으로 작성할 수 있다.

variable "enable_file" {
    default = true
}

resource "local_file" "foo" {
    count = var.enable_file ? 1 : 0
    content = "foo!"
    filename = "${path.module}/foo.bar"
}

output "content" {
    value = var.enable_file ? local_file.foo[0].content : ""
}

Terraform 함수

테라폼은 여러 내장 함수를 포함하고 있지만, 사용자가 구현하는 별도의 사용자 정의 함수를 지원하지 않는다. 함수 종류에는 숫자, 문자열, 컬렉션, 인코딩, 파일 시스템, 날짜/시간, 해시/암호화, IP 네트워크, 형변환 등이 있다.

함수 사용 방법을 익히고 결과를 확인하기 위해 매번 terraform plan, apply를 반복해서 사용하는 것은 비효율적이다.

단순히 함수 사용 결과를 확인하는 목적으로는 terraform console을 통해 함수와 값을 입력하여 곧장 확인하는 것이 더욱 효과적이다.

exit를 입력하여 console에서 빠져나올 수 있다.

Terraform Provisioner

프로비저너는 프로바이더로 실행되지 않는 커맨드와 파일 복사 같은 역할을 수행한다. 프로비저너로 실행된 결과는 테라폼의 상태 파일과 동기화 되지 않으므로 프로비저닝에 대한 결과가 항상 같다고 보장할 수 없다. 따라서 프로비저너 사용을 최소화 하는 것이 좋다.

프로비저너의 경우 리소스 프로비저닝 이후 동작하도록 구성할 수 있다. 예를 들어 AWS의 EC2 인스턴스를 생성하고 난 후 CLI를 통해 별도 작업을 수행하는 상황을 가정해보자.

variable "sensitive_content" {
    default = "secret"
    sensitive = true
}

resource "local_file" "foo" {
    content = upper(var.sensitive_content)
    filename = "${path.module}/foo.bar"

    provisioner "local-exec" {
        command = "echo The content is ${self.content}"
    }

    provisioner "local-exec" {
        command = "abc"
        on_failure = continue
    }

    provisioner "local-exec" {
        when = destroy
        command = "echo The deleting filename is ${self.filename}"
    }
}

프로비저너는 선언된 리소스 블록의 작업이 종료되고 나서 지정한 동작을 수행한다. 작성된 예제와 같이 다수의 프로비저너를 반복적으로 선언할 수 있다.

terraform apply 명령어를 통해 main.tf 파일의 결과를 확인해보면 다음과 같다.

provisioner "local-exec" {
    command = "echo The content is ${self.content}"
}

첫 번째 프로비저너가 수행되기 때문에 Provisioning with 'local-exec'라는 문구가 출력되지만, 출력하려는 self.content의 sensitive가 true로 되어있기 때문에 (output suppressed due to sensitive value in config)가 화면에 표기된다.

provisioner "local-exec" {
    command = "abc"
    on_failure = continue
}

이후 두 번째 프로비저너가 수행되지만, abc라는 커맨드가 존재하지 않기 때문에 apply 명령어가 실패해야 하지만 on_failure이 continue이기 때문에 중지되지 않고 다음 프로비저너로 넘어가는 것을 확인할 수 있다.

provisioner "local-exec" {
    when = destroy
    command = "echo The deleting filename is ${self.filename}"
}

세 번째 프로비저너는 when이 destroy로 설정되어 있기 때문에 terraform destroy 명령어가 수행될 때 동작한다. terraform destroy 명령어를 수행하면 아래와 같은 결과를 확인할 수 있다.

의도했던 문구가 정상적으로 출력됐다.

프로비저너에는 file, local-exec, remote-exec의 세 종류가 있다.

local-exec provisioner

local-exec는 테라폼이 실행되는 환경에서 수행할 명령어를 정의한다.

command
- 필수
- 실행할 명령어를 입력한다.
- << 연산자를 통해 여러 줄의 명령어를 입력 가능
working_dir
- 선택
- command를 실행할 디렉터리를 지정해야 한다.
- 상대/절대 경로로 설정
interpreter
- 선택
- 명령을 실행하는 데 필요한 인터프리터를 지정하며, 첫 번째 인수는 인터프리터 이름이고 두 번째부터는 인터프리터 인수 값을 의미한다.
environment
- 선택
- 실행 시 환경 변수는 실행 환경의 값을 상속받으며, 추가 또는 재할당하려는 경우 해당 인수에 key = value 형태로 설정한다.

resource "null_resource" "example" {
    provisioner "local-exec" {
        command = <<EOF
            echo Hello! > file.txt
            echo $ENV >> file.txt
            EOF

        interpreter = ["bash", "-c"]

        working_dir = "/tmp"

        environment = {
            ENV = "world!"
        }
    }
}

connection

remote-exec와 file 프로비저너를 사용하기 위해서는 원격지에 연결할 SSH, WinRM 연결 정보가 필요하다.

resource "null_resource" "example" {

    connection {
        type = "ssh"
        user = "root"
        password = var.root_password
        host = var.host
    }

    provisioner "file" {
        source = "conf/myapp.conf"
        destination = "/etc/myapp.conf"
    }

    provisioner "file" {
        source = "conf/myapp.conf"
        destination = "C:/App/myapp.conf"

        connection {
            type = "winrm"
            user = "Administrator"
            password = var.admin_password
            host = var.host
        }
    }
}

connection 블록은 리소스에 선언되는 경우 해당 리소스 내에 구성된 프로비저너에 공통으로 선언되고, 프로비저너 내에 선언된 경우 해당 프로비저너에만 적용된다.

connection에서 사용가능한 인수의 목록은 다음과 같다. 원격 연결을 사용하는 일이 잦기 때문에 표로 정리해두었다. 참고하도록 하자

인수	연결 타입	설명	기본값
type	SSH/WinRM	연결 유형으로 ssh 또는 winrm	ssh
user	SSH/WinRM	연결에 사용되는 사용자	ssh: root winrm: Administrator
password	SSH/WinRM	연결에 사용되는 비밀번호
host	SSH/WinRM	(필수) 연결 대상 주소
port	SSH/WinRM	연결 대상의 타임별 사용 포트	ssh: 22 winrm: 5985
timeout	SSH/WinRM	연결 시도에 대한 대기 값	5m
script_path	SSH/WinRM	스크립트 복제 시 생성되는 경로	(추가 설명)
private_key	SSH	연결 시 사용할 SSH key를 지정하며, password 인수보다 우선함
certificate	SSH	서명된 CA 인증서로 사용 시 private_key와 함께 사용
agent	SSH	ssh-agent를 사용해 인증하지 않는 경우 false로 설정하며 Windows의 경우 Pageant만 사용 가능
agent_identity	SSH	인증을 위한 ssh-agent의 기본 사용자
host_key	SSH	원격 호스트 또는 서명된 CA의 연결을 확인하는 데 사용되는 공개키
target_platform	SSH	연결 대상 플랫폼으로 windows 또는 unix	unix
https	WinRM	true인 경우 HTTPS로 연결	false
insecure	WinRM	true인 경우 HTTPS 유효성 무시	false
use_ntlm	WinRM	true인 경우 NTLM 인증을 사용	false
cacert	WinRM	유효성 검증을 위한 CA 인증서

원격 연결이 요구되는 프로비저너의 경우 스크립트 파일을 원격 시스템에 업로드하여 해당 시스템의 기본 쉘에서 실행하도록 하므로 script_path의 경우 적절한 위치를 지정하도록 하자. 경로는 난수인 %RAND% 경로가 포함되어 생성된다.

주로 사용하는 리눅스 환경에서의 경로는 /tmp/terraform_%RAND%.sh 다. Bastion Host를 통해 연결하는 경우에도 관련 인수를 지원한다. 인수는 다음과 같다.

인수	설명	기본값
bastion_host	io 설정하게 되면 바스티온 호스트 연결이 활성화되며, 연결 대상 호스트를 지정
bastion_host_key	호스트 연결을 위한 공개키
bastion_port	호스트 연결을 위한 포트 번호	port 인수 값
bastion_user	호스트에 연결할 사용자	user 인수 값
bastion_password	호스트 연결에 사용할 비밀번호	password 인수 값
bastion_private_key	호스트 연결에 사용할 SSH 키파일	private_key 인수 값
bastion_certificate	서명된 CA 인증서 내용으로 bastion_private_key와 함께 사용

file provisioner

file 프로비저너는 테라폼을 실행하는 시스템에서 연결 대상으로 파일 또는 디렉토리를 복사하는 데 사용된다. 사용되는 인수는 다음과 같다.

source
- 소스 파일 또는 디렉토리로, 현재 작업 중인 디렉토리에 대한 상대 경로 또는 절대 경로로 지정할 수 있다.
- content와 함께 사용할 수 없다.
content
- 연결 대상에 복사할 내용을 정의하며 대상이 디렉토리인 경우 tf-file-content 파일이 생성되고, 파일인 경우 해당 파일에 내용이 기록된다.
- source와 함께 사용할 수 없다.
destination
- 필수 항목으로 항상 절대 경로로 지정되어야 하며, 파일 또는 디렉토리다.
- SSH 연결의 경우 대상 디렉토리가 존재해야 하며, WinRM은 디렉토리가 없다면 자동으로 생성된다.

디렉토리를 대상으로 하는 경우 source의 경로 작성 방법에 따라 동작에 차이가 발생한다. 예를 들어 destination이 /tmp인 경우 source가 /foo와 같이 뒤에 /가 붙지 않는 형태일 때는 원격 대상에 /tmp/foo 디렉토리가 업로드 된다.

하지만, source가 /foo/와 같이 뒤에 /가 붙는다면, /foo 디렉토리 내부에 위치한 파일들만 /tmp 디렉토리 내부로 업로드 된다.

remote-exec provisioner

remote-exec는 원격지 환경에서 실행할 명령어와 스크립트를 정의한다. 예를 들면 AWS의 EC2 인스턴스를 생성하고 해당 가상 환경에서 명령을 실행하고 패키지를 설치하는 등의 동작을 의미한다.

사용되는 인수는 다음과 같으며, 각 인수는 서로 배타적이다.

inline
- 명령에 대한 목록으로 [ ] 블록 내에 " "로 묶인 다수의 명령을 ,로 구분하여 구성한다.
script
- 로컬의 스크립트 경로를 넣고 원격에 복사하여 실행한다.
scripts
- 로컬의 스크립트 경로의 목록으로 [ ] 블록 내에 " "로 묶인 다수의 스크립트 경로를 ,로 구분하여 구성한다.

script 또는 scripts의 대상 스크립트 실행에 필요한 인수는 관련 구성에서 선언할 수 없으므로 필요할 때 file 프로바이더로 해당 스크립트를 업로드하고 inline 인수를 활용해 스크립트에 인수를 추가한다.

resource "aws_instance" "web" {
    ...

    connection {
        type = "ssh"
        user = "root"
        password = var.root_password
        host = self.public_ip
    }

    provisioner "file" {
        source = "script.sh"
        destination = "/tmp/script.sh"
    }

    provisioner "remote-exec" {
        inline = [
            "chmod -x /tmp/script.sh",
            "/tmp/script.sh args",
        ]
    }
}

null_resource

null_resource는 아무 작업도 수행하지 않는 리소스를 구현한다. 해당 리소스는 테라폼 프로비저닝 동작을 설계하면서 사용자가 의도적으로 프로비저닝하는 동작을 조율해야 하는 상황이 발생하며, 프로바이더가 제공하는 리소스 수명주기 관리만으로는 이를 해결하기 어렵기 때문이다.

주로 다음과 같은 상황에서 사용된다.

프로비저닝 수행 과정에서 명령어 실행
프로비저너와 함께 사용
모듈, 반복문, 데이터 소스, 로컬 변수와 함께 사용
출력을 위한 데이터 가공

간단한 사용 예를 다음 상황을 통해 가정해보자.

AWS EC2 인스턴스를 프로비저닝하면서 웹 서비스를 실행시키고자 한다.
웹 서비스는 노출되어야 하는 고정 IP가 필요하기 때문에 AWS EIP 리소스를 생성해야 한다.

resource "aws_instance" "foo" {
    ami = "ami-5189a661"
    instance_type = "t2.micro"

    private_ip = "10.0.0.12"
    subnet_id = aws_subnet.tf_test_subnet.id

    provisioner "remote-exec" {
        inline = [
            "echo ${aws_eip.bar.public_ip}"
        ]
    }
}

resource "aws_eip" "bar" {
    vpc = true

    instance = aws.instance.foo.id
    associate_with_private_ip = "10.0.0.12"
    depends_on = [aws_internet_gateway.gw]
}

aws_eip가 생성하는 고정된 IP를 할당하기 위해서는 대상인 `aws_instance`의 `id`값이 필요하다. 하지만 `aws_instance`가 프로비저닝 되기 위해서는 `aws_eip`가 생성하는 `public_ip`가 필요하다.

어디까지나 예시이기 때문에 `terraform plan` 명령어를 실행해도 정상적으로 동작하지는 않지만, 만약 정상적인 코드라고 가정했을 때 위와 같은 순환 참조가 발생할 경우 `Cycle` 에러가 발생하게 된다.

상호 참조되는 종속성을 끊기 위해서는 둘 중 하나의 실행 시점을 한 단계 뒤로 미뤄야 한다. 이런 경우 실행에 간격을 추가하여 실제 리소스와는 무관한 동작을 수행하기 위해 `null_resource`를 활용한다.

위의 코드를 다음과 같이 수정할 수 있다.

resource "aws_instance" "foo" {
    ami = "ami-5189a661"
    instance_type = "t2.micro"

    private_ip = "10.0.0.12"
    subnet_id = aws_subnet.tf_test_subnet.id
}

resource "aws_eip" "bar" {
    vpc = true

    instance = aws.instance.foo.id
    associate_with_private_ip = "10.0.0.12"
    depends_on = [aws_internet_gateway.gw]
}

resource "null_resource" "barz" {
    provisioner "remote-exec" {
        connection {
            host = aws_eip.bar.public_ip
        }
        inline = [
            "echo ${aws_eip.bar.public_ip}"
        ]
    }
}

null_resource는 정의된 속성이 id가 전부이므로, 선언된 내부의 구성이 변경되더라도 새로운 Plan 과정에서 실행 게획에 포함되지 못한다.

따라서 사용자가 null_resource에 정의된 내용을 강제로 다시 실행하기 위한 인수로 trigger가 제공된다.

trigger는 임의의 string 형태의 map 데이터를 정의하는데, 정의된 값이 변경되면 null_resource 내부에 정의된 행위를 다시 실행한다.

resource "null_resource" "foo" {
    ...
    trigger = {
        ec2_id = aws.instance.bar.id # instance의 id가 변경되는 경우 재실행
    }
}

resource "null_resource" "bar" {
    ...
    trigger = {
        ec2_id = time() # 테라폼으로 실행 계획을 생성할 때마다 재실행
    }
}

terraform_data

테라폼 1.4 버전이 릴리즈되면서 기존 null_resource 리소스를 대체하는 terraform_data 리소스가 추가됐다.

terraform_data 리소스 또한 자체적으로는 아무것도 수행하지 않지만, 추가 프로바이더 없이 테라폼 자체에 포함된 기본 수명주기 관리자가 제공된다는 것이 장점이다.

사용 시나리오는 null_resource와 동일하며 강제 재실행을 위한 triggers_replace와 상태 저장을 위한 input 인수와 input에 저장된 값을 출력하는 output 속성이 제공된다.

triggers_replace에 정의되는 값이 기존 map 형태에서 tuple로 변경되어 쓰임이 더 간단해졌다.

resource "terraform_data" "foo" {
    triggers_replace = [
        aws_instance.bar.id,
        aws_instance.barz.id
    ]

    input = "world"
}

output "terraform_data_output" {
    value = terraform_data.foo.output # 출력 결과 : world
}

moved Block

테라폼의 State에 기록되는 리소스 주소의 이름이 변경되면 기존 리소스는 삭제되고 새로운 리소스가 생성되지만, 테라폼 리소스의 이름을 변경해야 하는 상황이 발생할 수 있다.

리소스의 이름은 변경되지만 이미 테라폼으로 프로비저닝된 환경을 그대로 유지하고자 하는 경우 테라폼 1.1 버전부터 moved 블록을 사용할 수 있다.

moved 블록은 State에 접근 권한이 없는 사용자라도 변경되는 주소를 리소스 영향 없이 반영할 수 있다.

resource "local_file" "a" {
    content = "foo!"
    filename = "${path.module}/foo.bar"
}

output "file_content" {
    value = local_file.a.content
}

위의 예제 코드에서 local_file의 이름을 a에서 b로 변경해야 할 때, 단순히 리소스의 이름을 a에서 b로 수정한 뒤 plan을 수행하면, a 리소스를 삭제하고 b를 새로 생성하려는 실행 계획이 발생한다.

a의 프로비저닝 결과를 유지한 채로 이름을 변경하기 위해서는 moved 블록을 활용하면 된다.

resource "local_file" "b" {
    content = "foo!"
    filename = "${path.module}/foo.bar"
}

moved {
    from = local_file.a
    to = local_file.b
}

output "file_content" {
    value = local_file.a.content
}

moved 블록을 추가하고 plan 명령어를 다시 실행하면 제거되거나 새롭게 생성되는 리소스가 존재한다는 메시지는 보이지 않고, 출력 결과에 local_file.a 주소가 local_file.b로 변경되었다는 메시지가 추가로 출력된다.

이후 apply를 수행하고 이후 moved 블록을 삭제하면 새로운 리소스 주소가 사용되어 리팩토링이 완료된 것을 확인할 수 있다.

[Helm] Helm Quick Start

겨울바람_ — Sat, 10 Aug 2024 19:43:35 +0900

Helm?

헬름은 The Package Manager for Kubernetes, 즉 쿠버네티스의 패키지 관리를 위한 툴이다.

여기서 패키지란, Helm Charts를 패키징한 것을 의미한다. 여기서 차트란 쿠버네티스의 리소스 yaml 파일을 템플릿화하여 메타 정보 파일 등을 압축한 파일을 뜻한다.

템플릿이란 쿠버네티스 환경에서 특정 프로그램을 실행시킬 수 있도록 해주는 리소스인 Deployment 혹은 Service 등을 포함하는 일종의 리소스 모음을 의미한다.

Helm Chart Structure

Helm의 공식문서를 살펴보면 헬름 차트는 이와 같은 구조를 갖는다. 구조에서 확인할 수 있는 각 파일 및 폴더는 다음과 같은 역할을 한다.

templates/ 디렉토리는 template 파일을 보관하기 위한 디렉토리이다.

Helm이 Chart를 검사할 때 templates/ 내부에 존재하는 파일들을 template rendering engine으로 전송한다. 그리고 템플릿 엔진은 탬플릿의 실행 결과를 취합하여 쿠버네티스로 보낸다.

values.yaml 파일은 Chart 내부의 기본 값을 포함하는데, 해당 파일의 값을 helm install, helm upgrade 중에 템플릿 값에 덮어씌울 수 있다. 즉, value.yaml을 통해 동적으로 템플릿 파일을 구성할 수 있다.

Chart.yaml 파일은 Chart의 버전, 이름 등 메타 정보와 설명을 포함하며, 템플릿 내부에서 접근할 수 있다.

charts/ 디렉토리는 다른 차트 파일들을 포함하기 위한 용도다.

Deploy Nginx using helm

Create template files

원하는 텍스트 에디터를 사용해 deployment.yaml과 service.yaml을 작성해보자. 필자는 templates/ 디렉토리 내부에 nginx 생성을 위한 deployment.yaml과 service.yaml을 아래와 같이 각각 작성했다.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx-for-helm
spec:
  selector:
    matchLabels:
      app: nginx-for-helm
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx-for-helm
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

# templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    run: nginx-for-helm
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: nginx-for-helm

tree 명령어로 다음과 같은 구조를 확인할 수 있다.

Create Chart.yaml

Chart.yaml 에 대해 나와있는 공식문서를 살펴보면 Chart.yaml 파일에 포함되는 요소가 굉장히 많은 것을 확인할 수 있다. 이 중 필수적으로 들어가야하는 것은 apiVersion과 name, version이고 나머지는 부가적인 요소이기 때문에 필수 요소에 대해 먼저 알아보도록 하자.

apiVersion은 Helm Chart에 대한 버전을 의미하며 과거에는 v1을 주로 사용했지만 Helm 3부터는 v2 사용이 필수적이다.

name은 해당 Chart의 이름을 의미하며 version 또한 Chart의 버전을 의미하기에 두 요소는 임의로 작성하면 된다.

위 내용을 바탕으로 Chart.yaml 파일을 작성해보자. Chart.yaml 파일은 templates/ 디렉토리와 동일한 depth에 작성해주면 된다.

apiVersion: v2
name: chart-for-nginx
version: 0.0.

tree 명령어로 다음과 같은 구조를 확인할 수 있다.

Create values.yaml

values.yaml 파일을 사용하면 외부에서 템플릿의 값을 동적으로 변경할 수 있다. values.yaml을 사용하기 위해서는 적용하고자 하는 위치에 템플릿 문법을 사용해야 한다.

values.yaml 파일에는 템플릿에 적용하고자 하는 값을 작성해줘야 한다. 만약 Nginx 배포에 사용되는 이미지를 동적으로 적용하고자 한다면, image: nginx:latest와 같은 값을 values.yaml 파일에 작성해둬야 한다.

위의 예시대로 이미지를 동적으로 변경하고자 한다면 템플릿의 이미지 필드를 다음과 같이 템플릿 문법을 통해 대체하면 된다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx-for-helm
spec:
  selector:
    matchLabels:
      app: nginx-for-helm
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx-for-helm
    spec:
      containers:
      - name: nginx
        image: {{ .Values.image }}
        ports:
        - containerPort: 80

{{ .Values.image }} 라는 문법은 values.yaml 파일에 위치한 필드들 중 image를 키 값으로 가지는 값이 대입된다는 것을 알려주는 것이다.

tree 명령어로 다음과 같은 구조를 확인할 수 있다.

Deploy

이렇게 작성된 Helm Chart를 통해 Nginx를 배포해보자. helm install <release-name> <chart-name> 명령어를 통해 간단히 배포가 가능하다.

release-name은 사용자가 임의로 작성 가능하며, chart-name의 경우 지금까지 작성한 Helm Chart의 위치를 입력하면 된다. 성공적으로 Helm Chart를 작성했다면 아래의 그림과 같이 성공적으로 배포가 된 것을 확인할 수 있다.

deployment.yaml 파일에서 replica 값을 2로 설정했기 때문에 2개의 Pod가 동작 중이며, Deployment 리소스와 Service 리소스 또한 정상적으로 실행 중인 것을 확인할 수 있다.

image 또한 우리가 values.yaml을 통해 동적으로 지정한 nginx:latest 이미지가 적용되어 있는 것을 확인할 수 있다.

Release Template

위에서 작성 예제에는 한 가지 문제점이 있는데, deployment.yaml의 metadata.name 값이 nginx-deployment로 고정되어 있기 때문에 하나의 release만 생성이 가능하다는 것이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx-for-helm
spec:
  selector:
    matchLabels:
      app: nginx-for-helm
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx-for-helm
    spec:
      containers:
      - name: nginx
        image: {{ .Values.image }}
        ports:
        - containerPort: 80

만약 helm install first-nginx . 명령어를 실행한 뒤에 helm install second-nginx . 명령어를 수행하게 되면 아래와 같이 에러가 발생하며 release에 실패하는 것을 확인할 수 있다.

이러한 문제점을 해결하기 위해 Release Template 문법이 필요하다. 사용 방법은 values.yaml을 사용했을 때와 거의 동일하다. 동적으로 변경하고자 하는 부분에 문법을 적용시키면 된다.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Values.app-name }}
spec:
  selector:
    matchLabels:
      app: {{ .Values.app-name }}
  replicas: 2
  template:
    metadata:
      labels:
        app: {{ .Values.app-name }}
    spec:
      containers:
      - name: nginx
        image: {{ .Values.image }}
        ports:
        - containerPort: 

---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    run: {{ .Values.app-name }}
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: {{ .Values.app-name }}

편의를 위해 두 템플릿의 metadata.name을 동일하게 설정했고 nginx-for-helm을 추출하여 values.yaml 파일을 통해 동적으로 주입하는 방식으로 변경했다.

Release Template을 사용한 방식으로 release를 배포하게 되면 first-nginx와 second-nginx 모두 잘 배포가 되는 것을 확인할 수 있다.

Deployment와 Service, Pod 또한 성공적으로 생성됐다. 배포된 리소스의 이름 또한 {{ .Release.Name }}을 통해 지정한대로 변경되어 실행되는 것을 확인해볼 수 있다.

Release Template 문법은 이외에도 여러가지 기능이 많이 존재하는데 대표적으로 특정 Namespace에 배포할 수 있는 {{ .Release.Namespace }}가 존재한다. 사용하기 위해서는 템플릿 파일에 metadata.namespace 항목을 추가하고 {{ .Release.Namespace }}을 적용해주면 된다.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  namespace: {{ .Release.Namespace }}
  labels:
    app: {{ .Values.app-name }}
spec:
  selector:
    matchLabels:
      app: {{ .Values.app-name }}
  replicas: 2
  template:
    metadata:
      labels:
        app: {{ .Values.app-name }}
    spec:
      containers:
      - name: nginx
        image: {{ .Values.image }}
        ports:
        - containerPort: 

---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  namespace: {{ .Release.Namespace }}
  labels:
    run: {{ .Values.app-name }}
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: {{ .Values.app-name }}

{{ .Release.Namespace }}을 사용하기 위해서는 Namespace가 사전에 생성되어 있어야 한다. 만약 Helm을 실행하는 동시에 Namespace를 생성하고자 한다면 --create-namespace -n 옵션을 사용하면 되지만, 이는 언제 누가 Namespace를 생성했는지 추적하기가 어렵기 때문에 무분별한 사용은 지양하는 편이 좋다.

기존에 생성되어 있던 Namespace인 helmprac에 배포하고자 한다면, helm install -n helmprac first-nginx . 명령어를 사용하면 된다.

Values.yaml override

Helm Chart의 기존 values.yaml파일의 일부 값을 변경하고자 할 때 사용할 수 있는 방법이다. 예를 들어 기존에 설정해둔 image: nginx:latest를 image: nginx:stable로 변경하고 싶을 때 사용할 수 있다.

첫번 째 방법은 --set 옵션을 사용하는 것이다.

helm install --set image=nginx:stable first-nginx . 명령어를 통해 배포되는 Nginx의 이미지의 버전을 stable로 변경할 수 있다.

하지만 --set 옵션을 사용하는 방법은 변경하고자 하는 변수가 많을 경우에는 효율적이지 못하다. 이러한 문제점을 해결하기 위해 파일에 변경하고자 하는 값을 설정해두는 방법이 있다.

helm install -f <file-path> <release-name> <chart-name> 명령어를 통해 실행 가능하다.

텍스트 에디터를 통해 my-values.yaml 파일을 생성하고 동적으로 변경하고자 하는 값인 Nginx의 이미지를 입력하자. values.yaml을 작성할 때와 동일하게 image: nginx:stable을 입력해주면 된다.

그리고 helm install -f my-values.yaml first-nginx . 명령어를 실행시키면, 다음과 같이 Nginx의 이미지 버전이 stable로 변경되어 배포되는 것을 확인할 수 있다.

[Terraform] 테라폼 반복문

겨울바람_ — Fri, 9 Aug 2024 21:34:36 +0900

Terraform 반복문

list 형태의 값 목록이나 Key-Value 형태의 문자열 집합인 데이터가 있는 경우 반복문을 통해 관리할 수 있다. 또한, 단순한 자료구조뿐만 아니라 리소스 내에 생성된 블록에 대한 것도 반복문을 통해 코드의 중복 없이 동적으로 생성이 가능하다.

count

리소스 또는 모듈 블록에 count값이 정수인 인수가 포함된 경우 선언된 정수 값만큼 리소스나 모듈을 생성하게 된다.

count에서 생성되는 참조값은 count.index이며, 반복하는 경우 0부터 1씩 증가해 인덱스가 부여된다. main.tf를 아래와 같이 작성해보자.

resource "local_file" "abc" {
    count = 5
    content = "abc"
    filename = "${path.module}/abc.txt"
}

위 코드를 실행시켰을 때 목표로 하는 결과는 다섯 개의 파일이 생성되는 것이지만, 파일명에는 변화가 없기 때문에 하나의 파일만 존재하게 된다. 본래의 의도대로 실행되도록 하려면 다음과 같이 count.index 값을 추가하면 된다.

resource "local_file" "abc" {
    count = 5
    content = "abc"
    filename = "${path.module}/abc${count.index}.txt"
}

count를 프로그래밍 언어의 반복문 인덱스처럼 활용하는 방법은 다음과 같다.

variable "names" {
    type = list(string)
    default = ["a", "b", "c"]
}

resource "local_file" "abc" {
    count = length(var.names)
    content = "abc"
    filename = "${path.module}/abc-${var.names[count.index]}.txt"
}

resource "local_file" "def" {
    count = length(var.names)
    content = local_file.abc[count.index].content
    filename = "${path.module}/def-${element(var.names, count.index)}.txt"
}

local_file.abc와 local_file.def는 var.names에 선언되는 값에 영향을 받아 동일한 개수만큼 생성하게 된다.

count로 생성되는 리소스의 경우 "<리소스 타입>.<이름>[<인덱스 번호>], 모듈의 경우 module.<모듈 이름>[<인덱스 번호>]로 해당 리소스의 값을 참조한다.

for_each

리소스 또는 모듈 블록에서 for_each에 입력된 데이터 형태가 map또는 set이면, 선언된 key 값 개수만큼 리소스를 생성하게 된다.

resource "local_file" "abc" {
    for_each {
        a = "content a"
        b = "content b"
    }
    content = each.value
    filename = "${path.module}/${each.key}.txt"
}

생성되는 리소스의 경우 <리소스 타입>.<이름>[<key>], 모듈의 경우 module.<모듈 이름>[<key>]로 해당 리소스의 값을 참조한다. 이 참조 방식을 통해 리소스 간 종속성을 정의하기도 하고 변수로 다른 리소스에서 사용하거나 출력을 위한 결과 값으로 사용한다.

for_each를 활용한 반복 참조 예시는 다음과 같다.

variable "names" {
    default = {
        a = "content a"
        b = "content b"
        c = "content c"
    }
}

resource "local_file" "abc" {
    for_each = var.names
    content = each.value
    filename = "${path.module}/abc-${each.key}.txt"
}

resource "local_file" "def" {
    for_each = local_file.abc
    content = each.value.content
    filename = "${path.module}/def-${each.key}.txt"
}

for

for문은 복합 형식 값의 형태를 변환하는데 사용된다. 예를 들어 list 값의 포맷을 변경하거나 특정 접두사를 추가할 수도 있고, output에 원하는 형태로 반복적인 결과를 표현할 수 있다.

list의 경우 값 또는 인덱스와 값을 반환한다.
map의 경우 키 또는 키와 값을 반환한다.
set의 경우 키 값을 반환한다.

variable "names" {
    default = ["a", "b", "c"]
}

resource "local_file" "abc" {
    content = jsonencode([for s in var.names: upper(s)]) # result: ["A", "B", "C"]
    filename = "${path.module}/abc.txt"
}

for문을 사용할 때 대상이 되는 타입에 따라 다음과 같은 규칙이 적용된다.

list 타입의 경우 반환 받는 값이 하나로 되어 있으면 값을, 두 개인 경우 앞의 인수가 인덱스를 반환하고 두 번째 인수가 값을 반환한다.
map 타입의 경우 반환 받는 값이 하나로 되어 있으면 키를, 두 개인 경우 앞의 인수가 키를 반환하고 두 번째 인수가 값을 반환한다.
for문의 결과값은 for문을 감싸고 있는 괄호의 종류에 따라 다르게 결정된다.
- [ ] 형태로 감싸고 있을 경우 tuple로 반환된다.
- { } 형태로 감싸고 있을 경우 object 형태로 반환된다.
  - object 형태의 경우 키와 값을 => 기호로 구분한다.

list 타입에 적용할 수 있는 규칙을 간단한 예제를 통해서 확인해보자.

variable "names" {
  type = list(string)
  default = ["a", "b"]
}

output "tuple_upper_value" {
  value = [for v in var.names: upper(v)]
} 

output "tuple_index_value" {
  value = [for i, v in var.names: "${i}: ${v}"]
}

output "object_upper_value" {
  value = {for v in var.names: v => upper(v)}
}

output "tuple_with_if" {
  value = [for v in var.names: upper(v) if v != "a"]
}

위의 HCL을 terraform apply 명령어를 통해 실행할 경우 아래와 같은 output 결과가 나오게 된다. 작성된 순서와 무관하게 결과가 표시되기 때문에 output의 이름을 잘 확인해보자.

이번에는 좀 더 복잡한 예제를 통해 확인해보자.

variable "members" {
  type = map(object({
    role = string
    group = string
  }))

  default = {
    "memberA" = {
      role = "member",
      group = "dev"
    }
    "adminB" = {
      role = "admin",
      group = "dev"
    }
    "devopsC" = {
      role = "member",
      group = "devops"
    }
  }
}

output "get_all_group" {
  value = [for k, v in var.members: "${k} is a ${v.group}"]
} 

output "get_only_admin" {
  value = {
    for name, user in var.members: name => user.role
    if user.role == "admin"
  }
}

output "C" {
  value = {
    for name, user in var.members: user.role => name...
  }
}

특히 주목해서 살펴봐야 할 output은 get_member_group_by_role인데, name 뒤에 ...이 붙은 것을 확인할 수 있다. 이는 object 타입으로 결과를 반환하는 경우 키 값은 고유해야 하기 때문에 값 뒤에 그룹화 모드 심볼인 ...를 붙여 키의 중복을 방지하는 것이다.

...는 SQL의 group by문과 동일한 역할을 한다.

dynamic

테라폼을 통해 리소스를 구성하다 보면 count나 for_each를 통해 리소스 전체를 여러 개 생성하는 것 이외에도 리소스 내에 선언되는 구성 블록들을 여러 개 작성해야 할 때가 있다.

동일한 요소가 리소스 선언 내부에서 블록 형태로 여러 개 정의되는 상황에 dynamic을 통해 동적으로 생성할 수 있다.

dynamic 블록을 작성하려면, 기존 블록의 속성 이름을 dynamic 블록의 이름으로 선언하고 기존 블록 속성에 정의되는 내용을 content 블록에 작성한다. 반복 선언에 사용되는 반복문 구문은 for_each를 사용한다.

기존 for_each문 사용시 각 속성에 key, value가 할당되었다면, dynamic에서는 dynamic에 지정한 이름에 대한 속성이 할당된다.

간단한 예시를 통해 dynamic의 사용법에 대해 알아보자.

data "archive_file" "dotfiles" {
  type = "zip"
  output_path = "${path.module}/dotfile.zip"

  source {
    content = "hello a"
    filename = "${path.module}/a.txt"
  }

  source {
    content = "hello b"
    filename = "${path.module}/b.txt"
  }

  source {
    content = "hello c"
    filename = "${path.module}/c.txt"
  }
}

위의 HCL을 terraform apply를 통해 실행시키게 되면 경로에 dotfiles.zip 이라는 압축 파일이 생성되고 해당 압축 파일을 풀어보면 리소스 내에 정의된 source 블록에 맞게 텍스트 파일이 생성된 것을 확인할 수 있다

참고로 처음 archive 프로바이더를 사용하는 경우에는 잊지 말고 terraform init을 실행하자.

이제 data 리소스 내에 반복적으로 정의되어 있는 source 블록을 dynamic을 활용하여 동적으로 설정하는 코드로 변경해보자.

우선 각 리소스 블록 내에서 매번 변동되는 값인 content와 filename 부분을 추출하여 variable 리소스로 만든다.

variable "names" {
    default = {
        a = "hello a"
        b = "hello b"
        c = "hello c"
    }
}

data "archive_file" "dotfiles" {
  type = "zip"
  output_path = "${path.module}/dotfile.zip"

  source {
    content = [ ]
    filename = "${path.module}/[ ]"
  }
}

이제 반복적으로 생성되는 source 리소스에 dynamic을 붙이고 for_each로 variable 리소스에서 반복 구문을 추출한다.

variable "names" {
    default = {
        a = "hello a"
        b = "hello b"
        c = "hello c"
    }
}

data "archive_file" "dotfiles" {
  type = "zip"
  output_path = "${path.module}/dotfile.zip"

  dynamic "source" {
    for_each = var.names
    content = {
        content = source.value
        filename = "${path.module}/${source.key}.txt"        
    }
  }
}

해당 코드를 실행시켜보면 이전에 dynamic없이 작성했던 코드와 동일하게 동작하는 것을 확인할 수 있다. 이러한 반복문을 적절히 사용하는 것으로 테라폼 사용 시 중복되는 코드를 줄여 유지 보수 및 확장에 용이한 코드 작성이 가능해진다.

[Terraform] 테라폼 기초 (1)

겨울바람_ — Sat, 3 Aug 2024 20:22:05 +0900

Terraform init

terraform init 명령어는 테라폼 구성 파일이 있는 작업 디렉토리를 초기화하는데 사용한다. 이 작업을 실행하는 디렉토리를

루트 모듈

이라고 부른다.

테라폼에서의 모듈이란?

테라폼이 실행되는 디렉토리를 모듈이라고 부른다. 모듈에는 테라폼 코드 정의를 위한 tf 또는 tf.json 확장자의 파일과 tfvars 같은 변수를 정의하는 파일이 포함된다. 일반적으로 기본 작업 디렉토리의 정의된 파일 집합을 루트 모듈이라고 부른다. 루트 모듈은 다른 모듈을 호출해 해당 루트 모듈이 구성하는 리소스 구성을 포함시킬 수 있고, 이렇게 호출되는 모듈을 자식 모듈이라고 한다.

테라폼을 시작하는데 사용되는 첫 번째 명령어로 테라폼에서 사용되는 프로바이더, 모듈 등의 지정된 버전에 맞춰 루트 모듈을 구성한다.

자바의 pom.xml 이나 노드의 package.json 등과 같이 의존성 정의를 읽고, 최초 실행 시 실행에 필요한 아티팩트나 라이브러리를 다운로드하고 준비시키는 역할과 비슷하다.

main.tf 파일이 존재하는 위치에서 terraform init 명령어를 수행하면 아래와 같이 성공적으로 초기화 되었다는 메시지를 확인할 수 있다.

-upgrade

0.14 버전 이후부터 프로바이더 종속성을 고정시키는 .terraform.lock.hcl이 추가됐다. 작업자가 로컬에서 init으로 받은 프로바이더, 모듈 버전으로 수행한 이후 다른 작업자나 리모트 환경에서 init을 수행하는 경우, 지속적으로 업그레이드되는 각 프로바이더와 모듈로 인해 변경된 버전으로 설치될 가능성이 있다.

따라서 작업 당시의 버전 정보를 기입하고 .terraform.lock.hcl 파일이 있으면 해당 파일에 명시된 버전으로 init을 수행한다. 이후 작업자가 의도적으로 버전을 변경하거나 코드에 명시한 다른 버전으로 변경하려면 terraform init -upgrade를 수행해야 한다.

Terraform validate

단어의 의미 그대로 디렉토리에 있는 테라폼 구성 파일의 유효성을 확인한다. 서비스나 인프라의 상태를 확인하기 위한 원격 작업 혹은 API는 발생하지 않으며, 코드적인 유효성만 검토한다.

Terraform plan & apply

terraform plan 명령어는 테라폼으로 적용할 인프라의 변경 사항에 관한 실행 계획을 생성한다.

이를 통해 출력되는 결과를 확인하여 어떤 변경이 적용될지 사용자가 미리 검토하고 이해하는데 도움을 준다.

terraform apply는 plan 명령어를 통해 작성된 적용 내용을 토대로 작업을 실행한다. 만약 plan 명령어로 생성된 실행 계획이 없다면, 자동으로 계획을 생성하고 해당 계획을 승인할 것인지 묻는 메시지가 출력된다.

-detailed-exitcode

실행 계획 생성 명령과 함께 사용하기 좋은 추가 옵션으로, 파이프라인 설계에서 활용할 수 있다. exitcode 또는 errorlevel은 동작의 결과를 숫자 코드로 제공한다.

각 숫자 코드는 자동화된 동작을 설계할 때 그 뒤 작업을 수행할지, 사용자에게 알릴지, 정지할지 등을 나타낸다.

0 : 변경사항이 없는 성공
1 : 오류가 있음
2 : 변경사항이 있는 성공-outterraform plan -out=tfplan 명령어는 실행 계획을 바이너리 파일 형태로 추출하는 옵션이다.

-out=<파일명> 형태다. 해당 명령어로 생성된 tfplan 바이너리 파일을 apply 명령 수행 시 붙여 실행할 경우 실행 계획을 생성할지 묻는 과정이 생략된 것을 확인할 수 있다.

실행 계획이 이미 존재하기 때문에 해당 과정이 생략된 것이다. 만약 바이너리 파일이 생성된 이후 원본 tf 파일이 수정되었다면 terrafrom apply tfplan 명령어는 실행할 수 없다.

-replace

프로비저닝이 완료된 이후 terraform plan과 terraform apply 실행 시 코드 변경이 없다면 실행 계획에 프로비저닝할 대상이 없지만, 사용자가 필요에 의해 특정 리소스를 다시 생성해야 하는 경우 -replace 옵션으로 대상 리소스 주소를 지정하면 대상을 삭제 후 생성하는 실행 계획이 발생한다.

terraform plan과 terraform apply 모두 적용이 가능하다.

Terraform destroy

terraform destory 명령어는 테라폼 구성에서 관리하는 모든 객체를 제거하는 명령어다. 테라폼 코드로 구성된 리소스의 일부만 제거하기 위해서는 테라폼의 선언적 특성에 따라 삭제하려는 항목을 코드에서 제거하고, 다시 terraform apply를 실행하는 방법이 있다.

하지만 모든 객체를 삭제하려면 terraform destory 명령어를 사용하면 된다. terraform destory 명령어 또한 apply처럼 실행 계획을 필요로 하며 실행 계획 파일을 생성한 후 terraform destory 명령어를 실행하는 단계적으로 나누어 실행하는 방식 또한 가능하다.

파이프라인에서는 주로 terraform plan -destroy -out=<파일명>로 실행 계획을 만들고 terraform apply로 해당 실행 계획을 실행하는 방식으로 단계를 나누어 사용한다.

-auto-approve

apply, destroy 명령어처럼 사용자의 승인이 필요할 경우 해당 승인 요청을 자동으로 승낙하는 옵션이다. 당연한 이야기지만 사용에 주의해야 한다.

Terraform fmt

terraform fmt 명령어는 테라폼 구성 파일을 표준 형식과 표준 스타일로 적용하는데 사용한다. 주로 구성 파일의 가독성을 향상시키는 목적으로 사용된다.

-recursive 옵션으로 하위 디렉토리의 테라폼 구성 파일을 모두 포함해 적용시킬 수 있다.

HCL

테라폼으로 인프라를 구성하기 위한 여러 선언 블록들이 존재한다.

Terraform Block
Resource Block
Data Block
Variable Block
Local Block
Output Block

Terraform Block

테라폼의 구성을 명시하는데 사용된다. 테라폼 버전이나 프로바이더 버전과 같은 값들을 명시적으로 선언하고 필요한 조건들을 입력하여 실행 오류를 최소화하기 위해 사용한다.

terraform {
    required_version = "~> 1.9.3"  # 테라폼 버전

    required_providers {
        random = {
            version = ">= 3.0.0, < 3.1.0"  # 프로바이더 버전 나열
        }
        aws = {
            version = "4.2.0"
        }
    }

    cloud {  # Cloud/Enterprise 같은 원격 실행을 위한 정보
      organization = "<MY_ORG_NAME>"
      workspaces {
        name = "my-first-workspace"
      }
    }

    backend "local" {  # state를 보관하는 위치를 지정
        path = "relative/path/to/terraform.tfstate"
    }
}

테라폼 버전 제약 구문에서 사용되는 크기 부호는 아래의 표에서 확인할 수 있듯 각기 다른 의미를 가지고 있다.

백엔드 블록의 구성은 테라폼 실행 시 저장되는 state파일의 저장 위치를 선언한다. 백엔드 블록은 하나의 백엔드만 허용한다.

테라폼은 state 파일의 데이터를 사용해 코드로 관리된 리소스를 탐색하고 추적한다. 또한 작업자 간의 협업을 고려한다면 테라폼으로 생성한 리소스의 상태 저장 파일을 공유할 수 있는 외부 백엔드 저장소가 필요하다.

state에는 외부로 노출되면 안되는 비밀번호와 같은 민감한 정보들이 포함되어 있을 수 있기 때문에 접근 제어 또한 필요하다.

기본적으로 활성화되는 백엔드는 local이다. 상태를 작업자의 로컬 환경에 저장하고 관리하는 방식이다. 이외의 다른 백엔드 구성은 동시에 여러 작업자가 접근해 사용할 수 있도록 공유 스토리지 같은 개념을 갖는다.

공유되는 백엔드에 state가 관리되면 테라폼이 실행되는 동안 .terraform.tfstate.lock.info 파일이 생성되면서 해당 state를 동시에 사용하지 못하도록 잠금 처리를 한다.

Resource Block

리소스는 테라폼이 프로비저닝 도구라는 측면에서 가장 중요한 요소다. 리소스 블록은 선언된 항목을 생성하는 동작을 수행한다.

resource "<리소스 유형>" "<이름>" {
    <인수> = <값>
}

리소스 유형은 첫 번째 언더바를 기준으로 앞은 프로바이더 이름, 뒤는 프로바이더에서 제공하는 리소스 유형을 의미한다. local_file의 경우 local 프로바이더에 속한 리소스 유형이다. 따라서 해당 리소스의 유형이 어떤 프로바이더가 제공하는 것인지는 언더바 앞쪽의 이름을 보고 확인할 수 있다.
이름의 경우 동일한 유형에 대해서 식별자 역할을 하기 때문에 유형이 같은 경우 동일한 이름을 사용할 수 없다.

lifecycle 메타 인수를 통해 리소스의 기본 생명주기를 사용자가 임의로 변경하는 것이 가능하다.

create_before_destroy (bool)
- 리소스 수정 시 신규 리소스를 우선 생성하고 기존 리소스를 삭제한다.
- 테라폼의 기본 생명주기는 삭제 후 생성이기 때문에 사용자는 의도적으로 수정된 리소스를 먼저 생성하기를 원할 수 있다.
- 생성되는 리소스가 기존 리소스로 인해 생성이 실패되거나 삭제 시 함께 삭제될 위험 또한 존재한다.
prevent_destroy (bool)
- 해당 리소스를 Destroy하려고 할 때 명시적으로 거부한다.
ignore_changes (list)
- 리소스 요소에 선언된 인수의 변경 사항을 테라폼 실행 시 무시한다.
precondition
- 리소스 요소에 선언된 인수의 조건을 검증한다.
postcondition
- plan과 apply 이후의 결과를 속성 값으로 검증한다.Data Block데이터 소스는 테라폼으로 정의되지 않은 외부 리소스 또는 저장된 정보를 테라폼 내에서 참조할 때 사용한다.

data "<리소스 유형>" "<이름>" {
    <인수> = <값>
}

# 데이터 소스 참조
data.<리소스 유형>.<이름>.<속성>

리소스 유형은 첫 번째 언더바를 기준으로 앞은 프로바이더 이름, 뒤는 프로바이더에서 제공하는 리소스 유형을 의미한다. local_file의 경우 local 프로바이더에 속한 리소스 유형이다.
따라서 해당 리소스의 유형이 어떤 프로바이더가 제공하는 것인지는 언더바 앞쪽의 이름을 보고 확인할 수 있다.
이름의 경우 동일한 유형에 대해서 식별자 역할을 하기 때문에 유형이 같은 경우 동일한 이름을 사용할 수 없다.

resource "local_file" "abc" {
    content = "123!"
    filename = "${path.module}/abc.txt"
}

data "local_file" "abc" {
    filename = local_file.abc.filename
}

resource "local_file" "def" {
    content = data.local_file.abc.content
    filename = "${path.module}/def.txt"
}

데이터 소스인 data.local_file.abc는 리소스 local_file.abc의 파일 이름을 참조하여 데이터 소스를 생성한다.

데이터 소스 local_file은 읽어온 파일의 내용을 content 속성으로 참조할 수 있으므로 리소스 local_file.def에서는 data.local_file.abc.content로 읽혀진 데이터를 참조한다.

Variable Block

입력 변수는 인프라를 구성하는 데 필요한 속성 값을 정의하여 코드의 변경 없이 여러 인프라를 생성하는데 목적을 둔다.

테라폼에서는 이를 Input Variable 즉 입력 변수로 정의한다. 입력이라는 수식어가 붙는 이유는, 테라폼이 plan 실행 시 값을 입력한다는 점 때문이다.

variable "<이름>" {
    <인수> = <값>
}

변수 정의 시 사용 가능한 메타인수는 다음과 같다.

default : 변수에 할당되는 기본값 정의
type : 변수에 허용되는 값 유형 정의
description : 입력 변수의 설명
validation : 변수 선언의 제약조건을 추가해 유효성 검사 규칙 정의
sensitive : 민감한 변수 값임을 알리고 테라폼의 출력문에서 값 노출을 제한
nullable : 변수에 값이 없어도 됨을 지정

지원되는 변수의 유형 또한 여러가지가 존재한다. 사용 예시는 아래를 참고

variable "string" {
    type = string
    description = "var String"
    default = "myString"
}

variable "number" {
    type = number
    default = 123
}

variable "boolean" {
    default = true
}

variable "list" {
    default = [
        "meta",
        "nvidia",
        "apple",
        "amazon",
        "google",
        "tesla",
        "microsoft"
    ]
}

output "list_index_0" {
    value = var.list.0
}

output "list_all" {
    value = [
        for name in var.list :
            upper(name)
    ]
}

variable "set" {
    type = set(string)
    default = [
        "google",
        "vmware",
        "amazon",
        "microsoft"
    ]
}

variable "object" {
    type = object({name=string, age=number})
    default = {
        name = "abc"
        age = 12
    }
}

variable "tuple" {
    type = tuple([string, number, bool])
    default = ["abc", 123, true]
}

variable "ingress_rules" {
    type = list(object({
        port = number,
        description = optional(string),
        protocol = optional(string, "tcp),
    }))
    default = [
        { port = 80, description = "web" }
        { port = 53, protocol = "udp" }
    ]    
}

변수에 대한 유효성 검사는 validation 메타인수를 사용해 진행할 수 있다. 예시는 다음과 같다.

variable "image_id" {
    type = string
    description = "The id of the machine image (AMI) to use for the server"

    validation {
        condition = length(var.image_id) > 4
        error_message = "The image_id value must exceed 4."
    }
}

변수에 대한 참조는 코드 내에서 var.<이름> 형태로 할 수 있다. 선언된 variable에 정의된 값이 없으면 terraform plan 혹은 apply 실행 후 변수 값을 입력하라는 항목을 확인할 수 있다.

변수 값을 입력하면 입력한 값으로 실행 계획을 생성하고 수행한다.

민감한 입력 변수를 사용해야 할 경우 다음과 같이 sensitive 메타인수를 사용하여 민감 여부를 선언할 수 있다.

variable "my_password" {
    default = "password"
    sensitive = true
}

resource "local_file" "abc" {
    content = var.my_password
    filename = "${path.module}/abc.txt"
}

기본 값이 추가되어 값을 입력받는 항목은 출력되지 않지만 테라폼의 실행 계획에서의 참조 변수 값이 감춰지는 것을 확인할 수 있다.

프로비저닝을 완료할 경우 출력에서는 값이 표현되지 않았지만 실제 생성되는 리소스 결과물에서는 지정한 값이 입력된 것을 확인할 수 있다.

sensitive를 사용하여 민감한 변수로 지정하더라도 terraform.tfstate 파일에는 결과문이 평문으로 기록되기 때문에 state 파일의 보안에는 유의해야 한다.

Local Block

코드 내에서 사용자가 지정한 값 또는 속성 값을 가공해 참조 가능한 local은 외부에서 입력되지 않고, 코드 내에서만 가공되어 동작하는 값을 선언한다.

선언된 모듈 내에서만 접근이 가능하고, 변수처럼 실행 시에 입력받을 수 없다.

locals로 선언할 수 있으며, locals 내에 선언한 로컬 변수의 이름은 전체 루트 모듈 내에서 유일해야 한다.

variable "prefix" {
    default = "hello"
}

locals {
    name = "terraform"
    content = "${var.prefix} ${local.name}"
    my_info = {
        age = 20
        region = "KR"
    }
    my_nums = [1, 2, 3, 4, 5]
}

locals {
    content = "duplicated content" # 중복 선언되었으므로 에러가 발생
}

선언된 로컬 변수는 local.<이름>으로 참조할 수 있다. 테라폼 구성 파일을 여러 개 생성해 작업하는 경우 서로 다른 파일에 선언되어 있더라도 다른 파일에서 참조할 수 있다.

Output Block

출력 값은 주로 테라폼 코드의 프로비저닝 수행 후의 결과 속성 값을 확인하는 용도로 사용된다. 또한 테라폼 모듈 간, 워크스페이스 간 데이터 접근 요소로도 활용할 수 있다.

예를 들어 자바의 getter와 비슷한 역할이라고 생각하면 좋다. 출력 값의 용도는 다음과 같이 정의할 수 있다.

루트 모듈에서 사용자가 확인하고자 하는 특정 속성 출력한다.
자식 모듈의 특정 값을 정의하고 루트 모듈에서 결괄르 참조한다.
서로 다른 루트 모듈의 결과를 원격으로 읽기 위한 접근 요소로 활용할 수 있도록 한다.

출력 값을 작성하면 단순 디버깅을 넘어 속성 값을 노출하고 접근할 수 있다.

모듈 내에서 생성되는 속성 값들은 output block에 정의된다.

output "instance_ip_addr" {
    value = "http://${aws_instance.server.private.ip}"
}

출력되는 값은 value의 값이며 테라폼이 제공하는 조합과 프로그래밍적인 기능들에 의해 원하는 값을 출력할 수 있다.

주의할 점은 output 결과에서 리소스 생성 후 결정되는 속성 값은 프로비저닝이 완료되어야 최종적으로 결과를 확인할 수 있고 terraform plan 단계에서는 적용될 값을 출력하지 않는다는 것이다.

사용할 수 있는 메타인수는 다음과 같다.

description : 출력 값 설명
sensitive : 민감한 변수 값임을 알리고 테라폼의 출력문에서 값 노출을 제한한다.
- 값이 출력되지 않으므로 디버깅보다는 값을 노출시키지 않고 상위 모듈 또는 다른 모듈에서 참조하기 위한 목적으로 사용
depends_on : value에 담길 값이 특정 구성에 종속성이 있는 경우 생성되는 순서를 임의로 조정한다.
precondition : 출력 전에 지정된 조건을 검증한다.

사용 방법은 다음과 같다.

resource "local_file" "abc" {
  content = "abc123"
  filename = "${path.module}/abc.txt"
}

output "file_id" {
  value = local_file.abc.id
}

output "file_abspath" {
  value = local_file.abc.filename
}

terraform plan을 사용할 경우 file_id의 경우 실행 계획 단계에서는 알 수 없기 때문에 apply 실행 이후 확인할 수 있다고 출력된다.

apply 명령어를 실행하면 프로비저닝 이후 해당 값이 잘 출력되는 모습을 확인할 수 있다.

[k8s] K8s Storage with OpenEBS

겨울바람_ — Fri, 2 Aug 2024 19:45:50 +0900

k8s Storage

컨테이너 환경에서는 별도 설정을 하지 않으면 데이터는 호스트 노드의 임시 디스크에 보관된다. 컨테이너를 삭제하면 임시 디스크에 있는 데이터는 저장되지 않고 컨테이너와 함께 삭제된다.

이러한 문제를 쿠버네티스에서는 Pod와 데이터를 분리해서 영구 볼륨이라는 별도의 추상화된 리소스로 해결한다.

쿠버네티스 볼륨을 구성하는 주요 리소스로 Persistent Volume (영구볼륨), PVC (Persistent VolumeClaim, 영구볼륨 요청자), Storage Class가 있다.

클러스터 관리자와 사용자(개발자)의 역할에 따라 쿠버네티스 볼륨에 관련된 작업이 서로 다르다.

클러스터 관리자는 클라우드 서비스 제공업자, 상용 혹은 오픈소스 솔루션 중에서 원하는 성능과 기
능을 제공하는 스토리지를 선택하여 개발자에게 적절한 솔루션을 제공하는 역할을 한다.

게빌지는 애플리케이션에서 필요한 스토리지 용량과 특성(ReadWriteOnce/ReadWriteMany)을 고려해 애플리케이션에 연결하는 작업을 진행한다.

이번 예제에서는 오픈소스 OpenEBS 로컬 호스트패스를 이용해 스토리지 클래스를 만들고 스토리지 관련 설정을 YAML 파일로 작성하는 방법에 대해 알아보려고 한다.

PersistentVolume

PV (Persistent Volume) 영구볼륨은 실제 데이터가 영속적으로 저장되는 스토리지의 일부다. 실제 데이터가 저장되는 리소스이며, 관리자는 정적으로 직접 영구볼륨을 생성할 수 있으나 운영 환경에서는 대부분 스토리지 클래스를 이용해 동적으로 영구볼륨을 할당한다.

PVC (Persistent Volume Claim) 영구볼륨 요청자는 실제 데이터가 저장돠는 영구볼륨과 분리해서 영구볼륨의 스토리지 용량과 액세스 모드 등 영구볼륨과 관련된 설정만 별도로 분리한 쿠버네티스 리소스다.

관리자는 PV, 스토리지 클래스를 만들고 개발자는 영구볼륨의 상세한 설정 내역을 몰라도 PVC를 이용해 볼륨을 사용할 수 있다.

스토리지 클래스는 스토리지 솔루션 또는 클라우드 서비스 제공업체에서 제공하는 여러 가지 스토리지 중 동일한 속성 (IOPS, 레이턴시, 백업정책 등)을 가지는 스토리지의 집합 리소스다.

사용자는 원하는 스토리지 클래스를 지정해 PVC에서 요청하면 스토리지 클래스에서 해당 볼륨을 동적으로 할당한다.

이러한 쿠버네티스 볼륨을 할당하는 프로세스를 간략히 정리하면 관리자는 사전에 클러스터에 필요한 스토리지 유형을 정하고 이를 스토리지 클래스로 생성한다.

사용자는 PVC로 볼륨 할당을 요청하면 해당 스토리지 클래스에서 동적으로 PV가 할당된다.

OpenEBS 로컬 호스트패스 설치

쿠버네티스 자체에서는 스토리지 클래스를 제공하지 않고 별도의 솔루션을 설치해야 사용할 수 있다. 일반적으로 퍼블릭 클라우드 서비스 업체는 스토리지 클래스를 기본으로 제공하고 온프레미스 환경은 별도 스토리지 솔루션으로 구현한다.

현업에서 많이 사용하는 오픈소스 스토리지 솔루션으로 Ceph와 GlusterFS, OpenEBS 등이 있다. 이번 포스팅의 예제에서는 속도가 빠르고 설치 및 사용이 쉬운 OpenEBS 호스트패스를 사용한다.

OpenEBS는 Pod가 실행되는 호스트 노드의 특정 디렉터리(호스트패스)를 Pod의 볼륨으로 할당한다. OpenEBS 솔루션 없이 호스트 노드의 원하는 경로를 직접 Pod의 볼륨으로 할당할 수 있지만 스토리지 클래스를 이용하지 않으므로 필요할 때마다 영구볼륨을 생성하고 다시 수동으로 삭제해야 하는 정적인 구성으로 굉장히 번거롭다.

OpenEBS를 사용하면 스토리지 클래스를 이용해 동적으로 볼륨을 생성하고 삭제할 수 있다. 또한 볼륨 관련 구성은 공통 속성을 사용하므로 기존에 사용하는 애플리케이션 YAML 파일을 수정하지 않고도 OpenEBS 환경에 그대로 사용할 수 있다는 장점이 있다.

외부 네트워크 지연과 분산 파일 시스템을 사용하지 않고 노드의 로컬 디스크에 직접 데이터를 읽고 쓰므로 다른 스토리지 솔루션에 비해 성능이 뛰어나다.

k create ns openbs
k ns openbs

k apply -f https://openebs.github.io/charts/openebs-operator-lite.yaml
k apply -f https://openebs.github.io/charts/openebs-lite-sc.yaml

k get sc

위의 명령어를 입력하면, openebs-device와 openebs-hostpath라는 2가지 스토리지 클래스가 생성된다.

openebs-device는 노드에서 마운트하지 않은 별도의 디스크 디바이스에 Pod의 데이터를 저장하고 openebs-hostpath는 호스트 노드의 특정 디렉터리에 데이터를 할당하는 방식이다.

호스트패스에서 사용하는 디렉터리 위치는 관리자가 변경할 수 있는데, 기본 설정은 /var/openebs/local이다.

OpenEBS에서 사용하는 볼륨이 호스트 노드의 파일시스템 용량에 영향을 끼치지 않도록 기본 디렉터리 경로가 아니라 별도의 마운트 포인트를 사용하는 것을 권장한다.

이제 새롭게 생성한 openebs-hostpath 스토리지 클래스를 이용해 PVC를 생성하고 Pod에 볼륨을 할당한다.

스토리지 클래스를 이용한 PVC 및 영구볼륨 사용

YAML 파일을 이용해 PVC를 생성하고 애플리케이션 내 영구 볼륨을 마운트하는 실습을 진행하려 한다. 개발자는 해당 작업만 가능하면 쿠버네티스 스토리지를 사용하는 데 별다른 문제가 없다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: default-pvc
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: FileSystem
  resources:
    requests: 
      storage: 1Gi
storageClassName: "openebs-hostpath"

kind: PersistentVolumeClaim
- 쿠버네티스는 영구볼륨을 요청하는 PersistentVolumeClaim을 별도의 리소스로 지정한다
namespace: default
- PVC는 네임스페이스 단위로 생성하고 구분된다
- 영구볼륨은 특정 네임스페이스가 아닌 전체 클러스터 단위로 할당된다
spec.accessModes: ReadWriteOnce
- 스토리지 클래스에서 지원하는 액세스 모드 중 한 가지를 지정한다
spec.volumeMode: Filesystem
- Filesystem과 Block의 두 가지 모드를 선택할 수 있다
spec.resources.requests.storage: 1Gi
- 영구볼륨이 사용하는 용량을 지정한다. Pod가 마운트한 볼륨은 해당 용량을 초과해서 사용할 수 없다
spec.storageClassName: "openebs-hostpath"
- 클러스터가 지원한느 스토리지 클래스 이름을 지정한다. 클러스터에서 사용 가능한 복수의 스토리지 클래스가 있으면 원하는 스토리지 클래스를 선택할 수 있다

개발자는 위와 같은 기본 템플릿 PVC 파일에서 용량과 스토리지 클래스 이름 등 몇 가지 변수만 변경해서 새로운 PVC를 반복 생성할 수 있다.

k ns default
k apply -f date-pvc.yaml
k get pvc

PVC를 생성하면 정상적으로 default-pvc가 생성된다. PVC 또한 리소스이므로 k get 명령어로 PVC 목록을 확인할 수 있다. 하지만, 상태가 정상이지 않고 Pending으로 표기되는 것을 확인할 수 있다.

k describe pvc default-pvc 명령어를 통해 확인해보면, 첫 번째 사용자(Pod)가 볼륨을 연결하기를 기다린다. 라는 의미의 메시지를 확인할 수 있다.

OpenEBS 스토리지 클래스의 특징으로 PVC는 해당 PVC를 사용하는 Pod가 먼저 생성되고 다음으로 볼륨이 연결된다. Pod가 생성되고 해당 PVC를 마운트하면 상태가 Pending에서 Bound로 변경된다.

이처럼 사용자는 먼저 Pod가 사용할 볼륨을 PVC로 생성한다. 이후 헤당 PVC를 Pod YAML 파일의 volumeMounts와 volumes에 추가해서 사용한다.

아래는 실제 애플리케이션에서 PVC를 사용하는 Deployment YAML 파일의 예제다

apiVersion: apps/v1
kind: Deployment
metadata:
  name: data-pod
  namespace: default
  labels:
    app: date
spec:
  replicas: 1
  selector:
    matchLabels:
      app: date
  template:
    metadata:
      labels:
        app: date
    spec:
      containers:
      - name: date-pod
        image: busybox
        command:
        - "/bin/sh"
        - "-c"
        - "while true; do date >> /data/pod-out.txt; cd /data; sync; sync; sleep 30; done"
        volumeMounts:
        - name: date-vol
          mountPath: /data
    volumes:
    - name: date-vol
      persistentVolumeClaim:
        claimName: default-pvc

spec.template.spec.containers.volumeMounts
- 컨테이너에서 사용할 볼륨의 정보를 지정한다. Pod는 볼륨을 사용하기 위해 volumeMounts와 volumes의 2가지를 사용한다
spec.template.spec.containers.volumeMounts.name
- 컨테이너 마운트 포인트에 사용할 볼륨의 이름을 지정한다
spec.template.spec.containers.volumeMounts.mountPath
- 컨테이너 내부의 마운트 포인트를 지정한다. 지정된 마운트 포인트로 볼륨이 할당된다
spec.template.spec.volumes.name
- 컨테이너 마운트 포인트 이름과 동일하게 매핑한다. YAML 파일 내에 볼륨 마운트가 여러 개 있으면 해당하는 볼륨 마운트 이름과 일치시킨다
spec.template.spec.volumes.persistentVolumeClaim.claimName
- 볼륨에 사용할 PVC 이름을 지정한다. PVC는 Pod와 동일한 네임스페이스에 있어야 한다

이전 Pod 예제와 동일하게 date 명령의 출력 결과를 파일에 저장하는 Deployment YAML파일이다. 이전과 다르게 PVC를 사용해 데이터가 사라지지 않고 영구볼륨에 저장된다.

PVC 볼륨을 사용하는 Deployment YAML 파일은 기존의 Deployment YAML과 동일하지만 volumeMounts와 volumes 부분만 기존 Deployment YAML에 추가됐다.

위의 YAML 파일을 통해 Deployment를 생성한다.

k apply -f date-pvc-deploy.yaml
k get pod -o wide
k get pvc

PV/PVC 삭제

영구볼륨은 Pod에서 볼륨으로 사용하고 있으므로 영구볼륨을 삭제하려면 먼저 볼륨을 사용하고 있는 Pod를 삭제해야 한다. Pod를 삭제하지 않으면, 영구볼륨이 삭제되지 않는다.

PVC를 삭제할 때는 영구볼륨의 삭제와 관련된 정책은 해당 스토리지 클래스의 정책을 따르며 k get pv 출력 결과에서 확인할 수 있다.

영구볼륨 삭제와 관련된 ReclaimPolicy(재요구정책)에는 Delete와 Retain옵션이 있다. Delete는 PVC를 삭제하면 영구볼륨도 함께 삭제되고, Retain은 PVC는 삭제돼도 영구볼륨은 삭제되지 않고 유지하는 정책이다.

Retain 옵션을 사용하면 PVC를 삭제해도 PV는 삭제되지 않으므로 안전하지만, 삭제 작업은 수동으로 진행해야 한다. 만약 지워지지 않은 영구볼륨이 있다면 향후 해당 영구볼륨을 이용해 수동으로 새로운 PVC를 생성할 수 있다.

OpenEBS 스토리지 클래스의 기본 정책은 Delete다.

사용자 스토리지 클래스를 지정해 헬름 차트 MySQL 설치하기

쿠버네티스 환경에서 애플리케이션을 설치하는 데는 주로 헬름을 이용한다. 헬름 차트는 템플릿 파일로 개별 상황에 맞게 설치 옵션을 지정할 수 있다. 스토리지 클래스도 템플릿 파일을 이용해 지정할 수 있다.

대부분의 헬름 파일에 스토리지 클래스만 지정하면 PVC가 자동으로 생성된다. 이번 예제에서는 OpenEBS 호스트패스를 스토리지 클래스로 지정해 헬름 차트로 MySQL 애플리케이션을 설치한다.

helm search repo mysql
helm pull bitnami/mysql
tar xvfz mysql-9.1.0.tgz
mv mysql mysql-9.1.0
cd mysql-9.1.0/
cp values.yaml my-values.yaml

이후 YAML 파일의 내용 중 아래 부분을 변경한다.

architecture: replication
- MySQL 애플리케이션 구조를 복제 구성으로 변경한다
persistence.storageClass
- primary.persistence.storageClass와 secondary.persistence.storageClass의 스토리지 클래스를 openebs-hostpath로 변경한다
```
k create ns mysql
k ns mysql
helm install mysql -f my-values.yaml .
```

헬름 차트를 이용해 애플리케이션을 설치할 때 헬름의 스토리지 클래스를 새롭게 생성한 openebs-hostpath로 지정하면 해당 스토리지 클래스를 이용해 자동으로 영구볼륨을 생성한다.

헬름 차트 삭제시, 데이터 보호를 위해 기본적으로 PVC는 삭제하지 않는다. 따라서 헬름 차트가 업그레이드되거나 변경돼도 데이터는 그대로 유지해서 기존 데이터의 변경 없이 그대로 사용할 수 있다.

PVC를 삭제하려면 다음과 같이 수동으로 삭제해야 한다.

k delete pvc --all

로컬 호스트패스 스토리지 클래스의 장점 및 제약 사항

OpenEBS 호스트패스는 이름에서 알 수 있듯이 로컬 호스트의 특정 디렉터리를 스토리지 클래스로 이용한다. 네트워크에 연결된 별도의 스토리지를 이용하지 않으므로 네트워크 전송에 따른 추가 지연 시간이 없다.

또한, 분산 파일 시스템을 사용하지 않고 로컬 노드의 디스크를 바로 사용하므로 다른 스토리지 솔루션에 비해 성능이 월등하다. 하지만 해당 노드에서만 Pod가 실행되므로 노드가 다운되면 Pod 역시 함께 사용하지 못한다는 제약 사항이 있다.

고가용성 측면에서의 제약 사항은 애플리케이션 단에서 다른 노드의 Pod와 데이터를 동기화하여 해결할 수 있다. 데이터베이스 자체에서 제공하는 동기화 기능을 사용하면 이러한 제약 사항이 없기 때문에 로컬 호스트패스를 실제 운영 환경의 데이터베이스 스토리지 클래스로 사용하는 경우도 있다.

스토리지 고가용성 구성 제약

로컬 호스트패스 스토리지 클래스는 Pod가 실행 중인 노드의 특정 디렉터리를 Pod의 볼륨으로 할당한다. 따라서 Pod의 데이터는 해당 노드에만 존재해서 다른 노드로 Pod를 이동하는 것이 불가능하다.

볼륨을 가지지 않는 일반 파드(Stateless POD)는 특정 노드에 장애가 발생해도 다른 노드로 이전이 가능하지만, 로컬 호스트패스를 스토리지 클래스로 가진 Pod는 다른 노드로 이동이 불가능하다.

PVC가 특정 노드만 실행 중인 Pod는 해당 노드에서만 실행 가능하다. 해당 노드의 문제가 발생하면 Pod가 실행되지 않아 서비스 장애가 발생한다.

호스트패스를 사용하는 Pod는 애플리케이션 단에서 서로 다른 노드의 Pod와 서로 데이터를 복제하도록 설정할 필요가 있다. 볼륨 복제를 지원하면 기존 PVC를 삭제했을 때 새로운 노드에서 기존 데이터를 처음부터 복제해서 Pod 실행이 가능하다.

다음 포스팅에서는 EKS 환경에서의 Storage 설정에 대해 작성해보고자 한다.

[EKS] AWS Load Balancer Controller on EKS

겨울바람_ — Mon, 29 Jul 2024 21:00:33 +0900

AWS Load Balancer Controller?

AWS Load Balancer Controller는 Kubernetes 클러스터를 위한 AWS Elastic Load Balancer를 관리하는 add-on이다. 따라서 별도로 AWS Load Balancer Controller를 추가 설치하여 로드 밸런서를 관리하는 것이다.

그림과 같이 클러스터 내부에 다수의 Pod가 존재하고 연결을 위해 AWS ELB를 구성했다고 가정해보자. 이 상황에서 AWS Load Balancer Controller는 Control Plane과 상호 작용하여 대상 Pod의 정보를 확인하고 이벤트를 모니터링 하는 것으로 클러스터 내부의 Pod 정보를 취득할 수 있다.

그리고 AWS ELB로 해당 Pod 정보를 프로비저닝하여 타겟 그룹 바인딩을 할 수 있다. 즉, 대상 그룹에 Pod 정보를 추가하거나 삭제하는 관리자 역할을 수행할 수 있다.

이렇듯 AWS Load Balancer Controller가 해당 권한을 수행하기 위해서는 IRSA라는 보안 작업을 선행해야 한다.

IRSA는 IAM Role for Service Accounts의 약자로 AWS Load Balancer Controller의 인증 절차를 통해 권한을 위임한다.

AWS Load Balancer Controller가 AWS ELB와 EKS Cluster Control Plane과 지속적인 상호작용을 통해 동작하는 것으로 미루어 봤을 때, Kubernetes 서비스 어카운트와 AWS IAM을 연동하여 인증 절차를 진행하는 것으로 볼 수 있다.

만약 위 그림처럼 AWS Load Balancer Controller가 존재하지 않는다면, ELB에서 노드의 IP와 Port로 Node Port와 Cluster IP를 거쳐 iptables 분산 룰로 Pod에 전달될 것이다.

AWS Load Balancer Controller가 구성된다면 노드에 Pod 형태로 구성이 된다. AWS Load Balancer Controller는 Control Plane과 상호 작용하여 ELB로 프로비저닝 하기 때문에 ELB는 대상 그룹에 Pod가 매핑되어 Node Port, Cluster IP를 거치지 않고 직접적으로 Pod와 통신을 수행한다.

그로 인해 리눅스 커널의 conntrack과 iptables 분산 룰을 확인하는 과정이 생략되어 효율적인 통신이 가능하다. 이러한 동작이 가능한 이유는 Amazon VPC CNI 환경에 따라 노드와 Pod가 동일한 IP 대역인 것이 가장 크다.

ELB의 대표적인 세 가지 중 NLB, CLB와 같이 L4 영역의 부하 분산으로 Kubernetes의 Service의 Load Balancer가 구성될 수 있고, ALB와 같은 L7 영역의 부하 분산으로 Ingress의 Load Balancer가 구성될 수 있다.

[EKS] Amazon VPC CNI

겨울바람_ — Fri, 26 Jul 2024 00:29:25 +0900

Amazon VPC CNI 소개

Amazon EKS는 Amazon VPC CNI 플러그인을 통해 클러스터 네트워킹 환경을 구성한다.

CNI는 Container Network Interface의 약자로 컨테이너 간 네트워킹을 제어하는 표준이라는 의미를 가진다. 참고로 Kubernetes의 경우 kubenet이라는 자체 CNI가 존재하지만 기능적 측면에서 제약이 많아 외부 플러그인을 주로 사용한다.

Amazon VPC CNI는 AWS VPC와 자연스럽게 연계되어 네트워킹 환경을 구성할 수 있다. 이로 인해 다양한 VPC 서비스와 통합이 가능하다.

Pod와 Node의 IP를 동일한 대역으로 할당할 수 있으며 이로 인해 통신에 대한 오버헤드가 거의 발생하지 않는다.

Assign IP Address on Pod

노드에 Amazon VPC CLI 플러그인을 설치하면 aws-node라는 이름의 DaemonSet이 생성된다. aws-node는 Local IP Address Manager의 약자인 L-IPAM과 CNI 플러그인으로 구성되어 있다.

VPC CNI와 L-IPAM은 gRPC를 통해 통신하여 IP주소를 삭제하거나 추가하는 구조이며, L-IPAM은 인스턴스에 대한 메타데이터를 확인하여 사용 가능한 ENI와 Secondary IP 주소를 파악한다.

이를 통해 Warm-Pool이라는 사용 가능한 Secondary IP 대역을 구성하는데 Warm-Pool에 구성된 IP 주소를 Pod가 생성될 때마다 하나씩 할당해준다. Warm Pool에 적재 가능한 IP 주소는 인스턴스 유형에 따라 가용 수량이 정해져 있다.

L-IPAM의 Warm-Pool과 인스턴스의 Primary ENI는 밀접한 연관을 지니고 있다.

우선 인스턴스에 구성되는 Primary ENI는 다수의 Priavte IP 주소를 포함하고 있을 수 있다. Primary ENI에 구성된 IP 주소는 Slot이라는 영역에 매칭된다.

위의 그림을 보면 총 3개의 Slot으로 구성되어 있으며, 이를 통해 해당 ENI에서는 3개의 Private IP 주소를 사용할 수 있다는 것을 알 수 있다.

이때 첫 번째 Slot에 매핑되는 IP 주소를 Primary IP 주소라고 하며 그 이외의 주소를 Secondary IP 주소라고 한다. 이 Secondary IP 주소가 Warm-Pool에 할당되는 것이다.

Pod가 생성되면 Warm-Pool 대역의 IP 주소를 제공하는데 이때 ENI에 Secondary IP 주소를 추가하는 개념이다.

만약 API Server로부터 Kubelet으로 신규 Pod를 추가하라는 명령이 내려오면 Kubelet은 Amazon VPC CNI로 추가 명령을 전달한다. VPC CNI는 L-IPAM에게 gRPC로 IP 주소 추가 명령을 전달하는 것이다.

L-IPAM은 Warm-Pool 대역의 IP 주소를 사용하도록 알리고 ENI의 빈 Slot에 Secondary IP 주소를 매핑한다. 최종적으로는 kubelet이 Pod에 ENI의 Secondary IP를 할당한다. 여기서 Node의 IP 주소는 Primary IP 주소이고 Pod의 IP 주소는 ENI의 Secondary IP 주소로 VPC 내의 동일한 IP 대역으로 유지된다.

만약 Primary ENI에 사용 가능한 Slot이 가득 찼을 때 새로운 Pod 생성 요청이 발생하면 어떻게 될까?

추가적인 ENI를 구성하여 해당 ENI의 Slot에 IP 주소를 매핑하고 해당 IP 주소를 Pod에게 할당한다. ENI의 경우 인스턴스의 유형에 따라 생성 한계가 정해져 있기 때문에 무한정 IP 주소를 할당할 수는 없다.

VPC CNI Communication

ENI로 연결된 구역은 VPC 연결 구간으로 AWS Networking을 통해 통신이 가능하다. 각각의 Pod는 통신을 위해 veth0로 구성되고 이를 연결하기 위해 가상의 ENI와 1:1 매칭이 된다.

그리고 이들을 서로 연결하여 통신이 가능하게 하는 Virtual Router가 각각의 가상의 ENI와 연결되는 Linux Networking 공간에 구성된다. 아래의 그림에서 Pod와 Node의 대역대가 동일한 것을 확인할 수 있는데 이는 VPC IP 대역을 활용하기 위해서다.

위의 그림은 Pod A에서 Pod C로 통신하는 상황을 예시로 그려둔 것이다.

Pod A에서 발생한 Packet은 Linux Networking을 통해 Node A의 ENI까지 전달되고 VPC 구간의 AWS Networking을 통해 Node B로 전달된다. Node B에 들어온 Packet이 Pod C로 전달될 때는 동일한 IP 대역이기 때문에 별도의 작업 없이 전달된다.

이러한 측면에서 오버헤드의 발생이 적어 빠른 통신이 가능하다.

EKS VPC CNI vs Kubernetes Calico

Kubernetes 환경에서 보편적으로 많이 사용하고 있는 CNI 플러그인 중 하나인 Calico와 VPC CNI를 비교해보자. 참고로 필자의 홈 서버에 구축된 쿠버네티스의 CNI 또한 Calico를 사용하고 있다.

우선 가장 다른 점은 Node와 Pod가 서로 다른 대역대로 IP 주소가 할당된다는 것이다.

VPC CNI의 예제와 동일하게 Pod A와 Pod C가 통신한다고 가정해보자. Pod A에서 목적지 주소를 Pod C의 IP 주소인 10.0.2.1로 할당한 Packet을 Linux Networking을 통해 Node A의 ENI까지 전달할 것이다.

하지만 Node 간 연결되는 네트워크 구간은 10.0.2.1의 IP 대역을 알지 못한다. 즉, 통신이 불가능하다는 것이다. 이러한 문제점을 해결하기 위해 VXLAN이나 IPIP같은 오버레이 네트워크를 구성하여 동작한다.

오버레이 네트워크는 Packet의 IP 헤더에 추가적인 IP 헤더를 덧붙여 전달하는 방법이다. Pod A가 전달하는 Packet을 VXLAN이나 IPIP로 ENI끼리 통신할 수 있는 IP 헤더를 캡슐화하여 전달한다.

그렇게 되면 ENI 구간은 추가된 IP 헤더를 사용하여 Node B까지 통신이 가능해진다. Packet을 Pod C로 전달할 때는 앞에서 덧붙였던 IP 헤더를 역캡슐화하여 원본 Packet을 Pod C에 전달한다.

오버레이 네트워크를 통해 Packet을 캡슐화 혹은 역캡슐화 하는 과정에서 VPC CNI에서는 발생하지 않았던 오버헤드가 발생하기 때문에 VPC CNI 보다는 비효율적인 통신이라고 생각할 수 있다.

Amazon VPC CNI Maximum Pod Quantity

Amazon VPC CNI를 통해 Pod를 생성할 경우 인스턴스 유형에 따라 최대 Pod 생성 수량에 제한이 존재한다.

위에서 살펴본 Secondary IPv4 Address 방식의 경우 최대 Pod 생성 개수는 ENI 수 x (ENI 당 지원하는 IPv4 수 - 1) + 2 라는 수식을 통해 계산할 수 있다.

ENI 별로 첫 번째 IP 주소는 Primary IP이기 때문에 제외하고 Node 별로 구성되는 aws-node와 kube-proxy Pod 2대를 포함하여 산정한다. 해당 Pod들은 Node의 Primary IP를 사용하기 때문에 카운팅되지 않는다.

이러한 최대 Pod 생성 수량에 대한 제약을 늘리기 위해 2021년 8월에 IP Prefix Delegation 방식이 추가되었다.

해당 방식의 원리는 ENI의 Slot에 하나의 IP가 아닌 /28의 IP Prefix 대역으로 구성하는 것이다. /28의 IP Prefix는 2의 4승으로 총 16개의 IP를 사용할 수 있는 대역이다. 그로 인해 계산식이 다음과 같이 변경되었다.

ENI 수 x (ENI 당 지원하는 IPv4 수 - 1) x 16

하지만 IP Prefix Delegation 방식은 Nitro System 계열의 인스턴스 유형에서만 사용이 가능하다. 또한 vCPU 30 코어 미만은 110개로 제한, 그 외에는 250개로 최대치가 정해져있다. 해당 방식을 사용하기 위해서는 kubectl 명령을 통해 활성화해야 한다.

[Network] TCP 프로토콜에 대한 이해

겨울바람_ — Tue, 23 Jul 2024 21:30:43 +0900

OSI 7 Layer

User Mode 레벨에서의 OSI 7계층은 각각 Application Layer, Presentation Layer, Session Layer가 존재한다. User Mode 레벨에서의 계층의 전송 단위는 Data로 표현되며, 호스트(PC 혹은 노트북)가 주요 장비라고 볼 수 있다.

Application Layer
- 사용자와 가장 밀접한 계층으로 인터페이스 역할
- 응용 프로세스 간의 정보 교환을 담당
- Protocol
  - HTTP
  - FTP
Presentation Layer
- 데이터 형식을 설정한다
- 송신자에게서 온 데이터를 해석하기 위한 Application Layer 데이터 부호화
- 수신자 측에서 데이터의 압축을 풀수 있는 방식으로 데이터 압축
- 데이터의 암호화 및 복호화
- Protocol
  - JPEG
  - MPEG
Session Layer
- 통신 장치 간 상호작용 및 동기화를 제공
- 연결 세션에서 데이터 교환과 에러 발생 시의 복구를 관리
- Protocol
  - RPC

Kernel Mode 레벨에서의 OSI 7계층은 각각 Tranport Layer와 Network Layer가 존재한다. Transport Layer의 전송 단위는 Segment이며, Network Layer의 전송 단위는 Packet이다. 각각 L4 스위치와 라우터가 주요 장비다.

Transport Layer
- 송수신 프로세스 간의 신뢰성 있고 정확한 데이터 전송을 담당
- 신뢰성 있는 데이터 전송을 위해 오류검출 및 복구, 흐름제어와 중복 검사 등을 수행
- 데이터 전송을 위해 Port 번호를 사용한다
- 주요 데이터 전송 단위는 Segment다
- Protocol
  - TCP
  - UDP
Network Layer
- 라우팅 기능을 담당하고 있으며 목적지까지의 최적화 된 경로를 제공
- 주요 데이터 전송 단위는 Packet이다
- Protocol
  - IP
  - ICMP

H/W 레벨에서의 OSI 7계층은 각각 Data Link Layer와 Physical Layer가 존재한다. Data Link Layer의 전송 단위는 Frame이다. 주요 장비로는 Data Link Layer는 브릿지와 스위치, Physical Layer는 허브, 리피터가 있다.

Data Link Layer
- 물리적인 연결을 통하여 인접한 두 장치 간의 신뢰성 있는 정보 전송을 담당
- MAC 주소를 통해서 통신
- 오류 제어, 흐름 제어, 회선 제어를 담당
- 주요 데이터 전송 단위는 Frame이다
- Protocol
  - HDLC
  - PPP
Physical Layer
- 주로 전기적, 기계적, 기능적인 특성을 이용해 데이터를 전송
- 데이터는 0과 1의 비트열, 즉 On, Off의 전기적 신호 상태로 이루어져 해당 계층은 단지 데이터를 전달
- 단지 데이터 전달의 역할을 할 뿐이라 알고리즘, 오류제어 기능이 없음
- Protocol
  - RS-232CSocketSession Layer에서 Transport Layer로 데이터가 전달될 때 Socket이라는 네트워크 통신 방식을 통해 전달된다.

Socket은 TCP와 같은 프로토콜을 User Mode Application Process에서 접근할 수 있도록 파일 형식으로 추상화한 인터페이스다.

Socket의 종류는 대표적으로 Stream Socket과 Datagram Socket 두 가지가 존재하는데, 이번 포스팅에서는 웹 서버에서 주로 사용하는 Stream Socket을 기반으로 설명하려고 한다.

참고로 Stream Socket은 양방향 통신으로 송신한 데이터가 실제로 도착했는지 즉각적으로 확인할 수 있기 때문에 높은 신뢰성을 보장한다. TCP 프로토콜을 사용하며 주로 웹 서버와 메일 서버 등에서 사용된다.

Datagram Socket은 단방향이며 수신 측에서 데이터를 순서대로 전달받을 수 있는 보장이 없고 패킷 손실이 발생할 수 있기 때문에 신뢰할 수 없다. 하지만 부하가 적고 가볍기 때문에 네트워크 게임 혹은 미디어 스트리밍에 주로 사용된다. Datagram Socket은 UDP 프로토콜을 사용한다.

Segmentation

Transport Layer는 Session Layer에서 전달된 Stream Socket을 일정 길이 단위로 분할하여 Transport Layer의 전송 단위인 Segment로 만드는데, 이러한 데이터 변형 과정을 Segmentation 이라고 한다.

Stream Socket의 경우 명확한 용량이 정해져 있지 않지만, Segment는 MSS(Maximum Segment Size)가 정해져있기 때문에 MSS 단위로 Stream을 분할한다. MSS의 경우 다음 계층인 Network Layer의 전송 단위인 Packet의 최대 전송 용량인 MTU(Maximum Transport Unit)의 영향을 받아 할당되는데, 일반적으로 1460bytes가 할당된다.

Packet

Packet은 Header와 Payload를 가진 구조로 되어있는데 특별한 이유로 변경하지 않는 이상 1500bytes로 고정되어 있다.

Packet의 Header에는 IP 헤더와 TCP 헤더가 각각 20bytes 씩 할당된다. 즉 헤더의 크기는 총 40bytes이며, 남은 Payload 부분이 1460bytes를 차지한다.

Transport Layer의 전송 단위인 Segment가 IP 헤더와 TCP 헤더로 Encapsulation된 형태를 Packet이라 지칭하기 때문에 위에서 언급했던 것처럼 Segment의 최대 크기인 MSS는 Packet의 Payload의 최대 용량인 1460bytes로 할당되는 것이다.

만약 Packet의 MTU 용량이 변화하여 Payload의 용량 또한 변한다면 Segment의 MSS 또한 Payload의 용량에 맞춰 변화한다.

TCP Transport

Packet은 다시 Encapsulation 되어 Frame에 감싸진채 수신 측으로 전달된다. TCP 프로토콜의 경우 이 송수신 과정에서 ACK를 통해 현재 송수신 진행 상태를 수신 측에서 송신 측으로 전달하게 되는데, ACK에는 Window Size라는 것이 포함되어 있다.

Window Size라는 것은 TCP Buffer의 현재 남아있는 용량을 의미한다. TCP Buffer에는 송신 측으로부터 전달받은 데이터가 Segment 단위로 저장되어 있다. 한 파일의 용량이 MSS보다 클 경우 여러 번에 걸쳐 데이터를 전송하게 되는데 이때 송신 측으로 전달받은 데이터를 임시로 보관하게 되는 곳이 TCP Buffer다.

TCP 프로토콜의 속도가 UDP에 비해 비교적 느린 이유가 이 ACK 때문이다. 수신 측 ACK에 담긴 Window Size가 만약 송신 측에서 전달하는 Segment의 MSS보다 작으면 Wait이 발생하게 되고 이로 인해 송수신이 지연되기 때문이다.

그림으로 이해하는 객체 지향 설계 5원칙 [SOLID]

겨울바람_ — Sat, 20 Jul 2024 20:06:29 +0900

SRP (Single Responsibility Principle): 단일 책임 원칙

"어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다."
- 로버트 C. 마틴

위의 그림과 같이 Man 클래스에 의존하고 있는 다양한 클래스들이 존재한다고 생각해 보자. 그림에서부터 확인이 가능하듯 Man 클래스에 부과된 역할과 책임이 너무 많기 때문에 남성의 표정이 그리 밝지 않다.

어느 날, 여자친구와 헤어질 경우 Man 클래스는 챙길 일 없는 기념일과 사랑한다고 말할 대상이 사라져 힘들어하게 된다. 거기다 여자친구와 결별한 영향이 부모님과 직장 상사에게 까지 영향이 미칠 수 있다. 이렇듯 한 클래스에 너무 많은 책임이 집중될 경우 발생할 수 있는 악영향과 관리의 어려움을 예방하기 위해 책임을 분리하라는 것이 단일 책임 원칙이다.

위의 그림에서 Man 클래스에 집중되어 있는 책임을 아래의 그림처럼 분리해보자.

Man 이라는 하나의 클래스가 역할과 책임에 따라 세 개의 클래스로 나누어진 것을 볼 수 있다. 만일 여자친구와 헤어져도 남자친구의 역할을 요구하지 않는 부모님과 직장 상사에게는 어떤 악영향도 주지 않는 구조가 만들어진 것이다.

위의 예시에서는 클래스의 분할에 대해서만 예를 들었지만 속성, 메소드, 패키지, 모듈, 컴포넌트, 프레임워크 등에도 적용할 수 있는 개념이다.

OCP (Open Closed Principle): 개방 폐쇄 원칙

"소프트웨어 엔티티는 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 한다."
- 로버트 C. 마틴

어느 날 한 운전자가 제네시스 G80을 구입했다. 수년 동안 제네시스 G80을 운전한 운전자는 돈을 더 모아 닷지 챌린저 SRT를 구입하게 된다. 창문과 기어 조작이 자동이던 제네시스 G80에서 창문과 기어 조작이 수동인 닷지 챌린저를 운전하려고 하니 운전자의 행동에 변화가 생긴다.

제네시스 G80을 운전할 때는 해당 차량 인스턴스의 창문자동개방() 메소드를 사용했는데 닷지 챌린저로 차종을 변경하자 닷지 챌린저 인스턴스의 창문수동개방() 메소드를 사용하게 된다.

현실 세계라면 차의 기종에 맞게 운전자가 행동을 다르게 하는 것이 올바른 방법이겠지만 객체 지향 원칙이 적용되는 프로그래밍 세계에서는 굳이 운전자가 기종 변경의 영향을 받을 필요는 없다.

위의 그림과 같이 상위 클래스 혹은 인터페이스를 중간에 두는 것으로 다양한 자동차가 생긴다고 해도 객체 지향 세계의 운전자는 영향을 받지 않게 된다.

여기서 다양한 자동차가 생긴다는 것을 자동차 입장에서는 자신의 확장에는 개방돼 있는 것이고, 운전자의 입장에서는 변화에 폐쇄돼 있는 것이다.

개방 폐쇄 원칙이 적용된 것들 중 자바 개발자가 자주 접했을 대표적인 예시가 바로 JDBC다. JDBC를 사용하는 클라이언트는 데이터베이스가 오라클에서 MySQL로 변경되더라도 Connection을 설정하는 부분 이외에는 수정할 필요가 없다.

JDBC뿐만 아니라 Hibernate, MyBatis, iBatis 등 데이터베이스 프로그래밍을 지원하는 다른 라이브러리와 프레임워크에도 개방 폐쇄 원칙이 적용되어 있다.

사실 개방 폐쇄 원칙을 따르지 않는다고 해서 객체 지향 프로그램을 구현하는 것이 불가능한 것은 아니다. 하지만 개방 폐쇄 원칙을 무시하고 프로그램을 작성하면 객체 지향 프로그래밍의 가장 큰 장점인 유연성, 재사용성, 유지보수성을 얻을 수 없다.

LSP (Liskov substitution Principle): 리스코프 치환 원칙

"서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다."
- 로버트 C. 마틴

객체 지향의 상속은 다음의 조건을 만족해야 한다.

1. 하위 클래스 is a kind of 상위 클래스

2. 구현 클래스 is able to 인터페이스

위 두 개의 문장대로 구현된 프로그램이라면 이미 리스코프 치환 원칙을 잘 지키고 있는 것이라 할 수 있다. 위의 문장대로 구현되지 않은 상속이 존재할 수 있을까?

만약 상속 관계를 조직도 혹은 계층도 형태로 구현할 경우 위 문장대로 구현되지 않은 상속이 발생하게 된다. 아래의 예시를 한 번 살펴보자.

위와 같은 가계도를 상속 관계라고 생각해보자. 최상위 클래스인 GrandFather 클래스가 존재하고 해당 클래스를 상속받는 Father와 Uncle 클래스가 존재한다.

이러한 형태의 상속 관계는 어째서 리스코프 치환 원칙을 잘 지키지 못하는 것일까?

상위 클래스의 객체 참조 변수에는 하위 클래스의 인스턴스를 할당할 수 있다. 즉, 상위 클래스인 Father 객체 참조 변수에는 하위 클래스인 Son 혹은 Daughter의 인스턴스를 할당할 수 있어야 한다.

간단한 코드로 표현하자면 다음과 같다.

Father 보영 = new Daughter();

굉장히 이상한 코드라는 생각이 든다. 보영이는 Father 클래스를 상속받고 있기 때문에 Father 객체가 가진 메소드를 가지고 있어야 한다. 그렇다면 어떤 경우가 올바른 형태의 상속 관계를 가져 리스코프 치환 원칙을 만족할 수 있을까?

바로 분류도 형태의 상속 관계가 이에 해당한다. 아래의 예시를 살펴보자.

최상위 Animal 클래스를 상속받는 Mammailia 클래스와 Birds 클래스가 존재한다. 보영이 때처럼 간단히 코드를 사용해 표현해보면 다음과 같다.

Mammaila 고래 = new Whale()

고래는 Mammailia 클래스의 메소드를 그대로 상속받아 사용해도 이상하지 않다.

결론적으로 계층도/조직도 형태의 구조는 리스코프 치환 원칙을 위배하고 있는 것이며, 분류도 형태의 구조는 리스코프 치환 원칙을 만족하는 것이다.

ISP (Interface Segregation Principle): 인터페이스 분리 원칙

"클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안 된다."
- 로버트 C. 마틴

ISP에 대한 설명 이전에, 단일 책임 원칙의 예제를 다시 기억해보자. 단일 책임 원칙을 적용하기 전 Man 클래스는 여러 책임과 역할을 가지고 있었지만, 단일 책임 원칙을 적용한 이후 각기 하나의 책임과 역할을 갖는 클래스로 나뉘었다.

하지만 Man 클래스를 나누지 않는 방법이 있다면 어떨까?

여자친구를 만날 때는 남자친구 역할만 할 수 있게 인터페이스로 제한하고, 부모님과 있을 때는 아들 역할만 할 수 있게 인터페이스로 제한하고, 직장 상사 앞에서는 사원 인터페이스로 제한하는 것이 바로 인터페이스 분리 원칙의 핵심이다.

결론적으로 SRP와 ISP는 같은 문제에 대한 두 가지 다른 해결책이라고 볼 수 있다. 프로젝트 요구사항과 설계자의 취향에 따라 단일 책임 원칙이나 인터페이스 분할 원칙 중 하나를 선택해서 설계할 수 있다. 하지만 특별한 경우가 아니라면 단일 책임 원칙을 적용하는 것이 더 좋은 해결책이라고 할 수 있다.

인터페이스 분할 원칙을 이야기할 때 항상 함께 등장하는 원칙 중 하나로 인터페이스 최소주의 원칙이라는 것이 있다. 인터페이스를 통해 메소드를 외부에 제공할 때는 그 역할에 충실한 최소한의 메소드만 제공하라는 것이다.

DIP (Dependency Inversion Principle): 의존 역전 원칙

"고차원 모듈은 저차원 모듈에 의존하면 안된다. 두 모듈 모두 다른 추상화된 것에 의존해야 한다."
"추상화된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화된 것에 의존해야 한다."
"자주 변경되는 구체 클래스에 의존하지 마라."
- 로버트 C. 마틴

이번 DIP 또한 예제를 통해 설명해보려고 한다. 우선 개방 폐쇄 원칙의 예시에서 사용한 자동차를 기억해낼 필요가 있다.

눈이 매우 많이 오는 날에 안전하게 운전을 하려면 스노우 타이어가 필요하다. 자동차가 스노우 타이어에 의존하는 것이다.

하지만 스노우타이어는 계절이 바뀌면 일반 타이어로 교체해야 한다. 스노우 타이어를 일반 타이어로 교체할 때 자동차는 보다 변경이 더 자주 발생하는 스노우 타이어라는 객체에 의존하고 있기 때문에 의도치 않게 영향을 받게 된다.

이 구조를 개선하려면 다음과 같이 자동차가 구체적인 타이어의 종류에 의존하는 것이 아닌 추상화된 타이어의 인터페이스에만 의존하게 하는 방식으로 구조를 변경해야 한다.

해당 구조는 스노우 타이어에서 일반 타이어로, 또는 다른 구체적인 타이어로 변경돼도 자동차는 그 영향을 받지 않는 형태로 구성된다.

위의 그림의 형태가 OCP에서 예시로 든 자동차의 구조도와 굉장히 유사하다는 것을 느낄 수 있다. OCP와 DIP는 객체 지향 4개 특성 중 상속과 다형성을 통해 구현되기 때문에 비슷한 형태를 띄는 것이다.

구조도가 변경되기 전 스노우 타이어와 변경된 후의 스노우 타이어에 큰 변화가 생겼다. 바로 스노우 타이어가 그 무엇에도 의존하지 않는 클래스였는데, 구조도가 변경된 이후의 스노우 타이어는 추상적인 타이어 인터페이스에 의존하게 됐다.

그리고 자동차는 변경되기 쉬운 스노우 타이어에 의존하던 관계를 추상화된 타이어 인터페이스를 추가해 두고 의존 관계를 역전시키고 있다.

이처럼 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변화로 인한 영향을 받지 않게 하는 것이 의존 관계 역전 원칙이다.

상위 클래스, 인터페이스, 추상 클래스일수록 변하지 않을 가능성이 높기에 하위 클래스나 구체 클래스가 아닌 상위 클래스, 인터페이스, 추상 클래스를 통해 의존하는 것이다.

[Jenkins] CI/CD 파이프라인 구축 중 .gitIgnore 처리된 Config 파일 관리

겨울바람_ — Fri, 19 Jul 2024 23:17:13 +0900

CI/CD Pipeline Architecture

개발자가 Github에 변경된 코드를 Push 하게 되면, 홈서버에 위치한 Jenkins로 HTTP POST 요청이 전달된다.

Jenkins에서는 해당 요청을 트리거로 지정된 Job을 수행하게 된다. 이번 프로젝트에서 설정한 Jenkins의 파이프라인은 Github의 Repository를 클론하여 해당 프로젝트의 이미지를 build 한 후 해당 이미지를 DockerHub로 Push 하는 것이다.

사용한 백엔드 프레임워크는 Spring Boot로 Gradle을 통해 bootJar된 jar 파일을 이미지화 시켜 DockerHub에 Push 하는 것이 주된 목표다.

Spring Boot & yaml file

Spring Boot의 경우 데이터베이스에 대한 정보, OAuth 사용을 위한 Key 값과 같이 노출을 피해야 하는 정보들을 application.yaml 혹은 application.properties 파일에 작성한다.

개발자들은 노출되서는 안되는 해당 파일들이 Github 같은 공용 저장소에 올라가지 않도록 주의해야 하는데, Git을 사용할 경우 .gitIgnore 파일을 통해 형상 관리의 범위에서 제외할 수 있다.

필자 또한 .gitIgnore 를 통해 application-local.yaml, application-oauth.yaml 파일을 관리하고 있었다. .gitIgnore에 지정한 파일들은 형상 관리의 범위에서 제외되기 때문에 Github에도 업로드 되지 않는다.

하지만 필자가 작성한 CI/CD 파이프라인은 Github의 리포지토리를 클론하여 동작하기 때문에 해당 파일들이 없다면 Spring Boot가 정상적으로 구동이 되지 않아 파이프라인이 실패하게 된다.

어떻게 해당 파일들을 공개된 저장소에 올리지 않으면서도 CI/CD 시에 적용할 수 있을까?

Jenkins Credentials

필자는 Jenkins에서 제공하는 Credentials에 각 파일을 등록하여, 파이프라인 스크립트 작성 시 변수로 불러와 사용하는 방법을 사용했다.

[Jenkins 관리] -> [Credentials] -> [Add Credentials] 를 통해 Credential을 생성할 수 있는 폼으로 이동할 수 있다.

위의 사진과 같이 파일 자체를 Credential로 등록할 때는 Kind를 Secret file로 선택하고 등록하고자 하는 파일을 지정하면 된다.

ID의 경우 파이프라인 스크립트에서 사용되기 때문에 명확하게 구분이 가능한 이름으로 지어주고, Description은 해당 Credential에 대한 간단한 설명글을 작성해두면 된다. 성공적으로 등록했다면 아래와 같이 Credentials 목록에서 확인이 가능하다.

이렇게 등록된 Credentials는 Jenkins의 파이프라인 스크립트를 통해 불러올 수 있다.

CI/CD Pipeline Script

이번 포스팅의 주요 목적은 Credentials로 등록된 config 파일을 파이프라인 스크립트에서 사용하는 것이기 때문에 이외의 스크립트에 대한 추가적인 설명은 진행하지 않는다.

...

stage('copy yaml') {
    steps {
        withCredentials([file(credentialsId: 'Animealth-Application-Local', variable: 'LOCAL_YAML'),
                        file(credentialsId: 'Animealth-Application-Oauth', variable: 'OAUTH_YAML')]) {
            script {
                sh 'cp $LOCAL_YAML /var/jenkins_home/workspace/Animealth_Backend/src/main/resources/application-local.yml'
                sh 'cp $OAUTH_YAML /var/jenkins_home/workspace/Animealth_Backend/src/main/resources/application-oauth.yml'
            }
        }

        echo 'copy yaml success!'
    }
}

...

위의 스크립트는 Docker 이미지를 빌드하기 전에 Credentials로 등록된 파일을 클론한 프로젝트 내부의 경로로 복사하는 스크립트다.

CredentialsId에는 아까전 등록한 Credential의 ID를 입력하고, variable에는 해당 스크립트에서 사용하게 될 Credential을 담게 될 변수명을 원하는대로 입력하면 된다.

아래의 sh 명령어는 $LOCAL_YAML 이라는 변수로 등록된 Animealth-Application-Local Credential을 /var/jenkins_home/workspace/Animealth_Backend/src/main/resources 경로에 위치한 application-local.yaml 파일로 내용을 복사하라는 의미다.

아래쪽의 sh 명령어 또한 동일한 의미의 명령어로 application-oauth.yaml에 대한 내용을 담고 있다.

성공적으로 copy yaml 스테이지가 종료되면 copy yaml success! 라는 문구를 콘솔에 출력한다.

Result

작성된 파이프라인을 통해 CI/CD를 진행하면 Jenkins의 Item Console Output을 통해 결과를 실시간으로 확인할 수 있다.

yaml 파일에 대한 Credentials 등록과 파이프라인 스크립트 작성이 잘 이루어졌다면, 아래와 같이 copy yaml success! 라는 문구가 콘솔에 출력되는 것을 확인할 수 있다.

Jenkins에서 제공하는 GUI를 통해 전체적인 파이프라인 공정이 성공적으로 수행된 것을 볼 수 있다.

[AWS] Elastic Block Storage (EBS)

겨울바람_ — Tue, 16 Jul 2024 21:15:47 +0900

Elastic Block Store

EC2 인스턴스에 사용할 영구 블록 스토리지 볼륨을 제공한다. 각 Amazon EBS 볼륨은 EC2와 동일한 가용 영역 내에 자동으로 복제되어 구성요소 장애로부터 부호해주고, 고가용성 및 내구성을 제공한다.

Amazon EBS 볼륨은 워크로드 실행에 필요한 지연 시간이 짧고 일관된 성능을 제공한다. Amazon EBS를 사용하면 몇 분 내에 사용량을 많게 또는 적게 확장할 수 있으며, 프로비저닝한 부분에 대해서만 저렴한 비용을 지불한다.

일종의 가상 하드디스크로 EC2와 EBS는 네트워크로 연결되어 있기 때문에 EC2 인스턴스가 종료되어도 계속 유지가 가능하다. EC2 스케일업 시에도 EBS를 종료하지 않고 EC2만 스케일업할 수 있다.

루트 볼륨으로 사용시에는 EC2가 종료될 때 함께 삭제된다. 단 설정을 통해 EBS만 따로 존속 가능하다.

총 5가지 타입을 제공한다.

범용 : SSD
프로비저닝 된 IOPS : SSD
Throughput 최적화
콜드 HDD
마그네틱

IOPS 수치가 높을수록 데이터 통신이 빠르다.

Snapshot

특정 시간대의 EBS 상태 저장본으로 필요시 스냅샷을 통해 특정 시간의 EBS를 복구할 수 있다. S3에 변화된 부분만을 저장하는 증분식으로 저장한다.

AMI

EC2 인스턴스를 실행하기 위해 필요한 정보를 모아둔 단위로 OS, 아키텍처 타입, 저장공간 용량 등이 AMI를 통해 구성된다.

스냅샷을 통하여 AMI 구성이 가능하기 때문에 AMI를 사용하여 EC2를 복제하거나 다른 리전, 계정으로 전달이 가능하다.

AMI는 총 두 가지 타입이 존재한다.

인스턴스 저장 기반
- EC2안에 storage가 들어있음 (네트워크 연결X)
- 속도가 빠름
- 안에 들어있는 형태이니, 인스턴스가 삭제되면 스토리지도 같이 삭제 됨
- EBS처럼 스토어를 분리해서 다른 인스턴스에 연결 불가능
- 보통 영구적이지 않은 데이터를 저장
  ex) 캐시 데이터
- S3에 저장된 템플릿을 기반으로 생성
EBS 기반
- EC2가 EBS와 네트워크로 연결
- 속도가 느림
- 인스턴스가 삭제되더라도 EBS는 남아있음
- 하나의 인스턴스에 연결한 EBS 볼륨을 따로 분리해서 다른 인스턴스에 연결 가능
- 스냅샷을 기반으로 루트 디바이스 생성

AMI 생성 방법

[AWS] Slack을 사용해서 EC2 인스턴스 조작하기

겨울바람_ — Mon, 15 Jul 2024 18:38:45 +0900

이번 포스팅에서는 AWS Chatbot을 활용하여 Slack을 통해 EC2 인스턴스의 상태를 중지/실행으로 변경해고자 한다.

AWS Chatbot

AWS Chatbot은 Microsoft Teams 및 Slack 채널을 통해 AWS 리소스를 쉽게 모니터링하고 상호 작용하도록 지원하는 대화형 에이전트다. AWS Chatbot을 활용하면 알림을 수신하고 명령을 통해 진단 정보를 반환하고, AWS Lambda 함수를 호출하고 AWS Support 케이스를 생성하여 팀이 더 빠르게 협업하고 이벤트에 대응할 수 있다.

AWS Chatbot은 별도의 요금이 존재하지 않는다. 대신 AWS Chatbot 없이 사용하는 것과 동일한 방식으로 사용하는 기본 서비스(예: Amazon Simple Notification Service, Amazon CloudWatch, Amazon GuardDuty, AWS Security Hub)에 대해서만 비용을 지불한다.

본 포스팅에서 사용되는 AWS 리소스는 AWS Chatbot과 EC2, IAM이기 때문에 프리티어 사용 시 발생 비용은 존재하지 않는다.

EC2 생성

우선 이번 포스팅에서 사용할 EC2 인스턴스를 생성한다. 본 포스팅에서 EC2가 메인이 아니고, EC2에서 추가적으로 수행해야 하는 사항은 없기 때문에 EC2 생성 부분은 각자가 원하는 방식대로 자유롭게 생성하면 된다.

마찬가지로 OS 또한 본 포스팅에서 크게 중요한 부분이 아니기 때문에 아무 OS나 택해도 크게 관계없다. 필자는 가장 친숙한 Ubuntu AMI를 선택했다.

실행 및 중지 테스트를 위한 EC2 인스턴스기 때문에, 보안 그룹은 내 IP에서만 접속을 허용해준다. 인스턴스 유형과 스토리지 또한 프리티어를 사용한다.

EC2가 정상적으로 동작하는 것을 확인한 후, Slack과 AWS를 연동하기 위해 AWS Chatbot을 생성한다.

AWS Chatbot과 연결할 클라이언트를 지정해주자. 필자는 이번 포스팅에서는 Slack과 연동하여 사용할 예정이기 때문에 Slack으로 지정했다.

클라이언트 구성 버튼을 누르면, Slack의 워크스페이스와 연동할 수 있는 페이지가 보인다. 만약 연동 가능한 워크스페이스가 존재하지 않다면 새로운 Slack 워크스페이스를 생성하자.

필자는 AWS 관리를 위한 워크스페이스를 새롭게 생성했다.

워크스페이스를 새롭게 만든 후, 다시 AWS Chatbot의 Slack 연동 페이지를 살펴보면 새롭게 만들어진 워크스페이스와 연동이 가능해진 것을 확인할 수 있다.

허용 버튼을 누르면 다음과 같이 해당 워크스페이스와 연동된 AWS Chatbot의 화면을 확인할 수 있다.

다음은 EC2에 접근할 수 있는 IAM을 만들어 챗봇에 부여해보자. 우선 챗봇에 부여할 역할을 생성한다. 역할 생성 버튼을 누르고 AWS 서비스 중 AWS Chatbot에 적용되는 사용 사례를 선택한다.

이번 포스팅의 목적은 챗봇을 활용하여 EC2 인스턴스를 관리하는 것이기 때문에, Amazon EC2 FullAccess 권한을 챗봇에 부여한다.

다음 버튼을 클릭한 후 해당 역할에 이름과 설명을 적절하게 부여하자. 태그의 경우 선택사항이기 때문에 이번 포스팅에서는 추가하지 않았다.

역할 이름과 설명을 부여한 후 생성 버튼을 클릭하면 다음과 같이 역할이 잘 생성된 것을 확인할 수 있을 것이다.

다음은 가드레일을 위한 정책을 부여할 차례다. 정책 생성 버튼을 누른 뒤, 서비스로는 EC2를 선택한다. 본 포스팅의 목적에 부합하는 EC2 인스턴스를 시작, 정지할 수 있는 정책만 허용한다.

이후 다음 버튼을 누르고 마찬가지로 이름과 설명을 적절히 부여하면 성공적으로 가드레일 정책이 생성된다.

이제 만들어진 역할과 정책을 부여한 챗봇 채널을 생성해보자. 채널 생성 과정은 AWS Chatbot과 Slack 워크스페이스의 채널을 연결하는 작업이다. 다시 AWS Chatbot 페이지로 돌아가 새 채널 생성 버튼을 클릭하자.

AWS Chatbot 또한 CloudWatch와의 연동을 통해 로그를 관리할 수 있다. 필요에 따라 해당 옵션을 활성화하면 된다.

채널에 대한 이름을 정해주고 스크롤을 아래로 내리면 연동하고자 하는 Slack 채널에 대한 ID를 입력하는 폼이 나온다. 각자 생성한 혹은 이미 존재하고 있는 워크스페이스의 채널 ID와 채널 유형을 각각 입력하면 된다.

참고로 채널 ID의 경우, 브라우저 사용 시에는 URL 맨 뒷자리에서 확인이 가능하며, 데스크톱 앱을 사용할 경우 채널의 설정 부분에서 확인할 수 있다.

슬랙 주소의 맨 끝부분이 해당 채널의 ID다

다음은 채널에 역할과 정책을 부여할 차례다. 위에서 생성한 역할과 가드레일 정책을 부여하자.

알림의 경우 특정 상황에서 발생되는 여러가지 이벤트를 Slack 챗봇을 통해 받고 싶을 때 사용하면 된다. 여기까지 설정이 완료됐다면 구성 버튼을 눌러 채널 생성을 완료하면 된다.

채널을 생성했다고 곧장 AWS와 Slack을 연동해서 사용할 수 있는 것은 아니다. AWS 기능을 Slack을 통해 사용하기 위해서는 챗봇과 연동한 Slack 채널에 AWS Chatbot을 초대해야 한다.

해당 채널의 메시지 입력란에 /invite @aws 라는 메시지를 입력한 후 전송하는 것으로 AWS Chatbot을 해당 채널에 초대할 수 있다.

AWS SNS를 통해 알림 설정을 등록했다면 테스트 메시지 전송을 통해 AWS Chatbot이 잘 등록됐는지 확인할 수 있다. 만약 설정하지 않았더라도 챗봇을 사용하는데 큰 문제는 없다.

이제 Slack에 등록된 AWS Chatbot을 통해 처음 만들어두었던 EC2 인스턴스를 중지시켜보자. 우선 생성해둔 EC2 인스턴스의 ID를 복사한 뒤, Slack의 메시지 입력란에 다음과 같이 입력해보자.

@aws ec2 stop-instances --instance-ids {EC2 Instance ID} --region {Region}

이때 주의할 점은 인스턴스 ID를 링크 상태로 복사하면 안된다. 순수한 문자열인 인스턴스 ID를 복사하도록 하자. 인스턴스 상세 페이지에서 복사 버튼을 클릭하는 방법을 권장한다.

해당 메시지를 전송하게 되면 아래의 사진과 같이 스레드가 생성되고 AWS Chatbot이 성공적으로 명령어를 인식했다는 Reply를 확인할 수 있다. 해당 Reply는 명령어를 실행했다는 Reply가 아닌 명령 수행 전 최종 확인을 위한 것이다.

Reply의 [Run] command 를 클릭해야 AWS Chatbot이 입력한 명령어를 수행한다.

성공적으로 수행했다는 챗봇의 Reply를 다음과 같이 확인할 수 있다.

AWS EC2 페이지에 들어가 직접 EC2의 상태를 확인해보면 실행에서 중지 중 상태로 변환된 것을 확인할 수 있다.

중지된 인스턴스를 다시 실행시키고 싶다면

@aws ec2 start-instances --instance-ids {EC2 Instance ID} --region {Region}

명령어를 통해 인스턴스를 실행 상태로 변경할 수 있다.

[AWS] Elastic Network Interface (ENI)

겨울바람_ — Sat, 13 Jul 2024 22:24:43 +0900

Elastic Network Interface

탄련적 네트워크 인터페이스는 VPC에서 가상 네트워크 카드를 나타내는 논리적 네트워킹 구성 요소다. EC2의 IP주소와 Mac 주소를 보유하고 있다.

EC2는 반드시 하나 이상의 ENI가 연결되어 있으며, EC2 최초 생성시 Primary ENI가 생성되어 연결된다. 사용자의 필요에 따라 한 개의 EC2에 여러 개의 ENI를 연결시킬 수 있다. 추가된 ENI의 경우 EC2와 동일한 가용영역이라면 다른 서브넷에도 설정이 가능하다.

하나의 ENI에 Private IP와 하나의 Public IP로 구성되어 있는데, Public IP의 경우 사용자의 선택에 따라 설정하지 않을 수도 있다. 또한 필요에 따라서 한 개 이상의 Private IP를 부여할 수 있다.

실질적으로 EC2의 서브넷 위치, 보안그룹 등 외부와 관련된 연결은 ENI 단위에서 결정된다. 사용자 입장에서는 서브넷 내부에 EC2를 위치시킨다고 생각할수도 있지만, 사실 EC2는 가용영역 단위에 존재하며 해당 EC2에 연결된 Primary ENI가 서브넷에 위치하는 것이다.

EC2 자체가 가용영역 단위이기 때문에, 동일한 가용영역에 위치한 서브넷에는 ENI를 여러개 연결할 수 있지만, 다른 가용영역은 불가능하다.

ENI & Security Group

보안그룹 적용은 ENI 단위기 때문에 하나의 EC2 인스턴스에 다양한 보안그룹으로 구성된 경로를 적용할 수 있다.

예를 들어 서브넷 A에서는 80번 포트만 허용하여 고객으로 하여금 웹서버를 통해 접근이 가능하도록 할 수 있고 서브넷 B에서는 22번 포트만 허용하여 SSH 연결로 인스턴스를 관리할 수 있도록 설정이 가능하다는 것이다.

참고로 NACL의 경우 서브넷 단위이기 때문에 보안그룹과는 상이하다.

EC2의 Public IP

EC2의 Public IP는 ENI가 아닌 Public IP와 Private IP를 중계하는 가상의 라우팅 테이블을 통해 관리된다. 예를 들어 특정 Public IP로 요청이 들어왔을 때 가상 라우팅 테이블을 통해 매핑되어 있는 Private IP 주소의 ENI로 요청을 전달하는 것이다.

해당 Public IP, Private IP 매핑 레코드는 Elastic IP를 사용해 고정하지 않는 이상 영구적인 레코드가 아니다. 이 때문에 EC2 중지 혹은 재부팅 시 Public IP가 변경되는 반면, Private IP는 변경되지 않는 것이다.

인터넷에서 Public IP로 요청이 전달되면 IGW가 해당 라우팅 테이블을 통해 Private IP로 변환 후 전달한다. 이 때문에 EC2 인스턴스의 OS에서는 할당된 Public IP를 절대 알 수 없다.

EC2 생성 시점에 만들어지는 Primary ENI가 아닌 별도의 ENI에 Public IP를 부여하기 위해서는 Elastic IP가 필요하다.

Source / Destination Check

ENI는 기본적으로 자신이 발생시켰거나, 대상이 아닌 트래픽은 무시한다. 단, 설정에 따라서 해제가 가능하다.

NAT 인스턴스 등 자신을 위한 트래픽이 아닌 다른 대상에게 중계해주는 경우 해당 설정을 해제할 필요가 있다.

[k8s] etcd & Raft Alogorithm (2)

겨울바람_ — Fri, 12 Jul 2024 18:09:30 +0900

Runtime Reconfiguration

etcd 클러스터가 동작 중일 때, etcd 서버를 추가/삭제하는 것을 런타임 재구성이라고 한다.

Member Add

3개의 서버로 구성된 etcd 클러스터의 lastIndex가 10101이라고 가정해보자. etcd에는 Snapshot 이라는 개념이 있는데, etcd 서버가 현재까지 받아들인 모든 log를 Entry에서만 관리하는 것이 아니라 파일 시스템에 백업해두는 것을 의미한다.

Snapshot 실행 빈도는 etcd 클러스터를 생성하면서 옵션으로 설정할 수 있고, 디폴트 값은 100,000이다. 이러한 상황에서 4번째 서버를 추가하는 요청이 발생했다고 가정해보자.

etcd는 이러한 구성의 변경을 log append와 동일한 메커니즘으로 처리한다. Leader는 사용자로부터 전달받은 재구성 요청에 따라 새로운 구성에 해당하는 Cnew를 log Entry에 추가하고 Append RPC call을 이용해 다른 서버에 전파한다.

일반적인 Log Replication과 다른 점이 있다면, 이 구성에 대한 요청은 commit 된 이후에 효력을 발휘하는 것이 아니라 Entry에 write 되자마자 곧장 효력을 발휘한다는 것이다. 만약 구성과 관련된 로그가 Entry 내에 여러 개 존재한다면 가장 최신의 로그를 사용하게 된다.

또한, Log Entry에 write 되자마자 곧장 효력을 발휘하기 때문에 Log Entry에 존재하는 Cnew를 commit 하기 위해 필요한 정족수는 3 (4/2 + 1)으로 증거된다.

서버 추가를 요청한 클라이언트에게 응답을 한 이후, Leader는 추가된 멤버가 가능한 빨리 동일한 log를 보유할 수 있도록 Snapshot을 보내준다. 해당 Snapshot은 파일 시스템에 저장되어 있는 것들 중 가장 최신의 것과 Leader의 현재 Log Entry를 합쳐 생성된다.

새롭게 추가된 서버는 해당 Snapshot을 이용해 DB를 만드는 것으로 Append RPC call을 정상적으로 받아들일 수 있게 된다.

Member Add Risk

만약 새롭게 추가된 4번째 서버가 새롭게 구성되고 있을 때, 새로운 서버 추가 요청이 한 번 더 들어온다면 어떻게 될까?

우선, 새롭게 서버 추가 요청이 Leader의 Log Entry에 저장된다. 정족수는 3 (5 / 2 + 1) 에서 증가되지 않지만, 만약 다른 서버에서 해당 요청 로그를 복제받는 것에 지연이 생긴다면 새롭게 들어온 서버 추가 요청이 지연이 commit 되는 것 또한 지연된다.

이러한 상황에서 추가적인 write 요청이 들어오게 된다면, 해당 요청 또한 block이 되고 클라이언트의 Timeout 시간 동안 해당 요청을 처리하지 못하면 가용성에 문제가 생기게 된다.

Raft 알고리즘은 이러한 문제를 해결하기 위해 Leader, Follower, Candidate 외에 Learner 상태가 존재한다. Learner는 etcd 클러스터의 멤버이지만, 정족수 카운트에서는 제외되는 특별한 상태로 etcd 3.4.0부터 구현됐다.

Learner는 etcd의 promote API를 사용하여 일반적인 Follower로 변경할 수 있다. Learner가 아직 log를 모두 따라잡지 못한 경우에는 거절된다.

Kubeadm, Kubespray와 같이 널리 쓰이는 Kubernetes 설치 자동화 도구는 etcd 클러스터 생성 시 Learner의 개념을 활용하고 있지는 않다. Kubernetes에서 사용하는 etcd 클러스터의 Snapshot은 평균적으로 크기가 수십 Kb에 불과하기 때문에 이러한 이슈가 발생할 가능성은 낮다.

또한 이러한 일을 방지하기 위해 Raft 알고리즘에서는 런타임 재구성은 한 번에 하나씩 처리할 것을 원칙으로 하고 있으며, etcd에서는 restriction을 설정하여 Leader의 log에 commit 되지 않은 구성 요청이 있다면 새로운 구성 요청을 받지 않는다.

Remove Leader

etcd 클러스터에서 특정 서버를 삭제하라는 요청 또한 etcd 서버 추가와 동일한 방식으로 진행된다. 하지만 삭제 대상이 Leader일 경우, Leader는 Leader 삭제에 대한 구성 요청을 commit 시키는데 필요한 로그 복제에 대한 정족수를 셈할 때 자기 자신을 제외한다.

Leader를 제외한만큼의 정족수가 확보되면 Leader 삭제에 대한 내용이 존재하는 로그를 commit 하고 해당 요청을 보낸 클라이언트에게 응답을 보낸다. commit 이후 Leader 상태에서 빠져나오게 되고 더 이상 다른 서버에 Heartbeat를 보내지 않게 된다. 이것을 Raft와 etcd에서는 step down 이라고 표현한다.

Leader가 클라이언트의 삭제 요청을 처리할 때 정족수에서 자기 자신을 제외하였기 때문에, 새로운 Leader의 선출이 가능해진다.

만약 step down 이 발생하기 전에 write 요청이 들어온다면 어떻게 될까?

구성 요청은 Entry에 들어가자마자 효력을 발휘하지만, Leader 삭제 요청의 경우 Entry에 존재하는 가장 최신의 구성 로그에 자신이 없더라도 Leader 역할을 수행한다.

예를 들어, 아직 삭제 요청이 commit 되기 이전에 write 요청이 들어온다면 Leader는 자기 자신을 제외한 정족수만큼 로그 복제를 수행한다.

Member Remove Restriction

Leader는 정족수와 현재 정상 동작 중인 서버의 수를 비교하여 현재 정상 동작 중인 서버 수가 정족수보다 낮아질 것으로 예상되면 클라이언트의 멤버 삭제 요청을 거절한다.

[AWS] Elastic Load Balancer

겨울바람_ — Thu, 11 Jul 2024 22:57:15 +0900

ELB?

다수의 서비스에 트래픽을 분산시켜주는 서비스이며, 직접 트래픽을 발생시켜 인스턴스가 살아있는지 체크한다. 여러 가용영역에 분산이 가능하기 때문에 애플리케이션 가용성을 향상시키고 HTTP, HTTPS, TCP, SSL, gRPC 등 다양한 프로토콜을 지원한다.

또한, AWS의 CloudWatch 기능을 이용하여 로그와 메트릭을 모니터링할 수 있으며, Auto Scaling 기능과 결합하여 트래픽이 증가할 때 자동으로 인스턴스를 추가하거나 제거하면서 애플리케이션 가용성을 유지한다.

지속적으로 IP가 변경되기 때문에 도메인 기반으로 사용하는 것이 편리하다.

대표적으로 4가지 종류가 존재한다.

Application Load Balancer (ALB)
Network Load Balancer (NLB)
~~Classic Load Balancer (CLB)~~ 현재는 잘 사용되지 않는다
Gateway Load Balancer (GWLB)

각 CLB를 제외한 각각의 ELB를 살펴보기 전에 AWS ELB의 구성 요소에 대해 먼저 알아보자

ELB 구성 요소

Load Balancer

여러 대의 EC2 인스턴스, IP주소, 람다 등을 사용하여 트래픽을 대상 그룹에 있는 인스턴스로 분산시켜 애플리케이션의 가용성을 유지하는 역할을 한다. 로드 밸런서는 사용자 요청을 받아 애플리케이션 서버로 전달하고, 애플리케이션 서버의 응답을 사용자에게 반환한다.

Listener

로드 밸런서에서 사용할 포트와 프로토콜을 설정하는 구성 요소로, 로드 m 밸런 서에서 클라이언트 요청을 수신하고, 해당 요청을 처리할 대상 그룹을 선택하는 역할을 한다.

리스너는 로드 밸런서에 연결된 프로토콜과 포트를 사용하여 클라이언트 요청을 수신하고, 해당 요청을 대상 그룹으로 라우팅한다.

Target Group

로드 밸런서에서 분산할 대상의 잡합을 정의하는 구성 요소. 대상 그룹의 인스턴스에 대해 정적 또는 동적으로 구성할 수 있으며, 라우팅 규칙에 따라 요청을 받아들일 대상 그룹을 선택한다.

로드 밸런서는 대상 그룹에 포함된 대상들의 상태를 정기적으로 확인하여 장애 발생 대상을 자동으로 제외하고, 정상적으로 동작하는 대상에만 요청을 전달한다.

ELB의 동작 방식

로드 밸런서에서 클라이언트 요청을 수신하면, 로드 밸런서는 클라이언트와 연결을 유지하며, 요청을 수신하기 위해 리스너를 등록한다.

수신한 클라이언트 요청을 처리할 대상 그룹을 선택한다. 대상 그룹은 인스턴스, IP 주소, 람다, ALB 등 여러 유형의 대상으로 구성된다.

선택된 대상 그룹에서 요청을 처리할 대상을 선택하고 해당 대상으로 요청을 분산한다. 이때 로드 밸런서는 각 대상의 가용성 상태를 모니터링하고 가용하지 않은 대상을 제외한다.

분산된 요청을 대상에서 처리하고 클라이언트에 응답을 반환한다. 이때 응답은 로드 밸런서에서 수신한 것으로 반한된다.

Cross-zone Load Balancing

ELB는 여러 가용 영역에서 로드 밸런서 노드를 실행하며, 각 노드는 가용 영역 내 대상 그룹으로 요청을 분산한다. 이때 대상 그룹에 등록된 대상이 여러 가용 영역에 걸쳐 있다면 기본적으로 로드 밸랜서는 동일한 비중으로 가용 영역 내에 있는 대상으로 트래픽을 분산한다.

하지만 가용 영역 내 인스턴스 수량이 불균형할 때는 일부 인스턴스로 트래픽이 몰리고 다른 인스턴스는 유휴 상태가 되는 불균형 문제가 발생할 수 있다.

이런 불균형 문제를 해결하는데 ELB 교차 영역 로드 밸런싱을 활용할 수 있다. 교차 영역 로드 밸런싱은 여러 가용 영역에 걸쳐 있는 EC2 인스턴스나 컨테이너 등 대상을 더 효과적으로 로드 밸런싱하는 기능이다.

이런 교차 영역 로드 밸런싱은 가용 영역별로 인스턴스 수량이 불균형하게 위치할 때 트래픽 비중을 보정할 수 있으며, 트래픽을 분산하는 기준이 가용 영역이 아닌 대상 그룹에 속한 자원을 기준으로 균일한 비중의 로드 밸런싱을 수행할 수 있다.

ALB 사용 시 기본적으로 활성화되어 있으나, NLB는 비활성화되어 있다. 또한, 교차 영역 로드 밸런싱은 대상 그룹 수준에서 구성할 수 있으므로 필요에 따라 각 대상 그룹 별로 별도로 구성할 수 있다.

단, 사용할 때 가용 영역 간 통신 비용이 발생할 수 있다.

ALB

ALB는 AWS에서 제공하는 L7 로드 밸런서로, HTTP/HTTPS 같은 웹 애플리케이션 프로토콜을 지원한다. ALB는 대상 그룹 단위로 트래픽을 분산하며, 각 대상 그룹은 ALB가 요청을 전달할 대상으로 라우팅하는 기능을 제공한다.

ALB 특징

- HTTP 헤더를 확인하여 다양한 라우팅 기능을 제공한다
- 경로 기반 라우팅
- 호스트 기반 라우팅
- 쿼리 문자열 기반 라우팅
- Auto Scailing과 함께 사용하여 확장성 있는 애플리케이션을 구성할 수 있다
- 대상 그룹 내 인스턴스에 대해 상태 검사를 수행하고, 문제가 발생하면 자동으로 장애 조치를 취할 수 있다
- Amazon CloudWatch와 통합되어 로그 및 지표 데이터를 수집하고 모니터링 및 분석이 가능하다

NLB

NLB는 AWS에서 제공하는 L4 로드 밸런서로, TCP/UDP/TLS 프로토콜을 지원한다. ALB와는 달리, 클라이언트와 로드 밸런서 간 연결을 TCP 레벨에서 유지하므로 대규모 트래픽을 처리할 수 있다.

동일한 IP 주소에서 여러 대상 그룹을 지원할 수 있다.

NLB 특징

- 높은 처리량
- 빠른 응답 시간
- 높은 가용성 : 여러 가용 영역에서 인스턴스를 실행하고 매우 빠른 인스턴스 검색을 수행하여 신속한 장애 복구가 가능
- IP 주소 보존 : 클라이언트 IP 주소를 원래 IP 주소로 보존할 수 있다. 이는 클라이언트 IP 주소를 유지하며 로드 밸런싱을 수행할 수 있다는 것을 의미한다
- 모니터링

GWLB

주로 가상 어플라이언스 배포/확장 관리를 위해 사용된다. 통상적으로 네트워크 트래픽을 서드 파티의 방화벽/어플라이언스 장비로 부하분산 처리하는 로드 밸런서다.

GWLB는 VPC 내에서 실행되는 애플리케이션의 가용성과 확장성을 향상시키는데 사용되며, TCP 및 UDP 프로토콜을 지원하여 다양한 유형의 애플리케이션에 유연하게 적용할 수 있다.

[k8s] etcd & Raft Algorithm (1)

겨울바람_ — Wed, 10 Jul 2024 22:58:00 +0900

etcd

쿠버네티스는 기반 스토리지(backing storage)로 etcd를 사용하고 있고, 모든 데이터가 etcd에 보관된다. 예를 들어, 쿠버네티스 클러스터에 노드가 몇 개 있고, 어떤 Pod가 어떤 노드에서 동작하고 있는지 등이 etcd에 기록된다.

etcd는 위와 이러한 정보를 key-value 형태로 저장한다. 만약 etcd가 다운되게 되면 쿠버네티스 클러스터는 제대로 동작하지 못하게 되기 때문에 높은 신뢰성을 제공해야 한다.

etcd는 Replicated State Machine(RSM)이다.

RSM은 서버들을 복사하고 복제된 서버와 클라이언트 간의 상호적용을 조율하는 것으로 장애 허용 서비스를 구현하는 일반적인 방법이다. RSM은 여러 노드에 동일한 상태 머신(State Machine)을 복제하여, 클라이언트 요청이 어떤 노드로 전달되든 동일한 결과를 얻게 한다. 이를 통해 시스템의 가용성과 내결함성을 높일 수 있다.

RSM은 command가 들어있는 log 단위로 데이터를 처리한다. 데이터의 write를 log append라고 부르며, Machine은 받은 log를 순서대로 처리한다. 하지만, 동일한 데이터를 여러 서버에 복제하기 때문에 발생하는 문제점 또한 존재한다.

안정적인 RSM을 구축하기 위해서는 데이터 복제 과정에서 발생할 수 있는 여러 가지 문제점을 해결하기 위해 컨센서스를 확보해야 한다. 컨센서스를 확보한다는 것은 RSM이 아래의 네 가지 속성을 만족한다는 것이다.

속성	설명
Safety	항상 올바른 결과를 리턴해야 합니다.
Available	서버가 몇 대 다운되더라도 항상 응답해야 합니다.
Independent from timing	네트워크 지연이 발생해도 로그의 일관성이 깨져서는 안됩니다.
Reactivity	모든 서버에 복제되지 않았더라도 조건을 만족하면 빠르게 요청에 응답해야 합니다.

쿠버네티스의 Control Plane Component인 etcd는 컨센서스를 확보하기 위해 Raft 알고리즘을 사용했다.

Raft Algorithm

Raft 알고리즘은 합의 알고리즘의 일종으로 여러 노드가 네트워크 지연, 노드 실패 등의 상황에서도 일관된 결정을 내릴 수 있도록 한다.

Raft 알고리즘을 설명하기 전에 기본적인 용어 3가지를 알아야 한다.

Quorum

Quorum이란 정족수, 라는 의미를 가지며 의사결정에 필요한 최소한의 서버 수를 의미한다. 예를 들어 RSM을 구성하는 서버의 숫자가 3대인 경우 Quorum 값은 2가 된다. etcd는 write 요청을 받았을 때, Quorum 숫자만큼의 서버에 데이터 복제가 발생하면 작업이 완료된 것으로 간주하고 다음 작업을 받아들일 수 있는 상태가 된다.

State

Etcd를 구성하는 서버는 State를 가지며 이는 Leader, Follower, Candidate 중 하나가 된다.

Timer

etcd의 Leader 서버는 다른 모든 서버에게 Heartbeat를 주기적으로 전송하여, Leader가 존재함을 알린다. 만약 Leader가 아닌 서버들이 일정 시간(Election Timeout) 동안 Heartbeat를 받지 못하게 되면 Leader가 없어졌다고 간주하고 다음 리더를 선출한다.

Leader Election

3개의 서버를 이용하여 etcd 클러스터를 구성했을 때, 각 서버는 Follower 상태이며 Term 값을 0으로 설정하고 동작을 시작한다.

최초로 초기화된 etcd 클러스터는 Leader가 존재하지 않기 때문에 누구도 Heartbeat를 보내지 않는다. 따라서 etcd 서버 중 한대에서 Election Timeout이 발생하게 되고, Timeout이 발생한 etcd 서버가 자신의 상태를 Candidate로 변경하고 Term을 1 증가 시킨다.

Candidate가 된 etcd 서버는 클러스터 내에 존재하는 다른 서버에 RequestVote RPC call을 보낸다. RequestVote RPC call을 받은 각 서버는 자신이 가진 Term 정보와 log를 비교하여 Candidate보다 자신의 것이 크다면 거절한다.

하지만 초기에는 Candidate의 Term 정보가 더 크기 때문에 해당 요청을 수락한다. Candidate 서버는 자기 자신을 포함하여 다른 서버로부터 받은 수락 응답이 Quorum과 동일하면 Leader로 선출된다.

Leader가 된 서버는 클러스터의 다른 서버에게 Heartbeat를 보내는데, 이 Append RPC call에는 Leader의 Term과 보유한 log index 정보가 들어있다.

Leader가 아닌 서버는 Append RPC call을 받았을 때 자신의 Term보다 높은 Term을 가진 서버의 call 인지 확인하고, 자신의 Term을 받은 Term 값으로 업데이트한다.

Log Replication

각 서버는 자신이 가지고 있는 log의 lastIndex 값을 가지고 있으며 Leader는 여기에 추가로 Follower가 새로운 log를 써야 할 nextIndex를 알고 있다. 사용자로부터 log append 요청을 받은 Leader는 자신의 lastIndex 다음 위치에 로그를 기록하고 lastIndex 값을 증가시킨다.

그리고 다음 Heartbeat Interval이 도래하면 모든 서버에게 AppendEntry RPC call을 보내면서, Follower의 nextIndex에 해당하는 log를 함께 보낸다.

첫 번째 Follower(이하 F1)는 자신의 Entry(메모리)에 Leader로부터 받은 log를 기록했고 두 번째 Follower(이하 F2)는 아직 기록하지 못했다고 가정해보자.

F1은 log를 잘 받았다는 응답을 Leader에게 보내주게 되고, Leader는 F1의 nextIndex를 업데이트한다. F2가 아직 응답을 주지 않았지만, 자기 자신을 포함해서 Quorum 숫자만큼의 Log Replication이 일어났기 때문에 commit을 수행한다.

commit이란, log entry에 먼저 기록된 데이터를 서버마다 가지고 있는 db(파일시스템)에 write 하는 것을 의미한다. 만약 commit된 데이터가 x = 1이라는 데이터일 경우, 사용자가 etcd 클러스터에서 x를 read하면 1이 return 된다.

Follower들은 Leader가 특정 로그를 commit한 사실을 알게 되면, 각 서버의 Entry에 보관 중이던 log를 commit 합니다.

Leader Down

사용자의 write 요청에 따라 Quorum 숫자만큼 log의 복제와 commit이 완료된 이후, Leader가 다운된다면 etcd는 어떻게 동작할지 알아보자. Log Replication에서 다룬 상황 이후에 Leader 서버의 etcd 프로세스가 알 수 없는 이유로 다운되었다고 가정한다.

Follower들은 Leader로부터 Election Timeout 동안 Heartbeat를 받지 못하고, F2가 Timeout 됐다고 가정해보자. F2는 자신을 Candidate로 바꾸고 Term을 증가시킨 다음 RequestVote RPC call을 모든 서버에게 보낸다.

RequestVote RPC call에는 요청을 받은 Candidate가 Leader가 되어도 문제가 없는지 Follower가 판단할 수 있도록 Term과 index 정보가 들어있다. RequestVote를 받은 F1은 F2가 보내온 RequestVote RPC 데이터를 살펴본다.

일단 Term의 숫자는 하나 높긴 한데, F1이 가진 log가 F2보다 더 최신이기 때문에 F1는 F2의 RequestVote에 거절 응답을 보내고, F2는 leader로 선출되지 못한다.

이후 F1에서 다시 Election Timeout이 발생하면 F1은 F2와 Term이 같으며 더 최신의 log를 보유하고 있으므로 F2는 F1의 RequestVote RPC call에 OK 응답을 하고 F1은 새로운 Leader로 선출된다. F1이 Leader가 된 이후 보낸 첫 번째 Heartbeat(Append RPC)를 수신한 F2는 자신의 상태를 Follower로 변경한다

F1이 새로운 Leader가 된 상태에서 write 요청을 받게 되더라도 쿼럼 숫자만큼의 etcd 서버가 Running 중이므로 etcd 클러스터는 정상 동작한다.

Leader Back

F1이 새로운 Leader가 된 상태에서 구 Leader가 복구되면, F1에게 Heartbeat를 보내거나 F1으로부터 Heartbeat를 받을 텐데 lastIndex 값이 더 작고 Term도 낮으므로 자기 자신을 follower로 변경하고 Term 숫자를 높은 쪽에 맞춘다.

여기까지가 대략적인 etcd에 대한 기본 개념과 etcd에 적용된 Raft 알고리즘에 대한 설명이다. 다음 포스트에서는 etcd 클러스터가 동작 중인 가운데 etcd 서버를 추가/삭제 발생할 때 어떤 식으로 Raft 알고리즘이 적용되는지 알아보자.

[K8s] k8s Pod 생성 시 벌어지는 일

겨울바람_ — Tue, 9 Jul 2024 13:41:09 +0900

Pod

K8s의 Pod는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. 하나 이상의 컨테이너의 그룹이며, 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고, 함께 스케줄되며, 공유 콘텍스트에서 실행된다.

ReplicaSet

yaml 파일 혹은 kubectl run 명령어를 통해 Pod를 생성할 수 있다. 하지만 Pod만 생성할 경우 Pod에 문제가 생겨 해당 Pod가 다운되거나, 종료되었을 때 쿠버네티스가 해당 Pod를 다시 생성할 수 없다.

Pod에 문제가 생겨 종료되었을 때, 해당 Pod를 복구할 수 있는 쿠버네티스의 기능을 Self-Healing 이라고 한다. Self-Healing 기능을 위해서는 ReplicaSet이 필요하다.

ReplicaSet은 주기적으로 Pod를 감시하며, 사용자가 설정한 수만큼 Pod가 실행되고 있는지를 확인한다.

Deployment

Deployment는 ReplicaSet을 관리하는 controller다. 또한, ReplicaSet에서는 지원하지 않았던 배포 관한 전까지도 지원하며, 문제가 생겼을 때 롤백을 어떤 식으로 진행할지에 대한 설정도 가능하다.

Deployment를 사용하면 더욱 안정적으로 Pod들의 운영이 가능하기 때문에 Pod를 생성할 때 Pod만 생성하는 것이 아니라 Deployment 단위로 생성하게 된다.

Pod가 생성되는 순서를 kubectl get events 명령어로 살펴보면, Deployment가 먼저 생성되고 Deployment에 의해 ReplicaSet이 만들어진다. 최종적으로 ReplicaSet 설정된 사용자의 설정에 따라 Pod가 생성된다.

k8s Cluster 내부

쿠버네티스 클러스터 내부는 각각 마스터 노드와 워커 노드로 분리되어 있다.

마스터 노드 내부에는 API Server, Scheduler, Controller Manager, etcd 와 같은 컴포넌트들이 존재한다. 워커 노드 내부에는 kubelet, kubeProxy 가 존재하며, kubectl 명령어를 사용할 때마다 각 노드에 존재하는 컴포넌트들이 상호작용하게 된다.

또한 각 컴포넌트들은 watch 라는 매커니즘을 가지고 있다. 예를 들어, API Server는 etcd를 지속적으로 watch 하며, API Server에 변경사항이 발생할 경우 해당 변경사항이 etcd로 업데이트 된다. etcd 는 API 변경사항을 새롭게 저장하게 되고, 그에 따라 etcd 에도 변경사항이 발생하게 된다.

etcd에 변경사항이 발생하게 될 경우, etcd를 watch하고 있는 API Server에 notify를 보내게 되고, API Server 또한 API Server를 watch 하고 있는 Components에 notify를 보내게 된다.

위와 같은 구조를 쿠버네티스 클러스터에 실제로 적용시키게 되면, 다음과 같은 흐름을 볼 수 있다.

Components 들은 API Server를 watch하고 있고, API Server는 etcd를 watch하고 있다. kubectl run 명령어를 통해 Deployment 단위로 Pod를 생성하게 되면 결과적으로 아래와 같은 흐름에 따라 Pod가 생성된다.

꽤 복잡해보이지만, 흐름을 정리하면 다음과 같다.

kubectl run 명령 실행시 Deployment Resource에 변화가 생기고 해당 Resource 를 watch 하고 있던 Controller 에 notify가 응답으로 보내지게 된다. 해당 notify에 따라 Controller는 Resource에 Resource 생성을 위한 요청을 Controller에 보내게 된다.

이 과정이 반복되고 최종적으로 Pod Resource에서 보내진 notify가 Scheduler로 보내지고, 해당 Scheduler가 워커 노드에 Pod를 생성하게 된다.

워커 노드에 Pod가 생성되는 과정까지 상세히 살펴보자. 우선 Scheduler는 API Server에 수집되고 있는 워커 노드에 대한 자원 사용량과 Affinity, Taint 등의 정보를 통해 Pod를 생성하기에 최적인 워커 노드를 선발한다.

최종적으로는 Pod Resource에 변경사항이 발생하고 해당 변경사항을 워커 노드의 kubelet이 감지하여 Pod를 생성한다.

Traefik 이란?

겨울바람_ — Thu, 30 May 2024 14:21:45 +0900

Traefik 이란?

Traefik은 Nginx, Apache와 같이 웹 서버 앞에서 동작하며 클라이언트로부터의 요청을 웹 서버에 전달하는 역할을 수행하는 Reverse Proxy Server의 일종이다.

오픈소스 Edge Router라는 명칭으로도 불리며, config 파일을 수정해야 하는 번거로움을 가진 Nginx, Apache 등의 다른 툴과 달리 서비스를 배포할 때 서비스가 처리할 수 있는 요청의 특성을 Traefik에 알리는 정보를 첨부하는 것으로, 서비스가 배포될 때 실시간으로 Traefik의 라우팅 규칙을 업데이트 할 수 있다.

실제로 Docker 환경에서 사용할 때, docker.sock, label 속성을 통해 적절히 값을 설정해주면 서비스 컨테이너와 Traefik이 실시간으로 연결되는 것을 확인할 수 있다. Traefik 또한 Docker Container를 통한 손쉬운 배포가 가능하다.

현재 필자의 개인 서버 또한, Traefik을 통해 Docker Container로 배포된 서비스들을 관리하고 있다.

Traefik Concept

Traefik은 다음과 같은 구성 요소들로 이루어져있다.

EntryPoint

엔트리포인트는 Traefik으로 들어오는 외부 요청의 진입점으로, 패킷을 어떤 포트로 받을지 정의하고 통신 방식을 정의할 수 있다.

EntryPoints are the network entry points into Traefik. They define the port which will receive the packets, and whether to listen for TCP or UDP.

Router

라우터는 엔트리포인트를 통해 Traefik으로 들어온 요청을 서비스로 전달하는 역할을 한다.

A router is in charge of connecting incoming requests to the services that can handle them.

Middleware

라우터와 함께 동작하며, 서비스로 요청 혹은 응답이 도착하기 전에 그것들을 수정할 수 있다. 예를 들어, http 요청을 https 요청으로 변환시키는 역할을 수행하는 역할을 담당할 수 있다.

Attached to the routers, middlewares can modify the requests or responses before they are sent to your service

Service

서비스는 들어오는 요청을 처리할 실제 서비스에 어떻게 도달하게 할 것인지를 구성한다.

Services are responsible for configuring how to reach the actual services that will eventually handle the incoming requests.

Auto Service Discovery

위에서 설명했듯이 Traefik은 전통적인 Reverse Proxy 도구인 Nginx 혹은 Apache 처럼 매번 서비스를 등록하기 위해서 config 파일을 수정해야 하는 번거로움이 없다.

이는 서비스가 배포됐을 때, Traefik이 배포된 서비스를 즉각 감지하고 라우팅 규칙을 실시간으로 업데이트 한다는 것을 의미한다. 비슷하게 서비스의 배포가 중단됐을 때, 해당하는 라우팅 규칙 또한 따라서 삭제된다.

즉, Traefik을 사용하는 개발자는 더 이상 배포되는 서비스와 IP주소와 라우팅 규칙 등을 config 파일에 작성하고 동기화 할 필요가 없는 것이다.

Traefik은 이와 같은 Auto Service Discovery를 구현하기 위해 Provider에게 API를 호출하여 Entry Point, Router, Service에 대한 정보를 받아온다. 이때 Provider는 오케스트레이터, 컨테이너 엔진, 클라우드 제공업체 또는 키-값 저장소와 같은 인프라 구성 요소가 될 수 있다. 대표적으로는 Docker, K8s 등이 해당된다.

Traefik with Docker Provider

필자의 개인 서버는 언급했듯이 Docker를 Provider로 하여 Traefik을 운영 중이기 때문에 Docker 환경에서의 Traefik 설정 방법에 대해 이야기 해보고자 한다.

우선 Traefik의 설정이 어떤 방식으로 구성되는지 알아보자.

Static Configuration

정적 설정은 설정 파일 작성, CLI 인자 작성, 환경 변수 설정 세 가지 방법 중 하나를 선택하여 Traefik에 대한 설정을 정의할 수 있다. 옵션에 대한 값을 정의하지 않을 경우 기본 값으로 해당 값이 설정된다.

Nginx와 Apache 등에서 이루어지는 설정 방식과 유사하며, Traefik의 설정 파일 작성 경로는 다음과 같다.

/etc/traefik/
$XDG_CONFIG_HOME/
$HOME/.config/
. (the working directory)

Traefik은 실행 시, 해당 경로에 위치한 traefik.yml 혹은 traefik.yaml, traefik.toml 을 찾아 해당 설정 파일의 내용을 반영하여 실행된다.

Dynamic Configuration

Docker를 Provider로 사용할 경우 동적 설정 방식은 labels를 사용하여 라우터, 서비스, 엔트리 포인트, 로드밸런서, 미들웨어 등의 설정을 정의할 수 있다.

예를 들어, Traefik의 관리 하에 두고싶은 서비스의 도커 컴포즈 파일을 다음과 같이 작성할 경우

  whoami1:
    image: traefik/whoami
    container_name: whoami1
    labels:
      - traefik.http.routers.whoami1.rule=Host(`example.com`) &&
        PathPrefix(`/1`)
      - traefik.http.routers.whoami1.entrypoints=websecure
      - traefik.http.routers.whoami1.tls.certresolver=myresolver
    networks:
      - proxy

자동으로 엔트리 포인트를 연결해주고, Host 도메인과 PathPrefix 경로에 해당하는 라우터와 해당 라우터에 연결된 서비스를 생성하여 실제 실행되는 whoami 서비스와 연결시킨다.

Docker-Compose.yaml

version: "3.8"
networks:
  proxy:
    name: proxy
services:
  traefik:
    image: traefik:v2.9
    container_name: traefik
    command:
      - --api.insecure=false
      - --api.dashboard=true
      - --providers.docker=true
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      - --certificatesresolvers.myresolver.acme.httpchallenge=true
      - --certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web
      - --certificatesresolvers.myresolver.acme.email=dev_in_wonderland@naver.com
      - --certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json
    labels:
      - traefik.enable=true
      - traefik.docker.network=proxy
      - traefik.http.routers.traefik.rule=Host(`web.dev-in-wonderland.pro`) &&
        (PathPrefix(`/api`) || PathPrefix(`/dashboard`))
      - traefik.http.routers.traefik.entrypoints=websecure
      - traefik.http.routers.traefik.tls.certresolver=myresolver
      - traefik.http.routers.traefik.service=api@internal
      - traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https
      - traefik.http.routers.redirs.rule=hostregexp(`{host:.+}`)
      - traefik.http.routers.redirs.entrypoints=web
      - traefik.http.routers.redirs.middlewares=redirect-to-https
      - traefik.http.routers.traefik.middlewares=auth
      - traefik.http.middlewares.auth.basicauth.users=[사용자]:[비밀번호]
    ports:
      - 80:80
      - 443:443
      - 8080:8080
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /home/cheshire-cat/traefik:/etc/traefik/
      - /home/cheshire-cat/letsencrypt:/letsencrypt
    networks:
      - proxy
  whoami1:
    image: traefik/whoami
    container_name: whoami1
    labels:
      - traefik.http.routers.whoami1.rule=Host(`web.dev-in-wonderland.pro`) &&
        PathPrefix(`/1`)
      - traefik.http.routers.whoami1.entrypoints=websecure
      - traefik.http.routers.whoami1.tls.certresolver=myresolver
    networks:
      - proxy

Traefik의 구성 요소인 EntryPoint, Router, Service, Middleware가 모두 잘 정의된 것을 확인할 수 있다. 주의해야 할 점은 Traefik의 관리하에 운영하고 싶은 서비스의 경우 Traefik과 동일한 네트워크를 사용해야 한다.

traefik에서 정의된 EntryPoint는 web(80), websecure(443) 두 개다. 아래의 whoami1 서비스의 경우 labels 속성에 동적으로 설정된 traefik.http.routers.whoami1.entrypoints=websecure 을 보면, traefik에서 정의한 EntryPoint를 진입점으로 가지는 것을 확인할 수 있다.

traefik.http.routers.whoami1.rule=Host(`web.dev-in-wonderland.pro`) && PathPrefix(`/1`) Routing Rule 부분을 살펴보면 Host가 web.dev-in-wonderland.pro 서브 도메인으로 잡혀있고, 경로는 1로 지정되어 있다.

결과적으로 `web.dev-in-wonderland.pro:443/1` 경로로 들어오는 요청을 whoami1 서비스로 전달한다는 의미다.

마무리

Traefik은 Reverse Proxy를 통해 구성할 수 있는 다양한 기능들을 굉장히 손쉽게 서비스에 적용할 수 있도록 해주는 굉장히 편리한 도구다. 해당 포스팅에서는 추가적으로 설명하지는 않았지만 로드 밸런서 기능 또한 동적 설정으로 손쉽게 적용할 수 있으며, HTTPS 사용을 위한 TLS 인증서 발급 또한 쉽게 가능하다.

현재 개인 서버를 운영하면서 다수의 서비스에 대한 관리를 Traefik을 통해 이어나가고 있는데, 사용하면 할 수록 굉장히 편리한 점들이 많아 간단하게 소개해볼 겸 해당 포스팅을 작성하게 됐다.

추후 Traefik에서 제공하는 다른 기능들, 로드밸런서, 미들웨어 등에 대한 포스팅도 기회가 되면 작성하려고 한다.

Ubuntu HomeServer - 2 : 외부 접속 허용하기

겨울바람_ — Sun, 26 May 2024 19:19:55 +0900

들어가기 전에, 필자의 환경에 대해 설명하고자 한다. 내부의 인터넷 망 연결 상태에 따라 방법이 달라지기 때문에 필자의 환경과 본인의 환경이 완벽하게 일치하지 않는 이상 그대로 따라하기 보다는 참고 정도로만 생각하는 것이 좋다.

필자는 LG U+ 통신사를 사용하고 있으며 이중 공유기를 사용하고 있다. 조금 더 이해를 쉽게하기 위해 아래의 그림을 참고하도록 하자.

LG U+의 경우 기가 인터넷 속도 증폭을 목적으로 홈 게이트웨이를 제공하는데, 해당 홈 게이트웨이를 한 번 거쳐서 공유기를 통해 노트북에 무선 인터넷이 연결되는 환경이었다.

외부 접속을 허용하기 위해서는 홈 게이트웨이와 공유기의 관리자 페이지에 접속해야 하는데, 이를 위해서는 각 기기의 관리자 페이지 접속을 위한 비밀번호를 알고 있어야 한다. 보통 기기 뒷면에 초기 비밀번호가 나와있으니 기기의 뒷면을 잘 확인해보자.

참고로 홈 게이트웨이는 신발장 배선함 내부에 존재했고, 공유기는 벽걸이TV 뒤에 있었기 때문에 확인하는데 굉장히 어려움을 겪었다. 하지만 확인이 안되면 외부 접속 허용이 불가능하니 인내심을 가지고 잘 찾아보자.

기기 관리자 페이지 접속

LG U+의 경우 기본적으로 관리자 페이지에 접속하는 주소는 동일하다. 본인 로컬 환경에서 192.168.219.1 을 주소창에 입력하면 관리자 페이지로 접속할 수 있다.

필자의 경우 위에서 설명했듯이 홈 게이트웨이라는 거추장스러운 친구가 존재하기 때문에 두 개의 기기가 화면에 표시되는 것을 확인할 수 있다. 화면에 공유기 하나만 나타난다고 해서 잘못된 것이 아니다.

각 기기 그림을 클릭하게 되면 해당 기기의 관리자 페이지로 접속하기 위한 인가 페이지가 화면에 나타난다. 우선 하단에 위치한 공유기의 관리자 페이지에 접속해보자.

공유기 뒤편에서 확인한 관리자 페이지 접속 비밀번호와 보안코드를 입력하고 로그인을 누르면, 아래와 같이 관리자 페이지에 접속할 수 있다.

여기서 네트워크 설정탭의 NAT 설정을 선택하면, 포트포워딩을 설정할 수 있는 설정창이 나오는데, 만약 본인의 환경이 단일 공유기만 존재한다면 해당 공유기를 포트포워딩 할 경우 바로 외부 접속이 허용된다.

서비스 포트는 외부로 공개할 포트, 내부 포트의 경우 서버로 사용하고 있는 노트북과 연결할 포트라고 보면된다. 즉, 서비스 포트로 요청이 들어왔을 때 해당 요청은 설정한 내부 IP 주소의 내부 포트로 향하게 된다.

내부 IP 주소를 확인하는 방법은 Ubuntu 기준으로 ifconfig 명령어를 통해 확인할 수 있다. 여기서 주의 사항을 몇 가지 말하자면 포트 번호를 설정할 때 잘 알려져 있는 포트 번호를 사용하기 보다는 임의의 포트 번호를 통해 연결해주는 것을 권장한다.

22번 포트의 경우 ssh 접속에 대한 기본 포트로 많이 알려져 있기 때문에 손쉽게 공격에 노출될 수 있기 때문에 별도의 포트 번호를 사용하는 것을 추천한다.

포트포워딩을 위한 정보 입력을 끝마쳤다면, 추가 버튼을 누르고 설정 적용을 버튼을 누르자. 참고로 LG U+ 환경에서는 설정 적용을 버튼을 클릭했을 때 공유기가 60초 가량 먹통이 되기 때문에 만약 가족과 함께 생활한다면 양해를 미리 구해두거나 가족들이 잠든 새벽에 진행하자.

단일 공유기만을 사용한다면, 여기까지만 해도 외부 접속이 가능하다. 하지만 필자는 홈 게이트웨이가 존재하는 이중 공유기 환경이기 때문에 홈 게이트웨이에도 공유기와 동일하게 포트포워딩을 적용시켜줘야 한다.

이중 공유기 환경의 경우, 홈 게이트웨이의 서비스 포트가 실질적인 외부 인터넷과 연결되는 외부 포트 역할을 하고 홈 게이트웨이의 내부 포트가 공유기의 서비스 포트로 포트포워딩을 진행하게 된다.

풀어서 설명하자면, 홈 게이트웨이의 서비스 포트가 11, 내부 IP 주소는 공유기의 외부 IP 주소, 내부 포트 번호는 공유기에서 설정한 서비스 포트 번호가 될 것이다.

단일 공유기 환경과 다른 점이라고 하면 홈 게이트웨이를 한 번 더 거쳐서 요청이 들어온다는 것이다.

홈 게이트웨이 또한 공유기와 동일하게 포트포워딩을 진행하면 되는데, 필자의 홈 게이트웨이의 경우 IPv6 환경이었기에 NAT 설정이 불가능했고 이를 IPv4 only로 바꿔줘야 했다.

IPv4 only로 설정하게 되면 IPv6로만 운영되는 서비스에 접속이 불가능해진다. IPv6로만 운영되는 서비스를 사용하고 있다면 주의하도록 하자.

성공적으로 홈 게이트웨이까지 포트포워딩에 성공했다면, 이제 포트포워딩을 통해 외부 접속을 허용한 포트가 실제로 외부 접속이 가능한지 확인해볼 차례다.

https://www.yougetsignal.com/tools/open-ports/

Open Port Check Tool - Test Port Forwarding on Your Router

www.yougetsignal.com

해당 사이트에 들어가서 홈 게이트웨이의 외부 IP 주소와 포트 포워딩을 허용한 서비스 포트 번호를 입력하여 테스트해보자. 참고로 각 기기의 외부 IP 주소는 관리자 페이지의 홈에서 확인 가능하다.

별 다른 문제없이 포트포워딩에 성공했다면 아래와 같이 초록색 깃발이 표시된다. 만약 붉은 색 깃발이 표시된다면 포트포워딩에 실패했다는 것이니 내부 포트와 서비스 포트, IP 주소를 잘 살펴보도록 하자.

Ubuntu HomeServer - 1 : Window에서 Ubuntu로 변경하기

겨울바람_ — Sun, 26 May 2024 18:08:58 +0900

사용하지 않은 채 방치되어 있던 노트북을 개인 서버 용도로 사용하기로 마음먹었다. 이번 게시글에서는 해당 노트북에 이미 설치되어 있던 Window 운영체제를 Ubuntu로 변경하는 과정을 설명하려고 한다.

Install Ubuntu ISO Image

https://ubuntu.com/download/desktop

ubuntu.com

본인이 사용하고 싶은 서버 환경에 따라 버전 및 데스크톱/서버 용도의 이미지를 잘 선택하여 다운로드하면 된다.

필자의 경우 최초에는 24.04 버전을 다운받았으나, 버전 충돌 문제 등으로 인해 22.04 이미지로 다시 내려받았다. 각 Ubuntu 버전마다 apt repository에서 기본적으로 제공되는 Python 등의 버전이 달라진다는 것을 유의하고 선택하길 바란다.

Create Bootable USB Drive

https://rufus.ie/ko/

Rufus - 간편하게 부팅 가능한 USB 드라이브 만들기

Rufus는 USB 메모리 및 플래시 드라이브를 포맷하고 부팅할 수 있도록 만드는 도구입니다. 이 페이지 아래에 나열된 ISO 이미지 이외에도 Rufus는 여러 종류의 ISO 이미지를 지원합니다. (1) Windows 8 이

rufus.ie

ISO 이미지 파일을 통해 BIOS에서 운영 체제를 다시 등록시켜야 하기 때문에, 부팅 가능한 USB 드라이브를 손쉽게 만들어주는 Rufus를 사용한다.

Rufus의 경우 Window 전용이기 때문에 별도의 OS를 사용하고 있다면, 다른 방법을 찾아봐야 한다.

Rufus를 사용할 경우 USB가 포맷되기 때문에, 포맷이 돼도 괜찮은 USB를 사용하는 것을 권장한다.

필자의 경우 Rufus Portable을 사용해 진행했다. 성공적으로 실행이 완료됐다면, 아래와 같은 창을 확인할 수 있을 것이다.

선택 버튼을 클릭하여, 내려받았던 Ubuntu ISO 파일을 선택하고, 장치에 본인이 부팅 가능한 USB로 만들고 싶은 장치를 잘 선택하여 시작 버튼을 누르자.

시작 버튼을 누르면 "다운로드가 필요합니다." 라는 경고창이 보일텐데, '예' 를 클릭하고 다음으로 넘어가면 "ISOHybrid 이미지가 감지되었습니다." 라는 팝업창을 확인할 수 있다.

해당 팝업창에는 두 가지 선택지가 존재하는데, 여기서 권장하는 방식인 ISO 이미지 모드로 쓰기 버튼을 클릭한다.

여기까지 진행하는데 별 다른 이상이 없었다면, 해당 장치의 데이터가 모든 삭제된다는 경고창이 화면에 나타날텐데, 다시 한 번 본인의 USB 드라이브가 포맷해도 되는 것인지 잘 생각해보고 확인 버튼을 눌러주자.

확인 버튼을 누르면, 상태창 아래에서 초록색 바가 서서히 움직이는 것을 확인할 수 있는데, 해당 작업이 완료되는데 약간의 시간이 필요하다.

우분투 공식 페이지에서 가져온 예시 이미지다

위의 이미지처럼 초록색 바가 완전히 꽉 채워졌다면, 닫기 버튼을 누르자. 시작 버튼을 누르면 똑같은 작업을 반복하게 되니 주의하도록 하자.

이제, 노트북이 부팅될 때 USB에 내려받은 Ubuntu 이미지 파일이 우선적으로 시행되도록 만들어줘야 한다. 해당 과정에 들어가기 앞서 본인의 노트북에서 BIOS로 들어갈 수 있는 방법을 알아보도록 하자.

삼성 노트북의 경우 노트북이 켜지고 삼성 로고가 화면에 나타날 때 F12 버튼을 연타하면 BIOS로 이동할 수 있다. 본인이 사용하는 노트북 제품에 따라 방법이 다르기 때문에 미리 알아두자.

Change Boot Device Priority

삼성 노트북의 경우 BIOS에 진입하면 위와 같은 화면을 확인할 수 있다. 여기서 초록색 배경에 Boot라고 쓰여있는 버튼을 클릭하면 아래와 같은 화면으로 이동하게 된다.

해당 화면에서 Boot Device Priority 를 선택하고

Boot Option에서 본인이 Rufus를 통해 부팅 가능한 USB로 만든 드라이브 장치가 Window보다 실행 우선순위가 높아지도록 순서를 변경해준 뒤, Save 버튼을 클릭하면 노트북이 재실행되고 Ubuntu 설치 화면으로 이동하게 된다.

추가적으로 구형 노트북을 사용할 경우 BIOS가 텍스트인 경우가 종종 존재한다고 한다. 본인의 BIOS가 텍스트 형태의 제품일 경우 아래의 링크를 참고하여 진행하길 바란다.

https://www.samsungsvc.co.kr/solution/22116

[삼성 PC] 부팅 우선 순위 변경하고 싶어요.

www.samsungsvc.co.kr

Install Ubuntu 22.04

성공적으로 부트 순서가 변경됐다면 위처럼 Ubuntu 설치와 관련된 선택지를 확인할 수 있는 화면을 볼 수 있다. Try or Install Ubuntu 를 선택하여 설치를 진행하자.

필자의 경우 Desktop 모드를 선택했기 때문에 Server 이미지를 선택했다면 나타나는 화면이 다를 것이다. 하지만 근본적으로 GUI냐 CLI냐의 차이를 제외하면 동일하기 때문에 잘 선택하여 진행하면 된다.

설치 언어를 선택하고 Install Ubuntu를 선택하자.

본인의 설치 언어에 맞는 키보드 배열을 선택하면 된다. 보통은 English(US) 혹은 Korea 를 선택한다.

이후 우분투 설치 시 함께 설치할 소프트웨어를 선택하면 된다. 필자는 Normal installation 으로 진행했다.

Erase disk and install Ubuntu를 선택하고, Install Now 클릭하여 설치를 시작한다.

본인이 원하는 위치를 선택하고 Continue를 선택하면 사용자 정보를 입력하는 화면이 나타난다.

사용자 정보를 입력하고 나면 설치가 본격적으로 시작된다.

설치가 완벽하게 끝나게 되면 아래와 같이 노트북을 재부팅하겠다는 알림창이 나타난다.

노트북이 다시 부팅되고 나면 Ubuntu 22.04가 성공적으로 설치된 것을 확인할 수 있다.

참고

https://rufus.ie/

https://ubuntu.com/download/desktop

CPU-Scheduling

겨울바람_ — Sun, 7 Apr 2024 11:28:28 +0900

CPU-Scheduling 이란?

모든 프로세스는 CPU를 필요로 하고 모든 프로세스는 먼저 CPU를 사용하고 싶어 하기에, 여러 프로세스들에게 합리적으로 CPU 자원을 할당하기 위해 운영체제는 어떤 프로세스에 어떤 CPU를 할당할지를 결정한다.

이렇게 운영체제가 프로세스들에게 합리적으로 CPU 자원을 배분하는 것을 CPU-Scheduling 이라고 한다. CPU-Scheduling 이 제대로 동작하지 않는다면, 반드시 실행되어야 할 프로세스들이 실행되지 못하거나, 중요하지 않은 프로세스들만 주로 실행되는 등 컴퓨터 성능에 직결되는 문제라고 볼 수 있다.

프로세스 우선순위

각 프로세스마다 우선순위가 다른데, 우선순위가 높은 프로세스일수록 빨리 처리해야 하는 프로세스들을 의미한다. 우선순위가 높은 프로세스에는 대표적으로 입출력 작업이 많은 프로세스가 있다.

프로세스의 종류마다 입출력장치를 이용하는 시간과 CPU를 이용하는 시간의 양에는 차이가 있다. 입출력장치를 사용하는 경우가 많은 프로세스를 입출력 집중 프로세스, CPU를 사용하는 경우가 많은 프로세스를 CPU 집중 프로세스라고 하는데, 입출력 집중 프로세스는 실행 상태보다는 입출력을 위한 대기 상태에 더 많이 머무르게 된다. 반면에, CPU 집중 프로세스는 대기 상태보다는 실행 상태에 더 많이 머무르게 된다.

CPU 집중 프로세스와 입출력 집중 프로세스가 동시에 CPU 자원을 요구했을 때 입출력 집중 프로세스를 최대한 빨리 실행시켜 입출력장치를 꾸준히 작동시키고, 그다음 CPU 집중 프로세스에 CPU를 집중적으로 할당하는 것이 더 효율적이다. 입출력 집중 프로세스는 어차피 입출력장치가 입출력 작업을 완료하기 전까지는 대기 상태가 될 예정이기 때문에 입출력 집중 프로세스를 우선적으로 처리한다면 다른 프로세스가 CPU를 사용할 수 있기 때문이다.

이렇듯 운영체제는 프로세스의 중요도에 맞게 프로세스마다 우선순위를 부여하여 PCB에 명시한다.

Scheduling Queue

PCB에 적혀있는 우선순위를 확인하기 위해 모든 프로세스의 PCB를 운영체제가 탐색하는 것은 비효율적이다.

이를 위해 운영체제는 프로세스들을 CPU 사용, 메모리 적재, 입출력장치 사용 등의 목적을 통해 구분하여 Scheduling Queue에 삽입한다. 대표적인 Scheduling Queue에는 CPU 사용을 위한 프로세스들을 적재하는 Ready Queue와 입출력장치 사용을 위한 프로세스들을 적재하는 Waiting Queue 가 존재한다.

준비 상태에 있는 프로세스들의 PCB는 Ready Queue의 마지막에 삽입되어 CPU를 사용할 차례를 기다린다. 운영체제는 PCB들이 큐에 삽입된 순서대로 프로세스를 하나씩 꺼내어 실행하되, 그중 우선순위가 높은 프로세스를 먼저 실행한다.

즉, 우선순위가 낮은 프로세스들이 먼저 큐에 삽입되었더라도 우선순위가 높은 프로스가 먼저 처리될 수 있다는 것이다.

Preemptive Scheduling (선점형 스케줄링)

선점형 스케줄링이란, 프로세스가 CPU를 비롯한 자원을 사용하고 있더라고 운영체제가 프로세스로부터 자원을 강제로 빼앗아 다른 프로세스에게 할당할 수 있는 스케줄링 방식을 의미한다.

프로세스마다 정해진 시간만큼 CPU를 사용하고, 정해진 시간을 모두 소비하여 타이머 인터럽트가 발생하면 운영체제가 해당 프로세스로부터 CPU 자원을 빼앗아 다음 프로세스에게 할당하는 방식 또한 선점형 스케줄링의 일종으로 볼 수 있다.

선점형 스케줄링은 어느 한 프로세스의 자원 독점을 막고 프로세스들에게 골고루 자원을 배분할 수 있다는 장점이 있지만, 그만큼 문맥 교환 과정에서 오버헤드가 발생할 수 있다.

대부분의 운영체제에서는 선점형 스케줄링 방식을 차용하고 있다.

Non-Preemptive Scheduling (비선점형 스케줄링)

비선점형 스케줄링이란, 하나의 프로세스가 자원을 사용하고 있다면 그 프로세스가 종료되거나 스스로 대기 상태에 접어들기 전까진 다른 프로세스가 끼어들 수 없는 스케줄링 방식을 의미한다.

이는 특정 프로세스가 자원을 독점할 수 있는 스케줄링 방식이며, 만약 비선점형 방식으로 자원을 이용하는 프로세스가 존재한다면 다른 프로세스들은 그 프로세스의 사용이 모두 끝날 때까지 기다려야 한다.

비선점형 스케줄링은 선점형 스케줄링에 비해 문맥 교환의 횟수가 적기 때문에 발생할 수 있는 오버헤드가 적지만, 하나의 프로세스가 자원을 사용 중이라면 당장 자원을 사용해야 하는 상황에서도 무작정 기다려야 하기 때문에 모든 프로세스가 골고루 자원을 사용할 수 없다는 단점이 있다.

Scheduling Algorithm

FCFS Scheduling (선입 선처리 스케줄링)

First Come First Served Scheduling 은 Scheduling Queue 에 삽입된 순서대로 프로세스들을 처리하는 비선점형 스케줄링 방식이다.

즉, CPU를 먼저 요청한 프로세스부터 CPU를 할당하는 방식인데, 이는 언뜻 가장 공정해 보이는 방식이지만, 프로세스들이 기다리는 시간이 매우 길어질 수 있다는 점에서 단점이 존재하는 방식이다.

SJF Scheduling (최단 작업 우선 스케줄링)

FCFS 에서 발생할 수 있는 단점을 최소화하기 위해 CPU 사용 시간이 짧은 프로세스를 먼저 실행하는 스케줄링 방식을 Shortest Job First 스케줄링이라고 한다. 기본적으로 비선점형 스케줄링으로 분류되지만, 선점형으로도 구현될 수 있다.

Round Robin Scheduling

Round Robin Scheduling 은 FCFS Scheduling 에 타임 슬라이스라는 개념이 더해진 스케줄링 방식이다.

타임 슬라이스란, 각 프로세스가 CPU를 사용할 수 있는 정해진 시간을 의미한다. 즉, Round Robin Scheduling 은 정해진 타임 슬라이스만큼의 시간 동안 돌아가며 CPU를 이용하는 선점형 스케줄링이다.

큐에 삽입된 프로세스들은 삽입된 순서대로 CPU를 이용하되 정해진 시간만큼만 CPU를 이용하고, 정해진 시간을 모두 사용하였음에도 아직 프로세스가 완료되지 않았다면, 다시 큐의 맨 뒤로 삽입된다. 이때 문맥 교환이 발생한다.

Round Robin Scheduling 에서는 타임 슬라이스의 크기가 매우 중요하다. 타임 슬라이스가 지나치게 크면 FCFS Scheduling 과 다를 바 없어지고, 타임 슬라이스가 지나치게 작으면 문맥 교환에 발생하는 비용이 커 CPU는 프로세스를 처리하는 일보다 프로세스를 전환하는데 더 많은 비용이 소모될 여지가 있기 때문이다.

SRT Scheduling (최소 잔여 시간 우선 스케줄링)

Shortest Remaining Time Scheduling 은 SJF Scheduling과 Round Robin Scheduling 을 합친 스케줄링 방식이다.

프로세스들은 정해진 타임 슬라이스만큼 CPU를 사용하되, CPU를 사용할 다음 프로세스로는 남아있는 작업 시간이 가장 적은 프로세스가 선택된다.

Priority Scheduling (우선순위 스케줄링)

Priority Scheduling 은 프로세스들에 우선순위를 부여하고, 가장 높은 우선순위를 가진 프로세스부터 실행하는 스케줄링 알고리즘이다.

SJF Scheduling, SRT Scheduling 이 넓은 의미에서 Priority Scheduling 의 일종으로 볼 수 있다. Priority Scheduling 은 우선순위가 높은 프로세스를 우선하여 처리하는 방식이기에 우선순위가 낮은 프로세스는 우선순위가 높은 프로세스들에 의해 실행이 계속해서 연기될 수 있다.

이를 기아 현상이라고 한다. 이를 방지하기 위한 대표적인 기법으로 에이징이 존재하는데, 이는 오랫동안 대기한 프로세스의 우선순위를 점차 높이는 방식이다.

Multilevel Queue Scheduling (다단계 큐 스케줄링)

Multilevel Queue Scheduling 은 Priority Scheduling의 발전된 형태로 우선순위별로 Ready Queue를 여러 개 사용하는 스케줄링 방식이다. 우선순위가 가장 높은 큐에 있는 프로세스들을 먼저 처리하고, 우선순위가 가장 높은 큐가 비어 있으면 그다음 우선순위 큐에 있는 프로세스들을 처리한다.

큐를 여러 개 두면 유형별로 우선순위를 구분하여 실행하는 것이 편리해진다. 또한 큐별로 타임 슬라이스를 여러 개 지정할 수도 있고, 큐마다 다른 스케줄링 알고리즘을 사용할 수 있다.

Multilevel Feedback Queue Scheduling (다단계 피드백 큐 스케줄링)

다단계 피드백 큐 스케줄링은 다단계 큐 스케줄링의 발전된 형태로, 다단계 큐 스케줄링에서는 프로세스들이 큐 사이를 이동할 수 없다. 그렇기 때문에 우선순위가 낮은 프로세스들이 계속 연기되는 기아 현상이 발생할 수 있다.

다단계 피드백 큐 스케줄링은 다단계 큐 스케줄링과 비슷하게 작동하지만, 프로세스들이 큐 사이를 이동할 수 있다는 점에서 차이가 존재한다. 다단계 피드백 큐 스케줄링에서 새로 준비 상태가 된 프로세스가 있다면 우선 우선순위가 가장 높은 우선순위 큐에 삽입되고 타임 슬라이스 동안 실행된다.

만약 프로세스가 해당 큐에서 실행이 끝나지 않는다면 다음 우선순위 큐에 삽입되어 실행된다. 결국 CPU를 오래 사용해야 하는 프로세스는 점차 우선순위가 낮아진다. 이로 인해 CPU를 비교적 오래 사용해야 하는 CPU 집중 프로세스들은 자연스레 우선순위가 낮아지고, CPU를 비교적 적게 사용하는 입출력 집중 프로세스들은 자연스레 우선순위가 높은 큐에서 실행이 종료된다.

또한 낮은 우선순위 큐에서 너무 오래 기다리고 있는 프로세스가 존재한다면 점차 우선순위가 높은 큐로 이동시키는 에이징 기법을 적용하여 기아 현상을 예방할 수 있다. 다단계 피드백 큐 스케줄링은 어떤 프로세스의 CPU 이용 시간이 길면 낮은 우선순위 큐로 이동시키고, 어떤 프로세스가 낮은 우선순위 큐에서 너무 오래 기다린다면 높은 우선순위 큐로 이동시킬 수 있는 알고리즘이다.

다단계 피드백 큐 스케줄링은 구현이 복잡하지만, 가장 일반적인 CPU 스케줄링 알고리즘으로 알려져있다.