상태를 가진 서비스 만들기에 대하여 [번역]

상태를 가진 서비스 만들기에 대하여  [번역중]

상태없는 (비연결) 서비스는 낭비요소가 많다.

• Stateless services have worked well. Storing the canonical source of truth in the database and horizontally scaling by adding new stateless service instances as needed has been very effective.

• The problem is our applications do have state and we are hitting limits where one database doesn’t cut it anymore. In response we’re sharding relational databases or using NoSQL databases. This gives up strong consistency which causes part of the database abstraction to leak into services.

• Data Shipping Paradigm

  • A client makes a service request. The service talks to the database and the database replies with some data. The service does some computation. A reply is sent to the client. And then the data disappears from the service.

  • The next request will be load balanced to a different machine and the whole process happens all over again.

• It’s wasteful to repeatedly pull resources into load balanced services for applications that involve chatty clients operating over a session over a period of time. Examples: games, ordering a product, any application where you are updating information about yourself.
  
  

상태를 (연결) 가진 서비스는 프로그램하기 더 쉽다.

• Caveat: stateful services are not magic. Stateless services are still incredibly effective if horizontal scalability is a requirement. Yet stateful services do offer a lot of of benefits.

• Data Locality. The idea that requests are shipped to the machine holding the data that it needs to operate on. Benefits:

  • Low latency. Don’t have to hit the database for every single request. The database only needs to be accessed if the data falls out of memory. The number of network accesses is reduced.

  • Data intensive applications. If a client needs to operate a bunch of data it will all be accessible so a response can be returned quickly.

• Function Shipping Paradigm

  • A client makes a request or starts a session the database is accessed one time to get the data and the data then moves into the service.

  • Once the request has been handled the data is left on the service. The next time the client makes a request the request is routed to the same machine so it can operate on data that’s already in memory.

  • Avoided are extra trips to the database which reduces latency. Even if the database is down the request can be handled.

• Statefulness leads to more highly available and stronger consistency models.

  • In the CAP world where we have different levels of consistency that we operate against, some are more available than others. When there’s a partition CP systems chose consistency over availability and AP systems chose availability over consistency.

  • If we want to have more highly available systems under AP we get Write From Read, Monotonic Read, Monotonic Write. (for definitions)

  • If we have sticky connections where the data for a single user is on a single machine then you can have stronger consistency guarantees like Read Your Writes, Pipelined Random Access Memory.

  • Werner Vogel 2007: Whether or not read-your-write, session and monotonic consistency can be achieved depends in general on the "stickiness" of clients to the server that executes the distributed protocol for them. If this is the same server every time than it is relatively easy to guarantee read-your-writes and monotonic reads. This makes it slightly harder to manage load balancing and fault-tolerance, but it is a simple solution. Using sessions, which are sticky, makes this explicit and provides an exposure level that clients can reason about.

  • Sticky connections give clients an easier model to reason about. Instead of worrying about data being pulled into lots of different machines and having to worry about concurrency, you just have the client talking to the same server, which is easier to think about and is a big help when programming distributed systems.