Amazon Web Services ブログ

ログとクリックストリームのデータを保存するためにデータベーステーブルを使用するアプリケーションがあるとしましょう。データは、開発タスクと管理タスクを容易にするためにリレーショナルデータベースに保存されているかもしれません。アプリケーションを起動すると、初めのうちはこのデータベースも管理可能ですが、データベースは毎週何百ギガバイトにも成長します。データストレージと取得だけでも、リレーショナルデータベースインスタンスの IOPS と CPU の 20 パーセントが消費されています。さらに、アプリケーションはトランザクションデータに加えて、データベーステーブルに XML ドキュメント、JSON ドキュメント、およびバイナリドキュメントも保存しています。履歴データも毎月増加し続けています。従来のオンプレミスデータベースのライセンスコストとインフラストラクチャコストは増える一方で、データベースのスケーリングが大きな課題になっています。このような場合には何ができるでしょうか? このブログ記事では、AWS クラウドに移行するときにデータベースコストを削減し、可用性を向上させる戦略について説明します。 データストアのタイプ リレーショナルデータベース管理システム (RDBMS) は、ほとんどのトランザクション処理システムの中核を成しています。RDBMS にすべてのデータを保存することによって、以下が起こる可能性があります。 パフォーマンス問題の原因になる。大規模なテーブルには、データのクエリにより長い時間が必要です。特定のテーブル一連における大量の読み取り/書き込みトラフィックは、データベースでの他のクエリの速度を低下させます。 総所有コスト (TCO) を増大させる。より多くの読み取り/書き込みトラフィックに対応するには、より多くのコンピューティングキャパシティーとストレージ容量を追加することによってデータベースを垂直にスケールする必要があります。これは季節的なトラフィックの増加に対処するためのものかもしれまんせんが、アプリケーショントラフィックへの対応に高額な先行投資を行わなければなりません。また、データベースサーバーをスケールダウンすることはできません。これも TCO を増加させます。 AWS に移行すると、アプリケーションはリレーショナルデータベースのストレージだけを使用するのではなく、そのデータを専用のデータストアに保存することができます。アプリケーションが使用するデータストアは、そのアクセスパターンに応じて異なります。これは、データがどのような規模で増加することを見込んでいるか、およびデータにどれだけ迅速にアクセスする必要があるかにも依存します。以下の表は、これらのデータストアのタイプと用途、および各タイプの例を示すものです。 データストア 用途 例 NoSQL 広告配信、ゲーミングデータ、IoT センサーデータ、およびユーザープロファイルなどの非構造化データ Amazon DynamoDB、MongoDB、Apache Cassandra ビッグデータ Twitter フィード、クリックストリームデータ、およびログなどのペタバイト規模のデータの保存と分析 Amazon EMR、Hadoop、Apache Spark、Apache Hive、Apache HBase キャッシング ゲームのスコアボードなどのアプリケーションサーバーとデータベースの間にあるキャッシュレイヤー Amazon ElastiCache オブジェクトストレージ ログファイル、画像、Twitter フィード、およびバックアップなどの、無制限の量のデータと無制限のオブジェクトの保存 Amazon Simple Storage Service (Amazon S3) […]

AWS データベースのページを見ると、私たちが信じられないほど幅広い種類のデータベースを提供していること、それぞれが特定のニーズに対応するために作られていることが分かるでしょう！ 最も素晴らしく、最も強力なアプリケーションを構築するために、リレーショナルデータベース、キーバリューデータベース、インメモリデータベース、グラフデータベース、時系列データベース、台帳データベースを組み合わせることができます。 Amazon DocumentDB (MongoDB 互換) の概要 本日、既存の MongoDB アプリケーションおよびツールと互換であるように設計された、高速、スケーラブル、高可用性のドキュメントデータベース Amazon DocumentDB (MongoDB 互換) を開始します。Amazon DocumentDB は、専用の SSD ベースのストレージレイヤーを使用し、3 つの個別のアベイラビリティーゾーンにわたって 6 のレプリケーションを作成します。このストレージレイヤーは分散型で、耐障害性があり、自己修復型であるため、本稼働規模の MongoDB ワークロードを実行するために必要なパフォーマンス、スケーラビリティ、可用性が得られます。 それぞれの MongoDB データベースには、一連のコレクションが含まれています。それぞれのコレクション (リレーショナルデータベースのテーブルに類似) には、それぞれが JSON に似ている BSON フォーマットである、一連のドキュメントが含まれています。以下に例を挙げます。 { name: “jeff”, full_name: {first: “jeff”, last: “barr”}, title: “VP, AWS Evangelism”, email: “jbarr@amazon.com”, city: “Seattle”, foods: [“chocolate”, “peanut butter”] } […]

Amazon SageMaker は、モデルの開発、トレーニング、およびデプロイ、ソリューション構築のコスト削減、データサイエンスチームの生産性向上のための完全な機械学習 (ML) ワークフローサービスです。Amazon SageMaker には、多くの事前定義済みアルゴリズムが付属しています。また、Docker イメージ、モデルをトレーニングするためのトレーニングイメージ、および REST エンドポイントにデプロイするための推論モデルを指定して、独自のアルゴリズムを作成することもできます。 機械学習モデルの構築とデプロイを自動化することは、本稼働の機械学習サービスを作成する上で重要なステップです。コードおよび/またはデータが更新されたときは、モデルを再トレーニングしてデプロイする必要があります。このブログ記事では、AWS Step Functions を使用した Amazon SageMaker の自動化の手法について説明します。新しいオープンソースプロジェクトである aws-sagemaker-build を通してそれを実証します。このプロジェクトは私たちのワークフローを完全に実装しています。Python と Amazon Alexa を使用してビルドの作成、起動、停止、進行状況の追跡を行う方法を示す Jupyterノ ートブックも含まれています。 aws-sagemaker-build の目的は、Amazon SageMaker と AWS Step Functions を使用する一般的で有用なパイプラインのリポジトリを提供することです。このリポジトリはコミュニティと共有され、コミュニティによって成長できます。 このコードはオープンソースであり、GitHub のここでホストされています。 カスタムモデル このブログ記事では、トレーニングや推論のために Dockerfile を作成および設計する方法の詳細については説明しません。詳細については、以下のドキュメントをご覧ください。 Example Project and Tutorial using aws-sagemaker-build (aws-sagemaker-build を使ったサンプルプロジェクトとチュートリアル) Training Image Documentation (トレーニングイメージのドキュメント) Inference Image Documentation (推論イメージのドキュメント) […]

simpleshow は 10 数年前に、3 分間のアニメーション解説動画を使用することによって、お客様がそれぞれの素材、アイデア、および製品を説明できるように援助し始めました。これらの解説動画は、ふたつの手とシンプルな白黒のイラストを使って視聴者にストーリーを伝えます。現在 simpleshow では、誰もがほぼすべてのトピックに関する高品質の解説動画を作成できるプラットフォーム、mysimpleshow.com も提供しています。このプラットフォームは Amazon Polly と統合されているため、台本が提供されていれば、誰でも解説動画に自然な発音の音声を使用できます。 最初に、simpleshow についてもう少しお話ししてから、mysimpleshow がどのように Amazon Polly と統合されているかについて説明したいと思います。 過去 10 年の間、simpleshow は解説動画フォーマットの有効性を科学的に証明し、simpleshow の専門家は、何千にも及ぶ解説動画において、シンプルかつ楽しい方法でそれぞれのトピックを紹介できるようにお客様を助けてきました。 これらの動画の制作には、チーム内に多くの才能が必要です。 ストーリーテリング: 認定された simpleshow のコンセプトライターが基本的な事実を中心にストーリーを創り出します。 イラストレーション: 才能豊かなアーティストが適切な抽象化レベルで対象物とコンセプトをイラストにします。 ビジュアル化: ストーリーボードアーティストとモーションデザイナーがストーリーをビジュアル化してアニメーションにします。 音声: プロの話し手のネットワークが、ふさわしい口調であることを確実にします。 解説動画が極めて幅広い用途を持つフォーマットであることに気付いた simpleshow のチームは、さらに多くの分野におけるさらに多くのユーザーがリソースを使用できるようにしたいと考えました。これが、simpleshow のチームが mysimpleshow.com を作った理由です。このプラットフォームは、誰もがほぼすべてのトピックに関する高品質の解説動画を作成できるようにするものです。mysimpleshow は人口知能 (AI) を使用し、使いやすいユーザーインターフェイスを備えています。 mysimpleshow でのプロセスはとてもシンプルです。 まず、ユーザーがストーリーを書きます。mysimpleshow は、幅広いトピックを対象とするサンプルストーリーを使ったテンプレートとインスピレーションでユーザーをガイドします。 ストーリーのテキストは、次に mysimpleshow の中核にある人工知能、Explainer Engine によって分析されます。Explainer Engine は、意味のあるキーワード、人物、および場所を認識するために自然言語処理 (NLP) を使用します。その後、Wikipedia […]

このブログ記事では、推論パイプラインを紹介します。これは、推論リクエストごとに実行される一連の手順を指定できる、Amazon SageMaker の新機能です。この機能を使用すると、同じコードの 2 つの別のコピーを保持する必要なしで、推論中のトレーニングで適用されたデータ処理手順を再利用できます。これにより、予測が正確になり、開発のオーバーヘッドを削減できます。ここでの例では、Apache Spark MLlib で変換器を使用してトレーニングと推論の入力データを前処理し、Amazon SageMaker の XGBoost アルゴリズムを使用して自動車の状態を予測する機械学習モデルをトレーニングします。 概要 データサイエンティストや開発者は、機械学習 (ML) モデルをトレーニングする前に、データのクリーニングと準備に多くの時間を費やしています。これは、現実のデータを直接使用することができないためです。値が欠落していたり、情報が重複していたり、標準化する必要がある同じ情報の複数のバリエーションがあったりするからです。さらに多くの場合、機械学習アルゴリズムで使用できるために、データをある形式から別の形式に変換する必要があります。たとえば、XGBoost アルゴリズムは数値データしか受け入れないため、入力データが文字列またはカテゴリ形式の場合は、使用する前に数値形式に変換する必要があります。他には、複数の入力の特徴を単一の特徴に組み合わせることで、より正確な機械学習モデルとなります。たとえば、気温と湿度を組み合わせて飛行遅延を予測すると、より正確なモデルが作成されます。 機械学習モデルを本稼働にデプロイして新しいデータを予測する場合 (推論と呼ばれるプロセス)、トレーニングで使用されたのと同じデータ処理手順がそれぞれの推論リクエストにも適用されるようにする必要があります。そうしないと、誤った予測結果となる可能性があります。今までは、トレーニングと推論に使用するために同じデータ処理手順の 2 つのコピーを維持し、それらが常に同期していることを確認する必要がありました。また、データ処理手順を、機械学習モデルへのリクエストを行うアプリケーションコードと組み合わせるか、推論ロジックに組み込む必要がありました。その結果、開発のオーバーヘッドと複雑さが必要以上に高くなり、迅速に繰り返す能力が制限されていました。 現在は、Amazon SageMaker に推論パイプラインを作成することで、推論中のトレーニングと同じデータ処理手順を再利用できます。推論パイプラインを使用すると、最大 5 つのデータ処理および推論の手順を指定できます。これらの手順は、全ての予測リクエストに対して実行されます。トレーニングのデータ処理手順を再利用できるので、データ処理コードのコピーを 1 つだけ管理し、クライアントアプリケーションや推論ロジックを更新することなくデータ処理手順を個別に更新することができます。 Amazon SageMaker は、推論パイプラインの作成方法に柔軟性をもたらします。データ処理手順では、Scikit-Learn および Apache SparkMLlib で利用可能な組み込みのデータ変換器を使用して、一般的なユースケースのためにデータをある形式から別の形式に処理および変換するか、カスタムの変換器を作成することができます。推論では、Amazon SageMaker で利用可能な組み込みの機械学習アルゴリズムとフレームワークを使用することもできますし、カスタムのトレーニングモデルを使用することもできます。リアルタイム推論とバッチ推論で同じ推論パイプラインを使用できます。推論パイプラインのすべての手順が同じインスタンスで実行されるため、レイテンシーによる影響は最小限になります。 例 この例では、AWS Glue を使用するデータ処理に Apache Spark MLLib を使用し、推論中にデータ処理コードを再利用します。UCI の Machine Learning Repository の Car Evaluation データセットを使用します。目標は、unacc、acc、good、vgoodの値の中から、特定の車の容認可能性を予測することです。根本的には分類問題であり、Amazon SageMaker の組み込みの […]

2018 年の re:Invent で、AWS は Amazon マネージドブロックチェーンを発表しました。一般的なオープンソースフレームワークのハイパーレジャーファブリックおよびイーサリアムを使用して、スケーラブルなブロックチェーンネットワークを簡単に作成および管理できる完全マネージド型のサービスです。このサービスのプレビューは、ハイパーレジャーファブリックフレームワークのサポートとともに利用できます。イーサリアムのサポートも間もなく開始されます。マネージドブロックチェーンの詳細については、「Amazon マネージドブロックチェーンとは何ですか？」を参照してください。 サービスを利用するには、プレビューにサインアップしてください。 この記事では、マネージドブロックチェーンを使用して、ハイパーレジャーファブリックのブロックチェーンネットワークを構築する方法を学びます。ファブリックネットワークを作成したら、そのネットワークを使用して非営利組織への寄付を追跡する 3 層アプリケーションをデプロイします。非営利組織は、その後援者に可視性を提供し、寄付金の使い方に対して透明性を保ちたいと思っています。ハイパーレジャーファブリックは、篤志家による各寄付金の使い方について詳細を追跡します。篤志家はこの情報を使用して、非営利組織が期待通りに寄付金を使っているかどうかを判断できます。 ブロックチェーンは、援助機関、投資家、慈善機関、サプライヤー、および非営利組織自身を含むネットワーク内の全メンバーの間で信頼を深められるため、このシナリオに適しています。ネットワーク内の全メンバーは、寄付および支出記録に対して、独自の不変で暗号化された安全なコピーを持ちます。メンバーは単独で、寄付金がいかに効果的に使われているかを見直すことができます。透明性は、非営利組織のコスト削減に対する効率性と洞察力の向上につながります。

先日 (2018/12/19) 開催しました AWS Black Belt Online Seminar「AWS Certificate Manager」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 AWS Black Belt Online Seminar 2018 AWS Certificate Manager from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. DNS検証に成功した後、Route53の該当するレコードを削除した場合、証明証の自動更新がされないなどの影響がありますか？ A. 影響がございます。こちらをご確認ください。 Q. RDSにSSL証明書があると思いますが、ACMで管理できるものですか？妄想的な質問で恐縮ですが、自動で更新されると良いかと思いまして A. ACMの管理対象ではありませんが、RDSの機能でメンテナンスウィンドウで自動更新されますが、RDSに接続するクライアント側で対応が必要な場合があります。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html Q. ACMで使えるドメインを教えてください A. 下記よくある質問の内容をご確認ください。 よくある質問では、複数ドメイン対応、ワイルドカードドメイン、ドメインに利用できる文字形式についての質問を掲載しております。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております！ AWS Black Belt Online Seminar 1月分申込先 ≫ Redshift […]

今月の初めに、同僚の Bala Thekkedath がエクストリームスケール HPC についての記事を公開し、AWS のお客様である Western Digital が AWS でクラウド規模の HPC クラスターを構築し、それを使用して次世代ハードディスクドライブ (HDD) のための将来のヘッドにおける極めて重要な要素をシミュレートした方法について語りました。 この記事で説明されているシミュレーションには 250 万強のタスクが含まれており、その実施は vCPU 100 万個の Amazon EC2 クラスター上でわずか 8 時間で完了しました。Bala がその記事で述べたように、Western Digital でのシミュレーション作業のほとんどが、HDD を包含するテクノロジーとソリューションの異なる組み合わせを評価する必要性を中心に展開されています。エンジニアはその過程において、ますます多くのデータを同じ領域に詰め込むこと、ストレージ容量を改善すること、そして転送速度を向上させることに焦点を当てます。材料、エネルギーレベル、および回転速度の何百万もの組み合わせのシミュレートすることは、Western Digital が最も高い密度と最も速い読み取り/書き込み時間を追求することを可能にし、結果をより迅速に得ることは、より良い判断を行うことを可能にすると共に、新しい製品を以前より速く市場に出すことができるようにします。 以下は、Western Digital のエネルギーによる記録処理が行われる様子を可視化したものです。上の横棒は磁気、中央の横棒は付加されたエネルギー (熱)、そして下の横棒は磁気と熱の組み合わせによって媒体に書き込まれた実際のデータを表しています。 先日、私は記録を塗り替えるこのシミュレーションを実現するために共に取り組んだ私の同僚、Western Digital のチーム、そして Univa に話を聞きました。私の目的は、このシミュレーションのための準備方法についての詳細を解明し、彼らが学んだ事柄を理解して、独自の大規模ジョブを実行する準備が整っている皆さんとそれらを分かち合うことでした。 規模の拡大 約 2 年前、Western Digital チームは、可能な限りコスト効率を良くするために、EC2 スポットインスタンスによって作動する、vCPU 8 万個もの大きさのクラスターを実行していました。クラスターは、8,000 個、1 万 6,000 個、および […]

  AWS ではこの 2019 年、DynamoDB での作業時にミッションクリティカルなワークロードのパフォーマンスを最大化して、コストを最適化するために役立つ Amazon DynamoDB のベストプラクティスに従うことをお勧めします。この記事は、このような抱負の維持を助ける DynamoDB のコンテンツに焦点を当てて行きます。 パーティションキーを効率的に設計して使用する DynamoDB テーブルにある各アイテムを固有に識別するプライマリーキーは、シンプルなキー (パーティションキーのみ) または複合キー (ソートキーと組み合わされたパーティションキー) にすることができます。アプリケーションは、テーブルとそのセカンダリインデックスの論理パーティションキー全体で統一されたアクティビティのために設計してください。これは NoSQL のベストプラクティスですが、バーストキャパシティー、アダプティブキャパシティー、および書き込みシャーディングといった追加のメリットが得られます。 ソートキーを使用してデータを編成する DynamoDB テーブルでは、テーブル内の各アイテムを固有に識別するプライマリーキーを、パーティションキーだけではなく、ソートキーも使って構成することができます。適切に設計されたソートキーは、関連する情報を一か所に集め、それを効率的にクエリすることができます。複合ソートキーは、データで階層 (1 対多) リレーションシップを定義することを可能にし、任意の階層レベルでクエリすることができます。 セカンダリインデックスを効率的に使用する 多くの場合、セカンダリインデックスはアプリケーションが必要とするクエリパターンをサポートするために必須です。その一方、非効率的なセカンダリインデックスの使用は不必要にコストを増加させ、パフォーマンスを低下させます。 大型のアイテムと属性を保存する方法を理解する DynamoDB では現在、テーブルに保存する各アイテムのサイズが制限されています。お使いのアプリケーションに、サイズ制限の許容範囲を超えるデータをアイテムに保存する、またはそのアイテムをソートキーの効率的な使用によって分類される複数のアイテムに分割する必要がある場合、ひとつ、または複数の大型の属性を圧縮してみる、またはそれらを Amazon S3 内のオブジェクトとして保存して、Amazon S3 オブジェクト識別子を DynamoDB アイテムに保存することができます。 期間ごとに 1 アプリケーションあたり 1 つのテーブルを使って時系列データに対応する DynamoDB における一般的な設計原則では、使用するテーブルの数を最小限にとどめることが推奨されています。ほとんどのアプリケーションには、単一のテーブルしか必要ありません。しかし、時系列データについては、期間ごとに 1 アプリケーションあたり 1 つのテーブルを使うことができます。 多対多リレーションシップを管理する 隣接リストは、DynamoDB における多対多リレーションシップのモデル化に有用な設計パターンです。より一般的には、DynamoDB でグラフデータ (ノードとエッジ) を表現する方法を提供します。 […]

AWS Auto Scaling は、AWS リソースをそれらのトラフィックパターンに基づいて動的にスケールアップ/スケールダウンすることができます。しかし、典型的なアプリケーションスタックには多数のリソースがあり、これらのリソースすべてに対して個別の AWS Auto Scaling ポリシーを管理することは、組織的な課題となり得ます。スケーリングプランを使用すると、タグを用いることによって AWS Auto Scaling ポリシーの作成を自動化し、これらのポリシーを簡単に変更できます。このブログ記事では、リソースをひとつ、または複数のタグに基づいてグループ化し、スケーリングプランを使用することによって AWS Auto Scaling ポリシーを集約、設定、および管理する方法をご紹介します。 タグベースのスケーリングプランを使用するには、AWS リソースにタグを付けてからプランをセットアップする必要があります。私は、この例を開始する前にスケーリングプランで管理したい AWS リソースを検討しました (私の場合は Amazon EC2 Auto Scaling グループと Amazon DynamoDB テーブルです)。次に、対応する正しい値 (DEV、BETA、または PROD のいずれか) を持つ環境タグを使用してリソースにタグ付けしました。環境タグは、リソースのスケーリングポリシーをインフラストラクチャの場所別にグループ化して管理する、そしてターゲット使用率の割合を調整するために使用できます。リソースのタグ付けに役立つヒントと戦略については、AWS Tagging Strategies をご覧ください。 注意: AWS Auto Scaling は現在、AWS のリージョン表に記載されているリージョンでご利用いただけます。 インフラストラクチャ環境に基づいたスケーリングプランのセットアップ このセクションでは、すべての開発リソースのためにひとつのスケーリングプランをセットアップし、本番リソースのために 2 つ目のプランをセットアップします。これらのスケーリングプランによって、選択したタグに関連付けられている関連リソースのグループに、ターゲット使用率のパラメーターを簡単に設定することができるようになります。 開発リソースのためのプランの作成 作成を開始するには、AWS Auto Scaling コンソールに移動します。既存のスケーリングプランはないので、[今すぐ始める] を選択します。(既存のプランがある場合は、AWS Auto Scaling […]