Amazon Web Services ブログ

Amazon Elastic Block Store (EBS) はサービス開始から 10 年以上になりますが、今では AWS の土台をなすビルディングブロックとなりました。EBS では、最大 16 TiB までの保存と最大 64,000 IOPS (1 秒あたりの入出力オペレーション数) までの処理が可能な永続的ストレージボリュームを作成できます。4 種類のボリュームをデータ転送スループット、IOPS、料金の要件に合わせて選択できます。要件が変わっても、ボリュームはオンラインでアクティブなままでボリュームタイプの変更、ボリュームの拡張、パフォーマンスの変更ができます。EBS スナップショットでは、バックアップ、災害対策などの用途でボリュームの状態をキャプチャできます。作成したスナップショットは、EBS ボリュームの新規作成に使用できます。スナップショットは、耐久性の高い Amazon Simple Storage Service (S3) に保存されます。 AWS の常にクリエイティブなお客様は、EBS スナップショットをさまざまな興味深い用途に活用しています。バックアップや災害対策といったユースケース以外にも、スナップショットの用途として、本番環境から収集したデータを使用した分析用環境やテスト用環境のすばやい作成や、仮想デスクトップインターフェイス (VDI、Virtual Desktop Interface) 環境のサポートといったものがありました。ご存知と思いますが、EC2 インスタンスの起動に利用されている AMI (Amazon マシンイメージ) も、1 個または複数のスナップショットとして保存されます。 Fast Snapshot Restore 本日より、EBS の Fast Snapshot Restore (FSR) の提供を開始いたします。新規および既存のスナップショットで AZ (アベイラビリティーゾーン) ごとに有効化して、パフォーマンスを最大化する EBS […]

何十万人もの AWS のお客様が Amazon DynamoDB を活用しています。AWS は 2017 年に、DynamoDB グローバルテーブルを提供開始しました。これは、マルチリージョン、マルチマスター対応の DynamoDB テーブルを独自のレプリケーションソリューションを構築して維持する必要なくデプロイできるフルマネージド型ソリューションです。グローバルテーブルを作成するときには、テーブルを使用できるようにしたい複数の AWS リージョンを指定します。DynamoDB は、これらのリージョンに同一のテーブルを作成して、進行中のデータ変更をそれらすべてに伝播するために必要なタスクのすべてを実行します。 AWS のお客様が DynamoDB グローバルテーブルを利用する主な 2 つの理由があります。クライアントに低レイテンシーの提供と、バックアップや災害対策の円滑化です。レイテンシーとは、ネットワークに転送要求を出してから実際にデータが送られてくるまでに生じる通信の遅延時間を指します。低いレイテンシーのアプリケーションでは、高い顧客エンゲージメントと、売上拡大が見込まれます。バックエンドをユーザーに近い複数のリージョンにデプロイすると、お客様のアプリケーションのレイテンシーが下がります。別のリージョンにデータをフルコピーしておくと、きわめてまれに起こるリージョン全体の不具合の際でもトラフィックをそのリージョンに切り替えやすくなります。AWS の CTO であるWerner Vogels 博士は以前に「障害は起こるものだ。あらゆるものは時間が経てば必ず障害が生じる」と述べています。 本日より、お持ちの DynamoDB テーブルはわずか数回のクリックでグローバルテーブルに変換できるようになりました。これには、直接AWS マネジメントコンソールから操作するか、または AWS コマンドラインインターフェイス (CLI) 、Amazon DynamoDB API のいずれかを使用します。これまでグローバルテーブルに変換できるのは空のテーブルだけでした。つまり、テーブルを作成する時点で、リージョン内のテーブルの使用法を推測する必要がありました。それが今回、テーブルのグローバル化や、既存のグローバルテーブルを別のリージョンへの拡張がいつでもできるようになりました。 レプリケーションの設定中であっても、ユーザーのアプリケーションではテーブルの使用を継続できます。テーブルにリージョンを追加すると、DynamoDB では既存のテーブルのスナップショットを使用して新しいレプリカの追加を開始します。DynamoDB で新しいレプリカを構築すると同時に、アプリケーションでは既存のリージョンに対して書き込みを継続します。進行中に生じたアップデートは最終的にはすべて新しいレプリカにレプリケーションされます。 AWS コマンドラインインターフェイス (CLI) を使用して DynamoDB グローバルテーブルを作成するために、まず米国西部 (オレゴン) リージョン (us-west-2) のローカルテーブルを作成します。 aws dynamodb create-table –region us-west-2 […]

この記事は、iHeartRadio 社の Matt Fielder 氏および Jordan Rosenblum 氏からの寄稿によるものです。おふたりの言葉を借りると、「iHeartRadio は、毎月数千万人の人に配信しており、また、数万人の新規登録者を日々集めているオーディオストリーミングサービスです。」、とのことです。 パーソナライゼーションはユーザー体験の中でも重要な位置を占めています。そして当社としても、お客様の使用履歴の早い段階で、有用なレコメンデーションを提供したいと強く希望しています。音楽作品の提案をユーザー登録直後に表示することで、当社のサービスがお客様の好みに素早く対応可能であり、その中で色々と探し回る必要はそれほどないのだと伝えられます。しかし、まだ視聴をまったく開始していないユーザーに対し、どうやってコンテンツの提案をしているのか、ご関心をお持ちの方もいらっしゃるでしょう。 この記事では、当社がリアルタイムのパーソナライズサービスを実現するために、ユーザーの方が登録の際に提供してくださる情報を、いかに活用しているかを説明します。新規のお客様には音楽視聴に関する記録がまったくありませんが、通常はサービス参加の段階で、一定数の好みジャンルを選択し、ご自身についての統計学的な情報を提供してくれるものです。ここではまず、当社がパーソナライゼーションに使用している有益なパターンを含む、それらの属性の分析をお見せします。次に、そういったデータを、新規のお客様それぞれに最良の音楽を予測するため使用しているモデルについて説明しいきます。最後に、登録直後に Amazon SageMaker を使用して、推奨としてこれらの予測をリアルタイムで提供する方法を示します。これにより、A / Bテストでのユーザーエンゲージメントが大幅に向上します。 新規ユーザーの視聴パターン モデル構築を始める前に、ヒントとなり得る情報が含まれそうな特別なパターンが、データの中に存在するかを確認しておく必要があります。 最初に挙げられる仮説は、統計学的に違う背景をもつ人々は、それぞれ別のタイプの音楽を好むはずだということです。たとえば、まったく同じ環境にいたとしても、50 歳の男性は、25 歳の女性よりクラシックロックを聴く確率は高そうだといえます。仮に、平均的な意味で、このことの中に何らかの真実が存在するならば、有用なレコメンデーション作成のためにユーザーの方が視聴履歴を残すのを待つ必要はないことになります。ユーザー登録の際に提供していただく、統計的な情報を活用するだけで十分でしょう。 この点の分析を行うため、ユーザー登録から 2 か月経過した方の視聴行動に着目し、それを、同じ方から登録の時にご提供いただいた情報に照らし合わせてみることにしました。この 2 か月というギャップにより、既にコンテンツの中をいろいろ試しているアクティブなユーザーに対し確実に焦点を絞れます。この時期になれば、その方がどのような好みであるのかは、かなり明白になっていると思われます。同時に、サービス参加時やマーケティングの初期段階に存在したノイズも、すでに低減しているはずです。 次の図では、あるユーザーの方が、登録から 2 か月間にとった視聴行動についてのタイムラインを示しています。 次に、新規の男性ユーザーと新規の女性ユーザーを対比して、視聴するジャンルにおける分布を比較します。この結果から、音楽の好みには統計的情報と関連があるパターンが存在するという、先の仮説が立証できます。たとえば、スポーツやニュース、そしてトークショーなどは、男性の間でより人気があることが読み取れるでしょう。このデータは、特に視聴履歴をまだ残していないユーザーの方に対するレコメンデーションを向上でき得るものだといえます。 次に示すグラフでは、ユーザーの性別と好みのジャンルの関連性を大まかに示しています。 2 つめに挙げられる仮説は、同じ好みを持つユーザーの方達でも、探しているジャンルを違った表し方をするということです。さらにいうと、iHeartRadio ではジャンルの分類に対し、ユーザーの方々が認識しているものと比べて少し違う定義をしています。当然これは、一定のジャンルに関する 分析の 1 つの論拠となり得ます。たとえば、実際には当社内部で Hip Hop として分類しているものをお聞きの多くの方が、好みの音楽は R&B だとおっしゃることがあります。このことは、同じジャンルに対してでも、ユーザーの方はそれぞれ別の定義をしているという意味で、ジャンルとういものが持ついくぶん主観的な特性も示しています。 ジャンルの予測 さて、統計情報とジャンルの好みが、新規ユーザーの行動を予測する上で有用であるという分析的な確証がある程度得られたので、モデルの構築とテストに着手することにします。モデルには、統計的背景とジャンルの好みがいかに視聴行動と関係性があるかを、システム的に学習してくれることが期待されます。もし上手くいけば、新しいユーザー様が当社のプラットフォームのご利用を開始する際に、適切なジャンル分けでコンテンツを提示するため、そのモデルが利用できるでしょう。 分析段階においては、サインアップから 2 か月経ったユーザーの方が自然と選択するであろうコンテンツを提示できる、見本の予測方法を人間が定義します。結果に求めるのは、モデル用のトレーニングデータをご提供いただいた方が、当社のアプリのコンテンツを開くのに時間を割くような、活発なユーザー様となることです。従って、目標変数は、登録 2 か月後にユーザーの方が最も視聴するジャンルになります。また、その方の統計的な背景と登録段階で選択されたジャンルの組合せを特徴量として使用します。 今回もその開始時点では、多くのモデリング作業と同じく、最も基本的なモデリングテクニックである、マルチラベルのロジスティック回帰分析を使用します。トレーニングするモデルでの特徴係数のサンプリング結果と、次のヒートマップに示している視聴結果がそれらの値との間に持つ関連性とを分析します。統計学的ではないモデルは、ユーザーの方が登録の際に選択したジャンルに関するマルチホットエンコーディングを備えています。より明るい色 (より重みがある) のスクエアは、よりモデルの特徴量との関連性があり、これは、ユーザーが登録から 2 か月後に視聴しているジャンルと関係します。 明らかにここからは、いくつかの初期パターンを見出すことができます。1 […]

クラウド上でソフトウェアを構築すると、ログ記録用のシステムを初期の段階から簡単に実装できます。AWS CloudTrail などのツールを使用すると、AWS のアカウントおよびサービスで実行されたすべてのアクションの追跡が容易になり、変更の原因となったイベントを探し出すことができます。ただし、ログエントリがすべて役立つわけではありません。スムーズに実行されている場合のログエントリは、さながら工場で安定して響く安心感のある機械音のようなものです。しかし不具合が発生した際には、その音が邪魔になりどの機器に不具合があるのかが聞き取りにくくなります。ログデータの量が膨大になる可能性があるような大規模なソフトウェアシステムでも、同じことが言えます。その記録を精査して実用的な情報を見つけるのは骨が折れる仕事です。記録の精査には通常、多くのカスタムソフトウェアやカスタム統合が必要なため、新しいサービスが追加されたときに誤検知やアラート疲れを引き起こすおそれがあります。 そこで、ソフトウェアのオートメーションと機械学習が役立ちます。本日、すべての商用 AWS リージョンで AWS CloudTrail Insights をリリースします。CloudTrail Insights は、CloudTrail の証跡からの書き込み管理イベントを自動的に分析し、異常なアクティビティを警告します。たとえば、確立されたベースラインと異なる TerminateInstance イベントの増加があった場合、Insight イベントとして表示されます。こうしたイベントにより、異常な API アクティビティの検出とそれへの対応がこれまで以上に簡単になります。 AWS CloudTrail Insights の有効化 CloudTrail は、ユーザーアクティビティと API の使用状況を追跡します。AWS マネジメントコンソール、AWS SDK、コマンドラインツール、その他 AWS のサービスを通じて実行されたアクションを含む、AWS アカウントアクティビティのイベント履歴が提供されます。AWS CloudTrail Insights を起動すると、これらのログの異常なアクティビティを検出する機械学習モデルが、数回クリックするだけで有効になります。AWS CloudTrail Insights は、過去の API コールを分析し、使用パターンを識別し、異常なアクティビティの Insight イベントを生成します。 put-insight-selectors コマンドを使用して、AWS コマンドラインインターフェイス (CLI) から証跡に対する Insights を有効にすることもできます。 $ aws cloudtrail put-insight-selectors –trail-name trail_name […]

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 この週刊AWSは、一週間のAWSでの新発表や新サービスについて厳選してコンパクトにまとめる…というのがコンセプトなのですが、先週は厳選してもコンパクトならない量の発表がありました。AWS Storage Dayと銘打ってストレージサービス周りの発表が一度に行われたりもしましたね。 そういうわけで、今回は”特大号”でお届けします。早速先週の主なアップデートについて振り返っていきましょう。

みなさんこんにちは！アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 11月21日に「ビルシリーズ@六本木一丁目住友不動産六本木グランドタワー 第１回」を開催いたしました。今回は「初めてのサーバレスWebアプリケーションハンズオン」を実施しました。こちら「ビルシリーズとは？」とお思いの方も多いかと思いますので、開催報告と合わせてご説明いたします。 「ビルシリーズ」とは？ このイベントは、日頃AWSをご利用いただいているお客様に、AWSからの情報発信はもちろん、同じビルに拠点を構えるお客様同士の活発な意見交換と交流の場を定期的に作ることを目的としたものです（同じビルなので移動が楽！）。 今回、住友不動産六本木グランドタワーのFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、このようなビル単位でのイベントを開催する運びとなりました。場所はFringe81様の素敵な大会場をお借りいたしました。Fringe81様ありがとうございました。 来月には住友不動産麻布十番ビルでも開催を予定しており、今後もこのようなビル単位で交流ができるようなイベントを開催していきたいと考えております。 当日の様子 当日は約40人のお客様にお越しいただき、イベントは終始盛り上がりを見せておりました。   まずはAWSJ 植本より、今回のビルシリーズの趣旨などを説明いたしました。   次に、AWSJ 木村より「サーバレスのご紹介 – ユースケースパターンを切り口に」というタイトルで、AWSのサーバレスプラットフォームについてご紹介いたしました。   続けてAWSJ 木村より「初めてのWebアプリケーションハンズオン」を実施いたしました。   ハンズオンの終了後、ご参加いただいた皆様と共に、簡単な懇親会を開催いたしました。   今回、AWSJより、アカウントマネージャー植本、藤田、細木、ソリューションアーキテクト上原、石見、小宮、木村がビルシリーズをサポートいたしました。こちらはソリューションアーキテクトの集合写真です。 貴社担当のアカウントマネージャから「ビルシリーズ」のお誘いがあるかもしれませんが、是非ご検討いただければと思います。それでは、次回のビルシリーズでお会いしましょう！   著者について 木村 公哉（Kimura, Koya） 香川県出身のソリューションアーキテクトです。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。   上原 誠（Uehara, Makoto） アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

AWS AppSyncはGraphQLのマネージドサービスで、単一または複数のデータソースのデータに安全にアクセスしたり、操作したり、結合するための柔軟なAPIを作成でき、アプリケーション開発をシンプルにすることができます。多くの場合、異なったデータソースは異なったユースケースに合わせて最適化され、データが配信されるスピードも異なっていることでしょう。その基になるGraphQLスキーマで定義されているデータフィールドもかなり多様です。

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング シニアエバンジェリストの亀田です。先日公開した第一弾はいかがでしたでしょうか。今日は第二弾、11月20日から11月21日（米国時間基準）分をお届けします。 11月20日 AWS Lambdaが、イベントソースとしてAmazon SQS FIFOキューをサポートしました Amazon SQSは、分散ソフトウェアコンポーネントとマイクロサービス間で確実に通信するための完全に管理されたメッセージキューサービスであり、SQS標準キューとSQS FIFOキューの2つをサポートします。FIFOキューは、標準キューを改良および補完し、メッセージが送受信される正確な順序を保持することが可能な、単一のキュー内で複数の順序付けされたメッセージグループを許可するメッセージグループをサポートします。 このアップデートにより、処理の順序は、メッセージグループ内のメッセージの順序に従うようになります。 AWS Storage Gatewayは、VMware上のHA構成をサポートし、新しいパフォーマンス監視メトリックスを追加しました VMware vSphere High Availability（VMware HA）と統合された一連のヘルスチェックを通じてVMware上で高可用性が提供するようになりました。この機能強化により、オンプレミスのVMware環境またはAWS上のVMware CloudにデプロイされたStorage Gatewayは、60秒以内にほとんどのサービス中断から自動的に回復します。ストレージゲートウェイ管理コンソールに埋め込まれたAmazon CloudWatchレポートにより、キャッシュ使用率、ゲートウェイアクセスパターン、スループットとI / Oメトリックスを継続的に可視化できるようになり、割り当てられたストレージ、コンピューティング、ネットワークリソースをより簡単に最適化できるようになりました Amazon RDS for Oracleは、sqlnet.oraパラメーターのALLOWED_LOGON_VERSION_SERVERおよびALLOWED_LOGON_VERSION_CLIENTをサポートしました SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメーターを使用して、Oracle DBインスタンス用にAmazon RDSに接続するときに許可される最小認証プロトコルを設定し、SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメーターを使用して、クライアントに許可される最小認証プロトコルを設定することができます。 AWS Config Conformance Packがリリースされました Conformance Packは、共通のフレームワークとパッケージモデルを使用して、ポリシー定義から監査および集計レポートに至るまで、AWSリソースの構成コンプライアンスを大規模に管理するのに役立ちます。AWS Organizationsと統合され、AWS Configルールと修復アクションのコレクションをパッケージ化して、組織全体で単一のエンティティとして一緒にデプロイできます。Conformance Packは、AWS Configルール（管理またはカスタム）および修復アクションのリストを含むYAMLテンプレートを作成することにより作成できます。こちらのサンプルテンプレートをご覧ください。 AWS Configがサードパーティリソースをサポートしました 新しいAPIを使用して、GitHubリポジトリ、Microsoft Active Directoryリソース、またはオンプレミスサーバーなどのサードパーティリソースの構成をAWS Configに公開できるようになりました。この設定データがAWS Configに公開された後、AWS ConfigコンソールとAPIを使用してリソースインベントリと設定履歴を表示および監視できます。AWS Config rulesまたはConformance Packsを作成して、これらのサードパーティリソースをベストプラクティス、内部ポリシー、および規制ポリシーに対して評価することもできます。これにより、AWS […]

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング シニアエバンジェリストの亀田です。 12月2日から6日にかけて米国ネバダ州ラスベガスで開催されるre:Invent 2019がいよいよ近づいてきています。 例年通り、re:Invent が始まる前に非常に多くのアップデートが毎日発表されています。その量が多く、また一部日本語化がされていないことなどから整理が大変だということを多くのお客様から頂いており、昨年同様2019年11月15日以降の発表分を一覧表形式にて日本語でまとめて行きたいと思います。 今回は11月15日から11月19日（米国時間基準）分です。 11月15日 Amazon Redshift がインスタンスをまたいだリストアに対応しました 異なるサイズまたは実行中の異なるノードタイプのクラスターに Redshift スナップショットを復元できるようになりました。これにより、スナップショットの復元ワークフローが簡素化されます。 Amazon SNS にデッドレターキュー (DLQ) をサポートしました Amazon Simple Notification Service (SNS) のサブスクリプションにデッドレターキュー (DLQ) を設定して、未送信のメッセージをキャプチャできることになりました。これにより、サブスクリプションがエンドポイントに届かない場合にメッセージを保存しておけるため、アプリケーションの復元性と耐久性が向上します。 Amazon Redshift でデータウェアハウスの管理とモニタリングを改善する新しいコンソールが発表 新しい Redshift コンソールの新しいモニタリングダッシュボードでは、可用性ステータス、クラスターとクエリのパフォーマンス、イベント、アラームなどのすべての関連情報を統合することにより、管理者はすべての Redshift クラスターを単一ページから簡単に監視できます。これにより、管理者はワークロードに関連するアクティビティを速やかに把握することができます。 Amazon WorkSpaces が WorkSpaces Directory API をリリースしました Amazon WorkSpaces API を使用して、ディレクトリを WorkSpaces に登録し、ディレクトリの詳細を変更できるようになりました。新しい API を使用すると、WorkSpaces にディレクトリを登録するか、デフォルトの ワークスペース 作成設定、セルフサービスのアクセス許可、アクセスコントロールなどのディレクトリレベルの […]

先日 (2019/11/14) 開催しました AWS Black Belt Online Seminar「 AWS Transit Gateway 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20191113 AWS Black Belt Online Seminar AWS Transit Gateway   AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. TGW を使う場合、DXGW も一緒に使う必要がありますか？TGW のみでも利用できるのでしょうか？ A. Direct Connect を使う場合は、DXGW を一緒に使う必要があります。構成については、こちらをご参照ください Q. VPC をアタッチするときに指定するサブネットをアタッチ専用のサブネットとする必要性について、もう少し具体例を挙げて説明していただきたいです。そのサブネットの内部のEC2 インスタンスのルーティングに影響あるとのことでしたが、どのような影響があるのか？などを教えていただきたいです。 A. Transit Gateway (TGW) のアタッチメントがついているサブネットと同一のサブネットに EC2 インスタンスが存在する場合に、その EC2 インスタンスはTGWと同じルーティングテーブルを参照します。 例えば　インライン監査用の VPC の TGW の ENI […]