🗃 ELB를 통해 HTTPS 설정하기

💬 ELB(Elastic Load Balacer)란?

트래픽을 적절하게 분배해주는 장치를 말한다

트래픽이 많아지고 그에 따라 만약 서버를 증설하게 된다면 서버가 증설한 만큼 각 서비스에 균일하게 요청이 분산되거나 특정 서비스로 가야하는 요청인 경우는 정확히 가야하는데 이를 관리해주는 것이다

 

근데 이번 블로그에서 다룰 내용은 실제로 서버를 증설해서 각 서비스에 전달하는 것이 아니라 HTTPS를 적용시키기 위해 등록하는 것이기 때문에 실제로 요청을 균등하게 분배하는 것은 확인하기 어렵다

 

💬 HTTPS

HTTP는 데이터를 전송할때 모든 데이터가 노출되기 때문에 보안적으로 굉장히 취약하다. 그래서 데이터를 암호화하기 위해 SSL/TLS 기능을 활용하는 HTTPS로 통신하도록 만들어볼 것이다.

 

• HTTPS를 도입하는 정확한 이유
  • 보안적인 이유
    데이터를 서버와 주고 받을 때 암호화를 시켜서 통신을 한다. 암호화를 하지 않으면 누군가 중간에서 데이터를 가로채고 해킹의 위험이 있기때문에 보안에 좋지 않다.
  • 사용자 이탈
    사용자가 나의 서비스에 들어왔는데 HTTP인 상황을 보고 데이터가 안전하지 않다는 것을 알았다. 그렇다면 여기에 나의 정보를 입력하는 것 자체를 꺼리게 된다. 

그래서 대부분 HTTPS를 도입하고 사용한다. HTTPS 인증을 받은 웹사이트가 백엔드 서버와 통신을 하기 위해 백엔드 서버의 주소도 HTTPS 인증을 받아야한다. 따라서 백엔드 서버와 통신을 할때에도 IP주소로 하는 것이 아닌 HTTPS 인증을 받은 도메인 주소로 통신을 해야한다.

 

💬 ELB 셋팅

1. 로드밸런서 생성

EC2 에서 시작한다. EC2의 왼쪽에 많은 탭을 내리다보면 로드밸런서 라는 것이 나온다 해당 이미지를 클릭하면 된다

• EC2에서 시작하고 왼쪽에 많은 탭들을 내리다보면 로드밸런서가 나온다
• 로드 밸런서 생성하기를 클릭

2. 유형 선택

Application Load Balancer를 선택해주면 된다. 설명을 읽어보면 알겠지만 HTTPS에 관한 이야기가 나온다.

• Application Load Balancer : HTTP/HTTPS 트래픽을 대상으로 하는 7계층 로드 밸런서이다. 애플리케이션 레벨에서 라우팅을 처리하고 여러 가용 영역에 걸쳐 로드 밸런싱을 수행한다
• Network Load Balancer : TCP/UDP 트래픽을 대상으로 하는 4계층 로드 밸런서이다. 높은 처리량과 낮은 지연시간을 제공하고 여러 가용 영역을 지원한다
• Classic Load Balancer : 이전 세대의 로드 밸런서로 4계층과 7계층 모두를 지원한다.

 

3. 기본 구성

• 인터넷 경계와 내부라는 옵션이 있다. 내부 옵션은 Private IP를 활용할 때 사용한다. 입문 강의에서는 VPC, Private IP에 대한 이야기를 따로 하지 않기 떄문에 인터넷 경계 옵션을 선택하는 것이 좋다.
• IPv4와 듀얼스택이라는 옵션이 있다. IPv6를 사용하는 EC2 인스턴스가 없다면 IPv4를 선택하면 된다

4. 네트워크 매핑

로드 밸런서가 어떤 가용 영역으로만 트래픽을 보낼 것인가에 제한을 하는 기능이다. 

• 로드 밸런서의 가용영역
  • 여러 데이터 센터에 걸쳐 분산된 물리적 위치를 의미한다. 만약 한곳의 가용 영역 자체에 문제가 발생하면 서비스 자체가 무너져내릴수 있지만 4개에 분산시켜 놓는다면 혹여 문제가 발생해도 다른 곳에서 우선 처리가 가능하다.

5. 보안 그룹 설정

EC2를 할때 보안 그룹에 대한 이야기를 한 적이 있는데 이는 별개의 문제다. 때문에 다시 한번 상기할 필요가 있다

EC2의 보안 그룹 탭으로 가서 보안그룹을 새로 만든다

규칙을 정하는 것은 elb의 보디가드 인것이다.

• ELB에 SSH(22)가 없는 이유는 직접 접속하지 않기 때문이다. 우리가 직접 ELB에 들어가서 뭔가를 할 조작을 할 필요가 없기 때문에 상관이 없다. 때문에 우리는 키페어도 사용하고 있지 않는것을 보면 알 수 있다
• ELB는 HTTPS를 지원하기 때문에 HTTPS(443)까지 지정해주는 것을 볼 수 있다.

그리고 다시 돌아와서 새로고침을 하고 보면 설정한 보안 그룹이 있는 것을 확인 할 수 있다. 이것을 눌러주면 된다

 

여기서 중요점
EC2 와 ELB는 다르다. 때문에 우리는 각각의 서버에 보디가드를 붙여주는 것이다. 이것을 잘 알아야한다.

 

6. 리스너 및 라우팅

ELB의 성격은 들어오는 요청을 어떤 EC2에게 전달할지 정하는 역할이라고 말했었다. 그것을 설정하는 곳이 바로 이곳이다

여기서 대상 그룹이라는 말이 나오는데 이게 뭐냐면 요청을 "어떤 곳" 으로 보내야 하는데 그 어떤 곳을 대상 그룹이라고 표현한다. 

 

대상 그룹 설정하기

1. 인스턴스로 보낼것이기 때문에 인스턴스를 클릭한다

2. ELB가 사용자로부터 요청을 받아 대상 그룹에게 어떤 방식으로 전달을 할지 설정하는 부분이다. 위에 설정대로 한다면 HTTP/1.1 방식으로 80번포트로 IPv4 주소 방식으로 전달하겠다. 라는 뜻이다 가장 흔하게 볼 수 있는 셋팅이다.

3. 상태검사(Health Check)

그 다음으로 상태 검사라는 것이 있다. 상태를 검사 즉, 서버의 상태를 검사하는 것은 ELB의 아주 중요한 역할이기도 하다. 때문에 좀 더 확실하게 짚고 넘어가려 한다

 

실제 ELB로 들어온 요청을 대상 그룹에 있는 여러 EC2 인스턴스로 전달하는 역할을 가진다. 그런데 만약 특정 EC2 인스턴스 내에 있는 서버가 예상치 못한 에러가 발생하면서 아예 고장이 나버렸다. 그럼 ELB입장에서는 고장난 서버에게 요청을 전달하는게 비효율적인 행동인 것이다

 

이렇게 비효율적인 행동을 방지하기 위해 ELB는 주기적으로 대상 그룹에 속해있는 각각의 EC2 인스턴스에 요청을 보낸다. 그 요청에 대한 200번대 응답이 잘 날아온다면 서버가 정상적으로 잘 작동되고 있다고 판단하고 만약 요청을 보냈는데 200번의 응답이 날아오지 않는다면 그때 서버가 고장났다고 판단한다. ELB가 고장났다고 판단하면 그 이후로 해당 EC2 인스턴스에게는 요청을 보내지 않는다

 

하지만 자체적으로 뭔가 할 수 있는 방법은 없고 서버단에 Health Check를 할 수 있는 API가 필요하다.

위에 접힌 글을 진행하면 이렇게 대상 그룹이이 등록된 것을 볼 수 있다. 그럼 이제 대상 그룹을 생성하면 대상 그룹을 등록할 수 있게 된것이다

이렇게 돌아와서 새로고침을 하면 만들었던 대상 그룹이 생성된 것을 볼 수있다

HTTP를 활용해서 80번 포트로 요청이 들어오면 설정한 대상 그룹에게 요청을 전달하겠다

라는 의미로 사용된다. 대상 그룹에 성질을 생각해보면 요청을 전달할때 HTTP, 80번 포트, IPv4상태로 전달하겠다는 것도 있지 말아야한다.

 

이를 마지막으로 로드밸런서를 생성해주면 된다.

 

7. Health check하기 위한 API가 있는 레파지토리가 필요하다

GitHub - Tedeeeee/practice_AWS

이곳에 들어가면 Spring Boot를 통해서 간단하게 테스트 해볼수 있게 만들었다. 이거 clone하면 된다

clone을 한다는 것은 기존에 EC2에 떠있는 것이 아닌 새로운 것을 가져와야 한다는 것이다. 물론 원래 기존에 있는 것에 vim이나 nano같은 것으로 코드를 추가시키고 재빌드하여 사용해도 좋다.

 

8. 로드 밸런서가 잘 작동하고 있는지 확인해보자

만약 생성하기를 누르고 EC2를 수정하고 왔다면 시간이 충분했겠지만 처음에 로드밸런서를 만들면 프로시저닝중이라고 뜨면서 3~5분정도 기다려야한다. 물론 그동안은 사용이 불가능 하다.

 

상태가 활성화가 되면 DNS이름을 가지고 테스트를 해보자

• 기본적인 DNS확인

• health_check

아주 잘 작동하는 것을 확인 할 수 있다.

 

8. 로드 밸런서와 ACM 등록하기

내가 만든 도메인은 위에서부터 봐왔다면 Route 53에서 만든것이 아니라는 것을 알 수 있다. 그래서 내도메인.한국을 통해 제작했는데 강의에는 그 내용이 없어서 꽤 애먹었다. 하지만 빛과같은 블로그를 작성하신 분 덕분에 해결 할 수 있었다

[Infra] Spring + EB + Github Actions + Docker + ACM을 통한 CI/CD 자동화 및 https 적용 방법 (feat. 내도메인 한국

내가 설명하는 것 보다 이분이 설명을 너무 잘해주셔서 이분 블로그를 보면 된다

 

9. 리스너 추가 설정하기

EC2에 로드밸런서를 들어가서 리스너를 추가 시켜주어야 한다 그럼 이런 화면이 뜬다.

• HTTPS를 통해 443번 포트로 요청이 들어온다면 그 요청에 대해 대상 그룹에게 요청을 전달해주겠다 라는 뜻이다
• 대상 그룹은 아까 만든 대상 그룹을 선택한다

• 정책은 권장하는 내용으로 만든다
• ACM은 아까 받은 ACM을 사용하면 된다.

이것을 마지막으로 추가하면 적용이 된것을 확인할 수 있다

HTTPS가 잘 연결이 되었다면 이 연결은 안전합니다. 라고 뜨는 것을 확인 할 수 있다.

 

10. 리스너 규칙(80) 삭제하기

 그렇다면 이로써 완전히 마무리가 된 것일까? 아니다. 안타깝게도 아직 아니다. 왜냐하면 http의 요청도 아직 처리하는 것을 볼 수 있기 때문이다.

때문에 우리는 http의 요청이 들어오면 자동으로 https로 리다이렉트하여 요청이 들어오게끔 만들어주면 된다.

이정도는 굳이 사진으로 남기지 않아도 된다고 생각한다

1. 우선 리스너(80)를 삭제해준다
2. 다시 리스너를 추가하고 대상 그룹으로 전달하는 것이 아닌 URL로 리디렉션 이라는 라디오 버튼을 누른다

이렇게 하면 사용자가 만약 http로 요청을 하면 자연스럽게 https로 다시 요청이 가는 것을 확인 할 수 있다.

 

만약 안된다면 잠시만 더 기다려보자

 

💢 HTTPS 를 사용할때 ELB는 뭐고 NginX, Certbot 이건 다 뭘까?

나는 앞서서 Route 53을 사용하지 않기때문에 HTTPS를 적용하려면 어떻게 해야하는지 한참을 찾았다. 덕분에 아주 좋은 블로그님을 찾아서 너무 다행이죠...

 

어쩄든 찾다보니 NginX를 어떻게 하고, Certbot을 사용하고 등등 많은 해결책이 있기도 하다

근데 왜 나는 ELB를 사용하고 있는 걸까?

 

답은 사실 간단하다. 잠깐만 찾아봐도 알겠지만 설정이 비교적 매우매우 편리하고 인증서의 만료기간도 자동으로 갱신을 해주기 때문이다.

 

그렇다면 왜 사용하는걸까? 전부다 ELB쓰면 되지?

바로 "비용" 때문이다.

위의 두개를 사용하면 HTTPS를 적용하는데 드는 비용은 0이다. 반면 ELB는 사용을 하는 것만으로도 비용이 발생한다. 따라서 학생이나 테스트, 이러한 경우에는 ELB대신 NginX, Certbot을 사용하는 경우도 굉장히 많다

 

그렇다면 두개는 어떻게 사용하는 걸까? 한번 알아보자 단! 이미 블로그가 너무 길어졌기 때문에 다음 블로그에서 알아보도록 하자

🗃 HTTPS 설정하는 방법 NginX, Certbot