Share
Embed
Transcript
34 slides
-
自己紹介 藤田 直幸 X:@amarelo_n24 ・JAWS-UG 彩の国埼玉支部 運営 ・コーヒー焙煎人兼エンジニア ・ひとりBuilderCards Player 好きなAWSサービス:IAM、S3、CloudShell
好きなこと:コーヒー豆の焙煎 今欲しいもの: TIMEMORE S3 Coffee Grinder -
AWS CLIにはS3関連のコマンドが6種類あるけど、なぜか気になり、Kiroに聞きました。 ※私は回答内容を信じましたが、精査は不十分です。過信しないようご注意ください。 s3 高レベル よく使う操作を抽象化したもの s3api 低レベル Amazon S3
REST API と 1:1 対応 s3control 低レベル S3 Control API と 1:1 対応(Access Grants、Storage Lens 等) S3 の操作には「マルチパートアップロード」のような複数ステップが必要な処理があります。 低レベル API では: アップロードを開始する操作 パートをアップロードする操作 アップロードを完了する操作 という 3 ステップが必要です。これを毎回書くのは煩雑なので、高レベルインターフェースとして 1 回の呼び出しで完結できる s3 コマンドが作られました。 つまり「よくある操作を簡単にする」という UX 上の理由で s3 が生まれ、細かい制御が必要なユーザー向けに s3api が残された、と いう構造です。 なぜ今、マルチパートアップロードを? -
マルチパートアップロードを作成 マルチパートアップロード実行 aws s3api create-multipart-upload \ --bucket BucketName \ --key
'multipart-upload-test-CLI-LowLv.txt' \ --checksum-algorithm sha256 { "ServerSideEncryption": "AES256", "ChecksumAlgorithm": "SHA256", "ChecksumType": "COMPOSITE", "Bucket": "BucketName", "Key": "multipart-upload-test-CLI-LowLv.txt", "UploadId": "xxxxxxxxxxx・・・xxxxxxxxx" } -
マルチパートアップロードするファイルと紐づけたパートをアップロード ※part-number は、1から始まります。 ※パートは、00から始まります。 マルチパートアップロード実行 for i in {0..2} do
aws s3api upload-part \ --bucket BucketName \ --key 'multipart-upload-test-CLI-LowLv.txt' \ --part-number $((i+1)) \ --body multipart-upload-test-CLI-LowLv-0${i} \ --upload-id "xxxxxxxxxxx・・・xxxxxxxxx" \ --checksum-algorithm SHA256 done -
パート番号、ETag、チェックサム情報をJSONにアウトプット マルチパートアップロード実行 aws s3api list-parts \ --bucket BucketName \ --key
'multipart-upload-test-CLI-LowLv.txt' \ --upload-id "xxxxxxxxxxx・・・xxxxxxxxx" \ --query '{Parts: Parts[*].{PartNumber: PartNumber, ETag: ETag, ChecksumSHA256: ChecksumSHA256}}' \ --output json > multipart.json -
アップロードしたパートを結合して1つのオブジェクトに戻します。 マルチパートアップロード実行 aws s3api complete-multipart-upload \ --bucket BucketName \ --key
'multipart-upload-test-CLI-LowLv.txt' \ --upload-id "xxxxxxxxxxx・・・xxxxxxxxx" \ --multipart-upload file://multipart.json -
マルチパートアップロードをする方法は、AWS CLI、AWS SDK、S3 REST APIの 3通り。マネジメントコンソールからマルチパートアップロードするための設定は 無い。 ※アップロードできるファイルの最大サイズが160GBのため、 マルチパートアップロードする設計になっていないのでは?と想像。 ※マネジメントコンソールから160GBを超えるファイルをアップロードする
場合は、AWS CLI、AWS SDK、S3 REST APIのいずれかで実施とのこと。 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/mpu-upload-object.html もっと簡単な方法はないのか? -
上述した通り、Kiroが「これを毎回書くのは煩雑なので、高レベルインターフェースとし て 1 回の呼び出しで完結できる s3 コマンドが作られました。」と回答していました。も しかしたら、s3(高レベルコマンド)で大容量のオブジェクトをコピーすると、マルチ パートアップロードの挙動をするのでは? aws s3
cp ならばマルチパートアップロードできる? aws s3 cp multipart-upload-test-CLI-HighLv.txt s3://bucktname/multipart-upload-test-CLI-HighLv.txt -
小容量ファイル(12MB)を aws s3 cp でアップすると? aws s3 cp multipart-upload-test-CLI-HighLv-2.txt s3://bucktname/multipart-upload-test-CLI-HighLv-2.txt
s3 cp コマンドを実行 PutObjectでアップロードして いた!? -
AWS CLIは、BotocoreというPythonのライブラリを使っています。これはBoto3でも使 われています。 https://docs.aws.amazon.com/boto3/latest/guide/new.html Boto3の公式ドキュメントより Boto3 is built atop of
a library called Botocore, which is shared by the AWS CLI. Botocore provides the low level clients, session, and credential & configuration data. Boto3 builds on top of Botocore by providing its own session, resources and collections. (Boto3は、AWS CLIで共有されているBotocoreというライブラリをベースに構築されています。Botocoreは、低レベ ルのクライアント、セッション、認証情報および構成データを提供します。Boto3は、独自のセッション、リソース、コ レクションを提供することで、Botocoreの上に構築されています。) なぜ挙動が異なる!? -
[S3 customization reference]のページに、以下のデフォルト設定の記述が? なぜ挙動が異なる!? DEFAULTS = {'io_chunksize': 262144, 'max_bandwidth': None,
'max_concurrency': 10, 'max_io_queue': 100, 'max_io_queue_size': 100, 'max_request_concurrency': 10, 'multipart_chunksize': 8388608, 'multipart_threshold': 8388608, 'num_download_attempts': 5, 'preferred_transfer_client': 'auto', 'use_threads': True} 8388608バイト、つまり約 8MB デフォルトで 8MBごとにファイルをパート 分けしている? -
Boto3と同じライブラリを使っているAWS CLIも、8MB以上のファイルをaws s3 cpで アップロードする時は、デフォルトで8MBごとにパートを作って(最後のパートは8MBに 満たなくても良い)アップロードするということになります。しかしながら、AWS CLIのリ ファレンスには同様の内容が書かれておらず、マルチパートアップロードに関する細 かい設定もできないようです。 それっぽい気はしますが、これが答えと言い切れず推測の域を出ません。
個人的見解で恐縮ですが、`aws s3 cp`のような高レベルコマンドが色んな処理をよし なにまとめて実行してくれて、ユーザーを楽にしてくれているのかなぁと思いました。 なぜ挙動が異なる!?