The following components provide a scheduling framework to help you easily build custom tooling, such as schedulers, on top of Amazon ECS. The framework makes it easy to consume events from Amazon ECS, store the cluster state locally, and query the local data store though APIs. The cluster-state-service consumes events from a stream of all changes to containers and instances across your Amazon ECS
はじめに AWS re:Invent 2015 で発表された AWS IoT は IoT (モノのインターネット) のためのマネージド型のクラウドプラットフォームを提供してくれるサービスです。現在はベータ版として一般公開されています(2015/10/26現在)。 AWS IoT の機能の一つである「Device Shadow」を使うと、IoT デバイスの状態を管理することができます。IoT デバイスのセンサー情報を受け取ったり、逆に IoT デバイスの状態を変更するためにデータを送ったり、双方向にやり取りすることができます。この通信には MQTT または HTTPS が利用できます。 Device Shadows for AWS IoT - AWS IoT (Beta) AWS IoT を試したい!しかしながら「IoT デバイスは持っていない」「コマンドラインは苦手…」という人も少なくない
Eメールは終わったのか? いや、そんなことはないです。世界では1秒間に200万通のメールが送受信されています。(スパムが多いと思うけど。。。) 従来のEメールのアーキテクチャーといえば、メール管理者、配達の管理、システム管理、エンジニアなどが必要で、めっちゃお金掛かっていました。 例えば、メール管理者は、メールボックスの中からスパムを排除し、送信者評価を行い、誤った判定がないか確認し、ボットかスパムか確認し、送信者の判定ロジックを更新する必要がありました。配達の管理では、多くの宛先に届き、SPFやDKIMに対応するなどが必要でした。システム管理やエンジニアは、ファイアウォール、セキュリティアプライアンス、メールボックスサーバー、キャンペーンマネジメント、カスタマーサポート、アーカイブなどが必要でした。まぁオフィスワーカーがGmailとかOffice365使っていれば、ある程度は受信周りの管
こんにちは、せーのです。 私のRe:InventはAWS IoTほぼ一色のRe:Inventだったわけですが、実は出張前には狙っていたセッションがありました。それは Amazon Echo。 なにせ日本では売っていない & そこそこ値段する & 入力音声が英語のみ、とハードルが高く敬遠していたものの「Lambdaが繋がる」とわかってからは俄然興味を引いていました。 実際にEchoのセッションも出てきました。 これですね。現地では「Echo」というより「Alexa」という名前で呼ぶことが多かったです。なのでここでもAlexaと呼ぶことにします。かなり濃い内容なのでこれは追々ブログ化していきたいと思います。 他にも展示会場の色々な場所にAlexaがあり入力コマンドとしてアーリーアダプタにはだいぶ浸透してきているようでした。またRe:Inventでは色々なところでプレゼント企画が行われているので
AWSでは、EC2を使わない『サーバレス』なアーキテクチャの構築方法がより注目を浴びていますが、ビッグデータ周りについてもその傾向を見ることが出来ます。当エントリではそんな流れを組んだAWS諸サービスのサービス毎の特徴と事例紹介に関する紹介セッションの内容をレポートしたいと思います。 当セッションについては既にスライド資料がSlideshareで公開されていたので共有します。 Amazon API Gateway RESTベースのエンドポイント作成 フルマネージド 自動的にスケール 高速な開発が可能に 柔軟なセキュリティ制御 Integrationタイプ Lambda/Proxy AWSサービス/Proxy既存サービス/モック ステージングデプロイ クロスオリジンリソース共有(CORS)のサポート 自動生成SDK:Android/iOS/Javascript 料金周りの情報: AWS La
AWS IoT Registry とは AWS IoT には Registry というコンポーネントがあり、IoT サービスで利用するデバイスに紐づく デバイス名 クライアントID X.509証明書 属性 などの情報を一元管理できます。 Registry のユースケース デバイスが MQTT で AWS IoT の Device Gateway にメッセージ送信する際には クライアントID X.509 証明書 が必要です。 デバイスの利用開始時には、デバイスのこれら情報を必ず Registry に登録する運用にしておくと、Device Gateway のログのクライアントID情報から、メッセージを送信しているデバイスを特定出来ます。 サービスが終了後、属性情報で抽出したデバイスに対して、証明書を無効化してメッセージ送信出来ないようにする、といったことも考えられます。 Registry の
ども、大瀧です。 AWSのカンファレンスイベント、re:Invent 2015で発表&ベータがローンチされたAWS IoT、皆さん触ってますか? メッセージブローカーやルールエンジンなど、複数の設定を組み合わせて利用する上で、実際にどのように処理されたのか、エラーが発生していないかなど検証時にログを取りたいこともあると思います。そこで今回は、AWSのロギングサービスであるCloudWatch Logsでログを取得してみたいと思います。 設定手順 1. IAMロールの作成 まずは、AWS IoTからCloudWatch Logsへのアクセス許可を定義するIAMロールを作成します。IAMの管理画面から[Create New Role]をクリックします。 適当なロール名(今回はaws_iot_cloudwatchlogs)を入力し、[Next Step]をクリックします。 [AWS Servic
全てのデプロイはスコープとリスクがあり難しい ->決まったパワフルな自動ツールのプラットフォームが必要 AWSでのBlue/Greenデプロイの利点 素早いデプロイ 柔軟なオプション スケーラブルな容量 使った分だけの課金 自動化機能 アプリデプロイでののBlue/Greenパターン EC2インスタンスを使う場合 古典的なDNSカットオーバー Auto Scaling Groupの交換 ローンチ・コンフィグレーションの交換 ECSを使う場合 DNSを経由したECSサービスの交換 ELBの背後のECSサービスの交換 ECSタスク定義の交換 一般的なシナリオ:環境自動化 デプロイの成功は以下のリスクに依存します。 アプリケーションの問題 アプリケーションの性能 人/プロセスのエラー インフラストラクチャーの失敗 ロールバック機能 大きなコスト 特に「人/プロセスのエラー」、「インフラストラクチ
丹内です。掲題のセッションをレポートします。 スピーカー Usman Shakeel - Principal Solutions Architect, Amazon Web Services Kevin Constantine - Sr. Systems Engineer, Walt Disney Animation Studios 前提 そもそもレンダリングにAWSを使うというのは、よくあるユースケースの1つです。 ゲーム マーケティング ライフサイエンス アニメスタジオ エンジニアや建築 このセッションでは、アニメーションやVisual Effectの業界について取り上げます。 また、アニメーションにおけるレンダリングでも諸々もワークフローがあります。 アセットマネジメント コンポジット レンダリング その中でも「レンダリング」に絞ってのプレゼンテーションでした。 なぜAWSが必要か
re:Invent 2015 キーノートで発表された AWS のマネージド MQTT(MQ Telemetry Transport)サービス AWS IoT Message Broker で Pub/Sub してみました。 作業の流れ 以下の手順で作業します MQTT クライアントのインストール AWS CLI のアップグレード 認証設定 IAM Role 設定 Pub/Sub 通信 MQTT クライアントのインストール MQTT プロトコルの通信は OSS の MQTT 実装 mosquitto のクライアントを利用します。 Amazon Linux のパッケージには含まれていないため、CentOS 向けのパッケージを利用してみました。 $ sudo curl http://download.opensuse.org/repositories/home:/oojah:/mqtt/Cent
本日発表された新サービス、AWS IoTのDeep Diveセッションに参加しました。スピーカーはJinesh Variaです。 このセッションでは多岐にわたるAWS IoTの構成要素の中で、Rules EngineとDevice Shadowに絞って説明が行われました。 構成要素 Device Gateway : powerful broker MQTTと HTTPを受け付ける 物理デバイス間でのfine-grained access controlを行うことが可能 Device SDKs 接続、認証、通信を行うためのライブラリ C(for embedded) JS(for Linux) Arduino AWSのハードウェアパートナのデバイスで動作する Rules Engine メッセージをルールに基いて変換する 他のAWSサービスにルーティングする Dynamo Kinesis S3
本日発表された新サービス、AWS IoTのDeep Diveセッションに参加しました。スピーカーは Eric Brandwine です。 このセッションでは AWS IoT サービスに関して モノとAWS ゲートウェイの通信 モノの識別 AWS ゲートウェイを経由したAWSリソースの操作 でいかにしてセキュリティを担保しているのか説明が行われました。 モノとAWS ゲートウェイの通信 暗号化せずにパケットを送受信すると、様々なツールを使ってパケットの中身をのぞき見出来てしまいます。 AWS IoT では MQTT と HTTP という2つのプロトコルで IoT からデータ送信できます。 MQTT では相互認証(mutual authentication) と TLS による暗号化 HTTP では AWS 認証と TLS による暗号化 を採用しています。 スライドにも "One Servic
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く