[9-10 주차 이론 정리]
1. 주요 개념들
- 서버리스(Serverless)의 본질: 서버가 아예 없다는 뜻이 아니라, 클라우드 제공업체(Azure, AWS, GCP 등)가 서버의 프로비저닝, 유지 보수, 스케일링을 전적으로 대신 처리해 준다는 의미이다. 개발자는 '함수(Function)' 형태로 코드만 작성하여 배포하면 된다.
- 이벤트 중심의 트리거(Trigger): 작성된 코드는 항상 실행 상태로 대기하는 것이 아니라, 특정 '이벤트'가 발생했을 때만 작동(트리거)한다. HTTP 요청, 데이터베이스 변경, 스토리지 내 파일 업로드 등이 대표적인 트리거 요인이다.
- 바인딩(Binding)을 통한 서비스 연결: 트리거로 함수가 실행될 때, 외부 데이터베이스나 스토리지와 데이터를 주고받아야 한다. 이때 함수가 데이터를 받아오는 것을 '입력 바인딩(Input Binding)', 처리 결과를 내보내는 것을 '출력 바인딩(Output Binding)'이라고 부르며, 이를 통해 여러 클라우드 리소스가 블록처럼 조립된다.
2. 서버리스 도입의 장단점
서버리스 도입을 고려할 때는 장단점을 명확히 이해해야 한다.
| 구분 | 특징 |
| 장점 | 사용한 컴퓨팅 리소스만큼만 비용을 지불하므로 경제적임. 트래픽에 맞춰 자동으로 확장(Auto Scaling)되며, 유지보수 부담이 줄어 개발 속도가 빠름 |
| 단점 | 함수가 처음 실행될 때 준비 시간이 필요한 '콜드 스타트(Cold Start)' 지연 현상이 발생할 수 있음. 또한 특정 벤더에 종속될 위험이 있고, 장기 실행 작업에는 적합하지 않음 |
[9-10 주차 실습 정리]
1. Blob Storage 기반 악성 파일 차단기 구축:
첫 번째 실습은 클라우드 스토리지에 파일이 업로드되는 이벤트를 감지하는 'Blob Trigger'를 활용했다. 사용자가 Blob Storage에 파일을 올리면, 함수가 즉각적으로 파일의 확장자나 메타데이터를 분석한다. 만약 .exe나 스크립트 파일 등 보안 위협 요소가 있는 파일로 판단되면 자동으로 삭제하는 로직을 구현했다.
2. HTTP 트리거를 활용한 나만의 번역 API 구축:
두 번째 실습에서는 HTTP 요청을 트리거로 삼아, 다국어 텍스트 번역과 언어 감지 기능을 제공하는 Azure Translator API와 연동했다.
- 과정: 사용자가 웹 프론트엔드에서 한국어를 입력하여 POST 요청을 보내면, 함수가 내부적으로 Translator API를 호출한다. 이후 번역된 영어 텍스트 결과를 다시 사용자 웹 화면으로 돌려준다.
- 역할: 이 실습을 통해 Azure Function 자체를 웹이나 앱에서 언제든 호출해 사용할 수 있는 독립적인 '백엔드 API'로 작동시킬 수 있음을 확인 할 수 있다.
3.중요한 점
- IDE의 중요성: 간단한 테스트는 Azure Portal 환경에서도 가능하지만, 복잡한 트리거 구성과 디버깅을 위해서는 Visual Studio Code와 같은 로컬 IDE 환경을 세팅하는 것이 작업 생산성 측면에서 훨씬 유리하다는 것을 깨달았다.
- 코드의 간결성: 서버리스 환경에서는 인프라 설정 코드가 통째로 빠지기 때문에, 비즈니스 로직(위협 파일 감지, 번역 API 호출 등)에만 집중할 수 있어 코드의 가독성과 생산성이 크게 높아졌다.
[정리]
- 서버리스 아키텍처는 인프라 관리 없이 비즈니스 로직 구현에만 집중할 수 있는 유연한 클라우드 모델입니다.
- Azure Functions는 HTTP, 파일 업로드 등 다양한 '트리거'에 반응하여 동작하며, 사용한 시간만큼만 비용을 지불합니다.
- 기능 단위로 설계된 서버리스 함수들은 그 자체로 독립적인 백엔드 API 역할을 훌륭히 수행할 수 있습니다.
다음 링크 >> https://mehannah.tistory.com/11