【注意】Amazon Aurora(MySQL)でZero Downtime Patch実行時に不具合が発生するケースがある【AWS】

はじめに

先日、Amazon Aurora(MySQL)の必須アップデートの案内が来たのでアップデートの検証作業を実施しておりました。
Zero Downtime Patch(以下、ZDP)が実行され、ダウンタイム無しでアップデートが行われるはずが、不具合が発生してしまいました。

ググっても関連する情報が見つからなかったので、取り急ぎ分かっている情報について記録しておきます。

なお、対象のアップデートは下記のものになります。(Cluster Version 1.14)

Database Engine Updates 2017-08-07
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20170807.html

ポイント(TL;DR)

重要なポイントは下記のとおりです。

Aurora(MySQL)に対し、DB Connection Poolを利用し、且つPrepared Statementを利用していると、Zero Downtime Patch実行時に不具合が発生する可能性が高い。
Aurora(MySQL)のアップデートを行う前に、アプリの構成・実装を調べた方が良い。

Zero Downtime Patch(ZDP)とは何か

Auroraを無停止(正確には5秒程度の遅延)でアップデートできる画期的な仕組みです。
アップデート処理中にも、クライアントからのDB接続は維持されます。

今回、Cluster Version 1.14へのアップデートとなりますが、本アップデートに関するドキュメントにも説明があります。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20170807.html

AuroraのCluster Version 1.10で初めて導入されたようです。
ZDPの内容について、下記ドキュメントにも記載があります。

Database Engine Updates 2016-12-14
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20161214.html

こちらの記事も情報がまとまっていて参考になります。

Amazon Aurora のアップグレード
https://qiita.com/tonishy/items/542f7dd10cc43fd299ab

事象の内容

Aurora(MySQL)でClusterのアップデートが必要の旨の案内が来たため、AWS Management Consoleからアップデートを行いました。
AuroraのClusterアップデートは無事に完了しましたが、当該Auroraインスタンスを利用しているJavaアプリが軒並みエラーを吐き出し始めました。
その後Javaアプリを再起動し、復旧しました。

AWS Management Console上、WriterとなっているインスタンスのEventに下記のものが表示されました。
従って、Zero Downtime Patchが行われていたことは間違いありません。

The database was successfully patched with a zero downtime patch.

Javaアプリのログ上には、「Unknown prepared statement handler」といったエラーが多数出力されておりました。

事象の原因

当該JavaアプリはJDBC Connection Poolを利用し、DBとの接続を維持する構成になっています。
また、Prepared Statementを利用する実装になっております。

ZDP実行時、MySQLのクライアント(i.e. Javaアプリ)からの接続は維持されるようですが、Prepared Statementは維持されないことが原因のようでした。
時系列的に整理すると、下記のような状況になっていたようです。

  1. Javaアプリ起動時、Auroraに対して幾つかJDBC接続を確立する
  2. リクエストに応じて、JavaアプリからAuroraにクエリを発行する。この際、Prepareを発行してPrepared Statementを作る。
    Javaアプリは、同一のリクエストに対してはPrepared Statementを再利用する。
  3. AuroraのアップデートをZDPで行う。この際、JavaアプリからのJDBC接続は維持されるが、Prepared Statementは全てクリアされる。
  4. Javaアプリに対し、項番2と同様のリクエストを行う。Javaアプリは、コンパイル済みのPrepared Statementが存在しているという認識のまま、これを再利用しようとし、エラーとなる。

同一のアプリに対し、Prepared Statementを利用するもの/しないものを用意してAuroraのアップデートを実施しました。
結果、前者はエラーが発生し、後者はエラーが発生しませんでした。

なお上記の挙動は、独自に調査・検証したものとなります。
現在、AWSの公式見解・ドキュメント等の情報は見つけられておりません。
# 一応、Database Engine Updates 2016-12-14には以下の記載がありますが、これが該当するかどうかは不明です。
# Note that temporary data like that in the performance schema is reset during the upgrade process.

2017/9/26にAWSサポートへの問い合わせを行っておりますが、2017/10/19現在、回答待ちの状況です。

確認した環境・構成

上記事象は、下記構成のJavaアプリで確認しました。

  • Java 8 (Oracle JDK)
  • spring-boot-1.4.0.RELEASE
  • mybatis-spring-boot-starter 1.1.1
  • mariadb-java-client 1.5.5

併せてMyBatisGeneratorも利用しています。
特別な理由がない限り、JavaアプリからはMyBatisGeneratorで生成されたMapperとClassを利用しています。

デフォルトでは、MyBatisGeneratorではPrepared Statementを利用するMapperを生成するようです。

回避策

回避策は概ね以下の3通りになると思います。

1.Prepared Statementを利用しないよう、アプリを変更する。

ソースコード/ORマッパーの改修・設定変更を行い、Prepared Statementを利用しないようにする方法です。
おそらく、この対応は難しいケースがほとんどだと思います。

2.MySQL接続ドライバの設定で、Prepared Statementを利用しないよう変更する。 

今回のケースでは、MariaDB Connector/Jを利用しており、オプションを指定することでPrepared Statementを利用しないように変更することができました。

useServerPrepStmtsオプションをfalseにすることで実現可能です。
ちなみに、1.6.0以降のバージョンはデフォルトでfalseになっているようですので、これ以降のバージョンを利用してる場合は、本件の影響を受けません。

About MariaDB Connector/J -> Optional URL parameters -> Essential options
https://mariadb.com/kb/en/library/about-mariadb-connector-j/

3.ZDPではない、通常のアップデートを実施する

Auroraインスタンスの再起動を伴う、通常のアップデートを実行することで、本件事象を回避することが可能と考えられます(※未検証)
20~30秒程度のダウンタイムが発生します。

下記に、ZDPにならないケースについて記載がありますので、このどれかを満たせば通常のアップデートになると推測できます(※未検証)

Database Engine Updates 2017-08-07 -> Zero-Downtime Patching
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20170807.html

  • Long-running queries are in progress
  • Open long-running transactions exist
  • Binary logging is enabled
  • Binary log replication is running
  • Pending parameter changes exist
  • Temporary tables are in use
  • Table locks are in use
  • Open SSL connections exist

まとめ

DBへのConnection Poolを利用し、且つPrepared Statementを利用するようアプリを実装していると、不具合が発生する可能性が高いです。

経験的な感覚ですが、JavaアプリはConnection Poolを利用しているケースが多いかと思います。
Aurora(MySQL)を利用している場合は、チェックをした方が良いかと思います。

検証作業について

古いClusterバージョンのAuroraインスタンスを作ることはできません。AWSサポートにも聞いてみましたが無理なようでした。
従って、運良く過去に構築した古いAuroraインスタンスが存在していれば検証は可能ですが、それ以外のケースでは検証手段がありません。

続きを読む

AWS関連用語まとめ

個人的に今勉強中のAWS関連の用語をなるべく簡単にまとめてみました。(語弊がある部分もあるかもしれませんが個人的に理解できる形で落とし込んでみました)。今後も随時追加予定

EC2

仮想サーバ

S3

Amazon Simple Storage Service。オンラインストレージサービス

EBS

Amazon Elastic Block Store。オンライン外付けストレージ

ELB

Elastic Load Barancing。ロードバランサー

EIP

Elastic IP。固定のグローバルIP

RDS

Relational Database Service。クラウド型RDBMS

AMI

Amazon Machine Image。ソフトウェア構成(オペレーティングシステム、アプリケーションサーバー、アプリケーションなど)を記録したテンプレート

IAM

AWS Identity and Access Management。AWSへのアクセスを安全に制御するための仕組み

VPC

Virtual Private Cloud。仮想プライベートクラウド。

CloudFormation

環境設定に関してソースコード化したものを読み込んでAWS上に環境構築してくれるサービス(インフラをコード化してくれるなんてすごいね)

CodePipeline

システムのリリースにおけるプロセスを監視し、自動化・視覚化してくれるサービス。GitHubでMasterブランチへのマージを検知し→ビルド→デプロイ作業を自動で行ってくれる、みたいな事ができる

CodeBuild

CodePipelineで連携している機能の一部。自動でビルドしてくれる

CodeDeploy

CodePipelineで連携している機能の一部。自動でデプロイしてくれる

続きを読む

RedashをAMIから起動してみた

公式AMIからインスタンスの起動

https://redash.io/help-onpremise/setup/setting-up-redash-instance.html

から AMI を選択します。Region ap-northeast-1 の AMI リンクをクリックするとインスタンスタイプを選択する画面に遷移するので、適当なインスタンスタイプを選択します。

1年間の無料枠を使っているので無料で使える t2.micro にしました。

キーペアを設定して起動します。

アクセス設定

マネジメントコンソールからインスタンスのセキュリティーグループのインバウンドで HTTP アクセスを適切に許可します。

これでブラウザからインスタンスのIPにアクセスすればページが表示されます。

internal_server_error.png

Internal Server Error(500エラー)ですね。サービス側に問題がありそうなので確認します。

サーバ側設定

起動したインスタンスに SSH ログインします。

とりあえずサービスを再起動してみます。

$ sudo supervisorctl restart all
redash_server: stopped
redash_celery_scheduled: stopped
redash_celery: stopped
redash_celery: started
redash_server: started
redash_celery_scheduled: started

再度ブラウザをリロードしてみますが、Internal Server Error に変化はありません。

supervisord のログを確認します。

$ less /var/log/supervisor/supervisord.log

が、怪しそうなログは出ていません。Redash が使っているサービスの起動状態をひとつひとつ確認します。

PostgreSQL のプロセスを確認します。

$ ps aux | grep -i postgres
ubuntu   21547  0.0  0.0  12948   932 pts/0    S+   13:47   0:00 grep --color=auto -i postgres

見つからないので、PostgreSQL が起動していない事が原因のようです。ログを確認します。

$ less /var/log/postgresql/postgresql-9.5-main.log
2017-10-16 13:32:30 UTC [1352-1] LOG:  database system was shut down at 2017-08-13 12:39:56 UTC
2017-10-16 13:32:30 UTC [1352-2] LOG:  MultiXact member wraparound protections are now enabled
2017-10-16 13:32:30 UTC [1351-1] LOG:  database system is ready to accept connections
2017-10-16 13:32:30 UTC [1356-1] LOG:  autovacuum launcher started
2017-10-16 13:32:31 UTC [1361-1] [unknown]@[unknown] LOG:  incomplete startup packet
2017-10-16 13:34:33 UTC [1351-2] LOG:  received fast shutdown request
2017-10-16 13:34:33 UTC [1351-3] LOG:  aborting any active transactions
2017-10-16 13:34:33 UTC [1705-1] redash@redash FATAL:  terminating connection due to administrator command
2017-10-16 13:34:33 UTC [1704-1] redash@redash FATAL:  terminating connection due to administrator command
2017-10-16 13:34:33 UTC [1356-2] LOG:  autovacuum launcher shutting down
2017-10-16 13:34:34 UTC [1353-1] LOG:  shutting down
2017-10-16 13:34:34 UTC [1353-2] LOG:  database system is shut down
2017-10-16 13:34:53 UTC [19851-1] FATAL:  could not map anonymous shared memory: Cannot allocate memory
2017-10-16 13:34:53 UTC [19851-2] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 148488192 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

FATAL エラーが出てますね。その前にログの時刻が見づらいので、タイムゾーンを日本時間に変更します。

$ sudo timedatectl set-timezone Asia/Tokyo
$ date
Mon Oct 16 22:53:17 JST 2017

JST に変わりました。

先ほどの PostgreSQL のエラーは割り当てられたメモリサイズが大きいというもののようです。

$ sudo vi /etc/postgresql/9.5/main/postgresql.conf

#max_connections = 100
max_connections = 50

#shared_buffers = 128MB
shared_buffers = 32MB

少ないですね。再起動します。

$ sudo /etc/init.d/postgresql restart
Restarting postgresql (via systemctl): postgresql.service.

プロセスを確認します。

$ ps aux | grep -i postgres
postgres 21785  0.0  1.5 186840 15880 ?        S    23:02   0:00 /usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.5/main -c config_file=/etc/postgresql/9.5/main/postgresql.conf
postgres 21787  0.0  0.3 186840  3832 ?        Ss   23:02   0:00 postgres: checkpointer process
postgres 21788  0.0  0.3 186840  3832 ?        Ss   23:02   0:00 postgres: writer process
postgres 21789  0.0  0.3 186840  3832 ?        Ss   23:02   0:00 postgres: wal writer process
postgres 21790  0.0  0.6 187244  6104 ?        Ss   23:02   0:00 postgres: autovacuum launcher process
postgres 21791  0.0  0.3 148544  3128 ?        Ss   23:02   0:00 postgres: stats collector process
ubuntu   21808  0.0  0.1  12948  1092 pts/0    S+   23:02   0:00 grep --color=auto -i postgres

起動した!

ブラウザからアクセスすると。

welcome_redash.png

表示された!

Admin ユーザを登録すればとりあえず使えるようになります。

このままだとメール設定などが出来ていなので、必要であればヘルプ

https://redash.io/help/

などを参考にします。

ちなみに

最初に試した時は、次のような en_US.UTF-8 ロケールが無いというエラーが出ていました。

2017-10-09 08:38:28 UTC [2801-1] redash@redash FATAL:  database locale is incompatible with operating system
2017-10-09 08:38:28 UTC [2801-2] redash@redash DETAIL:  The database was initialized with LC_COLLATE "en_US.UTF-8",  which is not recognized by setlocale().
2017-10-09 08:38:28 UTC [2801-3] redash@redash HINT:  Recreate the database with another locale or install the missing locale.

確認すると確かに無い。

$ locale -a
C
C.UTF-8  # en_US.utf8 がない
POSIX

そのため、次のようにして en_US.UTF-8 をインストールして起動しました。

$ sudo locale-gen en_US.UTF-8
$ locale -a
C
C.UTF-8
en_US.utf8
POSIX

この記事を書くために最初から通して試してみたら en_US.utf8 ローカルが入っていて、再現しませんでした。

Issue を立てたのですが、勘違いだった可能性が高いのでそっと閉じました。

続きを読む

DynamoDBの予約語一覧を無理やり動的に取得してみた

DynamoDBの予約語を対処するために一覧が欲しくなったのですが、いちいちプログラム内で定義したくなかったので、AWSの予約語一覧ページから一覧を取得するサービスを作りました。

前提

  1. AWSが公開しているDynamoDB予約語一覧のWebページ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ReservedWords.html )をスクレイピングして予約語一覧を抽出します。
  2. 実装はAWS Lambda (Python3)、Webサービスとして動作させるためにAPI Gatewayを利用します。

結果

https://github.com/kojiisd/dynamodb-reserved-words

DynamoDB予約語一覧ページの確認

今回は以下のページをParseしたいと思います。

http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/ReservedWords.html

HTMLを見てみると、Parseしたい箇所はcodeタグで囲まれているようで、しかもこのページ内でcodeタグが出現するのは1度だけのようです。

スクリーンショット 2017-10-15 18.03.18.png

これであればすぐにパースできそうです。

HTMLの取得とParse

BeautifulSoupを利用すれば、簡単に実装ができます。BeautifulSoupのインストールは他のページでいくらでも紹介されているので、ここでは省略します。

import sys
import os


sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)), 'lib'))
from bs4 import BeautifulSoup
import requests

URL = os.environ['TARGET_URL']

def run(event, context):

    response = requests.get(URL)
    soup = BeautifulSoup(response.content, "html.parser")

    result_tmp = soup.find("code")
    if result_tmp == None:
        return "No parsing target"

    result = result_tmp.string

    return result.split('n');

とりあえず申し訳程度にパースできない場合(AWSのページがcodeタグを使わなくなった時)を想定してハンドリングしています。

API Gatewayを定義してサービス化

コードが書けてしまえばAPI Gatewayを定義してサービス化するだけです。

設定は非常に単純なので割愛で。

スクリーンショット 2017-10-15 18.12.11_deco.png

アクセスしてみる

実際にアクセスしてみます。

$ curl -X GET https://xxxxxxxxxxx.execute-api.us-east-1.amazonaws.com/prod
["", "ABORT", "ABSOLUTE", "ACTION", "ADD", "AFTER", "AGENT", "AGGREGATE", "ALL", "ALLOCATE", "ALTER", "ANALYZE", "AND", "ANY", "ARCHIVE", "ARE", "ARRAY", "AS", "ASC", "ASCII", "ASENSITIVE", "ASSERTION", "ASYMMETRIC", "AT", "ATOMIC", "ATTACH", "ATTRIBUTE", "AUTH", "AUTHORIZATION", "AUTHORIZE", "AUTO", "AVG", "BACK", "BACKUP", "BASE", "BATCH", "BEFORE", "BEGIN", "BETWEEN", "BIGINT", "BINARY", "BIT", "BLOB", "BLOCK", "BOOLEAN", "BOTH", "BREADTH", "BUCKET", "BULK", "BY", "BYTE", "CALL", "CALLED", "CALLING", "CAPACITY", "CASCADE", "CASCADED", "CASE", "CAST", "CATALOG", "CHAR", "CHARACTER", "CHECK", "CLASS", "CLOB", "CLOSE", "CLUSTER", "CLUSTERED", "CLUSTERING", "CLUSTERS", "COALESCE", "COLLATE", "COLLATION", "COLLECTION", "COLUMN", "COLUMNS", "COMBINE", "COMMENT", "COMMIT", "COMPACT", "COMPILE", "COMPRESS", "CONDITION", "CONFLICT", "CONNECT", "CONNECTION", "CONSISTENCY", "CONSISTENT", "CONSTRAINT", "CONSTRAINTS", "CONSTRUCTOR", "CONSUMED", "CONTINUE", "CONVERT", "COPY", "CORRESPONDING", "COUNT", "COUNTER", "CREATE", "CROSS", "CUBE", "CURRENT", "CURSOR", "CYCLE", "DATA", "DATABASE", "DATE", "DATETIME", "DAY", "DEALLOCATE", "DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE", "DEFERRED", "DEFINE", "DEFINED", "DEFINITION", "DELETE", "DELIMITED", "DEPTH", "DEREF", "DESC", "DESCRIBE", "DESCRIPTOR", "DETACH", "DETERMINISTIC", "DIAGNOSTICS", "DIRECTORIES", "DISABLE", "DISCONNECT", "DISTINCT", "DISTRIBUTE", "DO", "DOMAIN", "DOUBLE", "DROP", "DUMP", "DURATION", "DYNAMIC", "EACH", "ELEMENT", "ELSE", "ELSEIF", "EMPTY", "ENABLE", "END", "EQUAL", "EQUALS", "ERROR", "ESCAPE", "ESCAPED", "EVAL", "EVALUATE", "EXCEEDED", "EXCEPT", "EXCEPTION", "EXCEPTIONS", "EXCLUSIVE", "EXEC", "EXECUTE", "EXISTS", "EXIT", "EXPLAIN", "EXPLODE", "EXPORT", "EXPRESSION", "EXTENDED", "EXTERNAL", "EXTRACT", "FAIL", "FALSE", "FAMILY", "FETCH", "FIELDS", "FILE", "FILTER", "FILTERING", "FINAL", "FINISH", "FIRST", "FIXED", "FLATTERN", "FLOAT", "FOR", "FORCE", "FOREIGN", "FORMAT", "FORWARD", "FOUND", "FREE", "FROM", "FULL", "FUNCTION", "FUNCTIONS", "GENERAL", "GENERATE", "GET", "GLOB", "GLOBAL", "GO", "GOTO", "GRANT", "GREATER", "GROUP", "GROUPING", "HANDLER", "HASH", "HAVE", "HAVING", "HEAP", "HIDDEN", "HOLD", "HOUR", "IDENTIFIED", "IDENTITY", "IF", "IGNORE", "IMMEDIATE", "IMPORT", "IN", "INCLUDING", "INCLUSIVE", "INCREMENT", "INCREMENTAL", "INDEX", "INDEXED", "INDEXES", "INDICATOR", "INFINITE", "INITIALLY", "INLINE", "INNER", "INNTER", "INOUT", "INPUT", "INSENSITIVE", "INSERT", "INSTEAD", "INT", "INTEGER", "INTERSECT", "INTERVAL", "INTO", "INVALIDATE", "IS", "ISOLATION", "ITEM", "ITEMS", "ITERATE", "JOIN", "KEY", "KEYS", "LAG", "LANGUAGE", "LARGE", "LAST", "LATERAL", "LEAD", "LEADING", "LEAVE", "LEFT", "LENGTH", "LESS", "LEVEL", "LIKE", "LIMIT", "LIMITED", "LINES", "LIST", "LOAD", "LOCAL", "LOCALTIME", "LOCALTIMESTAMP", "LOCATION", "LOCATOR", "LOCK", "LOCKS", "LOG", "LOGED", "LONG", "LOOP", "LOWER", "MAP", "MATCH", "MATERIALIZED", "MAX", "MAXLEN", "MEMBER", "MERGE", "METHOD", "METRICS", "MIN", "MINUS", "MINUTE", "MISSING", "MOD", "MODE", "MODIFIES", "MODIFY", "MODULE", "MONTH", "MULTI", "MULTISET", "NAME", "NAMES", "NATIONAL", "NATURAL", "NCHAR", "NCLOB", "NEW", "NEXT", "NO", "NONE", "NOT", "NULL", "NULLIF", "NUMBER", "NUMERIC", "OBJECT", "OF", "OFFLINE", "OFFSET", "OLD", "ON", "ONLINE", "ONLY", "OPAQUE", "OPEN", "OPERATOR", "OPTION", "OR", "ORDER", "ORDINALITY", "OTHER", "OTHERS", "OUT", "OUTER", "OUTPUT", "OVER", "OVERLAPS", "OVERRIDE", "OWNER", "PAD", "PARALLEL", "PARAMETER", "PARAMETERS", "PARTIAL", "PARTITION", "PARTITIONED", "PARTITIONS", "PATH", "PERCENT", "PERCENTILE", "PERMISSION", "PERMISSIONS", "PIPE", "PIPELINED", "PLAN", "POOL", "POSITION", "PRECISION", "PREPARE", "PRESERVE", "PRIMARY", "PRIOR", "PRIVATE", "PRIVILEGES", "PROCEDURE", "PROCESSED", "PROJECT", "PROJECTION", "PROPERTY", "PROVISIONING", "PUBLIC", "PUT", "QUERY", "QUIT", "QUORUM", "RAISE", "RANDOM", "RANGE", "RANK", "RAW", "READ", "READS", "REAL", "REBUILD", "RECORD", "RECURSIVE", "REDUCE", "REF", "REFERENCE", "REFERENCES", "REFERENCING", "REGEXP", "REGION", "REINDEX", "RELATIVE", "RELEASE", "REMAINDER", "RENAME", "REPEAT", "REPLACE", "REQUEST", "RESET", "RESIGNAL", "RESOURCE", "RESPONSE", "RESTORE", "RESTRICT", "RESULT", "RETURN", "RETURNING", "RETURNS", "REVERSE", "REVOKE", "RIGHT", "ROLE", "ROLES", "ROLLBACK", "ROLLUP", "ROUTINE", "ROW", "ROWS", "RULE", "RULES", "SAMPLE", "SATISFIES", "SAVE", "SAVEPOINT", "SCAN", "SCHEMA", "SCOPE", "SCROLL", "SEARCH", "SECOND", "SECTION", "SEGMENT", "SEGMENTS", "SELECT", "SELF", "SEMI", "SENSITIVE", "SEPARATE", "SEQUENCE", "SERIALIZABLE", "SESSION", "SET", "SETS", "SHARD", "SHARE", "SHARED", "SHORT", "SHOW", "SIGNAL", "SIMILAR", "SIZE", "SKEWED", "SMALLINT", "SNAPSHOT", "SOME", "SOURCE", "SPACE", "SPACES", "SPARSE", "SPECIFIC", "SPECIFICTYPE", "SPLIT", "SQL", "SQLCODE", "SQLERROR", "SQLEXCEPTION", "SQLSTATE", "SQLWARNING", "START", "STATE", "STATIC", "STATUS", "STORAGE", "STORE", "STORED", "STREAM", "STRING", "STRUCT", "STYLE", "SUB", "SUBMULTISET", "SUBPARTITION", "SUBSTRING", "SUBTYPE", "SUM", "SUPER", "SYMMETRIC", "SYNONYM", "SYSTEM", "TABLE", "TABLESAMPLE", "TEMP", "TEMPORARY", "TERMINATED", "TEXT", "THAN", "THEN", "THROUGHPUT", "TIME", "TIMESTAMP", "TIMEZONE", "TINYINT", "TO", "TOKEN", "TOTAL", "TOUCH", "TRAILING", "TRANSACTION", "TRANSFORM", "TRANSLATE", "TRANSLATION", "TREAT", "TRIGGER", "TRIM", "TRUE", "TRUNCATE", "TTL", "TUPLE", "TYPE", "UNDER", "UNDO", "UNION", "UNIQUE", "UNIT", "UNKNOWN", "UNLOGGED", "UNNEST", "UNPROCESSED", "UNSIGNED", "UNTIL", "UPDATE", "UPPER", "URL", "USAGE", "USE", "USER", "USERS", "USING", "UUID", "VACUUM", "VALUE", "VALUED", "VALUES", "VARCHAR", "VARIABLE", "VARIANCE", "VARINT", "VARYING", "VIEW", "VIEWS", "VIRTUAL", "VOID", "WAIT", "WHEN", "WHENEVER", "WHERE", "WHILE", "WINDOW", "WITH", "WITHIN", "WITHOUT", "WORK", "WRAPPED", "WRITE", "YEAR", "ZONE "]

うまくできました。

まとめ

思いつきで作成してみましたが、AWSのページが閉鎖されたりHTML構造が変更されない限り、仕様変更などは気にせずに使えそうです。

あとBeautifulSoup初めて使いましたが、かなり便利。

続きを読む

AWSの用語と解説

AWS(Amazon Web Services)General_AWScloud.png

インフラ系のクラウドサービスを提供しているAWSは2006年3月から始まり、現在10周年。
アメリカでは政府機関が使っているほど高いセキュリティ

サービスや機能は800個以上あり、もはや中の人も何がいつリリースされたかわからないらしい

Region(リージョン)

AWSは世界中のデータセンターのサーバーで実行されており、サービスを開始する時はリージョンを選択する
リージョンは以下の通り

リージョン
米国東部(バージニア北部) us-east-1
米国西部(オレゴン) us-west-2
米国西部(北カリフォルニア) us-west-1
欧州(アイルランド) eu-west-1
欧州(フランクフルト) eu-central-1
アジアパシフィック (シンガポール) ap-southeast-1
アジアパシフィック(東京) ap-northeast-1
アジアパシフィック (ソウル) ap-northeast-2
アジアパシフィック(シドニー) ap-southeast-2
南米 (サンパウロ) sa-east-1
中国(北京) cn-north-1

アジアパシフィックを選んでおけば問題ないが、特定のリージョンにしかないマイナーなサービスがあったりするので注意が必要

AZ(アベイラビリティゾーン)

リージョン内のデータセンターのことで、
東京リージョンだと ap-northeast-1a ap-northeast-1b ap-northeast-1c のAZがある

EC2(Elastic Compute Cloud) Compute_AmazonEC2.png

仮想サーバ

ブラウザ上で何回かクリックするだけで、簡単にインスタンスが立ち上がる
利用料金はインスタンスタイプや性能にもよるが、最低スペックで 744円/月 くらい?

RDS(Relational Database Service) Database_AmazonRDS.png

リレーショナルデータベース

Amazon Aurora  Oracle  Microsoft SQL Server  PostgreSQL  MySQL  MariaDB
からデータベースエンジンを選択可能

中でも MySQL5.6互換がある Amazon Auroraは1分あたり600万回のインサート、3000万件のセレクトが可能らしい。
下記のサイトによれば、DB性能向上が期待できそう?
http://dev.classmethod.jp/cloud/aws/wordpressdb-migrate-aurora/

Redshift  Database_AmazonRedshift.png

データウェアハウス

2TBから最大1.6PBまでスケール可能でログなどのビッグデータを保存するのによく使用される
カラムナー(列指向)と呼ばれるデータ格納方式が特徴

Redshift は、PostgreSQL 8.0.2 に基づいている。
なので、PostgreSQL 9系で追加されたクエリが使えなかったりする。

ElastiCache  Database_AmazonElasticCache.png

KVSのキャッシュサービス

Memcached・Redis から選べる
Elastic Cacheではなく ElastiCache(エラスティキャッシュ) という名前なので注意が必要

S3(Simple Storage Service) Storage_AmazonS3_bucket.png

オンラインストレージサービス

bucket(フォルダ)
object(ファイル)
という名称がある

1B ~ 5TBまでのオブジェクトを書き込み・読み込み・削除が可能
バケットに容量制限はない

・SLAは99.99%
・静的webサイトのホスティングが可能

CloudFront NetworkingContentDelivery_AmazonCloudFront.png

コンテンツデリバリネットワーク(CDN)

CDNはAkamaiなどがあるが、それに比べると割高

VPC(Virtual Private Cloud) General_virtualprivatecloud.png

仮想プライベートクラウド

Amazon VPCは、AWS上に利用者が占有可能な仮想プライベートネットワークを構築するためのサービス。
このVPCの内部にIPサブネットを作成し、その中に仮想サーバーの「EC2」やデータベースサーバーの「RDS」といったAWSのリソースを配置する。

・ユーザ側で使いたいIP空間(VPC) を作成
・VPCにユーザがサブネットを切ることができる
・サブネット単位で アクセスリストが設定できる

Route53 NetworkingContentDelivery_AmazonRoute53.png

DNSサーバ

DNSは通常マスターとスレーブ構成にすることが多く、2台で構成する場合が多いが
Route53では、4つのネームサーバーで構成され、全世界にDNSサーバーを設置しているので高可用性である
米国:20   欧州:16  アジア:12  オーストラリア:2   南米:2

・SLA100% (ほんとに?)
・DNSラウンドロビンでの負荷分散が可能
料金はかなり安い。

ホストゾーン
0.50 USD(ホストゾーンごと)/月 - 最初の25のホストゾーン
0.10 USD(ホストゾーンごと)/月 - それ以上のホストゾーン

標準的クエリ
0.400 USD(100 万クエリごと) - 最初の 10 億クエリ/月
0.200 USD(100 万クエリごと) - 10 億クエリ以上/月

1つのホストゾーンで、10億クエリ行かなければ、月1ドルかからない。

IAM(Identity and Access Management) SecurityIdentityCompliance_IAM.png

ユーザーの権限を管理できるサービス

ポリシーと呼ばれる権限をユーザーにアタッチすることで、該当ユーザーの操作できる範囲を限ることができる

ポリシーは自由に設定可能で、管理者が細かく設定可能で
例えば、とある管理者が s3-readonly-userを作成し S3の閲覧だけを許可するポリシーを作成してアタッチ。など

随時追加中…

続きを読む

何となくEC2(Amazone Linux)にMariaDBを入れてSpiderで水平Shardingしてみた

雑記と言うか備忘録と言うか、そんな感じでEC2にMariaDBの10.0系をyum経由で導入し、水平Sharding環境を構築しました

#RDS使えばいいんですけど、高いんですよね。それなりにお試しでならEC2を3台構成にすれば水平Shardingは遊べますし。

※構成例

MariaDB:USER / PASS = root / Spider
SERVER:三台 Spiderサーバ:1台 DATANODE:2台
※ IPは仮として
SpiderNode:192.168.10.10
Datanode1:192.168.10.11
Datanode2:192.168.10.12
としますので読み替えてご活用下さい
DB:example_db
table:books
使うエンジン:Spider&Innodb

下準備

yum -y update && shutdown -r now

1.MariaDBインストール
●MariaDBのレポジトリ追加

echo '# MariaDB 10.0 CentOS repository list - created 2014-04-02 07:21 UTC' >> /etc/yum.repos.d/mariadb.repo
echo '# http://mariadb.org/mariadb/repositories/' >> /etc/yum.repos.d/mariadb.repo
echo '[mariadb]' >> /etc/yum.repos.d/mariadb.repo
echo 'name = MariaDB' >> /etc/yum.repos.d/mariadb.repo
echo 'baseurl = http://yum.mariadb.org/10.0/centos6-amd64' >> /etc/yum.repos.d/mariadb.repo
echo 'gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB' >> /etc/yum.repos.d/mariadb.repo
echo 'gpgcheck=1' >> /etc/yum.repos.d/mariadb.repo
echo 'enable=1' >> /etc/yum.repos.d/mariadb.repo

●MariaDBの起動

yum install -y MariaDB-server MariaDB-client

●MariaDB起動

chkconfig mysql on
/etc/rc.d/init.d/mysql start

2.MariaDBの初期設定
●設定適用(対象:全サーバ)


/usr/bin/mysqladmin -u root password 'Spider'
mysql -u 'root' --password='Spider' -e 'CREATE DATABASE example_db;GRANT ALL PRIVILEGES ON *.* TO "root"@"192.168.10.%" IDENTIFIED BY "Spider";FLUSH PRIVILEGES;'

●設定適用(対象:Spiderサーバのみ)
▼MariaDBへのspiderエンジンのインストール

mysql -u 'root' --password='Spider' -e 'source /usr/share/mysql/install_spider.sql'

確認は mysql -u 'root' --password='Spider' -e 'show engines;' にて

●データノードのspiderサーバへの登録(対象:Spiderサーバのみ)

mysql -u 'root' --password='Spider' -e 'CREATE SERVER db1 FOREIGN DATA WRAPPER mysql OPTIONS (USER "root", PASSWORD "Spider", HOST "192.168.10.11", PORT 3306);'
mysql -u 'root' --password='Spider' -e 'CREATE SERVER db2 FOREIGN DATA WRAPPER mysql OPTIONS (USER "root", PASSWORD "Spider", HOST "192.168.10.12", PORT 3306);'

こちらも確認は mysql -u 'root' --password='Spider' -e 'select * from servers;' mysql にて

●スキーマの登録(対象:SpiderNodeのみ)

    CREATE TABLE books
    (
        id int AUTO_INCREMENT NOT NULL,
        name VARCHAR(255) NOT NULL,
        price int(11) NOT NULL default 0,
        created_at DATETIME NOT NULL,
        updated_at DATETIME,
        lock_version int(11) NOT NULL default 0,
        PRIMARY KEY (id)
    ) ENGINE = SPIDER DEFAULT CHARSET=utf8
    PARTITION BY HASH(id) (
      PARTITION p1 comment 'server "db1", table "books"',
      PARTITION p2 comment 'server "db2", table "books"'
    );

●スキーマの登録(対象:db1,db2)

    CREATE TABLE books
    (
        id int AUTO_INCREMENT NOT NULL,
        name VARCHAR(255) NOT NULL,
        price int(11) NOT NULL default 0,
        created_at DATETIME NOT NULL,
        updated_at DATETIME,
        lock_version int(11) NOT NULL default 0,
        PRIMARY KEY (id)
    ) ENGINE = SPIDER DEFAULT CHARSET=utf8
    ;

●Spiderサーバの「my.cnf」設定変更(対象:Spiderサーバのみ)

echo '[mysqld]' >> /etc/my.cnf
echo 'spider_internal_sql_log_off = ON' >> /etc/my.cnf
echo 'spider_remote_sql_log_off   = 1' >> /etc/my.cnf

●Spiderサーバの「my.cnf」設定変更(対象:Spiderサーバのみ)

/etc/rc.d/init.d/mysql restart

お仕舞。

テスト:以下10行のクエリを発行する
※クエリの発行はSpiderサーバのexample_dbで実施

    INSERT INTO books(name, price, created_at) VALUES ('3日で分かるJava', 2500, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('3日で分かるRuby', 2300, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('独習仮想化',      5000, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('Java入門',        2000, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('入門Ruby',        2800, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('Effective Ruby',  4200, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('すごいRuby',      5800, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('Ruby徹底入門',    3000, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('RubyからJavaへ',  1800, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('クラウド大全',    6000, NOW());

●Spiderノード上で全件Select

  MariaDB [example_db]> select * from books order by id;
  +----+----------------------+-------+---------------------+------------+--------------+
  | id | name                 | price | created_at          | updated_at | lock_version |
  +----+----------------------+-------+---------------------+------------+--------------+
  |  1 | 3日で分かるJava      |  2500 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  2 | 3日で分かるRuby      |  2300 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  3 | 独習仮想化           |  5000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  4 | Java入門             |  2000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  5 | 入門Ruby             |  2800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  6 | Effective Ruby       |  4200 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  7 | すごいRuby           |  5800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  8 | Ruby徹底入門         |  3000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  9 | RubyからJavaへ       |  1800 | 2017-09-13 00:06:51 | NULL       |            0 |
  | 10 | クラウド大全         |  6000 | 2017-09-13 00:06:51 | NULL       |            0 |
  +----+----------------------+-------+---------------------+------------+--------------+
  10 rows in set (0.01 sec

●db1ノード上で全件Select

  MariaDB [example_db]> select * from books order by id;
  +----+----------------------+-------+---------------------+------------+--------------+
  | id | name                 | price | created_at          | updated_at | lock_version |
  +----+----------------------+-------+---------------------+------------+--------------+
  |  2 | 3日で分かるRuby      |  2300 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  4 | Java入門             |  2000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  6 | Effective Ruby       |  4200 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  8 | Ruby徹底入門         |  3000 | 2017-09-13 00:06:51 | NULL       |            0 |
  | 10 | クラウド大全         |  6000 | 2017-09-13 00:06:51 | NULL       |            0 |
  +----+----------------------+-------+---------------------+------------+--------------+
  5 rows in set (0.00 sec)

●db2ノード上で全件Select

  MariaDB [example_db]> select * from books order by id;
  +----+----------------------+-------+---------------------+------------+--------------+
  | id | name                 | price | created_at          | updated_at | lock_version |
  +----+----------------------+-------+---------------------+------------+--------------+
  |  1 | 3日で分かるJava      |  2500 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  3 | 独習仮想化           |  5000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  5 | 入門Ruby             |  2800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  7 | すごいRuby           |  5800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  9 | RubyからJavaへ       |  1800 | 2017-09-13 00:06:51 | NULL       |            0 |
  +----+----------------------+-------+---------------------+------------+--------------+
  5 rows in set (0.00 sec)

出来てますね

続きを読む

【HashiCorp Vault】Dynamic Secrets (Secret Backend) の Lease 機能を試す

はじめに

Dynamic Secrets (Secret Backend) の Lease 機能について動作を確認しましたので備忘録として記録しておきます。

やったこと

  1. Vaultが作成したAWSユーザの有効期限(TTL)を確認する
  2. Lease機能を利用して有効期限(TTL)を設定する
  3. Lease機能を利用してAWSユーザの有効期限(TTL)を延長する

HashiCorp Vaultとは?

HashiCorpが提供している機密情報の管理ツールです。

Dynamic Secrets (Secret Backend) とは

VaultにAWSやDatabaseなどのアカウントを管理させる機能です。

この機能を利用することでVaultを通じてAWSなどのユーザ作成、削除を実施できるようになります。
有効期間が経過したユーザについてはVaultが自動で削除を行ってくれます。

参考

公式サイト

Vault by HashiCorp

ドキュメント

AWS Secret Backend – HTTP API – Vault by HashiCorp
/sys/leases – HTTP API – Vault by HashiCorp

過去の投稿

HashiCorp Vault の Dynamic Secrets (Secret Backend) を試す – Qiita


事前準備

VaultをDevモードで起動

$ vault server -dev

...
    export VAULT_ADDR='http://127.0.0.1:8200'
...
Root Token: dae8c23c-3749-0286-abc5-fbdf57b634f1

環境変数の設定

$ export VAULT_ADDR='http://127.0.0.1:8200'
$ export VAULT_TOKEN='dae8c23c-3749-0286-abc5-fbdf57b634f1'

AWS Backendをマウント

$ vault mount aws
Successfully mounted 'aws' at 'aws'!

AWSのTokenを設定

$ vault write aws/config/root 
    access_key=AKIAIFOCRMPWZMVED74Q 
    secret_key=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
Success! Data written to: aws/config/root

ポリシーを設定

policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
$ vault write aws/roles/deploy policy=@policy.json
Success! Data written to: aws/roles/deploy

1. Vaultが作成したAWSユーザの有効期限(TTL)を確認する

初期状態でLease設定や有効期限(TTL)を確認します。

Lease設定を確認する

Lease設定を確認しても、未設定のため取得できません。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/config/lease

{"errors":[]}

VaultにAWSユーザを作成させる

この状態(Lease未設定)でAWSユーザを作成せた場合、lease_duration": 2764800となっています。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/creds/deploy

{
  "request_id": "333374cd-1d0e-6015-adc9-85656d78a1c9",
  "lease_id": "aws/creds/deploy/6ceb69a0-249a-e65e-ff9a-9996a85bed45",
  "renewable": true,
  "lease_duration": 2764800,
  "data": {
    "access_key": "AKIAJIFBBLEAXHS4NQNQ",
    "secret_key": "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",
    "security_token": null
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

Lease設定を確認

AWSユーザのLease設定を確認すると、

  • “issue_time” : “2017-10-08T17:30:30.873476458+09:00”
  • “expire_time”: “2017-11-09T17:30:30.873476739+09:00”

となっており、有効期限(TTL)が 2764800秒 = 32日間 であることがわかりました。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/6ceb69a0-249a-e65e-ff9a-9996a85bed45" }' 
    $VAULT_ADDR/v1/sys/leases/lookup

{
  "request_id": "21234bd6-e722-8993-22f7-175f2c4d8dc6",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-11-09T17:30:30.873476739+09:00",
    "id": "aws/creds/deploy/6ceb69a0-249a-e65e-ff9a-9996a85bed45",
    "issue_time": "2017-10-08T17:30:30.873476458+09:00",
    "last_renewal": null,
    "renewable": true,
    "ttl": 2764126
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

2. Lease機能を利用して有効期限(TTL)を設定する

初期設定では有効期限(TTL)が長いので、短い有効期限(TTL)を設定して、AWSユーザが実際に削除されるのか確認したいと思います。

Lease設定

lease30mlease_max12hに設定します。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request POST 
    --data '{ "lease": "30m",  "lease_max": "12h" }' 
    $VAULT_ADDR/v1/aws/config/lease

Lease設定を確認すると、lease, lease_maxが指定した値になっています。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/config/lease 

{
  "request_id": "3b09ce08-b6b6-848f-3622-f3711d1a7d26",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "lease": "30m0s",
    "lease_max": "12h0m0s"
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

AWSユーザ作成

Lease設定後にAWSユーザを作成させると、lease_duration": 1800となっています。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/creds/deploy

{
  "request_id": "5413657e-78e4-4128-e7c0-ed61c6158bc8",
  "lease_id": "aws/creds/deploy/5d7f8036-762b-8fcb-fcea-7bb7f1842f13",
  "renewable": true,
  "lease_duration": 1800,
  "data": {
    "access_key": "AKIAJCVNQTVWYDKAEIMA",
    "secret_key": "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",
    "security_token": null
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

AWSユーザのLease設定を確認すると、

  • “issue_time” : “2017-10-08T17:52:06.741853365+09:00”
  • “expire_time”: “2017-10-08T18:22:06.741853771+09:00”

となっており、有効期限(TTL)が1800秒 = 30分となってることがわかります。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/5d7f8036-762b-8fcb-fcea-7bb7f1842f13" }' 
    $VAULT_ADDR/v1/sys/leases/lookup

{
  "request_id": "e528ba92-53f0-cee0-973d-069612a24207",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-10-08T18:22:06.741853771+09:00",
    "id": "aws/creds/deploy/5d7f8036-762b-8fcb-fcea-7bb7f1842f13",
    "issue_time": "2017-10-08T17:52:06.741853365+09:00",
    "last_renewal": null,
    "renewable": true,
    "ttl": 1646
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

AWSユーザの削除確認

AWSの管理コンソールを確認したところ、expire_timeに到達したタイミングでVaultが作成したAWSユーザ(vault-root-deploy-1507452723-604)が削除されました。

expire_time到達前
vault_lease01.png

expire_time到達後
vault_lease02.png

3. Lease機能を利用してAWSユーザの有効期限(TTL)を延長する

Lease機能には有効期限(TTL)を延長(renew)させる機能があるので、こちらの動作も確認してみます。

AWSユーザ作成

前回と同様にVaultにAWSユーザを作成させます。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/creds/deploy

{
  "request_id": "15e22c37-ff2f-2277-6bc5-0834f4dd4eba",
  "lease_id": "aws/creds/deploy/f822cb89-98d6-0cd5-05e7-69020bda05b9",
  "renewable": true,
  "lease_duration": 1800,
  "data": {
    "access_key": "AKIAIGFBKDIZ6VU7UOUA",
    "secret_key": "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",
    "security_token": null
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

前回と同様にAWSユーザの有効期限(TTL)は30分間です。

  • “issue_time” : “2017-10-08T18:34:39.368521987+09:00”
  • “expire_time”: “2017-10-08T19:04:39.368522185+09:00”
$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/f822cb89-98d6-0cd5-05e7-69020bda05b9" }' 
    $VAULT_ADDR/v1/sys/leases/lookup

{
  "request_id": "f1848a4a-7f3f-8e0c-90cf-7024dd242c35",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-10-08T19:04:39.368522185+09:00",
    "id": "aws/creds/deploy/f822cb89-98d6-0cd5-05e7-69020bda05b9",
    "issue_time": "2017-10-08T18:34:39.368521987+09:00",
    "last_renewal": null,
    "renewable": true,
    "ttl": 1753
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

有効期限(TTL)の延長

Lease機能を利用してAWSユーザの有効期限(TTL)を3600秒(30分)延長させます。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9", "increment": 3600 }' 
    $VAULT_ADDR/v1/sys/leases/renew

{
  "request_id": "86f059ec-1680-c886-2ade-3e15635ed38e",
  "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9",
  "renewable": true,
  "lease_duration": 3600,
  "data": null,
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

Lease設定を確認するとexpire_timeが更新されてます。

issue_timeから+3600秒(30分)されるわけではなく、延長(renew)コマンドを実行した時点(last_renewal)から3600秒(30分)延長されるようです。

延長前

  • “issue_time” : “2017-10-08T18:34:39.368521987+09:00”
  • “expire_time”: “2017-10-08T19:04:39.368522185+09:00”

延長後

  • “issue_time” : “2017-10-08T18:27:57.65077363+09:00”
  • “last_renewal”: “2017-10-08T18:35:52.918241764+09:00”
  • “expire_time” : “2017-10-08T19:35:52.918241648+09:00”
$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9" }' 
    $VAULT_ADDR/v1/sys/leases/lookup
{
  "request_id": "f8e035a6-a72b-395a-aca0-641ed7c747ce",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-10-08T19:35:52.918241648+09:00",
    "id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9",
    "issue_time": "2017-10-08T18:27:57.65077363+09:00",
    "last_renewal": "2017-10-08T18:35:52.918241764+09:00",
    "renewable": true,
    "ttl": 3556
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

有効期限(TTL)の最大値を確認

lease_max12hに設定していたので12時間を超える有効期限(TTL)は設定できなくなっています。

有効期限(TTL)を 43200秒(1日)延長(renew)させても、expire_timeissue_timeの12時間後となっており、lease_maxを超えた有効期限(TTL)が設定できないことがわかります。

  • “issue_time” : “2017-10-08T18:27:57.65077363+09:00”
  • “last_renewal”: “2017-10-08T18:38:06.850822545+09:00”
  • “expire_time” : “2017-10-09T06:27:57.650782301+09:00”
$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9", "increment": 43200 }' 
    $VAULT_ADDR/v1/sys/leases/renew

{
  "request_id": "9ed0ca65-18ee-2186-689a-1569f4f9e058",
  "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9",
  "renewable": true,
  "lease_duration": 42590,
  "data": null,
  "wrap_info": null,
  "warnings": null,
  "auth": null
}
$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9" }' 
    $VAULT_ADDR/v1/sys/leases/lookup

{
  "request_id": "00d1c93f-431d-61f0-a116-b5d8a57af815",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-10-09T06:27:57.650782301+09:00",
    "id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9",
    "issue_time": "2017-10-08T18:27:57.65077363+09:00",
    "last_renewal": "2017-10-08T18:38:06.850822545+09:00",
    "renewable": true,
    "ttl": 42560
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

続きを読む

HashiCorp Vault の Dynamic Secrets (Secret Backend) を試す

はじめに

HashiCorpのVaultが提供しているDynamic Secrets (Secret Backend) 機能について公式ドキュメントを参考に動作を確認しましたので備忘録として残しておきます。

やったこと

Vaultの Dynamic Secrets (Secret Backend) 機能を利用してAWSユーザの作成・削除を行う。

HashiCorp Vaultとは?

HashiCorpが提供している機密情報の管理ツールです。

Dynamic Secrets (Secret Backend) とは

VaultにAWSやDatabaseなどのユーザを管理させる機能です。

この機能を利用することでVaultを通じてAWSなどのユーザ作成、削除を実施できるようになります。
有効期間が経過したユーザについてはVaultが自動で削除を行ってくれます。

参考

公式サイト

Vault by HashiCorp

ドキュメント

Dynamic Secrets – Getting Started – Vault by HashiCorp
AWS Secret Backend – Vault by HashiCorp


事前準備

VaultをDevモードで起動

DevモードではVaultを停止させるとデータが消えてしまいますが、今回は動作確認のためDevモードで起動します。

$ vault server -dev

...
    export VAULT_ADDR='http://127.0.0.1:8200'

環境変数の設定

$ export VAULT_ADDR='http://127.0.0.1:8200'

AWS Backendをマウント

$ vault mount aws
Successfully mounted 'aws' at 'aws'!

AWSユーザの作成

vaultがAWSを操作するためのユーザ(vault)を作成します。

本来であれば目的に応じたポリシーを付与するべきですが、今回は動作確認のため「AdministratorAccess」ポリシーを適用しました。

作成したユーザの「アクセスキー ID」と「シークレットアクセスキー」はvaultで利用するためメモしておきます。

vault01.png

vault02.png

vault03.png

vault04.png

vault05.png


AWS Backendの設定

Vault用に準備したAWSユーザの「アクセスキー ID」と「シークレットアクセスキー」をaws/config/rootに登録します。

$ vault write aws/config/root 
    access_key=AKIAJDCIHPTOLCKLM6WA 
    secret_key=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

Success! Data written to: aws/config/root

aws/config/rootに書き込んだ情報は読み取れなくなります。

$ vault read aws/config/root

Error reading aws/config/root: Error making API request.

URL: GET http://127.0.0.1:8200/v1/aws/config/root
Code: 405. Errors:

* 1 error occurred:

* unsupported operation

ロールの作成

Getting Started を参考にjsonファイルを作成します。
Actionにec2:*という記載があるので、EC2を操作するアカウントが作成されそうです。

policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

作成したjsonファイルを指定してロールを作成します。

$ vault write aws/roles/deploy policy=@policy.json

Success! Data written to: aws/roles/deploy

AWSユーザの作成

ロールを指定してAWSユーザを作成させます。
レスポンスとして作成したユーザの「アクセスキー ID」と「シークレットアクセスキー」が返却されます。

$ vault read aws/creds/deploy

Key             Value
---             -----
lease_id        aws/creds/deploy/2cfb960b-7f2e-74c4-d351-917401d27f3b
lease_duration  768h0m0s
lease_renewable true
access_key      AKIAIYMLSSQ434JIRMUQ
secret_key      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
security_token  <nil>

AWSの管理画面を確認すると新しいユーザ(vault-root-deploy-1507372260-9128)が作成されて、EC2を操作するアクセス権限をもってることがわかります。

vault06.png

vault07.png

vault08.png


AWSユーザの削除

lease_idを指定してユーザを削除します。

$ vault revoke aws/creds/deploy/2cfb960b-7f2e-74c4-d351-917401d27f3b

Success! Revoked the secret with ID 'aws/creds/deploy/2cfb960b-7f2e-74c4-d351-917401d27f3b', if it existed.

AWSの管理画面でもVaultが作成したユーザ(vault-root-deploy-1507372260-9128)が削除されたことがわかります。

vault09.png

補足

【HashiCorp Vault】Dynamic Secrets (Secret Backend) の Lease 機能を試す – Qiita

続きを読む