Author: AWS Japan Staff


Earth on AWS: AWS の地理空間データ

AWS のオープンデータチームのメンバーで私の同僚、Joe Flasher が新たな Earth on AWS プロジェクトについて説明するため、ゲスト投稿者としてブログを公開しました。

Jeff;


 

AWS は地球観測衛星のランドサット 8 号が撮影した画像を集めた公開データセット、Landsat on AWS を 2015 年 3 月にリリースしました。Landsat on AWS をリリースしてから 1 年以内に記録された Landsat データのリクエスト数は 10 億件を超え、AWS はユーザーによる革新的なデータの使用方法から様々なインスピレーションを得ています。Landsat on AWS はクラウド内でのデータ共有により、従来の IT インフラストラクチャによる帯域幅やストレージ、メモリや処理能力の制限なしに地球的規模のアプリケーションを構築することが可能になりました。

そして本日、AWS がリリースした Earth on AWS により、今後はクラウド内で大容量の地理空間データセットの利用が可能になったため、アルゴリズムをローカルマシンにダウンロードせずにアルゴリズムをデータに持ち込めるようになりました。Earth on AWS では誰でも自由にデータを使えるだけでなく、リソースを提供することでデータをどのように使用できるか説明する情報も提供しています。また、Earth on AWS データセットを利用した調査方法の 公開プロポーザル も受け付けています。

使用可能なデータを追加
現在、Earth on AWS には次のデータセットがあります。

NAIP 1m の画像
The National Agriculture Imagery Program (NAIP) は、米国本土を対象に作物成長時期の航空画像を撮影しています。約 1 メートルの航空画像 (赤、緑、青、NIR) を Amazon S3 で入手できるようになりました。詳しくは NAIP on AWS をご覧ください。

地形タイル
地形ベクトルタイルで世界中の標高データを使用できるようになりました。また、米国では 10 メートルの NED データが以前の NED 3 メートルと 30 メートル SRTM データを拡大するようになり、より鮮明に山脈の詳細情報を表示できるようになりました。Amazon S3 でタイルを使用できます。詳しくは地形タイルをご覧ください。

GDELT – A Global Database of Society
The GDELT Project は、世界中のほぼすべての国々から 100 か国以上の言語によるブロードキャスト、印刷物、ウェブニュースなどをモニタリングし、毎日秒刻みにグローバル社会に影響を与えている人物、場所、企業や団体、数値、テーマ、ソース、感情、件数、引用文、画像、イベントなどを特定しています。詳しくは GDELT をご覧ください。

ランドスタット 8 号の衛星画像
ランドスタット 8 号のデータは Amazon Simple Storage Service (S3) で誰でも使用することができます。2015 年にランドスタッド 8 号が撮影した画像はすべて 2013 年と 2014 年のクラウドフリーシーンのセレクションと同様に使用可能になっています。ランドスタット 8 号の新しい画像はすべて毎日数時間内に作成されています。衛星画像は 16 日間ごとに 30 メートルの解像度で地球全体を撮影しています。詳しくは Landsat on AWS をご覧ください。

NEXRAD 気象レーダー
The Next Generation Weather Radar (NEXRAD) は、ドップラー式 160 度の高解像度気象レーダー網で、降水の傾向と大気移動を検知し各地点から約 5 分間隔で情報を発信しています。NEXRAD は暴風雨を予測し、研究者や営利企業は複数の地域に渡る気象上の影響を調査する場合にこれを使用しています。詳しくは NEXRAD on AWS をご覧ください。

SpaceNet 機械学習コーパス
SpaceNet は高解像度が非常に高い DigitalGlobe 衛星画像のコーパスで、研究者が機械学習アルゴリズムを開発するために利用するトレーニングデータです。このデータセットはおよそ 1,990 平方キロに渡る画像を 50 cm の解像度と基礎伏図に一致する 220,594 から成り立ちます。詳しくは SpaceNet コーパスをご覧ください。

NASA Earth Exchange
The NASA Earth Exchange (NEX) は研究者が地球科学データに簡単かつ効率的にアクセスできるようにします。NEX データセットは Amazon S3 で使用可能です。ダウンスケール気候予測 (リリースされたばかりの Localized Constructed Analogs を含む)、グローバル MODIS 植生指数、Landsat Global Land Survey データも含みます。詳しくは NASA Earth Exchange をご覧ください。

オープンデータの活用
オープンデータは自分の目的に合わせた使用法を理解することで初めて便利になります。そのため、Earth on AWS は他のユーザーがどのように地理空間データを独自のワークフローに取り入れているのかを説明したビデオや記事を提供しています。Lambda を使用して地理空間サーバーを置換する方法からレーダー情報を使用した鳥の大群移動の調査まで、様々な活用方法があります。

他にも Earth on AWS データを活用できるアイデアがあれば、ぜひお聞かせください。Earth on AWS データセットに関する調査用の公開プロポーザルを受け付けています。これは従来のバリアを崩すことで学生、教育者、研究者が技術革新において主要な促進力となり、ご自分の分野で新たに進歩することを目的としたものです。お客様に感謝の気持ちを込めて
こうしたデータセットを AWS で使用可能にするためにご協力いただいた DigitalGlobeMapzenPlanetUnidata のお客様に、この場を借りて感謝申し上げます。

AWS では常に大規模なデータセットを使用する新たな方法を模索しています。追加すべき新しいデータやデータ提供の新たな方法についてアイデアがあればこちらにお問い合わせください。

Joe Flasher、Open Geospatial Data リード担当、アマゾン ウェブ サービス

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; (翻訳は星野が担当しました。原文はこちら。)

AWS オンラインセミナー – 2016 年 9 月(英語によるセミナー)

今月始めに継続学習のメリットについて説明したブログを公開し、継続学習と昇給、効率性の向上や転職の傾向が減少する関連性について表したインフォグラフィックをご紹介しました。AWS のイノベーションのペースは、いつも何か新しいことを学べるチャンスがあることを意味しています。これを実践するには AWS のオンラインセミナーに参加するのも 1 つの方法です。AWS ではこうしたオンラインセミナーをデザインする上でトレーニングと教育の面を考慮しています。そうすることで、参加者は新しい AWS サービスを使い始める準備を整えることができるほか、既存のサービスを別の方法で活用するための知識を得ることができると考えています。9 月に開催するオンラインセミナーにも素晴らしい内容が揃っています。いつもながら受講は無料ですが、すぐに満席になってしまうため、お早目の登録をお勧めします。開催時間はすべて太平洋標準時、所要時間は 1 時間です。

9 月 20 日

9 月 21 日

9 月 22 日

9 月 26 日

9 月 27 日

9 月 28 日

9 月 29 日

Jeff;

 

PS – 過去のセミナーは AWS オンラインセミナーのアーカイブからご覧ください。

週刊 AWS – 2016 年 9 月 5 日

これは、週刊 AWS 第 3 回目のコミュニティ型エディションです。これを実現するために貢献してくださった 15 名の内外部寄稿者に感謝申し上げます。寄稿を希望される場合は、GitHub の週刊 AWS をご覧ください。

月曜日

9 月 5 日

火曜日

9 月 6 日

水曜日

9 月 7 日

木曜日

9 月 8 日

金曜日

9 月 9 日

土曜日

9 月 10 日

日曜日

9 月 11 日

新しい & 注目のオープンソース

  • s3logs-cloudwatch は S3 サーバーのアクセスログファイルの分析や CloudWatch でバケットのメトリックスを追加する Lambda 関数です。
  • README.md は、AWS 認定の準備に使用する AWS リソースのリストです。
  • RedEye は Redshift のパフォーマンスをモニタリングするユーティリティです。
  • Dockerfile は Docker イメージを作成、EC2 Container Registry にプッシュし Elastic Beanstalk でデプロイします。
  • lambda-contact-form は S3/CloudFront でホストしている静的ウェブサイトの投稿からの連絡に対応します。
  • dust は EC2 の SSH クラスターシェルです。
  • aws-ssh-scp-connector は EC2 インスタンスへの接続を助けるユーティリティです。
  • lambda-comments は Lambda で構築したブログのコメントシステムです。

新しい SlideShare プレゼンテーション

新しい YouTube 動画

新しいお客様の事例

  • MYOB は AWS を使用してインフラストラクチャをスケールし、新しいサービスの要求に対応したり未使用のキャパシティーをシャットダウンすることで 30 パーセントの節約、予約済みの Amazon EC2 インスタンスを使用します。MYOB はオーストラリアやニュージーランドの企業や団体、約 120 万社にビジネス管理ソフトウェアを提供しています。MYOB は予測分析を組み込んだスマートアプリケーションを構築する Amazon Machine Learning や、災害時に新しい AWS 環境を作成する AWS CloudFormation スクリプトなど、さまざまな AWS サービスを使用しています。
  • グローバルにわたる市場浸透を可能にする上で、ゲームサービスに確実な安定性と拡張性を持つ IT ソリューションを必要としていた PATI Games に、AWS はもっとも安全でコスト効率の高いソリューションを提供しました。韓国企業の PATI Games は主に SNS プラットフォームをベースにしたゲーム開発に取り組んでいます。Amazon EC2、Amazon RDS (Aurora)、Amazon CloudFront を含む AWS サービスは、PATI Games の高い信頼性やレイテンシーの短縮を維持し顧客の満足度の向上に協力しています。
  • Rabbi Interactive はライブブロードキャスト、セカンドスクリーンアプリ、何百、何千人というユーザーの投票システムをサポートし、テレビの視聴者がリアルタイムなインタラクションを楽しめるようにするほか、AWS を使用することで月々の運用コストを 60% も削減することを実現しました。イスラエルに拠点を構える同企業は、セカンドスクリーンアプリなどで「ライジングスター」や「ビッグブラザー」などテレビの人気番組で視聴者がインタラクションを楽しめるデジタルエクスペリエンスを提供しています。Rabbi Interactive は AWS パートナーと協力してインタラクティブなセカンドスクリーンプラットフォームを開発しました。

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローして、RSS フィードをサブスクライブしてね。

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; (翻訳は星野が担当しました。原文はこちら)

MeetMe での S3 データレイクへのリアルタイムデータのストリーミング

本日のゲスト投稿では、MeetMe の Anton Slutsky 氏が、自社のデータレイク用の実装プロセスについて説明します。

Jeff;


Anton Slutsky 氏は、この分野で 20 年近い経験を持つ経験豊富な情報技術者です。ビラノバ大学でコンピューター科学の修士号を取得し、ドレクセル大学で情報科学の博士号を取得しています。

現在のビッグデータシステムには、しばしばデータレイクと呼ばれる構造が含まれています。データレイクという業界用語は、大量の構造化データと非構造化データを吸収し、多数の同時分析ジョブを実行する機能を備えた大規模なストレージおよび処理サブシステムのことです。Amazon Simple Storage Service (S3) はスケーラブルで信頼性が高く、レイテンシーが短いストレージソリューションを低いオペレーションのオーバーヘッドで提供するため、データレイクインフラストラクチャとして現在人気の高い選択肢となっています。ただし、S3 によってペタバイト規模のストレージのセットアップ、設定、管理に関連する多くの問題が解決される一方で、S3 へのデータの取り込みがしばしば課題となっています。これは、ソースデータのタイプ、ボリューム、速度が組織によって大きく異なっているためです。このブログでは、Amazon Kinesis Firehose を使用して MeetMe で大規模なデータ取り込みを最適化、合理化する当社のソリューションについて説明します。これは毎日数百万人のアクティブなユーザーに対応している人気の高いソーシャル検出プラットフォームです。MeetMe のデータサイエンスチームは、1 日あたり約 0.5 TB のさまざまなタイプのデータを、データマイニングタスク、ビジネス向けレポート、高度な分析に公開するような方法で収集、保存する必要がありました。チームはターゲットのストレージ機能として Amazon S3 を選択し、大量のライブデータを堅牢で信頼性が高く、スケーラブルで運用費用が低い方法で収集するという課題に直面していました。ここでの全体的な目的は、可能な限り低いオペレーションのオーバーヘッドで、AWS データインフラストラクチャに大量のストリーミングデータをプッシュするプロセスをセットアップすることでした。Flume、Sqoop など多くのデータ取り込みツールが現在入手可能ですが、当社は、その自動的なスケーラビリティと伸縮性、設定と管理の容易さ、それに S3、Amazon RedshiftAmazon Elasticsearch Service など他の Amazon サービスとの即座の統合機能により、Amazon Kinesis Firehose を選択しました。

ビジネス価値 / 正当化
多くのスタートアップ企業と同じように、MeetMe は最大のビジネス価値をできるだけ低いコストで提供することに焦点を置いています。したがって、データレイクについては次のような目標がありました。

  • 効果的な意思決定のための高レベルなビジネスインテリジェンスでビジネスユーザーに力を与える
  • 収益を生み出す洞察の発見に必要なデータをデータサイエンスチームに提供する。

Scoop や Flume といったよく使われているデータ取り込みツールを検討した結果、データサイエンスチームはデータ取り込みプロセスをセットアップ、設定、調整、維持するためにフルタイムの BigData エンジニアを追加する必要があり、冗長性のサポートを可能にするために、エンジニアリングの時間がさらに必要であると予測されました。このようなオペレーションのオーバーヘッドは MeetMe でのデータサイエンスの費用を増やし、全体的な速度に影響する不要な範囲をチームにもたらします。Amazon Kinesis Firehose サービスにより多くの運用面の懸念が軽減され、それによりコストも削減されました。それでもある程度の社内の統合開発は必要でしたが、データコンシューマーのスケーリング、管理、アップグレード、トラブルシューティングは Amazon によって行われるため、データサイエンスチームの規模と範囲は大幅に減りました。

Amazon Kinesis Firehose Stream の設定
Kinesis Firehose には、複数の Firehose システムを作成する機能があり、それぞれの対象を異なる S3 の場所、Redshift テーブル、または Amazon Elasticsearch Service インデックスにすることができます。当社の場合、主要な目標はデータを S3 に保存し、将来的には上記のような他のサービスも検討するというものでした。Firehose の配信ストリームのセットアップは 3 ステップのプロセスです。ステップ 1 では、送信先タイプを選択する必要があります。これにより、データの統合先を S3 バケット、Redshift テーブル、または Elasticsearch インデックスに定義できます。当社ではデータを S3 に配置することを希望したため、統合先オプションとして “Amazon S3″ を選択しました。S3 を統合先として選択すると、Firehose でその他の S3 オプション (S3 バケット名など) が求められます。Firehose のドキュメントで説明したように、Firehose では自動的にデータを日時で整理し、”S3 プリフィックス” 設定が、特定の Firehose ストリームオブジェクトのすべての S3 キーの前に付加されるグローバルプレフィックスとなります。プレフィックスは、データを使用中のライブストリームにおいてさえ後日に変更できるため、最初から命名規則について深く考える必要はまったくありません。

プロセスの次のステップはストリーム設定です。ここで、さまざまなデフォルト値を上書きし、他の意味ある値を指定することができます。たとえば、非圧縮のデフォルト値の代わりに GZIP 圧縮を選択すると、S3 ストレージのフットプリントを大幅に減らし、それにより S3 のコストを減らすことができます。データ暗号化を有効にすると、保管時のデータが暗号化されます。これは機密データにとって重要です。

1 つの重要な注意点として、圧縮アルゴリズムの選択により、ストリームオブジェクトのファイル名 (S3 キー) に影響があります。したがって、これらの設定は後からライブストリームで変更することができるものの、処理スクリプトで発生する可能性がある問題を回避するため、最初から圧縮/暗号化手法を決定することが賢明かもしれません。

Amazon Kinesis Firehose Limits」で述べたように、 Kinesis Firehose にはデフォルトのスループットクォータのセットがあります。これらのクォータを超えると、Firehose は “ServiceUnavailableException: Slow down.” というエラーメッセージで応答し、データを削除します。したがって、データ損失を避けるには、個別のスループット要件を予測することが重要です。これらの要件がデフォルトのクォータを超える可能性が高い場合、制限で説明されているように限度の引き上げリクエストを送信することで、追加のスループットをリクエストできます。最終ステップ (ここには示しません) では、目的の設定を確認し、ストリームを作成します。

アップロードプロセスのセットアップ
MeetMe では、RabbitMQ が、システムを通過するほとんどのデータのサービスバスとして機能しています。したがって、データ収集のタスクのほとんどの部分は、大量の RabbitMQ メッセージを使用し、Firehose ストリームを利用してそれらを S3 にアップロードすることになります。これを達成するため、軽量の RabbitMQ コンシューマーを開発しました。RabbitMQ コンシューマーは他の場所 (Flume など) に実装されていますが、Firehose API との統合を可能にするため、独自のバージョンを開発することにしました。

Firehose には、データをアップロードするために、単一のレコードとバルクレコードという 2 つの方法があります。単一のレコードの手法では、各個別のレコードが Amazon Firehose API フレームワークオブジェクトにパッケージ化され、各オブジェクトは HTTP/Rest を通じて Firehose エンドポイントにシリアル化されます。この手法は一部のアプリケーションにとって適切な場合がありますが、当社はバルク API 方法を使用することで、より良いパフォーマンスを達成しました。バルク方法では、最大 500 レコードを 1 つのリクエストで Firehose にアップロードできます。メッセージのバッチをアップロードするため、軽量 RabbitMQ コンシューマーは小規模な内部バッファを維持します。これは事前定義されたプロセッサスレッドのセットにより、可能な限り多く Firehose にシリアル化されます。以下にコードを示します。

new Thread(new Runnable()
{
  public void run()
  {
    logger.info("Kinesis ライタースレッドが開始しました。  レコードの処理を待機しています...");
    while(true)
    {
      try
      {
        if(!recordsQueue.isEmpty())
        {
           if(logger.isDebugEnabled())
             logger.debug("現在のバッチを AWS にアップロードしています: "+recordsQueue.size());
        
           List<MMMessage> records = recordsQueue;
           recordsQueue = new CopyOnWriteArrayList<MMMessage>();
        
           final int uploadThreshold = 499;
        
           List<Record> buffer = new ArrayList<Record>(uploadThreshold);
        
           for(int i = 0; i < records.size(); i++)
           {
             // 内部キューから独自のメッセージオブジェクトを取得します
             MMessage mmmessage = records.get(i);
                 
             // バイト数を取得します
             String message = new String(mmmessage.body, "UTF-8");
                 
             // データの新しい行とタブ文字を確認し
             // Hadoop/Spark 処理行ベースの処理の問題を
             // 後で回避します
             message = CharMatcher.anyOf("\n").replaceFrom(message, "\\n");
             message = CharMatcher.anyOf("\t").replaceFrom(message, "\\t");
 
             // Amazon Firehose API ラッパーでメッセージバイトをラップします    
             Record record = new Record().withData(ByteBuffer.wrap(message.getBytes()));
 
             buffer.add(record);
                 
             // 現在のバッファが十分に大きい場合、
             if(buffer.size() == uploadThreshold)
             {
               // Firehose に送信し
               uploadBuffer(buffer);
               // 新しいバッファをインスタンス化します
               buffer = new ArrayList<Record>(uploadThreshold);
             }
           }
           // 最後のバッファのアップロードを忘れないでください!
           uploadBuffer(buffer);                                
         }
       }
       catch(Exception e)
      {
        logger.error("Error in sending to Kinesis:"+e.getMessage(), e);
      }
    }
  }
}).start();

uploadBuffer メソッドは、バルクアップロード Firehose API に対するシンプルなラッパーです。

private void uploadBuffer(final List<Record> buffer)
{
  // 新しいリクエストオブジェクトを作成します
  PutRecordBatchRequest request = new PutRecordBatchRequest();
  // ストリーム名を指定します
  request.setDeliveryStreamName("MEETME_STREAM");
        
  // データバッファを設定します
  request.setRecords(buffer);
 
  // Firehose への送信を試みます
  PutRecordBatchResult result = getAmazonClient().putRecordBatch(request);
        
  // 常に失敗について確認してください!
  Integer failed = result.getFailedPutCount();
  if (failed != null && failed.intValue() > 0)
  {
    // 失敗がある場合、その原因を見つけます
    logger.warn("AWS upload of [" + buffer.size() + "] resulted in " + failed + " failures");
                 
    // 応答を調べ、さまざまな種類の失敗がないかどうか確認します
    List<PutRecordBatchResponseEntry> res = result.getRequestResponses();
    if (res != null)
    {
      for (PutRecordBatchResponseEntry r : res)
      {
        if (r != null)
        {
          logger.warn("Report " + r.getRecordId() + ", " + r.getErrorCode() + ", " + r.getErrorMessage()
                      + ", " + r.toString());
        }
        else
        {
          logger.warn("Report NULL");
        }
      }
    }
    else
    {
      logger.warn("BatchReport NULL");
    }
  }
}

Firehose ストリームのモニタリング
Firehose ストリームをセットアップし、内部コンシューマープロセスがデータの送信を開始した後の一般的なタスクは、データフローのモニタリングを試みることです。データフローに注意する理由として、データボリュームの考慮事項、エラー状態の可能性、失敗の検出などがあります。Amazon Firehose では、モニタリングは Amazon CloudWatch を利用して達成されます。一般的な配信ストリームメトリックスは、各 Firehose ストリーム設定の [Monitoring] タブで表示でき、その他のメトリックスは CloudWatch コンソールから表示できます。

AWS は広範なモニタリング機能を提供していますが、当社の経験では、内部データプロデューサーログでエラーを慎重にモニタリングするのが重要であることがわかっています。syslog 機能、Splunk、およびその他のログモニタリングツールを使ってこのように注意深いモニタリングを行うことで、特定のエラーを検出して修正し、個別のレコードの失敗数を許容できるレベルにまで減らすことができました。さらに、内部ログのモニタリングにより、ボリュームが急速に Firehose のデフォルトのスループットクォータを超えていることを早期に認識できました (上記を参照)。

Anton Slutsky、データサイエンス担当ディレクター、MeetMe

Yemeksepeti: サーバーレスアーキテクチャへの当社の移行

AWS コミュニティヒーローの Onur Salk 氏から、自社のサーバーレスアーキテクチャへの移行をどのように支援したかについて、次のようなゲスト投稿が寄せられました。

Jeff;


私は AWS コミュニティヒーローAWS 認定ソリューションアーキテクト – プロフェッショナルトルコの AWS ユーザーグループの主催者である Onur Salk と申します。私はヒーローとして、AWS の経験と知識を個人ブログやコミュニティでの出会いを通じて共有していきたいと思っています。本日は、当社 Yemeksepeti の事例と、サーバーレスアーキテクチャへの移行についてお話したく思います。

Yemeksepeti の事例
Yemeksepeti はトルコ最大のオンライン注文企業です。ユーザーは、提携先のネットワークレストランから食材の注文を行うことができ、手数料はかかりません。Yemeksepeti では、スケーラブルでパフォーマンスと費用効率の高い、世界中に分散したサービスをセットアップする必要がありました。当社は、サーバーレスアーキテクチャを設計することで、サーバーの管理について心配することなく、チームから多くの運用面の負担を取り除くことができると考えています。つまり、コードの大規模な実行に集中できるということです。

Yemeksepeti.com では、約 4 年前に Joker と呼ばれるリアルタイムの割引システムを開発しました。このシステムの目的は、レストランに関して通常ないような割引を顧客に提案することです。元の Joker プラットフォームは .NET で開発され、その REST API を使ってウェブサイトやモバイルデバイスと統合されました。世界 34 か国で営業している関連会社も顧客にリアルタイムの Joker 割引を提供できるように、関連会社に対してプラットフォームの API を公開することを求められました。

最初はコードを共有し、関連会社にアプリケーションを統合させることを考えました。ただし、他のほとんどの国では異なる技術スタック (プログラミング言語、データベースなど) を使用していました。当社のコードを使用することで、最初は関連会社による開発が迅速化する可能性がありますが、不慣れなシステムを管理しなければなりません。実装がより簡単で、管理費用がより安い統合方法を見つける必要がありました。

当社の要件
これはグローバルなプロジェクトであり、次の 5 つの重点領域がありました。

  • 管理の容易さ
  • 高可用性
  • スケーラビリティ
  • 複数のリージョンでの使用
  • 費用のメリット

複数の異なる処理モデルについてこれらの重点領域を評価した結果を、次のマトリックスに示します。

管理の容易さ 高可用性 スケーラビリティ 複数のリージョンでの使用 費用のメリット
IaaS

一部の EC2 インスタンスにより Microsoft Windows Server で IIS を実行し、RDS DB インスタンスに接続できた。
いいえ。サーバーの管理が必要。 はい。別の AZ にサーバーを分散できる。 はい。Auto Scaling を使用できる はい。AMI を使用し、リージョン間でコピーできる 部分的。EC2 インスタンスの実行にはライセンス料と費用が必要。
PaaS

AWS Elastic Beanstalk を使用できた。
部分的。サーバーの管理が必要。 はい。別の AZ にサーバーを分散できる。 はい。Auto Scaling を使用できる。 はい。環境設定、AMI などを使用できる。 部分的。EC2 インスタンスの実行にはライセンス料と費用が必要。
FaaS

AWS Lambda を使用できた。
はい。AWS がサービスを管理。 はい。すでに高い可用性を確保している はい。規模を問わずパフォーマンスを発揮する はい。設定を簡単にエクスポート/インポート/アップロードできる。 はい。ライセンス不要で従量課金制である。

当社は Faas (Functions as a Service) を使用することに決定しました。以下のサービスを使って、Europe (Ireland) リージョンでプロジェクトを開始しました。

アーキテクチャ
当社のアーキテクチャを次に示します。

Amazon VPC: 当社は Amazon VPC を使用してプライベートネットワークでリソースを起動します。

Amazon API Gateway: 開発段階中、Europe (Ireland) リージョンでサービスの開発を開始しました。その当時、AWS Lambda は Europe (Frankfurt) で利用できませんでした。当社は 2 つの API を作成しました。1 つはウェブ統合用、もう 1 つは管理インターフェイス用です。JSON ウェブトークン (JWT) を使用したカスタム認証により、API 用にトークンベースの認証を可能にしました。マッピングテンプレートを使用して変数を Lambda 関数に渡しました。

開発段階では、各 API に対してテストステージのみがありました。

本稼働段階中に、AWS Lambda がフランクフルトで利用可能になりました。そこにサービスを移動し、トルコから低レイテンシーのアクセスのメリットを受けることにしました。API Gateway Export API 機能を使用して設定を Swagger 形式でエクスポートし、それをフランクフルトにインポートしました (インポート前に、エクスポートされたファイルのリージョン定義を eu-central-1 に変更しました)。その後、実稼働ステージを作成し、ステージ変数を使用して Amazon RDS インスタンスのデータベース定義 (ホスト、ユーザー名など) をパラメーター化しました。また、カスタムドメイン名を使用したいと考えました。ドメイン用に SSL 証明書を購入した後で、Amazon API Gateway コンソールでカスタムドメイン名を作成し、CloudFront ディストリビューション名のエイリアスを作成しました (Amazon API Gateway はバックグラウンドで Amazon CloudFront を使用します)。最後に、API コール、レイテンシーなどについて Amazon CloudWatch のログ記録を有効にするために IAM ロールを作成しました。

Get_Joker_offer リソースのメトリックス:

AWS Lambda: 開発段階中に、Python を使用してサービスを開発し、CloudWatch Events Lambda トリガーを使用して API メソッドとスケジュールされたタスクを統合するために、65 個の関数を作成しました。Lambda VPC の統合が実稼働段階中に利用可能になったため、関数をフランクフルトリージョンにアップロードし、VPC と統合しました。

Get_joker_offer Lambda 関数の呼び出しカウント (ピークは昼食時および夕食時に一致します (空腹時)):

Amazon RDS: 開発段階中に、Amazon RDS for PostgreSQL の使用を選択しました。サービスをテストするために、1 つの AZ RDS インスタンスを作成しました。実稼働段階中に、API と関数をフランクフルトに移行したため、データベースを移動する必要がありました。インスタンスのスナップショットを作成し、RDS のスナップショットのコピー機能を使用して、データベースを正常に移動しました。VPC で、実稼働用のマルチ AZ インスタンスと、テスト目的のシングル AZ インスタンスの 2 つのインスタンスを起動しました。API ステージ変数で、ステージングを適切なインスタンスにマッピングするため、RDS インスタンスのエンドポイント名を定義しました。また、両方のインスタンスで自動バックアップを有効にしました。Amazon S3: Joker プラットフォームには、Joker のオファーを管理および報告するための管理パネルがあります。この管理インターフェイスをホストするため (基本的に Single Page Application (SPA) と AngularJS)、Amazon S3 の静的ウェブサイトホスティング機能を使用しました。すべてのロジックと機能は Lambda で実行されているメソッドによって提供されているため、管理インターフェイス用のサーバーは必要ありませんでした。

Amazon CloudWatch: 当社はこのサービスを使用して重要なアセットの使用量をモニタリングし、何かあった場合にアラートを受け取っています。プロダクションデータベースの CPU、接続カウント、重要な API レイテンシー、および関数のカウントと継続時間をモニタリングするためにカスタムダッシュボードを作成しました。Python コードで、CloudWatch の各内部メソッドの継続時間をログに記録し、パフォーマンスを追跡してボトルネックを発見します。

CloudWatch ダッシュボードを次に示します。

Amazon ElasticSearch: 開発段階中に、Amazon ES への Cloudwatch ログストリーミングがアイルランドリージョンで利用可能になりました。この機能を使用して、コードから生成するログの他のメトリックスをモニタリングするため、Kibana ダッシュボードを作成しました。Amazon ES がフランクフルトリージョンで利用可能になったらすぐに、再びこれを使用する予定です。

初期の結果
Joker システムは、国の小規模なリージョンに対して、パイロット運用として現在は実稼働状態になっています。次の図からわかるように、注文数の増加は前途有望です。当社は、サーバーレスアーキテクチャを利用することで、オペレーティングシステムと依存関係をインストール、管理する必要がなくなりました。Amazon API Gateway、AWS Lambda、Amazon S3、および Amazon RDS を使用することで、当社のアーキテクチャを可用性の高い環境で実行できます。マスタースレーブレプリケーション機能やサードパーティーのツールについて学習し、管理する必要がありません。サービスでより多くのリクエストを受け取ると、AWS Lambda がより多くの Lambda インスタンスを追加し、任意のスケールで実行されます。実稼働に移行する前のように、AWS サービスの機能を使用してサービスを別のリージョンにコピーすることができます。最後に、サーバーは一切実行していないので、サーバーレスアーキテクチャの費用のメリットを活用できます。Joker を通じて行われたオーダー数を次に示します。

次のステップ
このサービスが Delivery Hero Holding の 34 の関連会社すべてに拡大されることを願っています。サービスをグローバルに展開する際に、他の AWS リージョンにデプロイします。会社に最も近いリージョンを選択する予定です。費用を最適化するため、RDS インスタンス用のリザーブドインスタンスを購入します。また、内部メソッドの継続時間をモニタリングし、コードをリファクタリングおよび最適化して、Lambda 関数の実行時間を減らすことができます。当社はクラウドの将来は FaaS であると考えています。他の機能、サービス、関数が利用可能になったときにさらに試したいと思っています。AWS コミュニティヒーローとして、トルコの AWS ユーザーグループと Yemeksepeti の事例を共有することを楽しみにしています。みなさまのサーバーレスアーキテクチャの検証と利用のお手伝いができればと考えております。– Onur Salk

AWS SDK for C++ – 本稼働環境で使用する準備ができました

1 年近くに及ぶ開発者からのフィードバックと貢献により、バージョン 1.0 の AWS SDK for C++ が利用可能になりました。本稼働環境での使用をお勧めします。SDK はセマンティックバージョニングに従っているため、バージョン 1.0 から、任意のバージョン 1.x の C++ SDK を信頼することができ、アップグレードによってビルドが破損することはありません。

SDK のデベロッパープレビューについて寄せられたフィードバックに基づいて、いくつかの重要な変更や機能強化を行いました。

  • セマンティックバージョニング – SDK はセマンティックバージョニングに従っています。バージョン 1.0 から、1.x シリーズ内のアップグレードによってビルドが破損することはありません。
  • Transfer Manager – 元の TransferClient は機能が強化された新しい TransferManager インターフェイスへと進化しました。
  • ビルドプロセス – CMake ビルドチェーンは、プラットフォームのデフォルト値を簡単に上書きできるよう機能が強化されました。
  • 簡略化された設定 – 実行時に SDK 全体の設定オプションを簡単に設定できるようになりました。
  • 暗号化 – SDK には、サポートされるすべてのプラットフォームで対称暗号化のサポートが含まれるようになりました。
  • NuGet – 現在、SDK は NuGet を通じて入手できます (詳細については、「AWS SDK for C++ Now Available via. NuGet」を参照してください)。
  • Fixes – 1.0 コードベースには数多くのバグ修正とビルドの機能強化が含まれています。

さらに、AWS での C++ の開発をさらに簡単で安全にするための、より高いレベルの API を間もなく公開します。機能が強化された新しい TransferManager API を使用したコードサンプルを次に示します。

#include <aws/core/Aws.h>
#include <aws/s3/S3Client.h>
#include <aws/transfer/TransferManager.h>

static const char* ALLOC_TAG = "main";

int main()
{
    Aws::SDKOptions options;
    Aws::InitAPI(options);

    auto s3Client = Aws::MakeShared<Aws::S3::S3Client>(ALLOC_TAG);
    Aws::Transfer::TransferManagerConfiguration transferConfig;
    transferConfig.s3Client = s3Client;

    transferConfig.transferStatusUpdatedCallback =
       [](const TransferManager*, const TransferHandle& handle)
       { std::cout << "Transfer Status = " << static_cast(handle.GetStatus()) << "\n"; }

    transferConfig.uploadProgressCallback =
        [](const TransferManager*, const TransferHandle& handle)
        { std::cout << "Upload Progress: " << handle.GetBytesTransferred() << " of " << handle.GetBytesTotalSize() << " bytes\n";};

    transferConfig.downloadProgressCallback =
        [](const TransferManager*, const TransferHandle& handle)
        { std::cout << "Download Progress: " << handle.GetBytesTransferred() << " of " << handle.GetBytesTotalSize() << " bytes\n"; };
    
    Aws::Transfer::TransferManager transferManager(transferConfig);
    auto transferHandle = transferManager.UploadFile("/user/aws/giantFile", "aws_cpp_ga", "giantFile", 
                                                     "text/plain", Aws::Map<Aws::String, Aws::String>());
    transferHandle.WaitUntilFinished();
     
    Aws::ShutdownAPI(options);
    return 0;
}

詳細については、AWS SDK for C++ ホームページおよび AWS 開発者ブログ (C++) を参照してください。

引き続きフィードバックをお寄せください
AWS SDK for C++ は本稼働環境で使用する準備ができたため、お客様のご意見やご感想、使用事例、さらにより良くするための方法などをお寄せください。改善点について、お気軽に問題を登録いただくか、プルリクエストを送信してください。

Jeff;

週刊AWS – 2016 年 8 月 29 日

これは、AWS Week in Review の 2 番目のコミュニティ型エディションです。 この実現に貢献してくれた 13 名の外部寄稿者に特に感謝します。 寄稿を希望される場合は、GitHub の AWS Week in Review をご覧ください。 関連するコンテンツの追加は、快適なご自分のウェブブラウザから迅速かつ簡単に行えます。 念のためですが、他者によって書かれたコンテンツを追加することもまったく問題ありません。 目標は、よく言われるように、すべてをキャッチすることです。

月曜日

8 月 29 日

火曜日

8 月 30 日

水曜日

8 月 31 日

木曜日

9 月 1 日

金曜日

9 月 2 日

新しい & 注目のオープンソース

  • apilogs は、API Gateway および Lambda サーバーレス API によって生成された CloudWatch ログイベントを集計、ストリーミング、フィルタリングするのを補助するコマンドラインユーティリティです。
  • MoonMail は、完全に Lambda / SES による、E メールマーケティングツールです。

新しい SlideShare プレゼンテーション

新しいお客様事例

  • Bustle は、AWS Lambda を使用して、リアルタイムでウェブサイトにより生成された大量のデータを処理し、チームが迅速にデータ主導の意思決定を行えるようにしています。 Bustle.com は女性の望みに応えるニュース、エンターテインメント、ライフスタイル、ファッションのウェブサイトです。
  • Graze は、そのインフラストラクチャを含め、俊敏性を維持することにより顧客エクスペリエンスを向上させ続けています。 同社はウェブサイトを通じて、および英国の小売業者を経由して健康的なスナックを販売しています。 顧客向けウェブサイト、および工場のフロアからビジネスインテリジェンスまでそのすべての内部システムを含むすべてのインフラストラクチャを、AWS で実行しています。
  • Made.com は、ダウンタイムなしで記録的な販売期間をサポートするために、AWS に移行しました。 同社は、家具デザイナーを直接消費者にリンクするウェブサイトを提供します。 Amazon EC2、Amazon RDS、および Auto Scaling グループなどのサービスを使用して、AWS で e コマースプラットフォーム、ウェブサイト、および顧客向けのアプリケーションを実行しています。
  • ソニー DADC ニューメディアソリューションズ (NMS) では、AWS の全面活用により、毎月数十万時間分のビデオコンテンツを配信し、データ分析をスピンアップし、ソリューションを数か月ではなく数日単位で提供し、ハードウェア更新にかかるコストを数百万ドル節約しています。 同社は、世界中の映画スタジオ、テレビ放送局、他のプロバイダにコンテンツを配信および提供しています。 NMS は、AWS クラウド上で、コンテンツ配信プラットフォーム、ブロードキャストプレイアウトサービス、ビデオアーカイブを実行しています。
  • Upserve では Amazon Machine Learning を使用して、100 以上の学習モデルを迅速に開発および訓練し、リアルタイムでレストランの売上高およびメニューアイテムのデータをストリームし、レストラン経営者が毎晩のビジネスを予測できるようにしています。 同社は米国中の数千人のレストランの経営者にオンライン決済および分析ソフトウェアを提供しています。Upserve は、そのシフト準備アプリケーションを使って予測分析を提供するために Amazon Machine Learning を使用しています。

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローしてください。また、RSS フィードをご購読いただき、コンテンツを投稿してください。

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 (翻訳は星野が担当しました。原文はこちら)