파이널 프로젝트코드스테이츠 데브옵스 부트캠프를 진행하며, 파이널 프로젝트를 마무리 지었다.기존 설계과정과 구현과정은 데일리회고로 남겨두었지만, 이 글에서 다시 한 번 정리하며 후기를 작성하려한다.프로젝트 기획기존의 프로젝트에서는 어떤 서비스를 써야하는지, 어떤 서비스를 만들어야 하는지 주어졌다면, 파이널 프로젝트는 최소한의 큰 주제를 받고, 거기에 맞춰 직접 시스템을 설계하는 방식으로 진행되었다.우리가 고를 수 있는 시나리오는 총 3개였고, 그 중 우리는 첫번째 시나리오인 마라톤 대회 기록 시스템 시나리오를 선택했다.마라톤 대회 기록 시스템시나리오 선정이유기능 요구사항이 명확기존의 배웠던 서비스들을 최대한 활용 가능인프라에 집중할 수 있고, 백엔드 쪽에 비중을 크게 두지 않아도 됨시나리오 요구사항 및 분..

To-Do CI/CD Docker image tag 기존의 ECR에 업로드 되는 이미지들은 Github Actions를 통해 ${{ github.sha }} 환경변수를 이용하여 커밋의 id를 이미지 태그로 사용하였다. 하지만 커밋 id의 길이가 너무 길다는 점과, 정작 Github에서 보이는 커밋 id는 짧게 되어있기 때문에, 굳이 그대로 사용할 필요가 없다고 느꼈다. - name: Set short git commit SHA id: vars run: | calculatedSha=$(git rev-parse --short ${{ github.sha }}) echo "::set-output name=short_sha::$calculatedSha" 먼저, ECR 로그인을 하는 step위에 git commit..

To-DoGithub ActionsECS 서비스들의 각각 CI/CD Pipeline을 구축하고 브랜치를 병합하는 문제와 task-definition.json 파일이 업데이트 될때마다 수동으로 업로드 해줘야 한다는 점에 대해 팀원들과 의견을 나눴고, 작업을 담당했다.Github Actions 공식 문서를 보며 특정 조건에 트리거를 걸 순 있었지만, 생각했을 때 과연 이게 필요한 과정인가 싶어져서 고민을 하게 됐다.어떤 파일은 추적을 하고, 어떤 파일은 제외를 시키고, 이런 형식의 workflow를 3개씩 관리하다보면 복잡하고 어렵고 무거워지지 않을까 라는 결론에 도달하여 결국 브랜치를 분리하여 관리하는 것이 더욱 좋다고 생각이 들었고, CI/CD Pipeline을 통합하는 작업은 하지 않게 되었다.task..

To-DoRDS 생성AWS 콘솔을 사용하여 MySQL을 구성했고, 접속한 뒤 테이블 세팅을 하였다.데이터를 넣으며 테스트를 하던 중 다른 팀원분께서 의견을 남겨주셨다.point 테이블의 point 칼럼이 생성되어 에러 방지 및 명확한 칼럼명 사용을 위해 point칼럼을 user_point 칼럼으로 변경했고, ERD에 반영했다.Lambda 함수 구현SQS를 통해 기록 데이터를 받을 때마다 유저의 점수를 1씩 증가하는 로직을 서버리스로 구축하였다.구축을 해놓고 연결 확인을 하던 중 private subnet에 위치한 RDS에 접근하기 위해 여러 방법을 생각해보았고,의견을 나눈 뒤 Lambda 함수를 private subnet에 종속시키는 것으로 결정되었다.Today...아키텍처를 조금 더 보기 좋게 변경해보..

To-Do 업무 분배 CI/CD Pipeline 구성 ECR에 도커 이미지를 빌드해 올리고, 그 이미지를 바탕으로 ECS 클러스터의 task를 교체하는 GitHub Actions workflow 파일을 작성하였다. GitHub에서 ECS 배포 자동화를 해주는 Actions workflow 파일의 양식을 제공해 주기 때문에, 필요한 리소스들의 이름만 잘 맞춰서 적어준다면 큰 문제없이 CI/CD 파이프라인을 구축할 수 있다. name: Deploy to Amazon ECR on: push: branches: - feature/ecs-race-record pull_request: branches: - main env: AWS_REGION: ap-northeast-2 ECR_REPOSITORY: race ECS..

To-Do아키텍처 점검 미팅아키텍처를 설계한 뒤 엔지니어님과 미팅을 통해 피드백을 전달 받았다.ECS의 점수 task와 람다의 점수 확인 함수가 하는 일이 동일시 되어 해당 람다를 삭제하는 방향으로 결정하였다.점수 확인의 경우 매분매초 요청이 들어오지 않더라도, 자주 사용되고 조회되는 서비스일 것이라 생각하여 람다보다는 ECS task를 통해 제공하는 것이 적합하다고 판단했다. 또한 회원 도메인에서 설계한 RDS를 DynamoDB로 변경함으로 회원 정보의 데이터가 삭제되지 않음으로 필요한 수평확장성과 비용적인 부분에서의 이점을 챙기기로 했다.추가적으로 SQL과 NoSQL을 둘 다 사용해봤다는 것을 어필할 수 있을 것 같았다. 회원 도메인의 ECS를 람다로 변경하는 방법에 대해 엔지니어님이 제안을 해주셨지..

To-Do아키텍처 설계 보완어제 아키텍처를 설계 한 뒤 팀원이 살펴보고 의견을 남겨줬다.아침에 이 의견과 다른 것들을 조금 더 살펴본 뒤 아키텍처를 수정할 필요가 있기에 전체적으로 다시 보완하는 시간을 가졌고, 한 눈에 알아볼 수 있도록 조금 정리를 하였다.먼저 권한 문제를 고려해 람다를 서브넷 안에 포함시킬 필요가 없다고 결정이 됐고, 또한 VPC 내에도 종속될 필요가 없어 람다는 VPC 외부로 옮겼다.ECS를 쓰는 이유에 대해선 후술하겠다. 기존에는 대회/기록 DB와 점수 DB를 안정성을 고려해 분리하려 했지만, 비용문제 또한 무시할 수 없기에 둘 중 어느것을 우선순위로 둬야할까 고민을 했고, 결국 이후에 다시 수정하게 되더라도 당장은 비용문제를 더 고려해야 했기에 두 DB를 합치기로 결정했다. 또한..

To-Do엔지니어 미팅담당 엔지니어님과 아침 9시부터 미팅을 진행했고, 전날 설계한 DDD 그림과 ERD를 보여드리며 설명하고, 왜 이렇게 설계했는지에 대해 답변을 했다.요구사항을 같이 하나하나 짚어보며 빠진 부분들이 있는 것을 발견했고, 오늘은 전체적으로 수정한 뒤 아키텍처 구성을 하는 쪽으로 정했다.CRUD 문서 작성엔지니어님이 미팅 중 CRUD 문서를 작성하며 설계를 하다보면 빠트리는 부분 없이 진행할 수 있을 것이란 조언을 듣고, CRUD 문서를 간단히 작성했다.문서를 정리하며 필요한 기능을 다시 생각해보니 조언해주신 것처럼 필요한 게 무엇인지 더 수월하게 파악할 수 있었다.ERD 수정CRUD 문서를 작성 한 뒤 ERD를 다시 살펴보며 수정을 하던 중 DB정규화에 관해 이슈가 생겼다. 참고자료정규..