S3のGlacier Deep Archiveに大量のファイルを置いて後悔した話
結論から言うと
「S3のGlacier Deep Archiveに大量のファイルを置くのはやめとけ、極力zip化してから置け」です。
背景
iPhoneに推しのデータ(画録やスクショや写真)をためてました。(※著作権的に、自分が見返すだけならOKなはずです)
ただ最近推しが生まれたんですよ、娘っていうんですが
動画がどんどん増えていくんですよ...
iPhoneの容量が、足りなくなっていくんですよ.........
さすがに「推し＜娘」なので、推しのデータをどこかへ追いやることにしました。
どうしようか考えたところ、S3のGlacier Deep Archiveならまあまあ安いしいいのでは？と思い至ったわけです。
そして早速、推しのデータをS3のGlacier Deep Archiveに移行しました。
快適さを手に入れた
いったんiPhoneのバックアップを取って、昔の写真など消しました
そして推しのデータも待避し、iPhoneの容量が減った！
娘の動画撮り放題！やったね！
想定より料金が高い？
数ヶ月運用して、ふと料金を見てみたところ、なんか思ってたより高い...
200GB預けてるから、0.002/USD * 200GB で0.4USD位だと思っていたのに。
Cost Explolerのフィルタで、ディメンションは使用タイプ、使用タイプは全選択してデータを確認したところ、
APN1-TimedStorage-GDA-Stagingが2.25/USDかかっていて、APN1-TimedStorage-GDA-ByteHrsが0.27/USDだった。
APN1-TimedStorage-GDA-Stagingは、「S3 Glacier Deep Archiveへのマルチパートアップロードが完了していない、一時的なデータ保存」らしい。
確かに、アップロード中iPhoneがロックしてしまって、何回も失敗したのでそれが残ってるのか？と思った
※正直ここ本題じゃないので、調査結果あとで追記します
S3やめよう
なんか料金もめんどいし上手く使えないから、やめます。
家に使い方に癖があるNASがあるので、とりあえず、S3からNASにデータを移します。
ということで、Glacier Deep Archiveで保存したオブジェクト達を一括選択し、復元リクエストをかけ、お金が惜しいので48時間待ってデータを取得します。
移行するぞー
はい、48時間がたち復元が終わりました！
復元したオブジェクトたちを一括選択し、アクションからダウンロードを...
「押せない？？？！！」
え、全部復元リクエスト終わってるよね？
うん、オブジェクト詳細画面で確認したら、1つめと2つめは確実に終わってる
1つめを選択したら、アクションからダウンロードが選べる
1つめと2つめを複数選択すると...
「ダウンロードが選べない？？！！」
...そうか、そういう仕様なのね...
あきらめきれず、何かできないか探します。
すると、ストレージクラスの変更ができるじゃないですか！
一括選択し、ストレージクラスを標準に変更し始めると...
失敗する。
どうやら、GDAから標準に戻すことはできないらしい。復元済みであっても。
なんじゃそりゃ...
マネジメントコンソールからの変更はあきらめます...
CloudShellで頑張る
aws cli入れていないので、CloudShellでコマンドをたたいて、一括ダウンロードを試みます
ですが...
cp でも、syncでも、Object is of storage class GLACIER. Unable to perform download operations on GLACIER objects. You must restore the object to be able to perform the operation. See aws s3 download help for additional parameter options to ignore or force these transfers.というエラーが出てしまい、ダウンロードができない...
嘘だろ...
いや、嘘だろ？復元済みやぞ？？
...
......
.........
どうやら嘘じゃないようです...
マネジメントコンソールでぽちぽち頑張る
1個1個オブジェクトを開いて、ダウンロードして...
頑張って、動画たちは救い出しました。
...ここからが本題です。
冠番組のスクショを撮ってたんですが、
なんと！
zip化なんて当然してないんですね～！
その数500ファイル近く...
もう必死に、
フォルダ内のオブジェクトをホイールクリックで新しいタブで大量に開き、
マウスでダウンロードボタンをクリックし、
Enterで名前を付けて保存ダイアログのOKを押下し、
Ctrl+Wで現在のタブを閉じ、
をもう必死に！やりました！
2～3時間くらいかかりましたね...
結論
「S3のGlacier Deep Archiveに大量のファイルを置くのはやめとけ、極力zip化してから置け」
に至ります
基本、いつかは取り出すんですよ
なのに、GUIからもCloudShellからも一括ダウンロードできないなんて、思わないじゃないですか...
ということで、しめます
料金の追記
不完全なやつ、どこで見るのか分からなかったんですがやっと分かりました
「S3 Storage Lens」 の「ダッシュボード」でデフォルトのダッシュボードを選び、
「傾向とディストリビューション」で「プライマリメトリクス」を「不完全なマルチパートアップロードのバイト数」を選択
あ～めっちゃあるわ...
CloudShellを起動して、aws s3api list-multipart-uploads --bucket <あなたのバケット名>を実行する
あ～...このオブジェクトのアップロード失敗してたのね
aws s3api abort-multipart-upload --bucket <あなたのバケット名> --key <オブジェクトのキー名> --upload-id <UploadId>で、不完全なやつを削除します
最後にもう一度一覧APIを呼んで、もうないことを確認して...
はい！終わり！！
これで原因も分かったんで、不完全なマルチアップロードはすぐ消すライフサイクルルールを作って、おしまいです
iPhoneからいったんS3経由するのは楽だから、GDAじゃなく標準でやろうかなぁ
NASの本当に使わないデータたちはzip化してバックアップとしてGDAに置くのはありだなぁ～
pyinstallerでexe化後にimportが失敗しまくった
厳密に言うと、exe化後にexeを実行するとエラー、です
Python3.9.6、pyinstaller 6.11.1、venvを使用しています
1.from PIL import ImageTk
近くにimport tkinterも記載することで回避
PILはtkinterに依存しているがexe化時にはtkinterを含んでくれないっぽい？
tkinterをインポートすることを明示しておくことで解決
2.from pytorch_lightning import Trainer
[Errno 2] No such file or directory: 'C:\\Users\\work\\AppData\\Local\\Temp\\_MEI65802\\pytorch_lightning\\version.info'というエラーが出た
exe化時のコマンドをpyinstaller -F .\entrypoint.py --add-data=".venv\Lib\site-packages\pytorch_lightning\version.info;."に変えることで回避
明示的に含んであげないといけないっぽい
3.from anomalib.config import get_configurable_parameters
Can't get source for <class 'kornia.geometry.boxes.Boxes3D'>. TorchScript requires source access in order to carry out compilation, make sure original .py files are available.というエラーが出た
cd .\lib pip download kornia --no-binary korina==0.6.9 cd ..\ pip install --no-index --find-links=.\lib kornia==0.6.9
の後、
pyinstaller -F .\entrypoint.py --add-data=".venv\Lib\site-packages\kornia;kornia"でexe化することで回避した
終了コードについて 自分用メモ
終了コードについて、自分用メモ
| 終了コード | 意味 |
|---|---|
| 0 | 正常終了 |
| 1 | 一般的なエラー |
| 2 | シェル組み込み関数の誤用 |
| 126 | コマンドの実行権限がない場合 |
| 127 | コマンドが見つからない場合 |
| 128 | exitへの無効な引数 |
| 130 | Ctrl+Cによる中断で返される |
| 255 | 終了コードが範囲外の値 |
らしい
使ったことがあるのは、0の正常終了と、1の一般的なエラー
設定ファイル読込失敗時に10も使ったことがある
他の人が、多重起動時に2を使っていたけど...よくないと思う
SQLite 自分用メモ
次SQLite使うとき、自分が思い出すためにメモ
SQLiteは、インストールが不要で、代わりに「1つのdbファイル」でDBデータを管理するDB。
型は基本、INTEGER, REAL, TEXT, BLOBの4つを使う 参考
boolはINTEGER、DateTimeはTEXT, DecimalもTEXTで持つといいらしい
カラム変更とかはなんか大変らしい
pragma writable_schema=on;の実行後、update sqlite_schema set sql='create table ○○' where tbl_name='○○';みたいなSQLを実行すると変えられるらしい？ 参考
けど注意点もあるっぽい、まだやったことはないからわからない
社内の人への質問の仕方
自分ならどう聞くかみたいなのをまとめてみます。
弊社内ではSlackでやり取りしているので、挨拶や回答期限の設定はしていません。
同じプロジェクトに参画していて同じ業務をしているチームメンバーに対して
現在、入力画面で入力された値をチェックするタスクをしています。 ○○さんは編集画面の入力値チェックを実装されたと思いますが、 文字数チェックと数字かどうかのチェックはどちらを先に判定しましたか？
①質問の背景
②質問
を記載しています。
同じような業務をしているので、ざっくりめな質問を投げても通じ合えると思っているからです。
同じプロジェクトに参画しているリーダーやチームメンバーに対して
自分自身がプログラマーで、仕様の担当者に質問を投げる想定
入力画面の仕様について質問があります。 現在、入力画面で入力された値をチェックするタスクをしています。 入力画面の入力値チェックでは、nullチェックと文字数チェックと数字チェックをする仕様になっていると思います。 チェックする順番は、 1-nullチェック 2-文字数チェック 3-数字チェック で問題ないでしょうか？
①何についての質問か
②現在の状況
③質問
を記載しています。
自分とは違う視点で仕事をしている人に対しては、最初にトピックを絞りにいきます。
こうすることで、「何に対して回答がほしいか」が明確になって、回答者側も思考の狭い範囲から回答を探せるので楽なんじゃないかなと思っています。
上司に対して
自分自身が設計者で、上司はこのプロジェクトのことは案件概要くらいしか知らない想定
実装時の入力値チェックについて、会社として方針があるか質問です。 現在、○○というプロジェクトで入力値チェックの作業をしています。 OKボタンを押したときにメッセージダイアログを出すよりも、 値が入力された時点でテキストボックスの下に赤文字でエラーメッセージを出すほうが良いと思いました。 複数の別の案件を確認したところ、テキストボックスの下に赤文字でエラーメッセージを出す実装はほぼありませんでした。 テキストボックスの下に赤文字でエラーメッセージを出す実装は避けたほうが良いのでしょうか？
①何についての質問か
②現在の状況
③調べたこと
④質問
を記載しています。
最初にトピックを絞りにいくのは先ほどと同じですが、何を調べたかも伝えることで上司の工数を1つ減らせるかなと思っています。
まとめ
私はこのテンプレートで質問することが多いです。
人によっては背景とか要らないという人がいるけど、私は、なぜ質問してきたかが分からないと答えるのが難しいタイプなので、背景を書くようにしています。
背景要らない人は読み飛ばせばいいだけの話なので。
また、
(前略) テキストボックスの下に赤文字でエラーメッセージを出す実装は避けたほうが良いのでしょうか？ それとも、実装しても問題ないでしょうか？
という質問はしないようにしています。
複数人から何度か、「はい、お願いします」というような返事を受け取ったことがあるためです。
「Yesですか？Noですか？」と聞くのではなく、「Yesですか？」または「Noですか？」とだけ聞くようにしています。
この質問テンプレートは、情報が整理できてとてもよい一方で、
記載するのに時間がかかる点はデメリットです...
P.S.
「設計書終わった？」みたいに声かけてくる人が苦手です。
どのプロジェクトの？
基本設計？機能設計？詳細設計？
期限いつまでだったっけ？
みたいに考えることが多くてパニックになるので...(;^ω^)
ビジネスメールの書き方
新人さんに聞かれたけどうまく答えられなかったのでまとめてみます。
といっても私が別会社の時に習ったものなので、オリジナルではありません。
送り先
To, Cc, Bccの3種類があります。
Toは返信がほしい相手、Ccは見ておいてほしい相手、Bccは隠れて見てほしい相手です。
Ccには上司を入れることが多いイメージです。
このあたりの使い分けは気が向いたら追記します。
件名
「内容が分かるように」以上のことは言えません。
というのも、件名は、企業によってだいぶルールが違います...。
以前の会社では【】(すみかっこ)を多用してましたが、ﾍｲｼｬではほとんど使いません笑
本文の構成
まず本文の構成。例は社内向けの場合。
○○さん お疲れ様です。○○です。 ～～～要件～～～ よろしくお願いいたします。 ------- 署名 -------
- 宛先の名前
まず、宛先の名前を書きます。
社内なら○○さん、○○課長、各位など。
何を選ぶかは今後追記するかもしれません。
社外なら会社名 ○○様。
- 挨拶
次に挨拶＋名前を書きます。
社内ならお疲れ様です。○○(自分の名字)です。
社外ならお世話になっております。○○(自分の名字)です。
...が無難だと思っています。
- 本文
次に本文を書きます。
ここは特に指定があるわけではないので、分かりやすい文を心がけましょう。
一文が30～40字になるように、適度に改行を入れるといいようです。
- 最後の挨拶
次に締めの挨拶を書きます。
以上、よろしくお願いいたします。とかご確認をお願いいたします。とかですね。
- 署名
本文の最後には署名を書きます。
------- 会社名 部署名や役職 漢字名前 (ふりがなやアルファベット表記があると親切) E-mail 会社住所 会社電話番号 -------
...などなど記載します。
「メール 署名 デザイン」とかでググればたくさん出てくると思うので、好みのものを見つけましょう！
送信前確認
メール送信の前に指さし確認するべき7点があります。
- 宛先があっているか
- 件名がついているか
- 本文 宛先の人の名前
- 本文 挨拶「お世話になっております、○○です」的な
- 本文 最後挨拶「以上、よろしくお願いいたします」的なやつ
- 本文 自分の署名
- 添付ファイル
個人的には、これを毎回(脳内で)指さし確認していたらメールのミスほぼなかったので、結構使えると思います！
引用返信
返信の際は引用返信しましょう。
ビジネスでは、話の流れを保持しておくために引用返信が基本です。
余談ですが、私が高1の時はまだLINEがなくて、メールでやり取りしていました。
引用返信＝晒しのような感覚だったので、ビジネスでは引用返信が基本だと知って驚いたものです...
以上
また何か思い出したら書き足します～
