Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

Amazon Aurora under the hood: Z-order curvesを用いたgeospatial indexの作成

Amazon Auroraのような高性能データベースシステムを設計する場合、一般的に最も幅広いワークロードを大きく改善出来るように取り組みたいと考えるかと思います。しかし時には、ゲームチェンジャーになりえる機会がある場合、特別な用途向けに改善を行うこともあります。 geospatial indexとはなにか、なぜ考慮する必要があるのか? 地理空間分析では、XY(Z)座標に沿った近さ、隣接性、重なりを識別することができます。 そのような分析を実行する必要があるアプリケーションには様々な例があります。タクシーアプリでは、利用可能な最寄りのタクシーを見つけることができます。不動産アプリは、サンフランシスコのPacific Heights地区で販売されている物件を探すことができます。 空間分析は、他にも多くの用途でも役立ちます: マーケティング – 店舗から2マイル以内のすべての見込み顧客をターゲットにプロモーションを行います 資産管理 – 顧客の位置と密度に基づいて影響を最小限に抑えるために修理ユニットを配置します リスク分析 – 顧客の居住地や職場の近くで車の盗難が発生した場合のリスクを見積もります 詐欺検出 – 前回のトランザクションからの距離に基づいて詐欺と考えられる取引の可能性を推定します ロジスティクス計画 – 運行の範囲を最小限にするように、トラブルのチケットを現場の技術者に割り当てます これらのアプリケーションは、高性能な空間データのインデックスから利益を得ることができます。残念なことに、Bツリーのような伝統的なインデックスは、Linlandのために作られたものであり、FlatlandやSpacelandではそうではありません。そのため、高性能な空間インデックスが必要です。 Rツリーとは? 最も一般的に使用される空間インデックスはRツリーです(詳細はこちらの論文を参照してください)。 MySQLとOracleはどちらもR-treeを使用しています。基本的な考え方は、バランスサーチツリーないにバウンダリーレクタングルを保存することです。リーフはデータポイントであり、各内部ノードは、その下のノードのミニマムバウンダリーレクタングルです。したがって、次の例では、長方形Aはリーフノードです。このノードは、矩形NおよびTによって順番に境界が作成されます。 Rツリーの主な問題は、安定していないことです(つまり、決定論的です)。挿入順序が異なると、異なるツリーが生成され、パフォーマンスの特性が大きく異なります。私たちのテストでは、ランダムな挿入順序では、最適な順序で構築されたツリーよりも1桁も性能が劣化したツリーが生成されました。これは、データの挿入順序が予測できず、変更可能なOLTP環境では明らかに問題になります。このような状況では、Rツリーは時間とともに性能が劣化します。1つの回避策は、データを定期的にインデックスを再構築することです。しかし、インデックスの再構築は負荷がかかります。加えて通常この作業は、手作業が必要であり、数時間かかることがあります。また、その期間中の他のトランザクションは遅くなる可能性があります。 そのため、Rツリーは人気がありますが、常に良好なパフォーマンスは得られません。 他にいい方法はあるのか? 私たちはそう考えています!トランザクションと同時実行に最適なデータ構造があります。それはBツリーです。 あらゆる場面で使用され、高いパフォーマンスを発揮するのはデータベースにとって基本です。 しかし、ちょっと待ってください。私はB-treeが多次元データに対してうまく機能しないと言いました。それは本当です。2次元を1次元にマップするトリックがあります。 私たちは、space-filling z-order curves(空間充填zオーダー曲線)を使用して行います。これは、ポイントのz値は、その座標値のバイナリ表現をインターリーブすることによって計算されます。zオーダー曲線は、これらの点をz値の順に横切る線です。たとえば、次の図は、0≤x≤7、0≤y≤7の整数座標の場合のz値を示しています(10進数と2進数の両方を示しています)。 zオーダー曲線上のBツリーの単純な実装では不十分です。なぜこれが当てはまるのかを知るために、以下の例を見てみましょう。緑色の四角形内のすべての点をBツリーで検索すると、クエリー領域外に30個の余分なz値(黄色い三角形の警告標識が付いている物)がスキャンされます。 元のクエリをより少ない偽陽性z値をカバーする小さなクエリに分割することで、この問題を改善します。(これを行うために幾つかの方法を使用していますが、それはこの記事でお伝えする範囲を超えています) それは私たちがポイントするために必要なものすべてを提示します。ポリゴンはどのように空間充填曲線で動作するのでしょうか?ポリゴンが単一点のように見えるまでズームアウトしたとします。どの程度ズームアウトしなければならないかは、ポリゴンの”レベル”によります。各空間オブジェクトは、オブジェクトのレベルとzアドレスの組み合わせとしてBツリーに格納されます。zアドレスがポイントのように見えるまでズームアウトしたので、zアドレスをポイントのように扱うことができます。他のシステムでは、このレベルを手動で指定する必要があります。明らかに、予測不可能で変更可能なデータを扱うOLTPシステムでは動作しません。このレベルはユーザーの設定なしで自動的に設定します。 Auroraのgeospatial indexesは、MySQL 5.7よりもselect-only(1秒当たりの読み込み回数)ワークロードで10倍以上、write-only(1秒当たりの書き込み回数)で20倍以上優れています。具体的には、サイズが1 GB未満のデータセットでSysbenchを使用して、AuroraとAmazon RDS for MySQL 5.7をdb.r3.8xlargeインスタンスを用いて計測しました。select-onlyのテストでは、2,000クライアントとST_EQUALSクエリを使用しました。write-onlyテストでは、4,000のクライアントを使用しました。 ご質問がある場合は、aurora-pm@amazon.comまでご連絡ください。 About the Author Sirish Chandrasekaran is a product […]

Read More

Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL リードレプリカを作成可能になりました

Amazon Aurora PostgreSQL リードレプリカ(2018/1/23現在英語版ドキュメントのみとなっています)を Amazon RDS for PostgreSQL のインスタンスとして作成し、継続的に Amazon Aurora PostgreSQL へレプリケーション出来るようになりました。これにより、実稼働ワークロードを Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL に移行する際、アプリケーションとユーザーを Amazon Aurora PostgreSQL へ移す準備ができるまで、インスタンスタイプを同期させておくことで、ダウンタイムを最小化させることが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。

Read More

暗号化されたスナップショットを Amazon Aurora PostgreSQL へ移行可能になりました

Amazon RDS for PostgreSQL の暗号化されたスナップショットから Amazon Aurora PostgreSQL へ移行できるようになりました。これにより、Amazon RDS から Amazon Aurora へ移行中の間も、データ暗号化を維持することが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。

Read More

AWS データセンターのセキュアな設計について

AWS は AWS のデータセンターのデジタルなツアーを公開しました。AWS が世界中で運用しているデータセンターをいかにセキュアに保護しているのか初めてお客様にご紹介するものです。このデジタルなツアー内のビデオ、写真および情報は、データセンターの設計、グローバルの統制および AWS のカルチャーがセキュリティの本質であることを解説しています。 このツアーにご参加いただくことで、AWS データセンターのセキュリティストラテジーが、お客様の情報を保護するためにスケーラブルな統制と複数の防御レイヤーによって成り立っていることを理解いただけます。例えば、AWS は潜在的な洪水や地震活動のリスクを慎重に統制しています。 AWS は境界防御レイヤー、保安要員、侵入検知システムおよびその他の電子システムを用いてデータセンターへのアクセスを制限しています。AWS はシステムのバックアップを実施し、定期的に装置やプロセスのテストを行い、継続的にAWSの従業員にトレーニングを行うことで予測不能な事態に備えています。 データセンターのセキュリティを検証するために、年間を通して、外部の監査人が2,600以上もの基準や要求事項に沿ったテストを行っています。そのような独立したテストが、セキュリティ基準が継続的に満たされている、もしくは基準を上回っている事を証明するために役立っていることになります。その結果、AWS は世界中の最も厳しい基準を有する監査機関からお客様のデータ保護に関して信頼を得ています。 データセンターのセキュアな設計の詳細についてはこちらのツアーにご参加ください。 – Chad Woolf, AWS Security Assurance (翻訳:AWS セキュリティ・アシュアランス本部 戸内加奈。原文はTake a Digital Tour of an AWS Data Center to See How AWS Secures Data Centers Around The World)

Read More

Microsoft Azure SQL Database から Amazon Aurora への移行

Oracle や Microsoft SQL Serverなどのライセンスが必要なエンジンから、AWS上で稼働するオープンソースエンジンへ移行する気運がますます高まっています。対象データの移行先として Amazon Aurora が選ばれています。この投稿では AWS Database Migration Service (AWS DMS) を用いた Microsoft Azure SQL database から Amazon Aurora MySQL クラスタへの移行方法を紹介します。 前提条件 この記事では、Azure SQLデータベースが既にインストールされていることを前提としています。移行には、このデータベースの接続情報(DNSエンドポイント、ユーザー名、パスワードなど)が必要です。また、移行作業に使用するユーザには、Azure SQLデータベースのデータにアクセスするための適切な権限が必要です。 記事の目的に合わせ、ターゲット(移行先データベース)として Amazon Aurora クラスタを作成します。 AWS DMSはソース(移行元データベース)およびターゲットとして、様々なデータベースエンジンをサポートしていますが、多くのお客様は独自のストレージエンジンを使用したAmazon Auroraを選択します。このエンジンは、3つのアベイラビリティゾーンに跨る耐久性、自動ポイントインタイムバックアップ、最大15台の低レイテンシ読み取りレプリカを実現します。 ターゲット用の Aurora クラスタを既に作成している場合は、新規に作成する必要はありません。新しい Aurora クラスタを作成する場合は、Amazon Aurora DB クラスタ作成の手順を参照してください。 AWS DMS インフラのセットアップ ここまででソースとターゲットの情報が確認できたので、AWS DMS インフラを設定していきましょう。 AWS DMSは非常に高い柔軟性をもつ為、多くのコンポーネントから構成されています。AWS CloudFormationを使用することで、これらのコンポーネントをまとめて単一の「スタック」にグループ化し、原子性を保った1つのユニットとして何度も再作成することができます。 AWS CloudFormation のコンソールを開いて設定を始めます。 […]

Read More

Amazon RDS for PostgreSQL が新しいマイナーバージョン 9.6.6, 9.5.10, 9.4.15, 9.3.20 をサポート

PostgreSQL コミュニティによるアップデートに追従し、PostgreSQL のマイナーバージョンである 9.6.6, 9.5.10, 9.4.15, 9.3.20 が Amazon RDS for PostgreSQL でサポートされました。このリリースでは、PostgreSQLの3つのセキュリティ上の脆弱性が修正され、追加のバグ修正と改善が行われています。 このアップデートでは、Oracle Database で利用される関数、パッケージの一部を実装した Extension “orafce” と、プレフィックスマッチングを提供する Extension “prefix” のサポートがバージョン 9.6.6 に含まれています。 マネジメントコンソールを使い数クリックで新たな RDS for PostgreSQL を作成するか、既存のインスタンスをワンクリックでアップグレードすることで、新しいバージョンを利用できます。アップグレードする場合、短いダウンタイムが発生することにご注意ください。データベースインスタンスをアップグレードするにあたっての詳細は、 Amazon RDS ユーザーガイドをご覧ください。 Amazon RDS for PostgreSQL は、クラウドで簡単に PostgreSQL を設定、運用、スケール可能です。それぞれのリージョンでご利用いただけるかどうかは、Amazon RDS for PostgreSQL の料金ページをご覧ください。 翻訳は江川が担当しました。原文はこちらです。

Read More

【開催報告】第11回 AWS Startup Tech Meetup

こんにちは、スタートアップ担当SAマネージャーの篠原英治(@shinodogg)です。 AWS Startup Tech CommunityはAWSをご利用中のStartup企業で働く技術者の皆さまにお集まりいただいているコミュニティですが、先日、11回目のMeetupをAmazon目黒オフィスで開催しました。カジュアルな雰囲気の中でも、ココでしか聞けないような実践的なやりとりが行われる非常に良い学びの場となりました。 – Voicyを支える技術 : Voicy 窪田 雄司さん Voicyを支える技術 from YujiKubota1 急成長中の注目スタートアップであるVoicyのCTO窪田さんに、Voicyで活用している技術をご紹介いただきました。 AWSのベーシックなサービスに加えて、Amazon CognitoやAmazon Mobile Analyticsといったマネージドサービスを適材適所でご利用いただいています。 – アルゴリズムマネジメント : scouty 伊藤 勝梧さん AI技術を活用しヘッドハンティングビジネスを展開しているscouty伊藤さんからは、研究とビジネスの違い、技術選定、そして、どこにどのアルゴリズムを用いるかのマネージメントについてお話いただきました。 お話は組織体制にまでおよび、講演後のディスカッションも活発な議論が行われました。 – Lightning Talks AWS FinTech リファレンス・アーキテクチャを作って出した話 ~Compliance as Code~ : AWS Japan 塚田 朗弘 先日、日本版のAWS FinTech リファレンス・アーキテクチャーを公開し、その作成に携わったStartup担当のSenior Solutions Architectの塚田から、改正銀行法成立にともなう今後の動向や、コンプライアンスに関連する要求事項への対応、そしてAWSのソリューションを活用したアーキテクチャ設計および構築についてご紹介しました。 AWS費用の事業部別コスト配分について : エネチェンジ川西智也さん AWSコストの事業部別コスト配分について from Tomoya Kawanishi エネチェンジの川西さんからは、各事業で共通のAWSアカウントを使用しているものの、コストは事業毎に算出したい、といった要件に対してどのように対応しているかご紹介いただきました。 AWS […]

Read More

Amazon RDS for MySQLとMariaDBのログをAmazon CloudWatchで監視出来るようになりました

Amazon RDSは、トラブルシューティングなどの目的にお使い頂けるように、DBインスタンスで生成されたログを表示およびダウンロードする機能を提供してきました。Amazon Relational Database Service(Amazon RDS) for MySQLとAmazon RDS for MariaDBでは、DBインスタンスのログイベントをAmazon CloudWatch Logsに直接保存出来るようになりました。これにより、AWSサービスを使用して、よりシームレスにDBインスタンスログを扱うことができます。 DBインスタンスログのニアリアルタイム分析 Amazon CloudWatch Logsを使用すると、アプリケーションの様々なコンポーネントからのログを集中的かつ永続的に保存できます。また、特定のフレーズ、値、パターン(メトリック)について、ニアリアルタイムでログを監視することもできます。さらに、設定した状態が発生したときに警告するアラームを設定することもできます。Amazon CloudWatchは他の様々なAWSサービスと統合することが可能です。これにより、以下のような幅広いユースケースでログを利用する価値を向上できます: 通常デジではありえない大量のスロークエリや接続の失敗など、異常な状態を検知するためのアラーム設定 他のアプリケーションログと関連させる セキュリティおよびコンプライアンスの目的でログを保持する ログデータの傾向を分析する 以下の図がアーキテクチャの概要です: ログエクスポートの概念 新しいログエクスポート機能は、MySQLおよびMariaDBの次のログタイプをサポートしています: Error log – 起動および停止にデータベースエンジンによって生成された診断メッセージが含まれています General query log – クライアントから受け取ったすべてのSQLステートメントのレコードと、クライアントの接続および切断時間を含みます Slow query log – 設定された時間よりも実行に時間かかったクエリや、定義された行数を超える行を走査したSQL文のレコードが含まれています。 両方の閾値は設定可能です Audit log – MariaDB Audit Pluginを使用して提供されるこのログは、監査目的でデータベースアクティビティを記録します これらのソースからのログイベントは、Amazon CloudWatchのロググループにログストリーム(ログイベントのシーケンス)の形式で保存されます。 各DBインスタンスとログの種類に応じて、DBインスタンスと同じAWS Region内に別のグループを次の命名パターンで作成します: /aws/rds/instance/<db-instance-id>/<log-type> ログデータは耐久性のあるCloudWatch Logsに保存され、透過的に暗号化されます。ただし、ログには機密情報が含まれている可能性があります。データを保護するために、アカウント内の適切なユーザーにアクセスを制限する必要があります。そのために、データベースログを含むロググループに対して適切なIAMアクセスポリシーを設定することが重要です。 Amazon RDSはDBインスタンスと同じアカウント内のロググループにservice-linked roleを使用してログを送信します。これにより、Amazon RDSはアカウント内の関連するロググループにアクセスできます。ログの送信を有効にすると、AWSServiceRoleForRDSという追加のIAMロールが表示されることがあります。 CloudWatch Logsへログの送信を有効にするには、以下のように設定を行います。 […]

Read More

AWS DMS と Amazon Kinesis Data Firehose を利用した Aurora PostgreSQL データベースへのストリームデータのロード

AWS Database Migration Service (AWS DMS) を利用することで、様々なデータソースから商用データベースやオープンソースデータベースへとデータを移行できます。このサービスでは、Oracle Database から Oracle Database への移行といった同一のDBMS製品間での移行をサポートしています。また、Oracle Database から Amazon Aurora, Microsoft SQL Server から MySQL へといった異なるプラットフォーム間での移行もサポートしています。さらに、ストリーミングデータを Amazon S3 から Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server を含む様々な移行先へ配信することが可能です。 Amazon Kinesis Data Firehose は、AWS へストリーミングデータをロードする上で、最も簡単な方法です。ストリーミングデータのキャプチャ、変換を行い、Amazon Kinesis Data Analytics, Amazon S3, Amazon Redshift, Amazon Elasticsearch Service へロードできます。Firehose を利用することで、すでに利用しているビジネスインテリジェンスツールやダッシュボードを使い、ニアリアルタイム分析が可能となります。Firehose はお客様が送信するデータのスループットに合わせて自動的にスケールするフルマネージドサービスで、継続した運用管理を必要としません。Firehose は、ロード前にデータをまとめ、圧縮し、暗号化することで、ロード先のストレージで必要な容量を最小化したり、セキュリティを向上させたりすることができます。 AWS DMS […]

Read More

SAP HANA Dynamic Tiering – AWSクラウド上で検証済み、およびサポート開始

この記事は、Amazon Web Services(AWS)でSAP Solutions Architectを務めるSomckit KhemmanivanhとRahul Kabraによるものです。 私たちは、パートナーであるSAP社と緊密に連携しており、AWSクラウド上でのSAP HANA Dynamic Tieringを検証してきました。AWSがSAP HANA Dynamic Tieringのプラットフォームとしてサポートされたことを発表でき、非常に嬉しく思います。SAP HANA Dynamic Tiering Product Managerを務めるCourtney Claussenの発表もご覧ください。ここでは、Dynamic TieringとAWS上での活用におけるメリットについて詳しく説明します。 SAP HANA Dynamic Tieringにより、SAP HANAデータベースは、Dynamic Tieringのサービス(esserver process)を稼働している別の専用ホスト上にウォームデータを格納できるようになります。Dynamic Tieringを使用すると、ウォームデータを格納して処理するためのマルチストアおよび拡張テーブルを作成できます。 Dynamic Tieringには以下の3つの大きなメリットがあります: 頻繁にアクセスされない古いデータを統合ディスク層にオフロードできます。 優れたパフォーマンスでディスク層のデータにアクセスできます。 SAP HANAシステムの総所有コスト(TCO)を大幅に削減します。 Courtney Claussenが、少し前にDynamic Tieringの非常に魅力的なユースケースについてのブログ記事を公開しています。電力・公益事業のお客様の請求処理の一環として、500万レコードが処理されました。これらのレコードは、SAP HANAだけで実行しているときには53分で処理できました。このベースラインが確立された後、500万レコードの25%をDynamic Tieringのマルチストアテーブルに移行しました。その結果、テーブル行の75%がSAP HANAに配置され、残り25%がDynamic Tieringに配置されます。請求処理を再度繰り返した結果、合計実行時間は58分、つまり実行時間はわずか10%の低下に留まっており、これは大幅な低コスト化をしつつ、ほぼ同等の性能を実現できることを意味します。 これらの驚くべき結果とお客様からのフィードバックが、SAP社と緊密に連携してAWSクラウド上のSAP HANA Dynamic Tieringを検証する動機になり、現在、AWSのお客様はこのサービスのパフォーマンス、コスト削減、および今後のイノベーションの恩恵を受けることができます。 AWSでは、認定されたSAP HANAシステム(244 GiB RAMから最大4 TiB RAMまでの範囲)を小規模から始め、要件の変更に応じて規模を拡大することができます。同様に、Dynamic Tieringでも、ニーズ、ワークロード、ユーザー、およびトラフィックパターンの変更に応じて、小規模から始めて容量を追加していくことができます。例えば、4 TiBのSAP HANAシステムを使用している場合、私たちが検証済みの488 […]

Read More