AWS Summit Tokyo 2017 に行ってきた #AWSSummit

AWS Summit Tokyo 2017

Day2 だけですが、今年も AWS Summit Tokyo に行ってきました。
[2014-07-19-1] から始まり、[2015-06-07-1] [2016-06-04-1] と、
今年で 4 回目の参加になります。

今回は過去最高の規模なのか、品川プリンスホテルの会場も増えてました。
グランドプリンスホテルからの移動時間は 10 分ほど。人によっては移動
が大変だったみたいです。暑かったですし。

私は聞きたいのがほとんど AWS Dev Day のセッションだったので、午後
は全部品川プリンスホテルに引き篭もっていました。

全てのセッションの動画や資料はこちらをどうぞ。
AWS Summit Tokyo 2017 開催レポート - 基調講演・特別講演動画・資料一覧｜AWS

Day2 基調講演（キーノート）

オープニングが例年のDJ田中氏から、三味線からのエレキギター＆バイオ
リンとのセッションに変わりました。DJ田中氏は Day3,4 ？

目立っていたのは先日ニュースにもなった、三菱東京UFJ銀行の事例。つ
いに日本の銀行も AWS 上で動き始めました。とは言え、これから上り調
子か！と思わせてからのスピーカーの村林氏の今週末退任という流れには、
さすがに会場がザワッとしていましたw

去年との違いは Machine Learning 推しかなあ。

全体的に例年よりも RDS, Lambda など具体的な用語が多いキーノートだっ
た気がします。そうできる状況になってきたのでしょう。

あとは Amazon Lightsail 東京リージョンの発表や、大阪ローカルリージョ
ンの来年開設など軽めの発表でした。

詳細なレポートはクラスメソッドさんの記事をどうぞ。
【レポート】AWS Summit Tokyo 2017：Day2 基調講演(キーノート) #AWSSummit ｜ Developers.IO

ナビタイムサービスにおける、Amazon ECS を活用したシステム移行　～『乗換NAVITIME』での移行事例～

資料ダウンロード

3 月に ECS にズビっと移行したお話。CPU 負荷をトリガーに自動でスケー
ルアウトする。スケールインはこれからみたい。

〜マイクロサービスを設計する全ての開発者に送る〜クラウド時代のマイクロサービス設計徹底解説！

資料ダウンロード

ご本人も始めに言った通り、だいぶ駆け足でした。

サービス観点で分割。利用者の観点で
疎結合化を受け入れる（運用でカバー） → Amazon ですら不整合発生 → 300円クーポン
最近は URL ではなくて、HTTP ヘッダで API のバージョニングをするらしい。そうなの？
マイクロサービスにおける可用性 → 障害が発生しないようにするではない → 復元力を高める
何人かは障害に遭遇している。「全体としてだいたい動く」

マイクロサービスでの設計のキモは、非同期による不整合を受け入れるこ
とだそうです。あの Amazon でさえもそれを受け入れ、技術ではなく 300
円クーポンという「運用でカバー」をしていることを強調していました。

[2017-03-12-1] の JAWS DAYS 2017 では運用でカバーが出来ないという
話があったけど、真相は如何に…。

モノリシックサービスだと「1 リクエストも 5xx を出さないように頑
張る」と思いますが、マイクロサービスにおいては「スケールを手に入れる
代わりに、全体としてだいたい動くように頑張る」らしいです。

まだ実装も運用もしたことがないので、なるほどという感想しかありません…。

チーム体制として「コンウェイの法則」を挙げていたのが印象的でした。
インフラチームが横断的に複数の開発チームと関わるのではなく、開発チー
ムで上から下まで面倒を見るアレです。

詳細なレポートはクラスメソッドさんの記事をどうぞ。
【レポート】AWS Summit Tokyo 2017：〜マイクロサービスを設計する全ての開発者に送る〜クラウド時代のマイクロサービス設計徹底解説！ #AWSSummit ｜ Developers.IO

スピーカーの鈴木氏ご本人の記事で補足ありました。
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017 - arclamp

[ABEJA] IoT / Bigdata / AI 時代におけるスケーラブルな Deep Learning 実行基盤と応用

ABEJA という Deep Learning のスタートアップのお話。

カメラのデータを解析
chalice よいとのこと。Serverless Framework + Application?
ECS 使ってる
GPU インスタンスで起動すれば、Docker から GPU を扱うことも可能
GPU はコア数が多く並列計算が得意。ディープラーニングは GPU が得意な行列演算が多い
IoT Device → API Gateway → Kinesis → Lambda → S3
Annotation(Person) → ALB → ECS → S3

Python 推し。Lambda が 3.6 に対応して喜んでいた。
https://rebuild.fm/ で聴いたような環境を使っていた。どのセッション
も ECS 出てきている。

[JapanTaxi] Athena 指向アナリティクス〜真面目に手を抜き価値を得よ〜

資料ダウンロード

外注だったアプリを内製にリニューアル。主に Beanstalk で構築。
fluentd で S3 に保存。わりと普通。

セッションでは触れられていなかったけど、S3 → Athena がリージョンを
跨ぐと、Data Transfer 料金がバカにならないので要注意です。

まだ Athena はまだ Tokyo Region に来ていない。S3 バケットが Tokyo で、絞り込まずにクエリを投げたりすると、冷や汗が出る程度には転送量がかかる https://t.co/5t3nLSvr36 #AWSSummit
— マスタカ (@masutaka) May 31, 2017

こういうのが必要。

“パーティションを作ってちゃんとスキャンされる範囲を制限してクエリを実行すればそれなりに安全ということで、本家からも推奨されてます。” / “AWS AthenaでPartitionを作る - Qiita” https://t.co/Rj051mGI1H
— マスタカ (@masutaka) February 5, 2017

下手したらこのようになります。私も会社で 3 万円ほど溶かしました。
この方は 170 万円…。

私の 2〜3 万なんてカスみたいだ...。Billing Alert とか設定したほうが良いですよ。私の場合は Mackerel に AWS Billing 送ってたので次の日に気づいた / “ぼくがAthenaで死ぬまで” https://t.co/3AaPkUkmkF
— マスタカ (@masutaka) April 3, 2017

そういう理由もあってまだ本気で使ってないけど、ログフォーマットは
LTSV でもいけるみたいです。