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 料金がバカにならないので要注意です。

こういうのが必要。

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

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

詳細なレポートはクラスメソッドさんの記事をどうぞ。
【レポート】AWS Summit Tokyo 2017:[JapanTaxi] Athena 指向アナリティクス 〜真面目に手を抜き価値を得よ〜 #AWSSummit | Developers.IO

追記(2017-07-01):
ついに Athena が東京リージョンに来ました。 Data Transfer 料金の心配は少なくなりました。

【ライブ コーディングも実施】Amazon Pay の仕組みと実装方法


資料ダウンロード

結構良かった。

  • バックエンドは API Gateway + Lambda + DynamoDB で構築
  • ELB + EC2 + DynamoDB は考えることが多いので不採用
  • 最後にフロントエンド側のライブコーディング。まあ簡単ね

Amazon ECS の進化、DevOps と Microservices の実践

  • まだ ECS 使ったことない人向けのセッション
  • Microservices は実装よりの導入事例。デプロイは ecs-deploy 簡単で便利とのこと。