오늘도 지식 한점!

https://istio.io/latest/docs/tasks/observability/ Observability Demonstrates how to collect telemetry information from the mesh. istio.io Observability vs Monitoring 외부 신호와 특성만 보고 시스템 안정적으로 동작하는지 확인하고 문제가 발생했을때 언제 잘못되었는지 어떤 이유인지 파악하기 위해 측정되는 시스템의 특성을 Observability라 얘기합니다. Observability는 런타임 동작을 변경할 수 있는 시스템에 대한 제어를 구현하는 데 중요합니다. 클라우드 인프라와 어플리케이션에서 생성하는 로그와 이벤트, 메트릭 등 모든것을 기록하고 관찰하는 것을 의미합니다. Obs..

Service Mesh(여기서는 istio)를 사용하는 이유를 들어보자면, MSA(Micro Service Arch.)구조에서는 너무나 많은 마이크로 서비스들이 생성될 수 있습니다. 그것은 서비스 단위를 설계하여 쪼개는 설계자에 달려있으나 이론적으로 아주 작게 분리하면 감당하기 힘들 정도의 서비스들로 나눌수도 있습니다. 이런 경우 외부에서 들어오는 트래픽이나, 컨테이너들끼리의 통신의 가시성을 확보하고 제어를 상대적으로 쉽게하는 기술이 필요하게 되었고 이를 위해 등장한 것이 서비스 메쉬(mesh)입니다. 여기서는 istio를 활용하여 서비스 디스커버리, 네트워크 모니터링, 컨트롤 등이 가능하게 시도하는 것입니다. 이를 가능하게 하는 것이 바로 sidecar 입니다. 각 컨테이너마다 통신을 담당하는 prox..

셋탑 위치(지역) 기반 테스트용 vs 일반 사용자 요금별(유료 고객 vs 무료 고객) Feature Flag Ramdom(Weighted) Flow Diagram 구성의 예> API Path에 따라 stable(blue) 또는 preview(green)으로 라우팅되도록 구성하였습니다. 롤 아웃 진행중에 preview(green) 환경으로 트래픽을 보내기 위해서는 특정 트래픽의 요청 path를 변경해야 합니다.(API GW에서 구성) 모든 POD를 새버젼(Green Pod)로 보내기 전에 weight에 따라 stable/preview 환경으로 트래픽 전달 특정 시간동안 일부 트래픽을 랜덤으로 Green 환경으로 배포 후 요청 사항을 수집하여 자동/수동으로 Promotion 진행 인증 POD에서 인증정보(s..

마이크로 서비스 아키텍처에서 문제중 일반적인 것은 cascading failure을 꼽을 수 있습니다. 어떤 이유로 서비스가 응답하지 않는 경우, 서비스에 request를 계속해서 보내면 latency가 길어지고 그에 따른 서비스에 불필요한 부하가 발생할 여지가 있습니다. 마이크로 서비스의 경우 다양한 서비스로 구성되는데, A 서비스와 B 서비스가 연계되어 있을 경우 다른 서비스의 부하로 이어지는데 이런 현상을 cascading failure라 한다. 이런 현상을 circuit breaking을 통해 과부하된 서비스의 연결을 끊고 서비스가 회복할 시간을 줄 수 있게하여 장애를 처리할 수 있게 됩니다. Destination rule에서 또는 value에서 이용하여 circuit break 설정이 가능합니다..