Serverlessconf Tokyo 2018にいってきた

Serverlessconf Tokyo 2018に行ってきました。
感想メモ。

基調講演

ビジネスロジックに集中したいからServerless
数人チームでシステムを開発運用をやっているとインフラ側に気を割きたくないという気持ちがある。
私はスケーラビリティというよりは、サーバの面倒を見たくないという方を重視してる。
OSとかミドルウェアのアップデートとか細々とタスクが出て、時間とられるのよね。
Webやゲームだけではなく、ギョーミング分野にも使われ始めている。
うん、実際、社内システムで使うとすごく楽。

The design for serverless ETL pipeline 〜データ分析基盤のレガシーなデータロードを、サーバレスでフルリプレースするまでの道のり〜

パイプライン実行、障害のリカバリがつらい。
後続のスケジュールまでにリカバリできるかとかの判断がほんとめんどい。
手動実行だとそもそも、職人的になりがち。
運用者にしかスケジュールの関連がわかってなかったりする。
運用を0にする。
定例の運用作業を圧縮したいという気持ちを強くしました。
欲を言えば0にしたい…
今の職場だと、どうしても人が手入力するデータを取り込んだりするので、0にはできないなぁ。
並列実行時の考慮
lambdaの平行度はいくつでもだけれども出力先のコネクションの関係で無限とはいかないパターンがある。
たしかに、自分がやるときに考慮漏れそう…
DynamoDBでステータス管理
DynamoDBにステータスを格納することで二重発火しないようになる。
ステータスがここで集約されるので、後続が実行してよいかをここで制御する。
ちょうどいま、後続制御について考えていたのでこれはすぐ取り入れたい。
実行完了時間がわかる。
マネジメントコンソールに入っていつ完了したか見に行くのがめんどいので、よさそう。
ログが見にくい話
DataDogに集約、重要なものはSalck。
Slack通知はやっているがDataDogは使ってないなぁ。
よく話は聞くので使ってみたい。
教訓運用も含めてリプレースの対象であることという共通認識を作る。
運用も変えるというのは重要で、『現状は局所的な最適だけどリプレース後は全体的な最適にするんだよ。』
みたいなことをしていくことが大事だと思う。
スコープの肥大化
要望の明文化、やるやらないの判断を最初にする。
新しいシステムがすべてをかなえてくれるわけではない。
やるやらないを最初に判断するのはやろうと思ってできてないのでうまいことやっていきたい。

サーバーレスシステムの複雑化に立ち向かう - IoTを例にみるAWSとDDDを駆使したアプリケーション設計

DDD要素は薄めでした。
がっつりエンプラ用途じゃなければ、私も業務ロジックはちゃんと一か所にまとめて分けようねというぐらいにするという方針は同意。

サーバレスで作るときはまずは機能ごとにラムダに分解して、それをいかにしてつなげるかみたいな作り方をする。
そんなに複雑な機能ものを作ったことがないけど、ラムダ関数が増えるとコード上、処理のトレースが難しくなりそう。
ディレクトリ構成まで突っ込んで話したり、具体的にどのサービスを使って何を達成すべきかを具体的に書いていたりでかなり実践的な内容でした。