[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

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

이미지
객체지향적 코드 작성과 DIP 원칙의 중요성 객체지향 프로그래밍을 하다 보면, 때때로 구현체에 의존하게 되는 상황이 발생합니다. 이는 DIP(의존 관계 역전 원칙) 원칙을 어기는 사례로 볼 수 있습니다. DIP는 객체지향 설계의 SOLID 원칙 중 마지막 원칙으로, "추상화에 의존해야 하며, 구체화에 의존하면 안 된다"는 원칙을 강조합니다. DIP 원칙 위반 사례 아래 예시는 간단한 상품 구매 및 회원 관리 시나리오에서 DIP 원칙을 어기는 경우를 보여줍니다. 시나리오에는 OrderService 인터페이스와 그 구현체인 OrderServiceImpl, 그리고 MemberRepository 인터페이스와 그 구현체인 MemoryMemberRepository, DbMemberRepository가 있습니다. 또한, DiscountPolicy 인터페이스와 그 구현체인 FixDiscount, RateDiscount가 존재합니다. 초기 코드는 다음과 같습니다: public class MemberApp { public static void main ( String [] args ) { // AppConfig appConfig = new AppConfig(); // MemberService memberService = appConfig.memberService(); MemberService memberService = new MemberServiceImpl ( new MemoryMemberRepository () ) ; Member memberA = new Member ( 1L , "memberA" , Grade . VIP ) ; memberService. join ( memberA ) ; Member findMember = memberService. findMember ( 1L ) ; System . out . println ( &quo