서비스 메시 사용 시나리오

메모. 번역: 이 기사의 저자(Luc Perkins)는 Linkerd, SMI(Service Mesh Interface), Kuma와 같은 오픈 소스 프로젝트의 본거지인 CNCF의 개발자 옹호자입니다. (그런데 Istio가 이 목록에 없는 이유가 궁금했던 적 있나요?) "서비스 메시"라는 유행어를 DevOps 커뮤니티에서 더 잘 이해하도록 하기 위한 또 다른 시도로, 그는 이러한 솔루션이 제공하는 16가지 일반적인 기능을 나열했습니다.

오늘 서비스 메시 ― 소프트웨어 엔지니어링 분야에서 가장 인기 있는 주제 중 하나입니다(물론 그럴 만한 이유도 있겠죠!). 저는 이 기술이 엄청나게 유망하다고 생각하고, (물론 합리적으로 받아들여질 때) 널리 채택되는 것을 보고 싶습니다. 하지만 대부분의 사람들에게는 여전히 신비로운 분위기에 둘러싸여 있습니다. 게다가, 심지어는 나는 그를 잘 알고 있다 그것을 사용하면 종종 그것의 장점이나 그것이 정확히 무엇인지 설명하는 데 어려움을 겪습니다(귀하의 겸손한 하인을 포함하여). 이 기사에서는 다양한 사항을 나열하여 상황을 바로잡으려고 노력할 것입니다. 사용 시나리오 "서비스 그리드"*.

* 참고: 번역: 이 문서부터 이 번역("서비스 메시")은 아직 새로운 용어인 서비스 메시를 대신하여 사용됩니다.

하지만 먼저 몇 가지 의견을 밝히고 싶습니다.

• 저는 서비스 메시를 사용해 본 적도 없고, 제 교육을 위해 진행한 프로젝트 외에는 서비스 메시를 사용해 본 적도 없습니다. 반면에 저는 2015년에 Twitter의 내부 서비스 메시에 대한 많은 문서를 작성했습니다(그때는 "서비스 메시"라고 불리지도 않았습니다) 그리고 웹사이트와 문서에 기여했습니다. 링커드, 그러니까 뭔가 의미가 있는 거죠.
• 제가 작성한 목록은 대략적이고 불완전합니다. 물론 제가 모르는 사용 사례도 있을 것이고, 기술이 발전하고 더 대중화됨에 따라 시간이 지나면서 새로운 사례가 나타날 가능성이 큽니다.
• 동시에, 기존의 모든 서비스 메시 구현이 나열된 모든 사용 사례를 지원하는 것은 아닙니다. 따라서 "서비스 메시는..."이라는 제 진술은 "일부, 그리고 아마도 모든 인기 있는 서비스 메시 구현은..."으로 읽어야 합니다.
• 예시의 순서는 중요하지 않습니다.

짧은 목록:

• 서비스 발견
• 암호화;
• 인증 및 권한 부여
• 부하 분산
• 회로 차단;
• 자동 확장
• 카나리아 배포
• 청록색 배포
• 건강 검진;
• 부하 분산
• 트래픽 미러링
• 단열재;
• 요청 속도 제한, 재시도 및 시간 초과
• 원격 측정;
• 심사;
• 심상.

1. 서비스 발견

요약: 간단한 이름을 사용하여 네트워크의 다른 서비스에 연결합니다.

서비스는 다음과 같은 적절한 이름을 사용하여 서로를 자동으로 "찾을" 수 있어야 합니다. service.api.production, pets/staging 또는 cassandra. 클라우드 환경은 탄력적이며, 여러 서비스 인스턴스를 하나의 이름 뒤에 숨길 수 있습니다. 이런 상황에서는 모든 IP 주소를 하드코딩하는 것이 물리적으로 불가능하다는 것은 분명합니다.

또한, 한 서비스가 다른 서비스를 찾으면 죽은 인스턴스의 입력으로 요청이 전달될까봐 걱정하지 않고 해당 서비스에 요청을 보낼 수 있어야 합니다. 즉, 서비스 메시는 모든 서비스 인스턴스의 상태를 모니터링하고 호스트 목록을 최대한 최신 상태로 유지해야 합니다.

각 서비스 메시는 서비스 검색 메커니즘을 다르게 구현합니다. 현재 가장 일반적인 방법은 DNS Kubernetes와 같은 외부 프로세스에 위임하는 것입니다. 과거에는 트위터에서 이 목적을 위해 이름 시스템을 사용했습니다. 속이다. 또한 서비스 메시 기술을 사용하면 사용자 정의 명명 메커니즘을 도입할 수 있습니다(하지만 아직 이러한 기능을 갖춘 SM 구현을 본 적은 없습니다).

2. 암호화

요약: 서비스 간의 암호화되지 않은 트래픽을 없애고 이 프로세스를 자동화하고 확장 가능하게 만드세요.

공격자가 내부 네트워크에 침투할 수 없다는 사실을 아는 게 좋습니다. 방화벽은 이런 일을 매우 잘 수행합니다. 하지만 해커가 침입하면 어떻게 되나요? 그는 서비스 내 교통 상황을 원하는 대로 처리할 수 있을까? 이런 일이 일어나지 않기를 바랍니다. 이러한 시나리오를 방지하려면 모든 서비스 간 트래픽을 암호화하는 제로 트러스트 네트워크를 구현해야 합니다. 대부분의 현대 서비스 그리드는 상호 연결을 통해 이를 달성합니다. TLS (상호 TLS, mTLS). 어떤 경우에는 mTLS가 전체 클라우드와 클러스터에서 작동합니다(저는 행성 간 통신이 언젠가는 비슷한 방식으로 이루어질 것이라고 생각합니다).

물론 mTLS 서비스 메시의 경우 선택 과목. 각 서비스는 자체 TLS를 처리할 수 있지만, 이는 인증서를 생성하고 이를 서비스 호스트 전반에 배포하고 파일에서 이러한 인증서를 로드하는 애플리케이션에 코드를 포함하는 방법을 찾아야 함을 의미합니다. 네, 정기적으로 인증서를 갱신하는 것을 잊지 마세요. 서비스 메시는 다음과 같은 시스템으로 mTLS를 자동화합니다. 스피페이를 통해 인증서 발급 및 교체 프로세스가 자동화됩니다.

3. 인증 및 권한 부여

요약: 요청을 시작한 사람이 누구인지 확인하고 요청이 서비스에 도달하기 전에 해당 사람이 무엇을 할 수 있는지 확인하세요.

서비스에서는 종종 다음을 알고 싶어합니다. 누구 요청(인증)을 하고 이 정보를 사용하여 결정합니다. 그 이 주체는 (권한 부여)를 할 수 있다. 이 경우 대명사 "who"는 다음을 숨길 수 있습니다.

1. 기타 서비스. 이것을 "인증"이라고 합니다 피어라". 예를 들어, 서비스 web 서비스에 접속하고 싶어합니다 db. 서비스 메시는 일반적으로 인증서를 필수 식별자로 사용하여 mTLS를 사용하여 이러한 유형의 문제를 해결합니다.
2. 일부 인간 사용자. 이것을 "인증"이라고 합니다 요청". 예를 들어, 사용자 haxor69 새로운 램프를 사고 싶어해요. 서비스 메시는 다음과 같은 다양한 메커니즘을 제공합니다. JSON 웹 토큰.

   우리 중 많은 사람이 애플리케이션 코드에서 이런 작업을 해야 했습니다. 요청이 들어오면 우리는 테이블을 살펴봅니다. users, 사용자를 찾아 비밀번호를 비교한 후 열을 확인합니다. permissions 서비스 메시의 경우, 이 작업은 요청이 서비스에 도달하기도 전에 발생합니다.

요청이 누구에게서 왔는지 확인한 후에는 해당 주체가 무엇을 할 수 있는지 결정해야 합니다. 일부 서비스 메시에서는 YAML 파일이나 명령줄에서 누가 무엇을 할 수 있는지에 대한 기본 정책을 설정할 수 있고, 다른 서비스 메시에서는 다음과 같은 프레임워크와의 통합을 제공합니다. 정책 에이전트 열기. 최종 목표는 귀하의 서비스가 신뢰할 수 있는 출처에서 온 것이라는 확신을 가지고 모든 요청을 수락하는 것입니다. и 이 작업은 허용됩니다.

4. 부하 분산

요약: 특정 패턴에 따라 서비스 인스턴스 전반에 부하를 분산합니다.

서비스 섹션의 "서비스"는 종종 여러 개의 동일한 사본으로 구성됩니다. 예를 들어, 오늘의 서비스 cache 5부로 구성되어 있으며 내일은 11부로 늘어날 수 있습니다. 요청은 다음으로 전송됩니다. cache, 특정 목적에 맞게 분배되어야 합니다. 예를 들어, 지연 시간을 최소화하거나 작동하는 인스턴스에 도달할 확률을 최대화합니다. 가장 일반적으로 사용되는 알고리즘은 라운드 로빈 알고리즘이지만, 가중치 방식 등 다른 알고리즘도 많이 있습니다. (가중치) 질의(선호하는 대상을 선택할 수 있음), 링 (반지) 해싱(상류 호스트에 대해 일관된 해싱 사용) 또는 최소 쿼리 방식(쿼리가 가장 적은 인스턴스가 우선적으로 제공됨).

클래식 로드 밸런서는 HTTP 캐싱 및 DDoS 보호와 같은 다른 기능을 갖추고 있지만, 이러한 기능은 동서 트래픽(서비스 메시의 일반적인 적용 분야)에는 그다지 적합하지 않습니다. 부하 분산을 위해 서비스 메시를 반드시 사용할 필요는 없지만, 서비스 메시를 사용하면 중앙 제어 평면에서 각 서비스에 대한 부하 분산 정책을 정의하고 제어할 수 있으므로 네트워크 스택에서 개별 부하 분산 장치를 실행하고 구성할 필요가 없습니다.

5. 회로 차단

요약: 문제가 있는 서비스로의 트래픽을 차단하고 최악의 경우 피해를 통제합니다.

어떤 이유로 서비스가 트래픽을 처리할 수 없는 경우, 서비스 메시는 이 문제를 해결하기 위한 여러 가지 옵션을 제공합니다(다른 옵션은 관련 섹션에서 설명합니다). 회로 차단은 트래픽에서 서비스를 분리하는 가장 심각한 옵션입니다. 하지만 그 자체로는 아무런 의미가 없습니다. 대체 계획이 필요합니다. 역압이 제공될 수 있습니다. (배압) 요청을 하는 서비스에(이를 위해 서비스 메시를 설정하는 것을 잊지 마세요!), 또는 예를 들어 상태 페이지를 빨간색으로 칠하고 "떨어지는 고래"("Twitter is down")가 있는 페이지의 다음 버전으로 사용자를 리디렉션하는 것.

서비스 그리드를 사용하면 다음을 결정할 수 있습니다. 언제 종료가 뒤따를 것입니다 그 이것이 뒤따를 것이다. 이 경우, "언제"에는 지정된 매개변수의 조합이 포함될 수 있습니다. 즉, 특정 기간 동안의 총 요청 수, 병렬 연결 수, 보류 중인 요청 수, 활성 재시도 수 등이 포함될 수 있습니다.

회로 차단 기능을 과도하게 사용하고 싶지는 않겠지만, 비상 상황에 대비해 대체 계획이 있다는 것을 아는 게 좋습니다.

6. 자동 확장

요약: 지정된 기준에 따라 서비스 인스턴스 수를 늘리거나 줄입니다.

서비스 메시는 스케줄러가 아니므로 수행하다 독립적으로 확장 가능. 하지만 이들은 어떤 기획자가 결정을 내릴 수 있는지에 대한 정보를 제공할 수 있습니다. 서비스 메시는 서비스 간의 모든 트래픽에 접근할 수 있으므로 어떤 일이 일어나고 있는지에 대한 광범위한 정보를 얻을 수 있습니다. 즉, 어떤 서비스에 문제가 있는지, 어떤 서비스에 활용도가 낮는지(할당된 용량이 낭비되고 있는지) 등을 알 수 있습니다.

예를 들어, 쿠버네티스는 포드의 CPU 및 메모리 사용량에 따라 서비스를 확장합니다. (보고서를 참조하세요.Kubernetes의 자동 크기 조정 및 리소스 관리" - 약. 번역)하지만 다른 지표(이 경우 트래픽 관련 지표)를 기준으로 확장하기로 결정한 경우 전담 지표가 필요합니다. 관리 이런 것 이것을 하는 방법을 보여줍니다 사절, 이스 티오 и 프로 메테우스하지만 그 과정 자체는 매우 복잡합니다. 우리는 서비스 메시를 통해 "서비스 인스턴스 수 증가"와 같은 조건을 간단히 지정할 수 있도록 하여 이를 단순화하고 싶습니다. auth, 실행을 기다리는 요청 수가 1분 동안 임계값을 초과하는 경우."

7. 카나리아 배포

요약: 일부 사용자를 대상으로 서비스의 새로운 기능이나 버전을 테스트합니다.

예를 들어, SaaS 제품을 개발 중이고 해당 제품의 멋진 새 버전을 출시할 계획이라고 가정해 보겠습니다. 스테이징에서 테스트해보니 잘 작동했습니다. 하지만 실제 생활에서의 행동에 대해서는 여전히 몇 가지 우려가 있습니다. 다시 말해, 사용자의 신뢰를 위험에 빠뜨리지 않고 실제 작업에서 새로운 버전을 테스트하는 것이 필요합니다. 이런 경우에는 카나리아 배포가 적합합니다. 이를 통해 일부 사용자에게 새로운 기능을 보여줄 수 있습니다. 이 하위 집합은 가장 충성도 높은 사용자, 제품의 무료 버전을 사용하는 사용자, 또는 "실험 대상"이 되기로 자원한 사용자로 구성될 수 있습니다.

서비스 메시를 사용하면 애플리케이션의 어떤 버전을 누가 볼 수 있는지 결정하는 기준을 지정하고, 이에 따라 트래픽을 라우팅할 수 있습니다. 하지만 서비스 자체에는 아무것도 변하지 않습니다. 서비스 버전 1.0에서는 모든 요청이 해당 서비스를 봐야 할 사용자에게서 온다고 가정하고, 버전 1.1에서는 해당 서비스를 봐야 할 사용자에게서 온다고 가정합니다. 그동안 기존 버전과 신규 버전 간의 트래픽 비율을 변경하여, 안정적으로 작동하고 실험 대상이 승인을 내리면 점점 더 많은 사용자를 신규 버전으로 리디렉션할 수 있습니다.

8. 블루-그린 배포

요약: 멋진 새 기능을 출시하되, 즉시 되돌릴 준비를 하세요.

의미 블루-그린 배포 기존의 "그린" 서비스와 병행하여 새로운 "블루" 서비스를 출시하는 것입니다. 모든 것이 순조롭게 진행되고 새로운 서비스가 효과가 입증되면 기존 서비스를 점차적으로 종료할 수 있습니다. (아쉽게도 언젠가 이 새로운 "블루" 서비스도 "그린" 서비스의 운명을 따라 사라질 것입니다...) 블루-그린 배포는 새로운 기능이 다음을 포함한다는 점에서 카나리아 배포와 다릅니다. 한꺼번에 사용자(부분이 아님) 여기서 중요한 점은 무슨 일이 잘못될 경우를 대비해 "백업 피난처"를 준비해 두는 것입니다.

서비스 메시는 "블루" 서비스를 테스트하고 문제가 발생할 경우 작동하는 "그린" 서비스로 즉시 전환하는 매우 편리한 방법을 제공합니다. 또한 "파란색" 장치의 작동에 대한 많은 정보(아래의 "원격 측정" 섹션 참조)를 제공하여 장치가 완전한 작동을 할 준비가 되었는지 파악하는 데 도움이 됩니다.

메모. 번역: Kubernetes의 다양한 배포 전략(언급된 Canary, Blue/Green 및 기타 포함)에 대해 자세히 알아보려면 여기를 클릭하세요. 이 기사.

9. 건강검진

요약: 어떤 서비스 인스턴스가 정상인지 모니터링하고, 더 이상 정상적이지 않은 인스턴스에 대응합니다.

건강 체크 (건강검진) 서비스 인스턴스가 트래픽을 수신하고 처리할 준비가 되었는지 여부를 결정하는 데 도움이 됩니다. 예를 들어, HTTP 서비스의 경우 상태 검사는 엔드포인트에 대한 GET 요청처럼 보일 수 있습니다. /health. 답변 200 OK 인스턴스가 정상임을 의미하고, 그렇지 않으면 트래픽을 수신할 준비가 되지 않았음을 의미합니다. 서비스 메시를 사용하면 상태 검사를 수행하는 방법과 수행 빈도를 모두 지정할 수 있습니다. 이 정보는 부하 분산 및 회로 차단과 같은 다른 목적으로 사용될 수 있습니다.

따라서 건강 검진은 단독으로 사용되는 사례가 아니며, 일반적으로 다른 목표를 달성하는 데 사용됩니다. 또한, 상태 점검 결과에 따라 다른 서비스 메시 대상과 관련된 외부 작업이 필요할 수 있습니다. 예를 들어, 상태 페이지를 업데이트하거나, GitHub에서 이슈를 생성하거나, JIRA 티켓을 작성하는 것입니다. 서비스 메시는 이 모든 것을 자동화하는 편리한 메커니즘을 제공합니다.

10. 부하 분산

요약: 사용량이 일시적으로 급증하면 트래픽 경로를 변경합니다.

서비스가 트래픽으로 과부하된 경우 해당 트래픽 중 일부를 일시적으로 다른 위치로 리디렉션할 수 있습니다(예: "drop" 또는 "pour"). (창고) (그가 거기에 있었음). 예를 들어, 백업 서비스나 데이터 센터, 또는 영구적인 데이터 센터에 저장하는 것입니다. 프레스 주제. 결과적으로 서비스는 모든 요청을 처리하는 것이 중단되거나 중단되는 대신 일부 요청을 계속 처리할 수 있게 됩니다. 부하 분산은 회로를 차단하는 것보다 바람직하지만, 과도하게 사용하는 것은 여전히 ​​권장되지 않습니다. 다운스트림 서비스의 충돌을 일으킬 수 있는 연쇄적 오류를 방지하는 데 도움이 됩니다.

11. 트래픽 병렬화/미러링

요약: 한 번에 여러 곳으로 요청을 보냅니다.

때로는 여러 서비스에 한 번에 요청(또는 여러 요청 선택)을 보내야 할 때가 있습니다. 대표적인 예로는 프로덕션 트래픽의 일부를 스테이징 서비스로 전송하는 것이 있습니다. 메인 프로덕션 웹 서버는 다운스트림 서비스에 요청을 보냅니다. products.production 그리고 오직 그에게만. 그리고 서비스 메시는 이 요청을 지능적으로 복사하여 전송합니다. products.staging웹 서버도 전혀 알지 못하는 사실이죠.

트래픽 병렬화 위에 구현할 수 있는 서비스 메시에 대한 또 다른 관련 사용 사례는 다음과 같습니다. 회귀 테스트. 이는 동일한 요청을 다양한 버전의 서비스에 보내고 모든 버전이 동일하게 동작하는지 확인하는 것을 포함합니다. 나는 아직 다음과 같은 통합 회귀 테스트 시스템을 갖춘 서비스 메시 구현을 접하지 못했습니다. 디피하지만 아이디어 자체는 유망해 보입니다.

12. 단열재

요약: 서비스 메시를 미니 네트워크로 나누세요.

또한 ~로 알려짐 분할격리란 서비스 메시를 서로에 대해 아무것도 모르는 논리적으로 분리된 세그먼트로 나누는 기술입니다. 격리는 가상 사설망을 만드는 것과 비슷합니다. 가장 큰 차이점은 서비스 메시의 모든 이점(서비스 검색 등)을 여전히 누릴 수 있고, 여기에 보안이 강화되었다는 점입니다. 예를 들어, 공격자가 서브넷 중 하나의 서비스에 침투하는 데 성공하더라도 다른 서브넷에서 실행 중인 서비스를 볼 수 없고 해당 서비스의 트래픽을 가로챌 수도 없습니다.

또한, 이러한 혜택은 조직적인 측면도 있을 수 있습니다. 회사 구조에 따라 서비스를 서브넷으로 나누고 개발자가 전체 서비스 메시를 염두에 두어야 하는 인지적 부담을 덜 수 있도록 하는 것이 좋습니다.

13. 요청 속도 제한, 재시도 및 시간 초과

요약: 더 이상 시간이 많이 걸리는 요청 관리 작업을 코드베이스에 포함할 필요가 없습니다.

이러한 모든 사항은 별도의 사용 사례로 간주될 수 있지만, 한 가지 공통적인 특징 때문에 이를 그룹화하기로 결정했습니다. 이는 일반적으로 애플리케이션 라이브러리에서 처리하는 요청 수명 주기 관리 작업의 부담을 덜어준다는 것입니다. 백엔드 서비스에 요청을 보내는 Ruby on Rails 웹 서버(서비스 메시와 통합되지 않음)를 개발하는 경우 gRPC, N개의 요청이 실패하면 애플리케이션은 스스로 무엇을 할지 결정해야 합니다. 또한 이러한 서비스가 처리할 수 있는 트래픽 볼륨을 파악하고 특수 라이브러리를 사용하여 이러한 매개변수를 하드코딩해야 합니다. 게다가 앱은 언제 포기하고 요청을 낭비할지(시간 초과) 결정해야 합니다. 위의 매개변수를 변경하려면 웹 서버를 중지하고, 재구성한 후 다시 시작해야 합니다.

이러한 문제를 서비스 메시에 위임하면 서비스 개발자가 이에 대해 생각할 필요가 없을 뿐만 아니라, 더욱 글로벌한 관점에서 문제를 볼 수 있습니다. A –> B –> C –> D –> E와 같이 복잡한 서비스 체인이 있는 경우 요청의 전체 수명 주기를 고려해야 합니다. 서비스 C에서 타임아웃을 연장하는 것이 작업이라면, 부분적으로 하는 것보다는 한꺼번에 모두 하는 것이 합리적입니다. 즉, 서비스 코드를 업데이트하고 풀 리퀘스트가 승인되고 CI 시스템이 업데이트된 서비스를 배포할 때까지 기다리는 것입니다.

14. 원격 측정

요약: 서비스에서 필요한 (그리고 꼭 필요하지 않은) 정보를 모두 수집합니다.

원격 측정은 측정 항목, 분산 추적, 로깅을 포함하는 일반적인 용어입니다. 서비스 메시는 세 가지 유형의 데이터를 모두 수집하고 처리하기 위한 메커니즘을 제공합니다. 여기서는 가능한 옵션의 수가 너무 많아서 약간 모호해집니다. 메트릭 수집 도구가 있습니다 프로 메테우스 그리고 로그를 수집하는 데 사용할 수 있는 기타 도구 유창한, 로키, 벡터 기타 (예를 들어, ClickHouse와 함께 통나무 집 K8의 경우 - 약. 번역)분산 추적을 위해서는 다음이 있습니다. 사냥꾼 등. 각 서비스 메시는 일부 도구를 지원하고 다른 도구는 지원하지 않을 수 있습니다. 프로젝트가 성공할 수 있을지 보는 것은 흥미로울 것입니다. 개방형 원격 측정 어느 정도 수렴성을 제공합니다.

이 경우 서비스 메시 기술의 장점은 사이드카 컨테이너가 원칙적으로 해당 서비스에서 위의 모든 데이터를 수집할 수 있다는 것입니다. 다시 말해, 단일 원격 측정 수집 시스템을 사용할 수 있으며 서비스 메시는 다양한 방법으로 이 모든 정보를 처리할 수 있습니다. 예를 들어:

• CLI에서 특정 서비스의 tail 로그
• 서비스 메시 대시보드에서 트랙 요청 볼륨을 확인합니다.
• 분산된 추적 정보를 수집하여 Jaeger와 같은 시스템으로 전달합니다.

주의, 주관적 판단: 일반적으로 원격 측정은 강력한 서비스 메시 개입이 바람직하지 않은 분야입니다. 기본 정보를 수집하고 적중률과 지연 시간과 같은 일부 "골든 메트릭"을 즉시 추적하는 것은 괜찮지만, 일부 전문화된 시스템을 대체하려는 프랑켄슈타인 스택이 등장하지 않기를 바랍니다. 이 중 일부는 이미 잘 확립되어 있고 잘 이해되고 있습니다.

15. 감사

요약: 역사의 교훈을 잊은 사람은 그 역사를 반복할 운명입니다.

감사는 시스템 내에서 중요한 이벤트를 관찰하는 기술입니다. 서비스 메시의 경우, 이는 특정 서비스의 특정 엔드포인트에 요청을 한 사람을 추적하거나, 지난달에 특정 보안 관련 이벤트가 몇 번 발생했는지 추적하는 것을 의미할 수 있습니다.

감사가 원격 측정과 매우 밀접한 관련이 있다는 것은 분명합니다. 차이점은 원격 측정은 일반적으로 성능이나 기술적 적합성과 같은 것과 연관되는 반면, 감사는 엄격히 기술적인 영역을 넘어선 법률 및 기타 문제(예: GDPR 준수)와 관련될 수 있다는 것입니다.

16. 시각화

요약: 기이한 인터페이스의 원천인 React.js가 오래 살기를.

더 적절한 용어가 있을지도 모르겠지만, 모르겠습니다. 제가 말하고자 하는 것은 서비스 메시나 그 일부 구성 요소의 그래픽 표현입니다. 이러한 시각화에는 평균 지연 시간, 사이드카 컨테이너 구성 정보, 상태 점검 결과, 알림과 같은 지표가 포함될 수 있습니다.

서비스 지향적인 환경에서 일하는 것은 His Majesty the Monolith보다 훨씬 더 높은 인지 부하를 수반합니다. 그러므로 인지적 압박은 어떻게 해서든지 줄여야 합니다. 버튼을 클릭하기만 하면 원하는 결과를 얻을 수 있는 서비스 메시용 간단한 그래픽 인터페이스는 이 기술의 성장에 매우 중요할 수 있습니다.

목록에 포함되지 않았습니다

원래는 목록에 몇 가지 사용 사례를 더 포함시키려고 했지만, 그렇게 하지 않기로 결정했습니다. 다음은 내 결정 이유와 함께 나열한 것입니다.

• 멀티 데이터 센터. 제 생각에 이건 서비스 메시의 좁고 구체적인 적용이나 서비스 검색 같은 기능 세트일 뿐 사용 사례는 아닙니다.
• 진입 및 진출. 이는 관련된 분야이지만, 저는 (아마도 인위적으로) "동서 교통" 사용 사례로 제한했습니다. 출입에 대해서는 별도의 기사로 다루겠습니다.

결론

이제 끝입니다! 다시 말해, 이 목록은 매우 조건적이며 대부분 불완전합니다. 내가 뭔가를 놓쳤거나 실수를 했다고 생각되면 Twitter에서 나에게 연락해 주세요.@lucperkins). 예의범절을 준수해 주세요.

번역가의 추신

이 기사의 주요 그림은 기사의 이미지를 기반으로 합니다.서비스 메시란 무엇이고, 언제 사용해야 하나요?"(그레고리 맥키넌). 애플리케이션의 일부 기능(녹색)이 애플리케이션 간 연결을 제공하는 서비스 메시(파란색)로 어떻게 이전되었는지 보여줍니다.

블로그에서도 읽어보세요.

• «Service Mesh: 최신 기술에 대해 모든 소프트웨어 엔지니어가 알아야 할 사항";
• «서비스 메시란 무엇이며 [마이크로서비스가 포함된 클라우드 애플리케이션의 경우] 서비스 메시가 필요한 이유는 무엇입니까?";
• «Istio를 사용한 마이크로서비스로 돌아갑니다. 1 부".

출처 : habr.com