« Amazon EMR 4.4.0 - Sqoop, HCatalog, Java 8, その他 | メイン | AWS Database Migration Service (DMS)が一般公開に!利用可能リージョンも拡大 »

10 Lessons from 10 Years of Amazon Web Services ~ AWS10年に学ぶ10のレッスン

 

Amazon.comのCTO  Werner Vogelsが、彼のブログでこの10年のAWSの軌跡を振り返っています。
ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。

--------------------

AWSの革新は2006年3月14日のAmazon S3のローンチで、約10年前の出来事でした。10年前を振り返ると、低価格で予測可能なパフォーマンスにより、セキュアで、信頼性があり、拡張性が高い、構築・運用が実現できていることから、数百もの学びがあります。AWSは、世界規模でサービスを構築・運用できるパイオニアであり、これらの学びは我々のビジネスにとってとても重要です。以前も何度となくお伝えしている通り、経験だけはショートカットするする方法がない、ということです。毎月の数百万ものアクティブなお客様と共に、彼らの先にいる数億ものお客様と共に、お客様にサービスを提供しながら改善するためのまたとない環境と学ぶ機会を得ています。

みなさんと共有したいいくつかの学びをご紹介します。

1. 進化可能な仕組みを構築する

ビジネスが始まる初日から、開発していたソフトウェアは、もはやソフトウェアに非ず、ということを一年間走らせてみてわかりました。その期待値は、金額でいえば一桁、二桁も異なり、スケールの問題を解決する為のアーキテクチャの再考が必要になったものです。
 
とはいえ、世界中で24時間365日多くのシステムが我々のプラットホームで動作しているのですが、システムアップグレード時にメンテナンスによる中断を起こさないようにする形態をとることはできませんでした。我々は、サービス停止を起こさずに新たなコンポーネントを導入できるアーキテクチャを作る必要がありました。Marvin Theimer, Amazon Distinguished Engineerの彼が、Amazon S3を例えば言うならば、当初は単機エンジンだったセスナが、時間を経過するとボーイング737や747sにアップグレードされている、そして最後はエアバス380sのようだ、と冗談まがいに言っていました。成長の途中で、空中燃料補給をしながら、お客様に築かれないように飛行機を乗り換えているようだと。
 
2. 想定していないことを想定する

失敗はもたらされるもので、すべてが最後は失敗に成り立っている。ルーターからハードディスク、OSからメモリユニット、誤ったTCPパケット、一時的なエラーから、永続的な故障などがあります。これは、最高品質のハードウェアであろうが量産品であろうが、最終的な顛末は同じです。

拡張性において、さらに重要になってきます。例えば、S3が数兆回ものトランザクションを処理しているときでも、ほんのわずかな可能性でも、それは現実に起こります。このような故障のシナリオの多くは事前に予知できますが、設計や構築時点では知る由もありません。

我々は、故障が何なのかは知らずとも、自然発生で起こる故障も冗長化しカバーできる構築が必要でした。システムがもし火事にあったとしても動作し続ける構造が必要なのです。システム全体をダウンさせることなく、個々のモジュールを管理できることが重要です。我々は、システム全体のヘルスチェックを可能にするような、故障発生時の影響範囲を管理する基本的な仕組みを開発しました。
 
3. フレームワークでなくプリミティブ

ほどなくして、AWSのサービスを利用したいと考えている企業の多くは既に何らかのAWSサービスを取り組んでいると気づきました。お客様が制約を許容し、過去のIT関連のハードウェアとデータセンターの世界と決別すると、前例のない使用パターンで構築し始めるということが起こりました。そのように、お客様のニーズに合ったものを確実に届ける為に、素早く動かざるを得ない状況でした。

もっとも重要な事のひとつに、小さなサービスやツールをお客様に届けるという事で、ひとつのフレームワークを強制されるよりも、キッチンの道具のようにすべてそろっていて組み合わせるように、AWSクラウドで実現できる最適な方法を選んでいただけるような構成にしていました。この方法はお客様の成功につながりましたし、後にAWSのサービスの基本的な製品/サービスの考え方をして活用しています。

お客様がサービスを手に取り、使って構築するまで、どのような優先順位で対応すべきか予期することは難しい、ということに気付くのが重要です。最小の機能性でサービスをリリースし、お客様の要望に合わせてサービスのロードマップを作っています。

4. 自動化がカギ

サービスを構築するのと従来のソフトウェア開発でお客様に納品するのとは大きく異なります。拡張性の高いシステムを管理するには、お客様の期待する信頼性、パフォーマンス、スケーラビリティに合うようにする異なるマインドセットが必要です。できるだけ自動化を可能にし、マニュアル操作とエラーを事前に取り除く管理方法を実現するには自動化が重要なカギになります。実現するには、操作に重要となる機能を制御するAPIを構築する必要がありました。お客様にも同様に助けになることです。アプリケーションの構造を分解し、それぞれ管理用APIで、拡張可能でパフォーマンスとメンテナンス性に優れたルールを作ることができます。

5. APIは永続

アマゾンの小売りの経験から得たものでもありますが、AWSがAPI中心のビジネスになることはさらに重要です。お客様が我々のAPIを使ったシステムとアプリを構築し始めたのなら、お客様のビジネスに影響を与えるとして、APIを変更することは不可能になります。APIのデザインは非常に重要であり、正しく設計できるチャンスは一度きりだということを肝に銘じねばなりません。

6. リソースの使い方を知る

適切なサービス利用料を特定しサービスを見積もる際には、コストと運用の良いデータを手に入れることです。特に薄利多売のビジネスモデルにおいてです。AWSはコストを低減させるための努力を惜しまないため、お客様に届けるサービスも投資してもよいと思えるものであり、さらに値下げしても運用継続可能な範囲を見極め、利益を低価格という形でお客様に還元しています。

先の一例として、S3ではどの程度使用されるかパターンがわかりませんでした。ですから、ストレージとネットワークの帯域に対して主な課金を行うというように仮定しました。しばらく運用した後、リクエスト回数も同様に重要な指標だと気づきました。もしお客様がたくさんの小さなファイルを持っているとすると、ストレージと帯域は何百万件のリクエストであろうと計算しませんでした。我々は、AWSのビジネスが継続的なものになるよう、計算モデルを調整しなければなりませんでした。

7. ゼロからのセキュリティ対策

お客様をセキュリティの脅威から守ることは、運用の観点においても、提供するツールや仕組みにおいても、AWSとしては最優先すべき事項です。我々が永遠に投資をし続ける領域です。

素早く学ぶひとつのアプローチとして、最初にサービスを企画・設計する段階で、セキュリティ対策を組み込んでおくことが必須です。セキュリティの専門チームは、何かを構築してから検証するチームではありません。サービスが始まるその日からパートナーとして基本的なセキュリティが担保され強固であるか確認しています。セキュリティに関しては妥協しません。

8. 暗号化は最良の住人

暗号化はお客様にとってデータにアクセスする人に対する最大の制御方法であると言えます。10年前、暗号化のツールやサービスは使いにくく、我々のサービスにどう組み込むのがベストか検討しました。

暗号化はコンプライアンス順守の観点で、サーバーサイドの暗号化をS3で実装しました。もしあなたがデータセンターでディスクをのぞき見しようとしても、どのデータへもアクセスはできないでしょう。しかし、Amazon CloudHSMと後のAmazon Key Management Serviceを使えば、お客様は独自キーの管理とそれを使った暗号化ができるようになります。

今では、暗号化対応は新サービスには企画・設計段階で統合されています。例えば、Amazon Redshiftは、それぞれのデータブロックはデフォルトでランダムキーで暗号化され、そのキーの集合はマスターキーで再度暗号化されています。マスターキーはお客様だけが知る唯一のキーで、ビジネスデータまたは個人情報にアクセスするための復号キーとなります。

暗号化は我々のビジネスにとって優先度の高い事項です。お客様にとってより簡単に使える暗号化の手段を継続して提供し、データやお客様をより強固に守ります。

9. ネットワークの重要性

AWSは多くの異なるワークロードに対応してきました。高トランザクション処理から動画変換、高度計算処理から大量のウェブアクセスまで規模を拡大しながら対応できます。これらのワークロードはネットワークにおいては独自の要件があります。

AWSはデータセンターの構成や運用に対して独自のスキルを有しており、お客様のワークロードがいかなるものであっても、それに対応した柔軟なネットワークインフラを持っています。我々は、お客様の達成したい目標に合わせて実現することに対して、ハードウェアまで独自に構築することもいといません。つまり、とても特殊な要件に対しても実現することを可能にし、AWSのネットワークを使用すればお客様が高いセキュリティの担保と差別化が可能になります。

どのようにAWS指定のネットワークハードウェアとソフトウェアでお客様のパフォーマンス改善しているかという成功事例でいうと、仮想マシンから仮想化されたネットワーク上での負荷を分散し解決する事でした。なぜならば、ネットワークアクセスは共有リソースであり、お客様が以前ネットワークアクセスで遅延を感じたこともあるからです。シングルルートの仮想I/Oに対応したNICの開発は独自のVMのハードウェア上にある仮想化NIC実装を可能にしました。これにより遅延に関しては2倍以上高速になり、ネットワーク上の実測では10倍もの改善になっています。

10. イノベーションに制限なし

AWSは、お客様に対して幅広で深いプラットホームを実現する為、様々な機能やサービスを提供しています。しかし、AWSはインハウスで構築するサービスはそれほど多くありません。パートナーエコシステムを活用し、様々な新たな方向にプラットホームを拡張しています。

例えば、StripeというパートナーはTwilioがAWS上でビジネスができるよう支払いサービスを提供しています。お客様の多くは提供するサービスの深さに対応する為のAWS上のサービスを構築しています。Philipsは健康に関するデジタルプラットホームを健康維持のためのデータ管理に使っています。OhpenはAWS上に少額バンキング向けのプラットホームを構築しています。Eagle Genomicsはゲノム解析のプラットホームを構築しています。他にもいろいろあります。肝心なことは、AWSプラットホーム上には、制限をかけるものは何もないので、やりたい事を実現すればいいのです。「制限がない」というのは、イノベーションに向けた開放で、思いがけない多くの発明の扉を開けるでしょう。

我々が今後学んでいくことが何か楽しみにしています。AWSのお客様が10年後に達成していることもです。覚えておいてください、今日がいつでも「初日」(Day 1)であることを・・・

--------------------

 

(翻訳は石橋が担当しました。)

 

 

コメント

Featured Event

2016年3 月

    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31