5. Q. What’s the point of doing multi region without local cache
6. Things That Will Not Be Covered
a. Why Master-Master Multi Region is SO HARD
b. How to migrate Monolith to Microservice
c. How to migrate to Serverless (Lambda)
7. Things That Will Be Covered
a. How to build multi-region cache replication
b. Include monitoring / backup
c. in Serverless
9. Scenario
1) Someone request User A’s profile image from VIRGINIA
2) Put user A’s profile in to cache (VIRGINIA) and return
3) Someone request User A’s profile image on SEOUL
4) Put user A’s profile in to cache (SEOUL) and return
5) User’A updates send profile image change request (VIRGINIA)
6) Update Database and purge cache (VIRGINIA)
7) Someone requests User A’s profile image from SEOUL
8) ???? Old Image ?????
10. Scenario
1) Someone request User A’s profile image from VIRGINIA
2) Put user A’s profile in to cache (VIRGINIA) and return
3) Someone request User A’s profile image on SEOUL
4) Put user A’s profile in to cache (SEOUL) and return
5) User’A updates send profile image change request (VIRGINIA)
6) Update Database and purge cache (VIRGINIA)
7) VIRGINA -> SEOUL, “DEL User’A Profile Image Cache”
or, “SET User’A Profile Image Cache with new image”
8) Someone requests User A’s profile image from SEOUL
9) NEW IMAGE!
14. Netflix does it, BUT
Requires,
1) Kafka Cluster
2) Service Discovery
- Address of kafka in local region
- Address of Replication Proxy on
Other Region(S)
3) EVCache cluster
4) Monitoring, Logging.....
15. EVCache
- Basically, <Memcached + Extra Features>
- Extra Features
- Replication Layer (Capture every commands)
- Secondary Index (Using ElasticSearch)
- But AWS doesn't have "Managed EVCache"
18. Replicator (Lambda)
• It only knows "Local Region"
memcached url
• Receive SET / DEL command,
execute it
• Application should know all
other regions Replicators
endpoint
MemcachedReplicator Application
MemcachedReplicator Application
MemcachedReplicator Application
20. Q. Application should know
all other regions Replicators endpoint.
A. It's Lambda! ARN is pretty same.
You don't need Service Discovery
npm run deploy:prod -- --region=ap-northeast-2
arn:aws:lambda:ap-northeast-2:12345:function:retriever-prod-receiver
npm run deploy:prod -- --region=us-east-1
arn:aws:lambda:us-east-1:12345:function:retriever-prod-receiver
npm run deploy:prod -- --region=us-west-1
arn:aws:lambda:us-west-1:12345:function:retriever-prod-receiver
21. Thus, At Application (Memcached Client),
const clients = [
"us-east-1",
"ap-west-1",
"ap-northeast-2"
].map(region => new AWS.Lambda({ region }));
async function set(key: string, value: string) {
const local = new MemcachedDriver(process.env.CACHE_URL);
await Promise.all([
local.set(key, value),
...clients.filter(c => c.region !== process.env.AWS_REGION).map((client) =>
client.invokeAsync({
FunctionName: "retriever-prod",
InvokeArgs: JSON.stringify({
source: process.env.AWS_REGION,
action: {
type: "SET", key, value
}
})
}).promise()
)
]);
}
22. Logging can be really complicated
1) For logging, it's better to have centralized bucket on single region
2) Otherwise,
us-east-1 → ap-northeast-2 log is at ap-northeast-2
ap-northeast-2 → us-east-1 log is at us-east-1
3) memcached SET / DEL takes about 5~10ms
4) but cross region access (either KinesisFirehose or Cloudwatch)
takes at least 300ms
5) So, Waiting for Logging is Really Really inefficient
6) And even expensive if you use Lambda. Cost = Duration * Memory
23. The only way to log without extra
latency in lambda:
Console.log + Cloudwatch
25. But how can we "Query" or "Search" that?
- Cloudwatch → ElasticSearch,
- Work fine, A lot of guides, not serverless, Expensive
- Cloudwatch → Kinesis Firehose → S3 → Athena,
- SERVERLESS!
- Link