この記事は re:Invent2016参加レポート(1) の続きです。

2日目

いよいよ初日が始まりました。昨日までは前夜祭だったのです……！

Keynote Day1 Andy Jassy

YouTube | AWS Japan公式

CEO の Andy Jassy のキーノートで改めて幕が開きます。

詳細は公式が詳しいです。

テーマは SUPERPOWER。
新サービス続々発表。"I'm excited to announce.." を何回聞いたかわからない
より大きくて速いEC2インスタンスと、EC2 Elastic GPU、FPGU付きの F1 インスタンス
S3のデータを直接扱えるSQLエンジン、Athena
AI系も。画像認識のRekognition、音声合成のPolly、自然言語認識のLex
昨日も登場したDr.Matt Wood が飛行機を音声で予約するデモ。すごいけどもはや麻痺していて普通に感じる
Oracleとは言わないが商用DBをディスる。ユーザーはそこから動けない。Auroraで自由をもたらしたい
What Is The Top Aurora Customer Request? PostgreSQL. Aurora は PostgreSQL に対応する!! （一番盛り上がった）
Lambdaをデバイス上で動かすGreenglass
大量データをクラウドに持っていくためのストレージに通信機能を持たせた Snowball Edgeと、エクサバイト級のデータ移動のための Snowmobile（会場にトレーラーが入ってきました…！アメリカンすぎる）

AWSのパワーと進化のスピードを見せつけられた Keynote でした。

ARC301 - Architecting Next Generation SaaS Applications on AWS

公式 | SlideShare | YouTube

マルチテナント対応のサービスをどのようにAWS上に構築するのかというセッションです。

いくつかパターンがある。それぞれが独立した「サイロ」、一部のクライアントはリソース共有する「ブリッジ」、全リソースを共有する「プール」
認証。テナントごとにIAMを割り振る（AWSアカウント分けるとサイロモデルしかできなくなってしまう）
- 認可には JWT (Json Web Token) を使い、ユーザーをテナントとして認識できるようにする
分離は必須ではない。「プール」から始めて必要なところを分離する。テナント個別のカスタマイズを避ける
データの分離。データ量に偏りがあることを意識したパーティショニングが必要
テナント単位でのモニタリングが重要。本業集中のためサードパーティーのツール活用も

参加した際は一般的な話だなという印象でしたが、見返してみると実際このようなニーズに対応するときに参考となるパターンが網羅されており、ぜひスライドを公開してほしかったところです。

2017.01追記

発表スライド公開されたようです！SlideShare

ARC318 - Busting the Myth of Vendor Lock-In: How D2L Embraced the Lock and Opened the Cage

公式 | YouTube

ベンダーロックインにどう対応するか、というのも重要なテーマです。

Desire2Learn : 教育サービスの会社。10年以上やっている
オンプレでやっていたが利用料が増えるにつれて、それを超える余剰リソースを増強していなかなければならなかった
オンプレだと4年位縛られるが、AWS の Reserved Instance だと1年しか縛られない。これは十分短い
Windowsの DFSR(Distributed File System Replication) - 階段関数的なコストがかかる。高い
- NetApp の ONTAP を使った。コストは半分くらいだが、まだ階段関数！
- S3にすると使った分だけのコストになった！……が、CIFSではないのでサービス側の修正が必要。
  - EFSはDFSRより高かったので使ってない
多数ドメインとるニーズあるが、DNSを自前では作らない。また、キャッシュのためにmemcachedを自前では作らない
ログを記録するDBも高かった。Kinesis Firehose から S3 に格納することで 1/4のコストになった
ビックデータ。リージョンが増えるごとに基本コストがかかる。
- 既存の基盤を単に IaaS としての AWS に移すだけだと、最初は安いがある時点以降オンプレより高くなる。そこなったらそのリージョンをオンプレにすることで、全体としてコストを低く抑えられる。
- すべてをAWSのネイティブのサービスに乗り換えることで全体のコストは非常に低く抑えられた。Paas > Iaas
コアでない部分を Amazon に押し付けよう！
その後 Solution Architect の方からのオンプレからハイブリッドクラウド移行話があったが、これはちょっと宣伝っぽかった

AWSに縛られるのもある意味ベンダーロックインではあるのですが、オンプレで縛られるよりは断然コストが安いということでしょうか。縛られ方としても、技術では縛られますが、契約としては縛られない。

※このセッションはスピーカーの方の英語が（私の英語力では）聞き取りづらく、後で YouTube を見て分かった話が多かったです。

WWPS401 - Data Polygamy: The Many-Many Relationships among Urban Spatio-Temporal Datasets

公式 | YouTube

40x 系のセッションにも参加してみようと思いたち、聞きに行きました。

タイトルには聞きなれない単語がありますが、Polygamy とは他重婚、Spatio-Temporal とは位置的・時系列的という意味だそうで、時間別・場所別の気温や交通量や……といったデータを指す用語です。

NYの交通データをもとに以下のような疑問に答える研究
- なぜ特定の日はタクシーが少ないのか？→風が強い日だった
- 速度制限を厳しくしたら事故は減るのか？→減ることがわかった。25マイル制限をつけた
全部で1200データセット、うち300が Spatio-Temporal
数多くのデータセットの中から関連するものを見つけることはむつかしい。needle in heystack
数学的な工夫をした。時間×位置の平面上で高さを値とした曲面のトポロジーを考えた。
- 「似たデータ」とはスパイクや谷の位置が似ているということ
- 一定の閾値を超える極大・極小のある時間・位置を見つけるような処理を行った
- まずは閾値 = 特定の極大値からはじめて、閾値を減らしていくとほかの極大が出てくる
- その極大の見つかりっぷりをツリー構造で表す（このあたりほとんどついていけなかったです……）
AWS で (EMRで) Hadoop 使った。評価に200分
ほかのデータとの関連が高かった（Polygamy）のは、天気のデータ

実際のデータや研究結果がここにあるそうです

事例としては面白かったですが、話の内容は AWSとほとんど関係なかったですw

DAT320 - AWS Database State of the Union

公式 | YouTube

AWSのデータベース関連サービスの全体感についてのセッションです。AWSのDB担当 Vice President、Raju Gulabani さんです。

特に Dynamo、Aurora のパートが濃かったです。これまでオンプレで苦労してきた可用性・スケーラビリティの両方が、クラウド向けに再設計されるといいことづくめですね！

AWS のデータベース戦略とは

顧客のニーズに寄り添う
マネージドサービスにする
クラウドを活かす
オンプレへ／からのデータ移行をサポート
ユースケースに応じた別サービス

RDB

RDSの話はほとんどなく、Aurora をかなり推している印象
Multi AZ では 99.95% の可用性。フェールオーバーは 30-45秒（DNSベース）
Aurora は RDB をクラウド向けに再実装したもの。
- MySQL版
  - 5倍の性能。 100k writes/s & 500k reads/sec
  - 6-way のレプリカを 3つのAZにまたがって作れる。最大64TB、15リードレプリカ
  - 暗号化や Lambda のストアドも
  - 実例として、ほぼリアルタイムの分析にも使える。6つのリードリプリカを使った
- Postgres （今日発表！）は 9.6 互換
- 10 リードレプリカを 10ms の遅延で使える。MySQL 版同様、6-wayレプリカを3AZで。
移行サービス。テラバイト級を $3 から

NoSQL & In-Memory

Dynamo
- 2004年にOracleでダウンがあり苦労した。Jeff Bezos が CTO の Werner Vogels に何とかしろといった。 Dynamo の論文(PDF) には Werner Vogels の名前が
- Aurora では「RDBであること」という以外の要件を全部取っ払った。NoSQLではなにをするか？
- スキーマレス、スケーラブルなデータストア。読み込み／書き込み性能以外の要件は考えなくてよい
ElasticCache - memcached, redis

Big Data

Redshift : $1,000/TB/year
- 企業のデータの90%は分析されていない - 安くスケーラブルなデータウェアハウスが必要だと思った
- 128 nodes / 最大2PB。3分でペタバイト級のプロビジョニングができる
EMR
- 既存のオープンソース、また Spark や Presto を使いたいというニーズにこたえるもの
Athena
S3上でSQL。1TBのスキャンあたり$5（BigQueryと一緒ですね）

Analytics

QuickSight : Redshift, RDS, S3 Excel, Salesforce, SPICE のデータソースが使える。super fast. AD Integration
ElasticSearch : 全文検索のほか、Kibana と合わせてログ分析に使われるようになってきた。

DAT301 - Amazon Aurora Best Practices: Getting the Best Out of Your Databases

公式 | YouTube

Aurora の移行や性能に関するベストプラクティスの紹介と、Intercomでの事例の紹介でした。

Aurora への移行
- MySQL RDSから -> コンソールでワンクリックで移行できる
- EC2/オンプレmySQLから -> バックアップやスナップショットをS3経由でコピー、レプレケーションを設定。負荷を Aurora に切り替える
- Oracle,SQLserver から -> AWS Schema Conversion Tool でスキーマ変換の事前調査ができる。変換後、DMS で取り込み
Aurora の性能
OLTP向き。接続数に比例する。DB/スキーマ/テーブル／レプリカ数が増えても性能は一定
MySQLのチューニング手法は使える
同時接続数を増やす
リードレプリカの活用
クエリキャッシュを使う。CloudWatch で見れる
個別メトリックス(CPU/IO/IOPS,...)は気にしない。アプリ性能ニフォーカスする
リアルタイムレポート／分析
- 旅行サイトの例 - リアルタイムレコメンド 700+ Users, 8TB Dataset
  - 移行前 - Storage + DB を各ユーザが参照。使っていない時もコストかかる
  - 移行後 - Aurora Cluster - DNS LB -> users
ゲーム会社の例 - 一定のレイテンシ
- 移行前 - NoSQLでやっていた。パーティショニングしていたが集中することがあった
- 移行後 - Aurora は Massive Pallarel Query に対応している。ホットパーティション問題もない
- NoSQLで作るとリクエストごとに課金されるが、Auroraならキャッシュでカバーできるので課金されない
スケーリングは定期実行の Lamdba で
Lambdaとの統合
イベントをS3からAuroraにLambdaでアップロードする。完了通知もLamdbaで。
監査のためのテーブルトリガも Lamdbaを呼び出すコードがかける（直接Lambdaが書けるわけではない）
Intercom社の事例
顧客との連絡手段を提供するサービス。twitter, facebook, mail, www, スマホアプリ
.js, Rails, MySQL の構成
MySQLのインスタンスを増やしても思うように性能上がらなかった。20億行がメモリに乗らない
移行先を悩んだ。候補は Dynamo, Partitioned RDS (MySQLは対応していなかった), Aurora
Auroraにした。MySQL5.6互換が今の利用バージョンだった、速度、耐障害性、スケーラビリティ
商用と同じ負荷でテストした。ツールを作った
70ステップのチェックリストを使った。結局8分のダウンタイムで移行できた

Japan Night

セッションが終わってちょっと空いた時間にラスベガスで有名な噴水など_一人で_観光した後、日本からの公式ツアー参加者ほぼ全員があつまる懇親会に参加してきました。いろいろな方と知り合える良い機会でした。パートナー企業の方が多く、ユーザー企業の方の割合は4割くらいだったでしょうか。

AWSの各サービスアイコンを使ったビンゴはAWS社の鉄板ネタらしいです。続いて、勝ち抜きクイズです。EC2の正式名称やリージョンの数に始まり、昨日の James Hamilton の靴の色は？などかなりマニアックな問題で盛り上がっておりました！

3日目

とうとう最終日です。東京ドーム何個かの広さがありそうなめちゃめちゃ広いホールで朝食を取り、キーノートの会場に向かいました。

Keynote Day2 - Werner Vogels

YouTube | AWS社公式まとめ

Amazon社のCTO、Werner Vogels のスピーチです。ひたすらパワフルです。

詳細は公式が詳しいです。

キーワードは Transformations。Tシャツがオプティマスプライムになっててカワイかったです
新サービスが目白押し！！多すぎてここで紹介するのは控えます。Qiitaの記事 AWS re:Invent 2016 発表サービスを三行でまとめるが網羅性高くて参考になります！
Twillio CEO の Jeff Lawson 氏の講演もパワフルでした。これまでのコールセンターは世界最大のものでも8,000人が1億件／年の会話。クラウド(Uber?)では 50万人のドライバーが40億件／年の会話。自前の交換機では対応できない。速さも重要。年間8,000回のサービス更新をしているが 99.999%の稼働率。100万人の開発者が1000億回のAPIコールがある。AWSはTwillioを利用しているしTwillioもAWSを利用している。
Vogels氏「Lambdaは時間制限があって苦労していた！状態管理付きのサービスだ！Step Functions!!」（会場、名前だけでは何がすごいのかわからず盛り上がれない）
分析の80%は価値を生まない作業になっている。データの取り込みだ。それを減らしたい。データ分析には10の課題があるが、AWSのサービスにはまだ足りていないピースが5つある。それを全部うめるサービスが Amazon Glue だ！このあたりの動画

最後は re:Play に登場するDJを紹介して元気に去っていきました。

実は昨日、日中韓向けのセッションで Werner Vogels と話ができるイベントがあったのですが、行き損ねてしまい最後の集合写真に入るだけになってしまいました。残念。

DAT303 - Deep Dive on Amazon Aurora

公式 | YouTube

Auroraの内部、特に最近の性能向上の工夫に関する話です。

個人的には、今回最も面白かったセッションです！！クラスメソッドさんのレポートも詳しいです。

性能向上について - Auroraはとにかくスケールするデータベース。MySQLの5倍早い

すべての処理は非同期、コミットはグループ化される
MySQLはコネクションとスレッドは1:1だが、Auroraはepoll
ロックも粒度が細かくなっている。Insert/Delete/Scanが同時に実行できる
普通のRDBのレプレケーションはスレーブ側の書き込みに70%の処理能力が使われていて、読み込み性能向上に寄与するのは30%だけだった。Auroraは Multi AZ な Shared Storage に書き込むのでスレーブ側は読み込みに100%処理能力を使える
キャッシュリードの向上：ディクショナリのカタログ化、NUMA対応（各CPUの近いところにあるメモリを使う）。25%向上
非キャッシュリードの向上：スケジューラの改良、データ取得元ノード選択の改良、先読みの改良。10%向上
v1.9 でロックをbitmapに圧縮、スピンロックをfutexに、ロック解除のアルゴリズムのオーダーをO(ロック数×待ち数)からO(ロック数)に。TPC-C 100で29倍の向上！
バッチインサートの改良
インデックス作成の改良。ブロックベースの先読みから、実際の位置ベースの先読みに。MySQLの2-4倍早い
空間インデックス(wiki) をR-Tree から Z-index に。12倍くらい早い

耐障害性について - 性能がすごくてもDBが生きていないと意味がない

64TBまでの自動拡張。Multi AZ で書き込み、お互いに同期。S3にバックアップ(9.11レベルの災害に対応)
レプリカは最大15まで。自動的に障害ノード切り離す。リードレプリカで性能向上できる
複数セグメントで時刻をずらしてスナップショットをS3に取得
復旧時のログ適用時間はゼロ。当該データ読み込み時にオンデマンドで実行する
エンジン部分のプロセスが落ちてもキャッシュは残っている
フェイルオーバーにかかる時間（検出後）は、30%が0-5秒、40%が5-10秒、25%が10-20秒、のこり5%が20-30秒
ほかの停止要因 - パッチ、スキーマ変更、再編成、ユーザーによるデータ破壊の復旧なども早い
ゼロダウンタイムのパッチ適用（ロングクエリ、パラメータ変更など適用できない例外はまだまだある）
Copy-On-Write ができるのでクローンが簡単に作れる。テストDB作成、分析用コピー作成、再編成が容易にできる
Online DDL : ブロックごとにスキーマバージョンを持っている。Add Nullable Column at the end のみ対応
以前の状態に戻すことは簡単。参照ポイントを戻すだけ。リストア不要。
PostgreSQL対応も、ストレージ部分はMySQLと同等。今はPreview
r3.large が高かった。t2.small が使えるようになった。
各種のセキュリティ認証。HIPPA、ISO27001、etc. 監査をONにした時の性能低下も20%程度

上記はみな2017/Q1 には実現されるそうです！

データベース技術はもうやることがなくなってきた感がありましたが、クラウド全体になるとまた進化が進んでいる印象です。こういうことができる技術者が続々 Aurora に集まっているかと思い、今後も目が離せません。料金は1-2割高いですが、RDS よりも Aurora のほうが断然面白いですね！

CON310 - Running Batch Jobs on Amazon ECS

公式 | SlideShare | YouTube

今日はコンテナ関連のセッション多めです。こちらはECS上でのバッチ実行に関するセッションです。

メイン会場のホテル Venetian からこちらの会場の Mirage に会場を移動するのに結構時間がかかり、前半間に合わず……

入出力はS3に置く
実行時間が決まっているタスクにはスポットインスタンスを使う
MapBox の事例。Day2の Keynote にも登場した、地図の総合サービス。
- 14のサービス、3500のインスタンス、5億時間／年の処理
- watchbot - SQSからメッセージを受け取って at least once でタスクを処理するライブラリ
- bash の exit code のルールを作った。0: OK、3: reject、4:no-op、それ以外。エラー通知とキュー消費の有無が違う
- 複数ジョブの終了を待つ reduce mode
- Watchbot の Lambda に比べていいところ - 実行時間、メモリ、同時実行数の制限がなく、やることも自由。ただ、今は DynamoDB Stream/Kinesisのサポートがないよ！
- ECS Optimized AMI は EBSのコストに注意！EBS より Instance-Store のほうが非常に速いということもあり、独自のAMI作ることも検討しよう
- デモは一部うまくいかず…… でしたが、mbox hogehoge という社内コマンド経由でいろいろな作業をラクにしていました！エムスリーはこういう工夫、BigQuery ラッパーの bq_* シリーズくらいしかやっていないですね

CON313 - Netflix: Container Scheduling, Execution, and Integration with AWS

公式 | SlideShare | YouTube

NetFlixでのコンテナ活用事例です。

11/29の発表でもあったように、VMベースで十分な耐障害性、マイクロサービス、CI/CD、スケーリングができている。それでもコンテナが必要？
必要。開発スピードを高めたい。ローカルで開発してできたらデプロイ、依存管理を簡単に、利用リソース定義のシンプル化
スケーラブルなエンコード基盤開発 - VMで1カ月→コンテナで1週間。Niagala - 全コードビルドを数時間で。デバッグ時間を劇的に短縮。サービス開発に集中でき、Node.js移行できた
Titus - Netflix独自のコンテナ／ジョブ管理ツールを作った。既存のコンテナ管理ツールは複数クラウドサービス対応しているが、いらない
Titus Network Driver - ネットワーク設定を行い、Pod Root Container に保存。後から起動したタスク用コンテナが Root Container から設定を取ってくる（？）
Metadata Proxy - コンテナが自分の hostname や ip や IAM Role 用クレデンシャルを取得するしくみ
上記を統合して使う。コンテナの Security Group に合わせてホスト側ののネットワークルーティング先を切り替える
Netflixのインフラと統合している - Spinnaker CI/CD, モニタリングのAtlas , 変更管理のEdda, Discovery/IPC, Healthcheck ChaosMonkey
Spinnaker を使うと VMもContainerも同じようにデプロイできる。利用したいスケーリングストラテジ、IAM Role、……を画面から選択して設定する
Fenzo は Titus のコア部分。Mesosベースのスケジューラ。時間制約厳しいジョブとそうでないジョブを区別してスケジューリングできる
Titus のデプロイ - 新しい Auto Scaling Group ができて、古いほうのコンテナを徐々に減らす
Titus は昔は ECS を使っていたが、ECS経由ではリアルタイムに状態把握ができなかった。今は Mesos から EC2 や Container を起動・終了している
AWS の ECS チームとコラボレーションしている
今後の予定：自動スケーリング、SLA管理、外部／内部スポットマーケット、などなど

このセッションは内容濃かったのですが、不慣れな領域なのでちょっと置いて行かれ気味でした。。

CON309 - Running Microservices on Amazon ECS

公式 | YouTube

ECSの入門と InstaCart社の導入事例の紹介です。

モノリシック→SOA→マイクロサービスと変化してきた。SOAとの違いは粒度
UI を Order, User, Shopping に分け、Service も Order, User, Shoppping に分ける粒度
デプロイ、開発のイテレーシヨンが並列で動き、早くなる
マイクロサービスの特徴 - 分散できる, 多言語, 一つのことをうまくやる, 独立性, ブラックボックス, 開発者がデプロイ
マイクロサービスの課題: リソース管理、サービスのディスカバリ、モニタリング、デプロイ…… ECSなら全部できるよ！
ECS は EC2 のクラスタ上に構築されている。各インスタンス用のAMIを作れる。スケジューラがついている。
シンプルな構成例： Route53 から ELBやAPI Gateway につなぐ。APi Gateway からALBにつなぐ。ELBとALBの背後にECSクラスタがいる
稼働コンテナ数の上限・下限を設定することでスケーリング方針を調整できる
タスクとサービス : 実行時間が長いものがタスク。短いものがサービス。
InstaCart の事例 : お店から配達するサービス。「顧客の1分を減らす」ことにフォーカス
- EC2は遅く、デプロイ単位がアトミックでないので使わなかった
- Jenkins で全体10%から徐々に100%までデプロイ。5xx と遅延を見るべき
- RabbitMQ を経由することでサービスディスカバリを実現した

その後

夕方は展示ブースを回りました。やはりセキュリティ系、モニタリング系の製品が目立ちます。次いで BI 関連でしょうか。Ask The Experts というコーナーで AWS ソリューションアーキテクトの方にいろいろ質問できるのもよいですね。

その後、日本からの参加者向けに Lambda 担当や Cognito 担当のエンジニアの方と話す機会があり、Lamda の C# のサポートは半年かかったとか、Lambda で Scala 使えるぜとか - Writing AWS Lambda Functions in Scala - いろいろ聞くことができました。ただ、会場のパブが爆音なため、お互い怒鳴りながらの会話になり、大変でした;;

最終日の夜は re:Play というパーティです。このために体育館二つくらいの大きさの会場を作ったという超巨大パーティーで、ゲームコーナーやらボルダリングやらでめちゃ混みでした。Tシャツをもらう列に後ろに並んでいた二人の話を聞くと、ニューヨークからカップルで来た！といってました。re:Invent にカップルで来るのか……

帰路は現地朝4:30に集合、成田着は日本時間で16:00ごろ。のべ19時間、とにかく長かったです。。

印象まとめ

最近気に入っている表現に、「実体験のビットレート」という表現があります。テキスト(数百bps)より動画(数メガbps)、動画より実体験。実体験はいうなればギガbpsを超えるレベルの情報量があります。今回も、動画を見るのと参加するのとで圧倒的に受ける刺激の量が違う、記憶に残る濃さが違う、ということが実感できました。

参加した印象は：

re:Invent はオープンソースのカンファレンスに近い雰囲気。技術色が濃く、企業のイベントによくあるようなマーケティング色は薄い。技術者が楽しめるイベント。
日本で感じていたよりもAWSの利用・進化の勢いがすさまじい。事業として大成功しており、サービス全体の規模、機能の成長スピードも早まっている
新機能系の発表内容や技術的な深堀りは、やはり日本よりもずいぶん進んでいる印象がある
一方、事例紹介については、（Netflixを除いて）やるべきことを普通にやったという印象のものが多く、日本でやっている事例も全く負けていない。純粋に英語が壁であり、日本ももっと発表できるのでは
利用企業や事例を多く見れば、移行の心理的ハードルは低くはなる。「AWSを使うべきかどうか」ではなく「AWSをどう使うか」という方に視点が移る
エムスリーのようなユーザーの立場では、膨大な最新機能を一つ一つキャッチアップしていく必要はない。落ち着いて枯れたサービスをうまく利用していきたい

オンプレがかなりを占めるエムスリーでの今後の取り組みとしては、「既存サービスをAWSに移行」するのではなく、「新規にクラウドに沿ったアーキテクチャで作り直す」、というのがマッチするように思います。単なるEC2移行だけではなく、マネージドサービスをうまく組み合わせて、インフラ部分に手間をかけずにサービス開発に集中できるような利用を進めていきたいですね。

いつかエムスリーも re:Invent で事例発表したいと思います。

P.S. Deep Dive 系セッションはまだまだ見たいものいろいろありますね！ YouTube での Deep Dive 系セッション一覧