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

技

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

https://platform.twitter.com/widgets.js

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

https://platform.twitter.com/widgets.js

尚、本ブログの内容はタイトルの通り私個人のものであり、所属企業・部門見解を代表するものではありません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)の↓とかを参照されたい [slideshare id=2FNMCpo8fSYiZ1&w=595&h=485&fb=0&mw=0&mh=0&style=border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;&sc=no]

・言いたいこととしては、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"-うぇ〜い(スイマセン、個人ブログなんで諸々ご了承くださいｗ)

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したいって思っちゃうカモ…！？

amzn_assoc_ad_type ="responsive_search_widget"; amzn_assoc_tracking_id ="diary045-22"; amzn_assoc_marketplace ="amazon"; amzn_assoc_region ="JP"; amzn_assoc_placement =""; amzn_assoc_search_type = "search_widget";amzn_assoc_width ="auto"; amzn_assoc_height ="auto"; amzn_assoc_default_search_category =""; amzn_assoc_default_search_key ="Nike";amzn_assoc_theme ="light"; amzn_assoc_bg_color ="FFFFFF"; //z-fe.amazon-adsystem.com/widgets/q?ServiceVersion=20070822&Operation=GetScript&ID=OneJS&WS=1&Marketplace=JP