제목 그대로입니다.
LG 스마트 TV 의 DLNA 사용은...그냥 그런 기능이 있다 수준으로만 생각하자구요...
얼마나 허접하냐면...
1. 최신의 펌웨어에선, REW/FF 작동 안합니다. 건너띄기만 작동하기 때문에 잠시 앞의 것을 보려면 1분 이상을 앞으로 가서 기다려야 합니다.
2. mkv 확장자 등을 이용한 멀티채널 음성을 지원 안합니다. 그래서 한글 더빙이 있는 동영상도 영어로 봐줘야 합니다. 다행이 자막은 지원을 하네요.
3. 1080p 동영상 재생 시 속도 저하로 인해 잦은 reload 혹은 음성 싱크 틀려지는 문제가 발생할 수 있습니다. 트랜스코딩 옵션을 켜면 고쳐질 수 있지만, DLNA Server 의 사양이 좋지 않을 경우 포기해야 합니다.
4. 업데이트는 죽어라 안합니다.
5. 그나마 된 업데이트가..위의 1~2 번 기능을 무려 "삭제" 한 업데이트랍니다.
본가에 있는 구형 LG 스마트 TV 는 1 번에 문제가 있을 수 있다는 경고와 함께 작동합니다. 그런데 인터넷을 뒤져보니 펌웨어 업그레이드 후 저 기능이 아예 막혔고, 2 번 역시 동일하다고 하는 글이 있네요.
그럴꺼면 왜 DLNA 를 재정하고 도입하려고 하는지 모르겠네요. 심지어 TV 에서 사용하라고 하는 PLEX Media Server 를 DLNA 서버로 썼는데도 말입니다.
아...물론 PLEX Media Server 의 재생앱에선 mkv 멀티음성 잘 지원합니다. 유료로 구입한 스마트폰 앱에서도 잘 되고 REW/FF 등도 잘 되고 트랜스코딩도 잘 됩니다.
당연히 TV 에 들어가는 칩이 x86 은 아닐꺼고 arm 도 아닐지도 모르고 더 열악한 개발환경을 제공하는 칩일 수 있고, 그러다보니 처음에 기능을 넣었다가 막을 수도 있겠지요. 하지만, 본가의 TV 만 해도 2010 년도 모델, 우리 집 TV 는 2012 년도 모델입니다. 심지어 TV 와 별개로 셋탑 형식으로도 판매되는 제품이 있던데...동일하지 않을까요? 이 기능 넣으면서 가격은 얼마나 비싸졌는데...
사실, DLNA 가 제대로만 구현된다면 나름 편한 점이 있습니다. 무엇보다 인트라넷에서 직접 정보를 가져오기 때문에 TV 에서 Server 까지 선으로 연결할 필요가 없죠. 그런 장점들 때문에 DLNA 지원을 확인하고 비싼 돈을 주고 구입했는데...LG 전자 페이스북을 포함해서...LG 전자의 응대도 개*이고...쩝...
다음에는 정말 삼성껄, 아니 중국 샤오미 이런걸 사야 할까요?
2014년 7월 10일 목요일
2014년 4월 16일 수요일
Couchbase 도입기 - 3
Couchbase 는 RHEL 이나 Ubuntu 계열에서 쉽게 설치가 가능합니다. 저의 경우 KT UcloudBiz 을 이용중이라 CentOS 6.5 을 사용중이고, yum install 로 Couchbase.com 에 있는 rpm 을 직접 설치하는 방식을 이용해서 설치하고 있습니다.
Couchbase 의 가장 편리한 점은 통상적으로 오픈소스 프로그램을 설치할 때 설정 파일을 열어 텍스트로 된 설정값을 수정하는 작업을 선행하는 형태의 작업이 필요없다는 것입니다. 상용으로도 제공되는 제품이다보니 설정이 굉장히 깔끔한 편입니다. yum 으로 install 한 뒤에 자동으로 couchbase-server 가 start 되어 있어서 바로 접속이 가능합니다.
첫번째 서버를 설치한 뒤 웹브라우저를 통해 8091 포트로 접속하면 설치 화면으로 접속이 가능합니다. 거기서 Admin 의 아이디와 비밀번호도 지정할 수 있고, 설치 위치도 지정할 수 있습니다. 그리고, 두번째 서버부터는 바로 첫번째 서버의 도메인을 지정하여 바로 연결할 수 있습니다.
이렇게 서버를 설치한 뒤 1 대 이상의 Couchbase 가 Clustering 이 되면 기본적으로 Data 을 분산하여 관리합니다(Sharding). Couchbase 내부의 알고리즘에 의해 데이터가 분산되어 저장되기 때문에 SDK 등으로 접속 시 원하는 자료를 불러오고 싶을 때 모든 서버를 뒤질 필요 없이 자료가 저장된 서버에서 가져오기 때문에 서버의 개수가 늘어날수록(Scale Out) 부하 분산이 되어서 속도가 느려지는 현상이 줄어듭니다. 일반적으로 Couchbase 는 서버의 사양을 올리는 것보다(물론 메모리는 크면 좋습니다) 이렇게 개수를 늘리는 쪽이 성능 향상에 도움이 되는 형태입니다.
그리고 이렇게 분산된 데이터는 각각 다른 서버의 Disk 에 Replica 로 저장이 되어 있기 때문에 장애가 발생해도 데이터가 유실되지 않습니다. 만약 하나의 서버에 장애가 발생한다면 해당 서버를 FailOver 처리를 한 뒤 Rebalacing 을 해주면 남아있는 서버에 남아있는 장애 서버의 자료의 Raplica 을 꺼내와 기존 서버의 메모리에 있는 자료들과 혼합하여 다시 분산 작업(Sharding) 을 진행하게 됩니다. 그리고 장애 서버는 Remove 할 수 있게 됩니다. 이 동작이 서버 중지 후 가능한 것이 아니라 서비스 도중 이루어지기 때문에 무중지 서버 운영이 가능하다는게 Couchbase 의 큰 장점 중 하나입니다. 그리고 장애가 발생한 서버를 고치거나 새로운 신규 서버를 투입한 뒤 다시 Rebalacing 을 할 때에도 마찬가지로 알고리즘에 의해 분산 저장(Sharding) 을 해서 서버는 항상 비슷한 양의 데이터를 분산 저장해서 응답 속도에 문제가 발생하지 않도록 구성되어 있습니다.
일반적인 운영에서 드러나는 가장 중요한 특징이 Sharding 와 Rebalacing 입니다. 그리고 장애 발생시 FailOver 처리와 Remove 처리 또한 이해가 필요한 작업입니다. 시간이 걸리는 작업인데 무턱대로 눌렀다가는 데이터 유실이 발생할 수도 있습니다(경험담). 서버를 추가한 뒤(yum 으로 설치 후 add server 을 이용해 매우 쉽게 추가 가능합니다) Rebalance 만 해주면 Scale Out 이 매우 손쉽게 된다는 것도 매우 매력적입니다.
이 다음 이야기는 다음 글에서 계속합니다...
Couchbase 의 가장 편리한 점은 통상적으로 오픈소스 프로그램을 설치할 때 설정 파일을 열어 텍스트로 된 설정값을 수정하는 작업을 선행하는 형태의 작업이 필요없다는 것입니다. 상용으로도 제공되는 제품이다보니 설정이 굉장히 깔끔한 편입니다. yum 으로 install 한 뒤에 자동으로 couchbase-server 가 start 되어 있어서 바로 접속이 가능합니다.
첫번째 서버를 설치한 뒤 웹브라우저를 통해 8091 포트로 접속하면 설치 화면으로 접속이 가능합니다. 거기서 Admin 의 아이디와 비밀번호도 지정할 수 있고, 설치 위치도 지정할 수 있습니다. 그리고, 두번째 서버부터는 바로 첫번째 서버의 도메인을 지정하여 바로 연결할 수 있습니다.
이렇게 서버를 설치한 뒤 1 대 이상의 Couchbase 가 Clustering 이 되면 기본적으로 Data 을 분산하여 관리합니다(Sharding). Couchbase 내부의 알고리즘에 의해 데이터가 분산되어 저장되기 때문에 SDK 등으로 접속 시 원하는 자료를 불러오고 싶을 때 모든 서버를 뒤질 필요 없이 자료가 저장된 서버에서 가져오기 때문에 서버의 개수가 늘어날수록(Scale Out) 부하 분산이 되어서 속도가 느려지는 현상이 줄어듭니다. 일반적으로 Couchbase 는 서버의 사양을 올리는 것보다(물론 메모리는 크면 좋습니다) 이렇게 개수를 늘리는 쪽이 성능 향상에 도움이 되는 형태입니다.
그리고 이렇게 분산된 데이터는 각각 다른 서버의 Disk 에 Replica 로 저장이 되어 있기 때문에 장애가 발생해도 데이터가 유실되지 않습니다. 만약 하나의 서버에 장애가 발생한다면 해당 서버를 FailOver 처리를 한 뒤 Rebalacing 을 해주면 남아있는 서버에 남아있는 장애 서버의 자료의 Raplica 을 꺼내와 기존 서버의 메모리에 있는 자료들과 혼합하여 다시 분산 작업(Sharding) 을 진행하게 됩니다. 그리고 장애 서버는 Remove 할 수 있게 됩니다. 이 동작이 서버 중지 후 가능한 것이 아니라 서비스 도중 이루어지기 때문에 무중지 서버 운영이 가능하다는게 Couchbase 의 큰 장점 중 하나입니다. 그리고 장애가 발생한 서버를 고치거나 새로운 신규 서버를 투입한 뒤 다시 Rebalacing 을 할 때에도 마찬가지로 알고리즘에 의해 분산 저장(Sharding) 을 해서 서버는 항상 비슷한 양의 데이터를 분산 저장해서 응답 속도에 문제가 발생하지 않도록 구성되어 있습니다.
일반적인 운영에서 드러나는 가장 중요한 특징이 Sharding 와 Rebalacing 입니다. 그리고 장애 발생시 FailOver 처리와 Remove 처리 또한 이해가 필요한 작업입니다. 시간이 걸리는 작업인데 무턱대로 눌렀다가는 데이터 유실이 발생할 수도 있습니다(경험담). 서버를 추가한 뒤(yum 으로 설치 후 add server 을 이용해 매우 쉽게 추가 가능합니다) Rebalance 만 해주면 Scale Out 이 매우 손쉽게 된다는 것도 매우 매력적입니다.
이 다음 이야기는 다음 글에서 계속합니다...
2014년 4월 11일 금요일
Couchbase 도입기 - 2
Couchbase 을 도입하기로 마음 먹었습니다. 국내에 총판도 있어서 유사시 구입해서 지원을 받을 수 있는 환경이기도 했습니다. 활성화가 잘 되어 있다고는 할 수 없지만 네이버에 카페도 운영하고 있었습니다.
그런데, 도입 후 가격에 대해 문의를 했는데, 딸리는 영어 실력에 솔루션에 대한 이해가 떨어져서 도입 예상가를 제대로 판단하지 못한 문제가 발생했습니다.
처음 도입 시 1 대만 도입해도 되고, 24 시간 서비스 안받아도 되니 가장 저렴한 것으로 구입해도 되겠네...라는 생각을 가졌고, 본사에서 운영하는 사이트에서 제시된 2000 달러(2백만원 초반)면 상용 솔루션으로 전환도 가능하겠다고 생각했습니다.
하지만, Couchbase 는 1 대를 운영하는 것으로는 정상적인 운영이라고 부르기 힘든 제품입니다. 데이터에 대한 분산(Sharding)을 지원하고, 장애가 발생한 서버의 데이터를 재분산(Rebalancing)하는 특징이 있기 때문에, 최소 3 대 이상을 운영해야 제대로 된 구성이라고 할 수 있습니다.
그리고, 초기 도입 시 무조건 교육 패키지를 포함해야 합니다. 한국 총판에서는 (가격을 밝혀도 되는지 모르겠지만) 대략 프리미엄 급 제품 1 개의 가격만큼 책정을 해놓았더군요. 미국 본사의 방침이기도 하답니다.
결국 엔터프라이즈 급으로 도입하기 위해서는 최소 천만원 초중반의 비용이 소모된다는 결론에 도달하게 됩니다. 그래서, 아무 회사에서 엔터프라이즈로 바로 도입하는 건 무리라고 생각합니다. 물론 자료가 많아져서 커뮤니티 버젼으로도 운영 시 장애가 발생해도 해결하는데 큰 어려움이 없어진다면 커뮤니티로 도전하는 회사가 늘겠습니다만...사실 이걸 커뮤니티로 써도 될 정도의 자료가 있는 제품이라고 다른 분에게 권하기는 어렵겠더라구요. 자료를 유실해도 크게 문제가 없는 개인이 운영하는 커뮤니티나 조그만 포털 정도에서 쓰는 거면 몰라도요...
어쨌든 이런 비용 문제 때문에, 우리 회사도 일단은 커뮤니티 버젼으로 시작은 하기로 했습니다. 서비스 시작 후 수입이 괜찮을 것 같다면 바로 구입한다는 전제 조건 하에서요.
Couchbase 의 또 다른 특징은 Cloud 와 같이 공인 IP 을 하나만 쓰고 포트를 나워서 쓰는 환경에서는 쓰기가 쉽지 않다는 것입니다. 이는 모든 경우에 해당하는 것은 아닌데, SDK 을 이용해서 각 프로그램에서 접속을 할 때 귀찮은 일이 발생하게 됩니다. 사실 Couchbase 는 가상 머신이 아닌 실제 머신에서 운영하는 것을 권장합니다만...서버가 유동적으로 늘어나거나(Scale Out) 줄어들 수 있는(Scale In) 환경(대표적인게 게임 서버 쪽입니다)에서는 Cloud 서비스를 생각하게 됩니다. 요즘 많은 게임 회사들이 Cloud 쪽을 선호하는 이유이기도 합니다.
어쨌든...Couchbase 는 각 프로그래밍 언어을 위한 SDK 을 제공하는데, 사용하기 매우 편리합니다만, 접속 시에는 Clustering 방식 때문에 약간 독특한 방식을 취합니다. 가장 큰 문제는 여러 개의 연결된 Couchbase 중 하나의 서버에 접속하여 데이터를 처리하는 것이 아니라, 접속 목록을 SDK Client 에 제공하면 순서대로 접속을 시도한 뒤, 서버에서 사용 가능한 서버들의 도메인과 포트 정보를 보내준다는 것입니다. 그래서 Cloud 등에 들어있는 서버에 접속하기 위해서는 대표 서버 하나의 정보만을 이용해서 접속을 하도록 소스 상에 설정을 해둬야 합니다. 이를 자동화하지 않는다면 상황에 따라 서버 접속 정보를 바꿔줘야 하는 불편함이 발생하게 됩니다.
또한, 사용하는 포트 중 11210 이후 포트가 있는데(아마 Memcached 쪽 포트일 듯) 이게 우리 회사가 사용하는 KT UCloudbiz 의 예약 포트번호입니다. 그래서 이 포트를 열기 위해서는 게시판에 별도 요청을 해야 합니다. 이것도 나름 귀찮더군요.
이 다음 이야기는 다음 글에서 계속합니다...
그런데, 도입 후 가격에 대해 문의를 했는데, 딸리는 영어 실력에 솔루션에 대한 이해가 떨어져서 도입 예상가를 제대로 판단하지 못한 문제가 발생했습니다.
처음 도입 시 1 대만 도입해도 되고, 24 시간 서비스 안받아도 되니 가장 저렴한 것으로 구입해도 되겠네...라는 생각을 가졌고, 본사에서 운영하는 사이트에서 제시된 2000 달러(2백만원 초반)면 상용 솔루션으로 전환도 가능하겠다고 생각했습니다.
하지만, Couchbase 는 1 대를 운영하는 것으로는 정상적인 운영이라고 부르기 힘든 제품입니다. 데이터에 대한 분산(Sharding)을 지원하고, 장애가 발생한 서버의 데이터를 재분산(Rebalancing)하는 특징이 있기 때문에, 최소 3 대 이상을 운영해야 제대로 된 구성이라고 할 수 있습니다.
그리고, 초기 도입 시 무조건 교육 패키지를 포함해야 합니다. 한국 총판에서는 (가격을 밝혀도 되는지 모르겠지만) 대략 프리미엄 급 제품 1 개의 가격만큼 책정을 해놓았더군요. 미국 본사의 방침이기도 하답니다.
결국 엔터프라이즈 급으로 도입하기 위해서는 최소 천만원 초중반의 비용이 소모된다는 결론에 도달하게 됩니다. 그래서, 아무 회사에서 엔터프라이즈로 바로 도입하는 건 무리라고 생각합니다. 물론 자료가 많아져서 커뮤니티 버젼으로도 운영 시 장애가 발생해도 해결하는데 큰 어려움이 없어진다면 커뮤니티로 도전하는 회사가 늘겠습니다만...사실 이걸 커뮤니티로 써도 될 정도의 자료가 있는 제품이라고 다른 분에게 권하기는 어렵겠더라구요. 자료를 유실해도 크게 문제가 없는 개인이 운영하는 커뮤니티나 조그만 포털 정도에서 쓰는 거면 몰라도요...
어쨌든 이런 비용 문제 때문에, 우리 회사도 일단은 커뮤니티 버젼으로 시작은 하기로 했습니다. 서비스 시작 후 수입이 괜찮을 것 같다면 바로 구입한다는 전제 조건 하에서요.
Couchbase 의 또 다른 특징은 Cloud 와 같이 공인 IP 을 하나만 쓰고 포트를 나워서 쓰는 환경에서는 쓰기가 쉽지 않다는 것입니다. 이는 모든 경우에 해당하는 것은 아닌데, SDK 을 이용해서 각 프로그램에서 접속을 할 때 귀찮은 일이 발생하게 됩니다. 사실 Couchbase 는 가상 머신이 아닌 실제 머신에서 운영하는 것을 권장합니다만...서버가 유동적으로 늘어나거나(Scale Out) 줄어들 수 있는(Scale In) 환경(대표적인게 게임 서버 쪽입니다)에서는 Cloud 서비스를 생각하게 됩니다. 요즘 많은 게임 회사들이 Cloud 쪽을 선호하는 이유이기도 합니다.
어쨌든...Couchbase 는 각 프로그래밍 언어을 위한 SDK 을 제공하는데, 사용하기 매우 편리합니다만, 접속 시에는 Clustering 방식 때문에 약간 독특한 방식을 취합니다. 가장 큰 문제는 여러 개의 연결된 Couchbase 중 하나의 서버에 접속하여 데이터를 처리하는 것이 아니라, 접속 목록을 SDK Client 에 제공하면 순서대로 접속을 시도한 뒤, 서버에서 사용 가능한 서버들의 도메인과 포트 정보를 보내준다는 것입니다. 그래서 Cloud 등에 들어있는 서버에 접속하기 위해서는 대표 서버 하나의 정보만을 이용해서 접속을 하도록 소스 상에 설정을 해둬야 합니다. 이를 자동화하지 않는다면 상황에 따라 서버 접속 정보를 바꿔줘야 하는 불편함이 발생하게 됩니다.
또한, 사용하는 포트 중 11210 이후 포트가 있는데(아마 Memcached 쪽 포트일 듯) 이게 우리 회사가 사용하는 KT UCloudbiz 의 예약 포트번호입니다. 그래서 이 포트를 열기 위해서는 게시판에 별도 요청을 해야 합니다. 이것도 나름 귀찮더군요.
이 다음 이야기는 다음 글에서 계속합니다...
피드 구독하기:
글 (Atom)