PlanB의 백엔드 엔지니어링

boto3는 워낙 기능이 방대하다 보니 대부분의 경우에는 gist 등에서 예제를 찾아보게 되는데, boto3.resource를 사용하는 예제도 있고, boto3.client를 사용하는 예제도 있었다. 둘을 비교해 보자.

Client

• low-level 인터페이스
• service description에 의해 만들어짐
• botocore 수준의 client를 공개(botocore는 AWS CLI와 boto3의 기초가 되는 라이브러리)
• AWS API와 1:1 매핑됨
• 메소드가 스네이크 케이스로 정의되어 있음

가끔가다 보면 botocore의 API를 찾아봐야 하는 경우가 생길 때도 있다. boto3.client는 AWS API와 1:1 매핑된다는 게 꽤 큰 메리트였던 것 같다.

Resource

• high-level, 객체지향적 인터페이스
• resource description에 의해 만들어짐
• 식별자(identifier)와 속성(attribute)을 사용
• 자원에 대한 조작 위주

'자원에 대한 조작 위주'라는 게 정확히 무슨 의미인지는 잘 모르겠지만, s3.Bcuket과 같은 구문을 의미하는 것이 아닐까 싶다. 당연하게도, boto3.resource는 boto3.client를 wrapping한 high-level 인터페이스지만 boto3.client의 모든 기능을 wrapping하진 않으므로 때때로 boto3.client나 boto3.resource.meta.client를 사용하여 작업해야 하는 경우가 생길 수 있다.

로직 수준의 직관성과 코드 수준의 직관성의 차이가 아닐까 싶다. 나는 boto3를 회사에서나 가끔 쓰는 정도였어서, 어떤 게 더 나았다거나 하는 주관적인 입장도 사실은 없다. 사용량 기준으로는 boto3.client가 더 많았던 것 같고, boto3를 써야 하는 작업이 있다면 boto3.client로 먼저 방법을 찾아보지 않을까 싶다. 그것보다 boto3는 네이밍 컨벤션이 참 특이한 것 같다.

boto3에서 거의 대부분의 기능은 AWS API를 사용하고, 자원에 대한 자격을 증명하기 위해 AWS IAM에서 얻어낼 수 있는 AWS access key ID와 AWS secret access key, 또는 임시 자격 증명을 위한 aws_session_token을 사용한다. 일반적으로 awscli 등의 도구를 통해 ~/.aws/credentials에 자격 증명 데이터를 설정하고, boto3는 여기에 접근해 자격 증명을 진행한다. 그러나 boto3를 사용하는 어플리케이션에서 여러 개의 자격 증명을 동시에 수행해야 하는 경우가 생길 수 있다. 데이터를 수집하여 원하는 곳으로 서빙해주는 B2B 서비스인 Segment의 Amazon S3 Integration 기능을 예로 들 수 있다.

다행히도, boto3는 자격 증명 데이터를 얻어낼 때까지 여기저기에 순서대로 접근한다.

client, resource 함수에서 자격 증명 데이터를 매개변수로 전달

client, resource, Session 등을 얻을 때 aws_access_key_id, aws_secret_access_key, aws_session_token이라는 문자열 타입의 선택 인자를 사용할 수 있다. 시스템 설정을 무시하고, 자격 증명 데이터를 직접 전달하고 싶을 때 대부분 이 방법을 사용한다.

환경 변수

client, resource, Session에 자격 증명 정보가 인자로 전달되지 않으면, 환경 변수를 확인한다.

AWS_ACCESS_KEY_ID

AWS 계정의 access key

AWS_SECRET_ACCESS_KEY

AWS 계정의 secret key

AWS_SESSION_TOKEN

AWS 계정의 세션 키

공유 자격 증명(Shared credentials) 파일

그 다음부턴 파일들에 접근하기 시작한다. 공유 자격 증명 파일의 기본 위치는 ~/.aws/credentials이고, AWS_SHARED_CREDENTIALS_FILE 환경 변수를 설정하여 위치를 변경할 수 있다. credentials는 .ini 형식의 파일이고, 각 섹션마다 자격 증명을 위한 세 가지의 변수를 지정할 수 있다.

섹션 각각을 profile이라고 부른다. session을 생성할 때 AWS_PROFILE 환경 변수를 설정하거나 profile_name 인자에 이름을 전달하여 어떤 profile을 사용할 지 명시할 수 있다. 여기서 session은 client나 resource를 생성할 수 있도록 자격 증명에 대한 '상태'를 저장하고 있는 객체다.

별도로 명시하지 않으면, [default] profile을 사용한다. 보통은 이렇게 credentials를 사용하는 방식을 쓰는 것 같다.

AWS Config 파일

기본 위치는 ~/.aws/config이고, AWS_CONFIG_FILE 환경 변수를 설정하여 위치를 변경할 수 있다. config 파일은 credentials 파일과 동일하게 작성된다. 유일한 차이점은, profile 섹션을 [profile [name]] 포맷으로 표현한다는 것이다.

AssumeRole을 호출시키기

AWS_CONFIG_FILE 환경 변수에 명시된 파일이나, 기본 경로인 ~/.aws/config 파일에서 role에 대한 정보를 명시하여, boto3가 자동으로 AWS STS에 AssumeRole을 호출하도록 할수도 있다. role_arn, source_profile, role_session_name 등의 파라미터가 필요하다.

boto2 config

그 후에는, boto2 config 파일에서 자격 증명을 로드한다. BOTO_CONFIG 환경 변수가 나타내는 경로의 파일을 먼저 검사하고, 그렇지 않으면 /etc/boto.cfg와 ~/.boto 파일을 검사한다. [Credentials] 섹션만 사용한다.

IAM Role

Amazon EC2에서 실행 중이며 위의 방법들로 자격 증명을 찾지 못한 경우, boto3는 EC2 인스턴스의 메타 데이터 서비스에서 자격 증명을 로드한다. EC2 인스턴스를 시작할 때 사용할 IAM role만 지정하면, 별도의 명시적인 구성을 하지 않아도 boto3가 알아서 인스턴스의 자격 증명을 사용한다.

Best Practice

boto3는 자격 증명 정보를 얻기 위해, 결론적으로 아래의 순서를 따른다.

1. client/resource/Session에 전달되는 자격 증명 정보
2. 환경 변수
3. AWS_SHARED_CREDENTIALS_FILE에 명시된 파일 또는 ~/.aws/credentials에 접근
4. AWS_CONFIG_FILE에 명시된 파일 또는 ~/.aws/config에 접근
5. AWS_CONFIG_FILE에 명시된 파일 또는 ~/.aws/config에 접근하여 role 데이터(arn 등)로 AWS STS에 AssumeRole
6. BOTO_CONFIG에 명시된 파일에 접근
7. /etc/boto.cfg에 접근
8. ~/.boto에 접근
9. EC2 인스턴스의 IAM role 설정에 접근

EC2 인스턴스에서 boto3를 사용하는 경우 IAM role을 사용하는 것이 좋고, 그렇지 않은 경우라면 공유 자격 증명 파일(~/.aws/credentials)을 쓰는 것이 좋다고 한다.

HTTP HEAD 메소드는 특정 자원을 GET 메소드로 요청하는 경우에 어떤 헤더들이 반환되는지를 요청한다. Amazon S3 API의 경우 객체에 대해 HEAD 요청을 전송하면 응답에 Content-Length가 함께 전달될텐데, 이를 통해 굳이 GET 요청으로 객체를 읽지 않고도 객체의 용량을 알아낼 수 있다. boto3에서는 head_object라는 이름의 메소드로 bucket에서 특정 key에 해당하는 객체에 HEAD 요청을 보낼 수 있다.

head_object 메소드는 객체의 메타데이터들로 이루어진 dict를 반환하고, 'ContentLength'라는 key에 객체의 size가 값으로 담겨 있다. 단위는 byte다. 아쉽게도 Bucket 객체에는 head_object 메소드가 없다.