[AWS] 서버리스란 무엇인가

이 글은 AWS Lambda로 시작하는 서버리스를 참고하여 작성하였습니다.

작성자 : 신동현

서버리스란?

서버리스는 Server+less로 서버가 없다는 뜻이다.

얼핏 들으면 물리적인 서버가 없다는 소리로 들릴 수 있으나 서버를 직접 구축하지 않고 서버에서 하는 작업을 클라우드 기반의 서비스로 처리하는 것이다.

서버리스를 이해하기 위해서는 클라우드 네이티브 패턴을 우선 알아야 한다.

전통적인 서버 구축 방식은 legacy 방식 부터 클라우드 컴퓨팅의 등장으로 생긴 서비스들을 먼저 이해해야 한다.

현존 클라우드 네이티브 패턴

서버리스의 형태

일반적으로 서버리스는 두가지 형태이다.

-BaaS

• 백엔드의 여러 파트를 부분적으로 서비스로 제공 받는 것.
• Auth0 같은 인증서비스 혹은 Firebase와 같은 모바일 백엔드 서비스가 있다.

-FaaS

• 함수를 서비스로 이용하여 구동하는 것. 서버코드 작성이 필요없고 함수만 구현하면 된다.
• 이벤트 기반으로 동작하며 단일 함수로 간단한 작업 뿐 아니라 여러 함수를 엮어 복잡한 로직도 구현 가능
• 기존 서비스와 달리 사용하지 않을 떄 비용이 나가지 않는다.

기존의 온프레미스 방식과 서버리스는 무엇이 다를까?

온프레미스 방식의 경우 서버가 24시간 구동되며 일을 처리한다. 이벤트가 발생하지 않더라도 서버는 24시간 내내 대기 상태에 있으면서 클라이언트의 request를 처리하게 된다.

 

그러나 서버리스의 경우 Clinet의 request에 따라 Function A 혹은 B 만 호출이 발생할 수 있고 24시간 내내 구동할 필요 없이 Client의 request가 발생할 때만 구동하면 된다.

 

기존 온프레미스에서 서버에 부하가 걸리는 경우 서버를 추가함으로써 급증하는 request에 대응 할 수 있다. 서버를 추가하는 것을 스케일 아웃, 서버 자체의 용량을 늘리는 경우 스케일 업이라 한다. 보통은 서버 한 곳에 요청이 몰리게 하지 않고 여러 서버에 부하를 균등하게 배분한다. 각 서버별로 균등하게 부하를 나누어 주는 역할을 하는 것을 로드밸런서라고 한다.

 

FaaS는 이러한 로드밸런싱이나 스케일 아웃, 업이 보통 필요하지 않다. AWS Lambda의 경우 AWS가 이에 알맞은 오토 스케일링을 진행하여 사용자 입장에서 관리하는 요소는 줄어든다. 물론 그렇다고 FaaS가 NoOps는 아니다. 아무리 FaaS라도 모니터링, 보안, 네트워크는 직접 관리해줘야 하며 AWS로 부터 제공받는 오토 스케일링도 제약이 있는만큼 엄밀하게 관리할 요소가 없지는 않다.

 

이렇게 많은 장점을 가지고 있는 FaaS도 단점이 없는 것은 아니다.

1. 상태유지가 되지 않는다
   • Client의 request가 들어온 경우 컨테이너가 잠시 실행되는 환경이다. 이로 인해 상태를 저장하지는 않으며 작성된 코드 상태 그대로의 값을 유지하다 매번 실행되기 때문에 변경된 값을 이용하여 로직을 구현하는 방식은 사용할 수 없다. 이를 보완하기 위해 DB를 사용해야한다.
2. 함수가 실행되기 위해 항시 대기하지 않는다
   • 함수를 실행 시 약간의 지연시간이 발생한다. 컨테이너가 새로 시작되는 시간이 필요하기 때문에 이를 ‘콜드 스타트’라고 한다. 그러나 한번 실행한 이후에 다시 실행하는 것은 대기상태에서 바로 구동하는 것이기에 지연시간이 없다. 이를 ‘웜 스타트’라고 한다.

AWS란?

AWS(Amazon Web Service)

클라우드 컴퓨팅 서비스로서 인터넷을 통해 IT리소스를 제공하는 서비스이다.

클라우드 컴퓨팅은 세가지 유형이 있다.

• 퍼블릭
  • 모든 리소스를 서비스 제공자가 이용하는 것
• 프라이빗
  • 퍼블릭과 반대로 서비스를 개인 혹은 회사가 독점적으로 이용하는 것
• 하이브리드
  • 퍼블릭/프라이빗 데이터와 어플리케이션을 모두 공유하는 것을 의미한다. AWS가 이에 해당한다

AWS는 서비스 지역에 따라 비용 및 퍼포먼스가 다르다.

1. Region
   • AWS는 각 지역마다 데이터 센터들이 독립적으로 존재하는데 이를 Region이라고 한다.
   • Region에 따라 제공되는 서비스의 종류가 다름.
2. Availability Zones
   • Region안에 존재하는 데이터 센터의 논리적인 그룹이다.
   • Availability Zones는 모두 물리적으로 나누어져 있으나 Zones 사이에서 빠른 통신이 가능하고 같은 Region에서 다른 Zones 설정을 통해 특별한 이벤트 발생에도 안정적인 서비스 운용이 가능하다.
3. Local Zones
   • Region안에 존재하며 보다 빠른 통신을 위해 존재한다.
4. Edge Location
   • 여러 콘텐츠를 빠르게 사용자에게 제공할 수 있도록 전세계 곳곳에 위치한 캐시서버에 복제하는 서비스이다.

 

AWS 권한관리

AWS IAM

IAM은 AWS의 권한을 관리하는 서비스이다.

AWS 계정을 이메일로 생성하면 모든 서비스에 접근할 수 있는 권한이 생긴다. ROOT 권한이라고 생각하면 된다. 그러나 이를 이용해서 서비스를 사용하는 경우 ID가 외부에 노출되었을 때 매우 위험하다.

그렇기에 위험을 방지하고자 일반적으로 IAM을 통하여 필요한 권한을 세분화하여 Role을 부여하고 불필요한 접근을 막아 보안적인 측면과 시스템의 안정성을 챙긴다.

IAM에서는 AWS계정인 증에 MFA를 지원한다.

 

아무런 MFA를 설정하지 않았을 때 MFA를 추가하라는 표시를 볼 수 있다.

IAM에서는 MFA(Multi Factor Authentication)을 통해 사용자의 신원을 확인할 수 있다.

Factor는 총 3가지로 나뉜다. 지식, 소유, 속성 기반 인증으로 3가지가 있다.

• 지식 기반- ID/PW와 같이 알고 있는 인증 정보를 이용한 방법
• 소유 기반- 휴대폰 SMS인증 등 사용자가 소유한 것을 이용한 방법
• 속성 기반- 고유의 속성을 이용하는 것으로 지문 인식, 홍채 인식 등을 이용한 방법

이러한 MFA를 사용하여 사용자는 작업을 위해 암호, 엑세스 키 뿐아니라 한단계 더 확인을 거치게 된다.

IAM에서는 크게 네가지 구분이 있으며 사용자는 이를 구분할 줄 알아야 한다.

1. IAM User - 사용자
2. IAM Group - 사용자 그룹
3. IAM Role - 권한
4. IAM Policy - 정책

예시를 들자면 이렇다.

개발자(User)는 A라는 역할(Role)이 있고 Role에 정의된 정책은 B정책(Policy)이다. B Policy는 C라는 Amazon S3 버킷(Resource)만 컨트롤(Role)할 수 있다. 여기서 B Policy는 Amazon S3 Resource에 접근하는 Entity(사용자, 그룹, 권한)을 Policy로 정의하는 것이다.

이러한 IAM Policy는 JSON으로 정의된다.

{
"Version": "2022-05-05",
	"Statement": 
	 [
			{
			 "Effect": "Allow",
			 "Action": "s3:GetObject",
			 "Resource": "arn:aws:s3:::test/*",
			 "Principal": {"AWS": "arn:aws:iam::AWS-account-ID:user/user-name"}
			}
	 ]
}

• Version: IAM Policy JSON 문서의 양식 버전이다.
• Statement: 배열구조이며, 정책의 요소들을 나열 한다.
• Effect: Allow, Deny 두가지가 들어간다.
• Action: 한번에 여러Action을 지정하는 경우 문자열을 사용하여 지정한다.
• Principal: Resource 접근 허용 주체를 지정한다. User, Group, Role에 따라 다르게 설정한다.
• Resource: ARN(Amazon Resource Name)으로 접근 가능한 Resource 지정한다.

이렇게 IAM을 통해 User마다 역할 및 접근 권한을 조정할 수 있으며 시스템 보안 및 안정성을 챙길 수 있다. Root 계정을 통해 서비스를 유지보수 하는 것은 많은 위험이 있으니 IAM을 꼭 쓰도록 하자.

 

IAM 사용자 계정 생성 및 권한 부여

그렇다면 실제로 어떻게 권한을 부여하고 계정을 생성할 수 있을까

사용자 계정을 새로 생성한다.

사용자 이름 설정 및 AWS Management Console Access권한을 부여하여 관리자는 초기 계정 생성 이외에는 사용자의 비밀번호 및 다른 요소에 신경쓰지 않아도 된다.

설정이후 사용자를 Group에 넣어줘야하지만 Group이 없는 관계로 Group을 생성한 후 사용자를 추가한다.

Group이름을 설정 한 다음 가장 상단의 ‘AdministratorAccess’를 체크하여 관리자에 준하는 권한을 부여한다.

 

마지막으로 검토를 진행한다.

검토를 진행하면 사용자를 만들고 계정 추가가 완료된다.

비밀번호는 초기 비밀번호가 설정되며 이를 이메일로 전송하거나 csv파일로 다운로드 할 수 있다.

사용자는 URL 혹은 파일을 제공받아 이를 통해 로그인을 하면 된다.