하이브리드(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 )
✅ 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 사용