AWS(1)

#### 概要 AWS re:Invent 2017に参加して面白かったセッションの備忘録です。 最近仕事でcache+DBの構成を考える事も多かったので自分の周辺知識の補強のためにもまとめておきたかった。 ある程度AWSの知識が前提となるような内容となっているのはご留意下さい。 #### AWS の BestPractice はどこから得るか？ 　AWS の情報探す際は公式のドキュメント、クラスメソッドなどのまとめ記事を使う事が多いと思います。 　しかし、毎年行われるre:Inventのセッションを検索してみると、AWSのエンジニアが各種サービスのBest Practiceを紹介していたり、AWSユーザの企業がユースケースを披露していたりとためになる情報が多くあります。 <br /> 　スライドも分かりやすくに作ってある場合も多く、難しい英語が使われている箇所も少ないので色々見てみるのも勉強になると思います。 <br /> re:Invent 2017の keynote で プレゼンを行った netflixの エンジニア Nora Jonesさんのセッションもここから検索できます。 > 参考記事: > [AWS最先進ユーザーNetflix - 「サル軍団」にシステム障害を起こさせる](http://itpro.nikkeibp.co.jp/atcl/column/17/122800596/010500003/) <br /> #### AWS re:Invent 2017のアジェンダがまとめられたサイト 　AWS re:Inventのセッションの内容とかスライドは[このサイト](https://www.portal.reinvent.awsevents.com/connect/search.ww) で簡単に検索することができます。 　例えばElastiCacheと検索すると関連するセッションとその概要とYoutube動画・Linkedinのスライドが閲覧できるので、英語でも問題ないという方はここで調べてみても良いでしょう。 #### slideはSlideShareにアップロードされている <iframe src="//www.slideshare.net/slideshow/embed_code/key/y4N9DIadVLES1O" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/AmazonWebServices/cache-me-if-you-can-minimizing-latency-while-optimizing-cost-through-advanced-caching-strategies-atc303-reinvent-2017" title="Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017" target="_blank">Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017</a> </strong> from <strong><a href="https://www.slideshare.net/AmazonWebServices" target="_blank">Amazon Web Services</a></strong> </div> <br /> #### Youtube動画で内容も聞くことが出来る <iframe width="560" height="315" src="https://www.youtube.com/embed/WFRIivS2mpo" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe> <br /> #### 本題 ##### Cache Me If You Can ? > Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies 自分がcahce + DBの構成に苦心してた中、re:Inventで魅力的な名前のセッションを見つけた。 ##### なぜキャッシュは必要なのか <iframe src="//www.slideshare.net/slideshow/embed_code/key/y4N9DIadVLES1O?startSlide=4" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/AmazonWebServices/cache-me-if-you-can-minimizing-latency-while-optimizing-cost-through-advanced-caching-strategies-atc303-reinvent-2017" title="Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017" target="_blank">Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017</a> </strong> from <strong><a href="//www.slideshare.net/AmazonWebServices" target="_blank">Amazon Web Services</a></strong> </div> このセッションでは Adtech業界でのキャッシュの必要性 - 特にpublisherとadvertisersを紐付け方 - についてまとめている。 そして高速化の方法を3つ上げている 1. Increase rate : **Complex** * 各種トランザクションの時間を短くする。ロジックの最適化O(n)の処理をO(nlogn)にするというようなイメージだろうか。最適化には終わりがないので難しいアプローチだと思います。 1. Parallelize: **Complex** * 並列化。各種トランザクションの実行を並列に実行する。これもアプリケーションの実装が複雑になってしまう 1. Do Less: **Easy** * やることを減らす。つまりストレージのアクセスを減らすことという意味かと。 * これがCachingにつながる ##### Cachingの種類 <iframe src="//www.slideshare.net/slideshow/embed_code/key/y4N9DIadVLES1O?startSlide=13" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/AmazonWebServices/cache-me-if-you-can-minimizing-latency-while-optimizing-cost-through-advanced-caching-strategies-atc303-reinvent-2017" title="Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017" target="_blank">Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017</a> </strong> from <strong><a href="//www.slideshare.net/AmazonWebServices" target="_blank">Amazon Web Services</a></strong> </div> ###### Edge Caching 　マルチリージョンにクライアントに近い場所にキャッシュを持つという意味でのEdge Caching。ここではAmazon CloudFrontが紹介されている。 TeamNetwork というドイツの企業のユースケースでCloudFrontの活用事例が紹介されていた。彼らはAdtech用のbiddingサービスのコンポーネントを提供しているようで、世界中のユーザに **300ms < の latency ** で、かつ ** 100%のDBライクな整合性が必要 ** という目標のため CloudFrontを使ってる模様です。 <br /> ###### Web Tier & App Tier Caching 　上図のWebとAppの違いは下記の様なイメージ * Web : アプリケーションがStorageを見に行かない、下位のInnerサービスを取り扱うアプリケーションのこと * App: ストレージを直接扱うResourceサービスのこと <br /> 　Web Tierの解決方法の一例として vernish, nginx, squidなどの一般的なミドルウェアも挙げられていたが、 Amazon API Gatewayでの解決方法も示唆されていました。これは簡単にAPI作れるが、requests per secで課金されるので大規模なシステムで使うのは少しお金がかかりすぎるという問題はあるそうです。 　App Tierに関しては直接ストレージを取り扱うアプリケーションであることから、Storageの前段にElastiCacheを用いてストレージアクセスを極力減らすことで効率化を狙うべきと書かれています。こちらに関しては次のDatabase Cachingでも詳しく触れられています。 <br /> ###### memcached VS Redis on Elasticache よくElastiCacheを使う上で悩む memcachedを使うかRedisを使うかという問題。このセッションでは二枚のスライドで解説されています。 <iframe src="//www.slideshare.net/slideshow/embed_code/key/y4N9DIadVLES1O?startSlide=42" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/AmazonWebServices/cache-me-if-you-can-minimizing-latency-while-optimizing-cost-through-advanced-caching-strategies-atc303-reinvent-2017" title="Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017" target="_blank">Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017</a> </strong> from <strong><a href="//www.slideshare.net/AmazonWebServices" target="_blank">Amazon Web Services</a></strong> </div> <iframe src="//www.slideshare.net/slideshow/embed_code/key/y4N9DIadVLES1O?startSlide=43" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/AmazonWebServices/cache-me-if-you-can-minimizing-latency-while-optimizing-cost-through-advanced-caching-strategies-atc303-reinvent-2017" title="Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017" target="_blank">Cache Me If You Can Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies - ATC303 - re:Invent 2017</a> </strong> from <strong><a href="//www.slideshare.net/AmazonWebServices" target="_blank">Amazon Web Services</a></strong> </div> データの永続性や保存するデータの柔軟さなどが比較で挙げられていました。 redisは **very fast !** 、 memcached は **fast !** と書かれているが、AWSはredis推しなのかも？？ <br /> ###### Database Caching 　App Tierとの違いがわかりづらいのですが・・・DynamoDBなどのストレージの前段にElastiCacheを置くことも良いが、DAX (DynamoDB Accelerator) を用いて更に効率的にキャッシュすることによるメリットが話されています。 　DAXの便利な部分は、キャッシュを使う上で一番面倒なキャッシュのキーをどうするか、中に保存するデータのフォーマットをどするかということを吸収してくれる仕組みがある点です。これを上手く活用してアプリケーションをシンプル化しようという事だと思われます。 　また、キャッシュにはNegativeキャッシュというStorageにデータが無いことを意味するキャッシュを保存することでhit rateは飛躍的向上することも書かれていました。 <br /> #### まとめ 　キャッシュ戦略はとても重要で、opennetwork社のようにあらゆるtierで行って課題を解決しているのはとても素晴らしい取り組みです。 　さらに、AWSは多くのサービスを提供してそれぞれの解決の難しさを吸収しているのがとても印象的でした。 　ただ選択肢が多い分、最終的にはmemcachedを使うか、DAXを使うかなどの技術的な検証はユーザに委ねられているところもあるので、自分も含め勉強を続けていく必要があると思います。