AWS SAA 試験準備ワークショップ②
目次
スケーラブルなコンピューティングリソースの識別
垂直スケーリング
必要な時にEC2等のコンピューティングリソース（CPUやメモリ等）の上げ下げが可能になっている。
1台のサーバを大きくする、小さくすることを垂直スケーリングと呼ぶ。
利点
サーバの能力自体がそのまま垂直に上がる・下がるといったことをする為、中のアーキテクチャがクラウド特有 （水平スケーリング） に対応していない形で書かれていても、純然たるサーバの能力を上げる・下げるだけなので対応することが可能になる。
欠点
Java等のアプリケーションを実行している場合で、大量のヒープメモリを使用している場合、ガベージコレクションの時間が長くなってしまうなどが挙げられる。
垂直スケーリングをおこなう際には、EC2インスタンスの再起動が必要になってくる。
水平スケーリング
1個のサーバの処理能力を上げる・下げるのではなくサーバの台数を水平方向にどんどんどんどん増やしていこう、足りなければサーバを増やしていき、過剰であればへらしていくことを水平スケーリングという。
Amazon EC2 Auto Scaling
サーバをデブロイする削除するサービス。
CPUが何十%を超えたら自動的にスケーリングする等。
- EC2 Auto Scalingグループの管理とスケールのみ必要な場合に使用。
- EC2フリートの正常性維持のみに関係する。
AWSでは、特定アプリケーションを実行するために用意されたインスタンス群のことを フリート と呼び、状態を監視することで可用性の維持が期待できる。
AWS Auto Scaling
こちらは、AWS EC2に限ったスケーリングではなく、EC2のオートスケーリンググループ、ECS、、Aurora、DinamoDB等のサービスと連携して必要なキャパシティの変更が可能。
複数のサービスにまたがってスケーリングを管理したい場合に使用する。
Amazon CloudWatch
いつオートスケーリングをするか否かを管理することができ、AWSリソースのCPU使用率やネットワーク等をモニタリングすることができる。
モニタリング方式
- デフォルトのモニタリング
AWS標準のモニタリングを指す。
AWSが標準でデータを収集してくれるものとなる。
- カスタムメトリクスによるモニタリング
ユーザがCloudWatchの大して何時何分何秒にこのデータのメトリクスがいくつかのデータを渡すことによりユーザが定義したカスタムメトリクスを保存することで、CloudWatch上において見ることができる方式を指す。
ELB（Elastic load Blancing）
ELB配下に対して複数のサーバを配置することによりアクセスを分散させることができるので負荷対策に繋がり、これらのサービスを使うことで自動的にスケーリングすることが可能。
パフォーマンスとスケーラブルなストレージソリューションの選択
EBS（Amazon Elastic Block Store）
- 汎用SSD（gp2）
- プロビジョンドIOPS SSD（io1）
- スループット最適化HDD（st1）
- ゴールドHDD（sc1）
ゴールドHDD > スループット最適化HDD > 汎用SSD > プロビジョンドIOPS SSDの順にI/O性能が高くなっている。
どういった場合にどういったものを選択しておけば良いか押さえておけば良い。
Amazon S3（Amazon Simple Storage Service）
ただデータを保存するといった用途だけではなく、htmlやjavascript、CSS等のファイルを置いて、WEBサーバとしての機能を持たすことが可能。
こうした機能をAWS側で、マネージドで管理してくれる。
S3のキャパシティ等を気にすることなく勝手にS3へアクセスできるよう処理してくれるので非常に高いスケーラビリティを享受することができる。
s3に保存される物は物（オブジェクトとして管理）され、KEYとして対応付けられている。
ユーザ側はKEYに対してアクセスすることで閲覧権限が付加されている場合、参照することができる。
S3の料金体系
中に保管しているデータ量に対して課金量が多くなっている、リクエスト回数やリージョン外への転送なども課金対象になっている。
S3へのデータ転送やS3から同一リージョンの他のサービスへのテータ転送は無料となっている。
S3にはストレージクラスというものが存在 しており、なにもしなかった場合は、S3標準といったストレージクラスに格納される。
中に置いている物を適切なストレージクラスに格納することによって、料金を抑えることができる。
ライフサイクルポリシー 、マネージメントコンソール上で、ボタンポチポチで設定することが可能で、中に入れたデータを時間的なポイントでストレージクラスを移動させることが実現できる。
S3標準（通常アクセス）⇒S3低頻度アクセス（アクセス少）⇒S3 Glacier（まったく見ないアーカイブ用）⇒ゴミ箱 といった様なライフサイクルポリシーを設定することが可能になっている。
何十日経過したらストレージクラスを移動するといった具合。
パフォーマンスが高いネットワーキングソリューションの選択
Amazon CloudFront
コンテンツデリバリーネットワーク（キャッシュ）のサービスになってくる。
例：エンドユーザが直接S3のコンテンツを参照しデータのやり取りをしている場合、間にCloudFrontを挟むことによって地理的な制約を受けずにスムーズにデータのやり取りをおこなうことができる。
CloudFront は世界中にサーバを持っておりデータを S3 からあらかじめキャッシュしておくことによりデータを素早く表示できる特性を持ち、データが存在しない場合には、都度 S3 を参照する。
エンドユーザからCloudFrontへのアクセスは自動的にもっとも近い CloudFrontエッジロケーション にアクセスし、 S3 へのアクセスは CloudFront のみからのアクセスを担保できるのでエンドユーザへは素早くデータを返すことができる仕組みとなっている。
適切な部分にデータを適切にキャッシュをするという部分も凄く重要な観点になってくる。
パフォーマンスの高いデータベースソリューションの選択
- Amazon Database Service
Amazon RDSAmazon DynamoDBAmazon Redshift
試験的にはこれらのデータベースサービスがよく利用される。
Amazon RDS
一般的な RDBMS として比較されるのが RDS で 複雑なトランザクションや複雑なクエリ 、 高耐久性 を求める場合に使用する。
Amazon RDSリードレプリカ
RDS 負荷軽減の施策として取られ、DBの負荷が大きくDB側で耐えきれない場合に、DBのコピー リードレプリカ 読込専用のインスタンスを作っておき 読み込み専用のインスタンスに対して読み込みアクセスを振り分け ることによってMatserの方に書き込みを制御している方へ、負荷がいかないようにするよという手法を リードレプリカ という。
書き込みのクエリを処理することはできないが、読み込みのクエリだけには耐えられるよということを担保するためのもの。
超高速な読み書き速度 や 簡単なGET/PUTリクエスト の場合は使用しない。
これらは試験によくでてくるポイントとなる。
DynamoDB
プロビジョンドスループット となり事前に読み込み書き込みそれぞれにおいて、どれくらいに量を使うよというリソースを事前に割り当てる方式となっている。
事前に割り当てた量を キャパシティユニット と言い、これを超えてしまうとエラーを返す。
なので適切な値まで上げてあげるよといったことが必要になってくる。
Amazon ElasticCache
Memcached や Redis と言ったようにな実際のcacheを管理する為のサービスとなっている。
DBに対して直接アクセスするのではなく、間に cache層 を置き（ElasticCache）等の中にDBのデータをキャッシュさせておきこれらのキャッシュデータにアクセスすることでDBに対するアクセスを下げることが期待できる。
-
Memcached
- マルチスレッド
- メンテナンスが簡単
- 簡単に自動検出機能で水平スケーリングできる。
-
Redis
- 複数のデータ構造をサポート
- アトミックオペレーション
- Pub/Subメーセージング
- リードレプリカ/フェイルオーバー
- クラスターモード/シャードされたクラスター
等の特徴がある。
試験的には
MemcachedやRedisは暗記するものではなく、どういったものかを把握していればよい。