Amazon Web Services ブログ

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

Amazon Relational Database Service (RDS)は構築や運用管理、スケーリングなどを行うプロセスを簡単に行えるクラウド上のリレーショナルデータベースです。現在6つのデータベースエンジン(Amazon Aurora, Oracle, Microsoft SQL Server, PostgreSQL, MySQL,  MariaDB) をサポートしており、RDSはクラウド上で動作するアプリケーションの基本となるサービスとなりました。 2013年後半にPostgreSQLサポートを発表し、PostgreSQLの新バージョンや新機能を追加し続けてきました。 2014年11月 – Read Replicas, version 9.3.5, Trigger-based Replication, and Three New Extensions. 2015年3月  – Version 9.4.1, Enhanced Monitoring, Enforced SSL Connections. 2015年11月 – Point and Click Upgrade from Version 9.3 to 9.4. 2016年4月  – Versions 9.3.12, 9.4.7, and 9.5.2. 2016年6月 […]

今月始めに継続学習のメリットについて説明したブログを公開し、継続学習と昇給、効率性の向上や転職の傾向が減少する関連性について表したインフォグラフィックをご紹介しました。AWS のイノベーションのペースは、いつも何か新しいことを学べるチャンスがあることを意味しています。これを実践するには AWS のオンラインセミナーに参加するのも 1 つの方法です。AWS ではこうしたオンラインセミナーをデザインする上でトレーニングと教育の面を考慮しています。そうすることで、参加者は新しい AWS サービスを使い始める準備を整えることができるほか、既存のサービスを別の方法で活用するための知識を得ることができると考えています。9 月に開催するオンラインセミナーにも素晴らしい内容が揃っています。いつもながら受講は無料ですが、すぐに満席になってしまうため、お早目の登録をお勧めします。開催時間はすべて太平洋標準時、所要時間は 1 時間です。 9 月 20 日 午前 9:00 – 詳細: ビッグデータ分析に Amazon Redshift を使用 午前 11:30 – コンテナを大規模にモニタリング 9 月 21 日 午前 9:00 – Cognito ユーザープールの使用開始について: アプリで簡単にユーザーのサインアップとサインインを追加 午前 11:30 – データウェアハウスを Amazon Redshift に移行する場合のベストプラクティス 午後 1:00 – Amazon Elasticsearch Service のログ分析 9 月 22 […]

これは、週刊 AWS 第 3 回目のコミュニティ型エディションです。これを実現するために貢献してくださった 15 名の内外部寄稿者に感謝申し上げます。寄稿を希望される場合は、GitHub の週刊 AWS をご覧ください。 月曜日 9 月 5 日 John McKim が AWS のサーバーレスフレームワークと GraphQL についてブログを公開しました。 火曜日 9 月 6 日 AWS Config を使用して設定変更に関係する API イベントの表示が可能になったことを AWS が公表しました。 本稼働環境で AWS SDK for C++ の使用が可能になったことを AWS が公表しました。 IAM Service Last Accessed Data がアジアパシフィック (ムンバイ) リージョンで利用可能になったことを AWS が公表しました。 が自動推測や Amazon s2n […]

機能向上を行うたびにAmazon Auroraはパワフルかつ簡単にご利用頂けるようになってきました。ここ数ヶ月で、MySQLバックアップからAuroraクラスタを作成する機能や、クロスリージョンレプリケーション、アカウント間でのスナップショットの共有、フェイルオーバー順を指定可能になったり、他のクラウドやオンプレミス環境のデータベースからAuroraへ移行などを追加してきました。 本日、Auroraのリードレプリカの機能を向上する、クラスタレベルのリードエンドポイントを追加しました。皆様のアプリケーションは今まで通り特定のレプリカに対して直接クエリを実行することが可能です。しかし、今回追加したリードエンドポイントを利用するように変更することで、負荷分散や高可用性といった2つの大きな利点を得ることが出来ます。 Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間でコネクションのロードバランシングが可能になります。これは、リードワークロードを分散することで利用可能なレプリカ間でリソースを効率的に活用することができ、よりよりパフォーマンスを得ることが可能になります。フェイルオーバーの際には、もしアプリケーションが接続しているレプリカがプライマリインスタンスに昇格した場合コネクションは一旦クローズされます。その後、再接続を行うことでクラスタ内の他のレプリカにリードクエリを実行することが可能です。 Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが出来ます。Availability Zoneの可用性の問題が万が一発生した場合、リードエンドポイントを利用することで最小限のダウンタイムでリードトラフィックを他のレプリカに実行可能です。   Find the Endpoint リーダーエンドポイントはAurora Consoleで確認可能です: この便利な機能は本日からご利用可能です！ — Jeff; (翻訳は星野が担当しました。原文はこちら)

本日のゲスト投稿では、MeetMe の Anton Slutsky 氏が、自社のデータレイク用の実装プロセスについて説明します。 Anton Slutsky 氏は、この分野で 20 年近い経験を持つ経験豊富な情報技術者です。ビラノバ大学でコンピューター科学の修士号を取得し、ドレクセル大学で情報科学の博士号を取得しています。 現在のビッグデータシステムには、しばしばデータレイクと呼ばれる構造が含まれています。データレイクという業界用語は、大量の構造化データと非構造化データを吸収し、多数の同時分析ジョブを実行する機能を備えた大規模なストレージおよび処理サブシステムのことです。 はスケーラブルで信頼性が高く、レイテンシーが短いストレージソリューションを低いオペレーションのオーバーヘッドで提供するため、データレイクインフラストラクチャとして現在人気の高い選択肢となっています。ただし、S3 によってペタバイト規模のストレージのセットアップ、設定、管理に関連する多くの問題が解決される一方で、S3 へのデータの取り込みがしばしば課題となっています。これは、ソースデータのタイプ、ボリューム、速度が組織によって大きく異なっているためです。このブログでは、 を使用して MeetMe で大規模なデータ取り込みを最適化、合理化する当社のソリューションについて説明します。これは毎日数百万人のアクティブなユーザーに対応している人気の高いソーシャル検出プラットフォームです。MeetMe のデータサイエンスチームは、1 日あたり約 0.5 TB のさまざまなタイプのデータを、データマイニングタスク、ビジネス向けレポート、高度な分析に公開するような方法で収集、保存する必要がありました。チームはターゲットのストレージ機能として Amazon S3 を選択し、大量のライブデータを堅牢で信頼性が高く、スケーラブルで運用費用が低い方法で収集するという課題に直面していました。ここでの全体的な目的は、可能な限り低いオペレーションのオーバーヘッドで、AWS データインフラストラクチャに大量のストリーミングデータをプッシュするプロセスをセットアップすることでした。Flume、Sqoop など多くのデータ取り込みツールが現在入手可能ですが、当社は、その自動的なスケーラビリティと伸縮性、設定と管理の容易さ、それに S3、、 など他の Amazon サービスとの即座の統合機能により、Amazon Kinesis Firehose を選択しました。 ビジネス価値 / 正当化 多くのスタートアップ企業と同じように、MeetMe は最大のビジネス価値をできるだけ低いコストで提供することに焦点を置いています。したがって、データレイクについては次のような目標がありました。 効果的な意思決定のための高レベルなビジネスインテリジェンスでビジネスユーザーに力を与える。 収益を生み出す洞察の発見に必要なデータをデータサイエンスチームに提供する。 Scoop や Flume といったよく使われているデータ取り込みツールを検討した結果、データサイエンスチームはデータ取り込みプロセスをセットアップ、設定、調整、維持するためにフルタイムの BigData エンジニアを追加する必要があり、冗長性のサポートを可能にするために、エンジニアリングの時間がさらに必要であると予測されました。このようなオペレーションのオーバーヘッドは MeetMe でのデータサイエンスの費用を増やし、全体的な速度に影響する不要な範囲をチームにもたらします。 サービスにより多くの運用面の懸念が軽減され、それによりコストも削減されました。それでもある程度の社内の統合開発は必要でしたが、データコンシューマーのスケーリング、管理、アップグレード、トラブルシューティングは Amazon によって行われるため、データサイエンスチームの規模と範囲は大幅に減りました。 Amazon Kinesis Firehose […]

AWS コミュニティヒーローの Onur Salk 氏から、自社のサーバーレスアーキテクチャへの移行をどのように支援したかについて、次のようなゲスト投稿が寄せられました。 私は AWS コミュニティヒーロー、AWS 認定ソリューションアーキテクト – プロフェッショナル、トルコの AWS ユーザーグループの主催者である Onur Salk と申します。私はヒーローとして、AWS の経験と知識を個人ブログやコミュニティでの出会いを通じて共有していきたいと思っています。本日は、当社 Yemeksepeti の事例と、サーバーレスアーキテクチャへの移行についてお話したく思います。 Yemeksepeti の事例 Yemeksepeti はトルコ最大のオンライン注文企業です。ユーザーは、提携先のネットワークレストランから食材の注文を行うことができ、手数料はかかりません。Yemeksepeti では、スケーラブルでパフォーマンスと費用効率の高い、世界中に分散したサービスをセットアップする必要がありました。当社は、サーバーレスアーキテクチャを設計することで、サーバーの管理について心配することなく、チームから多くの運用面の負担を取り除くことができると考えています。つまり、コードの大規模な実行に集中できるということです。 Yemeksepeti.com では、約 4 年前に Joker と呼ばれるリアルタイムの割引システムを開発しました。このシステムの目的は、レストランに関して通常ないような割引を顧客に提案することです。元の Joker プラットフォームは .NET で開発され、その REST API を使ってウェブサイトやモバイルデバイスと統合されました。世界 34 か国で営業している関連会社も顧客にリアルタイムの Joker 割引を提供できるように、関連会社に対してプラットフォームの API を公開することを求められました。 最初はコードを共有し、関連会社にアプリケーションを統合させることを考えました。ただし、他のほとんどの国では異なる技術スタック (プログラミング言語、データベースなど) を使用していました。当社のコードを使用することで、最初は関連会社による開発が迅速化する可能性がありますが、不慣れなシステムを管理しなければなりません。実装がより簡単で、管理費用がより安い統合方法を見つける必要がありました。 当社の要件 これはグローバルなプロジェクトであり、次の 5 つの重点領域がありました。 管理の容易さ 高可用性 スケーラビリティ 複数のリージョンでの使用 費用のメリット […]

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 […]

これは、AWS Week in Review の 2 番目のコミュニティ型エディションです。 この実現に貢献してくれた 13 名の外部寄稿者に特に感謝します。 寄稿を希望される場合は、GitHub の AWS Week in Review をご覧ください。 関連するコンテンツの追加は、快適なご自分のウェブブラウザから迅速かつ簡単に行えます。 念のためですが、他者によって書かれたコンテンツを追加することもまったく問題ありません。 目標は、よく言われるように、すべてをキャッチすることです。 月曜日 8 月 29 日 CloudWatch ログとダッシュボードの改良を発表しました。 は、楽しく簡単なスナップショットのためのスパースな EBS ボリュームの構築方法を説明しました。 [backspaceblog] は、アプリケーションのフロントエンドセキュリティ (「責任分担 2 – Dynamic CSS セレクタを使用して、ボットを停止する。」) について説明しました。 John McKim はサーバーレスアーキテクチャについて書きました。 Antoni Massó は、「AWS における ElastiCache (Memcached) ノードの自動検出の実装方法」のチュートリアルを共有しました。 火曜日 8 月 30 日 AWS […]

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 […]