Blogs

Graylog는 사용자의 모든 로그를 한 곳에 모아서 자동화된 기초분석을 해주며, 이를 시각적으로 표시해주거나 특이사항 발생을 감지했을 때 경보를 주는 기능을 제공한다. 또한 필요에 따라 사용자가 쉽게 세부사항을 찾거나 열람할 수 있도록 검색기능을 제공한다. 이 글에서는 이러한 기능요소에 대해 정리한다.

클라우드 컴퓨팅 환경에서 휘발성 인스턴스의 로그를 중앙화하여 (반)영구 보관하고, 다양한 소스로부터 발생하는 관련된 로그를 모아서 연관 분석을 진행할 수 있는 플랫폼을 찾던 중 발견한 공개 소프트웨어 중 하나가 오늘 소개하려 하는 Graylog이다. 이 글에서는, Graylog를 간단히 소개하고, 그 설치 방법을 정리한다.

이 글은 VMware의 네트워크 가상화 기술인 NSX 6.2를 이용한 프로젝트에서 네트워크 트래픽과 이상현상을 분석하는 과정에서, VDR과 DVS, vmnic 등의 정보를 확인했던 내용들을 간략하게 정리하는 글이다. 아쉬운 점은, 벌써 2년이 지난 기록이라서 현재의 상황에 맞지 않는 내용이 포함되었을 수 있고, 간단하게 메모로 남겼던 것을 편집한 것이다 보니 이야기의 맥이 없다. :-(

네트워크를 다루기가 상대적으로 어려운 클라우드컴퓨팅 환경을 겨냥한 네트워크 포트 미러링 솔루션을 찾다가, 도저히 기능이나 비용 면에서 마땅한 것이 없어서, 요즘 공부하고 있는 Golang을 사용해서 하나 만들었다.
이 글은, 일단 이 프로젝트를 소개하는 글(README)이다.

인터넷 기반 서비스, 특히 Cloud Computing 환경에서 개발되는 Application이라면 웹이든 모바일이든 꼭 사용하게 되고야 마는 OAuth2와 JWT, 그것을 바탕으로 하는 인증/인가 체계의 개념에 대하여 최대한 쉽게 정리한다. (사실, 쉽게 쓴다고 해도 쉬운 내용이 아니지만 일반적으로 접할 수 있는 Protocol 자체에 대한 관점보다는 사용하는 입장과 왜 이렇게 쓰는지를 이해하기에 조금이라도 수월한 글이 되었으면 좋겠다)

복잡하게 구성된 환경에서는 그 단위가 물리 네트워크 전체든, 그 안에 흐르는 VLAN이든, 단일 서비스에 대한 것이든, 네트워크의 성능을 제한하여야 할 때가 있다. 예를 들어, 웹서비스를 주로 하고 부가적으로 FTP가 허용된 서버에서 웹 성능을 보장한다든지, 아무리 바쁜 상황에서도 관리용 접속이 지연되는 것을 피해야 한다든지, 특정 기능은 제한된 범위에서만 허용해야 한다든지…
이런 부류의 관리를 보통은 Traffic Shaping이라고 부른다.

존재하지 않는 서버의 로그를 보려면 어떻게 해야 할까? 간단하다. 로그를 서버가 아닌 다른 곳에 저장해서 보면 된다. 더이상 서버가 존재하지 않는 클라우드컴퓨팅 환경에서 로그를 기록하고, 그 이상의 일을 하기 위해서, 다시 또다른 클라우드 서비스를 활용할 수 있는데, 그 중 하나가 Papertrail이다. (Part #2)

존재하지 않는 서버의 로그를 보려면 어떻게 해야 할까? 간단하다. 로그를 서버가 아닌 다른 곳에 저장해서 보면 된다. 더이상 서버가 존재하지 않는 클라우드컴퓨팅 환경에서 로그를 기록하고, 그 이상의 일을 하기 위해서, 다시 또다른 클라우드 서비스를 활용할 수 있는데, 그 중 하나가 Papertrail이다. (Part #1)

대부분의 프로그램은 여러 개로 나누어진 Routine(그것을 함수, Method, 뭐라 부르든)의 집합이며, 동시에 이것들의 반복되는 상호 호출의 결과이다. 따라서 전체 소프트웨어의 실행 시간은 이 단위 Routine이 소모하는 시간의 합이며, 그 중에는 분명히 절대적/상대적으로 “혼자 바쁜” 또는 “혼자 느린” 누군가가 있게 마련이다. 어느 집합이든 통하는 얘기다.

이번 시리즈를 통해서 배운 것이 하나 있다면, 글을 쓰려거든 딱 그 주제 하나에만 집중해야 한다는 점이었다. 시작은 단지, SoftLayer Cloud와 Object Storage를 활용한 시험적인 Application을 소개하는 것이었는데, 시리즈에 담을 내용을 정하는 과정에서 욕심이 과했던 것 같다.

지난번, “CAOS, Cloud Album on Object Storage“라는 제목의 글을 통해서 Cloud Computing 영역의 서비스를 다각도로 활용하여 간단한 “Photo Album” 서비스를 구성해본 경험에 대하여 운을 뗐다. 이 글은 그 “CAOS 시리즈"의 본편 첫 번째 이야기로, 기존에 내가 즐겨 해왔던 방식과는 조금 다르게 Rails App의 골력을 만드는 과정을 기록하려고 한다.

뜻하지 않던 파일 공유도 할 겸, SoftLayer의 Object Storage에 대한 API 시험도 할 겸 간단하게 Web Application을 하나 만들어봤다. 이름하여 CAOS. Cloud Album on Object Storage를 줄여 만든 이름이다.

한 10일 전에 SoftLayer의 Object Storage를 사용하면서 Temp URL을 사용하기 위한 수정을 더한 Custom 버전에 대하여 기록했었다. 그런데 언제나 급하게 간 길은 옳은 길이 아닐 수 있어서 왔던 길을 다시 걸어야 할 때가 있다. 지금이 그 상황이다.

잠깐 짬을 내서, 지난 주말에 SoftLayer의 Object Storage를 활용하는 개발의 시험을 해보려고 했다. 그런데 이 Object Storage 내에 저장된 비공개 자료를 임시 URL을 사용하여 URL을 알려줄 특정인에 한정하여 공유하는 부분에서 딱! 하고 막혀 버렸다. 이번 글은, 이 막힘을 푸는 과정을 두 가지 주제로 기록해 보려고 한다.

첫인상이 중요한 것은 사람에게만 해당하는 것이 아닌 것 같다. “PaaS” 하면 가장 먼저 생각나는 Heroku의 첫 인상이 내겐 그랬다. 이 글은, 간만에 Heroku에 신규 App을 등록/배포하면서, 그 과정을 정리한 것으로 Heroku를 사용하기 위한 가장 기본적인 Workflow를 설명하고 있다.

일반적인 Web Application이 아닌 API Backend를 위한 Python Web Framework을 선정하기 위하여, 인기있는 Framework 몇 개를 비교해보았다. 이 글은, 이 비교 과정과 결과에 대한 기록이다.

계단 하나 하나를 그냥 뛰어넘지 못하는 성격 탓에, 정작 쓰려던 글을 뒤로 미루고 먼저 써 내려가고 있는 이 글은, Bundler가 Ruby 세계에 제공하는 것과 유사한 기능을 Python 세계에 제공해주는 virtualenv와 pyvenv로 줄여 부르는 Python Virtual Environments에 대한 이야기이다.

이 글에서는, 앞서 작성한 Ember.js 기반의 Console App을 조금 다듬으면서 Console App의 방향을 다시 명확하게 잡고, 이 과정에서 Semantic UI를 적용하여 보다 보기 좋게 만드는 과정을 기록하였다. 또한, 시각적인 데이터 표현에 대하여 고민하여, 내 비용이 주로 어느 자원에 의하여 나가고 있는지 직관적으로 확인할 수 있도록 Billing 자료에 시각화를 적용해 보았다.

SoftLayer API에 대하여 파악하고 그 한계나 사용 가능성 등에 대하여 검증하기 위한 목적으로 작은 프로젝트 하나를 진행해 봤다. 이름하여, Hardened Layer.