도입 배경안녕하세요. 중고나라 DevOps 엔지니어 조상현, 김지헌입니다.복잡한 아키텍처를 개선하며, 자원 효율화를 위해 새롭게 도입한 Istio Ambient Mode에 대해 공유하려 합니다.중고나라는 회사의 성장과 함께 서비스 트래픽이 증가하면서 네트워크 관리의 중요성이 더욱 커졌습니다. 이를 해결하기 위해 Istio를 도입하여 서비스 메쉬를 구축했지만, 기존 Istio Sidecar Mode 기반 아키텍처는 몇 가지 한계를 보였습니다.Why Ambient Mode?간단하게 기존의 Sidecar Mode 형태의 아키텍처를 간단하게 소개하면 아래와 같습니다.큰 특징으로는 각 Pod마다 Envoy proxy를 Sidecar로 주입하여 트래픽을 전달하는 방식입니다.하지만 Sidecar Mode는 리소스 사용량 증가와 운영 복잡도 같은 문제를 야기했습니다.리소스 증가각 Pod마다 Envoy Proxy를 Sidecar로 주입하므로, 각 Pod의 컨테이너 개수는 (애플리케이션 컨테이너 1개 + Sidecar Proxy 컨테이너 1개)로 총 2개가 됩니다.따라서 Pod 수가 증가할수록 CPU와 Memory 사용량(요청량)이 크게 증가했고, 이는 전체적인 인프라 비용 증가로 이어졌습니다.2. 운영 복잡도Pod에 문제가 발생했을 때, 애플리케이션 컨테이너의 문제인지 Envoy Proxy의 문제인지 즉시 구분하기 어려웠습니다.Envoy Proxy와 애플리케이션이 강하게 결합(Coupling)된 형태여서, 하나의 문제로 인해 전체 Pod의 장애로 확대되는 경우가 많았습니다.저희는 이러한 문제를 해결하기 위해 새롭게 출시한 Ambient Mode로 전환하는 결정을 내렸습니다.새롭게 도입한 Ambient Mode 아키텍처를 간단하게 소개하면 아래와 같습니다.Ambient Mode는 기존의 Sidecar Mode와 달리, Envoy Proxy Sidecar의 역할을 Layer 4(ztunnel)와 Layer 7(waypoint)로 분리하여 네트워크 트래픽을 처리하는 방식으로 모든 pod 간 통신은 ztunnel 을 통하고, L7 기반 로직 처리 필요 시 waypoint 를 경유합니다. 이러한 구조적 변화로 인해 인프라 운영이 더욱 가볍고 효율적으로 설계되었습니다.key point는 아래와 같습니다.리소스 절감Pod마다 Envoy Proxy Sidecar가 존재하지 않으므로 CPU와 Memory 사용량(요청량)이 감소하였고, 더 적은 Worker Node로 동일한 트래픽을 처리할 수 있게 되었습니다.2. 운영 단순화Istio의 정책을 별도의 Proxy(ztunnel, waypoint)로 관리하여, 네트워크 정책 적용과 디버깅이 더욱 간편해졌습니다.애플리케이션을 Service Mesh에 포함하거나 제외할 때, 애플리케이션 Pod 재시작할 필요가 없습니다.Istio 버전을 업그레이드 할 때, 애플리케이션 Pod를 재시작할 필요가 없습니다.물론 Ambient Mode 전환 과정에서 기존 Sidecar Mode와의 호환성을 고려해야 했으며, 트래픽 라우팅 및 보안 정책이 기대한 대로 동작하는지 충분한 테스트가 필요했습니다.다음으로, Ambient Mode 전환 과정에서 맞닥뜨린 문제와 이를 어떻게 해결했는지, 그리고 현재 운영 방식에 대해 더 자세히 풀어보겠습니다!도입 과정Helm + Argo를 통한 Istio Ambient Mode 설치초기에 Istio를 도입할 당시, 중고나라는 Istio Operator를 활용하여 배포 및 운영을 진행하였습니다.그러나 Istio 1.18 버전 이후 Operator 기반의 방식이 Deprecated됨에 따라, 기존 방식으로는 더 이상 업그레이드가 불가능한 상황이 되었습니다.이에 따라 다양한 배포 방법을 검토하였으며, 잦은 업그레이드, 커스텀 설정, GitOps 등 유연한 운영이 가능한 방법을 찾고자 하였습니다.그 결과, Helm을 활용하여 환경별 세부 설정을 커스텀하고, Argo CD 기반의 GitOps 배포 방식을 도입하여 지속적인 운영 및 유지보수를 최적화하기로 결정하였습니다Kubernetes Gateway API 도입기존에는 Istio Gateway를 사용하여 트래픽을 관리하였지만, Gateway API를 도입한 이유는 다음과 같습니다.Istio 측에서 Gateway API를 향후 표준으로 자리 잡을 것이라고 언급했습니다.(참고 문서)Waypoint 트래픽을 세밀하게 제어하기 위해 Gateway API의 HTTPRoute 리소스를 활용할 필요가 있었습니다.이에 따라 기존의 VirtualService 및 DestinationRule 설정을 HTTPRoute 기반으로 재구성하였습니다.또한, Argo Rollout Controller 설치 시 gatewayAPI plugin을 같이 생성하고 Argo Rollout 의 트래픽 라우팅 방식도 기존 trafficRouting.istio에서 trafficRouting.plugins을 활용하는 방식으로 변경하여, Gateway API를 통해 트래픽을 분배할 수 있도록 수정하였습니다. (참고 문서1, 참고 문서2) trafficRouting: plugins: argoproj-labs/gatewayAPI: namespace: {{ .Release.Namespace }} httpRoute: {{ .Release.Name }}-httproute하지만 아직 HTTPRoute에서는 VirtualService, DestinationRule에서 제공하는 트래픽 관리 설정을 완벽하게 지원하지 않습니다.!! 예를 들어 Fault Injection 등은 아직 제공하지 않아 꼭 해당 기능이 필요한 상황이라면 Gateway API의 도입을 신중하게 검토해야합니다!!Ztunnel ProxyConfigAmbient Mode를 도입하면서 가장 큰 변화 중 하나는 L4 트래픽을 처리하는 ztunnel이 등장했다는 점입니다.그렇다면, 기존에 Istiod가 관리하던 ProxyConfig 설정이 ztunnel에도 그대로 적용될까요? 정답은 아니오 입니다.ztunnel은 Envoy 기반이 아니라 독립적인 L4 터널링 컴포넌트입니다.즉, 기존 ProxyConfi

안녕하세요. 토스에서 Gateway를 개발하고 있는 서버플랫폼팀 최준우입니다.토스에서는 목적에 맞는 다양한 Gateway를 사용하고 있는데요. 저는 이번 글에서 이러한 Gateway 아키텍처를 통해 토스가 누리고 있는 장점들과 이를 위해 어떠한 노력을 하고 있는지에 대해 간단히 소개하려고 합니다.우선 Gateway에 대해 간단히 알아보겠습니다. Gateway는 라우팅 및 프로토콜 변환을 담당하며 마이크로 서비스의 중개자 역할을 하는 서버입니다. 이를 통해 서비스는 클라이언트와 독립적으로 확장할 수 있으며 보안, 모니터링을 위한 단일 제어 지점을 제공합니다. Netflix Zuul을 통해 잘 알려졌으며 현재는 Saas나 플랫폼으로도 사용할 수 있게 대중화되었습니다.그림을 통해 예를 들어 보겠습니다. 서비스가 적고 트래픽이 적다면 클라이언트에서 서비스를 직접 호출하고 각각의 서비스에서 모든 로직을 처리해도 큰 부담이 되지는 않습니다. 그러나 스케일이 커지면 공통의 로직을 모든 서버에 적용하고 배포하는 것도 큰일이 됩니다.이러한 필요성을 위해 개발된 게 Gateway 패턴입니다. Gateway는 서버들에서 필요한 공통 로직을 통합하여 처리합니다. 모든 서비스에서 필요한 유저 정보, 보안 정책 등을 Gateway에서 처리하고 이를 업스트림 서버로 넘겨줍니다.Gateway는 요청이 오면 정의된 설정에 따라 요청을 라우팅하고 사전에 설정된 필터들을 작동시킵니다. 설정은 Route 단위로 구성이 되며 Route는 다시 Predicate와 Filter로 구성됩니다. Predicate는 요청을 구분할 때 사용하는 값인데, Path, Method, Host 등으로 요청을 매칭하고 Filter는 매칭된 요청에 대한 전처리나 서비스의 응답에 대한 후처리를 구현합니다.저희는 이러한 Gateway 들을 Spring Cloud Gateway를 사용하여 구성하고 개발하고 있습니다. Spring Cloud Gateway는 스프링 Webflux를 통해 구현되어 있으며 내부적으로 Reactor-Netty를 사용하여 비동기 처리를 지원하고 있습니다. 또한 필터 개발에 Kotlin Coroutine을 적극 활용하고 있으며 Istio의 Ingress / Egress Gateway 및 Envoy 필터와 함께 유기적으로 개발하고 있습니다.이제 앞에서 소개 드렸던 공통 로직들을 저희가 어떻게 개발하고 사용하고 있는지에 대해 간단히 소개해 드리겠습니다.Gateway에서 공통 로직을 처리하는 부분은 크게• None 유저 정보를 이용한 로직 수행등이 있는데, 몇 가지 사례와 그림을 토대로 설명드리도록 하겠습니다.우선 Request 처리입니다. Gateway에서 우선적으로 처리해 줘야 하는 것은 Request를 Sanitize 하는 것입니다. Sanitize는 Client로부터 올바르지 않은 요청이 올 경우 이를 지우거나 올바른 값으로 바꿔주는 것을 의미합니다. 그림처럼 사용자가 악의적으로 값을 주고 요청하더라도 Gateway에서 이를 올바른 값으로 바꿔서 서비스에 넘겨줍니다.토스 내부

안녕하세요, DevOps 팀의 Sammie입니다. Hyperconnect에서는 대부분의 service workload를 AWS 위에서 운영하고 있고, 다른 모든 회사와 동일하게 AWS 비용 절감은 중요한 주제입니다. AWS 비용을 절감할 수 있는 항목을 찾던 중, AWS Graviton Processor를 발견했습니다. Graviton2 instance는 기존 Intel 계열 (5th generation) instance와 비교하여 가격이 20% 정도 저렴하며, 최대 40% 더 빠르다고 홍보[1]하고 있었습니다. 정말로 가격대비 성능이 40% 향상되었는지는 실험 전까지는 알 수 없으나, 동일 CPU core당 가격이 저렴하기 때문에 일단 개발 환경부터 도입해 보기로 했습니다.몇몇 managed service와 workload를 migration 해봤고, 적어도 성능이 더 나빠지지는 않았으므로 대부분의 production workload을 Graviton으로 migration 하기로 하고 다양한 작업을 진행했습니다. 그 결과, 2022년 5월 전까지만 해도 회사 전체에서 ARM64 사용 비중은 거의 0%였지만, 2023년 5월 기준 EC2 instance 요금의 47% 이상을 차지할 정도로 빠르게 전환하여 많은 비용을 절감할 수 있었습니다.이번 글에서는 Kubernetes 위에서 작동하는 100개 이상의 microservice를 ARM64로 migration 했던 작업에 초점을 맞춰 긴 여정을 소개하려고 합니다. 전반적인 process, Kubernetes의 Node와 각종 system component를 ARM64로 전환하는 과정, AMD64와 ARM64 이미지를 동시에 build 하기 위해 CI/CD pipeline을 어떻게 수정했는지, 그리고 실제 이전하면서 문제가 되었던 것을 설명해 드리겠습니다.본격적으로 migration 과정을 설명하기에 앞서, ARM64와 Graviton processor에 대한 간략한 소개와 migration을 진행한 이유를 설명하겠습니다. ARM64는 cpu archicture의 한 종류로, Intel과 AMD에서 사용하는 ADM64 archicture 대비 전력 소모면에서 강점을 가집니다. 따라서, ARM64는 주로 mobile 환경에서 사용되었으며, 지난 2018년 re:Invent에서 ARM64 기반의 Graviton processor와 2019년 12월 Graviton2 processor를 발표한 이후 서버 시장에서도 유의미한 비중을 차지하게 되었습니다.Graviton processor의 장점은 다음과 같습니다.• Graviton processor를 사용하는 c6g, m6g, r6g 등의 instance는 Intel 기반 c5, m5, r5보다 20% 저렴합니다.• 일부 workload에는 40% 더 뛰어난 가격 대비 성능을 보여준다고 합니다. 물론 각 workload 특성에 따라 성능 향상의 수준은 달라지므로 stage 환경에서 load-test를 해보거나, production에 도입하기 전까지 얼

• None Kubeshark란? ・ Kubeshark는 어떻게 동작하나요? ・ TLS의 평문을 확인한다? ・ Kubeshark Architecture ┗ Kubeshark Worker ┗ Kubeshark Hub ┗ Kubeshark Fronted ┗ Kubeshark CLI• None QuotaLab에서는 어떻게 활용했나요? ・ 개발환경의 트러블 슈팅 ┗ CORS 추적 ┗ 서버간 토큰 교환 추적 ┗ 제 로컬에서는 재현이 안되는데요?를 방지합니다• None Kubeshark의 단점은? ・ 과도한 Resource 사용 ・ Pod 내부 컨테이너간 통신 확인 불가 ・ Official Helm Chart의 완성도 ・ Kubeshark CLI ・ 글쓰는 시점에 해결된 것? ・ *Kubeshark는 Sniff 도구입니다. 개인정보 유출에 조심합시다. *안녕하세요 QuotaLab DevOps 챕터의 김동규입니다.2023년에는 여전히 Kubernetes가 메가 트렌드로 자리 잡아 나가고 있고, QuotaLab 역시 Kubernetes를 활용해 모든 워크로드를 운영 중에 있어요.Kubernetes를 통해 매우 편리한 운영 도구와 시스템을 누릴 수 있지만, Security best practice를 따르다 보면 디버깅과 트러블 슈팅 과정이 쉽지 않아진다는 것은 흔히 경험해 볼 수 있는 상황이죠.예를 들어 Wireshark 한번 키면 바로 원인 파악이 가능한 상황이라거나, Shell 조차 없는 distroless 이미지를 사용하고 있어 접근조차 하지 못한 상황을 겪어보셨다면 이 글을 흥미 있게 읽게 되실 거예요.그래서 이번 글에서는 Kubeshark라는 도구를 사용해 Kubernetes 환경에서 “별도의 어플리케이션 수정 없이” 트래픽을 분석할 수 있는 도구를 소개해드릴게요.한마디로 표현하자면, Kubernetes를 위해 재창조된 TCPDump + Wireshark라고 생각하며 읽어주시면 좋겠습니다.최근 QuotaLab에서는 코프링 (Spring + Kotlin)을 기반으로 Spring Cloud Gateway 및 인증 레이어를 분리하는 프로젝트를 진행하고 있는데요. 요청이 실패한 경우 “어느 서비스에서 응답을 준 것인지”, “라우팅이 제대로 되긴 한 것인지”, “Gateway의 filter가 제대로 동작하여 http header 등이 적절하게 수정되었는지” 수많은 케이스를 머릿속으로 생각하며 “APM Trace”, “어플리케이션에서 로그를 추가해 배포”, “Istio의 Access Log 확인” 하는 과정을 반복하곤 했습니다.여러분도 느끼시겠지만 이 과정은 매우 느리고, 효율적이지 못합니다. 운영 환경에서는 당연히 적절한 로그와 Trace를 통해 높은 가시성을 기반으로 추측할 수 있겠지만, 처음 개발 환경을 셋업 하는 과정에서 트러블슈팅에 시간을 소비하긴 너무 아까웠습니다.긴 시간 비효율을 겪던 중, Kubeshark 프로젝트가 있던걸 기억해 내고 도움을 받아보기로 했습니다.Kubeshark는 Wireshark의 Kubernetes 버전이라고 이해하면