Category: Database*


Redshiftアップデート:列や表の名前に日本語が使用できるように

Amazon Redshift で列や表、もしくはビューといったオブジェクトの名前として日本語が利用可能になりました!これは以前から日本のお客様からご要望いただいていた機能ですので、以下で説明します。

Redshiftはこれまではデータとしては日本語を含むマルチバイト文字を格納可能でしたが、表や列の名前には使用できませんでした。これが改善され、Redshift v1.0.1122からは日本語のテーブル名や列名が利用可能になります。利用する前にご自身のRedshiftクラスターが1.0.1122以降に更新されているかをご確認ください。

列や表の名前は最大で127バイトまで利用でき、文字はUTF-8で保存されます(日本語の漢字やひらがなは1文字を表現するのに3バイト必要です)。以下のドキュメントも更新されています。現時点では日本語翻訳はまだ更新されていないので、英語に切り替えてご覧ください。

なおマルチバイト文字のテーブル名や列名を使用する場合は、RedshiftのJDBCドライバー 1.2.1以降、ODBCドライバー 1.3.1以降にアップデートする必要がある事に注意してください。どちらもRedshiftのマネジメントコンソールから、もしくは以下のリンクよりダウンロードが可能です(こちらも英語にしてご覧ください)。名前のマルチバイト対応だけでなく、バグフィックスや機能向上を含みますのでぜひこの機会にドライバを最新に更新して御利用ください。

RedshiftはPostgreSQLとの互換性がありますので、既存のPostgreSQLのJDBC/ODBCドライバやpsqlコマンドでの接続も可能です。パフォーマンスや機能の面から上記のRedshift専用ドライバの利用が強く推奨されますが、試しに手元の環境でpsqlコマンドでRedshift v1.0.1122に接続してみたところ、問題なく日本語のテーブル名や列名が利用できました。

下佐粉 昭(@simosako

Redshiftアップデート:CTASで表を作成時に自動的に圧縮されるように

Amazon Redshiftに次回適用されるパッチ(ver. 1.0.1115)の情報がフォーラムで公開されています。

メモリ確保やクエリーキャンセルの改善など、いくつかの機能改善に加えてCREATE TABLE AS SELECT (CTAS)のへ新機能が追加されていますので、ここではそれを紹介します。

CTASは、SELECTの結果(アンサーセット)を元にそのデータが入った表を作成するという構文です。Redshiftはデータウェアハウスとして利用される事が多いため、集計データの保存や、分析の途中のデータを表として保存して再利用する等のユースケースでCTASがよく利用されています。

このCTASを使って作成された表は各列が圧縮されないという課題がありました。CTASはSELECTの結果によって表が定義されるので、その元となる圧縮アルゴリズムが存在しないケースが考えられたためです。このためにCTASで作成されたデータはディスク領域をより多く使用することになり、処理のオーバーヘッドが大きくなってしまっていました。

今回のパッチではこれが改善され、自動的に各列にLZOで圧縮がかかるようになりました。列が含むデータの特性に関係なく一律でLZO圧縮を使用する形ですが、圧縮無しと比較して大きな改善ですし、多くのケースでLZO圧縮は安定した圧縮率を実現できるため有効なアプローチですね。特に大規模な利用ケースほど効果が高いと思われます。

ただし結果セットが返す列によっては圧縮されない場合もあります。列がソートキーである場合と、 BOOLEAN、 REAL、 DOUBLE PRECISION のどれかの型になった場合です。この場合その列はRAW、つまり未圧縮として作成されます。詳細は以下のドキュメントに記載されていますので、こちらもご覧ください。

ソートキー列を圧縮しないのはRedshiftのベストプラクティスに沿った動きです。こちらについては別の記事で解説しています。

フォーラムにもありますように、この機能を含んだ新バージョンはこれから2週間程度をかけて各リージョンにデプロイされていきます。ご利用のリージョンにデプロイされ、メンテナンスウィンドウでパッチが適用された後に利用可能になりますので、楽しみにお待ちください。

下佐粉 昭(@simosako

Amazon Auroraアップデート – ストアードプロシジャーからLambda Functionの呼び出しと S3からのデータ読み込みに対応 –

多くの AWS serviceはそれ自体だけでもよく動作しますが、組み合わせることで更に良くなります!この大事な我々のモデルは、各サービスを選択し学習を行ない、経験を積み時間とともに他のサービスへ拡張していく事が可能です。一方で、サービスを組み合わせて使う機会は常に存在し、お客様の要望に基づきロードマップへいくつも反映しています。

本日、MySQL互換のリレーショナルデータベースである、Amazon Auroraの2つの新機能をご紹介します。

  • Lambda Function Invocation – Amazon Auroraデータベース 内のストアードプロシジャーからAWS Lambdaのfunctionを呼び出すことが可能になりました
  • Load Data From S3 –  Amazon Simple Storage Service (S3)のバケットに保存されたデータをAmazon Auroraデータベースにロード可能になりました

これら2つの新機能はAmazon Auroraと他のAWSサービスを連携するためにAmazon Auroraに適切な権限を付与する必要があります。IAM Policyや IAM Roleを作成し、作成したRoleをAmazon Auroraデータベースクラスタへ付与します。詳細な手順はドキュメントをご覧ください。

 

Lambda Function Integration

ハイレベルな機能を実現するために、リレーショナルデータベースではトリガーやストアードプロシジャーを組み合わせて利用します。トリガーは特定のテーブルへの操作の前後で実行することが出来ます。例えば、Amazon AuroraはMySQLと互換性があるため、INSERT, UPDATE, DELETE操作へのトリガーをサポートしています。ストアードプロシジャーは実行されたトリガーへのレスポンスの中で実行可能なスクリプトです。

Lambda functionを呼び出すストアードプロシジャーを利用可能になりました。この拡張された機能を使うことで、Auroraデータベースと他のAWSサービスを結びつけることが出来るようになりました。Amazon Simple Email Service (SES)を利用してemailを送信したり、 Amazon Simple Notification Service (SNS)を利用し問題の通知を行ったり、Amazon CloudWatchにメトリクスを送信したり、 Amazon DynamoDBのテーブルを更新するようなことが可能です。

その他にも、複雑なETLジョブやワークフロー、データベース内のテーブルに対する監査、パフォーマンスモニタリングや分析なども用途として考えられます。

ストアードプロシジャーからはmysql_lambda_asyncプロシジャーを呼び出す必要があります。このプロシジャーは非同期で与えられたLambda functionを実行するため、Lambda functionの完了を待たずに処理を終了します。Lambda functionには利用するAWSサービスやリソースに対する権限を付与しておく必要があります。

詳細は、 Invoking a Lambda Function from an Amazon Aurora DB Clusterをご覧ください。

 

Load Data From S3

他の形のインテグレーションとして、S3バケットに保存されたデータを直接Auroraにインポート可能になりました (今までは一度Ec2インスタンス上にダウンロードしたあとにインポートする必要がありました)。

Amazon Auroraクラスタからアクセス可能であれば、AWSのどのリージョンにデータが配置されていてもロード可能です。形式はテキストかXML形式に対応しています。

テキスト形式のデータをインポートするためには、新しい LOAD DATA FROM S3コマンドを利用します。このコマンドはMySQLのLOAD DATA INFILEとほぼ同様のオプションをサポートしています。しかし、圧縮形式のデータは現在サポートしていません。特定の行やフィールドデリミタやキャラクタセットを設定可能で、指定した行や列数を無視して取り込むことも可能です。

XML形式のデータをインポートするためには、新しいLOAD XML from S3コマンドを利用します。XMLは以下の様な形式になります。

<row column1="value1" column2="value2" />
...
<row column1="value1" column2="value2" />

<row>
  <column1>value1</column1>
  <column2>value2</column2>
</row>
...

また

<row>
  <field name="column1">value1</field>
  <field name="column2">value2</field>
</row>
...

の形式に対応しています。

詳細は、Loading Data Into a DB Cluster From Text Files in an Amazon S3 Bucketをご覧ください。

 

すぐにご利用いただけます

これらの新機能は本日からご利用頂けます!

それぞれの機能には追加で料金はかかりませんが、通常のAmazon Aurora, Lambda, S3のご利用料金が発生します。

Jeff;  (翻訳は星野が担当しました。原文はこちら)

Amazon ElastiCache for Redisアップデート – Sharded Clusterの追加やエンジンバージョンを更新 –

多くのAWSのお客様に高速で、インメモリデータストアとして Amazon ElastiCacheをご利用頂いています。

2013年にAmazon ElastiCache for Redisリリースし、スナップショットのS3へのエクスポート機能エンジンバージョンの更新スケールアップ機能タグMulti-AZで自動フェイルオーバー機能を数年で追加してきました。

本日、新機能をElastiCache for Redisへ追加しました。詳細は以下の通りです。

  • Sharded Clusterサポート – 3.5 TiB以上をインメモリデータとして扱う事が出来るsharded clusterを作成可能になりました
  • コンソールの改善 – 以前より簡単にクラスタの作成やメンテナンスが行えるようになりました
  • エンジンアップデート – Redis 3.2の機能をご利用頂けるようになりました
  • Geospatial Data – 地理空間データの処理を行え、利用可能になりました

更に詳細を見ていきましょう!

 

Sharded Clusterサポート / 新コンソール

今まではElastiCache for Redisは1つのプライマリノードと5つまでのread replicaを含んだクラスタに対応していました。この構成では、メモリサイズがクラスタあたり237 GiBに制限されていました。

1クラスタで15シャードまで作成出来るようになったことで、クラスタ全体のメモリ容量を拡大することが可能になり、最大3.5 TiBまでのデータをインメモリデータとして格納出来ます。それぞれのシャードは5つまでread replicaを作成可能で、1秒あたり2,000万読み込み、450万書き込みの性能を提供します。

シャードモデルは、read replicaと合わせて利用することでクラスタ全体の可用性とパフォーマンスを向上します。データは複数のノードに分散され、read replicaは高速で自動的なフェイルオーバーをプライマリノードに障害が起こった際に提供します。

シャードモデルの利点を活かすために、cluster対応のRedisクライアントを使う必要があります。クライアントは、16,384個のスロットをシャード毎に均等に分散されたハッシュテーブルとして扱い、保存するデータを各シャードにマップします。

ElastiCache for Redisはクラスタ全体を1つのバックアップとリストア用途のユニットとして扱います。そのため、各シャード毎のバックアップを管理したり考えたりする必要がありません。

コンソールの機能が改善され、スケールアウトクラスタを簡単に作成可能になりました。(Redisエンジンを選択した後にCluster Mode enabled (Scale Out)にチェックを入れている点を注目して下さい)

ec_redis_create_so_cluster

新しい便利なメニューで適切なノードタイプを選択を手助けしてくれます

ec_redis_pick_your_node_not_your_nose

sharded clusterは、AWS Command Line Interface (CLI)AWS Tools for Windows PowerShellElastiCache APIAWS CloudFormationテンプレートからも作成可能です。

 

エンジンアップデート

Amazon ElastiCache for RedisはRedis3.2に対応しました。このバージョンは3つの興味深い機能を持っています。

  • Enforced Write Consistency – 新しいWAITコマンドはそれ以前の全ての書き込みコマンドに対して、プライマリノードと設定された数のread replicaから確認応答が返ってくるまで呼び出し元をブロックします。この変更はRedisを強い一貫性を持ったデータストアにするものではありません。しかし、新しく昇格したread replicaが直前にプライマリノードに書き込まれた出たデータを保持している可能性を向上します
  • SPOP with COUNTSPOPコマンドはsetからランダムにエレメントを削除してそれを返却します。1つ以上のエレメントを1回でリクエスト出来るようになりました
  • Bitfields – BitfieldsはRedis stringとして保存されていた小さい整数のコレクションをビットマップとして保存することでメモリ効率を良くする方法です。BITFIELDコマンドを使うことで、 (GET) や(SET, increment, decrement) をbyteアライメントや文字境界を気にすること無く扱うことが出来るようになります

私達のRedisの実装は、サーバプロセスをフォークする事なくスナップショットを取得する機能を持っています。過負荷状態では標準のフォークを利用したスナップショットはスワップによるパフォーマンスの低下を引き起こす可能性があります。私達の実装ではメモリ利用率が50%を越えていたとしても動作をし、問題を解決します。この機能は少し低速なため、必要になった場合にこの機能を利用します。

その他にも私達の実装では新しいread replicaがプライマリノードと同期する時のパフォーマンスを向上しています。これと似た性能向上を新しく昇格したプライマリノードと既存のread replicaが同期する際にも実装しています。

今までお伝えした通り、私達のエンジンはオープンソースバージョンのものと互換性があり、皆様のアプリケーションに変更は必要ありません。

 

Geospatial Data

地理空間データ(緯度・経度)を保存したりクエリ出来るようになりました。以下が関連するコマンドです。

  • GEOADD – 地理空間データを保存
  • GEODIST – 2地点間の距離を取得
  • GEOHASHGeohash (geocoding)を取得
  • GEOPOS – keyでしてされた地点のアイテムを取得
  • GEORADIUS – 指定された地点の半径内のアイテムを取得
  • GEORADIUSBYMEMBER – 他のアイテムの半径内に収まるアイテムを取得

 

今日からご利用頂けます

Sharded clusterを含む今回ご紹介した全ての機能は全てのAWSリージョン今日からご利用頂けます。

Jeff; (翻訳は星野が担当しました。原文はこちら)

Amazon RDS for OracleでOracle UTL_MailとJuly 2016 PSU Patchesがご利用可能になりました

UTL_MAILパッケージをご利用頂くことでRDS for Oracleデータベースから直接メールを送信頂けるようになりました。お使いのDBインスタンスでUTL_Mailを有効にするためには、新しいオプショングループを作成するか、既存のオプショングループをコピーもしくは編集をしOracle UTL_MAILオプションを追加します。その後、このオプショングループをDBインスタンスの作成時か変更時に設定を行ないたいDBインスタンスへ適用します。現在、32KBまでの1つの添付ファイルとASCIIとEBCDIC文字コードのみをサポートしています。Amazon RDSではUTL_MAILをOracle version 12.1.0.2.v5 以上、12.1.0.1.v6以上、 11.2.0.4.v9以上でサポートしています。またこれらのバージョンはJuly 2016 Oracle Patch Set Updates (PSU)を含んでいます。

Amazon RDSはOracle社から提供されているbug fixを、四半期ごとに提供されるDatabase Patch Set Updates (PSU)にて適用しています。現在、Oracle July 2016 PSUがAmazon RDS for Oracleでご利用頂けます。AWS Management Console中の”Launch DB Instance Wizard”から所望のDBエンジンバージョンを選択肢、数クリックで新しいOracle “11.2.0.4.v9″、 “12.1.0.1.v6″と”12.1.0.2.v5″DBインスタンスを作成出来ます。既存のデータベースインスタンスをアップグレードする場合は、AWS Management Console中の”Modify”オプションを選択し、所望のデータベースエンジンバージョンを設定します。プロダクションデータベースインスタンスのアップグレードを行う前に、プロダクションデータベースのスナップショットからテスト用のDBインスタンスを起動し、アップグレード手順や時間のテストやアプリケーションのテストを行うことを推薦します。

Amazon RDS for OracleでUTL_Mailを利用する詳細な手順はドキュメントをご覧ください。また、RDSでのOracle PSUサポートに関してはこちらをご覧ください。

星野 (原文はこちら)

Amazon RDS for SQL Serverがローカルタイムゾーンをサポートしました

Amazon RDS SQL Serverでローカルタイムゾーンをサポートしました。アプリケーションでお使いのタイムゾーンをAmazon RDS for SQL Serverインスタンスに設定頂けます。

こちらの機能はDBインスタンスのタイムゾーンをご指定の物に設定します。RDS for SQL Serverを作成する際にタイムゾーンを変更する場合は、AWS Management ConsoleのSelect your Time Zoneドロップダウンメニューを利用します。インスタンス作成後はタイムゾーンを変更することが出来ません。このオプションを変更すると、OSレベルでのタイムゾーンの変更が行われ、全てのdateカラムと値に影響がある点ご注意ください。その為、タイムゾーンの変更による影響を事前に調査することを推薦します。ローカルタイムゾーンを設定したデータベースインスタンスを作成する前に、テストデータベースインスタンスで変更を検証することをお勧めします。

Amazon RDS for SQL Serverのローカルタイムゾーンサポートに関する更に詳細な情報は、ドキュメントをご覧ください。

星野 (原文はこちら)

Amazon RDS for PostgreSQL – 新マイナーバージョン、ロジカルレプリケーション、 DMSサポートなどを追加 –

Amazon Relational Database Service (RDS)は構築や運用管理、スケーリングなどを行うプロセスを簡単に行えるクラウド上のリレーショナルデータベースです。現在6つのデータベースエンジン(Amazon Aurora, Oracle, Microsoft SQL Server, PostgreSQL, MySQL,  MariaDB) をサポートしており、RDSはクラウド上で動作するアプリケーションの基本となるサービスとなりました。

2013年後半にPostgreSQLサポートを発表し、PostgreSQLの新バージョンや新機能を追加し続けてきました。

本日、Amazon RDS for PostgreSQLに以下の新機能を追加しました。

  • 新マイナーバージョン – 既存のRDS for PostgreSQLデータベースインスタンスは新しいマイナーバージョンにアップグレード可能です
  • ロジカルレプリケーション – RDS for PostgreSQLがロジカルレプリケーションに対応しました。
  • DMSサポート – ロジカルレプリケーション機能によりRDS for PostgreSQLデータベースインスタンスをAWS Database Migration Serviceのソースデータベースとして利用可能になりました
  • Event Trigger – 新しいバージョンのPostgreSQLでデータベースインスタンスレベルでevent triggerをサポートしました
  • RAM Disk Size – RDS for PostgreSQLでRAM diskのサイズをコントロール可能になりました

詳しくご紹介します

 

新マイナーバージョン

PostgreSQL バージョン9.3.14, 9.4.9,  9.5.4をサポートしました。これらのバージョンはリリースノートに記載されているように機能向上やbug fixが行われています。RDSコンソールAWS Command Line Interface (CLI)から今お使いのデータベースインスタンスをアップグレード可能です。9.5.2から9.5.4にコンソールを利用してアップグレードする例です:

rds_pg_mod_954

次回のMaintenance Windowまでアップグレードを行ないたくない場合はApply immediatelyにチェックが入っていないか確認をしてください。

command lineからアップグレードを行う例を以下に示します。(私のスキルが現役ということをお伝えするために、今回のポスト中でコマンドラインを利用した例を掲載しています)

$ aws rds modify-db-instance –region us-west-2 \
–db-instance-identifier “pg95” \
–engine-version “9.5.4” \
–apply-immediately

アップグレードの進捗を確認するには

$ aws rds describe-events –region us-west-2 \
–source-type db-instance –source-identifier “pg95” \
–duration 10 –output table

以下の例はインスタンスのアップグレードが完了した場合の出力です

||+-------------------------------------------------+||
 || Events ||
 |+--------------------+------------------------------+|
 || Date | 2016-09-13T00:07:54.547Z ||
 || Message | Database instance patched ||
 || SourceIdentifier | pg95 ||
 || SourceType | db-instance ||
 |+--------------------+------------------------------+|
 ||| EventCategories |||
 ||+-------------------------------------------------+||
 ||| maintenance |||
 ||+-------------------------------------------------+||

データベースインスタンス全体のイベントを監視している場合、RDSがパッチを適用する前後でバックアップを取得している事を確認出来ます。このバックアップはコンソールやコマンドライン経由で参照可能です。

$ aws rds describe-db-snapshots –region us-west-2 \
–db-instance-identifier “pg95” \
–snapshot-type automated –output table

出力は以下のようになります。

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 | DescribeDBSnapshots
 +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 || DBSnapshots
 |+------------------+-------------------+-----------------------+----------------------------+------------+-----------+----------------+---------------------------+-------+---------------------+-----------------+-----------------------+-
 || AllocatedStorage | AvailabilityZone | DBInstanceIdentifier | DBSnapshotIdentifier | Encrypted | Engine | EngineVersion | InstanceCreateTime | Iops | LicenseModel | MasterUsername | OptionGroupName |
 |+------------------+-------------------+-----------------------+----------------------------+------------+-----------+----------------+---------------------------+-------+---------------------+-----------------+-----------------------+-
 || 100 | us-west-2b | pg95 | rds:pg95-2016-09-12-23-22 | False | postgres | 9.5.2 | 2016-09-12T23:15:07.999Z | 1000 | postgresql-license | root | default:postgres-9-5 |
 || 100 | us-west-2b | pg95 | rds:pg95-2016-09-13-00-01 | False | postgres | 9.5.2 | 2016-09-12T23:15:07.999Z | 1000 | postgresql-license | root | default:postgres-9-5 |
 || 100 | us-west-2b | pg95 | rds:pg95-2016-09-13-00-07 | False | postgres | 9.5.4 | 2016-09-12T23:15:07.999Z | 1000 | postgresql-license | root | default:postgres-9-5 |
 |+------------------+-------------------+-----------------------+----------------------------+------------+-----------+----------------+---------------------------+-------+---------------------+-----------------+-----------------------+-

 

ロジカルレプリケーション

Amazon RDS for PostgreSQLがロジカルレプリケーションをサポートしました。これにより、Amazon RDS for PostgreSQLデータベースインスタンスからRDS外のcomplementary logical decoding機能をサポートしたデータベースへストリーミングレプリケーションを行うことが出来るようになります(PostgreSQLはbyte/blockベースのPhysical Streaming Replicationもサポートしています)。レプリケーションがlogical slotを経由して行われます。それぞれのslotは確実に1回だけ再実行される変更のストリームを含んでいます(詳細はPostgreSQLドキュメント中のLogical Decoding Slotsをご参照ください)。

RDS外のデータベースへロジカルレプリケーションを設定するために、PostgreSQL のユーザアカウントにrds_superuserrds_replicationロールが付与されているか確認してください。その他にも、設定するデータベースインスタンスに紐付けられているデータベースオプショングループ中のrds.logical_replicationパラメータを1に設定し再起動を行う必要があります。このパラメータが適用されると、幾つかのPostgreSQLのパラメータがレプリケーションを行うために設定が行われます。

roleとデータベースインスタンスの設定が行われると、logical slotの作成が可能になりRDS外のデータベース(もしくは他のクライアントから)からslot内のレコードを読み込んで処理出来るようになります。例えば、pg_recvlogicalコマンドでデータベースインスタンスに接続し、replication slotからストリームデータを読み込んでローカルファイルに出力出来ます。

さらに詳細は、 Amazon RDS for PostgreSQLユーザガイド内のLogical Replication for PostgreSQLを参照してください。

 

DMSサポート

AWS Database Migration ServiceはAWSへのデータベースマイグレーションをサポートするサービスです。ロジカルレプリケーションと一緒に使用する事によりPostgreSQLデータベース(RDSやご自身で管理されているデータベースなど)から他のオープンソースデータベースやコマーシャルデータベースへマイグレーションを行うことが可能になりました。マイグレーションを行うために先程説明したように事前に logical replication slotを設定する必要があります。

 

Event Triggers

新しいPostgreSQLバージョン (9.4.9+ and 9.5.4+)ではデータベースレベルでevent triggerをサポートしています。このトリガーは特定のテーブル外に存在するため、create, modify, delete tableといったDDLレベルイベントを広範囲にキャプチャー可能です(トリガーの全てのイベントのリストはこちらに掲載されています)。さらに詳細や実装のサンプルはユーザガイド内のEvent Triggers for PostgreSQLを参照してください。

 

RAM Disk Size

rds.pg_stat_ramdisk_sizeを使用してPostgreSQLのstats_temp_directoryで利用されるメモリ量をコントロール可能になりました。このディレクトリはパフォーマンス情報などの一時的な統計情報に利用されます。メモリを多く割り当てることでI/Oを軽減しパフォーマンスを向上出来ます。

 

Available Now

今までご紹介した新しいバージョンや新機能は本日からご利用頂けます。

Jeff; (翻訳は星野が担当しました。原文はこちら。)

Amazon Auroraにリーダーエンドポイントが追加されました – 負荷分散と高可用性向上 –

機能向上を行うたびにAmazon Auroraはパワフルかつ簡単にご利用頂けるようになってきました。ここ数ヶ月で、MySQLバックアップからAuroraクラスタを作成する機能や、クロスリージョンレプリケーションアカウント間でのスナップショットの共有フェイルオーバー順を指定可能になったり、他のクラウドやオンプレミス環境のデータベースからAuroraへ移行などを追加してきました。

本日、Auroraのリードレプリカの機能を向上する、クラスタレベルのリードエンドポイントを追加しました。皆様のアプリケーションは今まで通り特定のレプリカに対して直接クエリを実行することが可能です。しかし、今回追加したリードエンドポイントを利用するように変更することで、負荷分散や高可用性といった2つの大きな利点を得ることが出来ます。

Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間でコネクションのロードバランシングが可能になります。これは、リードワークロードを分散することで利用可能なレプリカ間でリソースを効率的に活用することができ、よりよりパフォーマンスを得ることが可能になります。フェイルオーバーの際には、もしアプリケーションが接続しているレプリカがプライマリインスタンスに昇格した場合コネクションは一旦クローズされます。その後、再接続を行うことでクラスタ内の他のレプリカにリードクエリを実行することが可能です。

Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが出来ます。Availability Zoneの可用性の問題が万が一発生した場合、リードエンドポイントを利用することで最小限のダウンタイムでリードトラフィックを他のレプリカに実行可能です。

 

Find the Endpoint

リーダーエンドポイントはAurora Consoleで確認可能です:

aurora_read_replica_endpoint

この便利な機能は本日からご利用可能です!

Jeff; (翻訳は星野が担当しました。原文はこちら)

Amazon Auroraアップデート – Parallel Read Ahead, Faster Indexing, NUMA Awareness

Amazon Aurora はAWSサービスの中で最も速く成長するサービスになりました!

リレーショナルデータベースをクラウドに適したデザインにすることで(Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!! の記事もご覧ください)、Aurora は大きなパフォーマンス改善や、64TBまでシームレスにスケールアップするストレージ、堅牢性・可用性の向上を実現しています。AuroraをMySQL互換にデザインすることによって、お客様は既存のアプリケーションの移行や新しいアプリケーションの構築を簡単に行って頂けています。

MySQL互換を保ちながら、そしてクラウドネイティブなAuroraアーキテクチャを活用することでAuroraには多くのイノベーションを加えられると考えています。

本日、3つのパフォーマンスを改善する新機能をAuroraに追加しました。それぞれの機能は、AWSをご利用の多くのお客様の一般的なワークロードでAuroraのパフォーマンスを改善するように設計されました。

 

Parallel Read Ahead – レンジ select、 フルテーブルスキャン、テーブル定義の変更やindex作成が最大5倍高速に

Faster Index Build – indexの作成時間が約75%短縮

NUMA-Aware Scheduling – 2つ以上のCPUが搭載されているデータベースインスタンスをご利用の場合、クエリキャッシュからの読み込みやバッファキャッシュからの読み込みが速くなり、全体的なスループットが最大10%向上

 

詳細をご紹介します

Parallel Read Ahead

MySQLで利用されているInnoDBストレージエンジンは行やindex keyを利用するストレージ(ディスクページ)を管理します。これはテーブルのシーケンシャルスキャンの高速化や新しく作成されたテーブルに効果的です。しかし、行が更新・作成や削除されるにつれて、ストレージがフラグメントされることによって、ページは物理的にシーケンシャルではなくなってきます。そして、スキャン性能が大きく低下します。InnoDBのLinear Read Ahead機能はページが実際に利用されるまでメモリ内で64ページまでまとめることでフラグメントに対処しています。しかし、エンタープライズスケールのワークロードでは、この機能は有効な性能向上にはなりません。

今日のアップデートでは、Auroraは多くの状況で賢くこのような状況を扱う機能をご提供します。Auroraがテーブルをスキャンする際に、論理的に判断し、並列で追加のページをプリフェッチします。この並列プリフェッチはAuroraのレプリケーションが行われているストレージ(3つアベイラビリティゾーンにそれぞれ2つずつのコピー)で優位性を発揮し、データベースキャッシュ中のページがスキャンオペレーションに関連しているかを判断するのに役立ちます。

結果として、レンジselect、フルテーブルスキャン、ALTER TABLE そして、index作成を以前のバージョンと比較して最大5倍高速に行えるようになりました。

Aurora 1.7(詳細はこの後の情報をご覧ください)にアップグレードすることで、すぐにこのパフォーマンス改善をご体験頂けます。

 

Faster Index Build

プライマリー、セカンダリーインデックスをテーブルに作成する時、ストレージエンジンは新しいキーを含んだ木構造を作成します。この処理は、多くのトップダウンのツリーサーチや、より多くのキーの増加に対応するためにツリーの再構築によりページ分割が伴います。

Auroraはボトムアップ戦略でツリーを構築します。リーフを最初に作成し、必要な親ページを追加していきます。この機能によりストレージ内の移動を軽減し、加えて各ページが一旦全て埋まるためページを分割する必要がなくなります。

この変更により、テーブルのスキーマによりますがindexの追加やテーブルの再構築が最大4倍高速になります。例として、Auroraチームが以下の様なスキーマでテーブルを作成し100億行を追加し5GBののテーブルを作製しました:

 

create table test01 (id int not null auto_increment primary key, i int, j int, k int);

そして4つのindexを追加しました

alter table test01 add index (i), add index (j), add index (k), add index comp_idx(i, j, k);

db.r3.largeインスタンスで、このクエリの実行時間が67分から25分になりました。db.r3.8xlargeでは、29分から11.5分に短縮されました。

これは新機能でプロダクション環境以外でのテストをお勧めします。利用するには、Aurora 1.7へアップグレードを行ない DB Instance Parameter group(詳細は DB Cluster and DB Instance Parametersをご覧ください)でaurora_lab_mode1に設定します。

rds_aurora_set_lab_mode

Auroraチームはこのパフォーマンス改善に対するみなさまからのフィードバックを楽しみにしています。お気軽にAmazon RDS Forumへ投稿をお願いします。

 

NUMA-Aware Scheduling

最も大きいデータベースインスタンス(db.r3.8xlarge) は2つのCPUを搭載しNUMA(Non-Uniform Memory Access)と呼ばれる機能を持っています。このタイプのシステムでは、メインメモリの各区画は各CPUに直接効率的にアクセス出来ます。残りのメモリは少し非効率なCPU間のアクセス経路を介してアクセスします。

Auroraはこの不均等なアクセス時間を活用するためにスケジューリングスレッドのjobを効率的に扱うことが可能になりました。スレッドは他のCPUに接続されている非効率なメモリへのアクセスを気にする必要がありません。結果として、クエリキャッシュやバッファキャッシュを大量に利用する様なCPUバウンドな操作で最大10%性能が向上しました。パフォーマンス向上は同じデータベースインスタンスに数百または数千接続を行っているときに顕著に発揮します。例として、Sysbench oltp.lua ベンチマークで570,000 reads/secondから625,000 reads/secondに向上しました。このテストではdb.r3.8xlarge DBインスタンスで以下のパラメータを利用して行いました。

  • oltp_table_count=25
  • oltp_table_size=10000
  • num-threads=1500

Aurora 1.7にアップグレードすることで、すぐにこのパフォーマンス改善をご体験頂けます。

 

Upgrading to Aurora 1.7

新しく作成されたDBインスタンスはAurora 1.7で自動的に起動します。既に起動しているDBインスタンスでは、update immediately か during your next maintenance windowを選択することでインストールが可能です。

以下のクエリでAurora 1.7で起動しているか確認出来ます。

mysql> show global variables like “aurora_version”;
+—————-+——-+
| Variable_name | Value |
+—————-+——-+
| aurora_version | 1.7 |
+—————-+——-+

Jeff (翻訳は星野が担当しました。原文はこちら)

 

新発表 – Redshift や QuickSight で AWS のコストや使用状況レポートのアップロードが可能に

以前より、AWS の多くのお客様からプログラムを使用してコストや使用状況レポートを分析する方法をリクエスト頂いていました (詳しくは New – AWS Cost and Usage Reports for Comprehensive and Customizable Reporting をご覧ください)。リクエストをお寄せくださったお客様は、いくつものリージョンにわたり AWS を使用して複数のビジネスを行い、幅広く様々なサービスをご利用されている傾向があります。AWS では請求レポートやコストに関する詳細情報をご提供しているため、これはビッグデータに関与する問題であり、AWS サービスを使用すれば簡単に解決することができます。今月初旬に私が休暇を取っていた間に、AWS はコストや使用状況レポートを Amazon RedshiftAmazon QuickSight にアップロードできる新機能をリリースしました。今回はその新機能についてご説明します。

Redshift にアップロード
まず、新しい Redshift クラスターを作成してみました (すでに実行しているクラスターがある場合は新たに作成する必要はありません)。私が作成したクラスターは次の通りです。

次に請求レポート機能が有効になっていることを確認しました。

そしてコストと請求レポートに行き、Create report をクリックしました。

次にレポート名を指定 (MyReportRedshift) し、時間制に設定してから Redshift と QuickSight 両方のサポートを有効にしました。

最後に配信オプションを選択しました。

次のページでレポートを作成することを確認し、Review and Complete をクリックしました。レポートが作成され、最初のレポートは 24 時間以内にバケットに届くという通知が届きました。

待機している間に PostgreSQL を EC2 インスタンス (sudo yum install postgresql94) にインストールし、 Amazon QuickSight プレビューで登録済みであることを確認しました。また、Create an IAM Role の指示に従って、読み取り専用の IAM ロールを作成しその ARN もキャプチャしました。

Redshift コンソールでは、Manage IAM Roles をクリックし ARN を自分の Redshift クラスターと関連付けました。

翌日、予定通りにバケットにファイルが到着したことを確認してから、Redshift にアクセスできるようにヘルパーファイルを取得するためコンソールにアクセスしました。

Redshift ファイルをクリックし、SQL コマンドをコピーしました。

ARN と S3 リージョン名を SQL に挿入しました(予想通りにクエリが作動するようにするため、リージョン名に引用符を使用する必要がありました)。

次に psql を使用して Redshift に接続しました (任意のビジュアルまたは CLI ベースの SQL クライアントの使用が可能)。

$ psql -h jbcluster.XYZ.us-east-1.redshift.amazonaws.com \
  -U root -p 5439 -d dev

SQL コマンドを実行しました。これで 1 組のテーブルが作成され、S3 から請求データをインポートしました。

Redshift でのデータのクエリ
手始めに同僚が提供してくれたいくつかのクエリを使用して、今月の S3 使用量を計算してみました。

AZ ベースのコストを見てみました。

次に AZ ごと、サービス別に見てみました。

試しに Redshift コンソールも少し調べてみました。すると、私のクエリをすべて見ることができました。

QuickSight のデータ分析
Amazon QuickSight を使ってコストや請求データも分析してみました。ログインしてから Connect to another data source or upload a file をクリックしました。

次に S3 バケットにアクセスし (jbarr-bcm) マニフェストファイルの URL をキャプチャ (MyReportRedshift-RedshiftManifest.json) しました。

データソースとして S3 を選択し URL を入力しました。

QuickSight は数秒内でデータをインポートし、新しいデータソースが利用可能になりました。SPICE (QuickSight のインメモリ計算エンジン) にロードしました。3 回から 4 回のクリックで AZ には関係のないデータを除外し AZ 特有のデータだけに集中することができました。

もう一度クリックして円グラフの表示に切り替えました。

サービス別のコストも調べてみました。

ご覧のように、新しいデータと QuickSight の解析能力により、数分で AWS のコスト詳細を確認することができました。

今すぐ利用可能
この機能は今すぐ使い始めることができます。

Jeff;