1. 현상 최근에 검색 서버를 이전하면서 유예기간을 두어 옛 서버와 새 서버를 동시에 지원해두기로 결정했다. 그런데 DNS에 두 IP를 Round-Robin 방식으로 요청할 때마다 다른 IP를 줄 수 있도록 변경했는데, 실제 JVM의 서비스에서는 아무리 해도 새 서버 IP으로 요청을 하지 않는 것이 었다.
2. 첫 시도 일단 캐시를 의심을 했다. 이런 경우 실정보 반영이 느린 캐시가 범인인 경우가 많은데, 여러가지 캐시들을 차근차근 정리했다.
3. JVM JVM에서는 Host Name resolutions에 caching을 지원하고 있다. 캐시 방법에는 두가지 방식이 있는데 positive, negative로 각각 성공했을 경우와 실패했을 경우 캐시 유지 정책을 뜻한다. 이 값을 설정하는 방법에는 두가지가 있는데,
$JAVA_HOME/jre/lib/security/java.security 에서 설정값을 넣어주는 경우
java.security.Security.setProperty("key","value")으로 값을 넣어주는 경우
이며 그 키와 밸류 값은 다음과 같다.
networkaddress.cache.ttl : name lookup이 성공했을 경우 갱신할 초, 기본값 -1으로 영원한 캐시
networkaddress.cache.negative.ttl : 실패했을 경우 갱신할 초, 기본값 10초
설정값을 변경하고 Tomcat을 종료, 시작 했다.
4. 현상 지속 현상은 지속되고 있었다. HttpClient 라이브러리를 사용하고 있었기 때문에 도대체 어떤일이 벌어지고 있는지 알 필요성을 느꼈다. 마침 사내에서 JProbe 8.0을 구매해두었기 때문에 설치에 들어갔다. 한참은 보다가 문득 JVM단위에서 문제가 있을 수도 있다는 생각이 들었다. 예전에 CVM(cdc)이라는 Sun에서 나온 J2ME 구현체를 포팅할 때 Multicast관련 설정 문제로 한참 고생하다 결국 CVM의 버그인 것을 밝혔던 경험이 영향을 미친 것 같다.
5. 문제 발견 먼저 가장 손쉽게 JVM 어플리케이션을 띄울 수 있는 방법은 Groovy라고 판단이 들었다. 그루비 설치 후 간단한 스크립트로 확인했다.
6. 문제 검증 혹시 나만 이런 현상을 느끼고 있는 것은 아닌지 구글링을 통해 다른 사람들의 아우성들을 보도록 했다. 특히 눈길 끈 문서는 톰캣 개발팀의 메일링 리스트 였다. networkaddress.cache.ttl이라든지 getByName이라든지 현상이라든지 유사점이 무척 많았다.
The multiple InetAddress.getByName() calls in the above for-loop all return the first IP returned from InetAddress.getAllByName() as though it is cached, even though the network.cache.ttl setting is clearly changed to "0".
하지만 Tomcat 4이라는 너무 오래된 버전에서의 이야기였다. 그리고 Tomcat에서의 문제라니. 그럼 그루비에서는 발생하지 않아야 하는 법이다.
7. 원인 getByName을 집중적으로 공략해보기로 했다. 일단 Java Doc에서는 아무런 언급이 없었다. 소스를 보아도 내부 필드를 바로 반환하는 방식으로 별 도움은 되지 못했다. Inet4Address 클래스도 보았다. 첫번째 의심 코드는 sun.net.util.IPAddressUtil.textToNumericFormatV4이었는데 소스를 보니 단순히 포맷팅과 관련있었다. 두번째 의심코드는 InetAddress.getAddressFromNameSevice이었는데 이부분은 모든 InetAddress를 반환하도록 되어 있었다.
첫 시작은 대학교 동아리 홈페이지 입니다. 후배들이 자체 제작한 시스템이었는데 모든 게시글에 트랙백 붙이는 것을 지원해 주었습니다. (어떻게 로그인을 위한 사이트에 트랙백을 붙였는지 지금 생각해보면 의아하군요)
두번째 영향은 포럼이라는 형식의 여러 커뮤니티 였습니다. 글을 한참 읽다 보면 어떤 질문에 대해 답변자가 자기 블로그에 이미 다 정리된 글을 보라면서 링크를 남기는 것을 보았습니다. 으흠 링크 타고 들어가서 정리해 보기에는 영 귀찮은 것입니다.
세번째 영향은 블로그 메타 사이트들의 영향입니다. 의견이 분분한 사건에 대해 여러 사람들이 의견을 나누고 그것을 블로그스피어라고 통칭 하지만 컨텐츠 소비자인 저에게는 글들의 흐름이라든지 전후 관계를 파악하는 것이 무척이나 어려운 일이라는 생각이 들었습니다.
네번째 영향은 커뮤니티의 죽음에 대한 글입니다. 어렴풋이 인지하고 있었지만, 확실하게 느끼지 못하고 있었던 사건은 바로 블로그의 성장과 대비되는 커뮤니티의 몰락입니다. 물론 아직까지 블로깅을 하지 않는 분들이 많고 그런 분들 중에서는 카페 같은 곳에서 많은 활동을 하는 분들이 있지만, 최소한 어느 커뮤니티들을 운영하거나 깊은 개입을 할 수 있을 정도의 영향력 있는 분들은 대부분 파워 블로그라는 타이틀로 자신들의 블로그들을 운영 중이라는 생각이 들었습니다. 풍요 속의 빈곤이라는 말처럼, 혹은 그 섬에 가고 싶다는 말 처럼 풍부한 인터넷의 바다에서 외롭게 굶어 가고 있는 무인도 같은 느낌이었습니다. 메타 블로그들은 아직까지 그런 엮음에 대한 반영을 하지 못하고 있다고 생각합니다.
다섯째 영향은 아고라라는 토론 서비스 입니다. 정보의 자기복제및 재 생산을 끊임없이 하고 있는 모습을 보면서 만약 내 글이 쓰게 되어지는 문맥들을 전달할 수 있다면 어떤 결과가 나올지 무척 궁금해졌습니다. 글을 쓰면서 전, 후 문맥 관계를 매번 설정하고 알리는 것은 무척이나 까다로운 일입니다. 어떤 과정이 있어서 이런 생각을 하게 되었다는 부분을 전달하고 싶었습니다. 현대 사회는 너무 단편적이고, 순간적인 정보가 있다고 느껴집니다.
구슬도 꿰어야 보배라는 말과 같이 여러 보화 같은 블로그들을 하나의 실로 꿰어 낼 수 있는 그런 포럼이 필요 했습니다.
그것이 바로 Open Thread : 열린 글타래 입니다.
이것을 위해 시작한 프로젝트가 있습니다.
S.H.O.T(코드명)
python + Django 시스템을 기반으로 하고 있습니다. 파이선은 다루어 본 적이 있지만 장고에 대해서는 문외한이라 조금 어려움을 겪고 있지만, 구글 코드(프로젝트관리서비스)에 의존해 관리 할 생각입니다. 추후 구글앱스에 얹어내고 구글 광고 시스템으로 서비스 운영비를 충당해 볼 생각입니다.
