JAWS-UGアーキテクチャ専門支部 ServerlessConfレポート

JAWS-UGアーキテクチャ専門支部 ServerlessConfレポート

1. 1. SERVERLESSCONF ’16 NYC レポート 2016.7.14 株式会社セクションナイン @yoshidashingo
2. 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. 3. インフラのパラダイムシフト • その昔 • 土地：所有 • ハードウェア：所有 • キッティング：自分 • ミドルウェア設定：自分 • データセンターアウトソーシング • 土地：借りる • ハードウェア：所有 • キッティング：自分 • ミドルウェア設定：自分 • ハイパーバイザー仮想化 • 土地：借りる • ハードウェア：所有 • キッティング：イメージの展開 • ミドルウェア設定：イメージ /Configuration Management • クラウドコンピューティング • セルフサービス • ペットから家畜へ • Infrastructure as Code: ソフト ウェアのベストプラクティスをイ ンフラにも適用 • サーバーレスコンピューティング • コンテナ技術活用によるFaaSの現 実感 • マイクロサービス
4. 4. その他のパラダイムシフト アプリケーション • クラサバからWebへ • Enterprise Architecture による全体最適化 • SOAによるWebサービス 連携 • OSSの活用 • アジャイル開発 • ITのコンシューマライ ゼーション オペレーション • ITサービスマネジメント • ITSMSの導入 • ITSSv3 • Site Reliability Engineering • ソフトウェア・エンジニアリン グでITサービスマネジメントを 実現する • 自動化、連鎖障害の極小化(クラ スタレベルでの管理)、改善速度 の向上、エラーバジェットによ る管理 • DevOpsワークフロー
5. 5. Process→Experience 厳格なプロセスによるマネジメント ↓ 組織文化内での役割による必然性 （Workstyle Experience）による マネジメント
6. 6. サーバーレスとは レポートの前に…
7. 7. 参考資料 http://martinfowler.com/articles/serverless.html http://www.slideshare.net/acloudguru/ant- stanley-being-serverless
8. 8. サーバーレスとは 1. リッチクライアント アプリケーション • BaaSの活用 2. イベントドリブンな コード実行環境 • FaaSの活用 http://martinfowler.com/articles/serverless.html 2つのトレンドが混ざっていて「サーバーレス」の 定義は明確に定まっていない
9. 9. 1. リッチクライアントアプリケーション • サーバーサイドのロジックや状態を管理するサー ドパーティのクラウド上のアプリやサービスを利 用する • シングルページアプリケーションや モバイルアプリ • サービス • BaaS, mBaaS, 2-Tier Architecture … • クラウドなデータベース：ParseやFirebase,DynamoDB • 認証サービス：Auth0やCognito • APIとして提供、ひとつを上手くやる マイクロサービスの組合せ http://martinfowler.com/articles/serverless.html
10. 10. 2. イベントドリブンアプリケーション • サーバーサイドのロジックを、ステートレスな クラウドのコンテナでできた実行環境に載せて イベントドリブンに稼働させるアプリケーショ ン • Function as a Service：AWS Lambda, Azure Functions, Google Cloud Functions, IBM Bluemix OpenWhisk • Auth0は認証アプリだけでなく、Webtaskとい うサーバーレスコンピューティング環境も提供 http://martinfowler.com/articles/serverless.html
11. 11. 組合せ例 1. UIドリブンアプリケーション 2. メッセージドリブンアプリケーション http://martinfowler.com/articles/serverless.html
12. 12. UIドリブンアプリケーション • モノリスからマイクロサービスへ の移行でサーバーレス活用 1. 認証ロジックをBaaSで置換え 2. DynamoDBにクライアントから直 接アクセスするように 3. 大半のロジックをクライアントの シングルページアプリケーション に(UXに気をつける)してサーバー 側はAPI Gatewayで束ねる 4. 検索機能をFaaS上に 5. セキュリティの考慮で課金は別DB に別FaaSでアクセスするように http://martinfowler.com/articles/serverless.html
13. 13. メッセージドリブンアプリケーション • オンライン広告システム • 素早い配信(と同時に) アクティビティ記録 • 非同期にサーバーに送信してい た部分をスケーラビリティを気 にしなくていいFaaSに送信 http://martinfowler.com/articles/serverless.html
14. 14. http://www.slideshare.net/acloudguru/ant-stanley-being-serverless
15. 15. ServerlessConf レポート • 5/25(水)26(木)27(金) AWS Pop-up Loft, Villain @ New York • Serverless Computing/Architecture/Apps のベンダーニュートラルな技術カンファレンス • API Gateway • S3 • Elastic Transcoder • Auth0 • Firebase • DynamoDB をもちいたサーバーレスな Youtubeクローン作成 Day 1 Day 2ワークショップ • ベンダー各社 • ツール開発者 • ベンダー各社 • ユーザ事例 ü King of PaaS? ü Flourish ü NoOps?
16. 16. Category 1. Serverless Computing (Platform) 2. Ecosystem (Framework) 3. Usecase of developers
17. 17. Serverless Computing • サーバーレスがなぜ上手くいくか • 規模の経済性 • 使う人が多くなれば多くなるほどコスト集約され、リソース のムラがなくなる • Isolation Level • コード＆ライブラリをコンテナライズして配布 • プロビジョニングのリードタイム • リカバリのリードタイム • サービス形態 • コンテナを含むインフラレイヤを隠蔽し、Function as a Service化されている
18. 18. AWS Lambda • サーバーレス・マニフェスト 1. ファンクションはデプロイ単位/拡張可能単位で管理する 2. 機器や仮想サーバーやコンテナがプログラミングモデルから 見えてはいけない 3. データを永続化するストレージは他の場所に確保する 4. リクエスト単位にスケールが管理される。ユーザーはキャパ シティの調達不足も超過もしない 5. アイドル時間に課金されてはいけない（待機サーバー/コンテ ナや課金） 6. ファンクションはどこでも実行できるので、暗黙的に耐障害 性を持つ 7. Bring your own code. コードだけ持ち込めばいい 8. メトリクス収集やログ取得は絶対的正義である
19. 19. AWS Lambda YES • 独立したファンクション • RESTful APIか イベントドリブン • BYOC(コードを持ち込むだけ) • 複雑なアルゴリズムで管理 • 水平スケール • 同期/非同期/スケジューリング NO • サーバー上で稼働 • モノリシックなtarボールになっ ている • モノリシックなデプロイ方法 • 重量級フレームワーク • 分散配布されたシステムコード • 単調作業（ログ取得など）が必要 • サーバーレスアプリケーションかどうか
20. 20. Ecosystem (フレームワーク) • コードの再利用性 • リポジトリで共有 • CI/CDも：ビルド→レグレッショ ンテスト→デプロイ • APIやDBも含めた統合開発・管 理
21. 21. Flourish • 実行アプリケーションモデリング • Microserviceのフォーマット定義 • IDEプロジェクトとのマッピング • ビルドをおこなったり、ZIPによるデプロイ • 共有コンテナ上での実行 • 1箇所のダッシュボード上での監視 • 利用料金の集約 • モノリス(一枚岩)を避けるために使う • Lambdaファンクションは独立したアップデート機能を備えて いる • Flourishのバージョンコレクション • コードと設定の組合せによる一貫性のあるロールバック機能 • モノリシックなデプロイ方法は不要
22. 22. Flourish AWSがLambdaを産み エコシステムとサービスマネジメントが支える Serverless
23. 23. Python Serverless Microframework for AWS(Preview) FlourishはないけどChalice(聖杯)は出た
24. 24. Serverless Framework • Node.js • 豊富なサブコマンド • ステージの概念 • プロファイルやリー ジョンの切替 • リソースやエンドポ イントの削除など Python Serverless Microframework for AWS • Python • シンプル！ • chalice new-project してapp.py書いて deploy! • 今後に期待
25. 25. http://www.slideshare.net/acloudguru/ant-stanley-being-serverless
26. 26. より開発が簡単にできるサービス vs ファイングレインな設定ができる ビルディングブロックなサービス
27. 27. 10X Product Development • 製品がマーケットにフィットす るかどうかが最も重要である • ビジネスに関連するコードの開 発時間に極力時間を使うべきで ある • 顧客とまわすイテレーションを 最大化すべきである • 依存性を最小化すべきである： 仕様確定待ちで開発者を待たせ たり、運用やDBAやその他の開 発者の影響で待たせることを極 力避けるべきである http://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development
28. 28. 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
29. 29. 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
30. 30. From serverless to Service Full • サービスの可用性に依存しているので、GitHubが落 ちたらシゴトができない、みたいなことがよく起きる • 文書化されてない変更が入ったりする（CircleCIの 例） • ELBは事前暖機が必要で、忘れて急にトラフィック受 けると何もできずにエラーが大量に返ってしまう • サーバーレス、というかサービスフルな状態で 【SaaSがダウンしてサービスが継続できないリスク が上昇している】
31. 31. From serverless to Service Full • Lambdaのサービスの内部仕様 • Lambdaのコンテナの再利用ルールは非決定 • スケールは常に無限というわけではない • DevOpsを採用して、リモートAPIを駆使する • RSSでAWSの障害を監視 • Google Scanningを用いたGoogle Appsのデータのバックアップ • Slackを用いてステータス変更を素早くフィードバックできるようにする • (ポストモーテムなどを読んで)何に依存しているか明らかにする • カンファレンスでサービスへの希望を共有する • 他の人に経験をフィードバックする • 自分を頼りにしてくれる人たちにも知ったことを教えてあげる • 同僚のエンジニアたちにおそれずに情報交換すべきであるということを示す • 要望されていることに対する責任を持つ • DevとOpsのコラボレーションはいまや外部のサードパーティベンダーにまで広がって いることを認識する
32. 32. 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
33. 33. Serverlessness, NoOps and the Tooth Fairy • 運用とはなにか？ • 運用は自分の組織の技術スキルや練習、デ ザイン周りの文化づくり、システムの構築 やメンテナンス、ソフトウェアのデリバ リー、技術的な問題の解決 • 運用エンジニアのコアコンピテンシー • スケーラビリティ • レジリエンシー • 可用性 • メンテナンス性 • 複雑なシステムを簡素化するモニタリング の実装と可視性 • グレイスフル デグラデーション：ソフト ウェアのアップグレードなど http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy
34. 34. Serverlessness, NoOps and the Tooth Fairy • サーバーレス運用工学のベス トプラクティス • あなたのプロダクトの問題はあ なた以上にちゃんと直せる人は いない • クリティカルパスを理解する • できるかぎり小さく維持する • SaaSプロバイダの技術情報と、 何にどう依存しているか理解す る • アウトソース先に問題が起きても、 自身のサービスにおけるそれによ る結果については依然としてあな たが責任を持たなければいけない http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy
35. 35. Serverlessness, NoOps and the Tooth Fairy • トレードオフ • 可視性が下がる • 自分自身で問題をfixできない し、新機能を実装することも できない • サービスはあなたの支払うお 金で維持されている • 制限や制約は公開されること もあるし、公開されないこと もある http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy
36. 36. より開発が簡単にできるサービス vs ファイングレインな設定ができる ビルディングブロックなサービス ↓ 開発のアジリティとResponsibilityのバランス
37. 37. 日本でも…
38. 38. リクルートジョブズ • タウンワークにおけるサー バーレスアーキテクチャデ ザイン • CTL(データサイエンティス ト集団)が機械学習ロジッ クに集中できる環境 • ログ基盤を整備し、カスタ マーの回遊や検索における リアルタイムな特徴量の更 新や、バッチ処理による予 測モデルの作成に利用 https://techblog.recruitjobs.net/events/aws-summit-tokyo-2016-townwork-serverless-architecture-design
39. 39. リクルートジョブズ • Lambdaがなかったら こ の規模のシステムをごく 短期間でリリースする事 は 不可能だったと言える https://techblog.recruitjobs.net/events/aws-summit-tokyo-2016-townwork-serverless-architecture-design
40. 40. やっていく気持ち サーバーレスでビジネスを牽引する先駆者になる
41. 41. Serverlessconf Tokyo the future will be Serverless Community (JP) https://www.facebook.com/groups/813718382095265/