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

#概要
5日目、AWS全体像を振り返るの4日目になります。
昨日、投稿ボタンを押し忘れたまま眠りについていたので実質6日目(7日目？)ですが…

##AWSの全体像

###◆データベース(5日目のつづき…)

###3.Amazon ElastiCache

文章の説明だけ読んでもよく分からない感じのタイプですね。
一応、調べてみた結果でどのようなサービスであるかをまとめます。

まず、Amazon様が定義されている内容を振り返ります。

```
クラウドでのメモリ内分散キャッシュ環境のセットアップ、
管理、およびスケーリングを容易に行えるようにするウェブサービス
```

メモリ内分散キャッシュ環境とは具体的にどんな環境なんですかね。

```
このサービスは、パフォーマンスとコスト効率に優れ、
スケーラブルなキャッシュソリューションを提供すると共に、
分散キャッシュ環境のデプロイと管理に伴う複雑性を排除します
```

パフォーマンスとコスト効率、スケーラブルといった言葉は
よくAmazon様がうたわれている文句ですが、
キャッシュソリューションというのは何でしょうかね。

分散キャッシュ環境という言葉も何か分かったような分からないようなそんな感じです。

…というわけで言葉の定義を振り返ってみます。

```
キャッシュ：
頻繁にアクセスするデータを高速な記憶装置に蓄え、
低速な記憶装置から読み出す無駄を省き高速化すること
(出典(参考)：IT用語 e-words)
```

まずは前提として上記の言葉を理解した上で進むわけなんですが、
AWSの話しでも項目がデータベースの話なので、当然分散キャッシュ環境というのは
データベースに保存するデータをキャッシュさせる話になります。

そもそも、なぜデータベースのキャッシュデータを分散して保存する必要があるのでしょうか。
そりゃあ当然、キャッシュできたほうが出来ないよりは良いに決まっているのですが…

Webアプリケーションはデータベースにデータを保存するわけですが、
アクセスするデータが大量だったり、アクセスが集中してしまうと
データベースの負荷があがり、データベースの処理が遅くなることにより、
連携しているWebアプリケーション側の処理が遅延する等の影響があります。

そして、上記を踏まえた上で分散キャッシュ環境に戻ってきますと…

```
分散キャッシュ環境：
以下、memcachedという分散型メモリキャッシュシステムを例にします。

複数のmemcachedサーバに対し、KVS※という方式を用いて、
独自のアルゴリズムによりデータを分散して保存します。
memcachedサーバの機能で分散させる先のサーバを決定するのではなく、
クライアントライブラリ(Perl)を用いて決定している…とのことです。

保存するKVSが分散されることによって1台のサーバで障害が発生したとしても、
他のキャッシュには影響を与えずにシステムは動き続けることができる。

※KVS = キーバリューストアの略。保存したいデータ（value）に対して、
　対応する一意の標識（key）を設定し、ペアで保存する。
```

なるほど…要はキャッシュデータの引出し先も分散させることによって、
可用性も高めつつ、高速処理を実現させているわけですね。

やっと、前段のお勉強が終わってAWSに戻ってこれます。

Amazon ElastiCacheでは以下のオープンソースキャッシュエンジンをサポートしているそうです。

```
(1)Redis
高速のオープンソースのメモリ内データストアおよびキャッシュ。
Amazon ElastiCache for Redis は Redis に対応したメモリ内サービスで、
Redis の使いやすさと能力を引き出すとともに、要求の厳しい用途に適した可用性、
信頼性、およびパフォーマンスを提供します。
ElastiCache for Redis は完全に管理され、拡張性があり、
安全であるため、ウェブ、モバイルアプリ、ゲーム、アドテクノロジー、
IoT などの高いパフォーマンスが必要な用途に最適です。

(2)Memcached
幅広く採用されているメモリオブジェクトキャッシュシステムです。
ElastiCache は、Memcached に準拠するプロトコルです。
そのため、既存の Memcached 環境でお客様が現在使用しているツールは、
サービスでシームレスに機能します。
```

Memcachedは前述した通りの仕組みで分散していますが、Redisはメインメモリ上に
KVSを構築させて外部プログラムからの保存と読み込みを実現させているようです。

どちらのほうが自分が構築しようとしているサービスに適しているのかは
以下のAWSドキュメントに記載されています。

エンジンの選択: Memcached または Redis
https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/SelectEngine.Uses.html

###4.Amazon Redshift
データウェアハウスです。

偉そうに言いましたが、実はデータウェアハウスって言葉を分かっていません…
というわけでこちらの定義も振り返っておきます。

ウェアハウスという言葉自体は「倉庫」という意味を持つ英単語です。

以前から仕事のいろんな場面で聞く言葉ですが、要はデータベースでしょ？位に
自分の中で勝手に考えていました。

データベースとデータウェアハウスとの違いは何なのでしょうか？
色々と情報を調べてみましたが総合すると以下のような形に落ち着きました。

```
様々なシステムのデータをテーマに沿って整理し保存されたデータベース。
データベース内のデータは発生した時系列に記録されていき、更新や削除などの処理は行われず、
横断的に扱うことができ過去のある時点の個別データを参照できるように保存される。
```

上記が一般的なデータウェアハウスの定義であるとするならば、
AWSのデータウェアハウスと一般的なデータウェアハウスの違いとは何なのでしょうか。

ここでAmazon様のお言葉を拝借致します。

```
高速で管理も万全な、ペタバイト規模のデータウェアハウスサービスです。
シンプルで費用対効果の高いサービスを実現し、
既存のビジネスインテリジェンスツールを使用して、
すべてのデータを効率的に分析できます
```

なるほど、またペタバイトですね。もういい加減聞きなれましたよ。

「シンプル」という言葉がついた時点で今までの傾向からも
想像できますが以下の要素が入っています。

①高速
 ・I/Oの高速化(クエリ応答の高速化)
 ・スケーラブル(必要な容量に自動で最適化し処理が高速化される)

②シンプル
 ・フォールトトレラント※1 (クラスター)
 ・自動バックアップ

③安全性
 ・暗号化
 ・ファイアウォール(VPC ※2のなかで実行可能)

※1 フォールトトレラント
システムの一部が故障、停止しても予備の系統に切り替える等して機能を保ち、
正常に稼働させ続けることを目的とした設計の考え方

※2 VPC
次の記事で内容に触れます。

まぁAmazon様らしいお言葉でまとめられている文章ですが、
ビジネスインテリジェンスツールとは何のことでしょうか。

これはe-wordsから説明を抜粋致します。

```
BIツール(Business Intelligence tools) 
BIツールとは、企業の業務システムの一種で、業務システムなどに
蓄積された膨大なデータを蓄積・分析・加工し、意思決定に活用できるような形式にまとめるもの
出典：IT用語時点 e-words
```

ちなみにこのビジネスインテリジェンスツールはAmazon独自の何かが提供されているのかと
調べてみたところ、そんなことはありませんでした。

サードパーティーソフトをAmazon Redshiftと連携できるようにされているようです。
ちなみにAmazon様が公式に認定されているパートナーは以下に記載されています。

Amazon Redshift パートナー
https://aws.amazon.com/jp/redshift/partners/

5.DMS(マネージドデータベースマイグレーションサービス)
その名の通り、データベースの移行をサポートする機能のようです。

そういってしまうと身も蓋もない感じになってしまいますが、
説明を聞く限り、AWS上でデータベースの運用をするという前提であればとても便利です。

例のごとく、低コストに加え、スケーリングや冗長化を自動で行ってくれるだけでなく、
オンプレ → AWSへの移行を行え、異なるプラットフォーム間の移行もできるということです。

異なるプラットフォーム間というのは…
MSSQLServerからMySQLといった商用データベースから
オープンソースデータベースへの移行といったことも可能です。

サポートされるデータベースの種類は以下のようです(2016/9/18日時点)

(1)Oracle
(2)Amazon Aurora
(3)PostgreSQL
(4)MySQL
(5)MariaDB
(6)SAP ASE
(7)Microsoft SQL Server

実際にどのように行うのかは詳細を調べてみないとですが…
事実上ダウンタイムなしの移行を実現できるそうです。

「事実上」ってなんですかね…
理論的にはダウンタイムはないはずだが、実際はやってみないと分からないと言ったところでしょうか…

Amazon様が言っておられる理論としてはデータ移行中の移行元となるデータベースに
行われる変更を移行先となるデータベースに継続的にレプリケートする仕組みで実現し、
移行中も移行元のデータベースに対して利用可能な状態が保たれるためだそうです。

まぁ、理屈では何とでも言えますからね。実際のところはどうなんでしょうか。

###◆総括
2日(本当は3日)に渡って確認したデータベース機能ですが、
Amazon様の掲げている理論が上手く回るのであれば、
すごく便利なサービスですし、管理コストは大幅に削減されるでしょうね。

理屈通りならデータベースメンテナンス専門にエンジニアの方を抱えなくても
ある程度、知識を持ったエンジニアがいれば運用することができるはずですが…

果たして現実はどうでしょうか…
何か予期しないトラブルが発生し、あまりデータベースに詳しくない人が
徹夜で原因の切り分けをしている姿が目に浮かぶのは私だけですかね。

ただ、データベース機能全体を通じてAWSは透過性を高める試みが強い印象を受けました。

```
アプリケーションやプログラムの開発者がメンテナンスや環境の違いを意識せず、
より開発に打ち込める環境を作る。
```

アプリケーションを利用するエンドユーザーに関係するのはElastiCacheですが、
それもバックエンドの機能であり、要は従来は専門のエンジニアを抱えて
実現しなければならない部分をAWSが自動的にやってくれる。

それはAWS全体で言えることだと思っていますが、特にデータベース機能では
システムインフラの構築を簡素化・自動化しようとしているなと感じました。

こういったサービスが将来、より改善されて便利になっていくのだとすれば、
インフラエンジニアの需要は低くなり…