-
github actions, kustomize와 argocd를 EKS에서 kafka랑 사용하기 8부AWS 2023. 4. 8. 17:09
7부 링크
스프링 깃허브
https://github.com/TaeWoonJeong/spring-feign-kafka-multimodule
t3.large로 실습한다.
bitnami/kafka 로 하고싶었지만, pending 상태에 계속 있어서 아마도 pvc 를 설정해줘야 할거같다..
정보를 찾아봐도 없어서 어쩔수 없이 도커컴포즈로 카프카를 올리겠다.
도커를 설치한다.
sudo apt update sudo apt install docker.io sudo apt install docker-compose
로 설치한다.
https://pearlluck.tistory.com/638
이 블로그에서 docker-compose 파일을 가져왔다.
eks 에 명령을 내리는 컴퓨터에서 카프카를 실행한다.
eks에 명령을 내리는 컴퓨터는 사양이 cpu 1개 메모리 1기가이므로 적당히 메모리 값을 바꿔주거나, 스왑메모리를 사용하도록 하자.
version: '2' services: zookeeper: container_name: local-zookeeper image: wurstmeister/zookeeper ports: - "2181:2181" kafka: container_name: local-kafka image: wurstmeister/kafka depends_on: - zookeeper ports: - "9092:9092" environment: KAFKA_ADVERTISED_HOST_NAME: ec2-IP 주소를 적으세요 KAFKA_ADVERTISED_PORT: 9092 KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_HEAP_OPTS: "-Xmx512M -Xms512M" volumes: - /var/run/docker.sock:/var/run/docker.sock
메모리가 부족해서 512M 로 제한해줬다.
sudo docker exec -it local-kafka /bin/bash
로 접속해서 토픽1개 인데 파티션 10개 짜리로 만들어주자.
kafka-topics.sh --create --topic my-message --partitions 10 --bootstrap-server localhost:9092
그리고 준비해둔 스프링을 켜주고 kafka 컨테이너에 가서 아래 명령어를 입력해보자.
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group test-consumer-group1
아르고 cd도 잘 연결되어있다.
ingress도 잘 떠있고, 어드레스도 잘 받았다.
SSL 인증서도 잘 적용되어있다.
스프링 consumer이 각각 10개씩 해서 2개의 파드가 떠있으므로 총 컨슈머 개수는 20개다. 하지만 kafka topic의 파티션 개수는 10개이므로 스프링 파드의 로그를 보면 각각 5개씩 가져간걸 볼 수 있다. 항상 정확히 5개라고는 못하겠지만 이번엔 우연히 5개씩 가져갔다.
나중에 파드개수와 파드당 컨슈머 개수를 토픽의 파티션에 맞게 설정해야한다.
그래서 기존에 만들어둔 my-message 토픽의 파티션을 20개로 바꿔주겠다.
kafka-topics.sh --alter --topic my-message --partitions 20 --bootstrap-server localhost:9092
롤링업데이트가 잘 되는지 확인해볼겸 모듈들을 전부 하나씩 수정해서 github ci 와 argo cd가 잘 돌아가는지 확인해보자.
성공한다면, manifest가 있는 레포지토리에 각각의 이미지 태그들이 업데이트되어서 커밋될것이다. 즉 커밋이 4번된다.
전부 성공했고, manifest 가 있는 레포의 커밋기록을 봐보자
이런식으로 잘 올라간다.
아르고cd가 3분마다 한번씩 확인하므로 조금 기다리면 자동으로 변경을 감지해서 새로운 deploy를 재배포한다.
잘 올라갔고, consumer 의 로그를 봐보자.
스프링에서 producer/send 로 요청을 보내면 카프카가 받고, consumer 에서 하나씩 가져간다.
요청을 1개씩 수동으로 보내면 재미가 없으니 apache Jmeter을 사용해서 10만건 요청을 보내보겠다.
https://aws.amazon.com/ko/blogs/korea/how-to-loading-test-based-on-aws/
보고 원하는 만큼 테스트해보면 된다.
https://jnylove.tistory.com/316
설정 방법
Test Plan -> Add -> Listener 에 가면 jp@gc - Transactions per Second 가 있다.
Test Plan -> Add -> Treads -> Tread Group으로 쓰레드 그룹 만들고
Thread Group -> Add -> Sampler -> Http Request 에서 바디 잘 적고 advanced에서 HttpClient4 로 해준다.
post 요청이므로 HTTP Header Manager이 필요하다.
Thread Group -> Add -> Config Element -> Http Header Manager 을 클릭해서 아래 사진처럼 써주자.
이렇게 만들어주고, 나머지 리포터 들은 Thread Group -> Add -> Listener 에 가면 있다.
이렇게 실험해보겠다.
10000명의 유저가 있는데 10초동안 실행해야 하므로 1초에 1000개의 유저가 요청을 보낸다고 보면된다. 그리고 이걸 10번 반복이니까 총 100,000 번 한다.
오류가 없다면 db에는 10만개의 데이터가 있어야한다.
너무 많은 요청을 로컬컴퓨터가 보내서 렉이 걸릴수도 있다.
이런식으로 카프카 랙을 조회할 수 있다.
파티션이 20개고 컨슈머가 20개여서 그런지 상당히 빨리 끝났다.
RDS에 가서 데이터를 조회해보자.
10만개 보냈는데 3000개 정도 손실이 났다. 아마도 로컬컴퓨터 사양이 좋지 않아서 그런거 같다.
jmeter 그래프도 봐보자.
요청 보내는 중에 jmeter이 잠시 멈췄는데, 그래서 이부분에서 실패가 많이 발생했다.
실패한게 3000~4000개 인데, summary report에서는 에러율이 15%이니까 대략 15000개 실패했다고 한다.
누가 맞는지 보기위해 카프카 토픽을 조회해서 확인해보자.
GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID test-consumer-group1 my-message 7 4014 4014 0 consumer-test-consumer-group1-3-e7d82cf8-fa24-42f5-b421-ba510364e536 /13.209.184.155 consumer-test-consumer-group1-3 test-consumer-group1 my-message 6 6170 6170 0 consumer-test-consumer-group1-3-6f9e3598-c8ef-4ec4-9c47-9395bfbf8742 /13.209.184.155 consumer-test-consumer-group1-3 test-consumer-group1 my-message 1 4706 4706 0 consumer-test-consumer-group1-1-d7f535c9-17c2-4b94-8e16-419ae86675e9 /13.209.184.155 consumer-test-consumer-group1-1 test-consumer-group1 my-message 5 3942 3942 0 consumer-test-consumer-group1-2-ed74c6f4-6327-425f-9349-07bfa6d769fe /13.209.184.155 consumer-test-consumer-group1-2 test-consumer-group1 my-message 11 4838 4838 0 consumer-test-consumer-group1-5-77b0444d-8d43-4eee-bb34-83942cabc04c /13.209.184.155 consumer-test-consumer-group1-5 test-consumer-group1 my-message 14 4371 4371 0 consumer-test-consumer-group1-7-3f16bc4f-dbd7-41ff-b57f-b983ee870541 /13.209.184.155 consumer-test-consumer-group1-7 test-consumer-group1 my-message 4 4356 4356 0 consumer-test-consumer-group1-2-afbf2d05-7709-4a35-882a-ebdb0a50c225 /13.209.184.155 consumer-test-consumer-group1-2 test-consumer-group1 my-message 3 4761 4761 0 consumer-test-consumer-group1-10-e7824d1e-c2c7-44b0-ba4e-aef6f1d311cc /13.209.184.155 consumer-test-consumer-group1-10 test-consumer-group1 my-message 10 6396 6396 0 consumer-test-consumer-group1-5-1a4d5d72-c1e2-4c11-aac5-d7fadcbca453 /13.209.184.155 consumer-test-consumer-group1-5 test-consumer-group1 my-message 16 4165 4165 0 consumer-test-consumer-group1-8-c1cae9ae-e9b2-4e82-8d91-c733f9076aff /13.209.184.155 consumer-test-consumer-group1-8 test-consumer-group1 my-message 18 3895 3895 0 consumer-test-consumer-group1-9-6d8b83a1-6abf-4983-8fb6-8274ce932bc6 /13.209.184.155 consumer-test-consumer-group1-9 test-consumer-group1 my-message 19 7197 7197 0 consumer-test-consumer-group1-9-a50a18be-cbf2-40e8-8b04-2b2f262be3a4 /13.209.184.155 consumer-test-consumer-group1-9 test-consumer-group1 my-message 0 6228 6228 0 consumer-test-consumer-group1-1-29889237-fb8d-4923-8791-ef8e93966055 /13.209.184.155 consumer-test-consumer-group1-1 test-consumer-group1 my-message 17 5531 5531 0 consumer-test-consumer-group1-8-d7ecc242-db81-4e3a-8e9a-b8ab21fe6136 /13.209.184.155 consumer-test-consumer-group1-8 test-consumer-group1 my-message 15 4644 4644 0 consumer-test-consumer-group1-7-a7911239-d2e6-4f9a-a90d-480288bdd116 /13.209.184.155 consumer-test-consumer-group1-7 test-consumer-group1 my-message 9 3064 3064 0 consumer-test-consumer-group1-4-d2de8f15-c938-4bad-bccf-ec6f5bdfbfa7 /13.209.184.155 consumer-test-consumer-group1-4 test-consumer-group1 my-message 2 4688 4688 0 consumer-test-consumer-group1-10-73f9c213-e4b9-4c9b-89c6-d5ed79a2572a /13.209.184.155 consumer-test-consumer-group1-10 test-consumer-group1 my-message 12 4366 4366 0 consumer-test-consumer-group1-6-460a205e-a09e-4352-9960-92c957506cbb /13.209.184.155 consumer-test-consumer-group1-6 test-consumer-group1 my-message 8 4702 4702 0 consumer-test-consumer-group1-4-435100ef-bfbc-4d3d-935b-afe97fc1bfaa /13.209.184.155 consumer-test-consumer-group1-4 test-consumer-group1 my-message 13 4237 4237 0 consumer-test-consumer-group1-6-d3c9806f-ea1f-42c1-bb10-b24b5df45c0d /13.209.184.155 consumer-test-consumer-group1-6
CURRENT_OFFSET을 전부 더하면 4014+6170+4706+3942+4838+4371+4356+4761+6396+4165+3895+7197+6228+5531+4644+3064+4688+4366+4702+4237 = 96271 이다.
DB에 저장된 개수가 정확히 맞다.
summary report가 틀린거로 판단된다. 200응답을 못받은것도 전부 실패로 처리해서 그런가?? 라고 추측한다.
추가로 약 10만개 데이터가 RDS에 저장되어있는데, 용량은 얼마나 채웠는지 알아보자.
데이터 형식은 아래와 같다.
1 message1 2023-04-09T11:24:19.997039800 aaa
SELECT table_name AS 테이블 이름, ROUND(SUM(data_length+index_length)/(1024*1024), 2) AS 'All(MB)', ROUND(data_length/(1024*1024), 2) AS 'Data(MB)', ROUND(index_length/(1024*1024), 2) AS 'Index(MB)' FROM information_schema.tables GROUP BY table_name ORDER BY data_length DESC;
을 했더니
이렇게 나왔다.
다음에는 몽고DB를 eks클러스터 내부에 설치와, RDS말고 eks내부에서 DB를 pvc를 사용해서 생성한 다음, 실험을 해보겠다.
마지막으로 jmeter에서 graph results 도 추가해봤는데, 이렇게 나왔다.
위에는 카프카를 사용했을 때 이야기인데, 만약 카프카를 사용하지 않고 EKS를 사용하지 않는 상태라면 어떻게 될까??
동일한 인스턴스인 t3.large로 실험했다.
module1과 module2를 실행한다. 테스트는 간단히 module1에게 post요청을 주면 module2에서 RDS에 저장하는 내용이다. ThreadGroup 조건도 동일하게 했을 때 결과는 이렇게 나왔다.
시간도 오래걸리고, 에러율도 많다. RDS에 가서 얼마나 저장됬는지 확인해보자.
100,000개 요청을 보냈는데 50,000개 정도만 들어갔다.
카프카 쓴거는 97,000개 들어간걸로 봐서 kafka 를 써야 대규모 처리에 좋은거 같다.
물론 kafka 를 쓰면 100,000개 요청을 보내는건 금방 끝나지만, 내부에서 처리하는데 시간이 좀 오래걸린다.(토픽에 데이터가 계속 쌓여있어서 이거를 컨슈머에서 가져가는데 시간이 오래걸림)
kafka를 사용하지 않으면, 큐에 쌓을 수 없으니 일정 수준의 트래픽 이상으로 들어온다면, 에러가 높아질 수 밖에 없다.
'AWS' 카테고리의 다른 글
aws ec2 인스턴스 생성에 대한 고찰 (0) 2023.07.26 ec2에서 jenkins 빌드서버 만들어보기 3편 (0) 2023.04.10 github actions, kustomize와 argocd를 EKS에서 kafka랑 사용하기 7부 (0) 2023.04.05 github actions, kustomize와 argocd를 EKS에서 kafka랑 사용하기 6부 (0) 2023.04.05 github actions, kustomize와 argocd를 EKS에서 kafka랑 사용하기 5부 (0) 2023.04.03