핵심 역량 별 경험 정리

mizu·2025년 1월 5일

DevOps

목록 보기
5/8

하이브리드(AWS, GCP, 온프레미스) 환경에서 DevSecOps 기반 CI/CD 파이프라인 구축 및 운영

✅ Jenkins와 ArgoCD 활용
✅ Docker Image를 Pull 해와서 Linux 서버 위에서 관리
✅ SonarQube 활용하여 코드 품질 및 보안 관리
✅ Trivy 사용하여 Docker Image 취약점 파악

어려웠던 점
(1) Jenkins Console에 성공으로 찍히나 실제로는 그렇지 못했던 사례

  • Jenkins는 Linux 서버에 Docker 이미지로 Pull 한 상태.
  • S3에 빌드된 내용물이 올라가야 하는데 그렇지 못했음.
  • Console에는 Success로 뜨나 실제 Bucket을 확인해보면 없었음.
  • CLI의 --recursive가 문제가 되나 싶어서 뺐다가 다시 돌려봤지만 여전히 Success, 그러나 파일은 올라가지 않았음.
  • Jenkins Credential에 분명히 Access Key ID와 Secret Access Key 다 저장된 상태였음.
  • 여기서 아이디어를 얻어 Jenkins Container에 AWS CLI를 설치해두고 거기에는 Credential을 넣지 않았다는 것을 떠올림
  • 이후 AWS CLI에 Configure 커맨드로 정보 넣고 문제 해결

(2) Disk space is below threshold of 1.00 GiB.

  • 테스트를 마구잡이로 돌렸더니 발생한 디스크 용량 문제
  • 파이프라인에 불필요한 내용들을 시작하기 전, 끝난 후에 지워주는 것으로 자원 확보

(3) SEVERE h.model.UpdateCenter$DownloadJob#run: Failed to install aws-java-sdk-lambda - java.io.IOException: No space left on device

  • 디스크 용량 부족
    • EC2에 연결된 EBS의 볼륨을 증가 ( 8 → 16 )

Terraform을 활용한 IaC 구현으로 인프라 자동화 및 효율적인 배포 관리

✅ GCP Storage에 tfstate 파일 저장 및 관리
✅ VPC 설정
✅ Compute Instance에 start-script 반영하여 생성
✅ GCP 계정 이전시 Terraform 활용하여 만 1일만에 이전 계정과 동일한 상태로 구성
✅ Terraform 모듈화하여 관리. 필요한 내용만 Production 폴더로 가져와서 사용

어려웠던 점
(1) tfstate 파일로 버전 관리하는 것을 해보고 싶었으나, 혼자 사용한 탓에 따로 관리가 필요하지 않았음.
(2) GCP 계정 이전 문제

  • 계정에 문제가 생겨 다른 계정으로 옮겨야 했음
  • GCP를 관리하던 사람이 나 혼자였기에 도움을 받을 수 있던 상황이 아니었음
  • AWS의 CloudFormation 같은 서비스를 찾지 못했기에 더욱 막막했음
  • 기술 블로그들을 검색하다가 gcloud 명령어로 전체 에셋을 json 파일로 받을 수 있다는 것을 알게 됨.
  • gcloud로 json 파일을 받고, 이를 AI를 통해 terraform 코드로 변경할 수 있었음
  • terraform 코드를 통해 빌드를 한 후, 디스크는 구계정에 신계정 권한을 주고 빼오는 식으로 진행
  • 덕분에 만 1일만에 모든 아키텍처 그대로 옮길 수 있었음

GCP GCR 기반 컨테이너 이미지 관리 및 3-Tier 아키텍처 설계/구축

✅ FE : Google Storage + Load Balancer (CDN) 
✅ BE : Compute Instance + Load Balancer
✅ AWS RDS 와 GCP cloud SQL DMS 활용하여 연동

설명

  • Jenkins에서 도커 이미지를 만들고 그것을 GCP GCR로 옮기는 작업을 진행함
  • Compute Instance의 Script에 GCR에서 이미지를 Pull 해오는 것까지 자동화
  • Backend와 Cloud SQL은 private subnet에, Frontend는 public subnet에 생성
  • AWS의 DR로 GCP를 사용하기로 했기에 VPC가 피어링 되어야 했음
  • AWS의 Site-to-Site VPN 서비스와 GCP의 VPN 서비스로 각 벤더사에서 사용하고 있는 VPC 연동
  • 각 VPC에 존재하는 Linux 서버에서 Ping 테스트 및 telnet 테스트를 통해 연동 확인
  • 그러나 DMS는 작동하지 않았음. 계속 연결이 되지 않았다는 에러만 뜨길래 다른 방법 ( Public IP )로 해결
  • Public IP는 보안 문제가 발생할 수 있기 때문에 빨리 방법을 찾아야 했음
  • 기술 블로그 및 공식 문서를 찾다가 VPN의 라우팅 방법이 동적이었기에 DMS가 작동하지 않았다는 것을 확인.
  • 동적 연결을 해지하고 정적 연결을 진행. 이후 문제 해결.

Route53 ACM을 활용한 글로벌 분산형 애플리케이션 운영 시스템 구축

✅ Route53에서 도메인 구매 및 관리
✅ ACM으로 SSL 관리 및 사용
✅ Route53에서 FailOver Routing 사용하여 
   Primary는 AWS, Secondary는 GCP로 설정 후 전환 확인
   AWS -> FE는 CloudFront, BE는 ALB 설정
   GCP -> FE, BE 모두 Load Balancer와 연결 진행
   

어려웠던 점

  • AWS를 EKS로 관리. FailOver 테스트를 위해 아무리 EC2를 죽여도 FailOver가 되지 않는 상황 발생.
  • ALB도 삭제해보려고 하였으나 진행되지 않음.
  • 이를 해결하기 위해 EKS의 설정을 확인해보기로 함.
  • 특히 NodeGroup을 먼저 확인해보기로 함. NodeGroup의 역할이 EC2를 생성하고 관리하는 역할이기 때문.
  • 여기에서 최소, 최대가 각각 2로 잡혀있어서 삭제가 제대로 되지 않고 계속 생성되는 것을 확인함
  • 이를 0으로 줄이고, ALB를 삭제하였더니 자동으로 FailOver Routing이 진행되며 GCP로 전환됨.
  • GCP로 전환된 것은 SSL 인증서를 통해 확인함. AWS는 ACM 사용, GCP는 let'sencrypt 활용.

대규모 시스템의 장애 대응 및 성능 최적화를 위한 모니터링/테스트

✅ Observability as Code 라는 주제로 세미나 진행
✅ Grafana, Prometheus, Terraform 등을 사용하여
   DashBoard as Code, Alert as Code 모니터링 방법론 제시
✅ AutoScaling 그룹을 만들 때, stress-ng로 부하를 주어
  실제로 AutoScaling이 이루어지는가 테스트
  

Spring Boot와 React, RDBMS 기반의 풀스택 개발

** BE**
✅ 총 19개의 API 중 4개 개발
✅ API Response 통일

**FE**
✅ 프론트엔드 총괄
✅ UI 통일 및 폴더 구조 가이드라인 제시
✅ Fetch 사용하여 API 연동

**RDBMS**
✅ MySQL 사용 
profile
문제를 해결해보자 ✨

0개의 댓글