세상의 모든 Software 지식을 정리

1. 메모리 크기 레디스는 메모리에 데이터를 저장하기 때문에 레디스가 사용할 메모리의 크기를 지정하는것은 성능과 가장 밀접한 관련이 있다. 실제로 저장되는 데이터의 크기는 redisObject와 키가 저장된 크기를 뺀 나머지가 된다. 저장되는 데이터가 작은 크기의 문자열이라면 redisObject를 저장하기 위한 오버헤드가 더 크게 된다. 이럴 떄는 문자열을 숫자로 바꾸어 저장하거나, 다른 데이터형을 사용하면 더 많은 데이터를 저장할 수 있다. 만약 레디스에 저장될 데이터의 크기를 산정하지 못하여 redis.conf와 maxmemory 설정에 값을 지정할 수 없게 되었다고 하자. 그러면 레디스에 데이터가 계속 추가되어 물리 메모리를 모두 사용하게 된다. 이때 운영체제에서는 애플리케이션이 시스템에서 사용 가능한 물리 메모리 보다 더 많은 메모리를 사용하려고 할 때 스왑이라는 가상 메모리 공간을 하드디스크에 생성하여 사용하는데, 이 영역을 스왑공간이라 부른다. 이떄 스왑 공간이 충분하지 않으면 운영체제는 메모리에서 동작 중인 프로세스를 제거하여 사용가능한 메모리의 영역을 확보하게 된다. 이와 같이 동작 중인 프로세스를 죽이는 리눅스의 프로그램을  OOM킬러라고한다. 그러므로 OOM킬러를 피하려면 충분한 스왑공간을 확보해야한다. 그런데 데이터가 저장되기 시작하면 레디스의 응답시간은 수십 배에서 수백 배까지 늘어나게 된다. 만약 응답시간이 중요한 서비스라면 반드시 redis.conf의 maxmemory 설정에 설치된 물리 메모리 크기 이내의 값을 지정하여야 한다. 일반적으로 운영체제는 설치된 메모리 크기의 두 배를 스왑공간으로 할당한다. 여기서 말하는 두 배는 메모리가 충분하지 못했던 과거의 기준이다. 메모리의 가격이 저렴해지고 엔트리급 서버 시스템이 16GB이상의 메모리를 갖는 지금은 기준이 조금 달라졌다. 레드햇 엔터프라이즈의 가상 메모리 설정 가이드 문서에 따르면 시스템에 설치된 물리 메모리의 크기에 따라서 다른 값을 ...

레디스에 스케일 아웃을 처리하기 위한 방법으로 두 가지 기법을 제공한다. 읽기분산을 위한 복제(Replication)와 쓰기 분산을 위한 샤딩(Sharding)이 이에 해당된다. 1. 복제 복제는 동일한 데이터를 다중의 노드에 중복하여 저장하는 것을 말한다. 레디스는 복제를 위해 마스터와 슬레이브의 복제의 개념을 사용한다. 마스터는 복제를 위한 데이터의 원본 역할을 한다. 슬레이브는 마스터 노드에 데이터 복제 요청을 하고 데이터를 수신하여 데이터를 동기화 한다. 통상적으로 레디스 인스턴스 하나가 처리할 수 있는 TPS는 1만~2만이다. 또한 대부분의 레디스 명령은 읽기와 쓰기에 따른 성능편차가 없다. 복제는 슬레이브 노드가 마스터 노드의 데이터를 실시간으로 복제하여 데이터의 동기화를 유지한다. 슬레이브 노드가 시작할 때 마스터 노드에게 복제를 요청하고 최초 복제가 완료된 이후는 변경 사항만 업데이트 한다. 레디스의 복제는 마스터노드가 슬레이브노드의 정보를 가지지 않고, 슬레이브 노드가 마스터 노드의 위치만 알고있으면 복제를 할 수 있다. 1-1. 단일 복제 마스터노드와 슬레이브 노드 하나로 구성된다. 마스터 노드에 변경이 발생하면 실시간으로 슬레이브 노드에 데이터 변경사항이 기록된다. 하지만 슬레이브 노드에 변경이 발생하면 마스터 노드는 해당 변경 사항을 감지하지 못한다. 슬레이브 노드에서 데이터 변경이 일어나는 순간 데이터의 정합성이 무너지게 되므로 슬레이브 노드에서는 데이터의 변경을 수행하지 않아야 한다. 1-2. 다중 복제 단일 복제만으로는 필요한 읽기 성능을 만족하지 못할때 다중 복제를 고려할 수 있다. 단일 복제 구조의 클러스터에 슬레이브 노드를 추가하기 위해서는 마스터 노드의 위치정보를 슬레이브 노드에 설정하고 인스턴스를 실행하면 노드 추가가 완료된다. 이와 같이 단일 복제 상태에서 여러 대의 슬레이브 노드를 추가한 것을 다중 복제라고 한다. 마스터 노드의 재시작이 필요하지 않다. ...

<IOC 컨테이너를 통해 애플리케이션이 만들어지는 방식> 결국 스프링 애플리케이션이란, POJO클래스와 설정 메타정보를 이용해 IOC 컨테이너가 만들어주는 오브젝트의 조합이다. RootBeanDefinition을 보면 bean클래스가 private volatile Object beanClass; 로 되어있는 것을 볼 수 있다. 이는 volatile을 선언하게 되면 cpu cache에 해당 값을 저장하는 과정 없이 오직  MainMemory에서 값을 읽고, 쓰는 과정을 거친다. 즉, 멀티쓰레드에서 한개의 쓰레드가 read&write를 하더라도 다른 쓰레드에서 읽기를 하는 경우 값이 변하더라도 항상 일관된 값을 유지하게 해준다.

람다를 왜 JDK 1.1에서는 함수객체를 만드는 주요 수단은 익명 클래스였다. 그러나 익명클래스 방식은 코드가 너무 길어 자바는 함수형 프로그래밍에 적합하지 않았다. 결국 이러한 문제로 이를 람다로 교체됨 (더욱 간결하게 표현할 수 있음) 람다는 이름이 없고 문서화도 못 한다. 따라서 코드 자체로 동작이 명확히 설명되지 않거나 코드 줄 수가 많아지면 람다를 쓰지 말아야 한다. 람다는 한 줄일때 가장 좋고 길어야 세 줄안에 끝내는게 가장 좋다. 세 줄을 넘어가면 가독성이 심하게 나빠진다. 람다의 시대가 열리며 익명클래스 -> 람다로 대체 되었지만, 람다는 함수형 인터페이스에서만 쓰인다. 예컨대 추상클래스의 인스턴스를 만들 때 람다를 쓸 수 없으니, 익명 클래스를 써여한다. 마지막으로 람다는 자신을 참조할 수 없다. this키워드는 바깥 인스턴스를 가르킨다. 람다를 직렬화하는 일은 극히 삼가야한다. 정리: 함수객체를 구현하기 위해 익명클래스를 도입, 그러나 코드가 길어지는 단점이 존재하여 이를 람다로 대체하기 시작함 그러나 람다를 사용하지 못하는 경우가 있는데 1. 자기 자신을 참조하는 this를 사용하는 경우 2. 코드길이가 너무 길어지는 경우 오히려 문서화를 할 수 없음 3. 직렬화를 하는 경우는 삼가야 한다.

version: '2.2' services:   elasticsearch:     image: docker.elastic.co/elasticsearch/elasticsearch:6.2.1     container_name: elasticsearch     hostname: elasticsearch     environment:       - cluster.name=docker-cluster       - bootstrap.memory_lock=true       - "ES_JAVA_OPTS=-Xms512m -Xmx512m"     ulimits:       memlock:         soft: -1         hard: -1     volumes:       - esdata1:/usr/share/elasticsearch/data     ports:       - 9200:9200     logstash:     image: docker.elastic.co/logstash/logstash:6.2.1     container_name: logstash     hostname: logstash     environment:       - "LS_JAVA_OPTS=-Xms512m -Xmx512m"     ports:       - 9600:9600     volumes: ...

리플리카컨트롤러, 리플리케이션셋, 디플로이먼트는 모두 상태가 없는(stateless) 포드들을 관리하는 용도 였습니다. 스테이트풀셋(StatefulSets)은 단어의 의미 그대로 상태를 가지고 있는 포드들을 관리하는 컨트롤러 입니다. 스테이트풀셋을 사용하면 볼륨을 사용해서 특정 데이터를 기록해두고 그걸 포드가 재시작했을때도 유지할 수 있습니다. 여러개의 포드를 띄울때 포드 사이에 순서를 지정해서 지정된 순서대로 포드가  실행되게 할수도 있습니다. 이런식으로 어떠한 상태를 가지고 있어야 할때 사용하는게 스테이트풀 셋입니다.

둘의 차이는 Pod는 단순히 Pod만 생성하는 것이지만 Deployment는 Pod를 생성할 때, 실패하는 경우를 감시하고 만약 특정한 숫자 이상의 포드를 생성하라고 명령한 경우는 그 숫자가 될 때까지 지속적으로 pod를 생성하게한다.  If you don’t want a Deployment to monitor your pod (e.g. your pod is writing non-persistent data which won’t survive a restart, or your pod is intended to be very short-lived), you can create a pod directly with the create command.