Amazon Web Services ブログ

Amazon EFS 低頻度アクセスの料金値下げで、ストレージ費用を最適化

 本日、Amazon Elastic File System の低頻度アクセス (IA) のライフサイクル管理を使用した AWS クラウド史上最大の値下げが発表されました。今回の値下げにより、コストをこれまで以上に最適化し、ユーザーのアクセスパターンの変化に応じてファイルストレージコストを最大で 92% まで自動的に削減できるようになります。この値下げにより、月額 GB あたり 0.08 USD の料金で、ファイルをファイルシステムにネイティブに保存し、アクセスできるようになります。詳細は本記事の後半で紹介します。 Amazon Elastic File System (EFS) は、Linux ベースのワークロード用向けの低コストで使いやすいクラウドネイティブなフルマネージド型 NFS ファイルシステムで、AWS のサービスやオンプレミスのリソースでも使用できます。EFS は、ファイルを作成または削除するたびにペタバイト規模まで自動的に拡大または縮小する伸縮自在なストレージを提供します。中断は発生しません。アプリケーションは、必要とするストレージをいつでもすぐに使用できます。さらに EFS には、追加設定の不要なマルチ AZ アベイラビリティーと耐久性が (無償で) 含まれ、ファイルシステムの堅牢な整合性とともに利用できます。 ライフサイクル管理を使ってコストを簡単に最適化 特定のアプリケーションでは、ストレージが増加すると、すべてのファイルに常時アクセスする必要がなくなり、アクセスパターンも時間を経て変わっていきます。 IDC のような業界の専門家の分析や、使用パターンに関する当社独自の分析から、データの約 80% はアクセス頻度が低いことが確認されています。アクティブに使用されているのは残りの 20% です。アプリケーションをクラウドへ移行する際の一般的な 2 つの要因として、運用効率の最大化と総所有コストの削減が挙げられます。このことはストレージのコストにも同じことが言えます。すべてのデータを手元で実行速度が最速のストレージに保存するよりも、アクセス頻度の低いデータは異なるクラス/ティアのストレージに移行させて、関連コストを低減して利用するほうが合理的です。 こうしたデータを手動で探すのは面倒な作業です。したがって、アクセスを経時的にモニタリングし、ストレージティア間のデータ移動を自動的に実行するシステムがあればなお理想的です。繰り返しになりますが、実行中のアプリケーションで中断が発生することはありません。 EFS 低頻度アクセス (IA) のライフサイクル管理は、定期アクセスの不要なファイル向けに、使いやすい、コスト最適化された料金/パフォーマンスティアを提供します。本日発表された新たな値下げにより、ビルダーはファイルストレージのコストを EFS 標準ストレージクラスと比べて最大 92% まで削減できるようになります。 EFS ライフサイクル管理は、簡単に有効化でき、バックグラウンドで自動的に実行します。ファイルシステムで有効化すると、選択したライフサイクルポリシーに従わないファイルは、コスト最適化された EFS IA ストレージクラスに自動的に移動します。この移動は、アプリケーションに対して透過的に行われます。 […]

Read More

Amazon S3 オブジェクトロックによるデータの保護

Amazon S3 オブジェクトロックは、「Write Once Read Many」(WORM)モデルを使用したオブジェクトの保存を可能にする Amazon S3 の機能です。WORM による保護は、データが書き込まれた後変更または削除されないことが必須のシナリオに対して使用できます。ビジネスで財務またはヘルスケアの分野のコンプライアンス規制を満たすことが求められているか、後で行われる監査と調整のためにビジネス記録を最高の状態に整えておきたい場合でも、S3 オブジェクトロックはぴったりのツールです。 S3 オブジェクトロックは、Cohasset Associates により、SEC Rule 17a-4(f)、FINRA Rule 4511 および CFTC Regulation 1.31 により評価されています。Cohasset Associates Assessment report のコピーをダウンロードすることができます。その後、規制データに対して Amazon S3 を使用することを規制当局に通知するとき、規制当局に評価レポートを提供することができます。 この機能の使用に関する追加料金はありませんので、先に進み、S3 のオブジェクトに保持期間の日付をいくつか追加することができます。 S3 オブジェクトロックを使用するカスタマー 多くの AWS カスタマーが今日、AWS WORM ストレージ機能 (S3 Glacier ボールトロックおよび S3 オブジェクトロック) を使用しています。規制対象のブローカー-ディーラーは、AWS の WORM 機能を使用して米国証券取引委員会(SEC)および金融業界規制局(FINRA) の規則に従っています。 多くの AWS カスタマーは、情報が不可欠の会社資産であることを認め、貴重なデータの不変性と強力な制御を好みます。S3 オブジェクトロックは、このようなカスタマーに不変なストレージと削除からの保護を提供します。 Amazon […]

Read More

Amazon SageMaker Ground Truth を使ってプライベートのラベル付けチームのスループットを追跡

AWS re:Invent 2018 において発表された Amazon SageMaker Ground Truth は、機械学習モデル向けの高精度なトレーニングデータセットをすばやく構築することを可能にするサービスです。Amazon SageMaker Ground Truth を使うと、パブリックおよびプライベートのラベル付け作業者に簡単にアクセスしたり、そうした作業者に対して一般的なラベル付けタスクに使用できる組み込みのワークフローとインターフェイスを提供したりすることができます。さらに Amazon SageMaker Ground Truth は、自動ラベル付けによってラベル付けのコストを最大 70% 削減します。自動ラベル付けを機能させるには、人間がラベル付けしたデータを使用して Ground Truth をトレーニングし、サービスに自立的にデータのラベル付けを学習させます。 プライベートの作業者にデータのラベル付けを行わせるときは、そのスループットと効率を測定および追跡したいとお考えでしょう。Amazon SageMaker Ground Truth では、作業者のイベント (ラベル付け作業者によるタスクの開始時刻、送信時刻など) を Amazon CloudWatch に記録できるようになりました。さらに、CloudWatch に組み込まれたメトリクス機能を使って、作業チーム全体または個々の作業者のスループットを測定および追跡することも可能になりました。このブログ記事では、作業者イベントの raw ログと組み込みのメトリクスを、お使いの AWS アカウントで使用する方法について解説していきます。 作業者アクティビティログの使い方 Amazon SageMaker Ground Truth を使ってプライベートの作業者チームをセットアップし、ラベル付けジョブを実行すると、作業者のアクティビティログが CloudWatch に自動的に生成されます。プライベートチームのセットアップ方法と最初のラベル付けジョブの開始方法については、こちらの開始方法に関するブログ記事を参照してください。注: 過去にプライベート作業チームを作成したことがある場合は、新しいプライベート作業チームを作成し、作業チームと CloudWatch の間に信頼されたアクセス許可をセットアップする必要があります。このプライベート作業チームを使用する必要はなく、セットアップのステップは 1 回限りのものとなります。 ログを閲覧するには、CloudWatch コンソールにアクセスし、左側のパネルで [ログ] をクリックします。/aws/sagemaker/groundtruth/WorkerActivity […]

Read More

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 from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. サブネットグループで、AZを2つだけグルーピングしていた場合でも、ストレージ(データ)は、3つのAZに書込みされるのでしょうか? A. はい。サブネットグループの設定に関わらず、Amazon Aurora は自動的に 3 つのアベイラビリティーゾーンにかけて 6 個のデータコピーを保持します。サブネットグループには、プライマリインスタンス(Writer), Aurora レプリカ(Reader)を配置するために利用します。 Q. リードレプリカについては、追加インスタンス毎に、インスタンスタイプを変えることは可能という認識であっていますか? A. はい。ご認識の通り可能です。ただし、プライマリインスタンスとリードレプリカは同じインスタンスクラスを利用することを推奨しています。レプリカの追加方法についてはこちらのドキュメントをご確認ください。 Q. RDS for PostgreSQL を選択するメリットは、どういうものがあるでしょうか? A. […]

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