[Spring] 도커를 이용한 배포

1. aws를 선택한 이유

처음으로 도커를 이용해서 프로그램을 올리는 과정이었기 때문에, 신생인 ncp 보다는 비교적 참고 자료가 많은 aws를 이용해서 적용해보고자 하였다.

 

2.NLB 말고 ALB를 사용한 이유

Classic Load Balancer는 비효율성 때문에 outdated되었고, GateWay Load Balancer 는 트래픽 체크에 주된 녀석이니,

후보로는 NLB와 ALB가 남았다.

NLB는 7계층 중에서 4계층에 해당하는 layer를 다루는 로드 밸런서 이므로, 속도적 측면에서 ALB보다 성능이 더 빠르다고 할 수 있다.

이에, 대규모 트래픽 상황에서는 NLB가 ALB가 더 적합하다고 판단하였다.

 

하지만, ALB는 계층은 NLB보다 높고, 속도적 측면에서도 NLB가 더 빠르다고 할 수 있다. 하지만, ALB는 요청의 URL 경로나 포트 번호에 따라 특정 서버 그룹으로 요청을 전달하게 할 수 있기 때문에 도커 사용과 잘 맞는다. 추후에 ALB를 직접 도입을 해볼 수 있는 기회가 있다면 NLB를 ALB로 바꾸어서 성능 테스트도 진행해보고 싶다.

 

3. 무중단 배포 방식 중 블루-그린 방식을 이용한 이유

rolling 배포

트래픽을 점진적으로 구버전에서 새로운 버전으로 옮기는 방법

인스턴스를 하나 추가하고 새로운 버전을 실행. 그렇게 서버를 하나하나씩 바꿔나간다.

이는 구버전과 신버전이 동시에 서비스되기 때문에 호환성 문제가 발생할 수 있다.

rolling 배포 방식에 따라 서버의 개수가 일시적으로 줄어들기 때문에 병목현상이 일어날 수 있다.

 

블루-그린 배포

롤링 배포와 달리 한번에 트래픽을 보두 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않는다.

이는 실제 운영에 필요한 리소스 대비 2배 이상을 필요로 한다.

 

카나리 배포

새 버전을 소수의 사용자에게만 배포하고, 안정성과 성능을 검증한다.

초기 검증 단계에서 문제가 없다고 판단되면 전체 사용자에게로 배포 범위를 확대한다.

 

블루-그린은 높은 수준의 안전성을 제공하지만, 동시에 두 환경을 운영해야하기 때문에 비용이 많이들 수 있다.

롤링이나 키나리 같은 경우엔 비용은 더 적게 들지만, 복잡한 트래픽 관리나 롤백 절차를 필요로 한다.

처음 무중단 배포를 적용해보는 만큼, 비교적 쉬운 트래픽 관리를 할 수 있는 블루-그린 배포 방식을 선택하였다.

 

https://hudi.blog/zero-downtime-deployment/

무중단 배포 아키텍처와 배포 전략 (Rolling, Blue/Green, Canary)

 

4. nginx를 선택한 이유 - apache, cloudfront 등 다른 프록시 서버 대신

프록시 서버 : 클라이언트와 서버 사이에 위치하는 중간 서버이다. 사용자의 실제 IP 주소를 숨기고 네트워크 트래픽을 필터링 하여 데이터                        접근 속도를 높일 수 있다.

프록시의 종류 중 reverse proxy를 사용하였다.

ALB가 직접 클라이언트로부터 요청을 받은 후 nginx로 전달하기 때문에, nginx가 역방향 프록시로서 작동한다.

 

[nginx]

장점 : 높은 동시 연결 처리 능력. 리소스 사용률 낮음. 성능 우수. 확장성이 높음. 웹소켓을 지원 -> 추후 대기열 구현에 사용

단점 : Apache와 비교했을 때, 모듈 생태계가 상대적으로 작을 수 있다.

 

[Apache]

장점 : 유연한 모듈 시스템. 설정과 사용의 용이성

단점 : 동시 연결 처리 시, nginx보다 리소스를 더 많이 사용 가능. 높은 트래픽 하에서 nginx나 다른 서버보다 성능이 떨어질 수 있음

 

[Amazon CloudFront]

장점: CDN을 통핸 빠른 콘텐츠 전송. 보안 기능. 통합 AWS 서비스. 보안 기능

단점: 비용. 구성의 복잡성

 

Content Delivery Network : 전 세계에 분산된 서버 네트워크를 활용하여 사용자에게 웹 콘텐츠를 빠르게 전달하는 시스템.

                                               전 세계의 트래픽 분산을 관리하고 특정 서버에 과부하가 걸리는 것을 방지함.

 

이렇게 다 적어보고 나니, Amazon CloudFront도 좋은 선택지가 되었을 수도 있겠다는 생각이 들었다.

aws 기반으로 많은 선택을 하였고, 많은 트래픽 환경에서는 웹 콘텐츠를 빠르게 전달하는 것이 중요하기 때문이다.

 

5. RDS 복제를 해야하는 이유

수강신청 사이트를 만들다 보니, 수강신청 정보에 대한 많은 조회가 일어날 것이고, DB에 대한 쓰기 보다는 조회가 많을 것으로 판단하였기 때문에, 부 DB를 여러개 만드는 것이 효율적일 것이라 생각이 들었다.

 

6. github actions 사용한 이유 - jenkins 대신

두 방식 모두 자동화된 소프트웨어 개발 프로세스를 지원하는 CI/CD 도구이다.

 

[github actions]

장점: github 저장소에 내장되어 있어 별도의 CI/CD 도구를 설정할 필요가 없다.

단점: 비용 + 한정된 자원 : 실행 시간이나 동시 실행에 제한이 있을 수 있다.

 

[Jenkins]

장점: 강력한 유연성과 확장성. 많은 플러그인을 통해 거의 모든 종류의 CI/CD 요구 사항을 충족할 수 있다.

단점: jenkins 서버를 설정하고 유지 관리하는 데 많은 시간과 노력이 필요. 많은 컴퓨팅 자원을 소비할 수 있다.

 

github를 기본적으로 공유 사이트로 이용하고 있는 만큼, 자연스럽게 github actions를 사용하게 되었다.

 

7. http와 https의 차이

- http: 암호화되지 않은 평문 데이터 이용. 보안 취약점이 있음. 80번 포트 이용

- https : 클라이언트와 서버 사이의 모든 통신을 암호화. https는 데이터를 암호화하면서 중간자 공격으로부터 데이터를 보호.

               443번 포트 이용.

 

8. docker를 사용한 이유. (compose)

docker를 사용해서 개발, 테스트, 운영 환경에서의 차이를 최소화하여 애플리케이션을 일관되게 실행할 수 있음. docker 이미지를 사용해서 애플리케이션과 환경을 패키징하면 다른 개발자도 다른 환경에서 쉽게 재사용하고 공유할 수 있다.

docker compose: .yml 파일을 사용해서 애플리케이션의 모든 구성 요소를 정의할 수 있음. 복잡한 애플리케이션을 쉽게 구성하고 테스트할 수 있게 해줌.

 

9. 트러블 슈팅 내용

nginx에서 도커로의 연결이 되지 않았다.

 

nginx.conf 파일의 server 172.20.0.2:8081 에서 localhost:8081로 바꾸었다.

    upstream quokkax2-server {
        least_conn;
        server 172.20.0.2:8081 max_fails=3 fail_timeout=30s;
        server localhost:8082 max_fails=3 fail_timeout=30s;
    }

 

172.20.0.2 ( 루프백 인터페이스 )는 컴퓨터 네트워킹에서 시스템 내부 통신을 위해 사용되는 가상 네트워크 인터페이스이다. 즉 루프백 인터페이스를 위해 예약된 주소이다.

 

루프백 인터페이스는 자가 통신이 가능하다. 또한 네트워크 독립성으로, 내부적인 네트워크 서비스를 테스트 하기 용이하다.

 

172.20.0.2는 컨테이너에 할당된 내부 IP 주소였다. 이 주소는 docker 생성한 가상 네트워크 내에서만 접근 하능하고, docker 네트워크 밖에서는 직접 접근할 수 없다. 즉, 주로 컨테이너 간의 통신이나 docker 호스트에서 해당 컨테이너로의 접근에 사용될 수 있다.

 

localhost는 로컬에서 실행 중인 서비스에 접근할 수 있다. 이는 로컬 컴퓨터에서 리스닝 중인 포트로의 접근을 의미한다.

 

docker 호스트에서 포트 8081로 들어오는 모든 트래픽이 docker가 설정한 포워딩 규칙에 따라 특정 컨테이너의 8080 포트로 리디렉션된다. 이는 docker가 호스트의 포트와 컨테이너의 포트 사이에 네트워크 브릿지를 형성하기 때문에 가능함.

 

10. 데이터베이스 종류

noSQL = 비관계형 DB 데이터형식만 저장 가능

단순한 형태의 데이터저장 특화

장점 : 속도빠름, 단순한 DB설계에 특화

단점 : 복잡한 데이터관계 구현 어려움

 

mySQL = 순수 관계형 DB 데이터형식만 저장 가능 데이터간의 관계를 넣을 수 있음

장점 : 복잡한 데이터관계를 설계 할 수 있음

단점 : 상대적으로 느림

 

postgreSQL = 객체 관계형 DB 다양한 형식의 데이터 저장 가능 (ex, 함수, 인덱스, list 등 컨테이너 자료형)

장점 : 속도가 빠름, 복잡한 DB 설계 가능

단점 : 러닝커브, vacuum작업 필요

 

관계형 데이터를 다루고 있기 때문에 noSQL로는 구현의 어려움이 있음을 느껴서 mysql와 postgreSQL 둘 중 하나를 선택해야 했고 MySQL은 읽기 작업에 특화되어 있어, 데이터 조회에 있어 뛰어난 효율성을 보여줌

 

반면 PostgreSQL은 데이터를 주기적으로 정리해야 하는 vacuum 작업이 필요한 등, 관리 측면 및 러닝커브에 있어서 약간의 부담이 있어 MySQL을 선택 하게 되었음.