Amazon Web Services ブログ

AWS トレーニングの更新情報 – AWS Technical Essentials および Architecting on AWS コースの改訂

AWS プラットフォームの更新と、受講者から寄せられたフィードバックを反映させるため、技術コースの質を継続的に向上させています。最も人気のある AWS Technical Essentials と Architecting on AWS の 2 つの基礎トレーニングコースが大幅に更新され、AWS を使用したソリューションの作成を始めるための実用的な知識、および高度な学習への道を提供できるように改善されました。

AWS Technical Essentials – 最新情報
このコースは、ソリューションアーキテクト、開発者、SysOps アドミニストレーター、および AWS の利用を始めたい方向けの 1 日間のコースです。クラウドコンピューティング、ストレージ、およびネットワーキングの基礎について学習できます。同じ内容が AWSome Day でも使用されています。AWS の 18 のサービスが、更新されたコースで取り上げられるようになりましたが、特に 10 のコアとなるサービス (EC2、S3、EBS、IAM、Auto Scaling、ELB、RDS、DynamoDB、Auto Scaling、CloudWatch) の詳細を学習できます。新しい包括的なハンズオンラボ演習、およびインストラクター主導のデモにより、実際に使用するソリューションを AWS プラットフォームで作成し始める方法を学習できます。更新されたコースでは、Architecting on AWS や Systems Operations on AWS といった上級コースへ進んで、受講生が学習を継続できるようになっています。詳細についてはコースの説明をご覧ください。

Architecting on AWS – 最新情報
このコースは、ソリューションアーキテクト、およびソリューションデザインエンジニア向けの 3 日間のコースです。このコースでは、AWS Technical Essentials コースの変更点が反映されていて、そのコースで学習した概念を理解していることが前提条件となっています。更新されたこのコースでは、クラウドのベストプラクティス、アーキテクチャパターン、導入事例、および AWS でインフラストラクチャを構築するための他の実際的な方法に重点が置かれています。ハンズオンラボ演習では、Amazon VPC、Amazon EC2、Amazon S3、AWS Lambda などの、AWS の各種サービスを使用して包括的なアプリケーション環境を AWS に構築する方法が説明されます。新しいコンテンツでは、サーバー依存の少ないアーキテクチャを使用したインフラストラクチャの自動化や分離、一般的に誤って設定されるアーキテクチャのトラブルシューティング、および適切にアーキテクチャ設計されたフレームワークの概念についても扱われます。詳細についてはコースの説明をご覧ください。

コースへのアクセス方法
これらのクラスやその他のクラスには、AWS およびトレーニングパートナーを通して参加可能です。グローバルトレーニングスケジュールから今後のクラスについてご覧いただけます。詳細については AWS トレーニングを確認ください。


Jeff;

 

AWS Config Rulesが新しく4つのリージョンで利用可能になりました – US West (オレゴン), EU (アイルランド), EU (フランクフルト), Asia Pacific (東京)

AWS Config Ruleをご利用頂くと、ルールを作成することで、AWS Configにより記録されたAWSリソースの構成確認を継続的に実施することができ、リソースがガイドラインに準拠していない際は通知をすることが可能です。ルールのダッシュボードを使用することで、全体的にコンプライアントな状況かどうかを追跡し、コンプライアントでない状況につながった特定リソースの構成変更を特定するトラブルシューティングにご利用頂けます。

本日、AWS Config Rulesが新しく4つのリージョンで利用可能になりました。:US East (バージニア)に加え、 US West (オレゴン)、EU (アイルランド)、 EU (フランクフルト)、 Asia Pacific (東京)でご利用頂けます。

詳細情報
1. AWSマネジメントコンソールからAWS Configの利用開始
2. AWS Configのリージョンとエンドポイント
3. AWS Configフォーラム

翻訳は酒徳が担当しました。本文はこちら

LiveOps Cloud – AWS を使用した数十億ドル規模のコールセンター市場の開発

LiveOps Cloud は広大な未開発市場を開こうとしています。LiveOps Cloud は、コンタクトセンター業界におけるソリューションプロバイダとして長年サービスを提供してきました。最近では、完全に AWS を使用して構築され、運用されている、CxEngage という新しい Contact Center-as-a-service プラットフォームを立ち上げました。LiveOps Cloud のエンジニアリング CTO 兼 SVP、Jeff Thompson 氏にこのすばらしい最新のサービスを開始するに至った経緯について尋ねてみました。

Jeff;


LiveOps Cloud は創立 16 年の企業です。当社は LiveOps Inc から生まれた新しい企業で、母体会社のコンタクトセンターソリューション提供における長い歴史を、クラウドの利便性、パフォーマンス、低コストが重視される新しい時代へと引き継いでいくことが我々のミッションです。

コンタクトセンタービジネスは広大で、世界中に少なく見積もっても 1,500 万人もの雇用を生み出す、数十億ドル規模からなる市場です。しかしながら、この業界はクラウドコンピューティングとしては後発で、クラウドインフラストラクチャとツールに関する技能を持つのは、コンタクトセンター就労人口のわずか 10% 程度です。特に銀行や小売業などの伝統的業種では、有効期限が近づいているオンプレミスのレガシーコールセンターシステムが多数存在しています。これらのシステムは、コスト削減、パフォーマンスの向上と高度化、新興市場への対応といった、企業が抱える現在の市場ニーズを満たすには不適当です。

クラウドベークオフ
当社では、100% クラウドで稼働する contact center-as-a-service (CCaaS) を作成を計画していました。システムは常時稼働し、安全で、マルチテナントで、すぐにスケーリングできるプラットフォームなので、いつでもどこでもお客様に特化したサービスを提供できます。当社の CCaaS はまさに "ホッケースティック" のような高成長パターンを遂げることを期待しています。それを実現するために、どんなプラットフォームが最も効果的かを注意深く考慮する必要がありました。

ベークオフ前に、いくつかの代替案を探しました。Azure、Rackspace、Google、および AWS はクラウド内のプロバイダミックスに入っており、コロケーション設備の使用を考えました。しかし、最後にあげたサービスこそ、まず向かうべきところでした。コロケーション外で運用するプラットフォームでは、新しいプラットフォームに組み込む必要のある、冗長化とスケーラビリティを実現できないことを経験を通して知っていました。当社は Microsoft 販売店ではなく、プラットフォームの作成に Windows 以外の多くのツールと Linux を多く使用するため、Azure は除外しました。Rackspace の IaaS は良かったものの、当社のビジネス目標にはグローバル性が不十分でした。さらに、プラットフォームを構築するために必要な、幅広いアプリケーションがなかったので、Google も除外しました。

明白な勝者
明白な勝者は AWS でした。AWS では、当社が求めていた特徴とメリットがすべて提供されていました。AWS には、驚くほど充実したサービスカタログがあり、競合クラウドプロバイダが追いつけないペースで新規サービスをリリースしています。現時点ですべてのサービスが必要なわけではありませんが、これらのサービスが存在し、AWS は革新的で、常にサービスが追加されていることを知っているので、真の安心感があります。将来、新たなニーズが発生したり、機能がリクエストされたりした場合、AWS には、それを満たすために必要なサービスが備わっています。当社が使用している AWS のサービスには、このプラットフォームに欠かせない 2 つの強力なデータサービスである Amazon RedshiftAmazon Kinesis、およびエージェントツールバーへのメッセージングを行う Amazon Simple Queue Service (SQS) が含まれています。

CxEngage ビジネスモデルには不可欠な点ですが、AWS のグローバル性は非常に高いものです。北アメリカと西ヨーロッパ市場は重要な収益源となっています。また、中国、インド、およびアジアパシフィックリージョンといった新興コールセンター市場にも重要な商機があるとみています。AWS は世界中の 12 の地域で運用されています。つまり、新しいお客様と密接な連絡を保ってサービスを提供できるので、レイテンシーを減らし、パフォーマンス向上できます。当社のプラットフォームを利用しているお客様は、着電後のシステム内のタイムラグを望んでいません。特定の境界内でのデータ保持に関係した、所有権の問題の解決にも役立ちます。

AWS を使用する大きな利点は、柔軟性と財務パフォーマンスです。例えば、特定の Amazon EC2 インスタンスタイプを設計し、CxEngage プラットフォームの特定サービスのパフォーマンスニーズに合わせることができます。より多くの I/O が求められる場合もあれば、より大容量のメモリが求められる場合もありますが、正確なニーズを見極めることができ、オーバープロビジョニングを避けることで、パフォーマンスが最適化されるだけでなく、財務目標も達成できます。この点と、AWS の従量制料金モデルにより、AWS は当社の財務部で好評価を得ました。

シンプルで心配無用
AWS ではビジネスを構築しやすくなります。例えば、PCIHIPAA や、AWS GovCloud (US) に含まれるコンプライアンスや規制基準の組み込みサポートにより、潜在的な障害をすばやく解決し、新規の顧客および重要な顧客との契約の獲得をサポートします。これらの要件について考えることなく先へ進むことが可能です。

2014 年には、コールセンターのための次世代ソリューションの構築に乗り出しました。当社は AWS に賭けました。その 18 か月後に CxEngage を開始した時には、プラットフォームに関するすべての財務およびパフォーマンス予想は現実となりました。そして AWS の利用によって起こると予測したすべてのことが、その通りになったのです。すべてはシンプルで、心配の必要はありませんでした。AWS は当社のビジネスの基礎的な要素で、成長プランに不可欠なパートナーとなっています。

Jeff Thompson、LiveOps Cloud プラットフォーム CTO 兼 SVP

 

 

Amazon Route 53でメトリクスベースのヘルスチェック、プライベートホストゾーンのDNSフェイルオーバー、設定可能なヘルスチェックロケーションがアナウンスされました

Amazon Route 53の3つの新しいヘルスチェック機能を発表できることに興奮しています。

メトリクスベースのヘルスチェックにより、Amazon CloudWatchのメトリクスを基にDNSフェイルオーバーが実行できるようになりました。これには、AWSで提供されるメトリクスと、アプリケーションのカスタムメトリクスが含まれます。Amazon Route 53でメトリクスベースのヘルスチェックを作成すると、関連付けられたCloudWatchメトリクスが”ALARM”の状態になると、ヘルスチェックが”Unhealty”なステータスになります。

メトリクスベースのヘルスチェックは、VPC内でプライベートIPアドレスのみを持つEC2インスタンスなど、標準のAmazon Route 53ヘルスチェックでは到達できないエンドポイントのDNSフェイルオーバーを実行する場合にも有用です。Amazon Route 53の計算されたヘルスチェック機能を利用して、メトリクスベースのヘルスチェックと標準のヘルスチェック(標準のヘルスチェックでは、世界中のヘルスチェッカーからエンドポイントへリクエストを送り、健全性を確認します)の結果をあわせて、より洗練されたフェイルオーバーシナリオを実現することもできます。例えば、パブリックのWebページが利用できないか、CPUのLoad Averageやネットワークin/out、ディスクのReadからサーバーが正常でないと判断される場合に、エンドポイントを切り離すような設定ができます。

プライベートホストゾーンのDNSフェイルオーバーでは、プライベートDNSホストゾーンでホストされているリソースレコードセットとヘルスチェックを関連付けて、VPN内の複数のエンドポイントのフェイルオーバーを実行できます。メトリクスベースのヘルスチェックと組み合わせると、プライベートIPアドレスのみを持ち、標準のAmazon Route 53ヘルスチェクで到達できないエンドポイントに対するDNSフェイルオーバーを設定できます。このリリースでは、プライベートホストゾーン内でのエイリアスレコードの作成も、完全にサポートされています。

設定可能なヘルスチェックロケーションにより、どのリージョンからヘルスチェックを行うかを選択できるようになりました。エンドユーザーが集中するリージョンからのヘルスチェック結果に基づいて健全性確認とフェイルオーバーを行いたいお客様は、最もエンドユーザーにとって重要なロケーションからのみヘルスチェックを実施することが可能になりました。

Amazon Route 53のヘルスチェックとDNSフェイルオーバーを利用するのは簡単です。さらに学習したい場合には、詳細や料金についてAmazon Route 53の製品ページか、開発者ガイドを参照してください。

(翻訳はSA国政が担当しました。原文はこちら。)

より良いがん治療を目指して – Fred Hutchinson がん研究センターとの共同作業

Jessica Beegle 氏と Christopher Crosbie 氏による刺激を与える経験談。

Jeff;


がん研究の科学は、新たな学術分野を取り込みながら進化を続けています。例えば、化学療法、増幅放射線治療、および発がん性物質特定のための疫学分野の進歩がこれに含まれます。また病理学によって、病気の様々な症状に対する理解が深まってきています。

コンピュータサイエンスの原則は、がんについての理解と治療方法の探求において、比較的新しい切り口となっています。コンピュータサイエンスに求められているのは、特定の DNA の差異が、がんとどのように関連しているかを解読し、それぞれの患者に対してどのような治療法が最も効果的かを解明することです。ゲノミクスと呼ばれる DNA 研究には、非常に巨大なデータ処理能力が求められるため、この種のタスクを処理するにはコンピュータサイエンスが最適でしょう。実際、科学者たちは、ゲノミクスによって 2025 年までに天文学、YouTube、Twitter を上回るデジタル情報が生成されることを予言しています。

現在はこのようなデータの収集、分析、視覚化のために開発されるソフトウェアの多くが、異なる IT システム、研究施設、ヘルスケア機関、および政府機関といった組織の中で生み出されています。これらの隔たりによって、科学上の発見のスピードが著しく阻害されています。

シアトルにある Fred Hutchinson がん研究センターの研究者たちは、この状況を変えようとしてきました。Fred Hutchinson がん研究センターのヒト生物学部門、および固形腫瘍トランスレーショナルリサーチの理事 Eric Holland 医学博士が率いる研究チームは、分子および医療データの分析ツールの使用と開発を目的とした、Oncoscape と呼ばれるオープンソースウェブアプリケーションを開発しました。Oncoscape により、研究者たちは新たなパターンや関連性を発見できるようになり、さらなるがん研究の発展が可能になりました。

コンピュータサイエンスの現在の技術を活用するため、Oncoscape チームは Github および AWS を採用しました。それにより、Github が提供するコード共有プラットフォームと、AWS が提供するクラウドコンピューティング機能を組み合わせ、相乗効果をもたらすことが期待されました。Holland 博士は次のように語っています。

Oncoscape をクラウドにホスティングすることにより、ソフトウェアの変更および再デプロイが容易になり、開発チームは研究コミュニティのニーズにすばやく対応できます。世界のどこからでもサイトに安全にアクセスできることを知っているので、データのビジュアル化で何が可能になるか、がん研究で協働するためどのように共通のプラットフォームを活用できるかを共同研究者たちに示すことができます。

Oncoscape の AWS デプロイを支援した IT ソリューションアーキテクトの Robert McDermott 氏は、「AWS はプロジェクトのニーズにすばやく対応する上で非常に有能で信頼でき、柔軟性に富むプラットフォームだ」と述べています。さらに、成熟度、信頼性、サービスの幅広さ、およびセキュリティが、AWS を使用する強力な理由となったと述べています。

Oncoscape は Amazon EC2Elastic Load BalancingAmazon CloudWatch、および Amazon S3 を含むいくつかの AWS のサービスを使用しています。このアプローチにより、物理的なロケーション (アベイラビリティーゾーン) 間でのトラフィックの配分や、サイトで発生した問題のイベントをすばやく通知することが簡単に行えるようになりました。Amazon Route 53 の使用が、開発環境に合わせてすばやく修正を行うためにも大変有用であることが証明されています。

以下の表は、Oncoscape 全体の統合と展開を示した相関図で、GithubCircleciDockerHubSlack、および AWS 間の統合ポイントが示されています。

Oncoscape プロジェクトの共同作業についての詳細はビデオをご覧になるか、Oncoscape ホームページをご覧ください。

� Jessica Beegle 氏 (ヘルスケアとライフサイエンスのグローバルエコシステムリーダー) と Christopher Crosbie 氏 (ヘルスケアとライフサイエンスソリューションアーキテクト)

 

週間 AWS – 2016 年 4 月 4 日

先週 AWS の世界で起こった出来事を振り返ってみましょう。

月曜日

4 月 4 日

火曜日

4 月 5 日

水曜日

4 月 6 日

木曜日

4 月 7 日

金曜日

4 月 8 日

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローしてください。また、RSS フィードにもご登録ください

Jeff

Redshiftアップデート:COPYやUNLOADでIAMロールを指定可能に

Amazon Redshiftにデータを読み込む際(COPY)やエクスポートする際(UNLOAD)、その読み書き先(S3)に対してのアクセスを実現するため、これまではCOPYやUNLOADコマンドの引数にIAMのキー情報(アクセスクリデンシャル)を付与する必要がありました。

これが拡張され、Redshiftクラスターに対してIAMロールを付与して、その付与したロールでCOPY、UNLOADができるようになりました。以下がリリースノートの翻訳です。


1つ、もしくは複数のAWS Identity and Access Management (IAM)ロールをRedshiftクラスターにアサインし、データロードやエクスポート時に使用することが可能になりました。Redshiftクラスターはデータロード時(COPYコマンド)やエクスポート時(UNLOADコマンド)に指定されたIAMロールを使用し、結果としてRedshiftから各種AWSサービス(S3等)への操作時に確実にクリデンシャルを利用することになります。IAMロールを使うことで、SQLにAWSアクセスクリデンシャルを埋め込む必要がなくなり、クラスターのセキュリティを向上し、データのロードやエクスポートをシンプルにします。

Redshiftクラスターは長い時間の(COPYやLOAD)オペレーション時には、定期的にIAMロールを再アシューム(Re-assume)します。つまり、暗号化キーを使ったCOPY、UNLOADする場合においてもコマンドは変更されていません。


 

リリースノート(原文):https://aws.amazon.com/about-aws/whats-new/2016/03/amazon-redshift-now-supports-using-iam-roles-with-copy-and-unload-commands/

翻訳:下佐粉 昭(@simosako

ヒッグス粒子を発見した実験で自然界の調査に AWS を使用

同僚の Sanjay Padhi は AWS サイエンティフィックコンピューティングチームの一員です。Sanjay は、重要な科学的発見に役立つコンピューティングリソースを AWS がどのように提供したかに関するゲスト投稿を行いました。


Jeff


質量の起源への洞察を提供する上で重要な役割を担うヒッグス粒子 (神の粒子と呼ばれることもある) は、2012 年に、スイスのジュネーブにある CERN大型ハドロン衝突型加速器 (LHC) で、世界最大の実験装置である ATLAS および CMS により発見されました。この発見の基盤となる理論を提唱した研究者たちは、2013 年ノーベル物理学賞を受賞しています。

フランスとスイスの国境にまたがって地下深くに設置されている LHC は、世界最大 (全周 17 マイル) でこれまでにない高エネルギーの粒子加速器です。これにより、これまで探求してきたいかなる人間の発明よりも小さいスケールで自然界を探ることができます。

実験から生データへ
高エネルギー粒子の衝突により、質量はエネルギーに変換され、その後質量に再変換されて、新しい粒子が作り出されます。この粒子が CMS 検出器で観察されます。この検出器は長さ 69 フィート、幅 49 フィート、高さ 49 フィートで、フランスのセシー村近くにある地下 328 フィートのトンネルに設置されています。CMS からの生データは 1 秒あたり約 1 ペタバイトの割合で 25 ナノ秒毎に記録されます。

CERN Tier 0 データセンターで生データをオンラインおよびオフライン処理した後、そのデータセットは 48 時間以内に世界中の 7 つの大規模な Tier 1 データセンターに配信され、科学者たちがさらに処​​理および分析できるようになります (世界最大のプロジェクトの 1 つである CMS コラボレーションは、43 か国にある 180 を超える機関や大学からの 3,000 人を超える参加メンバーで構成されています)。

フェルミ研究所での処理
フェルミ研究所は、米国エネルギー省によって運営されている 16 の国立研究所のうちの 1 つです。イリノイ州バタビア市郊外に位置するフェルミ研究所は、CERN の CMS 実験のための Tier 1 データセンターの 1 つとして機能しています。

昨年の LHC の衝突エネルギーの増加に伴い、データ同化、イベントシミュレーション、および大規模なコンピューティングの需要も増加しました。この増加に伴い、必要に応じてリソースを動的にプロビジョニングすることでコスト効率を最大化したい、という要望が生じました。

この問題に対処するため、フェルミ研究所サイエンティフィックコンピューティング部門は 2015 年 6 月に HEP (High Energy Physics) Cloud プロジェクトを立ち上げました。このプロジェクトでは、商用クラウドを含む様々なコンピューティングリソースにアクセスするための共通のインターフェイスを提供する仮想施設の開発が計画されました。HEP Cloud プロジェクトでは、AWS を使用することにより、CMS 実験のためのオンプレミス施設に 58,000 コアを伸縮自在に追加する能力を実証しました。

下の画像は、AWS で実行されたシミュレーションの 1 つを示しています。この画像は、2 つの陽子の衝突がエネルギーを作り出した後、新しい粒子となる様子を示しています。

追加の 58,000 コアはフェルミ研究所の計算能力の 4 倍に相当し、すべて CMS 実験専用にプロビジョニングされて、モンテカルロシミュレーションイベントの生成および再構成を行います。290 万のジョブを使用して 10 日間で 5 億を超えるイベントが完全にシミュレートされました。AWS を使用せずにフェルミ研究所のオンプレミスコンピューティングリソースを使用したら、このジョブを完了するのに 6 週間かかることになります。

このシミュレーションは、著名な高エネルギー物理学国際会議の 1 つである Recontres de Moriond の準備のために行われました。世界中の物理学者が、このようなシミュレーションを使用して詳しく自然を調査し、各国から会議に参加した科学者と調査結果を共有します。

HEP Cloud で資金を節約する
HEP Cloud プロジェクトの目的は、計算処理のコストを最小化することです。AWS Cloud Credit for Research では、研究開発とデモンストレーションの優れた取り組みに対して表彰を行っています。

HEP Cloud の意思決定エンジンは施設の頭脳となるもので、いくつかの役割があります。Amazon のスポットチームによって提供されるツールや技術を使用して EC2 Spot Market の価格の変動を監視し、HTCondor を使用して Amazon EC2 インスタンスを初期化し、Amazon Route 53 を使用してインスタンスの DNS 名を追跡し、コードとしてのインフラストラクチャのために AWS CloudFormation テンプレートを使用します。

成功へ至る道の途中で、プロジェクトチームは、Amazon S3 と他のリソースに関する設定の微調整から使用の最適化まで、いくつかの課題を克服しなければなりませんでした。例えば、ストレージのコストやデータアクセスのレイテンシーを最小化するために、複数の AWS リージョンをまたいで補助データを配信するための戦略を考案しました。

AWS への自動スケーリング
下の図は、AWS のスポットインスタンスを使用して、フェルミ研究所のコンピューティング施設を AWS クラウドに伸縮自在かつ自動的に拡張し、CMS ワークフローに使用する様子を示しています。リソースのモニタリングには、Grafana から提供されているオープンソースソフトウェアを HEP Cloud によってカスタマイズして使用しました。

Panagiotis Spentzouris 氏 (フェルミ研究所サイエンティフィックコンピューティング部門責任者) は次のように語りました。

現代の HEP 実験では不規則なサイクルで大量のコンピューティングリソースが必要になるので、プログラムの成功には需要を満たすようリソースを速やかに拡張、収縮できるコンピューティング施設が不可欠です。この目標を達成するために重要な要因は商用クラウドを使用することであり、HEP Cloud により CMS 実験のワークロードを AWS で実行した今回の試みは、このアプローチの価値を実証する上で大きな成功を収めました。

物理学の最先端の調査に AWS が貢献している様子をご覧いただけたのではないかと思います。

Sanjay Padhi 博士、AWS サイエンティフィックコンピューティング

New – AWS CloudFormation の変更点

AWS CloudFormation を使用すると、AWS リソースのコレクション (「スタック」) を制御された予想可能な方法で作成、管理、および更新できます。CloudFormation を使用して、本番ワークロードを稼働するためのスタックの更新が 1 日に何十万回も実行されています。お客様は、初回のテンプレートを定義した後、要件が変わるとテンプレートを修正します。

通常「コードとしてのインフラストラクチャ」と呼ばれるこのモデルを使用すると、開発者、アーキテクト、および運用担当者の各チームが AWS リソースのプロビジョニングと構成を詳細に制御できるようになります。この制御と説明責任の詳細さは、CloudFormation を使用する際に最もはっきりとわかる利点の 1 つです。ただし、CloudFormation には、それほどはっきりとはわからないものの、同じくらい重要な利点がいくつかあります。

整合性 – CloudFormation チームは、AWS チームと連係して、リソースの作成、更新、および削除のセマンティクスについて、新しく追加されたリソースモデルでも整合性を保つようにしています。また、EBS ボリュームや RDS ボリュームの暗号化用の KMS キーなど、関連リソースの再試行、べき等性、および管理について説明できるようにしています。

安定性 – どのような配信システムでも、結果整合性に関連する問題は頻繁に発生し、必ず対処する必要があります。CloudFormation チームではこのような問題を十分認識しており、変更のプロパゲーションが必要な場合には、配信を実行する前に、自動的にそのプロパゲーションが完了するのを待つ仕組みになっています。多くの場合、CloudFormation チームはサービスチームと連係して、API と成功シグナルが CloudFormation で適切に使用できるよう調整されていることを確認します。

均一性 – CloudFormation では、スタックが更新される際に、インプレース更新とリソース置換のいずれかが選択されます。

この作業はすべて一定の時間がかかり、関連サービスが公開または更新される前にテストを完了できない場合もあります。

更新のサポートの向上
先述のように、AWS の多くのお客様が、本番スタックの更新を管理するのに CloudFormation を使用しています。お客様は、既存のテンプレートを編集 (または新しいテンプレートを作成) した後、CloudFormation の更新スタックオペレーションを実行して、変更を有効にします。

新しいテンプレートやパラメータ値に合わせてスタックが更新される際に CloudFormation が実行する変更の詳細について知りたい、というお問い合わせが、多くのお客様から寄せられています。変更のプレビューを行い、その変更が期待通りであることを確認してから、更新を実行するためです。

CloudFormation のこの重要なユースケースに対応するために、「変更セット」という概念を導入しました。変更セットを作成するための第 1 段階として、お客様は、更新対象のスタックに対する変更内容を送信します。CloudFormation では、更新対象のスタックが新しいテンプレートやパラメータ値と比較され、変更セットが作成されます。お客様は、この変更セットを確認してから、適用 (実行) するかどうかを選択できます。

この新しいモデルにより、変更される可能性のある内容を詳細に知ることができるだけではなく、更新をより詳細に制御できるようにもなります。IAM を使用すると、UpdateStackCreateChangeSetDescribeChangeSet、および ExecuteChangeSet といった CloudFormation の特定の機能の使用を制御できます。例えば、ほとんどの開発者に変更セットの作成とプレビューを許可するものの、実行は経験豊富な開発者で構成される少人数のグループのみに許可する、といった具合です。自動化項目をいくらか追加すると、データベースサーバーやネットワークといった主なリソースを変更しようとするとアラートが発生する、または追加の承認を要求するといった設定を行うこともできます。

変更セットを使用する
変更セットに関連する操作を順を追って見ていきましょう。AWS コマンドラインインターフェイス (CLI)AWS Tools for Windows PowerShell、および CloudFormation API を使用して、通常と同じ機能を利用できます。

今回は、まず、1 つの EC2 インスタンスで LAMP スタックを実行するスタックを作成します。リソースが作成されます。

その後、より複雑なアーキテクチャを利用することにします。同僚から適切なテンプレートをもらいました。「信頼するが確認する」という原則に基づいて、テンプレートを使用するとどうなるかを確認するために、変更セットを作成します。[Create Change Set] をクリックします。

その後、新しいテンプレートをアップロードして、変更セットに名前を割り当てます。テンプレートでパラメータを使用する場合は、ここで値を入力できます。

ここでは、既存のタグを変更することも、新しいタグを追加することもできます。スタックの詳細オプションを設定することもできます (当然、詳細オプションは、変更セットを実際に実行するまで適用されません)。

1、2 回クリックして設定を確定すると、テンプレートが分析され、スタックに適用した場合の結果がチェックされ、変更のリストが表示されます。

変更を有効にするには、ここで [Execute] をクリックします。変更セットの適用を見送ることも、他の方法を探すために変更セットをいくつか作成することもできます。準備が整ったら、変更セットを指定して、実行します。

CloudFormation がアクションを開始し、変更セットに沿って変更が実装されます。

数分後には、スタックの新しい構成が整い、完全に運用できるようになります。

これで完了です。先述のように、実行する変更セットを選択する前に、複数の変更セットを作成して、試してみることができます。この場合、実装しなかった変更セットは不要になるので、破棄します。

ロールバックを管理する
スタックの更新に失敗した場合、可能な限り、更新前の状態にロールバックされます。ロールバックオペレーションは失敗することもあります。多くの場合、ロールバックが失敗する原因は、CloudFormation の範囲外で行われた変更です。最近、ロールバックの結果をより適切に制御できるよう、新しいオプションが公開されました。このオプションの詳細については、Continue Rolling Back an Update for AWS CloudFormation stacks in the UPDATE_ROLLBACK_FAILED state をご覧ください。

今すぐ利用可能
変更点は今すぐ利用できます。ぜひご使用ください。


Jeff

週間 AWS – 2016 年 3 月 28 日

先週 AWS の世界で起こった出来事を振り返ってみましょう。

月曜日

3 月 28 日

火曜日

3 月 29 日

水曜日

3 月 30 日

木曜日

3 月 31 年

金曜日

4 月 1 日

日曜日

4 月 3 日

来週をお楽しみに。それまでは、Twitter でフォローしてください。また、RSS フィードにもご登録ください

Jeff