2007년 04월 04일
inotify NFS에서는 제대로 작동되지 않더라
설정 파일의 변화를 감지해서 자동으로 다시 불러들이는 기능을 구현하기 위해 리눅스의 inotify를 이용하려 했었다(링크). 테스트 코드를 돌려 보고 알게 되었는데 NFS 위에서는 notify가 되지 않는다. 시차가 있는 것이 아니라 아예 안 된다(젠장)!
왜 gamin이 디렉터리 또는 마운트 종류별로 monitoring하는 방식을 지정할 수 있게 했는지 알겠다. 안 되는 경우가 있으니 polling으로라도 검출할 수 있게 한 것이다.
NFS 위에 설정 파일을 놓고 클러스터 상의 서버들이 이를 공유하도록 구성할 예정이었기에 inotify를 이용하는 것은 포기했다. 결국 가장 간단한 방식인 주기적으로 파일을 체크하는 방식을 썼다. NFS에서 파일 변화가 로컬보다는 늦게 감지되지만 어쨌든 작동은 한다.
그래도 JNotify로 테스트해서 별 수고 없이 안 되는 것을 알아내서 다행이다. 만약 처음부터 JNI로 구현해서 테스트했다면 꽤 삽질을 많이 한 꼴이 됐을 꺼다. 바퀴를 다시 발명하지 말라는 말은 그래서 명심해야 할 격언이다.
왜 gamin이 디렉터리 또는 마운트 종류별로 monitoring하는 방식을 지정할 수 있게 했는지 알겠다. 안 되는 경우가 있으니 polling으로라도 검출할 수 있게 한 것이다.
NFS 위에 설정 파일을 놓고 클러스터 상의 서버들이 이를 공유하도록 구성할 예정이었기에 inotify를 이용하는 것은 포기했다. 결국 가장 간단한 방식인 주기적으로 파일을 체크하는 방식을 썼다. NFS에서 파일 변화가 로컬보다는 늦게 감지되지만 어쨌든 작동은 한다.
그래도 JNotify로 테스트해서 별 수고 없이 안 되는 것을 알아내서 다행이다. 만약 처음부터 JNI로 구현해서 테스트했다면 꽤 삽질을 많이 한 꼴이 됐을 꺼다. 바퀴를 다시 발명하지 말라는 말은 그래서 명심해야 할 격언이다.
# by | 2007/04/04 17:14 | 트랙백
2007년 03월 21일
설정 파일의 변화를 감지하는 방법
웹 애플리케이션을 개발할 때 애플리케이션의 여러 값들은 직접 코드에 넣지 않고(하드 코딩이라 한다) 보통 설정 파일로 빼놓고 이를 읽어 들여서 사용하도록 개발한다. 이로써 프로그램에 변경 사항이 있을 때 단지 설정 파일만 바꾸어 변경을 할 수 있게 된다. 개발 당시 환경과 실제 운영 환경은 다른 경우가 많기 때문에 프로그램 전개(deploy)에 문제 없기 위해서는 꼭 필요한 일이기도 하다.
성능 문제가 있기 때문에 설정 파일을 읽어 값을 구성하는 일은 매 값을 읽을 때마다 하지 않고 애플리케이션이 구동될 때(웹 애플리케이션의 경우 WAS가 기동되고 서블릿들이 기동되기 전) 한번만 하여 메모리에 올려 두는 경우가 많다. 이 경우 설정 파일의 내용을 바꾸었을 때 바뀐 내용을 적용시키는 것이 문제가 된다.
이 문제를 해결하는 거로는 몇가지 방법이 있겠다. 설정 파일의 변경을 감시하는 스레드를 생성하여 주기적으로 설정 파일의 변경 상태를 감시하게 하는 방법이 있겠고, 설정 파일을 다시 읽어들이는 메서드를 만들고 이를 외부로 노출시켜서 명령을 내리게 하는 방법도 있다. 외부로 노출시키는 데에는 xmlrpc를 써도 되고 jmx를 쓸 수도 있으며 아예 TCP 접속 서버 스레드를 만들어 명령어를 해석하게 해도 된다.
여러 서버를 병렬로 운영하는 클러스터링 환경에서는 직접 명령을 내리는 방법은 번거로울 때가 많다. 한번에 모든 노드에 명령을 보낼 수 있게 만들 수도 있지만 만드는 일이 꽤 번거로운 일이다. 아무래도 설정 파일의 변경을 자동으로 감지할 수 있게 하는 것이 여러모로 편하다.
감시 스레드로 주기적으로 감시하는 방법 외에 파일의 변화를 즉각 알아차릴 수 있는 방법이 없을까해서 자료를 찾아 보았다. 리눅스 2.6 커널에서는 inotify 라는 것을 통해 이런 작업을 할 수 있는 거 같다. FAM이라는 것도 있지만 이는 따로 데몬을 띄워야 하므로 관리가 귀찮아진다. 윈도우즈에도 IO 관련해서 비슷한 것이 있다지만 윈도우즈 환경은 관심이 없으므로 패스.
inotify를 이용하려면 inotify 지원을 포함하여 커널을 컴파일해야 한다. inotify는 커널 2.6.13 버전 이후에 공식 포함되었다고 한다. 커널 설정 단계에서 FileSystem 설정 부분에서 inotify 지원을 켜고 컴파일해야 한다. 기본값으로 켜져 있는 것을 보니 기본으로 포함되어 있는 경우가 많나 보다.
커널 관련 문서가 있는 곳에 inotify 문서가 있다(Document/filesystems/inotify.txt). 이 문서를 살펴보니 사용은 별로 어렵지 않을 듯 하다. inotify를 시작한 후 원하는 디렉터리를 등록하고 등록시 얻은 descriptor를 마치 파일 디스크립터처럼 사용하면 되는 거 같다. select나 poll로도 이용할 수 있다고 한다.
어찌되었든 대충 이 방향으로 작업하려 한다. Native Library 관리만 주의하면 별 문제는 없을 듯 하다.
성능 문제가 있기 때문에 설정 파일을 읽어 값을 구성하는 일은 매 값을 읽을 때마다 하지 않고 애플리케이션이 구동될 때(웹 애플리케이션의 경우 WAS가 기동되고 서블릿들이 기동되기 전) 한번만 하여 메모리에 올려 두는 경우가 많다. 이 경우 설정 파일의 내용을 바꾸었을 때 바뀐 내용을 적용시키는 것이 문제가 된다.
이 문제를 해결하는 거로는 몇가지 방법이 있겠다. 설정 파일의 변경을 감시하는 스레드를 생성하여 주기적으로 설정 파일의 변경 상태를 감시하게 하는 방법이 있겠고, 설정 파일을 다시 읽어들이는 메서드를 만들고 이를 외부로 노출시켜서 명령을 내리게 하는 방법도 있다. 외부로 노출시키는 데에는 xmlrpc를 써도 되고 jmx를 쓸 수도 있으며 아예 TCP 접속 서버 스레드를 만들어 명령어를 해석하게 해도 된다.
여러 서버를 병렬로 운영하는 클러스터링 환경에서는 직접 명령을 내리는 방법은 번거로울 때가 많다. 한번에 모든 노드에 명령을 보낼 수 있게 만들 수도 있지만 만드는 일이 꽤 번거로운 일이다. 아무래도 설정 파일의 변경을 자동으로 감지할 수 있게 하는 것이 여러모로 편하다.
감시 스레드로 주기적으로 감시하는 방법 외에 파일의 변화를 즉각 알아차릴 수 있는 방법이 없을까해서 자료를 찾아 보았다. 리눅스 2.6 커널에서는 inotify 라는 것을 통해 이런 작업을 할 수 있는 거 같다. FAM이라는 것도 있지만 이는 따로 데몬을 띄워야 하므로 관리가 귀찮아진다. 윈도우즈에도 IO 관련해서 비슷한 것이 있다지만 윈도우즈 환경은 관심이 없으므로 패스.
inotify를 이용하려면 inotify 지원을 포함하여 커널을 컴파일해야 한다. inotify는 커널 2.6.13 버전 이후에 공식 포함되었다고 한다. 커널 설정 단계에서 FileSystem 설정 부분에서 inotify 지원을 켜고 컴파일해야 한다. 기본값으로 켜져 있는 것을 보니 기본으로 포함되어 있는 경우가 많나 보다.
커널 관련 문서가 있는 곳에 inotify 문서가 있다(Document/filesystems/inotify.txt). 이 문서를 살펴보니 사용은 별로 어렵지 않을 듯 하다. inotify를 시작한 후 원하는 디렉터리를 등록하고 등록시 얻은 descriptor를 마치 파일 디스크립터처럼 사용하면 되는 거 같다. select나 poll로도 이용할 수 있다고 한다.
int fd = inotify_init();
int wd = inotify_add_watch(fd, "path name", IN_MODIFY || IN_OPEN);
...
size_t len = read(fd, buf, BUF_LEN);
while (i < len) {
event = (struct inotify_event *)&buf[i];
....
i += sizeof(struct inotify_event) + event->len;
}
...
inotify_rm_watch(fd, wd);
close(fd);
- 위키피디아 설명: http://en.wikipedia.org/wiki/Inotify
- IBM developer works 문서(오래되어 현재 내용과 다른 점도 있음): http://www-128.ibm.com/developerworks/linux/library/l-inotify.html
어찌되었든 대충 이 방향으로 작업하려 한다. Native Library 관리만 주의하면 별 문제는 없을 듯 하다.
# by | 2007/03/21 20:36 | 트랙백
◀ 이전 페이지다음 페이지 ▶



















