[AWS] openVidu(ver3) + ec2(t2.micro) 배포 실패 및 성공기

openvidu를 배포하기 위해서는 생태계 이해가 필요하다

대충 내가 이해한것은


backend에서 livekit 관련 설정을 알고 있고 해당 설정을 이용해서 Token을 만들 수 있다.

frontend에서 openvidu에 접근하기 위해 token이 있어야하는데 이를 backend 서버에 요청한다.


fontend -> backend -> frontend -> openvidu 순이다.


openvidu를 배포하기 위해서는 공식문서에서는 2가지 방식을 제공하고 있다.

On-premises Installation: Set up OpenVidu Single Node on your own servers.

AWS Installation: Deploy OpenVidu Single Node on Amazon Web Services.


두 가지 방법인데, 우선 나는 AWS installation을 활용해봤다. 

해당 방법은 aws의 cloudFormation을 활용해서 서버를 구축하는 방식을 설명한다.

요약하자면 
---

### OpenVidu Single Node 설치 요약: AWS


**호환성:**

- OpenVidu Single Node는 OpenVidu v2 API와 호환되지 않습니다.

- v2 호환성을 위해서는 OpenVidu Elastic 또는 OpenVidu High Availability를 사용해야 합니다.


**배포 단계:**

1. **AWS CloudFormation 템플릿:**

   - AWS CloudFormation 콘솔에서 템플릿을 가져옵니다.

   - 템플릿 URL: [AWS CloudFormation 템플릿](https://s3.eu-west-1.amazonaws.com/get.openvidu.io/community/singlenode/latest/aws/cf-openvidu-singlenode.yaml)


2. **CloudFormation 매개변수:**

   - **도메인 및 SSL 인증서 구성:**

     - 옵션: Let's Encrypt 인증서(권장), Self-Signed 인증서, Custom 인증서.

     - FQDN(정식 도메인 이름) 및 Elastic IP가 필요합니다.

     - 매개변수: `DomainName`, `PublicElasticIP`, `LetsEncryptEmail`.


   - **EC2 인스턴스 구성:**

     - 매개변수: `InstanceType`, `KeyName`, `AmiId` (기본값은 최신 LTS Ubuntu AMI).


   - **선택적 TURN 서버 구성:**

     - 제한된 방화벽에 유용합니다.

     - 매개변수: `TurnDomainName`, `TurnOwnPublicCertificate`, `TurnOwnPrivateCertificate`.


3. **스택 배포:**

   - CloudFormation 매개변수를 채운 후 "Next"를 클릭하고 "Stack failure options"에서 "Preserve successfully provisioned resources"를 설정한 후 제출합니다.


4. **CloudFormation 출력:**

   - CloudFormation "Outputs" 섹션에서 접근 자격 증명 및 서비스 URL을 확인합니다.

   - 자격 증명은 EC2 인스턴스의 `/opt/openvidu/.env` 파일에 있습니다.


**문제 해결:**

- 스택 생성이 실패(`CREATE_FAILED`)할 경우, 잘못된 구성, 권한 문제 또는 AWS 서비스 문제를 확인합니다.

- EC2 인스턴스 상태 및 로그(`/var/log/cloud-init-output.log`, `/var/log/cloud-init.log`)를 확인합니다.


**구성 및 관리:**

- 스택 상태가 `CREATE_COMPLETE`가 되면 배포가 완료됩니다.

- 관리에 대한 자세한 내용은 구성 및 관리 섹션을 참조하십시오.


이 가이드는 AWS에서 OpenVidu Single Node 인스턴스를 프로덕션 수준으로 배포하는 방법을 설명하며, AWS CloudFormation을 활용하여 설정 프로세스를 자동화합니다.

---

이런 방법인데, 탄력적 IP, 도메인 만 준비되면 템플릿 URL을 통해 인스턴스를 자동 생성해준다. 

이때 처음에, 기본 설정 되어 있는 인스턴스 자원을 선택했었다. c6.large 였나? 아무튼 프리티어 제공 자원은 아니였다.

근데 해당 템플릿 설정 후 실행하고 나니 ec2 인스턴스 서버 만드는데 fail을 했었다. 

해당 로그는 stack 의 이벤트 란에서 확인 가능했다. 

원인을 찾던 중, 나의 region이 서울이였고, default 서버 자원이 서울에서 지원 안할 수도 있다는 새ㅐㅇ각이 들었다. 

때문에 템플릿 URL 에 접근해서 yaml 파일을 읽어봤다.

가능한 서버 자원을 적는 란이 있어 t2.micro를 기입했다. (해당 자원이 서울 region에서도 사용 가능한 자원 + 프리티어)

그리고 stack을 t2.micro로 업데이트 하였다. 

이때는 인스턴스 생성까지 성공했다. 

하지만 waitCondition이 계속 update 중인것으로 뜨다가 10분 후에 실패로 뜬 것을 확인했다.

다시 yaml 파일을 까보았다. 

waitCondition 관련 설정을 봤는데, 10분 제한이 있었다.

t2.micro는 10분 보다는 더 필요하지 않을까? 라는 생각에 60분으로 설정해주었다. 

다시 stack 업데이트...

instance 생성 성공.. !

모든 리소스가 complete 된 것을 확인했다. 


이제 local 백엔드 서버와 local 프론트 서버를 키고 확인해봤다. 

local 환경변수에 livekit API 키랑 secret 키 추가해주고, 프론트 Livekit URL 에는 도메인 + 7780 포트를 설정했다. 

접근은 된다.. 근데 응답이 없다.....

aws instance 로그를 함 봐야겠다.

우선 실행중인 컨테이너 확인

docker ps -a

openvidu가 실행중인거 확인..

docker logs -f openvidu

... 첫 줄부터 내가 할당한 탄력적 IP 접근 실패..! 라는것을 확인했다. 

음..... 이 로그를 확인하기 전에 t2.micro로 만든게 잘못인가 해서 c5.large 로 설정 후 확인해봤지만 똑같았다. 

현재까지 5시간 소요..... 

안되겠다. 온 프로미스로 경로 변경.

Docs -> GPT 해석해줘

---

OpenVidu Single Node 설치 요약: On-premises

호환성:


OpenVidu Single Node는 OpenVidu v2 API와 호환되지 않습니다.

OpenVidu v2 애플리케이션과의 호환성을 위해서는 OpenVidu Elastic 또는 OpenVidu High Availability를 사용해야 합니다.

배포 단계:


아키텍처 개요:


OpenVidu 서버(LiveKit 호환)

Ingress 및 Egress 서비스

OpenVidu 대시보드

MinIO (S3 저장 서비스)

Redis (공유 데이터베이스)

MongoDB (분석 및 모니터링 데이터베이스)

Caddy (리버스 프록시)

OpenVidu Call (기본 화상 회의 애플리케이션)

Grafana, Mimir, Promtail, Loki (옵저버빌리티 모듈)

사전 요구사항:


최소 4GB RAM, 4 CPU 코어가 있는 리눅스 머신(우분투 권장)

충분한 디스크 공간 (100GB 권장)

공인 IP 및 FQDN

포트 규칙:


인바운드 포트 규칙: TCP 80, 443, 1935, 7881, 9000, UDP 443, 7885, 50000-60000

아웃바운드 포트 규칙: 모든 아웃바운드 트래픽 허용

설치 과정:


사전 요구사항 및 포트 규칙 확인

다음 명령어를 실행하여 설치 시작:

sh

코드 복사

sh <(curl -fsSL http://get.openvidu.io/community/singlenode/latest/install.sh)

설치 마법사에 따라 필요한 정보 입력:

인증서 유형 선택: Self Signed, Let's Encrypt, ZeroSSL, Own Certificate

도메인 이름 및 (선택적) TURN 도메인 이름 입력

활성화할 모듈 선택: Default App, Observability

기타 필요한 매개변수 입력 (비밀번호, 사용자 이름 등)

설치 완료 후:


성공적으로 설치되면 /opt/openvidu에 OpenVidu가 설치됨

다음 명령어로 서비스 시작:

sh

코드 복사

systemctl start openvidu

서비스 접근:

OpenVidu Call: https://openvidu.example.io/

OpenVidu Dashboard: https://openvidu.example.io/dashboard

MinIO: https://openvidu.example.io/minio-console

Grafana: https://openvidu.example.io/grafana

배포 자격 증명:


/opt/openvidu/.env 파일에서 모든 서비스의 접근 자격 증명 확인

애플리케이션에서 사용할 URL, API 키, API 비밀키:

URL: .env 파일의 DOMAIN_OR_PUBLIC_IP 값

API Key: .env 파일의 LIVEKIT_API_KEY

API Secret: .env 파일의 LIVEKIT_API_SECRET

---

확인 완료.

시작.

ec2 인스턴스 aws - linux로 만들고, t2.micro로 설정

인스턴스 생성 후 docker 및 docker-compose 설치 완료

이후에 docs 에서 제공하는 url로 openvidu 설치 시작
sh <(curl -fsSL http://get.openvidu.io/community/singlenode/latest/install.sh)

각종 옵션들 확인 

Let's Encrypt

도메인 이름

default App..

... 옵션들 설정 완료.

OpenVidu Community Installation Finished Successfully!


성공.

```
systemctl start openvidu
```

시작.

로그 확인. 정상작동 확인. 프론트 접근 시작

...?

실패

확인

aws ec2 서버의 livekit.yaml 확인

사용중인 포트 확인
7780 확인.

서버 보안 그룹 확인

7780 누락 확인

보안 규칙 추가 시작

확인

프론트 접근 시작.

접근 완료

배포 완료 확인 





블로그 포스트에서 다룬 문제와 그 해결방안을 요약하면 다음과 같습니다:

### 문제 요약 및 해결방안

1. **인스턴스 호환성 문제**
   - **문제**: AWS 서울 리전에서 지원되지 않는 c6.large 인스턴스 유형을 선택하여 EC2 인스턴스 생성 실패.
   - **해결**: t2.micro 유형으로 변경하여 호환성 문제 해결. t2.micro는 서울 리전에서 지원되며 프리티어 자원임.

2. **CloudFormation 초기화 시간 초과**
   - **문제**: 인스턴스는 생성되었으나, `waitCondition` 설정 때문에 10분 후에 시간 초과로 인해 실패.
   - **해결**: CloudFormation의 `waitCondition` 시간을 10분에서 60분으로 늘려 문제 해결.

3. **포트 설정 누락**
   - **문제**: EC2 인스턴스의 보안 그룹에 필요한 포트(7780)가 누락되어 OpenVidu 서버에 접근 불가.
   - **해결**: 보안 그룹 설정에 7780 포트 추가하여 접근 문제 해결.

4. **IP 접근 실패**
   - **문제**: Docker 로그에서 확인한 결과, 할당된 탄력적 IP로의 접근 실패 발견.
   - **해결**: 네트워크 설정 재검토 및 IP 설정 오류 수정으로 접근 실패 문제 해결.

이러한 문제 해결 과정은 AWS에서 OpenVidu Single Node 인스턴스를 성공적으로 배포하고, 로컬 환경에서의 백엔드와 프론트엔드 서버 구성을 완료하는 데 중요한 역할을 했습니다. 각 단계에서의 문제 인식 및 적절한 해결 방법 적용을 통해 배포 과정을 성공적으로 마무리할 수 있었습니다.


댓글

이 블로그의 인기 게시물

[OOP] 의존성 주입(Dependency Injection)을 통한 설계 원칙 준수: Java에서의 DIP 원칙 적용 사례