InhaBas / Inhabas.com-api

인하대학교 빅데이터 동아리 IBAS 웹앱, rest 개편 프로젝트 (2021.12.21~)
https://www.inhabas.com
9 stars 11 forks source link

[bugfix/Inhabas#286] github actions 개선 및 버그 수정 #304

Closed whitem4rk closed 3 months ago

whitem4rk commented 3 months ago

기존 문제 - PR시 헤드브랜치가 아닌 베이스브랜치 코드를 기반으로 실행되는 문제

  1. PR시, PR에서 추가 PUSH시, 병합 시 gradle build 실행
  2. PR이 main에 병합 시 dev 서버 배포 후 webhook 발생
  3. release-* 형태로 생성된 branch는 production 서버 배포 후 webhook 발생
whitem4rk commented 3 months ago

안녕하세요 :) 1기 팀장으로 있었던 양태영입니다. 이전에는 장고로 개발했었는데, 요즘은 스프링으로 개발하나보네요 :)

주제넘지만, 감회가 새로워서 코드도 볼 겸 현업자 입장에서 리뷰 몇 개 남겨볼테니 한번 고민해보시는 것도 성장에 있어 도움이 많이 될 것 같습니다.

안녕하세요~ 전혀 주제 넘지 않습니다... 안그래도 현재 코드가 어느 부분이 부족한지 알기 쉽지 않아서 고민중이었습니다. 처음 spring으로 개편할때는 태영님이 만드신 장고서버보다 나은 서버를 만들려고 했는데 권한부분이 하도 복잡해서 구현하다가 오히려 삭제한 기능도 꽤 있었고 솔직히 속도나 유지보수 측면에서도 나아졌는지도 잘 모르겠습니다.

spring 코드나 아키텍쳐나 데브옵스 부분(아주 적지만) 어느 부분이든 리뷰 남겨주시면 적극 반영하려 노력하겠습니다. 아직 부족한점이 많아서 리뷰에 대한 정확한 의도를 파악하지 못할 수 있는데 추가 질문을 해도 답변해주실 수 있을까요? 아무래도 직장인분 시간을 뺏을순 없어서 그저 권유일 뿐입니다. :)

YangTaeyoung commented 3 months ago

안녕하세요 :) 1기 팀장으로 있었던 양태영입니다. 이전에는 장고로 개발했었는데, 요즘은 스프링으로 개발하나보네요 :) 주제넘지만, 감회가 새로워서 코드도 볼 겸 현업자 입장에서 리뷰 몇 개 남겨볼테니 한번 고민해보시는 것도 성장에 있어 도움이 많이 될 것 같습니다.

안녕하세요~ 전혀 주제 넘지 않습니다... 안그래도 현재 코드가 어느 부분이 부족한지 알기 쉽지 않아서 고민중이었습니다. 처음 spring으로 개편할때는 태영님이 만드신 장고서버보다 나은 서버를 만들려고 했는데 권한부분이 하도 복잡해서 구현하다가 오히려 삭제한 기능도 꽤 있었고 솔직히 속도나 유지보수 측면에서도 나아졌는지도 잘 모르겠습니다.

spring 코드나 아키텍쳐나 데브옵스 부분(아주 적지만) 어느 부분이든 리뷰 남겨주시면 적극 반영하려 노력하겠습니다. 아직 부족한점이 많아서 리뷰에 대한 정확한 의도를 파악하지 못할 수 있는데 추가 질문을 해도 답변해주실 수 있을까요? 아무래도 직장인분 시간을 뺏을순 없어서 그저 권유일 뿐입니다. :)

네 질문 주셔도 됩니다. 사실 저도 되는 시간에만 답변하니까요 ㅎㅎ

편하게 질문 주시면 저도 편하게 답변 드리도록 하겠습니다. 🤣

꼭 코드 관련 질문 아니더라도 취준이나 이런걸로 어려움 있으시면 연락주세요 :)

public 레포라 연락처를 이곳에 남기긴 좀 그래서 예진이 통해서 전달받으셔서 저에게 연락해주세요 :) (카톡 문자 다 됩니다~)

whitem4rk commented 3 months ago

아마 EC2로 관리하고 계셔서 SSH를 사용하고 계시지 않을까 생각이 듭니다.

도커를 좀 더 제대로 컨테이너 기반으로 배포하고 관리하실 거면 AWS ECS(Elastic Container Service)를 Fargate기반으로 사용해보시는 것도 도움이 될 것 같습니다. (inhabas 정도의 트레픽이면 제일 낮은 스펙으로 배포해도 문제 없습니다.)

이전에 프로젝트 할 때 유사한 조건으로 실제 회사에서 배포하는 시퀀스에 맞게 ECS에 배포 시퀀스를 구축한 경험이 있는데, 만약 ECS통해서 배포하신다면 보시고 도움이 되셨으면 좋을 것같네요 :) (더 좋은 글들도 많으니 찾아보셔도 됩니다.)

프론트 쪽도 AWS Amplify 통해서 배포하면 엄청 쉽게 배포가 가능할텐데, 그건 예진이와 상의해보세요 :) (CSR이 아니라 좀 어려울 수도 있겠네요 허허허)

사실 신입 기준에서도 쉘 스크립트를 이렇게 써서 배포한 것도 매우 잘한 것이니 자부심을 가지셔도 됩니다.

항상 힘내세요 :)

안녕하세요! 태영님. 조언 해주신대로 ECS, ECR을 사용해보려고 하였으나 몇몇 걱정되는 문제가 있어서 질문 남깁니다! 현재는 dev 서버, prod 서버, cloud config 서버, 프로메테우스(예정), grafana(예정), k6(예정) 총 6개의 서버를 ec2 하나에 돌리고 있습니다.

  1. 그런데 만약 ECS를 사용하게되면 6개의 컨테이너를 돌리고 서로 통신해야 하는데 이때 최저사양 Fargate라도 비용이 많이 들진 않을까 걱정입니다.

  2. 만약 비용이 많이 들것으로 예상된다면 ec2에서 컨테이너를 돌리는 이전 방식을 유지해야할 것 같은데 nginx를 활용한 blue/green 무중단 배포를 하면 그나마 안정적인 배포가 될까요?

링크로 주신 글도 읽어봤는데 저와 서버 구조가 조금 달라서 갈피를 좀 못잡고 있는 상황입니다. 비용, 깔끔한 CI/CD, 컨테이너화 모두 챙기고 싶은데 쉽지 않네요... 질문도 막연하고 상황 설명도 부족하지만 지금 상황에선 어떻게 하는게 최선일지 약간의 의견이라도 주실수 있을까요?

YangTaeyoung commented 3 months ago

안녕하세요! 태영님. 조언 해주신대로 ECS, ECR을 사용해보려고 하였으나 몇몇 걱정되는 문제가 있어서 질문 남깁니다! 현재는 dev 서버, prod 서버, cloud config 서버, 프로메테우스(예정), grafana(예정), k6(예정) 총 6개의 서버를 ec2 하나에 돌리고 있습니다.

  1. 그런데 만약 ECS를 사용하게되면 6개의 컨테이너를 돌리고 서로 통신해야 하는데 이때 최저사양 Fargate라도 비용이 많이 들진 않을까 걱정입니다.
  2. 만약 비용이 많이 들것으로 예상된다면 ec2에서 컨테이너를 돌리는 이전 방식을 유지해야할 것 같은데 nginx를 활용한 blue/green 무중단 배포를 하면 그나마 안정적인 배포가 될까요?

링크로 주신 글도 읽어봤는데 저와 서버 구조가 조금 달라서 갈피를 좀 못잡고 있는 상황입니다. 비용, 깔끔한 CI/CD, 컨테이너화 모두 챙기고 싶은데 쉽지 않네요... 질문도 막연하고 상황 설명도 부족하지만 지금 상황에선 어떻게 하는게 최선일지 약간의 의견이라도 주실수 있을까요?

@whitem4rk 깃헙을 최근에 많이 둘러보지 않아서 답이 늦었네요 :) 급하신 거면 그냥 카톡으로 주셔도 됩니다 😄 음.. 제가 알기론 grafana의 경우는 AWS에서 제공하는 서비스를 사용하면 될 거라 그리 문제가 될 것 같진 않고(온프레미스로는 돌릴 필요가 없을 것 같네요), k6는 회사에서 경험했을 때 성능 테스트 용도로 사용했었는데, 별도의 서버를 띄운다는 것이 어떤 용도인지는 모르겠지만, 테스트 할 때 로컬로 한번 돌려보는 수준으로 충분하지 않을까 싶습니다.

먼저 질문 주신 부분에 대한 답변은 아래와 같습니다.

  1. 3개의 서버를 최소사양으로 돌릴 때 경험상 3달러 정도? 하루에 청구될 것 같네요. 약 10만원 정도가 한달에 청구될 예정이니 해당 부분은 참고하셔야 겠죠.
  2. ec2역시 ECS 로 배포하는 방법이 있는 것으로 알고 있습니다. 해당 방식을 찾아보셔서 컨테이너 형식으로 배포하시면 좋을 것 같네요. 사실 nginx 역시 라우팅만 해주는거라, 별도로 머신 안에 띄우기 보단 Elastic Load Balencer를 찾아서 공부해보시면 좋을 것 같습니다. AWS 와 같이 대형 클라우드 서비스 같은 경우 Nginx와 같은 인프라단 작업은 최소화 할 수 있도록 서비스가 나와있는 편입니다. 찾아보면 도입 예도 자세한 편이라 Nginx를 별도로 사용하기 보단 ELB를 사용해서 배포하는 것을 추천합니다.

Cloud Config Server 의 경우 필요하다면 말씀 주신대로 컨테이너를 분리해서 띄우긴 해야하는데요. 질문 드리고 싶은 부분은 왜 도입하려고 하시는 걸까요? 일반적으로 회사에서는 MSA 환경에서 서버를 관리를 좀 더 용이하게 하려고 사용하긴 한데, 사연 주신 부분에서는 기능적으로는 API 서버가 모놀리식인 것 같아서, 굳이 컨피그를 위한 서버를 두어야 할지 의문이긴 합니다. (물론 제가 구성 및 의도를 몰라서 그런걸 수도 있으니 해당 부분은 질문이라고 보시면 될 것 같습니다.)

제가 구성한다면, 2개의 컨테이너(ecs fargate || ecs ec2) 정도는 필수적으로 띄우고 grafana는 AWS 에 등록해서 사용하는 방식으로, 컨피그 서버는 별도로 두지 않고 프로파일만 분리해서 빌드 시 환경변수만 주입하는 방법으로, k6는(제가 아는 k6가 맞나요? 성능 테스트 용도인)로컬에서 테스트 보는 용도로만 사용 할 것 같습니다. Github Action 등으로 배포 시 자동화 할 계획이라면 다른 얘기일 것 같긴 한데, IBAS 구조 상 비용적으로 어렵진 않을 지 우려가 되네요.

사실 현 상태를 이렇게 읽는 것으로는 어떤 부분에서 정확히 문제가 있으신 지 파악은 안돼서, 시간이 되시면 한번 연락주시고 서비스를 한번 설명해주시고, 구성을 함께 고민해봐요. 😄

요즘은 이직해서 주4일제 풀재택이기에.. 시간은 꽤나 널널한 편입니다