개발왕 양선규

웹 서비스 요청의 80%는 단순 읽기 작업이라고 한다. 따라서 개발 속도는 빠르지만, 상대적으로 성능이 떨어지는 Python 기반의 웹 서버를(Flask, Django 등) Gateway로 두고 Core Engine으로 고성능 서버(Go 등)를 활용하는 MSA 방식이 요즘 유행이다. Python 기반의 웹 서버는, GIL 제약에 의해 멀티스레드 병렬 처리를 활용하지 못 하지만 I/O 작업에서는 전혀 문제가 없다. I/O 대기시간엔 CPU를 사용하지 않는 데다가, 기다리는 동안 GIL을 놓고 추가 스레드를 생성해 다른 작업을 맡길 수 있기 때문이다. 명시적 비동기 처리를 하지 않더라고 비동기 "처럼" 동작하기 때문에 I/O 작업엔 크게 무리가 없고(그렇다고 더 빠르단 건 아니다), 개발 속도가 빠르다는 장..

저번 시간엔 RabbitMQ 비동기 처리를 통해, Flask의 I/O Bound 병목점을 해결해 보았다. 응답시간은 약 500배 차이가 났었고, 처리량 및 드랍률도 RPS가 증가할수록 격차가 심해졌다. 이번 시간엔 Flask의 나머지 대표적 병목인 CPU Bound 작업을 Go에 위임해 볼 것이다. Flask는 Python의 GIL 한계 때문에 멀티코어 + 병렬 처리의 이점을 전혀 얻을 수 없어, CPU 연산 중엔 GIL을 놓지 못해 완전히 블로킹 되어 성능이 급감한다. 이러한 CPU Bound 작업을 병렬 처리에 특화된 Go에 위임하여, 어느 정도의 성능 향상을 가져오는지를 테스트 할 것이다. 기존 방식인 Flask 자체 연산 방식은, CPU 연산을 수행하는 동안 GIL에 묶여 동시에 단 하나의 코어(..

프로젝트 개요Flask + Go(Gin) 기반 MSA 아키텍처 성능 실험 프로젝트를 시작한다. 서비스 목적이 아닌 성능 개선 및 측정/검증 프로젝트이며 UI/UX, 도메인, 비즈니스 로직 등을 철저히 제외하고 백엔드 고급 기술 + 성능 개선 및 측정에 목표를 둔다. 프로젝트 목적- 이력서 & 포트폴리오 업그레이드 및 개인 실력 향상 주요 내용- Flask & Go(Gin) MSA 아키텍처 설계 및 구현- Flask & Go(Gin) 서버 간 Rest/gRPC 성능 측정- Flask 단일 vs Flask & Go 성능 측정 (CPU 집약적 연산, 외부 API 호출, 대용량 데이터 처리 등)- Docker/Docker compose 활용한 컨테이너 그룹화 및 Kubernetes 연동 컨테이너 오케스트레이션-..

메멘토 AI 3개월 근무 중 폐업에 의해 퇴직하고, 6개월의 취업준비를 거친 후에 드디어 재취업을 했다. 3개월이라는 근무 경험이 있긴 하지만 경력으로 인정받을 정도는 아니기 때문에, 사실상 신입과 큰 차이는 없다. KIDB 채용연계형 인턴 합격KIDB는 금융중개업 회사로서, 채권중개/자금중개 업계 1위의 인지도를 지키고 있는 근본 있는 회사이다. 나는 자산 증식에 관심이 많아 핀테크 또는 돈을 다루는 도메인에 가고 싶었는데, 결국 순도 100%의 금융권에 오게 되었다. 개발과 더불어 금융에 대한 지식까지 배울 수 있다는 게 큰 메리트다. 전형은 서류 -> 1차면접 -> 2차면접 순으로 진행되었으며, 기술적인 질문보다는 인성/태도 부분을 주의깊게 보시는 듯 했다. 그걸 빠르게 캐치하고 최대한 겸손하고 예..

HTTP에 SSL 인증서(암호화라고 보면 됨)를 적용한 것이 HTTPS 이다. 웹을 서비스하기 위해서 SSL 인증서는 필수라고 할 수 있다. SSL 인증서가 없다면 1차적으로 브라우저에 안전하지 않다는 경고가 뜨며, 데이터가 평문으로 노출되어 탈취당할 가능성이 있고, 최신 웹 프로토콜이나 기술들과 호환되지 않을 수 있다. 심지어 개인정보를 취급하는 웹 사이트의 경우 암호화 등의 보안 조치를 취하는 것이 법적으로 의무화 되어 있고, HTTPS는 암호화를 적용하는 가장 쉽고 표준적인 방법이기 때문에 적용하지 않을 이유가 없다. SSL 인증서를 적용하는 대표적인 방법은 크게 두 가지가 있다.1. AWS의 ACM, Route53, 로드 밸런서를 이용한 SSL 인증서 적용2. Let's Encrypt, 가비아(또..

테스트 코드처음으로 테스트 코드라는 것을 작성해 보았다. 단위 테스트, 통합 테스트에 대해 공부하고 그것을 적용해 테스트 코드를 작성했다. 테스트 코드는 말 그대로 테스트이기 때문에 간단할 것이라고 생각했지만 생각보다 고려할 것이 많았다. 물론 그냥 내 맘대로 짜면 짤 수도 있었겠지만, 무엇이 좋은 테스트인가? 어떤 것을 테스트해야 하는가? 모킹은 어느 정도 수준까지 해야 하는가? 테스트 해야 할 흐름은 어떤 것들이 있는가? 즉, 최적의 테스트 라는 게 무엇인지를 깊이 탐구하는 것과, 그것을 알기 위해 테스트라는 것 자체를 깊게 이해해야 했기에 많은 시간이 걸렸던 것 같다. 테스트는 보는 이로 하여금 테스트의 의도가 명확히 전해져야 하고, 그것을 위해 조금의 불편함도 감수할 수 있어야 한다. 쓸데없이 복..

일반적인 Hard Delete 방식을 사용했다면 외래키 관계를 이용한 엔티티와 DB 레벨에서의 cascade를 이용할 수 있었을 테지만, 중고차 거래 플랫폼 특성상 데이터의 신뢰도가 중요했기 때문에 Soft Delete 방식을 채용했다. 그로 인해 연쇄 삭제 기능은 서비스 레벨에서의 delete() 메서드 조합이나 QueryDsl 커스텀 쿼리를 통해 직접 구현해야 했다. 처음엔, 모든 엔티티가 상속받는 BaseEntity에 존재하는 softDelete() 메서드를 Facade 서비스 클래스에서 전부 호출해서 삭제할까 생각했다. 하지만, 그러면 제공되는 인자는 CarListing.id(판매 차량 id) 한개 뿐일텐데 이걸로 repository 조회해서 연관된 엔티티 id를 얻고 하는 일련의 작업을 서비스 ..

테스트 코드는 매우 중요하며, 개발자에게 있어 필수적인 핵심 역량이다. 서비스 규모가 작을 때야 코드를 수정한 후 api 몇 개 직접 호출하면 금방 테스트할 수 있겠지만, 규모가 커져서 api가 수백 수천 개, 메서드가 수천 수만 개 된다면 반드시 테스트 코드가 필요할 것이다. 미리 잘 짜놓은 테스트 코드는, 배포하기 전 매번 테스트를 직접 수행하는 번거로움을 줄여주며 정확히 어디에서 오류가 발생했는지 쉽게 디버깅할 수 있게 해 준다. 개발이라는 분야에 있어서 기능의 구현 만큼이나 코드의 유지보수성과 확장성이 중요하다는 것을 생각한다면, 테스트 코드는 비즈니스 로직 만큼이나 중요하다고 해도 과언은 아닐 것이다. 스프링 부트 테스트 전략은 크게 [단위 테스트, 통합 테스트, E2E/기능 테스트] 로 나뉜다..

스프린트 3이 종료되었다. 스프린트 2 회고에서 차량 등록, 조회를 어떻게 구현할지 걱정했지만 훌륭히 구현해 냈다.이번에 구현한 기능은 아래와 같다.차량 등록판매 차량 상세 조회 차량 정보를 다루는 엔티티가 무려 10개였기 때문에, 백엔드 코드 작성이 매우 매우 어려웠다. 애플리케이션 레벨에서 관계는 어떻게 정의하며, repository와 service는 어떤 구조로 작성하고 관리하는지, 쿼리는 어떻게 최적화 하는지 등등… 고민해보지 못했던 문제들을 많이 만났다. 스프린트 2의 유저 관련 로직을 짤 때보다 10배는 더 어려웠던 것 같다. 이번 스프린트 3을 진행하며 가장 크게 배운 것은 객체지향적 설계와 SOLID원칙, 그리고 쿼리 최적화이다. 백엔드에서 어려웠던 점 - 객체지향적 설계와 N+1, 카테시..

차량 상세조회 기능을 구현하며 차량 관련 엔티티 10개를 조회해야 했는데, 이 과정에서 Lazy Loading, fetchJoin, BatchSize를 공부하고 적용해 보았다. 백엔드에서 쿼리 짜는 게 제일 어려운 것 같다. 아래는 Lazy Loading, fetchJoin(), BatchSize에 대해 내가 정리한 글이다.https://yskisking.tistory.com/316 JPA 쿼리 최적화 - Lazy loading, fetchJoin(), BatchSize개인 프로젝트 썬카에서 차량 상세 조회 기능을 만들다가 쿼리 최적화 문제에 부딪혔다.무려 10개의 엔티티를 전부 조회해야 했고 성능 부분을 신경쓰지 않을 수 없었기에, 자연스럽게 Lazy loadingyskisking.tistory.com..