보배로움

k6 문서를 읽다보니 테스트 종류에 대한 글이 눈에 들어왔다. Load test types | Grafana k6 documentationLoad test types Many things can go wrong when a system is under load. The system must run numerous operations simultaneously and respond to different requests from a variable number of users. To prepare for these performance risks, teams use load testing.grafana.com서버 성능 테스트에도 종류가 여러가지 있음에도 보통 Load Testing만 해왔던 것 같다.공부하..

SLI (Service Level Indicator)서비스 수준을 측정하는 실제 지표 => "무엇을 측정할 것인가?"Example요청 성공률: (성공한 요청 수 / 전체 요청 수) × 100%응답시간: API 응답 시간의 p95 값시스템 가용성: (전체 시간 - 장애 시간) / 전체 시간 × 100% SLO (Service Level Objective)SLI에 대한 목표치 => "어느 수준을 달성할 것인가?"Example월간 가용성 99.95% 이상 달성API 응답시간 p95가 300ms 이하분당 에러율 0.1% 미만 유지 SLA (Service Level Agreement)서비스 제공자와 고객간의 공식적인 계약 => "고객에게 어떤 서비스 품질을 보장할 것인가?""계약"이므로 위반 시 보상조항이 포함됨..

메트릭 혹은 성능 테스트 결과를 보다보면, 많이 볼 수 있는 숫자가 있다.P90, P95, P99 이 숫자가 의미하는 것은 무엇일까? => 바로 백분위수(Percentile)이다.백분위 수는 전체 데이터를 순서대로 나열했을 때, 특정 위치의 값을 의미한다.p90은 90번째 백분위수라는 의미로 전체 데이터 중 90%가 이 값보다 작다는 의미이다.예를 들어, Resposne time이 p90 = 200ms라면, 전체 요청 중 90%는 200ms보다 빠르게 처리된다는 것. Percentile / 백분위수의 필요성그럼, 왜 p90, p95, p99을 나눠서 볼까?p90: 상위 10%를 제외한, 일반적인 상황의 성능을 보여준다p95: 상위 5%를 제외한, 조금 더 엄격한 기준의 성능을 보여준다p99: 상위 1%를..

Trace를 학습하다보면 "Sampling", "샘플링"에 대해 필수적으로 알아야 한다.근데 주변에서 가끔 헷갈려하시는 분들이 있어 글로 좀 정리해보자 한다.본 글의 내용은 아래 Opentelemetry 공식문서 글을 참조했다. SamplingLearn about sampling and the different sampling options available in OpenTelemetry.opentelemetry.io Sampling? 샘플링?Sampling / 샘플링모든 가시성 지표를 저장하지 않고, 대표적인 데이터만(대표성을 띄는 데이터만) 저장하는 것'대표성'이라는 건 작은 그룹이 더 큰 그룹을 정확하게 대표할 수 있다는 원칙 (위 그림이 이를 잘 표현하는 그림) "Sampling 됬어?" 같은 ..

"기술은 끊임없이 변화하지만, 성장의 본질은 변하지 않는다"IT 업계에서 일하면서 이런 책이 진작 있었더라면 하는 아쉬움이 들 정도로 유익한 내용들이 많았습니다. 책 목차책은 총 6부로 구성되어 있습니다:1부: 개발자 커리어의 기본 사항2부: 유능한 소프트웨어 개발자3부: 다재다능한 시니어 엔지니어4부: 실용주의 테크리드5부: 롤모델로서의 스태프 및 수석 엔지니어6부: 결론 마음에 들었던 점실용적인 조언들각종 실전 팁들이 현장감 있게 서술되어 있습니다.특히 코드 리뷰, 프로젝트 관리 부분은 바로 적용해볼 수 있는 내용들이 많았어요.균형 잡힌 시각기술적 역량과 소프트 스킬의 균형을 강조합니다.'사람'과 '기술' 사이의 조화를 잘 다루고 있어요.성장 단계별 가이드각 레벨에 맞는 기대치와 역량이 명확히 제시되..

오늘은 Github issue 내용을 Github 파일로 동기화 시키는 Github action 개발기를 이야기 해볼까 해요.오늘 이야기 할 Github action은 Marketplace에서 확인 및 사용할 수 있어요. Issue to File Sync - GitHub MarketplaceSync GitHub issues to files with customizable paths and labelsgithub.com 개발 동기 개발자들은 Github repository에 문서를 모아두기도 하고, 블로그를 운영하며 글을 작성해두기도 해요.저 또한 마찬가지였어요. 문서를 정리해 Github repository에 올려두기도 하고(지금은 미사용 중이긴 하지만) github.io 블로그가 있어 해당 글을 작성할..

이 글을 통해 SBOM 대한 생각을 정리하고, 여러 툴들을 이용해 SBOM을 만들며 보안 이슈를 확인해볼까 해요.간단히 만들어 보는 과정만을 담고 있으므로 SBOM 생성/분석 툴들의 상세한 옵션들은 다루지 않을게요. SBOM이란 무엇일까요?SBOM은 Software Bill of Materials의 약자예요.Maven을 사용해보신 개발자라면 BOM이라는 단어 그리고 Bill of Materials는 많이 접해보셨을 텐데요.단어 뜻 그대로 "자재명세서"를 의미해요. '어떤 소프트웨어가 무엇으로 이루어져있지?'한다면 Bill of Materials를 통해 '아 이런 소프트웨어들이 내포되어 있구나!'라는 것을 알 수 있어요.이러한 Maven BOM을 이용하여 여러 라이브러리들의 의존성 버전을 관리하고, 라이브..

정석'정석'이라고 하면 무엇이 먼저 떠오르시나요?저는 '수학의 정석' 책이 생각납니다.뭐랄까... 당연히 정수를 모아놓은 책이여서 좋은 책이긴 한데...개인적으로 사전(Dictionary) 같은 느낌이라 손이 쉽게 가지 않던 책이었습니다.(막상 내용은 사전은 아니였지만요)   이번에 읽은 책은 '소프트웨어 설계의 정석' 입니다.설계에 대한 책을 읽어본 적은 없었던 것 같아 도전을 하게 되었는데요.책 외관을 보았을 때 '수학의 정석'과 같이 투박한 형태는 아니여서 안심하며 책을 펼치게 되었습니다.  소프트웨어 공학책을 읽다보니 소프트웨어 설계를 어떻게 할 것이며, 어떤 방법들이 있고, 외/내부 설계 등책에서 다루는 내용들이 대학 시절 수강했던 '소프트웨어 공학' 과목과 겹쳐서 그 때 기억이 많이 났습니다...