Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見 / Serverless at Geeks Who Drink

by Ken’ichiro Oyama

Slide 1

Slide 1 text

Serverless Frameworkで AWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知⾒ Kenʼichiro Oyama Fusic Co.,Ltd. 2017.7.21 1 Geeks Who Drink

Slide 2

Slide 2 text

Who 2 Geeks Who Drink

Slide 3

Slide 3 text

k1LoW   Kenʼichiro Oyama   @k1LoW   Fusic Co.,Ltd. エンジニア   基盤ユニットテックリード   GitHub organizations   fukuokarb / faultline / emacs-jp / etc.   awspecというAWS⽤のテストツールを作っています   https://github.com/k1LoW/awspec 3 Geeks Who Drink

Slide 4

Slide 4 text

スミマセン。 AWSを知っている前提でお話します。 4 Geeks Who Drink

Slide 5

Slide 5 text

5 Geeks Who Drink

Slide 6

Slide 6 text

Serverless Framework   サーバレスアーキテクチャでアプリケーションを構築するためのフレームワーク   FaaS (Function as a Service。AWSだとAWS Lambda) を中⼼においた開発をサポートするツール   AWSだけでなく他のクラウドベンダが提供しているFaaS にも対応 (Azure Functionsなど)   Node製   だからといってランタイムがNodeに限定されているわけではない   Serverless,Inc.が主導して開発しているオープンソース 6 Geeks Who Drink

Slide 7

Slide 7 text

Serverless Frameworkとは結局何か   デプロイツール（+オーケストレーションツール）   プログラマブルCFn   いろいろ便利な機能があるし、名前からも「フルスタックな何か」に⾒えなくもないが、意外に薄い   途中で利⽤をやめることも可能   デプロイツールなので   全く難しくないです   個⼈的にはフロントエンドエンジニアに武器にして欲しい 7 Geeks Who Drink

Slide 8

Slide 8 text

AWSマネージド   AWSには⾃分で運⽤管理しないといけないサービスと AWSが運⽤管理をある程度肩代わりしてくれるサービスがある   本セッションでは、AWSが運⽤管理をしてくれるサービスの特徴を「AWSマネージド」と呼ぶ   AWS Managed Servicesというサービスのことではない   AWSマネージドなサービスのみで(AWSフルマネージドで)ツールを作ると運⽤管理の負荷が劇的に下がる   「サーバ（というよりもサーバ運⽤管理）」の部分が「レス」になる 8 Geeks Who Drink

Slide 9

Slide 9 text

実際にServerless Frameworkでどのようなツールが作れるのか 9 Geeks Who Drink

Slide 10

Slide 10 text

backslack 10 Geeks Who Drink

Slide 11

Slide 11 text

backslack   Backlogの操作をSlackに通知するツール   https://github.com/k1LoW/backslack 11 Geeks Who Drink

Slide 12

Slide 12 text

backslack アーキテクチャ 12 Geeks Who Drink

Slide 13

Slide 13 text

faultline 13 Geeks Who Drink

Slide 14

Slide 14 text

faultline   エラートラッキングツール   同様のSaaSだとAirbrake, Bugsnag, Rollbarなど   https://github.com/faultline/faultline 14 Geeks Who Drink

Slide 15

Slide 15 text

faultline アーキテクチャ 15 Geeks Who Drink

Slide 16

Slide 16 text

utsusemi 16 Geeks Who Drink

Slide 17

Slide 17 text

utsusemi   APIで“動的な更新”が可能な“静的サイト”⽣成ツール   https://github.com/k1LoW/utsusemi 17 Geeks Who Drink

Slide 18

Slide 18 text

utsusemi アーキテクチャ 18 Geeks Who Drink

Slide 19

Slide 19 text

hubedit 19 Geeks Who Drink

Slide 20

Slide 20 text

hubedit   https://hubedit.com   GitHubのプライベートリポジトリをメモツールにするサービス   GitHubを使っているので正確にはAWSフルマネージドではない 20 Geeks Who Drink

Slide 21

Slide 21 text

hubedit アーキテクチャ 21 Geeks Who Drink

Slide 22

Slide 22 text

他にもちょこちょこ作っています 22 Geeks Who Drink

Slide 23

Slide 23 text

Serverless Frameworkチョットデキル   Serverless FrameworkでAWSフルマネージドなツールをいくつか作ってきた   プロダクションベースの事例はよく聞くが、OSSなツールはまだ (⽇本では)少ないはず   https://github.com/toricls/pingbot など   Serverless Frameworkベースというと結構作った⽅では？   まだ作りたいものはあるのでボチボチ作っていく   普段のWebアプリケーションと実装の考え⽅が違うので知恵熱がでる 23 Geeks Who Drink

Slide 24

Slide 24 text

AWSマネージドなサーバレスアーキテクチャで使えるかもしれない知⾒ 24 Geeks Who Drink

Slide 25

Slide 25 text

前提   「サーバレスデザインパターン」みたいな仰々しいものではなくて、あくまで実装時に得たTips的なもの   ただ、いろいろ試⾏錯誤をして頭をひねって思いついたものばかりです   本当にスミマセン。AWSを知っている前提でお話します。 25 Geeks Who Drink

Slide 26

Slide 26 text

設定値をリクエストに付与する ”POST with conﬁg” 26 Geeks Who Drink

Slide 27

Slide 27 text

POST with conﬁg   backslack, faultline   設定値をツール側で保存するだけで管理対象が増えてしまうので、できるだけ値を保持しないのが鉄則   APIベースのツールなのであれば、リクエストに必要な設定を毎回付与してしまえばいいというアイデア   SlackのWebhook URL, チャンネル名など   秘匿が必要な設置値でさえもKMSを利⽤して暗号化してリクエストに付与する 27 Geeks Who Drink

Slide 28

Slide 28 text

backslack アーキテクチャ（再掲） 28 Geeks Who Drink

Slide 29

Slide 29 text

新しい順の⼀覧を実現する “Reversed Timestamp ID” 29 Geeks Who Drink

Slide 30

Slide 30 text

Reversed Timestamp ID (1/2)   faultline   実は⼀覧を作るのは難しい   RDSはサーバレスアーキテクチャではアンチパターン   DynamoDBで「テーブルの全てのデータの⼀覧」を作るのはアンチパターン   今のところS3を使うのを解にしている   Preﬁxの使い⽅が設計のカギ   /projects/{project}/errors/{message}/occurrences/ {reversedUnixtime}.json 30 Geeks Who Drink

Slide 31

Slide 31 text

Reversed Timestamp ID (2/2)   S3のオブジェクトはアルファベット順でソートされている。`ORDER BY created DESC` を実現するにはどうすればいいか   UNIX Timestampを逆カウントにして、ゼロパディングすることで実現   (Math.pow(2, 53) - 1) – unixtime   Number.MAX_SAFE_INTEGER - unixtime   IDから⽣成時刻もわかって便利（snowﬂakeみたい） 31 Geeks Who Drink

Slide 32

Slide 32 text

無限にファンアウトしかねない AWS Lambdaをいい感じに制限実⾏する ”Instant Job Queue” 32 Geeks Who Drink

Slide 33

Slide 33 text

Instant Job Queue (1/2)   utsusemi   AWS Lambdaのfunctionをinvokeしてページをクロールして、そのリンク先をまた同じfunctionをinvokeしてクロールして...   DoSになりかねないファンアウト   Queueを作ってWorkerプロセスを常時起動して待ち受ける形だとWorkerプロセスの管理が増える   AWS Step FunctionsがAWSの解だけど費⽤が増える 33 Geeks Who Drink

Slide 34

Slide 34 text

Instant Job Queue (2/2)   Queue (SQS)を作ってクロール開始時にWorkerを起動して、Workerは指定回数デキューしてクロールしたら値をエンキューして同じWorkerをinvokeして⾃分⾃⾝を終了   キューにたまっているメッセージが0になったらWorkerは⾃分⾃⾝を終了（最終的にWorkerは0）   クロールのような常にキューに値がはいるパターンに使える   同時に動かすWorker数や、Workerが処理するメッセージの数などが調整できる   FIFOキューにしたら実⾏順番も保証される（かも） 34 Geeks Who Drink

Slide 35

Slide 35 text

utsusemi アーキテクチャ（再掲） 35 Geeks Who Drink

Slide 36

Slide 36 text

意外に使われない機能を使ってメタ情報を保存する ”S3 Object Tagging” 36 Geeks Who Drink

Slide 37

Slide 37 text

S3 Object Tagging (1/2)   utsusemi   クロールして取得したHTMLファイルはS3バケットに保存   じゃあそのファイルの更新⽇時は？Content-Typeは？ ETagは？   ファイルシステムならあとでギリ取得できそうなファイルタイプすらS3では難しい   ヘッダ情報などの活⽤できそうな値は保持しなくていいのか   他に保存する場所を作ってしまったら管理対象が増える。。。 37 Geeks Who Drink

Slide 38

Slide 38 text

S3 Object Tagging (1/2)   S3 Object Taggingを使う   オブジェクトごとにKey-Valueの値を保持できる   “S3 Object Tagging” はS3の機能の名前   ユーザ情報（オブジェクト）とその住所情報（タグ）とか、Issue（オブジェクト）とラベル（タグ）など、⽤途は広い気がする 38 Geeks Who Drink

Slide 39

Slide 39 text

まとめ   結局、サーバレスアーキテクチャでうまく設計するためには「各サービスの機能を知っておいたほうがいい」ということ   サーバレスアーキテクチャは、雑に⾔えば「マネージドなサービスをフル活⽤して管理レスにしようぜ」アーキテクチャ   制約を受け⼊れてうまくステートレスな設計ができれば「スケール」「管理レス」という点でかなりインパクト⼤   サーバレスアーキテクチャで作ったツールはシンプルなSaaSのような感じ（faultline）   Serverless Frameworkはサーバレスアーキテクチャ専⽤ツールとして優秀なので是⾮   ⽇本語フォーラムもはじまっている！ https://github.com/serverless-japan/forum 39 Geeks Who Drink

Slide 40

Slide 40 text

40 Fusicはテクノロジーが好きなエンジニアを募集しています > https://fusic.github.io Thank you!