Storehouse

보통 도메인 이름으로 IP를 lookup 하는 용도로 DNS를 많이 사용한다. IPv4를 lookup할 때는 A Record 형태로 저장된다. IPv6는 AAAA Record 형태로 저장된다.

hostname을 조금 더 확장해서 동일한 hostname에 있는 여러 서비스의 하나하나를 lookup할 수 있는 용도로 SRV Record를 사용할 수 있다.

_service._proto.name. TTL class SRV priority weight port target.

service: 서비스 이름

proto: protocol (TCP, UDP 등)

name: 도메인 이름

TTL: DNS에서 살아 있을 기간 Time to Live

class: DNS class로 항상 IN

priority: 우선순위. 작은 숫자가 더 높은 우선순위

weight: 동일한 우선순위를 가졌을 때 비교할 가중치

port: 서비스 port

target: 서비스에 할당한 hostname

A Record에서 _service._proto 부분이 추가로 늘었다고 생각하면 조금 간단하다.

# _service._proto.name.  TTL   class SRV priority weight port target. _sip._tcp.example.com.   86400 IN    SRV 10       60     5060 bigbox.example.com. _sip._tcp.example.com.   86400 IN    SRV 10       20     5060 smallbox1.example.com. _sip._tcp.example.com.   86400 IN    SRV 10       20     5060 smallbox2.example.com. _sip._tcp.example.com.   86400 IN    SRV 20       0      5060 backupbox.example.com.

아래 커맨드들로 lookup 할 수 있다.

$ dig _sip._tcp.example.com SRV $ host -t SRV _sip._tcp.example.com $ nslookup -querytype=srv _sip._tcp.example.com $ nslookup > set querytype=srv > _sip._tcp.example.com

동일한 행동이 겹치는 경우가 있다.

모바일 화면에서는 손가락 하나로 스크롤링을 한다. 상하좌우.

페이지에 embed되어 있는 지도를 움직일 때, 손가락 하나로 움직인다.

둘이 겹쳐버리면 내가 원하지 않는 동작을 할 때가 있다. 특히, 화면이 작은 모바일 화면에서는, 페이지에 있는 지도가 전체 화면을 가려버리는 경우가 종종 발생한다. 나는 스크롤을 하고 싶지만 계속 지도만 움직인다. 지도가 화면을 모두 차지하고 있으니 손가락 하나로 아무리 비벼봐도, 스크롤을 할 수 없고 지도를 치울 수 없는 뫼비우스의 띠 같은 현상이..

Google Maps(http://maps.google.com/)는 간단히 지도를 움직이고 싶으면 손가락 2개를 사용하라고 한다. 그리고 이 헬프 메시지가 지도를 가리면 안 되니까, 지도에서 손가락 하나로 스크롤링을 할 때만 메시지를 보여준다. (지도의 가장 큰 목적은 지도를 보여주는거니까 메시지로 가리지 말자.)

그리고, PC화면은??

스크롤을 하기 위해 휠을 돌린다.

지도의 줌을 하기 위해 휠을 돌린다.

간단한 웹서버 python 버전.

사실 뭐 설치할 것도 없고, 이 명령어만 실행시켜주면 현재 경로가 웹서버로 제공된다. /로 접근할 때 index.html 같은 파일이 있으면 응답으로 내려주니 긋긋

$ cat index.html HELLO!!! $ python -m SimpleHTTPServer Serving HTTP on 0.0.0.0 port 8000 ... 10.10.10.10 - - [20/Jan/2017 16:44:01] "GET / HTTP/1.1" 200 - 10.10.10.10 - - [20/Jan/2017 16:46:22] "GET / HTTP/1.1" 200 -

$ curl http://localhost:8080 HELLO!!! $

port number는 parameter로 주면 된다

$ python -m SimpleHTTPServer 9000 Serving HTTP on 0.0.0.0 port 9000 ...

헷갈리기 쉬운 Docker Dockerfile 명령어, RUN, CMD, ENTRYPOINT. 모두 뭔가 실행하는 명령어이다.

RUN. 새로운 레이어에서 명령어를 실행하고, 새로운 이미지를 생성한다. 보통 패키지 설치 등에 사용된다. e.g. apt-get

CMD. default 명령이나 파라미터를 설정한다. docker run 실행 시 실행할 커맨드를 주지 않으면 이 default 명령이 실행된다. 그리고 ENTRYPOINT의 파라미터를 설정할 수도 있다. CMD의 주용도는 컨테이너를 실행할 때 사용할 default를 설정하는 것이다.

ENTRYPOINT. 컨테이너를 실행할 수 있게 설정한다.

RUN

보통 이미지 위에 다른 패키치(프로그램)를 설치하고 새로운 레이어를 생성할 때 사용한다. 다음은 ubuntu 이미지 위에 curl을 설치하는 예제이다.

FROM ubuntu:14.04 RUN apt-get update RUN apt-get install -y curl

RUN 명령을 실행할 때 마다 레이어가 생성되고 캐시된다. 따라서, 위와 같이 RUN 명령을 따로 실행하면 apt-get update는 다시 실행되지 않아서 최신 패키지를 설치할 수 없다. 아래처럼 RUN 명령 하나에 apt-get update와  install을 함께 실행해 주자.

FROM ubuntu:14.04 RUN apt-get update && apt-get install -y \     curl \     nginx \ && rm -rf /var/lib/apt/lists/*

CMD

CMD는 docker run 실행 시 명령어를 주지 않았을 때 사용할 default 명령을 설정하거나, ENTRYPOINT의 default 파라미터를 설정할 때 사용한다. CMD 명령의 주용도는 컨테이너를 실행할 때 사용할 default를 설정하는 것이다. CMD 명령은 3가지 형태가 있다.

CMD ["executable","param1","param2"] (exec form, this is the preferred form)

CMD ["param1","param2"] (as default parameters to ENTRYPOINT)

CMD command param1 param2 (shell form)

FROM ubuntu CMD echo "This is a test."

위와 같이 Dockerfile을 만들었을 때, docker run 실행 시 아무런 커맨드를 주지 않으면 CMD 명령이 실행된다.

$ docker run -it --rm <image-name> This is a test $

echo “Hello” 라고 커맨드를 주게 되면, CMD는 무시되고 커맨드가 실행된다.

$ docker run -it --rm <image-name> echo “Hello” Hello $

CMD는 여러번 사용할 수 있지만 가장 마지막에 있는 CMD 딱 1개만 남게 된다. (override) ENTRYPOINT의 default 파라미터는 아래 ENTRYPOINT에서..

ENTRYPOINT

ENTRYPOINT는 2가지 형태를 가지고 있다.

ENTRYPOINT ["executable", "param1", "param2"] (exec form, preferred)

ENTRYPOINT command param1 param2 (shell form)

docker run 실행 시 실행되는 명령이라고 생각해도 좋을 것 같다.

FROM ubuntu ENTRYPOINT ["/bin/echo", "Hello"] CMD ["world"]

위 Dockerfile의 내용을 실행하면 CMD 에서 설정한 default 파라미터가 ENTRYPOINT 에서 사용된다. docker run 명령 실행 시 파라미터를 주면 CMD에서 설정한 파라미터는 사용되지 않는다.

$ docker run -it --rm <image-name> Hello world $ docker run -it --rm <image-name> ME Hello ME $

shell form 으로 실행해야만 변수 등이 대체(substitution)된다.

FROM ubuntu ENTRYPOINT [ "echo", "$HOME" ]

$ docker run -it --rm <image-name> $HOME $

위처럼 exec form으로 사용하면 $HOME 이 그대로 사용되고, 아래처럼 shell form으로 사용하면 변수 등이 변환된다.

FROM ubuntu ENTRYPOINT echo $HOME

$ docker run -it --rm <image-name> /root $

CMD와 ENTRYPOINT의 조합은 ENTRYPOINT / CMD combinations에 표로 잘 정리되어 있다.

Dockerfile의 ADD 명령과 COPY 명령은 일반적인 복사 명령이다. 다만, 차이점이라면, ADD는 추가적 기능(?)이 더 있다:

URL을 복사할 source로 사용할 수 있다. remote에 있는 파일을 받아서 복사하게 된다.

source 파일이 gzip과 같이 일반적으로 잘 알려진 압축형태인 경우, 압축을 풀어준다.

압축된 remote 파일인 경우, 압축을 풀어주지는 않는다.

신기하다. :D

Google Translate(https://translate.google.com/)에는 친절하게도 읽어주는 기능(TTS)이 있다.

Play(https://playframework.com/)를 production 모드에서 실행하려면 application secret을 꼭 설정해 주어야 한다. 이 값을 세션 쿠키나 CSRF 토큰을 만드는 등 여러 암호화 작업에 사용된다고 한다.

application secret을 설정해 주지 않고 실행하면 이런 친절한 설명과 함께 실행되지 않는다.

[info] a.e.s.Slf4jLogger - Slf4jLogger started [info] a.r.Remoting - Starting remoting [info] a.r.Remoting - Remoting started; listening on addresses :[akka.tcp://[email protected]:2552] [info] a.c.Cluster(akka://application) - Cluster Node [akka.tcp://[email protected]:2552] - Starting up… [info] a.c.Cluster(akka://application) - Cluster Node [akka.tcp://[email protected]:2552] - Registered cluster JMX MBean [akka:type=Cluster] [info] a.c.Cluster(akka://application) - Cluster Node [akka.tcp://[email protected]:2552] - Started up successfully [error] p.a.l.c.CryptoConfigParser - The application secret has not been set, and we are in prod mode. Your application is not secure. [error] p.a.l.c.CryptoConfigParser - To set the application secret, please read http://playframework.com/documentation/latest/ApplicationSecret [error] p.a.l.c.CryptoConfigParser - The application secret has not been set, and we are in prod mode. Your application is not secure. [error] p.a.l.c.CryptoConfigParser - To set the application secret, please read http://playframework.com/documentation/latest/ApplicationSecret Oops, cannot start the server. @72eg7k97n: Configuration error    at play.api.libs.crypto.CryptoConfigParser.get$lzycompute(Crypto.scala:498)    at play.api.libs.crypto.CryptoConfigParser.get(Crypto.scala:465)    at play.api.libs.crypto.CryptoConfigParser.get(Crypto.scala:463)    at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)    at com.google.inject.internal.BoundProviderFactory.provision(BoundProviderFactory.java:72)    ( .. 생략 .. )

간단히 application.conf 파일에 아무 값이나 설정해 주면 된다.

play.crypto.secret=“This is my new super ultra extremely splendid shiny very very very strong and long secret key”

이렇게 application.conf 파일에 넣어 버리면 VCS에도 업로드 되니, 아래처럼 설정해 주고 실행할 때 마다 system environment variables로 넣어주는게 좋겠다.

play.crypto.secret=“changeme” # 사실 이건 play.jar의 resources.conf 안에 있기 때문에 없어도 된다. play.crypto.secret=${?APPLICATION_SECRET}

내부적으로는 “changeme”라는 설정이 resources.conf 파일에 default로 되어 있다. play.api.libs.crypto.CryptoConfigParser 소스를 열어보면, prod 모드로 실행할 때 play.crypto.secret 설정값이 “changeme”로 되어 있으면 에러를 뿜고 죽어버리게 되어 있다.

val secret = config.getDeprecated[Option[String]](“play.crypto.secret”, “application.secret”) match {  case (Some(“changeme”) | Some(Blank()) | None) if environment.mode == Mode.Prod =>    logger.error(“The application secret has not been set, and we are in prod mode. Your application is not secure.”)    logger.error(“To set the application secret, please read http://playframework.com/documentation/latest/ApplicationSecret”)    throw new PlayException(“Configuration error”, “Application secret not set”)  ( .. 생략 .. ) }

Docker container에 특정 IP를 할당해 줘야 하는 경우가 있다. docker run 실행 시 --ip 옵션으로 IP를 주면 된다.

$ docker run -it --rm --ip 10.10.10.10 my-image:v1 docker: Error response from daemon: User specified IP address is supported on user defined networks only.

역시. 한번에 되면 재미 없지.. IP를 할당해 주려면 container를 사용자 지정 네트웍에서 실행해 줘야 한다. 우선, 네트웍을 만들자.

mynet 이라는 이름으로 네트웍을 하나 만들자. create실행 시 -d 옵션으로 네트웍 드라이버를 선택할 수 있고, default는 bridge 이다. (Docker container networking 참고)

$ docker network create --gateway 172.19.0.1 --subnet 172.19.0.0/21 mynet 01674eb504f201c4c866ce9232455c9dc13e692b8c3a4d9a0323fd5bf849253b $ docker network ls NETWORK ID          NAME                DRIVER              SCOPE 74b9c320da82        bridge              bridge              local 4f2323a7701c        host                host                local 01674eb504f2        mynet               bridge              local 706556bf613d        none                null                local $ docker network inspect mynet [    {        "Name": "mynet",        "Id": "01674eb504f201c4c866ce9232455c9dc13e692b8c3a4d9a0323fd5bf849253b",        "Scope": "local",        "Driver": "bridge",        "EnableIPv6": false,        "IPAM": {            "Driver": "default",            "Options": {},            "Config": [                {                    "Subnet": "172.19.0.0/21",                    "Gateway": "172.19.0.1"                }            ]        },        "Internal": false,        "Containers": {},        "Options": {},        "Labels": {}    } ]

이제 새로 생성한 mynet 네트웍에 컨테이너를 만들고 돌려주자. 네트웍 대역에 맞춰서 IP도 주면 오케!!

$ docker run -it --rm --network mynet --ip 172.19.0.101 my-image:v1

메타포는 설명을 줄줄이 쓰지 않게 해주기 때문에 사용자 경험에서는 없어서는 안 될 요소이다. 전원버튼을 의미하는 이미지 대신 글씨로 설명을 주렁주렁 써놨다고 생각해 보자. 읽는 시간도 한참 걸릴뿐더러 그 많은 설명을 적을 공간도 없다.

여기서 잠깐. 많이 쓰이는 전원 아이콘의 의미는 0과 1을 합쳐서 그린 것이다. 컴퓨터에서 0(꺼짐, 없음)과 1(켜짐, 있음)을 뜻하는 2진수에서 온 내용이다.

그런데, 이 메타포는 만든 사람과 쓰는 사람의 공감대가 형성되지 않거나, 여러 메타포가 섞이는 경우 안 쓰니만 못 한 상황이 벌어질 수 있다.

마이크다. 왼쪽 버튼에 있는 메타포를 찾아보면,

- 사선이 그려진 마이크 - 음소거 - 초록불 - 커짐 - 빨간불 - 꺼짐

의미를 합쳐보면, 초록불은 음소거 기능이 켜짐, 빨간불은 음소거 기능이 꺼짐을 뜻할 것 같다. 그런데!! 아니었어!! 나만 이렇게 생각하는건가?? 이 마이크에 있는 불의 색깔은 음소거를 뜻하는게 아니라 마이크의 켜짐/꺼짐을 뜻하는거였다. 초록불이 마이크 켜짐, 빨간불이 마이크 꺼짐이다.

Typesafe’s config 에서는 다른 곳에서 설정해둔 값을 쉽게 재사용할 수 있다.

contact {   me {     name = ${my.name} # the value is evaluated to “ME”   }   you {     name =“YOU!!”   } } my {   name = “ME”   age = “secret” }

contact.me.name의 ${my.name}은 다른 곳에서 별도로 선언된 my.name의 값인 “ME”로 설정된다. 알고 나면 참 쉬운데, 모르면 알기 어렵다. @_@

Scala에는 동일한 클래스를 import할 수 없는 Java의 단점을 보완하고, 긴 클래스명을 내가 원하는 이름으로 바꿀 수 있는 기능이 있다.

import kr.leocat.test.{MyMeaninglesslyVeryLongClass => MyClass} val mine = new MyClass

이제, 겁나 긴 클래스명인 MyMeaninglesslyVeryLongClass를 짧게 MyClass로 쓸 수 있다.

Scala에는 Map, List 등의 클래스가 이미 만들어져 있다. 여기서 java.util.Map과 java.util.List를 쓰려면 클래스명이 충돌나지 않도록 이름을 바꿔줘야 한다.

import java.util.{Map => JMap, List => JList}

참, 쉽죠잉-??

docker-registry를 이용해서 local에 docker 이미지 배포가 필요할 때가 있다. (kubernetes를 연동한다던가..)

kubernetes는 이미지 위치만 설정해서 스스로 다운받기 때문에 다운받을 registry가 필요하다. docker-hub를 이용해도 되지만, 테스트 중일 때는 로컬이나 테스트서버가 편하니까..

docker-registry를 이용해서 local에 배포를 하면 아래 같은 에러가 발생하면서 실패하는 경우가 있다.

$ docker push 0.0.0.0:5000/hellonode:v1 The push refers to a repository [0.0.0.0:5000/hellonode] Get https://0.0.0.0:5000/v1/_ping: http: server gave HTTP response to HTTPS client

원인은 push 커맨드는 HTTPS로 진행되는데, 설치한 docker-registry가 HTTP만 지원해서 그렇다. push를 HTTP로 할 수 있도록 docker 설정을 변경해 주면 된다.

docker 설정을 열어서 “Insecure registries”에 HTTP로 사용할 registry 정보를 넣어주고, push push!!

MacOS 용이 아닌 다른 버전은 요기(https://docs.docker.com/registry/insecure/)를 참조.

kubernetes(http://kubernetes.io/)를 사용하려면 여러대의 master node와 slave node가 필요하다. local에서는 여러 node를 띄우기 어려우니 테스트하기 위해 single node로 사용할 수 있는 minikube라는 툴을 제공한다.

minikube는 Linux, MacOS, Windows 모든 OS를 지원하는데, VirtualBox나 VMware Fusion 등이 필요하다. 각 OS별 설치는 kubernetes 홈페이지나 github 페이지에서 확인하면 되고, 여기서는 MacOS 기준으로 설명한다.

아래 명령을 실행해서 minikube 커맨드를 받아 /usr/loca/bin 경로에 추가한다. /usr/loca/bin은 path가 잡혀 있으니 언제든 minikube 명령어를 실행할 수 있다.

$ curl -Lo kubectl http://storage.googleapis.com/kubernetes-release/release/v1.3.0/bin/darwin/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/

minikube start 명령으로 VirtualBox나 VMWare Fusion으로 실행하면 된다. 처음 실행할 때 minikube 이미지를 받아와서 설치하기 때문에 시간이 조금 걸린다.

$ minikube start Starting local Kubernetes cluster... Downloading Minikube ISO 36.00 MB / 36.00 MB [==============================================] 100.00% 0s Kubectl is now configured to use the cluster. $

kubernetes cli인 kubectl을 이용해서 실행 중인 kubernetes cluster 정보를 얻어올 수 있다. MacOS는 homebrew 등으로 kubectl을 간단히 설치할 수 있다.

$ brew update       ... $ brew install kubectl       ... $ kubectl cluster-info Kubernetes master is running at https://192.168.99.100:8443 KubeDNS is running at https://192.168.99.100:8443/api/v1/proxy/namespaces/kube-system/services/kube-dns kubernetes-dashboard is running at https://192.168.99.100:8443/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard $

kubernetes는 대부분 kubectl을 통해서 컨트롤하지만, 간단한건 UI를 통해서도 가능하다.

$ minikube dashboard Opening kubernetes dashboard in default browser... $

위 커맨드를 실행하면 브라우저로 아래와 같은 화면을 볼 수 있다.

Scala sbt에서 dependency를 추가할 때 아래처럼 써주면 된다.

libraryDependencies += "org.scala-tools" % "scala-stm_2.11.1" % "0.3"

그런데, 매번 scala 버전(여기서는 2.11.1)까지 써주기가 너무 불편하다. 또 scala 버전이 바뀌면 dependency 내용들을 다 바꿔줄 건가?? 이럴 때면 어김없이 등장하는 syntactic sugar!!

groupID와 artifactID 사이의 %를 %%로 써주면 scala 버전을 생략해도 자동으로 채워준다.

libraryDependencies += "org.scala-tools" %% "scala-stm" % "0.3"

하지만, 내가 사용해야 하는 scala 버전과 dependency의 버전이 다르다면 %%를 사용할 수 없다. T_T 그럴 때면 아쉽지만 아래처럼 별도 버전 기입을..

scalaVersion := "2.10.4" libraryDependencies += "org.scala-tools" % "scala-stm_2.11.1" % "0.3"

Typesafe’s Config는 Scala sbt처럼 라인단위로 실행이 되면서, 설정이 되는 형태의 config이다. (Maven처럼 선언적으로 설정하는 방식이 아니다.)

때문에, 하나의 key를 여러번 설정할 수도 있다. 아래 같이 설정하면, http.port의 값은 9090이 된다. (8080으로 설정된 다음, 다시 9090으로 덮어 써진다.)

http {   port=8080   port=9090 }

이 방법과 변수설정을 이용해서 default값을 설정할 수 있다.

http {   host=localhost   host=${?HTTP_HOST}   port=8080   port=${?HTTP_PORT} }

${VAR}와는 다르게 ${?VAR}는 변수에 설정된 값이 있는 경우에만 실행이 된다. java 명령 실행 시 -D 옵션으로 HTTP_PORT의 값을 주지 않는 경우 http.port는 8080이 되고, HTTP_PORT 값을 설정해 주면 다시 한번 덮어써져서 설정된 값으로 사용 가능하다. 시스템의 environment variables로 설정해 줘도 된다.

java -DHTTP_PORT=9090 MyClass java MyClass

Typesafe’s Config를 사용하는 프로젝트에서 시스템의 environment variable 이나 Java system properties를 사용할 수 있다. 아래처럼 ${VAR} 형식으로 써주면 된다.

http {   base-url=${BASE_URL}   port=8080 }

아래와 같이 java 명령의 -D옵션을 주거나, 시스템 환경변수를 넣어주면 된다.

java -DBASE_URL=myhost.com MyClass

${VAR}와 비슷하게 ${?VAR}를 사용할 수 있다. ${?VAR}는 해당 변수에 설정되어 있는 경우에만 실행이 된다. 아래처럼 설정되어 있을 때 -D옵션 등으로 HTTP_PORT 변수를 설정해 주지 않으면 http.port는 값이 없게 된다.

http {   port=${?HTTP_PORT} }

조심할 점은 아래처럼 “”안에 들어 있으면 치환되지 않으니 조심하자.

http {   base-url=“http://localhost:${HTTP_PORT}/some/path” }

개발 환경처럼 여럿이 사용하고 있는 Redis에 접속을 하다보면, 가끔 이런 메시지와 함께 접속이 불가능한 경우가 있다.

Caused by: redis.clients.jedis.exceptions.JedisDataException: ERR max number of clients reached    at redis.clients.jedis.Protocol.processError(Protocol.java:104) ~[jedis-2.4.2.jar:na]    at redis.clients.jedis.Protocol.process(Protocol.java:122) ~[jedis-2.4.2.jar:na]    at redis.clients.jedis.Protocol.read(Protocol.java:191) ~[jedis-2.4.2.jar:na]    at redis.clients.jedis.Connection.getRawObjectMultiBulkReply(Connection.java:221) ~[jedis-2.4.2.jar:na]    at redis.clients.jedis.Connection.getObjectMultiBulkReply(Connection.java:227) ~[jedis-2.4.2.jar:na]    at redis.clients.jedis.Jedis.sentinelGetMasterAddrByName(Jedis.java:2950) ~[jedis-2.4.2.jar:na]    at redis.clients.jedis.JedisSentinelPool.initSentinels(JedisSentinelPool.java:131) ~[jedis-2.4.2.jar:na]    at redis.clients.jedis.JedisSentinelPool.(JedisSentinelPool.java:73) ~[jedis-2.4.2.jar:na]    at redis.clients.jedis.JedisSentinelPool.(JedisSentinelPool.java:49) ~[jedis-2.4.2.jar:na]

이런.. 망.. 원인은 서버의 max client 개수 설정을 넘었기 때문인데, 실제 사용되지 않는 client 접속을 끊어주면 접속 가능하다. (sentinel을 사용하는 경우는 맨 아래에 따로 설명)

client list 명령(http://redis.io/commands/client-list)으로 접속된 client 목록을 확인할 수 있다. 간혹, 네트웍 문제인지 모르겠지만 연결이 끊어졌지만 접속되어 있는 것처럼 redis server가 목록을 가지고 있는 녀석들도 보인다. 확실히 끊어진 녀석들을 골라서 죽여주면 접속이 가능하다. client kill 명령(http://redis.io/commands/client-kill)을 쓰면 연결을 끊을 수 있다.

127.0.0.1:6379> client list id=3 addr=127.0.0.1:57288 fd=6 name= age=10 idle=10 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=client id=4 addr=127.0.0.1:57289 fd=7 name= age=3 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client id=5 addr=127.0.0.1:57290 fd=6 name= age=2 idle=2 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=info 127.0.0.1:6379> client kill addr 127.0.0.1:57288 (integer) 1 127.0.0.1:6379> client list id=4 addr=127.0.0.1:57289 fd=7 name= age=25 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client id=5 addr=127.0.0.1:57290 fd=6 name= age=2 idle=2 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=info 127.0.0.1:6379> client kill id 5 (integer) 1 127.0.0.1:6379> client list id=4 addr=127.0.0.1:57289 fd=7 name= age=54 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client

최근 삽질한건 Redis sentinel을 사용하는 경우!! sentinel을 사용하면 sentinel이 client 접속 컨트롤을 하기 때문에 sentinel에 죽은 client들이 붙어 있어서 접속이 안 되는 경우가 있다. SENTINEL client 명령으로 리스트 개수를 확인해 보고, sentinel에서도 제거해 주자.