Amazon Web Services ブログ

Amazon S3ストレージ管理機能のますます充実するポートフォリオに、新たな機能を発表します。これらにより、ストレージの分析と管理を効率化することができます。本日のリリースに含まれるものは以下です。

AWS re:Invent 2017の初日に開催されているGlobal Partner Summitにて 2017年度のAPN Premier Consulting Partnersが発表されました。 日本からはNEC様、NTT DATA様の2社が新たにプレミアパートナーとして紹介され、 既存の5社とあわせて合計7社となりました。各社様、おめでとうございます！ Classmethod (クラスメソッド株式会社様) cloudpack (アイレット株式会社様) NEC (日本電気株式会社様) NRI (株式会社野村総合研究所様) NTT DATA (株式会社エヌ・ティ・ティ・データ様) Serverworks (株式会社サーバーワークス様) TIS (TIS株式会社様) ※アルファベット順にてご紹介 これでグローバルでは55社のプレミアパートナーがおり、そのうちの7社が日本のパートナー様となります。 今後共、日本市場へのAWSサービスの展開をお願い致します。 (Partner SA 松本)

私の同僚の 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 パートナーをすばやく見つける […]

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

今までは、実行中の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のインタフェースを通じてクラスタの状態を監視したり、ユーザから報告された問題に返答するための診断情報を検索することができます。

Apache SparkやPresto、Apache Hadoopエコシステムを利用しているお客様は、ワークフローの完了次第クラスターを終了させることや、安価なAmazon EC2スポットインスタンスを利用してクラスターをリサイズをすることよってコスト節約するために、Amazon EMRの弾力性を活用しています。例えば、お客様は日次のETLや機械学習処理のためにクラスターを作成し、それらの処理が完了したらクラスターを終了させるということや、BI分析者がアドホックでレイテンシーの低いSQLをAmazon S3に置かれたデータに対して行えるよう、業務時間帯のみPrestoクラスターをスケールアウトする、ということが可能です。 Amazon EMRリリース4.xと5.xで新しくサポートされたAuto Scalingによって、お客様は、クラスターのノードを、より簡単に追加(スケールアウト)や削除(スケールイン)できます。スケーリングの動作は、EMRから提供される５分間隔の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は既に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は多くの開発・テスト環境に最適です。また、負荷の少ないプロダクションワークロードにも利用出来ます。CPUCreditUsageとCPUCreditBalance メトリクスを監視することで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 を使用すると、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 […]

本日のゲストポストでは、同僚の 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% […]