IT이야기2010. 12. 1. 23:27
Pingdom 블로그의 'Mobile OS usage splits the world (chart)' 글에 따르면 전세계 모바일OS별 이용률에서 아이폰은 북미, 유럽, 오세아니아 등 선진국이 많은 지역에서 앞선다. 반면, 노키아의 심비안OS는 아프리아, 아시아, 남미 등 개발도상국, 후진국이 많은 곳에서 비율이 높다. 그리고, 안드로이드가 아이폰의 비율을 점점 갉아먹으면서 비율이 높아지고 있다.

심비안 OS  31.93%
iOS           21.94%
블랙베리    19.25%
안드로이드 11.61%

이 자료는 StatCounter( http://gs.statcounter.com/ )의 통계를 기반으로 했다. 이 통계자료의 진정한 가치는 통계 수치보다는 비율의 변화에 있다.

전세계 모바일OS별 웹이용률

[ 전세계 모바일OS별 웹이용률. 출처 : StatCounter ]


한가지 흥미로운 통계는 국가별로 안드로이드 OS의 웹이용률이 50%가 넘는 나라는 우리나라 밖에 없다. 다른 나라와 극명하게 차이가 날 정도로 절대적인 1위를 차지하고 있다. 이게 바로 170만의 갤럭시S의 힘. 삼성의 힘이라고 보면 될 것 같다.

 1. South Korea, 78.3% (오늘 현재 통계는 81.93%)
 2. Austria, 27.3%
 3. Taiwan, 26.5%
 4. Denmark, 25.3%
 5. Slovenia, 24.0%
 6. United States, 23.3%
 7. Netherlands, 21.7%
 8. Sweden, 21.3%
 9. Estonia, 16.8%
10. Norway, 16.0%

우리나라의 모바일OS별 웹이용률 통계다. 안드로이드 81.93%, 아이폰 14.59%.

[ 우리나라의 모바일OS별 웹이용률. 출처 : StatCounter ]


한편 최근에 발표된 11월중순까지의 국내 스마트폰 가입자는 602만명이며, 이중에 안드로이드가 354만명, iOS가 162만명이다. 각각 58.6%, 26.9%를 차지한다.

[ 가입자 통계 출처 : 국내 스마트폰OS 시장, 안드로이드 '1위'(전자신문, 2010.11.30) ]


국내 안드로이드 가입자 비율이 58%인데, 웹이용률은 78.3%로 더 높다는 것은 2가지로 생각해볼 수 있을 것 같다. 첫째는 안드로이드 유저의 모바일웹 이용률이 더 높다는 것이다. 두번째는 이 통계가 전체 인터넷 이용률이 아닌 웹페이지 이용률이므로, 스마트폰 OS별로 유저의 인터넷 이용 성향의 차이가 있다는 것이다.

Posted by 좋은진호
시스템이야기2010. 11. 11. 22:04
커피닉스(coffeenix.net)의 '범냉이'님이 dig과 nslookup툴을 사용하여, resolv.conf에서 지정한 DNS 서버가 죽었을 경우 timeout시간은 어떻게 되는지 테스트를 하셨다. 테스트한 글은 '커피닉스'에 'DNS 질의 TimeOut의 진실은..'  에 정리되어 있다.

lookup

※ 이미지 출처 : 구글 'domain lookup' 이미지 검색


resolv.conf에 지정한 DNS서버 중 한대가 응답이 없을 때, DNS 요청의 timeout은 5초일까? 1초일까?
왜 이런 궁금증을 갖게됐을까? /usr/include/resolv.h에는 RES_TIMEOUT은  5초로 설정되어 있다. 하지만 dig이나 nslookup으로 테스트한 결과는 1초였기 때문이다.

1) Primary 정상, Secondary 정상
2) Primary 비정상, Secondary 정상
3) Primary 정상
4) Primary 비정상

위 4가지 상황에 대한 테스트 결과는 범냉이님의 글을 읽어보면 결과를 확인할 수 있다.
이후, 추가적인 실험은 제가 넘겨받아 하게 됐다. 자세한 글은 '커피닉스'의 'DNS 질의 TimeOut의 진실은.. (2번째)' 에 쓰여있고, 여기에는 간단하게 요약해서 적었다.

1. dig, nslookup에서는 왜 timeout이 1초인가?

결론적으로는 bind 소스내의 dig과 nslookup툴은 resolv.h의 설정값을 사용하지 않는다. dig소스의 dig.h에 timeout이 1초(#define SERVER_TIMEOUT 1)로 정의되어 있기 때문이다.

2. 만약 resolv.conf에 지정한 모든 서버가 응답이 없다면 dig, nslookup의 timeout 결과는?

정리하면 다음과 같다.
1) resolv.conf에 나열된 서버간 요청 대기는 1초(SERVER_TIMEOUT)
2) 나열된 모든 서버 요청 후 retry시 대기는 5초(UDP_TIMEOUT)
3) retry 횟수는 3번이다.

resolv.conf에 지정한 서버 대수에 따라서,

1) 1대일 때 응답없다면 : 5초 + 5초 + 5초 = 총 15초 소요.
2) 2대일 때 모두 응답이 없다면 : 1초+5초  +  1초+5초  +  1초+5초 = 총 18초 소요
3) 3대일 때 모두 응답이 없다면 : 1초+1초+5초  +  1초+1초+5초   +  1초+1초+5초 = 총 21초 소요

3. gethostbyname() 함수, ping 프로그램 테스트 결과는?

gethostbyname()함수를 사용하는 C프로그램이라면 지금까지 설명한 resolv.h와 resolv.conf을 따르게 된다. 대표적인 것이 ping일 것이다.

resolv.conf에 지정한 DNS서버에서 ICMP응답을 받을 수 있느냐 없느냐에 따라서 대기시간(timeout시간)은 달라지게 된다.

ICMP Port Unreachable

ICMP Port Unreachable (UDP Port 53)


1) ICMP응답이 온다면, timeout없이 바로 다음 서버로 요청을 한다.
2) ICMP응답이 없다면, timeout동안(5초) 대기하다가 다음 서버로 요청을 한다.

4. 효과적인 resolv.conf 설정

만약 resolv.conf에 지정한 첫번째 네임서버(또는 네임서버 VIP) 자체가 죽는다면 ICMP 응답을 못받을 것이다. 따라서 응답시간을 줄이고자 한다면 resolv.conf에서 timeout시간을 줄여주는게 더 나은 대비책이 될 것이다.

options timeout:1 attempts:2 또는
options timeout:1 attempts:1

하지만 resolv.conf 설정을 사용하지 않는 프로그램도 있다. 모든게, resolv.conf 설정대로 될 것이라는 믿음은 절대 금물.

Posted by 좋은진호
IT이야기2010. 9. 14. 12:30
ZFS 파일시스템은 snapshot(스냅샷) 기능을 제공하여, 원하면 언제든지 snapshot시점으로 복원할 수 있다. 명령어 한줄로 snapshot을 만들고, 명령어 한줄로 복원한다. snapshot 생성을 매일 1회 이상 자동으로 실행되도록 해주면, 데이터 복원에 유용할 것이다.

ZFS 파일시스템

참고로 FreeBSD 8.0은 ZFS v13을, 8.1은 v14를 지원한다. FreeBSD 8.2 또는 9.0에서는 v15를 지원할 예정이다. ZFS v15는 Solaris 10 update 8과 FreeBSD간의 호환성이 좋아졌으며, ZFS파일시스템에 php 코드가 있을 경우에 기존보다 15~20%정도 RPS가 향상되었다.

이 글은 FreeBSD에서 ZFS파일시스템을 운영한 것을 토대로 작성했지만 OS와 상관없이 ZFS파일시스템이라면 동일하게 적용된다.

1. snapshot 만들기

이론적으로 snapshot은 최대 2의 64제곱개까지 만들 수 있다. snapshot은 같은 스토리지 풀(파일시스템, 볼륨)의 공간을 사용한다.

snapshot을 만들어보자. snapshot시에 형식은 '파일시스템@snapshot명' 또는 '볼륨@snapshot명'이다. snapshot 이름은 기존 이름과 중복되지 않으면 임의로 만들면 된다.

# zfs snapshot data/log@2010_0621_1740_Mon

snapshot이름은 개인적으로 '년월일' 형식을 선호한다. snapshot 목록을 볼 때, 별도 속성 옵션(-o creation)을 줘야 생성일자를 볼 수 있는 불편함 때문이다. 좀 더 직관적으로 표기하기위해 요일까지 붙여줘도 좋다.

2. snapshot 확인하기

생성된 snapshot 목록을 살펴보자. 생성일시를 알고 싶다면 -o creation의 추가 옵션이 필요하다.

# zfs list -t snapshot
NAME                          USED  AVAIL  REFER  MOUNTPOINT
... 생략 ...
 data/log@2010_0619_0701_Sat   26K      -  20.9M  -
 data/log@2010_0620_0701_Sun   30K      -  21.5M  -
 data/log@2010_0621_0701_Mon   31K      -  21.5M  -
 data/log@2010_0621_1740_Mon     0      -  28.5M  -

3. snapshot rollback하기

rollback은 snapshot 방법과 동일하다. 특정 시점으로 되돌리고 싶으면 해당 'snapshot명'을 지정하기만 하면 된다.

# zfs rollback data/log@2010_0621_1740_Mon
cannot rollback to 'data/log@2010_0621_1740_Mon': more recent snapshots exist
use '-r' to force deletion of the following snapshots:
data/log@2010_0621_1750_Mon
data/log@2010_0621_1813_Mon

위의 경우는 data/log@2010_0621_1740_Mon 스냅샷 이후(즉, 보다 최근)에 2개의 스냅샷이 존재하기 때문에 나오는 메시지이다. 이를 무시하고 롤백하려면 -r 옵션(Recursively)을 주면 된다.

# zfs rollback -r data/log@2010_0621_1740_Mon

※ 여기서는 snapshot 생성, 확인, 복원에 대해 간단하게 적었으며, 자세한 글은 '커피닉스(coffeenix.net)'에 올려뒀다.

* 관련글
2009/02/26 - [시스템이야기] - FreeBSD 7에서 ZFS 사용 (유연성은 좋으나, 성능은 불만족)

Posted by 좋은진호
일상2010. 7. 7. 20:53
분당 KT IDC 근처에서 사람을 만날 때면, 정해진 한 곳을 찾아간다. 그 곳은 커피전문점 '크레마커피(Crema Coffee)'. 야탑역 3번 또는 4번 출구로 나온 후 KT IDC또는 코리아디자인센터(KDC) 방향으로 가면, KT IDC 건물 건너편 1층에서 만날 수 있다.

[ 크레마커피 위치 ]


  • 커피가 맛있다. 전문가가 어떻게 평가할지는 모르지만, 내가 마셔서 좋고, 함께간 사람이 맛있다고 한다.
  • 음악 선곡이 좋다. Britpop 등을 포함한 모던락 위주의 음악 선곡들.
  • 사장님의 친절함, 여자 바리스타들의 상냥함. (두세달전에 여자 바리스타 두분이 모두 바뀌셨는데, 이전에 계셨던 분도 친철하셨는데, 어디로 가셨을까)
  • 부담스럽지 않은 가격. 3명이 마시면 1만원 정도 나온다.

소셜 라이프(사교활동, 인간관계) 장소가 되기에 적합한 곳이라, 판단된다.

[ 크레마커피 ]


[ 입구쪽에서 안쪽을 바라 볼 때 ]


01

에스프레소 커피류, 그린티라테, 홍차류, 요거트 크레치노, 과일 음료 등

[ 토스트 등 사이트 메뉴 ]

아침에 모닝 토스트 세트를 저렴하게 먹을 수 있다.

01


01


[ 디자이너 톰 딕슨의 '미러 볼' 스타일의 조명 (조명에 거울이 있는 건 아니지만) ]


[ 잡지, 신문 ]

경향신문을 볼 수 있도록, 비치되어 있다. 맘에 들어...

[ 쿠폰함 ]

8잔 마시면 1잔을 무료로 마실 수 있다. 사장님은 이왕 무료로 마시니, 비싼 것을 마시라고 권한다. 이를테면, '화이트모카' 대신에 더 비싼 '화이트 모카 크레치노'를. 도장을 다 찍으면, 쿠폰에 서명한 후 추첨함에 넣는다. 매월 추첨을 통해 케익, 샌드위치 등 선물을 주신다. 그리고, 추천함에 넣은 쿠폰 1장당 500원을 기부하신다고.

[ 무선 인터넷 ]

무선 인터넷이 제공된다.

오전 8시 open. 밤 11시 close. 점심시간대는 사람들이 많으니, 편안하게 드시고 싶다면 1시 이후가 적당하다.
흡연자는 카페 밖에 테이블에서 피울 수 있다.

Posted by 좋은진호
IT이야기2010. 6. 30. 23:25
Datacenter Knowledge의 Rich Miller 글 'Facebook Server Count: 60,000 or More'에서 Facebook의 서버 대수는 6만대 이상일 것으로 추측하고 있다.

지난주에 있었던 Velocity 2010 컨퍼런스에서 Facebook의 'Tom Cook'의 프리젠테이션 자료를 토대로 서버 대수를 추측했다. 프리젠테이션에 포함된 차트에는 년도는 있지만, 서버 대수에 대한 수치는 없다. 그러나 이 차트의 성장 곡선의 비율로 대수를 할 수 있다.
facebook server footprint

[ Facebook 서버 증가 차트 ]


2009년 11월 Facebook의 CTO인 Jeff Rothschild(제프 로스차일드)은 서버가 3만대 이상이라고 밝혔다. 차트에서 2009년 후반에 있는 평평한 지점이 대략 이 3만대 이상이 되는 지점일 것이다. 그러면 차트 맨 오른쪽 2010년 초에는 그 때의 두배 정도 되므로, 서버 대수는 6만대 이상으로 추측이 가능하다. Facebook의 이용규모에 비해서는 서버 대수가 생각보다는 적다는 느낌이다. Memcached, HipHop(PHP를 C++로 변환하여 성능 개선), Varnish(분산 및 캐싱 웹서버), Cassandra(NoSQL) 등의 효율적인 운영 덕분일까?

[ 현재 운영중인 Facebook의 Data Center 내부 ]


[ 현재 운영중인 Facebook의 Data Center 내부 (랙에 장착된 서버 뒷면. 케이블링이 깔끔하다.) ]


[ 현재 운영중인 Facebook의 Data Center 내부 ]

※ 위 이미지 출처 : Datacenter Knowledge 블로그 등

Facebook유저는 작년 1월에 1억 5천명이었는데, 올해 2월에는 2배가 넘는 4억명으로 급성장했다. 이렇게 급성장하는 서비스를 대비하여 Facebook은 Facebook 최초의 자체 데이터 센터를 Prineville에 건설중이다. 규모는 147,000 Square Foot(SF, 약 13,600여 제곱미터). FIFA의 국제규격 축구장 넓이가 7140제곱미터 이니깐, 축구장 2배 정도의 규모라고 보면 된다. 건설 사진은 Facebook에 공개되어 있다.

Facebook의 Prineville Data Center

[ Facebook의 Prineville Data Center 조감도 ]

※ 이미지 출처 : Facebook 공식 블로그 'Breaking Ground on Our First Custom Data Center'


소셜미디어의 성장이 놀랍다.
그런데, 트위터는 몇 대일까?


* 서버대수 관련글

- Facebook 사용자 4억명 돌파, 그리고 서버수 (2010.2.12)
- 2009/06/01 - [IT이야기] 해외 주요 업체의 서버 대수는?

* 데이터센터 관련글

- 2011/04/20 - [IT이야기] Facebook의 데이터센터와 서버
- 2009/10/07 - [IT이야기] MS의 시카고 데이터센터 사진 공개
- 2009/04/03 - [IT이야기] 구글 데이터 센터 내부 공개, 그 안을 들여다보자
- 2009/04/10 - [IT이야기] 구글, 구글 서버와 데이터센터 발표자료를 풀 동영상으로 공개
- 구글 데이터센터의 놀라운 전력 효율 (2009.10.27)
- 애플 신규 데이터센터 (2009.7.16)
- 애플 신규 데이터센터 (2009.8.14)
- 터키 이스탄불의 Vodafone 데이터센터, 폭우로 물에 잠겨 (2009.9.16)

Posted by 좋은진호