Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイとはどういうものか? AWS re:Invent基調講演(Day2 AM)

2012年12月4日

クラウドによってリソースの制約から解放され、サーバやネットワークを含む冗長性までプログラミング可能になった新しい世界では、どのような考えによってソフトウェアを構築すべきなのか。

Amazon.com CTOのWerner Vogels氏は、Amazon Web Servicesが先週ラスベガスで開催したイベント「AWS re:Invent」2日目午前中の基調講演で、新しい時代のアーキテクチャとはどういうものなのか、聴衆に向けてたっぷりと解説しました。

(本記事は「AmazonクラウドのCTO「クラウドネイティブなアーキテクチャには4つの戒律がある」。AWS re:Invent基調講演(Day2 AM)」の続きです。

戒律その2「リジリエント」

21世紀のアーキテクチャの戒律、2つ目は「リジリエント」だ。

ビジネスをあらゆる状況から守る、ということである。

fig

もしも顧客名簿などのセンシティブなデータがあれば、暗号化すべきだ。Amazonでは実際にコンプライアンスのためにすべてのセンシティブなデータは暗号化されている。モダンなアーキテクチャは暗号を扱うのに十分な能力を持っている。

そして、プロダクションではぜひ複数のアベイラビリティゾーンを使ってほしい。ビジネスを守るために。すべてのものは壊れるのだから。

fig

そして最初からセキュリティをアプリケーションに統合するのだ。

もしもファイアウォールがアプリケーションを守ってくれていると考えるのならば、それはビジネスをリスクにさらしていることになる。セキュリティはセキュリティチームが作り込むのではなく、アーキテクチャの段階から作り込んでいくことを明確にすべきだ。

fig

そして開発スタイルも次世代的なものとして考えなければならない。

fig

新しい世界では要件はどんどん変わっていく。昔はこうしたリクエストに応えることはほとんど無理だった。

しかしリーン開発のコンセプトが登場し、限られた機能の製品を出して反応を見る、といったことを素早く繰り返すということが、プロダクトを作る新しい開発方法になっている。こうした開発方法論を持って開発をするべきだ。

クラウドネイティブなデプロイとはどういうものか?

Amazon.comでは11秒ごとに新しいコードがデプロイされている。そして最も多いときで1時間に1079回デプロイが行われた。これには機能追加だけでなくバグフィクスなども含まれるが。平均で1万、最大で3万ものホストがデプロイを受け取る。

fig

私たちはどうデプロイしてるのか。

以前、フェーズデプロイメントという方法をとっていた。3つのアベイラビリティゾーンをロードバランサーで分散していたが、それぞれの1つのボックスごとにデプロイして、OKだったら次へと続けて、やがて全体が新しいコードに置き換わる。実際には非常に複雑なワークフローだ。

fig

だがこれは21世紀的な方法ではない。クラウドネイティブなデプロイとはどういうものか?

いつでも使い捨てられるインスタンスがあるのだ。まず、新しいひとそろいのインスタンス(左)を用意して新しいコードをデプロイし、テストトラフィックを走らせる。

fig

OKだったら、ロードバランスを切り替える。これで新しいコードが本番環境になる。もし問題があったら、ロードバランスを元に戻せばいい。

fig

フェーズデプロイメントでは、元にもどすのは事実上不可能だった。しかしこれならロールバックしたいときにはAPIコール1つで済む。

障害を例外として扱わない

リジリエントを実現する要素。障害について考えよう。

fig

メモリ、プロセッサ、電源などあらゆるものは壊れる。個別の障害を考えるのではなく、あらゆる障害について考えるべきだ。そのためには新しいアーキテクチャへと切り替えるべきだ。

そのためには、障害を例外的なものとして扱わないことが大事だ。ビジネスロジックが10行でも、例外処理が20ページあっていい。コードは長い時間にわたって実行され続けるのだから。

fig

障害は例外ではなくデプロイの別の形であり、多くのイベントの1つとしてあなたのシステムに起こりうる。そう考えればシステムはリジリエントになる。

Amazon S3はどうデザインされているか?

リジリエントなシステムの例としてAmazonがある。Amazonはつねに動き続けることが求められた大規模な分散システムである。そのAmazon S3はどうデザインされているのかを紹介しよう。

Amazon Web Service、VP Storage ServicesのAlyssa Henry。

fig

Amazon S3はリジリエンシーでアダプティブに設計されている。

大規模システムでは、障害はつねに起きている。Amazon S3でもディスクの故障は1日に何度も起きているし、1兆個のオブジェクトが保存されているAmazon S3では、100万分の1の確率で起こることさえ毎日数千回も起きるのだから。

そのためのスケーラビリティとリジリエンシーだ。Amazon S3は障害を扱うための技術を複数用いている。

最もヘビーに使っているのは冗長性。複数のアベイラビリティゾーンは、まさにそのために使っている。Amazon S3はシングルリージョンの複数のアベイラビリティゾーンにコピーされ展開されている。

fig

リクエストがどう処理されるかを見てみよう。

DNS経由でロードバランサーがアベイラブルゾーン内のWebサーバへリクエストを投げる。Webサーバはインデックスサービスとストレージサービスにリクエストを転送する。インデックスサービスとストレージサービスは複数サーバからできており、耐久性が高くできている。

fig

Webサーバやインデックスサーバがオフラインになるなどもしどこかで障害が発生すれば、システムが自動的に回避し、冗長性が発揮されてリクエストが処理される。どこかのアベイラビリティが落ちたとしても、システムは動き続けることができるし、ピーク時であっても大丈夫なようにキャパシティが設計されている。

アダプタビリティとスケーラビリティは、疎結合によって実現されている。

Amazon S3は大規模サービスとして設計したが、システムを立ち上げて9カ月後には最初の見込みより急速にオブジェクトが増えてしまい、新たなストレージの仕組みに変えなくてはならなくなった。

そこでオリジナルのストレージ(図の青星印)と並行して新たな分散オブジェクトストレージを配置し、並行して運用した。

fig

新しいリクエストはすべて新しいサービスへ渡し、全体を移行したあとで従来のストレージを落とした。

顧客はこれによって高い可用性、性能向上などのメリットがあったが、アップグレード作業など何もする必要はなかった。

同じ仕組みをAmazon Glacierで用意した。これで既存のストレージからGlacierへ移行する際に、顧客はAPIで簡単に切り替えることができる。

fig

戒律その3「アダプティブ」

21世紀のアーキテクチャ、次は「アダプティブ」。これは環境への適応度が高いということ。

fig

まず、制約は何もないということから考え始めよう。どれだけサーバが必要か、ネットワーク容量は、といったことは考えないことだ。まず、顧客のビジネスにフォーカスすることから始めよう。

fig

そしてあとからリソースを追加できるようにする。レイトバインディングを使うのだ。

fig

戒律その4「データドリブン」

21世紀のアーキテクチャ、あと1つ戒律が残っていた。「データドリブン」だ。

fig

ビジネスレベル、システムレベルでコストやサービスのクオリティのフィードバックを見ることは非常に重要だ。

そのためにすべてを計測可能にし、データを集めるべきだ。そうしなければデータに基づいたアクションをとることはできない。

fig

そしてメトリクスを集めたら平均を見るのではない。全体を見る、特に悪いところを見る。例えば顧客を最大でどれだけ待たせているか、といったこと。それこそ肝心な点だ。

fig

4つの戒律、まとめ

まとめよう。21世紀のクラウドネイティブなアーキテクチャを紹介してきた。そこには4つの戒律がある。

fig

ビジネスレベルでのコントロールを持ち、アーキテクチャの中でコストを最初のオブジェクトと考えること。

アダプティブになるために、最初から制約を考えず、あとからリソースを追加できるようにする。

リジリエントのためには障害を例外として扱わず、最初から組み込んでおくこと。

そしてデータドリブンのために、すべてをログに入れることだ。

これらの背後にあるのは、あらゆるものがプログラマブルなリソースになっている、ということだ。

AWS re:Inventレポート

あわせて読みたい

AWS DevOps IaaS システム開発




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本