본문 바로가기
반응형

전체 글2287

✅ GPT 기반 Java Stacktrace 병목 탐지 및 리포트 자동화 1. 배경과 문제점운영환경에서 다음과 같은 문제들이 반복됩니다: • Stacktrace는 쏟아지지만, 원인을 파악하기 어렵다 • 로그만 봐서는 코드 구조나 호출 비용을 알 수 없다 • 개발자가 아닌 운영자 입장에서 분석 속도가 느리다 • 반복되는 병목이 문서화되지 않고 축적되지 않는다→ GPT 기반 구조 분석과 리포트를 통해 이를 자동화합니다.⸻2. 전체 구성 아키텍처graph TDA[Java App Log (Stacktrace)] --> B[FluentBit or Filebeat]B --> C[Loki or Logstash]C --> D[Stacktrace Extractor & Normalizer]D --> E[GPT 분석기]E --> F[Slack / Notion / Jira로 리포트 전송]⸻3. S.. 2025. 5. 31.
✅ Spring Boot – Kafka – DB 호출 체계 SLA 비용 최적화 전략 1. 전체 아키텍처 호출 흐름 예시sequenceDiagram participant Client participant SpringAPI participant KafkaProducer participant KafkaBroker participant KafkaConsumer participant DB Client->>SpringAPI: HTTP POST /order SpringAPI->>KafkaProducer: publish order-event KafkaProducer->>KafkaBroker: Kafka topic 메시지 전송 KafkaBroker->>KafkaConsumer: 메시지 소비 KafkaConsumer->>DB: Insert 주문 .. 2025. 5. 31.
✅ OpenTelemetry + LLM 기반 이상행위 요약 자동 보고 시스템 1. 개요실제 운영 환경에서는 수십만 건 이상의 로그/트레이스가 실시간으로 쌓이며,다음과 같은 상황이 자주 발생합니다: • 장애 시점 파악은 했지만 “어디가 문제인가” 찾는데 수십분~수시간 소요 • 로그 수는 많지만, “읽을 수는 없다” → 요약 불가 • 운영 보고용 문서 수기로 작성 → 중복 시간 낭비이를 해결하기 위해 OpenTelemetry 기반 로그/Trace 수집 체계 위에이상 패턴 탐지 + GPT 기반 요약 자동화를 결합합니다.⸻2. 시스템 구성도graph LRA[Spring Boot / WebLogic 앱] --> B[OpenTelemetry Collector]B --> C[Tempo / Loki / Jaeger]C --> D[Log Aggregation]D --> E[Anomaly Dete.. 2025. 5. 31.
✅ Spring Boot + WebLogic 환경에서 SLA 기반 과금(QoS Billing) 시뮬레이션 모델 설계 1. 개요서비스형 API, 프랜차이즈 SaaS, 혹은 마이크로서비스 기반 플랫폼에서는요청량, 응답 속도, 성공률 등 SLA 요소를 기반으로 한 과금 모델이 필요해집니다.이 시뮬레이션 모델은 다음과 같은 목적에 부합합니다: • 이용자 별 성능 기반 요금 차등화 (QoS Tier Billing) • 초과 사용량 기반 가변 과금 (Usage-based Billing) • 시스템 부하 대비 비용 회수율 추정 및 최적화⸻2. 핵심 과금 변수 정의항목 설명 단위RPS 초당 요청 수 (Request per Second) req/sLatency 95th Percentile 응답 시간 msSuccessRate 성공 요청 비율 (2xx/3xx 비율) %PayloadSize 평균 응답 크기 KBAPI Tier 서비스 등급 .. 2025. 5. 31.
✅ WebLogic 환경에서 /management/configprops 경로의 의미 및 보안 유의사항 ⸻1. Spring Boot 기반 /management/configprops 엔드포인트의 의미Spring Boot에서 제공하는 Actuator 기능 중 하나로, 다음과 같은 기능을 수행합니다:항목 설명엔드포인트 /management/configprops기능 현재 Spring ApplicationContext에 로드된 모든 @ConfigurationProperties 빈들의 구성 값 확인출력 형식 JSON (각 설정 클래스별 prefix, 값 등 포함)활용 목적 application.yml, application.properties의 실제 적용 상태를 실시간으로 확인 가능🔎 예시 응답 (요약):{ "my.custom.config": { "prefix": "my.custom.config", ".. 2025. 5. 30.
🧠 131. Kubernetes CronJob을 Argo Events로 확장하여 이벤트 중심 스케줄링 구현하기 “시간이 아닌 이벤트로 작동하는 진짜 ‘CronJob 2.0’”⸻📌 개요기존 Kubernetes CronJob은 시간 기반 스케줄링(schedule: "*/5 * * * *")에만 의존합니다.그러나 Slack 메시지, S3 업로드, Webhook 호출, Kafka 메시지 수신과 같은 외부 이벤트를 기반으로 Job을 실행해야 하는 경우에는 적합하지 않습니다.이럴 때 사용하는 것이 Argo Events입니다.Argo Events는 다양한 소스로부터의 이벤트를 감지하고, 해당 이벤트에 따라 Kubernetes 내 리소스를 트리거할 수 있게 해주는 이벤트 기반 워크플로우 트리거러입니다.⸻💡 핵심 구성 요소구성 요소 설명Sensor 이벤트 수신 조건을 명세하고, Job이나 Workflow 실행을 트리거함Eve.. 2025. 5. 30.
GitHub Actions에서 Nix를 이용한 완전 불변형(Immutable) 빌드 환경 구축기 CI 환경의 ‘예측 불가능성’을 제거하라.개발자마다, 워크플로마다, 시간대마다 달라지는 빌드 결과에 좌절했던 경험이 있다면 —이제 GitHub Actions에서도 Nix를 활용하여 완전한 재현 가능(100% reproducible) 빌드 환경을 구성할 수 있습니다.이 글은 GitHub Actions 내에서 Nix shell로 래핑된 Job 환경을 만드는 방법,그리고 Nix의 flake 기반 CI template 구조화를 통해동일한 환경에서 동일한 결과를 보장하는 불변형 CI 파이프라인을 만드는 실제 사례를 다룹니다.⸻🎯 왜 Nix인가? • 🧪 의존성 충돌 제거: 시스템 환경과 무관하게 독립적인 패키지 설치 • 🧱 불변성: 시간이 지나도 동일한 버전, 동일한 결과 보장 • 🧬 재현 가능성: 커밋 해.. 2025. 5. 30.
GitHub Actions를 Kubernetes 내부 서비스로 완전히 이식하기: Self-Hosted Action Runner Mesh 구축기 퍼블릭 CI에 의존하지 않고, 사내 망 내부에서 완전한 GitHub Actions 생태계를 운영하는 방법.GitHub Actions의 워크플로를 완전 사내망 Kubernetes 클러스터 내부에서 실행되도록 구성하며,GitHub Webhook → K8s 서비스 Mesh → Runner Pod 자동 생성 → Argo CD 자동 배포까지 연결하는GitHub Actions Runner Mesh 구조를 구축합니다.⸻🎯 목적 • GitHub Actions 워크플로를 사내망 Kubernetes 클러스터 내부에서 실행 • 워크플로별로 개별 Runner Pod를 생성하고 Job 단위로 Auto Terminate • Runner Autoscaler + GitHub Webhook + Service Mesh + Namesp.. 2025. 5. 30.
반응형

티스토리툴바