Author: AWS Japan Staff


パートナーソリューションファインダーの紹介: AWS でのニーズを満たすためのエキスパート APN パートナーを見つける

私の同僚の Kate Miller が AWS Partner Network Blog を投稿しています。本日、彼女のゲスト投稿で、お客様のビジネスニーズにぴったりのパートナー開発者ソリューションを見つけるための新しいツールを紹介しています。

Jeff;


お客様は、AWS でワークロードの設計、移行、管理、最適化を手伝ってくれるコンサルティングパートナーを AWS パートナーネットワーク (APN) 内で求める場合があります。また、ビジネスニーズを満たすために AWS で構築または AWS と統合して活用できるテクノロジーパートナーソリューションを求める場合もあります。AWS には、世界中の何万というコンサルティングパートナーやテクノロジーパートナーで構成されている巨大な AWS パートナープログラムがあります。APN パートナーは、AWS における実質的にすべてのユースケースに対処するお手伝いができます。また、AWS でお客様のニーズに満たすお手伝いができる最適な APN パートナーを、できるだけ簡単に特定して接触できるようにしたいと思います。

AWS パートナーソリューションファインダーの紹介
本日、グローバルパートナーサミットにおいて、APN チームが AWS パートナーソリューションファインダーを発表しました。AWS パートナーソリューションファインダーを使うことで、AWS でビジネスニーズに応じたサービスやソリューションを提供できる APN パートナーをすばやく検索して見つけることができます。AWS パートナーソリューションファインダーでは、以下のことができます。

  • 場所、業界、ユースケース、製品など、一般的なトピック別に検索する
  • 認定された AWS リセラーや AWS マネージドサービスプロバイダーを簡単に見つける
  • AWS コンピテンシーや AWS Service Delivery Program の賞を獲得した APN パートナーをすばやく見つける
  • APN パートナー別に AWS で検証されたデータを一覧表示する
  • APN パートナーとシームレスに接触する

AWS パートナーソリューションファインダーを利用するには、こちらをクリックしてください。

AWS パートナーソリューションファインダーを re:Invent で試す!
今週 re:Invent に参加している方は、パートナーソリューションファインダーを試す機会をお見逃しなく。Sands Lower Lobby、エグゼクティブサミット、AWS ブースのいずれかで弊社のキオスクを訪ねてください。

AWS リーダーシップが語る APN パートナーの利用価値
AWS は初めてですか? AWS でニーズを満たすお手伝いができる APN パートナーの利用方法を詳しく知りたいですか? 次のビデオをご覧ください。Commercial Sales & Business Development 担当バイスプレジデントの Mike Clayville と Channels & Alliances 担当バイスプレジデントの Terry Wise が、コンサルティングおよびテクノロジーパートナーの価値、APN パートナーを雇用する場合のベストプラクティスについて論じています。

Kate Miller、APN Senior Content and Communication Manager

AWS グローバルパートナーサミット – re:Invent 2016 のレポート

私の同僚の Dorothy Copeland は、AWS グローバルパートナープログラムのジェネラルマネージャーです。本日、AWS re:Invent の AWS グローバルパートナーサミットに参加した彼女から、以下の詳細なレポートがゲスト投稿として送信されてきました。

Jeff;


_2MM0323re:Invent での重要な AWS グローバルパートナーサミットが無事終了しました。この丸 1 日のイベントは、AWS パートナーネットワーク (APN) パートナー限定です。今年は、AWS のシニアリーダーの基調講演で、APN に関するいくつかの発表、マーケットのキートレンド、AWS でお客様の成功をサポートする APN パートナーの事例が紹介されました。次に、APN チームが、いくつかのビジネスセッションおよびテクニカルセッションを主催し、APN パートナーが AWS ベースのビジネスを構築して成功させるために役立つトピックを取り上げました。サミットにおいて、過去 12 か月間に 10,000 を超える新しいパートナーが APN に登録されたことが発表されました。これにより、お客様は、何千という新しい APN テクノロジーパートナーや APN コンサルティングパートナーから、AWS と統合されたソフトウェアとして最適なものを見つけ、AWS でのワークロードやアプリケーションの設計、構築、移行、管理に役立てることができます。今年のグローバルパートナーサミットで APN チームが行った他の発表についても、いくつか紹介します。グローバルパートナーサミットの基調講演で、以下の AWS 幹部から発表がありました。

  • Terry Wise
  • James Hamilton
  • Dave McCann
  • Mike Clayville
  • Andy Jassy

基調講演では、以下のお客様からも発表がありました。

  • Dan Zelem、CTO、Johnson & Johnson
  • Adam Japhet、Head of Technology Services Architecture & Design、Scholastic

基調講演のテーマ – AWS でお客様の成功と革新を促進する
世界をリードする企業は、AWS クラウドの俊敏性の利点を活かすために、信頼する APN パートナーからサポートを受けています。Fortune 500 の大半および Fortune 100 の 90% を超える企業は、APN パートナーのソリューションとサービスを利用しています。AWS で培った高いスキルと専門知識を活かして、AWS でのお客様の成功をサポートできるという強みは、APN パートナーならではのものです。基調講演全体を通じ、エンタープライズのお客様をサポートして AWS でデジタル変革および革新を起こす上で APN パートナーが成功した点と、今後 APN パートナーが改善に取り組むべき主な領域が報告されました。特に注目すべき点は、お客様が AWS に移行して AWS の利点を最大限に活用する際の APN パートナーのサポートについて改善の余地があることです。Terry Wise は、エンタープライズの移行、お客様にとっての次世代のクラウドマネージドサービスの価値、APN パートナーが自動化とライフサイクル全体のカスタマーエンゲージメントを通じてお客様に多大な価値を提供する方法について AWS のアプローチを説明しました。また、Terry は新しく発表された VMWare/VMWare Cloud on AWS との連携を紹介し、2017 年に VMWare Cloud on AWS パートナープログラムが開始することを発表しました。また、Terry は、APN パートナーが Amazon Alexa で革新を行っている興味深い方法を紹介しました。APN パートナーが Alexa の主要スキルを獲得できるように APN チームと Alexa チームが連携してサポートする方法についても紹介されました。APN プログラムの開始 APN チームは、基調講演でいくつかの魅力的なローンチを発表しました。以下は、そのまとめです。詳しくは、リンクを通じて AWS Partner Network Blog を参照してください。

  • AWS IoT コンピテンシー: さまざまな IoT ユースケースについて定評あるテクノロジーや導入機能を提供している業界屈指の APN コンサルティングおよびテクノロジーパートナーを紹介します。ユースケースには、インテリジェントファクトリ、スマートシティ、エネルギー、自動車、輸送、ヘルスケアなどが含まれますが、これらに限定されません。
  • AWS 財務サービスコンピテンシー: 銀行決済業務、資本市場、保険業務に携わるお客様向けのサービスやソリューションを提供する APN コンサルティングおよびテクノロジーパートナーを紹介します。
  • AWS Service Delivery Program: Amazon Aurora や AWS GovCloud (US) ワークロードの提供で特に実績のある AWS のサービスやスキルを提供している APN パートナーを AWS のお客様が探すお手伝いをします。
  • AWS Public Sector Program: 有資格の APN パートナーが AWS Public Sector ビジネスを構築して育成するのをサポートします。
  • AWS パートナーソリューションズファインダー: AWS のお客様がビジネスニーズに合った APN パートナーを簡単に検索して見つけ、接触できるようにします。

新しい AWS プレミアコンサルティングパートナーをご利用ください! コンサルティングパートナーが APN のプレミアレベルになるには、極めて高いハードルをクリアする必要があります (詳細はこちら)。現在、55 のプレミアパートナーが登録されています。本日 AWS プレミアコンサルティングパートナーに昇格した企業は以下のとおりです。おめでとうございます!

re:Invent で APN チームに会おう
APN について詳しく知りたい場合は、AWS のメインブースをお訪ねください。期間中、いつでも開いています。

Dorothy Copeland

Amazon ECSイベントストリームで、クラスタの状態を監視

今までは、実行中のAmazon ECSクラスタの状態の更新を取得するためには、AWS CLIやSDKを使ってコンテナインスタンスとタスクの状態を定期的にポーリングする必要がありました。新しいAmazon ECSイベントストリーム機能によって、これからはAmazon ECSのタスクとコンテナインスタンスの状態更新を準リアルタイムにイベント駆動で受け取ることが可能になりました。イベントはAmazon CloudWatch Eventsを通して配送され、AWS Lambda関数やAmazon SNSトピックといった、あらゆるCloudWatch Eventsのターゲットに向けることができます。

この記事では、簡単なサーバレスアーキテクチャを作って、イベントストリームの更新を受け取り、処理し、そして保存する方法をお見せします。まず最初にLambda関数を作成し、入ってきた全てのイベントをスキャンして実行中のタスクに関連したエラーが無いかを探し、もしあれば即座にSNSの通知を送ります。その後、関数は全てのメッセージをAmazon Elasticsearch Serviceを使ったElasticsearchのクラスタにドキュメントとして保存することで、皆さんや開発チームの方がKibanaのインタフェースを通じてクラスタの状態を監視したり、ユーザから報告された問題に返答するための診断情報を検索することができます。

(more…)

Auto Scalingを利用して、Amazon EMRのアプリケーションを動的にスケールする

Apache SparkやPresto、Apache Hadoopエコシステムを利用しているお客様は、ワークフローの完了次第クラスターを終了させることや、安価なAmazon EC2スポットインスタンスを利用してクラスターをリサイズをすることよってコスト節約するために、Amazon EMRの弾力性を活用しています。例えば、お客様は日次のETLや機械学習処理のためにクラスターを作成し、それらの処理が完了したらクラスターを終了させるということや、BI分析者がアドホックでレイテンシーの低いSQLをAmazon S3に置かれたデータに対して行えるよう、業務時間帯のみPrestoクラスターをスケールアウトする、ということが可能です。

Amazon EMRリリース4.xと5.xで新しくサポートされたAuto Scalingによって、お客様は、クラスターのノードを、より簡単に追加(スケールアウト)や削除(スケールイン)できます。スケーリングの動作は、EMRから提供される5分間隔のAmazon CloudWatchメトリクスによって、自動的にトリガーされます。トリガーになるメトリクスには、メモリ利用、未実行アプリケーションの状態、HDFS利用、に関連するいくつかのYARNメトリクスも含まれます。

EMRリリース5.1.0には、2つの新しいメトリクスが導入されました。YARNMemoryAvailablePercentageとContainerPendingRatioです。これらは、Apache SparkやApache Tez、そして、Apache Hadoop MapReduceのような、スケーラブルなYARNベースのフレームワーク向けの、クラスターの利用状況を知るのに便利なメトリクスです。さらに、お客様は、カスタムCloudWatchメトリクスをAuto Scalingポリシーに利用することもできます。

以下は、最大40・最小10インスタンスで、一度に1インスタンスずつ増減する、インスタンスグループに対するAuto Scalingポリシーの例示です。インスタンスグループは、YARN内の利用可能なメモリが15%を下回ると、スケールアウトし、75%を上回るとスケールインします。また、インスタンスグループは、割り当てられているYARNコンテナに対するYARNコンテナの未実行率が0.75になった場合も、スケールアウトします。

さらに、お客様は、EMR 5.1.0のクラスターによってノードが終了される際に、スケールダウンの振る舞いを設定することができます。デフォルトで、EMRは、いかなるタイミングで終了リクエストが投げられたとしても、インスタンス時間単位の境目に実施されるスケールインイベントの最中のみ、ノードの停止を行います。これは、EC2は、いつインスタンスを終了したかに関わらず、時間単位で請求をするためです。この振る舞いによって、クラスター上で実行されているアプリケーションは、コスト効率をより高く、動的にスケールする環境で、インスタンスを利用することができます。

反対に、5.1.0より前のEMRリリースでは、お客様は、以前のデフォルト設定を利用できます。インスタンス時間単位の境目に近接しているかどうかを考慮せず、ノードを終了する前に、ノードをブラックリストしたり、タスクを排出したり、ということが可能です。いずれの振る舞いにおいても、EMRは、まず最も動きの少ないノードを削除しますし、HDFSの不整合を招き得る場合は、終了処理をブロックします。

EMRコンソール、AWS CLI、または、AWS SDKのEMR APIを利用して、Auto Scalingポリシーの作成や変更ができます。Auto Scalingを有効にするためには、Auto Scalingで容量の追加・削除を行うための権限を付与すべく、追加のIAMロールをEMRに与える必要があります。さらに詳細な情報は、Amazon EMRでのAuto Scalingを確認して下さい。また、もし、EMRでのAuto Scalingに関して、ご質問や公開したい面白い事例などございましたら、コメントを下に書いていただければと存じます。

原文: Dynamically Scale Applications on Amazon EMR with Auto Scaling (翻訳: 半場 光晴)

Amazon Auroraを開発・テストワークロードでご利用しやすいT2.Medium DBインスタンスクラスをリリース

Amazon Auroraは既にdb.r3.large (2 vCPUs, 15 GiB RAM) から db.r3.8xlarge (32 vCPUs 244 GiB RAM)まで5つのインスタンスクラスをご提供していました。これらのインスタンスは非常に多くのプロダクション環境やアプリケーション向けのユースケースをサポートしています。

今日、 db.t2.medium DB インスタンスクラス (2 vCPUs, 4 GiB RAM)の6つ目の選択肢を追加致しました。通常時、このインスタンスクラスではシングルコアの40%のパフォーマンスを利用することが可能で、CPUを利用するクエリやデータベースタスクを実行する場合コアのフルパフォーマンスまでバーストをします。同名のEC2インスタンスの様に、この新しいインスタンスクラスはCPUクレジットを持っており、CPUが多く使われている場合は消費し、そうでない場合はCPUクレジットを蓄積します。(バースト可能な性能を持つ新しい低コストEC2インスタンスで詳細を説明しています)

db.t2.mediumは多くの開発・テスト環境に最適です。また、負荷の少ないプロダクションワークロードにも利用出来ます。CPUCreditUsageCPUCreditBalance メトリクスを監視することでCPUクレジットの利用や蓄積を確認することが出来ます。

本日からご利用いただけます

新しいインスタンスクラスを使ったAmazon Auroraデータベースは本日から起動頂けます。Amazon Auroraが利用出来る全リージョンで利用可能です。1時間あたり$0.082(N.Virginiaリージョンの場合)からご利用頂けます。

Jeff; (翻訳は星野が担当しました。原文はこちら)

最良のアーキテクチャ、バックワードアプローチを通して前進する

同僚の Philip “Fitz” Fitzsimons は次のゲストポストであの名高い最良アーキテクチャフレームワークに読者を招待します。

Jeff;


バックワードアプローチは私たちのイノベーションプロセスにとても重要な作業です。カスタマーからスタートして何を求めているかを探り、定義付けすることで、取り組みの方向を決めます。2015 年に優れた設計のフレームワークを発表し、そのなかで投稿されたブログ「優れた設計を導入していますか?」で、フレームワークを改善するためのカスタマーからのフィードバックに耳を傾けました。実施したいくつもの改善策のなかでもまず、AWS ソリューションアーキテクトによって集められた数千のレビューの指摘を基にフレームワークを更新しました。また、クラウド上での作業方法についてのさらなるガイダンスを希望するカスタマーに回答する形で、フレームワークに第5番目の柱である運用性へのベストプラクティスの取得を加えました。すべての柱は次のようになります:

  • セキュリティ – リスクの評価と軽減戦略を通して、ビジネス価値を提供しながら、情報、システム、資産を保護する能力です。
  • 信頼性 – インフラストラクチャまたはサービスの障害から復旧したり、必要に応じて動的にコンピューティングリソースを獲得したり、設定ミスや一時的なネットワークの問題などによる障害を軽減したりといったシステムの能力です。
  • パフォーマンス効率 – システムの要求に合わせてコンピューティングリソースを効率的に使用し、需要の変化や技術の進歩に合わせてこの効率を維持する能力です。
  • コストの最適化 – 不要なコストや最適でないリソースを回避または排除する能力です。
  • 運用性 – ビジネスの価値をもたらし、サポートプロセスと手順の継続的な向上を実現するために、システムを実行およびモニタリングする能力です。

AWS の最良アーキテクチャのフレームワークホワイトペーパーは、クラウド上の設計についてどのように捉えるかに観点を置いています。このホワイトペーパーでは、柱を達成するベストプラクティスを説明し、ベストプラクティスに見合う行動を取れていることの判断に役立つ自由回答形式の質問集を提供しています。これに加えて、クラウド上で設計する方法についてのアドバイスがもっと具体的であることを希望するカスタマーの声に対応して、それぞれの柱を背景とするクラウドネイティブアーキテクチャの設計方法に対する具体的なアドバイスを含むホワイトペーパーシリーズを作成しました。以上のホワイトペーパーは、最良アーキテクチャへの新しいホームから閲覧でき、私たちの最新の視点についてご覧いただけます。また、最良アーキテクチャの導入に役立つように、無料オンライントレーニングを始めました。AWS 最良アーキテクチャトレーニングコースは、AWS の優れた設計フレームワークとその 5 本の柱を深い理解を提供できるようにデザインされています。バックワードアプローチを通してカスタマーにとって最良のサービスを構築していくことができると信じています。最良アーキテクチャの真髄を表明するベストプラクティスを提供することで、カスタマーのビジネス前進に役立てていきます。– Philip Fitzsimonsリーダー、AWS 最良アーキテクチャチーム

AWS Mobile Hub を使用したエンタープライズモバイルアプリの構築 – 新規ユーザーの管理と SaaS 統合

AWS Mobile Hub を使用すると、AWS のサービスを使用したモバイルアプリケーションの構築、テスト、モニタリングが可能になります。単独の組み込みコンソールを使用して、ユーザー認証、データストレージ、バックエンドロジック、プッシュ通知、コンテンツ配信、分析機能をアプリに追加できますし、カスタマイズの機会も十分にあります。私たちは、エンタープライズモビリティで課題を抱える開発者の数が増え続けているのを見てきました。彼らは、既存のデスクトップアプリと同じくらいパワフルで、柔軟性が高く、安全な B2C (business to consumer) および B2E (business to employee) アプリケーションを構築したいと考えています。また、既存の企業ユーザーディレクトリを使用し、既存の CRM、セールス管理、経理、カスタマーサービス用ツールを利用したいとも考えています。本日、Mobile Hub が新しく SaaS 統合機能をサポートするように拡張されました。上記のようなタイプのアプリを構築している開発者の方々には特に興味を持っていただけると思います。これらの新機能は、最近リリースされた、AWS Lambda 関数と Amazon API Gateway エンドポイントを使用してアプリケーションに拡張クラウドロジックを追加しカスタムコネクターを構築するサポートのフォローアップです。どちらの機能も、最近リリースされたエンタープライズユーザー管理機能と一緒に機能し、アプリユーザーを認証します。

エンタープライズユーザー管理
B2C および B2E アプリへのユーザー認証の追加が簡単になる新機能を最近追加しました。B2C 側では Amazon Cognito に独自のフルマネージドディレクトリを作成し、多要素認証 (MFA) を含むサインアップおよびサインイン機能を追加できます。B2E 側では、ユーザーが既存の社内認証情報を使用してサインインするようにできます。この機能は SAML (セキュリティアサーションマークアップランゲージ) を利用し、Active Directory を含む複数のディレクトリと連携します。詳細は、Introducing Mobile Hub User Authentication Using SAML Federation or Email and Password Sign-in をご覧ください。これらのサインイン機能のいずれかを使用すると、各ユーザーに AWS Identity and Access Management (IAM) ロールが自動的に割り当てられます。これらの認証情報を使用して、AWS リソースや次に説明する新しい Mobile Hub コネクターへのアクセスを取得できます。

SaaS 統合
多くの B2C および B2E アプリでは、エンタープライズ SaaS アプリケーション内に保存されているデータにアクセスする必要があります。新しい Mobile Hub コネクターを使用すると、SalesforceMicrosoft DynamicsMarketoHubSpotZendesk、および QuickBooks で広く使用されているオブジェクト (アカウント、連絡先、リード、その他) にアクセスするアプリを構築できます。これらのアプリケーションから、カスタムオブジェクトにアクセスしてこれを取得するクエリを実行することもできます。

コネクターは、AWS Lambda 関数として実装され Amazon API Gateway 経由でアクセスする REST マイクロサービスの形をとるため、設定や実行が容易です。目的のコネクターをクリックして認証情報を入力するだけで、簡単に開始できます。

コネクターに対するコールは API Gateway を経由して基盤となる SaaS アプリケーションに送られます。このモデルを使用することで、コールの監査および測定、SaaS アプリケーションへのリクエストのスロットル、およびレスポンスのキャッシュを行うことができます。コネクターで SaaS アプリケーションが標準化され、カテゴリ (CRM、マーケティングオートメーション、カスタマーサポート、その他) 内で統一された整合性のあるオブジェクトが提供されます。すべての REST API 用に Swagger 2.0 の定義を、また各 SaaS アプリケーション用にリファレンスモバイルアプリを、それぞれ提供しています。舞台裏では、コネクターを作成すると、IAM ロール、API 定義、Lambda 関数をセットアップする AWS CloudFormation テンプレートを使用するプロセスが開始されます。以下に、Salesforce コネクターの API 定義を挙げます。

また、Mobile Hub のクラウドロジック機能を使用して独自のカスタムコネクターを構築し、ここに挙げたような利点をすべて手に入れることもできます。コネクターにはきめ細かいアクセス制御を使用できます。たとえば、特定のリソースパスでの PUTPOSTDELETE などのオペレーションを、アプリユーザーの限られたセットに制限できます。詳細およびコネクターの完全リストを確認するには、AWS Mobile Hub 開発者ガイドを参照してください。

今すぐご利用可能
今すぐ新機能をご利用いただけます。

Jeff;

アプリケーションパフォーマンスのパーセンタイルと AWS アプリケーションロードバランサーへのリクエストのトレース

本日のゲストポストでは、同僚の Colm MacCárthaigh が新しいCloudWatch パーセンタイル統計およびロードバランサーの意味と利点について語ります。 また、個別のリクエストがロードバランサーに到着した時点からその進行を追跡でき、そのリクエストがアプリケーションに繋がるための新しいリクエストのトレース機能も紹介します。

Jeff;


アプリケーションパフォーマンスのパーセンタイルメトリクス
AWS Elastic Load Balancer はすでに以前から Amazon CloudWatch メトリクスに含まれ、ロードバランサーのバックグラウンドで実行しながらインスタンスとソフトウェアのヘルス状態とパフォーマンスの可視化を提供します。たとえば、ELB はアプリケーションに送られたすべてのリクエストが負荷分散される応答時間を測定します。多くのカスタマーはアプリケーションのパフォーマンスを監視するために、ビルトインの平均と最大レイテンシーメトリクスを使用しています。また、インスタンスやコンテナを負荷の変動として追加や削除するためのきっかけとしてこういったメトリクスを使用することも一般的です。新しい CloudWatch パーセンタイルサポートに基づき、ELB Classic and Application Load Balancer(ALB) はアプリケーションの応答時間によりきめ細かなデータを提供します。こういった測定により範囲内のパフォーマンスをより正確に掴むことができます。たとえば、10 番目のパーセンタイルが 2 ミリ秒とすると、10% のリクエストは 2 ミリ秒以下かかることになり、99.9 番目のパーセンタイル値が 50 ミリ秒とすると、99.9% のリクエストは 50 ミリ秒以下かかっているという具合です。

パーセンタイルがどれだけ役に立つかという現実的な例としては、ほとんどのリクエストを 1 から 2 ミリ秒で高速キャッシュから処理するアプリケーションの場合、キャッシュが空になるとリクエストの処理はさらにずっと遅くなり、100 ミリ秒 から 200 ミリ秒の範囲までも落ちてしまいます。従来の最大メトリクスでは 200 ミリ秒台の最低速の案件のみが反映され、平均には高速と低速の回答が混合して示されることになり、どれだけのリクエストが高速または低速で処理され、そしてそれぞれがどれだけの速度であったかについての詳細はほとんど提供されませんでした。パーセンタイルメトリクスは、アプリケーションのパフォーマンスをリクエストの範囲を通して映し出し、より分かりやすい情報を提供します。パーセンタイルのメトリクスはアプリケーションに対してより有意義で積極的なパフォーマンスとして使用できます。たとえば、99番目のパーセンタイルを Auto Scaling のトリガーあるいは CloudWatch アラームとして使用すると、スケーリングのターゲットを設定できるために十分なリソースが提供されて 1% を超えないリクエストのみで 2 ミリ秒以上の処理時間がかかることになります。

リクエストのトレーシング内蔵
パーセンタイルはすべてのリクエストにおけるパフォーマンスの全体像を示すことでアプリケーションの可視性を大幅に向上させますが、AWS のアプリケーションロードバランサーの新しいトレーシング機能では、アプリケーションのパフォーマンスとヘルス状態を個々のリクエストの核心レベルまで掘り下げた理解を提供できます。ALB は現在 1 つの ALB へのすべてのリクエストにおける新しいカスタム X-Amzn-Trace-ID HTTP ヘッダーを探索しています。受信リクエストにこのヘッダーがない場合、ALB は次のようなヘッダーを生成します。

X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354 

そしてこのリクエストをアプリケーションに渡します。ヘッダーがないため、この受信リクエストは「ルート」リクエストと考慮され、ALB が送る新しいヘッダーが無作為に生成されるルート属性に含められます。受信リクエストにヘッダーが付けられている場合、そのコンテンツは保持され、こうしてヘッダーはリクエスト間の系統やタイミングデータなどのトレーシングと診断状態を送付、保持します。たとえば、生成されるリクエストは次のようになります。

$ curl -H \
  "X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354; TimeSoFar=112ms; CalledFrom=Foo" \
  request-tracing-demo-1290185324.elb.amazonaws.com 

このリクエストは ALB によって多少異なるヘッダーが生成されます。

X-Amzn-Trace-Id: Self=1-582113d1-1e48b74b3603af8479078ed6;\
  Root=1-58211399-36d228ad5d99923122bbe354;\
  TotalTimeSoFar=112ms;CalledFrom=Foo 

この例にように受信ヘッダーが自身のルーツ属性に含まれる場合、ALB はそれを保持して無作為に生成される新しい「セルフ」属性を代わりに追加します。この例に TotalTimeSoFar および CalledFrom 属性は任意でありオプショナルとなり、そしてロードバランサー自体にとっては実際意味のないものですが、アプリケーションとトレーシングフレームワークがリクエスト間でデータを移動させるためにそのまま保持されます。受信リクエストにヘッダーを設定しないアプリケーションでは、ALB のリクエストのトレースはすべてのリクエストを一意に識別する働きをします。リクエスト間でヘッダーを送付するアプリケーションでは、トレース機能によってシステム全体におけるエントリポイントを容易に識別し、ルート属性によって関連するリクエストを検索し、アプリケーションがリクエストをつなぐ「パンくず」リストを作成できるようにします。X-Amzn-Trace-ID ヘッダーのコンテンツは Application Load Balancer アクセスログに記載され、これにはそれぞれのリクエストにおけるエラー表示やパフォーマンス測定が含まれ、個別のリクエストにおける事案の特定のための識別用に使用できます。

http 2016-11-08T00:04:13.109451Z app/request-tracing-demo/f2c895fd3ea253c5 \
  72.21.217.129:20555 172.31.51.164:80 0.001 0.001 0.000 200 200 276 550 \
  "GET http://request-tracing-demo-1290185324.elb.amazonaws.com:80/ HTTP/1.1" \
  "curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.16.1 \
  Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" - - \
  arn:aws:elasticloadbalancing:us-east-1:99999999999:targetgroup/echoheader/21a6f1501d2df426 \
  "Root=1-5821167d-1d84f3d73c47ec4e58577259"

パーセンタイル統計は今すべての Application Load Balancer に利用でき、CloudWatch コンソール、AWS SDKsAPI からアクセスできます。既存の Application Load Balancer とすべての Classic Load Balancer へのサポートはこれから利用できる予定です。どちらの新しい機能も無償で導入されます。

Colm MacCárthaigh、AWS Elastic Load Balancer

AWS の値下げ – CloudWatch メトリクスの料金

2011 年と同じに 私は CloudWatch 用のカスタムメトリクスと、お客様のアプリケーションやスクリプトからそれらのメトリクスを発行する方法について説明しました。そのときに、最初の 10 個のカスタムメトリクスは無料で、追加のメトリクスは、発行したメトリクスの数にかかわらず、1 か月あたり、1 メトリクスあたり 0.50 USD でした。本日は、CloudWatch メトリクスの料金変更と数量割引について発表いたします。毎月お客様が発行するメトリクスの数に基づいて、最大 96% の節約を実現できます。US East (Northern Virginia) リージョンの新料金を次に示します (最初の 10 個のメトリクスは引き続き無料です)。

階層 下限 上限 1 か月あたり、1 メトリクスあたりの料金 現在の料金に対する割引率
最初の 10,000 メトリクス 0 10,000 0.30 USD 40%
次の 240,000 メトリクス 10,001 250,000 0.10 USD 80%
次の 750,000 メトリクス 250,001 1,000,000 0.05 USD 90%
残りの全メトリックス 1,000,001 0.02 USD 96%

EC2 詳細モニタリングを有効にした場合、1 か月あたりの料金は、1 か月、1 インスタンスあたり 3.50 USD から、ボリューム層に基づき 2.10 USD またはそれ以下に下がります。新料金は 2016 年 12 月 1 日に有効になり、お客様は何もする必要はありません。そのときに、更新された料金は CloudWatch 料金表ページに記載されます。ところで、CloudWatch メトリクスをご利用中の場合は、メトリクス保存期間の延長Collectd の CloudWatch プラグインCloudWatch ダッシュボード、新しいメトリクスからログへの概要ナビゲーション機能など、最近発表されたその他の機能もぜひご利用ください。

Jeff;

AWS ストレージの更新 – S3 と Glacier の値下げ + Glacier に追加された取得オプション

2006 年に、S3 のサービスを画期的な従量課金制 (月額 15 セント/GB の初期料金) で開始しました。以降、これまでの間に GB あたりの料金を 80% 値下げし、すべての AWS リージョンで S3 を開始しました。元の汎用モデルにはユーザー主導型の機能として、ウェブサイトのホスティングVPC の統合IPv6 のサポートなどが追加され、さらに S3 の低頻度アクセスなどの新しいストレージオプションも追加されました。AWS の多くのお客様は、法的、コンプライアンス、その他の目的で重要なデータをアーカイブしますが、このようなデータは滅多に参照することがないため、2012 年に Glacier を発表しました。そして、ライフサイクルのルールを使用して S3、S3 の低頻度アクセス、Glacier の間でデータを転送する機能を提供しました。ここでは、2 つのビッグニュースを紹介します。まず、S3 の標準ストレージと Glacier ストレージの料金が値下げになります。さらに、Glacier に新しい取得オプションが追加されます。

S3 と Glacier の値下げ
AWS を長くご利用いただいているお客様はご存じだと思いますが、AWS では絶えずコスト削減に取り組んでおり、その結果を AWS の値下げという形でお客様に還元しています。S3 の標準ストレージの GB あたりの料金は、ほとんどの AWS リージョンで 2016 年 12 月 1 日より値下げになります。12 月の使用量に対する請求には、自動的に値下げ後の新料金が反映されます。標準ストレージの新料金は以下のとおりです。

リージョン 0〜50 TB (USD / GB / 月) 51〜500 TB (USD / GB / 月) 500+ TB (USD / GB / 月)
  • 米国東部(バージニア北部)
  • 米国東部 (オハイオ)
  • 米国西部 (オレゴン)
  • 欧州 (アイルランド)

(値下げ幅は 23.33%〜23.64%)

0.0230 USD 0.0220 USD 0.0210 USD
  • 米国西部(北カリフォルニア)

(値下げ幅は 20.53%〜21.21%)

0.0260 USD 0.0250 USD 0.0240 USD
  • 欧州 (フランクフルト)

(値下げ幅は 24.24%〜24.38%)

0.0245 USD 0.0235 USD 0.0225 USD
  • アジアパシフィック (シンガポール)
  • アジアパシフィック (東京)
  • アジアパシフィック (シドニー)
  • アジアパシフィック (ソウル)
  • アジアパシフィック (ムンバイ)

(値下げ幅は 16.36%〜28.13%)

0.0250 USD 0.0240 USD 0.0230 USD

上の表を見ておわかりのように、料金体系も 6 段階から新しい 3 段階に簡略化されます。Glacier のストレージの料金もほとんどの AWS リージョンで値下げになります。たとえば、US East (Northern Virginia)US West (Oregon)、または Europe (Ireland) リージョンで 1 GB を 1 か月保存した場合の料金はわずか 0.004 USD (1 セントの半分未満) であり、43% の値下げになります。参考までに、同じ量のストレージは 2012 年の Glacier の開始時では 0.010 USD であり、前回の Glacier の値下げ (30%) 時では 0.007 USD でした。料金の値下げは、お客様が AWS を信頼して何兆というオブジェクトを利用された直接の結果です。ただし、利点はそれだけではありません。新しい機能に関して寄せられたフィードバックによると、クラウドストレージプラットフォームの真価は迅速で安定した進化にあります。お客様からは、お客様のニーズを事前に把握し、そのニーズに応じた新しい機能を提供している点を評価できるとよく言われます。

Glacier の新しい取得オプション
AWS の多くのお客様は、Amazon Glacier を階層化ストレージアーキテクチャのアーカイブ用コンポーネントとして利用しています。Glacier を使用すると、コンプライアンス要件 (組織または規制の要件) を満たしながら、必要なだけクラウドベースの処理能力を引き出してデータを処理し価値を取り出すことができます。Glacier には、データを取り出すための新しいオプションが 2 つ追加されました。データの取得を急ぐ場合は、少しのコスト負担で緊急オプションを利用できます。急がない場合は、より低価格の取得オプションを利用できます。Glacier に保存したデータの量とそれを取り出す頻度に基づいて、新しい料金体系を導入しました。この変更は AWS でのサービスの提供コストを正確に反映した結果ですが、説明しようとすると少し複雑です。これからは従量ベースの取得料金が、よりシンプルな GB あたりの料金に変ります。メディアおよびエンターテインメント業界のお客様は、テレビ映像を Glacier にアーカイブします。緊急事態が発生して特定の画像を取り出すために分を争うような場合、画像にすばやくコスト効率よくアクセスする必要があります。医療関係のお客様は、「患者を待たせている間に」アーカイブされた医療画像やゲノム情報にすばやくアクセスする必要があり、衛星データを販売するフォトアーカイブ企業も似たような必要性に迫られます。一方、データの取り出しを事前にスケジュールできて、5〜12 時間以内にデータを取得できれば問題ないというお客様もいます。以上のような状況を応じて、Glacier からデータを取り出す際に、以下のオプションを使い分けることができます (これまでの従量制の取得モデルは今後適用されません)。

標準取得は、Glacier が従来提供していたオプションの新しい名前であり、API 駆動のすべての取得リクエストに対するデフォルトです。データは数時間 (通常 3〜5 時間) で取得されます。料金は 0.01 USD/GB、0.05 USD/1,000 リクエストです。

緊急取得は、迅速対応アクセスのニーズに対処します。データはすばやく取得されます。通常、所要時間は 1〜5 分です。Glacier に 100 TB を超えるデータを保存 (または保存を計画) し、頻度は低いが急いでデータのサブセットをリクエストするような状況には、このオプションが最適です (データ量が少ない場合は、S3 の頻繁にアクセスしないストレージクラスがより適切なオプションです)。取得コストは 0.03 USD/GB、0.01 USD/リクエストです。

通常、取得の所要時間は 1〜5 分です (全体の需要により異なります)。まれに需要が非常に多い場合でも、この所要時間内にデータを取り出す必要がある場合は、取得容量をプロビジョニングすることができます。プロビジョニングを行うと、すべての緊急取得のデータは自動的にプロビジョンド容量を経由して取得されます。プロビジョンド容量の各ユニットは月額 100 USD です。これにより、5 分ごとに最低 3 回の緊急取得を行うことができます。取得スループットは最大 150 MB/秒です。

一括取得は、事前にスケジュールできる場合や緊急でない場合に最適です。通常、取得の所要時間は 5〜12 時間。料金は 0.0025 USD/GB (標準取得の 75% 未満)、0.025 USD/1,000 リクエストです。一括取得は、大量のデータを 1 日以内に取得する場合に最適です。さらに数時間を余分に待機できる場合は、大きな割引も得られます。

アーカイブを取り出す際に、どの取得オプションも指定しないで InitiateJob を呼び出すと、標準取得が開始されます。既存のジョブは引き続き正常に動作し、新料金が課金されます。詳細については、データ取り出し (よくある質問 – Glacier) を参照してください。これまで同様、嬉しいニュースでした。同じように喜んでいただければ幸いです。

Jeff;