본문 바로가기
반응형

DevOps67

오픈소스 검색엔진 비교: OpenSearch vs Meilisearch vs Typesense 1️⃣ 들어가며검색 기능은 단순히 문자열을 찾는 기능을 넘어, 언어 구조를 이해하고 유사한 의미까지 탐색하는 기술로 진화하고 있다.특히 한국어는 띄어쓰기 규칙이 불규칙하고 복합명사가 많아, 검색엔진 선택이 검색 품질에 직접적인 영향을 준다.이번 글에서는 대표적인 오픈소스 검색엔진인OpenSearch, Meilisearch, Typesense를 비교하며,한국어 처리력·띄어쓰기 오류 대응·개발 난이도 측면에서 분석한다.2️⃣ 엔진별 개요 항목 OpenSearch Meilisearch 기반 구조Lucene 기반 (Elasticsearch fork)Rust 기반C++ 기반주요 특징대규모 데이터, 고급 쿼리, 형태소 분석설치 간단, 빠른 인덱싱실시간 검색, 자동완성 최적화형태소 분석✅ Nori Analyzer .. 2025. 11. 6.
Argo CD에서 GitHub Apps로 보안 강화하기 GitOps 인증 토큰 관리의 새로운 표준: GitHub App 기반 접근 방식 목차 🧩 들어가며Argo CD는 GitOps 패턴의 핵심이라 할 수 있는 툴로,Git 리포지토리의 선언형 설정(Helm, Kustomize 등)을 Kubernetes 클러스터에 자동 동기화합니다.하지만 많은 팀이 여전히 Argo CD에서 Personal Access Token (PAT) 을 사용하고 있습니다.이 방식은 다음과 같은 문제가 있습니다.🔓 토큰이 사람 계정 기반으로 발급되어, 만료 및 유출 리스크 존재🧑‍💻 조직원이 퇴사하거나 계정이 비활성화되면, 배포가 중단됨🔁 토큰 수동 갱신 필요 → 자동화 불가능이 문제를 해결하는 방법이 바로 GitHub Apps 기반 인증입니다.Argo CD는 2.4 버전부터 Gi.. 2025. 10. 29.
Githup Apps 이란? 활용방법과 token과 비교 DevOps 관점에서 GitHub 자동화를 “안전하고, 감사 가능하며, 세분화된 권한”으로 운영하려면 GitHub App이 사실상 표준입니다. 아래에 개념부터, GitHub Token(특히 Fine-grained PAT)과의 차이, 조직에서의 도입 패턴, 실전 코드와 GitHub Actions 예시까지 “step-by-step”으로 정리했습니다.1) GitHub Apps란?GitHub 리소스(리포지토리, 이슈, 체크런 등)에 접근하는 1급(First-class) 통합 방식세분화된 권한(permissions) 과 짧은 수명의 토큰(short-lived) 을 사용해 보안 수준이 높음“앱을 조직/개인 계정에 설치(installation) → 설치가 허용된 리포/조직 범위 안에서만 작동” 구조OAuth App과.. 2025. 10. 29.
“Swiper is not defined”와 “Mixed Content” 오류, IIS 웹 서비스를 운영하다 보면 "같은 코드인데 어떤 PC에서는 정상, 어떤 PC에서는 오류"처럼정확한 원인이 헷갈리는 문제가 종종 발생합니다.이번 글은 실제로 AWS ALB + Windows VM(IIS) 환경에서Swiper is not defined 및 Mixed Content 오류가 일부 PC에서만 발생했던 문제를코드 수정 없이 인프라 레벨에서 완벽히 해결한 기록입니다.🧠 1. 증상 요약🧩 콘솔 오류 메시지common.js?v=1745305927:39 Uncaught ReferenceError: Swiper is not defined at Object.TopnavScroll (common.js?v=1745305927:39:9) at Object.init (common.js?v=174530.. 2025. 10. 17.
클라우드 계정이 다른 개발 / 운영 환경의 CIDR 범위 설정 규모에 상관없이일반적으로 하나의 서비스를 이용하게되면 보통 하나의계정에 개발,스테이징, 운영 환경을 구축하는게 일반적입니다. 한눈에볼수도 있고 연동시 편한 장점이 있기 때문입니다. 하지만 이번에 개발과 운영의 root 계정을 분리하여 운영하게 되었는데 이때 Best practice 네트워크 CIDR 은 서로 다르게 하는것 입니다. 간단히생각했을때 똑같이 구성해도 계정이 다르기 때문에 별문제가 안되어 보이지만 구분해는게 더 이점이 있습니다. 그에대해 이번 포스팅에서 살펴보겠습니다. 목차 왜 다르게 해야 하나? (step-by-step)VPC 간 연결(피어링/Transit Gateway/VPN/Direct Connect) 대비나중에 dev ↔ prod, shared-services ↔ prod 같은 동일 .. 2025. 10. 10.
[kafka] 토픽을 파티션으로 나누는 이유 1. 병렬 처리로 성능 향상토픽을 여러 파티션으로 나누면, 여러 Producer가 동시에 다른 파티션에 기록할 수 있고,여러 Consumer가 동시에 다른 파티션에서 읽을 수 있음.즉, 1개의 큰 로그 파일로 처리하는 것보다, 분산된 여러 파티션에 나눠 쓰고 읽는 게 훨씬 빠름.예) 토픽에 1초당 10만 건이 들어와도, 파티션 5개로 나누면 각 파티션당 2만 건씩 처리 가능.2. Consumer Group 기반 병렬 처리카프카는 Consumer Group 단위로 메시지를 읽는데,→ 1개의 파티션은 동시에 1개의 컨슈머만 읽을 수 있음.따라서 파티션 수를 늘리면 Consumer를 더 많이 붙여 병렬 처리 가능.예) 파티션 6개 → 컨슈머 그룹에 6개 컨슈머 붙이면 병렬 처리 x6.3. 확장성과 유연성클러스.. 2025. 9. 29.
퍼센타일 지표(p50, p90)로 보는 성능과 모니터링 웹 서비스나 API를 운영하다 보면 “응답 시간이 평균 200ms” 같은 말을 흔히 합니다. 하지만 **평균값(mean)**만으로는 사용자 경험을 제대로 설명할 수 없습니다. 실제로는 일부 요청이 아주 느릴 수 있고, 그 극단적인 요청들이 서비스 만족도를 크게 떨어뜨리기도 합니다.이때 자주 쓰이는 지표가 바로 **퍼센타일(percentile)**입니다. 그중에서도 가장 많이 언급되는 것이 p50, p90, p95, p99입니다.1. 퍼센타일이란 무엇인가?퍼센타일은 데이터를 정렬했을 때 특정 비율에 해당하는 지점을 말합니다.p50 (50th percentile): 중앙값(median). 절반의 요청이 이 값보다 빠르고, 절반은 더 느립니다.p90 (90th percentile): 요청 중 90%는 이 값보.. 2025. 9. 24.
isito 와 cilium path 정책 차이 1.패턴 매칭 방식Cilium - 정규식 지원http:path: "/api/v[0-9]+/users/[a-zA-Z0-9-]+" # 정규식path: ".*\\.(jpg|png|gif)$" # 파일 확장자Istio - Glob 패턴만operation: paths: ["/api//users/"] # 와일드카드만정규식 지원하지 않음2. 정책 우선순위 처리Cilium - 순서대로 첫 매칭ingress:rules: http:path: "/admin" # 먼저 매칭되면 허용path: "/admin/.*" # 두 번째 규칙은 무시됨Istio - DENY > ALLOW복수 정책이 있어도 DENY가 우선ALLOW: "/admin"DENY: "/admin/*"결과: DENY 승리3.헤더 및 조건부 매칭Cilium - 정규식.. 2025. 9. 24.
istio vs cilium 정책 차이 레이어/역할Istio: 서비스 메쉬의 L7(HTTP/gRPC) 중심 접근제어 + mTLS/JWT 인증/인가. AuthorizationPolicy(ALLOW/DENY/CUSTOM/AUDIT), PeerAuthentication(mTLS), RequestAuthentication(JWT)로 앱 레벨 보안/정책을 다룸. Sidecar 모드에선 Envoy 사이드카가, Ambient에선 L4 정책은 ztunnel, L7은 waypoint가 집행한다. IstioCilium: CNI + eBPF 기반 L3/L4(커널 레벨) 정책이 기본. 확장 리소스인 CiliumNetworkPolicy/ClusterwideNetworkPolicy로 L3/L4는 eBPF로, **L7(HTTP/gRPC/Kafka/DNS)**은 노드 로.. 2025. 9. 24.
GitHub Composite Action + ArgoCD: GitOps CI/CD 파이프라인 완성하기 최근 많은 팀이 GitOps 기반 배포를 도입하면서 ArgoCD를 활용하고 있습니다. 하지만 CI 단계(빌드, 테스트, 이미지 푸시)는 여전히 GitHub Actions에서 담당하는 경우가 많습니다.이때 유용하게 활용할 수 있는 것이 Composite Action입니다. 반복적인 빌드/배포 로직을 하나로 묶어 재사용할 수 있고, ArgoCD와 결합하면 완전 자동화된 GitOps 파이프라인을 구현할 수 있습니다.1. GitHub Composite Action이란?정의: 여러 Step을 조합해 하나의 Action처럼 사용할 수 있는 GitHub Actions 기능 (using: composite).장점공통 빌드/배포 로직을 표준화리포지토리/팀 전체에서 재사용유지보수 및 관리 용이형태: .github/acti.. 2025. 9. 8.
gitops와 app of apps 가 kubernetes 운영시 필요한 이유 1. 왜 GitOps가 필요한가?일반적인 서버 운영: 개발자가 코드를 수정 → 서버에 들어가서 수동으로 설정/배포.문제: 사람이 직접 서버를 만지다 보면 설정이 달라지거나, 누가 언제 뭘 바꿨는지 추적이 안 됨.GitOps 방식: “배포와 운영의 모든 상태를 Git에 적어두고, 쿠버네티스가 자동으로 따라가게 하는 것”.즉, Git = 진실의 원천(Single Source of Truth).코드 바꾸듯이 YAML(쿠버네티스 설정)을 수정 → Git에 올리면 → 자동으로 클러스터 반영.결과: 이력 관리, 협업, 롤백이 훨씬 쉬워짐.👉 비유: “노트에 모든 요리 레시피(서버 상태)를 적어놓고, 요리사는 그 레시피만 보고 자동으로 요리를 만드는 것”.2. App of Apps가 왜 필요한가?EKS 같은 환경에.. 2025. 9. 8.
kubernetes 셀프서비스 backstage 도입여부 환경 개발자들이 yaml 안건드리고 배포할수 있는 환경을 만들고싶어서 github으로 구현할지 backstage로 할지 고민을 하고 있습니다. 다음과 같은 조건을고려해서 도입여부를결정하였습니다. 1. Backstage가 필요 없는 경우팀 규모가 작다개발자 10명 이하 + 서비스 20개 이하 온보딩은 문서(Markdown/Notion)로도 1일 이내에 충분히 가능.DevOps 병목이 크지 않다새 서비스 생길 때 DevOps 1명이 직접 Helm/CI/CD 넣어주는 게 몇 시간 안 걸린다.개발자 요청 건수가 적어서 반복 부담이 크지 않다.서비스 표준화가 이미 잘 돼 있다Template repo, reusable GitHub Actions, Helm 차트가 있어서 복붙으로도 80% 커버 가능.👉 이런 .. 2025. 9. 8.
반응형

티스토리툴바