Author: AWS Japan Staff


CloudWatch の更新 – メトリクスから関連するログへ

数年前に Amazon CloudWatch で OS とアプリケーションログファイルを保存しモニタリングする方法について説明しました。最近では多数の AWS ユーザーがログのフィルタを作成して、その結果を CloudWatch メトリクスとして発行し、何か問題があった場合にアラームを送信するようにしています。たとえばウェブサーバーログに無効なインバウンドリンクを表す 404 エラーや、オーバーロードの状態を意味する 503 エラーがあるか監視しています。モニタリングやアラームは大量のログデータを要約する上で優れたツールですが、場合によっては別の視点が必要になることもあります。まず、概要ではフィルタにより識別されアラームを送信する原因となったログファイルエントリをすばやく見つけなければなりません。多くの AWS ユーザーがそうであるように、何百、何千ものインスタンスを実行し複数のタイプのログファイルをモニタリングしている場合、こうした作業は針山から 1 本の針を見つけるようなものです。そこで本日、AWS はそうした作業を簡易化するため CloudWatch の新しいオプションをリリースしました。たとえばこのグラフに表示されている 17:00 頃の ERROR メトリクスについて理解したいとします。

クリックとドラッグで時間範囲を限定します。

ログアイコンをクリックし (他のアイコンと同様にグラフ上にマウスをかざすと表示されます)、目的のログファイル (ERROR) を選択します。

CloudWatch が 2 つめのタブで開きます。指定した時間範囲でフィルタする前の目的のログファイルが表示されます。次に内容を見るためにエントリを展開します (この例で使用した特定のエラーはデモ用なのでシンプルにしました)。

この機能はメトリクスの発行にログファイルのフィルタを使用する場合に便利です。では、特定のログファイルに関連していない CloudWatch システムメトリクスの場合はどうでしょう?先の手順を使用できますが、この場合はメニューから [View logs in this time range] を選択します。

指定した時間範囲の CloudWatch ロググループすべてがグラフに表示されています。

この時点でアプリケーションのアーキテクチャに関する知識をもとに意思決定を行ったり調査したいロググループを選択しやすくなります。目的の時間範囲内だけを表示するため、ロググループ内のイベントは再びフィルタにかけられます。グラフで Lambda の名前空間にメトリクスが含まれている場合は、メトリクスフィルタを使用していない場合でも、そのロググループへのリンクが表示されます。この機能は今すぐ使い始めることができます。

Jeff;

MLB Statcast – David Ortiz、Joe Torre、Dave O’Brien をご紹介

私の同僚に十代の頃からボストンの野球チーム、レッドソックスの大ファンだという人がいます。その彼女が、つい先日レッドソックスの偉大な選手でありハンクアーロン賞も受賞した David Ortiz (別名 “ビッグパピ”) と、殿堂入りした Joe Torre、アナウンサーの Dave O’Brien (ESPN および NESN) と共に、ビッグパピのメジャーリーグ引退を記念した面白いビデオ制作に携わりました。ご覧のようにビッグパピがクオンティファイドセルフをシリアスに受け止め、引退後も競争力が衰えないように AWS を使用した Statcast でさまざまなことを測定しています。

MLB Statcast は高解像度カメラとレーダー装置を使用してボール (20,000 メトリックス/秒) と選手たち (30 メトリックス/秒) の位置をトラックし、1 試合ごとに 7 テラバイトのデータを生成します。そして、これをすべて保存し処理しているのが AWS Cloud です。このアプリケーションは Amazon CloudFrontAmazon DynamoDBAmazon Elastic Compute Cloud (EC2)Amazon ElastiCacheAmazon Simple Storage Service (S3)AWS Direct ConnectAWS Lambda など複数の AWS サービスを使用しています。アーキテクチャの全体像は次のとおりです。

詳細はこちらのケーススタディ Major League Baseball Fields Big Data, and Excitement, with AWS をご覧ください。

AWS re:Invent に参加される方は、肩を十分にほぐしてから Statcast 装置万端のバッティングケージにぜひお越しください。メジャーリーグの選手たちと自分の測定比較をすることもできます。

Jeff;

CodePipeline の更新 – CloudFormation スタックの継続的配信ワークフローの構築

2 つの AWS サービスを一緒に使用して生産性を高めるための新しい方法について記事を書き始めたときに、1980 年代の Reese ピーナッツバターカップの TV コマーシャルを思い出しました。2 つの有益なサービス (2 つのおいしい味) を組み合わせることで、さらにうまみのある新しいものが生まれます。

今日のチョコレート / ピーナッツバターの組み合わせは、AWS CodePipelineAWS CloudFormation が出会って生まれます。CodePipeline を使って、CloudFormation スタックの継続的配信パイプラインを構築できるようになりました。継続的配信を実行すると、コードの変更が毎回自動的にビルド、テストされ、本稼働環境へのリリースのために準備されます。ほとんどの場合、継続的配信のリリースプロセスには、手動と自動の承認ステップの組み合わせが含まれます。たとえば、自動化された一連のテストに合格したコードは、最終的な確認と承認のために開発マネージャーまたはプロダクトマネージャーにルーティングしてから、本稼働環境にプッシュできます。

この機能の重要な組み合わせにより、継続的配信の利点をすべて活用しながら、コードとしてのインフラストラクチャモデルを使用できるようになります。CloudFormation テンプレートを変更するたびに、CodePipeline はテストスタックを構築し、変更をテストして手動の承認を待ってから本稼働環境にプッシュするワークフローを開始できます。このワークフローでは多くの異なる方法でスタックを作成し、操作できます。

すぐ後で説明するように、ワークフローでは変更セットを生成して運用可能なスタックに適用する機能 (詳細については、「新機能 – AWS CloudFormation 用の変更セット」を参照) など、CloudFormation の高度な機能を活用できます。

セットアップ
私はこの機能の詳細について参照するため、CloudFormation テンプレートを使って継続的配信パイプラインをセットアップしました (これはコードとしてのインフラストラクチャの別の例です)。このテンプレート (こちらから入手可能で、詳細は こちらで参照可能) により、フル機能のパイプラインをセットアップできます。このテンプレートを使ってパイプラインを作成するときは、S3 バケットの名前とソースファイルの名前を指定します。

SourceS3Key は、S3 のバージョニングが有効な ZIP ファイルを指します。このファイルには、これから作成するパイプラインを介してデプロイされる CloudFormation テンプレート (WordPress のシングルインスタンスの例を使用) が含まれています。また、設定ファイルやパラメーターファイルなど、他のデプロイアーティファクトも含まれています。その例を次に示します。

[Create Stack] をクリックすると、わずか数秒で継続的配信ライン全体を準備できます。これを次に示します。

アクション
この時点で、CloudFormation を使ってパイプラインをセットアップしました。これで準備が整ったので、このパイプラインで新しい CloudFormation アクションを使用する方法をご覧いただくことができます。

2 番目のステージである、TestStage に注目しましょう。このステージは最初のステージによってトリガーされ、CloudFormation を使ってテストスタックを作成します。

このスタックは ZIP の test-stack-configuration.json ファイルのパラメーター値を使って作成されます。CloudFormation アクションごとに異なる設定ファイルを使用できるので、同じテンプレートをテストと本稼働に使用できます。

スタックが起動して実行されると、ApproveTestStack ステップを使って手動の承認を待ちます (“Waiting for approval above.” と表示されます)。私は開発マネージャーの役割を果たし、テストスタックが予期どおり動作、実行されることを確認したら、それを承認します。

承認後は、DeleteTestStack ステップによりテストスタックが削除されます。

これで、本稼働環境へのデプロイの準備がほぼ整いました。ProdStage は CloudFormation 変更セットを作成し、それを手動の承認用に送信します。このステージでは ZIP の prod-stack-configuration.json ファイルからのパラメーター値を使用します。これらのパラメーターを使って、小さい EC2 インスタンスで適切なサイズのテスト環境を起動し、同じテンプレートから大規模な実稼働環境を起動できます。

ここで私は上役の役割を果たし、実稼働サイトの起動と運用を維持する責任を負います。実稼働環境へのデプロイで何が起こるかを確実に理解するため、変更セットを確認します。パイプラインを実行するのはこれが初めてであるため、変更セットは EC2 インスタンスとセキュリティグループが作成されることを示します。

次に、私はこれを承認します。

変更セットが承認されると、ExecuteChangeSet ステップの既存の実稼働スタックに適用されます。既存のスタックに変更を適用すると、既存のリソースは可能な場合は継続して機能し、アプリケーションの完全な再起動を回避します。通常、これはスタック全体を置き換えるよりも効率的で、破壊的ではありません。インメモリキャッシュのウォームアップ状態が維持され、コールドスタートアクティビティで発生する可能性のあるバーストが回避されます。

変更の実装
HTTPS のサポートを決定するとします。これを行うには、アプリケーションのセキュリティグループにポート 443 を追加する必要があります。CloudFormation テンプレートを編集し、新しい ZIP にこれを配置して、S3 にアップロードします。テンプレートに追加したコードは次のとおりです。

      - CidrIp: 0.0.0.0/0
        FromPort: '443'
        IpProtocol: tcp
        ToPort: '443'

次にコンソールに戻り、CodePipeline がすでに変更を検出してパイプラインが動作するよう設定したことを確認します。

パイプラインはもう一度実行されます。テストスタックを承認し、変更セットを点検して、既存のセキュリティグループを変更することを確認します。

次に進む前に、1 つ注意事項があります。パイプラインの CloudFormation テンプレートによって IAM ロールが作成され、これを使ってテストおよびデプロイスタックを作成します (これは新機能です。詳細については、「AWS CloudFormation サービスロール」を参照してください)。最適な結果を得るには、パイプラインを削除する前にスタックを削除します。これを行わない場合は、スタックを削除するためにロールを再作成する必要があります。

その他の情報
スペースと時間が足りなくなってきましたが、この新機能のその他の側面のついて、いくつか簡単に説明します。

パラメーターの上書き – CloudFormation アクションを定義する際に、テンプレートに対して定義されるパラメーター値の追加の制御が必要になる場合があります。これを行うには、[Advanced] ペインを開き、必要なパラメーター値の上書きを入力します。

アーティファクトのリファレンス – 状況によっては、以前のステージのパイプラインで作成されたアーティファクトの属性を参照する必要が生じます。たとえば、パイプラインの早い段階で Lambda 関数を S3 バケットにコピーし、結果として生じるアーティファクト LambdaFunctionSource を呼び出すとします。パラメーターの上書きを使って属性からバケット名とオブジェクトキーを取得する方法を次に示します。

{
  "BucketName" : { "Fn::GetArtifactAtt" : ["LambdaFunctionSource", "BucketName"]},
  "ObjectKey" : { "Fn::GetArtifactAtt" : ["LambdaFunctionSource", "ObjectKey"]}
}

JSON パラメーターへのアクセス – 新しい Fn::GetParam 関数を使って、アーティファクトに含まれる JSON 形式ファイルから値を取得できます。

Fn:GetArtifactAttFn::GetParam は、パラメーターの上書き内で使用されるよう設計されています。

S3 バケットのバージョニング – 私のパイプライン (Source アクション) の最初のステップでは、S3 バケットのオブジェクトを参照します。オブジェクトの S3 バージョニングを有効にして、変更ごとにテンプレートの新しいバージョンをアップロードします。

ソースとして S3 を使用する場合は、バージョニングを使用する必要があります (既存のオブジェクトに対する新しいオブジェクトのアップロードはサポートされません)。AWS CodeCommit または GitHub レポジトリをソースとして使用することもできます。

パイプラインウィザードの作成
私は、CloudFormation テンプレートを使ってパイプラインを作成することで、このブログ投稿を開始しました。コンソールで [Create pipeline] をクリックし、ウィザードを使って最初のパイプラインを構築することもできます (ソース、ビルド、およびベータデプロイステージを使用)。このウィザードでは、デプロイプロバイダーとして CloudFormation を選択することもできます。ベータデプロイステージでスタックや変更セットを作成または更新できます。

今すぐご利用可能
この新機能は今すぐご利用可能で、すぐに使用を開始することができます。詳細については、CodePipeline ドキュメントの「AWS CodePipeline を使用した継続的配信」を参照してください。

Jeff;

新機能 – Amazon Simple Email Service (SES) にメトリックスを送信

Amazon Simple Email Service (SES) はメールの到達精度に注目し意図した受信者にメールが無事届くように努めています。以前公開したブログ (Introducing the Amazon Simple Email Service) では、いくつかの要因が到達精度に影響を与える点について説明したほか、複数のインターネットサービスプロバイダー (ISP) との信頼関係や、多数の苦情やバウンスしたメールなどについても取り上げました。

本日、SES 対象の送信メトリックスの新しいセットをリリースしました。この機能には 2 つの側面があります。

イベントストリーム – 重要なイベント (送信、拒否、配信、バウンス、苦情など) が発生するたびに JSON 形式のレコードを Amazon Kinesis Firehose に発行するように SES を設定することができます。

メトリックスAmazon CloudWatch にメトリックス集約を発行できるように SES を設定することができます。各メッセージに 1 つまたは複数のタグを追加して CloudWatch ディメンションとして使用することができます。メッセージにタグを追加することで、キャンペーン、チーム、部署に基づいて到達精度をトラッキングできます。この情報はメッセージやメール戦略の微調整に利用できます。

詳しくは Amazon Simple Email Service Blog のブログ Email Sending Metrics をご覧ください。

Jeff;

AWS Marketplace の顧客向け製品サポート接続(英語版)

現在、AWS Marketplace には 2,700 件を超えるソフトウェア製品がリストされています。数万という AWS の顧客が、925 以上の独立系ソフトウェアベンダー (ISV) の製品を検索して購入し、使用を開始しています。

今日は、AWS Marketplace を通じてソフトウェアを購入している皆さんに、ご自分の連絡先情報 (氏名、肩書き、電話番号、電子メールアドレス、組織名) を選ばれたソフトウェアベンダーと共有し、製品サポートのリクエストを単純化、合理化する方法を提供したいと思います。ベンダーは、プログラムを通じて連絡先情報にアクセスし、各自のサポートシステムに保管することで、購入者のアイデンティティを簡単に検証し、より良いサポートを提供することができるようになります。このプログラムへの参加は、任意です。販売者は、プログラムに参加するかどうかを選択でき、購入者は、連絡先情報を共有するかどうかを選択できます。

購入者にとっての製品サポート接続
この機能を試してみるため、私は、Barracuda Web Application Firewall (WAF) を起動しました。オプションを選択し、Accept Software Terms & Launch with 1-click ボタンをクリックすると、連絡先情報を共有するかどうかを選択するオプションが表示されました。

そこで、氏名などの連絡先情報を入力しました。

ここでは、サブスクリプションごとに最大 5 つの連絡先が入力できます。 必要であれば、連絡先情報を後で追加、変更、削除することもできます。

私がすでに持っている製品で Product Support Connection が有効になっているなら、ここで連絡先の詳細を追加することもできます。

販売者にとっての Product Support Connection
私が、ISV で、このプログラムへの参加を希望している場合は、AWS Marketplace 販売者/カタログ業務チーム (aws-marketplace-seller-ops@amazon.com) に連絡します。すると、プログラムに登録され、連絡先情報の入手に使用するセキュリティが確保された API へのアクセスが可能になります。私は、プログラムの条件に従い、サポートシステムまたは CRM システム内の各連絡先を 1 営業日以内に登録しなければならず、連絡先は、サポート目的にしか使用できません。詳細については、AWS Partner Network BlogAWS Marketplace Product Support Connection はソフトウェアベンダーによる製品サポートをよりシームレスにする をお読みください。

開始方法
AWS Marketplace で製品を検索するとき、希望する製品属性として Product Support Connection を選択することができます。

今日の発表に際して、Product Support Connection プログラムの企画に協力し、このプログラムを製品リストに追加してくださる以下のベンダーの皆さんに感謝したいと思います。

  • Barracuda – Web Application Firewall (WAF)、NextGen Firewall F-Series、Load Balancer ADC、Email Security Gateway、Message Archiver。
  • Chef – Chef Server、Chef Compliance。
  • Matillion – Matillion ETL for Redshift。
  • Rogue Wave – OpenLogic Enhanced Support for CentOS (6 & 7、Standard & Security Hardened)。
  • SoftNAS – SoftNAS Cloud (Standard & Express)。
  • Sophos -Sophos UTM Manager 4、Sophos UTM 9。
  • zData – Greenplum データベース。
  • Zend – PHP、Zend Server。
  • Zoomdata – Zoomdata。

他にも、これらのベンダーに続こうというベンダーが多数名乗り出てくれることを祈ります!

プログラムへの参加を開始するには、AWS Marketplace 販売者/カタログ業務チーム (aws-marketplace-seller-ops@amazon.com) までご連絡ください。

Jeff;

クラウドおよびオンプレミスワークロード用の新しい Amazon Linux Container Image

The Amazon Linux AMI は、EC2 上で実行しているアプリケーションにセキュアで安定した、高パフォーマンスの実行環境を提供します。リモートアクセスが制限され (ルートログインや必須の SSH キーペアがない)、重要でないパッケージがほとんどインストールされていない AMI は、優れたセキュリティプロフィールを誇ります。

たくさんの顧客から、この Linux イメージをオンプレミスで、特に開発ワークロードやテストワークロードの中で使用したいというリクエストがありました。

クラウドとオンプレミスでの使用に適した Amazon Linux Container Image の提供開始を今日発表することができ、光栄です。イメージは EC2 コンテナレジストリから入手できます (アクセス方法については、イメージの入手をお読みください)。AMI と同じソースコード、同じパッケージで構築されているため、コンテナの導入がスムーズに実行できます。そのままで使用することも、独自のイメージを作成するための土台として使用することもできます。

それを試してみるため、私は、作成したばかりの EC2 インスタンスを起動し、Docker をインストールし、新しいイメージを入手して実行してみました。その後、cowsaylolcat (と依存関係) をインストールし、上記のイメージを作成しました。

このイメージの詳細については、Amazon Linux Container Image をお読みください。

このイメージは、Amazon EC2 Container Service で使用することもできます。詳細については、Amazon ECR イメージを Amazon ECS で使用するをお読みください。

Jeff;

Amazon CloudWatch の更新 – メトリックス保存期間の延長とユーザーインターフェイスの更新

Amazon CloudWatch は AWS リソースと AWS で実行しているアプリケーションをモニタリングするサービスです。これはメトリックスの収集とトラッキング、ログファイルのモニタリング、アラーム設定、AWS リソースの変更に対応することができます。

本日、AWS は CloudWatch に追加した複数の重要な強化機能をリリースしました。

  • メトリックス保存期間の延長 – CloudWatch ですべてのメトリックスを 15 か月間保存できるようになりました。
  • メトリックスの選択をシンプルに – CloudWatch コンソールで必要なメトリックスの検索と選択が簡単になりました。
  • メトリックスのグラフ化を改善 – 選択したメトリックスのグラフ化が今までより簡単かつ柔軟になりました。

それらについて説明します。

メトリックス保存期間の延長
2009 年に CloudWatch をリリースした当時 (New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch) システムメトリックスの保存期間は 14 日間でした。その後、CloudWatch に自分のメトリックスを発行できるようになっても、保存期間は従来と変わりませんでした。AWS 利用者の多くが、より長い期間にわたりデータへのアクセスや閲覧を望んでいます。季節ごとの要因を検出して理解したり、毎月の成長傾向の確認、前年同期比の分析を実行するためです。

こうしたユースケースをサポートするため (そして多くの方々のリクエストにお応えするため)、CloudWatch ですべてのメトリックスを 15 か月間保存できるようになりました。追加費用はありません。全体のデータ量を合理的な範囲に抑えるため、履歴データは詳細度が低いレベルで保存されます。詳しくは次をご覧ください。

  • 1 分間内のデータポイントは 15 日間にわたり利用可能です。
  • 5 分間内のデータポイントは 63 日間にわたり利用可能です。
  • 1 時間内のデータポイントは 455 日間 (15 か月) にわたり利用可能です。

この新機能の価値を直接ご理解いただくため、今すぐ 3 か月分のメトリックス保存期間の延長にアクセスできます。今後 12 か月にわたり、メトリックスは 15 か月分の履歴を保存するまで保持されます。

メトリックス保存期間の延長によるメリットを次の例でご説明します。この長期間にわたる私の AWS Lambda 関数は 2 週間ごとに異変があることを表しています。

メトリックスの選択をシンプルに
詳しく調べグラフ化したいメトリックスを検索し選択しやすくするため、CloudWatch コンソールで見やすいカード形式による表示方法を可能にしたほか、AWS メトリックスとカスタムメトリックスを区別しました。

次のステップで目的のメトリックスを検索します。たとえば名前に "CPU" が含まれているメトリックスを探すとします。

ここでメトリックスを選びグラフ化することができます。次の図は EC2 インスタンス全体の CPU 使用率 のメトリックスを表しています。

同じグラフで複数のメトリックスを表示することもできます。

これでは明確にお見せすることができないので、あとで簡単に修正方法をご説明します。

メトリックスのグラフ化を改善
メトリックスを 15 か月にわたり保存できるようになったほか、メトリックスの検索と選択も簡単になりました。情報を理解しやすくする方法をご説明します。この段階で、新に追加されたタブ (Graphed metricsGraph options) が便利になります。

[Graphed metrics] タブで各メトリックスを細かく管理することができます。

右側の [Actions] の列でアラーム作成やメトリックスの複製またはグラフから削除することができます。

変更するには [Statistic] の列にあるエントリをクリックします (どの列でも構いません)。

メトリックスを複製してから統計を変更できるので、たとえば CPU 使用率の最大値と平均値を比較することができます (この例では期間も 6 時間に変更しました)。

Y 軸コントロールは [Graph options] タブにあります。これを見てみましょう。すでに 7 つの EC2 メトリックスを同時にグラフ化しましたが、範囲がさまざまであるため、グラフから十分な情報を読み取ることができませんでした。左と右の Y 軸で各範囲を選択し、左側または右側でメトリックスを指定します。

これをクリックするとメトリックスのラベルを編集できます。
左と右の Y 軸の範囲を選択することもできます。

新しくなった日付指定を使用して期間を指定します。目的の日付範囲や現在の日付に関連するメトリックスを見ることができます。日付範囲の絶対値を選択する方法は次のとおりです。

関連性のある日付範囲は次のように選択します。

グラフ名を変更するには現在の名前をクリックしてから新しい名前を入力します。

必要に応じてグラフの詳細設定を完了したら、既存のダッシュボードに追加するか新しいダッシュボードを作成します。

これは私の既存のダッシュボードです。新しいグラフは下部にあります。

今すぐご利用可能
メトリックス保存期間の延長と、このブログで紹介した機能はすべて US East (Northern Virginia)US West (Oregon)US West (Northern California)Europe (Ireland)Europe (Frankfurt)South America (Brazil)Asia Pacific (Singapore)Asia Pacific (Tokyo)Asia Pacific (Seoul)Asia Pacific (Mumbai)Asia Pacific (Sydney) リージョンで使用可能です。

先述のとおり、メトリックス保存期間の延長のご利用にあたり追加費用は発生しません。

Jeff;

Redshiftアップデート:CTASで表を作成時に自動的に圧縮されるように

Amazon Redshiftに次回適用されるパッチ(ver. 1.0.1115)の情報がフォーラムで公開されています。

メモリ確保やクエリーキャンセルの改善など、いくつかの機能改善に加えてCREATE TABLE AS SELECT (CTAS)のへ新機能が追加されていますので、ここではそれを紹介します。

CTASは、SELECTの結果(アンサーセット)を元にそのデータが入った表を作成するという構文です。Redshiftはデータウェアハウスとして利用される事が多いため、集計データの保存や、分析の途中のデータを表として保存して再利用する等のユースケースでCTASがよく利用されています。

このCTASを使って作成された表は各列が圧縮されないという課題がありました。CTASはSELECTの結果によって表が定義されるので、その元となる圧縮アルゴリズムが存在しないケースが考えられたためです。このためにCTASで作成されたデータはディスク領域をより多く使用することになり、処理のオーバーヘッドが大きくなってしまっていました。

今回のパッチではこれが改善され、自動的に各列にLZOで圧縮がかかるようになりました。列が含むデータの特性に関係なく一律でLZO圧縮を使用する形ですが、圧縮無しと比較して大きな改善ですし、多くのケースでLZO圧縮は安定した圧縮率を実現できるため有効なアプローチですね。特に大規模な利用ケースほど効果が高いと思われます。

ただし結果セットが返す列によっては圧縮されない場合もあります。列がソートキーである場合と、 BOOLEAN、 REAL、 DOUBLE PRECISION のどれかの型になった場合です。この場合その列はRAW、つまり未圧縮として作成されます。詳細は以下のドキュメントに記載されていますので、こちらもご覧ください。

ソートキー列を圧縮しないのはRedshiftのベストプラクティスに沿った動きです。こちらについては別の記事で解説しています。

フォーラムにもありますように、この機能を含んだ新バージョンはこれから2週間程度をかけて各リージョンにデプロイされていきます。ご利用のリージョンにデプロイされ、メンテナンスウィンドウでパッチが適用された後に利用可能になりますので、楽しみにお待ちください。

下佐粉 昭(@simosako

AWS ホットスタートアップ - 2016 年 10 月 – Optimizely、Touch Surgery、WittyFeed

今月も新しいホットスタートアップをご紹介します (Tina Barr からの許可により転載)。

Jeff;


AWS を使用している今月のホットスタートアップをご覧ください。

  • Optimizely – 世界有名ブランドにウェブとモバイル A/B テストを提供
  • Touch Surgery – 外科学に携わるコミュニティにテクノロジーを構築
  • WittyFeed – バイラルコンテンツの作成

Optimizely (サンフランシスコ)
Optimizely は有名ブランドにウェブサイトとモバイルの A/B テストやパーソナライズ化を提供、エクスペリエンスの最適化プラットフォームにおいて世界をリードする企業です。使いやすい製品と高速なデプロイを組み合わせたプラットフォームを提供することで、企業がテストを実施したりデータに基づいた判断を下せるようにしています。世界中にわたる何千人もの利用者が Optimizely を使用して、多種多様なチャネルの顧客に優れたエクスペリエンスを提供しています。これまでに Optimizely のユーザーが作成し提供したビジターエクスペリエンスの最適化数は 2750 億件にものぼります。

今日のデジタル世界において、企業は消費者のニーズに合わせるようにパーソナライズ化したエクスペリエンスを提供することが不可欠になっています。Optimizely は 個人化することはすでにオプションではありません。と述べています。同社のウェブをパーソナライズ化する製品は、ブラウザの動作や人口統計データ、文脈上のヒント、ファーストパーティやサードパーティのデータなどを利用することで、企業が顧客にリアルタイムで目的のコンテンツを提供できるようにしています。こうしたポイントは収益の上昇や顧客が戻ってくる理由に上手く作用しています。キャンペーンの結果を知るために分析チームやエンジニアチームに頼る必要はありません。Optimizely は各企業に合わせたテストや意思決定をサポートし業界をリードする統計エンジンを開発しています。Optimizely はさまざまなチャネルに及ぶテスト、対象、パーソナライズ化を可能にするデータインフラストラクチャの主要部分において AWS に大きく依存しています。同社は Amazon S3Amazon EC2Amazon EMRAmazon RDSAmazon RedshiftAmazon DynamoDBAmazon ElastiCache などのサービスを使用して、迅速かつ確実にインフラストラクチャをスケールアウトしビジネスの成長をサポートしています。さらに、Optimizely は監査に Amazon Identity and Access Management (IAM) ロール、Amazon Virtual Private Cloud (VPC)、AWS CloudTrail といった AWS サービスを使用し、自社製品に対する顧客の信用を高めています。

最新情報については Optimizely の公式ブログをご覧ください。

Touch Surgery (ロンドン)
4 人の外科医が設立した Touch Surgery は、最新技術を使用して外科医をトレーニングし専門知識の統一化を図ることで、外科分野をグローバルに拡大することを目的としたテクノロジースタートアップ企業です。同社はモバイルアプリとパワフルなデータバックエンドをリンクする独自のプラットフォームを通じて、従来のプロフェッショナルヘルスケアトレーニングを変えています。Touch Surgery のチームは外科学の専門知識をマップし共有するため、世界中の優秀な外科医達と何年も協力してきました。Touch Surgery は外科手術を体系化するために、コグニティブマッピングの技術と最先端技術の AI や 3D レンダリング技術を組み合わせて使用しています。同社は手術室における外科治療を進化させるために仮想現実や拡張現実のリーダー達とパートナーを組んでいます。未来の外科医はいつでもどこからでもアプリをダウンロード (iOS & Android) して医療業務を行うことができます。このアプリはユーザーが 50 種類以上の外科治療を学び練習し、経過を確認したり世界中の医師と繋がることを可能にしています。さらに、Touch Surgery は神経外科、整形外科など様々な専門分野のシミュレーションも提供しています。

Touch Surgery のバックエンドは AWS が完全にホストしています。同社は数多くの Amazon EC2 インスタンスを使用しているほか、Amazon S3Amazon Elasticsearch Service も利用しています。AWS は同社に Amazon RDS でのスケールを許可しています。現在のユーザー数は 100 万人となり、データ分析製品で必要となる膨大な量の使用データを記録しています。Touch Surgery はテストや提供までの時間を短縮できるように比較的容易に異なる環境でデプロイすることもできます。

Touch Surgery では常に優れた人材を探しています。詳しくは https://www.touchsurgery.com/jobs/ をご覧ください。

WittyFeed (インド)
WittyFeed はソーシャルメディアで影響力のあるユーザーと、面白く注目度抜群のストーリーを書くことができるクリエイティブライター達をリンクするプラットフォームです。Vinay Singhal (CEO)、Shahshak Vaishnav (CTO)、Parveen Singhal (COO) が 2014 年に設立した WittyFeed はインドでもっとも多くのバイラルコンテンツを発信する企業です。同社は 1 日に 60 件のストーリーを提供、毎月 7500 万人のユニークビジターがアクセスしています。常にコンテンツ制作に努めるライターが 100 人、そして社内のエディターチームは適切な利用者にコンテンツが届き、インターネットで急速に広まるようにします。WittyFeed チームは発行者がページを増やしていくためのお手伝いをしたいと考えています。そのため、投稿する時間や幅広いユーザーに届くタイプのコンテンツを知らせるツールも作成中です。WittyFeed は使用しやすくユーザーが自分に関連性のあるコンテンツを表示できるように、パーソナライズ化も可能にしています。フォトシリーズ、リスティクル や チャーティクル 、そしてカテゴリではテクノロジー、歴史、スポーツ、お笑いなどに焦点を置いています。WittyFeed はユーザー同士が交流しやすくするためにリアルタイムのコメント機能を追加しています。ユーザーは各自のアカウントにログインせずにコメントを残すことができます。

コンテンツを提供する企業として、WittyFeed は大量のユーザーベース、データを取り扱わなければなりません。AWS を使用することで、同社はトラフィックの急増やニーズへの対応に短期間で処理できるスケーラブルに優れたインフラストラクチャを備えています。WittyFeed は Amazon Kinesis FirehouseAmazon RedshiftAmazon RDS など幅広いサービスを使用しています。こうしたサービスは WittyFeed がほぼダウンタイムなしで 1 億人ものビジターと 5 億回にわたるページ閲覧の処理を可能にし、同社のインフラストラクチャで大きな役割を担っています。

今すぐ WittyFeed を見てみませんか?

Tina Barr

週刊 AWS – 2016 年 10 月 24 日

AWS にとって今週もまた忙しい 1 週間でした! 本日の投稿には、内外部の 21 名の寄稿者からの投稿に加えて、私の RSS フィード、受信トレイ、および私の身の回りのその他の内容が含まれています。これらをお楽しみいただくには、AWS 関連コンテンツを作成 (または検索) し、プルリクエストを送信してください。

月曜日

10 月 24 日

火曜日

10 月 25 日

水曜日

10 月 26 日

木曜日

10 月 27 日

金曜日

10 月 28 日

土曜日

10 月 29 日

日曜日

10 月 30 日

新しい & 注目のオープンソース

  • aws-git-backed-static-website は完全に AWS を使用した Git-backed 静的ウェブサイトジェネレーターです。
  • rds-pgbadger は PostgreSQL インスタンス用に Amazon RDS からログファイルを取得し、美しい pgBadger レポートを生成します。
  • aws-lambda-redshift-copy は Redshift でコピーコマンドを自動化する AWS Lambda 関数です。
  • VarnishAutoScalingCluster には、Auto Scaling グループを使用して拡張または縮小する、共有された水平方向にスケーラブルである Varnish クラスターを設定するためのコードと手順が含まれています。
  • aws-base-setup には、AWS CloudFormation ベースの AWS スタックを開発するためのスターターテンプレートが含まれています。
  • terraform_f5 には、AWS で Big IP をインスタンス化する Terraform スクリプトが含まれています。
  • claudia-bot-builder は Facebook、Slack、Skype、Telegram、GroupMe、Kik、および Twilio 用のチャットボットを作成し、数分で AWS Lambda にデプロイします。
  • aws-iam-ssh-auth は IAM を使用して SSH 経由で EC2 に接続するユーザーを認証するために使用される一連のスクリプトです。
  • go-serverless は、AWS でのサーバーレスアプリケーションのデプロイ用に go.cd サーバーを設定します。
  • awsq は、SQS を使用して AWS でバッチジョブを実行するヘルパースクリプトです。
  • respawn は YAML の仕様から CloudFormation テンプレートを生成します。

新しい SlideShare プレゼンテーション

新しいお客様事例

  • AbemaTV – AbemaTV は日本の大手ストリーミングプラットフォームの 1 つである FRESH! by AbemaTV を運営しているインターネットメディアサービス会社です。同社は Amazon EC2 Container Service でマイクロサービスプラットフォームを構築し、書き込み重視のマイクロサービス (タイムラインやチャットなど) に Amazon Aurora データストアを使用しており、その他のマイクロサービス API には Amazon RDS で MySQL データベースを使用しています。AbemaTV は、AWS を使用することで、最小のエンジニアリング作業で新しいプラットフォームを大規模かつ迅速にデプロイすることができます。
  • Celgene – Celgene は AWS を使用して内外部の研究者の間でセキュアなコラボレーションを可能にし、個別の科学者が数百のコンピューティングノードを起動できるようにしています。また、計算ジョブにかかる時間を数週間または数か月から 1 日以下に減らしています。Celgene は、がんやその他の病気または障害の薬を製造している世界規模のバイオ医薬品会社です。Celgene は高パフォーマンスのコンピューティング調査クラスターと、その調査コラボレーション環境を AWS で実行しています。
  • Under Armour – Under Armour は AWS の信頼性と高可用性を活用して自社の Connected Fitness アプリを拡大し、1 億 8000 万人を超える世界中のユーザーの要求を満たすことができます。また、革新により新製品や新機能をより迅速に提供し、国際的に拡大できます。同社は高機能なフットウェア、アパレル、および機材の世界大手です。また、成長中の Connected Fitness アプリプラットフォームを AWS クラウドで実行しています。

新しい YouTube 動画

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローして、RSS フィードをサブスクライブしてね。