2018년 4월 28일 토요일

AirPort 단종 뒤에 AirPlay 기술은 어떻게 되나?

가로 세로가 어른 손가락 길이 정도 밖에 안 되는 크기에 무선 공유기와 프린터 공유, 오디오 출력 공유 기능이 들어가 있다. 소비전력을 찾아보니 구동중에도 6와트 정도라고 하던데 계속 켜두었을 때 좀 따뜻해지는 정도의 발열을 생각하면 그보다는 좀 더 나오지 않을까 싶다.

다른 기능보다는 주로 AirPlay 때문에 쓴다. (원래는 AirTunes라는 이름이었다. iTunes와 연관성을 주고 싶었나보다.) 네트워크로 받은 음성 신호를 기기에 내장한 3.5파이 minijack 내지 원형 광출력 단자를 통해 출력하는 기능이 있고, 그 위에서 DAAP나 DACP 프로토콜 기반으로 재생과 제어를 담당하는 기술을 합한 게 AirPlay라고 할 수 있다.

유선과 무선 모두를 통해 신호를 받을 수 있기 때문에 거실에 스피커를 갖추어 놓고 방에서 iTunes로 재생하는 노래를 끌어다 듣는 식으로 쓰는 게 기본 용법이고 (DAAP 담당), 아예 iTunes에 해당하는 음원 저장 및 재생/제어까지를 분리하는 구성도 가능하다. (DACP 담당) iOS에 있는 Remote 앱이 제어만 분리한 형태다.



오디오 기기부터 자동차 옵션까지 몇몇 호환장비가 존재한다. 당연히 리눅스에서도 구현체가 있다. 가장 일반적이라고 할 수 있는 게 (FreeNAS에도 포함된 것으로 아는) forked-daapd로, iTunes의 재생 기능에 AirPlay로 출력을 보내는 기능이 있고 Remote 앱의 제어를 받아들인다. 음원을 구비하는 게 합법적이기만 하다면 아주 유동적인 구성으로 음악을 감상할 수 있다.

물론 전체 과정에서 핵심이 되는 건 스피커에 소리를 전달해주는 AirPlay 수신기의 존재다. 그리고 그게 AirPort 장치다.

AirPort가 공식적으로 단종된다고 발표가 났다. 새로운 기계가 안 나온지 이미 오래되긴 했다. 그리고 애플이라는 기업의 라인업 면에서는 AirPlay가 없어진다고 할수는 없을 거다. 그 사이에 Apple TV가 나오면서 AirPlay가 소리만이 아니라 영상도 전달하는 방식이 되었다. 소리만으로 한정해도 HomePod이라는 기계가 나왔다. HomePod이 AirPlay 기능이 있는 스피커라서 지금의 AirPort와 완전히 같지는 않지만.

지금 시장에 나와있는 AirPort 장치가 모두 없어지기 전까지야 AirPlay 기술이 계속 쓰이긴 할 것이다. 하지만 그 다음엔 어떻게 될까? 수중에 있는 장치가 고장이라도 나면 그 다음부터는 forked-daapd고 뭐고 써먹을 수가 없게 된다. 아니면 좀 더 연구를 해서 AirPlay 리시버 자체도 라즈베리파이 같은 걸로 구성해서 쓸 수 있으려나?shairport-sync 프로젝트가 있으니 지금도 가능한 일이다.

2018년 4월 23일 월요일

렌딧 중단

작년 여름부터 적금 말고 다른 방법도 찾아보기로 했다.
그 과정에서 P2P 금융이라는 이름이 붙은 업체들을 몇 개 정해서 조금씩 넣었다.

렌딧은 그 중에서도 5천원으로 단위 금액이 가장 적은데, 그만큼 위험이 분산되며, 소액에 세금이 붙는 거기 때문에 절세 효과가 생긴다는 설명이 그럴듯하게 보여서, 자동투자도 유지하고 개중 중점적으로 유지했다.
그런데 이제 몇 달이 지나고 보니 렌딧에서 계산해주는 수익률이 너무 떨어져 있었다. '실질 연환산 수익률' 항목은 8.37%로 낮지 않은데 '연체 채권의 추정손실률'이 7%라서 '예상 연환산 수익률'이 1.37%이 되었다. 세후 1.37이면 무난한 적금 정도로도 달성할 수 있는 이율이라서 아무래도 흥이 식는다.

2018년 4월 하순 현재 단기연체 5, 장기연체 3.

혹시 '수익추구형'으로 선택했던 수동 투자에서 연체가 발생한 건가 싶어서 채권상태 화면을 뒤적거려봤는데 그렇지도 않았다. '균형투자형'으로 만든 2017-08-21 첫 투자 100건 중에서 단기4, 장기3, 그리고 그 다음의 '수익추구형' 2017-11-23 투자 20건 중에서 단기1이 있다.
무엇보다 첫 투자에서 발생한 것들이기 때문에, 나는 이걸 '시간이 지나서 터질 게 터진' 상황으로 인지한다. 바꿔 말하면 '시간이 더 지나면 다른 투자건에서도' 연체가 더 계속 꾸준히 생길 거라고 본다.

이미 몇 년째 업계에 있었고 꽤 이름있는 업체인 렌딧의 채권에 대한 분류와 예측이 시원찮다는 의미일 수도 있겠고, 그 사이에 사람들 자금 사정이 한층 나빠져서 예측 모델을 벗어날만큼의 상황이 되었다고도 할 수 있겠지. 혹은 그냥 내가 투자에 대해서 너무 감이 없어서 지금 상황을 완전히 잘못 이해하고 있는 걸지도 모르겠다.

어쨌거나 일단은 자동투자를 껐고, 앞으로 회수되는 금액은 모두 출금할 생각이다.

2018년 4월 10일 화요일

로그 남기는 코루틴

일전에 뭔가 긴 코드를 짜다가, 로그 남기는 동작을 코루틴으로 돌리면 좋겠다는 생각이 들었었다.
어설프게 개념만 이해하고 실제로 써본 적은 없는 터여서 재밌겠다는 생각이 들었지만 내 것 아닌 코드에 집어넣기가 저어해서 진행은 하지 않았다.
그리고 오늘 마침 그때 생각이 나서 예제 코드를 짜보려고 했는데 막상 손을 대니 그럴듯한 코드가 나오지 않는다. 그때는 어떤 착상을 했던 건지 제대로 떠오르지 않고. 그냥 개념을 오해해서 잘못 생각했던 걸까?

2018년 4월 8일 일요일

kubernetes cluster 하나 설치, 일단 성공

https://blog.alexellis.io/kvm-kubernetes-primer/

위의 내용대로 br0 네트워크 인터페이스를 만들고 virt-install를 통해 vm을 생성하고 k8s를 설치했다. 손수 vm을 만들고 손수 docker와 k8s 패키지를 깔아서 세팅했을 때 네트워크 문제로 보이던 pod 실패도 없었고 반응 속도도 매우 빠르다.
br0 장치를 따로 만든거나 sysctl 설정을 바꾸고 진행한 게 vm끼리의 통신 문제를 해결한 것 같은데 어느 쪽이 맞는지는 모르겠다. 나중에 다시 궁금해지면 확인해봐야겠다.

대시보드는 github에 나와있는 명령대로 설치하고, master의 crontab에 kubectl proxy를 실행하도록 한 다음, ssh -L 명령으로 로컬 8001에 접속하면 master의 8001에 접속하게 했다.

대시보드 인증은 https://blog.heptio.com/on-securing-the-kubernetes-dashboard-16b09b1b7aca 에 나온대로 serviceaccount를 하나 만들어서 token을 썼다.

minikube라는 선택지도 있었지만, 그렇게 간단한 구성만으로는 충분히 맛을 볼 수가 없을 것 같아서 손을 대지 않았다.

2018년 4월 4일 수요일

rabbitmq priority queue support in php

https://www.rabbitmq.com/priority.html

rabbitmq 3.7.0
phpamqplib


큐 선언
    $args = new AMQPTable();
    $args->set('x-max-priority', 10);

    $ch->queue_declare($queue, false, true, false, false, false, $args);


메시지 생성
    if ($priority > 1) {
      $args['priority'] = $priority;
    }
    $msg = new AMQPMessage($message, $args);


x-max-priority 속성이 있는 임의의 큐에 10개 메시지를 priority 속성 부여한 상태로 publish 했을 때, consumer가 10개를 받는 순서대로 AMQPMessage의 priority 속성을 확인하면 숫자가 높은 순서대로 전달되는 것을 확인함

큐에 x-max-priority 속성이 없이 선언되었으면 각 메시지에 priority 속성을 부여해도 효과가 없는 것으로 보임

traefik, the kubernetes ingress controller

https://docs.traefik.io/user-guide/kubernetes/

kubernetes 클러스터도 하나 생겼으니 기념삼아 이것저것 생각나는 걸 깔아봤다.

안내문에 적힌 치즈 웹서비스를 다음과 같이 테스트해봤고, 까먹었을 때 보기 위해 적어둔다.

export ADDR=kube-node-3 PORT=32479; for h in cheeses.minikube cheddar.minikube stilton.minikube wensleydale.minikube; do curl $ADDR:$PORT -H "Host: $h" -v; done

kube-node-3은 ds가 아니라 deployment (=그 노드에서만 동작하는) 방식으로 설치한 traefik이 테스트 시점에 구동중인 노드였다.

원래 하고 싶었던 건 kubernetes 클러스터에 external loadbalancer를 붙이고 (그게 traefik이 되면 좋고) 거기서 다시 hostname 기반으로 분산을 하는 거였다. 외부에서 접근했을 때 traefik이 실행중인 노드로 접근하게 만드는 걸 아직 몰라서, 일단 hostname 방식으로 동작한다는 걸 확인하기 위해 Host 헤더를 강제로 집어넣었다. 원했던 대로 각 호스트의 웹서버가 각각 반응해줘서 기뻤다.

http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/ 여기서 설명하는 내용을 보면 traefik이 제공하는 ingress controller를 잘 쓰면 애초에 원하던 걸 처리할 수 있는 것 같다.

여전히 남는 의문은, 그럼 ingress controller가 동작중인 node를 어떻게 다시 공인IP의 세계로 노출시키는가 하는 점인데.

https://stackoverflow.com/a/37796383 를 보면 externalIPs라는 설정을 언급하고 있지만, 이건 hostname에 반응하는 것처럼 특정IP를 목표로 지정된 트래픽이 (미리 설정된 외부의 route에 따라) k8s 안쪽까지 들어가면, 그 IP에 반응하도록 서비스를 설정하는 것인데, 임의의 hostname을 지정할 수도 있는 것과 달리 숫자IP를 고정적으로 지정해야 해서 그다지 좋은 방식은 아닌 것 같다. 내가 찾던 방향도 아닌 것 같고.

https://medium.com/@maniankara/kubernetes-tcp-load-balancer-service-on-premise-non-cloud-f85c9fd8f43c 내용을 보면 yaml에서부터 externalIPs 설정을 적어주지 않고 kubectl expose 명령으로도 정할 수 있나보다. expose 명령의 옵션을 자세히 보지 않았던 게 잘못이다.
(이어서 tcp-echo-server라는 예제를 통해 NodePort 대신 hostNetwork:true 속성을 켜는 방법을 보여주는 것도 재밌는 방법처럼 보이지만, 권장되는 방법도 아니고, traefik을 쓸 거니까 관심사는 아니다)

expose 명령의 --external-ip 옵션에 traefik이 떠 있는 node의 IP를 지정하고 (kubernetes dashboard에 EXTERNAL-IP 항목으로 나온다) 80 포트를 80 포트로 연결하라고 한 다음에, (/etc/hosts에 kube-node-3와 같은 IP로 지정된) curl cheddar.minikube 명령을 실행하면 Cheddar라는 페이지가 출력된다. 앞서 curl에 Host 헤더를 강제로 먹였던 것과 같은 결과다.

AWS 같은 클라우드 서비스에서야 LoadBalancer 타입으로만 지정해도 expose에 사용될 공용IP를 받아서 지정하면 끝이니 복잡할 게 없이 클라우드 API 호출로 IP만 받으면 바로 끝날 동작이다.

공유기 안쪽에서 192.168.x.x 범위로 구성할 때를 기준으로 바꿔서 생각해보면 이렇게 되겠다.
  1. 공유기 밖에서 공유기 안으로 넘어오는 단계 - 포트포워딩, DMZ 등
  2. 넘어온 트래픽을 받을 내부IP를 어떻게 고정적으로 유지할지 - DNS에서 IP 고정
  3. 그 내부IP가 받은 신호가 traefik 같은 ingress controller로 넘어가는 과정을 어떻게 유지할지 - expose 명령을 쓰고, 고정된 내부IP를 external-ip로 지정

2018년 4월 3일 화요일

노조

예전에 (아마도) 금속노조에 가입했다는 어느 얘기를 본 기억이 있다.

왜 기억하냐면, 거기가 금속노조 하면 떠올릴만한 강성 파워 거친 업장이 아니어서다. 아마도 아줌마로 불릴만한 노동자가 대부분인 곳이었던 것 같다.

왜 하필 금속노조인가 물으니 여기도 쇠를 쓴다며 기왕 노조 들 거면 쎈 데가 좋지 않을까 해서 금속노조를 택했다고 답했다고 본 걸로 기억한다. 남아있는 이미지는 활기찬 인터뷰 분위기에서 마지막에 말하는 본인도 웃겨서 깔깔 웃으며 답하는 것.

오늘 네이버에서 노조가 출범했다는 기사를 봤다. 여기는 화학섬유노조, 2017년 11월부터는 화학섬유식품노조 산하로 들어갔다고 한다.

네이버가 화섬이라니, 하는 생각 끝에 일전의 금속노조 얘기가 새삼 떠올랐다. 금속노조 지부마다 지회 목록은 있나본데 하나씩 다 뒤져보기도 뭐하고 해서 정확히 찾아보진 않았다. 그렇다고 금속노조나 민주노총 게시판에 뜬금없이 '혹시 이러저러한 지회가 정말로 있는 것입니까?' 하고 물어보는 것도 분위기 상 안 맞을 것 같고.

그 금속노조인 이유가 식판이었나 하는 생각에 식당 쪽으로 검색해보니 나오긴 한다. http://www.redian.org/archive/14204 현대푸드. 근데 2006년 얘기라서 이건 아닌 것 같다.

어디 물어볼만한 데도 없고. 궁금하네.

찾았다. https://twitter.com/coke_cloud/status/955701669328666624 담터. '차'를 만드니까 금속노조, 라고. '금속노조 이색 지회' 따위로 찾았을 때는 안 나왔고, 하다 하다 '우리도 금속노조'라고 던져봤는데 덥석 나온다.

https://twitter.com/labordream/status/959698451914084352 노조를 뭘로 들든 업종이랑은 상관없다니 과연 헌법이 보장하는 권리.