JAWS FESTAで聞いたAWS誕生秘話とサーバーレスへの必然

なぜAmazonはマイクロサービスに舵を切ったのか？

2018年01月24日 10時00分更新

文● 重森大

JAWS FESTA 中四国 2017は数々のサポーター企業のおかげで開催できたイベント。その中でもやっぱりここは外せないよねっていう営業的な意味合いは実はなかったのだけど、﹁AWS誕生秘話﹂というタイトルに惹かれてAWSのサポーターセッションを聴講した。AWSに触れはじめて2年ほどの筆者にとっては﹁へえー﹂と思う話。すでに知っていたという人も、これを機にAWSの成り立ちを振り返ってみてほしい。

当初、モノリシックなアーキテクチャだったAmazon.com

　セッションを担当したのは、AWSの亀田治伸さん。JAWS-UG札幌でもお会いしたので、1ヶ月も経たずに再会だ。札幌ではここ半年のAWSアップデートを駆け足で紹介するという最新情報セッションを展開した亀田氏だが、今回は打って変わって﹁AWS誕生秘話　AmazonがAWSを生み出した背景　～マイクロサービスアーキテクチャとDevOpsの基本理念～﹂と題してAWS昔話。そう、それは2000年頃のことだった……。﹁2000年頃、Web ServiceとAPIがIT業界ではトレンド化していました。Web技術が進化して、基幹系など業務にも使えるようになったこと、サブシステムをAPIで疎結合すれば部分的な改良が可能なことなどが理由です﹂︵亀田さん︶

アマゾンウェブサービスジャパン亀田治伸さん

　話は2001年頃のAmazon.comのシステムに移る。まさにAPIブームの最中だったが、立ち上げ当初のAmazon.comのシステムはガチガチのモノリシックアーキテクチャだったという。顧客の住所氏名、クレジットカードナンバーなどを扱うため、単一の堅牢なシステムを目指していたのだ。﹁しかしAmazon.comのシステムは、モノリシックアーキテクチャのアンチパターンにハマってしまいました。ビジネスの急成長に、システムのスケールや機能追加が追いつかなくなっていったのです。密結合なので、メンテナンスや維持が大変だし、変更のたびに全体を再ビルドしてテストしなければなりません。デプロイは開発チームの一大イベントとなり、ビジネスのボトルネックともなりました﹂︵亀田さん︶

REST APIだけで連携するマイクロサービスに大きく方向転換

　モノリシックアーキテクチャの限界を感じたファウンダーのジェフ・ベゾスは、システムの方向性をまったく逆方向に向かわせるメッセージを全社に向けて発信した。肥大したシステムをマイクロサービス化し、各システムはHTTPSのAPIだけで連携させること。しかもAPIには、当時はまだ主流ではなかったREST APIを採用した。これを徹底するために、正当な許可なくマイクロサービス以外のシステム、API以外で他サービスと連携するシステムを作ったエンジニアはクビにするとまで言い切ったという。﹁どこくらいの規模までをマイクロサービスと呼ぶのか。AWSにはその基準もあります。﹃Two-pizza teams﹄と呼ばれるもので、2枚のピザでお腹を満たせないような規模のチームを作ってはいけないというルールです。といっても、アメリカンサイズでの話ですから、ピザ2枚でお腹を満たせるのは10人くらいでしょうか﹂︵亀田さん︶　また、すべてのチームが担当するサービスのすべての所有権、説明責任、より良くしようとする動機を持つべきだとされている。そうした姿勢がすべてのエンジニアに浸透し、Amazon.comの機能はマイクロサービス化し、2006年3月にAWSのスタートと言われる﹁Amazon S3﹂の商用サービスが始まった。　しかし、AWSのスタート以前にもAmazon.comはクラウドサービスを提供していた。Amazon ECS︵Amazon E-Commerce Service︶と呼ばれたサービス群だ。広告用APIやメッセージキューイングサービスであるSQSなどを2004年にリリースしている。﹁そういえばECSなんて呼ばれていたなあ﹂ってぼんやり思い出すのはおっさんだけかもしれないが。

2006年3月にS3のサービスがスタート、一般的にAWSの開始はこの時期とされるが、AWS以前からAmazonはクラウドサービスを提供していた

　2006年3月のS3に続き、同年8月にはいよいよEC2がサービスイン。しかしこの当時、まだサービス全体を統括するマネジメントコンソールは提供されておらず、個別に起動してAPIで連携させるしかなかった。マネジメントコンソールの提供が始まり、現在のAWSに近い形のサービスになったのは、2009年1月。Amazonがクラウドサービスの提供を開始して、4年以上の時間が経過していた。

クラウドサービス提供開始から4年以上を経てマネジメントコンソールをリリース、現在の形に近づいた

AWSの歴史とはアプリケーション開発効率化の足跡

　こうして成り立ちを振り返ってみるとわかることは、AWSはAmazon.comを支えるアプリケーションエンジニアたちの視点からスタートしているということだ。しかし、サーバーやストレージの印象が強いせいか、インフラとして見られてしまうことが多いと亀田氏は言う。﹁検討中の企業や利用中の企業からの依頼で勉強会を開くと、インフラエンジニアだけを集めて参加されるケースが、実際に数多くありました。しかしアプリケーションエンジニアとインフラエンジニアがうまく配分されないと、クラウドインテグレーションは定着しません﹂︵亀田氏︶　アプリケーションエンジニアとインフラエンジニアの双方が特性を理解して初めて、AWSの力が発揮される。システムインフラを単純にクラウドに持って行っただけのサービスではなく、アプリケーション開発の効率化を目指した上に生まれたサービスだからだ。そして、それをさらに推し進めた結果としてたどり着いたのが、﹁サーバーはない方がいい﹂というサーバーレスの機能群だ。マイクロサービス化もサーバーレス化も、アプリケーション開発の視点で考えて得られた解のひとつなのだ。﹁アプリケーション開発の効率向上のために採用したマイクロサービス化がもたらす効果については、AWS自身がいい例になっていると思います。数千のチームがあり、それぞれがマイクロサービスアーキテクチャにのっとって開発し、複数の環境に向けて継続的なデリバリを行なっています。その結果、2014年の時点で年間5000万回のデプロイがサービスの裏で行なわれていました﹂︵亀田氏︶　これだけの回数のデプロイがあっても、デグレーションはほとんど発生しないという。それぞれのチームがマイクロサービス化とAPIによる連携を固持し、チームごとの独立性を確保しているからだ。そして、数千のチームがあるということはそれだけの数の責任者がいるということでもある。それぞれが自分のチームのサービスをより良くする動機と責任を持つことで、サービス向上に取り組むモチベーションアップにもつながっているという。モチベーションが高まれば、それだけサービス品質は向上し、改善スピードも速くなる。AWSの歴史とは、アプリケーション開発効率化を追った足跡でもあったのだ。

■関連サイト