Marco Song의 블로그

[Javascript] async/await 과 Promise.all로 비동기 처리하기

Wed, 20 May 2020 10:00:00 GMT

자바스크립트의 비동기 동작에 대해 - 2 : 반복적인 비동기 동작 처리하기

자바스크립트에서 비동기 처리를 위해 자주 사용하는 방법은 3가지가 있으며, 자세한 개념 설명은 간단한 gif 이미지와, 아래의 링크로 대체한다.

자바스크립트의 비동기 처리 방법

콜백 함수(callback function) : https://joshua1988.github.io/web-development/javascript/javascript-asynchronous-operation/
프로미스(Promise) : https://joshua1988.github.io/web-development/javascript/promise-for-beginners/
async - await : https://joshua1988.github.io/web-development/javascript/js-async-await/

(+ generator 도 있음. 추후 포스팅 검토중 )

이 글에서는 자바스크립트에서 비동기 동작을 수천 번 이상 반복적으로 수행해야할 때 어떻게 해야하는지를 다뤄보고자 한다.

여러 개의 비동기 동작을 빠르게 처리하고 싶다면?

자바스크립트를 사용하면서 비동기 동작 관련하여 개발할 때 힘들었던 이슈는, 비동기 처리를 수천 개 이상 해야할 때였다. 구체적인 예시로는 이메일, 알림톡 등 HTTP 리퀘스트가 많이 발생하는 경우가 있다. 통신, 파일 입출력 등 시간이 오래 걸리는 프로세스를 동기로 실행하게 되면 처리가 상당히 느리며, 병렬로 작업을 가져가도록 코드 설계가 필요해진다.

간단한 코드 처리 예시와 결과를 통해 알아보자.

예제 함수

시간이 오래 걸리는 함수 프로세스가 있다. 예제에선 500ms 후 작업이 완료되도록 구성하였다.

json으로 HTTP POST 요청을 보낼 때 (axios 모듈 사용)

let longTimeTask = (index) => {
    return new Promise(function (resolve, reject) {
        process.stdout.write(`${index}번째 일하는중...`);
        setTimeout(function () {
            // let items = randomTime;
            resolve(`${index}번째 작업완료`)
        }, 500);
    });
}

코드 예제 - for문

이런 프로세스를 수천 번 실행해야 한다면 어떻게 할까? ex) 수천 명의 유저에게 이메일이나 SMS 메시지 등을 보내야 하는 경우

일단은 반복문을 써보기로 하자. for문을 돌려보면, 동기로 동작한다. 앞선 작업이 끝나야 다음 작업이 진행되기 때문에, 동작 횟수가 많아지면 시간이 오래 걸린다.

let main = async () => {
    console.log("작업 시작");
    //가상의 작업 리스트
    let workList = new Array(10).fill(0);

    let loopCount = 0;
		for(let work of workList){
        let taskRes = await longTimeTask(loopCount);
        console.log(taskRes);
        ++loopCount;
    }
    console.log('모든 작업이 끝났습니다.');
}

코드 실행 결과. 앞선 작업이 끝나야 다음 작업이 수행된다… (답답)

코드 예제 - Promise.all

따라서 반복문이 병렬로 처리될 수 있도록 추가적인 조치가 필요해진다. 여러 방법이 있지만, 나의 경우 map과 Promise.all()의 조합이 코드 양이 적어서 주로 활용하는 편이다.

let workPromises = await workList.map(async (item, index) => {
        let taskRes = await longTimeTask(index);
        console.log(taskRes);
        return index;
    })
await Promise.all(workPromises);
console.log('모든 작업이 끝났습니다.');

코드 실행 결과.

앞의 for문을 사용한 케이스와 비교했을 때 훨씬 빠르게 작업이 끝난다. (편안)

이외에도 가능한 여러 조합이 있다.

foreach 와 Array.push, Promise.all 조합 등등…

주의할 점은, 항상 비동기 처리를 병렬로만 처리하는 것이 능사는 아니라는 것이다. 예를 들어 클라이언트에서 한 번에 많은 리퀘스트를 서버에 병렬로 보내도록 시도한다면, 서버 혹은 중간에 있는 로드밸런서 등의 미들웨어에서 리퀘스트를 받아주지 못하기도 한다. 이렇게 되는 경우 서버가 감당할 수 있는 만큼만 보내도록 제한하는 방법을 생각해볼 수 있다. 항상 각자의 환경에 맞게 최적의 방법을 찾는 노력이 필요하다.

자바스크립트의 비동기 처리 방식에 대한 고찰

Sun, 12 Apr 2020 10:00:00 GMT

들어가며

사실 자바스크립트의 설계와 동작 방식에 대한 좋은 글은 이미 많이 있다. 그럼에도 불구하고 이 글을 쓰는 이유는, 내가 직접 이해하고 나만의 언어로 표현함으로써 자바스크립트를 더 잘 알게 되리라 생각했기 때문이다. 또한 웹 개발을 하면서 가장 어렵게 다뤘던 부분이 자바스크립트의 비동기 처리여서, 꼭 한 번은 정리하고 싶었다.

자바스크립트의 동작 방식에 대하여

자바스크립트는 싱글 스레드이며, 동기 방식으로 동작한다. 자바나 C++처럼 병렬 실행을 위해 스레드를 새로 만들 수 없다. 따라서, 싱글 스레드로 동작하는데 어느 한 코드에서 발이 묶여버린다면 그대로 전체 프로그램이 굳어 버린다. (block 된다고 표현한다.) 웹 페이지에서 이런 일이 일어난다면 UI가 완전 멈추게 되어, 브라우저에서 다음과 같이 에러를 발생시킨다.

이런 블로킹으로 인한 퍼포먼스 저하를 막기 위해, 자바스크립트는 비동기 방식으로 사용할 수 있도록 설계됐다. 시간이 오래 걸리는 작업을 기다리지 않아도 동작하도록 코드를 짤 수 있다. 핵심 원리는 오래 걸리는 일을 그 자리에서 기다리는 대신, 결과가 나왔을 때 받아서 처리하는 것이다. 따라서 HTTP 통신, 파일 입출력 등 시간이 많이 필요한 코드가 수행되는 동안 다른 동작(UX/UI 등)을 계속 수행할 수 있고, 유저 경험을 해치지 않게 되는 것이다.

정리하면 자바스크립트는 기본적으로 동기 방식이며, 싱글 스레드로 동작한다. 다만 비동기 처리를 위한 몇몇 유용한 기능을 지원한다. (틀리다면 피드백 환영합니다. 아래는 참고자료입니다.)

자바스크립트의 비동기 처리 방법

자바스크립트에서 비동기 처리를 하는 방법은 총 3가지 정도가 있다.

callback function
Promise
async - await

(generator는 제외)

각 기능들은 이전의 기능의 불편함을 개선하면서 등장했기 때문에, 이전 기능을 이해하지 않고 사용하면 겉핥기로만 사용할 우려가 있다. 특히 ES2017 이후 등장한 async / await 은 사용성이 너무 좋다보니, 이전의 개념들을 이해하지 않아도 어떻게든 쓸 수는 있다. 그러나 버그가 발생했을 때 Promise 에 대해서 모른다면 디버깅하기가 참 힘들다. 특히 반복문(foreach, map)이랑 사용할 때 시행착오를 많이 겪게 된다. async - await 을 알려면 Promise를 알아야 하고, Promise를 알려면 비동기 처리에 대해서 알아야 하니, 자바스크립트의 비동기 처리에 대해 개념 정리를 확실히 해두는 것이 좋다.

각 비동기 동작의 내용에 대해서는 다음 시리즈에서 다룰 예정이다.

참고 자료

DB 데이터를 변경할 때 사용하는 보험들 (UPDATE, DELETE)

Sun, 22 Mar 2020 10:00:00 GMT

근래 들어, 일하면서 특정 조건에 해당하는 고객데이터를 수정할 일이 많았다. DB 데이터를 변경하게 되는 UPDATE/DELETE 쿼리 문은 사용할 때 항상 조심스럽다. 트랜잭션을 마친 데이터는 DB에서의 복구가 불가능하며, 백업본으로 복구하는 것 밖에는 방법이 없기 때문이다. (백업본마저 없다면 애도를 표한다 …)

따라서 여러 개의 데이터를 변경할 경우에는, 잘못된 변경에 대한 복구가 가능하도록 보험을 들어놓고 시도하는 것이 안전하다. 아래는 데이터를 잘못 변경하더라도 복구할 수 있는 보편적인 방법들이다.

DB 백업
트랜잭션

나는 백업과 트랜잭션을 조합해서 다음과 같이 사용한다.

(테스트 DB에서) 트랜잭션을 이용해, UPDATE/DELETE 쿼리문을 실행하고 롤백해보면서 개발한다.
(라이브 DB 반영시) 라이브 DB 스냅샷 떠서 백업본을 만들고, 트랜잭션을 거쳐 업데이트를 실행한다.
- 업데이트 결과가 적절한지 확인한다.
  - affected rows를 체크
  - SELECT 문을 실행하여 해당 데이터들이 의도한데로 수정된지 확인 후 COMMIT
라이브 배포

지금까지 DB 데이터를 안전하게 변경하는 방법에 대해서 알아보았다. 백업과 트랜잭션을 사용하는 방법에 대한 내용은 다음 글에서 다룰 예정이다.

스키마란 무엇인가

Sun, 08 Mar 2020 10:00:00 GMT

최근 백엔드 작업을 하다가, “JSON 스키마”를 처음 접했다. 스키마? 데이터의 구조로 알고 있는데… 데이터베이스에서나 쓰던 개념 아니야? JSON에 무슨 스키마가 있다는 거지? 라는 질문에서 스키마에 대해서 잘 모르는 것이 많다는 생각이 들어서, 용어에 대한 정의부터 출발해 스키마가 실제로 어떻게 쓰이고 있는지에 대하여 고민해보았다.

이론

스키마의 사전적 정의는 다음과 같다.

Schema : (계획·이론의) 개요[윤곽]

흠… -_-;; 사전적 의미가 크게 와닿지 않아서 구글에 “Schema”를 이미지로 검색해보았다.

이미지를 보니, 복잡하고 큰 개념을 뭔가 형식으로 도식화한 느낌을 준다. 왜 이렇게 규칙을 만들어 도식화하는가? 규칙을 정해 데이터를 다룸으로써 우리가 복잡하고 큰 데이터를 컨트롤할 수 있겠다는 생각이 들었고, 형식과 규칙을 스키마의 핵심이라고 나름대로 생각을 정리했다.

실전에서 사용하는 스키마들

이번에는 실전에서 사용하는 스키마의 용례들을 살펴보자. 사례를 찾아보니 데이터를 다루는 곳에서 스키마가 많이 사용되고 있었다. 데이터를 효율적으로 다루기 위해서는 규칙과 형식, 즉 스키마가 필요한 것이다. 찾아본 바로는 크게 database(RDBMS, noSQL), XML(XSD), JSON Schema 에서 스키마를 언급하여 소개해둔다.

1. 데이터베이스에서의 기본 개념, 기본 구조로써 언급되는 스키마

외부 스키마, 개념 스키마, 내부 스키마 등 (아래 자료 참고)
https://ykcb.tistory.com/entry/데이터베이스-스키마의-개념-특징
https://www.guru99.com/dbms-schemas.html

2. RDBMS의 정해진 구조로써 언급되는 스키마

noSQL이 스키마가 없어 데이터 구조가 유연하다는 말은, 다음 두 가지 의미를 내포한다.
- RDBMS처럼 정해진 테이블 구조를 갖지 않는다.
  - RDBMS에서 property 하나를 추가하려면 Alter table 해서 모든 레코드에 컬럼을 추가해야 하지만, noSQL에서는 그럴 필요가 없다.
- 각 레코드의 property가 고정돼있지 않다(예를 들면, int 컬럼을 가진 레코드인데 string을 넣으면 테이블에선 대응이 안되지만 noSQL에서는 된다는 것)
- 참고 자료 : https://www.mongodb.com/blog/post/why-schemaless

3. mySQL에서 DB 자체로써 언급되는 스키마

mySQL에서는 테이블의 집합체로써의 데이터베이스를 스키마라고 얘기한다. 그래서 데이터베이스 만드는 코드랑 스키마 만드는 코드가 같다.
```
mysql > CREATE DATABASE `Sparta`;

mysql > CREATE SCHEMA `Greek`;
```

4. JSON, XML 에서 언급되는 스키마

JSON과 XML은 데이터를 형식화하는 방법이다. 이들과 함께 사용되는 스키마는 데이터의 구조를 알 수 있게 해주고, validation시 활용한다. (스키마에 맞지 않는 데이터를 보냈다면 오류를 발생시킨다던지)
참고 자료

아래 예시는 각각 JSON, XML 스키****마를 나타낸다.

    {
        "title": "강아지 스키마",
        "description": "이 스키마는 강아지에 관한 데이터를 검증하기 위해 작성된 스키마임.",
        "type": "object",
        "properties": {
            "name": {"type": "string"},
            "category": {"type": "string"},
            "age": {"type": "integer"},
            "weight": {"type": "number"},
        }
    }

    <?xml version="1.0" encoding="utf-8"?>
    <xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    	...
          <xs:sequence>
            <xs:element name="Recipient" type="xs:string" />
            <xs:element name="House" type="xs:string" />
            <xs:element name="Street" type="xs:string" />
            <xs:element name="Town" type="xs:string" />
            <xs:element name="County" type="xs:string" minOccurs="0" />
            <xs:element name="PostCode" type="xs:string" />
            <xs:element name="Country" minOccurs="0">
    
        ...
    </xs:schema>

정리하면…

스키마 자체는 개요, 구조, 형식이라는 뜻을 가지고 있다. 데이터베이스에서 사용하는 스키마에 대해서만(그것도 겉할기로) 스키마를 알고 있다보니, 여러 문맥에서 사용되는 스키마를 봤을 때 헷깔렸던 것 같다. 스키마는 문맥에 따라 다른 모습으로 머릿속에 그려져야 한다. 이론과 실제가 머리에 들어오게 되어, 이제는 스키마가 뭔지 확실히 얘기할 수 있다는 확신이 생겼다.

글또와 개발 블로그를 시작하며

Wed, 26 Feb 2020 10:00:00 GMT

개발 블로그를 시작하게 된 배경

우리 회사 대표는 네트워크의 달인이다. 적극적으로 멋진 사람들에게 SNS로 다가가 조언을 구하고, 좋은 인맥을 만든다. 개발자는 개발을 잘 해야되지 않겠나 하는 회의적인 시각이 처음에 있었지만, 좋은 개발자를 만나는 가장 좋은 방법은 결국 네트워크라는 생각이 들어서 네트워킹에도 조금씩 투자를 해야겠다는 생각이 들었다. 그래서 다른 개발자들은 어떻게 네트워킹을 하고 있는지 많이 검색해봤다. SNS, 블로그 등 다양한 채널이 있었지만 그중 가장 적합하다고 생각한 건 개발 블로그였다. 많은 개발자들이 자신의 성과를 블로그로 차곡차곡 잘 정리함으로써 네트워킹 뿐만 아니라 커뮤니케이션과 개발 실력 등 많은 이점을 얻고 있었고, 이에 동기부여가 되어 개발 블로그를 시작하기로 결심하였다.

헤맨 끝에 글또와 함께하다

막상 블로그를 시작해보니 티스토리, 벨로그, 깃헙 페이지, 개츠비 등등 글을 쓰는 것보다는 플랫폼에 눈이 돌아가서 이것 저것 옮겨다니는데 급급했다. 그림을 그려야되는데 붓만 계속 새로 사는 것과 같달까… 거기에 일이 바쁘다는 핑계가 더해져 개발 블로그를 거의 하지 않았었다. 그런 와중에 개발자 동료를 통해 글또를 알게 되어 좋은 기회로 함께하게 됐다. 함께 가려면 멀리 가라 했던가. 글또의 여러 개발자분들과 함께 꾸준히 글쓰기로 멀리 갈 수 있기를 바란다.

블로그를 시작한 이유와 목적을 기억하자

개발 블로그를 시작하기에 앞서, 왜 내가 개발 블로그를 시작하려는지, 무엇을 얻고자 하는지를 명확히 해두고자 한다. 열정을 가지고 열심히 글을 쓸 것이나, 동기부여가 때로는 떨어질지도 모른다. 그 때마다 이 글을 보고 초심으로 돌아갔으면 좋겠다.

왜 개발 블로그를 시작하려 하는가?

개발 블로그를 잘 만들어 두면, 그것 자체가 나의 브랜딩이 되고, 나의 이력서이자 포트폴리오가 된다.
기록은 커뮤니케이션 중 최고의 무기라고 생각한다. 글을 잘 쓴다는 것은 생각을 잘 정리한다는 것이며, 생각이 잘 정돈된 사람은 말도 잘한다.
꾸준히 뭔가를 한다는 것은 성공에 있어서 상당히 중요하다고 생각한다. 이전까지 블로그에 대해서 생각만 많았지, 정작 실천하는 것이 별로 없었다.

무엇을 얻고자 하는가?

커뮤니케이션
글쓰기 실력
꾸준한 실천력
개발 실력

어떻게 개발 블로그를 운영할 것인가?

개발하면서 공부한 내용들, 삽질했던 내용들을 글로 정리할 예정이다.

Javascript (node.JS, typescript 등)
RDBMS, SQL
REST API
백엔드 개발을 하면서 얻은 인사이트들
관심 기술들(graphQL, 데이터 분석 등등)
그외 진행하는 개인프로젝트 등

벤치마크한 개발 블로그들

개발자 이현섭님 : https://hyunseob.github.io/
개발자 윤우식님 : https://suitee.me/
개발자 박상권님 : https://gun0912.tistory.com/

ELB 로드밸런서 관련 오류를 해결하면서...

Mon, 20 Jan 2020 22:40:32 GMT

문제 발생

우리 서비스에서 동물 등록을 진행하려면, 동물 보호 시스템에서 다운로드 받은 엑셀 파일을 파싱하여 우리 DB에 업로드 한다. 이 때, 적게는 수십 개, 많게는 수백 개 이상의 동물 등록 데이터를 API 서버에 HTTP 리퀘스트로 보낸다.

최근 업로드한 데이터가 DB에 있던 기존 데이터와 맞는지 검사하는 로직이 추가되면서, 동물 등록 관련 프로세스가 헤비해졌다. 엑셀에 있는 데이터를 통으로 서버로 보내서 비교하기 때문에, 패킷도 무겁고 로직도 무겁다.

이로 인해 200건 이상의 데이터를 리퀘스트했을 때 에러 발생이 많아졌다. 에러 메시지는 502 Bad gateway. CORS 관련 에러 메시지였다.

원인 파악

CORS 관련 에러는 서버, 로드밸런서로 인해 생길 수 있는데, 삽질을 하며 파악해본 결과 로드밸런서의 문제로 파악했다.

다음 두 가지 원인으로 502 에러가 발생했다.

클라이언트 - 로드밸런서 사이에 한 번에 너무 많은 리퀘스트를 보낼 때
로드밸런서 - 서버 사이에 keep alive timeout이 끝나서 커넥션이 끊긴 상태인데 또 리퀘스트를 시도할 때

해결

클라 - 로드 밸런서 사이에는 리퀘스트 갯수가 50개 이상일 경우, 리퀘스트를 50개씩 끊어서 보내도록 구현했다. (전체 프로미스 - 내부 50개씩 보내는 프로미스로 비동기 처리)
로드밸런서 - 서버 사이에는 keep alive timeout 관련 설정을 추가해서 해결했다.

결론

힘들었던 점은, 나는 클라이언트-로드밸런서 / 혹은 로드밸런서-서버 둘 중 하나만 해결하면 문제가 해결될 줄 알았는데, 그렇지는 않았다는 점이다.

마지막에 지푸라기라도 잡는 심정으로, 클라, 서버 둘 다 처리한 걸 테스트해보니까 문제가 해결됐다. 어쩌면 ELB 관련 설정을 잘 해주면 단번에 해결될 문제였을지도 모르겠다. ELB 관련 공부가 더 필요하다.

테스트 환경과 라이브 환경이 다른 것도 이번 삽질의 원인이었던 거 같으니, 연습을 실전처럼 하자고 건의해야겠다. 버그 해결에는 다양한 시도와 창의적인 생각이 필수적인듯!