Amazon Web Services ブログ

re:Invent 2016 でリリースした Amazon AppStream 2.0 についてお知らせします。このアプリケーションストリーミングサービスは、デスクトップブラウザに Windows アプリケーションを配信することができます。 フルマネージド型の AppStream 2.0 は、多目的、コンピュート最適化、メモリ最適化のストリーミングインスタンスでアプリケーションを実行することにより、一貫性のあるスケーラブルなパフォーマンスを提供し、安全で忠実度の高いストリーミングプロトコルの NICE DCV を介して配信します。エンタープライズおよび公的機関のお客様は、レガシーアプリケーションストリーミング環境の代わりにオンプレミスでインストール済みの AppStream 2.0 をすでにご利用されています。こうしたお客様は AppStream 2.0 を使用して、商用アプリケーションおよびビジネスアプリケーションをデスクトップ ブラウザに配信しています。ISV をご利用されているお客様はコードを変更せずに、AppStream 2.0 を使用してアプリケーションをそのままクラウドに移動しています。こうしたお客様はデモ、ワークショップ、企業の SaaS プランなどに注目しています。 高評価を頂いている AppStream 2.0 には新しい機能が迅速に追加されています (AWS の平均に比べても速い方です)。今年に入ってからすでに image builder、SAML 2.0 のフェデレーティッドアクセス、CloudWatch モニタリング、Fleet Auto Scaling、シンプルなネットワークセットアップ、ユーザーファイル用の永続的ストレージ (Amazon S3 によりバックアップ)、VPC セキュリティグループのサポート、ユーザー向けのウェブポータルを含む組み込みのユーザー管理が追加されています。 新しい GPU によるストリーミングのインスタンス 専用のデザイン、エンジニアリング、HPC、メディアアプリケーションをユーザーに提供するために AppStream 2.0 を使用したいというリクエストを数多く頂きました。こうしたアプリケーションは、通常グラフィックスを集中的に使用し GPU (グラフィックスプロセッシングユニット) と組み合わせた高額で高性能の […]

Hightail (旧社名: YouSendIt) は、世界各地の 5,000 万人以上の専門家が優れたコンテンツをユーザーに提供できるよう支援することで、創造的な作業の確認、改善、承認方法を合理化しています。Hightail は、ファイル共有会社として 2004 年に設立されて以来、付加価値のある創造的なコラボレーションサービスの提供へと戦略的方向を転換し、著名な顧客を数多く獲得しています。 本日のゲスト投稿では、Hightail の技術担当上級副社長である Shiva Paranandi 氏が、同社が実施したオンプレミスからクラウドへのペタバイト単位のデータ移行について語ります。クラウドベンダーの評価プロセスと、すべてを AWS に移行した理由が述べられています。 Hightail はユーザーが大きなファイルを簡単に共有して保存できる方法を提供するために設立されましたが、それ以降、創造的なコラボレーションツールへと進化してきました。当社は、ユーザーがデジタル資産を管理、共有するだけの場所ではなく、創造的なチームを作り、顧客とつながり、創造的なワークフローを開発して、最初から最後までプロジェクトを管理できる場所になりました。現在では、Lionsgate や Jimmy Kimmel Live! といった有名ブランドのコラボレーションサービスの原動力となっています。当社は、国内外の顧客が増える中で、製品開発とユーザーへのサービスに対して社内的により傾注する必要がありました。独自のデータセンターの運営には、予定していたよりも多くの時間、費用、人材が必要になることがわかりました。 より迅速に反復して顧客のニーズを満たし、市場までの時間を大幅に改善する手法が必要でした。データセンターのコストを削減し、世界各地の特定のリージョンで迅速にスケールアップする柔軟性が必要だったのです。新しい場所でのデータセンターの設営には長い時間がかかり、当社が達成できる成長ペースの妨げとなっていました。さらに、使用することもないストレージキャパシティーを所有することになる、ニーズに先回りした購入にはうんざりしていました。頻繁に使用しないデータを非アクティブなストレージに保持する一方で、顧客のリクエストに応じてそのデータを迅速に取り出せることでコストを削減する、階層型で非常にスケーラブルなストレージソリューションが必要でした。当社の主な推進力は俊敏性と革新であり、クラウドはそれらを強力に可能にしてくれます。それを踏まえて、ストレージとコンピューティングインフラストラクチャの管理にリソースを投入するのではなく、ビジネスを差別化する構想に時間とコストを費やすことができる、クラウドファーストのポリシーを採用することに決定しました。 AWS とクラウド競合他社の比較 移行の開始にあたって、まず AWS、Google、IBM、Microsoft を含むさまざまなクラウドベンダーの評価を行いました。当社にとっては明らかに AWS が抜きん出た選択肢でした。ある時点では、ニーズを満たすために複数のクラウドプロバイダーからのサービスを組み合わせることを検討しましたが、最適なルートは AWS を単独で使用することであると判断しました。トレーニング、同期、サポート、システムの可用性、それに他の移行や管理の要素を考慮すると、複数のクラウドを使用する手法は実用的ではありませんでした。最善のコスト削減と、ほかに例を見ないパートナーソリューションのエコシステムにより、他のベンダーは必要なく、すべてを AWS に移行することを選択しました。 AWS に移行することで、ギガバイトあたりの最低料金、リッチなエコシステムへのアクセス、社内の迅速な人材開発、SOC II コンプライアンスの維持が可能になりました。エコシステムは特に当社にとって重要で、非常に多くのパートナーを持つ AWS は競合他社とは一線を画していました。実際に、イメージのプレビュー、ビデオのエンコード、プレゼンテーションの提供などのサービスについて当社が依存しているすべてのベンダーは既にこのネットワークに参加しているため、既存の投資や専門知識を簡単に利用することができました。別のプロバイダーを選択していれば、既に正しく稼働しているプラットフォームからの移行が必要になりますが、これは当社にとって望ましい結果ではありませんでした。また、AWS のテクノロジーについて社内で開発できる人材の数も驚くべきものでした。AWS の使用に関する内部チームのトレーニングは、AWS カンファランス、トレーニング教材、サポートなどの利用可能なツールを使用した簡単なプロセスです。 ペタバイト単位のデータの移行 AWS を選択したことで、作業が簡単になりました。多くの場合、社内で使用していたよりも優れた機能が提供されました。オンプレミスストレージから AWS に数ペタバイトのデータを簡単に移行できました。AWS の Direct Connect により高速に処理を進めることができたため、3 か月ほどですべてのデータをプッシュできました。それによるユーザーへの影響はありませんでした。AWS Key […]

昨今ではスマートホーム、ビッグデータ、IoT デバイス、携帯電話、ソーシャルネットワーク、チャットボット、ゲームコンソールなどが一般的に普及しており、ストリーミングデータはごく普通のことになりました。Amazon Kinesis Streams は、何千ものストリーミングデータソースから毎時間ごとにテラバイト単位のデータをキャプチャ、処理、分析、保存できるカスタムアプリケーションの構築を可能にしています。Amazon Kinesis Streams では、アプリケーションが同じ Kinesis ストリームから同時にデータを処理することができるので、並列処理システムを構築することができます。たとえば、処理済みのデータを Amazon S3 だけに送信するようにし、Amazon Redshift で複雑な分析を行ったり、AWS Lambda を使用する堅牢なサーバーレスストリーミングソリューションを構築することもできます。 Kinesis Streams では消費者が複数のストリーミングユースケースを利用できるようにしていますが、今後は Kinesis Streams でサーバー側の暗号化 (SSE) をサポートすることにより、移動中のデータをより効率的に保護できるようになりました。この新しい Kinesis Streams の機能により、データのセキュリティを強化したり、組織のデータストリーミングで必要となる様々な規制とコンプライアンス要件を満たすことができます。 Kinesis Streams は Payment Card Industry Data Security Standard (PCI DSS) のコンプライアンスプログラムで AWS 対象範囲内サービスの 1 つになっているほどです。PCI DSS は、主要な金融機関が設立した PCI Security Standards Council が管轄する専有情報のセキュリティ基準です。PCI DSS コンプライアンスは、カード所有者のデータやサービスプロバイダを含む機密性の高い認証データを保存、処理、転送する機関すべてに適用されます。AWS Artifact を使用して、PCI […]

先日DynamoDBのAuto Scalingについてお伝えし、そこでDynamoDBテーブルのキャパシティ管理を自動化するためにどのように複数のCloudWatchアラームを利用しているかをお見せしました。その裏では、これからいくつかの異なるAWSサービスに渡って利用が予定されている、もっと一般化されたApplication Auto Scalingのモデルを使うことでこの機能を実現しています。 新しいAuto Scalingのモデルはターゲットトラッキングと呼ばれる重要な新しい機能を含んでいます。ターゲットトラッキングを使ってAuto Scalingのポリシーを作成する時には、特定のCloudWatchメトリクスに対してターゲットとなる値を選択します。Auto Scalingはそのメトリクスがターゲットに向かう様に適切な(スピーカーで言う)つまみを回し、合わせて関連するCloudWatchアラームも調整します。どういったメトリクスであれアプリケーションにとって意味のあるもので必要なターゲットを指定するという方法は、元々あるステップスケーリングポリシーの様に手動でメトリクスのレンジと閾値を設定するよりも、一般的にはより簡単で直接的なやりかたです。しかし、より高度なスケーリング戦略を実装するために、ターゲットトラッキングとステップスケーリングを組み合わせることも可能です。例えば、スケールアウトにはターゲットトラッキングを使い、スケールインにはステップスケーリングを使う等が考えられます。 EC2に新しい機能 本日、EC2 Auto Scalingにターゲットトラッキングのサポートを追加しました。Application Load Balancerのリクエスト数、CPU負荷、ネットワークトラフィック、またはカスタムメトリクスによるスケーリングポリシーを作成することができます(ターゲット毎のリクエスト数というメトリクスは新しいもので本日のリリースの一部になります)。 これらメトリクスは重要な特徴が共通しています: EC2インスタンスを追加することで(全体の負荷が変化していない時に)、メトリクスを下げることになります。もしくはその逆もです。 ターゲットトラッキングを使ったAuto Scaling Groupを作るのは簡単で、ポリシーの名前を入力し、メトリクスを選択し、希望するターゲットの値を設定するだけです: スケールイン側のポリシーを無効にすることもできます。その場合、手動でスケールインしたり、別のポリシーを使うことができます。 ターゲットトラッキングポリシーは、AWS Management Console、AWS Command Line Interface (CLI)、またはAWS SDKでも作成することができます。 以下は、ターゲットトラッキングを使おうとする時に頭にいれておくべき項目になります: 1つのAuto Scaling Groupに対して、異なるメトリクスを参照している複数のターゲットを設定することができます。スケーリングは常に一番高いキャパシティを求めるポリシーに従います。 メトリクスのデータが不十分な時はスケーリングは発動しません。 Auto Scalingはメトリクスの急速で一時的な変動を補い、関連するキャパシティの急激な変動を最小化しようと努力します。 カスタムメトリクスでのターゲットトラッキングはAuto Scaling APIやAWS Command Line Interface (CLI)で設定することができます。 多くのケースで、1分間隔で入ってくるメトリクス(詳細モニタリングとも言われます)に応じてスケールするように選択すべきです。5分間隔のメトリクスをスケーリングの基本にすると、反応時間が遅くなってしまいます。 本日から利用可能です この新しい機能は本日から利用可能で、追加料金無しに使い始められます。より詳しくは、Auto Scalingユーザガイドのターゲットトラッキングスケーリングをご覧ください。 — Jeff; 原文: New – Target Tracking Policies for EC2 […]

私のようなタイプの人であれば、人工知能 (AI) や機械学習 (ML)、ディープラーニングは実に興味深く胸を躍らせるトピックではないかと思います。AI、ML、ディープラーニングが今まで以上に幅広く利用されるようになるに連れ、Dr. Issac Asimov 氏がサイエンスフィクションで描いた「スター・ウォーズ」に出てくるようなロボット工学そして医学の進歩、さらには「スタートレック」のキャプテンカークやそのクルーに「誰も行ったことのない場所へ、勇敢に突き進もう (to boldly go where no man has gone before)」と言わせたテクノロジーが実際に可能になるのではないかと思わずにいられません。   前述のトピックに興味がある人にとって、画像や動画を複数のカテゴリに区別する畳み込みニューラルネットワーク (Convolutional Neural Networks) や、音声認識、自然言語によるインターフェース、推奨エンジンなど、ディープラーニングにより可能となる AI や ML のソリューションには馴染みが深いのではないかと思います。けれども、データサイエンティスト、機械学習の利用者、リサーチサイエンティスト、ディープラーニングに興味を持つ熱心なユーザー達がこうしたテクノロジーに携わりインフラストラクチャや環境、ツールを設定する作業は必ずしも簡単ではありません。多くの開発者はディープラーニング技術を使用して、ディープラーニングをトレーニングモデルそしてソリューション開発に早く繋げていきたいと考えています。こうした理由から、経験豊富なデータサイエンティストであれ、今から始めたいと思っている興味津々の開発者まで、速くディープラーニングのソリューションを構築したいと思っている方々に向けて、いくつかのリソースをご提供したいと思います。 ディープラーニングのリソース Apache MXNet は Amazon が選んだディープラーニングのフレームワークです。Apache MXNet フレームワークと NVIDIA GPU コンピューティングを組み合わせれば、スケーラブルなディープラーニングプロジェクトとソリューションを簡単に AWS クラウドで開始できます。MxNet のディープラーニングの旅を始める方々を対象に、様々なセルフサービス形式のチュートリアルやデータセットが今すぐ利用できるようになっています。 AWS ディープラーニング AMI の起動: このガイドでは、Ubuntu で AWS ディープラーニング AMI を起動する手順を説明しています。 MXNet – コンピュータビジョンのアプリケーションを作成: この実践的なチュートリアルは構築済みのノートブックを使用してニューラルネットワークの利用でコンピュータビジョンを構築し、手書きの数字を識別する方法を説明します。 AWS […]

SA岩永です。AWS上にシステムを構築する際に、アプリケーションのデプロイをどのように行うか？については多様なやり方が考えられますが、今日はAWS CloudFormationを使ったデプロイをご紹介したいと思います。CloudFormationはインフラ構築のツールとして考えられている方も多いと思いますが、最近は特にAmazon ECSやAWS LambdaといったComputeサービスへのアプリケーションデプロイツールとしての活用が進んでいます。AWSのリソースはAWS Command Line Interface (CLI)やSDK等での操作が可能なので自作のツール等を使われるのはもちろん1つの選択肢ですが、もしCloudFormationを検討されたことのない方は、ぜひこの投稿を参考にして頂けるとありがたいです。 デプロイツールとしてのCloudFormationのメリット 最初に結論をまとめておきます。CloudFormationを使ったデプロイには以下の様なメリットがあります。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 宣言的にデプロイが定義・実行できる アプリケーションに関連する他のAWSリソースも合わせて管理可能 現在お使いのデプロイツールで、逆に上記の様な観点で困ったことのある方は、この投稿をじっくり読んで頂くと良いと思います。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 例えばCLIで行う様なデプロイツールの場合、そのツール自体のインストール等が必要になりますが、CloudFormationであればブラウザからテンプレートを指定するだけでデプロイできます。CloudFormationの一番のメリットはここです。アプリケーションの構成を記述したYAML or JSONのテンプレートファイルを用意するだけで、すぐにデプロイが可能です。 CloudFormationも実態はAWSのAPIを実行しながらリソースを作成・更新しますが、CloudFormationの場合にはAPIの実行そのものをCloudFormationのサービス側でやってくれます。例えばECSのデプロイで新しいTask Definitionを作成した後でそれを指定してServiceを更新するという依存関係のある2回のAPI操作を順番に実行する必要がありますが、CloudFormationに1回命令を送るだけで後のAPI操作はCloudFormationのサービスが代わりにやってくれます。なので、デプロイが終わるまで実行プロセスが待っている必要もないですし、複数人の排他的実行も実現できますし、さらに現在の状態と過去の履歴というデータの保存までもやってくれます。 もちろん、CloudFormation自体もAWSのサービスなので、CLI/SDKでの操作は可能です。もしもデプロイをCLIで実行して終わるまで待ちたい、ということであれば、aws cloudformation deployというコマンドを使うと更新が終わるまでポーリングしながら待ってくれます。この場合に必要なものはAWS CLIのインストールのみなので、そこまでハードルの高いものではありません。 宣言的にデプロイが定義・実行できる AWSのAPIを利用しながらデプロイツールを自作する場合には、リソースの作成順序に気を払いながら、かつ途中で失敗した場合のエラーハンドリング等も考慮しつつ手続き的に実装する必要があります。これはシンプルな構成であればそこまで難しくはないのですが、対応したい機能が徐々に増えてくるとだんだんと実装が複雑化してきてしまいます。 CloudFormationで使うテンプレートは、手続きを記述するのではなく、希望する状態を宣言的に定義するものです。そのため、複雑な構成であっても簡潔さを保って記述することができますし、多くのケースで各リソース間の依存関係も自動で判断されるので、実行順序を考えて記述する必要もありません。もちろん、テンプレートにはパラメータを設定することも可能なので、例えばECSであれば新しく作成したコンテナイメージ名をパラメータにしておくと、デプロイはそのパラメータを更新するだけで済みます。 アプリケーションに関連する他のAWSリソースも合わせて管理可能 ECSやLambdaは、それ単体だけで利用するケースよりも、他のAWSのサービスも合わせて利用されることが多いと思います。例えば、AWS Identity and Access Management (IAM)のRoleは良く使われますし、データベースとしてAmazon DynamoDBを使ったり、ECSのコンテナへの負荷分散にElastic Load Balancingを使うことは非常に多く、場合によってはアプリケーションのデプロイ時にそれらのリソースの更新も行いたいケースもあります。 CloudFormationでは他のリソースも合わせて定義して操作させられるので、そういったケースに非常に強力なツールとなります。アプリケーションと同じテンプレートで作成することもできますし、昨年リリースされたCross Stack Referenceという機能を使うと、先に作成しておいたリソースをアプリケーション側から参照するといった使い方もできます。 CloudFormationを使ったECSのデプロイ例 こちらは、ECSへの継続的デプロイメントについて紹介した以下のブログをご参照頂くのが良いです。 AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント ブログで紹介されている構成では、GitHubへのコードのpushをトリガーにして、イメージのビルドからECSのServiceの更新まで一貫したものを紹介していますが、Service更新部分はCloudFormationテンプレートを使って実施しています。また、AWS CodePipelineがデプロイ方式としてCloudFormationに対応しているので、簡単に設定することが可能です。 参考のために、Task DefinitionとServiceとIAM […]

【注意】セミナーの実施日程について更新がありました．最新の実施日程は，こちらをご覧ください． こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー8月の配信についてご案内させて頂きます。8月は開発者の方々に役立つ内容を多めに放送する予定です。ソリューションカットでは、デプロイをテーマにしたものと，Redshift のテーブル設計についてのものをお送りします。また今年に入って大きなアップデートがあった DynamoDB についてもお送りします。   8月の開催予定   サービスカット 8/2(水) 18:00-19:00 AWS X-ray 8/9(水) 18:00-19:00 Amazon DynamoDB 8/23(水) 18:00-19:00 AWS MobileHub 8/30(水) 18:00-19:00 AWS Key Management Service (KMS) ソリューションカット 8/22(火) 12:00-13:00 Deployment on AWS 8/29(火) 12:00-13:00 Amazon Redshift テーブル設計詳細ガイド お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

当社は、数年前に CloudWatch ダッシュボードの提供を開始しました。提供開始にあたって私が書いた投稿で、選択された CloudWatch メトリクスをグラフィカル形式で表示するダッシュボードをインタラクティブに作成する方法をご紹介しました。提供開始後に、フルスクリーンモード、暗いスキンのテーマ、Y 軸範囲のコントロール、名前変更の簡略化、永続的ストレージ、新しい視覚化オプションなどの追加の機能を導入しました。 新しい API および CLI コンソールのサポートはインタラクティブな使用には非常に役立ちますが、多くのお客様から、ダッシュボードとその内部のウィジェットのプログラムによる作成と操作のサポートを求める声が寄せられました。ダッシュボードの動的な構築と管理、および対応する AWS リソースの作成と削除に応じたウィジェットの追加と削除が求めらました。その他のお客様からは、2 つ以上の AWS アカウント間で一貫したダッシュボードのセットを設定、管理する機能の要望が寄せられました。そして、CloudWatch ダッシュボードの API、CLI、AWS CloudFormation のサポートの提供が開始され、今すぐご利用いただけるようになったことをここに発表いたします。4 つの新しい API 関数 (および同等の CLI コマンド) があります。 ListDashboards / aws cloudwatch list-dashboards – アカウント内のすべてのダッシュボードのリスト、または共通のプレフィックスを共有するサブセットを取得します。 GetDashboard / aws cloudwatch get-dashboard – 1 つのダッシュボードの詳細を取得します。 PutDashboard / aws cloudwatch put-dashboard – 新しいダッシュボードを作成するか、既存のダッシュボードを更新します。 DeleteDashboards / aws cloudwatch delete-dashboards – […]

AWS は 62 回目となる値下げを発表いたします。今回の対象は EC2 の Microsoft SQL Server Standard Edition です。多くのエンタープライズワークロード (特にオンプレミスまたは企業データセンター) は、Microsoft Windows で実行されています。そのグローバルな展開およびパートナーエコシステムによって支えられたサービスの幅広さにより、Windows アプリケーションの構築、デプロイ、スケール、管理には AWS が最適な場所であると考えています。 Adobe、Pitney Bowes、デブリー大学といったお客様は、すべて中核となる実稼働 Windows Server ワークロードを AWS に移行済みです。これらのお客様のアプリケーションは、SharePoint サイトからカスタム .NET アプリケーションや SAP まで広範囲に実行しており、頻繁に SQL Server を使用しています。AWS の Microsoft SQL Server は EC2 Windows インスタンスで実行され、お客様のアプリケーション開発および移行をサポートできます。リレーショナルデータベースをオンプレミスで実行している場合のように、すべての設定を管理でき、32 ビットおよび 64 ビットバージョンのサポートがあります。本日、R4、M4、I3、X1 インスタンスで実行される EC2 上の Microsoft SQL Server Standard Edition のオンデマンドおよびリザーブドインスタンスの料金を、インスタンスタイプ、サイズ、リージョンに応じて最大 52% […]

この投稿と付随するコードの作成には、下記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 […]