AWS EC2(7)Auto Scaling

EC2 Auto Scalingとは

EC2 Auto Scalingを用いることで、アプリケーションの負荷を処理するための適切な数のEC2インスタンスを利用することができる、。Auto Scalingを利用するためには、Auto Scalingグループと呼ばれるEC2インスタンスの集合を定義し、このグループに含まれる最小と最大のインスタンスの数を定義する。また、希望するインスタンス数(Desired capacity)を定義することも可能。また、Auto Scalingグループ内のEC2インスタンスを複数のAZに分散配置することで、地理的な冗長性や安全性を実現できる。

Auto Scaling グループ

Auto Scalingを用いることで、耐障害性や可用性が向上する。また、必要な数のインスタンスのみ起動されるため安定的なパフォーマンスを低コストで実現することができる。

Auto Scalingグループ内の各EC2インスタンスの負荷に偏りが発生した場合は、古いインスタンスを終了して新しいインスタンスを起動させる。この場合にスムーズに処理が継続されるように、一時的に最大容量に対して10%のマージンが確保される

ライフサイクル

Auto Scalingのライフサイクルは以下の通り。

ライフサイクル

Auto Scalingグループはグループ内のインスタンスに対して定期的にヘルスチェックを行なっている。スケールイン/アウトは、手動もしくはスケーリングポリシースケジュールに基づき実行される。スケールイン、ヘルスチェックの失敗、Auto Scalingグループからの離脱等が発生した場合には、Auto Scalingグループ内のEC2インスタンスは終了処理が実施される。

Auto Scalingグループ

起動設定

Auto Scalingグループ内のEC2インスタンスは、起動テンプレートもしくは起動設定の設定内容に基づいて起動される。これらには、AMIのIDやインスタンスタイプ、ネットワーク設定、ストレージの設定、オンデマンドインスタンスとスポットインスタンスの配分等が含まれる。また、起動設定は、既に起動済みのインスタンスの属性を使用して作成することも可能である。Auto Scalingグループに関連付けられる起動設定は1つだけであり、グループ作成後に変更することはできない。Auto Scalingグループに関連づける起動設定を変更する場合は、現在の起動設定をコピーした上で新たな起動設定を作成し、これを当該のAuto Scalingグループに紐づける。

ロードバランサとの連携

Auto Scalingで増減したインスタンスに対して適切にトラフィックが分散されるようにするためには、Elastic Load Balancingの受信トラフィックの通信先にAuto Scalingグループを指定する。Auto Scalingのヘルスチェックは、通常EC2のステータスチェックのみであるが、オプションでELBのヘルスチェックを用いてAuto Scalingグループのヘルスチェックを行う設定にすることも可能である。この場合、ELBから送られる定期的なPINGに応答しないなど、ELBのヘルスチェック合格しなかった場合、このインスタンスは異常ありと判定されて他のインスタンスに置き換えられる。

スケーリング

Auto Scalingでは、以下のスケーリング方法を実施可能である。

  • 現在のインスタンスレベルの維持
  • 手動スケーリング
  • スケジュールに基づくスケーリング
  • 要求に基づくスケーリング(動的スケーリング

CloudWatchのメトリクスを利用して複数のスケーリングポリシーを適用することも可能である。例えば、EC2のCPU使用率を指標としたポリシーと、SQSのメッセージ処理に関するメトリクスを指標としたポリシーを同時に適用する、といったような場合である。複数のポリシーが適用となった場合は、より影響を与えるポリシーの実行命令が優先される

スケジュールされたスケーリング

あらかじめ指定したスケジュールに沿って、スケーリングアクションが実行されるように指定することが可能である。スケーリングアクションが有効になる時間と、最小/最大サイズ希望するサイズを指定する。このスケジュールは、1回のみ実行することも定期的に実行することもできる。

スケジュールされたスケーリングを作成する場合、ほとんどの場合指定した時刻から数秒以内に実行されるが、最大2分ほど遅れる可能性もあるので留意が必要である。また、複数のスケジュールを同時刻に設定することはできない。

動的スケーリング

動的スケーリングは、以下の方法をサポートしている。

ポリシー名 トリガおよび動作
Target tracking scaling 特定のメトリクスのターゲット値を維持するようにスケーリング
Step scaling 複数のスケーリング調整値をトリガにスケーリング
Simple scaling 1つのスケーリング調整値をトリガにスケーリング

Simple scaling および Step scaling

トリガに基づいてスケーリングが実行される際には、以下の調整タイプに基づいてスケーリングが実行される。

調整タイプ 動作
ChangeInCapacity 指定した数だけ増減する
ExactCapacity 指定した数になるように増減する
PercentChangeInCapacity 割合指定する

また、Step scalingの場合は、新しく起動されたインスタンスがAuto Scalingグループに追加されるまでの待ち時間(ウォームアップ)を指定できる。

SQSに基づくスケーリング

SQSにキューが積み上がり、処理が遅延することがないようにするには、 SQSのデータを読み取り処理を行うEC2をAuto Scalingさせる必要がある。このAuto Scalingを適切にスケーリングさせるためには、 Amazon SQS メトリックスApproximateNumberOfMessagesを用いてキューの長さを測定した上で、1インスタンスあたりの処理能力を計算しどの程度スケーリングさせる必要があるか指定する。

SQSに基づくスケーリング

クールダウン

メトリクス値が短期間で増減し、その度にスケーリングが実行されることを防ぐために、クールダウン期間が設けられている。デフォルトのクールダウン値は300秒。クールダウン期間は新たなスケーリングは実行できない。なお、このクールダウンが有効なのは、Simple scalingのみ。

インスタンスの停止

スケールイン時に停止されるインスタンスは以下の条件で決定される。

  1. インスタンスが最も多いAZ
  2. 最も古い起動設定またはテンプレートを使用している
  3. 次の課金開始時間に近いインスタンス

終了時ポリシーはカスタマイズが可能である。また、終了から保護するインスタンスを指定することもできる。

ポリシー名 実行内容
OldestInstance 最も古いインスタンス
NewestInstance 最も新しいインスタンス
OldestLaunchConfiguration 最も古い起動設定のインスタンス
ClosestToNextInstanceHour 次の課金開始時間に近いインスタンス
Default デフォルト(上記)
OldestLaunchTemplate 最も古い起動テンプレート
AllocationStrategy オンデマンド/スポットの割り当て戦略に合わせて決定

ライフサイクルフック

インスタンスの起動時もしくは削除時に一時停止して、カスタムアクションを実行できる機能。ソフトウェア等をインストールできる。

ライフサイクルフック

スケーリングプロセスの中断と再開

スケーリングプロセスの1つ以上を停止し、あとで再開できる。

スケーリングプロセス 内容
Launch インスタンスを追加
Terminate インスタンスを削除
HealthCheck ヘルスチェック
ReplaceUnhealthy 異常なインスタンスを削除し代替インスタンスを作成
AZRebalance AZ間のバランスを調整
AlarmNotification CloudWatchからアラーム通知を受け取る
ScheduledActions スケジュールされたアクションを実施
AddToLoadBalancer ELBに追加

注意事項

Auto Scalingは、バーストトラフィックには対応できない

AWS ElastiCache(1)ElastiCacheの概要

Elasticacheとは

完全マネージドなRedis および Memcached。インメモリデータストアのため非常に高速で、大量のデータを処理したり既存のシステムを効率化することができる。

インメモリデータストアの目的は、データのコピーに超高速で低コストなアクセスを提供することである。キャッシュするデータを決定するためには、データ自体とそのアクセスパターンを把握する必要がある。また、これらのキャッシュされたデータは最新データではないという認識が必要で、使用するアプリケーションの特性上、古いデータでも許容されるのかどうかについて考察が必要である。

Elasticacheは、RedisとMemcachedをサポートしているが、できるだけシンプルな構成が必要であったり、大きなノードを実行する場合は、Memcachedを選択すべきである。

キャッシュできるデータは、S3RDS, DynamoDB streamsなど。

クラスタとレプリケーション

ElastiCacheは、メモリの断片であるノードという単位から構成され、これらを1〜6台まとめたグループをシャードと呼ぶ。クラスタモードを有効化したRedisでは、1〜15のシャードで構成される。無効化されている場合は常に1シャードのみである。

Redisクラスタ

クラスタ構成を有効化する場合には、ノード数を2以上とし、マルチAZ構成とすることが望ましい。クラスタ構成とするとデータは、シャードごとに分散されて保存され、クラスタの一部に異常が発生した場合には、正常なノード(サービス)にマスターが自動で移動する。また、異常が発生したノード(サービス)は再構成される。

Redisレプリケーション

リードレプリカを使用することで、耐障害性が向上するとともに読み込み能力がスケールアウトする。Redisに異常が発生した場合は、DNSが切り替わり、新しいノードにマスターが移動する。

キャッシング戦略

Redisにおけるキャッシュ方法は以下が用意されている。

方法 内容 利点 欠点
遅延書き込み データがキャッシュにない、もしくは古い場合に追加 容量, 障害の影響 遅延, データの古さ
書き込みスルー データがデータベースに書き込まれると常にデータを追加 データが新しい ノード拡張時にデータが存在しない, 不要なキャッシュ
TTLの追加 有効期限を指定し、期限切れはデータがないものとして扱う

AWS SQS(1)Amazon Simple Queue Serviceの概要

Amazon SQSについて

Amazon SQSは、マネージド型のメッセージキューイングサービス。SQSを使用することであらゆる量のソフトウェアコンポーネント間で、メッセージの送信や保存、受信が可能となる。

SQSでは、標準キューと呼ばれる配信順序がベストエフォート型のキューと、FIFOキューと呼ばれる送信順に配信されるキューの2つが用意されている。FIFOキューは、米国東部(バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、および 欧州 (アイルランド) リージョンのみで使用可能。

内容 標準キュー FIFOキュー
イメージ 標準キュー FIFOキュー
特徴 無限のスループット, 1回以上の配信, ベストエフォート 300件/秒, 1回のみ処理, 厳密な順序

キュー内のメッセージ数の上限は、12万件。メッセージ属性は、単一メッセージ内に10個まで。バッチ処理は、10メッセージまで同時に可能である。

AWSサービスとの連携

Amazon SQSは、他のAWSサービスと連携して使用することができる。

  • Amazon SNSでトピックが発行された際に、指定したSQS(標準キューのみ)対してキューメッセージを送信することができる。
  • キュー(標準キューのみ)にメッセージが着信した際に、これをトリガにLambda関数を事項させることができる。

キューの設定

キューを作成する際には、以下の項目を設定する。

設定項目 内容 デフォルト値 最大
可視性タイムアウト 受信したメッセージが他のキューから見えない時間 30秒 12時間
保持期間 メッセージの保持期間 4日 14日
最大メッセージサイズ 最大メッセージサイズ 256KB 256KB
配信遅延 初回配信時の遅延時間 0秒 15分
メッセージ受信待機時間 ロングポーリング時の待機時間。0秒に設定するとショートポーリングとなる。 0秒 20秒
コンテンツに基づく重複排除 (FIFOのみ) 本文のハッシュ値から重複排除IDを自動生成する 無効
デッドレターキュー 最大受信数を超えた場合の処理 無効 1000
サーバ側暗号化 CMKを用いたサーバ側暗号化の設定 無効

ロングポーリングとショートポーリング

ロングポーリングの場合、問い合わせの結果が空であった場合に、指定したメッセージ受信待機時間、SQSが待機してから応答を返す。これによって、空のレスポンス数を削減し、効率的なメッセージ取得が可能となる。

ショートポーリング

ショートポーリングは、問い合わせの結果に関わらず、常に応答を返す。

メッセージの送信

SQSのメッセージには本文に加えて、メッセージ属性を含むことができる。メッセージ属性は、キータイプ(String, Number, Binary)、から成る。

標準キー

1メッセージ単位で、配信遅延時間を設定することができる。

FIFOキー

メッセージグループIDメッセージ重複排除IDが入力必須。メッセージグループIDが同一のメッセージは、順序が保障される。キューの設定で、コンテンツに基づく重複排除を有効化していない場合は、メッセージ重複排除IDも入力する必要がある。

重複排除間隔は、5分

メッセージの受信

可視性タイムアウトの値は、受信ソフトウェアがメッセージを処理する時間を計測して決定する。具体的には、受信ソフトウェアが処理時間よりも長く、かつリトライまで待つ時間が必要以上に長くならない値に設定すべきである。

また、ロングポーリングを設定することで空の応答を減らしたり、バッチ処理によって複数のメッセージを処理することで、SQSの使用コストを削減することができる。

メッセージのエラー処理

デッドレターキューを設定することで、処理できない問題のあるメッセージをキャプチャすることが可能である。なお、デッドレターキューにメッセージが送信されても、元のメッセージのタイムスタンプは変更されないことに留意が必要

AWS Elastic Beanstalk(1)Elastic Beanstalkの概要

Elastic Beanstalkとは

Elastic Beanstalkは、Java、.NET、PHP、Node.js、Python、Ruby、Go などを使用して開発されたプログラムをApache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするためのサービス。インフラストラクチャの準備、運営から、アプリケーションスタック (プラットフォーム) の管理までをElastic Beanstalkが担当するため、ネットワーク設定や保守などの作業が不要

All at Onceローリング追加バッチとローリングイミュータブルブルー/グリーンなどの複数のポリシーからデプロイ方法を選択可能である。

Elastic Beanstalkを使用するにあたっての利用料金は不要で、デプロイしたAWSリソースに対する通常の使用料金のみ課金される。

使用するAWSリソースとその機能について、十分な知識を有する場合は、CloudFormationテンプレートを作成して運用することが望ましい。

Elastic Beanstalkのワークフロー

Elastic Beanstalkは、複数のアプリケーションを作成することが可能で、各アプリケーションは、Application VersionEnvironment(デプロイ済みのアプリケーション)やEnvironment TierEnvironmentの種別)、Environment Configuration(Environmentの設定)を有する。

Application Version

デプロイ可能なコードを指し、S3上でバージョン管理される。

Environment Tier

HTTP リクエストを処理し、ウェブアプリケーションを実行可能なWebサーバ環境と、Amazon SQSキューからタスクを引き出し、バッチ処理などをスケーラブルに実行可能なワーカー環境の2つから選択することが可能である。

Webサーバ環境

Webサーバ環境で構築されるEC2のソフトウェアスタックは、選択したコンテナタイプ(テンプレート)によって異なる。また、ホストマネージャー(HM)と呼ばれるソフトウェアコンポーネントも実行され、アプリケーションのデプロイの実行や、アプリケーションの監視等も行なっている。

Webサーバ環境

ワーカー環境

完了するまでに長い時間がかかる処理は、SQSを用いたワーカー環境で実行することが望ましい。ワーカー環境では、Amazon SQS キューを管理しタスクを実行するSQSデーモンが実行される。また、cron.yamlにタスクを記述することで、タスクの定期実行を行うことも可能である。

ワーカー環境

設計上の注意事項

スケーラビリティを確保する方法として、スケールアップ(垂直スケーリング)とスケールアウト(水平スケーリング)が存在が、スケールアップは過剰なリソースの準備となるなど問題点が存在するため、Elastic Beanstalkアプリケーションは、必要に応じてスケールアウトできる耐障害性に優れた疎結合コンポーネントを使用して、できるだけステートレスにする必要がある。

また、耐障害性を有するように、必ず故障から自動回復できるように設計、実装、およびデプロイする必要がある。

アプリケーションの管理

ソースコードをアップロードするたびに、新たなバージョンラベルを付与し、アプリケーションバージョンを作成する。古いアプリケーションバージョンは削除することも可能で、削除してもデプロイ済みのEnvironmentには影響を与えない

アプリケーションバージョンライフサイクルポリシーを設定することで、過去のバージョンを自動的に削除することが可能である。保有するバージョンの数、もしくは期間を設定でき、これを超えるとサービスが自動でアプリケーションバージョンを削除する。

アプリケーションは、ソースバンドルと呼ばれる処理プログラムを含む必要があり、ソースバンドルは、単一のZIPファイルまたはWARファイルで構成される必要がある。AWS Toolkit for Eclipse等を使用して開発を行なっている場合は、ツールが正しく構造化した上でZIP化してくれる。

Environmentの管理

1つのアプリケーションは、開発環境、統合環境、本番環境など複数のEnvironmentをデプロイすることができる。新たなEnvironmentを作成する場合は、

  • プラットフォーム
  • Application Version もしくは 新たなソースバンドル
  • Environment Tier(ウェブ環境/ワーカー環境)

等を指定する。作成したEnvironmentを終了すると、デプロイしたリソースの全てが削除される。

デプロイ

Environmentをデプロイする際には、複数のデプロイ方法の中から1つを選択することが可能である。

方法 デプロイメントポリシー 内容 制約 時間 ダウンタイム DNS変更
All at Once All at Once 現行のインスタンス全てに新たなコードを適用する
Rolling Rolling 現行のインスタンスに順に新たなコードを適用する 単一インスタンス環境では選択できない やや速
Rolling with additional batch Rolling with additional batch 新たなインスタンスと現行のインスタンスの一部に新たなコードを適用する 単一インスタンス環境では選択できない
Immutable Immutable 新たなインスタンスに新たなコードを適用する
Blue/Green Rolling with additional batch もしくは Immutable 新たなインスタンス(と現行のインスタンスの一部)に新たなコードを適用する 単一インスタンス環境では選択できない URL Swap もしくは DNS切り替え

Rollingを用いてデプロイする場合は、更新するバッチサイズを指定する。また、Route53の加重ラウンドロビンを利用することで、新バージョンを徐々に適用していくことも可能である。

プラットフォームの更新

アプリケーションを実行しているプラットフォームの更新を定期的に、もしくは手動で行うことが可能である。また、マイナーアップデートを含めるのか、パッチの適用だけなのかについても選択することができる。

AWS API Gateway(1)API Gatewayの概要

API Gatewayとは

API Gatewayは、完全マネージドのAPI作成サービス。受信したAPIコールと送出したデータ量に対して課金される。スロットリングによるトラフィック管理ができるため、DDoSやトラフィックの激増にも対応することが可能であり、リミットを超えたリクエストにはHTTPステータス 429が返却される。また、レスポンスはキャッシュ可能であり、レイテンシやトラフィック等を低減することができる。

API Gatewayは、IAMやCognitoを用いたアクセス認証署名付きAPIコールなどを使用することができるために柔軟にセキュリティ管理ができる。また、CloudWatchやCloudWatch Logsを用いた監視が可能で効率的なデバッグとモニタリングを実現している。

![API Gateway]https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/images/BackplaneArch.png

エンドポイント

API Gatewayは、特定のリージョンにデプロイされる。エンドポイントは以下の3種類がサポートされている。エンドポイントは、HTTPSのみサポートされている。

種類 内容
エッジ最適化 CloudFrontネットワークにデプロイ
リージョン リージョンにデプロイ。EC2 インスタンスまたは API と同じリージョン内のサービスから送られる場合に使用すると良い。
プライベート VPCからのみアクセス可能

リソースとメソッド

APIは階層構造となっており、リソースやメソッドをネストすることも可能。指定可能なメソッドは以下の通り。

種類 実行内容
POST 子リリースの作成
PUT 既存リソースの更新
DELETE リソースの削除
PATCH リソースの更新
HEAD テストシナリオに使用
OPTIONS 通信オプションに関する情報を取得する度に使用できる

CROSを有効にするためには、OPTIONSメソッドのプリフライトリクエストに対してAPIが応答することが必要であり、このリクエストに対して、HTTPステータス 200Access-Control-Allow-Method, Access-Control-Allow-Headers, Access-Control-Max-Ageヘッダを含んだレスポンスを返す。これらの挙動には、統合リクエスト/レスポンスのMockタイプを使用する。

リクエストに対して、 URLクエリ文字列パラメータHTTPヘッダHTTPボディを検証し、必須の項目が含まれているかやキャッシュを行うかなどを指定することができる。HTTPボディがapplication/json形式である場合は、JSON Schemaを用いてJSON形式を指定することもできる。

統合リクエスト/レスポンスとマッピングテンプレート

API Gatewayとバックエンドとを接続する内部インタフェース。マッピングテンプレートを用いることで、フロントエンド(API Gateway)とバックエンドのデータ形式を変換することができる。

  • Lambda関数の呼び出し
  • 他のAWSサービスの呼び出し
  • HTTPウェブサイトのアクセス

の3つのバックエンドへのアクセスに対応している。Lambdaプロキシ統合を用いることで、API GatewayとLambdaがより協力に結合され、リクエストヘッダやパス変数などがLambdaに渡される。また、HTTPプロキシとして使用することも可能である。

デプロイ

APIを利用可能とするためには、APIのリソースおよびメソッドのスナップショットであるAPIのデプロイを実施する必要がある。APIをバージョン管理できるために、新しいバージョンを簡単にテストしリリースすることが可能である。

1アカウント1リージョンあたりのAPIの上限は、10000RPSである。これ以上のアクセス負荷にも耐えうる値とする場合は上限緩和申請が必要となる。

AWS RDS(1)Relational Database Serviceの概要

RDSとは

RDSは、AWS内でRDBSを簡単に設定、運用、スケールできるサービスで、データベースのセットアップやパッチ適用、バックアップなどの管理タスクを自動化している。対応しているRDBSは、Amazon AuroraMySQLMariaDBOracleMicrosoft SQL ServerPostgreSQLの6種類である。一部制限事項も存在するため、この制限事項とのトレードオフが許容できない場合は、EC2上でRDBSを稼働させることも検討する。

管理負荷を軽減

RDBSにわずか数分でアクセス可能で、CloudWatchによる監視にも対応しているため、パフォーマンスの問題を簡単に検出することが可能である。また、ソフトウェアのパッチが自動的に適用されるために、常に最新の状態が維持されている。

パフォーマンス

汎用(SSD)ストレージプロビジョンドIOPS(SSD)ストレージから選択することが可能である。

スケーラビリティ

最大32vCPUおよびRAM244GiBまで拡張することが可能で、数分以内にスケーリングすることができる。また、ストレージサイズも柔軟に拡大が可能で、稼働中にダウンタイムなしに最大16TBまでストレージの拡張を行うことができる。また、リードレプリカを使用(=Amazon AuroraMySQLMariaDBPostgreSQLのみ対応)することで、読み込み負荷の高い処理をスケールアウトすることができる。

可用性と耐久性

自動バックアップ機能によって自動的(=1日に1回)に、もしくは任意の時点のスナップショットを保存することもでき最大35日(デフォルトは7日間保持)まで保存可能。また、RDは、5分に1回トランザクションログを保存しているため、これを用いて新たなインスタンスを起動(ポイントインタイムディカバリ)が可能。マルチAZ配置オプションを使用することで、異なるAZのスタンバイインスタンスにデータを複製し、可用性を向上させることができ、ハードウェア障害が発生した場合には、自動でフェールオーバされる。DNSでCNAMEが書き換えられ切り替えには数分要する。なお、スナップショット実行時は、短時間I/Oが停止することに注意が必要

セキュリティ

KMSを使用してデータベースを暗号化することが可能。また、VPC上で稼働させることで独自のネットワーク上で外部と隔離された状態で稼働できる。

AWS SNS(2)モバイルプッシュ通知

モバイルプッシュ通知

AWS SNSは、モバイルデバイスのアプリケーションにプッシュ通知メッセージを直接送信できる。通知可能なサービスは、

  • Amazon Device Messaging (ADM)
  • iOS および Mac OS X 用の Apple Push Notification Service (APNS)
  • Baidu Cloud Push (Baidu)
  • Android 用 Google クラウドメッセージング (GCM)
  • Windows Phone 用 Microsoft プッシュ通知サービス (MPNS)
  • Windows プッシュ通知サービス (WNS)

である。

プッシュ通知サービスは、登録時にデバイストークンを返すため、SNSはこのデバイストークンを元にモバイルエンドポイントを作成しプッシュ通知を行う。モバイルプッシュ通知を行うためには以下の手順が必要となる。

  1. 認証情報を上記サービスに対して要求し認証情報を取得する
  2. トークンを上記サービスに対して要求しトークンを取得する
  3. プラットフォームアプリケーションオブジェクトを作成する
  4. プラットフォームエンドポイントオブジェクトを作成する
  5. メッセージを送信する

AWS SNS(1)Simple Notification Serviceの概要

Amazon SNSについて

Amazon SNSは、マネージド型のメッセージ発行/購読サービス。SNSは、発行者からのメッセージを受信し、LambdaやSQS、Email、SMSなどの購読者に対してこれらを送信することが可能である。SNSを使用するときは、その所有者としてトピックを作成し、発行者と購読者を定義するポリシーを策定する。

SNSの流れ

トピック名は他と識別できるユニークな名称であり、発行者はこのARNを利用してメッセージをこのトピックに送信する。購読者は、送信されたメッセージを購読するかどうか判断し、購読を許可した場合に全てのメッセージが受信可能となる。発行者は、各配信先ごとに異なるメッセージを送信することも可能である。トピックの所有者は、購読情報を全て削除(クリーンアップ)することも可能となっている。

SNSの機能とシナリオ

SNSは以下のようなシナリオで動作させることができる。

ファンアウト

発行者からのメッセージをSNSが複製することで、並列非同期処理が可能となるシナリオ。並行処理を行なったり、本番環境のデータをテスト環境に入力するために使用できる。

アラートの送信

アプリケーションやシステムからの出力に対してあらかじめ閾値を定めておき、それを超えた場合にメッセージが送信される。

EメールおよびSMSの送信

特定の購読者へEメールおよびSMSの送信する。

モバイルプッシュ通知

モバイルアプリケーションへ通知を送信する。

ポリシー

所有者は各トピックに対して、「どの購読者(=プリンシパル)がどの配信先(=リソース)を受信できるか。」「どの発行者(=プリンシパル)がメッセージの発行を行えるか」などのアクションを定めることができる。ポリシーのデフォルトは拒否であるため、許可を与えるためにはポリシーを明示しなくてはならない。また、ポリシーでは、リトライ回数や遅延時間等も指定することができる。

AWS S3(3)S3の概要

S3 (Simple Storage Service)とは

S3は、どこからの、どのような量のデータ(通常100バケットまで1ファイル5TBまで)でも保存と取得が可能なオブジェクトストレージ。データは3箇所以上のデータセンタへ自動複製され、
99.999999999% の耐久性を提供している。高い耐久性、可用性、スケーラビリティー、数多くのセキュリテイ機能を持つ。AWS AthenaやS3 Selectを用いることで簡単に、S3内のデータに対してビッグデータ解析を行うことが可能で、さまざまな方法でS3へのデータ転送を行うことができる。

S3には、S3 StanderdS3 Standerd(低頻度アクセス)S3(1ゾーン/低頻度アクセス)Amazon Glacierの4つのストレージが用意されている。S3(1ゾーン/低頻度アクセス)は、地震や洪水といった災害によるアベイラビリティーゾーンの物理的な損失時にデータを失う可能性がある。S3 Standerd(低頻度アクセス)とS3(1ゾーン/低頻度アクセス)は、他の手法で復元可能なデータや原本のコピーを保存する目的で使用する。VPCエンドポイントを用いることで、同一リージョンのVPC内からセキュアにファイル転送を行うことが可能である。また、複数の暗号化、監査ログ、バージョニングにも対応している。

S3は、キーバリュー型のストアであるので、フラットな構造であり、ディレクトリや階層構造は存在しない。フォルダやファイル名に相当するのがキーであり、スラッシュ文字によってディレクトリ構造のように見せることができる。

タイプ 堅牢性 備考
Standard 99.999999999% 3箇所以上にデータ複製
Standard(低頻度アクセス) 99.999999999% 安価だが読み出しに課金される
1ゾーン(低頻度アクセス) 99.99% 低い堅牢性。オブジェクト毎に指定可能。
Glacier 99.999999999% 取り出しに時間(3-5時間)とコストを要する

S3は、ファイルを複数のチャンクに分割して並列アップロードを行う、Multipart Uploadに対応している。ファイルサイズが100MBを超える場合は、このMultipart Uploadを使用することが奨励されている。AWS CLIでは、ファイルサイズによって自動判別されてこの機能が利用される。Glacierに格納されたデータの復元時には、迅速(Expedited)(=1-5分)、標準(Standard)(=3-5時間)、大容量(Bulk)(=5-12時間)の3種類が用意され、それぞれ実行単価が異なる。

また、静的なファイルをS3のみでホステイング可能なWEBサイトホスティング機能を有している。独自ドメインの指定クロスドメインCloudFrontとの連携なども可能。

セキュリティ

アクセス管理

S3はデフォルトでは全てプライベートアクセス権限となっている。アクセス権限は、バケットやオブジェクト単位で指定可能である。IAMユーザ単位でS3へのアクセス権限を指定できる「ユーザポリシー」(=IPアドレスも指定可能)、バケット毎にアクセス権限を指定できる「バケットポリシー」(=IPアドレスレンジやMFA等も指定可能)、バケットやオブジェクト単位で指定可能な「ACL」などが存在する。バケットポリシーは、バケットの所有者のみが設定でき、またACLは、バケットACLよりもオブジェクトACLが優先される。

暗号化

サーバサイド暗号化、クライアントサイド暗号化の両方に対応している。デフォルト暗号化を指定することも可能である。

Pre-signed Object URL

一定時間のみアクセスを許可するURLを発行できる。

通知

バケットにイベントが発生した際に、SNS、SQS、Lambdaに対して通知を行うことが可能。

モニタリング

CloudWatchとCloudTrailによるモニタリングが可能。

料金

通常ははストレージおよびデータ転送に掛かるコスト全ては、バケットの所有者が負担する。しかし、リクエスタ支払いバケットに指定した場合は、リクエストおよびバケットからのデータダウンロードに掛かるコストは、 所有者ではなくリクエストを実行したリクエスタが支払う

バージョニング

バージョニングが有効となったオブジェクトに対してDELETE処理を行った場合、全てのバージョンはストレージに残り削除マーカーが付加される。当該オブジェクトをGETしようとすると404 Not Foundが返されるが、オブジェクトバージョンを指定すると当該オブジェクトを取得可能である。

ライフサイクル

ライフサイクルと呼ばれる、オブジェクトに対するアクションルールをXMLにより規定できる。ライフサイクルによって、オブジェクトを異なるストレージクラスに移行したり、オブジェクトを削除したりすることができる。Glacierは削除や上書き、アーカイブリクエスト、復元に対して費用が発生する。ただし90日以上アーカイブされているオブジェクトに対する削除および上書きは無料である。

AWS(3)監視およびログサービス

AWS Configとは

AWS Configは、リソースごとの設定項目を生成し、履歴としてこれを保持するため、全ての変更を追跡することが可能で、AWSリソース間の関係と設定の履歴などを確認することができる。また、設定が最適であるかの評価設定のスナップショットの取得設定変更時の通知IAMポリシーの確認などを行うことが可能である。

設定項目は、S3バケットに蓄積することが可能で、データはJSON形式でS3に6時間ごとに送信される。また、リソースが変更されたタイミング等で、Amazon SNSを用いてEメール等で通知することも可能である。

設定履歴と設定項目、設定レコーダ

設定履歴は、特定期間の特定リソースに関する設定項目のコレクションである。設定項目は、アカウント内のサポートされているAWSリソースの属性を記録したものである。設定レコーダは、これらのリソースの設定を設定項目としてアカウントに保存する。

設定スナップショットと設定ストリーム

設定スナップショットは、設定項目のコレクションで記録対象のリソースの全体像を示す。また、設定ストリームは、これらの記録しているリソースの設定項目の自動更新リストを示す。

AWS Configの仕組み

AWS Configは、サポートされているAWSリソースを検出し、リソースごとに設定項目を生成し、その記録を履歴として保持する。Configはリソースごとに、DescribeもしくはListのAPIコールによって、リソースの全ての変更を追跡するConfigルールを利用することで、定期的にこのルールに照らして、リソースの設定の評価を行うことができる。

AWS Configルール

AWS Configルールは、各リソースの望ましい設定を確認することが可能で、事前に定義済みのルールが用意されている。また、各ユーザがカスタムルールを作成することも可能となっている。AWS Configは、このルールを参照して、現在の設定を評価する。

マネージドインスタンスの記録

AWS Configを用いて、EC2やオンプレミスサーバのソフトウェアインベントリの変更を記録可能である。

課金

記録される設定項目ごとに 0.003 USDの課金が発生し、これに加えてS3やSNSを使用する場合には、これらのサービスの使用料金が課金される。

AWS Cloudtrailとは

AWSサービスによって実行されたアクションを記録するサービス。この記録を基にAWS アカウントのアクティビティの分析を行い、これらに対応することが可能である。デフォルトで有効にされており、90日間のログが履歴として保持される。また、それ以上保持したい場合には、トレイル機能を用いて、S3やCloudWatch Logs等にイベント配信することも可能である。トレイルは、全リージョンに対して、もしくは特定のリージョンの情報のみを保持することが可能で、作成後に設定内容を変更することもできる。デフォルトではS3の暗号化機能を用いて暗号化され、アクションの15分以内にデータが送信される。

Cloudtrailイベントとトレイル

Cloudtrailイベントには、管理イベントとデータイベントの2種類が存在するが、トレイルにはデフォルトでは管理イベントのみが記録される

課金

デフォルトでは無料で90日間のログを保持しており、これに加えて1つのトレイル作成までは無料となっている。S3やSNSを使用する場合には、これらのサービスの使用料金が課金される。