LoginSignup
0
0

More than 3 years have passed since last update.

AWS試験対策(④コンピューティングとストレージ続々)

Posted at

ストレージ〜自分はストレージのことよくわかってない気がするけどなんとか生きてる。この機会に覚えたいと思う。

EBS

cドライブみたいなもん。こいつは一途だから一つのインスタンスにしかくっつけない。一方、インスタンスくんはたくさんのEBSちゃんをたぶらかすことが可能…。
同じAZのインスタンスにのみくっつける。一途な割には遠距離恋愛不可。
他のAZのインスタンスとどーしてもくっつきたい場合は、s3に写真をあげて、くっつきたいインスタンスがあるところで写真からクローン作ればオッケイ。

容量は1GB単位で指定できる。最大は16TBまで。最初に10!って宣言しちゃって、後からやっぱ15ほしいわ!とかもできる。

この子はインスタンスに一途だけど運命共同体ではない。インスタンスがいなくなってもこの子は生き続ける。たくましい。

EBS最適化インスタンス

デフォルトで無効。
インスタンス君はEBSちゃんだけじゃ飽き足らず、いろんなとこに通信というちょっかいを出しに行きます。
なので、忙しくてEBSちゃんへの連絡が遅くなったりします。しかしこのオプションをつければ、EBS専用の回線ができて、他の子に邪魔されることがない!ってなやつです。

ボリュームタイプ

汎用SSD
いわゆる一般的なやつ。

プロビジョンドiops
汎用じゃスピード足りねえな!ってときに使う。DBとか。

スループット最適化HDD
シーケンシャルアクセス時に高い性能。要するに大きいデータを処理するのが得意だという。

コールドHDD
同じく大きいデータを処理するのが得意だけど、スループット最適化よりは劣る。劣ってても安いほうがいいなら使うんじゃないかな。

マグネティック
コールドHDDよりもさらに安い。しかしさらにパフォーマンスは劣る。旧世代のものだからあまりおすすめされない。

名前で覚えれそう。汎用は普通の。IOPSはI/O早い。スループット最適化は大きいデータ。コールドはそれの劣化。マグネティックは更にそれの劣化。でも安いからめったに使わないデータとかならこっちのほうがいいんちゃうか。

EBSスナップショット

要するにバックアップを圧縮してS3ってとこに保管してるよって話。S3で中身にアクセスすることはできない。
増分のバックアップをしている。一枚目はすべてを保存してる。2枚目は、一枚目と二枚目の違うとこだけ保存してる。
となると、途中を消しちゃ困るような気がするけども、ちゃんと考えてて、その場合は3枚目と違うとこだけ消える。文字だと何言ってるかわからないなこれ。。。
5枚目がA.B.Cってデータを持ってて、6枚目はCがDになってたため、Dのデータを持ってる。
その場合、5枚目を消そうとしてもA.Bは残ってCだけ消える。Cは2枚目でDになってて必要ないからな。
言ってて更にわかりにくくなったけど、とりあえず増分バックアップしてるってことだけ覚えればいいかも

初期化

新規作成の場合、作ってすぐに最高のパフォーマンスを出せるけど、スナップショットから生成した場合はそうはいかない。
アクセスしたことがないデータがあるから、動作がどーしても遅くなる。
じゃあどーすればいいかって、全部事前にアクセスしとけばいいじゃん!ってのがこの初期化。

EBSの課金

確保した分だけ課金される。
10GB分確保しておいて、実際1GBしか使ってなくても10GB分請求される。
さっきも言ったけどインスタンス君が死んでもこの子は生き続けるので課金マジ注意。

EBS暗号化

新しく作るときか、スナップショットからクローンを作るとき、暗号化できる。そのままでは暗号化できない。
暗号化されたやつのスナップショットは暗号化されてる。AES-256って形式のみらしい。

S3

オブジェクトストレージといい、ファイル構造を持たない。
データを入れる器をバケットと言う。
オブジェクトキーはファイルの名前。プレフィックスというものを使って階層構造のようなものをつくってる。
実態はファイル構造を持たないけど、ファイル構造のように見せるためにプレフィックスという属性をつけてるみたいな。

EBSへアクセスするときは同じAZじゃなきゃいけなかったけど、S3の場合は同じリージョン内まで可能。なぜなら、VPCエンドポイントというものを使うから。
VPCエンドポイントは、s3と通信を行うときの中継地点的なもの。s3はVPCの外にあるからこの中継点がないと繋げない。インスタンスとバケットの中継地点と覚えていいかも。

特徴は、ファイルを3箇所以上のAZのDCに保存するから耐久性が高い。
結果整合性モデルが使われている。どういうことかというと、書き込んだり削除したりすると、3つのDCすべてに反映されるまでにラグがあるよってこと。
削除指示してすぐに一箇所目からは消えたけど3箇所目にはまだ残ってるからアクセスできたりする。
名前通り、結果的に一緒になってればいい、整合性とれてればいいってこと。

容量は無制限で安い。使った分だけ課金される。

S3ストレージの種類

S3標準
その名の通り標準的なやつ。

S3 Intelligent-tiering
データへのアクセス頻度を判別してくれて、自動的に適切なとこに移してくれる。よく使うのはそのまま、使わないのは取り出すのに手間かかるけど安いとこにしまっておくとかそういうことをしてくれる。

S3標準-IA
あんまアクセスしないけど、必要なときはすぐほしい!ってものを入れる。安くしまえるけど、取り出すときにもお金がかかる…

S3 1ゾーン-IA
アクセスしないものを入れる。名前のとおり、従来では3箇所にしまってたけどこのプランは一箇所にしかしまわない。
一応耐久性はめちゃくちゃあるらしいけどAZ全体が破壊されたらデータはなくなる。戦争かな?
一箇所だから安い。もともとの標準も大概に安いからあんま恩恵受けないような気もするけど、死ぬほど大きなデータをしまう際には結構変わってくるんだろうな…

S3 glacier
テープバックアップらしい。やっすいけど取り出しのときにお金だけじゃなく時間もかかる。
グレイシア…氷…冷凍保存…って覚え方。

主要機能

バージョニング
世代管理できる。エクセルの過去のバージョンの復元みたいなやつ。これ使うとバージョンごとに保存されて容量増え続けるから注意。
MFA deleteという、多要素認証消去って機能がある。間違って消す操作しても他の要素で認証しないと消せないって仕組み。間違って消すオペレーションミスを防げる。

ライフサイクル
一定期間経ったオブジェクトをどうするかルールを決めれる。
移行ならIAとかグレイシアに移して安く済ませれる。
失効なら自動削除してくれる。

静的ウェブホスティング
静的なコンテンツ(掲示板のように変化のあるものじゃなくて、いつ開いても同じ結果が帰ってくるサイト)をS3に置くとWEBサーバ要らずにWEBページを公開できる。俺はこれを知らなくて、静的コンテンツなのにわざわざEC2をなんやかんやしてた…悔しい…
サーバーいらずなので最低限のメンテナンスだけで使えるのが強み。
パブリック読み取りアクセス権をつけないと使えないので注意。
HTTPSがつかえないのも注意。
スクリプトは、ユーザー側のスクリプトは含められるけどサーバー側のスクリプトは駄目。

暗号化
3つのサーバーサイド暗号化機能がある(SSE)

  • S3で管理されたキーによる暗号化
    暗号化キーの管理をAWSが行う

  • KMSで管理されたキーによる暗号化
    暗号化キーの管理にKMSを使う。権限制御や証跡が取れる。

  • ユーザーが用意したキーによる暗号化
    暗号化キーの準備及び管理はユーザーが行う。

アップロードしたときに暗号化するデフォルト暗号化オプションでは上2つのどちらかが使われる。

署名付きURL
S3のデータにアクセスする期限を決めたいとき、URLに有効期限をつけれる。期間限定のコンテンツを配信したいときに使う。
署名をつけない場合、期限なし。

その他

クロスリージョンレプリケーション
別のリージョンのバケットにオブジェクトのコピーを自動でとってくれる。コピーは非同期。

S3 object tagging
オブジェクトにタグをつけてくれる。

S3分析-ストレージクラス分析
S3のデータを分析して、より安価なストレージクラスに移行するタイミングをおしえてくれる。Intelligent-tieringと違うんこれ?提案だけで移してはくれないってこと?

S3インベントリ
オブジェクトのリストを定期的にCSV出力してくれる

S3 cloudWatch metrics
S3に対してのリクエスト量とかダウンロード量をcloudWatchで監視できる。

cloudtrailによる監査ログ取得
いつどこから誰がS3の操作を行ったのかというログを収集できる。

S3オブジェクトのアクセス制御

基本的にバケット作成主だけアクセスできる。
誰でもオッケーにしたいなら、パブリックアクセスを有効にする。

IAMポリシーによるアクセス制御
IAMポリシー(ルール)を作成し、IAMユーザーにオブジェクトに対してのread/put/deleteの権限付与できる

ACLによるアクセス制御
バケットそのもの、またはオブジェクト一個一個にアクセス権限を設定する。xml形式。

バケットポリシーによるアクセス制御
バケットそのものに対してのアクセス制御。IPアドレスで制限できたりする。JSON形式

パブリックアクセス
誰でもオッケーにしたいならパブリックにGET権限を付与します。
バケットポリシーを使えばすべてのオブジェクトにパブリックアクセスを設定できる。
ACLでやるならオブジェクトごとにパブリックアクセスを設定できる。
IAMのWEBアイデンティティフェデレーションを使えば、一時的なアクセス権も与えられる。

S3へのアクセス

REST APIを使う。マネジメントコンソールからか、CLIからか、SDKからアクセスできる。

content-MD5による完全チェック
ファイルアップロードの時にハッシュ値確認して、かけたりしてないか確認できる

マルチパートアップロード
一回のアップロードに5GBまでしか行けないので、5GB以上なら分割してアップロードしなきゃいけない。最大5TB。

ランダムなプレフィックス
連続でアップロードすると、同じとこばかり書き込んでると待ちが発生して効率悪いから、ランダムにしてIOのパフォーマンスをあげてる。

制約事項

バケット数は一つのアカウントで100まで。上限緩和申請すればもっとつくることもできる。
また、バケットの名前はかぶっちゃいけないし変更できない。かぶらないようにって変な名前つけると変更できなくて後悔するぞ!
また、バケットを人にあげることはできないです。

次回コンテナへ!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0