한 번 빌드해 Anthos로 클라우드와 온프레미스에서 구동하기 요약 (조병욱님)

Google Cloud Summit에 갔을 때 가장 인상 깊었던 조병욱님의 "한 번 빌드해 Anthos로 클라우드와 온프레미스에서 구동하기"를 정리해보고 싶었는데 그간 시간이 나지 않아서 이번 기회에 정리해보려고 합니다. 

 

블로그로 워낙 유명하신 조병욱님의 실시간 발표를 보다니 영광이였다

 

1) Kubernetes에서 개발을 어떻게 할 것인가 (개발환경에 대한 부분)

 

실제로 컨테이너와 쿠버테니스 기반에서 개발을 해보셨다면 불편함을 많이 느끼셨을겁니다. 쿠버네티스가 좋고 컨테이너 환경도 좋지만 컨테이너 빌드도 해야하고 애플리케이션을 배포하기 위해서는 YAML 파일도 만들어야하고 그것을 각각 개발계, 스테이징계, 운영계에 각각 배포를 해야하는 어려움이 있기 때문입니다. 보통 IDE를 가지고 개발하지만 배포는 다른 툴을 사용해야하는 불편함도 존재합니다. 

 

"이러한 문제들을 풀기 위해 구글의 기술이 어떻게 적용되는가?" 

 

마이크로 서비스를 위한 쿠버네티스

먼저 개발환경에 대해 얘기하기 위해서는 쿠버네티스 그리고 마이크로 서비스에 대한 얘기를 먼저 해야합니다. 그리고 마이크로 서비스를 이해하기 위해서는 먼저 마이크로 서비스와 반대되는 모노리틱 서비스에 대해서 알아야합니다. 

 

모노리틱 아키텍처는 하나의 서비스, 하나의 소프트웨어가 하나의 애플리케이션으로 되어 있는 구조를 뜻합니다. 즉, 하나의 애플리케이션 서버와 하나의 데이터베이스를 가지고 있는 것을 말하며 기존에 많이 쓰던 방법입니다. 하나의 프로그래밍 언어를 사용하여 개발하기 때문에 기술적인 통합성을 가져갈 수 있지만, 반대로 바이너리 사이즈가 커지게 되고 내부의 소스 코드들이 강하게 결합되어(tightly-coupled)있기 때문에 장애라던지 변경에 대한 부작용이 큰 단점을 가지고 있습니다. 그래서 대안으로 대두된 아키텍처가 마이크로 서비스 아키텍처입니다. 

 

마이크로 서비스 아키텍처는 큰 시스템을 각각의 기능 단위로 이를 서비스라는 단위로 나누게 됩니다. 그리고 각각의 서비스들은 REST API나 gRPC와 같은 표준 프로토콜을 통해서 외부로 서비스가 제공됩니다. 각각의 서비스는 다른 기술, 다른 프로그래밍 언어로 개발을 할 수 있는 장점을 가지게 됩니다. 예를 들면, Java 같은 경우 상당히 강건하고 트랜잭션에 강한 애플리케이션을 개발할 수 있는 반면에 Node.js 같은 경우에는 동시에 작은 서버에서 여러명의 커넥션을 소화할 수 있는 장점을 가지고 있습니다. 그래서 마이크로 서비스는 각각의 서비스 특성에 맞게 기술을 적용할 수 있다는 장점을 가집니다. 

 

마이크로 서비스를 보통 기술적인 측면에서 접근하지만, 문화적인 측면이 상당히 강합니다. 

마이크로 서비스를 개발하는 조직을 작게 봐서 5~6명으로 만든 후, 그 인원에게 자치권을 부여함으로써 의사결정이 바로 그 팀 내에서 일어나게 하고 그래서 개발 속도를 빠르게 할 수 있는 기동형 아키텍처라고 생각하시면 됩니다.

 

그리고 이러한 마이크로 서비스로 개발된 애플리케이션을 배포하고 운영할 수 있는 인프라스트럭쳐가 필요한데 그것이 바로 쿠버네티스입니다. 

 

쿠버네티스는 구글의 클라우드 내부 시스템에서 영감을 받아 개발된 오픈소스 소프트웨어이며 오픈소스이기 때문에 어디에서나 기동할 수 있다는 장점이 있습니다. 

 

쿠버네티스가 하는 일은 많겠지만, 가장 심플하게 생각해보면 여러분이 컨테이너를 만들었을 때 그 컨테이너를 물리적인 서버에다 배포를 해야합니다. 그렇다면 어느 서버에다 배포를 해야할까요? 서버가 한 대면 큰 문제가 없겠지만 여러 대의 서버라면 최대한 cpu를 잘 사용할 수 있고 메모리를 잘 사용할 수 있으면서 단편화(fragmentation) 없이 잘 채워서 배포하는 것이 첫 번째 목표입니다. 추가로 여러분이 MySQL 같은 데이터베이스를 고가용성(High Availability, HA) 모델로 배포한다고 가정하면 마스터 서버와 슬레이브 서버가 물리적으로 같은 서버에 배포되면 안됩니다. 왜냐하면 물리적인 서버가 셧다운 될 경우 마스터와 슬레이브 서버가 모두 다운되기 때문입니다. 따라서 적어도 두 서버는 다른 물리적인 서버에 배포 되어야 합니다. 좀 더 확장해서 생각해보면 하나의 물리적인 서버가 아니라 서버들은 하드웨어 렉에 들어가 있는데 좀 더 안전하게 만들기 위해 다른 렉에 배포되는 것이 더 바람직합니다. 여기서 좀 더 확장해서 생각해본다면 다른 렉이 아니라 다른 데이터 센터, 즉 멀티 존에 배포가 되어야 시스템을 안정적으로 운영할 수 있습니다. 

 

이런 복잡한 배포에 대한 컨셉을 개발자나 운영자가 최소한으로 고민하고 배포/운영할 수 있도록 도와주는 것이 컨테이너 오케스트레이션 솔루션이라하며 그 중에서 대표적인 것을 쿠버네티스라고 합니다.

 

대규모 서비스 내에서 복잡한 마이크로 서비스

이제 쿠버네티스와 마이크로 서비스 컨셉을 알게 됐으니 시스템을 실질적으로 운영하고 배포할 수 있을거라고 생각하지만, 마이크로 서비스는 훨씬 더 복잡합니다. 대형 서비스들은 700개에서 1000개 이상의 서비스로 구성되어 있기 때문에 점점 더 복잡해지고 점점 더 많은 서비스로 불어나게 됩니다. 이런 서비스의 문제점은 어떤 시스템 또는 그 안에 있는 서브 컴포넌트 하나가 장애가 나더라도 어떤 컴포넌트에서 장애가 났는지 찾을 수 없다는 것입니다. 그리고 모니터링도 상당히 어려워집니다. 1000개의 시스템은 하나의 시스템으로 돌아가는 것이 아니라 여러 개 10개 ~ 100개의 컨테이너 인스턴스로 운영되기 때문에 최소 수 천개에서 수 만개 이상의 컨테이너를 모니터링 해야되는 문제가 발생합니다.

 

마이크로 서비스 아키텍처 문제를 해결하기 위한 패턴

 이런 문제들을 해결하기 위해 마이크로 서비스 아키텍쳐 패턴이라는 것이 있습니다. 예를 들어 트래픽 제한 패턴 같은 경우에 특정 서비스를 보호하기 위해 서비스가 받을 수 있는 트래픽의 양을 제한합니다. (eg. 초 당 천 건 이상의 서비스를 받지 못하게 한다.)

 

마이크로 서비스 아키텍쳐 패턴을 이용해 서비스간 장애 전파를 막을 수 있는 방법에 대해서 살펴보면

 

서비스 A가 서비스 B에 의해 호출되고 있다고 가정했을 때, 현재 서비스 A가 느려지거나 멈춰있는 상태입니다. 이런 경우에 서비스 A를 호출하는 서비스 B가 요청이 오면, 쓰레드가 서비스 B의 요청을 기다리고 있는 상태가 됩니다. 그럼 이 쓰레드는 사용 중으로 다른 리퀘스트를 처리할 수 없게 됩니다. 이런 과정이 모든 쓰레드에 일어난다면 결국 요청을 처리할 수 있는 쓰레드가 없어져 서비스 B도 장애 상태에 빠지게 됩니다. 지금은 두 개의 서비스 관계에 관해서만 생각해보았지만, 서비스가 많으면 많을수록 이 서비스가 다른 서비스로 전파되면서 전체 시스템에 영향을 주는데 무엇보다 어떤 서비스가 장애의 원인인지 알 수가 없다는 것이 가장 큰 문제입니다. 

 

 

이런 문제점을 해결하는 마이크로 서비스 아키텍쳐 패턴을 서킷 브레이커(누전 차단기)라고 합니다.

서킷 브레이커 : 서비스 A와 서비스 B 사이에 서킷 브레이커라는 일종의 프록시를 설치하며, 서비스 B가 정상일 때는 트래픽을 정상적으로 통과시키며 만약 서비스 B가 장애가 났을 때는 서킷 브레이커가 연결을 인위적으로 끊어버린다. 

 

이런 패턴을 구현하기 위한 여러가지 소프트웨어들이 있습니다.

이런 소프트웨어의 가장 큰 문제점은 이런 패턴을 소프트웨어로 구현해 쓸 경우에 소프트웨어 플랫폼에 대한 종속성을 가진다는 점입니다. 보통 이런 플랫폼이 Java로 구현되어 있기 때문에 Node.js를 사용하거나 Python 같은 프로그래밍 언어를 사용할 때 한계점을 가질 수 있다는 말입니다.  

 

소프트웨어 수준에서 문제를 해결할 수 없기 때문에 이를 인프라 스트럭쳐 수준에서 처리합니다. 그리고 인프라 스트럭쳐 수준에서 문제를 해결한 시스템이 바로 Istio라는 오픈소스입니다.

마이크로 서비스 아키텍쳐 패턴을 구현하기 위한 오픈소스(lstio)

 

Istio의 구조는 대단히 단순한데, 여러분이 서비스 A와 서비스 B를 배포하게 되면 자동으로 각각의 서비스 A와 B 앞에 프록시 서버를 배포합니다. 개발자 입장에서는 본인의 컨테이너만 배포 하겠지만 Istio가 자동으로 이 트래픽을 중간에 가로챌 수 있는 프록시를 자동으로 배포함으로써 여러가지 일을 할 수 있습니다. 

 

새로운 버전을 릴리즈 할 때 새로운 버전에 문제가 있는지 없는지 판단하기 위해서 일부 트래픽만 새로운 버전으로 배포하는 방식을 카날리 배포라고 합니다. 새로운 버전을 배포한 후에 Istio 설정을 통해 새로운 버전으로는 10% 트래픽만, 기존의 버전으로는 90% 트래픽을 흘리도록 할 수 있는데 이 과정에서 애플리케이션 코드 변경은 전혀 발생하지 않습니다. 단지 Istio에서 configuration만 변경하면 중간에 프록시가 트래픽을 컨트롤하기 때문에 프록시단에서 카날리 형식으로 트래픽을 라우팅해줍니다. 

 

Istio는 여기서 그치는 것이 아니라 조금 더 스마트한 라우팅이 가능합니다. Istio에서 사용하는 프록시는 HA 프록시라든지 Nginx 같은 L4 레이어, TCP 레이어 프록시가 아니라 L7, 즉 HTTP를 이해하는 프록시를 사용하고 있습니다. NV proxy라는걸 사용하고 있는데 이를 통해 HTTP 해독 또는 콘텐츠의 내용을 직접 파싱해서 컨텐츠 기반 라우팅을 가능하게 해줍니다. 예를 들어 HTTP 헤더를 통해서 안드로이드로 들어온 트래픽이나 애플 아이폰에서 들어온 트래픽을 인지해서 각각의 서비스로 라우팅 할 수 있다는 장점을 가집니다.

 

이것뿐만 아니라 트래픽을 프록시해서 모니터링하고 하는 과정에서 각각 서비스간의 호출에 대한 메트릭을 모두 수집할 수 있습니다. 즉, 서비스 A가 B로 호출했을 때 호출의 빈도는 얼마가 됐고 호출의 응답 시간은 얼마가 되는지를 수집해 복잡한 마이크로 서비스에 대해서도 토폴로지를 그려줄 수 있습니다. => Stackdriver 서비스 모니터링

 

Istio를 사용하면 트래픽을 컨트롤링함으로써 운영의 유연성을 가질 수 있고 거기다 프록시 간 통신을 하면서 프록시 간 통신이 모두 암호화됩니다. 양방향 SSL을 통해 암호화되기 때문에 트래픽이 컨테이너를 떠나는 순간 모두 암호화 돼서 다른 사람이, 다른 시스템이 볼 수 없습니다. 

 

이제 쿠버네티스와 Istio도 알았기 때문에 모든 것이 해결되 보이지만, 단순하게 스프링부터 애플리케이션하나를 배포한다고 하더라도 로드 밸런서, 서비스, 오토 스케일러, 디스크, 컨피그레이션, 로깅 등 많은 것들을 설정해야하는 어려움 때문에 개발팀이 포기해버립니다. 그래서 나온 것이 바로 Knative입니다. 

 

기존의 서버리스는 벤더 종속성이라는 문제가 있었는데 이 말은 여러분들이 만든 서버리스 애플리케이션을 다른 벤더에서 돌릴 수 없다는 뜻입니다. 그러나, Knative는 오픈소스이기 때문에 어디서든 기동할 수 있습니다.

 

실제 Knative configuration 파일 예시

 

Knative는 REST API 기반 동기 호출뿐만 아니라 Kafka나 RabbitMQ와 같은 큐베이스로 비동기 처리를 해야되는 경우도 Knative 이벤팅을 통해서 비동기 호출을 처리할 수 있습니다. 

 

 

이제 개발자들이 비즈니스 로직에 맞춰 개발만 하면 됩니다!

 

Knative가 좋은 걸 알았으니 이제 깔아야하는 문제가 발생합니다. 

 

Knative를 사용하기 위한 방법

1) Cloud Run : 쿠버네티스에 대한 지식이 거의 필요 없이 컨테이너 url만 넣어주면 된다.

                    + 하나의 인스턴스가 필요한 cpu와 메모리량 정의

 

좀 더 세밀한 컨트롤이 필요하고 조금 더 나의 인프라 스트럭쳐 안에 있는 애플리케이션하고 통합하고 싶을 때, 이것을 쿠버네티스로 내립니다.

 

2) Cloud Run on GKE : 구글 클라우드로 내리는 경우 

 

 

마이크로 서비스를 위한 최종 쿠버네티스 런타임 환경

 

2) 멀티/하이브리드 클라우드 환경을 위한 쿠버네티스 Anthos

최근에 클라우드 도입 추세는 하이브리드 클라우드입니다. 하이브리드가 간단하다고 생각할 수 있지만 대단히 많은 패턴을 가지고 있습니다. 

 

클라우드 버스팅 : 데이터 센터의 온프레미스하고 퍼블릭 클라우드를 연결된 상태에서 컴퓨팅 파워가 모자르면 클라우드에 있는 자원을 사용하는 것을 뜻합니다. 

 

나는 개발자로서 모든 환경에 걸쳐서 통합된 개발을 하고 싶다

 

 

Anthos 안에는 구글 클라우드에서 사용할 수있는 쿠버네티스와 Istio와 Knative 스택을 가지고 있습니다. 이와 같이 똑같은 스택을 구글 클라우드 GKE 온프렘을 이용해서 여러분의 데이터센터에 똑같이 넣을 수 있습니다. 거기다가 타 퍼블릭 클라우드에 있는 쿠버네티스도 같이 운영할 수 있습니다. 

 

그러면 이렇게 많은 쿠버네티스 클러스터를 어떻게 관리할까요?

퍼블릭 클라우드의 경우 로드 밸런서나 ip주소 수가 프로젝트나 계정 단위로 제한되어 있기 때문에 하나의 커다란 쿠버네티스 클러스터를 만들어 놓고 다 넣을 수 없습니다. 그래서 많은 쿠버네티스 프로젝트를 운영해야합니다. 그래서 이것을 통합으로 모니터링할 수 있는 것이 바로 통합된 구글 클라우드 콘솔인 Anthos입니다. 

 

다음으로 해결해야 하는 것은 

 

1) 운영 관점에서는 configuration 통합/관리 해야하는 문제가 발생합니다. 

여러분이 500개 이상의 쿠버네티스 클러스터를 운영하고 있는데 보안 정책을 바꾸고 싶다. 

그러면 500개의 클러스터를 어떻게 바꿔야 할까요?

그리고 바꾼다고 하더라도 500개 클러스터의 바뀐 변경 내용을 어떻게 추적할까요?

또 바뀐 정책은 어디다 저장할까요?

 

이런 것들을 관리해주는 것이 바로 설정 관리(configuration management)라고 합니다. 

 

2) 애플리케이션을 개발하게 되면 똑같은 애플리케이션을 인스톨 할 때 개발환경, 스테이지 환경, 운영환경에다 배포에 대한 이슈도 생기고 만약 글로벌 서비스를 하게 된다면 같은 애플리케이션을 미국, 유럽, 아시아에 각각 다시 배포해야합니다. 

 

그럼 배포를 어떻게 해야할까요?

기존에는 Ansible이나 Terraform 같은 툴을 사용하셨겠죠.

쿠버네티스는 같은 컨셉을 가지고 있는데, 인스톨 스크립트를 여러분의 패키지 인스톨러로 만들어서 이것을 등록할 수가 있습니다. 그리고 이것을 마켓플레이스(Marketplace)라고 합니다.

 

3) 로깅과 모니터링

로깅과 모니터링은 한군데에서 모아서 하기가 대단히 어렵습니다. 모니터링이나 로깅 시스템의 고질적인 문제를 해결하기 위해 여러가지 SaaS 서비스를 이용할 수 있지만 이는 대단히 비쌉니다. 그래서 구글은 스택 드라이버(Stackdriver) 같이 모니터링과 스택 로깅을 최적화할 수 있는 여러 방법을 제공하고 있습니다. 

 

4) 빌드와 배포 

마이크로 서비스는 하나의 큰 시스템이 작은 서비스 여러개로 구성이 되어있기 때문에 빌드도 많이 발생하게 됩니다. 그래서 마이크로 서비스에서는 빌드를 컨테이너 안에서 하게 됩니다. 빌드가 필요할 때마다 Jenkins 컨테이너함을 올리고 그 안에 빌드하고 끝나면 내립니다. 이런식으로 컨테이너나 클라우드 안에서 빌드할 수 있는 컨셉을 제공하고 있습니다. 구글에서 하게 되면 클라우드 빌드(Cloud Build)를 통해 모든 것을 자동화할 수 있다는 장점이 있습니다. 

 

 

 

3) Anthos의 쿠버네티스 개발자 경험 

이제 여러분은 쿠버네티스와 Anthos를 이용해 개발환경을 멀티 클라우드와 하이브리드 클라우드에서 다 만들었습니다.

하지만, 아직도 개발을 하지 못하는 일이 발생합니다. 아직도 복잡하기 때문입니다.

 

실제 컨테이너 기반 개발 프로세스

코딩한 다음 Maven으로 빌드하고 그 다음에 도커 컨테이너 빌딩합니다. 도커 컨테이너를 빌딩할 때 도커 컨테이너에 버전을 붙일 수 있습니다. 이것을 "태깅"이라고 하는데 태그 번호를 바꿔주지 않으면 쿠버네티스에서는 일반적으로 디폴트 설정으로 버전 넘버가 바뀌지 않으면 컨테이너 내용이 다르더라도 캐싱되어 있는 것을 사용합니다. 그래서 여러분이 코드를 바꿔서 컨테이너를 새로 빌딩했는데 바뀌지 않는다면 태깅을 업데이트하지 않아 캐싱되어 있는 내용을 사용하기 때문일 것입니다. 그래서 보통 컨테이너를 빌드할 때마다 태그 버전 넘버를 바꿔 줘야 합니다. 하지만, 태그 버전 넘버를 바꾸기 위해서는 YAML 파일도 바꿔줘야 합니다. 또한, Configuration 파일의 바뀐 컨테이너 버전도 바꿔줘야합니다. 그리고 테스트하고 디버깅하기 위해서는 컨테이너에서 돌아가는 쿠버네티스를 통해 로그를 보고 싶은데, 그러면 Pod에 접속해서 Pod에서 로그 테일링해서 봐야합니다. 

 

자, 이렇게 개발 프로세스가 복잡하기 그지 없습니다.

그래서 이런 복잡한 과정을 해결하기 위해 구글이 Skaffold라는 오픈소스를 가져왔습니다. 

 

로컬 pc에서 Skafflod를 기동시켜 놓으면, 그러면 이것이 이후 과정을 모두 다 처리해줍니다. Skaffold run 이라고 한 번 실행해주면 코드를 가지고 컨테이너 빌드, 레지스트리, configuration 변경, 그리고 끝나면 삭제까지 다 해줍니다. 

 

그런데 또 복잡한게 생깁니다. 컨테이너는 빌드할 때 계층적인 구조를 가집니다. 그래서 여러분들이 OS 깔고 Java 깔고 애플리케이션을 올리면 각각 다른 계층으로 들어가게 됩니다. 그래서 우리가 이 계층을 잘 나누게 되면 캐싱을 해서 배포 속도를 대단히 빠르게 할 수 있습니다. 

 

계층적인 구조를 가지는 컨테이너

나중에 쓰려고 카피하고 실행하면 각각의 다른 레이어로 생깁니다.

만약 상단의 레이어에서 JVM을 변경하지 않았다면 쿠버네티스 배포 될 때 쿠버네티스 엔진이 컨테이너 이미지 전체를 다운받지 않고, 바뀐 부분만 다운을 받습니다. 이런 사실을 바탕으로 애플리케이션 컨테이너를 깍기 시작합니다.

 

 자바 애플리케이션을 생각해보면 그 안에 여러가지 바이너리들이 존재하고 여러분의 코드는 별로 안되지만 그 안에 스프링이라던지, 기본 라이브러리가 되게 많습니다. 그러면 이것을 풀어서 레이어를 인위적으로 만들게 되면 대단히 짧게 배포할 수 있습니다.  그러나 실제로 해보려고 하면 한 번 해보고 안하게 됩니다. 되게 귀찮기 때문이죠. 

 

그래서 이를 위해 또 구글에서 Jib이라는 오픈소스를 내놨습니다. 위에서 설명한 과정을 모두 자동화해줍니다. 

 

 

자, 이 모든 과정을 다 하려니 또 복잡해서 IDE 툴에 다 넣어버렸습니다. 비쥬얼 스튜디오 코드와 인텔리 제이 안에 임베딩을 하게 만들었습니다. 그래서 최종적으로 여러분은 IDE 안에서 개발만 하면 됩니다. 개발 클러스터 만들어서 거기다가 배포하고 끝나면 클러스터를 날려버리기만 하면 됩니다.

 

모든 과정을 IDE 내부로 통합하였다

 

최종적으로 개발 환경에서 생각해야 할게 빌드 환경 등 여러가지가 있지만 빼먹지 말아야 하는 것이 바로 보안입니다. 

그럼 이제 보안은 어떻게 처리할까를 생각해보겠습니다.

 

구글 클라우드의 재밌는 점 중 하나는 여러분들이 컨테이너를 빌드한 다음에 저장한 Repository가 있습니다. 구글은 구글 컨테이너 레지스트리라는 데를 사용하는데 거기다 여러분이 컨테이너를 등록하게 되면 자동으로 보안 스캔이 일어납니다. 그래서 컨테이너 안에 있는 보안적인 취약점을 잡아서 자동으로 리포트를 해줍니다.  ( os에 대한 보안 스캐닝만 일어나는거지 상단의 애플리케이션에 대한 보안 스캐닝은 아니란 점을 주의하시기 바랍니다. ) 애플리케이션에 대한 보안 검사는 CI 단계에서 다시 하는 것이 좋습니다. 

 

 

도커 컨테이너 해킹 당하기 가장 쉬운 경로는 보통 스택 오버플로우를 통해서 하면 가장 쉽습니다. 스택 드라이버에서 필요한 컨테이너를 다운 받아서 사용하는데, 누가 만든건지도 모르고 사용하게 됩니다. 그러나, 도커 hub나 컨테이너 레지스트리에 의해 보면 certified 이미자라는게 있습니다. 즉 승인된 이미지라는 것인데 이런 이미지는 보안 스캔도 다 되어있고 최적화도 잘 되어 있습니다. 그러나 이런 승인된 이미지를 잘 안쓰는 문제가 있어서 운영팀 관점에서는 이것을 활성화할 수 있는 기능이 있으면 좋을 것 같습니다. 그리고 이게 바로 binary authorization이라는 기능입니다. 컨테이너를 만든 다음에 그 컨테이너에 특정 표시를 해줘서 검증 절차를 거치지 않은 컨테이너는 쿠버네티스 배포를 못하게 하는게 binary authorization의 기능입니다. 

 

보안 기능뿐 아니라 Stackdriver을 이용해 모니터링 기능도 강화하였습니다. 

Stackdriver 트레이싱 기능

스택드라이버에 트레이싱 기능이 있는데 집킨(Zipkin)이라는 오픈 소스를 이용해 마이크로 서비스 간의 각각 얼마나 걸렸는지 보여줍니다. 그리고 코드를 인젝션하게 되면 코드 내 메소드 수준까지 추적이 가능합니다. 전통적인 APM 툴과 비슷하다고 생각하시면 되는데 APM 툴의 경우 한 대의 서버 아래에서만 되는데 반해 이것은 마이크로 서비스 간의 분석도 가능합니다. 또한 집킨은 오픈소스 커뮤니티 스팩을 따르기 때문에 다른 클라우드를 간다 하시더라도 집킨에 호환되는 백엔드만 있게 되면 그대로 이 기능을 사용할 수 있는 장점도 가지고 있습니다.

 

다음으로는 로깅 에러 리포팅에 대한 기능도 있습니다. 여러분들이 별도 설정 없이 스택 드라이버 로깅으로 로그만 저장하게 되면 에러 로그를 별도로 뽑아주는 기능을 제공합니다. 그래서 각각의 에러에 대한 트렌드를 보여주고 지라(Jira)나 버그 트래킹 시스템과 연결도 할 수 있습니다. 

 

클라우드 코드를 통한 개발 환경 그리고 CI/CD 빌드에서 보안 검사, 그리고 통합된 스택 드라이버를 이용한 로깅과 모니터링, 마지막으로 개발 클러스터로 여러분들이 직접 만들어서 운영할 수 있는 것을 통해 전체적인 개발 사이클을 만들어 줄 수 있는 장점을 가지고 있습니다. 

 

마지막으로, 모든 서비스를 통합해야 이런 사이클을 운용할 수 있습니다. 

그러나 통합은 API key 인증이나 네트워크 인증, IP 대역을 맞춰주는 복잡한 이슈들이 발생하는데 구글 클라우드를 사용하게 되면 이게 모두 자동으로 다 연결되게 됩니다. 인증 도커 같은 것도 자동으로 넣을 수 있는 기능이 있고 IP 대역도 맞춰주는 기능이 내재되어 있습니다.  그리고 구글 클라우드 내에 없는 부분(예를 들어 MongoDB, ElasticSearch)은 GCP Marketplace에서 찾아서 설치하시면 됩니다. 설치를 하게 되면 그 제품의 사이트가 아닌 구글 클라우드 콘솔 안에 들어가게 되며 과금도 구글 클라우드를 통해서 통합 과금됩니다. 서포트도 구글 클라우드 서포트 채널을 통해 기술 지원을 받게 됩니다.

ㅏ