AWS Meetup Paris - Short URL project by Pernod Ricard
•
0 likes•177 views
Find out my presentation during the AWS Meetup Paris on November 13th, 2018 at Pernod Ricard HQ. I talk about the short url project we did internally.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to AWS Meetup Paris - Short URL project by Pernod Ricard
Similar to AWS Meetup Paris - Short URL project by Pernod Ricard (20)
Recently uploaded
Recently uploaded (20)
AWS Meetup Paris - Short URL project by Pernod Ricard
- 1. PR HQ – IT SOLUTIONS SHORT URL #AWS #PernodRicard #Meetup Life is too short for long URLs. 13 NOVEMBRE 2018
- 2. 2 Charles Rapp Tech Lead @ Pernod Ricard charlesr.app/twitter charlesr.app/linkedin charlesr.app/github
- 3. 3 Few words about Pernod Ricard 18 500 employees in 85 affiliates 9Mds € Net Sales Co-leader worldwide in Wine & Spirits industry Hundred of brands And a tag line… Créateur de convivialité
- 5. 5 Introduction https://drinks.me/short-link https://www.pernod-ricard.com/en/our-group/our-organisation/ From a short URL To a much longer URL § Social Media § Email campaign § QR Code § Legal mentions § … Main usage in Simple need to reduce the length of our URL on social media or offline campaigns
- 6. 6 Prerequisites • Full serverless (NoOps spirit) • Scalable • Affordable • Under Pernod Ricard governance
- 7. 7 What we design in AWS as a first draft LogsDefault origin The picture can't be displayed. Availability zone AWS Cloud Public
- 8. 8 Our architecture in details LogsDefault origin The picture can't be displayed. Availability zone Route53 is mandatory for managing DNS directly in AWS in order to get ability to set an Alias on the @ record.
- 9. 9 Our architecture in details LogsDefault origin The picture can't be displayed. Availability zone As this project needs to be fast as possible, you should use a CDN for that, CloudFront is there.
- 10. 10 Our architecture in details LogsDefault origin The picture can't be displayed. Availability zone 2 S3 buckets are related to CloudFront distribution. 1 for logging all events from CloudFront and 1 as default endpoint of CloudFront, in case of.
- 11. 11 Our architecture in details LogsDefault origin The picture can't be displayed. Availability zone AWS Lambda is finally not really through in that case. We use AWS Lambda@edge for processing requests coming from CloudFront. More details in next slides
- 12. 12 Our architecture in details LogsDefault origin The picture can't be displayed. Availability zone DynamoDB stores our mapping between short and long URLs this NoSQL database. More details in next slides.
- 13. 13 Choice of lambda@edge Ø It is a feature of CloudFront that is globally replicated Ø It lets us run code directly in CloudFront Ø We can develop in NodeJS Ø Extremly scalable
- 14. 14 Lambda vs Lambda@edge Game of differences ! Lambda Lambda@Edge Specifications From 128MB, up to 3008 MB memory From 128MB, up to 3008 MB memory * Supported Languages Java, Node.js, C#, Python Node.js Pricing Based on # requests and volume of used memory per second Free tier available Based on # requests and volume of used memory per second Particularity Timeout 15 min Only usable along CloudFront distribution Environment variables can’t be setup Timeout depending on the event (between 5 to 30s) Out-of-the-box parallelization
- 15. 15 How Lambda@edge works with CloudFront Lambda@Edge can interact on 4 different moments of a request through a CloudFront distibution : Ø Viewer Request When CloudFront receives a request and before cache checks Ø Origin Request When CloudFront fowards a request to the origin Ø Origin Response When CloudFront receives a response from the origin and before it caches the object Ø Viewer Response When CloudFront sent request file to end user
- 16. 16 How we use it Origin Request event handler 1 2 3 4 Step by step 1. Client requests to CloudFront 2. CloudFront asks the origin for this request. This action handles an Lambda@edge function 3. Lambda@edge function requests item based on Client request 4. CloudFront modifies its response to fit redirection found in DynamoDB
- 17. 17 Storing redirections in database DynamoDB with Global Tables helps to store globally our redirections. Example of an item Items stored in DB should be light as possible for performance (and cost) purpose and also flexible for the future needs.
- 18. 18 How we deploy the project Redirect engine is fully managed by a single git repository and using CI/CD for deployment. Developers BitBucket repository Publishes new version with AWS SAM AWS ressources Manages Terraform configuration with Terragrunt Triggers code review by SonarQube Git push
- 19. 19 How to administrate Ø Development of a static website as Back-office Ø Implement REST API for CRUD on DynamoDB using Lambda Ø Authentication by Azure AD Ø RDS Database for all functional informations è Again full serverless
- 20. 20 Full architecture LogsDefault origin The picture can't be displayed. Availability zone Back Office database Public Contributors Back-Office in a static website
- 21. All that for this? Might be kidding!
- 22. 22 One more thing As we saw, architecture design is quite complex for only redirect users from A to B. As Lambda@edge function receives a request from CloudFront, we can play with all informations we get : - User Agent - Headers from CloudFront (country, device, referrer, …) Rules are stored in a item in DynamoDB then processed by Lambda@edge function. User Agent + CloudFront headers
- 23. Questions