Developers.IO 2017セッション「基調講演:History of AWS, Still Halfway through」で話しました #cmdevio2017

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

クラスメソッドが運営するIT系技術ブログDevelopers.IOのカンファレンスイベントDevelopers.IO 2017にて、セッション「基調講演:History of AWS, Still Halfway through」を発表しました。そのレポートです。

登壇前に緊張しているのがこちらの僕です。

DDnVQdSU0AA33XH

発表スライド

動画

基調講演:History of AWS, Still Halfway through

今日のアジェンダ

今日は4つのことを話します。

  • これまでのAWS
  • 今のAWS
  • これからのAWS
  • これからの僕たち

これまでのAWS

AWSの歴史

簡単にAWSの歴史を振り返ります。

  • 1995年、ECサイトであるAmazon.comがサービスインしました。スライドで紹介しているのがAmazon.comの初期のWebサイトです。現在と違ってテキスト中心のシンプルなものですね。Amazon.comを運営する上で発生したビジネス課題を解決するために、Amazon.comのインフラがどんどん開発されていきました。
  • そのインフラをAmazon.com以外の方にも使ってもらおうと、外部公開され始めます。まず最初に2004年11月、Amazon Simple Queue Service(SQS)がベータリリースされました。
  • その2年後の2006年3月、Amazon S3がリリースされました。このタイミングからAmazon Web Serivcesが正式にサービスインしました。
  • その4ヶ月後の7月、Amazon SQSが正式にリリースされます。
  • そして2006年8月にAmazon EC2がベータリリースされました。この後、どんどんサービスがリリース、機能拡張がされていきます。
  • そして日本において大きな転機になったのが、2011年3月の東京リージョン開設です。この後、日本でも多くの企業がAWSを利用するようになりました。
  • それからもAWSは多くの機能改善や新機能リリース、新サービスのリリースを続けています。東京リージョンが開設された2011年には82回でしたが、2015年には大凡9倍の722回、そして2016年には1000回を超えるリリースを続けています。
  • 現在AWS管理コンソールを開くとこんな感じです。数えると72ありました。すごく多いですね。

では実際に、AWSは日本国内でどのように使われてきたのでしょうか。

スタートアップ

まず最初にAWSを使い始めたのはスタートアップ企業でした。スタートアップ企業には以下の課題がありました。

  • スタートアップ企業は大抵の場合会社規模が小さく、インフラへの投資は最小限に抑えたいという思いがあります。サービスを開始するにあたりハードウェアを購入すると、そのハードウェアは有形固定資産になり、減価償却に5-6年かかります。また、専任のインフラエンジニアを採用するとそこでも人的コストがかかります。
  • ネットワークやハードウェア障害のために24時間365日でエンジニアを貼り付けると、そこにも人的コストがかかります。また、運用時に必要となるハードウェア保守費用は一般的に高額なケースが多く、サービスの開発費を圧迫してしまいます。
  • スタートアップビジネスとして一番重要なのは「安定したサービスをいかに早く提供するか」であり、障害対応に時間やコストをかけるより、サービス開発に注力したいと考えています。
  • スタートアップのような新規事業は市場に出してみないと成功するか失敗するかがわかりません。失敗した場合には早期に撤退し、損失を最小限にしたいと考えますが、ハードウェアやソフトウェアライセンスを購入してしまっていると、撤退後は無駄になってしまいます。
  • 新規サービスは当初はアクセスが少ない事が多いため、初期は低コストで小規模にスタートし、ビジネスがスケールした後にインフラもスケールしたいです。

では、スタートアップ企業がAWSを採用することで何が解決できるのでしょうか。

  • 1つはハードウェアの購入が費用なことです。AWSは従量課金であり、使った分だけしか費用が発生しないので、無駄に高性能のハードウェアを大量に抱え込む必要がありません。インフラを自前で持たないため、ネットワークやハードウェアといった低レイヤーの運用保守はAWSに任せて意識する必要がありません。ハードウェアの購入コストや低レイヤーの運用保守にかかる人的リソースを、本来ビジネスであるサービス開発に注力することが出来ます。
  • 2つめに、スモールスタート可能なことです。小規模・小コストでサービスを開始する事ができます。サービスがヒットしたらインフラをスケールアップ・スケールアウトさせることでコストの最適化が出来ます。
  • 3つめが即撤退可能なことです。事業が失敗したらリソースを削除するだけで、速やかに撤退可能です。

Webシステム

次にWebサービス、Webサイト、ECサイトといった、Webシステムです。特に既存システムより新規のシステムでAWSを選択する事が多くなりました。既存システムをAWSに移行する場合、一部で設計変更が必要な場合がありますが、そのためのシステム改修コストはなかなか掛けづらいというケースが多いです。また移行の場合にはデータ移行のリスクを考える必要があります。移行時のデータ欠損や移行後のデータ整合性の検証、移行に伴うシステム停止などです。新規システムであれば最初からAWSの古マネージドサービスを活用した形で設計出来るため、クラウドネイティブの恩恵を受けることが出来ます。また、当初は一般的なコーポレートサイトのような静的なwebコンテンツが利用が始まりましたが、多くの事例が公開されると共に、徐々にCMSやECサイトのような動的コンテンツでもAWSが活用されるようになりました。

WebシステムがAWSを採用することで解決できることをご紹介します。

  • 1つはリードタイムの縮小です。新規システムを立ち上げるためにハードウェアを購入すると、納入期間がかかります。短くても1週間、長ければ月単位で時間がかかってしまいます。AWSであればインフラがすぐに手配可能なため、新サービスを立ち上げるためのリードタイムが縮小できます。初期コストも最小限に抑えることが出来ます。
  • 2つめは環境の複製が容易なことです。CloudFormationで環境をテンプレート化しておけば、本番環境と同じ構成の開発環境や検証環境をすぐに手に入れることが出来ます。
  • 3つめはWebシステムにとって必要なサービスがフルマネージドで提供されていることです。もともとAWSはAmazon.comのインフラをサービスとして提供したものであるため、Webシステムとは相性が良いです。例えばWebサービスの可用性確保に必要なロードバランサーやCDNがサービスとして提供されていますし、Webシステムにありがちなバーストトラフィック時には簡単にシステムリロースをスケールアップ/スケールアウトする事ができます。

モバイル

次にモバイルです。ここ10年でスマートフォンが爆発的に普及し、モバイルアプリの利用が一般的になりました。モバイルの特徴として、PCよりも手軽にサービスを利用可能という点が挙げられます。PCの場合は自宅や会社など座席での利用が多いですが、モバイルの場合は常に持っていて手軽にアクセス出来るという特性から、通勤時間や深夜など、アクセス時間帯にばらつきがあります。モバイルアプリのサーバーサイドとしては、アクセスの多い時間はスケールアウトし、少ない時間はスケールインすることで、インフラにかかるコストの最適化を行いたいという課題がありました。

そこでモバイルアプリのインフラでもAWSが利用されるようになりました。

  • モバイルアプリも当たり外れが大きいため、最初はスモールスタートし、ユーザーの増加に合わせてスケールしたいですし、外れたら即撤退したいです。AWSはそのニーズ通りの使い方が出来ます。
  • モバイルアプリで必要な機能がフルマネージドサービスとして提供されています。例えば認証であるCognito、通知で使えるSNS、キューサービスのSQS、メール通知で組み込めるSES、キーバリューストアであるDynamoDBなどです。これらを活用することで、モバイルアプリの開発をスピードアップさせる事が出来ます。現在ではモバイルアプリのサーバーサイドはサーバーレス構成が一般的になってきており、API Gateway + Lambdaで作られることが多いです。

ゲーム

ゲームでも同様にAWSが活用されるようになりました。かつてブラウザゲームが大流行していた時代はまだVPSが主流でした。しかしスマートフォンが普及すると、PCよりスマートフォンからのほうが簡単にゲームにアクセスしプレイ出来るため、モバイルアプリによるゲームが一般的になり、ゲームインフラに対するアクセスが増加しました。これに伴い、ゲームインフラにも高可用性と拡張性が求められるようになりました。 また、コンシューマー機がハイスペック化することでオンラインゲームが一般的になりました。例えばPCでもSteamといったオンラインのゲームサービスを利用する事が普通になっています。こうしたオンラインゲームの普及により、世界中の人が同じゲームを遊べるようになり、グローバル名ゲームタイトルが増加しました。その結果、色んな国から同時に同じゲームで遊べるように、ゲームインフラにもグローバルが求められるようになりました。

ゲームインフラがAWSを採用することで解決する大きな課題はグローバルプラットフォームです。AWSは現在(GovCloudと北京リージョンを除いて)14のリージョンが世界中にあります。AWSのグローバルなインフラを利用することで、世界各地から同じオンラインゲームを低いネットワークレイテンシで楽しむ事ができます。自分たちでこれだけのグローバルなプラットフォームを作ろうとするのは大変です。また、スケールが自在なため、アクセスが集中する時間帯にはリソースを増強する事もできますし、逆にアクセスが減るタイミングではリソースを削減する事ができます。さらに地域に合わせたスケールも出来ます。例えばアメリカのユーザーが多いゲームではアメリカのリージョンは増強し、逆にアジアのユーザーが少ないのであればアジアのリージョンは削減することで、コストの最適化が出来ます。

ビッグデータ

次にビッグデータです。パブリッククラウドが普及することでデータストレージの価格が低下したことにより、ほぼ無限のデータストレージが安価に使えるようになりました。これで過去に蓄積していたデータをクラウド上にアップロードする事ができますし、更に今後どんどんデータを蓄積することが出来ます。こうして過去溜め込んできたデータを含めた大量のデータをどう活用するかが検討されるようになり、データを分析し傾向を把握しビジネスに役立てるための、ビッグデータ分析が多くの企業で一般的に行われるようになりました。クラスメソッドでも多くのお客様がビッグデータを活用しビジネスを急成長させています。

そして、ビッグデータ分析に必要なものがすべて揃ってるのがAWSです。

  • イレブンナインの耐久性を誇るS3。分析したいデータはとりあえずS3にアップロードしておけば、安価に、かつ高い耐久性で、データを貯めておく事ができます。
  • 高速、フルマネージドなデータウェアハウスであるAmazon Redshiftがあります。S3に蓄積したデータはRedshiftにインポートしておくことで簡単に分析可能になります。インポートし終わったデータはS3上から削除するか、より安価にデータ保管が可能なGlacierに貯めておくことが出来ます。
  • データを蓄積する事が出来たので実は可視化です。AWSには高速なクラウドBIサービス、Amazon Quicksightがあります。Redshiftに入れたデータを高速かつ簡単に可視化する事が出来ます。

エンタープライズとパブリックセクター

最後に、エンタープライズとパブリックセクターについてです。近年、数百大規模の大規模クラウドマイグレーションが増えてきています。これまでご説明したようなWebシステムやモバイルなどの新規事業だけでなく、基幹システムをAWSへ移行するのが最近のムーブメントだと感じています。その理由は専用線など高速なデータ回線が普及したことと、インターネットを介してもセキュアにデータ通信が出来るようなソリューションが増えたことです。日本においては東京リージョンが出来て6年が経っており、AWSは「様子見」のフェーズをとっくに超えました。このため、オンプレミスの減価償却やデータセンターの更新タイミングに合わせてAWSの導入を検討するエンタープライズ企業が増えてきています。

パブリックセクターでも同様です。大学などの研究機関では、研究者が使うハードウェアを購入した場合、購入時点のスペックを使い続ける必要がありました。AWSを利用することで常に最新のリソースを研究者に提供することが出来る、というメリットについての認識が広がってきたと思います。

国内のパブリッククラウド市場の状況

こうして日本国内においてもAWSの利用は一般的になりました。先日のPublickeyさんの記事で、国内のパブリッククラウド市場でにおいて、1/4の企業がAWSを活用しているという調査結果がありました。またに既に普及期にあると言って良いでしょう。

今のAWS

それでは現在のAWSがどのように使われているかをご紹介します。

IaaSからPaaSへ、PaaSからSaaSへ

SaaSという言い方は異論があるかも知れませんが、現在のAWSはインフラとしてのサービスだけではなく、プラットフォーム、更にサービスを提供するようになってきました。例えばWorkspaces、Workdocs、Workmail、Chime、Connectといった、AWSだけで完結できる多種多様なサービスが提供され始めています。

なぜこのような変化があるのでしょうか。理由はCustomer want、顧客が欲しいと言うから、があると僕は思います。AmazonやAWSの文化として「顧客が欲しいものを提供する」があります。そして顧客の「まるっとお任せしたいという要求」が、SaaSのようなサービスを提供するようになってきたのでしょう。

DevOps

近年、AWSはDevOpsに役立つサービスを多数リリースしてきました。

  • AWS CodeCommit … プライベートGitリポジトリ
  • AWS CodePipeline … CD(継続的デリバリ)
  • AWS CodeBuild … ビルド&テスト
  • AWS CodeDeploy … デプロイ自動化
  • AWS CodeStar

CodeStarは04/19に開催された『AWS Summit in San Francisco』で発表された新サービスで、CodeCommit、CodePipeline、CodeBuild、CodeDeployと、それらに付随する実行環境を一撃で構築・管理する事が出来るものです。これらのAWSのフルマネージドサービスを活用することで、開発プロセス自体を改善し、よりビジネススピードにマッチしたサービス開発とリリースが可能になります。

DevSecOps

AWSにはAPI連携可能なセキュリティサービスが多数あります。

  • AWS IAM … AWSリソースへのアクセスコントロール
  • AWS KMS … 暗号化キー管理
  • AWS CloudTrail … API証跡監査
  • Amazon Inspector … セキュリティ評価
  • AWS Certificate Manager … SSL/TLS証明書管理
  • AWS WAF & Shield … WAFとDDoS対策

これらを活用することで、DevOpsのプロセスに簡単にセキュリティプロセスを組み込むことが可能です。

Enterprise Migration

大規模なクラウドマイグレーションを支援するサービスのリリースが最近増えています。

  • AWS Directory Service ... Microsoft ADに接続可能なディレクトリサービス
  • AWS Database Migration Service(DMS) / Schema Convertion Tool (SCT) ... データベース移行
  • AWS Server Migration Service(SMS) ... VMwareサーバー群の移行プロセス自動化
  • Amazon Snowball ... 大容量データ転送サービス

このように移行プロセスを支援するためのサービスが増えており、実際に弊社でも移行案件の問い合わせが増えています。

AI/ML

近年、ビッグデータ分析は一般に普及しました。主な理由は3つあります。

  • POS端末やIoTセンサーなど、データを集めるデバイスが極小化及び安価になり、収集出来るデータ自体が増えた。
  • 収集したデータをアップロードするためにはネットワークが必要だが、モバイル回線やWi-Fiなどのネットワークが普及した。
  • パブリッククラウドが普及したことによりデータを蓄積するためのデータストレージが安価になった。

こうして大量のデータを安価に保持することが可能になり、ビッグデータ分析が多くの企業で行われるようになると、次にビッグデータの活用としてディープラーニングや統計的自然言語処理をビジネスに役立てようという動きが広まり、現在で第3次AIブームと言われています。そしてAWSもAI/MLに関するサービスを提供しています。

  • Amazon ML ... 機械学習モデルの作成と実行
  • Amazon Polly ... テキストを読み上げて音声に変換
  • Amazon Rekognition ... 画像解析
  • Amazon Lex ... 音声読み上げサービス

Alexa

そしてAlexaです。Amazonが提供するクラウドベースの音声認識サービスであるAlexaは、今年1月に米国で開催されたCES2017では700社がAlexa搭載製品を発表するなど、グローバルでは非常に盛り上がっているプラットフォームです。そして音声から処理を実行するプログラム(Skill)はLambda Functionであり、AWS上で実行されます。Amazon Alexaの拡大により、AWSの重要性は今後更に増すと思われます。

いくつかAlexaの活用事例をご紹介します。

  • アメリカのドミノピザは、Amazon Echoによってピザの注文や注文の追跡が可能なスキルをリリースしています。
  • Uberもスキルを公開。Amazon Echoから配車を依頼したり、配車の現在の位置を確認できます。
  • 1-800-Flowersのスキルを使えば音声で簡単に花を贈ることができます。
  • スマートホームデバイスを販売しているAlarm.comのスキルでは、自社デバイスの操作を音声で行うことができます。例えばドアの施錠や温度操作、照明操作が出来ます。
  • コネクテッドカーの分野では、フォードが車にAlexaを搭載する計画を発表、カーナビの操作や音楽再生、ライトやセキュリティシステムを音声で操作することが可能になります。
  • そして我々クラスメソッドは、Amazon Alexa技術に特化した専門部署を新設、海外のグループ会社を通じてAlexaの設計開発を行っています。

これからのAWS

ではこれからのAWSはどのように進化していくのでしょうか。幾つか予想してみました。

SaaS

まずSaas的なサービスです。今後もインフラとして使われるサービスだけではなく、単体でサービスとしてパッケージ化されたものが提供されるだろうと思います。このサービスを利用すれば、ユーザーはハードウェアやミドルウェアといった低いレイヤーを意識する必要はありませんし、可用性もセキュリティもAWSが担保してくれます。スピードやコストの面から、パブリッククラウドを上手く活用することは我々のビジネスのスピードアップに繋がります。適材適所で導入する事が増えるでしょう。

AI

Alexaの普及に従い、今後もAI系サービスが多数リリースや機能拡張は続くだろうと思います。例えばEcho Lookでは、2つの写真のうちどちらの服がお勧めかを教えてくれます。このように、Alexaは既に音声だけのサービスでは無くなりつつありますので、画像認識以外にもいろんなことが出来るようになるのではないでしょうか。それに伴ってAWSのAI系サービスも増えるだろうと思います。

しかし、AIは万能の武器ではなく、活用のストーリー自体は人が考える必要があります。適切なストーリーを構築しシステムに組み込むことで、より利便性の高いサービスを提供することができます。ビジネスにAIを活用するシーンは今後増え続けるでしょう

Enterprise

前述の通り、大規模システムのAWS移行は今後も続くと思います。そして移行だけでなく、大規模な新規システムの構築もAWSが選ばれるでしょう。

移行については、旧態依然の大人数が張り付いて行うような移行はもう重要ではありません。必要なのはエンジニアの頭数ではなく、各種ある移行支援サービスを活用した、効率良く早く確実な移行が出来るエンジニアです。もちろん移行設計が必要なくなる訳ではありません。システム移行を考える上では、移行方針や移行ツールの選定、データ移行方式の策定、システム停止時間の検討、移行データの検証が重要になります。こういったスキルを持ったエンジニアは今後ますます重宝されるのではないでしょうか。

Regional

現時点では、AWSの導入はまだまだ関東や関西などが中心です。これは日本のビジネス自体がどうしても関東や関西が中心であり、他の地方のビジネス規模が小さいが故です。しかし、AWSの特性であるスモールスタート可能、スケールが自由、費用対効果の高さなどは、小規模システムでも有効です。これからは地方においてもAWS導入がより一層進んでいくのではないでしょうか。

ぜひ地方からも、グローバルに展開するような熱いサービスがAWS上でどんどん生まれてほしいと思います。僕自身が北海道民なだけに、地方には強く思い入れがあります。

これからの僕たち

少しだけ僕の話をさせてください。僕自身は北海道で中小企業に就職し、大手のSIベンダに10年以上常駐していました。そこではインフラエンジニアとして、自治体や大学などのパブリックセクターを中心に、基幹ネットワークや付随するサーバーの設計構築を行っていました。しかしオンプレミスの経験のみを積み続けることで次の10年間エンジニアとして戦い続けられるかが不安になり、危機感を感じて、クラウドの世界に転職しました。

そして今、僕の居場所は、Developers.IO。僕たちの技術ブログです。今の僕は、クラスメソッドのエンジニア仲間と一緒に、常に最新の技術動向を勉強し続け、吸収した知識はDevelopers.IOにアウトプットしています。皆さん、ブログ見て頂いてますか?僕たちはとても楽しみながらアウトプットしています。Developers.IOは僕たち自身のアウトプットですが、それを読んでくれた皆さんが、ブログやSNSや皆さんの会社内など、様々な形でアウトプットしてくれると信じています。そしてそれを見たエンジニアが、また違う形でアウトプットしていきます。

アウトプットは連鎖し、繋がっていきます。

たくさんのエンジニアが、自分がインプットした知識を消化しアウトプットすることで、また別のエンジニアがそのアウトプットをインプットして、そうしてエンジニアの世界はどんどん盛り上がっていくはずです。でも今はまだ道半ばです。もっともっとみんなでアウトプットして、アウトプットを連鎖させて、エンジニアが楽しい世界にしていきたい。僕はそう思います。

今日のイベントのハッシュタグは #cmdevio2017 です。ぜひSNSやブログでフィードバックしてください。そして皆さんが今日のイベントで何か得て頂けたのならば、それもSNSやブログでアウトプットしてほしいです。

僕たちみんなで、エンジニアの世界を盛り上げていきましょう。

まとめ

今後ともDevelopers.IOをよろしくお願いします!

Special Thanks