Journey to Kubernetes with Blockchain Network(+CKAD)

안녕하세요. LINE에서 근무하고 있는 이지홍이라고 합니다. 2018년부터 가상 화폐 LINK가 살아 숨 쉬고 있는 블록체인 시스템을 개발하고 있습니다. 저는 블록체인 네트워크에 적합한 프로비저닝 방법을 연구하고 이를 Kubernetes(이하 K8s)와 같은 도구를 활용해 구현하기까지의 여정에 대한 후기를 이번 글에서 나누고자 합니다.

  • 글에서 언급한 블록체인 네트워크란 여러 블록체인 노드가 모인 한 그룹을 의미합니다. 이 그룹은 블록 단위로 새로운 정보를 기록하고 합의 알고리즘을 통해 합의에 성공한 블록을 체인 형태로 연결해 나갑니다. 
  • 참고로 이 글은 소프트웨어 개발과 프로비저닝에 관심 있는 독자라면 누구라도 가볍게 읽어 볼 수 있도록 작성하였고, 거기에 Docker, Mesos, K8s에 대한 101 지식과 경험이 함께 한다면 더 재미날 수 있습니다.

다음과 같은 순서로 연구 내용과 경험을 소개하겠습니다.

 

블록체인 네트워크 프로비저닝 준비

프로비저닝 대상을 바라보는 인식 변화의 중요성 – 애완동물(Pets) VS 소(Cattle)

블록체인 네트워크에 적합한 프로비저닝 방법에 대한 이야기를 시작하기 전에, 프로비저닝 대상을 바라보는 인식에 대한 차이를 짚고 넘어가고자 합니다. 아래 표를 보면 클라우드 친화적인 인프라를 소 떼에 비유하고 기존의 레거시 인프라를 애완동물에 비유하고 있습니다.

위 표를 한글로 번역해 보았습니다.

애완동물(레거시 인프라)소(클라우드 친화적 인프라)
애완동물은 grumpycat.petstore.com 같은 이름이 주어진다
애완동물은 하나하나가 특별하고 조심스레 다뤄진다
애완동물이 병들면 당신은 열심히 간호해 회복시킨다
소는 10200713.cattlerancher.com 같은 번호로 불린다
소는 다른 소들과 구분하기 어렵다
소가 병들면 당신은 다른 소로 교체해 버린다
인프라는 데이터 센터에 영구적으로 고정되어 있는 존재이다인프라는 무상태(stateless)이고, 수명이 짧고(ephemeral), 일시적이다
인프라는 오랜 시간을 들여 만들고 한 번 만들면 매주 유지 보수의 대상이 되며, 몇 년씩 지속되고, 마이그레이션할 땐 프로젝트 수준의 공을 들인다인프라는 자동화된 스크립트 등을 통해 금방 만들어지고, 거의 상시 수정/삭제/재생성된다
인프라는 유지 보수 시간 동안 수정되며 보통 루트 권한 같은 특수 권한이 필요하다인프라는 별도의 루트 권한 없이도 버전 관리되는 여러 스크립트를 이용해 아무 서비스나 수정할 수 있다
인프라는 서로 다른 팀들이 협력해야 전체 환경의 준비가 가능하다인프라는 단 한 번의 클릭만으로 컴퓨팅, 네트워킹, 스토리지 등의 전체 환경을 동적으로 제공받고 제공하는 자체 서비스다
인프라는 정적이며, 부하의 피크 시간대에도 안정적인 서비스 제공을 위해 항상 과도한 자원이 필요하다인프라는 유연하고 자동으로 스케일링되며, 서비스 부하 피크 시간대에는 그때의 상황에 맞춰 할당 자원량이 자동으로 조절된다
인프라는 사용 패턴과 관계없이 항상 정적인 양의 자본 비용이다인프라는 오로지 부하에 따라 자원을 사용한 양만큼만 지불하는 운영 비용이다

Ansible과 같은 도구는 프로비저닝 대상을 애완동물로 바라보고 있습니다. 이렇게 대상을 애완동물로 바라보고 관리하면 우리들은 어느새 집사(=노예)가 되어 버립니다. 만일 프로비저닝 대상을 애완동물이 아닌 소 떼와 같이 대체 가능한 자원의 집합으로 관리할 수 있다면, 우리는 집사가 아닌 자유로운 목동이 될 수 있습니다. 이는 시스템을 우리가 원하는 방향으로, 유연하고 확장성을 갖춘 시스템으로 만들어 갈 수 있는 초석이 됩니다(저를 전적으로 믿으셔야 합니다 🙂 ).

 

블록체인 네트워크 프로비저닝의 특징

블록체인 네트워크를 프로비저닝할 때 고려해야 할 점을 정리해 보았습니다. 

  • 블록체인 네트워크를 구성하는 각 노드는 저마다 고유한 권한과 설정을 가지고 있으며 자신들의 상태를 독립적으로 관리합니다. 심지어 서로 다른 버전의 코드를 가진 노드들이 하나의 네트워크를 구성하는 경우도 있습니다. 따라서 웹 서버를 프로비저닝하는 것과 같이 특정 블록체인 노드를 그대로 복제하는 방식으로는 블록체인 노드를 추가하거나 대체할 수가 없습니다.
  • 서로 다른 IDC 및 네트워크 환경에 위치한 블록체인 노드들이 네트워크에서 만나 블록에 대한 찬/반 투표를 쉼 없이 수행할 수 있도록 네트워크 접속 경로가 투명하고 유연하게 설정되어야 합니다.
  • 고유한 투표권을 가진 블록체인 노드들은 가능한 한 99.9%로 가용성을 유지해야 합니다. 이를 위해 주기적으로 블록체인 노드의 상태를 체크하고, 결함이 발견되면 즉시 시스템이 자동으로 복구 과정을 수행해서 장애 상태를 극복할 수 있어야 합니다.

이런 특징들을 바탕으로 블록체인 네트워크를 프로비저닝하는 방법을 소 떼의 관점에서 고민해 보고 해결하고자 했습니다. 그리고 블록체인 네트워크를 위한 프로비저닝뿐 아니라 기존의 프로비저닝 인프라를 어떻게 하면 좀 더 운영과 유지 보수가 편리한 환경으로 바꾸어 나갈 수 있을지도 함께 고민했습니다.

 

기존의 프로비저닝 구조(AS-IS)

아래와 같은 기존의 프로비저닝 환경에서는 블록체인 네트워크의 특성에 맞추어 프로비저닝하기가 매우 불편했습니다. 

  • Kerberos와 같은 인증 방식을 거쳐 프로비저닝 명령을 수행해야 했으며, 프로비저닝 명령의 수행 오류나 결과를 알기 위해서는 대상 서버에 접속하여 그 상태를 확인해야 했습니다. 이런 방법은 각 단계를 세심하게 모니터링하며 수행할 수 있다는 장점이 있었지만, 필요할 때 관리 대상 서버들을 손쉽게 교체하기 어렵게 만드는 원인이 되었으며, 관리하는 서버의 수가 늘어날수록 점점 관리 부담도 커졌습니다.
  • 서버를 프로비저닝하는 것과 이 서버와 연계된 로드밸런서를 준비하거나 갱신하는 과정이 서로 동떨어져 있으므로 애플리케이션이 서버의 규모(scale) 변화에 유연하게 대처하는 것이 어려웠습니다.
  • 프로비저닝을 수행하는 세부 명령과 서버의 상태를 모니터링하는 방법이 통일되지 않아 업무 전환이 어려웠고, 서비스 중인 시스템을 확충하거나 유지 보수하는 것이 어려웠습니다.

 

애플리케이션 컨테이너화

프로비저닝을 수행한 다음에도 블록체인 노드의 코드 변경은 빈번하게 발생합니다. 코드 변경이 있을 때마다 혹시 예기치 못한 부작용이 있는지 회귀 테스트(Regression Test)를 수행해서 확인하고, 특정 시나리오의 정상 동작 여부를 통합 테스트를 통해 검증해야 합니다. 블록체인 노드는 블록체인 네트워크에서의 합의를 기반으로 그 상태를 변경하니 이에 대한 여러 시나리오 테스트를 잘 수행하기 위해서는 블록체인 네트워크를 구성하는 노드들을 다양한 환경에서 손쉽게 프로비저닝할 수 있어야 합니다. 또한 동일한 환경과 조건에서 테스트를 반복 수행할 수 있어야 하며, 동시에 여러 테스트를 병행해서 수행하는 것도 가능해야 합니다. 테스트를 통과한 블록체인 노드가 운영 환경 등의 다른 환경으로 이음새 없이 배포되는 것도 가능해야 합니다.

이런 모든 요구 사항을 모두 충족시키기 위해서는 애플리케이션 컨테이너화 과정이 반드시 뒷받침되어야 합니다. 애플리케이션 컨테이너화란 애플리케이션이 OS(operating system) 수준의 가상화 기술을 기반으로 실행될 수 있는 것을 말하며, 가장 대표적인 컨테이너화 도구 및 컨테이너 런타임으로 Docker가 있습니다. 블록체인 노드를 컨테이너 기반으로 프로비저닝할 수 있게 되면, 한 번 빌드한 결과물을 재사용하여 다수의 블록체인 노드를 프로비저닝할 수 있게 됩니다. 애플리케이션을 기동하기 위해 필요한 시스템 자원을 컨테이너 런타임에서 제공받도록 했고, 애플리케이션은 이를 위한 설정을 모두 공개하여 이 과정을 거치고 나면 애플리케이션 코드 수준에서는 어떤 환경에서 프로비저닝될지 더 이상 고려하지 않아도 됩니다.

 

컨테이너 오케스트레이션 도구인 K8s가 필요한 이유

블록체인 노드를 포함한 다양한 애플리케이션을 컨테이너 기반으로 기동할 수 있게 되면서, 코드를 개발하는 단계와 프로비저닝하는 단계의 관심사를 분리할 수 있었으며, 다양한 애플리케이션을 편리하게 조합할 수 있게 되었습니다. 그런데 많은 컨테이너를 사용하게 되면서 컨테이너를 손쉽게 프로비저닝하고 이들의 생명 주기를 편리하게 관리해 주는 오케스트레이션 도구가 필요해졌습니다.

K8s는 컨테이너화된 애플리케이션을 오케스트레이션해주는 도구입니다. Google에서 만들어 CNCF라는 오픈소스 재단에 기부한 오픈소스 프로젝트이기도 합니다. 오픈소스 커뮤니티의 많은 사랑을 받으며 표준화된 여러 기술을 바탕으로 성장하고 있습니다.

 

K8s가 지원하는 것

컨테이너화된 애플리케이션이 준비되었다면, 컨테이너로 구동하기 위해 필요한 세부적인 명령과 과정은 K8s에게 맡길 수 있습니다. 즉, K8s의 사양에 맞추어서 프로비저닝이 완료되었을 때의 최종 상태만을 K8s에 알려주면, 복잡한 프로비저닝 수행 과정과 명령들은 이벤트 기반으로 K8s에서 모두 처리해 줍니다. 운영 도중에 업데이트가 필요할 때에도 변경 후의 상태를 K8s에게 다시 알려주기만 하면 됩니다. 아래에는 제가 처리했던 다양한 개발과 운영 이슈를 바탕으로 추천하고 싶은 K8s의 기능을 나열해 보았습니다.

특징설명
간결한 CLI와 YAML 기반 설정 방식(참고)을 제공하고, Minikube와 같은 편리한 로컬 테스트 환경 지원
  • Ansible 기반의 프로비저닝 명령은 작성자의 취향이 반영된 파편화된 여러 파일을 모두 해석해야 했으며, 이를 로컬 환경에서 재현해 보는 것 또한 매우 어려웠습니다.
  • 이동 중인 지하철과 같이 네트워크가 불안정한 곳에서도 선언적 프로비저닝 명령이 원격지의 K8s API 서버로 도달하기만 하면 됩니다. 나머지 세부적인 단계는 K8s가 담당합니다. 즉 Ansible처럼 명령이 수행되는 긴 시간 동안 SSH 커넥션을 유지하지 않아도 됩니다.
자동화된 롤 아웃과 롤백 지원
  • Nginx에 정적 컴파일(static compile)로 포함된 OPEN_SSL에 치명적인 보안 결함(예시)이 보고되어 업데이트가 시급한 경우에도 동일한 시스템에 설치된 다른 애플리케이션엔 영향을 주지 않고 다양한 방법(참고)으로 업데이트를 수행할 수 있습니다.
컨테이너의 복제본 수를 편리하게 조정할 수 있는 기능(참고) 지원
  • 간편한 단일 CMD 및 YAML 설정 변경으로 Pod 단위로 컨테이너의 수를 조정할 수 있습니다.
서비스 디스커버리(discovery)와(참고) 로드밸런싱 지원
  • 컨테이너의 복제본 수를 변경하면 연결된 해당 컨테이너를 대상으로 하는 로드밸런서의 설정도 함께 변경하여 요청이 잘 분배될 수 있도록 합니다.
자동화된 복구(self-healing) 지원
  • 프로세스가 올바르게 동작하고 있는지 확인할 수 있는 다양한 방법을 제공하고 문제가 있다고 판단되면 컨테이너를 다른 시스템에서 재생성합니다(참고).
  • 트래픽을 처리할 준비가 되었는지 확인할 수 있는 다양한 방법을 제공하고 상태가 정상인 경우에만 트래픽이 전달되도록 합니다(참고).
자동화된 빈 패킹(bin packing)(참고) 지원
  • 컨테이너별로 사용할 수 있는 컴퓨팅 자원(CPU, RAM, 디스크 공간)의 최소/최댓값을 사전에 설정할 수 있으며, CPU의 사용량을 기준으로 자동으로 수평 확장할 수 있는 기능(참고)을 제공합니다.
시스템에 종속되지 않으면서 고가용성을 바탕으로 작업을 수행할 수 있는 방법(참고)과 주기적으로 스케줄링해서 실행할 수 있는 방법(참고) 제공
  • Java 개발자에게 익숙한 마이크로 배치 프레임워크인 Spring batch를 K8s에서 사용할 수 있는 도구도 마련되어 있습니다.

이 밖에도 컨테이너에 저장소와 접근 권한을 할당하는 기능, 네트워크 보안 정책, 컨테이너를 사용자별로 어떤 권한으로 실행시킬지에 대한 설정 등 컨테이너를 안전하고 아름답게 사용하기 위한 대부분의 기능을 지원하고 있습니다.

 

CI/CD 파이프라인과 통합된 K8s기반의 프로비저닝 구조(TO-BE)

과거의 프로비저닝 방식은 코드 변경에 따른 CI/CD와 프로비저닝 과정이 개발자나 인프라 관리자의 도움이 있어야만 완결될 수 있는 구조였습니다. 하지만 K8s를 기반으로 CI/CD 파이프라인을 통합하면 풍부한 시스템 자원을 이용해 다양한 작업과 테스트를 빠르게 수행할 수 있으며 자동화된 빌드 및 배포 환경을 구축해 나갈 수 있습니다. 

이전 단계에서 애플리케이션 컨테이너화를 통해 애플리케이션의 개발과 빌드 및 배포를 위한 설정을 나눌 수 있었다면, 이번에는 프로비저닝을 위한 설정과 실제 수행하는 단계를 분리할 수 있게 되었습니다.

아래에는 위 구조의 특징을 나열해 보았습니다.

  • K8s의 사양으로 통일된 프로비저닝 CMD/YAML을 사용하여 이해하기 쉽고, 운영 및 유지 보수가 편리합니다.
  • 배포된 컨테이너에 요청을 잘 전달할 수 있도록 자동으로 네트워크 설정을 업데이트할 수 있습니다.
  • K8s가 다양한 배포 전략과 옵션을 제공하므로 이를 팀의 배포 전략에 따라 적절히 선택해서 업데이트 작업을 수행할 수 있습니다.
  • 코드가 변경될 때마다 Docker 이미지를 생성하고 컨테이너를 기반으로 테스트를 수행하여 격리된 테스팅 환경을 일관적으로 유지할 수 있습니다.
  • 테스트는 단일 머신이 아닌 풍부한 컴퓨팅 자원이 제공되는 K8s 클러스터에서 병행해서 수행시킬 수 있으므로 보다 빠르게 피드백을 얻고 버그를 수정할 수 있습니다.
  • 테스트를 모두 통과하면 해당 Docker 이미지를 그대로 운영 환경까지 자동으로 배포할 수 있으므로 사람의 개입을 최소화하면서 검증된 코드를 정확하게 배포할 수 있습니다. 

 

K8s 기반 프로비저닝 구현 과정

K8s를 기반으로 블록체인 네트워크를 프로비저닝하기 위해 어떤 과정을 거쳤는지 상세히 소개하고자 합니다. 구체적인 코드를 제공하기는 어렵지만, 블록체인 네트워크에서 필요한 빌드 과정을 이해할 수 있도록 일부를 발췌하여 설명하겠습니다.

 

K8s 기반 블록체인 네트워크 디자인

K8s 기반에서 블록체인 네트워크를 프로비저닝하는 과정을 검증해 나가기 위해 블록체인 노드 4대의 구성을 K8s가 제공하는 사양을 이용해 아래 그림과 같이 디자인해 보았습니다. 이를 시작점으로 삼아 조금씩 발전시켜 나가고자 합니다.

  • 블록체인 노드별 개별 업데이트가 가능하도록 복제본 수(replicas)가 하나인 Deployments로 구현했습니다. 
  • 블록체인 노드를 안정적으로 운영하기 위해서 로그/상태 모니터링과 경고(alert) 같은 기능을 제공하는 로깅 에이전트를 사이드카 패턴으로 추가했습니다. 
  • 블록체인 노드의 상태를 K8S-Worker-Node에서 유지할 수 있도록 K8S-Worker-Node에 라벨(label)을 추가하고 Pod에 Node Selector 옵션을 추가해서 서로 연결했습니다.
  • 클라이언트 사이드 로드밸런싱을 사용하고 있어서 로드밸런서나 서비스의 사용은 고려하지 않았으며, 성능 저하를 방지하기 위해 HostNetwork를 사용했습니다.

 

블록체인 노드 준비하기

블록체인 네트워크를 처음으로 구성할 때는 크게 아래와 같은 구성이 필요합니다.

  1. 블록체인 노드
    1. 노드 설정 파일 생성
    2. 블록체인 노드 바이너리 빌드
  2. Docker 이미지(dockerizing)
  3. K8s object management YAML file

위 1단계와 2단계를 단일 명령으로 수행해주는 GoLang 기반의 CLI 도구를 직접 개발하여 구성했습니다.

  • 블록체인 노드 구동에 필요한 설정 값을 OS의 환경 변수에서 읽어오게 한다면, 물리적인 블록체인 노드의 설정 파일을 K8s의 Configmap으로 대체해서 보다 더 유연하게 관리할 수 있다고 생각합니다.
provisioning이라는 주 명령어(main-command)와 K8s라는 보조 명령어(sub-command)로 구성되어 있습니다.
build 명령을 수행한 화면입니다. 기본적으로 4개의 노드로 구성된 TestNet 설정이 생성되며 포트(port)는 명시적으로 지정한 예시입니다.
build 명령을 수행한 결과 화면입니다. 
  1. k8s-chain-p2p-23656: Testnet의 고유한 식별자인 chainId입니다.
  2. binary: 블록체인 노드의 실행 파일이 위치합니다.
  3. node[N]: 각 노드별 설정과 서명 파일 등이 위치합니다.

 

K8s Deployment YAML 설정 살펴보기

kind: Deployment
metadata:
  labels:
    validator-order: "0" //블록체인 노드의 고유한 식별자
    p2p-port: "23656" //블록체인 노드의 P2P 접속 포트
    chain-id: k8s-chain-p2p-23656 //블록체인 네트워크의 고유한 식별자
  name: validator-0-p2p-23656
spec:
  replicas: 1
  template:
    spec:
      컨테이너s:
      - env:
        - name: BINARY_HOME
          value: /k8s-chain-p2p-23656/binary/linkd
        image: docker.hub-example.com/link-network/link:latest
        livenessProbe:
          httpGet:
            port: 23657
            path: /status?
        readinessProbe:
          httpGet:
            port: 23657
            path: /ready?
          image: linkdnode:latest
        name: blockchain-node
        ports:
        - Port: 23656
          protocol: TCP
        volumeMounts:
        - mountPath: /linkd
          name: storage
      nodeSelector:
        validator-order: "0"

위 내용은 블록체인 노드를 K8s에 Deployments 개체로 오케스트레이션을 요청하기 위해 생성한 validator-0.yaml 파일의 내용을 일부 발췌한 것입니다. Deployment는 컨테이너의 복제본 수에 대한 처리를 ReplicaSet에 위임하고 있으며 ReplicaSet은 컨테이너의 생명 주기를 Pod을 통해 처리하고 있습니다.

  • 컨테이너가 생성되면 이를 찾을 수 있도록 고유한 식별자를 부여했습니다.
  • 블록체인 노드가 건강한 상태를 유지하는지 확인할 수 있도록 livenessProbe와 readinessProbe를 설정했습니다.
  • Pod의 환경 변수로 BINARY_HOME과 같은 이름의 OS 환경 변수를 설정하여 Pod에서 참조할 수 있도록 하였으며, 이 밖에도 ConfigMap과 Secret과 같은 다른 개체를 활용해서 컨테이너에 고유한 속성을 부여하는 것도 가능합니다.
  • Pod의 상태를 특정 K8S-Worker-Node에서만 유지되도록 하기 위해 nodeSelector라는 설정을 추가하였으며, storage라는 볼륨을 마운트시켜 Pod에서 사용할 수 있게 하였습니다. 

 

블록체인 네트워크를 K8s에 컨테이너화 시키기

아래 명령어를 수행하여 앞서 준비한 Deployment들에 대해 K8s가 프로비저닝을 수행하도록 합니다.

Deployment 설정을 이용해 K8s에 프로비저닝 명령을 수행한 화면입니다.
배포 단계에서 추가한 고유한 속성 값인 레이블(Label)을 기반으로 K8s에 생성된 개체들을 확인한 화면입니다.

앞서 개발한 툴을 활용해 어떤 곳이든 K8s 클러스터만 준비되어 있다면 다양한 설정으로 블록체인 네트워크를 손쉽게 구성할 수 있게 되었습니다. 또한 기존에는 단일 머신에 단일 블록체인 노드만 기동할 수 있었던 반면에, 단일 머신에 여러 블록체인 노드를 구동해서 서버 자원을 보다 효율적으로 활용할 수 있게 되었습니다.

 

K8s 기반 블록체인 네트워크 프로비저닝 고도화

이후에는 아래와 같은 점들을 고도화할 예정입니다.

  • 블록체인 노드의 서명 파일을 보다 안전하게 관리
  • Deployments가 제공하지 않는 부가적인 기능을 이용하기 위한 CRD 사양 정의 및 구현
  • 블록체인 노드의 네트워크 접속 경로로 호스트 네트워크 유형을 사용하지 않고 서비스를 통해 연결할 수 있도록 변경
  • 블록체인 노드의 상태가 특정 K8S-Worker-Node에 종속되지 않도록 개선
  • 볼륨에 대한 액세스 정책 등을 추가해서 예기치 못한 스토리지 사용으로 데이터가 훼손되는 것을 방지

 

블록체인과 K8s의 미래

K8s는 자기 자신을 구성하는 기능도 Deployments, Pod과 같은 K8s의 기본 오브젝트로 구현하고 있습니다. 그리고 새로운 기능을 추가하고 싶을 땐 Operator Pattern으로 기능을 추가할 수 있습니다. 이 기능을 활용해 K8s 커뮤니티에서는 아래와 같이 다양한 애플리케이션 개발 영역을 커버하기 위한 기능을 계속 추가해 나가고 있습니다.

  • 소스 코드를 작성하면서 실시간으로 배포해서 그 결과를 살펴볼 수 있게 돕는 Skaffold
  • 간편하게 K8s 프로비저닝 명령을 사용할 수 있게 해주는 패키지 매니저 Helm
  • CI/CD와 통합해서 자동화된 배포를 지원하는 Keel
  • 서버리스(serverless) 아키텍처를 지원하기 위한 Knative
  • 머신러닝 업무 처리에 필요한 도구들을 지원하는 Kubeflow

K8s의 변화를 살펴보면서, 문득 실리콘 밸리라는 드라마에서 스마트 냉장고를 해킹해서 자신들이 만든 클라우드 서비스의 데이터 유실 위기를 모면한 일화가 떠오릅니다. 기술의 발전으로 컨테이너 기반의 애플리케이션 실행 환경이 보다 대중화되면, 스마트 가전이나 스마트폰을 경량화된 K8s와 같은 도구를 이용해 손쉽게 프로비저닝하는 것도 가능하다고 생각합니다. 또한 MySQL을 CRD로 만들어 사용하는 것처럼(참고), 블록체인 네트워크를 K8s에서 지원하는 CRD로 보다 표준화된 형태로 구현해서 사용하게 될 날이 올 것이라 생각합니다. 그렇게 되면 편리하게 주머니 속 스마트폰에 블록체인 노드를 가지고 다니면서 언제 어디서나 환전/송금 수수료 없이 가상 화폐를 사용할 수 있으며, 블록체인 네트워크에 참여해서 블록체인 네트워크로부터 노드 운영에 대한 수수료를 받는 날이 올 것이라 생각합니다.

 

여정의 소회(所懷)

처음 K8s에 대한 공부를 시작하게 된 계기는 높은 가용성과 효율성, 그리고 유지 보수 및 운영이 편리한 프로비저닝 기술을 터득하고 싶었기 때문입니다. 또한 탄력성과 유연함을 가지는 고가용성과 고효율성을 지원하는 소프트웨어를 디자인하기 위해서는 프로비저닝 방법과 도구를 다양하게 경험하고 보다 선명하게 이해할 필요가 있다고 생각했습니다. 꼭 K8s 기반으로 프로비저닝하지 않더라도 K8s의 면면을 살펴보면 커뮤니티를 통해 정제된 프로비저닝 철학과 소프트웨어 디자인, 그리고 시스템 디자인에 대한 정수를 배울 수 있다고 생각합니다. 이러한 마음으로 K8s에 대한 공부를 계속해 오다 보니 CKAD(Certified Kubernetes Application Developer)라는 인증 프로그램을 알게 되어 도전하였고, 결국 CKAD가 될 수 있었습니다.

CKAD 자격증명 배지입니다. 이미지를 클릭하면 자격의 유효성을 검증할 수 있는 공식 페이지로 이동합니다.

LINE에는 같은 팀이 아니어도 함께 논의할 수 있는 최고의 동료들이 많이 있습니다. 퇴근 시간이 훌쩍 지났을 무렵에도 프로비저닝 구상안을 들고 찾아갔을 때 흔쾌히 좋은 방향을 찾기 위해 함께 리뷰해 주신 최정대 님, 블록체인 네트워크를 K8s 기반으로 설계한 것에 대해 다양한 피드백을 주어 제 시야를 넓혀주신 이어형 님과 이정복 님, Caravan이라는 K8s 클러스터를 제공해 주시고 노하우를 전수해주신 이승 님과 손준호 님께 이 자리를 빌려 감사한 마음을 전하고 싶습니다. 끝으로 이 글을 함께 리뷰해 주신 LINE의 동료들, 그리고 함께 블록체인이라는 배를 타고 도전해 나가고 있는 믿음직스러운 팀 동료들에게도 깊은 감사의 마음을 전하고 싶습니다.

Related Post