공부하기싫어
article thumbnail

프로젝트 : 웹서비스 스타트업의 인프라 설계 및 구축

구름(구름 쿠버네티스 전문가 양성 과정 6기) 에서 진행하는 k-digital 국비지원의 마무리 프로젝트 진행

훈련 과정에서 도커와 Ansible, 쿠버네티스 관련 기초 지식을 배웠고

이를 활용해서

'가상의 웹서비스 스타트업의 인프라 구축을 수주' 했다는 시나리오를 가지고 프로젝트를 진행했다.

 

 

참여했던 부분

- 요구사항 수집 + 분석 전반

- 인프라 설계 전반

- 서버 설계 일부

- 보안 설계 일부

- CI/CD 전반

 

초반 설계 단계인 요구사항 수집과 분석, 클라우드 기반 인프라 설계에 많은 의견을 냈었다.

배경도나 인프라 설계 diagram 등을 직접 작성했었다.

서버 설계보안 설계 일부분에 참여했다.

이후 CI/CD(Jenkins+ECR+Github+ArgoCD) 파트를 맡아서 해당 부분 설계와 구축을 담당했었다.

이 프로젝트에서 다른 팀원분들이 eks를 포함한 aws의 resource 들을 terraform 으로 관리했었는데

해당 부분에 참여하지 못해 아쉬웠다.

 

 

프로젝트 파일

  • PPT (.pdf)

프로젝트 과정을 요약한 프레젠테이션

[2조] 프로젝트 결과 발표의 사본.pdf
3.00MB

 

  • docs (.pdf)

요구사항 상세 + 배경도 + 설계도 + 구축과정 등을 상세 기재한 구글 문서 기반 pdf 파일

 

프로젝트 전체 pdf

GoormProject-0-전체.pdf
5.22MB

프로젝트 목차별 pdf

- 프로젝트 개요

GoormProject-1-개요.pdf
0.07MB

- 인프라 요구사항분석

GoormProject-2-요구사항분석.pdf
0.64MB

- 인프라 설계

GoormProject-3-설계.pdf
1.34MB

- 인프라 구축

GoormProject-4.3-구축-DB.pdf
0.51MB
GoormProject-4.2-구축-CICD-Pipeline (1).pdf
0.39MB
GoormProject-4.1-구축-인프라.pdf
2.29MB

- 테스트

GoormProject-5-테스트.pdf
0.65MB

  • github

https://github.com/cyaninn-entj/Goorm-kdt-Project

 

GitHub - cyaninn-entj/Goorm-kdt-Project: ci/cd dipper

ci/cd dipper. Contribute to cyaninn-entj/Goorm-kdt-Project development by creating an account on GitHub.

github.com

 

 

 

프로젝트 정리

1
2
3
4
5

처음 프로젝트를 시작할때 IaC 로 코드를 관리하면 좋겟다는 의견을 냈었다.

CI/CD 는 프로젝트 요구사항 수집 당시에는 얘기가 안되었지만

추후에 추가하게 되어 요구사항 수집-분석-설계 부분이 부족했었다.

동작하는 백앤드 앱과 db는 다른 조원분이 맡았었다.

 

6
7
8
9

다른 조원분 이름은 가렸습니다.

 

10
11

 실제 문제 정의(요구사항분석) 기간이 길어졌던 것에 비해 설계 단계에 쓴 시간은 짧았다.

여러 다른 프로젝트가 케이스별로 다르겠지만 이번 프로젝트에서는 각 조원들의 의견표명, 즉 소통이 잘 안됬던게 문제가되어 요구사항분석 단계에 시간을 오래 썼었다.

 나는 이때 내 의견을 정확하게 이야기를 했었는데 소통하는데 시간이 오래 걸렸던게 아쉽다.

 구축하는데도 문제정의와 설계단계에서 정확한 분석이 이루어지지 않았기 때문에 마지막 테스트 기간이 겹쳤어서 급하게 마무리했던 기억이 있다. CI/CD pipeline 을 간과해서 심도있는 설계가 되지 않았던게 이유였다.

 

12
13

요구사항수집 단계에서 도출해낸 토픽들이다.

인프라 중심으로 구성하려고 했었는데, 이 단계에서도 대부분의 요구사항들에 대한 의견을 냈었다.

 

14
15

설계도 단계에선 다른 팀원분들과 같이 작업했는데 5명이서 공유되는 문서를 같이 띄워놓고 한땀한땀 작업하는데 상당히 비효율적이라고 느꼈었다.

파트별로 나눠 설계한걸 조립하는 방식이 효율적일것 같았다.

 

16

한 조원분께서 3-tier architecture 에 대한 의견을 내주셔서 반영했다. 이 전엔 이런 구조에 대해 잘 몰랐었는데 공부가 되었다.

 

17

CI/CD 파트를 맡고 여러번 수정했었다. jenkins 와 argocd 가 정확히 어디에 위치해야할지 프로젝트 끝나기 전까지 정해지지 않았었는데, 이유는 jenkins 서버를 별도 인스턴스로 마련할지 아닌면 eks 안의 namespace 로 배치할지가 문제였다. terraform IaC 를 맡은 조원분께서 마지막까지 jenkins 와 argoCD 를 코드에 포함시키겠다고 하여 작업이 늦어졌었는데 이 부분을 설계단계에서 짚고 넘어갔어야 했다고 느꼈다.

결국 테스트 영상 촬영 시 jenkins server 를 따로 만들어서 pipeline 을 만들었었고 프로젝트 제출시에는 eks 안에 포함된 상태인걸로 제출했다.

 

18

네트워크 환경 구성 시 초반 설계에 참여했었다. vpc 생성 시 cidr 를 정해서 라우팅테이블을 작성했었는데 이후 IaC 를 담당한 조원분께서 내가 빠트렸던 nat gw나 eks control-plane 등을 추가해주셨다.

 

19
20

이 부분은 위 설명대로 다른 조원 두분이서 담당해주셧었다.

나는 cloudformation 을 이용한 yaml 파일로만 다뤄봤었어서 terraform 을 활용한 IaC 관리에 참여하고 싶었으나 CI/CD 작업이 지연되면서 참여하지는 못했다.

 

21
22
23
24
25
26

Pipeline 은 위와 같이 github webhook 을 사용해 jenkins 를 통해 빌드해서 ECR 에 container image 를 저장하고 argocd 가 github repo의 변화를 캐치해서 EKS 클러스터에 배포하는 방식으로 설계했다.

설계 당시 jenkins 구성에는 크게 어려운점이 없었으나 argoCD 의 kustomize 를 설정하는데 시간을 많이 썼었다. 잘 이해가 안되서 여러번 찾아봤었는데 결국 프로젝트 끝나기 전까지 제대로 적용시키지 못해서 아쉬웠다.

 

위 cicd 구현은 당시에 메이킹 로그를 남길겸 따로 포스팅해뒀다.

CI - https://yeonwoo97.tistory.com/327

 

Jenkins + ArgoCD + ECR + EKS 구성해보기 - CI -완-

EKS 클러스터는 terraform 으로 만들어져있는 상태 cloud9 을 통해 EKS 에 연결된 EC2 로 들어가서 작업 terraform 문서는 추후 업데이트 사전 작업 보안그룹 eks 가 초기에 보안그룹 2개를 할당하는것 같다

yeonwoo97.tistory.com

CD - https://yeonwoo97.tistory.com/328

 

Jenkins + ArgoCD + ECR + EKS 구성해보기 - CD -완-

이전 포스트에서 구현한 흐름 1. 로컬에서 깃허브로 push 하면 2. github 하고 jenkins webhook 으로 변화를 감지해서 트리거가 발동 3. eks 외부 jenkins 서버에서 깃의 jenkinsfile 에 따라 stages 진행 4. stage(chec

yeonwoo97.tistory.com

 

27
28
29
30
31
32
33

프로젝트 및 kdt 교육 수료 후기

  • k-digital 훈련 과정 종료 당시 수료 후기

ci/cd 를 문제정의와 설계 단계에서 조금 더 알아보지 못했던 점이 아쉽다. 이후 구현 시 갖은 오류로 시간을 뺏겼지만, manifast 을 활용한 관리를 처음 구현해봐서 의미있었다. k8s 관련하여 트러블슈팅을 해본 것도 좋은 경험이였다.

 

  • 프로젝트 종료 한달 후 다시 써보는 후기

 인프라를 요구사항 수집부터 설계 - 분석 - 구현 - 테스트까지 진행해봤을때 역시 협업에서의 ‘소통’은 상당히 중요하다는 것을 알았다. 워낙 수평적인 팀원간의 프로젝트여서 그런지 처음부터 가고자 하는 방향부터 달랐던게 아쉽다. 처음 팀의 미팅 시 상당부분 회의 안건이나 프로젝트 방향등을 제시했었지만 이 부분들을 명확하게 짚고 넘어가지 않아서 이후 요구사항 수집이나 분석단계에서 프로젝트 본질이 흐려질 때가 있었는데 지금 다시 생각해보면 당시 팀원들에게 목표를 명확히 명시해서 진행했다면 더 좋은 결과물이 있었을것 같다.

 이 프로젝트를 진행하면서 각 조원들이 하고싶은 주제를 하나씩 정해서 각자 인프라와 서비스를 개발한 후 하나로 합친 종합 플랫폼 형식의 인프라를 만들고 싶었으나 다른 조원들은 하나의 서비스를 다같이 설계하자고 하여 아쉬웠다. 인프라 분석-설계-구현 단계를 오롯이 혼자 해보고 싶었지만 업무가 분담되며 결국 CI/CD 파트를 메인으로 맡았고 인프라 분석과 설계 단계에 참여했었는데 IaC 를 통한 구현은 직접 해보지 못해 아쉬웠다.

 구현단계에서는 많은 시간이 소요됬었는데 분석-설계 단계를 간과하지 않았음에도 불구하고 고려하지 않았던 사항들이 많이 필요했기 때문이다. 이번 프로젝트를 통해 앞으로의 개인 프로젝트 혹은 취업 후 업무에서 분석-설계 단계는 더욱 심혈을 기울일 필요가 있음을 느꼈다.

 오랜만에 해보는 협업이였고 제대로된 작업공간과 수평적인 의사소통은 좋았지만, 팀원간의 의사표현이 명확하지 못하여 시간이 지체된점은 아쉬웠다. 그래도 EKS 상에서 컨테이너들을 띄워보며 CI/CD 를 처음 적용해본건 매우 의미있었다. Pipeline 의 강력함을 느꼈고, 이전에 진행하던 개인 프로젝트에도 Ansible 과 함께 적용해서 사용하는데 개발이 한결 수월해짐을 체감했다.

 

  • 지극히 개인적인 후기

일단 훈련 과정 초반에 너무 기초적인 내용이 많아서.. 솔직히 6주간은 그냥 줌켜놓고 AWS 강의들었다 ㅋㅋ

이후 docker 들어가면서 난이도가 확 올라갔는데 비전공자에게 굉장히 벅찰것 같은 느낌을 받았었다. 나중에 프로젝트 같은 조원이 된 비전공자분께서 말씀해주셧는데 많이 힘드셨었다고 한다.

오랜만에 제대로된 프로젝트를 끝냈고 프로젝트를 이렇게 제대로된 문서로 남기는건 처음이라 개인적으로 굉장히 의미있었다.

4학년 과목중에 소프트웨어공학 과목이 있는데, 시스템 개발 전반에 대한 내용을 다뤘었는데 도움이 많이 되었다.

 현재 개인 프로젝트 중에서 설계부터 백앤드+프론트앤드+인프라 구현 그리고 웹+앱 배포까지 구현해보고 있는데 이 프로젝트가 처음엔 가볍게 playstore 와 웹에 배포하려고 시작한 프로젝트였지만, 이번 구름 프로젝트 이후로 개발환경도 docker 로 바꾸고, ci/cd pipeline 도 적용시키고 있다. 마이크로서비스를 배우는데 있어서 굉장히 도움이 많이 되었다는 얘기임 ㅋㅋ

 kubernetes 는 규모가 어느정도 있는(큰?) 시스템을 효율적으로 관리할 수 있는 오픈소스여서 막상 내 개인 프로젝트에 k8s 를 적용한다고 하면 이건 과대포장이다. 그래서 앞으로 웹앱을 찍어낼 예정이다.(?) 재밌겠다 ㅋㅋ

ㅇㅇ 재밌었다. 전부 zoom 에서 진행되는 강의여서 상사분과 소통이 원할하지 않았고 9월초 허리디스크 때문에 많이 빼먹은 부분도 있지만, 어차피 필요한건 전부 google이 알고있으니 마이크로서비스 인프라 구축에 대한 방향을 배우는데 상당히 도움이 되었고, 앞으로 공부해야할 분야에 대한 충분한 로드맵을 알 수 있어 좋았다.

 이제 AWS 자격증 공부 한 후 개인프로젝트까지 배포 완료되면 이력서를 완성시킬꺼고, 취업한 이후에는 지금 계획 초기단계인 sns 앱을 천천히 개발해볼 예정이다. API server 도 만들어보고싶어서 Go lang 을 공부할 생각이고 4학년 2학기중 애먹었던 db 설계 부분도 꼭 알아는 둬야겠다는 생각이다. 인프라 엔지니어는 모르는게 있으면 안되긴함 ㅋㅋ 끝!