6월 3주차 소식들..

소프트웨어

Ubuntu 리눅스의 패키지 관리 어플리케이션인 Snap이 캐노니컬의 프로젝트에서 커뮤니티 프로젝트로 전환 되었다는 소식.. 주요 특징은 기존 패키지 관리 시스템이 어플리케이션이 사용하는 라이브러리의 의존성에서 자유롭지 못했던 것과 비교해 개별 어플리케이션의 격리된 공간을 제공하고 여러 배포판들 사이의 패키지의 크로스플렛폼 호환을 지원 한다고.. 단점으로는 패키지 개별 용량이 증가하지만 이를 해결하기 위해 기존과 같이 공유라이브러리를 사용할 수도 있다고 함. 현재까지는 다른 배포판에서 기본 패키지 관리자로 채용할지는 미지수라고.. 링크

보안

Cisco의 비지니스용 무선 VPN 방화벽과 라우터 제품의 보안 결함 소식.. 패치는 3분기에 이뤄질 예정이라는데.. 원격 관리 콘솔에 커스텀 사용자 정보를 인증되지 않은 HTTP 요청에 실어 보내 루트 권한을 탈취할 수 있는 문제가 있다고. 그밖에도 아직 패치되지 않은 XSS 결함과 2개의 버퍼 오버플로 결함도 존재 하는데 문제는 패치가 되지 않은 상태에선 관리 콘솔의 외부 접근을 막더라도 여전히 XSS 결함에 노출될 수 있다고.. 링크

기타

삼성의 Joyent 인수 소식.. IoT쪽에 Node.js를 많이 사용하는 것 같더니 인수를.. Joyent가 Node.js 재단을 운영하기도 하지만 클라우드 서비스도 하고 있어서 주 목적은 삼성의 클라우드 서비스 진입이지 싶은데 일단 흡수하는 형태가 아닌 독립 회사로 운영될거라고.. 링크

6월 2주차 소식들..

소프트웨어

Visual Studio 2015 C++ 컴파일러를 사용시 용도 불명의 원격 코드가 삽입되고 있다는 소식.. 추후 빌드에선 없어질 거라고는 하는데 임시로 피하는 방법은 링크를 참고 하시길.. 링크 링크

jQuery 3.0 발표와 함께 구버전 Internet Explorer에 대한 지원 중단 소식이.. 6,7,8 버전에 대한 호환성을 유지하고 싶다면 jQuery 1.0을 사용하라고.. 링크

하드웨어

인텔의 PC 부문 축소와 함께 서버쪽을 강화한다는 이야기는 있었는데 이와 관련한 대략적인 윤곽에 대한 소식이.. 기존 폼팩터는 CPU와 각각의 부품들이 한세트로 구성된 형태 였는데 서로 다른 렉에 분리하는 형태를 추진중이고 이전에 HMC의 메모리 팜에 대한 구상이 현실화 되는 단계로 접어든 것 같음. 구리 배선이 아닌 기존에 연구하던 OmniPath 라는 광통신 인터페이스의 적용이 예상되고 제온칩에 포함된 FPGA 블럭은 재 프로그래밍이 가능하기 때문에 매우 강력한 무기가 될 것으로 보인다고.. 링크

보안

트위터의 로그인 정보 유출 소식.. 수백만명의 정보가 유출 되었다고 하며 현재 트위터측에서 유출된 정보를 확인하여 해당 계정들을 잠금 상태로 설정하고 비밀번호 초기화를 요청하도록 조치를 취했다고.. 링크

MS의 소프트웨어의 결함에 대한 위험을 경감 시켜주는 메커니즘인 EMET(Enhanced Mitigation Experience Toolkit, DEP, EAF, EAF+를 포함하는..)를 우회할 수 있는 가능성이 있어 어플리케이션에 대한 보안 패치를 미루지 말라는 권고가.. 특히 브라우저가 이러한 공격의 유입경로가 되는 경우가 많아 공격 대상으로 자주 거론되는 플러그인은 비활성 시켜두길 권한다고.. 링크

6월 1주차 소식들..

소프트웨어

HSA 1.1 스펙 소식.. 기존에는 AMD의 APU에 초점을 뒀다면 이제는 다양한 제조사들을 대상으로 하위 호환성을 갖도록 스펙을 확장하고 CPU + GPU 의 SoC 지원 뿐만 아니라 각종 DSP를 포함한 통합 칩에 대한 지원이 추가 되었다고. 링크

하드웨어

애플의 GPU 내장 5K 레티나 썬더볼트 모니터에 대한 소식.. AMD의 XConnect 기술을 사용한게 아닌가 개인적으로 추측하고 있고 애플만의 특별한 기능이 추가되거나 하는지는 아직 정보가 없는 상황.. 링크

MS의 홀로렌즈 스펙 오픈에 대한 소식.. 이제 파트너사들이 홀로렌즈 제품을 생산할 수 있게 되었고 VR과 AR 기기간의 경험을 공유하는 것에 대해서도 HTC와 함께 작업중인 걸로 보인다고.. 링크

기타

샤오미가 미국 진출을 위해 MS로 부터 특허를 구매 했다는 소식.. 1500개의 특허와 크로스 라이선싱이 포함되어 있고 자사폰에 오피스와 스카이프를 포함해서 출시하기로 됐다고.. MS가 안드로이드와 관련한 특허도 판매했는지는 아직 밝혀지지 않고 있다고.. 링크

보안

원격 데스크탑 소프트웨어인 TeamViewer의 계정 탈취소식... 얼마전의 대량 계정 유출 소식때 유출된 계정이 이용된 것 같다는 이야기는 있는데 아직 정확한 원인은 안밝혀 졌다고.. 후속 조치로 신뢰할 수 있는 장비에서 접근하는 것인지 확인하는 기능과 팀뷰어 계정이 탈취된 것 같다고 판단 될 경우 비밀번호를 강제로 초기화 하도록 하는 장치를 제공 하겠다는 이야기가.. 링크

AMD RX480 발표와 관련한 잡생각..

폴라리스 마카오 이벤트 직전에 던져진 떡밥으로 쉐이더 고유 펑션이라는 기능이 GPUOpen.com에 소개 됐었는데.. GCN 기반 아키텍쳐 제품에서 콘솔과 같이 하드웨어에 직접 접근하는 빌트인 쉐이더 펑션을 사용하는 기능이다. 생각해보니 EA의 프로그래머중 한명이 GCN 하드웨어를 OpenGL을 이용해서 해킹해 사용할려고 했던게 기억이..

결과적으론 빌트인 펑션이라는게 스펙 자체는 2014년 부터 거론이 되서 이번에 도입 되었는데.. Computex 발표회 때 Id 소프트의 엔지니어 인터뷰에서 Vulkan 버전의 둠이 AMD의 True 비동기 컴퓨트와 빌트인 펑션을 이용해서 개발중이며 200+ 이상의 프레임 레이트를 보여줄 것이라는 이야기가.. 마지막에 둠을 환상적인 프레임으로 즐기기위해 $700 그래픽 카드를 살필요 없다는 이야기는 1080 발표회때 초대한 엔비디아의 뒤통수를 강하게 치는 듯한 한마디였다; 관련 영상은 여기에서..

그리고 비동기 컴퓨트에 True를 붙인건 아마도 엔비디아의 비동기 컴퓨트와 구분할려고 붙인 것 같다.. 알고있는 바로는 AMD가 이야기 하는 비동기 컴퓨트에선 작업 타입이 크게 3종류가 있는데 쉐이더, 컴퓨트, 복사 작업이며 이런 작업 타입에 상관없이 전체 작업에 비동기 스케줄링이 가능한 방식이다. 하지만 엔비디아가 이야기하는 방식은 각각의 타입별로는 비동기 처리를 할지는 모르겠지만 작업 타입이 바뀌는 경우 전환 비용이 발생하고 있다.

현재 들리는 바로는 10월에 코드네임 VEGA 제품과 출시할 문명6가 이런 작업 타입 전체에 대해 기존보다 좀더 적극적으로 비동기 컴퓨트를 이용할 예정이라는 루머가 있고 6월 13일 E3에서 VEGA의 런칭 타이틀인 EA의 Battlefield1의 64인 멀티플레이 라이브 스트림 이벤트가 있다. 아마도 시연은 폴라리스 혹은 VEGA로 알려진 제품으로 하지 않을까 추측된다. Total War : Warhammer의 경우도 DX12 버전 패치를 준비중이며 비동기 컴퓨트, MLAA, TressFx 3.1등이 적용된 버전이며 게임의 전반적인 성능 향상에 초첨을 두었기 때문에 그래픽 카드 벤더와 상관없이 DX11버전 대비 큰 성능 향상이 있을 것으로 예상 된다.

AMD GPU ROADMAP

사실 이번에 가장 화제가 되었던 $199 에서 시작하는 가격은 아직 정확히 성능을 가늠하기 힘든 상황에서 대략적인 윤곽만 보이며 경쟁사의 라인업을 꼬이게 하는.. 아직까지는 엄청난 효과를 발휘하는 것 같아 보인다. 더군다나 예전부터 이야기 되었던 Primitive Discard Accelerator의 효과가 어느 정도인지도 미지수인 상태인데다 본격적으로 적용된 타이틀이 EA의 Battlefield1일 가능성이 크기 때문이다.

그밖에도 경제적인 문제로 보면 양적 완화를 시행한 미국에선 최근은 나아져 가는 편이지만 은행에서 돈은 풀었지만 개인의 삶은 나아지지 않는 문제라던가 BRICs와 같은 신흥국 소비자의 구매력이나 여러가지를 고민 했던 것 같다.. 아마도 이번 세대 최대 과제가 앞으로의 청사진을 위해 가능한 점유율을 끌어올리는게 목적이라 $500 가격대 성능을 $199에 제공하기로 결심한게 아닌가 생각된다..

개인적으로 추측하고 있는 AMD의 청사진은 위 슬라이드의 코드네임 Navi의 경우 Scalability를 강조하고 있는데 해외 웹진들과 AMD 관계자와의 인터뷰에서도 간간히 언급 되었지만 빅뷰티칩은 매우 비효율적이고 리스크가 크기 때문에 사실상 빅칩 전략을 사용하는 시대는 Vega가 마지막이 되지 않을까 생각하고 있다. 그렇기 위해서는 앞서 언급한 것 처럼 점유율을 끌어올리고 멀티 GPU를 이용하는 사용자를 많이 확보할 필요가 있는데 이는 VR을 위한 Liquid VR 기능과도 연관이 된다.

또한 현재 DX12의 멀티 GPU 렌더링 기술역시 과거의 Alternate Frame Rendering 기법에서 머물고 있는 상태를 넘어 이론적으로는 이미 알려져 있었지만 구현하긴 힘들었던 다양한 기법을 통해 APU와 같은 내장 GPU를 활용할 수 있길 바라고 있고 아마도 이를 위한 기반 기술인 비동기 컴퓨트였을 것으로 생각하고 있다. 덧붙여 크로스파이어의 API와 샘플 코드역시 공개되어 있는 상태이다.

AMD의 고유 API들은 대부분 오픈소스로 공개되어 있거나 앞으로 계속해서 추가되어 갈 것으로 보인다. 이렇게 풍부하게 보급된 AMD의 자원은 개발자들이 좀더 자신들과 협업할 수 있는 기회를 만들어주고 GPUOpen 프로젝트를 통해 개발자들과 결과물을 공유하는(GPUOpen 프로젝트의 업데이트를 유심히 보면 협력해서 작업한 게임이 출시되면 해당 프로젝트에서 나온 결과물들이 대량 업데이트 되는 것을 볼 수 있다..) 일은 게임웍스와는 다르게 개발 자원의 투명성을 보장해 주고 있다. 최근 대안으로 거론되는 경제 모델에선 Win-Lose는 존재하지 않고 상호간에 Win-Win 아니면 Lose-Lose 밖에 존재하지 않는 다는 것을 오랜기간 암흑기를 거치면서 깨달은 것 인지도 모르겠다. 사실 다른 관점에서 생각해보면 밥줄인 핵심 기능들은 하드웨어로 구현하고 이를 최대한 활용할 수 있는 자원들은 공유하는 형태이기도 하다.

여튼 이번 기회에 정상 궤도로 복귀해서 지금까지 경험하지 못한 화려한 그래픽의 세계로 소비자들을 초대하는 모습을 보여주기 바라며 이만 줄인다..

Java 9의 GC

참고 : https://www.infoq.com/presentations/java9-improvements

Java 9의 핵심 기능인 모듈러 Java를 위한 Jigsaw는 워낙 여러곳에서 다루고 있다보니 이를 제외한 기능에 대해 이야기 하고 있는 eclipsecon의 발표 자료가 나왔는데 이중 GC와 관련한 항목이 눈에 띄어 간단히 정리해 보기로 하였다.

Java 8까지는 Parallel GC가 기본 GC였는데 9부터는 G1 GC가 기본 GC로 바뀐다고 하며 String 중복 제거 기능에 대한 소개가 있는데 비동기로 동작해서 런타임 오버헤드가 없고 힙공간 낭비를 10%가까이 줄일 수 있다고 하며 Java 8u20 부터 사용 가능하다고..

사용 옵션은 다음과 같다.

-XX:+UseG1GC -XX:+UseStringDeduplication

이와 별도로 Java 9에서는 String 데이터 타입의 튜닝이 꽤 적용되서 전체적인 퍼포먼스 향상이 기대되고 Java 9의 마일스톤은 2016년 5월에 스펙이 마감되었고 2017년 3월 정식버전 발표를 앞두고 있다. Jdk9의 미리보기 버전을 사용하고 싶다면 다음 링크를 참고하면 된다.

5월 4주차 소식들..

기타

구글과 오라클의 법정 싸움은 2주간의 재판 진행 끝에 구글의 승리로... 처음 시작은 자바만의 문제였다가 이번 재판에선 API 디자인이나 명세가 저작권을 갖는지에 대한 문제로 바뀌면서 오라클이 이겼다면 변호사가 개발자의 친구가 될거라는 이야기가 있었던... 링크

구글의 안드로이드 업데이트와 관련해서 OEM과 통신사들의 랭킹을 부여해서 업데이트를 촉진 시킬려고 하지만 정작 제조사들은 상위 제품 사용자와 보급형 제품 사용자의 차이가 적어져서 매출에 악영향을 미치는 것을 우려하고 있다는 소식.. 링크

보안

WordPress의 플러그인 중 Jetpack의 코멘트 기능에 XSS 취약점을 이용해서 의심스러운 코드를 심을 수 있는 문제가 발견되어 21개의 브랜치에 대해 패치 버전이 나왔다는 소식.. 링크

JavaScript 첨부파일을 통해 전파되는 Locky 랜섬웨어에 대한 소식.. 아직까지는 암호화된 파일을 복원할 방법이 없다고 하며 일반적으로 JavaScript 코드의 첨부파일을 주고 받을일은 거의 없으나 .js나 .jse 파일을 포함한 메일은 주의를 기울일 필요가.. 링크

Drupal을 이용해서 운영되는 사이트를 대상으로 SQL injection 결함을 이용해 관리자의 비밀번호를 변경시키는 랜섬웨어 봇에 대한 소식이.. 대부분의 사이트들이 자동 백업 시스템을 갖추고 있어서 이와 관련하여 비용을 지불한 케이스는 아직 없다고.. 링크

JavaScript를 이용해서 웹페이지를 복사할 때 의심스러운 터미널 코드를 포함하도록 클립보드를 탈취해서 변조하는 Pastejacking이라는 해킹 기법이 소개된.. 링크

익명 통신 네트워크 서비스를 제공하는 Tor에서 보안을 강화하기 위해 분산된 다수의 시스템의 엔트로피를 수집해 랜덤 넘버를 생성하는 기법을 발표 했다고.. 링크

"Forbidden attack"이라고 불리는 오래전에 밝혀진 해킹 기법이 Visa 사이트에서 유효하게 동작 하는 것 같다는 소식이.. TLS 프로토콜을 이용해서 통신할 때 서버에서 1회성 랜덤키를 받아오는데 보통은 한번 사용하면 다시 사용할 수 없지만 만약 규칙을 준수하지 않아 한번이라도 더 사용할 수 있게 되어 있다면 공격자가 네트웍을 모니터링 할 수 있는 상황(공개된 WiFi 같은..)이라면 중간에 코드를 삽입하여 정보를 탈취할 수 있는 문제가 있다고.. 링크

소프트웨어

리눅스의 VFS레이어에 inode 타임스템프가 signed 32bit integer를 사용해서 발생하는 2038년 버그가 커널 4.7에서 한참 수정중이라는 소식 이와 더불어 EXT4 파일시스템도 다수의 버그픽스가 커널 4.7에 올라오고 있다고.. 링크 링크

하드웨어

CCIX 컨소시엄에 대한 소식..SoC를 위한 고속 통신용 인터페이스라는데 참여 기업이 ARM, Qualcomm, AMD, Xilinx, Huawei, IBM, Mellanox라고 모바일에서 PC 수준의 연결성을 제공할 인터페이스라는데 멀티칩모듈(MCM, 노트북의 그래픽카드나 AMD의 Fiji칩같은..)과 외장 카드형태 모두를 지원 할거라고.. 링크

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서버에서 이점이..
• 프로세스가 아닌 어플리케이션 레벨의 캐싱.

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