アマゾンCTOが語った、「クラウドネイティブ」なアプリのつくりかた：プログラマブルな、制約のないリソースを活用せよ

[三木 泉，＠IT]

　米アマゾンCTOのヴァーナー・ヴォーゲルズ（Werner Vogels）氏は11月29日、米Amazon Web Services（AWS）のイベント「re:Invent」2日目の基調講演で、21世紀的なアプリケーション開発のあり方について刺激的な議論を展開した。

米アマゾンCTOのヴァーナー・ヴォーゲルズ氏

　クラウドコンピューティング（ヴォーゲルズ氏にとってはAWSを意味する）では、ITリソースに関する制約が取り払われるとともに、これらのリソースすべてがプログラマブルになる。このため、あらゆる局面でITリソースを意識しなければならなかった従来のアプリケーション設計手法は本質的に変化し、開発者は、ビジネスに対して価値を与えることに集中できるようになる、とヴォーゲルズ氏は語った。これは、前日のAWS総責任者アンディ・ジャシー（Andy Jassy）氏による基調講演の影のテーマともシンクロする。

　「AWSのすべての機能やツールには、存在している理由がある」とヴォーゲルズ氏は話した。スピード、柔軟性、効率がますます求められるビジネスをITで支えるためには、アプリケーションの構築・運用手法がビジネスに直結しなければならない。AWSの機能やツールは、ビジネスに直結する新たな時代のアプリケーション・アーキテクチャを可能にするために存在しているのだという。

　ヴォーゲルズ氏は、21世紀型アプリケーションのあるべき姿を、「controllable」「resilient」「adaptive」「data driven」の4つの側面から語った。

21世紀型アプリケーションに向けた「四戒」

Controllable ―― ステートレス化、自動化、ビジネスとの融合

コンポーネント化とステートレス化

　ヴォーゲルズ氏がまず指摘したのは、アプリケーションをできるだけ小さな単位にコンポーネント化することと、できるだけステートレスな設計にすること。「ステートレス化を進めればオートスケールもしやすい」。例えばアマゾンは、IMDbという映画データベースサービス企業を買収。Amazon.comのDVD販売ページに関連情報を掲載するため、Amazon.comのWebサーバインスタンスからデータベースアクセスする設計を当初は導入した。しかしIMDbのデータベースはスケールする設計ではなかった。このためデータベース内の情報をあらかじめHTML化してAmazon S3に蓄積。Amazon.comのWebサーバはこれに対してアクセスするようにした。「これで突如として、Ajaxレディにもなった」。

iMDBとの接続のビフォー・アフター

デプロイメントおよび運用のプロセスの自動化

　自動化が不可欠である理由は、ビジネス自体が直接、アプリケーションを制御できなければならないからだ、とヴォーゲルズ氏は話した。ビジネス担当者が、「このページのレスポンスは1〜1.2秒の間」といったルールを決め、それに基づいてスケールアップ／スケールダウンを実行する。

　「ビジネスルールに基づいてアプリケーションをコントロールしたいなら、人間はそのループに介在する余地がない」。APIやChef、Puppet的なツールを活用し、作業を可能な限り自動化すべきだという。「sshやrdpでEC2インスタンスにログインすることがあるなら、あなたの自動化はそこで途切れている」。

アプリケーション設計の最初に考えるべきはコスト

　AWSのようなサービスによって実現される新たな世界では、ITリソースがプログラマブルであるため、各リソースを非常にきめ細かく制御できる、このため、コスト意識をアプリケーション自体に組み込める、とヴォーゲル氏は語った。

　「あなた（の組織）はどういう切り口でビジネスしているのか。コストもその切り口に連動しなければならない」。Amazon.comでは、注文の伸びとコストの伸びが比例する設計になっている、と同氏は話した。

Resilient ―― 強靭なシステムにはちょっとの努力だけ

顧客の保護は何よりも優先されるべき

　セキュリティについては「原則として、すべてのデータと通信を暗号化すべきだ。リソースに制約がない新たな世界では、暗号化プロセスのために1、2のインスタンスが増えても、大勢に影響はない。また、AWSでは自社のサービスのセキュリティ向上に注力する一方、きめ細かいセキュリティツールを提供している。セキュリティチームに頼るのではなく、あなた（開発者）自身が活用してほしい」とヴォーゲルズ氏はいう。

　可用性については、「どうか、Availability Zone（AZ）を使ってもらいたい。本番運用に移行する際に、最低2つのAZを活用してほしい。これほど簡単なことはない。追加的な作業は必要ない」と訴えた。

コンティニュアスなデプロイメントやインテグレーションは日常だ

　要件は刻々と変化していくものだ、とヴォーゲルズ氏はいう。「従来は、要件変更に答えることがほとんど不可能だった。次回のリリースで実現すると答えるしかなかった」。しかし（「リーン・スタートアップ」などの）リーンなコンセプトがビジネスに浸透してきた。まず限定的な機能を提供しつつ、ユーザーを巻き込みながら徐々に充実を図っていくといった、製品展開に関する新たな考え方もある。一方で競争は激化しており、製品の成功確率は非常にあいまいになってきている。「だから、開発メソドロジーも、この不確実性に対応したものでなければならない」。

　新たな世界では、リソースの制約がないことが、内在的な柔軟性を実現する、とヴォーゲルズ氏は話した。Amazon.comでは、平日の場合平均11.6秒ごとに、新たなコードがデプロイされる、という。「サーバ1台ごとに段階的にアップデートをしていくような方法は、ワークフローとして複雑すぎ、エラーの原因にもなる」。

Amazon.comにおけるデプロイメントのペース

　新しいやり方として採用すべきなのは、アップデート対象となるアプリケーションについて、稼働中の全サーバの複製を別途立ち上げ、アップデート後に確認を終えたら、Elastic Load Balancerの設定を新サーバ群に切り替えるといった方法だ。これなら、いままで不可能だったロールバックも、容易に行うことができる。

新コードのEC2インスタンス群に一括切り替えする

障害は例外的なものではないと考えること

　新しい世界では、メモリやCPUなどの物理的な障害からは大幅に解放される。しかし、新しい世界に生きているユーザー企業も、コードが多数の障害要因を含んでいることを認識している、とヴォーゲルズ氏。

　「次の曲がり角には、必ず障害が待ち受けている。障害は例外ではない。ステートレスなものの見方ができるユーザー企業は、障害を、多様なイベントの一部と捉えている」。

　ステートレスな設計の上で、迅速なスケールアップやフェイルオーバーを実現することで、アプリケーションの障害耐性を高めることが可能だと話した。

Adaptive ―― アプリケーションへの制約を減らせ

自分で制約することをやめよ

　物事を不要に複雑化せず、できるだけ制約から自由であることを心掛けよ。自分のやることになるべく前提を付けないようにすることは、障害の最少化にもつながる。

　例えば利用するEC2インスタンスのタイプを決めるのは、できるだけ後の工程にすべきだ。特定のインスタンスタイプを前提とせずに開発することで、適応性が生まれる。運用開始後に考えが変わったとしても、いつでも対応できるからだ。

Data Driven ―― データを最大限に活用せよ

　新世代のシステムは、現実のデータに基づいて制御されるべきだ。システム、アプリケーション、ビジネスといったあらゆるレベルの、現実のデータを活用してフィードバック・ループをつくるべきだ。すべてを常時計測することを考えよ。データを収集することなくしては、何の行動もできないからだ。計測データをCloudWatchにプッシュして、十分に活用すべきだ。

　Amazon.comで、痛い経験から学んだことの1つは、こうしたデータの平均値ばかり見ていてはいけないという点だ。「平均遅延」は、顧客の半数が、その値に劣るユーザー体験をしているということしか示してくれない。分布曲線の全体を見て、エッジのユーザーの環境改善に努めれば、多くの場合、全体の分布曲線も改善する。

　Apacheやユーザーエージェントだけでなく、あらゆるシステムやビジネスのデータを取得しておくべきだ。事後にアナリティクスを活用し、アプリケーションがどんな条件でどんなパフォーマンスを発揮するかを分析し、フィードバック・ループをつくることができる。

　AWSが新たに発表した「AWS Data Pipeline」は、こうした作業の大幅な省力化を実現するためのツールだ。