Swappiness in Linux 2.6

1개의 댓글 / Software Development / /

Linux 2.6의 swap 경향은 mm/vmscan.c에 의하면 다음과 같이 정의된다.

swap_tendency = mapped_ratio / 2 + distress + sc->swappiness;

이 때, mapped_ratio는 다음과 정의된다.

/*
* The point of this algorithm is to decide when to start
* reclaiming mapped memory instead of just pagecache.  Work out
* how much memory
* is mapped.
*/
mapped_ratio = ((global_page_state(NR_FILE_MAPPED) +
global_page_state(NR_ANON_PAGES)) * 100) /
vm_total_pages;

즉, mapped_ratio는 전체 메모리 크기에 대한 애플리케이션이 사용하고 있는 메모리 크기의 비율이다.

distress는 다음과 같이 정의된다.

/*
* `distress' is a measure of how much trouble we're having
* reclaiming pages.  0 -> no problems.  100 -> great trouble.
*/
distress = 100 >> min(zone->prev_priority, priority);

include/linux/mmzone.h에 따르면, priority는 priority of VM scanning이며, (아마도 free page를 확보하기 위해) 한번에 zone별 page 리스트를 스캐닝 하는 페이지의 수를 얻는데 (queue_length >> priority) 사용되며, 디폴트 값은 12로 한번에 2^12 = 4096개의 페이지를 스캔하는 것을 의미한다. (아마 free page를 확보하지 못해,) priority가 올라갈 수록 (값이 낮아질수록) 많은 페이지를 스캔하게 된다. 2.6 VM을 제대로 공부하지 않아서 이 부분은 확신할 수는 없다.

어쨌든, priority가 디폴트 값인 12일 때, distress값은 100/2^12 = 0이다.

swappiness는 sysctl이나 /proc/sys/vm/swappiness를 통해 사용자가 설정할 수 있는 파라미터이며, 0-100 사이의 값을 갖는다. swappiness의 디폴트 값은 60이다.

/*
* From 0 .. 100.  Higher means more swappy.
*/
int vm_swappiness = 60;

이런 값들로부터 계산된 swap_tendency가 100이 넘으면, mapped memory를 inactive list로 옮기기 시작한다. 다시 말하면, swap을 시작하게 된다.

예를 들어, 2GB의 메모리를 가지고 있는데, 1.8GB의 메모리를 애플리케이션이 사용하고 있고, distress가 0인 상태라면, swap_tendency는 1.8GB * 100 / 2GB / 2 + 0 + 60 = 105가 되어, swap 되기 시작한다.

결국, swap_tendency를 산출하는 식에 따르면, swappiness가 디폴트 값 60인 상태에서는 80% 이상의 메모리를 사용하기 시작하면, swap하기 시작한다. 다음과 같은 방법으로 swappiness 값을 조정함으로써, 이러한 swap behavior를 조정할 수 있다.

sysctl -w vm.swappiness=30

또는,

echo 30 >/proc/sys/vm/swappiness

References

Swappiness in Linux 2.6 더 읽기"

Web Search Engine Startups

댓글 달기 / Stray Thoughts / /

우리나라에서도 스타트업들의 웹 검색엔진들이 간혹 나오고 있지만, 검색엔진으로서의 기본적인 품질을 만족하는 것은 매우 드문 것 같다. 블로거스피어를 통해서 잠시 회자된다 하더라도 품질이 뒷받침 되지 않은 유명세는 의미없는 것이다.

검색엔진을 만났을 때 맨처음 해보는 쿼리는 두가지다. 바로 매우 일반적인 표제어에 해당하는 쿼리 – 나의 경우 주로 ‘C++’ – 와 최신성을 반영하는 쿼리 – 오늘 같으면 ‘원더걸스 수능’ 이다. 그리고, 이 간단한 쿼리 두 가지도 무난하게 처리하지 못하는 경우가 대부분이다.

검색 엔진이 해야할 일들은 너무나도 많고, 비용도 많이 들며, 경험도 많이 필요해서, 스타트업이 웹 검색 엔진을 제대로 하기란 정말 어려운 일이라고 생각한다. 이해할 수 있다. 하지만, 그 이상은 아니다. 스타트업의 용기를 칭찬하고 북돋아주는 소수의 블로거들을 제외한 나머지 사용자들은, 웹 검색엔진 스타트업의 사정을 어느 정도 이해하는 소프트웨어 엔지니어들보다는, 훨씬 냉정하다.

Web Search Engine Startups 더 읽기"

Proactive Attitude to Solve Problems

댓글 달기 / Uncategorized / /

얼마전 회사 워크샵, 아니 플레이샵을 마치고 집으로 또는 회사로 돌아갈 때의 일이었다.

난 회사에 들를 일이 있어서, 회사로 향하는 차에 타기로 했다. 그 때, 팀장님이 내게 프로젝터를 건내며 말했다.

"회사 들를거지? 이거 책임지고 회사에 갖다 놔."

나는 엑스박스도 들고 온터라 이래 저래 짐이 많았다.

"전 짐이 많아서…"

잠시 정적이 흘렀다.

워크샵 운영을 책임진 분이 분주하게 돌아다니다 프로젝터를 받아들어 차에 실으며 말했다.

"회사에 가시는 분들이 이 프로젝터 좀 회사에 가져다 놔 주세요."

아차 싶었다.

내가 짐이 많은 것은 사실이지만, 프로젝터를 두고 가거나 집으로 가져갈 수는 없으니, 어차피 회사로 가져다 둘 짐은 회사로 향하는 차에 실어야 하는 것이고, 또 회사로 향하는 차에 탄 사람이 책임을 져야하는 것이었다.

일을 하다보면 위와 같은 실수를 하는 사람이 비단 나만 있는 것은 아니다.

자신의 역할에 해당하는 문제가 아니라고, 또는 자신이 해결하기에 곤란하다고, 그 문제의 해결을 방관하거나 거절하는 경우가 있다. 하지만, 그 문제는 누군가는 해결해야하는 문제인 경우가 있다. 문제가 주어졌을 때, 그 문제가 자신만의 책임이 아니거나, 자신만의 힘으로 문제 해결이 어려운 상황에 부닥치더라도, 그 문제의 해결 방법을 모색해보는 태도가 프로페셔널에게는 필요하다. 물론, 이 말은 자신이 해결할 수 없는데도 해결할 수 있다고 거짓말을 하라는 얘기가 아니다. 이러한 태도가 있느냐 없느냐가 좀 더 성숙된 프로페셔널이냐 아니냐를 구분하는 잣대 중 하나라고 생각된다. (또한 그러한 태도가 없는 사람들이 답답하기도 하다.)

아마도 그 때 난 다음과 같이 말했더라면 좋았을 것이다.

"아, 제가 짐이 많긴 한데, 같이 가시는 분들이랑 함께 갖다놓도록 하죠."

Proactive Attitude to Solve Problems 더 읽기"

An Understanding

댓글 달기 / Stray Thoughts / /

초등학교나 중학교에 다니던 시절은 차라리 행복했다. 그가 아무것도 하지 않아도 그를 좋아하고 곁을 지켜주는 사람들이 있었다.

전조는 아마도 고등학교 시절부터 였는지도 모르겠다. 가벼운 말다툼 후 둘은 서로 사과하지 않았고, 졸업 후에 만나서도, 가벼운 인사치레만 나눌 수 있을 뿐이었다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 그의 미래에 대해 생각하기도 전에 대학교에 다니게 되었다. 대학교 시절에는 고등학교 친구들도 많았는데, 가장 친한 고등학교 친구 한명에게 실소가 나오는 이유로 주먹을 맞고나서, 그는 그 친구에게 핀잔인 듯한 소리를 했고, 그 친구는 사과했지만, 이후로 그도 그 친구도 원래처럼 대하지 못했다. 그래도, 그는 그 친구를 이해할 수 있었다.

그래도 대학시절 동안 그에게는 어울려 술마시고 함께 어깨동무를 하고 노래부를 대학 친구들이 있었다. 하지만, 대학을 졸업하고나자, 그 중 가장 친한 친구는 졸업 후에 점점 바빠지더니, 가벼운 부탁조차도 들어주지 않는 사이가 되었다. 그에게는 그저 가벼운 부탁이란 건 없었는데도 말이다. 그래도, 그는 그 친구를 이해할 수 있었다.

그에게는 특별한 친구 한명이 있었다. 그 친구는 그에게 지적인 자극을 주었으며, 음악의 기쁨을 함께 해주었다. 하지만, 그런 즐거움은 순간일 뿐이었고, 그 친구는 떠나갔다. 그 친구는 필요할 때마다 그를 찾았지만, 역시 자신이 필요할 때마다 떠나갔다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 직장을 가지게 되었다. 대학 친구들 중 몇몇은 그와 같은 일을 하게 되었고, 전문적인 의견을 종종 나누는 친구들도 생겼다. 하지만 그 친구들은 전문적인 의견을 물어보기 위해서 그와 이야기했고, 그가 뭔가 이야기 하고 싶다고 하면 바쁘다고 했다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 일을 하다가 좋은 동료들을 만났다. 동료들은 마치 친구처럼 그에게 관심을 보여주었고, 그도 그들에게 친구와 같이 마음의 문을 열어주었다. 하지만 그런 동료들도 다른 직장으로 옮기게 되어, 더이상 동료가 아니게 되자, 더이상 그에게 관심을 보이지 않게 되었다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 그가 말을 걸 수 있는 사람들이 별로 남지않게되자, 네트웍으로 사람들과 이야기하기 시작했다. 네트웍에는 많은 사람들이 있었고, 그들 중 몇몇은 그와 관심사도 생각도 비슷해서 친구처럼 지낼 수 있었다. 하지만, 그와 그들 사이에는 뭔가 친해지기 어려운 벽 같은 것이 있었다. 그들과 조금 친해졌다 싶어도, 자고 일어나면 그 벽은 다시 자라나있었다. 그러다보면 그들은 저절로 그로부터 멀어져갔다. 그래도, 그는 그 친구를 이해할 수 있었다.

그의 주위에 친구라고 할 만한 사람들이 거의 없어지자, 그는 외로웠다. 그에게는 삶의 목적이 있었고 삶에의 열망도 있었지만, 외로운 삶 자체는 너무 고통스러웠다. 그래서, 그는 자살하기로 마음먹었다. 하지만, 삶에의 열망이 매듭을 묶는 그의 손을 배반하여 그 자살은 실패로 돌아갔다. 그는 정신과 의사를 마주하게 되었다. 의사는 정말 그를 이해한 것 같았고, 그가 살겠다는 의지만 있다면, 그를 돕겠다고 약속했다. 그는 성실하게 의사와 정기적으로 면담을 했고 약도 빠뜨리지 않고 먹었다. 의사 친구가 웃으며 더이상 병원에 오지않아도 된다고 얘기했다. 그 날 이후로 의사는 그에게 아무것도 요구하지 않았고, 그가 요구를 해도 아무것도 받아주지 않을 것 같았다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 일과 친구가 되기로 했다. 그 친구는 말은 없었지만 솔직했고 늘 그의 곁에 있었다. 그는 직장에서 인정을 받았고, 직장 내의 누구나 그를 칭찬했다. 이윽고 그는 은퇴할 때가 되었고, 일이란 친구는 더이상 그가 필요하지 않다고 털어놓았다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 병에 걸렸다. 그는 잠시 생각했다. 이 병이 내 새로운 친구가 되어줄 수 있을까. 그는 알 수 있었다. 이 친구도 언젠가 소리없이 나를 떠나가겠지. 병은 그의 생각을 아는지 모르는지 그를 점점 장악하여 쇠약하게 만들고 있었다. 그래도, 그는 그 친구를 이해할 수 있었다.

병과 싸우는 일은 고통스러웠지만, 의외로 끝은 빨리 찾아왔다. 그와 친구가 되고 싶지는 않다는 투로 의사가 그에게는 이제 몇달의 시간밖에 없다는 것을 알려주었다. 삶도 나를 떠나가는구나. 그는 심한 배신감을 느꼈다. 그래도, 그는 그 친구를 이해할 수 있었다.

그는 그가 죽어가고 있다는 것을 알 수 있었다. 마지막 호흡이 잦아오는 동안 그는 기뻐했다. 죽음이 그의 새로운 친구이며, 그 친구는 그를 절대 배신하지 않을 것임을 깨달았다. 그는 후회했다. 그가 죽음과 친구가 될 수 있었을 때, 왜 삶을 한번 더 믿었던가를. 그가 눈을 감을 때, 그 친구는 속삭였다. 그가 삶을 살지 않았더라면, 나라는 친구가 얼마나 좋은 친구인지를 깨닫지 못했을거라고. 그제서야, 그는 그 친구를 이해할 수 있었다.

An Understanding 더 읽기"

WebCrawler

댓글 달기 / Software Development / /

Pinkerton, B. 1994. Finding What People Want: Experiences with the WebCrawler

이 논문은 1994년 10월, Chicago에서 열린 두번째 WWW 컨퍼런스에서 발표된 논문이다. WebCrawler 역시 웹의 resource discovery 문제 해결을 위해 웹 크롤러를 사용하는 검색엔진에 해당한다. 불과 5개월 간격이지만 첫번째 WWW 컨퍼런스에 등장한 검색엔진에 비해서 꽤 완성도 면에 있어서 나아진 면을 보인다.

WebCrawler의 디자인에 대한 설명은 웹에 대해서 잘 모르는 사람들도 이해할 수 있을 정도로 자세하고 쉽게 되어있어서, 웹 크롤러에 대한 설명이 필요하다면 참고할 만하다. WebCrawler의 architecture는 크게 Search Engine, Agents, Database, Query Server로 이루어진다. Search Engine은 크롤과 인덱싱 작업을 담당하며, 여러 프로세스 (15개)로 동시에 동작하는 Agents는 실제로 웹 페이지를 다운로드 받는 역할을 한다. Database는 문서의 메타데이터나 링크, full-text 인덱스를 저장한다. 특이한 점은 방문한 server들에 대한 정보를 가지고 있어서, 방문하지 않은 서버나 least recently visited 서버를 먼저 방문함으로써, 가능한 한 여러 서버들을 공평하게 방문하려고 시도한다는 것이다. Query Server는 사용자의 검색엔진 질의를 담당한다.

WebCrawler의 성능은 486 PC에서 1시간에 1000개의 문서를 인덱싱하는 정도라고 한다. 현재의 기계로는 1초에 그 정도 이상의 문서를 처리할 수 있음을 생각하면, 1000~10000배 이상의 성능 차이가 난다는 것을 알 수 있다. 게다가, 이러한 성능 차이는 웹 크롤러 – 검색엔진의 디자인에 많은 영향을 줄 것임에 틀림없다.

인덱싱은 IndexingKit이라는 라이브러리를 사용하는 것으로 보이고, lexical anlyzer, stop list, inverted index, vector-space model에 관한 언급들이 보인다.

이 논문에서 저자는 6개월 간의 WebCrawler 운영을 통한 교훈을 정리해놓았는데, 다음과 같다.

  • Full-text indexing is necessary
    • 당시에도 20% 가량의 웹 페이지들은 title을 가지고 있지 않았으며, title의 유효성을 인정하기 어렵기 때문에, full-text 인덱싱이 필수적이라는 견해를 보인다. 그리고 실제로 사람들이 원하는 것은 title이 아닌 내용에 대한 좀 더 나은 쿼리 기능을 원하고 있다는 면에서 full-text 인덱싱의 중요성을 설명하고 있다.
  • Precison is the limiting factor in finding documents
    • WebCrawler는 Recall을 적절히 만족시키고 있지만(adequate), Precison의 면에서 만족스럽지 못하다고 얘기하고 있다. 문서의 weighting이 도움이 되지만 false positive (irrelevant documents)를 제거하고 있지는 못했다고 한다. (이 문제는 랭킹의 문제로 보인다.) 또다른 문제는 사용자가 well-focused query를 던지지 못하는 문제를 언급하고 있으며, 사용자 쿼리의 평균 단어 수가 1.5이었다고 한다. 검색엔진이 보편화된 현재도 사용자들은 여전히 단순한 쿼리를 던지고 있다.
  • Breadth-first searching at the server level builds a useful index
    • 어떤 정보를 가지고 있는 서버만 발견할 수 있다면, 사용자들은 그 서버 내에서 좀 더 쉽게 navigate할 수 있기 때문에, Breadth-first searching이 사용자들을 만족시켜준다고 한다. navigational search라는 검색엔진의 용도라고 볼 수 있을 듯 하다. 또한, 크롤 전략 – 순서가 검색 결과에 영향을 미칠 수 있다는 인식이 보인다. 한편, BFS 크롤 전략의 다른 이익으로 politeness를 언급하고 있기도 하다.
  • Robot-like behavior is necessary now
    • 크롤러가 웹 트래픽을 낭비한다는 비판에 대해서 크롤러를 통해 오히려 웹 트래픽을 절감할 수 있다고 주장하고 있다. ALIWEB과 같이 사이트 별 인덱스를 사용하는 것이 아니라, 실제 문서를 인덱싱에 사용함으로써, 좀 더 나은 인덱싱 방법을 사용할 수 있음을 지적하고 있다.
  • Widespread client-based searching is not yet practical
    • 클라이언트에서 크롤러를 동작시켜 문서를 찾아내는 방법은 하나의 서버에서 인덱스를 만드는 방법에 비해 효율적이지 않음을 지적하고 있다. Future Work에서 클라이언트 기반 검색을 하더라도 이 결과를 사용자들이 공유하는 인덱스에 추가하는 방법을 제안하고 있다.

Future Work에서 좀 더 강력한 full-text 엔진의 기능으로, proximity searching과 query expansion & refinement를 제안하고 있다.

결론에서 크롤러에 기반한 검색엔진을 분산된 웹의 특성에 비유하고 있다. 크롤러에 기반한 검색엔진은, 웹 사이트들로부터 (아마도 인덱스 생성과 같은) 특별한 참여를 필요로 하지도 않고, 웹 프로토콜을 그대로 사용함으로써, 동작 방식과 정책의 분리가 가능해졌고, 여러 검색엔진이 여러가지 정책을 채용함으로써, 사용자는 자신의 필요에 적합한 검색엔진을 선택할 것이며, 기술은 좀 더 빠르게 성숙될 것이라고 저자는 예견하고 있다.

WebCrawler 더 읽기"

RBSE Spider

댓글 달기 / Software Development / /

Eichmann D. 1994. The RBSE Spider – Balancing Effective Search Against Web Load

1993년은 여러가지 목적을 가진 웹 크롤러들이 출현하기 시작한 해였다. 예를 들어, 최초의 크롤러로 기록되고 있는 World Wide Web Wanderer는 웹의 크기와 성장를 측정하기 위한 용도로 만들어졌다. 한편, RBSE Spider는 웹 검색엔진을 위한 크롤러로 만들어졌으며, 제목과 헤더들만 인덱싱하던 JumpStation과 달리 Full-text 인덱싱하는 검색 엔진의 일부분이었다. (이 때는 아직 검색 엔진과 크롤러의 구분이 모호했다.) 따라서, RBSE Spider는 웹 크롤러를 사용하는 최초의 Full-Text 검색 엔진이라고 볼 수 있다.

크롤러와 인덱서의 분리

크롤러의 architecture면에서 RBSE Spider는 크롤러를 인덱서로부터 분리했다. 크롤러와 인덱서를 분리함으로써 separation of concern의 효과를 얻을 뿐만 아니라, 각각의 컴포넌트를 다른 용도로도 사용할 수 있게 되었다. 하지만, RBSE Spider는 크롤러가 웹 페이지의 발견(discovery)만을 수행할 뿐, 저장하지 않았기 때문에, 크롤러가 발견한 웹 페이지를 받아오기 위해서 인덱서가 다시 방문해야 했다.

Incremental Crawler

크롤러와 인덱서를 분리하지 않을 수 없었던 또다른 이유는 incremental한 크롤러를 만들기 위한 것이었고, 크롤러가 incremental해야만 했던 이유는 robust한 (그러니까 잘 죽지 않는) 크롤러를 만들기가 어려웠기 때문이라고 한다. 그들의 이유는 조금 우습지만, 현재는 웹의 크기가 커지면서 incremental한 크롤러는 필수적인 것이 되었다.

Politeness

당시에 여러 목적의 크롤러들이 늘어나면서 크롤러가 유발하는 웹서버의 로드에 대한 우려가 생기기 시작했고, 이는 Koster의 Guidelines for Robot Writers라는 문서의 제안으로 이어졌다. RBSE Spider는 User-Agent 필드를 이용한 identification 등 Robot exclusion protocol을 따르며, 웹 서버에 로드를 주지 않기 위해 주의하고 있다.

상세한 구현

RBSE Spider의 크롤러 부분은 두개의 프로그램으로 이루어져 있다. 그 하나는 mite라는 프로그램인데, 주어진 URL의 문서를 다운로드한 후, 문서 내에 포함된 URL들을 출력해주는 것이다. 다른 프로그램은 특정 패턴을 가진 URL들에 대한 링크를 mite를 이용해서 추출한 다음 source-target pair들을 Oracle 데이터베이스에 저장하는 역할을 한다. 데이터베이스에는 다시 방문하는 것을 방지하기 위해, 다운로드에 실패하거나 링크가 없는 경우의 로그가 있다. Robot exclusion protocol에 따라 받아서는 안되는 URL들의 패턴들의 리스트도 있다.

페이지의 텍스트를 저장하지 않는 것을 제외하고는 기초적인 크롤러의 기능들을 갖추고 있다고 볼 수 있다.

인덱서 부분은 좀 더 단순하다. 데이터베이스로부터 URL들을 가져온다음 이들을 waisindexer라는 프로그램에 집어넣으면, waisindexer는 다시 mite를 사용해서 URL에 해당하는 페이지를 다운로드한 다음 이들을 인덱싱한다. 인덱싱 부분은 거의 WAIS의 인프라를 활용함으로써 relevance feedback도 활용할 수 있다고 한다.

검색 엔진의 역할

이 paper는 크롤러에 대한 Rationale로서 크롤러가 마치 지도와 같은 역할로, 사용자가 원하는 페이지에 바로 찾아갈 수 있도록 함으로써, 네트워크 트래픽을 감소시킬 수 있다고 주장하고 있다. 이는 당시에 클라이언트 기반의 검색엔진 등이 있었다는 것을 감안하면 옳은 주장이라고 생각되나 사실 현재에는 별로 의미가 없다.

당시에 증가하고 있던, 데이터베이스로부터  동적으로 생성된 페이지들을 인덱싱하지 말아야 한다는 주장은 지금 생각하면 완전히 잘못된 것이다. 당시엔 아마도 각 사이트에서 제대로 인덱싱 되고 있는 페이지들을 따로 인덱싱하는 것은 낭비라고 생각했을 것이다.

한편, 크롤러의 역할로서 내용 유사도(semantic similarity)에 따른 가상적인 이웃 (virtual neighborhoods) 정보를 생성할 수 있다고 얘기하고 있다. 당시에는 아마도 하나의 사이트는 특정한 주제를 취급하는 사이트였을테고 그런 사이트 몇개만 알면 특정 주제에 대한 검색이 가능했겠지만, 그 때까지 그 사이트들 사이의 내용 유사성에 기초한 어떤 서비스는 없었을 것이다. 현재의 일반적인 검색 엔진에서 제공하는 유사 페이지 검색이라든가 버티컬 검색 엔진 등을 생각하면 일리가 있다. 이제는 특정 사이트 몇몇이 특정 주제에 대한 포탈이 되기 힘들고, 검색 엔진의 쿼리를 통해서 또는 버티컬 검색 엔진을 통해서 그러한 서비스를 하고 있다.

RBSE Spider 더 읽기"

ALIWEB

댓글 달기 / Software Development / /

Koster, M. 1994. ALIWEB – Archie-Like Indexing in the WEB.

첫번째 WWW 컨퍼런스인 WWW ’94에 발표된 paper.

1990년 11월에 첫번째 웹서버가 생긴 이후로, 웹의 사용자와 정보의 크기는 점점 늘어나고 있었고, 1993년에는 200개 이상의 웹서버가 있다고 알려지게 되었다. 이렇게 되자, 웹에서 어떤 정보를 찾는 것은 점점 힘들어지게 되었고, 이 문제를 해결하기 위한 여러 노력들이 1993년부터 나타나기 시작했다. 그 결과로 나타난 첫번째 웹 검색엔진이 바로 ALIWEB이었다.

도입 부분에서, 웹의 resource discovery 방법이 진화한 과정을 Browsing – Listing – Searching (Catalogue) – Automatic Collection (from Catalogue) – Automatic Discovery의 단계로 설명하고 있는데 흥미롭다. 현재의 검색엔진에서 Automatic Discovery를 당연시하고 있는 것을 생각하면, 마치 FORTRAN Compiler가 탄생했을 때, 이를 Automatic Programming이라고 부르던 느낌이랄까.

한편, Archie란 여러 Anonymous FTP 사이트가 가지고 있는 파일들을 인덱싱하여 검색할 수 있도록 해주는 Anonymous FTP의 검색 엔진이었다. Archie의 동작 방식은 각 Anonymous FTP 사이트에서 파일 리스팅에 해당하는 파일을 받아서 사용자가 검색 가능하도록 해주는 것이었다. 이 paper에서 Archie-Like라고 부르는 것도 그러한 동작 방식을 사용했다는 것을 의미한다.

ALIWEB의 동작 방식은 다음과 같다.

  1. 웹사이트 관리자가 정해진 포맷으로 각 사이트에 대한 인덱스 파일을 만들고 이를 ALIWEB의 웹 인터페이스를 통해 등록한다.
  2. ALIWEB은 등록된 웹사이트들의 인덱스 파일들을 자동으로 받아와서 이를 검색 가능하도록 인덱싱한다.
  3. 검색을 원하는 사용자는 오늘날의 검색엔진 인터페이스와 거의 같은 모습의 ALIWEB의 웹 인터페이스를 통해서 쿼리를 보내고 결과를 볼 수 있다.

이 paper에서 밝히고 있는 ALIWEB의 문제점은 역시

  • 사이트별 인덱스 생성 과정의 어려움, 그리고
  • scalability

이다.

사실, 사이트 관리자에 의한 사이트별 인덱스 생성은, 사이트 관리자가 그 사이트에서 어떤 것이 인덱싱 되어야하는가를 가장 잘 알고 있을 것이라는 합리적인 의도를 가지고 있고, Koster는 이러한 방식이 적어도 medium term에서는 잘 동작할 것이라고 예상했지만, 실제로 이는 실패했다. 물론, 사이트 관리자에 의한 사이트별 인덱스 생성이라는 개념은 현재에도 Google Sitemap과 같은 형태로 존재하지만, 적어도 이러한 메커니즘이 Automatic Discovery의 주요한 역할을 맡고 있는 것은 아니다.

어쩌면, 텍스트를 위주로 한 현재의 웹에 대한 Automatic Discovery가 정점에 이르면, 오히려 장기적인 관점에서, 사이트 관리자에 의한 사이트별 인덱스 생성이라는 개념이 유효해질 가능성도 있다. Semantic Web이나 Web Services와 같은 웹을 구조화된 형태로 만드려는 노력이 어떤 방향으로 진행될지는 아직 미지수다.

Scalability의 문제는 프로토타입의 성격을 지닌 ALIWEB에서 해결되리라고 기대할만한 문제는 아니지만, 사이트별 인덱스를 사이트 내의 상위 레벨 서비스에 대해서만 생성한다든가, 특정 분류나 도메인에 한정된  ALIWEB 사이트를 만들어서 해결한다는 생각은 현재 시점에서 바라볼 때는 실망스럽다.

현재의 웹을 바라보면, 상위 레벨 서비스만 검색되면 되는 것이 아니라, 하위 레벨 페이지들이 실제로 사용자들에게 가장 흥미로운 내용을 포함하고 있고, 검색의 결과로서 적합한 경우도 많다. 한편, 특정 분류나 도메인에 한정된 검색도 물론 유용하지만, 이것이 Scalability 부족의 대안으로 나오는 것은 현재 웹의 크기를 고려할 때 바람직하지 못하다.

ALIWEB 더 읽기"

Use Boss-Worker model to accept connections with java.net.ServerSocket

댓글 달기 / Uncategorized / /

일반적인 소켓 API를 이용하여 멀티쓰레디드 서버 프로그램을 만들 때, 쓰레딩 방식을 결정함에 있어서, Boss-Worker 모델과 Peer 모델을 고려하게 됩니다.

서버 프로그램에 있어서 Boss-Worker 모델이라고 하면, (하나의) Boss thread에서 accept를 수행하고 Boss thread가 Worker thread에게 accept된 커넥션(connection)을 전달하여, Worker thread가 커넥션에 따른 서버 로직을 수행하는 것입니다. 한편, Peer 모델은 각 thread가 각자 커넥션을 accept하려고 시도하고, accept된 커넥션에 대해서 서버 로직을 각자의 thread에서 수행하는 것을 얘기합니다.

두 모델간에 어느 것이 낫냐는 질문을 종종 받곤 하는데, accept할 기회만 충분히 주어진다면, 큰 차이가 없다고 볼 수 있습니다. 굳이 말하자면, Peer 모델의 경우 (어떤 이유로든) thread 수가 부족하다면 accept될 기회가 없어서 자원이 남는데도 불구하고 불필요하게 처리량(throughput)이 떨어지는 서버가 만들어질 수도 있습니다. 클라이언트의 접속에 대해서 별 걱정없다는 면에서 Boss-Worker 모델이 좀 더 속편하다고 볼 수도 있습니다. 처리량의 문제는 클라이언트의 리퀘스트 양이라는 문제와 서버가 이를 처리할 수 있는 능력(capacity)이라는 문제와 연결되어있는데, 당연히 서버는 자신이 처리할 수 있는 양 이상을 처리하려고 시도하지 않아야겠죠. 이 때, 커넥션을 가지고 있는 상태에서 서비스할지 말지 결정하는 것이 커넥션이라는 하위 메커니즘에 대해서 이것저것 고민하는 것보다는 훨씬 편리합니다. (제 경험상, 다른 일을 할 수 없을 정도로 커넥션(클라이언트의 리퀘스트)이 들어오는 것은 상식적으로 클라이언트가 잘못된 상태거나 클라이언트-서버의 설계가 부적절하게 설계된 것입니다.)

원래 얘기로 돌아와서, Boss-Worker 모델과 Peer 모델은 적어도 POSIX 소켓 API를 이용하는 멀티쓰레디드 서버 프로그램에서는 일반적이지만, Java의 java.net.ServerSocket을 이용하여 accept하는 경우에는 Peer 모델을 사용하는 것은 부적절해 보입니다. 그 이유는 단순하게도 ServerSocket.accept() 메서드가 synchronized 메서드이기 때문입니다.

이 사실 자체가 정상적으로 ServerSocket을 accept하는 상황에서 문제가 되지는 않습니다. 하지만, Peer thread들을 정상적으로 종료시키려면 문제가 되기 시작합니다. ServerSocket.accept()는 non-blocking I/O이고 (당연하게도) interrupt도 불가능합니다. 따라서 Peer thread를 종료시키려면, ServerSocket.accept()에서 빠져나오게 하기 위한 방법이 필요합니다. ServerSocket.accept()를 빠져나오게 하기 위해서는 가짜 접속을 하거나, ServerSocket.setSoTimeout() 메서드를 통해서 소켓 타임아웃을 설정하는 방법밖에는 없습니다. 가짜 접속을 하는 방법이 복잡해 보이므로, 소켓 타임아웃에 의존해봅시다. 하지만, ServerSocket.accpet() 메서드는 synchronized 메서드이기 때문에, 모든 Peer thread에 대해서 소켓 타임아웃이 적용되어 모두 종료되려면, (number of peer threads) * (socket timeout) 만큼의 시간이 걸립니다. 그러면 가짜 접속을 하는 방법을 고려해볼까요? 이쯤에서 짜증이 나기 시작합니다.

해결책은 그냥 처음부터 Boss-Worker 모델을 사용하는 것입니다. 위에서 언급했듯이 숙제로 짜는 프로그램이 아니라면, Boss-Worker 모델이 Peer 모델에 비해서 별로 복잡하지도 않습니다. (제대로 짠 프로그램이라면, 어차피 통신 방법과 서버 로직은 잘 분리되어있어야 하겠죠) Boss-Worker 모델에서는 당연히 한 시점에 하나의 thread가 ServerSocket.accept()를 호출하므로 (socket timeout) 만큼의 시간이 걸릴 뿐입니다.

Peer 모델을 그대로 사용하면서, NIO의 java.nio.channels.Selector를 사용하는 방법도 있습니다만, 애초에 서버 프로그램을 NIO를 이용하여 짜지 않았기 때문에, 필요 이상의 복잡함이 추가됩니다.

사실 이런 종류의 문제들은 서버 프로그램에서 항상 반복되는 문제들이고 MINA와 같은 프레임워크들이 잘 해결하고 있습니다. 처음부터 이런 프레임워크를 고려하는 것도 한가지 방법입니다.

Use Boss-Worker model to accept connections with java.net.ServerSocket 더 읽기"

Bad Smell of Code: Too many top-level classes in a file of Java program

댓글 달기 / Software Development / /

소스 파일(이하, 파일)도 모듈의 일종이다.

어떤 프로그래밍 언어에서는 파일을 언어 자체가 정의하는 개념(예를 들어, C++의 ‘컴파일 단위’)으로 본다. 어떤 프레임워크에서는 특정한 파일은 어떤 특별한 역할을 하는 코드의 집합으로 본다. (예를 들어, RoR의 파일 구성) 마찬가지로, 어떤 프로젝트에서는 정해진 독특한 규칙에 따라 특정 파일에 특별한 역할을 부여할 수 있다.

이런 면에서, 소스 파일의 구성(File Organization)은 소프트웨어 품질에 영향을 미치는 디자인 결정 중의 하나다.

파일이라는 OS라는 낡고 거추장스러운 곳으로부터 나온 (어떤 면에서) 언어 외적인 요소를, 고매하고 청명한 정신으로부터 태어난 자신의 코드와 결부시키는 것이 불편하게 느껴질지도 모르겠다. 언어 자체가 파일 개념에 의존하지 않는다면, 한 프로젝트의 모든 코드가 한 파일에 들어있든, 1억개의 파일에 들어있든 무슨 상관이 있겠는가.

하지만, 아직은 프로그래밍 세계는 파일이라는 요소에 의존하는 편이다. 그럴 듯한 IDE를 사용하지 않는 프로그래머들도 너무나 많다. (당신이 vim을 IDE라고 주장하더라도 notepad는 어떤가?!) 그들에게 파일은 Readability에 직접 영향을 미치는 단위가 된다. 너무 긴 파일은 너무 긴 클래스나 너무 긴 함수의 문제점과 동일한 문제를 유발한다. 읽기 힘들다. 파악하기 힘들다. 소위, 스크롤의 압박이란거다.

한편, 현재의 IDE들은 언어가 파일에 의존하지만 않는다면, 파일이라는 요소를 배제할 수 있는 포텐셜을 가지고 있으나, 단순하게도, 그렇게 하지 않는다! 그나마 우리를 행복하게 해주기 위해 IDE를 제작하는 분들에게 뭔가를 추궁하지는 않겠다. 아직은 우리는 파일이라는 개념에 너무나 익숙하다. 정말로 파일이 싫은가 하면 그렇지도 않단 말이다.

어쨌든, 파일은 모듈이고 다시 말해, decomposition의 단위다. 이것은 파일이라는 모듈에도 높은 cohesion과 낮은 coupling이 요구된다는 것이다.

Java와 같은 언어에서는 (Top-level) 클래스 각각은 그 클래스의 이름을 가진 독립된 하나의 파일을 점유하는 것이 일종의 컨벤션이다.

얼마전에 코드 리뷰를 한 적이 있는데, Top-level 클래스 5-7개 정도가 하나의 파일에 들어가 있는 경우를 발견했다. 이것을 발견하자 내 직관은 뭔가 잘못된 것이라는 알려주었다. 도대체 이 클래스의 범위는 어디까지인거지? 왜 이렇게 길어? 이 클래스로 이동하려면? (난 이클립스를 사용하고 있고, 코드 navigation 기능은 숙지하고 있으니, 친절하게 알려주지 않아도 된다.) 혼자만의 생각이지만, 다른 개발자가 이런 코드를 보더라도 분명 나와 비슷한 느낌을 받으리라고 생각한다. (무슨 소리?)

자, 그럼 직관이 아니라, 뭔가 납득할만한 설명을 필요한 것 같다. 대체 왜 그  클래스들은 한 파일에 있어야만 할까? 클래스들을 자세히 들여다보면, 1) A와 B는 Use 관계에 있으나, 그 역할은 충분히 다르고, 특히 A와 B는 그 파일 밖에 있는 클래스 P와 Q에 의해서 사용되고 있었다. 2) D는 C의 구현이 되어야할 부분을 다시 모듈화한 것이었다.

1) A와 B는 충분하게 cohesive하지 않을 뿐만 아니라 파일 외부의 클래스에 의해서도 사용되므로 다른 클래스들과 동등한 자격으로 – 즉, 파일로 노출될 필요가 있다. 2) D는 C의 구현에 해당하고 외부로 노출될 필요가 없으므로 Top-level 클래스가 될 필요가 없다. 즉, D는 C의 임베디드 클래스가 되면 훌륭하다.

이런 식으로 리팩토링을 하고 나니, 하나의 파일에는 하나의 Top-level 클래스만이 남아있었다.

물론 하나의 파일에 무조건 하나의 Top-level 클래스만 써야만 하는 법은 없을 것이다. 내가 알지 못하는 문맥에서의 필요성이 있을 수도 있고, Top-level 클래스를 하나의 파일에 모아두는 것에 페티쉬를 가진 경우도 있을 것이다. 물론, 파일 개념의 철폐를 부르짖는 해방주의자도 빼놓을 수는 없다. 하지만, 대부분의 경우에는 별 생각 없이 한 파일에는 하나의 Top-level 클래스를 두는 것으로 생각하면 별 탈 없을 것이고, 어쩌면 칭찬을 들을지도 모른다.

오늘의 Rule of Thumb: Java 프로그래밍에 있어서 하나의 파일에는 하나의 Top-level class를 두자. 땅땅땅.

Bad Smell of Code: Too many top-level classes in a file of Java program 더 읽기"

Someone to inspire us

댓글 달기 / Politics, Stray Thoughts / /

“If our job teaches us anything, it’s that we don’t know what the next President’s gonna face. And if we choose someone with vision, someone with guts, someone with gravitas, who’s connected to other people’s lives, and cares about making them better; if we choose someone to inspire us, then we’ll be able to face what comes our way and achieve things we can’t imagine yet. Instead of telling people who’s the most qualified, instead of telling people who’s got the better ideas, let’s make it obvious. It’s going to be hard.” – Toby Ziegler, West Wing Season 4 Episode 1: ’20 Hours in America’

Someone to inspire us 더 읽기"