Inside Solaris™

삼성 크로노스노트북 (NT700Z5A-S78)의 키보드 부분의 특이사항.. 문제발생..

솔라리스™ — Thu, 26 Jan 2012 20:18:34 +0900

NT700Z5A-S78 모델과 NT700Z5A-S58 모델에서 노트북에서 키보드 부분에 대한 문제사항이

있습니다. 길이가 긴 키보드 자판.. 대표적으로 SPACE입니다. 타 노트북에서는 발생되지 않는 것인데 양쪽 사이드를 누르면 키보드가 동작하지 않습니다.

영상을 보시면 알게지만 커서는 글씨의 중간에 두고.. SPACE를 누르는데 반응하지 않습니다.

중심부를 누르면 동작을 합니다. A/S센터에서 동일기종으로 교환을 한뒤에 다시 한번 해보니..
헐.. 동일증상이 또 나오네요.

담당 A/S기사의 말.. 환불신청해 드릴까요 ??

일단 당시에는 별다른 대안이 없어서.. 일단 가지고 1층에 있는 디지털플라자로 가서 구매한 직원에게 애기를 했습니다. 그리고 전시되어 있던 노트북을 테스트 해보니.. 크로노스 모델 ( i5기종 )만 동일한 증상이 있더군요. 하지만 타 노트북의 경우에도 맨 끝을 눌러도 모두 동작을 하는데 크로노스 기종만 이런 증상이 있습니다.

만일 이 문제가 금형이 잘못된것이라면..
금형수정비용도 수십억 ?
중국생산이기 때문에 춘절 휴가 다 지나고 ??
그리고 재 생산을 하거나.. 아니면 생산중단 및 모든 제품 회수 ??

제2의 옴니아가 나타나는 것일까요 ? 지금도 삼성울트라 광고만 엄청 나오는 군요. 울트라보다 이 기종이 더 상위 기종인데.. 크로노스 광고는 안하는 삼성..

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Web Technology Stack [Analysis]

솔라리스™ — Wed, 10 Aug 2011 13:25:43 +0900

Even wondered what technologies are used for large web applications which have millions of unique visitors and have 1000s of requests per second. Which programming languages are making it happen, handling such peak amount of load at a time. We were curious about it and thought lets figure out what beneath the nice slick interface, who is handling the business logic efficiently. Here is what we found, a compiled list of technologies stack used at various web applications.

Product	Front End	Back end	Database	Others
Twitter	Ruby on Rails (RoR), JavaScript, jQuery LabJS, Modernizr, JSON-P, oEmbed	Scala	Cassandra	Java, C, Python, Mustache templating language
Facebook	PHP, XHP, Hiphop for PHP, JavaScript	C, C++, Java	Cassandra, MySQL	Python, Erlang
LinkedIn	JSP, Apache Coyote Web Server	Spring MVC, Linkedin spring, grails,	Oracle and MySQL	ActiveMQ for JMS, Lucene as a foundation for search, DWR, Jetty, Eh-cache, Quartz, Spring remoting.
YahooMail	HTML, CSS, JavaScript (with YUI 3)	PHP	MySQL	Apache Traffic Server (formely known as Yahoo! Traffic Server).
Google +	Closure framework, including Closure’s JavaScript compiler and template system, HTML5 History API	Closure templates server-side, C++, Java, or Python	BigTable and Colossus/GFS	MapReduce
FourSquare	scala(lift framework)	scala Amazon S3 for hosting, /img/ folder which is served by nginx directly	MongoDB	load balancer(s): nginx/0.8.52 Lift- A web framework written in scala.
Youtube	Python	psyco, a dynamic python->C compiler	MySQL
Quora	Python and JavaScript	LiveNode/webnode2, Thrift (Communicate to backend) Amazon EC2 and S3 for hosting	MySQL + memcached	C++ Load Balancing: nginx in front of HAProxy
Viddler	PHP, Python	Rails 2.x, ffmpeg/mencoder/x264lib, Java 1.6 / Spring / Hibernate / ehcache, Erlang Amazon EC2 and S3 for hosting	Mysql 5.0	Hadoop HDFS (distributed video source storage) Nginx/Keepalived (Load balancers for all web traffic) Wowza (RTMP video recording server) Mediainfo(reporting video metadata) Yamdi (metadata injector for flash videos) Puppet(configuration management) Logcheck(log scanning) Duplicity(backup)
StackOverFlow	jQuery, ASP .NET	C#, Microsoft ASP.NET (version 4.0), ASP.NET MVC 3, Razor.	LINQ to SQL, some raw SQL Server	HAProxy (for load balancing), Bacula(for backup), Redis(caching layer)
Disqus	jQuery,EasyXDM, Sammy, Flot, Raphaël, JSHint	Python scripts, Django, Celery, South	PostgreSQL, memcached	HAProxy + heartbeat (Load balancing)

In Short..

Conclusion

The current trends for front end development are mainly jQuery, Python, Scala. Though some companies use Microsoft technologies but, the percentage of such companies is very less. Although MySQL and Cassandra has been favorites databases but few are moving to MongoDB which is a NoSQL database. Back end of these high scaling sites run on variety of different technologies such as Django, python, RoR, Closure, C++, Java, Scala etc.

I’ve written this post to give insights about which technology combinations are preferred by websites with high user base, you might want to consider these points while choosing platforms and programming languages for your start-up.

Like this article? or have some thing to say? Comment down your opinions.

http://www.tutkiun.com/2011/07/web-technology-stack-analysis.html

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Setting up replica sets with MongoDB 1.6

솔라리스™ — Fri, 08 Jul 2011 17:35:51 +0900

Introduction

MongoDB 1.6 was released today, and it includes, among other things it includes support for the incredible sexy replica sets feature – basically master/slave replication on crack with automatic failover and the like. I’m setting it up, and figured I’d document the pieces as I walk through them.

My test deploy is going to consist of two nodes and one arbiter; production will have several more potential nodes. We aren’t worrying about sharding at this point, but 1.6 brings automatic sharding with it, as well, so we can enable that at a later point if we need to.

Installation

Installation is very easy. 10gen offers a yum repo, so it’s as easy as adding the repo to /etc/yum.repos.d and then running yum install mongo-stable mongo-server-stable.

Once installed, mongo --version confirms that we’re on 1.6. Time to boot up our nodes.

Configuration

For staging, we’re going to run both replica nodes and the arbiter on a single machine. This means 3 configs.

I have 3 config files in /etc/mongod/ – mongo.node1.conf, mongo.node2.conf, and mongo.arbiter.conf. As follows:

# mongo.node1.conf

replSet=my_replica_set

logpath=/var/log/mongo/mongod.node1.log

port = 27017

logappend=true

dbpath=/var/lib/mongo/node1

fork = true

rest = true

# mongo.node2.conf

replSet=my_replica_set

logpath=/var/log/mongo/mongod.node2.log

port = 27018

logappend=true

dbpath=/var/lib/mongo/node2

fork = true

# mongo.arbiter.conf

replSet=my_replica_set

logpath=/var/log/mongo/mongod.arbiter.log

port = 27019

logappend=true

dbpath=/var/lib/mongo/arbiter

fork = true

oplogSize = 1

Starting it up

Then we just fire up our daemons:

mongod -f /etc/mongod/mongo.node1.conf

mongod -f /etc/mongod/mongo.node2.conf

mongod -f /etc/mongod/mongo.arbiter.conf

Once we spin up the servers, they need a bit to allocate files and start listening. I tried to connect a bit too early, and got the following:

[root@261668-db3 mongo]# mongo

MongoDB shell version: 1.6.0

connecting to: test

Fri Aug  6 03:48:40 Error: couldn't connect to server 127.0.0.1} (anon):1137

exception: connect failed

Configuring replica set members

Once you can connect to the mongo console, and we need to set up the replica set. If you have a compliant configuration, then you can just call rs.initiate() and everything will get spun up. If you don’t, though, you’ll need to specify your initial configuration.

This is where I hit my first problem; the hostname as the system defines it didn’t resolve. This was resulting in the following:

[root@261668-db3 init.d]# mongo --port 27017

MongoDB shell version: 1.6.0

connecting to: 127.0.0.1:27017/test

> rs.initiate();

{

        "info2" : "no configuration explicitly specified -- making one",

        "errmsg" : "couldn't initiate : need members up to initiate, not ok : 261668-db3.db3.domain.com:27017",

        "ok" : 0

}

The solution, then, is to specify the members, and to use a resolvable internal name. Note that you do NOT include the arbiter’s information; you don’t want to add it to the replica set early as a full-fledged member.

> cfg = {_id: "my_replica_set", members: [{_id: 0, host: "db3:27017"}, {_id: 1, host: "db3:27018"}] }

> rs.initiate(cfg);

{

        "info" : "Config now saved locally.  Should come online in about a minute.",

        "ok" : 1

}

Bingo. We’re in business.

Configuring the replica set arbiter

If the replica set master fails, a new master is elected. To be elected, a replica master needs to have at least floor(n / 2) + 1 votes, where n is the number of active nodes in the cluster. In a paired setup, if the master were to fail, then the remaining slave wouldn’t be able to elect itself to the new master, since it would only have 1 vote. Thus, we run an arbiter, which is a special lightweight, no-data-contained node whose only job is to be a tiebreaker. It will vote with the orphaned slave and elect it to the new master, so that the slave can continue duties while the old master is offline.

> rs.addArb("db3:27019")

{

        "startupStatus" : 6,

        "errmsg" : "Received replSetInitiate - should come online shortly.",

        "ok" : 0

}

Updated driver usage

Once we’re set up, the Ruby Mongo connection code is updated to connect to a replica set rather than a single server.

Before:

MongoMapper.connection = Mongo::Connection.new("db3", 27017)

After

MongoMapper.connection = Mongo::Connection.multi([["db3", 27017], ["db3", 27018]])

This will attempt to connect to each of the defined servers, and get a list of all the visible nodes, then find the master. Since you don’t have to specify the full list, you don’t have to update your connection info each time you change the machines in the set. All it needs is at least one connectable server (even a slave) and the driver will figure out the master from there.

Conclusion

That’s about all there is to it! We’re now up and running with a replica set. We can add new slaves to the replica set, force a new master, take nodes in the cluster down, and all that jazz without impacting your app. You can even set up replica slaves in other data centers for zero-effort offsite backup. If your DB server exploded, you could point your app at the external datacenter’s node and keep running while you replace your local database server. Once your new server is up, just bring it online and re-add its node back into your replica set. Data will be transparently synched back to your local node. Once the sync is complete, you can re-elect your local node as the master, and all is well again.

Congratulations – enjoy your new replica set!

출처 : http://www.coffeepowered.net/2010/08/06/setting-up-replica-sets-with-mongodb-1-6/

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Replica Set Tutorial

솔라리스™ — Fri, 08 Jul 2011 15:55:55 +0900

This tutorial will guide you through the basic configuration of a replica set. Given the tutorial is an example and should be easy to try, it runs several mongod processes on a single machine (in the real world one would use several machines). If you are attempting to deploy replica sets in production, be sure to read the replica set documentation. Replica sets are available in MongoDB V1.6+.

Introduction

A replica set is group of n mongod nodes (members) that work together. The goal is that each member of the set has a complete copy (replica) of the data form the other nodes.

Setting up a replica set is a two-step process that requires starting each mongod process and then formally initiating the set. Here, we'll be configuring a set of three nodes, which is standard.

Once the mongod processes are started, we will issue a command to initialize the set. After a few seconds, one node will be elected master, and you can begin writing to and querying the set.

Starting the nodes

First, create a separate data directory for each of the nodes in the set. In a real environment with multiple servers we could use the default /data/db directory if we wanted to, but on a single machine we will have to set up non-defaults:

$ mkdir -p /data/r0
$ mkdir -p /data/r1
$ mkdir -p /data/r2

Next, start each mongod process with the --replSet parameter. The parameter requires that you specify a logical name for our replica set. Let's call our replica set "foo". We'll launch our first node like so:

$ mongod --replSet foo --port 27017 --dbpath /data/r0

Let's now start the second and third nodes:

$ mongod --replSet foo --port 27018 --dbpath /data/r1
$ mongod --replSet foo --port 27019 --dbpath /data/r2

You should now have three nodes running. At this point, each node should be printing the following warning:

Mon Aug 2 11:30:19 [startReplSets] replSet can't get local.system.replset config from self or any seed (EMPTYCONFIG)

We can't use the replica set until we've initiated it, which we'll do next.

Initiating the Set

We can initiate the replica set by connecting to one of the members and running the replSetInitiate command (that is,rs.initiate() in the mongo shell). This command takes a configuration object that specifies the name of the set and each of the members.

The replSetInitiate command may be sent to any member of an uninitiated set. However, only the member performing the initiation may have any existing data. This data becomes the initial data for the set. The other members will begin synchronizing and receiving that data (if present; starting empty is fine too). This is called the "initial sync". Secondaries will not be online for reads (in state 2, "SECONDARY") until their initial sync completes.

Note: the replication oplog (in the local database) is allocated at initiation time. The oplog can be quite large, thus initiation may take some time.

$ mongo localhost:27017
MongoDB shell version: 1.5.7
connecting to: localhost:27017/test
> rs.help(); // if you are curious run this (optional)
>
> config = {_id: 'foo', members: [
                          {_id: 0, host: 'localhost:27017'},
                          {_id: 1, host: 'localhost:27018'},
                          {_id: 2, host: 'localhost:27019'}]
           }
> rs.initiate(config);
{
   "info" : "Config now saved locally.  Should come online in about a minute.",
   "ok" : 1
}

We specify the config object and then pass it to rs.initiate(). Then, if everything is in order, we get a response saying that the replica set will be online in a minute. During this time, one of the nodes will be elected master.

To check the status of the set, run rs.status():

> rs.status()
{
	"set" : "foo",
	"date" : "Mon Aug 02 2010 11:39:08 GMT-0400 (EDT)",
	"myState" : 1,
	"members" : [
		{
			"name" : "arete.local:27017",
			"self" : true,
		},
		{
			"name" : "localhost:27019",
			"health" : 1,
			"uptime" : 101,
			"lastHeartbeat" : "Mon Aug 02 2010 11:39:07 GMT-0400",
		},
		{
			"name" : "localhost:27018",
			"health" : 1,
			"uptime" : 107,
			"lastHeartbeat" : "Mon Aug 02 2010 11:39:07 GMT-0400",
		}
	],
	"ok" : 1
}

You'll see that the other members of the set are up. You may also notice that the myState value is 1, indicating that we're connected to the member which is currently primary; a value of 2 indicates a secondary.

You can also check the set's status in the HTTP Admin UI.

Replication

Go ahead and write something to the master node:

db.messages.insert({name: "ReplSet Tutorial"});

If you look at the logs on the secondary nodes, you'll see the write replicated.

Failover

The purpose of a replica set is to provide automated failover. This means that, if the primary node goes down, a secondary node can take over. When this occurs the set members which are up perform an election to select a new primary. To see how this works in practice, go ahead and kill the master node with Control-C (^C) (or if running with --journal, kill -9 would be ok too):

^CMon Aug  2 11:50:16 got kill or ctrl c or hup signal 2 (Interrupt), will terminate after current cmd ends
Mon Aug  2 11:50:16 [interruptThread] now exiting
Mon Aug  2 11:50:16  dbexit:

If you look at the logs on the secondaries, you'll see a series of messages indicating fail-over. On our first slave, we see this:

Mon Aug  2 11:50:16 [ReplSetHealthPollTask] replSet info localhost:27017 is now down (or slow to respond)
Mon Aug  2 11:50:17 [conn1] replSet info voting yea for 2
Mon Aug  2 11:50:17 [rs Manager] replSet not trying to elect self as responded yea to someone else recently
Mon Aug  2 11:50:27 [rs_sync] replSet SECONDARY

And on the second, this:

Mon Aug  2 11:50:17 [ReplSetHealthPollTask] replSet info localhost:27017 is now down (or slow to respond)
Mon Aug  2 11:50:17 [rs Manager] replSet info electSelf 2
Mon Aug  2 11:50:17 [rs Manager] replSet PRIMARY
Mon Aug  2 11:50:27 [initandlisten] connection accepted from 127.0.0.1:61263 #5

Both nodes notice that the master has gone down and, as a result, a new primary node is elected. In this case, the node at port 27019 is promoted. If we bring the failed node on 27017 back online, it will come back up as a secondary.

Changing the replica set configuration

There are times when you'll want to change the replica set configuration. Suppose, for instance, that you want to make a member have priority zero, indicating the member should never be primary. To do this, you need to pass a new configuration object to the database's replSetReconfig command. The shell rs.reconfig() helper makes this easier.

One note: the reconfig command must be sent to the current primary of the set. This implies that you need a majority of the set up to perform a reconfiguration.

> // we should be primary.  can be checked with rs.status() or with:
> rs.isMaster();
> var c = rs.conf();
{_id: 'foo', members: [
                       {_id: 0, host: 'localhost:27017'},
                       {_id: 1, host: 'localhost:27018'},
                       {_id: 2, host: 'localhost:27019'}]
}
> c.members[2].priority = 0;
> c
{_id: 'foo', members: [
                       {_id: 0, host: 'localhost:27017'},
                       {_id: 1, host: 'localhost:27018'},
                       {_id: 2, host: 'localhost:27019', priority: 0}]
}
> rs.reconfig(c);
> //done. to see new config,and new status:
> rs.conf()
> rs.status()

Running with two nodes

Suppose you want to run replica sets with just two database servers (that is, have a replication factor of two). This is possible, but as replica sets perform elections, here a majority would be 2 out of 2 which is not helpful. Thus in this situation one normally also runs an arbiter on a separate server. An arbiter is a set member which has no data but gets to vote in elections. In the case here, the arbiter is the tie breaker in elections. Arbiters are very lightweight and can be ran anywhere – say, on an app server or a micro vm. With an arbiter in place, the replica set will behave appropriately, recovering automatically during both network partitions and node failures (e.g., machine crashes).

You start up an arbiter just as you would a standard replica set node, as a mongod process with the --replSet option. However, when initiating, you need to include the arbiterOnly option in the config document.

With an arbiter, the configuration presented above would look like this instead:

config = {_id: 'foo', members: [
                          {_id: 0, host: 'localhost:27017'},
                          {_id: 1, host: 'localhost:27018'},
                          {_id: 2, host: 'localhost:27019', arbiterOnly: true}]
           }

Drivers

Most of the MongoDB drivers are replica set aware. The driver when connecting takes a list of seed hosts from the replica set and can then discover which host is primary and which are secondary (the isMaster command is used internally by the driver for this).

With this complete set of potential master nodes, the driver can automatically find the new master if the current master fails. See your driver's documentation for specific details.

If you happen to be using the Ruby driver, you may want to check out Replica Sets in Ruby.

참고 : http://mongodb.onconfluence.com/display/DOCSKR/Home ( 한국어 메뉴얼 )
http://groups.google.com/group/mongodb-kr ( 한국 MongoDB 사용자 그룹 )

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

다시보는 이지아 외계인설

솔라리스™ — Fri, 22 Apr 2011 10:19:02 +0900

서태지와 이지아가 1997년 결혼해 14년간 부부였으며

최근 이혼소송 중이라는 기사

이지아 뱀파이어설, 외계인설 믿지 않았는데..

왠지 이젠 신비주의를 뛰어 공포 그 자체다 ㄷㄷ

★다시보는 이지아 외계인설★

우리 나라 인터넷 역사를 통틀어 지금까지 해결 못한 난제들이 있는데, 딸기를 들고 야릇한 표정을 짓는 딸녀, 지하철에서 개똥 안 치우고 내린 개똥녀, 등이 있다. 그런데 딸녀는 대충 외국 사람인 것으로 결론이 났고, 개똥녀는 일반인이라서 사실 공개된 정보도 적고, 찾는게 무척이나 힘들다. 하지만 유명인, 공공인사, 연예인이라면 사정이 다르다. 전국민이 다 아는 사람이기에 학교 다닐 때 같이 다녔다거나, 옆집에 산다거나, 부모를 안다거나, 어떻게든 아는 사람이 있기 마련이고.. 그런 소문들이 퍼지게 마련이다.
그런데 영원히 해결되지 않고 있는 문제가 하나 있는데 그게 바로 이지아다. 디씨에서 유일하게 추적에 실패한 연예인. 본명, 국적, 학력 등 기본적인 신상이 하나도 공개가 안 되었다. 사실 처음에 기획사에서 공개한 프로필이 있는데, 정작 그 학교에 알아보니 그런 졸업생이 없다고 해서.. 그것은 거짓으로 판명되었다. 이건 전에 케이블티비에서 직접 추적해서 학교 관계자를 통해서 확인한 것이다. 더 웃긴 건 이렇게 가짜 학력이라고 판명났음에도 여전히 네이버 프로필에는 그 학교로 기록되어 있고, 기획사에서 추후 조치를 하지도 않고, 기획사에서 학력을 다시 확인해주지도 않고, 또한 지난 번 학력위조 스캔들 대량으로 발생했을 때, 이지아 학력은 그냥 슬그머니 넘어갔다는 것이다. 허허.

더 황당한 것은 이지아가 못 하는게 없다는 것이다. 특히나 어학에서 출중한 능력을 보여주는데 아래는 그녀의 일본어 실력 및 영어 실력이다. 둘 다 수준급인데, 아무리 봐도 그냥 어학연수 1년 해서 나올 실력은 아니고.. 특히 발음이 아주 유창해서 일본 사람이라고 해도 믿겠고, 미국에 일찍 이민 갔다고 해도 믿겠다. (실제로 미국에는 이민 갔다고 주장하고, 미국에서 일본 친구들을 만나서 일본어를 배웠다고 주장하는데.. 미국에서 일본애들한테 배워서 이 수준이 된다?) 그리고 단순히 외워서 하는게 아니라 표정과 호흡하는 타이밍, 웃음이 완벽하다.

어학이야 일본과 미국에서 좀 살았나 보지.. 라고 생각할 수 있다. 그냥 살아서는 안 되고, 굉장히 열심히 어학을 배워야 가능한 실력인데.. 뭐... 어릴적에 미국에서 좀 살고 일본에서 몇년 살면서 일했나 보다.. 이러면 가능하다고 생각할 수도 있다. 그런데 여기에 또다른 미스테리 추가. 그녀의 음악 실력이다.
그리고 아래는 이지아의 베이스 기타 실력.

아니... 닥터코어 911 노래에 직접 들어가서 베이스 치고 있다. 이게 우리 나라 여자 연주자 중에서 가능한 사람 몇명 되겠음? 이거 단순히 한 몇달 연습해서 나올 수준이 아님...
그 외에 보컬도 되고, 작사도 함.
락밴드 닥터코어911과 상상밴드의 리더로 활동하고 있는 쇼기(showgy)가 작곡한 몽환적인 락발라드 ‘뱀파이어 로맨스’는 이지아의 진솔한 마음을 담아 가사가 돋보이는 곡. 특히 이지아는 직접 베이스를 연주, 세션으로 참여했다.

호소력 짙은 허스키 보이스를 선보인 이지아에 대해 작곡가 쇼기는 “나른한 목소리로 절제된 감성을 표현하면서도 마치 사막의 태양과 폭풍 같은 강렬함 또한 느껴진다”고 극찬했다.

2008년 불우아동돕기기금 마련차 ‘러브 바이러스’를 발표한 이지아는 지난해 텔레시네마 ‘내 눈에 콩깍지’ 삽입곡 ‘컵케익과 외계인’을 직접 작사하고 가창에 참여했다. 지난해 11월에는 팬미팅 겸 전시회에서 보컬무대를, 닥터코어911 단독공연에서 베이스기타를 연주하는 등 숨겨진 음악적 재능을 뽐냈다.

이외에도 그녀는 다양한 취미가 있다고 하는데.. 원래 디자인 전공했다고 확인되지 않은 이야기를 했었는데 실제로 의상, 그래픽 디자인을 한다고 한다.
이건 이지아가 직접 디자인한 옷이라고 하고..

이지아가 직접 디자인한 웹페이지 화면이라고 함.

이 외에도 승마, 바이올린 등을 드라마 출연을 계기로 익혔단다. 물론 이것들의 실력이 전문가는 아니겠지만.. 대단한 능력임에 틀림없다.

이런 이지아는 데뷔를 2004년에 LG 텔레콤 CF로 했는데, 배용준의 상대역으로 나왔다. 데뷔가 통신사 CF에.. 그것도 배용준 상대라니 이런 화려한 데뷔가 어디있겠나 싶다.

연기도 곧잘 해서 2007년에 MBC 신인상을 받았다. 태왕사신기, 베토벤 바이러스, 스타일에 출연했으며, 지금 아이리스 속편인 아테네 열심히 찍고 있다. 모두 주연급으로 출연했으며.. 데뷔부터 주연을 한 셈이다. 81년생이라고 주장하는데.. 도대체 이 모든 것이 다 가능한 것인가. 도대체 얘는 먹고 놀지도 않고 모든 것을 배우는데 인생을 다 쓰나. 81년생 이상이라고 하기에는 얼굴이 그렇지가 않고.. 특히 배용준이 굳이 데리고 있을 이유가 없을 것 같다. 그러면 진짜 81년생이라고 했을 때 얘는 정체가 뭐란 말인가.

그래서 여러 네티즌 수사대가 출동하여 몇년에 걸쳐서 캐어봤으나.. 아무 것도 알 수가 없었다. 인터넷에 이지아 기사에 댓글이 달릴 법도 한데, 그녀와 같이 학교에 다녔다는 사람, 어린 시절 같이 놀았다는 사람, 먼 친척 ... 아무도 없다. 그 흔한 교회 오빠도 하나 없으며, 초중고 선생님도 없고, 단지 아는 것은 배용준 연인이라는 것이다. 이나마도 초기에 연인설, 데이트 현장 목격설 나왔을 때 기획사에서 고소한다느니.. 아니라고 난리를 쳤고, 지금도 공식적으로 부인하고 있다. 어느 순간 어학 실력을 기준으로 추적 끝에 일본에서 텐프로 업소에서 일하다가 기획사 사장에게 픽업되어 왔다고 하는 설이 나왔는데.. 사실 그것도 그다지 설득력은 없다. 아무도 같이 일했다는 사람이 없고, 그렇다 하더라도 그러면 아는 친구라도 하나 있어야 하는데... 그런 사람이 없다. 아무리 성형 수술을 했어도.. 어떻게 이럴 수가 있냐 이거지.
연인설을 부인하고, 초등학교 졸업 이후 이민 갔다는 이지아의 인터뷰는 아래에서 볼 수 있다.

연속으로 2-3-4번 인터뷰도 있으니 읽어보시라. 특히 4번.. 시사 상식 퀴즈.시사 상식 퀴즈에서도 장난 아닌 실력을 보여줬다. 아래를 보시라. 솔직히 '간암'은 나라도 '위암'이라고 했을 것이고.. '명량대첩'은 국사를 한국에서 안 배우고 해외로 갔다는 걸 생각하면.. 한산대첩이라고 쓴 것도 용한 것이다.

이쁘고, 똑똑하고, 연기 잘 하고, 영어/일본어 능통에, 말도 타고, 미술에도 재능이 뛰어나단다. 아니 이런 엄친딸이 현실 속에서 있을 수 있냐고...

그리하여 결국 네티즌들은 추적을 포기하고 신이 내린 여자 이지아의 정체를 이렇게 규정하기 시작했다.
1. 배용준 여장설 (가만히 보면 배용준 하고 좀 닮았다.)
2. 아바타설
3. 컴퓨터 그래픽설 (정체가 없고 그냥 화면에 그래픽으로 나온다는 설..;;; ㅠ.ㅠ)
4. 뱀파이어설 (몇백년동안 살아서 이것 저것을 배우고 산다는 이야기)
5. 맨 프롬 어스 설 (영화 The Man from Earth에 나오는 2만년 산 사람.. 이런 동족이라는 것. 그래야 저걸 다 배울 수 있음)

암튼 결론은 이지아의 정체는 대중들에게 알려지지 않았고.. 아직도 어떤 네티즌들은 찾고 있지만.. 더이상 인터넷에 오를 정보는 다 올랐다고 본다. 그리고 어떠한 빈틈도 없이 여전히 베일에 쌓여있다.

이지아....도대체 정체가 뭐냐 ㅡㅡ;;;;

출처 : http://bbs1.telzone.daum.net/gaia/do/board/photo/read?bbsId=A000010&articleId=442854

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

How FriendFeed uses MySQL to store schema-less data

솔라리스™ — Tue, 12 Apr 2011 10:40:34 +0900

By Bret Taylor · February 27, 2009

Background

We use MySQL for storing all of the data in FriendFeed. Our database has grown a lot as our user base has grown. We now store over 250 million entries and a bunch of other data, from comments and "likes" to friend lists.

As our database has grown, we have tried to iteratively deal with the scaling issues that come with rapid growth. We did the typical things, like using read slaves and memcache to increase read throughput and sharding our database to improve write throughput. However, as we grew, scaling our existing features to accomodate more traffic turned out to be much less of an issue than adding new features.

In particular, making schema changes or adding indexes to a database with more than 10 - 20 million rows completely locks the database for hours at a time. Removing old indexes takes just as much time, and not removing them hurts performance because the database will continue to read and write to those unused blocks on every INSERT, pushing important blocks out of memory. There are complex operational procedures you can do to circumvent these problems (like setting up the new index on a slave, and then swapping the slave and the master), but those procedures are so error prone and heavyweight, they implicitly discouraged our adding features that would require schema/index changes. Since our databases are all heavily sharded, the relational features of MySQL like JOIN have never been useful to us, so we decided to look outside of the realm of RDBMS.

Lots of projects exist designed to tackle the problem storing data with flexible schemas and building new indexes on the fly (e.g., CouchDB). However, none of them seemed widely-used enough by large sites to inspire confidence. In the tests we read about and ran ourselves, none of the projects were stable or battle-tested enough for our needs (see this somewhat outdated article on CouchDB, for example). MySQL works. It doesn't corrupt data. Replication works. We understand its limitations already. We like MySQL for storage, just not RDBMS usage patterns.

After some deliberation, we decided to implement a "schema-less" storage system on top of MySQL rather than use a completely new storage system. This post attempts to describe the high-level details of the system. We are curious how other large sites have tackled these problems, and we thought some of the design work we have done might be useful to other developers.

Overview

Our datastore stores schema-less bags of properties (e.g., JSON objects or Python dictionaries). The only required property of stored entities is id, a 16-byte UUID. The rest of the entity is opaque as far as the datastore is concerned. We can change the "schema" simply by storing new properties.

We index data in these entities by storing indexes in separate MySQL tables. If we want to index three properties in each entity, we will have three MySQL tables - one for each index. If we want to stop using an index, we stop writing to that table from our code and, optionally, drop the table from MySQL. If we want a new index, we make a new MySQL table for that index and run a process to asynchronously populate the index without disrupting our live service.

As a result, we end up having more tables than we had before, but adding and removing indexes is easy. We have heavily optimized the process that populates new indexes (which we call "The Cleaner") so that it fills new indexes rapidly without disrupting the site. We can store new properties and index them in a day's time rather than a week's time, and we don't need to swap MySQL masters and slaves or do any other scary operational work to make it happen.

Details

In MySQL, our entities are stored in a table that looks like this:

CREATE TABLE entities (
    added_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    id BINARY(16) NOT NULL,
    updated TIMESTAMP NOT NULL,
    body MEDIUMBLOB,
    UNIQUE KEY (id),
    KEY (updated)
) ENGINE=InnoDB;

The added_id column is present because InnoDB stores data rows physically in primary key order. TheAUTO_INCREMENT primary key ensures new entities are written sequentially on disk after old entities, which helps for both read and write locality (new entities tend to be read more frequently than old entities since FriendFeed pages are ordered reverse-chronologically). Entity bodies are stored as zlib-compressed, pickledPython dictionaries.

Indexes are stored in separate tables. To create a new index, we create a new table storing the attributes we want to index on all of our database shards. For example, a typical entity in FriendFeed might look like this:

{
    "id": "71f0c4d2291844cca2df6f486e96e37c",
    "user_id": "f48b0440ca0c4f66991c4d5f6a078eaf",
    "feed_id": "f48b0440ca0c4f66991c4d5f6a078eaf",
    "title": "We just launched a new backend system for FriendFeed!",
    "link": "http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c",
    "published": 1235697046,
    "updated": 1235697046,
}

We want to index the user_id attribute of these entities so we can render a page of all the entities a given user has posted. Our index table looks like this:

CREATE TABLE index_user_id (
    user_id BINARY(16) NOT NULL,
    entity_id BINARY(16) NOT NULL UNIQUE,
    PRIMARY KEY (user_id, entity_id)
) ENGINE=InnoDB;

Our datastore automatically maintains indexes on your behalf, so to start an instance of our datastore that stores entities like the structure above with the given indexes, you would write (in Python):

user_id_index = friendfeed.datastore.Index(
    table="index_user_id", properties=["user_id"], shard_on="user_id")
datastore = friendfeed.datastore.DataStore(
    mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"],
    indexes=[user_id_index])

new_entity = {
    "id": binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c"),
    "user_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"),
    "feed_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"),
    "title": u"We just launched a new backend system for FriendFeed!",
    "link": u"http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c",
    "published": 1235697046,
    "updated": 1235697046,
}
datastore.put(new_entity)
entity = datastore.get(binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c"))
entity = user_id_index.get_all(datastore, user_id=binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"))

The Index class above looks for the user_id property in all entities and automatically maintains the index in the index_user_id table. Since our database is sharded, the shard_on argument is used to determine which shard the index gets stored on (in this case, entity["user_id"] % num_shards).

You can query an index using the index instance (see user_id_index.get_all above). The datastore code does the "join" between the index_user_id table and the entities table in Python, by first querying theindex_user_id tables on all database shards to get a list of entity IDs and then fetching those entity IDs from the entities table.

To add a new index, e.g., on the link property, we would create a new table:

CREATE TABLE index_link (
    link VARCHAR(735) NOT NULL,
    entity_id BINARY(16) NOT NULL UNIQUE,
    PRIMARY KEY (link, entity_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

We would change our datastore initialization code to include this new index:

user_id_index = friendfeed.datastore.Index(
    table="index_user_id", properties=["user_id"], shard_on="user_id")
link_index = friendfeed.datastore.Index(
    table="index_link", properties=["link"], shard_on="link")
datastore = friendfeed.datastore.DataStore(
    mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"],
    indexes=[user_id_index, link_index])

And we could populate the index asynchronously (even while serving live traffic) with:

./rundatastorecleaner.py --index=index_link

Consistency and Atomicity

Since our database is sharded, and indexes for an entity can be stored on different shards than the entities themselves, consistency is an issue. What if the process crashes before it has written to all the index tables?

Building a transaction protocol was appealing to the most ambitious of FriendFeed engineers, but we wanted to keep the system as simple as possible. We decided to loosen constraints such that:

The property bag stored in the main entities table is canonical
Indexes may not reflect the actual entity values

Consequently, we write a new entity to the database with the following steps:

Write the entity to the entities table, using the ACID properties of InnoDB
Write the indexes to all of the index tables on all of the shards

When we read from the index tables, we know they may not be accurate (i.e., they may reflect old property values if writing has not finished step 2). To ensure we don't return invalid entities based on the constraints above, we use the index tables to determine which entities to read, but we re-apply the query filters on the entities themselves rather than trusting the integrity of the indexes:

Read the entity_id from all of the index tables based on the query
Read the entities from the entities table from the given entity IDs
Filter (in Python) all of the entities that do not match the query conditions based on the actual property values

To ensure that indexes are not missing perpetually and inconsistencies are eventually fixed, the "Cleaner" process I mentioned above runs continously over the entities table, writing missing indexes and cleaning up old and invalid indexes. It cleans recently updated entities first, so inconsistencies in the indexes get fixed fairly quickly (within a couple of seconds) in practice.

Performance

We have optimized our primary indexes quite a bit in this new system, and we are quite pleased with the results. Here is a graph of FriendFeed page view latency for the past month (we launched the new backend a couple of days ago, as you can tell by the dramatic drop):

In particular, the latency of our system is now remarkably stable, even during peak mid-day hours. Here is a graph of FriendFeed page view latency for the past 24 hours:

Compare this to one week ago:

The system has been really easy to work with so far. We have already changed the indexes a couple of times since we deployed the system, and we have started converting some of our biggest MySQL tables to use this new scheme so we can change their structure more liberally going forward.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

어도비 “플래시 콘텐츠, 모바일로 손쉽게 확장”

솔라리스™ — Mon, 07 Mar 2011 19:03:12 +0900

어도비시스템즈가 풍부한 이용자 경험(UX)을 제공하는 멀티미디어 콘텐츠를 다양한 운영체제와 기기에서 자유롭게 배포할 수 있는 ‘N스크린’ 전략을 본격화한다.

한국어도비시스템즈는 3월7일 서울 코엑스에서 ‘어도비 리프레시’ 세미나를 열고 이와 관련한 개발자와 디자이너, 콘텐츠 제작사 지원 전략을 소개했다.

‘어도비 리프레시’는 지난해 10월 미국 LA에서 연 글로벌 컨퍼런스 ‘어도비 맥스’ 주요 발표 내용을 나라별로 요약해 소개하고자 마련된 행사다. 이번 행사에는 어도비 플래시 기술 전문가들이 방한해 최신 동향과 어도비 관련 기술 및 제품 소개를 진행했다.

‘리치 앱’ 한 번 개발해 다양한 기기로 배포

이번 발표에서 가장 눈에 띄는 건 ‘모바일 플랫폼’ 확장 기술이다. 요컨대 지금껏 웹이나 인쇄매체에 주력하던 디자인·멀티미디어 콘텐츠를 다양한 모바일 기기로 손쉽게 확장할 수 있는 도구를 제공하겠다는 뜻이다.

어도비는 ‘크리에이티브 스위트’(CS) 제품들을 통해 종이 잡지와 웹용 콘텐츠를 손쉽게 변환·배포할 수 있는 도구를 제공해 왔다. 여기에 스마트폰과 태블릿 보급 추세에 맞춰, 앞으로는 한 번 제작한 멀티미디어 콘텐츠를 모바일 기기용 응용프로그램(앱)으로 손쉽게 변환하고 배포할 수 있는 기능을 제공하게 된다.

지난해 선보인 ‘어도비 플래시 CS5′는 최근 기능을 판올림하면서 ‘아이폰 OS’ 변환 기능을 새롭게 선보였다. 플래시 개발자가 어도비 플래시 CS5로 멀티미디어 콘텐츠를 제작한 뒤, 이를 클릭 몇 번으로 간단히 아이폰·아이패드용 네이티브 앱으로 변환할 수 있는 기능이다. 현재 애플 앱스토어에는 플래시 CS5로 제작해 변환된 앱이 150개 넘게 등록돼 있다.

이렇게 iOS용으로 만든 앱은 안드로이드용 앱으로도 손쉽게 변환할 수 있다. 한 번 만든 콘텐츠를 아이폰과 아이패드는 물론, 크기와 해상도가 제각각인 다양한 안드로이드용 스마트폰과 태블릿용 앱으로 손쉽게 확장·배포할 수 있게 된 셈이다. 윈도우나 맥OS, 리눅스 등 다양한 데스크톱 운영체제(OS)에서 동시에 쓸 수 있는 건 기본이다.

TV 화면으로도 확장 가능하다. 독립 실행 프로그램 형태로 제공되는 ‘어도비 에어(AIR)’를 TV에서도 쓸 수 있게 해주는 ‘에어 포 TV’를 활용하면 된다. 이 역시 어도비 플래시 CS5에서 추가 작업을 하지 않아도 손쉽게 TV용 앱으로 변환할 수 있다. 어도비는 이를 위해 2008년부터 다양한 기기에서 어도비 에어 기반으로 플래시 애플리케이션을 구동할 수 있는 ‘오픈스크린’ 프로젝트를 여러 하드웨어 제조사와 협력해 진행해오고 있다.

웹표준 기반 기기별 맞춤 웹사이트 제작 지원

개발자가 힘들이지 않고 차세대 웹표준 기술 기반 웹사이트와 휴대기기용 콘텐츠를 제작할 수 있는 기능도 제공한다. ‘어도비 드림위버 CS5′가 최근 적용한 새로운 기능을 이용하면 된다.

‘드림위버’는 원래 웹사이트 저작도구였지만, 이제 스마트폰과 태블릿용 모바일 화면을 손쉽게 구현할 수 있는 도구로 확장하는 모양새다. 최근 판올림한 드림위버 CS5는 HTML5와 CSS3 태그를 모두 지원하며, 코드를 자동 검색하고 자동완성 기능을 제공해 개발자나 디자이너가 전문 지식 없이도 최신 웹표준 기반 웹사이트를 제작할 수 있게 했다. 최신 웹킷 브라우저를 탑재해 ‘라이브뷰’ 기능으로 HTML5와 CSS3 기반 웹사이트를 실시간 확인하며 제작할 수 있으며, 한 번 제작한 웹사이트를 ‘멀티스크린’ 기능을 이용해 PC용 웹, 스마트폰용 모바일웹, 태블릿용 웹사이트로 자동 변환할 수 있게 했다.

폴 버넷 어도비 플래시·오픈웹 전도사는 “지금까지는 개발자나 디자이너가 각 기기별로 언어를 알아야 하고 앱을 새로 만들어야 하는 어려움이 있었지만, 어도비 CS5와 에어, 플래시를 이용하면 서로 다른 이용자 경험을 제공하는 다양한 기기별 맞춤 콘텐츠를 손쉽게 제작·변환할 수 있다”라며 “더욱 흡입력 있고 인터랙티브한 콘텐츠를 모바일로 손쉽게 확장할 수 있게 됐다”고 어도비 기술의 장점을 소개했다.

어도비는 스마트폰과 태블릿 영역에서 플래시 기술 확장을 위해 ‘블랙베리’ 제작사인 캐나다 리치인모션(RIM)과도 긴밀히 협력하고 있다. ‘프로페셔널용 태블릿’을 내세운 RIM의 새 태블릿 ‘플레이북’은 제작 단계부터 OS 자체에서 플래시를 손쉽게 구동할 수 있게 했다. 플레이북에 기본 탑재된 앱은 모두 어도비 에어 기반으로 제작됐다.

리차드 갤반 어도비 플래시 프로페셔널 제품 매니저는 이날 기조연설에서 “어도비는 한 번 만든 콘텐츠를 다양한 기기에서 손쉽게 구현하는 멀티스크린 기능을 지원하고, 코드를 잘 모르는 디자이너도 손쉽게 인터랙티브 콘텐츠를 제작할 수 있는 디자이너 접근성을 개선하는 데 주력하고 있다”라며 “이용자가 어도비 주요 도구를 활용해 보다 쉽고 빠르게 풍성한 콘텐츠를 제공하도록 장기 계획을 갖고 지원을 다하겠다”고 밝혔다.

출처 : http://www.bloter.net/archives/52507

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

2011년 네이트 앱스토어 비즈니스 파트너 간담회

솔라리스™ — Fri, 25 Feb 2011 13:49:00 +0900

지난 2월 21일 SK커뮤니케이션즈 본사 5층 대강당에서 진행된

<2011년 네이트 앱스토어 비즈니스 파트너 간담회>의 발표자료를 공유합니다.

많은 개발사 여러분들께서 참석해주셔서 더욱 빛났던 행사였습니다.

참석해주신 모든 개발사 여러분들께 감사드립니다.

네이트 앱스토어 현황 | SK컴즈 오픈소셜사업팀 김영을 부장
http://slidesha.re/gqLHnG

* * *

네이트 앱스토어 모바일 사업 전략 | SK컴즈 오픈소셜사업팀 박지연 차장
http://slidesha.re/hvlgh8

* * *

T Store의 현재와 SNG | SKT 컨텐츠마켓사업팀 김지은 매니져
http://slidesha.re/i7H9Nn

* * *

2011 개발사 지원 프로그램 | SK컴즈 오픈소셜사업팀 최윤난 차장
http://slidesha.re/g3lpJb

* * *

2010년 PF 성공사례발표 - 에브리타운 | 피버스튜디오 김대진 대표
http://slidesha.re/exsWAs

* * *

Social Games on Azure | 한국마이크로소프트 오성미 차장
http://slidesha.re/hgNnfT

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

GDC10: Scaling Social Games, Robert Zubek March 12th, 2010 (Visited 14683 times) Tags: gdc, gdc10, social games

솔라리스™ — Tue, 22 Feb 2011 18:21:45 +0900

Scalable Social Games, Robert Zubek of Zynga (liveblog)

Social games interesting from an engineering point of view sinc ethey live at the intersection of games and web. We spend time thinking about making games fun, making players want to come back. We know those engineering challenges, but the web introduces its own set, especially around users arriving somewhat unpredictably, effects where huge populations come in suddenly. SNSes are a great example of this, with spreading network effects and unpredictable traffi fluctuations.

At Zynga we have 65m daily players, 225m monthly. And usage can vary drastically — Roller Coaster Kingdom gained 1m DAUs in one weekend going from 700k to 1.7m. Another example, Fishville grow from 0 to 6m DAUs in one week. Huge scalability challenges. And finally, Farmville grew 25m DAUs in five months. The cliff is not as steep but the order of magnitude difference adds its own challenge.

Talk outline: Introducing game developers to best practices for web development. Maybe you come from consoles or mobile or whatever, the web world introduces its own set of challenges and also a whole set of solutions that are already developed that we steal, or, uh, learn from. If you are alreayd an experiened web developer, you may know this stuff already.

2 server approaches and two client approaches. So you get three major types.

1. Web server stack + HTML, Mafia Wars, Vampires, et
2. Web server stack + Flash, Farmville, Fishwville, Cafe world
3. Web + MMO stack + Flash, yoVille, Zynga Poker, Roller Coaster Kingdom

Web stack based on LAMP, logic in PHP, HTTP Comms. Very well understood protocol, limitations well known.

Mixed stack has game logic in MMO server such as Java, web stack for everything else. When web stack limitations are preventing the game development. Use web for the SNS pieces.

Fishville:

DB servers
–> web stack
Cache and queue servers

yoVille:

DB > MMO
Cache > Web & CDN

Why web stack? HTTP is very scalable, very short lived requests, scales very well, and easy to load balance. Each request is atomic. Stateless, easy to add more servers. But limitations esp for games: server-initiated actions (NPCs running around, if you come to lose, the monster reacts…) are hard to do over HTTP, since it is request/response. There are some tricks, like the long poll, but fundamentally this makes it harder to scale. Load balancers will get unhappy with you, you can saturate a connection.

The other thing is storing state between requests. This is more particular to game dev than web. Say you areplaying Farmville and collecting apples. You do a bunch of actions which result in many different requests to the servers, but we want to make sure that only the first click gives you an apple, so you cannot click a dozen times on one tree. Whih means stored state and validation. If you had clients talking to many web servers, you cannot use the DB< the poor thing will fall over. If we can guaratee that the client only talks to one web server, you can store it there, and save to db later. But this is tricky to do. Ensuring that people are no allowed to break session affinity even in the presence of maliious clients and browsers… hard.

So instead, you can wrap th DB servers in a caching layer that is faster that does not hit the DB all the time, such as Network Attached Caching. This works much better.

MMO servers… minimally MMO. Persistent socket connection per lient, live game support such as chat and server side push. Keeps game state in memory. We know when a player logs in and load from DB then… session affinity by default. Very different from web! We can’t do the easy load balancing like on web.

Why do them? They are harder to scale out because of load balaning. But you get stuff like the server side push, live events, lots of game state.

Diagram:

DB servers, maybe less caching wrapping it — talks to both web server and MMO server, then those both talk to client.

On the client side, things are simpler.

Flash allows high prodution quality games, game logic on client, can keep open socket. You can talk any protocol you want.

HTML+AJAX the game is “just” a web page, minimal system reqs, and limited graphics.

SNS integration. “Easy” but not relate dto scaling. Call the host network to get friends, etc. You do run into lateny and scaling problems, as you grow larger you need to build your infrastructure so it can support gradeful performane degradation in the face of network issues. Networks provide REST APIs and sometimes client libraries.

Architectures:

Data is shared across all three of these: database, cache, etc.

Part II: Scaling solutions

aka not blowing up as you grow.

Two approaches: scaling up or scaling out.

up means that as you hit processor or IO limits, you get a better box.
out means that you add more boxes

The difference is largely architectural. When scaling up, you do not need to change code or design. But to scale out you need an architecture that works that way. Zynga chooses scaling out, huge win for us. At some point you cannot get a box big enough fast enough. Must easier to add small boxes, but you need the app to have architectural support for it.

Rollercoaster Kingdom gained a lot of players quickly. We started with one database, 500k DAUs in a week. Bottlenecked. Short term scaled up but switched to scaling out next.

Databases, very exciting. The first to fall over. Several ways to scale them. Terms unique to mySQL here but concepts the same for other systems:

Everyone starts out with one database, which is great. But you need to keep track of two things - the limit on queries per second, do benchmarking using standard tools like SuperSmack. You want to know your q/s ceiling, and beyon that how will it perform. There are optimizations you can use to move it. And two, you need to know the player’s query profile in terms of inserts, selets, updates, and average profile per second. It might trail your DAU number, which is nice because then you can project q/s and know when you will reach capacity.

If your app grows then you will need to scale out.

Approach one, replicating data to read only slaves. Works well for blogs and web properties but hnot games, because games have a higher modification profile so your master is still a bottleneck. But useful for redundancy.

Approach two, multiple master. Better because of split writes, but now you have consistency resolution problems, which can be dealt with but increases CPU load.

Approach three and best and push the logic for resolution up to the app layer, a standard sharding approach. The app knows which data goes to which DB.

Partition data two ways”:

vertical by table, whih is easy but does not scale with DAUs. MOve players to a different box from items.

horizontal by row. Harder to do but gives best results. Different rows on different DBs, need good mapping from row to DB. Stripe rows across different boxes. Primary key modulo # of DBs. Do it on an immutable property of the row. A logical RAID 0. Nice side eeffect to increase capacity… to sale out a shard, you add read only slaves, sync them, then shut down, cut replication, and hook it back up. Instant double capacity.

More clever schemes exist. Interaction layers which check where to go… but the nice thing about this is how straightforward it is. No automatic replications, no magic, robust and easy to maintain.

YoVille: partiioning both ways, lots of joins had to be broken. Data patterns had to be redesigned, with sharding you need the shard id per query. Data replication had trouble catching up with high violume usage. In sharded world cannot do joins across shards easily, there are solutions but they are expensive. Instead, do multiple selects or denormalize your data. Say a catalog of items and inventory, and you watch to match them. If catalog is small enough, just keep it in memory.

Skip transactions and foreign key constraints. Easier to push this to the app layer. The more you keep in RAM the less you will need to do this.

Caching.

If we don’t have to talk to the DB, let’s skip it. Spend memory to buy speed. Most popular right now is memache, network attached ram cache. Not just for caching queries but storing shared game state as well, such as the apple picking example. Stores simple key value pairs. Put structured game data there, and mutexes for actions across servers. Caveat: it is an LRU (least recently used) cache, not a DB. There is no persistence! If you put too much data in it, it will start dropping old values, so you need to make sure you have written the data to DB>

bc it is so foundational, you can shard it just like the DB. Different keys on different servers, or shard it veritcally or horizontally.

Game servers.

Web server part is very well known. Load-balance. Preferred approach is to load balance with a proxy first. This is nice from a security standpoint… but it i a single point of failure, capacity limits since the proxy will have a max # of connections.

If you hit those limits you load balance the load balancers… and using DNS load balancing in front of it. It doesn’t matter if dns propagation takes a while.

The other thing that is useful is redirecting media traffic away from media servers… swfs are big, audio is big, do not serve from the same place as game comms. You will spend all yor capaity on media files. Push it through a CDN, and if you are on the cloud already you can store them there instead. CDN makes it fast, sine the assets are close to the users. Another possibility is to use lightweight web servers that only server media files. But essentially, you want big server bank to only talk game data, not serve files. Seevral orders of magnitude performance by doing this.

MMO servers, the unusual part of the setup! Scaling is easiest when servers do not need to talk to each other. DBs can shard, memcache an shard, web can load balance farms, and MMOs? well, our approach is to shard like other servers.

Remove ny knowledge they have about each other and push complexity up or down. Moving it up means load balancing it somehow. Minimize interserver comms, all participants in a live event should be on the same server. Scaling out means no direct sharing — sharing thru third parties is OK, a separate service for that event traffic.

Do not let players choose their connections. Poor man’s load balancing, is a server gets hot remove it from the LB pool, if enough servers get hot, add more instances and send new connections there. Not quite true load balancing which limits scalability.

In deployment, downtime = lost revenues. In web just copy over PHP files. Socket servers are harder. How to deploy with zero downtime? Ideally you set up shadow new servers and slowly transition players over. This can be difficult — versioning issues.

For this reason, this is all harder than web servers.

Capacity planning.

We believe in scaling out, but demand can change fast.how to provision enough servers? Different logistics. Do you provision physical servers or go to the cloud? If you have your own machines, you have more choice and controll and higher fixed costs. With cloud lower costs, faster provisioning, canot control CPU, virtualized IO, etc. On cloud easier to scale out than up.

For a legion of servers you need a custom dashboard for health, Munin for server monitoring graphs, and Nagios for alerts. First level for drilldown is graphs for every server family separately so you can isolate it to a given layer in the system. Once you know memache usage spiked, then you can drill down to particular machines…

Nagios… SMS alerts for server load, CPU load exeeds 4, test account fails to connect after 3 retries.

Put alerts on business stats too! DAUs dropping belo daily average for example. Sometimes they react faster than server stats.

If you are deployed in cloud, network problems are more common. Dropping off net or restarting is common. Be defensive, Reduce single points of failure, program defensively. This includes on the game side.

Q&A:

q: why mySQL? Other DBs are better for scaling.
a: there are other DBs that have been around longer, have greater community, but we don’t use the features those large DBs do. Looking back at the sharding slides — we don’t do a lot of even things like transactions. Easier to move that complexity to the app layer. Once you are on that path, it is a good solution.

q: did you benchmark, that sort of thing, for the different DBs?
a: yes, of course.

q: and for data integrity, if you threw foreign key constraints, that sounds scary! Is it kind of a nightmare?
a: No, not too bad at all, actually. Esp if you do not hit the DB all the time, you ind you don’t get into those dangerous situations as often.

q: is the task when you add more tables… is it as complex?
a: not too bad, has worke well.

q: assuming browsers pick it up, are you guys looking into webGL?
a: many technologies interesting, 3d in browser, silverlight. I would be interested in using them personally… once they achieve high market penetration.

q: why flash?
a: everyone has it. Very pragmatic approach.

q: Do you back up dbs?
a: of course

q: and how?
a: onc eyou go with cloud and amazon, you have to use that approach… we have a number of redundant backups solutions.

q: I guess many joins are across friends… they have to tlak to multiple shards. Do you try to put friends on same shard?
a: no, everyone has different friends.

q: on SNS integration, did you run into issues with PHO not supporting asynh, with delays from answers from the SNS, running out of threads?
a: you will encounter delay with SNS comms, just part of the overall insfrastruture, could be anytihng, not just PHP. You have to program around it, have to find good solutions for dealing with it when it happens bc it will.

q: So you don’t switch from PHP, delay the process?
a: we did encounter a number of places where we had to dig deep into PHP in order to make it work well on that scale.

q: did you patch PHP?
a: we, uh… yes.

q: what are you feeling on tools like the no SQL sort of thing
a: we look into those atively, one the tech matures, it will be a very good candidate fot this sort of thing. But not currently implemented.

q: on sharding, you said use modulo to distrbute load. Once you have found a bottleneck, howdo you prepare the data to be moved from one shard to another.
a: You don’t move people between shards. You just copy a shard to two machine, and both have redundant, and then remove the redundant data.

q: on partitioning, partitioning to two tables. Say item trading that goes across two DBs, transactions may break? Changing ownership on two different dbs?
a: you need to do a guarantee across multiple DBs, putting the data in a memcache layer, locking it, then doing the write, or putting it in the app layre, implementing”transactions lite”

q: being on the cloud did you have to not use a service approach and have each PHP layer write direct to the DB instead of use a service layer? Say an MMO, achievments or presence services. Do you keep the servie layer as a web servie, or write direct to the DB? Your service call time can add time… even on the cloud.
a: Yes, you want this to be nicely modular… we end up not putting it on different machines. Same box as the game logic so there is no network traffic, so there is no separate layer between. So modular, but not in terms of network topology.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Fantasy Bet Eleven with EPL

솔라리스™ — Mon, 17 Jan 2011 20:47:04 +0900

Fantasy Bet Eleven is a live sports prediction game where real statistics from star player of the EPL are reflected in the fantasy team that you create in real time!

( http://www.facebook.com/FantasyBET11?v=wall )

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.