[aws] AI-driven DevOps(feat.gemini,chatgpt)

티스토리 뷰

IT/Devops

[aws] AI-driven DevOps(feat.gemini,chatgpt)

Hayley Shim 2025. 9. 28. 17:12

안녕하세요, 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' 카테고리의 다른 글

[cicd] 2주차 - Helm, Tekton (0)	2025.10.25
[cicd] 1주차 - Image Build (0)	2025.10.19
[aws] CICD 환경 구축(CodePipeline, CodeBuild, CodeDeploy) (1)	2025.08.31
[devops] DevOps Engineering (0)	2023.10.28

공지사항

광고 수익은 기부 활동에 사용됩니다:)

최근에 올라온 글

최근에 달린 댓글

Total

Today

Yesterday

링크

TAG more

« 2025/10 »
일	월	화	수	목	금	토
			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

글 보관함

create value with tech, not tool

티스토리 뷰