전체 글
-
Kotlin Arrow CircuitBreakerKotlin/Arrow 2025. 8. 2. 19:50
서킷브레이커의 메소드는 protectEither와 protectOrThrow가 있습니다.protectEither 는 내부에서 protectOrThrow를 호출하고 있고, catch로 exception을 잡은 다음 Left로 리턴하고 있습니다.서킷브레이커의 초기 상태는 Closed 이기 때문에 when 절의 Closed를 보면호출했던 람다 파라미터를 실행하고 right() 를 호출하여 Either로 감싸고 있습니다.람다로 감싸진 결과 값은 markOrResetFailures 메소드의 파라미터로 들어가게 되고해당 메소드는 Closed 상태에서 Right 인지 Left 인지 확인 후 이후 로직을 실행합니다.여기서 protectOrThrow 또는 protectEither 에 넣는 람다 메소드가 Either를 리..
-
Garbage Collector, GCJAVA/ETC 2024. 3. 28. 01:47
JVM에서 동적으로 할당된 메모리를 관리하는 구성 요소. 더 이상 사용되지 않는 객체를 식별하여 제거하여 메모리 누수를 방지하고 프로그램 성능을 최적화 함. 작동 방식 1. 객체를 추적 및 식별하여 객체의 상태를 모니터링함. 2. 객체의 참조를 카운트하며 더 이상 참조되지 않는지를 결정하기 위해 분석함. 3. 더 이상 참조되지 않는 객체를 식별하여 메모리에서 제거 (주로 힙 메모리) 4. 위에서 제거를 하여 메모리를 회수하여 다시 사용할 수 있는 메모리로 반환. --- 1. 힙 메모리는 Young Generation, Old Generation 2개로 나뉜다. 2. Young은 또 Eden, Survivor0, Survivor1 3개로 나뉜다. 3. 모든 객체의 생성은 Eden에서만 생성된다. 4. Ed..
-
데이터 적재 시스템 구축슬기로운 개발생활 2024. 2. 5. 19:41
신규 데이터 분석을 위해, 선발된 데이터들을 BigQuery와 Mixpanel에 등록해야 한다. ■ As-is BigQuery에 주기적으로 데이터를 insert, update해야한다. EC2 to BigQuery는 전송 가능하지만, EC2 to Mixpanel은 보안상 전송할 수 없다 ■ Challenge 주기적으로 데이터를 전송하도록 Jenkins Scheduler사용. BigQuery to Mixpanel로 데이터를 전송하도록 결정. GCP의 vm instance에 cron으로 GCP Scheduler 사용. bq 명령어를 사용하여 Buckit에 전송 데이터 적재. Cloud Function의 Trigger를 사용하여 Buckit Update시 Mixpanel로 데이터 전송. ■ To-be 신규 데이..
-
백오피스가 필요해요!슬기로운 개발생활 2024. 2. 5. 18:53
50개가 넘는 외부 업체와 1명의 Biz팀이 소통을 하는데, 백엔드팀 작업일 경우가 많았다. ■ As-is 외부 업체의 요청중 백엔드팀의 작업이 필요한 작업이 많다. 백오피스가 없어 Biz팀이 직접 작업을 할 수 없다. 백엔드팀의 업무가 많아져 실시간으로 처리를 할 수 없다. Biz팀은 외부 업체와 백엔드팀 사이에서 조마조마 기다릴수 밖에없다. 백엔드팀에서도 데이터베이스를 직접 Query를 입력해야 해서 휴먼에러가 발생할 확률이 높다. ■ Challenge 해당 서비스를 사용할 Biz팀과의 인터뷰를 통해 백오피스를 만들기로 결정. MSA환경의 모든 서비스와 통신해야하고, 추후 통신관련이 계속 변경될 수 있기 때문에 Hexagonal 아키텍쳐 적용. 변경 이력을 저장하고, 롤 백도 할 수 있어야 한다. 변..
-
API가 없는 회사와의 통신슬기로운 개발생활 2024. 2. 5. 18:31
회사의 신규 서비스 개발 중 외부 업체의 비지니스 로직을 통한 계산이 필요한 기능이 필요했다. ■ As-is 외부 업체는 IT업체가 아니기 때문에 사내 개발자와, API 서버가 존재하지 않는다. 외부 업체는 제휴를 통해 계속해서 늘려나가야 한다. (다른 외부 업체는 개발자와 API서버가 존재할 수도 있다.) ■ Challenge 외부 업체에서 만들어야 할 시스템을 우리 회사 내부 로직으로 만들기로 하였다. 기준 데이터들과 도메인 지식을 활용하여 내부 로직으로 구현. 기준 데이터가 주기적으로 변경되기 때문에 로직에 직접 넣는 것이 아닌 RDB에 값을 넣고 확인. 추후 통신을 할 수 있는 외부 업체가 있을수도 있으니, 통신이라는 Interface를 사용하여 Factory Pattern으로 작성. 외부 업체의..
-
Spring Cloud Feign - 2. Feign을 사용하여 통신하기Spring Cloud/Spring Cloud Feign 2024. 1. 29. 17:37
서버 2개를 띄우고 한쪽 서버에서 반대쪽 서버를 호출하여 값을 가져오도록 해보려 한다. 멀티모듈로 구성했습니다. 멀티모듈 관련해서는 이 글을 봐주세요! fegin 을 통하여 다른 서버에 요청할 프로젝트를 만든다. 요청받을 서버를 만들었다. http 통신이기 때문에 url 주소만 있으면 되므로 서버는 Feign이 필요가없다. Feign-client 모듈에서 FeignClient를 사용한다고 명시한다. 2개의 서버를 띄울것이기 때문에 main-server 모듈의 port를 8081로 변경한다. main-server는 feign-client든 다른 client든 상관없이 누구든 요청할 수 있도록 RestController를 작성한다. 데이터는 편하게 String 하나만 리턴하도록 하였다. main-server..
-
Spring boot for MSA - 2. Multi module Core적용하기Spring Boot/for MSA 2024. 1. 29. 17:07
MSA를 위해 Module을 나눴지만 Swagger, Security등 공통으로 적용될 설정들은 계속 새로운 모듈을 추가할때마다 복붙을 해야한다. 이런 것을 방지하기 위해, Core라는 별도 모듈을 만들어 이곳에 공통된 설정들을 집어넣고 이것을 각 하위 모듈에 지정하여 사용하도록 할 수 있다. 공통으로 사용할 모듈이름을 core라 짓고 security설정을 넣었다. core라는 모듈을 추가하고, settings.gradle에 include 한다. Core 모듈도 buld.gradle 외에 다른 설정파일은 삭제한다. 독립적으로 실행하지 않을것이기 때문에 Application.class도 삭제한다. 적용할 하위 모듈 build.gradle에 implementation(project(":core))로 해당 모..
-
Spring Boot for MSA - 1. intellij multi module 만들기Spring Boot/for MSA 2024. 1. 29. 16:42
MSA로 서버를 구성할 때 여러 서버를 동시에 띄워 테스트를 하려면 IDLE을 여러개 띄워 테스트를 해야한다. 위 같은 불편함을 없애기 위해 하나의 모듈안에 여러개의 모듈을 만들어 하나의 IDLE안에서 여러 서버를 띄우면서 테스트를 할 수 있는 환경을 만들어 보려고 한다 전체 모듈을 모을 상위 모듈을 생성한다. 상위 모듈은 따로 모듈을 가지고 있지 않을것이기 때문에 src는 삭제 한다. 하위에 넣을 모듈의 이름을 multi-module-sub1, sub2로 만들었다 하위모듈을 아까 src를 지웠던 상위 모듈 안으로 넣는다. 상위 모듈의 settings.gradle.kts 에 include로 하위 모듈 2개를 작성하고 Load Gradle Changes 버튼을 누른다. 하위 모듈로 등록되었다. 하위 모듈의..