Welcome to "This is my Architecture".
I'm Zenta Hori, an architect from
Amazon Web Services Japan Solutions.
Today, Mr. Takanori Kikuchi,
CTO of GungHo Online Entertainment, Inc.
is here from Japan.
Thank you for being here, Mr.Kikuchi.
To start with, can you tell us about GungHo?
Our goal is to bring excitement and enjoyable experience to
people all around the world through entertainment.
That in mind, we design, develop and produce game products.
Our masterpiece products include
a PC online game, "Ragnarok Online"
a huge hit, "Puzzle RPG" and
"Puzzle & Dragons", which are
offered regardless of platform or location.
I know that "Puzzle & Dragons" is very popular.
I used to play it in the past
and I still play it sometimes.
Well, this year, in June 2018,
I know that GungHo released a new game.
What kind of game is it?
Yes, we released a game using the player's location.
This is a fun game to play
even for those who usually have a small range of activity.
I see.
I heard GungHo took a new approach
in order to release this new game.
Can you tell us about the new approach?
Can you tell us about the key point of design
and any issues you wanted to resolve?
Yes, we assumed that the user's range of activity
would be centered around day time.
Therefore, we wanted to implement
Blue-green deploy with no maintenance.
Also, we needed an environment where
it can be easily scaled in and out
in order to handle game-specific spikes.
Therefore, we adopted ECS.
I see.
Since this game's property is that the number of users vary
depending on the time of the day,
it is a good structure that
scales the container based on the load.
So now, we would like to take a look at the architecture.
Can you please explain the architecture?
Yes.
In this situation, location information is sent through
the back-end process of the mobile account.
Therefore, we expected over a few thousands of requests per second,
we decided to divide it into two; Server API and Location API.
For location information,
we don't need to reflect it real time on database.
Also, when combined with Server API,
I was worried about the load carried upon Aurora.
That is why I decided to divide it.
For Server API, the data is received by the application on ECS
responding to a client request, then sent to
ElastiCache, DynamoDB, or Aurora,
depending on the frequency of
data access and the property.
For locationAPI
it is also received through the application on ECS.
However, first it is queued through Amazon SQS
to activate ECS worker with a certain condition,
and then written on Aurora.
I see.
Yes.
Instead of writing on Aurora real time,
it goes though a buffering at SQS
before writing.
That way, it puts no load on Aurora,
which is also a good point.
Lastly, can you share with us
your future prospects for this architecture, if there's any?
Yes.
For this Location API,
I would like to replace the segment before SQS with Kinesis Data Stream.
Also, I would like to switch this ECS
with Lamda or Fargate
to create a managed environment.
I see.
Thank you very much.
How was it, everyone?
I think it was a very intriguing architecture.
I hope you can use it as a reference.
Thank you for watching
"This is my Architecture"
featuring GungHo Online Entertainment, Inc.