ミニマムなAWS Summit Tokyo 2019 Day3に行ってきたのでまとめレポート

表題の通り AWS Summit Tokyo 2019 の Day3 だけ行ってきました。
3日間行きたかったけど都合つかず…。

企業ブースには寄らず、講演拝聴スケジュールを詰め込んで、合間にAWS認定資格の保有者しか入れない「認定者ラウンジ」に入ったりした程度で、かなりミニマム（かつギッシリ）な感じの1日でした。

こんな感じの拝聴予定でした。リンクはそれぞれの発表資料 or 他者さまのまとめとなっているのでいい感じに飛んでいただけると思います。(ほとんどクラスメソッドさんのまとめですが公式資料が出たらそっちに切り替えます)

------------------------------------
6月14日 10:00-11:30
　 基調講演
------------------------------------
6月14日 12:00-12:40
　メルカリ写真検索における Amazon EKS の活用事例
------------------------------------
6月14日 13:00-13:40
　【仮】来たるべきAI時代のための「イケてる」データ基盤の作り方
------------------------------------
6月14日 14:00-14:40
　Deep Dive DynamoDB
------------------------------------
6月14日 15:00-15:40
　ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker運用の知見
------------------------------------
6月14日 16:00-16:40
　めざせ！サーバレスプロフェッショナル
------------------------------------
6月14日 17:00-17:40
AWS & Alexa Automotive : Worldwide Automotive industry trends------------------------------------

13:00 - 13:40 のだけ会場がわからず（なんか地図持ってなかった）のですっぽかして認定者ラウンジでメモを整理したりしてましたが、それ以外はなんとか回れました。

企業ブースは全然回る暇ありませんでした…。
ノベルティ交換と共にメルアドを渡さなきゃいけなくて今後それらの企業からのいろんな宣伝メールがくるのが面倒臭いと思うと億劫になった感もありますが…。

基調講演

今回は「サイレントセッション」という仕組みでセッションが行われていましたが全然活用できませんでした…ｗ

仕組みは簡単に書くとこんな感じでした。

1. 会場に入る前に渡されるバッグの中にイヤホンが入っている
2. セッション会場の椅子に座ると前の席の背中に他言語翻訳レシーバーがぶら下がっている
3. そのレシーバーにイヤホンを差して適切なチャンネルに変えると希望のセッションが聴ける
4. 大会場ではセッション番号で聴けるセッションが別れていたり、別の個室的な会場だと英語と日本語を切り替えられたりしてかなり便利だった

なぜ活用できなかったかというと、あるはずの前の席の背もたれのレシーバーが存在しなかったから！ｗ

これは、仕組みを理解していなかった前の席の方が、自分の席の背もたれについているレシーバーを使っちゃってて、私がレシーバーを使えない状況だったからです…。

なので英語のスピーチをそのまま拝聴。

TOEICは550点しかありませんでしたが、なんとなーく半分くらいはわかったような…？

今回明らかだなーと思ったのは、AWSはパブリッククラウドとして急成長に次ぐ急成長を続けており、「もう出せそうな新サービスはあらかた出しちゃったよ」状態になっているということ。

これまでの基調講演だと、毎年毎年1個か2個は新サービスの発表があってエンジニア界隈が盛り上がったりしたのですが、今回は1個もありませんでした。

私はそれは別に悪いことではないと思っています。

プラットフォーム業者として支援できるジャンルのサービスは一通り提供できるようにしたということだと思いますし、それってかなりすごいことです。

いま、AWSを使って余裕のある資金と十分な実装力があれば、頭の中のアイデアをなんでも思い通りに実装できる状況になっている、そういうことだと思います。

つまり今後はAWSを利用して実装する側がどんどん実装をしていくフェーズなのかなと思いますし、逆にAWSは一通り出揃った各種サービスをいかに有効活用してもらうかを考えていくフェーズなのかなと思います。

なので今後はAWSは新製品の発表はかなり少なくなり、その代わり既存のサービスの「かゆいところに手が届かなかった部分のアップデート」みたいなものが多くなるのかなと感じています。

それはそれで楽しみですね！

メルカリ写真検索における Amazon EKS の活用事例

ランチセッションはこちらを拝聴しました。

EKSの学習になるかな？と思いましたが、やっぱり本などで一通り知識を仕入れていないのと、機械学習の知見が無いのとでだいぶ分からなかったです。
が、EKSというかK8Sで機械学習クラスタを構築して運用するといい感じにできるということで、K8Sと機械学習を学び直した後にスライドを読み直すとかなり知見が得られるのではないでしょうか。

発表スライドはいち早く公開していただいているので、リンクから飛んでチェックしてください。

Deep Dive DynamoDB

WebアプリケーションのNoSQLストレージとして従前より幅広く利用できるDynamoDBですが、サーバーレスのアーキテクチャ構成を考える上では鉄板というか必須要素みたいな感じになっているので、サーバーレスアーキテクチャを学んでいく上ではDynamoDBの理解が必須な感じです。
そう思って今回こちらのセッションを拝聴しました。

内容としては初級者も段階的に理解しながらDeep Dive できる感じで非常によかったです。
リンク先のクラスメソッドさんのメモを見ればだいぶもう勉強になると思いますが、私もメモを書いたので以下に残しておきます。

DynamoDB DeepDive

•  世界最大のEコマースサイトであるAmazon.comが利用しているNoSQLデータベース
• サービス提供開始から年月がたっておりAWSの中でも古いサービスではあるが今も大きなアップデートが続けられている
• トランザクション機能はめっちゃ便利
• データ構造的に殉難なデータ配置と可能
• パーテションキー＝主キー ソートキー＝検索性向上のために与える複合キー
• パーテーションは3つの領域に格納される
• LSIとGSIの使い方が大切 どちらもマッピングテーブルを別に追加して原本と組み合わせたりして使う
• GSIはテーブルの書き込みリクエストがあると先にレスポンスを返してから非同期でGSIに更新をかける

大規模でのDynamoDB

• RDSだと水平分散・垂直分散・もしくはその両方
• Cassandraみたいな分散DBだと可溶性は高いがアドミニストレーターオペレーションが多くそこのコストが多い
• ではDynamoDBだと…
• マネージドなのでメンテナンスフリー（小さい）
• DevOps（自分で作った昨日は自分で運用する）がやりやすい
• キャパシティ・オートスケーリングでコストパフォーマンスを自動的に最適化
• パーテーションに対するキャパシティの管理の問題があり以前は設計力が多く必要だった
• AdaptiveCapacityの登場によりそのオペレーションからも解放されるようになっている
• on-demandモードを利用することで事前のキャパシティ管理が不要になり利用料に応じた課金体系が適用される
• キャパシティ周りの改善については2019年サンタクララのサミットのスライドが参考になる

DynamoDBというNoSQLの使い方

• RDBや他のNoSQLとは考え方が違うのでベストプラクティスを参考にしてほしい
• ユースケースの理解が大前提 向いていないパターンもある
• アクセスパターンの理解
•     read / write の比率・頻度
• NoSQLデザインパターンがいろいろあるので参考にする
• NoSQLは正規化しすぎるとパフォーマンスが悪くなる場合がある
• データの持たせ型の典型パターン
•     1:1 リレーション or キーバリュー 型
•     1:N リレーション or プラットフォーム
•     N:M リレーション
• GSI OVERLOADING これかなりつかえる技なので覚えてほしい
• 具体的な利用例
•     Amazon Audible eBook Sync Service
•         端末Aで読んだ続きを端末Bでも読める
•     ER図をきちんと書いた
•     行われる処理を全部洗い出した
•     DynamoDBテーブルのテーブル定義書を書いた
•     元のテーブルから複数のGSIを定義
•     Query ConditionsというテーブルとAPIとクエリ条件の紐付け表一覧を作成した

ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker運用の知見

こちらのセッションがいまの業務内容も相まって個人的に一番刺さりました。
アカツキさんのECS運用の知見がぎゅっとつまっていてすぐに参考にできそうな感じでとてもよかったです。

以下わたしのメモ。

ロマサガRS

導入

• ゲームのトラフィックについて
•     イベントオープンの昼などにスパイク
•     最大のピークが読みづらくスケールしやすいシステムが大事
• リリース半年だが大きなダウンタイムなし

アーキテクチャ

• ロマサガのスマホ版
• リリース３週間後で1千万ダウンロード
• ゲームは１回ボタンを押されると１回以上APIが飛ぶそれが長時間多数人で行われる
• アーキテクチャは基本的にECSクラスタの複数個システムにより構成される
•     ゲームサーバ
•     認証サーバ
•     お知らせサーバ
• データストアは水平分割
•     プレイヤーデータ（Aurora）
•     session / cache （mamocached）
•     認証データ（Dynamo）
• APIプログラミング言語はElixer
• ほとんどのレイテンシが50ms以下
• インフラの管理はCloudFormationで管理
• CloudFormation自体はKumogata2を利用してラッパーコードとして管理して実行
• プロセス（サーバ）は全てDocker管理
• 特定のサーバだけ環境変数がおかしいなどのトラブルがない
•     デプロイが安定する
•     Immutableにすれば他のコンテナサービスでも同じ
• Fargateはデメリットを考慮して利用しなかった
•     スケールアウトの時間はECSとあまり変わらない
•     ロギングがCloudWatchLogsのみだった（使いづらい・高い）
• ロギングいろいろ
•     CloudWatchLogs
•     Datadog Logs Management
•     S3
•     その他プレイヤーの行動ログやDWH
• 監視もいろいろ
•     自動復旧の仕組みを作り込んでいる
• Redashでログを可視化して分析している
• 100%Docker運用

負荷対策

• 負荷テストの事例
•     大前提として負荷テスト&改善フェーズを必ず確保する きっちり期間をとる
•     負荷テストツールはLocust
•     Locust自体もDocker化して管理
•     目的ごとの負荷テストを実施する
•         単性能テスト
•             N+1 クエリ などを潰す
•         過負荷テスト
•             落ちる想定の量の負荷をかける
•             パラメータのボトルネックを探す
•         高負荷テスト
•             スケールアウトの動作確認
•         障害テスト
•             一部のコンポーネントにトラブルを起こした場合にサービス全体がどうなるか（動くか）の確認
•                 Auroraフェイルオーバー直前にEC2が不正なエンドポイントをキャッシュしてしまいエラー時間が伸びた
•         長時間テスト
•             メモリリークはfd枯渇などを検知できる
•             データ量に合わせて処理時間が伸びる内容のコードは危険
•     負荷テストを何回も回すための仕組みを作るのが大事
•         テスト用に最適化されたユーザデータを作るAPIを用意するとか
•             API１発で最強ユーザーデータができる など
• 負荷テストの結果
•     最大700台のコンテナが稼働
•     稼働率100%
• ECSスケーリングの工夫
•     コンテナをスケールアウトするにはECSインスタンスをスケールアウトさせる必要がある
•     スケールインの際はECSが落とそうとするECSコンテナとEC2が落とそうとしているEC2インスタンスが一致する保証がない（異なることが普通にある）
•     Lambdaとlife Cycle Hookを組み合わせてスケーリングをカスタマイズしてあげる必要がある(スライド参照)
•     スケールアウト時間は2分強

運用の工夫

• デリバリーパイプライン
•     デプロイは今時の感じ
•     CodeBuildを利用している
•         100 Build/day : $100/Month
• サーバレス運用の工夫
•     サーバレスバッチを作った
•         Docker Push → CodeBuild → ECR Push → CoudeBuild で　Push　したばかりの　Docker　Image　を　Run
•     自動復旧
•         「入門 監視」には「大規模システムだと必須」と書かれている
•         Datadog + Lambda を利用して自動復旧を実装した

めざせ！サーバレスプロフェッショナル

こちらは内容ギッシリでマジで最高でした。
1500円〜2000円ぐらいの技術書として売られててもおかしく無いような内容でした。
ですので公式スライドの公開が待ち遠しいです…！

メモは頑張って取ろうと思っていたのですがPCの電池がなくなってしまい泣く泣く諦めました…。
内容としてはメルカリさんのEKSのスライドよりは理解できたので「おっ、俺サーバーレス完全に理解したな！」みたいな感じでした。

AWS & Alexa Automotive : Worldwide Automotive industry trends

こちらはAlexaのテックトーク目当てで行ってみたのですが自動車×Alexaとうことで自動車に関する自動化「Automotive（オートモーティブ）」というジャンルの解説とAlexa Automotive の今後の展開についての発表でした。
USではすでに自動車搭載用のEchoが売られていて、自動車内でAlexaと会話していろんなことをできるようにするためのサービス開発が行われているそうです。
発表内ではいくつかの動画の公開がありました。

まずこれ。

いいですね、アメリカだともう実現されているそうです。
日本でもこれやりたいですねぇ。

次にこれ。

これもいいですねぇ。

日本でも郊外の土地の広さに余裕のある場所だったり、地方都市だったりなら実現できそうです。

手に届く近未来感がいい感じ。

もう1個めっちゃかっこいい未来のコンセプトVideoがあったんですが、Amazonの提携先の自動車メーカーを忘れてしまったので動画を探すことができませんでした…。

Alexaというよりは自動車内での自動化・生活向上という意味合いが強かったですが日本じゃまだ全然立ち上がっていない領域なのかなということで非常に興味深く拝聴できました。

ノベルティ

もらったノベルティはこんな感じです。

左から扇子、イヤホン、涼感マフラータオル（濡らして絞って首にかけると涼しい！的なやつらしい）、AWS認定保有者がもらえるステッカー、AWS認定保有者がもらえるピンバッヂ、でした。

あと、写真にはないですが、AWS認定保有者がビデオ撮影（1分程度「今後の受験者に向けてアドバイス」したりする）を行なったのでオリジナルTシャツをもらいました。

今回は企業ブースにはまったく寄らなかったので他の皆さんがもらってるあれやこれやはもらえませんでした…。
久しぶりに研修的に1日中インプットしてるとなかなかエネルギーを使って疲れました…体力が落ちてる気がするから頑張らないと。