Amazon Alexa および AWS Systems Manager でのカスタムスキルを使ったデータベースの管理

Amazon のお客様は何年も、消耗品を注文、音楽を聴く、ミーティングをサポート、ホームデバイスを管理、そして天気や最新ニュースを知るために Amazon Alexa の音声コマンドを使ってこられましたが、AWS のリソース管理となるとどうでしょうか。

AWS のマネージドサービスと完全マネージドサービスは、すでに管理タスクを減らし、アプリケーション上のリソースに焦点を当てることを可能にしていますが、今では音声対話で管理工数をさらに削減できるようになっています。

IT 管理者によるインフラストラクチャの管理と制御
開発者によるメトリクスのチェックと事前定義されたタスクのセキュアな実行
マネージャーによる IT リソースステータスとメトリクスの監視

さらに、これらのタスクはキーボードに触れることなく実行できます。

この記事では、Alexa の音声コマンドを使用して Amazon RDS インスタンス、または Amazon Aurora インスタンスを管理するためにインフラストラクチャを設定する方法について説明します。Alexa に、データベースインスタンスのメトリクス、設定、およびステータスを E メールするだけでなく、再起動やフェイルオーバーも実行してもらいましょう。

前提条件

AWS リソースの適切な音声管理には、以下を含めた AWS のサービスの組み合わせへのアクセスが関与します。

Amazon のクラウドベース音声サービスである Alexa は、毎日使うテクノロジーと直観的にやり取りすることを可能にします。このサービスを最大限に活用していただくため、Amazon は Alexa で音声エクスペリエンスを構築するためのツールと API を集めた Alexa Skills Kit を提供しています。Alexa スキルは、いくつかの方法でホストできます。

Alexa がホストするスキル
ウェブサービス上
Amazon Echo デバイスを使用して音声で呼び出された Lambda 関数 (この記事で使用する方法)

独自のプライベート Alexa スキルを作成してテストするための全手順については、aws-systems-manager-database-voice-commands GitHub リポジトリをご覧ください。次のセクションでは、これから構築する事柄について説明します。

Alexa スキル

Alexa スキルは、Alexa 操作を有効にする音声コマンドで構成されています。各 Alexa スキルには、以下のリソースを含めた適切なインタラクションモデルが必要です。

呼び出し: Alexa にやり取りを開始する信号を送ります
インテント: Alexa に既知のタスクを伝えます
スロットタイプ: リクエストされたタスクを指定、またはその範囲を狭めます

管理者、開発者、IT マネージャー、またはその他 IT プロフェッショナルとして、Alexa に AWS 上で実行されるデータベースフリートから情報を取得させる、またはそれらにコマンドを実行させることができます。これを開始するには、個人的にサービスを呼び出し、認識されたインテントを提示することによって Alexa にタスクを与えます。

Systems Manager に関連するインテントを 4 つのカテゴリーに分類しました。

インベントリ
- NumberOfInstances
- ListInstances
- ListApplications
- ListInstancesForApplication

チェック
- CheckInstanceMetric
- ListAlarms
- CheckInstanceProperty
- TablespaceUsage (Oracle のみ)
- ShowTopSession (Oracle のみ)
- ListEvents
- CheckInstanceParameter (Oracle のみ)
- CheckLog

タスク
- ConnectInstance
- RebootInstance
- FailoverInstance

その他
- SetNotifications
- ビルトインインテント

これらのインテントの詳細を説明する前に、システムの主なアーキテクチャについて説明したいと思います。

システムアーキテクチャとタグの重要性

以下の図は、音声コマンドを通じて RDS データベースフリートを管理するためのインフラストラクチャを示しています。

Lambda 関数によって実装された Alexa スキルは、その他多くの AWS のサービスとやり取りします。Alexa スキルは、具体的に以下の事柄を実行します。

RDS から直接情報を取得する (例: ListInstances インテント)。
Multi-Factor Authentication (MFA) が必要な場合に AWS Security Token Service (STS) とやり取りして、RDS で直接タスクを実行する (例: FailoverInstance インテント)。
EC2 インスタンスに保存されたスクリプトに基づいて Systems Manager コマンドを実行し、情報を取得する (例: TablespaceUsage インテント)。
EC2 インスタンスに保存されたスクリプトに基づいて Systems Manager コマンドを実行し、タスクを実行する (例: ShowTopSession インテント)。
CloudWatch からメトリクスとアラームを取得する (例: CheckInstanceMetric インテント)。
SNS を使用してデータベースログの内容を送信する (例: CheckLog インテント)。
(有効化されている場合) SNS を使用して、各タスクの実行結果を E メールでユーザーに送信する (SetNotifications インテント)。

この記事では、さまざまなエンジンが関与する異種データベースフリートでの作業方法について説明します。

Alexa を使ってこれらのリソースを適切に管理するには、具体的なタグをいくつか設定する必要があります。

Alexa が「オレゴンにあるアプリケーション『training』のインスタンスをリスト」といった質問に答えられるようにするため、「アプリケーション」にタグ付けする。
Alexa が「オレゴンにある『Blog』インスタンスのステータス」といった質問に答えられるようにするため、「インスタンス」にタグ付けする。
Alexa が「オレゴンにある『production』インスタンスの数」といった質問に答えられるようにするため、「環境」にタグ付けする。

「インスタンス」タグは、通常文字が制限されている所定の RDS インスタンス名よりも、人 (および Alexa) にとって読み取りやすいラベルを提供します。

フリートから情報を取得する

データベースフリートから情報を取得するために使用できるインテントのひとつに、ListInstancesForApplication があります。

ユーザー: OREGON にあるアプリケーション BLOG のインスタンスをリスト Alexa: OREGON にあるアプリケーション BLOG 用の RDS インスタンスのリストは、 db11204a db12201a db12201b [..]

このインテントは、特定のリージョン内で実行されているデータベースの、アプリケーションでフィルタリングされたリストを取得する describe-db-instances RDS コマンドを呼び出す Lambda 関数をトリガーします。この場合、Alexa は音声で情報を返します。

Alexa が、多数の結果が生成される可能性があるインテントに対して返答する場合、コードが出力される結果を最大 20 件に制限し、API アクションがデフォルトのページサイズ属性で実行されます。

フリートをチェックする

1 つのデータベースインスタンスのパフォーマンスに関心がある場合は、 CheckInstanceMetric インテントを使って、指定された CloudWatch インスタンスと時間範囲について値のメトリックを調べます。

ユーザー: 「OREGON にある REPORTING インスタンスの 30 分前の CPU 使用率」 Alexa: OREGON にある REPORTING インスタンスの CPU 使用率は 80% です

Lambda 関数は、RDS describe-db-instances コマンドを使ってデータベースインスタンスの DB インスタンス識別子を取得してから、CloudWatch get-metric-statistics コマンドを呼び出して、正確なメトリクス値を取得します。

次に、特定のデータベースインスタンス向けに定義された CloudWatch アラームが発行されたかどうか、発行された場合はどのアラームだったかを確認します。これが ListAlarms インテントの目的です。CloudWatch DescribeAlarms アクションを呼び出すことによって、ALARM に相当する状態のアラームの、アラームプレフィックスでフィルタリングされたリストを取得できます。

ユーザー: 「OREGON で REPORTING インスタンスについて発行されたアラームのリスト」 Alexa: OREGON の REPORTING インスタンスについて、以下のアラームが ALARM 状態になっています。 cloudwatch-alarm-reporting-DatabaseConnections cloudwatch-alarm-reporting-SwapUsage [..]

データベースインスタンスのステータスが「available」になっていても、そのインスタンスが到達不可能である場合があります。ConnectInstance インテントを使用して、データベース接続をテストします。このインテントは、Systems Manager Run Command ツールを通じて .sql スクリプトを実行します。

ユーザー: オレゴンの HR インスタンスに接続 Alexa: データベースが到達可能です

システムは、EC2 インスタンスをデータベースクライアントとして使用し、そこに .sql スクリプトを保存します。

.sql スクリプト、または Lambda 関数のコード内に認証情報を保存する必要はありません。スクリプトを実行するために使用されるマスターユーザーのパスワードは、以下のコード例にあるように、パラメータストアツールを使って Systems Manager が管理するパラメータ内に保存されます。

ssm = boto3.client('ssm')
response = ssm.get_parameter(Name="/rds/" + instance_name + "/dbpassword")

dbpassword = response['Parameter']['Value']

説明したメカニズムは、TablespaceUsage または ShowTopSession などの他のインテントにも適用されます。ShowTopSession インテントは、パフォーマンスモニタリングの一例です。この場合、特定のメトリック (たとえば、CPU、メモリ、DB 時間など) の最上位セッションを取得できます。

ユーザー: オレゴンの REPORTING インスタンスについて、CPU が最上位のセッションを検索 Alexa: CPU が最上位のセッションは、セッション ID 3345 でユーザー名は RDSADMIN です

セキュリティのため、データベースセキュリティグループは、アクセスを常に承認された IP、IP 範囲、およびセキュリティグループに限定しておくべきです。この場合、データベースにアクセスできるのは、この .sql スクリプトが含まれる EC2 インスタンスのみです。

.sql スクリプトが保存されている EC2 インスタンスは、データベースが管理されているすべてのリージョンに設置するようにしてください。サーバーは、データベースクライアントとして機能すると同時に、データベースのホーム VPC のパブリックサブネットで実行される「踏み台」としても機能します。少なくとも、これがこの記事のために設定されたネットワーク構成です。

Alexa に特定のリージョン内にあるデータベースへの接続をテストするように指示する場合は、関連付けられたタグを使って正しい EC2 インスタンスが識別されます。システムはこのタグを、Systems Manager によって提供されるパラメータストアツール内のパラメータとして保存します。

ログをチェックする

RDS では、RDS コンソール、AWS CLI、または RDS API を使用して、データベースログの表示、ダウンロード、および監視を実行できます。利用できるデータベースログタイプのリストは、使用されるエンジンに応じて異なります。RDS データベースログの詳細については、「Amazon RDS データベースログファイル」を参照してください。

RDS download-db-log-file-portion コマンドを使用すると、データベースインスタンスから最も重要なデータベースログの内容を抽出できます。

ユーザー: OREGON にある REPORTING インスタンスのアラートログをチェック Alexa: 警告: ログにエラーが見つかりました

リクエストされたログの内容は、一般的なエラー、または特定のエラーを検出するようにフィルタリングできます。

フリートに対してタスクを実行する

RebootInstance および FailoverInstance の各インテントを使用して、音声でデータベースインスタンスを再起動またはフェイルオーバーすることができます。RebootInstance インテントを呼び出すと、Lambda 関数が直接 reboot_db_instance コマンドを呼び出し、このコマンドが特定のデータベースインスタンスまたはリードレプリカ (RDS または Aurora) を再起動します。FailoverInstance インテントを呼び出す場合は、Lambda 関数が以下のいずれかを呼び出します。

RDS インスタンスを使用している場合は、直接 reboot_db_instance コマンド (ForceFailover パラメータは TRUE に設定)

または

Aurora を使用している場合は、failover_db_cluster コマンド

どちらのアクションも「クリティカル」と見なされるため、MFA を使って関連する API アクションを保護します。MFA は、AWS サインイン認証情報に加えて、一意の認証を提供することをユーザーに義務付けることによって、セキュリティを強化します。ユーザーには、6 桁の数字のコード、つまり MFA トークンを生成する AWS 対応の MFA メカニズムが必要です。詳細については、「MFA デバイスの有効化」を参照してください。

このデモでは、再起動またはフェイルオーバーを実行するように Alexa とやり取りするたびに、ユーザー自身を認証するための MFA トークンを提供しなければなりません。Alexa に対してコマンドと共に音声で提供されるこのトークンは、GetSessionToken アクションを通じて STS に送信されます。

AWS STS は、認証対象の IAM ユーザー、またはフェデレーティッドユーザーのために、権限が制限された一時的な認証資格をリクエストできるようにします。ユーザーは、フェイルオーバーと再起動を実行するための認証について、これらの一時的な認証資格に依存します。

そこで問題になるのが、STS によって提供された GetSessionToken アクションは、Lambda 関数で直接リクエストできないということです。Lambda 関数が実行されると、AWS の他のサービスとやり取りするための IAM 実行ロールを自動的に引き受けますが、GetSessionToken は、IAM ロールではなく、IAM ユーザーの長期的な AWS セキュリティ認証情報を使って呼び出される必要があります。では、Alexa を使って再起動またはフェイルオーバーをリクエストするにはどうすればよいのでしょうか。

解決策は、以下の特性を持つ個別の IAM ユーザーを作成することです。

プログラム的なアクセスが有効になっている
ポリシーが関連付けられていない
グループが割り当てられていない
MFA 認証が有効になっている

デモを構築するために使用された AWS CloudFormation テンプレートは、入力パラメータとして IAM ユーザーの長期的な AWS セキュリティ認証情報を提供し、パラメータストアを使ってそれらを暗号化されたパラメータとして保存します。

音声で再起動またはフェイルオーバーをリクエストすると、Lambda 関数が、前述の GetSessionToken を呼び出すことによって、提供された MFA トークンの有効性を確認します。以下が RebootInstance インテントの呼び出し時に実行されるコードです。

if IsMFAValid('mfatoken'):
  rds.reboot_db_instance(DBInstanceIdentifier=identifier, ForceFailover=False)
  final_str = "Reboot in progress for the " + instance_name + " instance in " + region
else:
  final_str = "Reboot not authorized for the " + instance_name + " instance in " + region

このコードは、IsMFAValid 関数を表しています。引用されたトークンは、再起動またはフェイルオーバーを承認するためだけに使用される、アクセス許可のない IAM ユーザー (この記事の前のセクションを参照) にリンクされます。

def IsMFAValid(token):
    # The GetSessionToken function throws an error when the token is invalid
    try:
        stscall.get_session_token(
            SerialNumber='arn:aws:iam::959815022820:mfa/nopermissions',
            TokenCode=token,
        )
        return True
    except:
        return False

Alexa とのやり取りの例は以下のようになります。

ユーザー: OREGON にある BLOG インスタンスをフェイルオーバー、mfa 645 281 Alexa: OREGON にある BLOG インスタンスのフェイルオーバーが進行中です

次のステップ

データベースの認証情報、API キー、およびその他シークレットの管理と取得に役立つサービス、AWS Secrets Manager を使ってデータベースのパスワードを管理することもできます。Secrets Manager では、コードをデプロイすることなく、これらの機密項目をセキュアにローテーションさせることも可能です。

Amazon Lex または Amazon Polly などの新しいサービスは、音声とチャットを使ってデータを管理するインタラクティブなウェブおよびモバイルアプリケーションを作成するために役立ち、その結果はすぐさま画面に表示できます。

最後に、音声を使ってデータベースのより高度な側面を管理する方法を学ぶこともできます。たとえば、特定のインスタンスのマルチ AZ 機能をアクティブ化/非アクティブ化する、リードレプリカを追加/削除する、またはクローン、復元、および復旧操作を管理することが可能です。

結論

この記事では、単一の RDS データベース、またはフリート全体をセキュアに監視し、管理するために Amazon Alexa を使用する方法について説明しました。適切な標準化と自動化により、自分の声を使って複雑なデータ環境、またはインフラストラクチャ全体をも管理することが可能です。 IT 管理者、そしてこれらのリソースを使って作業を行うことが許可されている人なら誰でも、E メールまたは SMS を使用してシステムから情報を迅速かつセキュアに取得し、それぞれの目的のために使用することができます。

ご質問またはご意見などがありましたら、お気軽にご連絡ください。いつでも大歓迎です!

ご質問またはご提案などについては、以下からコメントを残してください。

著者について

Marco Tamassia は、AWS のテクニカルインストラクターです。

Amazon Web Services ブログ