Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netflix Billing Migration to AWS

techblog.netflix.com

Post reply on HN
Print view View original

111–120 of 126 posts

Re: Netflix Billing Migration to AWS

#111

Post by bpicolo »

gdulli wrote: post #107
bpicolo wrote: post #74

Earlier quoted context omitted.

Really? Because Amazon, Netflix, Facebook, and Google all have stake in the MySQL ring (google least so). MySQL has a lot of good knowns at scale, too.

All companies old enough to have a lot of legacy infrastructure from before it was common knowledge that Postgres is better. It would be more curious why MySQL would be adopted today than 10-15 years ago.

MySQL is insanely performant for simple primary key lookups, and has a lot of good knowns. It also has fewer tripups for things like vacuuming, (pretty much requiring) pgbouncer, pgbouncer pooling settings...

If you're doing things with replication logs, mysql replication logs are a heck of a lot simpler, and there's more tooling for them in the OSS world

That said, I do use postgres a lot :)

Re: Netflix Billing Migration to AWS

#112

Post by toomuchtodo »

NetTechM wrote: post #63
tomphoolery wrote: post #62

Earlier quoted context omitted.

it is WAY more cost-effective when you get to that kind of scale to use someone else's battle-tested APIs. the best part is that when that stuff breaks down, it's not your job to fix it.

Plus, no pricey salaries to have event response teams on the payroll.

You still pay for an ops team, just with a different skillset.

Re: Netflix Billing Migration to AWS

#113

Post by toomuchtodo »

philliphaydon wrote: post #102
jon-wood wrote: post #93

Earlier quoted context omitted.

Amazon released their data migration service a while back, which allows you to transfer data in just about anyway you might want to, they'll migrate data between different RDS engines (MySQL to Postgres for example), and to databases outside AWS. They even support near real-time replication to database servers outside AWS, so you could hypothetically replicate your RDS instances to a fail over environment with anothe…

Unless you use SQL Server. The dms service is basically useless with sqlserver. We can't get our 200gb do out of AWS. And any method that works without dms takes about 40 hours.

Can you replicate to a slave outside of RDS and then perform a replica promotion during scheduled maintenance?

Re: Netflix Billing Migration to AWS

#115

Post by limeyx »

partiallypro wrote: post #36

I find it to be a peculiar business decision to completely (as much as you can) migrate to one of your largest competitors' cloud service. It seems like Microsoft is the only, of the larger cloud providers, that doesn't -really- compete with Netflix. (Google has YouTube, and I guess even Microsoft has a much smaller Windows Store presence.) Even if Amazon can't access the raw data, they could see how you're utilizing…

I think for smaller companies it could make sense but Netflix is big enough and visible enough that if AWS cut them off, I think you'd see a huge exodus off of AWS of people fearing they would be next ... simply not worth it to Amazon to shoot itself in the foot like that IMO

Re: Netflix Billing Migration to AWS

#116

Post by tokensimian »

tedivm wrote: post #95
Annatar wrote: post #92

Considering how much code and data was interacting with Oracle, one of our objectives was to disintegrate our giant Oracle based solution into a services based architecture. Some of our APIs needed to be multi-region and highly available. So we decided to split our data into multiple data stores. Subscriber data was migrated to Cassandra data store. Our payment processing integration needed ACID transaction. Hence al…

The majority of the corruption issues with MySQL comes from using the innodb engine. AWS built their own MySQL engine called Aurora that I would be shocked if Netflix wasn't using. It's designed for distributed workloads and should be harder to corrupt. I'll admit I'm confused about picking Cassandra as well, but not for the same reasons you are. They're only storing subscriber data (billing address, subscription typ…

I'm not sure if you saw this other thread, but I thought it answered one of your questions so was worth sharing. Sounds like Aurora wasn't stable when this migration began, so they did the migration with an eye towards the next migration (to Aurora).

Sorry about the c/p but I don't see a permalink on lapitopi's comment.

lapitopi 1 day ago I work on the Netflix Billing Team. PostgreSQL was indeed a very attractive option, but we wanted to keep a path to Aurora open. When we were working on the migration, Aurora was still in beta, so instead of going to Aurora directly, we decided run our own MySQL instances on EC2.

edit: begun/began

Re: Netflix Billing Migration to AWS

#117

Post by Annatar »

ww520 wrote: post #18

DRBD works very well for high availability, especially good to provide failover for master database, since that usually requires fast failover like under 10 seconds. Five or six years ago, did couple HA setup with DRBD along with Linux HA and virtual IP. The failover work great.

DRBD is failover - there is an interruption while the switch is made.

High availability is when you can afford to lose one or more nodes, and there is no service interruption. Moreover, the processing and I/O are symmetric and performance scales linearly by adding more nodes.

Re: Netflix Billing Migration to AWS

#118

Post by Annatar »

bpicolo wrote: post #111
gdulli wrote: post #107

Earlier quoted context omitted.

All companies old enough to have a lot of legacy infrastructure from before it was common knowledge that Postgres is better. It would be more curious why MySQL would be adopted today than 10-15 years ago.

MySQL is insanely performant for simple primary key lookups, and has a lot of good knowns. It also has fewer tripups for things like vacuuming, (pretty much requiring) pgbouncer, pgbouncer pooling settings... If you're doing things with replication logs, mysql replication logs are a heck of a lot simpler, and there's more tooling for them in the OSS world That said, I do use postgres a lot :)

> MySQL is insanely performant for simple primary key lookups, and has a lot of good knowns.

MySQL is extremely buggy and silently corrupts data. It also does not enforce explicitly requested referential integrity, a core mandate of a relational database management system.

https://www.youtube.com/watch?v=emgJtr9tIME

MySQL lacks adequate authentication model (like OS authentication or SmartCard authentication in Oracle).

Re: Netflix Billing Migration to AWS

#119

Post by Annatar »

lapitopi wrote: post #42
hetfeld wrote: post #12

Dropped Oracle, using MySQL. Why not use PostgreSQL instead?

I work on the Netflix Billing Team. PostgreSQL was indeed a very attractive option, but we wanted to keep a path to Aurora open. When we were working on the migration, Aurora was still in beta, so instead of going to Aurora directly, we decided run our own MySQL instances on EC2.

Does "Aurora" fix the inherently broken SQL and integrity constraint mishandling associated with MySQL?

Which security models does "Aurora" offer, for instance, are you able to use OS authentication like in Oracle? What about PKI on SmartCards?

Re: Netflix Billing Migration to AWS

#120

Post by Annatar »

crisopolis wrote: post #5

At least they ditched Oracle (licensed)...

And why is that good? Oracle is worth every penny of those $47,000 per core for an enterprise license, and then some. Provided my company makes a commercial product and I can pay, I would gladly pay Oracle that kind of money (and more) for their database.

Large companies have an enterprise wide license of the Oracle database, so they have thousands of instances (worked at a place like that, that's how I know), and at that point, with that kind of scale, Oracle becomes dirt cheap, considering it delivers the only database I have seen that can withstand the kind of abuse a large institution can throw at a relational database management system.

Post reply on HN