これだけは知っておきたい！AWS認定ソリューションアーキテクト アソシエイトの前提知識

# はじめに
先日、AWS認定ソリューションアーキテクチャ アソシエイト(AWS認定SAA)に合格しました！
私が資格の勉強をする際に、そもそもの知識不足で、なかなかAWSの本筋に入れなかったので、この記事ではAWS資格の勉強を始める前に抑えておいたほうがいい知識をまとめてみました。

※ AWS認定SAAを取得するために最低限必要だと思うレベルの記載なので、細かい仕組みは本記事では省いています。

# 本題
## DNSレコード
### そもそもDNSとは…
DNSとは**Domain Name System**の略で、インターネット上でドメイン名を管理・運用するためのシステムで、ドメイン名とIPの名前解決を行ってくれます。
AWSではDNSとしてRoute53というサービスがあります。

### DNSレコードについて
DNSが持っているドメイン名とIPの対応表のレコードそのものを指します。
DNSレコードにはいくつか種類があり、用途が異なるのでまとめていきます。

#### SOAレコード
ドメイン名はその階層構造に従ってゾーンと呼ばれる領域に分割され、各ゾーンごとに管理されています。
SOAレコードは**ゾーンの設定などを記述**するもので、Route53ではドメインを登録した作成したタイミングで自動でレコードが作成されています。

#### NSレコード
**ドメインの情報が格納されたネームサーバを指定する**ためのレコードです。
Route53で作成した場合は、AWSのネームサーバが自動で設定されています。

#### Aレコード
ドメインに対応するIPアドレス（IPv4）を定義し、**ドメインからIPアドレスを解決する**ためのレコードです。
AAAAレコードという、IPv6形式に対応した同種のレコードがあります。

#### PRTレコード
Aレコードの逆で、**IPアドレスからドメインを解決する**ためのレコードです。

#### MXレコード
メール配送先ホスト名を定義するレコードです。メール転送先ホスト名はAレコードで登録しておく必要があります。

#### TXTレコード
ドメインに関連するテキスト情報を記載するレコードです。送信ドメイン認証の認証情報や、ドメインの所有者を明示するために使われます。

#### CNAMEレコード
**ドメイン名の別名を指定する**ためのレコードです。特定のドメインを別のドメインに転送する場合に使用します。

### AWS Route53固有のDNSレコード
#### Aliasレコード
**Zone Apexに対しては、CNAMEが設定出来ません。**
これに対しRoute53は、Aliasレコードという別名機能を使用することで、これを解消しています。AliasレコードではAWSリソース(ELBやCloudFrontなど)のDNS名を設定できます。

※Zone Apexとは、サブドメインを含まないドメイン名のことを指します。”http:/○○○.com/”をルートドメインとした場合に、”http://×××.○○○.com/”の”×××”の部分をルートドメインに対するサブドメインと呼びます。

#### 参考
[DNSとは? 全体像とDNSレコードの種類](https://qiita.com/naoki_mochizuki/items/d90c1fdd5b25c0136a69) 

## 認証/認可プロトコル(SAML,OAuth2.0,OpenID Connect)について
### 「認証」と「認可」
そもそもの、「認証」と「認可」についてざっくり説明すると、

- **認証**…通信の相手が誰（何）であるかの特定をすること(例：認証の結果、Facebookにログインできる)
- **認可**…とある特定の条件に対して、権限を与えること(例：Facebookユーザは投稿を認可されている)

AWSではIAMのIDフィデレーション機能で認証/認可プロトコルがサポートされています。
また、Amazon Cognitoという、認証、認可、ユーザー管理機能を提供するサービスがあります。

#### SAML
「認証」、「認可」を行うためのプロトコルです。
異なるドメイン間で認証情報を連携するために使用します。SAML認証を利用してシングルサインオンを実現でき、1つのIDとパスワードで一度認証を行うことで複数のWebサービスを利用できます。

#### OAuth2.0
HTTP上で「認可」を行うためのプロトコルです。 
第三者クライアントからAPI操作をセキュアに認可する際に利用されます。
（例：あるWebサービスからTwitter連携して「ツイートする」機能など）

#### OpenID Connect
OAuth2.0を拡張したプロトコルで、「認証」のために使われます。
OAuth2.0では標準化されていないUserID情報の取得について標準化されており、Webサービス同士のID連携などに利用されます。
（例：あるWebサービスに「Twitterアカウントでログインする」機能など）

#### 参考
[SAML / OAuth2.0 / OpenID Connect / SSOの関係(細かい仕組みの話は無し)](https://memememomo.hatenablog.com/entry/2018/08/19/125746)

## 多要素認証(MFA)について
多要素認証は、アクセスに必要な本人確認のための要素を、複数種類ユーザーに要求する認証方式です。
例えばAWSでは、Google Authenticatorなどのモバイルアプリを使用してワンタイム認証コードを作成し、二段階認証とすることで安全性を強化できます。
#### 参考
[AWSでMFA(二段階認証)を有効にする方法を超丁寧に説明するよ](https://qiita.com/viptakechan/items/6d19aee635b2ab189e47)


## インメモリデータストア(redis,memcached)
### NoSQL(非リレーショナル)データベースについて
redis、memcachedの前にまずは、NoSQLについてです。
NoSQLとはリレーショナル型DBとは異なり主キー/外部キーのテーブル結合を使用しない、高速でスケーラビリティなDBです。特にビッグデータ処理や、キャッシュDBとして使用されます。
主な特徴として、以下のようなものがあります。

- RDBに格納し辛い、非構造化データを扱うことができる
- 高速に動作する
- スケールアウトしやすい
- トランザクション処理には不向き

また、NoSQLデータベースの種類も豊富で、

- **キーバリュー型** … キー値とバリューを紐づけてデータを管理する (redis,memcached,Amazon DynamoDB等)
- **列指向型** … 列方向のデータのまとまりを格納し効率的にアクセスする (Cassandra,Amazon Redshift等)
- **ドキュメント指向型** … キーに対してJSON/XML形式のデータを格納する (MongoDB,Amazon DocumentDB等)
- **グラフ型** … グラフ理論に基づいて関連性を持たせる (Neo4j,Amazon Neptune等)

といった様々なタイプがあります。
#### Redis, memcachedについて
redis、memcachedはキーバリュー型のNoSQLデータベースです。メモリ上で展開されるため高速処理を実現します。配信量の多いゲーム、SNSや、大量データ処理のスループット改善等のためのキャッキュとして使用できます。また、高速、高可用なNoSQLデータベースとしても使用可能です。
AWSでは、ElastiCacheというサービスでredis、memcachedを使用することができます。
#### 参考
[RedisとElastiCacheを分かりやすくまとめてみた](https://qiita.com/gold-kou/items/966d9a0332f4e110c4f8)

## データウェアハウスについて
データウェアハウス(DWH)とは、基幹系などの複数システムから必要なデータを収集し、目的別に再構成して時系列に蓄積した統合データベースを指します。**主にBI（ビジネスインテリジェンス）ツールと連携してデータ分析や意思決定**に利用されます。
AWSではRedshiftというサービスで列指向型DBのデータウェアハウスを提供しています。
#### 参考
[CRMとデータウェアハウス（DWH）](http://www.advanlink.co.jp/crmconsultation/crm_dwh.html)

## コンテナ技術(Docker,Kubernates)
### コンテナとは
ホストOS上に論理的な区画（コンテナ）を作り、個別のサーバーとして使えるようにしたものです。従来のVM等を利用した仮想化に比べオーバーヘッドが少なく、軽量で高速に動作するのが特徴となっています。コンテナを使用すると、アプリケーションのコードや設定、依存関係を、使いやすい構成要素に容易にパッケージ化できるため、環境の一貫性、運用効率性が向上し、バージョンコントロールが可能となります。これらの特徴により、後述するマイクロサービスアーキテクチャなどでよく使用されます。
#### Docker
Dockerはコンテナ技術のデファクトスタンダードとなっている、**コンテナ実行プラットフォーム**です。
Dockerイメージというテンプレート(アプリケーションコード、構成、および依存関係を単一オブジェクトへパッケージ化したもの)を使用して、コンテナを起動します。
AWSでは、ECSというサービスでDockerコンテナを稼働させる環境と、そのコンテナをスケールするための機能が提供されています。また、ECRという、Docker向けのレジストリーサービスも提供されています。
#### Kubernates　※略：k8s
Kubernates(クーバネティス)は、Dockerコンテナの運用を自動化するツール（**コンテナオーケストレーションツール**）です。
コンテナが増えてくると、デプロイ先の管理やコンテナの監視/復旧作業などをコンテナ毎にやる必要があり面倒です。それを解決するのがKubernatesです。
AWSではEKSというサービスでKubernatesの利用ができます。
#### 参考
[コンテナーとは？ Kubernetesとは？ 導入や運用、ユースケースを解説](https://codezine.jp/article/detail/11336)

## インフラ構成管理、インフラのコード化(IaC)
### インフラ構成管理技術の種類
インフラ管理技術を大きく以下の3種に分類します。

- **Orchestrationツール** …アプリケーションのデプロイ、構築管理
- **Configurationツール** …ミドルウェアレベルの設定、管理
- **Bootstrappingツール** …OS、ネットワークにあたる領域の設定、管理

ただし、この分類は人によって考え方が違ったり、ツールによっては上記の複数の機能をもつ場合もあるため、大枠として考えてください。
#### インフラのコード化(IaC)
Infrastructures as Code(インフラのコード化)とは、上記技術を利用して**インフラの構成情報をコード形式で管理**することです。インフラ構成をコード化することで以下のようなメリットを得ることができます。

- ネットワーク、サーバなどの生成の自動化
- インフラリソースに対して各種ツール・ライブラリのインストール自動化
- 手作業のインフラ構築に比べ、オペミスの危険が少ない
- テキスト形式なので、GitやSVNといったVersion管理が容易

#### インフラ構成管理ツール (CloudFormation,terraform)
AWSのCloudFormationというサービスや、terraform(OSS)といったツールは、Bootstrappingツールに属し、クラウド上に構築するインフラ構成をコード管理できます。
特にterraformはAWS、Azure、GCPなどのプラットフォームをサポートしており、サポートされているプラットフォーム上のインフラの構築/変更/バージョン管理を行うことができます。
#### サーバ構成管理ツール (Chef,Puppet,Ansible)
Chef、Puppet、Ansibleは、Configurationツールに属し、設定ファイルに応じてサーバーの構成管理を行うツールです。
複数のサーバーに対してのアプリケーションの一括デプロイ，アプリケーション構成の定義/管理をする事ができます。
AWSでは、AWS OpsWorksというサービスでChef、Puppetを使用した構成管理ができます。
#### 参考
[オープンソースの運用管理・運用自動化／Terraformとは](https://www.ossnews.jp/oss_info/Terraform)
[AnsibleとChefとPuppetの比較](https://macruby.info/windows/ansible-chef-puppet-compare.html)
[インフラ系技術の流れ ](https://mizzy.org/blog/2013/10/29/1/)

## ストリーミングデータとストリーム処理について
### ストリーミングデータとは

- 大量のデータソースから急速かつ継続的にデータが生成される
- 時間の経過によりデータ性質・傾向・価値が変動する

といった特徴を持つデータです。ビッグデータとしてよく語られているイメージがあります。
### ストリーム処理とは
ストリーミングデータをリアルタイムで処理することです。対義語としてバッチ処理があります。
AWSではAmazon Kinesisシリーズというサービスでストリーム処理をサポートしています。
#### 参考
[ストリーミングデータとは(AWS公式サイト)](https://aws.amazon.com/jp/streaming-data/)

## 分散処理について(Hadoop,Spark)
### 分散処理とは

- 大量データ処理などをネットワーク接続された複数のコンピュータを用いて同時並列で処理する
- 安価なサーバを複数台用意して処理を割り振れるので費用を抑えることが可能

#### Hadoop
Hadoopは、大量のテキスト/画像/ログなどの構造化されていないデータを、高速に処理出来る分散処理用のプラットフォームです。ゼロから分散処理を実現するには相当な体力がかかるため、こうした分散処理基盤を導入することで、低コストで大量データ処理システムを構築できます。
#### Spark
Sparkは、Hadoopと同じく、大規模データを分散処理するためのプラットフォームです。
Hadoopとの大きな違いは、「オンメモリで動作するため、より高速に処理が可能」な点で、リアルタイムにデータを解析する要件などで利用されます。
#### 参考
[Hadoopとは](https://www.techcrowd.jp/bigdata/hadoop/)
[Apache Sparkを勉強して分散処理できますよ！って言えるようになる](https://qiita.com/rtoya/items/d80e59371832877fbbb1)

## Pub/Sub処理モデルについて
### Pub/Sub処理モデルとは
非同期メッセージング処理の一種であり、メッセージの送信者（パブリッシュ）が特定の受信者（サブスクライブ）を想定せずにメッセージを送る処理です。
バックエンドアプリケーションへの処理の割り当て、イベントに関する統計の収集などに利用できます。
AWSではSNSというサービスを利用してPub/Sub処理を実現できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/331794/1f376a90-c800-71d4-eaaf-cffaa3633006.png)

#### 参考
[Pub/Subメッセージングモデル](http://itdoc.hitachi.co.jp/manuals/link/cosmi_v0870/APKC/EU070377.HTM)

## アプリケーションのアーキテクチャ
### マイクロサービスアーキテクチャとは
- システム全体の個々の機能をサービスとして切り出し、サービス同士をAPIなどで連携することでシステム全体を構成する、疎結合なシステムアーキテクチャ
- 1つの機能を、前述したコンテナとして構築し、Kubernatesで運用することで、可用性向上・独立開発・影響範囲の局所化などが期待できる。
- 対義語として、システム全体がモノリシック(一枚岩の)アーキテクチャがある。

### サーバレスアーキテクチャとは

- サーバー上の常駐プロセスを使用せず、イベント発生をトリガーにアプリケーション実行環境を立ち上げて処理を行うアーキテクチャ
- 主に**FaaS（Function as a Service）型のサービス**を利用して構築する
- FaaS型サービスは実行環境の確保、スケール、管理をサービス提供者側が自動的に行うため、開発者は開発に注力可能になる。
- FaaS型サービスは、イベント発生をトリガーにアプリケーション実行環境を立ち上げ、指定したプログラムが動いている間のみ課金が行われる。

AWSでは、LambdaなどのFaaS型サービスを利用して実現することができます。
#### 参考
[マイクロサービス アーキテクチャとは](http://album.cloudit.co.jp/?p=5212)
[サーバレスアーキテクチャとは何か？](https://codezine.jp/article/detail/10332)

# 最後に
本記事では、ざっくりベースで各用語や概念についてまとめたので、一部正確ではない表現もあります。資格目的の知識としては問題ないと思いますが、これを実施に使って深掘りしないと、頭でっかちなエンジニアになってしまいそうです。。。
私も実際に使ったことのない技術はたくさんあるので、スキルとしてに叩き込みたいと思います。