설 연휴 때 인사를 드린 게 엊그제 같은데 벌써 추석이 성큼 다가왔습니다. 올 한 해가 100일도 남지 않았기에 많은 분들께서 긴 추석 연휴를 빌어 한 해를 되돌아보고 남은 2023년도를 알차게 보내기 위해서 특별한 계획을 세우고 계실 것 같습니다.• 구성원을 위한 특별한 2023 설 선물 : 바로가기오피지지는 올 한 해도 열심히 달려오신 구성원분들을 위해서 추석선물을 준비하였습니다. 이번 선물의 테마는 Game입니다. 오피지지는 게임 서드파티 업계에 새로운 바람을 몰고 온 만큼 게임을 다양하게 즐길 수 있는 방법을 제시해왔습니다. 이런 오피지지의 행보는 결국 게임을 더욱더 재미있게 만드는 것이 목표라 생각합니다. 그렇기에 이번 추석선물은 구성원분들이 혼자 또는 누군가와 함께 즐겼던 게임을 하던 시기로 돌아가서 행복한 시간을 보내기를 바라며 준비하게 되었습니다.그럼 오피지지가 이번에는 어떤 생각으로 추석선물을 준비하였는지 소개해 드리겠습니다.초등학교 수업이 끝나고 친구들과 학교 앞 문방구에서 했던 갤러그 게임을 기억하시나요? 게임 테마에 어울리게 선물박스과 메시지 카드도 오피지지가 최종 보스인 갤러그 게임 컨셉으로 디자이너분께서 작업해주셨습니다🤓 역대급 디자인이라는 찬사를 받은 만큼 박스 하나만으로도 구성원분들께 설레는 기분을 드릴 수 있어서 기뻤습니다!고스톱은 한국인이라면 가족들과 모여서도 해보고 온라인 게임으로도 해봤을 게임입니다. 일반적으로 게임이라고 하면 RPG 게임, 스틱게임을 흔히들 떠올리시겠지만 전통적인 고스톱이야말로 우리에게 처음 게임이란 게 무엇인가를 알게 해준 첫 놀이이지 않을까 싶습니다. 전통적인 화투패 디자인과는 사뭇 다른 모습입니다. 똑같은 화투 패라도 새롭게 디자인했다는 점이 게임업계에 새로운 관점을 제시한 오피지지와 닮은 것 같아 구성원분들께 선물로 드리게 되었습니다.500개 이상의 추억의 게임을 담은 보조배터리입니다. TV에 연결해서 게임을 즐길 수 있습니다. 누구나 어린시절에 해봤을 게임이기에 나이 불문하고 혼자 또는 같이 즐길 수 있습니다🎮🕹️한 번쯤은 게임 속 물건들을 현실에서 사용하고 싶다는 생각을 해보셨을 것 같습니다. HP 비누는 포션을 실제로 사용해 보고 싶다는 아이디어에서 출발해서 제작하게 되었습니다. 각 비누마다 향이 다르기에 비누를 사용할 때마다 리프래시 되어 HP가 회복되는 느낌을 받을 수 있습니다💪일상생활을 하다 보면 퀘스트 같은 하루가 있습니다. 햇빛이 강하거나 비와 눈이 오는 상황이 특히 그렇습니다. 나가기 싫지만 ‘날씨를 이겨내야 하는 퀘스트로 생각한다면 일상이 게임처럼 즐겁게 느껴지지 않을까?’ 해서 준비하게 되었습니다.오피지지하면 떠오른 것 중 하나가 매번 독특하고 예쁜 디자인으로 교체되는 오피지지 웹페이지 로고입니다. 예쁜 로고를 쿠키에 담아서 드린다면 선물을 받아보시는 분들께서 그동안 오피지지가 지나온 시간들과 오피지지와 함께 해온 게임 경험을 떠올릴 수 있을것 같습니다. 쿠키에 담지못한 멋진 로고들은 오피지지 웹페이지에서 확인가능합니다🤭• 로고 히스토리 : 바로가기이번 추석

안녕하세요! 스푼라디오 Business Platform팀에서 서버 개발을 담당하고 있는 조민제(Jay)입니다. 🙌지난 6개월 동안 스푼라디오에서 일하며 깨달았던 몇 가지 경험을 공유해 보려고 합니다. 입사를 결정하게 된 이유부터 입사 초기와 지금을 비교해 보며 배웠던 점에 대해 적어보겠습니다.😃 왜 스푼라디오에 입사하게 되었나요?빠른 성장을 할 수 있을 것 같아 지원하게 되었는데요! Spring WebFlux와 MSA구조도 경험해 보고 싶었고, 국내뿐 아니라 해외에서도 활발히 서비스하고 있는, 글로벌 서비스를 경험해 보고 싶었습니다. 그뿐만 아니라, 백엔드 개발자의 성장에 있어 큰 도움이 되는 대규모 트래픽 처리 경험도 할 수 있을 것 같아 스푼라디오에 지원하게 되었습니다. 그리고 제일 중요한 4.5일제도 빼놓을 수 없죠문서화를 통한 서비스 이해입사 전, 사이드 프로젝트를 진행하며 문서화에 대한 중요성을 크게 느끼지는 못했습니다. 개발자들 간의 협업을 위한 문서 작성은 시간 낭비처럼 느껴졌는데요.그러나 입사 후에 문서화의 중요성을 몸소 느꼈습니다. 사내 백오피스를 담당하면서 복잡한 기능 구조와 그에 대한 문서의 부재로 많은 어려움을 겪었습니다.유닛 리드 Charles가 부족한 문서화를 필요한 사람이 한발 앞서 하면 이후 동료들이 같은 어려움을 겪지 않을 수 있지 않겠냐는 말을 듣고 수동적이었던 제 모습을 반성하게 되었습니다.그 이후부터는 복잡한 기능을 마주칠 때마다 코드 한줄 한줄 따라가보며 문서화를 진행하였습니다.제가 문서화를 하며 느낀 이점은 2가지입니다.구조화문서를 작성하다 보면, 자연스럽게 해당 내용을 구조화하게 되는데요. 이 과정에서 작성 중인 내용 전반에 대한 큰 틀이 잡히고 이해도가 향상됩니다.나와 팀원들을 위한 좋은 참고 자료한번 문서를 작성해 놓으면, 보다 빠른 히스토리 파악을 할 수 있다는 점에서 해당 내용을 잊어버릴지 모르는 미래의 나와 동료들에게 도움이 된다는 점입니다.신입 개발자에게 코드리뷰란이제 막 입사한 신입 개발자로서 처음 서비스 코드를 마주했을 때, 무수히 많은 질문들이 머릿속을 맴돌았습니다. “왜 이렇게 코드가 짜여 있을까?” 그런 질문들은 처음에는 간단하게 ‘나름의 이유가 있었겠지’ 라는 생각으로 털어버렸습니다.하지만 시간이 지나며, 담당한 서비스에 대한 이해가 생기며 그동안 놓쳐왔던 개선해야 할 점들이 눈에 들어오기 시작했습니다. 그런데 바로 행동으로 옮기기는 쉽지 않았습니다. 당장 눈에 보이는 개선점부터 고치기로 마음먹고 고치기 시작하다 보면 해당 부분에 의존하고 있는 코드들이 많이 있어 중간에 포기하게 되었습니다.그러다 생각한 방법은 ‘코드리뷰’였습니다. 매일 나에게 할당되는 코드리뷰를 통해 소스코드의 유지보수에 조금씩, 점진적으로 기여하고자 했습니다.사실 이전에는 ….코드리뷰 요청이 들어오면, 바로 PR링크를 클릭해 보지만 바뀐 파일이 72개라니… 시간을 내서 제대로 봐야 할 것 같습니다. 그렇게 열심히 일을 하다 보니 퇴근 시간이 가까워졌고 미루어 두었던 PR 링크를 보니 문제가 없어 보이네요!

광고 클릭 이벤트 저장과 관련된 작업을 하다가 Redis에 데이터를 JSON 형태로 압축 없이 저장하는 것과, 그 이벤트는 광고 클릭마다 쌓이기 때문에 양이 아주 많다는 사실을 알게 됐습니다. 평소에도 해당 Redis의 메모리 사용량에 대한 PagerDuty를 새벽 6시에 가끔 받은 기억이 있어서 줄여보면 좋겠다는 생각을 하게됐습니다. 또한 하나의 Redis를 두 서비스에서 공유함에도 JSON schema 없이 각자 코드에서 본인에 맞게 모델을 정의한 문제도 발견했습니다. 광고 클릭 이벤트의 특성상 갑작스럽게 traffic spike가 발생할 수 있으므로 cache.r6g.2xlarge 2~8대를 사용했고 비용 절감을 목적으로 작업을 시작했습니다.Protobuf는 다양한 언어의 코드를 생성해 주는 가 있으므로 공유를 쉽게 할 수 있습니다. 구글처럼 하나의 Protobuf repository를 만들고 모든 서비스가 한 repository를 바라보게 할 수도 있지만, 저희의 경우 아직 서비스간 schema가 자리 잡지 않았고, 이 작업은 두 서비스만 사용할 게 확실했기 때문에 한 서비스의 코드에 Protobuf를 두고 패키징해서 다른 서비스에 제공하는 방식을 선택했습니다. Golang으로 작성된 서비스 G, Python으로 작성된 서비스 P가 있을 때, 모델에 대한 책임은 대부분의 적재가 일어나는 G에 있다고 판단해서 Protobuf와 함께 패키징 코드를 G에 뒀습니다. 그 때문에 G에 있는 Protobuf가 변경되면 G의 CI에서 컴파일된 Python 패키지를 빌드 후 사내 PyPI에 업로드하도록 구성했습니다. P에서는 패키지 버전만 올리면 변경된 모델을 사용할 수 있습니다.Elasticache는 Redis의 비밀번호 기반 인증과 더불어 AWS IAM 기반 인증을 추가로 지원합니다. IAM 기반 인증을 사용하면 비밀번호를 생성하고, 어딘가 저장하고, 서비스 컨테이너에 주입하지 않고도, 서비스 컨테이너의 AWS 계정 & 역할을 통해 직접 인증할 수 있습니다. 이것을 적용해서 하루 정도 잘 사용하고 있었는데, 어느 순간 조회하는 API가 타임아웃이 발생해서 확인해 보니 IAM 기반 인증이 원인이었습니다. 어느 순간 WRONGPASS로 Redis client들이 접근에 실패하고, redis golang 라이브러리의 재시도 때문에 많은 커넥션이 Redis 서버에 쌓이면서 조회 또한 느려져서 발생한 문제였습니다. IAM 기반 인증을 배포한 지 26시간이 지나서 인증 토큰의 TTL 때문은 아니었던 것 같았고, 다른 원인을 찾아봐야 했습니다. 하지만 작업 목표를 생각했을 때, 비밀번호 대비 IAM 기반 인증의 편의성은 부수적인 목표라서 빠르게 딥다이브를 포기하고 비밀번호 기반 인증을 선택했습니다.

최대 24배의 성능을 보인 vLLM, 코드 레벨까지 분석해보자!LLM 시대로 들어오면서 서빙을 위한 다양한 최적화 방식들이 많이 개발되고 연구되고 있죠. 오늘은 허깅페이스 대비 최대 24배까지 성능을 높일 수 있었던 vLLM에 대해 분석해 보고자 해요. 지금 분석하고자 하는 내용은 vLLM이 릴리즈된지 얼마 안 됐을 때의 구현체 (v0.1.2)에 기반하기 때문에 일부 변경된 사항이 있을 수 있다는 점을 고려해 주세요. 코드 레벨까지 상당히 깊은 내용을 포함하고 있기 때문에 깊은 이해를 원하시는 분들께 추천합니다!vLLM은 PagedAttention 기법을 활용하여 문장 생성 속도를 비약적으로 높인 방법론이에요. 이뿐만 아니라 실제 서빙을 위해 많은 요소들이 포함되어 있죠. 예를 들어 멀티 클러스터 환경에서 안정적인 서빙을 하기 위한 Ray Cluster를 사용하거나 큰 모델과 데이터를 병렬로 처리할 수 있도록 Megatron LM의 Parallelism을 차용하고 있습니다. Ray Cluster나 Megatron LM은 관련된 많은 글들이 있으니 여기서는 설명을 생략하고, 이번 블로그에서는 vLLM의 핵심 기술이라고 볼 수 있는 PagedAttention과 Continuous Batching 기법을 코드 레벨까지 파악해 볼게요.vLLM의 전체적인 구조입니다. 에서 분산 처리를 위한 워커, PagedAttention의 블록을 관리하는 블록 매니저, KV 캐시 등을 관리하는 컴포넌트들을 생성하고, 매 요청 시 스케줄러를 통하여 요청된 프롬프트들의 생성 순서를 바꿔줍니다. LM에서 문장을 생성하기 위해서는 마지막 토큰이 나올 때까지 모델에 반복적으로 포워딩 해야 하는데, 스케줄러에 의해 메모리 및 우선순위를 따져 효율적인 방법으로 GPU 유틸리티를 달성하고 있습니다. 메모리의 효율성을 더욱 높이기 위해 PagedAttention 기법을 사용하며, GPU 메모리가 부족할 경우 CPU 메모리에 스왑하는 방식으로 중간 계산 과정들에 대해서도 안정적으로 관리하고 있습니다.이제 위 컴포넌트들 사이의 관계와 흐름을 차근차근 분석해 보겠습니다.vLLM의 가장 기본적인 사용 방법으로, 클래스를 만들어 함수로 문장을 생성할 수 있습니다.위 코드는 함수가 받는 인자의 목록입니다. 변수에 문자열로 이루어진 프롬프트의 리스트를 입력받고, 인자를 받아 생성하고 있습니다.함수의 로직입니다. 가 주어지지 않고 가 주어지면 이미 인코딩된 토큰들로 생성하고 있습니다. 그리고 생성은 각 프롬프트 별로 로 프롬프트를 하나씩 넣어주며, 모두 넣어주었다면 을 호출하고 있습니다.함수에서는 로 추가한 모든 프롬프트에 대해 완료될 때까지 을 호출하고 있습니다. 함수는 모델 포워딩을 한 번 하여 배치 내의 프롬프트에 대한 토큰들을 하나씩 생성합니다.은 실제 생성을 담당하는 엔진입니다. 초기화할 때 생성에 필요한 컴포넌트들(토크나이저, 워커, 스케줄러 등)을 모두 생성하고 초기화합니다. 이때 워커(Worker)는 병렬 작업을 위해 랭크마다 하나씩 생성합니다. 병렬화는 MegatronLM의

2022년을 회고하며…중고나라에는 초단위로 많은 유저들이 접속하여 상품을 등록하고 구매합니다. 이렇게 쌓인 로그, 상품, 채팅, 결제 내역 등 다양한 데이터들이 S3, RDB, ElasticSearch 등에 저장되고 있습니다.데이터 분석 as-is (ver 2022)2022년, 제가 입사했을 시에는 다른 부서에서 데이터 추출 및 분석 업무 지원 요청을 받으면 서비스용 데이터베이스에 부하를 일으키지 않는 선에서 데이터를 추출, 가공하여 드렸습니다.하지만, 회사가 빠르게 성장하고 발전하면서 자연스레 데이터 분석에 대한 니즈가 증가하였습니다. 서비스용 데이터베이스에 분석용 쿼리가 증가하고, 분석하고자하는 데이터의 크기, 기간이 점차 늘었습니다.높아진 데이터 니즈로 인해 아래와 같은 문제점이 하나, 둘씩 발생하기 시작하는데…..😱분석용 쿼리로 인한 DB 부하서비스에 사용하는 쿼리와 분석 목적으로 실행하는 쿼리는 같은 SQL문이여도 성격이 다릅니다.서비스 목적 쿼리는 빠르게 쿼리 결과를 얻어 유저들에게 서비스를 제공할 목적이고, 분석용 쿼리는 장기간 데이터를 그룹화하여 통계치를 추출하거나 데이터 간 패턴을 파악하려는 목적으로, 속도 측면에서는 어느정도 레이턴시가 허용되지만, 그만큼 쿼리 하나의 cpu 점유율이 높습니다.아래는 위 내용을 조금 더 자세히 정리한 표입니다.또한, 서비스용 데이터베이스는 유저들에게 빠른 서비스를 제공할 목적으로 컬럼 인덱싱이 되어있기 때문에, 분석용 쿼리는 해당 인덱싱을 활용하지 못해 더욱더 실행 시간이 오래 걸리게 되고, 이로 인해 서비스용 데이터베이스에 부하를 일으키는 경우가 종종 발생하였습니다.장기간 데이터 분석의 한계유저 행동 데이터는 파일 시스템으로 저장하고, 최근 3개월의 일부만 분석을 위해 ElasticSearch에 색인했습니다. 그러나 점차 반년, 1년치 데이터 분석의 니즈가 늘어났고, 이를 대응하기 위해 Spark⭐️를 사용하는 일도 증가하였습니다.추출 업무 증가긴 기간 분석 니즈와 함께, 대량 데이터에 대한 분석 요청이 증가하면서 추출 업무가 1년 사이 폭발적으로 늘어나, 추출 업무 관련자들의 퇴근 시간이 점점 늦어지고마는데………DW의 도입위와 같은 문제점을 해결하기 위하여 데이터웨어하우스(DW)를 도입을 결정하였습니다.데이터웨어하우스로는 AWS 에서 제공하는 redshift, GCP의 BigQuery, 오픈 소스의 ClickHouse 가 있는데요, 중고나라에서는 AWS 클라우드를 사용 중이며 이 외에 BigQuery나 오픈소스를 사용하였을 때 고려해야할 관리 포인트, 비용 등을 고려하여 AWS Redshift를 선정하였습니다.Redshift 는 Massive Parallel Processing(a.k.a MPP, 병렬 컴퓨팅) 기반의 columnar 데이터웨어하우스로, 대용량 데이터를 SQL 로 분석할 수 있습니다.구축기a) RDB우선, 데이터 분석 시 이전과 동일한 쿼리를 사용할 수 있도록, 서비스용 RDB에 저장된 데이터들을 Redshift 에 저장하는 작업이 필요했습니다.위 작업을 구현하기 위해

https://unsplash.com/photos/sfjS-FglvU4안녕하세요, 29CM 모바일팀 리드/iOS 개발자 김우성입니다. 지난 글 이후 오랜만에 글을 작성하게 되었는데요, 이번 글에서는 저희 팀이 오랜 기간에 걸쳐 개선해 온 개발 프로세스에 대한 얘기를 해볼까 합니다.저희 29CM 모바일팀은 전사적으로 추구하는 업무 문화인 29WAY 와 함께 지속적인 팀 성장과 프로세스 개선을 진행해오고 있있는데요, iOS팀에서는 이 목표를 달성하기 위해 지금까지 여러 도구를 도입하거나 프로세스를 시도해 왔었습니다.그 중에서도 Trunk-based development, Feature Flag, micro PR 라는 세 가지 키워드와 함께 저희가 스쿼드/플랫폼에서 지속적으로 새로운 피쳐를 개발하면서도 주 2회 배포를 진행하는 업무 문화를 만들어 왔는지 소개드리려고 합니다.1. Trunk-based development 와 Feature FlagTrunk-based development 는 이름에서도 알 수 있듯 모든 개발자가 하나의 코드 브랜치인 ‘trunk’ 에서 작업을 진행하는 방식입니다. 이 방식은 여러 브랜치를 관리하는 복잡함을 줄여주며 지속적인 통합을 통해 코드의 품질과 안정성을 지속적으로 확보할 수 있게 해줍니다. 일반적으로 GitHub Flow 라고도 부릅니다.저희 팀은 기존 두 개의 브랜치를 사용하던 Git Flow 에서, TBD 로 넘어오는 결정을 하게 되었는데 이를 위해 필요한 중요 인프라, Feature Flag 를 먼저 도입할 필요가 있었습니다.Git FlowGitHub FlowFeature Flag는 사용자에게 보이는 기능을 동적으로 토글할 수 있는 스위치로써, 서비스 중인 앱에 새로운 기능을 추가하거나 변경할 때 그 변경사항을 일부 사용자에게만 보이게 하거나 숨기는 데 사용됩니다. 이를 통해 저희 팀은 새로운 기능의 안정성을 테스트하면서도 실 사용자 환경에서의 피드백을 즉시 받을 수 있게 되었습니다.저희 팀에선 각 Feature Flag 를 생성할 때 각 개발자가 다음과 같은 정보를 기입하도록 했고, 같은 파일 내에서 리스트를 관리하되 각 스쿼드/플랫폼 등 영역을 명시적으로 구분해서 어떤 스쿼드에서 어떤 피쳐들이 플래그로 분기가 되어 있는지 한 눈에 확인할 수 있도록 했습니다.- 플래그 키- 플래그 설명- 피쳐 개발 상태 (개발중 / 카나리 배포 가능 / RC 배포 가능 / 릴리즈 가능 / 개발 중단)- 담당자//// FeatureFlag+List.swift///// A Squad@objc public extension FeatureFlag { static let searchResultAInventoryEnabled = FeatureFlag( key: "searchResultAInventoryEnabled", verbose: "검색 결과 화면에서 A 인벤토리를 볼 수 있습니다.", stage: .readyForRelease(targetVersion: "5.79.0"), owner: .personA ) static l

글. 조보민/ UX Researcher상반기의 큰 변화는 UX리서처가 여기어때 앱 사용자뿐만 아니라 파트너 경험을 심도 있게 연구하고 개선해 나가는 것이었어요. 저에게는 ‘여기어때 최초의 파트너 서비스 UX 리서처’라는 새로운 챌린지가 주어졌는데요. 결과적으로 대다수 온라인으로 진행한 여기어때 앱 사용자 리서치와 달리 전국 각지를 누비며 직접 파트너분들을 만나 부딪혀야 했어요. 역경과 고난의 연속이었지만, 현장 속에서 이뤄진 일명 ‘사장님 리서치’의 생생한 여정을 풀어보며 현장리서치는 어떻게 진행되는지 그리고 그 과정에서 얻게 된 배움은 무엇이었는지 공유해보려고 해요.파트너 서비스에서의 UX Research글 시작에 앞서 여기어때 파트너 서비스를 간략히 소개드릴게요. 위 이미지와 같이 파트너 분들이 사용하시는 숙박상품 판매 및 관리를 위한 서비스를 가리킵니다. PC 버전의 마케팅센터 (모텔 파트너 서비스), 파트너센터 (호텔, 펜션 등 파트너 서비스) 그리고 모바일 버전의 관리 서비스 앱들이 있어요. 상품 관리, 판매 설정, 예약 관리, 리뷰, 이벤트, 할인, 정산 등 파트너 서비스 리서치는 파트너 분들이 매일 사용하시는 다양한 기능들을 대상으로 이루어집니다. 나아가 해당 기능이 반영되는 여기어때 앱 화면에 관해서도 여기어때 앱 사용자 리서치가 병행되기도 해요.사장님 리서치를 위한 기반 만들기본격적인 ‘사장님 리서치’의 배경은 파트너센터 개선 프로젝트였습니다. 과거에 단발적인 UT를 진행한 적은 있었지만, 공식적으로 파트너 도메인 UX리서처가 생긴 것은 처음이었어요. 기존 파트너센터를 완전히 개편하는 형태였기 때문에 보다 본격적인 리서치가 필요했죠. 여기어때 앱 사용자에 관해서는 리서치풀을 활용해 익숙하게 리서치를 진행할 수 있었지만, 파트너에 관한 리서치 제반은 제로인 상태였어요.도메인 이해도를 높이기 위해 프로덕트팀 분들께 궁금한 점을 많이 질문했어요. ‘일잘러’이신 PO, UX Designer, UX Writer 분들 덕분에 빠르게 프로젝트에 합류할 수 있었죠. 고객 서비스와는 결이 달라 처음엔 서비스 화면과 기능 자체도 낯설었거든요. 나아가 파트너와 접촉이 많은 영업팀과 미팅을 잡고 현장의 목소리에도 귀를 기울였어요. 파트너 분들이 평소 어떤 부분에 있어 요구를 많이 하셨는지, 서비스 개선 시 우려 사항이 무엇인지 이야기를 들으며 파트너와 영업팀의 상황도 파악하고자 했죠. 파트너 중심 서비스로 개선하기 위해 앞으로 여러 형태의 리서치가 필요함을 논의했어요. 감사하게도 현장 리서치를 준비하는 데에 소중한 도움을 받을 수 있었죠. 파트너 리서치는 프로덕트팀을 넘어 영업팀과 UX리서처가 협업하게 된 최초의 경험이 되었습니다.여기어때 리서치 풀 신청 화면도메인 이해도를 높이고 stakeholder와의 여러 미팅 끝에 본격적인 제반을 만들기 시작했어요. 파트너 서비스 UX 리서처는 혼자였기 때문에 A to Z를 만든다는 생각으로 프로젝트와 함께 운영 업무를 바쁘게 병행했죠. 다양한 여기어때 앱 사용자 유형이 있는 것처럼, 파트너 또한 카테

TV는 리모컨으로 채널을 바꿔가며 조작하고, 세탁기는 버튼을 눌러서 동작시킨다. 컴퓨터는 이보다 복잡하다. 윈도우 운영체제를 통해 화면에 나타난 이미지나 아이콘, 메뉴를 마우스로 클릭해 가며 사용한다. 또한, 엑셀, 파워포인트 그리고 포토샵 등의 프로그램은 사용 방법을 배워야 이용할 수 있다. 스마트폰 앱 역시나 손가락으로 터치를 해가면서 화면에 나타난 메뉴와 앱의 사용법을 알아야 작동할 수 있다. TV만큼 작동 방식이 쉽지만, 그렇다고 누구나 금세 사용할 수 있을 만큼 간편한 것도 아니다. 태어나기 전부터 컴퓨터, 태블릿, 스마트폰이 있는 디지털 세상이었던 20세 이전의 세대는 어려움이 없겠지만, 노년층이나 장애인은 별도로 배우지 않으면 사용하기 어렵다. 또, 디지털에 능숙한 20대라 할지라도 동영상 편집 툴인 캠타샤나 이미지 편집기인 포토샵을 능숙하게 다루긴 어렵다. 또한, 엑셀은 20년간 컴퓨터를 사용하던 사람이라도 매뉴얼을 보며 함수 사용법 등을 숙지하지 않으면 사용할 수 없다. 그런데, 챗GPT를 가능하게 한 AI 모델인 LLM은 우리의 기기, 소프트웨어, 인터넷 서비스 사용에 획기적인 개선을 만들어 줄 것이다.챗GPT와 LLM 기술로 인한 대화형 사용자 인터페이스챗GPT를 가능하게 한 기술은 LLM이라고 부르는 새로운 AI 모델이다. 인류 문명 속에서 기록된 언어와 웹에 공개된 수많은 데이터를 통해 학습한 AI가 LLM이다. 챗GPT는 오픈AI라는 기업이 웹과 앱을 통해 서비스하는 대화형 챗봇 서비스로, GPT-3.5라는 LLM을 통해 구현되었다. 지금은 GPT-4라는 한 단계 진화된 AI로도 서비스되고 있다. 챗GPT가 단기간에 전 세계의 이목을 집중할 수 있었던 이유는 사용 방법이 초등학생도, 할아버지도 바로 즉시 이용할 수 있을 만큼 편했기 때문이다. 그렇게 챗GPT의 사용이 쉬운 이유는 LLM으로 구현된 이 서비스는 사람의 말을 잘 알아듣기 때문이다. 인간의 언어로 학습한 AI다 보니 사람 말을 잘 알아듣는다. 그래서, 챗GPT는 카카오톡의 대화창처럼 AI와 대화하는 챗봇 화면을 통해서 필요한 정보나 요청할 내용을 자연어로 입력하면 결과물을 보여준다. 필요한 것을 요청하면 요구에 맞는 정보나 데이터, 과제를 실행하는 것이다. 그렇다 보니 사용법이 쉬운 것이다. 컴퓨터는 키보드와 마우스로, 스마트폰은 손가락으로 조작했다면 LLM 기반의 서비스는 글로 말로 작동시킬 수 있다. 그렇다 보니 특히 메타버스와 같은 입체적인 공간에서의 조작법이 어려운 경우 LLM 기반의 AI agent(PDA : Personal Digital Agent)가 마치 아이언맨을 도와주는 자비스와 같은 역할을 해줄 수 있다. 챗GPT로 인해 달라진 가장 큰 변화는 바로 컴퓨터와 같은 기계 그리고 각종 소프트웨어와 인터넷 서비스의 사용을 더욱 편리하게 해주는 대화형 UI라는 새로운 사용자 경험을 가능하게 해준 것이다. 일례로, 키오스크에 LLM이 적용되면 화면에 나타난 여러 메뉴를 눌러가며 원하는 음식, 음료를 주문하지 않아도 그냥 키오스크 앞에서 원하는

안녕하세요, FINDA 현금그로스 PG 자산/신용관리 PT 백엔드 개발자 김형래 입니다.이번 글에서는 자산/신용관리 PT 에서 대량 트래픽에서 운영 서비스에 유입되는 트래픽을 원활이 처리하기 위해서 서버 간 메시지를 정의해서 비동기로 처리했던 프로젝트에 대해 알아보도록 할게요!왜 비동기 처리를 선택했나?이전 글에서 다뤄본 CircuitBreaker 로 대량 트래픽 처리 시, 해결되지 않는 부분이 존재했습니다. CircuitBreaker 는 온전히 트래픽 유입을 조절하는 부분에 초점이 맞추어져 있습니다. 그러나, 내부 서비스들 간의 통신에서 Latency 가 오래 걸리는 API 가 있고, Thread 를 더욱 안정적으로 사용하기 위해서는 다른 방법을 강구해 봐야 한다고 판단했습니다. 실제 FINDA APP 홈 화면에서 호출되는 API 가 위에서 이야기한 Latency 가 오래 걸리는 API 로서 이부분을 해결하고자 자산관리, 마이데이터관리 백엔드 개발자가 모여 많은 논의를 진행했습니다. 논의 결과 서버 간 비동기 메시지를 기반으로 통신을 처리하자고 합의점을 이루었습니다. 이번 작업에서 EDA(Event Driven Architecture) 기반으로 아래의 기술들을 적용해서 진행해 보기로 했습니다.Apache Kafka : 비동기 메시지 기반 통신 처리(Produce, Consume)Redis : SSE 통신 중에 Server Scale Out 대응 처리(Pub/Sub), Distributed LockSSE : 단방향 이벤트 발생 시, Server 에서 Client 로 다수의 응답 처리위에 소개한 기술들을 왜 선택하게 되었는지 하나씩 살펴 볼게요.Apache Kafka 는 왜 사용하나요?위에 질문에 답을 하기 위해서는 Apache Kafka 가 무엇인지 먼저 알아봐야겠네요. Apache Kafka 는 빠르고 확장 가능한 작업을 위해 데이터 피드의 분산 스트리밍, 파이프 라이닝 및 재생을 위한 실시간 스트리밍 데이터를 처리하기 위한 목적으로 설계된 오픈 소스 분산형 게시/구독 메시징 플랫폼입니다. Kafka는 Server 클러스터 내에서 데이터 스트림을 레코드로 유지하는 방식으로 작동하는 브로커 기반 솔루션입니다. Kafka Server 는 여러 데이터 센터에 분산되어 있을 수 있으며 여러 Server 인스턴스에 걸쳐 레코드 스트림(메시지)을 토픽으로 저장하여 데이터 지속성을 제공할 수 있습니다. 토픽은 레코드 또는 메시지를 키, 값 및 타임 스탬프로 구성된 일련의 튜플, 변경 불가능한 Python 객체 시퀀스로 저장합니다. Apache Kafka는 오늘날 시장에서 가장 빠르게 성장하는 오픈 소스 메시징 솔루션 중 하나입니다. 이는 주로 분산 시스템에 우수한 로깅 메커니즘을 제공하는 아키텍처 기반 설계 패턴 때문입니다. 실시간 로그 스트리밍을 위해 특별히 제작된 Apache Kafka는 다음 사항을 필요로 하는 애플리케이션에 적합합니다.서로 다른 구성 요소 간의 안정적인 데이터 교환애플리케이션 요구 사항 변경에 따라 메시징 워크로드를 분할하는

카카오페이지 웹 서비스는 graphql을 활용해 BFF를 운영하고 있습니다. 팀 내부에서는 graphql을 사용하는 방법에 대한 노하우들이 적립되어 DX(Developer Experience) 향상과 타 팀과의 커뮤니케이션에 많은 도움을 받으며 BFF를 사용하고 있었는데요. 유명 스트리머 우왁굳의 버추얼 걸그룹 이세계 아이돌의 웹툰이 카카오페이지에 런칭하는 날 트래픽이 3배 이상 몰리게 되며 BFF 서버의 CPU가 100%를 찍는 장애가 발생하게 됩니다. 저희가 문제를 겪으며 알아낸 해결책이 어떤 분께는 도움이 될 수 있을 것 같아 이 글을 쓰게 되었습니다. 문제를 찾아 나가며 알게 된 꿀팁들도 적어 볼 테니 재밌게 봐주셨으면 좋겠습니다.이세계 아이돌 웹툰 런칭 서비스 장애2023년 6월 21일 22시 이세계 아이돌의 웹툰 마법소녀 이세계 아이돌 이 카카오페이지와 카카오웹툰에 런칭하게 됩니다. 스트리머 우왁굳과 버추얼 아이돌 그룹 이세계 아이돌 멤버들이 트위치에서 실시간 생중계를 하며 런칭을 기다렸고, 많은 시청자들이 웹을 통해 작품에 접속하게 되면서 서버가 응답을 내려주지 못하는 장애가 일어나게 됩니다. 수분 정도 페이지가 뜨지 않는 현상이 있었고, 리소스 대비 생각보다 TPS가 안 나오고 있는 것을 발견하여 성능 개선을 우선 과제로 보고 여러 가설을 세워 문제를 찾아나가기 시작했습니다.BFF는 백엔드 API를 호출해서 응답을 가공해 클라이언트로 내려주는 역할 정도만 하고 있어서 CPU가 올라갈 만한 문제의 원인에 감이 안 오는 상황이었는데요. 저희 팀은 여러 가지 가설을 세워 문제의 원인을 찾아내고자 했습니다. 원인이 확실하게 떠오르지 않아 생각나는 대로 가설 리스트를 만들고 하나씩 넣어보며 원인을 찾아 나섰습니다. 가설을 말씀드리기 전에 일단 저희 구성도를 간단히 설명해 드리겠습니다.저희는 서비스 운영에 쿠버네티스를 활용하고 있고, 서버사이드 렌더링을 하는 next.js pod들과(인스턴스라 생각해 주시면 되겠습니다.) BFF를 담당하는 pod들이 따로 떠 있는 상황입니다. BFF에 요청이 들어오면 그에 맞는 백엔드 API를 호출하고, API 응답을 받은 후에는 클라이언트가 요청한 gql 포맷에 맞게 응답을 가공해 내려주는 작업을 진행합니다. BFF 환경은 node.js express에 apollo server를 사용해 띄우고 있었는데요. REST API로 데이터를 받아와 가공 정도만 하는 BFF 서버가 서버사이드 렌더링을 하여 html을 그려주는 next.js 서버보다 성능이 안 나오는게 이해가 안 되는 상황이었죠.제일 간단하게 생각을 해봤을 때 장애 당시 백엔드 응답이 늦어서 BFF도 응답을 내려주기까지 시간이 오래 걸려 타임아웃이 발생한 게 아닐까 하는 생각이 들었습니다. 하지만 당시 백엔드 팀의 모니터링 결과로는 응답 중에서는 특이하게 느린 응답이나 생각보다 부하가 없었다는 얘기를 전달받게 됩니다. 그렇다면 저희 쪽 BFF 서버에서 뭔가의 문제가 있는 것인데.. 정확한 확인을 위해 현 상황에서 nGrinder를 통해 부하 테