Amazon Web Services ブログ

Amazon EFS のスケーラブルでクラウドネイティブなファイルストレージを使いさらなるデータ保存を

先月投稿した記事において、当社の Amazon Elastic File System (Amazon EFS) の低頻度アクセスストレージクラス (EFS IA) が、数万社におよぶお客様によりいかに活用されているかをお伝えしました。完全マネージド型で、高い可用性と耐久性を持ち伸縮自在なクラウドシステムは、簡単でコスト効率が高く、ネイティブのようにファイル保存が行えます。 当社の AWS News ブログでは、Amazon EFS がさらに訴求力を高めたことも発表しています。EFS IA でのストレージ料金が 44%* 値下げされており、これは、AWS が現在までに行った値下げの中で、最も大きな値下げ率を適用した 1 つとなっています。 先月の記事で取り上げている業界でも浸透した 80/20 ルールを採用し、この Amazon EFS の新料金体系では、クラウドファイルシステムへのペタバイト級データの保存が、たったの 0.08 USD/GB – 月* という費用対効果の高い料金で行えます。この低価格設定により、EFS のお客様は大規模ファイルの保存とアクセスを行いながら、EFS がご提供するすべてのメリットを享受することが可能です。データのうちどれが頻繁に使用され、アクセス頻度の低いデータはどれかなどを気にすることなく、パフォーマンスと低コスト化の両面で役立てていただけるのです。 *料金は米国東部 (バージニア北部) リージョンでのものです。その他のリージョンでの料金については、 「Amazon EFS の料金」 をご参照ください。 Amazon EFS 導入の成功例 すでに多くのお客様が、EFS 低頻度アクセスストレージクラスを利用することで、クラウドのファイル保存に要する年間のコストを数十万ドルも削減しています。EFS IA を利用開始するのは非常に簡単で、ただ、EFS コンソールでの数回クリックにより、自分のファイルシステムのための EFS ライフサイクルの管理を有効化するだけです。EFS ライフサイクルの管理が有効化されると、EFS がファイルへのアクセスパターンを認識し、お客様が選択されたポリシーにしたがい、アクセス頻度の低いファイルを自動的に低コストストレージクラスへと移動します。EFS […]

Read More

Kubernetes サービスアカウントに対するきめ細やかな IAM ロール割り当ての紹介

本投稿は Micah Hausler と Michael Hausenblas による記事を翻訳したものです AWS ではお客様のニーズに最優先にフォーカスしています。Amazon EKS におけるアクセス権制御に関して、みなさまは「パブリックコンテナロードマップ」の Issue #23 にて EKS でのきめ細かい IAM ロールの利用方法 を求められていました。このニーズに応えるため、コミュニティでは kube2iam、kiam や Zalando’s IAM controller といったいくつかのオープンソースソリューションが登場しました。これらのソリューションは素晴らしいプロダクトであるだけでなく、それぞれのアプローチの要件及び制約は何なのかについて多くの方の理解を促すことを可能にしました。 そして今、柔軟かつ簡単に利用可能なソリューションがやってきました。私たちの重要なゴールとして、粒度の高いロールを Node レベルではなくPod レベルでの提供がありました。私たちが今回考え出したソリューションもオープンソースとして公開されているため、eksctl での Amazon EKS クラスター作成時にも利用できますし、DIY アプローチでの Kubernetes クラスターとしてポピュラーな kops によって作成されたようなクラスタにおいてもご利用いただくことが可能です。 アクセスコントロール: IAM と RBAC Kubernetes on AWS では、補完しあう2つのアクセスコントロール手法が動作します。AWS Identity and Access Management (IAM) は AWS サービスへのアクセス許可、例えばあるアプリケーションが S3 […]

Read More

トランザクションを使用した Amazon DynamoDB の一意制約のシミュレーション

大抵のリレーショナルデータベースシステム、そして一部の非リレーショナルデータベースシステムには、ユニークキーまたはユニーク制約として知られるコンストラクトがあります。この機能は、列またはフィールド内のすべての値が行全体で一意であることを確実にします。 たとえば、User テーブルがあるとします。それには、各ユーザーを一意に識別するプライマリキーとして UUID があるかもしれませんが、同じくユーザーにとって一意である必要があるユーザー名フィールドと E メールフィールド (DynamoDB 用語では「属性」) もあるかもしれません。このユースケースは、DynamoDB トランザクションに関する AWS Summit 2018 DAT374 セッションで言及されています。 Amazon DynamoDB では、プライマリキーがパーティションキー (テーブルにソートキーが選択されていない場合)、またはパーティションとソートキーの組み合わせのいずれかになります。プライマリキーは、テーブル内で一意であることが保証されています。しかし、DynamoDB には、プライマリキーではない属性の一意性を確実にするための組み込みメカニズムがありません。 この記事では、アプリケーション側からこのような類の一意性を実装するために使用されるパターンについて説明し、単一テーブルのスキーマ設計でこのパターンを使用するときに項目を作成、更新、および削除する方法の例をご紹介します。 ソリューションの概要 前述の例を使用して、User テーブルがあり、そのテーブルに以下のような属性があると考えてください。 pk (UUID として保存されたプライマリキー) userName email fullName phoneNumber UUID、userName、および email の各属性は一意である必要がありますが、fullName と phoneNumber にその必要はありません。複数の人物が同じ自宅電話番号を共有することができます。以下はサンプル行です。 pk userName email fullName phoneNumber b201c1f2-238e-461f-88e6-0e606fbc3c51 btables bobby.tables@gmail.com Bobby Tables +1-202-555-0124 8ec436a8-97e6-4e72-aec2-b47668e96a94 jsmith johnsmith@yahoo.com John Smith +1-404-555-9325 […]

Read More

Amazon DynamoDB スキャンパフォーマンスに対する Python バージョンの影響の分析

Amazon DynamoDB は、柔軟なスキーマを使用できる NoSQL データベースです。これは、項目それぞれにどのような属性が存在するかという点で、同じテーブル内の項目が互いに異なることを意味します。 前の AWS ブログ記事では、項目あたりの属性数の影響について検証しましたが、私たちは先日、お客様の Python アプリケーションにおけるスキャンが遅いという問題を解決するお手伝いをしていた時、Python バージョンのアップグレードがパフォーマンス向上に役立つかどうかを確認するために、異なるバージョンの Python インタプリタを調べました。 この記事では、Python インタプリタのバージョンがスキャンパフォーマンスにどのように影響し得るかをお見せしたいと思います。 手法 パーティションキーとソートキー (どちらも文字列) で構成されるプライマリキーというシンプルな構造の DynamoDB テーブルを 1 つ作成しました。また、それぞれに 7 文字のキー名 (「field01」、「field10」、など) を含む、個別の 6 文字の文字列属性 24 個 (6 x 24 = 合計 144 文字) で構成されるもうひとつの DynamoDB テーブルも作成しました。 DynamoDB には、単一のリクエストで取得するデータの量に 1 MB の上限があるので、ランダムなデータ 10,000 項目でテーブルをシードしてから、1 MB の上限内に収まるだけの項目を取得する単一のスキャンを実行します。その後、クライアント側でこれらの項目を取得し、アンマーシャルするためにかかる時間を測定します。 ウォークスルー 以下は、Python バージョンの比較に関する典型的な質問です。 Python のあるバージョンを使用する場合と、別のバージョンを使用する場合とでは、どのようにパフォーマンスが変化するのか? […]

Read More

Amazon Comprehend を使用してカスタムエンティティレコグナイザーを構築する

Amazon Comprehend は、非構造化テキストからキーフレーズ、場所、名前、組織、イベント、さらには感情の抽出などが行える自然言語処理サービスです。 お客様は通常、独自の部品コードや業界固有の用語など、ビジネスに固有の独自のエンティティタイプを追加することを望みます。2018 年 11 月、Amazon Comprehend の機能強化により、デフォルトのエンティティタイプをカスタムエンティティに拡張する機能が追加されました。さらに、カスタム分類機能により、ドキュメントを名前が付けられたカテゴリーにグループ化できます。たとえば、サポート E メールを部署ごとに、ソーシャルメディア記事を製品ごとに、または分析レポートを事業単位ごとにグループ化することができます。 概要 この記事では、カスタムエンティティレコグナイザーの構築方法について説明します。事前の機械学習の知識は必要ありません。カスタムエンティティレコグナイザーをトレーニングする前に、データを圧縮、フィルタリング、およびクリーンアップする必要がある例を示します。それ以外の場合は、次のステップバイステップの手順に従うだけで済みます。この手順は、データセットをすでに準備した状態で始めます。 この例では、Kaggle でホストされている Twitter のカスタマーサポートのデータセットを使用します。 データセットは主に短い発話で構成されています。これは、顧客とサポート担当者との間のチャット会話の典型的で一般的な例です。Twitter データセットからの発話のサンプルを次に示します。 @AppleSupport で返信が無視され、キーボードの下のタップされた通知が開きます?😡😡 @SpotifyCares ありがとう! Samsung Galaxy Tab A (2016) モデル SM-T280 のアンカー bluetooth スピーカーのバージョン 8.4.22.857 armv7 スピーカーからの距離が問題なのでしょうか? データをフィルター処理し、「TMobileHelp」と「sprintcare」を含むツイートのみを保持して、特定のドメインとコンテキストに集中できるようにしました。comprehend_blog_data.zip ファイルからコンピューターにデータセットをダウンロードして解凍します。 チュートリアル この例では、iPhone および Samsung Galaxy 携帯電話に関する情報を抽出するカスタムエンティティレコグナイザーを作成します。現在、Amazon Comprehend は両方のデバイスを「市販品」として認識しています。 このユースケースでは、より具体的にする必要があります。 特にスマートフォンデバイスを抽出できる必要があるため、抽出されたデータを一般的な市販品に制限すると効率的ではありません。この機能により、サービスプロバイダーはツイートからデバイス情報を簡単に抽出し、問題を関連するテクニカルサポートチームにルーティングすることができます。 Amazon Comprehend コンソールで、デバイスのカスタムエンティティレコグナイザーを作成します。[レコグナイザーをトレーニング] を選択します。 名前と、DEVICE などの [エンティティタイプ] […]

Read More

[AWS Black Belt Online Seminar] Amazon Aurora with PostgreSQL Compatibility 資料及び QA 公開

先日 (2019/8/28) 開催しました AWS Black Belt Online Seminar「Amazon Aurora with PostgreSQL Compatibility」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatibility AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. サブネットグループで、AZを2つだけグルーピングしていた場合でも、ストレージ(データ)は、3つのAZに書込みされるのでしょうか? A. はい。サブネットグループの設定に関わらず、Amazon Aurora は自動的に 3 つのアベイラビリティーゾーンにかけて 6 個のデータコピーを保持します。サブネットグループには、プライマリインスタンス(Writer), Aurora レプリカ(Reader)を配置するために利用します。 Q. リードレプリカについては、追加インスタンス毎に、インスタンスタイプを変えることは可能という認識であっていますか? A. はい。ご認識の通り可能です。ただし、プライマリインスタンスとリードレプリカは同じインスタンスクラスを利用することを推奨しています。レプリカの追加方法についてはこちらのドキュメントをご確認ください。 Q. RDS for PostgreSQL を選択するメリットは、どういうものがあるでしょうか? A. 現時点でAurora ではサポートされていない機能や拡張を利用したい場合は、RDS for PostgreSQL を選択する理由になります。例えば、PostgreSQL […]

Read More

[発表] Lambda 関数が VPC 環境で改善されます

本投稿は AWS サーバーレス アプリケーションのプリンシパルデベロッパーアドボケートであるChris Munnsによる寄稿です。 元の投稿からの更新情報: 2019年11月28日(PST):  次のリージョンに対して、元の投稿に記載されている改善を完全に展開しました:中東(バーレーン)。 2019年11月25日(PST):次のリージョン、米国東部(バージニア北部)、米国西部(オレゴン)、カナダ(中央)、EU(ロンドン)、EU(ストックホルム)、およびアジア太平洋(香港)に対して、これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 2019年11月6日(PST):次のリージョン、米国西部(北カリフォルニア)、EU(アイルランド)、EU(パリ)、アジア太平洋(ムンバイ)、アジア太平洋(ソウル)、アジア太平洋(シンガポール)、アジア太平洋(シドニー)、南アメリカ(サンパウロ)に対して、これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 2019年9月27日(PST):米国東部(オハイオ)、欧州(フランクフルト)、およびアジア太平洋(東京)の地域へ完全に展開しました。これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 既知の問題(2019年10月4日(PST)に更新): HashiCorp Terraformを使用している場合、サブネット、セキュリティグループ、VPCなどのVPCリソースは、この新しいモデルでのENIの動作方法の変更により破棄に失敗する可能性があります。この問題を解決するための手順と、詳細についてはこちらをご覧ください。 2019年9月3日(PST)の元の投稿: AWS Lambda 関数が Amazon VPC ネットワークでどのように機能するかが大幅に改善されたことをお知らせします。 2019年9月3日(PST)のローンチ機能により、関数の起動パフォーマンスが劇的に改善され、Elastic Network Interface がより効率的に使用されるようになります。 これらの改善は、すべての既存および新しい VPC 接続の関数に追加費用なしで展開されています。 ロールアウトは 2019年9月3日(PST)から始まり、すべてのリージョンで今後数か月にわたって徐々に展開されます。 Lambda は2016年2月に初めて VPC をサポートし、AWS Direct Connect リンクを使用して VPC またはオンプレミスシステムのリソースにアクセスできるようになりました。 それ以来、お客様が VPC 接続を広く使用して、さまざまなサービスにアクセスしているのを見てきました。 Amazon RDS などのリレーショナルデータベース Redis 用 Amazon ElastiCache または Amazon Elasticsearch Service などのデータストア Amazon EC2 または […]

Read More

Amazon SageMaker RL で継続的な学習を使用してコンテキストバンディットを強化する

Amazon SageMaker は、開発者やデータサイエンティストがあらゆる規模の機械学習モデルを短期間で簡単に構築、トレーニング、デプロイできるようにするモジュラー式完全マネージド型サービスです。 トレーニングモデルは、組み込みの高性能アルゴリズム、構築済みのディープラーニングフレームワークのセットや、独自のフレームワークを使用して、迅速かつ簡単に構築できます。 機械学習 (ML) アルゴリズムの選択を支援するために、Amazon SageMaker には、インストール済みでパフォーマンスが最適化された最も一般的な ML アルゴリズムが付属しています。 教師ありおよび教師なし学習手法を使用した機械学習モデルの構築に加えて、Amazon SageMaker RL を使用して Amazon SageMaker で強化学習モデルを構築することもできます。Amazon SageMaker RL には、強化学習の開始を容易にする、事前に構築された RL ライブラリとアルゴリズムが含まれています。GitHub には、Amazon SageMaker RL をロボットと自律走行車のトレーニング、ポートフォリオ管理、エネルギー最適化、自動容量スケーリングに使用する方法を示した例がいくつかあります。 このブログ記事では、Amazon SageMaker RL を使用してコンテキストを考慮したマルチアームバンディット (または略してコンテキストバンディット) を実装し、ユーザー向けにコンテンツをパーソナライズする方法を紹介します。コンテキストバンディットアルゴリズムは、おすすめをクリックしたかどうかなどのおすすめに対するユーザーの応答から学習することにより、ユーザー (ゲーマーやハイキング愛好家など) にさまざまなコンテンツオプションをおすすめします。このアルゴリズムでは、データの変化に適応するために機械学習モデルを継続的に更新する必要があり、Amazon SageMaker で反復トレーニングとデプロイループを構築する方法を説明します。 コンテキストバンディット パーソナライズされたウェブサービス (コンテンツレイアウト、広告、検索、製品のおすすめなど) のような多くのアプリケーションは、多くの場合、いくつかのコンテキスト情報に基づいて、継続的に決定を下す必要に迫られます。これらのアプリケーションは、ユーザー情報とコンテンツ情報の両方を利用して、個人向けにコンテンツをパーソナライズする必要があります。たとえば、彼女がゲーム愛好家であることに関連するユーザー情報と、そのゲームがレーシングゲームであることに関連するコンテンツ情報です。これらのアプリケーションを可能にする機械学習システムには、2 つの課題があります。ユーザーの好みを学習するためのデータはまばらで偏っています (多くのユーザーはほとんどまたはまったく履歴を持たず、過去におすすめされた製品も多くありません)。また、新しいユーザーとコンテンツが常にシステムに追加されています。パーソナライゼーションに使用される従来の Collaborative Filtering (CF) ベースのアプローチは、まばらで偏っているデータセットと現在のユーザーとコンテンツのセットに対して静的な推奨モデルを構築します。一方、コンテキストバンディットは、既知の情報の exploiting (ゲーム愛好家へゲームをおすすめすること) と、おすすめの exploring (ゲーム愛好家にハイキング用具をおすすめすること) との間でトレードオフを行うことで、戦略的な方法でデータを収集および増強します。これにより、高い利益が得られる可能性があります。バンディットモデルはユーザー機能とコンテンツ機能も使用するため、同様のコンテンツとユーザーの好みに基づいて、新しいコンテンツとユーザーにおすすめを作成できます。 先に進む前に、いくつかの用語を紹介しましょう。コンテキストバンディットアルゴリズムは、反復プロセスによって特徴付けられます。agent が選択できる (arm または […]

Read More

AWS CloudFormation を使用して Amazon Redshift クラスターの作成を自動化する

この投稿では、AWS アカウントで Amazon Redshift クラスターのデプロイを自動化する方法について説明します。セキュリティと高可用性に関する AWS のベストプラクティスに基づいてクラスターの設定を促進することで、AWS CloudFormation を使った設定を速やかに行うことができるようになります。 必要に応じてカスタマイズできる CloudFormation の一連のサンプルテンプレートを見ていきます。 Amazon Redshift は、高速かつスケーラブルで完全マネージド型の ACID と ANSI SQL に準拠したクラウドデータウェアハウスサービスです。新しいデータウェアハウスの設定とデプロイをほんの数分で行い、Amazon Redshift に保存されているペタバイト規模の構造化データに対してもクエリを実行できます。Amazon Redshift Spectrum を使用すると、データウェアハウジング機能が Amazon S3 に構築したデータレイクに拡張されます。Redshift Spectrum では、データをロードすることなく、エクサバイトの構造化および半構造化データをネイティブ形式でクエリできます。Amazon Redshift は、機械学習、巨大な並列クエリ実行、高性能ディスクのカラムナストレージを使用することで、他のデータウェアハウスデータベースよりも高速なパフォーマンスを実現します。Amazon Redshift を設定すれば、数分でスケールの拡大縮小が行えるだけでなく、コンピューティング能力を自動的に拡張して、無制限の同時実行を確実に行うことができます。 Amazon Redshift から開始し、AWS Well-Architected フレームワークの推奨ベストプラクティスに基づいて AWS リソースを設定する場合には、こちらで提供する CloudFormation テンプレートを使用できます。モジュラーアプローチでは、AWS インフラストラクチャをゼロから構築するか、既存の仮想プライベートクラウド (VPC) に Amazon Redshift をデプロイするかのいずれかを選択できます。 CloudFormation テンプレートを使用する利点 AWS CloudFormation テンプレートを使用すれば、何百にもおよぶ手動での手順を、テキストファイルにある少しの手順にまとめることが可能です。ファイル内の宣言コードは、作成するリソースの意図した状態をキャプチャし、数百の AWS […]

Read More

GoldenGate を使用したリアルタイムでの Oracle OLTP データの抽出と Amazon Athena からのクエリ

この記事では、レポート作成ワークロードをオンライントランザクション処理 (OLTP) データベースから Amazon Athena および Amazon S3 にオフロードすることによってパフォーマンスを向上させ、コストを削減できる方法について説明します。説明するアーキテクチャはレポート作成システムを実装するもので、到着時にクエリできるようにして、受け取るデータを理解することを可能にします。このソリューションでは以下が行われます。 ソース上で変更が行われるたびに、Oracle GoldenGate がターゲットに新しい行を生成し、緩やかに変化するディメンションのタイプ 2 (SCD タイプ 2) データを作成します。 Athena が SCD タイプ 2 データでのアドホッククエリの実行を可能にします。 最新のレポート作成ソリューションの原則 高度なデータベースソリューションは、コスト効率の良いレポート作成ソリューションを構築できるように原則のセットを使用します。これらの原則には以下のようなものがあります。 OLTP からレポート作成アクティビティを分離する。このアプローチは、リソースの分離を提供し、データベースがそれぞれのワークロードをスケールできるようにします。 Hadoop Distributed File System (HDFS) および Amazon S3 などのクラウドプロジェクトストアといった分散ファイルシステムの上で実行されるクエリエンジンを使用する。オープンソース HDFS とクラウドオブジェクトストアの上で実行できるクエリエンジンの到来は、専用レポート作成システムの実装コストをさらに削減します。 また、レポート作成ソリューションの構築時にはこれらの原則を使用できます。 商用データベースのライセンスコストを削減するため、レポート作成アクティビティをオープンソースデータベースに移動させる。 ソースシステムからの OLTP データをレプリケートでき (リアルタイムモードが望ましい)、データの現行ビューを提供する、ログベースでリアルタイムの変更データキャプチャ (CDC) を使用したデータ統合ソリューションシステムを使用する。ソースおよびターゲットのレポート作成システム間におけるデータレプリケーションは、CDC ソリューションを使用して有効化できます。トランザクションログベースの CDC ソリューションは、ソースデータベースから非侵襲的にデータベースの変更をキャプチャし、それらをターゲットデータストアまたはファイルシステムにレプリケートします。 前提条件 GoldenGate と Kafka を併用しており、クラウド移行を検討しているという場合は、この記事が役に立ちます。この記事では、GoldenGate に関する予備知識も前提としており、GoldenGate […]

Read More