1
00:00:00,450 --> 00:00:02,840
‫Okay. So I have my demo-lambda function

2
00:00:02,840 --> 00:00:05,290
‫that I want to invoke asynchronously this time.

3
00:00:05,290 --> 00:00:07,190
‫So if we look at the code again,

4
00:00:07,190 --> 00:00:09,120
‫it will print some values

5
00:00:09,120 --> 00:00:11,570
‫then it will return the event key1.

6
00:00:11,570 --> 00:00:13,240
‫But if we invoke this asynchronously,

7
00:00:13,240 --> 00:00:15,540
‫we cannot do it from the console,

8
00:00:15,540 --> 00:00:16,990
‫we have to do it from the CLA.

9
00:00:16,990 --> 00:00:18,380
‫So let's open CloudShell.

10
00:00:18,380 --> 00:00:21,340
‫And so the whole purpose of an asynchronous invocation

11
00:00:21,340 --> 00:00:24,890
‫is that we do not have the results back to us.

12
00:00:24,890 --> 00:00:27,140
‫So let's copy this entire command right here.

13
00:00:28,120 --> 00:00:30,143
‫So I paste a command and press enter.

14
00:00:32,980 --> 00:00:34,680
‫And my lambda function has now been invoked,

15
00:00:34,680 --> 00:00:37,530
‫and we get a status code 202 as a result.

16
00:00:37,530 --> 00:00:39,230
‫So that means that the lambda function

17
00:00:39,230 --> 00:00:40,790
‫has been successfully invoked

18
00:00:40,790 --> 00:00:42,690
‫but we don't know the results.

19
00:00:42,690 --> 00:00:44,400
‫And so to look at the result what we could do

20
00:00:44,400 --> 00:00:45,920
‫is we look at the CloudWatch logs.

21
00:00:45,920 --> 00:00:49,350
‫So if you go under monitor and look at the CloudWatch logs

22
00:00:49,350 --> 00:00:51,800
‫we can look at the recent invocations.

23
00:00:51,800 --> 00:00:53,640
‫And then if we look at

24
00:00:54,790 --> 00:00:56,913
‫one that will appear very soon hopefully.

25
00:00:59,300 --> 00:01:00,693
‫So let's go into here,

26
00:01:03,120 --> 00:01:04,863
‫and we look at the log groups,

27
00:01:05,770 --> 00:01:06,610
‫and we look at this one,

28
00:01:06,610 --> 00:01:08,200
‫here we go that's my latest invocation.

29
00:01:08,200 --> 00:01:09,970
‫As we can see the function was invoked

30
00:01:09,970 --> 00:01:11,590
‫and the requests was successful.

31
00:01:11,590 --> 00:01:13,070
‫But we don't know this,

32
00:01:13,070 --> 00:01:14,550
‫if it was successful or not,

33
00:01:14,550 --> 00:01:15,383
‫thanks to this command,

34
00:01:15,383 --> 00:01:17,860
‫because this was an asynchronous invocation.

35
00:01:17,860 --> 00:01:19,740
‫And we can do it for sure

36
00:01:19,740 --> 00:01:22,170
‫because if we go into our Lambda function

37
00:01:22,170 --> 00:01:24,500
‫and we're going to change the code to make it fail.

38
00:01:24,500 --> 00:01:26,500
‫So I will comment the return

39
00:01:26,500 --> 00:01:29,220
‫and I will uncomment the raise exception.

40
00:01:29,220 --> 00:01:30,560
‫I'll deploy to save my changes.

41
00:01:30,560 --> 00:01:32,060
‫Now if we test this function,

42
00:01:32,060 --> 00:01:32,900
‫we know it fails.

43
00:01:32,900 --> 00:01:34,920
‫It's just failed right now.

44
00:01:34,920 --> 00:01:38,060
‫But if we use CloudShell again,

45
00:01:38,060 --> 00:01:40,100
‫our CLI to invoke the function,

46
00:01:40,100 --> 00:01:44,210
‫we get again a 202 status code for the error.

47
00:01:44,210 --> 00:01:45,900
‫And I can know for sure that it has failed

48
00:01:45,900 --> 00:01:47,619
‫because if I go into my log stream

49
00:01:47,619 --> 00:01:49,600
‫and open this log stream,

50
00:01:49,600 --> 00:01:51,530
‫we get an error right here.

51
00:01:51,530 --> 00:01:54,460
‫So as we can see invoking the function asynchronously

52
00:01:54,460 --> 00:01:56,170
‫returns the same status code 202

53
00:01:56,170 --> 00:01:57,230
‫regardless of whether or not

54
00:01:57,230 --> 00:01:58,770
‫the function succeeded or failed

55
00:01:58,770 --> 00:02:00,850
‫because we don't want to know the results,

56
00:02:00,850 --> 00:02:03,030
‫due to the nature of asynchronous.

57
00:02:03,030 --> 00:02:04,540
‫So what we can do instead

58
00:02:04,540 --> 00:02:06,563
‫is maybe set up a dead letter queue.

59
00:02:06,563 --> 00:02:09,770
‫So if we go into our lambda function

60
00:02:09,770 --> 00:02:11,360
‫and go to configurations,

61
00:02:11,360 --> 00:02:15,050
‫under asynchronous invocations we have some information

62
00:02:15,050 --> 00:02:16,360
‫and we can edit some configuration

63
00:02:16,360 --> 00:02:18,260
‫around a dead letter queue.

64
00:02:18,260 --> 00:02:21,390
‫So we have 0, 1 or 2 retry attempts

65
00:02:21,390 --> 00:02:23,300
‫on the failure of an asynchronous event.

66
00:02:23,300 --> 00:02:24,970
‫So we'll keep it as 2.

67
00:02:24,970 --> 00:02:28,210
‫And then we can send the unprocessed events

68
00:02:28,210 --> 00:02:29,500
‫from an asynchronous invocation

69
00:02:29,500 --> 00:02:30,860
‫into a dead-letter queue.

70
00:02:30,860 --> 00:02:32,240
‫So we can choose SQS

71
00:02:32,240 --> 00:02:34,310
‫and we need to create an SQS queue for this.

72
00:02:34,310 --> 00:02:36,653
‫So let's go into the SQS service,

73
00:02:39,510 --> 00:02:41,150
‫and I'm going to create a queue,

74
00:02:41,150 --> 00:02:44,713
‫and its going to be a standard queue called lambda-DLQ.

75
00:02:46,710 --> 00:02:48,870
‫And I will click on create queue.

76
00:02:48,870 --> 00:02:51,020
‫Now my lambda-GLQ has been created.

77
00:02:51,020 --> 00:02:54,750
‫So let's go back into here and refresh this.

78
00:02:54,750 --> 00:02:59,360
‫And now I need to refresh this page probably.

79
00:02:59,360 --> 00:03:00,423
‫So let's refresh it,

80
00:03:01,580 --> 00:03:04,360
‫edit the letter queue service SQS

81
00:03:04,360 --> 00:03:07,930
‫and queue lambda-GLQ.

82
00:03:07,930 --> 00:03:09,320
‫Here we go, it's appearing.

83
00:03:09,320 --> 00:03:11,470
‫Save. And as we can see we can't save it

84
00:03:11,470 --> 00:03:13,040
‫because the function does not

85
00:03:13,040 --> 00:03:17,510
‫have enough permissions to call send message on SQS.

86
00:03:17,510 --> 00:03:18,343
‫And so to fix that

87
00:03:18,343 --> 00:03:21,180
‫we need to fix the IM role of our lambda function.

88
00:03:21,180 --> 00:03:24,300
‫So if you go into our lambda function,

89
00:03:24,300 --> 00:03:26,470
‫we go into our configuration

90
00:03:26,470 --> 00:03:29,710
‫and general configuration permissions, sorry,

91
00:03:29,710 --> 00:03:32,150
‫here is the execution role.

92
00:03:32,150 --> 00:03:32,983
‫So we click on it,

93
00:03:32,983 --> 00:03:35,180
‫so we're taking into the IM console,

94
00:03:35,180 --> 00:03:38,370
‫and I'm going to attach a policy to it.

95
00:03:38,370 --> 00:03:40,990
‫I will look for the SQS type of policy

96
00:03:40,990 --> 00:03:41,902
‫and I will just give it,

97
00:03:41,902 --> 00:03:46,110
‫the AmazonSQSFullAccess is going to be easy, at least.

98
00:03:46,110 --> 00:03:47,240
‫And this way we are sure

99
00:03:47,240 --> 00:03:50,790
‫that our lambda function can write into our SQS queue.

100
00:03:50,790 --> 00:03:53,230
‫So back into our lambda console,

101
00:03:53,230 --> 00:03:55,580
‫under the configuration for asynchronous,

102
00:03:55,580 --> 00:03:56,460
‫we scroll down,

103
00:03:56,460 --> 00:03:57,980
‫we save and this time,

104
00:03:57,980 --> 00:03:58,850
‫yes it completes

105
00:03:58,850 --> 00:04:01,957
‫and now my lambda function can write into SQS.

106
00:04:02,890 --> 00:04:07,350
‫So, if we try to go now into our CloudShell,

107
00:04:07,350 --> 00:04:09,650
‫and invoke this function again,

108
00:04:09,650 --> 00:04:12,090
‫we'll know that the invocation itself will fail

109
00:04:12,090 --> 00:04:15,170
‫because the lambda function function was coded to fail.

110
00:04:15,170 --> 00:04:16,890
‫But now what's going to happen is that

111
00:04:16,890 --> 00:04:19,710
‫the DLQ is going to kick into effect,

112
00:04:19,710 --> 00:04:22,150
‫so we're gonna have 2 retry attempts,

113
00:04:22,150 --> 00:04:24,730
‫and after the retry attempts have failed

114
00:04:24,730 --> 00:04:28,230
‫then the message should go into Amazon SQS.

115
00:04:28,230 --> 00:04:30,160
‫So right now if you're going to Amazon QS,

116
00:04:30,160 --> 00:04:32,380
‫and we're going to send and receive messages

117
00:04:32,380 --> 00:04:34,230
‫and look at the messages available.

118
00:04:34,230 --> 00:04:35,720
‫We can pull from messages.

119
00:04:35,720 --> 00:04:36,780
‫We have one message available.

120
00:04:36,780 --> 00:04:40,130
‫This was just a test for the lambda function,

121
00:04:40,130 --> 00:04:41,140
‫just to test whether or not

122
00:04:41,140 --> 00:04:44,200
‫it was able to send some data into SQS.

123
00:04:44,200 --> 00:04:46,020
‫So what I can do is that I can just

124
00:04:46,020 --> 00:04:47,570
‫delete that message right here.

125
00:04:49,100 --> 00:04:51,610
‫And now I'm going to wait 4 minutes

126
00:04:51,610 --> 00:04:54,330
‫to see if my lambda function

127
00:04:54,330 --> 00:04:57,160
‫sends a message to SQS due to the retries.

128
00:04:57,160 --> 00:04:59,630
‫So let me pause the video and get back to you.

129
00:04:59,630 --> 00:05:02,310
‫Okay, so now if I go into my CloudWatch logs,

130
00:05:02,310 --> 00:05:04,030
‫and look at this log stream,

131
00:05:04,030 --> 00:05:05,630
‫we can see something interesting.

132
00:05:05,630 --> 00:05:08,850
‫So there is a request ID that surfaces 2ab,

133
00:05:08,850 --> 00:05:10,220
‫and it's failed.

134
00:05:10,220 --> 00:05:11,980
‫Then if we scroll down,

135
00:05:11,980 --> 00:05:14,550
‫there is another request with 2ab,

136
00:05:14,550 --> 00:05:16,040
‫so the same request ID,

137
00:05:16,040 --> 00:05:17,000
‫and then it failed.

138
00:05:17,000 --> 00:05:18,177
‫So that was the first retry.

139
00:05:18,177 --> 00:05:20,670
‫And then there's another request with 2ab,

140
00:05:20,670 --> 00:05:23,230
‫then it failed and that was the secondary retry.

141
00:05:23,230 --> 00:05:25,687
‫So then the message went into the DLQ.

142
00:05:25,687 --> 00:05:27,990
‫And so if we go into SQS and pull for messages,

143
00:05:27,990 --> 00:05:30,790
‫we can see this message right here has failed.

144
00:05:30,790 --> 00:05:32,380
‫And we can look at the key and the value,

145
00:05:32,380 --> 00:05:35,320
‫and this was all the information around the message.

146
00:05:35,320 --> 00:05:37,390
‫And if we look at the attributes of the message itself,

147
00:05:37,390 --> 00:05:39,790
‫we can see that the error cause is 200,

148
00:05:39,790 --> 00:05:40,698
‫something went wrong

149
00:05:40,698 --> 00:05:43,430
‫and the request ID has 2ab in it,

150
00:05:43,430 --> 00:05:46,090
‫so this corresponds to the invocation ID in lambda

151
00:05:46,090 --> 00:05:49,490
‫that we can get directly from the message attributes in SQS.

152
00:05:49,490 --> 00:05:50,880
‫So this really shows

153
00:05:50,880 --> 00:05:54,890
‫that the asynchronous invocation and the DLQ work as well.

154
00:05:54,890 --> 00:05:56,200
‫So this is for this hands-on.

155
00:05:56,200 --> 00:05:57,040
‫I hope you liked it,

156
00:05:57,040 --> 00:05:58,990
‫and I will see you in the next lecture.