✅ 하이브리드(AWS, GCP, 온프레미스) 환경에서 DevSecOps 기반 CI/CD 파이프라인 구축 및 운영
📍 Trivy, SonarQube 활용 경험
✅ Terraform을 활용한 IaC 구현으로 인프라 자동화 및 효율적인 배포 관리
📍 Terraform을 활용하여 재구축을 하루 만에 끝낼 수 있었음
📍 AWS CloudFormation에서 아이디어를 착안해서 gcloud로 전체 에셋에 대한 json 파일 추출 -> Terraform 코드로 전환 -> 빌드 -> 세부적인 사항은 console로 조정 -> Disk는 권한 조정으로 그대로 이전
✅ GCP GCR 기반 컨테이너 이미지 관리 및 3-Tier 아키텍처 설계/구축
✅ Route53 ACM을 활용한 글로벌 분산형 애플리케이션 운영 시스템 구축
📍 Route53과 ACM을 통해서 도메인 및 SSL 인증서를 관리
📍 FailOver Routing으로 AWS와 GCP 간의 트래픽 전환 확인
✅ 대규모 시스템의 장애 대응 및 성능 최적화를 위한 모니터링/테스트
✅ Spring Boot와 React, RDBMS 기반의 풀스택 개발
프로젝트 간단 요약
멀티 클라우드로 고가용성을 보장하는 응급실 병상 확인 및 예약 서비스
- 왜 멀티 클라우드 ?
물론 Region을 다르게 한다던지, Availability Zone을 여러개를 둔다던지 하는 방향으로 고가용성을 구현할 수 있지만, 저희는 Azure의 클라우드 스트라이크 사태를 보고 한 벤더사에 종속되지 않는 구성을 해보고 싶어서 이렇게 도전을 해보았다. - 왜 AWS/GCP?
Azure를 제외하고 가장 많은 파이를 차지하는 것 2개. 또한 AWS/GCP에서 크레딧을 제공해줘서 비용적인 측면에서도 도움이 되었다. ( 부트캠프 지원 및 무료 제공 크레딧 ) - 목표했던 것
(1) 기존의 종합상황판 개선하기 - 프론트엔드 가독성 개선, 백엔드 효율성 개선 - 달성 ⭕️
(2) 멀티 클라우드 구축 - 달성 ⭕️
담당한 파트
- GCP 설계, 구축 및 운영
✅ FrontEnd : Storage + Load Balancer + SSL
📍 AWS에서 S3+CloudFront 조합을 차용하여 구성
📍 GCP에서는 Load Balancer에서 CDN 역할을 해줌
📍 SSL 인증서는 구글 인증서를 사용하려고 하였으나 어느 순간부터 작동하지 않아 Let's encrypt 무료 SSL 인증서를 사용
✅ BackEnd : Instance Group + Load Balancer + SSL
📍 Auto-Scaling Group으로 CPU에서 60% 이상 사용되면 자동으로 스케일 업
📍 Instance Group의 첫번째 인스턴스에 metadata로 start-script를 작성. 이후 이를 복제하여 2,3번째 인스턴스가 만들어짐
📍 HTTP/HTTPS Load Balancer : 백엔드에 들어오는 트래픽을 분산
📍 Health Check : Health Check를 위한 엔드포인트를 따로 만들지 않아서 Swagger 엔드포인트로 연결하여 확인
📍 Google Artifact Registry를 활용하여 Docker Image 연결- DockerHub의 private version은 유료
- Google Artifact Registry는 GCP 서비스기에 IAM 역할 및 권한을 사용하여 사용자 제어가 가능
- 멀티 클라우드 연결
✅ VPC peering
참고 사이트 : https://blog.naver.com/PostView.naver?blogId=blueday9404&logNo=223055342609
📍 Site-to-Site VPN과 일반 VPN으로 각 벤더사에서 사용하고 있는 VPC 연결
📍 IPsec VPN - Network to Network
AWS에서 GCP로 넘어가려는 패킷이 공인망 (터널)을 통해서 상대편으로 넘어갈 수 있게 함
📍 BGP - Border Gateway Protocol
데이터가 이동할 수 있는 모든 경로를 살펴보고 최적의 경로를 선택하는 것
📍 정적 라우팅
관리자에 의해 Routing Table이 유지/관리. 외부에 자신의 경로를 알리지 않기 때문에 보안에 강함.
📍 각 방화벽에 ICMP 프로토콜 오픈
네트워크 장치에서 네트워크 통신 문제를 진단하는 데 사용되는 네트워크 계층 프로토콜
✅ AWS-GCP DMS
📍 AWS를 메인으로 두고, GCP는 DR로 사용
📍 소스 - AWS RDS, 타겟 - GCP Cloud SQL
📍 DMS를 지속적으로 하되, AWS에 장애가 생겨 끊길 경우에는 GCP는 Cloud SQL을 사용하여 Transaction을 처리
- CI/CD 파이프라인
✅ FE Jenkins 사용 : GitHub Develop Clone - SonarQube Quality Test - NPM build - S3/Storage Upload - CloudFront Cache Invalidation
✅ BE Jenkins 사용 : GitHub Develop Clone - SonarQube Quality Test - Gradle Build - Docker Image Build - Artifact Registry/ECR - Update K8S Manifest
📍 보안 사항은 Jenkins Credential로 암호화 처리 후 사용
📍 왜 Jenkins?
오픈 소스로 비용을 아낄 수 있고, 다양한 플러그인을 제공하기 때문.
✅ GitOps/ArgoCD
직접 개발에 참여한 것은 아니나, GitOps가 무엇인지, ArgoCD를 어디에 사용하였는지는 파악하고 있음.
📍 깃 저장소에 저장된 쿠버네티스 매니페스트 같은 파일을 이용. 배포를 선언적으로 진행.
📍 인프라와 소프트웨어를 함께 관리, Git 버전 관리 시스템과 운영 환경 간의 일관성 유지, 소프트웨어 간의 불일치 문제 해결
📍 모든 코드와 인프라 변형 사항이 Git 저장소에 저장, 변경 내역 추적하고 롤백 진행
📍 ArgoCD는 이를 구현하기 위한 도구. Kubernetes 애플리케이션의 자동 배포를 위한 오픈소스.
프로젝트에서 아쉬웠던 점
✅ GCP 부분에서 완전 배포 자동화를 이뤄내지 못함
- Docker Image가 업데이트 되어 Artifact Registry에 반영되어도 자동으로 VM에 반영되지 않음
- Metadata에 start-script를 작성해두고, 이를 반영하는 부분에 대한 건 작성하지 않았음. 따라서 1번 VM과 2번 VM 간에는 간극이 존재할 수 있음
- 이를 위해서 수동으로 docker image의 업데이트 분을 반영해줘야 함
- 나중에 기회가 된다면 Artifact Registry의 변화를 감지하는 웹훅을 사용하고, 기존의 이미지와 현재 사용중인 이미지를 비교하는 JOB을 만들어서 반영하고 싶음.
✅ CI/CD 파이프라인에서 테스트 단계가 빠져있음
- Jenkins에서는 이미 Github Develop으로 Merge된 부분에 대해서 파이프라인을 작성했기 때문에 아쉬움
프로젝트에서 가장 자랑스러운 점
✅ 멀티 클라우드는 멘토들도 우려할 정도로 규모가 큰 도전이었는데 이를 해냈다는 점이 가장 자랑스러움
✅ 문제가 발생했을 때 차분하게 돌이켜보고 배운 점을 토대로 여러가지 해결방법을 꺼낸 것이 자랑스러움
📍 GCP 계정 문제 발생 시, Terraform이라는 IaC 도구를 생각해내고 이를 활용한 점
