Alden's Dev Log

오늘 다룰 내용은 Reactor Netty HTTP Client에서 간헐적으로 발생했던 Connection prematurely closed BEFORE response 에러와 관련된 내용 입니다. 왜 이 에러가 발생하는지 원인을 추적하는 과정과 어떻게 대응 했는지에 대한 내용을 살펴 보려고 합니다. 문제의 발단 서비스 오픈 후 트래픽이 증가하면서 기존에는 발생하지 않던 새로운 종류의 에러가 발생하기 시작 했습니다. 바로 Connection prematurely closed BEFORE response 에러 였습니다. 에러 메세지만 봐도 응답을 받기 전에 커넥션이 끊어졌다는 메세지 였고, 이는 네트워크 문제가 발생했음을 알 수 있는 메세지 였습니다. 과연 원인이 무엇일까, 원인을 찾아내기 위해 tcpdu..

간헐적으로 발생하는 네트워크 이슈 만큼 원인을 추적하기 어려운 이슈는 아마 없을 겁니다. 모든 요청에 대해서 에러가 발생하는 것도 아니고 가끔씩 에러가 발생하면서 수집하는 메트릭에는 특별한 흔적도 남기지 않는 그런 이슈들. 요즘에는 eBPF 기반의 도구를 이용해 네트워크 문제를 분석하는 경우도 많지만 어떤 경우에는 tcpdump와 같은 전통적인 도구가 필요한 경우가 있습니다. 간헐적인 네트워크 이슈들은 전반적인 패킷의 흐름을 수집하고 분석하면서 어느 구간에서 언제 문제가 생기는지를 분석해야 할 필요가 있기 때문 입니다. 하지만 클라우드 환경에서는 tcpdump와 같은 도구를 이용해 패킷을 수집하기 쉽지 않습니다. 그래서 이번 글에서는 AWS에서 제공하는 VPC Flow logs를 네트워크 문제 분석에 어..

쿠버네티스 기반으로 전환할 때 가장 중요한 요소 중 하나가 컨테이너에 대한 이해입니다. 쿠버네티스라는 시스템이 컨테이너를 어느 노드에서 실행하게 할 것인가를 관리하는 오케스트레이션 시스템이기 때문에 그 근간이 되는 컨테이너에 대한 이해가 없다면 쿠버네티스 기반의 환경을 제대로 활용하기 어렵습니다. 그래서 이번 글에서는 컨테이너 런타임으로 가장 많이 사용되는 docker의 run과 exec 명령어를 리눅스 명령어들로 하나씩 재현해 봄으로써 컨테이너에 대한 이해를 돕고자 합니다. 이 글에서 다룬 방법은 제가 컨테이너에 대해 학습할 때 사용했던 방법이고 저도 꽤 많은 도움을 받았던 방법입니다. 그럼 시작해 보겠습니다. 컨테이너란 무엇일까요? 본격적인 이야기를 시작하기 전에 컨테이너란 무엇인지에 대해서 이야기해..

AWS 기반의 인프라를 운영하는 곳에서 가장 많은 비용을 차지하는 것들 중 하나가 바로 EC2입니다. EC2 비용 최적화를 위한 작업은 보통 워크로드에 적합한 사양의 인스턴스를 사용하고, RI를 구매해서 온디멘드로 발생하는 비용을 줄이는 방식으로 진행하게 됩니다. 하지만 그 외에도 스팟 인스턴스를 도입하는 것도 EC2 비용을 줄일 수 있는 좋은 방법입니다. 하지만 스팟 인스턴스는 언제 종료될지 모른다는 단점을 가지고 있기 때문에 도입을 위해서는 자동화된 서비스 제외 환경이 구성되어야 합니다. 이에 대해서는 브런치를 통해서도 한 번 공유 하기도 했습니다. 오늘은 기존 글에서 조금 더 나아가 EKS에 스팟 인스턴스 도입을 하기 위해 고민했던 과정에 대해서 공유하려고 합니다. EKS 워커 노드에 스팟 인스턴스..

오늘은 Logstash의 Kafka Input 성능 개선과 관련된 이야기를 해보겠습니다. 어떤 문제가 있었고 어떻게 해결했는지 그 과정에 대해 살펴보겠습니다. 참고로 이 글에 있는 작업은 박병진 님의 작품 입니다. 저는 그저 사람들에게 알리기 위해 대신해서 글을 쓸 뿐입니다. ^^ 문제의 발단 일부 서비스를 오픈하고 트래픽을 처리하고 있던 중 아래와 같은 모습의 Kafka Lag 지표를 발견했습니다. 피크 시에는 3천을 육박할 정도로 높은 수준의 Lag이 감지되고 있었습니다. 초당 7백여개의 로그가 인입되고 있는 상황이었기 때문에 3천대의 Lag이라면 로그가 ES에 실리기까지 약 4~5초 정도 밀린다는 의미가 됩니다. 물론 4~5초 정도의 로그 적재 지연이 크리티컬 한 상황은 아니었지만, 좀 더 빠르고 ..

오늘은 타임아웃 계의 양대 산맥 Connection Timeout과 Read Timeout에 대해 이야기 해 보려고 합니다. 두 타임아웃의 의미에 대해 살펴보며 적정한 값을 찾는 방법에 대해서 살펴 보겠습니다. Connection Timeout과 Read Timeout의 의미 먼저 Connection Timeout은 종단 간 연결하는데 소요되는 최대 시간을 의미 합니다. 이 시간을 넘기게 되면 연결 할 수 없는 것으로 판단하고 에러가 발생 합니다. Connection 이라는 단어가 의미하는 것처럼 종단 간 연결에 사용되는 타임아웃 입니다. 그리고 이 때의 연결이란 우리가 잘 알고 있는 TCP 3 way handshake를 통해 TCP 연결이 생성되는 것을 의미 합니다. Read Timeout은 연결된 종..

jib 시리즈의 마지막 글로 Github Actions를 이용한 빌드 자동화 과정에 대해서 살펴보겠습니다. jib를 이용해서 애플리케이션의 컨테이너 이미지를 생성하고, 생성된 이미지를 이미지 저장소에 저장하는 과정까지를 Github Actions를 이용해서 사람의 참여 없이 진행해 보려고 합니다. 우선, 본격적인 이야기를 하기에 앞서 Github Actions에 대해 살펴보겠습니다. Github Actions Github Actions는 Github에서 제공하는 CI/CD 도구입니다. 아래는 Github 페이지에서 소개하는 Actions입니다. Automate라는 단어와 workflows라는 단어가 눈에 띕니다. Github Actions는 여러 개의 Action을 순서대로 조합해서 워크플로우라는 것을 ..

지난번 글에서는 패킷 덤프를 통해 ALB의 동작 원리에 대해 살펴봤습니다. 이번 글에서는 패킷 덤프를 통해 살펴보면서 NLB는 ALB와 어떻게 다르게 동작하는지 그 동작 원리에 대해서 살펴보겠습니다. NLB 생성하기 NLB도 ALB와 똑같이 80 포트로 받아서 8080 포트로 넘겨주도록 만들어 보겠습니다. 이번에도 테라폼을 이용해서 만들어 보겠습니다. NLB를 만들 때는 SecurityGroup을 지정하지 않는다는 것을 눈여겨 봐주시기 바랍니다. resource "aws_lb" "nlb" { name = "hello-jib-nlb" subnets = ["subnet-182c2954", "subnet-28fe2f43", "subnet-bb0230e7", "subnet-c2bf3db9"] internal =..

AWS 환경에서는 AutoScalingGroup은 통해서 간편하게 서버의 대수를 유지할 수 있습니다. 트래픽이 늘어나거나 줄어듦에 따라 EC2 인스턴스를 직접 늘리거나 줄이지 않아도 desired, min, max의 수를 변경하는 것만으로도 EC2 인스턴스의 대수를 조절할 수 있기 때문입니다. 만약 AutoScalingGroup이 없었다면, EC2 인스턴스를 하나하나 런칭 시키고 터미네이트 시켜야 했겠죠. 게다가 AutoScalingGroup에는 다양한 조건을 바탕으로 대수를 컨트롤할 수도 있습니다. CPU 사용량이 어느 정도 이상이 되거나, 네트워크 트래픽이 특정 수준 이상이 되면 서버를 늘리거나 줄이도록 설정해서 트래픽에 대한 대응을 자동으로 할 수 있게 도와줍니다. 그중에서도 오늘 살펴볼 Sched..

AWS에는 크게 세 가지 종류의 로드밸런서가 있습니다. CLB라 불리는 Classic LB, ALB라 불리는 Application LB, NLB라 불리는 Network LB 이렇게 세 가지 이죠. 그중 CLB는 사실상 deprecated 된 LB로 요즘엔 거의 사용하지 않습니다. ALB와 NLB가 용도에 맞게 각각 사용되고 있죠. 그래서 다들 궁금해합니다. 대체 ALB와 NLB의 차이점은 무엇인지, 그리고 각각 언제 사용해야 하는 건지. 그래서인지 구글링을 해보면 이 두 가지 LB의 차이점에 대해서 설명하는 글들을 많이 볼 수 있습니다. ALB와 NLB의 특징, 그리고 각각의 LB를 언제 사용하는 게 좋을지에 대한 자료들이 많이 존재하죠. 그래서 이번 글에서는 조금 색다르게 다들 알고 있는 그 차이점 말..