c10k 문제..

참고 : http://www.kegel.com/c10k.html , https://en.wikipedia.org/wiki/Continuation , https://en.wikipedia.org/wiki/Green_threads , https://en.wikipedia.org/wiki/State_machine_replication , https://en.wikipedia.org/wiki/VxD , http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ , http://stackoverflow.com/questions/5635362/max-thread-per-process-in-linux , http://www.lowtek.com/sockets/select.html , https://en.wikipedia.org/wiki/Zero-copy

머신의 성능이 충분해진 시대에 10000개의 클라이언트에 어떻게 서비스를 제공할 것인가에 대한 질문에서 출발한 이야기인데.. 참고 사이트는 사실 꽤 오래전 이야기에 시스템 레벨에서의 I/O최적화에 대한 히스토리를 주로 모아뒀고 OS나 서버사이드 어플리케이션들에 오랬동안 논의 되었던 해결책들이 하나둘씩 적용되고 있으며 또한 이미 사용되고 있다.

요즘같이 스케일아웃 솔루션들이 잘 나와있는 시대에는 별 의미 없는 이야기 일 것 같아 보이기도 하지만 전체 시스템의 I/O 응답성을 높이기 위해 한번쯤 생각해 볼만한 주제인 것 같아 간단히 정리해 보기로 하였다.

I/O 전략

네트워킹 소프트웨어 디자이너를 위한 몇가지 옵션들..

• 단일 쓰레드에서 다중 I/O 호출 발행 여부와 어떻게 발행할 것인지에 대해
• 다중 쓰레드나 동시성을 얻을 수 있는 프로세스를 사용할 수 있는 곳에 블러킹/동기식 호출 사용하지 않기.
• I/O 시작에 넌블러킹 호출을 사용하고 해당 채널에서 다음 I/O를 시작할 준비가 되었음을 알 수 있는 준비 알림 사용하기. 일반적으로 디스크 I/O가 아닌 네트워크 I/O에 유효함.
• I/O 시작에 비동기 호출을 사용하고 I/O가 끝났을 때 완료 알림 사용하기. 네트워크와 디스크 I/O 모두에 유효함.
• 개별 클라이언트에 대해 서비스를 어떻게 제어할 것인지에 대해
• 각각의 클라이언트에 하나의 프로세스 할당(고전적인 유닉스 접근방식, fork()와 같은..)
• 단일 OS 레벨 쓰레드가 다수의 클라이언트에 서비스를 제공하는 경우. 각 클라이언트는 다음에 의해 컨트롤 됨
• 사용자 레벨 쓰레드(GNU 상태 쓰레드나 Green 쓰레드를 사용하는 Java) - Green 쓰레드는 커널 레벨이 아닌 VM 레벨에서 동작하며 단일 코어 CPU를 사용할때 유효한 방식이라 JVM 1.3 이후에는 사용되지 않고 있습니다.
• 상태 머신 - 복제된 다수의 서버를 이용한 분산 시스템
• 컨티뉴에이션 - 최근 유행하기 시작한 펑셔널프로그래밍의 비동기 프로그래밍 기법
• 각각의 클라이언트에 하나의 OS 레벨 쓰레드 할당(네이티브 쓰레드를 사용하는 Java)
• 각각의 활성 상태의 클라이언트에 OS 레벨 쓰레드 할당(아파치 프론트엔드와 함께 Tomcat을 사용하거나 NT의 I/O completion port나 쓰레드풀을 사용)
• 표준 커널 서비스를 사용하거나 일부 코드를 커널에 포함시키는 방법(커스텀 드라이버, 커널 모듈 혹은 VxD - Virtual xxx Driver)

인기있어 보이는 몇가지 조합

쓰레드별로 다수의 클라이언트를 처리하며 넌블러킹 I/O와 함께 참조할 파일 디스크립터의 대기 상태를 select()나 poll()을 이용해 물어 처리(level triggered)하는 방식이 있는데 디스크 I/O가 블러킹 모드를 사용할 경우 병목이 발생할 수 있다.

파일 디스크립터의 대기 상태 변화시 알림을 받는 형태(edge triggered)로 처리하는 방법 있으며 프로그래밍 실수에 대해 관대하지 않은 방식이라 이벤트를 하나라도 놓친다면 해당 연결은 영원히 멈춘 상태가 될 수 있다.

비동기 I/O를 사용하는 경우는 큐를 이용한 신호(보통 유니크한 키값)와 값을 전달 하는 방식이며 기본적인 동작 방식은 작업이 완료된 상태 알림(edge triggered)을 받으면 큐에 담아 전달하는 형태이다.

클라이언트당 쓰레드를 할당하여 서비스를 하는 경우는 쓰레드당 사용되는 스택사이즈에 신경을 써야 하는데 메모리 비용의 문제가 발생할 수 있는 방식이다.

파일핸들러에서의 최대로 열 수 있는 파일수의 제약

최대로 열 수 있는 파일수의 제약이 있기 때문에 이런 제약에 걸린다면 OS의 설정 파일을 손봐야 할수도 있다. 리눅스의 경우 cat /proc/sys/fs/file-max를 이용해 값을 확인 할 수 있다.

쓰레드상의 제약

가상메모리를 소진시키지 않기 위해선 쓰레드당 할당된 스택의 크기에 주의할 필요가 있으다. 프로세스당 최대 쓰레드의 수가 제한되어 있으며 기본값은 시스템 메모리 크기에 따라 자동으로 계산 되며 런타임에 변경 가능하다. 리눅스의 경우 cat /proc/sys/kernel/thread-max를 이용해 값을 확인 할 수 있다. 시스템에서 쓰레드당 할당되는 메모리 묶음의 크기는 cat /proc/sys/vm/max_map_count를 이용해 확인할 수 있다. 해당 값들을 변경하게 될 경우 메모리 파편화와 오버커밋도 고려해야 하는 문제가 있다.

Java와 관련한 이슈

NIO에서 넌블러킹 I/O를 지원하고 있으니 일부 제약이 있긴 하지만 NIO를 사용할 수 있다면 사용하길 추천한다.

다른 팁들

• Zero-copy 이용하기 - CPU의 복사 시간에 낭비되는 자원을 줄여 네트웍의 효율을 높이는 방법이다. HSA 같은경우 CPU와 GPU간에 포인터를 전달할 수도 있다.
• 네트웍에서 부분 프레임만 지속적으로 보내는 상황 피하기.
• 과부하 상황에 재치있게 행동하기 - 과부하 상황에서 유입되는 접속수를 낮춤으로 퍼포먼스 양상을 개선하고 전체적인 에러율을 낮추는 방법을 선택할 수도 있다. 요즘은 유연하게 스케일 아웃을 할 수 있는 방향으로 가고 있다.
• 쓰레드별 워킹 디렉토리를 갖는 비 POSIX 쓰레드를 사용할 수 있다. FTP서버에서 이점이..
• 프로세스가 아닌 어플리케이션 레벨의 캐싱.

원문에서는 좀더 상세한 내용을 다루고 있으니 관심있는 분들은 원문을 참고하길 바라며 일부 링크의 경우는 세월이 많이 흘러 유실된 경우가 있지만 관련 자료들은 대부분 검색을 통해 확인할 수 있으니 참고하시길 바라며..

5월 3주차 소식들..

보안

TeslaCrypt 랜섬웨어의 제작자가 마스터키를 공개해서 무료로 감염된 장비를 치료할 수 있게 되었다는 소식.. 링크 링크

Gmail의 RC4와 SSLv3 지원 중단에 대한 소식.. 6월 16일 부터 적용되며 더이상 해당 프로토콜을 이용한 메시지를 주고받을 수 없게 된다고.. 링크

2012년에 유출 된 링크드인 계정정보가 거래되고 있는 것 같다는 소식이.. 2012년 이후로 비밀번호를 변경하지 않은 사람은 변경을 권장하고 2단계 인증을 사용하길 추천한다고.. 자신의 계정 정보가 유출 됐는지 확인할 수 있는 사이트 주소도 첨부.. 링크 링크

브라우저에서 검색엔진의 검색 결과를 변형 시켜 클릭 시 제작자에게 광고 수익이 돌아가게 하는 Redirect.Paco라는 멀웨어 소식.. WinRAR, Connectify, YouTube Downloader Stardock Star8이나 KMSPico같은 익숙한 프로그램의 인스톨러를 변형해서 배포되는 케이스가 있다고.. 원본 바이너리를 제공하는 곳도 털리는 경우가 있는데 미심쩍은 곳에서 뭔가 받아서 설치하는건 더 주의해야 할듯한... 작동 원리는 기본적으로 프록시 설정을 변경 시키는 형태라 네트워크 지연을 유발하고 브라우저 상태바에 프록시와 관련한 메시지를 노출하는 특징이 있다고.. 링크

CryptXXX 2.0 랜섬웨어 크랙인 RannohDecryptor소식.. 랜섬웨어도 계속해서 버전업 되기 때문에 한시적이긴 한.. 링크 링크

하드웨어

구글의 머신러닝용 프로세서인 TPU(Tensor Processing Unit)에 대한 소식.. 머신러닝용 플렛폼인 TensorFlow에 사용될 칩인데 좀더 효율적이면서 빠른 처리를 위해 자체칩을 개발 했다고 하며 범용 컴퓨팅 유닛인 GPU를 대체할 목적이며 앞으로도 특수 목적용 칩을 계속해서 개발할 예정이라고. 외부에 판매할 계획은 없다는 걸로 봐서 클라우드 서비스에 가속 기능을 추가하는 방향으로 가지 않을까 싶은.. FPGA의 경우 처리 속도의 문제 때문에 이런 방향을 택했다고 하는데 MS의 경우는 머신러닝용 FPGA를 개발하는 방향으로 진행 중이라고. nVIDIA 같은 경우 이런 변화에 직접적인 영향을 많이 받을 가능성이 높아 보이고 AMD같은 경우 특수목적용 블럭의 IP를 라이선싱 하는 형태로 사업 방향을 바꾸는 중인데 이런 흐름을 미리 읽고 사업 구조를 변화시킨듯 싶음.. 링크

소프트웨어

구글 I/O 소식.. 몇년 전부터 크롬OS와 안드로이드가 통합되면서 크롬OS가 사라질 것이라는 예측이 있었는데 서로의 기능을 주고 받으면서 당장 어느 하나가 사라질 것 같진 않다는 이야기가.. 재부팅이 필요없는 리눅스의 라이브 업데이트 기능이 크롬OS에는 적용되어 있었는데 안드로이드N에 적용 될 예정이고 크롬OS에 플레이스토어 기능이 들어오는게 눈에 띄는 변화인듯.. 링크

오픈소스 오케스트레이션 툴 특징

참고 : https://www.oreilly.com/ideas/swarm-v-fleet-v-kubernetes-v-mesos?cmp=tw-webops-free-lp-promo_swarm_v_fleet_v_kubernetes_v_mesos_article , http://stackoverflow.com/questions/27640633/docker-swarm-kubernetes-mesos-core-os-fleet

DevOps라는 단어의 대두와 함께 소프트웨어의 개발 뿐만 아니라 서비스의 운영이 개발 프로세스에서 중요한 비중을 차지하게 됨에 따라 다양한 클라우드 인프라 오케스트레이션 툴들이 나오게 됐는데 크게 Docker 이전의 경우 상용툴로 Chef와 Puppet 이후는 Swarm, Fleet, Kubernetes 그리고 Mesos를 들 수 있을것이다.

사실 이런 툴들이 없는 전통적인 방식의 개발, 운영 시스템에 DevOps를 해야 한다면 가혹한 환경에 놓이게 될 가능성이 매우 높겠지만 이런 툴들은 언제든지 새로운 소프트웨어를 제공 할 수 있는(Continuous Delivery)환경을 만드는데 도움을 주고 있는 것 처럼 보인다.

기존의 인프라는 머신 각각에 대해 신경을 썼다면 새로운 툴들은 시스템은 언제든 문제를 일으킬 수 있다고 보고 문제가 발생한 요소를 제거하고 새로운 백업 시스템으로 교체하는 형태로 발상의 전환이 이루어진 점이 특징이라고 볼 수 있다. 물론 오케스트레이션 툴을 이용하기 위해선 기존의 어플리케이션의 설계도 맞춰서 바뀌어야 하겠지만...

오케스트레이션 툴을 통한 제로 다운 타임, 자동 장애 복구, 서비스 확장을 위한 사전 프로비저닝 된 지원 시스템 그리고 보편화 된 서로 다른 데이터센터와 지역에서의 서비스 운영이 가능해진 시스템은 전통적인 시스템과는 달리 매우 매력적으로 보이지만 각 툴에 대한 충분한 이해가 필요하다는 것을 간과해서는 안된다.

다음은 각 툴을 선택할 때 고려할만한 특징에 대해서 간략히 정리해 보았으며 컨테이너(Docker와 같은..)를 스캐줄링 할 것인지 머신(EC2 인스턴스와 같은..)을 스케줄링 할 것인지와 같은 차이가 있으며 내용은 다음과 같다.

Swarm

Docker의 표준 API를 사용하는 툴로 기존에 Docker Compose와 같은 스크립트를 이용하는 환경이라면 상대적으로 적은 리소스를 투입하여 통합할 수 있지만 복잡한 스케줄링을 위한 커스텀 인터페이스 정의가 어려워 질 수 있다. 주요 구성요소로 머신에 설치되어 컨테이너를 스케줄링 하기 위한 매니저와 에이전트가 있다.

Fleet

CoreOS의 클러스터 관리 툴로 Kubernetes와 같이 추상화 단계가 높은 툴과 비교해 로우레벨 클러스터 엔진으로 분류되며 리눅스의 init을 대체하기 위해 나온 systemd위에서 동작하는 툴이다. Fleet은 단순한 레이어를 갖으며 Kubernetes와 같은 상위 레이어의 툴의 베이스가 될 수 있다. 머신간의 통신은 Etcd를 통해 이루어지며 장애에 유연하게 대처할 수 있도록 디자인 되었다. 만약 머신중 하나가 죽는다면 해당 머신에서 스케줄링 되던 유닛(컨테이너와 같은..)은 새 머신에서 재시작 할 수 있다. 네트워크 소켓을 통해 즉각적인 컨테이너 구동이 가능하다는 장점을 가지고 있다.

Kubernetes

구글의 서비스는 모두 컨테이너 기반으로 제공되고 있으며 이것을 가능하게 하는 것이 Borg인데 Kubernetes는 구글에서 Borg를 오픈소스로 공개한 대규모 컨테이너 시스템을 스케줄링 하기 위한 툴이다. Kubernetes는 몇가지 추상화된 개념들을 제공하며 서비스 추가나 복제와 같은 확장성을 제공하고 장애에 유연한 대처가 가능한 강력한 툴이지만 어플리케이션이 이를 충족시키기 위해 재 디자인 되어야 한다. Kubernetes가 제공하는 강력한 기능이 궁금하다면 링크의 영상을 보길 추천한다.

Mesos 

아파치의 Mesos는 수백에서 수천개의 머신으로 구성된 대규모 클러스터 관리를 위해 개발 되었으며 Twitter, eBay 그리고 Airbnb와 같은 회사들이 사용하고 있다. 대규모 클러스터 구성을 기본으로 하다보니 다수의 사용자에 대한 워크로드를 지원하는 것이 특징이며 Fleet과 같이 로우 레벨 클러스터 엔진으로 분류되며 스케줄러로 Marathon, Kubernetes 그리고 Swarm과 같은 툴을 이용할 수 있다. 12개 이하의 머신 노드를 이용하는 경우라면 필요 이상으로 복잡한 솔루션이 될 수 있다.

5월 2주차 소식들..

보안

7-zip의 사용자의 권한을 취득할 수 있는 결함이 발견되어 16.00의 패치가 나왔다는 소식.. 링크

플레시 플레이어의 보안패치 소식.. 개인적으로는 사용안한지 꽤 되었지만.. 윈도와 맥은 21.0.0.242 리눅스는 11.2.202.621로 업데이트를 권장한다고.. 링크

Jenkins의 보안 패치로인해 플러그인의 파라메터 전달방식이 변경되어 플러그인들이 정상적으로 동작하지 않는 문제가 있다고.. 현재 권장되는 버전은 2.3과 LTS 1.651.2인데 보안 위협에 노출 되기는 하지만 기존 방식을 유지하는 hudson.model.ParametersAction.keepUndefinedParameters 프로퍼티에 true를 사용하거나 hudson.model.ParametersAction.safeParameters 프로퍼티에 화이트리스트 파라메터를 지정할 수 있다고.. 링크

하드웨어

웨스턴디지털의 샌디스크 인수소식.. 조만간 WD 브랜드의 SSD와 메모리스틱 들을 보게 될듯한.. 링크

소프트웨어

OS X El Capitan 10.11.4 업데이트에서 프리징 현상을 겪는 사용자가 많다는 소식.. 나만 그러는줄 알았더니 아니었.... 2015년 전반기에 발매된 13인치 레티나 맥북프로가 유독 문제가 잦은 편이라고.. 링크

파이어폭스의 테스트파일럿 프로그램에 대한 소식.. 파이어폭스에서 제공하는 시험적인 기능들을 사용해 볼수 있으며 관심 있는 분들은 다음의 링크를 참고하시면 됩니다.. 링크

Debian 프로젝트의 32-bit 구형 x86 CPU의 지원 중단 소식.. i386부터 586/686 하이브리드 타입까지가 대상이며 커널 4.3부터 686 프로세서 부터 지원하도록 변경되기 때문에 중단 대상에 포함되는 시스템을 사용중이라면 안정버전인 Jessie를 사용하라는 소식.. 링크

5월 1주차 소식들..

소프트웨어

리눅스 커널의 네트웍과 관련하여 과도한 패킷 버퍼링으로 인해 응답시간 지연과 대역폭 저하를 유발하는 Bufferbloat문제 해결을 위한 추가 패치가 커널 4.7에 포함되었다는 소식.. 안정버전 커널에도 백포트 될 것으로 보인다고.. 링크

보안

이미지 처리용 툴인 ImageMagick의 보안 결함에 대한 소식.. 특별히 제작된 이미지를 이용한 해킹 방법에 대해 정리된 ImageTragick이라는 사이트도 나온 상태이지만 패치는 아직 안된 상태이고 정책 파일을 통해 문제를 임시적으로 막는 방법까진 나온 상태.. 해당 라이브러리를 사용하는 웹 플러그인 중에 대표적인 것으로 PHP imagick, Ruby rmagick, nodejs imagemagick이 있다고.. 링크 링크

OpenSSL의 패치 소식.. 1.0.2h와 1.0.1t 버전이 나왔는데 낮은 위험의 버그들을 조합해서 좀더 큰 버그를 만들어내는 케이스가 발견되어 다수의 버그 패치가 이루어 졌다고.. 링크

SHA-1 암호화 방식의 인증 시스템의 취약성 때문에 브라우저 제작사들이 SHA-1 방식을 이용하는 사이트는 차단할 예정인데 MS의 경우 Windows 10 1주년 기념 업데이트부터 IE11과 Edge에서 SHA-1 방식을 이용하는 사이트는 더이상 자물쇠 아이콘이 나타나지 않고 내년 2월부터는 차단할 예정이라고. 구글과 모질라는 이보다 빠른 올해 7월부터 차단에 들어갈 것으로 보인다는 소식.. 링크

Spring Transaction의 Propagation과 Isolation에 대해..

참고 : http://stackoverflow.com/questions/8490852/spring-transactional-isolation-propagation , http://www.byteslounge.com/tutorials/spring-transaction-propagation-tutorial , http://www.byteslounge.com/tutorials/spring-transaction-isolation-tutorial

헷갈릴 땐 라이브러리의 소스코드의 각 타입별 주석을 참고해도 되지만 이참에 정리하자 싶어서 작성합니다. Transactional 어노테이션의 propagation과 isolation 항목에 대한 설정 정보에 대해 알아보도록 하겠습니다.

PROPAGATION

비지니스 메소드가 호출될 때 자기 자신과 내부에서 호출 된 Transaction(이하 tx)간에 어떻게 상호 작용할 것인지에 대한 상태를 정의 하는 항목으로 다음과 같은 설정들이 존재 합니다.

• REQUIRED : 해당 상태가 선언된 메소드가 실행 될 때 tx가 존재 한다면 공유해서 사용하고 그렇지 않다면 새 tx를 생성해서 사용합니다. 만약 내부에서 호출 된 메소드가 자신과 마찬가지로 REQUIRED가 선언된 상태라면 자신과 내부 tx각각은 논리적으로는 구분 되지만 물리적으로는 하나의 tx가 됩니다. 내부에서 호출 된 메소드의 tx가 롤백 된다면 자신을 포함한 물리적인 하나의 tx가 롤백 되는 구조를 만들 수 있습니다.
• REQUIRES_NEW : 해당 상태가 선언된 메소드가 실행될 때 항상 새로운 물리적인 tx를 생성하고 해당 tx가 롤백 된다고해서 물리적으로 분리된 다른 tx가 롤백 되지는 않습니다. 만약 내부적으로 새로운 tx가 시작 된다면 자신의 tx는 잠시 정지 되었다가 내부 tx가 종료된 시점에 이어서 수행되게 됩니다.
• NESTED : 자신과 내부 tx들이 하나의 물리적인 tx를 사용하지만 내부에서 호출된 NESTED tx들에 savepoint를 세팅하는 형태 입니다. 그렇기 때문에 내부의 NESTED tx중 하나가 롤백이 된다고 하더라도 자신이 롤백 되지는 않습니다. 이 기능은 JDBC savepoint를 통해 구현되기 때문에 Spring JDBC로 관리되는 tx를 사용할때만 써야 합니다.
• MANDATORY : 해당 상태가 호출될 때 열려있는 tx가 반드시 존재해야하며 그렇지 않으면 컨테이너에서 예외를 던집니다.
• NEVER : 해당 상태가 호출될 때 열려있는 tx가 반드시 존재하지 않아야 하며 그렇지 않으면 컨테이너에서 예외를 던집니다.
• NOT_SUPPORTED : 해당 상태는 tx의 범위에 포함되지 않는 것을 수행합니다. 만약 열려있는 tx가 존재 한다면 해당 tx를 잠시 멈추고 작업을 수행합니다.
• SUPPORTS : 열려있는 tx가 이미 존재한다면 해당 tx에 포함되어 수행되며 만약 열려있는 tx가 존재하지 않더라도 수행은 되지만 tx와 관계없이 처리 됩니다.

주의할 점들..

• 기본적으로 tx을 롤백 상태로 만들기 위해서는 unchecked exceptions를 필요로 하며 checked exceptions를 이용하기 위해서는 별도의 설정이 필요합니다.
• Transactional 어노테이션만 선언된 메소드(Declarative transactions)에서 동일한 Bean 내부의 다른 메소드를 직접 호출할 경우(Self-invocation) 컨테이너에 의해 Transactional 선언이 무시되기 때문에 이경우는 aspectj를 사용해서 구성해야 합니다.

ISOLATION

ACID tx 요소 중 isolation 레벨에 대한 설정으로 특정 위치의 데이터에 대해 동시 다수의 tx가 존재 할 때 해당 데이터에 어떻게 접근할 것인지에 대해 정의할 수 있습니다.

• READ_UNCOMMITTED : 여러 tx가 동시에 x라는 데이터에 접근 할 때 x에 변경이 일어난 시점과 읽는 시점에 따라 롤백 여부와 상관없이 변경된 값을 읽는 더티 리드(dirty reads)를 허용하는 상태입니다.
• READ_COMMITTED : 더티 리드의 문제는 없지만 동시에 x라는 데이터에 접근할 때 타임라인 상 A라는 tx에서 x를 읽은 후 tx가 종료 되기 전에 B라는 tx에서 x를 변경후 커밋을 하게 될 경우 A에서 x를 다시 읽는 케이스가 존재 한다면 처음 읽은 x의 값과 나중에 읽은 x의 값이 다른 문제(non-repeatable reads)가 발생하게 됩니다.
• REPEATABLE_READ : 하나의 tx에서 단일 레코드를 여러번 읽는 경우 결과가 항상 같아야 하는 상태이며 dirty reads와 non-repeatable reads 문제를 제거할 수 있습니다. 하지만 범위 스캔을 하는 경우 tx A에서 범위의 조건이 0-20 사이의 값을 읽고 tx A가 종료되기 전에 tx B에서 0-20사이에 레코드를 추가하게 된다면 tx A에서 0-20 사이의 값을 다시 읽었을 때 tx B에서 추가한 레코드(phantom records)가 포함되는 팬텀 리드(phantom reads)의 문제가 있습니다.
• SERIALIZABLE : 가장 제한적인 상태이며 읽기, 범위 스캔, 쓰기에 tx락을 거는 형태입니다. 앞서 언급한 모든 문제를 해결할 수 있지만 tx의 동시성을 허용하지 않아 퍼포먼스 패널티를 지속적으로 증가시키는 문제가 있습니다.
• DEFAULT : DBMS에서 정의된 Default Isolation 레벨에 대한 상태를 적용합니다.

각 isolation 레벨이 갖는 문제를 요약하면 다음과 같습니다.

• READ_UNCOMMITTED : dirty reads, non-repeatable reads, phantom reads
• READ_COMMITTED : non-repeatable reads, phantom reads
• REPEATABLE_READ : phantom reads

4월 4주차 소식들..

보안

인기있는 업무용 메신저인 Slack의 보안 토큰을 Github과 같은 공개된 저장소에 올려서 보안위험에 노출된 경우가 많아 Slack측에서 발견된 토큰을 폐기하고 발행자와 관련 팀 담당자에게 연락을 하고 있다고.. 주로 봇 통합 용도로 많이 사용된 것 같다는데 보안 토큰을 공개된 장소에 공유하는 건 좀.. 음.... 링크

소프트웨어

Node.js 의 6.0 버전 소식.. 5.0과 다르게 10월부터 LTS 지원을 할 예정이라고.. 추가로 ECMAScript 2015 지원 정보 챠트.. 링크 링크

Linux의 /dev/random LRNG 패치에 대한 이야기.. 기존 방식과 차이점으로 가상화 환경이나 SSD를 사용하는 환경에서도 부트 타임에 충분한 엔트로피를 제공하고 대규모 병렬 시스템에서 엔트로피 수집에 대한 충격을 제한하며 /dev/urandom과 get_random_bytes에서의 큰 성능 향상등이 고려되고 있다고.. 링크
 
Nginx 1.10 Stable 버전이 발표 되었다는 소식.. 스트림 모듈, HTTP/2, 다이나믹 모듈 지원등이 특징이라고.. 링크


기타

특허 트롤에 대응하기 위한 시스템에 대한 소식.. 미국의 발행되거나 출판된 특허에 대한 공개정보를 마이닝 해서 앞으로 나올만한 가능성이 있는 특허 정보를 조합해서 사전에 공개하는 All Prior Art 라는 시스템에 대한 이야기가.. 링크 링크

하드웨어

구글 OnHub 라우터의 IFTTT 지원 소식.. IoT와 홈오토메이션의 중심이 되지 않을까 추측은 했었는데 IFTTT를 지원하게 될 줄은... 영상 링크를 보는편이 어떤게 가능해 지는지 바로 와닿을 듯한.. 링크

AMD의 서버관련 x86과 SoC 관련 IP의 중국 라이선싱 소식.. THATIC이라는 조인트 벤처인데 중국이 반도체 관련 사업에 꽤 적극적인 모습을 보이고 있어서 어떤 형태로 칩이 나오게 될지는 모르겠지만 중국내 FAB육성과 함께 자국내 IT기업들이 서버에 사용할 제품을 만들려는 것 같아보이는데 Intel과의 라이선스 문제는 없다고 그러고 Intel에겐 새로운 경쟁자가 추가되는 상황이라 탐탁치는 않을 듯... 링크