Comments
Description
Transcript
クラウドコンピューティングのアーキテクチャ： ベスト
Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 クラウドコンピューティングのアーキテクチャ： ベストプラクティス 2010 年 1 月 最終更新：2011 年 1 月 Jinesh Varia [email protected] ページ 1- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 序論 ここ何年間か、ソフトウェアアーキテクトは、高度にスケーラブルなアプリケーションを構築するベストプラ クティスを見い出し、実践してきました。今日の「テラの時代」では、成長の一途をたどるデータベース、予 期できないトラフィックパターン、さらに速まる応答時間への要求のために、こうした概念はさらに適切です。 本書では、こうした従来の概念を強調、繰り返しながら、クラウドコンピューティングに照らし合わせてどの ように進化していくのかを説明します。また、クラウドのダイナミックな特質のために出現してきた弾力性な ど、前例のない概念についても説明します。 本書は、固定化された物理的環境から仮想化されたクラウド環境へ、エンタープライズクラスのアプリケーシ ョンの移行を準備中のクラウドアーキテクトを対象としています。本書では、新たにクラウドアプリケーショ ンを構築する、または既存のアプリケーションをクラウドに移行する際の概念、原則、ベストプラクティスに 焦点を当てます。 背景 クラウドアーキテクトとして大切なことは、クラウドコンピューティングの利点を理解することです。この章 では、クラウドコンピューティングのビジネス上と技術上の利点、および今日利用可能な各種の AWS サービ スについて説明します。 クラウドコンピューティングのビジネス上の利点 クラウドでアプリケーションを構築するにあたり、明確なビジネス上の利点がいくつかあります。以下にその いくつかを挙げます。 ほとんどゼロのインフラストラクチャへの先行投資：大規模なシステムを構築する必要がある場合、土地、物 理的セキュリティ、ハーアドウェア（ラック、サーバー、ルーター、バックアップ電源）、ハードウェアマネ ジメント（電源管理、冷房装置）、オペレーションスタッフに投資するのは、莫大な費用がかかります。先行 投資が莫大にかかるため、通常プロジェクトが開始する前でさえ、経営陣による承認の段階をいくつも経なけ ればなりません。現在、ユーティリティスタイルのクラウドコンピューティングでは、固定費や立ち上げ費用 は必要ありません。 ジャストインタイム インフラストラクチャ：これまでは、御社のアプリケーションが普及し、インフラスト ラクチャが拡張しなかった場合、自らの成功の犠牲者になっていました。反対に、かなりの投資を行ったのに も関わらず、アプリケーションが普及しなかった場合は、失敗の犠牲者になっていました。アプリケーション をクラウドでジャストインタイム方式の自己プロビジョニングで導入することにより、御社は大規模システム に事前に調達する容量について心配する必要がなくなります。これにより、アプリケーションが増大する場合 のみスケールアップし、使用した分だけ支払えば良いため、アジリティが向上し、リスクが減り、運用コスト が削減されます。 さらに効率的なリソースの活用：システム管理者は、通常ハードウェアの調達（容量を使い果たす時期）や、 高度なインフラストラクチャの活用（過剰なおよびアイドルな容量を抱える時期）について悩みます。クラウ ドを使用すれば、アプリケーションにリソースの要求や解放をオンデマンドで実行させることにより、さらに 効果的かつ効率的にリソースを管理できます。 ページ 2- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 利用量ベースのコスト設定：ユーティリティスタイルの価格設定により、利用したインフラストラクチャの分 のみ請求されます。割り当てられたが使用していないインフラストラクチャに対して支払いは発生しません。 この方式は、コスト削減の新たな一面です。御社でクラウドアプリケーションをアップデートする最適化パ ッチを配置する際に、直ちにコスト削減を認識できます（ときには翌月の請求書で認識できることもあるで しょう）。たとえば、キャッシングレイヤーによりデータリクエストが 70％減尐すると、ただちに節約が始 まり、翌月の請求書ですぐに結果がわかります。さらに、クラウドの上位にプラットフォームを構築している とき、同一のフレキシブルな従量制のコスト構造を自社の顧客に適用できます。 市場投入までの時間を短縮：並列化は、処理をスピードアップする優れた方法の 1 つです。並列して実行する コンピュータ集約またはデータ集約であるジョブは、1 台のマシンで処理するのに 500 時間かかりますが、ク ラウドアーキテクチャ 6 だと、500 インスタンスを作成して起動し、同じジョブを 1 時間で処理します。弾力 性のあるインフラストラクチャを利用して、市場投入までの時間を短縮し、対費用効果のある並列化を利用す る機能を搭載したアプリケーションを提供します。 クラウドコンピューティングの技術上の利点 クラウドコンピューティングの技術上の利点をいくつか挙げます。 自動化－「スクリプト可能なインフラストラクチャ」：プログラマブル(API 主導) インフラストラクチャを活 用して、繰返し可能なビルドとデプロイシステムを構築可能です。 自動スケーリング：アプリケーションは、予期しない需要に合わせて、人間が介入せずにスケールアップ、ス ケールダウンが可能です。自動スケーリングにより自動化が推進され、さらに効率的に機能します。 事前のスケーリング：アプリケーションは、トラフィックパターンの適切な計画を理解し、予想される需要に あわせてスケールアップとスケールダウンするため、スケーリング中にコストを抑えることができます。 さらに効率的な開発ライフサイクル：製品システムは、開発環境とテスト環境にとして使用するために、容易 にクローン化できます。ステージング環境は、容易にプロダクション環境に昇格します。 テスト可能性の改善：テストを実施するためのハードウェアが欠乏しません。開発プロセスの各ステージでテ ストを導入し、自動化します。テストフェーズ期間中のためのみに事前設定された環境を伴う「インスタント テストラボ」を構築可能です。 災害回復と事業継続性：クラウドは、DR サーバーとデータストレージのフリートの維持のために低コストの オプションを提供します。クラウドを使用すれば、地理的分布を有効に活用し、他のロケーションの環境を数 分で複製します。 トラフィックのクラウドへの「オーバーフロー」：数回クリックし、効果的なロードバランシング戦略を使う だけで、余分なトラフィックをクラウドに送る、オーバーフロー防止型の完全なアプリケーションを作成でき ます。 ページ 3- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 Amazon Web Services クラウドについて理解するには Amazon Web Services (AWS) クラウドは、ウェブスケールのソリューションを展開する、極めて信頼性の高いス ケーラブルなインフラを提供します。このシステムは、最低限のサポートコストと管理コストで維持でき、御 社の構内またはデータセンターで、御社のインフラストラクチャから予想するよりもさらにフレキシブルに構 築が可能です。 AWS は、今日入手可能な各種のインフラストラクチャサービスを提供します。以下のダイアグラムでは、 AWS の用語を紹介しており、御社のアプリケーションが別の Amazon Web Services とどのように相互に関係し、 異なるサービスが互いに相互に関係する様子を理解するのに役立ちます。 Amazon Elastic Compute Cloud (Amazon EC2)1 は、クラウド内で規模を自在に変更可能なコンピュータ処理能力を 提供するウェブサービスです。オペレーティングシステム、アプリケーションソフトウェアおよび関連コンフ ィギュレーション設定を Amazon Machine Image (AMI)にバンドルできます。AMI を使用すれば、複数の仮想化 されたインスタンスを提供したり、シンプルなウェブサービスコールを使用して撤去し、容量の要件の変更に 合わせて容量を素早くスケールアップ/スケールダウンすることが可能です。On-Demand Instances（オンデマ ンドインスタンス、従量課金制）を購入すれば、時間単位でインスタンスの支払いを行います、また、 Reserved Instances（リザーブドインスタンス、イニシャル+従量課金制） は、1 回限りの低料金で、従量課金 制よりも低い利用率でインスタンスを実行できます。さらに、Spot Instances（スポットインスタンス）をご利 用いただくと、未使用の容量を入札し、さらにコストの削減を図ることが可能です。インスタンスは、1 ヶ所 または複数の地理的地域で起動できます。各地域には、複数の Availability Zones（アベイラビリティゾーン） があります。アベイラビリティゾーンは、他のゾ－ンからの影響を受けないように各々独立したロケーション であり、同一地域の他のアベイラビリティゾーンに対して利用は安価で、待ち時間の尐ないネットワーク接続 を提供します。 1 Amazon EC2 に関する詳細は、http://aws.amazon.com/ec2 をご覧ください。 ページ 4- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 Amazon SQS キュー Amazon RDS Amazon SNS トピック Amazon SimpleDB ドメイン 支払い: Amazon FPS/DevPay アプリケーション Auto Scaling Elastic LB Amazon Elastic MapReduce ジョブフロー Amazon S3 オブジェ クトとバ ケット Cloud Watch Amazon EC2 インスタンス （オンデマンド、リザー ブド、スポット） Amazon Virtual Private Cloud EBS ボリュ ーム Amazon Cloud Front スナップ ショット Amazon グローバル物理インフラストラクチャ（地理 的リージョン、利用可能ゾーン、エッジロケーション） 図 1: Amazon Web Services Elastic IP は、静的 IP アドレスを配分し、プログラム可能な状態でインスタンスに割り当てます。リソースの 利用、運用パフォーマンス、全体的なデマンドパターン（CPU の使用状況、ディスクの読み取りと書き込み、 ネットワークトラフィックなどのメトリックスを含む）を表示するには、Amazon CloudWatch2 を使用して Amazon EC2 インスタンスをモニターできます。Amazon CloudWatch が収集するメトリックに基づく特定の状況 で容量を自動的にスケーリングするには、自動スケーリング機能3を使用して自動スケーリンググループを作 成します。また、Elastic Load Balancing4 サービスを使用して弾力的なロードバランサーを構築することにより、 受信トラフィックを分散できます。Amazon Elastic Block Storage (EBS)5 ボリュームは、ネットワーク接続持続性 ストレージを Amazon EC2 インスタンスに提供します。EBS ボリュームのポイントインタイムに対応したスナ ップショットを作成し、Amazon Simple Storage Service (Amazon S3)に保管します6。 Amazon S3 は、耐性に優れた分散型データストアです。シンプルなウェブサービス インターフェースを使用す れば、標準的な HTTP 動詞を使用したウェブ上のどこでも、大量のデータをいつでもオブジェクトとしてバケ ット（コンテナ）に保管して取り出せます。オブジェクトのコピーは、Amazon CloudFront サービス（ウェブ 2 Amazon CloudWatch の詳細については、http://aws.amazon.com/cloudwatch/ をご覧ください。 3 自動スケーリング機能の詳細については、http://aws.amazon.com/auto-scaling をご覧ください。 4 Elastic Load Balancing 機能の詳細については、http://aws.amazon.com/elasticloadbalancing をご覧ください。 5 Elastic Block Store の詳細については、http://aws.amazon.com/ebs をご覧ください。 6 Amazon S3 の詳細については、http://aws.amazon.com/s3 をご覧ください。 ページ 5- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 上の静的またはストリーミングコンテンツ配信7サービス）を使用して配信リストを構築し、世界中の 14 のエ ッジロケーションで分散してキャッシュされます。Amazon SimpleDB8 は、複雑な運用なしにデータベースの中 核機能、つまり構築済みデータのリアルタイム検索と簡単なクエリを提供するウェブサービスです。お客様は データセットをドメインに組み込み、特定のドメインに保管されているすべてのデータに対してクエリを実行 することができます。ドメインは、属性-値ペアで記述した項目の集まりです。Amazon Relational Database Service9 (Amazon RDS) は、クラウドでリレーショナルデータベースのセットアップ、運用、スケーリングを行 う簡単な方法です。DB Instance を起動し、フル機能搭載の MySQL データベース にアクセスできます。バック アップ、パッチ管理などの通常のデータベース管理に悩むことはありません。 Amazon Simple Queue Service (Amazon SQS)10 は、コンピュータ間をメッセージが移動する間に、それらを保管 するための、信頼性の高い、拡張性のある、キューサービスを提供します。 Amazon Simple Notifications Service (Amazon SNS)11は、トピックを作成し、出版/購読プロトコルを使用して、 クラウドからアプリケーションまたは人に通知する簡単な方法を提供します。 Amazon Elastic MapReduce12 は、Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Simple Storage Service (Amazon S3)のウェブスケールのインフラストラクチャを実行するホストされた Hadoop フレームワークを提 供し、カスタマイズされた JobFlows が作成できます。JobFlow は、一連の MapReduce ステップです。 Amazon Virtual Private Cloud (Amazon VPC)13 では、コーポレートネットワークを AWS 内にあるプライベートク ラウドに拡張できます。Amazon VPC は、IPSec トンネルモードを使用して、データセンターにあるゲートウ ェイと AWS にあるゲートウェイ間のセキュアな接続を構築します。 Amazon Route53 は、可用性に優れた DNS サービスです。このサービスを使用すると、管理するすべてのドメ インに対して HostedZone を作成し、DNS レコードを管理できます。 AWS Identity and Access Management (IAM)14 を使用すると、一意のセキュリティ資格情報で複数のユーザーを 作成し、AWS アカウント内でそのユーザーごとにアクセス許可を管理できます。IAM は、ネイティブで AWS サービスに統合されています。IAM をサポートするサービス API はまったく変わっていません。IAM を使用す る際、AWS サービス API 上に構築された既存のアプリケーションとツールは引き続き動作します。 7 Amazon CloudFront の詳細については、http://aws.amazon.com/cloudfront をご覧ください。 8 Amazon SimpleDB の詳細については、http://aws.amazon.com/simpledb をご覧ください。 9 Amazon RDS の詳細については、http://aws.amazon.com/rds をご覧ください。 10 Amazon SQS の詳細については、http://aws.amazon.com/sqs をご覧ください。および 11 Amazon SNS の詳細については、http://aws.amazon.com/sns をご覧ください。 12 Amazon ElasticMapReduce の詳細については、http://aws.amazon.com/elasticmapreduce を参照してください。 13 Amazon Virtual Private Cloud の詳細につきましては、http://aws.amazon.com/vpc をご覧ください。 14 Amazon Identity and Access Management の詳細については、http://aws.amazon.com/iam をご覧ください。 ページ 6- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 AWS は、Amazon の支払いインフラストラクチャを活用した各種決済、請求サービスも提供します15。 すべての AWS インフラストラクチャサービスは、長期的なコミットメントや契約を必要としない、ユーティ リティスタイルの価格設定を提供します。たとえば、Amazon EC2 インスタンスの使用については時間単位で 支払い、Amazon S3 でのストレージとデータの移行については、ギガバイト単位で支払えます。これらのサー ビスの詳細と重量料金制の価格体系については、AWS のウェブサイトをご覧ください。 AWS クラウドを使用しても、ユーザーが慣れている以下の項目のフレキシビリティやコントロールが犠牲に なることはありません。 プログラミングモデル、言語、オペレーティングシステム（Windows, OpenSolaris または Linux のいず れかのフレーバー）をお好みで自由に利用できます。 ユーザー要件を最も満足させる AWS 製品を自由に選択できまいす。どのサービスも個別に、または組 み合わせて利用できます。 AWS はサイズ変更が可能なリソース（ストレージ、帯域、コンピューティング）を提供するため、で きるだけ大量にまたは尐量自由に利用し、利用した分だけ支払得ます。 これまで使用してきたシステムマネジメントツールを自由に使用し、データベースをクラウドに拡張 できます。 15 Amazon Flexible Payments Service の詳細については、http://aws.amazon.com/fps をご覧ください。Amazon DevPay につい ては、http://aws.amazon.com/devpay をご覧ください。 ページ 7- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 クラウドの概念 クラウドは、高度にスケーラブルなインターネットアーキテクチャ[13]を構築するというこれまでの概念を補 強しながら、アプリケーションの構築と配置方法を完全に変える新しい概念を導入します。従って、概念から 実践に移る際は、「すべて変更したのに、何も変わっていない」と感じることがあるかもしれません。クラウ ドは、いくつかのプロセス、パターン、プラクティス、基本方針を変え、これまでよりさらに重要となった従 来型のサービス指向 (SOA) のアーキテクチャの原理を補強します。この章では、こうした新しいクラウドの概 念と何度も繰り返される SOA の概念について説明します。 従来型のアプリケーションは、開発された当時、経済的でアーキテクチャ感覚であるという先入観で構築され ました。クラウドは、新しい基本方針をもたらしますが、ユーザーはこの方針を理解する必要があります。こ の点については、後述します。 スケーラブルなアーキテクチャの構築 スケーラブルなインフラストラクチャを活用するには、スケーラブルなアーキテクチャの構築が不可欠です。 クラウドは、概念上無制限のスケーラビリティを提供します。ただし、ユーザーのアーキテクチャがスケーラ ブルではない場合、AWS のスケーラビリティをすべて活用できるわけではありません。クラウドとユーザー のアーキテクチャは、協力して作動する必要があります。スケーラブルなインフラストラクチャを活かして、 クラウドを十分に活用するには、ユーザーのアーキテクチャでモノリシックコンポーネントとボトルネックを 識別し、オンデマンドプロビジョニング機能を活用できないエリアを特定し、アプリケーションをリファクタ リングします。 真にスケーラブルなアプリケーションの特性： リソースの増加がパフォーマンスの比例的な増加をもたらす スケーラブルなサービスにより、異質性の処理が可能 スケーラブルなサービスは、運用するうえで効率的 スケーラブルなサービスは、弾力性に富む スケーラブルなサービスは、成長するにつれて費用効率がさらに高くなります（谷数が増加するにつ れて、単位あたりコストが下がる） このように、ユーザーのアプリケーションの固有の部分とる事項があります。前述の特性を頭に置きながらア ーキテクチャを設計すると、アーキテクチャとインフラストラクチャの両方が一体となって、ユーザーが求め るスケーラビリティが達成されます。 ページ 8- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 弾力性に関する説明 以下のグラフは、需要を満たすためにアプリケーションをスケーリングする場合にクラウドアーキテクトが取 る異なるアプローチを示しています。 スケールアップ アプローチ：スケーラブルなアプリケーションアーキテクチャについて頭を痛めることなく、 大型のさらにパワフルなコンピュータに重点的に投資し、需要に対処します（垂直スケーリング）。このアプ ローチは、通常ある程度はうまくいきますが、莫大な投資が必要であり（ダイアグラムの「巨額の支出」を参 照）、または新しい大型コンピュータが導入される前に需要が需要量を超えることがあります（ダイアグラム の「あなたは顧客を失ったばかりです」を参照）。 従来型のスケールアウトアプローチ：水平にスケーリングするアーキテクチャを構築し、インフラストラクチ ャに尐額投資します。大半の企業や大型のウェブアプリケーションは、このパターンに従っており、アプリケ ーションコンポーネントを分配して、データベースを連合し、サービス指向のデザインを採用します。このア プローチは、多くの場合スケールアップアプローチよりもさらに効率的です。ただし、このアプローチでは、 定期的に需要を予測し、需要を満たすためにある程度まとまった量インフラストラクチャを導入する必要があ ります。このアプローチでは、多くの場合容量の超過（「キャッシュの焦げ付き」）や絶えず手動によるモニ タリングにつながります。さらに、アプリケーションがウィルス性の炎上の犠牲となる場合（スラッシュドッ ト効果と呼ばれます16）は、通常このアプローチはうまくいきません。 注：どちらのアプローチも初期立ち上げ費用がかかり、本来は受け身です。 16 http://en.wikipedia.org/wiki/Slashdot_effect ページ 9- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 インフラストラクチャコスト USD 過剰容量 過剰容量「機会費用」 「機会費用」 巨額の支出 巨額の支出 あなたは顧客を失 ったばかりです 予測需要 実際の需要 スケールアップアプローチ 従来型のスケールアウトア プローチ 自動化された弾力性 自動化された弾力性 + 拡張性 時間 t 図 2：自動化された弾力性 従来型のインフラストラクチャは、一般に数年間にわたりアプリケーションが使用するコンピューティングリ ソース量を予測する必要があります。過小評価を行うと、アプリケーションは予想外のトラフィックを処理す る馬力が足りず、顧客の不満足につながる可能性があります。過剰評価を行うと、余分なリソースに資金を無 駄遣いします。 クラウドアプローチのオンデマンド型の弾力性（自動弾力性）は、実際の需要に合わせてインフラストラクチ ャが密接に整合し（拡張、収縮するにつれて）、その結果、全体的な活用率が上昇し、コストが削減します。 弾力性は、クラウドの基本特性のひとつです。弾力性は、最小限の摩擦でコンピュータリソースを容易にスケ ールアップ/スケールダウンする能力です。弾力性は、究極的にクラウドの大半の利点を推進するということ を理解することが重要です。クラウドアーキテクトは、この概念を自分のものとし、クラウドの利点を最大限 に活用するために、アプリケーションアーキテクチャに採り入れます。 従来より、アプリケーションは、固定化された、融通の利かない、事前に設定されたインフラストラクチャに 構築されていました。企業は、毎日サーバーを設定し、インストールをする必要がまったくありませんでした。 その結果、大半のソフトウェアアーキテクチャは、ハードウェアの迅速な配置や削減に対処していません。新 規リソースを取得するためのプロビジョニング時間や先行投資が高すぎるため、ソフトウェアアーキテクトは、 ハードウェアの使用状況を最適化するにあたり、時間やリソースに決して投資を行いませんでした。アプリケ ページ 10- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 ーションを実行するハードウェアがあまり利用されていない場合でも、問題視されませんでした。新規リソー スを数分で構築するというアイデアは実現可能ではなかったため、アーキテクチャ内の「弾力性」という概念 は見過ごされていました。 クラウドでは、こうした考え方を変える必要があります。クラウドコンピューティングは、必要なリソースの 取得プロセスを単純かします。前もって発注したり、使用しないハードウェアをつなぎ止めて置く必要はあり ません。代わりに、クラウドアーキテクチャは、必要なリソースを数分前にリクエストするか、調達プロセス を自動化し、クラウドの広範なスケールと迅速な応答時間を十分に活用します。リソースが必要なくなった場 合、必要のないリソースや活用されていないリソースｗの解放する際に、同じ概念が適用されます。 ユーザーがこうした変化を受け入れられず、アプリケーションアーキテクチャで弾力性を実践できない場合、 クラウドの利点を完全に活用することはできないでしょう。クラウドアーキテクトは、創造的に考え、自社の アプリケーションで弾力性を実施する方法について考えます。たとえば、毎夜ビルドを実行し、毎日午前 2 時 に回帰テストとユニットテストを 2 時間実行するインフラストラクチャ（「QA/ビルドボックス」と呼ばれる） は、残りの時間はアイドル状態でした。現在、弾力性のあるインフラストラクチャで、ボックスで「活動中の」 ビルドを毎夜実行し、夜間の 2 時間分の料金を支払うだけで済みます。同様に、社内のトラブルチケッティン グ ウェブアプリケーションについて考えます。このアプリケーションは、1 日中需要を満たすために常にピ ーク容量（サーバー5 台 24x7x365）で実行されていました。現在は、トラフィックパターンに基づきオンデマ ンドで実行するように設定されています（5 台のサーバーが、午前 9 時から午後五時まで、2 台のサーバーが 午後五時から午前 9 時まで）。 インテリジェントな弾力性のあるクラウドアーキテクチャの設計、すなわち必要な時の時インフラストラクチ ャを実行するのは、それ自体が芸術です。弾力性は、アーキテクチャ上の設計要件の 1 つ、またはシステムの 属性です。ユーザーがすべき質問は、自社のアプリケーションアーキテクチャでどのコンポ－円とまたはレイ ヤーが弾力的になれるかということです。それでは、このコンポーネントを弾力的にするには何が必要です か？自社のシステムアーキテクチャ全体に弾力性を実践すると、どんな影響がありますか？ 次の章では、ユーザーのアプリケーションで弾力性を実践する特別なテクニックを紹介します。クラウドの利 点を効率的に活用するには、この考え方で設計することが大切です。 束縛を恐れない ユーザーのアプリケーションをクラウドに移行することにしたとき、また、システムの仕様をクラウドで実行 できるようにマップしようとするとき、クラウドには、御社の敶地にあるリソースが持つような正確な仕様が ないことに気づくでしょう。たとえば、「クラウドは、あるサーバーで X 量の RAM を提供しない」、または 「私のデータベースは、単一のインスタンスで取得できるよりももっと IOPS が必要です」などです。 クラウドは、観念的なリソース提供し、このリソースをオンデマンド プロビジョ人モデルと組み合わせると パワフルになります。クラウドリソースを使用するときは、恐れたり、束縛されることはありません。クラウ ド環境で御社のハードウェアとまったく同じ複製を得られなくても、その必要性を補うために、クラウドでさ らにリソースを取得する能力が御社にはあります。 ページ 11- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 たとえば、クラウドがサーバーで正確な量または大量の RAM を提供しなくても、memcached17 などの分散キ ャッシュを使用するか、複数のサーバー全体でデータを区切るようにします。データベースがさらに IOPS を 必要とし、クラウドの IOPS に直接マップしない場合、データのタイプや使用状況に応じて選択できるいくつ かの推奨事項があります。読み取りに重点を置くアプリケーションの場合、同期されたスレーブのフリート全 体に読み取り負荷を分散できます。代わりに、共有［10］アルゴリズムを使用して、必要な場所へデータを送 ったり、各種のデータベース クラスタリングソリューションを使用したりできます。 振り返ってみると、オンデマンドプロビジョニング機能をフレキシビリティと組み合わせると、表面上の束縛 が実際に崩壊し、スケーラビリティやシステムの全体的なパフォーマンスが構造します。 仮想管理 クラウドの出現により、システム管理者の役割が「仮想システム管理者」に変化しました。これは、管理者が アプリケーションについて知識を得、全体的に会社にとって最適なことを決断するにつれ、実施する日常的な タスクがさらに興味深いものになっています。システム管理者は、サーバーの設置やソフトウェアのインスト ールやネットワークデバイスの配線を行う必要はありません。こうした退屈な仕事は、数度のクリックとコマ ンドラインの呼び出しに取って代わられています。インフラストラクチャはプログラム可能なため、クラウド は自動化を促進します。システム管理者は、技術スタックをグレードアップし、スクリプトを使用して観念的 なクラウドリソースの管理法を学習する必要があります。 同様に、データベース管理者の役割も「仮想データ管理者」に変割りました。管理者は、ウェブベースのコン ソールを通じてリソースを管理し、データベースのハードウェアの容量が欠乏し足り、日常のプロセスを自動 化する場合に、容量を新たにプログラム可能なように追加するスクリプトを実行します。仮想 DBA は、現在 新導入メソッド（仮想マシンイメージ）を学び、新モデル（クエリの並行化、地理的な冗長性、非同期の複製） を採り入れ［11］、でーたのアーキテクト上のアプローチを再考し（［9］の共有、水平分割［13］、合体 ［14］）、別のタイプのデータセットに対してクラウドで使用可能な別のストレージオプションを活用します。 従来型の企業では、アプリケーション開発者はネットワーク管理者と密接に協力せず、ネットワーク管理者は アプリケーションのヒントを持ち合わせていません。その結果、ネットワークレイヤーとアプリケーションア ーキテクチャ レイヤーでの最適化の可能性が見逃されています。クラウドを使用すれば、2 つの役割がある程 度 1 つにまとまります。将来のアプリケーションを設計する際に、企業は 2 つの役割の間で知識の相互交流を 奨励し、これらの役割を統合できることを認識する必要があります。 17 http://www.danga.com/memcached/ ページ 12- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 クラウドのベストプラクティス この章では、クラウドにアプリケーションを構築するのに役立つベストプラクティスを紹介します。 故障のための設計と何も故障しないという確証 経験則：クラウドでアーキテクチャを設計するときは悲観論者になる。物事は失敗すると仮定する。言い換え ると、故障から自動的に回復するための設計、実践、導入を実行します。 特に、御社のハードウェアは故障すると仮定します。停電が生じると仮定します。災害が御社のアプリケーシ ョンを襲うと仮定します。1 秒あたりの予想リクエスト数を超えて多忙になると仮定します。時間が経つにつ れて、御社のソフトウェアは故障すると仮定します。悲観論者になることで、設計時に回復戦略について考え るようになり、全体的なシステムをさらにうまく設計するのに役立ちます。 物事は時間を経て失敗することを認識し、この考えをアーキテクチャに採り入れ、災害が襲い、スケーラブル なインフラストラクチャに対処する前に、故障を処理するメカニズムを構築すれば、しまいにはクラウドに対 して最適化された耐故障性のアーキテクチャを構築できます。 あなたが行うべき質問：システムのノードが故障したらどうなりますか？この故障をどのように認識します か？そのノードを交換するにはどうすればよいですか？どのようなシナリオを計画すべきですか？私の単一障 害点は何か？アプリケーションサーバーの前にロードバランサーがある場合、そのロードバランサーが故障し たらどうなりますか？アーキテクチャにマスターとスレーブがある場合、マスターノードが故障したらどうな りますか？フェールオーバーはどのようにして生じますか？また、新しいスレーブはどのようにインスタンス 化し、マスターと一緒に同期化されますか？ ハードウェアの故障のために設計するのと同じように、ソフトウェアの故障のために設計する必要があります。 あなたが行うべき質問：依存しているサービスがインターフェイスを変えると、当社のアプリケーションに何 が生じますか？ダウンストリームサービスがタイムアウトになるか、例外を返したらどうなりますか？キャッ シュキーがインスタンスのメモリー限度値を超えて成長したらどうなりますか？ この障害を処理するメカニズムを構築します。たとえば、障害が発生した場合は、次のような戦略が役立ち ます。 1. 首尾一貫したバックアップを作成し、データのストレージを復元し、自動化する 2. 起動を再開するプロセススレッドを構築する 3. クエリからメッセージを再ロードし、システムの状態を再同期にする 4. 起動/ブートで (2) と(3)をサポートするために、事前設定、事前最適化されたバーチャルイメージを維 持する 5. インメモリーセッションやステートフルなユーザーコンテキストを避け、データストアに移動する ページ 13- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 優れたクラウドアーキテクチャは、再ブートや再起動に影響されません。GrepTheWeb（『クラウドアーキテ クチャ白書』［6］で説明）では Amazon SQS と Amazon SimpleDB の組み合わせを使用することにより、コント ローラーアーキテクチャ全体が、この章で挙げている故障のタイプに対して弾性があります。たとえば、コン トローラスレッド上のインスタンスが活動していない場合、何事もなかったかのように以前の状態に戻します。 この状態は、事前設定された Amazon Machine Image を構築して達成されます。このツールは起動すると、 Amazon SQS キューからのすべてのメッセージのキューを解除し、リブート時に Amazon SimpleDB ドメインか らの状態を読み取ります。 基盤となるハードウェアが故障したという前提でデザインされているため、実際に故障したときの準備となり ます。 この設計方針は、Hamilton ［11］の論文でも強調されているように、操作がやさしいアプリケーションの設計 に役立ちます。この方針を事前対策やバランスボードのダイナミックな実践に拡大すれば、クラウドの複数テ ナントのために存在する、ネットワークとディスクのパフォーマンスの相違を処理することが可能となります。 このベストプラクティスを実行するための AWS 独自の戦略を以下に挙げます。 1. Elastic IP を用いるフェールオーバー： Elastic IP は、動的に再マップが可能な静的 IP です。 迅速に再マップし、別のサーバーセットにフェールオーバーして、トラフィックを新サー バーに遅れるようにします。旧バージョンから新バージョンにアップグレードする、また はハードウェアが故障した場合に、うまく作用します。 2. 複数の Availability Zones を活用する： Availability Zones は、論理上論理データセンターと似 ています。アーキテクチャを複数の Availability Zones に配置することにより、高可用性が 確保できます。Amazon RDS Multi-AZ [21] 導入機能を活用し、複数の Availability Zones 全体 でデータベースのアップデートを自動的に複製します。 3. Amazon Machine Image を維持し、異なる Availability Zones でクローン環境を極めて容易に 復元します。Availability Zones 全体で複数のデータベーススレーブを維持し、ホットな複製 を作成します。 4. Amazon CloudWatch （または各種のリアルタイムのオープンソース モニタリングツール） を活用してさらに可視性を高め、ハードウェアの故障やパフォーマンスの質の务化が生じ た場合に適切な手段を講じます。自動スケーリンググループを設定して、問題のある Amazon EC2 インスタンスを新しいものに取り替えられるように、固定されたフリートサイ ズを維持します。 5. Amazon EBS を利用して cron ジョブを設定し、インクリメンタルスナップショットが Amazon S3 に自動的にアップロードされ、データがユーザーのインスタンスから独立して 存在するようにします。 6. Amazon RDS を利用してバックアップの保存期間を設定し、自動バックアップが行えるよう にします。 ページ 14- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 コンポーネントの分離 クラウドは SOA の設計原則を強化します。システムのコンポーネントを疎結合にすればするほど、スケーリ ングが大規模にうまく行えます。 鍵となるのは、互いにしっかり依存し合わないコンポーネントを構築し、あるコンポーネントが何らかの理由 で故障、スリープ（反応しない）またはビジー（反応が遅い）状態になっても、システムの他のコンポーネン トが構築され、故障が生じてないかのように作業を継続します。基本的には、疎結合は各種のアプリケーショ ンのレイヤーやコンポーネントを隔離し、各コンポーネントが他のコンポーネントと非同期に相互作用し、 「ブラックボックス」として扱います。たとえば、ウェブアプリケーションアーキテクチャの場合、アプリケ ーションサーバーをウェブサーバーとデータベースから隔離できます。アプリケーションサーバーは、ユーザ ーのウェブサーバーについて知らず、またウェブサーバーは、アプリケーションサーバーについて知りません。 従って、コードワイズまたは機能的な観点からの依存関係はありません。バッチ処理アーキテクチャでは、互 いに独立している非同期コンポーネントを作成できます。 あなたが行うべき質問：ビジネスコンポーネントや機能は現在のモノリシックアプリケーションからいつ隔離 されますか？また、別にスタンドアロンで実行できますか？現在のシステムを壊さずに、このコンポーネント のインスタンスをさらに追加し、もっと多くのユーザーにサービスを提供するにはどうすればよいですか？コ ンポーネントが他のコンポーネントと非同期に相互作用するように、コンポーネントをカプセル化するにはど のぐらいの手間がかかりますか？ コンポーネントの分離、非同期システムの構築、水平にスケーリングを行うことは、クラウドの状況では非常 に重要です。同じコンポーネントのインスタンスをさらに追加してスケールアウトするだけではなく、革新的 なハイブリッドモデルを設計し、いくつかのコンポーネントが施設で実行され、他のコンポーネントはクラウ ドスケールを活用したり、計算能力や帯域を追加するためにクラウドを使用できます。最低限の取り組みで、 スマートなロードバランシング戦略を実行することにより、余分なトラフィックをクラウドに「オーバーフロ ー」できます。 疎結合のシステムは、メッセージングクエリを使用しても構築可能です。2 つのコンポーネントの結合にキュ ー/バッファが使用される場合、同時並行、高可用性、ロードスパイクをサポートすることができます。その 結果、コンポーネントの一部が一時的に使用できなくても、システム全体が実行を継続します。あるコンポー ネントが故障したか、一時的に使用できなくても、システムはメッセージをバッファーに保留し、コンポーネ ントがバックアップされたときに処理されます。 ページ 15- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス B 内のメソッドを A か C 内のメソッ ら呼び出す ドを B かす コントロ ーラ A コントロ ーラ B ； 2010 年 1 月 コントロ ーラ C 密結合（手続き型プログラミング） キュ ーB キュ ーA コントロ ーラ A キュ ーC コントロ ーラ B コントロ ーラ C 疎結合（キューを使用して各フェーズを独立させる） 図 3: キューを使用してコンポーネントを分離 Cloud Architectures ペーパー［6］で説明した GrepTheWeb Architecture でキューを多様しているのがわかります。 GrepTheWeb では、多数のリクエストが突然サーバーに到達すると（インターネット誘導のオーバーロード状 況）、または正規表現の処理に時間がかかると（コンポーネントの襲い応答率）、Amazon SQS キューは、遅 れが他のコンポーネントに影響を与えないような方法でリクエストをバッファに保留します。 このベストプラクティスを実践するための AWS 特有の戦略： 1. Amazon SQS を使用してコンポーネントを隔離する［18］。 2. Amazon SQS をコンポーネント間のバッファとして使用する［18］。 3. このように各コンポーネントを設計すると、サービスインターフェースが現れ、適切な 寸法でスケーラビリティに責任を負い、その他のコンポーネントと非同期で相互に作用し ます。 4. コンポーネントの論理的な構造を Amazon Machine Image にバンドルし、さらに頻繁に展 開できるようにします。 5. アプリケーションをできるだけステートレスにします。コンポーネント以外からセッシ ョンステートを保管（適切な場合、Amazon SimpleDB）。 ページ 16- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 弾力性の実践 クラウドは、アプリケーションに弾力性という新しい概念をもたらします。弾力性は、以下の３つの方法で実 践できます。 1. 事前の巡回スケーリング：一定間隔（毎日、週ごと、月ごと、四半期ごと）に発生する定期的なス ケーリング 2. 事前のイベントベーススケーリング：予定されているビジネスイベントのためにトラフィックリク エストが急激に増加されると予想されるときにスケーリング（新製品は票、マーケティングキャン ペーン） 3. オンデマンド自動スケーリング。モニタリングサービスを使用することにより、システムがトリガ ーを送信し、メトリックスに基づきスケールアップまたはダウンできるように適切な措置を講じま す（サービスまたはネットワーク I/O などの活用）。 「弾力性」を実践するには、まず導入プロセスを自動化して、コンフィギュレーションとビルドプロセスを簡 素化します。これにより、システムが人の介入を得ずにスケーリング可能となります。 その結果、ユーザーのリソースがあまり活用されていない潜在的に実行されるサーバーではなく、需要と密接 に関連しているために全体的な利用状況が増加し、費用対効果が直ちに現れます。 インフラストラクチャの自動化 クラウド環境を使用する最も重要な利点の 1 つに、クラウドの API を使用して展開プロセスを自動化できる機 能です。移行プロセスが終了してからではなく、初期の段階に時間をかけて自動化展開プロセスを構築するこ とを奨めます。自動化され、繰り返し可能な展開プロセスを構築すると、エラーを削減し、小売素敵でスケー ラブルなアップデートプロセスを活用できます。 展開プロセスを自動化するには： 「レシピ」という小型の頻繁に使用されるスクリプト（インストールとコンフィギュレーション用） を作成する AMI にバンドルされているエージェントを使用して、コンフィギュレーションと展開プロセスを管理 する インスタンスをブートストラップ インスタンスをブートストラップ インスタンスの起動時に「私は誰？私の役割は？」という質問をさせます。各インスタンスには、環境で演じ る役割があります（ウェブアプリケーションの場合は「DB サーバー」、「アプリケーションサーバー」、 「スレーブサーバー」）。この役割は、起動後にステップをインスタンス化する時期を AMI に指図する起動 時に引数として渡されます。起動時、インスタンスは、役割に基づいて必要なリソース（コード、スクリプト、 ページ 17- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 コンフィギュレーション）を取得し、クラスタに「添付」して機能を作動します。インスタンスをブートスト ラッピングする利点： 1. 数回のクリックと最低限の手間で（開発、ステージング、生産）環境を再現 2. 観念的なクラウドベースのリソースをさらにコントロール 3. 人が誘発する展開エラーを削減 4. ハードウェアの故障に対してさらに弾力性がある自己修復、自己発見環境を構築 インフラストラクチャを自動化する AWS 固有の戦略 1. Amazon EC2 で Amazon Auto-scaling の機能を利用して、異なるクラスタに自動スケーリンググ ループを定義します。 2. Amazon CloudWatch を利用してシステムメトリックス（CPU、メモリー、ディスク、I/O、ネ ットワーク I/O）をモニターし、適切な措置を講じるか（自動スケーリングサービスを使用し て、新 AMI をダイナミックに起動）、または通知を送信します。 3. マシンのコンフィギュレーション情報をダイナミックに保管、取り込みます。Amazon SimpleDB を利用し、インスタンスの起動時間中にデータを取り込みます（例、データベース 接続ストリング）。SimpleDB は、IP アドレス、マシン名、役割などのインスタンス情報の保 管にも使用されます。 4. ビルドプロセスをこのように設計すると、最新のビルドを Amazon S3 のバケットにダンプし ます。システムの起動中に最新版のアプリケーションをダウンロードします。 5. リソースマネジメントツール（自動化スクリプト、事前設定イメージ）の構築に投資する、 または Chef18、Puppet19、CFEngine 20または Genome21 などのスマートオープンソースのコンフ ィギュレーションマネジメントツールを使用します。 6. Just Enough Operating System (JeOS22) とユーザーのソフトウェア依存性を Amazon Machine Image にバンドルして管理と維持をしやすくします。起動時にコンフィギュレーションファ イルまたはパラメータをパスし、起動後はユーザーデータ23とインスタンスメタデータを検索 します。 18 Chef の詳細については、http://wiki.opscode.com/display/chef/Home をご覧ください。 19 Puppet の詳細については、http://reductivelabs.com/trac/puppet/ をご覧ください。 20 CFEngine の詳細については、http://www.cfengine.org/ をご覧ください。 21 Genome の詳細については、http://genome.et.redhat.com/ をご覧ください。 22 http://en.wikipedia.org/wiki/Just_enough_operating_system 23 インスタンスメタデータとユーザーデータの情報は、 http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?AESDG-chapter-instancedata.html をご覧ください。 ページ 18- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 7. バンドリングと起動時間を削減するには、Amazon EBS ボリューム24 から起動し、複数の Amazon EBS ボリュームをインスタンスに接続します。共通ボリュームのスナップショットを 作成し、スナップショットを25適切なアカウント間で共有します。 8. アプリケーションコンポーネントまたはアプリケーションが実行されている場所は、正常と 仮定すべきではありません。たとえば、新ノードの IP アドレスをクラスタにダイナミックに 接続します。故障の場合は、自動的にフェールオーバーし、新たにクローン化が開始されミ ズ宇。 並行して考える クラウドは、並列化を簡単に行えます。クラウドアーキテクトとして、ユーザーがクラウドからデータ、クラ ウドへデータ、クラウドでデータ処理（またはジョブの実行）を要求するかどうかにかかわらず、クラウドで アーキテクチャを設計する場合は、並列化の概念を採り入れる必要があります。クラウドは、極めて容易に繰 り返し可能なプロセスを構築できるため、可能な場所で並列化を実践するだけではなく、自動化することを奨 めます。 データにアクセス（検索し保管）するようになると、クラウドは並列オペレーション w の大量に処理します。 最大のパフォーマンスとスループットを達成するには、並列化のリクエストを活用します。複数の並列なスレ ッドを使用してリクエストをマルチスレッドすると、連続的にデータをリクエストするより速く、データを保 管または取り出せます。従って、可能な限り、クラウドアプリケーションのプロセスは、何も共有しない方針 でスレッドセーフにし、マルチスレッドを活用するようにします。 クラウドでリクエストを処理、実行するようになると、並列化の活用はさらに重要になります。ウェブアプリ ケーションの場合の一般的なベストプラクティスは、ロードバランサーを使用して、複数の非同期のウェブサ ーバー全体で受信リクエストを分散させます。バッチ処理アプリケーションの場合は、並列でタスクを処理す る複数のスレーブワーカーノードを作成することができます（Hadoop26 などの分散処理フレームワークのよ うに）。 弾力性と並列化を組み合わせると、クラウドの美しさが引き立ちます。クラウドアプリケーションは、API を 数回呼び出すだけで、数分で設定されたコンピュートインスタンスのクラスタを構築し、並列でタスクを実行 してジョブを処理し、結果を保管してから、すべてのインスタンスを終了させます。［6］で説明する GrepTheWeb アプリケーションは、その一例です。 24 Amazon EBS からの起動の機能の詳細については、 http://developer.amazonwebservices.com/connect/entry.jspa?externalID=3121 をご覧ください。 25 スナップシェアの共有方法については、http://aws.amazon.com/ebs/ をご覧ください。 26 http://hadoop.apache.org/ ページ 19- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 AWS 独自の並列化戦略： 1. ベストプラクティスペーパーで説明しているように、Amazon S3 リクエストをマルチスレッ ド化する 2。 2. Amazon SimpleDB GET と BATCHPUT のリクエストをマルチスレッド化する［3］［4］［5］。 3. 毎日のバッチ処理に対し、Amazon Elastic MapReduce Service を使って JobFlow を作成する （インデックスか、ログ分析など）ジョブを並列に処理し、時間を節約します。 4. Elastic Load Balancing サービスを利用し、複数ウェブアプリケーションサービス全体でダイナ ミックに負荷を拡散する。 動的データをコンピュータの近くに、静的データをエンドユーザーの近くに保管する 一般に、待ち時間を減らすには、データを計算または処理要素のできるだけ近くに保管すると良いでしょう。 クラウドでは、この場合のベストプラクティスは、インターネットの呼び出し時間に対処する必要があるため、 さらに関連深く、重要となります。さらに、クラウドでは、ギガバイトのデータ移転にクラウドの内外から帯 域に対して支払いっており、コストがすぐにかさみます。 クラウド外にある大量のデータを処理する必要がある場合は、データをまずクラウドに「出荷」して移転し、 次に計算を実行します。たとえば、データウェアハウスアプリケーションの場合、データセットをクラウドに 移行し、次にデータセットにたいして並列クエリを実行することを奨めます。リレーショナルデータベースか らデータを保管、検索するウェブアプリケーションの場合は、データベースとアプリケーションサーバーをク ラウドに一度に移行することを奨めます。 クラウドでデータが生成されると、データを消費するアプリケーションもクラウドに展開され、クラウド内で の無料データ移転を活用して待ち時間を短縮します。たとえば、ログとクリックストリームデータを生成する E コマースウェブアプリケーションの場合、クラウドでログアナライザとレポートエンジンを実行することを 奨めます。 逆に、データが静的でそれほど頻繁に変更されない場合（たとえば、画像、ビデオ、オーディオ、PDF、JS CSS ファイル）、コンテンツデリバリーサービスを利用して、静的データをエンドユーザー（依頼者）に近い エッジロケーションにキャッシュし、アクセスの待ち時間を短縮します。キャッシングのおかげで、コンテン ツデリバリーサービスは、ポピュラーなオブジェクトに素早くアクセスできます。 このベストプラクティスを実践するための AWS 独自の戦略： 1. Import Export Services を利用して、データドライブを Amazon に移転します27。大量のデータを 移行するには、インターネットでアップロードするより、スニーカーネット28を使用する方が 速く、コストもかかりません。 2. 同一の Availability Zone を利用してマシンの集団を起動します。 3. Amazon S3 バケットの分散を作成し、Amazon CloudFront に、全世界の 14 のエッジロケーショ ン全体にバケットのコンテンツをキャッシュさせます。 27 Import Export Services の詳細については、http://aws.amazon.com/importexport をご覧ください。 28 http://en.wikipedia.org/wiki/Sneakernet ページ 20- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 セキュリティのベストプラクティス マルチテナント環境では、クラウドアーキテクトは、しばしばセキュリティの懸念を表明します。セキュリテ ィは、クラウドアプリケーションアーキテクチャのどのレイヤーでも実践すべきです。物理的なセキュリティ は、通常サービスプロバイダが処理しており（セキュリティホワイトペーパー［7］）、これは、クラウドを 使用する上でのメリットです。ネットワークとアプリケーションレベルのセキュリティは、ユーザーの責任で あり、御社で適用されるベストプラクティスを実践します。この章では、AWS 環境でクラウドアプリケーシ ョンの安全を確保するための特殊なツール、機能、ガイドラインについて説明します。基本セキュリティを実 施するためのツールや機能を利用し、さらに、適切なまたは適当と思われる標準的な方法を使用して、セキュ リティのベストプラクティスを実践することを奨めます。 移行中のデータを保護 ブラウザとウェブサーバー間で秘密情報を交換する場合は、サーバーインスタンスに SSL を設定します。 VeriSign29 または Entrust30 などの外部認証機関からの認証を必要とします。認証に含まれるパブリックキーは、 サーバーをブラウザに認証し、両方向のデータの暗号化に使用される共有セッションキーを作成する基盤とし て働きます。 いくつかのコマンドライン呼び出しを作成して Virtual Private Cloud を構築（Amazon VPC の使用法） これを使 うと、AWS クラウド内で独自に隔離されたリソースを使用し、そのリソースを業界標準の暗号化された IPsec VPN 接続を使用して既存の企業システムに直接接続することができます。 Amazon EC2 インスタンスで OpenVPN サーバーをセットアップし［15］、すべての湯ユーザーPC で OpenVPN クライアントをインストールします。 休眠データを保護 クラウドに機密データを保管することに懸念を抱いている場合は、クラウドにアップロードする前にデータ （個別ファイル）を暗号化すべきです。たとえば、データを Amazon S3 のオブジェクトとして保管する前にオ ープンソース31 または商業用の32 PGP ベースツールを使用してデータを暗号化し、ダウンロード後に暗号を 解除します。この方法は、Protected Health Information (PHI) を保管する必要がある HIPPA 対応のアプリケーシ ョン［8］を構築する際には、優れたプラクティスとなります。 Amazon EC2 では、ファイルの暗号化はオペレーティングシステムにより異なります。Windows を実行してい る Amazon EC2 インスタンスは、ビルトイン方式の Encrypting File System (EFS)機能 [16]を使用できます。この機 能は、ファイルとフォルダの暗号化と暗号解除を自動的に処理し、ユーザーに対してトランスペアレントにプ ロセスを処理します [19]。ただし、この名称にもかかわらず、EFS はファイルシステム全体を暗号化するわけ 29 http://www.verisign.com/ssl/ 30 http://www.entrust.net/ssl-products.htm 31 http://www.gnupg.org 32 http://www.pgp.com/ ページ 21- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 ではなく、個別のファイルを暗号化します33。ファイルシステム全体を暗号化するには、オープンソースの TrueCrypt 製品の使用を検討してください。この製品は、NTFS 形式の EBS ボリュームを非常にうまく統合し ます。Linux を実行する Amazon EC2 インスタンスは、各種アプローチ (EncFS34、Loop-AES35、dm-crypt36、 TrueCrypt37)を備えた暗号化されたファイルシステムを使用しながら、EBS ボリュームを装着できます。同様に、 OpenSolaris を実行する EC2 インスタンスは、ZFS38 暗号化サポート 20 を利用できます。どの方法を選んでも、 Amazon EC2 の暗号化するファイルとボリュームは、ファイルとログデータを保護し、ユーザーとサーバー上 のプロセスのみがクリアテキスト形式でデータを参照できますが、サーバー以外にいる人は、暗号化されたデ ータのみを参照できます。 どのオペレーティングシステムやテクノロジーを選んでも、休眠中のデータの暗号化は問題を生じます。デー タの暗号化に使用するキーを管理します。キーをなくしたら、データも永遠に失われ、キーが破損したら、デ ータも危険な状態になります。従って、選んだ製品のキー管理機能について研究し、キーをなくすリスクを最 小限に抑える手順を確立します。 データを盗聴から守る他に、災害から守る方法も考慮します。Amazon EBS ボリュームのスナップショットを 定期的に取り、高度な耐性と可用性を確保します。スナップショットは、本来インクリメンタルであり、 Amazon S3 に保管され（別の地理上のロケーション）、数回クリックするかコマンドライン呼び出しを行うだ けで、復元されます。 AWS 資格情報の保護 AWS は、AWS アクセスキーと X.509 認証の 2 種類のセキュリティ資格情報を提供します。AWS アクセスキー は、キーID とシークレットアクセスキーの 2 つの部分に分かれます。REST または Query API を使用する場合、 シークレットアクセスキーを使用して、認証リクエストに含める署名を計算します。転送中の変更を回避する には、すべてのリクエストを HTTPS 上で送信します。 Amazon Machine Image (AMI) が他の AWS ウェブサービスとコミュニケーションが必要な場合（たとえば、 Amazon SQS キューをポーリングするため、Amazon S3 からオブジェクトを読み取るため）、1 つの設計ミスが AMI での AWS 資格情報を巻き込みます。資格情報を埋め込まずに、起動時に引数として渡し、送信前に暗号 化します［17］。 シークレットアクセスキーが破損した場合、新しいアクセスキーID に循環し39、新しいキーを取得します。優 れたプラクティスとしては、キーローテーションメカニズムをアプリケーションアーキテクチャに統合して定 33 http://www.truecrypt.org/ 34 http://www.arg0.net/encfs 35 http://loop-aes.sourceforge.net/loop-AES.README 36 http://www.saout.de/misc/dm-crypt/ 37 http://www.truecrypt.org/ 38 http://www.opensolaris.org/os/community/zfs/ 39 http://aws.amazon.com/about-aws/whats-new/2009/08/31/seamlessly-rotate-your-access-credentials/ ページ 22- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 期的にまたはときどき使用できるようにし（不満を持った従業員が退職するときに）破損したキーが永遠に残 らないようにします。 代わりに、X.509 認証を特定の AWS サービスに使用して認証を行います。認証ファイルには、base64-encoded DER 認証機関のパブリックキーが含まれています。別のファイルには、対応する base64-encoded PKCS#8 プラ イベートキーが含まれます。 AWS は、マルチファクター認証40 をサポートし、aws.amazon.com と AWS Management Console41 上のアカウン ト情報で作業する際に保護します。 IAM での複数ユーザーとそのアクセス許可の管理 AWS Identity and Access Management (IAM)42 を使用すると、複数のユーザーを作成し、AWS アカウント内でそ のユーザーごとにアクセス許可を管理できます。ユーザーは、AWS サービスへのアクセスに使われる独特な セキュリティ証明書を持つ（AWS アカウント内の）アイデンティティです。IAM で、パスワードやアクセ スキー共有の必要性が排除され、必要に応じてユーザーのアクセスを簡単に有効または無効にすることがで きます。 IAM を使用すると、「最小権限」などのセキュリティのベストプラクティスを実装できます。この最小権限で は、AWS アカウント内のすべてのユーザーに独自の資格情報を割り当てて、ユーザーがジョブを実行するの に必要な AWS サービスおよびリソースのみへのアクセスを許可します。IAM はデフォルトで安全です。新し いユーザーは、アクセス許可が明示的に付与されるまで、AWS へアクセスすることはできません。 IAM は、ネイティブでほとんどの AWS サービスに統合されています。IAM をサポートするサービス API はまっ たく変わっていません。IAM を使用する際、AWS サービス API 上に構築されたアプリケーションとツールは引 き続き動作します。アプリケーションは、新しいユーザー用に生成されたアクセスキーを使用して開始する必 要があるだけです。 AWS サービスを操作し、IAM ユーザーの資格情報を利用して AWS サービスおよびリソースにアクセスすると きは、AWS アカウントの資格情報をできるだけ最小限に抑える必要があります。 アプリケーションの安全性を確保 Amazon EC2 は、１つまたは複数のセキュリティグループ 43で保護され、どのインスタンスに配信する受信ネ ットワークトラフィックを指定するルールがあります。TCP と UDP ポート、ICMP タイプとコード、ソースア ドレスを指定できます。セキュリティグループは、実行中のインスタンスに対して、基本的なファイアウォー 40 マルチファクター認証の詳細については、http://aws.amazon.com/mfa/ をご覧ください。 41 AWS Management Console http://aws.amazon.com/console/ 42 詳細については、http://aws.amazon.com.com/iam をご覧ください 43 セキュリティグループの詳細については、http://docs.amazonwebservices.com/AWSEC2/2009-07- 15/UserGuide/index.html?using-network-security.html をご覧ください。 ページ 23- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 ルのような保護を提供します。たとえば、ウェブアプリケーションに属するインスタンスは、以下のセキュリ ティグループ設定を備えています。 図 4: EC2 Security Groups を使用してウェブアプリケーションのセキュリティを確保 受信トラフィックを制限する別の方法は、インスタンスにソフトウェアベースのファイアウォールを設定する ことです44。Windows のインスタンスは、ビルトイン方式のファアウォールを使用できます。Linux のインスタ ンスは、netfilter45 も iptables も使用できません。 ソフトウェアのエラーは、次第に、発見されるとパッチを当てることが必要となっています。アプリケーショ ンのセキュリティを最大化するには、以下の基本ガイドラインを確実に順守してください。 ベンダーのウェブサイトからパッチを定期的にダウンロードし、AMI をアップデートします。 新 AMI からインスタンスを再度配置し、アプリケーションをテストしてパッチにより何も破壊されて いないことを確認します。最新の AMI がすべてのインスタンスに配置されていることを確認します。 44 http://technet.microsoft.com/en-us/library/cc779199(WS.10).aspx, March 2003 45 http://www.netfilter.org/ ページ 24- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 テストスクリプトに投資して、セキュリティチェックを定期的に実行し、プロセスを自動化します。 サードパーティソフトウェアが最もセキュアな設定に構成されていることを確認します。 絶対に必要な場合以外は、プロセスを root または管理者ログインとして実行しないでください。 クラウド時代以前のすべての標準セキュリティプラクティス、たとえば、優れたコード化プラクティスや、機 密データの隔離は、依然として適用可能で、実践すべきです。 振り返ってみると、クラウドは物理的セキュリティの複雑さをユーザーから取り除き、ユーザーがアプリケー ションのセキュリティを確保できるように、ツールと機能を通じてコントロールします。 ページ 25- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 今後の調査の方向性 アプリケーションが物理的ハードウェアの認識を止める日は、そう遠くありません。マイクロウェーブのプラ グインに電気の知識が必要ないように、アプリケーションの実行に必要な電源を取得するために、だれでも、 ユーティリティプログラムのように、アプリケーションをクラウドにプラグインすることができます。アーキ テクトは、物理的なサーバーではなく、抽象的なコンピュート、ストレージ、ネットワークのリソースを管理 するようになります。アプリケーションは、基盤となる物理的なハードウェアが故障した、取り外された、ま たは交換されても、機能し続けます。アプリケーションは、リソースを瞬時にかつ自動的に配置し、常に最高 レベルの利用状況を達成することにより、変動する需要パターンに自ら適応します。スケーラビリティ、セキ ュリティ、高可用性、耐故障性、テスト可能性、弾力性は、アプリケーションアーキテクチャの構成可能なプ ロパティであり、構築されるプラットフォームの自動化される、または本質的な部分です。 ただし、私達はまだそこまでたどり着いていません。今日、本書で説明したベストプラクティスを実践するこ とにより、これらのいくつかを用いてクラウドでアプリケーションを構築することが可能です。クラウドコン ピューティングアーキテクチャのベストプラクティスは、進化し続け、私達は、研究者としてクラウドの強化 だけではなく、開発者の仕事を楽にするツール、テクノロジー、プロセスや、クラウドにアプリケーションを 容易にプラグインするアーキテクトについても重点的に研究すべきです。 結果 本書は、効率的なクラウドアプリケーションを設計するクラウドアーキテクトに対する規範的なガイドライン を提供します。 故障に備えた設計、アプリケーションコンポーネントの分離、弾力性についての認識と実践、弾力性と並列化 の組み合わせ、アプリケーションアーキテクチャのあらゆる面でセキュリティの統合などの概念とベストプラ クティスについて集中的に説明することにより、クラウドアーキテクトは、高スケーラブルなクラウドアプリ ケーションの設計に必要な設計上の考察について理解を深めることが可能です。 AWS クラウドは、非常に信頼性の高い従量料金制のインフラストラクチャサービスを提供します。本書で説 明した AWS 独自の戦略は、これらのサービスを使用したクラウドアプリケーションの設計に役立ちます。こ うしたコマーシャルサービスを利用し、他の人の仕事から学び、クラウドコンピューティングを構築し、進化 させ、さらに発明することを研究者の一人としてユーザーに勧めます。 謝辞 筆者は、本書の初期の草案に対して意見してくれた Jeff Barr, Steve Riley, Paul Horvath, Prashant Sridharan および Scot Marvin に深く謝意を表したい。貴重な見識を示してくれた Matt Tavis には、特に謝意を表したい。彼の助 力がなかったら、本書はこの世に出ていなかったかもしれない。 本書のコンテンツの一部は、著者の書籍『Cloud Computing: Paradigms and Patterns 』（Copyright © 2010 John Wiley & Sons, Inc.）から引 用した。 ページ 26- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 参考文献 1. Amazon S3 Team, Best Practices for using Amazon S3, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1904, 2008-11-26 2. Amazon S3 Team, Amazon S3 Error Best Practices, http://docs.amazonwebservices.com/AmazonS3/latest/index.html?ErrorBestPractices.html, 2006-03-01 3. Amazon SimpleDB Team, Query 201: Tips and Tricks for Amazon SimpleDB Query, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1232&categoryID=176, 2008-02-07 4. Amazon SimpleDB Team, Building for Performance and Reliability with Amazon SimpleDB, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1394&categoryID=176, 2008-04-11 5. Amazon SimpleDB Team, Query 101: Building Amazon SimpleDB Queries, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1231&categoryID=176, 2008-02-07 6. J. Varia, Cloud Architectures, http://jineshvaria.s3.amazonaws.com/public/cloudarchitectures-varia.pdf, 2007-07-01 7. Amazon Security Team, Overview of Security Processes, http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf, 2009-06-01 8. Amazon Web Services Team, Creating HIPPA-Compliant Medical Data Applications With AWS, http://awsmedia.s3.amazonaws.com/AWS_HIPAA_Whitepaper_Final.pdf, 2009-04-01 9. D. Obasanjo, Building Scalable Databases: Pros and Cons of Various Database Sharding Schemes, http://www.25hoursaday.com/weblog/2009/01/16/BuildingScalableDatabasesProsAndConsOfVariousDatabaseShardingSch emes.aspx, 2009-01-16 10. D. Pritchett, Shard Lessons, http://www.addsimplicity.com/adding_simplicity_an_engi/2008/08/shard-lessons.html, 2008-08-24 11. J. Hamilton, On Designing and Deploying Internet-Scale Services, 2007, 21st Large Installation System Administration conference (LISA ‘O7), http://mvdirona.com/jrh/talksAndPapers/JamesRH_Lisa.pdf 12. J. Dean and S. Ghemawat, MapReduce: Simplified data processing on large clusters2004-12-01, In Proc. of the 6th OSDI, http://labs.google.com/papers/mapreduce-osdi04.pdf 13. T. Schlossnagle, Scalable Internet Architectures, Sams Publishing , 2006-07-31, 14. M. Lurie, The Federation: Database Interoperability, http://www.ibm.com/developerworks/data/library/techarticle/0304lurie/0304lurie.html, 2003-04-23 15. E. Hammond, Escaping Restrictive/Untrusted Networks with OpenVPN on EC2, http://alestic.com/2009/05/openvpn-ec2, 2009-05-02 16. R. Bragg, The Encrypting File System, http://technet.microsoft.com/en-us/library/cc700811.aspx, 2009 17. S. Swidler, How to keep your AWS credentials on an EC2 instance securely, http://clouddevelopertips.blogspot.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html, 2009-08-31 18. Amazon SQS Team, Building Scalable, Reliable Amazon EC2 Applications with Amazon SQS, http://sqs-publicimages.s3.amazonaws.com/Building_Scalabale_EC2_applications_with_SQS2.pdf, 2008 19. Microsoft Support Team, Best Practices For Encrypting File System (Windows), http://support.microsoft.com/kb/223316, 2009 20. Solaris Security Team, ZFS Encryption Project (OpenSolaris), http://www.opensolaris.org/os/project/zfs-crypto/, 2009-05-01 ページ 27- 28 Amazon Web Services - クラウドコンピューティングのアーキテクチャ：ベストプラクティス 2010 年 1 月 21. Amazon RDS Team, Amazon RDS Multi-AZ Deployments, http://docs.amazonwebservices.com/AmazonRDS/latest/DeveloperGuide/Concepts.DBInstance.html#Concepts.MultiAZ. 2010-05-15 22. Amazon SimpleDB Team, Amazon SimpleDB Consistency Enhancements http://developer.amazonwebservices.com/connect/entry.jspa?externalID=3572 2010-02-24 ページ 28- 28