AWSクラウドサービスデザインパターン(1)

機械学習技術人工知能技術デジタルトランスフォーメーション技 ICTインフラ技術クラウド技術本ブログのナビ

AWSクラウドサービスデザインパターン(1)

Amazon Web Serviceクラウドデザインパターン設計ガイドより。

クラウドコンピューティングが普及するにつれて、コンピューターリソースの調達と運用に大きな変化が起こっている。クラウドにより、必要なときに必要なだけ、多岐にわたるITリソースを、安価かつ瞬時に調達することが可能となり、ITの新しい世界の幕開けとなった。

特に、2006年からクラウドサービスを提供しているAmazon Web Service(以下AWS)の進化は目覚ましく、仮想サーバー、ストレージ、ロードバランサー、データベース、分散キュー、NoSQLサービスなどの多種にわたるインフラストラクチャサービスを、初期費用の無い安価な従量課金モデルで提供している。利用者は、これらの非常にスケーラビリティの高いサービスを、必要な時に必要なだけ瞬時に調達して利用でき、また、必要なくなったときは、すぐに廃棄でき、その瞬間から利用料はかからなくなる。

これらのクラウドサービスにはすべてAPIが備わり公開されているので、Web上のツールからコントールできるだけでなく、ユーザーはプログラマブルにインフラストラクチャをコントロールできる。もはやインフラストラクチャは物理的に硬くて融通の効かないものではなく、非常に柔軟で変更ができるソフトウェア的なものになったといえる。

このようなインフラストラクチャを使いこなせば、これまでの常識では考えられないほど素早く安価に、耐久性が高くスケーラビリティがあり柔軟性の高いシステムやアプリケーションを構築できるようになる。こうした「インターネット時代の新しいサービスコンポーネント(=クラウド)」が用意された時代においては、システムのアーキテクチャ設計に携わる人には、新しい心構え、新しい発想、新しい標準が必要となる。つまり、新しいITの世界は、クラウド時代の新しいノウハウを身につけたアーキテクトを欲している。

日本にも2011年3月にAWSのデータセンター群が開設され、すでに数千の企業やディベロッパーが、AWSを活用してシステム作りをしている。顧客は、趣味でインフラを用いる個人のディベロッパーから、新しいビジネスを素早く立ち上げるスタートアップ、コスト削減の波にクラウドで抗おうとする中小企業、クラウドのメリットを見逃せない大企業、そして官公庁や自治体、教育機関に至るまで非常に幅広い。

クラウドを利用するユースケースとしても、典型的なWebサイト・Webアプリケーションのクラウドホスティングから、既存の社内ITインフラの置き換え、バッチ処理、ビッグデータ処理や化学計算、それから、バックアップやディザスターリカバリーまであり、汎用的なインフラとして利用されている。

クラウドの特徴を活かすことで、これまで考えられなかったようなビジネスやアプリケーションを実現し、新規事業、新規ビジネス、新規サービスとして成功を収めた例や、既存システムを移行してTCOを削減した例もすでに存在している。

しかしながら、クラウドを使おうとして挫けてしまった例はいまだに耳にするし、クラウドを最大限に活用したアーキテクティングを実施できているのは残念ながらいまだ多く無い、というのが現状となる。特にクラウド特有のメリットを活かした設計、例えばスケーラビリティ(Scalability)を活かすための設計や、システム全体で耐障害性を高める設計(Design for Failure)、コストメリットを考慮した設計などが十分にできているケースは未だ少ない。

ここではそれらのクラウドを用いた新しいアーキテクティングのパターンを整理したもの、Cloud Design Pattern(CDP)について述べる。

CDPは、クラウドを利用したシステムのアーキテクチャ設計時に起こる、典型的な問題とそれに対する解決策を、その本質を抽象化して再利用できるように整理・分類したものとなり、これまでアーキテクトが発見してきた、もしくは編み出してきた設計・運用のノウハウを、再利用が可能なデザインパターンという形式で、暗黙知から形式知に変換したものといえる。

CDPを用いることで、下記が可能となる。

既存ノウハウを活かすことで、クラウドを用いたシステムのより良いアーキテクチャ設計が可能となる。
アーキテクト同士で共通の言葉を使って会話できるようになる。
クラウドがより理解しやすくなる。

以下にCDPのパターンのうち、今回は「基本パターン」「可用性向上パターン」「動的コンテンツの処理パターン」「静的コンテンツの処理パターン」について述べる。次回は「データアップロードのパターン」「リレーショナルデータベースのパターン」「非同期処理/バッチ処理のパターン」について述べる。

基本パターン

Snapshot :クラウドの安全で容量制限がない「インターネットストレージ」を利用したある瞬間のデータを複製したバックアップ(スナップショット)を使ったデータのバックアップ

Stamp: 仮想サーバーに必要なOSやアプリケーションの設定を導入した状態のマシンイメージを作成して、コピーして再利用できるようにする。

Scale up: 稼働後にサーバーリソースが不足したときに、クラウド上で仮想サーバーのスペック(CPU、メモリサイズ等)を切り替える。

Scale out: Webサービスにおいて高トラフィックのリクエストを処理するためには、高スペックのマシンを使って処理能力を高める「スケールアップ」のアプローチがあるが、この手法は高コストとなるため、同じようなスペックのサーバーを複数台並べて、高トラフィックのリスエストを処理する「スケールアウト」アプローチを、複数の仮想サーバーとロードバランサーを用いた負荷分散により実現する。

Ondemand Disk: 仮想ディスクを用いて、好きなタイミングで必要なだけの容量を確保することで、システムで利用するディスク容量を利用量を見ながらオンデマンドに確保する。

可用性向上パターン

Multi-Server: システムの可用性(システムが継続して稼働できる能力)を上げるために、仮想サーバーを複数台並べ、ロードバランサを用いてて負荷を振り分ける。

MultiDatacenter: サーバー障害を想定した時の可用性向上にはMulti-Serveパターンが適しているが、データセンターレベル(例えば停電や地震、ネットワーク障害)の障害を想定すると、Nulti-Serverパターンでは対処できず、複数のデータセンターを高速な専用線で結んだ分散システムを用いる。

Floating IP: サーバーにパッチを当てたり、(処理能力を上げるために)サーバーをアップグレードしたりする場合に、サーバーの停止が必要となる。サーバーの停止はそのままサービスの停止となるので、停止時間をなるべく少なくて済むように、サーバーの停止に備えた予備のサーバーを立ち上げてサービスの代行をするようにする。

Deep Health Check: クラウドのロードバランサーやDNSが持つヘルスチェック機能を用いて、PHPやJavascriptなどの動的なページ(つまりプログラム)をチェックするように設定し、そのプログラムで、Proxyサーバーや、APサーバー、DBサーバーなどの動作をチェックして、その結果をロードバランサやDNSに返すことで、システム全体の健全性をチェックする。

Routing-Based HA: セグメント(サブネット)やデータセンターを超えたサーバーへのフェイルオーバー時の接続先の切り替えを、APIでネットワークのルーティングを操作することで実現する。

動的コンテンツの処理パターン

Clone Server: スモールスタートしたシステムでは、複数サーバーでのサービスが提供されておらず、負荷分散が考慮されていないシステムとなる。それを負荷分散可能なシステムとするために、既に存在するサーバーをマスターとし、追加するサーバーのマシンイメージを用意し、マシンイメージを起動してスケールアウトによる負荷分散を表現する。

NFS Sharing: 複数サーバーで負荷分散した場合、コンテンツを同期させる必要がある。マスターサーバーからスレーブサーバーに定期的に一方的に同期をとるのは容易だが、定期的な同期では遅延が問題があり、スレーブサーバーに書き込みがあるとマスターサーバーに反映されない課題が生じる。そのような複数サーバー間で同じコンテンツをリアルタイムで読み書きできるようにするものとなる。

NFS Replica: NFSを用いて複数サーバー間でファイル共有している場合、共有するサーバー数が増えアクセス頻度が高くなると、NFS部分のパフォーマンス劣化が無視できなくなる課題に対して、各サーバーに仮想ディスクを個別に用意しておき、NFSサーバーの共有ファイルをコピーしてNFSの参照専用レプリカとする。

State Sharing: 動的なコンテンツを生成する際、ユーザー固有の状態を持つステート情報(HTTPセッションの情報)を利用することが多い。だ、ロードバランサの配下で複数のWeb/APサーバーを動作させている場合に、各Web/APサーバーでステート情報を持つようにすると、サーバー障害時またはサーバー数を意図的に減少させる時、ステート情報が消失してしまう課題に対して、ステート情報を耐久性の高い共有データストア(メモリ/ディスク)に置き、複数サーバーからその情報を参照する形とする。

URL Rewriting: Webサービスを仮想サーバーで提供する場合、アクセス数が多くなると仮想サーバーの数を増やしたり仮想サーバーのスペックを上げて負荷に対応する。しかし、アクセスの大半は静的なコンテンツへのリクエストであることが多く、静的コンテンツのアクセスをどう分散するかは課題となる。そのような静的コンテンツへのアクセス分散方法として、インターネットストレージを利用することで、仮想サーバーを増強することなく負荷対策を行うことができる。これを実現するために、静的コンテンツのURLをインターネットストレージのURLに変換する必要があり、静的コンテンツを直接修正するか、WEbサーバーのフィルター機能を利用して配信時にURLを変更するか、インターネットストレージから配信するかわりに、コンテンツ配信サーバーからコンテンツを配信する手法がある。

Rewrite Proxy: 負荷対策の一つに静的コンテンツをいんたーねっとストレージやコンテンツデリバリーサービスに配置する方法がある。だが、静的コンテンツのアクセス先をインターネットストレージに変更する必要があり、コンテンツ内のURLの書き換えやWebサーバーへのフィルタリング設定など、既存システムに手を入れる必要がある。これに対して、既存システムに手を入れずにアクセス先を変更する方法として、プロキシサーバーを配置する手法がある。コンテンツを格納したサーバーの手前にプロキシサーバーを配置し、そこで静的コンテンツのアクセス先をインターネットストレージやコンテンツデリバリーサービスに変更する。

Cache Proxy: 負荷対策としてWeb/APサーバーを複数台利用するとコスト負担が大きくなる。そのため、Web/APサーバーを増やさずに艇庫システムのパフォーマンスを上げる手段として、コンテンツのキャッシュ(変化のあまりない静的コンテンツや動的コンテンツをWeb/APサーバーの上流でキャッシュし、キャッシュの期限が切れるまで配信パフォーマンスの高い上流のキャッシュサーバーでコンテンツの配信を行う)を、仮想サーバーで構築する。

Scheduled Scale Out: クラウド環境で構築されたWebサービスにおいて高トラフィックを処理する場合、Scale Outパターンが効果的となる。しかしながら、負荷状況を見て手製で仮想サーバーを追加したり、仮想サーバーの負荷状況に応じて自動的にインスタンスを追加していると、急激(目安として、5分以内にトラフィックが倍増するケース)なアクセス増の場合、インスタンスの起動が間に合わなくなる。また、一定期間のみ大量のコンピューターリソースを利用したいシチュエーションの場合、時間ベースでのインスタンス起動を行いたいケースがある。このような事前タイミングわかっている場合に、スケジューリングされたスケールアウトを行う。

IP Pooling: 携帯キャリアに対してメールを送信する際に、事前に登録したIPアドレスからしか送信を受け付けないようなケースや指定のネットワーク宛のサービスで接続元を制限しているようなケースなど、接続制限を行うために、接続元のIPアドレスを制限する場合、クラウドではグローバルIPアドレスを指定することができないため、サービス元に毎回登録する必要があるが、それらに対応するため、事前に必要なIPアドレスを確保して、接続先に登路することで、サーバーの変更や増減があっても、利用可能なIPアドレスプールから使用できるものを探し、サーバーに割り当てる。

静的コンテンツの処理パターン

Web Storage: 動画や高画質の画像、Zipファイルなどの容量の大きいファイルを1台のWebサーバーから配信する場合、ネットワーク負荷が問題となる。その場合、ネットワーク負荷を下げるために、複数台のWebサーバーを並べて負荷分散すると、大容量のファイルを複数サーバーに配置することになり、コストが増大する。この課題に対応するため、大容量のファイルをインターネットストレージへ配置し、そこから直接ファイルほ配信することで、Webサーバーのネットワーク負荷とディスク容量の問題を解決する。インターネットストレージに保存したオブジェクトは、公開設定にすることでユーザーに直接アクセスしてもらう。

Direct Hosting: 短期間で急激にアクセス数が増加した場合、マシンの増設では間に合わない。これに対してアクセス増を見越してサーバー数を増やすと、コスト面で課題となる。この課題に対応するための手段として、インターネットストレージをWebサーバーとして利用し、画像や動画などの大容量の静的ファイルをホスティングするだけでなく、HTMLファイルねホスティングする。

Private Distribution: インターネットストレージは可用性、耐久性が高く、サイズの大きなコンテンツやアクセス数の大きいコンテンツの配布にはあってつけである。しかし、特定のユーザーにのみコンテンツを配信する場合、作成したアプリケーションの認証の仕組みと連動する必要がある。インターネットストレージでけだアクセス制限を実現するのは難しい。この課題に対応するため、インターネットストレージで提供される制約付きURL発行機能を用いて、コンテンツに対して、アクセス元IPアドレスやアクセス可能期間が設定できる。ユーザーごとにURLを発行し、その制約付きURLでのみコンテンツをダウンとロードするようにすれば、期限が切れたリンクや異なるIPアドレスを持つ人がアクセスを試みてもダウンロードできない、実質的な特定ユーザーのみのコンテンツ配信が実現できる。

Cache Distribution: コンピューターやモバイルデバイスの普及に伴い、より多くの人が多くの地域から、インターネット上のコンテンツにアクセスできるようになった。また、画像や動画データはより高品質になり、データ量も非常におおくなっている。現在の技術では例えば日本から米国東海岸のサーバーにアクセスすると最低でも200ミリ程度の通信遅延が生じ、コンテンツの発信元が1カ所しかないと、ユーザーエクスペリエンスは低下する。これに対して、世界各地に配置されロケーションにコンテンツ配信元(オリジナル)から配布されるコンテンツのキャッシュデータ配置することで、地理的により利用者に近いロケーションからコンテンツを配信できるようにする。

Rename Distribution: Cache Distributionをコンテンツを配信する際に、オリジンサーバーのファイルを変更しても、エッジサーバー(キャッシュサーバー)のデータはタイムアウトになるまで更新されない課題に対して、エッジサーバー上のキャッシュデータはそこにアクセスするURLがキーになるが、更新したいファイルを違うファイル名で配置し、アクセスURLを変更することで、エッジサーバーのキャッシュタイムアウトにかかわらず新しいコンテンツを配信できるようにする。

Private Cache Distribution: 世界中のキャッシュロケーションを活用したコンテンツデリバリーのサービスを用いることで、世界中のユーザーに高速にデータを配信することが可能となっている。しかし、特定のユーザーにのみコンテンツを配信する場合、利用者を認証する必要があり、それらの仕組みを構築するのが容易ではない。この課題に対して、コンテンツデリバリーで提供される「署名付きURL認証機能」を用いる。これは、ユーザーがコンテンツをダウンロードするためにWebサイトにアクセスする際にあらかじめ設定しておいた「アクセス元IPアドレス」「ダウンロード可能期間」「アクセス元地域」などに適合した場合にのみ、「署名付きURL認証機能」を発行するもので、より高い精度での特定ユーザーへの配信を可能とする。

Latency Based Origin: グローバル展開している製品のWebサイト、ファームウェアや説明書などをCDNで配信する場合、ブランディングのために全世界から同じURLでアクセスさせたい。CDNを使用した場合、エッジサーバーにキャッシュがあればコンテンツを早くダウンロードできるが、キャッシュがない場合はオリジンサーバーまでコンテンツを取得に行く必要があり、ユーザビリティが低下する。この課題に対して、オリジンサーバーを複数用意し、同一のコンテンツを保持させて、オリジンへアクセスする際に使用するDNS名を登録する際に、一つのDNSに対して複数のオリジンサーバーのDNSを登録し、それを地理的に近いオリジンを返すように設定する。