Istio In Action - (Introducing the Istio service mesh) 1.1

본 블로그는 Istion In Action 책을 작성자에 스타일에 맞게 번역하여 정리하는 블로그 입니다.

 

1.1 더 빨리 가는데 도전하다.

 

                                        (HTTP Post /foo)     ->        serviceA(Database)

                                

ACMEmono.   (HTTP Get /customer/123)    ->         serviceB (Database)

                                                                          <-           (JSON)

 

                             (HTTP Put /order/456)      ->       serviceC(Database)

 

 

ACMEmono 에서 모듈 A 와 B 를 독립형 서비스로 분리하기로 하였고, C 를 구성하였습니다.

 

K8S 플랫폼에서 Container로 새로운 서비스가 배포되었습니다. 이러한 접근 방식을 구현하기 시작하면서 몇가지 문제를 빠르게 경험했습니다.

 

첫번째로 알아차린 부분은 아키텍처의 서비스가 요청을 처리하는데  걸리는 시간이 매우 일관성이 없다는 것 입니다.

 

소비자 사용이 피크인 기간에, 몇가지 서비스는 간헐적으로 문제가 발생하였고, 트래픽을 처리할 수 없었습니다.

 

또한, 만약 서비스 B의 요청을 처리하는데 문제가 생겼을때, 특정 요청에 대해서 서비스 A도 문제가 발생하였습니다.

 

두번째로 ACMC 가 알아차린것은 자동화된 배포를 연습할 때, 자동 테스트에서 포착되지 않은 시스템 버그를 확인하였습니다.

 

그들은 blue-green 형식의 배포를 연습하였고, 해당 방식은 자신의 클러스터에서 새로운 배포(green) 만들고 어느 시점에서 이전 클러스터의 배포(blue)에서 새로운 배포로의 트래픽을 차단합니다.

 

그들은 블루그린 접근 방식이 배포중 위험을 줄이기를 바랐지만, 그들은 피하고 싶었던 "big bang" release 를 더 많이 경험하였습니다.

 

마지막으로 ACME 는 서비스 A 와 B를 구현하는 팀이 보안을 완전히 다르게 처리하고 있음을 발견했습니다.

 

이러한 도전은 ACME에만 해당되는 것이 아니며, 그들이 직면한 도전의 범위도 제한되지 않습니다.

 

서비스 지향 아키텍처로 이동할때 다음과 같은 사항들이 해결되어야 합니다.

• 고립 경계를 넘어서는 결함을 방지하는 것 
• Env 변화에 대응할 수 있는 Application/Service 를 구축하는 것
• 부분적으로 실패한 상태에서도 실행할 수 있는 능력
• 시스템이 지속적으로 변화하고 진화함에 따라 전체 시스템에 무슨 일이 일어나고 있는지 이해하는 것
• 시스템의 런타임 동작을 제어할 수 없음
• 공격 표면(대상)이 커짐에 따라 강력한 보안을 구현하는 것
• 시스템 변경시 위험을 감소 시키는 것
• 누가 무엇을 시스템 구성요소를 사용할 수 있고, 언제 사용할 수 있는지에 대한 정책을 시행하는 것

1.1.1 우리의 클라우드 인프라환경은 신뢰할 수 없다.

 

클라우드 환경의 고객인 우리는 실제 수많은 종류의 하드웨어를 보지 못하였다.

이러한 구성요소의 형태는 compute, storage, 가상 환경의 네트워크가 있고, 우리는 self-service API 를 제공받는다.

이런 구성요소들은 실패한다. 과거에 우리는 모든 인프라는 HA로 구성하였고, 가용성과 안정성을 가정하여 그 위에 애플리케이션을 구축하였다. 클라우드 환경에서는 우리의 애플리케이션은 일시적이고 때때로 사용할 수 없다고 가정하고 빌드해야 한다.

 

1.1.2 서비스 상호작용을 탄력적으로 만들기

• Client-side load balancing
  • give the client the list of possible endpoints, and let it decide which one to call
• Service discovert
  • A mechanism for finding the periodically updated list of healthy endpoints for a particular logical service
• Circuit breaking
  • shed load for a period of time to a service that appears to be misbehaving
• Bulkheading
  • Limit client resource usage with explicit thresholds (connections, threads, sessions, and so on) when making calls to a service
• Timeouts
  • Enforce time limitations on requests, sockets, liveness, and so on when making calls to a service
• Retries
  • Retry a failed request
• Retry budgets
  • Apply constraints to retries: that is, limit the number of retries in a given period (for example, only retry 50% of the calls in a 10 second window)
• Deadlines
  • Give requests context about how long a response may still be useful; if outside the deadline, disregard processing the request

정확히, 이러한 유형의 타입은 application networking 으로 생각 할 수 있습니다.

이것은 패킷계층 대신 메시지 계층에서 작동하는 것을 제외하고는 네트워크 계측과 비슷한 구조를 가지고 있습니다.

 

1.1.3 실시간으로 어떤일이 일어나는지 이해하다

더 빨리 가는데 중요한 측면은 우리가 올바른 방향으로 가고 있는지 확인하는 것입니다.

고객이 어떻게 반응하지 테스트할 수 있도록 신속하게 배포를 시도하지만 느리거나 사용할 수 없는경우 고객은 서비스를 피하거나 반응할 기회가 없습니다. 서비스를 변경할 때 어떤 영향을 미칠지 이해하고 있습니까? 변경하지 전에 작업이 어떻게 실행되는지 알고 있습니다?

어떤 서비스가 각 사용자와 대화하는지, 일반적인 서비스 로드는 어떤 모습인지, 얼마나 많은 오류가 발생할 것으로 예상되는지, 서비스가 실패하면 어떻게 되는지, 서비스 상태 등 서비스 아키텍처에 대한 정보를 아는 것이 중요합니다.