개인 프로젝트로 만든 사이트에 도메인을 입혀주고, https를 적용하는 과정을 기록합니다.
- 가비아에서 도메인을 구입해줍니다.
- Route 53에 호스팅 영역을 생성합니다
- Route 53 생성후, 레코드의 NS값 4개를 가비아의 네임서버 값으로 넣어줍니다
- Certificate Manager에서 SSL 인증서를 받습니다
- Route53에 SSL레코드를 등록합니다(CNAME)
- ALB를 생성해줍니다.
- 이때, 리스너를 HTTP 80 / HTTPS 443으로 추가해줍니다. 리스너의 타겟은 현재 서버가 돌아가는 EC2인스턴스의 80포트입니다.
- 또, HTTP 80과 HTTPS 443의 인바운드를 허용한 새로운 보안그룹을 생성합니다(기존 ec2의 보안그룹에 해당 인바운드 추가도 가능). 이 보안 그룹을 로드밸런서의 보안그룹으로 지정합니다.
- Route53에 ALB에 대한 레코드를 생성합니다. 유형은 A이고, 별칭(alias)를 선택하여서 방금 생성한 ALB를 지정합니다.
간단한 과정이지만, 저를 계속 괴롭혔던 것은 7번입니다. 원래는 타겟을 http 80, https 443 두가지로 설정해줘서 각각 리스너에 따라 다르게 두었습니다.
그러나 ec2-publicIP-dns에 http 80또는 https 443으로 접근할 수 없었기 때문에 계속해서 health check를 실패했습니다.
두가지를 실수했던 것입니다.
1. ec2상의 서버가 타겟이 되는 서버를 listen하지 않음
2. ALB를 사용할 시, 클라이언트와의 HTTPS통신은 ALB가 담당하므로, EC2 인스턴스는 평문 통신만 하면 된다는 것을 몰랐음
2번에 대해서 먼저 얘기해보겠습니다.
로드 밸런서에 대한 이해가 필요합니다,
로드 밸런서는, load + balancer : 말 뜻 그대로 쏟아지는 트래픽을 여러 대의 서버로 분산하는 기능을 합니다.
같은 기능의 서버를 증설(scale-out)할때, 로드 밸런서를 활용하여 요청을 분산합니다.
애플리케이션 사용 요청이 들어오면, 이는 로드밸런서를 거친 후, 서버 팜의 단일 서버로 라우팅 됩니다.
로드밸런서는 또한, HTTP헤더나 SSL 세션 ID 같은 요청의 정보를 확인하여서 트래픽을 적절한 대상으로 라우팅합니다.
ALB(Application Load Balancer)는 OSI 계층의 최상위인 애플리케이션 레이어를 다루는 로드밸런서입니다.
이때 우선순위를 가지는 "규칙"들을 설정하여 요청을 분산합니다. 이 규칙은 헤더, 요청 메서드 등 HTTP의 특징을 활용하여 짜여집니다.
이 ALB에는 SSL 인증서를 탑재할 수 있습니다.
사용자와 서버가 직접 HTTPS를 이용하여 암호화 통신을 하려할 경우,
- SSL 인증서로 인증
- SSL Handshake
의 과정을 거쳐야 하는데, 이는 서버에 부담이 됩니다.
따라서 이 과정을 ALB가 대신하여서 SSL 인증서를 활용해서 사용자와 암호화 통신을 실시합니다.
이를 위해 Certficate Manger에서 SSL 인증서를 발급받는 것이죠.
앞서 말했듯이, HTTPS 리스너를 추가할 시 해당 SSL인증서를 사용합니다.
이때, 타겟의 EC2 인스턴스 포트는 443으로 둘 필요 없이 '80'으로 두면 됩니다. HTTPS 통신은 ALB가 담당하기에, EC2인스턴스는 HTTPS 통신을 할 필요가 없다는 것입니다.
SSL Termination(SSL로 암호화된 데이터가 해독(오프로드) 되는 프로세스)를 ALB에서 담당하고, ec2와는 일반적인 통신을 진행하면 됩니다.
문제는, 제가 HTTPS리스너의 타겟을 인스턴스의 443포트로 설정해주었다는 것입니다.
별 생각없이, HTTPS 리스너니까 443 포트로 연결해주면 되는 줄 알았습니다. 문제는 제 인스턴스는 HTTPS 통신이 불가능하다는 것입니다.
Certifiate Manager에서 발급한 SSL인증서는 ALB등 AWS 인프라 위에서 사용하기 위한 용도이기때문에, 이것의 private 키를 다운로드 받을 수 없고, 서버에서 직접적으로 사용할 수가 없습니다.
따라서 서버는 직접적으로 https통신을 감당할 준비가 되지 않은 상태입니다.
그래서 443포트를 타겟으로 두어도 https 443으로 접근할 수 없었던 것이죠.
~1024포트를 루트가 아니면 사용할 수 없게 둔 리눅스 특성상, 서버를 8443에서도 열어보고, 루트로 443에서도 열어봤지만, 결론은 결국 현재는 443 https통신이 불가능하다는 것이었습니다.
1번의 경우, 포트를 열어두더라도, 해당 포트를 listen하고 있는 프로세스가 없다면 요청이 전달될 수 없습니다. 따라서, 타겟이 되는 80포트로 스프링 부트 서버를 열어주었어야만 했던 것입니다.
