이 글은 기본적인 쿠버네티스 지식이 있는 사람들을 대상으로 작성된 문서입니다.

ConfigMap과 Secret

쿠버네티스의 ConfigMap과 Secret은 주로 애플리케이션의 설정 값을 저장하기 위해 사용된다. 생성과 사용법도 크게 다르지 않다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: berry
data:
  name: Berry
  nationality: Korean
  age: "32"
  simple_key_val: |
    desksetup.keyboard=keychron
    desksetup.mouse=logitec

ConfigMap은 일반적인 설정 데이터를 저장할 때 사용된다. 도메인주소, 포트 번호, 환경 변수 등이 그 예이다.

apiVersion: v1
kind: Secret
metadata:
  name: berry
type: Opaque
data:
  secretname: YmVycnktaW8tZXVyb3BhCg==
  password: dGVzdDEyMzQK

Secret은 비밀번호, API 키, 인증서 등 외부에 노출되면 안되는 민감정보를 저장하는데 사용된다. 일반 텍스트로 저장하는 것이 아닌 base64로 인코딩 된 데이터를 저장하여 옆에서 슬쩍 봤을 때는(?) 바로 값을 알기 힘들다.

하지만 암호화(encrypted)가 아닌, 인코딩(encoded)되었다는 점에서 정말 데이터 보호가 안전하다고는 할 수 없다. 기본적으로 쿠버네티스에서 Secret 리소스를 암호화하진 않는다. 그래서 encrypt at rest를 권장한다.(링크)

물론 secret이 TLS나 dockercred 등을 저장할 수 있고 자잘한 차이점이 있긴 하지만 기본적으로 보안 측면에서 큰 차이가 보이진 않는다.

Base64가 끝?

ConfigMap과 Secret 모두 환경변수로 선언하거나 파일로 마운트하여 사용할 수 있다는 점에서 매우 유사하다. 단지 base64 하나 먹이려고 Secret을 나눈 것인가에 대한 생각이 들어 더 자세히 찾아보니... 아주 중요한 차이점이 있었다.

바로 Secret이 노드 내에 저장되는 방식에서의 차이점이다.

tmpfs

굉장히 익숙한 단어이다. df -h라는 익숙한 명령어를 치면 보이는 unix-like의 OS에서 거의 볼 수 있는 파일시스템이다.

tmpfs는 RAM 기반의 휘발성 파일 시스템으로 데이터가 디스크에 물리적으로 기록되지 않고 메모리(RAM)에만 존재한다.

Secret은 마운트되어 사용될 때 tmpfs에 저장된다.

secret이 파드에서 마운트되어 사용될 때 해당 파드가 위치한 노드의 tmpfs에 저장된다. 이로 인해 노드가 재부팅되거나 파드가 삭제되면 tmpfs에 저장된 Secret 데이터는 자동으로 사라져 ConfigMap에 비해서 훨씬 안전하다.

물론 volume에 마운트 될 때만의 차이점이긴 하지만 단지 base64로 인코딩한 것 이외에 이런 차이가 있다는 것을 알고 조금 놀랐다. 많은 포스트에서 이 얘기가 없기 때문이다.

민감 정보는 꼭! Secret에 두고 쓰자.

GIL은 Global Interpreter Lock의 줄임말이다.

이것의 정체는 정확히는 '뮤텍스'이다. 이 뮤텍스는 한번에 오직 하나의 스레드만이 파이썬 인터프리터에 대한 control을 할 수 있게 제한한다.

즉, 진정한 의미의 멀티스레딩이 불가하다는 것이다.

왜 GIL을 사용할까?

Python의 GC

공식 파이썬 implementation은 CPython이다.

이 CPython은 Garbage Collection을 수행할 때, Reference Count(RC)를 본다.

파이썬에서 모든 데이터는 객체이며 각 객체는 변수에 의해서 참조된다.

예를 들어 아래 코드를 보자

a = [1, 2, 3]  # 1
b = a          # 2

1. [1, 2, 3]객체는 변수 a에 의해 참조된다. 여기서 RC는 1이다.

2. [1, 2, 3] 객체는 이제 변수 'b'에 의해서도 참조된다. 이제 RC는 2가 된다.

그럼 Garbage Collect가 일어나도록 해보자.

a = [1, 2, 3]
b = a

a = 'a'    # 3
b = 'b'    # 4

3. 변수 a가 str 객체 a를 참조하게 되면서 [1, 2, 3]의 RC는 1로 줄어든다.

4. 변수 b 또한 str 객체 b를 참조하게 되면서 [1, 2, 3]의 RC는 0이 된다. 이제 [1, 2, 3]은 언제든지 GC가 될 수 있다.

Critical Section 문제

OS를 공부하신 분이라면 모두 들어봤을 멀티스레딩의 critical section을 생각해 봐야 한다.

RC의 값을 변경하는 것이 바로 Critical Section이 된다. 여러개의 스레드가 동일한 객체를 참조한다고 해보자. 당연히 이 값을 업데이트 하는데 문제가 있을 것 같다는 생각이 든다.

CPython에서는 이 문제를 해소하기 위해 GIL을 사용하는 것이다. 결론적으로 보면 GC를 제대로 하기 위해서 GIL을 사용하는 것이다.

GIL의 문제점

앞에서도 말했듯이 우리가 원하는 진정한 멀티스레딩(여러개의 코어에서 각각 스레드가 돌아가는)을 구현하려면 GIL은 당연히 문제가 된다.

특히 CPU-bounded 한 task를 수행하는데 성능에 큰 지장을 준다. 이때문에 이를 과도한 통제라고 하는 시각도 적지 않다.

하지만 파이썬을 사용한다고 무조건 GIL을 사용해야 하는 것은 아니다. Jython이나 IronPython 같은 파이썬 구현체는 GIL을 사용하지 않음으로써 멀티스레딩을 구현할 수 있도록 한다.

앞으로 GIL의 운명

성능적으로 이슈가 많다는 것을 당연히 파이썬재단에서도 알고 있다. 그래서 그런지 파이썬 3.13이 올해 release하면서 GIL을 선택적으로 사용할 수 있도록 해주는 experimental feature가 추가되었다.

멀리 내다보았을 때 아무래도 싱글스레드를 고집할 수 없기 때문에 GIL은 언젠가는 사라질 듯 하다.

기본 아이디어

배열 내에 과반 이상을 차지하는 값이 있다면 투표의 마지막에는 해당 원소가 최후의 승자가 될 것이라는 아이디어를 기반으로 고안되었다.

크게 2 단계로 이루어져 있는데,

1. 투표를 통해서 후보를 가려낸다. (후보와 같은 값이면 vote에 1을 더하고 아니면 1을 뺀다.)
2. 실제 해당 후보가 과반 이상 나타났는지 확인한다.

만약 무조건 과반 이상 나타나는 원소가 있다고 가정하면 2번째 단계는 건너뛰어도 된다.

예시#1

철수, 영희, 민수, 은지, 지원 5사람이 저녁 메뉴를 투표를 통해 정하기로 하였다. 과반의 표를 얻는 메뉴가 선정된다. 투표 결과는 다음과 같다.

위의 결과를 보면 일식이 3표로 5/2=2.5 이상을 차지하는 과반의 값이라고 볼 수 있다. 이를 해당 알고리즘을 통해서 순서대로 살펴보자.

1. 철수가 일식에 투표했다. 후보는 일식이며, vote 수는 1이다.
2. 영희가 일식에 투표했다. 후보와 같은 값이기 때문에 vote에 1을 더해 2가 된다.
3. 민수가 중식에 투표했다. 후보가 다른 값이기 때문에 vote에 1을 빼서 1이 된다.
4. 은지가 일식에 투표했다. 후보가 같은 값이기 때문에 vote에 1을 더해 2가 된다.
5. 지원이 한식에 투표했다. 후보가 다른 값이기 때문에 vote에 1을 빼서 1이 된다.

마지막에 후보로 나온 일식이 과반 이상이 나왔을 것이라고 예상한다. 실제로 과반 이상이 나왔는지 확인해보자.

예시#2

이번엔 다른 예시를 들어보자.

이번에는 아무도 중식에 투표하지 않았다. 최종적으로 일식이 과반이지만 중간에 한식이 2표가 있다. 처음에는 일식이 후보겠지만 바로 뒤에 한식이 2번 연속으로 오면서 vote가 음수가 될 것이다. 하지만 이 알고리즘은 vote가 0이 되면 바로 후보를 교체한다.

1. 철수가 일식에 투표했다. 후보는 일식이며, vote 수는 1이다.
2. 영희가 한식에 투표했다. 후보가 다른 값이기 때문에 vote에 1을 빼서 0이 된다.
3. 민수가 한식에 투표했다. vote가 0이기 때문에 후보를 한식으로 변경하고 vote를 1로 초기화한다.
4. 은지가 일식에 투표했다. 후보가 다른 값이기 때문에 vote에 1을 빼서 0이 된다.
5. 지원이 일식에 투표했다. vote가 0이기 때문에 후보를 일식으로 변경하고 vote를 1로 초기화한다.

이번에도 마지막에 일식이 후보이고 최종 과반인지 확인해보니 3이므로 메뉴는 일식으로 결정되었다.

코드

def moore_voting_algorithm():
    nums = [1, 1, 2, 3, 1]
    # 변수 초기화
    candidate = nums[0]
    vote = 0

    for num in nums:
        # vote가 0이면 후보를 교체한다.
        if vote == 0:
            candidate = num
            vote = 1
        else:
            # 현재 값이 후보와 같은 값이면 vote에 1을 더한다.
            if num == candidate:
                vote += 1
            # 현재 값이 후보와 다른 값이면 vote에 1을 뺀다.
            else:
                vote -= 1

    occurrences = 0
    for num in nums:
        if num == candidate:
            occurrences += 1

    if occurrences > len(nums)//2:
        print(f"{candidate}은 과반을 획득했습니다.")
    else:
        print("과반을 획득한 원소는 없습니다.")