AWS Identity and Access Management(1)IAMの概要

AWS Identity and Access Management (IAM)とは

AWS IAMは、AWSをセキュアに使用するための認証認可の仕組み。UserやGroupを作成してパーミッションを付与することができる。AccessKey, SecretKeyの取り扱いは注意が必要で定期的な更新が望ましい。また、Rootアカウント(アカウントを作成したときのID)はIAMの設定するポリシーが適用されない強力なアカウントになるので極力使用しない。

IAMで作成したユーザでマネージメントコンソールにログインすることが可能で、ログインURLはIAM Dashboardより確認編集することが可能である。

安全なアカウント管理のために

安全にアカウントを管理するためには以下のような手法を講じることが望ましい。

  • ルートアカウントのアクセスキーを消去する
  • ルートアカウントをMFA認証にする
  • AWSが定期着したポリシーを利用する
  • ユーザにグループを割り当て、グループごとにポリシーを定義する
  • 最小限の権限のみを与える
  • EC2で動作するアプリケーションへは、アクセスキーではなくロールで権限を与える

セキュリティ監査

セキュリティ監査を実施することで高いセキュリティレベルを維持することができる。セキュリティ監査は、定期的もしくはユーザの増減があった際や、サービスの開始/停止時、不正アクセスが疑われる際などに推測を交えずに徹底的に行うと良い。

管理ポリシー

AWSアクセスへの管理権限をJSON形式で指定することが可能である。条件(Condition)は、項目を連ねた場合はAND、項目内で条件を連ねた場合はORとして扱われる。全てのアクセスはデフォルトで拒否、Allowが指定されれば許可、Denyが指定されれば明示的な拒否として扱われる。

分類 項目例 内容
Effect Allow or Deny 許可設定であればAllow, 拒否設定であればDeny
Action s3:createBucket 操作の指定、ワイルドカードも使用可能
Resource arn:aws:s3:::mybucket service:region:account:resouceの順で記述する
Condition “IPAddress”: {“AWS:SourceIP”: “192.168.0.1”} 条件を指定する

IAMロール

AWSサービスに対してAWSアクセスの管理権限を付与する仕組み。UserやGroupには紐付かない。例えばEC2からDynamoDBやS3にアクセスする場合は、EC2上にCredentialを置くのではなくインスタンス作成時に適切なIAMロールを紐付ける。EC2へのIAMロールの紐付けは、インスタンス作成時のみ可能であることに注意が必要である。

AWSCredentialsProvider

AWSの各サービスにアクセスするプログラムをEC2上で動作させる場合に、認証情報をCredentialsから取得するのか、IAMロールから取得するのか選択することができる。Credentialsから取得する場合はProfileCredentialsProviderを、IAMロールから取得する場合はInstanceProfileCredentialsProviderクラスを使用する。

// Credentialsから取得する場合
AWSCredentialsProvider credentialsProvider = new ProfileCredentialsProvider();

// IAMロールから取得する場合
//
// 引数(refreshCredentialsAsync)をtrueにすると認証情報を非同期に更新する新しいスレッドが生成される
// falseにすると認証情報の更新は、インスタンスメタサービスに合わせられる
AWSCredentialsProvider credentialsProvider = new InstanceProfileCredentialsProvider(true);

// 認証情報の取得
credentialsProvider.getCredentials();

STS(AWS Security Token Service)

AWSには、STS(AWS Security Token Service) と呼ばれる一時的に認証情報を付与するサービスが存在し、動的にIAMユーザを作成することができる。IAM Role for EC2はこの仕組みを利用している。有効期限は数分から数時間に設定可能である。

AWS VPC (1)Amazon Virtual Private Cloud とは

VPC

各アベイラビリティゾーンのデフォルトサブネットを持つデフォルトVPCが標準で作成され、インスタンス起動時にサブネットを指定しなかった場合は、このデフォルトVPCが指定される。これに加えて、ユーザ独自にデフォルト外VPCを作成することが可能である。VPCは、ルータを通じて他のVPCと接続(ピアリング接続)したり、S3などの他のAWSサービスのエンドポイントと接続したり、VPN経由で自社のネットワークと接続したりすることが可能である。VPCを利用するAWSサービスの例としては、AWS Data Pipeline, Elastic Beanstalk, Elastic Load Balancing, Amazon ElastiCache, Amazon EMR, AWS OpsWorks, Amazon RDS, Amazon Redshift, Route 53などがある。

VPCは生成する際にサイズを指定することが可能で、/16から/28までを指定できる。生成後にサイズを変更することはできないが、セカンダリ IPv4 CIDR ブロックを関連付けることができる。指定するCIDR ブロックは、プライベートIPアドレスの範囲から指定することが望ましい。

デフォルトVPC

デフォルトVPCには、ルータインターネットゲートウェイが含まれており、各サブネットは、インスタンスに対してパブリックIPの割り当てが実行される、インターネットに接続可能なパブリックサブネットである。サブネットを指定せずにEC2を起動した場合は、デフォルトVPCで起動される。デフォルトVPCでは、サイズ /16 の IPv4 CIDR ブロック (172.31.0.0/16) の作成と、インターネットゲートウェイとの接続を行う。新しいアベイラビリティーゾーンが追加された場合は、数日以内に、このアベイラビリティーゾーン内でデフォルト VPC の新しいデフォルトサブネットが自動的に作成される

デフォルトVPC

デフォルト外VPC

デフォルト外VPCには、ルータやインターネットゲートウェイが含まれておらず、自分で設定に加える必要がある。また、サブネットも標準では、パブリックIPの割り当てが行われず、プライベートサブネットに設定されている。

デフォルト外VPCでインターネット接続を可能にするためには、インターネットゲートウェイのアタッチや、ルーティングテーブルの追加、各インスタンスへのElastic IPの割り当てが必要である。プライベートサブネットの場合、サブネット内のインスタンスが直接インターネットに接続することができないため、別のパブリックサブネット内にNAT gatewayを生成し、このNAT gateway経由でインターネットと接続を行う。Elastic IPの数には限りがあるので、静的なIPアドレスを多く使用するようなネットワーク構成の場合にも、NAT gatewayは有効である。なお、NAT gatewayはIPv6には非対応である。

サブネット

サブネットは、アベイラビリティゾーン単位で指定できる。サブネットは生成する際にサイズを指定することが可能で、/16から/28までを指定できる。指定したCIDR ブロックの先頭4アドレスと最後の1アドレスは使用することができない。なお、先頭アドレスは、ルータに接続されるIPアドレスとなっている。また、CIDRブロックのサイズを後から増減することはできない

インターネットに接続する必要のあるリーソースの場合は、パブリックサブネットを、インターネットに接続しないリソースの場合は、プライベートサブネットに接続する。

サブネット

ルーティング

各VPCには暗黙的なルータ(implied router)が存在し、標準ではVPC内の各サブネット間の通信のみ許可されている。また、ルートテーブルは、標準で生成されるメインルートテーブルと、各サブネットにそれぞれ割り当てることが可能なカスタムルートテーブルが存在する。明示的にルートテーブルの関連付けを行わない場合は、メインルートテーブルにアタッチされる。インターネットゲートウェイを通じて、インターネットに接続する場合は、ルートテーブルにインターネットゲートウェイへの経路を明示的に追加する必要がある。また、VPN、Direct Connect、VPC Peeringでは、2hop以上先のネットワークとは通信できない

インターネットゲートウェイ(IGW)

EC2へインターネットへの接続を提供する。サブネット単位でルーティングを指定でき、インターネットゲートウェイを指定したサブネットをパブリックサブネットと呼ぶ。インターネットとの間で通信が必要なインスタンスには、パブリックIPの付与が必要となる。冗長性と高い可用性を有しており、水平スケーリングが可能である。

バーチャルプライベートゲートウェイ(VGW)

VPN接続やDirect Connect接続のエンドポイントを提供する。1つのVPCあたり1つのVGWを接続することができる。

カスタマーゲートウェイ(CGW)

オンプレミス側のVPNエンドポイント。

NATゲートウェイ

NATゲートウェイには、1つElastic IPを付与することができ、プライベートサブネットのインスタンスからインターネットへの接続を可能とする。インターネット側からのサブネットへのアクセスは許可されない。NATゲートウェイは、パブリックサブネットに配置する必要がある。また、NATゲートウェイは、5Gbpsの帯域をサポートし、最大45bpsまで自動的に拡張される。タイムアウト時、NAT GatewayはRSTパケットを送信するが、NATインスタンスの場合はFINパケットを送信する。

VPCピアリング

異なるVPC間でルーティングを行うサービス。MTUは1500
同一リージョン内のVPCのみ接続可能で、重複したCIDRブロックのサブネットは接続できない

ネットワークインタフェース

ネットワークインタフェースは、インスタンスにアタッチ、デタッチしても属性情報は変わらない。1つのインスタンスに複数のネットワークインタフェースをアタッチすることで、管理用ネットワークを別に作成することなどが可能となる。一方で、複数のネットワークインタフェースが存在すると、パブリックIPアドレスの自動割り当ては利用不可となる。

プライマリプライベートIPアドレスは、一度設定すると変更することはできない。セカンダリプライベートIPアドレスは、異なるインタフェースに割り当て直すことが可能である。EC2インスタンスは、プライベートIPアドレスのみを認識し、割り当てられたパブリックIPアドレスは、インターネットゲートウェイでNATされる。パブリックIPアドレスを有効化している場合、Elastic IPを指定しない限りアドレスは、起動時に自動的に割り当てられる

パブリックIP

ネットワーク帯域

同一リージョン内通信の場合、最大25Gbpsが利用可能となる。

通信方式 同一プレイスメントグループ 同一リージョン S3 リージョン外
シングルフロー 最大10Gbps 最大5Gbps 最大25Gbps 最大5Gbps
マルチフロー 最大25Gbps 最大25Gbps 最大25Gbps 最大5Gbps

セキュリティ

ネットワークアクセスリスト(NACL)

サブネットごとに設定するフィルタ。ステートレス。デフォルトは全て許可

セキュリティグループ

EC2の仮想インタフェースとして機能。ステートフル。デフォルトは全ての通信を禁止。拒否ルールは記述できない。また、デフォルトのセキュリティグループは削除できない

VPCのセキュリティ

DNS

各VPCにはDNSが用意されており、VPCのネットワーク範囲(CIDR)のアドレスに+2したIPで参照が可能。参照が可能なのはVPC内のEC2のみで、Direct Connect等で接続したオンプレミス環境からは参照することができない

フローログ

VPC のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャできるようにする機能。データは、CloudWatch Logs と Amazon S3 に出力することができる。

VPCエンドポイント

VPCエンドポイントを用いることで、AWSサービスやVPCエンドポイントサービスをプライベートに接続することができる。VPCエンドポイントを用いることでインターネットに出ることなく各種AWSサービスと通信を行うことができる。冗長性と高可用性を持ち、帯域幅の制約は存在しない。対応しているAWSのサービスは以下の通り。

インタフェースエンドポイント

プライベートIPアドレスを持つエンドポイント。プライベート DNSオプションを有効化しておくことで、通常のエンドポイントが、プライベートIPアドレスに置換される。

  • Amazon API Gateway
  • Amazon CloudWatch
  • Amazon CloudWatch Events
  • Amazon CloudWatch Logs
  • AWS CodeBuild
  • Amazon EC2 API
  • Elastic Load Balancing API
  • AWS Key Management Service
  • Amazon Kinesis Data Streams
  • Amazon SageMaker ランタイム
  • AWS Secrets Manager
  • AWS Service Catalog
  • Amazon SNS
  • AWS Systems Manager

ゲートウェイエンドポイント

ゲートウェイエンドポイント

ルートテーブルに指定されたルートのターゲットとなるエンドポイント。VPC ルートテーブルを指定する必要がある。

  • Amazon S3
  • DynamoDB

インタフェースエンドポイント

AWS S3(2)S3Sync:S3バックアップツール

S3Sync

以前、S3にバケットを作成してGlacierアーカイブを行う手順を確認したが、この仕組みを利用してMacの任意のディレクトリをS3 Glacierと自動的に同期するアプリケーション「S3Sync」を作ってみた。Macのスリープを検知すると同期を始めるので、寝ている間にラクラク同期できる。

といってもこのアプリ、単にNSTaskを使ってシステムコマンドを実行しているだけのアプリなので、任意のコマンドを自由に実行することができる。ステータスバーに常駐しているアプリなので、作業の邪魔にもならない。

S3Sync

スリープ検知

スリープ検知をするには、NSWorkspace ClassNSWorkspaceWillSleepNotification属性を使う。

    func applicationDidFinishLaunching(aNotification: NSNotification) {
        // スリープ検知
        NSWorkspace.sharedWorkspace().notificationCenter.addObserver(self, selector: #selector(self.receiveSleepNotification(_:)), name: NSWorkspaceWillSleepNotification, object: nil)
    }

    func receiveSleepNotification(notification: NSNotification){
        // スリープ実行時に行う処理
    }

システムコマンドの実行

システムコマンドは、NSTask Classから実行することが可能である。
NSTaskは、実行したシステムコマンドの出力結果を取り出すことも可能だが、readDataToEndOfFile()を使うとブロッキング処理が発生してしまうので、dispatch_async()を使って非同期に順次出力処理していく必要がある。

let task = NSTask() 
// 実行コマンドをフルパスで指定
task.launchPath = "/usr/local/bin/aws "
// パラメータを配列形式で指定
task.arguments = ["-h", "hogehoge"]
// 標準出力をパイプに渡す
let pipe: NSPipe = NSPipe()
task.standardOutput = pipe
let stdoutHundle = pipe.fileHandleForReading     
// 非同期処理
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), {
var dataRead = stdoutHundle.availableData
while(dataRead.length > 0){
	let stringRead = NSString(data: dataRead, encoding: NSUTF8StringEncoding)
        if let output = stringRead {
		// 出力結果処理
        }
        dataRead = stdoutHundle.availableData
}
// コマンドの実行
task.launch()

NSTaskは、suspend()terminate()を使って、途中で処理を停止したり、完全に終了してしまったりすることができる。suspend()で中断した処理は、resume()で再開することができる。また、タスクが実行中にも関わらず再度launch()を実行してしまうと、下記の実行エラーが発生してしまう。

task already launched

通知の送信

本アプリは、コマンド実行毎にMacの通知センターに実行状況を通知する。

アプリ通知

Macの通知センターに通知を送信するには、NSUserNotificationCenter Classを使う。送信する通知には、「タイトル」「サブタイトル」の他に様々な項目を設定することが可能である。

// NSUserNotificationCenterDelegateが必要
class AppDelegate: NSObject, NSApplicationDelegate, NSUserNotificationCenterDelegate {

    func deliverNotification(title : String, subtitle : String, informativeText: String){
        // AppDelegate Classにデリゲードを指定
        NSUserNotificationCenter.defaultUserNotificationCenter().delegate = self
        let notification = NSUserNotification()
        notification.title = title
        notification.subtitle = subtitle
        notification.informativeText = informativeText
        notification.contentImage =  NSImage(named: "MainIcon")
        notification.userInfo = ["title" : "タイトル"]
        NSUserNotificationCenter.defaultUserNotificationCenter().deliverNotification(notification)
    }

}

ログを保存するディレクトリの指定

本アプリは、実行ログをファイルに保存することができる。

NSOpenPanel

Macでディレクトリやファイルを開くする際は、NSOpenPanel Classを利用する。
また、保存の際はNSSavePanel Classというクラスも用意されている。

// MARK: ディレクトリ選択画面
let panel = NSOpenPanel()
// ファイル選択の可否
panel.canChooseFiles = false
// ディレクトリ選択の可否
panel.canChooseDirectories = true
// 複数選択の可否
panel.allowsMultipleSelection = false
panel.beginWithCompletionHandler({(num) -> Void in
      if num == NSModalResponseOK {
           // ディレクトリ・ファイル決定時の処理
      }
})

常駐アプリ

ステータスバーに常駐するアプリを作成するためには、Project > TARGET > Info > Custom OS X Application Target Propertiesから、Application is agent (UIElement)YESに設定する。

Application is agent

StoryBoardのTips

  • 常駐アプリであっても、Main Menu > Edit がないと、TextFieldの Shortcut Keyが使えない

Main Menu : Edit

AWS S3(1)MacのデータをGlacierにバックアップする

iMacに保存されているデータをAmazon Glacierに定期バックアップする。

Amazon Glacierは、長期バックアップに最適なストレージで、非常に低コストであることが特徴である。費用はリージョンごとに異なり、バージニアリージョンであれば0.007USD/GB、東京リージョンであれば0.0114USD/GB、1TBのデータを保存しても月額800円程度と安価である。Glacierは、データをアーカイブとして保存するため、アップロード後にデータを改変することができない。S3ではデータの保存先にGlacierを指定することが可能で、ライフサイクル設定によりデータを定期的にGlacierにアーカイブ可能となっている。

AWS CLI のインストール

MacからAWSにアクセスするためには、コマンドラインツールであるAWS CLIの利用が便利である。AWS CLIは、pip(Pythonパッケージ管理システム)からインストールが可能である。

$ sudo pip install awscli
  Downloading six-1.10.0-py2.py3-none-any.whl
Installing collected packages: pyasn1, rsa, futures, jmespath, six, python-dateutil, docutils, botocore, s3transfer, colorama, awscli
  Found existing installation: six 1.4.1
    DEPRECATION: Uninstalling a distutils installed project (six) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
    Uninstalling six-1.4.1:
Exception:
Traceback (most recent call last):
  File "/Library/Python/2.7/site-packages/pip/basecommand.py", line 209, in main
    status = self.run(options, args)
  File "/Library/Python/2.7/site-packages/pip/commands/install.py", line 317, in run
    prefix=options.prefix_path,
  File "/Library/Python/2.7/site-packages/pip/req/req_set.py", line 726, in install
    requirement.uninstall(auto_confirm=True)
  File "/Library/Python/2.7/site-packages/pip/req/req_install.py", line 746, in uninstall
    paths_to_remove.remove(auto_confirm)
  File "/Library/Python/2.7/site-packages/pip/req/req_uninstall.py", line 115, in remove
    renames(path, new_path)
  File "/Library/Python/2.7/site-packages/pip/utils/__init__.py", line 267, in renames
    shutil.move(old, new)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 302, in move
    copy2(src, real_dst)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 131, in copy2
    copystat(src, dst)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 103, in copystat
    os.chflags(dst, st.st_flags)
OSError: [Errno 1] Operation not permitted: '/tmp/pip-oO8sKD-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/six-1.4.1-py2.7.egg-info'

上記のようにsixが既にインストールされているという警告が出てインストールできない場合は、以下のコマンドでインストールを行う。

$ sudo pip install awscli --upgrade --ignore-installed six

インストール完了後は、認証情報の設定を行う。AWS Access Key IDAWS Secret Access Keyなどの認証情報は、AWSマネージメントコンソールのAWS Identity and Access Managementから設定が可能である。

$ aws configure
AWS Access Key ID [None]: xxxxxxxxxxxxxxxxxxxxx
AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxxxxxxxxxxx
Default region name [None]: ap-northeast-1
Default output format [None]: json

S3初期設定

S3の設定を行い、データを格納するバケットの生成および、Glacierへバックアップを行うライフサイクル設定をする。安価にデータをバックアップするという目的でGlacierを使用することから、今回は単価が最も安いバージニアリージョンをする。

バケットの生成

バケットを生成する。
このときAWS CLIに設定したユーザにS3へのアクセス権限がないとエラーが発生する。

$ aws s3 mb s3://backup-hoge --region us-east-1
make_bucket failed: s3://backup-hoge/ A client error (AccessDenied) occurred when calling the CreateBucket operation: Access Denied

そこで、AWSマネージメントコンソールのAWS Identity and Access Managementで、該当ユーザにAmazon S3 Full Access権限を付与する。

ポリシーのアタッチ

また、S3のバケット名はユニークである必要があるので、既に同一名称のバケットが存在する場合は、下記のようなエラーが発生するので注意が必要である。

$ aws s3 mb s3://backup-hoge  --region us-east-1
make_bucket failed: s3://backup-hoge/ A client error (BucketAlreadyExists) occurred when calling the CreateBucket operation: The requested bucket name is not available. The bucket namespace is shared by all users of the system. Please select a different name and try again.

ライフサイクル設定

次にライフサイクル設定で、どの程度の頻度でGlacierへアーカイブするかを設定する。
今回は、以下の設定としている。

設定内容 JSON
即日アーカイブする “Days”: 0″
特定のディレクトリに限定することなくバケット全体をアーカイブする “Prefix”: “”
Glacierへアーカイブする “StorageClass”: “GLACIER”

このとき、「”Prefix”: null」とすると、フォーマットエラーとなる。

vi /tmp/lifecycle.json

{
    "Rules": [
        {
            "Status": "Enabled", 
            "Prefix": "", 
            "Transition": {
                "Days": 0, 
                "StorageClass": "GLACIER"
            }, 
            "ID": "backup for xxx"
        }
    ]
}

JSONが作成できたら、ライフサイクル設定の反映を行う。

aws s3api put-bucket-lifecycle --bucket backup-hoge --lifecycle file://lifecycle.json

同期処理

同期処理は以下のコマンドにより実行できる。deleteオプションによりファイル削除も同期される。また、excludeオプションによって同期対象外のファイルやフォルダを指定できるので、.DS_Storeファイルなどを指定しておくと良い。excludeオプションは、条件の数だけいくつでも追記できる。

aws s3 sync /Volumes/hoge/ s3://backup-hoge --delete --exclude '*.DS_Store'

AWS CloudWatch(2)システム運用における監視項目

AWSでシステム構築を行う場合、基本的にはこのCloudWawtchのみの監視で十分なことが多い。様々な監視項目が存在するが、システム運用を行う際に特に監視する必要のある項目は以下の通り。

DynamoDB

多くの項目がデフォルトで 1 分ごとにデータを送信するが、5 分間隔で送信されるデータも存在する。事前に設定した容量(スループット)が十分であるかを監視しておくと良い。

  • ProvisionedReadCapacityUnits
  • ConsumedReadCapacityUnits
  • ProvisionedWriteCapacityUnits
  • ConsumedWriteCapacityUnits

EC2

Amazon EC2 はデフォルトで 5 分ごとに CloudWatch にデータを送信する。インスタンスを作成する際に、「詳細モニタリングを有効」にチェックを入れることでこれを 1 分ごとに変更することができるCPU使用率を監視しておくと良い。メモリやディスクのメトリクスを取得するためには、CloudWatch Agentをインストールする必要がある

  • CPUUtilization

Kinesis

事前に設定した容量(シャード数)が十分であるかを監視しておくと良い。

  • PutRecords.Records
  • IncomingRecords
  • GetRecords.Bytes
  • IteratorAge

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などのアクションを規定することも可能である。

CloudWatch Agent

統合 CloudWatch エージェントを使用することで、EC2やオンプレミスサーバからより多くのメトリクスを取得することができる。例えば、通常のCloudWatchでは計測できないサーバのメモリ量ディスク量などのメトリクスを追加で取得できる。また、メトリクスだけでなくサーバ内のログを収集して、CloudWatch Logsに送信することもできる。

EC2には、デフォルトではCloudWatchエージェントはインストールされていないため、Systems ManagerやCloudFormationなどを用いて追加でインストールする必要がある。なお、過去にはCloudWatch Logs エージェントが使用されていたが、現行バージョンは統合 CloudWatch エージェントであるため、特段の理由がなければ統合 CloudWatch エージェントを使用する。

AWS Kinesis(5)Kinesis Client Libraryでマルチスレッド処理を行う

マルチスレッド処理

AWSが公開しているKinesis Client Library(KCL)のサンプルプログラムでは、取得した各レコードをシングルスレッドで順次処理している。しかしこれでは、前のRecord処理が終了しないと次のRecord処理が実行できないため、Kinesis Client LibraryのDEFAULT_MAX_RECORDの値を上げたとしても性能が十分出ない。

そこで、Record処理を単純にRunnaleなどでマルチスレッド化してしまうとスレッド数が制御できなくなり、例えばKinesis Recordから取得したデータをDynamoDBに順次書き込むという制御を記述していた場合は、

com.amazonaws.http.AmazonHttpClient executeHelper
INFO: Unable to execute HTTP request: Timeout waiting for connection from pool
org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection from pool

など、DynamoDBにアクセスするためのHTTPのリソースが枯渇してエラーが発生し、Record処理に漏れが生じてしまう。そこで、ExecutorServiceを用いてスレッド数を制御しながらマルチスレッド化する。

    /**
     * Process records performing retries as needed. Skip "poison pill" records.
     *
     * @param records Data records to be processed.
     */
    private void processRecordsWithRetries(List<Record> records) {
        ExecutorService exec = Executors.newFixedThreadPool(NUM);
        try {	        
            for (Record record : records) {
                boolean processedSuccessfully = false;
                for (int i = 0; i < NUM_RETRIES; i++) {
                    try {
                        // スレッドタスクを実行
                        exec.submit(new My_Method(this, record));
                        // 略...
                    }
                }
            }
        } finally {
            // スレッドタスクを終了
            exec.shutdown();
            if(!exec.awaitTermination(60, TimeUnit.SECONDS)){
                exec.shutdownNow();
            }
        }
    }

ExecutorServiceは、スレッドプールを用いて、マルチスレッドタスクを管理しながら実行できる仕組みで、submit()によりタスクが生成されて、ブロッキングキューに挿入され、shutdown()もしくはshutdownNow()メソッドにより処理を終了させることができる。ExecutorServiceを用いると生成するスレッド数を指定できることから、無尽蔵にスレッドが生成される心配がない。

ExecutorServiceは、終了処理を必ず明示的に実装しておく必要があるサービスである。生成済みのタスクは、shutdown()メソッド実行後も処理が継続されるが、shutdownNow()メソッドの場合は、強制的に処理がキャンセルされる。すなわち、shutdown()メソッド実行を実行したあとも、処理が継続したままである場合があることに注意が必要である。したがって、上記のように、shutdown()メソッドを実行した後に、awaitTermination()メソッドによりタイムアウトの時間を設定しておき、この時間を超えても処理が継続している場合には、shutdownNow()メソッドで強制的に処理を終了させるという実装にすることが望ましい。

ExecutorServiceで設定したスレッド数(NUM)が多すぎると以下のエラーが発生するため、スレッド数の上限を設定する際は注意が必要である。

java.lang.OutOfMemoryError: unable to create new native thread 

プログラムがどれほどスレッドを消費しているかは、以下のコマンドで確認が可能である。

ls -l /proc/[プログラムのプロセスNo.]/task | wc -l

また、Linuxの最大スレッド数は、

cat /proc/sys/kernel/threads-max

ユーザ1人あたりの制限は、

ulimit -a

で確認することが可能である。

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 https://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や、ホスト名、リージョン、ネットワーク設定、セキュリティグループ名などを取得することができる。

https://169.254.169.254/latest/meta-data/

AWS Cognito(5)スロットリング

スロットリングとは

AWSは各サービスにサービス制限(スロットリングを行っており、各アカウントごとに使えるリソースの上限が設定されている。例えば、EC2は初期状態では最大20台までしかインスタンスを起動できない設定となっている。フルマネージドのサービスに対してもこれらの制限が設定されており、「フルマネージド」という名称でありながら負荷に合わせて際限なくスケールするわけではない。また、サービスによっては、サービス制限一覧にこの上限値が明記されていないものもある。

上限値以上にリソースを使用する場合はサポートプランに加入の上、サポートに必要なリソース数とその理由を付けて上限値の引き上げや撤廃を申請する必要がある。上限値の変更が必要な理由が不明確であったり必要以上のリソースを要求すると、要望が叶えられないこともあるので注意が必要である。理由を明確にした上で申請する必要がある。

なお基本的にAWSのマネージドサービスは、「定常的な利用」や「一時的なサービスを簡単に作成するため」に提供するシステムであるという考え方のようで、バースト的なアクセスや複雑な処理、定常的に大きな負荷が掛かる処理については、EC2上にシステムを構築して利用すべきであるというのがAmazonの方針のようである。大きな負荷の掛かる処理の場合は、上限引き上げ申請するだけでなく、EC2を用いて実現できないかについても検討すべきであろう。

Cognitoのスロットリング

AWSのサービスは日々拡張されていっているので、スロットリングの値は随時変更されている可能性がある。その前提のもと現時点で、

  • Cognito Identity: 数百/毎秒程度
  • Cognito Sync : 数千/毎秒程度

でスロットリングされており、それ以上の負荷が掛かる可能性があったりそれ以上のリソースを必要とする場合は、サポートに上限引き上げの申請を行う必要があるようだ。また、申請を行ったとしても標準値の数倍程度までしか拡張できないようである。Cognitoは昨年の9月に東京リージョンにきたばかりのサービスであるので、用意されているリソースにも限りがあるのかもしれない。今後のリソース拡張に期待したい。