쉐도잉 연습: Build a Real-Time Leaderboard on AWS with DynamoDB - YouTube로 영어 말하기 배우기

⏸ 일시 정지

Did you know that every match weekend, millions of people playing fantasy soccer get re-ranked within minutes of the final whistle?

재생 속도:

96 문장

문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.

Did you know that every match weekend, millions of people playing fantasy soccer get re-ranked within minutes of the final whistle?

Your striker scores twice, and before the highlights even air, your rank has jumped thousands of places.

Think about what that takes.

Millions of scores, reshuffled again and again, always in perfect order.

Ask any engineer how, and you'll get one word back.

Redis.

A cash to babysit A cluster to pay for One more thing that can fall over at 2 in the morning

We're skipping all of it Today, we build a real-time leaderboard on AWS where the database does the ranking itself Live boards,

daily and weekly rankings percentiles,

history and the entire ranking engine is one clever sort key We'll walk the diagram piece by piece and at the end,

there's a free, hands-on lab where you build every bit of it yourself.

Let's start with the hard part.

A leaderboard has one job that's harder than it looks, keeping thousands of scores in order all the time.

Sort them on every page load, and you're resorting the same data thousands of times a second, slow and expensive.

The trick is to never sort at read time at all.

So we store every score in Amazon DynamoDB, a serverless database that keeps rows physically ordered by their sort key.

Ordered ascending, smallest first.

Which is exactly the wrong direction for a leaderboard.

So we flip the scores upside down.

When a player scores 4,000, we subtract it from a fixed ceiling, 6 nines, and store the result as a sort key.

Now, the best player has the smallest key, and ascending order becomes highest score first.

Two small details make it bulletproof.

We pad the number with zeros so it sorts correctly as text.

And we glue the player's ID onto the end, so two identical scores can never collide.

The table itself is keyed by player.

One row per player, per board.

So updating your score is a single write.

Then we add a global secondary index.

A second, automatically maintained view of the same data, grouped by board and sorted by that inverted score.

That index is the leaderboard Read it top-down, and the ranking is already done The live board never stops moving, though The moment scores change,

yesterday's top 10 is gone forever So we add a second,

smaller table for history A snapshot table that freezes the top 50 Who ranked where,

at what moment Before a single line of code touches these tables, we decide who's allowed to That's IAM,

one execution role, shared by every function we're about to build With exactly two abilities Access to our tables,

and permission to write logs Five functions, same job description One role covers them all

Now the backend Five AWS Lambda functions Small pieces of Python that only run when called, and cost nothing in between

Each one does a single job The first takes score submissions

It writes your score to three boards at once The all-time board, today's daily board, and this week's weekly board

And it plays fair It only overwrites your old score if the new one is higher The second reads the board

One query against that inverted index, the top 25 rows, stamped rank 1 through 25

A few milliseconds and no sorting anywhere The third answers the question every player actually cares about Where do you rank?

It counts how many players sit above you in the index Adds one, and that's your rank

Turn that into a percentile against the whole board Because top 8% sounds a lot better than rank 200.

The fourth is the historian.

On request, it copies the current top 50 into the snapshot table, stamped with the moment it was taken.

And the fifth works for us.

A simulator that invents dozens of players, names, countries, scores, so we can test the system under load without recruiting real gamers.

It batch writes up to 90 rows in one shot More than Lambda's default 3 second timeout can survive

So we raise its timeout to 10 Five functions, but a browser can't call a Lambda directly So we put Amazon API Gateway in front

A REST API with five routes Submit a score, read the board, check a player,

take a snapshot, run the simulator Each route uses proxy integration The whole HTTP request goes straight to the function,

and the function shapes the whole response.

And every route allows cores, cross-origin requests, because our dashboard will live at a different address than the API,

and browsers block that unless the API explicitly allows it.

Deploy it to a production stage, and the whole backend sits behind one public URL.

Last piece, something for humans One small EC2 instance running Ubuntu With two doors open Web traffic for visitors,

SSH for us On it,

Nginx A web server built to hand out static files fast Serving a one-page dashboard A tiny config file tells

that page the backend's URL No framework,

no build step One HTML file and Nginx And quietly watching all of it CloudWatch.

Every one of the five functions streams its logs there.

That's the second half of the role we created.

When a score doesn't show up, that's the first place we look.

Now the payoff.

Open the instances public IP in a browser.

The dashboard loads.

Empty.

Click Seed Data, and the simulator floods the table.

Refresh.

There's the board.

Sorted top to bottom, avatars, country flags, the query time on screen reading just milliseconds.

Flip to daily.

Weekly.

Click a player.

Rank, percentile, games played.

No cache to warm, no cluster to babysit The database never sorted anything The scores were born sorted

Step back and count the pieces

Two DynamoDB tables A live board that sorts itself And one for history One shared IAM role Five Lambda functions Submit,

query, stats, snapshot, simulate One API gateway front door with five routes One EC2 instance serving the dashboard,

and CloudWatch logging every run.

And when nobody's playing, the serverless half costs nothing.

Functions and tables bill by use, not by the hour.

You've watched it come together on a diagram, but this design really sticks the moment the board lights up in your own browser, running on your own build.

So we made that free.

Two kinds of hands-on labs.

First, five mini labs.

IAM, DynamoDB, Lambda, API Gateway, and EC2.

Each a short, focused rep on one service from this video.

Then the capstone, a real AWS account where you build this exact system, the role, the two tables with the inverted index,

all five functions, the five API routes, the dashboard.

Then seed it and watch your own leaderboard sort itself.

The links are below.

If this one clicked, subscribe.

This video is part of a free AWS Crash Course, and more builds like it are on the way.

Tell us in the comments which system you want us to design next.

See you in the next one.

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

ShadowingEnglish.com – 영어 쉐도잉 연습

쉐도잉(Shadowing)으로 원어민처럼 영어를 말하세요. YouTube 영상을 한 문장씩 듣고 따라 말하며, 진짜 발음과 유창성을 키우세요. IELTS 학습자들이 선택한 방법.

쉐도잉 연습: Build a Real-Time Leaderboard on AWS with DynamoDB - YouTube로 영어 말하기 배우기

이 레슨을 통해 배울 것

핵심 어휘와 구문

연습 팁: Shadowing을 잘 하는 방법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉 연습: Build a Real-Time Leaderboard on AWS with DynamoDB - YouTube로 영어 말하기 배우기

앱 다운로드

이 레슨을 통해 배울 것

핵심 어휘와 구문

연습 팁: Shadowing을 잘 하는 방법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법