개발왕 양선규

"코딩 테스트 합격자 되기" 교재를 완독했다. 하루에 1문제 ~ 3문제 정도를 푼 결과 완독은 2달 정도 걸렸다. 분량이 700페이지 정도 되기에 이걸 언제 다 읽나 하긴 했지만, 매일 조금씩 늘어가는 스스로를 보니 그렇게 긴 분량도 아니었던 것 처럼 느껴진다. 이 교재는 프로그래머스 문제 + 저자 출제 문제 합쳐서 총 100문제가 담겨 있고, 코딩 테스트에서 중요하게 생각할 점이나 시간 복잡도 계산법 같은 초보자가 놓치기 쉬운 부분을 가장 먼저 짚고 시작한다. 최근 코딩 테스트에서 나오는 빈출 유형들은 대부분 실려 있으나, 이분 탐색 알고리즘이 실려 있지 않다는 것이 조금 아쉽긴 하다. 도서명: 코딩 테스트 합격자 되기평점: 7/10 우선 책을 읽기 전 나의 기반 지식부터 말하겠다. 1년 전 쯤 크래프..

웹 서비스 요청의 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에 묶여 동시에 단 하나의 코어(..

MQ 비동기 도입 전/후 테스트를 진행하며, 파이썬의 I/O 작업 처리 방식에 궁금증이 생겼다. 1초가 걸리는 요청을 초당 100개씩 보냈는데도 1초마다 100개를 전부 응답했기 때문이다. 파이썬은 GIL 때문에 한번에 하나의 작업만 처리하는 걸로 알고 있었는데다가, 내가 비동기 처리를 하지 않았는데도 비동기처럼 동작하길래 무슨 원리인지 궁금해서 파 보았다. GIL(Global Interpreter Lock)GIL은 Global Interpreter Lock의 약자로서, 간단히 말하면 파이썬에서 하나의 프로세스(워커)가 동시에 하나의 CPU 작업만 실행하게 하는 제약조건이다. 이 제약 때문에 파이썬 코드는 언제나 동시에 단 한개만 실행된다. 그러나 이것이 싱글스레드로 동작한다는 말은 아니다. 필요에..

이번 성능 테스트에서는 I/O 바운드 작업에 대한 클라이언트 응답 시간을, 메시지 큐 비동기 처리 도입 전/후로 테스트 했다. 사용자 -> Flask -> Go(Gin) 흐름으로 사용자 요청이 전달되고, 실제 비즈니스 로직 작업은 항상 Go에서 한다. 이 때, 실제 비즈니스 로직이 아닌 time.sleep() 함수로 대체하여 병목 시간 1초를 시뮬레이션한다. 기존 방식인 동기(Sync)방식은, Flask에서 Go에게 직접 요청을 건네고 Go가 1초 후 응답하는 것을 기다렸다가 클라이언트에게 응답한다.메시지 큐 비동기(Async)방식은, Flask에서 RabbitMQ에 메시지를 발행(publish)하고 클라이언트에게 즉시 응답한다. Go의 컨슈머는 무한 대기 상태로 있다가, 큐에 메시지가 publish되면..

드디어 성능 테스트에 필요한 모든 환경을 구축하고, 실제 테스트까지 해 보았다.트래픽 발생은 JS k6라이브러리를 활용했고, 시계열 데이터를 InfluxDB에 담아 Grafana와 연동해 시각화했다. InfluxDB + Grafana 컨테이너화 InfluxDB와 Grafana를 컨테이너로 올렸다. Docker에 준비된 이미지를 받아와 띄우고 기본 세팅만 하면 되기 때문에 크게 어렵진 않았다.기존 컨테이너 (Flask + Go(Gin) + PostgreSQL)와 하나의 compose 파일로 묶을까 했지만, 네트워크는 공유하되 테스트용 컨테이너는 분리해 관리하는 것이 나을 것 같아 따로 구성했다. InfluxDB, Grafana 세팅은 크게 건드린 건 없고 최대한 가볍게 띄웠다. 모든 컨테이너가 띄워졌다...

저번 글에서 Flask + PostgreSQL 환경 세팅 및 docker-compose 컨테이너화 까지 진행했었다.이번 글에서는 Go 서버 구현은 넘어가고, Flask Go gRPC 환경 세팅에 대한 내용을 다룰 것이다. 디렉터리 구조 우선 디렉터리 구조를 좀 손봤다. 작은 프로젝트가 될 거라서 구조는 신경쓰지 않으려고 했는데, 플라스크 기준으로 3가지 통신 방식이 있었다. 1. Flask가 요청 받고 직접 응답 (internal)2. Flask가 요청 받고 Go에게 Rest로 전달 (rest)3. Flask가 요청 받고 Go에게 gRPC로 전달 (grpc) 아직 제대로 시작도 안 했는데 벌써 복잡해져서, 아예 초반에 디렉터리 구조를 잡아버렸다.그나마 다행인 건, gRPC 서버(Go)에서는 gRPC ..