들어가며 Github에서는 코드 및 라이브러리 공유를 위한 Packages 서비스를 제공한다. 제공하는 패키지 관리자 툴은 아래와 같다. (Docker도 있고 npm도 있네!) 이 Github Packages를 사용하면 쉽게 내가 만든 라이브러리, 코드, 프레임워크들을 공유할 수 있다. 우리 팀에서도 Docker를 활용하여 여러 패키지를 공유하고 있기 때문에 나도 간단하게 실습해보려고 한다. 1. Token 발행하기! Github에서 제공하는 거의 모든 기능은 Token을 필요로 한다. 따라서 우리도 Github Packages 용 Token을 발급받아 보자!! Settings > Developer Settings > Personal access tokens로 이동하여 토큰 발

들어가며 여러 사이드 프로젝트나 개인 프로젝트를 하면서 REST API를 구현했었다.(라고 믿고 있었다.) 최근 후배들과 공모전 프로젝트를 진행하면서 서버 관련 스터디를 진행했다. 그때 API가 무엇인지, 거기서 REST API가 무엇인가에 대해 스터디 준비를 하는데 다음 발표 영상을 봤다. Day1, 2-2. 그런 REST API로 괜찮은가 이 영상의 핵심은 최근 REST API라고 하는(주장하는) API들은 실상 REST 규칙을 전혀 지키지 못한 HTTP API라고 하며 이 REST 규칙을 지키기 위해서 필요한 조건에 대해 설명했다. 따라서 이 REST API를 만족하는 API를 만들어볼 예정이며 inflearn에서 다음 강좌를 참고할 예정이다. 인프론 - 스프링 기반 REST API 개발

들어가며 요즘 Springboot Security의 로직을 공부하면서 node js의 Spring이라고 불리는 nest js에 대해 같이 공부하고 있다. 그러면서 유저 인증 관련 로직을 구현하면서 bcryptjs라는 라이브러리를 알게되었다. bcryptjs는 bcrypt 라이브러리를 js에서 사용할 수 있도록 구현되서 nest js에선 무조건 bcryptjs를 사용해야 하는 줄 알았으나 최근에 nest js에서도 bcrypt 라이브러리를 사용할 수 있다는 것을 발견했다. 그렇다면 bcrypt 라이브러리가 있는데 왜 bcryptjs가 생겨났는 지, 두 라이브러리를 비교해보기로 했다. npm 내부 사용 빈도 bcrypt bcryptjs ![](https://image

들어가며 이번 시간에는 CPU Bound Application과 I/O Bound Application을 만들어서 Multi Processing, Multi Threading, Async를 사용했을 때 어떤 방식이 더 효율이 좋은 지 비교해볼 것이다. CPU Bound Application CPU Bound Application은 300,001 ~ 300,030까지 그 보다 작은 수의 제곱을 더한 계산을 수행할 것이다. EX) 300,001 - 1x1 + 2x2 + 3x3 ~ 300,001 x 300,001 IO Bound Application IO Bound Application은 아래 uuid를 제공하는 해외 사이트를 100번 접속해서 uuid를 받아오는 작업을 수행한다. Multi Processing & Multi Threading & Async 구현 각 어플리케이션에 Processing, Thread, Asyncio 라

CPU Bound vs I/O Bound CPU Bound CPU Bound는 프로세스가 진행될 때, CPU 사용 기간이 I/O Wating 보다 많은 경우다. 주로 행렬 곱이나 고속 연산을 할 때 나타나며 CPU 성능에 의해 작업 속도가 결정된다. I/O Bound 반면 I/O Bound는 프로세스가 진행될 때, I/O Wating 시간이 많은 경우다. 파일 쓰기, 디스크 작업, 네트워크 통신을 할 때 주로 나타나며 작업에 의한 병목(다른 시스템과 통신할 때 나타남)에 의해 작업 속도가 결정된다.

Sync(동기) vs Async(비동기) Sync(동기) 동기 방식은 작업 A가 작업 B에게 작업 요청을 하고 작업 A가 작업 B가 작업을 끝낼 때까지 관심을 가지는 방식이다. 여기서 말하는 관심은 작업이 끝이 났는가에 대한 확인이다. Async(비동기) 비동기 방식은 작업 A가 작업 B에게 작업 요청을 하고 작업 A가 작업 B가 작업을 끝낼 때까지 관심을 버린다. 즉, B가 작업이 끝났다고 A에게 알려줄 때까지 작업이 끝났는가에 대해 확인하지 않는다. 예를 들어 웹 게시판 서버 2개를 각각 Sync와 Async로 운영한다고 가정하고 게시글을 올리고 사용자가 올라간 게시물을 확인하는 과정을 살펴보면 다음과 같다. Sync 방식 위 그림을 살펴보면 C

Concurrency(동시성) Concurrency(동시성)는 CPU 가용성 극대화 위해 Parallelism 의 단점 및 어려움을 소프트웨어(구현)레벨에서 해결하기 위한 방법이다. 1개의 코어는 한번에 한가지의 작업만 처리 할 수 있다. 이때 1개 Core에서 시분할을 통해 2개 이상의 작업을 번갈아가며 처리하는 방식을 동시성 처리라고 한다. 위 그림처럼 동시 작업에 있어서 일정양 처리 후 다음 작업으로 넘기는 방식인데 Task1을 처리하다가 처리 내용을 변경해서 Task2를 처리하는 과정을 작업이 끝날 때 가지 번갈아 반복한다. 이 과정을 시분할이라고 한다. 시분할은 Task 끼리 제어권을 주고 받으며 작업을 처리해나가는 패턴으로 병렬적으로 처리하진 않으나 유사하게 처리한다.

Queue In Process Thread에서 생산자 소비자 패턴을 학습할 때 처음으로 Queue를 사용했다. 간단하게 복습하면 Queue는 선입선출 방식의 자료구조로 주로 데이터를 전달할 때 많이 사용되며 멀티프로세스에서도 사용 가능하다 메인 프로세스 & 서브 프로세스 라이브러리 메인 프로세스 서브 프로세스 실행 결과 Pipe in Process 파이프라인은 프로세스 간의 통신을 할 수 있도록 통로를 열어주는 개념이다. 소켓 통신과 비슷한데 1대1 통신을 기본

서비스 기획자 정의 > 서비스 기획자는 비즈니스 요구사항을 분석하고 제품 설계를 담당하는 사람이다. 기획자가 필요한 조직 vs 기획자가 필요없는 조직 위 두 조직을 구분하기 위해서는 각 조직이 속해있는 비즈니스의 성격을 살펴봐야 한다. 고객이 가진 문제와 해결책을 분명하게 이해하고 있고 결과에 대한 확신까지 가지고 있는가? 만약 가지고 있다면 서비스 기획자가 필요하고 없다면 굳이 필요하지 않다 가지고 있는 경우 주로 이 경우에는 클라이언트가 자신이 필요로 하는 서비스를 제작 요청하는 경우다. 이때 효율적인 업무 프로세스는 워터폴 방식(Waterfall)이다. 워터폴(Waterfall) 방식은 소프트웨어 개발의 모든 단계를 확실히 매듭짓고 넘어가며, 완료된

각각의 프로세스 메모리는 독립적이다. 프로세스는 각각의 개체가 메모리를 할당받아 독립적인 Code, Data, Stack, Heap 영역을 가진다. 만약 1~1000까지 숫자를 더해야 하는데 총 10개의 프로세스에게 일을 맡기고 싶다면 어떻게 해야할까? 기본적으로 프로세스는 값을 공유하지 않기 때문에 1번 프로세스는 1~10까지, 2번 프로세스는 11~20까지 와 같이 범위를 지정해줘서 차후에 합치는 방법을 쓰거나 하나의 공유 메모리를 만들어서 순차적으로 메모리에 접근해 값을 더하는 방식을 쓸 수 있다. 이번 시간에는 공유 메모리를 만들어서 각각의 프로세스가 접근하는 방식을 구현해보고자 한다. 메인 프로세스 & 서브 프로세스 사용 라이브러리 메인 프로세스

Naming 멀티 프로세스로 작업하면 각 프로세스를 구분할 수 있어야 한다. 이때 PID를 통해 구분할 수 있지만 이는 운영체제를 통해 랜덤으로 부여되기 때문에 사용하기가 어렵다. 이에 프로세스의 name 파라미터를 줘서 프로그래머가 각각의 프로세스를 구분할 수 있는 값을 매길 수 있다. 메인 프로세스 & 서브 프로세스 라이브러리 메인 프로세스 서브 프로세스 실행 결과 결과를 보면 Process Name에 각 숫자값이 매핑된 것을 확인할 수 있다. 이때 프로세스 생성 갯수를 10개에서 100개로 늘린 후 CPU 사용량을 확인해보면 다음과 같다. ![](https://images.velog.io/images/carrykim/post/fc945c03

Parallelism (동시성) Parallelism은 동시성을 뜻한다. Concurrent와 다르게 Multiple Core 환경에서 사용 가능하며 멀티 프로세스의 기본이다. 완전히 동일한 타이밍에 태스크를 실행하여 다양한 파트로 나눠서 실행한다. 예를 들어 딥러닝을 위한 데이터 전처리에서 T1은 크롤링을 하고 T2는 엑셀에서 데이터를 수집하고 T3에서는 데이터베이스에서 데이터를 가져와 정제하여 마지막에 합칠 수 있다. 그림을 봐서 알겠지만 기본적으로 CPU가 1Core인 경우 만족하지 않으며 잘못 사용하면 오히려 성능이 떨어질 수 있다. 주로 CPU 사용량이 많은 딥러닝이나 블록체인 체굴등에 사용된다. Process vs Thread ![](https://images.velog.io/

Queue란 큐(queue)는 컴퓨터의 기본적인 자료 구조의 한가지로, 먼저 집어 넣은 데이터가 먼저 나오는 FIFO(First In First Out)구조로 저장하는 형식을 말한다. 영어 단어 queue는 표를 사러 일렬로 늘어선 사람들로 이루어진 줄을 말하기도 하며, 먼저 줄을 선 사람이 먼저 나갈 수 있는 상황을 연상하면 된다. 프린터의 출력 처리나 윈도 시스템의 메시지 처리기, 프로세스 관리 등 데이터가 입력된 시간 순서대로 처리해야 할 필요가 있는 상황에 이용된다. 파이썬에서는 queue 라이브러리를 통해 쉽게 Queue를 구현할 수 있다. Python Event 객체 python에서는 스레드간의 간단한 통신으로 활용할 수 있는 Event 객체를 제공한다. 이벤트 객체의

PM(Project Manager) & 서비스 기획자 - 신규 프로젝트 or B2B 모델 위 그림은 prudect가 출시되기 전, 개발에 필요한 역할군들이다. CEO는 비즈니스 관련 의사결정을 내리고 개발자는 기술 관련 의사결정, 디자이너는 UI/UX 관련 의사결정을 내린다. 이때 각 역할군은 서로 커뮤니케이션을 하면서 합리적인 결정을 내리면서 prudect 개발을 진행해야 한다. 하지만 각 직군별로 상대 직군의 이해도가 낮은 경우, 제대로된 의사소통이 이뤄지지 않는다. 예를 들어 CEO는 한국 내수 시장을 노리기 위한 Prudect A를 출시하고자 한다. 따라서 개발자와 디자이너는 안드로이드 기반으로 prudect를 개발하기 시작했다. 프로젝트가 진행되면서 CEO는 한국보다 해외 시장이 더 인기가

Thread Synchronization 스레드는 Stack을 제외하고 공유된 자원을 사용한다. 이때 하나의 자원에 여러 개의 스레드가 동시에 접근할 경우 문제가 생긴다. 그 중 가장 대표적인 문제가 DeadLock이다. DeadLock 데드락은 프로세스가 자원을 획득하지 못해 다음 처리를 하지 못하는 무한 대기 상황(교착 상태)를 뜻한다. 프로세스 A가 자원 1을 점유한 상태이고 프로세스 B가 자원 2를 점유한 상태이다. 이때 프로세스 A가 자원 2를 요구하고 프로세스 B가 자원 1을 요구하면 서로가 자원을 점유한 상태기 때문에 무한 대기 상태에 빠진다. 이를 데드락이라 한다. 세마포어와 뮤텍스 세마포어와 뮤텍스는 모두 병렬 프로그래밍 환경에서 공유 자원 접근의 상호 배제를

Thread pool 스레드를 비롯한 모든 객체의 생성은 자원 소모가 크다. 그렇기 때문에 미리 만들어놓고 필요에 따라 가져오는 방식을 사용할 수 있다. 이를 Thread pool이라고 한다. 스레드 풀의 장점은 객체의 생성과 제거에 드는 자원 소모를 줄여주기 때문에 성능이 향상되고 다수의 요청을 누락없이 처리할 수 있다. 반대로 너무 많은 스레드를 만들어 놓으면 메모리 낭비와 유휴 스레드가 생겨서 비효율적이다. 사용 라이브러리 스레드 풀 생성을 위한 ThreadPoolExecutor를 import한다. 메인 스레드와 서브 스레드 서브 스레드 1 ~ 10000까지 수를 세는 작업을 한다. 메인 스레드 ThreadPoolExe

사용 라이브러리 스레드 사용을 위한 threading 라이브러리와 스레드 작업 확인 시간 체크를 위한 logging과 time 라이브러리를 사용했다. 메인 스레드와 서브 스레드 구현 서브 스레드 : time.sleep 함수를 통해 3초 동안 대기하는 함수 구현 메인 스레드 : 프로세스의 메인 스레드로 서브 스레드의 전후 상황을 로깅한다. 결과 결과를 살펴보면 메인 스레드가 서브 스레드를 실행시킨 후 바로 종료가 된다. 그러나 서브 스레드는 자기 작업을 끝낸 후 종료가 된다. 그러나 서브 스레드는 특별한 경우가 아니면 메인 스레드가 종료될 때 같이 종료되거나 서브 스레드가 종료될 때 까지 메인 스레드는 종료되선 안된다. 이때 사용할 수 있는 함수가 바로 j

들어가며 분산 시스템에서 가장 중요한 것은 바로 데이터의 병렬 및 동시 처리다. 이를 병렬성과 동시성이라고 하는데 가장 쉽게 공부할 수 있는 방법이 바로 Thread와 Process에 대해 공부하고 다뤄보는 것이다. 따라서 이번 포스팅에서는 Thread와 Process의 개념에 대해 간략히 정리하고 다음 포스트부터는 간단한 실습을 진행해볼 계획이다. 언어는 Python을 사용할 것이다. GIL(Global interpreter Lock) 때문에 멀티 쓰레드 환경 구축이 쉽진 않지만 Java와 다르게 Multi Processing이 가능하므로(Java도 가능할 수 있지만 찾기가 어렵다) 파이썬을 통해 공부하고자 한다. 프로세스 (Process) 프로세스는 저장장치에 저장된 프로그램(소스코드)가 실행되어 운영체제에 의해 자원을 할당 받는 자원이다. CPU를 사용함에 있어서, 시간, 주소공간이 독립적이다. 즉 여러 프로세스가 실행되어도 각각이 독립적으로 구분

들어가며 Backend에 대해 공부하면서 가장 공부해보고 싶은 내용이 부하 분산 이다. 다양한 아키텍쳐, 프레임워크 등이 있지만 그들의 핵심적인 내용은 '서버에 몰리는 트래픽 부하를 어떻게 처리할 것인가'이다. 따라서 부하 분산과 관련해서 공부하면서 알게된 내용을 정리하는 시리즈를 만들어볼까 한다.(절대 취업할 때 다되서 정리하는 거 아님, 암튼 아님) 정리 순서는 다음과 같다. Thread & Process 내용 : Thread와 Process의 차이 언어 or 프레임워크 : Python CPU bound application & IO bound application 내용 : 어플리케이션이 CPU를 더 많이 사용하는가 IO 장치를 많이 사용하는가에 따른 차이 언어 or 프레임워크 : Python 서버 성능 테스트 내용 : 스트레스 테스트 도구를 사용해서 서버 성능 테스트 진행 언어 or 프레임워크 : Spring boo

![](https://ima