今年は会社のマックを持って行けたので、hands-onも快適でメモがかなり楽だった。
講演：茂木 健一郎など（10:00〜12:00）
・遊んでいる脳が一番クリエイティブ
HERE: Making sense of the world through the lens of location. （12:20〜13:00）
・海外の自動車関連企業説明。殆ど自社宣伝
Amazon EC2を使ってみよう（Linux）（13:20〜14:00）
・移動中、偶然ブースを見かけて予定変更しました
・EC2を構築するHands On。1時間中awsの無料サービスが使える
・ネット見ながら自前でやるよりは安心感があった
[ワイヤ・アンド・ワイヤレス] AWS Lambda を使ったモバイルバックエンドのサーバレス開発事例（15:20～16:00）
・lambdaでJAVAを実行する際にライブラリークラスが多くなると起動に時間が掛かる（10~30sec）→ 定期的に起動して解消
・API Gatewayとlambdaは同期処理になる（処理が終わるまで他の処理ができなくなる）ので、lambdaの後ろにもう一つのlambdaを立てて、非同期処理を実現した
・lambda単位（function単位）でログが出力されるので、ログ管理には工夫が必要
・SAM(serverless Apllication Model)フレームワークを使用してAPI Gatewayとlambdaを一緒にデフロイしている
・C#, java, node.js, pythonでlambda検証してみた
- メモリ：384MB タイムアウト：30秒
- duration：JAVA/C#は初回起動に時間が掛かる、継続して動作すると早い→といってもプレゼンの資料を見た感じpythonかnode.jsの方が早そう。
- メモリ：JAVAはメモリ使用量が多め
・lambdaのテストはモックを用意してやった
・lambdaエミュレータ（github）あるらしい
[ワークスアプリケーションズ] AWS Lambda で変わるバッチの世界 ~ CPU 時間トータル 100 時間の処理を 10 分で終わらせるには~（15:20〜14:00）
・Springのバッチ処理でHTMLを生成する処理
・従来ではsparkでトータル２時間掛かっていた。改修後の目標は処理時間 10分
・lambdaよりはspringに関わった処理を切り離して高速化
・処理をJAVAのコンストラクタに書くとlambdaの課金対象外になる。ただしTimeoutが短い（課金対象になる）
・lambdaのCPU性能はメモリに比例、コスト増は保々なし
[Sansan] AWS が支える Eight のリコメンデーションエンジンの裏側（16:20～17:00）
・リコメンド計算エンジン、という個人データを元に関連性を作る処理。毎日１回バッチで実行
・従来：redshift使用 → 無駄に複雑なクエリ、コスト増
・開発期間２ヶ月
・改善方法
- lambda：メモリを増やす
- dynamo DB：batch writeでまとめて処理
- lambdaが増えすぎて管理コストが掛かる→一つにまとめて処理を分岐させる
・レーティングデータの陳腐化があった
- dynamo dbはalter tableがないので、data pipelineを利用しdynamo dbを作り直す
・data pipeline+step functions利用し、フロー化
・lambdaは5分タイムアウトされてしまうので、完了してないとエラー扱いにしてリトライさせた
感想
・エンタプライズ環境ならともかく、サーバーレスでjavaはダメな気がする。これも時代の流れかも。
・当たり前かも知れないが、JAWSに比べると商業的な感じがする。開発者としてこのような雰囲気はあまり好きではない。
