개린이의 일기장

회사에서 local cache 를 사용할 일이 생겼습니다. 동료분이 guava 를 알려주셨고 처음 들어보았기에 일단 baeldung 을 검색해 보았는데 조금 이상했습니다. https://www.baeldung.com/guava-cache 캐시를 사용할 때 익히 쓰던 @Cacheable 어노테이션이 보이지 않았습니다. 그래서 익숙하던 ehcache 를 검색해 보면서 비교해 봤습니다. The difference between Ehcache and Guava Cache - actorsfit Recently, I have been doing some cache transformation scenarios, and there are some experience summaries as follows: Cached ..

일련번호는 총 16 자리의 숫자/영문 대문자로 이루어진 문자열이다. 최근 회사 업무를 하던 중 기존에 작성된 무작위 일련번호를 만드는 로직을 보게 되었습니다. 간단한 업무 내용에 Util 성격의 로직이었지만, 구현된 로직은 생각보다 복잡했습니다. 그래서 기존 로직의 의도를 파악하고, 개선을 시도해 보았습니다. 먼저 결론을 공유하고, 시도한 개선을 따라가 보겠습니다. 결론 (각 1만, 10만, 50만, 100만 회 반복) ThreadLocalRandom 의 성능은 매우 뛰어나다. Kotlin Random 역시 뛰어나다. String 변환은 매우 비싼 작업이며 Sequence 가 효율적으로 작동하지 않을 수 있다. Coroutine 은 학습이 부족하여 적용하지 않았다. GitHub - Hyune-s-lab/..

글을 시작하기 전에 짧게 배경을 설명합니다. 필자의 인프라 지식과 경험은 아래와 같습니다. - [On-premise] 서버 이중화 구성 & 운영 경험 O - [AWS] EC2 기반의 Elastic Beanstalk 구성 & 운영 경험 O - [AWS] ECS 운영 경험 O EKS X - [AWS] VPC, 보안그룹, 인바운드 규칙에 대한 이해 - Docker 에 대한 이해 - MSA 개발에 대한 이해 O MSA 인프라에 대한 이해 X - 그리고 이 정도로 거대한 규모의 인프라는 처음 만져봄 저는 9/1 일 신생 PG 회사로 이직하면서 모기업의 승인&정산 업무를 배정받았고, 이전 담당자는 퇴사가 예정되어 있었습니다. 이 글을 쓰는 시점에 이미 퇴사하신 승인/정산은 어느 회사에서나 가장 민감한 도메인 중 하..

GitHub - Hyune-c/blogcode-repository-di: Repository 의존성을 가볍게 관리하기 Repository 의존성을 가볍게 관리하기. Contribute to Hyune-c/blogcode-repository-di development by creating an account on GitHub. github.com 작고 단순한 피쳐를 개발할 때는 크게 신경 쓰지 않던 것들이 공부하고 실무를 할수록 의문이 생기곤 합니다. 그중 하나인 Repository를 개발하면서 느낀 점을 기록해봅니다. 도메인 로직과 영속성 영역의 경계는 어디일까? 어떻게 하면 인적 실수를 줄이고 생산성을 높일 수 있을까? 지금의 회사에서 개발하는 애플리케이션은 B2B 성격이기에 그리드 형태의 조회 로직이..

GitHub - Hyune-c/blogcode-delegate Contribute to Hyune-c/blogcode-delegate development by creating an account on GitHub. github.com STEP 1. 개선 전 코드 https://github.com/Hyune-c/blogcode-delegate/commit/7ac445974e1fc497509813303d80151ce705ce1c AWS S3 조작을 담당하는 서비스로 개선 전 코드는 중복 코드와 확장성에 큰 단점을 가지고 있었습니다. 초기에는 연관된 로직이 적어 괜찮았지만, 그것을 감안하더라도 가독성과 확장에 취약한 코드였습니다. 그러던 중 S3 버킷 추가의 요건이 생겼습니다. STEP 2. 코드 개선 버킷..

이번에 회사 업무의 일부를 확장/분리하는 업무를 맡았습니다. 프로젝트의 세팅부터 해야 되는 작업이었기에 제가 주도적으로 개발할 수 있었는데요. 이 과정에서 작업한 Legacy의 공통 Util 리팩토링의 일부를 기록해봅니다. AS-IS의 문제점 // 0. 이 프로젝트에 의존적인 로직이 존재합니다. // ex) 입력 값이 파싱할 수 없는 isEmpty() 라면 빈 값을 반환. (에러가 아니라) @UtilityClass public class LocalDateUtils { // 1. LOCAL_DATE_FORMAT_WITH_HYPHEN, LOCAL_DATE_FORMAT 이 String 변수로 존재합니다. public static final String LOCAL_DATE_FORMAT_WITH_HYPHEN = ..

이 글에서는 널리 쓰이는 모니터링 솔루션 중 하나인 datadog을 적용하면서 알게 된 정보를 기록해봅니다. 공식문서에 있는 내용은 언급만 하고 넘어가며, 완결되지 않은 이슈들도 있기에 맛보기로 생각하고 읽어주세요! AS-IS 자동화된 모니터링 룰이 없으며, cloudwatch로 사후 모니터링만 가능. datadog를 도입하기로 했으나, graphql이 제대로 지원되지 않음. datadog 은 공식 문서가 잘 나와있는 편이기에 설치나 일반적인 세팅에는 어려움이 없었습니다. 특히 resource를 기반으로 제공되는 기능들이 강력해서 REST API를 쓰는 환경이라면 크게 어려움 없이 세팅이 가능했습니다. 하지만 당사에서 사용하는 graphql 은 resource 가 모두 POST /graphql로 통일되어..

요구 사항 정리와 AS-IS 분석은 끝났지만 설계하기 전에 개발 범위 산정과 제약 조건을 먼저 생각해야 합니다. 목표 달성을 위한 리팩토링은 끝이 없기에 일정과 범위를 조율해야 하고, 개인의 이해도는 차이가 있기에 실무의 설계는 범용적인 구성을 해야 합니다. 디자인 패턴 공부의 필요성을 느끼는 요즘입니다. 이런 생각을 가지고 개발한 과정을 기록해봅니다. 개발 범위 산정 최소 개발 범위는 심플하지만 앞으로 알림 톡의 종류가 많아질 것을 대비하면 AlarmGqlService의 호출도 interface로 만들고 내부 서비스들도 표준화시키는 것이 좋을 것 같습니다. 하지만 개발 범위를 AlarmGqlService까지 확장하면 입력부에 대한 검증과 interface 설계에 따른 리팩토링도 추가되어야 해서 '알림 ..

높은 응집도와 느슨한 결합도의 설계는 객체 지향을 공부하는 사람이라면 누구나 고민하는 주제입니다. 공부는 했었지만 부끄럽게도 잘 활용하지 못하던 중 같이 공부하는 로치의 글을 보고, 또 운 좋게 설계가 필요한 업무를 맡게 되면서 개발한 내용을 기록해봅니다. 응집도와 결합도 응집도와 결합도는 소프트웨어 품질을 결정 짓는 요소이다. 대다수의 사람들은 코드를 작성할때 "응집도" 와 "결합도" 를 생각하지 않은채 관성적으로 코드를 적고는 한다. 응집도와 결합도는 devroach.tistory.com 업무 배경 알림 톡 발송의 주체는 외부 업체로 Lambda를 통해 연동되어 있습니다. 발송 기록은 저장되고 있습니다. (백엔드 - RDB, Lambda - DynamoDB) 개발 요건 Lambda API의 주소가 변..

pagination은 백엔드 구현에서 가장 많이 고려해야 되는 기술 중 하나입니다. 일반적으로 알려진 pagination 기술에는 page, slice 가 있고 특수한 경우에 사용되는 noOffset과 Covering Index 기술이 있는데요. 이번 글에서는 실무에서 만난 특이한 pagination 사례에 대해 각색하여 기록해봅니다. 업무 요건 전체고 조회가 필요합니다. 상품군이 신설되었습니다. 기존에는 회사와 상품이 존재했으며 M:N 관계입니다. 상품군과 상품은 1:N 관계입니다. 상품군과 회사의 관계는 M:N 관계입니다. 서로 다른 재고처에 있는 재고를 합쳐야 합니다. 각 상품군별, 회사별로 소계를 보여주어야 합니다. 페이지당 300개 안팎은 허용 범위입니다. 기술적 배경 각 도메인별 조인이 많이 ..