AWS Amplifyが扱うAWSサービス

AWS amplifyは、サーバレスにアプリを作成したい開発者向けのフルスタックなフレームワークです
amplifyを使ってアプリを構築する際に、一般的に利用頻度の高いAWSサービスを簡単に紹介していきます

Amazon Cognito

Webアプリといったら、ユーザーの登録・ログインが必要なことが多いですね
ログイン周りは、Cognitoというサービスが提供されています

ユーザー情報の管理、認証・認可の機能を提供するサービス
※認証：ユーザーの身元を確認する（Authentication）
※認可：ユーザーにリソースにアクセスする権利を与える（Authorization）

公式ページは以下https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/what-is-amazon-cognito.html

構成要素は「ユーザープール」「IDプール」の2つ

• ユーザープール
  ここでは、認証機能を提供しています
  外部からのリクエストに対して認証を行い、該当するユーザーだった場合はJWT（JSON Web Token）を返却する流れです

また、ユーザー（ユーザー名、パスワード、メールアドレスなどの情報）を管理します
サインアップやサインイン、MFAの設定、グループを作成してユーザーを采配するなど色々出来ます

• IDプール
  読み方は"アイデンティティプール"
  ここでは、ユーザープールで認証したユーザーに対してAWSサービスへアクセスを認可する機能を提供しています

因みに、Cognitoは、HIPAAやPCI DSSなどのコンプライアンス要件やセキュリティなどに対応してます
※HIPAA：電子化した医療情報に関するプライバシー保護とかセキュリティ確保に関して定めたアメリカの法律
※PCI DSS：カード決済を扱う事業者に求められるコンプライアンスを定めたやつ（EC事業者とか、もろ必須らしい）

Amazon S3

Webアプリを作成する際、画像やCSVファイルなどを保存したい時がありますよね
そんな時はS3が活躍します

公式ページは以下
https://aws.amazon.com/jp/s3/

S3の主な特徴

• 保存したオブジェクト分の支払いとなるため、無駄がない
• オンプレミスの会社ではプロビジョニング作業が必須となりますが、S3の場合は自動で拡張・縮小してくれるため、そこに時間が割く必要がない
• 耐久性と可用性が非常に高い
  • 耐久性
    公式発表では、99.999999999%（イレブンナイン）データロスが発生しないとのこと
    99.999999999%は、1万種類のデータを格納した場合に1種類のデータの消失が発生する確率が100万年に1度のレベルなんだとか
    保存されているはずの画像データがないとなったら、保存するタイミングでエラーが起きた可能性の方が高そうですね〜
  • 可用性
    S3はデータを保存する時に、データをリージョン内のいくつかのアベイラビリティゾーンに複製して格納させます
    どこかのアベイラビリティゾーンが障害を受けてデータが消失してしまったとしても、別のアベイラビリティゾーンが補ってくれます
• バケット名はグローバルで一意でなければならない
  バケットとはオブジェクトの格納場所のことです
  グローバルで一意なため、AWSアカウント、リージョン間関係なく一意です
  amplifyと連携した場合、1アプリに対して、2つバケットが作成されます
  語尾が「development」のバケットはamplifyが自動で作成した、amplifyのためのamplifyしか触らないバケットになります（間違って中身をいじってしまわないよう気をつけましょう）
  もう片方のバケットはストレージとして使われます。直下にはpublicキーが作成されます

Amazon DynamoDB

Webアプリでは、様々なデータを読んだり書き込んだりしたいですよね
データの保存場所として、DynamoDBが活躍します

公式ページは以下
https://aws.amazon.com/jp/dynamodb/

CAPの定理でいうと、AP型データベースに分類されます
※CAPの定理
分散データベースにおいて以下3つの特性のうち、2つの特性を重視すると残り1つは失うという考え方

• Consistency（一貫性）
• Availabiity（可用性）
• Partition tolerance（ネットワーク分離耐性）

DynamoDBは、データを複数のアベイラビリティゾーンに配置し保存することで
Availabiity（可用性）とPartition tolerance（ネットワーク分離耐性）を高めております
複数のアベイラビリティゾーンに配置されたデータをまとめて1つのデータベースとして扱います
同じデータもそれぞれのアベイラビリティゾーンに配置するため、片方が障害が起きたとしても、もう片方のアベイラビリティゾーンのデータで補えるという感じです

それぞれのアベイラビリティゾーンにデータを配置することで
通信エラーやノードの故障が起こってしまった場合に、整合性が取れなくなるケースも発生してしまうためConsistency（一貫性）は劣ってしまいます。

また、DynamoDBはNoSQLデータベースになため、RDBの時では当たり前にできたテーブル間結合などはできません
一応、PartiQLという機能を使えば、RDBの時のようにSQLで問合せすることは可能です
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/ql-reference.html

只、このPartiQLも扱うのに注意が必要です
データ容量が増えてきた状態でインデックスなどを駆使せずにSQLを使うと、テーブル全てをフルスキャンすることになるので、DBにかなり負荷がかかってしまいます

AWS AppSync

Webアプリでは、格納しているデータを効率的に取ってきたいことがありますね
そんな時はAppSyncを利用します。
GraphqlのAPIを作るためのサービスです

https://aws.amazon.com/jp/appsync/

このAppSyncをハブ（中継地点）として、lambdaにアクセスしたりDynamoDBにアクセスしたりできます

GraphQLを開発するため、REST APIで起こる以下の問題が解決できます

• オーバーフェッチング（過剰取得）：不必要なデータまで取ってきてしまうこと
• アンダーフェッチング（過小取得）：1回のリクエストで必要な情報が取れないため複数リクエストが必要
• エンドポイントの管理が大変