巷ではもうインフルエンザが流行り始めてますが、皆さん体調管理は万全ですか？
ということで、今回はデータベースの様々な特徴について解説したいと思います。
概念的なお話となりますが、サービス運用に関わる重要なポイントなので、しっかり理解してくださいね！
まずは皆さん、「可用性」という言葉は聞いたことありますか？
Wikipediaによると、システムが継続して稼働できる能力。
例えば皆さん、お買い物はネットで決済、なんて当たり前ですよね。
夜中だろうが休日だろうが、いつでもお買い物ができる。そして、デパートのように台風が来たら店が開かない、なんてこともありません。
そう、いつ何時でもサービスが使えることを「可用性」と言います。
そしてAWSのサービスでは、この可用性を担保する様々なオプションが用意されています。

まず前回構築したRDS。RDSは以下のように二つのアベイラビリティゾーンにDBが用意されます。

それぞれプライマリ、スタンバイDBが作成され、通常は更新も参照もプライマリDBがアクセスされます。
そして更新は即座にスタンバイにも反映されるようになっています。
そのため、プライマリDBに障害があっても、スタンバイDBに切り替わり、何事もなかったようにサービスが継続されるのです。
ではもう一つの要素、パフォーマンスについてはどうでしょうか。
デパートではお客さんが沢山来ると、レジで待ち時間が発生します。
レジで並んでいると、目の前の客が商品について文句を言い始めます。それはサービスカウンターでやってよ、って思いますよね・・・
RDSも、基本的にはデータの更新より、参照されるほうが圧倒的に多いです。

そのため、読み取り専用のDB（リードレプリカ）を用意することで、沢山の読み取りでも素早く応答を返すことができます。
データの更新は、プライマリからリードレプリカに伝播します。しかし伝播は非同期に行われ、タイムラグがあるため、参照したデータが必ずしも最新ではない可能性があることに注意が必要です。

さて今回初登場のNoSQLであるDynamoDBはどうでしょうか。

DynamoDBは三つのアベイラビリティゾーンで構成され、更新は同時に二つのDBに行われ、三つ目は非同期に伝播されます。
そのため、RDS同様、タイミングによって読み込んだデータが最新ではない可能性があります。

これを「結果整合性」と呼びます。
DynamoDBでは、常に更新されたデータを読み取れるよう、更新が全てのDBに行われているかを確認してから結果を返すオプションがあります。これを「強力な整合性」と呼びます。但し当然ながらパフォーマンス低下が発生します。
ここで重要なのは、業務要件が何を最も重視しているか、ということです。
パフォーマンスがいいに越したことはないですが、「いつでも最新のデータを返す必要がある」要件であれば、強力な整合性を選ぶ必要がある、ということです。

ちなみにこの整合性は、ストレージサービスのS3にもあてはまります。

S3もバケットは複数のアベイラビリティゾーンに複製され、結果整合性モデルとなっています。

そして最後に紹介するのは「Redshift」。
Redshiftは、大量のデータを分析するためのデータウェアハウスです。
データを単純に溜めるだけのデータベースとは毛色が異なりますが、こちらも必ず回答の選択肢で見かけるサービスです。
大容量のデータを複雑なSQLで分析する必要があるときは、迷わずRedshiftを選びましょう。
逆に、継続的な書き込みや更新には向かないので、そのような要件ならRDSとなります。

このように、何を実現したいか、何を重視するかでどんなデータベースサービスを選ぶかを問われる問題が多いので、各サービスとオプションの特徴をしっかりおさえて下さいね。

さてこのAWS認定資格を取ってみる企画も、残すところ二回となりました。
次回はこれまた重要なオプションのAuto Scalingと、出題数は少ないものの頻出であるサービスについて解説したいと思います。
そして最終回は模擬試験など、受験に向けての対策をご紹介しますので、お楽しみに！

すっかり朝晩冷え込む季節になりましたが、風邪等引かず勉強頑張ってますか？
今回からデータベース（DB）のお話をしたいと思います。
DBも、有名なOracleやMySQLなどのRDSから、NoSQL型のDynamoDB、そしてDBに分類するか微妙ですが、データウェアハウス系のRedshift等、色んなサービスが用意されています。
AWSのデータベース
とあるデータ処理のサービスを実現するのに最適なDBはどれが、的な問題が多く出題されます。
サイズの上限であったり、どんな処理をしたいか。コストは。などなど、要件に最適なサービスを見極めるため、違いをしっかり覚えましょう！
ということで、今回はまずRDSについて。何はともあれまずはDBを作ってみます。
AWSのコンソールからRDSを選択し、「データベースの作成」を押下します。

今回はお試しで、オープンソースDBのMySQLを選択します。

世の中で動いているDBは、24時間365日稼働し続ける必要があるため、可用性が重要になります。
当然、設定が大変なのですが、AWSではそれをテンプレートとして提供してくれます。
当然お金もかかりますので、お試しとして無料利用枠を選択します。

DBインスタンス識別子は、AWS上の管理名です。データベース名ではありません。
ユーザー名、パスワードは接続に必要なので覚えておいてください。

通常は、DBはVPC内のEC2などから接続され、外部から直接接続する必要はないため、インターネットからアクセスできないようになっています。
今回はテストとして、作ったDBにPCからインターネット経由で直接アクセスします。
そのため、追加の接続設定で、パブリックアクセス可能を有効にします。

さらに、追加設定で「最初のデータベース名」に、作成するデータベース名を入力します。
注釈にあるように、データベース名を入力しないとDBはインスタンスが作成されるだけで、DBそのものは作成されません。

これでDBを作成する準備が整いました。DBが作成されるまで数分、とありますが、10分ほどかかるので気長に待ちましょう。

DBが作成されたら、PCからの接続に必要となるエンドポイントとポートを控えておきましょう。
エンドポイントは、DBのアドレスです。ブラウザでネットサーフィンする際のURLと同じですね。
ポートはMySQLのデフォルト値です。

デフォルトのセキュリティ設定では、どこから誰でも接続できるようになってます。
とりあえずこのまま進めます。

早速DBに接続してみましょう。今回は接続のため、フリーのA5MK2というSQLツールを使いました。
ホスト名にエンドポイント、ユーザーID・パスワード・データベースにDB名を入力します。
テスト接続を押し、OKとなれば準備OKです！

無事DBに接続できたら、テーブルを作ったりいろいろ試してみてください。

さて、現状はインターネット経由でこのVPCにいつでも誰でもアクセスできてしまいますので、自分のPCから、MySQLへの接続のみ許可するようセキュリティを設定してみましょう。
※セキュリティ設定も試験に出るので、よく理解してくださいね
まず先ほどのセキュリティ設定画面にて、セキュリティグループを選択します。

インバウンドを選択します。これが、インターネットからこのVPCにアクセスする際の、セキュリティのルールです。
デフォルトは、すべてのトラフィック（どんなポート向けでも）が、すべてのアドレスから接続できるようになっています。

まず、あたなのPCのIPアドレスを調べてみましょう。一般的にはWi-fi等を使っていると思いますので、グローバルIPを調べます。
「IPアドレス調査」などで検索すると、グローバルIPを調べるサイトが出てくるので、アクセスするとあなたのIPアドレスが分かります。

編集を押します。
デフォルトの設定は×ボタンで削除します。
ルールの追加を押します。タイプはMYSQL/Aurorを選択すると、MySQL用のポートが自動で設定されます。
続いてソース、ここが接続元のIPアドレスになります。先ほど調べたアドレスに/32をつけて入力します。
IPアドレスはサブネットマスクで範囲指定しますが、/32とすることで特定のアドレスのみを意味します。

設定を保存し、再度SQLツールで接続できるか確認してください。
また、試しに先ほどのルールでアドレスを適当に変えると、接続できなくなることも確認してみてください。
このように、サービスとセキュリティを組み合わせた問題も頻出ですので、セットで覚えるといいですね！

さて今回も長くなってしまいました・・・次回もまだデータベースが続きますので、頑張りましょう！