[컴] callback 함수를 asyn/await 로 변경하기

callback to async/await / how to convert callback function to promise / to async function / callback 을 Promise 로 변경하기

callback 함수를 asyn/await 로 변경하기

callback 을 Promise 로 변경하면 된다.

아래와 같은 callback 을 사용하는 함수가 있다고 하자.

requestTest(param1, param2, 
    function(result){ return 'success'; },
    function(err){ return 'err'; });
await 키워드는 Promise 가 끝날때까지 기다리고, return 을 주게 된다.
그러므로 우리는 Promise 로 만들면 된다. Promise 는 아래와 같은 모습을 갖고 있다.

new Promise(function(resolve, reject){})

우리가 할 일은 callback 부분에서 ‘성공’, ‘실패’ 부분에 Promise 의 resolve, reject 부분만 맞춰서 실행해 주게 만들면 된다.

new Promise(function(resolve, reject){
    ...
    resolve(...);
    ...
    reject(...);
})

그래서 아래처럼 변경해 주면 된다.

resolve(result); 에서 보내는 result 가 await 함수의 return 값이 된다. resovle를 호출하지 않으면 await 으로 호출후 다시 return 돼서 처리되지 못한다. (yield 를 호출하지 않는듯)
const param1, param2;

// ...

const promise = await new Promise(function(resolve, reject){
    requestTest(param1, param2,
        function(result){ 
            resolve(result); // 여기서 보내는 result 가 await 함수의 return 값이 된다.
            return;
        },
        function(err){
            reject(err);
            return; 
        }
    );
})




[컴] Discord 에서 Go 에서 Rust 로 넘어간 이야기

golang



Discord 에서 Go 에서 Rust 로 넘어간 이야기

Discord의 서비스 중에 Read States Service 라는 것이 있는데, 이것을 Go 에서 Rust 로 옮겼다고 함.

Read States 은 message 를 보내고, 읽을때 계속해서 접근하게 된다고 함.

user 의 read state 를 저장하려고, "Read State" 라는 data sturucture 를 가지고 있는데, Discord 가 몇백만개의 Read State 를 갖게 된다. 이 Read State 는 한채널에서, user 당 1개를 갖는다. 그리고 이 Read State 가 여러개의 counter 를 갖고 있다. 예를 들면, 이 채널에서 당신의 @mention 이 얼마나 있는지등에 대한 counter.

이런 counter 의 update 를 빠르게 하기 위해 Read States Server 는 Read State 에 대한 cache 를 갖고 있는데, 이 cache 는 LRU(least recently used, 가장안쓰는 것을 버리는) 방식을 사용한다.
각 cache 에는 몇백만의 users 들이 있고, 몇백만개의 Read States 몇십개가 각 cache 에 있다. 초당 몇백, 몇천의 cache update 가 있다.

그런데, latency and CPU spikes 가 매 2분 마다 있다.

이것이 Go 의 Garbage Collector 때문이었다. 소스로 확인한 결과, Go 가 강제로 최소 매 2분마다 GC 를 돌리도록 하고 있다.

나중에 보니, spike 의 이유는 ready-to-free memory 가 많아서가 아니라, 어떤 메모리를 free 해야 하려고, GC 가 LRU cache 를 scan 하는 과정 때문이었다.

그래서 LRU cache size 를 줄여서 GC 가 scan 하는 시간을 줄였다. 그리고 한 서버에서 LRU cache 를 여러개로 쪼개서(partitioned) 가졌다. 그런데 cache size 가 줄면서, 이것이 database 의 load 로 이어졌다. 그래서 여러번의 load testing 으로 최적의 setting 을 찾아서 설정했다.

하지만, 결과적으로 Rust 로 옮긴 것이 golang 에서 최적의 setting 을 한 것보다 나은 결과를 가져왔다.

...

Reference


  1. Why Discord is switching from Go to Rust - Discord Blog, 2020-02-05



[컴][nodejs] ExpressJS debugging

익스프레스js / 익스프레스 / 디버깅 / 디버그



ExpressJS 를 Debugging 하기

vscode 에서 debugging

ExpressJS debug mode 로 실행

$node --inspect server.js
$node --inspect-brk server.js

vscode 의 launch.js

{

    "name": "Attach",
    "type": "node",
    "request": "attach",
    "port": 9889,  // 이 포트는 server.js 를 실행하면, 화면에 찍힌다.
    "address": "localhost",
    "restart": false,
    "sourceMaps": false,
    "localRoot": "${workspaceRoot}",
    "remoteRoot": "${workspaceRoot}",

}

References

  1. Debugging Express
  2. express - Debug ExpressJS server side code using Visual Studio Code - Stack Overflow


[컴] 네이버 지도 api 사용

naver map api /


네이버 지도 api 사용

  1. Map Api 는 네이버 클라우드 플랫폼(https://www.ncloud.com/product/applicationService/maps) 으로 옮겼다.[ref.2 참고]
  2. 네이버 클라우드 플랫폼 에 가입하자.
  3. 로그인 후 console 로 가서 Application 등록
  4. Application 이름 입력
  5. Service 선택 –> Web Dynamic Map
  6. 서비스 환경 등록 –> Web 서비스 URL 등록(ex: http://localhost)
  7. 인증 정보 클릭 –> client id / client secret 을 얻을 수 있다.

네이버 api 하루 허용량

API 일 허용량
Clova Face Recognition 1,000 회
Clova Speech Recognition 3,600 초
Clova Speech Synthesis 10,000 글자
Papago 번역 10,000 글자
Papago 언어감지 2,000,000 글자
검색 25,000 회
단축 URL 25,000 회
데이터랩 (검색어트렌드) 1,000 회
데이터랩 (쇼핑인사이트) 1,000 회
캡차 (음성) 1,000 회
캡차 (이미지) 1,000 회
한글인명-로마자변환 25,000 글자
지도 월 1000만회 [ref. 3], 무료

References

  1. 네이버 오픈API 종류 - Open API 가이드
  2. 지도 Open API를 NAVER MAPS Enterprise API로 개편합니다. - 공지사항, 2018-10-11
  3. NAVER CLOUD PLATFORM 네이버 클라우드 플랫폼, 2019-11-29
  4. 네이버 Map API 사용 설명서

[컴][javascript] webpack 을 이용해서 compile 시 process.env 사용



webpack 을 이용해서 compile 시 process.env 사용

webpack 을 이용해서 compile 시 React 에서 process.env 등의 값을 이용할 수 있다.

DefinePlugin

webpack.config. 에서 아래처럼 DefinePlugin 을 통해서 React code 에 process.env 를 넣어준다.
그리고 이로인해 만약 if(false) 같은 code 가 생기면, 이것은 unglify 같은 것들을 통해서 배포시 제외시킬 수 있다.
// webpack.config.js

function getClientEnvironment(publicUrl) {
  const raw = Object.keys(process.env)
    .filter(key => REACT_APP.test(key))
    .reduce(
      (env, key) => {
        env[key] = process.env[key];
        return env;
      },
      {
        // Useful for determining whether we’re running in production mode.
        // Most importantly, it switches React into the correct mode.
        NODE_ENV: process.env.NODE_ENV || 'development',
        // Useful for resolving the correct path to static assets in `public`.
        // For example, <img src={process.env.PUBLIC_URL + '/img/logo.png'} />.
        // This should only be used as an escape hatch. Normally you would put
        // images into the `src` and `import` them in code to get their paths.
        PUBLIC_URL: publicUrl,
      }
    );
  // Stringify all values so we can feed into Webpack DefinePlugin
  const stringified = {
    'process.env': Object.keys(raw).reduce((env, key) => {
      env[key] = JSON.stringify(raw[key]);
      return env;
    }, {}),
  };

  return { raw, stringified };
}


const env = getClientEnvironment(publicUrl);

...
module.exports = {
  ...
  plugins: [
    ...
    // Makes some environment variables available to the JS code, for example:
    // if (process.env.NODE_ENV === 'development') { ... }. See `./env.js`.
    new webpack.DefinePlugin(env.stringified),
    ..
  ],
}

References

  1. DefinePlugin fails to inject process.env.NODE_ENV into React without UglifyJSPlugin · Issue #868 · webpack/webpack · GitHub

[컴] 개인정보 보호강화에 따른 광고의 새흐름

데이터 수집 / 광고 고민 / 안드로이드 수집 데이터 제한, / 제한되는 데이터와 앞으로의 광고시장 / privacy / 프라이버시 강화와 앞으로의 마케팅 / 구글 광고 정책 변화 ad policy

개인정보 보호강화에 따른 광고의 새흐름

줄어드는 위치정보 수집

  • Location Sciences 에 따르면, iOS13 이후, 마케터들의 위치정보 수집68% 감소.
    • iOS13 에서 위치정보 수집할 때 popup 을 띄운다.
  • app이 forground 일때 수집된 data 도 24% 감소.
  • 구글, user 들이 자신들이 앱을 사용할때만 위치데이터 를 공유할 수 있는 option 이 있는 경우, 이 옵션을 선택하는 비율은 50% 정도.
    • Android 10 에서 iOS 와 비슷하게, 사용중일때만 데이터 수집 가능하게 할 수 있고,
    • 설치된 app 이 백그라운드에서 위치정보를 수집할 때 user 에게 alert 을 띄운다.
  • Digiday 기사, 광고기술업체 대표 말 인용, app 들이 사용중이 아닐때 위치데이터 를 수집하는 비율은 50% 이하이다.

위치 정보 수집의 제안에 따른 대안

  • 그래서 이제 GPS 위치 데이터 대신에 ip address 를 수집할 듯 하다.
    • 현재로선 android, iOS 전부 ip address 수집을 막지는 않는다.
    • 하지만 vpn 등의 사용을 할 수 있어, ip address 가 항상 정확치는 않다.
  • 다른 대안들
    • contextual clues(문맥적인 단서들)을 이용하는것
      • 예를 들면, 만약 누군가 런던에 앉아서 여행에 대한 글을 본다면, 항공편 관련 광고를 보여주는 것.
      • 이러면 정확한 위치정보가 필요하지 않다.
    • 광고의 타겟팅이 아주 좋지 않기때문에, 다음에 집중해야 한다.
      • 브랜드들은 상품 가치에 더 중점을 둬야 하고,
      • 자신의 데이터를 기꺼이 제공하는 고객직접적인 관계를 맺는 것
    • 광고가 좀 더 똑똑해져야 한다.
      • user 의 기분, 순간, 마음가짐, 감정 에 따라 다른 광고를 보여줘야 한다.

광고 에이전시의 대안

  • 광고 산업이 하는 일은 제품과 구매 욕망을 연결시키는 것. 하지만 개인들이 무엇을 원하는지 또는 어떤 커뮤니티에 속하는지까지 광고 에이전시가 정확히 알 필요는 없다.
  • 광고 에이전시의 대안
    • 이전처럼 하면된다. 이전에도 개개인에 대한 targeting 이 되지 않았다.
    • 그들이 타겟팅하고 싶은 커뮤니티의 사람들이 사용하는 앱과 서비스후원
    • 한 음료 회사가 히트시킨, 맥주를 마시는 느낌을 내주는 간단한 아이폰 앱
    • 이미 광고 회사나 기술 기업은 머신 인텔리전스, 특히 온디바이스 인텔리전스(On-device Intelligence)를 통해 개인 정보에 대한 접근을 제한하면서 광고주가 원하는 것을 더 많이 제공할 수 있다.
    • 연합학습(Federated Learning)
      • 단말기에서 인공지능을 학습시키는 기술
      • iOS 13의 시리에 사용

See Also

References

  1. Apple and Google’s location privacy controls are working, 2020-01-23
  2. 블로그 | 애플이 광고업계에 쏘아올린 작은 공 - CIO Korea, 2019-12-16

[컴] 서버리스 컴퓨팅 하기 전 알아두면 좋은 점

서버리스 컴퓨팅 도입하기전에 확인해야 할 점 / 서버리스 장단점 / serverless computing

서버리스 컴퓨팅 하기 전 알아두면 좋은 점

서버리스 컴퓨팅 serverless computing[ref. 3]

  • 특정 코드 조각을 실행할 때 필요한 컴퓨팅 리소스와 스토리지를 동적으로 할당
  • 그만큼에 대해서만 요금을 부과
  • 서버의 프로비저닝유지보수를 전적으로 제공 업체가 책임.
  • 서비스 제공업체가 해주는 일
    • 하드웨어 프로비저닝
    • 가상 머신 및 컨테이너 관리
    • 애플리케이션 코드에 자주 내장되는 멀티쓰레딩 같은 작업 등

서버리스를 사용하는 것이 유리한 작업

  • 특정 상황에서 동시에 많은 이벤트 요청을 처리해야 하는 애플리케이션
  • IoT 디바이스에서 제한된, 또는 간헐적인 인터넷 연결로 전송되는 데이터를 처리하는 애플리케이션
  • 특정 종류의 배치 프로세싱

서버리스관련 프레임워크

  • "서버리스 프레임워크"(이름이 서버리스)
    • 지원되는 플랫폼:  AWS 람다, 애저 펑션, 구글 클라우드 펑션, IBM 오픈위스크
    • 모든 플랫폼에서 동일한 경험을 제공
  • 에이펙스(Apex)
    • 특정 제공업체에서 원래 사용할 수 없는 몇몇 언어를 활용하는 데 도움

지원되는 언어

  • AWS 람다
    • Node.js
    • 자바
    • 고(Go language)
    • C#
    • 파이썬
  • 애저 함수
    • 자바스크립트
    • C#
    • F#

트리거

  •  AWS 람다
    • 가장 풍부, 그중 상당수는 AWS 플랫폼 전용
  • 구글 클라우드 펑션
    • 일반 HTTP 요청에 의해 트리거될 수 있다. 

테스트 방법

  • AWS SAM(Serverless Application Model)
    • 오프라인으로 람다 코드를 테스트할 수 있는 로컬 기능을 제공
  • 서버리스(Serverless) 애플리케이션 프레임워크
    • 로컬에서 코드 실행이 가능한 서버리스-오프라인(serverless -offline) 플러그인

물론 서버는 여전히 사용되지만 프로비저닝과 유지보수를 전적으로 제공 업체가 책임

원문보기:
http://www.ciokorea.com/news/125655#csidx9f3a9658ad9d50ca1e597a4b956498c

장점

  • 비용
    • 높은 비용 효율성
      • 서버리스 컴퓨팅 아키텍처는 태생적으로 다른 접근 방법에 비해
      • 사용하지 않을 때는 비용도 없다
    • 소비에 대한 비용만 지불
      • 서버리스 기술에서 고객은 용량이 아닌 소비에 비용을 지불
      • 부가적인 인프라와 유지보수 없이 딱 필요한 작업에 대한 비용만 내는 것
      • 서버리스 컴퓨팅이 리소스의 과도한 할당과 관련된 비용을 줄인다.
    • uptime 비용없다 : 사용한 만큼 비용을 내므로 업타임 비용이 없다
  • 애플리케이션이 클라우드 내에 빠르고 값싸게 배포하고 분산이 가능
    • 애플리케이션을 작은 용도별 기능으로 분할
  • IT 워크로드를 경감
    • 직원들이 서버 성능 관리, 안정성, 유지보수, 보안 업무 등에 상시 매달릴 필요가 없다
    • 애플리케이션 업타임을 보장하기 위한 작업을 서버리스 플랫폼에서 해준다.
      • 상태 확인을 구현
      • 기반 OS를 관리
      • 최신 보안 패치를 적용
      • 인프라에 최대 워크로드를 감당하기에 충분한 용량이 프로비저닝되도록 확인하는 일 등
  • 개발자의 부담도 덜어준다.
    • 개발자는 인프라 관련 문제가 아닌 자신이 작성하는 코드의 비즈니스 목표에 집중
    • 코드, 특히 인프라 코드를 덜 쓴다 --> 인프라 프로비저닝은 서버리스 기술에 맡기고 더 많은 개발자를 비즈니스 기능 구축에 투입 --> 개발 속도가 빨라진다. --> 조직은 민첩성과 혁신을 개선할 수 있다.
    • 개발 주기의 속도가 빨라지고, –> 제품화 기간도 개선 –> 조직은 지속적인 개선과 고객 만족에 집중

단점

  • 서버리스로 인해 오히려 워크로드가 늘어나는 경우도 있다.
    • 기능을 만들고 여러 API를 연결해 비즈니스가 요구하는 작업을 수행하는 데 더 많은 일이 필요하다
  • 버그 잡기
    • 표준화된 보안, 테스트, 모니터링, 구성 관리가 없는 경우 서버리스에 버그가 퍼질 수 있다.
    • 각자가 알아서 만들면, 코드가 여러가지가 돼서, 관리가 어려워 지고, 버그가 생기면 일괄적으로 수정하기 어려울 수 있다.
  • 장기간 지속되는 작업에는 적합하지 않다.
    • 계산에 오랜 시간이 걸리는 작업
    • 현재 애저 펑션(Azure Functions)과 AWS 람다(AWS Lambda)는 각각 최대 10분, 15분만 실행이 가능
  • 콜드 스타트(cold start) 역시 서버리스의 단점.
    • 보통 수십 밀리초 정도
    • 대다수 사용 사례에서 무시해도 되는 시간
  • 벤더 종속 : 주요 서버리스 시스템이 상호 호환되지 않는다
    • AWS 람다
    • 애저 펑션
    • 구글 클라우드 펑션
    • IBM 클라우드 펑션(IBM Cloud Functions) : 오픈소스 아파치 오픈위스크 플랫폼을 기반
  • 보안 측면
    • 기본적으로 서버리스는 짧은 실행 시간과 기반 호스트 OS로부터의 격리로 인해 위험이 제한된다
    • 다른 리소스에 대한 액세스 권한을 획득하기 위한 공격에서 중간 단계로 서버리스 함수가 사용될 수도 있다
      • 함수가 너무 많은 권한을 갖거나
      • 취약한 구성요소를 포함
      • 서버리스를 안전하게 구성하고, 이후 이상 현상과 악용을 모니터링해야 한다
  • 자동확장으로 인한 비용
    • 전통적인 서버는 용량이 초과하면 그냥 작동을 멈추므로 부가적인 비용이 발생할 일이 없다. 그러나 서버리스는 상대적으로 제한 없이 확장이 가능하므로 주의하지 않으면 상당한 비용으로 이어질 수 있다
  • 인건비 상승
    • 기술에 초점을 둔 기업에서 경비가 많이 할당되는 분야 중 하나는 개발자 채용
    • 스킬을 갖춘 적격 개발자가 적어 고용하고 보유하려면 많은 비용이 든다

서버리스 도입시 주의점

  • 구현에 앞서 충분한 시간 동안 서버리스 제품에 대해 알아봐야 한다
  • 최소한 롤백 프로세스는 마련해 둬야 한다.
  • 현재 시스템의 성능을 측정해서 계획 중인 서버리스와 비교해 가능한 운영 및 비용 상의 이점을 알아봐야 한다.
  • 서버리스에 반드시 ‘올인’해야 할 필요는 없다. 필요에 따라 적게 사용할 수도, 많이 사용할 수도 있다

서버리스 도입시 여전히 고려해야 할 점

  • 여전히 애플리케이션효율성에 중점을 두어야 한다.
    • 자원이 자동으로 할당된다.(애플리케이션의 요청에 의하거나, 서버리스 판단에 의해)
    • 만약 애플리케이션의 자원 요청이 언제 어떻게 이루어질지를 제대로 설계하지 않으면, 서버리스 시스템은 자원을 과잉 할당할 가능성이 크고, 결국 비용은 커지고 효율은 나빠질 것.
  • 여전히 관리 지점을 구축
    • 애플리케이션 안으로 향하는 API를 설계해야 하고,
    • 모니터링을 위한 외부 관리 툴로의 데이터도 설계해야 한다는 의미
    • 장기적으로 잘 관리하기 위해선 이런 인터페이스가 있어야 한다.
  • 설계 단계부터 보안이 필요
    • 설계와 계획이 없는 애플리케이션은 덜 안전한 애플리케이션이 된다.
    • 데이터 유출은 흔히 개발자의 실수와 설계에서 시작.

References

  1. 준비되었는가? 서버리스 컴퓨팅을 둘러싼 모든 장점과 의사 결정 - ITWorld Korea, 2020.01.17
  2. IDG 블로그 | 서버리스 시스템도 설계가 중요한 이유 - ITWorld Korea, 2019.10.23
  3. '이유 있는 인기'··· 서버리스 컴퓨팅의 효용 - CIO Korea, 2019-07-08