4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

1ヵ月で取得するAWSソリューションアーキテクト (3日目)

Last updated at Posted at 2016-09-14

概要

3日目ですね。

果たしてこのスケジュール感で1ヵ月間に合うのか?
これは試験対策になるのか?

…なんて自分の心の中の声も聞こえてきますが、一切無視してこのまま進めます。
2日目に書いたAWSの全体像に関して続きをまとめていきます。

AWSの全体像

◆ストレージ & コンテンツ配信

1.S3(Simple Storage Service)

S3って何の略なんだろって思ってましたけど、意外に単純なんですね…
SAN Solid State Storage(S4か…)とか勝手に想像してました。

そして、肝心の何が出来るのかということですが…
これは一応、資格の勉強でもあるのでさくっと振り返ります。

基本はストレージとして機能し、バケットというデータを保存するための器を作成し利用する。

色々と応用して使用することも出来るようでS3をPost先に指定したフォームを作成すれば
S3上にアプリケーション利用者のローカルファイルをアップロードできたり、
CloudFrontと連携させればCDNを使って世界中のどこからでも
高速にアップロードしたファイルにアクセス可能になるとのこと。
(まったくどこまで本当なんだか…)

まぁ、連携に関してはこれから調べていくとして、利用料金の計算方法は…

(1)容量
(2)転送量
(3)アクセス回数

…だそうで、謳い文句は「SLA99.9%(※条件があります)、耐障害性99.999999999%(イレブンナイン)のサービス」だそうです。
(こんなの本当に試験に出るんすかね…)

もう、なんだかS3はこの位にしておきます。

※ちなみにS3のボリュームをOSにマウントすることは出来ないそうです。

2.CloudFront

名前がかっこいいですね!で一体何なんですかね…

世界中にあるAWSサーバの力を駆使し、実現している高速・高パフォーマンスなCDNってことらしいです。
ファイルを保存したサーバ(オリジンサーバ)からユーザー最寄りのエッジサーバへ配信することで実現しているようです。
高速で配信できる理由としては世界中のサーバを駆使していること、キャッシュを利用して負荷を減らしたりすることで実現しているようです。

ちなみに前述している通り、S3上のデータをCDNの対象として選べるようです。

ここで覚えておく言葉は「ディストリビューション」という言葉でしょうか。
CloudFrontの各設定は「ディストリビューション」でまとめられるそうです。

3.Elastic File System (EFS)

最近(2015年)、発表されたサービスのようで…
要はファイルサーバなんですが、ただし、ただのファイルサーバではないようです。

EC2インスタンス上のOSにマウントさせるEBS(Elastic Block Store)とは異なり、
複数サーバでのファイル共有が可能になっているとのこと。

特徴としては以下の点が挙げられます。

[1]ファイルの追加/削除に伴い、自動で容量を拡張/縮小する
[2]SSDベースになっている(高いIOPS ※1と低レイテンシを提供する)
[3]ペタバイト(テラバイトのさらに↑)規模での利用を想定し設計されている
[4]高可用性、高耐久性のため複数AZ(※2)間でレプリケーションされ、複数AZからアクセスできる
[5]APIアクセスがIAMで制御できる
[6]API、コンソール、コマンドラインで操作できる

(※1) IOPS = Input/Output Per Secondの略。
ある条件の元、ハードディスクなどの記憶装置に1秒間に読み込み・書き込みできる回数のこと

(※2) AZ = アベイラビリティーゾーンの略。
また、別日に整理しますがAWSにはリージョンとアベイラビリティーゾーンという概念があります。
そして、AWS内の1つのリージョンには複数のアベイラビリティーゾーンが存在しています。
AWSのインスタンスはアベイラビリティーゾーン内で起動されます。

参考:リージョンとアベイラビリティーゾーン
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

ちなみにEFSはWindows Server 2012では利用できないようです。

少なくとも「NFSクライアント」の機能を有効にして、
「mount」コマンドを実行しても使えないそうです。
(本当かどうかも分からんのであえてソースのページは公開しません)

どうやら、Microsoftは対応していると言っているのに…

ちなみにNFSv4.1 Client for Windowsというものがあるそうで、
それをうまく使えるならワンチャンスあるのかもですね。

4.Amazon Glacier

グラシア…と読むのでしょうか…
こちらはAmazon様のお言葉を拝借します。

データのアーカイブおよび長期バックアップを行うための、
安全性と耐久性に優れたきわめて低コストのクラウドストレージサービスです

ストレージのサービスだが、アーカイブ用のストレージサービスとのこと。
一体、通常のストレージサービスとは何が違うのでしょうか?

以下が違いとして挙がるようです。

[1]ファイルの取り出しに時間がかかる
[2]値段が安い
[3]ファイル名がつけられない

例えば、比較対象としてS3を上げると

[1]ファイルの取り出しに時間がかかる
S3の場合: 即時
Glacierの場合: 4~5時間

[2]値段が安い
S3の場合: 10円/1GB
Glacierの場合: 1円/1GB

[3]ファイル名がつけられない
S3の場合: 任意
Glacierの場合: アーカイブID(自動採番)

データの堅牢性、耐障害性(イレブンナインだとか何とか…)はS3と変わらないようです。
まさに大容量のデータを長期にわたって保管するアーカイブ向きのサービスですね。

5.Import/Export Snowball

これも最近(2015年)に発表されたサービスのようです。
それにしても、なんで「Snowball」なんですかね、雪玉?

しかし、この雪玉はすごいサービスでAmazon様の言葉を拝借すると…

Snowball はセキュアなアプライアンスを使用したペタバイト規模の
データ転送ソリューションで、AWS クラウド 内外に大容量データを転送できます。

ペタバイト!?って

しかも調べてたら、なんかすごい話が見つかりましたよ。

・オンプレミスからクラウドの移行に関する課題:

「ギガビットの回線があっても、100TBのデータを移行させるには、100日間かかる。
 もちろん、コストをかければ、ネットワーク帯域を増強することも可能だ。
 しかし、クラウドに移行するためだけに、それだけのコストをかけられるだろうか?」

①に関してFedexで物理ディスクを運搬するという手段を講じた。しかし、ユーザー自身がディスクを調達し、データを載せ、出荷するという手間がかかる。さらにセキュリティ面での漏えいや人的なミスという課題がある。


50TBの容量を持つAmazon Snowballは、大量のユーザーデータを256ビットで暗号化してストレージに格納。
ユーザーはAmazonの物流を用いて、確実に、迅速にAWSにデータを移行できるというもの。
100TBのデータがあっても、Snowballが2台あれば、1週間でデータ移行が完了できる」

100TBのデータ移行を1週間でって…すげぇな。
でも、あれっ…ちょっと待てよ…物流?

と思って調べてみたら、以下のページにこんなことが書かれてました。

AWS Import/Export Snowball とは、安全な物理的な移動を目的として
設計されたストレージアプライアンスを使用して、
テラバイトからペタバイト規模のデータを AWS から、
または AWS への移動をスピードアップさせるためのデータ転送ソリューション

参考:Snowball リージョンのアベイラビリティ
https://aws.amazon.com/jp/importexport/faqs/#regions

これはどうやら物理的にデータを運搬するサービスのようです。
検索してみたら、いかつい箱の画像が出てきたりもしました。

そりゃ、そうですよね。

6.Storage Gateway

私のITリテラシーが低いだけなのでしょうが、これも文章をパッと見してもイメージ湧きません…

AWS Storage Gateway は、オンプレミスのソフトウェアアプライアンスを
クラウドベースのストレージと接続し、組織のオンプレミスの
IT 環境と AWS のストレージインフラストラクチャ間で
シームレスでセキュアな統合を提供するサービスです。

オンプレ環境とクラウド上のストレージを接続する?
何となく理解できそうな理解できなさそうな…

しかし、以下の言葉を出てきて少し具体的になりました。

①ゲートウェイキャッシュ型ボリューム
プライマリデータを Amazon S3 に保存し、頻繁にアクセスするデータをローカルに保持します。

②ゲートウェイ保管型ボリューム
データセット全体への低レイテンシーアクセスが必要な場合は、
プライマリデータをローカルに保存し、スナップショットを
非同期に Amazon S3 にバックアップする

③ゲートウェイ仮想テープライブラリ (VTL)
仮想テープの無制限のコレクションを作成できます。
各仮想テープは、Amazon S3 によってバックアップされた仮想テープライブラリまたは
Amazon Glacier によってバックアップされた仮想テープシェルフ (VTS) に格納できます。

バックアップの保存先をクラウド上に置き、その中で頻繁にアクセスするファイルは
ローカルに保存したりすることができるわけですね。
(具体的にどうやんのかはさっぱりだけど…)

ただ、S3とかGlacierという言葉が出てきているということは
そちらとオンプレの環境をつなぐ、まさにゲートウェイのような役割を果たすのでしょうね。
(もう、眠い…)

◆総括

全体といいつつ、かなりゆっくりめに各サービスの確認を行っていますが、
明日はネットワーキング、データベース、セキュリティ&アイデンティティの部分を
要点絞ってまとめていってみようと思ってます。

※この分野に関する感想としては、クラウドの概念がより日常的な環境に接近している印象を受けました。
もはや、ローカルのファイルサーバとかクラウドのファイルサーバなどといった概念は関係ありませんね。
あと、バックアップデータは賛否色々とあると思うけど、個人的には下手なオンプレの環境よりはクラウドの堅牢性を信じてもいいんじゃないかなぁと思ってます(イレブンナインか…本当にそう呼んでるのかな?)

4
3
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
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?