세상의 모든 Software 지식을 정리

DataLoader클래스란? 데이터를 배치로 만드는 작업을 돕는 유틸 클래스로, 배치 데이터를 만드는 여러한 복잡한 작업을 추상화 한다. 해당 클래스는 파이토치의 utils 모듈에 위치한다. 또한 tochvision과 torchtext를 제공한다. 이 두 클래스는 이미지 분석과 자연어 처리를 다룰 때 사용한다.

도커 컨테이너마다 자체적으로 네트워크 스택을 갖추고 있다. 이는 리눅스 커널의 네트워크 네임스페이스를 통해 제공되는 곳으로, 컨테이너 마다 net 네임스페이스에 대한 인스턴스가 새로 생성되기 때문에 다른 컨테이너나 외부에는 드러나지 않고 해당 컨테이너 내부에서만 사용된다. 1. docker0 브릿지 docker0 브릿지는 도커 네트워킹에서 가장 기본적인 기능을 제공한다. 도커서비스가 구동할 때마다 호스트 머신에 리눅스 브릿지가 생성된다. 이렇게 생성된 브릿지는 컨테이너의 인터페이스를 통해 통신하며, 외부에 대한 프록시 역할도 한다.  한 호스트에서 구동하는 여러 컨테이너는 리눅스 브릿지를 통해 서로 통신한다. docker0는 네가지 모드를 제공하며, 다음과 같이 --net 플래그를 통해 설정한다. --net=default: 컨테이너 끼리 연결하기 위한 브릿지로 디폴트 브릿지를 사용한다. --net=nonde: 컨테이너를 완전히 격리된 형태로 구동하며 네트워크에 연결하지 않는다. --net=container:$container2: $container2라는 이름의 컨테이너에서 사용하는 네트워크 네임스페이스를 공유하도록 컨테이너를 생성한다. 1-1. 도커 브릿지 설정 관련 문제의 해결 방법 컨테이너 포트를 호스트의 포트와 매핑하는 방법을 살펴보고, 컨테이너를 외부와 연결할 때 발생할 수 있는 문제를 보자 두 컨테이너 모두 상대방에게 핑(ping)을 보낼 수 있을 뿐만 아니라 외부 네트워크에도 연결 할 수 있다. 외부와 연결하기 위해서는 컨테이너의 포트를 호스트의 포트와 매핑해야 한다. 앞서 설명한 바와 같이 컨테이너마다 네트워크 네임스페이스를 갖고 있다. 컨테이너가 생성될 때, 그 컨테이너에 대한 네트워크 네임스페이스도 새로 생성된다. 컨테이너와 리눅스 브릿지는 가상 이더넷(Virtual Ethernet)=veth 링크를 통해 연결한다. 컨테이너의 eth0 포트에서 보

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. 직렬화를 하는 경우는 삼가야 한다.