Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kakaranet Presentation

Namdak Tonpa
October 24, 2012

Kakaranet Presentation

Synrc Research Center authored Turkish Kakaranet Social Gaming for classic turn-based board games. Built in pure Erlang environment Kakaranet is easy to manage and support. Perfectly outsourced following Quick and Well strategy.

Namdak Tonpa

October 24, 2012
Tweet

More Decks by Namdak Tonpa

Other Decks in Technology

Transcript

  1. Technical Input How modern portal should looks like ? •

    Active Fast Comet Pages • High-load Ready • Reliability and Failover • Ditribution for Speed • Monitoring tools • Facebook-like facilities and integration • Simple and small time-to-market • Single Environment
  2. Underlying Products Quick and Well strategy Riak • High Availability

    • Monitoring Tools • Best In-class • Stable • Manageable RabbitMQ • Connecting People • Deliver Messages • Invented in Banks • Language Opaque • Fast GProc • Distributed In- memory database • Consistent • Complex Queries Erlang • Automatic Fail-over • Purity of code • High Reliability • High Load • Mature Infrastructure Cowboy • Fastest Web Server • SSL Ready • Modular • Young but stable Nitrogen • Best Comet Server • Clustered • Typed HTML • Rich JavaScript • Easy to Develop • Event driven
  3. Social Web Application Simple but modern • Users and Groups

    • Free to register • Direct Messages • Friends • Likes • Feeds • Media Files as Attachments, Music, Video • Drop-down Auto-completion • Comet Pages with Rich JavaScript • Pub/Sub key-routing with RabbitMQ
  4. Game Server Nodes Easy to Write new games • AMF

    listeners and Flex Clients • Tables, Games, Tournaments model • Access to Riak and GProc databases • Matching Players Each Other in ranges • Global Registry of all games in Cluster • Persist Game Data • 40KB per game on server-side
  5. Sequential Consistency Guard Processes • All entities that could be

    changed controlled by Erlang Process spawn on bootstrap • Respawn on failover on another node • Back-end Workers for ordering write requests in RabbitMQ queues • All read operations still available for anyone in cluster • Examples: Feeds, Users, Groups, Lists
  6. Cluster Levels Diferrent Tasks Require Different Clusters Database • Riak

    is present in each node in cluster Memory • Each Process registered in global database Routing • Clustered RabbitMQ to handle routing Filesystem • GlusterFS on each server
  7. Cluster Line Erlang/OTP Releases per OS app@srv1 • Workers •

    Riak R/W • GProc game@srv1 • Games • Riak R/O • GProc web@srv1 • Nitrogen • Riak R/O • Gproc • Cowboy rabbit@srv1 • RabbitMQ • Routing Databse
  8. Three Production Lines Continue running after single server down SRV1

    • app@srv1 node • game@srv1 node • web@srv1 node • rabbit@srv1 node • SNMP Agent / node • Riak Control / node • 8x Xeon 3GHz • 30GB RAM • 512GB SSD • 3TB RAID SRV2 • app@srv2 node • game@srv2 node • web@srv2 node • rabbit@srv2 node • SNMP Agent / node • Riak Control / node • 8x Xeon 3GHz • 30GB RAM • 512GB SSD • 3TB RAID SRV3 • app@srv3 node • game@srv3 node • web@srv3 node • rabbit@srv3 node • SNMP Agent / node • Riak Control / node • 8x Xeon 3GHz • 30GB RAM • 512GB SSD • 3TB RAID