AIX에서 Ruby 돌리기?

별로 생각하고 싶지 않은 스토리인데.. 상황이 그리 되는 어쩔 수 없으니...

흐웅 그나저나 이 머신 왜이리 접속하는데 오래걸려. 그래도 행복하게 ruby를 쓸 수 있네 ㅋㅋ
들어가는게 느리니 느리겠거니...

요게 느린 것도 아마 AIX 요 머신이 특이한 걸 것이야..
얼래 그런데 ftp로 데이터 받아오기나, 그 외의 것들은 빠른데.... -ㅅ-
알고보니 Ruby에서 ext/socket 모듈로 Socket 생성시 접속이 오라지게 느리게 된다.
꾸에엑 이를 어쩌나.. 소켓이 필요한 부분이 TCPSocket으로 접속도 해야하고, open-uri를 이용해서 ftp에서 파일도 받아와야하는데..

고객은 앞에 있고.. 데모 보여줘야하는데... ㄷㄷㄷ
부랴 부랴 netcat, wget으로 두부분을 스슥 바꿨다.
UNIX는 저에게 system, popen과 ``를 주셨나이다. ㄳㄳ

일단 일단락.. 그러나 상황이 조금 바뀌어서 AIX에서 Ruby/Pcap도 써야할 상황.
컴파일을 하는데 잘 안 되네.. -ㅅ-
컴파일하고 나니 모듈 로딩이 안 된다.

 구글링하던 도중 AIX에서 Ruby Building할때 1차시도의 해결책을 찾았다.
 알고 보니 망할 Visual Age Compiler 6.0의 버그문제. python을 비롯한 다른 오픈프로젝트에서도 관련 얘기가 나오네. -ㅅ- 그래서 vac로 다시 한번 컴팔해봤다.

 그러나 역시 Ruby/pcap은 로딩이 되지 않는다. (해결되면 포스팅 이어짐 안되면 한동안 좀비모드일듯.. C++ Porting 고고싱 T-T)
 libpcap 컴파일시에 CC="gcc -maix64" CFLAGS="-g -O2" ./configure --with-pcap=dlpi --disable-ipv6  로 옵션을 줘서 해결. README.aix문서를 읽어보고 bpf를 사용하지 않고 dlpi를 사용하게 하니 문제없이 작동 - 머 특정 용도 활용이라서 원하는 기능만 돌아가는지 확인. (Fixnum을 Symbol로 사용하짐 랄라는 에러가 3개 뜬다 덜덜덜.. -ㅅ-)

추가적인 수정 사항 (흑 2006.03.29 새벽3시 퇴근 ㅠ.ㅠ)
1. Endian 문제가 있어서 (실제 데이터는 리틀엔디안 AIX는 빅엔디안) 2바이트짜리 길이를 나타내는 부분이었는데 len.unpack('s')를 len.reverse.unpack('s')로 수정
2. 이상하게 tcpdump에서 쓴 패킷 캡쳐시간이 리눅스에서와 AIX에서 14시간 정도 차이가 난다. 그냥 그런가 부다 하고 처리하는 중.

오랜만에 AIX만지면서 알게된 잼있는거 linux기반의 opensource들과 AIX가 좀 더 친해졌다.
미리 컴파일된 바이너리를 http://aixpdslib.seas.ucla.edu/ 에서 잘 받아썼는데 IBM에서 rpm으로 공식지원하는 녀석이 생겼다. 이름도 그럴듯하다~
 AIX Toolbox for Linux Applications 엄훠 이젠 rpm으로 설치하세요~
 
 또하나는 netcat, libpcap, tcpdump 그리고 몇몇 소프트웨어를 컴팔하면서 간단하게 에러나는 것을 잡은 부분 정리

 요사이 개발자로써의 목표는 "새로운 것을 접할 때 빠른 결과와 좋은 성능을 보장하는 개발하기"였다. 실제 여러가지 실제적인 상황을 보다보면 대부분 아는 것보다 모르는 것이 많은 것이 당연한데,  늘 그러한 일을 할 때면 밑바닥부터 모든 것을 만들겠다는 아집에 많은 시간을 쓰는 경우가 많았다. (알고보면 모든 것을 밑바닥부터 만들는 경우는 없는 것과 마찬가지이다.)

해야할 일은 TCP로 돌아다니는 패킷을 캡쳐 => 캡쳐된 패킷을 스트림으로 전환 => 특정 프로토콜에 맞게 파싱

장님 코끼리 만지기 식으로 도입한 프로세스
1. 고객에게 정보 수집
2. 먼저 빠르게 사용할 수 있는 라이브러리를 찾기.(libpcap)
3. lightweight framework language( Ruby, Python과 같은 유연하고 제네릭한 언어)에서 해당 라이브러리 찾기 (pcapy, Pcap/Ruby)
 그중 Pcap/Ruby에서 아주 쓰기 편하고 이쁜 라이브러리를 기반으로 구현을 해서 나머지 기능을 모두 기 능 구현을 했었다.
4. 그 외에 세부적으로 필요한 기능상의 내용은 TCP가 어떻게 돌아가는지는 오픈소스 구현물 tcpflow, wireshare, 그리고 관련 자료 wikipedia, the TCP Guide를 참조해서 Ruby로 만든 프로그램에 적용하는 식으로 개발을 했었다.

  3주 정도의 기간에 결과물을 대략 산출해내는데 성공했으나 - 아직 진행중 - , 몇 가지 문제점 및 개선방안을 발견할 수 있었다. 결국 실용주의 프로그래머에서 본 내용을 다시 한번 뼈저리게 느끼게 된다.

 수행하면서 좋았던 점
 1. 1주일 이터레이션 : 피곤하고 많은 시간을 뺏긴다고 생각했으나, 가야할 방향을 알려주는 나침반 역할을 수행했다.
 2. Lightweight framework language 활용 : ruby,python과 같은 유연하고 쉬운 언어를 통한 접근은 새로운 기능을 사용하는데 있어서 지렛대 역할을 수행했다. 또한 어떤 부분이 성능이 필요한지, 아닌지에 따라서 사용 여부를 판단할 수 있었다.

 개선해야할 점 및 반성점
 1. 기존에 있던 구현물을 최대한 활용하기(Unix 철학처럼 simple is best를 최대한 활용하라.)
 기능을 구현하는데 있어서 라이브러리보다 더 좋은 수단은 이미 구현된 프로그램이다. 그것을 최대한 재활용할 수 있는 방법을 먼저 강구했었으면 더 빠르게 그리고 안정적으로 구현이 가능했을 것이다. tcpdump를 이용해서 파일을 주기별로 만든 다음에 그걸 파싱하는 프로그램을 작성한다던지 하는 등의 개발방법론을 적용했다면 더 빠르게 개발이 가능했었을 것이다.
 2. 고객 그리고 같이 일하는 사람들의 얘기를 좀 더 주의깊게 들으라. 해당 문제를 좀 더 쉽게 단순화시킬 가능성이 높아진다. 받은 데이터를 기존에 같이 일할 때처럼 csv파일과 같은 형태로 만들기 위해 모두 파싱을 하느라 3-4일 정도의 기간을 소요했는데, 오프셋으로도 처리가 가능했었다. 기존에 같이 일할 때 방법만을 생각하고 개발하느라 그러한 문제점이 발생했었는데 생각해보니 지나가는 말로 이 안건을 개발하면서 관련 얘기를 들었던거 같다.
 3. 그중에서도 실시간성을 어떻게 감안하느냐에 따라서 concurrent 모델 혹은 배치작업(분리된 프로세스)로 처리하는 것이 월등히 좋은 성능을 발휘할 수 있다. 실시간의 DB 트랜젝션 그리고 실시간의 raw data를 파싱하는 작업등은 시간에 민감한 다른 작업에 지대한 영향을 줄 수 있다. 다량의 로그데이터를 처리하거나 실시간성이 중요한 패킷캡쳐등을 할 때 작업을 분리해 배치처리를 하는 방향으로 모델을 작성했었어도 나쁘지 않은거 같다.

프로세스 수정안
1. 고객에게 여러가지 제반사항에 관한 정보를 수집하기.
2. 같이 개발할 사람들과 협업할 부분에 대한 정보를 얻기
3. 모델을 쉽게 재구성하기
4. 해당 기능과 같은 혹은 비슷한 프로그램을 찾기
5. 실행해보기(기능, 성능체크)
6. 역할에 맞게 최소한의 수정 (라이센스 정책을 어기지 않게 모델을 구성하는데 참조)
7. 그 외의 부분은 상황에 따라 lightweight framework language와 기존의 언어로 빠르게 구현