Amazon Web Services ブログ

Category: Database

Amazon RDS for PostgreSQLで PostgreSQL 9.5(9.5.2)とバージョン9.4.7、9.3.12サポート

本日より、Amazon RDS for PostgreSQLでバージョン9.5のサポートを開始しました。このバージョンではUPSERTやRow Level Security (RLS)、Big Data capabilitiesなど多くの新機能を含んでいます。また、新しいメジャーバージョンに加えて、多くの機能向上やfixを含んだ9.4.7や9.3.12といった新しいマイナーバージョンもサポートしました。。 PostgreSQL 9.5 (マイナーバージョンは9.5.2) は以下の様な新機能を含んでいます: UPSERT: “INSERT, ON CONFLICT UPDATE”を簡単に実行可能です。この機能では行へのINSERTやUPDATEを同時に扱う事が可能で、同時に実行されるデータの衝突を扱うことが可能になり、アプリケーションの開発もシンプルに行えます Row Level Security (RLS): RLSは行や列レベルでデータへのアクセスコントロールを行うことが可能になります。この機能により、セキュアに扱わなければならないデータのコントロールを厳格に行なえます Big Data features: PostgreSQL 9.5はBig Dataシステムと連携出来る多くの新機能を含んでいます。例として、BRIN Indexingは小さいながらも効果的なインデクシングを “naturally ordered”テーブルに行えます。”abbreviated keys”アルゴリズムを用いたfaster sortsはtextやNUMERICフィールドのソートを高速に行います。CUBE, ROLLUP や GROUPING SETSはTableauなどのOLAPツールと連携して複数のレベルのサマリーを用いたレポートを可能にします。IMPORT FOREIGN SCHEMAやJOINプッシュダウンを用いたForeign Data Wrappers (FDWs) は外部データベースとのクエリの連携を簡単・効率的に行うことが出来ます。TABLESAMPLEは高コストのソートを避け、大規模テーブルの統計的サンプルを生成可能です。 PostgreSQL 9.5.2データベースインスタンスは、AWS Management Consoleから数クリックで起動可能です(ドキュメント)。また、既に起動しているPostgreSQL 9.4インスタンスから、バージョン9.5.2へメジャーバージョンアップグレードも可能です。もし、バージョン9.3から9.5へアップグレードを行う場合は、point-and-clickアップグレードを2回行う必要があります。それぞれのアップグレード操作中はデータベースインスタンスに短い時間ですが、接続できなくなります。データベースのアップグレードの詳細はこちらをご覧ください。 PostgreSQL 9.5.2に加えて、PostgreSQL 9.4.7 と 9.3.12のサポートも開始しました。これらのバージョンには、こちらのリストにあるようないくつかの修正や機能向上が含まれています。3つの新バージョンについての詳細は、それぞれのバージョンのリリースノートをご覧ください。 Release Notes for […]

Read More

Redshiftアップデート:COPYやUNLOADでIAMロールを指定可能に

Amazon Redshiftにデータを読み込む際(COPY)やエクスポートする際(UNLOAD)、その読み書き先(S3)に対してのアクセスを実現するため、これまではCOPYやUNLOADコマンドの引数にIAMのキー情報(アクセスクリデンシャル)を付与する必要がありました。 これが拡張され、Redshiftクラスターに対してIAMロールを付与して、その付与したロールでCOPY、UNLOADができるようになりました。以下がリリースノートの翻訳です。 1つ、もしくは複数のAWS Identity and Access Management (IAM)ロールをRedshiftクラスターにアサインし、データロードやエクスポート時に使用することが可能になりました。Redshiftクラスターはデータロード時(COPYコマンド)やエクスポート時(UNLOADコマンド)に指定されたIAMロールを使用し、結果としてRedshiftから各種AWSサービス(S3等)への操作時に確実にクリデンシャルを利用することになります。IAMロールを使うことで、SQLにAWSアクセスクリデンシャルを埋め込む必要がなくなり、クラスターのセキュリティを向上し、データのロードやエクスポートをシンプルにします。 Redshiftクラスターは長い時間の(COPYやLOAD)オペレーション時には、定期的にIAMロールを再アシューム(Re-assume)します。つまり、暗号化キーを使ったCOPY、UNLOADする場合においてもコマンドは変更されていません。   リリースノート(原文):https://aws.amazon.com/about-aws/whats-new/2016/03/amazon-redshift-now-supports-using-iam-roles-with-copy-and-unload-commands/ 翻訳:下佐粉 昭(@simosako)

Read More

ElastiCache for Redis の更新 – エンジンのアップグレードとスケールアップ

Amazon ElastiCache は、クラウド内のインメモリデータベースのデプロイ、運用、スケールの実行を簡単にするサービスです。ご存知のとおり、ElastiCache では Memcached エンジンと Redis エンジンがサポートされています。 Redis 向けの強化 本日、Redis ベースの ElastiCache クラスターがより詳細に制御できるようになる、ElastiCache の更新をローンチしました。You can now scale up to a larger node type while 保存された情報を ElastiCache に保持したまま (ベストエフォートベース)、より大きなノードタイプにスケールアップできるようになりました。ElastiCache for Redis のエンジンバージョンのアップグレードはこれまでずっと可能でしたが、保存された情報を保ったままでこれを実行できるようになりました。これらの変更は、両方とも、即時適用またはクラスターのメンテナンス期間の適用が実行できます。 ElastiCache for Redis のスケールアップとエンジンアップグレードのために、見えないところでさまざまな戦略が活用されています。スケーリングは Redis レプリケーションをベースにしています。エンジンのアップグレードでは、マルチ AZ がオフになったときにまずフォアグラウンドのスナップショットが使用され (SAVE)、マルチ AZ がオンのときにレプリケーションに続いて DNS スイッチが実行されます。 大きなノードタイプにスケールアップするには、AWS マネジメントコンソールで [Cache Cluster] を選択し、[Modify] をクリックします。新しい [Node Type] を選択し、変更を即時適用するかどうかを決定してから、[Modify] をクリックします。 […]

Read More

Amazon RDS for SQL Server – Windows認証のサポート

このブログの常連読者の方は私がAmazon Relational Database Service (RDS)の大ファンであることをご存じだと思います。マネージド型のデータベースサービスとして、リレーショナルデータベースのセットアップ、実行、そしてスケーリングといった日常業務の面倒を見てくれます。 2012年にはじめてSQL Serverのサポートをローンチしました。それからSSLサポート、メジャーバージョンアップグレード、透過的なデータ暗号化、そしてMulti-AZといった多くの機能を追加してきました。これらの機能はRDS for SQL Serverの適用範囲を広げてより多くのユースケースへの扉を開きました。 多くの組織ではアカウントのクレデンシャルとそれに関連するアクセス権をActive Directoryに保管しています。ディレクトリによりこの情報に対する単一で一貫性のあるソースを提供し集中管理を可能にします。AWS Directory Serviceを使用してAWSクラウド上でMicrosoft Active DirectoryのEnterprise Editionを実行することができますので、次のステップにすすむときです! Windows認証のサポートAWS Directory Service for Microsoft Active Directory (Enterprise Edition)に保存されたクレデンシャルを使用してAmazon RDS for SQL Serverに対するアプリケーションの認証ができるようになりました。同じディレクトリにすべてのクレデンシャルを保持することでそれぞれのコピーをさがして更新する必要がなくなるため時間と手間の節約になります。 SQL Serverを実行するデータベースインスタンスを新規に作成するときにこの機能を有効にしてActive Directoryを選択することができます。既存のデータベースに対して有効にすることもできます。こちらが新規にデータベースインスタンスを作成するときにディレクトリを選択するやり方です(新規にディレクトリを作成することもできます): より詳細は、Using Microsoft SQL Server Windows Authentication with a SQL Server DB Instanceを読んでください。 いますぐ利用可能この機能はUS East(北バージニア)、US West (オレゴン)、Europe(アイルランド)、Asia Pacific(シドニー)、Asia Pacific(東京)、そしてAsia Pacific(シンガポール)リージョンでいますぐ利用可能ですので今日からつかいはじめることができます。この機能に追加費用はありませんが、AWS Directory Service for […]

Read More

Redshiftアップデート:COPYやVACUUMの機能向上、クラスターリサイズの速度向上等

Redshiftの新しいバージョン1.0.1040リリースについて、その新機能や修正一覧の説明とメンテナンスの予告が公開されています。 Release: Amazon Redshift on 2016-03-17 Announcement: Amazon Redshift improvements and maintenance (Mar 17 – Mar 31) このリリースには以下の新機能が含まれています。 ユーザが定義したしきい値よりも大きい比率でソート済の表は、VACUUMでソートをスキップするように COPYで条件にそったデータを挿入した場合、ソート済の領域としてマージされるように 接続ログに、SSLのバージョンとSSLサイファーが記録されるように 1.はVACUUMコマンドの機能改善です。VACUUMは不要領域の削除とソートという2つの機能を持っているのですが、すでに大半の領域がソート済の場合はソート処理自体をスキップすることでVACUUMに掛かる時間を短縮します。 デフォルトではその閾値は95%に設定されていますが、これはユーザが指定することが可能です。VACUUMコマンドが拡張されTO sort_threshold PERCENTという形で指定できます。この数値を100にした場合は(今までと同様)常にソートが実行されるようになりますし、逆に0にするとソートが行われなくなります。この新しいオプションはREINDEXやDELETE ONLY等とも併用可能です。 参考)VACUUMコマンド ※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。 2. ですが、Redshiftの中では表のデータは「ソート済領域」と「非ソート済領域」に分けて管理されています。VACUUMを使ってソートされたデータはソート済領域に保存され、追加データは非ソート領域に保存されます。 今回の機能拡張では、条件を満たした場合にCOPYで追加したデータがソート済領域に追加されるようになります。その条件はマニュアルの以下のページに記載されています。 Loading Your Data in Sort Key Order ※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。  条件は以下の通りで、これらを全て満たしている必要があります。 表がコンパウンドソートキー(Interleaved Sort Keyではなく)を使っていて、かつソートキー列が1つのみ ソートキーの列がNOT NULL 表が100%ソート済か、もしくは空(から) 新しく追加されるソートキー列の値が既存データよりソート順で大きい値を持つ これは、列に常に大きい値が挿入されるようなケース、つまり時刻がソートキーになっていて、そこに追加で新しいデータを追加し続けるような表構造(時系列でデータを入れ続ける)の場合に役に立ちます。 3.は記述のままですね。STL_ CONNECTION_LOGにsslversionとsslcipherという列が追加されています。もしこのSTL表を定期的に別表やファイルにエクスポートしている場合は、クラスターバージョンが上がった途端に列が増えるのでご注意ください。 この他に、INリスト指定時にスキャン範囲を限定することで速度を向上させる機能や、クラスターリサイズ時の転送スループット向上(リサイズに掛かる時間の短縮)、Window関数利用時にORDER BY句が必須ではなくなるといった機能向上、およびバグの修正が行われています。 この新しいバージョンはこれから約2週間にかけて各リージョンにデプロイされます。適用されるとクラスターのバージョンが1.0.1040になっているはずです。 なお、すでにオレゴンリージョン(US-WEST-2)にはデプロイされていますので、新規にオレゴンでRedshiftクラスターを立ち上げると1.0.1040で起動できます。すぐに新機能を確認したい方はオレゴンで試してみてください。 下佐粉 昭(@simosako)

Read More

AWS Database Migration Service (DMS)が一般公開に!利用可能リージョンも拡大

みなさんは、現在リレーショナルデータをオンプレミスのOracle, SQL Server, MySQL, MariaDB, PostgreSQLといったデータベースに保存されていますか?それらのデータをAWSクラウドに実質的なダウンタイム無しで移動させ、スケールアウト可能というメリット、効率化されたオペレーション、複数のデータストレージが用意されている環境に移行する事に興味はありませんか? もしそうであれば、新しい AWS Database Migration Service (DMS) こそ、みなさんのためのサービスです!去年の秋に開催されたAWS re:Inventで最初の発表がなされ、すでにお客様により1,000を超えるオンプレミスのデータベースがAWSに移行されています。お客様はテラバイト級のデータベースを動かしたままクラウドに移行する事が可能になります。データベースプラットフォームを変えずに移行することも可能ですし、要件により適切な別のデータベースプラットフォームに移行することも可能です。新しいデータベースプラットフォームへの移行を、システム全体のクラウド移行とともに実施する場合は、AWS Schema Conversion Tool がみなさんのスキーマやストアドプロシージャを新しいプラットフォーム用に変換する事をお手伝いします。 AWS Database Migration ServiceはレプリケーションインスタンスをAWS上にセットアップすることで稼動を開始します。このインスタンスはソースデータベースからデータをアンロードし、ターゲットのデータベースにロードします。これは”on-going replicaion”をサポートしており、ダウンタイムを最小にする形でのマイグレーションをサポートします。加えて、DMSは、データ型変換や異機種間データ移動(例:OracleからAurora)といった多くの煩雑な処理を代行してくれます。このサービスはレプリケーションの状況やインスタンスをモニターしており、なにか発生した場合はユーザに通知するとともに、自動的に代替となるインスタンスをプロビジョンします。 DMSは多様なマイグレーションシナリオおよびネットワーク接続のオプションをサポートしています。1つのエンドポイント(※ソースもしくはターゲットのデータベースサーバ)はAWS上にある必要がありますが、他はオンプレミスでも、EC2上のデータベースでもRDSでもかまいません。ソースとターゲットは両方が同じVirtual Private Cloud (VPC)上にあっても良いですし、別々のVPC上でもかまいません(AWS上で稼動するデータベースを別のVPC上に移すようなケース)。オンプレミスのデータベースに対してもパブリックインターネット経由で接続するか(インターネットVPNを使うことも可能です)、AWS Direct Connectで接続することが可能です。 データベースをマイグレーションする 数クリックでマイグレーションをセットアップすることが可能です!ターゲットデータベースを作成して、データベーススキーマを移行し、データレプリケーションプロセスをセットアップし、最後にマイグレーションを実行するだけです。ターゲットデータベースがソースの内容に完全にキャッチアップできたら、あとは本番環境から利用するデータベースを切り替えるだけです。 AWS Database Migration Service コンソールを選択して、”Create Migration“をクリックします。(AWS Migration Serviceコンソールは、AWSマネジメントコンソールのデータベースのセクションに「DMS」と書かれたアイコンで表示されています)   コンソールにはマイグレーションプロセスのオーバービューが表示されています: Nextをクリックして、レプリケーションインスタンス作成に必要なパラメータを入力します: このブログポストでは、既存のVPCを選択し、”Publicly accessible”のチェックを外しています。同僚の社員が、私のためにEC2上に”オンプレミスDB”役のデータベースをセットアップしてくれているからです(訳注:オンプレミスのサーバと、VPNやDirect Connectを使わずにグローバルIP経由で接続するような場合は、ここでPublic accessibleをオンにする必要があります): レプリケーションインスタンスが作成されると、ソース、ターゲットの両データベースのエンドポイントを指定し、”Run test“をクリックしてエンドポイントに問題なくアクセスできるかを確認します。(正直に告白すると、テストをパスするために自分のセキュリティグループ設定を何度か修正するることで時間を費やしました) そしてマイグレーションタスクを作成します。Migration typeのところで、”migrate existing data(既存データの一括ロード)”,”migrate and then replicate(一括コピーをした後に、継続的に差分レプリケーション)”,”replicate […]

Read More

Amazon Auroraのリードレプリカで、フェイルオーバーの順番を指定可能になりました

本日、Amazon Auroraクラスタ中のレプリカノードを昇格させる順番をご指定頂けるようになりました。この機能により、フェイルオーバ発生時のレプリカノードの昇格を扱いやすくなりました。マスターインスタンスに障害などが発生した場合、Amazon RDSは優先順位が高いレプリカノードを昇格させます。低い優先順位を指定することで昇格させたくないレプリカインスタンスをご指定頂けます。例えば、バッチや集計用途などでご利用頂いているレプリカノードに対して低い優先順位を指定することで、昇格を防ぎバッチや集計作業の影響をアプリケーションに与えることを防ぐことも可能です。 フェイルオーバの優先順位は 指定した優先度 優先度が同じレプリカが複数ある場合は、フェイルオーバ発生時のマスターインスタンスよりインスタンスサイズの大きいインスタンス 優先順位もインスタンスサイズも同じ場合は、同じ優先順位のレプリカノードから任意のレプリカノードが選択されます さらに詳細なフェイルオーバのロジックや優先順位についてはAmazon Auroraユーザガイドをご覧ください。Amazon Auroraについてはプロダクト紹介ページをご覧ください。 — 星野 (原文はこちら)

Read More