Author: AWS Japan

ちょうど先週、私が 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 レスポンス – […]

私の同僚のGeorgie Mathewsは、あなたのモバイルアプリのユーザーエンゲージメントを測定して改善するのに役立つ新しいサービスであるAmazon Pinpointを紹介するため、以下のゲストポストを書きました。

私は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が含まれます。

AWS Service Heath Dashboardをリリースしたのは2008年になります。当時はAWS Cloudは比較的新しく、各サービスの利用状態を確認するのにいい手段でした(現在のService Health Dashboardと比べると、この8年でAWSがどのくらい成長した化が見て取れます)。 現在のダッシュボードは、AWSサービス毎の状態を俯瞰的に表示するため、個別最適されたダッシュボードというわけれではありませんでした。そのため、お客様と会話をすると、全体的なダッシュボードというよりは、お客様の利用サービス、リソースに合わせた状態管理を希望されることもありました。 新サービス Personal Health Dashboard 関心のあるサービスについてより多くの情報を提供できるよう、AWS Personal Health Dashboardをリリースしました。サービス名の通り、このダッシュボードは利用しているAWSサービスのパフォーマンス、可用性に関した個別のビューのみならず、サービスの状態に変化が会った際にはアラートを自動的に発行します。利用中のサービスに関して一元的に監視するためにデザインされており、影響を及ぼすであろう問題に関して、より詳細に可視化することが可能です。ダッシュボードに関係する情報が登録されると、コンソールから通知アイコンを確認出来ます。 “issues”をクリックすると、影響するであろうAWSインフラストラクチャが確認できます(これらのデータはすべてテストデータです)。 アイテムをクリックするとその問題を修復するためのガイダンスを含むより詳細の情報を確認することができます。 また事前に予定されているアクティビティを確認することで注意喚起をうながすこともできます。 それ以外にも、興味のあるサービスについての情報を確認することもできます。 またCloudWatch Eventsと連携することで、アラート対応でしたり、スケジュールイベント対応を自動化させることも可能です。例えば、自主的にメンテナンスイベント対応が必要なEC2インスタンスを移動することで、メンテナンスイベント通知対応が可能になります。 ご自身のアカウントがビジネスサポート、もしくはエンタープライズサポートに加入頂いてる場合、この新しいAWS Health APIをご利用頂けます。このAPIを使い、Personal HealthDashboardの情報をを既存のITマネジメントツールとの連携されることがが可能になります。 – Jeff(翻訳はSA酒徳が担当しました。原文はこちら)

2014年、私はAmazon ECSについてお話して、Dockerベースのアプリケーションをビルドし実行し、そしてスケールさせることを如何に手助けしてくれるかをご紹介しました。そこでは3つのスケジューリングの選択肢(自動、手動、そしてカスタム)について話をし、スケジューラがインスタンスにどの様にタスクを割り当てるかを説明しました。 その時書いた記事では、カスタムスケジューラは現在のクラスタの状態を見るためにListContainerInstancesとDescribeContainerInstancesを定期的に呼び出す必要があると記しました。数週前、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岩永)

開発者は通常、ソースコードの変更に対する継続的インテグレーションのビルドとテストを実行するために、共有のビルドサーバを構築し運用しなければいけません。継続的インテグレーションを運用するのは面倒なことなので、多くの開発者はそれを避けてローカルマシンでビルドを実行します。これによって、ある開発者の環境では動作するコードが最終的な本番環境ビルドで動作しないという状況が、しばしば引き起こされます。 多くの開発チームは、CI/CD（継続的インテグレーション / 継続的デプロイ）パイプラインの構成要素としてビルドファームを構築します。ビルドファームの構築と運用はコストが高く、また独特のスキルが求められます。普段はビルドファームはあまり使われていませんが、修羅場の時には利用率は100%に達し、未処理のビルドリクエストが増えてしまいます。

大統領自由勲章の受賞者であるGrace Hopperが、プログラムからエラーを特定し取り除く作業にデバッグという言葉を与えた最初の人だと思います。 実際にコンピュータから本物のバグ(虫)を見つけたことはないですが、働き初めた頃にアセンブラ言語のデバッグに膨大な時間を費やしました。その当時は、デバッグとはコードを1ステップずつ実行し、各プロセッサのレジスタの中身をステップの前後で比較し、自分の頭の中のモデルと実際に起こっていることが一致しているかを検証するというものでした。これはとてもうんざりするようなものでしたが、バグが残る余地はほとんどなく、自分のコードがどの様に動くかの深い理解も得られるものでもありました。その後、1ステップずつの実行はなくなり、デバック出力(こんにちは、stderr)に取って代わり、それからログファイルとログ分析ツールへと変わっていきました。 最近の過去数十年で、複雑な分散システムが登場してきたことで、デバッグは変化して新しい意味を持つようになりました。単体テストが個別の関数とモジュールが期待通り動作することを保証しているので、難易度の高いポイントは大規模な中での動作のパターンを見ることに変わっています。クラウドコンピューティング、マイクロサービス、そして非同期な通知ベースのアーキテクチャの組合せによって、システムは数百から数千もの可変な箇所を持つようになりました。こうした複雑なシステムでのパフォーマンス課題を特定し対応していく難しさは増していて、個別サービスレベルの観測情報を集約して意味のある上位の結果にすることに難しさがあります。開発者にとって、EC2インスタンス、ECSコンテナ、マイクロサービス、AWSのデータベースやメッセージサービスを辿って”筋道を追う”ことは簡単ではありません。 これを何とかしましょう！

AWSのお客様はT2インスタンスを使う時に得られるコスト効率のよい、バーストベースのモデルを好まれています。これらのお客様は webサーバや開発環境、継続的なインテグレーション用のサーバ、テスト環境、そして小さなデータベース等の一般的な用途でのワークロードを動作させるのにT2インスタンスを使います。これらのインスタンスは豊富なベースラインパフォーマンスと、必要に応じてフルコアのプロセッシングパワーにまで透過的にスケールアップを提供します。（もしこちらがあなたにとって新しいニュースであれば、バースト可能な性能を持つ新しい低コストEC2インスタンスをご参照ください） 本日２つの新しいより大きなT2インスタンスサイズを追加します。- 16GiB メモリの t2.xlargeと32GiB メモリのt2.2xlarge です。これらの新しいサイズにより、お客様はより大きなリソースの要件のアプリケーション向けに T2のバーストモデルの価格とパフォーマンスのメリットを享受頂けます。（t2インスタンスのレンジを拡大するのは、今回が3度目になります；昨年の6月にt2.largeを、昨年の12月にt2.nanoを追加しました。 こちらがT2インスタンスのすべてのサイズ向けのスペックになります。（価格は最近のEC2の値下げを反映しています。US Eastリージョンの料金になります。） 名前 vCPU ベースラインパフォーマンス プラットフォーム メモリ CPU クレジット / 時間 価格 / 時間 (Linux) t2.nano  1  5%  32bit または 64-bit  0.5  3  $0.0059 t2.micro 1 10%  32bit または 64-bit 1 6 $0.012 t2.small 1 20%  32bit または 64-bit 2 12 $0.023 t2.medium 2 40%  32bit […]

5月には、正式にAWS IoT Buttonを開始し、開発者コミュニティから提供されたボタンのサポートに圧倒されました。 私たちは皆様の提案に耳を傾け、AWS IoT Buttonの改良された開発者体験を発表することを喜ばしく思います。 今日から、iOSとAndroid用の新しいモバイルアプリでAWS IoT Buttonを設定できます。 モバイルアプリケーションは、ボタンの登録、設定、およびプログラミングのプロセスを簡素化します。 あらかじめ設定されたAWS Lambdaのブループリントを使用して、このボタンをクリックするとSMSや電子メールを送信するボタンを素早くプログラムすることができます。 または、あなたが選択した機能のための独自のLambdaコードを書くことができます。 さらに、新しいバージョンのAWS IoT Buttonは、バッテリー寿命を2倍に設計しました。 amazon.comで今予約注文することができます。 それまで待ちたくない場合は、元のAWS IoTボタンは引き続き使用でき、AWSアカウントごとに20ドルのAWSクレジットを提供します。 AWS IoT Buttonの詳細については、製品ページをご覧ください。   原文: Announcing an Improved AWS IoT Button Developer Experience (翻訳: SA福井)

私は過去にGPUベースのコンピューティングのメリットについて書いてきました。最近では最大16個のGPUを搭載したP2インスタンスのリリースがありました。過去に指摘したように、GPUは驚異的なパワーとスケールを提供し、同時に結果を得るまでの時間と全体的な計算コストを削減する可能性があります。 今日、私たちが取り組んでいる新しいGPUベースの機能について少しお話したいと思います。 もう少しすると既存のEC2インスタンスタイプにグラフィックアクセラレーションを追加することができるようになります。 G2またはP2インスタンスを使用する場合、インスタンスサイズによってGPUの数が決まります。 これは多くの種類のアプリケーションでうまく機能しますが、他の数多くのアプリケーションでも、より新しい、より柔軟なモデルを利用する準備が整ったと考えています。 Amazon EC2 Elastic GPUs 発表されたAmazon EC2 Elastic GPUは、それぞれ異なる長所を提供します。アプリケーションに最適なEC2インスタンスのタイプとサイズを選択でき、また、インスタンスを起動する際にElastic GPUの使用を指定し、4種類のサイズから選択できます。 Name GPU Memory eg1.medium 1 GiB eg1.large 2 GiB eg1.xlarge 4 GiB eg1.2xlarge 8 GiB Elastic GPUをM4、C4、およびX1インスタンスで使用できるようになります。 現在、新しいインスタンスを起動するときに新しく作成されたEBSボリュームを設定する機能がありますが、 Elastic GPUについても同様に起動設定の際に希望のサイズを指定したり、実行中のインスタンスを停止、起動することにより変更が可能です。 OpenGLで始める Amazonに最適化したOpenGLライブラリは、自動的にElastic GPUを検出して使用します。 OpenGLのWindowsのサポートから始め、その後、Amazon Linux AMIやOpenGLの他のバージョンのサポートを追加する予定です。 また、DirectXやVulkanなど他の3D APIのサポートも検討しています（興味があるかどうかをお知らせください）。 既存のMicrosoft Windows AMIのリビジョンにAmazonに最適化したOpenGLライブラリを追加します。 OpenGLはレンダリングには最適ですが、レンダリングされたものはどうやって見ますか？ 素晴らしい質問です！ 1つの選択肢は、レンダリングされたコンテンツをHTML5と互換性のあるブラウザやデバイスにストリーミングするために、NICE Desktop Cloud Visualization（今年初めに買収 – Amazon Web Services to […]