Amazon Web Services ブログ

AWS が 7 年連続でガートナーのサービスとしてのインフラストラクチャ (IaaS) に関するマジッククアドラントでリーダーとして認定される

AWS での各製品計画セッションはお客様を中心に進められています。当社は最善を尽くしてお客様の声に耳を傾け、それに基づいて将来の開発のロードマップを構築しています。ロードマップの項目の約 90% はお客様のリクエストに基づくものであり、お客様から寄せられた特定のニーズや要件を満たすよう設計されています。

このお客様主導のイノベーションにより、7 年連続でガートナーのサービスとしてのインフラストラクチャ (IaaS) に関するマジッククアドラントで当社が「リーダー」クアドラントで最上位の地位を確保し、最も高い実行力と先見性のあるビジョンを持っていると評価されたものと確信しています。

詳細については、レポートの全文をお読みください。このレポートには多くの詳細が含まれており、お客様がクラウドプロバイダーを選ぶときに確認する機能や要素がよくまとめられています。

Jeff;

新機能 – Auto Scaling for Amazon DynamoDBについて

Amazon DynamoDBには幅広い業界やユースケースを含む10万人以上の多くのお客様がいます。 お客様は世界中の16の地域で、DynamoDBの一貫性のあるパフォーマンスを利用する事が出来ます。 最近の傾向は、DynamoDBを使用してサーバレスアプリケーションと組み合わせるお客様です。 この使い方は非常にマッチします:DynamoDBでは、サーバーのプロビジョニング、OSとデータベースのソフトウェアパッチ適用、または高可用性を確保するためのAZゾーン間のレプリケーションの設定などを考える必要はありません。テーブルを作成してデータを追加するだけでDynamoDBが処理するようにします。

DynamoDBにはプロビジョニングキャパシティーユニットモデルが用意されており、アプリケーションで必要とされる読み書き容量を設定できます。 これによりサーバの考え方から解放され、簡単なAPIコールまたはAWS Management Consoleのボタンをクリックしてテーブルのプロビジョニングを変更できるようになりましたが、多くのお客様はDynamoDBの容量をさらに簡単に管理できるように望んでいました。

本日、DynamoDBのAuto Scalingを導入して、テーブルとグローバルセカンダリインデックス(GSI)の容量管理を自動化できるようになりました。 維持をしたい使用率を指定し、読み書き容量の上限と下限を指定するだけです。 DynamoDBは、Amazon CloudWatchアラームを使用して消費量を監視し、必要に応じてプロビジョニングされた容量を調整します。 Auto Scalingは、すべての新しいテーブルとインデックスに対してデフォルトでオンに出来ます(但しIAM権限の事前準備が必要です)。また、既存のテーブルやインデックスに対しても設定できます。

あなたが常にマネジメントコンソールに張り付いていなくても、DynamoDB Auto Scalingはテーブルとインデックスを監視して、アプリケーショントラフィックの変化に応じて自動的にスループットを調整します。 これによりDynamoDBデータの管理が容易になり、アプリケーションの可用性を最大化しDynamoDBのコストを削減するのに役立ちます。

どのような機能か早速御覧ください。

Using Auto Scaling

新しいテーブルを作成するときに、DynamoDB Consoleにデフォルトパラメータセットが提示されるようになりました。 あなたはそのまま利用する事も、「Use default settings」のチェックを外して独自のパラメータを入力することもできます

独自にパラメータを設定する方法は以下の通りです。

Target utilizationは、消費容量とプロビジョニングされた容量の比率で表されます。 上記のパラメータは、読み取りまたは書き込み要求が増えた時でも消費される容量の2倍になるように十分な空き容量を確保します(DynamoDBの読み書き操作とプロビジョニングされた容量の関係の詳細については容量単位の計算を参照してください)。 プロビジョニングされた容量の変更は、バックグラウンドで行われます。

Auto Scaling in Action

この重要な新機能が実際に動作するのを見るために、「Getting Started Guide」の指示に従いました。 私は、新しくEC2インスタンス起動し、AWS SDK for Pythonを設定(sudo pip install boto3)を実行し利用するための設定(aws configure)を行いました。 次に、PythonとDynamoDBのコードを使用していくつかのデータを含むテーブルを作成し、読み込みと書き込みの各容量を5ずつ手動で設定しました。

CloudWatchメトリクスで綺麗な直線を得るために私は急いで休憩を取ったので、AutoScalingの効果を示すことができました。 負荷を適用する前のメトリクスは次のとおりです。

私はステップ3のコードを変更して、1920年から2007年の範囲でランダムにクエリを発行し、1〜2分後に読み取りメトリクスを確認しました。

消費された容量はプロビジョニングされた容量よりも多く、その結果多くの読み込みリクエストに対してスロットルが発生します。 AutoScalingが実行される!

私はコンソールに戻ってテーブルのCapacityタブをクリックした。 Read capacityをクリックし、デフォルト値を受け入れ、Saveをクリックしました

DynamoDBは新しいIAMロール(DynamoDBAutoscaleRole)とCloudWatchアラームのペアを作成して、読み取り容量のAuto Scalingを設定しました。

DynamoDB Auto Scalingはアラームのしきい値を管理し、スケーリングプロセスの一部としてアラームのしきい値を上下に調整します。 最初のアラームがトリガーされ追加の読み取り容量がプロビジョニングされている間にテーブルの状態が[Updating]に変更されました。

この変更は、数分で読み取りメトリクスに表示されました。

私は変更されたクエリスクリプトをいくつか実行し、追加の容量がプロビジョニングされているのを見てみました。

私はすべてのスクリプトを停止しスケールダウンアラームが発生するのを待ちました。:

翌朝Scaling activitiesを確認し、アラームが夜の間に何度かトリガされたことを確認しました:

これはメトリクスにも表示されていました。

これまでは、あなたが期待した使用量についてプロビジョンキャパシティユニットを十分に設定し、余裕を持たせる設定(青い線と赤い線の間のスペース)を行うことで、このような状況に備えることができました。若しくはプロビジョンキャパシティユニットを少なくしすぎ、監視するのを忘れてトラフィックが増えた時に容量が使い果たされる可能性がありました。 Auto Scalingを使用すると、リクエストが増加し必要な場合は自動的に増やし、もう不要な時は自動的に下げる事が可能です。

Things to Know

DynamoDB Auto Scalingは、ある程度予測可能である程度定期的に変化する要求レートに対応するように設計されています。予期せぬバーストした読み取りアクティビティに対応する必要がある場合は、Auto ScalingをDAXと組み合わせて使用​​する必要があります(詳細は、Amazon DynamoDB Accelerator(DAX) – Read heavyなワークロード向けインメモリ型キャッシュクラスタを参照してください)。また、AWS SDKを利用したアプリケーションは、スロットリングされた読み込み要求と書き込み要求を検出し、適切な遅延の後に再試行します。

(補足:Auto Scaling実行され実際に使える容量が増えるまでにはどうしても時間が掛かります。その為瞬間的なリクエスト増加に対応するのは難しいケースがあります。その為、瞬間的なリクエスト増加に対応するにはDAXなどのソリューションと組み合わせる事や、瞬間的にスロットリングが発生してもリトライで処理を継続させる事により影響を最小限にする処理が必要です。)

 

私はDynamoDBAutoscaleRoleを先に述べました。このロールは、テーブルとインデックスのスケールを上下させるために必要な権限をAuto Scalingに提供します。このロールと権限の詳細については、「Grant User Permissions for DynamoDB Auto Scaling」を参照してください。

Auto ScalingにはAuto Scalingポリシーを有効または無効にする機能を含むCLIとAPIの完全なサポートがあります。トラフィックに予測可能な時間的なスパイクがある場合(ゲームなどであれば決まった時間に発生するイベントなど)は、プログラムによって自動スケーリングポリシーを無効にし、一定期間高いスループットをプロビジョニングしてから、後でAuto Scalingを再度有効にすることができます。

DynamoDBの制限ページに記載されているように、プロビジョニングされた容量は、必要に応じて必要なだけ増やすことができます(アカウントごとに設定されている上限内にて)。各テーブルまたはグローバルセカンダリインデックスごとに1日に最大9回まで容量を減らすことができます。(その為、あまり頻繁に容量を下げる設定にしてしまうとこの回数を使い切ってしまいその後下げる事が一時的に出来なくなる可能性があります。)

実際に実行された容量は通常のDynamoDBの価格が掛かります。さらに節約するためにDynamoDBのリザーブドキャパシティユニットを購入することもできます。

今すぐ利用可能
この機能は現在すべての地域で利用可能で、今すぐ使用することができます!

Jeff;

(この記事はSA 成田が翻訳しました。原文はこちら

 

 

 

EC2 Run Command を使用した、SSH アクセスなしでの大規模なインスタンスの管理

Ananth Vaidyanathan (EC2 Systems Manager のシニア製品マネージャー) および Rich Urmston (Pegasystems のクラウドアーキテクチャのシニアディレクター) によって書かれた次のゲスト投稿は、EC2 Run Command を使用して、SSH を用いることなく EC2 インスタンスの大量のコレクションを管理する方法を示しています。

Jeff;


多くの場合、エンタープライズは管理対象環境および数千の Amazon EC2 インスタンスを持っています。Secure Shell (SSH) について悩むことなく、システムをセキュアに管理することが重要です。Amazon EC2 Systems Manager の一部である Run Command では、制御され管理可能な方法で、インスタンス (またはタグを使用してインスタンスのグループ) でリモートコマンドを実行できます。これは、Run Command サービスに毎日依存する Pega Cloud オペレーションにとって、生産性を向上するための優れた追加機能です。標準の IAM ロールとポリシーを通じた Run Command の制御、ドキュメントの定義による入力パラメーターの使用、コマンド出力を返すために使用される S3 バケットの制御が可能です。また、他の AWS アカウントや一般ユーザーとドキュメントを共有することもできます。全体として、Run コマンドは優れた一連のリモート管理機能を提供します。

SSH よりも優れる
Run Command が SSH よりも優れたオプションであり、Pegasystems がこれを主要なリモート管理ツールとして採用した理由を示します。Run Command にかかる時間が短い – インスタンスへのセキュアな接続では、接続するジャンプボックス、ホワイトリストに登録する IP アドレスなど、いくつかのステップが必要です。Run Command では、クラウド Ops エンジニアはノートパソコンから直接コマンドを呼び出すことができ、キーやインスタンス ID を探す必要はありません。代わりに、システムセキュリティは AWS 認証、IAM ロールとポリシーに依存します。Run Command オペレーションは完全に監査される – SSH では、実行できる操作に実質的な制御はなく、監査証跡もありません。Run Command では、呼び出された各オペレーションは CloudTrail で監査されます。これには、呼び出し元のユーザーの情報、コマンドが実行されたインスタンス、パラメーター、およびオペレーションのステータスが含まれます。お客様は完全なコントロールを持ち、システムでエンジニアが実行できる機能を制限することができます。Run Command には管理する SSH キーがない – Run Command は標準の AWS 認証情報、API キー、および IAM ポリシーを利用します。エンジニアは、企業認証システムとの統合を通じて、企業の認証情報と ID に基づいてシステムとやり取りします。Run Command は同時に複数のシステムを管理できる – Linux サービスのステータスの確認や、マネージドインスタンスのフリート全体のログファイルの取得などの簡単なタスクでも、SSH を使用すると手間がかかります。Run Command では、ID またはタグでインスタンスのリストを指定し、指定したフリート全体に対して並行してコマンドを呼び出すことができます。これにより、最小の Pega クラスターよりも多くをトラブルシューティングまたは管理する場合に、高い利用価値が得られます。Run Command により複雑なタスクの自動化が簡単に – 操作タスクの標準化では、正確なコマンドを記述する詳細な手順のドキュメントやスクリプトが必要です。フリート全体でこうしたスクリプトを管理またはデプロイするのは面倒です。Run Command ドキュメントにより、複雑な関数をカプセル化し、ドキュメント管理とアクセスコントロールに対応するための簡単な方法が得られます。ドキュメントは、AWS Lambda と組み合わせると、複雑なタスクを処理するための強力なオートメーションプラットフォームを提供します。

例 – Docker コンテナの再起動
Docker コンテナの再起動に使用されるシンプルなドキュメントの例を示します。これには 1 つのパラメーター (再起動する Docker コンテナの名前) があります。ドキュメントは AWS-RunShellScript メソッドを使用してコマンドを呼び出します。出力はサービスにより自動的に収集され、呼び出し元に返されます。最新のドキュメントスキーマの例については、「Systems Manager ドキュメントの作成」を参照してください。

{
  "schemaVersion":"1.2",
  "description":"指定された Docker コンテナを再起動します。",
  "parameters":{
    "param":{
      "type":"String",
      "description":"(必須) 再起動するコンテナの名前。",
      "maxChars":1024
    }
  },
  "runtimeConfig":{
    "aws:runShellScript":{
      "properties":[
        {
          "id":"0.aws:runShellScript",
          "runCommand":[
            "docker restart {{param}}"
          ]
        }
      ]
    }
  }
}

 

Pegasystems での Run Command の実行
Pegasystems プロビジョニングシステムは、Pega Cloud リソースのデプロイと更新に使用される、AWS CloudFormation 上にあります。この最上位にあるのは Pega Provisioning エンジンです。これは CloudFormation テンプレートおよび Ansible 戦略のライブラリを管理する、サーバーレスで Lambda ベースのサービスです。設定管理データベース (CMDB) は各デプロイおよび更新のすべての設定詳細と履歴を追跡し、階層ディレクトリの命名規則を使用してデータをレイアウトします。次の図は、さまざまなシステムの統合方法を示しています。

クラウドシステム管理の場合、Pega オペレーションでは、 cuttysh と呼ばれるコマンドラインバージョンと、Pega Operations Portal と呼ばれる Pega 7 プラットフォームに基づくグラフィカルバージョンを使用します。両方のツールとも、Run Command を通じて、デプロイされた環境の CMDB の参照、設定の表示、デプロイされた EC2 インスタンスの操作が可能です。

CLI のウォークスルー
お客様のデプロイを調べ、Run Command を使用してインスタンスを操作する CLI のウォークスルーを示します。 cuttysh ツールを起動すると、CMDB のルートに移動し、プロビジョニングされたお客様のリストを表示できます。

% cuttysh
d CUSTA
d CUSTB
d CUSTC
d CUSTD

CMDB は、標準 Linux シェルコマンド ( cdlscat、および grep などを使用して操作できます。s という接頭辞が付く項目は、表示可能なプロパティを持つサービスです。d という接頭辞が付く項目は、CMDB 階層でナビゲート可能なサブディレクトリです。この例では、ディレクトリを CMDB 階層の顧客の CUSTB 部分に変更し、さらに Dev ネットワークの env1 というプロビジョニングされた Pega 環境に変更します。このツールは、その環境用にプロビジョニングされたアーティファクトを表示します。これらのエントリはプロビジョニングされた CloudFormation テンプレートにマッピングされます。

> cd CUSTB
/ROOT/CUSTB/us-east-1 > cd DEV/env1

ls –l コマンドは、プロビジョニングされたリソースのバージョンを表示します。これらのバージョン番号は、Pega Cloud のバージョンを構成する CloudFormation、Ansible、その他のコンポーネントのソース管理により管理されたアーティファクトにマッピングされます。

/ROOT/CUSTB/us-east-1/DEV/env1 > ls -l
s 1.2.5 RDSDatabase 
s 1.2.5 PegaAppTier 
s 7.2.1 Pega7 

ここで、Run Command を使用して、デプロイされた環境とやり取りします。これを行うには、attach コマンドを使用して、やり取りするサービスを指定します。次の例では、Pega ウェブ層にアタッチします。CLI は、CMDB およびインスタンスタグの情報を使用して、対応する EC2 インスタンスを見つけ、それに関するいくつかの基本情報を表示します。このデプロイには 3 つのインスタンスがあります。

/ROOT/CUSTB/us-east-1/DEV/env1 > attach PegaWebTier
 # ID         State  Public Ip    Private Ip  Launch Time
 0 i-0cf0e84 running 52.63.216.42 10.96.15.70 2017-01-16 
 1 i-0043c1d running 53.47.191.22 10.96.15.43 2017-01-16 
 2 i-09b879e running 55.93.118.27 10.96.15.19 2017-01-16 

ここから、 run コマンドを使用して Run Command ドキュメントを呼び出すことができます。次の例では、 docker-ps ドキュメントをインスタンス 0 (リストの最初のインスタンス) に対して実行できます。EC2 はコマンドを実行し、出力を CLI に返します。CLI はその出力を表示します。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-ps
. . 
CONTAINER ID IMAGE             CREATED      STATUS        NAMES
2f187cc38c1  pega-7.2         10 weeks ago  Up 8 weeks    pega-web

同じコマンドおよび定義されたその他のドキュメントの一部を使用して、Docker コンテナを再起動するか、ファイルのコンテンツをローカルシステムに戻すこともできます。ファイルを取得すると、Run Command は同僚にリンクを渡す場合に備えて、コピーを S3 バケット内に残します。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-restart pega-web
..
pega-web

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 get-file /var/log/cfn-init-cmd.log
. . . . . 
get-file

データはローカルに /tmp/get-file/i-0563c9e/data にコピーされました
データは S3 (s3://my-bucket/CUSTB/cuttysh/get-file/data) でも利用できます

ここで、Run Command の機能を利用して、一度に複数の操作を実行します。次の例では、デプロイに 3 つの実行中のインスタンスをアタッチし、各インスタンスの稼働時間を確認します。 par (parallel) オプション ( run 用) を使用して、CLI はすべてのインスタンスで並列で稼働時間ドキュメントを実行するよう Run Command に伝えます。

/ROOT/CUSTB/us-east-1/DEV/env1 > run par uptime
 …
Output for: i-006bdc991385c33
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.42, 0.32, 0.30

Output for: i-09390dbff062618
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.08, 0.19, 0.22

Output for: i-08367d0114c94f1
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.36, 0.40, 0.40

コマンドが完了しました。
/ROOT/PEGACLOUD/CUSTB/us-east-1/PROD/prod1 > 

 

要約
Run Command は、システムへのアクセスを高速にして生産性を向上させ、インスタンスのグループに対してオペレーションを実行する機能を提供します。Pega Cloud のオペレーションは、他の操作ツールとともに Run Command を統合し、システム管理のためのクリーンでセキュアな方法を提供します。これにより、運用効率が向上し、管理されたデプロイでだれが何をできるかについて、より高度な管理が可能になります。Pega の継続的な改善プロセスにより、ユーザーがアクセスを必要とする理由が定期的に評価され、それらのオペレーションを、ライブラリに追加する新しい Run Command ドキュメントに変換します。その長期的な目標は、SSH を有効にしたクラウドシステムのデプロイを中止することにあります。ご不明の点またはご提案があれば、当社までコメントをお寄せください。

— Ananth および Rich

AWS CodeBuild と HashiCorp Packer を用いた AMI ビルダーの構築方法

独自の アマゾン マシン イメージ を作成し維持することは、運用とセキュリティにおけるベストプラクティスです。インフラストラクチャをコードとして維持することもまたベストプラクティスの1つです。そのため、Amazon EC2 インスタンスを素早く起動するために AMI を作成し設定する、といったことをスクリプト化するための自動化ツールを利用することには価値があります。

公開する2つの記事の最初にあたるこの記事では、AWS においてプログラマブルに AMI を作成するために AWS CodeBuild を使用します。AMI 生成の一部として、OS のパッチを適用し、バナーステートメントを設定し、よく使うソフトのいくつかをインストールし、将来的な Amazon EC2 ベースのデプロイメントへの基盤を形成します。

(more…)

Amazon Cognito ユーザープールが SAML フェデレーションをサポート [パブリックベータ]

昨年、Amazon Cognito Identity に SAML フェデレーションのサポートを追加しました。この機能は SAML レスポンスから一時的な AWS クレデンシャル情報を取得できます。 Amazon Cognito Identity は API ベースのアプローチをサポートしており、AWS クレデンシャル情報を取得するためには、SAML IdP (Identity Provider) の SAML 応答を解析し、Amazon Cognito Identity API をコールします。

Amazon Cognito ユーザープールは、あなたのモバイルおよび Web アプリに、セキュアでスケーラブルなユーザーディレクトリを使用したサインアップおよびサインイン機能を追加します。本日、Amazon Cognito ユーザープールの SAML IdP (Identity Provider) フェデレーションをアナウンスできることを嬉しく思います。本機能はユーザーディレクトリに SAML IdP のユーザーをマッピングし、 SAML IdP でユーザーを認証後にユーザープールから標準認証トークンを取得します。ユーザープールは SAML 2.0 POST Binding エンドポイントをサポートします。これにより、クライアントは SAML アサーションレスポンスの解析が不要になり、ユーザープールはユーザーエージェント (訳注: Web ブラウザ等) を介して IdP から直接 SAML レスポンスを受信します。

SAML フェデレーション機能の一つとして、ユーザープールはアプリの代わりに service provider (SP) として機能します。ユーザープールはアプリの単一のアイデンティティ管理ポイントになります。そのため、アプリは複数の SAML IdP を統合する必要はなくなります。 Amazon Cognito コンソールを利用して複数の SAML IdP を追加し、属性のマッピングを定義することで、すぐに利用を開始できます。

(more…)

6 月の AWS Black Belt オンラインセミナーのご案内 [GreenGrass緊急開催決定!]

こんにちは。プロフェッショナルサービスの宮本です。AWS Greengrassが一般利用可能となったため、AWS GreengrassのAWS Black Belt オンラインセミナーの緊急開催が決定しました!IoTデバイスからのデータ送信量が増加傾向にある昨今、GreenGrassのようにIoTデバイスのローカル環境上で実行できるアプリケーションの管理が必須な技術要素となってきています。この機会をお見逃しなく!

※サービスカットですが、火曜日のお昼開催となりますのでご注意ください。

6 月は、AWSの新サービス、機能追加のご紹介や、5月30日から6月2日まで4日間に渡って開催されたAWS Summit Tokyo 2017の振り返りなど幅広いラインナップでお送りいたします。また今年から開始したオンラインハンズオンの開催もありますので、ふるってご参加いただければと思います。

※ 2017/6/6追記: 6/20に予定していたAWS Lambda回は都合により7月に延期になりました。

6 月の開催予定

サービスカット

6/7(水) 18:00-19:00 Amazon Redshift Update – 最近追加された新機能とRedshift Spectrumの解説
6/14(水) 18:00-19:00 AWS Snowball
6/21(水) 18:00-19:00 Server Migration Service Application Discovery Service
6/27(火) 12:00-13:00 AWS Greengrass
6/28(水) 18:00-19:00 AWS Code Services Part 2

ソリューションカット

6/13(火) 12:00-13:00 AWS Summit Tokyo 2017 まとめ

ハンズオン

6/28(水) 14:00-16:30 AWS 体験オンラインハンズオン~セキュア&スケーラブルウェブサービス構築編~

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカーおよびスタッフ一同、みなさまのご参加をお待ちしております。

Amazon Rekognition の更新 – 有名人の認識

re:Invent で Amazon Rekognition をリリースし (「Amazon Rekognition – ディープラーニングがサポートする画像の検出と認識 (Amazon Rekognition – Image Detection and Recognition Powered by Deep Learning))、本年初頭にイメージモデレーションを追加しました。本日は、有名人の認識を追加します。Rekognition のトレーニングにより、政治、スポーツ、芸能、ビジネス、メディアなどの分野の有名人や著名人を多数識別できるようになりました。このリストはグローバルで、頻繁に更新されます。この機能にアクセスするには、新しい RecognizeCelebrities関数を呼び出します。既存の DetectFaces 関数によって返される境界ボックスおよび顔ランドマーク機能に加えて、新しい関数では認識される有名人に関する情報が返されます。

"Id": "3Ir0du6", 
"MatchConfidence": 97, 
"Name": "Jeff Bezos", 
"Urls": [ "www.imdb.com/name/nm1757263" ]

Urls は、有名人に関する追加情報を提供します。現在、この API は IMDB コンテンツへのリンクを返します。今後は他のソースを追加する可能性があります。この機能をお試しになるには、AWS Management Console有名人の認識デモをお使いください。

イメージアーカイブを持っている場合は、有名人別にインデックスを作成できます。有名人の認識とオブジェクトの検出を組み合わせて使用して、あらゆる種類の検索ツールを構築することもできます。イメージが S3 にすでに保存されている場合は、そこで処理できます。この新機能には、いろいろな面白い使い方があるかと思います。ご意見ご感想をお寄せいただき、皆様がどのようなものをビルドしたかお知らせください。

Jeff;

AWS Greengrass – AWS Lambdaをネットワーク接続性のあるデバイス上で動かす

私が最初に AWS Greengrassについて投稿したのは、re:Invent期間中でした。(AWS Greengrass -ユビキタス, 現実世界におけるコンピューティング)
我々は、ご興味をお持ちいただいたお客様を招待制という限定プレビューのかたちでローンチさせていただきました。
そのときに私がお知らせしたように、多くのAWSの顧客は、接続が遅く、時には断続的、信頼できない場合がある、現場でデータを収集して処理したいと考えています。Greengrassでは、AWSプログラミングモデルを小型で簡単なフィールドベースのデバイスに拡張することができます。 AWS IoTAWS Lambdaをベースに構築されており、AWS Cloudで利用可能な多様なサービスへのアクセスをサポートしています。

一般利用可能

今日、Greengrassは米国東部(バージニア)と米国西部(オレゴン)のリージョンで一般利用可能になっています。プレビュー中、AWSのお客様はGreengrassでの実践的な体験を得て、その周辺のアプリケーションやビジネスの構築を開始できました。これらの初期の成功のいくつかをこの記事の後半で共有します。

(more…)

Amazon EMRでS3DistCpを使用してHDFSとAmazon S3間で効率的にデータを移動するための7つのヒント

Amazon S3とHadoop Distributed File System(HDFS)の間で大量のデータを移動する必要があったものの、データセットが単純なコピー操作には大きすぎるということはありませんでしたか? EMRはこれを救うことができます。ペタバイト級のデータの処理と分析に加えて、EMRは大量のデータの移動もできます。

Hadoopエコシステムでは、DistCpがデータを移動するためによく使用されます。 DistCpは、MapReduceフレームワークの上に構築された分散コピー機能を提供します。 S3DistCpは、S3で動作するように最適化されたDistCpの拡張機能であり、いくつかの便利な機能が追加されています。 S3DistCpは、HDFSとS3の間でデータを移動するだけでなく、ファイル操作のスイスアーミーナイフです。この記事では、S3DistCpを使用するための基本的なユースケースから始めて、さらに高度なシナリオまでのヒントについて説明します。

  1. 変換なしにファイルをコピーまたは移動する
  2. ファイル圧縮を変更しつつコピーする
  3. ファイルを段階的にコピーする
  4. 1つのジョブで複数のフォルダをコピーする
  5. パターンに基づいてファイルを集約する
  6. サイズが1TBを超えるファイルをアップロードする
  7. S3DistCpステップをEMRクラスターにサブミットする

(more…)

AWS Greengrass – 接続されたデバイスでの AWS Lambda 関数の実行

私が re:Invent 中に公開した投稿 (「AWS Greengrass – ユビキタスなリアルワールドコンピューティング」) で、初めて AWS Greengrass についてご紹介しました。その時点で限定プレビューの Greengrass の提供を開始し、関心をお持ちの場合はぜひサインアップしていただくよう皆様にお願いしました。そのときに説明したように、AWS の多くのお客様はフィールドでのデータの収集と処理を希望していますが、フィールドでの接続は低速で、中断したり信頼性が低くなったりすることが少なくありません。Greengrass では、AWS のプログラミングモデルを小型でシンプルなフィールドベースのデバイスに拡張することができます。これは AWS IoTAWS Lambda 上に構築されていて、AWS Cloud で利用できる、増え続けるさまざまなサービスへのアクセスがサポートされます。Greengrass では、フィールドで実行され、AWS リージョンへ継続的な高帯域幅接続に依存しないコンピューティング、メッセージング、データキャッシュ、および同期の各サービスにアクセスできます。Python 2.7 で Lambda 関数を記述し、デバイスシャドウを使用して状態を維持しながら、クラウドから Greengrass デバイスにデプロイできます。デバイスと周辺機器は、クラウドを経由しないローカルメッセージングを使用して相互に通信できます。

一般提供を開始
本日、AWS は US East (Northern Virginia) および US West (Oregon) リージョンで Greengrass の一般提供を開始しました。プレビュー中に AWS のお客様は Greengrass を実際に体験し、アプリケーションやビジネスの構築を開始できました。これらの初期的な成功のいくつかは、この投稿の後半でお知らせします。Greengrass Core コードは各デバイスで実行されます。デバイスに Lambda アプリケーションをデプロイして実行し、セキュアなネットワークでローカル MQTT メッセージングをサポートして、デバイスとクラウド間の対話がセキュアな接続で行われるようにします。Greengrass Core は、Lambda 関数を含む、セキュアな無線によるソフトウェア更新もサポートします。これには、メッセージブローカー、Lambda ランタイム、Thing Shadows の実装、およびデプロイエージェントが含まれます。Greengrass Core および (オプションで) その他のデバイスにより、Greengrass グループが構成されます。グループには設定データ、Greengrass Core のデバイスと ID のリスト、Lambda 関数のリスト、およびメッセージの送信先を定義するサブスクリプションのセットが含まれます。このすべての情報は、デプロイプロセス中に Greengrass コアデバイスにコピーされます。Lambda 関数は 3 つの個別の SDK で API を使用できます。

AWS SDK for Python – この SDK では、コードは Amazon Simple Storage Service (S3)Amazon DynamoDBAmazon Simple Queue Service (SQS)、およびその他の AWS のサービスと連携できます。

AWS IoT Device SDK – この SDK (Node.js、Python、Java、および C++ 用に利用可能) は、ハードウェアデバイスを AWS IoT に接続するうえで役立ちます。C++ SDK には、Greengrass 検出サービスやルート CA のダウンロードのサポートなど、いくつか追加の機能があります。

AWS Greengrass Core SDK – この SDK は、他の Lambda 関数のローカル呼び出し、メッセージの発行、Thing Shadows との連携が可能な API を提供します。Greengrass Core は、OverlayFS およびユーザー名前空間の機能を有効にしたバージョン 4.4.11 (またはそれ以降) の Linux カーネルを持つ x86 および ARM デバイスで実行できます。Greengrass のほとんどのデプロイは専門的な工業用ハードウェアを対象としていますが、デプロイおよびテスト目的で Raspberry Pi または EC2 インスタンスで Greengrass Core を実行することもできます。この投稿では、WiFi 経由で私の自宅のホームネットワークに接続された BrickPi に Raspberry Pi をアタッチして使用しました。

Raspberry Pi、BrickPi、ケース、およびその他すべてのパーツは、BrickPi 3 Starter Kit に用意されています。これらをすべて組み合わせて使用するには、Linux コマンドラインの関するいくらかの専門知識と、手動の巧みな操作がほどほど必要になりますが、私ができるのであれば、お客様も確実にできるでしょう。

Greengrass の実行
Greengrass はコンソール、API、または CLI からアクセスできます。私はコンソールを使用します。Greengrass コンソールの [Intro] ページでは、グループの定義、Greengrass Core の追加、およびグループへのデバイスの追加ができます。

[Get Started] をクリックし、[Use easy creation] をクリックします。

次に、グループに名前を付けます。

最初の Greengrass Core に名前を付けます。

準備ができたので、[Create Group and Core] をクリックします。

これは数秒間実行されてから、Greengrass Core とともに、ダウンロードできるセキュリティリソース (2 つのキーと証明書) が表示されます。

セキュリティリソースをダウンロードし、安全な場所に配置します。次に、目的のバージョンの Greengrass Core ソフトウェア (私の Raspberry Pi の場合は ARMv7l) を選択してダウンロードし、[Finish] をクリックします。次に、Pi を起動し、セキュリティリソースとソフトウェアを Pi にコピーします (S3 バケットに配置し、 wget でダウンロードしました)。この時点でのシェル履歴は次のとおりです。

 

重要な更新: AWS セキュリティチームの鋭い同僚の 1 人が指摘したように、これはシークレットをデバイスに配布するための良い方法ではありません。AWS CLI を使用して、暗号化されたバケットからこれらをダウンロードするか、カットアンドペーストでコピーするか、USB キーを使用することができました。ユーザーガイドの指示に従って、新しいユーザーとグループを作成し、 rpi-update スクリプトを実行して、 sqlite3opensslを含むいくつかのパッケージをインストールします。数回の再起動後に、続行する準備ができました。次に、引き続き指示に従って Greengrass Core ソフトウェアを展開し、セキュリティリソースを最終的な場所 (/greengrass/configuration/certs) に移動して、その過程で一般的な名前を付けます。ディレクトリは次のようになります。

次のステップは、AWS IoT Thing とコアの関連付けです。コンソールに戻り、クリックしてグループと Greengrass Core に移動して、Thing ARN を見つけます。

証明書と Thing ARN の名前を config.json ファイルに挿入し、 iotHostggHostの不足しているセクションを入力します。

Greengrass デーモンを開始します (これは 2 回目の試行です。1 回目はパス名の 1 つで入力ミスがありました)。

コマンドラインでの時間を楽しんだ後 (Unix v7 や BSD 4.2 を使用していたころを思い出しました)、再びビジュアルに戻ります。AWS IoT ダッシュボードに移動すると、Greengrass Core が IoT への接続を実行していることがわかります。

Lambda コンソールに移動し、Python 2.7 ランタイムを使用して Lambda 関数を作成します (ここでは IAM ロールは関係ありません)。

通常の方法で関数を発行し、Greengrass コンソールに移動してグループをクリックし、Lambda 関数の追加を選択します。

次に、デプロイするバージョンを選択します。

また、関数をオンデマンドではなく長期間使用するよう設定します。

コードにより AWS IoT にメッセージが発行されるため、ソースとターゲットを指定してサブスクリプションを作成します。

サブスクリプションでトピックのフィルター (hello/world) も設定します。

設定を確認し、サブスクリプションを保存します。これで、コードをデプロイする準備ができました。再びグループにアクセスし、[Deployments] をクリックして、[Actions] メニューから [Deploy] を選択します。

[Automatic detection] を選択して続行します。

これが最初のデプロイである場合は、他の AWS のサービスにアクセスする権限を Greengrass に与えるサービスレベルロールを作成する必要があります。[Grant permission] をクリックします。

各デプロイの状態を確認できます。

コードは現在、Pi で実行されています。コードはトピック hello/world にメッセージを発行します。これは IoT コンソールに移動し、[Test] をクリックして、トピックにサブスクライブすることで表示されます。

メッセージは次のとおりです。

すべての設定作業を行ったら、新しいバージョンのコードをアップロード、発行、デプロイして反復性のある開発を行うことができます。私は BrickPi を使用して LEGO Technic モーターを制御し、一部のセンサーから収集したデータを公開する計画です。この投稿をお楽しみに。Greengrass の料金表 Greengrass Core は、AWS 無料利用枠の一部として、1 年間 3 つのデバイスで無料で実行できます。次のレベル (3~10,000 デバイス) では、2 つのオプションを利用できます。

  • 従量制 – 1 か月、1 デバイスあたり 0.16 USD。
  • 年間契約 – 1 年、1 デバイスあたり 1.49 USD (17.5% の節約)。

10,000 以上のデバイスで Greengrass Core を実行するか、より長期的を希望される場合は、当社までお問い合わせください。

すべての料金モデルの詳細は、Greengrass 料金表ページでご覧いただけます。

Jeff;