Author: AWS Japan Staff


CloudTrail の更新 – Amazon S3 オブジェクトレベルの API アクティビティのキャプチャと処理

AWS の複数のサービスを組み合わせることで、多くのお客様が直面している問題に対処できることを示したいと思います。ここでは、本日発表される新しい AWS CloudTrail 機能を紹介し、この機能を CloudWatch イベントと合わせて使う方法について説明します。

課題
お客様はさまざまな種類のミッションクリティカルなデータを Amazon Simple Storage Service (S3) に保存しており、これらのデータに対するオブジェクトレベルのアクティビティを追跡できることを望んでいます。S3 アクセスログには、アクティビティの一部がキャプチャされて保存されますが、その詳細レベルは限定的でログ配信に何時間もかかる場合があります。お客様は、より充実した詳細とタイムリーな配信を求めています。金融サービスなどの規制業界では特にそうです。たとえば、特定の IAM ユーザーが S3 バケットの特定箇所に保存されている機密情報にアクセスした時間を確認したいというような要望があります。このようなお客様のニーズを満たすために、S3 オブジェクトに対するオブジェクトレベルのアクティビティをキャプチャする機能を CloudTrail に追加します。この機能はデータイベントと呼ばれます (CloudTrail の元のイベントは今後、管理イベントと呼びます)。データイベントは、”読み取り” オペレーション (GETHEADGet Object ACL など) と “書き込み” オペレーション (PUTPOST など) で構成されます。これらのオペレーションでキャプチャされる詳細のレベルは、セキュリティ、監査、ガバナンス、コンプライアンスのさまざまなユースケースに対応するよう意図されています。たとえば、この詳細のレベルに基づいて、個人識別情報 (PII) 用に新しいアップロードされたデータのスキャン、保護されたバケット内のデータに対するアクセス試行の監査、適切なアクセスポリシーが適用されていることの確認ができます。

オブジェクトレベルの API アクティビティの処理
以上のすべてを考慮して、選択されたバケット内のオブジェクトやバケット内の選択されたフォルダーに対して S3 オペレーションが実行されるたびに、それをカスタムアクションで処理する Lambda 関数を簡単に設定できます。この投稿に着手する前に、jbarr-s3-trail という新しい CloudTrail 追跡を作成しておきました。

この追跡を使用して、S3 バケットの 1 つ (jbarr-s3-trail-demo) に対するオブジェクトレベルのアクティビティを記録することにします。そのためには、この追跡にイベントセレクターを追加する必要があります。このセレクターは S3 専用であり、対象のイベントに集中してログを記録できます。イベントセレクターは CloudTrail の新しい機能です。本日、発表の一部として紹介されますのでご注目ください。読み取りイベントと書き込みイベントの両方を記録することにして、対象のバケットを指定します。プレフィックスを指定することでバケットの一部のみを対象としてイベントを記録したり、複数のバケットを対象としてイベントを記録したりできます。また、管理イベントのログ記録を設定することもできます。

CloudTrail では、追跡ごとに最大 5 つまでイベントセレクターを追加できます。各イベントセレクターは、最大 50 個の S3 バケットとオプションのバケットプレフィックスを指定できます。これを設定し、バケットを S3 コンソールで開き、ファイルをアップロードして、追跡内のエントリの 1 つを確認してみます。以下のようになりました。

{
"eventVersion": "1.05",
"userIdentity": {
"type": "Root",
"principalId": "99999999999",
"arn": "arn:aws:iam::99999999999:root",
"accountId": "99999999999",
"username": "jbarr",
"sessionContext": {
"attributes": {
"creationDate": "2016-11-15T17:55:17Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2016-11-15T23:02:12Z",
"eventSource": "s3.amazonaws.com",
"eventName": "PutObject",
"awsRegion": "us-east-1",
"sourceIPAddress": "72.21.196.67",
"userAgent": "[S3Console/0.4]",
"requestParameters": {
"X-Amz-Date": "20161115T230211Z",
"bucketName": "jbarr-s3-trail-demo",
"X-Amz-Algorithm": "AWS4-HMAC-SHA256",
"storageClass": "STANDARD",
"cannedAcl": "private",
"X-Amz-SignedHeaders": "Content-Type;Host;x-amz-acl;x-amz-storage-class",
"X-Amz-Expires": "300",
"key": "ie_sb_device_4.png"
}

次に、シンプルな Lambda 関数を作成します。

さらに、この関数の名前 (PutObject) に対応する CloudWatch Events ルールを作成し、Lambda 関数 (S3Watcher) を呼び出します。

いくつかのファイルをバケットにアップロードし、Lambda 関数が正常に呼び出されていることを確認します。

Lambda 関数の出力を含む CloudWatch エントリを確認することもできます。

料金と提供地域
データイベントは指定した S3 バケットについてのみ記録され、0.10 USD/100,000 イベントの料金になります。この機能は、すべての商用の AWS リージョンで使用できます。

Jeff;

Redshiftアップデート:列や表の名前に日本語が使用できるように

Amazon Redshift で列や表、もしくはビューといったオブジェクトの名前として日本語が利用可能になりました!これは以前から日本のお客様からご要望いただいていた機能ですので、以下で説明します。

Redshiftはこれまではデータとしては日本語を含むマルチバイト文字を格納可能でしたが、表や列の名前には使用できませんでした。これが改善され、Redshift v1.0.1122からは日本語のテーブル名や列名が利用可能になります。利用する前にご自身のRedshiftクラスターが1.0.1122以降に更新されているかをご確認ください。

列や表の名前は最大で127バイトまで利用でき、文字はUTF-8で保存されます(日本語の漢字やひらがなは1文字を表現するのに3バイト必要です)。以下のドキュメントも更新されています。現時点では日本語翻訳はまだ更新されていないので、英語に切り替えてご覧ください。

なおマルチバイト文字のテーブル名や列名を使用する場合は、RedshiftのJDBCドライバー 1.2.1以降、ODBCドライバー 1.3.1以降にアップデートする必要がある事に注意してください。どちらもRedshiftのマネジメントコンソールから、もしくは以下のリンクよりダウンロードが可能です(こちらも英語にしてご覧ください)。名前のマルチバイト対応だけでなく、バグフィックスや機能向上を含みますのでぜひこの機会にドライバを最新に更新して御利用ください。

RedshiftはPostgreSQLとの互換性がありますので、既存のPostgreSQLのJDBC/ODBCドライバやpsqlコマンドでの接続も可能です。パフォーマンスや機能の面から上記のRedshift専用ドライバの利用が強く推奨されますが、試しに手元の環境でpsqlコマンドでRedshift v1.0.1122に接続してみたところ、問題なく日本語のテーブル名や列名が利用できました。

下佐粉 昭(@simosako

Human Longevity, Inc. – ゲノム研究で医療を変える ゲノム研究の先端をリードする

Human Longevity, Inc. (HLI) は予防衛生を支持する上で、ヒトゲノムおよび関連性を持つ表現型データや臨床データを蓄える世界最大のデータベースを構築したいと考えています。今回のゲスト投稿では、Yaron Turpaz 氏と Bryan Coon 氏、Ashley Van Zeeland 氏が医学に大きな変化をもたらす努力の一端として生成している大量のデータを保存するため、どのように AWS を使用しているのか語ります。

Jeff;


2013 年に Human Longevity, Inc. を設立した当時から、前途に待ち受ける挑戦を認識していました。ゲノムには生命体を形成し維持する上で必要なすべての情報が詰まっています。ヒトにおいては、30 億もの DNA ベースのペアを含むゲノム全体のコピーが核を持つ全細胞に含まれています。我々の目的は 100 万のゲノムを配列し、その情報と関連付けた健康記録や疾病リスクを研究者や医師に提供することです。研究者や医師はデータを解釈して的を絞った個人の健康管理プランや、癌やその他の深刻な健康リスクにおいて最適な治療を従来より遥かにすばやく提供することができます。従来のように症状が出始めてから医師にかかり、病気を診断されてから治療を始めるモデルではなく、予防衛生やリスク予防を発展させることで医療を変えることが我々の目的です。大規模なコンピューティングを開発し適用、ゲノム研究に機械学習を使用するには Illumina のような企業が提供する DNA 配列技術による大量なデータの収集、分析、保存が必要になります。1 つのゲノムからの生データは約 100 ギガバイトを消耗します。注釈や表現型のソースや分析を含むゲノム情報を調整し、健康上の情報を分析するに伴ってこの数字は上昇します。我々が選ぶコンピューティングとストレージ技術が当社の成功に直接影響することは初めから理解していました。ですから、クラウドを使用することは明らかに最適な選択でした。当社はゲノミクスを専門としているので、IT インフラストラクチャの構築や維持にリソースを使用することは希望していません。そこで、プラットフォームの広さや当社が必要とする優れたスケーラビリティ、そしてビッグデータで展開した専門知識を備えている AWS を選ぶことにしました。また、AWS によるイノベーションのペースも考慮しました。利用者のために可能な限りコストを抑える AWS の手の込んだ策略も、当社のビジョンを実現する上で非常に大切なポイントだと考えました。

広範囲にわたる AWS サービスの活用

 スペクトルの核型分析 / 画像提供: Human Longevity, Inc.

スペクトルの核型分析 / 画像提供: Human Longevity, Inc.

現在、当社では広範な AWS サービスを使用して様々な種類のコンピューティングタスクやストレージタスクを行っています。たとえば HLI のナレッジベースは Amazon S3 ストレージと多数の Amazon EC2 ノードで構成される分散システムインフラストラクチャを活用しています。これにより、当社がリソースの分離やスケーラビリティ、迅速なプロビジョニング、ペタバイトスケールのデータベースクエリや動的なコホートビルダーに対し、ほぼリアルタイムの応答時間を可能にすることができました。AWS サービスの柔軟性により、当社のカスタマイズした Amazon Machine Image や事前構築の BTRFS 分割した Amazon EBS ボリュームで起動時間を数分ではなく数秒にすることもできました。当社が必要とする規模でデータレイクに対し Spark クエリを実行する場合には Amazon EMR を使用しています。AWS 関数は Amazon S3 イベントに接続したり、アプリと連携したり、すでに対応済みのビジネスロジックを含むコードをドロップするのに優れたツールです。当社はデマンドベースの Auto Scaling を使用し、Docker パイプラインの管理には AWS OpsWorks を使用しています。We also leverage the cost controls provided by Amazon EC2 スポットやリザーブドインスタンスタイプが提供するコスト管理も使用しています。当初はオンデマンドインスタンスを使用していましたが、コスト面で負担が急増しました。スポットインスタンスやリザーブドインスタンスでは、特定のニーズやワークフローに基づいてコンピューティングリソースを割り当てることができます。AWS サービスの柔軟性により、Apache Mesos が提供するリソース管理サービスを介して Docker サイズのコンテナをフル活用することも可能です。永続的およびスポット抽象化レイヤーにある何百もの Amazon EC2 の動的ノードは、使用量の需要や AWS 料金の最新情報に合わせてスケールアップしたりスケールダウンするよう、動的に調整されています。この動的にスケールされるコンピューティングクラスターと当社のナレッジベースサービスや社内のゲノミクスおよび腫瘍のコンピューティングパイプラインを共有することで多大な節約を実現しています。この柔軟性のおかげで、当社が必要とする処理能力を利用しながらコストを抑えることが可能になっています。こうした選択により、オンデマンドモデルを使用していた時に比べコンピューティングに掛かる費用を 50% 削減することができました。また、当社は AWS プロフェッショナルサービスを利用して特定のハードデータストレージにおけるチャレンジにも取り組みました。当社は Amazon S3 バケットに何百ものゲノミクスデータを保存しています。その多くはペタバイトレベルで何十億ものオブジェクトを含んでいます。中には未使用または 1 度か 2 度使用し再使用することのない何十億ものオブジェクトがあります。何十億というオブジェクトの中から 1 つを見つけることは大変なタスクです。Amazon S3 の頻繁にアクセスしないストレージクラスに当てはまるファイルやファイル形式がどれか識別する場合にさらなる負荷が掛かってしまいます。そうした状況でプロフェッショナルサービスは Amazon S3 オブジェクトのインデックス作成をソリューションとして提供し、当社の時間とコスト節約を可能にしました。

スピードの上昇とコスト削減
遺伝子配列とクラウドコンピューティングという 2 つの重要なテクノロジーの変曲点において、当社はタイミング良く AWS を選ぶことができました。つい最近まで、1 つのゲノム配列には 1 年間と約 1 億ドルの費用が掛かっていました。今では 1 つのゲノム配列に 3 日と数百ドルのコストが掛かる程度です。スピードとコスト低下の劇的な改善、可視化と分析ツールの急速な進展により、ほぼリアルタイムで大量のデータを収集し分析することが可能になりました。従来は何か月、何年と掛かっていたプロセスも、今ではユーザーがデータに基づく疾患性の検証を数日あるいは数時間で行うことができるようになりました。最終的には、これが患者の利益になるのです。当社のビジネスには HLI Health Nucleus があります。これはホールゲノム配列分析、高度な臨床画像、機械学習、収集し要約した個人の医療情報を使用し、ゲノミクスを利用する臨床研究プログラムで個人の健康の全体像を表す情報を提供します。当社では、これにより医師が病を識別し治療や予防を劇的に向上させ、患者の長期生存とより健康的なライフスタイルを可能にできると考えています。– Yaron Turpaz (最高情報責任者)、Bryan Coon (エンタープライズサービス部長)、Ashley Van Zeeland (最高技術責任者)

詳細
AWS が クラウドでゲノミクスをサポートする方法やゲノミクスのイノベータ―である Illumina が AWS を使用して遺伝子配列のスピードを促進しコスト効率を高めている方法をご覧ください。

AWS Lambda の新機能 – 環境変数とサーバーレスアプリケーションモデル (SAM)

AWS Lambda とサーバーレスアプリケーション開発をめぐる興奮のとりこになっています。過去 1〜2 年間に週刊 AWS で、多くのサーバーレスの成功事例、ツール、オープンソースプロジェクトを紹介しました。今回は Lambda に追加された重要な機能として、環境変数と新しいサーバーレスアプリケーションモデルについて説明します。

環境変数
開発者なら、だれでも複数の環境で利用できるコードを構築したいと思います。コードを簡単に再利用するには、実行時に設定値を受け入れられるように構築する必要があります。設定値とは、コードの環境をカスタマイズするためのテーブル名、デバイス名、ファイルパスなどです。たとえば、多くのプロジェクトは開発環境、テスト環境、本稼働環境ごとに設定が異なります。Lambda 関数に環境変数を指定できるようになりました。これでコードを変更または再デプロイすることなく設定の変更が可能になり、これまで以上にサーバーレスアプリケーション開発が効率化されます。各環境変数はキーと値のペアです。キーと値は AWS Key Management Service (KMS) で暗号化され、必要に応じて復号されます。関数あたりの環境変数の数には制限がありませんが、合計サイズは 4 KB を超えることができません。 Lambda 関数を新規作成する場合は、同時に環境変数も設定します。最新バージョンの関数の値は変更できますが、以前のバージョンの値は変更できません。次の例では、シンプルな Python 関数を作成して、いくつかの環境変数を設定し、その環境変数をコードから参照しています (このために os ライブラリをインポートする必要がありました)。

Lambda に用意されているデフォルトのサービスキーを使えば、この機能を使用しても料金はかかりません (独自のキーを使用する場合は、リクエストあたりの KMS の通常料金が適用されます)。この新しい機能の詳細とさまざまな活用方法については、AWS Compute Blog で「サーバーレスアプリケーションを簡素化する Lambda 環境変数」を参照してください。

AWS サーバーレスアプリケーションモデル
サーバーレスアプリケーションを構築するために、Lambda 関数、Amazon API Gateway リソース、Amazon DynamoDB テーブルを併用する場合があります。新しい AWS サーバーレスアプリケーションモデル (AWS SAM) を使うと、これらのすべてのコンポーネントを、AWS CloudFormation でネイティブにサポートされている簡略化された構文で記述できます。この構文を使用するには、CloudFormation テンプレートに次のような Transform セクション (CloudFormation の新しい要素) が含まれている必要があります。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

テンプレートの他のセクションでは、Lambda 関数、API Gateway のエンドポイントとリソース、DynamoDB テーブルを指定します。各関数宣言では、ハンドラー、ランタイム、および関数のコードが含まれている ZIP ファイルへの URI を指定します。API は、イベントを定義して暗黙的に宣言するか、Swagger ファイルを指定して明示的に宣言することができます。DynamoDB テーブルは、テーブル名、プライマリキー (名前とタイプ)、プロビジョニングされたスループットのみが必要な簡略化された構文を使用して宣言します。必要に応じてすべてのオプションを使用することもできます。これで、Lambda コンソールで新しい Export オペレーションを使用し、Lambda 関数の AWS SAM ファイルとデプロイパッケージを生成できるようになりました。[Actions] メニューをクリックして、[Export function] を選択します。

次に、[Download AWS SAM file] または [Download deployment package] をクリックします。

私の関数の AWS SAM ファイルは次のとおりです。

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: A starter AWS Lambda function.
Resources:
  ShowEnv:
    Type: 'AWS::Serverless::Function'
    Properties:
      Handler: lambda_function.lambda_handler
      Runtime: python2.7
      CodeUri: .
      Description: A starter AWS Lambda function.
      MemorySize: 128
      Timeout: 3
      Role: 'arn:aws:iam::99999999999:role/LambdaGeneralRole'

デプロイパッケージは ZIP ファイルで、関数のコードが含まれています。このファイルを S3 にアップロードし、SAM ファイルの CodeUri を更新してサーバーレスアプリケーションの一部として使えるようにします。これは手動で行うことも、新しい CLI コマンドのペア (aws cloudformation packageaws cloudformation deploy) を使って自動化することもできます。このオプションの詳細については、新しい記事「簡略化されたサーバーレスアプリケーションの管理とデプロイの概要」で「サーバーレスアプリのデプロイ」セクションを参照してください。Lambda 関数の設計図をエクスポートすることもできます。コーナーにあるダウンロードリンクをクリックします。

次に、[Download blueprint] をクリックします。

ZIP ファイルには、AWS SAM ファイルとコードが含まれています。

この新しい仕様の詳細と実際の使い方については、AWS Compute Blog で「簡略化されたサーバーレスアプリケーションの管理とデプロイの概要」を参照してください。

Jeff;

Web Access for Amazon WorkSpaces

2013 年後半に WorkSpaces を発表しました (Amazon WorkSpaces – クラウド内でのデスクトップコンピューティング)。以後、これまでに新しい機能が次々と追加されています。2016 年のハイライトをいくつか以下に紹介します。

今回、以上のリストに新しく Amazon WorkSpaces Web Access が追加されます。WorkSpace は、Windows、Mac OS X、または Linux で実行している最新バージョンの Chrome または Firefox からアクセスできるようになりました。これにより、制限の厳しいネットワークや WorkSpaces クライアントが使用できない状況でも生産性を発揮できます。ダウンロードやインストールは一切必要ありません。共有のコンピューターから利用してもプライベートなデータやキャッシュされたデータが残ることもありません。Amazon WorkSpaces Web Access を使用するには、サポートされているブラウザーから登録ページにアクセスし、WorkSpace の登録コードを入力します。 次にユーザー名とパスワードでログインします。

それだけで利用できます (この例は WorkSpaces で実行している IE と Firefox を Chrome で表示しています)。

この機能は、バリュー、スタンダード、パフォーマンスの各バンドルまたは Plus バンドルを実行しているすべての新しい WorkSpaces で利用できます。管理者に有効にしてもらうだけで、追加料金なしでアクセスできます。

Web Access を有効に活用するには、既存の WorkSpaces を再構築し、カスタムイメージを更新する必要があります。

Jeff;

Amazon CloudWatch 更新 – パーセンタイル統計およびダッシュボードの新ウィジェット

最近は Amazon CloudWatch 関連の動きが非常に活発です!今月前半には、メトリクスから関連するログへ移動する方法をご紹介し、またメトリックス保存期間の延長とユーザーインターフェイスの更新についてお知らせしました。本日、CloudWatch は再び改良され、パーセンタイル統計および 2 つの新しいダッシュボードウィジェットが追加されました。AWS re:Invent のおかげで時間がほとんどないため、簡潔に説明します。

パーセンタイル統計
ウェブサイトやクラウドアプリケーションを大規模に実行する場合、必要なレベルのパフォーマンスをお客様の大多数にお届けできていることを確認する必要があります。数字で平均を確認することも大切ですが、全体像が分かりにくい場合もあります。平均値によってパフォーマンスの異常値が隠れてしまうことがあり、たとえば、お客様の 1% に不便をおかけしていることがわからない場合があります。カスタマーエクスペリエンスを適切に伝える方法でパフォーマンスや挙動を理解し視覚化するために、パーセンタイルは便利なツールです。たとえば、パーセンタイルを使用して、ウェブサイトに対するリクエストの 99% が 1 秒以内に満たされていることを確認できます。Amazon ではパーセンタイルを広範に使用しており、今やお客様にも同様に使用していただけるようになりました。プレフィックスとして「p」を付け、サイトやサービスの応答時間の目標と実際のパフォーマンスを p90p99、および p100 (最低の場合) として表現します。長年の経験で、当社ではロングテールにおける応答 (p99 以上) が、データベースのホットスポットおよびその他のトラブルスポットを検出するために使用できることが判っています。パーセンタイルのサポートは、EC2、RDS、Kinesis、および新しく作成された Elastic Load Balancer および Application Load Balancer で利用できます。また、カスタムメトリクスでも利用できます。CloudWatch (カスタムダッシュボード含む) にパーセンタイルを表示できるほか、アラームを設定することもできます。パーセンタイルは他のメトリクスと組み合わせて表示できます。たとえば、オレンジと緑の線は p90 および p95 CPU 使用率を表します。

CloudWatch コンソールに、任意のパーセンタイルを設定できます。

新しいパーセンタイルメトリクスを使用してアプリケーションのパフォーマンスにさらに可視性を追加する方法について詳しくは、Elastic Load Balancing: Support for CloudWatch Percentile Metrics をご覧ください。新しいダッシュボードウィジェット Stacked Area ウィジェットおよび Number ウィジェットを CloudWatch のカスタムダッシュボードに追加できるようになりました。

以下はネットワークトラフィックの Stacked Area ウィジェットです。

EC2 および EBS メトリクスの Number ウィジェットはこのようになります。

 

今すぐご利用可能
すべての AWS リージョンで今すぐ新機能をご利用いただけます。

Jeff;

開発者の方へお知らせ – Amazon WorkDocs SDK のパブリックプレビューが利用可能になりました

私は Amazon WorkDocs のヘビーユーザーで、大ファンでもあります。AWS re:Invent をわずか数日後に控え、私は 20 件近いブログ投稿の下書きを作成中です。私は WorkDocs を使って、すべての関係者が各下書きの最新版を確実に確認し、コメントするようにしています。本日は、WorkDocs の Administrative SDK のパブリックプレビューを発表します。私はこれまで、この発表を楽しみしていました。また、ブログを効率化し、ワークフローを確認するツールをビルドすることを待ち遠しく思っています。この SDK により、高度なコンテンツ管理、ドキュメントの移行、ウイルススキャン、データ損失防止、電子情報開示を含む、多くのタイプの付加価値のある統合への扉が開きます。この SDK は、WorkDocs サイト内に含まれているリソースへの完全な管理者レベルのアクセスを提供します。ユーザー、コンテンツ、およびアクセス権限を管理するアプリケーションを構築し、WorkDocs 管理者コンソールを介してデプロイのために AWS Marketplace で販売できます。

リソースとアクション
Administrative SDK では、WorkDocs ユーザー、フォルダー、ファイル、およびアクセス許可での作成、読み取り、更新、および削除の各アクションを実行でき、それらにおいてアクションが実行されたときに送信される通知にサブスクライブする機能もあります。特定の機能やリソースへのアクセス権は、AWS Identity and Access Management (IAM) によって付与されます。SDK で提供される機能の概要は次のとおりです。

ユーザー フォルダ ドキュメント アクセス許可 [Notifications]
  • ユーザーの作成
  • ユーザーのアクティブ化
  • ユーザーの説明
  • ユーザーの更新
  • ユーザーの削除
  • フォルダーの作成
  • フォルダーの取得
  • フォルダーパスの取得
  • フォルダーの更新
  • フォルダーの削除
  • フォルダーの説明
  • フォルダーコンテンツの削除
  • ドキュメントの取得
  • ドキュメントの削除
  • ドキュメントパスの取得
  • ドキュメントのバージョンの取得
  • ドキュメントのバージョンの説明
  • ドキュメントのバージョンのアップロード開始
  • ドキュメントのバージョンのアップロード中止
  • ドキュメントのバージョンの更新
  • リソースに対するアクセス許可の追加
  • リソースに対するアクセス許可の説明
  • リソースに対するアクセス許可の削除
  • すべてのリソースに対するアクセス許可の削除
  • 通知へのサブスクライブ
  • 通知からのサブスクライブ解除

この SDK は、Java および Python 開発者が利用でき、WorkDocs が利用できる 6 つすべての AWS リージョンで利用可能です。ダウンロードは無料で、パブリックプレビュー期間中の API コールに料金はかかりません。

開発者を募集します
パブリックプレビュー期間中に、SDK を使用する PoC (実証支援) アプリケーションの構築に対して技術リソースをコミットできる開発者で、WorkDocs チームと会ってステータスの更新状況を提供し、フィードバックを共有する意思のある方を募集しています。優れたアプリケーションのアイデアがあり、パブリックプレビューへの適用を希望する場合は、今すぐサインアップしてください。

Jeff;

Amazon Simple Queue Service の新機能 – 1 回だけの処理と重複排除機能を備えた FIFO キュー

AWS サービスファミリーの本当に最初のメンバーである Amazon Simple Queue Service (SQS) は、明らかに時の試練を耐え抜きました。2004 年に、私たちはこのサービスを「分散アプリケーションコンポーネント間でメッセージをバッファリングするための、信頼性が高く、非常にスケーラブルなホストキュー」と説明しました。それからというもの、デッドレターキュー256 KB のペイロードSNS の統合ロングポーリングバッチオペレーション遅延キュータイマーCloudWatch メトリクスメッセージ属性といった多くの機能を追加してきました。

新しい FIFO キュー
現在、私たちは FIFO (先入れ先出し) キューのサポートにより、SQS をさらに強力で柔軟性の高いものにしています。この新しいタイプのキューは、現在 2 つのリージョンで導入中で、2017 年初旬に他の多くのリージョンで利用可能にする計画です。このキューは、メッセージが送信順に 1 回だけ、重複なく処理されることを保証するように設計されています。FIFO キューは財務サービスや e コマースのお客様、メッセージを使ってデータベーステーブルを更新しているお客様にとって特に役立つことを期待しています。こうしたお客様の多くは、送信順にメッセージを受信することを前提にしたシステムをお持ちです。FIFO の順序では、メッセージ A を送信した場合、成功の応答を待機してからメッセージ B を送信し、メッセージ B はメッセージ A の後のキューに入れられてから、適切に配信されます。この順序は、複数の SendMessage 呼び出しを並列で実行する場合には適用されません。SendMessageBatch への呼び出し内の個別のメッセージ、および SendMessageBatch への複数の連続した呼び出しの間では適用されません。1 回だけの処理は、単一のコンシューマーおよび複数のコンシューマーシナリオの両方に適用されます。FIFO キューを複数のコンシューマー環境で使用する場合、現在のメッセージが削除されるか、可視性タイムアウトの有効期限が切れた後でのみ、メッセージを他のコンシューマーに表示するようキューを設定できます。このシナリオでは、最大 1 人のコンシューマーがアクティブにメッセージを処理します。他のコンシューマーは、最初のコンシューマーが終了するか失敗するまで待機します。SQS 外部のネットワーキングの問題により、メッセージ送信者がアクションのステータスを確認できず、呼び出しを再試行するために、重複したメッセージが発生する場合があります。FIFO キューは複数の手法を使用して、重複したメッセージを検出し、排除します。コンテンツベースの重複に加えて、 MessageDeduplicationId を、FIFO キューに対して SendMessage を呼び出すときに含めることができます。ID の長さは最大 128 文字で、存在する場合はコンテンツベースの重複排除よりも優先順位が高くなります。FIFO キューに対して SendMessage を呼び出す場合、 MessageGroupId を含めることができるようになりました。同じグループ (ID によって示されます) に属するメッセージは順番に処理され、1 つのキュー内で順序が設定された複数のストリームを作成し、処理するとともに、複数のグループからのデータを区別して順序を保持しながら、複数のコンシューマーを使用することができます。標準キュー (元のキュータイプ) を作成するか、CreateQueue 関数、create-queue コマンド、または AWS Management Console を使って新しい FIFO キューを作成できます。同じ API 関数は両方のタイプのキューに適用されますが、1 つのキュータイプを別のキュータイプに変換することはできません。同じ API コールは両方のキュータイプに適用されますが、最新の AWS SDKs および SQS クライアントは、いくつかの追加機能を備えています。これには、失敗した ReceiveMessage 呼び出しの自動的なべき等の再試行が含まれます。個別の FIFO キューは、1 秒あたり最大 300 件の送信、受信、または削除リクエストを処理できます。

SQS リソース
SQS および新しい FIFO キューの詳細を参照するために役立つリソースをいくつか示します。

AWS re:Invent のためにラスベガスに来る予定で、AWS のお客様である Capital One による SQS および FIFO キューの使用事例の詳細についてお聞きになりたい場合は、11 月 30 日 (水) 午後 3:30 の ENT-217「エンタープライズメッセージングをクラウドに移行するには」への登録と参加をご検討ください。

今すぐ利用可能
FIFO キューは US East (Ohio) および US West (Oregon) のすべてのリージョンで利用可能になり、今すぐ使用を開始していただけます。お客様が US East (Northern Virginia) で運用中で、この機能をお試しになりたい場合は、US East (Ohio) でキューを作成し、リージョン間の低コストかつ低レイテンシーの接続を活用することができます。本日の発表の一環として、標準キューの料金も 20% 値下げいたします。最新の料金については、SQS 料金表ページを参照してください。

Jeff;

 

Amazon QuickSightが一般提供開始 – 高速で利用が簡単なビッグデータ用ビジネスアナリティクス

1,500以上のスタートアップからグローバルエンタープライズまでのAWSカスタマーが参加したプレビュー期間を経て、 Amazon QuickSightが一般提供開始(Generally Available:GA)になった事を発表いたします!去年、プレビューへのお誘いのブログエントリで、私は以下のように書きました:qs_net_tty_1

これまではビジネスインテリジェンス(Business Intelligence, BI)を実現するには対処方法が不明確で複雑な作業が大量に必要でした。インフラとソフトウェアをセットアップし、ユーザが不満に思わないようにシステムをスケールさせるために多くの費用が必要で、データからモデルを作成するために高給のコンサルタントを雇う必要がありました。システムが出来上がったあとは、ユーザは複雑なユーザインターフェースに不満を覚え、モバイルデバイスからデータを分析できるようにするリクエストを受けることになります。さらにNoSQLやストリーミングデータも含めて分析したいですって?幸運を祈ります!

Amazon QuickSightは、高速で使いやすくクラウドの力で構築されたビジネスアナリティクスをトラディショナルなオンプレミスBIシステムと比較して1/10のコストで提供します。QuickSightは数分で利用開始することが可能です。ログインし、データソースを指定すればデータを可視化(Visualize)できるようになります。その背後でSPICE(Super-fast, Parallel, In-Memory Calculation Engine)があなたのクエリを高速に処理し、結果を美しく可視化します。

データにディープダイブする

私が会話したお客様はみな、保存したデータからより多くの価値を得たいを考えておられました。彼らは価値を生む可能性がデータの中に埋もれており、そのデータが日々増えているということを理解していました。しかし、データから価値を取り出すことはとても高くつき、難易度が高いということを学習し、しばしば落胆していました。オンプレミスのビジネスアナリティクスツールは高価なライセンスが必要であり、既存のインフラに大きい負荷を追加する必要がありました。このライセンスコストと高い難易度は、ツールを利用できる人間をごく一部に制限してしまっていました。これらの要因が合わさることにより、多くの組織は自分たちが本当にビジネスアナリティクスの機能に投資をできる状態には無いと結論付けてしまっていました。

QuickSightはこういった状態を変えます!サービスとして実行され、全てのタイプ・全てのサイズの組織にビジネスアナリティクスをもたらします。高速で使うのが簡単であり、既存のインフラに負荷を追加することなく、わずか1ユーザあたり1ヶ月$9からという費用で利用を開始することが可能です。

使い始めるとすぐに分かるように、QuickSightは異なる場所に格納された多種多様なサービスのデータにアクセスすることが可能です。Amazon Redshiftデータウェアハウスや、Amazon Relational Database Service (RDS) 、S3上に置かれたフラットファイルからデータを取得することが可能です。オンプレミス上のMySQL、PostgreSQL、SQL Server、もしくはMicrosoft ExcelのスプレッドシートやSalesforce等の外部サービスにもデータコネクターを使うことでアクセスが可能です。

QuickSightはお客様の利用に合わせてスケールします。ユーザやデータソースを追加したり、新たなデータを追加した場合でもDC上でハードウェアを増強したり、長期契約のライセンスを追加購入する必要はありません。

ツアーに出かけましょう

QuickSightをめぐるツアーに出かけましょう。組織の管理者が、すでに私をQuickSightに招待(Invite)してくれています。これでもうログインしてスタート出来る状態にすでになっています。こちらがメインスクリーンです:

qs_main_screen_turn_on_how_are_you_gentlemen_1

Redshiftクラスターからデータを取得するところから始めたいと思います。Manage dataをクリックして、存在するデータセットを確認します:

qs_all_my_data_are_belong_to_me_1

欲しいものが無いようですので、New data setを押して別の方法をとることにします:

qs_data_sources_to_the_edge_3

Redshift(Manual connect)をクリックし、認証情報を入力します。これでデータウェアハウスにアクセスできるようになりました(もし私が自分のAWSアカウント内にRedshiftクラスターを稼動させている場合は、自動ディスカバリによりデータソースとして最初から現れているでしょう):

qs_new_data_source_dude_2

QuickSightはデータウェアハウスをクエリし、スキーマ(テーブルのセット)の一覧と、存在するテーブル一覧を見せてくれます。publicというスキーマを選択し、all_flightsテーブルから始めることにします:

qs_pick_a_table_1

ここで2つの選択肢があります。テーブルをSPICEにインポートしてアナリティクスの速度を上げる方法、もしくはクエリをウェアハウスで直接実行する方法です。ここではSPICEにデータをインポートします:

qs_import_spice_dune_1

もう一度2つの選択肢があります!Edit/Preview dataを選択してどの行や列をインポートするかを選択するか、もしくはVisualizeをクリックして全データをインポートし、楽しいパートをすぐに開始するかです!ここではEdit/Previewを選択しましょう。左側にフィールド(Fields)が確認でき、ここから必要な列だけにチェックボックスを付けて選択することができます:

qs_data_see_me_3

New Filterを選択してポップアップメニューからフィールドを選択し、フィルター(絞り込み条件)を作成することもできます:

qs_edit_my_filter_baby_1

それぞれの選択肢(フィールドを選択、列を選択)によりSPICEにインポートするデータをコントロールすることが可能です。つまり可視化したいデータを自分でコントロールすることができ、メモリをより効率的に利用することを可能にします。準備が完了したら、Prepare data & visualizeをクリックします。この時点でSPICEにデータがインポートされ、そのデータを使った可視化が可能になります。ここではシンプルにフィールドを選択して開始します。例えばorigin_state_abbrフィールドを選択して、それぞれの州を出発点としたフライトがどれぐらいあるのかを確認します:

qs_air_by_state_1

右側の縮小ビュー(右側の縦長いスクロールバー)を使うと追加の情報を得られます。スクロールアップ・ダウンして表示するレンジを調整することが可能です。データからもっと知見を得るためめに上部の2つ目のフィールドをクリックします。flightsをクリックし、ソート順をdescending(大きい順)とし、スクロールバーで一番上までスクロールします。これにより、それぞれの州からどれぐらいのフライトがあるかを自分のデータから取得し、確認することができます:

qs_air_by_state_and_flights_1

QuickSightのAutoGraph(オートグラフ)は、選択したデータをもとに自動的に適切なビジュアルを使用します。例えば、fl_data_fieldを追加すると、州ごとの折れ線グラフが表示されます:

qs_origin_flight_date_line_1

また、クエリやデータ型、もしくはデータの特質に応じてQuickSightは他の表現方法を提案します:

qs_try_this_instead_2

縦&横棒グラフ、折れ線グラフ、ピボットテーブル、ツリーマップ、パイチャート、ヒートマップなど多くの他のビジュアルから自分で選択することも可能です:

qs_pick_a_vis_1

効果的なビジュアルを作成した後は、それらをキャプチャし、ストーリーボードに結果をまとめることによって、データドリブンのストーリーを伝えることが可能になります:

qs_story_1

これらビジュアルを同僚と共有することも可能です:

qs_share_the_love_1

最後に、作成したビジュアルにモバイルデバイスからアクセスしてみましょう:

qs_ip_image1_1   qs_ip_image2_1b

価格とSPICEキャパシティ

QuickSightは1ユーザかつ1GBのSPICEのキャパシティを無料で永続的に利用することが可能です。これによりAWSユーザは追加コスト無しでビジネスインサイトを得ることが可能になります。Amazon QuickSightのStandard Editionは$9/月で開始することができ、それには10GBのSPICEキャパシティが含まれています(詳細はプライスのページをご覧ください)。

SPICEキャパシティの管理は簡単です。メニューからManage QuickSightを選択し(変更にはQuickSightのADMIN権限が必要です):

qs_manage_menu_1

すると現在の状況を確認できます:

qs_yum_pumpkin_spice_1

Purchase more capacity をクリックしてキャパシティを追加購入することが出来ますし、:

qs_more_spice_please_1

Release unused purchased capacityをクリックすることで使用していない分のSPICEキャパシティを削減することが可能です:

qs_take_my_spice_please_1

今日から使い始めましょう

Amazon QuickSightは、US East (Northern Virginia)、US West (Oregon)、 EU (Ireland)リージョンで提供されており、今日から使い始めることが可能です。

このブログポストの長さにも関わらず、まだQuickSightの表面を少しなぞって紹介しただけにすぎません。みなさんはすでに無料でQuickSightを利用開始できますので、ぜひサインアップしていただき、ご自身のデータをロードし、QuickSightを分析に活用してください!

— Jeff

翻訳:下佐粉 昭 (simosako@)

※日本語版補足) Amazon QuickSightのオンラインセミナーが12月14日(水)18時~19時で開催予定です。Webブラウザがあればどこからでもご覧いただける無料のセミナーです。

以下よりお申込みください。

https://connect.awswebcasts.com/qs-webinar-20161214/event/event_info.html

https://aws.amazon.com/jp/about-aws/events/webinars/

AWS ホットスタートアップ – 2016 年 11 月 –

AwareLabs、Doctor On Demand、Starling Bank、VigLink 今月も Tina が注目のスタートアップをご紹介します。

Jeff;


今月は、AWS による 4 つのホットスタートアップを取り上げます。

  • AwareLabs – 小規模ビジネス用の高度なウェブサイト構築サポート
  • Doctor On Demand – 質の高い医療提供者への迅速かつ簡単で費用効率に優れたアクセスの提供
  • Starling Bank – 次世代のモバイルバンク
  • VigLink – コンテンツ主導型取引の強化

まだお読みになっていない場合は、10 月のホットスタートアップもぜひご覧ください。

AwareLabs (フェニックス/シャーロット)
AwareLabs は、3 人の小さいスタートアップ企業で、多数の統合アプリケーションを通して顧客を取り込もうとするビジネスオーナーの支援に重点を置いています。このスタートアップ企業の誕生は 2011 年 11 月です。ウェブサイト構築ガイドとしてスタートし、最初の数週間で数百の起業家を支援しました。早くから、創立者である Paul Kenjora は、既存のビジネスソリューションでは小規模ビジネスの売上が伸びていないことを認識していました。そして 2013 年、ビジネス中心のウェブサイトビルダーを作る仕事を引き受けました。Paul は AWS セミナーへの参加後、小規模なチームでも資金豊富なハイテク企業と同じように、大規模なインフラストラクチャを設計し、デプロイできることに気が付きました。以前であれば、そのようなスケールに対応できるのは、会社規模や投資額の大きい企業だけでした。AwareLabs の支援があれば、時間と予算が制約された小規模企業でも、自分たちが必要とする高度なウェブサイトを構築できます。AwareLabs チームは AWS を利用して、以前の同じ規模のチームには不可能だったことを実現しています。彼らは資金を調達し、顧客に支持されるソリューションをより短期間で提供してきました。AwareLabs では、クライアントのウェブサイトの運用から、セキュリティで保護された自分たちのコードリポジトリの管理にまで、Amazon EC2 を大いに活用しています。また、Amazon S3 によって、データストレージと信頼性に関する負担が大幅に軽減されました。AwareLabs 開発チームがインフラストラクチャの問題ではなくクライアント向け機能を重視してきた唯一最大の理由はこれでした。Amazon SESAmazon SNS により開発者は、インテリジェントなバウンス低減機能を備えた、統合されたワンクリック操作のニュースレターを配信することに集中できました。それがクライアントから高評価を得ることにつながっています。最終的に、AWS は AwareLabs の収益向上に貢献しました。それはスタートアップ企業にしては非常に大きな額でした。プロフェッショナル用ウェブサイトのニーズについては、AwareLabs をご確認ください。

Doctor On Demand (サンフランシスコ)
Doctor On Demand は、米国内で拡大しつつある、多くの人が医療提供者にアクセスできないという問題に対処するために構築されました。医師の診察を受けるための平均待ち時間は 3 週間であり、都市部以外では、さらに長くなることがあります。医師や精神分析医の診断を受けるまで平均 25 日もかかります。また、メンタルヘルスの問題を抱える患者全体の半数近くが、治療を受けていません。Doctor On Demand を使用すると、患者はスマートフォンやタブレット、PC から数分以内に直接、認定専門医の診察を受けることができます。また、24 時間いつでも、どこからでもビデオ受診ができます。患者は Doctor On Demand アプリ (iOS および Android) をダウンロードするか、www.doctorondemand.com にアクセスします。主な症状を入力すると、居住している州の免許医につながります。サービスは数百人の従業員によって提供され、主要な多くの利用保険に対応しています。医療分野での Doctor on Demand のセキュアな運用は、そのサービス開始当初から AWS によって支えられてきました。Amazon EC2Amazon S3Amazon CloudFrontAmazon CloudWatchAWS Trusted Advisor が利用されています。これらのサービスを利用することで、法令に準拠したセキュリティとプライバシー管理の構築、シンプルな耐障害性、簡単にセットアップできる災害対策サイト (複数の AWS リージョンを使用) が実現します。Doctor on Demand では、AWS を利用する最大のメリットは必要なものをすべてスタートアップ企業の予算で手に入れられることだと言います。最新情報については、Doctor On Demand の公式ブログをご覧ください。

Starling Bank (英国)
Starling Bank
は、金融サービスの一新を使命として掲げています。Netflix によってテレビが、Spotify によって音楽が、そして Snapchat によってソーシャルメディアが一変しました。Starling はバンキングにその変化を起こそうとしています。2014 年に Anne Boden が設立した Starling は、最新技術を利用して従来の当座預金を旧式のものにしました。エンジニア、アーティスト、エコノミストからなるチームを編成し、Starling Bank の形は完成に近づきつつあります。同社のアプリは 2017 年の早い時期に提供が開始される予定です。多くの次世代バンクは、1960 年代から 70 年代の技術に基づいた従来のバンクモデルに固執し続けています。Starling は、広範囲の商品を用意し、それらを必ずしも希望していない顧客に販売または組み合わせ販売するのではなく、金融サービスや金融商品のモバイルマーケットプレースへのシームレスなアクセスを通じて、ユーザーがいつでも自分のニーズに合ったサービスや商品を自分で選べるようにしています。顧客は免許を得た法的規制に従った銀行のセキュリティと保護を利用しながら、自分のお金について自分で決定できるようになるための分析情報、データ、サービスにアクセスすることができます。Starling Bank は AWS を利用して、セキュアなインフラストラクチャをオンデマンドで自動的にプロビジョニングし、スケールします。同社は主に Amazon CloudFormationAmazon EC2 を利用していますが、Amazon S3Amazon RDSAmazon Lambda も活用しています。Starling の最初の顧客の 1 人になるには、ここから申し込んでください

VigLink (サンフランシスコ)
VigLink の創立者で CEO の Oliver Roup が初めてアフィリエイトマーケティングを知ったのは、ハーバードビジネススクールの学生のときでした。複雑なエコシステムに関心があった彼は、Amazon への既存の商品リンクを特定するクローラーを開発しました。Roup は、それらのリンクのうちアソシエイトプログラムに登録されているリンクは半分にも満たないことを発見しました。そのときこそ、身近にある確かなビジネスチャンスを彼が確信し、VigLink が生まれた瞬間です。これまでの 7 年間、同社はコンテンツのマネタイズプラットフォームとして成長しただけではなく、発行者とマーチャントに E コマースビジネスへの洞察を提供するプラットフォームとして拡大してきました。VigLink の中核は、発行者のコンテンツ内での商品への言及を識別し、収益があがるハイパーリンクに自動的に変換する機能です。リンク先は、広告主が入札するオークションによりリアルタイムで決定されます。2009 年の創立以来、Google Ventures、Emergence Capital Partners、RRE などの主要な投資家が VigLink に投資しています。Roup の最新インタビューや、VigLink のオフィスのツアーを見るには、こちらをご覧ください。創立以来、VigLink は AWS を広範囲に利用しています。資本コストやハードウェアの保守を伴わず、需要に対して伸縮自在に対応できる柔軟性は、画期的です。同社は、Amazon EC2Amazon S3Amazon SQSAmazon RDSAmazon Redshift などの多くのサービスを利用しています。拡大を続けている VigLink ですが、最近になって、AWS Cost Explorer などのツールを活用することで 15% のコスト削減に成功しました。VigLink の舞台裏を見てみたい場合は、こちらの短いビデオをご覧ください。

Tina Barr