일하는 방식 변화 핵심만 빠르게 이해하기: 애자일, 마이크로서비스, 데브옵스, 클라우드

새로운 변화의 물결

 

내용 순서

마이크로서비스가 최근에 왜 주목 받고 있는지 거시적 관점인 일하는 방식 변화의 측면에서 이해하는 것이 목표입니다.
이를 위해 일하는 방식 변화가 왜 필요한지 역사점 관점에서 먼저 생각해 보고 기업이나 조직들이 혁신적인 제품이나 서비스를 제공하기 위해 어떻게 변화하고 있는지 최근의 변화 트렌드를 살펴 봅니다.
그리고 일하는 방식의 변화를 이끌고 있는 애자일, 마이크로서비스, 데브옵스, 클라우드의 핵심을 설명 하겠습니다.

1. 일하는 방식의 변화가 왜 필요한가 ?

현대 사회 변화의 특징을 두가지로 말한다면 빠른 속도와 불확실성이라고 할 수 있을 것입니다.

먼저 빠른 변화의 속도에 대해 얘기해 보겠습니다.
인류문명이 약 기원전 1만년전에 농사를 짓기 시작한 이후 현재까지 많은 변화가 있었고 그 변화의 속도는 점점 더 빨라지고 있습니다.
그 발전 속도에 가장 큰 전환점은 18세기 후반의 산업혁명과 20세기 중반의 컴퓨터 혁명이라고 할 수 있습니다.
특히 1943년 최초의 컴퓨터 애니악이 나온 이후 인류 문명의 발전 속도는 그 전과는 비교할 수 없을 정도로 빨라졌습니다.
지금까지 인류 문명을 5분으로 정리했을 때 불과 13초도 안되는 기간 동안에 말이죠.
가속도가 붙은 변화의 속도는 앞으로 더 빨라질 것이고 그 변화에 적응하지 못하는 조직이나 기업은 결국 도태될 것입니다.
<그림>

출처: 점점 빨라지는 인류의 발전 속도를 5분으로 체험해보기
</>



두번째 변화의 불확실성에 대해 얘기해 보겠습니다.
18세기 후반 뉴턴이 운동의 원리와 만유인력의 법칙을 정립한 이후 20세기 초반 상대성이론과 양자역학이 나오기 전까지 세상의 모든 것은 초기 정보와 어떤 방정식만 있다면 예측 가능하다고 믿었습니다.
그러나 하이젠베르크가 불확정성의 원리를 발표하고 양자역학이 그것을 증명하기 시작하자 이 세상은 예측 가능한 결정론적 세계가 아니라 확률로만 가능성을 예측할 수 있는 세계라는 것을 알게 되었습니다.

<그림>

출처: 양자역학 세번째 이야기-불확실성
</>

물질의 위치와 운동량(물질의 방향과 속도)은 측정이라는 행위가 영향을 미쳐 동시에 정확하게 관측할 수 없고 확률로만 그 값을 알 수 있다는 하이젠베르크의 불확정성의 원리는 단순히 과학적 이론이 아니라 인류의 사상과 세계관에 지대한 영향을 미쳤습니다.
인류는 미래를 예측할 수 있다는 오만을 버리고 가장 가능성이 높은 미래를 예측 하려는 노력을 하게 된 거죠.
따라서 이러한 불확실한 세상에서 가장 성공 확률이 높은 방법을 찾는 기업과 조직만이 살아 남고 계속 성장할 수 있다는 것은 당연하겠지요.

결론적으로 급변하고 불확실한 세상에서 기업과 조직이 생존하고 지속성장 하려면 끊임 없이 변화에 적응하고 성공 확률을 높일 수 있는 방법을 찾을 수 밖에 없습니다.
그러기 위해서는 기업과 조직의 일하는 방식이 변화해야 합니다.
마이크로서비스는 이 일하는 방식의 변화와 밀접한 관련이 있습니다.

2. 무엇이 왜 변하고 있는가 ?

기업의 궁극적 목적은 이윤 추구이고 이윤은 고객에게 제공하는 제품이나 서비스로부터 나옵니다.
기업의 일하는 방식 변화를 얘기하기 전에 기업들이 혁신적인 제품이나 서비스를 제공하기 위해 어떻게 변화하고 있는지 최근의 변화 트렌드부터 말씀드리겠습니다.

위와같이 4가지 측면으로 요약할 수 있겠습니다.

먼저 조직구조는 기능별 대규모 사일로Silo조직에서 서비스와 매핑 되어 있는 다기능 소규모 스쿼드Squad조직으로 변화하고 있습니다.
아직 현재 많은 기업은 마케팅, 구매, R&D, 영업, IT 등 기능별로 대규모 인원을 가진 BU(Business Unit)가 명확히 나뉘어져 있습니다. 그 때문에 BU간에 소통과 협업에 한계가 많습니다. 비슷한 제품/서비스를 중복해서 투자하는 경우도 흔하고요.
이제는 각 제품/서비스에 필요한 제품 책임자, 서비스 기획자, 개발자, 운영자, 디자이너 등이 8~10명 정도의 스쿼드팀을 이루어 기획, 개발, 운영을 하면서 제품/서비스를 계속 발전시켜 나가는 조직으로 변화하고 있습니다.
이러한 조직구조의 변화는 아직 본격적으로 시작되지 않았지만 빅테크와 금융권을 중심으로 활발하게 변화의 노력을 하고 있습니다.
예를 들어 KB국민은행은 사업조직(Biz)과 기술조직(Tech)이 함께 일하는 25개 플랫폼조직을 8개 사업그룹 안에 신설하여 운영중에 있습니다. 이 외에도 대표적인 국내 기업으로는 배달앱 1위인 ‘배달의 민족’, 이커머스 1위인 ‘신세계그룹’등이 있습니다.
구글에서 ‘애자일 조직 사례’로 검색하면 많은 기업들이 이러한 조직구조로 변화하고 있다는 것을 알 수 있을 것입니다.

두번째, 서버 단위가 점점 더 작아지고 있습니다.
2000년 전까지만 해도 서비스를 운영하기 위한 서버는 물리적인 머신 이었습니다. 2000년대 초반 가상화 기술이 본격적으로 도입되었고 물리적인 머신 1대를 여러 대의 가상머신(VM: Virtual Machine)으로 나누어 CPU와 메모리 등의 자원을 효율적으로 사용할 수 있게 되었습니다.
2013년 도커Docker라는 컨테이너 기술이 나오면서 물리적인 머신 또는 가상머신을 컨테이너로 나누어 서비스하기 시작했습니다. 컨테이너의 목적은 자원의 효율적인 사용 보다는 서비스 상호간에 영향도를 없애는 것이었습니다. 서비스에 필요한 OS, WAS(Web Application Server), 라이브러리, 어플리케이션 소스를 하나의 컨테이너 단위로 합침으로써 각 서비스가 독립적으로 배포, 버전업, 인스턴스 수 증감이 가능하게 한 것입니다.

세번째, 어플리케이션 단위도 점점 더 작아지고 있습니다.
우리가 보통 구매 시스템, 영업 시스템, 모바일뱅킹 시스템과 같이 ‘시스템’이라고 부르는 것은 여러가지 서비스가 하나로 뭉쳐진 모놀리식Monolithic 서비스입니다.
모놀리식 서비스의 문제점은 내부의 서비스가 서로 영향을 미친다는 것입니다. 그래서 한 서비스를 새로운 버전으로 배포했는데 다른 서비스가 의도치 않은 영향을 받아 장애가 발생할 수가 있습니다. 그래서 사소한 기능 변경이라도 운영서버에 배포하려고 하면 전체 기능을 철저하게 테스트하고 관련자들이 긴장하면서 모두 대기해야 했습니다.
마이크로서비스는 이러한 서비스간의 영향도를 최소화하고자 하는 목적으로 나왔습니다.
큰 서비스를 작게 분할하고 마이크로서비스별로 자체적인 데이터베이스를 갖게 하며 서로 API로 통신하게 함으로써 영향도를 최소화하겠다는 것입니다.
이렇게 영향도를 최소화함으로써 각 마이크로서비스는 독립적으로 배포, 버전업, 인스턴스 증감이 될 수 있고 비즈니스의 요구에 보다 더 민첩하게 대응할 수 있게 되었습니다.
즉, 마이크로서비스의 목적은 서비스간 영향도 최소화라는 측면에서 컨테이너와 동일합니다.
그래서 마이크로서비스를 컨테이너화 해서 서비스하는 것이 자연스런 방향이 되었습니다.

마지막으로, 클라우드로의 변화입니다.
클라우드가 없던 시절에는 모든 IT자원을 각 기업이 소유해야 했습니다. 하드웨어, 소프트웨어, 운영인력등을 자체적으로 갖고 있어야 했죠.
클라우드는 이러한 자원들을 임대하여 사용할 수 있는 방법을 제공했습니다.
클라우드의 목적은 단순히 자원의 임대를 통한 비용 절감이 아닙니다. 사실 초기 비용이 줄지 전체 비용이 그렇게 획기적으로 줄지도 않습니다.
그 진정한 목적은 혁신적인 서비스를 만들고 발전시켜나가는 혁신 플랫폼이라는 것입니다.
예를 들어 비즈니스조직에서 좋은 아이디어를 내었고 그걸 IT서비스로 경쟁사보다 먼저 만들어 시장에 출시해야 하는데 하드웨어와 소프트웨어 구매하고 네트워크 작업하는데 한달 이상 걸린다면 그 아이디어는 무용지물이 될 수 있습니다.
클라우드는 이러한 비즈니스의 요구에 민첩하게 대응하여 혁신적인 서비스를 신속하게 만들고 발전시킬 수 있는 강력한 혁신 플랫폼이라는데 가장 큰 가치가 있습니다.

지금까지 혁신적인 제품/서비스를 만들기 위한 최근의 트렌드인 스쿼드, 컨테이너, 마이크로서비스, 클라우드에 대해 간략하게 살펴봤습니다.
이러한 변화의 1차적인 목적은 혁신적인 제품/서비스를 남들보다 더 빠르고 안정적으로 제공하겠다는 것입니다.
그러나 우리는 더 근본적인 이유를 알아야 합니다.
그 근본적인 이유는 급변하고 불확실한 세상에서 기업과 조직이 생존하고 지속성장 하기 위해서입니다.
기업의 생존과 지속성장을 위해서는 끊임 없이 변화에 적응하고 성공 확률을 높일 수 있는 방법을 찾아야 하고 그러한 노력이 조직구조, 서버 단위, 어플리케이션 단위, 서비스플랫폼의 변화를 가져온 것입니다.

3. 일하는 방식 변화 프레임워크 개요

급변하고 불확실한 세상에서 기업이 끊임 없이 변화에 적응하고 성공 확률을 높일 수 있는 방법을 찾기 위해서는 근본적으로 일하는 방식을 변화시켜야 합니다.
저는 일하는 방식 변화 프레임워크를 구성하는 4가지 축을 애자일, 마이크로서비스, 데브옵스, 클라우드라고 정의 합니다.
기업이 생존하고 지속성장 하려면 ‘애자일’이라는 사상과 철학을 구성원 모두가 이해하고 실천하여야 합니다.
‘마이크로서비스’와 ‘데브옵스’는 기업의 생존과 지속성장을 실현하는 강력한 수단과 도구이며, 그 기반이 되는 혁신 플랫폼이 ‘클라우드’입니다.
그래서 ‘왜 마이크로서비스가 출현했는가’의 근본적인 답은 ‘기업과 조직의 생존과 지속성장’을 위한 일하는 방식 변화를 위해 가장 성공 확률이 높은 수단의 하나이기 때문이라고 할 수 있습니다.

일하는 방식 변화 프레임워크를 구성하는 애자일, 마이크로서비스, 데브옵스, 클라우드를 WHY, HOW, WHAT의 관점에서 정리하면 아래와 같습니다.
여기서 WHY는 비전과 신념이고 HOW는 그 방법이며 WHAT은 그 결과입니다.

아직 위 그림을 이해하기 어려울 수 있습니다.
하지만 이후의 내용을 읽다 보면 자연스럽게 이해되실 테니 너무 걱정 마시고 계속 읽어 주십시오.

그럼 일하는 방식 변화 프레임워크를 구성하는 4개의 주제에 대해 간략히 이해해 보도록 하겠습니다.
저는 이 주제들에 대해 설명할 때 은유적인 제목을 즐겨 사용합니다.

4. 애자일 - 어떻게 살 것인가 ?

애자일은 비단 기업이나 조직의 일하는 방식에 대한 사상일 뿐만 아니라 우리가 세상을 살아가는 삶의 자세라고도 할 수 있습니다.
저는 애자일이 불확실하고 급변하는 세상에서 우리가 살아남고 계속 성장하려면 어떻게 인생을 살아가야 하는지를 알려주는 철학이라고 생각합니다.
제가 애자일 이라는 주제의 제목을 ‘어떻게 살 것인가?’라고 한 이유도 그 때문입니다.

4.1 애자일 핵심사상 “M”

 

애자일에 대해 많은 정의와 표현들이 있지만 저는 그 핵심 사상을 ‘M’이라는 알파벳으로 얘기하고 싶습니다.  ‘M’은 밸류 오리엔티드Value-Oriented, 인터랙티브Interactive, 이터레이티브Iterative의 각 첫 자를 합성한 알파벳입니다.  밸류 오리엔티드Value-Oriented는 우리가 만드는 제품/서비스의 가치가 제일 중요하고 그 가치를 제공하기 위한 방법이나 결과물은 상황변화에 따라 유연하게 바꿔 나가야 한다는 사상입니다.  여기서 가치라는 것은 우리가 왜 이 제품이나 서비스를 만드는지에 대한 우리의 믿음입니다. 조금 더 거창하게 말하면 우리의 비전입니다.   예를 들어 애플은 “우리가 하는 모든 일은 현상유지에 도전하고 다르게 생각하는 것”이라는 믿음을 갖고 제품과 서비스를 만들고 있습니다.  다시 말해 우리가 왜 이 일을 하는지 그 비전을 고수하면서 방법과 결과물은 과감히 바꾸거나 버릴 수 있어야 한다는 것입니다.  이 밸류 오리엔티드Value-Oriented 사상이 애자일의 가장 중요한 사상이라고 할 수 있습니다.  인터랙티브Interactive는 제품과 서비스를 중심으로 관련된 사람들이 지속적인 쌍방향 소통을 해야 한다는 사상입니다.  이를 위해 서비스별로 비즈니스조직과 IT조직을 합치는 데브옵스라는 방법이 나온 것입니다.  쌍방향 소통이 왜 필요할까요 ? 한마디로 “공통의 공감과 이해”를 위해서입니다.  제품과 서비스를 처음부터 끝까지 같이 만들면서 고객, 서비스, 일하는 방식 등에 대해 공감하고 공통의 이해를 해야 더 나은 제품과 서비스를 만들 수 있기 때문입니다.

이터래이티브Iterative는 한번에 큰 투자를 하여 만드는 것이 아니라 최소한의 기능으로 시작하여 끊임없는 실험과 학습을 반복하면서 점차 그 완성도를 높여 나가자는 사상 입니다.
린스타트업Lean Startup, 스크럼Scrum, 칸반Kanban과 같은 애자일 방법론들이 공통으로 강조하는 것이 이 순환/반복적 일하는 방식입니다.

4.2 일하는 방식 변화

애자일 사상과 철학을 실현하기 위해 우리의 일하는 방식은 어떻게 변해야 할까요 ?

인터랙티브Interactive한 쌍방향 소통과 협업을 위해 조직구조는 대규모 기능별 조직에서 소규모 다기능 조직으로 변화해야 합니다.
소규모 다기능 조직인 스쿼드Squad 구성원들은 자신들의 제품/서비스의 목표를 직접 수립 합니다.
애자일하게 일한다는 것은 처음의 계획을 고수하는 것이 아니라 실험과 학습을 바탕으로 상황에 따라 계속적으로 방향전환을 하는 것입니다. 이러한 상황에 따른 방향 전환을 피보팅Pivoting이라고 합니다. 참고로 피보팅은 농구에서 한 발은 고정 시키고 다른 한발은 계속 바꾸는 것을 말합니다.
고정 시키는 한발은 제품/서비스의 밸류Value(비전과 믿음)이고 전환하는 다른 한발은 그 방법이나 결과물입니다.
애자일한 기업의 문화는 수평적이고 개방적입니다. 특히 학습한 실패에 대해 매우 긍정적이고 이를 장려 합니다. 또한 내/외부의 변화를 매우 적극적으로 수용하고 거기에 적응합니다.

 

4.3 애자일 방법론과 성공 사례

가치 중심적으로 쌍방향 소통과 협업하면서 순환/반복적으로 일하는 방식을 기업과 조직에 적용하기 위해서는 체계적인 방법론이 필요합니다.
이러한 방법론 중에서 가장 널리 사용되는 것들이 린스타트업Lean Startup, 스크럼Scrum, 칸반Kanban입니다.

린스타트업 방법론을 처음 정립한 에릭 리스Eric Ries는 스타트업Startup을 극심한 불확실성 속에서 새로운 제품/서비스를 만들기 위해 기민하게 움직이는 초기 단계의 조직이나 기업이라고 정의 합니다.
에릭 리스에게 영감을 준 스탠퍼드대학 교수인 스티브 블랭크Steve Blank는 스타트업Startup은 아직 사업 모델이 검증되지 않은 조직으로 사업을 하려는 사람들은 회사를 세우기 전에 스타트업 조직을 만들어 먼저 자신들의 사업모델을 검증하라고 합니다.
린스타트업의 핵심 사상은 초기에 적은 비용으로 실험하여 제품/서비스의 성공 확률을 높임으로써 큰 낭비를 줄이자는 것입니다.
이를 위해 Build ⇒ Measure ⇒ Learn의 사이클을 반복적으로 수행하라는 것입니다.
검증되지 않은 가설인 아이디어를 최소 기능 제품인 MVP(Minimal Viable Product)로 만들어 제공한 후 그 결과를 측정하고 학습하여 더 나은 제품으로 만들어 나가는 순환 과정을 점점 더 빠르게 하라는 것입니다.
린스타트업에 대한 보다 더 자세한 내용은 이 책의 주제를 벗어나기 때문에 핵심 사상만 설명하였습니다.
에릭 리스와 애시 모리아Ash Maurya의 책을 꼭 보시길 추천 합니다. 애시 모리아는 린스타트업을 실제 업무에 적용할 수 있는 실용적 수행 방법을 만든 사람입니다.

애자일 개발 방법론인 스크럼과 칸반은 제품/서비스를 만들기 위해 해야 할 일을 의미하는 프라덕트 백로그Product backlog를 나누어 반복적으로 수행한다는 측면에서는 동일합니다.
이렇게 나뉘어진 각 단계를 스프린트Sprint라고 합니다.
가장 크게 다른 점은 스크럼은 각 스프린트에 시간 제약이 있다는 것이고 칸반은 없다는 것입니다.
스크럼은 보통 1주 ~ 4주 단위의 스프린트로 나누어서 제품/서비스를 개발해 나갑니다.
칸반은 WIP(Work In Progress: 진행중인 일)를 3개 이하로 제약하여 하고 있는 일에 집중하게 합니다.
칸반의 원리는 현재 하고 있는 일에 집중하면 더 빠르고 완성도 높게 일할 수 있다는 것입니다. 시간 제약으로 인한 팀원들의 스트레스와 많은 회의에서 오는 시간 낭비를 줄이고 일에만 집중할 수 있는 환경을 만드는 것이 더 좋다는 방법론입니다.
어떤 개발 방법론이 좋은지는 팀원들의 역량과 상황에 따라 선택하여야 하겠지만 실제 각 방법론을 체험하고 어떤 것이 더 본인의 팀에 맞는지 결정하는 것이 제일 좋을 것입니다.
스크럼과 칸반의 자세한 수행 방법에 대해선 시중에 책도 많고 인터넷에서도 쉽게 찾을 수 있습니다.
여러분에게 권장하고 싶은 것은 두려워 하지 말고 자신이 하고 있는 팀플레이에 스크럼과 칸반을 적용해 보라는 것입니다. 그리고 그 결과를 평가하고 학습하여 본인의 팀에 가장 맞는 방법을 찾아 나가길 바랍니다.

애자일의 성공 사례는 매우 많지만 그 중에 가장 대표적으로 많이 언급되는 곳이 스포티파이Spotify와 ING뱅크입니다.
스포티파이는 설립 때부터 애자일 조직을 만들어 성공한 사례로서 그 이후 많은 기업에서 그들의 조직구조를 벤치마킹 하였습니다.
유튜브에서 ‘Spotify 엔지니어링 문화’로 검색하시면 ‘헨릭 크니버그Henrik Kniberg’라는 사람이 올린 동영상이 있으니 참고하시기 바랍니다.

ING뱅크는 IT조직에서 시작하여 비즈니스 조직까지 애자일을 확산한 사례로서 전사 애자일을 추진하는 기업에서 많이 참고하는 사례입니다.
ING뱅크 사례에 대해선 아래 글을 참고하시기 바랍니다.
https://happycloud-lee.tistory.com/224

5. 마이크로서비스와 데브옵스 - 작은 것들을 위한 시

다음으로는 마이크로서비스와 데브옵스에 대해 이해해 보겠습니다.
제가 이 주제들에 ‘작은것들을 위한 시’라는 제목을 붙인 이유는 둘 다 ‘작다’라는 공통점이 있고 그 주제들을 함축적인 ‘시’처럼 핵심만을 전달하겠다는 생각에서였습니다.
BTS의 노래 제목에서 따왔지만 노래와는 아무 상관이 없습니다.

일하는 방식 변화 프레임워크에서 마이크로서비스와 데브옵스는 기업의 생존과 지속성장을 실현하는 수단과 방법이라고 얘기했습니다.
이 두 주제가 왜 가장 성공 확률이 높은 수단이 되는지를 효과적으로 전달하기 위해 세계적인 전략커뮤니케이션 전문가인 사이먼 사이넥Simon Sinek의 골든서클Golden Circles로 설명해 보겠습니다.
골든서클은 다른 사람의 행동을 이끌어 내기 위해서는 결과물인 ‘WHAT’부터 얘기하지 말고 자신의 믿음인 ‘WHY’부터 얘기하라는 논리입니다.
골든서클은 다른 사람에게 메시지를 전달할 때 어떻게 해야할 지 제게 큰 영감을 준 훌륭한 논리였습니다.
유튜브에서 ‘골든서클’로 검색하셔서 ‘How great leaders inspire action’라는 제목의 동영상을 꼭 한번 보시기 바랍니다.
https://m.blog.naver.com/hellokitty4427/220449855113

애플의 성공 마케팅 - 골든서클에 대해서

 

5.1 마이크로서비스

왜 마이크로서비스가 기업의 생존과 지속성장을 위한 강력한 수단이 될까요 ?

1) WHY
여러분이 좋은 아이디어가 있어 사업을 시작했다고 가정해 보겠습니다.
여러분의 회사가 안 망하고 100% 성공하는 비법이 있습니다. 그게 뭘까요 ?
바로 수입은 늘리고 비용은 줄이면 됩니다.
답을 듣고 보면 당연한 말이고 그걸 몰라서 안하는게 아니라 어떻게 그렇게 할 수 있는지 그 방법을 몰라서 못하는 거라고 생각할 겁니다.
하지만 그 방법을 조금만 더 생각해 봅시다.

수입을 늘리려면 시장의 변화에 맞춰 남들보다 먼저 제품이나 서비스를 제공하면 됩니다.
영어로는 ‘타임 투 마켓Time to market’이라고 말하죠. 즉 우리의 서비스는 Time to market할 수 있게 Speedy해야 합니다. 

서비스를 시작했고 잘 운영이 되다가 주문서비스에 장애가 발생했다고 생각해 봅시다. 그 주문 서비스가 정상화될 때까지 여러분의 수익 기회는 사라지고 기업 이미지도 나빠지게 될 겁니다. 그래서 우리의 서비스는 Service Always해야 합니다. 

비용을 줄이려면 불필요한 자원 사용량을 줄이면 됩니다.  
만약에 여러분이 수요 예측을 너무 높게 해서 서비스를 제공하기 위해 100대의 서버를 구매했는데 실제로는 2대의 서버로도 충분했다고 가정해 보죠. 여러분은 쓸데 없는 98대의 서버 비용을 낭비할 것입니다.
또는 그 반대로 수요 예측을 너무 낮게 해서 실제로는 200대의 서버가 필요했다면 어떻게 될까요 ?
엄청난 주문의 폭주를 견디지 못하고 서비스는 느려지다가 멈추게 되겠죠. 여러분의 돈 벌 기회가 사라지게 될 겁니다.
이렇게 우리의 서비스는 Save Cost할 수 있어야 합니다. 

요약하면 시장변화에 빠르게 대처하고, 항상 안정적이며, 비용 최적화를 할 수 있는 제품/서비스를 제공하기 위해 마이크로서비스가 필요한 것입니다. 기억하기 쉽게 요약하면 Speedy, Service Always, Save Cost의 앞 자를 따서 ‘3S’라고 말할 수 있겠습니다.
조금 표현을 바꿔 말하면 기업의 성공 확률을 높이기 위해서 우리의 서비스는 ‘3S’를 보장해야 한다는 것입니다.

2) HOW
그럼 우리의 서비스가 ‘3S’를 보장하려면 어떻게 해야 할까요 ?
‘코끼리를 냉장고에 넣기’라는 유명한 질문이 있습니다.
아마 많은 분들이 그 답을 아시리라 생각합니다.
이 질문의 답은 ‘냉장고 문을 연다 ⇒ 코끼리를 넣는다 ⇒ 냉장고 문을 닫는다’입니다.
복잡하고 어려운 문제는 나누어서 각각 해결하면 된다는 얘기입니다.

<그림>

출처: 블로그 ‘길 위에서 보는 세상’ - 코끼리를 냉장고에 넣는 방법
</>

우리의 서비스가 복잡하고 크다면 ‘3S’를 보장하기 쉽지 않습니다.
일단 큰 서비스를 잘게 쪼개야 합니다.
서비스가 작게 나뉘어지면 각 서비스별로 시장 변화에 대응하기도 쉬워 질것이고 각 서비스를 위한 서버수를 증감시키고 한 서비스의 장애가 다른 서비스에 전파되지 않게 할 방법도 있을 겁니다.

이해를 돕기 위해 예를 들어 보겠습니다.
여기 세트 도시락과 단품 도시락의 두가지 종류의 도시락이 있습니다.
세트 도시락은 판매자가 잘 팔릴 것같은 품목들을 모아 놓은 도시락이고, 단품 도시락은 구매자가 취향에 맞게 품목을 골라 구매할 수 있는 도시락입니다.
세트 도시락은 고민 없이 고를 수 있다는 장점이 있지만 단품 도시락에 비해서 고객 요구사항 수용이 어렵고 일부 품목만 늘리거나 줄일 수 없으며 일부 품목 하나만 떨어져도 그 세트 도시락의 판매는 중단된다는 문제가 있습니다.
각 부품을 서비스라고 생각한다면 3S를 보장하기 위해서 단품 도시락처럼 우리의 서비스를 잘게 쪼개야 한다는 것입니다.

서비스를 작게 쪼개기만 하면 3S를 보장할 수 있을까요 ?
단품 도시락으로 판매를 하는데 고기반찬은 반드시 김치와 같이 판매되어야 한다면 세트 도시락과 큰 차이가 없어질 수 있습니다.
서비스간의 독립성도 반드시 필요할 것입니다.
각 서비스가 독립적으로 버전업 될 수 있어야 하고 각 서비스를 위한 서버 수도 각 서비스마다 다르게 운영할 수 있어야 할 것입니다.

‘3S’의 ‘Speedy’를 위해서는 한가지가 더 필요합니다.
시장의 변화에 빠르게 대응하기 위해서는 한꺼번에 모든 서비스를 만드는 건 좋은 선택이 아닐 수 있습니다.
설사 인력과 비용을 많이 들어서 만든다 하더라도 그게 시장의 요구에 맞지 않을 수도 있습니다.
그렇게 되면 불필요한 낭비가 되겠죠.
그래서 우리는 서비스를 ‘이터래이티브Iterative’하게 만들어야 합니다.
최소한의 기능을 갖춘 서비스를 빨리 출시하고 시장의 반응에 따라 계속적으로 서비스를 발전시켜 나가야 합니다.

요약하면 우리 서비스가 ‘3S’를 보장하려면 우리의 서비스는 ‘마이크로화’되고 상호 ‘독립적’이어야 하며 ‘이터래이티브’하게 발전하여야 합니다.

3) WHAT
그래서 필요한 것이 마이크로서비스라는 수단입니다.
마이크로서비스는 ‘3S’를 보장하기 위해 서비스를 나누고 격리 시키고 이터래이티브하게 발전시키는 방법을 제공하는 기술입니다.
마이크로서비스를 구현하기 위해서는 필요한 것들이 있습니다.
첫째, 마이크로서비스로 나누어서 설계하고 개발하는 방법론이 필요합니다. 그것이 ‘DDD’입니다.
DDD는 Domain Driven Design의 약자로 비즈니스 도메인 중심으로 마이크로서비스를 나누고 설계하여 개발할 수 있는 일련의 방법론을 제공 합니다.
둘째, 마이크로서비스를 개발, 배포, 운영할 수 있는 아키텍처인 MSA(Micro Service Architecture) 도 필요합니다.
셋째, 좋은 MSA와 마이크로서비스를 만들기 위해선 MSA Features와 12Factors라는 특성과 요소들을 갖추어야 합니다.
넷째, 큰 서비스가 마이크로화 되면서 생기는 문제들을 해결하기 위해서 ‘마이크로서비스 패턴’과 ‘MSA’의 다양한 기술들이 적용되어야 합니다.
마이크로서비스는 Complex, Consistency, Operational overhead, Performance라는 4가지 큰 문제가 있습니다. 각 앞 자를 따서 ‘CCOP’라고 줄여서 부르겠습니다.
Complex문제는 마이크로서비스의 개수가 많아지면 많아질수록 서로를 연결하고 통제하는 것이 복잡해진다는 의미입니다.
Consistency문제는 마이크로서비스는 자체의 데이터베이스를 갖게 되는데 그 데이터베이스들간에 데이터 불일치가 발생할 수 있다는 것입니다.
Operational overhead문제는 서비스가 나누어져 있어 운영을 위한 테스트, 배포, 버전관리, 장애관리가 더 어렵다는 것입니다.
Performance문제는 기존에 하나의 모놀리식Monolithic 서비스일 때는 불필요했던 서비스간의 네트워크 트래픽이 발생하기 때문에 필연적으로 성능이 감소할 수 밖에 없다는 것입니다.

마이크로서비스의 ‘CCOP’문제를 해결하기 위해서는 ‘마이크로서비스 패턴’이라는 베스트 프랙티스와 Service Mesh, CI/CD Pipeline, 테스트 자동화, 로깅과 모니터링 등 MSA의 다양한 기술들이 적용되어야 합니다.

DDD, MSA, MSA Features & 12Factors, 마이크로서비스 패턴에 대해서는 이후 장에서 보다 자세히 설명하도록 하겠습니다.

바로 관련 정보를 보시고 싶으신 분들은 각 주제에 대한 글을 참조 하세요.

DDD

https://happycloud-lee.tistory.com/94

DDD 핵심만 빠르게 이해하기

MSA Features & 12 Factors

https://happycloud-lee.tistory.com/188

MSA특성과 MSA 12 Factors 이해

마이크로서비스 패턴

https://happycloud-lee.tistory.com/274

[마이크로서비스 패턴 쉽게 개발] WHY 마이크로서비스 패턴 ?

4) 마이크로서비스 요약
지금까지 마이크로서비스의 WHY, HOW, WHAT을 정리하면 아래와 같이 한 장의 골든서클로 요약할 수 있습니다.

5.2 데브옵스

데브옵스DevOps란 개발 조직과 운영 조직의 벽을 최소화하자는 개념입니다.
시작은 그랬습니다.
하지만, 현재 데브옵스의 진정한 의미는 비즈니스 조직과 IT조직의 협업을 강화하자는 것입니다.
다시 말해, 고객과 업무를 가장 잘 이해하는 비즈니스 조직원의 생각과 아이디어가 실제적인 IT서비스로 구현되고 계속 발전되는 "문화"를 만들자는 것이 데브옵스가 추구하는 방향입니다.

1) WHY
IT프로그램의 개발과 운영 비용 절감, 자동화를 통한 편의성과 속도 향상은 데브옵스의 목표가 아닙니다.
데브옵스문화의 진정한 목표는 고객과 비즈니스를 위한 지속적인 혁신입니다.

2) HOW & WHAT
데브옵스문화를 만들기 위한 힌트는 콘웨이의 법칙에 있습니다.
<인용>
"모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다."
</>
즉, 조직구조를 커뮤니케이션과 협업에 유연하도록 변경하라는 것입니다.

<그림>

출처: 블로그 ‘IT의 중심에서’-콘웨이의 법칙, 시스템은 조직을 닮는다.
</>

이러한 조직구조 변화를 위해서 나온 것이 스쿼드Squad기반의 데브옵스DevOps조직입니다.
데브옵스조직의 최초 성공 사례이자 애자일을 도입하려는 많은 기업들이 참조하고 있는 스포티파이Spotify의 조직 모델은 아래와 같습니다.
서비스별로 스쿼드팀을 만들고 유사한 성격의 서비스 도메인에 속하는 스쿼드를 묶어 약 100명정도의 트라이브Tribe조직을 구성했습니다.
동일한 역할을 하는 사람들끼리는 챕터Chapter라는 조직으로 묶고 서로 다른 역할과 트라이브Tribe의 사람들이 관심사별로 길드Guild라는 조직을 구성할 수 있습니다.

<그림>

출처: Scaling Agile @ Spotify by 헨릭 크니버그
</>



조직구조의 변화와 더불어 고객과 비즈니스를 위한 지속적인 혁신을 위해 더 필요한 것이 있습니다.

데브옵스 조직문화의 생명은 스피드Speed와 이터레이션Iteration에 있습니다. 즉, 비즈니스의 요구에 적시에 대처하고 지속적인 개선을 할 수 있어야 합니다.
이를 가능하기 위해서는 서비스의 CI(Continuous Integration-지속통합)와 CD(Continuous Deployment-지속배포)가 자동화 될 필요가 있습니다.
다시말해, 각 개발자의 개발 결과가 자동으로 통합되고 배포하는 과정이 물 흐르듯이 연속적으로 이루어져야 한다는 것입니다.
CI는 소스업로드에서 배포 이미지 업로드까지의 과정을 의미합니다. 보통 소스 업로드 → 단위 테스트 → 소스 보안 검사 → 실행 파일 생성 → 배포이미지 빌드 → 배포이미지 보안검사 -> 이미지 저장소 업로드의 단계를 거칩니다.
여기서 배포이미지란 어플리케이션 실행을 위해 필요한 OS, 런타임 엔진, 라이브러리, 소스가 하나로 압축된 컨테이너 이미지를 의미 합니다.
CD는 배포 이미지를 이용한 개발계 배포 -> 검증계 배포 -> 시스템/성능/인수 테스트 -> 운영계 배포까지의 단계를 의미합니다.
이러한 CI/CD를 위한 업무 절차를 ‘파이프라인’이라고 합니다. 그리고 파이프라인의 각 단계를 수행하기 위한 도구들을 ‘툴체인Toolchains’이라고 합니다.

위 그림은 CI/CD 파이프라인과 툴체인Toolchains의 예시입니다.
가장 많이 사용되는 툴체인을 구성하는 툴은 아래와 같습니다.

• CI/CD 파이프라인 관리: 젠킨스Jenkins, 뱀부Bamboo, 아르고CDArgo CD, 깃허브 액션GitHub Action, 텍톤Tekton
• 소스형상관리: 깃허브GitHub, 깃랩GitLab, 비트버켓Bitbucket
• 소스보안검사: 소나큐브SonarQube
• 단위 테스트: 스포크Spock
• 실행파일 빌드: 메이븐Maven, 그레들Gradle, npm
• Artifact Library(라이브러리 저장소): 넥서스Nexus, 제이프로그jFrog
• 컨테이너이미지 빌드: 도커Docker, 크라이오CRI-O
• 컨테이너이미지 저장소: 도커 허브Docker HUB, 하버Harbor, 넥서스Nexus
• 배포이미지 보안 취약성 검사: 트라이비Trivy & 클래어Clair(Harbor에 내장)
• 배포: 쿠베컨트롤kubectl, 헬름helm

3) 데브옵스 요약
지금까지 데브옵스에 대한 설명을 요약하면 아래와 같습니다.

 

6. 클라우드 플랫폼 - 시와 음악이 만나는 곳

일하는 방식 변화 프레임워크의 마지막 주제는 ‘클라우드’입니다.
앞에서 얘기 했듯이 클라우드의 목적은 단순히 자원의 임대를 통한 비용 절감이 아닙니다.
그 진정한 목적은 혁신적인 서비스를 만들고 발전시켜나가는 혁신 플랫폼이라는 것입니다.
그런데 플랫폼이 뭘까요 ?
서비스 플랫폼, 플랫폼 조직, 플랫폼 사업모델 등 플랫폼이라는 말을 매우 많이 들어 보셨을 겁니다.
하지만 플랫폼의 진정한 의미를 생각해 보셨나요 ? 혹시 막연히 기반 환경 정도로 생각하시지는 않나요 ?
플랫폼의 진정한 의미는 ‘만나는 곳’입니다. 사람과 사람, 기술과 기술, 사람과 기술을 연결하여 만나게 해주는 공간이 플랫폼입니다.
오고 가는 사람들이 만나는 기차 플랫폼이나 버스 플랫폼을 생각하시면 좀 더 이해하기 쉬울 겁니다.
그래서 서비스 플랫폼은 구매자와 소비자를 만나게 해주는 서비스 공간을 만드는 것이고, 플랫폼 조직은 같은 일을 하는 사람들을 하나의 조직에서 만나게 해주는 것이고, 플랫폼 사업모델은 사람과 사람을 연결하여 수익을 창출하는 사업모델을 의미하게 됩니다.
클라우드는 이러한 플랫폼을 스피디Speedy하게 만들 수 있는 공간을 제공 합니다.
제가 클라우드라는 주제의 제목을 ‘시와 음악이 만나는 곳’이라고 한 것도 사람과 기술을 이어주고 음악처럼 조화를 만드는 공간이라는 의미를 표현하기 위해서입니다.

그럼 클라우드에 대해 약간만 더 알아보고 컨테이너화된 마이크로서비스를 관리해 주는 쿠버네티스에 대해 핵심만 이해해 보도록 하겠습니다.

6.1 클라우드 이해

클라우드의 정의와 플랫폼의 의미에 대해선 이미 설명한 바와 같습니다.

클라우드를 위치와 범위라는 2가지 관점으로 분류해 볼 수 있습니다.
클라우드가 어디에 구성되는 지에 따라서 기업 내부에 위치하면 프라이빗 클라우드Private Cloud이고, 기업 외부에 위치하면 퍼블릭 클라우드Public Cloud라고 합니다. 하이브리드 클라우드Hybrid Cloud는 프라이빗 클라우드와 퍼블릭 클라우드를 같이 사용한다는 의미이지 물리적으로 기업 내부와 외부의 중간에 구성된다는 의미는 아닙니다. 서비스의 성격에 따라 어떤 클라우드에서 서비스를 제공할 것인지는 여러가지 기준이 있겠지만 제일 대표적인 것은 보안성입니다. 보안이 높게 요구되는 서비스는 당연히 프라이빗 클라우드에서 서비스하고, 상대적으로 보안성이 높지 않아도 되는 서비스는 퍼블릭 클라우드에서 서비스 하면 됩니다.

클라우드에서 임대하는 자원의 범위에 따라서는 아이아스 또는 이아스IaaS, 파스PaaS, 사스SaaS로 분류 합니다.
IaaS는 Infrastructure As A Service의 약자로 H/W, 가상화솔루션, OS 등의 인프라 자원만 임대하여 사용하는 모델입니다.

PaaS는 Platform As A Service의 약자로 IaaS의 인프라 자원과 개발과 운영에 필요한 런타임 환경(WAS, JVM 등), 서비스 연결/통제/모니터링, 데이터베이스, CI/CD툴 등까지 임대하여 사용하는 모델입니다. 한마디로 서비스 개발과 운영에 필요한 플랫폼 전체를 임대하는 모델입니다.

 

SaaS는 Software As A Service의 약자로 완성된 소프트웨어 자체를 임대하여 사용하는 모델입니다. 예를 들어 메일, 게시, 전자결재와 같은 그룹웨어나 SAP와 같은 ERP(Enterprise Resource Planning-전사업무통합관리)제품이 대표적이라고 할 수 있습니다.

컨테이너를 관리해주는 플랫폼인 쿠버네티스는 파스 클라우드Paas Cloud 입니다.

6.2 컨테이너 이해

마이크로서비스는 서비스 상호간에 독립성을 위해 컨테이너로 격리하는 것이 가장 좋기 때문에 컨테이너 기술은 마이크로서비스를 배포하고 운영하는데 있어 매우 중요합니다.

컨테이너의 개념을 이해하기 위해 일상 생활에서의 예를 들어 보겠습니다.
여러분이 60대의 은퇴한 직장인라고 생각해 보십시오. 그 동안 함께 많은 시간을 못 보낸 가족과 함께 국내 여러 곳에서 몇 달씩 머물다가 이동하면서 여행을 하고 싶어 합니다. 캠핑카를 이용할 수도 있겠지만 한 곳에 몇 달씩 머물기에는 많이 불편할 겁니다. 그렇다고 여행지 곳곳에 집을 사거나 빌리는 건 너무 비싸기도 하고 이동할 때마다 세간살이를 옮기는 것도 보통 귀찮은 일이 아니구요.
어떤 방법이 제일 좋을까요 ?
컨테이너 하우스를 구매하면 됩니다. 실제로 컨테이너 하우스를 판매하는 사이트도 많이 있습니다.
컨테이너 하우스는 그 안에 생활에 필요한 모든 것이 갖춰져 있고 이동하기도 쉬우며 약간의 공간만 있으면 어떤 환경에도 설치하기가 매우 쉽습니다.

컨테이너 하우스의 장점인 일체성과 이동성이 컨테이너 기술이 나온 이유입니다.
컨테이너는 어플리케이션 구동에 필요한 OS, WAS(Web Application Server: 실행엔진), 라이브러리, 소스를 하나로 합쳐 놓은 작은 서버입니다.
기존에는 물리적인 머신이나 가상머신에 서비스를 설치 하거나 배포하였습니다. 개발계, 검증계, 운영계 등은 각각 물리적으로 머신이나 가상머신이 다르고 어플리케이션은 각 머신이나 가상머신의 OS, WAS, 라이브러리의 영향을 받을 수 밖에 없었습니다.
개발계에서 잘 돌아가던 어플리케이션을 검증계에 배포하면 OS/WAS/라이브러리의 버전 충돌로 안 돌아가는 일이 빈번했습니다. 검증계에서 잘 돌아가던 것이 운영계에 배포하면 또 안 돌아가는 경우도 흔했고요.
이 문제를 해결하기 위해 어플리케이션에서 사용한 종류와 버전의 OS, WAS, 라이브러리를 하나로 합쳐 놓는 컨테이너 기술이 나오게 된 것입니다.
어플리케이션을 컨테이너로 구동하기 위해선 컨테이너 이미지를 빌드하는 단계와 컨테이너 이미지를 실행하는 단계로 나눠야 합니다.
빌드 단계에서는 OS와 WAS를 담고 있는 베이스 컨테이너 이미지Base Container image에 어플리케이션에서 사용하는 라이브러리와 소스를 합쳐서 하나의 압축 파일로 만듭니다.
이 압축 파일이 컨테이너 이미지이고 이 이미지를 실행하여 서비스를 제공하는 서버가 컨테이너입니다.
컨테이너의 일체성은 자연스럽게 컨테이너 간 격리성을 제공 합니다. 컨테이너가 서로 격리 되므로 그 안에 담겨져 있는 서비스는 자연스럽게 상호 독립성을 보장 받게 됩니다.
그래서 마이크로서비스가 독립적으로 빌드/배포/스케일링 되려면 컨테이너화 하는 것이 가장 좋은 방법이 되게 됩니다.

컨테이너 이미지를 빌드하고 실행하는 제품에는 도커Docker와 크라이오CRI-O가 있습니다.
이 중 가장 먼저 나오고 아직까지도 가장 많이 사용하고 있는 것이 도커Docker입니다.
크라이오CRI-O는 도커의 서버 모듈인 도커 데몬Docker Daemon이 너무 많은것을 하다 보니 느려지고 도커 데몬의 장애 시 전체 서비스가 중지되는 문제를 해결 하기 위하여 나온 제품입니다.
참고로 컨테이너디containerd라는 컨테이너 런타임 제품도 있는데 위 문제를 해결하기 위해 도커사에서 개발한 새로운 컨테이너 런타임 제품으로 도커 버전 1.11 이후부터 도커에 내장되어 있습니다. 도커를 설치하면 컨테이너디containerd도 자동으로 설치 됩니다.
크라이오CRI-O는 쿠버네티스 진영에서 만들었으며 쿠버네티스 1.24이후에는 도커가 아닌 크라이오와 컨테이너디가 컨테이너 실행 엔진으로 사용될 예정입니다. 2021년 12월 현재 쿠버네티스 최종 버전은 1.23.1입니다.
https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/
dockershim will be removed in December at the beginning of the 1.24 release development cycle.

쿠버네티스가 컨테이너 런타임을 도커에서 크라이오나 컨테이너디로 바꾸게 되더라도 도커로 만든 컨테이너이미지는 아무런 문제 없이 실행 됩니다.
왜냐하면 도커, 컨테이너디, 크라이오 모두 컨테이너 표준인 OCI(Open Container Initiative)를 준수하기 때문입니다.

6.3 컨테이너 관리 플랫폼 쿠버네티스

도커, 컨테이너디, 크라이오는 하나의 머신이나 가상머신에서 컨테이너를 관리할 수 있지만 여러개의 머신이나 가상머신에서 컨테이너를 관리하긴 힘듭니다.
실제 대부분의 서비스는 여러 머신이나 가상머신에서 서비스 되기 때문에 보다 발전된 기술이 필요하게 되었습니다.
그래서 나온 것이 컨테이너 관리 플랫폼인 쿠버네티스Kubernetes입니다.
쿠버네티스Kubernetes를 k8s로 줄여 부르기도 하는 데 첫자인 ‘k’와 마지막 자인 ‘s’사이에 8개의 알파벳이 있기 때문입니다.
쿠버네티스는 매우 복잡하고 범위가 넓은 제품이지만 개발을 위해서는 아래 그림 정도만 일단 이해해도 됩니다. 보다 더 자세한 내용은 이후 장에서 다루도록 하겠습니다.

쿠버네티스는 컨테이너를 관리하기 위해 여러가지 역할을 가진 컴포넌트로 구성되어 있습니다. 이러한 쿠버네티스 컴포넌트를 리소스Resource라고 부르고 그 리소스를 이용하여 생성한 객체를 쿠버네티스 오브젝트Object라고 부릅니다.
위 그림에서 빨간색으로 표시한 것이 쿠버네티스 리소스들입니다.
자바에서 클래스로 오브젝트를 만드는것과 똑같이 쿠버네티스 리스스는 오브젝트를 만드는 틀이라고 할 수 있습니다.
예를 들어 나만의 파드를 ‘pod1’이라는 이름으로 배포했다면 ‘pod1’은 리소스 ‘Pod’로 실행한 오브젝트가 되는 것입니다.

쿠버네티스 오브젝트는 확장자가 ‘야믈yaml’인 파일에 정의합니다. 예를 들어 ‘서비스Service’라는 리소스로 오브젝트를 생성하려면 야믈 파일에 정해진 규칙대로 정의하고 그 파일을 kubectl이라는 CLI툴로 적용하면 됩니다.

CLI(Command Line Interface)는 명령어를 통해 서버에 어떠한 수행을 요청해 주는 툴입니다.
쿠버네티스의 CLI는 kubectl이고 도커의 CLI는 docker입니다.
kubectl은 우리말로 쿠베컨트롤이나 큐브시티엘로 많이 부릅니다.
표준화된 명칭은 없지만 저는 쿠베컨트롤로 부르는게 더 좋은 것 같습니다.
예를 들어 쿠버네티스 서비스 오브젝트의 목록을 보려면 ‘kubectl get service’라고 입력하면 됩니다.

그럼 쿠버네티스의 핵심 리소스들에 대해 이해해 보겠습니다.

파드Pod는 컨테이너들을 담고 있는 리소스입니다. 하나의 파드에는 여러개의 컨테이너가 존재할 수 있습니다. 쿠버네티스에서는 파드를 ‘작은서버’라고 생각해도 크게 틀리지 않습니다.
그래서 쿠버네티스에서 스케일링 한다는 것은 이 파드수를 늘이거나 줄인다는 의미입니다.

파드는 실제 서비스 시 장애 대응을 위해 최소한 2개 이상을 실행하여야 합니다. 그래야 한 파드가 장애가 나면 다른 파드로 서비스를 할 수 있으니까요.
이렇게 서버를 2개 이상 구성하는 것을 ‘이중화’라고 표현하고 한 서버의 장애 시 다른 서버로 대체하는 것을 ‘Failover’라고 말합니다.

서버가 2개 이상이므로 사용자의 요청을 어떤 서버로 연결할 지 분배해주는 무언가가 필요합니다.
이렇게 사용자의 요청을 분배해주는 것을 로드밸런싱(Load Balancing)이라고 합니다.
여기서 로드Load는 워크로드Workload의 약자이고 서비스를 제공하는 서버를 의미합니다. 쿠버네티스에서는 파드라고 할 수 있습니다.

서비스Service는 파드를 로드밸런싱 해주는 리소스입니다.
우리가 흔히 말하는 서비스와 헷갈릴 수 있는데 마이크로서비스Microservice의 Service라고 생각하시면 자연스러울 수 있습니다.
예를 들어 우리가 주문을 처리하는 마이크로서비스를 만들었다면 ‘주문 Service’라는 오브젝트를 생성하고, ‘주문 Pod’ 오브젝트를 여러 개 띄우면 되는 것입니다.

쿠버네티스 Service는 특수한 경우가 아니면 클라이언트(웹브라우저, 모바일앱 등)에서 접근할 수 없도록 생성합니다. 그렇다면 클라이언트에서 접근할 수 있는 주소를 제공하고 쿠버네티스 Service를 연결해 주는 무언가가 필요하겠죠 ?
그것이 바로 Service Load Balancer인 ‘인그레스ingress’입니다.

그냥 Service를 외부에서 접근할 수 있도록 만들면 돼지 왜 복잡하게 인그레스ingress라는 리소스를 또 만들어야 할까요 ? 가장 큰 이유는 쿠버네티스 서비스를 외부에서 노출시킬 수 있는 수의 제한이 있기 때문입니다.
인그레스는 요청되는 주소의 경로에 따라 Service를 로드밸런싱할 수 있습니다.
예를 들어 ‘http://{ingress host}/order’로 요청되면 ‘주문 Service’를 연결하고, ‘http://{ingress host}/pay’로 요청되면 ‘Pay결제 Service’로 연결하도록 할 수 있습니다.

어플리케이션을 개발할 때 유연한 개발을 위해 환경변수를 많이 사용합니다.
예를 들어 데이터베이스를 연결할 때 데이터베이스 서버 주소, DB 사용자명, DB 사용자 암호를 지정해 줘야 하는데 이를 소스에서 하드코딩하면 안되겠죠 ? 왜냐하면 개발계, 검증계, 운영계에서 사용하는 데이터베이스 서버가 다 다른데 각 환경에 배포할 때 마다 소스를 바꾸는 것은 바보같은 짓이기 때문입니다. 데이터베이스 서버의 주소나 계정정보가 바뀔때도 문제가 되구요.
쿠버네티스에서 환경변수를 만들어 주는 리소스가 컨피그맵ConfigMap과 씨크릿Secret입니다.

어떤 리소스로 생성하던 어플리케이션에서는 환경변수처럼 읽어서 사용할 수 있습니다.
예를 들어 ConfigMap에 DB서버 주소와 DB사용자명을 DBHost, DBUsername으로 정의 했고, Secret에 DB사용자 암호를 DBUserPW라고 정의했다고 합시다.
Java어플리케이션이라면 System.getenv(“DBHost”), System.getenv(“DBUsername”), System.getenv(“DBUserPW”)와 같이 환경변수를 읽을 수가 있습니다.

그럼 ConfigMap과 Secret의 차이는 무엇일까요 ?
ConfigMap은 환경변수의 값을 평문으로 정의하고 Secret은 base64로 암호화해서 정의한다는 것입니다. 상대적으로 Secret이 보안을 약간 더 보장하기 때문에 암호나 API키와 같이 중요한 환경변수는 Secret으로 만들어야 합니다.
Secret은 보안을 보장하기 위한 다른 추가적인 방법도 제공 합니다.

어플리케이션은 처리를 위해 필요한 데이터를 읽거나 처리 결과를 저장하기 위해 데이터 저장소가 대부분 필요합니다.
어플리케이션이 데이터 저장소를 사용하기 위해 필요한 리소스가 PVC(Persistent Volume Claim)와 PV(Persistent Volume)입니다.
PVC는 데이터 저장소 사용 요청서이고 PV는 실제 데이터 저장소 정의 리소스입니다.
파드가 데이터 저장소를 연결하려면 PVC와 연결 되어야 하고, PVC와 PV가 연결(바인드-Bind)되어야 합니다.

지금까지 서버인 Pod, Pod 로드밸런서 Service, Service 로드밸런서 ingress, 환경변수 ConfigMap과 Secret, 데이터 저장소 사용을 위한 PVC와 PV를 설명했습니다.
마지막으로 파드를 배포하고 통제하는 리소스들인 워크로드 컨트롤러Workload Controller까지만 설명하고 마치겠습니다.
파드에 담긴 어플리케이션의 성격에 따라 워크로드 컨트롤러는 아래 5종류가 있습니다.

• 디플로이먼트Deployment: 보통 어플리케이션 배포 시 사용. 파드이름이 랜덤숫자로 만들어짐
• 스테이트풀셋StatefulSet: 보통 DB 배포 시 사용. Pod 이름이 일련번호가 붙어서 만들어짐
• 데몬셋DaemonSet: 항상 실행되어 무언가를 감시하거나 처리하는 데몬 성격의 어플리케이션 배포 시 사용. 한 노드(물리머신 또는 VM)에 항상 한개의 파드만 실행됨.
• 잡Job: 1회성으로 무언가 처리를 하고 종료되는 어플리케이션을 배포할 때 사용. 예를 들어 데이터 마이그레이션(이관) 작업을 하는 어플리케이션이나 어떤 작업의 사전 준비 상태를 체크하는 어플리케이션 같은 것을 배포할 때 사용
• 크론잡CronJob: 1회성이 아닌 주기적으로 무언가 처리를 하는 어플리케이션을 배포할 때 사용

※ 디플로이먼트와 스테이트풀셋의 개념 차이와 사용 방법은 3장에서 자세히 다루겠습니다.

7. 요약

최신 변화 트렌드를 요약하면 조직구조 변화 스쿼드Squad, 서버 단위의 변화 컨테이너Container, 어플리케이션 단위 변화 마이크로서비스Microservice, 서비스 플랫폼 변화 클라우드Cloud라고 할 수 있습니다.
이러한 변화의 이유는 급변하고 불확실한 세상에서 기업이 생존하고 지속성장하기 위해서입니다.
일하는 방식 변화 프레임워크는 기업의 생존과 지속성장을 위해 사상/철학인 애자일, 수단/도구인 마이크로서비스와 데브옵스, 혁신 플랫폼인 클라우드로 구성되어 있습니다.
이러한 일하는 방식 변화 프레임워크를 요약하면 아래와 같습니다.