람다, 서버리스의 첫걸음을 통해 AWS 의 Lambda 서비스에 대해 간략하게 소개를 했다. 이번에는 조금은 더 심도 있는 이야기를 할 텐데 람다의 구조와 원리를 파악하고 자연스럽게 그 한계를 깨우치도록 하자. 내부 로직을 어느정도 이해하고 있어야 어떤 상황에 서버리스( Serverless ) 람다가 독이 되는지 알 수 있게된다. 어설프게 이해하고 사용 하다가는 독이 된다는 사실로 시작해보자.서버리스는 없다람다는 AWS 에서 서버리스를 대표하는 서비스 중 하나다. 앞선 글에서도 그렇게 밝혔고. 근데 이제와서 서버리스는 없다니 이게 무슨 소리지? 이건 클라우드로 넘어오면서 생긴 개념인데 EC2 와 같은 IaaS 는 이미 사용자에게 서버를 클라우드 상에서 제공하며 IDC 상황에서 겪었어야 했던 수 많은 작업..
지금까지 읽었던 DevOps 책 중에 가장 재미있게 빠져들어 읽은 책인 것 같다. 정말 Dev와 Ops를 반반 정확히 섞어 놓은 느낌의 이 책은 결코 쉬운 책은 아니다. 커널 파라미터나 훌훌 넘어가는 리눅스 커맨드에 익숙하지 않다면 옆에 구글검색을 끼고 봐야할 것이다. 가령 strace, ftrace, tcpdump, wireshark 등 아주 짤막한 소개로만 넘어가고 바로 실전이다. 하긴, 이런 명령어만 다뤄도 책 한권은 뚝딱 쓰여진다. 아무튼 요즘 DevOps 는 이도저도 아닌 어정쩡한 포지션으로 남는 경우를 종종 보는데, 진정한 DevOps의 의미를 깨닫게 해준다. 클라우드에서 제공해주는 가성머신 위에 셸 스트립트 몇 개 돌린다고 DevOps가 아니다. DevOps라면 최소한 EC2나 GCE ..
아주 오래전부터 있던 개념이지만 클라우드와 함께 MSA 가 뜨거워지자 그 다음 단계로 Serverless 가 등장했다. Rest API 처리나 어차피 평소에 할일없이 빈둥거리는 서버를 없애고 인스턴스 내부에서 소소한 역할을 수행하던 것들을 함수처럼 클라우드에 등록해놓고 필요할 때 적절한 이벤트 트리거를 걸어 사용하는 방식이 람다에 대한 짧지 않은 소개가 되겠다. AWS lambda 는 GCP 에서는 Cloud Function 이라는 이름으로 존재하는 기능이다. 아무튼 여기서 람다에 대해 살펴보고 작은 모듈을 등록해서 사용까지 해보도록 하자. 우선 AWS console 에 접속해서 lambda 서비스를 검색하도록 하자. 검색후 서비스에 진입하게 되면 EC2 나 다른 서비스와 다르게 다소 심플한 메뉴로 구성..
지난번에 npm 과 pm2 에 대해서 살펴봤는데 이번에는 nvm 에 대해서 알아보도록 하자. 우리가 오픈소스를 개발한다면 readme 에 당연히 노드의 버전을 명시한다. 그리고 해당 오픈소스를 사용하려는 사용자는 (가급적) 명시된 노드 버전에 맞춰서 프로젝트를 돌려볼텐데 내가 설치한 버전과 상이한 버전의 노드를 실행시키기 위해서는 어떻게 해야 할까? 노드를 지우고 새로 설치? 혹은 파이썬의 virtualenv 와 같은 가상 환경이 존재할까? 아니, 그럴필요가 없다. 여기 노드 버전을 매니징 할 수 있는 nvm ( Node Version Manager )이 있다. ( 노드 공식 프로그램은 아니고 개인이 만든 프로그램인데 사실상 공식처럼 사용한다 )nvm 을 통해 우리는 다양한 노드 버전을 한 개의 시스템에..
노드의 강점은 그 홈페이지에서 찾아볼 수 있는데 아래와 같이 정의되어 있다.Node.js 는 이벤트 기반, 논 블로킹 I/O 모델을 사용해 가볍고 효율적입니다.하지만 이 강력함으로 인해 개발자는 곤욕을 치루게 되는데 그 중 하나가 콜백지옥이다. 콜백지옥이 발생하는 근본적인 이유는 노드의 비동기를 해결하고자 할 때 중첩 콜백이 이어지기 때문인데 왜 콜백을 중첩해서 사용해야 할까? 이 문제에 대해 나는 "우리 개발자 뇌가 아직 동기적으로 코드를 이해하려고 하기 때문" 이라고 이야기한다. 노드를 더 깊게 잘 이해하려면 비동기에 대한 이해를 높이고 중첩 콜백을 풀어야겠다. 각설하고 노드는 비동기에 특화되어 있는 플랫폼이다보니 무조건 동기적으로 처리해야만 하는 코드를 풀어내야 할 때 난항을 겪게 된다. 예를들어 ..
- Total
- Today
- Yesterday