kakao

카카오의 전사 리소스 모니터링 시스템 – KEMI(Kakao Event Metering & monItoring) KEMI(Kakao Event Metering & monItoring)는 카카오의 전사 리소스 모니터링 시스템 입니다. 서버, 컨테이너와 같은 리소스의 메트릭 데이터를 수집해서 보여주고 설정한 임계치에 따라 알림을 보내주는 KEMI-STATS과 ETL을 통해 수집한 log를 대시보드 형태로 보여주거나 실시간 알림을 할 수 있는 KEMI-LOG로 구성되어 있습니다. KEMI-STATS KEMI-STATS는 수만대에 이르는 카카오의 전체 서버와 컨테이너 서비스를 모니터링하는데 이용되고 있으며 polling방식과 push방식 두가지를 사용합니다. 리소스 중 서버(physical machine, virtual machine, amazon ec2)의 경우 polling방식으로 SNMP를 이용하여 시스템 메트릭을 수집합니다. 데이터를 수집하는데 여러가지 방식이 있을 수 있지만 SNMP를 기본으로 선택한 이유는 서버의 운영체제와(linux/windows/nw switch) 상관없이 모니터링하기 위해서 입니다. polling 방식의 수집은 젠킨스 배치 job을 이용해서 1분마다 아래와 같은 순서로 실행됩니다. job이 시작되면 KEMI의 Job Producer가 IMS(Infrastructure Management System)라는 카카오 인프라 관리 시스템에서 데이터를 가져올 대상을 받아와서 kafka의 polling job queue topic에 넣어 놓습니다. (이렇게 매 주기마다 호스트 목록을 [ more… ]

CODING BATTLE 가위바위보! – 못다한 이야기 어쩌다보니 키스톤! 지난 8월 13일(토)부터 이틀간 코엑스 그랜드에서 열렸던 PyCon 2016 APAC에서 카카오 부스를 지켰던 iolo.fitzowen 입니다. 키스톤 스폰서 자격으로 행사장에서 가장 큰 부스를 운영하게되었는데, 거대한 부스를 어떻게 활용할 것인가를 오랫동안 고민했습니다. 어쩌다보니 가위바위보! 부스 이벤트로 코딩 퀴즈를 하기로 하고 사내 그룹웨어인 아지트를 통해 문제를 추천 받았는데, bryan.j가 제안한 가위바위보 AI 대전 아이디어을 다듬어 CODING BATTLE 가위바위보!라는 이름의 행사를 진행했습니다. (이 자리를 빌어, 멋진 아이디어를 주신 bryan.j, 그리고 채택되지 않았지만 다양한 의견을 주신 여러분께 감사드립니다.) 자세한 내용은 이벤트 페이지 CODING BATTLE 가위바위보! in 파이콘 2016 APAC를 참고하시고, 이 글에서는 파이썬 초보(!)가 코딩 이벤트를 진행하면서 겪었던 에피소드를 인상적인 소스 코드와 함께 전해드리겠습니다. 1부: MAKING FILM Ver1. 클라우드 서비스 + 네트웍 대전 최초의 아이디어는 서버-to-서버 HTTP 통신을 이용하는 방식이었습니다. (제가) 게임 진행 서버(host-server)를 개발하고, (참가자들은) 플레이어 서버(player-server)를 개발해서 (무료) 클라우드 서비스에 올리고, (제가 만든) 진행 서버가 [ more… ]

개발자를 위한 SSD (Coding for SSD) – Part 6 : A Summary – What every programmer should know about solid-state drives 이번 챕터에서는 지금까지 언급했던 내용들을 간략히 요약해서 정리해 보았다. 조금 더 상세한 내용을 쉽게 찾아갈 수 있도록, 각 내용들은 다른 파티의 한두개 이상의 섹션을 나열해 두었다. SSD 기본 1. 메모리 셀 타입 SSD (Solid state drive)는 플래시 메모리를 기반으로 하는 저장 장치이이다. 각 비트들은 셀에 저장되는데, SSD의 셀은 1 비트(SLC), 2 비트(MLC) 그리고 3 비트(TLC) 셀 타입이 있다. See also: 섹션 1.1 2. 수명 제한 각 셀은 최대 가능한 P/E(Program/Erase) cycle을 가지며, 최대 가능한 P/E cycle을 초과하면 결함 셀(Defective cell)로 간주된다. 이는 NAND 플래시 메모리는 언젠가는 Wear-off되고 수명이 제한적이라는 것을 의미한다. See also: 섹션 1.1 3. 벤치마킹의 어려움 테스트도 결국 사람이 수행하는 것이기 때문에, 모든 벤치마크는 오류나 실수를 담고 있다. 그래서 제조사나 제 삼자에 의한 벤치 마킹 결과를 참조할 [ more… ]

개발자를 위한 SSD (Coding for SSD) – Part 5 : 접근 방법과 시스템 최적화 지금까지 SSD 드라이브의 내부적인 작동 방식에 대해서 살펴 보았다. 또한 SSD를 접근할 때 어떤 방식이 사용되어야 하며, 그리고 그 접근 방법이 다른 방법보다 왜 나은지 등의 이해를 돕는 자료들도 제공했다. 이번 챕터에서는 읽기와 쓰기는 어떻게 처리되어야 하는지, 그리고 읽고 쓰기가 동시에 발생할 때 서로 어떤 간섭 효과를 내게 되는지를 살펴보도록 하겠다. 그리고 성능 향상을 위해서 파일 시스템 레벨에서 가능한 최적화에 대해서도 조금 언급하도록 하겠다 7. 액세스 패턴 7.1. 시퀀셜과 랜덤 I/O의 정의 이번 섹션에서 사용되는 시퀀셜(“sequential”)과 랜덤(“random”)이라는 단어로 SSD 액세스를 의미한다. 이전 I/O 오퍼레이션의 마지막 논리 블록 주소(LBA) 직후의 논리 블록 주소(LBA)를 시작 지점으로 SSD를 접근하는 경우 시퀀셜이며, 그렇지 않은 경우를 랜덤이라고 한다. 그리고 FTL에 의해서 동적으로 블록 맵핑이 실행되기 때문에, 논리 주소가 연속적이라고 해서 실제 물리적인 데이터의 위치가 연속적인 것은 아닐 수도 있다는 것도 기억해두자. [ more… ]

개발자를 위한 SSD (Coding for SSD) – Part 4 : 고급 기능과 내부 병렬 처리 이번 챕터에서는 SSD의 주요 기능인 TRIM과 Over-provisioning(Over-provisioning)에 대해서 간단히 살펴보도록 하겠다. 또한 SSD의 내부 병렬 처리와 클러스터링 블록에 대해서도 같이 살펴보도록 하겠다. 5. 고급 기능 5.1. TRIM 용응 프로그램이 SSD의 모든 논리 블록 주소에 파일을 기록했다고 가정해보자. 그러면 SSD는 풀(full)로 사용되었다고 생각될 수 있다. 이제 이 모든 파일들이 지워졌다고 가정해보자. 파일 시스템은 SSD가 100% 비어 있다고 보지만, SSD 컨트롤러는 호스트로부터 삭제된 논리 블록의 주소를 알지 못하기 때문에 실제 SSD 드라이브는 여전히 100% 사용중이라고 생각하게 된다. SSD 컨트롤러는 호스트의 파일 시스템으로부터 덮어 쓰기 명령이 전달될 때에만 그 영역이 빈 공간이라고 판단할 수 있게 되는 것이다. 이때 Garbage-collection 프로세스는 삭제된 파일과 연관된 블록들을 지울(Erase) 것이다. 결과적으로 블록이 “stale” 데이터를 가지고 있다는 것을 알아내는 순간 삭제(Erase)하는 대신 지연 처리되는 것인데, 이는 성능을 심각하게 떨어뜨리게 된다. 또 다른 우려 [ more… ]