고가용성(High Availability) AWS Lambda 서버 구축

들어가며

노머스는 latency가 중요한 서비스는 ECS Fargate로 운영하지만, 많은 서비스를 AWS Lambda로 운영하고 있습니다.
AWS Lambda 배포 관리는 serverless framework과 github actions을 사용하고 있습니다.

AWS Lambda는 서버리스 컴퓨팅의 핵심 장점들을 제공합니다.

• 서버 관리 없이 자동 확장: 트래픽 변화에 따라 자동으로 스케일 업/다운되어 인프라 운영 부담이 적습니다.
• 종량제 과금: 실제 코드 실행 시간과 요청 수만큼만 비용이 발생하여 비용 효율적입니다.
• 빠른 배포와 수정: 코드만 업로드하면 즉시 반영되어 개발 속도가 향상됩니다.

하지만 AWS Lambda에는 예측하기 어려운 부분이 있습니다. 바로 함수가 언제 종료될지 알 수 없다는 점입니다.

정상적인 처리 완료 후 언제 종료될지 모르는 것은 그렇다 치더라도,
(정상적인 종료도 알 수 있으면, redis의 부담을 줄여줄 수 있는 swap out 같은 기능을 구현해 볼 수 있습니다.),
비정상적인 종료는 서비스를 운영하는 입장에서 간과하기 어려운 문제입니다.

AWS 는 Lambda Failures 에 대해 다음과 같은 문서를 제공합니다.
https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html
저희는 이 문서를 기반으로 어떻게 고가용성 AWS Lambda 서비스를 구축할 수 있는지에 대해 소개하고자 합니다.

Lambda Failures

1. Timeout

AWS Lambda 함수는 기본적으로 3초의 타임아웃을 가지고 있고, 최대 15분까지 설정할 수 있습니다.
타임아웃이 발생하면 Lambda 함수는 비정상적으로 종료되며, 이로 인해 데이터 손실이나 서비스 중단이 발생할 수 있습니다.
Lambda 기반으로 한 새로운 서비스를 배포할 때, request event에 따라, 적절한 타임아웃 값을 설정하지만,
이후 점진적으로 증가할 수 있는 서비스 부하에서 타임아웃의 발생여부를 인지하지 못할 수 있습니다.

특히 타임아웃에 주목하게 된 이유는, 이것이 DB 과부하의 사전 징후로 나타나는 경우가 많았기 때문입니다.
트래픽이 증가할 때 Lambda는 확장에 제약이 없지만, DB는 Lambda 만큼 동적 특성이 좋지 않았습니다.
따라서 타임아웃이 발견되면 해당 서비스의 부하 테스트를 다시 검토해야 했습니다.

2. Runtime Crash

저희 팀에서 개발시, 자주 하는 실수 중에 하나가, TypeOrmModule.forFeature()에 Entity를 등록하지 않는 것입니다.
그럴 경우, 아래와 같은 에러가 발생합니다. 이는 Lambda 시작 시 엔티티 메타데이터를 찾지 못해 발생하는 런타임 크래시의 대표적인 예시입니다.

TypeORMError: Entity metadata for <Table>#<Relation> was not found. Check if you specified a correct entity object and if it's connected in the connection options.
at /var/task/src/<WorkSpace>/lambda.js:205408:19
at Array.forEach (<anonymous>)
at EntityMetadataBuilder.computeInverseProperties (/var/task/src/<WorkSpace>/lambda.js:205405:34)
at /var/task/src/<WorkSpace>/lambda.js:204908:58
at Array.forEach (<anonymous>)
at EntityMetadataBuilder.build (/var/task/src/<WorkSpace>/lambda.js:204908:25)
at ConnectionMetadataBuilder.buildEntityMetadatas (/var/task/src/<WorkSpace>/lambda.js:205797:150)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async DataSource.buildMetadatas (/var/task/src/<WorkSpace>/lambda.js:207373:33)
at async DataSource.initialize (/var/task/src/<WorkSpace>/lambda.js:207083:11)

그리고, 얼마전 큰 Object 인지 모르고, logger로 출력하다가, OOM(Out Of Memory) 에러가 발생했습니다.
서비스 뒷단에서 도는 Batch Lambda라, CS를 받고서 알게된 장애였습니다.

<--- Last few GCs --->
[2:0x558c38855fa0]    22535 ms: Scavenge 892.7 (937.2) -> 892.5 (938.0) MB, 18.35 / 0.00 ms  (average mu = 0.900, current mu = 0.768) allocation failure;
[2:0x558c38855fa0]    22559 ms: Scavenge 893.6 (938.0) -> 893.3 (943.0) MB, 3.13 / 0.00 ms  (average mu = 0.900, current mu = 0.768) allocation failure;
[2:0x558c38855fa0]    22876 ms: Mark-Compact 896.4 (943.0) -> 895.7 (946.2) MB, 273.55 / 0.00 ms  (average mu = 0.798, current mu = 0.432) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0x558c13879cf3 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/var/lang/bin/node]
2: 0x558c13c452cd v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/var/lang/bin/node]
3: 0x558c13c45699 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/var/lang/bin/node]
4: 0x558c13ebe25a  [/var/lang/bin/node]
5: 0x558c13ed8c2e v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/var/lang/bin/node]
6: 0x558c13ea88f2 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/var/lang/bin/node]
7: 0x558c13ea9f74 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/var/lang/bin/node]
8: 0x558c13e8305b v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/var/lang/bin/node]
9: 0x558c13e6af23 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [/var/lang/bin/node]
10: 0x558c13e6db26 v8::internal::FactoryBase<v8::internal::Factory>::NewRawOneByteString(int, v8::internal::AllocationType) [/var/lang/bin/node]
11: 0x558c143bc88d v8::internal::IncrementalStringBuilder::Extend() [/var/lang/bin/node]
12: 0x558c14020ea8 v8::internal::JsonStringifier::SerializeString(v8::internal::Handle<v8::internal::String>) [/var/lang/bin/node]
13: 0x558c1402201a v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_<true>(v8::internal::Handle<v8::internal::Object>, bool, v8::internal::Handle<v8::internal::Object>) [/var/lang/bin/node]
14: 0x558c14026a91 v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_<false>(v8::internal::Handle<v8::internal::Object>, bool, v8::internal::Handle<v8::internal::Object>) [/var/lang/bin/node]
15: 0x558c14023ecd v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_<true>(v8::internal::Handle<v8::internal::Object>, bool, v8::internal::Handle<v8::internal::Object>) [/var/lang/bin/node]
16: 0x558c140248cf v8::internal::JsonStringifier::SerializeJSReceiverSlow(v8::internal::Handle<v8::internal::JSReceiver>) [/var/lang/bin/node]
17: 0x558c1402619a v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_<false>(v8::internal::Handle<v8::internal::Object>, bool, v8::internal::Handle<v8::internal::Object>) [/var/lang/bin/node]
18: 0x558c14027949 v8::internal::JsonStringify(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [/var/lang/bin/node]
19: 0x558c13cf015d v8::internal::Builtin_JsonStringify(int, unsigned long*, v8::internal::Isolate*) [/var/lang/bin/node]
20: 0x558c148091b6  [/var/lang/bin/node]
END RequestId: f7bd706c-3c22-44f2-a687-5192a09f71c3
REPORT RequestId: f7bd706c-3c22-44f2-a687-5192a09f71c3	Duration: 27627.15 ms	Billed Duration: 27628 ms	Memory Size: 1024 MB	Max Memory Used: 1024 MB	Init Duration: 1330.79 ms	Status: error	Error Type: Runtime.ExitError
XRAY TraceId: 1-685cb8e4-6ec7902913ad62f42e821e12	SegmentId: fe04f33977304521	Sampled: true 

이 Log Metric 모니터링 시스템이 구축되기 전에는 인지하지 못했던 런타임 크래쉬도 있었습니다. 😭
API Cache에 null 값을 저장하려고 시도했을 때 발생한 런타임 크래쉬입니다.

2025-07-17T09:08:32.363Z	49917c08-5711-4d3a-a945-80cb6ad821f7	ERROR	Unhandled Promise Rejection 	{
    "errorType": "Runtime.UnhandledPromiseRejection",
    "errorMessage": "Error: \"null\" is not a cacheable value",
    "reason": {
        "errorType": "Error",
        "errorMessage": "\"null\" is not a cacheable value",
        "stack": [
            "Error: \"null\" is not a cacheable value",
            "    at /var/task/src/arti/lambda.js:369323:25",
            "    at new Promise (<anonymous>)",
            "    at Object.set (/var/task/src/arti/lambda.js:369311:18)",
            "    at Object.set (/var/task/src/arti/lambda.js:281628:43)",
            "    at Object.next (/var/task/src/arti/lambda.js:282191:37)",
            "    at /var/task/src/arti/lambda.js:30379:78",
            "    at OperatorSubscriber2._this._next (/var/task/src/arti/lambda.js:25392:13)",
            "    at OperatorSubscriber2.Subscriber2.next (/var/task/src/arti/lambda.js:24521:16)",
            "    at /var/task/src/arti/lambda.js:26805:24",
            "    at OperatorSubscriber2._this._next (/var/task/src/arti/lambda.js:25392:13)"
        ]
    },
    "promise": {},
    "stack": [
        "Runtime.UnhandledPromiseRejection: Error: \"null\" is not a cacheable value",
        "    at process.<anonymous> (file:///var/runtime/index.mjs:1326:17)",
        "    at process.emit (node:events:524:28)",
        "    at process.emit (/var/task/src/arti/lambda.js:2227:25)",
        "    at emitUnhandledRejection (node:internal/process/promises:250:13)",
        "    at throwUnhandledRejectionsMode (node:internal/process/promises:385:19)",
        "    at processPromiseRejections (node:internal/process/promises:470:17)",
        "    at processTicksAndRejections (node:internal/process/task_queues:96:32)"
    ]
}

REPORT RequestId: 49917c08-5711-4d3a-a945-80cb6ad821f7	Duration: 534.29 ms	Billed Duration: 535 ms	Memory Size: 512 MB	Max Memory Used: 246 MB	Status: error	Error Type: Runtime.ExitError
XRAY TraceId: 1-6878bd8f-19a92cbd3ea1be424772578d	SegmentId: 3bd62ade4f027f28	Sampled: true	

구현

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html 에서는 총 4가지의 Lambda Failures를 소개합니다.

Example CloudWatch Logs log output (runtime or extension crash) - old style

START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
Runtime.ExitError
END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB

Example CloudWatch Logs log output (function timeout) - old style

START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3000 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms
The new format for CloudWatch logs includes an additional statusfield in the REPORT line. In the case of a runtime or extension crash, the REPORT line also includes a field ErrorType.

Example CloudWatch Logs log output (runtime or extension crash) - new style

START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 133 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError

Example CloudWatch Logs log output (function timeout) - new style

START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3016 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout

Log Filter Strings

위 4가지의 Lambda Failures에서, 저희는 아래 표의 문자열을 기준으로 CloudWatch Logs에서 필터링하여, 알림을 받도록 구현했습니다.

style	Timeout	Runtime Crash
old	Task timed out after	Error: Runtime exited without providing a reason
new	Status: timeout	Status: error, Error Type: Runtime.ExitError

아키텍쳐

CloudWatch Metric → CloudWatch Alarm → SNS → Lambda (슬랙 장애 채널로 알림)

저희는 aws-sdk를 이용하여, CloudWatch Logs에 Metric Filter와 Metric Alarm을 등록 했습니다.

import { CloudWatchLogsClient, PutMetricFilterCommand } from '@aws-sdk/client-cloudwatch-logs';
import { CloudWatchClient, PutMetricAlarmCommand } from '@aws-sdk/client-cloudwatch';

기존에 만들어진 Lambda는 DescribeLogGroupsCommand 를 통해, Metric Filter와 Metric Alarm을 등록 시켜주고,

import { CloudWatchLogsClient, DescribeLogGroupsCommand } from '@aws-sdk/client-cloudwatch-logs';

새로 만들어질 Lambda는 CreateLogGroup 이벤트를 통해, Metric Filter와 Metric Alarm을 등록 시켜줍니다.

    CreateMetric:
        handler: src/create_metric/lambda.handler
        events:
            - eventBridge:
                  pattern:
                      source:
                          - aws.logs
                      detail-type:
                          - AWS API Call via CloudTrail
                      detail:
                          eventSource:
                              - logs.amazonaws.com
                          eventName:
                              - CreateLogGroup

마치며

이제 저희는 AWS Lambda의 타임아웃과 런타임 크래시를 모니터링하고, 알림을 받을 수 있는 시스템을 갖추게 되었습니다.
이 시스템은 서비스의 안정성을 높이고, 장애 발생 시 빠르게 대응할 수 있는 기반이 될 것입니다.
앞으로도 AWS Lambda를 활용한 서비스 운영에서 발생할 수 있는 다양한 문제들을 해결하기 위해 지속적으로 노력할 것입니다.
이 글이 AWS Lambda를 운영하는 다른 개발자들에게도 도움이 되기를 바랍니다.

감사합니다.