컨테이너 기술 발달 컨테이너 기술이 발전함에 따라 현재는 많은 기업들이 쿠버네티스(이하 쿠버)를 많이 사용하고 있다 리눅스의 자원 격리 기술을 기반으로 컨테이너 기술이 생기고, 여기서 사람들이 많이 아는 현재의 도커가 모습을 드러냈다 시간이 지나면서 사람들은 더 많은 컨테이너를 관리해야 했고, MSA가 유행하는 현재는 쿠버네티스를 사용하기 정말 좋은 시대가 된 것 같다 쿠버네티스 종류 현재 사용해본 것만 기술하면 kubeadm과 minikube가 있다 kubeadm의 경우 멀티 노드 구성 및 다양한 기능을 사용할 수 있지만 설치 방법이 어렵다는 점이 있다 minikube는 반대로 kubeadm와 달리 초기 셋업은 쉽지만 kubeadm 만큼 기능이 다양하지 않다 제공되는 기능 컨테이너 자체 관리에 탁월하다..

15년에 클라우드 재단에서 쿠버네티스란 기술을 발표했다고 한다 (아는 척) 그리고 그 유행이 어느덧 우리나라에도 전파되어 많은 기업들이 적용했다고 한다 나는 최근에 이 기술을 적용해야 할 기회가 생겨서 긴급하게 공부를 했다 후기를 먼저 말하면, 정말 신세계였다 내가 젠킨스로 힘들게 구현한 롤링 배포 뿐만 아니라 블루/그린, 카나리까지 지원을 하고 수평/수직 오토 스케일링, 자동 복구, 전 버전 롤 백도 지원했다 예전에 짰었던 젠킨스 파이프라인이다... 복잡하지 않은가? 우리의 경우 WAS가 마스터/슬레이브인데 스케줄러가 마스터에만 있어서 조금 더 복잡한 파이프라인이 나왔다 그리고 먼저 배포되는 WAS에 문제가 생기면, 메인 파이프라인이 중단되고 롤백 파이프라인이 작동해서 전 버전으로 자동 롤백된다 근데 ..

게이트웨이 코드를 작성하다 보면, 이게 제대로 작동은 하는 것인가? 하고 의문이 들때가 있다 이러한 의문은 개인 프로젝트를 진행할 때뿐만 아니라 회사에서 동료들과 일할 때도 자주 떠올랐다 그리고, 비슷한 URI와 Route들의 순서 배열에 따라 몇몇 Route들이 동작하지 않기도 했다 길어진 Route 명세를 파악하기 위해 모니터를 위 아래로 훑는 시간도 많이 들고, 이 과정에서 실수할 소지가 많다는 것을 느꼈다 그래서 시간을 내서 리펙터링을 했고 성공적이었다 아래는 그때의 노하우를 좀 더 가다듬은 방식으로 진행한 것이다 문제의 YAML 명세 spring: cloud: gateway: routes: - id: ITEM-SERVICE uri: lb://ITEM-SERVICE predicates: - Pat..

내가 처음 리액티브를 많이 듣게 된 건 토비의 봄이었다 토비님도 이 Rx를 공부하는 데 많은 어려움이 있었고 몇 개월이 지나서야 감을 찾기 시작했다고 한다 Rx (Reactive Extensions)를 만든 MicroSoft 엔지니어들은 기존의 옵저버 패턴의 한계를 크게 2가지 지목했다고 한다 1. 도대체 이벤트는 언제 완료 되는가? 2. Error 핸들링을 어떻게 하는가? 옵저버 패턴에는 위 2개에 대한 기본 골조(아이디어)가 없다고 한다 이 2가지가 추가된 확장된 옵저버 패턴인 Observable이 Rx의 세 가지 축 중 하나의 축이 된다 (세 가지 축은 Observable, Scheduler, Observer를 말하는 것 같다) Reactive System 클라이언트와 맞장구를 잘 쳐주는 시스템 클..

11월말에 퇴사하고 12월에는 운동량이 부쩍 늘었다 ㅎㅎ 기록 규칙은 역시 마지막에 기록한 4세트만을 기록한다 (실제로는 더 많이 했다) (11월 20 월 부터 작성할것) 등 날짜 항목 볼룸 (부분 기록) 비고 11.2 목 언더그립 하이 로우 20kg * 15 30kg * 15 40kg * 12 10kg * 8 케이블 암 풀 다운 40kg * 12 20kg * 12 30kg * 12 40kg * 8 11.18 토 데드리프트 20kg * 12 30kg * 12 40kg * 12 50kg * 12 풀업 어시 50kg * 12 40kg * 12 30kg * 12 25kg * 8 11.20 월 시티드 케이블 로우 32kg * 20 40kg * 15 47kg * 12 55kg * 9 11.24 금 데드리프트 20..

회사에 입사하고 나서.. 헬스를 많이 못했다 ㅠㅠ 또, 작성하기도 부담스러웠던 것 같다... 그래서 지금이라도 늦었지만 작성한다! 등 날짜 항목 볼룸 (부분 기록) 비고 9.5 화 어시스트 풀업 50kg * 12 40kg * 12 30kg * 12 25kg * 12 데드리프트 20kg * 12 30kg * 12 40kg * 12 * 2 9.10 일 풀업 어시 50kg * 6 40kg * 12 30kg * 12 25kg * 12 랫풀다운 32kg * 12 40kg * 12 47kg * 12 55kg * 12 9.16 토 풀업 어시 50kg * 6 40kg * 12 30kg * 12 25kg * 12 랫풀다운 32kg * 12 40kg * 12 47kg * 11 55kg * 8 저번주에 비해 무게가 주는게 ..

23년 역시 순탄하지는 않았던 것 같다 나 자신이 긍정적으로 변화한 부분도 있고, 그렇지 못한 부분도 있었다 소원해진 사람들도 있고 얻은 사람들도 있었다 아직 나는 항해하고 있는 것 같다 개발 바닥 한파 (feat. 자연어 AI) 우선 23년 초에만 있을 것이라 생각했던 개발자 채용 불황이 더욱 더 심화됐다 도산하는 스타트업들, 학원, IT붐으로 너무나 늘어버린 구직자들 수요는 줄었고 공급은 너무 늘었다 이 타격은 나에게도 직격타였다 이게 끝이 아니라 GPT로 인해 개발자가 하는 역할에 의문점이 생기기 시작했다 종종 나보다도 코드를 잘 짜는 이 친구를 볼때마다 난 프롬프트 엔지니어인가 된 것 같았다 23 중순에는 미국 해고 인원의 25%가 AI라는 얘기도 있었다 특히 소설가, 개발자가 AI 대체 위험 직..

채용 과제를 하면서 급하게 웹플럭스를 익혔다 이전에는 머릿속으로만 희미하게 존재하던 그 녀석을 집적 손으로 다루니 여러모로 느끼게 되었다 거의 2.5일에 걸쳐서 짧은 강의를 완강하고 500page의 책을 75% 정도를 속독한 것 같다 이게 가능한건 토비의 봄 리액티브 편을 종종 누워서 보아왔기 떄문이다 리액티브는 평소 관심은 있었지만 이걸 먼저 공부하면 성장 순서에 악영향을 미칠 것 같았기 때문에, 본격적인 공부는 미루어 왔었다 자, 이제 느낀 걸 적겠다 :) 얼마 전에 알게 된 사실들이라 틀린 내용이 많을 수 있다 느낀 것들 반드시 Mono를 반환해야 한다 무슨 얘기나면 컨트롤러의 Return type이 없거나, Unit이어선 안됀다 즉, Mono.empty() 라도 반환해야 한다 처음에는 이걸로 정말..

이 글은 이 전 글의 내용들을 토대로 재구성되었습니다 https://blog.naver.com/progress0407/222068926986 https://blog.naver.com/progress0407/222074132611 완성본 만들게 된 계기 당시 SI 철수 이후 부장님, 차장님, 사원님 등 본인을 포함한 5~6명이 작성해야할 엑셀 시트가 있었다 이전 동일 작업하셨던 차장님 말씀으로는 이틀 정도는 부지런히 작업해야 끝낼 수 있다고 하셨다 그 업무가 주어질 당시, 다른 팀원들은 다른 태스크가 있었고 신입이었던 내가 가장 먼저 하게 되었다 (중견 이상 기업의 신입은 입사 초기에 일이 없는 경우가 많았다) 내용은 간단했던 걸로 기억한다 각 테이블과 관련된 쿼리의 갯수를 고려해서 기입하면 되는 것이다 ..

종종 배포할때 느린 마이크로서비스 등록 과정 때문에 빠르게 확인할 수 없어서 답답했다 단독 모놀리스면 바로 확인이 가능했지만 마이크로서비스는 정상 기동 후 1분 정도를 기다려야 503 Service Available이 없어진 후 확인이 가능했다 그러나 이건 잘못됐다. 등록은 사실 바로 된 것이다. 문제는 다른 곳에 있었다. 이걸 위해서는 Spring Cloud Nexflix이자 Service Discovery인 Eureka에 대해 알아야 한다 Eureka는 Service Discovery의 Server로, Netflix가 MSA에 관련해서 만든 것 중 하나이다 (Gateway 등) 그건 중요하지 않다 (응?) 등록 과정 Eureka에는 Server 와 Client가 있다 client는 자신의 IP, Po..

코드는 이곳에 :) https://github.com/progress0407/jvm-tools-2.7.x/tree/main/querydsl-sample 코틀린을 도입하기로 결정했는데 자바 코드를 유지할 부분(공통)과 코틀린 코드를 분리할 일이 생겼다 그때 사용한 방법이다 참고로 나의 경우 자바를 사용하는 모듈, 코틀린 사용 모듈을 모두 나누었다 (즉 한 모듈에 자바, 코틀린이 있는 경우는 없었다) 참고로 코틀린, 롬복, QueryDsl이 모두 있는 상황에서 정상 동작하게 만드는 것은 너무나도 힘들다... 여러분은 굳이 그렇게 하지 말고 나처럼 모듈별로 개별 적용하면 그게 차라리 마음의 건강에 좋을 것이다... Gradle 스크립트 우선 아래와 같은 Java, Kotlin 별 QueryDSL 적용을 위한 ..

종종 Spring Data 스택을 사용하다 보면 어떤 Entity Repoistory 던간에 자주 사용하는 기능이 나오기 마련이다 나의 경우 토이를 할때 Kotlin을 자주 사용하는데 ID에 의한 찾은 값의 반환타입이 Optional 보다는 nullable Entity 인게 편한 경우가 많았다 왜냐하면 Elvis Operator를 사용하는게 보다 간단하다고 생각했기 때문이다 val notNullObject = nullableObject ?: throw RuntimeException("null이 될 수 없습니다.") 이때 사용하면 좋은 심플한 트릭이다 Spring Data Repository 확장하기 확장할 Repository에서 구현하고자 하는 메서드만 기술한다 interface ExtendedCrudR..