Karpenter 트러블슈팅 — 비용과 안정성 두 마리 토끼 잡기안녕하세요, 저는 당근페이 인프라팀에서 Site Reliability Engineer로 일하고 있는 Yany라고 해요. 저희 팀은 당근페이의 인프라를 안정적으로 관리해요. 개발자들의 프로덕트 개발 속도를 향상하고, 동시에 비용도 최적화하죠.저희는 클러스터 오토스케일링 없이 ASG(AWS EC2 AutoScaling Group)로, 그리고 HorizontalPodAutoscaler 없이 클러스터를 관리하고 있었어요. 여기에는 몇 가지 문제가 있었어요:스케일 아웃 과정에서 네트워크에 여러 병목 지점이 생겼어요.클러스터 업데이트를 진행하면서 ASG마다 AMI를 업데이트해야 했고, 오토스케일링이 원활하지 못했어요.컴플라이언스 이슈로 인해 분리된 노드, 서브넷에서 동작해야 하는 워크로드가 증가하면서 ASG가 늘어나 관리 포인트가 증가하고 있었어요.새벽 시간대에 트래픽이 현저히 적은 것에 비해 리소스를 너무 많이 사용하고 있었어요.당근페이의 거래량과 유저 수가 급격히 증가하면서, 기존의 ASG 기반 인프라 운영 방식으로는 한계가 명확해졌어요. 이에 따라 더 유연하고 자동화된 클러스터 스케일링이 필요했고, 그 해답으로 Karpenter를 도입하게 되었어요.그 여정은 저희가 생각한 것만큼 마냥 쉽지만은 않았는데요. 이번 글에서는 그 트러블슈팅 과정을 구체적으로 소개해드리려고 해요. Karpenter 도입을 고민 중이시거나 더 효율적으로 사용할 방법을 찾고 계신다면, 이 글이 큰 도움이 되길 바라요.Karpenter란?Karpenter는 쿠버네티스 클러스터에서 파드의 수요에 맞춰 노드의 양을 조절하는 Cluster Autoscaling Operator에요. 여러 컴포넌트를 통해 원하는 규격의 노드를 생성하고, 생성된 노드의 생명주기를 관리하도록 도와줘요.출처: [https://karpenter.sh/]대표적인 기능은 아래와 같아요:ProvisioningPending 상태의 파드가 존재하면, 스케줄링을 통해 필요한 노드를 생성하여 해당 파드가 스케줄링될 수 있도록 해요.각 CSP(Cloud Service Provider, 저희의 경우 AWS가 여기에 해당해요.)에서 만든 NodeClass 구현체를 통해 인스턴스의 규격을 정해요.- AWS로 가정했을 때 AMI, Subnet, Storage, Security Group, Userdata 등 EC2 인스턴스 자체와 관련된 설정을 진행할 수 있어요.NodePool을 통해 기존 ASG처럼 목적별로 노드를 생성할 수 있어요.- 여러 타입의 인스턴스를 생성할 수 있어, Cluster Autoscaler (이하 CA)보다 훨씬 효율적으로 스케일링을 진행할 수 있어요.DisruptionDrift: NodeClass, NodePool이 바뀌면 Drift를 통해 노드들을 원하는 상태로 Sync할 수 있어요.Consolidation: 충분히 사용하고 있지 않은 노드를 삭제해서 최적화된 양의 리소스를 사용할 수 있어요.- SingleNodeConsolidation

토스증권 PC의 종목 상세 페이지에 접속해 보신 적이 있나요? 종목 상세 페이지에는 차트, 호가, 주문하기 등과 같은 여러 패널들이 여러분을 반겨줍니다.이때 각 패널들은 고정된 위치에 있지 않아요. 마우스로 드래그하면 패널의 위치를 옮길 수도 있고 패널의 크기를 조절할 수도 있습니다. 그리고 화면 편집 버튼을 눌러 패널을 추가하거나 삭제할 수도 있고, 이렇게 움직인 패널들의 레이아웃 상태는 나중에 다시 접속을 해도 저장되어 있습니다.이 레이아웃 기능은 어떻게 구현되어 있을까요? 보통 이렇게 복잡한 인터랙션을 가진 UI를 구현할 때는 “어떤 라이브러리를 쓰지?”를 먼저 생각하곤 하죠. 그런데 토스증권 PC에서는 이 기능을 구현할 때 라이브러리를 사용하지 않고 모두 직접 구현했습니다.왜 토스증권 PC의 그리드 레이아웃을 왜 직접 구현하게 되었는지, 그리고 어떻게 만들어져 있는지를 이제부터 소개해 드릴게요.2024년 중순, 토스증권 PC 서비스가 정식 출시를 위해 한창 달려가고 있었어요. 그런데 그때까지 개발되어 있던 종목 상세 화면의 레이아웃 UI는 현재와 달랐어요. PO와 디자이너분들은 토스증권 PC의 종목 상세 화면을 굉장히 중요한 핵심 기능으로 인식하고 있었는데, 이 화면이 구현되지 않았음을 굉장히 아쉬워하고 있었고 저도 이에 충분히 공감했어요. 그래서 이 기능을 구현하기로 결정했어요.PO와 디자이너분들이 기대하는 완전한 그리드 레이아웃을 만들기 위해선 다음 기능들이 필요했어요.• None 레이아웃을 로컬 또는 서버에 저장• None 패널의 디자인의 자유로운 커스텀꽤나 복잡해 보이죠? 구현이 복잡할 것으로 예상되었기 때문에 당연히 이에 맞는 적절한 라이브러리를 사용해야겠다고 생각하고 어떤 라이브러리가 적절할지 찾아 나서기 시작했어요.문제는 열심히 찾아보아도 요구사항을 모두 만족시키는 라이브러리를 찾을 수 없었어요! 원하는 기능이 모두 있으면 디자인을 자유롭게 커스텀할 수 없고, 디자인을 커스텀할 수 있으면 사용성이 직관적이지 않았어요.모든 요구사항을 만족시키는 라이브러리가 없는 상황에서, 다음 2개의 선택지 중 하나를 골라야 했어요.• None 라이브러리 코드를 커스텀하기어떤 게 더 유리할까요? 지금까지 라이브러리를 사용할 때의 제 경험을 토대로 다음과 같은 그래프를 생각했어요.어떤 문제를 해결할 때 그 문제를 해결하는 것을 상정하고 만들어진 라이브러리를 사용하면 문제를 쉽게 해결할 수 있어요. 라이브러리가 있는데도 직접 다 구현을 하게 되면 바퀴를 재발명하는 상황이 되어 불필요하게 시간을 더 쓰는 결과가 만들어져요. 이 경우에는 라이브러리를 사용하는 것이 직접 구현하는 것보다 리소스 소모가 더 적어서 유리해요.그런데 주어진 문제의 요구사항이 복잡해져서 라이브러리가 상정하고 있는 문제의 범위를 넘어선다면 어떻게 될까요? 그러면 라이브러리를 그대로 사용할 수 없고 코드를 커스텀해서 사용해야 해요. 그런데 라이브러리를 커스텀하게 되면 라이브러리의 원래 구조가 새로운 요구사항에 잘 들어맞지 않는다거나, 라이브러리가 업데이트되었을 때 따라가기

로그 모니터링 시스템은 서비스 운영을 위해서 반드시 필요한 시스템입니다. 로그 모니터링 시스템 구축에는 인덱스 기반의 빠른 검색을 제공하는 검색 엔진인 Elasticsearch가 널리 사용됩니다. 네이버도 Elasticsearch 기반의 로그 모니터링 시스템을 구축했으며, 수천 대의 서버로 수 페타바이트 규모의 로그 데이터를 저장하고 있습니다. 최근 들어 서비스 규모가 확장되고 저장해야 하는 로그 데이터의 규모와 트래픽 양이 급속도로 증가하면서 Elasticsearch 기반의 로그 모니터링 시스템은 비용 문제와 더불어 확장성 문제에 직면하게 됐습니다.네이버는 저비용으로 대용량의 로그 데이터를 수집할 수 있도록 Apache Iceberg(이하 Iceberg)를 도입한 신규 컴포넌트 Alaska를 개발해 네이버의 로그 모니터링 시스템 플랫폼 NELO에 적용했습니다. 이 글에서는 기존 로그 모니터링 시스템의 문제와 Iceberg의 특징을 소개하고, Alaska의 작동 방식과 Alaska를 NELO에 적용한 이후의 변화를 소개합니다.Elasticsearch 기반 기존 로그 모니터링 시스템의 한계Elasticsearch를 기반으로 구축된 기존 로그 모니터링 시스템의 구조를 간략하게 도식화하면 다음 그림과 같습니다.클라이언트로부터 수신된 로그 데이터는 Kafka에 적재된 후 Elasticsearch에 저장됩니다. Elasticsearch는 SSD 타입의 스토리지로 구성된 Hot 계층(Hot Tier)과 HDD 타입의 스토리지로 구성된 Warm 계층(Warm Tier)으로 구분되어 있습니다. 로그 데이터는 Hot 계층에 3일간 저장된 후 Warm 계층으로 이동되어 최대 90일까지 저장됩니다. 이렇게 Hot 계층과 Warm 계층의 두 단계로 나누어 데이터를 저장하면 검색이 빈번하게 일어나지 않는 데이터를 효율적이면서 저비용으로 저장할 수 있습니다.기존 로그 모니터링 시스템은 수년간 이와 같은 구조로 운영되었습니다. 그동안 데이터가 증가함에 따라 Warm 계층에 저장된 데이터의 크기도 급증했습니다. Elasticsearch는 단일 클러스터로 저장할 수 있는 데이터의 크기에 제한이 있기 때문에 다수의 Elasticsearch 클러스터를 구성해 클러스터 수준에서 확장을 진행했습니다. 그 과정에서 모든 클러스터가 한계 수준까지 도달해 운영 장애를 빈번하게 겪었습니다. 연간 수십억 원의 인프라 사용 비용도 부담이 되었습니다. 두 계층으로 구성된 Elasticsearch 클러스터는 더 이상 로그를 효율적으로 저장할 수 있는 구조가 아니게 되었습니다. 새로운 타입의 데이터 저장 스토리지의 필요성Warm 계층에 저장된 데이터의 크기가 급증하는 이유에는 장기간 로그의 저장에 대한 요구 사항도 있습니다. 기존 로그 모니터링 시스템은 Elasticsearch에 최대 90일까지 로그 데이터를 저장할 수 있게 허용했습니다. 하지만 서비스의 법적 요구 사항 등의 이유로 예외로 1년 이상의 로그 데이터 저장을 허용하고 있었습니다. 기존 로그 모니터링 시스템이 한계에 도달하면서

1. 에이닷의 LLM search 기능아래는 "LLM 최신 연구 동향 알려줘" 라는 질문에 대한 adot.ai 의 GPT-4o-mini 답변입니다.흥미롭게도, 아래처럼 에이닷 모바일 앱에서는 동일한 질문에 대해 위 예시보다 훨씬 더 풍부하고 정확한 답변을 제공하고 있습니다.동일하게 GPT-4o-mini를 기반으로 하는데도 이러한 품질 차이가 발생하는 이유는 무엇일까요?바로 접근 방식의 차이에 있습니다.첫 번째 예시는 단순히 LLM만 활용한 반면, 에이닷 모바일 앱은 LLM과 검색 기능을 결합한 'LLM search' 시스템을 구축했기 때문입니다.에이닷은 답변 하단에 빨간색 네모로 표시된 출처 웹페이지들을 실시간으로 스크래핑하여 최신 정보를 LLM에 제공합니다.이러한 접근 방식을 통해 사전 학습 데이터의 한계를 넘어 최신 정보를 반영한 더욱 상세하고 정확한 답변을 생성할 수 있게 되었습니다.2. LLM과 LLM Search의 주요 차이점LLM은 학습된 데이터를 기반으로 텍스트를 생성하고 이해하는 데 특화되어 있지만, 실시간 정보 검색이나 출처 제공에는 한계가 있습니다.이러한 한계를 극복하고자 LLM Search는 아래와 같은 기능을 추가로 제공합니다.참고로 작년 말부터 오픈AI도 검색과 출처 제공을 시작했습니다.에이닷의 LLM search 엔진 - PAAS 프로젝트현재 에이닷의 LLM search 엔진은 PAAS입니다.GPT-4o-mini 사용을 제외한 나머지 LLM search 기능들은 SKT에서 직접 개발했으며, 프로젝트명은 PAAS (PAA Search)입니다.PAAS의 데이터 흐름은 아래와 같습니다.위 이미지에서 빨간색 네모로 표시된 두 부분이 바로 오늘 소개해 드릴 HTML 본문 추출기입니다.지금부터 HTML에서 더 깔끔하고 정확하게 본문을 추출하기 위해 그동안 연구하고 고민했던 내용들을 공유해 드리겠습니다.실시간 본문 추출기는 다음과 같은 제약 조건을 충족해야 합니다:• None 본문 추출 작업은 1초 이내에 완료되어야 합니다• None 전체 프로세스(HTML 가져오기 + 본문 추출)는 4초 이내로 제한됩니다• None HTML 가져오기에 최대 3초가 소요되므로, 본문 추출에 쓸 수 있는 시간은 1초만 남게 됩니다.• None 문서 크기는 최소화하되 중요 정보의 손실이 없어야 합니다.• None LLM 토큰 제한으로 인해 모든 문서(최대 10개)의 총 텍스트는 3만 자 이내여야 합니다• None 광고, 메뉴, 목록 등 검색에 불필요한 요소들은 가급적 제거해야 합니다• None 벤치마크 라이브러리인 trafilatura보다 우수한 성능을 보여야만 실제 서비스에 적용됩니다기존 방식과 초기 아이이디어들• None 본문이나 중요한 내용이라고 잘 알려진 HTML 속성들만 사용하는 방식입니다.• None trafilatura 는 이와 같은 방식을 사용하고 있습니다.• None• None 설정 파일의 수동 관리와 부정확한 태그 지정은 중요 정보의 누락을 초래할 수 있습니다.• None 사용자 쿼리나 og tag 의 title, descrip