Author: AWS Japan

この投稿と付随するコードの作成には、下記3名による多大な貢献がありました。 Jeremy Cowan Solutions Architect Anuj Sharma DevOps Cloud Architect Peter Dalbhanjan Solutions Architect コンテナ化されていないトラディショナルな環境にソフトウェアアップデートを展開するのは難しく、リスクを伴います。デプロイパッケージまたはスクリプトを記述するときは、ターゲットマシンが特定の状態にあると仮定する必要があります。ステージング環境が本番環境の正確なミラーイメージでない場合、デプロイは失敗する可能性があります。デプロイが失敗すると、アプリケーションの最後の正常なバージョンを再デプロイするまでサービス停止が起きることがあります。あなたが運用管理者だとしたら、サービス停止があると夜間に起きていなければいけないでしょう。 リリース内容の審査が終わるまでユーザーに新しいバージョンをさらすことなく、本番環境でテストをおこないたいと考えているお客様が増えています。人によっては、新機能が多くの人たちに公開される前に少数の顧客に対してのみ公開し、フィードバックを集めることもあるでしょう。これは、カナリア分析またはカナリアテストと呼ばれる手法です。この記事では、Application Load Balancersとtarget groupsを使用してBlue/Greenとカナリアデプロイを実装するパターンを紹介します。 もし実際にこのアプローチを試したい場合、オープンソースのコードとAWS CloudFormationテンプレートをecs-blue-green-deployment GitHubリポジトリに公開しています。 このワークフローでは、サービスをECSクラスタにデプロイする自動化されたCI / CDパイプラインが構築され、コードの最新バージョンを本番環境に昇格する準備が整ったらターゲットグループをスワップする制御されたプロセスが提供されます。環境は3つのステップで簡単に設定でき、Blue/Greenのスワップが動作することを確認できます。ぜひ試してみてフィードバックを送ってください！   Blue/Greenの利点 Blue/Greenデプロイメントは、ソフトウェア更新を低リスクでおこなうことができるイミュータブルデプロイメントの１つのパターンです。現在の実行中の “Blue”バージョンのアプリケーションと新しい “Green”バージョンのアプリケーションを別々の環境で作成することで、リスクが軽減されます。 このデプロイメント方法では、アプリケーションの現在の実行中のバージョンに影響を与えずに、Greenの環境で機能をテストすることができます。Greenバージョンが正常に動作していることが確認できたら、DNSを変更して古いBlue環境から新しい環境にトラフィックを徐々にルーティングすることができます。この方法に従うことで、ほぼゼロダウンタイムで機能更新とロールバックをおこなうことができます。 2つの異なる環境感でトラフィックをシフトする典型的なBlue/Greenデプロイメント このように運用中のBlue環境に素早くトラフィックを戻すことできることは、Blue/Greenデプロイメントの主要メリットの1つです。Blue/Greenデプロイメントでは、デプロイメントプロセスのどのタイミングでもBlue環境にロールバックすることが可能です。ダウンタイムはGreen環境に問題があることを認識してから、Blue環境にトラフィックを切り戻すまでの時間に制限されます。さらに、停止の影響はすべてのトラフィックではなく、Green環境に振り分けられたトラフィックに限定されます。デプロイエラーの規模が縮小されると、全体的なデプロイのリスクも低下します。 コンテナでBlue/Greenをシンプルに実現する 複数環境の管理およびプロビジョニングの複雑さとコストのために、従来のオンプレミスでのソフトウェア更新にはBlue/Greenデプロイメントはあまり導入されていませんでした。代わりに、アプリケーションはin-placeでアップグレードされていました。 このアプローチは有効でしたが、障害時のロールバックの迅速性などいくつかの欠陥がありました。ロールバックには通常、以前のバージョンのアプリケーションの再デプロイメントをおこなっていましたが、再デプロイメントは良くないリリースがあった場合の停止時間を長期化させる可能性があります。 コンテナは、簡単にパッケージ化でき、環境間を移動しても一貫して動作するため、Blue/Greenデプロイメントの導入を容易にします。この一貫性のひとつの要因は、コンテナのもつ不変性です。コンテナの設定を変更するには、In-Placeでソフトウェアを更新するのではなく、Dockerfileを更新してコンテナを再構築、再デプロイする必要があります。 コンテナは、アプリケーションのプロセスと名前空間の分離も提供します。これにより、複数のバージョンのアプリケーションを同じDockerホスト上で競合することなく並行して実行できます。仮想マシンに比べてサイズが小さいため、ホストあたりにVMに比べて多くのコンテナを詰め込むことができます。これにより、コンピューティングリソースをより効率的に使用できるようになり、Blue/Greenデプロイメントのコストを削減できます。 Amazon ECSのフルマネージド更新 Amazon EC2 Container Service (ECS) は、既存のAmazon ECSサービスを更新すると、ローリングアップデートを実行します。ローリングアップデートでは、現在実行中のバージョンのコンテナを最新バージョンに置き換えます。ローリングアップデート中にAmazon ECSがサービスに追加または削除するコンテナの数は、サービスのデプロイ時に許可される健全なタスクの最小数と最大数を調整することによって制御されます。 最新バージョンのコンテナイメージを利用するようにサービスのタスク定義を更新すると、Amazon ECSによってコンテナの古いバージョンが自動的に最新バージョンに置き換えられます。デプロイメント中、Amazon ECSは現在実行中のバージョンから接続を切断し、新しいコンテナがオンラインになるとApplication Load Balancer に登録します。 Target groups […]

AWS 開発者用ツールのチームは AWS SDK for Java のリリースに向けて熱心に取り組んできました。そして本日、バージョン 2.0 の開発者用プレビューを公開するに至りました。このバージョンは過去にリリースした 1.11.x codebase を大きく書き換えたものです。整合性、イミュータビリティ、使い勝手の良さに視点を向けて Java 8 の上に構築しました。 新しい SDK には、ノンブロッキングの I/O のサポート、ランタイムで使用したい HTTP 実装を選択できるなど、リクエストが多かった機能を含んでいます。新しいノンブロッキング I/O サポートは既存のものに比べより効率的で、サービスクライアントの Async バリアントのスレッドベース実装を取り入れています。ノンブロッキングのリクエストはそれぞれ CompletableFuture オブジェクトを戻します。バージョン 2.0 SDK では、これまでの API にいくつもの変更を追加しています。たとえば、既存のクライアントのコンストラクタと変更可能なメソッドを、クライアントビルダーと変更不可能なクライアントをベースにした非同期モデルと置換します。また、SDK はリージョンをシングルリージョンクラスにするために使用するクラスの異種コレクションを折りたたみ、ストリーミング用 API の新しいセットを提供します。SDK は GitHub でご利用いただけます。GitHub に関する問題をスタートして公開フィードバックを送信したり、いつもの方法でリクエストのプルを送信することができます。 SDK の詳細については AWS 開発者ブログの「AWS SDK for Java 2.0 – 開発者用プレビュー (AWS SDK for Java 2.0 […]

5月末〜6月頭に開催されたAWS Summit Tokyo 2017において、Amazon ECSを実際にご利用頂いているお客様からの導入事例セッションとAWSからのTechセッションを合わせると、なんと11ものAmazon ECS関連セッションが行われました。Summit全体で130以上のセッションがありましたので、その中で10%程度がAmazon ECS関連だったということになります。Amazon ECSは、2015年4月にGA(東京リージョン含む)して以来、着実にお客様に導入を頂き、スタートアップからエンタープライズまで、新規システムだけでなくオンプレからの移行でも利用される標準的なサービスとなってきたことの表れかと思います。 この投稿では、それらのセッションを一気に見返せる様に情報を集約してお届けしたいと思います。これらの情報をご覧になって、Amazon ECSの利用をぜひご検討下さいませ。 導入事例トラック ナビタイムサービスにおける、Amazon ECS を活用したシステム移行　～『乗換NAVITIME』での移行事例 ～ 資料 [リコー] サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して 〜AWS を最大限活用して可用性を高める秘策〜 資料 動画 クックパッドの機械学習を支える基盤のつくりかた 資料 動画 Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョブワーカーシステム (※株式会社インティメート・マージャー様事例) 資料 動画 [Intelligence] オンプレから移行するので、Amazon ECS でコンテナ化と Terraform でインフラコード化した話 資料 DAU 100 万人突破！ 急成長を支える Shadowverse のインフラ技術 資料 DMM における会員基盤プラットフォームへのAWS導入から活用事例の紹介 資料 動画 [ABEJA] IoT / Bigdata / […]

2019/7/22 に一部内容を更新しました． Amazon Redshift Spectrum を使うことで、Amazon S3 に置かれたデータに対して Amazon Redshift の SQL クエリを走らせることができます。つまり Redshift Spectrum によって、データウェアハウスのローカルディスク内に保存されたデータ以外に対しても、Redshift の分析を拡張できるようになるのです。S3 の “データレイク” に貯まった大量のデータに対して、面倒で時間のかかる抽出・変換・ロード（ETL）処理を行うことなく、クエリを投げることができます。Redshift Spectrum は洗練されたクエリ最適化を用いて、数千ものノードにまでスケールして高速に処理を行います。 このブログポストでは、Redshift Spectrum の 10 の重要なベストプラクティスについて、いくつかのカテゴリにわけてご紹介します。 このガイドラインは、Redshift をお使いのお客さまとの多くのやりとりや、直接的なプロジェクトに基づいて作られています。 Amazon Redshift vs. Amazon Athena AWS のお客さまは、私たちによく「Amazon Athena と Amazon Redshift Spectrum について、どう使い分けをすればよいのでしょうか？」と尋ねます。 Amazon Athena の利用シーン Athena は S3 に置かれたデータに対して、SQL によるインタラクティブなアドホッククエリを投げるといったユースケースに向いています。Athena はサーバーレスアーキテクチャなので、クエリを投げるためにクラスタを立ち上げる必要はありません。クエリごとにスキャンした S3 のデータ量に基づいて料金が発生します。データを圧縮、パーティショニング、または列指向フォーマットに変換することにより、費用を節約しつつ優れたパフォーマンスを得ることができます。JDBC に対応しているすべての BI […]

データウェアハウスのワークロードは多様性で知られています。これは、季節性や、往々にして高コストになりがちな探索的クエリー、SQL開発者のスキルレベルのばらつきなどによるものです。 Amazon Redshiftワークロード管理機能（WLM）を用いて優先度やリソース使用量を柔軟に管理することで、極めて多様なワークロード環境でも高い性能を得ることが可能となります。WLMによって、短時間で完了するクエリーが長時間実行されるクエリーのせいでキューに滞留するような状況を避けることができます。にも拘わらず、あるクエリーが不釣り合いな量のリソースを独占し、システム内のその他のクエリーを圧迫することが依然として起こり得ます。こうしたクエリーは、一般にrogue queryやrunaway queryと呼ばれます（訳者註：rogueはならず者、面倒を起こすといった意味、runawayは暴走の意で、ここでは一方的にリソースを占有し他のクエリーに影響を及ぼすクエリーを指します） WLMは、メモリー使用量を制限し、タイムアウトを用いてクエリーを別のキューに移動させる機能を持ちますが、ずっと粒度の細かいコントロールができることが望ましいことは論を俟ちません。クエリーモニタリングルールを用いて、リソース使用量のルールを作成し、クエリーのリソース使用量を監視し、それらがルールを犯した時のアクションを決めることが可能になりました。 ワークロード管理における同時並列性とクエリーモニタリングルール Amazon Redshift環境では、単一クラスターに対し最大500まで同時接続することができます。性能指標であるスループットは一般に一時間あたりのクエリー数として表現されますが、MySQLのような行指向データベースであれば、同時接続数を増やすことによってスケールします。Amazon Redshift環境では、ワークロード管理（WLM）によって、同時接続数とは異なる方法でスループットを最大化します。WLMは二つの部分があります。キューと同時並列性です。キューはユーザーグループまたはクエリーグループのレベルでのメモリー割り当てを可能にします。同時並列性（またはメモリースロット）は、この割り当てをさらにどのように分割し、個々のクエリーにメモリーを割り当てるかを制御します。 例えば、同時並列性10の1つのキューがある（メモリー割り当て100％）と仮定しましょう。これは、個々のクエリーは最大10%のメモリーの割り当てを受けることを意味します。もしクエリーの大半が20%メモリーを必要とした場合、これらのクエリーはディスクにスワップアウトし、スループットの劣化をもたらします。しかし、もし同時並列性を5に下げた場合、個々のクエリーは20%のメモリー割り当てを受けることができるため、トータルのスループットは高くなり、SQLクライアントへのレスポンスも全体的に高速になります。高い同時並列性がよりよいパフォーマンスに繋がると考えてしまうことは、行指向のデータベースを列指向に切り替える時に陥りがちな典型的な落とし穴の一つです。 同時並列性について理解したところで、クエリーモニタリングルールについて掘り下げていきましょう。リソース使用量に基づくルールと、それに違反した場合に取るアクションを定義します。当該クエリーによるCPU使用量、クエリー実行時間、スキャンされた行数、返された行数、ネステッドループ（Nested loop）結合など、12の異なるリソース使用量メトリクスを利用できます。 それぞれのルールは最大3つの条件（述語）と、一つのアクションを持ちます。 述語は、メトリック、比較演算子（=、<または>）、値で構成されます。あるルール内の全ての述語がマッチすると、そのルールのアクションがトリガーされます。ルールアクションには、ログ（記録）、ホップ（次のキューへの移動）、アボート（終了）があります。 これにより、はた迷惑なクエリーを、より深刻な問題が出来する前に捕捉することが可能になります。ルールはアクションをトリガーしてキューを解放し、スループットと応答性を改善します。 例えば、短時間実行クエリー専用のキューのために、60秒を超えて実行し続けるクエリーをアボートするルールを作ることができます。設計のよくないクエリーを追跡するために、ネステッドループを含むクエリーを記録する別のルールを作ることもできます。Amazon Redshiftコンソールには、簡単に始められるよういくつかのテンプレートが事前定義されています。 シナリオ クエリーモニタリングルールを使って、単純なロギングからクエリーのアボートまで、幅広いクエリーレベルアクションを行うことができます。また、全てのアクションはSTL_WLM_RULE_ACTIONテーブルに記録されます。 ログ（LOG）アクションは、情報を記録した上でクエリーの監視を継続します。 ホップ（HOP）アクションは、クエリーを中断し、次に合致するキューで再起動します。 もし合致するキューがない場合、当該クエリーはキャンセルされます。 アボート（ABORT）アクションは、ルールに違反したクエリーをアボートさせます。 それでは、以下の三つのシナリオを用いて、クエリーモニタリングルールをどのように使うかを見ていきましょう。 シナリオ1：アドホッククエリーに潜む非効率なクエリーを制御するには？ 二つの大きなテーブルを結合するようなクエリーは、何十億、あるいはそれ以上の行を返す可能性があります。十億行を超える行を返すクエリーをアボートさせるルールを設定することで、アドホッククエリーの安全性を担保することができます。このルールは、論理的には以下のようになります。 IF return_row_count > 1B rows then ABORT 以下のスクリーンショットの設定では、十億行を超える行を返すBI_USERグループ内のクエリーはすべてアボートします。 シナリオ 2： 非効率で、CPUインテンシブなクエリーを制御するには？ CPUスパイクをもたらすクエリーが、必ずしも問題というわけではありません。しかし、高いCPU使用量と長いクエリー実行時間を併せ持ったクエリーは、実行中の他のクエリーのレイテンシーを悪化させます。例えば、高いCPU使用率を示し続ける非効率なクエリーが長時間実行されている場合、それは誤ったネステッドループ結合のせいかも知れません。 こうしたケースでは、10分間にわたって80%以上のCPU使用率を示しているクエリーをアボートさせるルールを作成することで、クラスターのスループットと応答性を上げることができます。このルールは、論理的には以下のようになります。 IF cpu_usage > 80% AND query_exec_time > 10m then ABORT 以下のスクリーンショットの設定では、10分間にわたってCPU使用率が80%を超えているクエリーはすべてアボートします。 80%以上のCPU使用率を5分以上続けるクエリーを記録し、10分以上続いた場合はアボートするよう、ルールを拡張することもできます。このルールは、論理的には以下のようになります。 IF cpu_usage > […]

今年の初め頃 Amazon DynamoDB Accelerator（DAX）について紹介をしました。DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段（論理的に）に置かれます。DAXはキャッシュされたデータに対するリクエストをマイクロ秒単位で返すため、読み込みワークロードに最適です。DAXはアプリケーションコード内ではDynamoDB APIと互換性を保つ様にサポートしており、シームレスで使いやすいようにデザインしています。管理することはDAXクラスタを作成して既存の読み取りと書き込みのターゲットとして使用するだけです。パッチ適用、クラスタメンテナンス、キャッシュデータの複製、または障害管理について心配する必要はありません。 本日から利用可能 今日DAXが正式に利用可能になったことをお知らせします。DAXが利用可能なAWSリージョンを追加拡張し、プレビューの期間にパフォーマンスと可用性をチューニングしました。 5つのリージョンで利用可能 – 現在 DAXはUS East (Northern Virginia)、EU (Ireland)、US West (Oregon)、Asia Pacific (Tokyo)、US West (Northern California) の5つの地域で利用可能です。 In Production – プレビュー期間内にDAXを本番で使用しているユーザーもおり、DAXをアプリケーションに追加するのが楽で今ではアプリケーションの速度が10倍速くなってたという声を頂いています。 Getting Started with DAX 以前の記事(翻訳版はこちら)で紹介したように、DAXを使用して既存のDynamoDBアプリケーションを高速化するのは簡単です。必要なリージョンにDAXクラスタを作成し、 DAX SDK for Javaを利用するようにアプリケーションを更新します（コード内の呼び出し方は同じですが、ライブラリの置き換えを行う事です）。SDKを構成してクラスタにエンドポイントを使用するようにします。リードスルー/ライトスルーキャッシュとして、DAXはすべてのDynamoDB読み取り/書き込みAPIをシームレスに処理します。 私たちは他の言語のSDKのサポートも取り組んでおり、利用可能になった時点で追加情報を共有します。 価格について US East (Northern Virginia) と US West (Oregon) の各地域で、時間あたり$ 0.269から始まる料金 でクラスター内の各ノード（詳細については、 DynamoDBの価格を参照）を1時間単位でお支払いいただきます。DAXでは、クラスタ内の各ノードが高可用性のための読み取りターゲットおよびフェールオーバーターゲットとして機能します。DAX SDKはクラスタを認識しており、クラスタ内のすべてのノードに対してラウンドロビンで要求を発行し、クラスタのキャッシュリソースを最大限に活用できるようにします。 DAXは読み取りトラフィックの急激な急上昇を容易に処理できるため、テーブルのプロビジョニングされたスループットの量を減らすことができ、結果としてマイクロ秒で結果を返しながら全体のコストを削減できます。 最後にAmazon.comのCTOであるWerner Vogelsが書いたブログを紹介させて頂きます。 Amazon DynamoDB […]

AWS WAF (ウェブアプリケーションファイアウォール) は、悪質または不正なリクエストに関与する様々なタイプのアプリケーションレイヤー攻撃からアプリケーションを保護するために利用できます。このサービスについて説明したブログ (「新しい AWS WAF について (New – AWS WAF)」でもお見せしましたが、クロスサイトスクリプティング、IP アドレス、SQL インジェクション、サイズ、コンテンツ制約に見合うルールを定義できます。 受信リクエストがルールと一致すると、アクションが呼び出されます。アクションは許可やブロックを実行したり、単にマッチ数をカウントすることができます。既存のルールモデルはパワフルかつ様々な種類の攻撃を検出し対応することができます。ただし、特定の IP アドレスから送られた有効なリクエストが大量に送信されただけのケースでは、攻撃として対応することはできません。こうしたリクエストはウェブレイヤーの DDoS 攻撃や総当たりのログインの試行、もしくはパートナー統合で不具合があった場合の可能性があります。 新しいレートベースのルール 本日、WAF にレートベースのルールを追加しました。これにより、ブラックリストへの IP アドレスの追加または削除を管理できるようになり、例外や特別なケースに対応できる柔軟性も提供します。IP アドレスをブラックリストに追加 – 設定済みのしきい値を超える速度でリクエスト数を送信した IP アドレスをブラックリストに追加することができます。IP Address のトラッキング– どの IP アドレスがブラックリストに追加されているか見ることができます。IP Address の削除 – ブラックリストに追加された IP アドレスは、設定済みのしきい値を超える速度でリクエストを送信しないようになれば自動的にリストから削除されます。IP Address の例外 – 特定の IP アドレスをブラックリストの対象外として設定することができます。その場合はレートベースのルール内にある IP アドレスのホワイトリストを使用してください。たとえば、自分のサイトに信頼できるパートナーが高速でアクセスできるように許可したい場合もあるでしょう。モニタリングおよびアラーム発行 – 各ルールに発行した CloudWatch メトリクスでモニタリングしたりアラーム発行をすることができます。新しいレートベースのルールと WAF の条件を組み合わせて高度なレート制限戦略を取り入れることもできます。たとえば、レートベースのルールやログインページと一致する WAF […]

Amazon WorkSpaces では、ウェブおよびさまざまなデスクトップおよびモバイルデバイスから、クラウド上の仮想デスクトップにアクセスできます。この柔軟性により、WorkSpaces はユーザーが自己所有しているデバイス (BYOD または Bring Your Own Device とも呼ばれます) を使用できる環境に最適です。このような環境では、組織は WorkSpaces にアクセスできるデバイスを管理する機能を必要とする場合があります。たとえば、コンプライアンスまたはセキュリティポリシー要件を満たすため、クライアントデバイスのオペレーティングシステム、バージョン、またはパッチレベルに基づいてアクセスの制御が必要になる場合があります。 マネージド型デバイスの認証 本日、WorkSpaces 用のデバイス認証の提供を開始します。これにより、デジタル証明書を使用して、Apple OSX および Microsoft Windows からのクライアントアクセスを管理できるようになりました。また、iOS、Android、Chrome OS、ウェブ、およびゼロクライアントデバイスからのアクセスを許可またはブロックする選択もできます。ポリシーを実装して、許可するデバイスタイプとブロックするデバイスタイプを、パッチレベルまで管理できます。アクセスポリシーは、各 WorkSpaces ディレクトリに対して設定されます。ポリシーの設定後、クライアントデバイスから WorkSpaces への接続リクエストが評価され、ブロックまたは許可されます。この機能を利用するには、Microsoft System Center Configuration Manager またはモバイルデバイス管理 (MDM) ツールを使用して証明書をクライアントデバイスに配布する必要があります。WorkSpaces コンソールからアクセスコントロールオプションを設定する方法を次に示します。 クライアントが接続を許可されていない場合は、次のようになります。   今すぐ利用可能 この機能は、WorkSpaces が利用できるすべてのリージョンで利用できます。 — Jeff;

はじめに JavaScript エコシステムが成長していくなかで、私達はモバイルおよびハイブリットアプリを構築するお客様を支援する取り組みを続けています。本日、 AWS Mobile Hub に Hosting and Streaming 機能をリリースしました。この機能は、Amazon S3 と Amazon CloudFront を使用するモバイル Web サイトのテスト及びプロダクション環境へのデプロイを自動化します。また、標準設定ファイルと SDK を使用する際の設定ワークフローを簡略化します。 この新しい機能によって、 JavaScript 開発者は事前設定された AWS アーキテクチャを起動したり、 Mobile Hub プロジェクトをビルドできます。また、集中管理された設定と事前ダウンロードされた SDK を使用して、ワンクリックでグローバル Web サイトを作成できます。

こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー 7 月の配信についてご案内させて頂きます。今月はAmazon Connect, AWS Shield, AWS Step Functions と Black Belt 初開催となるサービスの紹介が多く予定されておりますので、是非とも最新情報の習得にお役立ていただければと思います。またその他にも AWS Lambda, AWSの運用監視といった実用的な技術情報をお届けいたします。 サービスカット 7/5(水) 18:00-19:00 Amazon Connect 7/18(火) 12:00-13:00 AWS Shield   ※ 通常の開催日時と異なりますのでご注意ください 7/19(水) 18:00-19:00 AWS Lambda 7/26(水) 18:00-19:00 AWS Step Functions ソリューションカット 7/25(火) 12:00-13:00 Monitoring on AWS -AWS運用監視- お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。