CDP Advent Calendar2013の12/1担当の片山です。シアトル時間で12/1、ということで勘弁して下さい。
今年ももう残すところあと一ヶ月ですね。
はじめに
2013年もAWSプラットフォームのイノベーションのペースはますます加速し、2013年10月の時点で、235の新サービス/機能追加が行なわれました。
AWSのイベントre:Invent2013では、非常に多くのサービスが発表されました。新しいサービスに付いては、AWSユーザーの利用につれてノウハウがたまり、パターン化してくる事が期待できますが、既存のパターンについては、機能追加によりより良い実装が出来るようになったり、パターンのバリエーションが
増えたりしています。
今年はCDP2.0という事で様々なアーキテクトの方に新パターンを提唱頂きました。これらパターンをCDP2.0として入れていくと共に、既存パターンやカテゴリの
再精査を行ない、CDP2.0としてまとめて行きたいと思っているため、このエントリは見直し用のワーキングログということで、ざっと見直しポイントを
書き出してみようと思います。
なお、既存の各パターンは http://aws.clouddesignpattern.org/ で見ることができます。
基本のパターン
- Snapshotパターン(データのバックアップ)
- Stampパターン(サーバの複製)
- Scale Upパターン(動的なサーバのスペックアップ/ダウン)
- Scale Outパターン(サーバ数の動的増減)
- Ondemand Diskパターン(動的なディスク容量の増減)
Snapshotパターンについては、以前からクラウドワークスなどのツールでもサポートされていましたが、AWSからもリージョンを超える機能が出てきましたね。
Snapshotパターンを使う利点やユースケースとして、DR対策として利用できる点や、地域をまたいでディスクイメージを移動できる点を追加してもよいですね。
また実装ツールとしてはAWSのarcheがre:Inventで発表されました(いまだにgitリポジトリには上がっていませんが...)。
なお、スナップショットについては、re:Inventのスナップショットのセッションが参考になります。
http://www.slideshare.net/AmazonWebServices/stg402
可用性を向上するパターン
- Multi-Serverパターン(サーバの冗長化)
- Multi-Datacenterパターン(データセンターレベルの冗長化)
- Floating IPパターン(IPアドレスの動的な移動)
- Deep Health Checkパターン(システムのヘルスチェック)
Deep Health Checkは、ELBの実装以外にも、Route53でも出来るようになりました。ヘルスチェック機能を利用すると、リージョンをまたいだDeep Health Checkを行なう事ができますね。
可用性という意味では、データの可用性を目的としたパターンはありそうですね。GlusterFSやDRBD、商用であればClusterProやLifeKeeperなど方式や目的は異なれども可用性を上げる目的で使われるソフトウェアも多いので、一度精査したいですね。またエフェメラルがSSDベースのインスタンスも増えたので、例えばエフェメラル+EBSの組み合わせのようなパターンも、もっとありそうです。
動的コンテンツを処理するパターン
- Clone Serverパターン(サーバのクローン)
- NFS Sharingパターン(共有コンテンツの利用)
- NFS Replicaパターン(共有コンテンツの複製)
- State Sharingパターン(ステート情報の共有)
- URL Rewritingパターン(静的コンテンツの退避)
- Rewrite Proxyパターン(URL書き換えプロキシの設置)
- Cache Proxyパターン(キャッシュの設置)
- Scheduled Scale Outパターン(サーバ数のスケジュールにあわせた増減)
NFS Sharingパターンでは、実装としてStorage Gatewayを使う方法がありますね。特にCached volumeが使えるようになったので、単に共有するだけでなく、効率的にディスクを利用しながらバックアップポイントを絞るというような利点もあります。
NFS Replicaパターンは、最近SSDベースのインスタンスが増えてきた事を考えると、実は利点が多いパターンかも知れません。
State Sharingパターンは、ElastiCacheのRedisエンジンを利用する事が出来ますね。
URL RewritingパターンとRewrite Proxyパターンについては、CloudFrontの機能向上(SSL対応,POST対応)により、AWS上では少し登場回数が少なくなってきているかも知れません。
静的コンテンツを処理するパターン
- Web Storageパターン(可用性の高いインターネットストレージ活用)
- Direct Hostingパターン(インターネットストレージで直接ホスティング)
- Private Distributionパターン(特定ユーザへのデータ配布)
- Cache Distributionパターン(ユーザに物理的に近い位置へのデータ配置)
- Private Cache Distributionパターン(CDNを用いたプライベート配信)
- Rename Distributionパターン(変更遅延のない配信)
Direct Hostingパターンは、Wordpressのハンズオンなども盛んに実施され、かなり定着したパターンになったと感じます。単に価格面だけでなく、セキュリティ面での利点も多くうたわれていましたね。
今年はMobile SDKやJavaScript SDK、またIAMのフェデレーション機能が拡充したので、Direct Object Uploadパターンなどと組み合わせて、よりEC2レスなパターンが生まれてきそうです。
データをアップロードするパターン
- Write Proxyパターン(インターネットストレージへの高速アップロード)
- Storage Indexパターン(インターネットストレージの効率化)
- Direct Object Uploadパターン(アップロード手順の簡略化)
Storage Indexパターンという観点で見ると、S3->Glacier連携機能はこのパターンですね。Glacierは格納すると元のファイル名ベースでは検索出来なくなるのでインデックスは必要ですが、S3の機能追加によりそれを意識せずにGlacierに格納する事ができます。
Direct Object Uploadパターンは、先述の通り各種SDKやフェデレーションの組み合わせで、より多くの場面で使えるようになりました。
リレーショナルデータベースのパターン
- DB Replicationパターン(オンラインDBの複製)
- Read Replicaパターン(読込専用レプリカによる負荷分散)
- Inmemory DB Cacheパターン(頻度の高いデータのキャッシュ化)
- Sharding Writeパターン(書き込みの効率化)
Read Replicaパターンについては、MySQLのリージョン越えの機能やマスター昇格機能が追加されましたので、地域を越えてデータを非同期連携
したい場合にも有効なパターンと言えますね。
バッチ処理のパターン
- Queuing Chainパターン(システムの疎結合化)
- Priority Queueパターン(優先順位の変更)
- Job Observerパターン(ジョブの監視とサーバの追加・削除)
- Scheduled Autoscalingパターン(バッチ処理サーバの自動オンオフ)
Queing Chainパターンは、単純なもの以外は、Simple Workflow Service(SWF)やElastic Data Pipeleneで実装するほうが便利なケースがありますね。またこういったジョブ連携は、単にデータ加工やデータ生成だけでなく、インフラ構築やバックアップなどの処理にも使われてきています。
Job Observerパターンは、re:Inventの後藤さんの発表でも実際の案件例として取り上げて頂きました。
Scheduled Autoscalingは、OpsWorksでも使う事ができますね。使いやすいGUIが提供されています。
運用保守のパターン
- Bootstrapパターン(起動設定の自動取得)
- Cloud DIパターン(変更が多い部分の外出し)
- Stack Deploymentパターン(サーバ群立ち上げのテンプレート化)
- Server Swappingパターン(サーバの移行)
- Monitoring Integrationパターン(モニタリングツールの一元化)
- Web Storage Archiveパターン(大容量データのアーカイブ化)
- Weighted Transitionパターン(重みづけラウンドロビンDNSを使った移行)
このカテゴリは、来年もっとパターンが増えそうですね。AWSサービスとしてもOpsWorksが出てきましたし、最近ではImmutable InfrastractureやImmutable Serverのような、Immutable Object的な考え方でインスタンスを作るのが話題になっていたりしますね。BootstrapパターンやCloud DIパターン、Dockerなどのコンテナ、またChefやPuppetなどのツールと組み合わせて、より効率的に運用や開発、構築を作るものが考えられますね。
ネットワークのパターン
- OnDemand NATパターン(メンテナンス時のインターネット設定変更)
- Backnetパターン(管理用ネットワークの設置)
- Functional Firewallパターン(階層的アクセス制限)
- Operational Firewallパターン(機能別アクセス制限)
- Multi Load Balancerパターン(複数ロードバランサの設置)
- WAF Proxyパターン(高価なWeb Application Firewallの効率的な活用)
- CloudHubパターン(VPN拠点の設置)
このネットワークのパターンは、個人的には今年一番多く聞かれたところですね。
特に組織や子会社などとの関係性や、課金の分け方、セキュリティの担保などを考慮してVPCの切り方を検討するケースが多く、ここはもっとナレッジを貯めてパターン化素すべき所だと感じています。
また今後、VPC間接続やAWSエンドポイントへの接続口などをAWSが提供すれば、また設計が変わってくるところでもありますので、継続的に注目していきたいですね。
おわりに
このCDPアドベントカレンダーでもいくつか新しいパターンを提唱して頂けると思いますので、それも加味して、一度CDP2.0としてFIXさせたいと思います!