2016.8.25 JAWS-UG千葉團でお話した資料です。

1. 今なぜサーバーレスなのか？
シングルページからAPIまで
サーバーレス概論や海外事例
2016.8.25
株式会社セクションナイン
@yoshidashingo

2. 吉田真吾
n バックグラウンド
証券システム基盤開発
p 基盤開発、Oracleチューニングなど
エバンジェリスト
p 講演年間113回(2013年実績)
p AWS設計・構築・移行(2014-2015)
n 現在のしごと
(株)セクションナイン 社長
p AWSコンサルティング
Mobingi, K.K. VP of Eng
p サービスデベロップメント
n 実績等
p AWSウルトラクイズ
初代チャンピオン (2012年)
p AWS Samurai 2014
p AWSエキスパート養成読本 執筆
p AWS認定全資格(5種類)保持
p Oracle Database 11g認定 (OCP,
Performance Tuning)保持

3. サーバーレスとは

4. サーバーレスの起源
• Why The Future Of Software And Apps Is
Serverless
• 初出 2012/10/15
• コンピューティングリソースの調達リードタイムが
秒単位になっている
• クラウドで柔軟にコンピューティングリソースを
サービスとして利用することができる
• 将来的に開発者はサーバーについて「さほど考えな
くてもよくなる」
http://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/

5. サーバーレスの起源
http://www.serverworks.co.jp/wp-content/uploads/CloudDaysTokyo_2014spring.pdf
2008年

6. サーバーレスの起源
クラウドコンピューティング
活用の「トレンド」

7. サーバーレスの起源

8. サーバーレスの起源
「再定義」が必要そうだ

9. サーバーレスとは？
• 2014 AWS Lamda
• 従来のOSレベルのコンピューティングリソースの
調達・管理から、アプリケーション実行基盤の提供、
かつその実行単位の課金にまで微細化
→ Function as a Service
• 2015 Amazon API Gateway
• LambdaをBackend For Frontendとして使うために
Web API化するためのインタフェースサービスとし
て利用できる

10. サーバーレスとは？
1. リッチクライアント
アプリケーション
• BaaSの活用
2. イベントドリブンな
コード実行環境
• FaaSの活用
http://martinfowler.com/articles/serverless.html
2つのトレンド

11. 1. リッチクライアントアプリケーション
• サーバーサイドのロジックや状態を管理するサー
ドパーティのクラウド上のアプリやサービスを利
用する
• シングルページアプリケーションや
モバイルアプリ
• サービス
• BaaS, mBaaS, 2-Tier Architecture …
• クラウドなデータベース：ParseやFirebase,DynamoDB
• 認証サービス：Auth0やCognito
• APIとして提供、ひとつを上手くやる
マイクロサービスの組合せ
http://martinfowler.com/articles/serverless.html

12. 2. イベントドリブンアプリケーション
• サーバーサイドのロジックを、ステートレスな
クラウドのコンテナでできた実行環境に載せて
イベントドリブンに稼働させるアプリケーショ
ン
• Function as a Service：AWS Lambda, Azure
Functions, Google Cloud Functions, IBM
Bluemix OpenWhisk
• Auth0は認証アプリだけでなく、Webtaskとい
うサーバーレスコンピューティング環境も提供
http://martinfowler.com/articles/serverless.html

13. 組合せ例
1. UIドリブンアプリケーション
2. メッセージドリブンアプリケーション
http://martinfowler.com/articles/serverless.html

14. UIドリブンアプリケーション
• Backend For Frontendでサーバー
レス活用
1. 認証ロジックをBaaSで置換え
2. DynamoDBにクライアントから直
接アクセスするように
3. 大半のロジックをクライアントの
シングルページアプリケーション
に(UXに気をつける)してサーバー
側はAPI Gatewayで束ねる
4. 検索機能をFaaS上に
5. セキュリティの考慮で課金は別DB
に別FaaSでアクセスするように
http://martinfowler.com/articles/serverless.html

15. メッセージドリブンアプリケーション
• オンライン広告システム
• 素早い配信(と同時に)
アクティビティ記録
• 非同期にサーバーに送信してい
た部分をスケーラビリティを気
にしなくていいFaaSに送信
• その他、アップロードコンテン
ツのサムネイル作成など
http://martinfowler.com/articles/serverless.html

16. Serverless Manifesto
1. ファンクションはデプロイ単位/拡張可能単位で管理する
2. 機器や仮想サーバーやコンテナがプログラミングモデルか
ら見えてはいけない
3. データを永続化するストレージは他の場所に確保する
4. リクエスト単位にスケールが管理される。ユーザーはキャ
パシティの調達不足も超過もしない
5. アイドル時間に課金されてはいけない（待機サーバー/コ
ンテナや課金）
6. ファンクションはどこでも実行できるので、暗黙的に耐障
害性を持つ
7. Bring your own code. コードだけ持ち込めばいい
8. メトリクス収集やログ取得は絶対的正義である

17. AWS Lambda
YES
• 独立したファンクション
• RESTful APIか
イベントドリブン
• BYOC(コードを持ち込むだけ)
• 複雑なアルゴリズムで管理
• 水平スケール
• 同期/非同期/スケジューリング
NO
• サーバー上で稼働
• モノリシックなtarボールになっ
ている
• モノリシックなデプロイ方法
• 重量級フレームワーク
• 分散配布されたシステムコード
• 単調作業（ログ取得など）が必要
• サーバーレスアプリケーションかどうか

18. PaaSとの違い
• 非常に似ている
• Serverless Manifesto & 12-Factor Apps
• PaaSの実装→幅広い
• 開発プロセスとサーバープラットフォームを統合して提
供するプラットフォームが主流（S3をPaaSと呼んでい
るのは聞いたことない）
• Heroku, Engine Yard, Deis, Mocloud.io …
• 違い：Scalability
• HerokuやEngine Yardに比べてScalabilityを考慮する場
合にリソースの単位が「多くのPaaSの場合サーバーや
コンテナなどの台数」「FaaSの場合、Functionの実行
回数x消費リソース(CPU/メモリX時間)」

19. コンテナとの違い
• アプリのポータビリティのためステートレスに
扱うというベストプラクティスは同じ
• コンテナはOSレベルから上の管理（Docker
Image）、Serverlessはアプリから上の管理
（FaaS、API）
• FaaSはコンテナ技術をベースに利用すること
が多いが、マネージドするレイヤーが高い

20. Functional SaaS = Serverless too.
• GitHub Pages や S3 でのSPAのホスティングも
現在は「サーバーレス」の中に含む

22. サーバーレスは三位一体
• プラットフォーム
• フレームワーク
• アプリケーション開発者

23. プラットフォーム
• 課金単位の微細化（アプリケーション実行単
位）やスケーラビリティ（シームレス→無限）
を実装できるプラットフォーム
→ 規模の経済が如実に働く
• FaaS サービス
• AWS Lambda @ Amazon Web Services
• BlueMix OpenWhisk @ IBM
• Azure Functions @ Microsoft
• Google Cloud Functions @ Google

24. プラットフォーム
• サーバーレスがなぜ上手くいくか
• 規模の経済性
• 使う人が多くなれば多くなるほどコスト集約され、リソース
のムラがなくなる
• Isolation Level
• コード＆ライブラリをコンテナライズして配布
• プロビジョニングのリードタイム
• リカバリのリードタイム
• サービス形態
• コンテナを含むインフラレイヤを隠蔽し、Function as a
Service化されている

25. 参考資料
http://martinfowler.com/articles/serverless.html http://www.slideshare.net/acloudguru/ant-
stanley-being-serverless

26. Ecosystem (フレームワーク)
• コードの再利用性
• リポジトリで共有
• CI/CDも：ビルド→レグレッショ
ンテスト→デプロイ
• APIやDBも含めた統合開発・管
理

27. Python Serverless
Microframework for
AWS(Preview)
FlourishはないけどChalice(聖杯)は出た

28. Serverless Framework
• Node.js
• 豊富なサブコマンド
• ステージの概念
• プロファイルやリー
ジョンの切替
• リソースやエンドポ
イントの削除など
Python Serverless
Microframework for AWS
• Python
• シンプル！
• chalice new-project
してapp.py書いて
deploy!
• 今後に期待

29. サーバーレスの3つのポイント
• アプリケーション開発速度の向上
• Serverless というか ServiceFull !!
• NoOps?

30. 10X Product Development
• 製品がマーケットにフィットす
るかどうかが最も重要である
• ビジネスに関連するコードの開
発時間に極力時間を使うべきで
ある
• 顧客とまわすイテレーションを
最大化すべきである
• 依存性を最小化すべきである：
仕様確定待ちで開発者を待たせ
たり、運用やDBAやその他の開
発者の影響で待たせることを極
力避けるべきである
http://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development

31. 10X Product Development
• Commercial Search
• 2人の開発者で4ヶ月で作った
• 13,307行のTypeScript
• 開発者の稼働は95%以上だった(なにかに依存した待
ち時間はほとんどなかった)
• コンセプトはMicroservicesだが、自分たちはコアし
か書いていない
• 構成
• Auth: Firebase
• Static Site Hosting: Netlify
• 画像管理: Cloudinary
• 検索: Algolia
• ペインポイント
• Firebaseのダッシュボードでは大きなデータセット
が扱えない（APIであればOK）
• RDBMSからFirebaseに移行する開発者のラーニング
カーブは人それぞれ、非常識ってほどではないけど
http://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development

32. http://www.slideshare.net/acloudguru/ant-stanley-being-serverless

33. Netlify

34. Static Website Hosting
• Hugoをインストールして…
• ドメインを取得して…
• S3のバケットを取得してバケットポリシーなどを
設定して…
• CloudFrontのディストリビューションを設定して
…
• Route 53を設定して…
• ACMでSSL証明書を発行して…
• CircleCIをGitHubリポジトリとひもづけて…

35. Static Website Hosting
$ git add .
$ git commit –m “Change something”
$ git push –u origin master

36. Static Website Hosting
dependencies:
override:
- sudo pip install awscli
post:
- aws configure set region ap-northeast-1
deployment:
production:
branch: master
commands:
- aws s3 sync hugo/public s3://tokyo.serverlessconf.io/ --delete

37. Netlify

38. Netlify

39. Netlify
$ git add .
$ git commit –m “Change something”
$ git push –u origin master
→

40. サーバーレスの3つのポイント
• アプリケーション開発速度の向上
• Serverless というか ServiceFull !!
• NoOps?

41. From serverless to Service Full
• サーバーレスな構成のために積極的に
SaaSを使うことが増えた
• ITサポートサービス：DataDog, GitHub,
CircleCIなど
• オフィスサービス：Gppgle Apps, Slack,
Dropbox, Google Calendar, Skype,
Trello, Google Hangoutなど
• コミュニティサービス：npm, ubuntu,
coreos, NTP, Docker Registryなど
• フロントエンドサービス：jQuery,
Google font api, AngularJS, Google
Analytics
• モバイルサービス：AWS Device Farm,
Amazon Mobile Analytics, SNS, Cognito,
App Annie, AppStore, Google Play
Store, fabric, New Relic, ComScore
https://www.slideshare.net/jedi4ever/from-serverless-to-service-full-how-the-role-of-devops-is-evolving

42. From serverless to Service Full
• サービスの可用性に依存しているので、GitHubが落
ちたらシゴトができない、みたいなことがよく起きる
• 文書化されてない変更が入ったりする（CircleCIの
例）
• ELBは事前暖機が必要で、忘れて急にトラフィック受
けると何もできずにエラーが大量に返ってしまう
• サーバーレス、というかサービスフルな状態で
【SaaSがダウンしてサービスが継続できないリスク
が上昇している】

43. From Serverless to Service Full
• Lambdaのサービスの内部仕様
• Lambdaのコンテナの再利用ルールは非決定
• スケールは常に無限というわけではない
• DevOpsを採用して、リモートAPIを駆使する
• RSSでAWSの障害を監視
• Google Scanningを用いたGoogle Appsのデータのバックアップ
• Slackを用いてステータス変更を素早くフィードバックできるようにする
• (ポストモーテムなどを読んで)何に依存しているか明らかにする
• カンファレンスでサービスへの希望を共有する
• 他の人に経験をフィードバックする
• 自分を頼りにしてくれる人たちにも知ったことを教えてあげる
• 同僚のエンジニアたちにおそれずに情報交換すべきであるということを示す
• 要望されていることに対する責任を持つ
• DevとOpsのコラボレーションはいまや外部のサードパーティベンダーにまで広がって
いることを認識する

44. NoOps?
サーバーレスな世界で我々はインフラについていっさい
運用の必要性がなくなるのか？

45. Serverlessness, NoOps and the Tooth Fairy
• 来たるサーバーレスな未来では、アプリ
ケーション開発者がもっと運用品質に対
する責任を担うことになる
• インフラは外部にホストしてるから運用の
ことは考えたくないと言っても、アプリが
落ちているかもしれない状況においてはど
んな変更があったか、サービス側の問題か、
切り分ける必要性がある
• 運用とはなにか？
• 運用は自分の組織の技術スキルや練習、デ
ザイン周りの文化づくり、システムの構築
やメンテナンス、ソフトウェアのデリバ
リー、技術的な問題の解決
"In the glorious Future, we will be Serverless,
and there will be NoOps. - thought leaders"
http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy

46. Serverlessness, NoOps and the Tooth Fairy
• 運用とはなにか？
• 運用は自分の組織の技術スキルや練習、デ
ザイン周りの文化づくり、システムの構築
やメンテナンス、ソフトウェアのデリバ
リー、技術的な問題の解決
• 運用エンジニアのコアコンピテンシー
• スケーラビリティ
• レジリエンシー
• 可用性
• メンテナンス性
• 複雑なシステムを簡素化するモニタリング
の実装と可視性
• グレイスフル デグラデーション：ソフト
ウェアのアップグレードなど
http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy

47. Serverlessness, NoOps and the Tooth Fairy
• サーバーレス運用工学のベス
トプラクティス
• あなたのプロダクトの問題はあ
なた以上にちゃんと直せる人は
いない
• クリティカルパスを理解する
• できるかぎり小さく維持する
• SaaSプロバイダの技術情報と、
何にどう依存しているか理解す
る
• アウトソース先に問題が起きても、
自身のサービスにおけるそれによ
る結果については依然としてあな
たが責任を持たなければいけない
http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy

48. Serverlessness, NoOps and the Tooth Fairy
• トレードオフ
• 可視性が下がる
• 自分自身で問題をfixできない
し、新機能を実装することも
できない
• サービスはあなたの支払うお
金で維持されている
• 制限や制約は公開されること
もあるし、公開されないこと
もある
http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy

49. Serverlessconf Tokyo
the future will be
Serverless Community (JP)
https://www.facebook.com/groups/813718382095265/