recordException을 지정하지 않았을때 동작 방식 질문

soap님 오래 기다리셨습니다! 관련해서는 https://resilience4j.readme.io/docs/circuitbreaker#failure-rate-and-slow-call-rate-thresholds 에 아래와 같은 내용이 있습니다. Failure rate and slow call rate thresholdsThe state of the CircuitBreaker changes from CLOSED to OPEN when the failure rate is equal or greater than a configurable threshold. For example when more than 50% of the recorded calls have failed.By default all exceptions count as a failure. You can define a list of exceptions which should count as a failure. All other exceptions are then counted as a success, unless they are ignored. Exceptions can also be ignored so that they neither count as a failure nor success.The CircuitBreaker also changes from CLOSED to OPEN when the percentage of slow calls is equal or greater than a configurable threshold. For example when more than 50% of the recorded calls took longer than 5 seconds. This helps to reduce the load on an external system before it is actually unresponsive.The failure rate and slow call rate can only be calculated, if a minimum number of calls were recorded. For example, if the minimum number of required calls is 10, then at least 10 calls must be recorded, before the failure rate can be calculated. If only 9 calls have been evaluated the CircuitBreaker will not trip open even if all 9 calls have failed. 즉, Resilience4j에서 구현한 서킷 브레이커는 기본적으로 모든 예외(RuntimeException, Error 포함)를 실패로 간주합니다. 여기서 특정 예외를 recordException로 지정했을 때는 해당 예외의 하위 예외들로 실패로 간주되는 예외의 폭이 줄어드는 겁니다. 혹시 추가적으로 궁금한 내용 있으면 질문 남겨주세요!감사합니다.

Latency에 대한 질문이 있습니다!

김정우님 오래 기다리게해서 죄송합니다.관련해서 답변 드리겠습니다. 우선 Artillery는 FTTB(First Time To Byte)가 아닌 전체 패킷이 수신된 후를 기준으로 지연 시간을 계산합니다. 따라서, 스트리밍 서비스에서 오는 데이터 사이즈가 크다면 네트워크 대역폭에 따라 FTTB와 Atrillery가 계산한 지연 시간 사이에 꽤 큰 차이가 발생할 수 있습니다. 이 상황에서 어떤걸 목표로 삼을지는 어떤 서비스, 어떤 스트리밍 데이터인지, 어떤 성능을 튜닝하려고 하는지 등 개발자가 정해줘야할 것 같습니다. 만약 데이터 사이즈가 크다면 FTTB는 서버와 클라이언트 사이의 네트워크 지연 시간을 측정하는 데에만 참고로 활용하고, 실제 사용자가 체감하는 지연 시간은 패킷이 전체가 전달되는게 중요한 서비스라면 튜닝 대상을 패킷 전체가 전달되는 '전체응답을 다 수신한 뒤 지연율'을 타겟으로 튜닝을 해야할 것 같습니다. 다만 FTTB가 성능 튜닝의 목표가 되어야하는 서비스라면 Atrillery 말고 FTTB를 측정하고 모니터링할 수 있는 성능 테스트 툴을 사용해보시면 좋을 것 같습니다. 또한 전체 응답이 느려지더라도, 사용자가 FTTB만 충분히 빠르다면 서비스가 빠르게 동작하고 있다고 인지할 수 있는 UX를 만드는 것도 중요한 것 같습니다. 빨리 수신되어야하는 데이터와 사이즈가 큰 데이터를 구분하는 형태로요. 결과적으로 지연율을 어떤 기준으로 표기해줄지는 선택의 문제라고 생각됩니다!질문주신 내용에 대한 답변이 됐을까요?또 궁금한 내용 있으면 질문 남겨주세요.감사합니다.

recordException을 지정하지 않았을때 동작 방식 질문

soap님 안녕하세요!제가 현재 해외에 나와있어서 내일 복귀하는대로 답변 드리겠습니다.감사합니다.

Latency에 대한 질문이 있습니다!

김정우님 안녕하세요!제가 현재 해외에 나와있어서 내일 복귀하는대로 답변 드리겠습니다.감사합니다.

로그 레벨을 기준으로 알람 설정할 때, Kibana를 사용할 수 는 없나요?

denia park님 안녕하세요!질문 주셔서 감사합니다. 아래 AI 인턴이 잘 답변해줬는데, 현재 기준으로는 Kibana 무료버전에서도 자체적인 알람 기능을 제공합니다. Alerting 이라는 기능으로 사용할 수 있고, 관련된 내용은 아래 링크 참고해보시면 좋을 것 같습니다. https://www.elastic.co/guide/en/kibana/current/alerting-getting-started.html 강의 내에서 해당 기능을 활용하지 않고, Elasticsearch로 직접 쿼리를 날려서 확인하는걸 보여드린 이유는 Alert 기능으로 설정시 알람을 받아볼 대상을 지정하는 실습이 필요한데 이 부분까지는 강의에서 설명하려는 '로그 레벨'에 따른 알람 설정에서 벗어나는 내용인 것 같아서 간단히 포스트맨으로 aggregation이 가능하다는 것만 보여드리려고 현재처럼 구성했습니다. 🙂 강의 내용만 봤을 때는 Kibana는 해당 기능을 제공하지 않는 것처럼 오해하셨을 수도 있을 것 같습니다. 이 부분 혼동드려 죄송합니다. (_ _) 혹시 추가로 궁금한 내용 있으면 질문 남겨주세요.강의 잘 봐주셔서 감사합니다!

안녕하세요

wnsqud70님 안녕하세요~이 문제는 제가 직접 확인해봐야 할 것 같습니다. ㅠ혹시 괜찮으시다면, lleellee013@gmail.com 으로 메일 부탁드리겠습니다!

표준출력보다 Slf4J가 느릴 때

dlsrksrhk님 강의 내용에서 더 심화된 분석 글 감사합니다!AsyncAppender에 대한 내용도 언급할까 하다가 환경에 따라 차이가 나지 않을 수도 있어서 다루지 않았는데, 테스트 해주신 것처럼 표준출력이 오히려 빠른 경우 AsyncAppender로 변경했을 때 표준출력보다도 빨라질 수 있습니다.마지막에 이야기 해주신 것처럼, 성능 문제를 떠나서 로그 관리 차원에서 로깅 프레임워크 활용하는게 좋고, 실무 환경이라면 표준 출력이 경쟁적인 상태가 될 거라 로깅 프레임워크를 활용하는게 더 높은 성능을 보일겁니다. 😀남겨주신 내용은 제가 강의 노트란에도 추가해두겠습니다~감사합니다!!

강의 내용을 어느 정도로 파악하고 있는 것이 좋을까요?

형씌님 안녕하세요.우선 질문 주셔서 감사합니다. 프로그래밍을 처음 했을 때로 돌아가보면, 처음에는 하나씩 따라해보면서 문법을 익히고, 그 과정을 이해하면서 자연스레 문법들이 외워졌던 것 같습니다. 물론 처음에 잘 외워지지 않더라도 계속 반복해서 비슷한 코드를 작성하다보니 어느 순간 외워졌던 것 같아요. if 문은 조건식이 참일때 실행이 된다던지,for 문에는 초기식, 조건식, 증감식 순으로 넣어야 한다던지,변수에 대입은 = 로 하고, 실제 동일한지 비교는 ==로 한다던지 같은 것 처럼요. 제가 비록 형씌님이 얼마나 많은 프론트엔드 코드를 작성했는지 알지는 못하지만, 분명 이런 문법들 역시 반복해서 학습하고 작성하다보면 충분히 외워질겁니다. 다만 이걸 지금 꼭 외우고 넘어가야하는가 하면 저는 그렇지는 않은 것 같아요.백엔드 개발자라면 백엔드 개발과 관련된 부분에 좀 더 힘을 싣고 학습하는게 좋을 것 같습니다.프론트엔드 코드는 저도 아직 검색하여 작성하는 경우가 많습니다. 저도 자주 작성하지는 않거든요.물론 강의에서 사용한 코드 정도는 저도 대개는 외워서 작성하는 경우도 있긴 하지만, 이 외의 코드들은 상대적으로 IDE의 도움을 적게 받으면서 작성하는건 아직도 어렵습니다. 만약 프로그래밍 자체를 처음 배우는 사람이라면 외워서 작성할 수 있을 때까지 작성해보라고 권해드리겠지만, 지금 이미 백엔드 언어로 프로그래밍을 하고 계시기 때문에 그럴 필요는 없이 검색해서 작성할 수 있을 정도여도 괜찮을 것 같습니다. 길게 이야기 드렸는데, 혹시 또 궁금한 내용 있으면 질문 남겨주세요.감사합니다.

getStackTrace의 속도가 더 느리게 나옵니다

권선님 안녕하세요~실행 환경이 달라서 정확하게 비교가 된건지는 모르겠지만, 원래라면 getStackTrace가 더 빠르게 실행될 가능성이 높습니다. 권선님이 실행한 것처럼 결과가 나오는건 저도 현재 상태론 정확한 이유는 알 수 없네요 ㅎㅎ..다만, 설령 printStackTrace의 성능이 권선님께서 테스트 해보신 것처럼 조금 더 빠르더라도, 큰 차이는 아니고 예외를 더 적절히 로깅할 수 있다는 측면에서 getStackTrace를 사용하는게 더 좋을 것 같습니다. 궁금하셨던 내용인 getStackTrace의 속도가 더 느리게 나온 이유에 대해 속 시원한 답변을 해드리지 못해서 죄송합니다. (_ _)

블로그 포스팅 질문

Chan님 안녕하세요.강의 내용 정리해서 포스팅 하셔도 괜찮습니다~다만, 글에 강의 출처 남겨주시면 감사하겠습니다. (_ _)