Download to read offline
Uploaded byTerui Masashi
Reliability Engineering for Enterprise Serverless
The document discusses reliability engineering in the context of serverless architectures, emphasizing that serverless computing allows developers to build applications without server management. It outlines common challenges and considerations regarding the reliability of Functions-as-a-Service (FaaS) and Backend-as-a-Service (BaaS), and promotes a methodology for creating reliable serverless applications. The speaker highlights the importance of simplicity in design and implementation while leveraging serverless mechanisms to enhance reliability.
More Related Content
![[AWSKRUG 아키텍처 모임] 세일즈부스트 인프라스트럭처 사례 공유](https://cdn.slidesharecdn.com/ss_thumbnails/awskrug20180227-180228005405-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DO16] Mesosphere : Microservices meet Fast Data on Azure](https://cdn.slidesharecdn.com/ss_thumbnails/do16-170616021542-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Reliability Engineering for Enterprise Serverless
![[Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://cdn.slidesharecdn.com/ss_thumbnails/auroradeep-150322203758-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
Reliability Engineering for Enterprise Serverless
- 1. RELIABILITY ENGINEERING FOR ENTERPRISESERVERLESS MASASHI TERUI @ JAWS DAYS 2018
- 2. SERVERWORKS CO.,LTD. + FREELANCER •Serverless Oji-san • Serverless Framework Plugin Developer • Serverlessconf Tokyo 2016/2017 speaker • Remote worker (in Sapporo) • The best Cloud Engineer in Hokkaido!! (でありたい） MASASHI TERUI ARCHITECT / DEVELOPER
- 3. AGENDA SERVERLESS ってなんだっけ？ 1 6 2 7 38 4 9 5 10 SERVERLESS の信頼性とは？ SERVERLESS のよくある課題 SERVERLESS を実体を捉える RELIABILITY 考え方 RELIABILITY 設計編 RELIABILITY 実装編 RELIABILITY 監視編 SUMMARY 世界を広げる SERVERLESS は特別じゃない
- 4.
- 5. CNCF SERVERLESS WHITEPAPERV1.0 • Serverless computing refers to the concept of building and running applications that do not require server management • A platform may provide one or both of the following: • Functions-as-a-Service (FaaS) • Backend-as-a-Service (BaaS) • Products or platforms deliver the following benefits to developers: • Zero Server Ops • No Compute Cost When Idle https://github.com/cncf/wg-serverless/tree/master/whitepaper
- 6. SERVERLESS IS NOTGLUE IN ENTERPRISE APPLICATION ”THE ORCHESTRATOR MANAGES THE TRADES USING A GRAPH OF STATES”
- 7. SERVERLESS CLOUD NATIVELANDSCAPE
- 8. BUT I PREFERTHIS ONE https://www.slideshare.net/acloudguru/ant-stanley-being-serverless
- 9. SERVERLESS USE CASES(FROM CNCF WP) • Asynchronous, concurrent, easy to parallelize into independent units of work • Infrequent or has sporadic demand, with large, unpredictable variance in scaling requirements • Stateless, ephemeral, without a major need for instantaneous cold start time • Highly dynamic in terms of changing business requirements that drive a need for accelerated developer velocity • Non-HTTP-centric and non-elastic scale workloads that weren’t good fits for an IaaS, PaaS, or CaaS solution (Event Driven workloads)
- 10. “There are manyworkloads that are stateful and/or not easy to parallelize” と思ってませんか？ “Asynchronous and Event Driven processing is too difficult for humans”
- 11.
- 12. RELIABILITY(RASIS) 細分化すると色々ある • Reliability • Availability •Serviceability • Integrity • Security ここでは以下のように定義 「Reliability = 広義の信頼性(RASIS)」 Reliability Availability Serviceability Integrity Security Reliability
- 13. IS SERVERLESS DIFFICULTTO GUARANTEE THE RELIABILITY? • Strongly depends on FaaS platform and BaaS products • Lose the business continuity (Reliability, Availability) • Distributed Instances • Lose the traceability (Serviceability) • Hard to develop • All become functions (Serviceability) • NoSQL matches better than RDB (Integrity)
- 14.
- 15. FaaSのよくある課題 • How totest the functions? • Granularity of the functions • Messaging between the functions and backends • Handling request and response (Error Handling) • Log Aggregation, Traceability • Monitoring
- 16. BaaSのよくある課題 • How tochoose the services? • Fault Tolerance • Monitoring
- 17.
- 18.
- 19.
- 20. THE INTERNAL FLOWOF PROCESSINGhttps://github.com/apache/incubator-openwhisk/blob/master/docs/about.md#the-internal-flow-of-processing イベント(HTTP)が処理される流れを掴む ストリームやキューを挟んで分散処理するのが基本 外から見て同期でも中は非同期かつ分散
- 21. THE FUNCTIONS THAT INVOKEDASYNCHRONOUS IN THE CONTAINERS FaaS is… コンテナ内で非同期に呼び出される関数
- 22.
- 23. FROM OWNERSHIP TO USESERVICES クラウドによってサーバが所有から利用へ さらにミドルウェアやライブラリも利用へ BaaSを使うのはそういう自然な流れ
- 24. FULLY MANAGED ANDABSTRACTED MIDDLEWARES AND LIBRARIES BaaS is… フルマネージドかつ抽象化されたMWやライブラリ
- 25.
- 26. CONSTITUTED OF THEABSTRACTED FUNCTIONS AND MIDDLEWARES Serverless is… 抽象化されてるだけで関数とMWでできてる
- 27. WE CAN MAKERELIABLE SERVERLESS APPLICATION SO… 信頼性は作れる！
- 28.
- 29. RELIABILITYの考え方 • Make thereliability by myself • Serverless will help you, but will not protect your business • Think simple • Apply generally development/operation practices • If you can't apply the practices, take care of the serverless mechanism • Keep simple • Don't be afraid that increase the number of the functions • We should be afraid complicated architecture • Change your mind as a software • Everything is part of your application
- 30.
- 31. ALL EVENTS FLOWSIN THE SAME DIRECTION イベント(データ)は同じ方向に流す 結果が必要なら同期で返さず 取りに行かせる 🙅 🙆
- 32. ALL EVENTS FLOWSIN THE SAME DIRECTION • They will be naturally Asynchronous and Functional • Asynchronous processing is Retriable • Functional processing is Reproducible • The clients get the results by myself • However, polling is not good choise... • Pushing is better choice • Can we be happy with AppSync? (Pushing via Websocket)
- 33. UNIFY THE ENDPOINTS BETWEENTHE SERVICES サービス間のエンドポイントは集約する ラップして集約しコントロールを得る
- 34. UNIFY THE ENDPOINTSBETWEEN THE SERVICES • Microservices • Separate the services by the domains (One BaaS is one of your service) • The endpoint of the service is not unique, it has the endpoints for each operations • Wrap the endpoints to abstract them • Like a “MySQL Server” and “libmysql” • Do you call “libmysql” directly? • You can make Failover/Failsafe mechanism • Like a Reverse Proxy • Do you connect to multiple “Read replicas” from “each app servers”? • Trafic controlling, Caching
- 35. ALL SERIES OFEVENTS HAVE THE SAME ID 一連の処理には同じIDを付与 それを引き回すことでIDでトレースできる このIDは様々な制御にも使える
- 36. ALL SERIES OFEVENTS HAVE THE SAME ID • Log Aggregation • A series of events can be traced by the ID • Monitor the progress • Log all event messages • Execution control • At least once -> Exactly once • e.g. DynamoDB Conditional Writes • Make it easy to implement with something like a decorator
- 37. DATA MODELING • Becomethe friend with DynamoDB • Distributed by Partition Key and Indexed(B-tree) by Sort Key, LSI • GSI is a projection of sorted(indexed) data • The consistency can be guaranteed without ACID transaction • Denormalization • Strong consistency reading, Conditional Writing • There are some difficult situation • Write asynchronous to RDB
- 38.
- 39. GRANULARITY OF THE FUNCTIONS •Testable!! •Unit testing is justice in the serverless world • Make the dependencies of other services are replaceable • Would be replaceable to the mocks • Easy to Failover/Failsafe
- 40. HOW TO TESTTHE FUNCTIONS • Unit testing is justice in the serverless world (2回目) • Deploy a new environment if the mocks are not enough at integration testing • It is easy with some frameworks (e.g. Serverless, SAM) • The services outside of AWS are needed to be easily to deploy (via API) • Continuous E2E testing with traceable ID • It become a monitoring
- 41.
- 42. RELIABILITY MONITORING • Thegreatest monitoring is the notifications from the application • Be sure to catch the errors and notify them • Collect the metrics of the services • CloudWatch • This is a condition to choice the services outside of AWS • Continuous E2E testing with traceable ID
- 43.
- 44. “SERVERLESS IS NOTSPECIAL” THANKS!! “MAKE THE RELIABILITY BY MYSELF” “THINK SIMPLE, KEEP SIMPLE” “EVERYTHING IS PART OF YOUR APPLICATION” “LET'S EXPAND SERVERLESS WORLD”
- 45.