Governance Through Code
(코드를 통한 거버넌스)
함께 모여서 어떻게 일을 할지에 대해서 동의하는 것은 좋은 아이디어입니다.
그러나 사람들이 이러한 가이드라인을 따르도록 하는데 시간을 낭비하는 것은 각 서비스에서 기대하는 모든 이러한 표준들을 구현하는 것이 개발자들에게는 부담이 되므로 더 재미가 없습니다.
나는 올바른 일을 더 쉽게 하도록 하는 위대한 신봉자입니다.
내가 여기서 잘 보여주는 2가지 기법은 예제를 사용하고, 서비스 템플릿을 제공하는 것입니다.
Exemplars
(예제)
문서화를 하는 것은 좋고, 유용합니다.
그 가치를 분명하게 보았고, 결국 나는 이 책을 쓰게 되었습니다.
그러나 개발자는 코드, 즉 실행할 수 있고, 탐구할 수 있는 코드를 좋아합니다.
만약 여러분이 장려하고 싶은 표준이나 모범 사례(Best Practice)를 가지고 있다면, 사람들에게 가리킬 수 있는 예제를 갖고 있는 것이 유용합니다.
아이디어는 사람들이 시스템의 더 좋은 부분의 일부를 모방하는 것만으로는 잘못될 수 없다는 것입니다.
이상적으로는, 방금 구현된 격리된 서비스(isolated service)가 아니라 완벽한 예제가 되도록 올바르게 동작하는 실제 서비스(real-world service)를 제공해야만 합니다.
예제가 실제로 사용되고 있음을 보장함으로써, 모든 원칙들이 실제로 의미가 있음을 보장할 수 있습니다.
Tailored Service Template
(맞춤형 서비스 템플릿)
여러분이 매우 적은 업무로 가지고 있는 대부분의 가이드라인을 따르는 것이 모든 개발자가 정말로 쉽게 일하게 할 수 있는 것이라면, 대단하지 않을까요?
만약, 특별히, 개발자들이 각 서비스에서 필요로 하는 핵심 속성들을 구현할 수 있는 대부분의 코드를 가지고 있다면 어떨까요?
Dropwizard와 Karyon은 2개의 JVM 기반 마이크로 컨테이너 오픈소스입니다.
그것들은 Health-Checking, HTTP 제공, 메트릭 노출과 같은 기능을 제공하는 라이브러리 세트를 함께 사용하여 유사한 방식으로 동작합니다.
따라서, 특별히, 명령줄(command line)에서 실행될 수 있는 임베디드 서블릿 컨테이너(embeded servlet container)를 가진 완전한 서비스를 제공할 수 있습니다.
이것은 시작하기 좋은 방법이지만, 거기서 멈추는 이유는 무엇일까요?
하는 김에(while we are at it), 왜 Dropwizard나 Karyon과 같은 어떤 것을 사용하지 않을까요?
그리고 왜 맥락(context)에 적합해지도록 더 많은 기능을 추가하지 않을까요?
예를 들면, Circuit breaker를 필수적으로 사용하도록 할 수 있습니다.
이 경우, Hystrix와 같은 Circuit Breaker 라이브러리를 통합할 수 있습니다.
또는 모든 메트릭을 중앙의 Graphite 서버로 보내야 할 수도 있기 때문에 Dropwizard 메트릭과 같은 오픈소스 라이브러리를 가져와서 설정하여 알려진 위치로 응답 시간과 오류율(error rate)을 자동으로 Push할 수 있습니다.
자신만의 개발 사례 세트에 대한 그러한 맞춤형 서비스 템플릿으로 인해 팀이 더 빠르게 시작할 수 있고, 또한 개발자들이 서비스가 안 좋게 동작하도록 하는 방법에서 떠나도록 할 수 있습니다.
물론, 만약 다른 여러 가지 기술 스택을 포용한다면, 각각의 경우에 맞는 서비스 템플릿이 필요합니다.
이것은 미묘하게도 여러분의 팀에서 언어 선택 제약 사항이 될지도 모릅니다.
만약, 사내(in-house) 서비스 템플릿이 단지 자바만 지원한다면, 사람들은 대체 스택을 선택하면 많은 일을 해야만 하는 경우, 대체 스택을 선택하는 것에 대해서 낙심하게 될지도 모릅니다.
예를 들어, Netflix는 시스템의 한 부분의 작동 중지로 모든 것이 다운되지 않을 수 있도록 보장하기 위해서 내결함성(fault tolerance)와 같은 측면에 특히 관심을 가지고 있습니다.
이것을 처리하기 위해서, JVM 클라이언트 라이브러리가 있는 팀에 서비스가 잘 동작하도록 유지하는데 필요한 도구를 제공하기 위해 엄청난 노력을 하고 있습니다.
새로운 기술 스택을 소개받은 사람은 누구나 이 모든 노력을 재현해야함을 의미합니다.
Netflix의 주요 관심사는 중복된 노력을 덜하는 것보다 잘못되는 것이 너무 쉽다는 사실에 있습니다.
새롭게 구현된 내결함성(fault tolerance) 오류를 가진 서비스의 위험은 그 서비스가 시스템에 더 많은 영향을 줄 수 있을 때 높습니다.
Netflix는 적절한 라이브러리를 사용하는 JVM과 로컬로 통신하는 사이드카 서비스(sidecar service : 효력을 정지하는 서비스)를 사용하여 이 위험을 완화합니다.
여러분은 서비스 템플릿의 생성이 코드를 통해 일을 해야만 하는 방법을 지시하는 중앙 도구나 아키텍처 팀의 일이 되지 않도록 주의를 기울여야 합니다.
여러분이 사용하는 사례를 정의하는 것은 집합적인 활동이어야 합니다. 따라서, 이상적으로는 여러분의 팀이 이 템플릿을 업데이트하는 책임을 져야 합니다. (내부 오픈소스 접근 방식이 여기에서는 적합함).
또한, 그들이 신뢰하는 필수적인 프레임워크로 인해 많은 팀의 사기와 생산성이 파괴된 것을 보았습니다.
코드 재사용성을 향상시키기 위해서, 압도적인 괴물이 될 때까지 점점 더 많은 작업이 중앙집중화된 프레임워크에 위치하게 됩니다.
만약 여러분이 맞춤형 서비스 템플릿을 사용하기로 결정한다면, 그 일이 무엇인지에 대해서 매우 주의깊게 생각하십시오.
이상적으로, 그 템플릿의 사용은 순전히 선택적이어야 하지만, 만약 여러분이 그것의 취사 선택에서 더 강력하게 되는 경우, 개발자들을 위한 사용 용이성이 주요한 안내력(guiding force)이 되어야 한다는 것을 이해해야만 합니다.
또한, 코드 공유의 위험에 대해서 알고 있어야만 합니다.
재사용 가능한 코드를 만들기 위한 우리의 욕망으로 인해 서비스간 커플링 소스(밀접하게 엮여 있는 소스)를 만들 수 있습니다.
최소한 내가 말했던 조직 중 하나는 실제로 각 서비스에 수동으로 서비스 템플릿 코드를 복사하는 것에 대해 걱정하고 있습니다.
핵심 서비스 템플릿으로 업그레이드하는 것이 시스템 전반에 걸쳐 적용되는데 더 오래 걸리지만, 커플링 위험보다 덜 중요하다는 것을 의미합니다.
내가 말한 다른 팀들은 지나치게 결합된 시스템에서 DRY(스스로 반복하지 않음 : don't repeat yourself) 결과에 대한 경향이 되지 않도록 매우 부지런해야함에도 불구하고, 서비스 템플릿을 공유 바이너리 종속성(shared binary dependency)처럼 간단하게 취급합니다.
(DRY 결과로 인한 경향이 지나치게 결합된 시스템이 되지 않도록 매우 부지런해야함에도 불구하고, 단순히 서비스 템플릿을 공유 바이너리 종속성으로 취급합니다.)
이것은 미묘한 주제이므로, 4장에서 더 자세히 살펴보겠습니다.
댓글을 달아 주세요
댓글 RSS 주소 : http://www.yongbi.net/rss/comment/817