AOJ 에 해야 하는 수많은 작업들의 탑 리스트에 있는 것이 다른 언어의 지원이다. 딴건 다 그렇다 치고, 자바와 파이썬 정도만 지원할 수 있어도 potential user pool 이 훨씬 늘어날 거라고 생각하기 때문이다. (그전에 모의고사 문제나 좀 올려두던가...)
그런데 남의 프로그램을 받아다 내 컴퓨터에서 돌린다는 온라인 저지의 특성상 샌드박싱은 필수적이다. 지금은 제출된 프로그램을 띄운 뒤 부모 프로세스에서 메모리 사용량과 실행 시간을 감시하고, ptrace 를 이용해 시스템콜을 가로채는 방식으로 프로그램을 검증하고 있다. 그런데, 컴파일되는 언어들이라면 모르겠지만 VM 위에서 돌아가는 언어를 이런 식으로 검증할 수는 없다. 하지만 현실의 대세는 결국 VM 위에서 돌아가는 언어이니 지원 안할 수도 없다. 그런데, 이런 저런 방법들을 고민해 봤지만 지원하고자 하는 수많은 언어들을 한번에 지원하는 것도 힘들다. 결국 가상머신이라도 써야 하나 헐퀴 이러고 있었는데, 오늘 생각해 보니 왜 아마존 EC2 를 쓸 생각을 안하고 있었나 싶더라.
아마존 EC2 는 가상화 서비스들 중에서도 모든 것이 클라우드 위에 올라가 있다는 점에서 특이한데, 이 말인즉 실행중인 서버 인스턴스들이 특정 서버에 할당되지 않고 클라우드 위에서 시뮬레이션 된다는 뜻이다. (대개의 가상화 솔루션들 - 각종 vps 서비스들, 랙스페이스 클라우드 등은 특정 서버 위에서 돌아간다.) 반대로, 이 인스턴스들에 마운트된 디스크들은 인스턴스가 종료되면 사라져 버린다. 대개는 이런 non-persistence 가 굉장히 귀찮은 요소가 되지만, 우리 용도로는 오히려 매우 적당하다.
chroot jail 등의 최소한의 샌드박싱만을 추가해서 프로그램을 실행하고, 메모리 사용량 모니터링과 실행 시간 모니터링을 예전처럼 한다. 만약 프로그램도 종료하지 않고 샌드박스도 종료하지 않고, CPU 사용량 또한 감소하지 않는다면, 간단하게 VM 자체를 죽여 버리고 리스토어하면 된다. EBS 에 디스크 이미지 저장해 놨다가 여기에서 부트하면 리부팅하는 데도 시간이 별로 걸리지 않는다. (사실 이 기능이 12월에 추가된 걸 보고 이생각을 했따. ㅡㅡ;) 이미지는 오직 이 용도로만 사용할 테니, 악의적인 프로그램이 시스템을 장악한다고 하더라도 잃을 것도 없다. 더더욱이, 아무도 한 시간 동안 서브밋을 하지 않는다면 인스턴스를 죽여둬서 운영비를 절감할 수 있다는 장점까지 있다....
음.. 내가 이걸 왜 쓰냐면, 이렇게 포스팅 해두면 다음주엔 코딩 좀 하겠지 싶어서 써둔다. 후
