Becoming a Nimble Giant: How DynamoDB serves Nike at Scale を読んだ

AWSでかれこれもう5年以上働いていて、今まで色々なロスがあったけど、その中でも個人的に大きかったのは @riywo が居なくなったことかもしれない(彼がバンクーバーのAWSのサービスを開発するチームに異動してから、コレは!!っていう情報が手に入りにくくなった感)。そんな彼がイイ話だって言ってるので、チョロっと読んでみましたよ、と。

この記事を書いた人のTwitterを見てみると、ポートランドで働くNikeの人で、re:Inventでカマすから見に来てね!な感じらしい。(私は今年はARIAというホテルの会場のStartup Centralというブースにずっといる予定なので、お時間ある方いたらひやかしにきてください :P)

尚、本ブログの内容はタイトルの通り私個人のものであり、所属企業・部門見解を代表するものではありませんmm

はじめに

・重要なイニシアチブの1つに『microservices architecture with cloud deployment』が挙げられる
・近年data-center-deployedなモノリシックなシステムをインクリメンタルにマイクロサービス化してきた
・どんなmicroservice-basedにせよ、データストレージはクリティカル
・シンプルにスケールし且つ運用の手間のかからないDynamoDBはgo-to NoSQL data store

NoSQL Evolution

・Nikeがクラウドへのマイグレーションをはじめた時、self-hostedなCouchbaseとCassandraクラスターを運用していた
・それらのテクノロジーはWorkしていたものの、時が経つにつれメンテナンスが大変になってきて、サービス開発の足かせになってきてしまった
・NikeにおけるほとんどすべてのマイクロサービスはAWSにデプロイされているのでDynamoDBはリプレースの第一候補だった
・DynamoDBの前身であるDynamoはAmazonのショッピングカート用にRDBMSの代替として作られたものだが、今日ではDynamoDBは簡単なAPIでテーブルを作ることができて、always onなlow-latencyの読み書きが可能
・新しいサービスでは開始するためのバリアが低いDynamoDBを選択する傾向が強い

Learning the Model

・ほとんどの開発チームは過去の経験からCassandra and/or Couchbaseに親しみがある
・DynamoDBはitem(よくあるDBでいうところの”row”)とattribute(いわゆる”column”)とkeyで構成される
ってか、この辺は”DynamoDBとは?”的な話なので、オラニエ先生(@oranieoranie)の↓とかを参照されたい

・言いたいこととしては、DynamoDBはシンプルでフレキシブルなのでサービス開発が加速していくZE!っていう感じですかね

Scaling Up

・何百万人ものユーザーを抱えるNikeのフロントエンドにおいてmicroservicesのscalabilityはしばしばconcernに見舞われる
・ここでいうスケーラビリティとは何百万もの書き込みを受け付けられることと、バイボリュームなリクエストをさばくために水平方向にスケールできることで、DynamoDBはこの両方をパーフェクトに満たす
・DynamoDBのパーティショニングの振る舞いについては↑のBlack Beltの資料を参照いただければと思いますが、こちらのポストでは↓のような画像と共に紹介されています
DDB Partition
・ReadとWriteのプロビジョンスループットはそれぞれ別々に値を更新可能
・CassandraやCouchbaseを使っていた時はスケールさせるためにEC2インスタンスを追加しなければならなかったが、安定性において問題が発生することがあった
・DynamoDBを選択することで”no angry sneakerheads trying to cop the latest kicks”-うぇ〜い(スイマセン、個人ブログなんで諸々ご了承くださいw)

Challenges At Higher Scale

DynamoDBを使う上でのチャレンジもある。

Key Design and Throttling

・”hot keys”問題によって多数のトラフィックが1つのパーティションに短期間に集まってしまう場合
・DynamoDBにおいてKeyは分散されていてデータが増えた時に複数のパーティションに分散することが望ましい
・GSIを使う時のKeyの設計は注意が必要
・プロダクションに投入するまでhot key問題に気づかないことが多いのだが、それでは遅いので設計重要

Throughput During Spikes

・Nikeが新しいスニーカーを発売した時のトラフィックパターンは”isn’t just a hockey stick; it’s a steep cliff!”
・顧客の関心が高い新しいプロダクトをリリースしようとする時に複数のサービスをまたぐトラフィックが発生する
・普段とくらべて500%以上のトラフィックが来ることもしばしば
・さすがに秒単位でピークが来る場合にauto-scaleでは間に合わないこともある
・DynamoDBなら事前にプロビジョンスループットを上げておけばイイ。いつスパイクが発生するかNikeは知っている
・エンジニアのマニュアルな操作がなくてもDynamoDBのAPIをcallすれば良い
・それでもテーブルが十分にスケールできておらずスロットリングすることはある。そんな時もスロットルされるのはプロビジョンスループットを超えた分だけで、(全体が止まってしまうわけではなく)リジェクトされるリクエストの割合は小さい。そしてAWS SDKによるリトライもまたスロットリングの一時的なワークアラウンドである

Wrong Tool for Some Jobs

・DynamoDBが全てのワークロードに適しているわけではない
・複雑なクエリパターンが要求される場合はElasticsearchが適しているが、そんな時はAmazon Elasticsearch Serviceを選択する。なぜなら運用面と複雑なクエリのサポートといった点でのベネフィットを享受できる
・グラフデータベースやリレーショナル・データベースが適している場合もある。S3に大量のデータを配置する-RedisやKinesisを中継する-ことが適している場合もある
・ワークロードに応じて適切なツールを慎重に選ぶ

Final Thoughts

・DynamoDBはNikeのクラウド移行に重要な役割を担ってきた
・AWSはNikeのデータのストレージとクエリのスケーラビリティをシンプルなAPIとモデルでtake careしてくれている
・service-basedなソリューションとしてDynamoDBは高い可用性、信頼性、そして合理的なパフォーマンスを発揮している
・DynamoDBは進化を続けていてGlobal Tables/DAX/TTL/Encryption at rest/backup and restoreといった魅力的な新機能が追加されている
・DynamoDBはデータストレージの問題をlong termな視点で解決してくれる素晴らしいソリューションで、データベースクラスタの保守運用にかかる時間を抑えることができ、新サービスの開発に注力できている
・DynamoDBに追加されている機能はNikeのお客様体験の向上に寄与している!

・・・
Want to join the Nike Digital Team? Check out the available jobs here.
⇒ ここまで嬉しいコメントが続くとjoinしたいって思っちゃうカモ…!?

シェアする

  • このエントリーをはてなブックマークに追加

フォローする