Author: AWS Japan Staff


Amazon AppStream 2.0 – AWSからデスクトップアプリをストリーミング

私の同僚であるGene FarrellがオリジナルバージョンのAmazon AppStreamがお客様のフィードバックをもとにしていかに進化したかについてゲスト投稿を書きました。

Jeff;


AWSでは、お客様の問題を解決することを手助けしテクノロジーによってお客様にサービスを提供するのが私たちのミッションです。それが私たちに考えることをうながし、私たちがイノベーションを実現する方法の中心となっています。私たちのお客様はAWSのサービスを使用して次世代のモバイルアプリを構築し、快適なWebエクスペリエンスを作成し、そしてコアのITワークロードをグローバルスケールで実行しています。

モバイル、Web、そしてコアITにおけるイノベーションとトランスフォーメーションにはめざましいものがありますが、デスクトップとデスクトップアプリケーションについてはほとんど変化がありませんでした。エンドユーザーはどこでどのように仕事をするのかの自由をまだ享受できていません。ITは、デスクトップ、アプリケーション、そして無数のデバイスを管理するための堅牢で高価なシステムに悩まされています。そして企業情報をセキュアにすることはますますむずかしくなっています。おおくのやり方でクラウドはITのこの側面を迂回しているようです。

私たちのお客様はそれを変えたいと思っています。 モバイル、Web、およびコアITで見られるように、デスクトップとアプリケーションの柔軟性、スケール、セキュリティ、パフォーマンス、そしてコストのメリットが求められます。 たった2年以上前に、私たちはフルマネージドのセキュアなクラウドデスクトップサービスであるAmazon WorkSpacesを発表し、AWS上で永続的なデスクトップを提供しています。 本日、私はデスクトップアプリケーションをWebブラウザに配信するためのフルマネージドでセキュアなアプリケーションストリーミングサービスであるAmazon AppStream 2.0を紹介することにワクワクしています。

お客様は、さまざまなプラットフォームで動作することを必要としている従来のデスクトップアプリケーションがたくさんあると言っていました。 これらのアプリケーションの保守は複雑で高価であり、お客様はよりよいソリューションを求めています。 AppStream 2.0によって、任意のデバイス上のWebブラウザを使用することで、AWSからのストリーミングによってデスクトップアプリケーションへのインスタンスアクセスを提供することができます。 クラウドのためにアプリケーションを書き直す必要はなく、ひとつのバージョンをメンテナンスするだけですみます。 アプリケーションとデータはAWS上でセキュアにたもたれ、アプリケーションストリームはエンドツーエンドで暗号化されます。

オリジナルのAppStreamをふりかえって
AppStream 2.0の詳細について説明する前に、オリジナルのAmazon AppStreamサービスの歴史についてみる価値があります。 2013年に私たちはAppStreamをSDKベースのサービスとしてローンチし、お客様はデスクトップアプリケーションのストリーミング体験を構築してこれらのアプリケーションをクラウドに移行することができるようになりました。 私たちはSDKによるアプローチがお客様がアプリケーションストリーミングを自分たちの製品に統合できるようにすると考えていました。 私たちは、ゲーム開発者やグラフィックスISVがこの開発モデルを採用するだろうと考えていましたが、予想していたより多くの作業が必要であり、つかいはじめるためには重要なエンジニアリングへの投資が要求されることがわかりました。それを試した人たちはその機能セットが自分たちのニーズを満たしていないことに気づきました。 たとえば、AppStreamはg2.2xlarge EC2インスタンスをベースとしたひとつインスタンスタイプだけを提供していました。 これによって、パフォーマンスがコストを正当化できるハイエンドなアプリケーションへのサービスのみに限定されました。 しかし、経済性は多くのアプリケーションにとって割に合わないものでした。

AppStreamで、お客様の重要な問題を解決するために取り組んでいましたが、解決策を正しく得ることに失敗しました。 これは、アマゾンではあえて受け入れるリスクです。 われわれは迅速に動き、お客様を手助けすることができる分野を探求していますが、失敗の準備をします。 私たちは失敗するときに学習し、すばやく反復します。 この場合、お客様からデスクトップアプリケーションのためのよりよいソリューションが必要であることを継続的にヒアリングし、そしてふりだしに戻りました。 その結果がAppStream 2.0です。

AppStream 2.0の特長
AppStream 2.0では、オリジナルのAppStreamサービスを試していだいたお客様から聞いた課題の多くに対応しています。 こちらがにいくつかの特長です:

  • デスクトップアプリケーションをセキュアにWindowsおよびLinux PC、Mac、Chromebook上のHTML5ウェブブラウザでどのデバイスでも実行できます。
  • ユーザーがどこからでもデスクトップアプリケーションに即座にアクセスできます。遅延はなく、大きなファイルをダウンロードすることもなく、時間のかかるインストールもありません。ユーザーは、ネイティブにインストールされたアプリを実行するのと同じように、敏感で流動的なエクスペリエンスを得ることができます。
  • シンプルなエンドユーザーインターフェイスで、ユーザーはフルスクリーンモードで実行し、ブラウザタブ内で複数のアプリケーションを開き、簡単にスイッチして操作することができます。ファイルをセッションにアップロードし、アクセスして編集し、完了したらダウンロードすることができます。また、印刷や、音声の再生、そしてネットワークの状態に最適化するために帯域幅を調整することもできます。
  • アプリケーションとデータをセキュアにAWS上に保持 – 暗号化されたピクセルのみがエンドユーザーにストリーミングされます。アプリケーションストリームとユーザー入力は、HTTPS経由でAWS上のセキュアなストリーミングゲートウェイを通過するため、ファイアウォールと親和性が高いものになります。自身のVirual Private Cloud(VPC)内でアプリケーションを実行でき、Amazon VPCのセキュリティ機能を使用してアクセスを制御できます。 AppStream 2.0は、ユーザーが自社の認証情報を使用してアプリケーションにアクセスできるようにするIDフェデレーションをサポートしています。
  • フルマネージドなサービスのため、アプリケーションストリーミングインフラストラクチャを計画、デプロイ、管理、およびアップグレードする必要はありません。 AppStream 2.0は、アプリケーションのホストおよび実行に必要なAWSリソースを管理し、自動的にスケールし、必要に応じてエンドユーザへのアクセスを提供します。
  • 一貫したスケーラブルなパフォーマンスをAWSで、一般的にローカルデバイスでは利用できないコンピューティング能力にアクセスすることができます。ローカルおよびグローバルに即座にスケールし、ユーザーが低レイテンシーのエクスペリエンスをつねに得られることを保証します。
  • さまざまなストリーミングインスタンスタイプでアプリケーションを実行します。 General Purpose、Compute Optimized、およびMemory Optimizedインスタンスファミリーのインスタンスタイプを使用して、アプリケーションのパフォーマンスを最適化し、全体のコストを削減することができます。
  • ハイパフォーマンスなストリーミングのためのNICE DCVは、アプリケーションにセキュアでハイパフォーマンスなアクセスを提供します。 NICE DCVは流動的でインタラクティブな体験を提供し、ネットワークの状態に自動的に適応します。

価格と利用可能なリージョン
AppStream 2.0では、使用するストリーミングインスタンスに対してのみ料金を支払います。 ストリーミングインスタンスの料金は、選択したインスタンスの種類、およびアプリケーションにアクセスする同時ユーザーの最大数によります。

特定の月にリージョン内のアプリケーションにアクセスするユニークな認可されたユーザーごとにユーザーフィーが課金されます。 ユーザーフィーはMicrosoft RDS SALライセンスをカバーしており、MicrosoftのライセンスモビリティプログラムによってRDS CALライセンスを持ち込むする場合は免除されます。 AppStream 2.0には、つかいはじめるための管理者体験を提供する無料利用枠があります。 無料利用枠には、最長2ヶ月間、月40時間が含まれます。 詳細については、こちらのページを参照してください。

AppStream 2.0は、米国東部(北バージニア)、米国西部(オレゴン)、ヨーロッパ(アイルランド)、および東京リージョンで利用可能です。 AppStream 2.0に既にインストールされているサンプルアプリケーションにアクセスすることで、今すぐに無料でAppStream 2.0のエンドユーザエクスペリエンスを試すことができます。Try It Nowにアクセスするには、AWSアカウントでログインし、Get Startedを選択してください。

AppStream 2.0,についてもっとよく知るには、AppStream pageにアクセスしてください。

Gene Farrell, Vice President, AWS Enterprise Applications & EC2 Windows

(日本語訳はSA渡邉が担当しました。原文はAmazon AppStream 2.0 – Stream Desktop Apps from AWS

新機能 – Virtual Private Cloud での EC2 インスタンスの IPv6 サポート

インターネットは、特にモバイルアプリケーション、コネクテッドデバイス、そしてIoTの分野で引き続き成長しており、それが業界全体のIPv6への移行に拍車をかけています。米国政府機関は2010年に定められた指令に従って、パブリックに公開されたサーバーとサービスをできるだけすみやかにIPv6に移行するように取り組んでいます。128ビットのアドレス空間を持つIPv6では十分な拡張の余地があり、新しいアプリケーションやユースケースへの道が開かれます。

EC2のIPv6

今年の初めに、S3 (Transfer Accelerationを含む)、CloudFrontWAF、および Route 53のIPv6サポートを開始しました。本日、新しい大きなステップとして、Virtual Private Cloud (VPC) およびEC2インスタンスのIPv6サポートを開始しました。米国東部 (オハイオ) リージョンを皮切りに、他のリージョンも対応を進めていきます。

IPv6サポートは、新規および既存のVPCで利用できます。マネジメントコンソール上でチェックボックスにチェックを入れるだけで、VPCごとにオプトインすることができます (APIとCLIもサポートされます)。

(more…)

AWS Shield – DDoS攻撃からアプリケーションを保護

オンラインの世界は時として不愉快な場所です!あなたがウェブサイトを公開するや否や、問題を起こしたり、サイトを停止させようとする多くの種類の攻撃の標的にされます。DDoS (分散型サービス妨害) 攻撃は非常に一般的な問題の一つです。攻撃者はウェブ上のあらゆる侵害されたリソースを利用し、活動を特定の標的に集中させます。

DDoS攻撃には一般的に3つの種類があります。

アプリケーション層攻撃 はアプリケーションのリソースを消費するように設計された、整形式かつ悪意のあるリクエスト(HTTP GETやDNSクエリが一般的)からなります。たとえば複数のHTTP接続を開き、数秒または数分かけてレスポンスを読むことで、過剰にメモリが消費され、正当なリクエストが処理されなくなります。

State-Exhaustion 攻撃 はステートフルなプロトコルを悪用し、一接続当たりに多くのリソースを消費させることでファイヤーウォールや負荷分散装置に負荷を与えます。

ボリューム攻撃 は対処しきれないほどの大量なトラフィックを送りつけたり、無防備な被害者に驚くほど大量の低レベル”surprise”応答を送りつける偽クエリを発行(別名:リフレクション攻撃)させて、ネットワークを不通にします。

新サービス – AWS Shield

AWS Shieldは新しいマネージドサービスで、ウェブアプリケーションをDDoS (分散型サービス妨害) 攻撃から保護します。Elastic Load BalancingAmazon CloudFrontAmazon Route 53と連携して動作し、様々なタイプ、形状、サイズの攻撃からお客様を保護します。このサービスには二つのTierがあります。

AWS Shield Standard は追加費用なしで、すべてのAWS顧客が利用できます。 SYN/ACK フラッド、リフレクション攻撃、HTTPスローリードなど、今日最も一般的な攻撃の96%からお客様を守ります。 この保護は、Elastic Load Balancer、CloudFrontディストリビューション、Route 53リソースに自動的かつ透過的に適用されます。

AWS Shield Advanced は、ボリューム攻撃に対する追加のDDoS軽減機能、インテリジェントな攻撃検出、アプリケーションおよびネットワーク層での攻撃に対する軽減を提供します。 攻撃の軽減のカスタマイズ、高度なリアルタイムメトリクスとレポート、DDoS攻撃の影響で請求金額が跳ね上がるのを防ぐDDoSコスト保護のために、私たちのDDoSレスポンスチーム(DRT)に24時間365日アクセスできます。

詳しくは、AWS Shield もしくは Get Started with AWS Shield Advanced をご参照ください。

原文:AWS Shield – Protect your Applications from DDoS Attacks (翻訳:Security Solutions Architect 桐山 隼人)

AWS Step Functions – ビジュアルワークフローを使ったアプリケーションのビルドと配布

私たちは、ビルドの複雑性や配布されたアプリケーションを、多数のWebアプリやマイクロサービスの連携によってより簡易にしたいと考えています。あなたが複雑なビジネスプロセスを構築しているか写真のアップロードのプロセスをセットアップしているかに関わらず、あなたはコーディネーションではなくコードにフォーカスしてほしいと、私たちは思っています。また、あなたがツールやライブラリに既に明るくなっていてそれらを使うことで、可用性の高いアプリケーション、つまり強固であり、スケーラブルであり、コスト優位性があり、を構築できるようになってほしいと思っています。

 

AWS Step Functionsの概要

まさに上記に述べたことを実現していただくために、本日私たちはAWS Step Functionをリリースしました。これにより、あなたは、ビジュアルなワークフローにて、アプリケーションのコンポーネントを一連のステップとしてコーディネートすることが出来ます。あなたは、アプリケーション実行のスケール時にステップの特定や実行をするために”Step Function Console”により、”state machine”(マシン状態)を生成します。どのstate machineも”tate”のセットとそれらのトランザクションを定義します。”state”は直列や並列でアクティベートされることが可能です。並列のときは、Step Functionは、次に進む前に、全てのパラレルstateが完了に向けて実行されます。その結果、Statsは実行し、判断し、state machineを通してプロセスの進捗をコントロールします。

この図はstate machineの概要です。

 

 

複数のそれらのstate machineのコピーは、同時に独立して実行させることが可能です。そのとき、どのコピーも1つの実行と呼ばれます。このようにして、Step Functionsにより数千の同時実行もさせるこが出来るため、どのような要求レベルであってもスケールさせることが可能です。

stateが実行されたときに何を起こさせるかを指定するために2つの方法があります。1つは、stateが実行されたときに同期的に呼び出されるLambda関数を使う方法です。もう1つは、Activityと呼ばれるものを使う方法です。これは、長時間実行ワーカー関数の参照実装です。この参照実装では、APIを使ってworkの完了をポーリングします。どちらの方法でも、コードはインプットとしてJSON形式で、またアウトプット形式は別の型のJSON形式が期待されます。

state machineの機能として、エラーハンドリング時の挙動やリトライロジックを組み込むことが出来ます。これにより、あなたのコードの一部の問題により一時的な問題発生が起こったとしてもスムーズに実行できる、強固なアプリケーションをビルドできることになります。

 

クイックツアー

それでは、AWS Management Consoleを使ってstate machineをセットアップしてみましょう。本番のアプリケーションでは、ほとんどの場合、実行やstate machine生成にAWS Step FunctionのAPIを使うことにご留意ください。

まずシンプルなLambda関数を生成して保存します。

 

その間に、functionのARNを記録しておきます。

 

そしてAWS Step Functions Consoleに行き、「 Create a State Machine」ボタンを押します。マシン名(ここでは「MyStateMachine」) を入力し、実行開始のためにblueprintsから1つを選んでクリックします。

 

ここでは、MyStateMachineにこのJSONモデルを生成するためのParallelエレメントとHello Worldを使って開始します。

{
  "Comment": "A simple example of the Steps language using an AWS Lambda Function",
  "StartAt": "Hello",

  "States": {
    "Hello": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:eu-west-1:99999999999:function:HelloWord_Step",
      "Next": "Parallel"
    },

    "Parallel": {
      "Type": "Parallel",
      "Next": "Goodbye",
      "Branches": [
        {
          "StartAt": "p1",
          "States": {
            "p1": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:eu-west-1:9999999999:function:HelloWord_Step",
              "End": true
            }
          }
        },

        {
          "StartAt": "p2",
          "States": {
            "p2": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:eu-west-1:99999999999:function:HelloWord_Step",
              "End": true
            }
          }
        }
      ]
    },

    "Goodbye": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:eu-west-1:99999999999:function:HelloWord_Step",
      "End": true
    }
  }
}

 

グラフィカルに確認するために”Preview”ボタンを押します。

 

次に、自分のために適切に生成された、Step FunctionのIAMロールを選択します。

 

これで全てです!これで、コンソールから生成したstate machineを実行できます。つまり、最初のLambda関数をパスするJSONブロックで実行させることが出来ます。

 

Start Exctionボタンを押すとすぐに、定義したstate machineは実行するために開始します。state間を遷移する実行フローを確認することが出来ます。

 

また、Lamdaコンソールに行き、自分の関数の実行が期待どおり4回であることを確認できます。(事前に4回のクリックと、別々の4つのLambda関数の生成は苦に思わないとして)

 

AWS Step Functionsは、どのステップに関する全ての情報を記録しており、Step Consoleを使って確認することが出来ます。

 

AWS Step Functions API

前述のとおり、ほとんどのAWS Step Functions操作はAPIを通じて行われると思いますので、ここに、基本的な関数の概要を記載します。

  • CreateStateMachine – JSON定義による新規state machineの生成
  • ListStateMachines – state machineの一覧表示
  • StartExecution – (非同期な)state machineの実行
  • DescribeExecution – 実行に関する情報取得
  • GetActivityTask – 実行のための、新taskのポーリング(長時間実行ワーカーによる)

また、S3バケットにファイルがアップロードされるたびにLambda関数が実行されるようにすることもできました。

この関数は、StartExecutionを使ってstate machineをキックでき可能です。たとえばこのstate machineはイメージファイルの検査をしたり、複数のサイズ生成を並列的に実行したり、特定のタイプをチェックしたり、Databaseをアップデートさせたりすることが可能です。

同様の機能は、AWS Command Line Interface(CLI)によっても可能です。

 

開発ツール

手書きもしくは自動生成のJSON、それは共通エラーチェックやをチェックするために、新しい、statelint gemを使うことが出来ます。

AWS GitHub repoからダウンロードしインストールしてみてください。(Rubyの場合は、RubyGems

$ sudo gem install j2119-0.1.0.gem statelint-0.1.0.gem

以下は、もし問題があった場合の表示です。

$ statelint my_state.json
2 errors:
State Machine.States.Goodbye does not have required field "Next"
No terminal state found in machine at State Machine.States

問題ない場合は、以下のようになります。

$ statelint my_state.json
$

 

利用可能です

AWS Step Functionsは利用可能です。現在、US East (Northern Virginia)、US East (Ohio)、US West (Oregon)、EU (Ireland)、Asia Pacific (Tokyo) のリージョンで利用可能です。

AWS Free Tierの一部として、月間4,000までのstate transitionは無料です。それ以降は1,000state transtionにつき0.025USD課金されます。

 

Jeff;

原文:New – AWS Step Functions – Build Distributed Applications Using Visual Workflows(翻訳:市崎 洋平)

Lambda@Edge – プレビュー

ちょうど先週、私が Hacker News上で書いたコメントがきっかけでAWSのお客様から興味深いメールを頂きました。

彼はS3上でホストしているシングルページのアプリケーションを動作させていて(こちらについてはAmazon S3で静的なWebサイトの運用が可能に をご覧下さい。)、Amazon CloudFrontを経由して少ないレイテンシーで提供していると教えてくれました。そのページは、AWS Elastic Beanstalk上でホストしているAPIを使って、それぞれのユーザー向けにカスタマイズして表示するいくつかの動的な要素を含みます。

彼が説明してくれた彼の課題はこちらです。

適切に検索エンジンのインデックスを取得するために、またFacebookやTwitterないで正しく表示するためのコンテンツのプレビューをするためには、それぞれのページが事前に表示されたバージョンを提供する必要があります。こちらを実現するには、一般ユーザーがヒットするたびに、私たちのサイトはノーマルのフロントエンドをCloudFrontから提供する必要があります。しかし、もしユーザーエージェントがGoogle / Facebook / Twitter等にマッチする場合は、その代りに私たちは事前に表示されたバージョンへリダイレクトさせる必要があります。

私たちはこのユースケースについてよく分かっており、興味深いソリューションを準備中であることを彼に秘密を漏らすことなく伝えました。他のお客様もまた、エッジにおいてクイックな判定によりカスタマイズしたいと伝えてくれてました。

お客様に近いロケーションでHTTPリクエストを”賢く”処理しなければならないユースケースがあることがわかりました。これらには、HTTPヘッダの検査および変更、アクセスコントロール(特定のcookieを必要とする)、デバイス検出、A/Bテスト、クローラーまたはbotsのための処理または特別な対応、レガシーシステムに適応させるためにユーザーフレンドリーなURLを書き換えるユースケースを含みます。多くのこれらのユースケースは、シンプルなパターンマッチングやルールによって表現可能なユースケースよりも多くの処理や判定を必要とします。

Lambda@Edge
これらのユースケースのサポートを提供するために、私はLambda@Edgeのプレビューをラウンチしています。この新しいLambdaベースの処理モデルにより、ますます増加するAWSエッジロケーションのネットワーク内で動作するJavaScriptコードを書くことが出来ます。

CloudFrontのディストリビューションを通して流れるリクエストやレスポンスを処理する軽量なロジックを書くことができます。4つの異なるイベントに対するレスポンスの中でコードを実行できます。

Viewer リクエスト – あなたのコードは、コンテンツがキャッシュされるか否かに関わらず、あらゆるリクエストにおいて動作します。こちらがシンプルなヘッダ処理用のコードです。

exports.viewer_request_handler = function(event, context) {
  var headers = event.Records[0].cf.request.headers;
  for (var header in headers) {
    headers["X-".concat(header)] = headers[header];
  }
  context.succeed(event.Records[0].cf.request);
}

Origin リクエスト – リクエストされたコンテンツがエッジでキャッシュされていない時に、Originに転送される前にコードを実行します。ヘッダを追加したり、既存のヘッダを編集したり、URLを編集したりすることが可能です。

Viewer レスポンス – キャッシュされているか否かに関わらず、すべてのレスポンスにおいてコードを実行します。Viewerに戻す必要のないヘッダをクリーンアップするためにこちらを利用できます。

Origin レスポンス – キャッシュミスにより Originへコンテンツを取りに行き、エッジへレスポンスを戻した後でコードを実行します。

リクエストやレスポンスに含まれるURLやメソッド、HTTPバージョン、クライアントIPアドレス、ヘッダなどのさまざまな要素へコードからアクセスできます。まず最初にヘッダを追加、削除、そして編集することができるようになる予定です。すぐに、bodyを含むすべての値に対して読み込み/書き込みの完全なアクセスができるようになる予定です。

JavaScriptコードは、リクエスト/レスポンスパスの一部になるでしょう、そしてそれは効率的で、重要で、自己完結型のものでなければなりません。他のWebサービスをコールすることは出来ません、また他のAWSリソースへアクセスできません。128MBメモリ内で動作しなければならず、また50ms以内で完了しなければなりません。

開始するには、新しいLambda function を作成して、あなたのディストリビューションをトリガーとして設定し、新しいエッジランタイムを選択します。

その後で通常通りコードを書きます。Lambdaはエッジロケーションでの舞台裏での処理をしてくれます。

興味深いですか?
このクールな新しい処理モデルはいくつかのとてもクールな新しいアプリケーションや開発ツールの作成を導いてくれると信じています。あなたがこちらを使って何をもたらしてくれるか待ちきれません。

私たちは本日Lambda@Edgeの制限付きのプレビューをラウンチします、そして利用者を募集しています。もしあなたが関連しそうなユースケースをお持ちで、こちらを試す準備が出来れいれば、ぜひこちらにご応募ください。

-Jeff

翻訳は舟崎が担当しました。原文はこちらです。

AWS Batch – AWSでバッチ処理ジョブを実行する

私は1978年秋に大学に入学しました。モンゴメリー・カレッジのコンピュータ・サイエンス部門は、強力な(当時の)IBM 370/168メインフレームを中心に構築されました。 Keypunchマシンを使用してカードデッキを準備する方法、実際のコードの前にジョブの名前と優先順位を設定し、FORTRAN、COBOL、またはPL / Iコンパイラを呼び出す暗黙のジョブ制御言語(JCL) 。デッキを提出ウィンドウに持ってきて、ジョブIDと引き換えにオペレーターに渡してから、数時間後に戻って印刷出力とカードデッキを回収します。私はその印刷物を慎重に研究しましたが、仕事に就いて数時間を待ってから、実際の稼動時間はほんの数秒であったことに気付いていました。仲間の学生と私がすぐに学んだように、学校のIT部門が開始した仕事は優先順位4で実行され、私たちは8で実行されました。彼らの仕事は私たちよりも優先されました。優先順位の高いメカニズムの目標は、高価なハードウェアを可能な限り完全に使用することでした。学生の生産性は、リソースの効率的な使用に引き続き二次的でした。

今日のバッチコンピューティング
今日、バッチ・コンピューティングは依然として重要です!より簡単にコンピューティングパワーにアクセスすることで、映画スタジオ、科学者、研究者、数値アナリストなどがこれまで以上に多くのコンピューティングサイクルを楽しめるようになりました。多くの組織では、オープンソースまたは商用ジョブスケジューラを搭載した社内の計算クラスタを構築することによって、これらのニーズに対応しようとしています。三度、優先順位が立ちはだかり、依然として、決して十分な計算能力がないようです。クラスタは、構築・運用するのに費用がかかり、同一の、ほぼ差異のないプロセッサの大きな配列で構成され、ビンテージとまったく同じ仕様に構築されることが多い。

クラウドコンピューティングは、さまざまな種類のEC2インスタンスへの迅速なアクセス、ニーズの変化に対応して拡大縮小する機能、および、必要なキャパシティに対して入札を行い、可能な限り経済的にそれを得られる価格モデルによって、バッチコンピューティングモデルをより良いものに変える可能性を秘めています。これまで、多くのAWSのお客様は、EC2インスタンス、コンテナ、通知、CloudWatchモニタリングなどを使用して独自のバッチ処理システムを構築してきました。これは非常に一般的なAWSユースケースであることが判明し、バッチ処理システムの構築を達成することをさらに容易にすることに決めました。

AWS Batchの紹介
今日、完全に管理されたバッチ機能の新しいセットについてお話したいと思います。 AWS Batchにより、バッチ管理者、開発者、およびユーザーは、クラスタのプロビジョニング、管理、監視、またはメンテナンスを行うことなく、クラウドのパワーにアクセスできます。購入するものはなく、インストールするソフトウェアはありません。 AWS Batchは、特に違いを生まない重い作業を処理し、EC2インスタンスの動的にスケーリングされたセットでコンテナイメージとアプリケーションを実行できるようにします。 Amazon EC2とEC2 Spotによって提供される弾力性と選択性を活かした並列ジョブを大量に実行することができ、効率的で使いやすく、クラウド向けに設計されており、他のAWSサービスAmazon S3、DynamoDB、およびSNSが含まれます。

(more…)

AWS Personal Health Dashboard – 関係するリソースの管理

AWS Service Heath Dashboardをリリースしたのは2008年になります。当時はAWS Cloudは比較的新しく、各サービスの利用状態を確認するのにいい手段でした(現在のService Health Dashboardと比べると、この8年でAWSがどのくらい成長した化が見て取れます)。

現在のダッシュボードは、AWSサービス毎の状態を俯瞰的に表示するため、個別最適されたダッシュボードというわけれではありませんでした。そのため、お客様と会話をすると、全体的なダッシュボードというよりは、お客様の利用サービス、リソースに合わせた状態管理を希望されることもありました。

新サービス Personal Health Dashboard
関心のあるサービスについてより多くの情報を提供できるよう、AWS Personal Health Dashboardをリリースしました。サービス名の通り、このダッシュボードは利用しているAWSサービスのパフォーマンス、可用性に関した個別のビューのみならず、サービスの状態に変化が会った際にはアラートを自動的に発行します。利用中のサービスに関して一元的に監視するためにデザインされており、影響を及ぼすであろう問題に関して、より詳細に可視化することが可能です。ダッシュボードに関係する情報が登録されると、コンソールから通知アイコンを確認出来ます。
1

“issues”をクリックすると、影響するであろうAWSインフラストラクチャが確認できます(これらのデータはすべてテストデータです)。
2

アイテムをクリックするとその問題を修復するためのガイダンスを含むより詳細の情報を確認することができます。
3

また事前に予定されているアクティビティを確認することで注意喚起をうながすこともできます。
4

それ以外にも、興味のあるサービスについての情報を確認することもできます。
5

またCloudWatch Eventsと連携することで、アラート対応でしたり、スケジュールイベント対応を自動化させることも可能です。例えば、自主的にメンテナンスイベント対応が必要なEC2インスタンスを移動することで、メンテナンスイベント通知対応が可能になります。

ご自身のアカウントがビジネスサポート、もしくはエンタープライズサポートに加入頂いてる場合、この新しいAWS Health APIをご利用頂けます。このAPIを使い、Personal HealthDashboardの情報をを既存のITマネジメントツールとの連携されることがが可能になります。

– Jeff(翻訳はSA酒徳が担当しました。原文はこちら)

Blox – Amazon EC2 Container Serviceのための新しいオープンソーススケジューラ

2014年、私はAmazon ECSについてお話して、Dockerベースのアプリケーションをビルドし実行し、そしてスケールさせることを如何に手助けしてくれるかをご紹介しました。そこでは3つのスケジューリングの選択肢(自動、手動、そしてカスタム)について話をし、スケジューラがインスタンスにどの様にタスクを割り当てるかを説明しました。

その時書いた記事では、カスタムスケジューラは現在のクラスタの状態を見るためにListContainerInstancesDescribeContainerInstancesを定期的に呼び出す必要があると記しました。数週前、CloudWatch Eventsのサポートを追加することで各クラスタの状態を追跡する処理を簡素化しました。(これについて詳しくは、Amazon ECSイベントストリームで、クラスタの状態を監視をご覧下さい)

この新しいイベントストリームが出たので、我々はカスタムスケジューラの作成をもっと簡単にしたいと思います。

本日、我々はBloxを開始します。この新しいオープンソースプロジェクトには、イベントストリームを処理してクラスタの状態を追跡し、状態をREST APIで利用可能にするサービスが含まれています。また、クラスタ内の各コンテナインスタンスにタスクを1つだけ実行するデーモンスケジューラも含まれています。このコンテナを1つずつ配置するモデルで、ログ処理やメトリクス収集のワークロードをサポートします。

こちらが”ブロック図”です (ダジャレじゃありません ※訳注 BloxとBlockをかけています):

これはオープンソースのプロジェクトです; プルリクエストや機能要望を楽しみにしています。詳しい情報は、Amazon EC2 Container Serviceより、Bloxをご紹介をご覧下さい。

Jeff;

原文: Blox – New Open Source Scheduler for Amazon EC2 Container Service (翻訳: SA岩永)

AWS CodeBuild ― フルマネージドのビルドサービス

開発者は通常、ソースコードの変更に対する継続的インテグレーションのビルドとテストを実行するために、共有のビルドサーバを構築し運用しなければいけません。継続的インテグレーションを運用するのは面倒なことなので、多くの開発者はそれを避けてローカルマシンでビルドを実行します。これによって、ある開発者の環境では動作するコードが最終的な本番環境ビルドで動作しないという状況が、しばしば引き起こされます。

多くの開発チームは、CI/CD(継続的インテグレーション / 継続的デプロイ)パイプラインの構成要素としてビルドファームを構築します。ビルドファームの構築と運用はコストが高く、また独特のスキルが求められます。普段はビルドファームはあまり使われていませんが、修羅場の時には利用率は100%に達し、未処理のビルドリクエストが増えてしまいます。

(more…)