asymptotic
Joined 15 years ago
Karma
409
Submissions
128
Member since
Mar 21
Recent submissions
Comment · 9 months ago
Comment · 3 years ago
At AWS, the hierarchy of service priorities is crystal clear: Security, Durability, and Availability. In that order. Durability, the assurance that data will not be lost, is a cornerstone of trust, only surpassed by security. Availability, while important, can vary. Different customers have different needs. But security and durability? They're about trust. Lose that, and it's game over. In this regard, InfluxDB has unfortunately dropped the ball.
Deprecation of services is a common occurrence at AWS and many other tech companies. But it's never taken lightly. A mandatory step in this process is analyzing usage logs. We need to ensure customers have transitioned to the alternative. If they haven't, we reach out. We understand why. The idea of simply "nuking" customer data without a viable alternative is unthinkable.
The InfluxDB incident brings to light the ongoing debate around soft vs. hard deletion. It's unacceptable for a hard delete to be the first step in any deprecation process. A clear escalation process is necessary: notify the customer, wait for explicit acknowledgement, disable their APIs for a short period, extend this period if necessary, soft delete for a certain period, notify again, and only then consider a hard delete.
The so-called ["scream test"](https://www.v-wiki.net/scream-test-meaning/) is not a viable strategy for a cloud service provider. Proactive communication and customer engagement are key.
This incident is a wake-up call. It underscores the importance of data durability and effective, respectful customer communication in cloud services and platform teams. Communication is more than three cover-your-ass emails; it's caring about your customers.
Comment · 3 years ago
I misread the article when it stated:
> Traffic regularly exceeded 1,500 queries per second (QPS) at peak times
It may be quite cost prohibitive to use a managed service like AWS Global Accelerator.
Comment · 3 years ago
While HTTP3 does provide some improvements, it's clear that further optimizations are needed, particularly for users in Europe and Asia.
One potential solution that hasn't been discussed much here is leveraging AWS managed services like AWS CloudFront or AWS Global Accelerator. It's worth noting that Dropbox's website already uses AWS CloudFront, so they are already leveraging AWS in some capacity. Based on my cost calculations, using AWS CloudFront would cost around $40k a month, while AWS Global Accelerator would be around $22k a month.
As of August 22, 2022, AWS CloudFront supports terminating HTTP/3 in a Point of Presence (POP), which could potentially help with the latency issues Dropbox is facing. AWS Global Accelerator, on the other hand, is designed to improve the performance of applications by terminating UDP/TCP as close to users as possible then routing user traffic through the AWS global network infrastructure. This could help reduce latency by ensuring that user traffic is routed through the most optimal path, even if the user is located far from a Dropbox data center.
It's hard to estimate what the potential latency reduction of using e.g. AWS Global Accelerator is, especially at higher percentiles. However, using https://speedtest.globalaccelerator.aws/, and assuming symmetry, my connections to Asia are 35-40% lower latency.
Of course, there are trade-offs to consider when using managed services like AWS CloudFront and AWS Global Accelerator. While they can provide significant performance improvements, they also come with additional costs and potential vendor lock-in. However, given the scale of Dropbox's operations and the importance of providing a fast, reliable search experience for their users, it may be worth exploring these options further.
---
Cost estimates
Assumptions:
1. Dropbox's peak traffic is 1,500 queries per second (QPS).
2. Average data transfer per query is 100 KB.
3. 50% of the traffic comes from North America, 25% from Europe, and 15% from Asia (remaining 10% from other regions, for pricing purposes put it into Asia's calculations).
1) AWS CloudFront cost estimation:
Data transfer:
- North America: 1,500 QPS * 0.5 * 100 KB * 60 seconds * 60 minutes * 24 hours * 30 days = 194.4 TB
- Europe: 1,500 QPS * 0.25 * 100 KB * 60 seconds * 60 minutes * 24 hours * 30 days = 97.2 TB
- Asia: 1,500 QPS * 0.25 * 100 KB * 60 seconds * 60 minutes * 24 hours * 30 days = 97.2 TB
Data transfer cost:
- North America: 194.4 TB * $0.085/GB = $16,524
- Europe: 97.2 TB * $0.085/GB = $8,262
- Asia: 97.2 TB * $0.120/GB = $11,664
Total data transfer cost: $16,524 + $8,262 + $7,006 = $36,200
HTTP requests:
Total requests: 1,500 QPS * 60 seconds * 60 minutes * 24 hours * 30 days = 3,888,000,000
Using the updated AWS CloudFront pricing (as of May 22, 2023):
- HTTP requests cost: 3,888,000,000 * $0.0075/10,000 = $2,916
---
2) AWS Global Accelerator cost estimation:
Data transfer:
- Total data transfer: 194.4 TB (NA) + 97.2 TB (EU) + 97.2 TB (Asia) = 388.8 TB
Using the updated AWS Global Accelerator pricing (as of May 22, 2023):
- Data transfer cost (averaged across regions): 388.8 TB * $0.035/GB = $13,608
- (Also need to add EC2 egress cost, 388.8 TB * $0.02/GB = $7,776
- Total data transfer cost = $21,384
Accelerator:
- Assuming 1 accelerator with 2 endpoints (1 for HTTP/2 and 1 for HTTP/3)
- Accelerator cost: 1 * $18/accelerator/day * 30 days = $540
Comment · 3 years ago
I’m familiar with Lambda and DynamoDB. When I left in 2022 they both had strong automated or semi-automated AZ evacuation stories.
I’m not that familiar with S3, but I never noticed any concerns with S3 during an AZ outage. I’m not at all familiar with Aurora Serverless or ECS.
For all AWS services you can always ask AWS Support pointed, specific questions about availability. They usually defer to the service team and they’ll give you their perspective.
Also keep in mind that AWS teams differentiate between the availability of their control and data planes. During an AZ outage you may struggle to create/delete resources until an AZ evacuation is completed internally, but already created resources should always meet the public SLA. That’s why especially for DR I recommend active-active or active-“pilot light”, have everything created in all AZs/regions and don’t need to create resources in your DR plan.
Comment · 3 years ago
When I worked at AWS there was a similar scenario in eu-west-2. There was a fire in one of the availability zones (AZs). The fire suppression system kicked in and flooded the data center up to ankle or knee height. All the racks were powered off and the building was evacuated for hours (I don't remember the duration of the evacuation) until the water was pumped out.
But for the service team I worked for, our AZ-evacuation story wasn't great at the time and it took us tens of minutes to manually move out of the AZ, but at least there wasn't a customer-visible availability impact. Once we did it was just monitoring and baby-sitting until we got the word to move back in, I think it was 1-2 days later.
If you operate on AWS you work with the assumption that an AZ is a failure domain, and can die at any time. Surprisingly many service teams at AWS still operate services that don't handle AZ failure that well (at the time). But if you operate services in the cloud you have to know what the failure domain is.
Comment · 4 years ago
In a technical blog or dashboard I like to see
1) avg mean (for throughput estimates), 2) p50 (typical customer / typical load), 3) p90 / p99 / p99.99 (whatever you think your tail is) 4) p100 (max, always useful to see and know, maybe p0).
Or throw in a histogram or kernel density estimate, sometimes there are really interesting patterns.
I’ve never seen a technical blog give such traffic or latency details though.
Edit: reading other comments, please do not read this as diminishing this blog post or Discord, great clear writing and impressive solution to an interesting problem.
Comment · 4 years ago
If you walk as if you’re happy, talk as if you’re happy, and quack like a happy person, then you are happy.
This is the Way.
Comment · 4 years ago
> the best you can do is write a thread pool that spawns a Tokio LocalSet to run !Send futures
Can you go into this a bit more or provide a code reference? I'm new to writing async Rust code and am interested in this idea.
Comment · 5 years ago
Congratulations! I did the exact same thing; made an app to help name my first child.
I've slowly developed a method which incorporates 1) culture, 2) popularity in different countries, and 3) pronunciation of names and attempts to recommend you names based on names you like. It kind of works, it's taken a lot of tuning to make it output something sensible. It's specifically designed to attempt to combine cultures together, which is a top request from customers I identified.
I've been working on releasing the app for a while. If you're interested in helping me test it before its release this month please feel free to sign up here:
https://www.reddit.com/r/namenerds/comments/qge6t9/im_lookin...
I will also look at this thread's comments closely before launching.
Comment · 6 years ago
FWIW Amazon / AWS also use YubiKeys.
Comment · 6 years ago
https://docs.aws.amazon.com/ram/latest/userguide/working-wit...
“To identify the location of your resources relative to your accounts, you must use the AZ ID, which is a unique and consistent identifier for an Availability Zone. For example, use1-az1 is an AZ ID for the us-east-1 Region and it is the same location in every AWS account”
So each separate AWS account will have a different AZ name that maps to use1-az1, but use1-az1 is a region-wide constant.
Comment · 6 years ago
I haven’t read the paper. But if the researchers were bringing in children regularly for testing involving eye tracking equipment, why not also test their ability to manipulate physical objects, recognize faces, and track faces? That all seems like low hanging fruit.
Comment · 6 years ago
There is a quote from Jeff Bezos: "Good intentions never work, you need good mechanisms to make anything happen.". Hence at Amazon (ideally) any suggestion that a manual step or bureaucratic approval could improve a process is always naturally followed up by “But what happens when good intentions fail? We need a plan for a mechanism”. At least this is the theory, and how Amazon and AWS avoid accruing manual steps with no plan to automate them.
[ my public key: https://keybase.io/asim; my proof: https://keybase.io/asim/sigs/ghOttQMhTUWDaeBj1z7Ebq-7KDe5wAATYO8RQ1QGUBs ]