PYCON 2009 (Python Conference 2009) 비디오가 올라와있네요..
http://us.pycon.org/2009/conference/schedule/
몇개의 세션이 취소되서 좀 아쉽지만, 그래도 많은 정보가 있네요 🙂
저는 VM쪽 관련한 패널을 흥미롭게 봤고, CPython 이외의 다른 구현들이 이제 많은 부분을 차지하네요.
keynote중에 Reddit에 대한 내용을 재미있게 봤습니다. Reddit이 LISP에서 Python으로 소스를 옮긴 내용도 흥미롭고 서비스 최적화 관련된 내용도 건질게 많았네요.
그리고 Lightning Talks도 참 재미있더군요. Lightning Talks는 한사람에게 딱 5분만 주어지고 한 주제에 대해서 자유롭게 발표하는 것으로 짧은 시간내에 다양한 정보를 얻을수 있고, 넓고 얕은 지식 습득(–)에 도움이 됩니다.
memcached가 메모리에만 저장되기 때문에 서버 재시작하면 내용이 모두 날라갑니다. memcached가 캐시에 최적화되어 개발되어 있기때문에 당연한 거지만… 사용법이 간단하고, 퍼포먼스가 좋다보니 memcached의 간편함과 DB의 persistence를 모두 충족할수 있는 프로그램을 찾게되는듯하네요.
memcachedb는 memcached와 Berkeley DB(오라클이 인수했더군요)를 이용하여 만들어졌으며, 클라이언트는 memcached 프로토콜을 이용하여 접속하며, key, value는 메모리가 아니라 DB에 저장됩니다. 단순한 구조로 되어 있기 때문에 복잡한 DB에 비하면 훨씬 더 빠르게 동작합니다. 또한 replication을 지원하기 때문에, read를 분산하여 처리할수 있습니다. 다만, memcached처럼 여러개의 서버를 파티션해서 사용할수는 없습니다. replication으로 연결하면 write은 모든 서버에서 일어나게 됩니다.
memcachedb와 유사한 프로젝트로 tugela cache가 있습니다. 현재 소스가 더이상 관리가 되지 않고 있지만, tugela cache도 memcached와 Berkeley DB를 이용하여 만들어졌습니다. memcachedb와의 차이점은 persistency를 추구하지 않는다는 점입니다. 메모리보다 많은 캐시가 필요할때 디스크에 쓰는 형태입니다. replication이 없고 memcached와 마찬가지로 read/write를 모두 분산할수 있습니다. memcached에서 캐시 사이즈가 메모리보다 클때 사용하기에는 memcachedb보다는 tugela cache가 적절합니다.
회사에서 세션정보를 저장하는 데몬을 직접 작성하여, 메모리로 세션을 관리하고, 주기적으로 세션정보를 파일로 쓰고, 시작할때
파일에서 세션정보를 읽도록 해서 관리하는데 이거 작성하는것도 일이죠. 이럴 경우 memcachedb를 이용하면 좋을듯하네요…
repcached는 memcached에 리플리케이션(replication) 기능을 추가한 프로그램입니다.
memcached가 cache이기 때문에 세션정보등을 저장하기는 좀 불안한 면이 있죠. 그래서 memcached(repcached)를 두개 띄워놓고, 하나가 중단되더라도 replication을 해두면 보다 안정적으로 서비스 운영이 가능합니다.
repcached 서버를 두군데 띄우고 양쪽으로 리플리케이션 되도록 세팅하면 한쪽에 key,value를 입력하면 다른 서버에도 같은 key,value가 입력됩니다. 그리고 서버 재시작할때 다른쪽 서버의 모든 key,value를 받아오도록 되어있으니, memcached를 재시작해야하거나 서버의 문제로 종료된 경우 캐시를 전부 날리지 않아도 됩니다.
그리고 memcached 클라이언트 라이브러리를 그대로 이용할수 있으므로, 클라이언튼 쪽은 서버에 양쪽 서버 주소만 등록해주면 됩니다.
repcached는 memcached의 패치입니다. 따라서 컴파일하면 memcached 파일이 생성됩니다. 저는 혹시를 위해서 실행파일명을 repcached로 변경하여 설치했습니다.
아래처럼 두개의 호스트에서 repcached를 실행하면 모든 key,value가 공유됩니다.
10.0.0.3> repcached -m 128 -l 10.0.0.3 -p 4001 -d -x 10.0.0.2
한가지 불편한점은 하나의 호스트에서 리플리케이션하도록 세팅이 불가능해보입니다. -X로 replication에 사용하는 포트를 지정할수는 있지만, 상대편의 replication 포트를 지정하는 옵션이 없어서 어떻게 세팅해야할지 모르겠네요. 하지만 두개의 서버에 나누어 실행하는게 더 안전하므로 실제 서비스 적용할때는 크게 문제가 되지 않을거라 생각되네요.
memcached와 성능상의 차이가 얼마나 있는지는 테스트해봐야할듯하네요.
그리고 memcached와 마찬가지로 메모리가 부족하면 임의의 key,value를 지울듯한데, 세션정보등을 repcached에만 의존해도 되는지 의문이 드네요.
캐시가 날라가면 캐시를 채울때까지의 서버 부하 감소용으로 사용하면 좋을듯하네요. 그리고 read를 분산하는 효과도 있겠죠.
얼마전(5월1일)에 서점에 갔다가 상당히 괜찮은 책을 발견했습니다.
“서버/인프라를 지탱하는 기술”
일본서적 번역본인데 이렇게 서버 최적화와 서버 운영에 필요한 기술들에 나온 책은 흔하지 않은듯하네요. 번역본은 더 그렇죠…
무중단 서비스를 위한 다중화 기술에 대한 설명이 자세히 나와있으며, 서버 최적화에 내용도 어느정도 나와있습니다. 리눅스, Apache, MySQL 등의 오픈 소스를 이용한 서버운영에 대한 내용이고, 각각에 대한 최적화에 대한 내용도 있습니다. 하지만, 최적화에 대한 페이지가 제한되어 있는게 좀 아쉽네요. 이름만 듣고 적용하지 못했던 여러가지 툴들에 대한 설명도 볼수 있었습니다. 제가 수동으로 스크립트를 짜서 해오던 일들도 소개된 툴들을 활용해보면 좀더 쉽게 서버관리가 가능할거 같습니다.
목차입니다…
1. 서버/인프라 구축 입문 (다중화/부하분산의 기본)
1.1 다중화의 기본
1.2 웹 서버의 다중화 – DNS 라운드 로빈
1.3 웹 서버의 다중화 – IPVS를 이용한 로드밴런서
1.4 라우터 및 로드밸런서의 다중화
2. 한 단계 높은 서버/인프라 구축 (다중화, 부하분산, 고성능 추구)
2.1 리버스 프록시 도입
2.2 캐시서버 도입
2.3 MySQL 리플리케이션
2.4 MySQL 슬레이브 + 내부 로드밸런서 활용 예
2.5 고속, 경량의 스토리지 서버 선택
3. 무중단 인프라를 향한 새로운 연구 (DNS 서버, 스토리지 서버, 네트워크)
3.1 DNS서버의 다중화
3.2 스토리지 서버의 다중화
3.3 네트워크의 다중화
3.4 VLAN 도입
4. 성능향상, 튜닝 (리눅스 단일 호스트, 아파치, MySQL)
4.1 리눅스 단일 호스트 부하의 진상규명
4.2 아파치 튜닝
4.3 MySQL 튜닝의 핵심
5. 효율적인 운영 (안정된 서비스를 향해)
5.1 서비스의 가동감시 Nagios
5.2 서버 리소스 모니터링 Ganglia
5.3 서버관리의 효율화 Puppet
5.4 데몬의 가동관리 daemontools
5.5 네트워크 부트의 활용 PXE, initramfs
5.6 원격관리 관리회선, 시리얼 콘솔, IPMI
5.7 웹 서버 로그관리
6. 서비스의 무대 뒤 (자율적인 인프라, 다이나믹한 시스템 지향)
6.1 Hatena의 내부
6.2 DSAS의 내부