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

#概要
4日目、いよいよAWS全体像を振り返る最終日です。

まぁ、全体像といってもコンピューティング、ストレージ、
データベース、ネットワークの4つまでですが…

##AWSの全体像

###◆データベース

1.RDS

これはとても分かりやすいです。
クラウド上でリレーショナルデータベースのセットアップ～運用することができる代物。
データベースのスケーリングやチューニングを自動的に実施してくれます。

![image](https://qiita-image-store.s3.amazonaws.com/0/138274/c80f8e49-77e8-429b-3352-acfa3deb997f.png)

ところでデータベースのスケーリングというのは具体的に何を意味するんでしょうかね…
ちょっと気になったので調べてみましたよ。

まず、スケーリングという言葉ですが、以下はIT用語辞典 e-wordsよりの抜粋です。

```
対象の規模に応じて増減する、拡大・縮小する、などの意味を持つ英単語。

情報システムの分野では、装置やソフトウェア、システムなどの性能や処理能力を、
要求される処理量に合わせて増強したり縮減したりすることをスケーリングという。

処理能力を増強する際に、単体の性能を向上させることを「スケールアップ」
あるいは「スケールイン」、（サーバなどの）稼働数を増やして処理を分散し、
全体として処理能力を高めることを「スケールアウト」という。

出典：IT用語辞典 e-words

```

つまり、一つのことを意味するのではなく、「スケールアップ」と「スケールイン」と
状況に応じて柔軟に処理能力を合わせることを指すようですね。

上記のように明確に定義されていれば分かりやすいのですが…
色々と調べていると以下のような記載が見つかりました。

```
Scaling is specialization.
スケールさせるとは、何かに特化するということだ。
                         —Joe Stump, Lead Architect of Digg.com and SimpleGeo.com
```
上記はDigg.comというソーシャルニュースサイトのJoe Stumpという人の言葉だそうです。
couchDB(カウチデービー)のDefineGuideに記載されていました。

具体的にはということでFacebookとflickrを引き合いに出しています。

Facebookには大量のユーザーデータがあり、ユーザーデータに対して
「スケールアップ」したいこう思っているだろう。

しかし、flickrは画像データのストレージを「スケールアップ」することが
発展の近道となると考えているかもしれない。

つまり、スケーリングという言葉はそのシステムに適用した形でなければ、
意味をなさない言葉なのかもしれませんね。

そして、話は戻ってきてDBにおけるスケーリングというのは何なのか？

色々と考え方によって定義が変わってくるようですが、
対象となるのは基本的には以下の要素になりそうです。

・書き込み／読み込み要求
・データの保存量

書き込み／読み込みというのはデータベースの種類によって処理が変わってしまうので
一概に何を処理するという尺度ではかることはできないでしょう。

でも、「スケールアップ」という意味で言えば処理用のサーバを増やすということになるでしょう。
RDSはクラウドサービスなので、コンピューティングパワーを増やすという言い方なのでしょうか。

保存量が増えるということに関してはスケールを大きくするというのはイメージしやすいですね。

これらを自動的に調節してくれるのがRDSというサービスなわけですね。

つまりFacebookであれば、ユーザー用のテーブルに対して処理を早くしたり、
保存できるデータ保存量の絶対値を増やしたりと自動的に行ってくれて、
flickrであれば、画像用のテーブルに対するデータ保存量の絶対値を自動的に増やすわけですね。

そして、不要なところに不要なリソースを使わないようにしてくれるので
お金にも優しくなるというわけですね。

つまりそれが費用対効果に優れた拡張機能を提供し、面倒なDBの管理タスクを自動的に実施してくれて、アプリケーションの開発に専念できるというわけなんですねぇ…

ではこれらを踏まえた上でRDSというのは具体的に何を提供してくれるのか…

選択できるDBのインスタンスは以下になるようです。
MySQL、MariaDB、PostgreSQL、Oracle、Microsoft SQL Server、MySQL と互換性のある新しい Amazon Aurora DBというの使用できるようです(2016/9/16日時点)

そして、上記のインスタンスはAWSの基本概念であるAZ内で起動される…ようです。

![image](https://qiita-image-store.s3.amazonaws.com/0/138274/b77160c1-0d8e-c88e-b869-4b1c05870e83.png)

2.Amazon DynamoDB

出ましたNoSQLですね。

4年前位ですかね…夜な夜なSQL文を書いている私の姿を見た父親が
「Amazonはいま、NoSQLっていうのを使い始めて、BIGデータを高速に処理する試みをしてるんだ」

はっきし言ってなんのこっちゃ、でしたね。
だから、どうしたこっちはSQL文を書かなきゃならないんじゃい。
ストアドプロシージャを作らにゃあならんのじゃい。と

まぁ、有名なサービスのようなんですが、そもそもNoSQLという存在がよく分からないです。
というわけでNoSQLというのを調べてみましたよ。

これはWikipedia様のお言葉ですが、

```
NoSQL（一般に "Not only SQL" と解釈される）とは、
関係データベース管理システム (RDBMS) 以外の
データベース管理システムを指すおおまかな分類語である。
出典：Wikipedia
```

ふ～ん、あ～そうなのね…
…ってそりゃあそうでしょ！

タイトルでSQL使わないって言ってるんだから、そりゃあ分からんちんな俺にも想像つくよ！
しかし、そこはWiki様、ちゃんと続きが書いてありました。

```
NoSQLのアーキテクチャにおいては、結果整合性のみを保証するなどして
一貫性の保証を弱く設計したり、トランザクションを
ひとつのデータアイテムに限るという制限を設けたりすることが多い。
補助的なミドルウェアの層を付加することによって完全なACID保証を提供している場合もある
出典：Wikipedia
```

上記を読んでみると少しイメージがわいてきましたね。
RDBMSでは整合性が取れた状態でデータが保存されるように設計されていますし、
トランザクションも複数のしかも大量のデータに対して行われます。

しかし、上記を読んでみるとどうやらそういうものではないらしい…
データをいっぱい保存する代わりに何やら制限を行うようですね。

それとACID？ってなんだ？？？？

また、調べないといけないですねぇ…
AcidBlackCherryのことなんでしょうか？

ってわけで調べてみましたよ。

ACID:

原子性（英: atomicity、不可分性）
一貫性（英: consistency）
独立性（英: isolation）
永続性（英: durability）

上記、英語の頭文字を1文字ずつ取っているとのことです。
信頼性のあるトランザクションが持つべき要素として定義されているようです。

===

原子性 = 不可分操作(アトミック操作とも呼ばれる)のこと。

一つの処理における全操作が完了するまでの間はアクセスできない、
一部の操作に失敗した場合は操作を行う前の状態に戻ることを保証すること。

Mutex ※などの排他制御により実現する要素。

※同時に1つのタスクしかクリティカルセクションに入ることを許さなくする
　クリティカルセクションとはプログラム上、複数の処理が同時並行に行われると
　処理の破綻をきたす恐れがある領域のことを指す

===

一貫性 = データの整合性のこと。

トランザクションの開始時点で判明している整合性条件を満たすように処理が行われること

===

これは調べていて、諸説色々と見つかったので真偽が定かではないのですが…
私の中で以下のようなものであると判断しました。

独立性 = トランザクション中に行われる過程が見えず、他の処理の干渉を受けないこと

===

永続性 = トランザクションが完了し、結果が保存され、失われない状況となること

===

まぁ、これらを踏まえてNoSQLに戻ってきますと…
NoSQLというのは「大容量のデータを扱えますが、処理に関しては最低限の保証しかできない」
…といったイメージなのでしょうか。

ちなみにNoSQLには以下の種類のものがあるそうです。

キー・バリュー型：
キーに対してバリュー(値)があるという超単純な構造のDB。

ソート済みカラム指向 ：
各行ごとにカラムを好きな数だけ保存でき、カラム名によってソートされる

ドキュメント指向：
XMLやJSONのような柔軟なデータ構造を持つDB

どれもイメージはつきにくいですが、強いて分かるという意味で言うと
ドキュメント指向ですかね…

きっと、XMLやHTMLみたいなツリーのような形を伴ったデータの構造を持っているのでしょう。
まぁ、これはそんな感じのSQLを使うことができるようにするサービスというところにしておきます。

※ちなみにDynamoDBはキー・バリュー型だそうです。

![image](https://qiita-image-store.s3.amazonaws.com/0/138274/d85eb2dc-0bf3-dcbb-412c-a9b2628035e1.png)

いやぁ、今日中(…というかタイトルは昨日)に全体像の部分は終わらせたかったのですが、
大分横道にそれちゃいましたねぇ…

こんなんで本当にソリューションアーキテクトの試験に合格できんのか？
そして、何日目までに何が終わるのか見通しはついているのか？

…などとダメなプロジェクトのようなスケジュール感に漂いつつ、
自分でも疑問が濃くわいてきた4日目(5日目)でございました。

続きはまた、明日！