VPC Flow Logs で取得したフローログを CloudWatch Logs に発行する

はじめに

VPC Flow Logs で取得したフローログを CloudWatch Logs に発行する方法についてまとめる。

VPC Flow Logs とは

VPC のネットワークインターフェース(≒ ENI)との間で行き来する IP トラフィックに関する情報をキャプチャしてログに記録する機能であり、取得したデータは CloudWatch Logs または S3 に発行できる。 フローログはネットワークトラフィックのパスの外で収集されるため、ネットワークのスループットレイテンシーに影響を与えることなく取得できる。

フローログは VPC、サブネット、特定の ENI に対して作成できる。 ログのキャプチャレベルは下記のいずれかが設定できる。

ここからの作業の前提

  • AWS マネジメントコンソールから手動で作業を進める。
  • AdministratorAccess 権限を持つ IAM ユーザにて作業を行う。この作業では VPC、IAM、CloudWatch Logs の操作を行うため、必要な権限を持つ IAM ユーザで作業を行う必要がある。
  • 東京リージョンで作業を行う。

フローログを CloudWatch Logs に発行する

CloudWatch Logs へのフローログの発行」を参考に取得方法を見ていく。

準備

準備として下記の作業を行う。

  • IAM ロールの作成
  • CloudWatch Logs のロググループの作成

IAM ロールの作成

VPC Flow Logs にフローログを CloudWatch Logs に発行するための権限を与える必要がある。

IAM のコンソール画面を開き、「ロール」を選択する。

IAM のコンソール画面
IAM のコンソール画面

「ロールを作成」を選択する。

IAM ロールのコンソール画面
IAM ロールのコンソール画面

「信頼されたエンティティタイプ」では「AWS のサービス」、「ユースケース」では「EC2」を選択して、「次へ」を選択する。

「信頼されたエンティティを選択」の画面
「信頼されたエンティティを選択」の画面

「許可を設定」では、何も設定せずに「次へ」を選択する。 許可(権限)は後続の手順で設定する。

「許可を設定」の画面

「許可を設定」の画面
「許可を設定」の画面

「名前、確認、および作成」では「ロール名」(ここでは「network-demo-role」)のみ設定して、「ロールを作成」を選択する。 信頼されたエンティティは後続の手順で設定する。

「名前、確認、および作成」の画面

「名前、確認、および作成」の画面
「名前、確認、および作成」の画面

IAM ロールの作成が正常終了したことを確認する。 今回作成したロール(ここでは「network-demo-role」)を選択して、詳細画面を開く。

IAM ロールの作成完了画面
IAM ロールの作成完了画面

今回作成した IAM ロールに CloudWatch Logs にログを発行するための権限を設定する。 「アクセス許可を追加」のプルダウンメニューを開き、「インラインポリシーを作成」を選択する。

IAM ロールの「許可ポリシー」の画面
IAM ロールの「許可ポリシー」の画面

「ポリシーの作成」で「JSON」タブを選択する。 CloudWatch Logs にログを発行するための最小の権限は下記の通り。 これをコピー&ペーストして、「ポリシーの確認」を選択する。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": "*"
    }
  ]
}   

「ポリシーの確認」では「名前」(ここでは「network-demo-cloudwatch-logs-policy」)を設定し、「概要」に表示されている権限に問題がないことを確認して、「ポリシーの作成」を選択する。

「ポリシーの確認」画面
「ポリシーの確認」画面

「許可ポリシー」に今回作成したポリシー(ここでは「network-demo-cloudwatch-logs-policy」)が表示されていることを確認する。

IAM ロールの「許可ポリシー」の画面
IAM ロールの「許可ポリシー」の画面

「信頼関係」タブを選択して、「信頼ポリシーを編集」を選択する。

IAM ロールの「信頼関係」の画面
IAM ロールの「信頼関係」の画面

VPC Flow Logs に信頼ポリシー(IAM ロールを Assume するための権限)を付与する。 下記をコピー&ペーストして、「ポリシーを更新」を選択する(「Service」の値が差分)。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
} 

CloudWatch Logs のロググループの作成

ログの送付先となる CloudWatch Logs のロググループを作成する。 なお、ログストリームはネットワークインターフェースごとに自動で作成される。

CloudWatch のコンソール画面を開く。 左側メニューで「ログ」を開き、「ロググループ」を選択する。

CloudWatch のコンソール画面
CloudWatch のコンソール画面

「ロググループ」で「ロググループを作成」を選択する。

ロググループの画面
ロググループの画面

「ロググループの詳細」で「ロググループ名」(ここでは、「network-demo-log-group」)を設定し、「作成」を選択する。

「ロググループを作成」の画面
「ロググループを作成」の画面

ロググループの作成が正常終了したことを確認する。

ロググループの作成完了画面
ロググループ の作成完了画面

フローログを作成する

フローログは VPC、サブネット、特定のネットワークインターフェースに対して作成できるが、ここでは最も取得範囲の広い VPC に対して作成する。

VPC のコンソール画面を開き、フローログを設定したい VPC(ここでは、「network-demo-vpc」)の詳細画面を開く。 「フローログ」のタブを選択して、「フローログを作成」を選択する。

VPC の「フローログ」の画面
VPC の「フローログ」の画面

「フローログを作成」の画面に遷移する。

「フローログを作成」の画面
「フローログを作成」の画面

この画面での設定項目と説明、今回の設定値を下記にまとめる。 設定値の入力完了後に、「フローログを作成」を選択する。

設定項目 説明 設定値
名前 フローログの名前を設定する。オプション設定 network-demo-flow-log-vpc
フィルタ キャプチャするトラフィックのタイプを設定する。「承諾(ACCEPT)」「却下(REJECT)」「すべて(ACCEPT と REJECT の両方)」から選択する すべて
最大集約間隔 パケットのフローがキャプチャされてからフローログレコードに集約されるまでの間隔の最大時間。「10分間」「1分間」から設定する 10分間
送信先 フローログデータを公開する宛先。「CloudWatch Logs に送信」「Amazon S3 バケットに送信」から選択する CloudWatch Logs に送信
送信先ロググループ フローログデータが発行される CloudWatch Logs ロググループの名前を選択する。新しいログストリームは、モニタリングされている各ネットワークインターフェース(ENI)に対して作成される network-demo-log-group
IAM ロール CloudWatch ロググループに発行するアクセス許可を持つ IAM ロールを選択する network-demo-role
グレコードの形式 フローログレコードに含めるフィールドを指定する。「AWS のデフォルト形式」「カスタム形式」から選択する AWS のデフォルト形式

フローログの作成が正常終了したことを確認する。

フローログの作成完了画面
フローログの作成完了画面

ログの確認

VPC 内に EC2 インスタンスを作成し、そのインスタンスと通信した後に最大集約間隔として設定した10分程度待つと、CloudWatch Logs に下記のようなフローログが記録される(アカウント ID と VPC に設定した CIDR ブロック以外の IP アドレスを念のためマスクしている)。

フローログの例
フローログの例

EC2 インスタンスSSH(#22/TCP)で接続した際に記録されたフローログは下記の通り。 なお、AWS アカウント ID と接続元 IP アドレスは置き換えをしている。

2 123456789012 eni-03f3d84b79d1edb78 10.0.22.65 aaa.bbb.ccc.ddd 22 53443 6 44 6253 1647819365 1647819419 ACCEPT OK

VPC Flow Logs に関する補足事項

フローログレコード

  • フローログに記録されるレコードは AWS のデフォルト形式で下記が設定される。カスタマイズも可能。

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

フィールド 説明
version VPC フローログバージョン。デフォルト形式では2が設定され、カスタム形式の場合は最も高いバージョンが設定される
account-id トラフィックが記録されるネットワークインターフェイスの所有者の AWS アカウント ID
interface-id トラフィックが記録されるネットワークインターフェイスの ID
srcaddr 受信トラフィックの送信元の アドレスか、ネットワークインターフェイスにおける送信トラフィックのネットワークインターフェイスIPv4 または IPv6 アドレス
dstaddr 送信トラフィック送信先アドレスか、ネットワークインターフェイスにおける受信トラフィックのネットワークインターフェイスIPv4 または IPv6 アドレス
srcport トラフィックの送信元ポート
dstport トラフィック送信先ポート
protocol トラフィックの IANA プロトコル番号
packets フロー中に転送されたパケットの数
bytes フロー中に転送されたバイト数
start 集約間隔内にフローの最初のパケットが受信された時間(UNIX 秒)
end 集約間隔内にフローの最後のパケットが受信された時間(UNIX 秒)
action トラフィックに関連付けられたアクション。「ACCEPT(承諾)」「REJECT(拒否)」のいずれか
log-status フローログのロギングステータス。「OK(送信先に正常に記録された)」「NODATA(集約間隔内に通信がなかった)」「SKIPDATA(集約間隔内に何らかの問題があり一部のログがスキップされた。)」

最大集約間隔

  • 最大集約間隔は「10分間」または「1分間」のいずれかが設定できる。
  • 「最大」という表現はログの取得とログの発行に時間がかかるため。実際には下記の時間を目安にベストエフォートで配信される。
    • CloudWatch Logs: 5分
    • S3: 10分
  • Nitro ベースのインスタンス(例:M5、C5、R5 など)のネットワークインターフェースの場合は、設定した最大集約間隔に関係なく常に1分以下となる。

フローログの活用

下記のような利用方法が考えられる。

  • フローログを定常運用で定期的に監査して、自社サービスの利用の傾向(時間やアクセス数など)や不審なアクセスの有無などを調査する。
  • CloudWatch Logs のメトリクスフィルタと CloudWatch Alarms を利用して、特定の条件を満たした場合にアラートを発報する。
  • GuardDuty のインプットとして VPC 内の脅威の検知を行う。

参考文献

Amazon GuardDuty をセットアップし、AWS Chatbot による Slack 通知を設定する

はじめに

Amazon GuardDuty(GuardDuty) のセットアップ方法についてまとめる。 また、GuardDuty が脅威を検知した場合、速やかにその検知内容を確認して対処の要否を判断できることが重要である。 そのための手段として、検知結果を Slack に通知する方法についてもまとめる。

GuardDuty とは

AWS が提供する機械学習を用いたクラウドネイティブな脅威検知のマネージドサービス。 下記のログをデータソースとして脅威の検出を行い、検出結果を重要度(HIGH、MEDIUM、 LOW)で提示してくれる。

  • CloudTrail イベントログ
  • CloudTrail 管理イベント
  • CloudTrail S3 データイベント
  • Kubernetes 監査ログ
  • VPC Flow Logs
  • Route 53 の DNS ログ

ポートスキャンなどの悪意のあるスキャン、EC2 インスタンスへの DoS 攻撃、不正な API の呼び出しや予期しないリソースへのアクセスなども脅威として検出できる。 GuardDuty で検出できる脅威は「結果タイプ」を参照のこと。

また、EventBridge とも統合されており、GuardDuty が脅威を検知したことをトリガーにして E メールやチャットツールに通知の送付もできる。

ここからの作業の前提

  • AWS マネジメントコンソールから手動で作業を進める。
  • AdministratorAccess 権限を持つ IAM ユーザにて作業を行う。この作業では GuardDuty、Amazon EventBridge(EventBridge)、Amazon SNSSNS)、AWS Chatbot(Chatbot)、IAM の操作を行うため、必要な権限を持つ IAM ユーザで作業を行う必要がある。
  • 東京リージョンで作業を行う。

GuardDuty をセットアップする

AWS マネジメントコンソールでの作業の場合、GuardDuty は有効化のボタンを押下するだけでセットアップが可能である。

AWS マネジメントコンソールにログインし、GuardDuty のコンソール画面に移動する。 「今すぐ始める」を押下する。

GuardDuty のコンソール画面
GuardDuty のコンソール画面

表示されているメッセージを確認して、「GuardDuty の有効化」を押下する。

GuardDuty のセットアップ画面
GuardDuty のセットアップ画面

なお、ここで GuardDuty を有効化すると、GuardDuty に対して下記のアクセス権限と信頼ポリシーが付与される。 この内容は「サービスロールのアクセス権限の表示」を押下すると確認できる。

付与されるアクセス権限は下記の通り。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeImages",
        "ec2:DescribeVpcEndpoints",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcPeeringConnections",
        "ec2:DescribeTransitGatewayAttachments",
        "organizations:ListAccounts",
        "organizations:DescribeAccount",
        "s3:GetBucketPublicAccessBlock",
        "s3:GetEncryptionConfiguration",
        "s3:GetBucketTagging",
        "s3:GetAccountPublicAccessBlock",
        "s3:ListAllMyBuckets",
        "s3:GetBucketAcl",
        "s3:GetBucketPolicy",
        "s3:GetBucketPolicyStatus"
      ],
      "Resource": "*"
    }
  ]
}

信頼ポリシーは下記の通り。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "guardduty.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole"
      ]
    }
  ]
}

有効化に成功すると、下記のような「結果」の画面に遷移する。

GuardDuty のコンソール画面(有効化後)
GuardDuty のコンソール画面(有効化後)

なお、GuardDuty はリージョンサービスであり、有効化の作業を行なったリージョンでのみで有効化される。 セキュリティ向上のためには全リージョンでの有効化が望ましい。 リージョン数も多いので、CloudFormation の StackSets などを利用して有効化すると良い(参考:「一発でGuardDutyを全リージョン有効化して通知設定するテンプレート作った」)。

AWS Chatbot による Slack 通知を設定する

ここでは AWS Chatbot(Chatbot)を使い、Slack の通知を設定する。 大きく下記の作業を実施する。

  • SNS のトピック作成
  • EventBridge のルール作成
  • Chatbot の設定

SNS のトピック作成

SNS のコンソール画面を開く。 画面の右上の「トピックの作成」で、「トピック名」(今回は「guardduty-notification」)を設定し、「次のステップ」を押下する。

SNS のコンソール画面
SNS のコンソール画面

「トピックの作成」の「詳細」で下記を確認する。 その他はデフォルトのままとして、「トピックの作成」を押下する。

  • タイプ:スタンダード
  • 名前:前の画面で設定した「トピック名」

トピックの作成画面
トピックの作成画面

トピックの作成に成功した場合、下記のような画面が表示される。

トピックの作成完了画面
トピックの作成完了画面

EventBridge のルール作成

EventBridge のコンソール画面を開く。 画面の右上の「新しいルールを作成」で、「ルールを作成」を押下する。

EventBridge のコンソール画面
EventBridge のコンソール画面

「ルールの詳細を定義」の画面で、下記のように設定して、「次へ」を押下する。

分類 設定項目 説明 設定値
ルールの詳細 名前 ルールの名前を設定する。 任意(今回は「guardduty-rule」)
説明 ルールの説明を記載する。 設定しない
イベントバス イベントの発行元のリソースの種類を設定する。AWS サービス(GuardDuty)なので「default」を選択する。 default
選択したイベントバスでルールを有効にする イベントバスの有効/無効を設定する。 有効化
ルールタイプ ルールがイベントもしくは時間駆動のどちらなのかを設定する。 イベントパターンを持つルール

「イベントパターンを構築」の画面で、下記のように設定して、「次へ」を押下する。

分類 設定項目 説明 設定値
イベントソース イベントソース イベントの送信元となるイベントソースを選択する。 AWS のサービス
イベントパターン イベントソース イベントソースとなる AWS サービス名を選択する。 GuardDuty
イベントタイプ イベントのタイプを選択する。 GuardDuty Finding

上記の設定をすると、「イベントパターン」に下記が示される。 カスタマイズも可能だが、今回はこれで問題ないため、「次へ」を選択する。

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"]
}

「ターゲットを選択」の画面で、下記のように設定して、「次へ」を押下する。

分類 設定項目 説明 設定値
ターゲット1 ターゲットタイプ イベントの送信先となるターゲットのタイプを選択する。 AWS のサービス
ターゲットを選択 イベントがイベントパターンに一致した場合に呼び出すターゲットを選択する。 SNS トピック
トピック メッセージを発行する SNS トピックを選択する。 今回は「guardduty-notification」

「タグを設定」の画面では、必要に応じてタグを設定する。 今回は設定せずに「次へ」を選択する。

「レビューと作成」の画面で、設定に問題がないことを確認し、「ルールを作成」を選択する。

「レビューと作成」の画面
「レビューと作成」の画面

ルールの作成に成功した場合、下記のような画面が表示される。

ルールの作成成功画面
ルールの作成成功画面

Chatbot の設定

チャットクライアントの設定

Chatbot のコンソール画面を開く。 画面の右上の「チャットクライアントを設定」で、「チャットクライアント」に「Slack」を設定し、「クライアントを設定」を選択する。

Chatbot のコンソール画面
Chatbot のコンソール画面

Slack の認証ページにリダイレクトされるので、通知先となる Slack のワークスペースにサインインする。 処理を進めると、下記のような Chatbot と Slack の連携を設定する画面が表示される。 内容を確認して、「許可する」を選択する。

Chatbot と Slack の連携の設定画面
Chatbot と Slack の連携の設定画面

Chatbot と Slack の連携に成功すると、下記のような画面が表示される。 「新しいチャネルを設定」を選択する(矢印のどちらでも可)。

Chatbot と Slack の連携の成功画面
Chatbot と Slack の連携の成功画面

チャネルの設定

「Slack チャネルを選択」の画面で、下記のように設定して、「次へ」を押下する。

分類 設定項目 説明 設定値
設定の詳細 設定名 設定の名前を設定する。 任意(今回は「guardduty-notification」)
ログ記録 CloudWatch Logs へのログの記録の有無を設定する。 設定しない
Slack チャネル チャネルタイプ 通知先となる Slack チャネルの公開レベルを選択する。 パブリック
パブリックチャネル名 通知先となる Slack チャネル名を選択する。 notification
アクセス許可 ロール設定 チャネルのメンバーに付与するアクセス許可を設定する。 チャネル IAM ロール
チャネル IAM ロール チャネルに設定する IAM ロールを選択する。 テンプレートを使用して IAM ロールを作成する
ロール名 IAM ロールの名称を設定する。 任意(今回は「AWSChatbot-role」)
ポリシーテンプレート IAM ロールに設定する権限をポリシーテンプレートから設定する。 通知のアクセス許可
ガードレールポリシー ポリシ名 IAM ロールでチャネルのメンバーに付与するアクセス許可の制約を設定する(ガードレールポリシーで許可していない操作は実行できない)。 チャネル IAM ロールより広い権限を付与(今回は「AdministratorAccess」)
通知 SNS トピック リージョン 購読する SNS トピックがあるリージョンを選択する。 「アジアパシフィック - 東京」
トピック 購読する SNS トピックを選択する。 今回は「guardduty-notification」

チャネルの設定に成功すると、下記のような画面が表示される。

チャネルの設定の成功画面
チャネルの設定の成功画面

デスクトップアプリなどで Slack を開き、App 配下に「aws」が存在することを確認する。 存在しない場合は、「アプリを追加する」から「AWS Chatbot」を追加する。

Slack の App に Chatbot が追加された画面
Slack の App に Chatbot が追加された画面

Chatbot のコンソール画面で、今回設定したチャネル(「guardduty-notification」)のチェックボックスにチェックをつけて、「テストメッセージを送信」を選択すると、Chatbot - Slack 間の疎通をテストできる。

Slack - Chatbot 間の疎通確認
Slack - Chatbot 間の疎通確認

Slack に通知されたテストメッセージ
Slack に通知されたテストメッセージ

通知のテスト

GuardDuty では脅威の検知結果のサンプルを生成できる。 サンプルの生成をトリガーに Slack に検知結果が通知されることを確認する。

(注意)このテストで100通程度の Slack 通知が飛ぶ点に注意すること。

GuardDuty のコンソール画面を表示して、左側のメニューの「設定」を選択する。 「設定」画面の下の方にスクロールし、「結果のサンプル」の「結果サンプルの生成」を選択する(ボタン押下後の変化が少ないが問題ない)。

その後、左側のメニューの「結果」を選択する。 GuardDuty の脅威の結果画面を確認すると、脅威の検知結果のサンプルが表示されている。

(注意)この結果はあくまでサンプルであり、実際に攻撃を受けている訳ではない。

GuardDuty の結果画面
GuardDuty の結果画面

GuardDuty の結果サンプルの生成画面
GuardDuty の結果サンプルの生成画面

デスクトップアプリなどで Slack を開くと、下記のような通知が届く。 筆者がテストした際は通知が届くまでに少し時間がかかったので、届かない場合でも数分待つと届く。

GuardDuty の脅威の通知結果
GuardDuty の脅威の通知結果

Severity(重要度)は下記の通り。

  • HIGH: 赤
  • MEDIUM: 黄
  • LOW: 青

検知結果の意味は、「結果タイプ」に記載されている。

上図の「Finding type: Backdoor:EC2/DenialOfService.Udp」は、EC2 インスタンスUDP による DoS 攻撃を受けている可能性を示すもの。

補足

GuardDuty の利用料金

  • GuardDuty の利用料金は、分析したログのイベント数やデータサイズに対する従量課金となる。
  • 初回の有効時から30日間は利用料が無料となるが、GuardDuty のコンソール画面の「使用状況」から予測コストを確認できる(※ 下図は有効化の初日に確認したため、予測が0ドルになっている)。

GuardDuty の使用状況と予測コストの画面
GuardDuty の使用状況と予測コストの画面

GuardDuty の停止と無効化

  • GuardDuty による脅威検知を一時的に停止したい場合は「GuardDuty の停止」を選択する。再開も可能。
  • GuardDuty による脅威検知をやめたい場合は「GuardDuty の無効化」を選択する。
  • (注意)GuardDuty の無償期間は30日間なので、課金を停止したい場合は期限切れまでに対処する必要がある点に注意する。

GuardDuty の停止と無効化の画面
GuardDuty の停止と無効化の画面

参考文献

Amazon SageMaker Canvas を使ってノーコードで AI による予測をする

はじめに

こちらは APN Ambassadors(AWS Ambassadors)によるアドベントカレンダーJapan APN Ambassador Advent Calendar 2021」での20日目の記事となります。 AWS Ambassadors の詳細については、下記の記事をご覧ください。

本記事では AWS re:Invent 2021 にて発表された「Amazon SageMaker Canvas」(以下、SageMaker Canvas)の簡単な動作検証を実施してみたいと思います。

SageMaker Canvas

概要

SageMaker CanvasAWS re:Invent 2021 で発表された新機能であり、ノーコードで AI を用いた予測が行えます。 手元に構造化されたデータがあれば、30 分程度で簡単な予測結果が得られます。

f:id:kikuchitk7:20211219160551j:plain
SageMaker Canvas のイメージ

ビジネスおよびテクニカル観点で SageMaker Canvas を見てみます。

ビジネス観点

  • ビジネスアナリストやプロダクトオーナーがデータサイエンティストやエンジニアの手を借りずに自身の手でデータを検証できる
    • 「依頼」には余計なオーバーヘッドがかかりがち…
    • 手元にあるデータでサクッと仮説検証して、結果をデータサイエンティストやエンジニアに共有できればビジネスへの導入も円滑に進みやすい
    • スポンサーに有用性を説明して出資なども取り付けやすい
  • 下記のようなビジネス課題に対するソリューションになる(開発者ガイドより引用)
    • Reducing employee churn(従業員の離職を減らす)
    • Detecting fraud(不正を検出する)
    • Forecasting sales(売上を予測する)
    • Optimizing inventory(在庫量を予測して最適化する)

テクニカル観点

  • SageMaker Canvas の仕様や挙動から背後で SageMaker Autopilot が使われていると思われるため、SageMaker Autopilot でできることは実現可能
    • 学習データの分析(統計情報や欠損値の割合の分析など)
    • 下記の学習アルゴリズムを用いたモデル構築
      • 回帰
      • 分類(二値・多値)
      • 時系列予測
    • 構築したモデルによる推論
    • モデルの判断根拠の可視化(説明可能な AI: XAI)

使い方

SageMaker Canvas の概要や有用性がわかったところで、具体的な使い方を見ていきたいと思います。 SageMaker の開発者ガイドより、SageMaker Canvas は事前準備を含めて、下記の 6 ステップで予測まで実行することができます。

  • Step 0: 事前準備
  • Step 1: SageMaker Canvas へのログイン
  • Step 2: データのインポート
  • Step 3: モデルの構築
  • Step 4: モデルの評価
  • Step 5: 予測

ここからは SageMaker Canvas を使って簡単な動作検証を実施してみたいと思います。

今回は UCI Machine Learning Repository の Bank Marketing のオープンデータを利用して、二値判別問題に取り組みます。 このデータにはポルトガル銀行の顧客の属性情報(年齢、職業、住宅ローンの有無など)とその顧客が定期預金を申し込んだかどうかの情報が含まれています。 属性情報から何らかの法則性を見出せれば、定期預金を申し込んでくれそうな顧客に対して効率的に営業活動ができます。

Step 0: 事前準備

このステップでは、下記を実施します。

  • Step 0-1: AWS リソースに対する適切な権限を持った IAM ユーザにログインする
  • Step 0-2: S3 に学習データとテストデータをアップロードする
  • Step 0-3: SageMaker Domain をセットアップする

Step 0-1: AWS リソースに対する適切な権限を持った IAM ユーザにログインする

AWS マネジメントコンソールから IAM ユーザにログインします。

今回は簡単な動作検証なので AdministratorAccess 権限を持つ IAM ユーザで実施しますが、特にビジネスで利用する際は AWS のベストプラクティスにしたがって必要最小限の権限に制約してください。

SageMaker Canvas は、本稿の執筆時点では下記のリージョンでのみ利用が可能であり、東京&大阪リージョンに対応していません。 今回は「米国西部(オレゴン)」を利用します。

Step 0-2: S3 に学習データとテストデータをアップロードする

S3 のコンソール画面に移動し、学習データとテストデータをアップロードします。

f:id:kikuchitk7:20211219173255j:plain
S3 のコンソール画面

SageMaker Canvas にファイルに対して下記の制約がありますので、注意してください。

  • ファイルサイズは 5GB 以下で、CSV 形式とする
  • 欠損値補完などの前処理を事前に実施する(前処理機能が実装されていない)

Step 0-3: SageMaker Domain をセットアップする

この手順は SageMaker Domain が未セットアップの場合にのみ必要となります。

SageMaker のコンソール画面に移動し、「Canvas」を選択します。

f:id:kikuchitk7:20211219174449j:plain
SageMaker のコンソール画面

SageMaker Domain が未セットアップの場合は、下図に示すセットアップ画面に誘導されます。 構成状況が不明の場合でもこの方法で確認できます。

今回は「高速セットアップ」で進めます。

f:id:kikuchitk7:20211219174831j:plain
SageMaker Domain のセットアップ画面

SageMaker Domain は下記のリソースで構成され、AWS アカウントの 1 つのリージョンあたりに 1 つだけ構成できます。

  • EFS ボリューム
  • 認証されたユーザの一覧
  • 様々なセキュリティ、アプリケーション、ポリシー、VPC の構成

SageMaker Domain は SageMaker Studio でも活用されています。 例えば、同じ SageMaker Domain に所属するユーザ間では EFS ボリュームを介してノートブックなどのファイルを共有できます。

下記のような画面となれば SageMaker Domain の構成完了です。

f:id:kikuchitk7:20211219181510j:plain
SageMaker Domain のセットアップ完了画面

Step 1: SageMaker Canvas へのログイン

このステップでは、下記を実施します。

  • Step 1-1: SageMaker Canvas を起動する

Step 1-1: SageMaker Canvas を起動する

SageMaker Canvas は赤い矢印で示した「アプリケーションを起動」のプルダウンから「Canvas」を選択すると起動できます。

f:id:kikuchitk7:20211219182437j:plain
SageMaker Canvas の起動画面

起動に成功すると、下図のような画面が表示されます。

f:id:kikuchitk7:20211219182618j:plain
SageMaker Canvas の起動完了画面

初回接続時にチュートリアルが表示されますが、左下の「?」を選択すればいつでも確認できます。

f:id:kikuchitk7:20211219183039j:plain
SageMaker Canvasチュートリアル画面

Step 2: データのインポート

このステップでは、下記を実施します。

  • Step 2-1: S3 から学習データとテストデータをインポートする

ここでは、機械学習モデルの構築で利用する学習データと予測で利用するテストデータをインポートします。

Step 2-1: S3 から学習データとテストデータをインポートする

左側のメニューを開くと、それぞれのアイコンの内容が確認できます。 「Datasets」を選択します。

f:id:kikuchitk7:20211219203312j:plain
「Datasets」の選択画面

画面右上もしくは中央下の「Import」を選択します。

f:id:kikuchitk7:20211219204025j:plain
「Datasets」の遷移後画面

データが格納されている S3 Bucket を選択します。

f:id:kikuchitk7:20211219204344j:plain
S3 Bucket の選択画面

インポートするデータにチェックをつけて、「Import data」を選択します。

f:id:kikuchitk7:20211219205149j:plain
データの選択画面

ファイル名をクリックすると、データの内容を確認できます。

f:id:kikuchitk7:20211219204831j:plain
データのプレビュー画面

下図のように「Status」が「Ready」となれば完了です。

f:id:kikuchitk7:20211219205437j:plain
データのインポート完了画面

なお、開発者ガイドによるとデータソースとして下記がサポートされると記載されますが、本稿の執筆時点では S3 のみが利用可能です。 上図では「Upload」というボタンがあり、ローカル PC からのアップデートができそうに見えますが、ボタンが活性化されておらず利用できません。

また、今回は実施しませんが、「Join data」を選択するとインポートしたデータを結合できます(図は SageMaker の開発者ガイド より引用)。

f:id:kikuchitk7:20211220084559p:plain
データの結合(SageMaker の開発者ガイドより引用)

Step 3: モデルの構築

このステップでは、下記を実施します。

  • Step 3-1: 「Models」に移動する
  • Step 3-2: 機械学習モデルの名前を設定する
  • Step 3-3: 学習データを選択する
  • Step 3-4: 予測対象となるカラム名を選択する
  • Step 3-5: 学習方法を選択して実行する

Step 3-1: 「Models」に移動する

左側のメニューで「Models」を選択後、画面右上もしくは中央下の「New model」を選択します。

f:id:kikuchitk7:20211219210007j:plain
「Models」の遷移後画面

Step 3-2: 機械学習モデルの名前を設定する

機械学習モデルの名前を入力して、「Create」を選択します。

f:id:kikuchitk7:20211219210640j:plain
機械学習モデルの命名画面

Step 3-3: 学習データを選択する

学習データとするデータを選択して、「Select data」を選択します。

f:id:kikuchitk7:20211219211234j:plain
学習データの選択画面

Step 3-4: 予測対象となるカラム名を選択する

「Target column」から予測対象となるカラム名を選択します。 今回は定期預金を申し込んだかどうかが記録されている「y」を選択します。

f:id:kikuchitk7:20211219211655j:plain
予測対象のカラム名の選択画面

赤枠部分に学習データの「y」の比率が示されています。 この学習データは「no(定期預金を申し込まない)」よりも「yes(定期預金を申し込む)」が著しく少ない不均衡データであることがわかります。

青枠部分には「y」のデータの内容から、SageMaker Canvas が 自動で「2 category prediction(二値判別予測)」と判断し、その結果が示されています。 判断が間違っている場合は、その下の「Change type」で変更できます。

f:id:kikuchitk7:20211219213810j:plain
学習データの分析結果画面

画面の下半分には学習データのカラム別の分析結果が示されています。 データ型や欠損割合に加えて、平均や中央値などの統計情報も提示されます。

f:id:kikuchitk7:20211219214017j:plain
学習データのカラム別の分析結果

分析結果の上部にあるアイコンを選択すると、データの分析観点を変更したり、フィルタなどもできます。 下図は矢印を選択したものです。 カラム別にデータの分布が可視化され、学習データの中の 100 行が示されています。

f:id:kikuchitk7:20211219214711j:plain
データの分析観点の変更後画面

Step 3-5: 学習方法を選択して実行する

矢印のプルダウンを選択すると、2 つの学習方法を選択することができます。 今回は「Quick build」を選択します。

  • Standard build: 数時間かけて 250 モデルを作成し、精度が最良のものを選択する
  • Quick build: 数分でクイックに精度を提示する(恐らく 1 モデルのみの構築)

今回は「Quick build」を選択するので数分で結果が得られますが、「Standard build」は結果を得るまでに数時間かかります。 事前に精度の見通しを持てるため、非常にありがたい機能です。

なお、画面上部の「Share」を使うと学習モデルを他者に共有できますが、「Quick build」では共有ができない点に注意してください。

f:id:kikuchitk7:20211219215308j:plain
学習方法の選択画面

Preview model」を選択して数分待つと、画面右下に「Estimated accuracy(モデルの予測精度)」と「Column impact(カラムの値が予測に与える影響度合い)」が表示されます。

Preview model」の実体は「Quick build」と考えられますが、この時に構築したモデルは偶然良いもしくは悪い精度を出す可能性があるため、結果の妥当性を求めたい場合は「Standard build」を選択すると良いでしょう。

f:id:kikuchitk7:20211219221157j:plain
Preview model」の実行後画面

「_c0」というカラムは学習データの行番号を示すものであり、学習には不要なデータでした。 そのような場合はカラム名の左横のチェックを外すと学習から除外でき、数分待つと予測精度も更新できます。

f:id:kikuchitk7:20211219222754j:plain
不要カラムの除外と予測精度の更新

学習データに問題ないことが確認できたら「Quick build」を選択します。 下図のような画面に遷移するので、学習が完了するまで数分待ちます。

f:id:kikuchitk7:20211219223521j:plain
学習の実行画面

Step 4: モデルの評価

このステップでは、下記を実施します。

  • Step 4-1: モデルを評価する

ここでは、モデルの評価を行います。 正解がわかっている学習データを用いた評価となります。

Step 4-1: モデルを評価する

学習が完了すると、下図のような画面が表示されます。 「精度」と「カラムの値が予測に与える影響度合い」が図で示されます。

今回は「duration(最後の連絡期間)」が最上位になりました。 なお、今回利用した UCI のデータセットの説明では「duration」が「y」に大きな影響を与えるので検証以外で利用する場合には注意せよとの記載があります。 データの性質と一致する結果となりました。

f:id:kikuchitk7:20211219223729j:plain
学習完了後の画面

「Scoring」を選択すると、予測の正解と不正解の割合が図示されます。

f:id:kikuchitk7:20211219230032j:plain
予測の正解と不正解の割合の画面

画面の右の方にある「Advanced metrics」を選択すると、「no(定期預金を申し込まない)」と「yes(定期預金を申し込む)」のそれぞれについて、詳細なメトリクス(指標値)を確認することができます。 「Download」を選択すると、画像として保存もできます。

  • F1(適合率と再現率の調和平均)
  • Accuracy(精度、正解率)
  • Precision(適合率)
  • Recall(再現率)
  • AUC(ROC 曲線の面積)
  • 混同行列の内訳

f:id:kikuchitk7:20211219230538j:plain
詳細なメトリクス(no)

f:id:kikuchitk7:20211219230603j:plain
詳細なメトリクス(yes)

「yes」はデータ量の不足もあって十分な指標値が得られていません。 「no」はそこそこですが、誤検出や検出漏れが少なくないためビジネスで利用するには十分とは言えません。 このような結果を得た場合は「yes」「no」ともデータ量を増やし、かつ、両者の比率も揃える必要があるでしょう。

Step 5: 予測

このステップでは、下記を実施します。

  • Step 5-1: 「Predict」を選択する
  • Step 5-2: 「Batch prediction」を選択する
  • Step 5-3: テストデータを使って予測する
  • Step 5-4: 予測結果を確認する

Step 4 で構築したモデルを使って、未知データ(定期預金を申し込むかどうかわからない顧客のデータ)から予測を取得します。

Step 5-1: 「Predict」を選択する

確認が完了したら、右上もしくは右下の「Predict」を選択します。

f:id:kikuchitk7:20211219232948j:plain
予測の正解と不正解の割合の画面

Step 5-2: 「Batch prediction」を選択する

SageMaker Canvas は下記の 2 つの予測方法にて予測を行えます。

  • Batch prediction: 予測対象のデータをファイルで一括指定する
  • Single prediction: 予測対象のカラムの値を手動で設定する

「Batch prediction」を選択して、「Select dataset」を選択します。

f:id:kikuchitk7:20211219233535j:plain
予測方法の選択画面

Step 5-3: テストデータを使って予測する

テストデータを選択して、「Generate prediction」を選択します。

f:id:kikuchitk7:20211219235544j:plain
テストデータの選択画面

Step 5-4: 予測結果を確認する

少々分かりづらいですが、予測が完了すると画面の下部に黒いポップアップが表示されます。 「View」を選択すると、下図のように表形式で予測結果が提示されます。

  • Prediction (y): 予測した「y(定期預金を申し込むかどうか)」の値
  • Probability: 予測した「y」の値をとる確率

「Download CSV」を選択すると、予測結果を CSV 形式のファイルとして保存できます。

f:id:kikuchitk7:20211219235458j:plain
Batch prediction の予測結果の画面

なお、「Single prediction」を選択すると、各カラムの値を手動で変更して、その時の予測結果がどのように変化するかを確認できます。 業務知識をもとに値を設定して予測結果を得るなどのシミュレーションができます。

f:id:kikuchitk7:20211220000117j:plain
Single prediction の実行画面

制約事項

動作検証の中でも触れましたが、SageMaker Canvas の主な制約事項をまとめます。

  • 東京&大阪リージョンでは利用不可
  • S3 からのデータ(5GB 以下& CSV 形式)のインポートのみに対応
  • 回帰、分類(二値・多値)、時系列予測にのみ対応
  • 「Quick build」はモデルの共有不可

SageMaker Canvas はまだ発表されたばかりですので、順次機能が拡張されていくものと考えられます。

まとめ

本稿では SageMaker Canvas について、開発者ガイドのチュートリアルを利用しながら簡単な動作検証を実施しました。 製品の謳い文句の通りにノーコードで AI を利用した予測ができました。

本稿のボリュームはそれなりにありますが、慣れれば Quick build なら 30 分程度で予測結果を得られると思います。 非常に有用なサービスですので、早々の東京&大阪リージョンへの対応を期待したいところです。

Advent Calendar も佳境ですが、AWS Ambassadors の仲間が興味深い記事をたくさん投稿していますので、是非お読みいただければと思います。

参考文献

AWS Chatbot を使ってサインインイベントを Slack に通知する

はじめに

AWS の新規開発案件に携わることがあったので、AWS を利用する上での初期設定の1つとなるマネジメントコンソールへのサインイン(ログイン)を Slack に通知する方法をまとめる。 実現方法はいくつかあるが、ここでは AWS Chatbot を使った方法を採用する。

AWS Chatbot とは

AWS Chatbot(Chatbot)は、AWS で「ChatOps」を実現するためのマネージドサービスであり、Slack と Amazon Chime への連携を簡単に行える。 今回扱うような簡単な通知であれば、コードを一切書かずにマネジメントコンソールの操作だけで実現できる。

Chatbot の利用に追加費用は不要(つまり、無料)であり、東京&大阪リージョンでも利用できる。

ChatOps とは

ChatOps は、「Chat(チャット)」+「Ops(Operations: 運用)」を合わせた用語であり、文字通りにシステム運用にチャットを活用する手法のことを指す。

多くの組織で Slack や Mattermost などのチャットツールがコミュニケーションツールとして採用されているが、システムで発生したイベントをチャットに通知することで、状態の変化や障害にすぐに気づくことができ、その後のアクションを迅速に行える。

ここで扱うマネジメントコンソールへのサインインイベントの Slack 通知が実現できると、誰がいつサインインをしたか?を把握でき、Slack にその記録も残せる。 想定しないタイミングでサインイン通知があった場合には、その異常にもすぐに気づいて対処ができる。

今回実現するアーキテクチャ

下図に示すように、マネジメントコンソールへのサインインを契機に Slack にイベントを通知するアーキテクチャを実現する。

マネジメントコンソールへのサインインイベントの Slack 通知
マネジメントコンソールへのサインインイベントの Slack 通知

実現手順

Chatbot の管理者ガイドを参考に実施する。

なお、今回は通知機能の実現に必要な最低限の設定のみを行うこととする。 商用で採用する場合には要件にしたがい、蓄積データの暗号化やログの取得などを適切に行うこと。

Chatbot のセットアップ

Chatbot を利用するための前提条件が下記となる。 利用者の環境によっては既に設定されているものもあると思うが、不足があれば「Setting up AWS Chatbot」にしたがって設定を行う。

  • Chatbot に対する適切な権限を持つ IAM ユーザを作成すること
    • 今回は管理者権限(AdministratorAccess)を持つ IAM ユーザで作業を実施するが、商用の場合は AWS のベストプラクティスにしたがって最小権限を付与したユーザで作業することが望ましい。
  • Chatbot からの通知を受け取る SNS トピックを作成すること
    • 今回は「signin-notification」という SNS トピックを作成する。(作成手順を下記に示す)
  • Slack のワークスペースの管理者権限を持っていること
  • Slack のワークスペースSNS トピックからの通知を受け取るチャネルを作っておくこと
    • 今回は「notification」チャネルに通知する。

なお、サインインのイベントは「米国東部(バージニア北部)us-east-1」リージョンで発生するので、ここで作業を行う。

SNS トピックの作成

下記に SNS トピックの作成手順を示す。

ここでの作業範囲を下図に示す。

作業範囲(SNS トピック)
作業範囲(SNS トピック)

マネジメントコンソールで SNS のコンソールに移動する。 画面右上の「トピック作成」に「トピック名」を入力して、「次のステップ」を選択する。

SNS のコンソール画面
SNS のコンソール画面

「タイプ」で「スタンダード」が設定されていることを確認する。 その他はオプション設定なのでデフォルトのままとする。 画面の下までスクロールして「トピックの作成」を選択する。

SNS トピックの作成画面
SNS トピックの作成画面

SNS トピックの作成に成功すると、下記のようなメッセージが表示される。

SNS トピックの作成成功画面
SNS トピックの作成成功画面

Chatbot の設定

Getting started with AWS Chatbot」を参考にして、Chatbot を設定する。

ここでの作業範囲を下図に示す。

作業範囲(Chatbot と Slack)
作業範囲(Chatbot と Slack)

Chatbot のチャットクライアントのセットアップ

マネジメントコンソールで Chatbot のコンソールに移動する。

チャットクライアントには「Slack」と「Amazon Chime」が選べるが、ここでは「Slack」とする。 「クライアントを設定」を選択する。

Chatbot のコンソール画面
Chatbot のコンソール画面

Slack の認証ページにリダイレクトされるので、Slack のワークスペース名を確認する。 連携したいワークスペース名が表示されていない場合は、右上のプルダウンから選択する。 内容を確認して「許可する」を選択する。

Slack の認証ページ
Slack の認証ページ

Slack と Chatbot との連携に成功すると、下図のようなメッセージが表示される。 「新しいチャネルを設定」を選択する。

Slack と Chatbot の連携成功画面
Slack と Chatbot の連携成功画面

ここでは、下表のように設定する。 設定が終わったら、画面の下までスクロールして「設定」を選択する。

分類 設定項目 説明 設定値
設定の詳細 設定名 設定の名前を設定する。 「signin-configuration」
ログ記録 CloudWatch Logs へのログの記録の有無を設定する。 設定しない
Slack チャネル チャネルタイプ 通知先となる Slack チャネルの公開レベルを選択する。 「パブリック」
パブリックチャネル名 通知先となる Slack チャネル名を選択する。 「notification」
アクセス許可 IAM ロール Chatbot に付与する IAM ロールをテンプレートから新規作成するか、既存の IAM ロールから選択する。 「テンプレートを使用して IAM ロールを作成する」
ロール名 IAM ロールの名称を設定する。 「AWSChatbot-role」
ポリシーテンプレート IAM ロールに設定する権限をポリシーテンプレートから設定する。 「通知のアクセス許可」
通知 SNS トピック 購読する SNS トピックがあるリージョンを選択する。 「米国東部 - バージニア北部」
購読する SNS トピックを選択する。 「signin-notification」

Chatbot の設定が完了すると、下図のようなメッセージが表示される。

Chatbot の設定完了画面
Chatbot の設定完了画面

デスクトップアプリなどで Slack を開き、App 配下に「aws」が存在することを確認する。 存在しない場合は、「アプリを追加する」から「AWS Chatbot」を追加する。

Slack の App に Chatbot が追加された画面
Slack の App に Chatbot が追加された画面

ここまでの手順で Chatbot と Slack の連携が完了している。 下図のように、上記で設定したワークスペースの設定(「notification-configuration」)の左のラジオボタンを選択し、「テストメッセージを送信」を選択すると Slack にテストメッセージを送信できる。

Chatbot のテストメッセージの送付
Chatbot のテストメッセージの送付

Chatbot と Slack の連携がうまくできていれば、下図のようなメッセージが届く。

Slack に届いたテストメッセージ
Slack に届いたテストメッセージ

EventBridge の設定

Amazon EventBridge(EventBridge)のルールを使って、マネジメントコンソールへのサインインイベントの発生を捕捉する。

Tutorial: Creating an Amazon EventBridge rule that sends notifications to AWS Chatbot」を参考にして、EventBridge のルールを作成する。

ここでの作業範囲を下図に示す。

作業範囲(EventBridge)
作業範囲(EventBridge)

EventBridge のルールの作成

マネジメントコンソールで EventBridge のコンソールに移動する。

「ルールを作成」を選択する。

EventBridge のコンソール画面
EventBridge のコンソール画面

ルールの作成画面に遷移する。

EventBridge のルールの作成画面
EventBridge のルールの作成画面

ここでは、下表のように設定する。 設定が終わったら、画面の下までスクロールして「作成」を選択する。

分類 設定項目 説明 設定値
名前と説明 名前 ルールの名前を設定する。 「signin-rule」
説明 ルールの説明を記載する。 設定しない
パターンを定義 イベント駆動もしくは時間駆動のルールを選択する。 「イベントパターン」
イベント一致パターン サービスごとに事前定義されたパターンか、パターンをカスタマイズするかを選択する。 「サービスごとの事前定義パターン」
サービスプロバイダー イベントソースとなるサービスの提供者を選択する。 AWS
サービス名 イベントソースのサービス名を選択する。 AWS コンソールのサインイン」
イベントタイプ イベントのタイプを選択する。 「サインインイベント」
サインインイベントを捕捉するユーザを設定する。 「任意のユーザ」
イベントバスを選択 ルールのイベントバスを選択する。 AWS のデフォルトのイベントバス」
選択したイベントバスのルールを有効化するか選択する。 「選択したイベントバスでルールを有効にする」
ターゲットを選択 ターゲット イベントがイベントパターンに一致した場合に呼び出すターゲットを選択する。 SNS トピック」
メッセージを発行する SNS トピックを選択する。 「signin-notification」
タグ ルールに付与するタグを設定する。 設定しない

ルールの作成が完了すると、下図のようなメッセージが表示される。

ルールの作成成功画面
ルールの作成成功画面

以上で設定は完了である。

通知のテスト

マネジメントコンソールへのサインインで Slack に通知が届くかテストする。

マネジメントコンソールへのサインインイベントの Slack 通知(再掲)
マネジメントコンソールへのサインインイベントの Slack 通知(再掲)

一度マネジメントコンソールをサインアウトして、再度サインインする。

設定が正しく行われていれば、下図に示すようなメッセージが通知される。 なお、一段階目のパスワード認証時と二段階目の MFA 認証時で2つのサインインイベントが発生するため、2通メッセージが届く。

Slack に届くサインイン通知メッセージ(パスワード認証時)
Slack に届くサインイン通知メッセージ(パスワード認証時)

Slack に届くサインイン通知メッセージ(MFA 認証時)
Slack に届くサインイン通知メッセージ(MFA 認証時)

AWS のイベント情報は JSON で記録されるが、利用者側で特に情報の抽出や整形をすることなく Chatbot が自動で実行してくれている。

まとめ

Chatbot を使ってマネジメントコンソールのサインインイベントを Slack に通知する仕組みを構築した。 今回はサインインイベントをターゲットにしたが、コードを一切書くことなく簡単に実現できた。 他にも日々の Billing 情報の通知、CloudWatch Alarms でのエラー検知、CI/CD の実行状況の通知などにも使えるので、別の機会に試したい。

参考文献

Amazon Aurora PostgreSQL での擬似障害の実行 (1)

はじめに

Amazon Aurora PostgreSQL (以下、Aurora PostgreSQL) で擬似障害試験を実施することがあったのでまとめる。

Amazon Aurora における擬似障害

Amazon Aurora で擬似障害を発生させる方法には、大きく3つの方法がある。

  1. AWS マネジメントコンソールによる手動のフェイルオーバーを発生させる方法
  2. 障害挿入クエリを利用して DB インスタンスをクラッシュさせる方法
  3. AWS Fault Injection Simulator を利用する方法

Amazon Aurora には MySQL 互換の DB エンジン (以下、Aurora MySQL) も用意されているが、Aurora PostgreSQL と Aurora MySQL で障害挿入クエリが異なるため、具体的な擬似障害の発生方法が異なる点に注意する。

今回は Aurora PostgreSQL を対象とする。

検証環境の構成

Aurora PostgreSQL のバージョンは 3.2 (PostgreSQL バージョン 11.7 との互換性あり) とし、DB クラスタの構成を下記とする。

DB 識別子 ロール フェイルオーバー優先順位
aurora-test-cluster-instance-1 書き込み 1
aurora-test-cluster-read-replica-1 読み込み 1
aurora-test-cluster-read-replica-2 読み込み 2

「フェイルオーバー優先順位」は、0 (最高) から 15 (最低) までの16段階で設定可能である。

プライマリ DB (aurora-test-cluster-instance-1) に障害があった場合、優先度の高いリードレプリカ 1 (aurora-test-cluster-read-replica-1) がプライマリ DB に昇格することになる。

なお、Amazon Aurora の仕様では、優先度が同じ場合は、その中でサイズが最も大きいリードレプリカが選択される。 優先度もサイズも同じ場合は、その中からランダムに選択される。

AWS マネジメントコンソールによる手動のフェイルオーバーを発生させる方法

事前の準備が必要ないので、最も単純に実施できる方法である。

1. AWS マネジメントコンソールで Amazon RDS のコンソールに移動する

手動フェイルオーバー-1

2. 「データベース」を選択する

手動フェイルオーバー-2

3. DB クラスタと DB インスタンスの「ステータス」を確認する

DB クラスタと DB インスタンスとリードレプリカの「ステータス」が「利用可能」であることを確認する。

手動フェイルオーバー-3

4. フェイルオーバーを発生させる

「アクション > フェイルオーバー」を選択する。

手動フェイルオーバー-4-1

フェイルオーバーを発生させるクラスタクラスタ名 (ここでは、aurora-test-cluster) を確認する。 間違いがなければ「フェイルオーバー」を選択する。

手動フェイルオーバー-4-2

5. フェイルオーバーの発生を確認する

問題がなければ、元の「データベース」の画面に戻る。 画面のリフレッシュを行うと、DB クラスタののステータスが「Failing-over」となる。

手動フェイルオーバー-5

DB クラスタに1つ以上のリードレプリカが含まれる場合、一般的には120秒未満、多くの場合は60秒未満でリードレプリカの1つへのフェイルオーバーが完了する。

DB クラスタに1つ以上のリードレプリカが含まれない場合は、DB インスタンスの再作成処理が行われる。通常は10分未満で完了する。

6. フェイルオーバーの完了を確認する

1分程度待ち、「ステータス」が「利用可能」となれば、フェイルオーバーは完了。

手動フェイルオーバー-6

今回のフェイルオーバーにより、リードレプリカ 1 (aurora-test-cluster-read-replica-1) がプライマリ DB に昇格して、元プライマリ DB がリードレプリカとなったため、期待通り。

参考文献

Amazon Aurora PostgreSQL のリードレプリカの追加

はじめに

Amazon Aurora PostgreSQL (以下、Aurora PostgreSQL) の DB クラスタにリードレプリカを追加する方法をまとめる。

実施方法

下記の3つの方法で追加が可能。

  • AWS マネジメントコンソールを利用する方法
  • AWS CLI を利用する方法
  • RDS API を利用する方法

ここでは、「AWS マネジメントコンソールを利用する方法」と「AWS CLI を利用する方法」を検証する。

AWS マネジメントコンソールを利用する方法

AWS マネジメントコンソールを利用してリードレプリカを作成する方法を記載する。

1. AWS マネジメントコンソールで Amazon RDS のコンソールに移動する

AWS マネジメントコンソールを利用する方法-1

2. 「データベース」を選択する

AWS マネジメントコンソールを利用する方法-2

3. DB クラスタと DB インスタンスの「ステータス」を確認する

DB クラスタと DB インスタンス (ソース DB) の「ステータス」が「利用可能」であることを確認する。

AWS マネジメントコンソールを利用する方法-3

4. 「アクション > リーダーの追加」を選択する

AWS マネジメントコンソールを利用する方法-4

5. 「リーダーの追加」でリードレプリカの設定をする

設定項目はクラスタ (インスタンス) の作成時と基本同じ。 AZ の配置など要件に従って設定を行う。

AWS マネジメントコンソールを利用する方法-5-1

設定の入力が終わったら、「Add reader」を選択する。

AWS マネジメントコンソールを利用する方法-5-2

6. 「ステータス」が「利用可能」となったことを確認する。

設定値に不備などがなければ、「データベース」に戻る。 リードレプリカは「ロール」が「読み込み」と表示される。

AWS マネジメントコンソールを利用する方法-6-1

数分程度待ち、「ステータス」が「利用可能」となれば、作成完了。

AWS マネジメントコンソールを利用する方法-6-2

AWS CLI を利用する方法

AWS CLIcreate-db-instance コマンドを利用する。

AWS CLI の実行環境は下記の通り。

  • macOS Big Sur バージョン 11.2.2
  • AWS CLI v2 (2.1.29)

実行コマンド

下記のコマンドにて作成する。

aws rds create-db-instance --db-instance-identifier aurora-test-cluster-read-replica-2 \
    --db-cluster-identifier aurora-test-cluster \
    --engine aurora-postgresql \
    --db-instance-class db.t3.medium \
    --availability-zone ap-northeast-1d

引数の意味と設定値は順番に下記の通り。

引数 設定値
db-instance-identifier
(DB インスタンス名)
aurora-test-cluster-read-replica-2
db-cluster-identifier
(DB クラスタ名)
aurora-test-cluster
engine
(DB エンジン)
aurora-postgresql
db-instance-class
(DB インスタンスクラス)
db.t3.medium
availability-zone
(DB インスタンスを配置する AZ)
ap-northeast-1d

コマンドに不備がなければ、下記のような出力 (ここでは yaml 形式で出力) が返される。 今回作成したリードレプリカに加えて、DB クラスタの既存リソースの情報も出力されている点に注意する。

DBInstance:
  AllocatedStorage: 1
  AssociatedRoles: []
  AutoMinorVersionUpgrade: true
  AvailabilityZone: ap-northeast-1d
  BackupRetentionPeriod: 1
  CACertificateIdentifier: rds-ca-2019
  CopyTagsToSnapshot: false
  CustomerOwnedIpEnabled: false
  DBClusterIdentifier: aurora-test-cluster
  DBInstanceArn: arn:aws:rds:ap-northeast-1:12345678912:db:aurora-test-cluster-read-replica-2
  DBInstanceClass: db.t3.medium
  DBInstanceIdentifier: aurora-test-cluster-read-replica-2
  DBInstanceStatus: creating
  DBName: aurora_test_db
  DBParameterGroups:
  - DBParameterGroupName: default.aurora-postgresql11
    ParameterApplyStatus: in-sync
  DBSecurityGroups: []
  DBSubnetGroup:
    DBSubnetGroupDescription: Created from the RDS Management Console
    DBSubnetGroupName: xxxxx
    SubnetGroupStatus: Complete
    Subnets:
    - SubnetAvailabilityZone:
        Name: ap-northeast-1a
      SubnetIdentifier: subnet-xxxxxxxx
      SubnetOutpost: {}
      SubnetStatus: Active
    - SubnetAvailabilityZone:
        Name: ap-northeast-1d
      SubnetIdentifier: subnet-xxxxxxxx
      SubnetOutpost: {}
      SubnetStatus: Active
    - SubnetAvailabilityZone:
        Name: ap-northeast-1c
      SubnetIdentifier: subnet-xxxxxxxx
      SubnetOutpost: {}
      SubnetStatus: Active
    VpcId: vpc-xxxxxxxx
  DbInstancePort: 0
  DbiResourceId: db-xxxxxxxxxxxxxxxxxxxxxxxxxx
  PubliclyAccessible: false
  ReadReplicaDBInstanceIdentifiers: []
  StorageEncrypted: false
  StorageType: aurora
  TagList: []
  VpcSecurityGroups:
  - Status: active
    VpcSecurityGroupId: sg-xxxxxxxxxxxxxxxxx

AWS マネジメントコンソールを確認すると、リードレプリカが追加されている。

AWS CLI を利用する方法-1

数分程度待ち、「ステータス」が「利用可能」となれば、作成完了。

AWS CLI を利用する方法-2

注意事項

  • リードレプリカは、最大15個まで作成が可能。
  • マルチマスタークラスタでは、リードレプリカの構成がサポートされていない。
  • Aurora では、異なるリージョン (クロスリージョン) でリードレプリカを構成できない。異なるリージョンで読み取り用のレプリカを構成したい場合は、グローバルデータベースを利用する。

参考文献