코기판

Background Jmeter? Locust? 1. 코드로 TC 관리 가능 2. Use Less Resources Tips for Using Locust 1. RPS is quite consistent 2. Test boundary 3. Master-slave 구조의 필요성 4. test client 위치 5. Get Hints From Fail Conclusion Background 드디어 회사에서 개발하고 있는 서비스가 성능 검증을 받아야 하는 시기가 도래했습니다. 이전에는 기능에 대한 테스팅만을 진행하다 처음 성능 테스트를 하는 것입니다. 그렇기 때문에 개발 쪽에서 자체적으로 성능 수치를 제안해야 할 뿐 아니라, 성능에 대한 데이터 확보가 중요하게 되었습니다. 성능 측정을 처음 해보는 것이었기 때..

안녕하세요, 오늘은 grpc 번외편으로 grpc load balancing에 대한 이야기를 해볼까 합니다. 최근에 회사에서 이 이슈때문에 많은 삽질을 해서 .. 헤매는 분들께 도움이 될만한 부분이 있을 것 같습니다. 최근에 회사에서 Weave사에서 나온 Scope라는 툴을 붙였는데요, (Scope가 너무 일반명사 같아서 저는 그냥 Weave Scope라고 부릅니다.) 이 Weav Scope라는 툴은, 실시간으로 pod간 연결이나 container 간 연결에 대해 자동으로 지도를 그려주는 역할을 합니다. 즉, network topology를 실시간, 자동적으로 그려주는 모니터링 툴 중 하나입니다. 그런데 막상 이 툴을 붙여보니, frontend와 backend 연결에서 이상한 점이 보였습니다. 어떤 pod..

gRPC를 사용하려고, 가만히 들여다 보면 Protocol Buffers에 대한 이야기가 꼭 빠지지 않고 나옵니다. 줄여서 protobuf라고도 부르고, golang을 사용하다보면 pb라고 극단적으로 줄여서 말하기도 합니다. 스아실.. protobuf가 뭔지 몰라도, 왠지 생긴 것이 json과 왠지 비슷하기 때문에 그냥 대충 감으로 써도 gRPC 샘플을 만들어 보는데 무리가 없기는 하지만, 모든 것들이 다 그러하듯 조금 더 practical하게 쓰려고 하면 막히는 부분이 있어서 protobuf에 대해서 공부하는 느낌으로 한 번 짚고 가려고 합니다. 그래서, 이번 포스팅에서는 * protobuf가 무엇인지, 그리고 장점은 무엇인지 * protobuf 작성 가이드 * gRPC를 사용하기 위해서는 어떻게 해야..

최근 회사와는 별개로 구현해보려고 하는 개인 프로젝트가 있습니다. 머신 러닝을 이용한 챗봇 형태의 프로젝트이고, backend 서버는 golang, 그리고 각각의 모듈은 python 으로 구성하려고 합니다. 그림으로 표현해보면 간략하게나마 다음과 같이 표현할 수 있겠네요 . 그러다보니 자연스럽게 golang server와 python client가 어떻게 통신할 것인지에 대해 고민하게 되었습니다. 또한 다른 언어로 된 클라이언트들이 생길 수 있으므로 확장성을 고려한 연결이었으면 좋겠다고 생각했습니다. 가급적 빠르고, 구현도 쉽다면 더 좋겠죠 ?? 개발자들은 해야 할 일이 아주 많으니까요 ㅠㅠ 여러 가지 요구사항을 대강 생각만 해 두고 검색을 해 보니, gRPC를 쓰라는 답변을 발견했습니다. 마침 회사에서..

Pod autoscaling에 대해 개념적으로 알아보도록 하겠습니다. 지난 포스팅에서는 k8s CA(cluster autoscaler)에 대해서 알아봤는데요, 이번에는 그 연장선이라고 할 수 있습니다. 처음 CA(Cluster Autoscaler)를 도입할 때, 여러 명의 서비스 개발자가 계속해서 여러 개의 서비스를 배포할 수 있도록 node에 pod이 가득 차면 새로운 worker node를 만들어주기 위해 CA를 도입하였습니다. 그렇다면 개발자들이 pod deploy를 해야만 pod의 갯수가 증가할까요? pod은 서비스가 많이 deploy될 수록 늘어나기도 하지만, cpu 나 memory 사용량, 혹은 대량의 request가 들어올 때 스스로 늘어납니다. (물론 설정이 필요합니다) 그리고 이렇게 스스..

지난 번 포스팅에서 이야기 했듯이, EKS의 각각의 worker node는 EC2 instance인데, 아무리 작은 크기의 pod이라고 해도, 무한정 pod을 배포시킬 수는 없다. 그래서 여러 명의 개발자가 pod을 많이 배포시키거나, HPA(Horizontal Pod Autoscaling)에 의해 여러 개의 pod이 만들어지면, node가 가득 차버려서, pod이 스케줄 될 수 없어 pending 상태에 머무르는 상황이 발생한다 이럴 때 필요한 것이 바로 Clustster autoscaling(CA)이다 처음 cluster autoscaling이라는 단어를 들었을때, "클러스터 자체를 여러개 늘리는건가..?" 라는 생각을 했다. 하지만, CA는 worker node의 갯수를 늘리는 것이다. pod이 여..

백엔드 마이크로 서비스에 대한 로드 밸런싱을 테스트해보려고 하다가,worker node의 capability가 모두 차서, 더 이상 pod을 가진 service가 배포되지 않는 상황이 발생하였다.pod 갯수가 worker node instance에서 허용 가능한 갯수를 초과한 것이다.따라서, worker node가 가득 찬 상태에서는개발자들이 서비스를 배포하면, 배포 대상인 pod들이 pending 상태가 되며 새로운 서비스를 deploy할 수 없는 상황이 발생했다. instance당 수용 가능한 pod 갯수는 아래 링크에서 확인할 수 있다.https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt# Mapping is cal..