AWS Lambda-ს დეტალური ანალიზი

სტატიის თარგმანი მომზადდა სპეციალურად კურსის სტუდენტებისთვის "ღრუბლოვანი სერვისები". გაინტერესებთ ამ მიმართულებით განვითარება? უყურეთ ეგორ ზუევის მასტერკლასს (TeamLead InBit-ზე) "AWS EC2 სერვისი" და შეუერთდით შემდეგ საკურსო ჯგუფს: იწყება 26 სექტემბერს.

მეტი ადამიანი მიგრირებს AWS Lambda-ზე მასშტაბურობის, შესრულების, დაზოგვისა და თვეში მილიონობით ან თუნდაც ტრილიონობით მოთხოვნის დამუშავების შესაძლებლობისთვის. ამისათვის თქვენ არ გჭირდებათ ინფრასტრუქტურის მართვა, რომელზეც სერვისი მუშაობს. და autoscaling გაძლევთ საშუალებას მოემსახუროთ ათასობით ერთდროულ მოთხოვნას წამში. ვფიქრობ, AWS Lambda სამართლიანად შეიძლება ეწოდოს ერთ-ერთ ყველაზე პოპულარულ AWS სერვისს.

AWS ლამბდა

AWS Lambda არის მოვლენებზე ორიენტირებული სერვერის გარეშე გამოთვლითი სერვისი, რომელიც საშუალებას გაძლევთ გაუშვათ კოდი სერვერების უზრუნველყოფის ან მართვის გარეშე და გააფართოვოთ სხვა AWS სერვისები მორგებული ლოგიკის გამოყენებით. Lambda ავტომატურად პასუხობს სხვადასხვა მოვლენებს (ე.წ. ტრიგერები), როგორიცაა HTTP მოთხოვნები Amazon API Gateway-ის მეშვეობით, მონაცემების ცვლილებები Amazon S3 თაიგულებში ან Amazon DynamoDB ცხრილებში; ან შეგიძლიათ გაუშვათ თქვენი კოდი API ზარების მეშვეობით AWS SDK-ის და მდგომარეობის გადასვლების გამოყენებით AWS Step Functions-ში.

Lambda აწარმოებს კოდს მაღალ ხელმისაწვდომ გამოთვლით ინფრასტრუქტურაზე და სრულად არის პასუხისმგებელი ძირითადი პლატფორმის ადმინისტრირებაზე, მათ შორის სერვერისა და ოპერაციული სისტემის მოვლაზე, რესურსების უზრუნველყოფაზე, ავტომატურ მასშტაბირებაზე, კოდის მონიტორინგზე და ლოგინგზე. ანუ, თქვენ უბრალოდ უნდა ატვირთოთ თქვენი კოდი და დააკონფიგურიროთ როგორ და როდის უნდა შესრულდეს. თავის მხრივ, სერვისი იზრუნებს მის გაშვებაზე და უზრუნველყოფს თქვენი აპლიკაციის მაღალ ხელმისაწვდომობას.

როდის გადავიდეთ ლამბდაზე?

AWS Lambda არის მოსახერხებელი გამოთვლითი პლატფორმა, რომელიც შესაფერისია სხვადასხვა გამოყენების შემთხვევებისთვის, თუ თქვენი კოდის ენა და გაშვების დრო მხარდაჭერილია სერვისის მიერ. თუ გსურთ ფოკუსირება მოახდინოთ თქვენს კოდზე და ბიზნეს ლოგიკაზე, სერვერის შენარჩუნების, უზრუნველყოფისა და სკალირების აუთსორსინგის დროს გონივრულ ფასად, AWS Lambda ნამდვილად გამოსავალია.

Lambda იდეალურია პროგრამირების ინტერფეისების შესაქმნელად და API Gateway-თან ერთად გამოყენებისას შეგიძლიათ მნიშვნელოვნად შეამციროთ ხარჯები და უფრო სწრაფად მოხვდეთ ბაზარზე. არსებობს ლამბდას ფუნქციების და პარამეტრების გამოყენების სხვადასხვა გზა სერვერის გარეშე არქიტექტურის ორგანიზებისთვის - ყველას შეუძლია აირჩიოს რაიმე შესაფერისი თავისი მიზნიდან გამომდინარე.

Lambda გაძლევთ საშუალებას შეასრულოთ დავალებების ფართო სპექტრი. ამრიგად, CloudWatch-ის მხარდაჭერის წყალობით, შეგიძლიათ შექმნათ გადადებული ამოცანები და ავტომატიზირდეთ ინდივიდუალური პროცესები. არ არსებობს შეზღუდვები სერვისის გამოყენების ბუნებასა და ინტენსივობაზე (მხედველობაში მიიღება მეხსიერების მოხმარება და დრო) და არაფერი გიშლით ხელს სისტემატიურად იმუშაოთ ლამბდაზე დაფუძნებულ სრულფასოვან მიკროსერვისზე.

აქ შეგიძლიათ შექმნათ სერვისზე ორიენტირებული მოქმედებები, რომლებიც მუდმივად არ მუშაობს. ტიპიური მაგალითია გამოსახულების მასშტაბირება. განაწილებული სისტემების შემთხვევაშიც კი, ლამბდას ფუნქციები რჩება აქტუალური.

ასე რომ, თუ არ გსურთ გაუმკლავდეთ გამოთვლითი რესურსების განაწილებას და მართვას, სცადეთ AWS Lambda; თუ არ გჭირდებათ მძიმე, რესურსზე ინტენსიური გამოთვლები, ასევე სცადეთ AWS Lambda; თუ თქვენი კოდი პერიოდულად მუშაობს, ასეა, უნდა სცადოთ AWS Lambda.

უსაფრთხოების

ჯერჯერობით არ არის პრეტენზია უსაფრთხოებასთან დაკავშირებით. მეორეს მხრივ, ვინაიდან ამ მოდელის მრავალი შიდა პროცესი და განხორციელების მახასიათებელი დაფარულია AWS Lambda-ს მართული გაშვების გარემოს მომხმარებლისგან, ღრუბლოვანი უსაფრთხოების ზოგიერთი ზოგადად მიღებული წესი შეუსაბამო ხდება.

AWS სერვისების უმეტესობის მსგავსად, Lambda უზრუნველყოფილია უსაფრთხოებისა და შესაბამისობის საერთო საფუძველზე AWS-სა და მომხმარებელს შორის. ეს პრინციპი ამცირებს კლიენტის ოპერაციულ დატვირთვას, ვინაიდან AWS იღებს დავალებებს სერვისის კომპონენტების შენარჩუნების, ადმინისტრირებისა და მონიტორინგის შესახებ - მასპინძელი ოპერაციული სისტემიდან და ვირტუალიზაციის ფენიდან ინფრასტრუქტურის აქტივების ფიზიკურ უსაფრთხოებამდე.

კონკრეტულად AWS Lambda-ზე საუბრისას, AWS პასუხისმგებელია ძირითადი ინფრასტრუქტურის, ასოცირებული ძირითადი სერვისების, ოპერაციული სისტემის და აპლიკაციის პლატფორმის მართვაზე. მიუხედავად იმისა, რომ კლიენტი პასუხისმგებელია მისი კოდის უსაფრთხოებაზე, კონფიდენციალური მონაცემების შენახვაზე, მასზე წვდომის კონტროლზე, ასევე Lambda სერვისსა და რესურსებზე (Identity and Access Management, IAM), მათ შორის გამოყენებული ფუნქციების ფარგლებში.

ქვემოთ მოცემული დიაგრამა გვიჩვენებს საერთო პასუხისმგებლობის მოდელს, როგორც ეს ეხება AWS Lambda-ს. AWS პასუხისმგებლობა არის ნარინჯისფერი და მომხმარებელთა პასუხისმგებლობა ლურჯი. როგორც ხედავთ, AWS უფრო მეტ პასუხისმგებლობას იღებს სერვისზე განლაგებულ აპლიკაციებზე.

გაზიარებული პასუხისმგებლობის მოდელი, რომელიც გამოიყენება AWS Lambda-სთვის

ლამბდა გაშვების დრო

Lambda-ს მთავარი უპირატესობა ის არის, რომ თქვენი სახელით ფუნქციის შესრულებით სერვისი თავად გამოყოფს საჭირო რესურსებს. თქვენ შეგიძლიათ თავიდან აიცილოთ დროისა და ძალისხმევის დაკარგვა სისტემის ადმინისტრირებაზე და ფოკუსირება მოახდინოთ ბიზნეს ლოგიკასა და კოდირებაზე.

ლამბდა სერვისი დაყოფილია ორ თვითმფრინავად. პირველი არის საკონტროლო თვითმფრინავი. ვიკიპედიის მიხედვით, საკონტროლო თვითმფრინავი არის ქსელის ნაწილი, რომელიც პასუხისმგებელია სასიგნალო ტრაფიკის ტრანსპორტირებაზე და მარშრუტიზაციაზე. ეს არის ძირითადი კომპონენტი, რომელიც იღებს გლობალურ გადაწყვეტილებებს სამუშაო დატვირთვის უზრუნველყოფის, მომსახურებისა და განაწილების შესახებ. გარდა ამისა, საკონტროლო სიბრტყე მოქმედებს როგორც გადაწყვეტის მიმწოდებლის ქსელის ტოპოლოგია, რომელიც პასუხისმგებელია ტრაფიკის მარშრუტიზაციასა და მართვაზე.

მეორე სიბრტყე არის მონაცემთა სიბრტყე. მას, ისევე როგორც საკონტროლო თვითმფრინავს, აქვს თავისი ამოცანები. საკონტროლო სიბრტყე უზრუნველყოფს API-ებს ფუნქციების მართვისთვის (CreateFunction, UpdateFunctionCode) და აკონტროლებს, თუ როგორ დაუკავშირდება Lambda სხვა AWS სერვისებს. მონაცემთა სიბრტყე აკონტროლებს Invoke API-ს, რომელიც ახორციელებს Lambda ფუნქციებს. ფუნქციის გამოძახების შემდეგ, საკონტროლო სიბრტყე გამოყოფს ან ირჩევს არსებულ გაშვების გარემოს, რომელიც წინასწარ არის მომზადებული ამ ფუნქციისთვის და შემდეგ ახორციელებს მასში არსებულ კოდს.

AWS Lambda მხარს უჭერს სხვადასხვა პროგრამირების ენებს, მათ შორის Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 და სხვა, მათი შესაბამისი გაშვების გარემოში. AWS რეგულარულად ანახლებს მათ, ავრცელებს უსაფრთხოების პატჩებს და ახორციელებს სხვა ტექნიკურ აქტივობებს ამ გარემოში. Lambda გაძლევთ საშუალებას გამოიყენოთ სხვა ენებიც, იმ პირობით, რომ თქვენ თავად განახორციელებთ შესაბამის გაშვებას. შემდეგ კი მოგიწევთ იზრუნოთ მის მოვლაზე, უსაფრთხოების მონიტორინგის ჩათვლით.

როგორ მუშაობს ეს ყველაფერი და როგორ შეასრულებს სერვისი თქვენს ფუნქციებს?

თითოეული ფუნქცია მუშაობს ერთ ან რამდენიმე გამოყოფილ გარემოში, რომელიც არსებობს მხოლოდ ამ ფუნქციის სიცოცხლის განმავლობაში და შემდეგ განადგურებულია. თითოეული გარემო ახორციელებს მხოლოდ ერთ ზარს ერთდროულად, მაგრამ ის ხელახლა გამოიყენება, თუ არსებობს რამდენიმე სერიული ზარი იმავე ფუნქციაზე. ყველა გაშვების გარემო მუშაობს ვირტუალურ მანქანებზე ტექნიკის ვირტუალიზაციით - ე.წ. microVMs. თითოეული microVM ენიჭება კონკრეტულ AWS ანგარიშს და მისი ხელახლა გამოყენება შესაძლებელია ამ ანგარიშში სხვადასხვა ფუნქციების შესასრულებლად. MicroVM-ები შეფუთულია Lambda Worker ტექნიკის პლატფორმის სამშენებლო ბლოკებში, რომელსაც ფლობს და მართავს AWS. ერთი და იგივე გაშვების დრო არ შეიძლება გამოყენებულ იქნას სხვადასხვა ფუნქციით და არც microVM-ებია უნიკალური სხვადასხვა AWS ანგარიშებისთვის.

AWS ლამბდას იზოლაციის მოდელი

სამუშაო დროის გარემოს იზოლაცია ხორციელდება რამდენიმე მექანიზმის გამოყენებით. თითოეული გარემოს ზედა დონეზე არის შემდეგი კომპონენტების ცალკეული ასლები:

• ფუნქციის კოდი
• ფუნქციისთვის შერჩეული ნებისმიერი ლამბდა ფენა
• ფუნქციის შესრულების გარემო
• მინიმალური მომხმარებლის სივრცე Amazon Linux-ზე დაფუძნებული

შემდეგი მექანიზმები გამოიყენება შესრულების სხვადასხვა გარემოს იზოლირებისთვის:

• cgroups - ზღუდავს წვდომას CPU-ზე, მეხსიერებაზე, საცავზე და ქსელის რესურსებზე თითოეული გაშვების გარემოსთვის;
• სახელთა სივრცეები - პროცესის ID-ების, მომხმარებლის ID-ების, ქსელის ინტერფეისების და სხვა რესურსების დაჯგუფება Linux-ის ბირთვის მიერ. თითოეული გაშვების დრო გადის საკუთარ სახელთა სივრცეში;
• seccomp-bpf - ზღუდავს სისტემურ ზარებს, რომლებიც შეიძლება გამოყენებულ იქნას გაშვების დროს;
• iptables და მარშრუტიზაციის ცხრილები - შესრულების გარემოს ერთმანეთისგან იზოლაცია;
• chroot - უზრუნველყოფს შეზღუდულ წვდომას ძირითად ფაილურ სისტემაზე.

AWS საკუთრების იზოლაციის ტექნოლოგიებთან ერთად, ეს მექანიზმები უზრუნველყოფენ მუშაობის დროის საიმედო განცალკევებას. ამ გზით იზოლირებულ გარემოს არ შეუძლია წვდომა ან შეცვალოს მონაცემები სხვა გარემოდან.

მიუხედავად იმისა, რომ ერთი და იგივე AWS ანგარიშის მრავალჯერადი გაშვება შეიძლება ერთ microVM-ზე, არავითარ შემთხვევაში არ შეიძლება microVM-ების გაზიარება სხვადასხვა AWS ანგარიშებს შორის. AWS Lambda იყენებს მხოლოდ ორ მექანიზმს microVM-ების იზოლირებისთვის: EC2 ინსტანციები და Firecracker. სტუმრების იზოლაცია ლამბდაში EC2 მაგალითებზე დაფუძნებული 2015 წლიდან არსებობს. Firecracker არის ახალი ღია კოდის ჰიპერვიზორი, რომელიც სპეციალურად შექმნილია AWS-ის მიერ სერვერის გარეშე სამუშაო დატვირთვისთვის და დაინერგა 2018 წელს. ფიზიკური აპარატურა, რომელიც მუშაობს microVM-ებზე, ნაწილდება დატვირთვას შორის სხვადასხვა ანგარიშებზე.

გარემოს და პროცესის მდგომარეობის შენახვა

მიუხედავად იმისა, რომ Lambda გაშვების დრო უნიკალურია სხვადასხვა ფუნქციისთვის, მათ შეუძლიათ ერთი და იგივე ფუნქციის განმეორებით გამოძახება, რაც ნიშნავს, რომ გაშვების დრო შეიძლება გაგრძელდეს რამდენიმე საათის განმავლობაში განადგურებამდე.

თითოეულ Lambda Runtime-ს აქვს ჩასაწერი ფაილური სისტემა, რომელიც ხელმისაწვდომია /tmp დირექტორიაში. მის შინაარსზე წვდომა შეუძლებელია სხვა გაშვების დროებიდან. რაც შეეხება პროცესის მდგომარეობის მდგრადობას, ფაილები ჩაწერილი /tmp არსებობს გაშვების გარემოს მთელი სასიცოცხლო ციკლისთვის. ეს საშუალებას გაძლევთ დაგროვდეს მრავალი ზარის შედეგები, რაც განსაკუთრებით სასარგებლოა ძვირადღირებული ოპერაციებისთვის, როგორიცაა მანქანათმცოდნეობის მოდელების ჩატვირთვა.

ზარის მონაცემთა გადაცემა

Invoke API შეიძლება გამოყენებულ იქნას ორ რეჟიმში: მოვლენის რეჟიმი და მოთხოვნის პასუხის რეჟიმი. მოვლენის რეჟიმში, ზარი ემატება რიგში შემდგომი შესრულებისთვის. მოთხოვნა-პასუხის რეჟიმში ფუნქცია იძახება მომენტალურად მოწოდებული დატვირთვით, რის შემდეგაც პასუხი ბრუნდება. ორივე შემთხვევაში, ფუნქცია მუშაობს Lambda გარემოში, მაგრამ სხვადასხვა დატვირთვის ბილიკებით.

მოთხოვნა-პასუხის ზარების დროს, დატვირთვა მიედინება მოთხოვნის დამუშავების API-დან (API Caller), როგორიცაა AWS API Gateway ან AWS SDK, დატვირთვის ბალანსერში და შემდეგ Lambda Invoke Service-ში. ეს უკანასკნელი განსაზღვრავს შესაფერის გარემოს ფუნქციის შესასრულებლად და გადასცემს დატვირთვას იქ ზარის დასასრულებლად. დატვირთვის ბალანსერი იღებს TLS-ით დაცულ ტრაფიკს ინტერნეტით. ტრაფიკი ლამბდა სერვისში — დატვირთვის ბალანსერის შემდეგ — გადის შიდა VPC-ში კონკრეტულ AWS რეგიონში.

AWS Lambda ზარის დამუშავების მოდელი: მოთხოვნა-პასუხის რეჟიმი

ღონისძიების ზარები შეიძლება განხორციელდეს დაუყოვნებლივ ან დაემატოს რიგში. ზოგიერთ შემთხვევაში, რიგი ხორციელდება Amazon SQS-ის (Amazon Simple Queue Service) გამოყენებით, რომელიც გადასცემს ზარებს ლამბდა ზარის შესრულების სერვისზე შიდა პოლერის პროცესის მეშვეობით. გადაცემული ტრაფიკი დაცულია TLS-ით და არ არის Amazon SQS-ში შენახული მონაცემების დამატებითი დაშიფვრა.

ღონისძიების ზარები არ აბრუნებს პასუხებს - Lambda Worker უბრალოდ უგულებელყოფს პასუხების ნებისმიერ ინფორმაციას. მოვლენებზე დაფუძნებული ზარები Amazon S3-დან, Amazon SNS-დან, CloudWatch-დან და სხვა წყაროებიდან მუშავდება Lambda-ს მიერ მოვლენის რეჟიმში. ზარები Amazon Kinesis და DynamoDB ნაკადებიდან, SQS რიგები, Application Load Balancer და API Gateway ზარები მუშავდება მოთხოვნა-პასუხის რეჟიმში.

მონიტორინგი

შეგიძლიათ ლამბდას ფუნქციების მონიტორინგი და აუდიტი სხვადასხვა AWS მექანიზმებისა და სერვისების გამოყენებით, მათ შორის შემდეგი.

Amazon CloudWatch
აგროვებს სხვადასხვა სტატისტიკას, როგორიცაა მოთხოვნების რაოდენობა, რამდენი დრო დასჭირდა მოთხოვნის შესრულებას და იმ მოთხოვნების რაოდენობას, რომლებიც ვერ მოხერხდა.

Amazon CloudTrail
საშუალებას გაძლევთ შეხვიდეთ სისტემაში, მუდმივად აკონტროლოთ და შეინახოთ ანგარიშის აქტივობის ინფორმაცია, რომელიც დაკავშირებულია თქვენს AWS ინფრასტრუქტურასთან. თქვენ გექნებათ AWS Management Console-ის, AWS SDK-ის, ბრძანების ხაზის ხელსაწყოების და სხვა AWS სერვისების გამოყენებით შესრულებული ქმედებების სრული ისტორია.

AWS რენტგენი
უზრუნველყოფს სრულ ხილვადობას თქვენს აპლიკაციაში მოთხოვნის დამუშავების ყველა ეტაპზე მისი შიდა კომპონენტების რუქის საფუძველზე. საშუალებას გაძლევთ გაანალიზოთ აპლიკაციები განვითარების დროს და წარმოების გარემოში.

AWS კონფიგურაცია
თქვენ შეძლებთ თვალყური ადევნოთ ლამბდას ფუნქციის კონფიგურაციის (მათ შორის წაშლის) ცვლილებებს და გაშვების დროებს, ტეგებს, დამმუშავებლის სახელებს, კოდის ზომას, მეხსიერების განაწილებას, დროის ამოწურვის პარამეტრებს და კონკურენტულობის პარამეტრებს, ასევე Lambda IAM-ის შესრულების როლს, ქვექსელებს და უსაფრთხოების ჯგუფის კავშირებს. .

დასკვნა

AWS Lambda გთავაზობთ ინსტრუმენტების მძლავრ კომპლექტს უსაფრთხო და მასშტაბირებადი აპლიკაციების შესაქმნელად. AWS Lambda-ში უსაფრთხოებისა და შესაბამისობის მრავალი პრაქტიკა იგივეა, რაც სხვა AWS სერვისებში, თუმცა არის გამონაკლისები. 2019 წლის მარტის მდგომარეობით, Lambda შეესაბამება SOC 1, SOC 2, SOC 3, PCI DSS, ჯანმრთელობის დაზღვევის პორტაბელურობისა და ანგარიშვალდებულების აქტის (HIPAA) შესაბამისობას და სხვა რეგულაციებს. ასე რომ, როდესაც ფიქრობთ თქვენი შემდეგი აპლიკაციის განხორციელებაზე, განიხილეთ AWS Lambda სერვისი - ის შეიძლება საუკეთესოდ მოერგოს თქვენს ამოცანას.

წყარო: www.habr.com