티스토리 뷰
기존 배포 환경의 문제점
기존에는 빌드/배포 자동화를 위해서 Github Action에 Self-hosted Runner를 사용했습니다
하지만 Self-hosted Runner를 사용하면서 여러 불편한점이 있었습니다.
환경 변수 관리 문제
첫 번째로, 환경 변수의 관리가 어려웠으며, 어떤 값이 설정되었는지 알기 힘들었습니다.
단일 장애 지점(SPOF) 발생
두 번째로, 러너를 배포하기 위해 서버에 직접 설치해야 했는데, 이는 러너에 문제가 발생할 경우 단일 장애 지점(SPOF)으로 이어질 수 있습니다.
실제로 배포중에 메모리가 부족해서 서버가 다운되는 경우가 종종 있어서 가상 메모리를 추가했었습니다.
예상 치 못한 문제
추가적으로, 러너가 종료될 때 고아 프로세스들이 함께 종료되어서 서버가 다운되는 문제가 발생했습니다.(https://github.com/actions/runner/issues/598)
CodePipeline
CodeCommit, CodeBuild, CodeDeploy를 하나의 프로세스로 통합시켜주는 CI/CD 도구이다.
CodePipline을 활용하면 위와 같은 불편함을 해결할 수 있다.
CodeBuild
CodeBuild를 활용해서 Build & Test를 수행할 수 있습니다.
별로의 클라우드 환경에서 Build가 수행되기 때문에 실제로 서비스가 배포된 서버에 영향을 주지 않습니다.
즉 단일 장애 지점(SPOF) 문제가 발생하지 않습니다.
Elastic Beanstalk
Elastic Beanstalk을 활용하면 간편하게 앱을 AWS를 통해 배포할 수 있습니다.
오토 스케일링, 로드 밸런싱 등을 손쉽게 설정 할 수 있습니다.
그리고 환경변수 관리도 쉽게 할 수 있습니다.
기본적으로 http 환경으로 배포가 되는데 https 설정을 위해서는 로드밸런서가 필요합니다.
(https://repost.aws/ko/knowledge-center/elastic-beanstalk-https-configuration)
마무리
배포 환경을 CodePipeline 로 변경하면서 기존 배포 환경에서 발생하던 문제점을 해결했습니다.
하지만 Elastic Beanstalk의 경우 서비스에서 제공해주는 기능이 많다보니깐 학습 비용이 많이 발생했는데
시간이 있을때 CodeDeploy를 활용해보고 싶습니다.
- Total
- Today
- Yesterday
- BasicBinder
- 유저 시나리오
- dto 위치
- CreatedDate
- 레이어드 아키텍처
- 구글 OpenID
- setDateFormat
- FormProperty
- JPA SQL Injection
- @FormProperty
- @ElementCollection
- Attribute Converter
- ServletContainerInitializer
- java 17
- DispatcherServletInitializer
- 유저 스토리
- defer-datasource-initialization
- HTTPInterface
- WebFlux 의존성
- dto 검증
- feignClient
- @Converter
- ValidateException
- User Scenario
- HandlesTypes
- org.springframework:spring-webflux
- Spring Boot 3
- entity 검증
- 구글 소셜로그인
- CreationTimestamp
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |