The Required Standard
(필수 표준)

사례를 통해 작업하고 trade-pffs(장단점)에 대해서 생각할 때, 발견해야할 핵심 균형 중 하나는 시스템에 얼마나 많은 가변성을 허용할 것인가입니다. 서비스에서 서비스까지 일정해야 하는 것이 무엇인지를 식별하는 핵심 방법 중 하나는 잘 동작하고, 좋은 서비스가 어떻게 보일지를 정의하는 것입니다.

시스템에서 "훌륭한 시민" 서비스는 무엇일까요?

시스템이 관리 가능하고, 하나의 나쁜 서비스가 전체 시스템을 중단시키지 않도록 하기 위해 필요한 기능은 무엇입니까?

그리고 사람들과 마찬가지로, 하나의 맥락에서 훌륭한 시민이 다른 곳에서 좋게 보이는 것이 무엇인지를 반영하지는 않습니다.

그럼에도 불구하고, 잘 동작하는 서비스는 관찰하는 것이 매우 중요하다고 생각하는 공통적인 특징을 가지고 있습니다.
이것은 너무 많은 발산을 허용하게 되면, 꽤나 심각한 시간을 야기시킬 수 있는 몇 안 되는 주요 핵심 영역입니다.

Netflix의 Ben Christensen은 더 큰 그림을 생각할 때, "자율적인 수명주기(lifecycle)을 가지고 있지만, 모든 것이 함께 잘 어울리는  많은 작은 부분으로 이루어진 응집력 있는 시스템이 되어야 한다"고 말했습니다.

따라서, 큰 크림에 대한 시각을 잃어버리지 않고, 개별적인 마이크로서비스의 자율성을 최적화하는 것의 균형을 찾아야만 합니다.

각 서비스가 가져야 하는 명확한 속성(attribute)을 정의하는 것은 균형이 어디에 있는지를 분명하게 하는 한 가지 방법입니다.

Monitoring
(모니터링)

시스템의 건강에 대한일관성 있는 서비스 전반에 걸친 뷰(Cross-Service View)를 작성할 수 있어야 합니다.

이것은 서비스별 관점이 아닌, 시스템 전체적인 관점이어야 합니다.
8장에서 논의하겠지만, 개별 서비스의 상태를 아는 것은 유용하지만, 종종 더 낣은 문제를 진단하거나 더 커다란 트렌드를 이해하려고 하는 경우에만 유용합니다.

가능한 한 이것을 쉽게 하기 위해서 모든 서비스가 동일한 방식으로 상태(health)와 일반적인 모니터링 관련 메트릭을 내보내도록 하는 것이 좋습니다.

각 서비스가 중앙 위치로 이러한 데이터를 Push해야 하는 Push 메커니즘을 채택할 수 있습니다.
메트릭의 경우에는 Graphite를, Health를 위해서는 Nagios를 사용할 수 있습니다.

또는 노드 자체에서 데이터를 긁어서 보내는(Scrape) 폴링 시스템(Polling System)을 사용하도록 결정할 수도 있습니다.

박스 내부를 불투명하게 하고, 모니터링 시스템이 그것을 지원하기 위해 변경되지 않도록 하십시오.
로깅(logging)도 같은 범주에 속합니다. 모두 한 곳에서 필요합니다.

Interfaces
(인터페이스)

작은 수의 정의된 인터페이스 기술을 도입하는 것은 새로운 인터페이스 호출 서비스(Consumer)를 통합하는데 도움이 됩니다.
하나의 표준을 가지는 것이 좋습니다. 2개도 나쁘지 않습니다.
20개의 다른 스타일의 통합은 나쁩니다.

이것은 단지 기술과 프로토콜 선택에 대한 것이 아닙니다.

예를 들면, 만약 HTTP/REST를 선택한다면, 동사나 명사를 사용합니까?
자원에 대한 페이지화(pagenation)는 어떻게 처리합니까?
End-point의 버전관리는 어떻게 하나요?

Architectural Safety
(아키텍처적인 안전성)

나쁘게 동작하는 하나의 서비스가 파티의 모든 사람에게 손해를 끼치게 할 수 없습니다.

우리는 우리 서비스가 건강하지 않은(unhealthy) 다운스트림 호출(downstream call:외부에서 내려오는 호출)로부터 스스로를 보호할 수 있도록 보장해야 합니다.
다운스트림 호출의 잠재적인 실패를 적절하게 처리하지 못하는 서비스가 더 많을 수록, 시스템은 더 취약해질 것입니다.

적어도 각 다운스트림 서비스가 자체 Connection Pool을 가지도록 요구하고, 또한, 각 서비스가 Circuit Breaker를 사용하도록 말할 수 있을지도 모릅니다.

11장에서 마이크로서비스 확장(Microservices at scale)에 대해서 논의할 때, 더 깊이 있게 다룰 것입니다.

응답 코드에 대해서도 또한 규칙을 적용하는 것이 중요합니다.
만약 Circuit Breaker가 HTTP 코드를 사용하고, 하나의 서비스가 에러에 대해서 2XX 코드를 보내거나 4XX 코드를 5XX 코드로 혼동하여 보내는 경우에는 이러한 안전 조치가 분리될 수 있습니다.

유사한 문제가 HTTP를 사용하지 않는 경우에도 발생할 수 있습니다.
OK 및 올바르게 처리된 요청과 나쁘고 서비스가 수행되지 못하게 하는 요청, OK이지만 서버가 다운되어 확인할 수 없는 요청 사이의 차이를 아는 것은 빠르게 실패하고 이슈를 추적할 수 있는 것을 보장하는 핵심입니다.

만약 우리 서비스가 이러한 규칙에 대해 불성실하게 되면, 결국 더 취약한 시스템을 가지게 됩니다.
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/814

트랙백 주소 :: http://www.yongbi.net/trackback/814

트랙백 RSS :: http://www.yongbi.net/rss/trackback/814

댓글을 달아 주세요

댓글 RSS 주소 : http://www.yongbi.net/rss/comment/814
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다