Amazon Web Services ブログ

今週の投稿を実現するため、プルリクエストや新しいコンテンツについて内外部 25 名以上の寄稿者にご協力いただきました。皆様からのご協力に感謝申し上げます。 月曜日 10 月 31 日 2016 年 10 月 AWS ホットスタートアップ – Optimizely、Touch Surgery、WittyFeed をご紹介しました。 Amazon Redshift が南米 (サンパウロ) で利用可能になりました。 が 3 つの AWS クイックスタートについてエピソードを公開しました。 が AWS 公共セクターのひと月を振り返る – 10 月を公開しました。 が AWS と TeamCity でのエンドツーエンドの継続的配信およびデプロイパイプラインの構築についてブログを公開しました。 が Amazon RDS for PostgreSQL のトランザクション ID の循環に早期警告システムを実装する方法を公開しました。 Cloud Guru ブログが Amazon Alexa Analytics について投稿しました。 cloudonaut.io […]

数年前に 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 の名前空間にメトリクスが含まれている場合は、メトリクスフィルタを使用していない場合でも、そのロググループへのリンクが表示されます。この機能は今すぐ使い始めることができます。

私の同僚に十代の頃からボストンの野球チーム、レッドソックスの大ファンだという人がいます。その彼女が、つい先日レッドソックスの偉大な選手でありハンクアーロン賞も受賞した David Ortiz (別名 “ビッグパピ”) と、殿堂入りした Joe Torre、アナウンサーの Dave O’Brien (ESPN および NESN) と共に、ビッグパピのメジャーリーグ引退を記念した面白いビデオ制作に携わりました。ご覧のようにビッグパピがクオンティファイドセルフをシリアスに受け止め、引退後も競争力が衰えないように AWS を使用した Statcast でさまざまなことを測定しています。 MLB Statcast は高解像度カメラとレーダー装置を使用してボール (20,000 メトリックス/秒) と選手たち (30 メトリックス/秒) の位置をトラックし、1 試合ごとに 7 テラバイトのデータを生成します。そして、これをすべて保存し処理しているのが です。このアプリケーションは 、、、、、、 など複数の AWS サービスを使用しています。アーキテクチャの全体像は次のとおりです。 詳細はこちらのケーススタディ Major League Baseball Fields Big Data, and Excitement, with AWS をご覧ください。 に参加される方は、肩を十分にほぐしてから Statcast 装置万端のバッティングケージにぜひお越しください。メジャーリーグの選手たちと自分の測定比較をすることもできます。

2 つの AWS サービスを一緒に使用して生産性を高めるための新しい方法について記事を書き始めたときに、1980 年代の Reese ピーナッツバターカップの TV コマーシャルを思い出しました。2 つの有益なサービス (2 つのおいしい味) を組み合わせることで、さらにうまみのある新しいものが生まれます。 今日のチョコレート / ピーナッツバターの組み合わせは、 と が出会って生まれます。CodePipeline を使って、CloudFormation スタックの継続的配信パイプラインを構築できるようになりました。継続的配信を実行すると、コードの変更が毎回自動的にビルド、テストされ、本稼働環境へのリリースのために準備されます。ほとんどの場合、継続的配信のリリースプロセスには、手動と自動の承認ステップの組み合わせが含まれます。たとえば、自動化された一連のテストに合格したコードは、最終的な確認と承認のために開発マネージャーまたはプロダクトマネージャーにルーティングしてから、本稼働環境にプッシュできます。 この機能の重要な組み合わせにより、継続的配信の利点をすべて活用しながら、コードとしてのインフラストラクチャモデルを使用できるようになります。CloudFormation テンプレートを変更するたびに、CodePipeline はテストスタックを構築し、変更をテストして手動の承認を待ってから本稼働環境にプッシュするワークフローを開始できます。このワークフローでは多くの異なる方法でスタックを作成し、操作できます。 すぐ後で説明するように、ワークフローでは変更セットを生成して運用可能なスタックに適用する機能 (詳細については、「新機能 – AWS CloudFormation 用の変更セット」を参照) など、CloudFormation の高度な機能を活用できます。 セットアップ 私はこの機能の詳細について参照するため、CloudFormation テンプレートを使って継続的配信パイプラインをセットアップしました (これはコードとしてのインフラストラクチャの別の例です)。このテンプレート (こちらから入手可能で、詳細は こちらで参照可能) により、フル機能のパイプラインをセットアップできます。このテンプレートを使ってパイプラインを作成するときは、S3 バケットの名前とソースファイルの名前を指定します。 SourceS3Key は、S3 のバージョニングが有効な ZIP ファイルを指します。このファイルには、これから作成するパイプラインを介してデプロイされる CloudFormation テンプレート (WordPress のシングルインスタンスの例を使用) が含まれています。また、設定ファイルやパラメーターファイルなど、他のデプロイアーティファクトも含まれています。その例を次に示します。 [Create Stack] をクリックすると、わずか数秒で継続的配信ライン全体を準備できます。これを次に示します。 アクション この時点で、CloudFormation を使ってパイプラインをセットアップしました。これで準備が整ったので、このパイプラインで新しい […]

はメールの到達精度に注目し意図した受信者にメールが無事届くように努めています。以前公開したブログ (Introducing the Amazon Simple Email Service) では、いくつかの要因が到達精度に影響を与える点について説明したほか、複数のインターネットサービスプロバイダー (ISP) との信頼関係や、多数の苦情やバウンスしたメールなどについても取り上げました。 本日、SES 対象の送信メトリックスの新しいセットをリリースしました。この機能には 2 つの側面があります。 イベントストリーム – 重要なイベント (送信、拒否、配信、バウンス、苦情など) が発生するたびに JSON 形式のレコードを に発行するように SES を設定することができます。 メトリックス – にメトリックス集約を発行できるように SES を設定することができます。各メッセージに 1 つまたは複数のタグを追加して CloudWatch ディメンションとして使用することができます。メッセージにタグを追加することで、キャンペーン、チーム、部署に基づいて到達精度をトラッキングできます。この情報はメッセージやメール戦略の微調整に利用できます。 詳しくは のブログ Email Sending Metrics をご覧ください。

現在、 には 2,700 件を超えるソフトウェア製品がリストされています。数万という AWS の顧客が、925 以上の独立系ソフトウェアベンダー (ISV) の製品を検索して購入し、使用を開始しています。 今日は、 を通じてソフトウェアを購入している皆さんに、ご自分の連絡先情報 (氏名、肩書き、電話番号、電子メールアドレス、組織名) を選ばれたソフトウェアベンダーと共有し、製品サポートのリクエストを単純化、合理化する方法を提供したいと思います。ベンダーは、プログラムを通じて連絡先情報にアクセスし、各自のサポートシステムに保管することで、購入者のアイデンティティを簡単に検証し、より良いサポートを提供することができるようになります。このプログラムへの参加は、任意です。販売者は、プログラムに参加するかどうかを選択でき、購入者は、連絡先情報を共有するかどうかを選択できます。 購入者にとっての製品サポート接続 この機能を試してみるため、私は、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 […]

The Amazon Linux AMI は、EC2 上で実行しているアプリケーションにセキュアで安定した、高パフォーマンスの実行環境を提供します。リモートアクセスが制限され (ルートログインや必須の SSH キーペアがない)、重要でないパッケージがほとんどインストールされていない AMI は、優れたセキュリティプロフィールを誇ります。 たくさんの顧客から、この Linux イメージをオンプレミスで、特に開発ワークロードやテストワークロードの中で使用したいというリクエストがありました。 クラウドとオンプレミスでの使用に適した Amazon Linux Container Image の提供開始を今日発表することができ、光栄です。イメージは EC2 コンテナレジストリから入手できます (アクセス方法については、イメージの入手をお読みください)。AMI と同じソースコード、同じパッケージで構築されているため、コンテナの導入がスムーズに実行できます。そのままで使用することも、独自のイメージを作成するための土台として使用することもできます。 それを試してみるため、私は、作成したばかりの EC2 インスタンスを起動し、Docker をインストールし、新しいイメージを入手して実行してみました。その後、cowsay と lolcat (と依存関係) をインストールし、上記のイメージを作成しました。 このイメージの詳細については、Amazon Linux Container Image をお読みください。 このイメージは、 で使用することもできます。詳細については、Amazon ECR イメージを Amazon ECS で使用するをお読みください。

は 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 […]

Amazon Redshiftに次回適用されるパッチ（ver. 1.0.1115）の情報がフォーラムで公開されています。 Announcement: Amazon Redshift Maintenance (October 27th – November 10th, 2016) メモリ確保やクエリーキャンセルの改善など、いくつかの機能改善に加えてCREATE TABLE AS SELECT （CTAS）のへ新機能が追加されていますので、ここではそれを紹介します。 CTASは、SELECTの結果（アンサーセット）を元にそのデータが入った表を作成するという構文です。Redshiftはデータウェアハウスとして利用される事が多いため、集計データの保存や、分析の途中のデータを表として保存して再利用する等のユースケースでCTASがよく利用されています。 このCTASを使って作成された表は各列が圧縮されないという課題がありました。CTASはSELECTの結果によって表が定義されるので、その元となる圧縮アルゴリズムが存在しないケースが考えられたためです。このためにCTASで作成されたデータはディスク領域をより多く使用することになり、処理のオーバーヘッドが大きくなってしまっていました。 今回のパッチではこれが改善され、自動的に各列にLZOで圧縮がかかるようになりました。列が含むデータの特性に関係なく一律でLZO圧縮を使用する形ですが、圧縮無しと比較して大きな改善ですし、多くのケースでLZO圧縮は安定した圧縮率を実現できるため有効なアプローチですね。特に大規模な利用ケースほど効果が高いと思われます。 ただし結果セットが返す列によっては圧縮されない場合もあります。列がソートキーである場合と、 BOOLEAN、 REAL、 DOUBLE PRECISION のどれかの型になった場合です。この場合その列はRAW、つまり未圧縮として作成されます。詳細は以下のドキュメントに記載されていますので、こちらもご覧ください。 CTAS Usage Notes ソートキー列を圧縮しないのはRedshiftのベストプラクティスに沿った動きです。こちらについては別の記事で解説しています。 Amazon Redshiftのパフォーマンスチューニングテクニック Top 10 フォーラムにもありますように、この機能を含んだ新バージョンはこれから２週間程度をかけて各リージョンにデプロイされていきます。ご利用のリージョンにデプロイされ、メンテナンスウィンドウでパッチが適用された後に利用可能になりますので、楽しみにお待ちください。 下佐粉　昭（@simosako）

今月も新しいホットスタートアップをご紹介します (Tina Barr からの許可により転載)。 AWS を使用している今月のホットスタートアップをご覧ください。 Optimizely – 世界有名ブランドにウェブとモバイル A/B テストを提供 Touch Surgery – 外科学に携わるコミュニティにテクノロジーを構築 WittyFeed – バイラルコンテンツの作成 Optimizely (サンフランシスコ) Optimizely は有名ブランドにウェブサイトとモバイルの A/B テストやパーソナライズ化を提供、エクスペリエンスの最適化プラットフォームにおいて世界をリードする企業です。使いやすい製品と高速なデプロイを組み合わせたプラットフォームを提供することで、企業がテストを実施したりデータに基づいた判断を下せるようにしています。世界中にわたる何千人もの利用者が Optimizely を使用して、多種多様なチャネルの顧客に優れたエクスペリエンスを提供しています。これまでに Optimizely のユーザーが作成し提供したビジターエクスペリエンスの最適化数は 2750 億件にものぼります。 今日のデジタル世界において、企業は消費者のニーズに合わせるようにパーソナライズ化したエクスペリエンスを提供することが不可欠になっています。Optimizely は 個人化することはすでにオプションではありません。と述べています。同社のウェブをパーソナライズ化する製品は、ブラウザの動作や人口統計データ、文脈上のヒント、ファーストパーティやサードパーティのデータなどを利用することで、企業が顧客にリアルタイムで目的のコンテンツを提供できるようにしています。こうしたポイントは収益の上昇や顧客が戻ってくる理由に上手く作用しています。キャンペーンの結果を知るために分析チームやエンジニアチームに頼る必要はありません。Optimizely は各企業に合わせたテストや意思決定をサポートし業界をリードする統計エンジンを開発しています。Optimizely はさまざまなチャネルに及ぶテスト、対象、パーソナライズ化を可能にするデータインフラストラクチャの主要部分において AWS に大きく依存しています。同社は Amazon S3、Amazon EC2、Amazon EMR、Amazon RDS、Amazon Redshift、Amazon DynamoDB、Amazon ElastiCache などのサービスを使用して、迅速かつ確実にインフラストラクチャをスケールアウトしビジネスの成長をサポートしています。さらに、Optimizely は監査に Amazon Identity and Access Management (IAM) ロール、Amazon Virtual […]