Amazon Web Services ブログ

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 は次のゲストポストであの名高い最良アーキテクチャフレームワークに読者を招待します。 バックワードアプローチは私たちのイノベーションプロセスにとても重要な作業です。カスタマーからスタートして何を求めているかを探り、定義付けすることで、取り組みの方向を決めます。2015 年に優れた設計のフレームワークを発表し、そのなかで投稿されたブログ「優れた設計を導入していますか?」で、フレームワークを改善するためのカスタマーからのフィードバックに耳を傾けました。実施したいくつもの改善策のなかでもまず、AWS ソリューションアーキテクトによって集められた数千のレビューの指摘を基にフレームワークを更新しました。また、クラウド上での作業方法についてのさらなるガイダンスを希望するカスタマーに回答する形で、フレームワークに第5番目の柱である運用性へのベストプラクティスの取得を加えました。すべての柱は次のようになります: セキュリティ – リスクの評価と軽減戦略を通して、ビジネス価値を提供しながら、情報、システム、資産を保護する能力です。 信頼性 – インフラストラクチャまたはサービスの障害から復旧したり、必要に応じて動的にコンピューティングリソースを獲得したり、設定ミスや一時的なネットワークの問題などによる障害を軽減したりといったシステムの能力です。 パフォーマンス効率 – システムの要求に合わせてコンピューティングリソースを効率的に使用し、需要の変化や技術の進歩に合わせてこの効率を維持する能力です。 コストの最適化 – 不要なコストや最適でないリソースを回避または排除する能力です。 運用性 – ビジネスの価値をもたらし、サポートプロセスと手順の継続的な向上を実現するために、システムを実行およびモニタリングする能力です。 AWS の最良アーキテクチャのフレームワークホワイトペーパーは、クラウド上の設計についてどのように捉えるかに観点を置いています。このホワイトペーパーでは、柱を達成するベストプラクティスを説明し、ベストプラクティスに見合う行動を取れていることの判断に役立つ自由回答形式の質問集を提供しています。これに加えて、クラウド上で設計する方法についてのアドバイスがもっと具体的であることを希望するカスタマーの声に対応して、それぞれの柱を背景とするクラウドネイティブアーキテクチャの設計方法に対する具体的なアドバイスを含むホワイトペーパーシリーズを作成しました。以上のホワイトペーパーは、最良アーキテクチャへの新しいホームから閲覧でき、私たちの最新の視点についてご覧いただけます。また、最良アーキテクチャの導入に役立つように、無料オンライントレーニングを始めました。AWS 最良アーキテクチャトレーニングコースは、AWS の優れた設計フレームワークとその 5 本の柱を深い理解を提供できるようにデザインされています。バックワードアプローチを通してカスタマーにとって最良のサービスを構築していくことができると信じています。最良アーキテクチャの真髄を表明するベストプラクティスを提供することで、カスタマーのビジネス前進に役立てていきます。– Philip Fitzsimonsリーダー、AWS 最良アーキテクチャチーム

を使用すると、AWS のサービスを使用したモバイルアプリケーションの構築、テスト、モニタリングが可能になります。単独の組み込みコンソールを使用して、ユーザー認証、データストレージ、バックエンドロジック、プッシュ通知、コンテンツ配信、分析機能をアプリに追加できますし、カスタマイズの機会も十分にあります。私たちは、エンタープライズモビリティで課題を抱える開発者の数が増え続けているのを見てきました。彼らは、既存のデスクトップアプリと同じくらいパワフルで、柔軟性が高く、安全な B2C (business to consumer) および B2E (business to employee) アプリケーションを構築したいと考えています。また、既存の企業ユーザーディレクトリを使用し、既存の CRM、セールス管理、経理、カスタマーサービス用ツールを利用したいとも考えています。本日、Mobile Hub が新しく SaaS 統合機能をサポートするように拡張されました。上記のようなタイプのアプリを構築している開発者の方々には特に興味を持っていただけると思います。これらの新機能は、最近リリースされた、 関数と エンドポイントを使用してアプリケーションに拡張クラウドロジックを追加しカスタムコネクターを構築するサポートのフォローアップです。どちらの機能も、最近リリースされたエンタープライズユーザー管理機能と一緒に機能し、アプリユーザーを認証します。 エンタープライズユーザー管理 B2C および B2E アプリへのユーザー認証の追加が簡単になる新機能を最近追加しました。B2C 側では に独自のフルマネージドディレクトリを作成し、多要素認証 (MFA) を含むサインアップおよびサインイン機能を追加できます。B2E 側では、ユーザーが既存の社内認証情報を使用してサインインするようにできます。この機能は SAML (セキュリティアサーションマークアップランゲージ) を利用し、Active Directory を含む複数のディレクトリと連携します。詳細は、Introducing Mobile Hub User Authentication Using SAML Federation or Email and Password Sign-in をご覧ください。これらのサインイン機能のいずれかを使用すると、各ユーザーに ロールが自動的に割り当てられます。これらの認証情報を使用して、AWS リソースや次に説明する新しい Mobile Hub コネクターへのアクセスを取得できます。 SaaS 統合 多くの […]

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

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

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

AWS の複数のサービスを組み合わせることで、多くのお客様が直面している問題に対処できることを示したいと思います。ここでは、本日発表される新しい 機能を紹介し、この機能を CloudWatch イベントと合わせて使う方法について説明します。 課題 お客様はさまざまな種類のミッションクリティカルなデータを に保存しており、これらのデータに対するオブジェクトレベルのアクティビティを追跡できることを望んでいます。S3 アクセスログには、アクティビティの一部がキャプチャされて保存されますが、その詳細レベルは限定的でログ配信に何時間もかかる場合があります。お客様は、より充実した詳細とタイムリーな配信を求めています。金融サービスなどの規制業界では特にそうです。たとえば、特定の IAM ユーザーが S3 バケットの特定箇所に保存されている機密情報にアクセスした時間を確認したいというような要望があります。このようなお客様のニーズを満たすために、S3 オブジェクトに対するオブジェクトレベルのアクティビティをキャプチャする機能を に追加します。この機能はデータイベントと呼ばれます (CloudTrail の元のイベントは今後、管理イベントと呼びます)。データイベントは、”読み取り” オペレーション (GET、HEAD、Get Object ACL など) と “書き込み” オペレーション (PUT、POST など) で構成されます。これらのオペレーションでキャプチャされる詳細のレベルは、セキュリティ、監査、ガバナンス、コンプライアンスのさまざまなユースケースに対応するよう意図されています。たとえば、この詳細のレベルに基づいて、個人識別情報 (PII) 用に新しいアップロードされたデータのスキャン、保護されたバケット内のデータに対するアクセス試行の監査、適切なアクセスポリシーが適用されていることの確認ができます。 オブジェクトレベルの API アクティビティの処理 以上のすべてを考慮して、選択されたバケット内のオブジェクトやバケット内の選択されたフォルダーに対して S3 オペレーションが実行されるたびに、それをカスタムアクションで処理する Lambda 関数を簡単に設定できます。この投稿に着手する前に、jbarr-s3-trail という新しい CloudTrail 追跡を作成しておきました。 この追跡を使用して、S3 バケットの 1 つ (jbarr-s3-trail-demo) に対するオブジェクトレベルのアクティビティを記録することにします。そのためには、この追跡にイベントセレクターを追加する必要があります。このセレクターは S3 専用であり、対象のイベントに集中してログを記録できます。イベントセレクターは CloudTrail の新しい機能です。本日、発表の一部として紹介されますのでご注目ください。読み取りイベントと書き込みイベントの両方を記録することにして、対象のバケットを指定します。プレフィックスを指定することでバケットの一部のみを対象としてイベントを記録したり、複数のバケットを対象としてイベントを記録したりできます。また、管理イベントのログ記録を設定することもできます。 CloudTrail では、追跡ごとに最大 5 つまでイベントセレクターを追加できます。各イベントセレクターは、最大 […]

で列や表、もしくはビューといったオブジェクトの名前として日本語が利用可能になりました！これは以前から日本のお客様からご要望いただいていた機能ですので、以下で説明します。 Amazon Redshift introduces multibyte (UTF-8) character support for database object names and updated ODBC/JDBC Release: Amazon Redshift on 2016-11-10 Redshiftはこれまではデータとしては日本語を含むマルチバイト文字を格納可能でしたが、表や列の名前には使用できませんでした。これが改善され、Redshift v1.0.1122からは日本語のテーブル名や列名が利用可能になります。利用する前にご自身のRedshiftクラスターが1.0.1122以降に更新されているかをご確認ください。 列や表の名前は最大で127バイトまで利用でき、文字はUTF-8で保存されます（日本語の漢字やひらがなは1文字を表現するのに3バイト必要です）。以下のドキュメントも更新されています。現時点では日本語翻訳はまだ更新されていないので、英語に切り替えてご覧ください。 Names and Identifiers なおマルチバイト文字のテーブル名や列名を使用する場合は、RedshiftのJDBCドライバー 1.2.1以降、ODBCドライバー 1.3.1以降にアップデートする必要がある事に注意してください。どちらもRedshiftのマネジメントコンソールから、もしくは以下のリンクよりダウンロードが可能です（こちらも英語にしてご覧ください）。名前のマルチバイト対応だけでなく、バグフィックスや機能向上を含みますのでぜひこの機会にドライバを最新に更新して御利用ください。 Download the Amazon Redshift JDBC Driver Install and Configure the Amazon Redshift ODBC Driver on Microsoft Windows Operating Systems Amazon Redshift JDBC Driver 1.2.1リリースノート（リンク先PDF) Amazon Redshift […]

Human Longevity, Inc. (HLI) は予防衛生を支持する上で、ヒトゲノムおよび関連性を持つ表現型データや臨床データを蓄える世界最大のデータベースを構築したいと考えています。今回のゲスト投稿では、Yaron Turpaz 氏と Bryan Coon 氏、Ashley Van Zeeland 氏が医学に大きな変化をもたらす努力の一端として生成している大量のデータを保存するため、どのように AWS を使用しているのか語ります。 2013 年に Human Longevity, Inc. を設立した当時から、前途に待ち受ける挑戦を認識していました。ゲノムには生命体を形成し維持する上で必要なすべての情報が詰まっています。ヒトにおいては、30 億もの DNA ベースのペアを含むゲノム全体のコピーが核を持つ全細胞に含まれています。我々の目的は 100 万のゲノムを配列し、その情報と関連付けた健康記録や疾病リスクを研究者や医師に提供することです。研究者や医師はデータを解釈して的を絞った個人の健康管理プランや、癌やその他の深刻な健康リスクにおいて最適な治療を従来より遥かにすばやく提供することができます。従来のように症状が出始めてから医師にかかり、病気を診断されてから治療を始めるモデルではなく、予防衛生やリスク予防を発展させることで医療を変えることが我々の目的です。大規模なコンピューティングを開発し適用、ゲノム研究に機械学習を使用するには Illumina のような企業が提供する DNA 配列技術による大量なデータの収集、分析、保存が必要になります。1 つのゲノムからの生データは約 100 ギガバイトを消耗します。注釈や表現型のソースや分析を含むゲノム情報を調整し、健康上の情報を分析するに伴ってこの数字は上昇します。我々が選ぶコンピューティングとストレージ技術が当社の成功に直接影響することは初めから理解していました。ですから、クラウドを使用することは明らかに最適な選択でした。当社はゲノミクスを専門としているので、IT インフラストラクチャの構築や維持にリソースを使用することは希望していません。そこで、プラットフォームの広さや当社が必要とする優れたスケーラビリティ、そしてビッグデータで展開した専門知識を備えている AWS を選ぶことにしました。また、AWS によるイノベーションのペースも考慮しました。利用者のために可能な限りコストを抑える AWS の手の込んだ策略も、当社のビジョンを実現する上で非常に大切なポイントだと考えました。 広範囲にわたる AWS サービスの活用 現在、当社では広範な AWS サービスを使用して様々な種類のコンピューティングタスクやストレージタスクを行っています。たとえば HLI のナレッジベースは Amazon S3 ストレージと多数の Amazon EC2 ノードで構成される分散システムインフラストラクチャを活用しています。これにより、当社がリソースの分離やスケーラビリティ、迅速なプロビジョニング、ペタバイトスケールのデータベースクエリや動的なコホートビルダーに対し、ほぼリアルタイムの応答時間を可能にすることができました。AWS サービスの柔軟性により、当社のカスタマイズした Amazon […]