「AWS Cloud Roadshow 2014 札幌」レポート 〜 クラウド開発者のためのCloud Design Pattern入門 [UC-01]　#AWSRoadshow

こんにちは、石川です。 「クラウド開発者のためのCloud Design Pattern入門」というテーマで、CDPの発案メンバーであるNinja of Threeの「＃ヤマン」こと、ADSJの片山 暁雄さんのセッションについてレポートします。

※資料は別途、公開されると聞いております。公開されましたらリンクを追加するようにします。

概要

AWS クラウドデザインパターン (AWS Cloud Design Pattern, 以下、CDP)は、AWS クラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものです。

このセッションでは、CDP の概要、最も基本的なCDP、応用パターン、エンタープライズCDPなどを紹介しています。

はじめに

AWSは非常に多くのサービスがあり、うまく組み合わせることで、「ピーク対応」、「低コスト」、「セキュアシステム」、「対障害性が高い」、「世界展開」を容易に実現できるといった特長があります。一方、サービスが多くて、「全体がわからない」、「使い方が正しいのかわからない」、「組み合わせがわからない」、「書籍や日本語資料がもっとほしい」というお問い合せやご質問をされる場合が多くありました。

AWSでシステムを構築しようとすると、どういったサービスがあるのかの把握したり、組み合わせやその手順といった経験が必要であり、実際にはどうしたらよいかと良いのかと立ち止まってしまいます。そのお悩みを解決するために考えたのがCDPです。

CDPはプログラミング言語のデザインパターンと同様に、クラウドの様々なコンポーネントを使うときの道しるべになるようなパターンを抽出して、再利用できるようにしたものです。

AWS クラウドデザインパターン(CDP)とは

「AWSを利用する際に発生する、典型的な問題とそれに対する解決策・設計方法について、先人たちの知恵をわかりやすく分類して、ノウハウとして利用できるように整理したもの」です。 他のサービスも含めて２１のデザインをパターン化、総計４８種類

Webサイト

http://aws.clouddesignpattern.org/ http://en.clouddesignpattern.org (英語)

Webサイトでは、CDPに対して「解決したい課題」、「クラウドでの解決/パターンの説明」、「実装」、「構造」、「利点」、「注意」がそれぞれ書かれています。 様々なカテゴリに分かれており、基本のパターンをはじめに、可用性を向上するパターン、静的コンテンツを処理するパターン、バッチ処理のパターン、運用保守のパターン、ネットワークのパターンなどに分類しています。

書籍

• 設計ガイド

http://www.amazon.co.jp/dp/4822211983

• 実装ガイド

http://www.amazon.co.jp/dp/4822211967

• Kindle版設計ガイド

http://www.amazon.co.jp/dp/B00I3XD0I0/

基本パターン

仮想サーバや仮想ディスクをとりあげ、これらのコンポーネントの特性を活かした基本的なデザインパターン。

Stampパターン

仮想サーバのコピーを行うというパターンです。リソース制限を考えずにリソースの制限にとらわれずカジュアルに行えます。

Scale Upパターン

仮想サーバーの処理能力を増減させるパターンです。サーバーなの処理能力が足りない時に必要に応じて大きくすることをリソースの制限を考えずに行えます。

Ondemand Diskパターン

必要なときにディスクを調達するパターンです。最初は10GBから処理をしておいて、後ほど必要になったら100GBに上げるといった運用がカジュアルに行えます。

ディスクの性能が欲しい場合は複数ディスクによる性能アップも可能です。例えば、バックアップを書き出す時だけディスクを追加するといったことも考えられます。

応用パターン

基本的なパターンをベースにさまざまな課題に対して解決策を提供するパターン。

Floting IPパターン

瞬時にサーバーを切り替えることができます。新しいサーバーを構築して、グローバルIP(EIP)を新しいサーバーに付け替えることによって実現します。

実際にNASAでもフェイルオーバー構成に利用されています。Management Console以外に、APIからも可能なので監視と組み合わせて、何らかのアラートで切替を自動化するなどの応用が考えられます。

Job Observerパターン

バッチのパターンの一種で、処理(例．画像や帳票生成等)を行いたい場合に一旦ジョブをキューに入れ、処理をするワーカーがキューから取り出してジョブを実行するパターンです。

キューのジョブの数を確認して一定のしきい値を超えた場合にスケーリング仕組みを使ってワーカーを追加することでスケールアウトさせるパターンです。ジョブの大きさによってバックエンドのワーカー数を動的に増減することでコスト効果を高く運用することが可能になります。

Cloud DIパターン

インフラ自体をAPIやプログラムを使って作る "Infrastructure as a service"で利用できるパターンの一つで、サーバー自体に必要な設定を外出しにしておいて、後から設定する際にEC2に依存する固有情報を注入(DI)するパターンです。

サーバーを起動するときにフッキングできるポイントがあるので、そこに処理を入れます。サーバー自体に対してストアから設定出来る機能があり、サーバーにタグをつけたり、指定のURLから設定ファイル(UserData)を取得することができます。

例えば、事前にタグを付けておいた場合に自分に付いているタグを読み込んできて、サーバー自身を初期化することができます。IAMロールもこのパターンを使って実装されています。

Scheduled Scaleパターン

事前にスケジュールを組んでおいて、ピークに合わせてリソースを増減させるパターンです。

キャンペーンやテレビ、あらかじめ予測できるピークに合わせて対応する事ができます。

Routing-Based HAパターン

仮想IPを使ってデータセンターをまたいでフェイルオーバー構成を実現するパターンです。

アクセスしたいサーバーに対して仮想IPを割り当て、もし落ちた時に仮想IP自体のルーティングを変更するようにスクリプトを組んでおいてルーティングを切り替える。アクセス元を切り替えることなくルーティング切替えてHAを実現しており、多くのクラスタソフトでも同様のテクニック使ったHA製品が存在します。

エンタープライズCDP

昨今では紹介したCDPを効果的に組み合わせたシステムというのが多くありますが、エンタープライズのお客様ならではの悩みとして、「複雑なネットワーク」、「ハイパフォーマン」、「セキュリティ」、「DR／BCP」を必要とされる方が多くおられます。これまでのCDPから視野を広げて色々なパターンを作ろうという取り組みをしています。

AWS上でSAPのERPのシステムを構築する場合のアーキテクチャーを例にあげると様々な役割を持ったサーバーを効果用にするためにいくつかのパターンが利用されています。

Self Healing パターン

高可用で冗長化はしたいがアプリケーションの制約で分けて処理ができないパッケージやアプリケーションが多くありますが、このような場合に単体のサーバーの可用性を向上させるパターンです。

サーバーダウンの検知にオートスケーリングの仕組みを利用します。オートスケーリングの設定で、最大１インスタンス、最小１インスタンスと設定することで常に一台は起動しているという状態を作ります。オートスケーリングでネットワークが到達しないことを検知すると新しいインスタンスを起動しますが、その際にCloud DIパターンを使って、先ほど稼働していたディスク自分自身にデータ領域のマウントを実施する事によって、VMwareのVMHAのような機能を実現できます。

Syncronized Diskパターン

現在、AWSでは共有ディスクサービスを提供しておりませんが、例えばバッチ処理中のフェイルオーバー後も処理を引き継ぎたいといった場合に、この課題を解決するパターンです。

２つのインスタンスを立てておき、お互いのディスクを同期します。同期には有名なDRBDがありますが、その他にもNECのCLUSTERPROやサイオステクノロジーのDataKeeperなどがAWS上でデータ同期できる機能を提供しています。データセンタをまたいでディスクを同期し、どちらかが落ちたらもう片方で処理を継続するということができます。

Shared Serverパターン

非常に多くのシステムがあって、中でも共通のシステムを所有している場合があります。例えば、監視サーバー、アンチウイルスのパッチ配信サーバー、ログサーバー、共通のプロキシサーバーといった共通システムのサーバーををAWS上で実現するパターンです。このパターンはパートナー企業である(弊社)クラスメソッドがブログにて提案したパターンが採用されたものであることが紹介されました。

新CDP候補「Shared Serverパターン(仮)」 https://dev.classmethod.jp/cloud/aws/cdp-server-sharing/

共通のシステムは１つのネットワーク(VPC)で定義して、それ以外の各システムは個別に作っておきペアリングをして共通で使うというパターンです。AWSのネットワークであるVPC(Virtual Private Cloud)のペアリングという機能(VPC Peering)を応用したものです。VPC Peeringとは、異なるVPCをクラウドの中でペアリング(接続)するといった機能です。

例えば、インターネットの外向けのプロキシはネットワークを管理をするVPCの中に作り、プロキシに特定のURLとは通信しないような制限を設けたり、ログを取得する機能を実装しておきます。それ以外の各システムは個別にVPC作っておきインターネットに接続するときは必ず共通のVPCのプロキシを経由するといった設定にすることで、外部接続の一括管理によるセキュリティの向上が期待できます。また、WAFを共通のネットワークに導入の際にネットワークベンダにはこのVPCへのアクセスのみを許可するなどの運用が可能になります。

On Demand Bastion / On Demand Firefall パターン

セキュリティを管理しながらメンテ作業をするのに踏み台サーバー(Bastion Server)を経由させる事がよくありますが、On Demand Bastionパターンはこの踏み台を必要なときだけ起動し、不要になったら削除するという運用を実現するパターンです。同様にOn Demand Firefall パターンはそのFirewall版です。AWSではAPIがありますので起動や破棄を自動化することも可能です。

例えば、利用者が承認者に対して利用申請を上げると自動的に指定した時間帯だけ踏み台サーバーが構築され利用可能になるといった運用が考えられます。

まとめ

既存のベストプラクティスを利用できる

CDPを利用することでクラウドを使った設計や開発をする際の生産性を向上させることができると考えていますので、既存のベストプラクティスというものがありますので一読することで開発する際のヒントになると思われます。

自動化やセキュリティ、運用性も向上

パターンを利用することで自動化やセキュリティを向上させられるのではないかと考えています。 セキュリティを上げながら自動化をすることで運用性を向上させることができます。また、オートスケーリングを利用すると可用性を上げながら運用性を向上させるとこができます。

今後、ブラシュアップ

パターン自体は今後増えていったり、新しいサービスなどはそれ自体がパターンを実装している可能性があります。これからどんどんブラッシュアップを進めたいと考えています。

CDPは日本初のコンテンツでしてグローバルに発信していきたいと考えており、2012年のRe:Inventで発表しています。みなさんもいいなと思えるパターンを見つけたら、Facebook(https://www.facebook.com/awscdp)やTwitter(https://twitter.com/c9katayama)などでShareしてください。