박승필 
1# KubeCon + CloudNativeCon North America 2019 참가기
세션에 관한 이야기
자~ 그럼 저희가 참석한 세션들 중, 인상 깊었던 세션들 몇 가지에 대해서 적어 보겠습니다.
Running Istio and Kubernetes On-prem at Yahoo Scale
예전에 명성에 미치지는 못하지만, Yahoo에서의 CloudNative로의 변환 여정과 그 과정에서의 사용된 기술들을 설명하는 세션이었습니다.
Overview
발표자
Suresh Visvanathan(Verizon Media, Sr Architect)
Sr Architect 인 Suresh Visvanathan은 IT 및 소프트웨어 분야에서 13 년 이상의 경험을 가지고 있습니다. Suresh의 현재 업무에는 클라우드 플랫폼 서비스 (PaaS)의 아키텍처, 비전, 전략 및 디자인이 포함됩니다. Suresh는 탄력성 엔지니어링, 자동 복구 시스템을 중심으로 솔루션을 설계하고 제품을 제작 해 왔으며 K8s 밋업, 카오스 커뮤니티 이벤트 및 kubecon 2017의 스피커에서 자주 연설자입니다.
Mrunmayi Dhume(Verizon Media, Senior Software Engineer)
Mrunmayi Dhume은 Verizon Media의 핵심 플랫폼 팀 선임 소프트웨어 엔지니어입니다. 그녀는 Verizon Media에서 L3 / L4 라우팅 솔루션을 제공하는 팀의 일원이며 K8 워크로드를위한 라우팅 계층 및 아이덴티티 공급자 시스템 구성 요소의 설계 및 구현을 이끌고 있습니다. 그녀는 회사 내에서 Istio를 채택하는 데 중요한 역할을했습니다. 또한 텍사스 오스틴의 KubeCon 2017에서 연사로 활동했습니다.
Yahoo 는 전세계 7개 데이터 센터에 걸쳐 12만 8천개의 컨테이너를 운용하고 있다고 발표하였습니다.
정확한 수치로 나열 해 보겠습니다.
- 파드: 35942
- 컨테이너: 128412
- 노드: 2958
- 애플리케이션 수: 993
그리고, 이러한 큰 규모의 쿠버네티스로의 전환 작업은 2017 년부터 시작하여 오늘날에 이르렀다고 하였습니다.
<2017 년 모습과 현재 모습>
이 이야기를 듣고, 바로 떠오른 생각은 컨테이너 오케스트레이션 기술을 사용할 경우 이러한 양적 확산은 보장된 길이겠지만, 대규모의 이전 작업을 체계적으로, 오차없이, 글로벌 스케일로 전개 해 나간 조직적 역량과 히스토리를 듣고 싶다!! 였습니다.
하지만 아쉽게도 발표자께서는 리더 역할이 아닌 엔지니어 였고, 글로벌 스케일 컨테이너 운용 에서의 보안 과 배포 규약 에 관련된 키워드를 주제로 세션을 진행 해 주셨습니다.
그래도 저희가 따라잡기에는 한참 높은 수준의 기술력에 대한 이야기인지라, 세션 후에 별도로 스터디를 통하여 내용을 이해하여야 하였습니다.
Multi-tenancy & Auth
CICD 파이프라인을 통해 빠르게 변경사항을 적용하는 것은 오늘날 너무나 노멀한, 특이할 것이 없는 이야기 입니다. 조직 구조가 크지 않다면, 각 조직이 운영하는 어플리케이션 별로 파이프라인을 설정하고, 쿠버네티스의 Soft 레벨의 격리 구조인 Namespace 에 배포하도록 설정할 수 있습니다.
하지만 야후에서는 글로벌 규모의 쿠버네티스 운영을 설계 할 때부터, 수십개의 조직에서 수백개의 어플리케이션을 배포 하는 과정에서, 누군가 실수로 파이프라인 코드 안에 잘못된 배포 (남의 Pod 를 덮어쓴다든지) 설정을 하거나, 잘못된 마이크로 서비스 도메인 등록으로 인해 다른 조직의 어플리케이션에 Rest Api 를 보내 심각한 비즈니스 타격을 입히는 상황 등을 우려했다고 합니다.
발표자께서는 이 문제를 해결하기 위해 야후에서 직접 개발한 Athenz 오픈소스 프로젝트를 소개 해 주셨습니다.
Athenz는 프로비저닝 및 구성 (중앙 인증) 사용 사례와 서비스 / 런타임 (분산 인증) 사용 사례를위한 RBAC (역할 기반 인증)를 지원하는 서비스 및 라이브러리 세트입니다. Athenz 인증 시스템은 Principal Tokens (N-Tokens)와 RoleTokens (Z-Tokens)의 두 가지 유형의 토큰을 사용합니다. “Athenz”라는 이름은 “Auth”및 ‘N’및 ‘Z’토큰에서 파생됩니다.
Athenz 의 동작구조를 찾아보았습니다. 쿠버네티스 API 앞단에 위치하여, kubectl (user commands) 로부터 오는 명령, 즉 배포 요청에 대해 멀티 테넌시 인증 체크를 해 주는 모습입니다. 이 그림만 보아서는 매우 심플하며 특별 할 것 없는 것처럼 보였습니다. 그냥 단순한 Rest Api Filter 처럼 보였으니까요.
단순히 배포에 관해 멀티 테넌시 인증을 차용하는 것은 기술적 허들이 높지 않지만, 마이크로 서비스 간 통신에 멀티 테넌시 보안을 적용하는 것은 한단계 더 높은 보안 기술이 들어갑니다.
쿠버네티스 의 서비스 메쉬 프레임워크인 Istio 를 사용 할 경우, 그림과 같이 Istio 는 마이크로 서비스 간 인증서 기반의 암호화 통신을 사용할 수 있도록 되어있습니다.
*
만일 메가존에서, 야후와 같이 쿠버네티스 를 활용하여 모든 서비스를 이전하길 희망하는 큰 규모의 회사와 협업을 하게 되었다고 생각 해 봅시다.
이 회사에는 A 부서와 B 부서가 있고, 서로 개인정보를 가지고 있는데, 두 사업체의 도메인이 전혀 달라 서로간의 개인 정보는 보호되어야 합니다. 하지만 A 부서와 B 부서의 컨테이너들은 경우에 따라 서로간의 API 를 호출해야 하는 일도 있고, 운영적 이슈, 비용 등으로 인해 동일한 클러스터 내에서 배포 되었으면 합니다.
위 그림에서처럼 기존 Istio 의 인증서 기반 보안은 A 부서와 B 부서의 시스템을 구별하지 않고 하나의 인증서로 보안 통신을 합니다.
Athenz Istio Authz 컨트롤러 를 적용하면, A 부서와 B 부서간의 인증서 및 역할 정책을 분리 할 수 있으므로 서로간의 허용된 API 만 호출할 수 있게 네트워크 레벨에서 격리시킬 수 있습니다.
- Athenz Istio Authz 컨트롤러 :
- 테넌트 별 역할 및 정책을 Istio 보안 정책에 매핑
- 테넌트 별 역할 / 정책 변경 사항을 Istio 와 동기화 유지
*
Yahoo K8s Developer Experience
여전히 문제는 남아있습니다. 역할 분리 및 정책에 대한 대비를 잘 해놓고, 인프라적으로 구축했다 하더라도 개발자가 자신의 pod 설정에 이를 무시 해 버린다면 인재로 이어질 수 있습니다.
무슨 방법으로 이 문제를 해결하였나 들어보았는데, 답은 심플했습니다. “강제로 시켰다” 였네요.
코드 베이스와 마찬가지로 pod 설정 등을 포함한 배포 파일들도 템플릿 베이스가 있습니다. 개발자들이 배포 템플릿 파일들을 자신의 소스코드에 포함시켜 설정을 맞추면, 자동으로 나머지 Configuration 파일들이 생성되는 구조로 운영한다고 말하고 있습니다.
*<기준 배포="" 템플릿이="" 포함된="" jar="" 파일="">*
CI/CD 파이프라인에 대해서도, 배포 파일들의 적합성을 판단하고, Functional Tests 를 진행하는 흐름을 맞추기 위하여 각 조직별 파이프라인을 고려하기 보다는 하나의 표준화 된 CICD 파이프라인 플로우를 지키려 노력했다고 합니다.
<표준화 된 CI/CD Pipeline Flow>
세션이 끝날때 까지, 아쉽게도 정말 궁금했던 “대규모의 이전 작업을 진행했던 구체적인 스토리” 는 나오지 않았습니다.
그러나 파편 적으로 나왔던 이야기에서 얼추 예상한 바로는 기술은 기술이고, 이 기술을 스케일 있게 전체적으로 적용하기 위해서는 다소 강제성이 있었던 것으로 보입니다.
우리 나라 용어로는 강제성 이라는 네거티브 한 단어로 해석되지만 야후나, 기타 거대 IT 조직 에서는 스케일러블 애자일 프로세스 라고 불리며 큰 기술 방향성에 대해 매우 빠르게, 체계적으로 확산 가능한 조직적 힘이 뒷받침 되지 않았나 생각 해 봅니다.
Airbnb Services Discovery: Past, Present, Future (Challenges of Change)
Overview
글로벌 스케일 서비스의 하나인 Airbnb의 Service Discovery 변혁사에 대한 내용 주제로 발표하는 세션이었습니다.
해당 세션의 사이트 요약 내용은 아래와 같습니다.
2013 년 에어 비앤비는 오픈 소스 Service Discovery Solution (SmartStack)을 출시했으며 수년 동안 동일한 프레임 워크에서 작동했습니다. 역사적으로 우리의 인프라는 AWS EC2 인스턴스에서 실행되었으며 트래픽 프록시를 위해 HAProxy (스마트 스택 내)를 사용했습니다. 서비스 지향 아키텍처 및 Kubernetes로 마이그레이션함에 따라 Service Discovery도 변경 되어야 합니다. 이 프레젠테이션에서는 에어 비앤비가 Service Discovery Framework의 진화를 위해서 어디서 시작했고, 어디로 갔고, 어디서 실패했는지 그리고 에어 비앤비가 어디로 가는지(힌트 : Envoy)를 다룰 것입니다. 여기에는 우리의 실수와 하이브리드 EC2 / Kubernetes 세계 내에서의 마이그레이션에 대한 학습이 모두 포함됩니다. 자체 서비스 검색 스택 관리 및 마이그레이션, 수신 및 발신 트래픽 독립적으로 마이그레이션, 대규모 서비스에 인프라 변경 사항을 롤아웃하는 등의 주제에 대해 자세히 설명합니다.
발표자
Chase Childers(Airbnb, Site Reliability Engineer)
Chase Childers는 에어 비앤비의 사이트 신뢰성 엔지니어링 팀에 있습니다. 그는 서비스 오케스트레이션 및 트래픽 팀과 협력하여 EC2 및 Kubernetes 컨텍스트에서 서비스 검색 마이그레이션에 중점을 두었습니다. 이 협업 이외에도 에어 비앤비 제품 및 기능 출시 준비, 관찰 가능성 및 안정성 향상 노력, 에어 비앤비의 프로덕션 준비 상태 검토 프로세스 등이 그의 관련 작업에 포함됩니다.
Service Discovery - AirBnb
개인적으로 머리 속에 정립되어 있는 개념을 풀어보자면, Service Discovery 란 마이크로 서비스 아키텍쳐에서 각 서비스에 대한 엔드포인트 를 찾는 것을 말합니다. 단순히 생각하면 하나의 주소록 서버 라고 생각할 수 있겠는데, 다음의 시나리오로 쉽게 생각할 수 있습니다. 물론 오늘날 Service Discovery 는 아래 시나리오 보다 훨씬 기술적으로 발전되었지만, 이해를 돕기 위해 원시적 시나리오로 표현 해 봅니다.
- 서비스 A 는 호텔 정보를 전달하는 서비스 입니다.
- 새롭게 태어난 컨테이너 A-1 은 Service Discovery 에 자신의 출생 정보(IP) 를 등록합니다.
- 서비스 B 는 여행 패키지 조회 서비스인데, 서비스 A 의 호텔 정보를 호출하고 싶어합니다.
- 서비스 B 는 Service Discovery 에 서비스 A 가 어디에 있는지 물어봅니다.
- Service Discovery 는 컨테이너 A-1, A-2, A-3… 의 주소록 목록을 반환합니다.
- 서비스 B 는 라운드 로빈 룰에 의해 A-N 중 하나를 선택하여 API 를 호출합니다.
- 갑자기, 컨테이너 A-1 이 모종의 이유로 인해 Dead 상태가 되었습니다.
- Service Discovery 는 A-1 이 살았는지 계속 체크하다가 (health check) A-1 이 정상적이지 않다는 것을 알았습니다.
- Service Discovery 는 A-1 을 주소록에서 삭제합니다.
- A-1 이 갑자기 살아났습니다. 아마 네트워크 트래픽이 몰려 잠시 Dead 상태인 줄로 착각 하였나 봅니다.
- Service Discovery 는 A-1 을 다시 주소록에 등록시켜 놓습니다.
이처럼, Service Discovery 는 클라우드 환경에서 빈번하게 죽고 태어나는 컨테이너들의 Health 를 체크하며, 마이크로 서비스 간에 올바른 주소 호출을 할 수 있도록 도와줍니다.
저희는 줄곧 클라우드 매지니드 서비스로 제공되는 Service Discovery 만 사용해 왔던 입장이었기 때문에, 온-프레미스 환경에서부터 출발 해 온 AirBnb 가 직접 Service Discovery 를 운영 하며 겪어왔던 어려움에 대해서는 경험 해 보지 못한 세대입니다.
만약 메가존에서 클라우드 환경으로 갈 수 없는 온-프레미스 환경을 가진 고객을 만났을 때, 어떻게 Service Discovery 문제를 해결 할 수 있는지 AirBnb 의 사례를 공부하며 간접 경험을 할 수 있는 값진 시간이었습니다.
Phase 0: In the Beginning
발표자께서는 AirBnb 초장기 시절 Service Discovery 를 위해 SmartStack 서비스를 직접 개발하고 실 운영 하였던 경험을 이야기 해 주셨습니다.
서비스의 Health Check 를 위한 Nerve 와, Health 한 서비스로 라우팅 하기 위해 리버스 프록시 엔진인 Haproxy 를 사용했는데, Haproxy 컨피그레이션 를 실시간으로 하기 위한 Synapse 로 구성되어 있는 프로젝트 였습니다.
*
옛날 컨테이너 플랫폼들이 등장하기 전에 온프레임 환경의 대다수 Service Discovery 가 위와 비슷한 아키텍처로 되어 있음이 기억납니다.
Phase 1: Kubernetes
AirBnb 에서 쿠버네티스로 전환 작업을 시작했을 때는 Istio 의 핵심 프락시 엔진인 Envoy Proxy 는 존재했지만 Istio 는 아직 나오지 않았던 때 였던 것 같습니다.
왜냐하면, 이어지는 장표에서 일반적인 Istio 사용과는 너무 다른 모습의 아키텍처를 보여주었기 때문입니다.
*
오늘날 Istio 모듈에 들어가 있는 mTLS Syncer, Service Discovery, Control Plan 등의 역할을 자체적으로 만들어야 했고, 기존에 가지고 있는 솔루션인 SmartStack 과 연결하여 사용하였습니다. (1~2 년만 기다렸어도 하지 않을 선택을..)
AirBnb 가 택한 방식은 모든 컨테이너가 각자의 주소 정보를 Zookeeper 에 저장 해 놓고, 또 다시 모든 컨테이너들이 각자가 SideCar 로 들고다니던 HaProxy 모듈에 전체 클러스터의 모든 주소록을 갱신하는 방식이었습니다.
아마도, 위 그림을 함께 본 많은 경험많은 세션 참석자들이 저희와 같은 공통의 문제점을 생각하였을 것 같습니다.
서비스가 성장하여 컨테이너 수가 많아진다면, 컨테이너 주소 목록도 함께 증가 할 것입니다. 이 경우 문제가 되는 부분은 Haproxy 에 쓰여질 매우 길어질 라우팅 코드와, 주소지 변경사항을 갱신하기 위해 Haproxy 가 빈번하게 Re-load 될 때 발생하는 네트워크 딜레이 입니다.
단순히 메모리,CPU 를 많이 소모해서 비효율 적인 수준의 문제가 아니고, Haproxy 를 Re-Load 하는데 시간이 오래 걸리게 되면 핵심 비즈니스 프로세스 (결제 프로세스 등) 등이 타격을 받을 수 있기 때문에 매우 심각한 문제라고 볼 수 있습니다.
때마침 AirBnb 의 서비스가 급성장을 하기 시작했고, 이 아키텍처의 문제점이 바로 나타나기 시작했습니다.
*<너무 많은="" 주소지="" 갱신을="" 위해="" Re-load="" 하는="" Haproxy="" 로부터="" 발생하는="" 이슈="">*
또 하나의 문제가 있었는데, 모든 컨테이너 주소 변경 사항을 Zookeeper 를 통해 한번에 갱신하고 로딩하는 작업이 반복되다 보니 네트워크 트래픽을 감당하지 못했었다고 합니다.
관련 해결법에 대해 AWS 에 문의 해 보니, Zookeeper 가 설치된 EC2 인스턴스를 Scale-Up 하면 관련된 네트워크 트래픽 한도도 증가될 수 있다고 답변을 받았답니다.
EC2 인스턴스의 네트워크 트래픽 한도까지 다다르는 경험은 웬만해서는 잘 할 수 없지만, 컨테이너 배포가 한번에 많이 일어 날 경우, 컨테이너 이미지 다운로드 트래픽이 몰리는 상황에서 종종 발생 할 수 있는 문제입니다.
이런 팁은 현재 메가존 SA 분들이라면 거의 다 알고있는 사실일 텐데, AirBnb 초창기 시절에는 예상하지 못했을 수도 있겠구나~ 하며 경청하였습니다.
Phase 2: Envoy
이어지는 이야기들은 몇몇 어려웠던 점을 어필한 후에, 오늘날 AirBnb 에서는 결국 자체 개발한 SmartStack 을 모두 버리고 쿠버네티스와 Envoy(Istio) 구성으로만 운영하고 있다고 합니다.
SmartStack 을 개발했던 개발자 분들의 노고도 있고, 적지 않은 에포트가 들어갔겠지만, 더 좋은 방향이 있다면 과감히 인정하고 옳은 길로 향했던 AirBnb 의 결정이 인상깊었습니다.
Cloud Native Architecture: Monoliths or Microservices?
Overview
매우 흥미로운 주제 였습니다. 특히 발표 전에 사회자가 참석자들에게 모놀리스 아키텍처 vs 마이크로 서비스 아키텍처 중 선호하는 것에 대해 손을 들어 보라고 하였고, 손을 든 사람 숫자가 비슷하여 흥미로웠습니다.
해당 세션의 내용은 아래와 같습니다.
마이크로 서비스는 아주 좋은 이유로 현재 인기가 많습니다 . 그러나 마이크로 서비스에는 단점이 없지 않으며 복잡한 구성 및 배포가 필요하므로 개발자와 사용자 모두에게 진입 장벽이 높아집니다. 이 나쁜 사용자 경험은 프로젝트 채택 속도를 늦추고 개발자를 방해 할 수 있습니다.
이 문제에 대한 해결책은 많은 성공을 보았습니다. monolith로 기능이 가능한 Single banary App은 또한 마이크로 서비스로 변경할 수 있습니다. Thanos는 매우 간단하지만 필요에 따라 확장 할 수 있는 훌륭한 예입니다. Loki 프로젝트는 유사한 모델을 기반으로 패턴화되었으며 이후 Cortex도 다시 설계했습니다. 이번 강의에서는 애플리케이션을 모놀리스 및 마이크로 서비스로 설계하여 어떻게 클라우드 네이티브 마이크로 서비스 애플리케이션으로 확장 할 수 있도록하면서 채택 및 사용 편의성을 향상시킬 수 있는지 살펴 봅니다.
발표자
Edward Welch(Grafana Labs, Software Engineer)
Ed는 CNCF 커뮤니티의 초보자이지만 로봇 제어 시스템에서 통신 미들웨어에 이르기까지 소프트웨어 개발의 오랜 역사를 가지고 있습니다. 그는 신생 기업과 대기업 모두에서 일했으며 현재 Grafana Labs에서 일하며 주로 Prometheus에서 영감을 얻은 오픈 소스 로그 집계 시스템 인 Loki 프로젝트에 중점을두고 있습니다.
Goutham Veeramachaneni (Grafana Labs, Software Engineer)
Goutham Veeramachaneni는 인도의 개발자로 프로 메테우스 (Prometheus)를 배치하는 대기업에서 인턴으로 여정을 시작했습니다. 처음 만난 후, 그는 Prometheus에 공헌하기 시작했고 Prometheus의 새로운 스토리지 엔진을 연구하면서 CoreOS와 교류했습니다. 그는 현재 Prometheus 에코 시스템에 적극적으로 기여하고 있으며 Prometheus 2.0의 엔진 인 TSDB의 관리자입니다. 그는 Grafana Labs에서 오픈 소스 를 연구하고 있습니다. 코딩을 하지 않을때면, 그는 몇 마일씩 자전거를 타며 그의 엉덩이를 아프게 합니다.
저희는 이 세션을 듣기 전까지, 세션 제목인 Monoliths or Microservices 를 보고 모놀리스를 마이크로 서비스로 전환하는 장점에 대해 설명하는 세션인 줄 알았습니다.
그러나 예상치 못하게도, 발표자께서 아래 그림과 같은 첫 장표를 띄웠고, 세션의 주제는 “마이크로 서비스가 정답이 아니다” 라고 하였습니다.
발표자는 새로운 개발 패턴이 필요하다고 하면서, 농담으로 “몇 분 전에 상표를 등록한 모노-마이크로리스” 라고 소개를 하더군요.
History of Monoliths
이어지는 발언에서, 발표자는 하나의 저장소를 사용하는 웹 사이트와 백엔드를 만드는 방식을 사용한 pet-working 서비스의 예제를 들었습니다. (pet-working 은 모놀리식을 설명하기 위한 가상의 서비스 입니다.) 대부분의 응용 프로그램이 시작되는 방식 모놀리스 아키텍처이고, 단일 어플리케이션을 만드는 가장 쉬운 방식이라고 하였습니다.
그러나 사업이 성장하고 강아지 이외에 조류,파충류 등으로 확장되면서 시스템은 더욱 복잡해졌습니다. 모놀리스는 모든 것을 하나의 저장소에 보관했지만 동시에 더 많은 사람들이 파일 작업을 시작함에 따라 충돌이 발생했습니다. Ansible 같은 도구를 통해 배포를 확장 할 수는 있었지만, 모든 사람이 Ansible 플레이 북을 업데이트하거나 이해 할 수 없었기 때문에 유지 관리가 어려웠습니다.
앱이 스테리트리스 하게 설계되지 않았기 때문에 스케일 작업을 수행하려면 로드 밸런서에서 고정 세션을 사용해야했습니다.
조직에서 영업, 마케팅 및 교육과 같은 사업부를 추가하기 시작하면 모두 기존 소프트웨어와는 다른 요구를 가지고 있습니다. 발표자는 이 상황을 “선이 계속 흐려지고있다” 고 설명했습니다.
The Scalability of Microservices
이어지는 내용에서 발표자는 마이크로 서비스로 전환했을 때의 단점도 나열하였습니다. 하나의 예로, monzo(bank) 회사의 백엔드 엔지니어인 Suhail Patel 의 트윗을 보여주며, 1500 개가 넘는 마이크로 서비스가 운영되고 있다고 하며, 지나친 설계라고 지적하였습니다.
What is a Monomicrolith?
여기까지 들었던 이야기는 이미 많은 사람들이 알고 있는 사실이고, 발표자께서 너무 극단적인 예를 들었기 때문에 별로 공감가는 이야기는 아니었습니다. 어서 서론을 다 건너뛰고, Monomicrolith 란게 대체 무엇인지가 듣고 싶었습니다.
일단 “모노 마이크로리스는 마이크로 서비스로 구성되었지만 단일 바이너리로 동작할 수 있는 모놀리스 아키텍처이다” 라고 정의하더군요.
뒤이어, gRPC 를 소개하며 현재 GrafanaLabs 의 많은 프로젝트들을 gRPC 기반 통신으로 전환하고 있다는 이야기를 듣고, 모노 마이크로리스는 단지 gRPC 를 사용하여 개발 하였을 때 나타나는 양상을 재미있게 표현했을 뿐이고, 화자가 말하려는 핵심은 “어떻게 gRPC 를 활용하여 생산성을 높일 수 있나” 인 것을 알 수 있었습니다.
GRPC
<구글이 만든 쓰기 쉬운 RPC 프레임워크, gRPC>
gRPC는 구글이 사내에서 마이크로서비스를 연결하기 위해 사용하고 있던 Stubby 를 오픈소스화 한 것으로, 현재는 CNCF에 소속되어 개발되고 있습니다. gRPC의 용도를 간단하게 설명하자면, ‘원격 프로세스의 함수를 마치 로컬의 함수처럼 사용할 수 있는 프로토콜 또는 인터페이스’ 이라고 할 수 있습니다.
gRPC 사이트에 들어가 보니 “Start quickly and scale” 문구가 눈에 뜁니다. 개발 환경에서는 싱글 라인으로, 실제 프로덕션에서는 수만개로 확장가능 한 시나리오가 가능하다고 합니다. 발표자가 말했던 “모노 마이크로리스” 컨셉에 딱 맞는 설명 같아 보입니다.
Quick Start 예제를 살펴보았습니다.
먼저, .proto 파일을 다음과 같이 작성합니다.
HelloRequest 를 호출했더니 HelloReply 가 오더라… 라는 심플한 내용을 담고 있습니다. 이것을 컴파일하면, Client 코드와 Server 코드가 자동 생성됩니다.
*<서버 코드="">*
*<클라이언트 코드="">*
옛날 웹서비스가 (WSDL) 유행이던 시절의 접근법과 비슷 해 보여서, 이것도 유행이 곧 지나가나 싶었지만 그러기에는 CNCF 를 비롯하여 넷플릭스, CISCO, CoreOS 등 gRPC 를 적용 해 나가는 업계의 분위기가 심상치 않습니다. 하나의 웹 개발 표준처럼 자리 잡을 수도 있겠다는 생각이 들 정도로..
gRPC 는 일단 Rest api 로 호출하지 않고, 하나의 Repository 에서 모든 서비스들을 올려놓고 내 코드의 함수를 호출하는 행위로 마이크로 서비스를 개발하는 것과 동일한 효과를 볼 수 있습니다.
이는 곧, MSA 에 익숙치 않은 (혹은 꺼려하는) 개발자에게, Api gateway, Service Discovery, Fallback, Docker 등 Rest Api 향 MSA 개발에 필요한 개념들을 학습시킬 필요가 없이, 로컬 pc 에서 매우 적은 scale 단위에서 예전 하던 방식대로 유사하게 개발시켜도 되는 큰 장점이 있습니다.
단 .proto 파일을 작성하고 컴파일 해야 된다는 중간 단계가 있기는 하지만, 실력있는 SI 개발자들이 마이크로 서비스를 싫어하는 이유가 “내 코드에서 해결할 수 없는 의존성”, “타인에 대한 불신” 때문이지, 한국인 처럼 기술을 빨리 습득하는 사람들도 없습니다.
조심스러운 이야기지만, 마이크로 서비스 구축 프로젝트에서는 고급, 중급, 초급의 구분이 무의미하고, “경험 해 본 사람” 또는 “하려는 의지가 있는 사람” 들 만이 전력에 도움이 되는 현실입니다. 많은 MSA 관련 도전적인 프로젝트들이 투입 인력 구조를 고급,특급 으로 꾸리면 막연히 되겠지 하고 생각했다가 실패하는 경우가 많습니다.
이제 웬만한 기업체들은 한번씩 학습을 하였기 때문에 검증되지 않는 아키텍처, 검증되지 않는 수행 업체에 쉽사리 기회를 주지 않고 있기도 하고, 무엇보다 마이크로 서비스 환경에 트레이닝 된 우수한 아키텍터, 개발자 들은 서비스 기업에 몰려있고 SI 시장에 풀리지 않고 있어서 도전적인 과제가 시도 조차 쉽지 않은 현실입니다. 최근 정말 자주 듣는 소리가 개발자(Right Person) 구하기 힘들다는 이야기 뿐이니까요.
이런 상황에서 gRPC 로 작은 scale 단위에서 마치 모놀리식 개발 해 나가 듯이 진행하는 것도 하나의 해결법이라는 생각이 듭니다.
꼭 gRPC 가 아니더라도, 아주 처음부터 Scale 한 상황이 필요없는 프로젝트 일 경우에는 동일한 Repository 내에서 개발자 스스로가 2~3 개의 서비스를 핸들링 하는 것 만으로도 모놀리식 개발의 경험에서 크게 벗어나지 않아 거부감을 줄일 수 있겠다고 생각이 듭니다.
회사는 살아남고자 하고, 개발자들은 바뀌지 않으려 할 때, 서로의 탓만 하기 보다는 방향이 무엇이 되었든, 해결법을 찾아나가는 게 다가오는 클라우드 네이티브 시대의 올바른 대처 법이 아닐까요?