티스토리 뷰
안녕하세요, devops를 이해하기 위해 학습한 내용에 대한 정리글입니다.
그전에 Gemini에게 Agent AI가 나오면서 앞으로 devops 전망에 대해 물어봤습니다.
✦ 결론부터 말하면, DevOps 엔지니어의 역할은 사라지는 것이 아니라 'AI 조련사', '자동화 시스템 설계자' 와 같이 더 높은 수준의 전략가로 변화할 것입니다. DevOps의 각 단계가 AI 에이전트를 통해 어떻게 변하는지 살펴보면 다음과 같습니다.
1. 기획 및 설계 (Plan & Design)
* 현재: 사람이 요구사항을 분석하고 아키텍처를 설계합니다.
* AI 에이전트 도입 후: AI가 요구사항 문서를 분석해 최적의 기술 스택, 아키텍처 패턴, 예상 리소스 등을 추천합니다. 잠재적인 병목 현상이나 보안 취약점을 설계 단계에서 미리 예측하고 경고합니다.
2. 개발 (Develop)
* 현재: 개발자가 코드를 작성하고, 동료가 코드 리뷰를 합니다. (GitHub Copilot 등이 보조)
* AI 에이전트 도입 후: 개발자가 기능의 목표와 요구사항을 명시하면, AI 에이전트가 전체 기능에 대한 코드를 초안으로 작성하고 관련 단위 테스트(Unit Test)까지 생성합니다. 사람은 AI가 작성한 코드의 로직과 구조를 검토하고 개선하는 '리뷰어' 및 '설계자'의 역할에 더 집중하게 됩니다.
3. 빌드 및 테스트 (Build & Test) - CI (Continuous Integration)
* 현재: 미리 정의된 규칙에 따라 CI 파이프라인이 실행되고, 정해진 테스트 케이스를 수행합니다.
* AI 에이전트 도입 후: AI가 코드 변경의 맥락과 위험도를 분석하여 지능적인 파이프라인을 동적으로 구성합니다. 예를 들어, 간단한 UI 수정은 가벼운 테스트만 실행하고, 핵심 로직 변경은 더 복잡하고 광범위한 테스트를 자동으로 추가하여 실행합니다. 테스트가 실패하면, AI가 로그와 변경 사항을 분석해 실패의 원인을 추정하여 알려줍니다.
4. 배포 (Deploy) - CD (Continuous Deployment)
* 현재: 카나리, 블루/그린 등 정해진 전략에 따라 배포가 진행됩니다.
* AI 에이전트 도입 후: AI가 배포 중 실시간으로 성능 지표(지연 시간, 에러율 등)를 분석합니다. 카나리 배포 중 이상 징후가 감지되면, 사람의 개입 없이도 AI가 스스로 판단하여 롤백을 결정하고 실행합니다. 이를 통해 장애를 사전에 방지합니다.
5. 운영 및 모니터링 (Operate & Monitor)
* 현재: 엔지니어가 대시보드를 보며 이상 징후를 파악하고, 문제가 생기면 로그를 분석해 원인을 찾습니다.(AIOps 초기 단계)
* AI 에이전트 도입 후:
* 이상 징후 예측: AI가 과거 데이터를 학습하여 "30분 내에 디스크가 가득 찰 것" 또는 "트래픽 패턴으로 보아 곧 서버 다운 가능성이 있음"과 같이 장애를 예측합니다.
* 자동 원인 분석 (Root Cause Analysis): 장애 발생 시, AI 에이전트가 관련 로그, 메트릭, 배포 기록 등을 순식간에 종합하여 "5분 전 배포된 X 버전의 Y 함수가 원인"이라고 정확한 원인을 알려줍니다.
* 자율적인 복구 (Self-Healing): 가장 진화된 형태로, AI가 문제의 원인을 파악한 뒤 스스로 해결책(예: 문제되는 서비스 재시작 리소스 증설, 문제 버전 롤백)을 찾아 자동으로 시스템을 복구합니다.
DevOps 엔지니어의 역할 변화
- 단순하고 반복적인 작업(스크립트 작성, 파이프라인 설정, 로그 분석 등)은 점차 AI 에이전트에게 위임될 것입니다. 대신 DevOps
엔지니어는 다음과 같은 더 고차원적인 역할을 수행하게 됩니다.
* AI 시스템 설계 및 감독: 전체 개발-운영 사이클을 자동화하는 AI 에이전트 시스템을 설계하고 이들이 올바르게 작동하는지 감독
* 목표 및 정책 설정: "배포 시 에러율은 0.01% 미만이어야 한다" 또는 "비용이 X 달러를 넘지 않는 선에서 자동으로 확장하라"와 같은 비즈니스 목표와 정책을 AI 에이전트에게 설정해줌
* 복잡한 문제 해결: AI가 해결하지 못하는 복잡하고 예외적인 문제나 여러 시스템이 얽혀있는 대규모 장애 상황을 해결하는 최종 전문가 역할을 함
결론적으로, AI 에이전트는 DevOps를 없애는 것이 아니라, DevOps의 궁극적인 목표인 '더 빠르고 안정적인 소프트웨어 제공'을 극대화하는 강력한 도구가 될 것입니다. DevOps는 'AI-driven DevOps'로 진화하며, 엔지니어들은 자동화의 실행자가 아닌 설계자이자 전략가로 거듭나게 될 것입니다.
[실습 환경]
아키텍처 - cloud9 환경 구성
-
cloud9용 VPC의 private subnet에 cloud9구성
-
aws cli update
-
패키지 설치
-
kubectl
-
terraform
-
helm
-
jq
-
아키텍처 - 네트워크 환경 구성
- terraform-aws-modules/vpc/aws" 모듈을 사용하여 기반환경 구성
아키텍처 - EKS 환경 구성 및 EKS 권한 부여
-
terraform-aws-module/eks/aws 모듈 사용
- 유저가 aws console로 eks 자원정보를 확인 할 수 있도록 권한을 부여한다.
아키텍처 - ALB Controller 적용
-
클러스터와 연결되는 elb를 관리하는 aws-load-balancer-controller를 구성 한다 (terraform으로 구성)
-
예제 프로그램을 helm chart를 이용하여 배포한다.
아키텍처 - 모니터링 구성
-
EKS PV를 컨트롤할 수 있는 ebs_csi_driver addon을 구성한다.
-
prometheus를 구성한다
-
grafana를 구성한다.
Error
k8s-grafana-grafana-2fe56ed5a4-1660501491.ap-northeast-2.elb.amazonaws.com 페이지를 찾을 수 없음 다음 웹 주소(http://k8s-grafana-grafana-2fe56ed5a4-1660501491.ap-northeast-2.elb.amazonaws.com/)에 대해 발견된 웹페이지가 없습니다. HTTP ERROR 404
ChatGPT:
ALB 주소로 접속했을 때 404 Not Found가 발생하는 주요 원인은 다음과 같습니다:
🔍 주요 원인 진단
🔸 ALB는 열렸지만 백엔드 서비스로 트래픽이 라우팅되지 않음 | Ingress 설정의 host, path, serviceName 등이 ALB 설정과 불일치하거나 빠짐 |
🔸 Grafana Ingress가 grafana.local 호스트에만 반응 | 브라우저에서 grafana.local 도메인이 아닌 ALB DNS 이름으로 직접 접속하면 404 발생 가능 |
🔸 healthcheck 실패로 ALB Target이 unhealthy 상태 | /login 경로가 잘못되었거나 Grafana가 아직 준비 안됨 |
replicaCount: 1
adminPassword: admin123
persistence:
enabled: true
storageClassName: gp2
size: 10Gi
service:
type: ClusterIP
port: 80
targetPort: 3000 # ✅ Grafana 기본 포트로 맞춤
ingress:
enabled: true
ingressClassName: alb
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
alb.ingress.kubernetes.io/healthcheck-path: /
alb.ingress.kubernetes.io/success-codes: 200-399
path: /
pathType: Prefix
servicePort: 80
hosts: [] # ✅ 이 줄이 핵심입니다. 빈 리스트로 명시해야 host 조건을 제거함
datasources:
datasources.yaml:
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
url: http://prometheus-server.prometheus.svc.cluster.local
access: proxy
isDefault: true
[root@ip-10-0-136-60 grafana]# kubectl describe ingress grafana -n grafana
Name: grafana
Labels: app.kubernetes.io/instance=grafana
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=grafana
app.kubernetes.io/version=12.0.2
helm.sh/chart=grafana-9.2.10
Namespace: grafana
Address: k8s-grafana-grafana-2fe56ed5a4-995194297.ap-northeast-2.elb.amazonaws.com
Ingress Class: alb
Default backend: <default>
Rules:
Host Path Backends
---- ---- --------
chart-example.local
/ grafana:80 (10.7.1.145:3000)
Annotations: alb.ingress.kubernetes.io/healthcheck-path: /
alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}]
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/target-type: ip
kubernetes.io/ingress.class: alb
meta.helm.sh/release-name: grafana
meta.helm.sh/release-namespace: grafana
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfullyReconciled 2m55s ingress Successfully reconciled
kubectl describe ingress grafana -n grafana 결과를 보면 여전히 Ingress의 Host가 chart-example.local 으로 설정되어 있습니다:
즉, 지금까지의 Helm 업그레이드에도 불구하고 ingress.hosts 항목이 누락된 상태로 Helm 기본값(chart-example.local)이 계속 적용되고 있는 것입니다.
✅ 해결 요약
values.yaml에 아래 항목을 명시적으로 추가하여 Helm 기본값을 덮어써야 합니다:
ingress:
enabled: true
ingressClassName: alb
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
alb.ingress.kubernetes.io/healthcheck-path: /
alb.ingress.kubernetes.io/success-codes: 200-399
path: /
pathType: Prefix
servicePort: 80
hosts: [] # ✅ 이 줄이 핵심입니다. 빈 리스트로 명시해야 host 조건을 제거함
아키텍처 - 로깅 구성
-
opensearch를 구성한다(terraform)
-
fluentbit 배포
-
opensearch의 kibana를 통해 로깅 구성 확인
prompt)
terraform을 통해 opensearch domain과 k8s 내부의 fluent-bit에서 사용할 role과 policy, kubernetes serviceaccount(irsa)를 만든다.
opensearch는 기본적으로 access policy를 설정하도록 강제하는데, opensearch에 접근할 사용자의 로컬과 cloud9, eks 내부의 fluent-bit에서 접근을 허용하기 위해 ip를 추가한다.
Error :
{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet because no resource-based policy allows the es:ESHttpGet action"}
[root@ip-10-0-136-60 eks]# curl -u test:Test123@ https://search-user07-o5hh2m7vkue3vsbbfym3v7nkle.ap-northeast-2.es.amazonaws.com/_cat/indices?v
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open .opensearch-observability uezmDIwGT1Olougc913rFw 1 0 0 0 208b 208b
green open .plugins-ml-config rd-OjMCHSmSvFDpy5okiag 5 0 1 0 4.7kb 4.7kb
green open .ql-datasources RLhN_BU_R_qy0spRKWJRmg 1 0 0 0 208b 208b
yellow open logstash-2025.07.25 39Ik7pguRRSx1bGSLdTosA 5 1 129 0 378.3kb 378.3kb
green open .opendistro_security qdCsw4SvQJqllNdUIgRX1g 1 0 10 1 62kb 62kb
green open .kibana_1 PThTUBMHSOi2u6oaYb3qng 1 0 1 0 5.2kb 5.2kb
OpenSearch Dashboards 접속 시 anonymous not authorized 오류 -> 출력 결과를 보면 logstash-2025.07.25 인덱스가 정상적으로 생성되어 있습니다. 이는 Fluent Bit → OpenSearch 로그 수집이 성공적으로 작동 중이라는 뜻
'IT > Devops' 카테고리의 다른 글
[aws] CICD 환경 구축(CodePipeline, CodeBuild, CodeDeploy) (1) | 2025.08.31 |
---|---|
[devops] DevOps Engineering (0) | 2023.10.28 |
- Total
- Today
- Yesterday
- AWS
- cloud
- 파이썬
- OS
- S3
- terraform
- 혼공파
- gcp serverless
- handson
- SDWAN
- GCP
- NW
- 혼공챌린지
- EKS
- 혼공단
- security
- PYTHON
- GKE
- 도서
- IaC
- controltower
- VPN
- cni
- k8s cni
- k8s
- k8s calico
- AI
- operator
- NFT
- autoscaling
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |