AWS CloudWatch(1)CloudWatchの概要

CloudWatchとは

CloudWatchは、AWSの各リソースを監視することのできるサービスである。AWSでシステム構築を行う場合、基本的にはこのCloudWawtchのみの監視で十分なことが多く、Zabbixなどの他の監視環境を構築する必要がない。フルマネージドのサービスの場合は自ら監視環境を構築することができないため、CloudWatchによる監視が必須となる。また、CloudWatch Logsを用いることで、各リソースのLogデータをCloudWatchで監視することが可能になる。CloudWatch Logsは、ログデータを無期限で保存する

CloudWatchの概要

CloudWatchは、NameSpace(AWS/service)と呼ばれるAWSサービス単位の項目とMetricsと呼ばれる時系列のデータポイントセットから構成され、これらを組み合わせて指定することで任意の項目を確認することが可能となる。CloudWatch上のデータ(CloudWatch Logsのデータを除く)は削除することはできず、15ヶ月経過したデータポイントは自動的に削除される。データポイントに付随するタイムスタンプは、UTC時刻であることが望ましく、データの更新間隔は最短1分となっている。

開発環境か本番環境か、実行しているリージョンはどこかなど、同じMetricsであっても環境によってデータが異なる。同一名称のMetricsの中から特定のMetricsを一意に識別するためにDimentionと呼ばれる名前と値のペアを持つことができる。CloudWatchは、ソースが異なっていてもNameSpaceとMetricsが同一のMetricsは1つのMetricsとして扱う

データポイントの種類 保持期間
60秒間隔未満 3時間
1分 15日間
5分 63日
1時間 455日

アラームを使用することで、単一のMetricsを監視し、一定期間における閾値とMetrics値に応じてアクションを実行することができる。アクション機能を用いることで、各アラームに対する通知やAutoRecovery, AutoScaleなどのアクションを規定することも可能である。

AWS EC2(3)AMIとインスタンス

AMI

AMI(Amazon Machine Image)は、EC2インスタンスの起動に必要な情報を提供するイメージファイルで、

  • OSやアプリケーションなどのルートボリュームのテンプレート
  • 起動を許可するAWSアカウント
  • インスタンスにアタッチするボリュームのマッピング

などの情報が含まれている。

AMIは、AWSや様々な組織が公開しており、これを利用することができる。特にAmazon Linuxは、AWSが提供しているRHEL系のAMIで、AWS CLI Amazon EC2 API 等がパッケージに含まれているため便利で使い勝手が良い。また、自身が作成したインスタンスから生成したAMI(カスタムAMI)を登録/利用することもできる

なお、AMIは同一リージョン内や別のリージョンにコピーを作成することや、他のAWSアカウントとイメージを共有することが可能である。別リージョンにバックアップシステムを構築する場合、AMIのコピーはシステム構築の有用な手段となる。AMIの共有は、公開範囲をパブリックに指定するか、「イメージパーミッションの変更」設定から、許可するAWSアカウントの追加を行う。他者が公開しているAMIを利用する際は、機密データが第3者に送信されていないかや、認証情報が事前に設定されていないかなどを十分に検証する必要がある。

リージョンをまたがるコピー

作成したAMIを別リージョンで使用する際は、AWS CLIのリージョン設定やプログラムのデフォルトリージョン設定をハードコーディングせずに、シェルスクリプト等で変更できるようにしておくと良い。自身のリージョン情報を取得するには、AWS CLIから以下のコマンドを入力する。

$ curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g'

AMIの作成

既存のインスタンス、もしくはスナップショットからAMIを作成することが可能である。AMIの作成は、インスタンス上のすべての動作を停止し、作成プロセス中に一貫した状態が保たれるようにするために、インスタンスをシャットダウンしてから行う。自身で作成したAMIを共有する場合は、以下のように、共有キーやコマンド履歴の削除等の対策を行う。

$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
$ shred -u ~/.*history
$ history -c
$ exit

インスタンスからの Linux AMI の作成

ストレージ

ストレージは以下の2種類が存在する。どちらのデバイスから起動させるか選択することも可能であるが、高速で永続的なEBS-basedの起動方法が奨励されている。

Instance Store

  • EC2と不可分の内蔵ディスクで、EC2をTERMINATEするとクリアされる。ただし、再起動ではクリアされない
  • インスタンス停止(STOP)することができない。
  • 無料

instance store-backed のインスタンス

Elastic Block Store

  • ネットワークで接続されたディスクで、EC2とは独立しており、別途課金される。同じアベイラビリティゾーン内でレプリケーションされるため、高い可用性を有している。
  • デフォルトでは、DeleteOnTermination フラグが true に設定されているので、TERMINATEすると消去されてしまうことに注意が必要である。消去されたボリュームは、ゼロで上書きされて他のアカウントで使用される。機密データを有している場合は、暗号化の検討が必要である。
  • スナップショットを取ることが可能である。スナップショットは、過去のスナップショットとの差分として記録される。スナップショットを取得する際には、EBSをアンマウントすることが望ましい。一方で、スナップショットが開始されれば、スナップショット取得処理中であってもEBSをアタッチして使用して問題ない
  • インスタンスとEBSボリュームはネットワーク経由で接続されているため、他の通信の影響を受ける。EBS最適化インスタンスを利用することで、インスタンスとEBSとの間のスループットが保証され、他の通信の影響を受けない。

Amazon EBS-backed インスタンス

容量と性能

汎用SSD(gp2)のパフォーマンスは、ボリュームサイズに比例する。つまり、小さい容量のEBSの場合は、I/O性能も低い。したがって、高頻度のI/Oが発生する可能性があるアプリケーションが動作する場合などは、使用する容量が低くても、I/Oの性能を向上させるために、大きな容量を設定しておく必要がある。

各ボリュームは、最初に540万I/Oクレジットを受け取り、標準性能を超えたI/O処理(バースト)は、このクレジットから消費されていく。一方、標準性能を下回るI/Oであった場合はクレジットに加算されていく。ただし、加算できるクレジットは、初期値と同じ540万I/Oクレジットまで。クレジットが枯渇するとバースト性能を利用できなくなり、標準性能で頭打ちとなる。なお、汎用SSD(gp2)は、

  • 容量が33.4GB以下であれば、標準性能100IOPS
  • 容量が1000GB以下であれば、3000IOPSのバースト性能を利用可能
  • 容量が3333GBに標準性能10000IOPSに達して、容量16TBまでこの性能を維持

と定義されている。また、スループットは、170GB以下では128 MB/秒170GBを超えると160MB/秒である。

インスタンス

概要

  • EC2は、1500MTUに加えてジャンボフレームをサポートする。
  • ルートデバイスがEBSの場合は、インスタンスタイプを変更することが可能である。このときインスタンスIDは変更されない。パブリックアドレスは変更される。インスタンスタイプを変更する場合は、インスタンスを一度停止する必要がある。

インスタンスのライフサイクル

インスタンスは、以下のライフサイクルで動作する。インスタンスがStopのときは課金されない。ただし、EBSボリュームに対する課金は継続される。時期やタイミングによっては、EC2のリソースが枯渇し新たなインスタンスが起動できない場合もあるので、リソースを確保しておきたい場合は、インスタンスを作成し、使用するまで停止しておくとよい。

インスタンスのライフサイクル

インスタンスを再起動した場合は、同一ハードウェアで起動し、ボリュームやネットワーク設定等は前回起動の情報を保持する。一方、インスタンスを一度停止し起動した場合は、別のハードウェアで起動し、これらの情報は引き継がれない。ハードウェア障害が発生した場合など、明示的に別のハードウェアでインスタンスを起動する必要がある場合には、再起動ではなく停止と開始を行う

インスタンスの公開鍵

EC2に使用するSSHキーペアは、リージョンごとに別管理であるため、他のリージョンでEC2を使用する場合、通常は別途新たにキーペアを作成する必要がある。ただし、これでは管理する際に問題が生じるので、共通のキーペアで運用すると良い。手元の秘密鍵から公開鍵を生成し、AWSマネージメントコンソールから登録を行う。

キーペアのインポート

インスタンスの時刻

デフォルトでは UTC(協定世界時間)時間帯に設定されている。他のタイムゾーンを設定する場合は、起動時に以下を実行する。

vi /etc/rc.local
ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

インスタンスの復旧

ハードウェア障害が発生した場合に、自動的に再起動を行うことが可能なCloudWatchアラームを作成することができる。復旧したインスタンスは、ボリュームやネットワーク設定等は前回起動の情報を保持する。自動復旧は、1インスタンスにつき1日3回までである。

また、AWSがインスタンスの再起動や停止/開始、メンテナンスを事前に予告して実施する場合がある。再起動には、自身でスケジューリング可能なインスタンスリブートと、強制的に再起動されてしまうシステムリブートがある。また、ネットワークや電源のメンテナンスが実施される場合もある。

インスタンスメタデータ

実行中のインスタンスのメタデータは、以下のURLから取得することが可能である。AMIのIDや、ホスト名、リージョン、ネットワーク設定、セキュリティグループ名などを取得することができる。

http://169.254.169.254/latest/meta-data/

AWS EC2(1)EC2の概要

EC2(Elastic Compute Cloud)とは

EC2は、クラウド内で規模の変更が可能なコンピュータ処理能力を提供するウェブサービス。様々な種類の仮想サーバを起動し、Webコンソールやターミナルから操作することが可能である。

リージョンとアベイラビリティーゾーン

東京リージョンは、コード名:ap-northeast-1、名称:アジアパシフィック(東京)である。AWS SDK for Javaなどは、デフォルトのリージョンがバージニア州(us-east-1)に指定されていることに注意が必要である。すべてのインスタンスを 1 か所でホストしている場合、同じ場所にあるインスタンスすべてに影響する障害が起きたときに、インスタンスがすべて利用できなくなるため、複数のアベイラビリティゾーンにインスタンスを分散配置することが望ましい。

インスタンスを起動するときは、同じリージョン内にある AMI を選択する必要がある。AMI が別のリージョンにある場合は、これから使用するリージョンに AMI をコピーできる。異なるアベイラビリティゾーンにインスタンスを移行したい場合は、AMIを作成し、このAMIを用いて希望するアベイラビリティゾーンにインスタンスを生成する。

アベイラビリティーゾーンは、各アカウントの識別子に個別にマッピングされる。つまり、アカウントAのap-northeast-1aと、アカウントBのap-northeast-1aは、同じアベイラビリティゾーンを指していない場合がある。また、各アカウントごとに指定できるアベイラビリティゾーンの使用が制限され、アカウントによってリージョン内で使用できるアベイラビリティーゾーンの数が異なる場合がある。

リージョンとアベイラビリティーゾーンに関する概念

インスタンスファミリー

利用用途に合わせて様々なインスタンスの種類が存在する。

カテゴリ 名称 特徴/用途
汎用 M4 通常用途
バーストパフォーマンス T2 普段は殆ど負荷がないが一時的に負荷がある 開発機、小規模システム
コンピューティング最適化 C4 CPU性能が必要な用途 APサーバ、画像処理
メモリ最適化 R3 コアあたりのメモリが大きく大量のメモリが必要な用途 DBサーバ
ストレージIO最適化 I2 高速なIOPSを実現するSSDを内蔵 DBサーバ、ビッグデータ
ストレージ密度最適化 D2 大容量HDDを内蔵 DBサーバ、ビッグデータ
GPUインスタンス G2 GPUコアが必要な用途 グラフィック表示、画像処理

IP

  • Elastic IP
    • 明示的に割り当てられたIP。使用していないと課金される
  • Public IP
    • ランダムに割り当てられるPublic IP
    • EC2をStop/Startすると別のIPが割り当てられる
  • Private IP
    • 必ず割り当てられるIP
    • EC2をStop/Startしても同じIPが割り当てられる

Amazon Linux

デフォルトユーザはec2-user、sudo権限が付与されている。