메세지 서버에 스케쥴용 컨슈머를 설계하다 보니 1cpu, 2G 메모리에 만약 대량 발송 + 스케쥴 발송이 겹치는 경우 버틸 수 있을까에 대한 생각으로 그러면 기존 코루틴에 버츄얼 스레드를 추가하면 더 효율이 나오겠네??? 라는 생각으로 찾은 내용이다.결론 - 아니다

Aurora MySQL의 binlog를 실시간으로 캡처하여 S3에 구조화된 데이터로 저장하는 서버리스 CDC(Change Data Capture) 파이프라인이 프로젝트는 Aurora MySQL 데이터베이스의 모든 데이터 변경 이벤트(INSERT, UPDATE, DELE
관련 링크: Datadog Summit Seoul 후기(velog)Datadog Learn(무료) 코스에서 SLI를 정의하고 SLO를 설정한 뒤, SLO 위반 시 알림 전파와 담당자 자동 할당까지 구성했다.SLI 정의APM 기반: HTTP 상태코드(2xx/5xx)를 기
프로젝트 개요 기존 RDS(MySQL) 환경에서는 여러 테이블의 히스토리성 데이터(감사 이력, 변경 로그 등)를 각각 별도의 테이블에 저장해 관리하고 있었습니다. 감사 로그(히스토리 데이터)는 저장 빈도는 높고, 조회 빈도는 낮아 RDS의 저장/운영 비용과 성능 측면에서 비효율적이었습니다. 데이터 관리 일관성과 운영 효율성을 위해 DynamoDB 기반 이...
Dockerfile에서 apt-get update && apt-get install -y curl 실행 중 아래와 같은 오류가 발생했다:Debian 10 (buster)은 2024년 기준으로 EOL(지원 종료)되어 공식 저장소에서 제거되었기 때문에, apt-get up
최근 코딩테스트를 준비하면서 아래와 같은 문제를 자주 느꼈다:문제를 보고도 접근 방식이 떠오르지 않음AI가 짜준 코드는 동작하지만, 왜 그렇게 구현되는지 모름비슷한 문제를 다시 풀려고 하면 스스로 구현하지 못함기본 개념이 부족하니 디버깅도 어려움이 과정에서 AI 자동완
Kotlin Coroutine 환경에서 대량의 FCM Push 메시지를 처리할 때,많은 예제나 문서에서는 Dispatchers.IO를 사용하는 것을 기본으로 제시합니다. 그러나 실무에서는 다음과 같은 이유로 커스텀 ThreadPoolTaskExecutor를 Corout
도입: 왜 큐를 고려하게 되었는가?메시지 서버를 설계하면서 처음에는 HTTP 기반의 요청 처리를 고려했습니다. 하지만 HTTP는 클라이언트의 요청 수에 따라 서버가 직접 응답해야 하므로, 서버의 처리 능력과 상관없이 부하가 한순간에 몰릴 수 있는 위험이 있습니다.
이슈 위에 이미지는 앱 푸쉬 발송 워터플이다. 원인 스펙 vCPU: 1 Memory: 2G 원인 firebase-admin-java를 9.2.0 이후 버전 부터 이슈 발생 기존 버전의 경우 sendAll 메서드를 사용할댸 SDK 자체에서 http 요청을 batch
테스트하는 모듈에 @SpringBootApplication 이 없어서 발생테스트 패키지에 아래 추가
핫픽스 건으로 배포할때 실제 개발 수정시간은 1분이더라도 배포하는데 5분이 걸리면 실제 운영까지 적용되는 시간은 최소 6분이다.크리티컬 이슈의 경우 무엇보다 속도가 중요한데 이럴때 배포 버튼만 누르고 기다리면 답답했던 경우가 있었다해결 방법은 배포 플로우중에 테스트 부

말 그대로 베이스를 재배치 브랜치의 시작점을 재설정branch의 변경사항을 최신 상태로 유지가 가능커밋 라인을 정리하여 히스토리를 깔끔하게 유지리베이스 사용법최근 3개의 커밋을 interactive rebase 한다wq 로 저장 종료현재 “0번 feature - 커밋
비동기가 왜 필요한가?2개의 쿼리 조회시 속도가 너무 느려 사용 최대 로컬에서 500ms 발생적용해도 문제 없나?쿼리 자체가 개별적으로 동작하는 쿼리라 이슈 없음왜 느린가?외부 서비스에 요청해서 결과값을 가져오는데 이때 속도가 이슈결과운영에서 평균 80ms참고 : ht
jpa 에서 쿼리 작성 후 해당 쿼리의 count 를 가져올때 동일한 조건을 또 써야되서 불편해서 추가한 확장 함수
가능하면 사용안하는게 좋은것 같다.1\. 명시적이지 않다. 필수 값인지 그냥 사용해도 되는지2\. 휴먼 에러 만약 실수로라도 값을 입력하지 안은경우 오류 발생 가능아래는 배포후 다른 작업의 오류를 같이 찾으면서 경험 했던 내용이다.상품 정보가 정상적으로 나오지 않았던
Open Session In View 개인적인 생각을 먼저 말하면false 로 사용하는게 좋을것 같다. false -> true 변경은 크게 이슈가 없지만, true -> false 변경시 프로젝트에서 어떤 사이드 이펙트가 발생할지 모른다.이전에 프로젝트를 진행했을때
사내 결제서비스 연동후 몇건의 time out 오류가 발생 하였다.aws gateway 의 idle time이 api 요청시의 time out 시간보다 짧은 경우결제 요청을하는 도메인의 time out 시간이 결제 도메인의 time out 시간보다 짧은 경우 -> 결제
오류 모니터링으로 인증 오류 알림이 와서 오류 확인 후 로그에 있는 JWT 확인을 했을때 비정상적인 인증 토큰으로 요청해당 JWT를 풀어 봤을때 타사의 도메인이 나왔으며, user-agent를 확인했을때 POSTMAN으로 요청한 내용을 확인가능성은 매우 적지만 JWT