AWSトレーニング（Amazon Web Services 実践入門 ２ ～一日で学ぶ、AWSクラウド活用～ ） 受講記録

概要

実践入門１に引き続き、実践入門２を受講したので記録を残します。
実践入門２は運用についての内容になります。

前提知識

• AWS実践入門１を修了、または同等の知識を有する（必須）
• Linux OSまたは、UNIX OSの導入、管理経験（必須）
• RDBMSの知識（推奨）
• Webシステム構築・運用経験または（知識）

コースの目標

• 自動的にスケールするシステムの設定など応用操作を理解する。
• 耐障害性や性能向上を考慮したサービスの利用方法を理解する（Amazon EBS）。
• AWSの各種サービスの活用を理解する。
• AWSの各種サービスを利用するハンズオンを通して、AWSクラウドならではの実践的なシステム構築を理解する。
• AWSでのベストプラクティスに基づいたアーキテクチャーパターンを理解する。

今回利用したAWSサービス

• CloudWatch
• AutoScaling
• CloudFront
• EBS
• S3

Amazon CloudWatch

特徴

• AWSのリソースを監視する。
  • 死活、性能、ログ監視
  • 取得メトリクスのグラフ化
  • 各メトリクスに対してアラーム作成
• サービスごとに定義されたメトリクス（監視項目）がある
• メトリクスは2週間保存される
• メトリクスをベースにアラームを設定可能
• アラーム時のアクションを設定可能

料金体系

• 基本モニタリングは無料
• 以下のサービスは別途料金
  • 詳細モニタリング（最小で1分間隔）
  • カスタムメトリクス（メモリ監視はこちら）
    • メモリ監視は仕組みを作る必要がある。
  • APIリクエスト
  • アラーム
  • ログ

アラーム時のアクション

以下の３つから選択できる。

• 通知
• AutoScaling
• EC2アクション

CloudWatchログ

アプリケーションログや、Apatchログ等は通常監視では取得できない。
そのため、対象のログを収集して監視するための仕組み。
EC2にCloudWatch ログエージェントをインストールし、
対象のログをCloudWatch ログサービスに送信する。
※送信はAPIリクエストになるので、課金対象になる。

Auto Scaling

特徴

• 自動でインスタンス数の維持や増減を行える
• AutoScalingの対象はEC2のみ
• CloudWatchのアラームアクションにて増減が可能

価格体系

• 価格自体は無料
  • 増減するインスタンス数には課金対象

ELBへの配置

• AutoScalingはサーバを用意するだけなので、ELBは必須となる
  • 増減したサーバにトラフィックを振り分けるのはELBのため
  • ELBの特徴に、新しいサーバにヘルスチェックが通ったらトラフィックの分配対象にすることができる
• AutoScalingはサーバの用意先は指定できるので、ELB配下に用意させることができる

設定項目

LaunchConfiguration：インスタンスに必要な情報（AutoScalingの設定）

• AMIは？
• セキュリティグループは？
• キーペアは？

AutoScallingGroup：何台インスタンスを起動すべき？（ELBの設定）

• 最低何台？最大何台？
• どのELB配下に？
• どのAZに？
• 最小と最大台数を同じに設定した場合、AutoHealingとしても利用可能

AutoScallingPolicy：どういうルールで増減する？（CloudWatchの設定）

• 何台増やす？
• 条件は？
• 複数のEC2インスタンスをまとめて監視可能

Amazon CloudFront

特徴

• 世界各地のキャッシュサーバから静的ファイルを配信する
• マネージドCDNサービス
• サーバ負荷軽減、レスポンス向上
• 今までのCDNは定額であったが、従量課金製
• 世界50箇所以上のエッジロケーションのサーバにキャッシュでデータを配置している
• エンドユーザはオリジナルサーバではなくキャッシュサーバにアクセスすることで、レスポンスを早く取得することができる。

課金体系

• データ転送量（OUT)
• HTTP/HTTPSリクエスト数
• （利用する場合）SSL独自証明書など

Amazon CloudFrontの仕組み

1. CloudFrontにてディストリビューションを作成し、公開サーバを選択する。
2. ディストリビューションを作成すると、世界中にエッジロケーションにキャッシュが配置される
3. ディストリビューション作成時にCloudFront用DNSが発行される
4. CloudFront用DNSに対してアクセスすると、アクセスポイントから最適なエッジロケーションのアドレスが返される。
5. エッジロケーションにアクセスし、キャッシュから情報を取得できる。
6. キャッシュにデータがない場合のみ、オリジンサーバにデータを取得しにゆく

Invalidation Request

• 手動でキャッシュサーバのキャッシュを削除することができる
• コンテンツの更新時等には行わないこと
  • リクエスト扱いになるため、課金対象になる

S3を利用したバージョン管理

高度なオブジェクト管理機能

バージョン管理

• 重要なデータを保護する機能として、バージョニング機能がある
  • バージョニングを行うと、そのバージョン管理分が課金対象となる
  • あくまでファイル名単位でのバージョン管理のため、差分管理は出来ない
• バージョン管理下にあるファイルは削除できない。
  • 削除しても、履歴が残りそこから復旧が出来る。

署名付きURLの発行

• 非公開オブジェクトに対してアクセスできるURLを生成できる。
  • GUIからではなくAWS SDKを使ってプログラムを作成する必要がある。

オブジェクトのライフサイクル

• 決められた期限を過ぎると自動的にオブジェクトをアーカイブ化/削除することが出来る
• Amazon Glacierと連携し、アーカイブ先に指定することができる。
  • Amazon GlacierはS3と同等の堅牢性をもち価格は1/3ほど。
  • ただし、一度入れたファイルは容量に関係なく取り出すのに数時間かかる。

S3のサーバアクセスロギング

• S3バケットへS3のアクセスログを保存できる

S3のサーバサイド暗号化

• S3に格納するオブジェクトを暗号化できる

Amazon Elastic Block Store(Amazon EBS)

耐障害性の向上

• EBSとはストレージサービス、EC2からしかアクセスできない。
• サーバに付与するブロックストレージ
• 障害時に、破損EC2から別のEC２への付け替えが可能
• スナップショット機能でボリュームのバックアップができる
• 保存先はS3相当の場所（自己のS3に保存されるわけではない）
• 同じAZ内でしか付け替えはできない。
• 一度スナップショット化するとS3に配置されるので、別のAZのEC2への付け替えも可能

I/O性能チューニング

• デフォルトではインターネット回線とボリュームとの回線がまったく同じなため、ネットからのリクエストが増えるとボリュームからのデータ転送速度も落ちる
• インスタンスタイプからEBSの最適化インスタンスを選択すると、ボリューム用の専用回線につなげられる
  • インスタンス作成時、またはインスタンスタイプの変更時に選択できる
• I/O頻度が高い場合、プロビジョンドIOPS（SSD)を利用することで予めIOPSを指定することができる
  • 指定できるIOPSはEBS容量の30倍まで
  • 1年間で指定IOPSの+-10％の範囲を99.9%の確立で確保する

※EBS最適化インスタンスとProvisioned IOPSを組合せて、I/O値の最適化

まとめ

実践入門 1 に引き続き、災対性はとても高いと感じた。
また、監視機能であるCloudWatchを使いリソースの使用状況に応じて、
AutoScallingでサーバを増減が自動的に出来るところ、
増減先のELBを指定できるところをハンズオンでやってみて素晴らしいと感じました。

EBSについても、重要なデータはEBSに保管して
EC2本体はAMIからのコピーのみで稼働するようにすれば、常にサーバがAutoScallingで増減しても、
データの共有はEBSのマスタになるスナップショットで出来るんだなと思いました。

設計する際には、CDP（クラウドデザインパターン）を参照することだったので、目を通します。
Cloud Design Pattern

2日間受けてみてAWSに関して、もっと深く知りたいと思えました！
やってて楽しいと思えるのが、今回の研修で一番良かったところです！