Auroraの最近のアップデートを振り返ってみたいと思います。AuroraはMySQL互換のハイパフォーマンスなデータベースです(間もなくPostgreSQL互換のAuroraもリリース予定です)。RDSに費用対効果の高いMySQL互換のデータベースが登場!!をご覧ください。Auroraのスナップショット(自動・手動取得に関わらず)リージョン間でコピー出来るようになりました。Snapshotを選択します。その後、リージョンを選択後、新しいスナップショットの名前を入力します。この操作の中で、暗号化済みスナップショットも選択可能です。詳細はドキュメントをご覧ください。DBを作成する際に暗号化オプションを設定出可能です。数クリックで他のリージョンにリードレプリカを作成することが出来るようになりました。この機能を利用することで、マルチリージョン、ハイアベイラビリティなシステムが構築可能になりますし、ユーザに近い位置にデータを移動することも可能です。Replicaを選択するだけです。Securityからリージョンを選択し、Createをクリックします。Groupが必要です。このパワフルな新機能について詳細は、ドキュメントをご覧ください。DBインスタンスを作成する際に、定期的に自動でスナップショットを行う設定が可能です。この他にも、数クリックで任意のタイミングでスナップショットを作成することも可能です。DBインスタンスが暗号化されている場合はスナップショットも暗号化されます。AWS間で暗号化されたスナップショットを共有出来るようになりました。keyではないマスターキーで暗号化されている必要があります。Snapshotを選択します。サポートを2017年7月19日に終了致します。RDSで2014年10月から2015年6月にかけてサポートされました。新機能やセキュリティ・安定性向上を含んだバージョンに更新されてきました。5.6.34)にアップグレードを行うことを推奨致します。メジャーバージョンアップグレードと異なり、マイナーバージョンアップグレードはそれ以前データベースエンジンのマイナーバージョンと後方互換性を持っています。UpgradeがYesに設定されているDBインスタンスに対して、自動アップグレードを設定致します。アップグレードはこの日以降の通常のメンテナンスウインドウ内で順次実施されます。Upgradeの設定に関わらず自動的に最新のマイナーバージョンに、各インスタンスに設定されているにメンテナンスウインドウ内でアップグレードが行われます。MySQLインスタンスは、メンテナンスウインドウに関わらず即座にアップグレードが実施されます。RDSでのMySQLのマイナーバージョンアップグレードについては、こちらをご覧ください。サポートチームへコミュニティフォーラムかサポートセンター経由でご連絡下さい。今回のアップグレードは、2017年4月5日到来前にアップグレード対象バージョン以上のマイナーバージョンもしくは、メジャーバージョンにアップグレードして頂くことで回避可能です。そのため、テスト環境などでテストを行っていただき、自動適用が開始される前に手動でアップグレードすることをお勧め致します。原文はこちらをご覧ください。Auroraの新機能を2つリリース致しました。暗号化済みのデータベースでAWSリージョンをまたいだレプリケーションがサポートされました。クロスリージョンレプリケーションを利用することで、ユーザに近い場所でリードオペレーションを実行することが可能になったり、ディザスターリカバリー環境を簡単に構築出来ます。リージョンをまたいだデータベースの移行も容易に行なえます。暗号化されたスナップショットをAWSリージョン間でコピー可能になりました。開発チームとテストチームが様々な地域に分散していたとしても、本番データベースの最新のコピーを安全に共有することによって、グローバルな開発プロセスを構築できます。遠隔地にスナップショットを安全に保管することで、ディザスターリカバリー戦略を強化することも可能です。詳細は、クロスリージョンレプリケーションとクロスリージョンスナップショットコピーのドキュメントをご覧ください。AWSアカウント間で暗号化済みスナップショットの共有が可能になりました。暗号化キーを共有しているアカウントを分離するためにAuroraのセキュリティモデルを拡張出来ます。他のアカウントの所有者は、スナップショットをコピーしたり、スナップショットからデータベースインスタンスを復元することができます。詳細なドキュメントはこちらをご覧ください。Auroraは、フルマネージド、高可用性、コストパフォーマンスのよいリレーショナルデータベースです。MySQLと互換性があるためアプリケーションコードの変更なしに移行が行なえます。こちらのツールを利用することでダウンタイムを最小限に移行を行うことも可能です。翻訳は星野が担当しました。件のブログを公開しましたが、取り上げることができなかった紹介に値するリリースはいくつもありました。年に進歩を遂げたすべてのポイントに関する総集編をお届けします。つの主なエリアに注目しました。これらのエリアを見ていきましょう。リレーショナルデータベースは様々なタイプのアプリケーションにおいて、その中心にあります。配置を選択すれば、複数のインスタンス設定、レプリケーションのアレンジ、ネットワーク、インスタンス、ネットワーク問題などの検出に使うスクリプトを書いたり、フェイルオーバーの決断や新しいセカンダリインスタンスをオンラインにするために、何週間にもわたりセットアップにかける時間を省くことができます。クロスリージョンリードレプリカを作成しやすくします。年に行ったその他の機能強化については次のブログをご覧ください。Shareリレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。4つのシャードを持っているとすると、4つのデータベースを管理する必要があります。してもスケールアウトはスケールアップよりコスト効率がいい場面が多かったのです。RDSの様なマネージドデータベースの登場によりリレーショナルデータベースの管理を軽減することが出来るようになったのがその1つの要因です。Auroraの登場によりスケールアップという選択肢が戻ってきたのです。Auroraは非常にスケールし、MySQL互換のマネージドデータベースサービスです。GiBメモリ搭載のインスタンスまでを提供しています。TBまで自動的に増加します。将来のリードキャパシティの増加に備えて15インスタンスまで低遅延のリードレプリカを3つのアベイラビリティーゾーンに配置することが可能です。この構成の優れている点は、ストレージがリードレプリカ間でシャーディングされている点です。シャーディングされたシステムを1つのAuroraインスタンスに集約、もしくは少数のシャードに集約しAuroraで稼働させることで多くのコストを節約する事が可能です。これがこのブログポストでお話したいことの全てです。多くのシャーディングされたシステムは標準的な方法で行うことが可能です。データはカスタマーIDなどの特定のキーを元に分割されており、何かしらマッピングを行う機能を用いてシャードに分割されています。この方法には様々な種類があり、1例として参照用のデータを別のシステムか1つのシャードに格納したり、全てのシャードに参照用のデータを配置するなどがあります。どのようにデータを分割しても、シャーディングの複雑さは通常、アプリケーションレイヤーにあり、シャードの統合は比較的容易に行えます。皆さんは今、”利点はわかった。やってAuroraにデータを移行するのか”という疑問をお持ちかと思います。今回の例では、MySQLを利用して4つのシャードを持つシステムを利用していると仮定したいと思います。各シャードは他のシャードが持っているデータを持っていないものとします。1つのシャードが参照用のデータを持っている前提とします。現在の構成は以下の図の様な構成になっていると思います。mapは各シャードへのアプリケーショントラフィックを表しています。documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。どのシャードを最初に移行するかはそれほど重要ではありません。移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。この時点で、Auroraが特定のワークロードをどれくらいうまく処理しているか評価し、必要な調整を行う必要があります。設定に問題がなくなれば、他のデータを移行する準備は完了です。シャード2をAuroraインスタンスに移行しましょう。DMSはこのようなマイグレーションにも対応するように作られました。シャード2からAuroraインスタンスへデータをコピーするためにDMSをご利用になれます。シャード2にとランアクションを実行しながらこれらの作業が可能です。DMSは初期データのロードが完了すると、それらのトランザクションデータをシャード2から収集しAuroraインスタンスに適用します。DMSは継続的にシャード2からAuroraインスタンスへデータを移行し、シャード2の代わりにAuroraインスタンスの利用を開始させるまで同期させます。シャード2からAuroraインスタンスへ切り替える準備が出来たら、シャード2へのトランザクションを停止し、DMSが最後のトランザクションをAuroraインスタンスへ適用するまで待ち、mapの設定を、シャード2に向いていたトラフィックを直接Auroraインスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました!しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。それでは、シャードがクリーンな状態でない場合を見ていきましょう。システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。結果は次のようになります。この図は状況が複雑であるように見えます。理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。シャードの統合を行う前に、利用していない行を削除することができます。マッピング関数がID値のハッシュ(一般的な方法の1つ)で構成されている場合、利用していない行を特定するのは難しいかもしれません。別のオプションがあるかもしれません。各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。Share24時間365日稼働しているアプリケーションが利用しているデータベースエンジンを他のデータベースエンジンに移行するにはいくつかの方法を使う必要があると思います。データベースをオフラインにせずに移行する良い方法として、レプリケーションを利用する方法があります。Replicaを作成して移行する機能をリリースしました。Replicaを作成します。レプリカのセットアップが完了後、ソースデータベースとのレプリケーションの設定を行い最新のデータをキャッチアップします。レプリケーションラグが0になればレプリケーションが完了した状態です。clusterに接続します。マイグレーションはテラバイトあたり数時間かかります。DBインスタンスに対応しています。InnoDBテーブルのレプリケーションはMyISAMテーブルのレプリケーションよりもやや高速で、圧縮されていないテーブルの利点も受けられます。Actionsを選択します。master”を監視します)。(翻訳は星野が担当しました。Auroraの新機能を発表しました。auditing機能が全てのお客様にご利用頂けるようになったことを発表致します。Auditingとは特定のイベントを収集して手動もしくは他のアプリケーションで分析出来るように提供する機能を指します。これらのログはコンプライアンス規定やガバナンスのベースになる情報として利用可能です。auditingの例には、ログ分析、ユーザーアクションの監査(過去のイベントおよび、ニアリアルタイムの脅威検出など)、セキュリティ関連のイベントに設定されたアラームのが含まれます。auditing機能は、データベースのパフォーマンスに与える影響を最小限に抑えながら、これらの機能を提供するように設計されています。auditingの有効化や設定を行うことができます。これらのパラメータの変更がDBクラスタの再起動は必要ありません。parametersと同様です。server_audit_loggingパラメータを利用します。server_audit_eventsパラメータでどのイベントをログに記録するか設定します。監査ログの有効/無効化を指定します。イベントのリストをカンマで区切って指定します。8:59:60になります)。これは地球上での時刻(協定世界時)と太陽時(天文時)とのずれを小さくするために行われ、この結果、UTCでは今年最後の1分は61秒あることになります。–うるう秒挿入前後の24時間の期間にわたって、うるう秒の1秒を少しずつ分散します(UTCで12月31日の11:59:59から、2017年1月1日12:00:00まで)。AWS調整時刻と協定世界時はこの期間が終了後に同期します。(訳注:この期間の1秒をごくわずかに遅くすることで、追加される1秒を長い時間のなかに分散する方法であり、これは前回うるう秒挿入時と同じ挙動です。詳しくは前回の情報をご確認ください。WindowsのAMIを利用しているインスタンスは、AWS調整時刻に従います。AWS調整時刻に従います。11.2.0.4と12.1.0.2について詳細な情報が必要な場合はAWSサポートにお問い合わせください。このうるう秒挿入についてご質問がある場合は、AWSサポートにコンタクトいただくか、EC2フォーラムにポストしてください。Auroraは現在もAWSサービスの中で最も速く成長しているサービスです!お客様には速度、パフォーマンスや可用性を評価頂いています。互換のエンジンをご覧ください)。re:Inventでアナウンスをした、空間インデックスとゼロダウンタイムパッチの2つの機能をリリースしました。Auroraは今までも地点やエリアを表すためにGEOMETRY型をご利用頂けました。queryを実行するためにお使い頂けました。これらのクエリはパワフルですが、大きなデータセットに対してスケールするには不十分な点や制限がありました。Auroraを利用して、ラージスケールな位置情報を使うアプリケーションを作成していただくために、空間データに対してとても効率的なインデックスをお使い頂けるようになりました。(次元的に整列した空間充填曲線)を利用して、スケールし、高速かつ正確に情報を取り出すことが出来ます。Diveのこちらの箇所をご覧ください)。Modeを有効にして頂く必要があります。indexを設定頂けます(詳細はこちらをご覧ください)。今日のような24×7の世界で、データベースへのパッチ適用やアップデートでデータベースをオフラインにする良い時間はありません。replicaを利用して昇格させる方法が利用されてきました。私達の、新しいゼロダウンタイムパッチ機能により、Auroraインスタンスへのパッチ適用をダウンタイム無しで、可用性にも影響を及ぼさずオンラインで実行出来るようになりました。この機能は、現在の最新バージョン(1.10)が適用されたAuroraインスタンスで、ベストエフォートで機能します。シングルノードクラスタとマルチノードクラスタのWriterインスタンス双方で機能しますが、バイナリログが有効になっている場合は無効になります。このパッチは、既に開かれているSSLコネクション、アクティブなロック、トランザクションの完了やテンポラリテーブルの削除を待ちます。パッチ適用可能なウインドウが出来た場合、ゼロダウンタイムパッチとして適用します。アプリケーションセッションは保持されたまま、パッチが適用される間データベースエンジンがリスタートします。この間瞬間的(5秒程度)なスループット低下が発生します。ゼロダウンタイムパッチで適用出来るウインドウがなかった場合、通常のパッチ適用プロセスが実行されます。videoのこちらの箇所をご覧ください。fixはこちらのforumをご覧ください。(翻訳は星野が担当しました。記事にて紹介しました。チームがリレーショナルデータベースモデルを既存の制約にとらわれない新鮮な視点で考え、クラウドに適したリレーショナルデータベースをいかに作ったかを説明しました。それ以来、私たちがお客様から受けたフィードバックは心温まるものでした。み込みの暗号化オプションを愛しています。までスケール可能なストレージを備えているという事実を頼りにしています。バックアップされるということをお客様は把握しています。個の低レイテンシーリードレプリカを追加できることを把握しています。コンピューティングリソースとストレージのリソースを効率的に使用し、商用データベースと比較して、費用対性能が10倍もよくなることを理解しました。お客様は常によりよいものを求め、我々もお客様の必要とするものを理解し、それを達成するために最善を尽くします。ここでは、お客様のフィードバックに応えてリリースした最近のいくつかのアップデートを振り返ります。機会均等法を順守しています。平等に採用しています。