HTTPS (HTTP over SSL) HTTPS(HyperText Transfer Protocol Secure)는 HTTP 프로토콜에 암호화 프로토콜을 사용하여 통신을 암호화한 HTTP의 보안 버전이다. HTTPS는 데이터 전송의 보안을 강화하기 위해 사용된다. 모든 웹 사이트에 HTTPS가 권장되지만, 특히 로그인 자격 증명이 필요한 웹 사이트는 HTTPS를 사용해야한다. 우리가 접근하는 웹 사이트가 https://~ 로 시작한다면, 웹 서버로 데이터가 암호화되어 안정하게 전달됨을 의미한다. HTTP를 사용하여 데이터가 전송된다면, 데이터는 쉽게 스니핑할 수 있는 데이터 패킷으로 나뉘어 보안 위험에 노출될 수 있다. HTTPS를 사용하면 패킷을 스니핑하거나 가로챈다고 해도 암호화된 문자로 인식된다. ..
서킷 브레이킹 서킷 브레이킹에 대한 참고글: https://martinfowler.com/bliki/CircuitBreaker.html k8s 기반 분산 아키텍처에서 발생할 수 있는 문제 중 하나는 연계 고장이다. 한 부분의 실패가 다른 부분까지 영향을 주는 것이다. 특정 마이크로서비스에 문제가 생겼다고 치자. 문제가 있는 마이크로서비스로 요청이 가게되면 response time이 증가하고 요청 자체가 실패할 가능성이 높다. 트래픽이 낮으면 문제가 없을 수 있지만, 높은 수준의 트래픽이 주어진다면, 요청이 밀려들어오면서 보류 중인 요청들이 생길 것이고 많은 요청들이 타임아웃으로 실패할 것이다. 이를 해결하고자 생긴 것이 서킷 브레이커이다. 서킷 브레이커 솔루션은 여러가지가 있는데, 대표적으로 Hystri..
이전 글을 참고하면 좋습니다. [DevOps] - [Istio] 트래픽 관리 결함주입 https://istio.io/latest/docs/tasks/traffic-management/fault-injection/ Fault Injection This task shows you how to inject faults to test the resiliency of your application. istio.io istio를 통해 시스템에 의도적으로 결함을 주입 할 수 있다. 예를 들어, 요청에 시간 지연을 추가하여, 서비스를 천천히 실행시키는 것이다. 우리는 분산 시스템이 내결함성을 갖도록 구축해야한다. 시스템 신뢰를 위해 사전에 결함 테스트를 진행할 수 있다. 예를 들어, 외부에서 데이터를 가져오는 마이크로..
header 기반 라우팅 header 기반 라우팅으로, my-header: canary 라는 header가 존재하면 실험버전으로 보내고, 그 외에는 기존 버전을 보도록 정의하면 다음과 같다. kind: VirtualService apiVersion: networking.istio.io/v1alpha3 metadata: name: webapp namespace: default spec: hosts: - "*" gateways: - ingress-gateway-configuration http: - match: - headers: # IF my-header: exact: canary route: # THEN - destination: host: webapp subset: experimental - route..
이전 글을 참고하면 좋습니다. [DevOps] - [Istio] 로드밸런싱 (+ConsistentHashing) Istio Ingress Gateway & Edge Proxy k8s를 사용한다면 대게 ingress controller를 이용할 것이다. istio 문서에서는 istio ingress gateway를 권장하고 있는데, 이를 사용해야하는 이유를 알아보자. 클라이언트가 접근하게 되는 webapp을 카나리로 비율을 설정하여 배포해보자. 아마 테스트를 해보면, 비율대로 카나리가 나오지 않을 것이다. VirtualService가 제대로 작동하지 않는다는 것과 같다. 이유는 프록시에 있다. pod안에 있는 컨테이너가 다른 pod의 컨테이너를 호출하게 되면, 이 요청은 사이드카 프록시를 통해 전달된다. ..
이전 글을 참고하면 좋습니다. [*] - Istio 트래픽 관리 Session Affinity 카나리 버전을 일정 비율로 배포하였고, 어떤 유저가 방문하여 카나리 버전을 사용하게 되었다고 가정하자. 그 유저가 계속 카나리 버전을 사용하도록, 즉 같은 유저의 요청에 대해서는 같은 응답을 하도록 할 수 있을까? https://istio.io/latest/docs/reference/config/networking/destination-rule/ Destination Rule Configuration affecting load balancing, outlier detection, etc. istio.io Destination Rule 문서에는 sticky session을 설정하는 예제가 있다. 유저의 쿠키를 해..
