여기어때

RSS

게시글: 295
등록: 2026년부터

All Frontend Backend AI DevOps Architecture Etc

DevOps
옵저버빌리티 Right-Sizing: 여기어때에서 기준을 만드는 법
이 글은 여기어때컴퍼니에서 Kubernetes 환경의 옵저버빌리티 시스템을 Right-Sizing한 경험을 공유합니다. Right-Sizing은 Pod의 resources.requests와 limits를 실제 사용량에 맞게 조정하여 클러스터 자원 낭비를 줄이고 효율성을 높이는 작업입니다. 여기어때는 OpenTelemetry와 Grafana LGTM 스택을 활용하여 Self-hosted 옵저버빌리티를 운영하며, 노드 사용률 점검 중 의문을 품고 Right-Sizing을 시작했습니다. `resources.requests`가 실제 사용량과 다르게 설정될 경우 발생하는 문제점(over-provisioning, under-provisioning)을 설명하고, 이를 해결하기 위한 기준 마련 및 적용 과정을 다룹니다. 궁극적으로는 옵저버빌리티 인프라의 비용 효율성을 높이고 안정적인 운영을 목표로 합니다.
ObservabilityRight-SizingKubernetes
여기어때·2026년 4월 23일
DevOps
EKS + ALB 환경에서 Argo Rollouts 503 에러 없는 카나리 배포 적용기
본 글은 EKS와 ALB 환경에서 Argo Rollouts를 사용하여 503 에러 없이 카나리 배포를 적용하는 과정을 다룹니다. 기존 Kubernetes Deployment의 롤링 업데이트 방식은 즉각적인 롤백의 어려움과 배포 중간 개입 불가라는 단점이 있었습니다. Argo Rollouts의 Blue/Green 전략은 이러한 문제를 일부 해결했지만, Promote 시점에 503 에러가 발생하는 문제가 있었습니다. 카나리 배포는 트래픽을 단계적으로 제어할 수 있어 신규 버전의 영향을 최소화하지만, 503 에러 발생 가능성이 존재합니다. 이에 대한 해결책으로 'Canary PingPong' 전략을 소개하며, 503 에러의 원인 분석과 PingPong 전략을 통한 해결 방법, 실제 적용 사례 및 테스트 결과를 공유합니다.
Argo RolloutsEKSALB
여기어때·2026년 4월 23일
DevOps
여기어때 이벤트 기반 통합 알림 플랫폼 구축기 Part 2. How?
여기어때 DevOps팀에서 구축한 이벤트 기반 통합 알림 플랫폼 'NotiHub'의 기술적 설계와 의사결정 과정을 다룹니다. 기존 웹훅의 종속성 및 모니터링 부재, SaaS 연동의 제한된 포맷과 경직된 라우팅 문제를 해결하기 위해 중앙 집중형 구조를 선택했습니다. 이 과정에서 편의성과 안정성 간의 트레이드오프를 고려하여 단일 장애점(SPOF) 문제를 해결하기 위해 HPA 기반 Scale-out, 무중단 배포, 다중 레이어 캐싱 등을 적용했습니다. NotiHub는 확장성과 독립성을 갖춘 세 개의 주요 컴포넌트로 구성되어 있으며, 이를 통해 전사적인 알림 정책 수립과 효율적인 관제를 가능하게 합니다.
알림 플랫폼이벤트 기반NotiHub
여기어때·2026년 4월 3일
DevOps
여기어때 이벤트 기반 통합 알림 플랫폼 구축기 Part 1. Why?
여기어때 DevOps팀의 아리가 이벤트 기반 통합 알림 플랫폼인 Notification Hub 구축 배경을 설명하는 글입니다. 서비스 규모가 커지면서 기존의 개별 알림 전송 방식은 알림의 질을 관리하고 체계적으로 운영하는 데 한계를 드러냈습니다. 특히, 각 시스템에서 제공하는 기본 슬랙 인테그레이션은 낮은 자유도와 정보 파편화 문제를 야기하여 중요한 알림이 묻히는 현상이 발생했습니다. 이에 여기어때는 목적에 맞고 인지하기 쉬운 알림을 설계할 수 있는 전사적 토대를 마련하고자 Notification Hub를 구축하게 되었습니다. 본 글은 구축의 'Why'에 초점을 맞추고 있으며, 기술적인 구현 내용은 Part 2에서 다룰 예정입니다.
알림 플랫폼이벤트 기반Notification Hub
여기어때·2026년 4월 3일
DevOps
여기어때 Secret 플랫폼 구축기 Part 3: 시크릿 저장소를 운영 가능한 상태로 만들기 — 컨테이너화부터 CI/CD, 로그 수집까지
이 글은 여기어때컴퍼니의 Secret 플랫폼 구축기 3편으로, Secrethub를 운영 가능한 상태로 만들기 위한 DevOps 관점의 접근 방식을 다룹니다. Bun 런타임을 기반으로 개발된 Secrethub를 컨테이너로 배포하는 과정과 Bun의 특징을 활용한 최적화 전략을 소개합니다. 특히, `bunfig.toml`의 `isolated` 링커 설정을 통해 심볼릭 링크 없이 의존성을 관리하고, `bun build`를 사용하여 TypeScript 소스와 모든 의존성을 단일 파일로 번들링하여 컨테이너 환경에서의 예측 가능성과 효율성을 높였습니다. 또한, CI/CD 파이프라인 구축과 로그 수집, 모니터링 등 Observability 확보를 통해 단순 배포를 넘어 관리 가능한 구조를 만드는 데 중점을 둡니다.
Bun컨테이너화CI/CD
여기어때·2026년 2월 27일
DevOps
여기어때 Secret 플랫폼 구축기 Part 2: 시크릿 저장소를 전체 서비스에 적용하기까지
이 글은 여기어때컴퍼니 DevOps팀이 Secrethub를 도입하여 시크릿 저장소를 전체 서비스에 적용한 경험을 공유합니다. 특히 EKS 환경에 먼저 적용하여 CI/CD 표준화를 활용하고, 민감 정보 변경 시 자동으로 반영되는 ESO 기반 동기화 구조를 구축했습니다. Spring Boot 프로젝트에는 공통 로더와 Shadow 방식을 제공하여 충돌 없이 적용할 수 있도록 했습니다. EC2 환경은 아직 표준화가 덜 되어 있어 EKS 환경에서 안정성을 확보한 후 전사 확산을 목표로 했습니다. 이 글은 시크릿 관리의 효율성과 보안성을 높이기 위한 DevOps 팀의 실제 적용 사례와 설계 기준을 상세히 다룹니다.
SecrethubEKSKubernetes
여기어때·2026년 2월 27일
DevOps
여기어때 Secret 플랫폼 구축기 Part 1: 왜 시크릿 저장소를 만들었는가
여기어때 DevOps팀은 Secret 중앙 관리의 필요성을 느껴 Secret 저장소를 구축하는 프로젝트를 시작했습니다. 기존에는 각 서비스별로 Secret을 관리하여 보안 취약점, 관리의 어려움, 비효율성 등의 문제가 있었습니다. 본 글에서는 Secret 저장소 구축의 배경과 필요성을 설명하며, 향후 Secret 플랫폼 구축을 위한 첫걸음을 제시합니다. 이를 통해 개발 및 운영 환경의 보안 강화와 효율성 증대를 목표로 합니다.
비밀 관리Secret 저장소DevOps
여기어때·2026년 2월 27일
DevOps
Observability를 위한 LGTM 첫걸음
이 글은 여기어때컴퍼니 SRE팀에서 Observability 스택인 LGTM(Loki, Grafana, Tempo, Mimir)을 도입한 경험을 공유합니다. 대규모 서비스에서 발생하는 문제의 원인을 파악하기 위해 로그, 메트릭, 트레이스를 통합적으로 분석하는 LGTM의 필요성을 설명하고, 각 구성 요소(Loki: 라벨 기반 로그 저장/검색, Grafana: 통합 시각화/분석, Tempo: 분산 트레이스 추적, Mimir: 확장형 메트릭 저장소)의 역할과 특징을 소개합니다. 특히 EKS 환경에서 Helm Chart를 활용한 배포 경험과 시행착오를 바탕으로, LGTM을 처음 접하는 엔지니어들이 각 구성 요소의 구조를 이해하고 효과적으로 운영하는 데 도움을 주는 것을 목표로 합니다.
ObservabilityLGTMLoki
여기어때·2025년 12월 22일
DevOps
“서버가 죽었어요”에서 시작된 이야기, Grafana OnCall과 Amazon Connect로 완성한 실전형 온콜 시스템
본 글은 "서버가 죽었어요"라는 갑작스러운 장애 상황에서 시작하여, Grafana OnCall과 Amazon Connect를 활용해 실전형 온콜 시스템을 구축한 경험을 공유합니다. 기존 온콜 시스템의 한계를 극복하고, 장애 발생 시 신속하고 효과적인 대응을 위한 자동화된 알림 및 통화 시스템의 필요성을 강조합니다. Grafana OnCall을 통해 장애 알림을 통합 관리하고, Amazon Connect를 연동하여 담당자에게 자동으로 전화를 걸어 상황을 인지시키는 과정을 상세히 설명합니다. 이를 통해 장애 대응 시간을 단축하고 팀의 업무 효율성을 높이는 실질적인 효과를 얻었음을 보여줍니다. 궁극적으로는 안정적인 서비스 운영을 위한 필수적인 시스템으로서 온콜 시스템의 중요성을 재확인합니다.
Grafana OnCallAmazon Connect온콜 시스템
여기어때·2025년 12월 16일
DevOps
OpenTelemetry와 Kafka를 활용한 안정적인 Observability 구축기
본 글은 마이크로서비스 아키텍처(MSA) 환경에서 증가하는 시스템 복잡성과 전통적인 모니터링 방식의 한계를 극복하기 위해 OpenTelemetry와 Kafka를 활용하여 안정적인 Observability 환경을 구축한 경험을 공유합니다. OpenTelemetry는 예측하지 못한 복잡한 문제에 대한 답을 찾을 수 있도록 돕는 관찰 가능성(Observability)을 실현하기 위한 표준 기술로, Traces, Metrics, Logs 데이터를 수집하고 전송하는 데 사용됩니다. 글에서는 OpenTelemetry의 기본 개념과 함께, 여기어때컴퍼니가 이 기술을 도입하여 시스템 내부를 깊이 들여다보고 문제를 신속하게 진단할 수 있었던 구체적인 아키텍처 구축 과정을 설명합니다. 이를 통해 복잡한 분산 시스템에서도 효과적인 문제 해결 및 시스템 이해를 가능하게 하는 Observability의 중요성을 강조합니다.
OpenTelemetryKafkaObservability
여기어때·2025년 12월 16일
DevOps
AWS PrivateLink로 만드는 안전한 프라이빗 네트워크
본 글은 여기어때컴퍼니 SRE팀에서 AWS PrivateLink를 사용하여 Salesforce SaaS 솔루션을 AWS 환경에 안전하게 연동하는 과정에서 발생한 NLB Health Check 실패 이슈와 해결 과정을 공유합니다. AWS PrivateLink는 VPC 엔드포인트를 통해 퍼블릭 IP나 인터넷을 거치지 않고 AWS 서비스에 프라이빗하게 접속할 수 있게 하여 보안을 강화하는 기술입니다. 글에서는 PrivateLink 전용 프라이빗 서브넷을 추가하고, PrivateLink Endpoint Service를 위한 NLB Health Check가 실패하는 문제를 발견했으며, 이를 해결하는 과정을 상세히 다룹니다. 이를 통해 유사한 문제를 겪는 엔지니어들에게 실질적인 도움을 제공하고자 합니다.
AWS PrivateLinkNLBHealth Check
여기어때·2025년 10월 17일
DevOps
여기어때 CI/CD 개선기 Part 5: Slack으로 완성되는 배포 가시성
이 글은 여기어때 DevOps팀이 GitLab CI와 ArgoCD를 활용하여 CI/CD 알림 시스템을 개선한 경험을 공유합니다. 기존에는 팀별로 파편화된 알림 구조와 GitLab CI의 알림 기능 제약으로 인해 배포 실패 감지 및 전체 현황 파악에 어려움이 있었습니다. 이를 해결하기 위해 GitLab CI 파이프라인에서 일관된 알림 체계를 구축하고, ArgoCD 배포 결과를 Slack으로 효율적으로 알릴 수 있도록 개선했습니다. 이를 통해 환경별, 이벤트별 세분화된 알림 구현으로 배포 가시성을 높이고 실패 감지 시간을 단축하는 것을 목표로 합니다.
CI/CDGitLab CIArgoCD
여기어때·2025년 9월 10일
DevOps
여기어때 CI/CD 개선기 Part 4: 공통 Helm Chart 설계와 추상화
여기어때컴퍼니 DevOps팀은 CI/CD 공통화를 위해 Helm Chart의 파편화 문제를 해결하고 공통 Helm Chart를 설계하는 과정을 공유합니다. 이전 편에서 AWS ECR을 중앙 Chart Registry로 도입한 후, 이번 글에서는 서비스별로 상이했던 Helm Chart 구성을 표준화하는 데 초점을 맞춥니다. HPA, PDB, KEDA 등 다양한 배포 Spec의 차이를 극복하고 개발자가 인프라 복잡성에 신경 쓰지 않도록 추상화하는 전략을 제시합니다. 이를 통해 공통 Helm Chart를 설계하고, 개발 생산성과 운영 효율성을 높이는 것을 목표로 합니다.
CI/CDHelm ChartKubernetes
여기어때·2025년 9월 10일
DevOps
여기어때 CI/CD 개선기 Part 4: 공통 Helm Chart 설계와 추상화
여기어때 기술 블로그의 CI/CD 개선기 4부에서는 공통 Helm Chart 설계와 추상화에 대해 다룹니다. 이전 파트에서 CI/CD 파이프라인 구축의 필요성을 인지하고, GitOps 기반의 배포 전략을 수립했습니다. 이번 글에서는 반복적인 Helm Chart 작성을 줄이고 재사용성을 높이기 위해 공통 Helm Chart를 설계하고 추상화하는 방법을 구체적으로 제시합니다. 이를 통해 개발 생산성을 향상시키고, Kubernetes 환경에서의 애플리케이션 배포 및 관리를 더욱 효율적으로 할 수 있는 방안을 모색합니다. 궁극적으로는 안정적이고 빠른 배포를 위한 기반을 마련하는 데 중점을 둡니다.
CI/CDHelm ChartKubernetes
여기어때·2025년 9월 10일
DevOps
여기어때 CI/CD 개선기 Part 3: Helm Chart Registry 도입기
여기어때컴퍼니 DevOps팀에서 기존 CI/CD 파이프라인의 Helm Chart 관리 문제를 해결하기 위해 Helm Chart Registry를 도입한 경험을 공유합니다. Kubernetes 환경에서 Helm은 사실상 표준 배포 도구로 사용되지만, 서비스별로 Helm Chart를 개별 관리하면서 발생하는 반복적인 설정 복사, 버전 충돌, 이력 추적의 어려움 등의 문제점을 지적합니다. 이러한 문제 해결을 위해 AWS ECR을 활용하여 공통 Helm Chart를 관리하는 Helm Chart Registry를 도입하게 된 과정과 그 필요성에 대해 설명합니다. 이 글은 Helm Chart의 기본 개념과 함께, 실제 운영 환경에서 겪었던 구체적인 문제점과 이를 해결하기 위한 DevOps 팀의 노력을 보여줍니다.
CI/CDHelm ChartKubernetes
여기어때·2025년 9월 10일
DevOps
여기어때 CI/CD 개선기 Part 5: Slack을 통해 완성되는 배포 가시성
여기어때 기술 블로그의 CI/CD 개선기 Part 5에서는 Slack을 활용하여 배포 가시성을 확보하는 방법에 대해 다룹니다. 이전 파트들에서 구축된 CI/CD 파이프라인을 기반으로, 배포 과정의 각 단계를 Slack 알림으로 통합하여 팀원들이 실시간으로 배포 현황을 파악하고 문제를 신속하게 인지할 수 있도록 개선했습니다. 이를 통해 배포 프로세스의 투명성을 높이고, 잠재적인 이슈에 대한 빠른 대응 체계를 마련하여 전반적인 개발 및 운영 효율성을 향상시키는 것을 목표로 합니다. Slack 연동을 통해 개발팀과 운영팀 간의 커뮤니케이션을 강화하고, 배포 관련 정보 공유를 용이하게 함으로써 더욱 안정적이고 효율적인 서비스 운영에 기여할 수 있음을 보여줍니다.
CI/CDSlack배포
여기어때·2025년 9월 9일
DevOps
여기어때 CI/CD 개선기 Part 4: 공통 Helm Chart 설계와 추상화
여기어때 기술 블로그의 CI/CD 개선기 4부에서는 공통 Helm Chart 설계와 추상화에 대해 다룹니다. 이전 파트에서 CI/CD 파이프라인 구축의 필요성을 인지하고, Helm Chart를 활용하여 Kubernetes 환경에서의 애플리케이션 배포를 표준화하는 방안을 모색했습니다. 이번 글에서는 여러 프로젝트에서 재사용 가능한 공통 Helm Chart를 설계하고 추상화하는 구체적인 방법론을 제시합니다. 이를 통해 반복적인 설정을 줄이고, 일관된 배포 프로세스를 유지하며, 개발 생산성을 향상시키는 것을 목표로 합니다. 특히, 템플릿, 값 파일, 헬퍼 함수 등을 활용하여 유연하고 확장 가능한 차트 구조를 만드는 데 중점을 둡니다. 궁극적으로는 GitOps 환경에서 효율적인 배포 자동화를 달성하기 위한 기반을 마련합니다.
CI/CDHelm ChartKubernetes
여기어때·2025년 9월 9일
DevOps
여기어때 CI/CD 개선기 Part 2: CI Pipeline 설계
여기어때컴퍼니 DevOps팀에서 CI/CD 개선 프로젝트의 두 번째 이야기로, CI 공통화를 위한 모듈화 설계를 다룹니다. 기존 CI 템플릿이 30여 개 파일로 분산되어 있고 사소한 차이로 인해 파악 및 관리에 어려움이 있었던 문제를 해결하기 위해, Gitlab CI를 활용하여 CI 파이프라인을 모듈화하는 방안을 제시합니다. 각 팀의 다양한 브랜치 전략에도 유연하게 대응할 수 있도록 공통화 범위와 커스터마이징 가능 범위를 산정하는 과정에서 겪었던 난관과 해결 과정을 공유하며, 개발자들의 업무 몰입을 위한 개발 환경 체계 구축의 중요성을 강조합니다.
CI/CDGitLab CICI Pipeline
여기어때·2025년 9월 8일
DevOps
여기어때 CI/CD 개선기 Part 1: 문제 파악
여기어때컴퍼니 DevOps팀은 개발자들의 업무 몰입을 위한 개발 환경 개선의 일환으로 CI/CD 파이프라인 개선 여정을 5편에 걸쳐 공유합니다. 본 글은 그 첫 번째 이야기로, 현재 CI/CD 시스템의 문제점을 파악하는 데 집중합니다. 기존에는 Gitlab CI와 ArgoCD를 사용하여 EKS에 서비스를 배포했으나, 30개 이상의 복잡한 CI 관련 YAML 파일과 Helm Chart 설정으로 인해 개발자들이 변경 사항을 파악하고 적용하는 데 어려움을 겪었습니다. 이러한 비효율성을 개선하기 위한 첫 단계로, 문제의 근본 원인을 진단하고 현황을 명확히 하는 과정이 중요함을 강조합니다.
CI/CDGitLab CIArgoCD
여기어때·2025년 9월 8일
DevOps
데이터 자동 생성으로 생산성 향상 : Playwright로 3분 걸리던 계약 생성을 30초로!
본 글은 여기어때컴퍼니 QA2팀에서 Playwright를 활용하여 계약 생성 프로세스의 생산성을 획기적으로 향상시킨 경험을 공유합니다. 기존에 3분 이상 소요되던 계약 생성 작업을 자동화하여 30초 이내로 단축시킨 사례를 소개하며, 특히 테스트 데이터 자동 생성의 중요성을 강조합니다. Playwright를 이용한 자동화 스크립트 구현 과정을 통해 반복적인 수작업을 줄이고 QA 업무의 효율성을 높이는 방법을 제시합니다. 이를 통해 개발 및 QA 팀의 생산성 향상과 더불어 서비스 품질 개선에도 기여할 수 있음을 보여줍니다. 이 글은 테스트 자동화 도구 도입을 고려하거나, 반복적인 업무 자동화를 통해 생산성을 높이고자 하는 개발자 및 QA 엔지니어에게 유용한 정보를 제공합니다.
Playwright데이터 자동 생성테스트 자동화
여기어때·2025년 9월 3일

여기어때

옵저버빌리티 Right-Sizing: 여기어때에서 기준을 만드는 법

EKS + ALB 환경에서 Argo Rollouts 503 에러 없는 카나리 배포 적용기

여기어때 이벤트 기반 통합 알림 플랫폼 구축기 Part 2. How?

여기어때 이벤트 기반 통합 알림 플랫폼 구축기 Part 1. Why?

여기어때 Secret 플랫폼 구축기 Part 3: 시크릿 저장소를 운영 가능한 상태로 만들기 — 컨테이너화부터 CI/CD, 로그 수집까지

여기어때 Secret 플랫폼 구축기 Part 2: 시크릿 저장소를 전체 서비스에 적용하기까지

여기어때 Secret 플랫폼 구축기 Part 1: 왜 시크릿 저장소를 만들었는가

Observability를 위한 LGTM 첫걸음

“서버가 죽었어요”에서 시작된 이야기, Grafana OnCall과 Amazon Connect로 완성한 실전형 온콜 시스템

OpenTelemetry와 Kafka를 활용한 안정적인 Observability 구축기

AWS PrivateLink로 만드는 안전한 프라이빗 네트워크

여기어때 CI/CD 개선기 Part 5: Slack으로 완성되는 배포 가시성

여기어때 CI/CD 개선기 Part 4: 공통 Helm Chart 설계와 추상화

여기어때 CI/CD 개선기 Part 4: 공통 Helm Chart 설계와 추상화

여기어때 CI/CD 개선기 Part 3: Helm Chart Registry 도입기

여기어때 CI/CD 개선기 Part 5: Slack을 통해 완성되는 배포 가시성

여기어때 CI/CD 개선기 Part 4: 공통 Helm Chart 설계와 추상화

여기어때 CI/CD 개선기 Part 2: CI Pipeline 설계

여기어때 CI/CD 개선기 Part 1: 문제 파악

데이터 자동 생성으로 생산성 향상 : Playwright로 3분 걸리던 계약 생성을 30초로!