Alphahacker Notes

올 2월, USENIX에서 발표된 아주 따끈따끈한 논문을 하나 소개하고자 한다. 제목은 "InfiniCache: Exploiting Ephemeral Serverless Functions to Build a Cost-Effective Memory Cache" 뭐 어려운 말로 적혀있는 것 같지만, 요약하면, "Lambda를 활용한 저비용 분산 캐시" 쯤 될 것 같다. Lambda를 왜 활용하는 걸까. 무슨 이득이 있을까. AWS에서 (분산) 캐시를 사용하는 가장 간단한 방법은 Managed Service인 ElastiCache를 사용하는 것이다. 클라이언트는 ElastiCache를 쓰기 위해서 특별한 노력이 필요하지 않고, 그저 인스턴스를 생성해서, 만들어진 Endpoint를 통해 명령을 보내고 결과를 받..

Lambda에서 Exception이 발생했을 떈 어떻게 될까 특히 Lambda와 Lambda 간의 통신일 땐(, Lambda 1이 Lambda 2에게로 요청을 보냈다고 했을 때), 만약에 Lambda 2에서 에러가 발생하면, Lambda 1은 Retry를 시도한다. Retry는 최대 두 번까지 일어나고, 결과적으로 총 최대 3번의 Request가 들어가게 된다. 만약 이것이 의도된 Retry가 아니라면 비용적으로 문제가 된다. 왜냐면, Lambda는 요청 건 수 당 비용이 발생하는 과금 정책을 가지고 있고, 때문에 의도하지 않은 요청이 두번/세번 더 들어가면, 비용이 불필요하게 두배/세배 늘어날 수 있으니까. 현업에서는 이런 문제를 해결하기 위해서, Exception 객체를 Lambda 밖으로 나가지 않..

하나의 요청에 DynamoDB나 Redis와 같은 툴을 사용하기 위해, 여러 커넥션이 만들어지는 상황이라면, 매번 커넥션을 새로 생성하지 않고, 커넥션 정보를 global로 두고 Reuse 하는 방식을 사용하면 성능 최적화가 가능하다. References https://theburningmonk.com/2019/02/lambda-optimization-tip-enable-http-keep-alive/

현업에서 AWS Lambda를 사용하면서 경험했던 바에 따르면, Lambda를 사용하는 것에 있어 가장 큰 단점이자 어려움은 Cold start인 것 같다. Lambda의 근간이 되는 기술인 Container라는 개념은 Scaling하는데 있어 혁신적인 기술이라고 여겨진다. 왜냐하면, Scale-out하는 상황에서, AWS EC2와 같이, 가상OS가 새로 생성되는 방식이기 아닌, OS 위에 돌아가는 독립적인 하나의 프로그램을 생성하는 개념이기 때문이다. 다시말해, 우리가 꺼져있는 컴퓨터를 키는 것이 아니라, 켜져있는 컴퓨터에 프로그램을 하나 키는 것이다. 때문에 당연히 훨씬 가볍다. 때문에 Lambda를 쓰게 되면, 가장 낮은 사양으로 셋팅하더라도, 부하가 생기는 순간에, Container가 빨리 빨리 ..

Serverless? 서버가 없다? 우리가 서버를 구축한다고 하면 보통 실물 서버를 구축하는 것을 말한다. 용산에 가서 컴퓨터를 한대 사와서, 거기에 OS를 깔고, 톰캣을 깔고.. 혹은 누군가 실물 서버를 잔뜩 사놓고 빌려줄 수도 있다. AWS 같은 회사가 엄청 나게 많은 컴퓨터를 사서, 한곳에 모아놓고 IDC를 구축하고, 부분 부분을 온라인을 통해 빌려주는거지. 심지어 OS도 미리 설치해주고. 그렇게 되면, 우리가 직접 용산에 가서 발품팔고, 힘들게 들고와서 선 연결하고, USB 꽂아서 OS설치할 필요가 없을 것이다. 전보다는 확실히 편해지긴 했지만, 나는 개발만 하고싶은 개발자인데, 움직이는 것은 너무나도 싫은일인데 저거 누군가가 좀 다 해줬으면 좋겠다. 나는 코드만 올리고 싶다. 그래서 나온 것이 ..