Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to 今なぜサーバーレスなのか
Similar to 今なぜサーバーレスなのか (20)
More from 真吾 吉田
More from 真吾 吉田 (20)
Recently uploaded
Recently uploaded (10)
今なぜサーバーレスなのか
- 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/
- 7. サーバーレスの起源
- 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
- 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化されている
- 26. Ecosystem (フレームワーク) • コードの再利用性 • リポジトリで共有 • CI/CDも：ビルド→レグレッショ ンテスト→デプロイ • APIやDBも含めた統合開発・管 理
- 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
- 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のコラボレーションはいまや外部のサードパーティベンダーにまで広がって いることを認識する
- 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/