외부 api는 어떻게 테스트해야 하나요 ?

skehdxhd님 안녕하세요~우선 좋은 질문 남겨주셔서 감사합니다.외부 API를 호출하는 기능의 성능 테스트는 말씀하신 것처럼 신중해야 합니다. 실제로 타사의 API를 무분별하게 호출하면 과금 문제나 서비스 약관 위반 등의 문제가 생길 수 있죠.이럴 때는 외부 API를 모의(Mock) 서버로 대체하여 성능 테스트를 진행하는 것이 일반적입니다. WireMock이나 MockServer 같은 도구를 사용하면 외부 API의 응답을 모의할 수 있는데요, 테스트 코드뿐만 아니라 독립된 서버로 구동시켜서 성능 테스트 시에 실제 외부 API 대신 사용할 수 있습니다.이렇게 하면 실제 외부 API를 호출하지 않고도 시스템의 성능을 측정할 수 있고, 응답 시간이나 오류 상황을 자유롭게 설정하여 다양한 시나리오를 테스트할 수 있습니다. 요약하면, 성능 테스트를 위해서는 외부 API를 모의 서버로 대체하고, 그 모의 서버를 활용하여 테스트를 진행하시는 것이 좋을 것 같습니다.다만 이 경우 개발, 운영 환경을 별도로 구성하고 설정도 다르게 동작해야할 필요가 있을텐데요, 관련해서는 스테이징 환경 같은걸 두는 것도 좋은 방법입니다.혹시 더 궁금한 점 있으시면 언제든지 질문 남겨주세요~

Riot API Circuit Breaker 적용

백종인님 안녕하세요~ 찾아보신 것처럼, slidingWindowSize에 있는 값은 seconds가 맞습니다.잘 찾아보셨어요. 그런데 질문과는 별개로, Riot API Limit에 나와있는 내용은 서킷브레이커보다는 Rate Limiter(https://resilience4j.readme.io/docs/ratelimiter)로 구현하는게 더 적절해보입니다. 서킷브레이커는 부하, 오류 상황으로부터 시스템을 지키는 목적이지 호출 횟수를 제한하려는 목적은 아닙니다. 물론 서킷브레이커로도 구현하신 것처럼 비슷하게 구현은 할 수 있을겁니다. 그러나 조금만 커스터마이징을 하려고 해도 로직을 직접 구현해주셔야해요. 아마 Rate Limiter로 개발하시면 이런 부분이 이미 구현되어있을겁니다. 아무튼 질문 주셔서 감사하고, 혹시 또 궁금한 내용 있으면 질문 남겨주세요~

http 문제

uiw617님 안녕하세요~일단 https가 적용되어있다면 https로 테스트를 하는게 적절해보입니다.다만, 인증서에 문제가 있을지 모르겠네요. (NaN으로 나오는걸 보니 맞을 것 같기도한데.. 자세한 상황을 제가 알기 어려워서 정확하진 않을 수도 있습니다.) 문제의 원인이 뭔지와는 무관하게 artillery 스크립트 실행시 --insecure 설정을 함께 추가해서 실행해보시기 바랍니다.artillery run your-script.yaml --insecure 이런식으로요혹시 한번 시도해보시고 어떤지 답변 남겨주시면 마저 확인해보겠습니다. (_ _)

stage view 가 안보여요

해결 처리를 위한 답변입니다. (_ _)

부하 테스트 진행 중, DB사용과 관련하여 데이터 관리 문의사항

BeakGwa님 안녕하세요!질문 주신 내용에 대해 답변드리겠습니다.성능 테스트를 진행하면서 데이터베이스에 데이터를 생성하는 POST 메서드를 테스트하고 계신데, 테스트로 인해 생성된 데이터의 관리가 고민이 되시는 것 같습니다. Write 연산에 대한 성능 테스트라면 반드시 고려해야 할 중요한 내용입니다.결론부터 말씀드리자면, 성능 테스트 시 일반적으로 별도의 테스트용 서버와 테스트용 데이터베이스를 구성하여 테스트를 진행하는 것이 권장됩니다. 이때 테스트 서버의 성능은 실제 배포 서버와 최대한 유사하게 구성하여 현실적인 성능 측정이 가능하도록 하는 것이 좋습니다. 보통 이러한 테스트 환경을 "스테이징 환경"이라고 부릅니다. 관련해서는 제가 최근 업로드한 강의에 설명이 간략하게 나와 있으니 참고해보세요~하지만 여러 가지 이유로 스테이징 환경을 구성할 수 없어서 개발 환경에서 성능 테스트를 진행해야 하는 상황이라면, 기능 테스트를 위한 데이터와 성능 테스트에 사용된 데이터가 섞일 수 있습니다. 이로 인해 성능 테스트에 사용된 데이터를 반드시 제거해야 하는 상황이라면, 말씀하신 것처럼 SSH로 서버에 접속하여 데이터베이스를 정리하는 스크립트를 작성하고, 이를 Artillery의 after 스크립트에 추가하여 자동화하는 것도 하나의 방법입니다. 다만, 성능 테스트에 사용한 데이터는 어떤 식으로든 구분되도록 만들어야 하기 때문에 다소 번거로울 수 있습니다.질문에 대한 답변이 되었길 바랍니다.또 다른 궁금한 사항이 있으시면 언제든지 질문 남겨주세요.감사합니다!

성능 테스트 스크립트 실행결과에 대해 질문 있습니다.

감바스님 안녕하세요~우선 첫번째 질문주신 내용은 아래 내용으로 봤을 때 2000번에 근접하게 찍히고 있는 것 같은데, 혹시 제가 질문의 의도를 잘못 이해한건지 확인해주시면 감사하겠습니다~ 1000번으로 찍힌걸 발견하지 못해서요 ㅠ (사진) 2번 질문에 대한 내용은 말씀해주신 내용이 정확합니다~!

파라미터 활용하여 테스트 하는 부분 질문 있습니다.

BeakGwa님 안녕하세요~인프런 AI 인턴이 잘 답변해준 것 같은데, 1번은 말씀하신 이유가 맞습니다. 동일한 값으로만 요청했을 때 캐싱으로 인해 테스트가 제대로 되지 않을 우려가 있어서 여러개 중 랜덤한 값을 사용한겁니다.2번의 "어느정도의 데이터"를 사용해야할지는 사실 정해진 내용은 없습니다. 다만 강의에서 이야기드린 것처럼 최대한 "실제와 유사한 형태의 데이터"로 요청이 이루어질 수 있도록 만들기 위해 노력합니다. 필요하다면 스크립트를 작성해서 랜덤한 데이터를 매 요청마다 만들어내서 요청하기도 합니다. 그리고 때론 캐시를 걸고, 캐시가 성능을 끌어올려주는지 테스트해보기도 하는데, 이럴때는 오히려 일부러 이미 요청된 데이터를 활용하기도 합니다. 이럴 때는 실제 트래픽 중 전체 요청 중 10% 정도가 캐시에 걸릴 것으로 기대된다면, 테스트 데이터 역시 10% 정도는 중복된 요청이 오도록 테스트 데이터를 조절할 필요가 있습니다. 궁금한 내용에 대한 답변이 됐을까요?또 궁금한 내용 있으면 질문 남겨주세요.감사합니다!

AWS 실습

Jin Jin님 안녕하세요~아마 해외 결제 승인이 안되어있다던지 하는 이유로 거절이 될 수 있을 것 같습니다. ㅠ(다른 이유일 수도 있어요)우선 다른 카드를 활용해서 등록할 수 없는 상황이라면 AWS EC2, RDS로 실습을 대체해도 괜찮습니다. 다만 실습시 조금 차이가 발생할 수 있는데, 이 부분은 ChatGPT를 통해 해결해보시거나, 막히면 질문 남겨주시면 답변 드리겠습니다~감사합니다.

api 요청 횟수와 시나리오 갯수에 대해 질문 있습니다.

감바스님 안녕하세요~ 위에 BeakGwa 님이 적어주신 것과 동일합니다! 너무 잘 설명해주셨네요.정확하게 몇번 실행되는지 단정할 수 없는 이유는 마지막에 적어주신 것처럼 weight를 줘서 실행할 수 있지만, 해당 weight에 따라 실행될 "확률"이 결정될 뿐, 실제 몇번 실행될지는 알 수 없습니다.동전의 앞면이 나올 확률이 1/2이지만, 10번 던져서 꼭 5번이 나오는게 아닌 것처럼요. 앞서 다른분이 질문하셨던 내용에도 해당 내용 설명해두어서 링크 첨부합니다~https://www.inflearn.com/community/questions/1383094/%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4%EA%B0%80-%EC%97%AC%EB%9F%AC%EA%B0%9C%EB%A9%B4-%EC%9A%94%EC%B2%AD%EC%9D%B4-%EB%B6%84%EB%A6%AC%EB%90%98%EB%8A%94-%EA%B2%83-%EC%95%84%EB%8B%8C%EA%B0%80%EC%9A%94 혹시 추가로 궁금한 내용 있으면 질문 남겨주세요.감사합니다.

레디스에 대해서 질문드립니다.

안녕하세요, 김영빈님.다시 한 번 좋은 질문을 해주셔서 감사합니다.제가 캐시를 한 문장으로 설명한다면, "비용이 높은 작업을 비용이 낮은 작업으로 대체하는 것"이라고 표현할 수 있을 것 같습니다. 여기서 비용이 높은 작업은 데이터베이스(DB)에 대한 I/O이고, 비용이 낮은 작업은 Redis에 대한 I/O입니다.말씀하신 것처럼 Redis도 I/O를 발생시키고, 그 동안 대기 시간이 발생하는 것은 동일합니다. 그러나 여기서 주목해야 할 점은 I/O의 종류와 비용이 다르다는 것입니다. 특히 DB에 대한 I/O는 Redis에 대한 I/O보다 비용이 더 높습니다.그 이유는 DB가 일반적으로 데이터의 원천(Source) 역할을 하기 때문입니다. 데이터베이스는 트랜잭션 처리, 데이터 무결성 및 일관성 유지 등 다양한 강력한 기능을 제공합니다. 우리가 작성하는 애플리케이션 로직은 이러한 무결성과 일관성에 기반하는 경우가 많습니다.따라서 원래 DB가 처리해야 할 부하를 다른 시스템이 대신 처리해준다면, 그것만으로도 전체 시스템의 성능을 크게 향상시킬 수 있습니다. 이 역할을 일반적으로 "캐시"가 수행하며, 애플리케이션 간에 공유되는 캐시 저장소로 Redis가 자주 활용됩니다.Redis를 사용하는 것이 효과적인 경우는 다음과 같습니다:빈번한 동일 데이터 조회: 동일한 데이터를 반복적으로 조회하며, 데이터 변경 빈도가 낮은 경우.데이터베이스 부하 감소 필요: 데이터베이스에 과도한 부하가 걸려 성능 저하가 발생하는 경우.실시간 처리 요구사항: 매우 낮은 지연 시간이 필요한 실시간 애플리케이션의 경우.이렇게 Redis를 활용하면 DB에 대한 직접적인 접근을 줄이고, 전체적인 성능 향상을 기대할 수 있습니다. 물론 Redis를 도입할 때는 데이터 일관성, 캐시 적중률, 운영 비용 등을 종합적으로 고려해야 합니다. 마지막에 이야기 해주신 것처럼 그리 비용이 높지 않은 작업이라면 Redis를 도입할 필요가 없을 수도 있겠습니다. 😄 답변이 됐을까요? 참고로 다음 강의는 안정적인 서비스 배포를 위한 배포 전략에 대한 강의로, 아마 이달 내로 오픈될 것 같습니다. 강의 마지막까지 수강하느라 고생 많으셨고, 앞으로도 좋은 질문 기대하겠습니다.감사합니다.