AWS学習履歴の趣旨
AWSでデプロイをしたことはあるものの、AWSの理解に足りない部分があるのが悔しいと思い、UdemyのAWS講座で勉強を開始しました。
以下の記事の続きです。
学習内容を全て残すことは量が莫大になるので無理ですが、『重要かな？と思った部分を記録として残そう！』というのが趣旨です。
更新頻度は不定期ですが、地道に続けていこうかと思います。
応援よろしくお願いします。
Reliability（信頼性）の確保
Well Architected Frameworkのうちの一つです。
重要な点は2点です。
- 耐障害性の向上
- 高可用性の確保
耐障害性の向上
障害による中断・停止とそこからの復旧による影響を軽減させることです。
- 別リージョンや別AZにバックアップを取得管理
- 別リージョンや別AZにスタンバイ構成をとり、即座にフェイルオーバー（あるシステムに異常が発生した時、自動的に冗長なシステムに切り替えること）できるようにする
- BCP（事業継続計画）を整備し、バックアップからの復元やフェイルオーバーなどの手順を検証する
これら3点が耐障害性の向上の基本になる。
高可用性の確保
高可用性とは、なるべくダウンタイムをゼロにすること。
この2点が基本になる。
関連するベストプラクティスは「単一障害点の排除」であり、このためにELB(Elastic Load Balancing)が用いられる。
EC2だけでなくDBも同様に設計する必要があり、例えばマスターDBのコピー（スレーブ）にレプリケーションを常にとり、マスターがダウンしても自動でフェイルオーバーするように設計するなど。
EC2に対しては、ElasticIPをインスタンス障害時に同じパブリックIPをもつインスタンスにフローティング（別の代替サーバーにIPを移す）などして対策もできる。
ELB
EC2インスタンスの処理を分散させるものです。
ヘルスチェック（インスタンスの正常・異常をチェック）して、異常なインスタンスを認識し、そちらにトラフィックを回さないなどもできます。
また、ELB配下のインスタンスの負荷に応じてインスタンスの負荷分散（トラフィック量を分散させる）ことも可能です。
ELBを用いて、ベストプラクティスの1つスケーラビリティ（需要変化に対応させる）を確保します。
Auto-Scaling
スケーラビリティの確保に重要になるサービスです。
サーバーへの需要変化に応じて、インスタンスをスケーリングする機能です。
スケーリングには以下の2つがありますが、Auto-Scalingは「水平スケーリング」です。
- 垂直スケーリング：メモリやCPUの追加・増強（スケールアップ）/削除・低性能化（スケールダウン）
- 水平スケーリング：処理する機器/サーバー台数の増加（スケールアウト）/低減（スケールイン）
例えば、ELBで需要の負荷分散はできますが、分散させても処理できるトラフィック量を超えてしまう場合に、新しいEC2を立ち上げることが可能です。
逆に、需要が減った場合に不必要なインスタンスを削除することも可能です。
RDS
様々なデータベースソフトウェア（MySQL, ORACLE, ..etc）に対応したリレーショナルデータベース。
AWSでのデータベース構築は以下の2つのやり方がある。
- EC2に自らインストールする
- 専用DBサービス（RDS等）を利用する
「1. EC2に自らインストールする」場合は、自由なDB構成や機能を利用できますが、構築・運用の手間が多くなります。
「2. 専用DBサービス（RDS等）を利用する」場合は、構築・運用はAWSが大部分をになってくれますが、AWSの機能範囲内でしかソフトウェアを使うことができません。
RDSでは、高可用性の確保で例にだしたマスター・スレーブ構成の構築が簡単です（同期レプリケーション・自動フェイルオーバー）。
さらに、非同期レプリケーションでリードレプリカ（参照専用：データ読み取り処理スピードを向上できる）を設置できます。
また、Snapshotによる耐障害性の確保もできますし、マスターを複数構成にしてRDSの書き込み処理もスケーリング可能です（データベースシャーディング）。例えば、ID：0~100はこっちのRDS、ID：101~200は違うRDSなどと、ユーザーIDに応じてアクセス先を変えることも可能です。
次の記事へ
