Series 26

git branch 전략 + commit 기록 방법 선택하기

git branch 전략과 commit 방법은 이미 많은 레퍼런스가 존재합니다. 하지만 지금 내 환경에 적합한 전략을 선택하는 것은 조금 다른 이야기입니다. 이 글에서는 사이드 프로젝트를 진행하면서 내가 해본 선택 과정을 기록합니다. GitHub - Our-Class-Bank/core-backend: [side-project] 우리반은행 [side-project] 우리반은행. Contribute to Our-Class-Bank/core-backend development by creating an account on GitHub. github.com 배경 github repository 에서 1인 백엔드 개발 프론트 개발은 별도의 repository 사용 dev, prod 배포 환경 지원 필요 전략 선택..

Spring cache 는 어떤 provider 를 사용하는 것이 좋을까?

회사에서 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 ..

Series/실전! 2023.04.02

RandomCode Generator 성능 측정하기

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

Series/실전! 2023.01.11

스프링 마이크로서비스 코딩 공작소 (2)

GitHub - Hyune-s-lab/optima-growth: 스프링 마이크로서비스 코딩 공작소 스프링 마이크로서비스 코딩 공작소. Contribute to Hyune-s-lab/optima-growth development by creating an account on GitHub. github.com Phase 1 3. 스프링 부트로 마이크로서비스 구축하기 4. 도커 https://hyune-c.tistory.com/53 Phase 2 5. 스프링 클라우드 컨피그 서버로 구성 관리 6. 서비스 디스커버리 이 글입니다. eureka-server 구현 유레카는 클라이언트의 생존 여부를 체크하여 API 게이트웨이의 라우팅을 돕습니다. eureka-server // build.gradle.kts depen..

스프링 마이크로서비스 코딩 공작소 (1)

GitHub - Hyune-s-lab/optima-growth: 스프링 마이크로서비스 코딩 공작소 스프링 마이크로서비스 코딩 공작소. Contribute to Hyune-s-lab/optima-growth development by creating an account on GitHub. github.com Phase 1 3. 스프링 부트로 마이크로서비스 구축하기 4. 도커 이 글입니다. Phase 2 5. 스프링 클라우드 컨피그 서버로 구성 관리 6. 서비스 디스커버리 https://hyune-c.tistory.com/54 새로 입사한 회사는 제가 생각한 것보다 훨씬 서비스 구분이 많았습니다. 솔직히 이렇게까지 세분화 해야되나? 라는 생각이 들 정도였습니다. 마이크로서비스는 잘 쓰면 높은 생산성과 장애 ..

[트러블 슈팅] ECS 클러스터 안의 서비스간 네트워크 연결 불가

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

Series/실전! 2022.09.24

Repository 가볍게 관리하기

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 성격이기에 그리드 형태의 조회 로직이..

Series/실전! 2022.08.01

ErrorMessage를 관리하는 방법

GitHub - Hyune-c/blogcode-errormessage Contribute to Hyune-c/blogcode-errormessage development by creating an account on GitHub. github.com HTTP status code는 3자리의 코드와 설명으로 표현됩니다. 하지만 실무에서는 더 많고 다양한 종류의 에러 표현을 위해 name, code, reason을 활용하곤 합니다. 그리고 간결함과 생산성을 위해 프로젝트 내에서도 code와 reason이 직관적으로 연결되기를 기대합니다. STEP 1. Enum으로 관리하기 @Getter @RequiredArgsConstructor public enum Errorcode { NOT_EXIST_PRODUCT("..

레거시 코드 개선하기 with delegate pattern

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. 코드 개선 버킷..

Series/실전! 2022.06.05

현재 환경에 맞는 값을 가져오기 with enum

로직은 같지만 개발과 운영에서 필요한 값이 다른 경우가 있는데, 대표적으로 url이 있습니다. 지금의 회사에서는 enum을 통해 관리하고 있지만, 그 방식이 enum 스럽지 않다고 생각하고 있었습니다. 그러던 중 기존 test - dev - stage - prod로 구성되었던 환경이 dev - qa - stage - prod로 변경되었고, 이 과정에서 코드를 개선한 내용을 기록해 봅니다. Before 환경 변수 enum public enum DeploymentEnvironment { DEV, QA, STAGE, PROD; private static final String AUTH_SERVER_NAME = Optional.ofNullable(System.getenv("AUTH_SERVER_NAME")) ...