논리 서버가 여러 개 필요한데 물리 서버(EC2 인스턴스)를 여러 개 만들 돈이 없다면 EC2 대신 Lightsail을 사용하고 서버 구성에 nginx 를 사용해서 더 깔끔하고 확장성있게 요구사항을 만족시킬 수 있습니다.
아래 게시글은 '옛날엔 이런 방법도 쓴 사람이 있구나', 정도로만 읽어주세요.

서버는 여러 개가 필요한데 인스턴스를 여러 개를 만들 돈이 없을 때 유용한 방법이다.
접속량에 따라 추가 비용이 들 수는 있다.

이번 글에서는 AWS의 EC2, Route53 서비스만을 이용하여 제목에 적어놓은 일을 수행하는 방법을 알아본다.

정확히 할 일을 정의해보자면 하나의 EC2 인스턴스에 포트를 다르게 하여 여러 개의 서버를 열고, 각 서버에 서로 다른 도메인이나 서브도메인을 연결할 것이다.

이 방법의 경우 만든 하나의 EC2 인스턴스로 접속이 몰려서 서버가 느려지거나 최악의 경우 다운되는 일도 발생할 수 있으나,... 나같이 그냥 접속량도 별로 없는 개인 웹서버를 운영할 계획이라면 괜찮게 먹힐 것이다.
그럴 일은 없겠지만 나중에 유명해져서 접속량이 늘어난다면 그 때 인스턴스를 하나 더 파던지 하면 된다.

이 방법을 쓰면 메인 서버가 다운되었을 때 옆에 있는 다른 인스턴스로 요청을 전달해서 '현재 메인 서버가 다운되었거나 점검중이에요!'같은 메시지를 응답해 수도 있다.

우선 EC2에 탄력적 IP 설정이 완료되었으며 두 개의 서버가 각각 N, M 포트로 열려있고 각각 main.io와 sub.main.io로 연결한다고 가정한다.
과정을 진행할 때 N, M, main.io, sub.main.io가 보이면 각자가 사용하고있는 포트와 도메인으로 변경하면 된다.

다음과 같은 과정을 진행한다:

1. EC2 콘솔의 로드밸런서 탭으로 이동한다

2. LoadBalancer 생성을 클릭하고 Classic Loadbalancer를 선택한다

3. 1단계 과정이다. LoadBalancer 이름은 to-main으로 입력한다. 어떤 포트로 연결될지, 해당 포트가 어떤 서버인지를 구별할 수 있도록 하자.

4. LoadBalancer 프로토콜은 적당히 HTTP와 HTTPS(이 경우에는 ACM 인증서가 필요하다)로 설정한다. 포트는 건드리지 않는다.

5. Instance 프로토콜은 LoadBalancer 프로토콜과 동일하게 설정하되 백엔드에서 HTTPS를 구현한게 아닐 경우 HTTP로만 구성한다

6. Instance 포트는 N을 설정한 프로토콜 칸에 입력한다

7. 1단계 설정을 끝낸 예시는 다음과 같다(N=6402일 때):

8. 2단계 과정이다. 보안 그룹은 새로 만들기로 선택하여 기본값을 쓰도록 놔두고, 설명만 모두 영어로 바꾼다(한글이 적혀있다면)

9. 3단계 과정이다. 1단계의 Loadbalancer 프로토콜에서 HTTPS를 구성한 경우 인증서가 필요하다. 푸른 박스 안의 'ACM으로부터 새 인증서 요청'을 클릭한다.

10. 새 창이 열린다. 가지고있는 메인 도메인을 입력하고 인증서를 발급받는다.

11. Loadbalancer 생성 창으로 돌아와서 방금전에 만든 인증서를 선택한다. 나머지는 기본설정으로 두고 다음으로 넘어간다.

12. 4단계 과정이다. Loadbalancer가 원래 접속하려는 서버가 멀쩡한지 확인하고 그렇지 않다면 다른 곳으로 우회시켜주는 서비스이기 때문에 서버가 멀쩡한지 확인할 방법을 지정해줘야한다. 필자의 경우 따로 특정 node 라우터로 접속할 시 코드 200을 응답하도록 해놓았는데, 그게 귀찮다면 그냥 사이트 메인 페이지의 라우팅 경로를 넣어줘도 무방하다. 포트는 6번 과정에서 설정한 포트로 입력하고 넘어간다.

13. 5단계 과정에서는 웹 서버 인스턴스를 로드밸런서에 추가한다 깨알같은 마크 서버는 무시하고 넘어가자

14. 6단계 과정에서 태그는 필요하면 넣고 그렇지 않다면 그냥 넘어간다

15. 7단계 과정에서 설정이 맞는지 검토하고 로드밸런서를 최종적으로 생성한다

16. 생성이 완료되었다면 하나 더 만들어야하니 3번 과정으로 돌아간다. 돌아가서 진행할 때 로드밸런서 이름(1단계, 4번 과정)을 to-sub로 입력하고 Instance 포트(1단계, 6번 과정)와 상태 체크 포트(4단계, 13번 과정)만 M으로 입력해주면 된다. 이미 두 개의 로드밸런서가 만들어져 있다면 다음 과정을 진행한다.

17. 현재 상황을 정리해보면 다음과 같다:

    1. 두 개의 로드밸런서가 있다
    2. 한 개의 로드밸런서는 80번 포트로 들어오는 HTTP 프로토콜로 된 요청과 443번 포트로 들어오는 HTTPS 프로토콜로 된 요청을 N번 포트로 HTTP 프로토콜을 사용해 전달하고 있다.
    3. 나머지 한 개의 로드밸런서는 80번 포트로 들어오는 HTTP 프로토콜로 된 요청과 443번 포트로 들어오는 HTTPS 프로토콜로 된 요청을 M번 포트로 HTTP 프로토콜을 사용해 전달하고 있다.

18. 이제 로드밸런서를 도메인과 연결해줘야한다. Route53 콘솔로 이동하여 호스팅 영역 탭을 연다.

19. main.io를 선택하여 레코드 리스트 화면으로 넘어간다

20. 레코드 리스트에서 main.io의 A레코드의 값을 수정한다. 없다면 마법사 모드로 레코드 추가에 진입한 다음 단순 라우팅으로 추가한다.

21. '값/트래픽 라우팅 대상'의 첫번째 드롭다운을 'Application/ClassicLoadbalancer에 대한 별칭'을 선택한다.

22. 지역은 EC2 콘솔 오른쪽 위에 보이는 지역으로 추가한다. 지금 진행 중인 창을 닫지 말고 새 탭을 열어서 콘솔로 이동하면 쉽게 확인이 가능하다.

23. 값은 드롭다운에서 to-main이 포함된 것으로 선택한다. 정확히 to-main은 아닐 것이고 아마 어쩌구저쩌구.to-main-어쩌구저쩌구 일 것이다.

24. 저장하고 호스팅 영역 레코드 리스트 화면으로 돌아온다.

25. 20번 과정으로 돌아간다. 이번에는 sub.main.io를 선택하고 로드밸런서를 to-sub를 선택하여 수정한다.

26. 이제 마지막으로 기다리는 일만 남았다. 생성한 로드밸런서 중 아무거나 하나의 왼쪽 체크박스를 클릭하여 상세정보창을 띄운다.

27. 인스턴스 탭을 클릭하고 리스트에 뜨는 인스턴스의 상태를 확인하여 InService가 될때까지 기다린다(처음에는 OutOfService일 수 있다). 상태체크에 실패하지 않는다면 대략 3~5분 정도가 걸리니 그 시간이 지나고 새로고침을 해보자. 혹시 이 시간이 지나도 InService가 되지 않는다면 상태 체크에 문제가 생겼을 가능성이 높으므로 메인 페이지 혹은 상태체크 설정에서 세팅한 링크로 200코드가 응답으로 잘 돌아오는지 확인하자.

28. InService가 되었다면 각 도메인으로 접속하여 원하는 페이지가 잘 나오는지 확인한다

조금 길고 복잡한 과정이지만 특별히 알아야할 지식은 로드밸런서가 뭐하는 놈인지 정도 뿐이라 어렵지는 않았던 것 같다.

이 방법의 단점이라면 서버 코드가 변경되어 서버를 다시 시작할 때 껐다가 다시 켤때까지의 시간이 오래걸리면 로드밸런서가 이 서버는 죽었다고 판단하고 한동안 이 서버로 요청을 보내지 않는다는 점이다.
이게 문제가 되는 이유는 로드밸런서에 단 하나의 인스턴스만 연결했기 때문인데, 이 경우에서는 이렇게 되면 서버를 다시 켰더라도 5~10분동안 아예 접속이 되지 않는 현상이 발생한다.
그러니 코드를 업데이트할때는 최대한 빠르게 해줘야한다는 것이 단점일 수 있겠다.

물론 하나의 인스턴스를 더 만들어서 점검중 메시지를 전송하는 웹서버를 하나 더 판다면 모르겠지만 그러면 포스트 첫머리에서 말했던 'EC2 인스턴스 하나 더 팔 돈이 없을 때'라는 조건과 맞지 않으므로 넘어가자.

비용에 관해서는 사실 잘 모르겠는데 접속량이 적으면 로드밸런서에서는 딱히 추가 비용을 청구하지는 않는 것 같다.
단, 인스턴스를 꺼두고 로드밸런서만 연결해두면 추가요금이 나오는 것으로 확인되는 것 같다.
그걸 제외하면 EC2 비용만 내면 되는 것 같은데...잘은 모르겠다.