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

2012年12月4日

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

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

Vogles氏の話を紹介しましょう(本記事と、後編の「Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイとはどういうものか? AWS re:Invent基調講演(Day2 AM)」に分かれています)。

新しい世界にはリソースの制限がない

Amazon.com CTO Werner Vogels氏。

次世代のアプリケーションはどう構築されるのか、21世紀のアーキテクチャについて話そう。

fig

古い世界では、あらゆるリソースに制約があった。初期投資、キャパシティ、場所など。例えば2007年当時、Amazon.comのリテールビジネスでは、11月のピークに合わせてシステムが構築されていたが、そのハードウェアリソースの76%が使われていない。つまりインフラへの投資の76%が使われていないということで、ビジネスにとって悪いことだ。

fig

ハードウェアという物理的な制約があるためにこうしたことが起こる。

2010年11月10日、Amazon.comの最後の物理サーバがシステムから取り除かれた。そして2011年10月31日には、欧州ダブリンに置かれた欧州ビジネス向けの物理サーバもなくなった。すべてクラウド上のWebサーバに置き換えられた。

そしてグラフはこうなった。

fig

Amazon.comはサーバ1台単位でスケールを管理できるようになり、どんなプロモーションをかけてトラフィックが集中したとしても、リソースの制限はなくなった。

この新しい世界では、リソースの制限がない。

fig

これまでできなかったことが、いまでは可能だ。最も大きな違いは、あらゆるものがプログラマブルなリソースになった、ということだ。サーバを起動したかったら、ノートPCからすぐ起動できる。

fig

古い世界では、あらゆるリソースに制限があったため、そのリソースにフォーカスせざるを得なかった。しかし新しい世界では制限がないため、ビジネスにフォーカスできる。ルールが変わったのだ。

クラウドは、新しい世界でソフトウェアを開発するためのパワーを与えてくれた。

21世紀のアーキテクチャには4つの戒律がある

21世紀のアーキテクチャには4つの戒律がある。これは石碑ならぬタブレットに刻まれている。

fig

ビジネスがアーキテクチャをコントロールする「コントローラブル」、カスタマのビジネスを守る「リジリエント」、固定されたリソースに依存せず柔軟な「アダプティブ」、実際のデータに基づく「データドリブン」だ。

fig

「汝、新しいアプリケーションの構築には新しいコンセプトを用いるべし」

クラウドネイティブに考えよう。

戒律その1「コントローラブル」

21世紀のアーキテクチャの戒律、1つ目は「コントローラブル」だ。

fig

これを実現するためには、疎結合された小さな、ステートレスなブロックに分解するのだ。これがこれから話すことすべての基本である。

fig

どれだけ小さいブロック化というと、コントロールしたい単位の大きさだ。Node.jsのインスタンかもしれないし、Apacheかもしれない。数十のマイクロインスタンスかもしれない。いずれにせよ、ソフトウェアを小さなブロックに分けてコントロールする。

ステートレスはスケーラビリティにおいて重要だ。できるだけステートレスにすることで、よりスケーラブルになる。

疎結合についてはAmazon.comでの例を紹介しよう。

Amazon.comは疎結合で問題を解決した

Amazon.comの関連会社にIMDb(Internet Movie Database)がある。Amazon.comのWebべージでIMDbの情報を表示している。

以前はAmazon.comのサイトとIMDbは密結合されておりAmazon.comへのアクセスが増えると、すぐにIMDbのスケールが上限に達してしまっていた。

そこでAmazon.comとIMDbを分解することにした。IMDbでHTMLをあらかじめ生成しておきAmazon S3に保存しておく。それをAmazon.comが取り出して使うのだ。

fig

これで疎結合が実現され、いろんな問題を解決してくれた。

アーキテクトはコスト意識を持つべきだ

「コントローラブル」を実現する要素、次はアプリケーションとプロセスの自動化だ。

fig

ビジネスルールでアーキテクチャをコントロールするとすれば、そこに人は存在しない。ChefやPuppetのようにAPIを経由して行うのだ。Webページの表示が遅くなってシステムを拡大する、という背後にはビジネスルールが存在する。エンジニアがそれを判断して拡大するのではなく、ビジネスサイドが提供したいものによってアーキテクチャが操作され、拡大、縮小できるべきだ。

つまり、ビジネスがシステムを操作するようにするのである。

fig

そして、アーキテクトはコスト意識を持つべきである。

fig

可用性を実現する4つのアルゴリズムから1つを選ぶ、という判断はエンジニアとしてはできるだろう。しかし、ビジネス面で、アルゴリズム1とアルゴリズム2ではどれだけコストが違うのか?

アーキテクトとして、技術と売り上げやコストを同じ次元で考えるべきだ。

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

AWS re:Inventレポート

あわせて読みたい

AWS クラウド 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本