유용한 npm cache package 소개 및 적용

들어가며

저는 이전에 저희가 사용중인 백엔드에서 서버간에 통신하는 방법을 소개드린 적 있습니다.
이 모듈은 monorepo 안에서 독립 package로 분리되어 더욱 발전하고 있습니다.
이 internal_api package에 추가된 기능을 소개하고자 합니다.

결론을 먼저 말씀드리면, cache에 관한 2가지 npm package를 소개하는 글이 될 것 같습니다.

• DNS를 위한 cacheable-lookup
• data를 위한 in-memory node-cache

1. 빈번한 DNS 에러

저희는 lambda와 ECS fargate로 서버가 구성되어 있습니다.
백엔드 서버에서 외부든 내부든 또 다른 서버에 요청하는 경우, 대부분은 대상 서버가 정해져 있는 경우가 많은데,
특히, 한번 실행되면 오래 떠 있는 ECS에서 종종 DNS 에러가 발생하곤 했습니다.

Error: getaddrinfo EAI_AGAIN account-api.frommyarti.com
     at AxiosError.from (/app/node_modules/axios/dist/node/axios.cjs:836:14)
     at RedirectableRequest.handleRequestError (/app/node_modules/axios/dist/node/axios.cjs:3086:25)
     at RedirectableRequest.emit (node:events:513:28)
     at eventHandlers. (/app/node_modules/follow-redirects/index.js:38:24)
     at ClientRequest.emit (node:events:513:28)
     at TLSSocket.socketErrorListener (node:_http_client:502:9)
     at TLSSocket.emit (node:events:513:28)
     at emitErrorNT (node:internal/streams/destroy:151:8)
     at emitErrorCloseNT (node:internal/streams/destroy:116:3)
     at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
     at Axios.request (/app/node_modules/axios/dist/node/axios.cjs:3876:41)
     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
     at async AccountExternal.getAccountUser (/app/apps/server/dist/src/user/account/account.external.js:110:40)
     at async Promise.all (index 0)
     at async FanService.getFanProfile (/app/apps/server/dist/src/user/fan/fan.service.js:54:36)

이와 관련해서 구글링을 해보시면, getaddrinfo Error in Node.js 라는 제목으로 많은 글을 볼 수 있습니다.

Node.js에서 DNS issue가 종종 발생하는 이유는 libuv threadpool이 4개 쓰레드만 사용하는 것과 관련이 있습니다.
libuv에서 OS의 getaddrinfo() 호출은 동기적으로 수행되고, Node는 DNS를 caching하지 않으며, OS에게 위임합니다.
이와 관련된 글은 다음을 참고하시면 좋을 것 같습니다.

• https://httptoolkit.com/blog/configuring-nodejs-dns/
• https://medium.com/swlh/solving-node-dns-issues-and-other-things-5051d8526cac

저희가 개발해 사용중인 monorepo internal_api package에 아래와 같이 cacheable-lookup를 추가함으로써, 서비스 로직은 건들지 않으면서, 손쉽게 안정성을 높일 수 있었습니다.
아래는 저희 master branch에서 추출한 patch 입니다. 서버 내부에서 axios를 자주 사용하신다면, cacheable-lookup를 사용해 보시길 추천합니다.

Subject: [PATCH] [BETT-2457] 빈번한 DNS 에러 개선 (#1541)
===================================================================
+import { Agent as HttpAgent } from 'http';
+import { Agent as HttpsAgent } from 'https';
+
 import { Injectable } from '@nestjs/common';
 import axios, { AxiosInstance } from 'axios';
 import { ConfigService } from '@nestjs/config';
+import CacheableLookup from '@esm2cjs/cacheable-lookup';
 
 import { createSignature } from './signature.util';
 
@@ -15,7 +19,15 @@
         this.#INTERNAL_API_ORIGIN = this.configService.getOrThrow('internalApi.origin', { infer: true });
 
         this.#INTERNAL_API_ORIGIN_SIGNATURE = createSignature(internalApiSecretKey, this.#INTERNAL_API_ORIGIN);
-        this.#axiosInstance = axios.create();
+
+        const cacheableLookup = new CacheableLookup();
+        const httpAgent = new HttpAgent();
+        const httpsAgent = new HttpsAgent();
+
+        cacheableLookup.install(httpAgent);
+        cacheableLookup.install(httpsAgent);
+
+        this.#axiosInstance = axios.create({ httpAgent, httpsAgent });
 
         this.#axiosInstance.interceptors.request.use(config => {
             config.headers['origin'] = this.#INTERNAL_API_ORIGIN;

NestJS HttpModule에는 다음과 같이 적용하면 됩니다.

        HttpModule.registerAsync({
            useFactory: () => {
                const cacheableLookup = new CacheableLookup();
        
                const httpAgent = new HttpAgent();
                const httpsAgent = new HttpsAgent();
        
                cacheableLookup.install(httpAgent);
                cacheableLookup.install(httpsAgent);
        
                return {
                    httpAgent,
                    httpsAgent
                };
            }
        }),

개선 이후, DNS 에러(EAI_AGAIN, ENOTFOUND)를 보지 못했습니다.

2. node-cache를 통한 순차적 service logic 작성

internal_api package를 사용하는 service 코드

        // internal_api 결과 캐싱
        const cacheConfig: LocalCacheConfig = { contextId: uuidv4() };

        const merged = await mediaPosts.reduce(async (accPromise, mediaPost) => {
            const acc = await accPromise;

            const isVisible = await this.#checkVisibility(level, userId, mediaPost, cacheConfig);
            const responsePost = new GetMediaPostListResponsePost(mediaPost, isVisible, language);

            return [...acc, responsePost];
        }, Promise.resolve([]));

Artist article인 mediaPosts를 labelId로 읽어 왔을 때, 각 mediaPost를 해당 fan이 볼 수 있는지 확인하는 로직입니다.
membership에 가입 유무, message 구독 여부에 따라 각 mediaPost의 visibility를 결정합니다.

복수의 mediaPosts를 순차적으로, 각 mediaPost 마다 설정되어 있는 해당 article의 공유 범위(전체 허용, membership 가입, message 구독 등)와 fan의 membership 가입, message 구독 여부에 따라 visibility를 결정합니다.
그런데 article의 공유 범위와 fan의 membership 가입, message 구독 여부 조합이 많은 경우의 수가 아니라, mediaPosts를 순회하는 과정에서 동일한 요청을 여러 번 할 수 있게 됩니다.

이런 경우, 이번 서비스 요청에서 발생하는 모든 article의 공유 범위와 fan의 membership 가입, message 구독 여부 조합을 먼저 추출하고, 서비스 조직의 변수에 저장해 사용해도 되지만,
코드도 복잡해지고, 코드에서 사용하는 곳과 멀리 떨어진 선행작업이, 시간이 지나 코드를 볼 때, 서비스 로직을 이해하는데 어려움을 줄 수 있습니다.

그래서 절차적으로 필요한 시점에 데이터를 요청하는 코드를 작성해 코드 이해도를 높이면서, 동일한 요청으로 발생할 수 있는 성능상의 불이익도 제거하는 방법을 찾게되었습니다.

저희가 개발해 사용해 오고 있는 monorepo internal_api package에 cacheConfig option을 추가하였습니다.

export type LocalCacheConfig = {
    contextId: string;
    ttl?: number; // milliseconds
};

ttl을 줄 수도 있고, 위의 서비스 코드처럼 contextId: uuidv4()로 사용하면, 서버가 받은 각 요청마다 유효한 cache로 사용하고,
contextId: userId로 사용하면, 다른 요청에서도 이용가능한 cache가 됩니다.

withCache()를 추가 적용한 monorepo internal_api package

    async isAvailableMembership({ userId, artiGroupId }: { userId: string; artiGroupId: string }, cacheConfig?: LocalCacheConfig): Promise<boolean> {
        const cacheKeyMsg = `isAvailableMembership:${userId}:${artiGroupId}`;

        const internalAxiosOperation = async () => {
            const response = await this.internalAxiosService.instance
                .post<MembershipInternalResponse<boolean>>(`${this.#FROMM_MEMBERSHIP_API_DOMAIN}/v2/internal/membershipUsers/available`, { artiGroupId, userId })
                .catch(({ response }) => this.#throwLoggingError(response.status, response.statusText, response.data.errorType ?? 'INTERNAL_SERVER_ERROR', cacheKeyMsg));

            if (!response.data.success) {
                this.#throwLoggingError(HttpStatus.INTERNAL_SERVER_ERROR, response.statusText, response.data.errorType, cacheKeyMsg);
            }

            return response.data.data;
        };

        return cacheConfig ? this.withCache(cacheKeyMsg, internalAxiosOperation, cacheConfig) : internalAxiosOperation();
    }

import { Injectable } from '@nestjs/common';
import NodeCache from 'node-cache';

import { LocalCacheConfig } from './types/local_cache_config.type';

@Injectable()
export abstract class CacheableService {
    protected readonly localCache: NodeCache;
    protected readonly DEFAULT_CACHE_TTL = 60 * 1000; // 1 minute in milliseconds

    protected constructor() {
        this.localCache = new NodeCache({
            checkperiod: 60, // automatic delete check interval in seconds
            useClones: false // true: deep copy
        });
    }

    protected async withCache<InternalResponseType>(key: string, internalAxiosOperation: () => Promise<InternalResponseType>, cacheConfig: LocalCacheConfig): Promise<InternalResponseType> {
        const cacheKey = `${cacheConfig.contextId}:${key}`;
        const cachedResult = this.localCache.get<InternalResponseType>(cacheKey);

        if (cachedResult !== undefined) {
            return cachedResult;
        }

        const responseData = await internalAxiosOperation();

        const ttl = cacheConfig.ttl ?? this.DEFAULT_CACHE_TTL;
        this.localCache.set(cacheKey, responseData, ttl / 1000);

        return responseData;
    }
}

마치며

npm cache package를 추가로 도입하여, 하나의 도메인 서버에서 의존하고 있는 외부의 도메인 이나 데이터를 보다 안정적으로 편리하게 사용할 수 있어,
서비스 로직 구현시, 구현하려는 feature에 더욱 집중할 수 있게 되었습니다.

감사합니다.