서버의 성능을 최적화하기 위해선 어떤 작업이 필요할까요? 어떤 지표를 기준으로 성능을 측정할 것인지, 정의된 지표에 영향을 미치는 변수에는 무엇이 있는지, 해당 변수들의 변화가 성능에 미치는 영향은 어느 정도인지 등 많은 작업이 필요할 것입니다. 그 중에서도 반복해서 요청을 발생시킴으로써 지표를 측정할 수 있게 해주는 테스트 도구는 필수 불가결합니다. 이번 포스팅에선 Apache JMeter를 이용해 부하를 발생시키고, 그 결과를 리포트로 생성해보겠습니다. 부하 테스트를 위한 도구들 어떤 부하 테스트 도구를 사용할까요? 주변에서 가장 많이 접했던 k6, nGrinder, JMeter 세 가지를 고민했습니다. 처음엔 성능 측정을 위해 어떤 지표가 필요하고, 각 도구가 어떤 지표를 제공하는지 등을 고려했는데..
전체 코드는 여기에서 확인하실 수 있습니다 :) 두 곳에 Ajax 요청을 보낸 뒤, 결과를 취합해 후속 작업을 해야 한다면? 언제 처리가 완료될지 정확히 알 수 없는 두 가지 작업이 있고, 그 작업들이 모두 완료된 이후에 취합하여 후속작업을 처리해야 한다고 가정해보겠습니다. 가령 서비스 레이어에서 두 곳의 엔드포인트에 요청을 보내고, 응답 값을 취합해서 결과에 따른 분기처리가 필요한 상황이라고 생각해볼 수 있을 것 같아요. 요청한 클라이언트에게 즉시 결과를 응답해야 한다면 두 요청을 쓰레드 풀 작업 큐에 넣고, 두 Future 객체의 get() 메서드를 이용해 기다린 후 응답한다 이 방법의 장점은 하나의 요청이 응답될 때까지 기다렸다가 다음 요청이 나가는 것이 아니라, 동시에 두 가지 요청이 호출된다는 ..
쓰레드라는 키워드는 정말 무수히 뻗어나가는 가지를 지닌 나무 같습니다. 무수히 많은 가지만큼, 아래로 뻗어있는 뿌리도 아주 깊고 넓습니다. 서버 성능 측정 및 튜닝 관련하여 쓰레드풀, 커넥션풀 등의 키워드가 떠오르고 CPU의 쓰레드, OS의 쓰레드까지 하나의 단어가 여러 맥락에서 사용되기도 하고.. 결국 한 스푼 한 스푼 떠먹는 수밖에 없는 것 같습니다! 조금씩 조금씩 쌓아가보죠~! 쓰레드 풀(Thread Pool)이란? 쓰레드 풀은 제한된 수 만큼의 쓰레드를 미리 생성해두는 곳을 말합니다. 이를 통해 아래와 같은 장점을 취할 수 있습니다. 향후 새로운 처리를 위해 스레드 생성 비용을 매번 발생시키지 않게 된다 스레드의 과도한 증폭으로 인한 CPU, 메모리 사용에 따른 성능 저하를 방지한다 요청이 많아져..
CloudWatch를 구성하고 몇 주가 지난 뒤, 카드 결제 알림을 받게 되었습니다. 5만원 정도의 비용이었는데요, 의도하지 않은 사용 및 비용이었기에 환불 신청을 진행해보았습니다. Cost Explorer 확인 Cost Explorer 를 처음 접속한다면 구성하기 위한 24시간 가량의 시간이 필요하다는 안내와 함께 비용에 대한 안내가 바로 나오지 않습니다. 24시간 정도 기다린 뒤 다시 접속하면 일별 청구 요금과 서비스별 청구 요금을 확인할 수 있습니다. 정확히 연습삼아 CloudWatch를 구성했던 날부터 거의 동일한 금액이 청구되고 있었네요. 환불 문의 전 사전 조치 연습용으로만 프리티어를 사용하고 있었기에 큰 부담 없이 모든 서비스를 제거했습니다. CloudWatchAgent가 설치되어있던 EC2..
AWS CloudWatch 를 이용해 여러 서버의 로그 기록을 한 곳에서 모니터링해봅시다! 이번 포스팅에선 대시보드, 시각화, 경보 등은 다루지 않습니다. 또한, CloudWatch 구성 관련 권한을 부여받지 못해 우테코 EC2 인스턴스에 Agent를 설치하여 On-Premise로 활용하고, 개인 AWS CloudWatch를 중앙 모니터링 서버로 활용하는 상황을 가정하고 있으니 이점 참고부탁드립니다! 통합 모니터링 시스템의 필요성 팀 프로젝트를 진행하며, 다른 요구사항을 구현하는 데 쫓기다보니 로그를 통합 관제할 수 있는 시스템을 구축해두지 않아 불편함을 느낀 적이 많았습니다. 매번 로그를 확인하려면 서버에 접속해서 log파일을 열어봐야만 했었어요. 특정 버그를 해결하기 위해 nginx, 개발서버, 운영..
