스트림(Stream)

자바(Java) 세계에서 언제부터인지 스트림(Stream) 이라는 단어를 목격하게 되었다. 내 기억으로는 Java 8 에서부터 시작된 것 같은데 난데없는 이 단어가 왜 그렇게 핵심이 되었는지가 의문이였다. 도대체 왜 스트림(Stream) 이냐 하는 질문에 대한 대답을 듣기도 어려웠던 시절이기도 하다. 그져 사용하는 방법을 익히는데에 몰두하는 모습만 목격됐을 뿐이다.

java.util.stream

스트림(Stream) 에 대한 정의는 다양하다.

데이터 소스(Array, List) 로부터 흐름을 가지는 데이터의 집합체이며 통합연산을(bulk processing) 통해 데이터를 변형시키고 최종적으로 소비자가 그 데이터를 소비하도록 한다.

스트림을 다루게 되면 항상 다음과 같은 데이터 소스들을 만나게 된다. 모두 데이터의 집합체들이다.

  • Array
  • List

하필 왜 데이터 집합체들일까

컴퓨터 알고리즘 필요성과 유사한 스트림(Stream)

난데 없이 컴퓨터 알고리즘을 꺼내온 이유가 있다. 컴퓨터 알고리즘을 공부할때에 가장 먼저 만나는 것이 정렬(sort)문제이다. 그런데, 이런 질문을 하게된다.

왜 하필 정렬부터 인가?

이에 대한 대답은 간단다.

Compute 연산과 Memory 공간을 절약하기 위해서..

컴퓨터가 중복된 데이터를 어떻게 찾아낼까? 정렬을하면 쉽게 해결된다. 정렬된 데이터가 아니라면 모든 데이터를 비교해야 하지만 정렬할 경우에 같은 위상을 같은 데이터 값이 나오게 되는데 이를 하나만 남기고 지우면 간단해 진다.

이렇게 함으로써 Memory 공간도 절약하게 되고 이렇게 중복되지 않은 데이터를 가지고 Compute 연산을 할 경우에 당연히 그에 들어가는 비용도 줄게 된다.

자바에서 스트림도 이와 유사하다.

자바에서 데이터를 다루는 방법은 다양한다. 이는 데이터 소스를 통해서 다루어지는데, 이 데이터 소스를 간단하게 타입(Type) 이라고 생각해보자. 정수형, 문자열 등은 가장 단순한 타입이다.

이런 타입들은 단 하나의 데이터만 저장하고 있을 뿐 “데이터들” 을 가지고 있지 않다. Compute 연산 알고리즘에서는 여러 데이터들의 집합을 다룬다. 컴퓨터가 가지고 있는 데이터들이란 집합을 이야기 한다. 따라서 데이터 소스라고하면 “데이터들” 을 지칭하며 자바에서 이런형태의 데이터 타입은 Array, List 가 대표적이다.

그럼 이런 생각을 하게된다. 데이터 집합체들을 어떻게 하면 빠르게 중복을 제거하고 연산을 하게 만들 것인가? 과거에 For loop 문과 같은 것을 이용해서 조건식을 붙이면서 사용을 할 수도 있다.

람다(Lambda)

연속된 데이터들을 다루기만 할 거라면 단순하게 For loop 문을 이용하면 된다. 만일 이런 생각을 하게 된다.

연속된 데이터를 처리할때에 병렬을 이용해서 처리보자.

For loop 문에서 병렬처리는 쉬운게 아니다. Thread 를 이용할 수도 있지만 이건 동시성 프로그래밍이지 병렬은 아니다.

이를 위해서 자바 8 에서는 람다(Lambda) 를 도입했다. 이것에 대한 정의를 보면 함수형 프로그래밍(Funtional Programming) 이라는 말을 자주 접하게 되는데 병렬연산을 가능하게 하는 부분이다.

자바 8 스트림은 이 람다를 기반으로 한다. 결국에 스트림은 벌크 프로세싱(Bulk Processing) 을 람다를 사용해 구현하여 빠른 고속 데이터 처리가 가능하다.

스트림 – 흐른다.

스트림의 중요한 특징은 흐름이다. 프로그래밍에서 데이터를 다룰때 흐름 없이 다루는 경우도 많다. 앞에서 컴퓨터가 다루는 데이터는 “데이터들” 이라고 했는데, 이것들을 흐름을 가지고 연산을 수행하는게 스트림이다.

“흐른다” 라는 말을 수도관을 떠올리게 한다. 왼쪽에 물을 흘려보내면 오른쪽으로 물이 나온다. 데이터를 왼쪽에서 흘려보내면 오른쪽으로 물이 나온다. 만일 이 물이 설탕물로 만들고 싶다면 중간에 설탕을 뿌리면된다. 이물질을 제거하고 싶다면 이물질 제거기를 설치하면 된다.

이렇게 보면 누군가 데이터를 흘려보내는 놈이 필요하고 데이터를 받아 마시는 놈이 필요하게 된다. 이것을 Producer 와 Comsumer 관계라고 부른다.

리액티브 와 무슨 관계?

자바 스트림과 Reactive 관계보다 차이가 존재한다.

스트림(Stream) 은 데이터를 생산하면 즉각 소비가 발생한다. 하지만 리액티브 는 그렇지 않다. 리액티브 은 시간이 지남에 따라서 생산과 소비가 발생한다. 생산과 소비가 즉각적이지 않다.

이말을 잘 생각해 볼 필요가 있다. 스트림은 데이터를 다루는 영역에서 매우 유용할 수 있다. 프로그래밍 연산을 할 경우에 적합하게 사용되어질 수 있다. 하지만 Reactive 는 프로그래밍 연산보다 네트워크를 통한 데이터 요청과 리턴에 접합한 모델이라고 할 수 있다.

차이는 또 있다. 리액티브 에서 생산자는 반드시 흐름 데이터만 만들지 않는다. 대표적으로 웹에서 클릭(Click) 조차도 리액티브 에서 생산자가 될 수 있다. 그래서 연속된 데이터 흐름이 없다보니 뭔가 생산하는 개념이 아닌것이여서 생산자(Producer) 라는 말을 쓰지 않는다.

“즉각적으로 소비가 발생하지 않는다” 라는 말도 중요하다. 비동기적으로 데이터 리턴이 발생한다는 것을 의미 한다. 하지만 리턴 값을 받기 위한 준비는 항상하고 있다는것도 중요하다.

리액티브 는 네트워크를 통한 데이터 요청, 리턴 모델에 적합하다. 리액티브 요청한 것에 대한 데이터들을 다룰때에는 스트림을 이용할 수도 있다.

Time-Series data 특징

Time-Series 데이터베이스가 존재한다. InfluxDB, Prometheus 등이 대표적인데 Time-Series 데이터베이스의 특징에 대해서 정리 본다.

  1. High-speed data ingest: ‘고속 데이터 수집’ 으로 번역된다. IoT 사용 사례나 시장 분석 데이터와 같이 꾸준히 고속으로 도착하는 연속된 혹은 한꺼번에 밀려드는 대량의 데이터를 처리해야 한다. 대부분의 솔루션들은 데이터를 24시간 365일 처리하도록 되어 있다.
  2. Immutable data: ‘변경될 수 없는 데이터’ 로 번역된다. Immutable 은 프로그래밍에서도 자주 언급되는 단어다. 데이터베이스에 한번 Insert가 되면 데이터 포인트는 데이터가 만료(expire) 되거나 삭제(delete) 되기전까지 그 어떠한 변경도 일어나지 않는다. 이런 데이터는 전통적으로 timestamp 와 아주 적은 데이터 포인트를 가지는 로그 데이터들이다.
  3. Unstructured labels: Time-series 데이터는 일반적으로 많은 소스들에 의해서 오랜 기간 동안 지속적으로 생산되어진다. 예를들어, Iot 경우에, 모든 센서들은 time-series 데이터의 소스다. 이런 상황에서, 시리즈의 각 데이터 포인트들은 소스 정보와 라벨로 다른 센서의 측정치들을 저장한다. 모든 소스들의 데이터 라벨들은 같은 구조나 순서들을 보장하지 않는다.
  4. Diminishing value over time: ‘시간이 지남에 따라 가치가 낮아진다’ 정도로 번역할 수 있겠다. 적절한 시간 범위를 가진 집계된 요약 데이터만이 미래에 연관성이 있을 수 있다. 1년 후에, 대부분의 사용자들은 마이크로초 단위의 범위에 저장된 모든 데이터 포인트를 필요로하지 않을 것이다. 오직 수분, 수시간, 몇일동안 집계되어지고 정형화된 데이터만이 필요로하게 된다.
  5. Queries are aggregated by time intervals: time-series 데이터에 기반한 차트는 확대/축소를 가능하게 한다. 이건 시간 간격에 의해서 그들이 데이터를 수집함으로써 그렇게 할 수 있다. 전통적으로, time-series 데이터 쿼리는 집계들이다. 이것은 데이터베이스 시스템으로부터 개별적인 레코드들을 검색하는 것과 대비된다.

대한민국 병.

앞에 DBA 에 대한 비판글을 쓴적이 있다. 실제로 겪은 일이기도 하고 실제로 일어나는 일이기도 하다. 혹자는 “너의 경험이 전부가 아닐 진데, 전체로 매도하고 있다” 라고 항변하겠지만 전체적인 흐름을 모르고 하는 소리다.

환경의 변화 = 안해도되는 것들.

DBA 들도 환경의 변화를 겪고 있다. 적어도 내가 있는 분야, 그러니까 구체적으로 말하면 AWS 클라우드 시스템을 다루다보면 이러한 현상을 자주 목격한다.

AWS 클라우드에는 관리형 데이터베이스인 RDS 서비스가 존재한다. 데이터베이스 서버를 설치하거나 백업을 직접 구축하는 것이 없이 이러한 것들을 웹 인터페이스를 통해서 손쉽게 할 수 있다. 서버 설치는 아예 없고 그것을 관리하라고도 안한다.

문제는 DBA 들이 이것을 자신들의 직업적인 업무의 축소, 그러면서 단가는 그대로이면서 하는일을 떨궈버리는데 적극 활용한다는 것이다.

이들의 사고 방식은 간단하다. AWS 클라우드에서 제공하는 RDS 서비스이다 보니 그건 AWS 를 다루는 사람이 해줘야 한다는 것이다. 자신들은 이제 SQL 만 짜고 데이터만 만지면 된다는 사고방식을 고수한다.

더 웃긴건 그것이 이제 업계 표준인냥 떠들어 댄다는 것이다. RDS 백업 설정은 더 이상 DBA 가 하는 일이 아닌것이고 그것에 대한 업무 일채를 AWS를 다루는 사람이 해야 한다는 입장인 것이다. 그것이 자신의 주장일 뿐이라고 생각하는게 아니라 이제는 DBA 업계가 그렇게 하고 있다라고 주장한다.

AWS 클라우드 환경에서는 이게 DA나 DBA 들이 작정하고 주장하고 있는게 현실이다. 100이면 100 전부다. 자신들은 AWS 를 모른다고 강변하고 그것을 자신들이 알아야 할 이유가 없다고 강변하면서 SQL 만 잘 다루면서 단가는 그대로 가지고 갈려는 입장인 것이다.

자신이 해야할 일의 영역을 축소하고 적게 일하면서 돈을 많이 받는 계기로 삼게다는 심리가 아니고서야 이렇게까지 할 이유는 없다. 만일 자신이 진정으로 직업적 마인드나 윤리 의식이라도 가지고 있다고 한다면 적어도 AWS 클라우드에서의 데이터베이스를 공부라도 할 텐데, 그래서 RDS 가 무엇이고 S3 나 혹은 Dynamo DB 등과 같은 것들도 공부를 해야할 텐데 AWS 클라우드의 자원이니 자신들은 안해도 되는 거다라는 사고방식.

이쯤되면 이건 병이다.

개발자 = 코딩만 하고 결과만 나오면 그거까지.

DBA 만 깐거 같으니 DBA가 만고의 역적인 되는 느낌인데, 개발자들도 만찬가지다.

논의에 앞서 간단하게 내 경력을 말하면 거의 풀스택에 가깝다. DBA 로서 SQL 을 깊게 섭렵하지는 않았지만 데이터베이스 시스템을 꽤 다뤘었다. 개발자… 자바, 파이썬, Golang, Javascript.. C. 이래저래 할거는 다 해봤다. 특히나 프리랜서로 일을 하면서 요새는 자바를 자주 쓰는 거 같다. 한국에 SI 에서는 죄다 스프링기반으로 제작되고 있다보니 어쩔 수 없는 노릇이다.

이런 개발자적인 경력외에도 시스템 및 클라우드 경력도 가지고 있기에 어느 프로젝트에라도 가게되면 개발자로 지원해서 일을하다가도 어느샌가 시스템 인프라과 개발자들 사이에 뭔가를 중재하는 역할을 하는 경우로 바뀌게 되기도 한다.

이런 상황에 서 있다보면 개발자들을 아주 혐오하게 되는 경우가 아주 많다. 대표적인것이 자신이 만든, 자신이 작성한 코드로 작동하는 기능 혹은 결과물에 대한 성능지표를 계산하지 않는 것이다.

AWS 클라우드에 자바로 제작한 서버를 올린다고 가정해보자. 그러면 AWS 클라우드에서 이 서버를 운영하기 위한 자원이 필요할 것이다. EC2 Instance 를 생성해 그곳에서 자바 서버를 운영할거라면 어떤 타입이 적절한지에 대한 성능지표가 중요해진다.

그러한 성능지표는 누가 제공해야 할까?

당연히 개발자가 제공해야 한다. 성능이란 결국에는 그것을 만든 사람이 제일 잘 알 수밖에 없다. 굳이 코드를 눈으로 보지 않는다고 하더라도 머리속에서 대충 돌려보고 어디에서 병목구간이 생길수 있는지를 알수 있는 사람은 그것을 만든 사람이 제일 잘지 않겠나.

거기다 서버를 제작했다고 한다면 당연히 기획했던대로 성능이 나오도록 제작을 해야할 의무 또한 개발자에게 있다.

하지만 개발자가 자신이 제작한 서버에 대해서 성능지표를 제공하지 않는다. 적어도 한국의 SI 업계에서는 말이지.

이들의 사고방식은 어짜피 서버를 세팅하는 것은 인프라를 담당하는 사람이 하는 거니까 알아서 하라는 사고방식이다.

경력이 얼만데 서버 세팅하는데 감도 못잡아요?

개발자가 인프라 담당자에게 한 말이다. 인프라 담당자는 서버를 세팅해야하니 개발한 서버가 필요로하는 스펙을 알려달라고 했다고 한다.

용어에 혼동은 있었던 것 같다. 인프라 담당자는 “서버 스펙” 이라고 말을 했으니.. 개발자들이 그런 용어를 사용할 이유는 없는 것이였다. 그렇다고 해서 개발자가 그것을 경력 운운하면서 감도 못잡냐고 핀잔을 줄 권한은 어디에 있나.

그래서 내가 말을 바꿔 개발자 당신이 개발한 서버가 프로덕트 환경에서 동작하는데 필요로하는 메모리, CPU 사용량등의 대한 성능지표를 알려달라고 했다.

모르겠는데요. 테스트를 해봐야 하는데 성능 테스트는 제가 안해요.

단 1초의 망설임도 없이 나온 말이다.

적어도 자신이 개발한 결과물에 대해 어느정도의 성능을 가지고 있는지 정도는 파악하고 있어야 하는게 예의 아닌가? 아무나 개발자라는 딱지를 붙이지 않는다. 내가 볼때 개발자라면 최소한 성능지표정도는 자신있게 말할 수 있어야 하는 것이며 그것은 개발자라면 당연히 가져야할 책임이자 의무라고 생각한다.

하지만 성능을 알려면 테스트를 해야하고 그래서 테스트는 개발자가 하는게 아니라는 의식때문인지 그것은 개발자가 해야할 일이 아니라고 강변하는게 개발자들의 현실이다.

책임과 의무를 회피하기에 급급한 한국사회

프리랜서를 하다보면 다양한 사람들을 만나게 된다. 개발자, 기획자, 회사의 임원등등 다양하다. 개발자들의 경우에 대부분 자신들의 환경에 대한 불만을 많이 토로한다. 야근에다가 주말에까지 나와서 일을 해야하는 현실을 못마땅해하는 것이다. 거기다 경력 뻥튀기에 대해 비양심적인 행위라며 비난하기도 한다.

그들이 야근을 많이하고 일을 많이하는 것은 안타까운 일이다. 하지만 내가 여태까지 만나본 개발자들 중에 책임감을 가지고 일을 하는 사람은 단연코 단 한 사람도 없었다. 거기다 개발을 하는데 있어서도 이런 부분은 이런 기술을 적용하는 것이 낫겠다라는 고민을 하는 개발자도 단 한명도 없었다.

저마다 벽을 만들어서 그 벽을 넘어서려고 하지 않는다. 문제는 그 벽이라는 것이 개발자는 코딩만 하면 장땡, DBA 는 쿼리만 날리면 장땡이라는 벽이다. 나머지는 신경을 써야할 이유도 없고 그것이 내가 책임을 가지고 있어야 하는 이유도 없다는 인식이 팽배하다 못해 그것이 법처럼 여기지고 있다는데 있다.

개발자들의 잘못된 코드로 인해서 발생되어지는 시스템 장애를 인프라 담당자가 독박쓰면서 막고 있는 현실을 그들은 나몰라라 한다.

거기다 프로젝트를 수행하는 업체도 개발에서 발생한 문제를 인프라적인 요소로 땜빵할려는 마인드가 거의 지배적이다. 그렇게 하는 것이 정식인냥 떠들어대고 있으니…

한국 병이다. 개발자들이나 DBA 들을 보고 있노라면 이런 생각이 든다. 어디 SI, IT 분야만 이러겠나. 뭐든 일을 적게하면서 돈은 많이 받고 싶고, 뭐든 문제가 복잡해보이고 귀찮은 것은 남에게 떠넘기는 것이 능력으로 치부되는 사회.

뭐든 안하고 돈 받는게 능력으로 인정되는 사회… 양심, 책임, 의무.. 그런걸 주장하는 사람은 능력이 없는 사람이건 뭘 없어보이는 사람정도 평가 절하되는 사회.

소프트웨어 엔지니어링에서 파이프라인(Pipeline)은 무엇인가? Deployment, CI & CD 파이프라인에 대한 소개

이 글은 bmc blogs 의 “What is a Pipeline in Software Engineering? Intro to Deployment, CI, & CD Pipelines” 을 번역한 것 입니다. 원작자의 허락없이 재개시 및 상업적 이용은 불가합니다.

https://www.bmc.com/blogs/deployment-pipeline/

소프트웨어 엔지니어링 팀에서 파이프라인(pipeline)은 개발자나 DevOps 전문가가 효율적이면서도 확실하게 그들의 코드를 컴파일(Compile), 빌드(Build) 그리고 그들의 프로덕션 컴퓨팅 플랫폼에 배포(Deploy) 하게 해주는 자동화된 프로세스들의 묶음(set) 이다. 파이프라인이 이래야 한다거나 반드시 활용해야할 도구(Tools)를 지정하는 강하고 빠른 규칙은 없지만, 파이프라인이 가져야할 가장 일반적인 컴포넌트들이 있다. 빌드 자동화(build automation)/지속적 통합(continuous integration), 테스트 자동화(test automation), 그리고 배포 자동화(deployment automation) 이다.

일반적으로 파이프라인은 다음의 카테고리로 구분되는 일련의 도구들로 구성된다.

  • Source Control
  • Build tools
  • Containerisation
  • Configuration Management
  • Monitoring

소프트웨어 배송 파이프라인(Software Delivery Pipeline) 개념의 핵심은 어떤 파이프라인의 단계 사이에 수동적 단계나 수동적인 변경이 필요없는 자동화(automation) 이다. 휴먼에러(Human error)는 이러한 지루하고 반복적인 작업을(역, 파이프라인의 단계들을 말한다) 수동으로 하게되면 발생할 수 있고 결국 잘못된 배포로 인해 올바른 산출물 생성에 영향을 미치고 잠재적으로 SLA 까지 영향을 준다.

Deployment Pipeline

배포 파이프라인은 자동화된 방식으로 버전 컨트롤(Version control) 로부터 코드를 가지고 오고 당신의 애플리케이션 사용자에게 손쉽게 활용할 수 있도록 만들어주는 프로세스이다. 개발팀이 프로젝트나 기능에 대해 일을 할때에 그들의 일을 빌드, 테스트, 배포를 위한 확실하고 효율적인 방법이 필요하다. 역사적으로, 이것은 많은 커뮤니케이션과 많은 휴먼 에러를 발생시키는 수동 프로세스들이였다.

전통적인 배포 파이프라인 단계는 다음과 같다.

Version Control

일반적으로 코드를 가지고 일을하는 소프트웨어 개발자들은 코드 변경사항을 소스 컨트롤에(e.g. github) 커밋 한다. 소스 컨트롤에 커밋하면 코드 컴파일화, 유니테스트, 코드 분석 그리고 인스톨러 생성을 트리거하는 배포 파이프라인의 첫번째 단계가 시작된다. 이런 모든 과정이 성공적으로 완료되면 실행결과물은 바이너리로 만들어지고 나중에 사용위해 아티팩트 저장소에 저장 된다.

Acceptance Tests

합격 테스팅은 비지니스에 의해서 미리 정의된 합격 기준에 부합하는 테스트를 위해 미리 컴파일/빌드된 코드에 대해 테스트 묶음을 실행하는 프로세스이다.

Independent Deployment

독립 배포는 컴파일되고 테스트된 아티팩트를 개발환경에 배포하는 프로세스다. 개발 환경은 이상적으로 프로덕트 환경의 판박이 복사본이여 하거나 최소한 아주 비슷해야 한다. 이것은 기능적으로 모든 추가적인 자동화되거나 수동 테스팅을 위한 인프라 준비와 같은 프로덕션에 대해 테스트되어질 수 있는 소프트웨어 이다.

Production Deployment

이 프로세스는 일반적으로 운영팀(Operations) 이나 데브옵스팀에 의해서 다루어진다. 이것은 독립 패포 프로세스와 매우 유사해야 하며 라이브 프로덕션 서버에 코드를 배포해야 한다. 전통적으로 이 프로세스는 예기치못한 이벤트 이슈에 쉽게 버전 롤백을 하거나 제로 다운타임 배포를 위해서 Blue/Green 배포 혹은 Canary 릴리즈를 포함 한다. 제로 다운 타임이 아닌 상황에서 배포 기능 릴리즈 윈도우는 일반적으로 비지니스와 협상을 했었다.

Continuous Integration and Continuous Delivery Pipelines

Continuous Integration (CI) 는 개발자들이 하루에 여러번 그들의 코드를 버전 제어 저장소에 체크하는 방법이다. 이러한 체크는 오류를 빠르고 쉽게 찾을 수 있게 해주며, 자동화된 빌드 파이프라인은 이러한 체크인으로부터 트리거 된다.

CI 의 장점은 다음과 같다.

  • 크기가 좀 더 작은 변경은 좀 더 큰 코드 베이스로 통합하기가 좀 더 쉽다.
  • 당신이 무슨 일을 하고 있는지를 다른 팀 멤버에게 보여주기가 좀 더 쉽다.
  • 좀 더 큰 작업 부분에 버그를 좀 더 적은 디버깅 작업으로 문제을 해결하기 아주 쉽도록 조기에 발견하게 한다.
  • 일관된 코드 컴파일/빌드 테스팅
  • 거의 없는 통합 이슈는 빠른 배포를 가능하게 한다.

Continuous Delivery (CD) 는 개발자와 운영엔지니어가 버그 수정, 기능 및 구성 변경 사항을 프로덕트에 안정적으로 신속하고 지속적으로 배포할 수 있도록 해주는 프로세스다. 지속적 배포는(Continuous Delivery) 필요시 자신있게 수행 할 수 있도록 반복적으로 수행되는 코드 배포 파이프라인의 이점을 제공한다.

CD의 이점은 다음과 같다.

  • 아주 낮은 리스크 릴리즈 – Blue/Green 배포와 카나리 릴리즈는 사용자가 신경쓰지 않아도 되는 제로 다운타임 배포를 보장하며 이전 릴리즈로 롤백하는데 상대적으로 어려움이 없다.
  • 빠른 버그 픽스 & 기능 배포 – 기능 또는 버그 수정을 완료하고 승인 및 통합 테스트를 통과한 경우 CI & CD 사용 – CD 파이프라인은 이것들을 재빨리 프로덕트에 배포한다.
  • 비용 절약 – 지속적인 배포를 통해 팀은 기능 및 버그 픽스를 작업 배치로 처리할 수 있으므로 사용자 피드백을 훨씬 빨리 받을 수 있다. This allows for changes to be made along the way thus reducing the overall time and cost of a project

Blue/Green Deployments

Blue/Green 배포 프로세스의 활용은 하나는 Blue, 다른 하나는 Green 으로 이름붙여진 프로덕트 환경 미러 복사본을 생성함으로써 리스크와 다운타임을 줄인다. 오직 하나의 환경만이 매시간 라이브 프로덕트 트래픽을 제공하도록 살아 있다. 배포 소프트웨어가 non-live 환경에 배포되는 중에는 – 이것은 라이브 프로덕트 트래픽이 배포되는 동안 영향을 받지 않는다는 것을 의미한다. 테스트는 현재 라이브 환경이 아닌 곳에서 실행되며, 모든 테스트가 사전에 정의된 기준을 충족하면 트래픽 라우팅이 라이브 환경이 되도록 라이브 환경이 아닌 환경으로 교체한다. 이 과정은 기존 라이브 환경이 현재 라이브 환경이 아닌것으로 되면서 다음번 배포에 반복된다.

Canary Deployments

Blue/Green 배포와는 달리, Canary 배포는 병렬로 운영되어지는 중복 환경에 의존하지 않는다. Canary 배포는 모든 사용자/서버들에 지속적으로 릴리즈를 롤 아웃(Roll out) 하기 전에 라이브 프로덕션 테스트를 위해 사용자/서버들의 백분율이나 특정 버전으로 릴리즈를 롤라웃 한다. Canary 릴리즈의 주요한 장점은 일찍 실패를 탐지할 수 있다는 것과 예외나 실퍠 이벤트 발생시에 영향을 받는 사용자/서버들의 수가 제한됨에 따라 일부 변경된 것만 롤백할 수 있다는 것이다.

요약을하면, CI 는 소프트웨어 개발팀이 그들의 코드를 체크인하고 품질을 확인하고 컴파일할 수 있도록 하는 자동화된 프로세스다. CD 는 개발과 운영 팀이 자동화된 방식으로 그들의 최종 기능에 새로운 기능과 버그 픽스를 안정적이고 효율적으로 배포할 수 있도록 해준다.

아래에 몇가지 CI/CD 파이프라인 빌드를 위해 사용할 수 있는 다양한 도구들이 있으며, 모두 무료로 시작할 수 있는 이점과함께 안정적이고 강력한 CI/CD 파이프라인을 빌드하는데 사용되어질 수 있다.

한국 SI를 망치는건 프리랜서들이다.

프리랜서라는 길을 걷다보면 언제나 슬픈 이야기들을 자주 접하곤 한다. 짧은 일정으로 인한 월화수목금금금, 악독한 원청업체 거기다 중간에 사람만 채우고 돈만 때가는 보도방 등으로 인해서 한국 SI 가 발전이 없는 날이 계속된다는 슬픈 이야기…

물론 과도한 업무, 중간에 마진 갈취등은 개선되어야 한다. 누구나 다 인간적인 삶을 권리는 존재하니까.

하지만 프리랜서 생활을 하다 느끼점은 정 반대라는 것이 놀랍다. 프리랜서들 만큼이나 노력과는 거리가 먼 사람들도 없다는 것이 나의 결론이다. 그들을 보고 있자면 정해진 루틴, 자신이 프로젝트를 하면서 익힌 Tip 같은 것 외에는 거의 공부를 하지 않는다.

최근에 Spring Boot 를 사용한 MSA 로의 이행이 심심치 않게 프로젝트로 나오기도 한다. 근데, 웃긴건 무슨 용기가 인지 객끼인지 모르겠지만 15년차나 되는 개발자랍시고 오신분중에 자신은 오랫동안 Spring 으로 작업을 했었으니 이것도 금방 익혀서 할 수 있을 거라는 확신에 차 있다.

하지만 Spring Boot 를 사용한다는 것, 그래서 아키텍쳐 자체가 MSA 를 지향한다는 큰 틀 따위는 안중에도 없고 코딩을 한것이 어떻게 작동되고 아귀를 어떻게 맞추는지만 관심일 뿐이다. 잘 동작하면 그걸로 끝이다.

이론적 배경지식이나 그런것보다는 잘 동작하도록하는 Tip 을 익히는것으로 끝나는 것이 대부분이다.

불법복제 사용은 놀랄일도 아니다.

새로운 프로젝트를 투입되서 들어가보면 요새는 Windows 10 을 기본으로 사용한다. 거기다 가끔 문서작업을 위해서 MS Word 를 요구하는 곳도 있다.

투입된 프리랜서들의 노트북을 살펴보면 크랙된 Windows 10 에 크랙된 MS Office 가 당당하게 깔려있다. 10명이 필요한 프로젝트에 거의 9명, 아니 다 불법복제를 당당히 깔고 온다. 왜 그런지 물어보면…

돈 아까워서요…..

적어도 IT 에 몸 담고 있다면 타인이 만든, 혹은 기업이 만들어내는 소프트웨어가 얼마나 많은 사람들의 피와 땀으로 만들어진 결과인지를 알 것이다. 그럼에도 불구하고 돈이 아까워서 불법 소프트웨어를 당당하게 사용하겠다는 그 객끼…

프리랜서들이 자주가는 커뮤니티에 가면 다음과 같은 질문이 자주 나온다.

내가 몇년차 프리인데, 이정도 단가는 괜찮은 건가요.

프리랜서들은 현찰로 많은 돈을 지급 받는다. 그렇게 많은 돈을 지급하는데에는 ‘전문성’ 을 담보로 하는 것이다. 아무리 4대보험, 복지를 운운해도 프리랜서들이 현실세계에서의 돈을 더 많이 모으는 곳이 IT 프리랜서 세계다.

IT 프리랜서 생활을 하다 정규직으로 못가는 이유… 돈 때문 아니겠나. 그렇게나 돈돈하는 사람들이 타인이 피땀으로 만든 소프트웨어 하나 구입하는 것에 ‘돈이 아깝다’라는 말을 당당히 할 수 있는 갞끼….

Windows 10 Pro .. 온라인 가격으로 32만원이면 산다. MS Office Business 버전은 1년 구독으로 월 9,100 이다. 그것도 5명이게까지 라이센스를 공유할 수 있다. OneDrive 도 1TB 씩이나 준다. Windows 10 은 한번 사면 반 연구적이고 MS Office 는 1년에 고작해봐야 12만원 돈이다.

단가 400이요,, 500이요.. 600도 적다는 생각은 많고 50만원 돈 들이는게 그렇게나 아까운지…

Xshell 이라는 프로그램이 있다. Linux 서버 터미널 접속용으로 매우 좋은 프로그램인데, 유료든 무료든 기능상의 차이는 없다. 단, 개인용이나 학교등에서 사용할 경우에는 무료이며 상용으로 사용할 경우에는 구매를 해야 한다는 라이센스 규정이 존재한다.

무료 사용 약관
㈜넷사랑컴퓨터는 강력한 SSH와 SFTP/FTP 클라이언트 프로그램을 지난 10년간 무료로 배포해온 것에 대해 자부심을 느낍니다. 저희 무료 라이선스는 단지 비용만을 요구하지 않는 것이 아니라, 광고, 스파이웨어 또는 사용자의 어떤 정보도 요구하지 않습니다. 저희는 어떤 환경이나 조건의 사용자들도 강력하고 기능이 풍부한 SSH와 SFTP/FTP 프로그램을 배우거나 가르치는데, 심지어 단지 취미 목적에 상관 없이 접할 수 있어야 한다고 믿습니다.


㈜넷사랑컴퓨터의 Xshell과Xftp의 무료 라이선스는 비상업적 사용으로 제한됩니다. 업무 목적으로 저희 무료 라이선스를 사용하는 것은 저희 무료 라이선스 사용 동의서에 엄밀하게 반하는 것입니다. Xshell 또는 Xftp를 상업적 목적에 사용하고자 한다면 라이선스를 구매하기를 권합니다. 이는 저희가 저희 제품을 향상시키는 것을 돕는 일입니다.


저희 무료 라이선스 제품을 다운로드하는 것은 때때로 발송되는 판매 촉진을 위한 할인 정보나 프로그램 패치 안내와 같은 특별한 이벤트와 관련한 이메일 수신에 동의한 것을 의미합니다. 더이상 이런 이메일 수신을 원하지 않을 경우 해당 이메일 하단의 안내 링크를 클릭하여 등록을 해지할 수 있습니다. 저희는 절대로 귀하의 정보를 제 3자에게 제공하지 않습니다.

https://www.netsarang.com/ko/free-for-home-school/

아무도 안 지킨다. 아무도…… 언제부터 기능제한도 없고 광고도 없는 것이 무료 소프트웨어 라이센스가 됐나….

프리랜서는 엄밀히 말해 개인 사업자들이다. 그래서 노동자가 아니라 용역 수급자에 해당된다. 당연히 개인도 아니고 학교도 아니다. 당연히 돈주고 사서 써야하는 입장이지만 이걸 돈주고 사서 쓰는 인간 지금까지 단 한 사람도 본적이 없다. 돈두고 사서 쓰고 싶지 않다면 그야말로 무료 소프트웨어를 써라. 차라리 그것이 더 낫다.

돈은 프리로 받고 일은 정규직으로…

이율배반적인 행태는 또 있다. 프리랜서로 계약을 해놓고 일은 정규직처럼 하길 원한다는 것이다. 그래놓고 정규직처럼 일을 시킨다고 도급법 위반 운운한다.

진짜 프리랜서로 일해본적 있는가? 사람 할 짓 못된다. 마치 좋은 기업에서 가끔 시행하는 재택근무와 비슷하다. 말이 좋아 자유지 창살 없는 감옥이 따로 없었다. 재택이랍시고 일하고 싶을때 일하고 맘대로 침대에 누워 노트북으로 일을 할 수 있는게 아니다.

프리랜서도 마찬가지다. 근퇴도 없고 업무를 협의해서 해야하는 것이 마냥 좋아보이나.. 그렇지 않다. 개인적으로 도급법 위반 운운하는 사업장을 딱 한번만이라도 FM 프리랜서로 운영을 해봤으면 한다. 고도의 전문성을 요구하는 프리랜서, 그래서 진짜 법대로 한번 해보는 거다.

제발 그렇게나 불만이 높은 사업장, 불만만 토로하지 말고 고발을 하시라… 그렇게나 프리랜서로서 억울하면 제발 스스로 자신이 일하는 그곳을, 돈이 나오는 그곳을 고발을 하시라..

절대로 그렇게 하지 않는다. 그러면서 일은 정규직들처럼 9-6 시 사이에만 하는것으로 끝을 낼려고 한다. 개인 사업자에게 정해진 업무시간이 존재나 하나? 근퇴가 없는 것이 프리랜서들이라메…

마치 사무직들을 보는 것들만 같았다. 마치 공무원들이 컴퓨터에 저장된 와꾸(?) 를 꺼내서 말바꾸고 대충 근거를 찾아서 집어넣고 공문을 만드는 그런식의 프로그래밍… 연차가 쌓이는데 경험은 누가누가 Tip 을 더 많이 알고 있나…

단가를 왜 연차로 먹이는지 이해할 수 없다. 10년 차면 얼마… 호봉제가 따로 있지 않다.

인생은 항상 불공평 하지만은 않다.

도급용역계약서는 민법에서 정한 양자간 신뢰를 바탕으로 하는 상호 약속이다. 대부분 계약서를 문제로 불만을 토로하지만 계약서가 맘에 안들면 안하면 그만 이다.

프리랜서는 고도의 전문성을 필요로 한다고 했는데, 기술적인 부분만 필요한게 아니다. 협상력이 반드시 있어야 한다. 계약서를 읽을 줄 알아야하고 그것의 문제를 바로 끄집어내 협상을 해야 한다. 그럴 능력이 없으면 아예 프리랜서를 하지 않는게 낫다. 공급자는 당연히 싼 값에 사람을 부려먹을려고 할게 뻔한데, 그런 사람들을 상대로 협상을 하기란 쉽지가 않다.

자신이 처한 현실이 부당함을 목소리 높여 주장하기 전에 과연 나조차 그런 부당함을 눈감고 돈만 밝힌것은 아닌지 되돌아 봐야 한다.

왜 정규직 회사들이 프리랜서들의 경력을 인정해주지 않는지를 크게 생각을 해봐야 한다. IT 라는것이 정규직 프리랜서를 가르는 기준이 존재하나. 다 같은 기술이고 다 같은 사람들인데도 왜 정규직 채용시에 프리랜서 경력을 인정하려고 하지 않는지를 크게 생각을 해봐야 한다.

IT 라는 지식산업은 만만한 곳도 아니다. 숙련된 사람이 절실히 필요한데도 개인방송에서 할일 없으면 개발자나 하라고 앉았으니… IT 전문기업들이 왜 인재가 없다고 하는지.. 그것이 그냥 알른 소리가 아님을 알아야 한다.

DNF 사용하기

CentOS 8 로 넘어오면서 기본 패키지 매니지먼트로 dnf 가 되었다. 여전히 yum 을 지원하지만 앞으로는 dnf 로 쭉 간다고 하니 이참에 배워보자고 생각하지만….

겁나 빡치는게, 이제 그만 바꿨으면 한다. 뭔 yum 정도로도 충분히 잘 쓰고 있고 괜찮다고 싶다. 무슨 겁나 가볍네, 더 빠르네 어케 좋네… 응 yum 도 그렇게 느리고 그렇게 무겁지도 않아! 도대체 뭘 할때마다 갈아 엎고 이걸 새로 배우라고 하니.. 뭐 어쩌것나.. 그렇게 하겠다는데, 닥치고 배워야지!

dnf

햐.. 쓰기도 귀찮다… “DNF is the next upcoming major version of YUM, a package manager for RPM-based Linux distributions” 이렇게 맨 페이지에 설명이 나온다.

사용법

사용법은 아주 간단하다. yum 의 기본 사용법은 대동소이하다고 하겠다.

이정도만 알아도 패키지를 다루는데는 문제가 없을 것이다.

Ubuntu, systemd-networkd 전환하기

Ubuntu 16.04 로 넘어오면서 SysV 의 Init 이 Systemd 로 변경되었다. 이런 변화에는 Network 관리에도 적용되고 있는데, 이에 대해서 알아보자.

기존의 Network 관련된, 정확하게는 Network Interface 와 관련된 일은 NetworkManager 가 담당했다. Network Interface 가 무엇인지, 아이피는 DHCP 혹은 Static 인지 등이 그것이다.

하지만 Ubuntu 16.04 로 넘어오면서 시스템에 관련된 일체가 systemd 로 통합되면서 네트워크 관련 작업도 systemd 로 통합되어지게 되는데, 이것이 systemd-networkd 이 이다.

하지만 Ubuntu 18.04 로 넘어온 시점에서도 NetworkManger 는 이전과 호환을 위해서 살려뒀고 살려둔김에 지금도 기본적인 네트워크 설정 프로그램으로 활약(?) 하고 있다.

Network Manager

Network Manager 의 동작은 다음의 명령어로 이루어진다.

관련 설정은 /etc/NetworkManger/NetworkManger.conf 파일이다. 위 프로그램을 실행하게 되면 기본적으로 이 파일을 읽게 되어 있다.

그리고 netplan 설정에서도 NetworkManager 를 기본으로 지정하도록 되어 있다.

Network Manager 비활성화

비활성화는 다음과 같이 하면 된다.

이렇게 하면 네트워크가 비활성화 됨으로 절대로 원격지 서버에서 하면 안된다.

systemd-networkd 활성화

netplan

systemd-networkd 를 활성화하면 이제 네트워크 작업은 netplan 명령어를 통해서 이루어진다. 이 netplan 명령어는 기본적으로 ‘/etc/netplan’ 디렉토리에 파일을 읽어서 네트워크 설정을 적용해 준다.

‘/etc/netplan’ 디렉토리에 설정파일은 기본적으로 yaml 파일형식을 가진다. 예를 들면 다음과 같다.

파일을 수정한 후에는 다음과 같이 명령어만 주면 적용이 된다.

‘–debug’ 는 제외해도 된다.

기업이 프리랜서를 정규직으로 뽑지 않는 이유

나이가 먹어가면서 이런 저런 사회현상에 대한 답을 얻어가는 것 같다. 과거 어렸을적(?) 에는 그것이 왜 그렇게 되는지에 대한 의문만 가득했지만 시간이 약이라고 했던가…

한국 사회에서 나이가 가지는 특별함으로 인해서 나도 모르게 이제는 아랫사람이 생기고 과거에 윗사람에게 존댓말을 했던 내가 이제는 존댓말을 받을 위치에서 사회를 바라보게 됨에 따라서 과거에 못보던 것이 이제는 보이는 신기한 현상을 자주 겪는다.

개인적인 경력을 이야기를 하면 정규직 생활을 약 7년 정도하고 프리랜서로 전향한지 이제 약 5년쯤 됐다. 중간에 약 1년 쯤 놀았으니까 프리랜서를 개월수로 환산하면 만 4년 조금 될까…

지금도 그렇지만 과거에 이런 의문을 가진적이 있다.

다 똑같은 IT 기술을 가지고 일을 하는 사람들인데, 어째서 좀 나간다하는 기업에서는 프리랜서들을 정규직으로 고용하려고 하지 않는가?

과거에 가졌던 의문인데, 요새 그것이 정말로 맞는 말이라는 것을 절감한다.

새로운 프로젝트에 투입되고 새로운 인력을 뽑아 프로젝트를 지휘해야하는 입장에 있다. 문제는 SI 프리랜서에게 지급되는 월별 단가라는 것이 프리랜서 경력만 가지고 결정된다.

아무리 능력이 좋다고 한들 5년차라면 돈을 많이 못 받는다. 아무리 능력이 없다고해도 경력이 15년차면 특급대우를 해준다. 이력서에 많은 프로젝트를 뛰었다는 것이 그 사람의 IT 능력을 증명한다는 것이 웃기는 일인과 동시에 의문인데 이러한 의문 때문에 과거에 저런 질문이 절로 떠올라고 과연 맞는 말이라는 것을 절감한다는 것이다.

나랑 같이 투입된 15년차 프리랜서가 있다. 나이도 많아서 부장이라고 달았는데, 그야말로 기계적인 일만 한 경우였다. 그리고 그렇게 기계적인 일만으로 단가를 높게 받다보니 그것을 벗어나는 일은 절대로 하려고 하지 않는다.

더 웃긴건 한국 사회도 변화하고 있고 IT 세계도 그 변화에 흐름은 빗겨가지 못하고 있는데도 과거에 했던 버릇을 버리지 못하고 있다는데 있다.

한국 사회에서 저작권에 대한 생각이 많이 바뀌어 있고 그래서 요새 젊다하는 프리랜서들은 나름대로 소프트웨어 저작권에 대한 인식이 잘 갖춰져 있다. OS, MS Office 등은 업무에 필요한 필수 소프트웨어도 과거에 비해서 나름 저렴해진 것도 한 몫이다.

하지만 나랑 같이 투입된 15년차 프리랜서… MS Office 는 2007년 버전이고 그것도 크랙 버전이다. 사업장 마다 다르지만 소프트웨어 라이센스에 민감곳이 점점 많아지고 있는 시점이고 내가 있는 사업장도 불법 소프트웨어에 대해서 그렇게 좋게 보지 않는다. 한번 걸리면 사업장이라고 책임을 면할 수 있는 상황도 아니기 때문이지..

그래서 크랙 버전은 사용하면 안되고 문제가 될 거 같으니 돈 주고 사라고 권했다. MS Office 365 의 경우에 비지니스 버전 1년 구독으로 12만원이면 사용할 수 있다. 프리랜서 15년차면 단가가 적어도 700 은 넘을테니 1년 12만원 그냥 껍 아니겠나..

하지만 이 양반.. 그 돈이 아깝다는 거다. 계약을 체결한 회사가 제공해주지 않느냐는 질문부터 해서 어떻게든 싸게 구매할려는지 이커스 마켓에서 출처도 불문명한 3만원짜리 라이센스 구매가 어떠냐고 내게 물어보기까지…

더 웃긴건, 이 프로젝트에 투입된 그 인력은 인프라를 담당하는 사람이다. OS, Application 서버등을 운영, 모니터링, 장애대응이 주 임무다. IT 그것도 인프라 운영에 발을 들여논 순간부터 24시간 장애대응은 염두해 둬야하는 직업이다. 하지만 이 양반 집에 컴퓨터가 없다.

장애가 발생하면 집에서 회사까지 출근해서 할 사람으로 보이지도 않는데도 “어? 집에 컴터 없어요” 를 아주 대놓고 당당하게 하는 사람…

사업장에서는 그래도 야밤에 출근하는 불상사를 없애기 위해서 원격 접속 프로그램을 지원해 주고 있다. 실시간 대응이 필요한 서비스의 경우 이렇게 해주는 곳이 많은데 “어? 집에 컴터 없는데요~” 를 당당하게 말할 수 있는 배짱, 아니 객끼를 들어내는 사람..

나 같아도 정규직으로 안 뽑는다.

이 글을 읽는 사람이라면 프리랜서 전체를 매도하는게 아니냐고 하겠지만 안타갑게도 저렇지 않는 프리랜서 본적이 없다. 계약서를 따지고 단가를 계산하고 사업장에서는 정규직과 동일한 복지를 요구하면서도 진정으로 개인사업자에 준하는 대우와 그에 맞는 결과를 요구하면 그것이 매우 부당하다고 주장하는 이들… 출퇴근은 칼같이 지켜내야만 한다고 주장하는 사람… (원래 프리랜서는 출퇴근 개념이 없다.)

한국 사회에서 공무원들을 영혼없는 사람처럼 대하는데, 한국 프리랜서들도 별반다르지가 않더라는 거다. case by case 대로 Tip 을 많이 알고 있는 것이 한국 IT 인력들의 능력 수준일 뿐이다. 그것을 조금만 벗어나면 뭘 어쩌지 못하는 무능을 금방 들어내고야 많은 선배님들… 제발 빨리 은퇴하시고 치킨집 차리시길 권한다.

쿠버네티스(Kubernetes) 개념

쿠버네티스(Kubernetes) 처음 접하면 개념 잡기를 해야 한다. 쿠버네티스를 잘 사용하기 위한 사용법을 익히는것도 중요하지만 개념을 이해하고 나면 외워서 문제해결을 하는 것이 아닌 응용력이 생겨 예기치 않은 장애를 겪을때에 힘을 발휘한다.

개인적으로 쿠버네티스의 개념을 이해하는데 약간의 혼란이 있었다. 개념을 설명하는 용어와 실제 작업을 할때에 사용하는 단어, 명령어들이 다 틀리게 사용되고 있는데서 오는 것이였다.

Master/Worker

다들 알다시피 쿠버네티스는 Master Node와 Work Node 로 구성된다. 대부분 Work Node 가 Master Node 보다 훨씬 많고 대부분의 서비스들이 여기에 배포되어진다.

Node 라는 단어를 빼버리고 단순히 Master/Worker 라고도 하지만 그냥 Master/Node 라고 하기도 하는 모양이다. 하지만 정확하게는 Master Node, Worker Node 라고 불린다.

또, Master Node 를 Controller 라고도 한다. Master 의 역활이 Worker Node 를 모니터링, 감시를 하고 각종 명령어을 Master 가 받아서 처리한다. 이 Master Node 는 거대한 Controller 서버 역할이라고 보면 된다.

kubectl – ResTful API

Master 가 거대한 Controller 서버라면 클라이언트를 이용해서 이 서버에 명령을 보내면 될 것이다. 이 클라이언트가 바로 kubectl 이라는 커맨드가 수행한다. 서버-클라이언트 구조상 서버는 1대지만 클라이언트는 여러대 일 수 있다. 실제로 kubectl 은 단일한 명령어로서 도커(Docker), 컨테이너(Container) 등도 필요없이 동작한다. 그래서 클라이언트는 어느 머신이든지 다 설치/사용이 가능하다.

kubectl 은 클라이언트, Master Node 는 Controller 서버다. 이 둘이 명령어를 주고 받는 방법이 바로 RESTFul API 통신 방법이다.

ResTful API 는 HTTP 를 이요해 URI 에 자원(Resources) 을 명시하고 메소드(Method) 를 이용해 CRUD 연산을 수행한다.

쿠버네티스(Kubernetes) 에서 중요한 것이 바로 자원이다. ResTful API 를 이용해 어떤 작업을 명령할때에 반드시 대상이 필요한데, 이것이 바로 자원이다.

Object, Resource, Kind

쿠버네티스(Kubernetes) 에서 개념을 설명할때에 오브젝트(Object) 라는 말을 쓴다. 오브젝트라고하면 쿠버네티스를 구성요소쯤으로 이해하면 된다. 예를들어 Pods, Service, Volume, Namespace 등은 쿠버네티스의 기본 오브젝트라고 불린다.

문제는 이러한 오브젝트들이 때로는 자원(Resource), 때로는 종류(Kind) 로 불린다.

자원 ResTful API 관점에서 실체적인 존재로서 호출하는 오브젝트들이다. 실제로 kubectl 커맨드를 사용할때에는 ‘오브젝트를 명시한다’ 하지 않고 ‘자원을 명시한다’라고 한다. ResTful API 개념을 차용했기 때문에 ‘자원을 명시한다’라고 해야 맞다.

위 결과를 보면 자원(Resource) 목록에서 오브젝트들도 볼 수 있다. 물론 오브젝트는 개념화된 추상적 그야말로 개념이고 자원을 실체적인 대상으로서 차이를 보이지만 이들에 명명된 말이 모두 같다. 맨 오른쪽에 KIND 도 보인다.

종류(Kind) 는 보통 Pods 를 생성하거나 업데이트를 하기위한 매니페스트(Manifest) 파일 작성시에 사용된다. 종류(Kind)는 쿠버네티스 자원 종류를 말한다. 매니페스트 파일은 JSON, YAML 포맷형태인데 예를들면 다음과 같다.

kind: Pod 라는 것이 보인다. 매니페스트 파일에서 자원이라고 하면 그야말로 컨테이너가 사용할 컴퓨터 하드웨어 자원을 말한다. 그래서 Resource:Pod 라고 한다면 문제가 되니까 Kind 라는 것으로 바꾼거 짐작이 된다.

이 kind 가 궁금하다면 ‘kubectl api-resources’ 명령어를 호출하면 자원에 붙여진 kind 를 볼 수 있다.

어느 방향으로 이해하느냐가 관건

쿠버네티스가 다루는 자원의 방향으로 접근해 이해하는 것도 괜찮다. 아니면 추상화 개념으로서 개념을 이해하고 가는것도 괜찮다.

다만, 완전히 추상적인 개념과 실제적인 대상을 구분하고 연결짓는 것이 머리속에 체계적으로 저장하는 방법이 될 수 있다.

kubectl 원격 접속 설정

kubectl 은 Kubernetes Client 이다. 이 명령어는 HTTP 통신을 기반으로 Kubernetes Controller 와 RestFul API 통신을 요청하고 결과를 받아 사용자에게 출력하게 하는 역할을 한다.

HTTP RESTFUL API 통신을 한다는 말을 듣는 순간 직감했겠지만 인터넷만 된다면 kubectl 은 어느 컴퓨터에서든 실행이 가능하다. 처음 Kubernetes 설치문서들을 보면 대부분 Master Node 에서 실행되도록 설정을 하는데, 여기서는 다른 컴퓨터에서 kubectl 만 설치해서 Kubernetes Controller 와 연결하는 방법에 대해서 살펴보도록 할 것이다.

설치환경

설치 환경은 Mint Linux 19.2 – XFCE4 환경에서 진행했다. kubectl 를 실행하는 환경는 다양하겠지만 제일 편한 것으로는 Unix 환경일 것이다. Mac OS X, Linux 가 가장 적합한데, 필자는 Mint Linux 19.2 – XFCE4 데스크탑을 사용하고 있음으로해서 이 환경에서 진행하게 됐다.

Mint Linux 19.2 는 Ubuntu 기반이기 때문에 Ubuntu 에서 설치, 설정 모두 동일하다고 생각하면 된다.

kubectl 설치하기

Mint Linux 19/2 에서 설치하는 방법은 Ubuntu 에서 설치하기와 동일하다. 단, 여기서는 kubectl 패키지만 설치하면 된다. root 계정으로 다음과 같이 한다.

설치는 별다른 이상이 없는한 문제 없이 진행된다.

kubectl 설정하기

kubectl 명령은 일반계정으로 사용하길 권고 하기 있다. kubectl 은 일반 계정에서 .kube/config 파일을 참조한다. 파일의 내용을 볼수도 있지만 다음과 같이 명령어로도 같단히 확인할 수 있다.

config 설정을 kubectl config 명령어를 통해서 가능하지만 복잡해 보인다. 손쉬운 방법을 찾게 되는데, 그 방법은 바로 Master Node 를 초기화 할때에 나오는 것을 참고하면 된다.

Master Node 초기화 때 나오는 출력에 설정관련 내용이 나온다. Master Node 에서 Mint Linux 19.2 에 일반계정으로 config 를 복사해보자.

이렇게 한 후에 다음과 같이 샘플 명령어를 쳤을때에 나오면 정상이다.